
RedHat and SUSE Withdrawing Support for OpenLDAP - djsumdog
https://www.ostechnix.com/redhat-and-suse-announced-to-withdraw-support-for-openldap/
======
_wmd
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-r...](https://symas.com/message-president-regarding-
red-hat-suse-removing-openldap-linux-distributions/) , 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
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".

~~~
_wmd
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.

~~~
MattSteelblade
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
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/berkeley...](https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/debug/common.html)

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.

~~~
dboreham
Hmm...I've spent decades using BDB and honestly this doesn't jive with my
experience at all. I remember the Subversion debacle, but wasn't that resolved
before 2005?

~~~
_wmd
As I recall, it was only finally resolved by Subversion moving to a home-built
database backend, the issues with BDB were never 100% solved.

------
rkeene2
For a large enterprise deployment of LDAP I used OpenLDAP over
389DS/RHDS/FreeIPA because it was straight-forward and solved the problems of
a multi-master and slave-to-each-master architecture well.

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.

------
zaarn
I recently installed OpenLDAP on a server because I wanted an LDAP Server.

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.

~~~
gargravarr
I built my company's LDAP infrastructure using OpenLDAP from scratch. It's
redefined my pain threshold in the process!

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/!

~~~
oblio
My guess is that it's consultingware. Open Source projects with crap
documentation usually are. You're meant to hire the devs as consultants.

I could be wrong, but it's a common pattern.

------
vorpalhex
Source was down for me, here's the archive link:
[https://web.archive.org/web/20180828133125/https://www.ostec...](https://web.archive.org/web/20180828133125/https://www.ostechnix.com/redhat-
and-suse-announced-to-withdraw-support-for-openldap/)

------
oneplane
If I'm reading this correctly, they are withdrawing _commercial_ support. I
don't see the problem here; if you want 'normal' FOSS support you'll get
whatever you are used to, and if you want paid support from your distro vendor
it matters just a little bit what implementation you use since you're paying
someone else to make it 'just work'.

------
amyjess
According to the article (and articles I've read on this subject before), they
are not ditching LDAP entirely but rather they are switching which
implementation they'll be supporting from now on: instead of supporting
OpenLDAP, they will be supporting the 389 Directory Server, which does
everything OpenLDAP does.

~~~
xenophonf
389 is based on Netscape Directory Server which forked UMN's slapd way back
when. Red Hat sells a branded version of it called "Red Hat Directory Server",
although last I checked everything was released under reasonably free software
licenses. Frankly, as long as I can install current OpenLDAP packages on
CentOS/Fedora from base, an SCL, or EPEL, I'm OK with this change.

------
MattSteelblade
Reading the article, it doesn't look like RedHat announced anything recently.
In the SUSE release notes, "389 Directory Server replaces OpenLDAP to provide
a sustainable directory service." Is there really any news here?

------
LinuxBender
If they linked to the Redhat article, it would have removed some confusion I
believe. [1] Or maybe they did and I missed it?

[1] -
[https://access.redhat.com/solutions/2440481](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.

~~~
JoshTriplett
> If they linked to the Redhat article, it would have removed some confusion I
> believe.

Given the source of the article, they're not looking to _remove_ confusion,
they're looking to _benefit_ from it.

------
JoshTriplett
> Since 2003 Univention supports OpenLDAP for enterprise use. It is one of the
> central components of their product Univention Corporate Server (UCS).

...

> This is a guest post from Univention.

------
h1d
I'm in a small (< 10 users) shop having OpenLDAP to store users that
integrates with Apache authentication, postfix/dovecot authentication and
manages users with (patched) phpLdapAdmin but hearing that OpenLDAP may not
have a bright future, what should I replace it with for central user
management for Linux?

~~~
reqa
OpenLDAP will not go away, see
[https://lwn.net/Articles/755207/](https://lwn.net/Articles/755207/) for a
current road map. Only RedHat doesn't support it any longer, that's all, no
worries.

~~~
h1d
Seeing how I need a patched version of phpLdapAdmin maintained by a third
party instead of the one provided by Ubuntu 18.04 and a lack of easy to use
GUI app for LDAP administration, let alone any third party client interface
for users to login and change their password, I'm starting to think no one
likes LDAP and should move over, perhaps even to MySQL as user management
database.

------
AllegedAlec
Shouldn't the title in some way allude to that the article was written by a
RedHat/Suse competitor?

------
nineteen999
As a long time OpenLDAP user (ie. probably going on 20+ years at this point),
and as somebody who will be rolling out LDAP again on a long-term project on
RHEL 7.5 shortly I have a few questions about 389DS. I've considered migrating
to it for this project, but I just have too many open questions regarding
setting it up right now.

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.

~~~
hyc_symas
>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?

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.

~~~
nineteen999
If they have the resources to maintain their own directory server (389DS,
Netscape or iPlanet, whatever it's called this year) surely they can manage to
ship some client libraries of their own as well.

~~~
hyc_symas
You are correct, and that should tell you all you need to know.

~~~
nineteen999
So my impression is that the goal for Redhat here is to sell RHDS licenses,
rather than rid itself of having to support OpenLDAP on the server side. But
developing client libraries, which Netscape/Sun/389DS/Mozilla etc. all failed
to do, is a bridge too far. Oh well.

------
jakobdabo
There is an interesting fork of OpenLDAP called ReOpenLDAP -
[https://github.com/leo-yuriev/ReOpenLDAP](https://github.com/leo-
yuriev/ReOpenLDAP)

------
amaccuish
I wish 389ds would get rid of the java requirement. I'm sticking with Samba4
right now, both for AD and as an LDAP store for apps; replication handles
itself, sites etc, makes life so much easier.

~~~
dboreham
There is no Java requirement.

~~~
amaccuish
As "vetinari", you need it for the console.

~~~
dboreham
And you don't need the console.

------
kakwa_
ahh, OpenLDAP, I've a weird Stockholm syndrome with that piece of software.

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](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.

------
Allaman
The link has an internal server error :(

------
VLM
Will the LDAP server merge into systemd or will it merely exclusively product
tie or will it just be marketing?

Just curious how easy it'll be to continue using what works as opposed to what
marketing wants to sell.

