On 26-Jun-17 15:31, Abhilash Raj wrote:
Excerpts from tlhackque--- via Mailman-users's message of June 24, 2017 4:21 am:
I had to read code to discover that the web UI (Postorious) server address doesn't exist in any config file.
That is True, there is no stright forward way for Mailman Core to know who is using the API and where is the Web UI working. I *think* "Web Host" is used to generate emails, but that can't always be completely accurate because there is no easy way to know what is the "root" url for Postorius and Hyperkitty. Generally, the default configurations place it at "/postorius/" and "/hyperkitty/", but there are installations where it is placed at "/mailman3/" and "/archives/".
It would be helpful for API users to "register" with Mailman, so that API clients can figure out how to direct users to their web pages. There has to be a directory somewhere, and Mailman is the central character. It doesn't have to be one place. Perhaps something like "get( '/lists/config/admin_ui') and get('/lists/config/subscriber_ui") - which could return something like:
[ {"type":"gui", "name":"postorius", "uri":"https://www.example.net/mailman3/"}, {"type":"cli","name":"mailmanclient","uri":"domain://my.socket.example.net:1234"},{"type":"gui","name":"mailmanx","uri":"file:///usr/sbin/mailman-Tk"}, ...]
(Where the order indicates preference).
Speaking of which, without this knowledge, how can Mailman provide the personalized "to unsubscribe, visit your account at "...." customizations"?
I see that there are URLs for headers/footers, but we seem to have lost the ability to insert the URL for the GUI managing your list/account into personalized e-mails...
To bind it to something other than localhost, you put the desired ip address & port on the
python manage.py runservercommand line (in mailman-suite_project.Ok, so you should never use this in production. AGREEED This command starts a "development" server which is only supposed to be used in the development environment. My development environment is a VM for Mailman, and other VMs for the mail server. And if I try to run a web browser on the Mailman VM, it takes over the machine and even so is unresponsive. So I needed to make the UI visible on the network where my PC is. I do understand the issues, and there are firewalls protecting the environment.
For any production use, in general for any python web app, we use a wsgi server which interfaces between Django and a "real" web server like Nginx or Apache. I would recommend using uwsgi. This[1] and [2] might be of help.
AGREE. I know that I will have to do this eventually. But my immediate goal is to see if it's possible to get my application talking to Mailman V3 - it's a 1-user environment. So I needed an evaluation environment with the absolute minimum setup costs. If things work out, I'll do the right thing. If not, I can't afford to have spent a week or so untangling nested webservers talking to each-other with frameworks, a half-dozen passwords and config files.
This was the quickest path I could find to an 'almost out-of-the-box' evaluation and prototyping environment...and pretty much the only "step-by-step" instructions that I could find. I'd have tried "step-by-step" for production if (a) I could find it and (b) I could configure it with less than a couple of days of study :-(
I decided to document this in case it helps someone else.
I strongly agree that it's not production, and not for all users.
There is some configuration over here[3] that might help you get it running. You would have to change some parameters in the configuration though.
It must be an IP address - it doesn't resolve DNS names. The port is appended to the IP address with a ':'.
So, in venv 2.7
cd mailman-suite_project && python manage.py runserver 10.0.0.11:8000will work.There are all sorts of issues if your network is at all public, but in my case, a multi-machine walled garden, with no local web browser, it allowed bootstrapping to continue.
It is not supposed to be public and should only be used for development.
Agree, agree, agree.
The runserver command also takes --ipv6 (or -6) to bind to an IPv6 address, --nothreading and --noreload also exist (but i haven't tracked down whethere they're useful')
There are a whole lot of other optins available to
python manage.pycommand which you can find in the documentation for Django. Truth be told, I had no idea that 'runserver" had anything to do with Django. I was just following instructions to get something out of the box and onto the wire.
FWIW, 'python manage.py --help' and 'python manage.py help runserver' are semi-intructive. I still have no clue what an "auto-reloader" is, but the help does say that --noreload won't use it :-)
It's clear that a lot of work has gone into this release -- but it's also quite frustrating for people who just want to explore using it to get through the setup effort.
I've made some progress.
-- thanks, Abhilash Raj