On Wed, 2002-10-09 at 01:49, martin f krafft wrote: > 1. Select three servers to be the LDAP servers, configure them all for > ldap-ssl (no clear-text here) and then hook them into > a master-slave configuration with two of them mirroring the primary > one. I'll use bind9 round-robin to do some fairly unadvanced > load-balancing between them, and should be able to deal with the > failure of one of the three servers fairly easily.
For highest availability, you should have at least 1 and preferably 2 ldap servers per subnet. What is your network configuration? > 2. Move user management to the LDAP tree. Ideally, I want /etc/passwd > to contain no user but root and the various other defaults that > Debian installs. All users for all systems should be placed in > a global LDAP tree, with each user's record specifying what systems > s/he may log in to. Sure. This is easy with pam_ldap and libnss_ldap. > 3. Separate the mail users from the real users. About 70% of my users > never log in and simply use IMAPs or POP3s to retrieve their mail. > These should also live in the LDAP tree, but possibly under > a different subtree. I'd like to keep using postfix + courier to > handle all mail tasks. Is this possible, or should I start looking > into cyrus? Postfix works with ldap just fine. I use postfix/cyrus, but postfix does all the heavy lifting. It uses ldap lookups to determine how to route to an address, and just calls the appropriate mailer. It looks up with the key maillocaladdress, and uses the mailroutingaddress attribute: maillocaladdress: [EMAIL PROTECTED] mailroutingaddress: [EMAIL PROTECTED] Will deliver to cyrus user mailbox with the command "cyrdeliver -R dave" maillocaladdress: [EMAIL PROTECTED] mailroutingaddress: [EMAIL PROTECTED] Will deliver to a cyrus BB (shared mailbox) with "cyrdeliver -R -m Press" maillocaladdress: [EMAIL PROTECTED] mailroutingaddress: [EMAIL PROTECTED] Will deliver to our customer service application with the command "mailer.cserve --queue=generalsupport" The other half of that coin is IMAP authentication. Cyrus uses PAM, so if you have PAM working, cyrus will work. I assume that Courier will use PAM as well. If you're using PAM for your mail authentication, then all mail accounts have to have posix account attributes (i.e., they're all shell accounts). Technically, Cyrus actually uses a auth daemon called saslauthd. My saslauthd is configured to use PAM, but you could configure your saslauthd to use straight ldap if you wanted, in which case it could authenticate against any ldap entry that had a userpassword attribute, which would mean that you could create pure mail accounts that don't have any corresponding presence in posix-land. > 4. Put major user configuration items (like .forward, spamassassin) > into the LDAP tree. I am sure postfix can handle this particular one > somehow, and one can probably hack solutions up for other proggies. Now you're getting into an area where I haven't done much. We don't support .forward because Cyrus uses sieve, which does lots more than .forward (although not as much as procmail). For spamassassin, I use a custom proxy that adds a single header (x-spam-color: green|blue|yellow|orange|red), and the users' sieve files can filter on the color. This doesn't support per-user black/white lists, etc., but my users aren't sophisticated enough for anything more anyway. > 5. Put major system configuration (postfix, bind9, apt, etc.) into the > LDAP tree. Depending on which way you want to approach this, some of these things are probably not such a good idea. There are two broad ways of doing this. The first is to actually make the application speak ldap, and look up its configuration entries in the ldap tree instead of in its own configuration file. The second is to actually store the configuration file as a BLOB in the ldap tree, and have a program that extracts that and puts it into the program's native text config file. The problem with the first approach is that it can be a lot of work making the application speak ldap, and some programs just can't be configured with ldap. For example, apache config directives often need to be ordered (i.e., rewrite rules), and apache also supports things like conditional directives, but ldap is a non-ordered directory. The apache config just doesn't map to the ldap data model. The problem with the second approach is that you're adding complexity that you don't need to. Instead of keeping your config file in a simple text file in the filesystem, where you can edit it with any tool, manage it with CVS, etc., you're putting the file into the ldap database, which buys you very little. > I do have one question on LDAP: Can it be used as a relational > database? No, ldap is not a relational database, and it doesn't really make sense to try to make it one. An ldap database consists of a key and some unordered attribute/value pairs. You really want to use a combination of tools: ldap for directories (passwd, group, shadow, etc.), text files for software configuration, and some glue software like perl and cfengine to put it all together. Here is what I use ldap for in my site: User info. Everything that there is to know about a user, including, but not limited to office number, phone, etc., mail routing information, posix info (i.e., /etc/passwd). I've also used it for things like quickpage info (the pager service, pager id, service phone number), and at one site, used it to manage a user's WinNT desktop configuration. Group info. This is posix info (/etc/group) and non-posix groups. Non-posix account info, i.e., web accounts protected by auth_ldap, pure mail accounts, etc. Mail info. Mailing lists, non-human mail addresses, etc, mail routing of all sorts. Host info. All of the meta information about a system: ip addresses, cfengine classes it's part of, etc. I pull a lot of this together with perl and cfengine: a perl script generates /etc/network/interfaces based on the ldap info. Another perl script generates a customized cfengine script based on info from ldap combined with other cfengine fragments, and the cfengine script installs the appropriate config files onto the host. -- Dave Carrigan Seattle, WA, USA [EMAIL PROTECTED] | http://www.rudedog.org/ | ICQ:161669680 UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
