mailman/contribs9/mailman.INSTALL.REDHAT.in

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: