From owner-freebsd-ports@FreeBSD.ORG Sat Apr 21 10:21:22 2007 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3D7216A401 for ; Sat, 21 Apr 2007 10:21:22 +0000 (UTC) (envelope-from david@vizion2000.net) Received: from dns1.vizion2000.net (77-99-36-42.cable.ubr04.chap.blueyonder.co.uk [77.99.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C51913C44B for ; Sat, 21 Apr 2007 10:21:22 +0000 (UTC) (envelope-from david@vizion2000.net) Received: by dns1.vizion2000.net (Postfix, from userid 1007) id 1CD211CC28; Sat, 21 Apr 2007 03:33:09 -0700 (PDT) From: David Southwell Organization: Voice and Vision To: freebsd-ports@freebsd.org Date: Sat, 21 Apr 2007 03:33:08 -0700 User-Agent: KMail/1.9.6 References: <200704200842.48793.david@vizion2000.net> <2D8F0EEC-CA1A-403E-8799-8E6D27C11475@goldmark.org> <20070421092009.GR1402@isis.u-strasbg.fr> In-Reply-To: <20070421092009.GR1402@isis.u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704210333.08947.david@vizion2000.net> Cc: Guy Brand Subject: Re: Mailman GID problem X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 10:21:22 -0000 On Saturday 21 April 2007 02:20:10 Guy Brand wrote: > Jeffrey Goldberg (jeffrey@goldmark.org) 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@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 lists! ---> 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@dns1 /usr/ports/mail/mailman]# make clean ===> Cleaning for python24-2.4.4 ===> Cleaning for mailman-2.1.9_1 [root@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/msgfmt.py -o sv/LC_MESSAGES/mailman.mo sv/LC_MESSAGES/mailman.po /usr/local/bin/python2.4 ../build/bin/msgfmt.py -o tr/LC_MESSAGES/mailman.mo tr/LC_MESSAGES/mailman.po /usr/local/bin/python2.4 ../build/bin/msgfmt.py -o uk/LC_MESSAGES/mailman.mo uk/LC_MESSAGES/mailman.po /usr/local/bin/python2.4 ../build/bin/msgfmt.py -o vi/LC_MESSAGES/mailman.mo vi/LC_MESSAGES/mailman.po /usr/local/bin/python2.4 ../build/bin/msgfmt.py -o zh_CN/LC_MESSAGES/mailman.mo zh_CN/LC_MESSAGES/mailman.po /usr/local/bin/python2.4 ../build/bin/msgfmt.py -o zh_TW/LC_MESSAGES/mailman.mo zh_TW/LC_MESSAGES/mailman.po [root@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 ===> SECURITY REPORT: This port has installed the following binaries, which execute with increased privileges. /usr/local/mailman/cgi-bin/create /usr/local/mailman/cgi-bin/subscribe /usr/local/mailman/mail/mailman /usr/local/mailman/cgi-bin/listinfo /usr/local/mailman/cgi-bin/rmlist /usr/local/mailman/cgi-bin/options /usr/local/mailman/cgi-bin/private /usr/local/mailman/cgi-bin/admindb /usr/local/mailman/cgi-bin/edithtml /usr/local/mailman/cgi-bin/roster /usr/local/mailman/cgi-bin/admin /usr/local/mailman/cgi-bin/confirm 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: http://www.list.org/ [root@dns1 /usr/ports/mail/mailman]# /usr/local/mailman/bin/mailmanctl -q stop [root@dns1 /usr/ports/mail/mailman]# /usr/local/mailman/bin/mailmanctl -q start [root@dns1 /usr/ports/mail/mailman]# postfix reload postfix/postfix-script: refreshing the Postfix mail system [root@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 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@dns1 /usr/local/mailman/data]# ls -l total 64 -rw-r----- 1 nobody mailman 41 Apr 16 07:51 adm.pw -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 creator.pw -rw-r--r-- 1 root mailman 10 Apr 21 02:57 last_mailman_version -rw-rw---- 1 nobody mailman 6 Apr 21 02:59 master-qrunner.pid -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. David