David-
We face a similar problem. But first: the latest AFS client (3.5 3.17)
will indeed work over a PPP connection. You most likely have the
LANadapter problem. The release notes should have more complete
instructions, but essentially, to use the client over PPP, you need to
ensure that the following registry key matches the active NetBT network
route. Check this in Control Panel--> Network--> Services--> NetBIOS
Interface--> Lana number. The default is zero; for the dial-up adapter you
normally have to use 1. You may have to add the value (if I recall
correctly it's not specified in the release notes, but I assume a DWORD
is OK):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Paramete
rs]
"LANadapter"=dword:00000000
Also, set up a network-disabled hardware profile for users who want to use
the client at home. Otherwise it simply won't work. Needless to say, this
is an irritating and cumbersome solution, even if you package the registry
change somehow. Nor does this work on Windows 2000, as yet; we're
researching this with Transarc but I suspect the problem lies in a
completely revamped implementation of NetBIOS in Win2K.
We've used Samba as a solution, on a small scale, for Win95/98 clients,
but using Solaris as the gateway platform, not Linux. We believe this will
scale better than the NT-based gateway solution from Transarc, which even
Transarc recommends using only for workgroups of approximately 20 clients.
We have ~10 clients on an old Sparc 5 using the Samba service daily, and I
personally use it as a gateway to the Windows 2000 machines of mine that
don't want to work with AFS just yet. It's completely stable on that
scale, and I doubt we've even exercised it much.
We do have a large installed base of NT AFS clients, though, and would
certainly opt for that over a Samba gateway solution on NT, since the
Samba solution offers no ACL control, etc. Our Windows users aren't
interested in "arcane" fs commands anyway, so the GUI is useful, in that
regard. So the Samba solution, in our case, really only applies to Windows
95/98 connectivity (and any other SMB client without a native AFS
client--DAVE on Macintosh, for instance, works fine in this arrangement).
The problems with Samba we've had are several:
1) Clear text authentication must be eliminated for this to work. There
was some talk at the last Decorum of coding a workaround based on the
Samba code to this, but the problems with this are no doubt beyond my
understanding, since it would involve storing the hashed NT password and
reversing the hash for the AFS authentication (or something like that).
One of my colleagues says someone wrote an authd for DCE which performs a
similar function but I don't know much more than that.
The main problem with the plain text authentication, besides the obvious
security risk, is the need to determine for EVERY client whether or not it
authenticates in plain text, and if not, to add the registry key to enable
plain-text authentication. In poorly managed domains, this is really only
possible by going from machine to machine. On any kind of scale it has to
be managed centrally or given to the user with explicit instructions.
2) Any gateway solution is subject to all the browsing problems that
normal Windows filesharing experiences. I can't speak for others but WINS
is not very well managed (read: not at all) where I am, and I've had to
resort to using LMHOSTS files on some machines to get them to see the
Samba gateway, since they adamantly refused to see it any other way.
Ugly, but the intricacies of WINS are completely uninteresting to me, and
that's about as much time as I was willing to spend on broken Windows 95
clients anyway.
3) Copying large files seemed to be a problem, on occasion, and it was
time-related rather than size-related. We eventually determined that it
was dropping the token after 7 minutes--which apparently is the minimum
possible lifespan. For some Windows machines, even small files take this
long to copy. A colleague of mine thinks he's pinpointed the piece of code
to alter so we can change this to 25 hours, the default in our
environment, but we haven't tried it yet.
There are advantages to the Samba solution, though, the most important
being the file locking, which works properly since it's an SMB share. This
is critical for the Office apps, which all seem to employ the kind of file
locking AFS can't cope with.
The info-afs archives had some code snippets to make Samba and PAM work
together, which worked on my Sun when compiling --with-pam:
http://www-dccs.stanford.edu/lists/info-afs/hyper98/0769.html
There are some linking problems when compiling --with-afs on Solaris
because of the presence of Sun versions of some libraries. It's likely
these will disappear on Linux, since that's what Samba is probably
developed on.
There's also this, a pam_linux_afs module which I haven't examined yet,
also posted to info-afs a while back:
http://www.uni-hohenheim.de/~schaefer/linux/pam/index.html
I'd be very interested in hearing anyone's experience with this. We are
also interested in load-balancing connections to a group of identical
Samba servers, and have no idea how to approach that problem as yet. This
is more critical than it sounds, since we may have to deploy some sort of
solution for thousands of extant Windows 95/98 machines, and as much as we
like Linux, the scalability needs to be there if that's the case, and
load-balancing may be required.
James Ervin
UNC-CH
On Fri, 19 Nov 1999, David Bear wrote:
> On Fri, 19 Nov 1999, Terry McCoy wrote:
> > The quality of the AFS client for Windows NT is not on par with
> > its Unix counter part. Also there is still a fairly large number
> > of Win 95/98 machines still out there (at least in our environment).
> > On Fri, 19 Nov 1999, Alex Lenderman wrote:
> > > I don't understand why you want to use Linux and a gateway to AFS for smb
> > > clients.
>
> Thanks for the comments. 1) we have many legacy win9x machine that would
> benefit from afs access. 2) the NT afs client works okay, but generates a
> lot of additional smb traffic on the wire -- we caught this the otherday
> with a packet filter. I don't know what it all means yet, but the bottom
> line is I don't think it wise (or possible) to have a general afs
> deployment on all my client pc's.
>
> Another side, afs clients on nt refuse to work over ppp connections.
> However, smb shares work fine although a bit slow. ergo, if I can gateway
> smb clients into afs, I'll have more happy users.
>
>
> David Bear
> College of Public Programs/ASU
> A word is just two nibbles and a byte...
>
>
