A password-free deployment method and device in a Linux environment and a medium

Abstract

The application discloses a Linux environment password-free deployment method, device and medium, which is suitable for terminal cluster, and comprises the following steps: obtaining a plurality of UDP data packets; performing hierarchical verification on the plurality of UDP data packets; if the verification fails or the data of the plurality of UDP data packets is incomplete, reacquiring the plurality of UDP data packets; if the verification succeeds and the data of the plurality of UDP data packets is complete, installing the plurality of UDP data packets to a user directory or a system directory in a preset mode. The application provides a Linux environment password-free deployment method, device and medium, which can reduce the waiting time by transmitting the UDP data packets to the terminal in the form of broadcast; the hierarchical verification of the data packets can ensure the data completeness, the user directory password-free installation is executed, and the system directory installation is executed through the pre-defined password-free strategy, thereby reducing the root permission verification and redundant operation, solving the problem of the redundant operation difficult to eliminate the repeated permission verification, and improving the terminal cluster deployment efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a passwordless deployment method, apparatus and medium in a Linux environment. Background Technology

[0002] In the field of software deployment under Linux systems, package management tools can automate the downloading, dependency resolution, and installation of software packages, significantly simplifying the complexity of software deployment. Administrators can achieve large-scale software deployment simply through command-line commands, without having to manually handle the dependencies and installation steps of each package. Existing technologies commonly use package management tools such as apt-get install or yum install to achieve batch installation of software. When performing file operations involving critical system directories (such as / usr / lib and / etc), this approach requires users to enter the root password through an interactive terminal to obtain the necessary system privileges.

[0003] However, existing technologies have significant drawbacks in software deployment. Users need to enter passwords to access operating system files every time a full package is installed, which is extremely time-consuming and labor-intensive during large-scale deployments. Specifically, the permission verification process is redundant, requiring frequent manual password entry, which increases maintenance costs. Batch deployment is inefficient, and the time cost increases linearly with the number of devices. In addition, storing passwords in plaintext in automated scripts violates the security access control requirements of the ISO / IEC 27001 standard, posing security risks. These problems urgently need to be addressed to optimize the deployment process and improve maintenance efficiency. Summary of the Invention

[0004] This invention provides a passwordless deployment method, apparatus, and medium in a Linux environment to solve the problem of redundant operations that are difficult to eliminate for repeated permission verification, thereby improving the deployment efficiency of terminal clusters.

[0005] To achieve the above objectives, this application provides a passwordless deployment method under a Linux environment, applicable to terminal clusters, including:

[0006] Acquire several UDP data packets; wherein, the several UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in a broadcast manner;

[0007] Perform layered verification on the aforementioned UDP packets;

[0008] If the verification fails or the data of the UDP packets is incomplete, the UDP packets are retrieved again. If the verification succeeds and the data of the UDP packets is complete, the UDP packets are installed without a password to the user directory or to the system directory according to a preset method. The preset method is to execute the installation command with root privileges when the command path and parameters of the UDP packets match the regular expression in the passwordless policy file. The passwordless policy file is generated by a regular expression engine based on the command path and target path declared in the file list of the installation package.

[0009] This invention controls the host to broadcast UDP packets to the terminal cluster, allowing multiple terminals to simultaneously receive and process packets. This batch processing method reduces the waiting time of individual terminals and improves overall deployment efficiency. The terminal cluster performs layered verification on the received UDP packets to ensure data integrity and correctness. Since user directories typically do not contain sensitive files, passwordless installation is possible; however, system directories contain sensitive files, requiring privileged operations and strict access control. Therefore, when installing in the user directory, no password is required, and installation proceeds directly, improving the automation and efficiency of the installation process. For installation in the system directory, traditional deployment methods require the user to enter the root password for verification every time an operation requiring root privileges is performed. In this invention, by pre-defining a passwordless policy file and using regular expressions for matching, the system can directly execute the installation command based on the matching result after confirming the validity of the data packet, without needing to perform password verification each time. This significantly reduces the number of permission verifications, thereby reducing redundant operations.

[0010] Compared to existing technologies, this invention transmits UDP packets to the terminal in a broadcast manner, which can reduce waiting time; layered verification of data packets can ensure data integrity, perform passwordless installation of user directories, and perform system directory installation through predefined passwordless policies, reducing root permission verification and redundant operations. Therefore, it can solve the problem of redundant operations that are difficult to eliminate by repeating permission verification, thereby improving the efficiency of terminal cluster deployment.

[0011] As a preferred approach, layered verification is performed on the aforementioned UDP packets, specifically as follows:

[0012] The plurality of UDP packets are subjected to CRC32 verification based on the check value attached by the host;

[0013] The MD5 checksum of the UDP packets is performed based on the hash value provided by the host.

[0014] In this preferred embodiment, CRC32 checksum can efficiently detect errors at the data bit level, thereby ensuring the integrity of the data packet. MD5 checksum can generate a fixed-length hash value, which is highly sensitive to any minor changes in the data packet content; therefore, MD5 checksum can further reduce the risk of data being incorrectly modified or tampered with.

[0015] As a preferred embodiment, the plurality of UDP packets are subjected to CRC32 verification based on the checksum attached by the host, specifically as follows:

[0016] Obtain an additional first checksum from the end of the preset data of the plurality of UDP packets;

[0017] Calculate the CRC32 checksum value of each UDP packet in the plurality of UDP packets;

[0018] If the CRC32 checksum of each UDP packet matches the corresponding checksum in the first checksum, the UDP packets are considered valid; if the CRC32 checksum of each UDP packet does not match the corresponding checksum in the first checksum, the UDP packets are considered to have been transmitted incorrectly.

[0019] In this preferred scheme, since each data packet undergoes independent CRC32 verification, even if an error occurs in a data packet during transmission, it will not affect the correctness of other data packets. This reduces the risk of error accumulation and makes the transmission of the entire data packet sequence more stable and reliable.

[0020] As a preferred embodiment, the plurality of UDP packets are subjected to MD5 verification based on the hash value provided by the host, specifically as follows:

[0021] After the file transfer is completed, the first hash value of the plurality of UDP packets is obtained from the host;

[0022] Calculate the overall MD5 hash value of the aforementioned UDP packets;

[0023] If the MD5 hash value matches the first hash value, the UDP packets are considered valid; otherwise, the UDP packets are considered to have been transmitted incorrectly.

[0024] In this preferred embodiment, since the MD5 algorithm has good hash distribution characteristics, even a small change in the data packet will cause a significant change in the generated hash value. Therefore, by calculating the overall MD5 hash value of the UDP data packet and comparing it with the first hash value obtained from the host, it is possible to accurately determine whether the data packet remains intact during transmission.

[0025] As a preferred solution, if the verification fails or the data in the plurality of UDP packets is incomplete, the plurality of UDP packets are reacquired, specifically as follows:

[0026] If the layered verification fails, a retransmission request is initiated to the host according to the frame sequence number corresponding to the frame data that failed the verification, and the first target lost frame is obtained.

[0027] Write the first target lost frame into the corresponding position of the plurality of UDP packets to obtain the updated and reassembled plurality of UDP packets;

[0028] If the data of the aforementioned UDP packets is incomplete, then the second target lost frame is obtained based on the frame sequence number of the lost frame;

[0029] The second target lost frame is written into the corresponding position of the plurality of UDP packets to obtain the updated and reassembled plurality of UDP packets.

[0030] In this preferred scheme, once a verification failure is detected, a retransmission request is initiated based on the frame sequence number. This allows for the rapid location and repair of lost or corrupted data frames, thereby improving the reliability of data transmission. By retransmitting only the lost or corrupted frame data, rather than the entire file or data packet, network bandwidth waste can be reduced.

[0031] As a preferred embodiment, if the data of the plurality of UDP packets is incomplete, a second target lost frame is obtained according to the frame sequence number of the lost frame, specifically as follows:

[0032] A corresponding state management byte is created based on the number of slices of the aforementioned UDP packets to record the reception status of each frame;

[0033] When the expected target frame set of the plurality of UDP packets has been received, if the data of the expected target frame set is incomplete, the frames in the expected target frame set whose reception status is not received are defined as lost frames, and the corresponding position of the lost frames in the status management byte is set to zero.

[0034] A retransmission request is initiated to the host based on the sequence number of the lost frame, and the lost frame is reacquired to obtain the second target lost frame; wherein, the sequence number of the lost frame is determined based on the zero bit in the status management byte.

[0035] This preferred solution records the reception status of each frame by creating a status management byte, which clearly tracks the reception of each UDP packet and provides an efficient data foundation for subsequent lost frame detection and retransmission requests. After the expected target frame set has been received, by comparing the status management bytes, it is possible to accurately identify which frames were lost, avoiding unnecessary retransmission requests and improving data transmission efficiency.

[0036] As a preferred embodiment, the password-free policy file is generated using a regular expression engine based on the command path and target path declared in the file list within the installation package, specifically as follows:

[0037] Extract the command path and target path pattern for system directory operations from the file list of the installation package;

[0038] Based on the command path and target path pattern, a command whitelist is generated using a regular expression engine;

[0039] The command whitelist is converted into sudo matching rules, and the sudo matching rules are split into independent atomic strategy files to obtain the passwordless policy file.

[0040] This preferred solution utilizes a regular expression engine to generate a command whitelist, which can accurately match the system directory operation commands required to be executed in the installation package, enhancing the accuracy and specificity of the policy file. The command whitelist is converted into sudo matching rules and broken down into independent atomic policy files, enabling fine-grained control over specific operations, reducing the risk of unauthorized operations, and enhancing system security.

[0041] As a preferred embodiment, the plurality of UDP packets are installed without a password to the user directory or to the system directory according to a preset method, specifically as follows:

[0042] Obtain the target path from the file list of the aforementioned UDP packets;

[0043] The installation process of the UDP packets is executed according to the target path; wherein, if the target path is in the user directory, the UDP packets are decompressed or copied without a password; if the target path is in the system directory, privileged operations are performed on the UDP packets according to the preset method; the privileged operation refers to the automated script executing the copy command with root privileges through pre-configured passwordless sudo rules.

[0044] In this preferred solution, since the user directory belongs to the user and typically does not contain sensitive system files, the risk of passwordless installation is low. However, the system directory contains sensitive system files and configurations, therefore, performing installation operations in these directories requires privileges, and security is ensured through strict access control. Thus, when performing installation in the user directory, no password is required, improving the automation and efficiency of the installation process. When performing privileged operations in the system directory, pre-configured passwordless sudo rules allow the automated script to temporarily execute commands with root privileges, eliminating the need to wait for the user to enter a password and accelerating the installation process.

[0045] This application also provides a passwordless deployment device under Linux environment, suitable for terminal clusters, including a data module, a verification module and an installation module;

[0046] The data module is used to acquire several UDP data packets; wherein the several UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in a broadcast manner;

[0047] The verification module is used to perform layered verification on the plurality of UDP packets;

[0048] The installation module is configured to, if verification fails or the data of the UDP packets is incomplete, reacquire the UDP packets; if verification succeeds and the data of the UDP packets is complete, install the UDP packets to the user directory without a password or to the system directory according to a preset method; wherein, the preset method is to execute the installation command with root privileges when the command path and parameters of the UDP packets match the regular expression in the passwordless policy file; the passwordless policy file is generated by a regular expression engine based on the command path and target path declared in the file list of the installation package.

[0049] This application also provides a storage medium storing a computer program, which is called and executed by a computer to implement the passwordless deployment method in a Linux environment as described above. Attached Figure Description

[0050] Figure 1 This is a flowchart illustrating a passwordless deployment method in a Linux environment provided in an embodiment of this application;

[0051] Figure 2 This is a schematic diagram of the system framework provided in the embodiments of this application;

[0052] Figure 3 This is a schematic diagram illustrating the uploading of the installation package to the terminal according to an embodiment of this application;

[0053] Figure 4 This is a diagram illustrating the terminal frame reception flag bits provided in an embodiment of this application;

[0054] Figure 5 This is a schematic diagram of the frame protocol provided in an embodiment of this application;

[0055] Figure 6 This is a schematic diagram of file frame splicing provided in an embodiment of this application;

[0056] Figure 7 This is a schematic diagram of the one-click installation process provided in an embodiment of this application;

[0057] Figure 8 This is a schematic diagram of a passwordless deployment device under a Linux environment provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" and "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "several" means two or more.

[0060] The passwordless deployment method provided in this application under a Linux environment aims to solve the pain point of requiring manual input of the root password for each operating system directory file in traditional solutions. It achieves single authorization and batch operation through a permission management mechanism; it breaks through the efficiency bottleneck of traditional serial deployment, provides parallel batch deployment capability without manual intervention, decouples operation and maintenance time from the number of devices, and significantly improves efficiency.

[0061] Example 1:

[0062] Please see Figure 1 The embodiments of this application provide a passwordless deployment method in a Linux environment, applicable to terminal clusters, including S1 to S3, and the specific implementation steps are as follows:

[0063] S1. Obtain several UDP data packets; where the several UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in the form of broadcast.

[0064] In this embodiment of the application, step S1 includes S1.1 to S1.2, wherein S1.1 is the process of creating a passwordless policy file and determining the terminal cluster, and S1.2 is the process of the host sending data to the terminal cluster, specifically as follows:

[0065] S1.1 On the local computer's host (i.e., the local host), the operations and maintenance personnel use the one-click upgrade tool to pre-select the installation package stored locally and containing a file manifest; the installation package includes the software package and the files required for software deployment;

[0066] Extract the specific command paths and target path patterns for system directory operations from the file list of the installation package;

[0067] A command whitelist is generated using a regular expression engine based on the command path and target path pattern.

[0068] The command whitelist is converted into sudo matching rules, and these sudo matching rules are then split into independent atomic policy files to obtain the passwordless policy file. "sudo" is the core permission management tool of the Linux system, and the rules defined in its configuration file ( / etc / sudoers) are used to control the permissions of users or programs to execute privileged commands.

[0069] The host sends UDP multicast packets to a specified port of a preset multicast address to determine the terminal cluster. For example, UDP multicast (224.0.0.1:9999) can be used to quickly discover the device cluster; where "224.0.0.1" is the preset multicast address and "9999" is the specified port; in addition, UDP multicast is also used to issue commands.

[0070] The process of creating the passwordless policy file is as follows:

[0071] ① Dynamic permission configuration technology based on installation package feature analysis: By deeply analyzing the file manifest within the installation package, it automatically identifies specific command paths that require operating system directories (e.g., / usr / bin / cp, / bin / mv) and the patterns of target paths (e.g., / usr / lib / *.so, / etc / conf.d / [az].conf). This step provides a precise basis for subsequent permission configuration.

[0072] ② Implementation of the principle of least privilege: To adhere to the principle of least privilege, a regular expression engine is used to dynamically generate a whitelist of commands that match precisely, and then converts this whitelist into sudo matching rules. For example, rules such as " / usr / bin / cp / tmp / [A-Za-z0-9]*.so / usr / lib / " can be generated, thus avoiding the use of global passwordless execution strategies (such as NOPASSWD:ALL) in traditional methods. This approach ensures that only the necessary combination of commands and paths can obtain passwordless execution privileges.

[0073] ③ Atomic Policy Deployment: To enhance policy manageability and security, sudo matching rules are split into independent files (e.g., / etc / sudoers.d / deploy_rule), which are the passwordless policy files. Simultaneously, the `chmod 0440` command ensures these policy files have read-only attributes, preventing unauthorized modification or leakage. Here, "chmod 0440" is a file permission setting command in Linux / Unix systems, which sets permissions for files or directories using octal mode.

[0074] In this embodiment, S1.1, a command whitelist is generated using a regular expression engine. This whitelist can accurately match system directory operation commands that need to be executed in the installation package, enhancing the accuracy and specificity of the policy file. The command whitelist is then converted into sudo matching rules and split into independent atomic policy files, enabling fine-grained control over specific operations, reducing the risk of unauthorized operations, and enhancing system security.

[0075] Furthermore, the risk of unauthorized operations is reduced through policy file permission control (chmod 0440).

[0076] S1.2 In the host, the installation package is divided into several UDP data packets according to the data fragmentation strategy;

[0077] After the operations and maintenance personnel click to confirm, several UDP data packets of the installation package are transmitted to the service program of the terminal cluster in the form of broadcast, and the passwordless policy file is distributed to all terminal devices in the terminal cluster.

[0078] The control terminal cluster obtains several UDP packets and passwordless policy files.

[0079] The data fragmentation strategy is as follows: frames are divided according to MTU = 1500 bytes, and a CRC32 check value (i.e., the first check value) is appended to the end of the preset data of each frame.

[0080] Furthermore, the one-click upgrade tool can achieve multi-threaded communication (based on the epoll model) and supports breakpoint resumption (recording the Last_ACK sequence number). That is, it can utilize Linux's epoll I / O multiplexing mechanism to efficiently manage a large number of concurrent connections, thereby handling data transmission requests from thousands of terminals simultaneously within a single thread, reducing resource consumption and improving broadcast efficiency. It can also customize reliable transmission on the UDP protocol (User Datagram Protocol) by recording the last acknowledged ACK sequence number (Last_ACK) to mark the transmission progress. This allows transmission to resume from the "Last_ACK+1" sequence number after a network interruption, avoiding the retransmission of received data packets.

[0081] In addition, the terminal cluster's service programs include a security sandbox module (Seccomp policy) and can monitor the integrity of the " / etc / sudoers.d / " file in real time (inotify mechanism). This means that the service programs are restricted from making system calls (syscalls) through the Linux kernel's Seccomp (Secure Computing) mechanism, thereby preventing malicious code or accidental execution of dangerous instructions (such as execve, mount) and enhancing the security of the service programs. The inotify API is used to monitor file change events (such as creation, modification, and deletion) in the " / etc / sudoers.d / " directory. When the passwordless policy file (such as deploy_rule) is detected to have been tampered with, an alarm or recovery operation is immediately triggered to ensure the legitimacy of the permission configuration.

[0082] The transmission of several UDP packets uses a persistent transmission strategy, which is designed as follows:

[0083] ① Protocol Header Design: Each UDP packet header contains the following fields: SEQ / ACK sequence number (32 bits): identifies the packet order and reception acknowledgment status. FLAG flag (SYN / ACK / FIN): used to control the start, response, and termination of the transmission session. Frame offset: marks the storage location of data in the file, resolving UDP packet reordering issues. Valid data frame: carries the actual transmitted fragmented content of the installation packet. CHECKSUM checksum (16 bits): verifies the integrity of a single frame of data.

[0084] ② Resume interrupted transmission support: The control terminal cluster persistently records the last successfully received ACK sequence number (Last_ACK). When the transmission is interrupted and resumed, the host resumes the transmission from the sequence number "Last_ACK+1" to avoid retransmitting the received data.

[0085] For examples of this application, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of the system framework provided in the embodiments of this application, which shows the system framework for network communication between a local host and a terminal cluster.

[0086] S2. Perform layered verification on several UDP packets.

[0087] Step S2 in this embodiment includes S2.1 to S2.2, wherein S2.1 is the process of performing CRC32 verification on several UDP data packets, and S2.2 is the process of performing MD5 verification on several UDP data packets, specifically as follows:

[0088] S2.1 In the terminal cluster, obtain the additional first checksum from the preset data end of several UDP packets;

[0089] Calculate the CRC32 checksum of each UDP packet in a set of UDP packets;

[0090] If the CRC32 checksum of each UDP packet matches the corresponding checksum in the first checksum, the checksum is successful and the UDP packets are considered valid; if the CRC32 checksum of each UDP packet does not match the corresponding checksum in the first checksum, the checksum fails and the UDP packets are considered to have been transmitted incorrectly.

[0091] In this embodiment S2.1, since each data packet is checked independently using CRC32, even if an error occurs in a data packet during transmission, it will not affect the correctness of other data packets. This reduces the risk of error accumulation and makes the transmission of the entire data packet sequence more stable and reliable.

[0092] S2.2 After the file transfer is completed, obtain the first hash value of several UDP packets from the host;

[0093] Calculate the overall MD5 hash value of several UDP packets;

[0094] If the MD5 hash value matches the first hash value, the verification is successful, and the UDP packets are considered valid; if they do not match, the verification fails, and the UDP packets are considered to have been transmitted incorrectly.

[0095] Furthermore, the above methods of CRC32 checksum and MD5 checksum can be summarized as layered checksum.

[0096] In this embodiment S2.2, since the MD5 algorithm has good hash distribution characteristics, even if there are only small changes in the data packet, it will cause the generated hash value to change significantly. Therefore, by calculating the overall MD5 hash value of the UDP data packet and comparing it with the first hash value obtained from the host, it is possible to accurately determine whether the data packet remains intact during transmission.

[0097] In summary, the CRC32 checksum in embodiment S2 can efficiently detect errors at the data bit level, thereby ensuring the integrity of the data packet. The MD5 checksum generates a fixed-length hash value, which is highly sensitive to any minor changes in the data packet content; therefore, the MD5 checksum can further reduce the risk of data being incorrectly modified or tampered with.

[0098] S3. If the verification fails or the data of several UDP packets is incomplete, then reacquire several UDP packets; if the verification succeeds and the data of several UDP packets is complete, then install several UDP packets to the user directory without a password or to the system directory according to the preset method; the preset method means that when the command path and parameters of several UDP packets match the regular expression in the passwordless policy file, the installation command is executed with root privileges; the passwordless policy file is generated by the regular expression engine based on the command path and target path declared in the file list in the installation package.

[0099] Step S3 in this embodiment includes S3.1 to S3.2, wherein S3.1 is the process of retransmission control when verification fails or several UDP packets are incomplete, and S3.2 is the process of installing several UDP packets, specifically as follows:

[0100] S3.1 In the terminal cluster, if the layered verification fails, the terminal considers the frame data invalid and initiates a retransmission request to the host according to the frame sequence number corresponding to the frame data that failed the verification, and obtains the first target lost frame.

[0101] The first target lost frame is written to the corresponding position of several UDP packets, resulting in several updated and reassembled UDP packets.

[0102] A corresponding state management byte is created based on the number of UDP packet slices to record the reception status of each frame;

[0103] When the expected target frame set of several UDP packets has been received, if the data of the expected target frame set is incomplete, the frames in the expected target frame set with a received status of not received are defined as lost frames, and the corresponding position of the lost frame in the status management byte is set to zero.

[0104] A retransmission request is initiated to the host based on the sequence number of the lost frame, and the lost frame is reacquired to obtain the second target lost frame; the sequence number of the lost frame is determined based on the zeroed bit in the status management byte, and the "bit" contains both position and status information.

[0105] If all target lost frames in the expected target frame set are successfully received and pass the layered verification, the second target lost frame is written into the corresponding position of several UDP packets to obtain several updated and reassembled UDP packets.

[0106] For examples of this application, please refer to [link / reference]. Figure 3-6 , Figure 3 This is a schematic diagram of the installation package being uploaded to the terminal according to an embodiment of this application, showing the process of the local host uploading the installation package to terminal 4 in the terminal cluster.

[0107] Figure 4 This is a diagram illustrating the terminal frame reception flag bits provided in an embodiment of this application. Figure 5 This is a schematic diagram of the frame protocol provided in an embodiment of this application. Figure 6 This is a schematic diagram of file frame splicing provided in an embodiment of this application;

[0108] When handling UDP packet loss, if a terminal fails to receive a data frame for some reason, it can identify the lost frame through a specific calculation process and send a retransmission request to the host accordingly. The following combines... Figure 4-6 The calculation process (i.e., the process described above where the corresponding data is reacquired if the data of the expected target frame set is incomplete) is summarized as follows:

[0109] Figure 4 This section details how the terminal cluster determines the number of frames a file is divided into based on the "frames" field in the frame protocol. To this end, the control terminal cluster allocates a memory space (consisting of several bytes), where each byte can mark the reception status of 8 frames. For example, if the file is divided into 128 frames, the receiving end needs to allocate 16 bytes to track the reception status of each frame. Whenever a frame is successfully received and verified, the receiving end sets the corresponding bit to 1; if reception fails or times out, the corresponding bit remains 0. After all frame reception attempts have been completed, the control terminal cluster checks these flag bits, identifies bits with a value of 0, determines the sequence number of the lost frame, and initiates a retransmission request to the host. It is important to note that for each frame, the receiving end will attempt to retransmit a maximum of 3 times; if all 3 attempts fail, the receiving end will abandon retransmission of that frame.

[0110] Figure 5 This reveals the specific structure of the frame protocol. The "frame" field indicates the total number of frames in the file, the "cur_frame" field represents the sequence number of the current frame, the "offset" field indicates the location in the file where the current frame data should be stored, and the "data" field contains the valid data content. Furthermore, the "checksum" field is used to validate the "data" field to ensure data accuracy.

[0111] Figure 6 The text emphasizes the potential packet order disorder issue encountered when using the UDP protocol. To address this, the control terminal cluster uses the "offset" field to accurately write received valid data to a specified location in the file. This mechanism ensures that even with network packet order disorder, the data frames written to the file maintain the correct order.

[0112] With this design, the terminal cluster can effectively cope with packet loss in UDP transmission, ensuring data integrity and accuracy.

[0113] In this embodiment S3.1, once a verification failure is detected, a retransmission request is initiated based on the frame sequence number. This allows for the rapid location and repair of lost or corrupted data frames, thereby improving the reliability of data transmission. By retransmitting only the lost or corrupted frame data, rather than the entire file or data packet, network bandwidth waste can be reduced.

[0114] Furthermore, by creating state management bytes to record the reception status of each frame, the reception status of each UDP packet can be clearly tracked, providing an efficient data foundation for subsequent lost frame detection and retransmission requests. After the expected target frame set has been received, by comparing the state management bytes, it is possible to accurately identify which frames were lost, avoiding unnecessary retransmission requests and improving data transmission efficiency.

[0115] S3.2 If the layered verification is successful and the data of several UDP packets is complete, then obtain the target path from the file list of several UDP packets; where successful layered verification includes the case where layered verification of several UDP packets is successful, and also the case where layered verification of several UDP packets fails, but by re-acquiring the data, an updated and reassembled set of several UDP packets is obtained and the layered verification is successful.

[0116] After the operations and maintenance personnel click and confirm the one-click batch installation, the service program of the terminal cluster receives the installation instruction and begins to execute the automated script. Based on the target path, it performs the installation process of several UDP packets. Specifically: if the target path is in the user directory, it decompresses or copies several UDP packets without requiring a password, directly installing the relevant files to the user directory; this operation does not require a system password. If the target path is in the system directory, it performs privileged operations on several UDP packets according to a preset method, installing the relevant files to the system directory; this operation requires a system password. Furthermore, privileged operations refer to the automated script temporarily executing copy commands with root privileges through pre-configured passwordless sudo rules (i.e., sudo matching rules).

[0117] The default method refers to executing the installation command with root privileges when the command path and parameters of several UDP packets match the regular expression in the passwordless policy file. The regular expression consists of three parts: command path regular expression, parameter pattern regular expression, and target path regular expression. The passwordless policy file is generated by a regular expression engine based on the command path and target path declared in the file list of the installation package. The generation process of the passwordless policy file is described in detail in step S1.

[0118] For examples of this application, please refer to [link / reference]. Figure 7 , Figure 7This is a schematic diagram of the one-click installation process provided in this application embodiment, showing the process of the host sending the installation package to the terminal cluster (terminal) and performing the installation in this embodiment one.

[0119] The implementation scheme of this Example 1 is applicable to all Linux systems (such as Ubuntu 18.04 and above, CentOS 7 and above), and can cover common system requirements of enterprise-level environments.

[0120] This embodiment, S3.2, describes the execution process of the installation script. Since the user directory belongs to the user and typically does not contain sensitive system files, the risk of passwordless installation is low. However, the system directory contains sensitive system files and configurations, so performing installation operations in these directories requires privileges, and security is ensured through strict access control. Therefore, when performing installation in the user directory, no password is required, improving the automation and efficiency of the installation process. When performing privileged operations in the system directory, since the specific commands targeted by the sudo file (i.e., commands involving decompression or copying files to the system directory during the installation process) have been pre-configured for passwordless execution, no password is required to obtain root privileges during the automated script execution process. Through the pre-configured passwordless sudo rules, the automated script can temporarily execute commands with root privileges without waiting for the user to enter a password, thereby accelerating the installation process.

[0121] Overall, this embodiment has the following beneficial effects:

[0122] This application controls the host to transmit UDP packets to the terminal cluster via broadcast, allowing multiple terminals to simultaneously receive and process packets. This batch processing method reduces the waiting time of individual terminals and improves overall deployment efficiency. The terminal cluster performs layered verification on the received UDP packets to ensure data integrity and correctness. Since user directories typically do not contain sensitive files, passwordless installation is possible; however, system directories contain sensitive files and require privileged operations and strict access control. Therefore, when performing installation in the user directory, no password is required, and installation proceeds directly, improving the automation and efficiency of the installation process. Regarding the system directory installation method, traditional deployment methods require the user to enter the root password for verification every time an operation requiring root privileges is performed. In this application, an automated script is used to install the entire package, and the sudo command grants root privileges to ordinary users. Thus, during the installation process, the automated script can obtain system directory file permissions without requiring a password, significantly reducing the number of permission verifications, thereby reducing redundant operations and saving operational time and costs.

[0123] Example 2:

[0124] Please see Figure 8 The embodiments of this application provide a passwordless deployment device under a Linux environment, which is suitable for terminal clusters, including a data module 10, a verification module 20 and an installation module 30;

[0125] The data module 10 is used to acquire several UDP data packets; these UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in a broadcast manner.

[0126] Verification module 20 is used to perform layered verification on several UDP packets;

[0127] The installation module 30 is used to reacquire several UDP packets if the verification fails or the data of several UDP packets is incomplete; if the verification succeeds and the data of several UDP packets is complete, the several UDP packets are installed without a password to the user directory or installed to the system directory according to a preset method. The preset method means that when the command path and parameters of several UDP packets match the regular expression in the passwordless policy file, the installation command is executed with root privileges. The passwordless policy file is generated by a regular expression engine based on the command path and target path declared in the file list in the installation package.

[0128] In one embodiment, the data module 10 includes a creation unit and a sending unit, wherein the creation unit is the process of creating a passwordless policy file and determining the terminal cluster, and the sending unit is the process of the host sending data to the terminal cluster.

[0129] The creation unit is used by operations and maintenance personnel to pre-select an installation package stored locally and containing a file manifest on the local computer's host (i.e., the local host) using a one-click upgrade tool; the installation package includes software packages and files required for software deployment;

[0130] The creation unit is also used to extract specific command paths and target path patterns for system directory operations from the file manifest of the installation package;

[0131] The creation unit is also used to generate a command whitelist based on the command path and target path pattern using a regular expression engine;

[0132] The creation unit is also used to convert the command whitelist into sudo matching rules, and to break down the sudo matching rules into independent atomic policy files, resulting in passwordless policy files. "sudo" is the core permission management tool of the Linux system, and the rules defined in its configuration file ( / etc / sudoers) are used to control the permissions of users or programs to execute privileged commands.

[0133] The creation unit is also used to send UDP multicast packets from the host to a specified port of a preset multicast address, thereby determining the terminal cluster. For example, UDP multicast (224.0.0.1:9999) can be used to quickly discover device clusters; where "224.0.0.1" is the preset multicast address and "9999" is the specified port; and UDP multicast is also used to issue commands.

[0134] The process of creating the passwordless policy file is as follows:

[0135] ① Dynamic permission configuration technology based on installation package feature analysis: By deeply analyzing the file manifest within the installation package, it automatically identifies specific command paths that require operating system directories (e.g., / usr / bin / cp, / bin / mv) and the patterns of target paths (e.g., / usr / lib / *.so, / etc / conf.d / [az].conf). This step provides a precise basis for subsequent permission configuration.

[0136] ② Implementation of the principle of least privilege: To adhere to the principle of least privilege, a regular expression engine is used to dynamically generate a whitelist of commands that match precisely, and then converts this whitelist into sudo matching rules. For example, rules such as " / usr / bin / cp / tmp / [A-Za-z0-9]*.so / usr / lib / " can be generated, thus avoiding the use of global passwordless execution strategies (such as NOPASSWD:ALL) in traditional methods. This approach ensures that only the necessary combination of commands and paths can obtain passwordless execution privileges.

[0137] ③ Atomic Policy Deployment: To enhance policy manageability and security, sudo matching rules are split into independent files (e.g., / etc / sudoers.d / deploy_rule), which are the passwordless policy files. Simultaneously, the `chmod 0440` command ensures these policy files have read-only attributes, preventing unauthorized modification or leakage. Here, "chmod 0440" is a file permission setting command in Linux / Unix systems, which sets permissions for files or directories using octal mode.

[0138] In this embodiment, the creation unit utilizes a regular expression engine to generate a command whitelist, which can accurately match the system directory operation commands required to be executed in the installation package, enhancing the accuracy and specificity of the policy file. The command whitelist is converted into sudo matching rules and split into independent atomic policy files, achieving fine-grained control over specific operations, reducing the risk of unauthorized operations, and enhancing system security.

[0139] Furthermore, the risk of unauthorized operations is reduced through policy file permission control (chmod 0440).

[0140] The sending unit is used to divide the installation package into several UDP packets in the host according to the data fragmentation strategy;

[0141] The sending unit is also used to transmit several UDP data packets of the installation package to the service program of the terminal cluster in the form of broadcast after the operation and maintenance personnel click to confirm, and to distribute the passwordless policy file to all terminal devices in the terminal cluster.

[0142] The sending unit is also used to control the terminal cluster to obtain several UDP packets and passwordless policy files.

[0143] The data fragmentation strategy is as follows: frames are divided according to MTU = 1500 bytes, and a CRC32 check value (i.e., the first check value) is appended to the end of the preset data of each frame.

[0144] Furthermore, the one-click upgrade tool can achieve multi-threaded communication (based on the epoll model) and supports breakpoint resumption (recording the Last_ACK sequence number). That is, it can utilize Linux's epoll I / O multiplexing mechanism to efficiently manage a large number of concurrent connections, thereby handling data transmission requests from thousands of terminals simultaneously within a single thread, reducing resource consumption and improving broadcast efficiency. It can also customize reliable transmission on the UDP protocol (User Datagram Protocol) by recording the last acknowledged ACK sequence number (Last_ACK) to mark the transmission progress. This allows transmission to resume from the "Last_ACK+1" sequence number after a network interruption, avoiding the retransmission of received data packets.

[0145] In addition, the terminal cluster's service programs include a security sandbox module (Seccomp policy) and can monitor the integrity of the " / etc / sudoers.d / " file in real time (inotify mechanism). This means that the service programs are restricted from making system calls (syscalls) through the Linux kernel's Seccomp (Secure Computing) mechanism, thereby preventing malicious code or accidental execution of dangerous instructions (such as execve, mount) and enhancing the security of the service programs. The inotify API is used to monitor file change events (such as creation, modification, and deletion) in the " / etc / sudoers.d / " directory. When the passwordless policy file (such as deploy_rule) is detected to have been tampered with, an alarm or recovery operation is immediately triggered to ensure the legitimacy of the permission configuration.

[0146] The transmission of several UDP packets uses a persistent transmission strategy, which is designed as follows:

[0147] ① Protocol Header Design: Each UDP packet header contains the following fields: SEQ / ACK sequence number (32 bits): identifies the packet order and reception acknowledgment status. FLAG flag (SYN / ACK / FIN): used to control the start, response, and termination of the transmission session. Frame offset: marks the storage location of data in the file, resolving UDP packet reordering issues. Valid data frame: carries the actual transmitted fragmented content of the installation packet. CHECKSUM checksum (16 bits): verifies the integrity of a single frame of data.

[0148] ② Resume interrupted transmission support: The control terminal cluster persistently records the last successfully received ACK sequence number (Last_ACK). When the transmission is interrupted and resumed, the host resumes the transmission from the sequence number "Last_ACK+1" to avoid retransmitting the received data.

[0149] For examples of this application, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of the system framework provided in the embodiments of this application, which shows the system framework for network communication between a local host and a terminal cluster.

[0150] In one embodiment, the verification module 20 includes a first verification unit and a second verification unit, wherein the first verification unit is a process of performing CRC32 verification on a number of UDP packets, and the second verification unit is a process of performing MD5 verification on a number of UDP packets.

[0151] The first verification unit is used to obtain an additional first verification value from the end of a preset data of several UDP packets in the terminal cluster.

[0152] The first verification unit is also used to calculate the CRC32 check value of each UDP packet in several UDP packets;

[0153] The first verification unit is also used to verify that if the CRC32 check value of each UDP packet matches the corresponding check value in the first verification value, the verification is successful and the UDP packets are considered valid; if the CRC32 check value of each UDP packet does not match the corresponding check value in the first verification value, the verification fails and the UDP packets are considered to have been transmitted incorrectly.

[0154] In the first verification unit of this embodiment, since each data packet is checked independently using CRC32, even if an error occurs in a data packet during transmission, it will not affect the correctness of other data packets. This reduces the risk of error accumulation and makes the transmission of the entire data packet sequence more stable and reliable.

[0155] The second verification unit is used to obtain the first hash value of several UDP packets from the host after the file transfer is completed;

[0156] The second verification unit is also used to calculate the overall MD5 hash value of several UDP packets;

[0157] The second verification unit is also used to verify that if the MD5 hash value matches the first hash value, the verification is successful and the UDP packets are considered valid; if they do not match, the verification fails and the UDP packets are considered to have been transmitted incorrectly.

[0158] The second verification unit is also used to summarize the above-mentioned methods of CRC32 verification and MD5 verification as layered verification.

[0159] In the second verification unit of this embodiment, since the MD5 algorithm has good hash distribution characteristics, even if there are only small changes in the data packet, the generated hash value will change significantly. Therefore, by calculating the overall MD5 hash value of the UDP data packet and comparing it with the first hash value obtained from the host, it is possible to accurately determine whether the data packet remains intact during transmission.

[0160] In summary, the CRC32 checksum of the verification module 20 in this embodiment can efficiently detect errors at the data bit level, thereby ensuring the integrity of the data packet. The MD5 checksum can generate a fixed-length hash value, which is highly sensitive to any minor changes in the data packet content; therefore, the MD5 checksum can further reduce the risk of data being incorrectly modified or tampered with.

[0161] In one embodiment, the installation module 30 includes a retransmission unit and an installation unit, wherein the retransmission unit is the process of retransmitting when the verification fails or when the data of several UDP packets is incomplete, and the installation unit is the process of installing several UDP packets.

[0162] The retransmission unit is used in the terminal cluster to, if the layered verification fails, the terminal considers the frame data invalid, and initiates a retransmission request to the host according to the frame sequence number corresponding to the frame data that failed the verification, so as to obtain the first target lost frame.

[0163] The retransmission unit is also used to write the first target lost frame into the corresponding position of several UDP packets to obtain several updated and reassembled UDP packets.

[0164] The retransmission unit is also used to create corresponding status management bytes based on the number of slices of several UDP packets to record the reception status of each frame.

[0165] The retransmission unit is also used to define frames in the expected target frame set that are not received as lost frames when the expected target frame set of several UDP packets has been received, if the data of the expected target frame set is incomplete, and set the corresponding position of the lost frame in the status management byte to zero.

[0166] The retransmission unit is also used to initiate a retransmission request to the host according to the sequence number of the lost frame, and reacquire the lost frame to obtain the second target lost frame; wherein, the sequence number of the lost frame is determined according to the zeroed bit in the status management byte, and the "bit" contains both position and status information.

