[OpenAFS] What changed with 1.3.74?
Fri, 12 Aug 2005 05:56:19 -0700
Thanks for the response, Jeffrey.
I'm mostly concerned with the change between=20
1.3.73 and 1.3.74 since anything after 1.3.73 breaks in our environment.
Our servers are TransArc v3.6 and the admins are=20
too overwhelmed with other priorities to update=20
it, which is very unfortunate. I don't believe it supports K5.
I've poured through afs-install-notes and have=20
found some gems, but also found some confusing points:
"If KFW is installed, the Integrated Logon will=20
use Kerberos 5 to obtain tokens. Otherwise, Kerberos 4 is used."
This is confusing, since our installation uses=20
Integrated Logon and KFW, but I believe we can=20
only get tokens with K4 tickets because of the=20
TransArc server. I did a couple days of testing=20
NOT using Integrated logon because this verbage=20
led me to believe it would be requesting a token=20
with a K5 ticket from our servers. When I=20
finally did install using the Int. Logon option,=20
I was very surprised when 1.3.73 worked.
In terms of what is not working:
Any version past 1.3.73 (even on a clean bare XP=20
SP2 box), will hang Explorer when I attempt to=20
map an afs path using the afscreds GUI or cmd=20
line "net use x:=20
//afs/cats.ucsc.edu/users/t/mcintyre". We have a=20
cross-realm authentication scheme, so KFW gets=20
the tickets automatically. I disable AFS tokens=20
within KFW, because I found that it confuses the=20
AFS client (this might have been fixed,=20
dunno). THe workstations are used in general=20
access labs, so we run a script that runs=20
afscreds -a -q, finds their AFS path via LDAP,=20
creates a submount (I know you're against this=20
now), and maps the X: drive to //afs/home. For=20
testing, I've disabled the logon script and ran=20
it all by hand. Everything works like a charm=20
until I actually try to mount an AFS path.
1.3.73 seems to be working well now, but we're=20
very concerned about it and we've put it on=20
"probation". During the summer, we've had about=20
10% of the lab machines hang at login when the=20
AFS script runs. Since this failure rate is=20
unacceptable, and we're very concerned that some=20
new hotfix will break the version of the AFS=20
client that we're stuck at, we're starting to=20
research other methods of accessing the user's=20
home directory, like Explorer integrated SFTP=20
clients (MKS, Hummingbird, Web Drive, etc). It's=20
currently contentious, since I'm advocating for=20
the SSO aspects of AFS, but others in our group=20
are concerned about stability and=20
reliability... I wish I could wave my magic wand=20
and have our AFS servers updated, but that's not=20
going to happen any time soon.
At 02:37 PM 8/10/2005, Jeffrey Altman wrote:
>Charles McIntyre wrote:
> > We've been able to get OpenAFS 1.3.73 with KfW 2.6.5 to work with our
> > cross-realm Kerberos login, but any version after that breaks Windows.
> > What changed from 1.3.73 to 1.3.74 and subsequent versions? I looked at
> > the changes doc, but nothing rang out...
> > We've even tried installing 1.3.74+ on a base XP Pro SP2 system and it
> > still hangs explorer. I'm wondering if it has something to do with our
> > server software.
> > Any ideas?
> > Thanks!
> > Charles
>Lots of things have changed since 1.3.73.
>What is the version of the servers in your cell? Does it support
>Kerberos 5? (aka OpenAFS 1.2.8 or higher?)
>Have you followed the debugging instructions in the
>What is not working? Integrated Login? Obtaining tokens with the
>AFS System Tray tool?
PC/UNIX Systems Engineer
Information Technology Services, UCSC
got a question? see http://ic.ucsc.edu/help =20