Bug#883554: cups keeps breaking network printer with implicitclass:
Thank you for the level of detail, David.
On Tue 05 Dec 2017 at 19:43:54 -0600, David Fries wrote:
> On Tue, Dec 05, 2017 at 01:52:53PM +0000, Brian Potkin wrote:
> > On Mon 04 Dec 2017 at 23:47:04 -0600, David Fries wrote:
> >
> > > Package: cups
> > > Version: 2.2.1-8
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > > It seems to be every day or so the /etc/cups/printers.conf DeviceURI is
> > > modified to replace the version that works with a version that doesn't.
> >
> > Knowing "...the version that works..." would be useful.
>
> Doesn't work:
> DeviceURI implicitclass:Canon_BJC-2100
> web job state
> held since Tue Dec 5 19:00:56 2017 "No suitable destination host found by cups-browsed."
cups-browsed sees the server queue as either disabled or, for some
reason, not accepting jobs. This would imply the problem is on the
server. You need to look at an error_log there. See
https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem
for how to get one.
> works (after replacing in server name) was in there since 2015:
> DeviceURI ipps://<server>.local:631/printers/Canon_BJC-2100
Indeed, but printer-driver-gutenprint on the server has changed since
then.
> That is it works for about a day until it changes to the one that
> doesn't.
>
> > > This is printing to a cups system on the local network.
> > > Was working with the cups in Debian jessie.
> >
> > What is the cups version on the server? Can you print from the server?
>
> Both the serve and client were running Debian jessie prior to
> Thanksgiving, both were upgraded to stretch. On the client I see in
> aptitude.1.gz
> [UPGRADE] cups:amd64 1.7.5-11+deb8u1 -> 2.2.1-8
> Both client and server lists cups as version 2.2.1-8
>
> Yes the server was printing before and after the upgrade.
That means there is filtering of the job on the server. All seems well.
> > > It doesn't matter if I use a dnssd (auto detected), ipps, ipp, it gets
> > > replaced by,
> > > DeviceURI implicitclass:Canon_BJC-2100
> > > and that doesn't allow it to print. I've even gone so far as deleting
> > > the printer, the detecting it through the ipp web configuration
> > > interface and after a day or so it goes back to the implicitclass.
> >
> > I do not understand the existence of the time lag.
>
> It doesn't make any sense to me either when I'm using the cups browser
> interface and letting it write out the file that it works for a while
> and then it fails..
Sorted. See below.
> After the upgrade I can configure the client with that ipps and it
> is able to print, for about a day, and then printing fails and I check
> printers.conf and it is replaced with,
> DeviceURI implicitclass:Canon_BJC-2100
> and it can no longer print. This is one of the files that cups keeps
> modifying. I've been using the web configuration interface when
> modifying it, and have used the "Discovered Network Printers:" option
> which fills in a long dnssd://Canon%20BJC-2100%20%40%20... but while
> it initially prints it doesn't matter that will be replaced by
> implicitclass:Canon_BJC-2100 the next day.
>
> > > Any ideas?
> >
> > There will be a PPD for the BCJ-2100 in /etc/cups/ppd. Please do
>
> > /usr/sbin/cupsfilter -p <PPD> -m printer/foo -e --list-filters /etc/services
>
> /usr/sbin/cupsfilter -p /etc/cups/ppd/Canon_BJC-2100.ppd -m printer/foo -e --list-filters /etc/services
>
> That gives no output at all. I have a different version from 2015 in
> that directory with the following output.
>
> cupsfilter: File "/usr/lib/cups/filter/rastertogutenprint.5.2" permissions OK (040755/uid=0/gid=0).
> texttopdf
> pdftopdf
> gstoraster
> rastertogutenprint.5.2
Forget about this. It doesn't help towards a solution and, if I had
thought on about it, I should not have sought out the information I
was after with that command.
What I wanted to find out was whether you used a PPD with the CUPS
web interface and an ipp:// or dnssd:// URI. Because you can print
(initially at least) it implies you didn't.
> The majority seems to be different page sizes, dithering, and such.
> The header and cupsFilter might be of interest, so included here.
>
> --- Canon_BJC-2100.ppd 2017-12-05 09:35:07.689792328 -0600
This is the PPD on the client?
> +++ Canon_BJC-2100_remote.ppd 2015-11-29 00:33:04.432331311 -0600
This is the PPD on the server?
> @@ -15,7 +15,7 @@
> *% Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> *%
> *FormatVersion: "4.3"
> -*FileVersion: "5.2.11"
The stretch version.
> +*FileVersion: "5.2.10"
The jessie version. If this is on the server, it is highly advisable to
reinstall the print queue with 'cups-genppdupdate'. I wonder whether
that gets you printing with an implicitclass: URI?
> *LanguageVersion: English
> *LanguageEncoding: ISOLatin1
> *PCFileName: "STP00011.PPD"
> @@ -23,17 +23,17 @@
> *Product: "(Canon BJC-2100)"
> *ModelName: "Canon BJC-2100"
> *ShortNickName: "Canon BJC-2100"
> -*NickName: "Remote printer: Canon BJC-2100 - CUPS+Gutenprint v5.2.11"
> +*NickName: "Canon BJC-2100 - CUPS+Gutenprint v5.2.10"
> *PSVersion: "(3010.000) 0"
> *LanguageLevel: "3"
> *ColorDevice: True
> *DefaultColorSpace: RGB
> -*cupsManualCopies: True
> *FileSystem: False
> *LandscapeOrientation: Plus90
> *TTRasterizer: Type42
> *cupsVersion: 1.2
> -*cupsFilter: "*/* 0 -"
Fine for the client. cups-browsed gets the PPD from the server and puts
this line in.
> +*cupsManualCopies: True
> +*cupsFilter: "application/vnd.cups-raster 100 rastertogutenprint.5.2"
Exactly what the server PPD should have.
> *1284DeviceID: "MFG:Canon;MDL:BJC-2100;DES:Canon BJC-2100;"
> *cupsLanguages: "ca cs da de el en_GB es fi fr gl hu it ja nb nl pl pt ru sk sl sv tr uk vi zh_CN zh_TW"
>
> > and post its output and the outputs of
> >
> > systemctl status cups-browsed
>
> cups-browsed.service - Make remote CUPS printers available locally
> Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor preset: enabled)
> Active: active (running) since Tue 2017-12-05 09:34:59 CST; 9h ago
> Main PID: 447 (cups-browsed)
> Tasks: 3 (limit: 4915)
> CGroup: /system.slice/cups-browsed.service
> 447 /usr/sbin/cups-browsed
Ok.
> > lpstat -t
>
> lpstat -t
> scheduler is running
> system default destination: Canon_BJC-2100
> device for Canon_BJC-2100: implicitclass:Canon_BJC-2100
> Canon_BJC-2100 accepting requests since Tue Dec 5 19:19:12 2017
> printer Canon_BJC-2100 is idle. enabled since Tue Dec 5 19:19:12 2017
>
> How about this sequence, I go through the web interface, change it to
> the ipps URI that works. Verify in the browser it is the ipps URI,
> verify with `lpstat -t` it is ipps URI, wait until
> /etc/cups/printers.conf has the ipps DeviceURI, then.
> systemctl stop cups-browsed.service
> systemctl start cups-browsed.service
> and the browser immediately lists implicitclass:Canon_BJC-2100
I can now reproduce your observations, apart from the non-printing
aspect.
1. Start with cups-browsed running and no queue using ipp:// or
dnssd://. Printing takes place for me. For you I suspect it
doesn't. The PPD in /etc/cups/ppd is obtained by cups-browsed
from the server and modified slightly. The queue is a raw
queue and the PPD is only there so that applications know what
to display in their dialogs; it does not lead to any filtering
on the client to alter the submitted job file.
2. Configure a raw queue with ipp:// having the same queue name as
on the server. This setup method removes the existing PPD and
overrides the cups-browsed automatic setup. Printing takes place
for both of us.
3. At some future time cups-browsed refreshes what it knows about
remote queues, using what is in /var/cache/cups, and reinstates
the queue, once again getting the PPD it had in 1. I can still
print. (With a different queue name from the server's in 2 you
would also be able to print).
> I tried printing some text with lpr, after while the state was
> aborted.
>
> lpstat -t
> scheduler is running
> system default destination: Canon_BJC-2100
> device for Canon_BJC-2100: implicitclass:Canon_BJC-2100
> Canon_BJC-2100 accepting requests since Tue Dec 5 19:32:48 2017
> printer Canon_BJC-2100 is idle. enabled since Tue Dec 5 19:32:48
> 2017
I would question whether having two queues and two setup mehods
managing them is for the best. I'm not saying you shouldn't be able
to do it but my advice would be
1. Keep cups-browsed on the client. It automatically sets up print
queues from the server's DNS-SD broadcasts. Do not manually set
up any other queue.
2. Stop (or purge) cups-browsed and set up a queue with an ipp://
URI and no PPD (raw).
Both methods have been tested here to work for your printer in your
circumstances.
Have a look at the server and let us know how you go on.
Cheers,
Brian.
Reply to: