The Dreaded Group Mismatch Error
I tried to send a message to a low-traffic announce-list which failed:
Mailman mail-wrapper: 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 "nobody". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option `--with-mail-gid=nobody'.
So I go to the /usr/ports/mail/mailman/ directory to build mailman 'by hand' so to speak:
$ export MM_USERNAME=nobody $ export MM_GROUPNAME=nobody $ export MM_USERID=65534 $ make install ===> Installing for mailman-2.1.12 ===> mailman-2.1.12 depends on file: /usr/local/bin/python2.5 - found ---> Starting install script: ---> Using existing group "nobody" ---> Using existing user "nobody" ---> Using existing Mailman directory (/usr/local/mailman) (There may be existing active mailing lists - this installation will attempt to preserve them.) ===> Generating temporary packing list
etc etc
$ /usr/local/etc/rc.d/mailman start $
Try to send another message, and I get the exact same error.
Apr 24 09:26:44 mail Mailman mail-wrapper: 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 "nobody". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option `--with-mail-gid=nobody'.
Now /etc/postfix/aliases.db (where all the aliases for mailman have been since at least 2004) is owned by root, and man 8 local says:
When those files are
owned by the superuser, delivery is made with the rights specified with
the default_privs configuration parameter.
and the default for default_privs is nobody, which is what postfix is doing.
So, if mailman is built as above using group and user nobody why is it claiming it expected the wrapper to be run as mailman?
As far as I can tell, postfix is doing what it is supposed to, but mailman somewhere has a user mailman in it that it thinks should be being used. Where this is and why I cannot figure out.
All the mailman processes are running as 'nobody'
So, I went and grabbed the source and read up on http://www.gnu.org/software/mailman/mailman-install/node7.html
~/src/mailman-2.1.13 $ ./configure --with-username=nobody --with-mail-gid=nobody --with-group-name=nobody configure: WARNING: you should use --build, --host, --target checking for --with-python... no checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking Python version... 2.5.5 checking Python's email package... ok checking Japanese codecs... ok checking Korean codecs... ok checking that Python has a working distutils... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking for true... /usr/bin/true checking for --without-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether #! works in shell scripts... yes checking for --with-var-prefix... no checking for --with-permcheck... yes checking for --with-username... mailman checking for user name "mailman"... okay checking for --with-groupname... mailman checking for group name "mailman"... okay ...
it completely ignores the flags (this is 2.1.13 downloaded a today from ftp://ftp.gnu.org/gnu/mailman/mailman-2.1.13.tgz ).
and even if you try to make at that point, there is no Makefile
so, now what? What portion of mailman is expecting a gid of mailman? Since mailman seems to be totally insistent on running as mailman, I wen ahead and split the aliases out into a separate file and gave them the right permissions
$ chown mailman /usr/local/mailman/data/aliases.db
In the manual it say:
Run the bin/genaliases script to initialize your aliases file. % cd /usr/local/mailman % bin/genaliases
Make sure that the owner of the data/aliases and data/aliases.db file is mailman, that the group owner for those files is mailman, or whatever user and group you used in the configure command, and that both files are group writable:
However, when I run bin/genaliases I get:
To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program:
followed by a list of all the aliases.
There are no files in data/ named anything like alias
/usr/local/mailman $ ls -ls data/ total 20 2 -rw-r----- 1 root nobody 41 May 30 2009 adm.pw 2 -rw-r--r-- 1 root nobody 10 Apr 24 10:30 last_mailman_version 2 -rw-rw---- 1 nobody nobody 6 Apr 24 10:36 master-qrunner.pid 14 -rw-r--r-- 1 root nobody 14100 Apr 24 10:32 sitelist.cfg
But I created one, ran postalias on it, changed the permissions as noted above, and it STILL fails with the same error.
LuKreme wrote:
I tried to send a message to a low-traffic announce-list which failed:
Are other lists working?
Mailman mail-wrapper: 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 "nobody". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option `--with-mail-gid=nobody'.
So I go to the /usr/ports/mail/mailman/ directory to build mailman 'by hand' so to speak:
$ export MM_USERNAME=nobody $ export MM_GROUPNAME=nobody $ export MM_USERID=65534 $ make install ===> Installing for mailman-2.1.12 ===> mailman-2.1.12 depends on file: /usr/local/bin/python2.5 - found ---> Starting install script: ---> Using existing group "nobody" ---> Using existing user "nobody" ---> Using existing Mailman directory (/usr/local/mailman) (There may be existing active mailing lists - this installation will attempt to preserve them.) ===> Generating temporary packing list
etc etc
Which may or may not have any effect on this depending on how your package installation works.
$ /usr/local/etc/rc.d/mailman start $
Try to send another message, and I get the exact same error.
Apr 24 09:26:44 mail Mailman mail-wrapper: 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 "nobody". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option `--with-mail-gid=nobody'.
Now /etc/postfix/aliases.db (where all the aliases for mailman have been since at least 2004) is owned by root, and man 8 local says:
When those files are owned by the superuser, delivery is made with the rights specified with the default_privs configuration parameter.and the default for default_privs is nobody, which is what postfix is doing.
So, if mailman is built as above using group and user nobody why is it claiming it expected the wrapper to be run as mailman?
Ask your packager.
As far as I can tell, postfix is doing what it is supposed to, but mailman somewhere has a user mailman in it that it thinks should be being used. Where this is and why I cannot figure out.
All the mailman processes are running as 'nobody'
Which pretty much defeats Mailman's security model.
So, I went and grabbed the source and read up on http://www.gnu.org/software/mailman/mailman-install/node7.html
~/src/mailman-2.1.13 $ ./configure --with-username=nobody --with-mail-gid=nobody --with-group-name=nobody configure: WARNING: you should use --build, --host, --target
This is very strange. When I run the above command in a freshly unpacked 2.1.13 tarball directory (with 2.5 python), I get:
[msapiro@msapiro ...2.1.13/mailman-2.1.13]$ ./configure --with-username=nobody --with-mail-gid=nobody --with-group-name=nobody configure: WARNING: unrecognized options: --with-group-name
Because it's spelled --with-groupname
checking for --with-python... no ...
checking for --with-python... no checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking Python version... 2.5.5 checking Python's email package... ok checking Japanese codecs... ok checking Korean codecs... ok checking that Python has a working distutils... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking for true... /usr/bin/true checking for --without-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether #! works in shell scripts... yes checking for --with-var-prefix... no checking for --with-permcheck... yes checking for --with-username... mailman checking for user name "mailman"... okay checking for --with-groupname... mailman checking for group name "mailman"... okay ...
it completely ignores the flags (this is 2.1.13 downloaded a today from ftp://ftp.gnu.org/gnu/mailman/mailman-2.1.13.tgz ).
Well, it ignores --with-group-name because it's misspelled, but it should issue a warning about that.
Could there be something in your environment that's affecting this? Or your shell? What shell is invoked by /bin/sh?
and even if you try to make at that point, there is no Makefile
Are you saying configure completes and makes a config.status and runs that and there is no Makefile after that? Really strange...
so, now what? What portion of mailman is expecting a gid of mailman? Since mailman seems to be totally insistent on running as mailman, I wen ahead and split the aliases out into a separate file and gave them the right permissions
$ chown mailman /usr/local/mailman/data/aliases.db
In the manual it say:
Run the bin/genaliases script to initialize your aliases file. % cd /usr/local/mailman % bin/genaliases
Make sure that the owner of the data/aliases and data/aliases.db file is mailman, that the group owner for those files is mailman, or whatever user and group you used in the configure command, and that both files are group writable:
However, when I run bin/genaliases I get:
To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program:
followed by a list of all the aliases.
Because you don't have
MTA= 'Postfix'
in mm_cfg.py.
There are no files in data/ named anything like alias
/usr/local/mailman $ ls -ls data/ total 20 2 -rw-r----- 1 root nobody 41 May 30 2009 adm.pw 2 -rw-r--r-- 1 root nobody 10 Apr 24 10:30 last_mailman_version 2 -rw-rw---- 1 nobody nobody 6 Apr 24 10:36 master-qrunner.pid 14 -rw-r--r-- 1 root nobody 14100 Apr 24 10:32 sitelist.cfg
But I created one, ran postalias on it, changed the permissions as noted above, and it STILL fails with the same error.
Maybe because you still have aliases in /etc/postfix/aliases.db which is what is being used by postfix unless you added hash:/usr/local/mailman/data/aliases to Postfix alias_maps ahead of hash:/etc/postfix/aliases.
Note that the expected group (mailman) is compiled into the mailman/mail/mailman wrapper (from configure's --with-mail-gid) in standard Mailman. I don't know how to set it in your package.
On 24-Apr-2010, at 13:15, Mark Sapiro wrote:
LuKreme wrote:
I tried to send a message to a low-traffic announce-list which failed:
Are other lists working?
No, everything is dead.
[Let's just ignore anything having to do with the ports package, I'm trying to get the source tarball to work]
So, I went and grabbed the source and read up on http://www.gnu.org/software/mailman/mailman-install/node7.html
~/src/mailman-2.1.13 $ ./configure --with-username=nobody --with-mail-gid=nobody --with-group-name=nobody configure: WARNING: you should use --build, --host, --target
This is very strange. When I run the above command in a freshly unpacked 2.1.13 tarball directory (with 2.5 python), I get:
[msapiro@msapiro ...2.1.13/mailman-2.1.13]$ ./configure --with-username=nobody --with-mail-gid=nobody --with-group-name=nobody configure: WARNING: unrecognized options: --with-group-name
Because it's spelled --with-groupname
Yeah, I don't get that.
# python --version Python 2.5.5 # bash --version GNU bash, version 4.0.35(0)-release (i386-portbld-freebsd6.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. #
checking for --with-python... no
No idea, python is certainly installed.
Could there be something in your environment that's affecting this? Or your shell? What shell is invoked by /bin/sh?
running straight bash, nothing set in my environment. In fact, I tried to compile it just now with su root (no .profile or .bashrc active at all).
and even if you try to make at that point, there is no Makefile
Are you saying configure completes and makes a config.status and runs that and there is no Makefile after that? Really strange…
Yes, exactly.
I've downloaded the tarball twice now.
Note that the expected group (mailman) is compiled into the mailman/mail/mailman wrapper (from configure's --with-mail-gid) in standard Mailman. I don't know how to set it in your package.
I keep trying to get it to work properly with the mailman user and group but it is not playing nice. I would prefer, of course, to have this all working properly (with uid and gid of mailman) but working -at all- would be better.
I'm going to try and recompile the port with mailman/mailman and split the aliases out into the data/aliases file, set those perms, re-postalias all the files, wave a fresh chicken bone over the server, and hope for the best.
LuKreme wrote:
configure: WARNING: unrecognized options: --with-group-name
Because it's spelled --with-groupnameYeah, I don't get that.
And you do get another warning that I don't get. ???
# python --version Python 2.5.5 # bash --version GNU bash, version 4.0.35(0)-release (i386-portbld-freebsd6.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. #
checking for --with-python... no
No idea, python is certainly installed.
That only means you didn't specify --with-python. The next lines
checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking Python version... 2.5.5
say it found your python OK.
Could there be something in your environment that's affecting this? Or your shell? What shell is invoked by /bin/sh?
running straight bash, nothing set in my environment. In fact, I tried to compile it just now with su root (no .profile or .bashrc active at all).
and even if you try to make at that point, there is no Makefile
Are you saying configure completes and makes a config.status and runs that and there is no Makefile after that? Really strange=85
Yes, exactly.
Very strange.
I've downloaded the tarball twice now.
You could try running autoconf to generate a new configure from configure.in. There might be some idiosyncrasy between the packaged configure and what, I don't know.
Note that the expected group (mailman) is compiled into the mailman/mail/mailman wrapper (from configure's --with-mail-gid) in standard Mailman. I don't know how to set it in your package.
I keep trying to get it to work properly with the mailman user and group but it is not playing nice. I would prefer, of course, to have this all working properly (with uid and gid of mailman) but working -at all- would be better.
If the aliases are found in an aliases.db file whose owner (not group) is 'mailman', Postfix will invoke the wrapper as the mailman user:group.
I am truly puzzled as to why the configure in the tarball apparently isn't working correctly.
Also, You said you first saw this when you attempted to post to a low-traffic announce-list. Were other lists working at that time?
I'm going to try and recompile the port with mailman/mailman and split the aliases out into the data/aliases file, set those perms, re-postalias all the files, wave a fresh chicken bone over the server, and hope for the best.
OK
LuKreme....
<< wave a fresh chicken bone over the server >>
You WILL have FAR better 'luck' with a fresh [sic] turkey bone !!
I thought "everybody" knew THAT !!! Tsk, tsk !!!
Ed
PS: <VBEG> !!
On Apr 24, 2010, at 14:27, LuKreme kremels@kreme.com wrote:
wave a fresh chicken bone over the server
All hail the power of the chicken bone.
(it's working again, Woot)
On Sat, 2010-04-24 at 11:20 -0600, LuKreme wrote:
$ export MM_USERNAME=nobody $ export MM_GROUPNAME=nobody $ export MM_USERID=65534 $ make install
If you're truly building "by hand" you're missing an essential step here, maybe two.
Assuming you're cd'd to your build directory,
make clean ./configure ... --with-mail-gid=nobody ... etc. make; make install
I'm not entirely sure of the difference between the --with-groupname and --with-group-gid, both of which accept a name but have different functions. I do know that for my server distribution (gentoo Linux) it's essential that the environment setting which controls the --with-mail-gid configuration setting match the mail group which the MTA runs as.
I've run into this problem often when I've upgraded Mailman and if I forget to make this adjustment I get exactly the same error, and the fix is the same every time. In my case my MTA runs as group "mail" and Mailman has to be configured thusly.
On Mon, 2010-04-26 at 11:47 -0500, Lindsay Haisley wrote:
I do know that for my server distribution (gentoo Linux) it's essential that the environment setting which controls the --with-mail-gid configuration setting match the mail group which the MTA runs as.
I should maybe point out that gentoo Linux is a source-based distribution so that nearly every package installation is built from source before it's installed. Various build parameters can be controlled by setting environment variables at build time in gentoo, but in the absence of a complete configure/make/make install build cycle (as in installing a pre-compiled package), setting environment variables is generally only effective at run-time.
On 4/26/2010 9:47 AM, Lindsay Haisley wrote:
I'm not entirely sure of the difference between the --with-groupname and --with-group-gid, both of which accept a name but have different functions. I do know that for my server distribution (gentoo Linux) it's essential that the environment setting which controls the --with-mail-gid configuration setting match the mail group which the MTA runs as.
--with-groupname set's Mailman's group. This is the group of the files and directories in Mailman's file tree, and is the group that is able to run mailman's bin commands successfully and access Mailman's Python api. It is the group the qrunners run as.
Because you don't want to give the web server user/group and the MTA user/group the ability to access this stuff directly for security reasons, the web server and MTA access Mailman through compiled SETGID wrappers that set the effective GID to Mailman's group (as set by --with-groupname). As an additional security check, these wrappers are compiled to expect to be invoked by a particular group and will issue the group mismatch error if invoked by some other group. The expected MTA group is set by --with-mail-gid and the expected web server group by --with-cgi-gid.
See the FAQ at http://wiki.list.org/x/tYA9 for more. The FAQ refers to Mailman's group as 'mailman' which is the default, but can be changed by the --with-groupname option to configure.
participants (4)
-
Lindsay Haisley -
LuKreme -
Mark Sapiro -
Shop＠" Just Brits "