Working on system upgrade
david.cooper at genworks.com
Tue Jun 20 03:25:35 UTC 2017
Sounds good, thank you for all this effort!
On Sun, Jun 18, 2017 at 9:38 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
> 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
> 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.
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
Dave Cooper, david.cooper at gen.works
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clo-devel