netatalk with the GS

[toh@victoria.tc.ca (Marc Sira)]

I recall a discussion a month or so ago regarding the use of a IIgs as a client
to a netatalk Appleshare server, and complaints of unsupported user
authentication methods (UAMs). I happened to have the means to check this out
on a small BSD box, and I can verify that it does work. My test bed was 
netatalk 1.4b2+asun2.1.0 on a FreeBSD 3.1 machine speaking Ethertalk to a
Powerbook running Mac OS 8.6 and Localtalk Bridge 2.1, speaking Localtalk to
a GS running 6.0.1 (over the unused phone wires in my apartment, actually).

The problems some people have seen - a complaint from the GS that "the
file server does not use a recognisable log on sequence" -  aren't really
in the GS's Appleshare implementation, but in afpd's current failure to fall
back properly when negotiating a UAM. This is documented in the readme file
for adrian sun's patched version, which rolls in the ProDOS and randnum
patches. Surprisingly, the GS doesn't seem to be interested in cleartext
logins (either with netatalk or with a Mac's personal file sharing) - it only
works with one-way randnum number authentication. Since afpd doesn't quite
negotiate properly (either with a GS or a Mac), you'll need to force randnum
to be used with "-randnum" (not -rand2num, which is two-way scrambling and
apparently not supported by the GS). This also requires that any users logging
in need a .passwd file in their home directory readable only by them and
containing their cleartext password in their home directory (this is something
like using APOP for mail). After this it works just fine, and continues to
work for Macs (and in fact is more secure on the network than netatalk's
default cleartext logins, albeit slightly less secure in the filesystem).

There are a couple of small caveats, such as that  Localtalk Bridge (freely
available from Apple) has slight incompatibilities with Mac OS 8.5 and later.
Documented on Apple's TIL site is the one I noticed (it crashes when changing
Appletalk interfaces, so don't do that). The other thing I noticed is probably
a bug in the ProDOS support rolled into afpd; specifically, dates go out by
exactly 30 years between the server and GS client. Files on the server with
the current date will appear to the GS to be dated 30 years in the future,
and files copied from the GS with today's date will appear to be 30 years old
to any other client, or to the server's filesystem. I should be able to track
this one down and fix it, if it's simple and not the result of some weird
interaction. At least now we know the GSOS Appleshare FST is Y2K compliant. ;)

I am surprised that the GS doesn't seem to support cleartext logins. It's not
an issue with an Appleshare server, I suppose, but having each user's password
sitting in their home directory isn't a great feeling for a Unix admin.

-- 
Marc Sira		|	toh@victoria.tc.ca
If you can't play with words, what good are they?