dovecot director and keepalived

[Steven Varco]

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 <s.hoogeveen at nederhost.nl>:
> 
> Hi Steven,
> 
> On 14/03/2021, 17:53, "dovecot on behalf of Steven Varco" <dovecot-bounces at dovecot.org on behalf of dovecot.org at bbs.varco.ch> 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
> 
>