|
|
2.6 Install sendmailThere are two approaches to installing a new sendmail:
After you have compiled sendmail (and if the configuration file is ready and tested), you can install it as your production version. If you are already running a sendmail and will be overwriting that binary, you will need to kill that version first (Section 1.7.1.2). 2.6.1 Pre-V8.12 InstallationFor versions prior to V8.12, installing sendmail looks like this: # ./Build -n install You use -n to be sure that the installation caused is, in fact, correct for your site. A typical such run, for example, might look like this: Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=
Making in ../obj.SunOS.4.1.4.sun4/sendmail
if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi
install -c -o bin -g bin -m 444 helpfile /etc/mail/helpfile
if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi
install -c -o root -g bin -m 644 statistics /etc/mail/statistics
install -c -o root -g bin -m 4555 sendmail /usr/lib
for i in /usr/ucb/newaliases /usr/ucb/mailq /usr/ucb/hoststat /usr/ucb/purgestat; do \
rm -f $i; \
ln -s /usr/lib/sendmail $i; \
done
install -c -o bin -g bin -m 444 sendmail.0 /usr/share/man/cat8/sendmail.8
install -c -o bin -g bin -m 444 aliases.0 /usr/share/man/cat5/aliases.5
install -c -o bin -g bin -m 444 mailq.0 /usr/share/man/cat1/mailq.1
install -c -o bin -g bin -m 444 newaliases.0 /usr/share/man/cat1/newaliases.1
If all looks good, you can install sendmail with this command: # ./Build install But be aware that the new sendmail might not work properly with your old configuration file. See Chapter 4 for guidance in creating a new configuration file. Notice that Build will not create the queue directory even if it does not exist. If you have never run sendmail on your machine before, you will need to create that queue directory: # mkdir /var/spool/mqueue # chmod 700 /var/spool/mqueue See Section 1.6.3 for a description of the QueueDirectory option and information about how sendmail locates its queue directory. 2.6.2 Installation with V8.12 and AboveBeginning with V8.12, installation of sendmail has become a bit more complex. You now have the choice of running sendmail as either a set-user-id root or a non-set-user-id root program. The recommendation, beginning with V8.12, is to run sendmail as a non-set-user-id root. If you wish to install sendmail as a set-user-id root program, despite the potential security risks implied by such an approach, just issue this new special command: # ./Build install-set-user-id The preferred way to install sendmail, beginning with V8.12, is to first create three required system changes, and then to run ./Build install as usual:
In a non-set_user-id root world, sendmail runs under two guises. In one guise it is run by root to function as a listening daemon. This listening daemon is just like the listening daemon of earlier versions, except that, instead of running as root no matter who ran it, it now runs as root only if root runs it. In its second guise, sendmail runs as an ordinary user to collect locally submitted messages. In this mode of operation, sendmail is set-group-id to a special group, so it runs in that group no matter who runs it. That group owns and has write permission to a separate queue into which locally submitted deferred messages are placed. For this division of labor to work, the two guises need to use different configuration files. The configuration file used by the listening daemon is the traditional sendmail.cf file discussed throughout this book.[7] The configuration file used by the locally submitted message sendmail is called submit.cf.[8] Which configuration is used depends on how sendmail is run.
If sendmail is run with the -bm command-line switch (-bm), the -bs command-line switch (-bs), or the -t (-t) command-line switch, it first tries to open and read submit.cf. If that file does not exist, sendmail falls back to reading its standard configuration file. The -bm command-line switch (sendmail's default mode) causes sendmail to run as a mail sender, once in the foreground, gathering a list of recipients from the command line and reading the message from its standard input. The -bs command-line switch causes sendmail to run a single SMTP session in the foreground over its standard input and output, and then to exit. The -t command-line switch causes sendmail to gather its list of recipients from its standard input rather than from the command line. In addition to determining the use of submit.cf based on sendmail's mode of operation, sendmail can also be coerced into using or not using submit.cf based on a new command-line switch. The -A command-line switch takes one of two possible arguments. If it is followed by an m character, sendmail uses the sendmail.cf file. If the -A is followed by a c character, sendmail uses the submit.cf file: /usr/sbin/sendmail -Am In the following sections we first discuss the three system file modifications, then present a discussion of how to create and configure a submit.cf file. 2.6.2.1 Add smmsp to /etc/passwdWhen sendmail is run as non-set-user-id root, it is either run as root when it is invoked by the root user, or as another user when it should not run as root. The sendmail distribution clearly cannot divine ahead of time what user you wish to use when not running sendmail as root. It could have chosen nobody, for example, but the user nobody does not exist under all versions of Unix. You can choose your own username by using the confMSPQOWN build macro (confMSPQOWN) to place a line such as this into your build m4 file: define(`confMSPQOWN', `nullmail') If you change the username, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for the new users with the RunAsUser option (RunAsUser), like this: FEATURE(`msp') define(`confRUN_AS_USER', `nullmail') If you don't change the name, sendmail will presume to use the name smmsp, which stands for SendMail Message Submission Program. Whether your keep the username chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system's passwd(5) services. Here we show how to do this with the traditional Unix passwd(5) file. Consider the lessons taught here, and apply them to your passwd(5) services in the manner most suitable to your Unix system: nullmail:*:32764:32764:Null Mail:/no/such/directory:/bin/false In this example of a line from a traditional Unix passwd(5) file, we have elected to create the user named nullmail. The line is divided into five fields by colons. The first field is the name of the new user. The second field is the user's password. But, because this user is not an actual person, we disable the password with an asterisk. On some systems you will need to put an x in this field, or the word NOPASSWORD. See your system documentation for what to use in this field to disable a password for this new user. The third and fourth fields are the user and group ID for the user. Here, we chose high numbers that are unlikely to conflict with actual user numbers. Some versions of Unix restrict the size of the numbers you can use. See your system's documentation. The fifth field is called the gecos field. It contains the full name of the users. We chose Null Mail, but you can choose any name you desire. The last two fields are the home directory and shell for this user. The home directory should not exist, nor should it have the potential of ever existing. The shell should be a program that will never successfully run. We chose /bin/false because that program always exits with a non-zero (failure) value. 2.6.2.2 Add smmsp to /etc/groupWhen sendmail is run as non-set-user-id root, it is either run as root when it is invoked by the root user (in which case it can read all files), or as another user when it should not run as root. To enable the sendmail program to read and write its queue when it is not root, it needs to always run as a predefined group. It does this by having its set-group-id permission set, and by running under an appropriate group. The sendmail distribution clearly cannot divine ahead of time what group you wish to use when not running sendmail as set-group-id. It could have chosen nogroup, for example, but the user nogroup does not exist under all versions of Unix. You can choose your own group by using the confGBINGRP build macro (confGBIN...) to place a line such as the following into your build m4 file. But don't chose a group that is shared by any other user. For security reasons, the group you chose should be used only by sendmail: define(`confGBINGRP', `nullgroup') If you change the group, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for that new group with the RunAsUser option (Section 10.8.2.2), like this: FEATURE(`msp') define(`confRUN_AS_USER', `:nullgroup') Note that the same option sets both the user and the group. A combined declaration might look like this: FEATURE(`msp') define(`confRUN_AS_USER', `nullmail:nullgroup') If you don't change the group, sendmail will presume to use the group smmsp, which stands for SendMail Message Submission Program. Whether you keep the group name chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system's group(5) services. Here we show how to do this with the traditional Unix group(5) file. Consider the lessons taught here, and apply them to your group(5) services in the manner most suitable to your Unix system: nullgroup:*:32764: In this example of a line from a traditional Unix group(5) file, we have elected to create the group named nullgroup. The line is divided into four fields by colons. The first field is the name of the new group. The second field is the group's password. Because this group is not used by actual people, we disable the password with an asterisk. On some systems you will put an x in this field, or the word NOPASSWORD. See your system documentation to learn what is best to use in this field to disable a password for this new group. The third field contains the group number. That number should match the number used in the group field of the passwd(5) file. The last field contains the usernames of those that should also belong to this group. Generally, this will be an empty field. 2.6.2.3 Modify init filesIn a non-set-user-id root world, you run sendmail differently than the traditional manner to which you have become accustomed. There are two differences that you should attend to before installing the new non-set-user-id root setup. First, you need to decide how to drain the local message submission queue. Second, you need to decide on a name to differentiate the two roles with the syslog(8) facility. For local mail submission, sendmail will use a separate queue, one that is group read/write by the group discussed in the previous section. The sendmail program, in local message submission mode, sends a message and then exits. As a consequence, there is nothing running that can drain that separate queue of any messages that might be deferred there. The best way to drain it is with a queue processing daemon, such as this: /usr/sbin/sendmail -Ac -q30m Here, the -Ac command-line switch tells sendmail to use the configuration file named submit.cf. This is the special message submission configuration file that knows about the second queue. The -q30m command-line switch causes sendmail to wake up once each 30 minutes and process any deferred messages it finds in the second queue.[9]
To differentiate one sendmail from another in the logs created by the syslog(8) facility, you can use the -L command-line switch (-L). One suggestion looks like this: /usr/sbin/sendmail -L mta-daemon -bd -q30m /usr/sbin/sendmail -L msp-queue -Ac -q30m The first line is the invocation of sendmail that is most common (with the -bd -q30m). The second line has been added to drain the second (mail submission) queue. The first will contain the identifier mta-daemon in its syslog(8) log files. The second will contain the identifier msp-queue. These identifiers are only suggestions, and you might prefer something more suitable to your site's needs. The sendmail program is usually started from a script in the etc directory. On System-V based versions of Unix, that file is usually found in the /etc/init.d directory. On other versions of Unix, that file could live directly in the etc directory, and might be called rc or rc.local. Whichever file contains the commands to start sendmail on your system, look at it and determine how sendmail is currently started and stopped. You might, for example, find lines such as this, from a FreeBSD 4.0 sendmail startup file called rc: case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags}
fi
;;
esac
To modify this setup for use in a nonset-user-id root scheme, you would need to add the following line to your /etc/rc.conf file: sendmail_flags="${sendmail_flags} -L mta-daemon"
Then create the file /etc/rc.local (if it does not already exist), and add the following lines to it: case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' msp-queue'; /usr/sbin/sendmail -L msp-queue -q30m
fi
;;
esac
Take the time, now, to investigate how sendmail is started and stopped on your system. The new non-set-user-id root scheme will doubtless require special modifications on your part. Beginning with Solaris 7, for example, the pkill(8) command, as it is set up in /etc/init.d/sendmail, will not stop a sendmail that is running other than as root. 2.6.2.4 The submit.cf fileThe submit.cf is built for you automatically when you install sendmail.[10] When you run make install, the following is one of the commands executed:
cd ../../cf/cf && make install-submit-cf This command will create and install a default /etc/mail/submit.cf file if that file does not already exist. For most sites this default will be suitable for your use as is. If you customize at all, however, you will need to create your own submit.cf file. If, for example, you changed the user and group names for the non-set-user-id root version of sendmail with the following in your build m4 file: define(`confMSPQOWN', `nullmail') define(`confGBINGRP', `nullgroup') you will need to create a custom submit.cf file. You create a custom submit.cf file just like you create a sendmail.cf file (Section 4.2). You begin by creating a file called submit.mc. You can use the file cf/cf/submit.mc as a template for your own, or you can edit that file directly. If you edit that file directly, you will need to copy your changes to the same directory each time you upgrade sendmail to a new version. Note that the name submit.cf is hard-coded and cannot be changed. When sendmail runs, unless you have built it to do otherwise, it will look for submit.cf in the same directory that it looks for its standard configuration file. If you change the location of the standard configuration file with the _PATH_SENDMAILCF build-time macro (_PATH...), you will also want to change the directory in which the submit.cf file is located. That directory is defined with the _DIR_SENDMAILCF build-time macro.[11] For example, your build m4 file might look, in part, like this:
APPENDDEF(`confENVDEF', `-D_PATH_SENDMAILCF="/opt/sendmail/sendmail.cf"') APPENDDEF(`confENVDEF', `-D_DIR_SENDMAILCF="/opt/sendmail/"') Here, the first line changes the location of the sendmail.cf file. The second line is necessary so that sendmail will look for submit.cf in that same directory. Without this second line, sendmail would look for sendmail.cf in /opt/sendmail, but would look for submit.cf in the default location /etc/mail. Note that a Build install will always try to place the submit.cf file into a directory that begins with /etc/mail. But you can prefix this directory with another directory name, as shown here: # ./Build -E DESTDIR=/opt/sendmail install This will cause the submit.cf file to be installed in the /opt/sendmail/etc/mail directory. If you have changed the location of your configuration files, as shown earlier, you will have to manually move the submit.cf file from its default installed location to your chosen location.[12]
Table 2-4 shows how the Build process parallels the creation of the submit.cf file in certain limited ways.
Note again that _DIR_SENDMAILCF does not affect where Build install places the submit.cf file. Finally, note that by renaming or relocating the queue directory with the confMSP_QUEUE_DIR Build macro (confMSP_QUEUE_DIR), the MSP_QUEUE_DIR mc macro must also be updated so that a correct submit.cf file will be created. 2.6.3 The /etc/mail DirectoryOne surprise you will encounter when installing V8.10 sendmail and above is that all support files now have a default location of /etc/mail. If that directory does not exist, Build will create it for you. If it exists but is not a directory, you might see an error like this: install -c -o bin -g bin -m 444 helpfile /etc/mail/helpfile install: /etc/mail/helpfile: Not a directory *** Error code 1 If the file /etc/mail is serving no current purpose, consider removing it and rerunning Build. If that file is still important, take the time now to discover why and change its name. All future versions of sendmail will be grounded in the /etc/mail directory, so taking time now to free that name will be well spent. 2.6.4 Old Alias FilesOn sites that are already running sendmail, the /etc/mail directory will likely not exist. If this is the case, your aliases (and possibly other database files) will exist in another directory (probably /etc). The Build install process does not move those old files into the new /etc/mail directory. After installing the new sendmail, test it by running newaliases. If you see the following error (or something similar), you probably have old files you need to move into the new directory: % newaliases newaliases: cannot open /etc/mail/aliases: No such file or directory You should also check for directory assumptions in your prior mc configuration file. You might have carried old locations into the new V8.10 or above configuration file, and moving files can cause errors to appear after the move. 2.6.5 Other Moved FilesBe aware that other files have also moved into /etc/mail, while still others have both been moved and renamed. Table 2-5 shows the old and new locations and names for the affected files.
If any of these old names exist on your system, you should move them to the new /etc/mail directory, or remove them from service, as marked. 2.6.5.1 The MAIL_SETTINGS_DIR mc macroThe name of the default directory, /etc/mail, is stored in the MAIL_SETTINGS_DIR mc configuration macro. You can redefine this macro to relocate that default to a new directory, but if you do, be certain that the declaration ends in a slash character: define(`MAIL_SETTINGS_DIR', `/opt/sendmail/etc/')
Note that the MAIL_SETTINGS_DIR mc configuration macro must specify a full pathname, one that starts with a slash. If it does not specify a full pathname, unexpected problems might arise when you run sendmail. 2.6.6 The Wrong Symbolic LinkWhen upgrading from the vendor's version of sendmail to the open source version of sendmail, vendor assumptions about program locations might not agree with the new sendmail locations. One way to check for a mismatch is to look at the version of sendmail under each of its names. Consider, for example, a check to see if sendmail and the newaliases program are the same: % newaliases -d0.1 < /dev/null | head -1 Version 8.9.2 % /usr/lib/sendmail -d0.1 < /dev/null | head -1 Version 8.12.7 Here we find that newaliases is not a symbolic link to sendmail as we expected. Finding the cause of this mismatch can take some investigation. Under BSDI 3.x, for example, the /usr/sbin/newaliases program is a hard link, not a symbolic link, so replacing sendmail will not affect it. |
|
|
use sendmail.cf
/usr/sbin/sendmail -Ac 
must end in a slash