On 10-Dec-17 19:24, Mark Sapiro wrote: > > Note that with this specific issue, I could expose a list's web_page_url > in the web admin UI, but that wouldn't solve the problem. As Brian > indicates, making Mailman use https involve more than that. It also > requires certificates and web server configuration, and while I don't > know, I suspect these things require a server admin, even on cPanel. >
I'm not going to claim cPanel expertise - but in my experience a cPanel admin can allow server admins access to SSL/TLS configuration. Once I had that enabled, I was able to just paste certificates/keys into the cPanel UI, and apache is reconfigured behind the scenes. It's pretty good about decoding the certificate and telling you what it covers and when it's valid. I have heard that there's a let'sEncrypt module for cPanel (my provider doesn't have it yet). So the missing piece for allowing a MM admin to convert to (or from) https is 'just' the web admin UI - and some documentation. (Note: I don't run Mailman under cPanel, so I don't know what else there may be.) Of course MM is mostly a volunteer effort, and MM2.1 is on the back burner. Didn't mean to imply otherwise. As I noted, whether or not the web admin UI is improved for 2.1, it should be done for 3. And the doc should clearly indicate that shell access is (currently) a requirement post-install. Apparently, cPanel does some packaging/wrapping of Mailman - which I can't speak to. But there should be no need for root access for a private Mailman instance running from a user directory. Mailman does not run under root. If you choose to run mailing lists for multiple administrative domains under a single instance, you would need access to the instance's mailman user. And that could be undesirable and/or complicated. Off the top of my head, the only system file access required for MM2.1 is to /etc/aliases -- presumably, the cPanel wrapper takes care of updating it (and running newaliases) as lists are created/destroyed. As I said, the best solution is to provide all the MM admin functions from the web admin UI. (There are quite a few in mailman/bin.) Not just for this, but because as time passes, fewer mailing list admins are comfortable at the command line. Speaking of WordPress - I do run it in a cPanel -managed host. WP is a completely private install. My VirtualHost has a complete copy of WordPress in my_username/public_html - nothing is stored in a system directory. And no root access is required. From a hosting provider's point of view, this isn't as efficient as a shared install. But they can charge for the disk space and network/computes used to update each instance, so it works out. I don't see why Mailman couldn't be packaged the same way. TLS is configured by editing the WP config file for each instance (using the cPanel editor that I mentioned). And certificates are installed for the VirtualHost using cPanel->Security->SSL/TLS. (There are also plugins for getting certificates from various CAs.) Finally, I never said "all shared hosting providers are bad". I said "many don't provide shell access", and that Mailman currently requires it for a number of post-install admin operations. It would be good if those requirements could be reduced. If someone has the need/inclination/energy. But this has gone rather far afield. I don't have this particular problem, so I'm going to leave this here. I hope these notes help those who do. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
