~  CHAPTER 4:    INSTALLING SOFTWARE  ~

 

 

Given that a great deal of systems administration centers around installing the software necessary

to provide a service, it is important that we discuss the mechanisms for installing new packages as

well as compiling those packages that ship as source code.

 

You can change users by typing in the su command.

 

 

The Red Hat Package Manager

 

Red Hat, Caldera, and other distributions have started using this tool to distribute their software. 

Basically an RPM file is a collection of all the files necessary for a particular program to run.  It also

includes descriptions of the program, version information, and the necessary scripts to perform the

installation itself.

 

NOTE:  In this context, we are assuming that the RPM files contain pre-compiled 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 general management of all of the RPM packages that are installed on a

given host.  This includes tracking which packages are installed, their version numbers, and their

file locations.  All of this information is kept in a simple database file on the host.

 

But assuming that all you want to do is install a simple packages, RPM is perfect.  There are

several great resources for RPM packages, including the following:

 

http://www.rpmfind.net

ftp://ftp.redhat.com/pub/contrib

http://www.inuxapps.com

http://www.rpm.org

 

 

NOTE:   Although the name of the packages 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.

 

 

======================================================================

 

linux4.html                                                      PAGE 2                                                      2002/07/14

 

 

 

Installing a New Package

 

The easiest way to install a new packages is to use the –I option with RPM.  For example, if we

download a package called bc-1.05a-4.i386.rpm and wanted to install it, we would type

 

[root@ford^/root]# rpm^-I^bc-i.05a-4.i386.rpm

 

If the installation went fine, you would not see any errors or messages.

 

On the other hand, if the package already exists, we 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^-U^bc-1.05a-4.i386.rpm

 

 

Other Commands:

 

--force:  This is the sledgehammer of installation. The –force option tells RPM to forgo 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.

 

-h:  Prints hash marks to indicate progress during an installation.  Use the –v option for a pretty

display.

 

--%:  Prints the percentage completed to indicate progress.

 

--nodeps:  If 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 not to perform any

dependency checks.

 

test:  This option does not perform a real installation; it just checks to see whether an installation

would succeed.

 

-v:  Tells RPM to be verbose about its actions.

 

 

For example, to force the installation of a package regardless of dependencies or other errors,

we would type:

 

[root@ford^/root]#rpm^-I^--force^-nodeps^packagename.rpm

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

 

 

 

======================================================================

 

linux4.html                                                      PAGE 3                                                      2002/07/14

 

 

 

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^/ford]#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.

 

BE CAREFUL, the i switch is used in installs also.

 

 

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

 

 

gnorpm

 

For those of use who like a good GUI tool to help simplify our lives, there is gnorpm.  Although

it was meant to run under the GNOME environment, it works quite nicely under KDE as well.

Of course, this comes as the price of not being scriptable, but that’s why we have the

command-line version, too.

 

 

Compiling Software Yourself

 

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. 

 

 

 

 

======================================================================

 

linux4.html                                                      PAGE 4                                                      2002/07/14

 

 

 

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 hot 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.

 

A good directory for this is /usr/local/src, since software local to a site is generally installed

in /usr/local.

 

 

 

tarball

 

(ssh-2.0.13.tar.gz), for example, creates the subdirectory ssh-2.0.13.

When unpackaged, most tarballs create a new directory for all of its files.  Te SSH

To unpack the SSH tarball, first move the file into the /usr/local/src directory, like so:

 

[root@ford^/root]#mv^ssh-2.0.13.tar.gz^/usr/local/src

 

Tar is gathered together, and gzip is just compression.

 

z:  parameter in the tar command invokes gzip to decompress the file before the untar process

occurs.

 

            v:  parameter tells tar to show the name of the file it is untarring as it goes

            through the process.

 

            NOTE:  Never zip or compress take backups in Linux.  If you have any

            Error, even small , the entire group of tapes will be impossible to use.

 

 

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! 

 

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

packages.  The INSTALL file typically has directions for compiling and installing the package.

 

 

 

======================================================================

 

linux4.html                                                      PAGE 5                                                      2002/07/14

 

 

 

 

Sometimes you will find a directory called doc or documentation

 

TIP:  To get a quick list of all of the directories in a source tree, enter the command:

 

                        [root@ford^ssh-2.0.13] #ls^-l^|^grep^drwx

 

 

Configuring 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 names “configure”, and they take

parameters.

 

To view this configure type ./configure^--help

Yes, those two dashes (--) before the word “help”.

One commonly available option is --prefix.  This option allows you to set the base directory

By default, most packages use /usr/local.  Each component in the package will install into the

appropriate directory in /usr/local.  For example, the server component of SSH is called sshd,

which gets installed into /usr/local/sbin.

 

 

 

Compiling Your Package

 

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

 

make

 

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.

associated with it. 

 

 

 

 

======================================================================

 

linux4.html                                                      PAGE 6                                                      2002/07/14

 

 

 

Installing the Package

 

Similar to the compile stage, the installation stage typically goes smoothly. 

 

[root@ford^ssh-2.0.13]#make^install

 

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. Here are some other commands that are used by make:

 

 

chmod.  I assume this is check module.

chown.  I assume this means check owner.

chgrp.  I assume this is check group.

make^clean.  Cleans up temporary files.

mrproper^clean.  Another utility.

 

 

Clean Up

 

Once the package is installed, you can do some cleanup go get rid of all the temporary files

related during the installation.  Since you have the original source car tarball, it is okay to

simply get rid of the entire directory from which you compiled the source code.

In the case of SSH, you would get rid of the /usr/local/src/ssh-2.0.13.  Begin by going one

directory level above the directory you want to remove.  In this case, that would be /usr/local/src.

 

[root@ford ssh-2.0.13]#cd^/usr/local/src

 

Now use the RM command to remove the actual directory like so:

 

[root@ford^src]#rm^-rf^sssh-2.0.13] 

 

 

**** Use with caution ****

 

CAUTION:  the rm command, especially with the –rf parameter, is very dangerous.  It

recursively remove an entire directory without stopping to verify any of the files.  Run as 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.

 

 

SUMMARY