Mailman GID problem

David Southwell david at
Sat Apr 21 10:21:22 UTC 2007

On Saturday 21 April 2007 02:20:10 Guy Brand wrote:
> Jeffrey Goldberg (jeffrey at on 20/04/2007 at 23:59 wrote:
> >  From /usr/local/share/doc/mailman/mailman-install.txt
> >
> >   In section  6.1.1 Integrating Postfix and Mailman
> >
> >
> >     * When you configure Mailman, use the --with-mail-gid=mailman
> >       switch;
> >
> >  However, the current ports Makefile compiles mailman
> > --with-mail-gid=nobody
> [...]
> >  I am coming to that conclusion.  I now think that my second suggestion
> > of changing the ports Makefile to set MAIL_GID to mailman instead of
> > nobody when configuring for postfix is the correct direction to go.
>   cd /usr/ports/mail/mailman
>   MAIL_GID=mailman make install clean
>   works since the commit to mailman's port Makefile in Sep 2006 which
>   turned MAIL_GID to nobody (for use with postfix). The change you
>   suggest has the same effect, so I'd go for it.
>   BTW, does anyone know why MAIL_GID was changed from mailman to
>   nobody?

Well thanks everyone here is what eventually worked!!
[root at dns1 /usr/ports/mail/mailman]# make deinstall
===>  Deinstalling for mail/mailman
===>   Deinstalling mailman-2.1.9_1
---> Starting deinstall script:
---> Zeroing crontab for "mailman"
---> Stopping Mailman's qrunner daemon
---> Preserving the "last_mailman_version" file
---> Starting post-deinstall script:
---> /usr/local/mailman is not empty - this installation may have active 
---> Restoring "last_mailman_version" file
---> - If you are not using Mailman any more, you should manually delete
---> - the "mailman" user and "mailman" group.
---> - You may delete them with "pw groupdel mailman; pw userdel mailman".
[root at dns1 /usr/ports/mail/mailman]# make clean
===>  Cleaning for python24-2.4.4
===>  Cleaning for mailman-2.1.9_1
[root at dns1 /usr/ports/mail/mailman]# MAIL_GID=mailman make
===>  Found saved configuration for mailman-2.1.9_1
/usr/local/bin/python2.4 ../build/bin/ -o sv/LC_MESSAGES/ 
/usr/local/bin/python2.4 ../build/bin/ -o tr/LC_MESSAGES/ 
/usr/local/bin/python2.4 ../build/bin/ -o uk/LC_MESSAGES/ 
/usr/local/bin/python2.4 ../build/bin/ -o vi/LC_MESSAGES/ 
/usr/local/bin/python2.4 ../build/bin/ -o 
/usr/local/bin/python2.4 ../build/bin/ -o 
[root at dns1 /usr/ports/mail/mailman]# MAIL_GID=mailman make install
===>  Installing for mailman-2.1.9_1
===>   mailman-2.1.9_1 depends on file: /usr/local/bin/python2.4 - found
---> Starting install script:
---> Using existing group "mailman"
---> Using existing user "mailman"
---> 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
===>  Checking if mail/mailman already installed
Creating architecture independent directories...
===> Installing rc.d startup script(s)
===>   Registering installation for mailman-2.1.9_1
      This port has installed the following binaries, which execute with
      increased privileges.

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage:
[root at dns1 /usr/ports/mail/mailman]# /usr/local/mailman/bin/mailmanctl -q stop
[root at dns1 /usr/ports/mail/mailman]# /usr/local/mailman/bin/mailmanctl -q 
[root at dns1 /usr/ports/mail/mailman]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
[root at dns1 /usr/ports/mail/mailman]#  

mailman now seems to be working.. but I need to do some ehaustive checks 
before I can feel confident.

None of the other combinations suggested worked including:

# MAIL_GID=mailman make install clean 
left mw with the same GID problem reported in maillog
It whereas:
# Make clean
# MAIL_GID=mailman make
# MAIL_GID=mailman make install
worked satisfactorily

# make -DWITH-MAIL-GID=mailman 
also left the same GID problem.

I cannot tell you what caused these anomalies only  the results!!

It looks to me as though the existing port needs careful reaxmination by 
someone who understands these things <chuckles wryly- and that, 
unfortunately, does not include me :-( >

What is weird is that it does not seem to be due to any changes 
in /usr/local/mailman/data.
The owner:group combination remained UNCHANGED,., so I do not believbe the 
problem is entirely due to file ownership in that directory.
At no time did any of the different compilations/installs change owner:group 
from the following:
[root at dns1 /usr/local/mailman/data]# ls -l
total 64
-rw-r-----  1 nobody   mailman     41 Apr 16 07:51
-rw-rw----  1 nobody   mailman   4364 Apr 20 06:39 aliases
-rw-rw----  1 mailman  mailman  16384 Apr 20 06:39 aliases.db
-rw-r-----  1 nobody   mailman     41 Apr 16 07:52
-rw-r--r--  1 root     mailman     10 Apr 21 02:57 last_mailman_version
-rw-rw----  1 nobody   mailman      6 Apr 21 02:59
-rw-r--r--  1 root     mailman  14114 Apr 21 02:57 sitelist.cfg
-rw-rw-r--  1 nobody   mailman      0 Apr 17 09:52 virtual-aliases
-rw-rw----  1 nobody   mailman   2275 Apr 20 06:39 virtual-mailman
-rw-rw-r--  1 mailman  mailman  16384 Apr 20 06:39 virtual-mailman.db
I do not know wjhether any of this will help solve the problem.

I would mention that bin/check_perms -f would upset the current owner:group 
combination -- and as the docs firmly instruct  running check_perms post 
install it seems that bin/check_perms needs to be in step with a working 
install from ports. 

Finally would it be possible when the mailman port is revised for the revision 
to include a routine that checks file ownerships/permissions and brings all 
files up to standard.

Lastly the standard make ./configure does not work with mailman neither is 
there a record available which enables one to check the current settings 
including GID applicable to the installed version. This means that when an 
attempt is made to apply an option and the make does not do so there is no 
way one can tell!!

My two peenorth PLS

A sincere thank you to everyone who has chipped in on this one.


More information about the freebsd-ports mailing list