Bug 88083 - Upgrading to RedHat 9 results in corrupted Mailman configuration
Summary: Upgrading to RedHat 9 results in corrupted Mailman configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mailman
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: John Dennis
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-05 09:40 UTC by H. Peter Anvin
Modified: 2007-04-18 16:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-24 18:55:58 UTC
Embargoed:


Attachments (Terms of Use)
Script to create aliases (793 bytes, text/plain)
2003-04-06 09:00 UTC, H. Peter Anvin
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2003:179 0 normal SHIPPED_LIVE Mailman RPM does not properly handle package installation and upgrade. 2003-09-24 04:00:00 UTC

Description H. Peter Anvin 2003-04-05 09:40:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211

Description of problem:
The mailman included with RedHat 9 fails badly when upgrading; possibly also
when installing new.

I have found at least the following problems:

a) All mail aliases have to be changed from invoking /var/mailman/mail/wrapper
to /var/mailman/mail/mailman

b) The set of aliases for each mailing list have changed (I personally use a
separate aliases file for mailman aliases and have them auto-generated from the
current set of lists.  I recommend doing the same!)

c) One needs to add MAILMAN_USER and MAILMAN_GROUP to /var/mailman/Mailman/mm_cfg.py

d) (Possible) one needs to run the update script.

Although the web interface works "out of the box", received postings bounce or
are lost or delayed.  This is therefor a possible data loss bug.


Version-Release number of selected component (if applicable):
mailman-2.1-8

How reproducible:
Always

Steps to Reproduce:
Upgrade a working Mailman host from RH8 to RH9

Additional info:

Comment 1 Mace Moneta 2003-04-05 21:26:05 UTC
I ran into the exact same problem set as listed here when upgrading a working
Redhat 8.0 mailman to Redhat 9.  As additional info, I also had to: 

chkconfig --level 35 mailman on

(mailman was not being started at any run level).  The symptom I had when trying
to manually start was:

---

# 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

---

Adding:

MAILMAN_USER = 'mailman'
MAILMAN_GROUP = 'mailman'

to /var/mailman/Mailman/mm_cfg.py corrected that problem.

If I hadn't found this bug report, I'd be pulling my hair out; thanks to the
original reporter!

Comment 2 H. Peter Anvin 2003-04-06 09:00:58 UTC
Created attachment 90933 [details]
Script to create aliases

This is the script I use to create aliases.  This is a lot handier than
cutting-and-pasting aliases when prompted by the newlists script, and
furthermore it's a lot easier to deal with when Mailman changes aliases!

To use this, you need something like the following in /etc/mail/sendmail.mc:

define(`ALIAS_FILE',`/etc/mail/aliases,/var/mailman/aliases')dnl

Using a separate alias file for mailman-generated aliases should be pretty
obvious...

I'm obviously recommending that RedHat considers doing something like this in
their mailman package.

Comment 3 Trond Eivind Glomsrød 2003-04-15 13:42:34 UTC
I get these problems on fresh full installs as well

Comment 4 Chris Wiegand 2003-04-16 19:13:53 UTC
I just did an clean install (NOT an upgrade), and programs like ./check_perms 
and ./mailmanctl under /var/mailman/bin give an error. This bug appears to 
affect both upgrades and new installs.

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

The fix for me was to edit the mm_cfg.py in /var/mailman/Mailman and manually 
set the
MAILMAN_USER and MAILMAN_GROUP variables to 'mailman'. There is already a
MAILMAN_UID and MAILMAN_GID set, but it seems that those two scripts use 
MAILMAN_USER/_GROUP instead.

Comment 5 John Dennis 2003-04-16 19:24:00 UTC
Ack... The bug with the missing MAILMAN_USER, MAILMAN_GROUP is known and
understood. As time permits I will make a new RPM that corrects it. FYI, the
problem arises because of a philosophy conflict. The mailman build configuration
script expects the user/group "mailman" to exist before being run. Internal
build policy prohibits the creation of users and or groups on build machines. As
a consequence local build/testing did not reveal this problem, it only appeared
after the package went through the official build process. This problem only
occured as of mailman 2.1 with a change in the configure script. I have to
modify the configure script to remove the reliance on existing users/groups.
Barry (the mailman author) has agreed this is a good change. I'm sorry folks
have gotten bit by this :-(

Comment 6 John Dennis 2003-04-24 18:55:58 UTC
mailman-2.1.1-3 fixes the build problem so that MAILMAN_USER and MAILMAN_GROUP
should be properly defined in Defaults.py

Comment 7 John Dennis 2003-09-24 19:18:36 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2003-179.html


Comment 8 Robert Tindall 2004-10-03 02:59:59 UTC
Running mailman 2.1-8 and getting exactly the same behavior.

ccm-l Mailman # /etc/init.d/mailman restart
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


---

I tried setting UID and GID in mm_cfg.py as described and it has no
effect.

Comment 9 John Dennis 2004-10-04 14:18:31 UTC
Please verify that the user and group mailman exists (should be 41 for
both).

% grep mailman /etc/group
% grep mailman /etc/passwd

If both the user and group exist and are 41 then please attach a copy
of your mm_cfg.py file.

Comment 10 John Dennis 2004-10-04 14:20:17 UTC
opps, looks like email didn't go to Robert, adding him to cc list,
Robert please read previous comment.

Comment 11 Robert Tindall 2004-10-04 14:27:10 UTC
The groups existed, so I did the only intelligent thing I could think
of to do.  Tore everything out, including Postfix, and started over. 
The second time it worked, so either cosmic rays were interfering with
bit transfer from the hard drive or I did something amazingly stupid.

My vote is for the latter.

Thanks for the help, guys.


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