Linux Administration: Installing Software

Three basic software installations are covered here — using the Red Hat Package Manager, compiling software using the standard GNU compilation method, and compiling and installing the software by hand. (From the book Linux Administration, A Beginner’s Guide, third edition by Steven Graham and Steve Shah, McGraw-Hill/Osborne, 0072225629, 2002).

linuxA great deal of your time will be spent keeping your Linux system up to date with the latest and greatest software. There are three basic methods to installing software on a Linux system. One, use the package manager for the distribution. This is typically the Red Hat Package Manager (RPM). Two, compile the software using the standard GNU compilation method. Three, compile and install the software by hand. We will cover these methods in this module.

When installing software, you typically need to be the root user. (Module 6 will cover how to change user IDs with the su command.) In a terminal window, just type su – root.

Use the Red Hat Package Manager

The Red Hat Package Manager’s primary function is to allow the installation and removal of files (typically, precompiled software). It is wonderfully easy to use, and several graphical interfaces have been built around it to make it even easier. Red Hat, Caldera, and other distributions have started using this tool to distribute their software. In fact, almost all of the software mentioned in this book is available in RPM form. The reason you’ll go through the process of compiling software yourself in other modules is so that you can customize the software to your system, as such customizations might not exist in an RPM.

An RPM file is a package that contains files needed for the software to function correctly. These files can be configuration files, binaries, and even pre and post scripts to run while installing the software.

NOTE  In this context, we are assuming that the RPM files contain precompiled binaries. Several groups, such as Red Hat, also make source code available as an RPM, but it is uncommon to download and compile source code in this fashion.

The RPM tool performs the installation and uninstallation of RPMs. The tool also maintains a central database of what RPMs you have installed and other information about the package.

In general, software that comes in the form of an RPM is less work to install and maintain than software that needs to be compiled. The tradeoff is that by using an RPM, you accept the default parameters supplied in the RPM. In most cases, these defaults are acceptable. However, if you need to be more intimately aware of what is going on with a service, you may find that compiling the source yourself will prove more educational about what package components exist and how they work together.

Assuming that all you want to do is install a simple package, RPM is perfect. There are several great resources for RPM packages, including the following:

Of course, if you are interested in more details about RPM itself, you can visit the RPM Web site at RPM comes with Red Hat Linux (and derivatives) as well as Caldera Linux. If you aren’t sure if RPM comes with your distribution, check with your vendor.

NOTE  Although the name of the package says “Red Hat,” the software can be used with other distributions as well. In fact, RPM has even been ported to other operating systems, such as Solaris and IRIX. The source code to RPM is open-source software, so anyone can take the initiative to make the system work for them.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Installing a New Package}

The easiest way to install a new package is to use the -i option with RPM. For example, if you downloaded a package called bc-1.05a-4.i386.rpm and wanted to install it, you would type:

[root@ford /root]# rpm -ivh bc-1.05a-4.i386.rpm

If the installation went fine, you would not see any errors or messages. This is the most common method of installing RPMs. On the other hand, if the package already exists, you would see this message:

error: package bc-1.05a-4 is already installed

Some packages rely on other packages. A game, for example, may depend on SVGA libraries having already been installed. In those instances, you will get a message indicating which packages need to be installed first. Simply install those packages and then come back to the original package.

If you need to upgrade a package that already exists, use the -U option, like so:

[root@ford /root]# rpm -Uv bc-1.05a-4.i386.rpm

Some additional command-line options to RPM are listed in Table 1.

Command-Line OptionDescription
–forceThis is the sledgehammer of installation. Typically, you use it when you’re knowingly installing an odd or unusual configuration, and RPM’s safeguards are trying to keep you from doing so. The –force option tells RPM to forego any sanity checks and just do it, even if it thinks you’re trying to fit a square peg into a round hole. Be careful with this option.
-hPrints hash marks to indicate progress during an installation. Use with the -v option for a pretty display.

Prints the percentage completed to indicate progress. It is handy if you’re running RPM from another program, such as a Perl script, and you want to know the status of the install.

-nodepsIf RPM is complaining about missing dependency files, but you want the installation to happen anyway, passing this option at the command line will cause RPM to not perform any dependency checks.
-qQueries the RPM system for information.
–testThis option does not perform a real installation; it just checks to see whether an installation would succeed. If it anticipates problems, it displays what they’ll be.
-VVerifies RPMs or files on the system.
-vTells RPM to be verbose about its actions.

Table 1  RPM Command-Line Options

For example, to force the installation of a package regardless of dependencies or other errors, you would type:

[root@ford /root]# rpm -i –force -nodeps packagename.rpm

where packagename.rpm is the name of the package being installed.

Querying a Package

Sometimes it is handy to know which packages are currently installed and what they do. You can do that with the RPM query options.

To list all installed packages, simply type:

[root@ford /root]# rpm -qa

Be ready for a long list of packages! If you are looking for a particular package name, you can use the grep command to specify the name (or part of the name) of the package, like so:

[root@ford /root]# rpm -qa | grep -i ‘ name’

NOTE  The -i parameter in grep tells it to make its search case-insensitive.

If you just want to view all of the packages one screen at a time, you can use the more command, like so:

[root@ford /root]# rpm -qa | more

To find out which package a particular file belongs to, type:

[root@ford /root]# rpm -qf filename

where filename is the name of the file that you want to check on.

To find out the purpose of a package that is already installed, you must first know the name of the package (taken from the listing in rpm -qa) and then specify it, like so:

[root@ford /root]# rpm -qi packagename

where packagename is the name of the package that you want information about.

To find out what files are contained in a package, type:

[root@ford /root]# rpm -qlp packagename

where packagename is the name of the package that you want information about.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Uninstalling a Package}

Uninstalling packages with RPM is just as easy as installing them. In most cases, all you will need to type is

[root@ford /root]# rpm -e packagename

where packagename is the name of the package as listed in rpm -qa.

Verifying an RPM

A very cool option to the RPM tool is the ability to verify a package. What happens is RPM looks at the package information in its database, which is assumed to be good. It then compares that information with the binaries and files that are on your system. Unfortunately, in today’s Internet world, where being hacked is a real possibility, this kind of test should tell you instantly if anyone has done something to your system (see Module 11 for tips on securing your system from attacks). For example, if you want to verify that the /bin/ls command is valid, you would type:

[root@ford /root]# rpm –Vf /bin/ls

If everything is okay with /bin/ls, nothing will be displayed to the terminal. If something is wrong, RPM will inform you of what test failed. Some example tests are the MD5 checksum test, file size, and modification times. The moral of the story is: RPM is an ally in finding out what is wrong with your system. If you suspect several things might be wrong, you can verify all installed packages on your system by typing:

[root@ford /root]# rpm –Va

This command verifies all of the packages installed on your system. That’s a lot of files, so you might have to give it some time to complete.

GUI RPM Installers

For those who like a good GUI tool to help simplify their lives, there are several package managers included with your distribution. Gnorpm is a good GNOME tool that will typically work under KDE as well. It performs all of the functions that the command-line version does without forcing you to remember command-line parameters. Of course, this comes at the price of not being scriptable, but that’s why you have the command-line version, too.

Progress Check

  1. What does RPM stand for? (Red Hat Package Manager)
  2. What command is used to query the RPM database? (rpm -q)

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Compile and Install GNU Software}

One of the key benefits of open-source software is that you have the source code in your hands. If the developer chooses to stop working on it, you can continue. If you find a problem, you can fix it. In other words, you are in control of the situation and not at the mercy of a commercial developer you can’t control. But having the source code means you need to be able to compile it, too. Otherwise all you have is a bunch of text files that can’t do much.

Although almost every piece of software in this book is available as an RPM, we will step through the process of compiling it yourself so that you can pick and choose compile time options, which is something you can’t do with RPMs. Also, an RPM might be compiled for a specific architecture such as the Intel 486. That code might run better if you compiled it natively on your Intel 686 Pentium III class CPU.

In this section, we will step through the process of compiling the Hello package, a GNU software package that might seem useless at first, but there are reasons for its existence. Most GNU software conforms to a standard method of installing, so let’s go ahead and get the package.

Getting and Unpacking the Package

Software that comes in source form is generally made available as a tarball–that is, it is archived into a single large file and then compressed. The tools used to do this are tar and gzip. tar handles the process of combining many files into a single large file, and gzip is responsible for the compression.

NOTE  Do not confuse gzip with WinZip. They are two different programs that use two different (but comparable) methods of compression. It should be noted, though, that WinZip does know how to handle tarballs.

Typically, a single directory is selected in which to build and store tarballs. This allows the system administrator to keep the tarball of each package in a safe place in the event he or she needs to pull something out of it later. It also lets all the administrators know which packages are installed on the system in addition to the base system. A good directory for this is /usr/local/src, since software local to a site is generally installed in /usr/local.

When unpacked, a tarball will generally create a new directory for all of its files. The hello tarball (hello-1.3.tar.gz), for example, creates the subdirectory hello-1.3. Most packages follow this standard. If you find a package that does not follow it, it is a good idea to create a subdirectory with a reasonable name and place all the unpacked source files there. This allows multiple builds to occur at the same time without the risk of the two builds conflicting.

First, let’s get into the directory we want to compile in:

[root@ford /root]# cd /usr/local/src

Download the hello-1.3.tar.gz file from the GNU FTP site at You can type the URL into a browser and download the package or you can use the ftp command-line tool to download the package

[root@ford src]# ftp
Connected to
220 GNU FTP server ready.

330 Please specify the password. (You won’t see this when you type it)
ftp>cd /gnu/hello
ftp>get hello-1.3.tar.gz

It is a common courtesy to type in your e-mail address as the password. If the ftp account doesn’t work you might want to try anonymous. Once in the ftp command prompt, the bin option tells ftp that you want to transfer the files using binary mode. The hash option will print a hash mark for every 1024 bytes of data sent. Finally, you cd into the directory and then issue the FTP get command to grab the file. You exit the FTP program by typing bye. Then unpack the tarball with the following command:

[root@ford src]# tar -xvzf hello-1.3.tar.gz

NOTE  You might encounter files that end with the .tar.bz2 extension. Bzip2 is a compression algorithm that is gaining popularity, and GNU tar does support decompressing it on the command line with the y or j option (instead of the z parameter).

The z parameter in the tar command invokes gzip to decompress the file before the untar process occurs. The v parameter tells tar to show the name of the file it is untarring as it goes through the process. This way you’ll know the name of the directory where all the sources are being unpacked. You should now have a directory called /usr/local/src/hello-1.3. You can test this by using the cd command to move into it:

[root@ford src]# cd /usr/local/src/hello-1.3

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Looking for Documentation}

Once you are inside the directory with all of the source code, begin looking for documentation. Always read the documentation that comes with the source code! If there are any special compile directions, notes, or warnings, they will most likely be mentioned here. You will save yourself a great deal of agony by reading the relevant files first.

So then, what are the relevant files? Typically there are two files in a distribution, README and INSTALL, both of which are located in the root of the source code directory. The README file generally includes a description of the package, references to additional documentation (including the installation documentation), and references to the author of the package. The INSTALL file typically has directions for compiling and installing the package.

These are not, of course, absolutes. Every package has its quirks. The best way to find out is to simply list the directory contents and look for obvious signs of additional documentation. Some packages use different capitalization: readme, README, ReadMe, and so on. Some introduce variations on a theme, such as README.1ST or README.NOW, and so on.

Another common place for additional information is a subdirectory that is appropriately called “doc” or “documentation.”

To view a text file, use the more command:

[root@ford hello-1.3]# more README

To view the text file in the pico editor, use the pico command:

[root@ford hello-1.3]# pico README

TIP  To get a quick list of all the directories in a source tree, enter the command [root@ford hello-1.3]# ls -l | grep drwx.

Configuring and Compiling the Package

Most packages ship with an autoconfiguration script; it is safe to assume they do unless their documentation says otherwise. These scripts are typically named configure, and they take parameters. There are a handful of stock parameters that are available across all configure scripts, but the interesting stuff occurs on a program-by-program basis. Each package will have a handful of features that can be enabled or disabled or that have special values set at compile time, and they must be set up via configure.

To see what configure options come with a package, simply run:

[root@ford hello-1.3]# ./configure –help

Yes, those are two hyphens () before the word “help.”

One commonly available option is –prefix. This option allows you to set the base directory where the package gets installed. By default, most packages use /usr/local. Each component in the package will install into the appropriate directory in /usr/local.

With all of the options you want set up, a final run of configure will create a special type of file called a makefile. Makefiles are the foundation of the compilation phase. Generally, if configure fails you will not get a makefile. Make sure that the configure command did indeed complete without any errors.

Compiling Your Package

Compiling your package is the easy part. All you need to do is run make, like so:

[root@ford hello-1.3]# make

The make tool reads all of the makefiles that were created by the configure script. These files tell make which files to compile and the order in which to compile them–which is crucial since there could be hundreds of source files.

Depending on the speed of your system, the available memory, and how busy it is doing other things, the compilation process could take a while to complete, so don’t be surprised.

As make is working, it will display each command it is running and all of the parameters associated with it. This output is usually the invocation of the compiler and all of the parameters passed to the compiler—it’s pretty tedious stuff that even the programmers were inclined to automate!

If the compile goes through smoothly, you won’t see any error messages. Most compiler error messages are very clear and distinct, so don’t worry about possibly missing an error. If you do see an error, don’t panic. Most error messages don’t reflect a problem with the program itself, but usually with the system in some way or another. Typically, these messages are the result of inappropriate file permissions (see the chmod command in Module 6) or files that cannot be found. In the latter case, make sure your path has at the very least the /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and /usr/X11R6/bin directories in it. You can see your path by issuing the following command:

[root@ford hello-1.3]# echo $PATH

See Module 6 for information on environment variables so that you can set your path correctly.

In general, slow down and read the error message. Even if the format is a little odd, it may explain what is wrong in plain English, thereby allowing you to quickly fix it. If the error is still confusing, look at the documentation that came with the package to see if there is a mailing list or e-mail address you can contact for help. Most developers are more than happy to provide help, but you need to remember to be nice and to the point. (In other words, don’t start an e-mail with a rant about why their software is terrible.)

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Installing the Package and Testing the Software}

As with the compile stage, the installation stage typically goes smoothly. In most cases, once the compile is done, all you need to run is

[root@ford hello-1.3]# make install

This will start the installation script (which is usually embedded in the makefile). Because make displays each command as it is executing it, you will see a lot of text fly by. Don’t worry about it–it’s perfectly normal. Unless you see an error message, the package is installed.

If you do see an error message, it is most likely because of permissions problems. Look at the last file it was trying to install before failure, and then go check on all the permissions required to place a file there. You may need to use the chmod, chown, and chgrp commands for this step; see Module 6 for additional details.

Testing the Software

A common mistake administrators make is to go through all of the process of configuring and compiling and then when they install they don’t test out the software. Testing the software also needs be done as a regular user, if the software is to be used by non-root users. In our example, you run the hello command to verify the permissions are correct and users won’t have problems running the program. You will quickly change users to make sure the software is usable by everyone. We’ll cover the su command in Module 6.

[root@ford /]# su – sgraham
[sgraham@ford ]-> /usr/local/bin/hello

Hello, world!
[sgraham@ford ]-> exit
[root@ford /]#

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Common Software Problems}

The GNU hello program might not seem like a very useful tool, for the most part I will agree it is not. But one valuable thing it provides is the ability to test the compiler on your system. If you’ve just finished the task of upgrading your compiler, compiling this simple program will provide a sanity check that indeed the compiler is working.

One problem you might run into is when the program can’t find a file of the type “” and the program terminates because it can’t find the file. This file is what is called a library. This is synonymous with DLLs in Windows. These libraries are stored in several locations on the Linux system and typically reside in /usr/lib/ and /usr/local/lib/. If you have installed a software package in a different location than /usr/local you will have to configure your system or shell to know where to look for those new libraries.

NOTE  Linux libraries can be located anywhere in your file system. Typically Windows only allows you to store libraries in one location. You’ll see that with the use of NFS you can share a directory (in our case, software from one server) and allow any client using that share to use the software residing on the share. With Windows, you’re stuck installing the software on each and every machine.

There are two methods for configuring libraries on a Linux system. One is to modify /etc/ld.conf, add the path of your new libraries, and use the ldconfig –m command to load in the new directories. You can also use the LD_LIBRARY_PATH environment variable to hold a list of library directories to look for library files. Read the man page for ld.conf for more information.

Progress Check

1. What is the README file used for? (The README file holds information on how to compile/install and use the software.)
2. What three steps are used to compile a typical GNU software package? (First configure, then make, and then make install.)

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Cleanup and When There is No Configure Script}

