Ostatnia aktualizacja: 10.01.2024 r.

CentOS 7 oficjalnie traci wsparcie 30 czerwca 2024 roku. Kilka lat temu Red Hat pogrzebał ten projekt i zmienił jego kierunek. Społeczności jak i mi osobiście mocno się to nie spodobało. Na szczęście przyroda nie lubi pustki i miejsce CentOS`a zajęły dystrybucje AlmaLinux OS oraz Rocky Linux. Te dystrubucje Red Hat również próbuje "uzmienić". 😐

Oficjalnie GitLab wspiera AlmaLinux OS także na tą dystrybucję postanowiłem zmigrować. Cała operacja będzie "in-place" czyli z zachowaniem danych. Na moim CentOS`ie działa tylko GitLab, więc poziom skomplikowania zadania jest relatywnie mały. Jeśli na Twoim systemie działa więcej usług to poniższa instrukcja może być niekompletna dla Twojego przypadku.

Migracja do systemu AlmaLinux OS 8

1. Mój system zainstalowany jest na maszynie wirtualnej w systemie Proxmox więc przed rozpoczęciem prac wykonuję migawkę, do której się cofnę, jak coś pójdzie nie tak (a nie poszło kilka razy 😆). Dodatkowo mam nocny backup całej maszyny wirtualnej. Jeśli u Ciebie jest inaczej to musisz zastosować odpowiedni mechanizm kopii zapasowej pod swoją instalację.

   

2. Aktualizuję cały system i go restartuję.

   sudo yum check-update ; sudo yum update -y ; shutdown -r now

3. Sprawdzam czy mam najnowszą wersję systemu czyli CentOS 7.9.2009 (kernel 3.10).

   cat /etc/centos-release ; cat /etc/os-release

   

4. Instaluję ELevate, Leapp oraz paczkę migracji do AlmaLinux OS 8.

   sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm ; sudo yum install -y leapp-upgrade leapp-data-almalinux

5. Wykonuję "testową migrację". Narzędzie wykona szereg testów i wyświetli ewentualne problemy do rozwiązania. Ten etap trwał u mnie ok. 5 minut.

   sudo leapp preupgrade

   

