select uris randomly

[uli42]

man sss-ldap states:

ldap_uri, ldap_backup_uri (string) Specifies the comma-separated list of URIs of the LDAP servers to which SSSD should connect in the order of preference.

If I get the documentation right the system will always use the first available URI. If you have identical hosts (e.g. in a diskless environment) chances are they all have the same URI list. So the first server in the list will be the one answering all the requests while server 2, 3,... will not be referred to until the first server fails for some reason.

Therefore I would like to suggest an additional config option that changes the behaviour to select a random URI from the list. Rationale: this can used to setup a "poor man's load balancing".

[sumit-bose]

Hi,

you are correct, it is expected that the URIs are processed in the given order.

For your use-case we typically recommend to use DNS SRV records where a random server is picked if priority and weight are the same. Would this be possible in your environment?

bye,
Sumit

[uli42]

Unfortunately not, as we are not running the DNS servers and updating them is a very uncomfortable and lengthy process.

…

On Mon, Oct 12, 2020 at 8:29 AM sumit-bose ***@***.***> wrote: Hi, you are correct, it is expected that the URIs are processed in the given order. For your use-case we typically recommend to use DNS SRV records where a random server is picked if priority and weight are the same. Would this be possible in your environment? bye, Sumit — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQHBZDJ47S2GRTMPLIJG3LSKKO6LANCNFSM4SKFYT2Q> .

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto