Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Le 16/10/2018 à 07:10, Rick Moen a écrit : Quoting goli...@dyne.org (goli...@dyne.org): With help from my Devuan friends the connection times have improved significantly. After little poking around and a very interesting talk with my ISP, I decided that the ISP's DNS resolver was contributing significantly to the slow connection times. A suggestion from a Devuan ninja, encouraged me install unbound. Ding! Glad that works for you. (And, as other Dng regulars know, I am a huge fan of doing exactly that.) Yes, ISP recursive nameservers are very frequently awful as to performance. Also as to security, privacy, and reliability, by the way. Which is one of several reasons to try running a recursive DNS daemon of your own, on your own side of the pipe, and use that in preference to other people's recursive nameservers. Any reading to recommend about recursive, authoritative or what else name servers ? ___ 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: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]
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 b
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]
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] Introducing myself....
On Mon, Oct 15, 2018 at 01:42:04PM +0100, g4sra wrote: > > As an experienced systems administrator with strong gut instincts I can > 'bolt stuff together' that 'just works' 24x7x365. Unfortunately, I am > only a mediocre programmer, but despite that is my intention to > contribute to Devuan what little I can and try to keep my mouth shut > about the stuff I don't know. Don't shut up about what you don't know! Ask questions about it! After checking if there's already an answer online, of course. -- 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 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] Introducing myself....
On 15.10.2018 14:42, g4sra wrote: welcome. > The issue as I see it is that Linux is becoming commercialised by the > likes of Red Hat and other big players (Oracle, IBM, etc, etc). ACK. That's IMHO one of the major reasons for the massive quality degradation in recent years ... just look at the desktop crap ... :o > As an experienced systems administrator with strong gut instincts I can > 'bolt stuff together' that 'just works' 24x7x365. Unfortunately, I am > only a mediocre programmer, but despite that is my intention to > contribute to Devuan what little I can and try to keep my mouth shut > about the stuff I don't know. Looks like you're perfect guy for things like testing, infrastructure, valuable input on how to improve operating, etc, etc. > What I am looking for from the Devuan community now is an open > discussion about the alternative init systems, what is available (I have > googled and read a little), when to use which, and a very good reason > why I shouldn't just boot straight into bash and go it alone with a bit > of python ;) I personally, got tired of inventing yet another init system - did that over 20 years ago (actually, some things not so different from *early* systemd - before they became totally nuts). The problem, IMHO, isn't so much creating an init system, but maintaining the corresponding config/scripts for all the packages. One thing we perhaps could do is inventing a small declarative meta- config language for certain common service types / usecases, so we could automatically generate a large portion of the scripts/config automatically for many init systems. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Quoting Didier Kryn (k...@in2p3.fr): > Any reading to recommend about recursive, authoritative or > what else name servers ? Not trying to be perverse, but: What would you like to know? I'll give you two answers, where the first one is my effort to avoid seeming to promote my own writings. Zytrax has over the years had truly excellent online materials about DNS, and the current iteration is this really good (gratis but not libre) online book, _DNS for Rocket Scientists_: http://www.zytrax.com/books/dns/ Also, over the years when I was one of the editors for _Linux Gazette_, I wrote an intermittant series of articles on aspects of DNS for the interested layman. All of my _Linux Gazette_ articles are collected here, along with a picture of me gazing off myopically into the middle distance wondering why there is a blond-reddish caterpillar on my upper lip: http://linuxmafia.com/~rick/moen-lg.html (The hairy caterpillar eventually pupated and flew away, i.e., I no longer have facial hair, as the Devuan regulars who've seen me on video chat are aware.) I might immodestly suggest the slightly whimsical article (linked above) ' The Village of Lan: A Networking Fairy Tale' as a reasonable place to start, as it disambiguates the several types of DNS namserver software (recursive vs. authoritative vs. forwarder) using a quaint metaphor. Also, an earlier article 'The Basics of DNS' (likewise linked) attempted the same thing with less whimsy. Last, further straining the limits of Scandinavian-American self-deprecation, I might recommend my concise bestiary of all know DNS software for Linux, classifying them by category: http://linuxmafia.com/faq/Network_Other/dns-servers.html -- Rick Moen "The correct plural forms are as follows: r...@linuxmafia.comsurgeons general, brothers-in-law, Spiders-Man." McQ! (4x80) -- @FakeAPStylebook ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Am 16/10/2018 um 10:46 schrieb Didier Kryn: > > Any reading to recommend about recursive, authoritative or what else > name servers ? IIRC it doesn't cover everything and by no means is it technical, detailed or deep, but it's way too cute not to mention it: https://howdns.works/ -- Evilham signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
Rick Moen wrote: > I respect that. For the sake of community knowledge, I'll also tell you > what I do as an alternative: ... > 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 politely asked 'Why aren't people printing directly to the executive > LaserJet?' -- and, predictably, heard 'How do you do that?' 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. IMO you've demonstrated why such things as DNS-SD and mDNS are a good idea. You and I have the skills to go and find the printer's IP address, but we are not typical users who cannot do that. In much the same way, you (I assume) and I are happy to edit text files etc to configure our systems, but we are not typical users who cannot do that. So it comes down to a) try to kill the chatty discovery protocols and perpetuate the "geeks vs users" divide, or b) allow them and allow people to use technology for themselves. Don't forget that it's not all that long ago when people who owned cars employed a driver to operate it for them - now we are (mostly) all our own drivers now. Didier Kryn wrote: > 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. Exactly. Computers are supposed to do stuff for us, not have us do stuff for them. I was already using computers when the Mac came along (yes I know there were earlier examples, but it was really the Mac that made it out of the lab and onto people's desks), and I recall many complaints from software developers that it was hard to write programs for it. Back then, software was written on the basis of making the user do much of the hard work ... Where I used to work at the time, their standard word processor was Display Write from IBM. With this, you entered edit mode to work on your document but could not print from there. To print, you had to save the document and go into a different menu. From the developer's PoV it made things easy - the user can only do things that are allowed in the mode they are in. Then the Mac came along, now the user could just choose to print any time they liked. So the developer had to write their program to deal with user events *when the user wants to do them* rather than when the program allows. This made the developer's life harder - but now the computer did more and the user did less - ie the computer was doing more of the work instead of the user. Lots of overhead, more code, more memory required, etc, etc. But easier for the user. Sound familiar ? As an aside, I had to take the MIS people to task over document standards - which were all written on the basis that a word processor is just a glorified typewriter with fixed pitch fonts (eg "the left margin with be 12 spaces"). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Le 16/10/2018 à 20:28, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Any reading to recommend about recursive, authoritative or what else name servers ? Not trying to be perverse, but: What would you like to know? I'll give you two answers, where the first one is my effort to avoid seeming to promote my own writings. Zytrax has over the years had truly excellent online materials about DNS, and the current iteration is this really good (gratis but not libre) online book, _DNS for Rocket Scientists_: http://www.zytrax.com/books/dns/ Also, over the years when I was one of the editors for _Linux Gazette_, I wrote an intermittant series of articles on aspects of DNS for the interested layman. All of my _Linux Gazette_ articles are collected here, along with a picture of me gazing off myopically into the middle distance wondering why there is a blond-reddish caterpillar on my upper lip: http://linuxmafia.com/~rick/moen-lg.html (The hairy caterpillar eventually pupated and flew away, i.e., I no longer have facial hair, as the Devuan regulars who've seen me on video chat are aware.) I might immodestly suggest the slightly whimsical article (linked above) ' The Village of Lan: A Networking Fairy Tale' as a reasonable place to start, as it disambiguates the several types of DNS namserver software (recursive vs. authoritative vs. forwarder) using a quaint metaphor. Also, an earlier article 'The Basics of DNS' (likewise linked) attempted the same thing with less whimsy. Last, further straining the limits of Scandinavian-American self-deprecation, I might recommend my concise bestiary of all know DNS software for Linux, classifying them by category: http://linuxmafia.com/faq/Network_Other/dns-servers.html Le 16/10/2018 à 20:33, Evilham a écrit : Am 16/10/2018 um 10:46 schrieb Didier Kryn: Any reading to recommend about recursive, authoritative or what else name servers ? IIRC it doesn't cover everything and by no means is it technical, detailed or deep, but it's way too cute not to mention it: https://howdns.works/ Thanks guys. I will eventually be able to install some local dns in an educated way. Not that I have ever had problem with my ISP, but better be prepared. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Case studies of high-traffic web sites running Devuan?
Are there any case studies about large, high-traffic web sites running Devuan? For my part I understand that it is just Debian without the nasty bits. However, some are leery of change and would like at least anecdotal support that it is as reliable, or more so, than Debian. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] dig vs nslookup: was Weird network issue - slow to resolve IPs
On Sat, 13 Oct 2018 23:52:34 -0700 Rick Moen wrote: Rick's first word of the following paragraph refers to the dig program... > It's the most versatile and reliable tool around for testing DNS > functionality -- which in turn is useful to be able to test separately > from the separate task of actually making connections for services > after resolving DNS names to find where to reach them. What's your opinion of nslookup as an alternative to dig? Not sure, but I think you need to install bind to get dig, and not everyone wants to install bind. Thanks, SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Sun, 14 Oct 2018 09:13:12 +0200 Didier Kryn wrote: > Hi Golinux. > > Did you try to list your favorite sites in /etc/hosts ? This is > a primitive and oldfashioned, but very simple, way to see if you hit > a DNS issue or are routed to a slow lane. > > Didier Nice! SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Sun, 14 Oct 2018 02:30:09 -0500 goli...@dyne.org wrote: > > wicd finds a connection automatically. I think it uses DHCP. All > these years I have managed to avoid the fine points of networking > because it's always "just worked". > > Anyway, /etc/resolv.conf is one of the primary configuration files > > of a Linux system's DNS client software, part of glibc. The > > 'resolver library' in glibc uses as its sources of DNS resolution > > information the IP addresses in those 'nameserver nnn.nnn.nnn.nnn' > > lines. The resolver tries each one in turn, starting with the top > > line and moving down, until it finds the first one that answers DNS > > questions. > > > > Anyhow, it can be vital to know _what_ server is answering (well or > > otherwise) your system's DNS questions by default. Looking at > > /etc/resolv.cofn should answer that question. > > > > > I don't have anything in /etc/resolvconf except an avahi-daemon in > /update-libc.d/ Maybe I should start by putting 8.8.8.8 in > /etc/resolvconf? That's what I'd do, assuming you don't have your own resolver (like unbound) on your computer or a computer on your LAN. And then I'd do the following: chattr +i /etc/resolv.conf Doing that prevents wicd or anyone else from modifying your /etc/resolv.conf. Rick has a less sledgehammer way of preventing wicd messing at http://linuxmafia.com/kb/Network_Other/resolvconf.html , but I just weld it shut with the chattr command. > > And OT do I even need avahi installed at all? I don't have ahavi, and am not seeming to be suffering from it. You know who the author of ahavi is, don't you? SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] dig vs nslookup: was Weird network issue - slow to resolve IPs
For ASCII, both dig and nslookup belong to the dnsutils package, which also offers nsupdate (which seems like some other useful dns utility :) and nothing else. Ralph. Steve Litt wrote on 17/10/18 15:58: > On Sat, 13 Oct 2018 23:52:34 -0700 > Rick Moen wrote: > > Rick's first word of the following paragraph refers to the dig > program... > >> It's the most versatile and reliable tool around for testing DNS >> functionality -- which in turn is useful to be able to test separately >> from the separate task of actually making connections for services >> after resolving DNS names to find where to reach them. > > What's your opinion of nslookup as an alternative to dig? Not sure, but > I think you need to install bind to get dig, and not everyone wants to > install bind. > > Thanks, > > SteveT > > Steve Litt > September 2018 featured book: Quit Joblessness: Start Your Own Business > http://www.troubleshooters.com/startbiz > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] That part SOLVED. Re: No audio on speakers [Was: Re: Audio woes in Ascii - speakers but no headphones
On 16.10.18 17:51, Erik Christiansen wrote: > On 12.10.18 00:00, Alessandro Selli wrote: > > I'd go for the sledgehammer: > > > > apt-get -y purge pulseaudio > > Sounds good to me. What would one substitute, to provide sound instead? > > "No sound" has today hit me too, after bringing my Devuan ascii/ceres > box up after some weeks in storage. At Multimedia-> Pulseaudio_Volume_Control > it shows Firefox-Audiostream on the playback tab, and "Output Devices" > shows "Built-in Audio Analog Stereo", plus "Port: Speakers". The volume > slider is hard right. But still no sound. :-( > > It all worked before the mobo spent a couple of weeks in the dark. I've > checked the monitor menu to see that it's still set to HDMI, even though > the video obviously was, as that's there. Where there's a GUI, there's a way? It turned out that the selection in "configuration" had spuriously changed while the system was dismantled. > It was never as loud as I'd like, but no sound at all is no use at all. With the Pulseaudio_Volume_Control slid hard right, the sound level is still barely adequate while sitting with one's knees two feet from the monitor. (It's on the coffee table, fortunately.) ISTR that the ASUS monitor is supposed to be able to put out 1.5W, well it sounds more like 150 mW to me. And, yes, the monitor's volume control is set to 100%. Is there any other adjustment in an HDMI connection, which could be cranked up? Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
On Tue, 16 Oct 2018 10:46:29 +0200 Didier Kryn wrote: > Le 16/10/2018 à 07:10, Rick Moen a écrit : > > Quoting goli...@dyne.org (goli...@dyne.org): > > > >> With help from my Devuan friends the connection times have improved > >> significantly. After little poking around and a very interesting > >> talk with my ISP, I decided that the ISP's DNS resolver was > >> contributing significantly to the slow connection times. A > >> suggestion from a Devuan ninja, encouraged me install unbound. > > Ding! Glad that works for you. (And, as other Dng regulars know, > > I am a huge fan of doing exactly that.) > > > > Yes, ISP recursive nameservers are very frequently awful as to > > performance. Also as to security, privacy, and reliability, by the > > way. Which is one of several reasons to try running a recursive DNS > > daemon of your own, on your own side of the pipe, and use that in > > preference to other people's recursive nameservers. > > > > Any reading to recommend about recursive, authoritative or what > else name servers ? Yes, yes, yes, yes, YES! I just got thru updating my unbound doc at http://troubleshooters.com/linux/unbound_nsd/unbound.htm , and added a new glossary. This is very necessary because there are so many contradictory terms for things over the Internet. I'm not saying my glossary is the most accurate resource on the Internet, but I think my glossary probably does the best job of de-contradicting terms people throw around. I spent three weeks writing this glossary. It was one of the toughest docs I ever wrote: Tougher than any one chapter in Samba Unleashed. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
Quoting Simon Hobson (si...@thehobsons.co.uk): > IMO you've demonstrated why such things as DNS-SD and mDNS are a good idea. They might be a good idea, but not on my networks. (I continually find myself making the point on Dng that the quest for universal solutions may be noble in its aims but will never really succeed very well.) > You and I have the skills to go and find the printer's IP address, but we are > not typical users who cannot do that. Well, since you raise that assertion, no, I do _not_ agree. They can do it fairly easily. They just aren't _likely_ to. Steps: 1. Write down the printer make/model. 2. Web-search documentation. 3. Find where in the documentation it says how to make the printer print out or otherwise display its network configuration. Do that. > In much the same way, you (I assume) and I are happy to edit text > files etc to configure our systems, but we are not typical users who > cannot do that. Again, they _can_. They just aren't likely to. E.g., at one point, the Vice-President of Silicon Valley Linux User group asked on a mailing list how to solve a technical problem, and I replied back stating a complete solution using basic command-line tools. He said he wasn't willing to do that, and insisted on a graphical-tool equivalent. I cheerily replied that I had no problem with him imposing that additional requirement, wished him the very best of luck, and moved on to other priorities. Somehow, he found this dissatisfying. I, on the other hand, appreciated him warning me that I was better off lavishing my available time and energy elsewhere, so at least *I* got something out of the encounter. > So it comes down to a) try to kill the chatty discovery protocols and > perpetuate the "geeks vs users" divide Was there a particular part of 'not on _my_ network' that was unclear? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] who is working for who (was Avahi (was Weird network issue))
On 10/16/18 10:37 PM, Rick Moen wrote: Quoting Simon Hobson (si...@thehobsons.co.uk): IMO you've demonstrated why such things as DNS-SD and mDNS are a good idea. They might be a good idea, but not on my networks. (I continually find myself making the point on Dng that the quest for universal solutions may be noble in its aims but will never really succeed very well.) You and I have the skills to go and find the printer's IP address, but we are not typical users who cannot do that. Well, since you raise that assertion, no, I do _not_ agree. They can do it fairly easily. They just aren't _likely_ to. Steps: 1. Write down the printer make/model. 2. Web-search documentation. 3. Find where in the documentation it says how to make the printer print out or otherwise display its network configuration. Do that. In much the same way, you (I assume) and I are happy to edit text files etc to configure our systems, but we are not typical users who cannot do that. Again, they _can_. They just aren't likely to. E.g., at one point, the Vice-President of Silicon Valley Linux User group asked on a mailing list how to solve a technical problem, and I replied back stating a complete solution using basic command-line tools. He said he wasn't willing to do that, and insisted on a graphical-tool equivalent. I cheerily replied that I had no problem with him imposing that additional requirement, wished him the very best of luck, and moved on to other priorities. Somehow, he found this dissatisfying. I, on the other hand, appreciated him warning me that I was better off lavishing my available time and energy elsewhere, so at least *I* got something out of the encounter. So it comes down to a) try to kill the chatty discovery protocols and perpetuate the "geeks vs users" divide Was there a particular part of 'not on _my_ network' that was unclear? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng For real fun, turn on Avahi along with all the pulse audio stuff. Watch your network get flooded with multi-cast audio. Scramble to shut it down as fast as you can. There is a reason the mbone went nowhere. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] dig vs nslookup: was Weird network issue - slow to resolve IPs
Quoting Steve Litt (sl...@troubleshooters.com): > What's your opinion of nslookup as an alternative to dig? Not sure, but > I think you need to install bind to get dig, and not everyone wants to > install bind. 1. No, dig isn't bundled with BIND9 _in Linux distros_ (or in other *ixes), all of which build it standalone from parts of the ISC BIND9 sources. 2. It's complicated. For quite a long time, nslookup was officially deprecated because it gave provably wrong results in some use cases, and because it relied on a chunk of very buggy spaghetti code carried forward from the old BIND4 codebase. This was covered in, among other places a Paul Vixie interview (http://linuxmafia.com/faq/Network_Other/dig-nslookup.html). DJB had a page about this (circa end of the 1990s) that I kept referring people to: https://cr.yp.to/djbdns/nslookup.html Then, in 2017, ISC suddenly removed the notations declaring that nslookup was deprecated and that people should be learning to use dig & host. Specifically, this was in the release notes for BIND 9.9.0a3: 1700. [func] nslookup is no longer to be treated as deprecated. Remove "deprecated" warning message. Add man page. I never got the full story about what exactly happened. Perhaps someone at ISC found the time and interest to rewrite nslookup's internals to fix its lingering problems. In any event, having moved on from nslookup to dig about two decades ago, I seriously no longer care. Even back then when it was a pain in the tochis to learn a repalcement networking tool, I could see that 'dig' was a generally better, more flexible, more functional tool with more script-parseable output, so I really don't care if nslookup has been improved from unacceptable to tolerable. To my knowledge, the main reason nslookup persists is that it, and not dig/host, is bundled by default with MS-Windows. All other commonly available OSes (and most particularly any *ix including OSX) long ago replaced it with 'dig'. For any MS-Windows-using friends, this page explains step-by-step how to retrofit .EXE-binary copies of dig / host / whois: https://www.mowasay.com/2017/10/r-i-p-nslookup-start-using-dig-or-host/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Quoting Steve Litt (sl...@troubleshooters.com): > I just got thru updating my unbound doc at > http://troubleshooters.com/linux/unbound_nsd/unbound.htm , and added a > new glossary. This is very necessary because there are so many > contradictory terms for things over the Internet. I'm not saying my > glossary is the most accurate resource on the Internet, but I think my > glossary probably does the best job of de-contradicting terms people > throw around. I spent three weeks writing this glossary. It was one of > the toughest docs I ever wrote: Tougher than any one chapter in Samba > Unleashed. I sympathise with you needing to do all of that painstaking work, Steve. In the glossary, you take particular pains to declare bogus for purposes of your guide the phrase 'iterative server' and similar. But I cannot recall seeing that phrase, so I'm unclear on why you needed to say that. In my 'Village of LAN' piece, I speak in one of the examples about 'a nameserver offering iterative service only', and in several other places use the subphrase 'iterative service' -- clarified elsewhere in the piece in contrast to recursive service. But it would not have occurred to me to use the odd phrase 'iterative server'. It's not the _server_ that iterates, but rather the query, for lack of ability to send back an answer properly with the RA = Recursion Available bit set when sent a query with the RD = Recursion Desired bit set. My point is, you seem to be walking the long way around a pothole that wasn't actually there to fall into. IMO. Although I don't share your desire to use the word 'resolver' in the way your document does -- because in context it ends up creating too much confusion -- you're of course correct that that usage is observed in DNS discussion. And that reflects, as you say, there being too many decades of sloppy and gradually changing terminology. I don't _think_ that problem's as bad as you suggest, but it's definitely present. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] dig vs nslookup: was Weird network issue - slow to resolve IPs
> On 17 Oct 2018, at 15:58, Steve Litt wrote: > > What's your opinion of nslookup as an alternative to dig? Not sure, but > I think you need to install bind to get dig, and not everyone wants to > install bind. Since looking at Unbound and NSD, I’ve been trying out drill as an alternative developed by the same NLnet people. https://www.nlnetlabs.nl/projects/ldns/about/ Install via the ldnsutils package. —Tom___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
