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

Rick Moen rick at linuxmafia.com
Mon May 2 09:16:26 PDT 2016


Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> Precise Pangolin (12.04) will continue to receive updates until next
> April, but this July, it will become possible to upgrade from Trusty
> Tahr (14.04) to Xenial Xerus (16.04), so I would recommend keeping 12.04
> until that time.

Yes, this is part of what's motivating me to want to get to 14.04.1 LTS
(Trusty Tahr) before we are on an orphaned version.  We're overdue.

The NSD 2.x -> 3.x transition was sufficiently bad that I started
deferring package maintenance lest I break the system and not have the
time and energy to deal with the problem.  But of course in the end, 
you pay for that.

I would not force the upgrade to 16.04 LTS (Xenial Xerus) until the
first point release 16.04.01 LTS, at the very earliest, i.e., I would
take my cue from what heuristics are built into the do-release-upgrade
tool.

> Trusty does package systemd, but not as PID 1. Xenial has it as PID 1.

Yes, and I'm distinctly unthrilled about that.  It would be nice to move
sideway to, say, OpenRC[1], but I would need to somehow test that, which
I'd have to think about.  I hate just bobbing along taking paths of
least resistance in Canonical, Ltd.'s questionable choices in system
software, but that might be safest.

> The VM is currently running a 4.1.5 kernel. Trusty uses a 3.13 kernel,
> and Xenial uses a 4.4 kernel.

Yes, but please note that we _always_ run whatever Linode-compiled
kernel Linode recommends in its bespoke upgrade documents for Ubuntu
versions, selecting those in the Linode customer console. 

The www.svlug.org system _itself_ literally does not have a kernel
package.  Run 'dpkg -l | less', to see for yourself.

> The nsd package is 4.0.1 in Trusty, and 4.1.7 in Xenial.

OK, thanks.  _This_ I do not anticipate any problem from.


[1] OpenRC runs as an event-driven main process manager and service
supervisor, but not as PID 1. You typically run some small init of your
choosing as PID 1.  (SysVInit's init will do.)  If this were Debian, I'd
migrate to such a setup with confidence, as I've tested this already in
a VM and it works perfectly, but then, Debian isn't a distro where
servers are an afterthought.

If I really care about that problem, I suppose I could set up a replica
of www.svlug.org in a VM at home, and test-migrate it to use OpenRC, but
that seem like a whole lot of effort for one small matter.  OTOH, having
a VM-based test platform at home would not be a bad thing for other
reasons, either.




More information about the volunteers mailing list