A cross-platform visual server firmware concurrent update method and device

Abstract

The present invention relates to a cross-platform visual server firmware concurrent update method and device, wherein the method uses an installation package construction module to build installation packages installed on different platforms on a host computer based on an Electron framework; the host computer imports or adds server information, and stores the server information in the host computer; the device front end on the host computer constructs a data packet from the Session ID and firmware update-related data obtained from the back-end management session module, and sends it to the back-end data parsing module; the data parsing module verifies the data and sends it to the task distribution module to distribute the task, generates a corresponding thread, and the server executes the update task; the back end returns the task progress to the host computer device front end in real time and displays it. The cross-platform visual server firmware concurrent update method and device provide a clear and intuitive operation interface, have the ability to execute tasks across platforms and concurrently, the device can be installed and used with one click, and the firmware update task can be executed simply and efficiently.

Description

Technical Field

[0001] The present invention relates to the field of server operation and maintenance, and in particular to a cross-platform visual server firmware concurrent update method and device. Background Art

[0002] Existing server operation and maintenance usually upgrades the firmware of servers one by one through the Web interface or by writing scripts. When the operation and maintenance personnel upgrade the firmware through the Web interface, they need to upgrade the firmware one by one, and when a restart is required, they need to restart manually, which is time-consuming and laborious. The method of executing the firmware update task through the Shell script method requires the construction of a development environment for Shell script execution. After replacing the computer, the development environment needs to be constructed again, and complex Shell script codes need to be written to meet the needs of firmware update. The programming ability of the operation and maintenance personnel is high, and the operation is complicated. Each time the update task is executed, the script file needs to be modified, and there is a possibility that the code change will cause program BUG. In addition, the serial execution efficiency of the task is low, and the Shell script does not have concurrency capabilities. The task of executing the firmware update needs to be executed serially, that is, the next task can only be executed after waiting for one task to be completed. The operation is not intuitive and clear. The whole process needs to be executed in the terminal, all in string form, and the status of the firmware update task cannot be intuitively and clearly seen. The operation is time-consuming and laborious. There is no corresponding task log. When a problem occurs, it takes time and energy to troubleshoot the problem. Summary of the invention

[0003] The present invention provides a cross-platform visualization server firmware concurrent update method and device, aiming to solve at least one of the technical problems existing in the prior art.

[0004] The technical solution of the present invention is a cross-platform visualization server firmware concurrent update method, which is applied to a cross-platform visualization server firmware concurrent update device, which includes an installation package construction module, a session management module, a data parsing module and a task distribution module. The cross-platform visualization server firmware concurrent update device is installed on a host computer and also includes multiple servers whose firmware is to be updated. The host computer is respectively connected to the multiple servers to be updated through a network device. The cross-platform visualization server firmware concurrent update method includes the following steps:

[0005] S100, if the host computer does not have a cross-platform visual server firmware concurrent update device, the installation package construction module constructs the installation package based on the Electron framework, selects the Windows or Linux compilation environment for construction according to the platform architecture of the host computer, and then installs the constructed installation package on the host computer;

[0006] S200, if the data of the server whose firmware is to be updated does not exist, the host computer must import or add the server data and store the server data in the host computer;

[0007] S300, based on the server and firmware type of the firmware to be updated, the device front end on the host computer initiates a request to the back-end session management module to obtain a Session ID, and then the front end sends the obtained Session ID, necessary firmware update-related data and the HTTP address of the firmware package to the back-end data parsing module;

[0008] S400, after receiving the data packet, the data parsing module performs data verification, calls the task distribution module to distribute tasks, generates a corresponding number of threads based on the number of server devices that need to be updated, and the threads execute the update tasks to update the corresponding firmware on the corresponding servers;

[0009] S500. When executing the update task, the host computer displays the update task progress in real time, and displays the result and details of the success or failure of each server firmware update task.

[0010] Further, in step S100,

[0011] S110. If the host computer is a Windows platform, it is necessary to build a Windows platform installation package. First, build the backend executable file in the compilation environment under the Windows platform, and then build the Windows platform installation package based on the configuration file of the Windows installation package in the Electron framework;

[0012] S120. If the host computer is a Linux platform, it is necessary to build a Linux platform installation package. First, build the device backend executable file in the compilation environment under the Linux platform, and then build the Linux platform installation package based on the configuration file of the Linux installation package in the Electron framework.

[0013] Further, the step S110 includes:

[0014] S111. Execute the npm run build command to build the installation package, specifically execute node build_python.js &&vite build && electron-builder, where node build_python.js is a command for building the backend executable file of the device, and the vite build && electron-builder command is a command used to build the installation package;

[0015] S112, copy the built backend executable file pl_tool.exe to the project directory tools / server, and pack tools / server into the installation package, and call it from the front end when the device is running;

[0016] S113, the Electron framework builds a Windows installation package based on the Windows installation package configuration items in the configuration file electron-builder.json5, where the configuration file at least includes a Windows program icon field, a program execution level field, an installation package building tool field, a platform architecture field, an installation package name field, and a program name field;

[0017] S114. Generate a Windows installation package.

[0018] Further, the step S120 includes:

[0019] S121. Execute the npm run build:linux command to build the installation package. Specifically, execute node build_python.js && vite build && electron-builder --linux, where node build_python.js is the command to build the backend executable file.

[0020] S122, copy the built backend executable file pl_tool to the project directory tools / server, and package tools / server into the installation package, and call it from the front end when the device is running;

[0021] S123, the Electron framework builds a Linux installation package based on the Linux installation package configuration items in the configuration file electron-builder.json5, where the configuration items at least include a Linux program icon field, an installation package type field, a platform architecture field, an installation package name field, a program name field, a program category field, a program description field, and a desktop entry information field;

[0022] S124. Generate a corresponding Linux platform installation package.

[0023] Further, the step S200 includes:

[0024] S210, based on a visual operation interface, the host computer imports server information in batches by reading an Excel spreadsheet or increases the server information stored in the host computer by adding a single server;

[0025] S220: The host computer stores the server information in JSON format in the host computer, where the server information at least includes the IP address information, user name, password and port of the server.

[0026] Further, in S300, the firmware types include BIOS firmware, BMC firmware and CPLD firmware, and the BIOS firmware, BMC firmware and CPLD firmware correspond to different installation packages respectively;

[0027] If you choose to update the BIOS firmware, you need to further choose whether to restart the corresponding server. If you choose to update the BMC firmware, you need to choose to update the first image, the second image, and the first image and the second image at the same time. After filling in the address of the firmware file, choose to update the corresponding BMC firmware.

[0028] Further, the step S400 includes:

[0029] S410, the host computer login front end initiates a request to the back-end session management module to obtain a Session ID, and the front end and back end of the device on the host computer communicate based on the Session ID;

[0030] S420, after the host computer obtains the Session ID, it sends the corresponding data packet to the data analysis module, the data analysis module determines the thread that actually executes the task according to the module name field module_name and the task name field task_name in the data packet, and then sends the configuration list config_list and the variable sid containing the Session ID value to the task distribution module;

[0031] S430, the task distribution module loops the configuration list config_list, generates a thread each time the loop is completed, and passes the variable sid containing the Session ID value, the data sending method send_data, and an element in the configuration list config_list to the corresponding thread.

[0032] Furthermore, the data sending method send_data is used by the task distribution module to send data to the front end of the host computer;

[0033] An element in the configuration list config_list at least includes the device IP address, device port port, user password password, user name username, machine model project_name, firmware package file address link link to be upgraded, and whether to restart the machine is_reboot.

[0034] Further, the step S500 includes:

[0035] S510, creating a new virtual environment in the compilation environment of the corresponding platform, and installing the dependent libraries required by the backend in the virtual environment;

[0036] S520, the program will traverse the backend business code directory, obtain the corresponding code module, and generate a spec file;

[0037] S530, based on the spec file, the backend code executable file construction tool PyInstaller generates the executable file of the corresponding platform according to different platforms;

[0038] S540, build the script build_python_for_ps.ps1, build_python_for_sh.sh or build_python_for_linux.sh for the backend executable file, copy the generated binary executable file of the corresponding platform to the tools / server directory, and the installation package building module packages it to the specified location. After the installation package is installed, the device front end will call the corresponding backend executable file;

[0039] S550, returning the task progress and update success or failure information to the host computer in real time.

[0040] Furthermore, the present invention also proposes a cross-platform visualization server firmware concurrent update device, which is used to execute the cross-platform visualization server firmware concurrent update method, and the cross-platform visualization server firmware concurrent update device is installed on a host computer, and the cross-platform visualization server firmware concurrent update device includes:

[0041] Installation package building module, used to generate installation packages for Windows platform or Linux platform;

[0042] The session management module is used to generate the session ID for the communication between the front-end and back-end of the device, create and destroy sessions, and manage the entire session life cycle;

[0043] The data analysis module is used to analyze the data sent by the operation and maintenance personnel at the front end of the device. The analyzed data will be forwarded to the task distribution module;

[0044] A task distribution module is connected to the data analysis module, and after the task distribution module distributes the task to the corresponding thread, each thread is connected to the server to be updated with firmware based on the HTTP protocol, and the concurrent update of the corresponding server firmware is achieved by sending HTTP requests.

[0045] The beneficial effects of the present invention are:

[0046] The cross-platform visual server firmware concurrent update method and device provide a clear and intuitive operation interface, and have the ability to perform tasks across platforms and concurrently. The device can be installed and used with one click, and performs firmware update tasks simply and efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 The overall flow chart of the cross-platform visual server firmware concurrent update method.

[0048] Figure 2 A flowchart of the installation package building steps in the cross-platform visualization server firmware concurrent update method.

[0049] Figure 3 Flowchart built for the backend executable in the cross-platform visualization server firmware concurrent update method.

[0050] Figure 4 Schematic diagram of the front-end and back-end communication connections for the cross-platform visualization server firmware concurrent update method.

[0051] Figure 5 A schematic diagram of the front-end and back-end communication process of the cross-platform visualization server firmware concurrent update method.

[0052] Figure 6 The present invention is a schematic diagram of the progress, result, result details and HTTP address of the BIOS firmware package in a BIOS firmware update for a cross-platform visual server firmware concurrent update method. DETAILED DESCRIPTION

[0053] The following will be combined with the embodiments and drawings to clearly and completely describe the concept, specific structure and technical effects of the present invention, so as to fully understand the purpose, scheme and effect of the present invention. It should be noted that the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0054] It should be noted that, unless otherwise specified, when a feature is referred to as being "fixed" or "connected" to another feature, it may be directly fixed or connected to the other feature, or it may be indirectly fixed or connected to the other feature. In addition, the descriptions of up, down, left, right, top, bottom, etc. used in the present invention are only relative to the relative positional relationship of the components of the present invention in the drawings.

[0055] In addition, unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art. The terms used in this specification are only for describing specific embodiments, not for limiting the present invention. The term "and / or" used herein includes any combination of one or more related listed items.

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

[0057] Reference Figures 1 to 6 In some embodiments, the technical solution of the present invention is a cross-platform visualization server firmware concurrent update method, the cross-platform visualization server firmware concurrent update method is applied to a cross-platform visualization server firmware concurrent update device, the cross-platform visualization server firmware concurrent update device includes an installation package construction module, a session management module, a data parsing module and a task distribution module, the cross-platform visualization server firmware concurrent update device is installed on a host computer, and also includes multiple servers to be updated, the host computer is connected to multiple servers of firmware to be updated (usually including a combination of one or more firmware of BMC firmware, BIOS firmware and CPLD firmware) through a network device, refer to Figure 1 The cross-platform visualization server firmware concurrent update method comprises the following steps:

[0058] S100, if the host computer does not have a cross-platform visual server firmware concurrent update device, the installation package construction module constructs the installation package based on the Electron framework, selects the Windows or Linux compilation environment for construction according to the platform architecture of the host computer, and then installs the constructed installation package on the host computer;

[0059] S200, if the data of the server whose firmware is to be updated does not exist, the host computer must import or add the server data and store the server data in the host computer;

[0060] S300, based on the server and firmware type of the firmware to be updated, the device front end on the host computer initiates a request to the back-end session management module to obtain a Session ID, and then the front end sends the obtained Session ID, necessary firmware update-related data and the HTTP address of the firmware package to the back-end data parsing module;

[0061] S400, after receiving the data packet, the data parsing module performs data verification, calls the task distribution module to distribute tasks, generates a corresponding number of threads based on the number of server devices that need to be updated, and the threads execute the update tasks to update the corresponding firmware on the corresponding servers;

[0062] S500. When executing the update task, the host computer displays the update task progress in real time, and displays the result and details of the success or failure of each server firmware update task.

[0063] The beneficial effects of the present invention are:

[0064] The cross-platform visual server firmware concurrent update method and device provide a clear and intuitive operation interface, and have the ability to perform tasks across platforms and concurrently. The device can be installed and used with one click, and performs firmware update tasks simply and efficiently.

[0065] The cross-platform visualization server firmware concurrent update method and device have cross-platform capabilities and meet the needs of using different operating systems. Since the company's internal operation and maintenance can only use a certain operating system, such as the domestic Linux operating system with ARM architecture, this device provides different operating system installation packages such as Windows, Linux ARM / X86 architecture, DEB / RPM, etc., to realize a cross-platform operation device.

[0066] The cross-platform visual server firmware concurrent update method and device are simple and efficient to operate. They only require a computer that can run the system and can be used after installation. The operation interface is intuitive and clear. The operation and maintenance personnel only need to click on the interface to complete the firmware update task.

[0067] The cross-platform visual server firmware concurrent update method and device saves a lot of energy and time of operation and maintenance personnel, and executes tasks concurrently. Once the device issues an update task, all tasks will be executed concurrently at the same time, saving a lot of time and energy costs and greatly improving operation and maintenance efficiency.

[0068] The cross-platform visualization server firmware concurrent update method and device perform a variety of firmware update tasks. The device can update BMC, BIOS, and CPLD firmware to meet the daily work needs of operation and maintenance personnel.

[0069] The cross-platform visual server firmware concurrent update method and device have low requirements on the programming ability of operation and maintenance personnel. They only need to read the device document once to directly operate the device to perform the firmware update task.

[0070] The cross-platform visualization server firmware concurrent update method and device have complete operation records during task execution, which is convenient for operation and maintenance personnel to troubleshoot problems when problems occur during task execution.

[0071] Specifically, the cross-platform visualization server firmware concurrent update method and device have cross-platform capabilities, and are based on Electron, an open source framework for building cross-platform desktop applications, to build an installation package for the device program running on Windows / Linux platforms. The device has cross-platform capabilities, which are specifically implemented by modifying the configuration file for Electron to compile and build the installation package, executing the corresponding build command on different platforms, and generating the installation package for the corresponding platform; the backend architecture for concurrent tasks is also cross-platform, and an automated installation package building tool is executed to integrate the backend executable binary package into the installation package to achieve cross-platform capabilities.

[0072] In step S500, the cross-platform visualization server firmware concurrent update device has visualization capability, based on Electron combined with the browser Chromium rendering engine, so that the device can use the front-end framework Vue to write front-end code to achieve the visualization capability of the device.

[0073] In a specific embodiment, the following updating steps are generally included:

[0074] 1) Update the server firmware on a Windows computer, taking BIOS as an example.

[0075] (1) Build the installation package for the device on the Windows platform in the compilation environment. Refer to the following installation package building process:

[0076] electron-builder version=24.6.4 os=10.0.22631

[0077] loaded configuration file=D:\coding\XXX-TOOL\electron-builder.json5

[0078] writing effective config file=release\builder-effective-config.yaml

[0079] packaging platform=win32 arch=x64 electron=28.1.4 appOutDir=release\win-unpacked

[0080] building target=nsis file=release\XXXManagementTool_Setup_1.1.1.exearchs=x64 oneClick=false perMachine=true

[0081] building block map blockMapFile=release\XXXManagementTool_Setup_1.1.1.exe.blockmap

[0082] After the installation package building module is built in the compilation environment, a Windows platform installation package ending with exe will be generated;

[0083] (2) Take out the installation package file with the suffix exe and install it on the host computer. Then, a device icon will appear on the desktop. Double-click the icon to run the device.

[0084] (3) New equipment can be imported from Excel or a single equipment can be created;

[0085] (4) After adding the device, select the device that needs to update the BIOS firmware.

[0086] (5) After selecting the device, select BIOS as the firmware type to be updated, fill in the HTTP address of the firmware file to be updated, and then click Update;

[0087] (6) During the firmware update, you can view the task progress, update results, and update result details. Figure 6 , which shows the result of a BIOS upgrade. The figure shows the HTTP address of the firmware package, firmware upgrade progress, upgrade status, upgrade results, and upgrade details that can be viewed by clicking.

[0088] 2) The firmware update of the host computer under the Linux platform is basically the same as that of the Windows platform. Taking the Ubuntu system under the RAM architecture as an example, update the BIOS.

[0089] (1) Build the installation package for the device on the Linux platform in the compilation environment. Refer to the following installation package building process:

[0090] electron-builder version=24.13.3 os=5.15.0-117-generic

[0091] loaded configuration file= / home / tree / POWER-TOOL / electron-builder.json5

[0092] writing effective config file=release / builder-effective-config.yaml

[0093] packaging platform=linux arch=x64 electron=28.3.3 appOutDir=release / linux-unpacked

[0094] building target=deb arch=x64

[0095] file=release / PowerleaderManagementTool_1.1.1_amd64.deb

[0096] packaging platform=linux arch=arm64 electron=28.3.3 appOutDir=release / linux-arm64-unpacked

[0097] building target=deb arch=arm64

[0098] file=release / PowerleaderManagementTool_1.1.1_arm64.deb

[0099] building target=rpm arch=x64

[0100] file=release / PowerleaderManagementTool_1.1.1_x86_64.rpm

[0101] building target=rpm arch=arm64

[0102] file=release / PowerleaderManagementTool_1.1.1_aarch64.rpm

[0103] After the build module is built, four installation packages ending with amd64.deb, arm64.deb, x86_64.rpm, and aarch64.rpm will be generated;

[0104] (2) Take out the installation package file with the suffix arm64.deb and install it on the host computer. Then a device icon will appear on the desktop. Double-click the icon to run the device.

[0105] (3) New equipment can be imported from Excel or a single equipment can be created;

[0106] (4) After adding the device, select the device that needs to update the BIOS firmware.

[0107] (5) After selecting the device, select BIOS as the firmware type to be updated, fill in the HTTP address of the firmware file to be updated, and then click Update;

[0108] (6) During the firmware update, you can view the task progress, update results, and update result details.

[0109] Further, refer to Figure 2 and Figure 3 In the step S100,

[0110] S110. If the host computer is a Windows platform, it is necessary to build a Windows platform installation package. First, build the backend executable file in the compilation environment under the Windows platform, and then build the Windows platform installation package based on the configuration file of the Windows installation package in the Electron framework;

[0111] S120. If the host computer is a Linux platform, it is necessary to build a Linux platform installation package. First, build the device backend executable file in the compilation environment under the Linux platform, and then build the Linux platform installation package based on the configuration file of the Linux installation package in the Electron framework.

[0112] Specifically, refer to Figure 2 and Figure 3 The construction of installation packages for different platforms needs to be on the corresponding platforms. For example, the Windows platform installation package needs to be built in the Windows compilation environment, and the Linux platform installation package needs to be built in the Linux compilation environment.

[0113] Further, refer to Figure 2 , the step S110 comprises:

[0114] S111. Execute the npm run build command to build the installation package, specifically execute node build_python.js &&vite build && electron-builder, where node build_python.js is a command for building the backend executable file of the device, and the vite build && electron-builder command is a command used to build the installation package;

[0115] S112, copy the built backend executable file pl_tool.exe to the project directory tools / server, and pack tools / server into the installation package, and call it from the front end when the device is running;

[0116] S113, the Electron framework builds a Windows installation package based on the Windows installation package configuration items in the configuration file electron-builder.json5, where the configuration file at least includes a Windows program icon field, a program execution level field, an installation package building tool field, a platform architecture field, an installation package name field, and a program name field;

[0117] S114. Generate a Windows installation package.

[0118] In a specific embodiment, if the Windows platform installation package is built, the npm run build command is executed for construction. The command actually executed is node build_python.js && vite build && electron-builder, where node build_python.js is a command for building the backend code as an executable file, and then the built executable file pl_tool.exe is copied to the project directory tools / server. When the installation package is built, tools / server will be packaged into the installation package, and the front end will call it when the program is running. The vite build && electron-builder command is the command used to build the platform installation package.

[0119] After building the backend code executable file, Electron starts building the installation package for the Windows platform based on the configuration file electron-builder.json5. The content of the configuration file is as follows, where the icon field specifies the program icon, the target field specifies the build tool for the installation package under Windows, the arch field specifies the platform architecture, and the artifactName and executableName fields specify the installation package name and program name respectively:

[0120] "win": {

[0121] "icon": "public / favicon.ico",

[0122] "requestedExecutionLevel": "requireAdministrator",

[0123] "target": [

[0124] { "target": "nsis",

[0125] "arch": [

[0126] "x64" ]

[0127] }

[0128] ],

[0129] "artifactName": "xxx_Setup_${version}.${ext}",

[0130] "executableName": "xxx"

[0131] },

[0132] After the build installation package command is executed, a file named

[0133] The installation package of XXXManagementTool_Setup_1.1.1.exe is now complete. After the installation, an executable file named XXXManagementTool.exe will appear.

[0134] Further, refer to Figure 3 , the step S120 comprises:

[0135] S121. Execute the npm run build:linux command to build the installation package. Specifically, execute node build_python.js && vite build && electron-builder --linux, where node build_python.js is the command to build the backend executable file.

[0136] S122, copy the built backend executable file pl_tool to the project directory tools / server, and package tools / server into the installation package, and call it from the front end when the device is running;

[0137] S123, the Electron framework builds a Linux installation package based on the Linux installation package configuration items in the configuration file electron-builder.json5, where the configuration items at least include a Linux program icon field, an installation package type field, a platform architecture field, an installation package name field, a program name field, a program category field, a program description field, and a desktop entry information field;

[0138] S124. Generate a corresponding Linux platform installation package.

[0139] Specifically, in step S123, the installation package related fields are set as needed, and the Debian series installation package type DEB and the Red Hat series RPM installation package type can be set. The platform architecture field can also be set as needed, and the options that can be set include X64 platform architecture and ARM64 platform architecture.

[0140] In a specific embodiment, if the installation package is built on a Linux platform, the construction process is similar to that on a Windows platform. To build the installation package in a Linux environment, the npm run build:linux command is executed to build it. The command actually executed is: node build_python.js && vite build && electron-builder --linux, where nodebuild_python.js is a command for building the backend code as an executable file, and then the built executable file pl_tool is copied to the project directory tools / server. When the installation package is built, tools / server will be packaged into the installation package, and the front end will call it when the program is running, and then the vite build && electron-builder --linux command will be executed to build the Linux platform installation package.

[0141] After executing the construction of the backend code executable file, Electron starts to build the installation package for the Linux platform based on the configuration file electron-builder.json5. The content of the configuration file is as follows, where the icon field specifies the program icon, the target field specifies the packaged installation package type, which is the Debian series installation package type deb and the Red Hat series installation package type rpm, the platform architecture is x64 and arm64, artifactName and executableName are the installation package name and program name, the category field specifies the program category, the description field specifies the program description, and the desktop field is the Linux desktop entry information:

[0142] "linux": {

[0143] "icon": "public / icons",

[0144] "target": [

[0145] { "target": "deb",

[0146] "arch": [

[0147] "x64",

[0148] "arm64" ]

[0150] },

[0151] { "target": "rpm",

[0152] "arch": [

[0153] "x64",

[0154] "arm64" ]

[0156] }

[0157] ],

[0158] "artifactName": "PowerleaderManagementTool_${version}_${arch}.${ext}",

[0159] "executableName": "PowerleaderManagementTool",

[0160] "category": "Utility",

[0161] "description": "Powerleader Management Tool",

[0162] "desktop": {

[0163] "Name": "PowerleaderManagementTool",

[0164] "Comment": "Powerleader Management Tool",

[0165] "Categories": "Utility;"

[0166] }}

[0167] After the installation package building task is completed, four Linux installation packages will be generated. At this point, the Linux platform installation package building is complete. Install different installation packages according to different types of operating systems on the host computer.

[0168] The four installation packages are:

[0169] XXXManagementTool_1.1.1_aarch64.rpm、

[0170] XXXManagementTool_1.1.1_arm64.deb、

[0171] XXXManagementTool_1.1.1_amd64.deb and

[0172] XXXManagementTool_1.1.1_x86_64.rpm.

[0173] When building the backend executable file, the installation package building module will package all the backend dependent packages and resources into a binary file, saving the trouble of configuring resources. This method is the basis for the device to be installed and ready to use. The backend build executes the node build_python.js command. The general logic of the command execution is to execute the corresponding build backend executable script according to the platform being built. If it is a Linux platform, execute the build_python_for_linux.sh script. On the Windows platform, execute the build_python_for_ps.ps1 or build_python_for_sh.sh script according to different terminals:

[0174] The content of build_python.js is as follows:

[0175] const { execSync} = require('child_process');

[0176] const os = require('os');

[0177] const isWindows = os.platform() === 'win32';

[0178] const isLinux = os.platform() === 'linux';

[0179] const isGitBash = process.env.MSYSTEM === 'MINGW64' ||process.env.MSYSTEM === 'MINGW32';

[0180] try {

[0181] if (isLinux) {

[0182] / / If it is a Linux platform, execute the Bash script

[0183] execSync('bash build_python_for_linux.sh', { stdio: 'inherit'});

[0184] } else if (isWindows) {

[0185] if (isGitBash) {

[0186] / / If it is Git Bash on Windows, execute the Bash script

[0187] execSync('bash build_python_for_sh.sh', { stdio: 'inherit'});

[0188] } else {

[0189] / / If it is Windows but not Git Bash, execute the PowerShell script

[0190] execSync('powershell -Command "& { Set-ExecutionPolicy Bypass -Scope Process -Force}; .\\build_python_for_ps.ps1"', { stdio: 'inherit'});

[0191] }

[0192] } else {

[0193] console.error('Unsupported operating system');

[0194] process.exit(1);

[0195] }

[0196] } catch (error) {

[0197] console.error('Error running script:', error);

[0198] process.exit(1);

[0199] }

[0200] build_python_for_ps.ps1 file:

[0201] # Virtual environment directory

[0202] $ENV_NAME = "myenv"

[0203] # Enter the python project

[0204] cd "socketio_server"

[0205] # Determine whether a virtual environment exists

[0206] if (-not (Test-Path $ENV_NAME)) {

[0207] Write-Host -ForegroundColor Green "Creating virtualenvironment..."

[0208] python -m venv $ENV_NAME

[0209] Write-Host -ForegroundColor Green "The virtual environment iscreated"

[0210] }

[0211] # Activate the virtual environment

[0212] Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

[0213] . .\$ENV_NAME\Scripts\Activate

[0214] # Install dependent packages

[0215] Write-Host -ForegroundColor Green "Install python dependencies in avirtual environment..."

[0216] pip install -r requirements.txt > $null

[0217] Write-Host -ForegroundColor Green "The virtual environment pythondependency installation is completed"

[0218] # Generate documentation

[0219] cd "docs"

[0220] sphinx-build -b html source\ build\ > $null

[0221] # Pack

[0222] cd ..

[0223] cd "build"

[0224] python setup.py

[0225] # The server directory may not exist

[0226] if (-not (Test-Path ".. / .. / tools / server")) {

[0227] New-Item -ItemType Directory -Path ".. / .. / tools / server / "

[0228] }

[0229] # Copy to the server directory

[0230] Copy-Item -Recurse "dist\pl_tool.exe" ".. / .. / tools / server / "

[0231] Write-Host "`nPython Project Compiled Successfully!"

[0232] # Exit the virtual environment

[0233] deactivate

[0234] build_python_for_sh.sh file

[0235] #! / bin / bash

[0236] # Virtual environment directory

[0237] ENV_NAME="myenv"

[0238] # Enter the python project

[0239] cd socketio_server

[0240] # Determine whether a virtual environment exists

[0241] if [ ! -d "${ENV_NAME}" ]; then echo -e "\e[32mCreating virtual environment...\e[0m\n"; python -m venv ${ENV_NAME}; echo -e "\e[32mVirtual environment created\e[0m\n" ;fi

[0242] # Activate the virtual environment

[0243] source ${ENV_NAME} / Scripts / activate

[0244] # Install dependent packages

[0245] echo -e "\e[32mInstall Python dependencies in virtual environment...\e[0m\n"

[0246] pip install -r requirements.txt 1> / dev / null

[0247] echo -e "\e[32mVirtual environment Python dependency installation completed\e[0m\n"

[0248] # Generate documentation

[0249] cd docs

[0250] sphinx-build -b html source / build / 1> / dev / null

[0251] # Pack

[0252] cd -

[0253] cd build

[0254] python setup.py

[0255] # The server directory may not exist

[0256] if [ ! -d ".. / .. / tools / server" ]; then mkdir .. / .. / tools / server / ; fi

[0257] # Copy to the serevr directory

[0258] cp -r dist / pl_tool.exe .. / .. / tools / server /

[0259] echo -e "\n\e[32mPython Project Compiled Successfully!\e[0m\n"

[0260] # Exit the virtual environment

[0261] deactivate

[0262] build_python_for_linux.sh file:

[0263] #! / bin / bash

[0264] # Virtual environment directory

[0265] ENV_NAME="myenv"

[0266] # Enter the python project

[0267] cd socketio_server

[0268] # Determine whether a virtual environment exists

[0269] if [ ! -d "${ENV_NAME}" ]; then echo -e "\e[32mCreating virtual environment...\e[0m\n"; python -m venv ${ENV_NAME}; echo -e "\e[32mVirtual environment created\e[0m\n" ;fi

[0270] # Activate the virtual environment

[0271] source ${ENV_NAME} / bin / activate

[0272] # Install dependent packages

[0273] echo -e "\e[32mInstall Python dependencies in virtual environment...\e[0m\n"

[0274] pip install -r requirements.txt 1> / dev / null

[0275] echo -e "\e[32mVirtual environment Python dependency installation completed\e[0m\n"

[0276] # Generate documentation

[0277] cd docs

[0278] sphinx-build -b html source / build / 1> / dev / null

[0279] # Pack

[0280] cd -

[0281] cd build

[0282] python setup.py

[0283] # The server directory may not exist

[0284] if [ ! -d ".. / .. / tools / server" ]; then mkdir .. / .. / tools / server / ; fi

[0285] # Copy to the serevr directory

[0286] cp -r dist / pl_tool .. / .. / tools / server /

[0287] echo -e "\n\e[32mPython Project Compiled Successfully!\e[0m\n"

[0288] # Exit the virtual environment

[0289] deactivate

[0290] Further, the step S200 includes:

[0291] S210, based on a visual operation interface, the host computer imports server information in batches by reading an Excel spreadsheet or increases the server information stored in the host computer by adding a single server;

[0292] S220: The host computer stores the server information in JSON format in the host computer, where the server information at least includes the IP address information, user name, password and port of the server.

[0293] Specifically, after installing the device, the user needs to add a device when using it for the first time. This can be achieved by importing an Excel spreadsheet containing multiple device IP information or creating a separate device. Devices can then be added or deleted. After the device is added successfully, the device will return the corresponding device information and store it in a local json file. When executing a task, the device will read the json file and display the corresponding device IP address on the page. The operation and maintenance personnel can check the IP address to execute the firmware update task of the device corresponding to the IP address.

[0294] Further, in S300, the firmware types include BIOS firmware, BMC firmware and CPLD firmware, and the BIOS firmware, BMC firmware and CPLD firmware correspond to different installation packages respectively;

[0295] If you choose to update the BIOS firmware, you need to further choose whether to restart the corresponding server. If you choose to update the BMC firmware, you need to choose to update the first image, the second image, and the first image and the second image at the same time. After filling in the address of the firmware file, choose to update the corresponding BMC firmware.

[0296] Specifically, BMC has two chips on the motherboard, each chip has a firmware, mainly to improve reliability and manageability. Generally, the first BMC chip is used, and the other is used as a backup. When updating, you can choose to update the firmware of the first chip, or update the firmware of the second chip (backup), or update both the first image and the second image at the same time, and the image can be understood as a firmware file.

[0297] Further, refer to Figure 4 and Figure 5 , the step S400 includes:

[0298] S410, the host computer login front end initiates a request to the back-end session management module to obtain a Session ID, and the front end and back end of the device on the host computer communicate based on the Session ID;

[0299] S420, after the host computer obtains the Session ID, it sends the corresponding data packet to the data analysis module, the data analysis module determines the thread that actually executes the task according to the module name field module_name and the task name field task_name in the data packet, and then sends the configuration list config_list and the variable sid containing the Session ID value to the task distribution module;

[0300] S430, the task distribution module loops the configuration list config_list, generates a thread each time the loop is completed, and passes the variable sid containing the Session ID value, the data sending method send_data, and an element in the configuration list config_list to the corresponding thread.

[0301] In a specific embodiment, after selecting the updated firmware for firmware update, the front end constructs data and sends it to the back end service. After the back end receives the data, it performs a simple data check and then starts distributing tasks. It generates a corresponding number of threads based on the number of devices and starts executing the update task.

[0302] Further, refer to Figure 4 and Figure 5 , the data sending method send_data is used by the task distribution module to send data to the front end of the host computer;

[0303] An element in the configuration list config_list includes at least the device IP address, device port port, user password password, user name username, machine model project_name, firmware package file address link link to be upgraded, and whether to restart the machine is_reboot.

[0304] Specifically, the cross-platform visualization server firmware concurrent update method has concurrent capabilities, and is based on the programming language Python and its technology stack to build a backend service, so that the device has the ability to execute tasks concurrently. The specific implementation is: the front end of the device obtains the Session ID from the backend session module, and the front end connects to the backend service through the Session ID; data is sent, and after the front end connects to the backend service, the corresponding firmware update data and the Session ID are sent to the backend together. The data parsing module determines the thread that actually executes the task according to the module_name and task_name in the sent data, and then passes the config_list and sid (a variable containing the Session ID value) to the task distribution module. The task distribution module loops the config_list, generates a thread each time it loops, and passes the sid, send_data method, and an element in the config_list to the thread, and then the thread starts to execute the task. The send_data method is used for the back end to send data to the front end, and an element in the config_list contains the device ip, device port port, user password password, username username, machine model project_name, firmware package file address link to be upgraded, and whether to restart the machine is_reboot.

[0305] Taking updating the BIOS as an example, the data sent is as follows:

[0306] { "module_name": "model.update_service.update_bios",

[0307] "sid": sid,

[0308] "task_name": "TaskManager",

[0309] "config_list": [{

[0310] "ip": "192.168.44.38",

[0311] "port": "443",

[0312] "username": "admin",

[0313] "password": "Admin123.",

[0314] "project_name": "XXX",

[0315] "link":"https: / / test.hpm",

[0316] "is_reboot": false,},

[0317] {"ip": "192.168.44.53",

[0318] "port": "443",

[0319] "username": "admin",

[0320] "password": "Admin123.",

[0321] "project_name": "XXX",

[0322] "link":"https: / / test.hpm",

[0323] "is_reboot": false,},

[0324] ]}.

