Getting connection refused on postfix trying to connect to mailman-core:lmtp
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)
is it something I'm missing on mailman side or postfix side (like this post suggests: https://gitlab.com/mailman/mailman/issues/365 )?
Note: I've configured TLS on postfix side but none on mailman side. Is that the issue?
-- Sr System and DevOps Engineer SoM IRT
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)
is it something I'm missing on mailman side or postfix side (like this post suggests: https://gitlab.com/mailman/mailman/issues/365 )?
Note: I've configured TLS on postfix side but none on mailman side. Is that the issue?
I don't think that is a possible issue. Can you show us the configurations and environment variables you have set to make sure everything is done right?
-- Abhilash Raj maxking@asynchronous.in
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)
is it something I'm missing on mailman side or postfix side (like this post suggests: https://gitlab.com/mailman/mailman/issues/365 )?
Note: I've configured TLS on postfix side but none on mailman side. Is that the issue?
I don't think that is a possible issue. Can you show us the configurations and environment variables you have set to make sure everything is done right?
here's a snippet of relevant configs generated by both docker-compose and mailman itself:
https://gist.github.com/droopy4096/d596008b57c4bc4809b56d35ff7650a7
-- Sr System and DevOps Engineer SoM IRT
On 10/05/2017 05:36 PM, Dmitry Makovey wrote:
here's a snippet of relevant configs generated by both docker-compose and mailman itself:
https://gist.github.com/droopy4096/d596008b57c4bc4809b56d35ff7650a7
inside container I see nothing listening on 8024:
/opt/mailman # netstat -na | grep 8024 /opt/mailman #
misconfiguration on my part?
-- Sr System and DevOps Engineer SoM IRT
On 10/05/2017 05:39 PM, Dmitry Makovey wrote:
inside container I see nothing listening on 8024:
/opt/mailman # netstat -na | grep 8024 /opt/mailman #
misconfiguration on my part?
Is Mailman actually running inside the docker container? I.e., have you done 'mailman start'? Does 'ps -fwwu mailman' show twelve runner processes with different values of --runner=, --runner=lmtp in particular?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
On 10/05/2017 07:20 PM, Abhilash Raj wrote:
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_HOSTNAMEenv 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.)
thank you so much for the hints! I've changed docker-compose to include MM_HOSTNAME variable *and* made sure that for the mailman-core I've got:
services: mailman-core: hostname: mailman-01 domainname: stanford.edu ... environment: ... MM_HOSTNAME: mailman-01.stanford.edu
that solved the issue while keeping the mentioned mailman config. Is that what you've had in mind? I was looking for a quick hack, but still would like to find out proper solution if that isn't the one.
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 aliasesin mailman-core to re-generate transport_maps), it would work out.
if I understand above correctly that means semi-manual mangling of postfix aliases file which I'd rather not do. Using above technique mailman-core does generate proper aliases while binding to the appropriate IP. kind of icky but seems to work.
Also, I see your docker-compose.yaml configuration (
MAILMAN_CORE_IP: 172.19.199.2) is not consistent with your output ofmailman 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.
right, some of the IPs keep on popping at me and I've got to look for them - I intentionally removed direct IP assignment in docker-compose.yaml yet I get the feeling that someplace there's another IP assignement I've missed.
Hope that was helpful!
very much so! thanks for your quick responses - provided my existing deadlines I value them that much more :)
-- Sr System and DevOps Engineer SoM IRT
On Thu, Oct 5, 2017, at 08:56 PM, Dmitry Makovey wrote:
On 10/05/2017 07:20 PM, Abhilash Raj wrote:
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_HOSTNAMEenv 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.)thank you so much for the hints! I've changed docker-compose to include MM_HOSTNAME variable *and* made sure that for the mailman-core I've got:
services: mailman-core: hostname: mailman-01 domainname: stanford.edu ... environment: ... MM_HOSTNAME: mailman-01.stanford.edu
that solved the issue while keeping the mentioned mailman config. Is that what you've had in mind? I was looking for a quick hack, but still would like to find out proper solution if that isn't the one.
If that is the address that can be used to reach the container from postfix, nothing else is needed. That is the proper solution.
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 aliasesin mailman-core to re-generate transport_maps), it would work out.if I understand above correctly that means semi-manual mangling of postfix aliases file which I'd rather not do.
Not exactly manual, next time you re-create the container, these aliases
should be generated correctly. I asked for re-generating aliases as
you'd have wrong ones. BUT, because mailman-01.stanford.edu was
actually the correct address, it probably wasn't needed.
Using above technique mailman-core does generate proper aliases while binding to the appropriate IP. kind of icky but seems to work.
Also, I see your docker-compose.yaml configuration (
MAILMAN_CORE_IP: 172.19.199.2) is not consistent with your output ofmailman 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.right, some of the IPs keep on popping at me and I've got to look for them - I intentionally removed direct IP assignment in docker-compose.yaml yet I get the feeling that someplace there's another IP assignement I've missed.
Hope that was helpful!
very much so! thanks for your quick responses - provided my existing deadlines I value them that much more :)
-- Sr System and DevOps Engineer SoM IRT
Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
-- Abhilash Raj maxking@asynchronous.in
On 10/05/2017 09:32 PM, Abhilash Raj wrote:
services: mailman-core: hostname: mailman-01 domainname: stanford.edu ... environment: ... MM_HOSTNAME: mailman-01.stanford.edu
that solved the issue while keeping the mentioned mailman config. Is that what you've had in mind? I was looking for a quick hack, but still would like to find out proper solution if that isn't the one.
If that is the address that can be used to reach the container from postfix, nothing else is needed. That is the proper solution.
yep. I've used inside container the same hostname that is assigned to public IP. Thanks for confirming appropriateness of this :) Shall I pop some notes someplace for posterity? This is the kind of issue people may step into rolling with docker containers.
P.S. Great thanks to you Abhilash for maintaining docker implementation and supporting it's users! :)
-- Sr System and DevOps Engineer SoM IRT
On Fri, Oct 6, 2017, at 07:51 AM, Dmitry Makovey wrote:
On 10/05/2017 09:32 PM, Abhilash Raj wrote:
services: mailman-core: hostname: mailman-01 domainname: stanford.edu ... environment: ... MM_HOSTNAME: mailman-01.stanford.edu
that solved the issue while keeping the mentioned mailman config. Is that what you've had in mind? I was looking for a quick hack, but still would like to find out proper solution if that isn't the one.
If that is the address that can be used to reach the container from postfix, nothing else is needed. That is the proper solution.
yep. I've used inside container the same hostname that is assigned to public IP. Thanks for confirming appropriateness of this :) Shall I pop some notes someplace for posterity? This is the kind of issue people may step into rolling with docker containers.
I would like to mention here that it would be best if the mailman-core container is not exposed to internet (or, outside of your trusted network).
A note here1 might be a good place to put this information. Pull requests are welcome :)
P.S. Great thanks to you Abhilash for maintaining docker implementation and supporting it's users! :)
:)
-- Abhilash Raj maxking@asynchronous.in
participants (3)
-
Abhilash Raj -
Dmitry Makovey -
Mark Sapiro