SRCF: Bit Rot

Coping with bitrot

The SRCF's current operating procedures don't recognise the extent to which the Society's userbase is dynamic. Whereas there are procedures for creating and (to a lesser extent) zapping users, there's no real equivalent in respect of societies. The policy of allowing user and society material to rot away on the Facility is gradually being abandoned under pressure from resource issues, takedown requests, privacy concerns, etc. In principle, no user or society is immortal, and it is not in the interests of the Society to manage its resources as though they were.

The way the system works currently is as follows: there is a well-defined set of people who are supposed to have access to the Facility. In response to certain events (emailed requests from users, and the end of the academical year), the Membership Secretary and the sysadmins manipulate the Society's records, causing members to gain and lose access to the Facility. For societies, there only exists a reactive procedure for adding new societies, and associating and desociating users from societies. Holistically, there is never an assertion to the effect "these users should have access - make it so";

As a technical matter, this is all simple: you just disable accounts of people who shouldn't have access. The substantive issue is a matter of membership administration. Currently the Membership Secretary has, unless the author is mistaken, a largely reactive rôle.

The SRCF has finite resources, yet it delegates access and authority on a non-time-limited basis to users, groups and sysadmins. Only the constitutional limit of (renewable) annual terms on the committee, and the rules governing CUDN access, serve to limit these delegations.

User bitrot

Regarding users and members, the situation is clear: the CUDN rules will eventually cause all users to lose access (ignoring the trivial case of those who get jobs with the University). The only minor issue is the membership status of alumni in the absence of financial fees for membership. Between the expiry of CUDN authorisation, and the removal of access to the Facility, there exists a delta which can in some cases be quite wide (and open long enough to allow at least one root compromise of via a user account which should have been purged). All that needs to be done is tighten up the procedures for catching purgeable users, which means being pro-active rather than reactive, and defining more precisely what removal of access means in terms of email, web, voting rights, existing associations with societies.

Society Bitrot

For societies the problem is much greater. Not every group on the SRCF is a society in any meaningful sense of the word. Bands, JCRs, and other projects and collectivities are (rightly) lumped together under this category. It is difficult for the SRCF to know when such a group has stopped existing or at least ceased to want to use the Facility. There exists no procedure for removing societies, no script in /usr/local/sbin which might accomplish this, but it wouldn't be hard to write one. The problem consists in knowing when to use it. Once again, pro-active membership administration is required.

Sysadmin bitrot

With regard to sysadmins the problem is mildly political, since suggesting that old or dormant sysadmins ought to be given the push might be construed as reflecting personally on particular individuals. The author (who was SRCF Chairman in 2000, twice a sysadmin, and is still a card-carrying interfering old fart) has no particular stake in these questions any longer. The proposal is a constitutional amendment stating that all delegations by the committee, including the appointment of sysadmins, automatically expire 14 months after the most recent AGM unless renewed. The webpage containing the list of officers should provide details of the expiry of the term of office of each individual. There seems no reason to exclude the Membership Secretary and Senior Treasurer from this arrangement.

Ultimately, the principle could be generalised: if the Society has no contact with a given user or society for some Committee-specified period, they get a warning or their account gets suspended, disabled, deleted, etc. Basically, once bitrot has been accepted as inevitable, the level to be accepted can just be treated as a parameter of the SRCF system as a whole and dealt with.

Conclusion

At any rate, just as the Linux kernel has evolved to cope with hardware which changes after bootup, such as USB, the SRCF should evolve to deal with the reality that access to its facilities should not be permanent, and shed itself of the inertial drag of people who have access they don't need (and tie down resources they don't need, such as disk space). Everyone should be viewed as ephemeral.

As a refinement, it should perhaps be noted that shell access for users and code execution access for societies is no longer the only type of service provided, and may be overkill for what some users want to do, and that any monitoring of whether a user or group is dormant ought to include checking whether execution access is required so that it might be removable without affecting what that user wants to do.