Summary of software installation methods in Linux (centos)

This article is excerpted from: laruence Linux Private food basic article 22nd, chapter 23; reprinted please note the Source: http://www.cnblogs.com/beanmoon/archive/2012/10/30/2746103.html

Installing and uninstalling software in Linux is a headache and does not need to be as convenient as in windows. In general, there are the following types:

1. tarball

The so-called tarball file is actually to package all the software's original code files in tar and then compress them with compression technology. The most common is to compress them with gzip. Because the tar and gzip functions are used, the general extension of the tarball file will be written as * .tar.gz or abbreviated as *. tgz! However, recently, because Bzip2 has a better compression ratio, tarball gradually replaces gzip with Bzip2 compression technology! Therefore, the file name will also be * .tar.bz2 and so on. So, tarball is a software package. After you decompress it, the files in it usually include:

• Original program code file;
• Detects program files (which may be configure or config files );
• Install or readme ).

The most important one is the install or readme files. Generally, as long as you can refer to these two files, the installation of the tarball software is very simple!

OK! The following describes how to issue the installation commands for most tarball software:

1. ./Configure
   This step is to create the MAKEFILE file! Generally, program developers will write a scripts to check your Linux system and related software attributes. This step is very important, because your installation information will be completed in this step in the future! For more information about this step, see readme or install related files in this directory!
2. Make clean
   Make reads the clean work in makefile. This step may not always exist, but you want to run it because it can remove the target file! Because no one is sure whether the source code contains the target file (*. O) that was compiled last time, it is appropriate to clear it. At least wait for the newly compiled running file to make sure it is compiled by your own machine!
3. Make
   Make will compile Based on the default work in makefile! GCC is used to compile the source code into object files that can be run. However, these object files usually require links such as libraries, to generate a complete running file! Using make is to compile the original code into a runable file that can be run, and this runable file will be placed under the current directory, has not been installed in the pre-installed directory;
4. Make install
   This is usually the final installation step. Make will install the data compiled in the previous step to the predefined directory based on the install project in the MAKEFILE file, the installation is complete.

Let's take a look at the default installation path of the Linux distribution software? Let's use the Apache Software to describe:

• /Etc/httpd
• /Usr/lib
• /Usr/bin
• /Usr/share/man

We will find that the software content is generally placed in the ETC, Lib, bin, man and other directories, representing the "configuration file, correspondence library, running file, online instruction file" respectively 』. Well, what if you install it with a tarball? If it is placed inDefault/usr/localBecause/usr/local is the default directory, your data will be placed in:

• /Usr/local/etc
• /Usr/local/bin
• /Usr/local/lib
• /Usr/local/man

However, if you choose to install each software in this default path, all the software files will be placed in these four directories. Therefore, if you are installed in this directory, it will be difficult to trace the source of the file if you want to upgrade or remove it in the future! If you select a separate directory during installation, for example, install Apache in/usr/local/Apache (you can set it in this way:./configure-- Prefix=/Usr/local/Apche -- enable-all-clocks -- enable-Parse-clocks), then your file directory will become:

• /Usr/local/Apache/etc
• /Usr/local/Apache/bin
• /Usr/local/Apache/lib
• /Usr/local/Apache/man

Haha! The files of a single software are all under the same directory, so it is much easier to remove the software! The software has been removed as long as the directory is removed! For example, if you want to remove Apache, you only need to release "RM-RF/usr/local/Apache" to remove the software! Of course, during actual installation, you still have to check the install information in the makefile of the software to find out what the installation is. For example, installing Sendmail is troublesome ......

Although this method is advantageous for Software Removal, I wonder if you have found that when running some commands, it is related to whether the command is recorded in the PATH environment variable, for example, my/usr/local/Apache/bin is definitely not in the path, so the absolute path must be used to run Apache commands, otherwise, add this/usr/local/Apache/bin to the path. In addition, the/usr/local/Apache/man must be added to the man page search path!

