Linux RPM and Tarball suite management tools (1)

Why do we need to upgrade the suite?
This is really an interesting topic. Why do we need to upgrade the suite? If my machine works well, why should I upgrade it? There are usually three reasons for our upgrade:
· New features are required, but old hosts do not. Therefore, a new suite needs to be installed;
· The old version of the suite may have security concerns, so you need to update it to the new version of the suite;
· The execution efficiency of earlier versions of suites is poor, or the execution capability cannot be satisfied by managers.
In the above requirements, we need to pay special attention to the second point. When a suite has security concerns, do not doubt it. Update the suite quickly! Otherwise, it may cause a network crisis. Isn't it a joke? So what are the update methods? In fact, there are many different update kits in Linux, including the online update mode of RPM and up2date developed by Red Hat; The dpkg Method Used in distribution of Debian; the pkg Upgrade Method Used in Sun Unix, the more popular online apt update mode, and the most frequently used Tarball Compilation Method in the original code, if I want to explain it one by one, is it too tiring? Therefore, here we will describe the common RPM and Tarball suite upgrade methods in the Linux distributions such as Mandrake, Red Hat, and OpenLinux:
· RPM
Currently, one of the most widely used suite management programs is to use the database management method to install the suite. It has a very easy operation interface and the suite query and verification function is quite powerful, however, the trouble lies in the dependency of its attributes;
· Tarball
Install the source code directly after compilation. It has great flexibility in installation and can change user-preferred parameters at any time. However, it requires assistance from other kits, such as gcc compiler, kernel-header, and make. In addition, it is difficult for anti-installation;
The two methods have their own advantages and disadvantages. Here we want to talk about the installation methods of RPM and Tarball!
RPM kit administrator:
Next, let's talk about the widely used RPM suite administrator methods!
· What are RPM and SRPM?
The RPM full name is "RedHat Package Manager! As the name suggests, the suite management program was developed by Red Hat, but many other suites also have similar suite management programs. However, RPM is easy to use, so it is now the most popular suite management program! So what is RPM? To put it simply, RPM installs the required suite to a set of management programs on your Linux host in a way recorded by the database. Its biggest feature is to package the package you want to install first, and record it through the preset database records in the package, record the dependency attribute modules required for installation of this suite. These modules are required for your Linux host.) When installed on your Linux host, RPM will first query whether the dependency attribute suite of the Linux host meets the requirements according to the records in the suite. If yes, it will be installed. If not, it will not be installed. During the installation, the information of this suite is written into the RPM database for future query, verification, and anti-installation! The advantage is:
1. The installation is convenient because the compilation is complete and the package is complete;
2. The information of the suite has been recorded in the database of the Linux host, which makes it easy to query, upgrade, and reverse install;
But this also caused a lot of trouble, because the RPM program is packed with information, that is to say, the information in it has been "compiled! Therefore, you must first install the host environment at the time of installation. That is to say, the installation environment of this suite must also appear on your host! For example, the rp-pppoe ADSL dial-up kit must be installed in the environment where the ppp suite exists! If your host does not have the ppp suite, sorry, unless you install ppp first, rp-pppoe won't let you install it. Of course, you can install it forcibly, however, a problem usually occurs !). Therefore, the RPM files released by different distribution cannot be used in other distribution files. For example, the RPM files released by Red Hat cannot be directly installed on Mandrake, what's more, different versions cannot communicate with each other. For example, the RPM file of Mandrake 9.0 cannot be directly applied to version 8.2! As a result, we can find that its disadvantages are:
3. The installation environment must be consistent with or equal to the environment requirements during packaging;
4. The dependency attribute needs to be met;
5. Be careful when installing anti-installation. The lowest-level suite cannot be removed first, otherwise it may cause problems in the entire system!
What should we do? Haha! Okay, there's SRPM! What is SRPM? He is also an RPM! However, since both the original code and the original code are included, you can re-compile the code. Generally, the file name of SRPM is ***. src. rpm. Because SRPM contains the original code and parameter setting file, you must re-compile the packaged information file suite before installation! Of course, if a problem occurs during the compilation process, you can also modify the problem with the original code! Therefore, the biggest difference between RPM and SRPM is whether there are programs that contain the original code!
· What is i386, i586, i686, noarch?
Okay! Now we know the RPM and SRPM formats, respectively:
The format of xxxxxxxxx. rpm <= RPM, the packaged rpm file, and the format of xxxxx. src. rpm <= SRPM, containing the compiled original code information.
·
OK! Is there any version of the rpm file or the name of the suite? Yes, you can look at an rpm file like a rp-pppoe-2.6-5.i386.rpm
Rp-pppoe-2.6-5. i386. rpm the first part is the suite name. This is the Suite version information. This is the number of releases. This is the appropriate hardware platform file name.
In this way, you can clearly find the name, version information, number of packages, and operating hardware platform of the suite! Okay. Let's talk about each different place:
O kit name: Of course, it is the name of each suite!
O version information: each time a version is updated, a version information is required. Otherwise, how can I know whether the version is new or old? Here, the main version and next version are usually divided. There are many versions!
O release number of versions: that is, the number of compilation times! So why do we need repeated compilation? This is because the same version of the suite may have some bugs or security concerns, so you must reset the set parameters when packaging, after setting, recompile and package it into an RPM file! So there are different packages!
O operating hardware platform: This is a very interesting place, because RPM can be applied to different operating platforms, but the parameters set by different platforms are still different! So the so-called i386, i586, i686 and noarch file names appear!
§ I386: It is applicable to almost all x86 platforms, including the old pentum or the new pentum-IV and K7 series CPUs! That I refers to Intel compatible CPU. As for 386, It is the CPU level!
§ I586: It's a 586-level computer. What is it? CPU levels include the first generation of pentum mmx cpu, AMD K5, and K6 series CPU (socket 7 plug-in;
§ I686: Intel series CPU after pentun II and CPU after K7 all belong to this 686 level!
§ Noarch: There is no hardware level limit.
Note that i386 files can be installed on any machine, whether 586 or 686, but i386 may not be used on 586 or 686 hardware, in addition, i686 files may be better executed on 686 of machines than i386 files! In any case, using i386 should be okay! In addition, because different distirbution environments and function libraries are different, you may also add the abbreviated version of this suite after i386!
Okay! Next, let's talk about the directory to be used during installation!
· Installation Directory required for SRPM and RPM
SRPM compilation process:
As mentioned above, some original codes are included in SRPM, so we need to compile and package SRPM! Where is the compilation performed? Because the original code is decompressed during compilation and the parameter control options are also removed at the same time, some materials will appear. Where should these materials be stored? You can check in your/usr/src directory. Generally, the directories provided by each distribution are different. Take Mandrake 9.0 as an example, he uses/usr/src/RPM as the working directory, Red Hat uses/usr/src/redhat as the working directory, and Openlinux uses/usr/src/openlinux as the working directory! In any case, it is in the/usr/src directory! Well, since we are in the Mandrake 9.0, go to/usr/src/RPM and have a look:
O/usr/src/RPM/SPEC: the configuration files of the suite are placed in this directory, such as the Information parameters and configuration items of the suite;
O/usr/src/RPM/SOURCE: This directory contains the original file * .tar.gz of the suite) and the config file;
O/usr/src/RPM/BUILD: during compilation, some temporary data will be stored in this directory;
O/usr/src/RPM/RPMS: After compilation and successful compilation, put the packaged files in this directory. There are sub-directories including i386, i586, i686, noarch... and so on.
In addition, unknown errors or set errors may occur during the compilation process. At this time, a corresponding error file will be generated under/tmp, you can perform the debugging based on this error file! After all the problems are solved, the compilation is successful. The files after decompression are in/usr/src/RPM/SPEC, SOURCE, all files such as BUILD will be killed, and only files placed under/usr/src/RPM/RPMS will be left!
RPM installation process:
When RPM is installed, it will first read the set parameter content in the suite, that is, the information we just got in/usr/src/RPM/SPEC! This document is then used to compare the environment of the Linux system. These environments include the precursor suite of the suite to be installed, such as the current postfix e-mail suite, most of them support the identity authentication feature of cyrus-sasl. Therefore, to install postfix, you must first install cyrus-sasl. Otherwise, the postfix will not allow you to install cyrus-sasl! There are also information about similar versions. These are the requirements of the RPM environment. If the environment is consistent, install them. If the environment is not consistent, the information will be displayed! After the installation is complete, the rpm will write the information about the suite to the/var/lib/rpm directory! Therefore, the relevant information will be provided by the content of the/var/lib/rpm directory when you are querying or are expected to upgrade! In addition, when installing RPM kits, these kits usually use the following directories:
O/etc directory for some configuration files, such as/etc/samba
O/usr/bin executable files
O/usr/lib dynamic library used by some programs
O/usr/share/doc basic software user manual and instructions
O/usr/share/man some man page files
Next, let's explain the RPM commands first!
· RPM command usage: security, upgrade and update, check and verify, anti-security and re-build information
RPM provides "installation", "upgrade and update", "query", "Verification", and "anti-Installation and reconstruction of databases". Let's explain it one by one!
O installation:
Installation is now available from scratch! So what is the installation method? If RPM is used, use ivh! If SRPM is used, use rebuild or recompiler!
[Root @ test/root] # rpm -- rebuild rp-pppoe-2.6-5.src.rpm <= SRPM [root @ test/root] # rpm -- recompile rp-pppoe-2.6-5.src.rpm <= SRPM [root @ test/root] # rpm-ivh rp-pppoe-2.6-5.i386.rpm <= RPM
-- Rebuild: this parameter will compile and package the subsequent SRPM, but it is not installed. When you use -- rebuild, at last, we usually find a line of Font:
Wrote:/usr/src/RPM/RPMS/i386/rp-pppoe-2.6-5.i386.rpm
This is the compiled RPM file! This file can be used for installation! Add an absolute path for installation!
-- Recompile: this action will directly "compile", "package", and "Install! Please note that rebuild is only "compile and package", while recompile not only compiles and packs, but also performs "Install" at the same time!
§-Ivh: this parameter is used to install RPM. Under this parameter, there may be "dependency attribute" problems or files that have been installed, therefore, you can add the following parameters to force the installation:
-- Nodeps: forcibly install nodeps without considering the dependency attribute;
§ -- Replacepkgs: If this suite has been installed before and you want to overwrite it, you can add -- replacepkgs to force overwrite it without installing it;
§ -- Replacefiles: What if the file has been modified after the package is installed? If "confilcting files" appears during the installation process, replacefiles will overwrite this file!
[Root @ test/root] # rpm-ivh rp-pppoe-2.6-5.i386.rpm [root @ test/root] # rpm-ivh -- nodeps rp-pppoe-2.6-5.i386.rpm <= not considering dependency modules [root @ test/root] # rpm-ivh -- replacepkgs rp-pppoe-2.6-5.i386.rpm <= directly overwrite the suite that has been installed [root @ test/root] # rpm-ivh -- replacefiles rp-pppoe-2.6-5.i386.rpm <= directly overwrite the modified problematic files
O upgrade:
Upgrading with RPM is really easy! Upgrade it with Uvh! However, in a large number of upgraded versions, it is better to use fvl. However, it should be noted that, if you are using fvl, but you still do not have this suite on your machine, you are sorry that this suite will not be installed on your Linux host, so install ivh again!
[Root @ test/root] # rpm-Uvh rp-pppoe-2.6-5.i386.rpm [root @ test/root] # rpm-fvl *. rpm <= All packages installed on your Linux host are upgraded
Note that Uvh is the package you have written for upgrading, and fvl is the package that only exists in your system 』, so some friends do the following when patching a large number of KIT versions:
　
1. Capture the latest i386 files on the errata website of various developers;
2. Use-fvl to fix and upgrade the kits installed in your system! It's really convenient !)
O query:
Query is also one of the important functions of RPM, because it provides the version, usage, and other information of this suite, which is quite useful! So how to query? The query parameters are listed below:
1. query Information obtained from the/var/lib/rpm database from the system) [root @ test/root] # rpm-q rp-pppoe <= only lists the version of the rp-pppoe suite; [root @ test/root] # rpm-qa <= List all installed kits and versions; [root @ test/root] # rpm-qi rp-pppoe <= list details of the rp-pppoe suite [root @ test/root] # rpm-ql rp-pppoe <= List the files and paths installed in the rp-pppoe package; [root @ test/root] # rpm-qf/etc/rc. d/init. d/pppoe <= which package does the pppoe file belong? 2. by the file query file content [root @ test/root] # rpm-qpi rp-pppoe-2.6-5.src.rpm <= query details of this suite; [root @ test/root] # rpm-qpl rp-pppoe-2.6-5.src.rpm <= query how many files exist in this suite
O
§ Query suite: You can use-q to query the installed Suite version. However, if you forget the full name of the suite, you can use
Rpm-qa | grep pakagename to select the appropriate suite!
If you use-qi, you can learn the main information about this suite!
Looking for a suite file: When we often forget the file contained in a suite content, we can use-ql to query the suite and list quite a few files!
§ Search for a suite by archive: this is the longest problem, that is, you "mistakenly cut" a file, but you don't know which suite it is! So you can ask your friends in the same system to use-qf to query the suite to which the archive belongs, and then reinstall the suite and you will be back!
O Verification:
The function of verification is mainly to provide a useful management mechanism for the system administrator! The function is to use the database content under/var/lib/rpm to compare all the suite files in the current Linux system environment. That is to say, when you accidentally lose any information, or because you accidentally killed the archives of a suite, or accidentally did not know the file content of a suite, you can use this simple method to verify the original file system! So that you can see which archives have been modified for a while!
[Root @ test/root] # rpm-V rp-pppoe <= check whether the file content of the installed rp-pppoe package is the same as that of the original [root @ test/root] # rpm-Va <= check whether all databases under/var/lib/rpm are the same files as those in Linux! Example: [root @ test/root] # rpm-V xinet s.5 .... T c/etc/xinetd. d/echo s.5 .... T c/etc/xinetd. d/echo-udp s.5 .... T c/etc/xinetd. d/time s.5 .... T c/etc/xinetd. d/time-udp parameters before file Name Description S: file Size differs file capacity has been changed) M: Mode differs (supported des permissions and file type) the file type or attributes, such as whether the file can be executed, and other parameters have been changed.) 5: MD5 sum differsMD5, an encryption and Anti-Terrorism attribute, has been changed.) D: device major/minor number mis-match Device name changed) L: readLink (2) path mis- The matchLink attribute has been changed) U: the ownership differs file owner has been changed) G: the Group to which the Group ownership differs file belongs has been changed) T: the Creation Time of the mTime differs file has been changed.) [root @ test RPM] # rpm-ql crontabs <= query what files does crontabs have? /Etc/cron. daily/etc/cron. hourly/etc/cron. monthly/etc/cron. weekly/etc/crontab [root @ test RPM] # rpm-V crontabs <= which files have been modified? S.5... T c/etc/crontab
For example, in the above example, we know that crontabs has five files or directories. If we verify the files, we will find that/etc/crotab has been changed? If the change to the archive is "expected", there will be no major problems. But if the archive is "unexpected", will it be infiltrated? Haha! Pay attention to it!
O Anti-Installation and Reconstruction of the database:
Uninstalling the package! Note that "the installation process must be removed from the top layer". Taking rp-pppoe as an example, this suite is mainly installed based on the ppp suite, therefore, to remove ppp, you must first remove rp-pppoe! Otherwise, structural problems will occur! This can be explained by the building. If you want to demolish the fifth and sixth floors, of course, the sixth floor should be demolished; otherwise, the fifth floor should be demolished, so will the above floors be suspended?
What about rebuilding the database? Because we are constantly modifying some file content, such as/etc/xinetd. the parameter files in "d" and the operations that may be added or removed during system operations lead to a messy system database. In this case, you can use "-- rebuilddb" to recreate the rpm database! The parameters of these two methods are as follows:
[Root @ test/root] # rpm-e re-pppoe <= deinstalling rp-pppoe [root @ test/root] # rpm -- rebuilddb <= rebuilding the database