This file contains instructions for how to complete the installation

of mailman after you have installed the Red Hat mailman RPM. There are

certain items you will need to manually configure as the RPM is not

capable of doing every installation and confirguration task.

First, you should note that the RPM has installed mailman in the

following directory:

@prefix@

You may want to examine this directory to find additional mailman

documentation, or other mailman files.

IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN

INSTALLATION OR THOSE FAMILAR WITH "STANDARD MAILMAN INSTALLATIONS"

    Earlier Red Hat mailman rpms installed all of the mailman files under

    /var/mailman. This did not conform to the Filesystem Hierarchy

    Standard (FHS) and created security violations when SELinux is

    enabled. As of mailman-2.1.5-21 the following directory and file

    changes occurred:

    variable data (e.g. lists) is in @VAR_PREFIX@, library code,

    executables, and scripts are located in @prefix@, lock files are in

    @LOCK_DIR@, the pid file is in @PID_DIR@, qfiles are in @QUEUE_DIR@,

    and configuration files have been moved to the new @CONFIG_DIR@.

    If you previously had mailman installed and have edited files in

    /var/mailman (e.g. configuration) you will need to move those changes

    to their new locations.

    A script has been provided to aid in the task of migrating your

    mailman datafiles, it is contrib/migrate-fhs, run with -h for help

    information.

    The mapping of old locations to new locations is as follows:

    Directory Mapping:

    /var/mailman				--> /var/lib/mailman

    /var/mailman/Mailman			--> /usr/lib/mailman/Mailman

    /var/mailman/archives			--> /var/lib/mailman/archives

    /var/mailman/bin				--> /usr/lib/mailman/bin

    /var/mailman/cgi-bin			--> /usr/lib/mailman/cgi-bin

    /var/mailman/cron				--> /usr/lib/mailman/cron

    /var/mailman/data				--> /var/lib/mailman/data

    /var/mailman/lists				--> /var/lib/mailman/lists

    /var/mailman/locks				--> /var/lock/mailman

    /var/mailman/logs				--> /var/log/mailman

    /var/mailman/mail				--> /usr/lib/mailman/mail

    /var/mailman/messages			--> /usr/lib/mailman/messages

    /var/mailman/pythonlib			--> /usr/lib/mailman/pythonlib

    /var/mailman/qfiles				--> /var/spool/mailman

    /var/spool/mailman/qfiles			--> /var/spool/mailman

    /var/mailman/scripts			--> /usr/lib/mailman/scripts

    /var/mailman/spam				--> /var/lib/mailman/spam

    /var/mailman/templates			--> /usr/lib/mailman/templates

    /var/mailman/tests				--> /usr/lib/mailman/tests

    File Mapping:

    /var/mailman/data/adm.pw			--> /etc/mailman/adm.pw

    /var/mailman/data/creator.pw		--> /etc/mailman/creator.pw

    /var/mailman/data/aliases			--> /etc/mailman/aliases

    /var/mailman/data/virtual-mailman		--> /etc/mailman/virtual-mailman

    /var/mailman/data/sitelist.cfg		--> /etc/mailman/sitelist.cfg

    /var/mailman/data/master-qrunner.pid	--> /var/run/mailman/master-qrunner.pid

    Discussion of directory and file relocation:

    Two new directories were created and three existing directories which

    were hardcoded are now configurable.

    PID_DIR is used to hold the process id and is new because FHS wants

    pid files to be located in /var/run. The FHS says when there is only a

    single pid file it should be located in /var/run/<name>.pid, and when

    there are multiple pid's files they should be located together in a

    subdirectory, /var/run/<name>/. Currently mailman only has a single

    pid file, but it does have multiple processes (qrunners). Also SELinux

    security policy is easier to write if processes are segregated into

    individual subdirectories. Therefore we elected to place the mailman

    pid file in its own subdirectory, there is some debate if this is 100%

    FHS compliant because there is only currently a single pid file, but

    this gives us greater future flexibility and is in the spirit of FHS.

    CONFIG_DIR is used to hold the site configuration files. FHS wants

    configuration files stored in /etc/mailman. Previously configuration

    files were mixed in with data files in DATA_DIR and with the run-time

    code (e.g. Mailman/mm_cfg.py). CONFIG_DIR continues to exist but is

    now restricted to data files (e.g. python pickle files). The password

    files, alias files, and .cfg (e.g. sitelist.cfg) files have been moved

    to CONFIG_DIR. mm_cfg.py which is the primary mailman configuration

    file was presented a bit of a dilemma. In theory it should be located

    in /etc/mailman, however it is executable code which argues it should

    be located with the other executable files, it has traditionally lived

    in $PREFIX/Mailman and experienced mailman admins will expect to find

    it there. Modifying all the mm_cfg import statements and paths.py was

    believed to be too invasive a change, and technically its part of the

    "Mailman" package and moving it would take it out of the package

    (although currently I don't think that presents any known

    issues). Instead a compromise approach was adopted, mm_cfg.py is

    symbolically linked into the /etc/mailman directory pointing to

    $PREFIX/Mailman/mm_cfg.py. Thus mm_cfg.py "appears" in the

    configuration directory but retains its traditional location, this was

    deemed a reasonable compromise for the mailman 2.1.x timeframe.

    sitelist.cfg has a symbolic link in its old location in the DATA_DIR

    pointing to its new location in the CONFIG_DIR.

    New Directories (can be specified as parameter to configure):

    CONFIG_DIR:	default=$VAR_PREFIX/data		FHS=/etc/mailman

    PID_DIR		default=$VAR_PREFIX/data	FHS=/var/run/mailman

    Existing directories that can now be specified as parameter to configure:

    LOCK_DIR:	default=$VAR_PREFIX/locks	FHS=/var/lock/mailman

    LOG_DIR:	default=$VAR_PREFIX/logs	FHS=/var/log/mailman

    QUEUE_DIR	default=$VAR_PREFIX/qfiles	FHS=/var/spool/mailman

