Re: How long until a deleted printer actually vanishes?

[Marc Haber <mh+debian-printing@zugschlus.de>]

Hi,

On Mon, Jan 28, 2019 at 04:42:13PM +0000, Brian Potkin wrote:
> https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.2.1.pdf

Ok, that's a bit too much to read between two train stops.

> > 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
> 
> 'lpstat -a' only shows local queues. You have set these two up.
> 
> > [6/3709]mh@parada:~ $ lpstat -l -e
> > lpstat: Error - unknown option "e".
> > [7/3710]mh@parada:~ $ 
> 
> '-e' is a new option to lpstat. buster only.
> 
> > [6/4999]mh@fan:~ $ lpstat -a
> > lpstat: No destinations added.
> 
> Destinations are added when a dialog entry (not GTK) is printed to.

Ah! There they are.

> > So, CUPS 2.2.10 on fan will create those temporary queues automatically
> > even without cups-browsed, right?
> 
> Yes. But note that a queue is only created (a PPD appears and stays in
> /etc/cups/ppd for a minute) when the dialog entry is printed to. Queues
> created by cups-browsed are permanent queues.

And my original issue most probably was that those permanent queues
generated by cups-browsed got broken during some update. That can happen
on Unstable, and I now know to simply delete them.

> > The iPad now sees all three queues, and printing on the Lexmark queue
> 
> That's a win, isn't it? Very pleasing because I think it was one of your
> main objectives.

Absolutely!

> > 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.
> 
> In many ways the printing system is at the mercy of PDF it has to deal
> with. This crops up from time to time; I generally try to avoid dealing
> with a user's "bad" PDF issues.

Wise decision.

> > Ouch. Those two, and the upstream bug, and the lack of any
> > maintainer/upstream reaction looks very very frustrating.
> 
> A little. But, in time, someone in a position to take action will
> notice and act.

I surely hope so. Hope dies last. Debian has way too little
knowledgeable people working on KDE, the people working on KDE barely
get it to compile and don't have much time for bug handling.

> > And okular will immediately and happily print once cups-browsed is
> > installed on fan despite it having CUPS 2.2.10?
> 
> I told you you would be glad to have cups-browsed around.

Of course, but it was probably better for my understanding to first
simplify, then get the simple variant to work and then to add complexity
again.

> > 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.
> 
> I think that is the PreserveJobFiles option. It can go in cups.conf.
> The default is 24 hours.

Looks like the issue is no longer here.

> > 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).
> 
> Sorry, I cannot help with that.

No problem, I'll do some experiments with that. Printing sensitive data
is seldomly a good idea, but having a hard copy backup of key material
in a bank locker sometimes needs to do things that might look stupid in
the first place.

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