Thanks Stephen. I'm able to run the mailmanclient with no issues from the container via localhost:8001.
So I will look into this API mismatch issue you suggest. My tests so far have been from an iMac where I used brew install to get Python 3 and pip3 running to set up mailmanclient.
"That doesn't sound like instability, that sounds like an API mismatch. Have you tried logging in on the container and using mailman shell and/or the Python interpreter (and importing mailmanclient)?"
Dan Caballero Systems Administrator Academic Computing Solutions IMSS - Caltech https://imss.caltech.edu
From: Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> Sent: Monday, July 8, 2019 8:42 PM To: Caballero, Danny (Dan) Cc: mailman-users@mailman3.org Subject: [MM3-users] exposing Mailman3 API securely
dancab@caltech.edu writes:
What is the simplest way to expose the API to an external host?
At the moment, I seem to have this partially working via an Apache virtual host configuration which simply proxies via api.example.edu:80 to localhost:8001 on the container.
An alternative would be an ssh tunnel. That might not be as simply for your users though.
I'm able to remotely use the mailmanclient module for the client.lists, client.system and client.members commands. However running client.domains generates an API connection error. So it seems unstable.
That doesn't sound like instability, that sounds like an API mismatch. Have you tried logging in on the container and using mailman shell and/or the Python interpreter (and importing mailmanclient)?
Have you updated either core or mailmanclient but not both?
If you can't think of anything you may have done to create an API mismatch (such as partial update or patching), please file this as a bug on gitlab.
Steve