MemberFreezing92014-03-09 18:46:35cpe-071-070-253-241.nc.res.rr.comPruned the top description in case a non-sysadmin person wants to figure out what/why they got frozen.82012-12-18 21:55:08ClintonEbadithis page and freezing in general need serious work72012-09-06 07:09:43ClintonEbadicategories, needs work62008-07-07 04:28:14localhostconverted to 1.6 markup52008-06-29 16:20:3078.134.206.19742008-06-29 16:20:1678.134.206.19732008-06-29 16:18:0978.134.206.19722008-06-29 16:15:4178.134.206.19712008-05-31 18:26:15AdamChlipalaThe freezing process is currently somewhat broken. See . This documentation is from before freezing was implemented, and must be updated. Our last resort for getting ahold of delinquent members is taking down as many of their services as we can manage to do in a generic "member freeze" script. A corresponding "unfreeze" script restores everything idempotently* once a member pays up. We freeze accounts whose balances are close to the point where the member will have paid less than they've been charged. We freeze accounts at least a month ahead of this point, giving members a chance to notice that their services are down and pay up before we need to boot them. Crucially, we want to leave alone anything that they host with us that could be important for facilitating online communication between them and us. This refers mainly to e-mail and access to the HCoop portal and Bugzilla. One consequence is that we can't reset a member's password, since passwords from our Kerberos database are used for authentication to HCoop IMAP/POP, the portal, and Bugzilla. * In a way that won't mess up the services after unfreezing. Things the freeze script doesDisable log-inSave old shell preference, if any. Give the user a shell that just tells them that they need to pay their dues to have access restored. The message should point to the portal front page, saying that information on how to pay is found there. The message should also give the e-mail address admins@hcoop.net as the last resort place to send requests for help, if the member has forgotten their password or can't access the portal for some other reason. Remove Domtool accessRun domtool-admin perms $USER
to get $USER
's full list of Domtool permissions. Save the results somewhere, to use when unfreezing. Run domtool-rmuser $USER
to remove $USER
's Domtool permissions and tell all daemons to stop serving domains that only $USER
can configure. Remove crontab accessFor every server where we allow members cron access: Check whether the member is in /etc/cron.allow
on that server. Save the result somewhere, to use when unfreezing. Remove the member from /etc/cron.allow
, if present. Kill lingering processesFor every server where members may run processes: Run slay $USER
. (The slay
command comes from Debian package slay
.) Hide Mailman listsFigure out which lists belong to this member and temporarily block them at the Exim level? Auto-reply to post attempts suggesting that the poster complain to the delinquent member would be great! Not yet implemented Revoke database accessSomehow revoke permissions on MySQL and Postgres databases, in a way that can be reversed in unfreezing. This seems like low priority and can almost certainly be left out of the first version. (Though maybe it could be done easily by unmounting the member's database volume, though we want to leave his other volumes mounted.) Not yet implemented Disable services on PAM levelAdd username to /etc/frozen.users or something, and have not being mentioned in that file as a prerequisite for PAM success. Two things to take into account: must be done on all servers unless file is in AFS some services should not honor that file (email most notably) Not yet implemented CategorySystemAdministration CategoryNeedsWork