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