You can find addition documentation in the

@DOC_DIR@/README.* files and/or

@prefix@/README.* files.

Mailman is an open source project and full documentation, current

sources, patches, etc. can be found at the following official mailman

web sites:

http://www.gnu.org/software/mailman/mailman.html

http://www.list.org

1. Final installation instructions:

    Congratulations!  You've installed the Mailman software.  To get

    everything running you need to hook Mailman up to both your web

    server and your mail system.

    - If you plan on running your MTA and web server on different

      machines, sharing Mailman installations via NFS, be sure that

      the clocks on those two machines are synchronized closely.  You

      might take a look at the file Mailman/LockFile.py; the constant

      CLOCK_SLOP helps the locking mechanism compensate for clock skew

      in this type of environment.

    - Configure your web server. The RPM has made the assumption you

      are running the apache web server (httpd). The RPM has installed

      a mailman config file (@HTTPD_CONF_FILE@) in @HTTPD_CONF_DIR@.

      You should edit the file to set your domain, see the

      instructions in the config file.

      Now restart your web server so the new settings take effect:

      % /sbin/service httpd restart

    - Create the site password using:

      % @prefix@/bin/mmsitepass <your-site-password>

      This password can be used anywhere that individual user or

      mailing list administrator passwords are required, giving the

      mailman site administrator the ability to adjust these things

      when necessary.

      You may also want to create a password for the site-wide "list

      creator" role (someone other than the site administrator who as

      privileges to create and remove lists through the web).  Use the

      -c option to mmsitepass to set this.

    - Set the values for DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST in

      @prefix@/Mailman/mm_cfg.py file if the fqdn of the host you are

      running mailman on is not the email and url host you need to use.

    - Update Mailman list files to new verson by running:

      @prefix@/bin/update

      Users upgrading from previous releases of this package may need

      to move their data or adjust the configuration files to point to

      the locations where their data is.

    - Create a "site-wide" mailing list (Note: this must be done

      before starting the mailman daemon). This is the one that

      password reminders will appear to come from.  Usually this

      should be the "mailman" mailing list, but if you need to change

      this, be sure to change the MAILMAN_SITE_LIST variable in

      mm_cfg.py (see below).

      % @prefix@/bin/newlist mailman

      Follow the prompts, and see the README file for more

      information.

    - Start the Mailman qrunner daemon

      As of mailman version 2.1 mailman requires a service (daemon) to be

      run for mailman to operate. RedHat does not ship RPM's that enable

      services as part of package installation. You will need to enable

      the mailman service if you want mailman to run.

      To enable the mailman service after package installation you may run

      the "serviceconf" GUI tool, or you may do the following on the

      command line as root.

      /sbin/service mailman start

      To have the mailman service automatically start at certain run

      levels (replace the runlevel below with your desired run levels, for

      example to start mailman at run levels 3 and 5 runlevel would be 35:

      /sbin/chkconfig --level runlevel mailman on

    - You should then subscribe yourself to the mailman list.

2. Customize Mailman

    You should do these steps using the account you installed Mailman

    under in section 2 above.

    - The file @prefix@/Mailman/Defaults.py contains a number of

      defaults for your installation.  If any of these are incorrect,

      override them in @prefix@/Mailman/mm_cfg.py.

      DO NOT EDIT Defaults.py!

      Note: If you have upgraded your mailman installation RPM will

      save a copy of your previous version of mm_cfg.py in

      mm_cfg.py.rpmsave.

      See the comments in Defaults.py for details.  Once a list is

      created, editing many of these variables will have no effect.

      At that point, you'll need to configure your lists through the

      web admin interface or through the command line script

      @prefix@/bin/withlist or @prefix@/bin/config_list.

      Note: Do *not* change HOME_DIR or MAILMAN_DIR.  These are set

      automatically by the configure script when the RPM was created.

    - Create the site password using:

      % @prefix@/bin/mmsitepass <your-site-password>

      This password can be used anywhere that individual user or

      mailing list administrator passwords are required, giving the

      mailman site administrator the ability to adjust these things

      when necessary.

      You may also want to create a password for the site-wide "list

      creator" role (someone other than the site administrator who as

      privileges to create and remove lists through the web).  Use the

      -c option to mmsitepass to set this.

