Howard, I have longingly looked at libnss-ldapd for almost 4 years now, and absolutely agree it has a better architecture, cleaner code etc., and is a sensible long-term migration path. (The other possibly being sssd.)
But multiple test migrations in my LDAP deployments always turned up some show-stopper problem or another. The last of these happend 3-4 months ago with ubuntu workstations, running an up-to-date karmic client-side (actually triggered by trying to work around exactly this bug).
If the server team decides they want to try migrating for lucid, i'd be the first to offer help testing. But I sure don't see this happening before lucid+1.
Disclaimer: haven't tried the caching slapd with nssov yet, only nslcd, because i need at least an incremental migration path.
Howard, I have longingly looked at libnss-ldapd for almost 4 years now, and absolutely agree it has a better architecture, cleaner code etc., and is a sensible long-term migration path. (The other possibly being sssd.)
But multiple test migrations in my LDAP deployments always turned up some show-stopper problem or another. The last of these happend 3-4 months ago with ubuntu workstations, running an up-to-date karmic client-side (actually triggered by trying to work around exactly this bug).
If the server team decides they want to try migrating for lucid, i'd be the first to offer help testing. But I sure don't see this happening before lucid+1.
Disclaimer: haven't tried the caching slapd with nssov yet, only nslcd, because i need at least an incremental migration path.