Re: using LDAP as a configuration/user management backend
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: dave@pdaverticals.com
mailroutingaddress: dave@local.cyrus
Will deliver to cyrus user mailbox with the command "cyrdeliver -R dave"
maillocaladdress: press-releases@pdaverticals.com
mailroutingaddress: Press@local.cyrusbb
Will deliver to a cyrus BB (shared mailbox) with "cyrdeliver -R -m Press"
maillocaladdress: support@pdaverticals.com
mailroutingaddress: generalsupport@local.cserve
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
dave@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL
Reply to: