FS#63897 - [unbound] use upstream default configuration file

Attached to Project: Community Packages
Opened by David Runge (dvzrv) - Monday, 23 September 2019, 20:47 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 26 September 2019, 06:14 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:Currently /etc/unbound/unbound.conf gets overwritten by a custom configuration file [1], that has only a very minimal subset of the settings, while an unpopulated template file is installed to /etc/unbound/unbound.conf.example [2].
This way it is impossible to properly follow upstream's changes (e.g. using pacdiff after upgrade) and it is also cumbersome to e.g. report problems to upstream with the default configuration (as it is not in place).

Please don't overwrite the default configuration but only modify the template (before build/installation) if really necessary in prepare().

I understand the idea to have the systemd service be able to start without configuration changes after installation (however, that's usually not what Arch does [3]). The user setup scenarios will vary widely.

Using sed, the two lines can be set in prepare() though:

```
sed -e 's|\# do-daemonize\: yes|do-daemonize\: no|g' \
-e 's|\# trust-anchor-file\: \"\"|trust-anchor-file\: /etc/unbound/trusted-key.key|g' \
-i doc/example.conf.in
```

After that, the custom install calls in package() and the custom configuration can be removed.

Thanks!

[1] https://git.archlinux.org/svntogit/community.git/tree/trunk/conf?h=packages/unbound
[2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/unbound#n64
[3] https://wiki.archlinux.org/index.php/Arch_Linux#Simplicity

Additional info:
* package version: unbound 1.9.3-3
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

* install unbound
This task depends upon

Closed by  Gaetan Bisson (vesath)
Thursday, 26 September 2019, 06:14 GMT
Reason for closing:  Implemented
Additional comments about closing:  unbound-1.9.3-4 in [community]
Comment by Gaetan Bisson (vesath) - Tuesday, 24 September 2019, 07:21 GMT
Sounds good. I'll implement this tomorrow or the day after if there are no objections. Thanks again for the suggestion.
Comment by Jensen McKenzie (your_doomsday) - Wednesday, 25 September 2019, 18:18 GMT
@vesath I recommend to cherry-pick more upstream fixes for systemd service file:
https://github.com/NLnetLabs/unbound/commit/ae2d5276d27f16044382ce49eb2e2459e073e619
https://github.com/NLnetLabs/unbound/commit/acdd4058d27ede378d0ab720df8a61d7a50189b1
https://github.com/NLnetLabs/unbound/commit/6943cab6708761c64e8eb55f2d4bbc5660871ff3

After that you shouldn't need setting "do-daemonize: no" in config.

Also there was an old idea about providing (https://bugs.archlinux.org/task/59606):
"include: "/etc/unbound/unbound.conf.d/*.conf"

so users won't need to overwrite default config but just add their own on top of it. I think implementing that would save people from many issues regarding to missed .pacnew file.

What I propose is:
1. Take verbatim unbound.conf from upstream
2. Add "include: "/etc/unbound/unbound.conf.d/*.conf" with sed to it.
3. Add /etc/unbound/unbound.conf.d/10-arch.conf with minimal arch specific config.
Comment by Jensen McKenzie (your_doomsday) - Wednesday, 25 September 2019, 18:22 GMT
@dvzrv regarding https://bugs.archlinux.org/task/63898

Those "run" and "dev" folders doesn't come from package but are created during runtime of unbound service. They are needed and created inside unbound chroot dir which resolves to /etc/unbound in Arch but it doesn't have anything to do with unbound user home dir.
Comment by Gaetan Bisson (vesath) - Thursday, 26 September 2019, 06:13 GMT
As stated in  FS#59606  I'm opposed to the idea of a /etc/unbound/unbound.conf.d/*.conf directory. The point of a simple configuration file is to be edited, not to refer to a bunch of other file with configuration values spread among them. What happens when a user sets in 20-my-custom-stuff.conf values incompatible with what we ship in 10-arch-defaults.conf? No configuration other than vanilla is going to be supported by me.

However, thanks for your suggestions, I've implemented all of them but the above. Cheers.

Loading...