Description of Problem:
Mailman won't run if if the incoming mail delivery isn't running as the GID
specified at compile time. There are many ways to tie Postfix and Mailman
together, in many of those scenarios, the incoming mail delivery runs as user
and group mailman.
Luckily we can compile in multiple GID values, so this is easy to fix.
In the SPEC file, change:
%define mailgroup mail,nobody
%define mailgid 12,99
%define mailgroup mail,nobody,mailman
%define mailgid 12,99,41
I've tested this and it solves the problem.
Version-Release number of selected component (if applicable):
This also applies to Limbo/Null, etc.
This applies to Red Hat Linux 8.0 as well. This seems like an easy bug to fix. :)
Any comment on this? This enables better integration of mailman and Postfix.
I have just picked up ownership of the mailman and postfix RPM's here at RedHat.
So I'm just coming up to speed on their issues. I am in the process of upgrading
the mailman RPM to the new 2.1 release and going through the spec file. The
package build has already brought issues to light with user id's so I will
definately be looking at this. Please be patient, I do have a goal to get new
versions of these packages out for 8.1. With luck I hope to have a new mailman
package pushed out to Rawhide by tomorrow and will look for help verifying the
robustness of the package from those who are experts in using it.
Will any changes be needed to my exisitng mailman data/configs in order to test
Mailman 2.1? I am currently using mailman-2.0.13-1.
Dax wrote that "Luckily we can compile in multiple GID values, so this is easy
Unfortunately that is not true, only one gid is every compiled in. One can
specify multiple gid's to the configure script, but the configure script treats
this as an ordered list, it steps through the list testing each gid in the list
until it finds a valid one. This gid is then passed as the MAIL_GROUP macro when
This creates a problem for producing a binary RPM because the id's that will be
selected from the list are those on the build machine that produced the binary
RPM, not the target machine the RPM will be installed on. If the gid is not
appropriate for the target machine the user could get the SRPM and do a build
and then install the resulting RPM, that should fix the problem for the user.
Thus I'm happy to add the extra gid to the spec file, but its less than the
solution I think you're looking for because it won't work for binary RPM's which
is what the majority of user's install.
Also, its important to note the syntax for specifying multiple id's is with
whitespace separation between the ids (or symbolic names), NOT with commas, I
have no idea how the previous spec file worked. In both the previous release and
the new 2.1 release the list is passed to the python split() string function.
Without any arguments to split() the separation tokens default to whitespace.
"...but the configure script treats this as an ordered list, it steps through
the list testing each gid in the list until it finds a valid one. This gid is
then passed as the MAIL_GROUP macro whencompiling src/mail-wrapper.c"
Additional -- not understood things are happening then since when doing:
%define mailgid 12,99,41
It works. And the wrapper is OK with being invoked as GID 41.
By your description above only '12' should be getting compiled in as GID 12
exists on all Red Hat machines and is first in the list.
O.K., I see what is going on now. The pristine upstream mailman sources only
allow a single gid. But there was a patch on the old 2.0.9 release that allowed
for multiple gid's. I had been working on the assumption the patches from 2.0.9
had been submitted and accepted by the upstream maintainers and I didn't need to
bring old patches forward into the current release. This does look like a
worthwhile patch to pull forward.
Someone should see if the Mailman developers will accept that patch.
this was fixed long ago, the bug should have been closed out. Patches were sent