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

Hi Michael,

Thanks a lot for your reply, that clarifies a few things. To begin
with, I didn't know that cups-browsed was the piece responsible for
automatically finding the shared printers, but I did a quick
experiment by uninstalling the cups-browsed package from my system and
the shared printers were no longer being automatically added, even
though I could add them later on manually by explicitly searching for
printers in the local network.

That said, based on your reply I'm not sure that removing cups-browsed
from the system is the right solution here either, and I see
cups-browsed installed in my other Linux machine where I don't have
this issue so I still feel like I'm missing something here.

Would you mind elaborating a bit more on what you mean by "stop using
cups-browsed by default" and "let cupsd/libcups manage the printers
that come and go in such environments"?

Thanks again,
Mario

On Wed, Sep 27, 2017 at 6:05 PM, Michael Sweet <[email protected]> wrote:
> 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-6IF/jdPJHihWk0Htik3J/[email protected]> 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
>> [email protected]
>> https://lists.cups.org/mailman/listinfo/cups-devel
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
> _______________________________________________
> cups-devel mailing list
> [email protected]
> https://lists.cups.org/mailman/listinfo/cups-devel