[volunteers] www.svlug.org NSD and distro upgrade notes
rick at linuxmafia.com
Mon May 2 01:29:49 PDT 2016
Did some planning, and I'm just sharing the results.
TOPIC 1 of 2: NSD
When Daniel and I were talking the other day, he gave me a heads-up that
he heard that the package for NSD is going to break when we upgrade on
www.svlug.org. (Thank you, Daniel.)
Let me back up.
www.svlug.org, our Linode host, runs these public-facing network daemons:
Web pages (lighttpd)
Authoritative DNS for role ns1.svlug.org (NSD 3.x)
outbound SMTP to deliver root-user mail to off-system (nullmailer)
(This is a non-essential service, but a good idea.)
sshd (Portable OpenSSH)
Non-network (or not loopback-only) daemons:
NTP, as a client only (ISC NTPd)
FastCGI access (local-only) for PHP5 (php-cgi)
DHCP client (ISC dhclient), necessary as a Linode-ism
This system runs _old_ Ubuntu Server release 12.04.2 LTS, and is in
need of update.
Currently available LTS (long-term support release) is 14.04.1 LTS
(Trusty Tahr). I believe said upgrade replaces the Upstart init with
the systemd one.
NSD is an excellent authoritative-only network server (daemon).
Ubuntu Server has it in package collection 'universe', i.e., NOT as a
When we first set up the Linode system, in 2006, the package name was
'nsd' and furnished NSD 2.x.
In 2013 during a very major upgrade from 10.04.04 LTS to
12.04.2 LTS, the package manager disabled our NSD configuration as
obsolete and non-functional, essentially taking down our nameservice.
It turned out this breakage was somewhat justifiable if annoying and
badly handled, as the new NSD required a radically different conffile
format, which I was thus called upon to write from scratch. The new
package was called 'nsd3' instead of nsd.
About an hour or so of frantic research and conffile writing sufficed to
get our primary nameservice back up -- but I was profoundly unimpressed
that Ubuntu Server didn't just _leave the legacy version_ functional,
and notify the sysadmin that he/she would want to install package nsd3,
construct /etc//nsd3/nsd.conf, test the new version, stop and remove the
old version, and start the new one.
They didn't do that. Instead, they just left the 2.x daemon broken, and
let you figure out the problem.
So, Daniel's heads-up is that 14.04.1 LTS (Trusty Tahr) breaks NSD
Package to be provided will be nsd 4.0.1-1ubuntu0.1 . Apparently small
transitional package nsd3_4.0.1-1ubuntu0.1_all.deb also gets installed.
I see at https://dogfood.paddev.net/ubuntu/trusty/+source/nsd/+changelog
that the package has been renamed from nsd3 to just nsd, again.
Will need to construct /etc/nsd/nsd.conf
Manpage nsd-control, was nsd-control-setup
To check, I fetched
unpacked it using ar, tar, and xz, and poked around.
Inside the deb, /usr/share/doc/nsd/UPGRADING includes:
Upgrading from NSD 3.x to NSD 4
by Wouter C.A. Wijngaards, NLnetLabs, Jul 2012
This document lists the changes in the upgrade from NSD 3 to NSD 4 systems.
(scroll down for the NSD 2.x to NSD 3 upgrade manual).
* nsdc is gone. You can control the daemon via kill -HUP and kill -TERM,
or you can use nsd-control.
* to setup nsd-control you have to run nsd-control-setup (as root) and enable
remote-control in the nsd.conf file. It uses SSL to contact the daemon.
* the nsd.conf file from NSD3 can be used for NSD4 (defaults for new stuff).
* the difffile: setting is no longer used but ignored for
* zones listed in nsd.conf are served.
* the zonelistfile: setting sets the file where zones that are
added dynamically (and can be removed dynamically) are stored.
* the xfrdir: is used to store temporary zone transfer files.
* it is possible to define patterns in the nsd.conf file and
use the patterns to give config settings for the zones.
* patterns accept the same sort of settings which NSD3-zones did.
* you can make super-patterns with the include-pattern: setting
* the zonefile: statement creates directories when needed, if they
do not exist. In the zonefile: statement you can use %s (and
other codes) to use (part of) the name of the zone to generate
the pathname of the zonefile.
* if there is no zonefile (for slave zones) it is not used.
* nsdc rebuild and so on is gone, use nsd-control reload or kill -HUP.
* it scans if zonefiles are modified and reads those.
* you can also specify a zone by name and have nsd read that file.
* if you nsd-control reconfig it rereads the config file for zones.
* nsdc patch is not necessary
* the database is edited at runtime.
* it mmap's the nsd.db file for file I/O, this increases
virtual memory usage of NSD with the size of the file.
* if you like cronjobs, you could have one to nsd-control write
and write slave zones that have changed to their zonefile.
* other nsdc commands, reconfig (reread patterns, zones, keys),
add a zone, delete a zone, and zone transfer control, statistics.
Initially, we can do without the nsd-control facility and just use the
suggested crude kill commands, but configuring that would be the next
step after NSD 4.x is running.
I've looked at the manpage for nsd-control. It has an extensive list of
functions, not covered here. Also:
The setup requires a self-signed certificate and private keys for
both the server and client. The script nsd-control-setup generates
these in the default run directory, or with -d in another
directory. If you change the access control permissions on the
key files you can decide who can use nsd-control, by default owner
and group but not all users. The script preserves private keys
present in the directory.
So, _looks like_ you just run 'nsd-control-setup' and you get the
necessary SSL certs generated, and nsd-control then works locally.
The optional ability to control the processes from a remote host
are interesting to note, but I expect we will _not_ use that.
As for the rest, it _looks_ like one can just copy /etc/nsd3/nsd.conf to
/etc/nsd/nsd.conf and it should Just Work. If I read the above right.
As before with the NSD 2.x -> 3.x transition, I expect I'll have to
completely rewrite site-docs/nsd-instructions.
TOPIC #2 of 2: Distro upgrade
As mentioned above, we're overdue to do a major upgrade of www.svlug.org
to 14.04.1 LTS (Trusty Tahr).
Upgrades are a little dangerous generically. Prerequisites:
1. Have an utterly complete system backup.
2. Make damned sure we're not within a week or so of an SVLUG
meeting, just in case there's downtime.
3. Search out and read special Linode docs.
4. Make sure you have credentials for the Linode customer
console, and are logged into it on the Web.
To explain item #3, you can't just obliviously do a regular
upgrade of a Linode VM. For one thing, the VM's kernel is _outside_
the VM -- a Linode-built custom binary image that gets specified in the
Linode customer console. One way to fuck up a Linode VM spectacularly
is to upgrade the OS to a version the external kernel image cannot run.
Thus the need to find and read Linode-written docs. In this case,
Web-searching 'linode 14.04.1 upgrade' finds:
Notice the recommendation about making sure your VM is using the latest
It is best to follow that set of instructions carefully.
It would be an excellent idea to ensure that essential www.svlug.org
network services are reachable after upgrade. They are listed in topic
More information about the volunteers