[volunteers] www.svlug.org NSD and distro upgrade notes

Rick Moen 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:

cron
syslogd, klogd
udevd
upstart-socket-bridge
getty 
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
core-maintained/supported package.

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
again.

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.


/etc/init.d/nsd3
/etc/cron.d/nsd3
Will need to construct /etc/nsd/nsd.conf
nsd user
Manpage nsd-control, was nsd-control-setup


To check, I fetched
https://dogfood.paddev.net/ubuntu/+source/nsd/4.0.1-1ubuntu0.1/+build/6716404/+files/nsd_4.0.1-1ubuntu0.1_i386.deb,
unpacked it using ar, tar, and xz, and poked around.

Inside the deb, /usr/share/doc/nsd/UPGRADING includes:

--<begin excerpt>--

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
          backwards compatibility.
        * 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.

--<end excerpt>--


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:

  SET UP
       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:
https://www.linode.com/docs/security/upgrading/how-to-upgrade-to-ubuntu-14-04-lts
Notice the recommendation about making sure your VM is using the latest
supported kernel.

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
#1.




More information about the volunteers mailing list