A method, apparatus, and storage medium for batch configuring server BIOS

Abstract

This invention relates to a method, apparatus, and storage medium for batch configuring server BIOS. The method includes: batch importing server device information into a host computer; traversing the server device information, requesting the server's Basic Input / Output System (BIOS) configuration information via the Redfish API interface, receiving and interpreting JSON returned data, and generating a BIOS configuration interface; dynamically modifying and adjusting the BIOS configuration data; batch requesting BIOS configuration modifications and verifying successful configuration; batch restarting operations and re-verifying successful configuration; enabling and configuring the server's remote serial port management function via the Redfish interface, and verifying the output bytecode. Through the Redfish protocol interface, the method batch modifies the server's BIOS configuration, and also provides batch dynamic adjustment options, batch restart functionality, and a JSON bytecode verification scheme, comprehensively ensuring the automation and security of the configuration.

Description

Technical Field

[0001] This invention relates to the field of servers, and more particularly to a method, apparatus, and storage medium for batch configuring server BIOS. Background Technology

[0002] Driven by the information technology innovation industry, servers have been developing strongly in recent years. With the increase in batch shipments, whether for actual operation and maintenance deployment or for carrier POC testing, BIOS customization has become a necessity. At present, there is a lack of mature methods for configuring BIOS for batch servers.

[0003] There are many BIOS options, and many of them are abbreviations of technical terms. Modifying them is very difficult for non-professionals. Modifying them one by one is also quite troublesome, and it involves a series of operations such as saving, restarting, and re-verifying, which is a waste of time. Summary of the Invention

[0004] This invention provides a method, apparatus, and storage medium for batch configuring server BIOS, aiming to at least solve one of the technical problems existing in the prior art.

[0005] The technical solution of the present invention is a method for batch configuring server BIOS. The method is applied to a device for batch configuring server BIOS, which includes a host computer and multiple servers. The method for batch configuring server BIOS includes the following steps:

[0006] S100, Batch import of server device information into the host computer;

[0007] S200: Traverse server device information, request basic input / output system (BIOS) configuration information from the server via the Redfish API interface, receive and interpret the JSON returned data, and generate the BIOS configuration interface;

[0008] S300: Dynamically modify and adjust the configuration data of the Basic Input / Output System BIOS;

[0009] S400: Batch request to modify BIOS configuration and verify whether the configuration is successful;

[0010] S500, batch restart operation, and re-verify whether the configuration is successful;

[0011] The S600 enables and configures the server's remote serial port management function (Serial OverLAN, SOL) via the Redfish interface to verify the output bytecode.

[0012] Furthermore, step S100 includes:

[0013] S110. Batch import server device information from Excel files;

[0014] S120. Convert the server device information into a processable structured list of device instances;

[0015] S130. Log in to the Baseboard Management Controller (BMC) of the server via the Redfish protocol and obtain a temporary access token for authentication of subsequent API requests.

[0016] S140. Construct a complete URL request address using the BMC IP address field, send a request to the server, and obtain the server's system information;

[0017] S150. Verify whether the device model is the preset device. If it does not match, stop the operation to avoid accidental operation of non-target devices.

[0018] S160. If it is the target device, obtain the device serial number and BIOS version information.

[0019] Furthermore, in step S110,

[0020] The server device information is in the form of a two-dimensional data table, and includes at least a device model field, a BMC IP address field for a separate network interface used for remote management, a BMC login account field, and a BMC login password field.

[0021] Furthermore, step S200 includes:

[0022] S210. Call Redfish's BIOS interface and BIOS Settings interface to obtain a valid authentication temporary access token, log in to the selected server device, and obtain the currently effective BIOS configuration and pending BIOS settings.

[0023] S220. Obtain the full JSON format basic input / output system BIOS information to prepare for subsequent parsing and display;

[0024] S230. Convert the full JSON format basic input / output system BIOS information into front-end renderable structured data InteractiveBiosConfig. The front-end renderable structured data includes a list of configuration items (attributes), data grouped by function through groupAttributes, and a dependency graph (dependencies).

[0025] S240. In transformAttributes, type each attribute of the renderable structure data InteractiveBiosConfig, including automatically identifying or specifying the type, extracting the option list, marking read-only or editable items, distinguishing the current value from the modification to be applied, and dynamically calculating the optional value through resolveOptions;

[0026] S250. Based on the predefined BiosSchema, the linked component buildDependencyGraph is called to construct the Bios operation module BiosConfigParser and establish dependency mappings between configuration items.

[0027] Furthermore, step S300 includes:

[0028] S310. Obtain and parse the raw Basic Input / Output System (BIOS) configuration data from the server through the initialize method, and provide the user with the latest configuration snapshot;

[0029] S320: Dynamically adjust configuration data during user interaction. When a user updates a single configuration item, trigger dependency checks and linked updates, including performing read-only checks, value validity checks, and updating the value to be applied.

[0030] The read-only check first verifies whether the target attribute is read-only. If the target attribute is read-only, the modification request is rejected. The value validity check checks the validity of the new value based on predefined value constraints. When the application value is updated to the state of application pending, the relevant dependencies are processed.

[0031] S330. Recursively process all related configuration items that depend on the current modification, calculate the new list of options for the dependencies, and update the available options for these dependencies according to the changes. If it is found that the current value of some dependencies is no longer valid, automatically reset it to one of the new available options and continue to recursively process its dependencies.

[0032] Furthermore, step S400 includes:

[0033] S410. The BatchBiosConfigurator class is used to send configuration requests in batches to the imported list of server devices. The executeBatchUpdate method is called, and a configGenerator function is passed in to dynamically generate the target BIOS configuration for each server device.

[0034] S420 uses a semaphore for concurrency control to limit the maximum number of concurrent requests, preventing network congestion or excessive load on the BMC due to too many requests.

[0035] S430. To cope with temporary network fluctuations or session timeouts, a retry policy (retryPolicy) is integrated during the configureDevice configuration process. The maximum number of retries and the retry interval are set for each server device.

[0036] S440. After each server device is modified, the configuration effectiveness verification process verifyConfiguration is executed immediately. This process involves re-acquiring the current configuration of the Basic Input / Output System BIOS, comparing whether the key attributes are consistent with expectations, and confirming that the configuration has been successfully applied to prevent situations where the request is successful but the configuration has not taken effect.

[0037] Furthermore, step S500 includes:

[0038] S510: For all successfully configured devices, initiate a batch restart operation by calling the ServerPowerManager.gracefulReboot method to trigger a graceful restart, thus avoiding data or configuration anomalies caused by forced power outages.

[0039] S520: Send a POST request to the Redfish interface via sendResetCommand to specify Graceful Restart, notifying the server to shut down and restart normally;

[0040] S530, after restarting, execute pollServerStatus to poll the device power status and confirm recovery;

[0041] S540: Obtain the current BIOS configuration of the device, compare the returned actual configuration with the user's expected configuration, and call the Redfish interface to verify whether the configuration is effective;

[0042] S550: If there are mismatches, clearly indicate which configuration items are not effective and record an alarm log.

[0043] Furthermore, step S600 includes:

[0044] S610. Call the SolManager.enableSol method to get the current status of the remote serial port management function (SerialOver LAN, SOL). If it is enabled, return success directly to avoid repeated configuration.

[0045] S620. If the remote serial port management function (Serial Over LAN, SOL) is not currently enabled, enable the remote serial port management function and set the bit rate and signal type.

[0046] S630. Call getSolState again to get the latest state and confirm that InterfaceEnabled has taken effect.

[0047] Furthermore, an apparatus for batch configuring server BIOS, used to perform the method for batch configuring server BIOS, the apparatus comprising:

[0048] The server is equipped with at least a baseboard management controller (BMC).

[0049] The host computer is connected to the baseboard management controller (BMC) of the server via the Redfish API interface.

[0050] Furthermore, the present invention also proposes a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the method for batch configuring server BIOS.

[0051] The beneficial effects of this invention are:

[0052] The method, apparatus, and storage medium for batch configuring server BIOS described herein modify the server's BIOS configuration in batches via the Redfish protocol interface. It also provides batch dynamic adjustment options, batch restart functionality, and a SOL bytecode verification scheme, comprehensively ensuring the automation and security of the configuration. Attached Figure Description

[0053] Figure 1 A flowchart illustrating the overall process for batch configuring server BIOS.

[0054] Figure 2 This is a schematic diagram of the SOL data verification process. Detailed Implementation

[0055] The following will provide a clear and complete description of the concept, specific structure, and technical effects of the present invention in conjunction with the embodiments and accompanying drawings, so as to fully understand the purpose, solution, and effects of the present invention. It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0056] It should be noted that, unless otherwise specified, when a feature is referred to as "fixed" or "connected" to another feature, it can be directly fixed or connected to the other feature, or indirectly fixed or connected to the other feature. Furthermore, the descriptions of "upper," "lower," "left," "right," "top," and "bottom" used in this invention are only relative to the relative positional relationships of the various components of the invention in the accompanying drawings.

[0057] Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing particular embodiments only and not for limiting the invention. The term "and / or" as used herein includes any combination of one or more of the associated listed items.

[0058] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various elements, these elements should not be limited to these terms. These terms are only used to distinguish elements of the same type from one another. For example, without departing from the scope of this disclosure, a first element may also be referred to as a second element, and similarly, a second element may also be referred to as a first element.

[0059] Reference Figures 1 to 2 In some embodiments, the technical solution of the present invention is a method for batch configuring server BIOS.

[0060] The method for batch configuring server BIOS is applied to a device for batch configuring server BIOS, which includes a host computer and multiple servers, as described above. Figure 1 The method for batch configuring server BIOS includes the following steps:

[0061] S100, Batch import of server device information into the host computer;

[0062] S200: Traverse server device information, request basic input / output system (BIOS) configuration information from the server via the Redfish API interface, receive and interpret the JSON returned data, and generate the BIOS configuration interface;

[0063] S300: Dynamically modify and adjust the configuration data of the Basic Input / Output System BIOS;

[0064] S400: Batch request to modify BIOS configuration and verify whether the configuration is successful;

[0065] S500, batch restart operation, and re-verify whether the configuration is successful;

[0066] The S600 enables and configures the server's remote serial port management function (Serial OverLAN, SOL) via the Redfish interface to verify the output bytecode.

[0067] The beneficial effects of this invention are:

[0068] The method, apparatus, and storage medium for batch configuring server BIOS described herein modify the server's BIOS configuration in batches via the Redfish protocol interface. It also provides batch dynamic adjustment options, batch restart functionality, and a SOL bytecode verification scheme, comprehensively ensuring the automation and security of the configuration.

[0069] This invention is easy to use: it uses a method of parsing BIOS configuration into an interactive interface for configuration.

[0070] This invention is highly efficient: it improves BIOS configuration efficiency by using HTTP requests in conjunction with thread processing.

[0071] This invention is reliable: after configuration is completed, the configuration results are verified in batches, and the output bytecode of SOL is also verified to ensure the completeness of the update.

[0072] This invention features automation: Each step is automated, significantly reducing manpower allocation time and improving accuracy.

[0073] This invention proposes a dynamic linkage configuration: Traditional BIOS configuration does not consider the existence of dynamic linkage, and often only corresponds to key and value without considering the global context. This invention provides a dynamic linkage solution by parsing the configuration data, which maximizes the success of the configuration.

[0074] This invention proposes a security enhancement scheme for SOL: Traditional SOL is at risk of plaintext transmission, while this invention provides an encryption and decryption scheme to ensure the security and reliability of SOL transmission.

[0075] Furthermore, refer to Figure 1 Step S100 includes:

[0076] S110. Batch import server device information from Excel files;

[0077] S120. Convert the server device information into a processable structured list of device instances;

[0078] S130. Log in to the Baseboard Management Controller (BMC) of the server via the Redfish protocol and obtain a temporary access token for authentication of subsequent API requests.

[0079] S140. Construct a complete URL request address using the BMC IP address field, send a request to the server, and obtain the server's system information;

[0080] S150. Verify whether the device model is the preset device. If it does not match, stop the operation to avoid accidental operation of non-target devices.

[0081] S160. If it is the target device, obtain the device serial number and BIOS version information.

[0082] Specifically, in step S110, server device information is imported in batches via an Excel file. The user first prepares an Excel spreadsheet file containing basic information about the servers to be managed, mainly including: device model (expected to be RG221F V1), BMC IP address (a separate network interface for remote management), login account (BMC login username), and login password (BMC login password). This Excel file serves as the input source for the batch device list. The system reads this file and parses its contents into a data structure that the program can process (such as an array or list), with each record representing a server device to be operated.

[0083] Use ExcelJS to read the uploaded Excel file, extract each row of data, and convert it into a structured device list DeviceInfo[], which includes fields such as BMC IP, account, and password.

[0084] In step S120, the user-filled form data is converted into a structured device list that the program can process. The system calls the data parsing module to convert each row of data in the Excel file into a structured device object, for example:

[0085] {

[0086] "model": "RG221F V1",

[0087] "bmc_ip": "192.168.10.100",

[0088] "username": "admin",

[0089] "password": "******"

[0090] }

[0091] These structured device objects are organized into a device list for subsequent batch processing. The program creates an instance of the RG221FV1DeviceList class for each device and passes in information such as bmc_ip for subsequent operations.

[0092] Create an RG221FV1DeviceList instance for each device, call its validateAndRegister() method, and perform the following operations: call getSession(bmc_ip, username, password) to obtain the Redfish authentication token; call getSystemInfo(token) to request the https: / / {bmc_ip} / redfish / v1 / Systems / 1 interface to obtain the device system information; call validateModel(systemInfo) to verify whether the Model field is "RG221F V1", skipping if it does not match; and call getSerialNumberFromSystemInfo(systemInfo) to extract the serial number.

[0093] All devices that pass verification will return a registration result, DeviceRegistrationResult, containing information such as bmcIp, model, serialNumber, and biosVersion, for subsequent management, deduplication, and auditing.

[0094] In step S130, each device is authenticated individually to confirm the correct device model and prevent accidental operation. For each device in the list, the system performs the following verification steps:

[0095] 1) Establish a connection and obtain an identity token:

[0096] Log in to the BMC using the device's bmc_ip, username, and password via the Redfish protocol to obtain a temporary access token. This token is used for authentication in subsequent API requests.

[0097] 2) Call the getSystemInfo(token) method to obtain device system information:

[0098] This method is the core function in the RG221FV1DeviceList class. It uses a predefined Redfish API address template.

[0099] https: / / {} / redfish / xxxxxxxReplace the curly braces {} with the actual this.bmc_ip to construct the complete request URL; then call an external function called getSerialNumber, passing in the BMC IP, token and the constructed URL, to send a request to the device to obtain its system information (such as model, serial number, BIOS version, etc.).

[0100] The `validateModel(systemInfo)` method is called to verify the device model. After obtaining `systemInfo`, the system calls the `validateModel` method to check if the `Model` field in the returned data is equal to a preset value. If they match, the device model is correct, and the operation can continue; if they do not match, the model is determined to be incorrect, and the system will refuse to perform further operations on that device to prevent accidental operation on a non-target device.

[0101] Simultaneously, the system obtains information such as the device serial number and BIOS version to facilitate subsequent management, log auditing, and deduplication. After successfully obtaining the systemInfo, the system further extracts key device information:

[0102] The `getSerialNumberFromSystemInfo(systemInfo)` method is called to extract the serial number. This method reads the `SerialNumber` field from the `systemInfo` object and returns the device's unique serial number. This serial number can be used for: device deduplication (avoiding duplicate imports of the same device), asset management (serving as a unique identifier for the device), and log auditing (recording operation objects).

[0103] Furthermore, refer to Figure 1 In step S110,

[0104] The server device information is in the form of a two-dimensional data table, and includes at least a device model field, a BMC IP address field for a separate network interface used for remote management, a BMC login account field, and a BMC login password field.

[0105] Furthermore, refer to Figure 1 Step S200 includes:

[0106] S210. Call Redfish's BIOS interface and BIOS Settings interface to obtain a valid authentication temporary access token, log in to the selected server device, and obtain the currently effective BIOS configuration and pending BIOS settings.

[0107] S220. Obtain the full JSON format basic input / output system BIOS information to prepare for subsequent parsing and display;

[0108] S230. Convert the full JSON format basic input / output system BIOS information into front-end renderable structured data InteractiveBiosConfig. The front-end renderable structured data includes a list of configuration items (attributes), data grouped by function through groupAttributes, and a dependency graph (dependencies).

[0109] S240. In transformAttributes, type each attribute of the renderable structure data InteractiveBiosConfig, including automatically identifying or specifying the type, extracting the option list, marking read-only or editable items, distinguishing the current value from the modification to be applied, and dynamically calculating the optional value through resolveOptions;

[0110] S250. Based on the predefined BiosSchema, the linked component buildDependencyGraph is called to construct the Bios operation module BiosConfigParser and establish dependency mappings between configuration items.

[0111] In step S250, the linked component buildDependencyGraph is called when constructing BiosConfigParser.

[0112] Specifically, requesting BIOS data to return the BIOS information of a device involves calling the Redfish interfaces / Bios and / Bios / Settings. A valid authentication token must first be obtained, and the final data is JSON in "attribute-value" format. Log in to the selected server device to obtain the currently active BIOS configuration and pending BIOS settings (PendingSettings). Obtain the full JSON format BIOS information to prepare for subsequent parsing and display. In a specific embodiment, the reference code is as follows:

[0113] let res = await getBios(this.bmc_ip,token,API_LIST['get_bios'].replace('{}', this.bmc_ip),JSON.parse(this.biosSet) )

[0114] / / this.msg.setToken(token);

[0115] let bios_attr = res["Attributes"].

[0116] Parse and display BIOS data, convert the raw BIOS JSON data obtained from the Redfish interface into a user-friendly interactive configuration interface, supporting dynamic options, input type recognition, and linkage control. Include:

[0117] (1) Convert to interactive configuration items (BiosConfigParser.parse), call the parse(rawConfig) method, pass in the raw Attributes data obtained from the / Bios interface, and convert it into a front-end renderable InteractiveBiosConfig structure, including: a list of configuration items (attributes), grouped by function (such as CPU, memory, implemented through groupAttributes), and a dependency graph (dependencies).

[0118] (2) Support diverse inputs and linkages (transformAttributes, resolveOptions), perform typed processing on each attribute in transformAttributes: automatically recognize or specify the type according to the Schema (such as switch, dropdown, numeric input), extract the options list (such as "Enable / Disable", "UEFI / Legacy"), mark read-only or editable items, support pendingValue to distinguish the current value from the pending effective modification, and dynamically calculate the available values through resolveOptions, for example, limit the memory frequency options according to the CPU model.

[0119] (3) Build a dependency graph to support linkages (buildDependencyGraph), based on the predefined BiosSchema, call buildDependencyGraph when constructing BiosConfigParser to establish the dependency mapping between configuration items. For example: when "CPU overclocking mode" is enabled, "CPU voltage setting" is displayed; some advanced options depend on the "Advanced mode" switch; this dependency graph is used in the front end to dynamically control the visibility and availability of fields, achieving intelligent linkages.

[0120] Furthermore, referring to Figure 1 , step S300 includes:

[0121] S310. Obtain and parse the raw Basic Input / Output System (BIOS) configuration data from the server through the initialize method, and provide the user with the latest configuration snapshot;

[0122] S320: Dynamically adjust configuration data during user interaction. When a user updates a single configuration item, trigger dependency checks and linked updates, including performing read-only checks, value validity checks, and updating the value to be applied.

[0123] The read-only check first verifies whether the target attribute is read-only. If the target attribute is read-only, the modification request is rejected. The value validity check checks the validity of the new value based on predefined value constraints. When the application value is updated to the state of application pending, the relevant dependencies are processed.

[0124] S330. Recursively process all related configuration items that depend on the current modification, calculate the new list of options for the dependencies, and update the available options for these dependencies according to the changes. If it is found that the current value of some dependencies is no longer valid, automatically reset it to one of the new available options and continue to recursively process its dependencies.

[0125] Specifically, in steps S310 and S320, user interaction and dynamic adjustment are performed. Initialization involves obtaining and parsing the original BIOS configuration data from the specified device using the `initialize(device)` method to provide the user with the latest configuration snapshot. Updating a single configuration item allows the user to update a specific configuration item using the `updateAttribute(name, newValue)` method, triggering dependency checks and linked updates. These include read-only checks (first verifying whether the target attribute is read-only; if so, the modification request is rejected); value validity checks (checking the validity of the new value based on predefined value constraints, such as numerical range and enumerated options); and updating the pending value (setting the new value to a pending state and handling related dependencies).

[0126] In step S330, linkage processing and validity verification are performed. The dependency linkage processing method `handleDependencies(name, newValue)` is used to recursively process all related configuration items that depend on the currently modified item: it calculates a new list of options for the dependencies and updates the available options for these dependencies according to the changes. If it is found that the current value of some dependencies is no longer valid, it is automatically reset to one of the new available options, and the recursive processing of its dependencies continues.

[0127] The achieved technical effect is as follows:

[0128] Dynamic linkage processing and intelligent linkage: Based on the dependency graph between configuration items, the values ​​and optional ranges of related options are dynamically adjusted to ensure the consistency of configuration logic.

[0129] User-friendly experience: It provides instant feedback to guide users in making legitimate and valid configuration changes, while avoiding the possibility of manual configuration errors. This design makes BIOS configuration management more flexible and efficient, ensuring not only the consistency and legitimacy of configuration data but also significantly improving the user's configuration experience.

[0130] Furthermore, refer to Figure 1 Step S400 includes:

[0131] S410. The BatchBiosConfigurator class is used to send configuration requests in batches to the imported list of server devices. The executeBatchUpdate method is called, and a configGenerator function is passed in to dynamically generate the target BIOS configuration for each server device.

[0132] S420 uses a semaphore for concurrency control to limit the maximum number of concurrent requests, preventing network congestion or excessive load on the BMC due to too many requests.

[0133] S430. To cope with temporary network fluctuations or session timeouts, a retry policy (retryPolicy) is integrated during the configureDevice configuration process, and a maximum number of retries and a retry interval are set for each server device.

[0134] S440. After each server device is modified, the configuration effectiveness verification process verifyConfiguration is executed immediately. This process involves re-acquiring the current configuration of the Basic Input / Output System BIOS, comparing whether the key attributes are consistent with expectations, and confirming that the configuration has been successfully applied to prevent situations where the request is successful but the configuration has not taken effect.

[0135] Specifically, batch BIOS modification enables batch BIOS configuration changes to imported devices, supporting concurrency control and failure retries to ensure efficient and stable operation. This includes:

[0136] (1) Send configuration requests in batches and perform unified operations on the imported device list through the BatchBiosConfigurator class. Call the executeBatchUpdate() method, pass in a configGenerator function, and dynamically generate the target BIOS configuration (such as enabling virtualization, disabling power saving, etc.) for each device.

[0137] (2) Concurrency control and retry mechanism: Concurrency control uses a semaphore to limit the maximum number of concurrent requests (default concurrentLimit = 5) to avoid network congestion or excessive load on the BMC due to too many requests. The failure retry mechanism integrates a retry policy (retryPolicy) during configureDevice, allowing each device to retry a maximum of 3 times with a 2-second interval to cope with temporary network fluctuations or session timeouts.

[0138] (3) Verify the configuration effect. Each device immediately performs the verification process (verifyConfiguration) after modification: re-acquire the current BIOS configuration ( / redfish / v1 / Systems / 1 / Bios), compare whether the key attributes are consistent with the expectations, and confirm that the configuration has been successfully applied to prevent the situation of "request successful but not effective".

[0139] Furthermore, refer to Figure 1 Step S500 includes:

[0140] S510: For all successfully configured devices, initiate a batch restart operation by calling the ServerPowerManager.gracefulReboot method to trigger a graceful restart, thus avoiding data or configuration anomalies caused by forced power outages.

[0141] S520: Send a POST request to the Redfish interface via sendResetCommand to specify Graceful Restart, notifying the server to shut down and restart normally;

[0142] S530, after restarting, execute pollServerStatus to poll the device power status and confirm recovery;

[0143] S540: Obtain the current BIOS configuration of the device, compare the returned actual configuration with the user's expected configuration, and call the Redfish interface to verify whether the configuration is effective;

[0144] Specifically, the Redfish interface is called to verify whether the configuration is effective by using the reVerifyBiosConfiguration function to obtain the current BIOS configuration of the device and compare the returned actual configuration with the user's expected configuration.

[0145] S550: If there are mismatches, clearly indicate which configuration items are not effective and record an alarm log.

[0146] In S550, handleBiosMismatch is called to record alarm logs.

[0147] Specifically, server restart and verification involves performing a unified restart on the devices and monitoring the recovery status after successful batch BIOS configuration to ensure that the changes take effect and the system runs normally. This includes:

[0148] (1) Initiate a batch restart operation. For all successfully configured devices, call the ServerPowerManager.gracefulReboot() method to trigger a graceful restart and avoid data or configuration abnormalities caused by forced power outage.

[0149] (2) Call the Redfish interface to perform a restart. Send a POST request to the Redfish interface / redfish / v1 / Systems / 1 / Actions / ComputerSystem.Reset via sendResetCommand(), specifying ResetType: "GracefulRestart", to notify the server to shut down and restart normally.

[0150] (3) Poll the status and confirm recovery. After restarting, execute pollServerStatus() to poll the device power status: request / redfish / v1 / Systems / 1 to get PowerState every 5 seconds, and try up to 30 times (about 150 seconds). Wait for the status to change to "On". If it still does not recover after timeout, throw a timeout exception and mark it as a restart failure. At the same time, capture network errors, authentication failures and other errors to ensure that the exceptions are traceable.

[0151] (4) Request data verification again. After the device restarts, the BIOS configuration needs to be retrieved again to confirm that the user-modified settings have truly taken effect, preventing configuration loss due to firmware incompatibility, configuration not being written, or abnormal restart. This includes:

[0152] Call the Redfish interface to verify whether the configuration is effective. Use the reVerifyBiosConfiguration() function to send a request to the / redfish / v1 / Systems / 1 / Bios interface with the existing token (actually calling reGetBios()) to obtain the current BIOS configuration of the device (i.e. the Attributes field).

[0153] The returned actual configuration is compared with the user's expected configuration (biosSet). The core logic is completed in verifyBIOSSet(): iterate through all expected configuration items; check if they exist in the current configuration; check if the values ​​are completely consistent; and record mismatches to a mismatch object.

[0154] For devices that do not meet expectations, exception handling is performed as follows: If mismatches exist: Return { success: false, mismatch}, explicitly indicating which configuration items are not effective; call handleBiosMismatch() to record an alarm log, which can be used for subsequent alarms, retries, or manual intervention. If all matches, return { success: true}, indicating that the device's BIOS configuration has been successfully applied and persisted.

[0155] Furthermore, refer to Figure 1 Step S600 includes:

[0156] S610. Call the SolManager.enableSol method to get the current status of the remote serial port management function (SerialOver LAN, SOL). If it is enabled, return success directly to avoid repeated configuration.

[0157] S620. If the remote serial port management function (Serial Over LAN, SOL) is not currently enabled, enable the remote serial port management function and set the bit rate and signal type.

[0158] S630. Call getSolState again to get the latest state and confirm that InterfaceEnabled has taken effect.

[0159] Specifically, if the SOL function is not currently enabled, then call...

[0160] The configureSol() function sends a PATCH request to / redfish / v1 / Managers / 1 / SerialInterface, setting: InterfaceEnabled: true (enable SOL), BitRate: 115200 (baud rate), SignalType: 'Rs232' (signal type) to ensure that the serial communication parameters meet the requirements of remote management.

[0161] To verify the validity of the configuration, after configuration, call getSolState() again to get the latest state and confirm that InterfaceEnabled has taken effect. If it is not enabled, throw an exception to mark the operation as failed.

[0162] Key methods: enableSol() → getSolState() + configureSol()

[0163] Core logic: Status check → Condition activation → Parameter configuration → Result verification

[0164] Value: Securely and reliably enables remote serial port access, supports out-of-band debugging and troubleshooting, and is suitable for unattended server scenarios.

[0165] In addition, refer to Figure 2 Regarding SOL data verification, this invention proposes an SOL data verification flowchart, which describes a three-party interactive process (Client -> Validator -> BMC), aiming to establish a secure and encrypted SOL communication channel for remote serial communication (such as accessing the server BIOS or operating system console).

[0166] The entire process can be divided into three main stages: 1. Session initialization -> 2. Encrypted data transmission -> 3. Session termination.

[0167] Phase 1: Session initialization and key exchange (Handshake & Key Exchange) is the most complex part, and its purpose is to securely exchange encryption keys in an insecure network.

[0168] The client initiates a request: The client executes the command `ipmitool sol activate` to request activation of the SOL function.

[0169] Request forwarding: The request is sent to the Validator (usually a management controller or middleware), and then forwarded by the Validator to the BMC of the target server.

[0170] SOL Ready: BMC confirms readiness to establish a SOL session.

[0171] OEM Key Exchange (Core Security Steps):

[0172] l Request public key: Validator requests the public key of its OEM (manufacturer) from BMC.

[0173] l Sending Public Key: BMC sends its public key to Validator.

[0174] Public key transfer: The Validator forwards the BMC's public key to the Client.

[0175] l Session ready: At this point, the Client has the BMC's public key and is ready to establish an encrypted session.

[0176] The core objective of this stage is to enable the client to securely obtain the server's BMC public key. The client can then use this public key to encrypt data, while only the BMC with the corresponding private key can decrypt it.

[0177] Phase Two: Encrypted Data Transfer. After the key is established, the actual encrypted data transfer cycle begins.

[0178] Encryption and transmission: The client encrypts the serial data to be sent using the BMC's public key to form "encrypted frame data", and then sends it to the Validator.

[0179] Validation and forwarding: The Validator may perform some validation operations and then forward the encrypted data to the BMC.

[0180] Decryption and Processing: After receiving the data, the BMC decrypts it using its private key and verifies it. The decrypted data is the original serial command (e.g., keyboard input) sent by the Client.

[0181] Return response: The BMC will encrypt the execution result or serial port output data and return it to the Client along the original path (BMC -> Validator -> Client).

[0182] Decryption and display: The client decrypts the received response data and displays it to the user (e.g., terminal output).

[0183] The core objective of this stage is to establish a bidirectional, encrypted "data tunnel" between the Client and the BMC, where all transmitted serial data is encrypted to prevent eavesdropping and tampering.

[0184] Phase 3: Session Termination, when the user needs to end the session.

[0185] Client-initiated termination: The client executes the command `ipmitool sol deactivate` to request the termination of the SOL session.

[0186] Request forwarding: The termination request is forwarded to BMC via Validator.

[0187] BMC confirms termination: After receiving the instruction, BMC closes the SOL session.

[0188] Session ended: The entire encrypted communication channel is closed.

[0189] In the remote serial port management function (Serial Over LAN, SOL), there are three roles:

[0190] l Client: The user terminal, which initiates and terminates sessions, encrypts and sends data, and decrypts and receives data.

[0191] Validator: A middleman responsible for forwarding requests, responses, and encrypting data; may also participate in validation.

[0192] BMC: Server Management Controller, responds to requests, provides a public key, decrypts received data, and encrypts and sends responses.

[0193] Core security mechanism: asymmetric encryption (public key encryption).

[0194] BMC holds the private key.

