Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #247046 > unrolled thread
| Started by | Greg Wooledge <greg@wooledge.org> |
|---|---|
| First post | 2022-04-08 18:20 +0200 |
| Last post | 2022-04-08 21:30 +0200 |
| Articles | 15 on this page of 75 — 12 participants |
Back to article view | Back to linux.debian.user
CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 18:20 +0200
Re: CUPS - how to match autodetected printers to physical ones Tixy <tixy@yxit.co.uk> - 2022-04-08 19:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Tixy <tixy@yxit.co.uk> - 2022-04-08 19:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 19:30 +0200
Re: CUPS - how to match autodetected printers to physical ones didier gaumet <didier.gaumet@gmail.com> - 2022-04-08 20:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-08 21:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 22:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Stefan Monnier <monnier@iro.umontreal.ca> - 2022-04-08 23:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 21:40 +0200
Re: CUPS - how to match autodetected printers to physical ones David Wright <deblis@lionunicorn.co.uk> - 2022-04-08 21:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Fred <fred@blakemfg.com> - 2022-04-08 21:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-09 17:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 14:50 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 15:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 16:00 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 16:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 16:40 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 23:00 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 15:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 19:50 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 20:40 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 21:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 21:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 21:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-11 16:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-11 18:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-11 18:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-11 19:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-11 19:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-11 20:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-11 20:30 +0200
Re: CUPS - how to match autodetected printers to physical ones "Gareth Evans" <donotspam@fastmail.fm> - 2022-04-11 21:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-08 21:20 +0200
Re: CUPS - how to match autodetected printers to physical ones Tixy <tixy@yxit.co.uk> - 2022-04-08 22:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-09 01:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-09 01:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Tixy <tixy@yxit.co.uk> - 2022-04-09 09:20 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-08 21:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 21:30 +0200
Re: CUPS - how to match autodetected printers to physical ones David Wright <deblis@lionunicorn.co.uk> - 2022-04-08 21:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-08 22:00 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-08 22:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-09 00:50 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-09 01:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-09 14:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-09 15:40 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 02:30 +0200
Re: CUPS - how to match autodetected printers to physical ones Teemu Likonen <tlikonen@iki.fi> - 2022-04-10 07:00 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 08:40 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 11:50 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 12:10 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 13:10 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 13:20 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 14:00 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 14:20 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 14:20 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 15:40 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 14:00 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 13:50 +0200
Re: CUPS - how to match autodetected printers to physical ones <tomas@tuxteam.de> - 2022-04-10 14:10 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 14:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 15:00 +0200
Re: CUPS - how to match autodetected printers to physical ones gene heskett <gheskett@shentel.net> - 2022-04-10 15:40 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 16:50 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 14:40 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 15:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-10 20:30 +0200
Re: CUPS - how to match autodetected printers to physical ones The Wanderer <wanderer@fastmail.fm> - 2022-04-10 21:10 +0200
Re: CUPS - how to match autodetected printers to physical ones David Wright <deblis@lionunicorn.co.uk> - 2022-04-09 03:00 +0200
Re: CUPS - how to match autodetected printers to physical ones Brian <ad44@cityscape.co.uk> - 2022-04-09 14:10 +0200
Re: CUPS - how to match autodetected printers to physical ones Greg Wooledge <greg@wooledge.org> - 2022-04-08 22:30 +0200
On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] <tomas@tuxteam.de> - 2022-04-09 08:40 +0200
Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] Brian <ad44@cityscape.co.uk> - 2022-04-09 13:50 +0200
Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] <tomas@tuxteam.de> - 2022-04-09 14:10 +0200
Re: CUPS - how to match autodetected printers to physical ones David Wright <deblis@lionunicorn.co.uk> - 2022-04-08 21:30 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 14:50 +0200 |
| Message-ID | <EaFaV-7NLf-5@gated-at.bofh.it> |
| In reply to | #247136 |
On Sunday, 10 April 2022 08:02:32 EDT tomas@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote: > > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: > > > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. > > > > Checking all my machines, all but one was set to 1, fixed the others > > and redid the initramfs as it said in 2 of the 5, in that file. > > > > Thank you for that Tomas, now its done by the official way including > > on this bullseye box. I also took advantage and disabled brltty by > > similar means. That leaves orca dirtying the logs with about 20 > > lines every 15 seconds. And that leads to a reboot about weekly by > > filling up the /var partition. Orca however, does not appear in > > /etc/default. Where is it started so I can officially stop it? That > > would extend my uptimes I expect. > > As it came out in That Other Thread :) I think this is some rogue USB > serial adapter fooling udev that it is a Braille input. Find that, fix > your udev rules (or dump the adapter). > > Background: whenever you stick an USB into your device tree, it tells > udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But > of course, this comes roundabout: it tells the maker and the maker's > device model as a pair of numbers. > > There's a lot of things which may go wrong there: from an inexact > device database to some cheap manufacturer skimping on the USB > consortium membership and squatting on wrong identifiers. > Or even ducks the issue by all-balling the identifiers. Those most often encountered looking like a usb key gismo and soon find the trash can. But since fdti is the only maker of seriel adaptors that actually works, proliic tried but failed miserably, I see no reason not to reach thru the adaptor and see if its actually a braille device, rather that blindly assuming it is when there are many other often legacy devices that need the adaptor. The cm11a to control your lights and appliances interface is likely at least 30 years old, and the protocol was known in the mid 80's. I wrote software in the late 80's to do that from a trs-80 Color Computer running os9-level one, then jim hines and I moved it to amigados using ARexx and sold registered copies of it for a few years. Called it ezhome based on something else we wrote called ezcron since amigados had no cron utility. We gave that away. > Once we have more details perhaps someone can lead you through the > process. But test-booting the thing while some USB devices are > unplugged until you find the culprit is something only you can do. True Tomas, but my attempts to install w/o it have all failed as it will not reboot without it so a reboot turns into a new install, 20 some times now, which I'm sick of doing, hence my questions that keep harping on getting rid of it gracefully AFTER the install. Basicly, whats done should have an undo method and I will keep asking until the magic phrase comes out of someones fingertips. In the meantime I am reminded of it by the need to reboot weekly in order to have a usable machine. > Hint: binary search may be helpful (unstick first half of the USBs > and so on). > > Cheers > -- > t Take care and stay well, Tomas. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-10 15:00 +0200 |
| Message-ID | <EaFkC-7NOJ-13@gated-at.bofh.it> |
| In reply to | #247128 |
On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: [...] > This, FWIW, has nothing to do with cups and printer sharing, cups does > its own advertising. All printers here are attached to this machine, > marked as shareable and I can put stuff on their output trays from any > machine including the rpi4 on my local network. Indeed, CUPS does do its own advertising of print queue and uses mDNS/DNS-SD. That is its *only* technique it has available for sharing the queues. mDNS/DNS-SD requires avahi-daemon to be active. Without it there isn't any sharing and advertising. So, I do not understand "...has nothing to do with...". -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 15:40 +0200 |
| Message-ID | <EaFXj-7Ogm-1@gated-at.bofh.it> |
| In reply to | #247144 |
On Sunday, 10 April 2022 08:54:07 EDT Brian wrote: > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: > > [...] > > > This, FWIW, has nothing to do with cups and printer sharing, cups > > does > > its own advertising. All printers here are attached to this machine, > > marked as shareable and I can put stuff on their output trays from > > any > > machine including the rpi4 on my local network. > > Indeed, CUPS does do its own advertising of print queue and uses > mDNS/DNS-SD. That is its *only* technique it has available for > sharing the queues. > > mDNS/DNS-SD requires avahi-daemon to be active. Without it there > isn't any sharing and advertising. > > So, I do not understand "...has nothing to do with...". > The avahi-daemon has either been removed by rm. or by chmod -x on all machines here, yet cups shared printers (plural) can use those shared printers just as if they were plugged into that machine. So IMO removing or disabling avahi-daemon has nothing to do with cups sharing. You are saying it won't work, but it does here. What else is there except cups. > -- > Brian. > > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-10 16:50 +0200 |
| Message-ID | <EaH34-7OT7-11@gated-at.bofh.it> |
| In reply to | #247146 |
On Sun 10 Apr 2022 at 09:31:59 -0400, gene heskett wrote: > On Sunday, 10 April 2022 08:54:07 EDT Brian wrote: > > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: > > > > [...] > > > > > This, FWIW, has nothing to do with cups and printer sharing, cups > > > does > > > its own advertising. All printers here are attached to this machine, > > > marked as shareable and I can put stuff on their output trays from > > > any > > > machine including the rpi4 on my local network. > > > > Indeed, CUPS does do its own advertising of print queue and uses > > mDNS/DNS-SD. That is its *only* technique it has available for > > sharing the queues. > > > > mDNS/DNS-SD requires avahi-daemon to be active. Without it there > > isn't any sharing and advertising. > > > > So, I do not understand "...has nothing to do with...". > > > The avahi-daemon has either been removed by rm. or by chmod -x on all > machines here, yet cups shared printers (plural) can use those shared > printers just as if they were plugged into that machine. So IMO removing > or disabling avahi-daemon has nothing to do with cups sharing. > You are saying it won't work, but it does here. What else is there except > cups. You can print from an rpi4 to a printer attached to another machine on the network. There are only two ways this can happen: * The rpi4 knows about the print server via mDNS/DNS-SD. * There is a manual queue set up on the rpi4. Only you can decide which it is. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-10 14:40 +0200 |
| Message-ID | <EaF1f-7NHT-11@gated-at.bofh.it> |
| In reply to | #247120 |
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.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-10 15:00 +0200 |
| Message-ID | <EaFkB-7NOJ-1@gated-at.bofh.it> |
| In reply to | #247140 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-04-10 at 08:38, Brian wrote: > On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote: > >> On 2022-04-09 at 07:56, Brian wrote: >>> 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, That will very definitely vary depending on the user. > who is better served by being informed of the URI. This may be true in some cases, but is very definitely not true in all. > For various reasons, IP addresses can change, of course; printers > being moved round the network, for example. This is based on a set of assumptions which may apply in some cases, but very definitely do not apply in all cases. I don't want to dive deep into them, however, since this has already gone on long enough. >>> 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. 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. (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.) -- 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
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-10 20:30 +0200 |
| Message-ID | <EaKtX-7R2U-5@gated-at.bofh.it> |
| In reply to | #247143 |
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? 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. > (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. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-10 21:10 +0200 |
| Message-ID | <EaL6F-7Rvg-1@gated-at.bofh.it> |
| In reply to | #247162 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2022-04-09 03:00 +0200 |
| Message-ID | <Ea7Ch-7rF8-3@gated-at.bofh.it> |
| In reply to | #247073 |
On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote: > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote: > > 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 Would the ping output give an IP address like the one quoted (10.76.172.100), or would you only get a 169.254/16 one? (I've not run an mDNS configured network.) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-09 14:10 +0200 |
| Message-ID | <Eai4F-7zn9-3@gated-at.bofh.it> |
| In reply to | #247078 |
On Fri 08 Apr 2022 at 19:57:53 -0500, David Wright wrote: > On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote: > > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote: > > > > 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 > > Would the ping output give an IP address like the one quoted > (10.76.172.100), or would you only get a 169.254/16 one? > (I've not run an mDNS configured network.) brian@desktop:$ ping -c 1 envy4500.local PING envy4500.local (192.168.7.235) 56(84) bytes of data. 64 bytes from 192.168.7.235 (192.168.7.235): icmp_seq=1 ttl=255 time=31.3 ms -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-04-08 22:30 +0200 |
| Message-ID | <Ea3oZ-7pf2-3@gated-at.bofh.it> |
| In reply to | #247065 |
On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote: > You didn't like my bus analogy, did you? I don't think it's a very good analogy for this situation. > What makes you think that knowing an IP address tells you where > any machine of any description is located? Because the device is (was) sitting 50 feet away from me, and even if the people who installed it had not been kind enough to print some kind of config page and attach it to the front of the printer, I could have Googled the printer's model number and found out how to print the printer's own config page myself. Or else how to scroll through the printer's control panel menus to find its IP address that way. The printer's brand, model and IP address are the extremely concrete pieces of information that I can readily acquire and compare. Software that refuses to divulge useful information is not acting in a helpful manner. Also, completely coincidentally, I happen to know how the corporate network is subdivided -- at least in the building that I work in. Each floor has a /23 network assigned to it. So, from the IP address alone, I can at least tell whether the device is on my floor. If I need more specific location info than that, I would either have to call someone, or search manually. > Trial and error is not neeed. Just an IT department with basic > skills and the intention to help users would suffice. I wonder how many IT departments match both parts of that description. In any case, "avahi-browse -rt _ipp._tcp" was helpful and useful, so thank you for that. I've typed it into my notes for next time I need it.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-09 08:40 +0200 |
| Subject | On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] |
| Message-ID | <EacVj-7w0K-5@gated-at.bofh.it> |
| In reply to | #247065 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote: [...] > You didn't like my bus analogy, did you? I did like it. Nevertheless, I thought something's missing: > 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? This is, of course, not guaranteed. But "the system" might provide for the user not being an idiot and perhaps having bits of info "the system" doesn't. In Greg's (was he the OP? I lost the thread in the process) case it's the IP address stuck on the printer (most printers these days tell you, if you ticke their menus for long enough, BTW). In the bus's case, perhaps there is a big sign on the parking lot "NEUF-BRISACH". There, that's your IP address. Back to the printers, I'm horrified at the idea that CUPS doesn't tell you the IP address it thinks the printer is at. It's what I call "authoritarian software", where the software thinks it's smarter than me. Don't get me wrong, I like comfort like the next guy, but I don't like being treated like an idiot. Look: if some programmer gal thinks she's smarter than me, I go "arrogant gal, but who knows, probably she's right". But if a piece of software does that, I tend to kick it out of my box. My box, my rules :) And yes: no CUPS (no Avahi either) on my box :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-09 13:50 +0200 |
| Subject | Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] |
| Message-ID | <EahLj-7z0U-5@gated-at.bofh.it> |
| In reply to | #247081 |
On Sat 09 Apr 2022 at 08:33:31 +0200, tomas@tuxteam.de wrote: > On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote: > > [...] > > > You didn't like my bus analogy, did you? > > I did like it. Nevertheless, I thought something's missing: In general, analogies don't really work, do they? > > 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? > > This is, of course, not guaranteed. But "the system" might provide > for the user not being an idiot and perhaps having bits of info > "the system" doesn't. > > In Greg's (was he the OP? I lost the thread in the process) case > it's the IP address stuck on the printer (most printers these days > tell you, if you ticke their menus for long enough, BTW). Setting up a queue in some circumstances may require knowledge of an IP address. Printing to it doesn't. The wrong path was taken. > In the bus's case, perhaps there is a big sign on the parking lot > "NEUF-BRISACH". There, that's your IP address. > > Back to the printers, I'm horrified at the idea that CUPS doesn't > tell you the IP address it thinks the printer is at. It's what > I call "authoritarian software", where the software thinks it's > smarter than me. Don't get me wrong, I like comfort like the next > guy, but I don't like being treated like an idiot. What is important for printing is the queue name (the destination) an the URI. Cups will take care of all the nitty-gritty in getting the job to the printer. A card with the queue name would have saved much head scratching. > Look: if some programmer gal thinks she's smarter than me, I go > "arrogant gal, but who knows, probably she's right". But if a > piece of software does that, I tend to kick it out of my box. > My box, my rules :) > > And yes: no CUPS (no Avahi either) on my box :-) Avahi is not mandatory for printing. However, it does benefit many users. Plug in a mouse. It wors straightaway. Nobody gives it a secomd thought. Nowadays, plug in a modern printer to USB and, with Avahi, it is immediately available for printing. What is there to dislike? People have been asking for this level of operation for years. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-09 14:10 +0200 |
| Subject | Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones] |
| Message-ID | <Eai4F-7zn9-9@gated-at.bofh.it> |
| In reply to | #247088 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Apr 09, 2022 at 12:47:09PM +0100, Brian wrote: > On Sat 09 Apr 2022 at 08:33:31 +0200, tomas@tuxteam.de wrote: > > > On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote: > > > > [...] > > > > > You didn't like my bus analogy, did you? > > > > I did like it. Nevertheless, I thought something's missing: > > In general, analogies don't really work, do they? In a former life, I used to be physicist. We actually thrive from analogies :) [...] > Setting up a queue in some circumstances may require knowledge of > an IP address. Printing to it doesn't. The wrong path was taken. That's, strictly speaking, right; in the OP's case, it'd been helpful to finding the printed rag, though. > > In the bus's case, perhaps there is a big sign on the parking lot > > "NEUF-BRISACH". There, that's your IP address. > > > > Back to the printers, I'm horrified at the idea that CUPS doesn't > > tell you the IP address it thinks the printer is at. It's what > > I call "authoritarian software", where the software thinks it's > > smarter than me. Don't get me wrong, I like comfort like the next > > guy, but I don't like being treated like an idiot. > > What is important for printing is the queue name (the destination) > an the URI. Cups will take care of all the nitty-gritty in getting > the job to the printer. A card with the queue name would have saved > much head scratching. That didn't help the OP. To back out from analogy land, a piece of software which makes available to me as much info as it can has more of my sympathy. Doing it in a well-structured and discoverable way gets it 100+ points of sympathy. I appreciate the designer's hard work in this. > > > Look: if some programmer gal thinks she's smarter than me, I go > > "arrogant gal, but who knows, probably she's right". But if a > > piece of software does that, I tend to kick it out of my box. > > My box, my rules :) > > > > And yes: no CUPS (no Avahi either) on my box :-) > > Avahi is not mandatory for printing. However, it does benefit many > users. I know, I know. Before kicking out Avahi I looked into what it does. It was a voluntary decision, which most definitely isn't right for everyone. > Plug in a mouse. It wors straightaway. Nobody gives it a secomd > thought. Nowadays, plug in a modern printer to USB and, with Avahi, > it is immediately available for printing. What is there to dislike? > People have been asking for this level of operation for years. Overgeneralisation works even less than analogies :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2022-04-08 21:30 +0200 |
| Message-ID | <Ea2sV-7oFy-3@gated-at.bofh.it> |
| In reply to | #247054 |
On Fri 08 Apr 2022 at 20:08:22 (+0100), Brian wrote: > On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote: > > How is one *supposed* to figure out which autodetected printer is the > > correct one, apart from trial and error? > > Fancy an analogy? > > My local bus intercange has display screens showing bus nummbers and > destinations (IP addresses). It does not display the stands the buses > start from. Whose responsibillity is that down to? > > You got it! > > Now contact you highly paid sys admins to ask them to add a "Location" > field to whatever the server/printer is advertising. Where I used to work, they got this right: they put /user/ information into the Queue name, where it can't but be seen, using the pattern DeptRoom_unusualCharacteristics. So MathsB037 might be an ordinary one (A4 B&W), and PhysicsS221_A3_colour_foil would be something rather special, that might only operate at certain times of day when they load the foil. Cheers, David.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.debian.user
csiph-web