Slashdot Mirror
Deploying OpenLDAP
The book begins with a quick note that the target audience is those wishing to install and configure OpenLDAP, and not those that wish to delve into the intricacies of LDAP architecture. Unfortunately, Jackiewics delivers on this promise. While I didn't expect the book to provide me with a guide on enterprise-level LDAP deployment, I had hoped to see more focus placed on design, but that wasn't forthcoming.
The first chapter, "Accessing Your Environment," is a moderately good review of how to identify key elements of your company that are appropriate for inclusion in a directory service. In addition, Jackiewics makes a clear case that an LDAP directory is not a relational database -- so don't try to replace Oracle with OpenLDAP. A very good point.
Chapter 2, "Understanding Data Definitions," provides background information on how schemas are defined. Basically, a schema is just the types of object classes and attributes that your directory supports. Jackiewics actually does a good job covering customized schemas, which is a troublesome area for new OpenLDAP administrators.
It was in Chapter 3, "Implementing Deployment, Operations, and Administration Strategies," that I was hoping to get some real nuggets of information. Alas, that wasn't forthcoming. The chapter should be renamed to "Where to put your OpenLDAP server on the network, and what to name the server." There are some areas of this chapter that really disappointed me. The most culpable: Jackiewics spends almost four pages explaining how to come up with a good hostname for your server, and then a brief page on understanding OpenLDAP's log file, and that brief page mostly contains example output. This chapter is also a good example of a bad book layout -- why are we reading about hostname conventions in the same chapter that discusses debug output?
Chapter 4, "Installing OpenLDAP," is a decent HOWTO for installing OpenLDAP. It also provides several manpages in case you accidentally deleted the 'man' command on your own system.
Chapter 5, "Implementing OpenLDAP," is kind of the "catch all" chapter. Jackiewics discusses how to decide on hardware, but his examples aren't very clear. One of the real gems of the book is his discussion on SASL and OpenLDAP. In addition, there is a reasonable discussion of replication between OpenLDAP servers. Alas, there is almost no troubleshooting on replication, and replication does hiccup at times. (Indeed, this book contains essentially no help in troubleshooting any problems.) Another sore point: Jackiewics only provides a single paragraph on access control (i.e., OpenLDAP ACLs). That topic alone deserves its own chapter.
Because Jackiewics had specifically stated that this book's scope was quite narrow I would typically be more lenient. However, Chapter 6, "Scripting and Programming LDAP," consumes sixty pages that are immediately outside the book's scope. I would prefer to see this chapter removed entirely, and the sixty pages devoted to a chapter on troubleshooting OpenLDAP and deciphering slapd's debug log file, and perhaps another chapter on designing a scalable replication infrastructure using OpenLDAP. Unfortunately, what we get is essentially sixty pages of manpages and documentation labeled as "Scripting and Programming LDAP."
Jackiewics closes the book with Chapter 7, "Integrating at the System Level," and Chapter 8, "Integrating OpenLDAP with Applications, User Systems, and Client Tools."
Chapter 7 discusses how to replace "old technology," such as NIS and Sendmail alias files, with LDAP. Not a bad chapter, although Jackiewics continues to delve too far into man-page material. Chapter 8 provides examples of using LDAP in Apache, Pine, Samba, and various other types of clients.Overall, I would say that I left this book with little new information. People that are just now installing OpenLDAP may find the book beneficial, but I really didn't see any material that stood out. My personal belief is that this "Deploying OpenLDAP" needs to provide far more troubleshooting and example deployment scenarios and less regurgitation of manpages and HOWTOs.
You can purchase Deploying OpenLDAP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It was in Chapter 3, "Implementing Deployment, Operations, and Administration Strategies," that I was hoping to get some real nuggets of information. Alas, that wasn't forthcoming
What a surprise. I would have expected each of these substantial areas to have their own individual chapters on strategy.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Geographic division of the LDAP tree is very common and works best for most situations but it is not a requirement. Depending on your environment you may prefer to divide the tree by department(political) or by function, or any other way you can think of. What usually makes the decision for you is your business process and network operation/replication.
There are many books available that cover this topic. From this review, I would skip this particular book.
It covers more recent RFC's that are typically not even mentioned in other references. It also covers both commercial and open source solutions to problems of scaling, standards, and interoperability. Also, this is a fast paced book and covers in just a few pages what other books fill with useless garbage and repetition.
This is really a carryover from the now largely-obsolete X.500 days. In most cases, a geographical based setup (or in fact, breaking up the DIT at all) is not the best practice. RFC 2247 recommends using domain components based on your DNS domain (so if your domain is example.com, then you could use dc=example,dc=com). Most of the large deployments (at least in the millions of users) I have seen do this. Once you have the suffix named, then it is often best to just leave it relatively flat below that (e.g., all users below "ou=People,dc=example,dc=com") and use attributes within the entries to provide logical arrangements of users.
Note, however, that some directory servers do not perform well or scale very well to larger systems, and therefore they often recommend that you break up the DIT so you can spread it across multiple systems in order to handle the necessary load. If you're in a situation where this might be necessary, then perhaps it's a better idea to look at a directory that can scale.
So I am to assume you would spell out common IT acronyms like Transmission Control Protocol/Internet Protocol? Or Hypertext Transfer Protocol?
I hope you never write an article about a piece of GNU software. Better start expanding that one now.
"Power corrupts, and absolute power corrupts absolutely." -- Lord Acton
It's obvious you haven't read the book. All the information in the book points to LDAP not being used as a database and helping to structure info. You're a Linux weenie and your web site sucks.
Are there any decent books on ldap ? (amazon say no decent books either)
My problems with ldap:
1. Why do you have to buy a 'commercial' product (no not MS - but say IBM (domino),Novell (nds))
2. or Enterprise Linux?
Please do not get me wrong
1. Writing ldif files is easy
2. Ldap (i assume is easy) but only if you have done it before
Openldap still appears to be a 'priesthood' occult.
Send Peter Clifford Francis Macrae comdoms to 23 Bedford St, St.Neots, PE19 1AX, England
This is because LDAP isn't used widely outside enterprise markets.
It's not going to be usefull for a web/file/print server unless they are part of a wider sceme.
It's for managing large amounts of desktop users (as in Microsoft's LDAP service (aka Active Directory)), and user information, which isn't something you see very often with Linux deployments.. yet.
I'll probably get crucified for this, but the Microsoft Press books on Active Directory actually get this right. It's specificially focused on Active Directory, of course, but there's a lot of it that is applicable to any form of LDAP. MS recommends that you configure your sites (essentially, units of replication) based upon geography and you configure your LDAP based upon the IT organization. Factors to take into account include administration responsibilities and security concerns. Sometimes, this coincides with geography. If you have local admins at each location, it might make sense to put users and computers at each location in a seperate OU. You can then delegate full admin control of the OU to the admins at that location. On the other hand, in a different structure it might make sense to divide your OUs up by departments, with, for example, everybody in Sales in one OU, regardless of which location they work.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
I really think the absolute VOID of good practical LDAP books is why microsoft is winning.
If ldap had any documentation for how it would be used, there would be stunning amazing products to pound the living tar out of Active Directory. Unfortunately for free software and whatever author-should-be that never decided to get rich, no one has stepped up to the plate.
There is no more pressing need. Period. At all. Directory services are absolutely vital to absolutely everyone.
I've been pissed off over this for years. I got the whole LDAP+Kerberos+PAM+every service known to man thing working but could not for the life of me figure out how to build an ldap infrastructure to manage it. Albiet I was so tired of the whole project by the time I got there I didnt have much patience (and all too many other projects).
Basically RedHat and Novell exist based on making people pay for their proprietary directory services. I realize cutting them out could be concieved of as a bad thing, but I'm sure they can adapt. On the other hand, Microsoft will finally have gained a sincere challenger.
Myren
In reality this book is meant to be for LDAP beginners and Tom does make that clear. I believe the book was actually originally written as a college text which further strengthens the point is geared for a beginner. Having a actual paperback book on man pages and scripting examples is probably one of the most lacking pieces of documentation around for LDAP. The only good docs I've found on Net::LDAP and even the php libraries are only the authors api docs. The truth is you need scripting examples to get good at managing LDAP.
Flat actually works better for replication. I've done designs that have 2mm, 8mm and 10mm users. When you get to that level, flat is best, and small numbers of attributes is highly recommended. On the 2mm, the tree was c=US, dc=company,dc=net. Below that was ou=people, ou=companies, ou=divisons. Under ou=people were all 2mm users. They had 22 attributes attached. The replication was from one master to 2 rep hubs to 8 consumers. It served as the basis for a portal. Worked like a charm.
Yes, this was on real LDAP- SUN and Netscape.
The 10 million was for a very large ISP (as was the 8 million). They had similiar setups-- ou=isp, ou=people, ou=companies, ou=administrators. Again, worked great.
One mistake people make in LDAP is to make it look like an organization chart-- big mistake. Use your attributes to create context and you'll be fine. Just keep your entry small.
Again, not a replication nightmare at all, its actually the opposite that's true-- the more complex the tree, the harder replication is to complete and index properly.
# nohup