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 | 20 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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-04-08 22:00 +0200 |
| Message-ID | <Ea2VX-7oPI-3@gated-at.bofh.it> |
| In reply to | #247057 |
On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote: > On Fri, Apr 08, 2022 at 08:08:22PM +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? > > > Now contact you highly paid sys admins to ask them to add a "Location" > > field to whatever the server/printer is advertising. > > So... if your corporate network is not set up in the way that Brian > expects, there is simply nothing you can do about it. You're just > screwed, and must resort to trial and error to figure out where > the printers are. Even though CUPS can magically contact the printers, > it will refuse to tell you how it does that, because of some kind of > policy decision. 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? Trial and error is not neeed. Just an IT department with basic skills and the intention to help users would suffice. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-08 22:30 +0200 |
| Message-ID | <Ea3oZ-7pf2-5@gated-at.bofh.it> |
| In reply to | #247065 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-04-08 at 15:52, Brian wrote: > On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote: > >> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote: >>> Now contact you highly paid sys admins to ask them to add a >>> "Location" field to whatever the server/printer is advertising. >> >> So... if your corporate network is not set up in the way that >> Brian expects, there is simply nothing you can do about it. You're >> just screwed, and must resort to trial and error to figure out >> where the printers are. Even though CUPS can magically contact the >> printers, it will refuse to tell you how it does that, because of >> some kind of policy decision. > > 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. 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. 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. 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. If CUPS found the printer on the network directly, then it certainly also found the printer's IP address. 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. 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. If the printer happens to be one from a central print server, CUPS might not have its IP address locally - but being able to get the information for that print server (whether IP address or hostname or whatever else), along with the identifier used on that print server for the printer, might well be enough to make it possible to proceed forward anyway. -- 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-09 00:50 +0200 |
| Message-ID | <Ea5At-7quB-1@gated-at.bofh.it> |
| In reply to | #247069 |
On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote: > On 2022-04-08 at 15:52, Brian wrote: > > > On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote: > > > >> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote: > > >>> Now contact you highly paid sys admins to ask them to add a > >>> "Location" field to whatever the server/printer is advertising. > >> > >> So... if your corporate network is not set up in the way that > >> Brian expects, there is simply nothing you can do about it. You're > >> just screwed, and must resort to trial and error to figure out > >> where the printers are. Even though CUPS can magically contact the > >> printers, it will refuse to tell you how it does that, because of > >> some kind of policy decision. > > > > 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? > 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? > 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. > > 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. > 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. > 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. > 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 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. It could then be matched with the IP. > If the printer happens to be one from a central print server, CUPS might > not have its IP address locally - but being able to get the information > for that print server (whether IP address or hostname or whatever else), > along with the identifier used on that print server for the printer, > might well be enough to make it possible to proceed forward anyway. Of course. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-09 01:50 +0200 |
| Message-ID | <Ea6wx-7r34-3@gated-at.bofh.it> |
| In reply to | #247073 |
[Multipart message — attachments visible in raw view] — view raw
(This is probably both overly long and overly repetitive, among possibly other undesirable things, but I'm running short on time.) 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? >> 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. >> 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 That only works if IPP is in use, which isn't guaranteed. 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). > 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. 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. 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. > 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). -- 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-09 14:00 +0200 |
| Message-ID | <EahUZ-7z4i-1@gated-at.bofh.it> |
| In reply to | #247076 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-04-09 15:40 +0200 |
| Message-ID | <EajtL-7A7z-1@gated-at.bofh.it> |
| In reply to | #247089 |
On Sat, Apr 09, 2022 at 12:56:12PM +0100, Brian wrote: > 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 I'm not on site now, so I can't recall all of the information that was on the "card" (folded sheet of paper actually). There was something that looked like a Windows pathname, but it did not match any of the names presented by CUPS, and I don't remember exactly what it said.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-10 02:30 +0200 |
| Message-ID | <EatCO-7GEq-3@gated-at.bofh.it> |
| In reply to | #247089 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Teemu Likonen <tlikonen@iki.fi> |
|---|---|
| Date | 2022-04-10 07:00 +0200 |
| Message-ID | <EaxQ6-7Joq-7@gated-at.bofh.it> |
| In reply to | #247120 |
[Multipart message — attachments visible in raw view] — view raw
* 2022-04-10 03:59:25+0100, mick crane wrote: > On 2022-04-10 01:21, The Wanderer wrote: >>> avahi-browse -rt _ipp._tcp >> >> Does that get the information from CUPS? > > With printer connected via other PC (CUPS print server) there is no > output from "avahi-browse -rt _ipp._tcp" Should be, if the print server has setting "Share printers connected to this system". Obviously Cups and Avahi must be running on machines in the same network. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-10 08:40 +0200 |
| Message-ID | <EazoR-7Koo-3@gated-at.bofh.it> |
| In reply to | #247120 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote: [...] > 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.) If that local printer is known to CUPS and the local sysadmin has marked it as shareable (however you do that in CUPS), that would, as I have understood it, be Avahi's job, which is a service (advertisement and) discovery protocol. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 11:50 +0200 |
| Message-ID | <EaCmJ-7M5Y-7@gated-at.bofh.it> |
| In reply to | #247126 |
On Sunday, 10 April 2022 02:33:21 EDT tomas@tuxteam.de wrote: > On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote: > > [...] > > > 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.) > > If that local printer is known to CUPS and the local sysadmin has > marked it as shareable (however you do that in CUPS), that would, > as I have understood it, be Avahi's job, which is a service > (advertisement and) discovery protocol. Then why, after a decade and change of bitching about it because it insists on putting a 169.254.xx,yy address in ones routing table that only removing avahi fixes, has it not been fixed? You can spec the correct address other places such as in /etc/networking/interfaces.d/ anyfilename, or in the last two paragraphs of /etc/dhcpcd.conf, but if avahi is executable, it will override your settings and kill your networking setup dead in the water. And what I mean is that removing it is done behind apt's back by hunting it down and rm-ing it. apt will not remove it w/o destroying the rest of the system. For those of us using hosts files for networking on our little home networks of less that say 16 machines, avahi is the first thing we hunt down and rm after the installers reboot. Only then can we spec a 192.168.xx.yy address to our local gateway and make it stick. Of note is that NOTHING else in the system considers a missing avahi as a loggable event. ONLY apt thinks it is valuable enough to cause its dependencies to destroy the system if you try to remove it with apt as the package manager. Which suits me just fine as its been a headache, looking for a problem that does not exist since it came on the scene. Here, at the coyote.den domain, it does not exist in executable form. Except to pull my trigger when someone recommends that broken concept utility for anything. 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. The missing avahi has nothing to do with that. The only disadvantage is the long walk to retrieve the printout, but I probably needed the exercise anyway. > Cheers > -- > t 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-10 12:10 +0200 |
| Message-ID | <EaCG5-7MrF-3@gated-at.bofh.it> |
| In reply to | #247128 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote: [...] > Then why, after a decade and change of bitching about it because it > insists on putting a 169.254.xx,yy address in ones routing table that > only removing avahi fixes, has it not been fixed? This would be an IPv4 link-local [0] address. Correctly naming things is always the first step to taking control over them: casting spells and that ;-) Setting that up is zeroconf's [1] job, which, AFAIK, is actually done by the avahi daemon. I can't check it myself, because my box has no avahi. But if you know how the thing's called, you can throw your spells at a search engine (hopefully not the one of survellance capitalism, but I disgress ;-) and find things like [2]. It tells you how to convince different systems to not do that; under Debian, this would be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. No need to rm it. But if it satisfies you, you're your box's boss :) I just don't install it. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 13:10 +0200 |
| Message-ID | <EaDC9-7MZK-1@gated-at.bofh.it> |
| In reply to | #247130 |
On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote: > > [...] > > > Then why, after a decade and change of bitching about it because it > > insists on putting a 169.254.xx,yy address in ones routing table that > > only removing avahi fixes, has it not been fixed? > > This would be an IPv4 link-local [0] address. Correctly naming > things is always the first step to taking control over them: > casting spells and that ;-) > > Setting that up is zeroconf's [1] job, which, AFAIK, is actually > done by the avahi daemon. I can't check it myself, because my > box has no avahi. > > But if you know how the thing's called, you can throw your spells > at a search engine (hopefully not the one of survellance capitalism, > but I disgress ;-) and find things like [2]. It tells you how to > convince different systems to not do that; under Debian, this would > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some > /etc/default/avahi-daemon. Then whyintarnation does it not say that in what serves as a man page? > No need to rm it. But if it satisfies you, you're your box's boss :) Exactly. > I just don't install it. And how do you accomplish that? Its automatically installed AFAIK. And once installed, apt will not remove it without destroying the install. rm or chmod -x seems to be the only way, and nothing complains. > 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 | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-10 13:20 +0200 |
| Message-ID | <EaDLP-7N34-1@gated-at.bofh.it> |
| In reply to | #247131 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-04-10 at 07:08, gene heskett wrote: > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: >> I just don't install it. > > And how do you accomplish that? Its automatically installed AFAIK. > And once installed, apt will not remove it without destroying the > install. rm or chmod -x seems to be the only way, and nothing > complains. What package(s), by exact name, are you referring to? That is, which package(s) is it that produce this effect when you try to remove them? On my computer, I have several libavahi* packages, which could not be removed without removing large swaths of packages - but I also have avahi-daemon and avahi-utils, which can be removed with few if any side effects (as far as triggering removal of other packages goes). And since the subject at hand in this branch of the thread appears to be avahi-daemon, surely removing that single package should be enough to prevent avahi from doing anything undesirable? -- 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-10 14:00 +0200 |
| Message-ID | <EaEoy-7NfU-3@gated-at.bofh.it> |
| In reply to | #247132 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 10, 2022 at 07:17:42AM -0400, The Wanderer wrote: > On 2022-04-10 at 07:08, gene heskett wrote: > > > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: > > >> I just don't install it. > > > > And how do you accomplish that? Its automatically installed AFAIK. > > And once installed, apt will not remove it without destroying the > > install. rm or chmod -x seems to be the only way, and nothing > > complains. > > What package(s), by exact name, are you referring to? That is, which > package(s) is it that produce this effect when you try to remove them? > > On my computer, I have several libavahi* packages, which could not be > removed without removing large swaths of packages - but I also have > avahi-daemon and avahi-utils, which can be removed with few if any side > effects (as far as triggering removal of other packages goes). The lib* things are different. That's the price we pay for a binary distribution. I have quite a few libsystemd around. The alternative would be to compile everything. I'm not that uncompromising :) > And since the subject at hand in this branch of the thread appears to be > avahi-daemon, surely removing that single package should be enough to > prevent avahi from doing anything undesirable? Yes, that would be the one implementing zeroconf. As I see, gnome is listed as avahi-daemon dependency. So that could be what happens to Gene. "I'm going to remove Gnome now" does sound scary :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-04-10 14:20 +0200 |
| Message-ID | <EaEHT-7NBK-1@gated-at.bofh.it> |
| In reply to | #247132 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-04-10 at 08:10, gene heskett wrote: > On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > >> On 2022-04-10 at 07:08, gene heskett wrote: >>> And how do you accomplish that? Its automatically installed >>> AFAIK. And once installed, apt will not remove it without >>> destroying the install. rm or chmod -x seems to be the only way, >>> and nothing complains. >> >> What package(s), by exact name, are you referring to? That is, >> which package(s) is it that produce this effect when you try to >> remove them? >> >> On my computer, I have several libavahi* packages, which could not >> be removed without removing large swaths of packages - but I also >> have avahi-daemon and avahi-utils, which can be removed with few if >> any side effects (as far as triggering removal of other packages >> goes). >> >> And since the subject at hand in this branch of the thread appears >> to be avahi-daemon, surely removing that single package should be >> enough to prevent avahi from doing anything undesirable? > > Which IMO It should be but apt will not remove avahi-daemon on any of > my buster machines or on bullseye without taking "large swaths" of > stuff with it. Based on what Tomas said in his reply, I'm guessing that that's because you've got GNOME or some similar fancy DE installed, and that DE's packages declare a dependency on avahi-daemon directly. I don't use such a DE (preferring, instead, a WM so niche that it's not even packaged and in the repositories anymore), so it's no surprise that I wouldn't see that effect - and also, if you do, no surprise that you would. -- 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 | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 14:20 +0200 |
| Message-ID | <EaEHT-7NBK-3@gated-at.bofh.it> |
| In reply to | #247132 |
On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > On 2022-04-10 at 07:08, gene heskett wrote: > > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: > >> I just don't install it. > > > > And how do you accomplish that? Its automatically installed AFAIK. > > And once installed, apt will not remove it without destroying the > > install. rm or chmod -x seems to be the only way, and nothing > > complains. > > What package(s), by exact name, are you referring to? That is, which > package(s) is it that produce this effect when you try to remove them? > > On my computer, I have several libavahi* packages, which could not be > removed without removing large swaths of packages - but I also have > avahi-daemon and avahi-utils, which can be removed with few if any side > effects (as far as triggering removal of other packages goes). > > And since the subject at hand in this branch of the thread appears to > be avahi-daemon, surely removing that single package should be enough > to prevent avahi from doing anything undesirable? Which IMO It should be but apt will not remove avahi-daemon on any of my buster machines or on bullseye without taking "large swaths" of stuff with it. Tomas just found, and I have now edited /etc/default/avahi-daemon to officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 lines of errors into the log every 15 seconds until it takes so long to append the log that the machine is unusable for over 30 seconds at a time and must be rebooted about weekly to recover, all because the installer thinks ANY usb to seriel adaptor plugged in is driving a braille interface. Theres a lot of other reasons to have such on a system, and in fact I have 2 of them, one serviceing my ups, and one servicing a cm-11a interface for heyu. I dare say that is a more common a use than a braille interface. Or a speech synth that isn't understandable, which category orca certainly is in. So I'll repeat my request as to how do I turn off orca AND get rid of the every 15 second error spew to the log because its been killed? > -- > 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 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:40 +0200 |
| Message-ID | <EaFXj-7Ogm-5@gated-at.bofh.it> |
| In reply to | #247138 |
On Sun 10 Apr 2022 at 08:10:17 -0400, gene heskett wrote: > On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > > On 2022-04-10 at 07:08, gene heskett wrote: > > > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: > > >> I just don't install it. > > > > > > And how do you accomplish that? Its automatically installed AFAIK. > > > And once installed, apt will not remove it without destroying the > > > install. rm or chmod -x seems to be the only way, and nothing > > > complains. > > > > What package(s), by exact name, are you referring to? That is, which > > package(s) is it that produce this effect when you try to remove them? > > > > On my computer, I have several libavahi* packages, which could not be > > removed without removing large swaths of packages - but I also have > > avahi-daemon and avahi-utils, which can be removed with few if any side > > effects (as far as triggering removal of other packages goes). > > > > And since the subject at hand in this branch of the thread appears to > > be avahi-daemon, surely removing that single package should be enough > > to prevent avahi from doing anything undesirable? > > Which IMO It should be but apt will not remove avahi-daemon on any of my > buster machines or on bullseye without taking "large swaths" of stuff > with it. > > Tomas just found, and I have now edited /etc/default/avahi-daemon to > officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 I do not think AVAHI_DAEMON_DETECT_LOCAL does what you think it does. It applies to detection of *unicast* dns servers. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-10 14:00 +0200 |
| Message-ID | <EaEoy-7NfU-1@gated-at.bofh.it> |
| In reply to | #247131 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 10, 2022 at 07:08:36AM -0400, gene heskett wrote: > On Sunday, 10 April 2022 06:06:31 EDT tomas@tuxteam.de wrote: [...] > > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some > > /etc/default/avahi-daemon. > > Then whyintarnation does it not say that in what serves as a man page? Sometimes systems become... complex. I guess (just guess) that avahi-daemon has some command-line parameters to manage that. Those would be in the man page. The /etc/default hierarchy is rather a Debian-specific things to provide start-up options to system-wide services (and also to the boot process). Those are picked up from there. > > No need to rm it. But if it satisfies you, you're your box's boss :) > > Exactly. > > > I just don't install it. > > And how do you accomplish that? Its automatically installed AFAIK. And > once installed, apt will not remove it without destroying the install. rm > or chmod -x seems to be the only way, and nothing complains. There are things depending on avahi. I don't need them. I've to jump through some hoops to keep systemd or dbus to be installed (but it's manageable), but avahi hasn't ever tried, yet :-) Current desktop environments won't like that, mind you. But I don't particularly like them, either. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-04-10 13:50 +0200 |
| Message-ID | <EaEeR-7NcQ-5@gated-at.bofh.it> |
| In reply to | #247130 |
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. Thanks 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-04-10 14:10 +0200 |
| Message-ID | <EaEyd-7Nyr-5@gated-at.bofh.it> |
| In reply to | #247133 |
[Multipart message — attachments visible in raw view] — view raw
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. 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. Hint: binary search may be helpful (unstick first half of the USBs and so on). Cheers -- t
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web