Re: CUPS - how to match autodetected printers to physical ones
On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> On 2022-04-08 at 15:52, Brian wrote:
>
> > On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:
> >
> >> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
>
> >>> Now contact you highly paid sys admins to ask them to add a
> >>> "Location" field to whatever the server/printer is advertising.
> >>
> >> So... if your corporate network is not set up in the way that
> >> Brian expects, there is simply nothing you can do about it. You're
> >> just screwed, and must resort to trial and error to figure out
> >> where the printers are. Even though CUPS can magically contact the
> >> printers, it will refuse to tell you how it does that, because of
> >> some kind of policy decision.
> >
> > 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?
> 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?
> 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.
>
> 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.
> 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.
> 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.
> 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.
Finding the IP address is easy:
ippfind -T 5
ipp://envy4500.local:631/ipp/print
ping -c 3 envy4500.local
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. It could then be matched with the IP.
> If the printer happens to be one from a central print server, CUPS might
> not have its IP address locally - but being able to get the information
> for that print server (whether IP address or hostname or whatever else),
> along with the identifier used on that print server for the printer,
> might well be enough to make it possible to proceed forward anyway.
Of course.
--
Brian.
Reply to: