[OpenAFS] Questions, vol. 2.

Todd M. Lewis Todd_Lewis@unc.edu
Wed, 21 Jan 2004 13:53:41 -0500


Stephen Bosch wrote:
> More questions!

And they're darned good ones, too.  Questions that old AFS heads take 
for granted, but go a long way towards letting the newbie "get it."

> -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). What is too big? For example, I have just created a volume 
> with a 4 Gb quota, as that will comfortably fit on a DVD-R.

You've got to decide (1) what you want a volume to hold and (2) how 
you're going to manipulate its data.  You've done #2 nicely here, as 
it's something you can back up on a specific medium.

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

If I understand your questions correctly, you're asserting that 
everything that shows up in a given directory comes from the same 
volume, right? That's the case. Mount points for volumes can appear in 
any directory, however, and act like regular directories. (Mostly. 
They're really symbolic links underneath.)

> -Another partition question -- on a /vicepxx partition, where does the 
> data actually reside?

I deffer to the server-side folks on that one.

> -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.

Actually, you do want to; you just don't know it yet. :-)

> Do we have to? All the docs seemed geared to that, but all we want 
> is an AFS cell where we can save critical data and then replicate it or 
> back it up.

No you don't have to. What you outline is a perfectly fine way to start out.

> 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.

That's true enough, but hardly relevant (except for suid executables 
perhaps).  The owner's permissions are used as a mask for everybody on a 
directory's ACL. The actual owner doesn't affect access; the ACL does.

> 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?

The order doesn't matter.  The UID needs to match up, but there's no 
relation between pts group numbers (the negative numbers in your next 
question) and the UNIX gid of the local ID.

> -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"

Right. The UNIX/Linux gid for users is not relevant to AFS.  Don't leave 
them equivalent to "0" -- that looks rootly and may be dangerous. (Not 
that AFS cares, but Linux might let your users do something nasty.)

> -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? Is it better to just 
> put klog in the login script?

I use the pam_afs.krb.so.1 that got built with openafs-1.2.11 with
> auth        sufficient    /lib/security/$ISA/pam_afs.krb.so.1 try_first_pass ignore_root debug
in my /etc/pam.d/system-auth file.  I don't know why mine works when 
others are having problems. (I probably started something under a PAG 
ages ago, and since I'm the only one logging in it doesn't matter.)

Putting klog in the login script is probably not a good idea unless 
something in the login environment itself requires AFS authentication. 
In particular, klog in the login script (or AFS authentication) should 
not be required if home directories are not in AFS. If home dirs _are_ 
in AFS, then you really do want to get authenticated logins to create a 
PAG and get tokens. (I could be persuaded otherwise by a cleverly 
constructed argument, but that's my gut reaction.)
-- 
    +-----------------------------------------------------------------+
   /   Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl  /
  / A Freudian slip is when you say one thing but mean your mother. /
+-----------------------------------------------------------------+