Hi,
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
my DB_CONFIG file is
------
# Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment.
set_cachesize 0 524288000 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 20485760 set_tmp_dir /tmp
# Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option).
set_flags DB_LOG_AUTOREMOVE set_flags DB_LOG_INMEMORY set_flags DB_TXN_NOSYNC
-------------
Can someone help me
Thanks Ram
ram wrote:
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
We have about 50,000 students, and 20,000 faculty & staff, with over four million records. My understanding is that we're one of the larger OpenLDAP sites around, although Stanford and some other major Universities might be larger.
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
Our production OpenLDAP servers have 32GB of RAM on Solaris 9, running OpenLDAP 2.3.35 (we've seen some weird problems with 2.3.40, and haven't even seriously looked at the 2.4.* stuff). We've been working with assigning 10GB or 20GB for Berkeley DB cache in this environment, and we're not sure if the larger amount is causing the weird problems we've had this week. I couldn't tell you what our IDL or slapd caches are set to, however.
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
I don't know that much about OpenLDAP yet, but based on my reading of the OpenLDAP documentation and what I know of different database formats like dbm and db outside of OpenLDAP, you want to avoid dbm if at all possible.
Can someone help me
The one thing that is kind of weird about our environment is that they're going add-happy in giving an OpenLDAP unique identifier to each and every student who has ever passed through the University, and to each and every person who has ever worked at the University, including temps or consultants who may have only been here for a few days. So, I think we're issuing a lot more ids than we have currently active people.
One thing you're going to want to look at is how many records you have for each active user, and how big those records are, so that you have an idea of how much memory you're going to need. In our case, we've been told that with an average record size of about 3KB, we should be able to fit all the BDB files into a 16GB RAM cache. Checking the various *.bdb files we have on our production server, I see that they take up just under 14GB on disk, so a 16GB RAM cache for them would seem reasonable. However, that doesn't account for the index (*.hdb) files....
To be honest, my past experiences with other databases is that the indexes are frequently an order of magnitude larger than the raw data itself, so we could be in some really big trouble here, but at this point I'm just guessing blind.
ram wrote:
I am confused what database type to use ldbm or bdb.
bdb!
Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
Try to upgrade to 2.3.40 and look if that solves your problem. Also you did not say anything about your Berkeley DB installation.
Ciao, Michael.
Michael Ströder wrote:
Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
Try to upgrade to 2.3.40 and look if that solves your problem. Also you did not say anything about your Berkeley DB installation.
In our case, we tried upgrading to 2.3.40, and we had a crash of a sort that has not been seen before, at least not very often. We've stepped back to 2.3.35 because we know at least something of what caused the failure there, and we know how to avoid at least that particular problem. We're still working on the details of exactly what is going wrong and why.
Brad Knowles wrote:
Michael Ströder wrote:
Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
Try to upgrade to 2.3.40 and look if that solves your problem. Also you did not say anything about your Berkeley DB installation.
In our case, we tried upgrading to 2.3.40, and we had a crash of a sort that has not been seen before, at least not very often. We've stepped back to 2.3.35 because we know at least something of what caused the failure there, and we know how to avoid at least that particular problem. We're still working on the details of exactly what is going wrong and why.
While ITS#5342 is still being investigated, I would recommend that everyone use 2.3.39 and not 2.3.40. Sorry for the trouble.
Howard Chu wrote:
While ITS#5342 is still being investigated, I would recommend that everyone use 2.3.39 and not 2.3.40. Sorry for the trouble.
Unfortunately, this is a pretty important production server, and there are a number of other groups involved.
In any normal upgrade, we have a fairly extensive proposal/discussion/consensus process we have to go through with all the stakeholders before we get into the test/qualification process, which has to happen before we can think about scheduling an outage to take down one of the production servers for an upgrade. As you can imagine, this is a fairly long and involved procedure. And I'm just starting to scratch the surface on this one.
In this particular case, we had jumped from 2.3.35 to 2.3.40 because there was a critical operational problem and we were looking for quick solutions that we could implement in a short period of time, and we bypassed all the normal processes -- which did not end up working for us.
Unless there is another critical problem that occurs with 2.3.35, I doubt we'll be going through all the normal processes to consider an upgrade to a newer version, at least not until after we've had more extensive consultation to ensure we're not doing lots of other stupid stuff elsewhere.
From what I can tell, other than the one operational problem we've identified and know how to work around, 2.3.35 seems to work okay, and I think we're likely to leave it alone until we know we've got something that will be a big improvement.
Thanks!
--On Thursday, January 31, 2008 3:56 PM -0600 Brad Knowles b.knowles@its.utexas.edu wrote:
Unless there is another critical problem that occurs with 2.3.35, I doubt we'll be going through all the normal processes to consider an upgrade to a newer version, at least not until after we've had more extensive consultation to ensure we're not doing lots of other stupid stuff elsewhere.
If your 2.3.35 servers can be accessed via a remote connection, anyone can crash them at any time. Is that considered critical?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
If your 2.3.35 servers can be accessed via a remote connection, anyone can crash them at any time. Is that considered critical?
So far as I know, they can't be accessed remotely by anywhere off campus, so that should at least mitigate the risk.
But I will mention this as a risk to management, and see if we can get the process started for upgrading to 2.3.39. Thanks!
Quanah Gibson-Mount wrote:
If your 2.3.35 servers can be accessed via a remote connection, anyone can crash them at any time. Is that considered critical?
Out of curiosity, can you point me at specific weaknesses in 2.3.35 that we should be concerned about? Are we talking about ITS#s 4923, 4925, 4938, 4966, or something else?
Is this something where they could only crash the server if they could get direct access to send malformed LDAP queries, or is this something that could potentially be abused through a third-party XSS-style attack?
Thanks!
--On Friday, February 01, 2008 12:46 PM -0600 Brad Knowles b.knowles@its.utexas.edu wrote:
Quanah Gibson-Mount wrote:
If your 2.3.35 servers can be accessed via a remote connection, anyone can crash them at any time. Is that considered critical?
Out of curiosity, can you point me at specific weaknesses in 2.3.35 that we should be concerned about? Are we talking about ITS#s 4923, 4925, 4938, 4966, or something else?
Is this something where they could only crash the server if they could get direct access to send malformed LDAP queries, or is this something that could potentially be abused through a third-party XSS-style attack?
There were a lot of bugs in 2.3.35, but basically if someone can send a query to the server, regardless of anonymous vs auth, they can crash it.
It is ITS#5119.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
In our case, we tried upgrading to 2.3.40, and we had a crash of a sort that has not been seen before, at least not very often. We've stepped back to 2.3.35 because we know at least something of what caused the failure there, and we know how to avoid at least that particular problem. We're still working on the details of exactly what is going wrong and why.
While I admit it's very hard (and very important) to retain a good S/N ratio...
One of the great things about using community software is that we can all help each other out, either directly ("we've analyzed this and found X") or indirectly ("we've noticed Y three times, which never happened before, just FYI for now" for pattern development), by sharing our progress in these matters. If you have anything of this sort to report, I'm sure it'd be welcomed here or in -devel as appropriate.
Aaron Richton wrote:
One of the great things about using community software is that we can all help each other out, either directly ("we've analyzed this and found X") or indirectly ("we've noticed Y three times, which never happened before, just FYI for now" for pattern development), by sharing our progress in these matters. If you have anything of this sort to report, I'm sure it'd be welcomed here or in -devel as appropriate.
I don't have full knowledge of the situation yet. I started this job last week, and it's taking time for me to get unprivileged access to the machines in question, and we're still waiting on word for when I'll get privileged access. Until then, I can do things like iostat, vmstat, prstat, netstat, etc... but I don't have direct access to any of the active production data files (I can't even cd to the directory where they're located), and there's limits in terms of what else I can do with the server.
I'll give you folks more information as I get it, and I'll be glad to share as much as I can. It will be incumbent upon you to tell me to shut up and go away, if I'm being too verbose. ;-)
Hi,
ram ram@netcore.co.in writes:
Hi,
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
ldbm is not an option!
my DB_CONFIG file is
[...]
set_cachesize 0 524288000 0
You should check wether the cachesize is sufficient. http://www.openldap.org/faq/data/cache/1072.html
set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 20485760 set_tmp_dir /tmp
# Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option).
set_flags DB_LOG_AUTOREMOVE set_flags DB_LOG_INMEMORY set_flags DB_TXN_NOSYNC
You should read http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_con...
to understand the flags.
-Dieter
On Thu, 2008-01-31 at 19:27 +0100, Dieter Kluenter wrote:
Hi,
ram ram@netcore.co.in writes:
Hi,
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
ldbm is not an option!
my DB_CONFIG file is
[...]
set_cachesize 0 524288000 0
You should check wether the cachesize is sufficient. http://www.openldap.org/faq/data/cache/1072.html
set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 20485760 set_tmp_dir /tmp
# Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option).
set_flags DB_LOG_AUTOREMOVE set_flags DB_LOG_INMEMORY set_flags DB_TXN_NOSYNC
You should read http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_con...
to understand the flags.
My db version seems to be messed up
When I run db_stat I get an error [root@netserv ldap]# db_stat -d dn2id.bdb db_stat: Program version 4.3 doesn't match environment version db_stat: DB_ENV->open: DB_VERSION_MISMATCH: Database environment version mismatch
The db4 rpm I have installed is "db4-4.3.29-9"
Should I upgrade the db4 rpm ??
-Dieter
When I run db_stat I get an error [root@netserv ldap]# db_stat -d dn2id.bdb db_stat: Program version 4.3 doesn't match environment version db_stat: DB_ENV->open: DB_VERSION_MISMATCH: Database environment version mismatch
The db4 rpm I have installed is "db4-4.3.29-9"
Should I upgrade the db4 rpm ??
That may or may not help. Whatever Sleepycat version you used to create dn2id.bdb (which is to say, the version slapd is linked against) doesn't match your db_* utilities. They have to match -- whether your upgrade would make them match or not is debatable.
So what can you do? The {b,h}db initialize functions print the Sleepycat version they use with LDAP_DEBUG_TRACE. i.e.,
bash$ slaptest -u -d trace 2>&1 | grep Sleepycat bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003)
So you can use that to find what version of db_* utilities you need to play along.
ram skrev, on 31-01-2008 11:13:
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
my DB_CONFIG file is
# Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment.
set_cachesize 0 524288000 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 20485760 set_tmp_dir /tmp
# Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option).
set_flags DB_LOG_AUTOREMOVE set_flags DB_LOG_INMEMORY set_flags DB_TXN_NOSYNC
This has been repeated to the point of boredom, nevertheless:
I'm a Red Hat admin and am running RHEL5.1 on a number of machines. RHEL5 is a dependable and stable operating system, as are by far most of the utilities it comprises. One RHEL5 offering to be avoided at all costs is openldap-*-2.3.27. Apart from anything else it is built with bdb 4.3.29 support. db4.3 has been condemned as unsuitable by the OpenLDAP developers. There are other reason too, but this is the most important.
I (and other Red Hat admins in the know) run Buchan Milne's alternative which comprise discrete, patched db-4.2.52 and can exist beside the RHEL5 offering. This is an utterly stable and dependable product; it is available at http://staff.telkomsa.net/packages/rhel5Server/openldap/.
You should always use bdb or hdb as DB, never ldbm.
Best,
--Tonni
On Fri, 2008-02-01 at 06:13 +0100, Tony Earnshaw wrote:
ram skrev, on 31-01-2008 11:13:
I am using ldap for authentication & addressbook for a large mailserver setup with around 300k users ( this will grow to 500k )
The ldap server is a 8GB Ram box with RHEL-5 with openldap-servers-2.3.27-5
I am confused what database type to use ldbm or bdb. Currently I have the users on bdb with lot of problems. The ldap server dies all of a sudden and I have to recover the data to get it started
my DB_CONFIG file is
# Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment.
set_cachesize 0 524288000 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 20485760 set_tmp_dir /tmp
# Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option).
set_flags DB_LOG_AUTOREMOVE set_flags DB_LOG_INMEMORY set_flags DB_TXN_NOSYNC
This has been repeated to the point of boredom, nevertheless:
I'm a Red Hat admin and am running RHEL5.1 on a number of machines. RHEL5 is a dependable and stable operating system, as are by far most of the utilities it comprises. One RHEL5 offering to be avoided at all costs is openldap-*-2.3.27. Apart from anything else it is built with bdb 4.3.29 support. db4.3 has been condemned as unsuitable by the OpenLDAP developers. There are other reason too, but this is the most important.
I (and other Red Hat admins in the know) run Buchan Milne's alternative which comprise discrete, patched db-4.2.52 and can exist beside the RHEL5 offering. This is an utterly stable and dependable product; it is available at http://staff.telkomsa.net/packages/rhel5Server/openldap/.
Will I have to remove my current db4* rpms to install these ?
You should always use bdb or hdb as DB, never ldbm.
Best,
--Tonni
I (and other Red Hat admins in the know) run Buchan Milne's alternative which comprise discrete, patched db-4.2.52 and can exist beside the RHEL5 offering. This is an utterly stable and dependable product; it is available at http://staff.telkomsa.net/packages/rhel5Server/openldap/.
Will I have to remove my current db4* rpms to install these ?
No. Buchan's RPMs "can exist beside the RHEL5 offering" after all.
ram skrev, on 01-02-2008 14:53:
[...]
I (and other Red Hat admins in the know) run Buchan Milne's alternative which comprise discrete, patched db-4.2.52 and can exist beside the RHEL5 offering. This is an utterly stable and dependable product; it is available at http://staff.telkomsa.net/packages/rhel5Server/openldap/.
Will I have to remove my current db4* rpms to install these ?
As Aaron wrote, no. If you do install Buchan's rpms it's important to know that he separates it from Red Hat's by tacking '2.3' on to the end of everything, including the man pages. So slapd is called slapd2.3, ldapsearch is called ldapsearch2.3, /usr/bin/slapd_db_recover2.3, etc.
Even the libraries (which are in the normal place) have different sonames, e.g. /usr/lib/libldap_r-2.3.so.0, /usr/lib/liblber-2.3.so.0 etc. Anything you later build using OL libraries will find these during the build, or it will find the Red Hat libraries if you still have them.
--Tonni
Tony Earnshaw skrev, on 01-02-2008 16:20:
[...]
Will I have to remove my current db4* rpms to install these ?
As Aaron wrote, no. If you do install Buchan's rpms it's important to know that he separates it from Red Hat's by tacking '2.3' on to the end of everything, including the man pages. So slapd is called slapd2.3, ldapsearch is called ldapsearch2.3, /usr/bin/slapd_db_recover2.3, etc.
with all this I regard all subsequent posts, including my own, regarding Red Hat's miscreated (and mostly miscreant) OpenLDAP stuff as being "earth to earth, dust to dust" etc. AKA OT.
Here's the link: "ram@netcore.co.in" "tonni@hetnet.nl", wait for it to mature to Google.
IOW I wish to have nothing further to do on this list with Red Hat OpenLDAP or alternatives to it, Buchan rules until Red Hat proves the opposite.
--Tonni
Best,
Tony Earnshaw:
[...]
If you do install Buchan's rpms it's important to know that he separates it from Red Hat's by tacking '2.3' on to the end of everything, including the man pages. So slapd is called slapd2.3, ldapsearch is called ldapsearch2.3, /usr/bin/slapd_db_recover2.3, etc.
Even the libraries (which are in the normal place) have different sonames, e.g. /usr/lib/libldap_r-2.3.so.0, /usr/lib/liblber-2.3.so.0
It's been my experience that while this is true on RH4, if you have RH5, Buchan's RPMs do in fact replace the RH ones. The only one you can install along side is the 2.4 branch. In fact, if you look at the files in the referenced url: http://staff.telkomsa.net/packages/rhel5Server/openldap/i386/ you will see that only the 2.4 branch has anything tacked on, the 2.3 branch is named the same as RH's packages and will replace them--but so far it works great, and the upgrade was flawless (you have to rebuild the DB since it is using an older [better] version of bdb), and yes the package RH ships is an embarrassment.
-Ryan
---- Ryan Horrisberger rhorrisb@ssc.wisc.edu
On Fri, Feb 01, 2008 at 03:24:50PM -0600, Ryan Horrisberger wrote:
same as RH's packages and will replace them--but so far it works great, and the upgrade was flawless (you have to rebuild the DB since it is using an older [better] version of bdb), and yes the package RH ships is an embarrassment.
I'm curious: why do all these people who purchased (expensive) RH server licenses don't open bug reports with Redhat about their openldap packages?
--On February 1, 2008 7:56:03 PM -0200 Andreas Hasenack ahasenack@terra.com.br wrote:
I'm curious: why do all these people who purchased (expensive) RH server licenses don't open bug reports with Redhat about their openldap packages?
RH is not building OpenLDAP for running as a server. RH is building OpenLDAP for providing client libraries. They spend months testing that all of the things that link to these libraries work. To upgrade/change the versions of those libraries would take many months of testing and cost lots of money. There are basically two very different sets of goals at work. (1) The goal of RH to provide a set of stable client libraries and (2) the goal of LDAP server admins to have a stable LDAP server.
Those desiring (2) need to build and maintain their own packages, or rely on the packages of another who has the same goal as they do. This situation is not unique to RH, either. It just happens that its wide-scale usage brings this problem up with their packages more than other vendors.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hello,
That was a great explation.Simple and Succinct.Too bad it did not come from stupid RH folks.I am sorry I did not get it. What exactly you mean by "RH is not building OpenLADP for running as a server"? I feel like I am being cheated by RH for duping me to buy expensive RH boxes. Red Hat support is terrible as far as LDAP is concerd.I wish there will be a update only subscription available for RHEL.
Thanks
Joy
On 2/2/08, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On February 1, 2008 7:56:03 PM -0200 Andreas Hasenack ahasenack@terra.com.br wrote:
I'm curious: why do all these people who purchased (expensive) RH server licenses don't open bug reports with Redhat about their openldap packages?
RH is not building OpenLDAP for running as a server. RH is building OpenLDAP for providing client libraries. They spend months testing that all of the things that link to these libraries work. To upgrade/change the versions of those libraries would take many months of testing and cost lots of money. There are basically two very different sets of goals at work. (1) The goal of RH to provide a set of stable client libraries and (2) the goal of LDAP server admins to have a stable LDAP server.
Those desiring (2) need to build and maintain their own packages, or rely on the packages of another who has the same goal as they do. This situation is not unique to RH, either. It just happens that its wide-scale usage brings this problem up with their packages more than other vendors.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On February 2, 2008 6:08:37 PM +0530 Count Of Dracula countofdracula@gmail.com wrote:
Hello,
That was a great explation.Simple and Succinct.Too bad it did not come from stupid RH folks.I am sorry I did not get it. What exactly you mean by "RH is not building OpenLADP for running as a server"?
I mean exactly what I wrote:
RH is not building OpenLDAP for running as a server. RH is building OpenLDAP for providing client libraries. They spend months testing that all of the things that link to these libraries work. To upgrade/change the versions of those libraries would take many months of testing and cost lots of money.
I.e., RH wants to ensure that everything that links against the OpenLDAP libraries (perl modules, PHP, apache, NSS_ldap, PAM_ldap, just to name a few), work against a known release. So they don't maintain the packages to the quality necessary for an LDAP administrator to use them.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount skrev, on 02-02-2008 22:23:
[...]
I mean exactly what I wrote:
RH is not building OpenLDAP for running as a server. RH is building OpenLDAP for providing client libraries. They spend months testing that all of the things that link to these libraries work. To upgrade/change the versions of those libraries would take many months of testing and cost lots of money.
I.e., RH wants to ensure that everything that links against the OpenLDAP libraries (perl modules, PHP, apache, NSS_ldap, PAM_ldap, just to name a few), work against a known release. So they don't maintain the packages to the quality necessary for an LDAP administrator to use them.
As far as that goes, it's worth noting that Red Hat is now financially committed to (Fedora|Red Hat) Directory Server and has little interest in supporting any OpenLDAP server. OTOH it's obvious that the clients/libraries should work properly.
--Tonni
I guess RH does not want to promote OpenLDAP as *the* directory server or identity management solution. They want to force RHDS for it.
One sign of their inking is FreeIPA project.
Joy
On 2/3/08, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On February 2, 2008 6:08:37 PM +0530 Count Of Dracula countofdracula@gmail.com wrote:
Hello,
That was a great explation.Simple and Succinct.Too bad it did not come from stupid RH folks.I am sorry I did not get it. What exactly you mean by "RH is not building OpenLADP for running as a server"?
I mean exactly what I wrote:
RH is not building OpenLDAP for running as a server. RH is building OpenLDAP for providing client libraries. They spend months testing that all of the things that link to these libraries work. To upgrade/change the versions of those libraries would take many months of testing and cost lots of money.
I.e., RH wants to ensure that everything that links against the OpenLDAP libraries (perl modules, PHP, apache, NSS_ldap, PAM_ldap, just to name a few), work against a known release. So they don't maintain the packages to the quality necessary for an LDAP administrator to use them.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
On Sunday 03 February 2008 09:06:02 Count Of Dracula wrote:
I guess RH does not want to promote OpenLDAP as *the* directory server or identity management solution. They want to force RHDS for it.
One sign of their inking is FreeIPA project.
I note that with OpenLDAP, Heimdal, sudo with LDAP support, eash, FreeRADIUS and tac_plus I already have everything (and more) in their roadmap targeting August 2008, except for "AD Sync" (for which there is a patch, but I personally have some requirements I haven't had the time to hack onto it) and "Machine policy" (but our company mandates proprietary software to do this on all OS platforms anyway).
Right, I don't (yet) have a GUI for all of this (I was working on DNS and DHCP maintenance in LDAP last time I had time ...), but I will soon.
Regards, Buchan
This thread has gone off-topic and is now closed. (This list is for discussion of technical issues specific to OpenLDAP issues.)
-- Kurt, your moderator
On Fri, 1 Feb 2008, Quanah Gibson-Mount wrote:
I'm curious: why do all these people who purchased (expensive) RH server licenses don't open bug reports with Redhat about their openldap packages?
RH is not building OpenLDAP for running as a server. [...]
Seems to me they would server the community better by not shipping a server configuration, but I suppose that would be an admission that their software isn't up to scratch.
ahasenack@terra.com.br wrote:
I'm curious: why do all these people who purchased (expensive) RH server licenses don't open bug reports with Redhat about their openldap packages?
Quanah Gibson-Mount wrote:
RH is not building OpenLDAP for running as a server.
Also, Red Hat has a conflict of interest--they sell Red Hat Directory Server which for support it is ~$15,000/year per master and ~$3,000/year per slave. They clearly wouldn't be too happy if everyone was running OpenLDAP.
-Ryan ---- Ryan Horrisberger rhorrisb@ssc.wisc.edu SSCC Developer/Network Admin 608.262.8263
openldap-software@openldap.org
-
Aaron Richton -
Andreas Hasenack -
Brad Knowles -
Buchan Milne -
Count Of Dracula -
Dave Horsfall -
Dieter Kluenter -
Howard Chu -
Kurt Zeilenga -
Michael Ströder -
Quanah Gibson-Mount -
ram -
Ryan Horrisberger -
Tony Earnshaw