RedHat and SUSE Withdrawing Support for OpenLDAP
ostechnix.com
ostechnix.com
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.
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".
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.
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.
...
>they have been the exclusive maintainers for OpenLDAP for many, many years,
I think your critical source analysis skills might need some brushing off.
> "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)
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/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.
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.
I don't think I could've been more clear.
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.
This is a poor excuse. While the flat file (slapd.conf) is deprecated in 2.4, it still works fine if you don't mind restarting to apply changes, and you can easily switch from slapd.conf to back-config (but not the other way) when you are finished getting a new stack up.
I encourage you to look at things from the perspective of someone new to LDAP, or maybe someone new to directory services in general.
LDAP already introduces its own terminology which is a little confusing at first. And it is an object database, which will be less familiar to many people than a relational database. Add to that the 'database number' thing when it might not be clear to beginners what is going into which one and why.
It's not something you're going to be able to get setup and running in an afternoon, and that's fine, some things are too complex to just be thrown together.
Even when I worked out how to do online config, if I made a mistake and the service wouldn't start, I couldn't work out how to manually revert the change so the service could start again.
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-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-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... 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=tr...
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)
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.
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.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725091
> Distribution packages are not meant to be used for production services.
You have to have balls to put in a ticket something that basically amounts to: "what you are doing is useless, people should be recompiling everything".
And while while searching for this ticket, I also can across a few others like that. But at least, there are active on downstream tickets...
http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-... https://bugzilla.redhat.com/show_bug.cgi?id=502133 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=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
The blog probably directly tells us the motivation for a response at all: external pressure to Symas.
The initial deployment used Sun Directory Server Enterprise Edition (Sun DSEE, now Oracle DSEE) but when Oracle bought Sun we had conversations with Oracle's product team where they explicitly stated that going forward Sun DSEE would be discontinued and replaced by Oracle's competing (but from our perspective, inferior) product.
Contrary to most of the posters here I had no significant trouble figuring out OpenLDAP and found the documentation complete. The main pain points I ran into were: - OpenLDAP was trying to move configuration inside the DIT, which made system administration harder - I ran into some bugs with MDB on Solaris/UltraSPARC before it was officially announced - I ran into some bugs, which the OpenLDAP team fixed
In a later job, I was supporting a customer who purcashed RedHat Directory Services (RHDS) and therefore they wanted to use this in preference to OpenLDAP, but it conveyed no advantages, and had worse characteristics and licensing requirements with regards to multi-master replication. The reason the customer purchased RHDS was because their "Solution Architect" team thought they could use it to integrate with Active Directory authentication. However, RHDS's integration mechanism required that something be installed on all Active Directory servers (of which there were around 200, managed by various other companies) this plan was not feasible. Instead, I created a PAM module and used RHDS's "pam_tally" to pass through authentication attempts. This was not as good as could be done on OpenLDAP, however, because pam_tally creates a lock in RHDS and no authentication could happen while it was authenticating -- leading to a few nation-wide lockouts while I figured this undocumented feature out.
Sadly, LDAP isn't the most accessible system in the world and I only managed to set it up using FreeIPA, which is based no the 389 system mentioned in the article.
Most advice online around LDAP seems to amount to "ask your sysadmin", which isn't terribly useful either when I'm the sysadmin.
I hope 389DS will make LDAP a bit easier for newcomers like me.
OpenLDAP is a solid piece of software, no doubt, but there's one critical problem - most of the guides are third-party because the OpenLDAP documentation has been pretty lacking for a long time, and those guides are usually from the era before the entire thing was redesigned around OLC and LDIF! Adapting the guides is beyond irritating. I'm now at the stage where I have the schema defined and I no longer want to touch it, /ever/!
I could be wrong, but it's a common pattern.
[1] - https://access.redhat.com/solutions/2440481
>Important: Starting with Red Hat Enterprise Linux 7.4, the openldap-servers package has been deprecated and will not be included in a future major release of Red Hat Enterprise Linux.
Given the source of the article, they're not looking to remove confusion, they're looking to benefit from it.
...
> This is a guest post from Univention.
1) I need support for both RFC2307 and RFC2307bis. I haven't found any good documentation on how to set these up from scratch with 389DS where it's fairly trivial to make them work together with OpenLDAP and the memberof overlay.
2) I also have a need for an equivalent of the Tacacs schema that works with the mavis-Tacacs fork that Google maintains. Will this schema work with 389DS?
3) Same goes for the sudo.schema that is provided with sudo - does this work with 389DS?
4) Same goes for the ppolicy.schema (password policy) schema (ppolicy overlay) and memberof overlay. What are the equivalents of these for 389DS?
5) multi-master replication - OpenLDAP makes this a breeze, but not so sure with 389DS.
Finding information about how to implement these things from scratch seems extremely hard for 389DS. Granted, it was also hard for OpenLDAP, but that work is behind me now. I have serious misgivings about trying to reimplement all of this on 389DS within my given timeframe.
Other things that irk me about this decision:
a) I really dislike the Java console - doesn't feel like it changed much since the 1990's. It's still slow, ugly and doesn't feel like it integrates well.
b) feels like a weird choice to drop the openldap-server packages but not the openldap-clients package. Are they going to provide a replacement for the OpenLDAP client libraries eventually as well? Is there even a good alternative (ie. API compatible and replacements for all the command line utilities) to openldap-clients?
While it seems like an easy decision to move on the surface, most OpenLDAP deployments have a massive amount of customisations to make all the third-party applications work, and 389DS making those kind of migrations easy doesn't currently seem like one of its strong selling points.
They have no choice here, they use OpenLDAP's libraries. Mozilla/Netscape's own LDAP SDK has been unmaintained for more than a decade; it's abandonware.
It's probably one of the most reliable nosql DB out there. And you can actually implement schemas to ensure data formatting \o/ (provided you like OIDs...).
It can support quite rich ACLs, but those are a little hard to debug and fix. But it's nice it is there.
You also have an interesting query language using polish notations (okay, I prefer to slapcat the complete directory and do '|less' or '|grep' if I've direct access to the server and if it's not too big, I could never remember the options names in ldapsearch).
Lastly the ldif syntax is so great, I always have to google it even for the most basic edits...
More seriously, ldap is somewhat painful to deploy:
* Indeed the documentation is a bit lacking, the zytrax one is great but somewhat dated (specially with the cn=config paradigm).
* If you are doing complex setups like n-way multi-masters replication the documentation is somewhat verbose and really hard to understand (https://www.openldap.org/doc/admin24/replication.html). Generally it involves a lot of trial and errors in a lab to figure it out.
* There can be traps if you are not aware of the internals. For example, in one of our deployments we were maintaining large groups, and batch updates were taking a really long time. After digging, I finally understood why: each time you add or remove an entry in a group, it rewrites the complete group entry (at least with the BDB backend), rewritting 100000 entries each time you update one is somewhat costly... Not sure if it's still the case with the lmdb backend however.
* The source code is not really easy to read in my opinion. I did try it once (debugging the issue mentioned above), but was not successful at roughly understanding how it worked from reading the source code, at least in the few hours I devoted to it (I know, it's not necessarily a lot).
* Usually, with replication, schema tweaking, backups, monitoring and some testing, deploying OpenLDAP can easily be a one or two months project.
* deploying all the integrations correctly is also quite hard (ldap auth for ssh or web authentication on each web applications),
That being said, 389 Directory/RedHat Directory Server is not much better, the setup is done through a weird perl script. Setup ssl/tls is a pain (I learn to hate certutil, and its certs/ca/private keys in DBs, deploying flat pem files is so much easier and convenient). The "rich" client looks like it has not changed in years (or removed all together), and it looks so much like the Old Sun One I'm wondering if it has changed since the Netscape days apart from code maintenance.
Also, I'm not sure if it's still the case, but IIRC RDS is a separate subscription from RedHat, it doesn't come with a basic RHEL OS subscription (I recall having to recompile the srpm my self when 6.0 went out).
RHEL was also not a really great maintainer of their OpenLDAP packages, I remember for example a breaking change because they went from 2.4.38 to 2.4.41 (I'm expecting a stable distro like RHEL to not introduce breaking changes, and to not update software like a rolling release, Debian does a far better job at it for example).
After all this 'praise' of the ldap world, you must think I actually hate it. No, I actually kind of like it (to the point of maintaining an ldap web UI). Having a centralized user DB makes things so much easier for everybody, the user only has one password, the security officer can trustfully enable/disable accesses, the sysadmin as one source of truth. If you maintain local accounts for each of your applications you are in for a lot of troubles down the line.
It's also an authentication method that is widely supported by most applications, and if it's not, there is probably a ticket/PR/patch somewhere to add it.
Lastly once it's setup and configured, it's generally quite reliable even with complex replication setups, this makes it relatively low maintenance. And at least for reads, it has quite good performances.
OpenLdap: I love to hate you, but I love you.
Just curious how easy it'll be to continue using what works as opposed to what marketing wants to sell.