Re: [DNG] Avahi [was Weird network issue]
On Tue, Oct 16, 2018 at 11:29:28AM +0200, Alessandro Selli wrote: > Somehow administering the printer is not > considered a facet of infrastructure sysadminship, it's instead like a > dirty floor: you don't wash it yourself if someone spilled their Double > Hot Chocolate mug on it, you call the janitor to clean up the mess instead. But then there isn't a janitor for the printer. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On 16.10.2018 11:29, Alessandro Selli wrote: > I find it amazing how often there is no one who knows anything> technical > about the printer, and I do not mean the list of printing or> shared filesystem protocols it supports or if it can take Postscript/PDF> files directly, but not even it's IP or whether at the given IP I can> find the printer itself or some PC acting as a print spooler. A couple> of times when I asked how comes no one knew anything about the printer I> was answered something like: "Oh well, it got setup by some guy years> ago, I was not even here when he did the job, and anyway nobody bothers> to know so long as it works". Somehow administering the printer is not> considered a facet of infrastructure sysadminship, it's instead like a> dirty floor: you don't wash it yourself if someone spilled their Double> Hot Chocolate mug on it, you call the janitor to clean up the mess instead. hmm, perhaps we should build some fancy product for that, something with the word "ENTERPRISE" written in very big letters onto it ;-) --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On 16/10/18 at 03:31, Rick Moen wrote: > Quoting Alessandro Selli (alessandrose...@linux.com): > >> "Go to 'Settings', 'Network' and 'Search the local network', when you >> see the icon with the printer double click on it and accept the download >> of the driver and install it if you don't have it". >> >> This is the answer I get 99% of the times when I ask. > Yeah, well, if I got that, I'd pretend to be really grateful, say 'Thank > you _so_ very much!', and then go quietly figure out the real answer for > myself. Yes, that's what I end up doing many of the times, usually nmappping the net for some host with a 515 or 631 port open and directing the browser to it's IP and see if and what printer is there. In some larger enterprise setting this did not work because of some firewall/intrusion-detection system that'd block my probes. I find it amazing how often there is no one who knows anything technical about the printer, and I do not mean the list of printing or shared filesystem protocols it supports or if it can take Postscript/PDF files directly, but not even it's IP or whether at the given IP I can find the printer itself or some PC acting as a print spooler. A couple of times when I asked how comes no one knew anything about the printer I was answered something like: "Oh well, it got setup by some guy years ago, I was not even here when he did the job, and anyway nobody bothers to know so long as it works". Somehow administering the printer is not considered a facet of infrastructure sysadminship, it's instead like a dirty floor: you don't wash it yourself if someone spilled their Double Hot Chocolate mug on it, you call the janitor to clean up the mess instead. > https://rationalwiki.org/wiki/Dunning-Kruger_effect > (See also .signature block.) Yeah, good reading! Thumbs up for Socrates! ☺ -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
Le 15/10/2018 à 20:33, Rowland Penny a écrit : On Mon, 15 Oct 2018 11:12:41 -0700 Rick Moen wrote: Quoting Didier Kryn (k...@in2p3.fr): This is fine if you always work in the same place. During my professional life, I used to travel to various labs and found it convenient to automatically find, in the cups menu of my laptop, a list of the local printers. And to always have the list up to date when the computing department installed/removed old/new printers. I respect that. For the sake of community knowledge, I'll also tell you what I do as an alternative: When I visit a new location, I look around for a networked printer, and see if it happens to have a label on it including its IP address (usually not). If not, I can usually figure out from the printer's front-panel controls how to make it print out an information sheet to proclaim its network access details. (For example, all HP laser printers have a standard way to do this.) If I cannot easily figure that out, I type its make/model into a Web browser to look up how on the Web. Either way, within a couple of minutes, I know details of how to print on it, usually over my choice of several protocols (lpr, ipp, etc.) Or, if there's someone technical handy, I lazily ask 'Hey, how would I print directly to this printer?' And a possibly amusing cautionary tale: After the dot-com collapse, a small firm named California Digital Corporation (CDC) picked up the hardware business that Larry Augustin decided my old firm VA Linux Systems could no longer compete in, resuming manufacture and sale of VA Linux's models (and successors to those) under their new brand. (Incidentally, they showed that Augustin's pessimistic conclusion had been in error, as they were prosperous in that industry segment for quite a few years, and had numerous achievements to boast, including building for Lawrence Livermore Labs the #2 HPC cluster in the world, a 1024 quad-Itanium computing cluster named 'Thunder'.) CDC was run by a husband and wife firm, the Aruns. I was for a while their system administrator and de-facto IT guy. One morning, I walked in, and Ms. Arun was very vexed, because she said that printing was not working anywhere around the firm. Notably, she said there had been a power outage right at the beginning of the business day. I conducted tests of printing to several of the HP JetDirect printers across the network, and everything worked fine. Moreover, all of the technical staff were having no problem at all printing. It was just the executive staff reporting total printing failure. Getting to the bottom of the problem required looking at the printing setup objects of those people's -- yes -- Microsoft Windows workstations. Each of them had a printer object that was defined as a queue on the controller's (the main company accountant's) workstation. Every single executive was routing all print jobs through that poor fellow's workstation, before those jobs then recrossed the network out to the printer near the executive offices. (Meanwhile, the technical staff were enjoying faster, more reliable, more direct printing.) As it happened, the controller's workstation had an ATX power supply that was set to put the workstation in standby power mode after a power loss, rather than come back online. So, from I politely asked 'Why aren't people printing directly to the executive LaserJet?' -- and, predictably, heard 'How do you do that?' It seems that someone had originally helped the controller print to the executive printer and, in so doing, had created on that workstation a Network Neighbourhood queue object, advertised to the network. Subsequently, every time someone on the executive staff set up printing, he/she groped in Network Neighbourhood, found the accountant's printing object, and assumed that was the only way to reach the executive printer. I re-did all of the executives' printing so that they did JetDirect printing straight to the printer, replacing their convoluted and fragile workaround. This is part of why I would rather not trust to automated printer discovery. I'd rather know what I'm doing, instead of assuming someone else knows what's good for me, as that often is not the case. Well, it's a burden to always do everything by hand. This reminds of the time I was asked at work why printing was so slow. This was after a so called expert had supposedly set up the network. It was years ago and it was a small XP workgroup, I traced it down to the print server the 'expert' had installed on the network and connected to the main printer i.e. the one everybody used. This by itself wasn't the problem, the problem was that he had then setup the printer driver on one PC and then shared it across the network, all printing went through that PC. After I spent about an hour sorting this out and print speed went up by a large amount, the 'expert' was asked not to come back and I got a promotion. I never had that problem of printing being slow
Re: [DNG] Avahi [was Weird network issue]
Le 15/10/2018 à 20:12, Rick Moen a écrit :
We noticed, if the network
became saturated, the stacks became unusable in this order:
1. AppleTalk (Apple)
2. NetBEUI (Microsoft)
3. IPX/SPX (Novell Netware)
The fourth stack, TCP/IP, was never observed to become unusable (though
of course a severe enough problem_could_ take it down).
The difference owed mostly to good vs. bad design, but in no small part
to how 'chatty' they were -- how some plastered the network with
excessive announcement and acknowledgement blasts, and others did not.
The DNS-SD ('dnssd') / mDNS stack_absolutely_, in that regard, reminds
me of AppleTalk.
Kill it with fire. ;->
It's true that these networks which work by broadcast consume a lot
of the bandwidth. They aren't designed for large LANs. But service
discovery is something very handy. I imagine it might be centralized
into a local DNS server, with maybe some extension of the protocol,
instead of letting every host talk to every host. I don't want to waste
time figuring out printer properties and maintaining a printer list on
my laptop. There are already too many reasons to waste time.
Didier
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
Quoting Alessandro Selli (alessandrose...@linux.com): > "Go to 'Settings', 'Network' and 'Search the local network', when you > see the icon with the printer double click on it and accept the download > of the driver and install it if you don't have it". > > This is the answer I get 99% of the times when I ask. Yeah, well, if I got that, I'd pretend to be really grateful, say 'Thank you _so_ very much!', and then go quietly figure out the real answer for myself. https://rationalwiki.org/wiki/Dunning-Kruger_effect (See also .signature block.) -- Cheers, "It ain't so much the things we don't know that get us Rick Moenin trouble. It's the things we know that ain't so." r...@linuxmafia.com -- Artemus Ward (1834-67), U.S. journalist (attr.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On 15/10/18 at 20:12, Rick Moen wrote: [...] > Or, if there's someone technical handy, I lazily ask 'Hey, how would I > print directly to this printer?' "Go to 'Settings', 'Network' and 'Search the local network', when you see the icon with the printer double click on it and accept the download of the driver and install it if you don't have it". This is the answer I get 99% of the times when I ask. Because no one in the building remembers or ever knew what the printer's IP is. At most they'd tell me it's name. Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On Mon, 15 Oct 2018 11:12:41 -0700 Rick Moen wrote: > Quoting Didier Kryn (k...@in2p3.fr): > > > This is fine if you always work in the same place. During my > > professional life, I used to travel to various labs and found it > > convenient to automatically find, in the cups menu of my laptop, a > > list of the local printers. And to always have the list up to date > > when the computing department installed/removed old/new printers. > > I respect that. For the sake of community knowledge, I'll also tell > you what I do as an alternative: > > When I visit a new location, I look around for a networked printer, > and see if it happens to have a label on it including its IP address > (usually not). If not, I can usually figure out from the printer's > front-panel controls how to make it print out an information sheet to > proclaim its network access details. (For example, all HP laser > printers have a standard way to do this.) If I cannot easily figure > that out, I type its make/model into a Web browser to look up how on > the Web. Either way, within a couple of minutes, I know details of > how to print on it, usually over my choice of several protocols (lpr, > ipp, etc.) > > Or, if there's someone technical handy, I lazily ask 'Hey, how would I > print directly to this printer?' > > > And a possibly amusing cautionary tale: After the dot-com collapse, a > small firm named California Digital Corporation (CDC) picked up the > hardware business that Larry Augustin decided my old firm VA Linux > Systems could no longer compete in, resuming manufacture and sale of > VA Linux's models (and successors to those) under their new brand. > (Incidentally, they showed that Augustin's pessimistic conclusion had > been in error, as they were prosperous in that industry segment for > quite a few years, and had numerous achievements to boast, including > building for Lawrence Livermore Labs the #2 HPC cluster in the world, > a 1024 quad-Itanium computing cluster named 'Thunder'.) > > CDC was run by a husband and wife firm, the Aruns. I was for a while > their system administrator and de-facto IT guy. One morning, I walked > in, and Ms. Arun was very vexed, because she said that printing was > not working anywhere around the firm. Notably, she said there had > been a power outage right at the beginning of the business day. > > I conducted tests of printing to several of the HP JetDirect printers > across the network, and everything worked fine. Moreover, all of the > technical staff were having no problem at all printing. It was just > the executive staff reporting total printing failure. > > Getting to the bottom of the problem required looking at the printing > setup objects of those people's -- yes -- Microsoft Windows > workstations. Each of them had a printer object that was defined as a > queue on the controller's (the main company accountant's) workstation. > Every single executive was routing all print jobs through that poor > fellow's workstation, before those jobs then recrossed the network out > to the printer near the executive offices. (Meanwhile, the technical > staff were enjoying faster, more reliable, more direct printing.) > > As it happened, the controller's workstation had an ATX power supply > that was set to put the workstation in standby power mode after a > power loss, rather than come back online. So, from > > I politely asked 'Why aren't people printing directly to the executive > LaserJet?' -- and, predictably, heard 'How do you do that?' > > It seems that someone had originally helped the controller print to > the executive printer and, in so doing, had created on that > workstation a Network Neighbourhood queue object, advertised to the > network. Subsequently, every time someone on the executive staff set > up printing, he/she groped in Network Neighbourhood, found the > accountant's printing object, and assumed that was the only way to > reach the executive printer. > > I re-did all of the executives' printing so that they did JetDirect > printing straight to the printer, replacing their convoluted and > fragile workaround. > > This is part of why I would rather not trust to automated printer > discovery. I'd rather know what I'm doing, instead of assuming > someone else knows what's good for me, as that often is not the case. > This reminds of the time I was asked at work why printing was so slow. This was after a so called expert had supposedly set up the network. It was years ago and it was a small XP workgroup, I traced it down to the print server the 'expert' had installed on the network and connected to the main printer i.e. the one everybody used. This by itself wasn't the problem, the problem was that he had then setup the printer driver on one PC and then shared it across the network, all printing went through that PC. After I spent about an hour sorting this out and print speed went up by a large amount, the 'expert' was asked not to come back
Re: [DNG] Avahi [was Weird network issue]
Quoting Didier Kryn (k...@in2p3.fr): > This is fine if you always work in the same place. During my > professional life, I used to travel to various labs and found it > convenient to automatically find, in the cups menu of my laptop, a > list of the local printers. And to always have the list up to date > when the computing department installed/removed old/new printers. I respect that. For the sake of community knowledge, I'll also tell you what I do as an alternative: When I visit a new location, I look around for a networked printer, and see if it happens to have a label on it including its IP address (usually not). If not, I can usually figure out from the printer's front-panel controls how to make it print out an information sheet to proclaim its network access details. (For example, all HP laser printers have a standard way to do this.) If I cannot easily figure that out, I type its make/model into a Web browser to look up how on the Web. Either way, within a couple of minutes, I know details of how to print on it, usually over my choice of several protocols (lpr, ipp, etc.) Or, if there's someone technical handy, I lazily ask 'Hey, how would I print directly to this printer?' And a possibly amusing cautionary tale: After the dot-com collapse, a small firm named California Digital Corporation (CDC) picked up the hardware business that Larry Augustin decided my old firm VA Linux Systems could no longer compete in, resuming manufacture and sale of VA Linux's models (and successors to those) under their new brand. (Incidentally, they showed that Augustin's pessimistic conclusion had been in error, as they were prosperous in that industry segment for quite a few years, and had numerous achievements to boast, including building for Lawrence Livermore Labs the #2 HPC cluster in the world, a 1024 quad-Itanium computing cluster named 'Thunder'.) CDC was run by a husband and wife firm, the Aruns. I was for a while their system administrator and de-facto IT guy. One morning, I walked in, and Ms. Arun was very vexed, because she said that printing was not working anywhere around the firm. Notably, she said there had been a power outage right at the beginning of the business day. I conducted tests of printing to several of the HP JetDirect printers across the network, and everything worked fine. Moreover, all of the technical staff were having no problem at all printing. It was just the executive staff reporting total printing failure. Getting to the bottom of the problem required looking at the printing setup objects of those people's -- yes -- Microsoft Windows workstations. Each of them had a printer object that was defined as a queue on the controller's (the main company accountant's) workstation. Every single executive was routing all print jobs through that poor fellow's workstation, before those jobs then recrossed the network out to the printer near the executive offices. (Meanwhile, the technical staff were enjoying faster, more reliable, more direct printing.) As it happened, the controller's workstation had an ATX power supply that was set to put the workstation in standby power mode after a power loss, rather than come back online. So, from I politely asked 'Why aren't people printing directly to the executive LaserJet?' -- and, predictably, heard 'How do you do that?' It seems that someone had originally helped the controller print to the executive printer and, in so doing, had created on that workstation a Network Neighbourhood queue object, advertised to the network. Subsequently, every time someone on the executive staff set up printing, he/she groped in Network Neighbourhood, found the accountant's printing object, and assumed that was the only way to reach the executive printer. I re-did all of the executives' printing so that they did JetDirect printing straight to the printer, replacing their convoluted and fragile workaround. This is part of why I would rather not trust to automated printer discovery. I'd rather know what I'm doing, instead of assuming someone else knows what's good for me, as that often is not the case. > >(Check the authors of Avahi, and you'll see a familiar name.) > > I guess some Lennart guy is involved. Got it in one. > I don't think he is pure evil. Nor I. I just find it amusing that he went out of his way to implement a network protocol that I consider a blight on networks, a thing that IMO is best eliminated. Back in the 1980s, I worked as IT staff (or, as we then said, MIS) at a firm called Blyth Software. This was just before the transition from network hubs to network switches, where the latter implicitly helped alleviate network congestion by localising traffic. Blyth's LAN was a somewhat monstrous thing with an odd history, and putting a network analyser box onto it revealed interesting things, which we spent some time studying. In those days, if there was a cable problem, or a failing/chattering ethernet card,
Re: [DNG] Avahi [was Weird network issue]
Le 14/10/2018 à 22:42, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Avahi daemon is the Linux dnssd service. dnssd is a protocol for service discovery on LAN (formerly known as Apple "Bonjour"). The essential utility for me is to allow to discover CUPS servers on the LAN, because recent versions of CUPS advertise their presence by the dnssd protocol instead of the former ad hoc protocol. dnssd is the most annoyingly and pointlessly chatty network protocol since Appletalk. If like me you don't want that crud junking up your network, edit the line 'BrowseRemoteProtocols dnssd cups' in cupsd.conf to 'BrowseRemoteProtocols none' and restart cupsd. Blessed silence will ensue. This is fine if you always work in the same place. During my professional life, I used to travel to various labs and found it convenient to automatically find, in the cups menu of my laptop, a list of the local printers. And to always have the list up to date when the computing department installed/removed old/new printers. This of course requires determining a target printer's IP address and supported network transports, when configuring printing, rather than having it be automagical. (Quelle horreur!) (Check the authors of Avahi, and you'll see a familiar name.) I guess some Lennart guy is involved. I don't think he is pure evil. The problem is that he hasn't simplicity amongst his targets. But a few of his things works, like avahi and ifplugd. Maybe Avahi is chatty, but I never found it on my way reversing any of my configuration choices or forcing anything on me. After all it is just the implementation on Linux of a protocol which is now a multi-os standard, even if it originated in Apple (which isn't a criteria of quality). I think one has to remain realistic and only avoid potterware when there is choice. There is concerning systemd, thanks Devuan, and a few other, and there is concerning pluseaudio, thanks apulse. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
