|
|
Before you look at Sendmail or PostFix, you should know about a subsystem of Fedora Core and Red Hat Linux that controls which MTA the system uses. It is critical that you understand this MTA control system, since you need to know which MTA is in use before you can troubleshoot related e-mail problems.
The alternatives system is a set of control scripts and symlinks that was developed by the Debian team to support application interoperability and dependency resolution. This system has been available on Red Hat installations since at least version 7.3. It usually goes unnoticed unless you need to track down a pesky MTA binary- or daemon-related problem.
Often, an e-mail server administrator has much more to contend with than just dealing with user-based e-mail. System scripts, web CGIs, user programs, and other parts of the system often send mail from the server. Each of these scripts and programs have their own method of sending automated e-mail. For example, many scripts send e-mail by calling the MTA directly. One may use /usr/sbin/sendmail while another may expect /usr/sbin/postfix to be installed, and still another may want /usr/local/sbin/qmail. If you don't offer these various MTAs to your users, you probably don't want to install and administer them all just for your automated scripts.
In order to deal with these multiple requests, many old-school mail administrators resort to ugly combinations of parallel binary installations and tricks involving scripts and aliases, all to gain a fraction of the functionality that alternatives provides out of the box. The problem with these customized designs is that only the designer knows how it works or how it fits together! While being the only one who can fix a crashing server may seem like good job security, it's not an optimal situation for the modern production enterprise-level e-mail environment. The alternatives system gives you the ability to use the MTA best suited to your situation, without the related headaches normally associated with multiple-MTA compatibility.
| Note |
The alternatives system can be used to manage various overlapping binaries, such as redundant packages, daemons, or services. Under Fedora and Red Hat Linux, however, alternatives is currently used only to manage multiple MTAs and for CUPS/lpr printer daemon control and maintenance. |
The theory behind the alternatives system is simple. Rather than rely on a single binary like /usr/sbin/sendmail, alternatives uses a set of symlinks that provide standard link names, all pointing to the ultimate MTA binary, like this:
/usr/sbin/sendmail -> /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
where the last filename is actually the Sendmail binary:
# ls -la /usr/sbin/sendmail.sendmail -rwxr-sr-x 1 root smmsp 738752 Oct 2815:06 /usr/sbin/sendmail.sendmail
The /usr/sbin/sendmail binary has become a set of links that ultimately calls the "real" sendmail binary, /usr/sbin/sendmail.sendmail.
Why is this useful? User scripts, system packages, web CGI scripts, and other bits of code can now call your local MTA by the Sendmail legacy name and location, by the system MTA reference /etc/alternatives/mta, or by its legacy name, /usr/sbin/sendmail. For example, if the system were using PostFix under the alternatives system's control, the Sendmail symbolic link would look like this:
usr/sbin/sendmail -> /etc/alternatives/mta -> /usr/sbin/sendmail.postfix
The sendmail.postfix binary is actually the postfix binary with an additional Sendmail compatibility wrapper included that can take some Sendmail-formatted command-line options. Here is the actual file:
# ls -la /usr/sbin/sendmail.postfix -rwxr-xr-x 1 root root 99776 Jul 22 14:45 /usr/sbin/sendmail.postfix
Compare this to the standalone PostFix binary shown here:
# ls -la /usr/sbin/postfix -rwxr-xr-x 1 root root 62488 Jul 22 14:45 /usr/sbin/postfix
On an RPM-based system such as SuSE, Red Hat, or Fedora Core, you may notice that neither the PostFix nor the Sendmail RPM packages provide the symlink /etc/alternatives/mta. This link is dynamically created and switched by the alternatives system's control scripts. Curiously, both the Sendmail and PostFix RPMs "own" the symlink /usr/sbin/sendmail:
# rpm -qf /usr/sbin/sendmail sendmail-8.12.10-1.1.1 postfix-2.0.11-5
At first glance, an experienced system administrator may see the alternatives system as one big mess of unneeded complexity and confusion that does not belong on a "properly managed" mail server. However, the more you study and use the alternatives system, the more you may begin to appreciate the genius of its layout and functionality.
To see what the alternatives system is doing for your MTA, issue the command alternatives -display mta and browse the output:
# alternatives --display mta
mta - status is auto.
link currently points to /usr/sbin/sendmail.sendmail
/usr/sbin/sendmail.sendmail - priority 90
slave mta-pam: (null)
slave mta-mailq: /usr/bin/mailq.sendmail
slave mta-newaliases: /usr/bin/newaliases.sendmail
slave mta-rmail: /usr/bin/rmail.sendmail
slave mta mailqman: /usr/share/man/man1/mailq.sendmail.1.gz
slave mta-newaliasesman:
sr/share/man/man1/newaliases.sendmail.1.gz
slave mta-aliasesman:
/usr/share/man/man5/aliases.sendmail.5.gz
/usr/sbin/sendmail.postfix - priority 30
slave mta-pam: /etc/pam.d/smtp.postfix
slave mta-mailq: /usr/bin/mailq.postfix
slave mta-newaliases: /usr/bin/newaliases.postfix
slave mta-rmail: /usr/bin/rmail.postfix
slave mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz
slave mta-newaliasesman:
/usr/share/man/man1/newaliases.postfix.1.gz
slave mta-aliasesman:
/usr/share/man/man5/aliases.postfix.5.gz
Current 'best' version is /usr/sbin/sendmail.sendmail.
When you switch MTAs with the alternatives system, the entire system shifts gears. The manual page assignments for MTA binaries, mail queuing, system aliases, and even the PAM authentication system and SysV init (boot) scripts are reconfigured on the fly for the new MTA you have chosen (assuming, of course, that your new MTA is alternatives-aware). If you want to migrate from a Sendmail system to a PostFix system, all your mailing scripts, programs, and CGI scripts should work without major rewrites.
Once you understand the concept behind alternatives, it is an easy system to use. In this section, we show you a simple command-line session. This output shows the process of switching between Sendmail and PostFix, using the alternatives or redhat-switch-mail-nox command, as well as some troubleshooting tips to make the switch easier.
| Tip |
Learn more about the alternatives system with the command man 8 alternatives. |
To begin the process of switching MTAs, you should first verify that the system is using Sendmail as its mail transfer agent, and that alternatives is aware of this fact. Issue the command alternatives-display mta, as described in the previous section.
The line that shows the active MTA is link currently points to .... Remember, the actual Sendmail binary is /usr/sbin/sendmail.sendmail and the Sendmail/PostFix wrapper binary is /usr/sbin/sendmail.postfix.
When Sendmail is the active MTA, you'll also see that it is configured to come up as a service when the machine is booted via the chkconfig command:
# chkconfig --list|grep sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
This shows that Sendmail will start up at boot time in runlevel 2, 3, 4, or 5. Once you have verified that Sendmail is active, you can issue the next set of commands, which notify the alternatives system to use PostFix as the MTA instead of Sendmail:
# alternatives --set mta /usr/sbin/sendmail.postfix # alternatives --display mta mta - status is manual. link currently points to /usr/sbin/sendmail.postfix /usr/sbin/sendmail.postfix - priority 30 slave mta-pam: /etc/pam.d/smtp.postfix slave mta-mailq: /usr/bin/mailq.postfix slave mta-newaliases: /usr/bin/newaliases.postfix . . .
Now it's pointing to /usr/sbin/sendmail.postfix, the Sendmail compatibility wrapper for PostFix. Again, use chkconfig to see whether Sendmail is still set to run at boot time:
# chkconfig --list |grep sendmail
You should receive no output. Alternatives knew that you had Sendmail set up as the system MTA and switched to PostFix. The lack of output indicates that alternatives has not only changed the MTA, but has ensured that Sendmail will not be referenced at boot time or during runlevel changes.
Next, test whether the system also correctly set up PostFix as the system MTA and also configured it for the system's boot and runlevel changes:
# chkconfig --list |grep postfix postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Now, when the system boots into either runlevel 3 or runlevel 5 (the default boot runlevels for Red Hat and Fedora Core), the Postfix MTA will start. It will also run if the runlevel is changed to anything from runlevels 2 to 5.
This all looks good, but the one thing that alternatives does not do for you is actually start and stop running daemons or services. In this example, Sendmail is still running. If you check the status of the MTA daemons before you stop Sendmail by hand, you will see something like this:
# /etc/init.d/sendmail status sendmail (pid 5777 5768) is running # /etc/init.d/postfix status master is stopped
Stop the Sendmail daemon:
# /etc/init.d/sendmail stop Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ]
After you have seen the confirmation that Sendmail is stopped, you can start PostFix. PostFix can either be started manually or through runlevel change, as shown here:
The first command showed the previous and current runlevels (N=unknown, or the system booted before your current runlevel was entered). On a headless or GUI-less server, this is runlevel 3 on Red Hat based systems. If you want to simulate a reboot without actually rebooting your system, just toggle over to another runlevel and then back to your production default runlevel. After doing this, anything set to run in your default runlevel should start up if not already running. The last command shows us that PostFix is now running.
| Note |
Changing runlevels is done here for illustrative purposes. Most administrators will not change runlevels on a production server unless they really have to. Most would simply issue the command /etc/init.d/postfix start. If you do want to simulate what happens when you boot a system, changing runlevels will get you as close as possible without doing an actual reboot. |
Some experts consider the changing of runlevels (to test the ability of init script-configured services to properly start and stop on reboot) to be unduly dangerous on a production server. This is because a lot happens to a server when you toggle runlevels. Services across the system are checked for running process IDs (or PIDS), kill and start scripts are called, logs are written, and so on. However, the "boot survivability" of a service is best tested using this real world runlevel testing method. You just need to be sure that you know exactly what you have running (and not running) in each run level. If you are not intimately familiar with the configuration of all of the daemons on your server, or testing chkconfig controlled services like this makes you nervous on a live system, then just verify the proper per daemon configuration settings with chkconfig, manually start the service you're configuring, and then just check its status either with the init script or with ps, like this:
# chkconfig --list sendmail sendmail 0:off l:off 2:on 3:on 4:on 5:on 6:off # /etc/init.d/sendmail status sendmail is stopped # /etc/init.d/sendmail start Starting sendmail: [ OK ] Starting sm-client: [ OK ] # ps auxw| grep [s]endmail root 31988 0.0 0.5 6320 2672 ? S 18:46 0:00 sendmail: accepting connections smmsp 31997 0.0 0.4 6148 2340 ? S 18:46 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
Once you get PostFix running, you may want to check the process to be sure that it is working correctly. You can use the /etc/init.d/postfix status method for testing (as we did previously), but if you instead use the ps command, you should see output like this when the PostFix MTA is functioning properly:
# ps auxw| grep [p]ostf root 6123 ... /usr/libexec/postfix/master postfix 6124 ... pickup -l -t fifo -u postfix 6125 ... ngmgr -l -n qmgr -t fifo -u
Should you no longer want to work with PostFix, it is easy to reverse these commands and get back to Sendmail:
# /etc/init.d/postfix status master (pid 5904) is running... # /etc/init.d/postfix stop Shutting down postfix: [ OK ] # alternatives --set mta /usr/sbin/sendmail.sendmail # chkconfig --list| grep sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off # chkconfig --list| grep postfix # # /etc/init.d/sendmail status sendmail is stopped # init 4 # init 3 # runlevel 4 3 # /etc/init.d/sendmail status sendmail (pid 5988 5979) is running...
This code block shows the complete process for using alternatives to change the server MTA, and then testing the change by switching runlevels. Be warned: changing runlevels can be dangerous if you don't know exactly what is going on in each runlevel. If you're not sure, just use the safer /etc/init.d/sendmail start command to start up Sendmail (or whichever service you're toggling) instead of init 4 and init 3.
| Caution |
Under Red Hat Linux 9, there was a bug in the stock alternatives system that makes Send-mail's smtpauth fail if you switch MTAs to PostFix and then back to Sendmail. Though it appears to have been fixed in Fedora Core 1, you should be aware of the potential problem. The bug is caused by a missing line in /var/lib/alternatives/mta :
/usr/sbin/sendmail.sendmail
90 sendmail
/etc/pam.d/smtp.postfix <---Add this line...
/usr/bin/mailq.sendmail
Add the line, change the default MTA to PostFix and then back to Sendmail, and turn on the saslauthd service (don't forget to issue the chkconfig saslauthd on command), and it will work fine. If you continue to see error messages in /var/log/messages or /var/log/maillog, check http://bugzilla.redhat.com to find a fix or patch. |
Some people prefer to work with graphical user interfaces, and Red Hat has made a real commitment to providing GUI tools for the programs included with Red Hat Linux and Fedora Core. In some cases, a program may have both a GUI and a TUI (text-based user interface). All three options-GUI, TUI, or good old command line-will get the job done.
Under Fedora Core, the alternatives system has a Python-based graphical user interface, shown in Figure 19-1. Invoke it with the command redhat-switch-mail. If you prefer, you can invoke a text-based user interface, as seen in Figure 19-2, with redhat-switch-mail-nox (where nox stands for "no-X11").
Both these commands call the Python and XML underpinnings now used in Red Hat based systems to set up alternatives so that it runs properly with commands issued through the graphical or text-based configuration tools.
There is also a GUI for the chkconfig tool, shown in Figure 19-3. Note, however, that the chkconfig GUI only toggles the boot-time configuration for the runlevel that you are currently in (runlevel 5 if you are in the GUI). In contrast, chkconfig at the command line affects runlevels 2 through 5 when configuring services and daemons to be on and off. Invoke the chkconfig GUI with the command redhat-config-services.
If you are working on a Red Hat based system, you might prefer ntsysv, the ncurses, or text-based user interface for chkconfig, invoked with the ntsysv command. It is lightweight, fast, and does not require X11; you can use it via ssh over a text login. The ntsysv TUI is shown in Figure 19-4.
One nice feature of these tools is that you can use them to learn about the various services available on your server. For example, in the ntsysv TUI example, just highlight the service that you're interested in and press F1 to see a Help window that describes that service. This is how many new Red Hat based sys-admins learn the ropes about system initialization services.
|
|
