Method and device for detecting operating system

Abstract

The invention discloses a method and a device for detecting an operating system, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: acquiring identification information of a to-be-detected server; according to the identification information and a pre-configured storage path, a detection script corresponding to the to-be-detected server is obtained, the detection script comprises a plurality of detection instructions, and each detection instruction corresponds to one or more detection parameters associated with an operating system; sending the detection script to the to-be-detected server, and obtaining a detection parameter returned by the to-be-detected server after running the detection script; verifying the performance state of the operating system of the to-be-detected server according to the detection parameters; and under the condition that the performance state does not pass verification, distributing a repair script to the to-be-detected server, so that the to-be-detected server runs the repair script to repair the performance state of the operating system. According to the embodiment, the detection efficiency of the operating system is improved, the workload of operation and maintenance personnel is reduced, and the consistency of the operating system can be maintained.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for detecting an operating system. Background Technology

[0002] As enterprises expand and deploy in multiple regions, it becomes necessary to deploy Linux operating systems on servers in different regions. Furthermore, it is required that the operating systems in multiple regions maintain consistent performance and stability under different geographical and network environments. Therefore, after deploying the operating system, it is usually necessary to perform batch testing of the operating system on servers in multiple regions.

[0003] Currently, Linux operating systems on different servers are typically tested manually. This results in low testing efficiency for Linux systems, and manual testing is prone to errors. Furthermore, a large number of scripts need to be written to meet various testing requirements, leading to a large number of scripts that are difficult to manage. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide an operating system detection method and apparatus. By managing and distributing detection scripts to servers under test through a central server, automatic batch detection of operating systems on multiple servers under test is achieved, improving the detection efficiency. Furthermore, each server under test can use a common detection script, eliminating the need to write separate scripts for each server, further improving detection efficiency and facilitating script management. Additionally, if the central server detects that the operating system performance status of a server under test has failed verification, it can automatically repair the performance status by distributing repair scripts to the server under test, thereby reducing the workload of maintenance personnel and contributing to maintaining operating system consistency.

[0005] To achieve the above objectives, according to one aspect of the present invention, an operating system detection method is provided. The operating system detection method of the present invention can be applied to a central server and includes: acquiring identification information of at least one server to be detected;

[0006] Based on the identification information and the pre-configured storage path, obtain the detection script corresponding to at least one server to be detected. The detection script includes multiple detection instructions, each of which corresponds to one or more detection parameters associated with the operating system.

[0007] Send the detection script to each server to be detected, and obtain the detection parameters returned by each server after running the detection script;

[0008] Verify the performance status of the operating system of the server under test based on the test parameters;

[0009] If the performance status fails verification, a repair script is distributed to the server under test, causing the server to run the repair script to repair the operating system's performance status.

[0010] Optionally, if the performance status fails to pass verification, the following also applies:

[0011] Identify the target servers that failed verification, and the target detection parameters that failed verification within those target servers;

[0012] Determine the fault type based on the target detection parameters, and select the repair script corresponding to the fault type;

[0013] Distribute the repair script to the server to be tested, including: distributing the repair script to the target server to be tested.

[0014] Optionally, after distributing the repair script to the target server to be detected, the following may also be included:

[0015] Send the detection script to the target server again to obtain the target detection parameters of the target server;

[0016] The performance status of the operating system of the target server to be detected is verified again based on the target detection parameters.

[0017] If the performance status of the operating system of the target server to be tested fails the verification, a manual intervention prompt message will be issued.

[0018] Optionally, based on the identification information and the pre-configured storage path, a detection script corresponding to at least one server to be detected is obtained, including:

[0019] Based on the identification information, identify multiple functions to be tested corresponding to each server to be tested;

[0020] Based on the pre-configured storage path, determine the script function module corresponding to each function to be detected. The script function module encapsulates the detection instructions corresponding to the function to be detected.

[0021] The script modules corresponding to multiple functions to be tested are assembled to form a testing script.

[0022] Optionally, the detection script is sent to each server to be detected, and the detection parameters returned by each server after running the detection script are obtained, including:

[0023] Based on the identification information corresponding to each server to be tested, determine the forward filtering strategy and the reverse filtering strategy corresponding to the server to be tested.

[0024] The detection scripts are distributed to each server to be detected according to the forward filtering strategy, and the detection parameters of the server to be detected are obtained according to the reverse filtering strategy.

[0025] Optionally, the detection script is sent to each server to be detected, including:

[0026] The detection script is distributed to each server to be detected using a data mirroring backup tool.

[0027] Optionally, before obtaining the identification information of at least one server to be detected, the method further includes:

[0028] Configure the storage path for the detection scripts; store the detection scripts according to the storage path, and add the storage path to the environment variables of the central server so that the detection scripts can be called according to the storage path;

[0029] Optionally, before obtaining the identification information of at least one server to be detected, the method further includes: establishing a communication connection with the server to be detected via an SSH key pair.

[0030] To achieve the above objectives, according to another aspect of the present invention, an operating system detection device is provided. The operating system detection device of the present invention, applicable to a central server, includes: an information acquisition module, a script distribution module, a status verification module, and a repair module; wherein,

[0031] The information acquisition module is configured to acquire the identification information of at least one server to be detected;

