-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"lpadmin ... -o printer-is-shared=true" does not work for ipp queues without visible reason #4738
Comments
CUPS.org User: mike Johannes, You cannot re-share a remote printer - this change was made several years ago because it causes a lot of problems when the final server requires authentication. That said, you should probably be getting an error from lpadmin when you try to set the printer-is-shared attribute to 1... Will use this bug to track that change. |
CUPS.org User: jsmeix.suse I think the basic question is what "remote printer" means. I know that the local cupsd cannot re-share a queue that it got But in my case here my foofwd queue is a local queue I do not want to re-share it. I thought that all queues that exist in /etc/cups/printers.conf In my case it seems one cannot share a local queue depending Initially I detected this behaviour with CUPS 1.3.9 on SLES11 In CHANGES-1.3.txt I detected now this entry
For example if local queues with any ipp//... DeviceURI But somehow this seems to work:lpadmin -p baz -v ipp://dummy.example.org/something -Eless /etc/cups/printers.conf... lpadmin -p baz -o printer-is-shared=falseless /etc/cups/printers.conf... lpadmin -p baz -o printer-is-shared=trueless /etc/cups/printers.conf...Shared YesTherefore I think the real issue is to describe precisely Perhaps for queues that exist in /etc/cups/printers.conf a new explicit entryRemote [Yes/No]could be provided to make it clear Or alternatively and perhaps even more to the pointShareable [Yes/No]to make it clear which queue can be shared and which cannot. In general regarding my current understanding of the terms (excerpt):There is a difference between "local/remote queue"
Now I am confused regarding a network printer that is accessed According to my current understanding in both cases In particular I am confused about a (hypothetical?) Could one share queues in /etc/cups/printers.conf |
CUPS.org User: jsmeix.suse I guess I found the hardcoded DeviceURI magic that distinguishes (excerpt):load_ppd(cupsd_printer_t *p) ... ...
...
and its hardcoded consequence also in scheduler/printers.c (excerpt)cupsdSetPrinterAttrs(cupsd_printer_t *p) ... ... /*
|
CUPS.org User: jsmeix.suse Furthermore there is in scheduler/printers.cload_ppd(cupsd_printer_t *p) ... ...
but that is the only place in the CUPS 2.1.0 sources Now I wonder what "APRemoteQueueID" is? |
CUPS.org User: jsmeix.suse This is only a guess but perhaps I am on the right track: When there is a queue in /etc/cups/printers.conf In particular for such a queue one gets printer specific PPD options via "lpoptions -l":lpoptions -h localhost -p foofwd -lResolution/Resolution : *600 ... PageSize/Page Size: Letter Legal A5 *A4 ...This is unexpected because my "foofwd" queue has no PPD file. If my above assumption is right the problem is that According to my current understanding the solution should be When setting up such a queue the cupsd can of course set In short: |
CUPS.org User: mike Raw queues are the only ones to be flagged as remote queues, and then only IPP queues that point to a CUPS server (/cups on the end for Bonjour URIs, /classes and /printers for ipp/ipps URIs). Source changes (to produce an error) are below. |
"str4738.patch": Index: scheduler/ipp.c--- scheduler/ipp.c (revision 12973)
if (pclass->shared && !attr->values[0].boolean) @@ -2471,6 +2481,16 @@
if (printer->shared && !attr->values[0].boolean) |
Version: 2.1.0
CUPS.org User: jsmeix.suse
I have a remote CUPS server with a queue "foo".
On the local system I create a raw queue that only forwards
to the queue "foo" on the remote CUPS server:
lpadmin -p foofwd -v ipp://server.domain/printers/foo -E
echo $?
0
I can print from the local system via the local foofwd queue.
Now I like to share that foofwd queue on my local system:
lpadmin -p foofwd -o printer-is-shared=true
echo $?
0
In /var/log/cups/error_log (with LogLevel debug) there is:
D ... CUPS-Add-Modify-Printer ipp://localhost:631/printers/foofwd
D ... cupsdIsAuthorized: username="root"
I ... Setting foofwd printer-is-shared to 1 (was 0.)
...
I Saving printers.conf...
But in /etc/cups/printers.conf the foofwd queue is still "Shared No"
In contrast "printer-is-shared=true" works for a "raw" queue
where the DeviceUri is not "ipp://...":
lpadmin -p bar -v socket://dummy.example.org -E
it has by default "Shared Yes" in /etc/cups/printers.conf
and I can toggle it as I like with
lpadmin -p bar -o printer-is-shared=false
versus
lpadmin -p bar -o printer-is-shared=true
I found that this behaviour was already reported in
https://www.cups.org/pipermail/cups/2014-June/026272.html
but without an aswer that explains why CUPS
does not share an ipp print queue.
Therefore I report it now as a bug because
ther are thre issues with that behaviour:
When "lpadmin ... -o printer-is-shared=..." does not work,
it should at least report an error or warning.
"man lpadmin" does not tell anything that
sharing an ipp print queue does not work.
https://www.cups.org/documentation.php/doc-2.1/sharing.html
does not tell anything that sharing an ipp print queue does not work.
There is no debug message in /var/log/cups/error_log
that could help to dind out what the reason is
why sharing an ipp print queue does not work.
Actually the messages in /var/log/cups/error_log
seem to show that it has worked:
"Setting foofwd printer-is-shared to 1 (was 0.)"
I assume there is a good reason why sharing an ipp print queue
does not work but then this reason should be at least documented.
Additionally it is perhaps a minor bug that lpadmin does
neither show an error message nor return an error exit code
in this case.
The text was updated successfully, but these errors were encountered: