Re: CUPS - how to match autodetected printers to physical ones
On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote:
> 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 delegates resolution of hosts and services to mDNS; I am happy
to follow in its footsteps.
CUPS may very well know the IP address but it is not of direct interest
to the user, who is better served by being informed of the URI. For
various reasons, IP addresses can change, of course; printers being moved
round the network, for example.
> >>> 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.
Yes.
> 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.
The CUPS web interface is not designed to show the IP address but to
display the URI. However, the URI might give an IP address if it is
a socket://... or lpd://... URI.
An offlin machine would continue to list information for manually
set up queues.
If CUPS retains an address of a previous connection, I am not aware
of a way to extract it
> >>>> 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.
I'm no expert, either.
> 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.)
I think that is possible, but, as you say, its tangential.
> 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.
An IP address would be used with a socket://... URI.
> >> 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?
Your probing has just set off a train of thought to tackle that in
another way. I wil outline the solution in another post.
--
Brian.
Reply to: