Re: git: 1d577bedbae8 - main - unbound: Fix config file path

In message <202301181640.30IGeTbo010751@gndrsh.dnsmgr.net>, "Rodney W. 
Grimes"
writes:
> > 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 sy
> stem
> > > .
> > >
> > > 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 igno
> res 
> > > 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-set
> u
> > 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.

Hmm.

slippy$ lh /etc/unbound
ls: /etc/unbound: No such file or directory
slippy$ 

cwsys# lh /etc/unbound
ls: /etc/unbound: No such file or directory
cwsys# 

Seems it got deleted on two of my systems and never recreated.



>
> Just make the change I suggested and all is fine...

On second thought, if the comment in the commit log is correct, the change 
you suggested would break running unbound chroot. Or do I misunderstand?


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0