What to do about 389-ds support

[Firstyear]

Hi all, I'm the maintainer of 389-ds and related parts at SUSE. Slightly embarrassing but I didn't actually know yast-users could manage users and groups in ldap, so I haven't looked into this in some time! Sorry!

I've had a look at this module and yast-ldap and think we need to discuss how to proceed. Currently, using yast-users with 389-ds is broken. Users can be created and modified but they don't match the "expected" schema of 389-ds. If a password is set via yast-users, it will never work as the yast-users module pre-crypts before sending the value which 389-ds rejects (this works on openldap for "reasons"). The default bind dn of "cn=Administrator,base_dn" is not the same as 389-ds. It's not clear the yast-users is reading from /etc/openldap/ldap.conf at all to be honest ... . User Management Settings (Configuration Modules) don't work because yast users can't read the schema properly. Reading the code, it looks like the access controls can't be set either because 389-ds ACI's are vastly different to openldaps.

Generally, pretty much most features have "some kind of problem".

To compound this, the module is split over perl, c++ and ruby, which are three languages that I don't know, and am not confident to "make large sweeping chanages" over this module in.

As a result, I think there are a few ways we could proceed. These are listed in order of "least work to most".

1 - Only support openldap, not 389-ds with this. On connection, read the RootDSE entry, and if the 'vendorName' is 389 Project, then warn the user and disable all LDAP related elements. It would be then up to the community to maintain this support. 389-ds would continue to manage it's users via it's existing inbuilt admin tool kit (dsidm).

2 - Fully remove LDAP support from yast-users. Currently, there has only been a single bug report about this feature, which may indicate it's not widely used or adopted amongst 389-ds users. However it may be working with openldap still. regardless, there appears to be a "lack of appetite" to maintain this, give the general age of the code and lack of interest to develop the ldap integration. The ldap integration as it currently exists is also generally confusing and difficult to find (even as an ldap expert it took me about half an hour to even find how to list ldap users ....)

3 - Only support 389-ds, not openldap with this module. On connection, read the RootDSE entry, and if the 'vendorName' is 389 Project, then proceed. Any other value is an error. This would allow some features to be remove, aci's to be fixed, removal of the pre-hashing of pws and more. This would bring yast-users into line with the other yast modules also only supporting 389-ds. However, this would basicly be a "large rewrite" of many elements of the ldap feature, and would require "someone else" to really help because I'm not able to do this code confidently.

4 - Support both 389-ds and openldap. This would require verification of the server type at module start, and then effectively swapping behaviours underneath. This is effectively combining 1 and 2, and would be the most work wrt to testing, making sure both code paths work, and the features involved.

I hope this gives some ideas,

[kobliha]

I'd go for "2", code removal. If there are other tools to do it...

[Firstyear]

@kobliha Sure, I can submit a PR for that then :)

[johnlmax]

Hi, I would like to know the current status of this.

[Firstyear]

It has been marked as deprecated, I need to finalise when it will be removed for good.

You should use dscreate instead, and follow https://www.port389.org/docs/389ds/howto/quickstart.html