[0032] The script distribution module is configured to: obtain a detection script corresponding to at least one server to be detected based on the identification information and the pre-configured storage path. The detection script includes multiple detection instructions, and each detection instruction corresponds to one or more detection parameters associated with the operating system.

[0033] The status verification module is configured to: send the detection script to each server to be tested, and obtain the detection parameters returned by each server after running the detection script; and verify the performance status of the operating system of the server to be tested based on the detection parameters.

[0034] The repair module is configured to: distribute a repair script to the server under test if the performance status fails verification, and cause the server under test to run the repair script to repair the performance status of the operating system.

[0035] To achieve the above objectives, according to another aspect of the present invention, a server for detecting an operating system is provided. An embodiment of the present invention provides a server for detecting an operating system, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a detection method according to the present invention.

[0036] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is provided. One such computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements a detection method according to an embodiment of the present invention.

[0037] To achieve the above objectives, according to another aspect of the present invention, a computer program product is provided, including a computer program that, when executed by a processor, implements a detection method according to an embodiment of the present invention.

[0038] One embodiment of the above invention has the following advantages or beneficial effects: The central server obtains the detection script corresponding to the server to be tested according to the pre-configured storage path, and sends the detection script to each server to be tested. The detection script includes multiple detection instructions, each of which corresponds to one or more detection parameters associated with the operating system. This allows each server to be tested to obtain the detection parameters associated with the operating system by running the detection script and return the detection parameters to the central server. The central server verifies the performance status of the operating system of the server to be tested based on the detection parameters. If the performance status fails verification, a repair script is distributed to the server to be tested, allowing the server to run the repair script to repair the performance status of the operating system. Thus, by managing and distributing the detection script to the servers to be tested through the central server, automatic batch detection of the operating system on multiple servers to be tested is achieved, improving the detection efficiency of the operating system. Furthermore, each server to be tested can use a common detection script without needing to write its own script for each server, which further improves the detection efficiency of the operating system and facilitates the management of the detection script. In addition, if the central server detects that the operating system performance status of the server under test has failed verification, it can automatically repair the performance status by distributing repair scripts to the server under test, thereby reducing the workload of operation and maintenance personnel and also helping to maintain the consistency of the operating system.

[0039] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0040] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0041] Figure 1 This is a schematic diagram of the architecture of an operating system detection system according to an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the main steps of an operating system detection method according to an embodiment of the present invention;

[0043] Figure 3 This is a schematic diagram of the main steps of another operating system detection method according to an embodiment of the present invention;

[0044] Figure 4 This is a schematic diagram of the main modules of an operating system detection device according to an embodiment of the present invention;

[0045] Figure 5 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0046] Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0047] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0048] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0049] Operating systems (such as Linux) require a series of tests before delivery to ensure their stability and reliability. To improve the efficiency of operating system testing, this invention provides a method for detecting operating systems, enabling batch testing through the automated execution of testing scripts.

[0050] Figure 1 A schematic diagram of the architecture of a detection system for detecting an operating system according to an embodiment of the present invention is shown. Figure 1As shown, the detection system for detecting operating systems mainly includes a central server A1 and multiple servers B1-Bn to be tested. The central server A1 is configured with a standard script code structure. When it is necessary to detect the operating system on the servers B1-Bn, the central server A1 can generate the corresponding detection script based on the standard script code structure according to the detection requirements. For example, when it is necessary to detect data such as CPU usage, disk space, database, and middleware during the operation of the operating system on the servers to be tested, the central server A1 can assemble different script function modules according to different detection parameters to generate the detection script.

[0051] In this embodiment of the invention, the script code structure in the central server A1 includes a general function module a1, a detection function classification module a2, a configuration file module a3, a repair function module a4, and a detection result module a5.

[0052] The general-purpose module a1 forms the foundation of the script code structure. It contains the basic functions used to drive the code execution flow and is responsible for implementing common functions such as log management, numerical comparison, and file inspection. For example, the general-purpose module a1 defines how to record log information, how to compare whether two values ​​are equal, and how to verify the existence of a file. These basic functions provide unified methods and tools for other modules, ensuring code consistency and maintainability.

[0053] The detection function classification module a2 is configured as a tool to check operating system characteristics. This module is equipped with various detection methods to verify whether various aspects of the operating system meet the expected configuration or state. For example, it can check the type and capacity of the file system, confirm whether the kernel version is up-to-date, and whether the configuration file settings are correct. To achieve these functions, the detection function classification module a2 typically includes the following parts: File system detection—checking the type, capacity, and other related attributes of the file system by calling a series of functions; Kernel version detection—obtaining the current kernel version information of the operating system by calling commands, and then comparing this information with the known latest kernel version to determine whether an update is needed; Configuration file detection—reading and parsing the system configuration file, checking whether the various settings in it meet the predetermined standards, and prompting for modification if any non-compliant configuration items are found; Other system characteristic detection—adding detection functions for other system characteristics, such as hardware device status, network connectivity, etc., can be added as needed. According to the above description, by using the detection function classification module a2, potential problems can be discovered and resolved in a timely manner, ensuring the stable operation of the operating system.

[0054] The configuration file module a3 contains a series of standard system configuration values, which are set according to the system's best practices and performance requirements and are used to compare and verify with the actual system configuration values ​​in operation.

[0055] The configuration file module a3 can be divided according to different functions, such as network settings, security policies, and user permissions. Each part stores corresponding configuration parameters to verify various aspects of the operating system. During batch testing of the operating system, these predefined standard values ​​serve as benchmarks to evaluate the accuracy and completeness of the operating system configuration. If the actual configuration is found to be inconsistent with the standard values, anomalies can be marked. In the event of a configuration anomaly, a series of remedial measures can be executed to restore the operating system to a normal working state. For example, a repair script can automatically repair the operating system's performance, or a notification mechanism can be triggered for manual intervention by the administrator. Furthermore, to track configuration changes and prevent unauthorized modifications, the configuration file module a3 can implement version control, ensuring that every configuration change is recorded and traceable to a specific point in time and responsible party. All configuration standards and changes are documented in detail for subsequent maintenance and auditing. Through these methods, the configuration file module a3 not only facilitates correct operating system configuration but also provides strong support for the stable operation of the operating system.

[0056] The repair module a4 is used to detect and resolve abnormal operating system configuration issues. It provides a series of repair methods, taking problematic detection parameters or configuration information as input and calling the corresponding functions of the repair scripts to fix the problems. This allows the script code structure system to not only diagnose problems in the operating system, but also provide corresponding repair scripts to automatically repair the performance of the operating system, so that the operating system meets the expected configuration standards.

[0057] Specifically, the repair module a4 can identify the fault type based on detected abnormal detection parameters or abnormal configuration information, such as incorrect configuration parameters, improper permission settings, or component version discrepancies. Then, the repair module a4 can provide corresponding repair methods based on the fault type, such as providing automatic repair scripts, manual repair steps, or recommending the use of specific tools to resolve the problem. Users can choose to execute the provided repair methods automatically or manually. If automatic repair is selected, the repair module a4 will invoke the repair script to automatically repair the corresponding problem; if manual repair is selected, users will receive detailed guidance steps to manually resolve the problem. After the repair is completed, the repair module a4 can also re-detect the operating system configuration. If unresolved problems still exist, it can issue a manual intervention prompt, which may include further repair suggestions to ensure all problems are resolved.

[0058] The detection results module a5 automatically collects the detection results of each server after each test. Examples of detection results include key parameters such as CPU usage, memory consumption, and disk space. Each detection result records detailed information about the checks performed, including the test time, the name of the server under test, the server IP address, and specific values. After collecting the detection results, the detection results module a5 can format the data uniformly, ensuring that various data types are stored with the same structure, facilitating subsequent data analysis and processing. Furthermore, the formatted data is securely stored in a database and files for easy access and analysis, enabling subsequent problem analysis, test case optimization, and operating system quality improvement. This, in turn, helps identify potential problems and make corresponding adjustments, ultimately improving the overall performance and stability of the operating system.

[0059] In addition, the central server can be configured with a detection report module (not shown), which is responsible for managing and storing the detection results of batch servers. It can acquire data from multiple sources and integrate them onto a unified platform. Furthermore, the detection report module can generate detailed detection reports based on the collected data, helping administrators to more intuitively understand the system's operational status. Moreover, by summarizing and analyzing data from multiple servers under test, the detection report module enables administrators to grasp the overall stability and reliability of the operating system, thereby facilitating the timely identification and resolution of problems that may affect the entire system.

[0060] In addition, the central server can be configured with a temporary file storage module (not shown) to store temporary files generated during the execution of automated tests, in order to maintain the cleanliness and order of the entire operating environment and avoid unnecessary chaos.

[0061] Each of the above modules can be implemented using the Shell language, thus directly leveraging Linux command-line tools and scripting capabilities to simplify the writing and debugging of test code. This also gives the Linux operating system's batch testing code framework good flexibility, maintainability, and scalability. Furthermore, the framework supports customization and extension to meet the requirements of different testing needs and scenarios.

[0062] Based on the script code structure of the central server configuration described above, this embodiment of the invention provides a method for detecting an operating system, such as... Figure 2 As shown, this detection method can be applied to a central server and mainly includes the following steps S201-S205:

[0063] Step S201: Obtain the identification information of at least one server to be detected.

[0064] For example, the identification information of the server to be tested can be its IP address and / or hostname. The central server can obtain the identification information of the server to be tested by inputting the IP address and hostname of the server to be tested, or by selecting the identifier of the server to be tested from an existing list of servers. The server to be tested can be a single server or multiple servers. In this embodiment of the invention, to improve detection efficiency, multiple servers are generally used to achieve batch detection of the operating system on the server.

[0065] In some embodiments, the central server can establish a communication connection with the server under test via an SSH (Secure Shell) key. For example, an SSH key pair, including an SSH public key and an SSH private key, is generated on the central server. The central server can securely distribute the SSH public key from the SSH key pair to each server under test, allowing the server to obtain the SSH public key upon initialization. When the server under test establishes a connection with the central server, SSH public key authentication enables login to the central server without manually entering a password, thus establishing a communication connection between the server under test and the central server. This approach not only improves the security of communication between the central server and the servers under test but also facilitates efficient and secure management of multiple servers under test through the central server, thereby improving operational efficiency.

[0066] It is understandable that the central server can establish a communication connection with the server under test either before or after obtaining the identification information. For example, the central server can pre-establish communication connections with all the servers under test that it manages, such as attempting to connect to all the servers under test based on an SSH key pair to achieve passwordless login. After obtaining the identification information, the central server determines the server to be tested in this instance from the servers with established communication connections, and then performs batch testing on its operating system. Alternatively, the central server can also establish a communication connection with the server under test in this instance based on an SSH key pair after obtaining the identification information of the server under test in this instance.

[0067] Step S202: Based on the identification information and the pre-configured storage path, obtain the detection script corresponding to at least one server to be detected. The detection script includes multiple detection instructions, and each detection instruction corresponds to one or more detection parameters associated with the operating system.

[0068] In this embodiment of the invention, before performing batch testing on the operating system of the server to be tested, the storage path of the testing script can be configured in advance in the central server, and the testing script, the various script function modules used to compose the testing script and / or the repair script can be stored according to the storage path. The storage path can be added to the environment variables of the central server so that the testing script and / or repair script can be called / assembled according to the storage path during the testing process.

[0069] For example, first, select a suitable directory in the file system as the storage path to store the detection scripts. For instance, create a directory named ` / opt / insbaseline` and use the `chmod` command to set appropriate permissions for this storage path, ensuring that only authorized users or services can access and execute the detection scripts stored there. For example, use the command `sudo chmod 755 / opt / insbaseline` to grant the administrator read, write, and execute permissions to the detection scripts stored in this directory, while other users only have read and execute permissions. Then, add the storage path of the detection scripts to the PATH environment variable of the central server. Thus, regardless of the current working directory, the central server can directly call the detection scripts via the command line according to the storage path. For example, this can be done by editing the shell configuration file and adding the following line: `export PATH=$PATH: / opt / insbaseline`, to add the storage path of the detection scripts to the PATH environment variable. The changes will take effect after reloading the configuration file or restarting the central server.

[0070] By pre-configuring the storage path of the detection scripts, the central server can invoke the scripts according to the pre-configured storage path during batch detection. The detection scripts include multiple detection instructions, each corresponding to one or more detection parameters associated with the operating system. In other words, the detection instructions can detect operating system parameters. For example, the detection scripts can be used to collect system information, run diagnostic tests, or perform other specific tasks, and may include detection instructions corresponding to parameters such as CPU utilization, memory usage, disk space, kernel version, component version, and installers. When the central server distributes the detection scripts to the servers to be tested, the servers running the scripts automatically collect various system information and performance indicators of their operating systems, such as CPU utilization, memory usage, disk space, kernel version, component version, and installers.

[0071] Specific detection parameters can be configured according to actual detection needs and objectives, and correspondingly, the detection script can also be assembled according to actual detection needs and objectives. Specifically, in this embodiment of the invention, the detection script adopts a modular design to decompose the detection task into multiple small, manageable modules. Each module is responsible for a specific function; for example, detection parameters such as CPU, component version, or time synchronization correspond to different modules, and each module can be executed independently. Therefore, modules can be added, deleted, or modified according to actual needs and objectives without affecting the functionality of other modules, thereby assembling detection scripts adapted to different detection needs and objectives.

[0072] Based on the above modular script design, in this embodiment of the invention, the central server can determine the server to be detected according to the identification information, and determine multiple functions to be detected corresponding to the server to be detected; then, according to the pre-configured storage path, it determines the script function module corresponding to each function to be detected, and the script function module encapsulates the detection instructions corresponding to the function to be detected; the script functions corresponding to multiple functions to be detected are assembled to form a detection script.

[0073] For example, if the server under test is configured with components such as a database and middleware, then the functions to be tested can be determined, including the collection of database and middleware versions. Additionally, operating system testing typically involves collecting parameters such as operating system version, kernel, hostname, IP address, and configuration file information. Therefore, the central server, based on a modular script design, determines the corresponding script function modules according to each function to be tested, and assembles these modules to form the testing script. This modular design results in a clear script code structure; if a function module malfunctions, only the problematic module needs to be addressed, without affecting the entire test script, thus facilitating understanding and maintenance. Furthermore, by encapsulating commonly used testing parameters (such as operating system version, kernel, hostname, and IP address) into modules, the testing instructions can be reused in different test scripts, reducing the workload of repetitive code writing. Since each script function module is relatively independent, each module can be tested individually to ensure its proper functioning, thereby improving the overall quality of the test script.

[0074] It is understood that, in this embodiment of the invention, when the central server assembles the detection script according to the script function modules, it can assemble a corresponding detection script for each server to be detected based on the different functions to be detected corresponding to different servers to be detected, so as to perform personalized detection for different servers to be detected. Alternatively, the central server can also assemble the detection script according to the needs of the server to be detected with the most / most complete functions to be detected, so that each server to be detected can collect the detection parameters corresponding to each function to be detected by running a unified detection script. For functions to be detected that do not exist, null or other characteristic characters indicating that the function to be detected does not exist are returned. The central server can determine that the server to be detected does not have the corresponding function to be detected based on the return value, and will not verify the performance status of the server to be detected based on the return value.

[0075] In addition, in this embodiment of the invention, a suitable programming language (such as Python, shell, etc.) can be used to write a detection script according to the detection needs of the server to be detected. This allows the server to execute system commands or call APIs to obtain the required information, such as system version, kernel, hostname, important component version, configuration file information, and other detection parameters, by running the detection script. These detection parameters are then sent back to the central server for centralized processing.

[0076] Step S203: Send the detection script to each server to be detected, and obtain the detection parameters returned by each server after running the detection script.

[0077] After the detection script is generated, it can be distributed to each server to be tested using a data mirroring backup tool. In this embodiment of the invention, the rsync tool can be used to quickly and efficiently distribute the detection script from the central server to each server to be tested, thereby enabling each server to run the detection script to automatically collect operating system-related detection parameters and return the detection parameters to the central server.

[0078] Furthermore, in this embodiment of the invention, the central server can also determine the forward filtering strategy and the reverse filtering strategy corresponding to each server to be detected based on the identification information corresponding to each server to be detected; distribute the detection script to each server to be detected according to the forward filtering strategy; and obtain the detection parameters of the server to be detected according to the reverse filtering strategy.

[0079] The forward filtering strategy and the reverse filtering strategy are pre-configured by the central server according to the detection requirements of each server under test. The forward filtering strategy is the filtering strategy when the central server sends files to the server under test, and the reverse filtering strategy is the filtering strategy when the server under test sends data back to the central server. For example, the central server can pre-configure the identification information of each server under test and its corresponding forward and reverse filtering strategies. For example, the central server can configure the forward filtering strategy to avoid repeatedly sending the same code corresponding to the same detection function module to the same server under test, and it can also configure the transmission archiving mode of detection parameters through the reverse filtering strategy. For example, the archive mode, file attribute preservation mode, or compressed transmission mode of detection parameters can be configured through the -avz option of the rsync command, and a specific file or directory to be excluded can be configured through -exclude to store the detection parameters in the specified file or directory.

[0080] For example, if the forward filtering strategy of the central server is configured to avoid sending the code corresponding to the same detection function module twice consecutively, then when the central server distributes the detection script to the server under test after the component version of the server under test is updated, it can send only the detection script that collects the detection parameters corresponding to the component version, without having to send the code corresponding to other detection functions again. This avoids the server under test from repeatedly collecting other unchanged detection parameters, thereby improving detection efficiency.

[0081] For example, when the server under test returns detection parameters to the central server, that is, when the central server obtains the detection parameters from the server under test, a reverse filtering strategy can be used. For instance, if the file corresponding to the detection parameters is larger than a preset file size, the detection parameters can be transmitted according to the compression transmission mode configured in the reverse filtering strategy. Thus, this embodiment of the invention achieves flexible forward and reverse specification of the files to be filtered through forward and reverse filtering strategies, ensuring the reliability and security of file transmission, and improving detection efficiency and file transmission efficiency.

[0082] In addition, forward and reverse filtering strategies are pre-configured on each server under test. The forward filtering strategy is used when the server under test receives files from the central server, while the reverse filtering strategy is used when the server under test sends data back to the central server. Similar to configuring forward and reverse filtering strategies on the central server, configuring them on the servers under test allows for better control. Forward filtering can be configured to avoid repeatedly receiving code corresponding to the same detection function modules, thus preventing the server under test from repeatedly collecting unchanged detection parameters and improving detection efficiency. Furthermore, reverse filtering can be configured to adjust the archiving mode for detection parameter transmission to improve file transfer efficiency.

[0083] Step S204: Verify the performance status of the operating system of the server under test according to the detection parameters.

[0084] Step S205: If the performance status fails verification, distribute the repair script to the server under test, so that the server under test runs the repair script to repair the performance status of the operating system.

[0085] After receiving the detection parameters returned by the server under test, the central server can verify the performance status of the operating system of the corresponding server under test based on the detection parameters. For example, the central server A1 verifies the detection parameters by calling the detection method configured in the detection function classification module a2 based on the standard values ​​configured in the configuration file module a3, thereby verifying the performance status of the operating system of the server under test. Furthermore, the central server A1 can generate a detection report for this detection based on the detection report module. This report includes data such as operational details, system status, and detection results, which can be reviewed by the administrator and used as a basis for auditing and subsequent improvements. If one or more detection parameters do not conform to the standard values, that is, if the detection parameters deviate from their corresponding standard values, the central server can also mark the anomalies in the detection report to centrally and prominently display important information such as the operating system status and the baseline standard status that needs adjustment.

[0086] If the central server determines that the operating system performance status of the server under test has failed verification based on the detection parameters, such as multiple detection parameters in the server under test not conforming to their corresponding standard values, then the operating system performance status of the server under test has failed verification. In this case, the central server can further distribute a repair script to the server under test to repair the operating system performance status. For example, if the detected problem is a known fault type, and a corresponding repair script is pre-configured for this known fault type, the central server can select the repair script corresponding to the fault type and send it to the server under test. Specifically, in this embodiment of the invention, the central server determines the target server under test that has failed verification, and the target detection parameters that have failed verification in the target server under test; determines the fault type based on the target detection parameters, selects the repair script corresponding to the fault type, and then distributes the repair script to the target server under test. The repair script includes all steps and commands to resolve the corresponding fault. After receiving the repair script, the target server under test can automatically call and execute the repair script. This process does not require manual intervention, thereby reducing the workload of maintenance personnel.

[0087] After executing the repair script, the central server sends the detection script to the target server again to obtain the target detection parameters. Then, based on the target detection parameters, it verifies the performance status of the target server's operating system. If the performance status fails verification, a manual intervention prompt is issued. In other words, in this embodiment, after running the repair script, the central server checks again whether the fault on the target server has been repaired. If the fault persists, the central server provides a further manual intervention prompt so that maintenance personnel can address the relevant faults promptly. Throughout this process, regardless of whether the repair is successful or not, the central server logs the entire process, including the fault type, the executed test and repair scripts, and the final result, to aid in subsequent analysis and improvement.

[0088] Additionally, the central server can create a dedicated directory within its file system to store log reports generated during the operating system detection process. For example, a directory named ` / opt / insbaseline / log` can be created to store these log reports, ensuring that only authorized users or services can access and write to this directory. Ownership can be set using the `chown` command, and appropriate permissions can be set using the `chmod` command. This stores the generated log reports in the specified directory while ensuring that only authorized users or services can access them, facilitating the review of the detection process and aiding in future improvements.

[0089] The following example illustrates the operating system detection method provided in this embodiment of the invention, which involves batch testing of the Linux systems on multiple servers under test via a central server to ensure that each server meets predetermined baselines and configuration standards. Figure 3 As shown, the method may include the following steps:

[0090] Step S301: Initialize the detection environment.

[0091] Configure the central server for the deployed detection system, clear logs, and configure the IP list to ensure that the central server's network environment allows for passwordless, one-way SSH connections to all servers under test that have Linux operating systems installed. The central server's detection system is used for batch detection of the operating systems of multiple servers under test.

[0092] Step S302: Define the baseline and configuration criteria.

[0093] Based on delivery requirements, determine baseline requirements for the Linux operating system, such as the version and purpose, including specific kernel versions, pre-installed package versions and configuration parameters, network settings, and security policies.

[0094] Step S303: Perform batch testing.

[0095] Specifically, the process for performing batch testing can be found in [reference needed]. Figure 2 The operating system detection method is as follows: After the central server obtains the identification information of each server to be tested, it establishes a communication connection with the server based on the SSH key. Then, the central server retrieves the detection script from a pre-configured storage path and distributes the script to each server to obtain the detection parameters returned by the server after running the script. In other words, during batch testing, instructions can be initiated from the central server to execute pre-prepared detection scripts and tools on all servers running Linux. To improve detection efficiency, the central server can distribute detection scripts and tools to multiple servers in parallel. After receiving the scripts and tools, each server can execute its own detection process in parallel and then return the detection parameters to the central server. This means that during batch testing, the detection processes of each server are parallel, preventing interference between servers and improving efficiency. Furthermore, the execution process can be monitored by the central server and / or testers during batch testing to ensure that each server is detected and the detection script runs correctly. If an error is found in the execution of the detection script on a server under test during the detection process, the detection script can be redistributed to that server so that it can re-execute the detection script to detect the Linux system installed on it.

[0096] Step S304: Collect and analyze the test results.

[0097] After the detection script is executed on the server under test, the detection parameters associated with the Linux system are sent to the central server to collect the detection results. The central server can analyze and organize the detection results, identify target servers that do not conform to the baseline and configuration standards, and record detailed deviation information.

[0098] Step S305: Problem diagnosis and repair.

[0099] For target servers that fail the initial testing, the central server performs in-depth problem diagnosis to determine the specific reasons for configuration deviations and identify the target testing parameters that failed verification. Then, based on the fault type corresponding to the target testing parameters, the central server distributes appropriate repair scripts to the target servers, enabling them to correct the problems and ensuring all servers meet the established standards. Additionally, if no suitable repair script is available, or if the performance of the target server still fails verification after running the repair script, manual intervention can be used to fix the corresponding problems, ensuring all servers meet the established standards.

[0100] Step S306: Generate a test report.

[0101] Based on the collected data and problem-solving status, the central server generates a detailed test report. The report should include the test results for each server under test, the problems found, and the remedial measures taken.

[0102] Step S307: Final acceptance.

[0103] The central server performs another test on the Linux system in the repaired server to verify whether the problem has been completely resolved. After the final acceptance is completed, the system can be marked as ready and await delivery.

[0104] Furthermore, continuous monitoring and maintenance of the operating system can be performed after this testing. For example, regular configuration and security checks can be conducted to ensure the system continues to meet standards. In summary, this batch testing process ensures that the Linux system not only meets delivery requirements before delivery but also maintains high standards of security and consistency, avoiding unforeseen problems and risks in the production environment.

[0105] According to an embodiment of the present invention, an operating system detection method involves a central server retrieving a detection script corresponding to a server under test based on a pre-configured storage path and sending the detection script to each server under test. The detection script includes multiple detection instructions, each corresponding to one or more detection parameters associated with the operating system. This allows each server under test to obtain the detection parameters associated with the operating system by running the detection script and return these parameters to the central server. The central server verifies the performance status of the operating system of the server under test based on the detection parameters. If the performance status fails verification, a repair script is distributed to the server under test, enabling it to run the repair script to repair the operating system's performance status. Thus, by managing and distributing detection scripts to servers under test through the central server, automatic batch detection of operating systems on multiple servers under test is achieved, improving the detection efficiency. Furthermore, each server under test can use a common detection script without needing to write its own script for each server, further improving the detection efficiency and facilitating script management. In addition, if the central server detects that the operating system performance status of the server under test has failed verification, it can automatically repair the performance status by distributing repair scripts to the server under test, thereby reducing the workload of operation and maintenance personnel and also helping to maintain the consistency of the operating system.

[0106] Based on the same inventive concept as the above embodiments, this embodiment of the invention also provides an operating system detection device, which can be applied to a central server; such as Figure 4 As shown, the detection device 400 includes: an information acquisition module 401, a script distribution module 402, a status verification module 403, and a repair module 404; wherein,

[0107] The information acquisition module 401 is configured to acquire the identification information of at least one server to be detected;

[0108] The script distribution module 402 is configured to: obtain a detection script corresponding to at least one server to be detected based on the identification information and the pre-configured storage path. The detection script includes multiple detection instructions, and the detection instructions correspond to one or more detection parameters associated with the operating system.

[0109] The status verification module 403 is configured to: send the detection script to each server to be tested, and obtain the detection parameters returned by each server after running the detection script; and verify the performance status of the operating system of the server to be tested based on the detection parameters.

[0110] The repair module 404 is configured to: distribute a repair script to the server under test if the performance status fails verification, so that the server under test can run the repair script to repair the performance status of the operating system.

[0111] In one embodiment of the present invention, the repair module 404 is configured to, when the performance status fails verification, determine the target server to be tested that has failed verification, and the target detection parameters that have failed verification in the target server to be tested; determine the fault type according to the target detection parameters, and select a repair script corresponding to the fault type; and distribute the repair script to the target server to be tested.

[0112] In one embodiment of the present invention, the repair module 404 is further configured to, after distributing the repair script to the target server to be detected, send the detection script to the target server to be detected again to obtain the target detection parameters of the target server to be detected; verify the performance status of the operating system of the target server to be detected again according to the target detection parameters; and issue a manual intervention prompt message if the performance status of the operating system of the target server to be detected fails the verification.

[0113] In one embodiment of the present invention, the script distribution module 402 is configured to determine multiple functions to be detected corresponding to each server to be detected based on the identification information; determine the script function module corresponding to each function to be detected based on the pre-configured storage path, wherein the script function module encapsulates the detection instructions corresponding to the function to be detected; and assemble the script function modules corresponding to multiple functions to be detected to form a detection script.

[0114] In one embodiment of the present invention, the script distribution module 402 is configured to determine the forward filtering strategy and the reverse filtering strategy corresponding to each server to be detected based on the identification information corresponding to each server to be detected; distribute the detection script to each server to be detected according to the forward filtering strategy; and obtain the detection parameters of the server to be detected according to the reverse filtering strategy.

[0115] In one embodiment of the present invention, the script distribution module 402 is further configured to distribute the detection script to each of the servers to be detected through a data mirroring backup tool.

[0116] In one embodiment of the present invention, the information acquisition module 401 is further configured to: configure the storage path of the detection script; store the detection script according to the storage path, and add the storage path to the environment variables of the central server so as to call the detection script according to the storage path.

[0117] In one embodiment of the present invention, the information acquisition module 401 is further configured to establish a communication connection with the server to be detected via an SSH key pair.

[0118] As can be seen from the operating system detection device provided in the above embodiments, the central server obtains the detection script corresponding to the server to be detected according to the pre-configured storage path, and sends the detection script to each server to be detected. The detection script includes multiple detection instructions, each of which corresponds to one or more detection parameters associated with the operating system. This allows each server to be detected to obtain the detection parameters associated with the operating system by running the detection script and return the detection parameters to the central server. The central server verifies the performance status of the operating system of the server to be detected based on the detection parameters. If the performance status fails verification, a repair script is distributed to the server to be detected, allowing the server to run the repair script to repair the performance status of the operating system. Thus, by managing and distributing the detection script to the servers to be detected through the central server, automatic batch detection of the operating system on multiple servers to be detected is achieved, improving the detection efficiency. Furthermore, each server to be detected can use a common detection script without needing to write its own script for each server, further improving the detection efficiency and facilitating the management of the detection scripts. In addition, if the central server detects that the operating system performance status of the server under test has failed verification, it can automatically repair the performance status by distributing repair scripts to the server under test, thereby reducing the workload of operation and maintenance personnel and also helping to maintain the consistency of the operating system.

[0119] Figure 5 An exemplary system architecture 500 is shown, to which the operating system detection method or operating system detection apparatus of embodiments of the present invention can be applied.

[0120] like Figure 5 As shown, the system architecture 500 may include a central server 501, a network 502, and servers 503, 504, and 505. Network 502 serves as the medium for providing communication links between servers 503, 504, and 505 and the central server 501. Network 502 may include various connection types, such as wired, wireless communication links, or fiber optic cables. Servers 503, 504, and 505 can obtain detection scripts and / or repair scripts from the central server 501 through network 502, and after executing the detection scripts and / or repair scripts, can return detection results, including multiple detection parameters, to the central server 501 through network 502.

[0121] It should be understood that Figure 5 The number of networks and servers shown is merely illustrative. Depending on implementation needs, there can be any number of networks and servers.

[0122] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing a terminal device of the present invention. Figure 6 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0123] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0124] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0125] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined above in the system of this invention.

[0126] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described system can also be located in a processor, for example, it can be described as: a processor including an information acquisition module, a script distribution module, a status verification module, and a repair module. The names of these modules do not necessarily limit the module itself; for example, the information acquisition module can also be described as "a module for acquiring the identification information of the server to be detected".

