[cups-devel] CUPS_PRINTER_REMOTE for automatically added printers on Linux

Wed Sep 27 10:05:20 PDT 2017

Mario,

CUPS_PRINTER_REMOTE (and CUPS_PRINTER_DISCOVERED) are a bit of a legacy.  Modern CUPS no longer automatically creates printer queues for every network/shared printer it sees, and we do NOT recommend using things like cups-browsed to do so, either.  There *is* a hack in cupsd for flagging queues that point to ipp://something/printers/somethingelse with the CUPS_PRINTER_REMOTE printer-type bit, but it is simply not a reliable indicator that a particular print queue points to a remote (shared) printer.

One of the features of CUPS 2.2.x is that cupsGetDests/cupsEnumDests will return shared printers on the currently associated network(s) whether those printers have been added or not.  The first time you use one of these printers, a temporary print queue is automatically created to manage spooling, etc.  After some period of inactivity, the printer then goes away.

So my advice is to a) stop using cups-browsed by default (it has its uses, but printing in coffee shops and coworking spaces is not one of them...) and b) let cupsd/libcups manage the printers that come and go in such environments.

> On Sep 27, 2017, at 12:23 PM, Mario Sanchez Prada <mario at endlessm.com> wrote:
> 
> Hi,
> 
> I've trying to debug an issue for a while in our Linux-based operating
> system [1] that has been an annoyance for our users in certain
> scenarios, and I thought I'd ask here for some advice, because I'm
> clearly missing things in the way, as I'm not sure whether it's a bug
> in CUPS, or wrong usage of the CUPS API from gnome-settings-daemon.
> 
> FWIW, I'm using CUPS 2.2.4, which I believe is the latest release, and
> the problem observed could be summarized as this:
> 
> When using our OS in busy network environments like coffee shops and
> coworking spaces a notification often pops up to let you know that a
> shared printer (or many) has been automatically found and installed,
> from among those shared by nearby Apple or Microsoft users. By poking
> at the code involved (CUPS, which provides all the information related
> to the printers, and gnome-settings-daemon (g-s-d, from this point
> on), which is in charge of notifying these kind of events), it seems
> clear to me that the intention in GNOME is NOT to report these events
> for *remote* printers, as you can see in [2] and [3].
> 
> However, g-s-d *does* report those events in our OS, so I debugged it
> and found that the problem is that the `printer-type` attribute for
> those printers, as retrieved via cupsGetOption, does not contain
> neither the CUPS_PRINTER_REMOTE nor the CUPS_PRINTER_IMPLICIT bits,
> which is what g-s-d checks for (see [2]), therefore determining that
> the printer is local, and thus reporting the notification to the user.
> 
> Doing some more debugging, I found that the `printer-type` attribute
> reported by CUPS is not empty at all, it actually makes kind of sense:
> for instance, for the first printer found it contained the bits
> CUPS_PRINTER_BW, CUPS_PRINTER_COLOR, CUPS_PRINTER_SMALL,
> CUPS_PRINTER_MEDIUM, CUPS_PRINTER_VARIABLE... and
> CUPS_PRINTER_NOT_SHARED. So, it's not that CUPS is not returning valid
> data, it's definitely returning it.
> 
> What strikes me a bit, with my limited knowledge on the matter, is
> that at some point I could see in the debug-verbose logs how CUPS was
> setting the bits I would expect for the "printer-type" attribute right
> when adding the printer, that is, the *very same bits I mentioned
> above* (_BW, _COLOR, _SMALL...) plus CUPS_PRINTER_REMOTE, but no trace
> of CUPS_PRINTER_NOT_SHARED.
> 
> With this observation in mind, I did poke the CUPS code to try to
> understand why CUPS was apparently "replacing" _REMOTE with
> _NOT_SHARED, but all I could find is the place where _NOT_SHARED is
> added to the printer's type in [4], at which point it looks like the
> _REMOTE bit is already gone, and I failed to see where that bit got
> actually removed (if it was ever added).
> 
> So, after all this struggling I think I'm now at a point where I could
> use some help :-). I guess my questions would be something like:
> 
>  * What flags for printer-type should I expect from an automatically
> added printer in Linux? _REMOTE?, _IMPLICIT? _DISCOVERED? Other?
>  * Is it correct to determine whether a printer is remote by doing
> something like what g-s-d does in [2] and [3]? Should it be done in a
> different way?
>  * Is there perhaps a configuration option in CUPS that affects this behaviour?
>  * Any other comment/advice that you might find interesting to help
> me keep debugging this issue?
> 
> For the sake of completeness, this is what `lpinfo -v` prints when I
> run it from the terminal after those printers got automatically added
> by my CUPS instance, just by connecting to the local network:
> 
> ```
> network dnssd://Canon%20MG4100%20series%20%40%20moucho._ipp._tcp.local/cups?uuid=5103d1bd-3bfd-3be9-598e-825bbcf3f291
> network dnssd://EPSON%20XP-412%20413%20415%20Series%20%40%20moucho._ipp._tcp.local/cups?uuid=fd210d3f-28bb-3e6c-5d43-f3dfe564aeb5
> network dnssd://HP%20LaserJet%20Professional%20P1606dn%20%40%20MacBook%20Pro._ipp._tcp.local/cups?uuid=a763098c-4512-3f50-5638-612450c829d1
> network dnssd://RICOH%20Aficio%20MP%20C2500%20%40%20moucho._ipp._tcp.local/cups?uuid=561c2092-e732-3294-6dce-38018345d2fe
> network dnssd://SHARP%20MX-3060N._printer._tcp.local/
> network dnssd://Samsung%20ML-1610%20%40%20MacBook%20Pro._ipp._tcp.local/cups?uuid=1caadc2a-4e7d-3f74-5e1d-55af53304a99
> ```
> 
> Any help very much appreciated. Also, please feel free to ask me to
> perform any more tests that might be interesting, if it's a bug in
> CUPS I'd be very happy to spend time helping to fix it.
> 
> Thanks in advance and sorry for the long email.
> Mario
> 
> [1] https://endlessos.com
> [2] https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/print-notifications/gsd-print-notifications-manager.c#n505
> [3] https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/print-notifications/gsd-print-notifications-manager.c#n164
> [4] https://github.com/apple/cups/blob/d2123aee5550f3b984e5bd8b11a6abbbd9913485/scheduler/ipp.c#L5055
> _______________________________________________
> cups-devel mailing list
> cups-devel at cups.org
> https://lists.cups.org/mailman/listinfo/cups-devel

_________________________________________________________
Michael Sweet, Senior Printing System Engineer