Subject: DHX uam error

From: sat <[email-masked]>
Date: Sat, 04 Mar 2000 18:11:34 -0500

I have openssl 0.95 compiled, and then I compiled and installed 
pre-asun2.1.4-38b_test

This is my syslog output:   Any clues?

I'm on a RedHat 6.1 system runnng 2.2.15pre11.

Mar  4 18:02:13 beer afpd[21841]: uam: uams_guest.so loaded
Mar  4 18:02:13 beer afpd[21841]: uam: uams_clrtxt.so loaded
Mar  4 18:02:13 beer afpd[21841]: uam_load(uams_dhx.so): failed to load: 
/usr/lo
cal/atalk/etc/uams/uams_dhx.so: undefined symbol: __udivdi3
Mar  4 18:02:13 beer afpd[21841]: uam: "Cleartxt Passwrd" available
Mar  4 18:02:13 beer afpd[21841]: uam: "No User Authent" available

---

From: Ryan Thomas <[email-masked]>
Date: Tue, 7 Mar 2000 11:19:24 -0600

I'm experiencing the same thing w/ 0.95 OpenSSL -- but I'm using 
pre-asun2.1.4-37b.  This is on yellowdog linux, champion server 1.1 
(AWS 9650).

-Ryan

>Mar  4 18:02:13 beer afpd[21841]: uam_load(uams_dhx.so): failed to 
>load: /usr/lo

-- 
===========-------------------------------------------------------
Ryan Thomas, CCSO Consultant
Network & Systems Administrator for the College of Education, UIUC
[email-masked], 217/244-0429, http://www.uiuc.edu/ph/www/rthomas

---

From: Ryan Thomas <[email-masked]>
Date: Wed, 8 Mar 2000 11:51:49 -0600

Is anyone else using uams_dhx.so w/ openssl 0.9.5?

-Ryan

---

From: Ryan Thomas <[email-masked]>
Date: Thu, 09 Mar 2000 08:07:53 -0600

FYI, I just uninstalled openssl 0.9.5 and recompiled netatalk using openssl 
0.9.4.  DHX auth now works.

-Ryan

At 11:51 AM 3/8/00 -0600, Ryan Thomas wrote:

>>pre-asun2.1.4-37b.  This is on yellowdog linux, champion server 1.1 (AWS 9650).
>>
>>-Ryan
>>

---

From: Harry Zink/Netatalk List <[email-masked]>
Date: Thu, 09 Mar 2000 09:50:03 -0800

While dealing with the ppd files, I'd like to make a couple of suggestions:

* Could we place the ppd folder inside the atalk folder in /etc? Since
hardly anything else needs access to he ppds, this seems like a more logical
location for the files, since it's part of the netatalk files. Is there any
reason (besides ideology) not to keep them there?

* Would it be possible to distribute a separate RPM (or include with the
netatalk RPM), a well-filled directory of existing ppds, for popular
printers, and properly formatted? This might be a legal issue (not sure
about that) but I think it would make may people's lives easier when
installing papd for postscript printers. If someone wants to help me create
the RPM, I'd be willing to convert every ppd file I find (or that is being
forwarded to me). We could start with all the ppds Apple ships, and the
gamut of thoe hp provides. That ought to cover a nice chunk.

Any other ideas?

Harry

---

From: Patrik Schindler <[email-masked]>
Date: Thu, 9 Mar 2000 19:48:02 +0100

>reason (besides ideology) not to keep them there?

You can keep them anywhere you like. I provide evertime the full pathname to it in papd.conf.

:wq! PoC

---

From: "Olivier Thomas" <[email-masked]>
Date: Fri, 10 Mar 2000 10:28:26 +0900

Hi,

When my mac tries to print documents with Japanese fonts through netatalk,
it crashes (error system 10).
Is it a problem of ppd file ? I installed the ppd file for my printer
(HP4000N) on my linux box but after reading the mail from Andrew Morgan, I
understand that the Mac directly sends postscript to the Linux box.
However the Japanese font for the mac doesn't seem to be loaded correctly
to the printer.
Does anybody know where it comes from ?

Thanks for your help,
Olivier.

-----Original Message-----
From: Patrik Schindler [mailto:[email-masked]]
Sent: Friday, March 10, 2000 3:48 AM
To: [email-masked]
Subject: Re: couple of suggestions for the RPM/papd

>reason (besides ideology) not to keep them there?

You can keep them anywhere you like. I provide evertime the full pathname to
it in papd.conf.

:wq! PoC

---

From: Tom Kacvinsky <[email-masked]>
Date: Mon, 2 Oct 2000 15:52:09 -0400 (EDT)

I tracked this down to the code in openssl-0.9.x/crypto/bn/bn_div.c,
around line 129, where x > 4.  Read the comments there.  No fix from
me is forthcoming, because I don't have the time right now.

For some reason, openssl 0.9.4 does not generate the __udivdi3 symbol
when compiled with gcc.

I am now trying to get DHX working with Solaris 2.7, openssl-0.9.6, and
Sun's Workshop Pro compiler (version 5.0).

I'll see what happens...

Tom