From: Chris Hoogendyk (hoogendyk@bio.umass.edu)
Date: Fri Sep 09 2005 - 13:52:09 EDT
(cross-posted, but these should be mostly disjunct lists -- please do
not reply back to the lists -- I will post a summary if I get anything
useful)
I'm at a point where I'm ready to say that this just doesn't work for
now, get on with other things.
I'm trying to provide AppleTalk services for Macs from Solaris 9. This
is a patched system that does have the kernel patch 112233-12, which is
extensive, fixing hundreds of issues and having a huge number of
dependencies with other patches. I built and installed Netatalk 2.0.3
from SourceForge using gcc 3.3.2, gnu make 3.80, and configured with
BerkeleyDB 4.2.52, the Solaris 9 version of tcpwrappers, and without pam.
AppleTalk over IP works. Plain AppleTalk, which depends on the netatalk
ddp kernel module, does not. I did the `make kinstall` in the
sys/solaris subdirectory, and it appeared to work without errors. When I
reboot the server, I see the ddp module loading in the kern.info
messages without any error. However, all the tools like nbplkup and
getzones simply time out without getting any information.
One of my sources says that this is a Solaris problem: if I uninstall
patch 112233, it should work, or, if I could move to Solaris 10, it
would work. Neither of these is a viable option at the moment. It seems
the issue has been around for a while and hasn't been fixed seemingly
because it is a Solaris problem and not a problem with the netatalk
kernel code.
Another source says that the ethernet packets simply have a different
class code in their header, that there is a hook in the Solaris kernel
to say, in effect, "if you see that class code, pass it to me;"
otherwise, those packets would get ignored, because Solaris doesn't care
about or deal with AppleTalk. This would seem pretty simple, and not
something that would easily get broken by patches. This source thought
there might be something in the way of ndd commands that might turn
something back on that has been turned off by the patches. Then, we
could just get it working without too much trouble. However, this
requires an intimate inside knowledge of the kernel and packet handling
as well as how something like the netatalk kernel module hooks into it.
The reason I am able to move on and leave this behind is that I do have
AppleTalk over IP working through netatalk. Also samba is working, and
Mac OS X can do either. However, it would be nice to have everything
working. Service discovery doesn't work over AppleTalk over IP, and many
printers are native AppleTalk. It would be nice to have all that
controlled by and going through the server. This is the way we have it
working for those users who are on PCs and using samba.
What I'm hoping for in this last ditch request is that someone from the
Sun, Mac or netatalk world, who has an intimate inside knowledge of what
is going on, can tell me difinitively what the issue is, how to fix it,
or what I have to wait for in terms of someone at Sun or someone on the
netatalk team doing something.
TIA
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
---------------
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:31:37 EDT