On Thu, Oct 5, 2017, at 05:36 PM, Dmitry Makovey wrote:
On 10/05/2017 03:20 PM, Abhilash Raj wrote:
On Thu, Oct 5, 2017, at 03:08 PM, Dmitry Makovey wrote:
I've got a setup where postfix runs inside one VM(container) and mailman runs inside another one (maxking containers). I've wired everything according to docs yet I'm getting:
postfix/lmtp[266]: 66A72800A87: to=<somelist@lists.here.stanford.edu>, relay=none, delay=0.5, delays=0.48/0.01/0/0, dsn=4.4.1, status=deferred (connect to mailman-01.stanford.edu[1.2.3.4]:8024: Connection refused)
I found this in your settings:
[mta] lmtp_host: mailman-01.stanford.edu
[mta] lmtp_port: 8024And the log message above.
I believe that the LMTP runner died because it wasn't able to bind to
mailman-01.stanford.edu, which I am assuming is the hostname assigned
to the host running these containers.
MM_HOSTNAME env variable in the docker containers should be something
that the process inside mailman-core container can bind to and can be
reached by postfix (which can run either on host or on another
container). (Now that I read it myself, I agree that the name of the
variable sounds not-so-intuitive.)
The default configuration (and docker-compose.yaml) sets this value to
the IP Address of the container (172.19.199.2), which is reachable from
the host. If you set this value to whatever IP the mailman-core is
assigned and re-create the containers (or just re-start and run mailman aliases in mailman-core to re-generate transport_maps), it would work
out.
Also, I see your docker-compose.yaml configuration (MAILMAN_CORE_IP: 172.19.199.2) is not consistent with your output of mailman conf([webservice] hostname: 172.19.199.5`). I am not sure how that
happened though, just wanted to point it out. This *might* cause the
rest runner to die to and thus Postorius/HK wouldn't work.
Hope that was helpful!
-- Abhilash Raj maxking@asynchronous.in