Overview of Class Two

by tor mohling
CU Boulder, dept of Computer Science

0 Contents

1 Introduction

Following the basic installation of a Unix-like Operating System there are possibly many customization or localization procedures that need to be performed. Exactly what is performed is either personal preference or determined by local site policy.

If you are installing a machine to operate in an existing environment, this process is often called localization because you alter system files and add custom software to get the new machine behaving properly in that local environment. At CSops we have prototype machines, one for each hardware+OS combination. When we install a new machine of a given type we immediately perform a localization procedure that basically copies the prototype machine's changes onto the newly installed box. I will talk a lot more about that in a later class covering large-scale , heterogenous computing environments.

1.1 OpenBSD Installation

This entire procedure is well documented at the OpenBSD website.

An excellent document to read for getting an overview of post-installation issues is the OpenBSD afterboot(8) manpage. The manpage lists each item and explains where to look for how to deal with it (i.e. what other manpages you'll need to reference). For example, from the manpage:

    Check hostname
     Use the hostname(1) command to verify that the name of
     your machine is correct.  See the man page for hostname
     if you need to change it.  You will also need to edit the
     /etc/myname file to have it stick around for the next reboot.
The description is succinct and tells you what you need to know, informing you about what manpage to read and what file(s) are important.

1.2 RedHat Linux Installation

This entire procedure is well documented at the RedHat website.

1.3 Adding Software

OpenBSD and RedHat Linux are at opposite ends of the spectrum when it comes to the default sofware accompanying the OS installation. RedHat installs a lot of extra software that you may or may not actually need, but often-times it is nice to have. OpenBSD on the other hand, by default, only installs the really important stuff that the OS and an administrator needs to keep the machine running smoothly. With either OS, if you want to install other software, like a new shell or a different window manager, the process is generally pretty easy.

For OpenBSD (and other BSDs) there are two ways to easily install lots of useful software. By far the simplest, if you have a fast network link or you have the Official CD sets, is to install from the binary packages, using the pkg_add(8) command. The alternative method makes use of the BSD Ports Collection and requires an active network link (in general).

RedHat Linux doesn't have anything like the Ports Collection (that I am aware of), but binary packages are readily available in the form of rpm archives. The rpm(8) command (RedHat Package Manager) is used to install these packages.

When all else fails, or even before if you're that sort of person, you can always download, compile and install software yourself! (We will look at this topic later in the semester as well.) One important reason to choose this option is security. The pkg_add(8) manpage states the problem thusly:

    Warning: Since the pkg_add command may execute scripts or
    programs contained within a package file, your system may
    be susceptible to `trojan horses' or other subtle attacks
    from miscreants who create dangerous packages.  Be sure the
    specified package(s) are from trusted sources.
Not that the problem is necessarily avoided by downloading sources and compiling + installing them without first reading through the code! It comes down to trusting the sites from whom you obtain your software.

2 Binary Packages in OpenBSD - pkg_add(8) and friends

Binary packages for OpenBSD are available from two primary sources. If you obtained a copy of the Official CD set, then one of the two CDs will have binary packages for your architecture (i386 is on CD1, and Sparc is on CD2). If you don't have a CD set available then you need to turn to one of the OpenBSD ftp mirror sites. We explore both of these alternatives.

Associated utilities:

Let's first assume you have a copy of the CD distribution and are using the PC platform. Insert the CD into the CDROM reader and mount it up:

    xbalanque% sudo mount -t cd9660 /dev/cd0c /mnt
(By the way, the CD is created in a format called ISO-9660; under OpenBSD you specify that with the -t cd9660 arguments; the cdrom device will generally be /dev/cd0c unless you have more than one (we'll look at what the device names mean in more detail in a future class); finally, the mountpoint is /mnt, which will also be explained in the future.)

To view what packages are available, cd onto the newly mounted CD. There are lots of files in the packages directory, so it is wise to narrow down what you list out so that most of it doesn't scroll off of your screen.

    xbalanque% cd /mnt/2.8/packages/i386
    xbalanque% ls b*
    base64-1.0.tgz             bitchx-1.0c17.tgz          bricons-3.0.tgz
    bash-2.04.tgz              bk2site-1.1.5.tgz          brs-4.00l1.tgz
    bclock-1.0.tgz             blackbox-0.61.0.tgz        buffer-1.17.1.tgz
    beav-1.40-13.tgz           blast-1.0.tgz              bulk_mailer-1.13.tgz
    bfbtester-1.0.tgz          bnetd-0.4.19.tgz           bvi-1.2.0.tgz
    bibview-2.2.tgz            bochs-2000_0325a.tgz       bytebench-3.1.tgz
    bind-9.0.0.tgz             boehm-gc-4.12.tgz          bzip2-1.0.1.tgz
    bing-1.0.4.tgz             bonnie-1.0.tgz
    bison-1.27.tgz             bounix-1.21.tgz

To add a package, simply use pkg_add with the package as an argument like so:

    xbalanque% sudo pkg_add bash-2.04.tgz

+--------------- | For proper use of bash-2.04 you should notify the system | that /usr/local/bin/bash is a valid shell by adding it to the | the file /etc/shells. If you are unfamiliar with this file | consult the shells(5) manual page +---------------

xbalanque% sudo vi /etc/shells ...

By default, output is not printed unless there are specific user instructions that should be followed (as there is in the example). Use the -v flag for more verbose output. Let's pkg_delete bash so we can re-add it with the verbose flag turned on.

    xbalanque% sudo pkg_delete bash-2.04
    sh: ./+DEINSTALL: No such file or directory
    pkg_delete: deinstall script returned error status
Ouch! What just happened? It turns out the de-install script (living in /var/db/pkg/bash-2.04/+DEINSTALL ) has an incorrect path to the shell interpreter - doh! It is a simple enough matter to edit the script and fix the path..

    xbalanque% sudo vi bash-2.04/+DEINSTALL
    xbalanque% sudo pkg_delete bash-2.04

+--------------- | To completely deinstall the bash-2.04 package you need to edit | /etc/shells and remove this line: | | /usr/local/bin/bash | +---------------

Now we get the message that we should remove bash from the /etc/shells file, but I'm going to ignore it since we are adding bash back to the system again anyhow. (By the way, this is the only BSD package I have encountered that was actually broken like this - but then again I don't normally run pkg_delete either :) Let's re-add bash:

    xbalanque% sudo pkg_add -v bash-2.04.tgz
    Requested space: 4000624 bytes, free space: 55022592 bytes
     in /var/tmp/instmp.mBTNHc8545
    Running install with PRE-INSTALL for `bash-2.04'
    extract: Package name is bash-2.04
    extract: CWD to /usr/local
    extract: /usr/local/bin/bash
    extract: /usr/local/bin/bashbug
    extract: /usr/local/man/man1/bash.1
    extract: /usr/local/man/man1/bashbug.1
    extract: /usr/local/info/bash.info
    extract: execute 'install-info  /usr/local/info/bash.info
    extract: /usr/local/share/doc/bash/article.ps
    extract: /usr/local/share/doc/bash/article.txt
    extract: /usr/local/share/doc/bash/bash.html
    extract: /usr/local/share/doc/bash/bash.ps
    extract: /usr/local/share/doc/bash/bashbug.ps
    extract: /usr/local/share/doc/bash/bashref.html
    extract: /usr/local/share/doc/bash/bashref.ps
    extract: /usr/local/share/doc/bash/builtins.ps
    extract: /usr/local/share/doc/bash/readline.ps
    extract: CWD to .
    Running install with POST-INSTALL for `bash-2.04'
    Attempting to record package into `/var/db/pkg/bash-2.04'
    Package `bash-2.04' registered in `/var/db/pkg/bash-2.04'
The verbose output gives a lot of useful information about the package, and about packages in general. In particular,

We'll explore the package contents and structure a bit more below. For now, let's get out of the package directory on the CDROM and un-mount it.

    xbalanque% cd /
    xbalanque% sudo umount /mnt
Now we consider adding packages by FTP'ing them from one of the OpenBSD mirror sites. See: http://www.openbsd.org/ftp.html for a list of available sites. There happens to be one here locally in the CS department, so I'll be using that one. Now there are several ways to proceed, so let's look at each in turn.

First, you can simply FTP the packages and then run pkg_add on them. For example,

    xbalanque% ftp -a anonopenbsd.cs.colorado.edu
    Connected to anonopenbsd.cs.colorado.edu.
    220 anonopenbsd.cs.colorado.edu FTP server (Version 6.5/OpenBSD) ready.

ftp> cd /pub/OpenBSD/2.8/packages/i386

ftp> get angband-2.9.1.tgz local: angband-2.9.1.tgz remote: angband-2.9.1.tgz 229 Entering Extended Passive Mode (|||3476|) 150 Opening BINARY mode data connection for 'angband-2.9.1.tgz' (486624 bytes). 100% |**************************************************| 475 KB 00:17 226 Transfer complete. 486624 bytes received in 17.70 seconds (26.85 KB/s)

ftp> quit

Second, you can specify the entire ftp URL one the pkg_add command-line:

    xbalanque% sudo pkg_add ftp://anonopenbsd/pub/OpenBSD/2.8/packages/i386/angband-2.9.1.tgz
    >>> ftp -o - ftp://anonopenbsd/pub/OpenBSD/2.8/packages/i386/angband-2.9.1.tgz
That's nice, because it is all done with a single command-line. The problem, though is that it is a wicked, long command line to type every time you add a package. One solution is to create a shell variable with the FTP site prefix. To illustrate, I will use pkg_info command to get the long-description (with the -d flag) for the above package:

    xbalanque% set ftp_site='ftp://anonopenbsd/pub/OpenBSD/2.8/packages/i386'
    xbalanque% pkg_info -d ${ftp_site}/angband-2.9.1.tgz
    >>> ftp -o - ftp://anonopenbsd/pub/OpenBSD/2.8/packages/i386/angband-2.9.1.tgz
    Information for ftp://anonopenbsd/pub/OpenBSD/2.8/packages/i386//angband-2.9.1.tgz:

Description: Angband is a "graphical" dungeon adventure game in the vein of "rogue", "hack", "nethack", and "moria".

There are some ascii "on line help" files in /usr/local/share/angband/help

WWW: http://thangorodrim.angband.org/

Another solution is to run pkg_add directly from an ftp session. Details for that process are given in the manpage.

Now let's download another package and examine its contents instead of installing it. Following the procedure above, I FTP downloaded a package called nmap-2.54b6.tgz. Nmap is a portscanner that we will examine closely when we talk about network security.

The first thing to point out again is the suffix .tgz that indicates a gzip-compressed tar archive. This is one thing that I really like about BSD packages: they are just tar archive, so it is very easy to examine or unpack them without any special utilities. For example, you can simply view the tar-archive's table of contents:

    xbalanque% tar ztvf nmap-2.54b6.tgz
    -rw-r--r--  1 root     wheel        642 Oct 30 15:03 +CONTENTS
    -rw-r--r--  1 root     wheel         29 Oct 30 15:03 +COMMENT
    -rw-r--r--  1 root     wheel       1600 Oct 30 15:03 +DESC
    -r-xr-xr-x  1 root     bin       155648 Oct 30 15:03 bin/nmap
    -r--r--r--  1 root     bin        35643 Oct 30 15:03 man/man1/nmap.1
    -r--r--r--  1 root     bin       215182 Oct 30 15:03 share/nmap/nmap-os-fingerpr
    -r--r--r--  1 root     bin         8097 Oct 30 15:03 share/nmap/nmap-protocols
    -r--r--r--  1 root     bin         9054 Oct 30 15:03 share/nmap/nmap-rpc
    -r--r--r--  1 root     bin        95602 Oct 30 15:03 share/nmap/nmap-services
Note that the tar command provided by BSD and Linux supports the z flag allowing automatic use of gzip for [de-]compression. For versions of `tar' that don't support this feature you'll have to decompress first in a pipeline like this:

    % gzip -cd nmap-2.54b6.tgz | tar -tvf -
On the topic of tarballs (i.e. tar archives) it is always a good idea to look at the archive's table-of-contents as I just demonstrated above; although this doesn't necessarily apply to the BSD package archives we're talking about here. The reason is that you should examine the files to see if they are referenced as absolute paths (i.e. with a leading / character) or not. When un-tarring an archive as root this can have dangerous consequences. What would happen if the archive contained a bogus /etc/ipf.rules file? More about `tar' below in the Ports section.

At any rate, we can un-tar our nmap package in a temporary directory and look at some of the files held therein. This particular package is extremely simple, in fact it doesn't even have an install script. This just means that all the package's files are simply copied into place; no special work needs to be done before or after this process.

    xbalanque% mkdir tmpdir
    xbalanque% cd !$
    cd tmpdir
    xbalanque% tar zxf ../nmap-2.54b6.tgz
The +COMMENT file is a one-line description of the package while the +DESC file has the long description. The +CONTENTS file is more interesting:

    xbalanque% cat +CONTENTS 
    @name nmap-2.54b6
    @cwd /usr/local
    @src /usr/ports/net/nmap/work/fake-i386/usr/local
    @comment $OpenBSD: PLIST,v 1.7 2000/08/05 00:12:45 fgsch Exp $
    @comment MD5:d57f9b6b2bffe75325bfd6f7af05c10e
    @comment MD5:f20a928c60333d30e3039aff14ed1671
    @comment MD5:d326b9c8d9eace021f0a0e0c6b230e39
    @comment MD5:dc93082d8b5aaae469e3884f5962df52
    @comment MD5:c0b3826880e8d1c79743f01ed291e72b
    @comment MD5:3b63698490f944552cde9ea30e7d0a54
    @dirrm share/nmap
    @comment name=net/nmap/nmap-2.54b6
    @cwd .
You can see that this file has the information necessary to correctly install this package. In particular we have the target base base directory given on the @cwd line. Notice also that MD5 checksums are given for each filein the archive. The checksums are used to verify the integriy of each file.

The pkg_info(1) command can instead be used to get at most of the information you might want to glean from a package file, except for the data itself (i.e. binaries or manpages). For example, the -i flag will cause the install script for the package to be printed, if one exists:

    xbalanque% pkg_info -i bash-2.04.tgz 
    Information for bash-2.04.tgz:

Install script: #!/bin/sh # $OpenBSD: INSTALL,v 1.2 2000/07/04 21:26:17 brad Exp $ # # Pre/post-installation setup of bash ...

Read the manpages for more details!

    + READ: *pkg_add(1)*  *pkg_delete(1)*  *pkg_info(1)*

3 The BSD Ports Collection

The way to get start with the ports collection, especially if you don't have the CD media, is to download the ports tarball from an OpenBSD anonymous FTP site:

    coatlicue% cd /tmp
    coatlicue% ftp -a anonopenbsd.cs.colorado.edu
    Connected to anonopenbsd.cs.colorado.edu.
    220 anonopenbsd.cs.colorado.edu FTP server (Version 6.4/OpenBSD) ready.
    331 Guest login ok, type your name as password.
    [ ... intro text deleted ... ]
    230 Guest login ok, access restrictions apply.
    Remote system type is UNIX.
    Using binary mode to transfer files.
    ftp> cd pub/OpenBSD/2.6
    250 CWD command successful.
    ftp> get ports.tar.gz
    local: ports.tar.gz remote: ports.tar.gz
    227 Entering Passive Mode (128,138,192,84,144,190)
    100% |**************************************************|  2071 KB    00:00 ETA
    226 Transfer complete.
    2120804 bytes received in 77.25 seconds (26.81 KB/s)
    ftp> quit
    221 Goodbye.
Once you have the ports.tar.gz tarball, you unzip and untar it in the /usr directory of your (OpenBSD) system.

The tar command (Tape Archiver) was originally written for archiving files to magnetic tape. The command still defaults to trying to access an (often non-existant) tape-drive. The -f <filename> arguments to tar tell it to access the named file instead. The file has the exact same format that a tarball on magnetic tape would have, and it is not a text file or something you would want to edit with vi or whatever.

Here is an example of looking at the table-of-contents for the ports tarball:

    coatlicue% tar -ztvf ports.tar.gz | more
    drwxr-xr-x  2 root     wheel          0 Oct 23 12:00 ports
    drwxr-xr-x  2 root     wheel          0 Oct 23 12:00 ports/CVS
    -rw-r--r--  1 root     wheel          6 Oct 22 11:10 ports/CVS/Repository
    -rw-r--r--  1 root     wheel        674 Oct 23 12:00 ports/CVS/Entries
    -rw-r--r--  1 root     wheel         10 Nov 24  1997 ports/.cvsignore
    -rw-r--r--  1 root     wheel      95884 Oct 15 17:05 ports/INDEX
    -rw-r--r--  1 root     wheel      27465 Oct  8 19:24 ports/LICENSE
    -rw-r--r--  1 root     wheel       1490 Jul 27  1999 ports/Makefile
    -rw-r--r--  1 root     wheel      13676 Oct  7 10:44 ports/README
    -rwxr-xr-x  1 root     wheel       3302 Sep 24  1998 ports/license-check
    drwxr-xr-x  2 root     wheel          0 Oct 23 11:49 ports/archivers
    drwxr-xr-x  2 root     wheel          0 Oct 23 12:00 ports/archivers/CVS
Notice that it looks a whole lot like the output of ls -l ! One very important thing to check when you untar an archive is to make sure that the files being untarred do not start at the root of the filesystem (i.e. with a leading / ). Sometimes you could be untarring a trojan-horse tarball that, perhaps, over-writes your /etc/inetd.conf or /root/.rhosts files or whatever. It is always wise to do a table-of-contents check before you ever untar an archive when you are root or using sudo !

Anyhow.. Once you verify how the tarball will untar itself, in this case, you must move into the /usr directory to untar it. The -x flag is used to extract an archive:

    coatlicue% sudo -v
    coatlicue% sudo tar -zxf /tmp/ports.tar.gz 
Now let's change into the newly created /usr/ports directory and have a look:

    coatlicue % cd ports
    coatlicue % ls
    CVS/            benchmarks/     editors/        mail/           russian/
    INDEX           cad/            emulators/      math/           security/
    LICENSE         chinese/        games/          mbone/          shells/
    Makefile        comms/          graphics/       misc/           sysutils/
    README          converters/     infrastructure/ net/            textproc/
    archivers/      databases/      japanese/       news/           www/
    astro/          devel/          lang/           plan9/          x11/
    audio/          distfiles/      license-check*  print/
You can see directories for lots of different software categories. To install a desired software package, simple cd into the relevant directory and run make install . The Makefile for each package has been set up to automatically FTP the source for the package and then compile it. Here is an example:

    coatlicue% cd security/portscanner/
    coatlicue% sudo make install
    >> PortScanner-1.0.tar.gz doesn't seem to exist on this system.
    >> Attempting to fetch from http://www.ameth.org/~veilleux/.
    Requesting http://www.ameth.org/~veilleux/PortScanner-1.0.tar.gz
    100% |**************************************************|  1791       00:00 ETA
    Successfully retrieved file.
    >> Checksum OK for PortScanner-1.0.tar.gz. (SHA1)
    ===>  Extracting for portscanner-1.0
    ===>  Patching for portscanner-1.0
    ===>  Configuring for portscanner-1.0
    ===>  Building for portscanner-1.0
    ===>  Installing for portscanner-1.0
    ===>  Registering installation for portscanner-1.0
Pretty simple.

In both the pkg_add case as well as the OpenBSD ports collection, commands and manpages tend to get installed in "normal" places. E.g. /usr/bin or /usr/local/bin and /usr/man or whatever. To know exactly what's going on, you would have to explore the specific package: look at the source code and makefiles.

The Ports Collection offers a whole mess of useful features beyond just make and make install. Definately read the ports(7) manpage for all the grizzly details. Also suggested reading is the /usr/ports/README file that can only be viewed after you unpack the ports archive (or on saclass.cs.colorado.edu ). Many of the features are used by selecting specific make targets in the base ( /usr/ports ) directory. Before I really get going with the ports tree, I like to chown(8) the entire archive to my own UID. That way I don't have to use sudo until the final `make install'.

    xbalanque% sudo chown -R tor ports
    xbalanque% cd ports
One useful `make target' is index which builds searchable index files. You use the target search with an associated key to search the index.

    xbalanque% make index
    Generating INDEX...
    ===> archivers
    ===> archivers/arc

xbalanque% make search key=portscan Port: portscanner-1.0 Path: security/portscanner Info: simple and easy to use TCP port scanner Maint: Brad Smith <brad@openbsd.org> Index: security B-deps: R-deps: Archs: any

There are other ways to search the indexes, read the ports(7) manpage for details. Another fun target is readmes which generates .html readme files throughout the archive: you can then browse the archive with Netscape or whatever. And finally, packages that can be added (to other machines) with pkg_add can be created by using the package target in the appropriate sub-directory.

4 Binary Packages in RedHat Linux - rpm(8)

RedHat uses a package management system called RPM . The term `rpm' denotes two things. First, it is the name of the source or binary archive file that contains all of the necessary information to install a given software package. The archive is kind of like a tarball in that it is a compressed compilation of more than one actual unix file. These archive files are simply called rpm packages. In fact, rpm packages can be unpacked, but the process is a little more involved. We'll look at that below.

Second, rpm is the name of the command used to create, install, upgrade or remove the rpm-packages; it is a complicated command with many, many flags and argument options.

The RPM system maintains a database in /var/lib/rpm about the status of each RPM package installed on the system. Unfortunately, these datafiles are not text files and you can't just browse them with less or grep.

One way to get new RPM packages is to go to the RedHat website, See: http://www.redhat.com/ and perform a search to find the specific RPMs. For example, if I were looking for an SSH package for a PC, I would use the following search criteria:

    rpm ssh i386
That will bring up a list of links that you must navigate through to then find the RPM. This method is somewhat tedious. A much better choice is to see: http://freshmeat.net/ and do your search there! The links you get here are way more useful. Try just searching for ssh . The freshmeat.net site has much more than just RedHat RPM's - you can find pointers to most any software package you can think of, in a source form that is, or could be, ported to a particular target hardware+OS combination. Another way to get RPMs is with the rpmfind command, see: http://rpmfind.net/ for details.

Once you download an RPM package, say for example, ssh-1.2.27-7us.i386.rpm , the actual installation is easy:

    saclass-4 % sudo rpm -i ssh-1.2.27-7us.i386.rpm
    saclass-4 %
RedHat-7.0 now comes with SSH (Yeah! this is due to the recent RSA patent expiration/change-of-status) so that example isn't so useful.. unless you happen to be installing a Sparc in which case you are stuck with RedHat-6.2 and thus you must also install SSH. sigh.

One command I insist on having that is not installed is sudo so let's install that. It does come as an RPM file on the CD set though, so we can mount that up. The default installation includes an entry for the CDROM in the /etc/fstab file (we'll discuss that file later in the course). The result of that, though, is it is quite easy to mount CDs:

    xibalba % mount /mnt/cdrom
    xibalba % cd !$/RedHat/RPMS
    cd /mnt/cdrom/RedHat/RPMS
