How to Abandon CentOS7 Flat (Excellent) Smooth (Elegant)

Leave a Comment / 28/08/2022 /

Original link: https://zdyxry.github.io/2022/08/28/%E5%A6%82%E4%BD%95%E5%8E%9F%E5%9C%B0%E5%8D%87% E7%BA%A7CentOS7/

background

CentOS 7 itself has a life cycle until June 30, 2024. At the end of 2020, the CentOS community announced to modify the existing release model, changing CentOS from being the downstream of RHEL to CentOS Stream, that is, the upstream of RHEL, which led to the short life cycle of CentOS8, which made the community dissatisfied with CentOS. of developers/users are dissatisfied, resulting in abandoning CentOS and switching to other distributions.

Everyone chooses to use CentOS. Although they are talking about stability, I understand that what is more important is the endorsement of RedHat. CentOS is the downstream of RHEL. All software versions have been tested and verified by RedHat, and there is also RedHat in the later maintenance. , do not worry about maintenance issues.

The original mode of CentOS is also problematic, and it is difficult for users to participate in the RHEL development cycle. The user found a problem with a certain version of CentOS, and wanted to contribute to CentOS so that the next version of CentOS could fix the problem. At this time, there is only one way, that is to contribute to the open source components themselves, but this is only the possibility of repair. Whether it is possible to repair in the end depends on the decision of the RedHat developers (after all, there are a large number of open source components in RHEL/CentOS that are not included, but RHEL/CentOS does not include it. Patch included by CentOS by way of Patching in rpm spec). After the introduction of CentOS Stream, users can contribute to the CentOS community to ensure that the next version of CentOS includes the Patch. As for whether RHEL includes it, users do not care, that is what RedHat cares about.

Fedora pays more attention to the latest code in the upstream community, including the most abundant functions, as a pioneer; CentOS Stream, as the upstream of RHEL, provides a stable and reliable continuous delivery version to ensure that more contributors can participate; RHEL is used by enterprise users , there is RedHat to provide a complete maintenance service.

Under the existing mode, CentOS Stream has deviates from the original intention of the original users who adopted CentOS. Existing CentOS7 users need to find new alternatives. Under the wave of localization, the direction of choice has also changed.

community alternative

Rocky Linux

Rocky Linux aims to function as a build downstream as CentOS had done previously, building releases after they have been added to the upstream vendor, not before.

AlmaLinux

AlmaLinux OS is replacing CentOS as the downstream rebuild of RedHat Enterprise Linux.

After CentOS announced the change of strategy, two alternatives appeared in the community, namely Rocky Linux and AlmaLinux, both of which have the same purpose. They are built and released as the downstream of RHEL, and the release mode and release cycle adopt the original CentOS. model.

Through the comparison of the official distributions provided by AlmaLinux), it can be seen that there is no difference between AlmaLinux and Rocky Linux for users. If it must be true, most of AlmaLinux personnel are from CloudLinux company, while Rocky Linux is Greg company.

Domestic alternatives

Anolis OS (Alibaba)

Anolis OS 8 is a completely open source, neutral, and open distribution launched by the OpenAnolis community. It supports multi-computing architectures, is also optimized for cloud scenarios, and is compatible with the CentOS software ecosystem. Anolis OS 8 aims to provide stable, high-performance, secure, reliable, and open-source operating system services for developers and operators.

openEuler (Huawei)

openEuler is an open source operating system. The current openEuler kernel is derived from Linux, supports Kunpeng and other processors, and can fully release the potential of computing chips. It is an efficient, stable and secure open source operating system built by global open source contributors, suitable for databases, big data, cloud Computing, artificial intelligence and other application scenarios. At the same time, openEuler is a global operating system open source community. Through community cooperation, it creates an innovative platform, builds a unified and open operating system that supports multi-processor architecture, and promotes the prosperity and development of software and hardware application ecology.

Galaxy Kylin Operating System

Galaxy Kylin Advanced Server Operating System V10 is aimed at enterprise-level key businesses and adapts to the reliability, security, performance, scalability and real-time performance of host systems in the era of virtualization, cloud computing, big data, and industrial Internet. According to the CMMI 5 standard Developed a new generation of autonomous server operating systems that provide endogenous intrinsic safety, cloud native support, in-depth optimization of independent platforms, high performance, and easy management

Under the wave of localization, if the product needs to meet the Xinchuang standard, then the choice of the operating system needs to consider domestic alternatives. At present (personally understand) the operating system that meets the Xinchuang standard is only Galaxy Kirin, openEuler and Anolis OS are not yet fully passed. Xinchuang Review. In this series of alternatives, the release mode and version control method adopted by Rocky Linux, AlmaLinux, and Anolis OS all maintain the original CentOS mode, that is, the 8.1, 8.2, and 8.3 release methods. Although openEuler and Galaxy Kylin operating systems also use RPM as the package manager and most of the component versions are the same as the CentOS 8 in the community, they are not completely equivalent, so we need to pay attention here.

Compare options

If you want to meet the requirements of Xinchuang, you can only choose Galaxy Kylin as a substitute; from the perspective of use, choosing Rocky Linux/AlmaLinux/Anolis OS is a better choice, with good community support, and version control is also consistent with CentOS , the mental burden is lower; if considering domestic hardware support, openEuler is a good choice.

For the distributions discussed above, the current package manager used is RPM, and all software has been installed as granular RPM. On top of RPM, there will be Yum/DNF including RPM dependency management, conflict management, upgrade and upgrade and other functions. RPM based package manager. Among them, the RPM-based package manager used by the CentOS 7 series is Yum, and the RPM-based package manager used by the current maintenance versions of other distributions is DNF (Dandified Yum).

upgrade conversion

In an existing CentOS 7 environment, a replacement is required to convert the CentOS 7 upgrade to the target distribution.

If the application environment is a monolithic application and can have offline maintenance time, it is a safe choice to perform a data backup and then completely reinstall the OS. If the application environment is a cluster, and most of the applications have been containerized, then reinstalling the OS on a single node requires careful testing and verification. The default system parameters of different distribution versions may be different, even if the upper-layer basic platform ensures that the versions are consistent (For example, the versions of Kubernetes, containerd, and runc are the same), which may also cause abnormal situations.

If you choose not to reinstall the OS, there are two ways to upgrade and convert in place: automatic and manual. Among them, Rocky Linux/AlmaLinux/Anolis OS provides automatic upgrade and conversion methods, and openEuler and Galaxy Kylin can use manual conversion methods.

automatic process

Automatic upgrade and conversion depends on Leapp ), Leapp is an open source tool developed by Redhat employees. Leapp itself is just a workflow framework, which includes concepts such as Actor, Model, Message, Workflow, etc. The specific component relationship diagram is as follows, in which workflow contains multiple phases, Each phase contains 3 stages: Before, Main, After, and each stage contains multiple Actors. There is no strict order between Actors, but they communicate by Message. Message follows the definition of Model. If ActorA relies on ActorB to generate MessageB, then ActorA will be executed after ActorB, ActorC without MessageB dependencies will be executed in the loading order, and there is no strict order dependency.

At present, the main usage scenarios of Leapp are for the upgrade of RedHat series distributions and the upgrade and switching between different distributions.

