On 10/19/2017 01:30 PM, Dmitry Makovey wrote:
On 10/19/2017 10:14 AM, Dmitry Makovey wrote:
after a full remove of the DB - I still get this error. I left some of the directories intact but for the most part it's a fresh new install that gets the same error where previous didn't give us as much trouble. Something else must be messed up. logs show very little detail other than originally posted exception. I'll try to dig up some more info...
running mailman-web with DEBUG=True it looks like issue is rising from here:
does it mean we're setting domains somehow improperly?
Adding info here for posterity:
turns out problem stems from much deeper. Since we're running containerized mailman deployment previously I've posted that for mailman-core I've had to resort to a trick making it think it runs off the public FQDN for the host:
services: mailman-core: image: maxking/mailman-core:0.1 container_name: mailman-core hostname: $CORE_HOSTNAME domainname: $CORE_DOMAINNAME
however it turns out that REST calls to mailman-core are adding abovementioned FQDN to the responses. For some reason Docker/iptables dind't allow mailman-web to talk to the public IP of the host directly, so the solution was to extend above trick a bit further:
and add to mailman-core definition an alias:
services: mailman-core: image: maxking/mailman-core:0.1 container_name: mailman-core hostname: $CORE_HOSTNAME domainname: $CORE_DOMAINNAME ... networks: mailman: aliases: - $CORE_HOSTNAME.$CORE_DOMAINNAME
now mailman-web can properly communicate with mailman-core using either of two names: mailman-core and $CORE_HOSTNAME.$CORE_DOMAINNAME
-- Sr System and DevOps Engineer SoM IRT