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: ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/mailman-2.1-2.i386.rpm If you are installing on another architecture start here and drill down to your architecture of choice. ftp://ftp.redhat.com/pub/redhat/linux/rawhide 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 errata. 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. John
mailman-2.1-3: 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.
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 ? main() File "/var/mailman/bin/mailmanctl", line 319, in main check_privs() File "/var/mailman/bin/mailmanctl", line 274, in check_privs gid = grp.getgrnam(mm_cfg.MAILMAN_GROUP)[2] 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 details.
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. http://marc.theaimsgroup.com/?l=bugtraq&m=104342745916111&w=2
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: ftp://people.redhat.com/jdennis
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: https://rhn.redhat.com/errata/RHSA-2002-176.html 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