FAQ
I updated my secondary DNS server from 5.3 to 5.4 today. After the
update, named would not start. A bit of investigation found that all of
the files in /var/named/chroot/var/named/data had been turned into links
to themselves!

Fortunately, since this is a secondary DNS, all I had to do was delete
the files, replace the root hints file and let everything else copy back
over from the master. If this had been the master, I would have had to
restore from backups.

Has anyone else seen this problem?

--
Bowie

Search Discussions

  • Kai Schaetzl at Jan 19, 2010 at 10:31 pm

    Bowie Bailey wrote on Tue, 19 Jan 2010 15:51:40 -0500:

    Has anyone else seen this problem?
    No. I usually see some change in the permissions
    (/var/named/chroot/var/named/ loses group write and named logs some
    complaints but still works) when updating named. I think I've seen this
    happen several times and with the last update as well. I've not taken this
    serious as it didn't stop named from working. I assume the write
    permissions are only necessary for client DNS updates which I do not use.
    I remember there was a more serious problem a year or so ago, when an
    update stopped named from working because it overwrote some files.
    So, the upgrading experience has been less smooth with named than with
    other packages, but I haven't seen what you experienced.

    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Kai Schaetzl at Jan 21, 2010 at 12:00 pm

    Kai Schaetzl wrote on Tue, 19 Jan 2010 23:31:33 +0100:

    No. I usually see some change in the permissions
    (/var/named/chroot/var/named/ loses group write and named logs some
    complaints but still works) when updating named.
    And sure enought that happened with latest bind update today again.

    /var/named/chroot/var l
    drwxrwx--- 2 named named 4096 Jan 20 17:33 log
    drwxr-x--- 4 root named 4096 Jan 20 17:33 named
    drwxr-x--- 4 root named 4096 Mar 14 2003 run
    drwxrwx--- 2 named named 4096 Mar 14 2003 tmp

    I usually set g+w for the named directory. I wonder now if the owner of
    that directory should actually be named? Thanks.

    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Kai Schaetzl at Jan 21, 2010 at 1:20 pm

    Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:

    I wonder now if the owner of
    that directory should actually be named?
    Hm, after looking on other machines that have named installed but not in
    use it's excactly the same there. So, if named wants write permission
    there, but the rpm always removes that permission - isn't the rpm wrong
    then? Should I report this as a bug?

    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Bowie Bailey at Jan 21, 2010 at 2:34 pm

    Kai Schaetzl wrote:
    Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:

    I wonder now if the owner of
    that directory should actually be named?
    Hm, after looking on other machines that have named installed but not in
    use it's excactly the same there. So, if named wants write permission
    there, but the rpm always removes that permission - isn't the rpm wrong
    then? Should I report this as a bug?
    On my system, named does not have write permission to the named
    directory, but it does have permission to named/data.

    # ll /var/named/chroot/var/
    total 24
    drwxr-x--- 4 root named 4096 Aug 25 2004 named
    drwxrwx--- 3 root named 4096 Mar 13 2003 run
    drwxrwx--- 2 named named 4096 Mar 13 2003 tmp

    # ll /var/named/chroot/var/named/
    total 16
    drwxrwx--- 5 named named 4096 Sep 25 14:25 data
    drwxrwx--- 2 named named 4096 Jul 27 2004 slaves

    Everything is working fine for me with these settings, so I don't think
    this is a problem.

    --
    Bowie
  • Kai Schaetzl at Jan 21, 2010 at 4:31 pm

    Bowie Bailey wrote on Thu, 21 Jan 2010 09:34:02 -0500:

    # ll /var/named/chroot/var/
    total 24
    drwxr-x--- 4 root named 4096 Aug 25 2004 named
    drwxrwx--- 3 root named 4096 Mar 13 2003 run
    that has no group write permission here.
    drwxrwx--- 2 named named 4096 Mar 13 2003 tmp

    # ll /var/named/chroot/var/named/
    total 16
    drwxrwx--- 5 named named 4096 Sep 25 14:25 data
    drwxrwx--- 2 named named 4096 Jul 27 2004 slaves
    Same here.
    Everything is working fine for me with these settings, so I don't think
    this is a problem.
    It seems to be working, but I get this complaint (I see it as a complaint)
    each time named gets restarted - until I give it write permission for that
    directory.
    2) The directory that does contain the zone files appears to be owned by
    named with write permissions by default.
    This would be data then. Yes, same here. And the files in it are
    owner/group named and rw for both.
    3) All of my master zone files are owned by root with 644 permissions,
    so regardless of the directory permissions, named can't mess with them.
    I have them even 640. owner root, group named.


    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Lhecking at Jan 21, 2010 at 4:48 pm

    It seems to be working, but I get this complaint (I see it as a complaint)
    each time named gets restarted - until I give it write permission for that
    directory.
    This is RedHat's policy for bind. The working directory does not need to
    be writable, and RH's bind maintainer Adam Tkac has explained this on numerous
    occasions.
  • Kai Schaetzl at Jan 21, 2010 at 7:31 pm

    Lhecking at users.sourceforge.net wrote on Thu, 21 Jan 2010 16:48:10 +0000:

    This is RedHat's policy for bind. The working directory does not need to
    be writable, and RH's bind maintainer Adam Tkac has explained this on numerous
    occasions.
    Thanks for the hint. I cannot see that he explained that "on numerous occasions",
    but I can see some bug reports about this, for instance http://www.mail-
    archive.com/fedora-package-announce at redhat.com/msg26692.html
    As long as they keep doing this and *not* change the reporting at the same time
    they will get questions about it.

    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Brian Mathis at Jan 21, 2010 at 2:38 pm

    On Thu, Jan 21, 2010 at 8:20 AM, Kai Schaetzl wrote:
    Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:
    I wonder now if the owner of
    that directory should actually be named?
    Hm, after looking on other machines that have named installed but not in
    use it's excactly the same there. So, if named wants write permission
    there, but the rpm always removes that permission - isn't the rpm wrong
    then? Should I report this as a bug?

    Kai
    I don't think you'd want a compromised named to be able to make
    changes to your authoritative DNS records, which is what could happen
    if you have permissions set that way.
  • Bowie Bailey at Jan 21, 2010 at 2:45 pm

    Brian Mathis wrote:
    On Thu, Jan 21, 2010 at 8:20 AM, Kai Schaetzl wrote:

    Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:

    I wonder now if the owner of
    that directory should actually be named?
    Hm, after looking on other machines that have named installed but not in
    use it's excactly the same there. So, if named wants write permission
    there, but the rpm always removes that permission - isn't the rpm wrong
    then? Should I report this as a bug?

    Kai
    I don't think you'd want a compromised named to be able to make
    changes to your authoritative DNS records, which is what could happen
    if you have permissions set that way.
    1) The directory he was referring to does not contain the zone files.
    2) The directory that does contain the zone files appears to be owned by
    named with write permissions by default.
    3) All of my master zone files are owned by root with 644 permissions,
    so regardless of the directory permissions, named can't mess with them.
    4) The secondary server's zone files have to be writable by named so
    they can update from the master.

    I don't see a problem here.

    --
    Bowie
  • Kai Schaetzl at Jan 21, 2010 at 4:31 pm

    Brian Mathis wrote on Thu, 21 Jan 2010 09:38:12 -0500:

    I don't think you'd want a compromised named to be able to make
    changes to your authoritative DNS records, which is what could happen
    if you have permissions set that way.
    But why does named then report it right after the update?

    Jan 21 12:46:40 chacha named[16607]: the working directory is not writable


    Kai

    --
    Get your web at Conactive Internet Services: http://www.conactive.com
  • Veiko Kukk at Jan 22, 2010 at 9:03 am

    Kai Schaetzl wrote:
    Brian Mathis wrote on Thu, 21 Jan 2010 09:38:12 -0500:
    I don't think you'd want a compromised named to be able to make
    changes to your authoritative DNS records, which is what could happen
    if you have permissions set that way.
    But why does named then report it right after the update?

    Jan 21 12:46:40 chacha named[16607]: the working directory is not writable
    I experienced same message when upgrading bind on freebsd recently.
    After googling, I settled down, seems that its exactly as it must be.
    Only that message shold be more precise and add at the end something
    like "... good!".

    --
    Veiko
  • Brian Mathis at Jan 19, 2010 at 11:26 pm

    On Tue, Jan 19, 2010 at 3:51 PM, Bowie Bailey wrote:
    I updated my secondary DNS server from 5.3 to 5.4 today. ?After the
    update, named would not start. ?A bit of investigation found that all of
    the files in /var/named/chroot/var/named/data had been turned into links
    to themselves!

    Fortunately, since this is a secondary DNS, all I had to do was delete
    the files, replace the root hints file and let everything else copy back
    over from the master. ?If this had been the master, I would have had to
    restore from backups.

    Has anyone else seen this problem?

    --
    Bowie

    Do you have the caching-nameserver package installed? I've heard this
    can cause problems with files getting overwritten.
  • Les Mikesell at Jan 19, 2010 at 11:47 pm

    On 1/19/2010 5:26 PM, Brian Mathis wrote:
    On Tue, Jan 19, 2010 at 3:51 PM, Bowie Baileywrote:
    I updated my secondary DNS server from 5.3 to 5.4 today. After the
    update, named would not start. A bit of investigation found that all of
    the files in /var/named/chroot/var/named/data had been turned into links
    to themselves!

    Fortunately, since this is a secondary DNS, all I had to do was delete
    the files, replace the root hints file and let everything else copy back
    over from the master. If this had been the master, I would have had to
    restore from backups.

    Has anyone else seen this problem?

    --
    Bowie

    Do you have the caching-nameserver package installed? I've heard this
    can cause problems with files getting overwritten.
    If you install the caching-nameserver package it assumes you don't have
    any other configuration (that's that point of it being a
    caching-nameserver).

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Bowie Bailey at Jan 20, 2010 at 2:01 pm

    Les Mikesell wrote:
    On 1/19/2010 5:26 PM, Brian Mathis wrote:

    On Tue, Jan 19, 2010 at 3:51 PM, Bowie Baileywrote:
    I updated my secondary DNS server from 5.3 to 5.4 today. After the
    update, named would not start. A bit of investigation found that all of
    the files in /var/named/chroot/var/named/data had been turned into links
    to themselves!

    Fortunately, since this is a secondary DNS, all I had to do was delete
    the files, replace the root hints file and let everything else copy back
    over from the master. If this had been the master, I would have had to
    restore from backups.

    Has anyone else seen this problem?

    --
    Bowie
    Do you have the caching-nameserver package installed? I've heard this
    can cause problems with files getting overwritten.
    If you install the caching-nameserver package it assumes you don't have
    any other configuration (that's that point of it being a
    caching-nameserver).
    Nope, no caching-nameserver here. All I have is:

    bind-libs-9.3.6-4.P1.el5_4.1
    bind-utils-9.3.6-4.P1.el5_4.1
    bind-chroot-9.3.6-4.P1.el5_4.1
    bind-9.3.6-4.P1.el5_4.1

    --
    Bowie

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJan 19, '10 at 8:51p
activeJan 22, '10 at 9:03a
posts15
users6
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase