


Red Hat Opens Netscape Directory 229
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."
This was an expensive ordeal... (Score:5, Interesting)
Re:This was an expensive ordeal... (Score:4, Informative)
Goodness, that is a lot of money.
Re:This was an expensive ordeal... (Score:4, Insightful)
Plus, after years of hotair, RedHat just became credible Windows alternative for internal applications. cheep.
Re:This was an expensive ordeal... (Score:2, Informative)
Re:This was an expensive ordeal... (Score:2)
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
Re:This was an expensive ordeal... (Score:2)
Re:This was an expensive ordeal... (Score:5, Insightful)
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... (Score:5, Informative)
Re:This was an expensive ordeal... (Score:3, Insightful)
Re:This was an expensive ordeal... (Score:4, Insightful)
Re:This was an expensive ordeal... (Score:2, Informative)
SUN ONE not quite direct descendent. (Score:4, Informative)
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.
OpenLDAP is not hard to configure. (Score:2, Interesting)
Re:This was an expensive ordeal... (Score:2)
"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... (Score:2, Insightful)
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
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 int
Re:This was an expensive ordeal... (Score:2)
Definitely overrated.
Re:This was an expensive ordeal... (Score:2)
Re:This was an expensive ordeal... (Score:2)
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
Re:This was an expensive ordeal... (Score:2, Informative)
Now the CIO knows he/she can buy Red Hat "Professional"
Re:This was an expensive ordeal... (Score:2, Informative)
Now that Novell own SuSE I except eDirectory to be the number one Linux LDAP compliant directory available.
Re:This was an expensive ordeal... (Score:3, Interesting)
(Leaving aside the obvious question of using SunOne for anything at all...)
Re:This was an expensive ordeal... (Score:2)
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... (Score:2)
Actually, Red Hat paid 20.5 million for this implementation of LDAP. It's actually the same protocol as everyone else.
What's ND have that OpenLDAP doesnt? (Score:4, Interesting)
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? (Score:5, Interesting)
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? (Score:4, Informative)
Regards,
Steve
Re:What's ND have that OpenLDAP doesnt? (Score:2)
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 [symas.com]
Those are real facts that anyb
Re:What's ND have that OpenLDAP doesnt? (Score:2)
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? (Score:2, Informative)
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 woul
Re:What's ND have that OpenLDAP doesnt? (Score:2)
Re:What's ND have that OpenLDAP doesnt? (Score:2)
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? (Score:5, Interesting)
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? (Score:5, Informative)
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? (Score:2, Interesting)
Re:What's ND have that OpenLDAP doesnt? (Score:2)
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:
up2dat
Re:What's ND have that OpenLDAP doesnt? (Score:4, Informative)
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? (Score:5, Interesting)
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.
Proper replication (Score:3, Funny)
Re:What's ND have that OpenLDAP doesnt? (Score:4, Informative)
* 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? (Score:4, Interesting)
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? (Score:3, Informative)
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 actual
From a user perspective (Score:4, Interesting)
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 (Score:5, Insightful)
Well, you can actually do that and more with any LDAP server.
Well... (Score:2)
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... (Score:3, Insightful)
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 g
Re:From a user perspective (Score:2)
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
Re:From a user perspective (Score:2)
Comparison (Score:5, Interesting)
Re:Comparison (Score:2, Informative)
Re:Comparison (Score:4, Interesting)
Re:Comparison (Score:2)
Re:Comparison (Score:5, Interesting)
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 (Score:4, Insightful)
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 (Score:2)
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 wi
Re:Comparison (Score:2, Informative)
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 s
Re:Comparison (Score:3, Informative)
With eDirectory and AD, you can update any server and each server then replicated globally. Each have their own mechanism fo
Re:Comparison (Score:2)
Right here [novell.com].
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.
This has huge potential (Score:5, Interesting)
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 (Score:2)
Perhaps you might consider combining the now-open Netscape Directory and combining it with something like Citadel [citadel.org] 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 pro
Re:This has huge 'killer' potential (Score:2)
Things are a lot different than they were back then... even 5 years ago.
Re:This has huge 'killer' potential (Score:2)
Re: Calendar server too? (Score:2)
Steltor (CorporateTime) became Oracle Calendar. That's also a cool product.
Also in the calendaring realm is MeetingMaker.
Now if only it had Hula's calendaring and email (Score:5, Interesting)
A killer kombination for Open Source.
Re:Now if only it had Hula's calendaring and email (Score:3, Insightful)
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!
Enterprise Solutions (Score:4, Insightful)
Now if they would only open source Netscape calendaring...
Re:Enterprise Solutions (Score:3, Informative)
Did RedHat get rights to Netscape Calendar? I thought that was all sold to Steltor as Steltor CorporateTime [steltor.com] before it all got gobbled-up by Oracle and became Oracle Collaboration Suite's Oracle Calendar [oracle.com]. 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, per
Sun Directory Server vs. Netscape Directory Server (Score:3, Interesting)
Where are they now? (Score:2, Informative)
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 w
Re:Where are they now? (Score:2)
It has took them 8 months to GPL it. I guess they've focused more in the netscape directory.
Re:Where are they now? (Score:2)
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 MT
LDAP is lightweight (Score:4, Interesting)
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 (Score:3, Interesting)
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 (Score:2)
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
Re:LDAP is lightweight (Score:2)
Re:LDAP is lightweight (Score:2)
Re:LDAP is lightweight (Score:2)
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 (Score:2)
http://www.ietf.org/rfc/rfc2251.txt?number=2251 [ietf.org]
Section 4 "Elements of Protocol" (page 9)
Re:LDAP is lightweight (Score:2)
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 addi
Re:LDAP is lightweight (Score:2)
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 feature
Re:LDAP is lightweight (Score:2)
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 h
Re:LDAP is lightweight (Score:2)
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 behav
Re:LDAP is lightweight (Score:2)
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 prot
Re:LDAP is lightweight (Score:2)
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 bo
Re:LDAP is lightweight (Score:2)
"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 (Score:2)
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
Re:LDAP is lightweight (Score:2)
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 specif
Re:LDAP is lightweight (Score:2)
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,
What do you know, it ain't dead yet... (Score:3, Informative)
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... (Score:2)
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 binar
Open LDAP (Score:2)
We used SUN/One for SprintPCS and....... it sucked (Score:5, Interesting)
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 [internetnews.com])
-- 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 (Score:4, Informative)
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/d
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?
Re:BFD...the IBM LDAP Server has *always* been fre (Score:2)
Even if that is true, that's still different from releasing as Open Source.
Re:BFD...the IBM LDAP Server has *always* been fre (Score:5, Insightful)
Re:BFD...the IBM LDAP Server has *always* been fre (Score:2, Interesting)
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.
One other interesting note (Score:2)
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.
Re:Netscape Directory **IS** OpenLDAP (Score:4, Interesting)
See for yourself:
http://www.stanford.edu/services/directory/openld
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.
I'm sure OpenLDAP 17 will be faster still (Score:2)
Re:I'm sure OpenLDAP 17 will be faster still (Score:2)
Re:I'm sure OpenLDAP 17 will be faster still (Score:3, Interesting)
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