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/.pid, and when there are multiple pid's files they should be located together in a subdirectory, /var/run//. 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 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 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 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: