bind-chroot, runs, works, dies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bind-chroot, runs, works, dies

Todd Chester

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_64

I 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


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Reindl Harald


Am 10.08.2017 um 00:14 schrieb toddandmargo:

> I 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. |
>
>
> |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

while this is Fedora 25 - get rid of the crappy PID file dance for every
systemd-unit, i ripped them out many years ago and since named is even a
single process service "Type=simple" is enough while it even works for
httpd-preforker

frankly i go so far and specify /dev/null for mariadb and guess what -
all the random startup errors are gone for a long time

[root@srv-rhsoft:~]$ cat /etc/systemd/system/named.service
[Unit]
Description=DNS Server
After=network.service systemd-networkd.service network-online.target
network-wan-bridge.service network-wlan-bridge.service openvpn.service

[Service]
Type=simple
ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z
/etc/named.conf
ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off
TimeoutSec=25
Restart=always
RestartSec=1

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN
CAP_DAC_OVERRIDE CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
delete_module fanotify_init finit_module get_mempolicy init_module
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
kexec_load keyctl lookup_dcookie migrate_pages move_pages
open_by_handle_at perf_event_open process_vm_readv process_vm_writev
ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
vmsplice

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib

InaccessibleDirectories=-/root
InaccessibleDirectories=-/media
InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/run/console
InaccessibleDirectories=-/run/dbus
InaccessibleDirectories=-/run/lock
InaccessibleDirectories=-/run/mount
InaccessibleDirectories=-/run/systemd/generator
InaccessibleDirectories=-/run/systemd/system
InaccessibleDirectories=-/run/systemd/users
InaccessibleDirectories=-/run/udev
InaccessibleDirectories=-/run/user
InaccessibleDirectories=-/var/lib/dbus
InaccessibleDirectories=-/var/lib/rpm
InaccessibleDirectories=-/var/lib/systemd
InaccessibleDirectories=-/var/spool

[Install]
WantedBy=multi-user.target
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

/dev/rob0
In reply to this post by Todd Chester
On Wed, Aug 09, 2017 at 03:14:00PM -0700, toddandmargo wrote:

> 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.

Your mail client has a problem with line wrapping, which made this
very difficult to read.

> # 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

Yes, named seems to start and to be running fine.

> 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.

Your systemd, for some reason probably related to what it said, has
killed named.

> 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

And named obediently did a clean shutdown.

Your issue might more effectively be dealt with in a Fedora forum, or
as a Fedora bug.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: bind-chroot, runs, works, dies

Darcy Kevin (FCA)
In reply to this post by Todd Chester

I’m not very familiar with Fedora, but on Redhat, at least, there is no /run directory. Which makes me think that “/var/named/chroot/run/named/named.pid” is a misconfiguration. That would be seen as “/run/named/named.pid” from *within* the chroot. Following usual conventions, I think you probably meant to specify “/var/run/named/named.pid” in named.conf, didn’t you? The full, pre-chroot’ed path would then presumably be /var/named/chroot/var/run/named/named.pid.

 

-    Kevin

 

 

From: bind-users [mailto:[hidden email]] On Behalf Of toddandmargo
Sent: Wednesday, August 09, 2017 6:14 PM
To: [hidden email]
Subject: bind-chroot, runs, works, dies

 


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_64

I 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


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Reindl Harald


Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
> I’m not very familiar with Fedora, but on Redhat, at least, there is no
> /run directory

don't get me wrong but you are missing some years - /run is a important
part of the system for a long time because it is a) tmpfs and b)
available at early boot while /var maybe a later mounted filesystem

https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesystem

[root@hosting:~]$ stat /run
   File: '/run'
   Size: 560             Blocks: 0          IO Block: 4096   directory
Device: 11h/17d Inode: 9222        Links: 22
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-07-19 10:51:46.500000000 +0200
Modify: 2017-08-09 03:44:16.083351213 +0200
Change: 2017-08-09 03:44:16.083351213 +0200
  Birth: -
[root@hosting:~]$ rpm -q --file /run
filesystem-3.2-21.el7.x86_64

[root@hosting:~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Todd Chester
In reply to this post by Reindl Harald
that did the trick.  Thank you!!!!!!!!

---- On Wed, 09 Aug 2017 15:19:02 -0700 Reindl Harald<[hidden email]> wrote ----


[Service]
Type=simple


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: bind-chroot, runs, works, dies

Darcy Kevin (FCA)
In reply to this post by Reindl Harald
Your point is taken, I looked at a very old Redhat system, although I'll note that the pathnames under a chroot are not subject to the technical limitations you mentioned.

                                                                        - Kevin


-----Original Message-----
From: bind-users [mailto:[hidden email]] On Behalf Of Reindl Harald
Sent: Wednesday, August 09, 2017 6:48 PM
To: [hidden email]
Subject: Re: bind-chroot, runs, works, dies



Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
> I’m not very familiar with Fedora, but on Redhat, at least, there is
> no /run directory

don't get me wrong but you are missing some years - /run is a important part of the system for a long time because it is a) tmpfs and b) available at early boot while /var maybe a later mounted filesystem

https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesystem

[root@hosting:~]$ stat /run
   File: '/run'
   Size: 560             Blocks: 0          IO Block: 4096   directory
Device: 11h/17d Inode: 9222        Links: 22
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-07-19 10:51:46.500000000 +0200
Modify: 2017-08-09 03:44:16.083351213 +0200
Change: 2017-08-09 03:44:16.083351213 +0200
  Birth: -
[root@hosting:~]$ rpm -q --file /run
filesystem-3.2-21.el7.x86_64

[root@hosting:~]$ cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) _______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Todd Chester
In reply to this post by /dev/rob0


On 08/09/2017 03:28 PM, /dev/rob0 wrote:
> Your mail client has a problem with line wrapping, which made this
> very difficult to read.

Ya, no fooling.  That would be Zoho's web mail.  I had to
post from the field.

I am back in station on Thunderbird now.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Todd Chester
In reply to this post by /dev/rob0


On 08/09/2017 03:28 PM, /dev/rob0 wrote:
> Your issue might more effectively be dealt with in a Fedora forum, or
> as a Fedora bug.

Tried that to no avail: both Ask Fedora and Fedora Forum

But Reindl knew what to do and it fix the thing.  It now
runs so smooth it is like poetry.


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Petr Mensik
In reply to this post by Todd Chester
Hi Todd.

I think much better than Ask Fedora would be filling a bug in bugzilla.redhat.com. I would see it straight away.
I am Fedora bind maintainer. If there is bug preventing correct start of named-chroot, I would like to fix it.

You would see SElinux errors in command "ausearch -i -ts recent -m avc -m user_avc -m selinux_err" if that errors were SElinux related.

I think your config file is missing pid-file "/run/named/named.pid"; It has to match pid file used by your named-chroot.service. If systemd does not find the pid file of forking service, it will cancel the service.
PIDFile in named-chroot service includes chroot path, but configuration file has to point to path inside chroot only.
It should work with default configuration even when pid-file directive is commented out. There is symlink from /var/run to /run also in /var/named/chroot.

Can you check rights and selinux context of chroot run directories?

These are on my Fedora 26.

$ ls -ldZ /var/named/chroot/{,var/}run{,/named}
drwxr-x---. 3 root  named system_u:object_r:named_conf_t:s0    4096 Aug 11 13:01 /var/named/chroot/run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 18:45 /var/named/chroot/run/named
lrwxrwxrwx. 1 named named system_u:object_r:named_conf_t:s0       6 Jun 30 18:45 /var/named/chroot/var/run -> ../run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 18:45 /var/named/chroot/var/run/named

Is it possible you do not have the /var/run symlink there? It would not find pid file and cancel the service then.
Did you upgrade to Fedora 26 from previous version?

I would be grateful If you could fill a bug. You may not be the only one affected and I would like to fix it for everyone.

I would test whether Type=service proposed by Reindl can be used in new Fedora release. I like it.

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [hidden email]  PGP: 65C6C973

----- Original Message -----
From: "toddandmargo" <[hidden email]>
To: [hidden email]
Sent: Thursday, August 10, 2017 12:14:00 AM
Subject: bind-chroot, runs, works, dies


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_64


I 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

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Reindl Harald


Am 11.08.2017 um 15:57 schrieb Petr Mensik:

> Hi Todd.
>
> I think much better than Ask Fedora would be filling a bug in bugzilla.redhat.com. I would see it straight away.
> I am Fedora bind maintainer. If there is bug preventing correct start of named-chroot, I would like to fix it.
>
> You would see SElinux errors in command "ausearch -i -ts recent -m avc -m user_avc -m selinux_err" if that errors were SElinux related.
>
> I think your config file is missing pid-file "/run/named/named.pid"; It has to match pid file used by your named-chroot.service. If systemd does not find the pid file of forking service, it will cancel the service.
> PIDFile in named-chroot service includes chroot path, but configuration file has to point to path inside chroot only.
> It should work with default configuration even when pid-file directive is commented out. There is symlink from /var/run to /run also in /var/named/chroot

and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade
and removed all that pid-file-stuff excatly becuse it causes only
troubles long before most package maintainers provided systemd-units
while as we deloyed F15 we overrided every single service with a unit in
/etc/systemd/system

after 6 years running systemd nobody was able to show me a single
service which needs a pid-file these days because the whole concept is
broken by design when we have a system manager which can track services
and processes proper

the pid-file stuff in systemd is last ressort for heavily broken software
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bind-chroot, runs, works, dies

Petr Mensik
Hi Reindl,

I have tested it and it has undesired side-effects. It would be great if pid files did not have to match systemd unit files. But presence of pid files also work as notification of completed initialization (which is done BEFORE forking and finishing ExecStart command).

Service type=simple is not good replacement of forking, because it does not let you know when service failed to start at all. If you already have something listening on your port and start named with
$ systemctl start named

It prints nothing, error code 0 - success. But you have to look at
$ systemctl status named

to see there is actually failure. I would not expect that. It works better now.

Forking does allow you to first read basic configuration, initialize first. When that is successfully done, continue with daemonizing. Systemd will wait until it finds pid file created by daemonizing. Any initialization errors, even those that named-checkconf cannot find, are reported and you are told it did NOT start. Before "systemd start named" returns. I consider it important feature, worth still playing with pid files.

I think type=notify would be good replacement. It would requires support implemented in bind however, so it can tell you when it finished initialization and started handling requests. I think nothing such is implemented yet. At least I do not know about option for that.

While I agree pid files are strange relicts of old days, the way systemd handles them has some advantages over simple services. Unless bind supports sd_notify of systemd, I think default configuration has to stay playing with pid files. Of course if you want automatically restarted service, simple service may suit you. Not for default configuration however.

Regards,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [hidden email]  PGP: 65C6C973


----- Original Message -----
From: "Reindl Harald" <[hidden email]>
To: [hidden email]
Sent: Friday, August 11, 2017 4:04:12 PM
Subject: Re: bind-chroot, runs, works, dies



Am 11.08.2017 um 15:57 schrieb Petr Mensik:

> Hi Todd.
>
> I think much better than Ask Fedora would be filling a bug in bugzilla.redhat.com. I would see it straight away.
> I am Fedora bind maintainer. If there is bug preventing correct start of named-chroot, I would like to fix it.
>
> You would see SElinux errors in command "ausearch -i -ts recent -m avc -m user_avc -m selinux_err" if that errors were SElinux related.
>
> I think your config file is missing pid-file "/run/named/named.pid"; It has to match pid file used by your named-chroot.service. If systemd does not find the pid file of forking service, it will cancel the service.
> PIDFile in named-chroot service includes chroot path, but configuration file has to point to path inside chroot only.
> It should work with default configuration even when pid-file directive is commented out. There is symlink from /var/run to /run also in /var/named/chroot

and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade
and removed all that pid-file-stuff excatly becuse it causes only
troubles long before most package maintainers provided systemd-units
while as we deloyed F15 we overrided every single service with a unit in
/etc/systemd/system

after 6 years running systemd nobody was able to show me a single
service which needs a pid-file these days because the whole concept is
broken by design when we have a system manager which can track services
and processes proper

the pid-file stuff in systemd is last ressort for heavily broken software
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Loading...