Shulou(Shulou.com)06/01 Report--

This article focuses on "how to understand the installation and management of software packages under Linux". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the installation and management of software packages under Linux.

Let's take a look at the Linux software extension. The software suffix .rpm was originally a package encapsulation format provided by Red Hat Linux and is now used by many Linux distributions; the suffix .deb is a package encapsulation format provided by Debain Linux; the suffix .tar.gz, tar.Z, tar.bz2 or .tgz is packaged using the Unix system packaging tool tar; the suffix .bin is generally some commercial software. Through the extension, you can understand the software format, and then understand the software installation.

One source installation mode

Because the linux operating system is open source, most of the software installed on it is open source software, such as apache, tomcat, php and so on. Open source software basically provide source code download, source code installation; the advantage of source code installation is that users can customize the software functions, install the required modules, unnecessary functions can not be installed, in addition, users can also choose their own installation path to facilitate management, uninstall the software is also very convenient, just delete the corresponding installation directory. There is no such thing as a registry in windows.

The source code installation software generally consists of the following steps: download and decompress the source code, analyze the installation platform environment (ifconfigure), and compile and install the software (make,make install). Let's introduce each of them.

1.1 download the decompression source code

The source code of software under linux is generally written in C or C++ language, and the source package is available for download on the official website of the software. For example, the official website of the apache open source project is http://www.apache.org. In addition, many open source communities on the Internet generally provide downloads of some commonly used software source code, which are packaged into compressed files. Common source code packaging and compression formats are ".tar.gz", ".tar.baz2" and so on. We can first download the source code file from the website, and then transfer it to the linux system, if your linux system is in a network state, you can also download the source code package directly to the linux system through download commands such as wget in the system.

Download is complete, the corresponding software can be unpacked, according to the different download packages, use different methods to decompress, after decompression into the directory generated by decompression, in this directory, there is generally a REDAME file, this text file is very important, it describes in detail the functions that the software can complete, licensing, installation requirements, installation precautions, installation methods and so on Due to the differences in different versions of linux, as well as the installation environment, the installation of the software is also different, so before installing the software, be sure to read this README file in advance to ensure the correctness of the installation.

1.2 analyze the installation platform environment

After the package is decompressed, we go to the source directory. Generally, there are two files, configure and README. README is the introduction and installation instructions for the software mentioned above. The installation of software under linux is affected by the installation environment of the operating system, for example, some software needs to call the library file of the operating system itself during installation or operation, or needs to run a tool of the system, etc., but the library file does not exist in the system or the tool is not installed, then the installation or operation of the software will fail.

In order to avoid this problem, it is necessary to analyze the operating system environment when installing the software, check whether the current system has all the files and tools needed to install the software, and give a prompt if the system is missing a file. until all the requirements of the software are met. This is the function of the configure file, the configure file is generally an executable file, you can directly enter ". / configure" in the current directory for software installation environment testing, if prompted for the lack of some installation packages, you need to install until the test passes. Usually, the source code installation requires GCC or CC compilers, these compilers are generally customized when installing the system under the development tools options in the installation package, in fact, this is why we are required to choose the development kit in the second chapter of installing the linux system.

In addition, when performing configure analysis of software requirements, you can also add some options such as the installation path of the software and the modules required for installation after ". / configure" to customize the software functions that users need.

1.3 compile and install the software

After verifying the software installation environment, formally enter the compilation step of the software, before compiling, first understand some basic knowledge about compilation.

Under linux system, make is a compilation command that we often use. No matter when installing software or project development, we often use compilation and installation commands, that is, make and make install. For an application that contains a lot of source files, using make and makefile tools can simply and quickly solve the complex dependencies between various source files. At the same time, make tools can also automatically complete the compilation of all source files. And only the files modified after the last compilation can be compiled incrementally, so after mastering the make and makefile tools, the source code installation software becomes as simple as installing the software under windows.

Makefile file

The main function of the make tool is realized through the makefile file. The makefile file is written according to a certain syntax, which defines the dependency between the source files, and explains how to compile the source file and generate the executable file. It allows the make tool to complete the compilation work automatically by describing the relationship between the various source programs.

Under the linux system, it is customary to replace the makefile file with Makefile. After we execute configure, we will generate this file in the current directory. Generally speaking, when you enter make on the command line, the make command will default to find the Makefile file in the current directory. If we use other files as makefile, we should specify the makefile file after the make command option. For example, we set the compilation rule file to make_file. You need to specify using the following command:

