[SSSD] [PATCH] LDAP: Inform about small range size

Lukas Slebodnik lslebodn at redhat.com
Fri Oct 9 07:29:38 UTC 2015


On (08/10/15 11:39), Stephen Gallagher wrote:
>On 10/08/2015 05:16 AM, Lukas Slebodnik wrote:
>> On (23/01/15 12:27), Stephen Gallagher wrote:
>>> On Fri, 2015-01-23 at 17:27 +0100, Jakub Hrozek wrote:
>>>> On Fri, Jan 23, 2015 at 05:24:51PM +0100, Michal Židek wrote:
>>>>> On 01/23/2015 04:35 PM, Lukas Slebodnik wrote:
>>>>>> On (23/01/15 10:21), Stephen Gallagher wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, 2015-01-23 at 14:39 +0100, Lukas Slebodnik
>>>>>>> wrote:
>>>>>>>> ehlo,
>>>>>>>> 
>>>>>>>> I was reprodicing other bug and it took me some time to
>>>>>>>> find out why I was not able to resolve user. RID was
>>>>>>>> bigger than range size.
>>>>>>>> 
>>>>>>>> I saw just general message about id mapping failer 
>>>>>>>> [sdap_save_user] (0x0400): Processing user matthewbe 
>>>>>>>> [sdap_save_user] (0x1000): Mapping user [matthewbe]
>>>>>>>> objectSID 
>>>>>>>> [S-1-5-21-2997650941-1802118864-3094776726-200065] to
>>>>>>>> unix ID [sdap_idmap_sid_to_unix] (0x0080): Could not
>>>>>>>> convert objectSID 
>>>>>>>> [S-1-5-21-2997650941-1802118864-3094776726-200065] to a
>>>>>>>> UNIX ID ^^^^^^ Default range size is 200000 
>>>>>>>> [sdap_save_user] (0x0020): Failed to save user
>>>>>>>> [matthewbe] [sdap_save_users] (0x0040): Failed to store
>>>>>>>> user 0. Ignoring.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Feel free to propose better debug message. I think it
>>>>>>>> would simplify debugging.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I'd avoid making a recommendation about changing the
>>>>>>> range size. That will result in any other domain having
>>>>>>> all of their IDs changed. That's not a good situation. We
>>>>>>> should certainly log this at a very low level, though.
>>>>>> 
>>>>>> As you can see from debug message it is almost impossible
>>>>>> to say why converting of objectSID failed. I have already
>>>>>> seen such problem in customer reports. and reasonable hint
>>>>>> could speed up fixing of a problem.
>>>>>> 
>>>>>> user issue -> bug report -> requests for log files -> 
>>>>>> analysis of log file -> advice to increase
>>>>>> ldap_idmap_range_size
>>>>>> 
>>>>>> 
>>>>>> Maybe we can recommend just to double value of range size, 
>>>>>> but current situation isn't user friendly.
>>>>>> 
>>>>>> LS
>>>>> 
>>>>> I think there is just problem with wording here. You used
>>>>> "You should..." in the debug message. I would change it to
>>>>> "You could/can..." and add a sentence that warns the user
>>>>> about the consequences. like "But be careful because changing
>>>>> the range size will also change the ID mappings in all
>>>>> trusted domains." Or some better warning.
>>>> 
>>>> We can also point the user to the man page in the debug message
>>>> to avoid being overly terse...then in the man page, we can
>>>> explain all the pros and cons better.
>>> 
>>> Yeah, I like this approach. So maybe the phrasing should be:
>>> 
>>> "objectSID [%s] has a RID that is larger than the
>>> ldap_idmap_range_size. See sssd-ad(5) for an explanation of how
>>> to resolve this issue."
>>> 
>> I reminded this thread after seeing another BZ with such issue. But
>> I would like to provide more hints. Maybe incorporate "ID MAPPING"
>> section to the debug message and/or 3rd paragraph in this section.
>> 
>> Stephen, could you help with new message (or even prepare  updated
>> patch.)
>> 
>> LS
>> 
>
>Updated patch attached. I didn't change anything in the manpage
>because there's already an involved section explaining the mechanism
>for and consequences of changing the ID range values.
>

>From a710c8cbfd37a2851c29f8f57a278d1b92f584ef Mon Sep 17 00:00:00 2001
>From: Stephen Gallagher <sgallagh at redhat.com>
>Date: Thu, 8 Oct 2015 11:33:30 -0400
>Subject: [PATCH] LDAP: Inform about small range size
>
>When a returned RID has a higher value than the ldap_idmap_range_size,
>it means that the administrator did not plan appropriately for the size
>of their network. We need to alert the admin at a severe notification
>level that their configuration will fail on entries with a high RID and
>point them at the explanation in the manual.
>---
> src/providers/ldap/sdap_idmap.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/src/providers/ldap/sdap_idmap.c b/src/providers/ldap/sdap_idmap.c
>index 36d529836eb7e4becd27721df15cfbccf035ae3b..f4a065b0b251b868344eae856c3655ff30b8a5dc 100644
>--- a/src/providers/ldap/sdap_idmap.c
>+++ b/src/providers/ldap/sdap_idmap.c
>@@ -501,10 +501,17 @@ sdap_idmap_sid_to_unix(struct sdap_idmap_ctx *idmap_ctx,
>               "Object SID [%s] is a built-in one.\n", sid_str);
>         /* ENOTSUP indicates built-in SID */
>         ret = ENOTSUP;
>         goto done;
>         break;
>+    case IDMAP_NO_RANGE:
>+        DEBUG(SSSDBG_IMPORTANT_INFO,
>+              "Object SID [%s] has a RID that is larger than the "
>+              "ldap_idmap_range_size. See the \"ID MAPPING\" section of "
>+              "sssd-ad(5) for an explanation of how to resolve this issue.",
>+              sid_str);
>+        /* Fall through intentionally */
>     default:
>         DEBUG(SSSDBG_MINOR_FAILURE,
>               "Could not convert objectSID [%s] to a UNIX ID\n",
>                sid_str);
>         ret = EIO;

ACK

I knew it would be a piece of cake for you :-)
Thank you very much.

LS


More information about the sssd-devel mailing list