CN117827266A - Method and system for inquiring version and path of rpm packet in yum source - Google Patents

Abstract

The invention discloses a method and a system for inquiring version and path of rpm package in Yum source, which relates to the field of operating system in IT and software development, the method comprises the steps of determining root directory of Yum source, obtaining the same directory as the Yum source path in local source, writing the inquiring result into file A, cutting out the Yum source path and storing the Yum source path into file B; acquiring information of all package names based on the file A, and storing the information into the file C as key information during inquiry; acquiring complete version information of all packages based on the file A, and storing the complete version information into the file D, wherein the version information consists of epoch, version-release; splicing and formatting JSON files in a 'package name-version-path' form according to stored information; and periodically detecting and updating the JSON file and synchronizing to the corresponding service directory. The package management system based on the Yum source has the characteristics of data accuracy, real-time updating and user friendliness, and can improve the basic service capacity of the Yum source and a Linux distribution provider for a user by utilizing own data and advantages.

Description

Method and system for inquiring version and path of rpm packet in yum source

Technical Field

The present application relates to the field of operating systems in IT and software development, and more particularly, to a method and system for querying rpm package version and path in yum source.

Background

The Yum source is the source of RPM software installation packages in Linux systems, and one type of Linux release typically corresponds to Yum sources to continuously provide the service capabilities of the Linux release. The Yum source is provided to the user through the web form, the provider of the Yum source needs to create a local source at the local server and then synchronize the local update to the Yum source, so that the Yum source and the local source data are consistent. Use of Yum source, after configuring available repo file under Linux release/etc/yum.repos.d/directory, the system parses the repodata file in the specified Yum source path (the file records the path, version, dependency and other information of all RPM packages under the directory where repodata is located), and the user can use Yum command to perform on-line query, installation and uninstallation management on RPM packages.

Currently, in the official Yum source corresponding to the mainstream Linux release, there are usually several to tens of software directories with different numbers according to the category of the software package, and different repodata are placed under different directories according to the architecture. This approach of configuration facilitates Yum management to prevent confusion, but has a disadvantage that when it is required to query whether the Linux distribution being used supports certain RPM software, and the two most critical information of the repodata path and version where the software is located, then the Yum source path where the software is located needs to be known for query, and if the configured repo does not contain the package information, the package information is not obtained by direct query.

Therefore, how to obtain the Yum source path of the software conveniently and efficiently is a technical problem to be solved at present.

Disclosure of Invention

The invention provides a method and a system for inquiring an rpm packet version and a path in a Yum source, which are used for solving the problem that the path of a Yum source where software is located is difficult to acquire conveniently and efficiently.

In one aspect, the present invention provides a method for querying version and path of rpm packet in yum source, comprising:

step 1, determining a root directory of a Yum source, acquiring a directory which is the same as a Yum source path in a local source, writing a query result into a file A, cutting out the Yum source path and storing the Yum source path into a file B;

step 2, acquiring information of all package names based on the file A, and storing the information into the file C as key information during inquiry;

step 3, obtaining complete version information of all packages based on the file A, and storing the complete version information into the file D, wherein the version information consists of epoch, version-release;

step 4, splicing and formatting the JSON file in a package name-version-path form according to the stored information;

step 5, periodically detecting and updating the JSON file, and synchronizing to the corresponding service directory;

and 6, providing a Web interface for a user to display, and acquiring JSON file data by the user only by inputting and submitting the package name.

Preferably, the query manner and the storage flow in the step 1 are as follows:

and inquiring the complete paths of all rpm package files under the same directory in the local source through a find command in the linux, redirecting and storing the complete paths into the file A, and comparing the actual root path of the Yum source, cutting out the paths corresponding to the paths identical to those of the Yum source by using awk, and redirecting and storing the paths into the file B.

Preferably, the specific method for acquiring the packet name information in the step 2 is as follows:

and using the cat file A, then using a pipeline symbol 'I' and using xargs to transfer parameter fragments to an rpm-q command, inquiring packet names by appointing with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and redirecting all inquired information to store the information into a new storage file C.

Preferably, the method for obtaining the complete version information of each packet in the step 3 includes:

and transmitting information in the file A to an rpm query command through a cat file A by utilizing a pipeline character and a xargs command, printing version information in an epoch: version-release format by utilizing a queryFormat parameter, intercepting the version information which is empty by the epoch by utilizing a sed command, and finally redirecting the version information to be stored in a storage file D.