[root@WEBServer] # make-f make_file

Let's take an example to understand the writing principles and content of Makefile.

For example, there is a test program, there are three source files file1.c, file2.c, file3.c and library file LS compiled and generated, these three source files also contain their own header files 1.h, 2.h, 3.h. Typically, the C compiler will output three target files, file1.o, file2.o, and file3.o. Suppose both file1.c and file3.c declare that an apcs file is used, but file2.c does not, that is, there is a declaration like "# include" apcs "in both file1.c and file3.c files.

The following code describes the test program:

1:#It is an example for describing makefile2:test: file1.o file2.o file3.o3:cc file1.o file2.o file3.o-LS-o test

4:file1.o: file1.c 1.h apcs

5:gcc-c file1.c

6:file3.o: file3.c 3.h apcs

7:gcc-c file3.c

8:file2.o: file2.c c.h

9:gcc-c file2.c

The description document is actually a makefile file, the first behavior comment line, the second line specifies that the test program has file1.o, file2.o, file3.o link generation, the third line describes how to create an executable file from the file on which test depends, and the next four, six, and eight lines define the three target files and their dependent ".c", ".h" and "apcs" files. The remaining lines 5, 7, and 9 define how to generate executables from files that the target depends on.

After understanding the Makefile file structure, we can control the compilation options and customize the software functions we need.

Next, we only need to enter the make command on the command line to enter the compilation phase. According to the size of the software source program and the hardware configuration of the system, the compilation time varies, and the corresponding executable files will be generated in the current directory and subdirectory. Next, we will enter the final stage of installing the software, enter the make install command on the command line, and begin to install the software. The installation process will first create the installation directory. If we do not specify the installation directory, the installer will by default install in the / usr/local directory of the system to create the installation directory, and then copy the corresponding files and executables from the source directory to the installation directory, so that the installation is complete.

1.4 Source Code installation of Apache Http server

Below we install apache through the source code, and an example explains how to install the source code under linux.

1. Download and decompress apache source code

[root@WEBServer~] # mkdir / apache # create an apache directory under the root directory [root@WEBServer~] # cd / apache # switch to the apache directory [root@WEBServer apache] # wget\ # download apache source code > http://apache.mirror.phpchina.com/httpd/httpd-2.2.9.tar.bz2[root@WEBServer apache] # tar-jxvf httpd-2.2.9.tar.bz2 # decompress the apache source code [root@WEBServer apache] # ls # display solution Pressure result httpd-2.2.9 httpd-2.2.9.tar.bz2

2. Test the installation environment

[root@WEBServer apache] # cd httpd-2.2.9 # switch to [root@WEBServer httpd-2.2.9] # / configure-- prefix=/opt/apache2.2.9\ >-- enable-so\ >-- enable-mods-shared=most\ under the httpd-2.2.9 directory

>-- enable-proxy-balancer=shared\

>-- enable-proxy-http=shared\

>-- enable-proxy-ajp\

>-- enable-rewrite

Note: above we specify the installation directory of apache as / opt/apache2.2.9 and the apache modules that need to be compiled.

The meanings of these modules are described below. Please refer to the apache documentation for more details.

L-- enable-so option: means to allow Apache to support DSO mode, which uses the later syntax of Apache2.0. If your Apache is version 1.3, change it to "--enable-module=so".

L-- enable-mods-shared=most option: indicates dynamic compilation of most commonly used modules. Of course, you can optionally load some modules. Most means to include only commonly used modules and load them in dynamic loading mode. If you are using Apache1.3, change it to "--enable-shared=max".

L-- enable-proxy-balancer=shared option: allows apache to support load balancing, that is, dynamically compiling the load balancing module of apache.

L-- enable-proxy-http=shared option: represents the http proxy module that dynamically compiles apache.

L-- enable-proxy-ajp option: represents the proxy-ajp module that dynamically compiles apache.

L-- enable-rewrite option: let apache support address rewriting, that is, dynamically compile apache's rewrite module.

3. Compile and install software

[root@WEBServer httpd-2.2.9] # make

[root@WEBServer httpd-2.2.9] # make install is installed, apache is installed under / opt/apache2.2.9, and then we can use the apache software.

