Bug#940019: cups: No more options for remote shared printers
Le 13/09/2019 à 12:58, Brian Potkin a écrit :
> reassign 940019 cups-browsed
> thanks
>
> On Thu 12 Sep 2019 at 23:25:48 +0200, Vincent Danjean wrote:
>
>> Le 12/09/2019 à 21:15, Brian Potkin a écrit :
>>> There should not be any Brother (or Canon) files on the client. The job
>>> should be processed completely on the server. This is why I wanted the
>>> outputs of 'lpstat -l -e' and 'lpstat -t' (which were not sent).
>>
>> I'm back at home. Here are the results :
>>
>> $ lpstat -l -e
>> brother permanent ipp://localhost/printers/brother implicitclass://brother/
>
> "permanent" indicates local queues. There are two URIs. The second is
> one managed by cups-browsed; the first is something set up by you. I
> doubt this arrangemment will work reliably.
No. Unless I'm mistaken, the "permanent" queue is setup by cups-browsed.
>From its own doc :
# With OnlyUnsupportedByCUPS set to "No", cups-browsed creates queues
# for all printers which it supports [...] As queues
# created by cups-browsed are permanent CUPS queues [...]
# [...] This setting is the default.
And indeed, I do not change this settings.
So, the "permanent" queue comes from cups-browsed.
I also checked it by :
1) stopping cups and cups-browsed
2) checking that no reference to a "brother" printer exists in
all files under /etc/cups (I removed /etc/cups/printers.O for example)
3) removing all files under /var/cache/cups/
4) restarting cups
=> the brother printer was not listed by "lpstat -l -e"
5) restarting cups-browsed
=> the brother printer appears as before with "lpstat -l -e", ie:
brother permanent ipp://localhost/printers/brother implicitclass://brother/
>> Brother_DCP_9020CDW_kooot_2 network none ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
>
> This appears to be a print queue or printer on the network.
This one is directly discovered by cups itself (appears at step 4 above)
>> I'm sure that my laptop was using the provided one (ie the one
>> from Brother) because I can see it with 'git diff' (my /etc is
>> handled with etckeeper). Looking at the history, it appears and
>> disappears regularly (depending if my laptop is at home or not)
>> until 2018-03-26 when I added these ppd files in the .gitignore...
>> What I do not know is where the ppd file was coming from (each time
>> the laptop was at home, the printer was rediscovered and the PPD file
>> reinstalled)
>
> From the information provided, and what you have said, it appears you
> are processing a print job twice; this is not a setup supported by
> Debian. I have triaged enough reports involving this situation to know
> that it generally leads to grief for both parties. I am closing the
> report on that basis.
I perhaps did it. But it is not the case anymore as the PPD file
on the laptop is now (wrongly) generated by driverless. And I doubt
it was the case before, because even if I remember I gave the PPD
at install time, I never install the binary drivers/filters
as it is done on the server.
The result is that the printing system is unusabled for now.
Both at home and at work, I cannot manage important options.
For others that can read this bug report, I found a partial
workaround for this situation: completely bypass the local cups/
cups-browsed servers with the bad PPD files, and directly talk
to the remote cups server. This can be done by using the
CUPS_SERVER envvar or the ~/.cups/client.conf file as said in
documentation.
$ lpoptions -l -pbrother | wc -l
2
$ CUPS_SERVER=cups.servername.domain lpoptions -l -pbrother | wc -l
18
The ~/.cups/client.conf is better for already opened programs
(libreoffice, thunderbird, ...) as changing this file is taken
into account immediately (no need to restart the program in
a changed environment). And then, you get access to all the
options available in the cups server.
That said, it is just a workaround because it is not very
convenient to change this file, and the settings must be removed
to access local printer (such as the virtual cups-pdf printer)
Regards,
Vincent
Reply to: