[OpenAFS-port-darwin] Re: Many crashes on OS X 10.3 - MP problem?

[Ragnar Sundblad]

--On den 15 februari 2004 13:21 -0500 Gedaliah Wolosh <gwolosh@njit.edu> 
wrote:

> I have been running an openafs client on my G4 powerbook since Mac OS
> 10.1 without a kernel panic.  I have had the finder hang and other
> minor annoyances but stability has generally not been a problem.

Another PB working good, interresting.

Typically all kinds of applications hangs or at least gets
inresponsive when your tokens expire - are you sure this is
not the problem you see?

(We currently use an app that renews kerberos tickets and
tokens every now and then, we launch it automatically for
all users.)

> As an aside, it would seem to me that if Apple wants to make serious
> headway into academic institutions, then full integration with AFS is
> absolutely needed.

I agree. I am very happy that there are (at least have been)
people working on AFS within apple. (Remember that this is
more than you can say about most of the other companies you
mentioned...)

> 1) The login window does not integrate with AFS.  You need Krb5 and the
> login.logout hook supplied by Kosut. Integrating the login window with
> pam would be a great improvement.

I think it can use PAM, can't it? I don't know why you would,
though, I have never seen PAM solve any problem that I couldn't
solve better and cleaner and with less trouble with other means.
PAM is also just an login-time user authentication mechanism
that integrates poorly with many combinations of programs and
back ends, it doesn't solve all the other problems that for
example krb solves.

Why wouldn't you want Krb5? If you use AFS you (currently) need
kerberos 4 on some form, and you don't want krb4 since it is
insecure and old, you want krb5 with afs compatibility ("2b").

> 2) As Joe Jackson has mentioned much earlier on in this list, there are
> reasons to give users local home directories, with links into the afs
> home directory for ~/Library, etc...  This is inconvenient and not
> necessary in any other Unix client.

We have home directories for all our 12K users in AFS. We have
some links for some app caches up in /tmp that we establish
at login time. Most things work really good.
Portable use is another issue, but that is an AFS "problem",
not an Mac OS X problem.

> 3) Although not necessarily an Apple problem, some software will not
> install correctly in AFS, Adobe Photoshop for example.  In our university
> we prefer to install all of our software in AFS volumes and make it
> available to all of the clients.  Photoshop will not even let a user
> save files to, or retrive files from an AFS directory.

Yes, there are such problems. Except the access() problem
(some programs look at the rwxrwxrwx bits of which some are
meaningless in AFS), it is mainly a problem with just a few
applications.
I have never looked into what the problem really is, but
since these programs often work on UFS and AppleShare, I
tend to think that it actually is some problem with the
AFS client semantics that could be solved.

> 4) As reported in this list there are significant instabilities using
> Panther.  OpenAFS.org does not have a latest release package for Jaguar.
> This instability will need to be addressed.

Yep! How much we all would love to see Apple do that, I am
afraid that we can't count on it. I think we need someone
who understands this code to take a look, and for now I think
it must be someone outside apple.

It is probably something trivial, we just need the right
person to take a look.

/ragge