Red Hat Bugzilla – Bug 74165
SPEC file fix for Postfix/Mailman GID
Last modified: 2014-01-21 17:48:03 EST
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 to %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): mailman-2.0.13-1
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 to fix." 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 compiling src/mail-wrapper.c. 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 upstream.