A high-reliability rpm upgrading method and device for a network interruption environment

Abstract

The application relates to the technical field of RPM package updating, and provides a high-reliability RPM upgrading method and equipment for a disconnected network environment, which comprises the following steps: before an upgrading operation is performed, the dependency relationship of an RPM package to be upgraded is analyzed, and the dependency relationship is checked; if the dependency relationship passes the check, a backup package is dynamically constructed for an old version RPM package to be upgraded in a current system, and installation state information of each software package is recorded; according to a predefined service dependency relationship, the RPM package to be upgraded is divided into multiple upgrading groups, and upgrading is sequentially performed in group order; when upgrading of any upgrading group fails, a differential rollback operation is performed on the upgraded software package according to the recorded installation state information. According to the high-reliability RPM upgrading method and equipment for the disconnected network environment, high-reliability RPM upgrading capability can be realized under the disconnected network environment.

Description

Technical Field

[0001] This invention relates to the field of RPM packet update technology, and in particular to a highly reliable RPM upgrade method and device for network outage environments. Background Technology

[0002] In Linux operating systems, RPM (Red Hat Package Manager) is the mainstream software package management mechanism. In enterprise-level distributed systems, operating system vulnerability fixes and feature updates are often implemented through batch upgrades of RPM packages. Therefore, the reliability of RPM upgrade operations is directly related to the continuous and stable operation of business systems.

[0003] Currently, the mainstream RPM upgrade solutions mainly include the following two categories:

[0004] The YUM / DNF online upgrade method relies on the internet or an intranet repository and can automatically resolve dependencies and complete the installation. However, this method is completely unavailable in environments without internet access, highly secure isolated environments, or scenarios where a local repository is not configured.

[0005] The offline `yum localinstall` method, which involves copying the RPM package to the target node for local installation, solves the network dependency problem, but has the following serious drawbacks:

[0006] First, there is a lack of a dependency pre-check mechanism. During offline upgrades, if the prepared RPM set is incomplete, the upgrade process will fail midway, resulting in the system being in a "semi-upgraded" state, where some packages have been upgraded and some have not, leading to a chaotic system state that is difficult to repair.

[0007] Secondly, there is a lack of precise rollback capabilities. Traditional solutions require preparing old version packages in advance for rollback, but in real-world environments, the RPM versions installed on each node are difficult to predict and cannot be prepared uniformly. Once the upgrade fails, the system often cannot reliably roll back to its precise state before the upgrade.

[0008] Third, it lacks service awareness. Traditional solutions upgrade all RPMs in a batch at once, without distinguishing between critical and non-critical components. If the upgrade of critical components (such as glibc and systemd) fails, it may cause the entire machine to become unusable, while other non-critical packages have already been updated, resulting in serious system instability.

[0009] Fourth, interruption recovery is difficult. After an interruption during a YUM upgrade, duplicate RPM packages (dupes) are often generated, making dependency cleanup complex and prone to causing secondary failures, further increasing the difficulty and risk of system maintenance.

[0010] Chinese patent CN111124465A discloses a method and system for remote upgrade of cross-network client / server applications. This solution addresses the problem of remote software upgrades in client / server architectures by proposing a sequential upgrade mechanism based on execution node status records. Essentially, it's a file-level overwrite upgrade for client / server applications, operating on specific files rather than operating system-level software packages. RPM upgrades involve complex operations such as package dependency resolution, version status recording, and database updates, fundamentally different from simple file overwrites. This solution does not address the core mechanisms of RPM package management and cannot be directly applied to batch upgrade scenarios at the operating system level.

[0011] Therefore, there is an urgent need for an RPM upgrade method that does not require network dependencies, supports precise rollback, groups services by topology, and has system status verification capabilities, in order to ensure the safe and stable operation of enterprise-level systems in network outage environments. Summary of the Invention

[0012] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a highly reliable RPM upgrade method and device for network outage environments.

[0013] According to a first aspect of the present invention, a highly reliable RPM upgrade method for network outage environments is provided, the method comprising:

[0014] Step S1: Before the upgrade operation is executed, the dependencies of the RPM package to be upgraded are resolved and the dependencies are checked;

[0015] Step S2: If the dependency check passes, dynamically build backup packages for the old version RPM packages to be upgraded in the current system, and record the installation status information of each package.

[0016] Step S3: Based on the predefined service dependencies, divide the RPM package to be upgraded into multiple upgrade groups and upgrade them sequentially according to the group order;

[0017] Step S4: When the upgrade of any upgrade group fails, perform a differentiated rollback operation on the upgraded software packages based on the recorded installation status information.

[0018] Optionally, in the high-reliability RPM upgrade method for network outage environments of the present invention, in step S1, the dependencies are checked in the following manner:

[0019] Parse the header information of all RPM packages to be upgraded, extract the package names and version requirements that each RPM package depends on, and build a dependency set;

[0020] Query the local RPM database to determine if any local dependencies corresponding to the dependency set are missing;

[0021] If no corresponding local dependency is missing, the dependency check is considered successful. If any local dependency is missing, a dependency missing report is generated and the upgrade process is terminated.

[0022] Optionally, in the high-reliability RPM upgrade method for network outage environments of the present invention, in step S2, a backup package is dynamically constructed in the following manner:

[0023] Check if the rpmrebuild tool is installed on the system. If not, install the rpmrebuild tool.

[0024] The rpmrebuild tool is used to parse the RPM packages to be upgraded one by one and reverse-engineer the old version RPM backup packages that can be used for rollback from the corresponding old version software currently running on the system.

[0025] Query and record the current installation status information of each software package to be upgraded to a status file. The installation status information includes at least the software name, a flag indicating whether it is currently installed, and the current exact version number.

[0026] Optionally, in the highly reliable RPM upgrade method for network outage environments of the present invention, in step S3, the upgrade group containing critical components is prioritized over the upgrade group containing non-critical components in the predefined service dependency relationships.

[0027] Optionally, in the high-reliability RPM upgrade method for network outage environments of the present invention, step S3 involves upgrading the RPM packets by topology grouping in the following manner:

[0028] After all RPM packages in the same upgrade group have been successfully upgraded, the upgrade of the next upgrade group can be performed.

[0029] If any RPM package in any upgrade group fails to upgrade, the entire upgrade process is terminated, and the upgrade group is marked as a failed group.

[0030] Optionally, in the high-reliability RPM upgrade method for network outage environments of the present invention, step S4 involves performing a differentiated rollback operation on the upgraded software package in the following manner:

[0031] Read the installation status information recorded when dynamically building backup packages, and obtain the original installation status and version number of each upgraded package before the upgrade;

[0032] Rollback operations are performed on each upgrade group in reverse order, following the reverse of the upgrade sequence.

[0033] Optionally, in the highly reliable RPM upgrade method for offline environments of the present invention, in step S4, when rolling back a software package, if the original state recorded in the installation status information is not installed, the operation of uninstalling the current new version package is performed; if the original state recorded in the installation status information is installed and an old version number is recorded, the operation of downgrading the current new version package to the old version number is performed.

[0034] Optionally, the high-reliability RPM upgrade method for network outage environments of the present invention further includes cleaning up duplicate RPM packets in the following manner: when retrying the upgrade after the upgrade process is interrupted, or before or after the rollback operation is executed, scanning and cleaning up duplicate RPM packets generated due to the process interruption.

[0035] Optionally, the high-reliability RPM upgrade method for network outage environments of the present invention cleans up duplicate RPM packets, specifically including:

[0036] If the upgrade process is interrupted and then restarted, identify and clean up duplicate packages in the system that have the same name as the new package to be upgraded and have a higher version number;

[0037] If in the rollback phase, identify and clean up duplicate packages in the system that have the same name as the old package to be rolled back but with a lower version number.

[0038] According to a second aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0039] The highly reliable RPM upgrade method and device for network outage environments of the present invention have the following beneficial technical effects:

[0040] I. Achieve fully localized upgrades even in offline environments, overcoming network dependency limitations.

[0041] The entire process requires no internet access, no local software repository configuration, and no downloading of any software packages from a remote server, completely solving the problem of RPM upgrades being infeasible in special scenarios such as offline environments, highly secure isolation environments, and confidential intranets.

[0042] II. Achieve dynamic backup and differentiated, precise rollback.

[0043] There's no need to know the software version differences of each node in advance, nor is there a need to prepare a unified set of old version packages beforehand, greatly reducing the complexity of operation and maintenance preparation. At the same time, it ensures that the system can be accurately restored to its original state before the upgrade, avoiding version inconsistencies caused by a simple and crude "downgrade."

[0044] Third, implement service topology-based group upgrades to ensure the stability of critical system components.

[0045] Ensure that critical components are upgraded first, and that the upgrade process is atomic, either all succeed or all are rolled back. This prevents the system from becoming unusable due to the failure of critical component upgrades, while other non-critical packages have been updated, thus significantly improving the upgrade process's ability to guarantee system stability.

