just use first IP as MM_HOSTNAME if multiple there

[aiomaster]

in case you have configured multiple networks hostname -i returns a list of IPs and that gives a bad MM_HOSTNAME. We just use the first and hope that the mailserver can access it.

[maxking]

I don't like the part where we use the first ip and hope that mail server can access it. I'd rather ask people to set the IP manually, in case they have multiple IPs configured, or possibly remove that functionality if it doesn't take into account multiple addresses.

[aiomaster]

Yep, I know this is not the best solution, cause it is not really predictable which IP is taken. I could not find some information about the order of the IPs of hostname -i. (maybe the order in which the networks are defined?) But I think it is better than the current behaviour of setting an incorrect MM_HOSTNAME. In my case it is perfectly fine to take any IP, cause I have 2 networks and the mailman-core container and my postfix container are in both of them, so it works in every case. I don't want to set fixed IP addresses for every container instead.

My first idea was to use the name mailman-core for MM_HOSTNAME, cause my postfix and my mailman containers are started with the same docker-compose.yml file, but when it comes to access the mailman-core from my postfix container I just get Host or domain name not found. Name service error for name=mailman-core type=AAAA: Host not found but it works using the container IP instead of the name mailman-core. I have something like this in the postfix_lmtp:

# this is not working
/^mylist@lists\.mydomain\.tld$/                  lmtp:[mailman-core]:8024

# this works
/^mylist@lists\.mydomain\.tld$/                  lmtp:[127.30.0.3]:8024

I don't really understand why this happens, cause I thought the containers are reachable with their service_name by default in docker-compose, but it doesn't work for my mailserver. Maybe because the option domainname is given. (BTW: I use https://github.com/hardware/mailserver) But this is another problem.

So to come back to the topic: I don't think it is better to fail if multiple networks are configured and no MM_HOSTNAME is set, than to take just one ip of them. If one has problems with the take-first-ip behaviour MM_HOSTNAME can just be set by hand, but if it works (like in my case) everything is fine. Why should that fail?

[maxking]

The whole reason we had to go through this static-ip dance in compose file was becase the containers aren't accessible through their hostnames from the host.

If you mail server in running in a container and is linked to your mailman-core container, then, it should work.

I have a better solution to that problem, which would involve getting rid of all the static IP addresses and instead using host Ports to communicate, in which case containers can listen on host port 8001/8024/8080/8000 for whatever they need and can also more easily communicate among themselves with hostname mapping.

[aiomaster]

Yeah accessing the container by service_name should work out of the box for me, but in fact it isn't (for the mailserver only) and I have no idea why. Your idea for the setup of a native mailserver at the host could be reached by setup the ports: section in the service config and map the container ports to the host. You would also set MM_HOSTNAME to localhost in this case, right? This setup wouldn't help me, but in this scenario it seems far better than this static-ip stuff, I agree.

[maxking]

How are you deploying the mailserver and mailman-core? Are they deployed using the same docker-compose.yaml (and, same network in docker)? Are they linked to each other?

Can you ping the IP address of mailman-core from your mailserver? What are the contents of /etc/hosts in your mailserver container?

Sorry for so many question, just trying to help you with that problem. They should really be able to reach each other via hostnames, but there are certain limitations based on how you create and configure you containers.

[aiomaster]

Thanks for your help. Right now I have another idea. The mailserver image from https://github.com/hardware/mailserver uses the unbound dns resolver inside. Maybe this breaks the service discovery stuff. No I could not ping mailman-core, cause it is expanded to mailman-core.mydomain.tld and tried to get resolved this way. I will experiment around a little and if I could figure it out, I will write a small documentation how to use https://github.com/hardware/mailserver and your mailman images.

[maxking]

The documentation would awesome!

[aiomaster]

Ah ok, just if someone finds this and has similar problems: unbound was the problem and setting the envvar DISABLE_DNS_RESOLVER=true for the mailserver container disables this and now I can access mailman-core as expected by the service name. Yippieh!

But what to do with this PR?

[github-actions[bot]]

This Pull Request has not been updated for more than 1year