Re: git: 1d577bedbae8 - main - unbound: Fix config file path
- Reply: Cy Schubert : "Re: git: 1d577bedbae8 - main - unbound: Fix config file path"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 18 Jan 2023 16:40:29 UTC
> In message <202301181551.30IFpbRu010474@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > [ Charset UTF-8 unsupported, converting... ] > > > > > > > > > > On 18 Jan 2023, at 16:34, Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> wr > > ote: > > > > > > > > No, otis fixed it thus: > > > > -#define CONFIGFILE "/usr/local/etc/unbound/unbound.conf" > > > > +#define CONFIGFILE "/var/unbound/unbound.conf" > > > > > > > > > > > > > > I am suggesting that it should be > > > > #define CONFIGFILE "/etc/unbound/unbound.conf" > > > > > > > > ALL base system configuration files *should* be relative to /etc, not /va > > r. > > > > > > > > > > Would this need any mtree changes or similar? > > > > No, /etc/unbound is a symbolic link already installed by the build system, > > and /var/unbound is already a directory, again, installed by the build system > > . > > > > This is a one line change that actually makes the /etc/unbound link work > > correctly, without this change the binary has a hard coded path that ignores > > the > > /etc/unbound symbolic link and requires a recompile if I want to move > > things around, or maintanance of 2 symbolic links. > > > > Personally I dont see *why* unbound has a /var/unbound directory, can > > someone tell me why that was done? Is this some attempt and maintaining > > read only root? Does unbound scribble in the config directory, or > > is this simply mirroring some of the stuff that bind did? > > I see why it does this. Looking at usr.sbin/unbound/setup/local-unbound-setu > p.sh, it installs its config files in $workdir. Looking at git log > 49cede74eecf4 (SVN r255809), the last paragraph in the commit log entry > says: > > Note that these scripts place the unbound configuration files in > /var/unbound rather than /etc/unbound. This is necessary so that > unbound can reload its configuration while chrooted. We should > probably provide symlinks in /etc. > > Providing symlinks in /etc/unbound appears to be the correct solution. For the forth or fith time, there already IS a symbolic link etc/unbound -> ../var/unbound. Just make the change I suggested and all is fine... -- Rod Grimes rgrimes@freebsd.org