3. Troubleshooting

    If you encounter problems with running Mailman, first check the

    "Common Problems" section, below.  If your problem is not covered

    there, check both the FAQ file and the online FAQ Wizard.

    Check for errors in the mailman log files which can be found in

    @LOG_DIR@

    Mailman logs errors to this file:

    @LOG_DIR@/error

    If you encounter an error, send an error report to

    mailman-users@python.org.  Include a description of what you're

    doing to cause the problem, and the relevant lines from your

    syslog.  Also include information on your operating system, which

    version of Python you're using, and which version of Mailman

    you're installing.

4. Common Problems

    Problem:  All Mailman web pages give a 404 File not found error.

    Solution: Your web server has not been set up properly for handling

              Mailman's cgi commands.  Make sure you've:

              1) Configured the web server to give permissions to

                 @prefix@/cgi-bin

              2) Restarted the web server properly.

              Consult your web server's documentation for instructions

              on how to do these things.

    Problem:  All Mailman web pages give an "Internal Server Error".

    Solution: The likely problem is that you are using the wrong GID or

              UID for CGI scripts.  Check your syslog.  If you see, for

              example, a line like:

                  Attempt to exec script with invalid gid 51, expected 99

              You need to reinstall Mailman, and specify $CGI_GID to be 51,

              as described in the installation instructions.

    Problem:  I send mail to the list, and get back mail saying the

              list is not found!

    Solution: You probably didn't add the necessary aliases to the system

              alias database, given to you when you ran the newlist

              command.  If you did add them, you likely did not update

              the alias database, or your system requires you to run

              newaliases explicitly.  Refer to section 5 above for

              more information.

    Problem:  I send mail to the list, and get back mail saying,

              "unknown mailer error".

    Solution: The likely problem is that you are using the wrong GID or

              UID for mail.  Check your syslog.  If you see, for

              example, a line like:

                  Attempt to exec script with invalid gid 51, expected 99

              You need to reinstall Mailman, and specify $MAIL_GID to

              be 51, as described in the installation

              instructions. see notes on Postfix below, as by default

              it will create these problems on installation.

    Problem:  I use Postfix for my MTA and the mail wrapper programs

              are logging complaints about the wrong GID.

    Solution: Create a separate aliases file for Postfix in its

              main.cf config file under the variable "alias_maps". Put

              the file somewhere in Mailman's home directory, or

              somewhere else where the user mailman has write access

              to it; *as user mailman* call Postfix's "postalias" on the

              alias file.

              % postalias <the alias file>

              Also as user mailman, run

              % python -c'import os; print os.getgid()'

              This should print out the group id that Mailman should

              be configured to expect when the mail wrapper programs

              are run.  Call it "thegid".  Rebuild Mailman with

              % ./configure --with-mail-gid=thegid

              See also the "Using the Postfix mail server" section of

              the mailman installation manual for more information on

              connecting Postfix and Mailman.  The manual is available

              in several formats at /usr/share/doc/mailman-*/admin/www.

    Problem:  I send mail to the list, and get back mail saying,

              "sh: mailman not available for sendmail programs"

    Solution: Your system uses sendmail restricted shell (smrsh).  You

              need to configure smrsh by creating a symbolic link from

              the mail wrapper (@prefix@/mail/mailman) to the directory

              identifying executables allowed to run under smrsh.

              Some common names for this directory are

              /var/admin/sm.bin, /usr/admin/sm.bin or /etc/smrsh.

              Note that on Debian Linux, the system makes

              /usr/lib/sm.bin, which is wrong, you will need to create

              the directory /usr/admin/sm.bin and add the link there.

              Note further any aliases newaliases spits out will need

              to be adjusted to point to the secure link to the

              wrapper.

    Problem:  I messed up when I called configure.  How do I clean

              things up and re-install?

    Solution: % make clean

              % ./configure --with-the-right-options

              % make install

-------------------- Other Useful Information -----------------

RPM Preserves User Modified Files

---------------------------------

The rpm during installation will preserve changes you have made to

configuration files and templates from a previous installation. This

is almost always what is desired. However you may want to check for

the existence of files with either the .rpmsave or the .rpmnew

extension and verify if any of these backup files created during the

RPM install exist and if you are indeed using the version of the file

you desire.

Note: The installation directory for non-data files changed from

@VAR_PREFIX@ to @prefix@ in mailman-2.1.5-20. Configuration files and

templates that were user modified in a previous installation will need

to manually move those changes from the earlier @VAR_PREFIX@ to the

new @prefix@ installation directory.

Here are a few commands that will aid you in this process:

List any rpm backup files in the mailman installation directory:

% find @prefix@ @VAR_PREFIX@ -name '*.rpm*'

List any configuration files NOT in the mailman installation directory

you might miss with the above command which also have the potental for

backup copies. Given this short list you'll have to look for a

matching backup file.

% rpm -qc mailman | egrep -v '@prefix@|@VAR_PREFIX@'

When rpm preserves a user modified file it installs the newest version

of the file by appending the .rpmnew extension to the file name thus

preserving the file but making the latest version avialable. If rpm

replaces a user modified file the file being replaced is renamed to

have the .rpmsave extension. RPM only performs these backup operations

if the file is marked as being a configuration file in the rpm spec

file, it is not performed in general on all files in the package.

Mailman Cron Jobs:

------------------

Mailman relies on the cron daemon to schedule periodic actions. These

are contained in a crontab file. Previous versions of the mailman RPM

from Red Hat created the cron jobs by running the crontab(1) command

during the RPM installation phase. The cron jobs are now handled

slightly differently. Rather than invoking crontab which loaded the

cron jobs into a private cron file a mailman crontab file is installed

into /etc/cron.d. The crontab file and the commands it runs were

modified from the upstream distribution so these commands would run

under the correct SELinux security profile.

Previously the cron jobs were installed when the RPM was

installed. This was less than optimal because the act of having the

mailman RPM installed on a system should not cause the cron jobs to

run. A better solution is to only run the mailman cron jobs if the

mailman service is enabled. This is accomplished by installing the

mailman crontab file in /etc/cron.d when the mailman service is

started by mailman init.d script (e.g. either at boot time or via

/sbin/service). When the mailman service is stopped the crontab file

is removed from /etc/cron.d. The crontab file is copied from

@prefix@/cron/crontab.in to /etc/cron.d/mailman. Thus if you edit the

cron jobs you will need to edit the master copy in @prefix@/cron

otherwise your edits will be lost the next time the mailman service is

started or restarted. To pick up any changes made to the crontab file

edit the master copy in @prefix@/cron and then use /sbin/service to

restart mailman (e.g. /sbin/service mailman restart). Some may wonder

why the crontab file in /etc/cron.d is not symbolically linked to the

master copy when the service starts and unlinked when it stops. The

reason is because newer versions of cron will refuse for security

reasons to run any crontabs which are links to other files or

writeable by anybody else except root.

Choosing your MTA (sendmail or postfix) on Red Hat Systems:

-----------------------------------------------------------

Red Hat ships two different MTA's, sendmail and postfix. Because the

sendmail and postfix rpms's share file names when installed the

conflict is accomodated by utilizing the "alternatives" mechanism

which manages a set of links. When one of the MTA's is selected via

/usr/sbin/alternatives links are established which point to the

correct files for that MTA. There are two ways to select your MTA:

The system-switch-mail package contains a GUI front end to the

alternatives mechanism and /usr/bin/system-switch-mail is an easy way

to select your MTA, or you can invoke alternatives directly like this:

% /usr/sbin/alternatives --config mta

Note: Selecting your preferred MTA is distinct from configuring the

MTA, you will need to consult the documentation for the MTA you

selected for information on how to configure it.

Local Variables:

mode: indented-text

indent-tabs-mode: nil

End: