Eind 2022 hebben we de Mail XXL server geüpgrade naar AlmaLinux 8. Voorheen moest je in zo'n situatie een nieuwe server opzetten, en al je diensten daar naartoe migreren. Dat is gelukkig niet meer de enige optie; sinds kort heeft AlmaLinux de 'ELevate' tool welke je in staat stelt om met een paar commando's te upgraden naar AlmaLinux 8, iets wat je erg veel werk kan schelen. In deze blog lees je hoe wij dat succesvol hebben toegepast op onze Mail XXL server.
Mocht je deze upgrade op je eigen server uit willen voeren, dan is deze blog interessant voor wat tips en waar wij tegenaan liepen en welke stappen je uit moet voeren. Voor de volledige documentatie, broncode en instructies verwijs ik graag naar de officiële site van cPanel: https://cpanel.github.io/elevate/. Let er ook op dat als je deze upgrade gaat uitvoeren, dat klanten op de hoogte zijn. De upgrade heeft geen invloed op het functioneren van de diensten, maar gaat wel gepaard met wat downtime.
Voorbereiden op de ELevate
Elevate volgt de volgende stappen als je het uitvoert;
- Er wordt gecontroleerd op upgrade blockers waardoor de upgrade niet mogelijk is
yum update && reboot
Tip: Nu is het systeem nog ongewijzigd en up-to-date: hier hebben wij een extra back-up gemaakt.- Packages die geïnstalleerd zijn worden door ELevate vastgelegd, en daarna verwijderd exclusief de data.
- AlmaLinux ELevate zelf wordt uitgevoerd
- De eerder verwijderde software wordt weer terug geïnstalleerd met hun AlmaLinux 8 versies, zoals bijvoorbeeld
- cPanel (upcp)
- EA4
- MySQL
- Distro Perl/PECL
6. Laatste reboot
ELevate script installeren
Je kunt het script snel en eenvoudig downloaden met het volgende commando. Geen zorgen; er wordt nog niets geks uitgevoerd, dus je het kunt het gerust uitvoeren.
Eventuele upgrade-blockers controleren
Als je de vorige stap uitgevoerd hebt, kun je nu het check-proces uitvoeren. In de output kun je dan zien welke voorbereidingen je nog moet treffen voordat je kunt upgraden naar AlmaLinux 8. Waarschijnlijk zijn dat wel een paar. Je kunt het uitvoeren met het volgende commando;
De output ziet er dan zo ongeveer uit (ik heb de output verkort in dit voorbeeld)
Op basis van deze output hebben we voorbereidingen getroffen op de upgrade. In ons geval was dat onder andere MySQL upgraden, netwerkkaarten.
Let er op dat het oplossen van deze upgrade-blockers ook impact kunnen hebben op de sites die je hebt draaien. Een eis voor AlmaLinux 8 is dat je alles op MySQL 8 en PHP 7.3 of nieuwer hebt draaien. Als je applicatie niet geschikt hiervoor is, dan is het upgraden naar AlmaLinux met ELevate pas mogelijk als alle sites geschikt zijn voor beide systemen.
MySQL upgraden
Een van de grootste upgrade blockers is MySQL. Als je cPanel op CentOS 7 installeert, krijg je daar standaard MySQL 5.7 bij. MySQL 5.7 is echter zelf ook al bijna end-of-life, en wordt vervangen door MySQL 8.
Op AlmaLinux 8 is MySQL 5.7 echter niet beschikbaar. Hierdoor moet je dus eerst naar MySQL 8 upgraden, om vervolgens ELevate uit te kunnen voeren. cPanel heeft hier gelukkig ingebouwde tools voor, welke je kunt gebruiken om dit te doen.
Let op! Afhankelijk van hoeveel databases je op het systeem hebt, gaat MySQL een tijdje offline. Dit kan tussen de 5 en 30 minuten duren, hoe meer databases hoe langer. Ook kan het proces mis gaan. Maak dus een backup! Aangezien de Mail XXL server geen databases host, was dit puur een formaliteit voor ons.
Ik raad aan om het via de WHM te doen. Open hier het MySQL/MariaDB Upgrade tabblad. Hier kies je MySQL 8.0, en kies je Continue.
Hier vink je het vinkje aan, en kies je continue.
Kies vervolgens voor Unattended Upgrade en klik op Continue. Ik heb beide opties een keer gebruikt, maar ik kon het verschil niet ontdekken. In beide gevallen wordt het proces op de achtergrond aangezet, en kun je de output volgen in de browser. De interactive upgrade biedt eigenlijk geen interactie.
Mislukt de upgrade bij de eerste keer? Geen paniek; je kunt dan het beste de upgrade nog eens starten. Bij upgrades die ik zelf gedaan heb, moest ik altijd het proces 2 keer laten draaien.
Mocht het proces na 3 keer telkens nog mislukken met de melding dat de data dictionary conversion mislukt, zet dan een back-up terug. De upgrade is dan mislukt, en rollbacken is niet mogelijk. Er zijn dan waarschijnlijk een of meerdere databases waar een tabel vreemde karakters bevat. Het exporteren van deze tabellen, verwijderen, en terugzetten na de upgrade is dan de oplossing.
Oude PHP verwijderen
PHP 7.2 en ouder is niet meer beschikbaar vanaf AlmaLinux versie 8. Hierom is het belangrijk om te verifiëren dat alle sites op PHP 7.3 of nieuwer werken. Alle cPanel accounts bij Mail XXL stonden nog op PHP 7.2, maar ook dit is een formaliteit aangezien er toch geen websites op staan. Wij hebben alles omgezet naar 8.1.
Voor het omzetten zelf heb ik de MultiPHP Manager gebruiken. Hier kun je al je accounts omzetten naar een bepaalde PHP-versie.
Als je geen accounts meer hebt op PHP 7.2 of ouder, dan moet je deze nog even verwijderen van de server. Hiervoor kun je EasyApache gebruiken.
Kies hier voor Customize
De-selecteer onder PHP versions de php versies die ouder zijn dan 7.3. Nu je er toch bent, kun je ook direct php versies 8.0 en 8.1 installeren als je dat nog niet gedaan hebt. Kies vervolgens voor Next totdat je voor provision kunt kiezen.
Interfaces hernoemen
Dit stukje was het meest riskant, en kostte wat tijd om goed te krijgen. Je kunt elke netwerkkaart zien als een virtuele internetpoort waar een internetkabel op aangesloten zit. Standaard heeft een server er 3, een voor het publieke IPv4 adres, het interne IPv4 adres en het publieke IPv6 adres. Elke netwerkinterface heeft een automatisch gegenereerde naam, in de vorm van 'ethx', waar 'x' het nummer is. AlmaLinux 8 gebruikt hier een andere naamstandaard voor, en omdat deze namen standaard gegenereerd zijn, kan het zijn dat dit na de upgrade in de war raakt waardoor de server mogelijk niet meer goed online komt. Hierom moet je de configuratie aanpassen.
Je kunt deze interfaces zien met het commando ip link show
Je krijgt dan de volgende output
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 72:0a:b7:10:19:92 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 72:0a:b7:10:90:86 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 72:0a:b7:10:12:86 brd ff:ff:ff:ff:ff:ff
Je ziet dan 3 interfaces: eth0, eth1 en eth2. Met het commando ip addr
kun je ook zien welke IP adressen daar aan gekoppeld zijn.
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 72:0a:b7:10:19:92 brd ff:ff:ff:ff:ff:ff
inet <public_ipv4>/24 brd 109.71.54.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::700a:b7ff:fe10:1992/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 72:0a:b7:10:90:86 brd ff:ff:ff:ff:ff:ff
inet <private_ipv4>/22 brd 10.5.151.255 scope global dynamic eth1
valid_lft 1063sec preferred_lft 1063sec
inet6 fe80::700a:b7ff:fe10:9086/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 72:0a:b7:10:12:86 brd ff:ff:ff:ff:ff:ff
inet6 <public_ipv6>:1286/64 scope global dynamic mngtmpaddr
valid_lft 86121sec preferred_lft 14121sec
inet6 fe80::700a:b7ff:fe10:1286/64 scope link
valid_lft forever preferred_lft forever
Wij hebben elke interface de onderstaande naam gegeven:
eth0 -> public_ipv4
eth1 -> private_ipv4
eth2 -> public_ipv6
Ik heb hier het onderstaande script voor gebruikt. Het script doet 3 dingen;
- Voegt het MAC adres toe aan de configuratie. Een MAC-adres is een fysiek adres die nooit veranderd, waar een IP adres wel kan veranderen.
- Hernoemd ethx naar de nieuwe naam, dus bijvoorbeeld eth0 naar public_ipv4
- Herstart de netwerkinterfaces.
Mocht je de server niet meer kunnen bereiken, start de server dan opnieuw op. Dat werkt ook om de nieuwe instellingen toe te passen.
#!/bin/bash
if [ -f /etc/sysconfig/network-scripts/ifcfg-eth0 ]
then
# rename eth0 to public_ipv4
echo "HWADDR=$(ip link show eth0 | grep ether | awk '{print $2}')" >> /etc/sysconfig/network-scripts/ifcfg-eth0
sed -i 's/eth0/public_ipv4/g' /etc/sysconfig/network-scripts/ifcfg-eth0
# move ifcfg-eth0 to ifcfg-public_ipv4
mv /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-public_ipv4
ip link set down eth0
ip link set eth0 name public_ipv4
ip link set up public_ipv4
else
echo "eth0 does not exist - probably already renamed"
fi
# --------------------------------------------------------------- #
if [ -f /etc/sysconfig/network-scripts/ifcfg-eth1 ]
then
# rename eth1 to private_ipv4
echo "HWADDR=$(ip link show eth1 | grep ether | awk '{print $2}')" >> /etc/sysconfig/network-scripts/ifcfg-eth1
sed -i 's/eth1/private_ipv4/g' /etc/sysconfig/network-scripts/ifcfg-eth1
# remove line device from ifcfg-eth1
# move ifcfg-eth1 to ifcfg-private_ipv4
mv /etc/sysconfig/network-scripts/ifcfg-eth1 /etc/sysconfig/network-scripts/ifcfg-private_ipv4
ip link set down eth1
ip link set eth1 name private_ipv4
ip link set up private_ipv4
else
echo "eth1 does not exist - probably already renamed"
fi
# --------------------------------------------------------------- #
if [ -f /etc/sysconfig/network-scripts/ifcfg-eth2 ]
then
# rename eth2 to public_ipv6
echo "HWADDR=$(ip link show eth2 | grep ether | awk '{print $2}')" >> /etc/sysconfig/network-scripts/ifcfg-eth2
sed -i 's/eth2/public_ipv6/g' /etc/sysconfig/network-scripts/ifcfg-eth2
# move ifcfg-eth2 to ifcfg-public_ipv6
mv /etc/sysconfig/network-scripts/ifcfg-eth2 /etc/sysconfig/network-scripts/ifcfg-public_ipv6
ip link set down eth2
ip link set eth2 name public_ipv6
ip link set up public_ipv6
else
echo "eth2 does not exist - probably already renamed"
fi
dhclient
Als het goed is, ziet na het uitvoeren van het bovenstaande script de netwerkconfiguratie er zo uit:
# cat /etc/sysconfig/network-scripts/ifcfg-public_ipv4
BOOTPROTO=static
ONBOOT=yes
IPADDR=<ipadres>
NETMASK=255.255.255.0
GATEWAY=<ipadres>
HWADDR=72:0a:b7:10:04:c7
DEVICE=public_ipv4
ELevate uitvoeren
Toen alle checks uitgevoerd waren, hebben we nog één keer yum update
uitgevoerd. Die heeft nog een aantal updates geïnstalleerd waarna met een laatste reboot
de server klaar was om ge-ELevate te worden.
Nu alles klaar staat, hebben wij nog een snapshot backup gemaakt. Na het uitvoeren van ELevate is er niet echt meer een weg terug; het is dus belangrijk om deze backup achter de hand te hebben mochten zaken in de soep lopen.
Het ELevate proces kun je starten met het commando:
/scripts/elevate-cpanel --start --upgrade-to=almalinux
ELevate wordt nu gestart. Na een aantal laatste checks gaat het systeem aan de slag om de server te upgraden.
Bij ons gingen de stages 1 en 2 vlekkeloos. Bij stage 3 ging het echter mis; het proces kwam een package tegen wat voor conflicten zorgde. Dit package was 'openssl-libs-1'; zie ook onderstaande melding:
2022-12-28 16:50:32.943 DEBUG PID: 60811 leapp.workflow.Download.dnf_package_download: file /usr/lib64/libcrypto.so.1.1.1k from install of openssl-libs-1:1.1.1k-7.el8_6.x86_64 conflicts with file from pack
Ik heb het opgelost door 'openssl-libs-1' te verwijderen met het commando yum remove openssl-libs-1
Vervolgens kon ik het proces weer vervolgen met het commando /scripts/elevate-cpanel --continue
.
Stage 4 duurde het langste; maar deze gebeurde ook compleet offline. Tijdens stage 2 & 3 zijn alle cPanel services offline, maar kun je nog wel inloggen met SSH bijvoorbeeld.
Na stage 4, reboot de server naar stage 5. Let op! In mijn geval was de bootloader GRUB onjuist geconfigureerd; hij probeerde AlmaLinux met de oude kernel (3.x) op Ik moest hier handmatig via de server console de juiste, nieuwe kernel kiezen (4.x).
Bij stage 5 wordt alle software opnieuw geconfigureerd, afgesloten met één laatste reboot. Controleer ook hier even of GRUB goed zijn werk doet.
Het kan zijn dat na de laatste fase de server nog 1 laatste keer gereboot wordt. In mijn geval had ik vette pech; na de eerdere fout m.b.t. had ik besloten om GRUB nog even opnieuw te installeren met het commando grub2-install /dev/vda
. Dat is normaal gesproken een prima veilige actie om te doen, maar net toen het commando liep besloot ELevate om nog 1 reboot te doen. Hierdoor kon de server niet meer opstarten. Met een live-cd heb ik uiteindelijk de Grub configuratie weten te repareren gelukkig.
Conclusie
Dit was mijn ervaring met ELevate. Het proces is erg goed uitgedacht en verloopt grotendeels erg goed. Het neemt erg veel werk uit handen, maar toch voelt het nog als een erg riskant proces wat niet alles 100% vlekkeloos kan doen en waar dus toch nog een menselijke handeling voor nodig was. Toch ben ik erg positief over deze ontwikkeling; dit maakt het een stuk makkelijker om bestaande (cPanel) servers om te zetten naar een nieuw besturingssysteem zonder een hele nieuwe server te hoeven opzetten.