Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
> On 2022-06-20 at 08:59, Brian wrote:
>
> > On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote:
> >
> >> On 2022-06-19 at 15:47, Brian wrote:
>
> >>> You (or the OP) would have to say what is meant by "delete".
> >>> CUPS essentially *discover* printers. It is why it exists. Is
> >>> that not wanted?
> >>
> >> I understand the reason for CUPS' existence to be, not
> >> *discovering printers*, but *facilitating the ability to print*.
> >> That could involve discovering printers and presenting them as
> >> available, or it could involve only presenting as available a list
> >> of printers that have been entered into CUPS or otherwise set up in
> >> CUPS by some more manual means. (Among perhaps other
> >> possibilities.)
> >
> > 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.
> >> Certainly at my workplace I understand that our Macs use CUPS for
> >> (network) printing, but at least at one point in our history
> >> (within the past decade), we had to go in and define each printer
> >> by IP address in CUPS on each Mac (or on the central machine which
> >> would be replicated to the others).
> >
> > 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.
> 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.
> The set of printers which are discoverable on the network, and the set
> of printers which are available to applications as print destinations,
> should not have to be the same thing; the former should be generated on
Not a bad iea. Others have also asked for it. Upstream have responed
positively.
> demand whenever discovery is performed, and the latter should be
> maintained locally. It should be possible to populate the latter list
> from the former, selectively, but this should not *have* to happen -
> much less always happen automatically in all cases.
>
> >> I can certainly see it as being reasonable to want to be able to
> >> have CUPS perform printer discovery *on request*, and manually
> >> choose which of the discovered printers to add to the list of ones
> >> that will be remembered and shown as available when printing, but
> >> not have CUPS run discovery *automatically* and *automatically* add
> >> every discovered printer to that list. (I don't know with any
> >> confidence whether CUPS does the latter; I don't run it in enough
> >> environments with enough different available printers to have been
> >> able to make an assessment. However, I do have the impression that
> >> it may.)
> >
> > 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.
> 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.
> As far as I can tell, that's entirely a matter for CUPS, since CUPS is
> the software which would be maintaining such a list and providing such a
> list to the applications which need to print.
>
> If that behavior is possible, it must be CUPS that is providing it. If
> it is not possible, then by the nature of CUPS' purpose and role (that
> of middleman between applications and printers), it must be CUPS that is
> at fault for not providing it.
>
> > 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.
--
Brian.
Reply to: