[OpenAFS] Questions, vol. 2.

[Russ Allbery]

Stephen Bosch <posting@vodacomm.ca> writes:

> -Volumes and volume sizes -- what do you use as a typical volume
> size/quota? The default is 5 Mb, which is ridiculously small (and points
> toward an assumption that AFS will be used largely for user home
> directories).

The volume creation command probably doesn't really need a default.  5MB
is a reasonable size for your root infrastructure volumes, though
(root.afs, root.cell), since in general those volumes will only hold mount
points for other volumes.

What size of a volume to use depends entirely on what you want to put in
it.  For example, we install every separate software package in its own
volume just for ease of administration, so we have lots of replicated 5MB
volumes.  We also have data volumes as large as 12GB.

Our experience is that end users get very confused when their workspace is
made up of multiple volumes, so in general you want to try to put each
coherent workspace in a single volume.  This doesn't always work, though,
particularly if you're using replication and want to release portions
independently, or if you want to keep volume sizes smaller for backup
reasons or just so that moving them between servers doesn't take forever.

In general, we try to limit volume size to 2-4GB, mostly so that we can
move volumes around in reasonable amounts of time.

> -Volume granularity -- at a minimum, a volume must correspond to one
> directory, correct? In other words, I can't concatenate volumes invisibly.

Right.

> -Unix/AFS user account synchronization: We have two existing workstations
> that are heavily used. These workstations will also use AFS, but we don't
> want to move their local home directories to the AFS cell. Do we have to? 

No.  It's quite reasonable to have a home directory on local disk and then
put some files in AFS.  In fact, my desktop machine works that way, and
this often seems more natural for Windows users, who like viewing their
AFS home directory as a network drive they can copy things to and from.

> The docs leave me with the understanding that a client workstation will
> treat the mounted AFS filespace the same as a mounted local disk. That
> is, a file owned by user ID 501 in AFS will appear the same as a file on
> a local disk owned by user ID 501.

This depends a lot on what you mean by "the same."  ls will show the
ownership to be the same, but remember that the UID ownership of files is
mostly meaningless in AFS.  Access control is managed through
per-directory ACLs that (apart from a few exceptions) don't care about
owners at all.

It's nice for consistency to use the same UIDs in PTS that you use on your
individual systems, but it's not actually necessary for AFS to work
correctly, and in fact my login UID on my workstation is not the same as
my PTS UID.  Files stored in AFS will be stored owned by the PTS UID of
the person who created them.

> If I want to create a new user in the cell, does this mean that I have
> to first create a user in AFS create a user on the user's workstation
> with the same UID/GID as the new AFS user?

No, there is in fact no need to ever create the local account if you don't
want to.  :)

I'd encourage you to make the local UID match the AFS UID (AFS has no
concept of GIDs and doesn't care about them at all except for setgid
programs -- which even then isn't actually AFS caring about the GID),
though, just to remove confusion.

> -Group IDs -- AFS uses negative group ID numbers. The Linux machines
> have no idea what to do with that -- they just read the group ID's as
> "0"

I don't know what you mean by this.  PTS group IDs have nothing to do with
Unix groups and do not own files.  Linux should never see those numbers.
They are not GIDs and have nothing to do with GIDs.

PTS groups are solely and exclusively a mechanism to more easily manage
directory ACLs.  That's it.

> -afs-modified login, etc. The documentation recommends using the afs
> modified login. In our case, that essentially means using pam for afs
> authentication, but as one poster has just pointed out, some
> applications like openssh don't always function properly with the afs
> pam module. What do you use in your installations?

We replace login with a Kerberos-aware login and patch OpenSSH to have
more sense about AFS.  But this is an aggressive stance coming largely out
of the fact that we've been running AFS since 1992 and exclusively since a
little after that, and probably isn't necessary any more.

> Is it better to just put klog in the login script?

Not from the user perspective because they have to type their password in
again.  It should be possible to get OpenSSH to play properly with your
PAM modules, although you may have to turn off privilege separation.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>