Multiple LDAP servers support for redundancy

[bloodeagle40234]

Proposed change

For redundant LDAP service, usually multiple LDAP server are provided by admin. Then, users can integrate their authenticator to write every (multiple) server uri in their ldap.conf file (See URI section in *1). A LDAP client will try the next one if the one currently used are not responsive in mean time.

As proposed change, it would be nice that

• Enable server_address and server_port to have list (or dict) in ldapauthenticator conf to have multiple servers
• get_connection will be changed to iterate the servers when a server failed to connect

Those changes will enable us to redirect the one of the available servers in the servers list automatically even if some of servers being in maintainance.

*1: https://linux.die.net/man/5/ldap.conf

Alternative options

Sorry, I don't have another option for now.

Who would use this feature?

Absolutely us. And any other guys who want to build the jupyterhub and LDAP environment with high availability.

(Optional): Suggest a solution

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[bloodeagle40234]

In the alternative way, we could add sort of secondary servers (or uri) option to keep the backward compatibility in the configuration space. Then, ldap client can handle the secondaries if the primary sitting down on servers_address failed.

[geninv]

Is it possible to check this issue and one of the two PR that answers this issue ? We recently ran into this problem where our primary LDAP server was down and couldn't access to our service.
We tried the PR #190 on our qualification platform and it seems to be working well in our case.