Recipe 1.1 Downloading the Latest Release
ProblemYou must keep your sendmail software up-to-date. SolutionSticking with the standard software management method used on your system is the easiest way to upgrade sendmail. If you use a package manager, go to your Unix vendor's web site, download the appropriately packaged sendmail update, and install it using the package manager. If the vendor cannot provide a critical sendmail update or does not provide the compiled-in features you need, and you decide to use the sendmail source code distribution, gracefully transition from the package manager to the source code distribution by following the Unix vendor's advice on how to remove a package that was installed by the package manager. Recipe 1.1.3 shows an example of using the Red Hat Package Manager to remove the sendmail RPM before the sendmail source code distribution is installed. If you need to use the sendmail source code distribution, download the latest version of sendmail from ftp://ftp.sendmail.org/, from http://www.sendmail.org/current-release.html, or from one of a large number of mirror sites. A link to the mirror sites is found on the http://www.sendmail.org/ home page. The Discussion section provides an example of downloading the sendmail source code distribution via ftp . Get the signature file associated with the version of sendmail you downloaded. For example, the signature file for the sendmail.8.12.9.tar.gz tarball downloaded in the Discussion section is sendmail.8.12.9.tar.gz.sig . Download the PGP keys needed to verify the signature, and add them to your key ring (you only need to do this approximately once a year). After the PGP keys are added to your key ring, they can be used to verify the signature file of any further downloads made during that calendar year. Use the pgp or gpg programs to verify the signature of the downloaded file (the Discussion section shows an example using gpg ). If you accept the signature, restore the sendmail distribution tarball file. Discussionsendmail changes frequently. When the first draft of this chapter was written, the latest release of sendmail was about 3 weeks old, and the previous release was only 11 weeks old! Does this mean you must upgrade sendmail every few months? Not at all. Yet you should keep track of new sendmail releases in order to determine when upgrading is important to you. Three reasons that system administrators choose to upgrade are:
Of these three reasons for upgrading, security is the most important. If you know of a security problem, you can bet that the bad guys also know and are doing their best to exploit it. Close security holes as quickly as possible. Chapter 10 shows how sendmail can be patched to close security holes. Once you have decided to upgrade the sendmail software, you need to decide how you will do it. The easiest way to upgrade software is to use the software management tool provided with your version of Unix. A classic example of such a tool is the RPM Package Manager (RPM) that was developed by Red Hat and is used in many different Linux distributions. Tools like RPM install software packages that have already been customized for a particular Unix variant, placing the files in the proper directories and relieving the administrator of the burden of compiling the software. These tools also provide security features, such as the --verify option of the rpm command, that check the software and files for tampering during and after the installation. When you want to upgrade to a new version of sendmail, check your Unix vendor's web site to see if it is available in their package format. [4]
Despite the benefits of software management tools, sometimes you need to compile your own software to enable special features, and sometimes the latest version of software is not available in a package format. If you must switch to the sendmail tarball on a system where the previous sendmail installation was done by a package manager, backup the current configuration and then uninstall the current version of sendmail using the package manager before you upgrade. The example shows how to uninstall sendmail using RPM: # service sendmail stop Shutting down sendmail: [ OK ] # rpm -qa grep sendmail sendmail-8.11.6-15 sendmail-cf-8.11.6-15 sendmail-devel-8.11.6-15 # rpm --erase sendmail-devel-8.11.6-15 # rpm --erase sendmail-cf-8.11.6-15 # rpm --erase --nodeps sendmail-8.11.6-15 warning: /etc/mail/statistics saved as /etc/mail/statistics.rpmsave This example is from a Red Hat 7.3 system. Start by shutting down the current sendmail daemon. Then use rpm -qa to find out which sendmail RPM packages are installed, and rpm --erase to remove each of the packages. Notice that the --nodeps option is used with the final rpm command. The --nodeps option forces rpm to erase the package, even if doing so breaks the dependencies of other packages. Removing the sendmail daemon, which is what the final rpm command does, breaks other packages that depend on the sendmail daemon. Once you install the new sendmail daemon, those packages should function again. However, the negative impact on dependencies, caused by switching from an RPM based installation to a tarball installation, is one reason why you should always try to upgrade an RPM installation with another RPM, if possible. Perform these steps to remove the currently installed sendmail after successfully compiling the new version of sendmail and before installing the newly created sendmail binaries. This uninstall step is necessary to prevent the package manager from falsely reporting errors when the package manager is used to scan the software for possible tampering. Caution should also be exercised when installing a vendor's sendmail package on a system that already has a custom sendmail configuration. As Recipe 1.2 to Recipe 1.7 show, sendmail can be compiled with special options; however, the vendor might not provide the options you need, and the vendor package might overwrite the specially compiled sendmail binary. Bottom line: take care whenever you transition from one installation technique to another. If you're not changing installation techniques, and you don't use a package manager, you don't need to be concerned with any of this before you proceed with installing the sendmail source code distribution ”you can just follow the steps that are discussed below. Begin by downloading the sendmail source code distribution from http://www.sendmail.org/current-release.html, from any of the mirror sites, or from ftp://ftp.sendmail.org/pub/sendmail/. Here is an example using ftp : $ ftp ftp.sendmail.org Connected to ftp.sendmail.org (209.246.26.22). 220 services.sendmail.org FTP server (Version 6.00LS) ready. Name (ftp.sendmail.org:alana): anonymous 331 Guest login ok, send your email address as password. Password: alana@rodent.wrotethebook.com 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd pub/sendmail 250 CWD command successful. ftp> get sendmail.8.12.9.tar.gz local: sendmail.8.12.9.tar.gz remote: sendmail.8.12.9.tar.gz 227 Entering Passive Mode (209,246,26,22,207,236) 150 Opening BINARY mode data connection for 'sendmail.8.12.9.tar.gz' (1886008 bytes). 226 Transfer complete. 1886008 bytes received in 10.1 secs (1.8e+02 Kbytes/sec) The new release is stored in the pub/sendmail directory as a compressed tarball under the name sendmail.release.tar.gz for those who use gzip and sendmail.release.tar.Z for those who use compress . In either case, release is the current numeric release number. For example, the release number at this writing is 8.12.9, so the gzipped tarball is named sendmail.8.12.9.tar.gz and the compressed tarball is named sendmail.8.12.9.tar.Z . Next, get the signature file associated with the version of sendmail you downloaded. For example, the signature file for sendmail.8.12.9.tar.gz is sendmail.8.12.9.tar.gz.sig . Here we download it during the same ftp session: ftp> get sendmail.8.12.9.tar.gz.sig local: sendmail.8.12.9.tar.gz.sig remote: sendmail.8.12.9.tar.gz.sig 227 Entering Passive Mode (209,246,26,22,207,238) 150 Opening BINARY mode data connection for 'sendmail.8.12.9.tar.gz.sig' (152 bytes). 226 Transfer complete. 152 bytes received in 0.00221 secs (67 Kbytes/sec) If you do not have the current sendmail PGP keys on your key ring, download the PGP keys needed to verify the signature. Here we add the following step to the ftp session to download the keys for the current year: ftp> get PGPKEYS local: PGPKEYS remote: PGPKEYS 227 Entering Passive Mode (209,246,26,22,207,239) 150 Opening BINARY mode data connection for 'PGPKEYS' (57704 bytes). 226 Transfer complete. 57704 bytes received in 0.491 secs (1.1e+02 Kbytes/sec) ftp> quit 221 Goodbye. Add the PGP keys to your key ring. In the following example, gpg (Gnu Privacy Guard) is used: $ gpg --import PGPKEYS gpg: key 16F4CCE9: not changed gpg: key 396F0789: public key imported gpg: key 678C0A03: not changed gpg: key CC374F2D: not changed gpg: key E35C5635: not changed gpg: key A39BA655: not changed gpg: key D432E19D: not changed gpg: key 12D3461D: not changed gpg: key BF7BA421: not changed gpg: key A00E1563: non exportable signature (class 10) - skipped gpg: key A00E1563: not changed gpg: key 22327A01: not changed gpg: Total number processed: 11 gpg: imported: 1 (RSA: 1) gpg: unchanged: 10 gpg is used in this example because it is included as part of the Red Hat Linux distribution used on our sample sendmail system. Of the 11 exportable keys in the PGPKEYS file, only one is imported to our key ring. The not changed comment for the other 10 keys shows that they were already installed on the key ring. The first time you import PGPKEYS , all 11 keys will be added to the key ring. Before using the new key, verify its fingerprint , as shown here: $ gpg --fingerprint 396F0789 pub 1024R/396F0789 2003-01-15 Sendmail Signing Key/2003 <sendmail@Sendmail.ORG> Key fingerprint = C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F Compare the displayed fingerprint against Table 1-1 that shows sendmail's signing key fingerprints . Table 1-1. sendmail signing key fingerprints
If the fingerprint is correct, you can sign, and thus validate, the key. In this gpg example, we sign the newly imported sendmail key: $ gpg --edit-key 396F0789 gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: checking the trustdb gpg: checking at depth 0 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1 pub 1024R/396F0789 created: 2003-01-15 expires: never trust: -/- (1). Sendmail Signing Key/2003 <sendmail@Sendmail.ORG> Command> sign pub 1024R/396F0789 created: 2003-01-15 expires: never trust: -/- Fingerprint: C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F Sendmail Signing Key/2003 <sendmail@Sendmail.ORG> How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don't know what to answer, enter "0". (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking. Your selection? 3 Are you really sure that you want to sign this key with your key: "Craig Hunt <craig.hunt@wrotethebook.com>" I have checked this key very carefully. Really sign? y You need a passphrase to unlock the secret key for user: "Craig Hunt <craig.hunt@wrotethebook.com>" 1024-bit DSA key, ID 34C9B515, created 2003-07-23 Command> quit Save changes? y Remember, it is not necessary to download and import the PGPKEYS file every time you download a new sendmail release. New keys are only added to the PGPKEYS file about once a year. After the sendmail keys have been added to the key ring and signed, you can verify the sendmail distribution tarball. Here we use the sendmail.8.12.9.tar.gz.sig signature file to verify the sendmail.8.12.9.tar.gz compressed tarball: [5]
$ gpg --verify sendmail.8.12.9.tar.gz.sig sendmail.8.12.9.tar.gz gpg: Signature made Sat 29 Mar 2003 09:12:38 AM EST using RSA key ID 396F0789 gpg: Good signature from "Sendmail Signing Key/2003 <sendmail@Sendmail.ORG>" gpg: checking the trustdb gpg: checking at depth 0 signed=1 ot(-/q/n/m/f/u)=0/0/0/0/0/1 gpg: checking at depth 1 signed=0 ot(-/q/n/m/f/u)=1/0/0/0/0/0 Based on this, the distribution can be safely restored, compiled, and installed. Use tar to restore the tarball. The tarball creates a directory with a name derived from the sendmail release number. Therefore the following commands create a directory named sendmail-8.12.9 in /usr/local/src : # cd /usr/local/src # tar -zxvf /home/craig/sendmail.8.12.9.tar.gz The path /usr/local/src/sendmail-8.12.9 is used throughout this book. When implementing the recipes, adjust this path as appropriate for your system. See AlsoRecipe 10.4 provides a detailed example of downloading and installing sendmail patches, which are sometimes used as an alternative to downloading a full distribution. sendmail , Third Edition, by Bryan Costales with Eric Allman (O'Reilly), covers downloading the sendmail source distribution in Section 2.2. PGP: Pretty Good Privacy , by Simson Garfinkel (O'Reilly), is a full book about PGP. The GNU Privacy Handbook (GPH) , which is available at http://www.gnupg.org/gph/, provides detailed information about GPG. |