[0129] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to: acquire identification information of at least one server to be tested; acquire a detection script corresponding to the at least one server to be tested based on the identification information and a pre-configured storage path, the detection script including multiple detection instructions, each detection instruction corresponding to one or more detection parameters associated with an operating system; send the detection script to each server to be tested and acquire the detection parameters returned by each server to be tested after running the detection script; verify the performance status of the operating system of the server to be tested based on the detection parameters; if the performance status fails verification, distribute a repair script to the server to be tested, causing the server to run the repair script to repair the performance status of the operating system.

[0130] According to the technical solution of this invention, the central server obtains the detection script corresponding to the server under test according to the pre-configured storage path and sends the detection script to each server under test. The detection script includes multiple detection instructions, each of which corresponds to one or more detection parameters associated with the operating system. This allows each server under test to obtain the detection parameters associated with the operating system by running the detection script and return the detection parameters to the central server. The central server verifies the performance status of the operating system of the server under test based on the detection parameters. If the performance status fails verification, a repair script is distributed to the server under test, allowing it to run the repair script to repair the operating system's performance status. Thus, by managing and distributing the detection script to the servers under test through the central server, automatic batch detection of the operating system on multiple servers under test is achieved, improving the detection efficiency. Furthermore, each server under test can use a common detection script without needing to write its own script for each server, further improving detection efficiency and facilitating script management. Additionally, if the central server detects that the operating system performance status of a server under test has failed verification, it can automatically repair the performance status by distributing a repair script to the server under test, thereby reducing the workload of maintenance personnel and helping to maintain operating system consistency.

[0131] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for detecting an operating system, characterized in that, Applied to the central server, including: Obtain the identification information of at least one server to be detected; Based on the identification information and the pre-configured storage path, a detection script corresponding to the at least one server to be detected is obtained. The detection script includes multiple detection instructions, and each detection instruction corresponds to one or more detection parameters associated with the operating system. The detection script is sent to each of the servers to be detected, and the detection parameters returned by each of the servers to be detected after running the detection script are obtained. Verify the performance status of the operating system of the server under test based on the detection parameters; If the performance status fails verification, a repair script is distributed to the server under test, causing the server under test to run the repair script to repair the performance status of the operating system.

2. The method according to claim 1, characterized in that, If the performance status fails verification, the following is also included: Identify the target servers that failed verification, and the target detection parameters that failed verification within those target servers; The fault type is determined based on the target detection parameters, and a repair script corresponding to the fault type is selected. Distributing the repair script to the server to be detected includes: distributing the repair script to the target server to be detected.

3. The method according to claim 2, characterized in that, After distributing the repair script to the target server to be detected, the method further includes: The detection script is sent to the target server to be detected again to obtain the target detection parameters of the target server to be detected. The performance status of the operating system of the target server to be detected is verified again based on the target detection parameters. If the performance status of the operating system of the target server to be tested fails the verification, a manual intervention prompt message will be issued.

4. The method according to claim 1, characterized in that, The step of obtaining the detection script corresponding to the at least one server to be detected based on the identification information and the pre-configured storage path includes: Based on the identification information, multiple functions to be tested are determined for each server to be tested; Based on the pre-configured storage path, a script function module corresponding to each function to be detected is determined, and the script function module encapsulates the detection instructions corresponding to the function to be detected; The script function modules corresponding to the multiple functions to be detected are assembled to form the detection script.

5. The method according to claim 1, characterized in that, The detection script is sent to each of the servers to be detected, and the detection parameters returned by each server after running the detection script are obtained, including: Based on the identification information corresponding to each of the servers to be detected, the forward filtering strategy and the reverse filtering strategy corresponding to the servers to be detected are determined. The detection script is distributed to each server to be detected according to the forward filtering strategy, and the detection parameters of the server to be detected are obtained according to the reverse filtering strategy.

6. The method according to claim 1, characterized in that, Sending the detection script to each of the servers to be detected includes: The detection script is distributed to each of the servers to be detected using a data mirroring backup tool.

7. The method according to claim 1, characterized in that, Before obtaining the identification information of at least one server to be detected, the method further includes: Configure the storage path of the detection script; store the detection script according to the storage path, and add the storage path to the environment variables of the central server so as to call the detection script according to the storage path; And / or, A communication connection is established with the server to be detected using an SSH key pair.

8. A detection device for an operating system, characterized in that, It is applied to the central server; it includes: an information acquisition module, a script distribution module, a status verification module, and a repair module; among which, The information acquisition module is configured to acquire the identification information of at least one server to be detected; The script distribution module is configured to: obtain a detection script corresponding to the at least one server to be detected based on the identification information and the pre-configured storage path. The detection script includes multiple detection instructions, and each detection instruction corresponds to one or more detection parameters associated with the operating system. The status verification module is configured to: send the detection script to each of the servers to be detected, and obtain the detection parameters returned by each of the servers to be detected after running the detection script; and verify the performance status of the operating system of the server to be detected based on the detection parameters. The repair module is configured to: if the performance status fails verification, distribute a repair script to the server under test, so that the server under test runs the repair script to repair the performance status of the operating system.

9. A server for detecting an operating system, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the detection method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the detection method as described in any one of claims 1-7.

Images