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