Preferably, the manner of splicing and obtaining the final json file in the step 4 is as follows:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

Preferably, the method for updating the json file at regular time in the step 5 is as follows:

integrating a process tool for generating a json file F into a timing task crontab of a local source server, judging whether all processes of the step 1-the step 5 are needed or not by calculating an MD5 value of a file A before executing the process for generating the json, and indicating that the Yum source data is unchanged and the json file is not needed to be updated when the MD5 value of a new file A is the same as an old MD5 value; after updating and generating a new json file, the json file is updated to the html file and the catalog in the step 2 at regular time by using a cp/scp command, so that the updating of the json file can be completed and the data timeliness of the query tool can be maintained.

Preferably, the usage mode shown to the user in the step 6 is as follows:

generating a simple static search box comprising a search input field and a clickable search key through html, associating the simple static search box to a custom function G in javascript through onclick events to realize interaction, triggering the javascript to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, inquiring json files by the package name and the current page number and only returning the content of the current page and the total count to the function G by the rear-end nodejs, transmitting json and the total count to a function H by the function G, displaying the data of the current page to the front end according to the total count and json paging, judging whether the page number clicking event occurs, and calling the function G to inquire the page number data if the page number clicking event occurs.

In another aspect, the invention provides a system for querying version and path of rpm packets in yum source, comprising:

the information processing module is used for determining a root directory of the Yum source, acquiring the directory which is the same as the Yum source path in the local source, writing the query result into the file A, cutting out the Yum source path and storing the Yum source path into the file B; the information processing module is also used for acquiring information of all package names based on the file A and storing the information into the file C as key information during inquiry; the information processing module is also used for acquiring complete version information of all packages based on the file A and storing the complete version information into the file D, wherein the version information consists of epoch, version-release; splicing and formatting JSON files in a 'package name-version-path' form according to stored information;

the automatic detection module is used for periodically detecting and updating the JSON file and synchronizing the JSON file to the corresponding service directory;

and the interaction module is used for providing a Web interface for a user to display, and the user can acquire the JSON file data only by inputting the package name and submitting the package name.

Preferably, the query mode and the storage flow of the information processing module are as follows:

inquiring the complete paths of all rpm package files under the same directory in a local source through a find command in linux, redirecting and storing the complete paths into a file A, and comparing the actual root path of a Yum source, cutting out paths corresponding to the paths identical to those of a Yum source by using awk, and redirecting and storing the paths into a file B;

the specific method for acquiring the packet name information of each information processing module comprises the following steps:

the cat file A is used, then the pipeline symbol I is used for transmitting parameter fragments to an rpm-q command by using the xargs, and inquiring packet names are agreed with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and all the inquired information is redirected and stored in a new storage file C;

the method for obtaining the complete version information of each packet by the information processing module comprises the following steps:

transmitting information in the file A to an rpm query command by using a pipe character and a xargs command through the cat file A, printing version information of the version-release format by using a queryFormat parameter, intercepting the version information which is empty by the epoch by using a sed command, and finally redirecting the version information to be stored in a storage file D;

the information processing module is used for splicing and obtaining a final json file in the following manner:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

Preferably, the method for updating the json file at regular time by the automatic detection module comprises the following steps:

integrating a process tool for generating a json file F into a timing task crontab of a local source server, judging whether all processes in the information processing module are needed or not by calculating an MD5 value of a file A before executing the process for generating the json, and indicating that the Yum source data are unchanged and the json file is not needed to be updated when the MD5 value of a new file A is the same as an old MD5 value; after updating and generating a new json file, periodically updating the json file to the html file and the catalog of the information processing module by using a cp/scp command, so that the json file can be updated and the data timeliness of the query tool can be maintained;

the use mode of the automatic detection module displayed to the user is as follows:

generating a simple static search box comprising a search input field and a clickable search key through html, associating to a custom function G in javascript through onclick event to realize interaction, triggering the javascript to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, inquiring json file by the package name and the current page number, returning only the content of the current page and the total count to the function G, transmitting json and the total count to a function H by G, displaying the data of the current page to the front end according to the total count and json paging, judging whether the page number clicking event occurs, and calling the function G to inquire the data if the page number clicking event occurs.

By applying the technical scheme, the method and the system for inquiring the version and the path of the rpm packet in the yum source have the following technical effects:

