No CentOS 7 uz AlmaLinux 9: divi godīgi ceļi

CentOS 7 dzīves cikls beidzās 2024. gada 30. jūnijā. Tajā rītā nekas nenotika, serveris turpināja strādāt, un tieši tā ir problēma. Šodienas CentOS 7 mašīna ielādē 3.10 kodolu, izmanto glibc 2.17 un OpenSSL 1.0.2, un neviens no tiem vairs nesaņem labojumus. Šeit ir divi ceļi prom no tā, kas tiešām strādā: jauns AlmaLinux 9 serveris ar datu pārnesi, ko iesakām visam, kas ir pieejams no interneta, un pārinstalēšana uz vietas ar ELevate tām mašīnām, kuras patiešām nevar uzbūvēt no jauna.

Kas īsti pārstāj strādāt

Acīmredzamā atbilde ir drošības atjauninājumi, un tā ir taisnība, bet praksē kļūmes parasti nāk no citas puses.

• Pakotnes kļūst grūti uzstādīt. mirror.centos.org vairs nedarbojas. CentOS 7 palicis tikai vault.centos.org, iesaldēts versijā 7.9.2009. Viss, ko no turienes uzstādāt, ir tikpat vecs kā atbalsta beigu diena.
• Mūsdienu programmatūra atsakās strādāt. Jaunākajam Node.js, konteineru dzinējiem, monitoringa aģentiem un daudzām Composer vai pip pakotnēm vajag jaunāku glibc, OpenSSL 3 vai Python versiju, kādas CentOS 7 nav.
• Sveši serveri sāk jums atteikt savienojumu. Šī ir tā kļūme, kas pienāk bez brīdinājuma. Maksājumu vārtejas, bankas un partneru API atslēdz TLS 1.0 un 1.1 un vecos šifrus, un jūsu cron skripts pēkšņi nevar pieslēgties. OpenSSL 1.0.2 vispār neprot TLS 1.3.
• Sertifikātu atjaunošana klusi apstājas. ACME klienti ir pametuši Python 2, tāpēc neaiztikts CentOS 7 serveris agrāk vai vēlāk vairs nespēj atjaunot savus sertifikātus.
• Auditi un anketas. Jebkurā klienta drošības pārbaudē, PCI vērtējumā vai apdrošinātāja anketā šī OS tagad parādās kā atsevišķs punkts.

Vispirms saprotiet, kas uz vecās mašīnas vispār strādā

Lielākā daļa neveiksmīgo migrāciju izgāžas tāpēc, ka uz vecā servera darbojās kaut kas, ko neviens neatcerējās. Veltiet stundu inventarizācijai. Uz CentOS 7 mašīnas:

rpm -qa --qf '%{NAME} %{VERSION} %{VENDOR}\n' | sort -k3 > /root/inventory-packages.txt
systemctl list-unit-files --state=enabled > /root/inventory-services.txt
ss -tulpn > /root/inventory-ports.txt
iptables-save > /root/inventory-iptables.rules
crontab -l; ls -l /etc/cron.d /etc/cron.daily
for u in $(getent passwd | awk -F: '$3>=1000 {print $1}'); do crontab -l -u $u; done
httpd -M; php -v; php -m
mysql -e "SELECT VERSION(); SHOW DATABASES;"

Šķirošana pēc ražotāja ir noderīgākais paņēmiens: tā uzreiz parāda visu, kas nācis no EPEL, Remi, IUS vai Webtatic, un tieši šai programmatūrai AlmaLinux 9 nav automātiska ekvivalenta. Pēc tam atrodiet failus, kas nepieder nevienai pakotnei, un konfigurācijas, kas rediģētas ar roku:

rpm -Va --nomtime --nosize | grep '^..5' | grep ' c '
find /opt /usr/local /srv -maxdepth 3 -type f | head -100

Ja uz vecās mašīnas migrācijai vēl kaut kas jāuzstāda, pārslēdziet yum uz vault. Tas ir iesaldēts, tāpēc izmantojiet to tikai migrācijai:

