![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
![Books Books](http://a.fsdn.com/sd/topics/books_64.png)
![Media Media](http://a.fsdn.com/sd/topics/media_64.png)
![Book Reviews Book Reviews](http://a.fsdn.com/sd/topics/bookreview_64.png)
Deploying OpenLDAP 117
Deploying OpenLDAP | |
author | Tom Jackiewicz |
pages | 344 |
publisher | Apress |
rating | 5 |
reviewer | Dustin Puryear |
ISBN | 1590594134 |
summary | HOWTO for installing and using 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.
Can somebody answer this (Score:4, Interesting)
Whenever I've looked into LDAP, all the tutorials seem to revolve around organising things into geographical locations. This just seems backward to me, and I can't believe for a second that this is how you are meant to use LDAP. Is this really the case, and if not, can anybody suggest some good learning material that doesn't set things up this way?
Re:Can somebody answer this (Score:5, Insightful)
There are many books available that cover this topic. From this review, I would skip this particular book.
Re:Can somebody answer this (Score:2)
One master, two replicas.
Use fast machines with lots of ram, hold everything in memory. Run a recent version of OpenLDAP.
Re:Can somebody answer this (Score:4, Insightful)
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.
Re:Can somebody answer this (Score:5, Interesting)
Just how many LDAP deployments of millions of users have you seen? That were flat no less?
I've seen hundreds of implementations. Most of the ones I've seen had thousands or hundreds of thousands of objects in them and one had over a million objects. I have not seen any implementation, with more than a couple of hundred objects, that was flat.
The thought of a flat tree with millions of objects sounds like a replication nightmare!
Re:Can somebody answer this (Score:2)
I'd be interested in hearing your experience, as I've been on deployments with hundreds of thousands of users under an OU. Most directory structures are going for a flatter design (per resource type), using attributes
Re:Can somebody answer this (Score:1)
Bottom line: It's very 1995 to create your DIT based upon location or department. I've worked with more than 1 Fortune 10 company that had several million entries in a Directory with only a handful of branches in their DIT. Think about having to move users in
Re:Can somebody answer this (Score:1, Informative)
corporate office -> many hospitals -> many clinics & doctors offices / users on local network
Its useful depth
A shallow OU for us would be a nightmare
Re:Can somebody answer this (Score:2, Insightful)
Yes, this was on real
Re:Can somebody answer this (Score:2)
Give the man a cigar!
screw this dividing everything up in branches... attributes are the way to do this.
Flat branches here (Score:2)
Branches of trees should be used for your replication design and security model, they were very important as search bases in X500 but much less so in a typical LDAP directory.
Consider a organisation which has people in multiple countries. It is just as efficient to run a search from the base of people
Re:Can somebody answer this (Score:1)
Re:Can somebody answer this (Score:3, Insightful)
No crucification necessary (Score:2)
While AD is extensible and you can use it in nearly any instance where you could use a "standard" LDAP directory, it's designed for a corporate network. The basic structure, client access, and replication topology of AD is meant to serve this end. It's less flexible, but it works really well.
AD was created in 2000, where broadband and otherwise high speed connections were quickly becoming commonplace between compa
Re:No crucification necessary (Score:2)
Re:No crucification necessary (Score:2)
Designating a specific server to be the bridgehead should only be done manually (opposed to the KCC designating it's own) if there appears to be some impact on one of the DCs during replication.
If you specify the bridgehead and it goes down, replication to the opposite si
LDAP organisation (Score:1)
I guess that many books on LDAP just assume that you are part of a multinational company and use this as an example.
Chapter title based review (Score:5, Insightful)
What a surprise. I would have expected each of these substantial areas to have their own individual chapters on strategy.
Access Control (Score:4, Interesting)
Are there any books on this? I have no problem setting up OpenLDAP (the docs are pretty clear) but am not in a position to use it in anger because I don't have the benefit of learning from other peoples high level mistakes. Access Control is the biggest question mark for me.
Re:Access Control (Score:2)
My biggest question is in schema design. I mean there are hundreds of schemas out there yet it seems next to impossible to put them together intelligently to get an object that would allow something along the lines of
Re:Access Control (Score:1)
If you poke around you can find schema's for apps out here, like Netscape. There are keywords to mark compatible types too.
Re:Access Control (Score:1)
You missed my point, almost entirely.
I didn't say I couldn't create my own schema. I said that something as obvious as what I described should already exist somewhere, and I was hoping someone reading knew where it was. I didn't want to reinvent the wheel with something inferior. I mean I can't be the only person on the planet who is looking for even 70% of what I listed. I'm sure it's been done before and likely includes things I didn't even think of.
That's the bigger problem with LDAP I think -- onc
Disgustingly Bad Book (Score:5, Informative)
Re:Disgustingly Bad Book (Score:2, Insightful)
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.
Re:Disgustingly Bad Book (Score:1, Insightful)
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.
Re:Disgustingly Bad Book (Score:1)
So should disaster happen I can
1. fix 'broken' thing
2. restore backup
3. change hostname
4. Problem ?
Ldap (like imap) is ideal for this
The sooner a good book on ldap appears the better for Linux.
IBM Commercial Products and a good Book for free (Score:1)
From IBM, you should go for the Tivoli Directory Server [ibm.com].
It is a full function DB2-based directory server. Best of all, you can download it FOR FREE.
Re:IBM Commercial Products and a good Book for fre (Score:1)
Do i need to login? - it's the reason I hate all IBM websites.
I'd love to do it myself in openldap - after all its only text files put through a parser to a bdb
Re:IBM Commercial Products and a good Book for fre (Score:1)
HERE IT IS [ibm.com].
Re:IBM Commercial Products and a good Book for fre (Score:1)
If you have no need to change the schema and are comfortable with DB2 admin issues, go ahead and look at this. It really didn't work well where I used to be (as a replacement for the old Netscape LDAP) and was being removed.
Re:IBM Commercial Products and a good Book for fre (Score:1)
You can download and use it for free. Only if you want support do you have to pay. It's also included with other IBM middleware such as WebSphere.
On the linked page there's also a link to an IBM redbook that has a few initial chapters on LDAP. Again this is free for the download.
Re:Disgustingly Bad Book (Score:3)
1a.) Multi-master replication. Something very handy to have when you're looking at high-availability environments.
1b.) Speed. OpenLDAP can be tuned quite nicely, but doesn't match the performance of the commercial app's. If someone has anything contrary to this, I'd love to hear it.
1c.) Supportability. Having a vendor to yell at when it all falls down in pieces is rather handy.
I am waiting with baited breath for Redhat's release of the Netscape Directory server 6 code. Tha
Re:Disgustingly Bad Book (Score:2)
Yup, have to agree here. I do believe OpenLDAP is getting this soon though. I think its in the latest betas.
I'm sorry I can't give you anything better than colloquial evidence, but I do run a 700,000 email a day system
Re:Disgustingly Bad Book (Score:2)
Yup, have to agree here. I do believe OpenLDAP is getting this soon though. I think its in the latest betas.
Well, it's going to be a moot point as soon as redhat releases the Netscape Directory server source that they bought. They've had a few patches over the years, but nothing that made it into a release.
I'm sorry I can't give you anything better than colloquial evidence, but I do run a 700,000 email a day system and every mail coming in is one to three LDAP lookups. The CPU load on my load
Re:Disgustingly Bad Book (Score:2)
You're right, of course. There are 94,000 entries in the directory. Entries are mostly a posixUser objectClass with a few extra attributes to support our mail system (based on qmail+ldap, but we don't use qmail anymore - we use exim).
The entries are small. Replication is
Re:Disgustingly Bad Book (Score:2)
I kind of have to disagree. I set it up to replace NIS and serve as a shared addressbook on my little home LAN. I wouldn't say it was easy, but I don't consider myself a once-in-a-lifetime genius and I was able to get it up and running with only the documentation I could find online.
I'm sure a professional LDAP admin would laugh at my setup, but it serves my purposes and is easy enough to maintain. A steep initial learning curve? Sure. Unlearnable
Re:Disgustingly Bad Book (Score:2)
-Mark
Re:Disgustingly Bad Book (Score:5, Informative)
Re:Disgustingly Bad Book (Score:2)
Re:Disgustingly Bad Book (Score:1)
Re:Disgustingly Bad Book (Score:1)
Re:You can spot trolling ACs... (Score:4, Insightful)
I hope you never write an article about a piece of GNU software. Better start expanding that one now.
Re:You can spot trolling ACs... (Score:2)
got no uncles
green needy ugboots
Good things about this book (Score:1, Insightful)
Thanks for the Review. Any recomendations? (Score:4, Interesting)
Sounds like the book could be replaced with a few google searches.
Do you have any recomendations for a Good dead tree on OpenLDAP? I'm getting ready to do a small installation and would be very interested in intermediate reference work/howto/security and trouble shooting book
Re:Thanks for the Review. Any recomendations? (Score:2, Interesting)
It could be replaced by ohh... a card cataloge.
Re:Thanks for the Review. Any recomendations? (Score:4, Informative)
Also, The Samba/LDAP How-To using Samba v. 3 [k12.me.us] by David Trask may be helpful to you as well.
Finally, while I have not reviewed this one it sounds like what you are searching for: LDAP System Administration [oreilly.com] from O'Reilly.
Happy authenticating!
O'Reilly book (Score:1)
Re:O'Reilly book (Score:2)
It got me to the point of setting up slapd and getting my directory populated with the migration tools, and the Gentoo LDAP Authentication How-to got my server up and running on my Gentoo box.
It also has some great examples of PERL's LDAP libraries
Re:Thanks for the Review. Any recomendations? (Score:1)
Even after learning much of the inns and out through trial and error, this book has taught me a great deal I didn't know and desperately needed to know (often without me knowing how desperate).
Sounds like a new book is in order. (Score:5, Interesting)
Go for it!
ldapsh (Score:5, Informative)
Re:ldapsh (Score:2, Informative)
Re:ldapsh (Score:2)
Re:ldapsh (Score:2)
On a related note... (Score:2)
Also, given that this isn't a great book, are there any recommendations for guides on implementing SASL + OpenLDAP out there? Again, I am specifically looking for OpenLDAP + SASL + Kerberos. And pushing even further, any good guides to using Mac OS X as a Kerberos / OpenLDAP client. (Yes, I know OS X Se
Re:On a related note... (Score:1, Interesting)
OpenLDAP Schemas? (Score:2)
1. What are the existing default Classes and attributes in OpenLDAP?
2. How do you add your own custom classes and attributes?
My most recent e
Re:OpenLDAP Schemas? (Score:1, Informative)
Proprietory implementations like Oracle Internet Directory and Sun Java Directory Server among others have their own java gui to browse and edit schema elements as they store this information inside the ldap dabase an
Re:OpenLDAP Schemas? (Score:1)
You are right about the lack of good material on schema design. I surveyed the web a few months ago and found very little (and some of what I did find was trying to treat LDAP as a relational database!).
As a result, I ended up presenting a paper on LDAP Schema Design at the UKUUG Winter Conference. [ukuug.org] The paper covers issues of tree design and also entry design, and explains why the examples used in X.500 and early LDAP documents are not indicators of good practice. The full paper is available from my own w [skills-1st.co.uk]
Re:OpenLDAP Schemas? (Score:1)
Missed opportunity (Score:2, Informative)
1) Has a good explanation of how to implement InetOrgPerson, including userCertificate;binary and digital certificates.
2) Explains ACL's in depth, particular to OpenLDAP.
3) Cover some of the schemas, such as java.schema for storing serialized java objects like Strings and HashMaps. I n
Re:I'm a Man Page Reprint Hater (MPRH) (Score:1)
Microsoft Won (Score:5, Insightful)
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
Re:Microsoft Won (Score:1)
Re:Microsoft Won (Score:5, Insightful)
First off, and FYI, AD is LDAP+Kerberos. "It has nothing to do with LDAP in general"
MS domination of the desktop is because of services like Active Directory, not the other way around. Windows would be nowhere if evolution ended at shared folders. You yourself state "In order to have a well managed windows based network you need AD," which is exactly my point. To have a well managed network you need directory services. No directory services, no prayer, no desktop domination.
Which brings me back to my point; its a joke to think of people trying to promote Linux to buisness or consumers when there's no directory services and no docs for how design them should you be dumb enough to try building them yourself. There's docs for how to build them (as in,
Myren
Re:Microsoft Won (Score:3, Insightful)
I've done a study for the company I work for now, to help make a choice between directory services (Free Software/Open Source, Novell OES, Microsoft AD). I have also implemented the OpenLDAP/Kerberos/PAM/... platform in the past.
I saw the problems. You are right with the fact that nowadays, there is still a lack of administrative tools. That is the only lack, though a big one.
Vendors like Red Hat are taking care of that right now, they will have a solution soon, a
Re:Microsoft Won (Score:1)
just look at the intersection between Active Directory and RedHat Enterprise Linux (RHEL). they both provide many user and machine management directory services. sure, EL provides more system rollout stuff as well, but there is a directory service in there, even if its not called so.
i really hope redhat does something Good (v. evil) with their Netscape DS purchase. couple months ago we had a RHEL talk
Re:Microsoft Won (Score:1)
He said that he expected it to be released within the next few months.
Re:Microsoft Won (Score:1)
In reality (Score:2, Insightful)
recomended book for LDAP (Score:2)
Understanding and Deploying LDAP Directory services:
http://www.amazon.com/exec/obidos/tg/d
A good book.
Re:recomended book for LDAP (Score:2)
For the record, this is a general LDAP book, not specific to OpenLDAP.
http://www.amazon.com/exec/obidos/tg/detail/-/067
Alternatives (Score:1)
Another excellent free book (Score:2, Informative)
(a large pdf file inside the zip)
Search for the title on MS Downloads site. This is a very good book that covers the Unix side of LDAP as well as it does their AD implementation of LDAP.
This is one area that MS got right. They started with open standards and then enhanced it for their servers, while keeping full access to Unix servers. I have no problem with this. We want LDAP mostly so we can in
Decent OSS LDAP browser? (Score:2)
Re:Decent OSS LDAP browser? (Score:1)
Re:Decent OSS LDAP browser? (Score:2)
http://pegacat.com/jxplorer/
Re:Decent OSS LDAP browser? (Score:1)
Re:Decent OSS LDAP browser? (Score:2)
LDAP Programming, Management, and Integration (Score:1)
LDAP Programming, Management, and Integration by Clayton Donley
is an excellent book on the basics of how LDAP works and how to set up LDAP services.
examples of when I should use OpenLDAP? (Score:3, Interesting)
Better book coming... (Score:1)
If the quality is similar to any other of his Samba books, then this will become one of the best LDAP books.
Re:Thank you! (Score:4, Funny)
Re:Uh just me? (Score:2)
Laugh, it's funny!