2 RPM package installation

2.1 introduction to RPM package management tools

RPM is the abbreviation of Red Hat Package Manager, the original meaning is Redhat software package management, is the first linux software package management tool developed by Redhat company, because this kind of software management method is very convenient, it is gradually borrowed by other linux publishers, and now it has become a general software package management method under the linux platform, such as Fedora, Redhat, suse, Mandrake and other mainstream linux distributions all adopt this software package management mode by default.

RPM package management is similar to add / remove programs under windows, but is much more powerful than add / remove programs. On the Linux system installation CD, there are many packages that end with ".rpm". These package files are what we call RPM files. Each RPM file contains the compiled binary executable file, in fact, the software source code file is compiled and installed, and then packaged into a RPM file, similar to the ".exe" file in the windows installation package. In addition, the RPM file also contains other files needed to run the executable file, which is similar to the software package under windows. In the installation package of the windows program, in addition to the "exe" executable file, there are other files that depend on running.

The advantage of RPM package management is that it is easy to install, because the software has been compiled and packaged, and installation is just a process of verifying the environment and decompressing. In addition, software installed through RPM, RPM tools will record the installation information of the software, which facilitates future software query, upgrade and uninstall.

The disadvantage of RPM package management is that it is highly dependent on the operating system environment, which requires that the installation environment of RPM packages must be consistent with or equivalent to that of RPM packages. It also needs to meet the dependency on some software packages of the system during installation, for example, software A needs to be installed, but software A requires that the system is supported by B and C software, so B and C software must be installed before A software can be installed. This is also what we need to pay special attention to when installing software with RPM packages.

2.2 RPM package types and commands

There are generally two encapsulation formats of RPM package, namely RPM and SRPM,SRPM package, which is also a kind of RPM, but it contains the source file at compile time and some parameter files specified by compilation, so it needs to be recompiled when it is used. Usually, the RPM file corresponding to SRPM is similar to the "xxxxxxxx.src.rpm" format.

Let's talk about the meaning of the file names corresponding to the two RPM packages:

For example, a rpm file: nxserver-2.1.0-22.i386.rpm where "nxserver" indicates the name of the software, "2.1.0" indicates the version number of the software, "22" indicates the number of software updates and releases, "i386" indicates the platform suitable for the hardware, and the final ".rpm" is the identity of the rpm package.

The general naming format of the RPM package consists of these five parts. Because the SRPM package needs to be compiled before it can be used, there is no corresponding platform option in the items shown above, and the other is exactly the same as the RPM package command format.

For the five components of the RPM package, here are some of their more detailed meanings and similarities and differences:

Software name: is the identification of the software package

Software version number: each software has its own version number, which can indicate how much the software has been released from the beginning to the present, whether the software is new, and so on.

The number of software updates released: because a version of software may have bug or vulnerabilities after release, it needs to be repaired and re-packaged. Each time the package is repaired, the name of the software will be updated.

Suitable hardware platform: because the RPM package is used on a variety of different linux hardware platforms, but because each different hardware platform RPM package package parameters are also different, so there is a platform name identification for i386, i686, x86room64, noarch and so on.

I386 means that this package is suitable for computers with x86 architecture after intel 80386.

I686 refers to computers with x86 architecture after intel 80686 (Pentium pro or above).

X86 processors 64 means that this software package is suitable for computers with 64 processors in x86 architecture.

Noarch said that the package is independent of hardware architecture and can be used in general.

It should be noted that i386 software packages can be used on any x86 platform, whether on i686 or x86664 machines. On the contrary, i686 software packages may not be used on i386 hardware. Because i686 software packages are generally optimized for cpu, all have backward compatibility, but do not have previous compatibility features.

RPM package ID: the RPM package ID is used to indicate that this file is in rpm format, usually with two suffixes, ending with ".rpm" and ending with ".src.rpm".

2.3 use of RPM tools

The use of RPM tools is divided into installation, query, verification, update, deletion and other operations, which are described below.

1. Install the package

Command format: rpm-I [ancillary options] file1.rpm file2.rpm... .. fileN.rpm main option description:

-i:install means to install software. You can also use "--install".

Parameter description: file1.rpm file2.rpm … ... filen.rpm is the file name that specifies the RPM package to be installed, which can be installed with multiple files.

Auxiliary options description: there are many options here. We only list the common options, which are explained in detail as follows:

L-v: displays additional information.

L-h: output the flag "#" during installation.

L-- test: only tests the installation, not the actual installation.

L-- nodeps: does not check for dependencies between software. Adding this option may cause the software to become unavailable.

L-- force: ignore software packages and software conflicts.

L-- replacepkgs: forces reinstallation of already installed packages.

L-- prefix: installs the package to the path specified by.

L-- percent: outputs the progress of the installation as a percentage.

L-- excludedocs: do not install the documentation in the package l-- includedocs: install the package, including the documentation.

For example:

(1) We install ipvsadm-1.24-6.i386.rpm, using the following command:

[root@localhost ~] # rpm-ivh ipvsadm-1.24-6.i386.rpm execution result is as follows:

Warning:ipvsadm-1.24-6.i386.rpm:V3 DSA signature: NOKEY, key ID 44e181 setting. # # [100%]

1:ipvsadm # # [100%]

(2) the following operation shows the process of installing the gcc-3.4.4-2.i386.rpm package. During the installation, the problem of installation package dependency occurs. Our process is as follows:

[root@server ~] # rpm-ivh gcc-3.4.4-2.i386.rpm execution result is as follows:

Warning: gcc-3.4.4-2.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60eerror: Failed dependencies:

Glibc-devel > = 2.2.90-12 is needed by gcc-3.4.4-2.i386Suggested resolutions:

Glibc-devel-2.3.4-2.13.i386.rpm

This shows the support for installing the glibc-devel package before installing the gcc compiler. The detailed version of this package is glibc-devel-2.3.4-2.13.i386.rpm, so we need to install this package first.

[root@server ~] # rpm-ivh glibc-devel-2.3.4-2.13.i386.rpm execution result is as follows:

Warning: glibc-devel-2.3.4-2.13.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60eerror: Failed dependencies:

Glibc-headers is needed by glibc-devel-2.3.4-2.13.i386glibc-headers = 2.3.4-2.13 is needed by glibc-devel-2.3.4-2.13.i386Suggested resolutions:

Glibc-headers-2.3.4-2.13.i386.rpm

There are dependencies again, and the error above says that to install the glibc-devel package, you need to install the glibc-headers package first, and the recommended installation version is given, so we install the glibc-headers package first.

[root@server ~] # rpm-ivh glibc-headers-2.3.4-2.13.i386.rpm execution result is as follows:

Warning: glibc-headers-2.3.4-2.13.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60eerror: Failed dependencies:

Kernel-headers is needed by glibc-headers-2.3.4-2.13.i386kernel-headers > = 2.2.1 is needed by glibc-headers-2.3.4-2.13.i386Suggested resolutions:

Glibc-kernheaders-2.4-9.1.98.EL.i386.rpm

The error is still reported, and the message is the same as above, which means that before installing the kernel-headers package, we need the support of the glibc-kernheaders package, and given the recommended version, let's install the glibc-kernheaders package first.

[root@server ~] # rpm-ivh glibc-kernheaders-2.4-9.1.98.EL.i386.rpm execution result is as follows:

Warning: glibc-kernheaders-2.4-9.1.98.EL.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... # # [100%]

1:glibc-kernheaders # # [100%]

This time the dependency is finally released and the installation begins in reverse order. The installation steps are shown below.

[root@server] # rpm-ivh glibc-headers-2.3.4-2.13.i386.rpmwarning: glibc-headers-2.3.4-2.13.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... # # [100%]

1:glibc-headers #

[root@server] # rpm-ivh glibc-devel-2.3.4-2.13.i386.rpmwarning: glibc-devel-2.3.4-2.13.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... # # [100%]

1:glibc-devel #

[root@server] # rpm-ivh gcc-3.4.4-2.i386.rpmwarning: gcc-3.4.4-2.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... # # [100%]

1:gcc # # [100%]

(3) in the above example, if we add the parameter "--nodeps" in the first step of installing gcc, gcc can be installed successfully because it does not check the dependencies:

[root@server ~] # rpm-ivh gcc-3.4.4-2.i386.rpm-nodeps execution result is as follows:

Warning: gcc-3.4.4-2.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... # # [100%]

1:gcc # # [100%]

A parameter that ignores dependencies is added here, although it can be successfully installed, but we do not recommend it, because the installed software is likely to be unavailable or have problems with its use. this parameter can be used only if we know that ignoring dependencies has no effect on the software itself.

(4) how to install xxxxxx.src.rpm. Here we take the name of my-package.src.rpm as an example and introduce it under the redhat linux i386 platform. There are two common methods. The steps are as follows:

Method 1:

1) execute rpm-I my-package.src.rpm

2) cd / usr/src/redhat/SPECS

3) rpmbuild-bp my-package.specs a specs file with the same name as the package.

4) cd / usr/src/redhat/BUILD/my-package/ A directory of a software package with the same name 5). / configure this step is the same as compiling ordinary source software, you can add parameter 6) make7) make install

Method 2:

1) execute rpm-I my-package.src.rpm

2) cd / usr/src/redhat/SPECS

The first two steps are the same as method one.

3) rpmbuild-bb my-package.specs a specs file with the same name as the package.

At this point, in / usr/src/redhat/RPM/i386/ (the path here may be i686, noarch, and so on, depending on the package), there are one or two new rpm packages in this directory, and this is the compiled binary.

4) execute rpm-I new-package.rpm, and the installation is complete.

For example, install rsh software using a package in xxxx.src.rpm format as follows:

[root@localhost ~] # rpm-I rsh-0.17-25.3.src.rpm [root@localhost ~] # cd / usr/src/redhat/SPECS/rsh.spec [root@localhost SPECS] # rpmbuild-bb rsh.spec [root@localhost SPECS] # cd / usr/src/redhat/RPMS/i386/rsh-0.17-25.3.i386.rpmrsh-debuginfo-0.17-25.3.i386.rpm

Rsh-server-0.17-25.3.i386.rpm

[root@localhost i386] # rpm-ivh rsh-*

Preparing... # # [100%]

1:rsh-server # # [33%]

2:rsh # # [67%]

3:rsh-debuginfo #

[root@localhost i386] #

2. Query software package

Command format: rpm-Q [ancillary options] package1... Description of the packageN primary option:

-q:query means "--query" can also be used.

Parameter description: package1... PackageN is the name of the package that has been installed.

Auxiliary option description:

L-f: query which corresponding rpm package a file belongs to in the operating system.

For example:

[root@localhost ~] # rpm-qf / bin/bash

Bash-3.0-19.2

L-p: query the package name after installation of the package with the suffix ".rpm".

For example:

[root@server ~] # rpm-qp gcc-3.4.4-2.i386.rpmgcc-3.4.4-2 you can see from the query here that after "gcc-3.4.4-2.i386.rpm" is installed on the system, the corresponding package name is gcc-3.4.4-2.

L-l: displays a list of all files in the package. This option is followed by the package name corresponding to the package installation, keeping in mind that it is not a rpm package with the suffix ".rpm".

For example:

[root@server] # rpm-ql gcc-3.4.4-2

/ usr/bin/c89

/ usr/bin/c99

/ usr/bin/cc

/ usr/bin/gcc

/ usr/bin/gcov

. (omitted below).

L-I: displays an overview of the package, such as software name, version, adaptation platform, size, and so on. This option is followed by the full package name, and do not use rpm packages with the suffix ".rpm".

For example, before getting a software, you usually need to see what the package contains before you install it. You can use the following command:

[root@server ~] # rpm-qi gcc-3.4.4-2.i386 or use [root@server ~] # rpm-qpi gcc-3.4.4-2.i386.rpm. Because the "- p" option is used, the installed package name is first displayed, so the "- I" option can be followed by the package ending with ".rpm".

L-g: query which software packages belong to the specified category in the system. According to the different functions of the software, the RPM tool divides the software into many categories, as follows, with comments in parentheses:

Amusements/Games (Entertainment / Games)

Amusements/Graphics (Entertainment / Graphics)

Applications/Archiving (Apps / Archives)

Applications/Communications (applications / Communications)

Applications/Databases (application / database)

Applications/Editors (application / editor)

Applications/Emulators (application / simulator)

Applications/Engineering (Application / Engineering)

Applications/File (application / file)

Applications/Internet (applications / Internet)

Applications/Multimedia (application / multimedia)

Applications/Productivity (applications / products)

Applications/Publishing (Application / Printing)

Applications/System (application / system)

