It's hard to get in touch with people on the Internet today, with all the spam filtering that goes on. Sometimes HCoop members are behind on their dues but are genuinely unaware of it, because our automated low balance reminder e-mails aren't reaching them. Presumably, these people either don't want to keep their memberships, in which case they won't mind if we nuke their services; or they are active HCoop users, and they'll notice if we take their services down. Thus, 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. 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 LDAP database are used for authentication to HCoop IMAP/POP, the portal, and Bugzilla. At the same time, our job is made easier by the fact that we aren't trying to stop malicious members from continuing to use our servers without paying. We'll nuke their accounts before things get to that point. We freeze accounts whose balances are close to the point where the member will have paid less than he's 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. = Things the freeze script does = == Disable log-in == * Save old shell preference, if any. * Give the user a shell that just tells him that he needs to pay his 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 his 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 '''