cp -a /etc/yum.repos.d/CentOS-Base.repo /root/CentOS-Base.repo.bak
sed -i 's|^mirrorlist=|#mirrorlist=|' /etc/yum.repos.d/CentOS-Base.repo
sed -i 's|^#\?baseurl=http://mirror.centos.org/centos/$releasever|baseurl=http://vault.centos.org/7.9.2009|' /etc/yum.repos.d/CentOS-Base.repo
grep -E '^(mirrorlist|baseurl)' /etc/yum.repos.d/CentOS-Base.repo
yum clean all && yum makecache

grep te nav dekorācija. Ja šablons nesakrīt, aizvietošana klusi neizdodas un yum joprojām rādīs uz serveri, kas vairs neatbild, tāpēc pārbaudiet, pirms turpināt: katram baseurl tagad jāsākas ar http://vault.centos.org/7.9.2009, un katrai mirrorlist rindai jābūt izkomentētai. Viena reize nosedz base, updates, extras un centosplus, jo tās ir vienā failā. Katru citu repozitoriju, kas jums vēl ir, EPEL vai SCLo, vai nu norādiet uz tā arhīvu, vai izslēdziet uz šo laiku.

Pirmais ceļš: jauns AlmaLinux 9 serveris

Šo ceļu iesakām mājas lapām, veikaliem, API un visam, kam priekšā ir lietotāji. Jūs uzbūvējat tīru mašīnu, pārnesat datus, testējat, kamēr vecais serveris vēl strādā, un pārslēgšanās ir DNS izmaiņa, ko var atgriezt atpakaļ. Konversija uz vietas neko no tā nedod. Jauno mašīnu var paņemt kā VPS, ja slodze to atļauj, vai kā nomātu serveri, ja trūkst procesora vai diska. Abi darbojas mūsu pašu datu centrā Rīgā un mūsu pašu tīklā, un, ja jūsu pašreizējais serveris jau ir pie mums, vecā un jaunā mašīna darbu laikā paliek vienā datu centrā.

Vispirms izdariet bāzes darbu: lietotāji, SSH atslēgas, laika josla, monitorings, rezerves kopiju aģents. Tad atkārtojiet steku, nevis mašīnu. Mērķis ir atbalstīta AlmaLinux 9 konfigurācija, kas darbina jūsu lietotni, nevis desmit gadus vecas iekārtas kopija baitu pa baitam.

Versiju lēcieni, kas sāp

Komponents	CentOS 7	AlmaLinux 9	Kas salūzt
PHP	5.4 bāzē	8.0 AppStream, 8.1 un jaunāki kā moduļu straumes	mod_php vairs nav, izņemtas funkcijas, stingrāki salīdzinājumi
Datubāze	MySQL 5.7 vai MariaDB 5.5	MariaDB 10.11 kā moduļa straume, MySQL 8.0 kā parasta pakotne	sql_mode stingrība, nulles datumi, autorizācijas spraudņi, kolācijas
Python	2.7 kā /usr/bin/python	3.9 sistēmā, Python 2 nav vispār	katrs skripts ar veco shebang rindu
TLS	OpenSSL 1.0.2	OpenSSL 3 un sistēmas kriptopolitika	TLS 1.0 un 1.1 izslēgti, SHA-1 paraksti un RSA zem 2048 bitiem noraidīti
Ugunsmūris	iptables	nftables ar firewalld 1.x	saglabātie noteikumi neielādējas, ipset un iptables-nft ir novecojuši
Tīkla konfigurācija	ifcfg network-scripts	NetworkManager keyfile	network-scripts pakotnes vairs nav
SELinux	parasti izslēgts	enforcing, targeted politika	atteikumi, kas izskatās pēc lietotnes kļūdām

PHP

Vispirms pārbaudiet, kādas straumes piedāvā tieši jūsu minorversija, jo tās tika pievienotas AlmaLinux 9 dzīves laikā, un vienkāršs dnf install php uzstāda 8.0:

