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 groupnobody, 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 groupmailman. check_perms should tell you that. All the wrappers /usr/lib/mailman/mail/mailman and /usr/lib/mailman/cgi-bin/* shoulkd be SETGID and groupmailmanso they actually execute as effective groupmailman.
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 RIGHTSsection at http://www.postfix.org/local.8.html. This means if /var/lib/mailman/data/aliases.db is owned bymailman, Postfix will invoke the wrapper as groupmailmanand 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/