Slashdot Mirror
Red Hat Acquires Netscape Server Products
KrisWithAK writes "According to a press release, Red Hat is acquiring parts of the Netscape Enterprise Suite including the directory server and certificate management system. I am definitely looking forward to more open source competition with OpenLDAP!"
I've used it to replace some Netscape stuff - it was part of a big Weblogic->Oracle->Solaris EJB app.
OpenLDAP seemed to work fine, although maybe it was because we weren't really loading it up too much...
The Army reading list
Netscape Directory Server 6 was basically a fork of the iplanet DS 5 product, where Sun carried on the 5.x versioning.
Very very similar products, both good.
Developers from Netscape started LDAP. From the looks of the Directory Server it does.
Here's the feature guide for Directory Server 6.21.
Check out Mon and Mon.cgi
1. Netscape DS compares very favorably. It has multi-master replication, and its performance is far above that of openLDAP. OpenLDAP is opensource, though, and very flexible. Netscape has to be paid for, and it's (if I recall) per-seat licensing. Sun's DS is per-entry licensing. Sun's DS and Netscape's DS are very similar, being forks of iPlanet's DS.
2. Yes, sort of. Some forms of replication can work, and both are standard ldap servers. As far as I know (I haven't used openldap for a bit) openldap cannot understand Netscape/iPlanet/Sun Directory server's new replication.
ACL's in iPlanet/Netscape/Sun's DS are wonderful. ACL's can be held in any entry, and take effect immediately. All you have to do is request the aci attribute (assuming you have priveledges) to see the rules. Acl's go so far as to be dynamic, too, taking into account the binding user's DN, being able to create masks, etc.. There are some wonderful features that I hope make it into openLDAP, or heck, if they just open the source of Netscape DS, that'd be incredible.
Then this is definitly for you. Red Hat, as with all things, will open source this. A lot of people say bad things about Red Hat, but they do alot for the community, they just don't try to take the spotlight. I mean how cool is their patent policy? Any patent they get ( which is always for defensive purposes) can be used by any free software project without worries.
Regards,
Steve
iPlanet was a join Sun/Netscape venture. AOL bought Netscape, thus Netscape's Directory server. When the iPlanet venture was dissolved, AOL had the directory server, which was one of the things Netscape brought to the iPlanet experiment. I don't recall the details, but I think they forked the code when iPlanet was absorbed into Sun.
I can respond to that with an enthusiastic YES, it does work.
We use it to authenticate our email and calendar users (from two different servers). I'm migrating us off our OLD Netware servers (damn lean budget years!) to Samba and am setting Samba to authenticate against it as well, finally giving our users a single userid and password for all our services.
OpenLDAP is lightweight (size and CPU-wise), robust, and reliable. It's also really easy to set up if you use the version included with your distribution. You can also replicate the server to give yourself good fault-tolerance on another piece of hardware.
RedHat has good online documentation on their website in the RHEL Reference Guide that should help explain things to you a bit.
Life is short: void the warranty.
You may be interested in pGina; it's a nifty, opensource, project that allows you to bypass Microsoft's authentication schemes and replace it with something like LDAP. Works like a charm! We're still working out the kinks of the roaming profiles with the ftp plugin though. Anyone interested in cross-platform authentication should check it out.
harmonious design
It became iPlanet CS, which became SunONE CS and is integrated into the Sun JES stack. It now includes an Outlook connector.
http://wwws.sun.com/software/products/calendar_
You said that wrong. Let me help:
I, for one, welcome our new LDAP overlords!
With that said, let me also say that I've been working with Sun's iPlanet Directory server since they acquired it from Netscape. It's used for our iPlanet mail suite. In a word, it sucks ass. The intial migration from Netscape Directory server 3.x to iPlanet's directory server was a nightmare. The documentation on the schema layout for mail was non-existent. (Still is as far as I know) There were no migration tools. I just had to dump the Netscape Directory server data to a huge text file. iPlanet support then told me to go through this file by hand and edit or remove any of the lines that didn't apply or had the wrong format. !!!! WTF!? I spent months of late nights pushing the file back and forth between OpenVMS and Solaris just so my boss could use DCL and EDT to make most of the changes needed. The migration actually took me about a year and a half and there is still detritus floating around the LDAP directory. I now have a better understanding of the user account portion of iPlanet's schema, but no thanks to Sun. iPlanet sucks. I can only hope that Redhat will do a better job with what they've acquired.
One last bit to my rant:
Sun STILL has portions of the old Netscape administration tools in the iPlanet suite. This wouldn't be a problem except for the fact that they still kind of work. Enough to damage LDAP data. According to their support they told me to NOT use those tools. THEN WHY THE HELL ARE THEY STILL INCLUDED!!!!??? Crap. Pure crap.
Un-news
First, migration from 3.x? That product was end of lifed like 6 or 7 years ago...
Second, the directory server is a great product (probably one of the few great products left unscathed by Sun).
The problems you are seeing are Sun's failure to integrate the iPlanet products well, which only got worse with JES 6.0 - For instance when they added pmdf to the messaging server and changed to the 5.x schema, they broke all the Messaging user admin in Console, and never fixed them or came up with reasonable replacements (Delegated Admin - puleeaze; identity server? don't even get me started...). In JES 6.0, they don't document their new schema again, but this is a messaging/cal problem, not a DS problem. No one bought many of their products, so now they make install all interdependent (messaging and cal depend on identity, which depends on their lousy web or app server, etc). Sun has made a major mess of what used to be pretty good, easy to use products.
In any case, take out the messaging and cal products, and directory is actually very good, very fast, very flexible.
You forgot the <smartass> tag. You did mean that sarcastically, didn't you?
I replaced NIS with OpenLDAP on a small network and have a lot of love for it, but your example looked like a Sendmail config file rewritten as APL macros piped through Perl with a couple of trips through Babelfish. That is, I recognized a few words but have no freakin' idea what you were trying to say.
I sincerely hope Netscape provides some good competition to OpenLDAP, because I'd like to think I'll never have to try to understand what you just wrote.
Dewey, what part of this looks like authorities should be involved?
Sorry, Sun makes a great alternative to exchange. With Sun Messaging Server, and Calendar deployed it works better, and cheaper than exchange. With the outlook connector you can use it with Outlook as well. Sun also offers a unified web client that brings calendar, mail and address book together in one web interface (much better than OWA).
For proof, I did an implementation for over 1 million users of calendar, directory and messaging. Its run on three 6800's (two for messaging, one for calendar, all domained and clustered) and has, yes, this is true, only 2, yes 2 admins.
Try that with exchange!
# nohup
Yes a Directory Server is a database. However, whereas a SQL server is a general purpose database engine, an LDAP Directory Server is typically optimized for read speed at the expense of write speed. Other highlights include a hiarchical tree structure to store entries and extensive standard schema for many object types.
Essentially, LDAP directories fill niche roles, one of which is as an address book server, another is authentication services. In their niche, DS deployments are unequalled (and no, slapping an LDAP protocol interface on a SQL engine doesn't cut it.) One guiding principal is if you have 70/80% reads to 30/20% writes - a directory server may be a better option for your application. There are other considerations, but that is beyond the scope of this blah blah blah...