[OpenAFS] readonly/readwrite

[Corey Kovacs]

Derek Atkins wrote:

> Corey Kovacs <ckovacs@DEPAUW.EDU> writes:
>
> > i.e. I create readonly volumes for system stuff that I want to have
> > consistant across machines (and not let users muck with). for
> > example if I want to add the latest and greatest copy of my favorite
> > window manager and X, I could make a readonly volume for say
> > /usr/X11 and call it usr.X11, or should it be root.cell.usr.X11?
> > then create a mount point at say /afs/cellname/usr.X11 and symlink
> > it to /usr/X11. Then when I make changes to /afs/cellname/usr/X11
> > I'd do a vos release? Is this correct?
>
> Well, no.  Whenever you create a volume using 'vos create' you are
> creating a RW volume.  You create a RO clone by using 'vos addsite' to
> add a replication site, and then you use 'vos release' every time the
> data changes, to push the data from the RW to the RO volumes.
>
> Clients access volumes based upon how they are mounted.  By default,
> volumes are mounted 'RO', which means the client will use the RO
> volume if one exists, falling back to the RW volume is there are no RO
> volumes in the VLDB.  In order to make changes to files, you need to
> access the RW volume directly, and then release it.
>

> The problem with your solution is that you have no way to access the
> RW volume.  When you create a mountpoint at /afs/<cell>/usr.X11, it
> will default to the RO volumes.  You still need a way to get to the
> RW volume.
>
> MIT does this the way Transarc (used to?) recommend it: When you
> create your root.afs, you make a mount for <cell> as the normal
> mountpoint, and you make a mount for .<cell> as the read-write
> mountpoint:
>
>         fs mkmount -dir my.cell.name -vol root.cell -cell my.cell.name
>         fs mkmount -dir .my.cell.name -vol root.cell -cell my.cell.name -rw
>
> Due to the way parenting works, you can then access all the RW volumes
> in your cell under the /afs/.<cell>/hierachy, whereas you access the
> RO volumes (where they exist) via the /afs/<cell>/hierarchy.
>

So when I create a "home" volume, by default it will exhibit the behavior I
want (distributed homes) since the client will not find a RO volume because
I have not issued the 'vos addsite' command.  But when I create the volumes
for system binaries etc, I DO issue the 'vos addsite' which then creates the
RO (.usr.X11) volumes which the client tries to use by default, which again
is the way to do it. When I make changes to the RW version (usr.X11)
then I do a 'vos release' on that particular RW volume and the changes will
propogate to the RO volume and then users will have access to the new files.

I think I am starting to get this. The description of the roles that RO/RW vols

play was a big help.


>
> > Then for users, I create a r/w volume called home or users or whatever,
> > then mount
> > it at say /afs/cellname/home. Now do I create volumes for each user, then
> > mount them
> > at places like
> >
> > /afs/cellname/home/user1
> > /afs/cellname/home/user2
> > ...
> > then creating a symlink from /afs/cellname/home to /home on each machine?
> > Or can I
> > simply go into that volume and do a mkdir user1, user2 ...
>
> This is up to you.  You probably just want to have /etc/passwd use
> /afs/<cell>/home/user as the user's homedir.  If you symlink /home ->
> /afs/<cell>/home, then you lose the ability to have local accounts on
> machines.

This is actually what I want to do since this is a student lab. I don't see
anyone actually having a "local" account but if they do then nsswitch.conf
is set up to try local files for logins etc first, then LDAP/AFS. Then I could
just have a different home path (/localhome/user).

Thanx again for the help!

--
Corey Kovacs               "I know not with what weapons World War III
Computer Science Dept.      will be fought, but World War IV will be
DePauw University.          fought with sticks and stones."
765.658.4761                            - Albert Einstein