Working on system upgrade

[Erik Huelsmann]

Hi,

It's nearly time for Debian Stretch to be released. When that happens (and
GitLab releases packages for it), we want to upgrade the system quickly
afterwards.

In preparation, I'm working on trial runs for the base OS upgrade. As a
consequence, performance may be degraded. To facilitate the upgrade (make
it more quick), I reviewed all packages installed on the system with the
purpose of removing unused ones.

I've removed quite a few packages indeed (from the current production
system, that is): all packages related to the X11 (server) have been
removed. So have most LaTeX and LuaTeX packages. The idea behind this step
is that the access provided by Common-Lisp.net is merely provided to
support uploading and maintaining the static html pages -- my assumption is
that that has little relationship to being able to start a desktop
environment or graphics environment.

If you miss packages that you depend on, don't hesitate to speak up. Please
explain what you need them for and I'll make them available again.

While going over the upgrade process, I'm doing the so-many-th round of
configuration cleanup: due to the fact that the host has been managed by
multiple people at various times in the past, each with their own
approaches to managing the configuration, the configuration can be much
more standardized. On each round of maintenance, that's exactly what I've
been doing. Configuration is more-and-more getting in line with "how Debian
intends it". Let me use this e-mail as an opportunity to ask current and
future (co)maintainers to stick to it; it's often a learning curve, but
saves a lot of effort on upgrades later on.

There will be a pre-notification and some (planned) downtime for the system
when the final cut-over arrives.


For those interested in how the migration strategy and dress rehearsals
work, I'm going over these steps (wash, rinse, repeat -- in other words:
over and over until it works):

1. Create LVM writeable snapshots of the VM's volumes
2. Create a new VM on top of these snapshots
3. Start up the new VM with different IP and hostname settings (patched
Apache config too)
4. Change the (git-versioned) /etc directory to the new target distribution
version branch
5. Run dist-upgrade (and a number of additional steps)
6. Fix the configuration issues found in the resulting installation and
commit (to another server)
7. Ditch the copy-VM and go back to (1)

This procedure, although it's taking quite a bit of time to run the
dist-upgrade, is turning out pretty effective in producing a reproducible
upgrade procedure which can be repeated consistently once the production
server needs to be upgraded.

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20170618/71898769/attachment.html>