> Op 27 okt. 2022 om 04:25 heeft Timo Sirainen <t...@sirainen.com> het volgende > geschreven: > > Director never worked especially well, and for most use cases it's just > unnecessarily complex. I think usually it could be replaced with: > > * Database (sql/ldap/whatever) containing user -> backend table. > * Configure Dovecot proxy to use this database as passdb. > * For HA change dovemon to update the database if backend is down to move > users elsewhere > * When backend comes up, move users into it. Set delay_until extra field for > user in passdb to 5 seconds into future and kick the user in its old backend > (e.g. via doveadm HTTP API). > > All this can be done with existing Dovecot. Should be much easier to build a > project doing this than forking director.
This is my train of thought as well. I believe the following would suffice for most setups. A database with: - Current vhost count per backend server. Alternatively, count the temporary user mappings. - Backend servers. - Temporary user mappings between user - backend server. This database is accessible by all Dovecot proxies in case there’s multiple. Steps when receiving a login: - Check if a temporary user mapping exists. - If so, proxy to the backend server in the temporary mapping. (To do: clean up mappings.) - If not, pick the backend server with the lowest vhost count, create a temporary mapping, then increase the vhost count of the chosen backend server. A monitoring service up/downs backend servers. E.g. by checking the port that we proxy to for each backend server. When a backend server is set to down, kick the user to force a reconnection. (Is that how Director ‘moves’ users?)