Ruth Ivimey-Cook writes:
On 21/06/2020 04:52, Mark Sapiro wrote:
Change that to greyarea-post
Problem is, if I do that (which I did in the beginning), the core rest service listens on localhost / 127.0.0.1
I don't understand. I'm not in a position to test with Mailman itself right now, but the standalone gunicorn[1] does the right thing (takes an IP address and binds to the corresponding interface, or takes a domain name, resolves it to the IP address, and binds that to the corresponding interface). It does not substitute localhost.
It could be a Mailman bug (Mailman 3 is usually configured with all components running on the same host, and that's how it's tested), but first, does greyarea-post resolve to a routable address on the relevant network when queried from that host?
IMO, the hostname parameter needs to be split up into a "what address should the rest of the world use to address me" and separately "what address(es) should I listen on". Multiple listen addresses enable multihomed hosts to get the right connectivity, too.
I'm not clear on what you're saying. An address is a rendezvous point; if you're not listening on the address that others are using, you won't meet. What good does it do to split them up?
It's not clear to me why you think Mailman might want to be multihomed (which is different from the host wanting to be multihomed). I don't object to the work to make it so. But my paranoia says it's best if Mailman is cordoned off into the DMZ with webservers and other hazmat. By design, Mailman core doesn't need to talk to the Internet or to the secure internal network -- Internet functions are delegated to the MTA and the webapps, and local configuration is via shell access which in principle could be console.
I'd rather not enable the complexity of a multihomed application unless there's an important use case. (I don't make the final decision, but I am listened to by Those Who Do.)
Footnotes: [1] gunicorn is the Python module that manages web services for the REST interface.