[cups-devel] [UNKN] STR #4323: Add raw remote printer with class fails

[berend.de.schouwer at gmail.com]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Description of problem:

Adding a remote printer to a local cups server, and assigning that printer
to a class fails to assign the class correctly.  The printer is not
assigned to the class exactly 50% of the time.

This appears to only happen with raw printers (no -P to lpadmin)

This appears to only happen if the remote printer is an IPP printer.

This appears to only happen if the remote printer shares a remote name with
another remote printer.  I don't think I can make this happen -- at least
not reliably -- if the remote printers have different remote names.

The remote IP does not actually have to be reachable.  I actually used IP
'1.2.3.4...' below, on a private 172. network with no Internet access.  If
the IP is reachable, no attempt is made to contact the remote IPP service.


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

Tested on

cups-1.7.0-6.fc20     # Fedora 20, brand new
cups-1.4.2-50.el6.5   # RHE 6.5, far from new
cups MacOS X          # current


How reproducible:

Exactly 50% of the time.


Steps to Reproduce:
1. lpadmin -p SIX -v "ipp://1.2.3.6:631/printers/PRINTER" -E -c DEMO
2. lpadmin -p SEVEN -v "ipp://1.2.3.7:631/printers/PRINTER" -E -c DEMO #
different IP; different *local* name; same *remote* name
3. lpadmin -p SEVEN -v "ipp://1.2.3.7:631/printers/PRINTER" -E -c DEMO #
exact same line

Actual results:

1. no error.
2. lpadmin: The printer or class was not found.
3. no error

1. SIX is added to class 'DEMO'
2. SEVEN is not added to class 'DEMO'.  However, printer SEVEN is added
correctly with the IPP URI.
3. SEVEN /replaces/ SIX in the list for class 'DEMO'


Expected results:

Both SIX and SEVEN are members of class DEMO.


Additional info:

I can do this if ipp://printers/NAME has different NAMES on different IPs.

I can do this if I add -P something.ppd to lpadmin.  This is my current
workaround with a ppd that runs /bin/cat (the remote printers are not
consumer devices, expect raw)


Logs:

Note the difference appears to simply be "200 271 CUPS-Add-Modify-Class
successful-ok" vs. "200 312 CUPS-Add-Modify-Class client-error-not-found"

The numbers after '200' are different for different versions of Cups; but
the message "CUPS-Add-Modify-Class client-error-not-found" are the same.


for (1):

localhost - - [27/Dec/2013:10:11:21 +0200] "POST /admin/ HTTP/1.1" 401 169
CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:21 +0200] "POST /admin/ HTTP/1.1" 200
169 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:21 +0200] "POST /admin/ HTTP/1.1" 200
173 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:21 +0200] "POST /admin/ HTTP/1.1" 200
271 CUPS-Add-Modify-Class successful-ok

for (2):

localhost - - [27/Dec/2013:10:11:31 +0200] "POST /admin/ HTTP/1.1" 401 171
CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:31 +0200] "POST /admin/ HTTP/1.1" 200
171 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:31 +0200] "POST /admin/ HTTP/1.1" 200
175 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:11:31 +0200] "POST /admin/ HTTP/1.1" 200
312 CUPS-Add-Modify-Class client-error-not-found

for (3):

localhost - - [27/Dec/2013:10:16:08 +0200] "POST /admin/ HTTP/1.1" 401 171
CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:16:08 +0200] "POST /admin/ HTTP/1.1" 200
171 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:16:08 +0200] "POST /admin/ HTTP/1.1" 200
175 CUPS-Add-Modify-Printer successful-ok
localhost - root [27/Dec/2013:10:16:08 +0200] "POST /admin/ HTTP/1.1" 200
273 CUPS-Add-Modify-Class successful-ok

Link: https://www.cups.org/str.php?L4323
Version: 1.7-current