On 2022-04-10 at 14:25, Brian wrote: > On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote: > >> On 2022-04-10 at 08:38, Brian wrote: > > [...] > >>> The CUPS web interface is not designed to show the IP address but >>> to display the URI. >> >> This, I think, is exactly the detail that's being complained of. If >> CUPS knows the IP address, it should be possible to get CUPS to >> reveal that IP address. >> >> If on the other hand CUPS *doesn't* know the IP address, but only >> the hostname et cetera (because that's part of the URI, and CUPS >> only knows/stores the URI), then that might be reasonable. > > CUPS uses the standard networking APIs (getaddrinfo, for example) > for resolving DNS names to get IP addresses, just like every other > network service on Linux. CUPS rolling its own DNS resolver would > cause problems on systems with working resolvers. Why reinvent the > wheel? I'm not suggesting that CUPS roll its own DNS resolver. I'm just suggesting (or, rather, was just assuming) that after having first learned the IP address during the discovery process, which probably involves using an external DNS resolver (whether automated or in the form of sysadmin entering IP address manually), it would cache that IP address and make use of that cached value rather than repeating the - presumably relatively expensive - discovery lookup every time. This was based, at least in part, on the expectation that there would/will not be DNS lookup for the printer's IP address from its hostname, since I have rarely if ever seen a network where such lookup was functioning (never mind one where the printer's hostname was reliably meaningful or discoverable by any other means than connecting to it by IP address and asking). If that expectation was out of sync with reality, then so be it. > Basically, CUPS leaves it to libnss-mdns. Why should it have any > record of an IP address when it can easily ask libnss-mdns? We do the > same with avahi-browse. Because the lookup will be more expensive than connecting to the IP address, which is unlikely to have changed - and if it *has* changed, you've got little or no way of telling whether or not the printer you're connecting to now is the same one as used to be at the previously-known address. >> (My previous comments were based on the assumption that all >> communication with the printer would be done based on IP address, >> rather than on symbolic name and on connect-time resolution. That >> may in turn be based on my experience in the Windows world, where >> printer hostnames and DNS lookup are in my experience wildly >> unreliable and as a consequence are very rarely used; I reflexively >> expect that the parts of a system which communicate with a printer >> will always know it primarily, if not exclusively, by its IP >> address.) > > Of corse the IP address is needed, but not by the user. The user is > better served by having the queue name matching the printer. That depends on what information the user is going to be able to access about the printer. I have frequently seen printers which have a front-panel display that will show the IP address. I have never, that I recall, seen a printer which has a display that will readily show the queue name, or the hostname, or any other seemingly-relevant information about the printer's identity. (Besides the model, which tends to also be displayed as part of the printer's physical shell.) In the case which started this thread, the user had the printer's IP address (via a label which, I imagine, stood in the stead of such a display; we also sometimes apply such labels in case the printer loses its IP address in a power outage and has to have it re-applied), but did not have the queue name. Whether or not the queue name matches the printer is irrelevant when the queue name is not what the user can get from the printer itself. -- 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