Re: [Mailman-Developers] Python 3
Am 06.01.2015 um 13:48 schrieb Barry Warsaw: On Jan 06, 2015, at 01:37 PM, Aurelien Bompard wrote: I must also consider how much work it would be to just port HyperKitty KittyStore to Python3. All things considered, it may very well be faster and more reliable. Of course, I encourage any porting to Python 3 just on principle :) and certainly if I can help, let me know. But you may still want to consider a more distributed communication protocol between core and HK. What if a site wanted to run them on different VMs for example? Another thing we shouldn't forget is that Hyperkitty or Postorius might not be the only apps living in a Django project. Some people might choose to integrate them into their long-running Django sites, with lots of Py2-app dependencies. Of course it would be easier for us to just port our apps to Py3. But as far as I remember integratability was the main argument in favor of keeping our Django apps bilingual when we discussed the topic at Pycon last year. But then, hey, one *could* also argue we ignore these issues in order to make a point. Florian ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Python 3
I must also consider how much work it would be to just port HyperKitty KittyStore to Python3. All things considered, it may very well be faster and more reliable. A. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Python 3
On Jan 06, 2015, at 01:37 PM, Aurelien Bompard wrote: I must also consider how much work it would be to just port HyperKitty KittyStore to Python3. All things considered, it may very well be faster and more reliable. Of course, I encourage any porting to Python 3 just on principle :) and certainly if I can help, let me know. But you may still want to consider a more distributed communication protocol between core and HK. What if a site wanted to run them on different VMs for example? Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Python 3
What if a site wanted to run them on different VMs for example? Yeah, but certainly there should be a limit to that. What if a site wanted to run each mailman runner on a different VM for example? Oh well, I guess there's no other way. I hope it's not going to be a mess to configure, I'd like to avoid having the admin set HK's base URL in 3 different places. Another thing we shouldn't forget is that Hyperkitty or Postorius might not be the only apps living in a Django project. Some people might choose to integrate them into their long-running Django sites, with lots of Py2-app dependencies. Very good point. Thanks. Aurélien ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Python 3
On Jan 06, 2015, at 02:55 PM, Aurelien Bompard wrote: What if a site wanted to run them on different VMs for example? Yeah, but certainly there should be a limit to that. What if a site wanted to run each mailman runner on a different VM for example? There's already some support for that, in a way. The runners with queues already employ an algorithm to safely split the queue space up into 2^n separate runners without the need for locking. They do of course have to have access to the same directory (e.g. over NFS). Also, now that MM3 is backed by SQL, the use of a client/server db like PostgreSQL eliminates another co-location bottleneck. I wouldn't say this latter is thoroughly fleshed out, and I'm not even sure there's a compelling use case, but it may indeed be possible. Oh well, I guess there's no other way. I hope it's not going to be a mess to configure, I'd like to avoid having the admin set HK's base URL in 3 different places. Agreed. Configuration complexity among all the various components is definitely something to be wary of. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Some raw thinking on user level authorization and authentication
Hi Andrew, thanks for starting to look at this. On Dec 17, 2014, at 09:29 AM, Andrew Stuart wrote: step 1: authentication —- HTTP client provides username and password —- username and password sent to Mailman REST server —- if Mailman REST server authenticates username and password: —- authentication token returned to client MM3's REST API has the resource api/users/uid/login which you can POST to with form data `cleartext_password` as the authentication step. You get back a 204 if the password matches, and a 403 if it does not. step 2: authorization -- examines inbound requests —- if request contains valid authentication information, continue —- examine requested Mailman resource -— send REST request to Mailman REST server to find out if this user is -allowed to do this resource request This is the trickiest part because we don't currently codify what a particular user is or is not allowed to do. We'll need to do this carefully, and the question is whether that information should be kept in the core or in the proxy layer. I wonder if there is prior art or best practices on how best to specify authorizations to REST resources and methods. —- requires execution of the Mailman REST API as a wsgi application, which is potentially complex and more tightly coupled than desirable and would require implementation into the Mailman code base It already is a wsgi application actually. But I think the bigger problem is that we want admins to be comfortable exposing the full admin API only on localhost, and they'll need to expose the proxy on a public IP, so it's likely that the proxy would run on a separate machine/VM from core. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
Tanstaafl writes: On 12/30/2014 2:39 PM, Barry Warsaw ba...@list.org wrote: * A release, which remains on Python 2.7 * B release, which is only compatible with Python 3.4 So, wheezy admins will be left out in the cold. There may be free software, but There Ain't No Such Thing As A Free Lunch, man! People who depend on package managers take that risk. This is especially true of the Debian paleolithic distribution. You want rock-like stability, you best be prepared to use Stone-Age tech. Get out of your cave and kill yourself some sabertooth fur if you feel a chill. Yabba dabba doo! :-) Note that I use Debian stable when possible myself, but I'm not a Debian stable admin, I'm an admin who chooses the best[1] distro for the job, and that is usually Debian stable. The point for me is that it provides a very stable platform for locally-configured and -built installations of mission-critical software that I'm willing to baby- sit. Over the occasional period I have to upgrade to testing; a very few times I've had to pin versions of a few packages in testing. One can also take on the packaging task oneself, or persuade the packagers to do so. Often it's not that hard to do the latter ... they want the same things their users do (at least, that's usually the case for packages in popular distros). Really, you should be lobbying Debian, not Mailman. Footnotes: [1] Which includes considerations of my time for evaluation of best and switching costs. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] X-Message-ID-Hash header (was Re: Python 3)
On Jan 04, 2015, at 03:10 PM, Jeff Breidenbach wrote: So the homebrew hash was dumb idea, and will gracefully retire in favor of the standard mailman hash algorithm. It was pretty neat to see some usage, though. And Archived-At still looks like a winner. Definitely. X-Message-ID-Hash was just a way to elaborate on RFC 5064 $3.2, and because Base 32 was chosen, there isn't any need to worry about needing to escaping non-ascii characters in the Message-ID, nor case/letter/number ambiguity, and still have a reasonably short-ish, human readable URL. Mailman guarantees that any message it forwards will have a Message-ID, although it's usually the case that something upstream will also make such a guarantee. The X-Message-ID-Hash is a pure convenience. We could omit it since we still create and add an Archived-At header with the hash as the last path component, and of course with a well-documented algorithm, it can always be calculated from the Message-ID. It's just handy to include it for other system components that want to combine it easily with RFC 2369's List-Archive header. Cheers, -Barry pgpPBFcd5Qzx7.pgp Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 REST API testing [was: Python 3]
Am 06.01.2015 um 04:24 schrieb Barry Warsaw: On Jan 01, 2015, at 11:40 PM, Barry Warsaw wrote: I'm playing with a solution that involves the use of the 'vcr' package So this branch is now ready for review. https://code.launchpad.net/~barry/mailman.client/bilingual/+merge/245537 I even added documentation on how to run the test to record the yaml file containing the HTTP traffic. There are tox rules for doing both the recording, and for running the test suite with the recorded traffic against both Python 2 and Python 3. I've only tested 2.7 and 3.4 since I don't currently have good builds of 2.6, 3.2, or 3.3, but the tox.ini file should support those. There are now no imports of any `mailman` modules. I did have to add a new top-level `queues` resource to the REST API which will allow you to inject messages, query, and delete messages from the various queues. I thought this was a pretty handy feature anyway, and it was easy to add, so that's now in the Mailman 3 trunk. Which btw, as you might notice, I did go ahead and merge the py3 branch. I think with this mailman.client approach and a REST-based HK IArchiver implementation (TBD), it was safe enough to do, and I didn't want to have to continue to implement new features in both branches (e.g. the queues resource). Please have a look and let me know what you think. I haven't had the time to look at it today. But will definitely do it tomorrow. Thanks a lot! Florian ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On Wed, Jan 7, 2015 at 1:48 AM, Tanstaafl wrote: So, wheezy admins will be left out in the cold. I expect Debian jessie will become Debian stable soon enough. -- bye, pabs http://bonedaddy.net/pabs3/ ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 1/6/2015 8:36 PM, Paul Wise pa...@bonedaddy.net wrote: On Wed, Jan 7, 2015 at 1:48 AM, Tanstaafl wrote: So, wheezy admins will be left out in the cold. I expect Debian jessie will become Debian stable soon enough. Not for those wanting to avoid systemd. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On Wed, Jan 7, 2015 at 3:09 PM, Tanstaafl wrote: Not for those wanting to avoid systemd. systemd is optional and easy to avoid in Debian. -- bye, pabs http://bonedaddy.net/pabs3/ ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 12/30/2014 2:39 PM, Barry Warsaw ba...@list.org wrote: * A release, which remains on Python 2.7 * B release, which is only compatible with Python 3.4 So, wheezy admins will be left out in the cold. Bummer... :( ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Introduction and GSoC project requests
Hello again Mailman developers. I have received some more guidance so i wanted to correct some mistakes in my previous email. On 01/05/2015 08:09 PM, Konstantinos N wrote: On to the requests now. I saw two project ideas for GSoC 2014 that really interested me and i would like some guidance around them so i could read more on them. Could someone give me some status on the implementation of them at the moment? Were these ideas for mailman 3, mailman 2 or both? The 2 ideas are 1. Full anonymization [2] 2. No-logging Mode [3] I read again the GSoC wiki page for 2014 [1] and saw that Mailman 2 development has been frozen so the projects i was asking about are indeed for Mailman 3. Still, i would like all the help you could give me on these 2 subjects. Specifically: Is anyone working on implementing either of these ideas right now? Are there any more specifications i could read or similar features in other projects or services that i could use as reference? Thank you again Konstantinos N [1]http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014 [2]http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014#GoogleSummerofCode2014-Fullanonymization [3]http://wiki.list.org/display/DEV/Google+Summer+of+Code+2014#GoogleSummerofCode2014-No-loggingmode ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 01/06/2015 09:48 AM, Tanstaafl wrote: On 12/30/2014 2:39 PM, Barry Warsaw ba...@list.org wrote: * A release, which remains on Python 2.7 * B release, which is only compatible with Python 3.4 So, wheezy admins will be left out in the cold. Bummer... :( See the last paragraph of Barry's post at https://mail.python.org/pipermail/mailman-developers/2014-December/024134.html. Multiple Python versions can coexist happily side by side. For example, on my production CentOS 5 server, I have (uptime included as partial explanation of why it's CentOS 5) [mark@sbh16 ~]$ uptime 09:55:41 up 1821 days, 17:04, 1 user, load average: 0.00, 0.03, 0.08 [mark@sbh16 ~]$ python -V Python 2.4.3 [mark@sbh16 ~]$ python2.7 -V Python 2.7.9 [mark@sbh16 ~]$ python3 -V Python 3.4.2 I submit that for quite some time it will be significantly easier to install an alternate Python from source than it will be to install and configure and migrate to any Mailman 3, so just consider the Python installation a small part of the total. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
