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

[Neulinger, Nathan]

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> >>>>> "Nathan" =3D=3D Neulinger, Nathan <nneul@umr.edu> writes:
>=20
> 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.
>=20
> Nathan> Would this be something that y'all would be willing to commit?
>=20
> Well, I'll at least express an interest in it.   A keen one, too.
>=20
> 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.
>=20
> 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).

You might consider running with the options that allow not running
salvager at startup.

> 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.
>=20
> I'd love to lock these people out for good.

An initial patch has been submitted (it's in the bug tracking system),
but there is a question at the moment if it should return EROFS or
EACCES/EPERM as the error code.=20

BTW, Not sure if it would be useful to you or not, but the "vos copy"
patch I also submitted sounds like it might be an easier way for you to
do your copies to remote sites, although your current mechanism may be
faster, would be interesting to see.=20

>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20