+++ This bug was initially created as a clone of Bug #2129466 +++

Description of problem:

Running systemctl status named-chroot-setup throws an error

1. systemctl status named-chroot-setup.service
   ○ named-chroot-setup.service - Set-up/destroy chroot environment for named (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot-setup.service; static)
   Active: inactive (dead) since Thu 2022-09-22 15:27:40 PDT; 13min ago
   Process: 933 ExecStart=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files (code=exited, status=0/SUCCESS)
   Process: 1040 ExecStop=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files (code=exited, status=0/SUCCESS)
   Main PID: 933 (code=exited, status=0/SUCCESS)
   CPU: 80ms

Version-Release number of selected component (if applicable):

Fresh install of RHEL 9.0

bind-license-9.16.23-1.el9.noarch
bind-libs-9.16.23-1.el9.x86_64
bind-utils-9.16.23-1.el9.x86_64
bind-dnssec-doc-9.16.23-1.el9.noarch
bind-dnssec-utils-9.16.23-1.el9.x86_64
bind-9.16.23-1.el9.x86_64
bind-chroot-9.16.23-1.el9.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Install RHEL 9
2. Install Bind packages listed above
3. Run systemctl status named-chroot-setup.service

Actual results:

1. systemctl status named-chroot-setup.service
   ○ named-chroot-setup.service - Set-up/destroy chroot environment for named (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot-setup.service; static)
   Active: inactive (dead) since Thu 2022-09-22 15:27:40 PDT; 13min ago
   Process: 933 ExecStart=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files (code=exited, status=0/SUCCESS)
   Process: 1040 ExecStop=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files (code=exited, status=0/SUCCESS)
   Main PID: 933 (code=exited, status=0/SUCCESS)
   CPU: 80ms

Sep 22 15:27:38 systemd[1]: Starting Set-up/destroy chroot environment for named (DNS)...
Sep 22 15:27:38 setup-named-chroot.sh[979]: ls: cannot access '/var/named/chroot/usr/lib64/named': No such file or directory
Sep 22 15:27:38 setup-named-chroot.sh[981]: mount: /var/named/chroot/usr/lib64/named: mount point does not exist.
Sep 22 15:27:38 systemd[1]: Finished Set-up/destroy chroot environment for named (DNS).
Sep 22 15:27:39 systemd[1]: Stopping Set-up/destroy chroot environment for named (DNS)...
Sep 22 15:27:40 systemd[1]: named-chroot-setup.service: Deactivated successfully.
Sep 22 15:27:40 systemd[1]: Stopped Set-up/destroy chroot environment for named (DNS).

Expected results:

Expected bind-chroot-9.16.23-1.el9.x86_64 to find and mount /var/named/chroot/usr/lib64/named in chroot

Additional info:

The dir is in the list to mount, and it exists in the main root, but the mount point does not exist in the chroot (installed by named-chroot package):

[root@staypuft:~]# egrep "lib64/named" /etc/named-chroot.files
/usr/lib64/named

1. ls -ald /usr/lib64/named
   drwxr-xr-x. 2 root root 28 Sep 20 13:52 /usr/lib64/named

1. ls -al /var/named/chroot/usr/lib64/
   total 0
   drwxr-xr-x. 3 root root 18 Sep 22 15:45 .
   drwxr-xr-x. 4 root root 32 Sep 20 13:52 ..
   drwxr-xr-x. 2 root root 6 Nov 26 2021 bind

Since named-chroot creates the dirs in /var/named/chroot, and /var/named/chroot/usr/lib64/named does not exist and therefore cannot be chroot mounted, I believe this is an error in the package (in not creating that mount point).

— Additional comment from gmcnealy@redhat.com on 2022-09-24 00:24:48 CEST —

=== In Red Hat Customer Portal Case 03321528 ===
— Comment by Grant McNealy on 9/23/2022 6:24 PM —

Hello,

My name is Grant, I am with the Security and Services Group in North America and I will be taking ownership of this case.

I understand that you are experiencing an error with the package bind-chroot-9.16.23-1.el9.x86_64 not creating a mount

point in /var/named/chroot/usr/lib64/named chroot. I was able to recreate this issue in my test environment and I have opened

a bugzilla report for this issue.

named-chroot-setup.service - Set-up/destroy chroot environment for named (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot-setup.service; static)
Active: active (exited) since Fri 2022-09-23 17:32:58 EDT; 29min ago
Process: 2876 ExecStart=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files (code=exited, status=0/SUCCESS)
Main PID: 2876 (code=exited, status=0/SUCCESS)
CPU: 41ms

Sep 23 17:32:58 localhost.localdomain systemd[1]: Starting Set-up/destroy chroot environment for named (DNS)...
Sep 23 17:32:58 localhost.localdomain setup-named-chroot.sh[2933]: ls: cannot access '/var/named/chroot/usr/lib64/named': No such file or directory
Sep 23 17:32:58 localhost.localdomain setup-named-chroot.sh[2936]: mount: /var/named/chroot/usr/lib64/named: mount point does not exist.
Sep 23 17:32:58 localhost.localdomain systemd[1]: Finished Set-up/destroy chroot environment for named (DNS).

The bugzilla report is: Bug 2129466 - bind-chroot-9.16.23-1.el9.x86_64 fails to create mount point /var/named/chroot/usr/lib64/named in chroot

I will update this case every 15-30 days or as information is made available from our engineering team. Let me know if you have any other questions or concerns.

Best Regards,
Grant McNealy, RHCSA
1.888.GO.REDHAT
Red Hat Enterprise Linux 9.
Innovate. Optimize. Protect. Trust.
access.redhat.com/products/red-hat-enterprise-linux

— Additional comment from Petr Menšík on 2022-10-03 14:33:55 CEST —

Ah yes, there are two directories for /usr/lib64/bind and /usr/lib64/named. But in package files only %dir %

{chroot_prefix}/%{_libdir}/bind is mentioned, but %dir %{chroot_prefix}

/%{_libdir}/named is not. But because /etc/named-chroot.files lists /usr/lib64/named and that source directory exists, it checks whether target directory is empty. It is missing in this case and it should not.

Just adding %

{chroot_prefix}

/%{_libdir}/named between the chroot files should help.

— Additional comment from errata-xmlrpc on 2022-12-15 21:03:36 CET —

This bug has been added to advisory RHBA-2022:105606 by Petr Mensik (pemensik@redhat.com)

— Additional comment from errata-xmlrpc on 2022-12-15 21:03:37 CET —

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2022:105606-02
https://errata.devel.redhat.com/advisory/105606

— Additional comment from errata-xmlrpc on 2022-12-15 21:03:44 CET —

This bug has been added to advisory RHBA-2022:105606 by Petr Mensik (pemensik@redhat.com)