Applications/Text (application / text)

Development/Debuggers (developer / debugger)

Development/Languages (Development / language)

Development/Libraries (development / function library)

Development/System (Development / system)

Development/Tools (development / tools)

Documentation (documentation)

System Environment/Base (system Environment / Foundation)

System Environment/Daemons (system environment / daemon) System Environment/Kernel (system environment / kernel) System Environment/Libraries (system environment / function library) System Environment/Shells (system environment / interface) User Interface/Desktops (user interface / desktop) User Interface/X (user interface / X window)

User Interface/X Hardware Support (user interface / X hardware support) for example: to see how many packages the current system belongs to the developer / Debugger category, use the following command:

[root@server] # rpm-qg "Development/Debuggers" lsof-4.72-1.1crash-4.0-2

Sysreport-1.3.15-5

Ltrace-0.3.36-2.EL4

Strace-4.5.13-0.EL4.1

Valgrind-2.2.0-5.EL4

Valgrind-callgrind-0.9.9-1

Gdb-6.3.0.0-1.63

Pstack-1.2-6

L-d: displays a list of description files in the package. RPM divides the files in the package into three categories: configuration files, description files, and executable files. Followed by the full package name, do not use a rpm package with the suffix ".rpm".

For example: view the documentation in the file package and use the following command:

[root@server108 cicro] # rpm-qd file-4.10-2/usr/share/doc/file-4.10/LEGAL.NOTICE/usr/share/doc/file-4.10/README

/ usr/share/man/man1/file.1.gz

/ usr/share/man/man3/libmagic.3.gz

/ usr/share/man/man5/magic.5.gz

L-s: similar to the "- l" option, except for the list of all files in the package, it also shows the status of each file. Each file in the installed software package of RPM has four states, namely, normal (normal state, indicating that the file has not been modified by other software packages), not installed (not installed, indicating that the file is not installed), replaced (replaced state, indicating that this file has been modified and replaced by other software packages), net shared (network sharing state, indicating that the file is in network sharing state).

For example: to view the status of each file in the ipvsadm-1.24-6 package, use the following command:

[root@localhost ~] # rpm-I-excludedocs ipvsadm-1.24-6.i386.rpm [root@localhost ~] # rpm-qs ipvsadm-1.24-6normal / etc/rc.d/init.d/ipvsadmnormal / sbin/ipvsadm

Normal / sbin/ipvsadm-restore

Normal / sbin/ipvsadm-save

Not installed / usr/share/doc/ipvsadm-1.24not installed / usr/share/doc/ipvsadm-1.24/READMEnot installed / usr/share/man/man8/ipvsadm-restore.8.gznot installed / usr/share/man/man8/ipvsadm-save.8.gznot installed / usr/share/man/man8/ipvsadm.8.gz can be seen from above that we specified not to install the documentation when installing ipvsadm-1.24-6.i386.rpm Then when you view the file status through the "- s" command, the documentation status of the package is "not installed".

L-R (or-- requires): displays the functions required by the software package, which can be package identification, shared dynamic library files, and so on. The dependency of the software package depends on the function. If the required function does not exist, the dependency relationship must not be satisfied, and the software installation will fail.

L-- provides: displays the functions provided by the package, which can be dynamic library files, package names of virtual software, and so on.

For example: to view the features provided by nxclient-2.1.0-17.i386.rpm, use the following command:

[root@localhost] # rpm-qp-- provides nxclient-2.1.0-17.i386.rpmnxclient = 2.1.0-17 you can see that this software provides the functionality of nxclient.

3. Verify the package

Verify installed software packages

Verifying that a package compares the information of the installed file of a software package with that of the same file in the original package. It verifies the size, permissions, MD5 value, type, owner, and group of each file.

Command format: rpm-V [ancillary options] package1... Description of the packageN primary option:

The meaning of V:verify can also be replaced by "--verify". The main purpose of this parameter is to verify that the files in the installed package are consistent with the original installation.

Parameter description: package1... PackageN indicates the name of the package that needs to be verified and has been installed.

Auxiliary option description:

L-p: verify the package file

For example, the following is to verify the installation status of the rsh package, and the procedure is as follows:

[root@localhost] # rpm-V rsh-0.17-25.3

Package rsh-0.17-25.3 is not installed

[root@localhost] # rpm-Vp rsh-0.17-25.3.i386.rpmwarning: rsh-0.17-25.3.i386.rpm: V3 DSA signature: NOKEY, key ID db2a6emissing / usr/bin/rcpmissing / usr/bin/rexec

Missing / usr/bin/rlogin

Missing / usr/bin/rsh

Missing d / usr/share/man/man1/rcp.1.gz

Missing d / usr/share/man/man1/rexec.1.gzmissing d / usr/share/man/man1/rlogin.1.gzmissing d / usr/share/man/man1/rsh.1.gz [root@localhost ~] # rpm-ivh rsh-0.17-25.3.i386.rpmwarning: rsh-0.17-25.3.i386.rpm: V3 DSA signature: NOKEY, key ID db2a6ePreparing... # # [100%]

1:rsh #

[root@localhost] # rpm-Vp rsh-0.17-25.3.i386.rpmwarning: rsh-0.17-25.3.i386.rpm:V3 DSA signature: NOKEY, key ID db2a6e [root@localhost ~] # rpm-V rsh-0.17-25.In the above operation, we first verify that rsh is not installed on the system, and then we install the rsh package. When we check the rsh package status again, there is no output. Indicates that the package files are all normal.

L-f: verify the status of the file in the package to which it belongs, followed by the corresponding file name.

For example, check the status of each file in the mysqlclient package. Our actions are as follows:

[root@localhost] # rpm-ql mysqlclient10- 3.23.58-4.RHEL4.1/etc/ld.so.conf.d/mysqlclient10-i386.conf/usr/lib/mysql/libmysqlclient.so.10/usr/lib/mysql/libmysqlclient.so.10.0.0

/ usr/lib/mysql/libmysqlclient_r.so.10

/ usr/lib/mysql/libmysqlclient_ r.so.10.0 [root @ localhost ~] # mv\ > / usr/lib/mysql/libmysqlclient.so.10 / usr/lib/mysql/libmysqlclient.so.10.d [root@localhost ~] # rpm-V mysqlclient10-3.23.58-4.RHEL4.1missing / usr/lib/mysql/libmysqlclient_ r.so.10 [root @ localhost ~] # rpm-Vf / usr/lib/mysql/libmysqlclient_r.so.10missing / usr/ Lib/mysql/libmysqlclient_r.so.10# here we first checked all the files contained in the mysqlclient package Then simulate deleting a file in the mysqlclient package, and then check the status of the file, you can see that it is displayed as "missing". If we check a file through the "- Vf" option and there is no output, it means that the file is in a normal state.

L-a: verify all software packages.

L-g: verify all software packages that belong to the group.

Verify uninstalled package files

Whether the released package in RPM format is trustworthy and corrupted can be verified by the options provided by RPM. RPM packages are generally signed by Gnu Privacy Guardians, or GPG, to help users confirm the trustworthiness of downloading packages.

Command format: rpm-K file1.rpm... FileN.rpm

Description of the main option:

-K: the meaning of checksig can also be replaced by "--checksig". This option is used to check the md5 checksum GPG signature of the RPM package file.

Parameter description: file1.rpm... FileN.rpm indicates that the package name needs to be verified.

Example: if you want to verify whether a software package has been tampered with or damaged, you can check it with the following command:

[root@localhost ~] # rpm-K nxserver-2.1.0-22.i386.rpmnxserver-2.1.0-22.i386.rpm: md5 OK the "md5 OK" here indicates that the file was not corrupted or tampered with during the download. That is, this file is secure.

[root@localhost ~] # rpm-K ipvsadm-1.24-6.i386.rpmipvsadm-1.24-6.i386.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#443e1821) the output above indicates that the software is not authorized to sign, so be careful when installing packages that are not authorized by linux publishers, as these packages may contain harmful code.

4. Update the package

Command format: rpm-U [ancillary options] file1.rpm... Description of the fileN.rpm primary option:

-U:upgrade means "--upgrade" instead.

Parameter description: file1.rpm... FileN.rpm represents the rpm package that needs to be upgraded.

Auxiliary option description:

-- oldpackage means to allow "upgrade" to an older version, that is, software version degradation.

The other options are exactly the same as installing the auxiliary parameters of the RPM package, which are not covered here.

Example: we upgrade rsh from rsh-0.17-25.3 to rsh-0.17-37.el5 as follows:

