A Linux operating system update transaction automation configuration method and system

Abstract

This invention relates to a method and system for automated configuration of Linux operating system update transactions, belonging to the field of software automated operation and maintenance. The method includes: establishing a parameter template library; obtaining command-line parameters, configuration file parameters, and system-collected parameters; merging multi-source parameters according to a preset priority order and performing format verification and conflict detection; mapping parameters to JSON templates to generate transaction configurations; interacting with a web-based update management platform via API to complete transaction creation, enabling, disabling, or deletion; parsing the platform response and providing execution results; and passing the transaction identifier to an automated testing framework to trigger tests, collect results, and automatically clean up the environment. This invention encapsulates complex, multi-level nested parameters using predefined JSON templates, reducing manual configuration time from tens of minutes to seconds. It supports script calls and CI / CD pipeline integration, significantly improving the configuration efficiency, automation level, and test coverage of Linux operating system update transactions.

Description

Technical Field

[0001] This invention relates to the field of automated software operation and maintenance, and in particular to a method and system for automating the configuration of Linux operating system update transactions. Background Technology

[0002] In routine Linux operating system testing, testers frequently need to create update transactions to verify system functionality. However, current Linux operating system update transactions rely on manual configuration via a web interface, requiring the input of dozens of parameters (up to five levels of nesting) per transaction, taking tens of minutes and being prone to errors. Furthermore, purely manual operations cannot be invoked by scripts, resulting in an automation rate of less than 20% for update modules, severely hindering testing efficiency.

[0003] In existing technologies, some solutions have attempted to address issues related to operating system updates. For example, patent CN119292629A proposes a Linux upgrade path recommendation method, focusing on decision analysis before the upgrade; patent CN113886220A provides an application upgrade testing method, focusing on compatibility verification after the upgrade; patent CN115509557A solves the problem of batch deployment on multiple client machines; patent CN118259936A optimizes the acquisition and installation process of update packages; and US patent US20190188021A1 focuses on the distribution architecture and rollback mechanism of update packages. However, none of the above-mentioned existing technologies have solved the core problem of "how to efficiently and accurately automate the configuration of update transactions containing a large number of complex parameters after the update content is determined," that is, there is a technological gap in configuration automation between upgrade decision-making and execution verification.

[0004] Therefore, there is an urgent need for a technical solution that can transform the complex manual configuration process into an efficient and reliable automated pipeline to fill the aforementioned technical gap and improve the management efficiency and automated testing level of Linux operating system update transactions. Summary of the Invention

[0005] This invention aims to solve the technical problems of low efficiency, insufficient automation, and inability to deeply integrate with testing frameworks in the existing Linux operating system transaction configuration update, and provides a method and system for automated configuration of Linux operating system transaction updates.

[0006] In a first aspect of the present invention, a method for automating transaction configuration updates in a Linux operating system is provided. The method includes: Step S1, System Initialization Phase: Initialize the parameter template library and set the default API connection parameters. The parameter template library stores predefined JSON template files, which have a multi-level nested structure. Step S2, Parameter Input Processing Stage: Receive command-line parameters input by the user, parse the command-line parameters, read the user-specified configuration file to obtain configuration file parameters, automatically collect Linux system environment information to obtain system collection parameters; the command-line parameters include transaction name, configuration file name, machine information, package list, and source address configuration; Step S3, Parameter Fusion Verification Stage: Execute the multi-source parameter fusion algorithm to merge command line parameters, configuration file parameters, system-collected parameters, and template default parameters according to a preset priority order to obtain the parameter fusion result, and perform parameter format verification and parameter conflict detection on the parameter fusion result; Step S4, Template Application Stage: Load the specified JSON template file, map the merged parameter results to the corresponding nodes of the specified JSON template, and generate a complete transaction configuration; Step S5, API Request Construction Phase: Construct the API request payload according to the transaction configuration, and set the request header and timeout parameters. The API request payload is serialized data that conforms to the API specification of the Web-based update management platform. Step S6, Transaction Execution Phase: Submit API request payload to the Web-based update management platform via API interface, and perform operations such as creating a transaction, enabling a transaction, disabling a transaction, or deleting a transaction; Step S7, Response Processing Stage: Parse the response status code and response body of the Web-based update management platform, determine whether the operation was successful or not based on the HTTP response status code and the business status field in the response body, and obtain the execution result feedback information; Step S8, Result Feedback Stage: Provide the user with execution result feedback information, including success information, error details, and suggested actions; Step S9, Test Integration Phase: When this method is integrated into an automated test scenario and a transaction creation or transaction enable operation is performed, after the transaction is successfully executed, the transaction identifier is passed to the automated test framework to trigger the execution of test cases, test results are collected, transaction configuration is associated with test results and stored, and transaction cleanup operations are automatically performed after the test is completed. Step S10, Log Recording Stage: Record the operations performed in each of the above steps to the log storage and link it with the Web-based update management platform to ensure traceability of the entire process.

[0007] By adopting the above technical solution, this invention encapsulates complex multi-level nested parameter structures through predefined JSON template files, simplifying dozens of parameters that originally needed to be filled in manually to only a few core parameters, significantly reducing configuration complexity; at the same time, it automatically merges command line parameters, configuration file parameters, system-collected parameters and template default parameters through a multi-source parameter fusion algorithm, realizing automated parameter filling and intelligent conflict resolution, compressing the configuration time of a single transaction from tens of minutes to seconds.

[0008] Optionally, the automatic collection of Linux system environment information includes: Obtain the MAC address using Linux system commands; Obtain package list information using the Linux package manager; Automatically identifies IP address, network configuration, and system version information.