[0167] The retransmission unit is also used to write the second target lost frame into the corresponding position of several UDP packets if all target lost frames in the expected target frame set are successfully received and pass the layered verification, so as to obtain several updated and reassembled UDP packets.

[0168] For examples of this application, please refer to [link / reference]. Figure 3-6 , Figure 3 This is a schematic diagram of the installation package being uploaded to the terminal according to an embodiment of this application, showing the process of the local host uploading the installation package to terminal 4 in the terminal cluster.

[0169] Figure 4 This is a diagram illustrating the terminal frame reception flag bits provided in an embodiment of this application. Figure 5 This is a schematic diagram of the frame protocol provided in an embodiment of this application. Figure 6 This is a schematic diagram of file frame splicing provided in an embodiment of this application;

[0170] When handling UDP packet loss, if a terminal fails to receive a data frame for some reason, it can identify the lost frame through a specific calculation process and send a retransmission request to the host accordingly. The following combines... Figure 4-6 The calculation process (i.e., the process described above where the corresponding data is reacquired if the data of the expected target frame set is incomplete) is summarized as follows:

[0171] Figure 4This section details how the terminal cluster determines the number of frames a file is divided into based on the "frames" field in the frame protocol. To this end, the control terminal cluster allocates a memory space (consisting of several bytes), where each byte can mark the reception status of 8 frames. For example, if the file is divided into 128 frames, the receiving end needs to allocate 16 bytes to track the reception status of each frame. Whenever a frame is successfully received and verified, the receiving end sets the corresponding bit to 1; if reception fails or times out, the corresponding bit remains 0. After all frame reception attempts have been completed, the control terminal cluster checks these flag bits, identifies bits with a value of 0, determines the sequence number of the lost frame, and initiates a retransmission request to the host. It is important to note that for each frame, the receiving end will attempt to retransmit a maximum of 3 times; if all 3 attempts fail, the receiving end will abandon retransmission of that frame.

[0172] Figure 5 This reveals the specific structure of the frame protocol. The "frame" field indicates the total number of frames in the file, the "cur_frame" field represents the sequence number of the current frame, the "offset" field indicates the location in the file where the current frame data should be stored, and the "data" field contains the valid data content. Furthermore, the "checksum" field is used to validate the "data" field to ensure data accuracy.

[0173] Figure 6 The text emphasizes the potential packet order disorder issue encountered when using the UDP protocol. To address this, the control terminal cluster uses the "offset" field to accurately write received valid data to a specified location in the file. This mechanism ensures that even with network packet order disorder, the data frames written to the file maintain the correct order.

[0174] With this design, the terminal cluster can effectively cope with packet loss in UDP transmission, ensuring data integrity and accuracy.

[0175] In the retransmission unit of this embodiment, once a verification failure is detected, a retransmission request is initiated based on the frame sequence number. This allows for the rapid location and repair of lost or corrupted data frames, thereby improving the reliability of data transmission. By retransmitting only lost or corrupted frame data, rather than the entire file or data packet, network bandwidth waste can be reduced.

[0176] Furthermore, by creating state management bytes to record the reception status of each frame, the reception status of each UDP packet can be clearly tracked, providing an efficient data foundation for subsequent lost frame detection and retransmission requests. After the expected target frame set has been received, by comparing the state management bytes, it is possible to accurately identify which frames were lost, avoiding unnecessary retransmission requests and improving data transmission efficiency.

[0177] The installation unit is used to obtain the target path from the file list of several UDP packets if the layer verification is successful and the data of several UDP packets is complete; wherein, successful layer verification includes the case where layer verification of several UDP packets is successful, and also the case where layer verification of several UDP packets fails, but by re-acquiring the data, updated and reassembled several UDP packets are obtained and layer verification is successful.

[0178] The installation unit is also used by operations and maintenance personnel to click and confirm one-click batch installation. After receiving the installation instruction, the service program of the terminal cluster starts to execute the automated script, which performs the installation process of several UDP packets according to the target path. Specifically: if the target path is in the user directory, several UDP packets are decompressed or copied without a password, that is, the relevant files are directly installed to the user directory. This operation does not require entering the system password. If the target path is in the system directory, privileged operations are performed on several UDP packets according to the preset method, that is, the relevant files are installed to the system directory. This operation requires the system password. Furthermore, privileged operations refer to the automated script temporarily executing the copy command with root privileges through the pre-configured passwordless sudo rules (i.e., sudo matching rules).

[0179] The default method refers to executing the installation command with root privileges when the command path and parameters of several UDP packets match the regular expression in the passwordless policy file. The regular expression consists of three parts: command path regular expression, parameter pattern regular expression, and target path regular expression. The passwordless policy file is generated by a regular expression engine based on the command path and target path declared in the file list of the installation package. The generation process of the passwordless policy file is described in detail in data module 10.

[0180] For examples of this application, please refer to [link / reference]. Figure 7 , Figure 7 This is a schematic diagram of the one-click installation process provided in this application embodiment, showing the process of the host sending the installation package to the terminal cluster (terminal) and performing the installation in this embodiment 2.

[0181] The implementation scheme of this second embodiment is applicable to all Linux systems (such as Ubuntu 18.04 and above, CentOS 7 and above), and can cover common system requirements of enterprise-level environments.

[0182] This embodiment describes the execution process of the installation script. Since the user directory is personal and typically does not contain sensitive system files, the risk of passwordless installation is low. However, the system directory contains sensitive system files and configurations, so performing installation operations in these directories requires privileges, and security is ensured through strict access control. Therefore, when performing installation in the user directory, no password is required, improving the automation and efficiency of the installation process. When performing privileged operations in the system directory, since the sudo file has been pre-configured for passwordless execution of specific commands (i.e., commands involving decompression or copying files to the system directory during the installation process), no password is required to obtain root privileges during the automated script execution. Through the pre-configured passwordless sudo rules, the automated script can temporarily execute commands with root privileges without waiting for the user to enter a password, thereby accelerating the installation process.

[0183] Overall, this embodiment has the following beneficial effects:

[0184] This application controls the host to transmit UDP packets to the terminal cluster via broadcast, allowing multiple terminals to simultaneously receive and process packets. This batch processing method reduces the waiting time of individual terminals and improves overall deployment efficiency. The terminal cluster performs layered verification on the received UDP packets to ensure data integrity and correctness. Since user directories typically do not contain sensitive files, passwordless installation is possible; however, system directories contain sensitive files and require privileged operations and strict access control. Therefore, when performing installation in the user directory, no password is required, and installation proceeds directly, improving the automation and efficiency of the installation process. Regarding the system directory installation method, traditional deployment methods require the user to enter the root password for verification every time an operation requiring root privileges is performed. In this application, an automated script is used to install the entire package, and the sudo command grants root privileges to ordinary users. Thus, during the installation process, the automated script can obtain system directory file permissions without requiring a password, significantly reducing the number of permission verifications, thereby reducing redundant operations and saving operational time and costs.

[0185] Example 3:

[0186] This application provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute a passwordless deployment method under a Linux environment.

[0187] The passwordless deployment method in a Linux environment, if implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0188] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A passwordless deployment method in a Linux environment, characterized in that, Applicable to terminal clusters, including: Acquire several UDP data packets; wherein, the several UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in a broadcast manner; Perform layered verification on the aforementioned UDP packets; If the verification fails or the data of the UDP packets is incomplete, the UDP packets are reacquired. If the verification succeeds and the data of the UDP packets is complete, the UDP packets are installed to the system directory according to a preset method. Specifically, installing the UDP packets to the system directory according to the preset method involves: obtaining the target path from the file list of the UDP packets; executing the installation process of the UDP packets according to the target path; the preset method is that when the command path and parameters of the UDP packets match the regular expression in the passwordless policy file, the installation command is executed with root privileges. If the target path is in the system directory... Then, privileged operations are performed on the aforementioned UDP packets according to the preset method; the privileged operation refers to the automated script executing copy commands with root privileges through pre-configured passwordless sudo rules; the passwordless policy file is generated by a regular expression engine based on the command paths and target paths declared in the file list of the installation package, specifically: extracting the command path and target path patterns for system directory operations from the file list of the installation package; generating a command whitelist based on the command path and target path patterns using a regular expression engine; converting the command whitelist into sudo matching rules, and splitting the sudo matching rules into independent atomic policy files to obtain the passwordless policy file; If the verification fails or the data in the UDP packets is incomplete, the UDP packets will be retrieved again, specifically as follows: If the layered verification fails, a retransmission request is initiated to the host based on the frame sequence number corresponding to the frame data that failed the verification, to obtain the first target lost frame; the first target lost frame is written into the corresponding position of the plurality of UDP data packets to obtain the updated and reassembled plurality of UDP data packets; if the data of the plurality of UDP data packets is incomplete, a second target lost frame is obtained based on the frame sequence number of the lost frame; the second target lost frame is written into the corresponding position of the plurality of UDP data packets to obtain the updated and reassembled plurality of UDP data packets.

2. The passwordless deployment method in a Linux environment as described in claim 1, characterized in that, The aforementioned UDP packets are subjected to layered verification, specifically as follows: The plurality of UDP packets are subjected to CRC32 verification based on the check value attached by the host; The MD5 checksum of the UDP packets is performed based on the hash value provided by the host.

3. The passwordless deployment method in a Linux environment as described in claim 2, characterized in that, The plurality of UDP packets are subjected to CRC32 verification based on the checksum attached by the host, specifically as follows: Obtain an additional first checksum from the end of the preset data of the plurality of UDP packets; Calculate the CRC32 checksum value of each UDP packet in the plurality of UDP packets; If the CRC32 checksum of each UDP packet matches the corresponding checksum in the first checksum, the UDP packets are considered valid; if the CRC32 checksum of each UDP packet does not match the corresponding checksum in the first checksum, the UDP packets are considered to have been transmitted incorrectly.

4. The passwordless deployment method in a Linux environment as described in claim 2, characterized in that, The MD5 checksum of the plurality of UDP packets is performed based on the hash value provided by the host, specifically as follows: After the file transfer is completed, the first hash value of the plurality of UDP packets is obtained from the host; Calculate the overall MD5 hash value of the aforementioned UDP packets; If the MD5 hash value matches the first hash value, the UDP packets are considered valid; otherwise, the UDP packets are considered to have been transmitted incorrectly.

5. The passwordless deployment method in a Linux environment as described in claim 1, characterized in that, If the data in the aforementioned UDP packets is incomplete, then the second target lost frame is obtained based on the frame sequence number of the lost frame, specifically as follows: A corresponding state management byte is created based on the number of slices of the aforementioned UDP packets to record the reception status of each frame; When the expected target frame set of the plurality of UDP packets has been received, if the data of the expected target frame set is incomplete, the frames in the expected target frame set whose reception status is not received are defined as lost frames, and the corresponding position of the lost frames in the status management byte is set to zero. A retransmission request is initiated to the host based on the sequence number of the lost frame, and the lost frame is reacquired to obtain the second target lost frame; wherein, the sequence number of the lost frame is determined based on the zero bit in the status management byte.

6. A passwordless deployment device under a Linux environment, characterized in that, Suitable for terminal clusters, including data module, verification module and installation module; The data module is used to acquire several UDP data packets; wherein the several UDP data packets are obtained by the host dividing the installation package into several UDP data packets and transmitting them to the service program of the terminal cluster in a broadcast manner; The verification module is used to perform layered verification on the plurality of UDP packets; The installation module is used to reacquire the UDP packets if the verification fails or the data of the UDP packets is incomplete; if the verification succeeds and the data of the UDP packets is complete, the UDP packets are installed to the system directory according to a preset method. Specifically, installing the UDP packets to the system directory according to the preset method involves: obtaining the target path from the file list of the UDP packets; executing the installation process of the UDP packets according to the target path; the preset method is to execute the installation command with root privileges when the command path and parameters of the UDP packets match the regular expression in the passwordless policy file; if the target path is in the system directory... If the system directory is accessed, privileged operations are performed on the aforementioned UDP packets according to the preset method. These privileged operations refer to the automated script executing copy commands with root privileges using pre-configured passwordless sudo rules. The passwordless policy file is generated using a regular expression engine based on the command paths and target paths declared in the file list of the installation package. Specifically, this involves: extracting the command path and target path patterns for system directory operations from the file list of the installation package; generating a command whitelist based on the command path and target path patterns using a regular expression engine; converting the command whitelist into sudo matching rules; and splitting the sudo matching rules into independent atomic policy files to obtain the passwordless policy file. If the verification fails or the data in the UDP packets is incomplete, the UDP packets will be retrieved again, specifically as follows: If the layered verification fails, a retransmission request is initiated to the host based on the frame sequence number corresponding to the frame data that failed the verification, to obtain the first target lost frame; the first target lost frame is written into the corresponding position of the plurality of UDP data packets to obtain the updated and reassembled plurality of UDP data packets; if the data of the plurality of UDP data packets is incomplete, a second target lost frame is obtained based on the frame sequence number of the lost frame; the second target lost frame is written into the corresponding position of the plurality of UDP data packets to obtain the updated and reassembled plurality of UDP data packets.

7. A storage medium, characterized in that, The storage medium stores a computer program, which is called and executed by a computer to implement a passwordless deployment method in a Linux environment as described in any one of claims 1 to 5.

Images