dnf module list php
dnf module enable php:8.2 -y
dnf install -y php php-fpm php-mysqlnd php-gd php-mbstring php-xml php-opcache
systemctl enable --now php-fpm

Strukturālā izmaiņa, ko neviens negaida: EL8 un EL9 mod_php vairs nepastāv. PHP darbojas caur php-fpm, un Apache ar to runā pa ligzdu. Šajā daļā jums nekas nav jādara: PHP pakotnes uzstāda /etc/httpd/conf.d/php.conf ar globālu FilesMatch un SetHandler bloku, tāpēc PHP strādā katrā vhostā bez papildu izmaiņām. Apstrādātāju rakstāt tikai tad, ja konkrētam vhostam vajag savu php-fpm pūlu:

SetHandler "proxy:unix:/run/php-fpm/app.sock|fcgi://localhost"

Patiesībā salūzt pretējais: vecās konfigurācijas paliekas, un tās izpaužas divos dažādos veidos. Atsevišķa php_value vai php_flag rinda bez mod_php ir nezināma direktīva: vhostā vai httpd.conf Apache atsakās startēt ar Invalid command 'php_value', bet .htaccess failā tā atdod 500 tikai tajā ceļā, kamēr pārējā vietne turpina strādāt. Klusā kļūme ir tā, kas jāmeklē pašam: viss, kas ir <IfModule mod_php5.c> blokā, tiek izlaists bez vārda, jo moduļa vairs nav, tāpēc šie iestatījumi vienkārši pazūd un žurnālā par tiem nav ne rindas. AddHandler php5-script ir parasta mod_mime direktīva, tā Apache nekad neaptur, un globālais SetHandler no php.conf tiek piemērots pēc .htaccess un uzvar, tāpēc PHP joprojām strādā un rinda ir tikai lieks balasts. Lai arī no kurienes tās nākušas, pašus iestatījumus pārceliet uz pūla failu zem /etc/php-fpm.d/ kā php_admin_value[...] ierakstus vai uz /etc/php.d/.

Kodā, kas rakstīts 5.4 laikā, būs mysql_* izsaukumi, each(), create_function() un figūriekavu virkņu indeksi, kas visi ir izņemti. PHP 8 mainīja arī virknes un skaitļa salīdzināšanu, tāpēc "abc" == 0 tagad ir false, un tas klusi maina vecas validācijas uzvedību, nevis met kļūdu. Sāciet ar sintakses pārbaudi, tad lasiet kodu:

find /var/www -name '*.php' -print0 | xargs -0 -n1 -P4 php -l | grep -v 'No syntax errors'

Datubāzes

Veidojot dumpu, norādiet kodējumu skaidri, un lietojiet --lock-all-tables, nevis --single-transaction, ja kāda tabula vēl ir MyISAM:

mysqldump --single-transaction --routines --triggers --events --default-character-set=utf8mb4 --databases app > /root/app.sql

Uz jaunās mašīnas ieslēdziet straumi, uzstādiet un importējiet:

dnf module list mariadb
dnf module enable mariadb:10.11 -y
dnf install -y mariadb-server
systemctl enable --now mariadb
mysql < /root/app.sql
mariadb-upgrade

Ja paliekat pie MySQL, nevis MariaDB, moduļa soli izlaidiet pilnībā: AlmaLinux 9 sistēmā MySQL 8.0 ir parasta AppStream pakotne, nekādas mysql straumes, ko ieslēgt, nav, un dnf install -y mysql-server ir visa komanda. Ievērojiet nosaukumus: sākot ar MariaDB 10.5, rīki saucas mariadb, mariadb-dump un mariadb-upgrade, bet vecais mysql_upgrade palicis tikai kā simbolsaite. Importā regulāri klūp divas lietas. DEFINER klauzulas skatos un procedūrās norāda uz lietotājiem, kuru vēl nav, tāpēc vispirms izveidojiet lietotājus vai noņemiet klauzulas. Un datumi 0000-00-00 ar stingrāko noklusēto sql_mode tiek noraidīti, kas vecu ierakstu pārvērš par kļūdu darbības laikā, nevis importā. Norādiet character_set_server un sql_mode skaidri failā zem /etc/my.cnf.d/, nevis paļaujieties uz noklusējumiem, jo tie versijās atšķiras.

Python 2

AlmaLinux 9 Python 2 nav vispār, arī ne kā modulis, un /usr/bin/python pēc noklusējuma neeksistē. Katrs iekšējais skripts ar #!/usr/bin/python uzreiz izmet kļūdu. Mazus skriptus parasti ātrāk pārrakstīt. EL8 vēl bija pakotne python2, tāpēc apstāšanās uz AlmaLinux 8 dod interpretatoru, ko var uzstādīt, tikai arī tā straume 2024. gada jūnijā beidza dzīves ciklu un labojumus vairs nesaņem, bet uz 9 vairs nav ko uzstādīt vispār. Kodam, ko tiešām nevar pārrakstīt, paliek divi varianti: konteiners, kas būvēts uz vecāka bāzes attēla, vai palikšana uz vecās mašīnas, līdz to kāds pārraksta. Nekompilējiet Python 2 no pirmkoda uz produkcijas servera. Atsevišķs gadījums, uz ko atbild python3.11, ir lietotne, kurai vajag jaunāku Python 3 nekā sistēmas 3.9: uzstādiet paralēlo pakotni python3.11 un dodiet lietotnei savu virtualenv.

Šifri un kriptopolitika

AlmaLinux 9 uztur sistēmas mēroga kriptopolitiku. Ar DEFAULT ir izslēgts TLS 1.0 un 1.1, noraidīti SHA-1 paraksti un RSA atslēgas zem 2048 bitiem. Tas attiecas arī uz izejošajiem savienojumiem, tāpēc skripts, kas runā ar vecu partnera galapunktu, uz jaunās mašīnas var neizdoties, kaut uz vecās strādāja. Vispirms pārbaudiet, tad atslābiniet tikai tik, cik nepieciešams:

update-crypto-policies --show
update-crypto-policies --set DEFAULT:SHA1

Pēc tam pārstartējiet attiecīgos servisus, jo ilgi strādājošie dēmoni politiku nolasa startā. Divas radniecīgas lamatas: OpenSSL 3 neatvērs vecus PKCS#12 failus ar RC2, tāpēc vajag openssl pkcs12 -legacy -in old.pfx, un SSH pieslēgums ar vecu ssh-rsa SHA-1 atslēgu tiks atteikts. Šis labojums jāieliek pareizajā vietā. Faila /etc/ssh/sshd_config sākumā ir Include /etc/ssh/sshd_config.d/*.conf, komplektā iekļautais 50-redhat.conf pievieno kriptopolitikas failu, kurā PubkeyAcceptedAlgorithms jau ir uzstādīts, un sshd katram parametram paņem pirmo atrasto vērtību. Tāpēc rinda, kas pierakstīta sshd_config beigās, tiek klusi ignorēta, un cilvēkam, kurš jau ir izslēgts no servera, tas ir sliktākais iespējamais iznākums. Lietojiet atsevišķu failu, kas kārtojas agrāk:

echo 'PubkeyAcceptedAlgorithms +ssh-rsa' > /etc/ssh/sshd_config.d/40-legacy-rsa.conf
sshd -t && systemctl reload sshd

Visas šīs lietas uzskatiet par pagaidu tiltiem ar konkrētu beigu datumu.

No iptables uz nftables un firewalld

Saglabātais iptables noteikumu komplekts vienkārši neielādēsies. Godīgie varianti ir pārrakstīt politiku firewalld, ko vairumam serveru arī vajadzētu darīt, vai pārtulkot komplektu, ja tajā ir reāla loģika. Tulkošanai uzstādiet saderības rīkus uz jaunās mašīnas, pārtulkojiet un izlasiet rezultātu pirms piemērošanas. Dariet to ar atvērtu konsoles piekļuvi, jo pārtulkots noteikumu komplekts var jūs pašus izslēgt no SSH tikpat viegli kā ar roku rakstīts, un izvēlieties vienu ugunsmūra saimnieku: ja komplektu ielādējat ar nftables.service, izslēdziet firewalld, citādi abi pārrakstīs viens otru.

dnf install -y iptables-nft nftables
iptables-restore-translate -f /root/inventory-iptables.rules > /root/ruleset.nft
nft -c -f /root/ruleset.nft
nft -f /root/ruleset.nft

Vairumam slodžu firewalld ir mazāk darba un vieglāk nodot tālāk kolēģim:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="3306" protocol="tcp" accept'
firewall-cmd --reload
firewall-cmd --list-all

Divas lietas jāzina. firewalld 1.x izņēma zonu dreifu un mainīja pārsūtīšanas noklusējumus zonas iekšienē, tāpēc konfigurācija, kas pārkopēta no EL7 laika pamācības, var uzvesties citādi. Un ipset un iptables-nft šajā laidienā ir atzīti par novecojušiem, tāpēc neko jaunu uz tiem nebūvējiet. Ja lietojat fail2ban, skaidri norādiet nftables vai firewalld darbību un pēc tam pārbaudiet ar nft list ruleset, ka bloķēšana tiešām notiek: kluss un nedarbīgs fail2ban ir sliktāks par tā neesamību.

SELinux atkal ir ieslēgts

Gandrīz katrā reālā CentOS 7 mašīnā ir SELINUX=disabled. Svaigi uzstādīts AlmaLinux 9 ir enforcing režīmā, un simptomi izskatās pēc lietotnes kļūdām: Apache atdod 403 dokumentu saknei ārpus /var/www, php-fpm nevar rakstīt sesijas, serviss nevar atvērt nestandarta portu, izejošs savienojums tiek atteikts bez redzama iemesla. Lasiet atteikumus, nevis minējiet:

dnf install -y policycoreutils-python-utils setroubleshoot-server
ausearch -m AVC -ts recent
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/app/storage(/.*)?"
restorecon -Rv /var/www/app
setsebool -P httpd_can_network_connect on
semanage port -m -t http_port_t -p tcp 8080

Šis bloks ir izvēlne, nevis skripts. Palaidiet uzstādīšanu un ausearch, pēc tam tikai to labojumu, kas atbilst tieši jūsu redzētajam atteikumam. Īpaši setsebool -P httpd_can_network_connect on: tas pastāvīgi atļauj katram httpd procesam iet uz āru tīklā, tāpēc neaiztieciet to, ja vien atteikums to neprasa. Ievērojiet -m porta rindā: ar -a komanda apstājas ar ValueError: Port tcp/8080 already defined, jo targeted politikā 8080 jau ir http_cache_port_t, tāpēc tipu var tikai mainīt, nevis pievienot. Portiem 8008, 8009, 8443 un 9000 komanda nav vajadzīga vispār, tie jau ir http_port_t. Rīks semanage starp laidieniem nomainīja pakotni: EL7 tas bija policycoreutils-python, EL8 un EL9 tas ir policycoreutils-python-utils. Pēc liela rsync pārmarķējiet pārkopētos datus ar restorecon -R vai piespiediet pilnu pārmarķēšanu ar touch /.autorelabel un pārstartēšanu. Ja migrācijas vidū esat iestrēdzis, setenforce 0 pārslēdz SELinux permissive režīmā, kur var savākt visus atteikumus vienā piegājienā, izlabot un ieslēgt atpakaļ. Nemēģiniet to izslēgt pavisam: AlmaLinux 9 ieraksts SELINUX=disabled failā /etc/selinux/config vairs pilnībā nestrādā, kodols startē ar ieslēgtu SELinux bez ielādētas politikas, un atbalstītais veids ir kodola parametrs ar grubby --update-kernel ALL --args selinux=0. Tas ir lēmums, kas jāspēj pamatot.

Testēšana, pirms to redz kāds cits

Novirziet savu darbstaciju uz jauno IP adresi ar ierakstu hosts failā un izmantojiet lietotni pa īstam: ielogojieties, augšupielādējiet failu, izejiet pasūtījuma soļus, izsauciet e-pastus, palaidiet katru cron uzdevumu ar roku tā lietotāja vārdā, kam tas pieder. Tajā pašā laikā skatieties žurnālos:

journalctl -u php-fpm -u httpd -p warning --since "15 min ago"
tail -f /var/log/php-fpm/www-error.log

Divas lietas aizmirstas katru reizi. Izejošais pasts ir piesaistīts jaunajai IP: pārbaudiet PTR ierakstu, SPF un DKIM pirms pārslēgšanas, nevis pēc pirmās atgrieztās vēstules. Un katram partnerim, kas filtrē pēc jūsu IP, maksājumu sniedzējam, bankai, piegādātāja API, jaunā adrese jāpievieno dažas dienas iepriekš. Pirmajās dienās ieslēdziet arī lēno vaicājumu žurnālu, jo MariaDB 10.11 optimizators ne vienmēr izvēlas to pašu plānu, ko MySQL 5.7, un vaicājums, kas bija ātrs, reālā slodzē var kļūt lēns.

Pati pārslēgšana

Vispirms samaziniet DNS TTL, un dariet to laikus. Ja ierakstam tagad ir 24 stundu TTL, šodienas izmaiņa rītdienai nepalīdz, jo resolveri veco vērtību tur līdz vecajam TTL beigām. Nolaidiet to uz 300 sekundēm, nogaidiet iepriekšējo TTL un tikai tad plānojiet pāreju.

Pārejas dienā: ieslēdziet apkopes režīmu, palaidiet pēdējo rsync ar rsync -aHAX --numeric-ids --delete, paņemiet pēdējo datubāzes dumpu, importējiet, pārmarķējiet, palaidiet servisus, pārbaudiet jauno mašīnu caur hosts ierakstu un tikai tad mainiet DNS. Veco serveri atstājiet ieslēgtu un vērojiet abu access žurnālus, līdz vecais apklust, kas parasti aizņem TTL laiku plus astes garumu no slikti uzvedīgiem klientiem. Pēc dienas vai divām TTL atgrieziet atpakaļ.

Vecais serveris kā atkāpšanās logs

Neatsakieties no vecās mašīnas tajā pašā nedēļā. Paturiet to nedēļu vai divas, bet apturiet uz tās lietotni un pārslēdziet datubāzi tikai lasīšanas režīmā, citādi klients ar iekešotu DNS atbildi ieraksta pasūtījumu datubāzē, kurā neviens vairs nekad neieskatīsies. Šī datu sadalīšanās ir īstais risks pēc pārejas, nevis pati migrācija. Esiet godīgs par atkāpšanās logu: tas ir tīrs pirmajās stundās, un pēc tam, kad uz jaunā servera nonākuši reāli ieraksti, atgriešanās nozīmē datu salikšanu ar roku.

Otrais ceļš: pārinstalēšana uz vietas ar ELevate

Reizēm pārbūve nav iespējama: licence piesaistīta dzelzij, iekārta ar specifisku lomu vai mašīna ar desmit gadu vecu, nedokumentētu skriptu slāni. AlmaLinux ELevate, kas balstīts uz leapp, spēj konvertēt uz vietas. Divi fakti uzreiz. Tieša ceļa no CentOS 7 uz AlmaLinux 9 nav. Vispirms CentOS 7 uz AlmaLinux 8, tad AlmaLinux 8 uz AlmaLinux 9, kas nozīmē divus atjauninājumus, divus pārstartēšanas logus un posmu uz starpversijas. Un ELevate atjaunina operētājsistēmu, nevis jūsu lietotni: viss iepriekš aprakstītais darbs ar PHP, datubāzi un kriptogrāfiju paliek, tikai tagad uz dzīva servera.

Sāciet ar yum pārslēgšanu uz vault, kā parādīts augstāk. Šajā ceļā tas nav izvēles solis: neaiztiktai CentOS 7 mašīnai mirrorlist.centos.org atbild ar 404, yum update apstājas ar Cannot find a valid baseurl for repo: base/7/x86_64, un leapp bloķē atjaunināšanu sistēmā, kas nav pilnībā atjaunināta. Pirms pirmās komandas paņemiet momentuzņēmumu vai pilnu rezerves kopiju un sagatavojiet konsoles piekļuvi ārpus tīkla, jo jau pirmā rinda atjaunina mašīnu, kas nav atjaunināta gadiem, un pēc tam to pārstartē. Kad vault repozitorijs ir vietā:

yum update -y && reboot
yum install -y https://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux
leapp preupgrade

Izlasiet /var/log/leapp/leapp-report.txt pilnībā un novērsiet katru bloķētāju. Tipiskākie ir trešo pušu repozitoriji bez atbilstības kartes, izmainīts sshd_config, kas atjaunināšanas fāzē neļauj root pieslēgumu, un neatbalstīti kodola moduļi. Atskaites beigās ir arī vismaz viens jautājums, uz kuru jāatbild atsevišķi, uz CentOS 7 gandrīz vienmēr par pam_pkcs11, un bez atbildes leapp upgrade nesāksies. Atbildiet apzināti, nevis ielīmējiet gatavu rindu: confirm=True nozīmē, ka piekrītat pam_pkcs11 moduļa izņemšanai, kas parastam serverim ir pareizi, bet serverim, kurā cilvēki pieteicas ar viedkartēm, nav. Kad atskaite ir tīra:

leapp answer --section remove_pam_pkcs11_module_check.confirm=True
leapp upgrade
reboot

Šī pārstartēšana ielādē īpašu atjaunināšanas initramfs un ilgst ilgi. Tieši te noder konsoles piekļuve: ja ielāde tur apstājas, SSH vairs neatgriezīsies, un vienīgā atsaukšana ir momentuzņēmums, ko paņēmāt iepriekš. Tad secību atkārtojiet uz AlmaLinux 8, lai nokļūtu līdz 9, sākot ar elevate-release uzstādīšanu un ar dnf, nevis yum: pārslēgšana uz vault ir CentOS 7 solis un tur neder. Pēc tam sakopiet palikušo:

rpm -qa | grep -E 'el7|el8'
find /etc -name '*.rpmnew' -o -name '*.rpmsave'
systemctl list-units --state=failed

Kur ELevate īsti neder: serveri ar vadības paneļiem, kuriem ir savi ražotāja migrācijas rīki, mašīnas ar netipisku diska konfigurāciju un viss, kam nevar dabūt konsoli. Mašīnai izvietošanā, ko nevar vienkārši nodublēt, šis ceļš ir saprātīgs. Publiskam tīmekļa serverim jauna servera uzbūve gandrīz vienmēr ir ātrāka un drošāka.

Nākamā nedēļa

Pārbaudiet, vai rezerves kopijas uz jaunā servera tiešām izveidojās un vai atjaunošana strādā, nevis tikai to, ka uzdevums beidzās bez kļūdas. Pārliecinieties, ka logrotate apstrādā jaunos žurnālu ceļus, ka monitoringa aģents ziņo un ka drošības atjauninājumi ir automatizēti ar dnf-automatic. Pārstartēšanas atkal ir svarīgas: pēc kodola vai glibc atjauninājuma tā ir vajadzīga, un dnf needs-restarting -r pateiks, kad. Ja pēc pārcelšanās kaut kas uzvedas dīvaini, mūsu inženieri ir pieejami visu diennakti, un IT atbalsts var salīdzināt jauno mašīnu ar veco, kamēr tā vēl ir pieejama.