1. simplifying the workflow of the user and provider. From the authority of the Yum source, key-value corresponding relations are extracted by processing and arranging information of all RPM packages in a local source, and the relation information is stored as json objects, and meanwhile timeliness of queried data is ensured through timing updating, only one-time deployment is needed, and manual maintenance is not needed. Through html+nodejs, the entry of the RPM package query is provided for a Linux issuing user in a webpage form, and the user can input the RPM package name in a search box to query and acquire a result only by opening a query webpage.

2. And the basic service capability of the Linux distribution plate is improved. The local synchronous data of the Yum source are further arranged and processed and then provided for a user, so that the management configuration of the Linux software warehouse is optimized, more optimized service is provided, and the basic service capability of the Yum source software warehouse and the Linux distribution plate is further improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method for querying version and path of rpm packet in yum source according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of RPM packet information processing flow in a method for querying an RPM packet version and path in a yum source according to an embodiment of the invention;

FIG. 3 is a schematic diagram showing a process of detecting and updating json to deployment directory in a method for querying version and path of rpm packet in yum source according to an embodiment of the present invention;

FIG. 4 is a functional schematic diagram illustrating query interaction implemented by html+nodejs in a method for rpm packet version and path in a query yum source according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a method and system for querying version and path of rpm packet in yum source according to an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

In order to deal with such demands, one current feasibility solution is to configure the repodata path under each directory in the repo file, but this method needs to determine the location of each repodata in the Yum source and then configure the location in the repo file one by one, and then can use Yum related commands to query the path and version information of the RPM software required. In the working process, a user often encounters such a query requirement, and the use of such a method increases the complexity of the overall workflow and is limited to the service capability of the Linux release, so that from the perspective of a Yum manager, a method is designed by using local data to sort key information such as package names, paths and versions of all RPM software packages in a Yum source, and a quick and convenient way is provided for the user to query after packaging.

In view of the above needs, referring to fig. 1-3, an embodiment of the present application provides a method for querying an rpm packet version and path in a yum source, including:

step 1, determining a root directory of a Yum source, acquiring a directory which is the same as a Yum source path in a local source, writing the queried information into a file A for storage, cutting out a Yum source path and storing the file B;

step 2, acquiring information of all package names based on the storage file A, wherein the information is used as a key at the time of inquiry and is stored in the storage file C;

step 3, obtaining complete version information of all the packets based on the storage file A, wherein the version information is key information of the packets and mainly consists of epoch: version-release, and the epoch part is ignored in consideration of the partial complete packet name, so that the version information is required to be re-extracted and stored in the file D;

step 4, based on the information stored in the file, the json format file in the form of package name-version-path is obtained through splicing and formatting;

step 5, in order to ensure the accuracy of data query, the json file is periodically detected and updated and synchronized to the corresponding service directory;

and 6, providing a web interface for a front-end user to display, so that the user can acquire json file data only by inputting the package name and submitting the package name.

Specifically, the RPM packet information processing section needs to sort out packet name, path and version correspondence information of the RPM packet under the source directory: and (3) arranging, cutting, filtering and combining the local source information of the server which is completely the same as the Yum source data according to the same local source information to form a json data file.

It can be understood that by determining the root directory of the Yum source and writing the directory information in the local source, which is the same as the Yum source path, into the file a for storage, the basic directory structure of the Yum source can be conveniently obtained and used in subsequent updating and querying. By analyzing the information in the file A, the names of all the packages can be obtained and stored into the file C as keywords during inquiry, so that the user can conveniently inquire and operate according to the package names. According to the information in the file A, the complete version information of all the packets can be extracted, including epoch, version and release, and the version information needs to be re-extracted and stored in the file D because the epoch part may be ignored by the partial complete packet name, so that the accuracy of the version information can be ensured. In addition, based on the information stored before, a JSON format file meeting the requirements can be generated through splicing and formatting operations, wherein the JSON format file contains information of package name-version-path, and thus a front-end user can conveniently acquire related version and path information according to the package name. In order to ensure the accuracy and timeliness of the data, JSON files can be periodically detected and updated and synchronized to the corresponding directory of the service. This ensures that the data acquired by the user is always up to date. Finally, a Web interface can be provided for a front-end user to use, so that the user can acquire corresponding JSON file data only by inputting and submitting the package name, and thus the user experience can be improved, and the user can conveniently inquire and browse the information of the package management system. In general, the Yum source-based package management system has the characteristics of data accuracy, real-time updating and user friendliness, and can provide a convenient and quick package management function for users.

