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.
This entire procedure is well documented at the OpenBSD website.
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.
This entire procedure is well documented at the RedHat website.
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.
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:
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
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
/usr/local/info/dir'
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'
xbalanque%
The verbose output gives a lot of useful information about the
package, and about packages in general. In particular,
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
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
xbalanque%
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
ints
-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
xbalanque%
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 $
bin/nmap
@comment MD5:d57f9b6b2bffe75325bfd6f7af05c10e
man/man1/nmap.1
@comment MD5:f20a928c60333d30e3039aff14ed1671
share/nmap/nmap-os-fingerprints
@comment MD5:d326b9c8d9eace021f0a0e0c6b230e39
share/nmap/nmap-protocols
@comment MD5:dc93082d8b5aaae469e3884f5962df52
share/nmap/nmap-rpc
@comment MD5:c0b3826880e8d1c79743f01ed291e72b
share/nmap/nmap-services
@comment MD5:3b63698490f944552cde9ea30e7d0a54
@dirrm share/nmap
@comment name=net/nmap/nmap-2.54b6
@cwd .
@ignore
+COMMENT
@ignore
+DESC
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)*
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.
coatlicue%
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.
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
coatlicue%
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
Password:
>> 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
coatlicue%
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.
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
/etc/pam.d/sudo
/etc/sudoers
/usr/bin/sudo
/usr/sbin/visudo
/usr/share/doc/sudo-1.6.3
...
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
setup-2.3.4-1
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
else
grep '^/bin/tcsh$' /etc/shells > /dev/null || echo "/bin/tcsh" >> /etc/shells
grep '^/bin/csh$' /etc/shells > /dev/null || echo "/bin/csh" >> /etc/shells
fi
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
fi
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.)