Subject: Re: [netatalk-admins] Netatalk and remote printers (fwd)
From: Russell E Glaue (russ@cait.org)
Date: Tue Sep 14 1999 - 13:35:15 EDT
Yes. This is a (recently discovered) known problem.
I assume that the answer to this problem has not been put into any FAQ or
PRINTING-HOWTO documentation yet.
If anyone out there maintaining documentation or FAQ's could add this
explaination it would be appreciated. We need to tell others about the
problem with printing through papd to TCP/IP connected printers using LPR.
It is a problem with LPR. Discovered by Ryan Cleary.
The fix to LPR is attached, and explained below. From Ryan Cleary.
+--------------------------------------------------------------+
Russell E Glaue, Technologies Engineer russ@cait.org
Center for the Application of Information Technologies
101 Horrabin Hall, 1 University Circle, Macomb, Illinois 61455
http://www.cait.org http://cait.wiu.edu
On Tue, 14 Sep 1999, Ali Boudani wrote:
>
>
> hello,
>
> i installed netatalk1.4.2b as an rpm in my Redhat6 and all things seem
> ok.
>
> i want that i can print from my mac to 2 HP printer connected to my
ethernet
> network so i can conrol the use of number of page that every user use
> in my network.
>
---------- Forwarded message ----------
Date: Tue, 10 Aug 1999 15:29:09 -0400
From: Ryan Cleary <tryanc@interdim.com>
To: Russell E Glaue <russ@cait.org>, Mary L Stracke <stracke@helix.nih.gov>
Subject: Re: [netatalk-admins] Netatalk and remote printers
Russell E Glaue wrote:
> Has this been brought to the attention to those individuals completing the
> overhaul on Netatalk? A fix for this should be included in the next
> release so we can all print from papd through LPD to any remote TCP/IP
> LPR.
Like I said before, I fixed lpd, not netatalk, since lpd exhibits the
same problem when printing via lpr machine A to lpd on machine B then to
lpd on machine C.
See the attached patch, and modified spec file for rebuilding the lpr
rpm (which includes lpd). [*]
Here's what I think is going on with lpd:
When lpd finds a file in it's queue that is supposed to go to a remote
lpd queue, it calls the function sendit() (in lpd/printjob.c), which
mirrors the cf file with a new, temporary filename. The creation of
this temporary filename is dependent on the original filename having 13
characters, and fails if it's longer.
(771) dup_cfpname = strdup(file);
(772) memcpy((dup_cfpname+7), "XXXXXX", 6);
(773) mktemp(dup_cfpname);
(774) tmpmask = umask(007);
(775) dup_cfp=fopen(dup_cfpname, "w");
(776) umask(tmpmask);
(777) if (dup_cfp == NULL)
(778) {
(779) syslog(LOG_ERR, "Can't create temp cfp file %s", dup_cfpname);
(780) return(OK);
(781) }
the memcpy in line 772 replaces characters 7-12 (the last 6 characters
of a 13 character filename) with XXXXXX, so the mktemp in the next line
can create a unique temporary file name. However if the last 6
characters are not XXXXXX, and they won't be if the original filename is
longer than 13 characters, mktemp fails, and returns NULL.
Sound like a valid conclusions?
By editing line 772 to be:
(772) memcpy((dup_cfpname + (strlen(dup_cfpname) - 6)), "XXXXXX",
6);
so that it just replaces te last 6 characters with XXXXXX, I seem to
have fixed it.
> I would be interested in any patches to Netatalk papd that will allow it
> to successfully work together with LPD for printing to remote LPRs over
> TCP/IP.
>
> After 2 years I finally got this problem answered by someone.
> Please forward your patches. Thank you very much!
You're welcome. I hope this is useful to you.
--Ryan Cleary
--------------------------------------------------------------------------
* If haven't built your own RPMs before, here's how to rebuild lpr in a
nutshell:
Get the SRPM for lpr-0.35 and install it. This will put RedHat's spec
file in /usr/src/redhat/SPECS, and the source (lpr-0.35.tar.gz) in
/usr/src/redhat/SOURCES. Now put my .patch file in the
/usr/src/redhat/SOURCES directory, and replace RedHat's .spec file with
mine.
Now, to actually build the binaries, use the command
rpm -bb /usr/src/redhat/SPECS/lpr.spec
Then update your installed rpm (probably lpr-0.35-1) to my version
(release 1id1), which should now be in
/usr/src/redhat/RPMS/i386/lpr-0.35-1id1.i386.rpm
rpm -Uvh /usr/src/redhat/RPMS/i386/lpr-0.35-1id1.i386.rpm
Of, if you prefer, I can email you the binary rpm, ready for
installation.
It's about 76k.
=============== Forwarded message from Ryan Cleary ===============
I searched RedHat's bugzilla site for lpr bugs, and found the one I was
referring to earlier. It's already been reported (at least twice), and
their fixes are the same as the one I came up with. There is an updated
version of lpr available (lpr-0.39) that incorporates this fix. I found
it at:
http://rpmfind.net/linux/rawhide/1.0/i386/RedHat/RPMS/lpr-0.39-2.alpha.rpm
for the Intel version. SPARC and Alpha versions are there, as well, in
the expected places.
Again, it's not a problem with netatalk at all. It is (was) a bug in
RedHat's lpd.
--Ryan Cleary
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:17:13 EST