In addition, tarball is also quite troublesome during the upgrade. How can this problem be solved? We can still explain it with Apache. For the sake of interaction, the WWW server usually installs PHP + MySQL + Apache together. Suppose I only need to Upgrade PHP today? Sometimes, I only need to Upgrade PHP because it only involves updates to the dynamic library! Other parts may have little impact. However, if PHP needs to re-compile many modules today, it may be associated. Even the Apache program needs to be re-compiled! It really gave him a headache! No way! Using tarball does have some advantages, but in this respect, he does have a certain degree of headache.

Finally, the tarball software cannot perform software correlation check during installation, which may make the installed software unavailable.

Because tarball has these features during upgrade and installation, that is, it is difficult for tarball to perform reverse installation (if you do not plan well ~), Therefore, for the convenience of tarball management, we recommend that you:

1. It is best to extract the original tarball data to/usr/local/src;
2. During installation, it is best to install the software in the default path/usr/local. considering future anti-installation steps, it is best to install each software separately under/usr/local;
3. Add man path search to man page of software installed in a separate directory: if the software you installed is stored in/usr/local/software/, then man page searches for configuration, it may have to be in/etc/man. 40 ~ in config ~ At around 50 lines, write the following line: "manpath/usr/local/software/man". In this way, man can be used to query online files of the software! Of course, add the/usr/local/software/bin directory to the command search path.

Note: software installed using the tarball method cannot be managed through rpm. For example, rpm-Q software_name cannot query files that have been installed using the tarball.

2. rpm and dpkg

Due to the vigorous development of free software and the powerful performance of large Unix-like hosts, many software developers can release their software using tarball. Later, after the development of Linux, some enterprises or communities collected the software and made it into distributions to release this useful Linux operating system. But later I found that the software management of these distribution is really a headache. If the software has vulnerabilities, How can I fix them? Is it managed using the tarball method? I often don't know what programs have we installed? Therefore, some communities and enterprises begin to think about Linux software management methods.

Therefore, the Linux developer first compiles the software to be installed or upgraded on the fixed hardware platform and operating system platform, then, all related files of the software are packaged into a special file, which also contains scripts for pre-detecting systems and dependent software, it also provides information on all documents provided by the software. Finally, release the software file. After obtaining the file, the client only needs to install the file by using specific commands. Then, the software file will detect the existence of dependent precursor software based on internal scripts. If the installed Environment meets the requirements, then the installation will begin. After the installation is complete, the information of the software will be written into the software management mechanism, so that the software can be upgraded or removed in the future.

Currently, the most common installation methods for Linux software are:

• Dpkg:
  This mechanism was first developed by the Debian Linux community. Through the dpkg mechanism, the software provided by Debian can be simply installed and the installed software information can be provided, very good. Most Linux distributions derived from Debian use dpkg to manage software, including b2d and ubuntu.

• Rpm:
  This mechanism was first developed by Red Hat and was very useful later. Therefore, many distributions use this mechanism as a management method for software installation. Well-known developers, including fedora, centos, and Suse, all use this plug-in.

As mentioned above, no matter whether dpkg/RPM or not, these mechanisms will have software property dependency problems. How can this problem be solved? In fact, I have mentioned that each software file has a dependency attribute check? Then, if we make the data of dependency attributes into a list, when the actual software is installed, if there is a dependency attribute of the software, for example, to install a, we need to first install B and c, when installing B, you need to install D and E. When you want to install a, you can use the dependency attribute list and management mechanism to automatically obtain B, C, D, and E for simultaneous installation, does it solve the issue of dependency between attributes?

That's right! At present, new Linux developers have provided such an "online upgrade" mechanism. Through this mechanism, the original CD is only required for the first installation. Other times, as long as there is a network, you will be able to obtain any software provided by the original developer! On the dpkg management mechanism, the online upgrade mechanism of APT is developed. RPM has the Yum and YaST online update (you) of the Red Hat system, depending on the developer ), the urpmi software of mandriva.

Distribution representative	Software Management Mechanism	Use commands	Online upgrade mechanism (command)
Red Hat/Fedora	Rpm	Rpm, rpmbuild	Yum (YUM)
Debian/Ubuntu	Dpkg	Dpkg	APT (APT-Get)

Here we take the centos system as an example. The software management mechanism used is the RPM mechanism, and the online upgrade method is yum! Let's talk about rpm and yum!

2.1 What is rpm and srpm?

The RPM full name is "RedHat Package Manager! As the name suggests, the software management mechanism was developed by red hat. Rpm is a management mechanism for installing the software you need to your Linux system in a database record manner.

Since the RPM file is packaged data, that is to say, all the data in the file has been compiled! Therefore, the software file can only be installed in the original default hardware and operating system version. That is to say, your host system environment must be the same as the host environment where the software file was originally created! For example, the RP-pppoe ADSL dial-up software must be installed in the environment where the PPP software exists! If your host does not have the PPP software, I'm sorry, unless you install PPP first, RP-pppoe won't let you install it (of course you can force installation, however, a problem usually occurs !). Therefore, the RPM files released by different distributions cannot be used in other distributions. For example, an RPM file released by Red Hat cannot be directly installed on SuSE. Furthermore, different versions of the same distribution cannot communicate with each other. For example, RPM files of centos 4.x cannot be directly applied to centos 5.x! Therefore, the problems with these software management mechanisms can be discovered:

1. The environment for installing software files must be consistent with or equal to the environment requirements during packaging;
2. The dependency attribute requirements of software must be met;
3. Be especially careful when installing the anti-Installation tool. The bottom-layer software cannot be removed first, otherwise it may cause problems in the entire system!

What should we do? If I really want to install the good RPM software files provided by other distributions? Haha! Okay, there's srpm! What is srpm? As the name suggests, it means that the source RPM file contains the original code! Note that the software content provided by this srpm is not compiled, and the original code is provided!

Generally, the srpm extension is named in the format of ***. SRC. rpm. However, since srpm provides the original code, why don't we use the tarball to directly install it? This is because although the srpm content is the original code, it still contains the dependency software description required by the software and the data provided by all RPM files. In addition, unlike rpm, it also provides parameter configuration files (configure and makefile ). Therefore, if we download srpm, you must:

• First, compile the software in RPM management mode. At this time, srpm will be compiled into an RPM file;
• Then install the compiled RPM file to the Linux system.

No, why is srpm so troublesome! We need to re-compile it once, so we just need to use rpm for installation? When a software is released, the RPM and srpm of the software are released simultaneously. We now know that RPM files must be installed in the same Linux environment. Since srpm is in the format of the original code, we can modify the parameter configuration file in srpm, then re-compile and generate an RPM file that is suitable for our Linux environment. As a result, we can not install the software in our system, instead of having to be the same as the Linux environment packaged by the original author? This is the use of srpm!

File Format	File Name format	Directly installed or not	Embedded program type	Can I modify parameters and compile them?
Rpm	Xxx. rpm	Yes	Compiled	Not Allowed
Srpm	Xxx. SRC. rpm	Not Allowed	Uncompiled original code	Yes

TIPS: Why is centos the Enterprise Edition of community maintenance? After RHEL of Red Hat is released, srpm is released. Community friends will collect these srpm and re-compile it into the required software, and then re-release it into centos, so they can claim to be synchronized with Red Hat RHEL Enterprise Edition! Thanks to srpm! If you want to understand how centos compiles a program, you can also learn the compilation parameters contained in srpm!

 

Since rpm is installed after being pre-compiled and packaged into an RPM file format, it can also be recorded in the database. Therefore, RPM has the following advantages:

• Rpm contains compiled programs, configuration files, and other data, which frees users from re-compilation;
• Before rpm is installed, it checks the hard disk capacity and operating system version of the system to avoid incorrect installation of files;
• The RPM file provides the software version information, dependency attribute software name, software usage instructions, software documents, and other information for the software to understand the software;
• The RPM management method uses the database to record relevant parameters of the RPM file, so as to upgrade, remove, query, and verify the file.

2.2 how to overcome dependency of RPM attributes: Yum online upgrade

To reuse existing software functions, many software releases some functions in the form of a function library to facilitate call applications of other software, such as the PAM module verification function. In addition, in order to save the user's data volume, the current distributions releases the software into two categories: general use and development use. So you will often see a file like pam-x.x.rpm and pam-devel-x.x.rpm name ah! By default, most of the software-devel-x.x.rpm will not install, because most of the end users will not go to the development of software well!

Due to the above phenomenon, RPM software files will have the so-called property dependency problem (in fact, almost all software management has this situation ). Is there a solution? Didn't I mention that the RPM software file records the dependent attribute data internally? Let's think about it. If I first list the software with dependency attributes and find the software to be installed first, and compare it with the software installed in the system, if dependency software is not installed, it will be installed at the same time. Isn't the dependency attribute solved? Is there such a mechanism? Yes! That is why the yum mechanism is created!

Centos first places the released software on the yum server, analyzes the dependency attribute of the software, and writes down the record information in the software (header ). The information is then analyzed and recorded as a list of software dependencies. The location of the List data and software can be called a container ). When the client needs to install software, the client host will actively download the list from the container URL of the yum server on the network, then, by comparing the list data with the existing software data in the local RPM database, you can install all required software with dependency attributes in one breath. The entire process can be described as follows:

Figure 1.5.1 process used by yum

When the user side needs to upgrade and install the configuration, yum will upgrade the configuration to the container. After the configuration is upgraded to the local/var/Cache/yum, during the upgrade, the local configuration will be compared with the local RPM database, so that you can know what software to download. Next, yum will run to the container server (YUM server) to download the required software, and then install the software through the RPM mechanism! This is the entire process!

3. Management Options: rpm or tarball

This has always been an interesting question: "If I want to upgrade or install a new software, should I choose RPM or tarball for installation ?』, In fact, there are many factors to consider, but laruence usually suggests this:

1. First select the original RPM function:
   Software released by the original manufacturer usually has a maintenance period of time. For example, each version of RHEL and centos provides a upgrade period of at least five years. This is a very good option for our system security! Why? Since Yum can be automatically upgraded and the original manufacturer will continue to maintain the software upgrade, our system will be able to keep the software up to date. Of course, it will be better for zi'an! In addition, rpm and Yum features easy installation, removal, and upgrade, as well as query and verification functions, providing digital seal protection during installation, make your software management easier! Therefore, the first choice is to use rpm for processing!

2. Select the RPM released on the official software website or the container website:
   However, the original manufacturer does not cover the sea of Shan Bao, so some special software your original manufacturer will not provide! For example, centos does not provide NTFS-related modules. At this time, you can go to the official website to check whether the RPM file relative to your system is provided. If there is a container URL, it is better! You can modify the yum configuration file to add the container to automatically install and upgrade the software! It's inconvenient for you!
3. Use tarball to install special software:
   Some special-purpose software will not help you to create RPM files. At this time, we recommend that you do not want to create srpm on your own to convert it into RPM! Because you only have one host in the zone. If you want to manage the same 100 hosts, it is valuable to convert the original code into RPM! Standalone edition of special software, such as the mpich/PVM parallel operation library commonly used by academic networks, this software is recommended to use tarball for installation, do not need to search for RPM!
4. Use tarball to test the new software version:
   You may need to use a new version of software at some time, but the original manufacturer only provides the old version of software. For example, our centos is mainly positioned on the Enterprise Edition, therefore, a lot of software requires "stability" rather than "new", but you just need new software! Then I was worried about problems after the new software was installed. If I couldn't return to the old software, it would be terrible! Now you can use tarball to install the new software under/usr/local, so that the software can install two versions on the system at the same time! In addition, the majority of software installation versions do not interfere with each other! Hey! It's good to use it as a new software test! You just need to know whether the command you are using is a new version of software or an old version of software!

Therefore, rpm and tarball have their own advantages and disadvantages. However, if rpm is available, the priority is still on RPM installation. After all, the management is convenient, but if the architecture of the software is too different, or it cannot solve the dependency Attribute Problem. Instead of spending a lot of time and energy on solving the dependency problem, it is better to install it directly with the tarball, Which is easy and comfortable!