On Fri, Jun 29, 2007 at 09:41:49PM +0200, Almir Karic wrote:
quoted text
> >> i like virtual mail users.

I don't. But that's me.

quoted text
> 
> if you have relativelly few users the postfix hashes should do the
> trick, there is one annoyance tho, after every edit you have to run
> postmap (easily solvable by wrapper scripts). i tend to use mysql,
> maybe it is because i'm used to it.
> 
> if you have trully big setups you might wanna look at ldap, from what
> i've heard/read it should perform well under heavy read intensive
> operations.
> 

Err... No.

NOTHING outperforms flat files. LDAP is good, but not that good.

The more users that you have, the *more* likely you are to use postfix's
builtin maps (esp btree).

The way that ISP's often do it:

Keep customer data in a Postgres database (views, forigen keys, ACID,
triggers, stored procedures, functions,..... this is what a database is
for....) Support staff and customers can web into this and manipulate
accounts. Heck, even give the account's lassie a button where she can
suspend services for non-payment. Customer data != OS data.

Have scripts that pull data from (materialised) views periodically, use
that data to generate the postfix maps. Diff the new maps to the live
ones, and install the new ones if there is a difference, on all of the
MTA boxes in your mail farm.

When you have (tens of) thousands of users, your CPU is going to be busy
with spam and virus filtering, and SQL is just way to slow.

LDAP is faster, but it is just as much work to set up as is some
perl/shell scripts to set up maps. But you have introduced a weak point,
namely LDAP must be online for you to receive mail.

Repeat the above for passwd, httpd.conf, ftpusers, ftpchroot,
sshd_config, quota.user, mailman, courier,.... mysql wont help you with
half of the services that you'll end up offering, so why bother?

And just so you don't think that I'm anti SQL, I work as an SQL Data
Analyst. Before that, I worked as a sysadmin, and before that, I worked
as a sysadmin for a national ISP.

Just take the time to think about what it is that you want to achive,
and work back from there, using the bare minimum of stuff, because stuff
goes wrong. e.g: you place all of your trust in a database, and a new
release comes out, that enforces strict practices that your schema does
not adhere to. You upgrade, can't serve requests for week while you
alter all of your data, your name is mud. If you use flat files, kill
the update cronjobs so that things run as they are, fix your data, and
then you can insert new customers. But your existing customers are
unaware that there was a problem at your end as the vast bulk of
business went on as normal.

SQL is complex, and complex equals unreliable. It has its place, but be
careful where you use it.
-- 
Craig Skinner | http://www.kepax.co.uk | aye-right@kepax.co.uk