[0325] After the task distribution module distributes each task to the corresponding thread, the thread starts to execute the corresponding task. After that, each thread sends the execution progress, results, and operation logs to the front end, and the front end is responsible for displaying the data sent by the back end. The data sent is as follows: the thread will call send_data(sid, data) to send data to the front end, where sid is the session id, which is used by the front end to identify this connection, and data is the specific data during the execution process. When type is 1, it is the returned task execution progress, progress is the specific progress, when type is 0, it is the result of the last execution, message is the description of the result of the execution task, and result is the success or failure of the execution. When it is 0, it is successful, and when it is 1, the execution of the task fails. The front end renders these data according to the returned data as visual data to present to the operation and maintenance personnel.

[0326] {"ip":"ip",

[0327] "port":"port",

[0328] "type":1,

[0329] "progress":50

[0330] "message": message,

[0331] "result": 0

[0332] }

[0333] Further, the step S500 includes:

[0334] S510, creating a new virtual environment in the compilation environment of the corresponding platform, and installing the dependent libraries required by the backend in the virtual environment;

[0335] S520, the program will traverse the backend business code directory, obtain the corresponding code module, and generate a spec file;

[0336] S530, based on the spec file, the backend code executable file construction tool PyInstaller generates the executable file of the corresponding platform according to different platforms;

[0337] S540, build the script build_python_for_ps.ps1, build_python_for_sh.sh or build_python_for_linux.sh of the backend executable file, copy the generated executable file of the corresponding platform to the tools / server directory, and the installation package building module packages it to the specified location. After the installation package is installed, the front-end program of the device will call the back-end executable file of the corresponding platform;

[0338] S550, returning the task progress and update success or failure information to the host computer in real time.

[0339] Specifically, in step S550, the thread will call send_data(sid, data) to send data to the front end, where sid is the Session ID, which is used by the front end to identify this connection, and data is the specific data in the execution process. When type is 1, it is the returned task execution progress, progress is the specific progress, when type is 0, it is the result of the last execution, message is the description of the result of the task execution, and result is the success or failure of the execution. When it is 0, it is success, and when it is 1, the task execution fails. The front end renders the returned data as visual data to the operation and maintenance personnel.

[0340] {"ip":"ip",

[0341] "port":"port",

[0342] "type":1,

[0343] "progress":50

[0344] "message": message,

[0345] "result": 0}

[0346] Furthermore, the present invention also proposes a cross-platform visualization server firmware concurrent update device, which is used to execute the cross-platform visualization server firmware concurrent update method, and the cross-platform visualization server firmware concurrent update device is installed on a host computer, and the cross-platform visualization server firmware concurrent update device includes:

[0347] Installation package building module, used to generate installation packages for Windows platform or Linux platform;

[0348] The session management module is used to generate the session ID for the communication between the front-end and back-end of the device, create and destroy sessions, and manage the entire session life cycle;

[0349] The data analysis module is used to analyze the data sent by the operation and maintenance personnel at the front end of the device. The analyzed data will be forwarded to the task distribution module;

[0350] A task distribution module is connected to the data analysis module, and after the task distribution module distributes the task to the corresponding thread, each thread is connected to the server to be updated with firmware based on the HTTP protocol, and the concurrent update of the corresponding server firmware is achieved by sending HTTP requests.

[0351] The meanings of some technical terms in this article are as follows:

[0352] Concurrency: Tasks are executed simultaneously.

[0353] Serial: Tasks are executed one by one.

[0354] Firmware: is a special type of software that is embedded in server hardware and provides basic control and operation functions for the hardware. Common firmware includes BMC, BIOS, and CPLD firmware.

[0355] BMC: It is a dedicated microcontroller responsible for remote management and monitoring of the server. It has a corresponding web interface and management background for operation and maintenance / development personnel to use.

[0356] BIOS: is the first software program that runs when the computer starts.

[0357] CPLD: A programmable logic device used to implement specific hardware functions.

[0358] ARM / X86: They are different underlying architectures of computer hardware, and different hardware architectures run corresponding operating systems.

[0359] DEB / RPM: Common installation package formats in Linux distributions. The .deb format is mainly used for Debian series operating installation packages, and the .rpm format is mainly used for Red Hat series system installation packages.

[0360] Device front end: provides a visual operation interface, is used to send relevant data of firmware update, receives the results and progress of firmware update, and renders it into visual data for operation and maintenance personnel to view.

[0361] Device backend: receives data sent by the frontend, executes corresponding tasks, and returns task progress and results to the frontend, etc.

[0362] The above is only a preferred embodiment of the present invention. The present invention is not limited to the above implementation. As long as the technical effect of the present invention is achieved by the same means, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the scope of protection of the present disclosure. All should belong to the protection scope of the present invention. Within the protection scope of the present invention, its technical scheme and / or implementation method can have various modifications and changes.

Claims