Let's demonstrate some of the querying capabilities of the rpm command. Querying options must be preceded by the -q flag. You use -p to specify a specific RPM package file to be queried (the default queries the database of installed packages). Use the -l query option to get a listing of files included in the package.

    xibalba % rpm -q -l -p sudo-1.6.3-4.i386.rpm 
A perhaps more useful flag is -i which simply queries for the standard information about the package. (Note well that this -i is totally different from the install -i option shown above; the context is different in that it follows the -q* flag.)

    xibalba % rpm -q -i -p sudo-1.6.3-4.i386.rpm
    Name        : sudo                         Relocations: (not relocateable)
    Version     : 1.6.3                             Vendor: Red Hat, Inc.
    Release     : 4                             Build Date: Wed 12 Jul 2000 07:31:13 PM MDT
    Install date: (not installed)               Build Host: porky.devel.redhat.com
    Group       : Applications/System           Source RPM: sudo-1.6.3-4.src.rpm
    Size        : 298776                           License: BSD
    Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
    URL         : http://www.courtesan.com/sudo/
    Summary     : Allows restricted root access for specified users.
    Description :
    Sudo (superuser do) allows a system administrator to give certain
    users (or groups of users) the ability to run some (or all) commands
    as root while logging all commands and arguments. Sudo operates on a
    per-command basis.  It is not a replacement for the shell.  Features
    include: the ability to restrict what commands a user may run on a
    per-host basis, copious logging of each command (providing a clear
    audit trail of who did what), a configurable timeout of the sudo
    command, and the ability to use the same configuration file (sudoers)
    on many different machines.
