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.
LS
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.
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
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.
Michal
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.
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."
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
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@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 */
ACK
I knew it would be a piece of cake for you :-) Thank you very much.
LS
On Fri, Oct 09, 2015 at 09:29:38AM +0200, Lukas Slebodnik wrote:
ACK
I knew it would be a piece of cake for you :-) Thank you very much.
This patch is harmless, so I pushed it to both master: a47102e74050d8ab14a9ea835ab2640c9aa65856 and sssd-1-13: 51ee1fb077e927be7ae2b289c7c5243ab084f642
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Michal Židek -
Stephen Gallagher