Installing Programs from the Shell

As you would expect, working at the shell offers the most control with regard to program installation. It's one of the only ways of installing packages that are considered "unofficial," which are usually RPM files that are not supplied by SUSE.

A variety of commands are available to handle program installation and maintenance. They let you interface directly with the RPM software, avoiding YaST2 completely if you wish (although bear in mind that YaST2 merely presents the RPM database in a user-friendly form and lets you administer it easily).

Understanding RPM Filenames

As discussed earlier, SUSE Linux uses RPM files for software installation. These are the files you'll usually be dealing with at the command line, and their filenames usually tell you everything you need to know about them. Here's one example:

mozilla-1.6-72.i586.rpm 

At the beginning of the filename is the name of the program: the popular Mozilla web browser in this instance. Following this are the version numbers: 1.6-72. These aren't guaranteed to follow the version number conventions used by the developer of the software, although they're very similar in most cases. However, the numbers after the dash in a version number tend to refer to the build of the RPM, which indicates the specific version of the RPM file. Many different RPMs might be created from the same original software, so it's necessary to have such a way of telling the different RPMs apart.

After the name and version number is the platform the RPM file will work on. i586 indicates that this program will work on all 80586-compatible processors—anything including a Pentium chip and above. i586 refers to the numbering system used within CPU manufacturing.

In some instances, you might find packages stipulating i686, indicating that they're designed for a Pentium II processor and above. Also, many RPM files simply indicate i386, which means they'll work on any processor from the 80386 upwards, including the 486, Pentium, Pentium II, and all subsequent Intel, AMD, IBM, and other improvements.

Note 

SUSE produces a version of SUSE Linux that is optimized for the new 64-bit range of chips, such as the AMD Athlon 64. Unfortunately, RPM files compiled for use on these chips won't work on 32-bit systems, which includes the majority of computers in use today. Such files are usually marked with an x86_64 extension.

If you attempt to download an RPM file from an unofficial source, it's very likely the filename will indicate the Linux distribution it's designed to work with, too. For example, fc2 indicates that an RPM file is designed to work on Fedora Core 2. In the case of SUSE Linux, you might find suse91 added to the RPM filename. Alas, there are no rules regarding the naming of RPM files. Understanding the filenames is usually a case of applying common sense and understanding the conventions outlined here.

Tracking down RPM files for your specific distribution can sometimes be difficult, and you might be tempted to install one designed for a different Linux distribution. The question arises as to whether these will work. To answer this, you need to bear in mind that an RPM is more than just a collection of program files waiting to be installed. RPM files are able to change your current system configuration, too. Additionally, the RPM system can both delete and create files practically anywhere on your hard drive. Each RPM is tailored to an individual system. Not all distributions install day-to-day binary program files in the same location, as just one example, and this can cause obvious problems if an RPM is used on an incompatible system.

In many cases, you might find that an RPM for a different distribution from yours will seem to install correctly. However, it might not work. Because of this, if you cannot track down an RPM file for your distribution, the best solution is to compile from source, as discussed later in this chapter.

Using YaST at the Command Line

SUSE's officially prescribed way of installing an RPM at the shell is to use the following command (which, as with all these package installation commands, must be run as root):

yast -i mozilla-1.6-72.i586.rpm 

This invokes the shell version of YaST2, YaST, to install the program, and the RPM file is expected to be in the directory from which the command is run. This simply installs the file without first checking for dependencies, so it's not a very good way to install software.

Specifying just a program name means that YaST will look to the DVD-ROM archive for the program. For example, typing the following:

yast –i mozilla

will cause YaST to try to install the RPM called Mozilla on the DVD-ROM, as shown in Figure 29-5. As with running YaST2 in GUI mode, this will also resolve any dependencies, so that everything you need will be automatically installed.

Figure 29-5. Installing programs at the command prompt can be done via YaST.

Because using YaST2 in this way is virtually identical to using the program in GUI mode, there's no real advantage to be had from running the program in command-line mode. Additionally, there are other clear disadvantages to using YaST2 for command-line program installation. For example, there's an almost complete lack of feedback, meaning that it can be hard to see whether something has worked or not.

