One of the best collaboration tools to date has been the mail list. The power geeks have been taking advantage of this form of group-wide communication for years now, and many worldwide-networked communities have, in one way or another, benefited from the collaborative nature of the mail list.
Your small to midsize company, with its various departments, can also take advantage of this type of tool. But where do you start? Why, with Linux, of course. The open source community has more mail list server applications than Bill Gates has autos, so it can be tough to figure out which one to choose. After some searching, I opted to give Mailman a try. This mail list server, used by such groups as GNOME and Red Hat (for a full list, check out the Mailman In Use page), promised to be fairly easy to set up and, once installed, offered a Web-based administration for individual lists. We like Web-based administration. Unfortunately, the installation wasn’t all that simple. In fact, it took nearly three weeks of work to get this application up and running. I’ve worked it all out, though, and I’m going to show you how it’s done. This Daily Feature will walk you through the steps of getting, installing, configuring, and setting up a test list with Mailman.
What you need
Before you grab and install Mailman, make sure you have the following:
- · Python >= 1.5.2 installed on your computer
- · An SMTP server and an Mail Transport Agent (MTA), such as sendmail
- · A Web server, such as Apache
- · An ANSI C compiler (Most Linux distributions will have this.)
Although not critical for installation (but critical for actually using Mailman), you’ll need:
- · A static IP address
- · A domain (certainly suggested if this mailing list is to be open to the outside world)
For more information on getting sendmail up and running, take a look at Stew Benedict’s Daily Drill Down “Understanding sendmail from the ground up.”
Getting the Mailman application is as simple as pointing your browser to List.org and grabbing the latest stable release (2.0.8, as of this writing). Once you have that file and the requisites, you’re ready to install.
Installing Mailman is not the simplest task you’ll undertake. Before you actually go about the installation, you’ll have to take care of a few housekeeping details.
First, make sure the username and group mailman are both on your system. If the user and group mailman are installed, that’s great. If they aren’t on your system, add them (however you would normally add/administer users). Mailman is very sensitive to permissions and user/group ID numbers. Make sure you know the IDs of the mailman user and group.
Because this application relies heavily on the system’s Web server, we’re going to install Mailman alongside Apache (on a Red Hat 7.2 system). To make this installation work, we’ll create the directory /var/www/html/mailman by running, as root, mkdir /var/www/html/mailman, and then we’ll hand its ownership over to the mailman user and the mailman group. To change these ownerships, run this command:
chown mailman.mailman /var/www/html/mailman
The finishing touches for the /var/www/html/mailman directory involve permissions. Because a number of users will need read/write permissions to the directories under mailman, you’ll need to run the following commands, which will give all users read, write, and execute permissions (as well as set the suid bit) to the files and directories under mailman:
chmod a+rxws /var/www/html/mailman
This isn’t the most secure of setups, but it was the only way to get the application to install and run properly. Make sure you employ other means of security, such as a firewall.
Now that the user and group are ready, you can begin the installation process. The first step is to move the tarr’d and g’zipped file into /usr/local/src and then change to that same directory. In that directory, issue the following command to unpack the tar file:
tar -xvzf mailman.tar.gz
With the tar file unpacked, you’ll change to the newly created mailman-2.0.8 directory and run the configure command. You’ll add a couple of arguments to your configure command that will add certain local specifications.
This is where you must pay close attention to detail. Once you have run the configure command, you can’t change these configurations without starting all over. Because of this, I had to reinstall the application seven times. Eventually, I discovered, through error logs and broken e-mail sent from a broken system, that the full command should look like this.
This command will configure Mailman, setting the default group to ID 12 (this belonged to the group mail on my system), setting the group responsible for handling cgi to 48 (apache), and setting the base directory to /var/www/html/mailman. I ran this configuration because of the errors I was receiving in the broken e-mail. I originally ran the command with –with-gid=41 because that was the ID of the Mailman group. The problem was that Mailman wouldn’t be actually handling the mail transport.
The first error I caught was after receiving an e-mail sent to the moderator. I discovered a line that said this.
This was telling me that I had configured the application with the wrong group ID number. Instead of configuring Mailman by using–with-gid=41, I needed to use –with-gid=12 (the group ID 12 belongs to mail).
Along these same lines was an error telling me that the cgi scripts were expecting group ID 48 but getting 12. Again, I had to rerun configure and use –with-cgi-gid=48.
Your configure command will depend on these answers:
- · What is the ID of the group handling mail transport?
- · What is the ID of the group allowed to use the cgi-bin executables?
You’ll know pretty quickly, after the install is complete, if the configuration used was correct. Check the sent e-mail for errors as shown above. If you see a line like WANTED gid 41, GOT gid 12, you’ll know what to reconfigure that ID with.
The next step is to run the make install command (still as the mailman user). This will install the application.
Now you need to check all the permissions of Mailman. Don’t sweat it; the creators of Mailman wrote a handy script that will take care of that for you. Switch to the /var/www/html/mailman/bin/ directory and enter the command ./check_perms. After this script runs, you should get the message No problems found. If you still get errors, run the script again (this time, adding the -f switch) until it finally says No problems found. Once you have no errors, you’re ready to move on. If you get errors, you may have to run the same command with the -f flag to fix the problems.
Take note that getting a successful run of the check_perms script doesn’t guarantee that your Mailman setup is right. I was able to get check_perms to report zero errors on a number of broken systems. This is only checking the permissions of directories and files; it’s not checking the actual configuration used.
You’re not quite ready for prime time yet. You still have to take care of a couple of configuration options. You must tell your server that the /var/www/html/mailman/cgi-bin/ is allowed to run cgi scripts. If you don’t do this, the cgi scripts will all be displayed as Web pages instead of run as scripts.
To make this configuration, su to root, fire up your favorite text editor (mine is Pico), open the /etc/httpd/conf/httpd.conf file (under the Aliases section), and add this.
Next, add the Mailman aliases to your /etc/aliases file. You’ll see a section that looks like this:
Edit this to reflect the correct information. After you add the aliases, you must run (as root) the command newaliases to add these aliases to the system.
You still have a few more steps, but you’re almost done. Next, create the directory where Mailman will house its images. You can create a directory, called images, in /var/www/html/ and give its ownership over to mailman. After you’ve created this directory, copy all the .jpg files in the /var/www/html/mailman/icons/ directory to the new images directory. Finally, add this line to the /var/www/html/mailman/Mailman/mm_cfg.py file:
The final step is to add to the mailman user’s crontab the /var/www/html/mailman/cron/crontab.in file. For this, do the following:
su – mailman
These commands will result in the addition of the crontab.in file (a number of necessary crontab entries for Mailman) into mailman’s cron jobs. Once you’ve done this, you’re ready to create your test list.
Creating a test list
To create a test list, su to the mailman user. Once you are mailman, issue the following command:
You’ll be asked a few questions (name of list, list owner’s e-mail address, list password) and then you’ll be given a set of aliases. Caution: Before you press [Enter], as you’re asked to do, copy this set of aliases into the /etc/aliases file. You have to do this as root, and the entries will look something like this.
Place the outputted text at the bottom of the /etc/aliases file, save it, go back to the console where you created the test list, and press [Enter]. An e-mail will be generated and sent to the mail list owner/administrator. From that e-mail, you’ll see instructions on how to get to the Web-based administration tool.
Remember again that you’ve added aliases to your /etc/aliases file, and you must, as root, rerun the aliases command.
Is it working?
You should know right away if it’s working. As soon as the test list is created, the owner of the list (preferably yourself) will be sent an e-mail informing the owner of the list’s location and information. Also in root’s e-mail (on the server on which Mailman is running) will be any mail with error information. Other than the errors already mentioned, look for crontab errors. If you find e-mail containing crontab errors, the ./configure command was run with the wrong IDs.
It may take a number of tries to get the configuration right; it’s very dependent on how your system is set up. If you’re using a standard Red Hat 7.2 system, you’ll more than likely be able to run the ./configure command as I did. Fortunately, the returned e-mail (to root’s mail spool) will give you all the clues you need.
Once Mailman is set up, you’ve created your first test list, and you get the instructions from the e-mail, the rest is a piece of cake. Administration of individual lists is handled via a nicely done Web interface, and the application runs very smoothly. Mailman wasn’t the simplest service to get up and running, but the payoff is fairly significant.
Still having trouble?
If you’re still having trouble getting this application up and running, send Jack an e-mail so he can offer his assistance.