CN107943502B - Upgrading method based on fine-grained system state detection in Linux system - Google Patents
Upgrading method based on fine-grained system state detection in Linux system Download PDFInfo
- Publication number
- CN107943502B CN107943502B CN201711247522.1A CN201711247522A CN107943502B CN 107943502 B CN107943502 B CN 107943502B CN 201711247522 A CN201711247522 A CN 201711247522A CN 107943502 B CN107943502 B CN 107943502B
- Authority
- CN
- China
- Prior art keywords
- version
- upgrade
- package
- upgrading
- fine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
An upgrading method based on fine-grained system state detection in a Linux system comprises the following steps: s1: generating an upgrade check file with the complete state of the current system; s2: calculating an upgradable version according to the upgrade check file; s3: selecting a target version needing to be upgraded from the upgradable versions; s4: calculating an upgrade list, and judging packet conflicts; s5: generating a static upgrade file; s6: and packaging the static upgrade file and an instruction execution program required to be used for upgrading to the target version into an upgrade package, and upgrading the version. The beneficial effect of this application is: based on fine-grained judgment of the system state, the generated upgrade check file is more reliable; eliminating conflicts and then finely generating an upgrade package to ensure that operating systems in various states can be safely and uniformly upgraded to target versions; the operating systems of different projects and application scenes can be automatically distinguished, each project has a version state and an upgrading route, and can be upgraded to any available version state in the route.
Description
Technical Field
The application belongs to the technical field of Linux system upgrading, and particularly relates to an upgrading method based on fine-grained system state detection in a Linux system.
Background
With the continuous update of the terminal equipment and the continuous improvement of the operating system, the terminal equipment needs to be upgraded at intervals. The current mainstream operating system upgrading method comprises the following steps: and the latest upgrade package is placed in the upgrade server, if the terminal equipment detects a new system version, the terminal equipment prompts a user to upgrade, and after the user confirms the upgrade package, the latest upgrade package is downloaded from the upgrade server to be upgraded.
This conventional upgrade method has the following disadvantages:
(1) unlike Windows, which processes the key components of the system and the user software separately, the key components of the Linux system and the common software exist in the same form, i.e. a software package. Because of the complex dependency relationship between the software packages, the user may directly or indirectly influence the key components of the system when installing, uninstalling and upgrading the software packages. At this point, installing a fixed system upgrade package may not work for the system, or even cause system confusion. This is also the reason why the upgrading Linux system often presents an abnormal problem;
(2) in practical application, in the face of different clients and use environments, different types, branches, versions and even system structures can be derived from an operating system, in the face of the four conditions, required upgrade packages are different, and huge workload can be generated when the upgrade packages are manually made, and the upgrade terminals and the upgrade servers are manually matched;
(3) the conventional method can only upgrade the operating system to the fixed latest version uniformly, and cannot select to upgrade to an intermediate state.
The invention relates to a Linux operating system and a security upgrading method thereof (application number CN 102662647A). The invention judges the security level of a computer to be upgraded and upgrades the computer by a movable storage medium, thereby overcoming the technical problem that the operating system cannot be upgraded under the condition of network disconnection or computer security requirement and achieving the purpose of safely upgrading the operating system. The differences from the patent are as follows: the patent is an upgrading method based on fine-grained system state detection in the Linux system, and the patent directions are different.
The invention relates to a system upgrading method and a device thereof (application number CN105242945A), which inquires the upgrading criteria stored in a user terminal in the upgrading process, compares the upgrading criteria of a server, and upgrades the user system if the upgrading criteria are met. The differences from the invention are: the invention can detect the system state, the software package state and the configuration file state and judge the software package conflict, and can automatically distinguish the operating systems of different projects and application scenes, each project has own version state and upgrading route, and can be selectively upgraded to any available version state in the route.
The invention discloses a system upgrading method and a system upgrading device of an intelligent terminal (application number CN105045671A), which are invented by China and used for acquiring a storage capacity value of a connected intelligent terminal; matching the acquired storage capacity value with a storage capacity value of an intelligent terminal suitable for the system upgrade package; and if the matching is successful, sending the system upgrading packet to the connected intelligent terminal for upgrading. The differences from the invention are: the invention can detect the system state, the software package state and the configuration file state and judge the software package conflict, and can automatically distinguish the operating systems of different projects and application scenes, each project has own version state and upgrading route, and can be selectively upgraded to any available version state in the route.
The invention relates to a method for upgrading a UNIX environment software system (application number CN105117263A), which is characterized in that a directory structure is pre-established for an upgrade package, a rule mapping table is established according to configuration difference between every two upgrade packages in all application servers, then the rule mapping table is pre-stored in all the application servers, the upgrade package which is successfully installed is applied to other application servers by integrating the rule mapping table, and the installation and deployment of the self-adaptive upgrade package of all the application servers are completed. The differences from the invention are: the invention relates to an upgrading method based on fine-grained system state detection in a Linux system, which has different patent directions.
The invention relates to a method, a device and a server for upgrading a terminal system (application number CN104778057A), which are invented by China and used for receiving a version upgrading request sent by a terminal; determining a version to be upgraded of the terminal according to the current system version and the user identification; detecting whether a difference packet between the version to be upgraded and the current system version is stored; if the differential packet is not stored, performing differential processing on the large packet of the version to be upgraded and the large packet of the current system version to obtain a differential packet; and sending the differential packet to a terminal, wherein the terminal is used for carrying out system upgrading according to the differential packet. The differences from the invention are: the invention can detect the system state, the software package state and the configuration file state and judge the software package conflict, and can automatically distinguish the operating systems of different projects and application scenes, each project has own version state and upgrading route, and can be selectively upgraded to any available version state in the route.
The invention discloses a terminal updating system and a terminal updating method thereof (application number CN104572212A, the invention mainly compares an updating configuration file 1 with a local updating configuration file 0 and a local temporary updating configuration file L to determine a file list needing to be downloaded, and then downloads the file needing to be updated according to the file list.
Disclosure of Invention
In view of this, in order to solve the defects and shortcomings in the prior art, the present application provides an upgrade method based on fine-grained system state detection in a Linux system, so as to solve the problem of version confusion possibly generated by upgrading a traditional operating system.
In order to solve the technical problem, the application discloses an upgrading method based on fine-grained system state detection in a Linux system, and the upgrading method is realized by adopting the following technical scheme.
An upgrading method based on fine-grained system state detection in a Linux system comprises the following steps: s1: generating an upgrade check file with a current system state, wherein the upgrade check file is generated by performing fine-grained detection on the system state based on a client; the system state comprises user system authentication information, ex-warehouse serial numbers, system version numbers, system architectures and software package lists;
s2: calculating an upgradable version according to the upgrade check file;
s3: selecting a target version needing to be upgraded from the upgradable versions;
s4: calculating an upgrade list, and judging packet conflicts;
s5: generating a static upgrade file;
s6: and packaging the static upgrade file and an instruction execution program required to be used for upgrading to the target version into an upgrade package, and upgrading the version.
Further, the upgrade check file is generated by performing fine-grained detection on a system state based on a client, where the fine-grained detection includes:
a) user system authentication information: if not authorized or activated, stopping the upgrading program;
b) the ex-warehouse serial number: if the ex-warehouse serial number does not exist or the ex-warehouse serial number does not have a record in the database, stopping the upgrading program;
c) system version number: the system version information management system is used for positioning the item and/or the history node to which the user system version belongs;
d) and (3) system architecture: an upgradeable version for locating the user system version;
e) software package list: for performing a package list comparison after the target version is selected.
Further, the specific step of generating the upgrade check file includes:
s11: acquiring an un-generated check file;
s12: detecting whether the ex-warehouse serial number of the user system is empty, if not, inquiring the database to see whether the record is on the counter, otherwise, not upgrading;
s13: detecting the ex-warehouse version, if the ex-warehouse version is verified to be an abnormal ex-warehouse version, stopping generating the check file, and entering S11; otherwise, entering the next step;
s14: detecting whether the user authorization file is complete, if so, entering the next step, and if not, or the system does not carry out activation authentication, not upgrading;
s15: judging whether the system is authorized or activated, if not, stopping generating the check file, and entering S11; otherwise, entering the next step;
s16: acquiring a system version number, a system architecture and/or an installed package list;
s17: and integrating the acquired system version number, the system architecture and the installed package list into an upgrade check file.
Further, the step of determining packet collision includes: s41: and (3) judging packet conflict for the first time: performing package conflict judgment on the upgrade check file and the target version according to a package list and a package version to obtain an upgrade installation package list; s42: and (3) judging packet conflict for the second time: and performing package conflict judgment on the installation package list needing to be upgraded and the installed package list in the current system version.
Further, the step of determining packet collision further includes: s43: if the packet conflict judgment result indicates that a conflict packet exists, normal upgrading cannot be performed, and upgrading is selected to be abandoned or the conflict packet is automatically unloaded; if the conflict packet is unloaded, continuing to upgrade to the target version; if the upgrade continues, the package integrity of the target version will be maintained.
Further, judging whether compatibility conflict exists between the installed package and the packages listed in the upgrade installation package list; and judging whether the version of the dependency package or the library of the installed package conflicts with the version of the package or the library which is listed in the upgrade installation package list and depended on.
Further, the specific content of S2 is: inquiring a database according to the system version number and the architecture in the upgrade check file, positioning the digit corresponding to the system through the architecture information, positioning the item and/or the version series of the system through the system version number, and finally obtaining the node position in the version system according to the system version number to determine the upgradable version.
A system based on fine-grained state detection, comprising:
client (101): detecting information of a current operating system, wherein the information of the current operating system comprises user system authentication information, a ex-warehouse serial number, a system version number, a system architecture and a software package list, integrating and processing the detected information in format to generate an upgrade check file, and sending the upgrade check file to a processing center (102); receiving a scalable version sent by the processing center (102) for selection, sending the selected target version to the processing center (102), and receiving an upgrade package generated by the processing center (102) for installation and upgrade;
the processing center (102): receiving the upgrade check file sent by the client (101), obtaining a set of the upgradable versions according to the information in the check file matching database (103), and sending the set of the upgradable versions to the client (101); generating an upgrade package according to the target version and sending the upgrade package to the client (101);
and a database (103): the system is used for storing all system architecture, project, system version and package list information for the processing center (102) to inquire and acquire.
A computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of any of the upgrade methods described above.
An upgrade apparatus based on fine-grained state detection, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the steps of any of the upgrade methods above when executing the computer program.
Compared with the prior art, the application can obtain the following technical effects: fine-grained judgment is carried out on the whole state of the operating system, and the generated upgrade check file is more reliable; eliminating conflicts and then finely generating an upgrade package to ensure that operating systems in various states can be safely and uniformly upgraded to a specified version state; the operating systems of different projects and application scenes can be automatically distinguished, each project has a version state and an upgrading route, and can be upgraded to any available version state in the route.
Of course, it is not necessary for any one product to achieve all of the above-described technical effects simultaneously.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is an overall architecture diagram of an embodiment of the present application.
FIG. 2 is a schematic flow diagram of one embodiment of the present application.
Fig. 3 is a process of generating a user upgrade check file according to an embodiment of the present application.
Detailed Description
Embodiments of the present application will be described in detail with reference to the drawings and examples, so that how to implement technical means to solve technical problems and achieve technical effects of the present application can be fully understood and implemented.
Fig. 1 shows a schematic overall architecture diagram of an embodiment of the present invention, which mainly includes three parts, namely a client 101, a processing center 102, and a database 103.
The client 101 detects version information, package information, and the like of the user system, integrates and format-processes the detected information to generate a check file, and sends the check file to the processing center 102.
The client 101 receives the upgradable version analyzed by the processing center 102 for the user to select, and sends the target version selected by the user to the processing center 102, and receives the upgrade package finally generated by the processing center 102 for installation and upgrade.
The client 101 communicates with the processing center 102 via Http protocol and performs file transmission, including checking files, scalable version information interaction, and transmission of the final upgrade package.
The processing center 102 receives the check file sent by the client 101, and obtains a set of upgradable version nodes according to the check file matching with the version information of each item in the database 103 and sends the set of upgradable version nodes to the client 101.
After receiving the target version selected by the user, the processing center 102 calculates a package list to be newly installed and upgraded when upgrading to the target version, a processing script and an installation package for final upgrading and use according to the package list information in the verification file, and packages the static upgrade file and a pre-stored instruction execution program into the installation package for final upgrading and use, and sends the installation package to the client 101.
The database 103 stores all system architecture, project, system version, package list and other information, and provides information query and acquisition for the processing center 102.
Fig. 2 shows a main flow diagram of an embodiment of the present invention, which illustrates a main process of an upgrade technique based on fine-grained system state detection.
An upgrading method based on fine-grained system state detection in a Linux system comprises the following steps:
s1: the user system client detects the fine granularity of the system state, generates an upgrade check file with the system state through detection, and the content of the upgrade check file is agreed according to a certain format and can be directly read and analyzed by a script of a processing center;
s2: the processing center compares the upgrading verification file generated by the client with the versions of various project systems in the database, calculates an upgradable node set of the user system version for the user to select, and prompts that the user version is the latest state if the user is the latest version;
s3: after a user selects a target version, a processing center reads a package list of the target version in a database, compares the package list with a verification file package list of a user system, and calculates a package list which needs to be incrementally installed and upgraded when the state of the user system is upgraded to the target version, wherein the package list and the package list are collectively called as an upgrade package list; meanwhile, the upgrade package list and the original package list of the user system are subjected to package conflict judgment, so that upgrade failure caused by package version or package dependence conflict is prevented;
s4: after the conflict is judged, the processing center pulls the relevant static upgrading file and the instruction execution program needed to be used for upgrading to the target version according to the generated package list, packages the static upgrading file and the instruction execution program into an installation package (namely an upgrading package) used for upgrading the final version, and sends the installation package (namely the upgrading package) to the client for installation and upgrading.
The specific steps of the above 4 steps are shown in fig. 2, and include:
s201: acquiring the state of a user system before upgrading by using the current system version;
s202: starting a client; when a user needs to upgrade, the client software is operated to start detecting the system state;
s203: detecting the system state to generate an upgrade check file;
and the user system client detects the system state at a fine granularity, and generates a check file with the system state through detection.
The fine-grained detection of the system state can be obtained by instructions or directly checking system files, and the detection content comprises the following steps:
a) user system authentication information (i.e., authorized activation of version): if the upgrade program is not authorized or activated, the upgrade program is stopped;
b) the ex-warehouse serial number: if no ex-warehouse serial number or no record of the serial number in the processing center library exists, the pirate is regarded as the pirate, and the upgrading program is stopped;
c) system version number: the system version locating method is used for locating items and historical nodes to which a user system version belongs;
d) and (3) system architecture: for locating a user system version upgradeable version;
e) software package list: and comparing the package list after the user selects the upgraded target version.
Then, the generation of the verification file requires: detecting a warehouse-out serial number, detecting version authorization activation, acquiring a system version number, acquiring a framework, a package list and the like; the content is processed according to the agreed format, and finally integrated into an upgrade check file which can be directly read and analyzed by a processing center script, and used for positioning the later upgrade node, and the specific steps of obtaining are shown in fig. 3:
s301: acquiring an un-generated check file;
s302: detecting whether the ex-warehouse serial number of the user system is empty, if not, sending the out-warehouse serial number to a processing center to inquire a database to see whether the out-warehouse serial number is recorded in a case, otherwise, judging that piracy is not upgraded;
s303: if the verification result is that the version is abnormal, the check file generation is stopped, and the step 301 is entered; otherwise, continuing the detection process and entering the next step;
s304: detecting whether the user authorization file is complete, further detecting whether a user system is activated if the user authorization file is complete, and not upgrading the user authorization file if the content of the authorization file is incomplete or the system is not activated and authenticated;
s305: judging whether the system is authorized or activated, if the system is detected to be unauthorized or not activated, stopping generating the verification file, and entering step 301; otherwise, continuing the detection process and entering the next step;
s306: the system version number and the system architecture are obtained by instructing or inquiring the system file, for example, in the Ubuntu system, the relevant information can be inquired by a command line lsb _ release-a or a view/etc/lsb-release file. Acquiring an installed package list of a system through an instruction, for example, in an Ubuntu system, acquiring the package list in the system and the version numbers of the packages through dpkg-l, directionally outputting the package list and the version numbers to a file, and then carrying out format adjustment and deleting unnecessary information according to convention;
s307: and integrating the acquired system version number, system architecture and package list into an upgrade check file and sending the upgrade check file to a processing center.
And 7, generating an upgrade check file.
S204: judging whether the upgrading condition is met, if not, stopping upgrading, and entering step 201; otherwise, continuing the upgrading process and entering the next step; judging whether the upgrading condition is met specifically by judging the system state, such as detecting the ex-warehouse serial number, version authorization activation and the like;
s205: the processing center inquires a database according to the system version number and the architecture in the upgrade check file, positions whether the system is an x86 version or an arm version and whether the system is a 64-bit system or a 32-bit system through the architecture information, positions items, version series and the like which a user system belongs to through the version number, finally obtains the node position in the version system according to the version number, determines the upgradable version and returns the upgradable version to the user for selection;
s206: judging whether an upgradable version exists, if the processing center calculates that the user system is the latest version, prompting the user system that the user system is the latest version and does not need to be upgraded, and entering step 201; otherwise, entering the next step;
s207: a user selects a target upgrading version; providing the set of the upgradable versions for a user to select, and the user selects the node version which the user wants to upgrade to and submits the node version to a processing center for generating an upgrade package;
after the user selects the target version, the processing center reads the package list of the target version in the database, compares the package list with the package list in the verification file of the user system, and calculates the package list which needs to be incrementally installed and upgraded when the state of the user system is upgraded to the target version at present.
S208: performing package conflict judgment and generating a static upgrade file;
and performing increment comparison on the package list and the package version number in the upgrade check file and the package list and the package version number of the target version in the database through the script, calculating that the packages with more target versions than the package list in the check file are required to be installed, and the packages with more target versions than the versions in the check file are required to be upgraded, thereby obtaining a package list which is required to be additionally installed and upgraded when being upgraded to the target version.
The specific steps of comparing the user upgrade check file with the target version package list and the package version comprise:
a) the target system is listed into an increment installation package list relative to a newly added package of the user system;
b) the package with the version higher than that of the user system package in the target system is listed as a 'version upgrading package list';
c) the user system will need to make a conflict determination with the above-mentioned packages listed in the "incremental install package list" with respect to the additional packages of the target system.
After the comparison, after the upgrade installation package list is obtained, package conflict judgment needs to be carried out on the upgrade installation package list and packages installed in the current version of the user, because the user may install a plurality of packages in the system use, the packages may have the problem of dependency conflict with packages needing to be additionally installed when the upgrade is carried out to the target version, and package conflict judgment can prevent upgrade failure caused by package version or package dependency conflict.
And comparing the check file package list with the target version package list again to obtain packages with more check file package lists than the target version, wherein the packages are packages additionally installed when the user uses the packages and packages removed from the old version to the target version (the packages cannot conflict with the target version certainly), and after obtaining the packages additionally installed by the user, performing package conflict judgment on the packages additionally installed by the user and the packages additionally installed by the system upgrading. For example, in the Ubuntu system, the "Conflicts" information in the package can be compared through a script to detect whether a package with a dependent conflict exists, and the "Conflicts" information of the software package can be obtained through a command line: and the ap-cache show package receiving name can be checked by displaying package information or a control file in the source code, the comparison and the processing can be automatically completed through a script, and if no conflict exists, a static upgrade file package is obtained.
The second packet collision judgment in this step includes:
a) judging whether compatibility conflict exists between the user installed package and the package listed in the increment installation package list, namely whether the package is a package which cannot be stored together;
b) judging whether the version of the dependent package or library of the user installed package and the package or library depended by the package listed in the increment installation package list have version conflict, for example, the original package depends on the library with low version, and the package to be installed for upgrading depends on the same library with high version, which can cause version conflict.
S209: judging whether a package which conflicts with the system exists in the current system, if so, prompting a conflict package name to a user, and the user can choose to abandon the upgrade and return to the step 201; otherwise, automatically unloading the conflict packet on the system and entering the next step;
if any one of two conflicts exists in S208, the package installed by the user and the package which needs to be incrementally installed when the package is upgraded to the target system, the normal upgrade cannot be performed, the name of the conflict package is prompted to the user, and the user can choose to abandon the upgrade or automatically unload the conflict package on the system and continue to upgrade to the target system; if the upgrade continues, it will be essential to maintain the integrity of the target system package.
S210: adding an instruction execution program to generate an upgrade package;
the instruction execution program mainly comprises: upgrade install instructions for packages and special processing instructions for partial packages. If the packages upgraded to the target version need special processing, if some packages cannot be installed in a covering mode, the packages need to be installed after being uninstalled; some packages need special configuration after being installed. The special processing scripts and the target version are stored in a database together, when the version needs to be upgraded to a certain version, the corresponding scripts under the path of the instruction file stored in the database are added into an upgrade package, and finally the static upgrade file and the instruction execution program are packaged into an upgrade package and sent to a user for upgrading;
s211: running an upgrade package to upgrade the system to a target system; the client side directly operates to upgrade the system after receiving the upgrade package of the processing center, and the upgrade interface automatically guides the user to complete the upgrade.
The beneficial effect of this application is: fine-grained judgment is carried out on the whole state of the operating system, and the generated upgrade check file is more reliable; eliminating conflicts and then finely generating an upgrade package to ensure that operating systems in various states can be safely and uniformly upgraded to a specified version state; the operating systems of different projects and application scenes can be automatically distinguished, each project has a version state and an upgrading route, and can be upgraded to any available version state in the route.
The fine-grained system state detection-based upgrading method in the Linux system provided by the embodiment of the application is described in detail above. The above description of the embodiments is only for the purpose of helping to understand the method of the present application and its core ideas; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
As used in the specification and in the claims, certain terms are used to refer to particular components. As one skilled in the art will appreciate, different mechanisms may be used to refer to a same component by different names. This specification and claims do not intend to distinguish between components that differ in name but not function. In the following description and in the claims, the terms "include" and "comprise" are used in an open-ended fashion, and thus should be interpreted to mean "include, but not limited to. "substantially" means within an acceptable error range, and a person skilled in the art can solve the technical problem within a certain error range to substantially achieve the technical effect. The description which follows is a preferred embodiment of the present application, but is made for the purpose of illustrating the general principles of the application and not for the purpose of limiting the scope of the application. The protection scope of the present application shall be subject to the definitions of the appended claims.
It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such good or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a commodity or system that includes the element.
The foregoing description shows and describes several preferred embodiments of the present application, but as aforementioned, it is to be understood that the application is not limited to the forms disclosed herein, but is not to be construed as excluding other embodiments and is capable of use in various other combinations, modifications, and environments and is capable of changes within the scope of the inventive concept as expressed herein, commensurate with the above teachings, or the skill or knowledge of the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the application, which is to be protected by the claims appended hereto.
Claims (9)
1. An upgrading method based on fine-grained system state detection in a Linux system comprises the following steps: s1: generating an upgrade check file with a current system state, wherein the upgrade check file is generated by performing fine-grained detection on the system state based on a client; the system state comprises user system authentication information, ex-warehouse serial numbers, system version numbers, system architectures and software package lists;
s2: calculating an upgradable version according to the upgrade check file;
s3: selecting a target version needing to be upgraded from the upgradable versions;
s4: calculating an upgrade list, and judging packet conflicts;
s5: generating a static upgrade file;
s6: packing the static upgrading file and an instruction execution program required to be used for upgrading to the target version into an upgrading packet, and upgrading the version;
the content of the fine-grained detection comprises:
a) user system authentication information: if not authorized or activated, stopping the upgrading program;
b) the ex-warehouse serial number: if the ex-warehouse serial number does not exist or the ex-warehouse serial number does not have a record in the database, stopping the upgrading program;
c) system version number: the system version information management system is used for positioning the item and/or the history node to which the user system version belongs;
d) and (3) system architecture: an upgradeable version for locating the user system version;
e) software package list: for performing a package list comparison after the target version is selected.
2. The fine-grained system state detection-based upgrading method in the Linux system according to claim 1, characterized in that: the specific steps for generating the upgrade check file comprise:
s11: acquiring an un-generated check file;
s12: detecting whether the ex-warehouse serial number of the user system is empty, if not, inquiring the database to see whether the record is on the counter, otherwise, not upgrading;
s13: detecting the ex-warehouse version, if the ex-warehouse version is verified to be an abnormal ex-warehouse version, stopping generating the check file, and entering S11; otherwise, entering the next step;
s14: detecting whether the user authorization file is complete, if so, entering the next step, and if not, or the system does not carry out activation authentication, not upgrading;
s15: judging whether the system is authorized or activated, if not, stopping generating the check file, and entering S11; otherwise, entering the next step;
s16: acquiring a system version number, a system architecture and/or an installed package list;
s17: and integrating the acquired system version number, the system architecture and the installed package list into an upgrade check file.
3. The fine-grained system state detection-based upgrading method in the Linux system according to claim 1, characterized in that: the step of judging the packet collision comprises the following steps: s41: and (3) judging packet conflict for the first time: performing package conflict judgment on the upgrade check file and the target version according to a package list and a package version to obtain an upgrade installation package list; s42: and (3) judging packet conflict for the second time: and performing package conflict judgment on the installation package list needing to be upgraded and the installed package list in the current system version.
4. The fine-grained system state detection-based upgrading method under the Linux system according to claim 3, characterized in that: the step of determining packet collision further comprises: s43: if the packet conflict judgment result indicates that a conflict packet exists, normal upgrading cannot be performed, and upgrading is selected to be abandoned or the conflict packet is automatically unloaded; if the conflict packet is unloaded, continuing to upgrade to the target version; if the upgrade continues, the package integrity of the target version will be maintained.
5. The fine-grained system state detection-based upgrading method under the Linux system according to claim 3, characterized in that: the S42 specifically includes: judging whether compatibility conflict exists between the installed package and the packages listed in the upgrade installation package list; and judging whether the version of the dependency package or the library of the installed package conflicts with the version of the package or the library which is listed in the upgrade installation package list and depended on.
6. The fine-grained system state detection-based upgrading method under the Linux system according to any one of claims 1 to 5, characterized in that: the specific content of the S2 is as follows: inquiring a database according to the system version number and the architecture in the upgrade check file, positioning the digit corresponding to the system through the architecture information, positioning the item and/or the version series of the system through the system version number, and finally obtaining the node position in the version system according to the system version number to determine the upgradable version.
7. A system based on fine-grained state detection, comprising:
client (101): detecting information of a current operating system, wherein the information of the current operating system comprises user system authentication information, a ex-warehouse serial number, a system version number, a system architecture and a software package list, integrating and processing the detected information in format to generate an upgrade check file, and sending the upgrade check file to a processing center (102); receiving a scalable version sent by the processing center (102) for selection, sending the selected target version to the processing center (102), and receiving an upgrade package generated by the processing center (102) for installation and upgrade;
the upgrade check file is generated by performing fine-grained detection on a system state based on a client, and the fine-grained detection comprises the following contents:
a) user system authentication information: if not authorized or activated, stopping the upgrading program;
b) the ex-warehouse serial number: if the ex-warehouse serial number does not exist or the ex-warehouse serial number does not have a record in the database, stopping the upgrading program;
c) system version number: the system version information management system is used for positioning the item and/or the history node to which the user system version belongs;
d) and (3) system architecture: an upgradeable version for locating the user system version;
e) software package list: the system is used for comparing the package list after the target version is selected;
the processing center (102): receiving the upgrade check file sent by the client (101), obtaining a set of the upgradable versions according to the information in the upgrade check file matching database (103), and sending the set of the upgradable versions to the client (101); generating an upgrade package according to the target version and sending the upgrade package to the client (101);
and said database (103): the system is used for storing all system architecture, project, system version and package list information for the processing center (102) to inquire and acquire.
8. A computer-readable storage medium storing a computer program, characterized in that: the computer program, when being executed by a processor, implementing the steps of the upgrade method as claimed in any one of claims 1-5.
9. An upgrade apparatus based on fine-grained state detection, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: the steps of the upgrade method according to any one of claims 1-5 are implemented when the computer program is executed by the processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711247522.1A CN107943502B (en) | 2017-12-01 | 2017-12-01 | Upgrading method based on fine-grained system state detection in Linux system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711247522.1A CN107943502B (en) | 2017-12-01 | 2017-12-01 | Upgrading method based on fine-grained system state detection in Linux system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107943502A CN107943502A (en) | 2018-04-20 |
| CN107943502B true CN107943502B (en) | 2021-04-27 |
Family
ID=61948170
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711247522.1A Active CN107943502B (en) | 2017-12-01 | 2017-12-01 | Upgrading method based on fine-grained system state detection in Linux system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107943502B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109117158A (en) * | 2018-08-02 | 2019-01-01 | 郑州云海信息技术有限公司 | Firmware update and device |
| CN109542499A (en) * | 2018-10-11 | 2019-03-29 | 珠海许继芝电网自动化有限公司 | A kind of distribution terminal software version management method and device |
| CN112068855B (en) * | 2019-06-10 | 2024-03-26 | 海信视像科技股份有限公司 | Method and system for upgrading application under dual systems |
| CN110611650B (en) * | 2019-07-05 | 2021-12-28 | 中国工程物理研究院计算机应用研究所 | Smooth upgrading method for operation state PKI/CA authentication system |
| CN110502263B (en) * | 2019-08-14 | 2023-04-07 | 深圳市东微智能科技股份有限公司 | Upgrade package manufacturing method, system and computer readable storage medium |
| CN111158719B (en) * | 2019-12-26 | 2023-06-16 | 湖南快乐阳光互动娱乐传媒有限公司 | Application software upgrading method and device |
| CN112947988B (en) * | 2021-03-10 | 2024-03-08 | 中国民航信息网络股份有限公司 | Continuous integration method of mainframe, related device and computer storage medium |
| CN113204355A (en) * | 2021-05-20 | 2021-08-03 | 山东英信计算机技术有限公司 | Method, system, terminal and storage medium for pre-installing software of domestic system |
| CN114499948A (en) * | 2021-12-23 | 2022-05-13 | 麒麟软件有限公司 | Linux firewall dynamic policy processing method and device and storage medium |
| CN116009912B (en) * | 2022-12-26 | 2023-08-18 | 郑州云智信安安全技术有限公司 | Construction method for automatically generating upgrade package aiming at private network environment |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105302586A (en) * | 2014-06-24 | 2016-02-03 | 中兴通讯股份有限公司 | Software upgrade processing method and device, terminal and server |
| CN107172460A (en) * | 2017-06-16 | 2017-09-15 | 深圳市云联志远网络科技有限公司 | Network television upgrade method, device and computer-readable recording medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070240134A1 (en) * | 2006-02-28 | 2007-10-11 | Joydeep Buragohain | Software packaging model supporting multiple entity types |
-
2017
- 2017-12-01 CN CN201711247522.1A patent/CN107943502B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105302586A (en) * | 2014-06-24 | 2016-02-03 | 中兴通讯股份有限公司 | Software upgrade processing method and device, terminal and server |
| CN107172460A (en) * | 2017-06-16 | 2017-09-15 | 深圳市云联志远网络科技有限公司 | Network television upgrade method, device and computer-readable recording medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107943502A (en) | 2018-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107943502B (en) | Upgrading method based on fine-grained system state detection in Linux system | |
| US8443354B1 (en) | Detecting new or modified portions of code | |
| EP0849657B1 (en) | Secure data processing method and system | |
| US11875143B2 (en) | Deploying device campaign updates to IoT devices | |
| CN111309336B (en) | Deployment method and device of distributed application | |
| KR20060129312A (en) | Use loader for signaling the system software update service | |
| CN103729597A (en) | System starting verifying method and device and terminal | |
| CN106293691A (en) | Automatic discovery and installation of secure boot credentials | |
| US10360396B2 (en) | Token-based control of software installation and operation | |
| US20220253297A1 (en) | Automated deployment of changes to applications on a cloud computing platform | |
| CN106548065B (en) | Application program installation detection method and device | |
| AU2019201237A1 (en) | Updating software packets in water installation controlling apparatus | |
| CN111368299A (en) | Dynamic link library file hijacking detection method, device and storage medium | |
| CN107632932B (en) | Multi-stage checking software warehouse reliability detection method | |
| CN111966422A (en) | Localized plug-in service method and device, electronic equipment and storage medium | |
| CN109032641B (en) | Application version updating method and device | |
| CN115543429A (en) | Project environment building method, electronic equipment and computer readable storage medium | |
| CN114443065A (en) | Platform deployment method, platform deployment device, electronic equipment and storage medium | |
| CN111930411B (en) | Code upgrading method and device, computer equipment and storage medium | |
| CN111522560A (en) | Software installation method and device, storage medium and electronic equipment | |
| CN106325898B (en) | Software upgrading method and system | |
| CN114546420A (en) | Software remote installation protection uninstalling method | |
| CN117786666B (en) | Function code starting verification method and device, electronic equipment and storage medium | |
| CN109284601B (en) | Software authorization method and device | |
| CN113495729A (en) | Software upgrading method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB03 | Change of inventor or designer information |
Inventor after: Huang Cheng Inventor after: Wen Bo Inventor after: Zhang Dongsong Inventor after: Li Xiang Inventor after: He Bing Inventor after: Ma Chao Inventor after: Xia Ruobing Inventor after: Wu Kaige Inventor before: Ma Jun Inventor before: Xia Ruobing Inventor before: Wu Kaige Inventor before: Liu Xiaodong Inventor before: Yu Jie Inventor before: Huang Cheng Inventor before: Wen Bo Inventor before: Zhang Dongsong Inventor before: Li Xiang Inventor before: He Bing Inventor before: Ma Chao |
|
| CB03 | Change of inventor or designer information | ||
| CB02 | Change of applicant information |
Address after: 6-8 / F, building 3, Xin'an pioneer Plaza, Tanggu marine science and Technology Park, Binhai New Area, Tianjin Applicant after: Kirin Software Co.,Ltd. Address before: 6-8 / F, building 3, Xin'an pioneer Plaza, Tanggu marine science and Technology Park, Binhai New Area, Tianjin Applicant before: TIANJIN KYLIN INFORMATION TECHNOLOGY Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |