On 10/24/2020 6:57 PM, Mark Sapiro wrote:

On 10/24/20 3:10 PM, Dennis Putnam wrote:

...

I am getting this error:

cufsalumni@localhost.localdomain (expanded from cufsalumni@localhost): Command died with status 2: "/usr/lib/mailman/mail/mailman post cufsalumni". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "nobody", but the system's mail server executed the mail script as group "mailman". Try tweaking the mail server to run the script as group "nobody", or re-run configure, providing the command line option `--with-mail-gid=mailman'.

When I upgraded to this version of Mailman (2.1.34) I specified the configure options per the article (https://wiki.list.org/x/17892071) for RHEL. The group for '/usr/lib/mailman/mail/mailman' is indeed 'nobody'. What is this error trying to tell me. It is not clear what wrapper it is talking about since the group on the indicated script is correct.

Hi Mark,

Thanks for the reply. See embedded comments.

That's not what the error is saying. See the FAQ at https://wiki.list.org/x/4030645 for the detail.

Mailman expected the mail wrapper script to be executed as group "nobody" is because you configured --with-mail-gid=nobody and that says you expect your MTA to invoke the /usr/lib/mailman/mail/mailman wrapper as group nobody, but in fact it invoked it as group mailman.

This is still a bit confusing. I need to state that 'fetchmail' is involved here. I don't know how it interfaces but I have the 'postmaster' parameter in 'fetchmailrc' set to 'mailman'. This was not an issue with the previous version of mailman so I did not change it. That I had to use 'nobody' when installing the new version was different than the old version. I really don't know what else that would effect.

There are two things going on here. The actual group of the /usr/lib/mailman/mail/mailman wrapper should not be nobody. it should be SETGID and group mailman. check_perms should tell you that. All the wrappers /usr/lib/mailman/mail/mailman and /usr/lib/mailman/cgi-bin/* shoulkd be SETGID and group mailman so they actually execute as effective group mailman.

Yes, I ran 'check_perms' and it set it back.

The second thing is I'm guessing your MTA is Postfix and you have Mailman/Postfix integration so your Mailman aliases are in /var/lib/mailman/data/aliases. If this is the case, Postfix executes the pipe for the alias with the user/group set to the user and primary group of the owner of the .db file in which it found the alias. See the DELIVERY RIGHTS section at http://www.postfix.org/local.8.html. This means if /var/lib/mailman/data/aliases.db is owned by mailman, Postfix will invoke the wrapper as group mailman and you should configure --with-mail-gid=mailman

This is where I'm a bit confused. That aliases file is owned by mailman:mailman. I don't know what configure file you are talking about. That is not a postfix parameter as far as I know in either main.cf or master.cf. If you are referring to rebuilding mailman and the 'configure' command, that was where this started. I don't know if you recall the emails from back when I was installing 2.1.34. If I set that to 'mailman' rather than 'nobody', mailman will not start.

---

Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-leave@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/

On 10/25/2020 11:48 AM, Mark Sapiro wrote:

On 10/25/20 7:37 AM, Dennis Putnam wrote:

...

This is still a bit confusing. I need to state that 'fetchmail' is involved here. I don't know how it interfaces but I have the 'postmaster' parameter in 'fetchmailrc' set to 'mailman'. This was not an issue with the previous version of mailman so I did not change it. That I had to use 'nobody' when installing the new version was different than the old version. I really don't know what else that would effect.

Whatever the cause, the /usr/lib/mailman/mail/mailman wrapper is being invoked by group mailman so you need to start over with configure and make install with the --with-mail-gid=mailman option to configure and not with --with-mail-gid=nobody.

...

Yes, I ran 'check_perms' and it set it back.

Good. Leave it that way.

...

This is where I'm a bit confused. That aliases file is owned by mailman:mailman.

Actually, it's the aliases.db file that counts and only the owner, unless the invoking user:group comes from fetchmail.

...

I don't know what configure file you are talking about.

I'm talking about the configure command you use to configure Mailman.

...

If you are referring to rebuilding mailman and the 'configure' command, that was where this started. I don't know if you recall the emails from back when I was installing 2.1.34. If I set that to 'mailman' rather than 'nobody', mailman will not start.

Are you referring to the thread at https://mail.python.org/archives/list/mailman-users@python.org/thread/NR7ACRKU552EJYGXNLUVUVB47HF2N3QD/? If so, I don't have time at the moment to look in detail, but the issue seemed to be permissions and only changing the --with-mail-gid option from mailman to nobody would not have affected this at all.

Hi Mark,

Yes that is what I was referring to. I have this sorted out now but I don't understand it completely. There are actually 2 servers involved here. The one you helped with originally  (and on which that article was based) was RHEL 7 and that is where I used 'nobody' to get it working. This one is CentOS 7 which I thought was the same but obviously it is slightly different. So I did indeed change it to 'mailman' and now it works. Thanks again.