LDAP -Time to Leave Home, Young Man
If you have followed my articles on LDAP, you know we began looking at objectClasses in the last installment back in March. Since that time, I haven't written much more about directory servers. I began contemplating whether or not to continue the LDAP series because things have changed. Let me explain:
When I began this series in September 2006, I wanted to convey the approach I used in Linux System Administration (LSA). As O'Reilly, our book publisher, stated:
The ingredients for this book had been scattered throughout mailing lists, forums, and discussion groups, as well as books, periodicals, and the experiences of colleagues.
In September, LDAP documentation, though some what scattered and in need of a fix, existed more than the other topics in LSA. As the lead author, I wanted LDAP included in our book. My editor thought differently.
The book addressed experienced system administrators of any operating system and seasoned Linux power users needing complete documentation to advance to sysadmins.
LDAP did not seem like a subject for the faint of heart. I felt like traditional authors and LDAP team members refused to address beginners. The series, we began last September, addressed beginners. It filled the hole I saw in the existing documentation out there.
As one of the authors of the Book of Postfix suggested, one needed a deep understanding of LDAP to build a company mail server. I wondered why. Then I remembered how I struggled with the subject myself as I began working with directories. Beginners need help. They need a decent introduction or their eyes glaze over and they conclude that LDAP isn't for them.
After consider thought about the subject of LDAP today, I believe you can pick up Gerald Carter's book, LDAP Administration and it can take you the rest of the way. Aside from that, the Fedora Directory Server documentation project now does a first class job of getting you over the LDAP hump.
Have you worked in an environment where directory services exist? Then you, more like than not, understand how LDAP makes the IT world a better place. I have worked with infrastructures where Novell's e-Directory and Identity Management System, OpenLDAP, and Active Directory existed. Currently, my employer uses Active Directory.
I do not think LDAP is an intuitive technology. You need to focus and read repetitively to grasp the subject matter. If you want to become proficient, then lower your time expectations.
I have gone from working as a system administrator to working as a full-time technical writer and system analyst. I no longer build web sites, commerce enable them, build complex networks or lead development projects. I document development processes, watch the customer service department, test products,write Sarbox documents and user manuals. It's a complete change from my previous life.
Still, I continue to study the writing craft. I read "The Elements of Style" repetitively. I have not memorized it, but I may have accomplished that in the near future. Why would I do that?
Regardless of one's discipline, he or she needs to keep after it from a theoretical through practical application. With LDAP, if you want to master it, then read about it, practice it and put it to work for you even in a home network. You'll find ways to deploy it.
I doubt that you will see much about LDAP from me in the future. I might gig you every once in a while to remind you to keep your eye on the ball, but it's time to set out on your own.
Respectively submitted
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Trying to Tame the Tablet
- git-annex assistant
3 hours 31 min ago - direct cable connection
3 hours 53 min ago - Agreed on AirDroid. With my
4 hours 3 min ago - I just learned this
4 hours 8 min ago - enterprise
4 hours 38 min ago - not living upto the mobile revolution
7 hours 29 min ago - Deceptive Advertising and
8 hours 4 min ago - Let\'s declare that you have
8 hours 5 min ago - Alterations in Contest Due
8 hours 7 min ago - At a numbers mindset, your
8 hours 8 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



Comments
Tom hit it write on the head
Tom, I agree completely with you. OpenLDAP veterans all swear there is sufficient documentation, but to us "noob" junior admins, there is virtually no documentation that helps me actually build a working server. Theory does me no good if I never see it in action.
I'm the IT manager for a small company, and we do not have LDAP here. I can't see it in action. We use M$ servers. I'm in a position to replace them with linux servers, and they let me learn linux here at work. However, I'm having great difficulty getting past the rookie level.
I have been trying to learn samba+ldap for several months now, and although I have made some progress, I still can't seem to get things working right.
I own and have read the above mentioned book LDAP System Administration, which only has a few pages talking about getting samba to work. I have also read the OpenLDAP v2.3 Admin Guide, which also makes some mention, but not enough. I have also read the samba docs samba3-howto and samba3-byexample, and the samba book by R. Smith. They cover samba quite well, but do not go into enough detail integrating into ldap.
As I see it, the problem is not ldap documentation, or samba documentation, or suse documentation (the distro I'm working on). Theres plenty of theory documentation around. It's a total lack of integration documentation that teaches me how to get ldap and samba to work together, on an opensuse (or any distro) server. If you google for samba+ldap howto's, sure there are some out there for various distro's, but none of them really teach you anything. They all assume you already know how to do it, and list some sample config files, and say tweak to your liking. I bring up howto's because there are NO books (that I can find) that teach you the hows and whys for actually building an ldap server integrated with samba on a specific distribution.
For instance, I found ONE howto for opensuse 10.1 configuring samba+ldap. It is poorly written, has bad suggestions, and will not work on opensuse 10.2. There are NONE for 10.2. I found a debian script that automates everything for me. If I was a debian fan, it wouldn't really help me learn, unless I want to read every line of code. Sure I could learn it that way, but that would take an extremely long time, since I am hardly a coder yet.
As for support, the linux forums are full of people asking questions, but most answers come from other noobs asking the same questions. It doesn't help me to post a question, then get five people telling me to RTFM!
I am learning at a snails pace, and at times I wonder if I can maintain the enthusiasm to finish learning all this stuff. It is very frustrating.
Tom, you brought up a valid point that applies to more of us than you may realize. I wonder if you are in a position to help us out. Maybe somebody on your team can address some specific scenario's, such as a opensuse10.2+ldap3+samba3+mail+squid+vpn+http+mysql howto :)
I've been documenting what I've learned, and I intend to release a howto when everything works. I wish there were some veteran admins that were good at writing, and would make the effort to write one. It would probably be very easy for them to write. They would be helping probably thousands of people that are trying to learn what they know.
Until then, my addiction to coffee continues to thrive...
> I found a debian script
> I found a debian script that automates everything for me
You can put this script for to download,
TIA,
LDAP Documentation
I've been an LDAP administrator for a long time, since OpenLDAP version 1.2.x, which is awhile. :) And I've heard the claims about bad documentation *FOREVER*. And to be blunt, it simply isn't true. LDAP is well documented. For some reason Open Source people tend to only view HOWTOs as documentation; books about LDAP in general are consistently ignored while people go on and on about not understanding schema, partitions, terminology, etc... It is the result of a kind of blindness, not a shortage of documentation. If you take the time to learn about LDAP then things in specific services like OpenLDAP make more sense and seam more intuitive. Building a directory service is no trivial thing to taken on lightly; my employer took three years to bring everything under the umbrella of our Dit. It was certainly worth it as LDAP is a wonderfully flexible and robust technology. But skip all the HOWTOs and learn about LDAP first.
LDAP Documentation
I think it's a matter of experience. Once you learn something, it seems logical and you wonder why someone else doesn't just get it. Documentation on LDAP? Maybe you have selective perception - like when people buy a car, suddenly they see the brand they drive everywhere.
I have experience with LDAP too - a lot of experience. But, I don't see quality in the documentation that does exist. It's sloppy, incomplete and does little more than go around in circles. To learn LDAP, you have to put your hand on the keyboard and work on it.
You just admitted it took three years for your employer to bring everything under your DIT. Well, if someone doesn't know LDAP terminology, then what's a DIT to them?
I have to side with Adelstein, who doesn't put down LDAP documentation. He just seems to say, that it's difficult for beginers to get over the hump. I agree.
I wish that the articles in
I wish that the articles in this series had been more helpful. I read all of them, and there just isn't much to them. The OpenLDAP Administrator's Guide is very good; I learned more from spending a few minutes with it than this whole series. After a couple of weeks with the admin manual and a lot of manual data entry I had a functioning LDAP server for a LAN serving 20-some users, for both network authentication and central address book.
The data migration is the slowest part. We're cleaning it up as we go, which takes longer but we're weeding out a lot of cruft. I don't think three years for a larger shop to migrate is out of line. They probably have to integrate data from multiple sources and also do a clean-up, plus testing, and not interfering with business.
Now I have the O'Reilly book 'LDAP System Administration' and it is very helpful too.
Corrected Link
For those looking for the book mentioned above (and don't know how to use "hred" links ;) here is the correct address.
Tom, thanks again for your work on this subject.
Corrected Link
Jon, thanks for pointing out the href typo. It's fixed now. Regarding your thank you, you're welcome.