Referring to fig. 2-4, in some embodiments of the present application, the query manner and the storage flow in step 1 are as follows:

and inquiring the complete paths of all rpm package files under the same directory in the local source through a find command in the linux, redirecting and storing the complete paths into the file A, and comparing the actual root path of the Yum source, cutting out the paths corresponding to the paths identical to those of the Yum source by using awk, and redirecting and storing the paths into the file B.

Specifically, in step 1: the RPM packet information first needs to be processed to determine the root directory of Yum sources in the local source, typically version number of Linux distribution. After the directory is determined, the complete path information of all rpm package files under the same directory in the local source is queried by using a command find directory-name command, and then the complete path information is stored into the file A through a redirection symbol. Meanwhile, the information after find query is transferred to awk by using the pipe symbol "|", because the rpm packet path of the local source and the yum source contrast are usually inconsistent with the left part information, the right part is completely consistent, and the completely consistent path needs to be cut out and oriented to be stored in the file B by using the awk command.

Referring to fig. 2 to 4, in some embodiments of the present application, a specific method for obtaining the packet name information in step 2 is as follows:

and using the cat file A, then using a pipeline symbol 'I' and using xargs to transfer parameter fragments to an rpm-q command, inquiring packet names by appointing with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and redirecting all inquired information to store the information into a new storage file C.

Specifically, in step 2: the information in the B and the subsequent version information obtained in the step 1 are information which the user wants to inquire, and the information which needs to be submitted or input for inquiring the information is the RPM package name. Because file a is already available, it can directly use cat file a and then pass the parameter fragments to rpm-q command using the pipe symbol "|" and use xargs, and query the package name with the queryformat parameter convention, i.e. can obtain the individual package name information (obtain lrzsz) without information such as version number and architecture (e.g. complete package name lrzsz-0.12.20-36.el7.x86_64. Rpm), and then redirect all the queried information to store in the new storage file C.

Referring to fig. 2-4, in some embodiments of the present application, the method for obtaining the complete version information of each packet in step 3 is as follows:

and transmitting information in the file A to an rpm query command through a cat file A by utilizing a pipeline character and a xargs command, printing version information in an epoch: version-release format by utilizing a queryFormat parameter, intercepting the version information which is empty by the epoch by utilizing a sed command, and finally redirecting the version information to be stored in a storage file D.

Specifically, in step 3: version information is information of an RPM package most often required by a user, because the information is key identification information of the RPM package, and the rest of information can be obtained according to a drawing based on the information. The complete version information consists of epoch: version-release, and the epoch portion is ignored in consideration of the partial complete package name, so that version information re-extraction is required. Similarly, version information in version-release format is printed by transferring information in the file A to an rpm query command through a cat file A by utilizing a pipeline character and a xargs command and using a queryFormat parameter (since all rpm packets are stored in a local source, version information can be directly queried and obtained, and the advantage of integrating local source data is also achieved), the version information of which the epoch is empty is intercepted by using a sed command, and finally the version information is redirected and stored into a storage file D for subsequent combination;

referring to fig. 2-4, in some embodiments of the present application, the manner of splicing and obtaining the final json file in step 4 is:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

Specifically, in step 4: based on the obtained input information 'package name', output information 'version' and 'path', the json object file which is easy to read and retrieve is obtained through combination and optimization. Combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; then, each group of correspondences in file E is processed as json objects using the jq commands and redirected into json file F. The reconstructed json format intercepts the fragments as follows, and each json object has only three groups of key value pairs, so that the structure is simple and structured enough, and the specific json structure is as follows:

it will be appreciated that such json structures generally have several technical advantages:

compact and efficient: each JSON object contains only the necessary three sets of key-value pairs, avoiding unnecessary data redundancy. The simplicity not only improves the readability of the data, but also ensures the efficiency of network transmission, especially in the environment with limited bandwidth;

the user requirements are accurately met: the "name", "version" and "repo" key pairs in each object provide key information for one RPM package in its entirety. The user can judge whether an RPM packet exists, how its version number is, and in which warehouse it can be found by just looking at the core fields;

providing a solution to the key problem: this format provides a compact solution to the major doubt of the user, namely the presence of RPM packets, version information and the repo path. This straightforward solution helps users make decisions quickly and accurately without having to be involved in complex data processing and analysis;

easy maintenance and expansion: the structure of each object is clear, so that subsequent maintenance and updating become intuitive. If more information needs to be added in the future, the method can be easily expanded in the existing structure without destroying the whole data format;

