Bug 615 - NSD fails to write slave zone files
NSD fails to write slave zone files
Status: ASSIGNED
Product: NSD
Classification: Unclassified
Component: NSD Code
4.1.x
x86_64 FreeBSD
: P5 normal
Assigned To: NSD team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-10 14:57 CEST by rblayzor
Modified: 2014-10-10 15:59 CEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rblayzor 2014-10-10 14:57:54 CEST
NSD 4.1.0 on FreeBSD amd64

The following options in nsd.conf

database: ""
zonefiles-write: 3600


Zones are successfully xfr'd from master server and served out of the NSD process on the slave server, but zone files are never written to disk, even with a valid path.  No warnings or errors in the log from NSD.


Workaround: use database
Comment 1 Wouter Wijngaards 2014-10-10 15:00:43 CEST
Hi Rblayzor,

Did you configure zonefile: "example.com.zone" statements for the slave zones?  With zonefile: "" the files are not written at all.

I assume you waited 3600 seconds (an hour), and nsd did not write them.

If you pass nsd-control write , or nsd-control write example.com  is the zone then written to disk (with your zonename for example.com) ?

Best regards,
   Wouter
Comment 2 rblayzor 2014-10-10 15:08:52 CEST
Yes.  The zonefile *is* specified in the configuration.

zone:
        name: "example.org"
        zonefile: "zones/2a/example.org"
        include-pattern: "std_zone"


There is no zonefile written after the initial xfer and no zonefile after hours.

I did try "nsd-control write" and that did not work.

I did NOT try "nsd-control write example.org" implicitly for the domain, I just assumed that would not work either.
Comment 3 Wouter Wijngaards 2014-10-10 15:13:18 CEST
Hi Rblayzor,

That looks like a bug, does nsd-control write example.com zone specified work?  I guess not because it uses the same code.

For me, this works, i.e. the zone is written to zonefile when the timer expires.

So what is causing this?  Can you reproduce this (eg. use zonefiles-write: 10 seconds or so to test quickly)?

Best regards,
   Wouter
Comment 4 Wouter Wijngaards 2014-10-10 15:20:56 CEST
Hi,

It may also help to increase verbosity level (eg. -V 2 or verbosity: 2), perhaps it prints more to the log, the default verbosity 0 prints very little, 1 prints more information and 2 is fairly verbose.

Best regards, Wouter
Comment 5 rblayzor 2014-10-10 15:21:23 CEST
Specifying the domain did not work.

I'm wondering if it's just failing to write the zone files?  Will NSD create the sub-directory when saving slave zones or is that a manual process?  Regardless there is no error if it can't be written.

If it won't create subdir paths under the zone directory that may be part of the problem.
Comment 6 Wouter Wijngaards 2014-10-10 15:22:11 CEST
It should create subdir paths and report errors in syslog ...
Comment 7 rblayzor 2014-10-10 15:23:08 CEST
I will try verbosity when I get a chance and update.
Comment 8 Wouter Wijngaards 2014-10-10 15:25:13 CEST
Hi Rblayzor,

If your pattern std_zone has zonefile: "" set this will override the zonefile you set in the line above it.  That would explain why it is not writing them?

Yes, verbosity log could be useful.  Otherwise if that fails let me know and we can try to get more logs some other way.

Best regards,
   Wouter
Comment 9 Wouter Wijngaards 2014-10-10 15:27:13 CEST
And you can check this with nsd-checkconf -v [configfile] and see what the zonefile: statement for that zone is.
Comment 10 rblayzor 2014-10-10 15:42:10 CEST
I do not specify a zonefile in the pattern, and it looks ok in the checkconf.  Virtually all domains look the same:

zone:
        name: "example.org"
        zonefile: "zones/ec/example.org"
        allow-notify: 172.31.1.1 foo
        request-xfr: AXFR 172.31.1.1 foo
        notify-retry: 5


The do xfer ok and they're served from memory, i just never see zonefiles written.  I will try turning up the verbosity a bit.  I would think if it failed to create/write the zonefile that would be something in the error log/syslog.
Comment 11 Wouter Wijngaards 2014-10-10 15:56:08 CEST
Hi Rblayzor,

Yes that config looks fine.  In the code, it sets a flag after the zone transfer (is_changed = 1), then when the timer expires, it checks that flag, create path components and write the zone.  On errors it logs an error to syslog (NSD does manage to log other stuff, such as startup?, is your logging failed and thus we cannot see the failure?).  It logs for path components, write calls.

It writes to zonefilename~ and then renames it to zonefilename.

Best regards,
   Wouter
Comment 12 Wouter Wijngaards 2014-10-10 15:59:55 CEST
Is it the case that the directory that NSD runs in (chroot?) is not owned by username nsd, and it cannot create the initial directory zones?  It logs such permission denied failures, but perhaps logging fails too somehow (syslogd sometimes filters on daemon name and if you misconfig that everything is dropped).