Added John Dennis' (RedHat) FHS patch to the contrib directory.

2 files changed, 556 insertions, 0 deletions

diff --git a/contrib/README.redhat_fhs.patch b/contrib/README.redhat_fhs.patch
new file mode 100644
index 00000000..a36d33ef
--- /dev/null
+++ b/contrib/README.redhat_fhs.patch
@@ -0,0 +1,305 @@
+The following is the contents of the post at
+<http://mail.python.org/pipermail/mailman-developers/2004-October/017343.html>.
+
+The actual patch is at redhat_fhs.patch in this (contrib/) directory.
+
+Note that this patch only patches configure.in, so if you apply this patch,
+you need to then run GNU autoconf to build the patched ./configure.
+
+
+[Mailman-Developers] FHS installation changes
+John Dennis jdennis at redhat.com
+Mon Oct 18 22:26:21 CEST 2004
+
+Overview:
+---------
+
+Earlier I wrote about our (Red Hat's) desire to make mailman be FHS
+compliant, in part to allow mailman to fall under the protection of
+SELinux security policy which is file and directory based and as a
+consequence much easier to author when packages install into canonical
+locations (e.g. FHS).
+
+Previously we had installed all of mailman under /var/mailman
+(prefix=var_prefix=/var/mailman) and I had proposed a much simpler
+change of just setting prefix=/usr/lib/mailman. This took care of the
+majority of SELinux issues and limited the scope of changes. There was
+a concern that sites and administrators who were familiar either with
+our RPM, the upstream package, or were working with an existing
+installation would run afoul of the location changes and keeping them
+to absolute minimum was advantageous. However a few folks in private
+email pointed out that if changes were going to occur its best to do
+it all at once and not piecemeal, in other words endure the pain once.
+
+Thus I embarked on an exercise to make everything FHS compliant. There
+are two reasons I'm addressing the developer community here:
+
+1) I want to apprise you of the exact changes, their rational, provide
+   a patch against 2.1.5 and solicit review.
+
+2) Test the results.
+
+Description:
+------------
+
+Currently the configuration allows for partitioning the mailman
+installation between two installation roots, prefix for non-modifiable
+files and var_prefix for variable data. This is a great start and
+covers 90% of the installation, but there remains a small set of items
+which even in this scheme are not FHS compliant, in summary:
+
+1) config files located under /etc
+
+2) pid file located under /var/run
+
+3) queue files located under /var/spool
+
+4) lock files located /var/lock
+
+5) log files located under /var/log
+
+I think one could characterize the competing installation philosophies
+as follows:
+
+Mailman not knowing what type of system its going to be installed on
+elects to group all of its files together (makes perfect sense). FHS
+on the other hand says most packages share common traits and we group
+by functional component thus spreading out package installations
+across a diverse set of directories.
+
+Implementation:
+---------------
+
+I discovered I had to add some new directories to configure and alter
+some of the *_DIR variables in Defaults.py.in so they pick up their
+values from configure. My strategy was to allow configure when run
+without providing any other parameters to produce the exact same set
+of installation defaults as previously existed so unless you specify a
+different installation mapping a user won't see any change.
+
+Configure added:
+
+--with_lock_dir
+--with_log_dir
+--with_config_dir
+--with_data_dir
+--with_pid_dir
+--with_queue_dir
+
+I also modified bin/check_perms so it was aware of the new directory
+specifications. The patch also made a few non FHS fixes to the install
+target of the Makefiles, some generic issues were discovered when
+testing check_perms. Those changes included: setting SETGID on the root
+prefix and var_prefix directories, check_perms demands all
+directories, including the roots are SETGID. The messages Makefile was
+creating a two level directory hierarchy but only setting SETGID on
+the child. Some of the "make install" logic seemed to depend on the
+property that new child directories created under a parent that was
+SETGID inherits the SETGID property. To the best of my understanding
+this is true only on Linux and Solaris and not generally portable. I
+replaced the use of the local mkinstalldirs (and subsequent chmod g+s)
+with what I believe is much more standard "install -d" and with the
+SETGID as part of the mode. All directories are created this way,
+nothing depends on inheritance. I also removed some ancient Makefile
+cruft that is no longer in use, variables no longer initialized by
+configure, etc. (just confusing, accidents waiting to happen if
+someone thought it was valid).
+
+Issues:
+-------
+
+Most of the changes were isolated to whole directories and were well
+defined. Only the contents of DATA_DIR required splitting its contents
+across more than one directory. DATA_DIR contained both pickle files
+created during processing and what would be characterized as
+configuration files (e.g. password files, MTA alias
+files. sitelist.cfg). A new directory CONFIG_DIR was created (in FHS
+its /etc/mailman) to hold what has traditionally been in /etc
+(e.g. configuration, passwords, aliases, etc). The other things that
+were in DATA_DIR was left there.
+
+The mailman configuration file presented the biggest challenge and the
+one exception to FHS. The culprit is mm_cfg.py. This is really
+mailman's configuration file and it should be located in CONFIG_DIR
+(/etc/mailman). But there were several major problems with moving that
+file there.
+
+1) It's executable python code, not a text file containing
+   configuration parameters. Executable code should be in a "lib" or
+   "bin" location. Why is this an issue? Because SELinux pays very
+   close attention to who can execute and with precise control over a
+   host of run time operations, its often based on directory
+   location. But most importantly config files have to be editable,
+   security properties transit when modified and new files pick up
+   security properties of the directory that contains the file. We do
+   not want any file created (or modified) in a configuration
+   directory to pick up security permissions granting execution
+   rights or for that matter any other run time security permissions.
+
+2) The import of mm_cfg and its directory (Mailman) is all through the
+   code, it would be very invasive to change. If mm_cfg continues to be
+   executable python code as opposed to a text file then paths.py
+   would have to be altered to prepend /etc/mailman to the import
+   path, another significant security violation.
+
+3) Any experienced mailman admin will know that mm_cfg.py is located
+   with the rest of the mailman executable code under $prefix/Mailman
+   and will expect to find this critical file there.
+
+I concluded for the above reasons that mm_cfg.py in the 2.1.x
+time frame was best handled as an FHS exception. Our rpm does however
+create a symbolic link from /etc/mailman/mm_cfg.py to
+$prefix/Mailman/mm_cfg.py so that it "appears" in configuration
+directory. This will prepare admins to start looking for mm_cfg along
+with the other configuration files. Note that security policies do not
+transit across links therefore there are no security policy issues
+with the sym link in /etc/mailman. Hopefully in MM 3.0 the
+configuration file will be textural which will eliminate the security
+policy issue. Also note that sitelist.cfg was completely moved to
+/etc/mailman as that is not executed, but rather "evaluated" (I think
+evaluation in /etc is fine, but I'm not 100% positive :-).
+
+Request for testing:
+--------------------
+
+I have created RPM's with the changes outlined above and documented
+below, you may obtain them here:
+
+ftp://people.redhat.com/jdennis/mailman-2.1.5-26.i386.rpm
+ftp://people.redhat.com/jdennis/mailman-2.1.5-26.src.rpm
+
+I have tested the new rpm and have not found any problems. The
+modified check_perms does not report any problems. But I'm well aware
+my testing is limited and my comprehension of mailman is limited, it
+is inevitable something has been missed that only wider testing will
+reveal and I would appreciate that testing by experts. These changes
+are slated to appear in our Fedora Core 3 release which is closing in
+a couple of days in preparation for release. Testing prior to that
+close would be appreciated. Note that with Fedora Core 3 SELinux will
+be enabled by default in "targeted mode". This means that SELinux
+policy will be applied to key system services only, mail and hence
+mailman is one of those key system services. Ideally any testing
+should be done from "rawhide" with the 2.1.5-26 version of mailman and
+the new matching SELinux security policy, but I would be perfectly
+happy for any testing of the basic rpm even if its not running under
+targeted security policy.
+
+Patch File:
+-----------
+
+Attached is the patch made against a virgin 2.1.5 tarball with the
+changes outlined above.
+
+
+User / Admin Documentation:
+---------------------------
+
+The following is what I prepared for our installation documentation
+which can be found in /usr/share/doc/mailman-*
+
+
+
+IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN
+INSTALLATION OR THOSE FAMILIAR 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/lib/mailman, library code,
+    executables, and scripts are located in /usr/lib/mailman, lock files are in
+    /var/lock/mailman, the pid file is in /var/run/mailman, qfiles are in /var/spool/mailman,
+    and configuration files have been moved to the new /etc/mailman
+
+    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.
+
+    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
+
+
+-- 
+John Dennis <jdennis at redhat.com>
diff --git a/contrib/redhat_fhs.patch b/contrib/redhat_fhs.patch
new file mode 100644
index 00000000..e05347f6
--- /dev/null
+++ b/contrib/redhat_fhs.patch
@@ -0,0 +1,251 @@
+Only in mailman-2.1.5.FHS: autom4te.cache
+diff -r -u mailman-2.1.5.orig/bin/check_perms mailman-2.1.5.FHS/bin/check_perms
+--- mailman-2.1.5.orig/bin/check_perms	2003-03-31 15:07:55.000000000 -0500
++++ mailman-2.1.5.FHS/bin/check_perms	2004-10-08 16:05:09.000000000 -0400
+@@ -164,7 +164,8 @@
+         print _('checking mode for %(prefix)s')
+     dirs = {}
+     for d in (mm_cfg.PREFIX, mm_cfg.EXEC_PREFIX, mm_cfg.VAR_PREFIX,
+-              mm_cfg.LOG_DIR):
++              mm_cfg.CONFIG_DIR, mm_cfg.DATA_DIR, mm_cfg.LOCK_DIR,
++              mm_cfg.LOG_DIR, mm_cfg.QUEUE_DIR, mm_cfg.PID_DIR):
+         dirs[d] = True
+     for d in dirs.keys():
+         try:
+Only in mailman-2.1.5.FHS/bin: check_perms~
+Only in mailman-2.1.5.FHS: config.log
+Only in mailman-2.1.5.FHS: configure
+diff -r -u mailman-2.1.5.orig/configure.in mailman-2.1.5.FHS/configure.in
+--- mailman-2.1.5.orig/configure.in	2003-12-24 12:11:48.000000000 -0500
++++ mailman-2.1.5.FHS/configure.in	2004-09-30 16:13:56.000000000 -0400
+@@ -180,7 +180,7 @@
+ AC_SUBST(VAR_PREFIX)
+ AC_MSG_CHECKING(for --with-var-prefix)
+ AC_ARG_WITH(var-prefix, dnl
+-[  --with-var-prefix     directory for mutable data [/var/mailman]])
++[  --with-var-prefix    directory for mutable data [/var/mailman]])
+ case "$with_var_prefix" in
+         yes)    VAR_PREFIX="$default_var_prefix"; ans=$VAR_PREFIX;;
+         ""|no)  VAR_PREFIX="$prefix"; ans="no";;
+@@ -207,6 +207,61 @@
+     prefixcheck=$VAR_PREFIX
+ fi
+ 
++# Get the configuration file directory
++AC_SUBST(CONFIG_DIR)
++AC_MSG_CHECKING(for --with-config-dir)
++AC_ARG_WITH(config-dir, dnl
++[  --with-config-dir    specify directory for configuration data other than [VAR_]PREFIX/data])
++case "$with_config_dir" in
++    yes|no|"") CONFIG_DIR="$VAR_PREFIX/data";;
++    *)         CONFIG_DIR=$with_config_dir;;
++esac
++AC_MSG_RESULT($CONFIG_DIR)
++
++# Get the lock directory
++AC_SUBST(LOCK_DIR)
++AC_MSG_CHECKING(for --with-lock-dir)
++AC_ARG_WITH(lock-dir, dnl
++[  --with-lock-dir    specify directory for lock files other than [VAR_]PREFIX/locks])
++case "$with_lock_dir" in
++    yes|no|"") LOCK_DIR="$VAR_PREFIX/locks";;
++    *)         LOCK_DIR=$with_lock_dir;;
++esac
++AC_MSG_RESULT($LOCK_DIR)
++
++# Get the log directory
++AC_SUBST(LOG_DIR)
++AC_MSG_CHECKING(for --with-log-dir)
++AC_ARG_WITH(log-dir, dnl
++[  --with-log-dir    specify directory for log files other than [VAR_]PREFIX/logs])
++case "$with_log_dir" in
++    yes|no|"") LOG_DIR="$VAR_PREFIX/logs";;
++    *)         LOG_DIR=$with_log_dir;;
++esac
++AC_MSG_RESULT($LOG_DIR)
++
++# Get the pid directory
++AC_SUBST(PID_DIR)
++AC_MSG_CHECKING(for --with-pid-dir)
++AC_ARG_WITH(pid-dir, dnl
++[  --with-pid-dir    specify directory for the pid file other than [VAR_]PREFIX/data])
++case "$with_pid_dir" in
++    yes|no|"") PID_DIR="$VAR_PREFIX/data";;
++    *)         PID_DIR=$with_pid_dir;;
++esac
++AC_MSG_RESULT($PID_DIR)
++
++# Get the queue directory
++AC_SUBST(QUEUE_DIR)
++AC_MSG_CHECKING(for --with-queue-dir)
++AC_ARG_WITH(queue-dir, dnl
++[  --with-queue-dir    specify directory for queue files other than [VAR_]PREFIX/qfiles])
++case "$with_queue_dir" in
++    yes|no|"") QUEUE_DIR="$VAR_PREFIX/qfiles";;
++    *)         QUEUE_DIR=$with_queue_dir;;
++esac
++AC_MSG_RESULT($QUEUE_DIR)
++
+ # new macro for finding group names
+ AC_DEFUN(MM_FIND_GROUP_NAME, [
+ # $1 == variable name
+@@ -619,7 +674,7 @@
+            templates/Makefile cron/Makefile scripts/Makefile messages/Makefile
+            cron/crontab.in misc/mailman Makefile
+            tests/Makefile tests/bounces/Makefile tests/msgs/Makefile
+-           $SCRIPTS],
++           $SCRIPTS ],
+         echo "configuration completed at" `date`)
+ 
+ # Make sure all the build scripts are executable.
+Only in mailman-2.1.5.FHS: configure.in~
+diff -r -u mailman-2.1.5.orig/Mailman/Defaults.py.in mailman-2.1.5.FHS/Mailman/Defaults.py.in
+--- mailman-2.1.5.orig/Mailman/Defaults.py.in	2004-04-24 22:30:03.000000000 -0400
++++ mailman-2.1.5.FHS/Mailman/Defaults.py.in	2004-10-08 14:38:57.000000000 -0400
+@@ -1198,9 +1198,11 @@
+ 
+ # Useful directories
+ LIST_DATA_DIR   = os.path.join(VAR_PREFIX, 'lists')
+-LOG_DIR         = os.path.join(VAR_PREFIX, 'logs')
+-LOCK_DIR        = os.path.join(VAR_PREFIX, 'locks')
++LOG_DIR         = '@LOG_DIR@'
++LOCK_DIR        = '@LOCK_DIR@'
++CONFIG_DIR      = '@CONFIG_DIR@'
+ DATA_DIR        = os.path.join(VAR_PREFIX, 'data')
++PID_DIR         = '@PID_DIR@'
+ SPAM_DIR        = os.path.join(VAR_PREFIX, 'spam')
+ WRAPPER_DIR     = os.path.join(EXEC_PREFIX, 'mail')
+ BIN_DIR         = os.path.join(PREFIX, 'bin')
+@@ -1211,7 +1213,7 @@
+ PRIVATE_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'private')
+ 
+ # Directories used by the qrunner subsystem
+-QUEUE_DIR       = os.path.join(VAR_PREFIX, 'qfiles')
++QUEUE_DIR       = '@QUEUE_DIR@'
+ INQUEUE_DIR     = os.path.join(QUEUE_DIR, 'in')
+ OUTQUEUE_DIR    = os.path.join(QUEUE_DIR, 'out')
+ CMDQUEUE_DIR    = os.path.join(QUEUE_DIR, 'commands')
+@@ -1225,9 +1227,9 @@
+ MAILDIR_DIR     = os.path.join(QUEUE_DIR, 'maildir')
+ 
+ # Other useful files
+-PIDFILE = os.path.join(DATA_DIR, 'master-qrunner.pid')
+-SITE_PW_FILE = os.path.join(DATA_DIR, 'adm.pw')
+-LISTCREATOR_PW_FILE = os.path.join(DATA_DIR, 'creator.pw')
++PIDFILE = os.path.join(PID_DIR, 'master-qrunner.pid')
++SITE_PW_FILE = os.path.join(CONFIG_DIR, 'adm.pw')
++LISTCREATOR_PW_FILE = os.path.join(CONFIG_DIR, 'creator.pw')
+ 
+ # Import a bunch of version numbers
+ from Version import *
+Only in mailman-2.1.5.FHS/Mailman: Defaults.py.in~
+diff -r -u mailman-2.1.5.orig/Mailman/MTA/Postfix.py mailman-2.1.5.FHS/Mailman/MTA/Postfix.py
+--- mailman-2.1.5.orig/Mailman/MTA/Postfix.py	2003-03-31 16:49:43.000000000 -0500
++++ mailman-2.1.5.FHS/Mailman/MTA/Postfix.py	2004-10-08 16:02:20.000000000 -0400
+@@ -32,8 +32,8 @@
+ from Mailman.Logging.Syslog import syslog
+ 
+ LOCKFILE = os.path.join(mm_cfg.LOCK_DIR, 'creator')
+-ALIASFILE = os.path.join(mm_cfg.DATA_DIR, 'aliases')
+-VIRTFILE = os.path.join(mm_cfg.DATA_DIR, 'virtual-mailman')
++ALIASFILE = os.path.join(mm_cfg.CONFIG_DIR, 'aliases')
++VIRTFILE = os.path.join(mm_cfg.CONFIG_DIR, 'virtual-mailman')
+ 
+ try:
+     True, False
+Only in mailman-2.1.5.FHS/Mailman/MTA: Postfix.py~
+Only in mailman-2.1.5.orig: mailman-FHS.patch
+diff -r -u mailman-2.1.5.orig/Makefile.in mailman-2.1.5.FHS/Makefile.in
+--- mailman-2.1.5.orig/Makefile.in	2003-03-31 14:26:57.000000000 -0500
++++ mailman-2.1.5.FHS/Makefile.in	2004-10-15 16:48:17.000000000 -0400
+@@ -28,6 +28,11 @@
+ prefix=		@prefix@
+ exec_prefix=	@exec_prefix@
+ var_prefix=	@VAR_PREFIX@
++configdir=	@CONFIG_DIR@
++lockdir=	@LOCK_DIR@
++logdir=		@LOG_DIR@
++piddir=		@PID_DIR@
++queuedir=	@QUEUE_DIR@
+ DESTDIR=
+ 
+ CC=		@CC@
+@@ -41,8 +46,12 @@
+ OPT=		@OPT@
+ CFLAGS=		@CFLAGS@ $(OPT) $(DEFS)
+ 
++FHS_DIRS= \
++	${configdir} ${lockdir} ${logdir} ${piddir} ${queuedir}
++
++
+ VAR_DIRS= \
+-	logs archives lists locks data spam qfiles \
++	archives lists data spam \
+ 	archives/private archives/public
+ 
+ ARCH_INDEP_DIRS= \
+@@ -96,6 +105,15 @@
+ 	    else true; \
+ 	    fi; \
+ 	done
++	@for d in $(FHS_DIRS); \
++	do \
++	    dir=$(DESTDIR)/$$d; \
++	    if test ! -d $$dir; then \
++		echo "Creating directory $$dir"; \
++		$(INSTALL) -d -m $(DIRMODE) $$dir; \
++	    else true; \
++	    fi; \
++	done
+ 	chmod o-r $(DESTDIR)$(var_prefix)/archives/private
+ 	@for d in $(ARCH_INDEP_DIRS); \
+ 	do \
+Only in mailman-2.1.5.FHS: Makefile.in~
+Only in mailman-2.1.5.FHS/messages: Makefile.in~
+diff -r -u mailman-2.1.5.orig/misc/mailman.in mailman-2.1.5.FHS/misc/mailman.in
+--- mailman-2.1.5.orig/misc/mailman.in	2003-09-25 18:13:26.000000000 -0400
++++ mailman-2.1.5.FHS/misc/mailman.in	2004-10-06 16:15:28.000000000 -0400
+@@ -24,13 +24,13 @@
+ # On Debian, type "update-rc.d mailman defaults"
+ # On RedHat, and derivatives, install with "chkconfig --add mailman"
+ #
+-# chkconfig: 2345 98 12
++# chkconfig: - 98 12
+ # description: Mailman is the GNU Mailing List Manager, a program that \
+ #              manages electronic mail discussion groups.  For more \
+ #              on GNU Mailman see http://www.list.org
+ # processname: mailmanctl
+ # config: @prefix@/Mailman/mm_cfg.py
+-# pidfile: @prefix@/data/master-qrunner.pid
++# pidfile: @PID_DIR@/master-qrunner.pid
+ 
+ PYTHON=@PYTHON@
+ MAILMANHOME=@prefix@
+Only in mailman-2.1.5.FHS/misc: mailman.in~
+diff -r -u mailman-2.1.5.orig/misc/Makefile.in mailman-2.1.5.FHS/misc/Makefile.in
+--- mailman-2.1.5.orig/misc/Makefile.in	2004-05-13 23:34:34.000000000 -0400
++++ mailman-2.1.5.FHS/misc/Makefile.in	2004-10-13 14:00:19.000000000 -0400
+@@ -26,6 +26,12 @@
+ prefix=   	@prefix@
+ exec_prefix=	@exec_prefix@
+ var_prefix=	@VAR_PREFIX@
++configdir=	@CONFIG_DIR@
++lockdir=	@LOCK_DIR@
++logdir=		@LOG_DIR@
++piddir=		@PID_DIR@
++queuedir=	@QUEUE_DIR@
++MAILMAN_GROUP=  @MAILMAN_GROUP@
+ DESTDIR=
+ 
+ CC=		@CC@
+@@ -84,7 +90,7 @@
+ 	    $(INSTALL) -m $(FILEMODE) paths.py $$dir; \
+ 	done
+ 	$(INSTALL) -m $(EXEMODE) mailman $(DESTDIR)$(SCRIPTSDIR)
+-	$(INSTALL) -m $(FILEMODE) sitelist.cfg $(DESTDIR)$(DATADIR)
++	$(INSTALL) -m $(FILEMODE) sitelist.cfg $(DESTDIR)$(configdir)
+ 
+ install-packages:
+ 	for p in $(PACKAGES); \
+Only in mailman-2.1.5.FHS/misc: Makefile.in~
+Only in mailman-2.1.5.FHS/templates: Makefile.in~