[root@localhost] # rpm-Q rsh

Rsh-0.17-25.3

[root@localhost] # rpm-Uvh rsh-0.17-37.el5.i386.rpmwarning: rsh-0.17-37.el5.i386.rpm: V3 DSA signature: NOKEY, key ID 37017186 recording. # [100%]

1:rsh # # [100%]

[root@localhost] # rpm-Q rsh

Rsh-0.17-37.el5

5. Delete the software package

Command format: rpm-e [accessibility] package1... Description of the packageN primary option:

The meaning of e:erase can also be replaced by "--erase".

Parameter description: package1... PackageN indicates the name of the package that has been installed.

Auxiliary option description:

L-- test: only delete tests are performed.

L-- nodeps: do not check for dependencies.

For example:

(1) remove the rsh package and use the following command:

[root@localhost] # rpm-Q rsh

Rsh-0.17-37.el5

[root@localhost ~] # rpm-e rsh-0.17-37.el5 [root@localhost ~] # rpm-q rshpackage rsh is not installed

(2) delete the gcc package, but there is a dependency. The operation procedure is as follows:

[root@server] # rpm-e gcc

Error: Failed dependencies:

Gcc = 3.4.4-2 is needed by (installed) gcc-c++-3.4.4-2.i386gcc = 3.4.4-2 is needed by (installed) gcc-g77-3.4.4-2.i386gcc = 3.4.4-2 is needed by (installed) gcc-java-3.4.4-2.i386gcc = 3.4.3 is needed by (installed) libtool-1.5.6-4.EL4.1.i386gcc is needed by (installed) systemtap-0 .4-0.EL4.i386 here again delete dependencies According to the above tips, to delete gcc software packages, you must delete five packages that are interdependent with gcc. This operation should be very careful. Do not delete blindly unless you know that there is no impact on the system after deletion, as this may lead to system crash.

In fact, we can also add the "- nodeps" parameter to ignore the dependencies, but this may lead to the unavailability of the dependent software.

III. Installation mode of binary software

The binary format software under Linux means that the relevant software has been compiled and installed on various platforms in advance, and then compressed and packaged, and only need to decompress or execute the installation executable file during installation. This software distribution format is similar to the windows system, the reason for this is to protect source code programs from disclosure and protect intellectual property rights. The advantage of binary software package is that it is simple and easy to install, but the disadvantage is the lack of flexibility. The corresponding software package is installed on the corresponding platform, and the software cannot run without this environment.

Binary packages provide many types of packaging, the most common of which are packages in RPM format we mentioned in the previous section, as well as binary packages in the form of "* .tar.gz, * .tgz, * .bz2", and finally, a binary package that provides an installer for installation. The following are described separately:

3.1 install the "* .tar.gz, * .bz2" binary package

This format of the software package, installation is actually a simple decompression process, according to different software packaging format, we can use the corresponding decompression command to decompress.

For * .tar.gz software format decompression: tar-zxvf xxxxxx.tar.gz for * .bz2 software format: uninstall software such as tar-jxvf xxxxxx.tar.gz. For software with only a single directory after decompression, you can directly delete the corresponding software directory. If the extracted files are scattered in several directories, you need to delete the directory manually.

For example, our commonly used application server container tomcat software is released based on this packaged and compressed format. We just need to download and decompress to complete the installation. If we need to uninstall it, we can delete the corresponding tomcat directory directly.

3.2 provide software packages for the installer

This kind of software package all provides the installation script or the installation wizard program, just unpack after downloading such software package, then enter the installation directory, find the executable file like setup, install, install.sh and so on to run, then according to the prompt (such as installation path, parameter setting, etc.) to carry on the corresponding setting, and then the installation is completed automatically.

The uninstall of this kind of software also provides the corresponding uninstall script or uninstall wizard, and the software uninstall can be completed according to the prompt.

For example: frequently used sun jdk is this kind of installation, jdk downloaded from the network is a binary executable file, first set the executable permissions of the file (such as chmod 755 jdk1.6.0_07.bin, permissions operation will be described in more detail later in this book), and then run the software (that is,. / jdk1.6.0_07.bin) to complete the installation. When the installation is complete, a corresponding jdk program directory is generated in the current directory.

At this point, I believe you have a deeper understanding of "how to understand the installation and management of software packages under Linux". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.