Bug 81267 - include mailman 2.1 as it released now
Summary: include mailman 2.1 as it released now
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mailman
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-07 11:40 UTC by Daniel Resare
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2003-04-06 16:46:21 UTC

Attachments (Terms of Use)

Description Daniel Resare 2003-01-07 11:40:49 UTC
Description of problem:

The final release of mailman 2.1 seems to be here according to list.org, however
the mailman package in phoebe is still in version 2.0.x.

To have the new vesion packaged in redhat would be relly nice :)

Since this is a farily major upgrade I'd be happy to do some beta testing of the
package for you.

Comment 1 John Dennis 2003-01-07 15:45:40 UTC
I am the new package owner for mailman. I am in the process of updating the RPM
for the new release. I will aprise you when this is done. Thank you for your
offer to beta test.

Comment 2 Warren Togami 2003-01-08 20:57:40 UTC
"Me too" for beta testing.  Would changes to my existing mailman 2.0.13
files/configs be needed?

Comment 3 John Dennis 2003-01-20 15:14:14 UTC
The new mailman 2.1 package is now available, for those who are installing on
i386 architectures you can grab this file:


If you are installing on another architecture start here and drill down to your
architecture of choice.


I would appreciate feedback on any issues with the package as soon as possible
as this version will be going into the next 8.1 release which is only weeks
away. If there are problems I'd like to get them fixed so we don't have do an

A few things to note:

As one of the final steps in the package installation it runs the mailman update
script which converts your data files from your previous version to the new 2.1
version. Thus the upgrade to 2.1 should be transparent. I cannot attest to
robustness of the update script.

Mailman 2.1 now requires a daemon (mailmanctl) to be run, this is new. The
package install invokes chkconfig so that the daemon is automatically started.

The httpd config file was moved to the etc/httpd/conf.d directory to be
consistent with the rest of the httpd config files. There is some discussion as
to whether it should be renamed from httpd-mailman.conf to mailman.conf, a
subsequent package might do this.


Comment 4 Dave Habben 2003-01-25 07:22:14 UTC

Running the command:
service mailman start
works fine the first time, however if you run it multiple times you get multiple
instances of:

10997 ?        S      0:00 /usr/bin/python /var/mailman/bin/mailmanctl -s -q start
10999 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=ArchRunner:0:1 -s
11000 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=BounceRunner:0:1 -s
11001 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=CommandRunner:0:1 -s
11002 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=IncomingRunner:0:1 -s
11003 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=NewsRunner:0:1 -s
11004 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=OutgoingRunner:0:1 -s
11005 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=VirginRunner:0:1 -s
11013 ?        S      0:00 /usr/bin/python /var/mailman/bin/mailmanctl -s -q start
11014 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=ArchRunner:0:1 -s
11015 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=BounceRunner:0:1 -s
11016 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=CommandRunner:0:1 -s
11017 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=IncomingRunner:0:1 -s
11018 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=NewsRunner:0:1 -s
11019 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=OutgoingRunner:0:1 -s
11020 ?        S      0:00 qrunner /var/mailman/bin/qrunner
--runner=VirginRunner:0:1 -s

service mailman stop 
only stops the most recent 'service mailman start', not all the mailman processes.

Comment 5 John Dennis 2003-01-27 16:44:01 UTC
The mailman service script as shipped in the 2.1 mailman release passes the -s
command line argument to the mailmanctl python script (mailmanctl is where all
the real work of controlling the daemon is performed). The -s disables the check
for an existing mailman daemon, this is what is allowing you to start multiple
daemons. If the -s is removed subsequent attempts to start the daemon will fail
with the message that there is already a running daemon.

I have no idea why mailman passes the -s argument, it seems like a bad idea to
me. I'll follow up with the mailman developers and if there is a concensus about
removing it I'll update the RH RPM. In any event you shouldn't be starting the
service more than once anyway so this is proably not a serious issue.

Please also note that there is now a version 6 of the package. The previous
version started the service as part of the install which was not correct, it
also invoked "chkconfig on" which was not correct. So in summary there have been
some "fixes" for service management in the last few days. Its possible that you
were seeing multiple services running because of the problems in the RPM install
with respect to the mailman service which has now been fixed.

Comment 6 Dave Habben 2003-02-01 17:24:04 UTC
rpm -e mailman        
(This was the 2.1-3 release)

rpm -Uvh mailman-2.1-7.i386.rpm

service mailman start
Traceback (most recent call last):
  File "/var/mailman/bin/mailmanctl", line 524, in ?
  File "/var/mailman/bin/mailmanctl", line 319, in main
  File "/var/mailman/bin/mailmanctl", line 274, in check_privs
    gid = grp.getgrnam(mm_cfg.MAILMAN_GROUP)[2]
KeyError: getgrnam(): name not found

Comment 7 John Dennis 2003-02-03 15:09:12 UTC
With respect to the problem dhabben reported in version 3, this has been fixed
in subsequent versions of the RPM. The current version of the package on rawhide
is 8. FYI, the problem occurs because the mailman user and group had not yet
been created on the installation machine, thus the call to getgrnam() fails
because there is no mailman group. Subsequent versions of the RPM postpone any
mailman operation util the package is fully installed, but do require the user
to permform a minimal amount of manual configuration after installation. See
README.REDHAT in the installation directory (/var/mailman) or the spec file for

Comment 8 Dave Habben 2003-02-17 20:08:23 UTC
Is it too late in the beta to get this fix included?

2.1.1 (08-Feb-2003)

    Lots of bug fixes and language updates.  Also:

    - Closed a cross-site scripting vulnerability in the user options page.


Comment 9 John Dennis 2003-02-18 18:48:29 UTC
I have upgraded the mailman RPM to the new 2.1.1 release and made a number of 
minor fixes to the installation process and documentation. In particular please 
read INSTALL.REDHAT which can be found in /usr/share/doc/mailman-2.1.1.

I think its too late in the game to get 2.1.1 into the next RedHat release 
(8.0.1) but you can pick up the package from here:


Comment 10 Dave Habben 2003-02-18 19:01:39 UTC
If it isn't going to be updated for this release, is it going to be listed as an
errata then? Such as this previous mailman package:

Updated mailman packages close cross-site scripting vulnerability:

I'm just trying to have as few errata to install 'out-of-the-box' as possible.

Comment 11 Daniel Resare 2003-04-06 16:46:21 UTC
The original feature request in this bug seems fixed now with rh9

Note You need to log in before you can comment on or make changes to this bug.