Once the package is installed, you can do some cleanup to get rid of all the temporary files created during the installation. Since you have the original source code tarball, it is okay to simply get rid of the entire directory from which you compiled the source code. In the case of the hello program, you would get rid of /usr/local/src/hello-1.3. Begin by going one directory level above the directory you want to remove. In this case, that would be /usr/local/src.

[root@ford hello-1.3]# cd /usr/local/src

Now use the rm command to remove the actual directory, like so:

[root@ford src]# rm -rf hello-1.3

CAUTION  The rm command, especially with the -rf parameter, is very dangerous. It recursively removes an entire directory without stopping to verify any of the files. When run by the root user, this has the potential to really cause problems on your system. Be very careful and make sure you are erasing what you mean to erase. There is no “undelete” command. I repeat, there is no “undelete” command.

When There Is No configure Script

Sometimes you will download a package and instantly cd into a directory and run ./configure. And you will probably be shocked when you see the message, “No such file or directory.” As stated earlier in the module, read the README and INSTALL files in the distribution. Typically, the authors of the software are courteous enough to provide at least these two files. I don’t know how many times I’ve tried compiling something without first looking at the docs and then come back hours later to find that I missed a step. The first step you take when installing software is to read the documentation. It will probably point out the fact that you need to run imake first, then run make. You get the idea: always read the documentation first, then proceed to compiling the software.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Compiling and Installing a GNU Program}

In this project, you will download a GNU software package, compile, and install it. I am a big emacs fan, so I am going to show how to download and compile it in this project. emacs most likely already comes standard on a Linux system, as it is a fairly popular editor. As an administrator, you will be exposed to many editors, such as vi, pico, and emacs. You are always guaranteed to have vi on the system. You don’t have to install emacs, just pick a package that sounds interesting (stay away from gcc, though)

Step by Step

1. Change your directory to a scratch space that will allow you to compile (typically /usr/local/src).

[root@ford /root ]# cd /usr/local/src

2. Go to the GNU FTP site and download emacs. The latest version as of this writing is emacs-21.2. The software is located at

3. Untar the package.

[root@ford /usr/local/src ]# tar -xvzf emacs-21.2.tar.gz

4. cd into the package directory and read the documentation, notably README and INSTALL.

[root@ford /usr/local/src ]# cd emacs-21.2
[root@ford emacs-21.2]# more README
[root@ford emacs-21.2]# more INSTALL

5. Run the configure script with the standard options: –prefix=/usr/local.

[root@ford emacs-21.2]# ./configure –prefix=/usr/local

6. Run make.

[root@ford emacs-21.2]# make

7. If the make completed without any errors, type make install.

[root@ford emacs-21.2]# make install

8. Make sure that you can run the software as both root and a regular user.

[root@ford emacs-21.2]# cd /usr/local/bin
[root@ford bin]# ./emacs
[root@ford bin]# su – sgraham
[sgraham@ford ]-> /usr/local/bin/emacs
[sgraham@ford ]-> exit
[root@ford bin]#

9. Do any cleanup and have a fun time using the software.

[root@ford bin]# cd /usr/local/src/emacs-21.2
[root@ford bin]# make clean

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Project Summary}

You have now compiled and installed the emacs editor. I usually leave the source sitting around for a while, just in case I need to make some changes to the software. If you are running low on space you might want to do a make clean in the package directory to clear out any object files (.o) and other files needed for the compilation. Or you can simply delete the directory. Please note that emacs is a fairly big package to download and to compile. On a slow system it can take quite a while to compile. You now know how to download and compile software for your system. Luckily, most software is distributed in the GNU format where you just have to type ./configure, then make, then make install to compile and install the software.

Module 4 Mastery Check

  1. What is a .gz file?
  2. What does the tar command do?
  3. How do you configure a typical GNU software package?
  4. What file tells make what to do?
  5. What command would you issue to install the package hello-1.3.i386.rpm?
  6. What command would you issue to see all the RPM packages installed on your system?
  7. How would you verify all of the RPM packages on your system?
  8. What two files should you always look for when installing software?
  9. You have just gotten done installing some software by hand. As a regular user, you try running the command and it doesn’t work the way you thought. What steps would you take in troubleshooting the problem?
  10. How do you become the root user?
  11. Name some advantages to using the RPM tool.
  12. Name some disadvantages to using the RPM tool.
  13. What does the make program do?
  14. What does the command make clean do?
  15. What command would you issue to install the software you just got done compiling?

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today.

Buy this book now.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye