Bug 5697 - remote printing with lpd does not work
remote printing with lpd does not work
Status: CLOSED DUPLICATE of bug 5835
Product: Red Hat Linux
Classification: Retired
Component: lpr (Show other bugs)
6.1
All Linux
high Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-07 16:39 EDT by eloranta
Modified: 2014-03-16 22:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-14 17:11:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description eloranta 1999-10-07 16:39:30 EDT
with lpr-0.41-2 package distributed with rh6.1 the
network printing does not work. The jobs go to the
queue on the server but never come out (most likely
due to corrupt control files originating from the
client - see below).

It appears that the problem is in lpd/printjob.c
in function sendit(). The bug is somehow related to the
creation of the control file copy. If I remove the
control file copy code (which is forced in the current
version) then the printing begins to work.
Comment 1 Bill Nottingham 1999-10-07 17:33:59 EDT
Could you try the lpr package from Raw Hide
(ftp://ftp.redhat.com/pub/rawhide/) and let us know if that
works better for you?  Remote printing works OK here...

------- Additional Comments From   10/08/99 03:54 -------
I had the same problem printing from a 6.1 box to a 6.0 box. after
downgrading lpr to the package in 6.0, everything works. I use
hosts.equiv authorization on the server.
Comment 2 eloranta 1999-10-08 03:58:59 EDT
Using lpr-0.41-3 from rawhide solves the problem here.
Comment 3 István Tóth 1999-10-08 04:07:59 EDT
I confirm, lpr-0.41-3 solves this problem for me, too.
Comment 4 steveh 1999-10-08 04:15:59 EDT
lpr-0.41-3 only partially fixes the problem. The current solution
will not work for multiple copies.
Comment 5 steveh 1999-10-08 04:19:59 EDT
Here is what I think is a more elegant solution to the problem. I'm
not sure I can paste a patch on this little box on the bugtraq web
page, but here goes... (I'm also submitting a similar patch to Debian
lpr, which is also based off of Redhat's 0.41 lpr; I'm actually a
Debian user <grin>). If this doesn't paste well and you're interested
in it, email me privately and I'll resend it.

--- ../lpr-0.41/lpd/printjob.c  Wed Sep 29 13:05:11 1999
+++ lpd/printjob.c      Fri Oct  8 03:45:14 1999
@@ -756,7 +756,6 @@ sendit(file)
        int  ifchild, pid;
        int  sendresult;
        int  tmpmask;
-       int  numcopies=0;

        int  ii;

@@ -875,16 +874,22 @@ sendit(file)

                        strcpy(last, line);
                        /* handle multiple copies */
-                       while (i = getline(cfp))
+                       while (i = getline(cfp)) {
+                         if (dup_cfp)
+                           fprintf(dup_cfp, "%s\n", line);
                                if (strcmp(last, line))
                                        break;
-                               else
-                                       numcopies++;
+                       }


                        /* msf - here is where we hack in IF
support    */
                        /*       will only run the IF, no other
filters */
                        /*       will be
run.                           */
+                       /* This hack will work for multiple files
only  */
+                       /* if the 'f' lines are separated by at
least   */
+                       /* one non-'f' line (i.e. a U or N line) due
to */
+                       /* the multiple copies getline() while
loop     */
+                       /* right above this
comment.                    */
                        if (IF != NULL && last[0] == 'f') {

                            memcpy(tmpfile, last+1, 7);
@@ -895,11 +900,6 @@ sendit(file)
                            /* Nasty trick of the day, to attempt
                             * to be RFC compliant */
                            rename(last+1,tmpfile);
-                           /* we make a new f and U entry for remote
cfp */
-
-                           for (;numcopies>0;numcopies--)
-                                 fprintf(dup_cfp, "f%s\n",last+1);
-                           fprintf(dup_cfp, "U%s\n",last+1);

                            fi = open(tmpfile, O_RDONLY);
                            ifi = open
(last+1,O_WRONLY|O_CREAT|O_TRUNC, 0664);
@@ -918,11 +918,6 @@ sendit(file)
                          /* wait on it to finish */
                          waitpid(ifchild, NULL, 0);
                         }
-                        else
-                        {
-                         if (dup_cfp)
-                           fprintf(dup_cfp, "%s\n", line);
-                         }

                         sendresult = sendfile('\3', last+1);
Comment 6 Bill Nottingham 1999-10-08 13:37:59 EDT
OK, could you try the lpr-0.42-1 RPMs at
ftp://people.redhat.com/notting/lpr/
-or-
http://people.redhat.com/notting/lpr/

to make sure it still works for everyoone?  It checks out fine here...
Comment 7 eloranta 1999-10-09 11:23:59 EDT
lpr-0.42-1 works ok here.


------- Additional Comments From   10/14/99 06:45 -------
I had the same problem. lpr-0.42-1 seems to fix it.
Comment 8 Bill Nottingham 1999-10-14 17:11:59 EDT
*** This bug has been marked as a duplicate of 5835 ***

Note You need to log in before you can comment on or make changes to this bug.