[0195] The client obtains the public key from the BMC.

[0196] The client encrypts data using a public key, and the BMC decrypts it using a private key, ensuring that only the target BMC can read the data.

[0197] Main function: Implements end-to-end encryption of remote serial communication (SOL), ensuring the security of the management channel.

[0198] Key commands:

[0199] Startup: ipmitool sol activate.

[0200] l Stop: ipmitool sol deactivate.

[0201] This includes (1) the IPMI-SOL bytecode validator (IpmiSolValidator), whose goal is to ensure that the received raw data packets conform to the IPMI-SOL protocol specifications and security requirements. Core verification steps:

[0202] validatePacket() — The main entry point, executing the complete verification chain.

[0203] l Header check: Check if the first byte is 0x21 (SOL start character).

[0204] l Length matching: Extract the length field (lower 6 bits) and verify that packet.length === length + 2.

[0205] l Checksum verification: Call calculateChecksum() to verify the integrity of the transmission.

[0206] l Opcode whitelist: Only allow 0x01, 0x02, 0x10, 0x11 to prevent illegal instruction injection.

[0207] l Returns a structured result: including valid, code, and severity.

[0208] calculateChecksum() — Implements the IPMI cumulative sum algorithm (summing from the 2nd byte to the 2nd to 3rd byte and taking the lower 8 bits).

[0209] Security response strategy:

[0210] Warning level (e.g., length / checksum error) → Log and continue processing.

[0211] Fatal level (e.g., illegal header / opcode) → Immediately block, triggering a security event.

[0212] (2) SOL Session Management (IpmiSolSessionManager) aims to establish and maintain an encrypted serial communication channel (SOL).

[0213] Core process:

[0214] establishSession() — Starts the ipmitool sol activate child process to establish the basic connection.

[0215] performKeyExchange() — Performs forward secure key exchange:

[0216] l Generate an ECDH temporary key pair (P-256).

[0217] l Send the public key via IPMI OEM command 0x3A.

[0218] l Receive the BMC public key and derive the AES-GCM 256-bit session key.

[0219] Return to secure interface:

[0220] l send(data) → Automatically encrypts and sends the data.

[0221] l receive() → Returns the decrypted stream.

[0222] `terminate()` → Safely terminates the process.

[0223] Security features: forward secrecy, key isolation, and OEM extended command communication.

[0224] (3) SOL Traffic Validation Middleware (IpmiStreamValidator)

[0225] Objective: To extract, decrypt, and verify IPMI frames in real time during streaming.

[0226] Core Mechanism:

[0227] validate(stream) — An asynchronous generator that builds a pipeline for decryption → validation → output.

[0228] l Use buffers to concatenate data streams to solve the problem of packet merging / partial packet formation.

[0229] l Repeatedly call extractFrame() to extract complete frames.

[0230] extractFrame(buffer) — Dynamically slice frames based on the length field:

[0231] l Parse length = data[1] & 0x3F

[0232] l Determine if buffer.length >= length + 2.

[0233] If successful, it returns {payload, remaining}.

[0234] decryptFrame(payload) — Decrypts frame data (AES-GCM), throws an exception if it fails.

[0235] Exception handling:

[0236] l handleViolation(): Records illegal packets (such as invalid opcodes).

[0237] `handleCryptoError()`: Handles decryption failure, which may indicate a man-in-the-middle attack.

[0238] Performance optimization: Double buffering + streaming yield, supporting high-throughput real-time processing.

[0239] (4) Complete Validation Workflow (SecureSolWorkflow)

[0240] Objective: To orchestrate end-to-end secure communication processes and unify policies and resource management.

[0241] Core function:

[0242] start(config) — Orchestration in three stages:

[0243] l Establish a session (IpmiSolSessionManager.establishSession)

[0244] l Initialize the validation stream (IpmiStreamValidator.validate)

[0245] l Returns to the unified secure connection interface: send, receive, shutdown

[0246] handleViolation(result) — The central hub of security policies:

[0247] l Write to the audit log (SecurityMonitor.recordIncident)

[0248] l Response by severity level:

[0249] WARNING: Record, continue

[0250] CRITICAL: Calling emergencyShutdown() terminates the session.

[0251] shutdown() — Safety cleanup:

[0252] Terminate child process

[0253] l Clear key materials from memory (to prevent residue)

[0254] Security closed loop: From connection establishment to destruction, the entire process is auditable, responsive, and cleanable.

[0255] Furthermore, an apparatus for batch configuring server BIOS, used to perform the method for batch configuring server BIOS, the apparatus comprising:

[0256] The server is equipped with at least a baseboard management controller (BMC).

[0257] The host computer is connected to the baseboard management controller (BMC) of the server via the Redfish API interface.

[0258] Furthermore, the present invention also proposes a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the method for batch configuring server BIOS.

[0259] The above description is merely a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure, as long as they achieve the technical effects of the present invention by the same means, should be included within the scope of protection of this disclosure and should fall within the protection scope of the present invention. Within the protection scope of the present invention, the technical solutions and / or implementation methods can have various modifications and variations.

Claims

