hi,
while all files is owned by nsd user and nsd run as nsd the nsd.db is
still owned by root user (because the compiler run as root and create
this file as root, ok i know just it'd be better if this file is owned
by nsd too).
another strange thing is that on the slave nsd i've got such messages:
hi,
while all files is owned by nsd user and nsd run as nsd the nsd.db is
still owned by root user (because the compiler run as root and create
this file as root, ok i know just it'd be better if this file is owned
by nsd too).
As long as the nsd user is allowed to read the nsd.db it is fine.
another strange thing is that on the slave nsd i've got such messages:
-----------------------------------------
zonec: reading zone "lfarkas.org".
warning: slave zone lfarkas.org with no zonefile 'lfarkas.org'(No such
file or directory) will force zone transfer.
This is because your zonefile does not exist. And because it is a slave
zone, NSD will start without content, and do a zone transfer
immediately. The warning is to help operators that have errors in the
names of zone files see why a zone transfer is happening.
zonec: processed 0 RRs in "lfarkas.org".
-----------------------------------------
but the slave file is never written. so i assume the zone date is
written into nsd.db, but from nsd.conf zonefile: "This attribute must be
present in each zone." but then why? and anyway why not written the zone
zone transfer data is stored in ixfr.db. When you run nsdc patch
(nsd-patch) to get rid of the ever-growing ixfr.db (in a cron job for
example - see the README), nsd-patch will create the zonefile.
files after the zone transfer. wouldn't be easier to read from this file
next time rather than do a fill transfer all the time?
It will read the zone transfer from disk next time. So it will force one
zone transfer, then store it on disk. Initially it is stored in ixfr.db.
But ixfr.db grows only. To compact your disk space you run nsdc patch.
This writes the information into the zone files, and rebuilds the
database with that information, cleaning out ixfr.db in the process.
hi,
while all files is owned by nsd user and nsd run as nsd the nsd.db is
still owned by root user (because the compiler run as root and create
this file as root, ok i know just it'd be better if this file is owned
by nsd too).
As long as the nsd user is allowed to read the nsd.db it is fine.
yes, but regenerate it as root:-(
It will read the zone transfer from disk next time. So it will force one
zone transfer, then store it on disk. Initially it is stored in ixfr.db.
But ixfr.db grows only. To compact your disk space you run nsdc patch.
This writes the information into the zone files, and rebuilds the
database with that information, cleaning out ixfr.db in the process.
Does this answer your questions?
yes thanks, besides that all generated files are owned by root and put
into the current working dir even if nsd.conf assume relative to the
conf file ie. next time nsd have to retransfer all files, what's more
nsd assume it already do the patch (nsdc: no patch necessary.) ie. no
data in ixfr.db even if wrote into wrong dir:-(
It will read the zone transfer from disk next time. So it will force one
zone transfer, then store it on disk. Initially it is stored in ixfr.db.
But ixfr.db grows only. To compact your disk space you run nsdc patch.
This writes the information into the zone files, and rebuilds the
database with that information, cleaning out ixfr.db in the process.
Does this answer your questions?
yes thanks, besides that all generated files are owned by root and put
into the current working dir even if nsd.conf assume relative to the
conf file ie. next time nsd have to retransfer all files, what's more
nsd assume it already do the patch (nsdc: no patch necessary.) ie. no
data in ixfr.db even if wrote into wrong dir:-(
Sounds like you need the zonesdir: "/path/to/zonefile/directory" feature
in the config file, is sets the working directory, so it can find files
for which you specified relative paths.
It will read the zone transfer from disk next time. So it will force one
zone transfer, then store it on disk. Initially it is stored in ixfr.db.
But ixfr.db grows only. To compact your disk space you run nsdc patch.
This writes the information into the zone files, and rebuilds the
database with that information, cleaning out ixfr.db in the process.
Does this answer your questions?
yes thanks, besides that all generated files are owned by root and put
into the current working dir even if nsd.conf assume relative to the
conf file ie. next time nsd have to retransfer all files, what's more
nsd assume it already do the patch (nsdc: no patch necessary.) ie. no
data in ixfr.db even if wrote into wrong dir:-(
Sounds like you need the zonesdir: "/path/to/zonefile/directory" feature
in the config file, is sets the working directory, so it can find files
for which you specified relative paths.
is not the commented values are the default ones? ie if
# zonesdir: /etc/nsd
than files are relative to it?
but if i run nsdc patch in /root than nsdc put the files into /root.
It will read the zone transfer from disk next time. So it will force one
zone transfer, then store it on disk. Initially it is stored in ixfr.db.
But ixfr.db grows only. To compact your disk space you run nsdc patch.
This writes the information into the zone files, and rebuilds the
database with that information, cleaning out ixfr.db in the process.
Does this answer your questions?
yes thanks, besides that all generated files are owned by root and put
into the current working dir even if nsd.conf assume relative to the
conf file ie. next time nsd have to retransfer all files, what's more
nsd assume it already do the patch (nsdc: no patch necessary.) ie. no
data in ixfr.db even if wrote into wrong dir:-(
Sounds like you need the zonesdir: "/path/to/zonefile/directory" feature
in the config file, is sets the working directory, so it can find files
for which you specified relative paths.
is not the commented values are the default ones? ie if
# zonesdir: /etc/nsd
than files are relative to it?
but if i run nsdc patch in /root than nsdc put the files into /root.
Ah. You have a point there. That is not a default at all, only a
suggested value. Hmm this should be fixed so it is obvious that is not
the default value.