-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPNLUkACgkQeiVVYja6o6MqVwCfXP/RfVbEL3ojKjBdEw3JLvXv NeAAn10YBMy2Q2J75KQxDS7JOSP+VnJA =2Gtf -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel