Mailinglist Archive: opensuse (389 mails)

< Previous Next >
Re: [opensuse] Why are nsupdate changes not persistent?
15.03.2019 23:23, Marc Chamberlin пишет:
Hi Per,  Thanks for following up and taking a look at this issue. ;-)  I
set up a test host in one of my zones and used nsupdate to insert a txt
record for that host.  Monitoring what is happening in the chroot
directories where named does it's work.

First I set up a small test file to use

# cat test.example.txt
debug yes
update add 86400 TXT "foobar"

Then using nsupdate I add the TXT record "foobar" for -

nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key -v

dig does show that indeed the TXT record was added and I see that the
jnl file - has been created. However neither of the
config files for in /etc/named.d/local/master/ or
/var/lib/named/etc/named.d/local/master/ has been updated
yet, as expected...

quasar:/var/lib/named/etc/named.d/local/master # dig +short -t txt "bar"
Now for a small segway, if I manually sync the jnl file, i.e. rndc sync 
I do see that the TXT record is copied into the chrooted version of as can be seen with this copy/past section from -

test                    A
$TTL 86400      ; 1 day
                        TXT     "bar"
$TTL 172800     ; 2 days
However, it still is not persisted into
/etc/named.d/local/master/  The jnl file is still in the
chrooted directory...

So far so good...  Next I stop the named service -

quasar: /etc/named # systemctl stop named.service

And the contents of the chrooted directory is still intact, both the
record remains defined and the jnl file exists. But the file at
/etc/named.d/local/master/ remains unchanged and not updated.

When I start up the named service, the entire chrooted directory at
/var/lib/named/etc/named.d/local/master is destroyed and then recreated.
I was able to determine that this is done by copying the contents of
/etc/named.d/local/master into the new chroot directory. Thus the TXT
record inserted by nsupdate is lost and the jnl file is destroyed.
Therefore I must conclude that either the scripts that stop the named
service or the ones that start the named service do not copy the files
out of the chrooted directories back into the files at /etc/named.d
before the chrooted directory is destroyed. I don't know which step
should have this responsibility, but my guess is that the copy back
should occur when the named service is stopped. Anywise, this is where a
systemd guru is needed, as this is getting above my pay grade...

It has absolutely nothing to do with systemd. systemd service just calls
script which is basically the same as in case of sysvinit. It is this
script that re-creates chroot environment and any copyback should happen
in this script also. This script is not part of upstream distribution.

Open bug report in openSUSE bugzilla.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >