Red Hat Bugzilla – Bug 81267
include mailman 2.1 as it released now
Last modified: 2008-05-01 11:38:04 EDT
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.
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.
"Me too" for beta testing. Would changes to my existing mailman 2.0.13
files/configs be needed?
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.
Running the command:
service mailman start
works fine the first time, however if you run it multiple times you get multiple
10997 ? S 0:00 /usr/bin/python /var/mailman/bin/mailmanctl -s -q start
10999 ? S 0:00 qrunner /var/mailman/bin/qrunner
11000 ? S 0:00 qrunner /var/mailman/bin/qrunner
11001 ? S 0:00 qrunner /var/mailman/bin/qrunner
11002 ? S 0:00 qrunner /var/mailman/bin/qrunner
11003 ? S 0:00 qrunner /var/mailman/bin/qrunner
11004 ? S 0:00 qrunner /var/mailman/bin/qrunner
11005 ? S 0:00 qrunner /var/mailman/bin/qrunner
11013 ? S 0:00 /usr/bin/python /var/mailman/bin/mailmanctl -s -q start
11014 ? S 0:00 qrunner /var/mailman/bin/qrunner
11015 ? S 0:00 qrunner /var/mailman/bin/qrunner
11016 ? S 0:00 qrunner /var/mailman/bin/qrunner
11017 ? S 0:00 qrunner /var/mailman/bin/qrunner
11018 ? S 0:00 qrunner /var/mailman/bin/qrunner
11019 ? S 0:00 qrunner /var/mailman/bin/qrunner
11020 ? S 0:00 qrunner /var/mailman/bin/qrunner
service mailman stop
only stops the most recent 'service mailman start', not all the mailman processes.
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.
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)
KeyError: getgrnam(): name not found
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
Is it too late in the beta to get this fix included?
Lots of bug fixes and language updates. Also:
- Closed a cross-site scripting vulnerability in the user options page.
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:
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.
The original feature request in this bug seems fixed now with rh9