Bug#883554: cups keeps breaking network printer with implicitclass:
tags 883554 moreinfo
thanks
On Wed 06 Dec 2017 at 18:56:33 +0000, Brian Potkin wrote:
> 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.
Any progress on this, David?
Regards,
Brian.
Reply to: