On Sat, Jan 26, 2019 at 07:02:21PM +0000, Brian Potkin wrote: > On Sat 26 Jan 2019 at 15:51:51 +0100, Marc Haber wrote: > > On Fri, Jan 25, 2019 at 06:42:25PM +0000, Brian Potkin wrote: > > > On Fri 25 Jan 2019 at 16:27:36 +0100, Marc Haber wrote: > > > > in my overengineered home network, I have > > > > > > > > - a VLAN with my Laser Printer and an Inkjet. > > > > - another VLAN with my CUPS server, parada, running Debian stable > > > > - another VLAN with my desktop workstation, fan, running Debian > > > > unstable and KDE. > > > > - a router/firewall, barrida, running a packet filter and avahi-daemon > > > > in reflector configuration. > > > > > > I have no knowledge or experience of VLANs or reflectors but I will > > > give my interpretation of what the setup does. Please correct it if > > > necessary. > > > > This is very helpful anyway. I am an experienced networker, so we can > > probably together make sense from that. I am especially interested in > > learning about what avahi does and how to debug it. > > My main debugging tool is avahi-browse,
In avahi-browse, I fail to make the connection between the service type such as _http._tcp and the output. For example: [11/5292]mh@drop:~ $ sudo avahi-browse --all --terminate | grep parada + lanw0 IPv6 Lexmark C534 @ parada Internet Printer local + lanw0 IPv6 Canon MX420 series @ parada Internet Printer local + lanw0 IPv6 AirPrint c534-ka51 @ parada Internet Printer local + lanw0 IPv4 AirPrint c534-ka51 @ parada Internet Printer local + lanw0 IPv4 Lexmark C534 @ parada Internet Printer local + lanw0 IPv4 Canon MX420 series @ parada Internet Printer local + lanw0 IPv6 Lexmark C534 @ parada Secure Internet Printer local + lanw0 IPv6 Canon MX420 series @ parada Secure Internet Printer local + lanw0 IPv4 Lexmark C534 @ parada Secure Internet Printer local + lanw0 IPv4 Canon MX420 series @ parada Secure Internet Printer local + lanw0 IPv6 Canon MX420 series @ parada UNIX Printer local + lanw0 IPv6 Lexmark C534 @ parada UNIX Printer local + lanw0 IPv4 Canon MX420 series @ parada UNIX Printer local + lanw0 IPv4 Lexmark C534 @ parada UNIX Printer local + lanw0 IPv6 CUPS @ parada Web Site local + lanw0 IPv4 CUPS @ parada Web Site local [12/5293]mh@drop:~ $ I would assume that each of this lines has a pseudo "host name" under the .local domain? Also, avahi-browse --all --terminate --resolve gives me a truckload of messages like Failed to resolve service 'Lexmark C534 @ parada' of type '_ipp._tcp' in domain 'local': Timeout reached that I cannot make sense from. When the Lexmark printer is on, avahi-browse on parada also sees it: [15/3715]mh@parada:~ $ sudo avahi-browse --all --terminate | grep -iE '(534|lexmark)' | grep -v parada + eth0 IPv4 c534-ka51 FTP File Transfer local + eth0 IPv4 c534-ka51 UNIX Printer local + eth0 IPv4 c534-ka51 Internet Printer local + eth0 IPv4 c534-ka51 Web Site local [16/3716]mh@parada:~ $ And I _think_ that the printer prints PDFs uploaded via ftp just fine, although CUPS seems to access it via _printer._tcp: [21/3721]mh@parada:~ $ sudo lpinfo -v | grep c534 network dnssd://c534-ka51._printer._tcp.local/ [22/3722]mh@parada:~ $ > but on occasion I have used a > .service file in /etc/avahi/services/. See message #7 at > > https://bugs.launchpad.net/hplip/+bug/1797501 So you basically created a test service in your avahi that _should_ look identical to the one you were expecting? > > AirPrint_c534_ka51_parada (Paused, Rejecting Jobs, Not Shared) > > Description: AirPrint_c534_ka51_parada > > Location: > > Driver: Local Raw Printer (grayscale, 2-sided printing) > > Connection: file:///dev/null > > Defaults: job-sheets=none, none media=unknown > > > > After cleaning up, fan now has zero queues visible in fan:631/printers, > > That's ok. You have no local queues set up by you or cups-browsed. That was my intention for debugging purposes. > > and parada:631/printers only shows the Inkjet: > > Am I missing something? Where is the Lexmark? That one was not present at the time of this try. The "AirPrint_c534_ka51_parada" definition was a phantom that vanished with restarting CUPS on parada. I cannot reproduce this and thus would not investigate this any further unless this behavior keeps showing up > > mx420-ka51 (Idle, Accepting Jobs, Shared) > > Description: Canon MX420 series > > Location: KA51 KE > > Driver: Canon PIXMA-MX426 Foomatic/gutenprint-ijs-simplified.5.2 (color) > > Connection: dnssd://MX420-KA51._printer._tcp.local/ > > Defaults: job-sheets=none, none media=iso_a4_210x297mm > > sides=one-sided > > > > evince on fan shows > > c534-ka51 Lexmark C534-KA51 on parada > > mx420-ka51 KA51 KE > > And both can be printed to? No, the "c534-ka51 Lexmark C534-KA51 on parada" didn't work, and I don't remember the message I received when trying to print. I guess that there was no error message and the print job just vanished in tht darkness. > > > > Which daemons (cups? cups-browsed? avahi?) on which hosts do I restart > > > > to have the old printer entry vanish? Or, alternatively, how long do I > > > > have to wait until those entries time out eventually? > > > > > > Stop CUPS on parada; the Inkjet entry(ies) should disappear from Evince. > > > What happens to c534-ka51 Lexmark C534-KA51 on parada? Restarting CUPS > > > should see Inkjet reappear almost instantaneously in Evince. > > > > Stopping cups on parada made both entries vanish, starting cups on > > parada again made the inkjet reappear. > > So parada was responsible for the Lexmark queue. It's gone now, so we > will not worry about it. Right. > > > > Now stop CUPS on fan (this also stops cups-browsed). What happens in > > > Evince? > > > > cups-browsed on fan was already gone when I did those experiments, so > > stopping and starting CUPS on fan didn't have any effect. Do I see > > correctly that CUPS on fan is not needed to access the printers served > > by parada from applications running on fan? > > Not quite. Correct for the GTK print dialog but not for the LibreOffice > and Qt ones. On buster, the later two enumerate remote queues and IPP > printers using CUPS' temporary queue mechanism (see the wiki Glossary > and Index). Without cups-browsed, lpstat gives me the following: [5/3708]mh@parada:~ $ lpstat -a c534-ka51 accepting requests since Sa 26 Jan 2019 15:36:04 CET mx420-ka51 accepting requests since So 23 Sep 2018 17:06:38 CEST [6/3709]mh@parada:~ $ lpstat -l -e lpstat: Error - unknown option "e". [7/3710]mh@parada:~ $ [6/4999]mh@fan:~ $ lpstat -a lpstat: No destinations added. 1 [7/5000]mh@fan:~ $ lpstat -l -e AirPrint_c534_ka51_parada network none ipp://AirPrint%20c534-ka51%20%40%20parada._ipp._tcp.local/cups Canon_MX420_series_parada network none ipps://Canon%20MX420%20series%20%40%20parada._ipps._tcp.local/cups Lexmark_C534_parada network none ipps://Lexmark%20C534%20%40%20parada._ipps._tcp.local/cups [8/5001]mh@fan:~ $ So, CUPS 2.2.10 on fan will create those temporary queues automatically even without cups-browsed, right? > > > > Another question, will my Lexmark C534 (it can do Postscript, prints PDF > > > > uploaded via ftp and alot more, but does not do AirPrint by itself) be > > > > eligible for driverless printing? > > > > > > No. It doesn't use DNS-SD broadcasting. > > > > Ok. So I recreated a queue ("Lexmark C534") on parada, and I can print > > from fan now. Thanks. That was painless. > > > > c534-ka51 (Idle, Accepting Jobs, Shared) > > Description: Lexmark C534 > > Location: KA51 KE > > Driver: Lexmark C534dtn Foomatic/Postscript (recommended) (color, > > 2-sided printing) > > Connection: dnssd://c534-ka51._pdl-datastream._tcp.local/ > > Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided > > > > Now my wife's iPad. The iPad sees the Lexmark C534 queue, and printing > > there works. Glacially slow, but it works, and the iPad gives an > > unspecific error message ("Error while printing" in German), before the > > print job prints OK. She doesn't see the mx420-ka51 queue. > > > > There is clearly something going wrong here. How can I influence this? > > You would have to look at an error_log (how to get one is on the wiki) > to track if the printing system is responsible for the slowness. Will the hints given in https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem also apply to buster? The wiki page only mentions jessie and stretch. Oh, btw, the work you guys have done on the Wiki starting https://wiki.debian.org/Printing is just great. I love it. Don't get me started about the CUPS error_log though. Uncounted the times where stracing the CUPS daemon immediately showed a clear error message from auxillary proceses such as "ghostscript: unable to write to /var/tmp, permission denied" but that never showed up in the CUPS error_log even in the higest debug setting. A horrible mess. > I am unfamiliar with iDevices but I wouldn't have thought that mattered, > (maybe). fan can see the mx420-ka51 queue (on parada,we assume), so why > not the iPad? I'll have a think. You could try setting the queues on fan > to shared. The iPad now sees all three queues, and printing on the Lexmark queue works in reasonable time (now that I have given my wife a simple PDF to print). The one that was so slow was in color, with color gradients, so it might have been legitimate to take ages to render. I also have a bank that keeps sending statement PDFs that literally take five minutes to render, maybe their (monochrome) logo is sent as a 30.000 dpi bitmap or so. > > KDE applications such as okular see historical printer queues that have > > been deleted from CUPS long ago, "AirPrint_c534_ka51_parada", > > "Canon_MX420_series_parada" and "Lexmark_C534_parada". none of which > > seem to work. For example, the Lexmark_C534_parada printer entries does > > not allow me to set values for Duplex (grey) or nup (not present in the > > dialogs) printing. > > Do you see the same three queues with 'lpstat -l -e'? Yes, I do, see above. But they don't seem to work, and not all features of the printer such as duplex printing and not all features of CUPS such as n-up printing seem to be handed through. Where does the AirPrint queue come from? It seems to be gratuitous, both Linux and the iDevices print to the regular "Lexmark_C534_parada" queue just fine. > > When I tell okular to actually print, it says on the console > > "/usr/bin/lpr: No such file or directory", but that file is present, > > from cups-bsd, and invoking it manually from the same shell says "lpr: > > Error - No default destination." stracing okular for hints why this > > fails makes me end up without available printers at all. > > You have confirmed Bug #911702. Do you fancy having a go at #911844? Ouch. Those two, and the upstream bug, and the lack of any maintainer/upstream reaction looks very very frustrating. > Installing cups-browsed on fan is necessary to avoid both bugs. And okular will immediately and happily print once cups-browsed is installed on fan despite it having CUPS 2.2.10? After installing cups-browsed on fan I now have: AirPrint_c534_ka51_parada accepting requests since So 27 Jan 2019 18:50:14 CET Canon_MX420_series_parada accepting requests since So 27 Jan 2019 18:50:14 CET Lexmark_C534_parada accepting requests since So 27 Jan 2019 18:50:13 CET [18/5010]mh@fan:~ $ lpstat -l -e AirPrint_c534_ka51_parada network none ipp://AirPrint%20c534-ka51%20%40%20parada._ipp._tcp.local/cups Canon_MX420_series_parada network none ipps://Canon%20MX420%20series%20%40%20parada._ipps._tcp.local/cups Lexmark_C534_parada network none ipps://Lexmark%20C534%20%40%20parada._ipps._tcp.local/cups [19/5011]mh@fan:~ $ And, indeed, okular prints just fine to the Lexmark_C534_parada queue, I can now see and activate all features of the printer, same goes for LibreOffice. I cannot think of any other use case that I need urgently. I think that all of my real problems have been solved with your help, with the only real changes that were done were removing cups-browsed from parada, deleting all queues on fan and recreating the Lexmark queue on parada. Btw, I have been wondering for years whether there is a mechanism cleaning up temporary spool files from past print jobs on the CUPS server. /var/*/cups on parada is surprisingly clean in these days, so there must be some (rather new?) mechanism. And, also btw, when I print sensitive stuff like passwords etc, would it be sufficient to temporarily mount a tmpfs over /var/spool/cups and restart the daemon to avoid this sensitive data staying on disk? Since the system must always be ready to lose /var/spool, maybe having a LUKS device mounted with a random key on /var/spool/cups would be a good idea for parada? Probably also /var/tmp, right (/tmp is a tmpfs anyway). Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
