RE: [CentOS] LDAP Implementations (was: Linking against a specifi c Berkeley DB install)
From: Bryan J. Smith [mailto:thebs413@earthlink.net]
Bowie Bailey Bowie_Bailey@BUC.com wrote:
It is an interesting choice. It supports multi-master replication which I will need and has some GUI management utilities. Anyone know of any problems with it?
Only that many people on this list have been ignorant of what NsDS is in the past, even though it's in major use -- especially before even the appearance of ADS in Windows 2000, let alone how well it does integrate it for ADS-to/from-NsDS synchronization. I.e., NsDS can run on Windows too, and Fedora makes those binaries available.
I don't know if I'd trust the FDS 1.0 "open source" version yet, as it's missing components last time I checked, but the FDS binaries? 100% NsDS 7.1 -- Linux, Windows, Solaris, etc...
I'm not resistant to changing programs. We are in a testing mode now and I have barely even started looking into how to configure multi-master replication in OpenLDAP.
The showstopper at the moment is that FDS 1.0 does not currently support x86_64, which is what our production servers will be running.
Bowie
Bowie Bailey Bowie_Bailey@BUC.com wrote:
I'm not resistant to changing programs.
I didn't think you needed to, that's why I didn't suggest FDS. I only commented on FDS after several people commented, and it was clear that was a tangent going forward.
We are in a testing mode now and I have barely even started looking into how to configure multi-master replication in OpenLDAP.
Oh, I had assumed you already had OpenLDAP in production. In that case, download FDS 7.1 (legacy binary version) from here: http://directory.fedora.redhat.com/wiki/Special:Download
The showstopper at the moment is that FDS 1.0 does not currently support x86_64, which is what our production
servers
will be running.
You can run the i386 version on x86_64. But yeah, from a scalability standpoint, it would be nice.
On Thu, 2005-12-01 at 14:37 -0800, Bryan J. Smith wrote:
Bowie Bailey Bowie_Bailey@BUC.com wrote:
I'm not resistant to changing programs.
I didn't think you needed to, that's why I didn't suggest FDS. I only commented on FDS after several people commented, and it was clear that was a tangent going forward.
---- Les has that way about him.
Craig
Craig White craigwhite@azapple.com wrote:
Les has that way about him.
I noted several people, not just him. Regardless, it seems the original poster is not totally tied to OpenLDAP, so it wasn't really an unwarranted tangent in the end. I'm just less assuming at first I guess.
One of our strategic goals for this year is to switch from NIS to LDAP (which hasn't happened so far due to some ancient Unix boxes). Which should I investigate first OpenLDAP or FDS?
Can some one point me to pro's and cons? (links very much appreciated) I'm semi leaning to FDS since it appears to scale really well and I like its replication abilities, but honestly I'm fairly ignorant and just starting my research.
Thanks, Bill Triest Systems Specialist Department of Chemistry The Ohio State University
On Thu, 2005-12-01 at 15:22 -0800, Bryan J. Smith wrote:
Craig White craigwhite@azapple.com wrote:
Les has that way about him.
I noted several people, not just him. Regardless, it seems the original poster is not totally tied to OpenLDAP, so it wasn't really an unwarranted tangent in the end. I'm just less assuming at first I guess.
"William (Bill) E. T." wtriest@chemistry.ohio-state.edu wrote:
One of our strategic goals for this year is to switch from NIS to LDAP (which hasn't happened so far due to some
ancient
Unix boxes). Which should I investigate first OpenLDAP or
FDS?
Can some one point me to pro's and cons? (links very much appreciated)
FDS is NsDS, which has been a _long_time_ and is well trusted. It's synchronization with ADS is much, much better, and removes the need to deal with a set of "glue together" services just to get such. The included certificate server is a nice touch, although being truly open, you can still use Kerberos and other authentication systems as well.
But probably the biggest boost to why NsDS is more viable for most enterprises than OpenLDAP is Red Hat's license of it. Red Hat really tried to make OpenLDAP work in its enterprise services model, but in the end, it was well worth their bother to pay $20M to open source NsDS. Red Hat is behind it 100%, and that includes charging $15,000/server for what is free in the same FDS you can download.
On Thu, 2005-12-01 at 16:38 -0800, Bryan J. Smith wrote:
"William (Bill) E. T." wtriest@chemistry.ohio-state.edu wrote:
One of our strategic goals for this year is to switch from NIS to LDAP (which hasn't happened so far due to some
ancient
Unix boxes). Which should I investigate first OpenLDAP or
FDS?
Can some one point me to pro's and cons? (links very much appreciated)
FDS is NsDS, which has been a _long_time_ and is well trusted. It's synchronization with ADS is much, much better, and removes the need to deal with a set of "glue together" services just to get such. The included certificate server is a nice touch, although being truly open, you can still use Kerberos and other authentication systems as well.
But probably the biggest boost to why NsDS is more viable for most enterprises than OpenLDAP is Red Hat's license of it. Red Hat really tried to make OpenLDAP work in its enterprise services model, but in the end, it was well worth their bother to pay $20M to open source NsDS. Red Hat is behind it 100%, and that includes charging $15,000/server for what is free in the same FDS you can download.
---- OK - I'm intrigued...I just signed up for their mail list to see what the questions/problems are.
Craig
On Thu, 2005-12-01 at 20:33 -0700, Craig White wrote:
On Thu, 2005-12-01 at 16:38 -0800, Bryan J. Smith wrote:
"William (Bill) E. T." wtriest@chemistry.ohio-state.edu wrote:
One of our strategic goals for this year is to switch from NIS to LDAP (which hasn't happened so far due to some
ancient
Unix boxes). Which should I investigate first OpenLDAP or
FDS?
Can some one point me to pro's and cons? (links very much appreciated)
FDS is NsDS, which has been a _long_time_ and is well trusted. It's synchronization with ADS is much, much better, and removes the need to deal with a set of "glue together" services just to get such. The included certificate server is a nice touch, although being truly open, you can still use Kerberos and other authentication systems as well.
But probably the biggest boost to why NsDS is more viable for most enterprises than OpenLDAP is Red Hat's license of it. Red Hat really tried to make OpenLDAP work in its enterprise services model, but in the end, it was well worth their bother to pay $20M to open source NsDS. Red Hat is behind it 100%, and that includes charging $15,000/server for what is free in the same FDS you can download.
OK - I'm intrigued...I just signed up for their mail list to see what the questions/problems are.
I think FDS (RH Directory Services) will certainly be the answer in the long run ... at least for PNAELV source based distros like CentOS. We will provide it once it is released by the upstream vendor in it's final form for the enterprise. For now, OpenLDAP works OK ... as least for me.
Johnny Hughes mailing-lists@hughesjr.com wrote:
I think FDS (RH Directory Services) will certainly be the answer in the long run ... at least for PNAELV source based distros like CentOS. We will provide it once it is
released
by the upstream vendor in it's final form for the
enterprise.
For now, OpenLDAP works OK ... as least for me.
As I've been saying all along, for now, stick with the legacy, binary 7.1 releases. They are well proven and well documented.
I think the "litmus test" for FDS is when Red Hat switches to it features and default programs (such as the admin tools) for its paid/SLA Red Hat Directory Server product (only providing any non-free stuff as "legacy").
Until then, CentOS users should feel free to use the binary 7.1 release or the new 1.0 release as they feel appropriate. I'm sure the 1.0 will have more of a direct upgrade path, although both are network-level compatible and can directly replicate (which is why they say 1.0 is like a "7.2" release).
The lack of autoconf/automake and other source-level changes in the current 1.0 state really makes rebuilding a pain from SRPM. I'm sure their initial, main focus was getting as much open source as possible, including replacing the few components they couldn't have open sourced. Now that is done with the 1.0 release, at least to a point of compatibility and effective usability (especially the admin tools). So you can be sure a complete source set that builds from SRPM is next.
Hello folks,
Just to chime in here:
On Fri, 02 Dec 2005 08:47:11 -0800 (PST), "Bryan J. Smith" thebs413@earthlink.net wrote:
Until then, CentOS users should feel free to use the binary 7.1 release or the new 1.0 release as they feel appropriate. I'm sure the 1.0 will have more of a direct upgrade path, although both are network-level compatible and can directly replicate (which is why they say 1.0 is like a "7.2" release).
Yesterday, Sun also made their JES/Identity Server stack all free. From a few Sun internal mailing lists that I am subscribed to:
======================================================================= TO: All Java Enterprise System Beta Evaluators
There is an exciting announcement posted at: http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051130.1.html that I would like to bring to your attention. The title is:
"Sun Pioneers Shift to Free and Open Source Software; Builds on Success of Solaris by Announcing Java Enterprise System, Developer Tools and N1 Software are Available at No Cost"
"Combines Middleware, Tools and Management Components With Solaris to Create Consolidated, Multi-Platform Software Environment"
Thank you for your attention.
Eric Redmond Solaris Enterprise System Beta PM =======================================================================
Further discussion on the iMS list, provided this info from Dan Newman:
======================================================================= On 1 Dec 2005 , at 10:20 AM, Chet Burgess wrote:
This announcement would seem to imply that they are going toopen source the messaging server. Any of the dev types have any more details on if this is going to happen,
Yes, the goal is, over time, to open source JES including JES Messaging Server. What's with the "over time"? Well, our lawyers need to work with each point product team to identify and resolve any legal encumbrances. Then some group somewhere has to santize the code: remove, shall we say, embarrassing comments and similar. Our lawyers, product managers, and engineers already do a thorough job tracking of encumbrances; however, it should be clear that in such a situation you want to go back over everything with a fine tooth comb less you accidentally release someone else's (intellectual) property to the world as open source. So, that is the process which has been happening and is continuing to happen. I'm not aware of a date for Messaging Server but I hope that it indeed is open sourced and sooner rather than later. (Some time back I started amusing myself by putting in random, weird comments just so I can see what does or doesn't get excised.) =======================================================================
-----------------------------------------------------------------------------------
So, soon one should be able to get not only Sun's Java Messaging Server (which incidently runs beautifully on CentOS ;-)), but also their Directory Server 5.2 with source code (under CDDL, I believe).
Hope that helps,
-Bruno
"Bruno S. Delbono" Bruno.S.Delbono@Mail.AC wrote:
Yesterday, Sun also made their JES/Identity Server stack all free. From a few Sun internal mailing lists that I am subscribed to: ... So, soon one should be able to get not only Sun's Java Messaging Server (which incidently runs beautifully on CentOS ;-)), but also their Directory Server 5.2 with source code (under CDDL, I believe).
Sun isn't standing while Red Hat moves forward.
Be aware that many things are still "Free Beer" and not even MPL-licensed, and there is the Java requirement, but for some integrators (including myself), there are too many advantages to Solaris and Sun technologies in some uses.
Just remember it's _not_ 100% redistributable and open source like anything that comes out of Red Hat, so remember to mitigate any risks in those regard if you still see value.
-
Bowie Bailey -
Bruno S. Delbono -
Bryan J. Smith -
Craig White -
Johnny Hughes -
William (Bill) E. T.