Between November 2003 and May 2005, I was working on the rather mammoth task of evaluating my department’s environment, analyzing and auditing our infrastructure services, seeing if we could migrate from NIS to LDAP, and then evaluating LDAP server software, writing tools to perform the migration, writing tools to maintain data consistency between NIS and LDAP (for those things that couldn’t use LDAP yet), and writing tools to administer LDAP and integrate it into our environment.
Software evaluation at the time was fairly quick: I looked at eDirectory and SunOne, both of which (at the time) allowed you to store some obscene number of objects under a no-cost license. I chose OpenLDAP at this time because it was libre software with a pretty active support mailing list.
I spent the next year learning the intricacies of OpenLDAP: which back ends might benefit my deployment, how to configure that back end, why my distribution vendor chose not to use the recommended back end (forcing me to build from source), keeping up with the rather frequent upgrades (which the support list folks demand you do, lest you be heckled rather than supported), figuring out how Access Control Lists work, figuring out why some operations were so slow while others seemed blazing fast (this goes back to choice of back end and its configuration), and the list goes on. Over the course of a year, I probably upgraded OpenLDAP 3 times, upgraded the back end at least two times (one was the advent of Sleepycat BDB 4.0, if memory serves), and began to feel like there was no end to the tweaking. I feared I’d be pigeonholed into being solely an “LDAP Admnistrator” instead of a system administrator.
Then, on June 1, 2005, Fedora Directory Server (and Red Hat Directory Server) was released to the world. It wasn’t yet completely open source, but they announced that they were committed to open sourcing the bits that weren’t yet open in the coming months. I downloaded and installed the server, got on the support IRC channel, and imported all of our data in a couple of hours. By September, just three months later, it was in production, and I haven’t looked back.
I also haven’t become a full-time LDAP administrator. Though I’m the “LDAP guy” in my department, the server tends to need just about zero tweaking, and it’s easily as fast, if not faster, than our old NIS setup. However, the feature list of the software is a relatively minor reason for my sticking it out. In fact, I have some issues with Fedora Directory Server: it uses NSS to manage certificates (which is a personal pet peeve that I probably just need to get over), it doesn’t log to syslog, and its graphical interface can be somewhat clunky (leading me and others to share tools to completely bypass its use).
I’m sure to get flamed for this, but a significant part of my thinking in sticking with Fedora Directory Server was that it lacked just about all of the baggage of OpenLDAP. Namely, incomplete, unorganized documentation, and a community that was, and is, quick to wallop newbies, and redirect or outright reject questions to the mailing list. It’s almost as if the community has morphed over the years into a few hardcore, OpenLDAP-using buddies who could care less if anyone else is actually able to do useful things with the product.
In contrast, the Fedora Directory Server has huge, enormous, steaming wads of documentation, a wiki that has a huge amount of more task-specific documentation written by those in the community who waded through one project or another and lived to tell about it, a mailing list that is extremely user-friendly, and even an IRC channel where you can talk directly to some of the folks writing the code, who are an immense help, and whose wisdom often makes it into the published wiki documentation for all to benefit from.
So, in short, Fedora Directory Server is a blazing fast directory server that supports multimaster replication (should you choose to use it), hot backups and restores, access control changes (and many other changes) without a server restart, running multiple instances on a single machine, and it stores its entire configuration in the directory itself, making it completely manageable using the LDAP protocol itself. If you’re a GUI fan, there’s also a graphical interface that lets you do everything from adding new users, to adding new objectclass and attribute definitions, to managing certificates and viewing logs. What’s more, with its PassSync utility, it can synchronize passwords easily with an Active Directory server.
Also, Fedora Directory Server is now completely open source, and has been/can be built on just about any Linux distribution, in addition to Solaris, HP-UX, and even Windows.
I urge you to give it a try!
Great blog entry, Brian!
If anyone is evaluating Fedora DS, I view the clunky GUI as a *strength*, precisely because of the consequent strength of the various supporting programs that get traded around (mostly on #fedora-ds), many of which are more powerful than their GUI counterparts. However, there is still a GUI to help newbies through what can be a daunting process.
I also think it's important to stress the awesomeness of the IRC channel. It has a great signal-to-noise ratio, and, in contrast to the openLDAP channel, is frequented by a cadre of hardcore gurus and core programmers on the project who are more than willing to help.
I second your conclusion!
Excuse this unworthy grasshopper's ignorant question, but is Fedora Directory Server a suitable authentication backend for a mixed nix-OS X-windoze LAN? The magical single-sign on solution?
I haven't used FDS for single sign-on *yet*. However, OS X can authenticate via LDAP, and FDS can fill that role without a problem. Windows authentication *can* be done against an LDAP server, but it involves some other tools, and there is more than one way to do it. One is to use Samba as a windows domain controller, point your windows machines at *that*, and then tell samba to use LDAP as its back end. I believe you can also use pGina to replace the windows login box completely, and pGina can be told to use NIS, LDAP, or whatever as the authentication back end. This, of course, involves client software installations, but it's an option.
So, with some work, yes, FDS (or any LDAP server, methinks) should be able to *facilitate* single sign-on, but it's not the only tool you'll need to pull it off.
Hope that helps.
brian.
pGina looks very interesting. If I'm understanding it, it means no hassling with domains, and not doing the usual samba/winbind/kerberos dance. I think I must try it out.
I rarely do the flame thing, in fact, I don't remember flaming anyone. But maybe I have. I don't consider this a flame just an observation.
We installed FDS sans the gui. My co-author and I have some decent experience with LDAP. I'm not convinced that it's the greatest thing since sliced bread. I wonder if readers of your article will rush out and try FDS and wind up wasting enormous amounts of time and energy only to fail and feel endless frustration. You may have gotten FDS to work, we consider it a kludge/kluge.
Readers should take note of the fact that you did mention months of effort, tons of documentation, IRC channels, etc. You spent 1.5 years studying LDAP.
I just want to STRESS that FDS isn't easy and that you are a system administrator and had a lot of experience before you started this project and then jumped on the FDS bandwagon. You have to have gotten some schooling on the OpenLDAP list and from interaction with those hoodlums.
I spend most of my time solving free software problems. I see howtos and articles about how easy and wonderful things work and discover that few seem to have really done what they say they've done. I'm not saying that about you. But it's a fair observation generally.
Here's the point for readers: This ain't easy and it ain't elegant. LDAP requires patience, time, some strong data modeling skills and a deep level of knowledge and experience in system administration in UNIX or Linux.
In the mean time, thanks for sharing your experience. I get things done with OpenLDAP and have for a number of years. I stay away from the project team and do my own research. I'm not a fan, because it just isn't elegant or easy.
I hope FDS does wonders for the community because we need it. But for now, getting the console to work is nearly impossible. So, if you can manage the CLI great. Otherwise, if you know LDAP, LDAPadministrator.com might be the tool you need to make FDS a reality.
Tom,
It's no surprise that somewhere along the line, somebody somewhere is having heaps of trouble with FDS. No matter if the application is a simple desktop clock or a full-fledged inventory tracking system, there's always someone who the stars don't line up for.
While I absolutely agree that there is a non-trivial learning curve if you plan to do useful things with LDAP (in any form) in a production environment, I also don't feel that your claim that FDS is a "kludge" is really justified.
More detail would be needed about your problem in order for me to comment further on that, but while you correctly point out that I had 1.5yrs experience in LDAP in general, that would seem to have very little to do with how to build a console gui. I've never tried to build the gui for FDS from source, because it hasn't ever been necessary either for me or my clients. The binary packages are working wonderfully. What circumstances have caused you to build from source?
Thank you for STRESSING that I'm a sysadmin who had lots of experience, but the bit about the 'FDS bandwagon'? Say what you will, but when you try to tweak and pull and prod and pry OpenLDAP for over a year, and then you find this product you can download and it "just works" in under a day.... well.... I say "use that!"
I also see no justification for your claim that FDS is not elegant. I've found it to be as elegant as any other LDAP solution, and I've used several. Of course, IMHO, this isn't saying a whole heckuva lot, because I don't find most solutions to be particularly elegant, but this one is no less elegant than the others.
I'm glad you find OpenLDAP useful. I also support OpenLDAP as a solution provider, though I'm not a fan of it. I don't think it gets less elegant than OpenLDAP, personally. Whenever I've ever had a problem with it, it tends to become a treasure hunt. Do I have the latest slapd? Do I have the latest bdb? What's in the DB_CONFIG file? Did you set all of the sparsely documented variables correctly? How about the TLS_REQCERT variable? Are you doing the proper magical incantations for your ACLs?
Ugh. It's always been painful. The only thing more painful to me than dealing with OpenLDAP is dealing with the people on the OpenLDAP mailing lists. Truly a horror.
So we each have our favorites. So be it. Just don't be so quick to judge. It took me about 9 months to conclude that OpenLDAP sucked. I had run it on a couple of versions of several different distributions, tried binary and source-compiled versions of it (and all of its components), run several testing and development servers, and at the end of 9 months, I said "this sucks". I don't know your full experience with FDS, but if you just tried one time to build one of its components from source, and you had difficulty, and now you're warning others to stay away from FDS based on that one experience, I'd say that's unfair.
I wondered if you knew of other sites with more documentation about the FDS + Samba + pGina implementation besides the FDS official site?