[OpenAFS-devel] Adding a "-readonly" option to file server?

Phil.Moore@morganstanley.com Phil.Moore@morganstanley.com
Thu, 24 Oct 2002 17:46:53 -0400


>>>>> "Nathan" == Neulinger, Nathan <nneul@umr.edu> writes:

Nathan> I've been looking over afsfileprocs.c, and it looks like it
Nathan> would be relatively easy to add a "-readonly" option to the
Nathan> file server to allow creating a file server that can only
Nathan> serve read only data, and not permit any updates, regardless
Nathan> of permissions. This would be ideal for mounting online
Nathan> backups of volumes, or for extra security/safety for software
Nathan> only type servers.

Nathan> Would this be something that y'all would be willing to commit?

Well, I'll at least express an interest in it.   A keen one, too.

Our huge AFS installation here is organized, for redundancy purposes,
into "campuses" of AFS cells.  For example, in NY alone, we have 4 AFS
cells that serve nothing other than RO volumes, and 2 AFS cells that
house all of the RW data.

The segregation is important, since we architect the RW servers very
differently than the RO servers.  For example, a RW AFS server is
configured with far more redundancy than a RO server, since we don't
really care about losing data on a machine that houses nothing other
than RO volumes (not counting the RW part of a replicated volume, of
course).  RW servers have fully repliacted disks, with the copy of the
data offsite, and a cluster that spans both sites, providing us with
relatively fast failover from any failure on the primary (white lie:
the salvager times can be horrible, but 30-60 minutes to recover from
a hardware failure is better than several hours).

Since we use our own homegrown architecture for distributing changes
to these volumes, and the updates are exclusively performed via vos
restore, the option you are proposing would help us close a small hole
that has bothered me for year -- namely, rogue users (the ones that
think they understand the AFS volume structure well enough to do this)
will sometimes hack a RW volume and then perform a manual vos release,
bypassing the supported up[date mechanism.

I'd love to lock these people out for good.