Another useful query feature is the -f option which requires a pathname as an argument. You can use this to find out from what RPM package a particular file came. (This, of course, involves querying the database of already-installed packages.)

    xibalba % rpm -q -f /etc/passwd
Cool! That can be really useful. (In conjunction with a subsequent invocation of rpm using a verify option you can see if a specific file has been corrupted.)

There are very many query options, including the ability to format what the output you get looks like. Here is one final example that is reminiscent of the `pkg_info' example from above. We can use rpm to list out the install script used by the package if one exists:

    xibalba % rpm -q --scripts -p tcsh-6.09-6.i386.rpm 
    postinstall script (through /bin/sh):
    if [ ! -f /etc/shells ]; then
        echo "/bin/tcsh" >> /etc/shells
        echo "/bin/csh" >> /etc/shells
        grep '^/bin/tcsh$' /etc/shells > /dev/null || echo "/bin/tcsh" >> /etc/shells
        grep '^/bin/csh$' /etc/shells > /dev/null || echo "/bin/csh" >> /etc/shells
    postuninstall script (through /bin/sh):
    if [ ! -x /bin/tcsh ]; then
        grep -v '^/bin/tcsh$' /etc/shells | grep -v '^/bin/csh$'> /etc/shells.rpm
        mv /etc/shells.rpm /etc/shells

The rpm command also offers a facility for verifying the integrity of installed files. Typically, there are a number of options that modify the default behavior. The process of verification involves comparing a newly computed MD5 checksum of each file with a stored checksum value from the original installation of the package. In its simplest form:

    xibalba % rpm -V sudo
    S.5....T c /etc/sudoers
Only files that don't match in some fashion are listed. Eight checks are performed, and the specific failures are denoted by characters other than a dot. In this case, file-size, mod-time and MD5 sum were different. The reason for that is obvious: the /etc/sudoers file gets edited to add new users (e.g. me) almost immediately.

Finally, let's look at how we can unpack an RPM package without actually installing it. To do this, we use the rpm2cpio(8) command to convert the RPM package into a cpio archive, and then use cpio(1) to extract it. Cpio is similar to `tar', only different. Here is an example:

    schwinn % cp sudo-1.6.3-4.i386.rpm /tmp
    schwinn % cd /tmp
    schwinn % rpm2cpio sudo-1.6.3-4.i386.rpm | cpio --extract -d
    574 blocks
The --extract argument is hopefully obvious. The -d flag tells `cpio' to create directories as necessary. The archive will be unpacked relative to your current directory. (However, recall the discussion about `tar' and absolute-paths? The same argument applies here, and it is wise to examine the listing of the archive before unpacking.)

Go to: top / index

Source document: class02.txt
Last modified: 0
Category: guide