[OpenAFS-port-darwin] Re: port-darwin digest, Vol 1 #81 - 1 msg

Henry B. Hotz hotz@jpl.nasa.gov
Wed, 15 Jan 2003 09:17:47 -0800


Way cool!!!

Just out of curiosity, do you have anything better than the kerberos 
plugin for authentication?  What's needed IMHO is an Open Directory 
plugin instead.  That would hopefully support renewing tokens from 
the screen saver (like something Ragnar's got) as well as doing the 
right thing from an SSH login.  I assume the reason Apple hasn't 
provided a kerberos pam (even though some non-working ones exist in 
Darwin) is that they intend to push people in this direction.  I 
don't like the idea of installing three fixes when one should do.

At 12:01 PM -0500 1/14/03, port-darwin-request@openafs.org wrote:
>Message: 1
>Date: Mon, 13 Jan 2003 10:42:38 -0800
>From: Alexei Kosut <akosut@stanford.edu>
>To: port-darwin@openafs.org
>Subject: [OpenAFS-port-darwin] Patches to make OpenAFS on Mac OS X 
>more user-friendly
>
>I finally got a chance to clean up a few patches to OpenAFS that we've
>been using here at Stanford to make AFS on Mac OS X more user-friendly
>and similar to our (AppleShare-based) Mac OS 9 and Windows clients.
>Hopefully others will find them useful as well:
>
>The patches are against OpenAFS 1.2.7 and are available from
><http://rescomp.stanford.edu/~akosut/macosx/openafs/>.  I haven't
>tested with 1.2.8, but they should apply cleanly and work with a minor
>change to afsd.patch (s/28/29).
>
>- permission.patch
>     Conservatively fakes the mode bits on files and directories, so
>     that the Finder and other apps using the Carbon and Cocoa
>     libraries don't try to restrict access based on them.  This means
>     that all AFS files can be easily accessed from the Finder without
>     needing to change uids or taking any other extraordinary measures.
>
>- mount.patch
>     Allows AFS to be mounted multiple times, each mountpoint with its
>     own root volume.  This allows usage similar to the Windows client,
>     e.g., mounting a drive that contains only the user's home
>     directory.  Our users find this much easier to work with than
>     having to navigate the entire AFS tree in the Finder or open/save
>     dialog.
>
>     I have also included mount_afs.tar.gz, which provides a
>     "mount_afs" command that can be used to mount a volume and
>     register it with the DiskArbitration system so that it shows up in
>     the Finder immediately and can be ejected correctly by the user.
>
>     Note that this patch also makes it so that /afs (mounted by afsd)
>     will not unmount unless MNT_FORCE is given.  This prevents the
>     user from accidentally ejecting /afs in the Finder, and also works
>     around a DiskArb bug in Mac OS X (maybe fixed in 10.2?) where
>     autodiskmount would sometimes unmount /afs when logging out, even
>     though it's marked as non-ejectable.
>
>- afsd.patch
>     This patch has afsd register /afs with the DiskArbitration system
>     when mounting it.  This means that the root afs volume shows up in
>     the Finder immediately, and prevents the Finder from getting
>     confused by additional AFS volumes later on (i.e., if you use
>     mount.patch, you need this one too).
>
>     Also adds a "-nomount" option to afsd, which prevents afsd from
>     mounting /afs.  We use this by default on our Mac OS X client, so
>     that AFS doesn't show up in the interface at all unless the user
>     explicitly asks for an AFS volume to be mounted.  This is
>     especially handy for portable or remote users who don't always
>     have a network connection, since there isn't an AFS filesystem
>     around to hang the Finder if the AFS servers can't be contacted
>     (the cache manager may still hang, but since there are no AFS
>     volumes mounted, the rest of the OS doesn't notice).
>
>- rc.patch
>     The standard OpenAFS SystemStarter (rc) script uses grep, which
>     isn't part of the base Mac OS X install (it's in the BSD package).
>     This patch replaces the use of grep with perl, which is always
>     available.
>
>We've been using various versions of these patches here at Stanford
>for the better part of the year, and they seem to work pretty well.
>
>--
>Alexei Kosut <akosut@cs.stanford.edu> <http://rescomp.stanford.edu/~akosut/>

-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu