From terri at zone12.com Sun Oct 7 05:35:13 2012 From: terri at zone12.com (Terri Oda) Date: Sat, 06 Oct 2012 23:35:13 -0400 Subject: [Mailman-Developers] GHC 12 Open Source Day was amazing! Message-ID: <5070F871.3000800@zone12.com> A very quick report: We had our post-GHC12 hackathon today and I think we were wildly successful. I didn't sit down and count, but we had around 15 women, most new contributors, hacking on Postorius/Mailman today. We stomped on a bunch of the specially-marked bugs, and just as vitally, we had a bunch of folk go through decent first-pass usability testing of the Postorius interface with Robin (who is an experienced UI person from Google) and file bugs for the missing bits that seem most essential for the Postorius release. Sometimes we also filed fixes for the bugs that were tractable in the time we had! Because we were on limited time, I've just got a pile of contributions tarballed up on our dev vm (and backed up elsewhere), and I got everyone who fixed a bug to comment on it on Launchpad so we can send out the appropriate copyright forms. I'll be marking those bugs as fixed once I get home (I need to pack and sleep now) and sometime thereafter (probably next weekend) I'll separate out the code to merge requests and triage the rest of the new bugs so we can start work on those. I think people had a lot of fun seeing their code go live on our test server and watching their bugs get fixed, and I think we've got a few contributors who'll be interested in doing more (and maybe, once I wrangle the travel funds, coming to pycon!). I'm so very excited! :) Terri From stephen at xemacs.org Sun Oct 7 10:43:18 2012 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 07 Oct 2012 17:43:18 +0900 Subject: [Mailman-Developers] GHC 12 Open Source Day was amazing! In-Reply-To: <5070F871.3000800@zone12.com> References: <5070F871.3000800@zone12.com> Message-ID: <87d30uekpl.fsf@uwakimon.sk.tsukuba.ac.jp> Terri Oda writes: > I think people had a lot of fun seeing their code go live on our test > server and watching their bugs get fixed, and I think we've got a few > contributors who'll be interested in doing more (and maybe, once I > wrangle the travel funds, coming to pycon!). I'm so very excited! :) Wow! And-I-thought-getting-the-T-shirt-was-a-big-deal-ly y'rs, From barry at list.org Mon Oct 8 16:21:58 2012 From: barry at list.org (Barry Warsaw) Date: Mon, 8 Oct 2012 10:21:58 -0400 Subject: [Mailman-Developers] GHC 12 Open Source Day was amazing! In-Reply-To: <5070F871.3000800@zone12.com> References: <5070F871.3000800@zone12.com> Message-ID: <20121008102158.0cc725ca@limelight.wooz.org> On Oct 06, 2012, at 11:35 PM, Terri Oda wrote: >I think people had a lot of fun seeing their code go live on our test server >and watching their bugs get fixed, and I think we've got a few contributors >who'll be interested in doing more (and maybe, once I wrangle the travel >funds, coming to pycon!). I'm so very excited! :) This is so fantastic to hear! I'm glad it went well, and thanks very much for organizing it. I'm sorry I wasn't able to make it up there. Let me know if I can help with the whole FSF thing. -Barry From barry at list.org Wed Oct 17 16:37:23 2012 From: barry at list.org (Barry Warsaw) Date: Wed, 17 Oct 2012 10:37:23 -0400 Subject: [Mailman-Developers] Manipulate mailman in / out queue (from mailman-users) In-Reply-To: References: Message-ID: <20121017103723.45c3d60e@resist.wooz.org> [Redirecting part of this discussion from mailman-users to mailman-developers. Mark does a great job of explaining the gory details of the queue runners.] On Oct 16, 2012, at 09:23 PM, Mark Sapiro wrote: >First of all, The actual physical size of the queue directory impacts >processing. Every time an entry is added to the queue, and every time >a .pck file is renamed to .bak, the entire physical directory must be >searched to ensure this isn't a duplicate name. Depending on OS >settings, cache sizes and the physical directory size, this may >actually involve multiple disk reads each time. Thus, if the >qfiles/out/ directory has grown large because 8000+ messages were >added to the queue when the runner couldn't handle them (and there may >have been more in the retry/ queue because of SMTP failures), it would >benefit from shrinking. This is accomplished by moving (mv) or >renaming the queue directory itself aside, not just its contents and >then letting the runner recreate it when it starts. Then, if >necessary, move messages back a few at a time so the directory doesn't >grow large again. I'd like to begin to explore ways to make this automatically more manageable, so that when problems occur (e.g. upstream SMTPd not responding or slow), Mailman can recognize and response more efficiently to the problem. The first question to ask is whether this mostly affects the outgoing queue, or whether other queues *in practice* can suffer the same overloading? I suspect that the incoming queue could get filled quickly if Mailman is slow to handling an onslaught of new messages. My sense is that in general, it's the outgoing queue that gives people the most problems though. The switchboard in Mailman 3 is largely the same as in Mailman 2 (modulo updating the code to more modern Pythons). Before describing my own thoughts, I'd like to open it up and get a sense of your experiences, and strategies you think might help manage big queues. Cheers, -Barry From shacker at birdhouse.org Fri Oct 19 16:50:12 2012 From: shacker at birdhouse.org (Scot Hacker) Date: Fri, 19 Oct 2012 07:50:12 -0700 Subject: [Mailman-Developers] add_members and nomail Message-ID: <7B74B511-1A08-49D4-B95D-C2741B408974@birdhouse.org> Back in 2005, while working at an OS X Server-based organization, I wrote a bash + python script pair that extracted students/staff/faculty from a database to populate mailman lists, where many members were subscribed to various lists in nomail mode, using add_member's "-e" flag. The system worked very well. Later, we dropped OS X Server and moved to Linux, and I was surprised to find that my script no longer worked. Only then did I realize that "-e" for "nomail" was an Apple customization that never found its way into the standard Mailman distribution. I solved the problem by copying the Apple-provided add_members to my Linux systems and changing the python shebang at the top. These days, I find myself still doing the same thing on the cPanel-based systems I run, which means my systems break each time cPanel updates Mailman, and that I now run a very old version of add_members. Every organization I've worked for has had this need to batch-add people in nomail mode, which makes it really surprising to me that the standard distribution still doesn't support the option (I can't possibly be the only admin with this need!) Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included? Thanks, Scot From mark at msapiro.net Fri Oct 19 20:52:39 2012 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 19 Oct 2012 11:52:39 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: <7B74B511-1A08-49D4-B95D-C2741B408974@birdhouse.org> Message-ID: Scot Hacker wrote: > >Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included? Probably yes. The reason it was never include upstream is that Apple has *never* shared any of its Mailman changes with the upstream GNU-Mailman project. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Sat Oct 20 02:26:06 2012 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 19 Oct 2012 17:26:06 -0700 Subject: [Mailman-Developers] Logging automatic rejects of incoming posts. Message-ID: When a handler raises Errors.RejectMessage to reject an incoming post, nothing is logged. I have filed in preparation for addressing this. My question is what to log. Currently, IncomingRunner logs automatic discards with the message 'Message discarded, msgid: %s'. This is a bit cryptic. I think it would be good to have the list name in this message, but I have never changed it as that could be disruptive. It would also be possible to log which handler raised the exception, but again, that could be disruptive. With a new message for rejects, disruption is not much of an issue as existing log analyzers would presumably not recognize the message and skip it, which is no different from no message, or report the raw message. The question is whether it is a good thing to log the error message that accompanies the exception. This can be quite verbose as the error message can be the list's member_moderation_notice or nonmember_rejection_notice, but if only the handler name is logged, it doesn't distinguish between a non-member reject and a moderated member reject. Does anyone have an opinion on this? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Sat Oct 20 07:18:19 2012 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 20 Oct 2012 14:18:19 +0900 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: References: <7B74B511-1A08-49D4-B95D-C2741B408974@birdhouse.org> Message-ID: <878vb167s4.fsf@uwakimon.sk.tsukuba.ac.jp> Mark Sapiro writes: > Scot Hacker wrote: > > > >Long story short, if I were to submit a patch, would it likely be > >accepted? Or is there a good reason why it's not included? > > Probably yes. The reason it was never include upstream is that Apple > has *never* shared any of its Mailman changes with the upstream > GNU-Mailman project. Of course it has shared the changes. What it never done is to provide free labor to liaison with Mailman and integrate its changes into Mailman. Personally, I can't blame them. Even in projects where I'm a core contributor it's often difficult to get my changes in in the form that I think is best, and my experience with contributing to projects I'm not a core member of have been downright miserable. "In-spected, ne-glected, re-jected, and de-jected"[1] being a common outcome. If an assignment is the problem, that's still not a "failure to share" as defined in the open source community IMO. That's *our* failure to accept the sharing on terms that are accepted by every definition of "free software". The Mailman team has every right to choose which which changes it will devote its labor to. But the changes *are* shared -- they're available both physically and legally. It's our choice not to provide labor, or not to accept universally acceptable terms. Please let's use more accurate rhetoric, and not cut off our nose to spite our face. Footnotes: [1] With apologies to Alice and the Restaurant. From sfeng at stanford.edu Sat Oct 20 08:04:46 2012 From: sfeng at stanford.edu (Xueshan Feng) Date: Fri, 19 Oct 2012 23:04:46 -0700 Subject: [Mailman-Developers] Manipulate mailman in / out queue (from mailman-users) In-Reply-To: <20121017103723.45c3d60e@resist.wooz.org> References: <20121017103723.45c3d60e@resist.wooz.org> Message-ID: Hello Barry, I have seen both in and out queue get overloaded in our environment. We even have a Nagios monitoring plugin to monitor mailman's in and out queue size and sends alerts when it reaches a threshold. If we get mailbomb - for example, lists get hijacked and spammed, lists receive automated run away alerts (sent by programs that do not have alert interval). Under those circumstances, a few thousand messages can be pumped into 'in' queue in very short time. For situation like this, I'd find the message pattern, stop mailman service, use a shell script to scan the 'in' queue and remove these messages. Sometimes we also need to block the sending machine on incoming MTA to stop the messages coming to mailman. It would be helpful to have a utility tool to get status of the in queue - what's the top sender for example and a tool to remove them. The outgoing queue gets piled up when outgoing MTA has trouble to accept messages. In these cases, nothing to remove from the queue. Manually manipulating out queue's size becomes necessary. I think tools or automation to help quickly and reliably address the problem before it advances to a service outage would be very important improvement! Xueshan On Wed, Oct 17, 2012 at 7:37 AM, Barry Warsaw wrote: > [Redirecting part of this discussion from mailman-users to > mailman-developers. Mark does a great job of explaining the gory details > of > the queue runners.] > > On Oct 16, 2012, at 09:23 PM, Mark Sapiro wrote: > > >First of all, The actual physical size of the queue directory impacts > >processing. Every time an entry is added to the queue, and every time > >a .pck file is renamed to .bak, the entire physical directory must be > >searched to ensure this isn't a duplicate name. Depending on OS > >settings, cache sizes and the physical directory size, this may > >actually involve multiple disk reads each time. Thus, if the > >qfiles/out/ directory has grown large because 8000+ messages were > >added to the queue when the runner couldn't handle them (and there may > >have been more in the retry/ queue because of SMTP failures), it would > >benefit from shrinking. This is accomplished by moving (mv) or > >renaming the queue directory itself aside, not just its contents and > >then letting the runner recreate it when it starts. Then, if > >necessary, move messages back a few at a time so the directory doesn't > >grow large again. > > I'd like to begin to explore ways to make this automatically more > manageable, > so that when problems occur (e.g. upstream SMTPd not responding or slow), > Mailman can recognize and response more efficiently to the problem. > > The first question to ask is whether this mostly affects the outgoing > queue, > or whether other queues *in practice* can suffer the same overloading? I > suspect that the incoming queue could get filled quickly if Mailman is > slow to > handling an onslaught of new messages. My sense is that in general, it's > the > outgoing queue that gives people the most problems though. > > The switchboard in Mailman 3 is largely the same as in Mailman 2 (modulo > updating the code to more modern Pythons). > > Before describing my own thoughts, I'd like to open it up and get a sense > of > your experiences, and strategies you think might help manage big queues. > > Cheers, > -Barry > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://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: > http://mail.python.org/mailman/options/mailman-developers/sfeng%40stanford.edu > > Security Policy: http://wiki.list.org/x/QIA9 > -- Xueshan Feng Infrastructure Delivery Group, IT Services Stanford University From shacker at birdhouse.org Sat Oct 20 20:06:45 2012 From: shacker at birdhouse.org (Scot Hacker) Date: Sat, 20 Oct 2012 11:06:45 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: References: Message-ID: On Oct 19, 2012, at 11:52 AM, Mark Sapiro wrote: > Scot Hacker wrote: >> >> Long story short, if I were to submit a patch, would it likely be accepted? Or is there a good reason why it's not included? > > > Probably yes. Ah - Just realized that the project is now on 3.x, but the fix I have is for 2.x (which is also what cPanel still provides). Looking at the 3.x, the project structure (at least for the command line tools) has changed radically. Is it still worth submitting a patch if I don't have anything prepared for 3.x? Here's a simple 2.x diff in case it's useful to anyone: https://gist.github.com/3924229 Thanks, ./s From barry at list.org Sat Oct 20 20:38:06 2012 From: barry at list.org (Barry Warsaw) Date: Sat, 20 Oct 2012 14:38:06 -0400 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: References: Message-ID: <20121020143806.6d93ca71@limelight.wooz.org> On Oct 20, 2012, at 11:06 AM, Scot Hacker wrote: > >Ah - Just realized that the project is now on 3.x, but the fix I have is for >2.x (which is also what cPanel still provides). Looking at the 3.x, the >project structure (at least for the command line tools) has changed >radically. Is it still worth submitting a patch if I don't have anything >prepared for 3.x? I'd say a bug and a branch or patch would still be useful. Perhaps Mark will decide to apply this to the 2.1 branch, or someone else will port it to Mailman 3 some day. Cheers, -Barry From barry at list.org Sat Oct 20 20:45:26 2012 From: barry at list.org (Barry Warsaw) Date: Sat, 20 Oct 2012 14:45:26 -0400 Subject: [Mailman-Developers] Logging automatic rejects of incoming posts. In-Reply-To: References: Message-ID: <20121020144526.7ba4c013@limelight.wooz.org> On Oct 19, 2012, at 05:26 PM, Mark Sapiro wrote: >When a handler raises Errors.RejectMessage to reject an incoming post, >nothing is logged. I have filed > in preparation for >addressing this. > >My question is what to log. I'm not sure MM3 is any beacon of clarity here. For all intents and purposes, it just logs the Message-Id (if available) into the mailman.vette logger. bounce_message(mlist, msg) log.info('REJECT: %s', msg.get('message-id', 'n/a')) notify(RejectEvent(mlist, msg, msgdata, self)) One thing MM3 does also though is to send a RejectEvent with the mailing lisst, message, and metadata so listeners could use that to do more logging or whatever. >Currently, IncomingRunner logs automatic discards with the message 'Message >discarded, msgid: %s'. This is a bit cryptic. I think it would be good to >have the list name in this message, but I have never changed it as that could >be disruptive. It would also be possible to log which handler raised the >exception, but again, that could be disruptive. > >With a new message for rejects, disruption is not much of an issue as >existing log analyzers would presumably not recognize the message and skip >it, which is no different from no message, or report the raw message. Putting the mailing list in there is a great idea. (If you do this, maybe you'd like to work up a similar patch for MM3? :). >The question is whether it is a good thing to log the error message >that accompanies the exception. This can be quite verbose as the error >message can be the list's member_moderation_notice or >nonmember_rejection_notice, but if only the handler name is logged, it >doesn't distinguish between a non-member reject and a moderated member >reject. Logging the reason for the rejection is probably a good idea. I'd like to do the same in MM3, but currently that information doesn't make it through to the reject chain. The way to do that is probably add some additional metadata containing the reason, and plumb that through to the actual bounce code, and the logger. Cheers, -Barry From mark at msapiro.net Tue Oct 23 04:15:56 2012 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 22 Oct 2012 19:15:56 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: References: Message-ID: <5085FDDC.8050504@msapiro.net> On 10/20/2012 11:06 AM, Scot Hacker wrote: > > Here's a simple 2.x diff in case it's useful to anyone: > https://gist.github.com/3924229 Thanks. I'm inclined to implement this for the 2.1 branch, but my taste is to do it differently. I would prefer to have a -n|--nomail option which if specified would set the added members to nomail by admin, the default in the absence of the option being current behavior. Thus, no need for --enable-mail=. Also, If the member to be added is already a member, I wouldn't change its delivery option. Would such an implementation work for you? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shacker at birdhouse.org Tue Oct 23 08:07:04 2012 From: shacker at birdhouse.org (Scot Hacker) Date: Mon, 22 Oct 2012 23:07:04 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: <5085FDDC.8050504@msapiro.net> References: <5085FDDC.8050504@msapiro.net> Message-ID: On Oct 22, 2012, at 7:15 PM, Mark Sapiro wrote: > On 10/20/2012 11:06 AM, Scot Hacker wrote: >> >> Here's a simple 2.x diff in case it's useful to anyone: >> https://gist.github.com/3924229 > > > Thanks. > > I'm inclined to implement this for the 2.1 branch, but my taste is to do Sorry for response delay - no time to learn bazaar and launchpad right now for this, so I appreciate your offer. > it differently. I would prefer to have a -n|--nomail option which if > specified would set the added members to nomail by admin, the default in > the absence of the option being current behavior. Thus, no need for > --enable-mail=. > Absolutely - anything that can be scripted easily would work fine for me, and for others too I imagine. > Also, If the member to be added is already a member, I wouldn't change > its delivery option. > Hmm, not sure about that part - my implementation sometimes includes duplicate addresses, relying on the mailman import to weed them out. So I would *prefer* to have the option changed for existing members. But if that doesn't sit well with you, I understand - my script will just have to be smarter about it. Thanks, Scot > Would such an implementation work for you? > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > -- Birdhouse web and mail hosting http://hosting.birdhouse.org http://about.me/shacker From mark at msapiro.net Tue Oct 23 20:06:33 2012 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 23 Oct 2012 11:06:33 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: Message-ID: Scot Hacker wrote: > >On Oct 22, 2012, at 7:15 PM, Mark Sapiro wrote: > >> Also, If the member to be added is already a member, I wouldn't change >> its delivery option. >> > >Hmm, not sure about that part - my implementation sometimes includes duplicate addresses, relying on the mailman import to weed them out. So I would *prefer* to have the option changed for existing members. But if that doesn't sit well with you, I understand - my script will just have to be smarter about it. I don't see this as a problem. If you try to add the same address twice with a --nomail option, the first add will succeed and set nomail and the second add will fail and do nothing, but the result is the address is added with nomail set. The only situation in which this makes a difference is if the address is already a member without nomail, which would only occur if it was added previously by some other process or if it was added previously and the user subsequently enabled delivery. Either way, I think the right thing is for add_members --nomail to not disable delivery for an existing member. Note, if you want to just set some or all users to nomail, see . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From shacker at birdhouse.org Wed Oct 24 08:01:16 2012 From: shacker at birdhouse.org (Scot Hacker) Date: Tue, 23 Oct 2012 23:01:16 -0700 Subject: [Mailman-Developers] add_members and nomail In-Reply-To: References: Message-ID: On Oct 23, 2012, at 11:06 AM, Mark Sapiro wrote: > > > I don't see this as a problem. If you try to add the same address twice > with a --nomail option, the first add will succeed and set nomail and > the second add will fail and do nothing, but the result is the address > is added with nomail set. > The only situation in which this makes a difference is if the address > is already a member without nomail, which would only occur if it was > added previously by some other process or if it was added previously > and the user subsequently enabled delivery. Either way, I think the > right thing is for add_members --nomail to not disable delivery for an > existing member. True - I guess it's only happenstance that my script subscribes the yesmail members first, then does a second pass for the nomail members. I could easily reverse this order in my script. Problem solved. > Note, if you want to just set some or all users to nomail, see > . Also a good option! Thanks for that. ./s -- Birdhouse web and mail hosting http://hosting.birdhouse.org http://about.me/shacker From terri at zone12.com Wed Oct 24 08:27:41 2012 From: terri at zone12.com (Terri Oda) Date: Wed, 24 Oct 2012 00:27:41 -0600 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman Message-ID: <50878A5D.7070807@zone12.com> Since I now treat every gathering of hackers as an excuse to get people to tell me things about Mailman, I was chatting with folk at the GSoC mentor summit and my friend V was telling me that she really likes Listadmin as a nicer interface to Mailman: http://freecode.com/projects/listadmin Seems like something I might have to look at and learn some lessons from before we're done with postorius dev. Anyhow, it got me thinking: does anyone here use any other add-ons that they think I should know about? :) I used to have a set of greasemonkey scripts for my own lists, and I'll bet I'm not the only one. Terri From richard at NFSNet.org Thu Oct 25 16:36:42 2012 From: richard at NFSNet.org (Richard Wackerbarth) Date: Thu, 25 Oct 2012 09:36:42 -0500 Subject: [Mailman-Developers] [Merge] lp:~sophron/postorius/create_users into lp:postorius In-Reply-To: <20121025081846.13344.91473.codereview@wampee.canonical.com> References: <20121025081846.13344.91473.codereview@wampee.canonical.com> Message-ID: <85728E0B-B4A1-4946-9D2D-E271E9B7CB12@NFSNet.org> Isn't the visibility of the list members a per_list policy setting? In any case, we will need to have list administrators (who are not the superuser) be able to see the membership on their list. I think that Postorius will require a better model for roles. Richard On Oct 25, 2012, at 3:19 AM, Florian Fuchs wrote: > Review: Approve > > Hi George, > > thank you for your changes (and the bug reports)! I have just merged them to the trunk. I only made some very small changes and additions (adjusted the docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I also made the user list and details only available to superusers (I don't think every user should be able to see who else is there...). From p at sys4.de Fri Oct 26 08:29:23 2012 From: p at sys4.de (Patrick Ben Koetter) Date: Fri, 26 Oct 2012 08:29:23 +0200 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman In-Reply-To: <50878A5D.7070807@zone12.com> References: <50878A5D.7070807@zone12.com> Message-ID: <508A2DC3.2070503@sys4.de> Terri, Am 24.10.2012 08:27, schrieb Terri Oda: > Since I now treat every gathering of hackers as an excuse to get > people to tell me things about Mailman, I was chatting with folk at > the GSoC mentor summit and my friend V was telling me that she really > likes Listadmin as a nicer interface to Mailman: > > http://freecode.com/projects/listadmin > > Seems like something I might have to look at and learn some lessons > from before we're done with postorius dev. first of all: I don't consider listadmin a contradiction to postorious. To me listadmin is simply another user interface to mailman for another user group - those that like to run (automated) commands from command line or prefer to work on command line (like I do). One of the great improvements of MM3 over previous versions is its REST interface. IIRC it was Pycon in Chicago when Barry, Florian and I discussed about the possibilities that come along with the REST interface. We came up with ideas like "use a template to create and setup a mailinglist from command line", "do a remote backup of list settings and subscriptions", "include MM3 management in some sort of account provisioning". It's been a while since Pycon in Chicago and we might add "smartphone app to deal with post requests" or similar things one might want to do from an app. My favourite still is a command line interface to MM3 which I can run as a local REST client from wherever I am at the moment. p at rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich -------------- next part -------------- A non-text attachment was scrubbed... Name: p.vcf Type: text/x-vcard Size: 311 bytes Desc: not available URL: From barry at list.org Fri Oct 26 20:15:24 2012 From: barry at list.org (Barry Warsaw) Date: Fri, 26 Oct 2012 14:15:24 -0400 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman In-Reply-To: <508A2DC3.2070503@sys4.de> References: <50878A5D.7070807@zone12.com> <508A2DC3.2070503@sys4.de> Message-ID: <20121026141524.7f775bd8@resist> On Oct 26, 2012, at 08:29 AM, Patrick Ben Koetter wrote: >first of all: I don't consider listadmin a contradiction to postorious. >To me listadmin is simply another user interface to mailman for another >user group - those that like to run (automated) commands from command >line or prefer to work on command line (like I do). > >One of the great improvements of MM3 over previous versions is its REST >interface. IIRC it was Pycon in Chicago when Barry, Florian and I >discussed about the possibilities that come along with the REST >interface. We came up with ideas like "use a template to create and >setup a mailinglist from command line", "do a remote backup of list >settings and subscriptions", "include MM3 management in some sort of >account provisioning". It's been a while since Pycon in Chicago and we >might add "smartphone app to deal with post requests" or similar things >one might want to do from an app. > >My favourite still is a command line interface to MM3 which I can run as >a local REST client from wherever I am at the moment. Indeed, I agree with all of this. One thing we need though is an authenticating proxy for the REST API so that non-localhost users can script their own changes to lists they own or are members of. We can't expose the admin REST API to non-localhost and I really don't want to have to add the authentication layer to the default REST API (at least not right now). It's possible that such an authenticating layer could be implemented as part of Postorius, since I think Django supports REST also, and you'll *have* to be authenticated to interact with Postorius. OTOH, it would be nice if that could be provided without requiring Django. Cheers, -Barry From terri at zone12.com Sat Oct 27 23:05:12 2012 From: terri at zone12.com (Terri Oda) Date: Sat, 27 Oct 2012 15:05:12 -0600 Subject: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman In-Reply-To: <508A2DC3.2070503@sys4.de> References: <50878A5D.7070807@zone12.com> <508A2DC3.2070503@sys4.de> Message-ID: <508C4C88.6070404@zone12.com> On 12-10-26 12:29 AM, Patrick Ben Koetter wrote: > first of all: I don't consider listadmin a contradiction to postorious. Me neither, don't worry, but it's always good to learn from the way other people like to use a system. That doesn't mean "we need to do all of this too! in this way!" so much as "huh, I never thought about having an interface which showed $foo..." Terri