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.