[0009] By adopting the above technical solution, this invention automatically collects key environmental information such as MAC address, IP address, package list and system version by executing specific Linux system commands and reading system identification files. This eliminates the tediousness and error risk of manual input, ensures the accuracy and real-time nature of environmental information, and provides a reliable data foundation for subsequent parameter fusion and version adaptation.

[0010] Optionally, the preset priority order is as follows: Command line parameters > Configuration file parameters > System collection parameters > Template default parameters.

[0011] By adopting the above technical solution, this invention handles multi-source parameter conflicts through a hierarchical priority strategy. Command-line parameters have the highest priority, facilitating dynamic configuration overriding by scripts and CI / CD pipelines; configuration file parameters have the next highest priority, supporting scenario-based pre-configuration; system-collected parameters have the next highest priority, enabling environment adaptation; and template default parameters serve as a fallback, ensuring that all required fields have reasonable initial values. This priority strategy guarantees both flexibility and the integrity and consistency of the configuration.

[0012] Optionally, the parameter format validation includes: checking whether all required fields have been assigned values, checking whether the length of string parameters exceeds the limit, checking whether numerical parameters are within the valid range, and checking whether enumerated parameter values ​​are in the allowed list; The parameter conflict detection includes: checking whether the same machine is specified repeatedly, checking whether the package dependency is satisfied, and checking whether the source address is reachable; If an illegality or conflict is detected, the process will be terminated immediately and a detailed error report will be output to guide the user in making corrections.

[0013] By adopting the above technical solution, the present invention performs format verification and conflict detection immediately after parameter fusion, which can detect and intercept errors before the configuration is submitted to the web-based update management platform, avoiding invalid requests from occupying platform resources. At the same time, by outputting detailed error reports, it guides users to quickly locate and correct problems, significantly improving the configuration success rate and troubleshooting efficiency.

[0014] Optionally, step S4 further includes source address resolution: Intelligent parsing of source address parameters, which include a complete source address and optional additional attributes, including one or more of type identifier, priority identifier, and source repository type identifier; The system automatically identifies and standardizes the input format, then fills the parsed complete source address and additional attributes into the source address configuration node of the transaction configuration.

[0015] By adopting the above technical solution, the present invention supports source address input in multiple combination formats through an intelligent source address parsing engine. Users only need to provide a simplified source address string, and the system automatically identifies and standardizes it into a complete internal data structure, reducing the complexity of source address configuration and improving input flexibility and processing consistency.

[0016] Optionally, step S4 also includes Linux distribution compatibility adaptation: Based on the system version information collected in step S2, the target Linux distribution version is automatically identified; For different distribution versions, the corresponding rule sets stored in the parameter template library are called to perform differentiated processing on the transaction configuration, dynamically adjusting the parameter structure and verification logic. The rule sets are stored in the form of code branches or configuration mapping tables to ensure that the generated configuration is accurately adapted to the target system version.

[0017] By adopting the above technical solution, this invention automatically identifies the target system version and calls the corresponding rule set, realizing differentiated parameter processing for different Linux distributions, ensuring accurate adaptation of configuration to the target system version, and improving the universality and maintainability of the solution.

[0018] Optionally, the transaction execution in step S6 includes four core operations: Create a transaction: Submit a transaction creation request to the web-based update management platform, and receive and record the unique transaction identifier returned by the platform; Enable Transaction: Submit an enable request to the web-based update management platform based on the transaction identifier to enable the push function for the corresponding update transaction; Disable transaction: Submit a disable request to the web-based update management platform based on the transaction identifier to disable the push function of the corresponding update transaction; Delete transaction: Submit a deletion request to the web-based update management platform based on the transaction identifier to delete the corresponding update transaction.

[0019] By adopting the above technical solution, this invention encapsulates four core transaction operations of the Web-based update management platform through API interfaces, realizing automated management of the entire transaction lifecycle. Users can create, enable, disable, and delete transactions without logging into the Web interface, significantly improving operational efficiency and automation.

[0020] Optionally, the execution result feedback information includes: Parsing HTTP response status codes and response bodies; If the response status code is in the 2xx series and the business status field in the response body indicates success, the operation is considered successful, and the transaction identifier is extracted and recorded for subsequent use. If the response status code is not from the 2xx series, or the business status field indicates failure, the operation is deemed to have failed. The system extracts the error information from the response body and, in conjunction with the error handling module's strategy, outputs detailed reasons for the failure and suggested actions to the user.

[0021] By adopting the above technical solution, this invention accurately identifies operation results through a two-layer judgment mechanism (HTTP status code + business status field), extracts detailed error information for failure scenarios and outputs suggested operations in combination with error handling strategies, helping users to quickly locate and solve problems, and improving the system's fault tolerance and user experience.

[0022] Optionally, step S9 specifically includes: Step S91, Test Trigger: Pass the created transaction identifier to the automated testing framework to trigger the execution of the corresponding update function test cases; Step S92, Status Polling: Poll the Web-based update management platform to monitor the transaction execution status until it changes to the completed status or reaches the preset timeout threshold; Step S93, Result Collection: Collect the test execution results returned by the automated testing framework, including the test pass / fail status and details of failed test cases; Step S94, Associated Storage: Associate the complete configuration information of this transaction with the test execution results for storage; Step S95, Environment Cleanup: After the test is completed, the transaction status is automatically checked. If the transaction is enabled, the transaction is disabled first, and then the transaction is deleted. If the transaction is disabled, the transaction is deleted directly to clear the residual data in the test environment. Step S96, Unified Feedback: Return the integrated execution results to the caller, including transaction configuration summary, test execution results and cleanup status, forming a closed loop of the entire chain of "configuration → execution → verification → cleanup → traceability".

[0023] By adopting the above technical solution, this invention achieves deep integration with the automated testing framework through the test integration phase, forming a closed loop of the entire chain from configuration, execution, verification to cleanup. The associated storage of transaction configuration and test results supports subsequent traceability, and the automated environment cleanup avoids the pollution of the environment by test residues, increasing the automated testing ratio of update modules from less than 20% to more than 60%.

[0024] In a second aspect of the invention, an automated configuration system for Linux operating system update transactions is provided. The system includes: The user interface layer provides a command-line interface, a configuration file interface, and a system environment collection interface. It receives command-line parameters and configuration file parameters input by the user, and automatically collects Linux system environment information to obtain system collection parameters. The system collection parameters include system version information; the command-line parameters include transaction name, configuration file name, machine information, package list, and source address configuration. The core processing layer, connected to the user interface layer, integrates a parameter template management module, a multi-source parameter fusion engine, an intelligent source address parsing engine, a version compatibility adaptation layer, and a test automation integration module. It loads predefined JSON template files, merges command-line parameters, configuration file parameters, system-collected parameters, and template default parameters according to a preset priority order to obtain the parameter merging result, verifies the parameter format and detects parameter conflicts in the merged result, maps the merged result to the corresponding node in the JSON template file to generate a complete transaction configuration, intelligently parses the source address parameters to identify and standardize the complete source address and additional attributes, and calls the corresponding rule set based on the system version information to perform differentiated processing of the transaction configuration. The data persistence layer, connected to the core processing layer, consists of a template library, configuration cache, and log storage. It is responsible for the persistent storage and management of template data, cached data, and system logs, and enables connection with the log system of the external web-based update management platform. The API communication layer, connected to the core processing layer, integrates a request construction module, a response processing module, and an error handling module. It is used to construct an API request payload that conforms to the API specification of the Web-based update management platform according to the transaction configuration, and set request headers and timeout parameters. It submits the API request payload to the Web-based update management platform through the API interface to perform operations such as creating a transaction, enabling a transaction, disabling a transaction, or deleting a transaction. It also parses the response status code and response body of the Web-based update management platform, determines the success or failure of the operation based on the HTTP response status code and the business status field in the response body, and obtains the execution result feedback information. The test integration layer connects with the core processing layer and the automated testing framework, providing test framework interfaces and test template libraries. It is used to pass the transaction identifier to the automated testing framework after successful transaction execution to trigger test case execution, collect test results, associate and store transaction configurations with test results, and automatically perform transaction cleanup operations after the test is completed.

[0025] By adopting the above technical solution, this invention achieves separation of concerns through a five-layer architecture design. Each layer has clear responsibilities and low coupling. The user interface layer provides flexible input methods, the core processing layer implements intelligent parameter processing, the data persistence layer ensures data reliability, the API communication layer encapsulates platform interaction details, and the test integration layer supports DevOps practices. The overall architecture has good scalability and maintainability.

[0026] In summary, the present invention has at least one of the following beneficial technical effects: 1. By using JSON-based structured templates for parameter management and a multi-source parameter intelligent fusion mechanism, the manual configuration process that originally took tens of minutes is compressed to seconds, improving transaction configuration efficiency by tens of times.

[0027] 2. Automatic acquisition of system environmental information reduces manual input steps, and the legality verification and conflict detection mechanisms in the multi-source parameter fusion process effectively avoid parameter input errors and omissions, greatly improving the configuration success rate.

[0028] 3. Provides a complete command-line interface, supports script calls and CI / CD pipeline integration, increasing the proportion of automated testing for update modules from less than 20% to over 60%, significantly improving testing efficiency and DevOps practice level.

[0029] 4. By achieving deep integration with the automated testing framework through the test integration layer, a closed-loop process of "configuration → execution → verification → cleanup → traceability" is formed, which improves the efficiency of test environment management and the traceability of test results.

[0030] 5. By automatically identifying the target system version and calling the corresponding rule set through the Linux distribution compatibility and adaptation module, the configuration is accurately adapted to different versions, which improves the versatility and maintainability of the solution.

[0031] 6. The intelligent source address resolution engine supports automatic recognition and standardization of various combination formats, reducing the complexity of user input and improving the flexibility and accuracy of source address configuration. Attached Figure Description

[0032] Figure 1 This is a framework diagram of an automated configuration system for updating transactions on a Linux operating system, according to an embodiment of this application.

[0033] Figure 2 This is a schematic diagram of the web-based update management platform according to an embodiment of this application.

[0034] Figure 3 This is a flowchart of a method for automating transaction configuration updates in a Linux operating system, according to an embodiment of this application.

[0035] Figure 4 This is a flowchart of the multi-source parameter fusion processing in an embodiment of this application.

[0036] Figure 5 This is a flowchart of the intelligent source address resolution engine in an embodiment of this application. Detailed Implementation

[0037] The present invention will be further described in detail below with reference to the accompanying drawings.

[0038] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of the present invention.

[0039] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] The following are explanations of the relevant technical terms involved in this invention: Update Transaction: In the operating system update management platform, a complete update operation (e.g., pushing a security patch to a batch of machines) is defined as a "transaction".

[0041] CLI: Command-Line Interface.

[0042] CI / CD pipeline: An automated process for continuous integration / continuous deployment.

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

[0044] Figure 1This is a framework diagram of an automated configuration system for updating transactions on a Linux operating system, according to an embodiment of this application. The system is connected to a web-based update management platform and an automated testing framework. The system includes a user interface layer, a core processing layer, a data persistence layer, an API communication layer, and a test integration layer, wherein: 1. The user interface layer serves as the front-end for interaction between the system and users, providing command-line and configuration file interfaces. The command-line interface allows users to input commands and parameters via the terminal to perform operations such as creating, deleting, disabling, and enabling transactions. The configuration file interface allows users to specify scenario parameters through predefined JSON configuration files. Additionally, the user interface layer provides a system environment collection interface, which manages and executes automated collection of system environment information, including automatically obtaining parameters such as MAC address, IP address, software package list, and system version, eliminating the tediousness and error risks of manual input. The user interface layer diversifies and automates parameter input methods, providing users with a flexible operation entry point across all scenarios, from manual interaction to script integration. In short, the user interface layer is used to obtain command-line parameters, configuration file parameters, and system-collected parameters.

[0045] 2. The core processing layer is the intelligent hub of this system, integrating a parameter template management module, a multi-source parameter fusion engine, an intelligent source address parsing engine, a version compatibility adaptation layer, and a test automation integration module. Specifically, the parameter template management module maintains a predefined JSON template file library, which encapsulates the complete multi-level nested parameter structure required for updating transactions. The multi-source parameter fusion engine merges transaction parameters from different input sources (command line parameters, configuration file parameters, system-collected parameters, and template default parameters) according to a preset priority order. The intelligent source address parsing engine automatically identifies and standardizes source address inputs in various formats. The version compatibility adaptation layer automatically identifies the release version of the target system and calls the corresponding rule set. The test automation integration module collaborates with external automated testing frameworks. By coordinating the work of these five modules, the core processing layer transforms raw, multi-source input parameters into accurate, compliant, and target-environment-adaptive complete transaction configurations.

[0046] 3. The data persistence layer, serving as the system's logistical support center, consists of a template library, a configuration cache, and a log storage. The template library stores all predefined JSON template files; the configuration cache stores temporary configuration data generated during runtime, improving the efficiency of repetitive operations; and the log storage records all operation logs during system operation, including parameter inputs, fusion processes, API requests and responses, and error messages. The data persistence layer also connects to the web-based update management platform, ensuring persistent, efficient access, and end-to-end traceability of system runtime data.

[0047] 4. The API communication layer serves as the communication bridge between the system and the web-based update management platform. It professionally encapsulates all API interaction details through request construction, response processing, and error handling modules. The request construction module generates HTTP requests conforming to the web-based update management platform's API specifications based on transaction configuration, including setting correct request headers and timeout parameters. The response processing module parses the HTTP response status code and response body, extracts business status fields, and returns data. The error handling module captures network errors, timeout errors, and business errors returned by the platform, and performs appropriate retries or error reporting. The API communication layer ensures reliable request delivery, accurate response parsing, and smooth handling of network errors, guaranteeing the stable execution of core business processes.

[0048] 5. The Test Integration Layer is a key layer for enabling DevOps and improving testing efficiency. By providing test framework interfaces and a test template library, the Test Integration Layer achieves deep integration with automated testing frameworks. The test framework interfaces define standardized calling contracts, allowing external automated testing frameworks to seamlessly call the system's command-line interfaces. The test template library predefines configuration templates for various common test scenarios, supporting rapid reuse by testers. The Test Integration Layer directly supports the development, execution, and result analysis of test cases, thereby seamlessly embedding update transaction management into the continuous integration / continuous testing pipeline.

[0049] like Figure 2 As shown, the main functions of the web-based update management platform include creating transactions, enabling transactions, disabling transactions, and deleting transactions. Transaction querying and transaction log management are additional functions integrated throughout the four core transaction operations. The core processing layer achieves automated execution of these transaction operations through the collaborative processing of various core modules.

[0050] The process of creating a transaction includes: Prepare transaction parameters and validate them. If verification fails, an error message will be output. If the verification is successful, then check if a transaction parameter with the same name exists. If they exist, the existing parameters on the platform will be used, and no new ones (nodes, configuration items, source addresses) will be created. If it does not exist, a transaction will be created using the newly passed transaction parameters; Judge the creation result; If the creation result is a failure, the web-based update management platform will not have a new transaction, record the failure log, and output "creation failed". If the creation result is successful, the web-based update management platform will record a new transaction, log the success, and output "creation successful".

[0051] The process of enabling transactions includes: Check the transaction status; If the transaction status is "transaction does not exist", then output an error message; If the transaction status is enabled, a message will be displayed indicating that it is enabled. If the transaction status is disabled / draft, the Start Transaction API is called and the result of enabling is obtained; Judge the activation result; If the activation result is unsuccessful, the Web-based update management platform transaction activation will fail, a failure log will be recorded, and the activation failure will be output. If the activation result is successful, the Web-based update management platform transaction will be successfully activated, a success log will be recorded, and the activation success message will be output.

[0052] The process for disabling transactions includes: Check the transaction status; If the transaction status is "transaction does not exist", then output an error message; If the transaction status is disabled, a message will be displayed indicating that it is disabled. If the transaction status is enabled / draft, then call the Disable Transaction API and get the disabled result; Judge the results of the disabling; If the disabling result fails, the web-based update management platform transaction for disabling will fail, the failure log will be recorded, and the disabling failure will be output. If the disabling result is successful, the Web-based update management platform transaction is successfully disabled, a success log is recorded, and the disabling success is output.

[0053] The process of deleting a transaction includes: Check the transaction status; If the transaction status is "transaction does not exist", then output an error message; If the transaction status is enabled, a message will be displayed indicating that the transaction is enabled and cannot be deleted. If the transaction status is disabled / draft, call the delete transaction API and delete the transaction and / or the nodes and configuration items associated with the transaction to get the deletion result; Judge the deletion results; If the deletion fails, the web-based management platform will update the transaction deletion failure, record the failure log, and output "deletion failed". If the deletion is successful, the web-based update management platform will record a success log and output "deletion successful".

[0054] The process of querying transactions includes: Enter the query criteria and call the query API to get the query results; Judge the query results; If the query fails, an error message will be output. If the query is successful, the query result will be displayed.

[0055] The transaction log management process includes: Display log information and query log information.

[0056] In summary, the core idea of ​​this invention is to construct an automated update transaction management system based on parameter templating and multi-source information fusion. Complex parameter structures are encapsulated using predefined structured templates (preferably JSON format), allowing users to focus on only a few core parameters. The entire system workflow begins with the user interface layer receiving instructions and parameters, and ends with the API communication layer driving the external web-based update management platform to execute the transaction. Specifically, the system acquires parameters through three channels: command line, configuration files, and automatic system data collection, and intelligently fuses them according to preset priorities to generate a complete transaction configuration adapted to the target environment. Subsequently, the API communication layer submits this transaction configuration to the external web-based update management platform to complete the transaction operation. Simultaneously, the test integration layer collaborates with an external automated testing framework to provide fully automated support for the entire process, from test case development to report generation. All operation logs are persistently stored and linked with the external web-based update management platform to ensure process traceability.

[0057] Figure 3 This is a flowchart illustrating a method for automatically updating transaction configurations on a Linux operating system, as described in an embodiment of this application. Taking transaction creation as an example, the specific steps are as follows: Step S1: System initialization phase.

[0058] When the system starts, it first performs basic configuration and sets the default API connection parameters; then it initializes the parameter template library and loads predefined JSON template files. Each predefined JSON template file corresponds to a specific transaction scenario. The predefined JSON template file encapsulates the complete parameter structure required for that transaction scenario, including multi-level nested field definitions and reasonable default values ​​(template default parameters); finally, it establishes an API connection pool to prepare for subsequent high-frequency API calls.

[0059] Step S2: Parameter input processing stage.

[0060] It receives command-line arguments from the user, parses the command-line arguments, reads the configuration file to obtain the configuration file parameters, and automatically collects Linux system environment information to obtain system collection parameters.

[0061] Command-line arguments are parameters that users specify directly when entering system commands in the terminal. They offer the highest operational flexibility and are suitable for temporary adjustments or scenarios where parameters are dynamically passed to scripts. They include transaction names, configuration file names, machine information, package lists, source address configurations, etc.

[0062] The configuration file is preferably read in JSON format. The system parses the file content, verifies the validity of the JSON format, checks whether required fields are complete, and ensures that parameter values ​​are within the allowed enumeration range. If verification fails, the system immediately sends specific error information to the user to prevent invalid parameters from entering subsequent processes.

[0063] Configuration file parameters refer to the parameters defined in a JSON configuration file pre-written by the user. They are suitable for fixed configurations in standardized scenarios and can be written once and reused multiple times.

[0064] System-collected parameters refer to environmental parameters that the system automatically obtains through Linux commands, including MAC address, IP address, package list, system version, etc., without requiring manual input from the user.

[0065] Command-line parameters, configuration file parameters, and system-collected parameters are independent of each other in terms of source, but may overlap in content (such as the same package name appearing in both the command line and the configuration file). The system resolves conflicts by using a preset priority order (see step S3) to ensure the consistency and controllability of the final configuration.

[0066] Step S3: Parameter fusion verification stage.

[0067] like Figure 4 As shown, the multi-source parameter fusion processing flowchart illustrates the complete process from template default parameters to parameter merging results. The multi-source parameter fusion algorithm merges parameters according to a preset priority order to obtain the parameter merging results. The preset priority order is command line parameters > configuration file parameters > system collected parameters > template default parameters.

[0068] The system starts with the default parameters of the template and sequentially accepts system-collected parameters, configuration file parameters, and command-line parameters for progressive overlay. Necessary verification is performed after each overlay step, ultimately generating a complete, consistent, and usable parameter set. The core of this process lies in the three-stage structure of "baseline loading → progressive overlay → verification output," and the layer-by-layer overlay rule of "low priority → high priority," ensuring the controllability of the parameter fusion process and the correctness of the final result.

[0069] The specific process is as follows: Step S31, Command line parameter input: First, the parameters passed by the user through the command line are received. This is the starting point of the entire process. At this stage, the user provides various parameters required for the operation.

[0070] Step S32, Parameter Parsing: Parse the input command line parameters, extract the name and corresponding value of each parameter, and prepare for subsequent verification and fusion.

[0071] Step S33, Required Parameter Integrity Verification: After parsing, the system checks the completeness of the required parameters for the command line parameters. If the required parameters are incomplete, the system enters an error state, prompts the user with missing parameter information, and guides the user to re-enter the command line parameters. The process returns to step S31, forming a loop until the required parameters are complete. If the required parameters are complete, step S34 is executed.

[0072] Step S34, Optional parameter existence check: After the required parameters pass the verification, the system further checks whether the user has passed optional parameters. If yes, proceed to step S35; otherwise, proceed to step S36.

[0073] Step S35: Merging Command-Line Arguments and Configuration File Parameters: Command-line arguments and configuration file parameters are merged. During this merging process, command-line arguments have higher priority than configuration file parameters. That is, when two parameters have the same name, the value of the command-line argument takes precedence, achieving parameter overriding and merging. After merging, new configuration parameters are formed (see attached table). Figure 4 In the "Configuration File Parameters" section located below, proceed to step S36.

[0074] Step S36: System Parameter Acquisition Relevance Judgment: The system determines whether the current running scenario involves system acquisition parameters. If not, the system acquisition parameters (which are empty or default values ​​at this time) are merged with the template default parameters, and step S37 is executed after merging. If yes, the new configuration file parameters are merged with the template default parameters. In this merging, the configuration file parameters have higher priority than the template default parameters, and the template default parameters are only used as a fallback default value for unconfigured items. Step S37 is executed after the merging is completed.

