On Wed, Jan 06, 2016 at 11:03:45AM +0100, Sumit Bose wrote: > On Wed, Jan 06, 2016 at 10:47:13AM +0100, Pavel Březina wrote: > > On 01/05/2016 05:33 PM, Jakub Hrozek wrote: > > >On Tue, Jan 05, 2016 at 02:12:51PM +0100, Pavel Březina wrote: > > >>On 12/14/2015 03:36 PM, Petr Cech wrote: > > >>>Hi all, > > >>> > > >>>there is patch for https://fedorahosted.org/sssd/ticket/2791 attached. > > >>> > > >>>Result of patch: > > >>> > > >>>The message: > > >>>Dec 14 14:16:11 vm-058-166 sssd[be[uma.dev]]: dereference processing > > >>>failed : Input/output error > > >>>is replaced by > > >>>Dec 14 15:29:26 vm-058-166 sssd[be[uma.dev]]: LDAP server claims to > > >>>support deref, but deref search failed. Disabling deref for further > > >>>requests. You can permanently disable deref by setting > > >>>ldap_deref_threshold to 0 in domain configuration. > > >>> > > >>>But I am little afraid of this patch. Why? I tested this work on RHEL 6 > > >>>how it is described in the ticket. > > >>>If I tried to set > > >>> ldap_deref_threshold = 0 > > >>>it was still falling into bad case and printed I/O error. So, if we > > >>>considered patch is right, there is question if advice in new message is > > >>>valid for IPA 3.x. > > >>> > > >>>Regards > > >>> > > >>>Petr > > >> > > >>This threshold parameter applies for groups membership, not for views > > >>where > > >>dereference is always used in current code. > > >> > > >>The question is, why does sdap_x_deref_search_send fail with EIO? > > >>Dereference should be supported with IPA... > > > > > >Because the dereferenced attribute doesn't exist on the server IIRC. > > > > Then the debug message is misleading since dereference is in fact working. > > We should return different error code if possible (ENOENT?) and this case > > should be handled in views code. > > Unfortunately there is no specific LDAP error code for this case, see > e.g. comments in a50b229c8ea1e22c9efa677760b94d8c48c3ec89. Different > versions of 389ds return LDAP_UNAVAILABLE_CRITICAL_EXTENSION or > LDAP_PROTOCOL_ERROR, not sure what OpenLDAP does. > > I think the error handling code should be moved to the callers because > only they know how to handle different error conditions.
+1 we can also translate the LDAP-specific error codes into sssd private error codes instead of overloading ENOENT/EIO/ENOSUP (ENOSUP is IMO the only one that really fits the problem..) > > As an alternative now options/flags can be added to > sdap_deref_search_send() as it was done for sdap_get_generic_ext_send() > some time ago, but I would prefer the other. No, I also prefer to let the low-level function be dumb and just return an error which the caller deals with. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