1. A method for bulk configuration of server BIOS, the method for bulk configuration of server BIOS is applied to a device for bulk configuration of server BIOS, the device for bulk configuration of server BIOS comprises a host computer and a plurality of servers, and the method comprises the following steps: The method for batch configuring a server BIOS comprises the following steps: ​ S100, a host computer batch imports server device information; S200, the server device information is traversed, BIOS configuration information of the server is requested through a Redfish API interface, JSON return data is received and interpreted, and a BIOS configuration interface is generated; step S200 comprises: S210, a Bios interface and a Bios Settings interface of Redfish are called, valid authentication temporary access tokens are obtained, selected server devices are logged in, and currently effective BIOS configuration and to-be-effective BIOS settings are obtained; S220, full-amount JSON format BIOS information is obtained, and preparation is made for subsequent parsing and display; S230, the full-amount JSON format BIOS information is converted into front-end renderable structure data, wherein the front-end renderable structure data comprises a configuration item list, implemented function grouping data and a dependency relationship graph; S240, each attribute of the renderable structure data is subjected to type processing, including automatic identification or specified type, extraction of an option list, marking of read-only items or editable items, differentiation between a current value and to-be-effective modification, and dynamic calculation of selectable values through resolveOptions; S250, a linkage component buildDependencyGraph is called to construct a Bios operation module BiosConfigParser, and a dependency mapping between configuration items is established; S300, configuration data of the BIOS is dynamically modified and adjusted; step S300 comprises: S310, original BIOS configuration data is obtained from the server through an initialization method and is parsed, and the latest configuration snapshot is provided for a user; S320, the configuration data is dynamically adjusted in interaction with the user, dependency checking and linkage updating are triggered when the user updates a single configuration item, including execution of read-only checking, value validity checking and to-be-applied value updating, the read-only checking verifies whether a target attribute is read-only, the value validity checking checks the validity of a new value according to predefined value constraint conditions, and the to-be-applied value updating processes related dependencies when it is detected that the new value is in a to-be-applied state; S330, all related configuration items dependent on a current modification item are processed recursively, a new option list of the dependent items is calculated, and available options of the dependent items are updated according to changes, if it is found that a current value of certain dependent items is no longer valid, the current value is automatically reset to one of new available options, and dependent items thereof are continuously processed recursively; S400, BIOS configuration is batch requested and modified, and whether the configuration is successful is verified; S500, a batch restart operation is performed, and whether the configuration is successful is verified again; S600, a remote serial port management function of the server is enabled and configured through a Redfish interface, and output bytecode is verified.

2. The method for bulk configuration of server BIOS according to claim 1, wherein, Step S100 comprises: S110, import server device information in batches through an Excel file; S120, convert the server device information into a structured device instance list that can be processed; S130, log in to the baseboard management controller (BMC) of the server through the Redfish protocol, obtain a temporary access token for subsequent API request authentication, and get system information of the server by constructing a complete URL request address through the BMC IP address field and initiating a request to the server; S140, verify whether the device model is a preset device, and if not, abort the operation to avoid misoperation on a non-target device; S160, if it is a target device, obtain the device serial number and BIOS version information. In step S110, 3. The method for bulk configuration of server BIOS according to claim 2, wherein, The server device information is in the form of a two-dimensional data table, and the server device information at least includes a device model field, a BMC IP address field of an independent network interface for remote management, a BMC login account field, and a BMC login password field. Step S400 includes:

4. The method for bulk configuration of server BIOS according to claim 1, wherein, S410, send a configuration request in batches to the imported server device list through the BatchBiosConfigurator class, call the executeBatchUpdate method, and pass in the configGenerator function to dynamically generate a target BIOS configuration for each server device; S420, use a semaphore for concurrent control to limit the maximum number of concurrent requests, so as to avoid network congestion or high BMC load caused by too many requests; S430, to cope with temporary network fluctuations or session timeouts, integrate a retry strategy during the configuration process, set a maximum number of retries and a retry interval time for each server device; S440, each server device immediately performs a configuration validation process after modification, re-obtains the current BIOS configuration, compares the key attributes with the expected values, confirms that the configuration has been successfully applied, and prevents the situation where the request is successful but not effective. Step S500 includes:

5. The method for bulk configuration of server BIOS according to claim 1, wherein, S510, for all devices with successful configuration, initiate a restart operation in batches, call the ServerPowerManager.gracefulReboot method, trigger graceful restart, and avoid data or configuration abnormalities caused by forced power-off; S520, send a POST request to the Redfish interface, specify graceful restart, and notify the server to shut down normally and restart; S530, poll the device power state after restart and confirm the recovery; S540, obtain the current BIOS configuration of the device, compare the returned actual configuration with the user's expected configuration, and call the Redfish interface to verify whether the configuration is effective; S550, if there are mismatches, specify which configuration items are not effective, and record the alarm log. Step S600 includes:

6. The method for bulk configuring server BIOS of claim 1, wherein, S610, obtain the current remote serial port management function state, if it is enabled, return success directly, and avoid repeated configuration; ​ S620, if the remote serial port management function is not enabled at present, enabling the remote serial port management function, setting the bit rate and signal type; S630, acquiring the latest state again, confirming that InterfaceEnabled has taken effect.

7. An apparatus for bulk configuration of server BIOS, configured to perform the method of any one of claims 1 to 6. The device for batch configuring the BIOS of the server comprises: a server provided with at least a baseboard management controller (BMC); a host computer connected with the baseboard management controller (BMC) of the server through a Redfish API interface.

8. A computer-readable storage medium, characterized in that, A computer program product, wherein program instructions stored thereon are executed by a processor to implement the method for batch configuring the BIOS of the server according to any one of claims 1 to 6.

Images