LDAP Tools - Where are they? 350
fixe asks: "I have spent the last few months up to my eyeballs in LDAP. While I am still hopeful of what LDAP can bring to the table I am admittedly disappointed in the tools, support and documentation surrounding the standard. I have been successful at creating and populating an LDAP directory and even authenticating against it, however I cannot find decent replacements for useradd, userdel, usermod, passwd, etc. Nor have I found any decent LDAP editors or browsers (preferably console or web-based). I am hoping that the Slashdot crowd might be able to shed some light on the subject. Are there any LDAP veterans out there who can reccommend any tools? What is the best way to maintain system account synchronization with an LDAP directory? Or perhaps, is there a more attractive alternative to LDAP?"
Re:Directories are dead in the water (Score:3, Insightful)
XML is a file format (or metaformat), not a directory service like LDAP. The two technologies are orthogonal.
>its hard to make an argument of listing >another protocol on an isolated port to provide a >solitary service
<sarcasm> Yeah that's a great idea! Let's run everything over port 80! </sarcasm>
>There also doesn't appear to be much corporate interest - Microsoft has moved its mindshare >strategies to web services, leaving the only big backer of LDAP being Novell - not really a key >industry player at this point.
Hello?? Active Directory is LDAP based. Admittedly it's LDAP with the usual "embrace and extend" twists like proprietary Kerberos extensions and slightly non-standard schemas, but LDAP none the less.
Re:Java based browser/editor (Score:3, Insightful)
Re:ever hear of Freshmeat? (Score:2, Insightful)
Re:Anything but OpenLDAP (Score:4, Insightful)
It all works fine on someone's home machine, because it's never under any load. Try to put it into a moderate production environment, though, and it all falls down go boom.
I used to hear similar comments about open source NIS implementations 3-4 years back.
So you either start load testing it yourself, understand why it's broken and fix it. Or go with a commercial product that has already been through this process.
*sigh* (Score:3, Insightful)
1) If the public protocol is leaky, why not develop their own, totally different & competing protocol?
2) If they did care about the public domain issues and improvement, why not submit their improvements to the standards body to have their "improvements" included?
3) Failing or separate from this, why not license out their "improvements" to other software vendors? They would still make money, right?
I think the truth is that while it is possible that MS may have made a few small improvements (doubtful, but possible), their real goal is to ensnare new customers and to dig existing ones even deeper. If you still disagree, I would appreciate hearing any lucid arguments.
Re:Why use LDAP? (Score:3, Insightful)
NIS+ is a truly elegant architecture, in many ways, what AD should have been. It's far superior to AD, LDAP, or any other X.500-derived directory - that ISO/OSI brain damage is just too deep to let X.500's ilk be easily used in the real world.
Unfortuantely, Sun really botched its attempt to get NIS+ accepted, for several very good reasons:
1) Although the directory itself was incredibly impressive, and worked very well, there were NO administrative tools usable by mere mortals. I was a "Network Ambassador" at Sun at the time NIS+ was attempting to make inroads, and I can tell you that even amongst that elite group, not 1 in 50 was capable of setting up and properly administering NIS+ in a configuration suitable for enterprise use. Some things were just impossible, like recovering from a lost root key: You just had to rebuild everything from scratch. Secure, but hardly practical. This inordiante complexity may well be why there's still no Linux NIS+ server (besides the fact that one would be pointless now...)
2) There was no good migration plan from NIS to NIS+, and no way to keep the two in sync: it was pretty much an all-or-nothing scenario, at least for the Unix boxes. Not surprisingly, lacking Microsoft's arm-twisting ability, all but a handful of Sun's customers chose to pass NIS+ by, no matter how good it was.
3) Sun tried hard, but didn't make adopting NIS+ sweet enough for IBM and HP, who at one time had "committed" to putting NIS+ into their Unix OSes. Unfortunately, the combination of NIS+ being perceived as "Sun's" and its underwhelming adoption even solid Sun accounts (due to reason #1 above) led to its not being considered a serious contender.
4) If you really know what you're doing, it's possible to build a hierarchical multi-domain name/directory service using NIS, although I only know of one company (a Fortune 20 former employer) that's ever actually put this in production enterprise-wide. All the capabilities are there, it's just that very few people bother to figure out how NIS really works. We eventually wound up replacing regular NIS with a security-enhanced superset NIS (and appropriately modified utilities) of our own design, where all appropriate changes at a higher level filtered down to the lower domains, and each domain only had to administer its own portion of the namespace.
Sad, but I'd say NIS+ is pretty much completely irrelevant now.
Microsoft and AD have won this battle so far, but it may once again be the unlikely knight Samba that will save the day and turn the tide. We'll see.
P.S.: Side note to comment 1 above: This is just one in a long line of times Sun has developed extremely impressive core architectures and failed in the marketplace. (NIS+, SunNet Manager, Jini, Jiro, and even Java itself, to some degree...) The fallacious assumption is that the elegant core is all that's required, and that dealing with pesky details like administration, management, or writing apps that take advantage of the elegant plumbing can be left as an excercise for the customer, not something worthy of Sun's time and attention. When will they learn?!
Re:Anything but OpenLDAP (Score:3, Insightful)
No I'm saying that any time you post a query about most open source projects not working for you because of load issues, the response is "It works fine on my little home network."
Listen, load and stress testing an application takes a fair amount of resources. It takes money to buy the test hardware and execute tests and such. This isn't something most people can do on their little home networks, so it takes corporate investment to make it happen.
How many people do you know who have a dozen servers and 200 desktops sitting in a room just waiting around for someone to setup and run some tests?
Companies like Compaq, IBM, Microsoft, and so forth have these resources. If Compaq and IBM view OpenLDAP(or whatever) to be critical, perhaps they will make their testing labs available to the open source developers.
Otherwise you are relying upon testing in production, which is not the way to win friends.