[0075] Step S37, Parameter Verification Phase: After all parameters have been fully integrated across multiple layers, the system enters the parameter verification phase. The system comprehensively verifies the legality, validity, and correct format of the final parameter set to ensure that the parameters meet operational requirements. This concludes the entire parameter loading and configuration process.

[0076] Specifically, the system first constructs an initial parameter set based on the default parameters of the JSON template; then it fills the corresponding fields with the environmental information collected by the system (MAC address, IP address, package list, system version, etc.), overriding the default values ​​in the JSON template; next, it reads the parameter settings in the configuration file and overrides the parameters collected by the system (if there are conflicts); finally, it parses the command-line parameters and overrides all the aforementioned parameters with the highest priority.

[0077] After merging, the parameter format is verified and parameter conflict is detected in the merged parameter results.

[0078] Parameter format validation includes: checking whether all required fields have been assigned values, checking whether the length of string parameters exceeds the limit, checking whether numeric parameters are within the valid range, and checking whether enumerated parameter values ​​are in the allowed list.

[0079] Parameter conflict detection includes: checking whether the same machine is specified repeatedly, checking whether package dependencies are satisfied, and checking whether the source address is reachable.

[0080] If an illegality or conflict is detected, the system will immediately terminate the process and output a detailed error report to guide the user in making corrections.

[0081] Step S4: Template application stage.

[0082] The system loads the specified parameter template, maps the merged parameters to the corresponding nodes in the template, and generates a complete transaction configuration. The transaction configuration is a platform-independent structured parameter object containing complete fields such as target machine information, package list, source address, and update strategy.

[0083] The system intelligently parses the source address parameter, which includes the complete source address and optional additional attributes. These additional attributes include one or more of the following: type identifier, priority identifier, and source repository type identifier. The system automatically identifies and standardizes the input format, then populates the parsed complete source address and additional attributes into the source address configuration node of the transaction configuration.

[0084] like Figure 5 As shown in the diagram, the intelligent source address resolution engine workflow illustrates the complete processing path from user input of source address parameters to the final generation of standardized source address configurations. This process is divided into two paths depending on whether the input is a complex source address.

[0085] Enter the source address parameter in the command line and determine whether the source address parameter is a complex source address; If the source address parameter is a complex source address, it is passed in as a file. After file data preprocessing (comment removal, blank line filtering, and space standardization), the system automatically identifies and intelligently parses each source address format (five format types), automatically completes missing additional attributes, and then determines whether the source address parameter has passed a type or priority. If so, the system sets the parameter value (type, priority, etc.) passed in the source address parameter to the corresponding source address record. If not, the system sets the default type of the source address to upgrade source and the priority to 500. If the source address parameter is not a complex source address, then directly enter the source address in the command line.

[0086] The two paths mentioned above ultimately converge in the "fusion" step, where the system deeply integrates the parsed source address parameters with existing configuration file parameters, outputting a standardized source address configuration. The core value of this source address engine lies in its support for automatic recognition and standardization of multiple input formats. Users do not need to remember complex parameter formats; they only need to provide a simplified source address string, and the system can automatically complete the parsing, completion, and standardization.

[0087] The intelligent source address resolution engine of this invention supports five formats of source address input: Format 1: Complete source address (using default type, priority, and source repository type), i.e., the system uses the default type, priority, and source repository type to fill in the address; Format 2: Complete source address + type, i.e., the system uses the specified type, default priority and source repository type; Format 3: Complete source address + priority, i.e., the system uses the specified priority, default type and source repository type; Format 4: Full source address + type + priority, which means the system uses the specified type and priority, with the default source repository type; Format 5: Complete source address + type + priority + source repository type, meaning the system uses all specified field values.

[0088] The intelligent source address resolution engine automatically identifies the input format through regular expression matching and delimiter segmentation, and standardizes the parsing results into a unified internal data structure to ensure consistency in subsequent processing.

[0089] Based on the system version information collected in step S2, the system automatically identifies the target Linux distribution version (such as a domestic Linux distribution V10 or V11). For different versions, the system calls the corresponding rule set to perform differentiated processing on the transaction configuration: For version V10, some API fields may use the old naming convention, and the system needs to perform field name mapping; some validation rules may be more lenient, and the system needs to adjust the validation threshold.

[0090] For version V11, new parameter structures (such as enhanced security policy fields) have been introduced, and the system needs to add default values ​​for these new fields in the configuration; at the same time, V11 may be more stringent in verifying SSL certificates for source addresses, and the system needs to automatically configure the corresponding SSL options.

[0091] Implement the differentiated parameter processing logic described above by using code branches to ensure that the generated configuration is accurately adapted to the target system version and avoid API call failures due to version incompatibility.

[0092] Step S5: API request construction phase.

[0093] Based on the API specifications of the target web update management platform, serialize the transaction configuration into a specific API request payload (such as an HTTP body in JSON format), and set the request headers and timeout parameters.

[0094] Step S6: Transaction execution phase.

[0095] Requests are submitted to the web-based update management platform via the API interface. For transaction creation operations, the web-based update management platform returns a unique transaction identifier for subsequent use. This phase supports four core operations: Create a transaction: Submit a transaction creation request to the web-based update management platform, and receive and record the unique transaction identifier returned by the platform; Enable Transaction: Submit an enable request to the platform based on the transaction identifier to enable the push function of the corresponding update transaction; Disable transaction: Submit a disable request to the platform based on the transaction identifier to disable the push function of the corresponding update transaction; Delete transaction: Submit a deletion request to the platform based on the transaction identifier to delete the corresponding update transaction.

[0096] Step S7: Response processing phase.

[0097] The system parses the HTTP response status code and response body; If the response status code is in the 2xx series and the business status field in the response body indicates success, the operation is considered successful, and the transaction identifier is extracted and recorded for subsequent use. If the response status code is not from the 2xx series, or the business status field indicates failure, the operation is deemed to have failed. The system extracts the error information from the response body and, in conjunction with the error handling module's strategy, outputs detailed reasons for the failure and suggested actions to the user.

[0098] Step S8: Result Feedback Phase.

[0099] The system provides users with detailed feedback on the execution results.

[0100] For successful operations, the execution result feedback information includes: transaction name, transaction identifier, creation time, number of target machines, list of included software packages, and other summary information.

[0101] For failed operations, the execution result feedback information includes: error type, error details, possible root cause analysis, and suggested corrective actions.

[0102] At this point, the transaction creation process is complete for typical operational scenarios. Users can then proceed with operations such as enabling, disabling, or deleting transactions as needed.

[0103] Step S9: Test Integration Phase (for automated testing scenarios).

[0104] When this system is integrated into a CI / CD pipeline or automated testing framework, the following operations are performed after the transaction is created and enabled: Step S91: Test triggered.

[0105] After a transaction is created and enabled, the system passes the created transaction identifier to the automated testing framework (such as pytest or JUnit). The automated testing framework queries the corresponding transaction configuration based on the transaction identifier and triggers pre-written update function test cases.

[0106] Step S92: Status polling.

[0107] The system polls the web-based update management platform to query the transaction execution status using the transaction identifier. The polling interval is configurable (e.g., once every 30 seconds) until the transaction status changes to "completed" (indicating that the update push has ended) or a preset timeout threshold is reached (e.g., 30 minutes). If a timeout occurs, the system determines it as abnormal and triggers an alarm.

[0108] Step S93: Results collection.

[0109] After the automated testing framework completes its execution, the system collects the test results it returns (pass rate / failure rate, details of failed test cases).

[0110] Step S94: Associate storage.

[0111] The system associates and stores the complete configuration information of this transaction (transaction name, target machine, package list, source address, etc.) with the test results, making it easy to trace the complete configuration parameters corresponding to a specific test case later.

[0112] Step S95: Environmental cleanup.

[0113] After testing, the system automatically performs environment cleanup, automatically checking transaction status. If a transaction is enabled, it first disables the transaction and then deletes it; if a transaction is disabled, it directly deletes it, clearing any residual data in the test environment. This automated cleanup mechanism avoids the risk of omissions associated with manual cleanup, ensuring the purity of the test environment.

[0114] Step S96: Unified Feedback.

[0115] The system returns the integrated execution result to the caller (such as the Jenkins CI system), in the format of: transaction configuration summary + test execution result + cleanup status.

[0116] The above process forms a closed loop of "configuration → execution → verification → cleanup → traceability", achieving seamless integration of update transaction management and automated testing.

[0117] Step S10: Log recording phase.

[0118] All operations (including test integration operations) are recorded in the log storage and linked with the external web-based update management platform log system to ensure full traceability.

[0119] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A Linux operating system update transaction automation configuration method, characterized in that, include: Step S1, System Initialization Phase: Initialize the parameter template library and set the default API connection parameters. The parameter template library stores predefined JSON template files, which have a multi-level nested structure. Step S2, Parameter Input Processing Stage: Receive command-line parameters input by the user, parse the command-line parameters, read the user-specified configuration file to obtain configuration file parameters, automatically collect Linux system environment information to obtain system collection parameters; the command-line parameters include transaction name, configuration file name, machine information, package list, and source address configuration; Step S3, Parameter Fusion Verification Stage: Execute the multi-source parameter fusion algorithm to merge command line parameters, configuration file parameters, system-collected parameters, and template default parameters according to a preset priority order to obtain the parameter fusion result, and perform parameter format verification and parameter conflict detection on the parameter fusion result; Step S4, Template Application Stage: Load the specified JSON template file, map the merged parameter results to the corresponding nodes of the specified JSON template, and generate a complete transaction configuration; Step S5, API Request Construction Phase: Construct the API request payload according to the transaction configuration, and set the request header and timeout parameters. The API request payload is serialized data that conforms to the API specification of the Web-based update management platform. Step S6, Transaction Execution Phase: Submit API request payload to the Web-based update management platform via API interface, and perform operations such as creating a transaction, enabling a transaction, disabling a transaction, or deleting a transaction; Step S7, Response Processing Stage: Parse the response status code and response body of the Web-based update management platform, determine whether the operation was successful or not based on the HTTP response status code and the business status field in the response body, and obtain the execution result feedback information; Step S8, Result Feedback Stage: Provide the user with execution result feedback information, including success information, error details, and suggested actions; Step S9, Test Integration Phase: When this method is integrated into an automated test scenario and a transaction creation or transaction enable operation is performed, after the transaction is successfully executed, the transaction identifier is passed to the automated test framework to trigger the execution of test cases, test results are collected, transaction configuration is associated with test results and stored, and transaction cleanup operations are automatically performed after the test is completed. Step S10, Log Recording Stage: Record the operations performed in each of the above steps to the log storage and link it with the Web-based update management platform to ensure traceability of the entire process.

2. The method for Linux operating system update transaction automation configuration according to claim 1, characterized in that, The automatic collection of Linux system environment information includes: Obtain the MAC address using Linux system commands; Obtain package list information using the Linux package manager; Automatically identifies IP address, network configuration, and system version information.

3. The method for Linux operating system update transaction automation configuration according to claim 1, characterized in that, The preset priority order is as follows: Command line parameters > Configuration file parameters > System collection parameters > Template default parameters.

