Majordomo is, of course, the piece of code that this document
revolves around; it consists of a collection of Perl scripts
with the sole purpose of managing mailing lists.
Download the gzipped source distribution of the latest
version of Majordomo from Great
Circle Associates and uncompress it
[jarchie@kes jarchie]$ tar zxvf majordomo-1.94.5.tar.gz
|
This will create a subdirectory with all of the files
necessary to install Majordomo; this directory
cannot be the same directory in which Majordomo
is to be installed.
Majordomo must run under a specific UID and GID so when any
of the scripts are run, they will run under Majordomo's UID.
Thus, it is necessary to decide what UID and GID Majordomo
should run under. Also, Majordomo must be a Sendmail trusted
user (see Section
2.2.3).
Check the /etc/passwd and
/etc/group files to find a UID and
GID that are not taken. For this example, a UID of 16 and a
GID of 16 was chosen. You have to decide on the location
where the Majordomo scripts will reside; in this HOWTO, the
directory /usr/local/majordomo-1.94.5/ was chosen. If
you are using a shadowed password file, add entries similar
to
majordomo:x:16:16:Majordomo List Manager:/usr/local/majordomo-1.94.5:
|
to your
/etc/passwd and add
an appropriate entry to
/etc/shadow.
majordomo:*:10883:0:88888:7:::
|
Use the other entries in these files as a guide for
exactly what should be added.
These are
only the values for my system. If you are not using
shadowed passwords, only an entry in the
/etc/passwd file is necessary.
To create a Majordomo group, add a line similar to
to your
/etc/group file.
Appending your username to the end of the line will give you
access to the Majordomo files that are group writable.
The Makefile contains all the
information needed to install Majordomo; it is usually
necessary to edit lines in the Makefile that refer to system specific
settings so Majordomo will be able to install cleanly on your
system. Most of the default settings are correct; however,
the following settings, almost invariably, need to be changed
on a per system basis.
[jarchie@kes majordomo-1.94.5]$ vi Makefile
|
The settings
PERL = /bin/perl
CC = cc
W_HOME = /usr/test/majordomo-$(VERSION)
MAN = $(W_HOME)/man
W_USER = 123
W_GROUP = 45
|
should be changed to something more appropriate for
your system. For example, in my setup, the values were changed
to
PERL = /usr/bin/perl
CC = gcc
W_HOME = /usr/local/majordomo-1.94.5
MAN = /usr/man
W_USER = 16
W_GROUP = 16
|
Also the
majordomo.cf file
must be created. An easy way to create this file is to copy the
provided
sample.cf file to
majordomo.cf and edit it.
[jarchie@kes majordomo-1.94.5]$ cp sample.cf majordomo.cf
[jarchie@kes majordomo-1.94.5]$ vi majordomo.cf
|
Again, most of the settings are correct by default, but
the following lines might need to be changed for your system
from
$whereami = "example.com";
$whoami = "Majordomo\@$whereami";
$whoami_owner = "Majordomo-Owner\@$whereami";
$homedir = "/usr/test/majordomo";
$digest_work_dir = "/usr/local/mail/digest";
$sendmail_command = "/usr/lib/sendmail";
|
to something more appropriate such as
$whereami = "kes.emeraldis.com";
$whoami = "majordomo\@$whereami";
$whoami_owner = "majordomo-owner\@$whereami";
$homedir = "/usr/local/majordomo-1.94.5";
$digest_work_dir = "/usr/local/majordomo-1.94.5/digest";
$sendmail_command = "/usr/sbin/sendmail";
|
$whoami and
$whoami_owner do not need to be changed for
Majordomo to work; however, I changed them because I like to
avoid typing capital letters.
$digest_work_dir is a temporary directory where
digest files should be placed; this directory should be
assigned to wherever you want digests to be stored. If you do
not plan to use digested lists, do not worry about this option.
$whereami,
$homedir, and
$sendmail_command should be changed to
appropriate values for your system. Unlike the
Makefile, these options can always be changed
after Majordomo is installed by editing
majordomo.cf in the directory where Majordomo
was installed. (The configuration file is simply copied during
setup.)
The next step is to compile the Majordomo wrapper. The
wrapper is the only Majordomo component that needs to be
compiled because everything else is a collection of perl
scripts and, therefore, is not compiled.
[jarchie@kes majordomo-1.94.5]$ make wrapper
|
To install the Majordomo files, execute the commands
[root@kes majordomo-1.94.5]# make install
[root@kes majordomo-1.94.5]# make install-wrapper
|
The first command can be done as the Majordomo user
(assuming
majordomo can create or has
access to
$home_dir), but the second
command needs to be done as
root so
the installation script can SUID root the Majordomo wrapper.
(Since,
majordomo was created without
a login shell or password, if you want to execute the first
command as
majordomo, you will need to
su majordomo as root in order to become
majordomo.)
Sendmail aliases must be created for Majordomo so commands
sent to Majordomo can be processed by majordomo, and an alias for the Majordomo owner
must be created so people can E-mail you through the standard
owner-majordomo address. Add the
following entries to your aliases file (see Section 2.1).
majordomo: "|/usr/local/majordomo-1.94.5/wrapper majordomo"
owner-majordomo: jarchie
majordomo-owner: jarchie
|
As a regular user (not as majordomo or as
root), run
[jarchie@kes jarchie]$ /usr/local/majordomo-1.94.5/wrapper config-test
|
This program can detect most problems in the Majordomo
installation.
To create a list, create a file with the name of the list in
the Majordomo lists directory. For example, to create a list
called test, create a test file as Majordomo
[root@kes /]# su majordomo
[majordomo@kes /]$ touch /usr/local/majordomo-1.94.5/lists/test
|
and add the related aliases
test: :include:/usr/local/majordomo-1.94.5/lists/test
owner-test: jarchie
test-request: "|/usr/local/majordomo-1.94.5/wrapper request-answer test"
test-approval: jarchie
|
Now test the operation of the list by issuing a lists command to Majordomo.
[jarchie@kes jarchie]$ echo lists | mail majordomo
|
It should only take a second for
majordomo to reply with a message containing all
the lists which are currently set up. Next, try issuing a
help command.
[jarchie@kes jarchie]$ echo help | mail majordomo
|
Majordomo should reply with a list of all commands that
Majordomo accepts. It might be a good idea to save the message
for future reference.
To see if the aliases are working properly, try subscribing
and unsubscribing yourself to the list.
[jarchie@kes jarchie]$ echo subscribe test | mail majordomo
|
You will receive an E-mail message containing
instructions on how to confirm your subscription as well as a
letter confirming that your command was successful. After
sending back your confirmation, Majordomo should send back two
letters--one letter stating that your subscribe request was
successful and another letter welcoming you to the test list.
The owner of the list will also be sent a message stating that
you have subscribed to the list.
To unsubscribe from a list, send a unsubscribe command
[jarchie@kes jarchie]$ echo unsubscribe test | mail majordomo
|
You should be sent back a letter stating that your
command was successful.
For some lists, it may be desirable to have Majordomo process
messages before they reach the list. For example, Majordomo
has the resend script to automatically
filter messages based on content (such as taboo words), to
prevent people from sending Majordomo commands to the list,
and other features. To use these options, it is necessary to
use a better set of aliases such as
test: "|/usr/local/majordomo-1.94.5/wrapper resend -l test test-list"
test-list: :include:/usr/local/majordomo-1.94.5/lists/test
owner-test: jarchie
test-owner: jarchie
test-request: "|/usr/local/majordomo-1.94.5/wrapper majordomo -l test"
|
The last entry allows someone simply to send a message
to
test-request@kes.emeraldis.com with
the text
subscribe rather than sending
a letter to
majordomo@kes.emeraldis.com with the text
subscribe test. Also, note that if
sendmail is using smrsh, the above aliases should reference the
copy of the wrapper in the safe path--usually
/etc/smrsh/wrapper.
It is common for Majordomo's permissions to be set
incorrectly causing Majordomo to work improperly.
Fortunately, Sendmail and Majordomo typically, give decent
error messages indicating a problem. For example, the
lists directory must be executable
by the user sendmail setuids to, typically mail or daemon. If
sendmail cannot execute lists, the permissions must be loosened.
[root@kes root]# chmod +x /usr/local/majordomo-1.94.5/lists
|
Another common problem is caused by the
lists directory being group writable. To solve
this problem, one can ether clear the group writable bit, or
use the sendmail option
IncludeFileInGroupWritableDirPath (see
Section 2.2.5 and
Section 2.4.1 for more details).
Majordomo is intended to run on a isolated system; there are
a couple of well-known security holes in the scripts that
allow any local user capable of executing wrapper to execute code as the majordomo user. If Majordomo must be run on a
system providing users with shell access, then it is
advisable to tighten up permissions on the wrapper. This can
be done by clearing the world executable bit and chgrping the wrapper to the user that needs to
run the Majordomo scripts. For example, if Sendmail and
MajorCool are both being used to execute the wrapper use the
commands
[root@kes root]# cp /usr/local/majordomo-1.94.5/wrapper /etc/smrsh/wrapper
[root@kes root]# chmod 4750 /usr/local/majordomo-1.94.5/wrapper
[root@kes root]# chown root:nobody /usr/local/majordomo-1.94.5/wrapper
[root@kes root]# chmod 4750 /etc/smrsh/wrapper
[root@kes root]# chown root:mail /etc/smrsh/wrapper
|
to secure the system. This will allow
sendmail (while running under
mail) to execute
/etc/smrsh/wrapper while allowing the webserver's
MajorCool (running under
nobody) to
execute
/usr/local/majordomo-1.94.5/wrapper. This
solution, however, will allow anyone with the UID or GID of
mail or
nobody to also obtain access to the
majordomo account. To protect the
nobody account, it is important not to allow
normal users to make use of server side includes or cgi scripts
unless those services do not run under
nobody.