4 ms·
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
by nineteen999 8y ago
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 8y ago>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 8y agoIf 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 8y agoYou are correct, and that should tell you all you need to know.
- nineteen999 8y agoSo 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.