[OpenAFS-port-darwin] Patches to make OpenAFS on Mac OS X more user-friendly

David Botsch dwb7@ccmr.cornell.edu
Thu, 27 Feb 2003 11:43:48 -0500


Hi.

First off, I wanted to say, I'm very excited about the potential of 
these patches. They give us the opportunity for things to just work as 
Mac users expect rather than having to tell mac users it works except 
if this is set like this and this happens to do this in which case this 
and that happens.

I do have a few questions:

1. Will these patches be included in the next openafs package to be 
release (presumably the 1.2.9 client)?
2. How exactly does the permission patch fake the modebits? I would 
assume it dose like appleshare does and sets the user of files and 
directories to the user logged in and sets rwx for directories? Other 
mode bits? Group mode bits?
3. Related to #2, if while a user is at the console, and another user 
sshes in, how will the ownership/mode bits appear to him/her? If two 
users ssh in? If no one is at the console and two separate users ssh in?
4. With the -nomount option, does an icon for /afs still appear on the 
desktop? How does the user mount /afs ?

Also in related business, any thoughts comments on the problem where if 
you have no afs tokens and attempt to access a folder with the finder, 
the afs server denies permission, and you see an empty folder in the 
finder. If you then klog and get tokens, the finder seems to have 
cached the fact that the folder is empty and cannot be refreshed w/o 
logging out or even restarting the computer.

And related to just apple stuff, we will see the pam module (at least 
the non-kerberos one, which does compile after hacking up the Makefile 
a bit) included with the openafs 1.2.9 package?

Thanks again, guys!

On 2003.01.15 13:16 Steve Lidie wrote:
> 
> On Monday, Jan 13, 2003, at 13:42 US/Eastern, Alexei Kosut wrote:
> 
>> 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:
> 
> With patience from Alexei, I have all the patches described below 
> installed. He even described how to create a new openAFS.pkg for a 
> double-click install.  Many thanks.
> 
>> 
>> 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.
> 
> When I, as a tokenized AFS user, try to eject my home directroy 
> mounted via mount-afs, all I get is a Finder beach ball. It doesn't 
> show up in a df output, but the icon remains on the desktop.
> 
>> 
>>     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.
> 
> Trying to eject /afs => beach ball ...
> 
>> 
>> - 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
> 
>  I've tried editing 
> /Library/OpenAFS/Tool/root.client/usr/vice/etc/afs.rc, but that must 
> not be the proper file (; So far /afs continues to be mounted.. hmm.
> 
> 
> 
> A find didn't turn up any other afs.rc files.
> 
> 
>>     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.

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7@ccmr.cornell.edu
********************************