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.
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.
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... , 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.
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".
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.
> 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.
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.
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...
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.
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?
So your primary complaint with 389 is that it's built on a BerkleyDB backend? At the very least, there is some technical merit to this position and it looks like Red Hat is currently working on getting 389 to work with other databases; they mention LMDB as a specific example. https://directory.fedoraproject.org/docs/389ds/design/backen...
> 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.
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.
I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time.
> I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time.
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.
If you're totally new to LDAP (which despite being "just an object database" has many bells and whistles to fit into various deployments) there is always going to be a little friction at first - there's a reason people make good money offering consultancy and support for LDAP servers.
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.
Sorry but I can only agree with parent. Not only was there no up to date documentation, I couldn't even find out how to revert back to offline config. I gave up and looked elsewhere, and I consider myself fairly experienced with LDAP and other products.
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.
This comment is nonsense. The OpenLDAP Project isn't responsible for 3rd parties not updating their guides. Use the official documentation if you want docs that are up to date.
> 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-l...
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...
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)
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.
> 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.
> 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...
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.
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...
See https://lwn.net/Articles/755674/ and 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.
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?
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'.
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.
If you search the internet for advice on how to install OpenLDAP, you will also get thousands of results with examples for outdated versions and configurations that will not work. It's a real headache.
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/!
>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.
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.
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.
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). 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...
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.
>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.
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.
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.
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?
OpenLDAP will not go away, see https://lwn.net/Articles/755207/ for a current road map. Only RedHat doesn't support it any longer, that's all, no worries.
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.
66 comments
[ 2.9 ms ] story [ 131 ms ] threadRed 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.
Just curious how easy it'll be to continue using what works as opposed to what marketing wants to sell.
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.
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.
...
> This is a guest post from Univention.
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...
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.