[SSSD] [PATCH] ldap_opts: Get rid on 389ds specific values in rfc2307bis schema

Jakub Hrozek jhrozek at redhat.com
Mon Jul 21 15:16:50 UTC 2014


On Mon, Jul 21, 2014 at 11:10:02AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/20/2014 03:20 PM, Jakub Hrozek wrote:
> > On Fri, Jul 18, 2014 at 05:32:09PM +0200, Lukas Slebodnik wrote:
> >> On (18/07/14 16:34), Jakub Hrozek wrote:
> >>> On Thu, Jul 17, 2014 at 04:35:31PM +0200, Lukas Slebodnik
> >>> wrote:
> >>>> ehlo,
> >>>> 
> >>>> There is problem with OpenLDAP server and dereferencing of
> >>>> attributes that is not in the schema  of the server?
> >>>> 
> >>>> sh-4.2$ ldapsearch -x -LLL -h openldap.server.test -b
> >>>> 'dc=example,dc=com' \ -E 'deref=member:uid,dummy_attr'
> >>>> cn=ref_grp Protocol error (2) Additional information:
> >>>> Dereference control: attribute decoding error sh-4.2$ echo
> >>>> $? 2
> >>>> 
> >>>> The attribute nsUniqueID is a 389-only, non-standard
> >>>> attribute. It is an operational attribute that is not in the
> >>>> rfc2307bis nor inetOrgPerson nor posixAccount schema.
> >>>> OpenLDAP supports the standard entryUUID attribute, which is
> >>>> basically the same (uniquely identifies an entry throughout a
> >>>> replication topology), but uses the standard UUID format
> >>>> rather than the non-standard format used by 389.
> >>>> 
> >>>> 4x FIXME removed :-)
> >>>> 
> >>>> 
> >>>> Any comments are welcomed.
> >>>> 
> >>>> LS
> >>> 
> >>> Thanks for the detective work on finding the root cause of the
> >>> problem!
> >>> 
> >>> I wonder if we could remove the attribute completely, though.
> >>> It appears to be completely unused now:
> >>> 
> >>> $ git grep -l SYSDB_UUID src/db/sysdb.h:#define SYSDB_UUID
> >>> "uniqueID" src/providers/ad/ad_opts.h:    { "ldap_user_uuid",
> >>> "objectGUID", SYSDB_UUID, NULL }, src/providers/ad/ad_opts.h:
> >>> { "ldap_group_uuid", "objectGUID", SYSDB_UUID, NULL }, 
> >>> src/providers/ad/ad_opts.h:    { "ldap_netgroup_uuid",
> >>> "nsUniqueId", SYSDB_UUID, NULL }, src/providers/ipa/ipa_opts.h:
> >>> { "ldap_user_uuid", "nsUniqueId", SYSDB_UUID, NULL }, 
> >>> src/providers/ipa/ipa_opts.h:    { "ldap_group_uuid",
> >>> "nsUniqueId", SYSDB_UUID, NULL }, src/providers/ipa/ipa_opts.h:
> >>> { "ipa_netgroup_uuid", "ipaUniqueID", SYSDB_UUID, NULL }, 
> >>> src/providers/ipa/ipa_opts.h:    { "ipa_host_uuid",
> >>> "ipaUniqueID", SYSDB_UUID, NULL}, src/providers/ipa/ipa_opts.h:
> >>> { "ipa_hostgroup_uuid", "ipaUniqueID", SYSDB_UUID, NULL}, 
> >>> src/providers/ipa/ipa_opts.h:    { "ipa_selinux_usermap_uuid",
> >>> "ipaUniqueID", SYSDB_UUID, NULL}, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_user_uuid", NULL,
> >>> SYSDB_UUID, NULL }, src/providers/ldap/ldap_opts.h:    {
> >>> "ldap_group_uuid", NULL, SYSDB_UUID, NULL }, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_user_uuid",
> >>> "nsUniqueId", SYSDB_UUID, NULL }, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_group_uuid",
> >>> "nsUniqueId", SYSDB_UUID, NULL }, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_user_uuid",
> >>> "objectGUID", SYSDB_UUID, NULL }, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_group_uuid",
> >>> "objectGUID", SYSDB_UUID, NULL }, 
> >>> src/providers/ldap/ldap_opts.h:    { "ldap_netgroup_uuid",
> >>> "nsUniqueId", SYSDB_UUID, NULL },
> >>> 
> >>> And according to "git log -S" it was actually never used.
> >>> 
> >>> So my proposal is to just remove the attribute along with
> >>> SYSDB_UUID.
> >> I was thinking about this change but I thought that we need to
> >> deprecate options before removing. I don't have a problem with
> >> removing them. and it should not be a problem in this case. I
> >> would like to know opinion of older developers (Sumit, Stephen,
> >> ...) Why were these options introduced? Do they help with ldap
> >> search?
> >> 
> >> LS
> > 
> > Sure, being defensive when removing anything is a good idea. But
> > since the option doesn't do anything and never did, I think we're
> > fine. You're right that removing an option requires two acks,
> > though. So far you have mine :-)
> 
> I'll ack it as well. I suspect that this was planned for a future use
> that we never ended up with. I don't remember any reason for it.

Thanks for the second pair of eyes!



More information about the sssd-devel mailing list