<quote who="Howard Lowndes"> > Now, let us consider setting up my database more like the examples. The > questions here are: > > 1: Can I have more than 1 "database bdb" entry, say 1 for each of > several disparate domains? > > 2. If I can have more than 1 "database bdb" entry, can they all co-exist > in the same directory path "/var/lib/ldap" or do they need separate > directory paths "/var/lib/ldap/firstdomain", "/var/lib/seconddomain", etc? > > 3. Do the rootdn's have to match each dc= for its suffix or can it be > quite different, and can I have a common rootdn for all domains? > > 4. I understand that multiple "database bdb" entries are permissible and > apparently multiple suffix entries are permissible. Are > multiple/multiples permissible? > > 5. If multiple suffixes are permissible under any "database bdb" entry, > then how is the following considered: > suffix "dc=example,dc=com" > suffix "dc=sitea" > suffix "dc=siteb" > Is the third line a subset of the second or of the first?
Gus gave you great technical answers to your questions - I'm going to focus more on the "Zen of LDAP" side of things. :-) Sorry that this email is so long, I hope it's worthy of more than a quick skim. Your examples and questions suggest you want to "host multiple domains" in your LDAP directory, and that you're conflating this goal with the structure of your directory - ie. the generic DN, the multiple db files, domains as dc elements under the generic DN, etc. This is not the way to go with LDAP, and it's usually learned the hard way, because there seems to be a vacuum of written documentation about LDAP best practices. So hopefully this will help a little bit. Firstly, try to keep thinking about LDAP as a directory, not a database. It changes the way you perceive problems, and lets you see past some of the things we assume from database land. You'll often read about LDAP explained in terms of phone books, because they are physical directories. It's handy to use this metaphor, and think about its differences in the digital domain, when dealing with LDAP. For example, a) why do we have separate phone books, and b) why are there different sets for residential and business entries? (a) is easy: it'd be a fucking expensive and unwieldy to produce such a huge book. In the digital domain, we talk about management and scalability. (b) because that's the easiest way to structure the information for humans, particularly that crucial first categorisation step (when you want to get as rid of as much irrelevant information as cheaply as possible), but it'd be pretty hopeless and arbitrary for a computer to deal with, right? So some decisions are based on human management, some are based on computer scalability and application of the data. In the case of hosting multiple domains, your brain *really* wants to conflate all the information about a single domain into a nicely identifiable ball of stuff, whereas the computer (and its software) just has a bunch of unrelated configuration data that happen to work together. WARNING: Do not think of "LDAP" in general as a management tool, think of it as a directory-optimised data storage and retrieval tool. Management tools are built on top of LDAP, and some are really very cool, like eDirectory and Active Directory. But though they have LDAP at their heart, most of what you see is the management infrastructure. When you're working with OpenLDAP, you are dealing with the storage infrastructure, and usually custom management tools, because we are cheap and dirty and haven't solved many of those hard problems in FOSS land yet. *cough* So, go flat. Put all of the entries for people under ou=People. Their mail attributes will identify them. Put all of the hosts under ou=Hosts. Their DNS attributes will identify them. This will make it easier to configure your applications, and manage changes to your directory in future. You won't need to worry about having separate bdb files until you're really pushing scalability limits - it is transparent and has nothing to do with management of the directory. *Do* think about using one of the simpler backends, such as ldbm. bdb is a pain in the arse to manage, and doesn't give you enough bang for your buck to be worth bothering about (again, until scalability or performance are massive concerns - I was running a very busy 80,000+ account mail server on ldbm). Experiment with your applications and policies before mucking around too much with the details of LDAP. That's *hugely* important, because you can spend a lot of time working around your assumptions if you don't think about your applications before you put your directory together. Finally, go flat. Yes, it's great that LDAP is hierarchical, but it's too easy to abuse and tie yourself up in knots. It's not a benefit, it's a feature. :-) And to finish off... go flat! :-) - Jeff -- GNOME Summit 2005: October 8th-10th http://live.gnome.org/Boston2005 "I think hot Chinese girls who kick ass are the wave of the future, as far as films go." - Cody Russell -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
