7 ms·

This is a real shame, Howard is an absolute asset not just for his LDAP work, but for the LMDB database engine borne from it and the ton of supporting technical

by _wmd 8y ago

This is a real shame, Howard is an absolute asset not just for his LDAP work, but for the LMDB database engine borne from it and the ton of supporting technical materials surrounding it. Symas (Chu's consulting company) have a far clearer take on the matter: https://symas.com/message-president-regarding-red-hat-suse-removing-openldap-linux-distributions/ https://symas.com/message-president-regarding-red-hat-suse-r... , seems this is entirely motivated by upsell. Red Hat's move here is a bit like taking a trusted well-supported tool like bash and replacing it with some shit branch of ksh from 1984, and forcing people to pay for it.

amyjess 8y ago
That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". It is simply one company attacking a competitor's product. And of course the article contains direct links to both a page where you can buy support packages for OpenLDAP and something called "OpenLDAP Gold".
- reqa 8y ago
  To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...
- _wmd 8y ago
  That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine. There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all, they have been the exclusive maintainers for OpenLDAP for many, many years, and it is of course the exact same model used for 389 DS. Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any.
  - amyjess 8y ago
    > There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.
  - Twirrim 8y ago
    > That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.
  - MattSteelblade 8y ago
    Let's break this down as an external party that uses neither products: > "That is not an opinion based on any marketing material - 389DS is an unreliable dog" The press statement you linked to reads as an advertisement. You posit a statement as fact without any information to back it up. Why is it so unreliable? > "and even today it's still built on top of an Oracle-owned database engine." Whether the product is built on an Oracle-owned database engine or not, is not a reflection of the stability of a product. It's clear that you mention this as a negative to reinforce your position, but while technically correct, looking through the history of the product, it was developed by Sun and acquired by Red Hat in 2005, years before Sun was acquired by Oracle. > "There is no need to attack Symas" @amyjess's comment simply declared your linked article as biased, which it clearly is. This is not an attack. > "Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any." Why do we have to assume the product is broken and find proof that it is not? You have posited an opinion without any sources to back it up; the burden of proof lies with you. (Edited for formatting changes)
    - _wmd 8y ago
      You make a fair point, it is hard to read as a bystander. However I disagree the burden of proof lies with me. I'm not here to convince you of anything, if you want to be sure of something, you must put the effort in like everyone else. Despite that.. Just focusing on storage backends - if you have ever deployed anything that uses BDB (Subversion, Apache, 389, Exim, god knows how many more), one thing you'll become quickly familiar with is it's amazing ability to randomly get into an unusable state, despite an otherwise healthy and unrebooted machine, despite no administrative interference, despite apparently no users or no load at all (e.g. on a Monday morning in a ~10 user office). My opinions are based on having worked in infrastructure since ~2002, having deployed BDB many times, and having spent many hours trying to figure out how to get an app unbricked without losing its underlying database. I spent time as an administrator at several companies where Subversion would go down monthly or worse because BDB locking would get messed up like this, and the result is always yet another tarball of the previous database just in case poking it completely corrupts the install. I've had to handle emergency calls because Exim was spewing permanent errors to customers due to a BDB lookup randomly starting to fail. In other words over the years, like many before me, and for very good reasons, I've come to consider BDB a red flag, and where it goes trouble goes. Put in simpler terms, on a scale of software quality running from 10 ("excellent") to 0 ("crapware"), BDB sits somewhere around -7 ("you had one job"). But don't take my word for it, look at the list of common hazards listed here: https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/debug/common.html https://web.stanford.edu/class/cs276a/projects/docs/berkeley... Despite that, having deployed OpenLDAP and suffered through its.. suffering.. documentation on several occasions going back ~15 years, including during periods when BDB was the default, post installation I have never once seen OpenLDAP going down. It's very solid software, in spite of prior database engine hindrances. LMDB is of course no panacea, but having spent years with it as a developer (and maintainer of py-lmdb), I can say categorically that I would not pick BDB over it in any situation, not just due to performance concerns (which are great), but because the design is so damned simple (a single write lock, a single lock file) that I have never once seen it self-corrupt or get wedged in ways that I would have struggled to deal with in my time served an administrator.
- gargravarr 8y ago
  I agree with the bias aspect, as soon as they mentioned Univention I realised it was a sales pitch. Feels like ambulance-chasing!
- ti_ranger 8y ago
  > That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". The article says: "This is a guest post from Univention." Howard Chu's company is Symas, not Univention (a different consulting company who does provide support contracts for open-source software including OpenLDAP). Yes, there is a link to a blog post by Symas that relates to the announcement, but not in the article being discussed here. If you meant the Symas blog post, you should be more clear on that.
  - amyjess 8y ago
    I was directly replying to a comment that linked the Symas post and recommended it over OP's article. I don't think I could've been more clear.
    - reqa 8y ago
      Ok, thanks for clarifying your comment!
evol262 8y ago
The point of this is that OpenLDAP, while an ok solution which has stood the test of time, isn't well integrated with anything a systems vendor would want to do with it. Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. 389 doesn't have any of those problems. Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large.
- hyc_symas 8y ago
  > Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. That's nonsense. OpenLDAP has had seamless integration with Heimdal Kerberos for literally decades. And the support for running a KDC on top of LDAP was written by OpenLDAP contributors (Luke Howard and myself). https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-ldap.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-l... as an aside, I also wrote the support for using the KDC on top of LMDB https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-mdb.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-m... As for duct tape and random LDIFs - again, Symas Corp and the OpenLDAP Project were the only guys funding efforts to standardize this integration. http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema-for-kdc-td34649.html http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema... https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ The fact that Kerberos works well on top of LDAP today is because the OpenLDAP Project laid the groundwork for that to happen. > Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large. RedHat has never tried to contribute anything large to OpenLDAP. And large contributions aren't a problem. We have entirely new DB backends still being contributed by 3rd parties. E.g. the WiredTiger backend http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=servers/slapd/back-wt;h=5ad3be00bfb1e8beea31e213d8159361e050ec00;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tr...
- briffle 8y ago
yellowapple 8y ago
What do you mean forcing people to pay for it? 389DS is under the GPL. Red Hat's branded version of it is indeed not free-as-in-beer, but the only thing that gets you is Red Hat branding and a support contract, and it's still (IIRC) under the GPL. Also not sure where you're getting the "shit branch of ksh from 1984" characterization. Looks actively-developed to me. Both 389DS and OpenLDAP are slapd forks, so the simile doesn't really work anyway. (Side note: the notion of bash somehow being "trusted" relative to ksh is a little weird considering ksh's continued use in OpenBSD and bash's well-publicized security holes with hip names like Shellshock)
throwaway_ldap 8y ago
Those who've been following OpenLDAP-technical long enough know that the project's support policy is very much at odds with the way in which classic Linux distros work. The recommendation from the maintainers has always (or at least for a long time) been that one should skip distro-provided server packages and install the latest release from tarballs or third-party packages, with the implication, or sometimes rather direct assertions, that the distros are doing a bad job of maintaining and packaging the server. The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) So, my impression is that OpenLDAP and RH never had good cooperation. Since LDAP is a rather niche protocol/ecosystem these days (a pity, IMO, but that's how it is), I'm not surprised that RH felt confident in ditching a component which they couldn't maintain to anyone's satisfaction, especially given that they have their own server, which is not as good but good enough.
- hyc_symas 8y ago
  RH's insistence on using MozNSS was certainly a point of contention, since MozNSS was absolutely unsuitable for the purpose and unfit for use. http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-NSS-tp196021p196029.html http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-... https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Not that we didn't try. We went out of our way to support that crap. Despite the inadequacies of the API I wrote the code to support it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=history;f=libraries/libldap/tls_m.c;h=95bcd3cad62e2c73de56b47e84aa7025b3b7d0fd;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=hi... We bent over backwards to support their crap. Which is more than can be said in return. https://bugzilla.mozilla.org/show_bug.cgi?id=480174 https://bugzilla.mozilla.org/show_bug.cgi?id=480174
- ti_ranger 8y ago
  > The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) But, IIRC, the Debian developers did some work on addressing the gaps, whereas the RH/moznss guys just put their fingers in their ears and said "nobody needs well-performing SSL handling in a server context like OpenSSL provides", and all of their contributions focused purely on the OpenLDAP client-side. For a long time, I provided builds of OpenLDAP for RHEL3/4/5, and finally on RHEL7 RH's packages were recent enough and didn't have too many mozNSS-related problems to be usable out-the-box in our large OpenLDAP deployment. I'll have to give the guys who are still there a heads-up and consider reviving my RPM rebuilds for RHEL.