1. A cross-platform visualization server firmware concurrent update method, the cross-platform visualization server firmware concurrent update method is applied to a cross-platform visualization server firmware concurrent update device, the cross-platform visualization server firmware concurrent update device includes an installation package construction module, a session management module, a data parsing module and a task distribution module, the cross-platform visualization server firmware concurrent update device is installed on a host computer, and also includes multiple servers to be updated with firmware, the host computer is connected to the multiple servers to be updated through a network device, characterized in that, The cross-platform visualization server firmware concurrent update method comprises the following steps: S100, if the host computer does not have a cross-platform visual server firmware concurrent update device, the installation package construction module constructs the installation package based on the Electron framework, selects the Windows or Linux compilation environment for construction according to the platform architecture of the host computer, and then installs the constructed installation package on the host computer; S200, if the data of the server whose firmware is to be updated does not exist, the host computer must import or add the server data and store the server data in the host computer; S300, based on the server and firmware type of the firmware to be updated, the device front end on the host computer initiates a request to the back-end session management module to obtain a Session ID, and then the front end sends the obtained Session ID, necessary firmware update-related data and the HTTP address of the firmware package to the back-end data parsing module; S400, after receiving the data packet, the data analysis module performs data verification, calls the task distribution module to distribute tasks, generates a corresponding number of threads based on the number of server devices that need to be updated, and the threads execute the update tasks to update the corresponding firmware on the corresponding servers; The step S400 includes: S410, the host computer login front end initiates a request to the back-end session management module to obtain a Session ID, and the front end and back end of the device on the host computer communicate based on the Session ID; S420, after the host computer obtains the Session ID, it sends the corresponding data packet to the data analysis module, the data analysis module determines the thread that actually executes the task according to the module name field module_name and the task name field task_name in the data packet, and then sends the configuration list config_list and the variable sid containing the Session ID value to the task distribution module; S430, the task distribution module loops the configuration list config_list, generates a thread each time the loop is completed, and passes the variable sid containing the Session ID value, the data sending method send_data, and an element in the configuration list config_list to the corresponding thread; The data sending method send_data is used by the task distribution module to send data to the front end of the host computer; An element in the configuration list config_list at least includes the device IP address, device port port, user password password, user name username, machine model project_name, firmware package file address link link to be upgraded, and whether to restart the machine is_reboot; S500. When executing the update task, the host computer displays the update task progress in real time, and displays the result and details of the success or failure of each server firmware update task.

2. The cross-platform visualization server firmware concurrent update method according to claim 1, characterized in that: The step S100 includes: S110. If the host computer is a Windows platform, it is necessary to build a Windows platform installation package. First, build the backend executable file in the compilation environment under the Windows platform, and then build the Windows platform installation package based on the configuration file of the Windows installation package in the Electron framework; S120. If the host computer is a Linux platform, it is necessary to build a Linux platform installation package. First, build the device backend executable file in the compilation environment under the Linux platform, and then build the Linux platform installation package based on the configuration file of the Linux installation package in the Electron framework.

3. The cross-platform visualization server firmware concurrent update method according to claim 2, characterized in that: The step S110 includes: S111. Execute the npm run build command to build the installation package, specifically execute node build_python.js &&vite build && electron-builder, where node build_python.js is a command for building the backend executable file of the device, and the vite build && electron-builder command is a command used to build the installation package; S112, copy the built backend executable file pl_tool.exe to the project directory tools / server, and pack tools / server into the installation package, and call it from the front end when the device is running; S113, the Electron framework builds a Windows installation package based on the Windows installation package configuration items in the configuration file electron-builder.json5, where the configuration file at least includes a Windows program icon field, a program execution level field, an installation package building tool field, a platform architecture field, an installation package name field, and a program name field; S114. Generate a Windows installation package.

4. The cross-platform visualization server firmware concurrent update method according to claim 2, characterized in that: The step S120 includes: S121. Execute the npm run build:linux command to build the installation package. Specifically, execute node build_python.js&& vite build && electron-builder --linux, where node build_python.js is the command to build the backend executable file. S122, copy the built backend executable file pl_tool to the project directory tools / server, and package tools / server into the installation package, and call it from the front end when the device is running; S123, the Electron framework builds a Linux installation package based on the Linux installation package configuration items in the configuration file electron-builder.json5, where the configuration items at least include a Linux program icon field, an installation package type field, a platform architecture field, an installation package name field, a program name field, a program category field, a program description field, and a desktop entry information field; S124. Generate a corresponding Linux platform installation package.

5. The cross-platform visualization server firmware concurrent update method according to claim 1, characterized in that: The step S200 includes: S210, based on a visual operation interface, the host computer imports server information in batches by reading an Excel spreadsheet or increases the server information stored in the host computer by adding a single server; S220: The host computer stores the server information in JSON format in the host computer, where the server information at least includes the IP address information, user name, password and port of the server.

6. The cross-platform visualization server firmware concurrent update method according to claim 1, characterized in that: In the step S300, the firmware types include BIOS firmware, BMC firmware and CPLD firmware; If you choose to update the BIOS firmware, you need to further choose whether to restart the corresponding server. If you choose to update the BMC firmware, you need to choose to update the first image, the second image, and the first image and the second image at the same time. After filling in the address of the firmware file, choose to update the corresponding BMC firmware.

7. The cross-platform visualization server firmware concurrent update method according to claim 1, characterized in that: The step S500 includes: S510, creating a new virtual environment in the compilation environment of the corresponding platform, and installing the dependent libraries required by the backend in the virtual environment; S520, the program will traverse the backend business code directory, obtain the corresponding code module name, and generate a spec file; S530, based on the spec file, the backend code executable file construction tool PyInstaller generates the executable file of the corresponding platform according to different platforms; S540, build the script build_python_for_ps.ps1, build_python_for_sh.sh or build_python_for_linux.sh for the backend executable file, copy the generated binary executable file of the corresponding platform to the tools / server directory, and the installation package building module packages it to the specified location. After the installation package is installed, the device front end will call the corresponding backend executable file; S550, returning the task progress and update success or failure information to the host computer in real time.

8. A cross-platform visualization server firmware concurrent update device, the cross-platform visualization server firmware concurrent update device is used to execute the cross-platform visualization server firmware concurrent update method according to any one of claims 1 to 7, characterized in that: The cross-platform visualization server firmware concurrent update device is installed on a host computer, and the cross-platform visualization server firmware concurrent update device includes: Installation package building module, used to generate installation packages for Windows platform or Linux platform; The session management module is used to generate the session ID for the communication between the front-end and back-end of the device, create and destroy sessions, and manage the entire session life cycle; The data analysis module is used to analyze the data sent by the operation and maintenance personnel at the front end of the device. The analyzed data will be forwarded to the task distribution module; A task distribution module is connected to the data analysis module, and after the distribution module distributes the task to the corresponding thread, each thread is connected to the server to be updated with firmware based on the HTTP protocol, and the concurrent update of the corresponding server firmware is achieved by sending HTTP requests.

Images