FS#59606 - [unbound] use /etc/unbound/unbound.conf.d for user configs
Attached to Project:
Community Packages
Opened by Tommy Schmitt (spinka) - Friday, 10 August 2018, 14:52 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 05 September 2018, 21:16 GMT
Opened by Tommy Schmitt (spinka) - Friday, 10 August 2018, 14:52 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 05 September 2018, 21:16 GMT
|
Details
Description:
Recently there was a couple of bug reports about broken unbound configs for users who modified the original one and didn't merged pacnew changes. In debian they use a clever trick[0] to source user configs from /etc/unbound/unbound.conf.d/ so users don't have to change one provided by distro. Regardless of obvious need to handle pacnew for every Arch user, using debian approach may prevent such issues in future. To use debian approach we need to do following changes: 1. Add new directory in package section in PKGBUILD mkdir /etc/unbound/unbound.conf.d 2. Append below line at the end of provided unbound config: include: "/etc/unbound/unbound.conf.d/*.conf" [0] https://salsa.debian.org/dns-team/unbound/blob/master/debian/unbound.conf |
This task depends upon
Closed by Gaetan Bisson (vesath)
Wednesday, 05 September 2018, 21:16 GMT
Reason for closing: Won't implement
Wednesday, 05 September 2018, 21:16 GMT
Reason for closing: Won't implement
server:
use-syslog: yes
do-daemonize: no
username: "unbound"
directory: "/etc/unbound"
trust-anchor-file: trusted-key.key
# The following line includes user configuration files from the
# /etc/unbound/unbound.conf.d directory.
include: "/etc/unbound/unbound.conf.d/*.conf"
The sole purpose of our default /etc/unbound/unbound.conf is to provide a simple, working configuration so that users who do not wish to customize their resolver can get started right away. The same goes for the systemd service file we provide.
When a user modifies any of the default parameters, it is their responsibility to ensure the configuration remains consistent across files. Just as when you patch a piece of code, you have to properly maintain it as a fork or risk seeing your patch fail in the future.
In that respect, shipping more complicated configuration files seems counterproductive to me. However I'm open to hearing others' perspectives on this so I'll leave this report open for a while. Cheers.
In my approach, the main config file stay simple as before with assumption that most people won't change the few defaults which are there. There is no need for any customisation to get started right away.
When users want to add their modifications they wouldn't need to touch default config (and handle pacnew after Arch config update) but put them to /etc/unbound/unbound.conf.d/*.conf . This brings isolation between distro config and user config (similar how editing systemd units works).
Of course if nobody thinks this is better approach feel free to close this. Thanks for your attention.