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(a)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