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.