bind-chroot queries on symbolic Links to named.conf

[Grant Taylor]

On 12/9/21 12:18 AM, Harshith Mulky wrote:
> Hello Experts

Hi,

I'm fairly certain that I'm not an expert, but I've dealt with BIND in 
chroot recently.

> I need some help with bind-chroot
> 
> We are running below version of bind and bind-chroot
> 
> bind-9.11.2-lp151.10.1.x86_64
> bind-chrootenv-9.11.2-lp151.10.1.x86_64

First, which platform and version?

> Our Automation code is running to add Zone files to 
> /var/lib/named/etc/named.conf only and not to /etc/named.conf

Is that the path that your automation is using?  Or is that the path to 
the named.conf file independent of your automation's influence?

> So in order to reflect the zone files created in 
> /var/lib/named/etc/named.conf in /etc/named.conf, i created a symbolic 
> link in /etc as "ln -s /var/lib/named/etc/named.conf named.conf" to 
> reflect as below
> lrwxrwxrwx 1 root root 29 Dec  9 11:03 named.conf -> 
> /var/lib/named/etc/named.conf

Please clarify, was this done outside of the chroot or is this a 
reference to /etc/named.conf inside the chroot?

> Now, when I make changes to file in /var/lib/named/etc/named.conf and do 
> a "service named restart"
> The file in /etc/named.conf fails to Load

Is this "/etc/named.conf" inside of or outside of the chroot?

> Error messages in /var/log/messages as below
> 
> 2021-12-09T11:04:46.684677+05:30 lavasadns1 systemd[1]: Stopped Berkeley 
> Internet Name Domain (DNS).
> 2021-12-09T11:04:46.685049+05:30 lavasadns1 systemd[1]: Starting 
> Berkeley Internet Name Domain (DNS)...
> 2021-12-09T11:04:46.735359+05:30 lavasadns1 named.init[2509]: Starting 
> name server BIND cp: cannot stat '/etc/named.conf': No such file or 
> directory
> 2021-12-09T11:04:46.844546+05:30 lavasadns1 named.init[2509]: open: 
> /etc/named.conf: file not found
> 2021-12-09T11:04:46.847806+05:30 lavasadns1 systemd[1]: named.service: 
> Control process exited, code=exited status=6
> 2021-12-09T11:04:46.848137+05:30 lavasadns1 systemd[1]: Failed to start 
> Berkeley Internet Name Domain (DNS).
> 2021-12-09T11:04:46.848475+05:30 lavasadns1 systemd[1]: named.service: 
> Unit entered failed state.
> 2021-12-09T11:04:46.848772+05:30 lavasadns1 systemd[1]: named.service: 
> Failed with result 'exit-code'.
> 2021-12-09T11:05:31.657460+05:30 lavasadns1 systemd[1]: Starting 
> Berkeley Internet Name Domain (DNS)...
> 2021-12-09T11:05:31.666976+05:30 lavasadns1 named.init[2573]: Name 
> server configuration file /etc/named.conf does not exist.
> 2021-12-09T11:05:31.667600+05:30 lavasadns1 systemd[1]: named.service: 
> Control process exited, code=exited status=6

This is almost certainly from viewed as inside of the chroot.  Thus it 
is quite likely really the /var/lib/named/etc/named.conf file, assuming 
that's the proper path for the chroot.

> and the Symbolic link changes color to Red.

That sounds to me like the sym-link is broken.  I don't know what is 
creating the break.  Either it was broken in the first place (bad paths 
used when creating it) or something removed / moved files. Or....

> Why is this happening?

Not yet.

> And how can avoid this error

You're going to need to do some more investigation to identify the 
underlying cause.

If things work properly before automation and then break after 
automation I'd guess that automation is doing something that is 
incompatible with how you're trying to do things.

I'd suggest looking at the output of "namei -l" on any and all 
named.conf (et al.) files involved using any and all paths, both before 
and after automation.  Hopefully that will give some more information as 
to what might be wrong.

Note:  If you don't have namei installed, you can get similar 
information manually by doing an ls -l on each component in the path; 
/etc/named.conf becomes /etc/named.conf, /etc, and /.  Namei just makes 
that much more convenient, especially for deeper files.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20211209/c3c5b6d6/attachment.bin>