jiveturkey 8y ago
It’s not a shame at all. This is fair and square competition. Contrary to Martin’s (Symas) statements, openldap is a rapidly aging product. No one without an openldap legacy wants to deploy this beast today (no one in their right mind). Many of the 2.5 changes are misguided. Performance sounds great, but no, the right place for directory configuration is not in fact inside the directory itself. etc. The blog probably directly tells us the motivation for a response at all: external pressure to Symas.
- reqa 8y ago
  See https://lwn.net/Articles/755674/ https://lwn.net/Articles/755674/ and https://lwn.net/Articles/755673/ https://lwn.net/Articles/755673/ . Having cn=config is very useful for config parameter changes without downtime (e.g. log level) and for replication. But I agree that file based config is more convenient for boot strapping.
- amaccuish 8y ago
  Configuration can be find in the DIT, Active Directory does it quite well. But you're right, even say with Active Directory, certain key knobs are outside of the DIT. The problem I had with OpenLDAP was that if you fucked up, and it wouldn't start, how are you supposed to be able to fix it if the config requires the service to be running. It wasn't very well thought through...
  - reqa 8y ago
    This is on the road map to 2.5, as stated e.g. in https://lwn.net/Articles/755207/ https://lwn.net/Articles/755207/
deleted 8y ago
[deleted]

by _wmd 8y ago

amyjess 8y ago

That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". It is simply one company attacking a competitor's product. And of course the article contains direct links to both a page where you can buy support packages for OpenLDAP and something called "OpenLDAP Gold".

reqa 8y ago
To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...
_wmd 8y ago
That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine. There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all, they have been the exclusive maintainers for OpenLDAP for many, many years, and it is of course the exact same model used for 389 DS. Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any.
- amyjess 8y ago
  > There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.
- Twirrim 8y ago
  > That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.
- MattSteelblade 8y ago
  Let's break this down as an external party that uses neither products: > "That is not an opinion based on any marketing material - 389DS is an unreliable dog" The press statement you linked to reads as an advertisement. You posit a statement as fact without any information to back it up. Why is it so unreliable? > "and even today it's still built on top of an Oracle-owned database engine." Whether the product is built on an Oracle-owned database engine or not, is not a reflection of the stability of a product. It's clear that you mention this as a negative to reinforce your position, but while technically correct, looking through the history of the product, it was developed by Sun and acquired by Red Hat in 2005, years before Sun was acquired by Oracle. > "There is no need to attack Symas" @amyjess's comment simply declared your linked article as biased, which it clearly is. This is not an attack. > "Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any." Why do we have to assume the product is broken and find proof that it is not? You have posited an opinion without any sources to back it up; the burden of proof lies with you. (Edited for formatting changes)
  - _wmd 8y ago
    You make a fair point, it is hard to read as a bystander. However I disagree the burden of proof lies with me. I'm not here to convince you of anything, if you want to be sure of something, you must put the effort in like everyone else. Despite that.. Just focusing on storage backends - if you have ever deployed anything that uses BDB (Subversion, Apache, 389, Exim, god knows how many more), one thing you'll become quickly familiar with is it's amazing ability to randomly get into an unusable state, despite an otherwise healthy and unrebooted machine, despite no administrative interference, despite apparently no users or no load at all (e.g. on a Monday morning in a ~10 user office). My opinions are based on having worked in infrastructure since ~2002, having deployed BDB many times, and having spent many hours trying to figure out how to get an app unbricked without losing its underlying database. I spent time as an administrator at several companies where Subversion would go down monthly or worse because BDB locking would get messed up like this, and the result is always yet another tarball of the previous database just in case poking it completely corrupts the install. I've had to handle emergency calls because Exim was spewing permanent errors to customers due to a BDB lookup randomly starting to fail. In other words over the years, like many before me, and for very good reasons, I've come to consider BDB a red flag, and where it goes trouble goes. Put in simpler terms, on a scale of software quality running from 10 ("excellent") to 0 ("crapware"), BDB sits somewhere around -7 ("you had one job"). But don't take my word for it, look at the list of common hazards listed here: https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/debug/common.html https://web.stanford.edu/class/cs276a/projects/docs/berkeley... Despite that, having deployed OpenLDAP and suffered through its.. suffering.. documentation on several occasions going back ~15 years, including during periods when BDB was the default, post installation I have never once seen OpenLDAP going down. It's very solid software, in spite of prior database engine hindrances. LMDB is of course no panacea, but having spent years with it as a developer (and maintainer of py-lmdb), I can say categorically that I would not pick BDB over it in any situation, not just due to performance concerns (which are great), but because the design is so damned simple (a single write lock, a single lock file) that I have never once seen it self-corrupt or get wedged in ways that I would have struggled to deal with in my time served an administrator.
gargravarr 8y ago
I agree with the bias aspect, as soon as they mentioned Univention I realised it was a sales pitch. Feels like ambulance-chasing!
ti_ranger 8y ago
> That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". The article says: "This is a guest post from Univention." Howard Chu's company is Symas, not Univention (a different consulting company who does provide support contracts for open-source software including OpenLDAP). Yes, there is a link to a blog post by Symas that relates to the announcement, but not in the article being discussed here. If you meant the Symas blog post, you should be more clear on that.
- amyjess 8y ago
  I was directly replying to a comment that linked the Symas post and recommended it over OP's article. I don't think I could've been more clear.
  - reqa 8y ago
    Ok, thanks for clarifying your comment!

evol262 8y ago

The point of this is that OpenLDAP, while an ok solution which has stood the test of time, isn't well integrated with anything a systems vendor would want to do with it. Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. 389 doesn't have any of those problems. Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large.

hyc_symas 8y ago
> Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. That's nonsense. OpenLDAP has had seamless integration with Heimdal Kerberos for literally decades. And the support for running a KDC on top of LDAP was written by OpenLDAP contributors (Luke Howard and myself). https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-ldap.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-l... as an aside, I also wrote the support for using the KDC on top of LMDB https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-mdb.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-m... As for duct tape and random LDIFs - again, Symas Corp and the OpenLDAP Project were the only guys funding efforts to standardize this integration. http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema-for-kdc-td34649.html http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema... https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ The fact that Kerberos works well on top of LDAP today is because the OpenLDAP Project laid the groundwork for that to happen. > Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large. RedHat has never tried to contribute anything large to OpenLDAP. And large contributions aren't a problem. We have entirely new DB backends still being contributed by 3rd parties. E.g. the WiredTiger backend http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=servers/slapd/back-wt;h=5ad3be00bfb1e8beea31e213d8159361e050ec00;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tr...
briffle 8y ago

yellowapple 8y ago

What do you mean forcing people to pay for it? 389DS is under the GPL. Red Hat's branded version of it is indeed not free-as-in-beer, but the only thing that gets you is Red Hat branding and a support contract, and it's still (IIRC) under the GPL. Also not sure where you're getting the "shit branch of ksh from 1984" characterization. Looks actively-developed to me. Both 389DS and OpenLDAP are slapd forks, so the simile doesn't really work anyway. (Side note: the notion of bash somehow being "trusted" relative to ksh is a little weird considering ksh's continued use in OpenBSD and bash's well-publicized security holes with hip names like Shellshock)

throwaway_ldap 8y ago

Those who've been following OpenLDAP-technical long enough know that the project's support policy is very much at odds with the way in which classic Linux distros work. The recommendation from the maintainers has always (or at least for a long time) been that one should skip distro-provided server packages and install the latest release from tarballs or third-party packages, with the implication, or sometimes rather direct assertions, that the distros are doing a bad job of maintaining and packaging the server. The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) So, my impression is that OpenLDAP and RH never had good cooperation. Since LDAP is a rather niche protocol/ecosystem these days (a pity, IMO, but that's how it is), I'm not surprised that RH felt confident in ditching a component which they couldn't maintain to anyone's satisfaction, especially given that they have their own server, which is not as good but good enough.

hyc_symas 8y ago
RH's insistence on using MozNSS was certainly a point of contention, since MozNSS was absolutely unsuitable for the purpose and unfit for use. http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-NSS-tp196021p196029.html http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-... https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Not that we didn't try. We went out of our way to support that crap. Despite the inadequacies of the API I wrote the code to support it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=history;f=libraries/libldap/tls_m.c;h=95bcd3cad62e2c73de56b47e84aa7025b3b7d0fd;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=hi... We bent over backwards to support their crap. Which is more than can be said in return. https://bugzilla.mozilla.org/show_bug.cgi?id=480174 https://bugzilla.mozilla.org/show_bug.cgi?id=480174
ti_ranger 8y ago
> The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) But, IIRC, the Debian developers did some work on addressing the gaps, whereas the RH/moznss guys just put their fingers in their ears and said "nobody needs well-performing SSL handling in a server context like OpenSSL provides", and all of their contributions focused purely on the OpenLDAP client-side. For a long time, I provided builds of OpenLDAP for RHEL3/4/5, and finally on RHEL7 RH's packages were recent enough and didn't have too many mozNSS-related problems to be usable out-the-box in our large OpenLDAP deployment. I'll have to give the guys who are still there a heads-up and consider reviving my RPM rebuilds for RHEL.

jiveturkey 8y ago

It’s not a shame at all. This is fair and square competition. Contrary to Martin’s (Symas) statements, openldap is a rapidly aging product. No one without an openldap legacy wants to deploy this beast today (no one in their right mind). Many of the 2.5 changes are misguided. Performance sounds great, but no, the right place for directory configuration is not in fact inside the directory itself. etc. The blog probably directly tells us the motivation for a response at all: external pressure to Symas.

reqa 8y ago
See https://lwn.net/Articles/755674/ https://lwn.net/Articles/755674/ and https://lwn.net/Articles/755673/ https://lwn.net/Articles/755673/ . Having cn=config is very useful for config parameter changes without downtime (e.g. log level) and for replication. But I agree that file based config is more convenient for boot strapping.
amaccuish 8y ago
Configuration can be find in the DIT, Active Directory does it quite well. But you're right, even say with Active Directory, certain key knobs are outside of the DIT. The problem I had with OpenLDAP was that if you fucked up, and it wouldn't start, how are you supposed to be able to fix it if the config requires the service to be running. It wasn't very well thought through...
- reqa 8y ago
  This is on the road map to 2.5, as stated e.g. in https://lwn.net/Articles/755207/ https://lwn.net/Articles/755207/

deleted 8y ago

[deleted]