Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022, at 23:50, Gareth Evans <donotspam@fastmail.fm> wrote:
> On Mon 20 Jun 2022, at 23:31, Gareth Evans <donotspam@fastmail.fm> wrote:
>> On Mon 20 Jun 2022, at 17:34, The Wanderer <wanderer@fastmail.fm> wrote:
>>> On 2022-06-20 at 12:01, Brian wrote:
>>>
>>>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>>>>
>>>>> On 2022-06-20 at 08:59, Brian wrote:
>>>
>>>>>> The ability to print to an IPP printer involves discovering its
>>>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>>>> on-demand or manual queue.
>>>>>
>>>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>>>> known, it should be possible for CUPS to simply accept the URI and
>>>>> work with it from then on, without discovery entering into the
>>>>> picture.
>>>>
>>>> "...once the URIis known"? What mechaism does that? Incidentally, a
>>>> URI is required to query a printer for its attributes.
>>>
>>> Any of a number of mechanisms.
>>>
>>> CUPS could run discovery once, then either A: present the discovered URI
>>> with a prompt for whether to add it to its local list of known printers
>>> or B: add it to that list automatically, and then in either case not run
>>> discovery again until something asks it to.
>>>
>>> The user could run discovery manually (e.g. from the command line), then
>>> enter the discovered URI into CUPS.
>>>
>>> The user could look at another computer where the URI is already present
>>> in CUPS, and copy that across to the computer at hand.
>>>
>>> I could probably come up with more options if I thought about it for
>>> long enough.
>>>
>>>>>> Setting up a manual queue for a moden printer is still available
>>>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>>>> and they should (barring bugs) appear in an application's print
>>>>>> dialog without any intervention.
>>>>>
>>>>> The thing is, though, sometimes this is *undesirable*.
>>>>
>>>> It is possible that upstream CUPS would agree. The intention is to
>>>> do something about it eventually.
>>>
>>> Depending on what the "something" is, that could be a very positive
>>> development!
>>>
>>>>> Going back to my workplace as an example, we have one subnet per
>>>>> building per floor, and one printer per classroom; we want the
>>>>> computers in each room to be able to see and print to the printer
>>>>> from that classroom, *only*. Having the ones from the other
>>>>> classrooms show up in the applications' print dialog would be a
>>>>> problem.
>>>>
>>>> DNS-SD doesn't traverse subnets.
>>>
>>> Yes, but we don't have one subnet per classroom, we have one subnet per
>>> floor, with multiple classrooms per floor.
>>>
>>>>>> You can control whether Avahi browses for printers or not but
>>>>>> cannt make it selective in its browsing. DNS-SD is an
>>>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>>>> of the display screens at airports.
>>>>>
>>>>> That's just about discovery, though. I'm talking about what's done
>>>>> with the discovered information.
>>>>>
>>>>> It sounds to me as if it's being said that CUPS takes the
>>>>> discovered information and automatically puts every discovered
>>>>> printer into the list of printers that will be made available in
>>>>> the print dialog (or equivalent).
>>>>>
>>>>> That should not be the only option. It should also be possible to
>>>>> run discovery, manually select zero or more printers from the set
>>>>> discovered, and add *just those printers* to the list of those
>>>>> that will be shown in the print dialog
>>>>>
>>>>> (It should also be possible to add printers to that list manually,
>>>>> without running discovery, if you know the necessary information.)
>>>>
>>>> That's certainly possible at present.
>>>
>>> I figured, and seemed to recall, but did not want to assume.
>>>
>>>>> The result would be being able to be sure that the list of printers
>>>>> available in the print dialog will only change if someone manually
>>>>> modifies it, rather than changing automatically if the set of
>>>>> printers discoverable on the network changes.
>>>>
>>>> Other would see the automatic change as a definite plus.
>>>
>>> And in some cases so would I! But not in others. And my interpretation
>>> of Gene's original complaint, as you quoted it, would suggest that he is
>>> in a case where he also would not.
>>>
>>> That's why whether or not this discovery-and-updating process is
>>> performed automatically should be *configurable*.
>>>
>>>>>> I beleive filtering of a printer list using LDAP is something
>>>>>> being considered for inclusion in a future CUPS.
>>>>>
>>>>> Why should LDAP need to be involved? Unless you're using an
>>>>> external print server to get the printer list from (in which case
>>>>> things become in some ways simpler and in other ways considerably
>>>>> more complicated), the list of printers that applications should
>>>>> see is local, and should be able to be maintained locally without
>>>>> bringing external things such as LDAP into the picture.
>>>>
>>>> My understanding of LDAP is very limited. All I know is that CUPS
>>>> will eshew simple filtering. It has been tried, and didn't work.
>>>
>>> I don't even know why filtering would be involved. You're not starting
>>> with a longer list and filtering it to show only a subset; you're
>>> starting with an empty list, populating it (either manually, or
>>> automatically but only on demand) from a longer one, storing the
>>> resulting list, and later showing it on demand.
>>>
>>> Or, at least, that's the way it *should* work.
>>>
>>> If there's a reason why filtering needs to be involved, given that "two
>>> separate lists" model, I'd be interested in seeing that reason
>>> clarified.
>>>
>>> (I can see why it would be useful in a model which says that the list
>>> which is available to applications is always updated automatically from
>>> the list generated by discovery; in that context you'd need some way to
>>> tell the system which things from the discovered list should be included
>>> or excluded from the made-available list. But since that shouldn't be
>>> the only behavior, filtering shouldn't be the starting point for
>>> thinking about this.)
>>>
>>> --
>>> The Wanderer
>>>
>>> The reasonable man adapts himself to the world; the unreasonable one
>>> persists in trying to adapt the world to himself. Therefore all
>>> progress depends on the unreasonable man. -- George Bernard Shaw
>>>
>>>
>>> Attachments:
>>> * signature.asc
>>
>> My understanding is that /queues/ appear in application dialogs and
>> seem to be what is at issue.
>>
>> I can't test this as my combination of cups + printer isn't working as
>> expected, but from /etc/cups/cups-browsed.conf:
>>
>> "# Set CreateIPPPrinterQueues to "No" to not auto-create print queues
>> # for IPP network printers.
>>
>> [...]
>>
>> # cups-browsed by default creates local print queues for each shared
>> # CUPS print queue which it discovers on remote machines in the local
>> # network(s). Set CreateRemoteCUPSPrinterQueues to "No" if you do not
>> # want cups-browsed to do this. For example you can set cups-browsed
>> # to only create queues for IPP network printers setting
>> # CreateIPPPrinterQueues not to "No" and CreateRemoteCUPSPrinterQueues
>> # to "No"."
>>
>
>
>> If cups or avahi still provide a list of /printers/
>
> ... and queues from other reachable CUPS instances ...
>
>> when setting up
>> /queues/ manually, doesn't this provide a mechanism to achieve
>> "list-on-demand" with queues otherwise hidden to applications and
>> system-config-printer?
>>
>> Best wishes,
>> Gareth
Though duplicating a "printer" (which I had come to consider a queue) in system-config-printer results in another PPD file in /etc/cups/ppd/, so I guess there's one queue per "printer representation with settings".
Reply to: