From: Craig White [mailto:craigwhite@azapple.com]
On Thu, 2005-12-01 at 13:01 -0600, Les Mikesell wrote:
On Thu, 2005-12-01 at 12:19, Bowie Bailey wrote:
I was able to get OpenLDAP to compile against db4.3. Any particular reason it isn't recommended?
I see fedora directory server just made the 1.0 release. Might that be a better choice?
I doubt that it would be a better choice but I would agree that it is indeed a choice. One of those things where there isn't a black and white better daemon. This however doesn't answer OP's question.
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?
Bowie
On Thu, 2005-12-01 at 15:24 -0500, Bowie Bailey wrote:
From: Craig White [mailto:craigwhite@azapple.com]
On Thu, 2005-12-01 at 13:01 -0600, Les Mikesell wrote:
On Thu, 2005-12-01 at 12:19, Bowie Bailey wrote:
I was able to get OpenLDAP to compile against db4.3. Any particular reason it isn't recommended?
I see fedora directory server just made the 1.0 release. Might that be a better choice?
I doubt that it would be a better choice but I would agree that it is indeed a choice. One of those things where there isn't a black and white better daemon. This however doesn't answer OP's question.
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?
---- Seems that it languished for a long time after Sun bought it from AOL before Red Hat bought it from Sun (it was originally known as Netscape Directory Server).
I don't think it supports schema checking. I got the impression that it isn't that fast. I don't think that there are many people using the newly revised open source version.
Craig
I avoided even suggesting FDS because I assumed that if someone was using OpenLDAP already, they wouldn't want to convert their schema and setup. But since others have responded, let me clear up some things.
Craig White craigwhite@azapple.com wrote:
Seems that it languished for a long time after Sun bought it from AOL before Red Hat bought it from Sun (it was originally known as Netscape Directory Server).
Whoa whoa whoa! Let's get some things straight here ...
1) Netscape Directory Server (NsDS) and Certificate Server (CS) are in _heavy_ use across _many_ huge (10,000+ user/node) networks -- especially those that use a variety of platforms.
2) Sun _licensed_ NsDS' LDAP components from AOL-Netscape as the directory portion of their Sun One platform. Sun still uses RSA for its authentication/crypto, just as it did in NIS+.
3) Red Hat spend several years trying to beef up OpenLDAP as the heart of its open source enterprise services platform, but finally just started reselling NsDS/CS as RHDS/CS last year. This deal included the rights to GPL most of NsDS/CS no later than April 30, 2005.
4) The same NsDS/CS version 7.1 that has been used by many enterprise is now available as the identical FDS/CS (free) and RHDS/CS ($15K w/support). The current, binary FDS/CS is 100% freely redistributable.
5) FDS/CS is also available in a new, changing form -- a sprawling set of GPL/Freedomware compnents that are almost complete. Long story short, several components cannot be directly GPL'd/Freedomware'd, although lawyers and technologists alike are working together to make a 100% GPL version. The new 1.0 milestone is a good sign, although _not_ everything is in there.
I don't think it supports schema checking. I got the impression that it isn't that fast.
Which versions?
The binary FDS/CS release that is based on the existing RHDS/CS 7.1? Or the new FDS/CS 1.0 source code release?
I don't think that there are many people using the newly revised open source version.
Then use the binary version. It's free and freely redistributable. ;->
On Thu, 2005-12-01 at 13:28 -0800, Bryan J. Smith wrote:
- Red Hat spend several years trying to beef up OpenLDAP as
the heart of its open source enterprise services platform, but finally just started reselling NsDS/CS as RHDS/CS last year. This deal included the rights to GPL most of NsDS/CS no later than April 30, 2005.
---- I hesitate to go on this divergent path but I was never convinced that Red Hat has opened their heart to openldap... RHEL 3 after all shipped the ancient 2.07 version and RHEL 4 continues to languish with a partially broken 2.2.13 and only recently have they finally tried to integrate a broken but commendable effort of openldap & kerberos in FC-4
Thus - the OP was trying to get an openldap installation up to speed.
Craig
Craig White craigwhite@azapple.com wrote:
I hesitate to go on this divergent path but I was never convinced that Red Hat has opened their heart to
openldap...
RHEL 3 after all shipped the ancient 2.07 version
Red Hat Linux 8/9 is well over 3 years old! RHEL 3 is based on that.
and RHEL 4 continues to languish with a partially broken 2.2.13
Fedora Core 2/3 is now over 18 months old. RHEL 4 is based on that.
and only recently have they finally tried to integrate a broken but commendable effort of openldap & kerberos in
FC-4
And now you know _why_ they decided to go NsDS last year. Because OpenLDAP 2.2 at the time was really missing a lot without requiring a lot of site customization.
Unlike the few vendors who tried to integrate a "basic" OpenLDAP with maybe a Samba schema and store at best, Red Hat wanted a _true_ LDAP + Certificate + Kerberos + etc... setup out-of-the-box for UNIX networks (not just Windows/e-mail).
The only good OpenLDAP implementations I've seen are the ones where people put a _lot_ of effort into their own, custom schema. It's really an undertaking, and not one I'd even want to look at. Again, outside of some cookbook OpenLDAP+Samba setups, there is a _lot_ that OpenLDAP requires someone to integrate that NsDS did well off-the-bat.
Especially the ADS integration portions where NsDS is a _peer_ or "master" to ADS, not just its "bitch" (member server and _not_ really a directory server ;-).
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...
On Thu, 2005-12-01 at 15:49, Bryan J. Smith wrote:
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 thought the point of it being a 1.0 release meant that all the parts were done. But I'm not sure how it fits into the RHEL or Centos world. Is some maintained version likely to end up in the Centos extras repository?
Les Mikesell wrote:
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 thought the point of it being a 1.0 release meant that all the parts were done. But I'm not sure how it fits into the RHEL or Centos world. Is some maintained version likely to end up in the Centos extras repository?
Upstream is making binaries avaiable for El3/ EL4 that work fine with CentOS - the build process, at this stage, is non-trivial and unless we have someone come on board who understands the issues involved and can work the source code of FDS, I'd hesitate to import it into the CentOS repositories.
I, for one, have no clue about that source base.... if anyone here has an idea of whats going on, feel free to drop in on #centos-devel at irc://irc.freenode.net/ and say hi to either Johnny ( hughesjr on irc ) or Jim Perrin ( Evolution on irc ).
as for it being a 'maintained' version ? well, again - maintained at upstream would be a better idea.
- K
On Fri, 2005-12-02 at 12:49 +0000, Karanbir Singh wrote:
Les Mikesell wrote:
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 thought the point of it being a 1.0 release meant that all the parts were done. But I'm not sure how it fits into the RHEL or Centos world. Is some maintained version likely to end up in the Centos extras repository?
Upstream is making binaries avaiable for El3/ EL4 that work fine with CentOS - the build process, at this stage, is non-trivial and unless we have someone come on board who understands the issues involved and can work the source code of FDS, I'd hesitate to import it into the CentOS repositories.
I, for one, have no clue about that source base.... if anyone here has an idea of whats going on, feel free to drop in on #centos-devel at irc://irc.freenode.net/ and say hi to either Johnny ( hughesjr on irc ) or Jim Perrin ( Evolution on irc ).
as for it being a 'maintained' version ? well, again - maintained at upstream would be a better idea.
- K
I agree with Karanbir here ... and if / when we build it ... it will probably be because the Enterprise version is released, for EL3 and EL4, available only to paying customers, and is different than the FDS version.
Johnny Hughes mailing-lists@hughesjr.com wrote:
I agree with Karanbir here ... and if / when we build it ... it will probably be because the Enterprise version is released, for EL3 and EL4, available only to paying customers, and is different than the FDS version.
And that's an excellent approach. I'm sure you're seeing what happens if and when there is SRPM for RHDS -- if ever. It could be likely be you'll never see one, because the future 1.x series will just be FDS -- bit for bit.
In case it isn't clear to many, this is not like RHEL which is a 18-month released based on 2-3 revisions of RHL/FC. This is a project-product added to the distro, and is the same that runs on either series.
But according to the FAQ, they don't even have the codebase working with autoconf/automate yet, so I'd say it'll be a bit before you can even rebuild FDS from SRPM directly. So any RHEL SRPM will be behind that (if offered at all -- again, probably not if it's 0 different).
On Fri, 2005-12-02 at 10:51, Bryan J. Smith wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
I agree with Karanbir here ... and if / when we build it ... it will probably be because the Enterprise version is released, for EL3 and EL4, available only to paying customers, and is different than the FDS version.
And that's an excellent approach. I'm sure you're seeing what happens if and when there is SRPM for RHDS -- if ever. It could be likely be you'll never see one, because the future 1.x series will just be FDS -- bit for bit.
So, if you were starting now and hoping as soon as possible to switch painlessly to something that will take care of itself with a 'yum update' like the rest of the system, what's your best guess about what to install?
On Fri, 2005-12-02 at 13:33 -0600, Les Mikesell wrote:
On Fri, 2005-12-02 at 10:51, Bryan J. Smith wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
I agree with Karanbir here ... and if / when we build it ... it will probably be because the Enterprise version is released, for EL3 and EL4, available only to paying customers, and is different than the FDS version.
And that's an excellent approach. I'm sure you're seeing what happens if and when there is SRPM for RHDS -- if ever. It could be likely be you'll never see one, because the future 1.x series will just be FDS -- bit for bit.
So, if you were starting now and hoping as soon as possible to switch painlessly to something that will take care of itself with a 'yum update' like the rest of the system, what's your best guess about what to install?
---- having just now installed fedora-ds and starting to play with it, it's not likely to be a 'yum' able install...at least not in the immediate future.
Craig
Les Mikesell lesmikesell@gmail.com wrote:
So, if you were starting now and hoping as soon as possible to switch painlessly to something that will take care of itself with a 'yum update' like the rest of the system, what's your best guess about what to install?
Neither at this point. Red Hat does not have even the FDS 1.0 code base in a form that is manageable and buildable like most open source code bases. I'd say that's still 3-6 months away.
I'd personally just install the 7.1 binaries. NsDS 5.x-7.x is what I've been using for the last few years.