Hi Sebastiaan Many thanks for that hint, it does work just perfectly, after I configured an address on the service director inet_listener! :) Now each instance only binds to its own IP, which is exactly what I was looking for.
I think it would be helpfull, if this could be added as a note to the docs in the director configuration settings. And to answer the questsions from others regarding my mentioned „haproxy" on the server: haproxy is not directly in connection with doevecot at all, instead I use it for proxying the SMTP submission port to postifix until I can upgrade dovecot to 2.3 (which I believe should habe the smtp sumbmission service included). And it is also used for proxing to other services, like http for webmail, etc. Regarding the dovecot setup, I just use keepalived -> dovecot director -> dovecot IMAP Sorry for the confusion, might should have mentioned that in the beginning… ;) thanks, Steven -- https://steven.varco.ch/ > Am 16.03.2021 um 13:39 schrieb Sebastiaan Hoogeveen > <[email protected]>: > > Hi Steven, > > On 14/03/2021, 17:53, "dovecot on behalf of Steven Varco" > <[email protected] on behalf of [email protected]> wrote: > >> Now I’m hitting the issue with the way director determines his „Self IP“ by >> trying to >> bind to all configured director_servers IPs, taking the first one possible. >> >> However this approach only works, when the sysctl setting is: >> net.ipv4.ip_nonlocal_bind=0 >> On the other side keepalived needs net.ipv4.ip_nonlocal_bind=1 in order to >> bind the VIP. > > This can be fixed by specifying the IP address of the director in the > inet_listener section of the director service, like this: > > service director { > ### other configuration here ### > inet_listener { > address = 172.20.1.4 > port = 9090 > } > } > > The listener address will be used as the 'self IP' of the director. This also > means that each director will have a slightly different configuration file, > but that should usually not be a problem. > > I got this from skimming the source, afaict it is not documented anywhere so > I'm not sure if this behavior can always be relied on in future releases (it > does seem logical to me though). > > Kind regards, > > -- > Sebastiaan Hoogeveen > > NederHost > KvK: 34099781 > >
