Bug 185225 - Cups gets printer hostname totally wrong
Cups gets printer hostname totally wrong
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2006-03-11 23:40 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-13 08:54:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2006-03-11 23:40:55 EST
Description of problem:
When cupsd browses other IPP hosts it first invokes AddPrinter().
In AddPrinter() the code changes to p->hostname to point to local hostname.
After the call returns the browser code zaps the p->hostname to remote hostname.
This is unfortunate, because AddPrinter() calls WritePrintcap() which results
in an /etc/printcap conatining the wrong "rm=" entry.
This stuffs up programs like Samba which might use /etc/printcap as a reliable
source of information.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Start cupsd on host1
2.Start cupsd on host2
3.Look at /etc/printcap on host2
4.Read the code, esp scheduler/{dirsvc.c:284,printers.c:106}
Actual results:
host2:/etc/printcap will have host1 remote printer entries with "rm=host2"

Expected results:
host2:/etc/printcap entries for remote printers on host1 should have "rm=host1"

Additional info:
The programming workers writing cupsd should have added a rhostname entry to
the printer_t structure.
Comment 1 JW 2006-03-12 00:11:19 EST
Please excuse the bad grammar and spelling mistakes in above.
Why isn't there a facility to edit bug entries?
Comment 2 Tim Waugh 2006-03-13 07:26:47 EST
This behaviour is correct.  The queues exist on the local machine too, and get
forwarded to the remote machine.
Comment 3 JW 2006-03-13 07:46:00 EST
(In reply to comment #2)
> This behaviour is correct.  The queues exist on the local machine too, and get
> forwarded to the remote machine.

I don't think so. The "rm=" means remote machine, and the local machine is *not*
a remote machine.

It is also a lie to say that the printer exists on the local machine - it
doesn't. It exists on another machine.  That is exactly what the "rm=" is for!!

The way the printcap was dresigned was *not* to use "rm=" to point to local
host.  Because the printcap was designed for the print spooler to determine
where the actual printer is.  And that is exactly what the "rm=" was for.
Comment 4 Tim Waugh 2006-03-13 08:54:03 EST

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