When confronted with such a project, and with a short time to deploy, I look for tried and tested tools to help me maximize my time, adhere to best practices or standards, develop easy documentation for new IT employees to understand and support, and broaden acceptance of Linux in our enterprise.
Oftentimes, this will have me choosing brevity over personal education -- that is, I may choose an installation tool over learning a package fully to start, just to deploy as quickly as is feasible. I learn quite a bit in a rapid deployment scenario, and my education on the packages in question usually grows exponentially once I have the time to study the package in depth.
In this event, I had to choose something quick to deploy, easy to configure and understand, well-documented enough to be Googled to death when there's a problem, and functional enough to not generate an inordinate amount of future feature requests.
For a hardware platform I chose the IBM x335 1U server with twin 3.2GHz Xeon CPUs, 4GB RAM, and a pair of 80GB SCSI disks running in a mirrored configuration. For backups, our site uses Tivoli Storage manager, which picks up the mail spool and home directories nightly. The system is housed in our data center along with the rest of our high-availability machines, so power considerations followed our standard procedure for all new boxen.
For software, I chose the old standby of Sendmail, Open Webmail as the front end to the mail server, and a nifty little script I found for installation of Sendmail called (predictably enough) install-sendmail.
Utilizing my trusty Kickstart server, I installed a stock Red Hat Linux 9.0 installation. Since the system already has hardware RAID, I configured LVM like so:
/boot 200M swap 1024M PV (physical Volume) 1M -- fill to maximum allowable disk space
and I divided up the physical volume into logical volumes:
homelv /home 20480K varlv /var 20480K tmplv /tmp 2048k rootlv / 2048k usrlv /usr remainder of space
Unfortunately, Red Hat has a bad habit of making its text-based stuff clunkier than it has to be. Since we're installing from Kickstart, we're forced to use textmode, and the interface to Disk Druid is nowhere near as easy to use in text mode as the GUI client. It'd be nice if the Disk Druid team would make the two interfaces a little more similar in that regard. (Having said that, Fedora is much better, and I look forward to future releases being even better.) Another thing you can do is to lay out the filesystems/LVs as you need them and pre-configure a ks.cfg file for automated installation.
In any event, as you can see, I maximized space on my var filesystem and the home directories to support the mail spools and personal mailboxes. The mail system will initially place mail in /var/spool/mail/, and once users read their mail, the mail subsystem will copy the read mail to the file "mbox" in the users' home directories.
I chose a Server Installation and installed a few basic packages (text-based Internet, some utilities, etc.; it's also important to have the latest version of Perl installed on your system to support the Webmail interface and some support software which is also dependent on Perl to function) and let the install run. After the installation completed, I employed a tool I found called install-sendmail, a Perl script that automatically configures Sendmail for you by asking you questions. The current version, install-sendmail 6.0, supports RedHat 9.0 and the installed version of Sendmail (sendmail-8.12.8-4).
After downloading it, extract the install-sendmail script and place it in a user-accessible directory. From the extraction point, run ./install-sendmail -c as a non-root user.
After a quick churn, the script asks which of 13 languages to use. The script warns about needing to have fetchmail and sendmail already installed, which isn't a problem since it's a default configuration for Red Hat 9.0. After a few questions about your domain, and a request for your root password, the system is fully configured to send e-mail on behalf of your domain. If you have any further issues with the script, the INSTALL document has a quick coverage of the install process, and the author is pretty responsive if you have any issues.
When I arrived at my job here a few years ago, we used a great little Perl front end to our mail spools called Neomail. Today, as near as I can tell, Neomail development has pretty much stopped, so I chose Open Webmail, a more recent project based on Neomail, for our Web front end. It includes features including a handy file manager, shell client, and address book/calendar functionality, and currently supports 30 languages. If you don't need the extras, you can still use Neomail, which is simpler to deploy and configure than Open Webmail.
Instead of installing the RPM binary, I decided to go with the tarball. Call me old-fashioned, but the documentation kept speaking about Red Hat 6.2. I decided that enough had changed in the filesystem structure (like the Web directory being moved from /home/httpd/ to /var/www/) that I should maintain control over where everything got deployed myself.
First and foremost, I had to download the latest tarball, Open Webmail-2.21.tgz, from the project's site. I made me a test directory and extracted the file using the command
tar -zxvf Open Webmail-2.21.tgz
The extraction process created two directories: data and cgi-bin. This indicated to me two things: First, it expects me to be working in Apache's server root (/var/www/), and second, it expects Apache to have been installed from source. The source installation has a single directory with all configuration files and binaries under a single location, and the main HTML directory is called "data." Red Hat 9.x, by contrast, puts the application files in /var/www/ and calls it "html," so there is a mismatch between what the tarball expects and what is found on the Red Hat system.
Fortunately, this is quite easy to remedy. First, change to root and move the contents of each directory to its intended destination:
# mv data/openwebmail /var/www/html/ # mv cgi-bin/openwebmail/ /var/www/cgi-bin/
In this way, the files and directories would exist where the installer expects them to be.
Next, the Open Webmail project expects certain tools to be installed already, namely:
Fortunately, the Open Webmail project makes these packages available on its Web site. Go to http://www.openwebmail.org, select a mirror, click "download," then browse into the "packages" directory. You can download the entire aforementioned list from this location.
The installation for each of the packages is the same. Extract the package using tar, and then run:
perl Makefile.PL make make install
After three separate installs now I've concluded that whether you have any of the packages installed or not (most likely not since this is a fresh installation), you should extract and install each of these for continuity's sake. Open Webmail looks for them in specific places, and it's best just to install the packages as suggested. (On the other hand, if your server is not an appliance and serves double-duty, check your current usage to see whether adding these packages will cause you trouble.)
Finally, you need to edit a couple of files to finish up the configuration. Go to /var/www/cgi-bin/openwebmail/etc/. In the file openwebmail.conf, change:
dbm_ext .db dbmopen_ext dbmopen_haslock 0
dbm_ext .db dbmopen_ext %dbm_ext% dbmopen_haslock yes
ow_cgidir /usr/local/www/cgi-bin/openwebmail ow_htmldir /usr/local/www/data/openwebmail
ow_cgidir /var/www/cgi-bin/openwebmail ow_htmldir /var/www/html/openwebmail
In the same directory, edit the file auth-unix.pl and change the following lines like so:
set $unix_passwdfile_encrypted /etc/shadow set $unixpasswdmkdb none
Exit the configuration files and execute as root the command
After a great deal of churning and computing you will be returned to a system prompt.
Now make sure your Web server is configured and started. On Red Hat systems, you can execute the commands:
chkconfig --level 2345 httpd on service httpd start
as root, and your system will start up the httpd server and configure it to start every time you boot your system into any of the runlevels 2, 3, 4, or 5.
Finally, launch your Web browser and point to http://your-host.com/cgi-bin/openwebmail/openwebmail.pl.
If everything has gone smoothly, you should see a logon screen. Enter your system login and password, answer a few configuration questions, and you are ready to use the system.
To add a new mail user, use the Linux useradd script and passwd to set their password. For the security-conscious among us (I can hear you shouting at me now), I created an /etc/nologin file that tells any users trying to log into the system that they should load the mail interface in a browser instead, and gives the support desk phone number.
The Open Webmail user interface includes a nice set of features covering mail reading and sending, file management, a Java SSH terminal implementation, and a calendar. The interface is intuitive and easy to navigate, and leaves little room for user error.
Open Webmail is easy to deploy on just about any version of Unix (with some background work). You may wish to turn on quotas, or even allow shell logins, or keep your users out and just offer the e-mail service. It's all up to you. I have a friend who has deployed Open Webmail and put in server redirects so users can just call up their main mail server hostname and be presented with the Open Webmail login screen.
Jerald Sheets is a senior Unix systems administrator for Our Lady of the Lake Regional Medical Center in Baton Rouge, Louisiana. Their network consists of several AIX boxes ranging from 4.2 through 5.2 including IBM's new Regatta system. Jerald is team lead for open source initiatives, Lawson Systems Administration, and DNS.