Group mismatch ( YES I KNOW THIS IS A FAQ BUT..)
Hi,
I know this is a FAQ and yes I've tried to read all items and still I can't find my way out so hope someone Can shed some light to this.
Just summarizing what I am about to do. I have an old mailman installation I need to port to a new server. The old one is based on EXIM as MTA but I would like to use postfix, because this is the one I use on a lot of servers. I need to make mailman virtual. I have around 20 mail domains to handle.
So I install a Ubuntu 10.04LTS 64 bit and get the packages for postfix apache2 and mailman and install No problem.
When trying to make the virtual postfix/mailman integration, I ran across a post recommending to use mailman 2.1.14 Ok - I removed the mailman package from Ubuntu , actually 2.1.13 - downloaded the 2.1.14 source Ran configure, make and make install all seems OK.
I have added following to mm_cfg.py
################################################## MTA = "Postfix" # Put YOUR site-specific settings below this line. POSTFIX_STYLE_VIRTUAL_DOMAINS = [ 'test.sdu.dk', 'some.other.domain', ......
add_virtualhost('test.sdu.dk','test.sdu.dk' add_virtualhost('some.other.domain','some.other.domain')
called check_perms -f called genaliases and checked that i have the files : my@mls2:/usr/local/mailman$ ll data/alia* -rw-rw---- 1 mailman mailman 114222 2011-06-10 09:04 data/aliases -rw-rw---- 1 mailman mailman 172032 2011-06-10 09:04 data/aliases.db my@mls2:/usr/local/mailman$ ll data/virt* -rw-rw---- 1 mailman mailman 86149 2011-06-10 09:04 data/virtual-mailman -rw-rw---- 1 mailman mailman 176128 2011-06-10 09:04 data/virtual-mailman.db
Added to postfix main.cf: transport_maps = hash:/etc/postfix/transport alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases alias_database = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman mailman_destination_recipient_limit = 1
AND in transport i have entries like: test.sdu.dk mailman: some.other.domain mailman: ....
Then when trying to send a mail to a new list I get the following in mail.log
Jun 10 08:44:22 mls2 Mailman mail-wrapper: Group mismatch error. Mailman expected the mail#012wrapper script to be executed as group "mailman", but#012the system's mail server executed the mail script as#012group "nogroup". Try tweaking the mail server to run the#012script as group "mailman", or re-run configure, #012providing the command line option --with-mail-gid=nogroup'. Jun 10 08:44:22 mls2 postfix/local[28200]: 3E460FFDF2: to=<mailman-bounces@mls2.sdu.dk>, relay=local, delay=0.03, delays=0.01/0/0/0.02, dsn=5.3.0, status=bounced (Command died with status 2: "/usr/local/mailman/mail/mailman bounces mailman". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "mailman", but the system's mail server executed the mail script as group "nogroup". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option --with-mail-gid=nogroup'. )
OK I go to the mailman source and recompile as suggested and get
Jun 10 07:28:29 mls2 Mailman mail-wrapper: Group mismatch error. Mailman expected the mail#012wrapper script to be executed as group "nogroup", but#012the system's mail server executed the mail script as#012group "mailman". Try tweaking the mail server to run the#012script as group "nogroup", or re-run configure, #012providing the command line option --with-mail-gid=mailman'. Jun 10 07:28:29 mls2 postfix/local[22760]: 711C8FFD9D: to=<its@mls2.sdu.dk>, orig_to=<its@test.sdu.dk>, relay=local, delay=14, delays=14/0.02/0/0.03, dsn=5.3.0, status=bounced (Command died with status 2: "/usr/local/mailman/mail/mailman post its". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "nogroup", but the system's mail server executed the mail script as group "mailman". Try tweaking the mail server to run the script as group "nogroup", or re-run configure, providing the command line option --with-mail-gid=mailman'. )
Permissions on mailman wrapper are: ll /usr/local/mailman/mail/mailman -rwxr-sr-x 1 root mailman 23741 2011-06-10 07:30 /usr/local/mailman/mail/mailman*
Postfix alias file has permissions: ll /etc/alias* -rw-r--r-- 1 root mailman 775 2011-06-09 15:45 /etc/aliases -rw-r--r-- 1 root mailman 12288 2011-06-10 07:43 /etc/aliases.db
From what I can see, the postfix should use the owner of the mail wrapper script and get the corresponding group and execute with that.
Can anyone help?
Regards
Peter Sorensen/Univ. Of Southern Denmark/email: maspsr@sdu.dk
On 6/10/2011 2:28 AM, Peter Sørensen wrote:
And you have conflated your Debian/Ubuntu package configuration and the standard GNU Mailman configuration.
OK
OK
Added to postfix main.cf: transport_maps = hash:/etc/postfix/transport
See below:
alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases alias_database = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases
You don't need hash:/usr/local/mailman/data/aliases in alias_database. This only makes Postfix's newaliases command do extra work. See <http://www.list.org/mailman-install/postfix-integration.html>.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman mailman_destination_recipient_limit = 1
The above, the transport maps entries below, and the mailman transport in master.cf are for postfix-to-mailman.py delivery which is an incompatible alternative to delivery vfia aliases and virtual maps.
This looks like a delivery via aliases which should work if the ownership of data/aliases.db is as above.
OK I go to the mailman source and recompile as suggested and get
Jun 10 07:28:29 mls2 Mailman mail-wrapper: Group mismatch error. Mailman expected the mail#012wrapper script to be executed as group "nogroup", but#012the system's mail server executed the mail script as#012group "mailman". Try tweaking the mail server to run the#012script as group "nogroup", or re-run configure, #012providing the command line option
--with-mail-gid=mailman'. Jun 10 07:28:29 mls2 postfix/local[22760]: 711C8FFD9D: to=<its@mls2.sdu.dk>, orig_to=<its@test.sdu.dk>, relay=local, delay=14, delays=14/0.02/0/0.03, dsn=5.3.0, status=bounced (Command died with status 2: "/usr/local/mailman/mail/mailman post its". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "nogroup", but the system's mail server executed the mail script as group "mailman". Try tweaking the mail server to run the script as group "nogroup", or re-run configure, providing the command line option--with-mail-gid=mailman'. )
And Postfix invoking the wrapper as group 'mailman' is what should have happened above.
Now you should reconfigure with --with-mail-gid=mailman and try again. I'm guessing that for the first try above when Postfix invoked the wrapper as 'nogroup', the owner of data/aliases.db was root, and somehow in the re-configure/install process, it got changed to 'mailman' which is what it should be.
No. It uses the owner of the aliases.db file in which it found the alias and uses that user's primary group.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, 10 Jun 2011, Peter Sørensen wrote:
Actualy, it's probably several.
It's because of the very sort of permission problems you hit that I don't generally do this. Unless you really need to run Mailman 2.1.14, 2.1.13 should be plenty fine enough. One server I help administer still runs Debian Lenny with Mailman 2.1.11 and again works fine for me.
However, I did have to hand-compile Mailman on a Ubuntu system for work (I no longer have access to this box) because I needed to have multiple installs for separate domains. I made some notes. See below.
You don't need this, and in fact if I recall correctly, it's bad to have this.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman
You don't have any other virtual alias domains?
mailman_destination_recipient_limit = 1
I've never seen this one before.
You're mixing up methods here.
You can set up Mailman+Postfix in one of two ways, using virtual alias domains or using a Mailman-specific domain (e.g. lists.example.com) and using a transport. You seem to have employed both here which is not necessary, and by definition only one will ever work.
I've never used the transport option and consider it unnecessary, but it may be simpler for someone who is using a subdomain specifically for lists and no other Email.
Not sure which documentation you're using, but I recommend the official installation guide, specifically the section on Postfix. It's a little confusing but Email administration is a confusing business. http://list.org/./mailman-install/node12.html
Like I said, you run the risk of running into these problems if you try to compile Mailman from source under Debian or a Debian-based system (and probably other package-based systems). Debian is tricky because they use different usernames than stock Mailman, though of course the reason is so that you have consistant user/group names across software packages.
Here's some info if you decide you want to persist with the compile-it-yourself method.
From the notes I made, you'll need the folllowing configure line based on that used for the Debian package:
./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
You'll also want to use --prefix if you want to install somewhere special (I forget what the default is).
Prefix dir must be owner/group list. Must be group writeable and setgid.
You might want to "umask 002" before running make.
After make install:
cd $prefix bin/check_perms
then chown www-data archives/private chmod o-x archives/private
Run bin/genailiases from $prefix
Check that data/aliases and data/virtual-mailman are owned by list and are world-writeable (try check-perms again after genaliases)
It's almost two years since I made these notes for myself so I don't remember the finer points. I've set up Mailman on several other systems and just used the packaged versions.
HTH, Geoff.
Thanks Geoff
You really got me on the track and pointed out what is was mixing. Really confusing with all this information :-)
I did as you suggested:
recompiled with: ./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
and removed the transport.
Thats it - thanks.
regards
Peter
Fra: Geoff Shang [geoff@QuiteLikely.com] Sendt: 10. juni 2011 20:59 Til: Peter Sørensen Cc: mailman-users@python.org Emne: Re: [Mailman-Users] Group mismatch ( YES I KNOW THIS IS A FAQ BUT..)
On Fri, 10 Jun 2011, Peter Sørensen wrote:
Actualy, it's probably several.
It's because of the very sort of permission problems you hit that I don't generally do this. Unless you really need to run Mailman 2.1.14, 2.1.13 should be plenty fine enough. One server I help administer still runs Debian Lenny with Mailman 2.1.11 and again works fine for me.
However, I did have to hand-compile Mailman on a Ubuntu system for work (I no longer have access to this box) because I needed to have multiple installs for separate domains. I made some notes. See below.
You don't need this, and in fact if I recall correctly, it's bad to have this.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman
You don't have any other virtual alias domains?
mailman_destination_recipient_limit = 1
I've never seen this one before.
You're mixing up methods here.
You can set up Mailman+Postfix in one of two ways, using virtual alias domains or using a Mailman-specific domain (e.g. lists.example.com) and using a transport. You seem to have employed both here which is not necessary, and by definition only one will ever work.
I've never used the transport option and consider it unnecessary, but it may be simpler for someone who is using a subdomain specifically for lists and no other Email.
Not sure which documentation you're using, but I recommend the official installation guide, specifically the section on Postfix. It's a little confusing but Email administration is a confusing business. http://list.org/./mailman-install/node12.html
Like I said, you run the risk of running into these problems if you try to compile Mailman from source under Debian or a Debian-based system (and probably other package-based systems). Debian is tricky because they use different usernames than stock Mailman, though of course the reason is so that you have consistant user/group names across software packages.
Here's some info if you decide you want to persist with the compile-it-yourself method.
From the notes I made, you'll need the folllowing configure line based on that used for the Debian package:
./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
You'll also want to use --prefix if you want to install somewhere special (I forget what the default is).
Prefix dir must be owner/group list. Must be group writeable and setgid.
You might want to "umask 002" before running make.
After make install:
cd $prefix bin/check_perms
then chown www-data archives/private chmod o-x archives/private
Run bin/genailiases from $prefix
Check that data/aliases and data/virtual-mailman are owned by list and are world-writeable (try check-perms again after genaliases)
It's almost two years since I made these notes for myself so I don't remember the finer points. I've set up Mailman on several other systems and just used the packaged versions.
HTH, Geoff.
On 6/10/2011 2:28 AM, Peter Sørensen wrote:
And you have conflated your Debian/Ubuntu package configuration and the standard GNU Mailman configuration.
OK
OK
Added to postfix main.cf: transport_maps = hash:/etc/postfix/transport
See below:
alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases alias_database = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases
You don't need hash:/usr/local/mailman/data/aliases in alias_database. This only makes Postfix's newaliases command do extra work. See <http://www.list.org/mailman-install/postfix-integration.html>.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman mailman_destination_recipient_limit = 1
The above, the transport maps entries below, and the mailman transport in master.cf are for postfix-to-mailman.py delivery which is an incompatible alternative to delivery vfia aliases and virtual maps.
This looks like a delivery via aliases which should work if the ownership of data/aliases.db is as above.
OK I go to the mailman source and recompile as suggested and get
Jun 10 07:28:29 mls2 Mailman mail-wrapper: Group mismatch error. Mailman expected the mail#012wrapper script to be executed as group "nogroup", but#012the system's mail server executed the mail script as#012group "mailman". Try tweaking the mail server to run the#012script as group "nogroup", or re-run configure, #012providing the command line option
--with-mail-gid=mailman'. Jun 10 07:28:29 mls2 postfix/local[22760]: 711C8FFD9D: to=<its@mls2.sdu.dk>, orig_to=<its@test.sdu.dk>, relay=local, delay=14, delays=14/0.02/0/0.03, dsn=5.3.0, status=bounced (Command died with status 2: "/usr/local/mailman/mail/mailman post its". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "nogroup", but the system's mail server executed the mail script as group "mailman". Try tweaking the mail server to run the script as group "nogroup", or re-run configure, providing the command line option--with-mail-gid=mailman'. )
And Postfix invoking the wrapper as group 'mailman' is what should have happened above.
Now you should reconfigure with --with-mail-gid=mailman and try again. I'm guessing that for the first try above when Postfix invoked the wrapper as 'nogroup', the owner of data/aliases.db was root, and somehow in the re-configure/install process, it got changed to 'mailman' which is what it should be.
No. It uses the owner of the aliases.db file in which it found the alias and uses that user's primary group.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, 10 Jun 2011, Peter Sørensen wrote:
Actualy, it's probably several.
It's because of the very sort of permission problems you hit that I don't generally do this. Unless you really need to run Mailman 2.1.14, 2.1.13 should be plenty fine enough. One server I help administer still runs Debian Lenny with Mailman 2.1.11 and again works fine for me.
However, I did have to hand-compile Mailman on a Ubuntu system for work (I no longer have access to this box) because I needed to have multiple installs for separate domains. I made some notes. See below.
You don't need this, and in fact if I recall correctly, it's bad to have this.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman
You don't have any other virtual alias domains?
mailman_destination_recipient_limit = 1
I've never seen this one before.
You're mixing up methods here.
You can set up Mailman+Postfix in one of two ways, using virtual alias domains or using a Mailman-specific domain (e.g. lists.example.com) and using a transport. You seem to have employed both here which is not necessary, and by definition only one will ever work.
I've never used the transport option and consider it unnecessary, but it may be simpler for someone who is using a subdomain specifically for lists and no other Email.
Not sure which documentation you're using, but I recommend the official installation guide, specifically the section on Postfix. It's a little confusing but Email administration is a confusing business. http://list.org/./mailman-install/node12.html
Like I said, you run the risk of running into these problems if you try to compile Mailman from source under Debian or a Debian-based system (and probably other package-based systems). Debian is tricky because they use different usernames than stock Mailman, though of course the reason is so that you have consistant user/group names across software packages.
Here's some info if you decide you want to persist with the compile-it-yourself method.
From the notes I made, you'll need the folllowing configure line based on that used for the Debian package:
./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
You'll also want to use --prefix if you want to install somewhere special (I forget what the default is).
Prefix dir must be owner/group list. Must be group writeable and setgid.
You might want to "umask 002" before running make.
After make install:
cd $prefix bin/check_perms
then chown www-data archives/private chmod o-x archives/private
Run bin/genailiases from $prefix
Check that data/aliases and data/virtual-mailman are owned by list and are world-writeable (try check-perms again after genaliases)
It's almost two years since I made these notes for myself so I don't remember the finer points. I've set up Mailman on several other systems and just used the packaged versions.
HTH, Geoff.
Thanks Geoff
You really got me on the track and pointed out what is was mixing. Really confusing with all this information :-)
I did as you suggested:
recompiled with: ./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
and removed the transport.
Thats it - thanks.
regards
Peter
Fra: Geoff Shang [geoff@QuiteLikely.com] Sendt: 10. juni 2011 20:59 Til: Peter Sørensen Cc: mailman-users@python.org Emne: Re: [Mailman-Users] Group mismatch ( YES I KNOW THIS IS A FAQ BUT..)
On Fri, 10 Jun 2011, Peter Sørensen wrote:
Actualy, it's probably several.
It's because of the very sort of permission problems you hit that I don't generally do this. Unless you really need to run Mailman 2.1.14, 2.1.13 should be plenty fine enough. One server I help administer still runs Debian Lenny with Mailman 2.1.11 and again works fine for me.
However, I did have to hand-compile Mailman on a Ubuntu system for work (I no longer have access to this box) because I needed to have multiple installs for separate domains. I made some notes. See below.
You don't need this, and in fact if I recall correctly, it's bad to have this.
virtual_alias_maps = hash:/usr/local/mailman/data/virtual-mailman
You don't have any other virtual alias domains?
mailman_destination_recipient_limit = 1
I've never seen this one before.
You're mixing up methods here.
You can set up Mailman+Postfix in one of two ways, using virtual alias domains or using a Mailman-specific domain (e.g. lists.example.com) and using a transport. You seem to have employed both here which is not necessary, and by definition only one will ever work.
I've never used the transport option and consider it unnecessary, but it may be simpler for someone who is using a subdomain specifically for lists and no other Email.
Not sure which documentation you're using, but I recommend the official installation guide, specifically the section on Postfix. It's a little confusing but Email administration is a confusing business. http://list.org/./mailman-install/node12.html
Like I said, you run the risk of running into these problems if you try to compile Mailman from source under Debian or a Debian-based system (and probably other package-based systems). Debian is tricky because they use different usernames than stock Mailman, though of course the reason is so that you have consistant user/group names across software packages.
Here's some info if you decide you want to persist with the compile-it-yourself method.
From the notes I made, you'll need the folllowing configure line based on that used for the Debian package:
./configure --with-username=list --with-groupname=list --with-mail-gid=list --with-cgi-gid=www-data
You'll also want to use --prefix if you want to install somewhere special (I forget what the default is).
Prefix dir must be owner/group list. Must be group writeable and setgid.
You might want to "umask 002" before running make.
After make install:
cd $prefix bin/check_perms
then chown www-data archives/private chmod o-x archives/private
Run bin/genailiases from $prefix
Check that data/aliases and data/virtual-mailman are owned by list and are world-writeable (try check-perms again after genaliases)
It's almost two years since I made these notes for myself so I don't remember the finer points. I've set up Mailman on several other systems and just used the packaged versions.
HTH, Geoff.
participants (3)
-
Geoff Shang -
Mark Sapiro -
Peter Sørensen