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.