Red Hat Opens Netscape Directory

suezz writes " Eweek is running a story that Redhat is releasing Netscape Directory (LDAP) under the GPL - this is huge at least from my point of view. I know of at least two huge companies that have standardized on Netscape Directory for their web applications."

Comments

This was an expensive ordeal...

[coop0030]

Red hat paid $20.5 million for this LDAP. Will they get that in return? Is it possible with this type of software?

Re:This was an expensive ordeal...

[coop0030]

I forgot to mention this in my first post...but if enough customers purchase this by April 30th, Red Hat will have to pay an additional $2.5 million.

Goodness, that is a lot of money.

Re:This was an expensive ordeal...

[Anonymous Coward]

$20M is not a lot of money in Silicon Valley, especially for an enterprise product. Probably nothing compared to Netscape/iPlanet's development costs.

Plus, after years of hotair, RedHat just became credible Windows alternative for internal applications. cheep.

Re:This was an expensive ordeal...

[LnxAddct]

In the short term no they wont make this money back right away, but in the long term they'll make it back a thousand fold. Anyone who has ever tried to setup and configure OpenLDAP knows that its not worth it and will send you to a mental hospital fairly quickly. Netscape Directory (or whatever they're calling it now) is not only extremely easy to configure, but it was designed by brilliant engineers. Back a few years ago the engineers were claiming that one typical server running Netscape Directory could handle 200,000 clients. I haven't looked at the code yet, but according to some Red Hat enginneers that I've talked to that have seen it, they confirm that this is probably possible and were generally extrememly impressed with the code quality. Netscape Directory is high quality from its core all the way out to its exterior with easy configuration, how often do you see that in any environment(commercial or open).

I know that a few of the Fedora devs commented on how they also got a whole bunch of additional code that they hadn't even asked for but came along with Netscape Directory that they are still trying to figure out what to do with. In a worst case scenario, they'll just open source it and let the community find uses for it (Red Hat open sources everything they do, they even allow any open source projects free use of any patents they may hold, patents btw are only held as legal defense). This a great advancement for the community and should allow many more businesses to start migrating to linux. Back to my original point though... this will allow many more companies to switch to linux, whether it be Red Hat or some other distro it doesn't matter. Overall it will increase linux's marketshare and as a result make linux more popular leading more businesses to look at it as an alternative. A good percentage of those businesses will probably become Red Hat customers so everyone wins.
Regards,
Steve

Re:This was an expensive ordeal...

[NixLuver]

Actually, I'm aware of an installation where a single (fairly robust) sun box is running at 200GB db size and 32 million LDAP entries on SunOne (descendant of the Netscape code). It sucks, but it works. Let's be honest - even the NS directory server is a nightmare to set up beyond the most rudimentary schema. Easier than OpenLDAP, true, but *easy*?

Re:This was an expensive ordeal...

[ehvoy]

An active directory-killer is something Linux has needed--that is, one that is easy to set up, and has that MS-like integration. I wonder if they'll include integration with BIND/. Looks like Red Hat is going head-to-head with Microsoft to control the corporate LANscape.

Now the CIO knows he/she can buy Red Hat "Professional" :) and Red Hat "Server 200x" and set up a "Domain" with it.

Re:This was an expensive ordeal...

[askegg]

Novell eDirectory has been available on Linux for sometime and has features Netscape, OpenLDAP, Active Directory and Sun One lack.

Now that Novell own SuSE I except eDirectory to be the number one Linux LDAP compliant directory available.

Re:This was an expensive ordeal...

[kjs3]

I'm familiar with a SunOne install with somewhat more than 32 million users on a Sun cluster about to go into production for a major cellular provider (in pilot for something short of a year). My impression is that you're comments are spot on correct.

Re:This was an expensive ordeal...

[Anonymous Coward]

i used to run netscape directory on linux and had to migrate to openldap due to licensing issues at the time. netscape was a nightmare to manage and openldap was such a breeze to install and manage.

Re:This was an expensive ordeal...

[KarmaMB84]

Configuring anything for serving 32 million user on a cluster isn't going to be pretty ;)

Re:This was an expensive ordeal...

[msp0]

And Sun's Directory Server has features that Novell's doesn't. It runs on Linux. So what's your point? As far as technology goes, there are always swings and roundabouts with different vendors. Price, performance, stability, features, support ... these are always up and down. I've heard plenty of things about eDirectory that make me shudder. Accept that you have made a choice you like and others have chosen differently. And that there is no "number one", except in your own mind, for your own situation. Or put your Novell employee ID in your .sig :-P

Re:This was an expensive ordeal...

[C0vardeAn0nim0]

not only extremely easy to configure

"LDAP" and "easy" are oxymorons.

NS directory may be easier to configure when compared to OpenLDAP, but i bet BOTH are madening when you go past the basic setup. LDAP is a sure path to the looney bin. i know. thats why i dont work with it anymore.

Re:This was an expensive ordeal...

[Anonymous Coward]

Here's what's going on:
+ Microsoft ships with ActiveDirectory
+ Solaris ships with SunOne Directory
+ SuSE Linux ships with (or will) Novell eDirectory
+ RedHat will ship with Netscape/RH Directory

So, "number one" for most people is probably going to depend highly on their choice of operating system. Obviously as the market-leading Linux, RedHat Directory will see a lot of installs out of inertia.

Re:This was an expensive ordeal...

[Nailer]

Red hat paid $20.5 million for this LDAP.

Actually, Red Hat paid 20.5 million for this implementation of LDAP. It's actually the same protocol as everyone else.

Re:This was an expensive ordeal...

[M1FCJ]

Some time ago I installed a Netscape LDAP 4 family server with about a million users, if they are still using it, it must have had even more by this time. It works folks, it works.

It wasn't that hard to set up either. (That config had a rather simplistic hierarchy).

Re:This was an expensive ordeal...

[hyc]

Sun has backpedaled on Linux so many times; if anyone still considers using SunOne on Linux today they've got to be a complete and total moron.

(Leaving aside the obvious question of using SunOne for anything at all...)

Re:This was an expensive ordeal...

[hyc]

Yet another mindless raving rated as "Insightful" - where do you guys get this stuff?

The above post is a stream of empty claims and not even a hint of factual support. How can you rate someone saying "I haven't looked at the code yet .. it is high quality from its core to its exterior" as *Insightful* ?? There is ZERO insight here.

Nobody here knows what kind of server the Netscape guys were talking about, what those 200,000 clients were doing, or what the directory data looked like. We have No Insight into what that claim means.

But you can look here http://www.symas.com/benchmark.shtml and see charts derived from documented benchmark procedures that You Yourself can repeat and verify, showing that Netscape's performance drops off FASTER than OpenLDAP's as the number of clients increases. You want INSIGHT - doing systematic tests and publishing the tests so that others can verify the results is how you get it. Not by factless gushing from a fanboy who has never seen the code in question.

Re:This was an expensive ordeal...

[opos]

But RedHat is not in Silicon Valley. In Raleigh-Durham , $20M is a lot of money. This investment is an interesting move to opening up more resources for the open source community

Re:This was an expensive ordeal...

[Kalak]

Insight is a test from 5 years ago? Not in the computer world it isn't. You want to do more than flame at someone, then make the effort to find current benchmarks. Even the page you linked to says they're old: "A previous study can be found here, comparing various Directory Service technologies, but it dates back to May 15, 2000."

Definitely overrated.

Re:This was an expensive ordeal...

[rikkards]

Actually the latest from Novell (oes) is based off of linux.
Actually just lately I have started playing with eDirectory and am impressed with it. A bit different of a mindset than Microsoft's but quite nice. I think I will come to like it more as I get more involved with it.

Re:This was an expensive ordeal...

[hyc]

Your reading skills are weak, then. That page refers to the May 2000 study merely to provide a point of reference. The results on that page are all only a couple of months old.

Re:This was an expensive ordeal...

[Kalak]

No openldap to compare it to on that page.

Re:This was an expensive ordeal...

[robfoo]

Yet another mindless raving rated as "Insightful" - where do you guys get this stuff?

Remember, this is Slashdot: News for Nerds, Moderators on Crack.

I'm holding out for a more surrealist mod system. I think "+1, Giraffe" type mods would prove just as useful as the current set, given the required state of mind of moderators.

Re:This was an expensive ordeal...

[LnxAddct]

Perhaps you should stop flaming and duplicating the same post on every comment that you don't like. Netscape Directory is a high quality product and it is known for that, and many posts in here have agreed with me. The benchmarks you linked to are not only limited in scope but also put out by the company that makes a competing product. They are no more legitimate then benchmarks put out by Microsoft on Linux's performance. In fact, you're so adament about screaming how bad Netscape Directory is that I wouldnt be surprised if you worked for Symas.

So lets see... I've talked to engineers that have dealt with the code and tested it, along with other folks who have extensively used the product, along with myself who has also setup a server and found it quite easy and you're saying my claims are baseless, yet you link to a company putting out benchmarks that are no different the Mcirosoft's Get the Facts campaign. You sir are the one with baseless claims. I can only assume that you work for Symas because their product is quite limited in funtionality and features when compared to Netscape and I see no reason why anyone would argue in favor of them other then the fact that open sourcing Netscape Directory just made Symas irrelevant as a business. If you disagree with my post, respond with something that shows otherwise, not this mindless blabbering that you responded with.
Regards,
Steve

Re:This was an expensive ordeal...

[askegg]

Not true. Novell eDirectory has been proven to scale to at least 1 billion objects in 2000. Administration involved breaking the users into 4 groups of 250,000 each and replicating them between the servers. With Novell's management tools, this is trival.

Re:This was an expensive ordeal...

[zerocool^]

Plus, after years of hotair, RedHat just became credible Windows alternative for internal applications. cheep.

I completely disagree. Take another look at redhat's cost - it's not cheap at all. Enterprise workstation costs $180, with no tech support. Red Hat Enterprise Server costs, at a *minimum*, $350, and that's without the update subscription, tech support, access to a 1-800 number, physical media, email support, and for a specific number of uses.

My take on this: If we're going to replace windows in the corporate environment, trying to copy and emulate windows, and charging as much as windows charges, is not the way to go about doing it. I mean, hell, in this scenario, we have:

1.) Redhat. Slightly cheaper than windows, but as yet unproven for things like active directory integration. Unsure whether you'll still be able to get updates in 5 years (thanks redhat 9.0). And, hell, they didn't even write 95% of the OS.

2.) Slightly more expensive. Active directory is pretty stable in 2003, and easy to configure. Based on the fact that you can still get updates for windows 95 on windowsupdates.microsoft.com, you assume that updates will be available for quite some time.

I mean, come on. I would *never* run a windows server for things like webserving, email, and most other internet-accessable applications, but for in-house policy management and integration with windows desktops - come on, I'd freaking use windows.

Don't be so blinded that you can't see the forest for the trees.

~Will

Re:This was an expensive ordeal...

[Trigun]

-1, bandicoot.

Re:This was an expensive ordeal...

[hyc]

Actually, I am a founder of Symas Corp. And I made no effort to hide that fact, you can see my associations all over my personal web site (which is linked on all of my slashdot posts) as well as the relevant Symas and other web sites.

Your comparison to Microsoft's "Get The Facts" campaign is way off base. The real point of my posting here is that you are passing anecdotes about things nobody can meaningfully assess or prove on their own.

The information I refer to on the Symas benchmarking page is provable by anybody. The OpenLDAP code can be downloaded by anybody. Anybody can download DirectoryMark and set up the same tests. We documented the hardware we used so that you can have meaningful points of reference for every data point.

Whether you think Symas has a product that's relevant to you is not my concern. I don't care a whit if you buy anything from us or not, and none of my posts said "buy our stuff!"

Re:This was an expensive ordeal...

[Donny Smith]

>Plus, after years of hotair, RedHat just became credible Windows alternative for internal applications.

Why would a directory service product make a Linux distribution company credible Windows alternative for internal apps?
And when exactly did that happen? Right after the announcement, perhaps?

>cheep.
Chimp?

Re:This was an expensive ordeal...

[SgtChaireBourne]

Plus, after years of hotair, RedHat just became credible Windows alternative for internal applications. cheep.

Assuming that the context of your statement is still directory services, on what basis to you make your implied claim that MS-Windows is a credible alternative for internal directory applications?

Its support for LDAP/OpenLDAP and Kerberos leave a lot to be desired compared to other platforms, unless you count third party options. Is there anything that can hold a candle to Novell's Directory Services (NDS) yet? Don't bark about "Active Directory" it has terrible scalibility problems, is not crossplatform and can't really do LDAP. What is left?

Re:This was an expensive ordeal...

[Anonymous Coward]

Er, no they're not. They're just words.

"easy LDAP" (taken to mean "LDAP is easy" not "easy, for LDAP") could be thought by some to be oxymoronic.

Okay, I'll go hide in the corner again...

Re:This was an expensive ordeal...

[i.r.id10t]

Unless of course you are an educational institution, a student, instructor, or otherwise in education. Then its $25 for the workstation version and $50 for the servers.

Re:This was an expensive ordeal...

[KrisWithAK]

It is true that OpenLDAP performed better in the test than Netscape across the interval from 1 client to 10 clients. But it does nothing to show the performance for 50, 100, 500, or 1000+ clients etc which would be more relevant of a test to verify other peoples' claims of the Netscape code quality.

Re:This was an expensive ordeal...

[giberti]

zerocool^ said:

Based on the fact that you can still get updates for windows 95 on windowsupdates.microsoft.com, you assume that updates will be available for quite some time.

I wouldn't count on that... It's now a 10 year old OS, I would expect Microsoft to phase this out in the next year or two like they did NT.

Re:This was an expensive ordeal...

[Random BedHead Ed]

Anyone who has ever tried to setup and configure OpenLDAP knows that its not worth it and will send you to a mental hospital fairly quickly.

Absolutely. I spent a long time fiddling with schema that seem to change between releases and running buggy scripts to get my passwd data into LDIF. And in the end I'd spent a terrible amount of time on it and it barely worked - unfortunately it crashed under heavy loads (or a single lookup from an Outlook client - no kidding). Funny thing is, I work at a mental hospital, which is where I have been setting it up. So yes, it sent me here pretty quickly. :)

Re:This was an expensive ordeal...

[dekemoose]

The point, you nitwit, was that 10 years later MS is till providing updates, whereas Red Hat is only giving its OS a 5 year life-cycle. Additionally, if you bought Windows 95 10 years ago, you would have gotten 10 years of updates, free (at least in terms of dollars). Red Hat, on the other hand, has decided that getting security updates will cost you. I'm a Linux fan, don't like the way Windows runs, don't like the business practices MS uses. However, I have some serious doubts about some of the decisions Red Hat is making. (and since freakin' when did you have to start using one of those irritating Type This Seriously Obscured Text things to comments on Slashdot?)

Re:This was an expensive ordeal...

[LnxAddct]

The guy that linked to the stats not only linked to a page of a company with a competing product (akin to Microsoft talking about Linux), but he is also the founder of the company. I'd ignore him and take anything he says with a grain of salt.
Regards,
Steve

Re:This was an expensive ordeal...

[LnxAddct]

The guy linking to the stats is not only linking to a page from a company with a competing product, but he is also the founder of the company. I'd be careful of anything he says. But yes you're right about how the tests don't accurately show how it would perform. From personal experience and talking with other people about it, Netscape Directory is clearly a very nice product and I think this guy is just scared because it's open source now, so he is spreading FUD.
Regards,
Steve

Re:This was an expensive ordeal...

[dTb]

Red Hat will provide maintenance for RHEL for 7 years after General Availability. I agree with you that Red Hat charge too much for RHEL - a less expensive version with no email or phone support would be great. As it is, there is always CENTOS.

Re:This was an expensive ordeal...

[louissypher]

> Anyone who has ever tried to setup and configure > OpenLDAP knows that its not worth it and will
> send you to a mental hospital fairly quickly.

I don't usually post on Slashdot as a good deal of the users are noobs and idiots, but I couldn't let this one slide.

Way to invalidate years of development on OpenLDAP . In my opinion, OpenLDAP is very easy to configure, and quite robust. I built an ISP with over 100k users and nearly *everything* relies on OpenLDAP (sendmail routing, classes, hashes, auth, pop3, imap, ftp, htaccess, etc) and has so for years. This is not to say that the Netscape/now Redhat offering doesn't provide anything positive. I'm just not planning on rushing out and switching because it has a nice GUI, which is what you say the benifit is. (well that and the stupid 200,000 comment).

> Back a few years ago the engineers were claiming > that one typical server running Netscape
> Directory could handle 200,000 clients.

What the hell does that mean? You obviously don't know anything about LDAP. Each instance of OpenLDAP takes over 90 hits a second. 90 hits for every one of the over 3 million emails we recieve a day. We have millions of LDAP entries. "What does 200,000 clients" mean? 200k concurrent connections? Nope, take a look at available sockets on Linux. 200k records? Please.

Re:This was an expensive ordeal...

[Anonymous Coward]

Hi, Steve. Again I see you posting nonsensical drivel on Slashdot. The degree to which you'll say ignorant things in support of RedHat, Java, and anything else that suits your fancy is truly impressive. What you're doing is indulging in a logical fallacy. They do teach elementary logic to you at that second-rate business school you go to, yes?

Re:This was an expensive ordeal...

[Rich3800]

I'm a Red Hat shareholder/Linux user and I approve this transaction. I knew before investing in Red Hat that it would not necessarily make me rich but this is just one of the ways that I am making a contribution to the open source field, apart from buying my Linux distribution, which may not necessarily be Red Hat.

Re:This was an expensive ordeal...

[Wdomburg]

1.) Redhat. Slightly cheaper than windows, but as yet unproven for things like active directory integration. Unsure whether you'll still be able to get updates in 5 years (thanks redhat 9.0).

Red Hat Enterprise and Desktop products now come with a guaranteed support cycle. The current version is set for maintainance until 2012. That is what the subscription cost is paying for.

What's ND have that OpenLDAP doesnt?

[stratjakt]

I think this is a good thing, I'm just honestly curious, having messed around with OpenLDAP, and never really doing much with ND.

What's the major differences, feature-wise not philosophy-wise (no Free vs free vs Open vs open rants).

Re:What's ND have that OpenLDAP doesnt?

[bernywork]

From TFA:

single-authentication, user-identity management and multimaster replication. Also, centralized phone book, employee locator and org-chart tool.

I would also suggest that the speed complaints that people have with OpenLDAP wouldn't be there.

Re:What's ND have that OpenLDAP doesnt?

[{X-Frog}]

I didn't really use both a lot, but I tried to set up an Open LDAP server with some modification to the default templates, it was a fucking HELL to make it works!

Netscape Directory is sooooooo but soooo easy to install, manage (with a little gui if you want), replicate. It's really important in a big environment with thousands of users and hundreds of servers that really on ldap servers! I would never do that with OpenLDAP!

Re:What's ND have that OpenLDAP doesnt?

[Temkin]

Speed, and certain enterprise features like multi-master replication if I remember correctly. It's been a while since Netscape dropped off everyone's radar, and I know they continued work on it after iPlanet broke up.

You can compare them using SLAMD. www.slamd.com

Re:What's ND have that OpenLDAP doesnt?

[Doktor Memory]

OpenLDAP is basically an LDAP toolkit. You've got your LDAP server, client libraries, command-line tools... but that's it. What you build with it is up to you, and you're starting from scratch each time pretty much.

Now, that isn't necessarily a bad thing in and of itself, but when you're trying to bootstrap a real, useful corporate directory service from scratch, it's a hell of a learning curve.

Netscape/SunONE Directory Server was less hacker-friendly, but it would take you from zero to a functioning directory in about 30 minutes, not including hiring a temp to type in all of the corporate info.

It had its quirks, and I worry about the codebase being a bit... rotted these days. But I'm happy to see it hitting OSS-land. A little competition for OpenLDAP can only improve matters.

Re:What's ND have that OpenLDAP doesnt?

[stratjakt]

You can do all that stuff in OpenLDAP, and I wasn't really aware of any speed complaints. I guess it's about as fast as the backend you use (mysql/bdb/etc)

Re:What's ND have that OpenLDAP doesnt?

[LnxAddct]

Netscape Directory is very very fast and very very easy to install and configure. After using OpenLDAP, I'm sure everyone can agree that it is not worth your sanity just to configure a program:) Netscape Directory makes this all easy, it integrates well and is highly efficient. As I said in another post, the Netscape engineers who coded this (very bright guys) claim that one mid to high end server running Netscape Directoy can handle 200,000 clients. This is a huge gain for linux in enterprise.
Regards,
Steve

Re:What's ND have that OpenLDAP doesnt?

[tweek]

The only reason Netscape is faster is because they cache the whole fucking btree in memory and operates on that. I'm not sure how often it flushes to disk though.

Re:What's ND have that OpenLDAP doesnt?

[Panoramix]

Fwiw, I did install a Netscape Directory Server on a HP-UX 11 machine, not that long ago. It was reasonably straightforward, except in that I had to install a number of OS patches and muck around with kernel parameters.

(Btw, what is it with these big proprietary apps that always want to change your kernel parameters? What on earth does Oracle need 2GB of shared memory for? And 64K file descriptors per process? That's beyond ridiculous. That sounds dangerously like extremely sloppy programming inside the product.)

But I digress. My point is that installing and configuring NDS is not hard, but nothing like "soo but soo easy" either (e.g., a far, far cry from "apt-get install slapd").

Enabling SSL is a PITA if you don't have the Netscape Certificate Server (which I didn't). I involves all manner of funky maneuvering with OpenSSL and some tools that you have to fetch from some obscure page at mozilla.org.

Management is more or less the same than with OpenLDAP, which is to say that it mostly depends on how good or bad are your LDAP client tools. In fairness, I hear the Netscape client is nice. I couldn't use it because the damn thing runs on Windows and I was not about to install that in my laptop just to see a stupid LDAP client.

Replication is probably better than OpenLDAP, though I haven't yet a chance to try it on either one.

As for big environments with many users and clients, until today I would have gone with OpenLDAP (or, if a PHB just had to see a lot of money spent in this, with Novell or Microsoft's directories). That's because nobody had source code to NDS and it was all but discontinued from the vendor. You don't want to find yourself in a position where you know there's a bug in the software, but you can't fix it and your vendor won't because they discontinued the product (and are pretty much out of business themselves, anyway).

Anyway. This is good news, certainly. Though I mostly hope there are parts and components that can be salvaged into slapd.

Re:What's ND have that OpenLDAP doesnt?

[Anonymous Coward]

And that's a problem how?

Re:What's ND have that OpenLDAP doesnt?

[ocelotbob]

I'm not an oracle dev, but I imagine that given oracle's reputation, they want the server to just work, regardless of load spikes, etc. There could be some unforseen time when you need 64k files open, like doing a massive modification to your database layout. Oracle just wants to make sure that it can do crazy things like that ahead of time, without having the system crash.

Re:What's ND have that OpenLDAP doesnt?

[kauttapiste]

Well, throwing some features off the top of my head:

* multi-master replication (up to 4 servers)
* very, VERY extensive plugin interface
* useful access logging and log file analysers
* SNMP reporting
* configuration under cn=config branch (updatable over LDAP)
* you can take backups by sending commands over LDAP

And it's fast as hell, compared to OpenLDAP.

Re:What's ND have that OpenLDAP doesnt?

[Nailer]

But I digress. My point is that installing and configuring NDS is not hard, but nothing like "soo but soo easy" either (e.g., a far, far cry from "apt-get install slapd").

Enabling SSL is a PITA if you don't have the Netscape Certificate Server (which I didn't). I involves all manner of funky maneuvering with OpenSSL and some tools that you have to fetch from some obscure page at mozilla.org.

It sounds like most of your problems were to do with install and configuration. The install will consist of:

up2date redhat-directory

I'd be surprised if the configuration wasn't either a GTK2 app called 'system-config-directory' or a web based tool (to get an idea of the quality of a Red Hat web based config tool, check out Red Hat Network Satellite).

Re:What's ND have that OpenLDAP doesnt?

[Anonymous Coward]

Actually, my experience of NDS was that OpenLDAP vastly outperforms NDS, and is a million more times stable. I've run Stanford's Directory service for over 5 years, part of that time on NDS, part of it on OpenLDAP, and I can't see any scenario that would make me switch back to NDS. It is a horribly broken piece of software that would be better off being put out of its misery.

See:
http://www.stanford.edu/services/directory /openlda p/history/index.html>

Re:What's ND have that OpenLDAP doesnt?

[hyc]

re: multi-master - like the SprintPCS guy said a few posts over - prone to failure and database corruption, utterly useless in an enterprise deployment.

re: plugin interface - OpenLDAP supports both the (incredibly inefficient) Netscape plugin interface and its own (incredibly fast) plugin architecture.

re: logging - "useful" is a subjective term. Since you don't explain what this means, it's difficult to comment further on it.

re: SNMP reporting - you're right, this is lacking in OpenLDAP, and for IT purchasers going down the checklist of "must haves" this can be a problem. The NetSNMP package is an easy solution here, especially with all of the information provided by OpenLDAP's cn=monitor. I know of several commercial OpenLDAP deployments where this was an issue at first, but integrating NetSNMP allowed the OpenLDAP deployment to proceed.

re: cn=config - This is implemented in OpenLDAP 2.3. And it doesn't require a server restart to make new plugin settings and other changes take effect, unlike Netscape/SunOne.

re: backups via LDAP-initiated commands - this topic actually came up on the openldap-devel mailing list recently. The conclusion was that it was a band-aid Netscape needed for their lame replication mechanism.

re: fast as hell - OpenLDAP 2.1 beats Netscape into the dirt. OpenLDAP 2.2 is even faster, and scales to large numbers of clients even better. If you still believe Netscape is faster than OpenLDAP, you haven't used a recent release of OpenLDAP.

Re:What's ND have that OpenLDAP doesnt?

[hyc]

In what way is the above post "Informative" ??

All it consists of are subjective claims ("very very fast") with no facts or any points of reference. That is not "information" that is "groundless opinion."

Show us the "Netscape Directoy" server that can handle 200,000 clients, and show us the operation mix, database size, representative data, network topology, and server configurations. *That* would be "Informative."

*THIS* is informative: http://www.symas.com/benchmark.shtml

Those are real facts that anybody can replicate using their own hardware.

What you're spewing is just noise, not information.

Re:What's ND have that OpenLDAP doesnt?

[netsrek]

exactly.

I'm seeing a lot of uninformed crap here.

Setting up ANY directory service is complicated. It has to be, or you're not designing it properly I reckon.

OpenLDAP is not difficult to manage or install. It may have shitty command line syntax, but anyone doing anything repetitive can easily script around that.

Re:What's ND have that OpenLDAP doesnt?

[krady]

Try setting up a proper security architecture for it using SASL and/or TLS to support samba and pam SSO.

I know LDAP very well and have worked with many different servers but trying to find the exactly correct version of openldap to support properly secured passwords for samba manager and root in the DIB was a nightmare. I eventually gave up and had to go back to the security requirements phase to get around it.

As for hoping to train up the less experienced admins on the system, I was pretty sure that would never be possible.

Re:What's ND have that OpenLDAP doesnt?

[hyc]

Been there, done that. At least 5 years ago the first time, and many times since then. Perhaps if you had asked for help you would not have had such a hard time with it. That *is* one of the benefits of working in an open source community after all.

Re:What's ND have that OpenLDAP doesnt?

[netsrek]

doing that now...

Sure, it's complicated, but it's not freakin' quantum mechanics or like trying to outsmart Saul Kripke or something.

Yeah, the OpenLDAP documentation sucks. Get a good book.

Or maybe just get Mac OS X Server. SSO out of the box with OpenLDAP and Samba...

Re:What's ND have that OpenLDAP doesnt?

[Ih8sG8s]

Speaking to the installation portion of it...

I have never installed this piece of software on any platform, but I can tell you some things about HP/UX:

Stock kernels, or kernels configured for a specific purpose are either vanilla and useless for most things (vanilla instlled kernel), or highly specialized (post configuration omptimized to suit a specific purpose or application).

Just about any enterprise level application that you install on HP/UX will require patches and kernel tweaks.

That's just the way it is, and one small of the many reasons that I find HP/UX a horrid system.

Re:What's ND have that OpenLDAP doesnt?

[illumin8]

re: multi-master - like the SprintPCS guy said a few posts over - prone to failure and database corruption, utterly useless in an enterprise deployment.

What the hell is with you OpenLDAP fans that want to spread baseless claims about Netscape Directory? In the real world, Fortune 500 CEOs do NOT trust some long-haired GNU/Hippy with deploying their 1+ million entry DIT on some homemade OpenLDAP framework. They want a supported and trustworthy enterprise product.

Name me one company that is using OpenLDAP with over a million entries. Just one. Can't do it? I could name over 20 that are using NDS or Sun's version of NDS with over a million. Not only that, if you went through the fortune 500, you'd probably find that at least half of them use these products.

Re:What's ND have that OpenLDAP doesnt?

[DG]

Yeesh....

I ran a major Netscape Directory server installation at a major US automaker. As far as I know, it's still running there. Started at 3.0, and was on 5.x when I left.

Netscape's internal replication did indeed suck for a while, where the biggest failure was the inability to emancipate a slave directory and make it a master if the master puked.

I got around that through the brilliantly elegant feature that Netscape had the OpenLDAP did not - the replication ChangeLog was availible via LDAP. I actually wrote a program called replicator.pl - that's right, in PERL! - that handled all our replication and made multi-master happen. Later on, when we bought this upstart young German automaker, that program did real-time replication with real-time schema translation between their directory inrastructure and ours.

An early version of that program is availible online - it was GPLed - and I have the code for the most up-to-date version if anybody wants it.

Later on, the internal Netscape->Netscape replication got solid enough to the point where it could be relied on, and replicator.pl was phased out except for where schema translation was required.

As for the plugin interface, we actually wound up using this. I'm not going to say what for... but it had to do with the way a certain bit of very important information from the mainframe systems got tied into the directory. We had a "oh shit!" moment, I dove into the plugin documentation, and less than an hour later we had a working solution that solved the problem COLD. Saved our collective asses. You might think it horrible, but it solved the problem.

And as far as speed goes, Netscape handled everything we threw at it. Where eDirectory would just give up and cry, Netscape would go blasting through serving data. It was an awesome bit of work. The Java console sucked, but the server itself was awesome, and Netscape's support was pretty good.

Now I wanted to try OpenLDAP, but the configuration and installation was a PITA, it didn't support Netscape's ACL syntax, nor would it support ACL updates over LDAP, the replication changelog wasn't availible over LDAP, and whenever I breached these subjects on the OpenLDAP lists, all I ever got was aggressive and nasty grief. People tellling me how what I wanted OpenLDAP to do was stupid.

Whatever. Good on RedHat. I fully expect those speed improvements will migrate into Netscape's server (God Bless the GPL!) and then the world will have speed, ease of use, and hopefully, a more polite developer base all rolled into one place.

DG

Re:What's ND have that OpenLDAP doesnt?

[Skjellifetti]

It's not just HP/UX. I've had similar experiences with patch requirements for many other unix vendors and enterprise software. I worked for a small workflow tools vendor at one point where a genius salesman told a potential customer "sure our tools run on Solaris with the Iona Orbix ORB" even though no one had ever tried that combo. Took me a weekend just to patch the solaris box to meet the Iona requirements but only 20 minutes to compile our tools.

One thing I did notice about HP/UX was that many kernel config params that can be changed on Linux by a simple echo 1 > /proc/sys/some/param/or/other required a kernel re-link and reboot or something similar on HP/UX. This made it a real pain to do simple things like uping the max amount of memory that a user's process could have.

Re:What's ND have that OpenLDAP doesnt?

[Ih8sG8s]

Yup, I agree there. I just happen have the shittiness of HP/UX on the brain right now.

I just completed building a 9000 K class on 10.20, with all of the GNU tools, the HP ANSIC kit, the developer's toolkit, etc.

Try getting a bare metal HP/UX 10.20 box running with a somwhat current GNU development environment on it for c++, (userland) threaded apps. Sheer hell.

From a user perspective

[Dancin_Santa]

How does this improve my user experience?

How can using ND make my life, as a user/administrator/purveyor of exotic animals, easier?

I think that is a useful question to ask any time a "new" feature is presented.

Re:From a user perspective

[0racle]

Ever used the Active directory on Windows? I mean a properly created one in a larger organization. Had to search for an email address of someone in another branch or division? Ever had to log into another machine on that network? Search for printers on another floor?

Well, you can actually do that and more with any LDAP server.

Re:From a user perspective

[ImaLamer]

Welcome to the world of "Directory Services". They will help you locate resources on the network. As an administrator, enabling or restricting access to resources has now become a lot easier.

Sarcasm aside: It's all about options. Another directory services project/product/option is always a good thing. However, I still want to see Novell return to its former glory. It's a sad day when people are relying on Active Directory, using it as a REAL directory services solution.

But back to the point, it's good to see another option. And it's good to see that RedHat is putting their power behind it.

Re:From a user perspective

[Hatta]

Also, why does this matter since the Mozilla Directory is already open?

Re:From a user perspective

[askegg]

By storing all the items you administer (users, workstations, applications, printers, files, phones, handhelds, etc) you can build a a directory that can store and describe the relationships between everything. True policy based management.

Re:From a user perspective

[caferace]

RTFA. You're comparing apples and orangutans.

Re:From a user perspective

[Anonymous Coward]

Well, I laughed.

Re:From a user perspective

[Anonymous Coward]

Is possible to create security templates on this ldap!? is possible to restrict the use of the floppy drive or any other device, directory, printer, or specific setting of a program by using the ldap directory so no matter were the user logs on, he has the same restrictios and file access permitions?

Comparison

[rsax]

I know this story is going to prompt people wanting to know how the Netscape directory server compares with OpenLDAP. I've never used the Netscape one but what I would really love to know is how does it stack up against Novell eDirectory? eDirectory isn't open source but the licenses are damn cheap, the first 250,000 licenses are free. Any LDAP experts care to share their opinions?

Re:Comparison

[Kartoch]

To add a bit of complexity in this question, I heard that guys from Samba are developping their own LDAP because they are not satisfied with OpenLDAP. Does anyone has more informations/opinions about it ?

Re:Comparison

[deviator]

I have to say that while I've not worked with ND, Novell eDirectory (formerly NDS) is a technically brilliant tour de force. It's a really amazing package; multimaster replication; multimaster schema changes; extremely efficient over slow links, unbelieveably secure (and has some really sophisicated extensible authentication systems), works on every platform under the sun, the APIs & developer tools are extremely mature, scales like crazy and runs super-fast, and like the previous poster said, it's CHEAP.

Anything else, to me, is a weak imitation--but I guess as long as your directory speaks LDAP all is well. Unless it's Active Directory--which is really just a set of "nested" domains with automated trust relationships. And that part makes it a huge pain in the ass to maintain. (The trick to this is to throw an AD domain into eDirectory and have eDirectory manage the whole thing - it is so flexible it can manage _other directories._)

NDS has always "just worked" - move, rename & merge tasks are super-easy. How does ND handle all of this?

Re:Comparison

[ScytheBlade1]

It does indeed look like that they're building their own LDAP server. I'd have to search the mailing lists for reasons as to why, but if it's the same quality as their current products, it won't be a let down.

Re:Comparison

[Anonymous Coward]

The earlier question of why Red Hat would do this is answered...The Novell eDirectory is a signficant competitor...It's unlikely that Red Hat would want it to become the de facto LDAP.

Re:Comparison

[Anonymous Coward]

This http://www.novell.com/products/edirectory/pricing. html says that the price is $2.00 per monkey.

Where are my 250,000 free licenses?!

Re:Comparison

[wild_berry]

Where Novell sell complete, supported solutions making use of eDirectory, SuSE et al, Red Hat can now supply a GPL-compliant solution of their own. This may help Red Hat make money in the cases where the use of White Box and other GPL-clones of RHEL provide an entry to Red Hat support contracts.

Re:Comparison

[alistair]

I have used both and run both in production at a major corporation.

In many ways eDirectory is far more sophisticated. It is more close to a true X500 directory and it has some very sophisticated tools for data replication and management. The admin console is streets ahead of the old Netscape Java Console for starters and the APIs are very well developed. It is very easy do do operations such as prune and graft on the Novell Directory than on the typical standalone LDAP directories (Open LDAP, SUN ONE) where you have to essentially delete and recreate the entry rather than just modify the base DN.

One key differentiator is replication strategy. eDirectory and Microsoft AD are genuine multi-master directories, you can configure them to accept updates anywhere and the data then replicates among the cloud of replicated servers. Open LDAP and Netscape's LDAP are have pyramid structure replication, you update a master, it updates slaves and these can update further consumer servers. This approach can have some advantages if you want to secure updates and be able to take a consistent snapshot of your data at a particular point in time.

Speed is also an issue. I feel that SUN ONE is currently the leader in raw search speed, Netscape produced a very fast server on the same database backend and a suspect Novell is a little slower as it is more feature rich. You will probably only notice this if you are making in excess of 20 searches per second to your box.

So I would advise people to check out eDirectory. Novell have a great history of making some superb product which they then do their upmost to keep secret from paying consumers. If it is free it could well meet most of your needs, especially as the console makes it very easy to set up and populate with sample entries.

Re:Comparison

[bigman921]

Based on the code it jsut looks like they want to expose the data in samba via an ldap interface. it's actually quite interesting as this would let you expose NT4 environments via ldap pretty quickly. Anyone from samba have any details?

Re:Comparison

[michaelhood]

The "why" is simple. With recent (past few years) advancements in SAMBA, the addition of their own LDAP server would allow them to completely replace domain controllers on Windows-client networks - allowing Linux to replace Windows Server.

Re:Comparison

[rsax]

Where are my 250,000 free licenses?!

Right here.

On a some what related note, Novell open sourced YaST, Hula and a bunch of other software after they acquired SUSE. I guess to show that they want to be on the open source bandwagon. It would be interesting to see if they will open source eDirectory to match Red Hat's move. Especially since the licenses are either free or so uber cheap.

Re:Comparison

[hyc]

Thanks for an interesting read. My impression of Novell eDirectory mostly agrees with yours. A couple of points, not to detract from your excellent post:
OpenLDAP 2.2 back-hdb supports subtree renames. The lack of this feature has been an obvious, longstanding deficiency but that was corrected over a year ago.
Replication strategy - I think this may be an irreconcilable religious issue. I don't believe a feature that allows unresolvable update conflicts is suitable for use, others are willing to live with it because the possibility for problems to arise is usually low.

Re:Comparison

[msh104]

I also read that there is also going to be an openldap option... but perhaps just not in the first release.

Re:Comparison

[ian13550]

Wow -- you should not talk about Sun ONE because you obviously don't know what you are talking about. What version of Sun ONE did you use? 4.x from 1999? You information is not correct at all and badly outdated.

As of iPlanet 5.1 (before re-branding) you could do 2 way multi-master replication (with schema replication, etc etc etc) and with Sun ONE 5.2 (post-rebranding) you can do true attribute-based multi-master replication.

eDirectory has a MAJOR fault where the thread processing a BIND attempt goes to sleep for 3sec to prevent brute force password attacks. In a high traffic environment, 3sec is a damn eternity. Oh yeah, the morons at Novell decided that this is hardcoded into the product and cannnot be disabled

AD is a total joke. Don't even talk about using it in a *real* production environment. Most of the shit is badly documented and is not used by serious retail consumer sites.

You are 100% correct that the eDir replication robustness is the best in the business. If you are serious about a true multi-datecenter environment that is replicated in real-time over a WAN -- eDir is great. Also, the eDir admin console is light years ahead as well -- but who the hell ever uses the GUI to admin a production Directory server??? Sun ONE has EVERY command available via the command line -- and some that the GUI can't even comprehend.

For pure read speed -- not many products can touch Sun ONE when properly tuned (allidthreshold, indexes, etc).

Re:Comparison

[alistair]

Hmmm, don't know what I am talking about, 7 years running a team of 8 people implementing a global LDAP service for a Fortune 500 Company, beta tester for SUN ONE versions 5.1 and 5.2 (including being the only person to submit a P1 bug on the 5.2 version) speaker at the RSA Conference Europe on Identity Management in 2003 and accepted for 2005, sorry if I need to dig out my cluestick.

With eDirectory and AD, you can update any server and each server then replicated globally. Each have their own mechanism for reconciling conflicts as changes move across the cloud, each with their own drawbacks (although Novell's is more customisable IMHO). However, in theory, you can have 1000 servers all accepting updates.

When Innosoft launched their DS 5 as was, they took the lead with what they called either failover or standby master. This is the code that SUN bought to build DS 5, and also because they didn't have Smith and Howes who were their lead architects on the iPlanet Directory and gained Mark Wahl, who I think still works for them.

With DS 5.1 and 5.2 you still have failover or standby masters, with 5.2 you can have 4. SUN rebranded these as Multi Master in response to marketing critisism from MS and Novell. However, it is not true multi-master in the sense of eDirectory or AD, most installations use one master for writes and the 2nd/3rd/4th as failovers. There is a two phase commit between masters before updates are sent to hubs and consumers with NO conflict resolution, which you abolutly need if you are running multi master over slow WAN links or the link between masters breaks while both masters are up and you need to reconcile them when the network link returns.

Everything else you write is 100% correct, for all my production environments I use SUN ONE 5.2 SP3 and I think they are the fastest on the planet, serving over 1000 searches per second on very cheap Linux hardware (lots of indexes and allids at arount 20% of entry size).

Consoles do suck but people have to lean somewhere, we have written a Web based interface to SSH to command line that manages our global SUN ONE servers but people have to start somewhere and Novell's is much better than SUN ONE.

Re:Comparison

[ear1grey]

The development of this server was overseen by several of the original authors of the LDAP RFC's including Howes, Smith and Good.

These guys had a fair amount of experience of the problem that was under investigation, so the engineering team had cogent technical leadership (and as I recall, the engineers themselves were fairly black-belt when it came to coding ability and dedication to the cause).

Additionally, this server is several generations old with significant input from large corporate customers whose almost always demanded 100% availability as their number one priority (and speed as number two).

There are all kinds of things that this release version won't be able to do because it's development has no doubt slowed of late (multi-mastering? management of ephemeral session data? etc?); but what it can do, thanks to the GPL, is provide a fantastic reference implementation for other projects such as OpenLDAP and Samba, and perhaps even a useful set of binaries in it's own right.

Re:Comparison

[hey]

Yes, Samba is good but it has taken decades to get that way! Any I wouldn't say that it "just works" either. You need to configure the ~300 line /etc/smb.conf file.

Re:Comparison

[Anonymous Coward]

Do you have a link that supports this 250,000 license thing you're talking about? Looking at the page, I see a buy now link, which is pretty cheap, but not free. Am I missing something?

Re:Comparison

[widderslainte]

What about system requirements:

One of the following:
* SUSE LINUX Enterprise Server 9 (IR3 required)
* SUSE LINUX Enterprise Server 8
* RH Linux 7.3, 8.0, 9.0, or RH Adv Server 2.1

Can this be run on regular Suse 9.X? Anyone tried?

Re:Comparison

[Anonymous Coward]

How many of those lines are comments and commented out options? You can have an extremely short smb.conf and it will still work fine!

Re:Comparison

[ScytheBlade1]

True, it took it's time to get there, but now that they know what they're doing, I'm not too worried either.

A ~300 line smb.conf file? Maybe if you leave all of the comments in it...or if you have quite a bit of shares...

This was an expensive ordeal...MS Flashback.

[Anonymous Coward]

"Goodness, that is a lot of money."

Remember this next time someone compares Redhat to Microsoft.

Thanks! Another question

[Dancin_Santa]

This is probably a stupid, domain-specific question.

I was recently trying to embed my JRun eServer through an SMB pipe to an NNTP share running on a remote VNC server without having to use the required intranet JVM. Would it be possible to attempt to lower my TCO using ND by utilizing the Active Directory installations in one division of the company while retaining administrator rights on the Linux network at the co-loc's Apache web server?

Money isn't a big issue, but keeping costs down is better than paying out the nose, naturally.

Netscape Directory ...

[kabz]

Is this some kind of BitTorrent search engine ?

Re:Thanks! Another question

[Anonymous Coward]

How will this help us liberate copyrighted music and movies? If not, you've got the wrong site.

Re:Thanks! Another question

[Anonymous Coward]

BOHICA.

ODP [dmoz.org]?

[tepples]

I thought it was Open Directory Project.

This has huge potential

[EvilStein]

I've used OpenLDAP and Netscape Directory Server. NDS is a *very very very* cool product. It's easy to use, scales like there's no tomorrow (it was the backend for a lot of the older Netscape Netcenter sign on functions) and it's nice & documented. (I still have books for it)

Red Hat releasing it under the GPL is a good thing, any way that you look at it. Cool product, "big name company" supporting it, and oodles of applications that can already use many of its functions.

Now, if someone would slurp up Netscape Calendaring Server and release *that* under the GPL..
If the Netscape SuiteSpot Server suite still existed and was under the GPL, there's your Exchange-killer right there.

Re:This has huge potential

[Anonymous Coward]

Netscape Calendar Server has already been slurped up. It's now called Oracle Corporate Time.

Re:This has huge potential

[IGnatius T Foobar]

Now, if someone would slurp up Netscape Calendaring Server and release *that* under the GPL.. If the Netscape SuiteSpot Server suite still existed and was under the GPL, there's your Exchange-killer right there.

Perhaps you might consider combining the now-open Netscape Directory and combining it with something like Citadel which can do mail, calendars, and a bunch of other things, and is designed to plug into an external LDAP directory.

That would give Exchange a run for its money, except for the same problem that plagues all non-Microsoft servers: people still want to use Outlook. Hopefully the next generation of upcoming open source client products will change that, though.

Re:Thanks! Another question

[stratjakt]

That all depends.

Can you provide me with an internet connection that is compatable with my token ring ethernet configuration?

Now if only it had Hula's calendaring and email

[gnatware]

Can RH possibly integrate the http://hula-project.org/ into this roll out? I would really like to have THE non-M$ directory/email/calendaring system running for my school district: single sign-on and email accounts for teachers, staff, students, parents... with Mac OS X Server directory delegation, Kerberos, etc.

A killer kombination for Open Source.

Re:Now if only it had Hula's calendaring and email

[Anonymous Coward]

Almost, but OS X is not open source, and Apple's policy of promoting software patents in Europe forces me to avoid their software at all costs.

Re:Now if only it had Hula's calendaring and email

[Moulinneuf]

OS X is not Open Source "yet" , I have been saying for years that we should takem out before they become a nuisance. Whas made into a waco for that comment.

Guess what : Apple Mac OS X is actually replacing GNU/Linux in some area now :

http://www.macworld.com/news/2005/05/24/maclinux/i ndex.php?lsrc=mwrss

Re:Now if only it had Hula's calendaring and email

[Anonymous Coward]

Hula project is funded by Novell.http://hula-project.org/General_FAQ#Relatio nship_with_Novell Don't think that Novell will ever support Netscape Directory when they have a better (eDirectory) alternative. Integration with Openldap might be a possibility. Netscape...doubtful

Re:Now if only it had Hula's calendaring and email

[10Ghz]

Guess what : Apple Mac OS X is actually replacing GNU/Linux in some area now :

And Linux is replacing Apple somewhere else. So what's your point? OS X replaced Linux in some university? Run for the hills! The world is coming to an end!

Re:Now if only it had Hula's calendaring and email

[Moulinneuf]

You ever played russian roulette with a fully loaded barrel , really you should try it , it would solve the natural evolution who's going to kill you for something obvious that you whont get but will get killed by it anyway , this way it just save time.

Gnu/Linux ( thats the name of the OS BTW ) replacing Apple = Good thing.

Gnu/Linux beeing replaced by Mac OS X = Bad thing

I hope its really clear for you this time.

Apple MAc OS X is actually some great code but which is proprietary and not Open Source.

Still following ?

Since its great code and its closed and Apple is a nuisance , then you take out the nuisance and change it into Open Source and Free software.

This way the good code that apply can be used to boost GNU/Linux in some area where Apple Mac OS X as the advantage.

Get it now ? No ? dont worry its too intelligent and visionary for you , go back to making dumb ass comments , it whont save your life, but you will get modded as insighful , even when your comment is tottaly clueless.

So to resume the point Apple MAc OS X , proprietary and closed source = BAD

Apple Mac OS X , bought and changed to Open Source , GPL and free software = Good

You must be an Etats-Unians you run for the Hills when your Gov say WMD and terrorist , in a war you would be the one shooting your ally in the back I guess , keeping up with your own country traditions.

I would hate to see what you would do in a case where GNU/Linux gets replaced by windows.

Re:Now if only it had Hula's calendaring and email

[Anonymous Coward]

Gnu/Linux ( thats the name of the OS BTW ) replacing Apple = Good thing.

Gnu/Linux beeing replaced by Mac OS X = Bad thing

Ah.. an open source zealot.

Actually, as a Unix professional I find Linux to be amateurish bullshit. It is currently being replaced in my environment by Solaris 10 and OpenBSD.

As far as desktops go, comparing Linux to OS X is like comparing a Hyundai to an Acura. Both get you there, but at the end of the day the Acura is more comfortable and at the end of 100k miles the Acura still works.

Apple MAc OS X is actually some great code but which is proprietary and not Open Source.

Still following ?

Nobody cares.. are YOU following? The only people who care are open source fanboys. We even gave Redhat AS a shot in production. It didn't make the cut.

You must be an Etats-Unians you run for the Hills when your Gov say WMD and terrorist , in a war you would be the one shooting your ally in the back I guess , keeping up with your own country traditions.

You must be one of those disgruntled emasculated Western European types who enjoys capitulating to the demands of Islam. As far as allies go, we haven't any.. and I like it like that.

I just can't wait till we resume nuke testing over here.. we need enough for all of you.

Re:Now if only it had Hula's calendaring and email

[Anonymous Coward]

Gnu/Linux ( thats the name of the OS BTW )

No, the name of the OS is either Linux, or Mozilla/[KDE|XFCE|Blackbox|SomeOtherDE]/[X.org|XFr ee86]/GNU/Linux. If you're going to be an annoying pedantic asshat, you may as well go all the way, otherwise you're just a hypocrite.

Here's a clue for you: "GNU/Linux" (as in Linux with GNU tools) *CAN'T* replace OSX, because "GNU/Linux" *HAS NO GUI*.

Re:Now if only it had Hula's calendaring and email

[Moulinneuf]

"an open source zealot."

Zealot are a good thing ;-)

"as a Unix professional "

Such a thing as never existed ...

" I find Linux to be amateurish bullshit"

Its Gnu/Linux and thats why all so called Unix are replaced by it.

"It is currently being replaced in my environment by Solaris 10 and OpenBSD."

Yes when your the sole administrator of 2 box you have complete control over what is used.

"comparing Linux to OS X is like comparing a Hyundai to an Acura. "

Comparing an OS to a simple kernel ... I have to agree on that one.

"the Acura is more comfortable and at the end of 100k miles the Acura still works."

Yes , just like GNU/Linux.

"Nobody cares.. are YOU following?"

No , because everyone that mathers care , your just really irrelevant ;-)

"The only people who care are open source fanboys."

You mean everyone right ? ;-)

"We even gave Redhat AS a shot in production. It didn't make the cut."

No because the problem would be the administrator who are incompetents fool ...

Nope , Real American here , I am A Canadian , Unlike the whannabe "of America" , where it :

C ourageous
A mericans
N oble
A mericans
D efender of
A mericas

we fought every legal War from start to finish we aint coward like the US.

"I just can't wait till we resume nuke testing over here.. we need enough for all of you."

I guess we know who as WMD and who needs to be first striked , nah wil wait when you pull out of irak and have recalled all your troops this way you cant claim it whas unfair like usual.

Re:Now if only it had Hula's calendaring and email

[Moulinneuf]

"No"

Yes ,very few people know this but the Linux kernel is actually dual licensed at version 1.0 , some license and the GPL.

So its GNU/Linux because of that and alos because its GPL.

"Mozilla/[KDE|XFCE|Blackbox|SomeOtherDE]/[X.org| XF r ee86]/GNU/Linux. "

No because Morons like you dont get to decide anything, you should know by now ;-)

""GNU/Linux" *HAS NO GUI*."

Oh no we have no GUI according to the foremost expert : Anonymous Coward ...

Quick lets hide the fact that we pay the GNOME and KDE developpers.

Here is a clue for you : YOU have no clue

Re:Now if only it had Hula's calendaring and email

[Anonymous Coward]

So its GNU/Linux because of that and alos because its GPL.

What the fuck are you talking about? Just because it's licensed under the GPL *DOES NOT* make it "GNU", fucktard. Try reading RSF's writings on this, you stupid fanboi.

lets hide the fact that we pay the GNOME and KDE developpers

*BZZT* Wrong!

Gnome and KDE are desktop environments - they *RUN ON TOP* of the GUI.

Lest you doubt - delete your X binaries, and see how useful they are.

So.. what else you got, moron?

Re:Now if only it had Hula's calendaring and email

[Moulinneuf]

"What the fuck are you talking about?"

Gnu/Linux , you cant understand ;-)

"Just because it's licensed under the GPL *DOES NOT* make it "GNU","

It would be one more reason ;-)

"Try reading RSF's writings on this, you stupid fanboi."

Try to learn to read yourself ;-)

"*BZZT* Wrong!"

You think sound effect is going to chenge reality ? its not ;-)

"Gnome and KDE are desktop environments"

No , but then would have been weird to see you get it right ;-)

"they *RUN ON TOP* of the GUI."

GUI is general user interface ;-)

"Lest you doubt - delete your X binaries, and see how useful they are."

I have not doubt your truley are clueless ;-)

"So.. what else you got,"

everything ;-) , you should try it.

"moron?"

Yes I got you as a pet ;-)

Netscape Directory **IS** OpenLDAP

[ramam]

Aren't both of these largely Tim Howes work from UMich?

Re:Netscape Directory **IS** OpenLDAP

[hyc]

Not since 1999-2000. The overall shape is still similar but the internal details have all been reimplemented by the OpenLDAP Project. Today OpenLDAP is miles ahead of Netscape in terms of performance, scalability, and stability.

See for yourself:

http://www.stanford.edu/services/directory/openlda p/history/index.html

OpenLDAP 2.0 is slow, snail's pace, frozen molasses slow. That's the release that RedHat has bundled for years, up to RH9 and even beyond. It's only in the past few months that anything from them (Fedora Core) has shipped anything newer.

OpenLDAP 2.1 is over Two Hundred Times faster than OpenLDAP 2.0 and already significantly faster than Netscape 5. OpenLDAP 2.2 is 30-50% faster than OpenLDAP 2.1 and leaves Netscape in the dust. OpenLDAP 2.3 is faster yet.

Re:Netscape Directory **IS** OpenLDAP

[whoisshe]

OpenLDAP 2.1 is over Two Hundred Times faster than OpenLDAP 2.0 and already significantly faster than Netscape 5. OpenLDAP 2.2 is 30-50% faster than OpenLDAP 2.1 and leaves Netscape in the dust. OpenLDAP 2.3 is faster yet.

and that is completely irrelevant *if you can't get the software installed and configured without slitting your wrists*.

Re:Netscape Directory **IS** OpenLDAP

[ramam]

I've setup multiple Netscape and OpenLDAP systems, neither in the last year. They're both LDAP systems so you have to make decisions WRT your requirements. If you are a unixy type they behave the way you would want and come with robust command line tools that make it relatively easy to migrate data from other systems . If you are expecting a solid UI that covers everything look elsewhere - I'm not sure it exists but it ain't these guys last time I checked.

Is this an answer to Palladium?

[Anonymous Coward]

Does the user authentication they talk about in tfa do the important parts of what Palladium was supposed to do? Everyone was VERY upset about Palladium and rightly so. It would have removed our control of our own computers.

It sounds to me as if this would make Palladium unnecessary. Or, as often happens, have I missed something?

Enterprise Solutions

[kjs3]

This isn't particularly big news for the SMB market, but for the enterprise market, this is a huge open source win. Quality, scalable, enterprise capable LDAP solutions are a hot topic in all of the Fortune 500 sized companies that I deal with, and ND has a track record of being able to play ball there.

Now if they would only open source Netscape calendaring...

Re:Enterprise Solutions

[lactose99]

Now if they would only open source Netscape calendaring...

Did RedHat get rights to Netscape Calendar? I thought that was all sold to Steltor as Steltor CorporateTime before it all got gobbled-up by Oracle and became Oracle Collaboration Suite's Oracle Calendar. The only reason I know this is because my company was a legacy Steltor CorporateTime customer and we recently completed an upgrade to Oracle Calendar as support was about to expire on the Steltor product.

If Netscape Calenedar was open-sourced, perhaps I could better-understand the proprietary database backend used with it.

Re:Enterprise Solutions

[kjs3]

Ah...you are of course correct. My bad, Netscape undoubtedly doesn't have rights.

Well...

[Craig Ringer]

You can do distributed authentication, mail routing, etc with LDAP, yes. Building most of the features of AD would involve lots of custom hacking though - for example, to do software auto-installs on log-in.

There's a lot more writing of custom schema and swearing with LDAP than there is with AD, and a LOT less good documentation, but once it works it stays working, unlike AD ;-)

Re:Well...

[SparklingClearWit]

Building most of the features of AD would involve lots of custom hacking though - for example, to do software auto-installs on log-in.

Wrong. Blatant FUD, or pure ignorance.

Look up Group Policy, Intellimirror, and Published Applications under Active Directory. If I say you can have Microsoft Word, you'll get it on *any* domain computer you sit at. If it's not already installed, it will be installed the first time you run it. I can distribute service packs, etc., to different departments or computers using Group Policy. Shit, I can install the entire OS using Remote Installation Services with a PXE-capable computer, if you'd like.

but once it works it stays working, unlike AD ;-)

Again, pure shit. If you plan and deploy it poorly, you'll have a mess. If you do it right, on proper hardware, it will run for years with no problems whatsoever. Delegated authority of OUs, users with specific rights (you can change/reset passwords, but can't add/remove users; YOU can add printers, etc.). The whole Linux crowd crows "RTFM!" unless it's about Microsoft. Jesus, take the time to understand your enemy before just running your mouth.

Re:Well...

[Craig Ringer]

Er ... my point was that lots of custom hacking would be required to do with LDAP on *NIX the things that come BUILT IN in AD. I thought it was pretty darn obvious, actually.

My whole point is that you don't get anything even remotely like Group Policy under any *nix LDAP authentication scheme I'm aware of unless you do a lot of custom hacking.

AD is pretty awesome, and I'd really LIKE most of the power it offers on other platforms. As far as I'm concerned that's the biggest thing the Windows platform has going for it. That, and it's documented ;-)

As for AD problems ... what you say is probably true. On the other hand, even quite large organizations often seem to fail to deploy it correctly. A national manufacturing outfit in Australia was bought down for a while because one of their branch offices lost its connection to the WAN, their AD secondary master promoted its self to primary, then the WAN was restored and everything went *splat*. Avoidable? Probably. Need an AD black-magic wizard? Definitely. What's needed is documented somewhere? Without a doubt ... but good luck finding it and understanding it then applying it correctly. The AD admins I've spoken to have all expressed the view that AD is great, but just too damn hard to configure robustly and that it tends to be fragile if not configured exactly right.

I would ask you to, next time, take the time to ACTUALLY READ MY MESSAGE before flaming me out too much, OK? You've been just as bad as the people you're complaining about.

Re:Well...

[pangloss]

R E A D I N G, it's fundamental. Try your own dog food: take the time to understand "before just running your mouth".

Re:Well...

[SparklingClearWit]

I did go back and re-read it. And I read it backwards, as you say.

I will say it loud here:

I am a tool for flaming Craig Ringer, since I agree with him, but apparently I can't fucking read and comprehend.

That said, on the described situation - yuck. That's definitely weird. You usually have to either transfer (the nice way) or seize (the not-nice way) the FSMO roles, unless you've gone past the 90-day tombstone border; then you're doing a Directory Services Restore mode and some lovely ADSI Edit action. (Bleah)

You're right about some things - you can easily muck shit up, like you say. MS makes it very easy to *install* Active Directory - do a DC Promo, and you're done! Oops, you borked it, and you've got 500+ clients on the domain? Uh oh... time for some UGLY regedits and ADSIEdits.

;0

Thanks for catching me on my stupidity.

Re:Well...

[SparklingClearWit]

And if you read my reply, I did apologize as I completely flipped his meaning.

Re:Well...

[pangloss]

that was a damn good & honest apology =)

tip 'o the hat to you.

This has huge 'killer' potential

[Anonymous Coward]

"Now, if someone would slurp up Netscape Calendaring Server and release *that* under the GPL..
If the Netscape SuiteSpot Server suite still existed and was under the GPL, there's your Exchange-killer right there."

If it wasn't an "exchange-killer" before? What makes you think open-sourcing it is going to change that?

Re:This has huge 'killer' potential

[EvilStein]

It *was* an Exchange killer before. The SuiteSpot server stuff predates modern Microsoft Exchange. Back in those days, Exchange was only around 5.x and lacked a *lot* of features. Exchange Server 2003 has matured and added POP/IMAP and many other features that the SuiteSpot server packages had way back when.

Things are a lot different than they were back then... even 5 years ago.

Re:This has huge 'killer' potential

[Anonymous Coward]

Exchange "killer" is a bit of an overstatement -- featurewise they were about the same -- in fact relying on IMAP can be considered a downside in a corporte environment.

The big downside to the product is that you had to use Netscape 4 client, and the calendaring was kinda clunky. That killed when my company did a comparison with Exchange.

Re:This has huge 'killer' potential

[rikkards]

Pop was there back in Exchange 5.5 but I believe you had to install the proper connector. By default with Exch 2003 it is disabled by default. But I do agree 2003 is a much better product than 5.5 just in security plus integration with AD as well.

OpenLDAP is not hard to configure.

[Some Random Username]

My first ever experience with LDAP was with openldap, and it took 10 minutes to configure, and then maybe an hour to work out how I wanted my schema, and write an ldif of it to import. Unless it used to be significantly different than it is now, I can't see any way anyone could think its hard to configure.

Re:OpenLDAP is not hard to configure.

[msh104]

It get's harder when you try to secure it with sasl/gssapi. but I agree. openldap isn't THAT hard for a simple setup. don't know how well it scales though...

Sun Directory Server vs. Netscape Directory Server

[mrbill]

Isn't Sun's Directory Server based off this as well? I thought they'd acquired all the old Netscape stuff back in the Netscape/iPlanet days.

Where are they now?

[fce2]

Where are the other bits of software that once was Netscape Suitespot?

Netscape Calendar was not actually developed by Netscape, but was a version of CS&T's CorporateTime system. CS&T later renamed to Steltor, and is now part of Oracle, CorporateTime forming a large part of their colloboration suite.

Both Netscape and Sun got copies of everything when iPlanet split. Sun still develops and sells them, first as Sun ONE, now as Java Enterprise System. Netscape tried to keep development going for a while, but it kind of stagnated (much in the same way that the Netscape browser stopped moving after the AOL aquisition).

Redhat also got Certificate Server and Enteprise Server (the web server) as part of their deal, see http://www.redhat.com/software/rha/netscape/ for more.

So where is the other Netscape software? I'm mostly talking about Messaging Server, which is an awesome piece of software, and Collabra Server, which .. isn't. Presumably they're still kicking around in a CVS in the depths of AOL somewhere. Anybody else know anything?

Re:Where are they now?

[diegocgteleline.es]

So where is the other Netscape software?

It has took them 8 months to GPL it. I guess they've focused more in the netscape directory.

Re:Where are they now?

[Temkin]

So where is the other Netscape software? I'm mostly talking about Messaging Server, which is an awesome piece of software

Sun still sells JES Messaging Server, which is a blend of NMS and Sun's old SIMS. There's still a Linux port. It runs some of the larger ISP mail systems on the planet, competing with OpenWave's Email Mx.

I'm not sure who got ahold of Netscape's rights after iPlanet. The old NMS message store has it's roots in CMU's Cyrus IMAP. The last versions of the iPlanet server used Sun's MTA (formerly PMDF), which can pretty much claim the crown for speed/features.

Re:Where are they now?

[fce2]

Correct. iPlanet MS (the 5.x series) used the NMS message store and IMAP/POP/HTTP servers (which, as you say, were once Cyrus IMAP), and included PMDF as the MTA (I believe iPlanet bought InnoSoft to get it).

After iPlanet split, we got NMS 6.0 and Sun ONE MS 6.0. ONE became JES, which is doing some hairy integration stuff with Sun's calendar, directory and web server (we're still on iMS 5.2 where I work, and its getting harder and harder to upgrade).

As far as I know, there's nothing of SIMS in iMS/ONE MS/JES MS (thank goodness - it was the pits).

What I'm wondering, is where is Netscape's version of the code? My interest in it is purely selfish - if I had it I could fix the issues we currently have with iMS, and I could stop implementing really awful workarounds and/or rewriting parts of the MTA to do my bidding.

Re:Where are they now?

[Temkin]

As far as I know, there's nothing of SIMS in iMS/ONE MS/JES MS (thank goodness - it was the pits).

SIMS had PMDF back in 97. The Innosoft aquisition came years later. Are you referring to SIMS 1 & 2? SIMS 3.x & 4 were pretty good unless you mismanaged the message store. Then you were at the headwaters of this certain creek...

What I'm wondering, is where is Netscape's version of the code?

As far as I know, it's not public. I'm pretty sure RedHat did not aquire it with DS.

My interest in it is purely selfish - if I had it I could fix the issues we currently have with iMS, and I could stop implementing really awful workarounds and/or rewriting parts of the MTA to do my bidding.

Do tell... Are you on HP-UX or W2K? Why haven't you moved to 6.x?

Proper replication

[Nailer]

Asides from Multi master replication (OPenLDAP onyl allows a single master), Netscape directory server solves the 'OpenLDAP being fucking retarded, and holding ACLs to objects in the directory OUTSIDE the directory, therefore replicating objects before their access controls' issue.

LDAP is lightweight

[Sufood]

It's all very well and good to have a lightweight directory system as part of your operating system. However, if Red Hat wants it's identity management system to be more than a lightweight, it should consider asking Netscape to implement more features of the X.500 Directory standard.

The problem with LDAP is that adding the 'L' (lightweight) to the 'DAP' (directory access protocol) removed many features including, most noticably, proper distribution of data over multiple servers and proper chaining of requests.

Proper distribution and request chaining protools would allow Linux systems and MS systems to share a perceived common user data store. At the moment, hybrid enterprises are forced to support multiple islands of trust in the organization. It also sets the operational limits of the system to an enterprise/employee rather than a global/customer scale solution.

Still, it's a good thing that Red Hat is implementing a directory based identity management solution. It's a step in the right direction.

Re:LDAP is lightweight

[WindBourne]

LDAP has been able to do distribution over multiple servers for some time. The L in LDAP modifies the protocol, not the server software.

As to directory based ID management, Linux (including Redhat) has had it for eons. You have always had your choice of using kerberos or LDAP or NIS or whatever you like. In fact, I have done some set-ups ~4 years ago where we used LDAP for the ID. It Worked fine.

Re:LDAP is lightweight

[Anonymous Coward]

It's all very well and good to have a lightweight directory system as part of your operating system. However, if Red Hat wants it's identity management system to be more than a lightweight, it should consider asking Netscape to implement more features of the X.500 Directory standard.

Of course they should, given the widespread industry adoption of X.500. They should also probably convert over all of the networking to X.25.

Re:LDAP is lightweight

[Anonymous Coward]

The funny thing is that if you look at an MS Exchange 5.5 installation, it does come with X.500, X.400, X.25 and other useless OSI support.

Re:LDAP is lightweight

[Nailer]

The problem with LDAP is that adding the 'L' (lightweight) to the 'DAP' (directory access protocol) removed many features including, most noticably, proper distribution of data over multiple servers and proper chaining of requests.

The reason the university of Michigan created a standalone LDAP server was because 96 or 98% of their requests (I can't remember what the number was exactly) were coming through their LDAP to DAP gateway.

LDAP removed many features including, most noticably, proper distribution of data over multiple servers...It also sets the operational limits of the system to an enterprise/employee rather than a global/customer scale solution.

How is LDAP directory partitioning improper? Subsection of the directory can live on localized sites. Does what I want. Works enough to fit, say, France inside an LDAP dir (France, by the way,. is larger than a single enterprise - it's a country, in Europe - sorry, but there's lots of Americans on this web site). What am I missing?

Proper distribution and request chaining protools would allow Linux systems and MS systems to share a perceived common user data store

Like what I can do now with pam_ldap authenticating against AD, making it a common store for Linux and Windows (even though pam_krb5 is a better way of doing things)?

Or what I can do with PGINA on Windows, or the Novell GINA, against any directory server / NDS?

I don't dispute that DAP may do things that LDAP can't. But you haven't definied what you mean by 'proper distribution of data' means, you're just saying LDAP doesn't do something the way you want. Linux and Windows and OS X and Solaris can share LDAP servers. There are massive global LDAP directories that work very well. More detail, please.

Re:LDAP is lightweight

[Nailer]

Also, DAP uses the OSI protocols, including ASN.1. Are you sure that's what you want?

Re:LDAP is lightweight

[hyc]

LDAP uses ASN.1 as well, as it must. And while DAP was defined in the context of OSI protocols, it is not inseparably tied to them. Many companies have released good DAP over TCP implementations.

Re:LDAP is lightweight

[hyc]

The previous poster is right on. Data distribution in LDAP is a hack, accomplished using the poorly specified concept of "referrals" that was added as an afterthought to LDAPv2 and is still underspecified today in LDAPv3.

By throwing out all of the design intelligence that went into the X.500 DSP protocol, defining how server-to-server communication works, the LDAP folks have set themselves back another decade and are still struggling to define the controls and extensions to provide the distribution features that are needed (and were already provided, in real X.500).

All the LDAP servers that implement chaining for management of data distribution have to use proprietary techniques because the LDAP standard is so weak it doesn't provide any meaningful guidance here.

Re:LDAP is lightweight

[Nailer]

LDAP uses ASN.1 as well, as it must.

Really? Can you point to the RFC section where it says ASN1 is mandatory?

Do you think most DAP over TCP implementions are more or less stable than LDAP implementations?

Re:LDAP is lightweight

[hyc]

Perhaps English is not your first language. Otherwise, it would seem to be self-evident.

http://www.ietf.org/rfc/rfc2251.txt?number=2251

Section 4 "Elements of Protocol" (page 9)

4. Elements of Protocol

The LDAP protocol is described using Abstract Syntax Notation 1
(ASN.1) [3], and is typically transferred using a subset of ASN.1
Basic Encoding Rules [11].

Re:LDAP is lightweight

[alistair]

Agreed, "referrals" are a hack, as were "alises" which appeared and then were dropped from the Netscape and SUN series of servers.

However, you have to accept that this is an issue of hourses for courses. I run a global network of LDAP servers which processes tens of millions of queries per day across a corporation. 95% of our queries want to know what cost center a users is, what the phone numbers for people called "alistair" are or are used for password or token authentication.

Referrals aren't an issue here, we just replicate all the people data worldwide. Integration with clients is, we integrate with PERL, JAVE, MS Excel and a huge range of third party vendor apps and this is hard enough with a very simple protocol like LDAP, we simply couldn't support these apps if we had to access the data with a heavyweight API.

WRT LDAP servers implementing chaining, if this is proprietary, so what. LDAP is an access protocol, once I have access the interface on a data source my client shouldn't care if I hold the data locally, read from an alternate server or pull it from a completely different data source as long it is returned in a format consistant with the LDAP protocol. Techniques for bridging between databases, eDirectory, MS AD and standalone LDAP Directories are well understood, I don't see a major issue here.

Re:LDAP is lightweight

[hyc]

I don't see a major issue here

That's OK for you to say, because you've already considered the factors that are important to your individual use case. But LDAP is intended to fit a multitude of use cases and for the protocol designers to take this stand is grossly irresponsible.

You blithely say that "Techniques for bridging between databases" are well understood, but you don't notice that they only work when the entire system and all connections work well. When any component fails or misbehaves, the behavior of the entire system goes into a randomizer. The fact is that in any complex network, the probability is 100% that some component will be failing or misbehaving for a non-trivial amount of the system's operational life. Without paying careful attention to these details, the design will collapse in the face of those outages.

The fact that the LDAP working groups are still struggling with these distribution issues today is a testament to my point - the original LDAP guys didn't do their homework, and now that LDAP has crept in all around the network, the rest of the world is paying the price.

Re:LDAP is lightweight

[Nailer]

What exactly is it about the referrals currently used in multiple-million object LDAP servers you dislike?

Referals work. Server to Server works. They're in production. Now. There are almost no DAP servers. LDAP was invented because DAP was bloated. It suceeded in the marketplace. DAP did not.

Again - tell me, specifically, what's wrong. Don't tell me it's 'not proper' or 'underspecced'that doesn't mean anything. Burden of proof is on you - I'm happy with LDAP, so is the rest of the world, so I can't be bothered reading the OSI DAP RFC. You do it. Prove me wrong.

Re:LDAP is lightweight

[hyc]

I've already proved you wrong once, haven't you had enough yet?

"Referrals work." Only in a fantasy world where security and authentication are unimportant, and where firewalls don't exist.

The fact that there are still people submitting drafts to the LDAPEXT Working Group to define controls and extensions for real distributed operation is proof that the rest of the world is not as happy as you are with LDAP's server to server capabilities today. If you can't see that, it's no burden to me.

Re:LDAP is lightweight

[Nailer]

I didn't doubt you, I just wanted you do do the work. I was wrong: LDAP does indeed use a subset of ASN 1. Point is, it's not a full implementation - this is often touted as one of LDAP's advantages - and I don't see anyone complaining about it except from 2 guys on Slashdot.

From your RFC:

The protocol elements of LDAP are encoded for exchange using the
Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
high overhead involved in using certain elements of the BER, the
following additional restrictions are placed on BER-encodings of LDAP
protocol elements:

(1) Only the definite form of length encoding will be used.

(2) OCTET STRING values will be encoded in the primitive form only.

(3) If the value of a BOOLEAN type is true, the encoding MUST have
its contents octets set to hex "FF".


Now, as I was asking earlier: since DAP is older than LDAP, and LDAP was invented because DAP wasn't being used, and since LDAP has been used to implement larger directories than DAP ever has, and since global directories are possible and dare I say only mature on LDAP (ironically fulfilling ITUT's dream of a global directory), why is DAP better?

Re:LDAP is lightweight

[alistair]

Hmmm, an interesting discussion.

I still disagree, the key points for me is that LDAP is Lightweight and provides Access to data. I think the designers of the protocols have done an excellent job in designing a protocol which is lightweight and can be extended through supported controls; we use about two of these but I know other LDAP developer who use far more and have even written their own to extend the protocol.

What I don't think LDAP is ever good for is replicating between servers, it is an awful protocol for this and the attempts by commercial servers to use changelogs and persistant LDAP serches to monitior the changelog crude and unreliable.

But I don't think that is what LDAP should be used for. Client to server should be LDAP, data holding server to data holding server should be whatever works best for those servers.

I know some years ago there was some work on LDUP, a distribution and update protocol for LDAP servers, but that stalled and maybe that is what you are referring to. However, we are now moving into middleware. If we have an efficient replication protocol for sychronising databases why limit it to LDAP, why can't we bring in AD, Oracle and the rest, that would be a far bigger win which would benefit more of our users.

But none of this is a critisism of LDAP as an access protocol, it is the fault of all vendors, open source and commercial, who provide distributed data stores.

There is nothing to stop people who require rock solid guarenteed replication from using X500, many major vendors offer these servers and almost all of them offer LDAP interfaces. Or use Oracle or Sybase which both offer LDAP interfaces.

But please, lets not criple LDAP's simplicity and speed by extending it to do everything. With the possible exception of DNS, a well configured and indexed LDAP server is the fastest indexed data retrieval server you can install, full stop.

I will agree, referrals are broken but n exactly the same way as HTTP redirects are broken, the web has found ways around that and your LDAP environment can too.

Re:LDAP is lightweight

[alistair]

I run some half million object LDAP servers and have the following issues with referrals.

i) ACL Management is inconsitent. e.g.

A client connects to server A. They bind and that establishes the branches and attributes they are allowed to access. They search and receive a referral to server B. They then connect to this server. However, the credentials are not always passed correctly for that server resulting in some unconsisency in the data to be returned. This seems to vary by server vendor but more specifically by the API being used to access the servers, what may work in NET::LDAP in PERL may produce different results in JNDI or ADSI.

ii) Referrals use hard coded server names. When our clients access our LDAP servers we always give them a list of 3 servers (or LDAP Proxies) mapped to DNS aliases which they should access, as no one server or proxy can be available 100% of the time but in 5 years of running the service we have never had 3 servers out at any one time.

However, if a referral server fails, that is what clients are accessing. You then have to change every server reference in the referral entries or change DNS which can take time to propagate. Maybe you can have multi valued attributes in your referral fields but not all clients and APIs will implement this.

iii) Referrals can behave differently at different points in the tree.

If you have a entire tree branch and you ise a referral to move it to another server this can work well.

However, if you have, say, 100,000 people entries and then a referral to another 100,000 on a different server, different clients work differently. Some will read the first 100K entries and then the next on the second server. owever, I have found a number will follow the referral first. This also causes issues with ACL parsing.

The above usssues are real world exaples from trying to integrate over 300 applications with the Netscape / iPlanet / SUN ONE series of Directory servers over a 5 year period, so your milage may vary. However, I think referrals should have been better specified or could do with refinement.

Does that go some way to meeting your burden of proof? (don't get me wrong, I like them, I just feel they could do with some refinement).

Re:LDAP is lightweight

[Nailer]

Sorry, that LDAP uses a portion of ASN 1 does not prove that DAP (which lost in the marketplace) is better than LDAP (which is being used now, and works).

Referals work fine on every LDAP server I've set up. Hashes are sent through SSL encrypted pipes, LDAP glue works, it ain't hacky,m it works between LDAP directories.

Prove your point.
* Saying 'security and authentication' are mysteriously bad doesn't do it.
* That people are still submitting things to the LDAP working group proves nothing either. People are still submitting things to the http working group. Does that mean it is inferior to its predecessors?

The last major thing that even happened to DAP was slapd.

You're right, I can't see it. And you can't show it to me, otherwise you would have.

Wasting your time promoting DAP without any detailed technical evidence is indeed a burden on your time. Why bother?

Personally I think you just like showing off that you knew LDAP was descended from OSI DAP, and didn't mean to get caught up in this conversation.

Re:LDAP is lightweight

[Nailer]

Does that go some way to meeting your burden of proof? (don't get me wrong, I like them, I just feel they could do with some refinement).

It certainly does - but like you, I'm more inclined to think that the LDAP RFC needs to be expanded to cover areas outside the spec rather than wholesale replaced with OSI DAP, as the original poster was suggesting. Think of LDAP like ipsec in the early days, or SANs right now - a good technology at the point where it's so useful everybody wants to interoperate with it, which tends to show up areas the original spec is lacking.

Thanks for your post.

Re:LDAP is lightweight

[Sufood]

I don't dispute that DAP may do things that LDAP can't. But you haven't definied what you mean by 'proper distribution of data' means, you're just saying LDAP doesn't do something the way you want. Linux and Windows and OS X and Solaris can share LDAP servers. There are massive global LDAP directories that work very well. More detail, please.

Thanks for the reply. I think there is a degree of confusion here between X.500 distribution and LDAP referrals. A referral system forces the work back onto the client and therefore does not support proper server side distribution. I believe there are performance issues in this approach that do not lend LDAP only servers well to certain performance sensitive applications.

I can see this descending into a rather long debate so here is a good link that I think fairly explains the differences between X.500 and LDAP.

http://tinyurl.com/7829u

I've only used OpenLDAP, AD and Open Directory (now Computer Associate's eTrust Directory) so I'm willing to be corrected on the exact features of Netscape's directory.

To my knowledge there are only 3 X.500 directories on the market, none of which are free or open source. :-(

• Isode Directory (http://www.isode.com/)
• Siemens DirXServer (http://www.siemens.ie/fixedoperators/CarrierNetwo rks/Meta/meta_range.htm)
• eTrust Directory (http://www3.ca.com/Solutions/Product.asp?ID=160)

By the way, don't get me wrong, I'm delighted that someone has GPL'd Netscape directory. Together with a nice free Java based LDAP browser client...

http://pegacat.com/jxplorer/

I think it gives Red Hat a huge boost.

Re:LDAP is lightweight

[Sufood]

Now, as I was asking earlier: since DAP is older than LDAP, and LDAP was invented because DAP wasn't being used, and since LDAP has been used to implement larger directories than DAP ever has, and since global directories are possible and dare I say only mature on LDAP (ironically fulfilling ITUT's dream of a global directory), why is DAP better?

DAP server side implementations do not limit themselves to DAP only clients. The X.500 directory I've used the most supports LDAPv3 clients equally as well as DAP clients. DAP servers also implement DSP and DISP communication protocols for proper distribution as mentioned earlier.

Now while DAP is clearly older, it doesn't mean that technology built around it has been standing still. For instance most X.500 directories communicate over TCP/IP rather than at the OSI level as I think a previous poster correctly mentioned.

Anyway, I think we are arguing at cross purposes, We're probably the only three people still reading this thread and one thing is for certain, we all think Directories (whatever their flavor) are pretty cool. It's been nice arguing with you all. :-)

Re:LDAP is lightweight

[hyc]

Personally I think you just like showing off that you knew LDAP was descended from OSI DAP, and didn't mean to get caught up in this conversation.


Actually, I distinctly remember waking up this morning and thinking to myself "ah, what a nice day. I hope I can get into an argument about LDAP with someone on slashdot, that would be just perfect." Must've been the full moon last night.

Re:LDAP is lightweight

[hyc]

I would never advocate replacing LDAP with DAP, that wouldn't solve anything anyway. My point is that LDAP is only a client to server access protocol, but people thought they could use it for everything and forget about the problems that DSP and DISP were designed to solve. People are trying to do distribution now with LDAP, and beating their heads against the walls.

As a simple example - in X.500, two servers (A and B) that trust each other can establish a DSP session between themselves. If an authenticated client request comes in to server A but data is needed from server B to satisfy the request, the server A can securely chain the request on behalf of the client without any fuss.

In LDAP, if the same situation arises, a couple of things can happen:
server A can return a referral to the client. The referral mechanism doesn't address how to handle security in a referral though. Possibly the two servers support a disjoint set of authentication mechanisms. Possibly one server requires TLS and the other doesn't; that information isn't encoded in the referal. Possibly the referred server is behind a firewall that the client can't cross. There are any number of problems here that will prevent the client from successfully concluding the request. In the absence of any policy information (and where does that come from?) the client may have no choice but to chase the referral using a plaintext Simple Bind. The referral might point to a rogue server, which will then take the client's credentials and feed that info to who knows where.

There's another possibility, for a server that implements chaining via LDAP: in this case you might be able to create the same kind of trusted inter-server session that DSP allows. But since LDAP doesn't have server-to-server support built in, that session needs to be established by means of Controls and Extended Requests. One of the big problems here is that the LDAP standard cannot distinguish between client-server and server-server communication. Any client could legitimately use the same Controls that are intended to facilitate server-server communication; when server A receives a request decorated in this manner, there's no clear way for the server to determine how to progress the request. For example, the Proxy Authorization control, which essentially allows one to say "I'm identity A but please perform this operation with the privileges of identity B." This capability is a key requirement for secure server to server chaining, but if a client issues a request with Proxy Authorization attached, the correct behavior for the server is ambiguous.

What do you know, it ain't dead yet...

[sillypixie]

I feel happy about this.

I feel that this may be karmic retribution for Sun railroading us into having to use ^$@#%$&ing pkgadd, instead of those lovely tarball installs of yore, where it all installed into a single directory that I could tar up, or simply blow away if it screwed up... ah, the days of control...

But then, in the short term, the only way that I can see Netscape Directory Server making it into the enterprises that I deal with daily are if it comes bundled or as a dependency for some very well-trusted and established open source app, like maybe a CMS or something such as Bugzilla, or SVN. As an "Enterprise Directory" (ooh aah) it will be a long time before this version could compete, if ever -- everybody wants a stack, these days.

Still, it could be interesting leverage for the big Sun clients who are actually paying for the SJS Directory Server. I think this is the final stage of the commoditization of the animal that is a directory server... damn, I owe a certain Burton Group analyst a beer now...

(-:

Pixie

Re:What do you know, it ain't dead yet...

[Temkin]

I feel that this may be karmic retribution for Sun railroading us into having to use ^$@#%$&ing pkgadd, instead of those lovely tarball installs of yore, where it all installed into a single directory that I could tar up, or simply blow away if it screwed up... ah, the days of control...

Oh excuses... excuses... You could still do this, you just need to know how to hack the package DB as well. Packages make field support much easier, and following standards for disk layout, seperating data and binaries, makes managing backups much simpler.

Re:What do you know, it ain't dead yet...

[sillypixie]

Heh, you must not work with middleware much. Packages work really well for things that can never occur on a machine more than once.

Now that the DS is a package, it means that I can only have a single o=NetscapeRoot tree. So, I can create a test instance and a pre-prod instance and a bunch of other instances, but every instance writes configuration data to the same o=NetscapeRoot. So if something goes terribly wrong, firstly there is the possibility of a single instance rendering all LDAP instances unusable, and secondly, it is next-to-impossible to manually remove every trace of a single instance, because you have to hack the configuration tree as well.

Before this, you could simply install two separate stand-alone versions of the directory server, running on different ports, and know that the two were completely uninvolved with each other. There is a huge value to that.

Of course, Solaris 10 is going to improve things considerably. Instead of multiple standalone directory servers running on the same box, I'll be able to run multiple virtual servers on the same box, each running their own single DS package...

Re:What do you know, it ain't dead yet...

[Temkin]

Heh, you must not work with middleware much.

Actually... I QA middleware all day long.

Packages work really well for things that can never occur on a machine more than once.

Not true. You just apparently don't know how.

Before this, you could simply install two separate stand-alone versions of the directory server, running on different ports, and know that the two were completely uninvolved with each other. There is a huge value to that.

You can still do this with packages. It's a requirement for clustered services, take a looking in the docs for installation instructions on a cluster. Specificly, you need the "-R" flag or "-a" with a custom pkg admin file.

Re:What do you know, it ain't dead yet...

[sillypixie]

Sigh,

You are right. It can be done, which basically means that I'm whining about *how* it gets done...

I guess I'm just a fan of keeping it simple. Which gives me the bias that you mentioned.

Thanks for keeping me honest (-:

Pixie

Open LDAP

[a3217055]

Open LDAP was hard for me to set up, I finally joined forces with an old sysdamin. Even with her old ways she finally managed to convert NIS over to LDAP and promote it to Linux, Windows, Mac OSX and SGI. I about the time she got the SGI's working said, " So long Alice.." and ran west ward on the continental us. LDAP was a nightmare it, it was really nightmarish for the ADD young sys admins. I know at a company that I was looking into was using a verison of LDAP for the whole company's email, security to log into computers, smb mounted drives. LDAP is good if you know how to set it up but it must have an age filter. But I never have used Netscape Directory but I have heard about it from my NYC buds who say it kicks ass and you get big booty with it. :)

Weird /. error

[Anonymous Coward]

From the /. right side nav/ad bar:

Apache
· Your Headline Reader Has Been Banned
· You May Only Load Headlines Every 30 Minutes
· In 72 Hours, Your Ban Will Be Lifted
· Do Not Bother Contacting Us For 72 Hours

WTF? They have been banned from their own RSS feed?

Yeah

[Anonymous Coward]

eeee

Re:Thanks! Another question

[Anonymous Coward]

Answer my question, Mr. "Santa":

Have you stopped FUCKING your children IN THE EAR?

Software WANTS to be free

[Anonymous Coward]

Redhat just lets it

"this is huge at least from my point of view"

[Anonymous Coward]

Well, back off RedHat's knob a bit and it won't engulf your vision.

Even Tommy Lee is an ant when viewed from space.

how much this will cost M$, and Novell

[kokoko1]

I know how hard is to configure openldap I'm just excited after reading nice comments from people who had use ND. Redhat really got a better heart then M$ and other "greedy" parties over there. I just want to know does GPLed ND will cost M$ (AD) and other concern parties in short and long term. Do you people thinks migration from AD base setups to ND (when it beacome avaiable under GPL) would be beneficial? Regards

Re: Calendar server too?

[catellie]

Someone DID slurp up Netscape Calendaring Server in a manner of speaking: It was just a rebrand of what was then call CSTime, which after a few name/owner iterations is now owned by Oracle and part of ther collaboraton suite. I agree, it DOES really rock.

Re: Calendar server too?

[EvilStein]

Kind of. From what I heard, the codebase is a little different..

Steltor (CorporateTime) became Oracle Calendar. That's also a cool product. :)

Also in the calendaring realm is MeetingMaker. :)

Re: Calendar server too?

[catellie]

Emphasis on little - the clients appear to work fine with each other, so I'd say the difference is primarily in the branding. The old NS (4.x) browser integrated client is the only significat part I can not find these days (hardly surprising).

We used SUN/One for SprintPCS and....... it sucked

[dlippolt]

In the development and staging environments it was great. As other posters mentioned you could get from zero to something usable in less than 30 minutes. Everything was as you would expect.

However... in the -production- environment, with 10's of millions of ldap objects connected to SprintPCS's provisioning systems which were making 1,000+ ldap writes --a minute-- the SunOne system absolutely blew chunks.

LDAP architects will ask what the hell we were doing with the entire database in one ldap instance rather than partition the dataset, and they'd be right, but we were acting under Sun's direction since at the time we had one of (if not) the largest LDAPs in the world.

LDAP architects would also wonder why on earth you would ask an ldap server to live under such a write intensive churn, and they'd be right again.

That being said...

-- Multimaster replication would never ever work. Most of the time the entire SprintPCS userbase was hanging off one master and less than 4 replication slaves. For several months the entire messaging system was wedged into a single point of failure nightmare. (to be fair, this wasn't all slapd's fault and had 1/2 of the root cause in Sprint Datacenter practices which produced predictable results)

-- Other posters asked for SunOne Calendar server to be opensourced. My first response is to suggest you have your head examined since that thing would die for absolutely no reason on a regular basis. We actually automated the process of detecting its death and restoring from last night's backup. If you were a SprintPCS customer and your calendar ever seemed screwy now you know why. Of course further reflection suggested opensourcing it is probably the only thing that could help at this point because...

-- We used to get hotfix builds from Sun which were missing entire sections of the binaries. Whoever was managing the code would forget to use the same compilation flags for hotfixes as original code so we would receive webmail frontend builds which couldn't talk to imap backends, or calendar backends which wouldn't accept connections from calendar front ends.

-- SOL if you wanted to run more than 4G of memory in slapd.

Dont consider this post a rant, just let any CIO's/etc. reading this know that this opensource release will probably work great for you if you dont load it heavily (unlike exchange 5x, which would grenade just sitting there)

On the other hand, if you want to push the performance envelope, pretty much expect it to take alot of time and cause a bunch of headaches -in production-. Get help from people who have pushed the performance of the tools you are considering running.

Weird mood tonight.

BFD...the IBM LDAP Server has *always* been free

[The Last Gunslinger]

Why is this even newsworthy?

IBM has licensed its enterprise-class LDAP directory server software free of charge for over 5 years now.

Yep, free. Go to ibm.com and download it for yourself. Anyone. For any purpose.

http://www-306.ibm.com/software/tivoli/products/di rectory-server/

It's currently under the Tivoli brand, going as the IBM Tivoli Directory Server v6.0.

Not only does it pack all the bells and whistles of other enterprise LDAP directories, such as multimaster and cascaded replication models, but instead of flat files it *includes* IBM DB2 UDB enterprise edition database (also licensed free of charge) for its data storage. I've seen the comparative test results, and nothing touches this solution for performance and scalability.

It runs on just about anything, too...including Linux on non-x86 hardware.

And they've always GIVEN it away. Free download.

So, someone explain again WHY any company of any size would PAY for an LDAP solution, or why RedHat giving away Netscape Directory is big news?

I'm sure OpenLDAP 17 will be faster still

[Gopal.V]

Not intending to troll, the factor for most enterprise consumers are in this order -

• stability
• scalability
• security
• single box performance

I'd really want to wait until someone says OpenLDAP 2.1 is secure and stable before I push it onto a box.

Re:I'm sure OpenLDAP 17 will be faster still

[hyc]

Your points are all right on. If you actually read the link in the previous post, you would see that Netscape failed on all of those measures, while OpenLDAP excelled. The Netscape servers would crash at least twice a week and their databases went corrupt more often than that. The OpenLDAP servers never crashed and never corrupted the database. And that was all in a Kerberos-enabled environment - security features in OpenLDAP are second to none.

Re:I'm sure OpenLDAP 17 will be faster still

[DG]

I ran the Corporate Directory for a major US automaker for a number of years.

We used Netscape's Directory Server. There were hundreds of apps pointing at it, and the main Internet proxy server used it as the authentication service.

Over a million objects, hundreds of thousands of searches per day. It might crash once or twice per year, and never corrupted anything.

The management GUI sucked, but it was an outstanding product in all other respects.

DG

Re:I'm sure OpenLDAP 17 will be faster still

[ramam]

I've setup and deployed multi-million entry Netscape LDAP server systems that never go down. At somepoint I hit a file system size limit (Solaris at the time) and used DB plug-in to work around.

SUN ONE not quite direct descendent.

[alistair]

This isn't 100% correct. SUN ONE is a merge of the Netscape Code base with the Innosoft Code base they aquired in around 2001. Both Netscape and Innosoft developed their own directory servers based around the Open LDAP reference installation. What made Innosoft more advanced was its capability for several masters (it's not true multi - master in the sense of eDirectory from Novell or Active directory but that is no bad thing).

SUN aquired the Netscape Code in partnership with AOL and also bought Innosoft. SUNs Directory 4.x servers are the Netscape code, 5.x are Innosoft.

Having said that I have happily tested both servers with 4 million entries on a fairly small box and run 500K entries in production. We managed uptimes of in excess of a year on some of our 4.x servers running over a million queries a day, not so bad.

Re:SUN ONE not quite direct descendent.

[illumin8]

What made Innosoft more advanced was its capability for several masters (it's not true multi - master in the sense of eDirectory from Novell or Active directory but that is no bad thing).

You are somewhat misinformed. Sun's latest incarnation of the Sun Java System Directory Server (that's what they're calling it now), fully supports 4-way multi-master replication. It even supports it over WAN and slower links by queueing changes up and transferring them in batches, rather than one at a time.

Re:SUN ONE not quite direct descendent.

[alistair]

Agreed, but this is still not true multi master in the sense of good X500 implementations or eDirectory.

What happens when you have an update to the same entry on 2 masters which are not in sync? In Novell's eDirectory (IMHO the best implementation yet of multi master) the conflict resolution is at attribute level and you can specify a range of rules to say which update application or server wins in the event of conflict. You can even look at audit logs of these events.

With SUN ONE it generally uses 2 phase committ. So you (as an application) update master 1. It then tries to update the other masters. Once this is complete it then return a success code to the LDAP client. I don't know how this works over the WAN (my impression of the WAN functionality was that it is for HUBS and Consumers, I have never tried it for masters).

Either way, you still have a pyramid structure of masters and consumers unless you have four or fewer servers in which case they can all be masters. With something like eDirectory or AD almost every server is a writable master rather than hub or consumer, which I what I would understand to be true multi-master. I prefer this as you can capture the data from a master at any one point and know this a true view of that data, with the eDirectory model you can have updates propagating through the system at all times and no one server can know the full state of the data because some updates may be hours away. This can be especially useful in environments like Finance where audit may want a guarenteed snapshot of your data at midnight on a particular day and this is very easy with the clasic SUN model.

Re:SUN ONE not quite direct descendent.

[illumin8]

With something like eDirectory or AD almost every server is a writable master rather than hub or consumer, which I what I would understand to be true multi-master.

Ahh.. I see the difference now. Thanks for the explanation. I had no idea that Novell's eDirectory was so capable. If Sun's wasn't free for under 200,000 entries, we would probably switch.

Re:BFD...the IBM LDAP Server has *always* been fre

[AaronLawrence]

Can you point me to the download link? All I could find was "Buy Now" which lead me to a price list saying US$10,000.

Re:BFD...the IBM LDAP Server has *always* been fre

[sceptre1067]

At the bottom of the page is the download link. It does appear to go to a "free" evaluation/beta copy.

I didn't download it though, so I don't know what the exact terms of use are.

The fact that there is a "Buy Now" would suggest that the eval copy is for testing but not production. Just a guess though.

Re:BFD...the IBM LDAP Server has *always* been fre

[maxwell demon]

IBM has licensed its enterprise-class LDAP directory server software free of charge for over 5 years now.

Even if that is true, that's still different from releasing as Open Source.

Not Fast

[Anonymous Coward]

We used Netscape LDAP server on British Telecom's Talk21 (www.talk21.com) which I think had 2 million accounts and around 2,000 simultaneous sessions when I used to develop it.

Netscape LDAP was not fast enough in this environment and seemed overly complicated to use - it seemed to me that an RDBMS would make more sense for many application and it was just that BT was a big OSI player so it was being used for political reasons.

Re:Not Fast

[Anonymous Coward]

Netscape LDAP was not fast enough in this environment and seemed overly complicated to use - it seemed to me that an RDBMS would make more sense...

So what was the environment? How many replica servers were there? What were the DS's used for (just message routing or other stuff too)? What were the read rates? What were the write rates? To just say "it wasn't fast enough and seemed overly complicated" sounds like you hadn't learned about the tool that you were using to solve the problem, rather than the tool being at fault.

Re:Cheep

[Anonymous Coward]

Cheep cheep cheep.
I here the sound of chickens hatching....

Re:Cheep

[Anonymous Coward]

Doh!
(pun not intended.....)

small, inconsequential company

[dAzED1]

I work for Lockheed Martin at a NY facility, and we use Netscape's LDAP for several very important things. They also have a policy against GPL software. I wonder what this means, now...

Re:small, inconsequential company

[Doktor Memory]

Means nothing. Lockheed bought NS-LDAP under whatever commercial license Netscape sold it under. Unless they want to upgrade to the RedHat release, the terms of that license still apply.

Re:small, inconsequential company

[dAzED1]

ah, so as long as they only want what they currently have, and not something newer, then they're ok. Unfortunately, that just might work for a long time here...I do have to get by with perl5.003, for example... :/

Re:small, inconsequential company

[dAzED1]

btw- first half was sarcasm.

Re:BFD...the IBM LDAP Server has *always* been fre

[diegocgteleline.es]

Because red hat is not just giving it for free - they've opensourced it. Under the GPL. This means it's really free, we can improve it, port to weird architectures, to freeBSD, etc. We can see the code, not just use it.

One other interesting note

[TheLinuxWarrior]

Where I'm currently contracting, it most likely won't fly to implement Netscape Directory since there probably won't be pre-compiled SPARC binaries for Solaris, etc.

However, even though we won't be officially allowed to run ND on Linux, that doesn't mean we can't use it as a club to beat Sun to get the price of support for Sun Java System Directory Server reduced.

really

[Anonymous Coward]

Aren't both red hat and netscape dead?

I bet ms has some great, if not even better, alternatives.

Re:Thanks! Another question

[Anonymous Coward]

Hell yeah!

Re:Thanks! Another question

[Anonymous Coward]

Hell no!

BS ALERT! -- AD is NOT multi-master

[Anonymous Coward]

Yes, its *marketed* as multi-master, but when a change to a multi-valued attribute (MVA; for example, the membership list of a Group) on one DC can get over-written by a change to the same MVA on the same object made on another DC, that ain't multi-master. And the Redmond solution was for admins to use a "focus DC" - essentially, a master-slave arrangement - for all administrative changes.

Ad is nothing but NT4 Domains - they added an extensible schema, transitive trust and a 3-D viewer. But its still a flat namespace, still a 2D data structure, has no partitioning ability, no meaningful time synchronization, is chained by the neck to DNS, uses Experimental RFCs, and you can't leverage the Directory structure for much of anything (for example, Users and Groups are the *only* security principals). And naturally, AD is only available on Windoze.

eDirectory is at *least* 5 years ahead of AD in any technical aspect you might care to mention.

Didn't Sun...

[eno2001]

...take Netscape's LDAP in the whole iPlanet debacle?

I remember distinctly being told by iPlanet (now SunOne) support that iPlanet Messaging Server was a hybrid of Netscape's Directory Server, some components of it's MTA or IMAP/POP3 implementation and Sun's SIMS (sp?) messaging system. So who actually owns Netscape Directory Server at this point?

Re:Didn't Sun...

[ear1grey]

The iPlanet deal was described to the UK employees as follows:

1. the iPlanet engineering and consultancy groups would be spun off to form an independent company owned by both AOL and Sun, or
2. at the end of the three year deal both companies could walk away with equal rights in the shared codebase.

Critically, AOL suffered accute corporate myopia due to their overinflated shareprice and their concentration on the "who's got the most web portal users" war. They appeared indifferent to the value of the server and professional services businesses of Netscape, so both entry into the deal, and exit from it, were IMO largely mishandled resulting in no significant gain for AOL.

Interestingly the deal was non-exclusive, so AOL could have signed similar deals with other hardware vendors, but failed to capitalize on that possibilitiy.

AOL disposed of part of the resulting code to RedHat, and that's what's been GPL'd.

Novell's competition has its uses

[Random BedHead Ed]

This is obviously a direct attempt to head off competition from Novell. Novell stands to become a powerful player in the Linux services biz if it plays its cards right, but this new directory (if it's stable and easy to use) could make people take a second look at Red Hat's offerings. Because let's face it, NIS stinks and doesn't do the sorts of things large enterprises want. A good directory is Linux's weak spot right now. I'm eager to try RHDS - I actually decided months ago to put off my OpenLDAP work until I can test RHDS.

What book do you recommend?

[Anonymous Coward]

Get a good book.

Help us out here....

Re:What book do you recommend?

[Anonymous Coward]

LDAP System Administration
By Gerald Carter
First Edition March 2003
ISBN: 1-56592-491-6

http://www.oreilly.com/catalog/ldapsa/toc.html

Re:BFD...the IBM LDAP Server has *always* been fre

[The Last Gunslinger]

http://www-306.ibm.com/software/tivoli/resource-ce nter/security/code-directory-server.jsp

You have to register (free) in order to download the code. Though it's under the "trial & beta" heading, the directory server is licensed free. You can use it for any purpose for any length of time.

The caveat is that it's unsupported. If you want a support contract for your use of the LDAP server, that's where the $10k comes in. Or, if you have a current support license for any software that includes the LDAP server (AIX, Websphere, Tivoli security stuff), you're supported without any additional license fees.

Re:BFD...the IBM LDAP Server has *always* been fre

[zx-6e]

From the website:
IBM TIVOLI DIRECTORY SERVER MGD PR FOR LINUX ON Z LIC+SW MAINT 12 MO (D54J6LL) 10,000.00
...

Doesn't look free to me...

That's for support...the code is licensed free.

[The Last Gunslinger]

That part# is for a maintenance & support agreement (LIC+SW MAINT). You only pay $10k if you want support for the LDAP server AND you don't already have a support contract for an IBM software product that includes it.

Re: Calendar server too?

[Anonymous Coward]

But has it become open source ?

Re:BFD...the IBM LDAP Server has *always* been fre

[Michael Snoswell]

Click on the link to get the software and it comes up:

IBM TIVOLI DIRECTORY SERVER MGD PR FOR LINUX ON Z LIC+SW MAINT 12 MO (D54J6LL) 22,330.00 (tax ex) 24,563.00 (tax inc)

Doesn't sound free...

when all you have is a hammer...

[Doktor Memory]

LDAP architects would also wonder why on earth you would ask an ldap server to live under such a write intensive churn, and they'd be right again.

It could have been worse. Circa 1999, I worked as postmaster for one of the three largest webmail providers in the world, and we kept our entire user directory, which was consulted every single time a piece of email was delivered... ...in NIS+.

Yes, really. No, no one was willing to take responsibility for the decision by the time I got there. Yes, it worked about as badly as you'd imagine.

Sun tech support makes all sorts of amusing strangled noises when you tell them that you've got 3 million user objects in Passwd.org_dir. Then they stop returning your phone calls.

We eventually replaced the whole nightmare with a monstrously huge Oracle database running on an E6000, but for a few terrifying months, I could claim to be administering the largest NIS+ instance in the world. But for some reason, I never put that one on my resume...

p.s.

[Doktor Memory]

Other posters asked for SunOne Calendar server to be opensourced. My first response is to suggest you have your head examined since that thing would die for absolutely no reason on a regular basis.

FWIW, whatever bugs were in the NSCP/Sun Calendar server were fixed in the Steltor/Oracle branch of the product, so while it might take some time to turn a hypothetical GPLed branch of SCS into something useful, I'm confident that it could be done.

But mainly, I want to see it done just to fuck Larry Ellison right in the damned eye for buying Steltor (a company with a great product and excellent support) and burying it underneath the rotting carcass of Oracle Collaboration Suite.

(Huh, guess you're not the only person in a weird mood today.)