Re: Working on system upgrade

Dave Cooper <[email protected]>
Newsgroups gmane.lisp.common-lisp-net.devel
Message-ID <CAHBe5Xi0tNFy0m9vDRJJM66yfVoPYqpBZwVQJ014WA3LWtAk0g@mail.gmail.com>
Sounds good, thank you for all this effort!


On Sun, Jun 18, 2017 at 9:38 AM, Erik Huelsmann <[email protected]> wrote:

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



-- 
My Best,

Dave Cooper, [email protected]
genworks.com, gendl.org
+1 248-330-2979
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.