On 2022-04-09 at 07:56, Brian wrote: > 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. I don't strongly mind that, no. A few of them were probably rephrasings of the same thing in different ways. >> On 2022-04-08 at 18:44, Brian wrote: <snip> >> 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 Does that get the information from CUPS? It looks to me as if it gets the information from the network, via what are probably the same discovery methods as CUPS used to get it. That's not the same as getting the information *from CUPS*, which must logically already have that information. Having a way to get the information at all (and we already seem to have at least two of those, from this thread, one of them being the one you just cited) is not the same as having a way to get the information *from where it must logically already be*, and the apparent lack of the latter is what's bothering me about the described behavior. >>> 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 This seems to be confirming the hypothesis above: that this is not getting CUPS to reveal the information, but performing the same discovery method that CUPS used to get the information. If, for example, the printer was online when CUPS discovered it and is therefore listed in the CUPS interface, but is offline now (perhaps someone accidentally unplugged the network cable from the printer?), I would be mildly surprised if this would still result in showing the IP address of the printer. CUPS, however, must still have that address, from its past discovery. >>>> 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 As above. >>> 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. Okay, those are both details which I didn't know. >> 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. But that's an essential thing to do for designing in discoverability. >>> 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. I honestly don't know the subject very well myself, but I'd definitely like to know it better than I do. One aspect of Windows printer sharing is that it makes it possible to connect a printer not directly to the network, but locally to a particular computer, and then configure that computer to advertise the printer over the network. Other computers can then send jobs to that printer via that computer, which is de-facto a print server for that printer. Do you know whether CUPS is capable of interacting with printers which are shared in that way? (This is a tangent to the topic of the thread, but it fits this local context and it's a thing I'd be interested in.) ISTR that CUPS *is* capable of letting an appropriate sysadmin set a network printer up on the local machine by IP address (which is the standard way of doing network-printer setup on Windows when not using a print server), but my closest connection to that is by way of a former co-worker who used that method to configure printers for MacOS X, and I never got a good look at the details. >> 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 > :). Tell me about it... >>> 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 Does this address the question of how the printer could be matched with the IP? (I could go off on a rant about the usefulness of including the IP address on such a labeling card, but I don't want to make this even more of a tangent and even less productive than it already is.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature