Subject: Netatalk 1.5 Success was Re: Netatalk on 64-bit Solaris with GCC ...

From: Xiaping Lin <[email-masked]>
Date: Mon, 07 Jan 2002 14:17:49 +1000

Hi,
Just to let everyone know that regardless following error(setsockopt ....) occurs in
/var/adm/messages
when starting atalkd, the new version 1.5 that I compiled with 64-bit gcc does NOT
have problem of
not appearing in Chooser! I have tested on a few Macs. I don't need the cron job any
more!!
Thanks again everyone.

Here is another question:
Why uams_dhx.so does not work ?
I did not specify "--with-shadow" during configuration, would is be the reason DHX
authentication does not work?
It seems that if both uams_clrtxt.so and uams_dhx.so are listed in afpd.conf,
MacOS7.x machines pickups
clear_text password method to authenticate, but MacOS9 pick up uams_dhx.so for
password authentication, but did not work in my case.
I would like to get DHX authentication working for both MacOS7.x and MacOS9
machines. Is this possible?

Cheers!

Xiaping Lin wrote:

> Hi,
> My sincere gratitude to Celeste Suliin Burris, Joe Clarke and Steve Freitas for
> the help on compiling
> Netatalk1.5 on 64-bit Solaris machine. I have succefully compiled 64-bit gcc and
> ddp and Netatalk1.5.
> But to my horror, the same error messages shows up when I start the new atalkd
> (v1.5):
>
> Jan  3 21:18:48  atalkd[29352]: [ID 441591 user.info] plumbed /dev/ge0
> Jan  3 21:18:48  atalkd[29353]: [ID 602610 daemon.info] restart (1.5.0)
> Jan  3 21:18:48  atalkd[29353]: [ID 430690 daemon.info] setsockopt incompatible
> w/ Solaris STREAMS module.
> Jan  3 21:18:50  last message repeated 1 time
> Jan  3 21:18:50  atalkd[29353]: [ID 875075 daemon.info] zip_getnetinfo for ge0
> Jan  3 21:19:08  last message repeated 2 times
> Jan  3 21:19:18  atalkd[29353]: [ID 877925 daemon.info] config for no router
> Jan  3 21:19:20  atalkd[29353]: [ID 430690 daemon.info] setsockopt incompatible
> w/ Solaris STREAMS module.
> Jan  3 21:19:20  atalkd[29353]: [ID 128247 daemon.info] ready 0/0/0
> Jan  3 21:19:32  papd[29364]: [ID 602610 lpr.info] restart (1.5.0)
>
> I am afraid that the same problem(server not showing in Chooser) happens to the
> new version, although
> I have not yet confirm this, since I do not have access to a Mac at that time.
> At present, my workaround
> is to have a cron job running "nbplkup" on the SUN Netalalk server every minute
> to force it stay up in all
> mac's Chooser. From a mac, I can connect to the server by IP, but most Macs here
> don't have that option
> in Chooser.
>
> I have seen some talk about the setsockopt patch, such as the e-mail below:
>
> http://www.mtusysadm.mtu.edu/mtudocs/netatalk/netatalk-combo.html
>
> But don't know if the patch has already been considered in the new version. Is
> there any patch that I should apply?
>
> My platform for Netatalk server is : Sun e420 Enterprise Solaris8
>
> Any tips on how to fix above error?
>
> Thanks everyone!
>
> Xiaping
>

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 07 Jan 2002 08:30:20 +0100

> Why uams_dhx.so does not work ?

Please post the relevant lines from your messages when you startup afpd.

> [...]
> MacOS7.x machines pickups clear_text password method to authenticate, but
> MacOS9 pick up uams_dhx.so for password authentication,

When you connect to an AFP server the client gets a list of possible UAMs
(User Authentication Modules). He compares the server's list with the ones,
he is able to handle (either builtin or via third-party modules in
SystemFolder) and tries to choose the best match.

DHX Authentication worked the first time with AppleShare Client 3.8.1 (see
<http://docs.info.apple.com/article.html?artnum=58373>) but with MacOS up to
7.5.3 you can only use 3.7.x. So you should upgrade to OS 7.6.1 and choose
3.8.3 (to avoid some problems with 3.8.1 and server aliases). Look at this
overview to find out, which AppleShare client to use with which OS version:
<http://docs.info.apple.com/article.html?artnum=60792>

> but did not work in my case.

Do you have a MacOS X box around? As Leland wrote once before, you can turn
on debugging output that helps in situations like these, too:

| On Thu, 15 Nov 2001 09:33:21 -0800, Leland Wallace wrote:
| 
| > From the terminal in Mac OS X type:
| > setenv AFP_DEBUG_LEVEL 8
| > mkdir /Volumes/volname
| > /sbin/mount -t afp afp://username:password@servername/volume \
| >     /Volumes/volname
| >
| > replacing username, password, servername, volume, and volname with your
| > local names

This will give you probably some hints, what's happening...

> machines. Is this possible?

If you upgrade the MacOS 7.x machines to 7.6.1 and their AppleShare Client
to 3.8.3 then it should.

Regards,

Thomas