[0046] Fourth, implement automatic cleanup of duplicate packages after interruption to enhance the robustness of the upgrade process.

[0047] It can automatically identify and forcibly remove redundant packages caused by process interruption, eliminate dependency conflicts and parsing anomalies caused by duplicate packages, avoid secondary failures, and significantly enhance the robustness and fault tolerance of the upgrade process.

[0048] Fifth, achieve full-process status traceability and consistency assurance to improve operational reliability.

[0049] The entire process is traceable, operations are reversible, and anomalies are manageable, enabling system administrators to clearly grasp the precise status of each upgrade and have a reliable recovery path in case of anomalies, greatly improving the reliability and maintainability of batch upgrade operations for enterprise-level systems. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a flowchart illustrating the steps of a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 1 of the present invention.

[0052] Figure 2 This is a schematic diagram of the execution flow of a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 1 of the present invention;

[0053] Figure 3 A flowchart illustrating the dependency checking process for a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 2 of the present invention;

[0054] Figure 4 A schematic diagram illustrating the backup process for a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 3 of the present invention;

[0055] Figure 5A schematic diagram illustrating the process of upgrading a highly reliable RPM upgrade method for a network outage environment according to an exemplary embodiment 4 of the present invention;

[0056] Figure 6 A schematic diagram illustrating the rollback process of a highly reliable RPM upgrade method for network outage environments according to Exemplary Example 5 of the present invention;

[0057] Figure 7 This is a schematic diagram illustrating the process of cleaning up duplicate RPM packets in a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 6 of the present invention.

[0058] Figure 8 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0059] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0060] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0061] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0062] Example 1

[0063] Exemplary embodiment 1 of the present invention provides a highly reliable RPM upgrade method for network outage environments. Figure 1 This is a flowchart illustrating the steps of a highly reliable RPM upgrade method for network outage environments according to Exemplary Embodiment 1 of the present invention. Figure 2 This is a schematic diagram illustrating the execution flow of a highly reliable RPM upgrade method for network outage environments according to an exemplary embodiment 1 of the present invention.

[0064] like Figure 1 and Figure 2 As shown, the method of this embodiment is implemented in the following manner:

[0065] Step S1: Before executing the upgrade operation, the dependencies of the RPM (Red Hat Package Manager) package to be upgraded are parsed and checked. In this embodiment, before the upgrade, it is checked whether the local machine meets the dependency requirements of this RPM upgrade. If not, an error is reported in advance and the upgrade process is exited, thereby improving the upgrade success rate.

[0066] Step S2: If the dependency check passes, dynamically build backup packages for the old version RPM packages to be upgraded in the current system, and record the installation status information of each package. In this embodiment, the old version packages are dynamically backed up for rollback operations after upgrade failure. If the backup fails, an error is reported and the upgrade process is exited.

[0067] Step S3: Based on predefined service dependencies, divide the RPM packages to be upgraded into multiple upgrade groups and upgrade them sequentially according to the group order. In this embodiment, all specified RPMs are upgraded; if successful, the upgrade process exits; otherwise, it waits for the user to specify subsequent operations.

[0068] Step S4: When any upgrade group fails, perform a differentiated rollback operation on the upgraded software packages based on the recorded installation status information. In this embodiment, if the user chooses to retry the upgrade, the upgrade is performed again; if the user chooses to rollback, the rollback is performed. During the re-upgrade, duplicate packages of the new version are cleaned up; during the rollback, duplicate packages of the old version are cleaned up.

[0069] Example 2

[0070] Exemplary embodiment 2 of the present invention provides a highly reliable RPM upgrade method for network outage environments.

[0071] In practical applications, the main reason for RPM upgrade failure is the lack of related dependencies. Therefore, RPM upgrade packages should include as many dependency packages as possible for the RPM to be upgraded. However, actual environments vary greatly, and some dependency packages may inevitably be missed. To improve the upgrade success rate and avoid the system being in a "partial upgrade" state, this embodiment's check task first parses all RPMs to be upgraded and obtains all their dependencies. Then, it queries the local dependencies and determines whether the check passes or fails based on whether any dependencies are still missing.

[0072] Figure 3 A flowchart illustrating the dependency checking process for a highly reliable RPM upgrade method for network outage environments according to Exemplary Embodiment 2 of the present invention is shown below. Figure 3 As shown, in this embodiment, dependencies are checked in the following manner:

[0073] Parse the header information of all RPM packages to be upgraded, extract the package names and version requirements of each RPM package, and build a dependency set; query the local RPM database to determine if any local dependencies corresponding to the dependency set are missing; if no corresponding local dependency is missing, the dependency check is considered passed; if any local dependency is missing, a dependency missing report is generated and the upgrade process is terminated.

[0074] Example 3

[0075] Exemplary embodiment 3 of the present invention provides a highly reliable RPM upgrade method for network outage environments. Figure 4 A schematic diagram illustrating the backup process for a highly reliable RPM upgrade method for network outage environments according to Exemplary Embodiment 3 of the present invention, as shown below. Figure 4 As shown, in this embodiment, the backup package is dynamically built in the following manner:

[0076] Check if the rpmrebuild tool is installed on the system. If not, install the rpmrebuild tool. Use the rpmrebuild tool to parse the RPM packages to be upgraded one by one and reverse-engineer the old version RPM backup packages that can be used for rollback from the corresponding old version software currently running on the system. Query and record the current installation status information of each package to be upgraded to a status file. The installation status information should include at least the software name, a flag indicating whether it is currently installed, and the current exact version number.

[0077] It should be noted that in practical applications, in order to roll back to the original version in case of upgrade failure, it is necessary to prepare the old version package in advance. However, in a real environment, it is impossible to predict the RPM versions installed on each node, so it is impossible to prepare a uniform old version package in advance. In the method of this embodiment, the backup task first ensures that rpmrebuild is installed, then parses all RPMs to be upgraded, and then uses rpmrebuild to dynamically rebuild the old version package for all RPMs. At the same time, the installation status of all RPMs is recorded in sys_rpms_install.info, with the format: <software name>|<installed status>|<version number-release number>. This information is used for precise rollback.

[0078] Example 4

[0079] Exemplary embodiment 4 of the present invention provides a highly reliable RPM upgrade method for network outage environments.

[0080] In practical applications, when all RPMs are upgraded in a batch at once, if critical components (such as glibc and systemd) fail to upgrade, the entire machine becomes unusable, while other non-critical packages have already been updated, leading to state chaos. In this embodiment, the upgrade task follows a predefined service topology. First, all RPMs to be upgraded are parsed to obtain group information. Upgrades are performed sequentially by group. The next group of RPMs is upgraded only after all RPMs in a group have been successfully upgraded. If any group of RPMs fails to upgrade, the upgrade task fails. Only when all RPM groups are successfully upgraded is the upgrade task considered successful.

[0081] Figure 5 This is a schematic diagram illustrating the upgrade process for a high-reliability RPM upgrade method for network outage environments according to Exemplary Embodiment 4 of the present invention. Figure 5 As shown in this embodiment, the RPM package to be upgraded is divided into multiple upgrade groups according to the predefined service dependency relationship, and the upgrades are performed sequentially according to the group order.

[0082] In this embodiment, in the predefined service dependencies, upgrade groups containing critical components are upgraded before upgrade groups containing non-critical components. When RPM packages are upgraded by topology grouping in the following manner, the upgrade of the next upgrade group is performed only after all RPM packages in the same upgrade group have been successfully upgraded; if any RPM package in any upgrade group fails to upgrade, the entire upgrade process is terminated, and that upgrade group is marked as a failed group.

[0083] Example 5

[0084] Exemplary embodiment 5 of the present invention provides a highly reliable RPM upgrade method for network outage environments. Figure 6 A schematic diagram illustrating the rollback process of the high-reliability RPM upgrade method for network outage environments according to Exemplary Embodiment 5 of the present invention is shown below. Figure 6 As shown, in this embodiment, a differentiated rollback operation is performed on the upgraded software package in the following manner:

[0085] Read the installation status information recorded when dynamically building backup packages, obtain the original installation status and version number of each upgraded package before the upgrade; and perform rollback operations on each upgrade group in reverse order of the upgrade order.

[0086] It should be noted that in the method of this embodiment, when rolling back a software package, if the original state recorded in the installation status information is not installed, the operation of uninstalling the current new version package is performed; if the original state recorded in the installation status information is installed and an old version number is recorded, the operation of downgrading the current new version package to the old version number is performed.

[0087] To improve upgrade reliability and avoid a "partial upgrade" state, the rollback task needs to be executed in reverse order of the upgrade task. In this embodiment, the rollback task is performed according to a predefined service topology, but in the exact opposite order to the upgrade task. That is, first, all RPMs to be upgraded are parsed to obtain group information. During rollback, the rollback is performed in reverse order of groups. The next group of RPMs is rolled back only after all RPMs in a group have been successfully rolled back. If any group of RPMs fails to roll back, the rollback task fails. Only when all RPM groups are successfully rolled back does the rollback task represent a successful rollback. At the same time, the rollback task needs to ensure that the system is restored to the version before the upgrade. Therefore, a simple "downgrade all" operation cannot be performed. Instead, a differentiated and precise rollback is required based on the three-state information (<software name>|<installed>|<version number-release number>) recorded in sys_rpms_install.info. That is, differentiated rollback strategies are supported for "uninstalling new packages" and "downgrading old packages".

[0088] Example 6

[0089] Exemplary Example 6 of the present invention provides a highly reliable RPM upgrade method for network outage environments.

[0090] In practical applications, duplicate RPM packages are often generated after an interruption during the upgrade or rollback process. If these packages are not cleaned up, they can easily cause secondary failures. To enhance the robustness of upgrades or rollbacks, this embodiment obtains specific duplicate packages based on the scenario and performs forced cleanup. Specifically, in upgrade scenarios, duplicate packages of the new version are cleaned up, and in rollback scenarios, duplicate packages of the old version are cleaned up.

[0091] Figure 7 This is a schematic diagram illustrating the process of cleaning up duplicate RPM packets in a high-reliability RPM upgrade method for offline environments according to Exemplary Embodiment 6 of the present invention. Figure 7 As shown, in this embodiment, duplicate RPM packages are cleaned up in the following manner: when retrying the upgrade after the upgrade process is interrupted, or before or after the rollback operation is executed, duplicate RPM packages generated due to the process interruption are scanned and cleaned up.

[0092] If the upgrade process is interrupted and then restarted, identify and clean up duplicate packages in the system that have the same name as the new package to be upgraded and have a higher version number;

[0093] If in the rollback phase, identify and clean up duplicate packages in the system that have the same name as the old package to be rolled back but with a lower version number.

[0094] The high-reliability RPM upgrade method for network outage environments according to embodiments of the present invention has the following beneficial technical effects:

[0095] I. Achieve fully localized upgrades even in offline environments, overcoming network dependency limitations.

[0096] By designing a process involving local dependency checks, local backup and build, local upgrade execution, and local rollback, all upgrade-related operations are completed based on the local resources of the target node. The entire process requires no internet access, no local software repository configuration, and no downloading of any software packages from a remote server. This completely solves the problem of RPM upgrades being infeasible in special scenarios such as offline environments, highly secure isolation environments, and confidential intranets, providing a feasible and reliable technical means for system maintenance in special environments.

[0097] II. Achieve dynamic backup and differentiated, precise rollback.

[0098] By introducing the rpmrebuild tool, corresponding RPM backup packages are dynamically built for the older versions of software currently running on the system before the upgrade. This eliminates the need for prior knowledge of software version differences across nodes and for preparing a unified set of older packages, significantly reducing the complexity of maintenance preparation. Simultaneously, by collecting and recording the precise installation status information of each software package before the upgrade (including software name, installation status, version number-release number), two different scenarios can be distinguished during rollback: performing a "downgrade old package" operation for software already installed before the upgrade, and performing a "uninstall new package" operation for software not installed before the upgrade. This ensures the system can be accurately restored to its original state before the upgrade, avoiding version inconsistencies caused by a simplistic "downgrade all" approach.

[0099] Third, implement service topology-based group upgrades to ensure the stability of critical system components.

[0100] Based on the importance of system components and their service dependencies, the RPM packages to be upgraded are divided into upgrade groups with a specific order, and upgrades are performed in that order: all RPM packages in the same group must be successfully upgraded before moving on to the next group; if any group fails, the upgrade is immediately terminated and a rollback is triggered. This ensures that critical components (such as core system libraries and services like glibc and systemd) are upgraded first, and that their upgrade process is atomic—either all upgrades succeed or all upgrades are rolled back. This prevents the system from becoming unusable due to the failure of critical component upgrades, while other non-critical packages have already been updated, resulting in a chaotic situation and significantly improving the upgrade process's ability to guarantee system stability.

[0101] Fourth, implement automatic cleanup of duplicate packages after interruption to enhance the robustness of the upgrade process.

[0102] To address the issue of duplicate RPM packages being generated after interruptions during upgrades or rollbacks, a scenario-aware automatic duplicate package cleanup mechanism is designed: in upgrade retry scenarios, duplicate packages of the new version are cleaned up, and in rollback scenarios, duplicate packages of the old version are cleaned up. This mechanism can automatically identify and forcibly remove redundant packages generated due to process interruptions, eliminate dependency conflicts and parsing anomalies caused by duplicate packages, avoid secondary failures, and significantly enhance the robustness and fault tolerance of the upgrade process.

[0103] Fifth, achieve full-process status traceability and consistency assurance to improve operational reliability.

[0104] By recording the installation status before the upgrade, performing grouped atomic commits during the upgrade process, implementing differentiated and precise operations during rollback, and cleaning up duplicate packages after interruption, a complete upgrade lifecycle management system is constructed. The entire process is traceable, operations are reversible, and anomalies are handleable, enabling system administrators to clearly grasp the precise status of each upgrade and have a reliable recovery path in case of anomalies, significantly improving the reliability and maintainability of batch upgrade operations for enterprise-level systems.

[0105] like Figure 8 As shown, the present invention also provides a device including a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 implements the aforementioned high-reliability RPM upgrade method for offline environments by running the executable computer program.

[0106] The computer program in memory 330, when implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0107] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0109] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A highly reliable RPM upgrade method for network outage environments, characterized in that, The method includes: Step S1: Before the upgrade operation is executed, the dependencies of the RPM package to be upgraded are resolved and the dependencies are checked; Step S2: If the dependency check passes, dynamically build backup packages for the old version RPM packages to be upgraded in the current system, and record the installation status information of each package. Step S3: Based on the predefined service dependencies, divide the RPM package to be upgraded into multiple upgrade groups and upgrade them sequentially according to the group order; Step S4: When the upgrade of any upgrade group fails, perform a differentiated rollback operation on the upgraded software packages based on the recorded installation status information.

2. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, In step S1, the dependencies are checked as follows: Parse the header information of all RPM packages to be upgraded, extract the package names and version requirements that each RPM package depends on, and build a dependency set; Query the local RPM database to determine if any local dependencies corresponding to the dependency set are missing; If no corresponding local dependency is missing, the dependency check is considered successful. If any local dependency is missing, a dependency missing report is generated and the upgrade process is terminated.

3. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, In step S2, the backup package is dynamically built as follows: Check if the rpmrebuild tool is installed on the system. If not, install the rpmrebuild tool. The rpmrebuild tool is used to parse the RPM packages to be upgraded one by one and reverse-engineer the old version RPM backup packages that can be used for rollback from the corresponding old version software currently running on the system. Query and record the current installation status information of each software package to be upgraded to a status file. The installation status information includes at least the software name, a flag indicating whether it is currently installed, and the current exact version number.

4. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, In step S3, among the predefined service dependencies, the upgrade group containing critical components is upgraded before the upgrade group containing non-critical components.

5. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, In step S3, the RPM package is upgraded by topology grouping as follows: After all RPM packages in the same upgrade group have been successfully upgraded, the upgrade of the next upgrade group can be performed. If any RPM package in any upgrade group fails to upgrade, the entire upgrade process is terminated, and the upgrade group is marked as a failed group.

6. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, In step S4, a differentiated rollback operation is performed on the upgraded software package as follows: Read the installation status information recorded when dynamically building backup packages, and obtain the original installation status and version number of each upgraded package before the upgrade; Rollback operations are performed on each upgrade group in reverse order, following the reverse of the upgrade sequence.

7. The highly reliable RPM upgrade method for network outage environments according to claim 6, characterized in that, In step S4, when rolling back a software package, if the original state recorded in the installation status information is not installed, the operation of uninstalling the current new version package is performed; if the original state recorded in the installation status information is installed and an old version number is recorded, the operation of downgrading the current new version package to the old version number is performed.

8. The highly reliable RPM upgrade method for network outage environments according to claim 1, characterized in that, The method also includes cleaning up duplicate RPM packages in the following manner: when retrying the upgrade after the upgrade process is interrupted, or before or after a rollback operation is performed, scanning and cleaning up duplicate RPM packages generated due to the process interruption.

9. The highly reliable RPM upgrade method for network outage environments according to claim 8, characterized in that, Cleaning up duplicate RPM packages includes: If the upgrade process is interrupted and then restarted, identify and clean up duplicate packages in the system that have the same name as the new package to be upgraded and have a higher version number; If in the rollback phase, identify and clean up duplicate packages in the system that have the same name as the old package to be rolled back but with a lower version number.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-9.

Images