Quick HOWTO : Ch06 : Installing Linux Software
You'll frequently need to install additional software on your Linux server that you didn't think you'd need when you first installed the operating system. This could be because of new business requirements for additional packages or the need to install new administrative tools to make your job easier.
When Linux developers create their software they typically bundle all the executable and data files into a single file that is often called a "package" file. Package files have different formats and contain different control files that determine where the rest of the files should be placed, the permissions they should have and a list of prerequisite packages that are required for the package to function correctly. Some of this information may also be stored in a database on your system by the package management software used to install the software and is used to speed up some of the administrative functions of the package manager.
Redhat, Centos and Fedora Linux software is primarily available in RedHat Package Manager (RPM) files. Regular RPM package files are used for installations in which the kernel, or master program, hasn't been customized in any way. This is the usual scenario for most departmental servers. Source RPMs are used when the kernel has been customized to add or drop support selectively for various devices or features for the sake of performance or functionality. The procedure for installing source RPMs involves recompiling source code to fit the needs of these kernel customizations. This makes life easier for the software developer who wrote the package as he or she now has only to create a single package to support all types of customizations. Both package types use standardized commands for installing the software contained inside making RPMs relatively easy to use.
Debian and Ubuntu versions of Linux use the Debian Package format in which the filenames all end with ".deb". It is for this reason that they are frequently called DEB files.
Software developers who want to use a universally recognizable file format across all flavors of Linux also will make their products available as TAR packages. TAR packages are generally more difficult to work with than RPM packages because the archived files within them may or may not need to be compiled and the commands to install the software may vary from package to package. Instructions are usually contained within a file inside the TAR package to help guide the installation.
The Perl programming language is often used by Linux software developers to create their programs. Perl relies on the presence of certain libraries, or "modules", to work correctly and many Linux distributions install Perl with only the most commonly used ones. There will be times when you will be required to install additional prerequisite Perl modules prior to the installation of your packages. Knowledge of how to install Perl modules is a valuable component of a Linux systems administrators' skill set.
This chapter focuses on the RPM and DEB formats, which are used by a majority of installed distributions. There are smaller sections on TAR packages and Perl modules near the end to cover these less frequently used, but important software installation tools.
Where to Get Commonly Used Packages
There are three commonly used sources for packages; distribution CDs; packages manually downloaded via a browser, File Transfer Protocol (FTP) client, or the wget utility; and automated downloads. Each of these methods is introduced here, but is covered in greater detail in sections to follow.
Packages on Your Installation CDs
Installing from your distribution CDs is usually easier than having to download files from a remote Web site, but they are never up to date for very long. We discuss using this method in more detail later.
Manually Downloaded Packages
The two most common ways of getting packages are by manually using FTP or a Web browser. Table 6-1 lists some common download sites that can be used. Remember to match the RPM to the distribution and version of Linux your system is running.
Table 6-1 Popular Package Download Sites
Note: With Fedora you can also download packages from the download.fedora.redhat.com site. Start your search in the /pub/fedora/linux/core/ directory and move down the directory tree. If you're new to FTP, don't worry, it's explained later.
Automated Package Download
The disadvantage of manual downloads is that the packages often won't install unless certain prerequisite packages have been installed beforehand. This can lead to the download and installation of several packages which can become tedious.
All the major Linux distributions have automated download and update utilities. For example, Fedora uses yum and Ubuntu and Debian use apt. These are all covered in greater detail in sections to follow.
How to Download Software
One of the most universally performed tasks by Linux systems administrators is the downloading of software. It is usually very simple to do and the most commonly used methods are covered in this section.
Getting Software Using Web-Based FTP
There are numerous Web sites that provide links to software you can download. The methodology to get the software is usually the same for all:
- Browse the desired Web site until you find the link to the software package you need.
- Click on the link for the desired software package.
- Save the file to your hard drive
Some web browsers, such as Firefox, will automatically download the file to your desktop, but where is the desktop? In Linux, your desktop is usually a sub-directory named Desktop located in your home or ~ directory. Here we see that the root user's desktop already contains a downloaded RPM file.
[root@bigboy tmp]# cd ~/Desktop/ [root@bigboy Desktop]# ls ElectricFence-2.2.2-20.2.i386.rpm [root@bigboy Desktop]# pwd /root/Desktop [root@bigboy Desktop]#
Getting RPMs Using Command-Line Anonymous FTP
The Web based method above transparently uses anonymous File Transfer Protocol (FTP). Anonymous FTP allows you to log in and download files from a FTP server using the username anonymous or the shorter username ftp and a password that matches your e-mail address. This way anyone can access the data. Let's illustrate this with an example of using anonymous FTP to download the SSH package from download.fedora.redhat.com:
1) First we issue the FTP command targeting download.fedora.redhat.com at the command line.
[root@bigboy tmp]# ftp download.fedora.redhat.com Trying 184.108.40.206... Connected to download.fedora.redhat.com (220.127.116.11). 220 Fedora FTP server ready. All transfers are logged. Name (download.fedora.redhat.com:root): anonymous 331 Please specify the password. Password: 230 Login successful. Have fun. Using binary mode to transfer files. ftp> pwd 257 "/" ftp> ls 227 Entering Passive Mode (66,187,232,35,57,155) 150 Here comes the directory listing. drwxr-xr-x 3 ftp ftp 4096 Oct 29 15:59 pub 226 Directory send OK. ftp>
2) After we've logged in, we can use the help command to see what options we have at our disposal.
ftp> help Commands may be abbreviated. Commands are: ! cr mdir proxy send $ delete mget sendport site account debug mkdir put size append dir mls pwd status ascii disconnect mode quit struct bell form modtime quote system binary get mput recv sunique bye glob newer reget tenex case hash nmap rstatus trace ccc help nlist rhelp type cd idle ntrans rename user cdup image open reset umask chmod lcd passive restart verbose clear ls private rmdir ? close macdef prompt runique cprotect mdelete protect safe ftp>
The commands you'll most likely use are listed in Table 6-2:
Table 6-2 FTP Commands
|binary||Copy files in binary mode|
|cd||Change directory on the FTP server|
|dir||List the names of the files in the current remote directory|
|get||Get a file from the FTP server|
|lcd||Change the directory on the local machine|
|ls||Same as dir|
|mget||Same as get, but you can use wildcards like "*"|
|mput||Same as put, but you can use wildcards like "*"|
|passive||Make the file transfer passive mode|
|put||Put a file from the local machine onto the FTP server|
|pwd||Give the directory name on the local machine|
3) By using the Web browsing feature on the Web site ahead of time, I know that the Fedora Core 2 RPMs are located in the pub/fedora/linux/core/2/i386/os/Fedora/RPMS/ directory and will use the cd command to change my directory to there. We can use the ls command to get a listing of files in this directory.
ftp> cd pub/fedora/linux/core/2/i386/os/Fedora/RPMS/ 250 Directory successfully changed. ftp> ls open* 227 Entering Passive Mode (66,187,232,35,58,3) 150 Here comes the directory listing. ... ... -rw-r--r-- ... ... 184281 Oct 28 23:29 openssh-3.6.1p2-34.i386.rpm ... ... 226 Directory send OK. ftp>
4) Next we get the file we need and place it in the local directory /usr/rpm. The hash command will print "#" hash signs on the screen during the download.
ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> lcd /usr/rpm Local directory now /usr/rpm ftp> get openssh-3.6.1p2-34.i386.rpm local: openssh-3.6.1p2-34.i386.rpm remote: openssh-3.6.1p2-34.i386.rpm 227 Entering Passive Mode (66,187,232,35,58,25) 150 Opening BINARY mode data connection for openssh-3.6.1p2-34.i386.rpm (184281 bytes). ################################################################################################################################################################################### 226 File send OK. 184281 bytes received in 3.41 secs (53 Kbytes/sec) ftp>
Note: You can also use wildcards to download the RPMs you need using the mget command. You'll be prompted for each of the matching RPM files. In the next example, we just aborted this download by typing n.
ftp> mget openssh-3.6* mget openssh-3.6.1p2-34.i386.rpm? n ftp>
5) Finally we use the exit command to leave FTP.
ftp> exit 221 Goodbye. root@bigboy tmp]#
Getting Software Using wget
The wget command can be used to download files quickly when you already know the URL at which the RPM is located. This is especially convenient if you are logged into your Linux box from another machine running a Web browser. You can browse the download site for the RPM you need, right click on the desired link and select copy shortcut (Windows) or Copy Link Location (Linux). After you have done this, you can then select your SSH/telnet/Linux Terminal login window and type in the command wget URL. Here is an example downloading a DHCP update from Fedora.
[root@bigboy tmp]# wget http://linux.stanford.edu/pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS/dhcp-3.0pl2-6.16.i386.rpm --17:38:36-- ftp://linux.stanford.edu/pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS/dhcp-3.0pl2-6.16.i386.rpm => `dhcp-3.0pl2-6.16.i386.rpm.5' Resolving linux.stanford.edu... done. Connecting to linux.stanford.edu[18.104.22.168]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS ... done. ==> PASV ... done. ==> RETR dhcp-3.0pl2-6.16.i386.rpm ... done. Length: 529,890 (unauthoritative) 100%[===============================>] 529,890 889.12K/s ETA 00:00 17:38:36 (889.12 KB/s) - `dhcp-3.0pl2-6.16.i386.rpm.5' saved  [root@bigboy tmp]#
Installing Software From RPM Files
The Fedora, Redhat and Centos versions of Linux rely heavily upon the use of software packages in the RPM format. This section covers some of the most important topics required for you to master their use.
How To Install RPMs Manually
There are generally two ways to install RPM files manually. The first method is by using a file previously downloaded to your hard drive, and the other is to install the RPM from some sort of removable media such as a CD-ROM drive.
Using Downloaded Files
Download the RPMs (which usually have a file extension ending with .rpm) into a temporary directory, such as /tmp. The next step is to issue the rpm -Uvh command to install the package.
The -U qualifier is used for updating an RPM to the latest version, the -h qualifier gives a list of hash # characters during the installation and the -v qualifier prints verbose status messages while the command is run. Here is an example of a typical RPM installation command to install the MySQL server package:
[root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm Preparing... ####################### [100%] 1:mysql-server ####################### [100%] [root@bigboy tmp]#
Using CD-ROMs or DVDs
The underlying steps to install RPMs from CDs are similar to those used when installing from your hard disk. The main difference is that you have to access your CD-ROM drive by mounting it first to the mnt/cdrom directory. Your RPMs will then be located in the CD-ROM's Fedora/RPMs subdirectory. The procedure is as follows:
1) Insert the CD-ROM, check the files in the /mnt/cdrom/Fedora/RPMS directory and then install the RPM.
[root@bigboy tmp]# mount /mnt/cdrom [root@bigboy tmp]# cd /mnt/cdrom/Fedora/RPMS [root@bigboy RPMS]# ls filename* filename.rpm [root@bigboy RPMS]# rpm -Uvh filename.rpm Preparing... ####################### [100%] 1: filename ####################### [100%] [root@bigboy RPMS]#
2) When finished, eject the CD-ROM
[root@bigboy RPMS]# cd /tmp [root@bigboy tmp]# eject cdrom [root@bigboy tmp]#
Note: You can use the rpm command's --aid switch to make it search the CD-ROM for any other RPM dependencies and install them automatically.
Using ISO Files
The underlying steps to install RPMs from ISO files are similar to those used when installing from your hard disk. The main difference is that you have to access your ISO file by mounting it first to the /mnt directory. Your RPMs will then be located in the ISO file's Fedora/RPMs subdirectory. The procedure is as follows:
1) Let's assume you have downloaded the ISO file to the /tmp directory. Mount the file, check the files in the /mnt/Fedora/RPMS directory and then install the RPM.
[root@bigboy tmp]# mount -o loop -t iso9660 file.iso /mnt [root@bigboy tmp]# cd /mnt/Fedora/RPMS [root@bigboy RPMS]# ls filename* filename.rpm [root@bigboy RPMS]# rpm -Uvh filename.rpm Preparing... ####################### [100%] 1: filename ####################### [100%] [root@bigboy RPMS]#
2) When finished, unmount the ISO file
[root@bigboy RPMS]# cd /tmp [root@bigboy tmp]# umount /mnt [root@bigboy tmp]#
Note: You can use the rpm command's --aid switch to make it search the ISO for any other RPM dependencies and install them automatically.
How to Install Source RPMs
Sometimes the packages you want to install need to be compiled in order to match your kernel version. This requires you to use source RPM files:
- Download the source RPMs or locate them on your CD collection. They usually have a file extension ending with (.src.rpm)
- Run the following commands as root:
Compiling and installing source RPMs with Fedora can be done simply with the rpmbuild command
[root@bigboy tmp]# rpmbuild --rebuild filename.src.rpm
Here is an example in which we install the tacacs plus package.
[root@bigboy rpm]# rpmbuild --rebuild tac_plus-4.0.3-2.src.rpm Installing tac_plus-4.0.3-2.src.rpm Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.61594 + umask 022 + cd /usr/src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf tac_plus-4.0.3 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/tac_plus-4.0.3.tgz + tar -xvvf - ... ... ... + umask 022 + cd /usr/src/redhat/BUILD + rm -rf tac_plus-4.0.3 + exit 0 [root@bigboy rpm]#
The compiled RPM file can now be found in one of the architecture subdirectories under /usr/src/redhat/RPMS directory. For example, if you compiled an i386 architecture version of the RPM it will placed in the i386 subdirectory.
You will then have to install the compiled RPMs found in their respective subdirectories as you normally would.
RPM Installation Errors
Sometimes the installation of RPM software doesn't go according to plan and you need to take corrective actions. This section shows you how to recover from some of the most common errors you'll encounter.
Sometimes RPM installations will fail giving Failed dependencies errors which really mean that a prerequisite RPM needs to be installed. In the next example we're attempting to install the MySQL database server application, which fails because the mysql MySQL client RPM, on which it depends, needs to be installed beforehand:
[root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm error: Failed dependencies: libmysqlclient.so.10 is needed by mysql-server-3.23.58-9 mysql = 3.23.58 is needed by mysql-server-3.23.58-9 [root@bigboy tmp]#
Installing the MySQL client also fails because it requires the perl-DBD-MySQL package.
[root@bigboy tmp]# rpm -Uvh mysql-3.23.58-9.i386.rpm error: Failed dependencies: perl-DBD-MySQL is needed by mysql-3.23.58-9 [root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm error: Failed dependencies: libmysqlclient.so.10 is needed by perl-DBD-MySQL-2.9003-4 [root@bigboy tmp]#
Strangely enough, the installation of the perl-DBD-MySQL package fails because it needs the mysql client package. To get around this problem you can run the rpm command with the --nodeps option to disable dependency checks. In the next example we install the MySQL client ignoring dependencies, followed by successful installation of perl-DBD-MySQL and mysql-server.
[root@bigboy tmp]# rpm -Uvh --nodeps mysql-3.23.58-9.i386.rpm Preparing... ####################### [100%] 1:mysql ####################### [100%] [root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm Preparing... ####################### [100%] 1:perl-DBD-MySQL ####################### [100%] [root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm Preparing... ####################### [100%] 1:mysql-server ####################### [100%] [root@bigboy tmp]#
Note: If all the installation RPMs are located in the same directory, the rpm command can automatically install all the prerequisite RPMs using the --aid option. One of the advantages of using the yum facility is that you don't have to worry about this dependency process as much because the dependency RPMs are always downloaded and installed automatically also.
Fedora digitally signs all its RPM files, so it's best to import their public encryption key beforehand so that the RPM installation program will be able to verify the validity of the RPM file.
This is usually done automatically in newer versions of Fedora, but will need to be done manually in legacy versions. The manual method uses the rpm command as seen in the next example, but locate the key files first as their locations can vary between Fedora distributions. It is a good idea to import both the RedHat and Fedora keys:
[root@bigboy tmp]# locate RPM-GPG-KEY /usr/share/rhn/RPM-GPG-KEY /usr/share/rhn/RPM-GPG-KEY-fedora [root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY [root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora [root@bigboy tmp]#
If you don't install the keys you'll get a DSA signature warning that alerts you to the fact that the RPM file might be bogus:
[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm warning: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2 Preparing... #################################### [100%] 1:dhcp #################################### [100%] [root@bigboy tmp]#
It is always good to install the key files. If they are not there, the RPMs will install with only a warning message. If the RPM's digital signature doesn't match that in the key file, the rpm installation program also alerts you and fails to install the RPM package at all:
[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm error: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: BAD, key ID 4f2a6fd2 error: dhcp-3.0pl2-6.16.i386.rpm cannot be installed [root@bigboy tmp]#
Signatures are therefore useful because they help protect you against tampered and otherwise corrupted RPMs being installed.
How to List Installed RPMs
The rpm -qa command will list all the packages installed on your system
[root@bigboy tmp]# rpm -qa perl-Storable-1.0.14-15 smpeg-gtv-0.4.4-9 e2fsprogs-1.27-9 libstdc++-3.2-7 audiofile-0.2.3-3 ... ... ... [root@bigboy tmp]#
You can also pipe the output of this command through the grep command if you are interested in only a specific package. In this example we are looking for all packages containing the string ssh in the name, regardless of case (-i means ignore case)
[root@bigboy tmp]# rpm -qa | grep -i ssh openssh-server-3.4p1-2 openssh-clients-3.4p1-2 openssh-askpass-gnome-3.4p1-2 openssh-3.4p1-2 openssh-askpass-3.4p1-2 [root@bigboy tmp]#
Note: You could use the rpm -q package-name command to find an installed package because it is much faster than using grep and the -qa switch, but you have to have an exact package match. If you are not sure of the package name and its capitalization, the latter method is probably more suitable.
Listing Files Associated with RPMs
Sometimes you'll find yourself installing software that terminates with an error requesting the presence of a particular file. In many cases the installation program doesn't state the RPM package in which the file can be found. It is therefore important to be able to determine the origin of certain files, by listing the contents for RPMs in which you suspect the files might reside.
Listing Files for Already Installed RPMs
This can be useful if you have to duplicate a working server that is already in a production environment. Sometimes the installation of an application fails on the new server due to the lack of a file that resides on the old one. In this case you need to know which RPM on the old server contains the file.
You can use the -ql qualifier to list all the files associated with an installed RPM. In this example we test to make sure that the NTP package is installed using the -q qualifier, and then we use the -ql qualifier to get the file listing.
[root@bigboy tmp]# rpm -q ntp ntp-4.1.2-0.rc1.2 [root@bigboy tmp]# rpm -ql ntp /etc/ntp /etc/ntp.conf /etc/ntp/drift /etc/ntp/keys ... ... ... /usr/share/doc/ntp-4.1.2/rdebug.htm /usr/share/doc/ntp-4.1.2/refclock.htm /usr/share/doc/ntp-4.1.2/release.htm /usr/share/doc/ntp-4.1.2/tickadj.htm [root@bigboy tmp]#
Listing Files in RPM Files
Sometimes you make a guess and download what you think is the RPM with the missing file. You can use the -qpl qualifier to list all the files in an RPM archive to make sure before installing it:
[root@bigboy updates]# rpm -qpl dhcp-3.0pl1-23.i386.rpm /etc/rc.d/init.d/dhcpd /etc/rc.d/init.d/dhcrelay /etc/sysconfig/dhcpd /etc/sysconfig/dhcrelay ... ... ... /usr/share/man/man8/dhcrelay.8.gz /var/lib/dhcp /var/lib/dhcp/dhcpd.leases [root@bigboy updates]#
Listing the RPM to Which a File Belongs
You might need to know the RPM that was used to install a particular file. This is useful when you have a suspicion about the function of a file but are not entirely sure. For example, the MySQL RPM uses the /etc/my.cnf file as its configuration file, not a file named /etc/mysql.conf as you'd normally expect. The following example confirms the origin of the /etc/my.cnf file.
[root@zippy tmp]# rpm -qf /etc/my.cnf mysql-3.23.58-9 [root@zippy tmp]#
The rpm -e command will erase an installed package. The package name given must match that listed in the rpm -qa command because the version of the package is important.
[root@bigboy tmp]# rpm -e package-name
Which RPMs Will Start Up At Boot Time?
The best way to view and configure which RPMs will start at boot time is by using the chkconfig command with the --list switch. A more detailed explanation will be provided later in this chapter.
Automatic Updates with yum
The yum automatic RPM update program comes as a standard feature of Fedora Core. It has a number of valuable features:
- You can configure the URLs of download sites containing the RPM repositories you need. This provides the added advantage of you choosing the most reliable sites in your part of the globe.
- yum makes multiple attempts to download RPMs before failing.
- yum automatically figures out not only the RPMs packages that need updating, but also all the supporting RPMs. It then installs them all.
Note: Updating packages could cause programs written by you to stop functioning especially if they rely on the older version's features or syntax.
The configuration parameters that affect all packages and all yum server URLs are stored in the [main] section of the /etc/yum.conf file. You generally don't need to edit this file, but it can be useful in listing packages that you don't want yum to update.
# # File: /etc/yum.conf # [main] exclude=kernel perl
In this example the kernel and perl packages are excluded.
Configuring /etc/yum.repos.d Repository Files
The /etc/yum.repos.d directory has files defining where yum should look on the Internet to find the latest Linux updates. For most common tasks you won’t need to modify these files at all. If you want to know how these files affect your system, then continue reading! The configurations for each RPM repository are located in individual configuration files with the .repo file extension. This directory will be populated with files for your Linux distribution's most important repositories. You can also add your own custom files for repositories containing non-standard RPM packages. These files will have the following format:
[repositoryid] name=Some name for this repository baseurl=url://path/to/repository/
The [repositoryid] is an identifier that is unique to all files in the directory and can only be one word long and is often given a name that reflects the function of the repository. For example, you may have a fedora-updates.repo file that contains a [updates], and [updates-source] sections that refer to URLs for updates of regular RPMs and source RPMs. You can create your own repository files using popular repository sites. The easiest way to determine the exact URLs to use as the baseurl parameter is to go to the http://fedora.redhat.com/download/mirrors.html Web site to get a listing of alternative download sites. Browse the listed sites to find the correct locations of the RPM files in the /updates or /fedora-version URL branches. Make sure that baseurl points to a URL with a /repodata sub-directory beneath it as this sub-directory contains files with instructions for yum to use in doing its updates. Be careful, this sub-directory can be located within the RPM directory or one level above them. Also remember to make the [repositoryid] in your .repo file unique to all other files.
Note: yum accepts the use of variables in the configuration file. The $releasever variable refers to the current version of Fedora Core running on your server and the $basearch variable maps to the base architecture of your server which is determined automatically. Here is an example of the use of these variables.
[repository-name] name=Fedora Core $releasever - $basearch - Base baseurl=http://url.com/fedora/core/$releasever/$basearch/os/
Note: It is probably best to select yum update sites that use HTTP instead of FTP. There are a number of reasons for this. FTP firewall rules are more difficult to implement than HTTP, outbound HTTP access to the Internet is often already allowed in offices, and web servers are less likely to have connection limits imposed on them, unlike FTP servers, which often have limits on the number of user logins. Note: You can list multiple URLs in a baseurl statement like this and yum will try them all. If you use multiple baseurl statements in each section then yum may act strangely, frequently only selecting the last one in the list.
baseurl=url://server1/path/to/files/ url://server2/path/to/files/ url://server3/path/to/files/
Note: You can also place all your [repositoryid] sections in the yum.conf file. This was the methodology used in some older versions of yum.
Note: The yum utility can be configured to match the downloaded RPMs against checksum files to help protect against file corruption and malicious forgeries. This is set using the gpgcheck variable in the .repo files. Checks are done when the value is set to 1, when set to 0, they are disabled. Here is an example:
# # File: example.repo # gpgcheck=1 gpgkey=http://URL/example.key
Repositories will sometimes provide you with the URL for their checksum files and it is a good idea to take advantage of them. This is a valuable feature.
How to Automate yum
Older versions of yum could be configured to run in the background as a daemon that was simple named yum that used a unified yum.conf file for all its configuration data. Newer versions use the yum-updatesd daemon instead. This uses the /etc/yum/yum-updatesd.conf configuration file which governs update frequency, the types of files to be downloaded and whether they should be automatically installed using the yum command.
To get started with yum-updatesd follow these easy steps: 1. If using a newer version of Fedora / Redhat, make sure the yum-updatesd package is installed.
[root@bigboy tmp]# yum –y install yum-updatesd
2. Use these commands to get yum configured to start at boot:
Systems using sysvinit:
[root@bigboy tmp]# chkconfig yum-updatesd on
Systems using systemd:
[root@bigboy tmp]# systemctl enable yum-updatesd.service
3. Use the these commands to instruct the /etc/init.d yum script to start/stop yum after booting
Systems using sysvinit:
[root@bigboy tmp]# service yum-updatesd start [root@bigboy tmp]# service yum-updatesd stop
Systems using systemd:
[root@bigboy tmp]# systemctl start yum-updatesd.service [root@bigboy tmp]# systemctl stop yum-updatesd.service
Note: Updating packages could cause programs written by you to stop functioning especially if they rely on the features of an older package. The yum-updatesd daemon won't update packages unless the yum-updatesd.conf file has been updated as shown here:
# # File: /etc/yum/yum-updatesd.conf # [main] do_update = yes
The /etc/yum/yum-updatesd.conf file has many more updating options and is well documented. Read it carefully to get the results best suited to your environment.
Creating Your Own yum Server
An obvious advantage of using yum is that you can use it to update a yum server at your office with the same directory structure of the mirror download sites on the Fedora Web site. The full set of steps to do this is beyond the scope of this book, but there are some factors you should consider before doing this.
A small desktop PC with about five to six gigabytes of free disk space per distribution should be sufficient to start with for a dedicated small business yum server. Large RPMs are about twenty-five megabytes in size, and they are updated infrequently, so your network load should be minimal on average with an update once or twice a week per server. In large server farms you may want to use a more robust system that can handle many more clients, but before doing so, get trend data for its network load to help your final decision. The configuration of the MRTG graphing tool is covered in Chapter 22, " Monitoring Server Performance".
When established, you can then configure all your Fedora servers to use this local yum server for all updates which will significantly reduce your Internet congestion and the associated bandwidth costs.
yum clients can access the yum server using either FTP or HTTP requests. If you need help in setting these up, Chapter 15, "Linux FTP Server Setup", discusses Linux FTP servers and Chapter 20, "The Apache Web Server", covers the Apache Web server for HTTP requests.
Note: When setting up an HTTP based yum server, you'll need to enable the viewing of directory structures so that it will be easy for someone to use his or her Web browser to navigate down the directories to double check the location of the yum files.
How to Automate yum
As of Fedora Core 6 the
yum daemon has been named
yum-updatesd, whereas in the past it was just called
yum. To get yum started, select the commands that match your OS version:
1) Use the chkconfig command to get yum configured to start at boot:
[root@bigboy tmp]# chkconfig yum-updatesd on [root@bigboy tmp]# chkconfig yum on
2) Use the service command to instruct the
/etc/init.d yum script to start/stop yum after booting
[root@bigboy tmp]# service yum-updatesd start [root@bigboy tmp]# service yum-updatesd stop [root@bigboy tmp]# service yum start [root@bigboy tmp]# service yum stop
Keeping Your System current with Yum
You can make the installed RPM packages on your system up to date with the latest patches using the yum update command. When used without listing any packages afterwards, yum will attempt to update them all. The yum update package-name command updates only a particular RPM package.
It is always advisable to use yum after installing Linux to make sure the latest versions of software are installed for the sake of improved security and functionality. Here is an example of output of what to expect with yum updating your system.
[root@bigboy tmp]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - i386 - Base Server: Fedora Core 2 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: kernel 2.4.22-1.2166.nptl.i686] [update: samba-client 3.0.2-7.FC1.i386] [update: binutils 22.214.171.124.6-4.i386] ... ... ... Is this ok [y/N]: y Getting samba-client-3.0.2-7.FC1.i386.rpm samba-client-3.0.2-7.FC1. 100% |=========================| 128 kB 05:01 ... ... ... Running test transaction: Test transaction complete, Success! glibc-common 100 % done 1/127 glibc 100 % done 2/127 Stopping sshd:[ OK ] Starting sshd:[ OK ] bash 100 % done 3/127 mozilla-nspr 100 % done 4/127 sed 100 % done 5/127 ... ... ... Completing update for pango - 65/127 Completing update for samba-client - 66/127 Completing update for binutils - 67/127 ... ... ... Completing update for XFree86-font-utils - 127/127 Kernel Updated/Installed, checking for bootloader Grub found - making this kernel the default Installed: kernel 2.4.22-1.2166.nptl.i686 Updated: pango 1.2.5-4.i386 samba-client 3.0.2-7.FC1.i386 binutils 126.96.36.199.6-4.i386 XFree86-Mesa-libGLU 4.3.0-55.i386 initscripts [root@bigboy tmp]#
Note: If you don't want to be prompted to install the files use the yum with the -y switch.
Example of a yum Package Installation
Here is a sample installation of an individual package using yum. In this case the RPM installed is the net-snmp-utils package:
[root@bigboy tmp]# yum -y install net-snmp-utils Repository updates-released already added, not adding again Repository base already added, not adding again Setting up Install Process Setting up Repo: base repomd.xml 100% |=========================| 1.1 kB 00:00 Setting up Repo: updates-released repomd.xml 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ############################################ 2622/2622 primary.xml.gz 100% |=========================| 88 kB 00:00 MD Read : ################################################## 229/229 updates-re: ################################################## 229/229 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package net-snmp-utils.i386 0:5.1.2-11 set to be installed --> Running transaction check Dependencies Resolved Transaction Listing: Install: net-snmp-utils.i386 0:5.1.2-11 Downloading Packages: net-snmp-utils-5.1.2-11.i 100% |===================| 6.2 MB 00:48 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: net-snmp-utils 100 % done 1/1 Installed: net-snmp-utils.i386 0:5.1.2-11 Complete! [root@bigboy tmp]#
Remember The Following Yum Facts
- yum does its updates using TCP port 80 for http:// update URLs and uses passive FTP for ftp:// update URLs in /etc/yum.conf. This will have importance for your firewall rules.
- More details on configuring yum can be obtained by running the man yum.conf command.
- yum runs automatically each day. The cron file is located in /etc/cron.daily/.
- Don't limit yourself to the default yum.conf URLs because they can become overloaded with requests and make yum perform poorly.
Installing Software From DEB Files
Unlike the Redhat, Fedora and Centos versions of Linux that use RPM packages, the Debian and Ubuntu versions of Linux rely on packages in the DEB format. This section covers some of the most important topics required for you to master their use.
How To Install DEBs Manually
There are generally two ways to install DEB files manually. The first method is by using a file previously downloaded to your hard drive, and the other is to install the DEB from some sort of removable media such as a CD-ROM drive.
Using Downloaded Files
Download the DEBs (which usually have a file extension ending with .deb) into a temporary directory, such as /tmp. The next step is to issue the dpkg --install command to install the package. Here is an example of a typical DEB installation command to install the ndiswrapper utilities package:
root@u-bigboy:~# dpkg --install ndiswrapper-utils_1.8-0ubuntu2_i386.deb Selecting previously deselected package ndiswrapper-utils. (Reading database ... 70221 files and directories currently installed.) Unpacking ndiswrapper-utils (from ndiswrapper-utils_1.8-0ubuntu2_i386.deb) ... Setting up ndiswrapper-utils (1.8-0ubuntu2) ... root@u-bigboy:~#
Installing DEB files from CDROM is similar to that with Fedora / Redhat. The difference is that the CDROM device name is /media/cdrom. The following procedure installs the ndiswrapper DEB that had previously been copied to a disk.:
1. Insert the CD-ROM, check the files in the /media/cdrom directory and then install the DEB.
root@u-bigboy:/tmp# mount /media/cdrom -o unhide mount: block device /dev/hdc is write-protected, mounting read-only root@u-bigboy:/tmp# cd /media/cdrom root@u-bigboy:/media/cdrom# ls ndiswrapper-utils_1.8-ubuntu2_i386.deb root@u-bigboy:/media/cdrom# dpkg --install ndiswrapper-utils_1.8-ubuntu2_i386.deb Selecting previously deselected package ndiswrapper-utils. (Reading database ... 70221 files and directories currently installed.) Unpacking ndiswrapper-utils (from ndiswrapper-utils_1.8-0ubuntu2_i386.deb) ... Setting up ndiswrapper-utils (1.8-0ubuntu2) ... root@u-bigboy:~#
2. When finished, eject the CD-ROM
root@u-bigboy:/media/cdrom# cd /tmp root@u-bigboy:/tmp# umount /media/cdrom root@u-bigboy:/tmp# eject cdrom root@u-bigboy:/tmp#
Note: Unlike the Fedora CD / DVD sets, Ubuntu Linux is distributed on a single CD / DVD. The Ubuntu installation process downloads any additional packages it may need on demand from the Internet. It is for this reason that you may find it easier to install Ubuntu software using the APT utility which automatically download and install most of the packages you desire. The APT utility is covered in a following section.
DEB Installation Errors
Sometimes the installation of DEB software doesn't go according to plan and you need to take corrective actions. This section shows you how to recover from some of the most common errors you'll encounter.
As should be expected, packages often rely on the existence of other previously installed packages. This will sometimes result in dpkg installations failing with dependency problems errors which really mean that a prerequisite DEB needs to be installed. In the next example we're trying to install the mrtg-contrib package, but it needs the mrtg package to be installed first beforehand.
root@u-bigboy:/tmp# dpkg --install mrtg-contrib_2.12.2-1_all.deb Selecting previously deselected package mrtg-contrib. (Reading database ... 70759 files and directories currently installed.) Unpacking mrtg-contrib (from mrtg-contrib_2.12.2-1_all.deb) ... dpkg: dependency problems prevent configuration of mrtg-contrib: mrtg-contrib depends on mrtg (= 2.12.2-1); however: Package mrtg is not installed. dpkg: error processing mrtg-contrib (--install): dependency problems - leaving unconfigured Errors were encountered while processing: mrtg-contrib root@u-bigboy:/tmp#
After installing the mrtg package, mrtg-contrib was installed correctly. You can automatically install prerequisite packages using the APT utility. This will be covered later in th echapter.
How to List Installed DEBs
The dpkg --list command will list all the packages installed on your system
root@u-bigboy:~# dpkg --list Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===================-===================-================================ ii ssh 4.1p1-7ubuntu4 Secure shell client and server ... ... ... root@u-bigboy:~#
The output will be in six columns. The fourth column lists the name of the package, the fifth states the package version, and the sixth and last provides a description.
The first three columns are each only a single character wide and provide very specific information about the package as outlined in Table 6-3.
Table 6-3 Column Formatting for the dpkg command
| Desired State
| Current State
| Error State
|u||Unknown: The package has never been installed|
|i||Installed: A privileged user has requested the installation of the package|
|r||Remove: A privileged user has requested the removal of the package. Configuration files for the package most likely remain.|
|p||Purge: A previously installed package has been removed. Configuration files for the package have probably been removed.|
|h||Hold: A privileged user has requested that the package remain at its current version with no automatic upgrades.|
|n||Not Installed: The package is not installed|
|i||Installed: The package is installed|
|c||Configuration Files Exist: Package was installed, but the configuration files exist.|
|u||Unpacked: Files have been unpacked, but not installed|
|f||Failed: Configuration of the package has failed.|
|h||Halt: The package installation failed to complete|
|h||Enforced Hold: Package upgrade is on hold because another dependent package with a user defined hold requires this package to remain not upgraded.|
|r||Reinstallation: The package is broken and requires a reinstallation.|
|x||The package is both broken and on enforced hold.|
You can specify the desired package in which you are interested after the --list option to get a listing specific to that package. Here we see a single listing for the openssh-server package using this method.
root@u-bigboy:~# dpkg --list openssh-server Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===================-===================-======================================== ii openssh-server 4.2p1-7ubuntu3 Secure shell server, an rshd replacement root@u-bigboy:~#
You can also pipe the output of this command through the grep command if you are interested in only a specific package. In this example we are looking for all packages containing the string dhcp in the name.
root@u-bigboy:~# dpkg --list | grep dhcp ii dhcp3-client 3.0.2-1ubuntu6 DHCP Client ii dhcp3-common 3.0.2-1ubuntu6 Common files - dhcp3* packages root@u-bigboy:~#
Listing Files Associated with DEBs
Sometimes you'll find yourself installing software that terminates with an error requesting the presence of a particular file. In many cases the installation program doesn't state the DEB package in which the file can be found. It is therefore important to be able to determine the origin of certain files, by listing the contents for DEBs in which you suspect the files might reside.
Listing Files for Previously Installed DEBs
As stated previously, listing the files found in a package can be very useful. With dpkg, the --listiles option can provide this information easily. Here we list the files present in the openssh-server package.
root@u-bigboy:~# dpkg --listfiles openssh-server ... ... ... /var/run/sshd /usr/lib/sftp-server /usr/share/doc/openssh-server root@u-bigboy:~#
Listing Files in DEB Files
Download sites often have packages with different functions, but similar names. It is good to be able to list the contents of a DEB package to verify you have the correct one. This can be done with the --contents option for dpkg as can be seen in this example.
root@u-bigboy:/tmp# dpkg --contents openssh-server_4.2p1-7ubuntu3_i386.deb ... ... ... -rw-r--r-- root/root 10444 2006-05-17 17:43:19 ./usr/share/man/man8/sshd.8.gz -rw-r--r-- root/root 1169 2006-05-17 17:43:19 ./usr/share/man/man8/sftp-server.8.gz drwxr-xr-x root/root 0 2006-05-17 17:43:24 ./usr/share/doc/ drwxr-xr-x root/root 0 2006-05-17 17:43:24 ./usr/share/doc/openssh-client/ drwxr-xr-x root/root 0 2006-05-17 17:43:19 ./var/ drwxr-xr-x root/root 0 2006-05-17 17:43:19 ./var/run/ drwxr-xr-x root/root 0 2006-05-17 17:43:19 ./var/run/sshd/ ... ... ... root@u-bigboy:/tmp#
Listing the DEB Package to Which a File Belongs
Searching for the ownership of a particular file is also simple when using the --search option with dpkg. In this example, we see that the /etc/syslog.conf file is a part of the sysklogd package.
root@u-bigboy:~# dpkg --search /etc/syslog.conf sysklogd: /etc/syslog.conf root@u-bigboy:~#
The dpkg --remove command will erase an installed package as seen in this example.
root@u-bigboy:~# dpkg --remove ndiswrapper-utils (Reading database ... 70241 files and directories currently installed.) Removing ndiswrapper-utils ... root@u-bigboy:~#
Which DEBs Will Start Up At Boot Time?
You can view and configure which DEBs will start at boot time is by using the update-rc.d command. A more detailed explanation will be provided later in this chapter.
Automatic DEB Updates with apt-get
Like Fedora, Debian / Ubuntu Linux has its own package update application that will automatically retrieve packages from a network based repository. It is called the Advanced Package Tool (APT) and it is the most commonly used command is apt-get which we'll cover in more detail later
APT uses the /etc/apt/sources.list file to instruct your server as to where to find the required packages on your network. The default file locations in this file refer to a few trusted APT download websites on the Internet.
It is important to periodically resynchronize the APT package index files from the sources listed in the /etc/apt/sources.list file. This updates your system with listings of the most current package versions. This can be done with the apt-get update command as seen here:
root@u-bigboy:/tmp# apt-get update Get:1 http://security.ubuntu.com dapper-security Release.gpg [189B] Get:2 http://us.archive.ubuntu.com dapper Release.gpg [189B] Get:3 http://us.archive.ubuntu.com dapper-updates Release.gpg [189B] ... ... ... Fetched 184kB in 2s (66.1kB/s) Reading package lists... Done root@u-bigboy:/tmp#
Note: If you install Ubuntu without Internet access, only a barebones set of packages will be installed and the URL entries in the /etc/apt/sources.list file will be commented out, but the required packages will be flagged for eventual installation in the dpkg database. When you get Internet access, uncomment the URL entries and upgrade your installation with the apt-get command which will update your system with the full complement of required packages downloaded from the Web.
You can also create an APT server on your own network if you don't want all your Debian / Ubuntu servers to have Internet access. You'll have to update your sources.list file accordingly, but the full configuration steps are beyond the scope of this book.
Keeping Your System current with APT
The apt-get utility can be used to simultaneously upgrade all the packages on your system with the upgrade option. When used without listing any packages afterwards, apt-get will attempt to update them all. The apt-get upgrade package-name command updates only a particular DEB package.
It is always advisable to use apt-get after installing Linux to make sure the latest versions of software are installed for the sake of improved security and functionality. Here is an example of output of what to expect; the -y flag causes apt-get to assume "yes" as the answer to all prompts and allows it to run non-interactively:
root@u-bigboy:/tmp# apt-get -y upgrade Reading package lists... Done Building dependency tree... Done The following packages have been kept back: linux-image-386 The following packages will be upgraded: capplets-data desktop-file-utils eog gdm gnome-about ... ... ... Setting up libgtk2.0-bin (2.8.18-0ubuntu1) ... Updating the IM modules list for GTK+-2.4.0...done. Updating the gdk-pixbuf loaders list for GTK+-2.4.0...done. root@u-bigboy:/tmp#
Example of an apt-get Package Installation
Here is a sample installation of an individual package using yum. In this case the RPM installed is the apache Web server package:
[root@ root@u-bigboy:/tmp# apt-get -y install apache Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: apache-common apache2-utils libapr0 libpcre3 Suggested packages: apache-doc apache-ssl apache-perl The following NEW packages will be installed: apache apache-common apache2-utils libapr0 libpcre3 ... ... ... Creating config file /etc/apache/httpd.conf with new version Creating config file /etc/apache/srm.conf with new version Creating config file /etc/apache/access.conf with new version Creating config file /etc/apache/modules.conf with new version * Starting apache 1.3 web server... ...done. root@u-bigboy:/tmp#
Remember The Following APT Facts
- The APT utility's sources.list file primarily lists URLs using TCP port 80 (http://) for its updates This will have importance for your firewall rules.
- More details on configuring yum can be obtained by running the man sources.list and the man apt-get commands.
Installing Software Using tar Files
Another popular software installation file format is the tar file, which can frequently be obtained from the Web sites of software developers, and online software libraries such as www.sourceforge.net.
The Linux tar command is used to archive files and typically have a .tar file extension in the file name. These files are also frequently compressed in the gzip format, and when they do, their file extensions will end with .tar.gz or .tgz. The commands to extract the data from either type are similar. When a tar file is uncompressed, the command to extract the data is tar -xvf filename.tar. When the archive is compressed, the command to use is tar -xzvf filename.tar.gz.
The tar file installation process usually requires you first to uncompress and extract the contents of the archive in a local subdirectory, which frequently has the same name as the tar file. The subdirectory will usually contain a file called README or INSTALL, which outlines all the customized steps to install the software.
Here are the initial steps to take to install tar-based software:
1) Issue the tar command to extract the files.
[root@bigboy tmp]# tar -xvzf linux-software-1.3.1.tar.gz linux-software-1.3.1/ linux-software-1.3.1/plugins-scripts/ ... ... ... linux-software-1.3.1/linux-software-plugins.spec [root@bigboy tmp]#
This creates a subdirectory with the installation files inside.
[root@bigboy tmp]# ls linux-software-1.3.1 linux-software-1.3.1.tar.gz [root@bigboy tmp]#
2) Use the cd command to enter the subdirectory and follow the directions listed in the INSTALL and README files:
[root@bigboy tmp]# cd linux-software-1.3.1 [root@bigboy linux-software-1.3.1]# ls COPYING install-sh missing plugins depcomp LEGAL mkinstalldirs plugins-scripts FAQ lib linux-software.spec README Helper.pm Makefile.am linux-software.spec.in REQUIREMENTS INSTALL Makefile.in NEWS subst.in [root@bigboy linux-software-1.3.1]#
Software installation with tar files can be frustrating, frequently requiring the installation of other supporting tar files, each with its own customized installation commands. RPMs, with the single standardized command format, are usually easier to use and may be the better method to use for newer Linux users.
Installing Perl Modules
Even if you don't know how to program in Perl, you may find yourself having to install Perl modules to get some of your software packages to work.
Modules can be installed manually by downloading the TAR files from www.cpan.org, the primary Perl module site. The disadvantage is that this method doesn't automatically install any prerequisite modules you may need. Another disadvantage, though small is that the perl module names usually have a double colon (::) in their names, but the installation TAR file in which this module resides won't have the colons in its name. For example version 1.74 of the
Mail::Tools module has the file name
Modules can also be installed automatically using the
perl command. We will cover both methods in this section.
Manual Installation of Perl Modules
Most of the commonly used Perl modules can be downloaded from the CPAN website. The installation steps are straightforward.
1. Browse the CPAN website, identify the module package you need and then download it using a utility such as wget.
[root@bigboy tmp]# wget http://www.cpan.org/authors/id/M/MA/MARKOV/MailTools-1.74.tar.gz --15:07:36-- http://www.cpan.org/authors/id/M/MA/MARKOV/MailTools-1.74.tar.gz => `MailTools-1.74.tar.gz' Resolving www.cpan.org... 188.8.131.52 Connecting to www.cpan.org|184.108.40.206|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 47,783 (47K) [application/x-tar] 100%[===================================>] 47,783 100.88K/s 15:07:38 (100.51 KB/s) - `MailTools-1.74.tar.gz' saved [47783/47783] [root@bigboy tmp]#
2. Extract the file from the package with the tar command.
[root@bigboy tmp]# tar -xzvf MailTools-1.74.tar.gz MailTools-1.74/ MailTools-1.74/t/ ... ... ... MailTools-1.74/ChangeLog MailTools-1.74/MANIFEST [root@bigboy tmp]#
3. Enter the newly created directory with the same name as the TAR file, and install the module with the following commands.
- perl Makefile.PL
- make test
[root@bigboy tmp]# cd MailTools-1.74 [root@bigboy MailTools-1.74]# perl Makefile.PL Checking for Net::SMTP...ok Checking for Net::Domain...ok Checking for IO::Handle...ok Checking if your kit is complete... Looks good Writing Makefile for Mail [root@bigboy MailTools-1.74]# make cp Mail/Cap.pm blib/lib/Mail/Cap.pm cp Mail/Mailer/rfc822.pm blib/lib/Mail/Mailer/rfc822.pm ... ... ... Manifying blib/man3/Mail::Util.3pm Manifying blib/man3/Mail::Address.3pm [root@bigboy MailTools-1.74]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/extract.....ok ... ... ... All tests successful. Files=7, Tests=95, 2 wallclock secs ( 1.28 cusr + 0.29 csys = 1.57 CPU) [root@bigboy MailTools-1.74]#
Your Perl module installation should now be complete.
Note: The output of the perl Makefile.PL command will tell you whether there are any other required modules. You can either install them all manually, running the risk of having to install more prerequisite modules for these prerequisite modules, or you can use automated updates which will be covered next.
Automatic Installation of Perl Modules
Modules can be installed automatically using the
perl utility but you must first install the prerequisite
ncftp and perl-CPAN package to download the packages from
[root@bigboy tmp]# yum -y install ncftp perl-CPAN
After the package installed you can use the following
perl command to enter the
perl -MCPAN -e shell
The first time it is run, Perl will prompt you for a number of configuration options. In most cases the defaults will be sufficient. After the initial setup is complete you will have a cpan> command prompt
Installation of modules can then be done with the install command followed by the name of the module. In this example we install the
Mail::Audit module using the CPAN utility.
[root@bigboy tmp]# perl -MCPAN -e shell Terminal does not support AddHistory. cpan shell -- CPAN exploration and modules installation (v1.7602) ReadLine support available (try 'install Bundle::CPAN') cpan> install Mail::Audit CPAN: Storable loaded ok LWP not available CPAN: Net::FTP loaded ok Fetching with Net::FTP: ftp://archive.progeny.com/CPAN/authors/01mailrc.txt.gz ... ... ... Installing /usr/share/man/man3/Mail::Audit::MAPS.3pm Appending installation info to /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod /usr/bin/make install -- OK cpan> exit Terminal does not support GetHistory. Lockfile removed. [root@bigboy tmp]#
The exit command allows you to return to the Linux command prompt and your Perl module should be fully installed.
Updating Your Perl Modules
Upgrading or updating your modules to the latest version can also be done using the perl command line utility like this.
[root@bigboy tmp]# perl -MCPAN -we 'CPAN::Shell->install(CPAN::Shell->r)'
This is a simple process, but make sure you have internet connectivity first.
A simple definition of a daemon is a program that runs unattended even when nobody is logged into your system. They operate without the need for for interactive human control.
Daemons can be found in laptops, PCs and tablets to name a few. The program that automatically detects your network is probably a daemon. Many computer systems almost exclusively run daemons. These are often servers located in data centers and operate, for example, as webservers, database servers and fileservers.
Common examples of Linux server daemons are the syslog daemon which receives system error messages and writes them to a log file; the apache or httpd daemon that serves web pages to Internet web browsers and the sendmail daemon that places email it receives into your inbox. Many software packages provide daemons that must be managed. We’ll now discuss how this is done.
Daemon Management Command Summary
There are many ways to control daemons that are specific to your Linux distribution. These include: 1. systemd: Used by more recent versions of Fedora. 2. sysvinit / init scripts: Used by most Linux distributions. Daemon control scripts are located in the /etc/init.d directory. Sysvinit systems also come with the service comand that executes the daemon control scripts in /etc/init.d. 3. sysv-rc-conf: A Debian package that mimics the sysvinit service command. We will discuss the most commonly used daemon control commands next.
Reboot Persistent and Non-Persistent Commands
Reboot persistent commands define the state of the daemon when your system starts. Non-persistent commands govern the state of the daemon after the system has started. Non-persistent commands are typically run by systems administrators during troubleshooting and when daemons packages are newly installed and need to be activated.
You should remember when configuring your persistent commands that your system can boot in different states, such as a mode where only the CLI is accessible on the console, or other modes where a GUI interface is available. See Chapter 7, "The Linux Boot Process" for details.
Daemons can be set to start in some boot states and not others. It is important to keep this in mind when configuring your daemons.
All daemons have a configuration file that they reference. In most cases this is only done when they start up. To reconfigure a daemon you have to edit its configuration file and then restart it. Don't worry, each chapter of this book describes how to edit the the required configuration files for each package covered.
Daemons can be started in a number of ways depending on your distribution. Here are some examples using the sendmail daemon.
|systemd||# systemctl start sendmail.service||# systemctl enable sendmail.service|
|sysvinit||# service sendmail start||# chkconfig sendmail on|
|Init Script||# /etc/init.d/sendmail start||# chkconfig sendmail on|
|sysv-rc-conf||# sysv-rc-conf sendmail start||# sysv-rc-conf sendmail on|
Note: You can use the daemon status commands discussed in a later section to determine whether it is running. If the daemon manages a network related service you can also use the netstat command to check the TCP/UDP ports on which your server is listening. If it isn't running then there will be no response. In this case we are testing to see whether the TFTP daemon is running. As you can see we get a response. Success!
[root@bigboy tmp]# netstat -a | grep tftp udp 0 0 *:tftp *:* [root@bigboy tmp]#
The syntax for stopping daemons is very similar. Here are some examples using the sendmail daemon.
|systemd||# systemctl stop sendmail.service||# systemctl disable sendmail.service|
|sysvinit||# service sendmail stop||# chkconfig sendmail off|
|Init Script||# /etc/init.d/sendmail stop||# chkconfig sendmail off|
|sysv-rc-conf||# sysv-rc-conf sendmail stop||# sysv-rc-conf sendmail off|
Note: All daemons have a configuration file that they reference. In most cases this is only done when they start up. To reconfigure a daemon you have to edit its configuration file and then restart it. Don't worry, each chapter of this book describes how to edit the the required configuration files for each package covered.
Restarting daemons is also not difficult. Here are some examples using the sendmail daemon.
|systemd||# systemctl restart sendmail.service||N/A|
|sysvinit||# service sendmail restart||N/A|
|Init Script||# /etc/init.d/sendmail restart||N/A|
|sysv-rc-conf||# sysv-rc-conf sendmail restart||N/A|
Troubleshooting often requires you to know the state of your daemons. Here are some examples using the sendmail daemon.
|systemd||# systemctl status sendmail.service|| # systemctl is-enabled sendmail.service |
# systemctl list-unit-files --type=service
|sysvinit||# service sendmail status||# chkconfig --list|
|Init Script||# /etc/init.d/sendmail status||# chkconfig --list|
|sysv-rc-conf||# sysv-rc-conf sendmail status||# sysv-rc-conf --list|
The chkconfig Command
As stated earlier, the chkconfig command can be used to adjust which applications start at each runlevel. You can use this command with the --list switch to get a full listing of packages listed in /etc/init.d and the runlevels at which they will be on or off:
[root@bigboy tmp]# chkconfig --list keytable 0:off 1:on 2:on 3:on 4:on 5:on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off wlan 0:off 1:off 2:on 3:on 4:on 5:on 6:off sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off random 0:off 1:off 2:on 3:on 4:on 5:on 6:off ... ...
A Simple chkconfig Exercise
You can use chkconfig to change runlevels for particular packages. In this exercise we'll use the command to manipulate the operation of the sendmail daemon.
1. Use chkconfig to get a listing of sendmail's current startup options The chkconfig command can be used with grep to determine the run levels in which sendmail will run. Here we see it will run at levels 3 and 5.
[root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off [root@bigboy tmp]#
2. Switch off sendmail starting up in levels 3 and 5 The chkconfig command with the --level switch indicates that some action needs to be done at the runlevels entered as its values. The first argument in the command is the package you want to affect and the second defines whether you want it on or off. In this case we want sendmail not to be started when entering runlevels 3 and 5:
[root@bigboy tmp]# chkconfig --level 35 sendmail off [root@bigboy tmp]#
By not specifying the runlevels with the --level switch, chckconfig will make the changes for runlevels 3 and 5 automatically:
[root@bigboy tmp]# chkconfig sendmail off
Because the intention is to permanently shutdown sendmail permanently, we might also have to stop it from running now.
[root@bigboy tmp]# service sendmail stop Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ] [root@bigboy tmp]#
3. Double-check that sendmail will not start up We can then use chkconfig to double-check our work.
[root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@bigboy tmp]#
4. Turn on sendmail again To reactivate sendmail, we can use chkconfig once more, but with the on argument. Start sendmail again to get it running immediately, not just after the next reboot.
[root@bigboy tmp]# chkconfig sendmail on [root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off [root@bigboy tmp]# service sendmail start Starting sendmail: [ OK ] Starting sm-client: [ OK ] [root@bigboy tmp]#
This exercise should have given you insights into the basic operation of the chkconfig command. Next we'll explore the use of chkconfig daemon management.
Using chkconfig to Improve Security
A default Fedora installation automatically starts a number of daemons that you may not necessarily need for a Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.
The screen output of the netstat -an command below shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?
[root@bigboy tmp]# netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 :::22 :::* LISTEN udp 0 0 0.0.0.0:32768 0.0.0.0:* udp 0 0 0.0.0.0:930 0.0.0.0:* udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* ... ... [root@bigboy tmp]#
For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command which lists all open, or actively used, files and can be given additional options to extend its scope to include the TCP/IP protocol stack.
In the next examples we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd and ntp daemons respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS", and 30, "Configuring NIS". portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. NTP, which is covered in Chapter 24, "The NTP Server", is required for synchronizing your time with a reliable time source, and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and xinetd", and it might be required for their operation:
[root@ bigboy tmp]# lsof -i tcp:111 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME portmap 1165 rpc 4u IPv4 2979 TCP *:sunrpc (LISTEN) [root@ bigboy tmp # [root@bigboy tmp]# lsof -i tcp:32769 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME xinetd 1522 root 5u IPv4 2764 TCP probe-001:32769 (LISTEN) [root@bigboy tmp]# [root@bigboy root]# lsof -i udp:123 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ntpd 1321 ntp 4u IPv4 3390 UDP *:ntp ... ... [root@bigboy root]#
In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently.
[root@bigboy tmp]# lsof -i tcp:32768 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME rpc.statd 1178 rpcuser 6u IPv4 2400 TCP *:32768 (LISTEN) [root@bigboy tmp]# ls /etc/init.d/rpc.statd ls: /etc/init.d/rpc.statd: No such file or directory [root@bigboy tmp]# grep -i statd /etc/init.d/* /etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0 ... ... [root@bigboy tmp]#
As a rule of thumb, applications listening only on the loopback interface (IP address 127.0.0.1) are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address 0.0.0.0, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shutdown nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers", for details). Your needs may be different.
Remember to thoroughly research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books and the Internet for information. Unpredictable results are always undesirable.
Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.
Final Tips on chkconfig
Remember the following:
- In most cases, you want to modify runlevels 3 and 5 simultaneously and with the same values.
- Don't add/remove anything to other runlevels unless you absolutely know what you are doing. Don't experiment, unless in a test environment.
- chkconfig doesn't start the programs in the /etc/init.d directory, it just configures them to be started or ignored when the system boots up. The commands for starting and stopping the programs covered in this book are covered in each respective chapter.
The sysv-rc-conf Command
With Debian / Ubuntu Linux, the
update-rc.d command replaces
chkconfig as the default package for modifying
/etc/init.d script links. Unfortunately, the utility was written to facilitate link modification when packages are installed or removed, but is less friendly when you need to alter links for existing packages you want to keep.
Fortunately there is hope for the harried systems administrator in the form of the
sysv-rc-conf package which uses an almost identical syntax to
chkconfig, and has a GUI mode if you run it from the command line without any arguments. This section will show you some important tips in using
sysv-rc-conf package can be installed easily using
apt-get. Here is an example.
root@u-bigboy:~# apt-get install sysv-rc-conf
Listing the runlevels for Daemons
This can be done with the
--list option. In this example below we get a listing for only the apache daemon.
root@u-bigboy:~# sysv-rc-conf --list apache apache 0:off 1:off 2:on 3:on 4:on 5:on 6:off root@u-bigboy:~#
Here we get a listing for everything.
root@u-bigboy:~# sysv-rc-conf --list acpi-support 0:off 1:off 2:on 3:on 4:on 5:on 6:off acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off alsa-utils 0:off 6:off … … … vbesave 2:on 3:on 4:on 5:on x11-common S:on root@u-bigboy:~#
Setting the runlevels for Daemons
sysv-rc-conf program has further similarities to the
chkconfig syntax. Here we set the
apache daemon to start automatically at levels 2 through 5.
root@u-bigboy:~# sysv-rc-conf apache on
Similarly, we can set the
apache daemon not to start at levels 2 through 5 with this command:
root@u-bigboy:~# sysv-rc-conf apache off
Finally we can use set the
apache daemon to start only at levels 3 and 5.
root@u-bigboy:~# sysv-rc-conf --level 35 apache on
This is just the beginning. If the software you install is intended to make your Linux machine permanently run an application such as a Web server, mail server, or any other type of server you have to know how to get the software activated when the system reboots. This is covered in Chapter 7, "The Linux Boot Process". Subsequent chapters cover the use, configuration, testing, and troubleshooting of many of the most popular Linux server applications used today.