In the complete upgrade process, the unified definition of Workflow is used, and the same Workflow is called in different stages (such as pre-upgrade, upgrade, and Firstboot).

  • Pre-upgrade (preupgrade), collects and checks environmental information, and provides the check results to users in the form of reports. The number of information collection and check items carried out here is very large, including many details, except for the checks of some basic components: In addition to CPU architecture, openssh configuration changes, PAM module changes, Driver support, NTP changes, etc., it also includes checks for some third-party applications: SAP HANA, Memcached, Pagoda, etc.
  • Upgrade (upgrade), the main action of upgrade, uses the same Workflow as pre-check.
    • configuration_phase
    • FactsCollection
    • Checks
    • TargetTransactionFactsCollection, generate a temporary minimal environment, including the complete target version of the runtime environment, used to use the target version of the tool stack, such as DNF, RPM advanced features, etc., this environment will also be used to generate the initramfs image required for the next step
    • TargetTransactionCheck, through the minimal environment generated above, use the dnf tool, dnf rhel-upgrade check to check whether the current node can be upgraded
    • Reports
    • Download, the steps to download the packages required for the upgrade, dnf rhel-upgrade download
    • InterimPreparation, generate the initramfs required for the next step, install the dracut related toolkit in the minimal environment in the previous steps, use dracut to generate the initramfs image, adjust the system startup item after the generation is completed, and set it as the first startup item
  • Interim Upgrade, which actually performs the steps of the RPM upgrade, uses the same Workflow as the pre-check
    • After the system reboots, the system boots to the initramfs generated in the previous step, the system boots normally, and two hooks are added to the dracut hook, namely 85sys-upgrade-redhat and 90sys-upgrade , of which 85 is the actual execution node software package The upgrade action (leapp upgrade –resume), 90 Configure the systemd upgrade unit (relevant to restart)
    • InitRamStart, remove startup item settings
    • LateTests
    • Preparation
    • RPMUpgrade, dnf rhel-upgrade upgrade upgrade RPM
    • Applications
    • ThirdPartyApplications
    • Finalization
  • After the upgrade action (Firstboot), the system upgrade will be completed, and it will automatically reboot into the target version system. At this time, the Firstboot phase will be executed. After the execution is completed, the system upgrade will be completed.
    • FirstBoot, perform cleanup actions, modify partial configuration (NM), etc.

A total of 4 workflows are executed in the complete upgrade process. The purpose of using the temporary environment to perform the upgrade action is: the upgrade action execution tool chain is the tool chain of the corresponding version of the target environment.

automatic implementation

Project address list:

Among them, leapp is the framework itself, leapp-repository is the application implementation of Leapp, that is, the Actor implementation executed in the upgrade, and leapp-data is the basic configuration information used in the upgrade. Different distributions maintain their own leapp-repository. For example, Anolis OS maintains its own Git repository (on Gitee) and adds its own check items. In Leapp’s architecture, because the final application will be installed in an independent socket, Python’s syspath may change, and the path address needs to be modified accordingly when viewing the code. Take NTP checking as an example:

Actor implementation of NTP inspection:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 twenty one
 twenty two
 twenty three
 twenty four
 
 from leapp.actors import Actor
 from leapp.libraries.actor.checkntp import check_ntp
 from leapp.models import InstalledRedHatSignedRPM, NtpMigrationDecision, Report
 from leapp.tags import ChecksPhaseTag, IPUWorkflowTag

 class CheckNtp(Actor):
 "" "
 Check if ntp and/or ntpdate configuration needs to be migrated.
 " ""

 name = 'check_ntp'
 consumes = (InstalledRedHatSignedRPM,)
 produces = (Report, NtpMigrationDecision)
 tags = (ChecksPhaseTag, IPUWorkflowTag)

 def process(self):
 installed_packages = set()

 signed_rpms = self.consume(InstalledRedHatSignedRPM)
 for rpm_pkgs in signed_rpms:
 for pkg in rpm_pkgs.items:
 installed_packages.add(pkg.name)

 self.produce(check_ntp(installed_packages))

The implementation of the check_ntp function called in the Actor:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 twenty one
 twenty two
 twenty three
 twenty four
 25
 26
 27
 28
 29
 30
 31
 32
 
 # Check services from the ntp packages for migration
 def check_ntp(installed_packages):
 service_data = [( 'ntpd' , 'ntp' , '/etc/ntp.conf' ),
 ( 'ntpdate' , 'ntpdate' , '/etc/ntp/step-tickers' ),
 ( 'ntp-wait' , 'ntp-perl' , None)]

 migrate_services = []
 migrate_configs = []
 for service, package , main_config in service_data:
 if package in installed_packages and \
 check_service( '{}.service' .format(service)) and \
 (not main_config or is_file(main_config)):
 migrate_services.append (service)
 if main_config:
 migrate_configs.append (service)

 if migrate_configs:
 reporting.create_report([
 reporting.Title( '{} configuration will be migrated' .format( ' and ' .join(migrate_configs))),
 reporting.Summary( '{} service(s) detected to be enabled and active' .format( ', ' .join(migrate_services))),
 reporting.Severity(reporting.Severity.LOW),
 reporting.Groups([reporting.Groups.SERVICES, reporting.Groups.TIME_MANAGEMENT]),
 ] + related)

 # Save configuration files that will be renamed in the upgrade
 config_tgz64 = get_tgz64(files)
 else :
 api.current_logger().info( 'ntpd/ntpdate configuration will not be migrated' )
 migrate_services = []
 config_tgz64 = ''

 return NtpMigrationDecision(migrate_services=migrate_services, config_tgz64=config_tgz64)

Manual process

For a Linux distribution, the whole is composed of countless RPMs. The smallest granularity seen in the final system is RPM. We can upgrade the overall distribution through RPM upgrades. But for some RPMs, the dependencies between RPMs prevent us from completing a complete upgrade and replacement by upgrading some RPMs in turn. Some of the key components, such as glibc, glib2, openssl, etc., are strongly dependent. We There had to be a way to complete the overall upgrade. In Yum, there is a distribution-synchronization command to synchronize all RPMs in the current OS to the version in the target Repository, but with Yum there may be situations where rpmlib cannot be recognized. As a basic package manager, RPM will provide some advanced features in the form of rpmlib dependencies. If the current system package manager cannot recognize rpmlib, there will be unresolved dependency conflicts during the synchronization process.

Example: The target RPM is dnf-4.2.23-6.oe1.noarch.rpm, and the upgrade prompts a conflict of dependency rpmlib(RichDependencies) <= 4.12.0-1. This is because the rpm environment (possibly openEuler 20.03 or higher) used by the dnf-4.2.23 RPM during the build phase is higher than the current OS RPM version (CentOS 7), so the current rpm cannot satisfy this dependency condition.

We can use DNF’s distro-sync and some RPM modifications to complete the manual upgrade conversion. The process is as follows:

  • Upgrade the current CentOS7 to the latest version of the CentOS 7.x series;
  • Stop all applications running on the node
  • Configure CentOS7 Repository, install DNF (DNF depends on the execution version of glib2, but it is not declared in the spec, you need to upgrade glib2 separately)
  • Remove Yum manager to prevent conflict with DNF
  • Configure Target Release Repository
  • Upgrading conversion with dnf distro-sync
  • Use dnf remove to remove useless RPMs
  • Restart the host to take effect

Manual implementation

The current CentOS7 package manager is Yum, and the package manager in the target version is DNF. After installing DNF through Yum, on the premise that the Yum(DNF) Repository configuration is the target version, use the dnf distro-sync command to upgrade the RPM and sync, this command will match the RPMs installed by the current OS with the RPMs in the Yum Repository. RPM version matching exists in the following situations:

  • If the current RPM version is lower than the RPM version contained in the target Repository, it will be upgraded;
  • If the current RPM version is higher than the RPM version contained in the target Repository, it will be downgraded;
  • If the current RPM is replaced by the RPM contained in the target Repository (specify Obsolete), the new RPM will be installed and the original RPM will be uninstalled (replaced);
  • If the current RPM version is the same as the RPM version contained in the target Repository, but other RPM metadata such as dist is different, it will be reinstalled;
  • The current RPM is imported by other RPM dependencies, but other RPMs have been replaced, then the RPM will be uninstalled;
  • If the current RPM is not contained in the target Repository, it will not be processed;

Summarize

We can upgrade CentOS 7 to our desired target distribution in place, either automatically or manually. The community’s Rocky Linux/AlmaLinux/Anolis OS can be done automatically, and the domestic non-equivalent alternative openEuler can be done manually by controlling the Repository, reducing the workload caused by the change of the distribution.

Reference link

This article is reprinted from: https://zdyxry.github.io/2022/08/28/%E5%A6%82%E4%BD%95%E5%8E%9F%E5%9C%B0%E5%8D%87% E7%BA%A7CentOS7/
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment