How to Login to Any UNIX System and Get Your E-Mail
Russ Hill Introduction If you work for a company with a large number of UNIX workstations or UNIX systems, you probably depend on e-mail and would find it useful to be able to log on to any workstation, not just your own, to read your mail. Then if you were in a meeting in the next building, or if your system went down, you could just borrow another workstation or terminal for a while and handle your mail. At a large site, it's always easy to find another workstation to use temporarily: the point is, e-mail service does not need to be interrupted. This article presents one method of providing e-mail services throughout your network. The method uses a central e-mail hub to hold the mail and NFS to deliver the e-mail on demand. The Central E-Mail Hub I have a Sun workstation, named "central.mycompany.com," which is dedicated as a network services system. This system provides many central services, including serving as the central e-mail hub. The system receives all e-mail because it is the only system that has a sendmail daemon running (this not only allows for centralized mail management, but also frees up valuable system resources on the network). To make sure that central's is the only sendmail daemon running, I enable site hiding in every system's sendmail configuration file -- on any system not configured for site hiding, the local copy of sendmail would be executed when mail was sent. This site hiding provides central's address in each outgoing message so that replies and returned messages are automatically routed back to central. Central accepts mail for every user, and, additionally, each user is told that his e-mail address is now "user@central.mycompany.com". Configuring Site Hiding To enable site hiding, you must change the sendmail config file, /usr/lib/sendmail.cf, by uncommenting the DH configuration line and putting in the fully qualified domain name of the central site:
DHcentral.mycompany.com
You then re-freeze the configuration by executing sendmail with the "-bz" option. This will create a file called /usr/lib/sendmail.fc. (For a complete descripton of how to set up sendmail, see your system's documentation. sendmail-5.65c+IDA-1.4.4.1 on UUNET also has good documentation on sendmail.) All of this allows central to accept any e-mail that is addressed to "mycompany" and puts that e-mail into the central e-mail spool directory: /usr/spool/mail. The central machine must also receive mail for every user. You can accomplish this by standardizing passwd information among central and all the centralized mail clients of central. With passwd information standard on all of these systems, each user can log on and receive mail at any station. To standardize passwd use NIS (see sidebar) or copy the same /etc/passwd file around to all systems and always keep it consistent. Exporting Once sendmail is configured, you'll use NFS to export the e-mail spool directory. On central, I export the directory to every other system by including it in central's /etc/exports file:
/usr/spool/mail -root /usr/spool/mqueue -root
One very important note: the spool directory must be exported allowing root access because the mail delivery programs run as root when delivering e-mail. E-mail gets delivered by the local system into central's e-mail spool directory using NFS. Clients Each client must be able to accept mail for all users who want their mail centrally located. Again, you ensure this by standardizing passwd information between central and all the central mail clients. The central server is NFS-mounted on each client system; I NFS mount each system's /usr/spool/mqueue and /usr/spool/mail directories through the /network/central directory to a centrally located /usr/spool/mail. To do this, I first remove the local client's /usr/spool/mail and /usr/spool/mqueue directories, then add the following mount points to the central server:
rm -rf /usr/spool/mail /usr/spool/mqueue
On each system I have a directory named "/network" that has central's filesystem NFS mounted. I mount the exported filesystems by including them in the client's /etc/fstab file:
central:/usr/spool/mail /network/central/usr/spool/mail nfs rw,bg,intr,retry=10 0 0 0 central:/usr/spool/mqueue /network/central/usr/spool/mqueue nfs rw,bg,intr,retry=10 0 0 0
You must kill the sendmail daemon and comment out the sendmail daemon's startup from the /etc/rc file on each client so that there is only one sendmail daemon using the central /usr/spool/mqueue directory. Find a line in /etc/rc similar to:
# /usr/lib/sendmail -bd -q15m &
and be sure it is commented out. Then save the new /etc/rc. The next step is to remove and link the directories to the central location:
rmdir /usr/spool/mail /usr/spool/mqueue ln -s /network/central/usr/spool/mail \ /usr/spool/mail ln -s /network/central/usr/spool/ \ mqueue /usr/spool/mqueue
Enabling Site Hiding To enable site hiding, uncomment the DH line in each system's sendmail configuration file, /usr/lib/sendmail.cf, and re-freeze it. When you're finished, all mail is sent out and received as if it were local. Patching Mail You need to modify the local mailer, /bin/mail, to retry if the /usr/spool/mail/${USER} file is locked at the same time due to another /bin/mail process appending a message (you can find source for /bin/mail several places on the Internet). Just add a for loop to try a few retries before failing. This will cut down on "unknown mail error 1 -- unable to append" messages. Listing 1 is an excerpt from /bin/mail. The added code is noted by the define RETRY. You can take out the #ifdef RETRY -- this was included only to show the code added to the function sendmail, which is only a portion of /bin/mail.c. System V Machines If you are linking System V machines be sure to link /usr/mail instead of /usr/spool/mail, and make a directory name ":saved" in central's mail spool directory (the one linked to /usr/mail). You can link BSD and System V machines to the same central e-mail hub. Just symbolically link /usr/mail and /usr/spool/mail on the individual client systems to the centrally located mail spool directory through an NFS mount point. I have linked a network of over 300 machines to the same mail spool directories. They are all linked to the same mail and mqueue directories. The number of systems does not seem to have much effect. Potential Problems of the Full NFS Method Sendmail usually uses the current process ID as part of the filename in /usr/spool/mqueue. This can be a potential problem with a large number of systems linked to the same directory -- process IDs can conflict. This is rare as there are approximately 65,000 unique process IDs. It is usually a problem only when something else goes wrong and causes a very large number of files to be in /usr/spool/mqueue at the same time. With over 300 systems linked to the same mail and mqueue directories for well over a year, I have had great success and a great reduction in the number of day-to-day mail problems. Security I have not discussed security. If you want tight security, turn off e-mail completely. The method discussed in this article is secure if you do not give out root access to your client machines. Since root access across NFS is necessary for this central mail method to work, any root user on any client machine can read anyone else's mail. Mail is owned by the user with read-write permissions, it has the group "daemon" with read-write permissions, and world permissions are closed with no access. Conclusions This type of centralizing mail works very well. I suggest only centralizing similar machines. All SunOS systems are centralized with a Sun server, Ultrix systems are centralized with an Ultrix server, and so on. This helps keep things straightforward if you ever have problems and need a vendor's technical support. With all of these "pockets" of mail hubs you can create a heirarchy of mail hubs.
About the Author
Russ Hill graduated from the University of Florida in Computer Engineering in August 1990 and has been working for Harris Space Systems Corporation as a UNIX Sysadm since September 1990. He works with Irix, Ultrix, ISC, SunOS, Domain/OS, CX/UX, HP-UX, and AIX UNIX systems. He is currently enrolled in the Master's degree program in Computer Science at the University of Central Florida.
|