**PLEASE RESPOND IN YOUR RELEVANT SUBTASK IF MENTIONED.**
There is a breakdown here:
http://etherpad.wikimedia.org/p/admin_accounts_cleanup
Paste version as of 2/26/15 P336
The unique list of unconfirmed but possible people who will be removed //on some relevant server// if we let loose the cleanup logic:
* amire80 T90950
* dartar T90949
* diederik T90951
* hoo T90940
* leila T90954
* mglaser T90947
* santhosh T90937
* tfinc T90927
* tnegrin T90932
Known good removals (from the non-puppet-access-defined hosts):
* cscott - manually removed by @robh
* edenhill - manually removed by @robh
* ironholds - manually removed by @dzahn
* jamesur - manually removed by @robh
* jdlrobson - manually removed by @dzahn
* khorn - manually removed by @dzahn
* legoktm - manually removed by @dzahn
* mah T90944 - manual removal confirmed
* nuria - manually removed by @robh
* qchris - manually removed by @dzahn
* smalyshev - manually removed by @robh
* ssmith T90946 - user now uses phuedx, set key to absent, will manually check for rogue accounts later @robh
* ssastry - manually removed by @dzahn
Users to escalate/formalize access
* milimetric - T90956
Please be aware these accounts may be valid, and most probably are, but for a specific server in question the access could be old, manually added, or unknown to even the user in question. We have to justify the existence of the account in a group in data.yaml for it to persist.
I will be enabling our cleanup logic after a three phase approach to remedying this:
1. Notify the people in question
1.5 If the user replies and says they don't need the access, manually remove the user.
2. Wait a set amount of time (I plan on feeling enabled to allow cleanup after 2 business weeks which would mean as early as March 13th, 2015)
3. Give teeth to https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/admin/files/enforce-users-groups.sh and let it make our environment consistent with data.yaml