[MM3-users]Re: [Mailman-Users] Mailman3 administration
On 06/17/2016 12:16 PM, Bill wrote:
Hi,
I'm looking for some information on Mailman3 administration. I've found that it's not yet packaged by any of the common Linux distros - Debian, Ubuntu, Mint, RedHat, Centos, Fedora, Suse, Arch etc so I have some concerns about the amount of upkeep that running Mailman3 will entail.
I know that Mailman2 is available as a package on the above distros, but we would really like to take advantage of the kludge-free, virtual domains feature on Mailman3.
I've been asked by a local non-profit provider to assist them in moving their 200+ mailing lists from an outdated Sympa list server to Debian8/Postfix/Mailman. One of their chief concerns is the amount of extra administration, over and above normal list administration, that Mailman3 will require in the form of manual updates and maintenance.
We are in the evaluation and design stage right now, but could use any pertinent advice about supportive distros, available packages, the amount of extra administration involved or perhaps, in a worst case scenario, alternate list managers supporting a virtual domains feature similar to Mailman3.
Thanks for your help,
Bill McGrath President, Vancouver Linux Users Group https://vanlug.bc.ca
I've copied this post and set Reply-To: to the Mailman 3 users list <mailman-users@mailman3.org>. Please join at <https://lists.mailman3.org/mailman3/lists/mailman-users@mailman3.org/> before replying there.
That said, we are working on packaging for a more turn-key installation, but we aren't there yet. I've installed a couple of instances including the one at lists.mailman3.org, and it does require extra work. Some of the work in my case is because I want to run all the Mailman pieces from the heads of their branches rather than what's in PyPI, but even without that, installation is significantly more work than installing a distro's package.
I will be writing up my experiences, but that's not done yet either.
I will say that once you have Mailman 3 installed and running, updating (which I do frequently, but which doesn't need to be done unless you want specific updates/fixes) is pretty easy.
As far as alternatives are concerned There is an up to date Mailman 2.1 branch with better virtual domain support at <https://code.launchpad.net/~msapiro/mailman/vhost>, but I think in the long run, you'd be better off with Mailman 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Jun 18, 2016, at 12:10 PM, Mark Sapiro wrote:
because I want to run all the Mailman pieces from the heads of their branches rather than what's in PyPI, but even without that, installation is significantly more work than installing a distro's package.
My hope is that the upcoming 3.1 release will be much more solid and usable than 3.0 so that you won't have to run from the git heads. I think of it very much like Python 3.0 and 3.1 - the 3.0 release was really a stake in the ground and a major milestone so that people will start using it in anger and helping us understand the priorities for fixing and improving it. In that we've succeeded I believe (witness in addition to Mark's work on python.org, that the Fedora mailing lists have all been converted to use MM3).
There are a number of interesting options for improving the turnkey installation of MM3. There are Debian folks who are waiting for 3.1 to complete the packaging work there, and there are docker/juju/etc. containerization work happening too.
I will say that once you have Mailman 3 installed and running, updating (which I do frequently, but which doesn't need to be done unless you want specific updates/fixes) is pretty easy.
Yes, we're trying to be very serious about upgrades and backward compatibility, so that even if you bravely install 3.0 today, it should always be easy to upgrade to the next point release. Similarly, I try to keep core's git head always working so you could track that if you want.
Cheers, -Barry
Hi,
All this is very helpful. Thank you.
And it leads me to think about timelines.
I'm aware that the freeze for Debian 9 (Stretch) is scheduled for the end of this year, and that we can expect it to be released sometime in mid-2017. (Don't quote me on that though ;) And I'm not sure about Centos, I didn't see a Mailman 3.0 package there or in Fedora.
But is there any chance that a Mailman 3.0 or 3.1 package is going to make it into current release cycles?
From what I can gather, we're very early to the table here, and nothing's going viral yet. As a Debian user, I certainly get the bit about "selling no wine before its time", so I completely understand long development cycles.
But we're in the evaluation/design phase of this project and from the providers point of view it would be helpful to know if they should wait a few months for Mailman 3.0/3.1 or just go ahead now with 2.1.x and upgrade to 3.1 at some point down the road. While their list admins are experienced, they are new to Mailman and the fewer burps the better. Although they may very well take a run at 3.0 now and see how things work out. We just need some sort of timeline to consider.
I'm not looking for firm dates of course, best guesstimates will do.
Thanks,
b.On Jun 20, 2016, at 10:47 PM, Bill wrote:
And it leads me to think about timelines.
I'm aware that the freeze for Debian 9 (Stretch) is scheduled for the end of this year, and that we can expect it to be released sometime in mid-2017. (Don't quote me on that though ;) And I'm not sure about Centos, I didn't see a Mailman 3.0 package there or in Fedora.
We have a Debian maintainer who did some work on packaging, but got stuck on a few issues. I think one of the biggest problems is also something that HK/Postorius is grappling with right now - the eminent demise of persona.org. Work is being done to switch over to django-social-auth, and that's a blocker for a full 3.1 suite release.
For the core, the last big missing thing is the unsubscription workflow (see GL#213). I'll be looking at that, trying to adapt or finish Abhilash's work there.
But is there any chance that a Mailman 3.0 or 3.1 package is going to make it into current release cycles?
I'd like for it to happen; we'll have to see.
But we're in the evaluation/design phase of this project and from the providers point of view it would be helpful to know if they should wait a few months for Mailman 3.0/3.1 or just go ahead now with 2.1.x and upgrade to 3.1 at some point down the road. While their list admins are experienced, they are new to Mailman and the fewer burps the better. Although they may very well take a run at 3.0 now and see how things work out. We just need some sort of timeline to consider.
I still think we can get a 3.1 release out by year's end, if not sooner. As I say, we have just a couple of blockers left, though they may or may not be small. I'd say, don't try to deploy 3.0, but either go with the git heads, or wait for hopefully some beta releases of 3.1 coming soon. I am seriously considering not releasing a 3.0.4 and just EOL'ing 3.0.x once 3.1 is released. It should be a smooth upgrade if you already have 3.0 deployed.
Cheers, -Barry
On 06/18/2016 02:10 PM, Mark Sapiro wrote:
I think in the long run, you'd be better off with Mailman 3.
Is it time to install version 3?
Is that going to work with different rewrite rules behind nginx?
Will it cure my problem with moderation and nginx and https?
Thanks,
John Griessen
On Jun 24, 2016, at 10:18 AM, John Griessen wrote:
Is it time to install version 3?
Honestly, I'd wait until 3.1 is released, unless you want to run from git head. I expect 3.1 to be released some time in the next month or so, but we're still working out the specific details.
Cheers, -Barry
On 6/24/16 8:18 AM, John Griessen wrote:
On 06/18/2016 02:10 PM, Mark Sapiro wrote:
I think in the long run, you'd be better off with Mailman 3.
Is it time to install version 3?
Is that going to work with different rewrite rules behind nginx?
Will it cure my problem with moderation and nginx and https?
If you are going to post to mailman-users@mailman3.org, please join the list. That way you will see replies to your posts such as the one at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/GRCBWKJPVEFEIP6RT7OB3OKQOD54OX2X/>. You can join at <https://lists.mailman3.org/mailman3/lists/mailman-users@mailman3.org/>.
The reply addresses your first question.
With respect to your other questions, I think you have resolved your http/https issues in MM 2.1. MM 3 works similarly, but perhaps more obviously. When you create a domain in MM3 you specify a web URL for the domain's web UI. If this is an https URL, you won't have the issues you saw.
There is another way to address this, and that's in the web server (nginx in your case) when you configure the web server to redirect http to https with a 301 Moved Permanently status (or maybe a 302), this tells the browser to issue a GET for the new URI, even if the original request was a POST. Thus the POST data is lost. That is the underlying issue. If instead, you configure the web server to issue a 308 Permanent Redirect instead, this tells the browser to issue a request for the new URI using the original GET/POST/whatever method, so the browser SHOULD reissue the original POST to the new URI. This will work provided the browser recognizes 308 and acts appropriately.
Thus, fixing the scheme in Mailman is the more reliable solution as it doesn't depend on the browser knowing what to do.
See, e.g., <https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Barry Warsaw -
Bill -
John Griessen -
Mark Sapiro