Centos 7 To Almalinux

Centos 7 To Almalinux

Reading time1 min
#Linux#Migration#OpenSource#CentOS#AlmaLinux#SysAdmin

Seamless Migration: A Step-by-Step Guide to Upgrading from CentOS 7 to AlmaLinux

CentOS 7’s EOL (June 2024) marks the end of official support, patches, and security maintenance for a massive install base. Running legacy workloads on unmaintained OS versions introduces clear operational risks—regulatory, security, and even kernel-level stability. AlmaLinux, a downstream, RHEL-compatible project, is a natural migration target for infrastructure teams unwilling to pay RHEL licensing or gamble with unsupported distributions.

However, there’s a critical snag: there is no safe, supported in-place upgrade path from CentOS 7 (built on RHEL 7) to AlmaLinux 8 (built on RHEL 8). This is not a branding swap; RHEL/AlmaLinux 8 uses an updated kernel, different RPM versions, DNF vs. YUM, and major core package revisions. Any so-called “one-click conversion” is, at best, experimental for this jump.

Is an In-Place Upgrade Possible?

No. In-place upgrades from CentOS 7 → AlmaLinux 8 are not considered production-safe or recommended for enterprise workloads. The AlmaLinux migration tool (almalinux-deploy) targets CentOS 8.x, not 7.x.

Bottom line: A clean AlmaLinux 8 install is the only way to ensure a stable and supportable platform post-migration from CentOS 7.


High-Level Migration Checklist

StepRequired Tools or ExamplesSide Notes
Audit & backup CentOS 7 systemstar, mysqldump, snapshotsValidate backup integrity
Inventory OS and package staterpm -qa, custom scriptsRetain for troubleshooting/mapping later
Identify and disable 3rd-party reposyum-config-managerEPEL/remi often cause conflicts
Build new AlmaLinux 8 hosts (VM or HW)installer ISO, PXE, cloud-initSize and network identical to old server
Migrate configuration/datarsync, config managementPreserve perms, test subprocesses
Application-specific validation/testingCustom scripts, smoke testsCheck systemd, service paths, dependencies
Traffic cutover/rollback planDNS/IP updates, backupsMaintenance window scheduling critical

1. Backup: No Shortcuts Here

Before touching anything, generate full system and application-level backups. For production systems:

tar czvf /backup/etc-centos7-2024-06-13.tar.gz /etc
tar czvf /backup/var-centos7-2024-06-13.tar.gz /var
mysqldump --all-databases --single-transaction -u root -p > /backup/db_all_2024-06-13.sql

Validate restores from these archives before migrating. If using LVM, snap the volume for rapid rollback.


2. Audit Inventory: Know What You’re Migrating

Generate an inventory of installed packages and running services:

rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" > /backup/rpm-list-centos7.txt
systemctl list-units --type=service --state=running > /backup/running-services.txt

This output is indispensable for post-migration troubleshooting (“Why isn’t this binary on AlmaLinux?”).


3. Neutralize 3rd-Party Repositories

Disable non-core repos to avoid mismatched RPM downgrades or conflicts:

yum-config-manager --disable epel*
yum-config-manager --disable remi*

Note: Many CentOS 7 servers accumulate legacy repos over years. Miss one, and migration pain follows.


4. Prepare the AlmaLinux 8 Environment

Spin up new compute instances (physical, VM, or cloud) with AlmaLinux 8.9 (latest as of June 2024). Match architecture, CPU/memory layouts, and attached storage.

  • For virtualized hosts, consider snapshotting the blank OS before migration in case you need to revert.
  • If using configuration management (Ansible, Salt), generate fresh host inventories now.

5. Data & Application Migration

Use rsync for files—preserve permissions, ownership, and timestamps. Database migration will depend on your service (for MySQL/MariaDB, dump and import; for Postgres, use pg_dump and pg_restore targeting new versions).

Example: migrating Apache HTTPD configuration and web root

rsync -avz --numeric-ids /etc/httpd/ user@al8-new:/etc/httpd/
rsync -avz --numeric-ids /var/www/html/ user@al8-new:/var/www/html/

Install the corresponding package on AlmaLinux:

dnf install httpd -y
systemctl enable --now httpd

Gotcha: httpd on AlmaLinux 8.x may introduce stricter default SELinux policies or slightly different configuration directives. Always run systemctl status httpd and check /var/log/httpd/error_log after starting the service.


6. Service Validation

Before cutover, validate services function as expected:

  • Test systemd unit states; run ss -tuln to verify listening ports.
  • For web servers, confirm TLS certs and HTTP/2 support (if enabled previously).
  • If using SSSD, LDAP, or Kerberos, validate end-to-end authentication.

Example failure log:

Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xe" for details.

Translate CentOS 7 service paths to AlmaLinux 8 equivalents. Sometimes a simple path difference blocks startup.


7. Traffic Cutover / Rollback

Schedule a migration window. Once validation is green, switch DNS, VIP, or IPs to point clients at the new AlmaLinux system. Keep CentOS 7 host powered (but isolated) for rapid rollback if needed.


One Non-Obvious Tip

Some applications’ config files or data formats evolve across OS major versions. Example: OpenSSL and system crypto policies in RHEL/AlmaLinux 8 are notably stricter—TLS handshakes may break with legacy service defaults. Test all outbound and inbound encryption scenarios, especially if your stack isn’t containerized.


Summary

  • No in-place or automated upgrade tool reliably bridges CentOS 7 to AlmaLinux 8. Team discipline and incremental migration yield much better results.
  • Inventory, backup, and staged cutover are not optional.
  • Setting up test environments and validating every service post-migration avoids production outages.

The uncomfortable reality: for CentOS 7-era servers, the safest strategy is to provision fresh AlmaLinux instances and migrate workloads deliberately, service by service. This path yields a clean, future-proof environment.


For scenarios involving container orchestration, multi-node database clusters, or CI-driven configuration, workflow and validation steps will diverge—be prepared to adapt this strategy.


End of migration guide.