Release upgrades and distribution migration
You upgrade end-of-life servers to a new release or move them to another distribution, following pre-checks, backups, the upgrade itself, validation and a rollback plan.
Level 301 · 15 lessons · 12 practice labs
Lessons
Preparation
- Upgrade in place or rebuild
- Pre-checks: third-party packages, disk and configuration
- A rollback plan and a snapshot
- Short task: write an upgrade readiness report
Upgrading
- Release upgrades on Debian
- do-release-upgrade on Ubuntu
- In-place upgrades on the Red Hat family: Leapp
- Merging configuration after an upgrade
- Third-party repositories and orphaned packages after an upgrade
- Short task: upgrade a web server and keep the site working
Migration
- Distribution conversion: moving within a family
- Moving a service to a new host: data, users and settings
- Cut-over day plan: data sync, the final copy and the name switch
- Post-upgrade validation checklist
- Capstone: move three end-of-life servers onto a current release within the outage plan
Practice labs
- Determine support status and upgrade path: Find the release of Debian, Ubuntu and Rocky servers and write which is out of support and the next supported release.
- Scan for upgrade blockers: Before upgrading check third-party repositories, held packages, disk space and hand-installed software and produce a blocker list.
- Test a rollback plan with a snapshot: Take a snapshot before upgrading, make a trial change, roll back and prove the services run in the old state.
- Upgrade Debian to the next release: Point the sources at the new release, run the two-stage upgrade and verify the new version number.
- Answer config prompts correctly during an upgrade: During an Ubuntu upgrade keep the local settings of modified SSH and web server configs and merge the new options by hand.
- Upgrade a Rocky server across a major version: Clear the inhibitors in the pre-upgrade report, run the upgrade and verify services and kernel after the reboot.
- Run the post-upgrade service check: After the upgrade compare failed units, packages left from the old release and listening ports with the state before.
- Repair a service that will not start after an upgrade: Find from the journal why a service fails on a removed config option and adapt it to the new syntax.
- Finish an upgrade that stopped halfway: On a server left with packages mixed between two releases after a dropped connection, repair the package state and finish the upgrade.
- Inventory the data and settings to migrate: List the services, users, scheduled jobs and data directories on the old server as a migration checklist for the new one.
- Move a service to a server on the new release: Copy a website and database to the new server, match user IDs and show the same requests return the same responses.
- Plan and perform a short-outage cutover: Perform a cutover with final sync, making the old server read-only, switching the name record and a way back, and measure the outage.
About this course
You upgrade end-of-life servers to a new release or move them to another distribution, following pre-checks, backups, the upgrade itself, validation and a rollback plan.
What you will learn
- Preparation
- Upgrading
- Migration
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.