From src-etc-mail-makefile-nov07@oldach.net  Sun Nov 11 19:35:54 2007
Return-Path: <src-etc-mail-makefile-nov07@oldach.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 9003E16A46C;
	Sun, 11 Nov 2007 19:35:54 +0000 (UTC)
	(envelope-from src-etc-mail-makefile-nov07@oldach.net)
Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250])
	by mx1.freebsd.org (Postfix) with ESMTP id 0692B13C4B7;
	Sun, 11 Nov 2007 19:35:53 +0000 (UTC)
	(envelope-from src-etc-mail-makefile-nov07@oldach.net)
Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210])
	by rigel.oldach.net (8.14.1/8.14.1/hmo30jul04) with ESMTP id lABJ0ffW079414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 11 Nov 2007 20:00:43 +0100 (CET)
	(envelope-from src-etc-mail-makefile-nov07@oldach.net)
Received: from sep.oldach.net (localhost [127.0.0.1])
	by sep.oldach.net (8.14.1/8.14.1/hmo26jun05) with ESMTP id lABJ0ePg017139
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 11 Nov 2007 20:00:40 +0100 (CET)
	(envelope-from src-etc-mail-makefile-nov07@oldach.net)
Received: (from hmo@localhost)
	by sep.oldach.net (8.14.1/8.14.1/Submit/hmo26jun05) id lABJ0dNI017138;
	Sun, 11 Nov 2007 20:00:39 +0100 (CET)
	(envelope-from hmo)
Message-Id: <200711111900.lABJ0dNI017138@sep.oldach.net>
Date: Sun, 11 Nov 2007 20:00:39 +0100 (CET)
From: Helge Oldach <src-etc-mail-makefile-nov07@oldach.net>
Reply-To: Helge Oldach <src-etc-mail-makefile-nov07@oldach.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Gregory Shapiro <gshapiro@freebsd.org>
Subject: [patch] map improvement for etc/mail/Makefile
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         117984
>Category:       conf
>Synopsis:       [patch] [request] map improvement for etc/mail/Makefile
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gshapiro
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov 11 19:40:01 UTC 2007
>Closed-Date:    Wed Oct 31 19:24:37 UTC 2012
>Last-Modified:  Wed Oct 31 19:24:37 UTC 2012
>Originator:     Helge Oldach
>Release:        FreeBSD 6.3-1032 i386
>Organization:
>Environment:

System: FreeBSD localhost 6.3-1032 FreeBSD 6.3-1032 #0: Sat Nov 10 11:14:15 CET 2007 toor@localhost:/usr/obj/usr/src/sys/HMO i386

>Description:

Below is a suggested improvement for /etc/mail/Makefile. It implements
multiple input files for various maps, e.g. virtusertable, permitting
easier maintenance of map input files. The idea is that the map input
file (e.g. /etc/mail/virtusertable) may not only be a flat file (as it
is currently the case) but may also be a directory which contains a set
of files that comprise the map sources.

For example consider that the three files

/etc/mail/virtusertable/thisone.com
/etc/mail/virtusertable/another.com
/etc/mail/virtusertable/third.com

contain virtusertables specific to the domains thisone.com, another.com,
and third.com. They now can be independently maintained, alleviating the
need to maintain a single, potentially large map source file.

The rather trivial patch below implements this, and also maintains
backward behaviour. (Note that /dev/null for the cat(1) command is
necessary; it catches the case of an empty directory.)

>How-To-Repeat:

>Fix:

--- etc/mail/Makefile.ctm	2005-07-14 20:42:19.000000000 +0200
+++ etc/mail/Makefile	2007-11-11 19:16:20.000000000 +0100
@@ -144,8 +144,9 @@
 	sed -e 's/^/#/' < ${.OODATE} > ${.TARGET}
 .endif
 
-${_f}.db: ${_f}
-	${MAKEMAP} ${SENDMAIL_MAP_TYPE} ${.TARGET} < ${.OODATE}
+_src!=		test -d ${_f} && find ${_f} -type f -print || echo ${_f}
+${_f}.db: ${_src}
+	cat ${.ALLSRC} /dev/null | ${MAKEMAP} ${SENDMAIL_MAP_TYPE} ${.TARGET}
 	chmod ${SENDMAIL_MAP_PERMS} ${.TARGET}
 .endfor
 
>Release-Note:
>Audit-Trail:

From: Remko Lodder <remko@FreeBSD.org>
To: Helge Oldach <src-etc-mail-makefile-nov07@oldach.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org, 
 Gregory Shapiro <gshapiro@FreeBSD.org>
Subject: Re: conf/117984: [patch] map improvement for etc/mail/Makefile
Date: Sun, 11 Nov 2007 20:45:59 +0100

 Helge Oldach wrote:
 > Below is a suggested improvement for /etc/mail/Makefile. It implements
 > multiple input files for various maps, e.g. virtusertable, permitting
 > easier maintenance of map input files. The idea is that the map input
 > file (e.g. /etc/mail/virtusertable) may not only be a flat file (as it
 > is currently the case) but may also be a directory which contains a set
 > of files that comprise the map sources.
 > 
 > For example consider that the three files
 > 
 > /etc/mail/virtusertable/thisone.com
 > /etc/mail/virtusertable/another.com
 > /etc/mail/virtusertable/third.com
 > 
 > contain virtusertables specific to the domains thisone.com, another.com,
 > and third.com. They now can be independently maintained, alleviating the
 > need to maintain a single, potentially large map source file.
 > 
 > The rather trivial patch below implements this, and also maintains
 > backward behaviour. (Note that /dev/null for the cat(1) command is
 > necessary; it catches the case of an empty directory.)
 
 I think this describes edge cases which are not suitable for the default
 installation, but that is just my opinion. If people want to go outside
 of that scope, they can surely do that, on their on free-will and they
 might be able to use the patch you submitted with the ticket, but I
 honestly think this should not be part of the base install.
 
 Thanks for using FreeBSD though and your willingness to consider this! I
 for one really appreciate this! Lets see what others think about this :)
 (because this is my opinion and others might think differently).
 
 Cheers
 remko
 
 -- 
 Kind regards,
 
      Remko Lodder               ** remko@elvandar.org
      FreeBSD                    ** remko@FreeBSD.org
 
      /* Quis custodiet ipsos custodes */
State-Changed-From-To: open->feedback 
State-Changed-By: gshapiro 
State-Changed-When: Sun Nov 11 20:52:10 UTC 2007 
State-Changed-Why:  
Take ownership, feedback provided to submitter. 


Responsible-Changed-From-To: freebsd-bugs->gshapiro 
Responsible-Changed-By: gshapiro 
Responsible-Changed-When: Sun Nov 11 20:52:10 UTC 2007 
Responsible-Changed-Why:  
Take ownership, feedback provided to submitter. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117984 

From: Gregory Shapiro <gshapiro@gshapiro.net>
To: Helge Oldach <src-etc-mail-makefile-nov07@oldach.net>,
        FreeBSD-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: conf/117984: [patch] map improvement for etc/mail/Makefile
Date: Sun, 11 Nov 2007 12:51:45 -0800

 > > Below is a suggested improvement for /etc/mail/Makefile. It implements
 > > multiple input files for various maps, e.g. virtusertable, permitting
 > > easier maintenance of map input files. The idea is that the map input
 > > file (e.g. /etc/mail/virtusertable) may not only be a flat file (as it
 > > is currently the case) but may also be a directory which contains a set
 > > of files that comprise the map sources.
 
 I tend to agree with Remko.  Luckily, their is already infrastructure in
 place to do this on your machine.  Simple create a Makefile.local with
 something like:
 
 virtusertable: a b c
 	cat ${.ALLSRC} > ${.TARGET}
 
 From then on, if a, b, or c changes, running make in /etc/mail/ will do
 the right thing.  You can also use your directory method to accomplish
 the same thing.
 
 > > contain virtusertables specific to the domains thisone.com, another.com,
 > > and third.com. They now can be independently maintained, alleviating the
 > > need to maintain a single, potentially large map source file.
 
 Note that with your model, you can't allow other people to
 manage the files as the owner of third.com can easily add
 a another.com line to his/her file.  Instead, if you want
 delegated virtusertable domain administration, take a look at
 /usr/src/contrib/sendmail/contrib/buildvirtuser.

From: src-etc-mail-makefile-nov07@oldach.net (Helge Oldach)
To: gshapiro@gshapiro.net (Gregory Shapiro)
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: conf/117984: [patch] map improvement for etc/mail/Makefile
Date: Mon, 12 Nov 2007 07:06:21 +0100 (CET)

 Hi,
 
 Gregory Shapiro:
 > Luckily, their is already infrastructure in
 > place to do this on your machine.  Simple create a Makefile.local with
 > something like:
 > 
 > virtusertable: a b c
 > 	cat ${.ALLSRC} > ${.TARGET}
 
 This will collide with the already existing rule to create a
 non-existant virtusertable from virtusertable.sample. I.e. we will get
 it wrong the first time, and need to touch a, b, or c, and re-make.
 POLA violation...
 
 OTOH, if one creates Makefile.local, he should be clever enough to
 understand the implications...
 
 > if you want
 > delegated virtusertable domain administration, take a look at
 > /usr/src/contrib/sendmail/contrib/buildvirtuser.
 
 Thanks for the hint. Actually I have thought of something like that.
 However in a few cases I need more than one file per domain (e.g.
 one static and one regularly changing list of virtuser rules).
 Probably I may extend this script to properly deal with filenames like
 tmp@domain.com to help with that case. Or extend Makefile.local to deal
 with it in a similar fashion...
 
 However please note that my proposed patch is not so much an "edge case"
 (as Remko called it) but a rather simple generalization. After all,
 there is a reason why you wrote buildvirtuser. :-) It is also fully
 backward-compatible with the current behaviour. Further, it applies to
 a (user-extendable) list of maps - I also have an application of it for
 the mailertable map which your buildvirtuser won't handle.
 
 I'll leave it to you do decide whether to apply the patch or not.
 
 Helge
State-Changed-From-To: feedback->closed 
State-Changed-By: gshapiro 
State-Changed-When: Sun Feb 17 05:04:40 UTC 2008 
State-Changed-Why:  
Thanks for the suggestion, but I'd prefer not to add this to the default 
setup at this point. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=117984 
State-Changed-From-To: closed->analyzed 
State-Changed-By: crees 
State-Changed-When: Wed Oct 31 18:42:14 UTC 2012 
State-Changed-Why:  
I think we could kill two birds with one stone here, and minimise the 
code duplication; use the pf_check function in pf_reload, and add your 
patch to pf_check http://www.bayofrum.net/~crees/patches/119874.diff 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117984 
State-Changed-From-To: analyzed->closed 
State-Changed-By: crees 
State-Changed-When: Wed Oct 31 19:24:36 UTC 2012 
State-Changed-Why:  
Close PR incorrectly set to analyzed. Sorry. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117984 
>Unformatted:

My mail didn't make it into the ticket so here it is:

From: Gregory Shapiro <gshapiro@gshapiro.net>
To: Helge Oldach <src-etc-mail-makefile-nov07@oldach.net>,
        FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: conf/117984: [patch] map improvement for etc/mail/Makefile
Date: Sun, 11 Nov 2007 12:51:45 -0800     

> > Below is a suggested improvement for /etc/mail/Makefile. It implements
> > multiple input files for various maps, e.g. virtusertable, permitting
> > easier maintenance of map input files. The idea is that the map input       
> > file (e.g. /etc/mail/virtusertable) may not only be a flat file (as it
> > is currently the case) but may also be a directory which contains a set
> > of files that comprise the map sources.   

I tend to agree with Remko.  Luckily, their is already infrastructure in
place to do this on your machine.  Simple create a Makefile.local with     
something like:

virtusertable: a b c
        cat ${.ALLSRC} > ${.TARGET}

From then on, if a, b, or c changes, running make in /etc/mail/ will do 
the right thing.  You can also use your directory method to accomplish
the same thing.

> > contain virtusertables specific to the domains thisone.com, another.com,
> > and third.com. They now can be independently maintained, alleviating the
> > need to maintain a single, potentially large map source file.

Note that with your model, you can't allow other people to
manage the files as the owner of third.com can easily add
a another.com line to his/her file.  Instead, if you want
delegated virtusertable domain administration, take a look at
/usr/src/contrib/sendmail/contrib/buildvirtuser.      
