Communicating with 'education' list admins to discuss spam practices. List is active and admins are current WMF employees. Just noting.

So; on record we have the following:

this task was meant generally for looking at that list and creating tickets for action with lists if there is a characteristic to look at (e.g. a list has no moderator and so on). This ideally should be a master ticket. I'll make it generic and start looking at lists.

Resolved in my opinion. Now let's look at these lists and figure why they have tens of thousands of emails in moderation.

A summary? Sure. Will sum up and add any breaking / fun stuff separated for people.

@Jalexander also to make things easier for Daniel, to clear up uncertainty and document something relating to mailman correctly (T109534 as an irrelevant quip), who outside of operations has/needs the password?

Probably coordinate this with the migration as we're planning on changing it anyway.

https://gerrit.wikimedia.org/r/#/c/235065/ moves the variable to hiera allowing role and host overrides instead of in site.pp (following ganglia's cluster variable setting) and defaults to 'admins' if not set.

I've looked at this and the implementation seems fairly straight forward (though depends on personal definitions).

Needs clarify above though. Suffix is missing for some lists like wikiru-l and then a few Wikimedia's are listed.

Glancing over the above list and recalling memories related to them (but not tickets right now; perhaps will track these tomorrow if needed), they're not real lists. Some are either deleted (tools-wmt-staff as I requested it) or disabled in a bad way (Wikitech-announce as an example, renamed twice by directory).

Seems to have little use being public. I'd got for a rmlist as the archives don't really serve a purpose. @Dzahn

Perfect chance to see disable_list.sh in action :)

http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1086 adds the cron we're interested.

So crons do run - just not all jobs.

Thanks for reopening I guess. Anyway, resolved by following a bit of @jcrespo's advice which can be seen in the commit.

qfiles; this can be handled two ways. We could stop mailman with exim and rsync them or we can hold exim and let mailman run for a defined period of time (10 minutes to be safe) before we stop it. This would mean we don't actually have to rsync the qfiles at all and any held mail like pending and so on would also be cleaned up which makes an rsync easier, cleaner and reduces chance of duplicating out-going emails.

Added the table to the description.

@RobH would be the best person in regards to this.

policy.wikimedia.org is behind misc-web-lb as such it doesn't have its own SSL cert but instead uses star.wikimedia.org. So this would need a certificate to be issued if needs to be off the cluster.

I've looked at this. If we add lists.wikimedia.org to the hold domains and increase the retry time (to at least 4 hours, the window length), then all emails should be written to /var/spool/exim4/input.

Will review user impacting changes via the change logs but I dobt think there are really.

@akosiaris nothing is dependent on fermium, everything we need has been puppetised and only a single file exists in my home directory which will be lost (which can be). So feel free to proceed when you can. Thanks.

Since I cant edit comments, 14 is done and depends on 15. Since nothing else depends on fermium existence as is and other work is blocked, I'm going to give Alex an okay go move fermium from private to public spaces.

4 hours seems fair of a maintenance window. Looking at the plan we've drafted [need to make public :)]; we're just doing a 'what has changed' rsync after stopping mailman and holding exim. 4 hours seems more than safe with the lowered TTL.

@akosiaris can we modify and reinstall the current VM or do we need to delete it and re-create it from scratch with a vlan?

Below is my final compiled list of what should and shouldn't go.

@eliza Keeping tasks focused on a single goal is best and helps manage work flows easier. As such I've created T109868 for moving the alias to Google Mail and assigned it to Joel for now. Feel free to use that task to update on the progress of this. Thanks :)

Last real usage goes back to 2 years, archives don't directly seems relevant or of use currently. A deletion is fine though a disable will also be sufficient.

Created and sent the password list to Ryan.

From the VM creation task and Alex comments there - my understanding is Ganeti is just using the public subnet for eqiad c1 and no specific subnet beyond that.

Presumably the disable followed the old system so I recommend we reverse it and just correctly disable the lists.

To resolve a main issue right now; here is a very quick modification to the documentation I'll apply (noting here as well).

They should also come under this task ideally then to improve them if need be. History goes back to 2004 and looking at it, seems mostly the same content so best to verify.

data is not needed if we do things right. As in actually reset passwords and so on.

The archives weren't online when we began and shouldn't be in the end. If they were meant to be; it would not have been renamed out of existence. Instead it would have been unadvertised and all emailed dropped in oblivion.

Done. Emailed to the original email in the task description.

@Slaporte we do this during the change so this is already done.

Taking back. Will handle in due time with the rename clean up.

archives; yes
bin; no
cgi-bin; no
cron; no
data; to my knowledge - not necessary. Just stored site password, list creator password and version. Ideally, all should be different (and lists need them to be changed after import)
icons; no
lists; yes
locks; no (symlink)
logs; no (symlink)
mail; not to my knowledge; [verify] (symlink)
Mailman; no
messages; no
qfiles; yes
scripts; no
spam; unsure, need to verify usage definitely.
templates; managed by puppet.
templates*; no reason for them to exist.
tmp; usage unknown. verify on sodium its usage.

anything works. The T just needs to go as a capital.

Asked James on IRC, he's going to follow a response up. +cc Philippe and James.

Hate to be a pain but since you're doing this already tomorrow (let's look at expanding the windows to 2 hours perhaps to be safe), could you handle this as well?

Clarify: List *names* can be capital. List identifiers (the /listinfo/* part and directories and what Mailman knows the list as) can't.