In order to install at the command-line prompt, it's a much better idea to use the rpm command, as described next.

Using the rpm Command

The single rpm command administers practically the entire RPM system. However, it's never used on its own and is controlled by various command-line options. Consider the following example:

rpm -i mozilla-1.6-72.i586.rpm

The -i command option is used to tell the rpm command to install the specified file. If you're updating a file, you can use the -U option instead. In fact, using -U all the time is a good idea because, if the program isn't installed, rpm is clever enough to realize and will install the program instead.

You can try this yourself. You'll find the RPM for the Firefox web browser in the /suse/i586 directory of the SUSE installation DVD (remember that DVDs are usually mounted in the /media/dvd folder). You can use the following command to install it:

rpm -U /media/dvd/suse/i586/MozillaFirefox-0.8-44.i586.rpm 

The trouble with running this command is that it will go through the process of installing the file, but it will give little, if any, feedback or indication of progress. Because of this, many people add the -v and -h command options. The -v specifies verbose output, meaning that more information is fed back to the user. The -h option simply causes rpm to indicate its progress with a progress bar consisting of hash symbols. Figure 29-6 shows an example.

Figure 29-6. The rpm command offers all the power you need to install software on SUSE Linux.

Putting all this together, the standard command issued to install a program takes the following form (for the Firefox example):

rpm -Uvh MozillaFirefox-0.8-44.i586.rpm

After each installation, under SUSE Linux, you should run the following command:

SuSEconfig 

This will register the new program with any necessary background services and also update any necessary configuration files. Because of this, it's a good idea to run the SuSEconfig program (discussed in Chapter 13) each time you use rpm. Note that this is specific to SUSE Linux and isn't necessary on other distributions.

RPM Security

When installing programs, it's vital that some mechanism exists to prove that the RPM files utilized are genuine. By its very nature, open-source software is open to abuse. A nefarious individual could alter the source code of a program, implanting something such as a trojan routine that could steal data. After inserting the code, he could then compile and package the file as if it were the genuine article provided by SUSE. The simplest defense is to make sure that you download only from web sites you can trust, such as that of SUSE itself. However, you can also make use of the RPM GPG key system.

Every officially released RPM file from SUSE is signed with a GNU Privacy Guard (GPG) hashcode. This hash-code is unique to each file and is generated based on the contents of the RPM using a so-called secret key, which only SUSE knows. All secret keys have public key counterparts, and the SUSE RPM public key is added by default to all SUSE Linux installations. The public key can be used to confirm that the hashcode is correct, based on the contents of the file. This allows for a high degree of security.

RPM files also contain checksums that can be used to confirm that the file is complete and not missing files, or that it doesn't contain altered files. Checksums are the results of mathematical formulas applied to the file. If the file changes in any way, no matter how small, then the checksum will change, too.

To check any kind of RPM file for both checksum and GPG hashcodes, type the following:

rpm --checksig filename.rpm 

The results should read OK for each category. Of course, this depends on whether the GPG public key from the organization that created the RPM file is known to your system. If it's not, then you will see an error.

You can import public keys from trusted online sources using the following command:

rpm --import ftp://mysite.com/publickey

Ordinarily, the key is imported directly from an online source, such as an FTP server, although it can also be from a text file on your own hard disk. But, once again, this file must be from a trusted source. If you intend to use a new online RPM file archive, for example, you should ensure you use the key offered on its server. You certainly cannot assume that a site you stumble across using a search engine will contain an authentic public key for another download source.

For various reasons, both GPG and checksum signing of RPM files are imperfect forms of security and can be overcome by crackers. One simple way of confirming any kind of installation file's integrity, not only RPM files, is to use a separate program to check its md5sum checksum figure. For example, you could download an installation file from a third-party source, and then check its md5sum against a list held on a server you can trust. Using md5sum is easy. Just type this:

md5sum filename 

You should then compare the resulting figure to that contained in a list on an authentic server. These figures are usually contained in a text file called md5sums, or something similar. If the numbers are different, which is usually immediately apparent, this means that the file has been altered since the original checksum was created, and you should be suspicious.

Note that a different checksum doesn't necessarily mean a cracker has been at work. It might be that the file is simply corrupted, perhaps during download, for example. Often, simply downloading the file afresh solves the checksum problem.

Taking Care of Dependencies

If there are any problems with the installation of the program, the rpm command will let you know. The most common of these is the dreaded dependency failure, which occurs when additional software or libraries required by the program aren't present and therefore need to be installed, too.

For example, if you try to install the Epiphany web browser on the SUSE installation DVD, you receive the following error message:

error: Failed dependencies:   mozilla = 1.6 is needed by epiphany-1.0.7-64   libgtkembedmoz.so is needed by epiphany-1.0.7-64

The problem then becomes one of trying to track down the missing dependencies. In the case of Epiphany, the first one is easy enough to solve: you can list the directory specifying mozilla as a filter (using ls mozilla*) and see what comes up.

The best guess is that the main Mozilla program is what's needed. There's no rule for working this out; it just takes a little common sense. However, it's important to take note of the version number: 1.6. This is the lowest version of Mozilla that you can install in order to meet this particular dependency (version numbers later than that specified are usually okay, too).

The second dependency is more difficult to solve because its filename indicates that it's a library (it starts with lib and ends with an .so file extension). Library files are usually installed as part of a larger program or as part of a larger RPM containing many libraries. In most cases, it's very hard to find out if the RPM file in question contains the library file.

In such a situation, the quickest and easiest solution is to search the Web. For example, typing the library filename into the Google search box will bring up sites containing information about the library, as shown in Figure 29-7. By careful detective work examining and comparing the search results, you should be able to find out which RPM file on the DVD is likely to contain the library. If you do not get any joy after this, trying adding "RPM" to the search string as well.

Figure 29-7. When tracking down library dependencies, a good search engine like Google helps enormously.

Alternatively, if you have an archive of RPM files at your disposal, such as the SUSE installation DVD, you can query each of the RPM files in turn, looking at the files they contain, and searching for the library file. You can do this using the rpm command with the -q command option. The query command option is unusual because it has it own set of command options. Anything that appears after -q is considered a query option.

By default, -q queries installed RPM files (the main database). This is handy if you want to explore the list of installed programs (the -qa option will list all of the installed programs). To query an RPM file that's not installed, you need to add the -p command. Used together, the -qp options will merely tell you what program is contained within the specified RPM file— nothing more. You want a complete file listing, so add -l, and also -i, to return some additional information about the program contained in the file. Using all these command options together, plus specifying a wildcard so that all files are searched, and piping the command to less, you can create a scrollable list of files contained in every single RPM file in the archive:

rpm -qpli *.rpm |less 

After this, you can use the search function within less. For this example, press the forward slash key, /, and type libgtkembedmoz.so to find the library file. However, the list of files will be very long, and you might need to wait a minute or two for the entire set of files to be queried and the results piped into less.

Once the file is located in the output, it's simply a matter of scrolling through the list of files to find the name of the RPM that owns it. In our example, it turns out that it is Mozilla itself that installs this particular system file, so all that is necessary is to install Mozilla to take care of both dependencies.

Using Advanced RPM Techniques

As well as querying files, there are other advanced ways of using the rpm command. More than one file can be specified for installation at the same time, for example. In order to install Epiphany, as in the example in the previous section, two separate RPM files need to be installed: Mozilla and Epiphany itself. Therefore, you can simply specify them on the same command line, like this:

rpm -Uvh mozilla-1.6-72.i586.rpm epiphany-1.0.7-64.i586.rpm

It doesn't matter in which order you list the RPMs. The rpm command is clever enough to put everything in order and install the packages in the right sequence.

Uninstalling an installed RPM file is just as easy as installing one. Simply specify the -e command option, like so:

rpm -e mozilla

In most cases, this is quick and simple. Note that there's no need to specify anything other than the main program name, unless there are a number of programs on the system with similar filenames. If this is the case, rpm will prompt you for more information. You can grep the output of rpm -qa to search for the exact package name.

Once again, when uninstalling RPM packages, you can specify more than one RPM file on the command line in order to overcome dependency problems. This is useful because removing a program is just as prone to dependency problems as installing programs.

As with most shell commands, rpm has a very long and interesting man page. This is well worth reading in order to get a complete understanding of how package management works.