Re: CUPS - how to match autodetected printers to physical ones
On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:
> (This is probably both overly long and overly repetitive, among possibly
> other undesirable things, but I'm running short on time.)
So I hope you do not mind if I do not reply to every point you make.
> On 2022-04-08 at 18:44, Brian wrote:
>
> > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> >
> >> On 2022-04-08 at 15:52, Brian wrote:
>
> >> > You didn't like my bus analogy, did you?
> >> >
> >> > What makes you think that knowing a bus number and destination
> >> > provudes information for where it departs from?
> >> >
> >> > What makes you think that knowing an IP address tells you where any
> >> > machine of any description is located?
> >>
> >> I'm confused as to why you might think anyone involved in this
> >> conversation thought that.
> >>
> >> There's no reason to expect that knowing an IP address tells you the
> >> location of the device at the other end.
> >
> > The OP explicitly associated IP address with physical location:
> >
> > > "Aha," I thought. "All I have to do is figure out which one of the
> > > autodetected printers on this list has the same IP address as the printer
> > > that I can see and touch over there.
> >
> > The user may be aware of the printer's location, but is the printing
> > system in possession of the same knowledge?
>
> ...I do not follow your reasoning in parsing that statement. I do not
> see how that statement leads in any way to the conclusion that the
> printing system has, or must have, any knowledge of the printer's
> location.
>
> Even if the printing system doesn't have any knowledge of the printer's
> physical location, it must still have some knowledge of the printer's
> *network* location, in the form of an IP address (or other routing
> information, such as in the print-server model described below).
>
> What Greg was asking about, as far as I can tell, is a way to get CUPS
> to tell him that network-location information - so that he, as someone
> external to the printing system, could then apply that information to
> his additional knowledge about the physical location of the printer with
> a specific IP address.
>
> I'm not sure we (in this thread) have yet found a way to do that
> directly; we've found what appear to be two different ways to find the
> IP address of the printer with the name that CUPS is reporting, but it
> looks to me as if both of them are getting that information via an
> external method (probably similar to how CUPS found the printer in the
> first place), rather than getting that information from CUPS itself.
>
> The IP-address (etc.?) information must exist within CUPS, since CUPS is
> able to actually send jobs to the printer; why isn't it straightforward
> and obvious how to get that information *from* within CUPS *to*
> someplace visible?
It is straightforward, I don't know about obvious to all users.
avahi-browse -rt _ipp._tcp
> >> However, if CUPS did autodiscovery and found the printer, then it
> >> must know what the place is that it was looking at when it found
> >> that device.
> >
> > By "place" do you mean physical place?
>
> No. I mean, the place on the network where it got the information.
> (Which will presumably be a place which has an IP address.)
>
> >> Unless I'm missing something, the options are that either CUPS
> >> found the printer in a list of printers being maintained somewhere
> >> else (e.g. a print server on the network), or CUPS found the
> >> printer on the network directly.
> >
> > The same technique is used for both: mDNS/DNS-SD.
>
> I find that plausible enough, but will have to take your word for it.
>
> >> If CUPS found the printer on a list of printers being maintained
> >> somewhere else, then it must have also found information about
> >> that "somewhere else", and that information might include an IP
> >> address.
> >
> > "somewhere else" would have to be explained. It is not part of my
> > inderstanding.
>
> I was referencing the same definition of "somewhere else" as used in the
> previous sentence, where I gave the example of a print server on the
> network.
>
> I was thinking of the design in which a print server maintains a list of
> print queues, and serves as a proxy to receive print jobs and pass them
> to those print queues, so as to both avoid contention on the printer
> itself and facilitate central management of those print queues (rather
> than needing to manage them on the individual endpoints, whether the
> client computers or the printers).
>
> In that case, as the print server would not hand out the IP addresses of
> the printers (since that would enable bypassing the server-side print
> queues), but would only hand out the combination of the server's IP
> address and the name of the print queue to specify when sending jobs to
> that printer via that print server, CUPS would not have access to the IP
> address of the printer itself.
>
> (I could have sworn that I'd found this arrangement documented somewhere
> in the past, but at the moment I can't completely rule out that it's
> anything other than the product of my vivid imagination. It seems like a
> coherent and sane design to my immediate eye, however.)
>
> >> If CUPS found the printer on the network directly, then it
> >> certainly also found the printer's IP address.
> >
> > Indeed. But that information does not give the physical location of
> >
> > > ...the printer that I can see and touch over there.
>
> Not to the print system, it doesn't.
>
> But if that IP-address information is given to the user, who knows the
> IP address of "the printer that I can see and touch over there", then
> the user can determine whether or not "the printer that I can see and
> touch over there" has the same IP address as the printer object seen by
> CUPS, and therefore determine whether or not it is the same printer.
>
> >> Regardless, if CUPS can send a print job to the printer, then it
> >> must have some information to be able to route the job towards
> >> that destination - and that information will certainly include an
> >> IP address at some point along the way, either that of the printer
> >> or of the print server or of some other intermediary system.
> >
> > CUPS knows how to route the job. The physical location of the
> > printer is not involved in the routeing.
>
> True, and I don't understand why you thought it was involved (as relates
> to CUPS) at all.
>
> The IP address, however, *is* involved in the routing - and therefore
> CUPS must know it. (Or some proxy piece of information, as above.)
>
> The original question as I understand it was how to get CUPS to reveal
> that piece of information which it must know.
CUPS uses mDNS/DNS-sd for discovery. The user does the same:
avahi-browse -rt _ipp._tcp
> >> What I understood Greg as asking about is how to get CUPS to *tell*
> >> you what the IP address it knows about for a given printer object
> >> is. That doesn't seem to be an unreasonable thing to want to know,
> >> or to expect CUPS to be able to provide; I'd want the same thing,
> >> in anything remotely like his place.
avahi-browse -rt _ipp._tcp
> > Finding the IP address is easy:
> >
> > ippfind -T 5
> > ipp://envy4500.local:631/ipp/print
> > ping -c 3 envy4500.local
>
> That only works if IPP is in use, which isn't guaranteed.
Communication between CUPS servers is guaranteed to be by IPP. Between
CUPS and modern printers is only via IPP.
> Also, how is that command supposed to be discoverable? Greg certainly
> doesn't seem to have discovered it in his efforts, and I wasn't aware of
> its existence either, and it also hasn't previously been mentioned in
> this thread (despite the mentioning of 'avahi-browse -rt _ipp._tcp',
> which turned out to also be an adequate way of finding out what is
> probably the same information).
I don' think I want to hazard a guess as to users' thought processes.
> > If you were in his place, you should hope that the sys admins would
> > include the physical location of the printer when advertising it.
> > This is part of the IPP standard.
>
> Speaking as someone who has *been* such a sysadmin (though I'm not now,
> except insofar as those who are call on me to help solve problems), I
> can say that aside from specifying the name of the print queue on the
> print server, we've never bothered to set such information that I'm
> aware of.
It is not obligatory but can be useful.
> We also don't use IPP, at least not directly; we define printers on a
> Windows print server, and share them from there, using Windows printer
> sharing. This is probably common in many environments. If Windows
> printer sharing uses IPP in any way, I'm not aware of it.
I am unfamiliar with Windows but would think a CUPS server would not
talk with a Windows server without IPP being involved.
> We do try to put location information in the queue name - but it's not
> terribly uncommon for the printer to get relocated without that name
> being updated, and in some cases without anyone even telling us that the
> printer's been moved.
I forgot about that aspect. Another job for the hard-pressed sysadmin :).
> > It could then be matched with the IP.
>
> ...how? In order to match the physical location with the IP address, you
> have to *know* the IP address of not only the printer at the physical
> location (which Greg did) but the IP address of the printer as seen by
> CUPS (which Greg was not able to figure out how to determine, that being
> the entire point of his original post as far as I can tell).
It woould have been far, far more useful to have had the queue name on
the card. Perhaps it can be added? Printing then becomes a two minute,
no-fuss job:
lp -d DESTINATION FILE
--
Brian.
Reply to: