{{{#!wiki caution The freezing process is currently somewhat broken. See https://bugzilla.hcoop.net/show_bug.cgi?id=791. 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 does = == Disable log-in == * Save 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 access == * Run `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 access == For 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 processes == For every server where members may run processes: * Run `slay $USER`. (The `slay` command comes from Debian package `slay`.) == Hide Mailman lists == Figure 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 access == Somehow 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 level == Add 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