[BALUG-Admin] List migrations and preserving options as feasible - another approach ... WWW::Mechanize to load!

[Michael Paoli]

And yes, tested, for the target Mailman,
list admin can alter the relevant member's options just fine via
the web GUI ... so ...

Have what should be sure-fire method now
(and eliminates unknown bit about how long it would take for me to
figure out method via Python pickle (.pck) or similar CLI interface
method) - and it will also include verification.

So, with that, I'm guestimating I'll likely do the first *for real*
list migration sometime today or tomorrow (after writing additional
relevant code, and quite full testing, etc.).

Don't think I'll have all the lists migrated by end-of-month (I
think that was somewhat earlier target timeline), but I'm thinking
all the lists would be migrated* within 5 to 10 days from now.

*well, will take a bit longer to get mbox archives from DreamHost.com -
presuming we can get 'em to cough 'em up.

Some other fairly smallish and relatively easy bits to cover after that
to fully extricate ourselves from DreamHost.com ... but getting
rather close now.  Can almost taste it.  :-)  Yes, freedom is good!

> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
> Subject: List migrations and preserving options as feasible -  
> another approach ... WWW::Mechanize to load!
> Date: Sun, 30 Jul 2017 12:22:18 -0700

> Not sure why I didn't think of it earlier (perhaps it wasn't quite as
> obvious earlier),
> but another approach which may be highly feasible ...
> use WWW::Mechanize to load options!
> So, ... presuming it's fully workable (list admin can load? - need
> to test that), if that bit is doable - notably list admin can load/edit
> member's options on the individual members' options page,
> then that ought be fairly straight forward (moderate extension of what
> I've already coded to gather the options) - would also have
> key verification advantage - can (reload and) inspect target page
> after to ensure options match as expected (programmatically* of course).
> But I notice list admin can't make *some* member changes (e.g. disallows
> list admin to change member's password ... at least one Mailman version
> I looked at) - but setting that isn't an issue/concern - it's all the
> other options.
> Anyway, in theory (presuming the relevant tests work), could go
> quite something like this:
> "disable" old list (set "emergency" moderation, update description
>   regarding migration - effectively leave old location read-only)
> scrape source data
> stop exim (so that member settings will be suitably adjusted before
>   they're notified of subscription having been migrated)
> subscribe members - preserving email case (as user subscribed**)
> tweak user's options (using the scraped data, and also verifying results),
> restart exim
>
> *dang, I have to resort to american-english-huge before programmatically
>   passes the spell(1) check.
>
> **I also notice Mailman (at least one version I checked) doesn't let
> user's change their email address to another version of same email
> address but only with changes in case - it complains that they're
> already subscribed/member - or something to that effect.  Now, I
> could see requiring email verification if case of localpart changes
> (as they *could* be distinct addresses/recipients), but seems
> Mailman ought handle that same way it does for user making any
> other change to their email address.
>
> Anyway, presuming it works, may well get me to the needed load
> functionality more quickly than the Python pickle (.pck) route
> or the like - plus has the verification advantage.
>
>> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
>> Subject: Re: lot of really nice command-line tools to use in  
>> dumping and editing various pck databases
>> Date: Sun, 30 Jul 2017 11:55:20 -0700
>
>> Thanks, slick, noted.
>>
>> I also noticed there's package (mailman-api)for a REST API for Mailman.
>> I also found a very promising mmclient (which uses Mailman's REST API),
>> but alas, don't see a corresponding package by Debian.
>>
>> Also thought of something else highly practical ... but, topic drift,
>> will post that separately.