Subject: Success: Compiling netatalk-1.4b2+asun2.1.4 with pam and dhx under RH7

From: "Guillaume" <[email-masked]>
Date: Fri, 23 Mar 2001 10:59:44 +0100

Hi,

I encounter a lot of troubles when I tried to do a rpm based install of Netatalk (netatalk-1.4b2+asun2.1.4) on my RedHat 7.0 server.

Only guest login were OK...cause the rpm binary install do not support pam, des, ssl by default :-(

One night after, and reading this mailing archives, I did it successfully.

So here are my tips, hoping it will help someone one day!

Compile your kernel with support for Appletalk DDP as a module.
(I use a custom modified kernel based on 2.2.16 kernel instead of the 2.2.16-22 from the RH7)

If not installed, install the external libs: pwdb, pam, openssl
easy install with RH rpms: 
openssl-0.9.5a-14
openssl-devel-0.9.5a-14
pam-0.72-26
pwdb-0.61.1-1

also, check that you have the /usr/include/des.h on your box.

Install the source from the rpm : 
rpm -i netatalk-1.4b2+asun2.1.4-0.i386.rpm

cd /usr/src/redhat/SOURCE (where rpm put it!)

to unzip the source:
tar -zxvf netatalk-1.4b2+asun2.1.4.tar.gz 
cd netatalk-1.4b2+asun2.1.4

then edit the Makefile
uncomment the install prefixes:
SBINDIR=${INSTALL_PREFIX}/usr/sbin
BINDIR=${INSTALL_PREFIX}/usr/bin
LIBDIR=${INSTALL_PREFIX}/usr/lib
RESDIR=${INSTALL_PREFIX}/usr/lib/atalk
ETCDIR=${INSTALL_PREFIX}/etc/atalk
INCDIR=${INSTALL_PREFIX}/usr/include
MANDIR=${INSTALL_PREFIX}/usr/man

set the crypto dir var to:
CRYPTODIR=/usr/include/openssl
( this is the default location from the openssl rpm install)

set the vars:
DESDIR=/usr/lib
PAMDIR=/usr

and, (and also that's why I spend one night awake), edit the etc/uams/Makefile and near the line 43, change:
CRYPTOINCPATH="-I${CRYPTODIR}/include -I${CRYPTODIR}/include/openssl";\
by :
CRYPTOINCPATH="-I${CRYPTODIR}"; \

then run a : make depend; make && make install

edit your /etc/atalk/afpd.conf and  add the needed dso modules to the uamlist of your config.

then start the daemon:
/etc/init.d/atalk start

check the /var/log/messages for lines like:

afpd[7991]: uam: uams_dhx.so loaded
afpd[7991]: uam: uams_randnum.so loaded
afpd[7991]: uam: "2-Way Randnum exchange" available
afpd[7991]: uam: "Randnum exchange" available
afpd[7991]: uam: "DHCAST128" available

...

note that some of the dso are links:
#ls -al /usr/lib/atalk/uams/
total 48
lrwxrwxrwx    1 root     root           11 mar 22 17:24 uams_clrtxt.so -> uams_pam.so
lrwxrwxrwx    1 root     root           15 mar 22 17:24 uams_dhx.so -> uams_dhx_pam.so
-rwxr-xr-x    1 root     root         8757 mar 22 17:24 uams_dhx_pam.so
-rwxr-xr-x    1 root     root         5948 mar 22 17:24 uams_dhx_passwd.so
-rwxr-xr-x    1 root     root         3386 mar 22 17:24 uams_guest.so
-rwxr-xr-x    1 root     root         6027 mar 22 17:24 uams_pam.so
-rwxr-xr-x    1 root     root         4001 mar 22 17:24 uams_passwd.so
-rwxr-xr-x    1 root     root         9286 mar 22 17:24 uams_randnum.so

that's it, now my Mac clients are able to login with their Unix accounts too, no need for .passwd files!

a call to sleep(12*3600) needed now :-)

Guillaume.

---

From: Jason Quigley <[email-masked]>
Date: Tue, 27 Mar 2001 20:26:21 +0200

I don't know if anybody else has been testing this combo recently. I 
tested with the public beta and had no success copying or moving files. 
Now, it appears to have gone from bad to worse, I cannot even connect to 
the server. It connection "unexpectedly" closed. The second time I tried 
connecting, I had a kernel panic (not me personally, though close :-)

Apple still has a way to go to get this up and running, so if you're 
planning on buying public beta 2, don't bother for a while. I hope not 
too many people have invested money in this yet.

BTW - It's still as slow as the PB too, if not slower. All those reports 
you've read on the web are rubbish. I think it's just geeks playing with 
techie things as opposed to using it in the real world.

Cheers,
Jason.

---

From: Ryan McBeth <[email-masked]>
Date: Tue, 27 Mar 2001 13:41:11 -0500

If what I've been hearing, and what I've been experimenting 
with is correct, we are all in for a heck of a time.  Straight 
Appletalk doesn't work anymore.  You need an IP address, and then, 
you can't connect to Machines lower than OS X, although they can 
connect to you.

	Unfortunately, I realized this *after* I put it on my iBook. 
I knew I was going to have problems, but losing straight appletalk is 
one big problem.  Now the only way to transfer files to and from my 
PC is through connecting and disconnecting a zip drive.

	Everyone really needs to tread lightly with this new OS.

	Ryan

>tested with the public beta and had no success copying or moving 
>files. Now, it appears to have gone from bad to worse, I cannot even 
>connect to the server. It connection "unexpectedly" closed. The 
>second time I tried connecting, I had a kernel panic (not me 
>personally, though close :-)
>
>planning on buying public beta 2, don't bother for a while. I hope 
>not too many people have invested money in this yet.
>
>BTW - It's still as slow as the PB too, if not slower. All those 
>reports you've read on the web are rubbish. I think it's just geeks 
>playing with techie things as opposed to using it in the real world.
>
>Cheers,
>Jason.

__________________________________
Ryan McBeth
Systems Administrator, Mobius New Media
Voice: (302) 475-9880 x11
FAX: (302) 475-9894
www.mobiusnm.com
__________________________________
The secret to not getting burned out is to play at
working hard, and not taking things too seriously.
- Linus Torvalds

---

From: "Daniel E. Lautenschleger" <[email-masked]>
Date: Tue, 27 Mar 2001 12:42:47 -0600 (CST)

I get the same response.

Mar 27 11:00:07 itchy afpd[2804]: login usrdel (uid 500, gid 500)
Mar 27 11:00:11 itchy afpd[2804]: dsi_stream_read(0): No such process
Mar 27 11:00:11 itchy PAM_pwdb[2804]: (netatalk) session closed for user usrdel
Mar 27 11:00:11 itchy afpd[2804]: 0.45KB read, 8.53KB written
Mar 27 11:00:11 itchy afpd[2804]: Connection terminated
Mar 27 11:00:11 itchy afpd[2370]: server_child[1] 2804 exited 1

-- 

Daniel E. Lautenschleger
University of Wisconsin
R.M. Bock Laboratories
Network Administrator and Computer Support
[email-masked]

---

From: Scott Every <[email-masked]>
Date: Tue, 27 Mar 2001 13:51:13 -0500

actually, i use it in the real world and it runs VERY well on the new pbg4

i do have problems connecting with appletalk servers, but expect that the 
osx appletalk client is still weak.  the server side appletalk is rock 
solid. bugfixes will come soon i'm sure.

if you are running classic reformatting with a clean copy of 9.1 will make 
things run better.  classic is faster than 9.1 native for most things. 
better yet get rid of classic and its even faster.

s

---

From: Jason Quigley <[email-masked]>
Date: Tue, 27 Mar 2001 21:11:42 +0200

> actually, i use it in the real world and it runs VERY well on the new 

pbg4 says it all. OS X has acceleration for G4 machines. Those of us 
with with G3's have to live in a world where, in comparison,  OS 8.1 
feels positively spritely on a 7100/66! ;-)

Cheers,
Jason.

---

From: David <[email-masked]>
Date: Tue, 27 Mar 2001 14:20:09 -0500

I posted earlier last week about this.  Same trouble.  Although I 
found that netatalk-1.4b2+asun2.1.4 works!  I don't see how we could 
use DHX, just cleartext and 2way with the .passwd file.

Temporary solution I hope.

David Shaub

---

From: Paul Krohn <[email-masked]>
Date: Tue, 27 Mar 2001 19:23:45 -0800

well, since i haven't successfully re-compiled netatalk on my qube yet, 
i'm still using what came with:

#rpm -q -a | grep netatalk
netatalk-1.4b2+asun2.1.4-pre35_C3

and connecting from OS X release version works great. in fact, my mac is 
a much faster client with OS X installed.

the secret is to find out what options cobalt did or did not compile in, 
and try to figure from that what needs done to current versions for the 
same happy results.

also, at work, OS X connects no problem to our totalnet/syntax server 
with dhx encrypted passwords, as well as an oldish version of netatalk 
(exactly which i forget) on my ultra5.

i think it is unlikely that this is a server problem. perhaps some 
things which were forgiven in the past no longer are?

On Tuesday, March 27, 2001, at 10:26 AM, Jason Quigley wrote:

> Now, it appears to have gone from bad to worse, I cannot even connect 
> to the server. It connection "unexpectedly" closed. The second time I 
> tried connecting, I had a kernel panic (not me personally, though 
> close :-)

---

From: "Chad Leigh, Objectwerks, Inc." <[email-masked]>
Date: Tue, 27 Mar 2001 23:35:25 -0500

Well, I have had no problem connecting to a netatalk1.4+asun on FreeBSD 
system from two different MacOSX boxes and my Mac OS X machines are faster 
than the Public Beta, and I am using it for real work, both development and 
text writing as well as other sorts of work.

I did have one problem with OS X and netatalk but I don't know what the 
real issue is.  I used OS X to copy an OS 9 application and support files 
from an HSF+ disk on the Mac to the netatalk server described above and 
thej went to an OS 9 box to try to run the app of the netatalk volume but 
it gave an error -39 every time I tried to run the app by double clicking 
it.  I erased it off the netatalk and rebooted the OS X machine into OS 9 
and copied it over and then went to the other machine and it ran fine.  But 
in general the netatalk volume behaves exactly the same to both OS X and OS 
9 machines.

Chad

---

From: Paul Krohn <[email-masked]>
Date: Wed, 28 Mar 2001 08:31:39 -0800

> things which were forgiven in the past no longer are?

sheesh. let's hear it for proof reading: i meant i don't think it's a 
_client_ problem.