6. Weryfikuję wygenerowany raport.

   sudo vi /var/log/leapp/leapp-report.txt

   Risk Factor: high (inhibitor)
   Title: Missing required answers in the answer file
   Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
   For more information consult https://leapp.readthedocs.io/en/latest/dialogs.html
   Remediation: [hint] Please register user choices with leapp answer cli command or by manually editing the answerfile.
   [command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True
   Key: d35f6c6b1b1fa6924ef442e3670d90fa92f0d54b
   ----------------------------------------
   Risk Factor: high
   Title: GRUB core will be updated during upgrade
   Summary: On legacy (BIOS) systems, GRUB core (located in the gap between the MBR and the first partition) does not get automatically updated when GRUB is upgraded.
   Key: baa75fad370c42fd037481909201cde9495dacf4
   ----------------------------------------
   Risk Factor: high
   Title: Packages not signed by Red Hat found on the system
   Summary: The following packages have not been signed by Red Hat and may be removed during the upgrade process in case Red Hat-signed packages to be removed during the upgrade depend on them:
   - elevate-release
   - gitlab-ce
   - gpg-pubkey
   - leapp
   - leapp-data-almalinux
   - leapp-deps
   - leapp-upgrade-el7toel8
   - leapp-upgrade-el7toel8-deps
   - python2-leapp
   Key: 13f0791ae5f19f50e7d0d606fb6501f91b1efb2c
   ----------------------------------------
   Risk Factor: high
   Title: Difference in Python versions and support in RHEL 8
   Summary: In RHEL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. Read more here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_basic_system_settings/#using-python3
   Remediation: [hint] Please run "alternatives --set python /usr/bin/python3" after upgrade
   Key: 0c98585b1d8d252eb540bf61560094f3495351f5
   ----------------------------------------
   Risk Factor: medium
   Title: SSH configuration automatically modified to permit root login
   Summary: Your OpenSSH configuration file does not explicitly state the option PermitRootLogin in sshd_config file. Its default is "yes" in RHEL7, but will change in RHEL8 to "prohibit-password", which may affect your ability to log onto this machine after the upgrade. To prevent this from occuring, the PermitRootLogin option has been explicity set to "yes" to preserve the default behaivour after migration. The original configuration file has been backed up to /etc/ssh/sshd_config.leapp_backup
   Remediation: [hint] If you would prefer to configure the root login policy yourself, consider setting the PermitRootLogin option in sshd_config explicitly.
   Key: 226502bd7d858185a700d2876791bed087c75cf5
   ----------------------------------------
   Risk Factor: medium
   Title: chrony using default configuration
   Summary: default chrony configuration in RHEL8 uses leapsectz directive, which cannot be used with leap smearing NTP servers, and uses a single pool directive instead of four server directives
   Key: c4222ebd18730a76f6bc7b3b66df898b106e6554
   ----------------------------------------
   Risk Factor: low
   Title: Grep has incompatible changes in the next major version
   Summary: If a file contains data improperly encoded for the current locale, and this is discovered before any of the file's contents are output, grep now treats the file as binary.
   The 'grep -P' no longer reports an error and exits when given invalid UTF-8 data. Instead, it considers the data to be non-matching.
   In locales with multibyte character encodings other than UTF-8, grep -P now reports an error and exits instead of misbehaving.
   When searching binary data, grep now may treat non-text bytes as line terminators. This can boost performance significantly.
   The 'grep -z' no longer automatically treats the byte '\200' as binary data.
   Context no longer excludes selected lines omitted because of -m. For example, 'grep "^" -m1 -A1' now outputs the first two input lines, not just the first line.
   
   Remediation: [hint] Please update your scripts to be compatible with the changes.
   Key: 94665a499e2eeee35eca3e7093a7abe183384b16
   ----------------------------------------
   Risk Factor: low
   Title: SElinux will be set to permissive mode
   Summary: SElinux will be set to permissive mode. Current mode: enforcing. This action is required by the upgrade process to make sure the upgraded system can boot without beinig blocked by SElinux rules.
   Remediation: [hint] Make sure there are no SElinux related warnings after the upgrade and enable SElinux manually afterwards. Notice: You can ignore the "/root/tmp_leapp_py3" SElinux warnings.
   Key: 39d7183dafba798aa4bbb1e70b0ef2bbe5b1772f
   ----------------------------------------
   Risk Factor: low
   Title: Brltty has incompatible changes in the next major version
   Summary: The --message-delay brltty option has been renamed to --message-timeout.
   The -U [--update-interval=] brltty option has been removed.
   Remediation: [hint] Please update your scripts to be compatible with the changes.
   Key: 6bdee7a18a7b2ef8926cda49eba5bab74726b412
   ----------------------------------------
   Risk Factor: low
   Title: Dosfstools incompatible changes in the next major version
   Summary: The automatic alignment of data clusters that was added in 3.0.8 and broken for FAT32 starting with 3.0.20 has been reinstated. If you need to create file systems for finicky devices that have broken FAT implementations use the option -a to disable alignment.
   The fsck.fat now defaults to interactive repair mode which previously had to be selected with the -r option.
   
   Remediation: [hint] Please update your scripts to be compatible with the changes.
   Key: c75fe5e06c70d9e764703fa2611f917c75946226
   ----------------------------------------
   Risk Factor: low
   Title: Postfix has incompatible changes in the next major version
   Summary: Postfix 3.x has so called "compatibility safety net" that runs Postfix programs with backwards-compatible default settings. It will log a warning whenever backwards-compatible default setting may be required for continuity of service. Based on this logging the system administrator can decide if any backwards-compatible settings need to be made permanent in main.cf or master.cf, before turning off the backwards-compatibility safety net.
   The backward compatibility safety net is by default turned off in Red Hat Enterprise Linux 8.
   It can be turned on by running:  "postconf -e compatibility_level=0
   It can be turned off by running: "postconf -e compatibility_level=2
   
   In the Postfix MySQL database client, the default "option_group" value has changed to "client", i.e. it now reads options from the [client] group from the MySQL configuration file. To disable it, set "option_group" to the empty string.
   
   The postqueue command no longer forces all message arrival times to be reported in UTC. To get the old behavior, set TZ=UTC in main.cf:import_environment.
   
   Postfix 3.2 enables elliptic curve negotiation. This changes the default smtpd_tls_eecdh_grade setting to "auto", and introduces a new parameter "tls_eecdh_auto_curves" with the names of curves that may be negotiated.
   
   The "master.cf" chroot default value has changed from "y" (yes) to "n" (no). This applies to master.cf services where chroot field is not explicitly specified.
   
   The "append_dot_mydomain" default value has changed from "yes" to "no". You may need changing it to "yes" if senders cannot use complete domain names in e-mail addresses.
   
   The "relay_domains" default value has changed from "$mydestination" to the empty value. This could result in unexpected "Relay access denied" errors or ETRN errors, because now will postfix by default relay only for the localhost.
   
   The "mynetworks_style" default value has changed from "subnet" to "host". This parameter is used to implement the "permit_mynetworks" feature. The change could result in unexpected "access denied" errors, because postfix will now by default trust only the local machine, not the remote SMTP clients on the same IP subnetwork.
   
   Postfix now supports dynamically loaded database plugins. Plugins are shipped in individual RPM sub-packages. Correct database plugins have to be installed, otherwise the specific database client will not work. For example for PostgreSQL map to work, the postfix-pgsql RPM package has to be installed.
   
   Key: 5721e0a07a67d82cf7e5ea6f17662cd4f82e0a33
   ----------------------------------------
   Risk Factor: low
   Title: The subscription-manager release is going to be kept as it is during the upgrade
   Summary: The upgrade is executed with the --no-rhsm option (or with the LEAPP_NO_RHSM environment variable). In this case, the subscription-manager will not be configured during the upgrade. If the system is subscribed and release is set already, you could encounter issues to get RHEL content using DNF/YUM after the upgrade.
   Remediation: [hint] Set the new release (or unset it) after the upgrade using subscription-manager: subscription-manager release --set 8.6
   Key: 01986584e27e85ea18929586faf614eee011a121
   ----------------------------------------
   Risk Factor: info
   Title: SElinux relabeling will be scheduled
   Summary: SElinux relabeling will be scheduled as the status is permissive/enforcing.
   Key: 8fb81863f8413bd617c2a55b69b8e10ff03d7c72
   ----------------------------------------
   Risk Factor: info
   Title: Current PAM and nsswitch.conf configuration will be kept.
   Summary: There is a new tool called authselect in RHEL8 that replaced authconfig. The upgrade process was unable to find an authselect profile that would be equivalent to your current configuration. Therefore your configuration will be left intact.
   Key: 40c4ab1da4a30dc1ca40e543f6385e1336d8810c
   ----------------------------------------
   

   Wymagane jest rozwiązanie problemów oznaczonych słowem (inhibitor). W moim przypadku był tylko jeden taki wpis, więc miałem mało rzeczy do poprawiania. Zastosowałem poniższe kroki (pierwsze polecenie jest zalecane przez twórców AlmaLinux, a drugie jest z mojego pliku logu):

   sudo rmmod pata_acpi

   sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

   Profilaktycznie wykonuję jeszcze jedno sprawdzenie.

   sudo leapp preupgrade

   

7. Uruchamiam migrację. Ten etap trwał u mnie ok. 11 minut.

   sudo leapp upgrade

   

8. Po pomyślnej aktualizacji restartuję system.

   reboot

   W GRUB`ie pojawi się nowa pozycja ELevate-Upgrade-Initramfs i system właśnie na niej zostanie uruchomiony.

   

   Proces migracji będzie kontynuowany. Podczas tego procesu system będzie się kilkukrotnie restartował. Ten etap trwał u mnie ok. 80 minut.

   

   Po ostatnim restarcie czekam na końcowe wykonanie zadań migracji.

   

9. Po zalogowaniu do systemu sprawdzam jego wersję - w moim przypadku AlmaLinux 8.9 (kernel 4.18).

   cat /etc/redhat-release ; cat /etc/os-release

   

Porządkowanie systemu AlmaLinux OS 8

Część poniższych kroków jest zalecana przez Red Hat`a, a reszta jest moja. 😋

1. Usuwam wszystkie wykluczone pakiety dodane przez narzędzie Leapp podczas migracji.

   sudo yum config-manager --save --setopt exclude=''

2. Czyszczę pamięć podręczną DNF ze wszystkich pobranych pakietów podczas migracji.

   sudo dnf clean packages

3. Usuwam wszystkie osierocone i stare pakiety CentOS 7.

   sudo rpm -qa | grep -E 'el7[.-]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | xargs rpm -e

4. Usuwam puste katalogi oraz katalogi narzędzia Leapp.

   sudo rm -r /lib/modules/*el7* /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp

5. Sprawdzam, czy mam jakieś stare kernele. W moim przypadku wszystkie stare jądra zostały usunięte podczas migracji.

   sudo rpm -qa kernel

   

6. Sprawdzam, czy zostały mi stare wpisy w bootloaderze. W moim przypadku trochę wpisów pozostało więc je wszystkie usuwam.

   grubby --info=ALL | grep "\.el7" || echo "Old kernels are not present in the bootloader."

   

   /bin/kernel-install remove 3.10.0-1160.105.1.el7.x86_64 /lib/modules/3.10.0-1160.105.1.el7.x86_64/vmlinuz

   /bin/kernel-install remove 3.10.0-1160.102.1.el7.x86_64 /lib/modules/3.10.0-1160.102.1.el7.x86_64/vmlinuz

   /bin/kernel-install remove 3.10.0-1160.99.1.el7.x86_64 /lib/modules/3.10.0-1160.99.1.el7.x86_64/vmlinuz

   /bin/kernel-install remove 3.10.0-1160.95.1.el7.x86_64 /lib/modules/3.10.0-1160.95.1.el7.x86_64/vmlinuz

   /bin/kernel-install remove 3.10.0-1160.92.1.el7.x86_64 /lib/modules/3.10.0-1160.92.1.el7.x86_64/vmlinuz

   Na koniec sprawdzam czy wszystko usunąłem.

   grubby --info=ALL | grep "\.el7" || echo "Old kernels are not present in the bootloader."

   

7. Usuwam stary kernel ratunkowy i początkowy dysk RAM, a następnie reinstaluje je na świeże wersje.

   sudo rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*

   /usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"

   Sprawdzam czy stare jądro ratunkowe i początkowy dysk RAM zostały podmienione na aktualny kernel.

   ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*

   lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"

8. Sprawdzam czy wpisy rozruchu ratunkowego odnoszą się do istniejących plików.

   grubby --info $(ls /boot/vmlinuz-*rescue*)

   

9. Na koniec aktualizuję konfigurację GRUB`a - usuwam przestarzały wpis  elevator=noop.

   sudo vi /etc/default/grub

   

   Zapisuję zmiany i aktualizuję konfigurację (w moim przypadku dla Legacy BIOS).

   grub2-mkconfig -o /boot/grub2/grub.cfg

   Dodatkowo usuwam powyższy parametr ze wszystkich wpisów bootloadera.

   grubby --update-kernel ALL --remove-args='elevator=noop'

10. Uruchamiam ponownie system w celu sprawdzenia czy wszystkie zmiany zostały poprawnie zapisane.

    reboot

Reanimacja Gitlab`a na systemie AlmaLinux OS 8

Wszystkie ustawienia jakie wprowadziłem podczas instalacji GitLab`a na CentOS 7 zostały przeniesione.

1. Usuwam stare repozytorium.

   rm /etc/yum.repos.d/gitlab_gitlab-ce.repo

2. Dodaję serwer pakietów GitLab.

   curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

3. Doinstalowuję brakujący pakiet, a następnie instaluję serwer GitLab.

   sudo dnf install -y perl ; sudo dnf install -y gitlab-ce

4. Uruchamiam serwer GitLab.

   sudo gitlab-ctl reconfigure