Majordomo is a nifty piece of perl that maintains mailing lists. The clever bit is that, once the system administrator at a site has completed the basic setup, the owner of the list, who doesn't actually have to have an account on the computer running Majordomo, can handle day-to-day maintenance via e-mail messages.
Majodomo was originally written by Brent Chapman after he got frustrated trying to compile and set up ListProc. The latest versions of Majordomo are maintained by John Rouillard.
Majordomo and its associated programs were designed with the Unix guiding principle in mind; that of using suites of small, easily understood tools to do surprisingly complex tasks; and it does those tasks remarkably well. It also makes for an easily extensible system. There are some problems, but—and this brings us to the second big advantage of using Majordomo—you can fix them yourself.
Majordomo is free. This means that you get all the source code and you can modify it to your heart's content. Not only that, but that source is remarkably well commented and easy to understand, especially considering how easy it is to write obfuscated perl code.
Of course, there are things about Majordomo that things like LISTSERV and ListProc do better—it doesn't handle large, busy mailing lists as efficiently as they do. It is, however, easier to administer (once you've got the aliases set up) than either of these, you don't have to pay for it, and it works with Linux.
First make sure you have the most up-to-date copy you can lay your hands on. This discussion will cover Majordomo 1.93, but who knows: 2.0 might be out by the time you read this. Whatever you do, don't use 1.92, since it had a rather nasty security hole. Majordomo's home site is ftp://ftp.greatcircle.com/pub/majordomo/.
You'll also need perl, at least version 4.035, preferably 4.036. Majordomo does run under perl 5.000 but it was developed (and is being developed) under perl 4.036. The site here is running sendmail 8.6.91, but things should work okay with smail, although I haven't tried it. See footnote 1.
Compiling Majordomo is easy. Just a couple of caveats:
Majordomo expects perl to be in /usr/local/bin/perl
As it comes out of the box there is a bug which causes Majordomo to read in the config file twice, once from /etc/majordomo.cf and once from $homedir/majordomo.cf. This is easily fixed though; simply remove the line: require `majordomo.cf'; from config_parse.pl.
For what follows, I'll assume you have set up a /etc/majordomo.cf which looks like this:
$whereami="yourhost.yourdomain"; $whoami="Majordomo@$whereami"; $whoami_owner="Owner-Majordomo@$whereami"; $homedir="/usr/lib/majordomo"; $listdir="/var/spool/majordomo/lists"; $digest_work_dir="/var/spool/majordomo/digest"; $log="$homedir/Log"; $mailer="/usr/lib/sendmail -f$sender"; $filedir="/var/spool/majordomo/archive"; $filedir_suffix=""; $index_command="/bin/ls -lRL"; $return_subject=1; $majordomo_request=0; umask(007); @archive_dirs=();
and that the directories /var/spool/majordomo/lists, /var/spool/majordomo/digest and /var/spool/majordomo/archive exist and are owned by majordomo.majordomo with mode 775.
For this I'll assume you're using sendmail 8.6.9 (purely because that's the mailer that we use here at Frontier). If you're not using a version 8 sendmail you will need to add majordom to the list of “trusted” users that sendmail allows to spoof the sender of a mail envelope (find the T line in sendmail.cf and add majordom to the list).
As root, add the following lines to your /etc/aliases file:
majordomo: "|/usr/lib/majordomo/wrapper majordomo" owner-majordomo: postmaster
Now assume you want to set up a list “test” with all the bells, whistles, and gongs that Majordomo provides. You'll need to add the lines shown in Listing 1 to your /etc/aliases file.
Run newaliases to make the aliases visible.
Now, su to majordomo and run the commands in Listing 2.
Edit /var/spool/majordomo/lists/test.config, set a new list password, and add a moderator if necessary. Hopefully it's all pretty self-explanatory. Copy test.config to test-digest.config and edit things like message_footer and message_fronter.
message_fronter << END In test today: _SUBJECTS_ END message_footer << END -- To switch to the undigested list, send this to email@example.com unsubscribe test-digest subscribe test end END
Watch out for the config sections advertise and noadvertise. These expect a list of perl regular expressions, complete with /'s. These are used when someone queries your Majordomo server for a list of lists. So, say you had a list “local-jellygarglers” which you didn't want anybody off your site to know about (and who would), you could put the following in your local-jellygarglers.config file:
advertise << END /yourdomain$/ EOF
which means that Majordomo will only mention the list in its list of lists if the sender's address is in the domain yourdomain.
The default digesting provided by Majordomo is not bad for busy lists. It waits until the digest size reaches a certain specified size (use the maxlength setting in test-digest.config to set this) then sends the digest. However, this is not a good solution if you're looking at a list which has periods of infrequent posting—especially if the majority of the lists subscribers go for the digestified version, there is the potential for a message to hang around unread in the digest queue for weeks. There are two solutions to this. The first method is to copy contrib/digest.send into /usr/lib/majordomo, editting the value of DIGESTDIR to correspond with the directory where you stash your digests, then add the line
0 2 * * * /usr/lib/majordomo/digest.send
to Majordomo's crontab file. The digest will be sent every morning at 2, no problems.
The second (and to my mind neater) method is to apply Paul Close's patch to digest and use a slightly different crontab line. The patch to digest does a couple of things. It adds the variables digest_maxlines and digest_maxdays to the list.config files. (If you do this after you've created a config file you'll need to mail the commands writeconfig test and writeconfig test-digest to majordomo so it can write out a new, valid config file again, so this is really best done before you make the config files.) These two parameters mean you can tune the digester so that a digest should never get sent with any messages older than (say) a week in it.
The patch also adds a -p switch to digest. When digest is invoked with this switch it checks to see if the digest should be sent (i.e., it checks to see if any articles in the digest are too old), and sends it out if necessary. To use this, simply change the -m to -p in the line that invokes the digest program from digest.send.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- ServersCheck's Thermal Imaging Camera Sensor
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- Petros Koutoupis' RapidDisk
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide