On Thu, Mar 20, 2003 at 11:41:27AM +1200, John Blance wrote: > And LDAP is not a fast database - it may seem like one, but it strickly > is just the method of accessing the 'fast database'
Define database :-) Part of the semantic problem here is that LDAP is just a protocol, and does not actually describe the data storage mechanisms - although it implies a 'directory' type of database. Often the term 'database' is used as being equivalent to 'relational' data storage, which is another type of storage mechanish - albeit the more prevalent form, because it's very flexible. SQL is a very flexible language that is often used to get data in and out of a relational database. LDAP can be used as a front-end to a relational db, but directory storage mechanisms are tuned to tree-traversal retrievals. The whole thing is optimised for fast read access, and writes are often difficult, and relatively slow. Relational databases, on the other hand, are structured so that writes are pretty efficient, and the management system will undertake a lot of work over and above the data itself in order to facilitate fast retrieval (i.e. it will maintain indexes - some explicitly placed by the designer, and some implicit in the RDBMS itself) So, you could use a relational database to maintain your rapidly-changing data, and then parcel it out to an LDAP for retrieval. One of the headaches with large LDAP installs is that you often want to have several 'read-only' LDAP servers, but only one writeable. Once your updates have been committed to the writer (an example of rdbms-language there :-) ) it may take a significant (=non-instant) time before your changes have replicated out to the front-end readers. All of which is gloriously out of scope for anyone with less than a couple of hundred servers :-) and a source of problems for those whose networks grow, without taking the initial design hit of expecting sufficuent growth! Or the opposite - where the network was designed to cope with the marketing department's expectations, but real demand is a fraction of expectations ... then such large layers of servers are an active hinderance. And as a final hit - DNS is an example of a working directory service that doesn't use LDAP :-) Unless you're Dan Bernstein, that is ... -jim > > >>> [EMAIL PROTECTED] 03/20/03 11:20 AM >>> > On Thu, Mar 20, 2003 at 06:28:15AM +1200, Liane Williams wrote: > > Thanks for the background info - good to know. > > I guess standardisation and interoperability is another advantage of > > LDAP. > > But LDAP is just a directory access protocol isn't it? What service > > offers the actual directory? Is it part of the X500 compliant breed > now > > on many platforms? > > Yes, LDAP is just the directory service, you can't run an authentication > system to replace NIC with just LDAP ... > > However, NIS is "just" a system to distribute configuration files over a > network, and besides the inevitable problems in doing that, there's the > basic question of having configuration _files_ for system and security > onformation available at all. > > So, you replace the libraries that access files directly (or via NIS) > with libraries that call an authentication system, like PAM. Actually, > most libraries in a modern unix will have this option available. PAM > itself acts as your broker, and will itself use config files, or call a > directory for information. Another simplification - LDAP is "just" a > fast database, so your PAM could elect to use a SQL database instead. > Too many choices are not always a good thing ... :-) > > > I guess my question is - what is the full Linux/Unix equivalent of > > Windows 2000 Active Directory and Domain structure, and Novell's NDS? > > Is there a short answer? > > Now that I'm not sure of, as I've not been convinced that rolling all > your data into one delivery service is a good thing. I've only worked at > scales where either directories were too much overhead (i.e. small > systems) or too limited (large systems). Actually, as with websites, > most of the time you don't need dynamism, but it can be handy. > > Usually I've distributed fixed config files to machines, which means > that they can be "fixed" by admins who don't need to know how the > distribution method works, only that it exists. Obviously you need to > confirm the state of the target before overwriting things ... :-) > > -jim > > > > ********************************************************************** > ** This email and attachments have been scanned for content and viruses > and is believed to be clean ** > > This email or attachments may contain confidential or legally > privileged information intended for the sole use of the addressee(s). > Any use, redistribution, disclosure, or reproduction of this message, > except as intended, is prohibited. If you received this email in error, > please notify the sender and remove all copies of the message, > including any attachments. Any views or opinions expressed in this > email (unless otherwise stated) may not represent those of Canterbury > District Health Board > ********************************************************************** > > >
