Steven Hirsch

All,

I bought myself a Seagate Dockstar to use as a dedicated Appletalk server.
Setup was very simple, thanks to Peter Wong's excellent writeup on his blog:

http://peterwong.net/blog/?p=115

He was kind enough to fix some minor nits in the page formatting so
cut-and-paste of the commands should now work.

Can't beat a functional ARM-based Linux computer for $28 (shipping included)!

Next step was to build netatalk 2.1.2 from the Debian package and see what the
maintainers managed to break in terms of A2 support (they could care less
about us). For starters:

- All options to run a2boot have been removed from the initscripts, although
for whatever reason they left the "A2BOOT_RUN=" variable in
/etc/default/netatalk.

- The package is not built with a2boot support. Requires editing of the
debian/rules build script.

- The magic incantation to build with randnum_uam is now activated by

DEB_BUILD_OPTIONS=openssl blah, blah

- The default for protocol is now '-noddp' and atalkd is off by default in the
startup scripts.

(used to be 'ssl')

Those were easy enough to hack around and I quickly had a build up and running.

Now the bad news: They have broken preservation of file dating for IIGS
clients when writing from IIgs --> server. With my little patch installed, it
does appear to work for IIe (short-name) clients. This is going to take a bit
of chasing around through the sources and stepping with gdb. Not sure how
quickly I can get to it.

In the meantime, if anyone wants to play with this code, please contact me
privately. When the bugs are ironed out I'll make it generally available.

You will need to edit your /etc/netatalk/afpd.conf file to have this:

- -transall -uamlist uams_guest.so,uams_clrtxt.so,uams_randnum.so

and set ATALKD_RUN=yes in /etc/default/netatalk to support A2 clients. Also,
don't forget to setup Unix accounts for users and create randnum entries for
them using afppasswd.

I haven't tested the boot server yet.

Steve

A2Aviator

I wish there were something with any of that A2 support that was used
on classic Macs, that way they could be called on the carpet for
breaking functionality instead of maintaining a proper working package.

Steven Hirsch

On 10/31/2010 04:52 PM, A2Aviator wrote:
> I wish there were something with any of that A2 support that was used
> on classic Macs, that way they could be called on the carpet for
> breaking functionality instead of maintaining a proper working package.

That would be helpful. It's not that they try to break things, just that they
do not consider A2 users to be of enough importance to actually test code
changes for regression. The AFP "short name" support (ProDOS 8) was always a
poor cousin, but at least the patch was accepted when I sent it in - 12 years ago.

Whatever is broken this time is probably simple, but I suspect that fixing it
will involve the server keeping track of the type of client and using
different logic for maintaining file date depending on whether it's
"conventional" or "short name". That may or may not be so simple, depending
upon the data structures available.

I found a note to myself in the last file date patch (on the A2 list with my
version of 2.0.5) about something making a final set-attribute call with no
data under p8. Will have to do some work to recapture my thought process and
understanding of the code.

Steve

mdj

On Nov 1, 12:02*pm, Steven Hirsch <snhir...@gmail.com> wrote:
> On 10/31/2010 04:52 PM, A2Aviator wrote:
>
> > I wish there were something with any of that A2 support that was used
> > on classic Macs, that way they could be called on the carpet for
> > breaking functionality instead of maintaining a proper working package.
>
> That would be helpful. *It's not that they try to break things, just that they
> do not consider A2 users to be of enough importance to actually test code
> changes for regression. *The AFP "short name" support (ProDOS 8) was always a
> poor cousin, but at least the patch was accepted when I sent it in - 12 years ago.
>
> Whatever is broken this time is probably simple, but I suspect that fixing it
> will involve the server keeping track of the type of client and using
> different logic for maintaining file date depending on whether it's
> "conventional" or "short name". *That may or may not be so simple, depending
> upon the data structures available.

How much work would it be to develop and contribute a small test
harness that validated the behaviour of Apple II specific
functionality ?

It's almost certainly expecting too much for the maintainers to have
setup and working Apple II networks, but a harness that automates an
Apple II-alike client would go a long way towards helping this out.

Perhaps it'd start a trend, and a comprehensive test framework will
end up part of the code, facilitating refactoring and future
development

Matt

Steven Hirsch

On 10/31/2010 10:23 PM, mdj wrote:
> On Nov 1, 12:02 pm, Steven Hirsch<snhir...@gmail.com> wrote:
>> On 10/31/2010 04:52 PM, A2Aviator wrote:
>>
>>> I wish there were something with any of that A2 support that was used
>>> on classic Macs, that way they could be called on the carpet for
>>> breaking functionality instead of maintaining a proper working package.
>>
>> That would be helpful. It's not that they try to break things, just that they
>> do not consider A2 users to be of enough importance to actually test code
>> changes for regression. The AFP "short name" support (ProDOS 8) was always a
>> poor cousin, but at least the patch was accepted when I sent it in - 12 years ago.
>>
>> Whatever is broken this time is probably simple, but I suspect that fixing it
>> will involve the server keeping track of the type of client and using
>> different logic for maintaining file date depending on whether it's
>> "conventional" or "short name". That may or may not be so simple, depending
>> upon the data structures available.
>
> How much work would it be to develop and contribute a small test
> harness that validated the behaviour of Apple II specific
> functionality ?
>
> It's almost certainly expecting too much for the maintainers to have
> setup and working Apple II networks, but a harness that automates an
> Apple II-alike client would go a long way towards helping this out.
>
> Perhaps it'd start a trend, and a comprehensive test framework will
> end up part of the code, facilitating refactoring and future
> development

I appreciate your idealism, but based on my past experience with the netatalk
maintainers I think this is a long shot. I'm way too busy to put a test
together "on spec". This is a case where biting the bullet and fixing each
release is probably going to be the path of least resistance.

Steve