On Sat, Dec 01, 2007 at 12:07:54AM +0100, Bengt Frost wrote:
> > >
> > > Someone out there have any suggestions how use Postfix (and Dovecot)
> > > with PostgreSQL?
> >
> > Pull the user data from PostgreSQL and generate the files:
> > /etc/sasldb2.db (copy to /var/spool/postfix/etc && postfix reload)
> > /etc/cram-md5.pwd
> >
> > e.g: have a cron driven perl script check for changes to the user tables
> > in the last 15 mins & if so, then generate new files. Stops PostgreSQL
> > becoming a bottleneck when under high load (a spam attack).
> >
> Ok. Not quite sure I'm following you. You mean pull user data from
> PostgreSQL
> and generate flat(db) user file for smtp-auth using
> p5-Authen-SASL-2.10p0 ...
Aye, using whatever you fancy, probably loads of modules on CPAN that
will do most of what you want for your site. Perl is in base, so you
wont run the risk of a broken port of ruby/python/whatever stopping you
working after an upgrade.
Same for /etc/postfix/{aliases,canonical.map,virtual.map}
>
> > As your site grows, you can punt the flat files out across your mail
> > farm from your central db/admin box, use rdist or something similar.
>
> Then pull out 'other' Postfix data maps via (f.ex) Perl script across
> my 'mail farm'.
> Not sure yet how to do it - but I figure it out.
PostgreSQL is brilliant as you can have views of multiple tables, such
as user id & passwd, then reference another accounts table with foriegn
keys to see if payment is upto date, & how much they paid (disk quota).
Then from this one view, just select * and dump that data into flat
files, then push to your front line smtp, imap, webmail, shell... boxes.
No fancy SQL in the scripts, let the DB do the work for you with views &
stored procedures. (Your business logic is separate from the oily bits
of service implementation)
Implement another service, such as web hosting accounts, then just write
another SQL view, and another Perl script to config apache, etc, etc.
My basic point is this: you can go to a lot of bother to get some
services to auth against SQL, then you want to bring up another service
and there is no way of using SQL directly, so you write some scripts to
generate flat files. Then you bring up another service,.... So why not
just do it that way from the beginning? After all, the app was developed
to use flat files, so as a mere user of an app, why fight against the
developer?
>
> How about - using OpenLDAP?
Same thing. Flat files are fast and reliable, and are basically the only
way to give users shell access (mutt/pine) on OpenBSD as login wont auth
against LDAP or SQL.
--
Craig Skinner | http://www.kepax.co.uk | [EMAIL PROTECTED]
