mouss put forth on 10/31/2009 11:06 AM:

mouss, you rock.

> you can use a script if you prefer. the advantage of 'make' is that it
> only re-generates files when needed (source change).

The only likely changes would be adding another country.  In this case,
would I just add the file name to the "source" section below, and run
the make script?

> for your country maps and assuming gnu make, your Makefile would contain
> something like this:
> 
> #---------------
> 
> #directpry where we store our cidr maps
> CIDR_DIR=/etc/postfix/cidr_files
> 
> #file to generate
> COUNTRIES_DEST=${CIDR_DIR}/countries
> 
> #"source" files, withput directory nor suffix.
> COUNTRIES += china
> COUNTRIES += korea
> COUNTRIES += russia
> ...
> 
> #non portable commands. gnu make assumed.
> CIDR_COUNTRIES=$(addsuffix .cidr, ${COUNTRIES})
> COUNTRY_MAPS=$(addprefix ${CIDR_DIR}/, ${CIDR_COUNTRIES})
> 
> ${COUNTRIES_DEST}: ${COUNTRY_MAPS}
>       cat $^  > $@
> 
> ...
> #-------------
> 
> this will catenate all your china.cidr, korea.cidr, ... into "countries"
> which you can then use with
>       check_client_access cidr:/etc/postfix/cidr_files/countries

Neat.  I'm using gnu make so this should all work.  Still don't
understand how this would affect memory footprint, but at least it would
clean up my main.cf a bit.

> PS. since you use a cidr specific directory, you can get rid of the
> ".cidr" suffix. you could then use (in main.cf):
> 
> cidr=cidr:/etc/postfix/cidr_files
> smtpd_foo_restrictions =
>       ...
>       check_client_access ${cidr}/access_foo
>       ...
>       check_client_access ${cidr}/access_bar

Ahh, also sweet.  I'd seen folks using variables but I hadn't really
found a need yet to dig into it.  That and I was afraid of confusing
myself down the road. ;)  Just implemented this.  Works fine, main.cf
much cleaner looking, _and_ I'm now practicing "good form" with
"check_client_access" in front of each CIDR map. ;)

Lots of good ancillary info coming out of this thread.  Thanks guys.
Still wondering about the map file memory overhead details...

--
Stan

Reply via email to