4. The method of claim 1, wherein, The parameter format validation includes: checking whether all required fields have been assigned values, checking whether the length of string parameters exceeds the limit, checking whether numeric parameters are within the valid range, and checking whether enumerated parameter values ​​are in the allowed list; The parameter conflict detection includes: checking whether the same machine is specified repeatedly, checking whether the package dependency is satisfied, and checking whether the source address is reachable; If an illegality or conflict is detected, the process will be terminated immediately and a detailed error report will be output to guide the user in making corrections.

5. The Linux operating system update transaction automation configuration method of claim 1, wherein, Step S4 also includes source address resolution: Intelligent parsing of source address parameters, which include a complete source address and optional additional attributes, including one or more of type identifier, priority identifier, and source repository type identifier; The system automatically identifies and standardizes the input format, then fills the parsed complete source address and additional attributes into the source address configuration node of the transaction configuration.

6. The method of claim 1, wherein, Step S4 also includes Linux distribution compatibility adaptation: Based on the system version information collected in step S2, the target Linux distribution version is automatically identified; For different distribution versions, the corresponding rule sets stored in the parameter template library are called to perform differentiated processing on the transaction configuration, dynamically adjusting the parameter structure and verification logic. The rule sets are stored in the form of code branches or configuration mapping tables to ensure that the generated configuration is accurately adapted to the target system version.

7. The method of claim 1, wherein the Linux operating system update transaction automation configuration method is characterized by, The transaction execution in step S6 includes four core operations: Create a transaction: Submit a transaction creation request to the web-based update management platform, and receive and record the unique transaction identifier returned by the platform; Enable Transaction: Submit an enable request to the web-based update management platform based on the transaction identifier to enable the push function for the corresponding update transaction; Disable transaction: Submit a disable request to the web-based update management platform based on the transaction identifier to disable the push function of the corresponding update transaction; Delete transaction: Submit a deletion request to the web-based update management platform based on the transaction identifier to delete the corresponding update transaction.

8. A method for automating transaction configuration updates in a Linux operating system according to claim 1, characterized in that, The execution result feedback information includes: Parsing HTTP response status codes and response bodies; If the response status code is in the 2xx series and the business status field in the response body indicates success, the operation is considered successful, and the transaction identifier is extracted and recorded for subsequent use. If the response status code is not from the 2xx series, or the business status field indicates failure, the operation is deemed to have failed. The system extracts the error information from the response body and, in conjunction with the error handling module's strategy, outputs detailed reasons for the failure and suggested actions to the user.

9. A method for automating transaction configuration updates in a Linux operating system according to claim 1, characterized in that, Step S9 specifically includes: Step S91, Test Trigger: Pass the created transaction identifier to the automated testing framework to trigger the execution of the corresponding update function test cases; Step S92, Status Polling: Poll the Web-based update management platform to monitor the transaction execution status until it changes to the completed status or reaches the preset timeout threshold; Step S93, Result Collection: Collect the test execution results returned by the automated testing framework, including the test pass / fail status and details of failed test cases; Step S94, Associated Storage: Associate the complete configuration information of this transaction with the test execution results for storage; Step S95, Environment Cleanup: After the test is completed, the transaction status is automatically checked. If the transaction is enabled, the transaction is disabled first, and then the transaction is deleted. If the transaction is disabled, the transaction is deleted directly to clear the residual data in the test environment. Step S96, Unified Feedback: Return the integrated execution results to the caller, including transaction configuration summary, test execution results and cleanup status, forming a closed loop of the entire chain of "configuration → execution → verification → cleanup → traceability".

10. A Linux operating system update transaction automated configuration system, which is connected to a web-based update management platform and an automated testing framework, characterized in that... include: The user interface layer provides a command-line interface, a configuration file interface, and a system environment collection interface. It receives command-line parameters and configuration file parameters input by the user, and automatically collects Linux system environment information to obtain system collection parameters. The system collection parameters include system version information; the command-line parameters include transaction name, configuration file name, machine information, package list, and source address configuration. The core processing layer, connected to the user interface layer, integrates a parameter template management module, a multi-source parameter fusion engine, an intelligent source address parsing engine, a version compatibility adaptation layer, and a test automation integration module. It loads predefined JSON template files, merges command-line parameters, configuration file parameters, system-collected parameters, and template default parameters according to a preset priority order to obtain the parameter merging result, verifies the parameter format and detects parameter conflicts in the merged result, maps the merged result to the corresponding node in the JSON template file to generate a complete transaction configuration, intelligently parses the source address parameters to identify and standardize the complete source address and additional attributes, and calls the corresponding rule set based on the system version information to perform differentiated processing of the transaction configuration. The data persistence layer, connected to the core processing layer, consists of a template library, configuration cache, and log storage. It is responsible for the persistent storage and management of template data, cached data, and system logs, and enables connection with the log system of the external web-based update management platform. The API communication layer, connected to the core processing layer, integrates a request construction module, a response processing module, and an error handling module. It is used to construct an API request payload that conforms to the API specification of the Web-based update management platform according to the transaction configuration, and set request headers and timeout parameters. It submits the API request payload to the Web-based update management platform through the API interface to perform operations such as creating a transaction, enabling a transaction, disabling a transaction, or deleting a transaction. It also parses the response status code and response body of the Web-based update management platform, determines the success or failure of the operation based on the HTTP response status code and the business status field in the response body, and obtains the execution result feedback information. The test integration layer connects with the core processing layer and the automated testing framework, providing test framework interfaces and test template libraries. It is used to pass the transaction identifier to the automated testing framework after successful transaction execution to trigger test case execution, collect test results, associate and store transaction configurations with test results, and automatically perform transaction cleanup operations after the test is completed.

Images