rpms
/
mailman
7
0
Fork 0
Code Issues Pull Requests Releases Activity
mailman/SOURCES/mailman.INSTALL.REDHAT.in

477 lines
20 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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:
Reference in New Issue View Git Blame Copy Permalink