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.
