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
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
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@redhat.com 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Lawrence Kearney -
Sumit Bose