On Fri, Jun 29, 2007 at 09:41:49PM +0200, Almir Karic wrote: > >> i like virtual mail users.
I don't. But that's me. > > 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 | [EMAIL PROTECTED]
