welcome: please sign in


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.

1. Things the freeze script does

1.1. Disable log-in

1.2. Remove Domtool access

1.3. Remove crontab access

For every server where we allow members cron access:

1.4. Kill lingering processes

For every server where members may run processes:

1.5. 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

1.6. 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

1.7. 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:

Not yet implemented

CategorySystemAdministration CategoryNeedsWork

MemberFreezing (last edited 2014-03-09 18:46:35 by cpe-071-070-253-241)