bind-chroot, runs, works, dies

toddandmargo toddandmargo at zoho.com
Wed Aug 9 22:14:00 UTC 2017


Hi All,

Help!

Fedora 26 x64
Xfce 4.12

# rpm -qa \bind\*
bind-libs-lite-9.11.1-2.P2.fc26.x86_64
bind99-libs-9.9.10-1.P2.fc26.x86_64
bind-chroot-9.11.1-2.P2.fc26.x86_64
bind-license-9.11.1-2.P2.fc26.noarch
bind-9.11.1-2.P2.fc26.x86_64
bind-libs-9.11.1-2.P2.fc26.x86_64
bind99-license-9.9.10-1.P2.fc26.noarch
bind-utils-9.11.1-2.P2.fc26.x86_64I have a weird one. I am trying to set up bind-chroot. When I run it, it works
for about 30 seconds, then dies. And for the entire 30 seconds, it works
beautifully. I can go anywhere with Firefox and look up anything with "host". Then it breaks my heart.
 # systemctl start named-chroot Job for named-chroot.service canceled.  This is my error logs:
 Aug 8 15:58:49 FedoraServer named[10120]: all zones loaded Aug 8 15:58:49 FedoraServer named[10120]: running Aug 8 15:58:49 FedoraServer named[10120]: zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug 8 15:58:49 FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) Aug 8 15:58:49 FedoraServer systemd: named-chroot.service: PID file /var/named/chroot/run/named/named.pid not readable (yet?) after start: No such file or directory Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: Start operation timed out. Terminating. Aug 8 16:00:19 FedoraServer named[10120]: shutting down Aug 8 16:00:19 FedoraServer named[10120]: stopping command channel on 127.0.0.1#953 Aug 8 16:00:19 FedoraServer named[10120]: stopping command channel on ::1#953 Aug 8 16:00:19 FedoraServer named[10120]: no longer listening on ::#53 Aug 8 16:00:19 FedoraServer named[10120]: no longer listening on 127.0.0.1#53 Aug 8 16:00:19 FedoraServer named[10120]: no longer listening on 50.124.80.106#53 Aug 8 16:00:19 FedoraServer named[10120]: exiting Aug 8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name Domain (DNS). Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: Unit entered failed state. Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: Failed with result 'timeout'. Aug 8 16:00:19 FedoraServer systemd: Stopping Set-up/destroy chroot environment for named (DNS)... Aug 8 16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=named-chroot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Aug 8 16:00:20 FedoraServer systemd: Stopped Set-up/destroy chroot environment for named (DNS). Aug 8 16:00:20 FedoraServer audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=named-chroot-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'  I find the
 PID file /var/named/chroot/run/named/named.pid not readable (yet?) after start: No such file or directory  error to be a bit weird as the directory does exist and the entire directory tree from /var/named is owned by "named". This is usually SELinux's doing. But SELinux does not throw an error.
 My "named.conf":
 // generated by named-bootconf.pl options { # the following forwarders is for Open DNS forwarders { 208.67.222.222; 208.67.220.220; }; directory "/var/named"; # pid-file "/var/named/chroot/run/named/named.pid"; # pid-file "/var/named/chroot/run/named/nonamed.pid"; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; }; // // /etc/named.boot // // This is the boot file that /etc/init.d/inetsvc uses to run in.named // // // The "directory <path>" statement points to where the name server (and // its files) will be running. // example: // directory /var/named // // // // The "cache . named.ca" statement appears on all servers and tells the // server which servers are authoritative name servers for the root zone. // The addresses of the "higher authorities" are listed in the named.ca file. // zone "." { type hint; file "named.ca"; }; // // // forwarders 206.40.79.2 // forward-only // // key DHCP_UPDATER { algorithm hmac-md5; secret dgGxxxxxxxxxxxxxxxxQZwgQ==; }; zone "alpine.local" { type master; file "slaves/alpine.hosts"; allow-update { key DHCP_UPDATER; }; # allow-update { 127.0.0.1; }; }; zone "255.168.192.in-addr.arpa" { type master; file "slaves/alpine.hosts.rev"; allow-update { key DHCP_UPDATER; }; # allow-update { 127.0.0.1; }; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; logging { channel update_debug { file "slaves/named-update-debug.log"; severity debug 3; print-category yes; print-severity yes; print-time yes; }; channel security_info { file "slaves/named-auth.info"; severity info; print-category yes; print-severity yes; print-time yes; }; category update { update_debug; }; category security { security_info; }; };  This is my "named-chroot.service:
 # Don't forget to add "$AddUnixListenSocket /var/named/chroot/dev/log" # line to your /etc/rsyslog.conf file. Otherwise your logging becomes # broken when rsyslogd daemon is restarted (due update, for example). [Unit] Description=Berkeley Internet Name Domain (DNS) Wants=nss-lookup.target Requires=named-chroot-setup.service Before=nss-lookup.target After=named-chroot-setup.service After=network.target [Service] Type=forking EnvironmentFile=-/etc/sysconfig/named Environment=KRB5_KTNAME=/etc/named.keytab PIDFile=/var/named/chroot/run/named/named.pid ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi' ExecStart=/usr/sbin/named -u named -t /var/named/chroot $OPTIONS ExecReload=/bin/sh -c '/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID' ExecStop=/bin/sh -c '/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID' PrivateTmp=false [Install] WantedBy=multi-user.target  Any words of wisdom?
 Many thanks, -T
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170809/cb0eacdd/attachment.html>


More information about the bind-users mailing list