emphasis on developer friendliness: the use of clear, abbreviated key names improves the readability and understandability of the data, helping developers to integrate the data into the application more quickly.

Referring to fig. 2-4, in some embodiments of the present application, the method for updating json file at timing in step 5 is as follows:

and (3) integrating a process tool for generating the json file F into the timing task crontab of the local source server, judging whether all processes of the steps 1-5 are needed or not by calculating the MD5 value of the file A before executing the process for generating the json, and when the MD5 value of the new file A is the same as the old MD5 value, indicating that the Yum source data is unchanged and not needed to update the json file.

It can be understood that after the new json file is updated and generated, the json file is updated to the html file and the catalog in the step 2 at regular time by using the cp/scp command, so that the updating of the json file can be completed and the data timeliness of the query tool can be maintained.

Referring to fig. 2-4, in some embodiments of the present application, the usage mode shown to the user in step 6 is:

generating a simple static search box comprising a search input field and a clickable search key through html, associating to a custom function G in javascript through onclick event to realize interaction, triggering the javascript to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, the rear-end nodejs querying json files through the package name and the current page number and only returning the content of the current page and the total count to the function G, transmitting json and the total count to a function H, displaying the data of the current page to the front end according to the total count and json paging, judging whether the page number clicking event occurs, and invoking the function G to query the page number data if the page number clicking event occurs.

It can be appreciated that this method can only display the current page data to the front end in extreme cases even if the data is matched with tens of thousands of data, prevents the front end from displaying overflow and ensures the data security.

On the other hand, referring to fig. 5, the embodiment further proposes a system for querying rpm packet version and path in yum source, including:

the information processing module is used for determining the root directory of the Yum source, acquiring the directory which is the same as the Yum source path in the local source, writing the query result into the file A, cutting out the Yum source path and storing the Yum source path into the file B; the information processing module is also used for acquiring information of all package names based on the file A and storing the information into the file C as key information during inquiry; the information processing module is also used for acquiring complete version information of all the packets based on the file A and storing the complete version information into the file D, wherein the version information consists of epoch, version-release; splicing and formatting JSON files in a 'package name-version-path' form according to stored information;

the automatic detection module is used for periodically detecting and updating the JSON file and synchronizing the JSON file to the corresponding service directory;

and the interaction module is used for providing a Web interface for a user to display, and the user can acquire the JSON file data only by inputting the package name and submitting the package name.

In some embodiments of the present application, the query manner and the storage flow of the information processing module are:

inquiring the complete paths of all rpm package files under the same directory in a local source through a find command in linux, redirecting and storing the complete paths into a file A, and comparing the actual root path of a Yum source, cutting out paths corresponding to the paths identical to those of a Yum source by using awk, and redirecting and storing the paths into a file B;

the specific method for the information processing module to acquire the name information of each packet comprises the following steps:

the cat file A is used, then the pipeline symbol I is used for transmitting parameter fragments to an rpm-q command by using the xargs, and inquiring packet names are agreed with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and all the inquired information is redirected and stored in a new storage file C;

the method for obtaining the complete version information of each packet by the information processing module comprises the following steps:

transmitting information in the file A to an rpm query command by using a pipe character and a xargs command through the cat file A, printing version information of the version-release format by using a queryFormat parameter, intercepting the version information which is empty by the epoch by using a sed command, and finally redirecting the version information to be stored in a storage file D;

the information processing module is used for splicing and obtaining the final json file in the following modes:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

In some embodiments of the present application, the method for the automatic detection module to update the json file at regular time is:

integrating a process tool for generating a json file F into a timing task crontab of a local source server, judging whether all processes in an information processing module are needed or not by calculating an MD5 value of a file A before executing the process for generating the json, and indicating that the Yum source data are unchanged and the json file is not needed to be updated if the MD5 value of a new file A is the same as an old MD5 value; after updating and generating a new json file, periodically updating the json file to the html file and the catalog of the information processing module by using a cp/scp command, so that the json file can be updated and the timeliness of the data of the query tool can be maintained;

the use mode of the automatic detection module displayed to the user is as follows:

generating a simple static search box comprising a search input field and a clickable search key through html, associating to a custom function G in javascript through onclick event to realize interaction, triggering the javascript to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, inquiring json file by the package name and the current page number, returning only the content of the current page and the total count to the function G, transmitting json and the total count to a function H by G, displaying the data of the current page to the front end according to the total count and json paging, judging whether the page number clicking event occurs, and calling the function G to inquire the data if the page number clicking event occurs.

Currently, for querying unknown RPM package information in a Yum source, one feasible mode needs to be divided into two steps, namely, the position paths of repodata files under a plurality to dozens of unequal catalogues in Yum are firstly required to be determined, then, the paths are configured in/etc/yum.repos.d/repo files in the catalogues, and then, the information required for querying is further required by using commands such as yucinfo. It can be seen that this type of approach consumes much time and is more cumbersome to process, and if the yum source directory structure changes due to official adjustments, the configuration process needs to be re-performed once again.

In summary, by applying the above technical solution, the method and system for querying the version and path of the rpm packet in the yum source of the present application have the following technical effects:

1. simplifying the workflow of the user and provider. From the authority of the Yum source, key-value corresponding relations are extracted by processing and arranging information of all RPM packages in a local source, and the relation information is stored as json objects, and meanwhile timeliness of queried data is ensured through timing updating, only one-time deployment is needed, and manual maintenance is not needed. Through html+nodejs, the entry of the RPM package query is provided for a Linux issuing user in a webpage form, and the user can input the RPM package name in a search box to query and acquire a result only by opening a query webpage.

2. And the basic service capability of the Linux distribution plate is improved. The local synchronous data of the Yum source are further arranged and processed and then provided for a user, so that the management configuration of the Linux software warehouse is optimized, more optimized service is provided, and the basic service capability of the Yum source software warehouse and the Linux distribution plate is further improved.

From the above description of the embodiments, it will be clear to those skilled in the art that the present invention may be implemented in hardware, or may be implemented by means of software plus necessary general hardware platforms. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.), and includes several instructions for causing a computer device (may be a personal computer, a server, or a network device, etc.) to execute the method described in the respective implementation scenario of the present invention.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, one of ordinary skill in the art will appreciate that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not drive the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims (10)

1. A method of querying rpm packet versions and paths in a yum source, comprising:

step 1, determining a root directory of a Yum source, acquiring a directory which is the same as a Yum source path in a local source, writing a query result into a file A, cutting out the Yum source path and storing the Yum source path into a file B;

step 2, acquiring information of all package names based on the file A, and storing the information into the file C as key information during inquiry;

step 3, obtaining complete version information of all packages based on the file A, and storing the complete version information into the file D, wherein the version information consists of epoch, version-release;

step 4, splicing and formatting the JSON file in a package name-version-path form according to the stored information;

step 5, periodically detecting and updating the JSON file, and synchronizing to the corresponding service directory;

and 6, providing a Web interface for a user to display, and acquiring JSON file data by the user only by inputting and submitting the package name.

2. The method for querying the rpm packet version and path in the yum source as claimed in claim 1, wherein the querying manner and storage flow in step 1 are as follows:

and inquiring the complete paths of all rpm package files under the same directory in the local source through a find command in the linux, redirecting and storing the complete paths into the file A, and comparing the actual root path of the Yum source, cutting out the paths corresponding to the paths identical to those of the Yum source by using awk, and redirecting and storing the paths into the file B.

3. The method for querying the rpm packet version and path in the yum source as claimed in claim 1, wherein the specific method for obtaining each packet name information in step 2 is as follows:

and using the cat file A, then using a pipeline symbol 'I' and using xargs to transfer parameter fragments to an rpm-q command, inquiring packet names by appointing with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and redirecting all inquired information to store the information into a new storage file C.

4. The method for querying the rpm packet version and path in the yum source as claimed in claim 1, wherein the method for obtaining the complete version information of each packet in the step 3 is as follows:

and transmitting information in the file A to an rpm query command through a cat file A by utilizing a pipeline character and a xargs command, printing version information in an epoch: version-release format by utilizing a queryFormat parameter, intercepting the version information which is empty by the epoch by utilizing a sed command, and finally redirecting the version information to be stored in a storage file D.

5. The method for querying the rpm package version and path in the yum source as claimed in claim 1, wherein the manner of splicing and obtaining the final json file in step 4 is as follows:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

6. The method for querying the rpm packet version and path in the yum source as claimed in claim 1, wherein the method for periodically updating the json file in step 5 is as follows:

integrating a process tool for generating a json file F into a timing task crontab of a local source server, judging whether all processes of the step 1-the step 5 are needed or not by calculating an MD5 value of a file A before executing the process for generating the json, and indicating that the Yum source data is unchanged and the json file is not needed to be updated when the MD5 value of a new file A is the same as an old MD5 value; after updating and generating a new json file, using a cp/scp command to update the json file to the htm l file and the same directory in the step 2 at regular time.

7. The method for querying the rpm package version and path in the yum source as claimed in claim 1, wherein the usage pattern presented to the user in the step 6 is:

generating a simple static search box comprising a search input field and a clickable search key through htm l, associating the simple static search box to a custom function G in a Java pt through a click event to realize interaction, triggering the Java pt to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, inquiring a json file by the package name and the current page number, returning only the content of the current page and the total count to the function G, transmitting json and the total count to a function H by the G, displaying the data of the current page to the front end according to the total count and json paging, judging whether the click event occurs, and calling the function G to inquire the page number data if the click event occurs.

8. A system for querying rpm packet versions and paths in a yum source, comprising:

the information processing module is used for determining a root directory of the Yum source, acquiring the directory which is the same as the Yum source path in the local source, writing the query result into the file A, cutting out the Yum source path and storing the Yum source path into the file B; the information processing module is also used for acquiring information of all package names based on the file A and storing the information into the file C as key information during inquiry; the information processing module is also used for acquiring complete version information of all packages based on the file A and storing the complete version information into the file D, wherein the version information consists of epoch, version-release; splicing and formatting JSON files in a 'package name-version-path' form according to stored information;

the automatic detection module is used for periodically detecting and updating the JSON file and synchronizing the JSON file to the corresponding service directory;

and the interaction module is used for providing a Web interface for a user to display, and the user can acquire the JSON file data only by inputting the package name and submitting the package name.

9. The system for querying version and path of rpm packet in yum source as claimed in claim 8, wherein the querying means and storage flow of the information processing module are:

inquiring the complete paths of all rpm package files under the same directory in a local source through a find command in linux, redirecting and storing the complete paths into a file A, and comparing the actual root path of a Yum source, cutting out paths corresponding to the paths identical to those of a Yum source by using awk, and redirecting and storing the paths into a file B;

the specific method for acquiring the packet name information of each information processing module comprises the following steps:

the cat file A is used, then the pipeline symbol I is used for transmitting parameter fragments to an rpm-q command by using the xargs, and inquiring packet names are agreed with the queryformat parameters to obtain independent information without version numbers, architecture and the like, and all the inquired information is redirected and stored in a new storage file C;

the method for obtaining the complete version information of each packet by the information processing module comprises the following steps:

transmitting information in the file A to an rpm query command by using a pipe character and a xargs command through the cat file A, printing version information of the version-release format by using a queryFormat parameter, intercepting the version information which is empty by the epoch by using a sed command, and finally redirecting the version information to be stored in a storage file D;

the information processing module is used for splicing and obtaining a final json file in the following manner:

combining the files C, D and B into a file E by rows by using a paste command, wherein the file E is the corresponding relation of the RPM package name, the package version information and the key-values of the Yum source path where the package is located; and processing each group of corresponding relations in the file E into a json object by using the jq command and redirecting the json object into the json file F.

10. The system of rpm packet version and path in a query yum source of claim 8,

the method for updating json file at regular time by the automatic detection module comprises the following steps:

integrating a process tool for generating a json file F into a timing task crontab of a local source server, judging whether all processes in the information processing module are needed or not by calculating an MD5 value of a file A before executing the process for generating the json, and indicating that the Yum source data are unchanged and the json file is not needed to be updated when the MD5 value of a new file A is the same as an old MD5 value; after updating and generating a new json file, periodically updating the json file to the htm l file and the catalog of the information processing module by using a cp/scp command, so that the json file can be updated and the data timeliness of the query tool can be maintained;

the use mode of the automatic detection module displayed to the user is as follows:

generating a simple static search box comprising a search input field and a clickable search key through htm l, associating the simple static search box to a custom function G in a Java pt through a click event to realize interaction, triggering the Java pt to transmit an initial page number and a package name to a rear-end nodejs when the event of clicking a search button occurs, inquiring a json file by the package name and the current page number and only returning the content of the current page and the total count to the function G by the rear-end nodejs, transmitting json and the total count to the function H by the function G, paging the data of the current page to the front end according to the total count and json, judging whether the page number clicking event occurs, and calling the function G to inquire the page data if the page number clicking event occurs.