concerning "ldap_idmap_range_size"

[Lawrence Kearney]

I have a question concerning values for the the "ldap_idmap_range_size"
directive. I'm aware that v1.13.4 or better of the daemon supports multiple
slices for the same domain. My question goes to earlier versions of the
daemon  that do not, "and" the v1.13.4 or better versions of the daemon
that do.

In environments that have high RID values (>750,000), what disadvantages
are there to setting the value of the "ldap_idmap_range_size" directive to
values above 1,000,000 to accommodate extraordinary large RID values. My
common sense says the computational tax would be too high for a host to be
sustainable, but I wanted to ask.

So, in environments where I might want to have slice capacity > 200,000,
what are the concerns, best practices, and briefly, why?


Many thanks


-- Lawrence Kearney

[Sumit Bose]

On Tue, Aug 28, 2018 at 03:55:37PM -0400, Lawrence Kearney wrote:
>  I have a question concerning values for the the
> "ldap_idmap_range_size"
>  directive. I'm aware that v1.13.4 or better of the daemon supports multiple
>  slices for the same domain. My question goes to earlier versions of the
>  daemon  that do not, "and" the v1.13.4 or better versions of the daemon
>  that do.
>  
>  In environments that have high RID values (>750,000), what disadvantages
>  are there to setting the value of the "ldap_idmap_range_size" directive to
>  values above 1,000,000 to accommodate extraordinary large RID values. My
>  common sense says the computational tax would be too high for a host to be
>  sustainable, but I wanted to ask. 
No it is ok to use larger value there is no additional tax. See the 'ID
MAPPING' section of the sssd-ad man page for details about how the
mapping is done.

>  
>  So, in environments where I might want to have slice capacity > 200,000,
>  what are the concerns, best practices, and briefly, why? 
You have to be aware that the UIDs and GIDs assigned to a user or a
group will change if you change ldap_idmap_range_size. If you already
used the default value for some time you have to migrate existing file
system permissions to the new values. Given that you should choose the
new value for ldap_idmap_range_size large enough so that chances are low
it has to be increased again.

If you increase the size of a range the number of ranges will decrease.
Since ranges are selected for each domain with the help of a hashed
value the chance of a collision (a range assigned to two different
domains) will increase. But so far I'm not aware of a reported
collision so this is more a theoretical concern.

HTH

bye,
Sumit
>  
>  
>  Many thanks
>  
>  
>  -- Lawrence Kearney 
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Lawrence Kearney]

Sumit,
Thank you that helps immensely.

The goal of the referenced configuration is for new "direct integration"
deployments in large AD environments for which we want to accommodate both
growth and UID-GID alignment across systems that support the
"ldap_idmap_helper_table_size" directive and those that don't.

-- lawrence

On Wed, Aug 29, 2018 at 5:01 AM Sumit Bose <sbose(a)redhat.com&gt; wrote:

>  On Tue, Aug 28, 2018 at 03:55:37PM -0400, Lawrence Kearney wrote:
>  > I have a question concerning values for the the "ldap_idmap_range_size"
>  > directive. I'm aware that v1.13.4 or better of the daemon supports
>  multiple
>  > slices for the same domain. My question goes to earlier versions of the
>  > daemon  that do not, "and" the v1.13.4 or better versions of the daemon
>  > that do.
>  >
>  > In environments that have high RID values (>750,000), what disadvantages
>  > are there to setting the value of the "ldap_idmap_range_size" directive
>  to
>  > values above 1,000,000 to accommodate extraordinary large RID values. My
>  > common sense says the computational tax would be too high for a host to
>  be
>  > sustainable, but I wanted to ask.
>
>  No it is ok to use larger value there is no additional tax. See the 'ID
>  MAPPING' section of the sssd-ad man page for details about how the
>  mapping is done.
>
>  >
>  > So, in environments where I might want to have slice capacity > 200,000,
>  > what are the concerns, best practices, and briefly, why?
>
>  You have to be aware that the UIDs and GIDs assigned to a user or a
>  group will change if you change ldap_idmap_range_size. If you already
>  used the default value for some time you have to migrate existing file
>  system permissions to the new values. Given that you should choose the
>  new value for ldap_idmap_range_size large enough so that chances are low
>  it has to be increased again.
>
>  If you increase the size of a range the number of ranges will decrease.
>  Since ranges are selected for each domain with the help of a hashed
>  value the chance of a collision (a range assigned to two different
>  domains) will increase. But so far I'm not aware of a reported
>  collision so this is more a theoretical concern.
>
>  HTH
>
>  bye,
>  Sumit
>  >
>  >
>  > Many thanks
>  >
>  >
>  > -- Lawrence Kearney
>
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  

-- 
Lawrence Kearney

e: lawrence.kearney(a)earthlink.net
t: +001 706.951.6257
w: www.lawrencekearney.com­­­
l: www.linkedin.com/in/lawrencekearney