Re: [DNG] Weird network issue - slow to resolve IPs
On 13-10-18 00:26, Rick Moen wrote: > Quoting goli...@dyne.org (goli...@dyne.org): > >>> Disabling IPv6 can be done with adding in /etc/sysctl.conf: >>> >>> net.ipv6.conf.all.disable_ipv6 = 1 >>> >>> and executing sysctl -p or reboot >>> >>> Grtz. >>> >>> Nick >>> >>> >> Thanks Nick. Much appreciated. Will sort that later and report back. > Well, might make it really difficult to use transport to a IPv6 VPS, > that way. True. But the question was how to disable IPv6 because some serverside voodoo should do IPv4. Does it not sort out then it is easily restored by changing the 1 into 0. Which i indeed should have added in my first reaction. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
Arguing about the subjectivity inherent in interpretation, to defend the use of words, that are either too strong, or plainly meant to insult making manipulation of victims easier to achieve. This is dishonesty of the highest rank. So, someone has the ability to plan, write and debug software that is often tens of thousands of lines of code, and, at the same time, is dumb to be intellectually incapable of identifying words, that may be easily misunderstood or taken as an insult. No matter how many times lies are repeated, repetition will not turn them into the truth. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On Thu, 11 Oct 2018 23:23:38 -0700 Rick Moen wrote: > Part > of the point I wanted to make, here (bearing in mind that I'm > speaking only my own view), is that Devuan needs to be mindful of > priorities and has necessarily limited volunteer effort. For better > or worse, _if_ I understand correctly, for now Devuan's primary > delivery target for current and future releases involves SysVInit. > > As it hapens, I personally share your liking for OpenRC over SysVInit, > and respect runit based on readings but haven't experimented with it > as Steve Litt has. But my point is that, if I guess correctly, in the > short term there may not be enough time/effort available to build in > fully packaged, optimally architected implementations of those two > init systems. Speaking for both runit and s6, packaging isn't all that necessary. A document would suffice. Runit's not a huge monster like sysvinit (or a massively entangled monolith like systemd). And in my opinion, the capability of initting with multiple inits is s *good* thing. > > The other immediate thought I had, and I'll just throw this out as a > slightly rhetorical question: Is it so bad to retain the PID1-process > fragment of SysVinit, e.g., as what runs the OpenRC init system? > Seems to me, it's the part of SysVinit nobody has any significant > problem with. It's not unreasonably complex, it's not notably buggy, > and it's certainly not overfeatured. Yes. First of all, you need sysvinit or something like it to be OpenRC's PID1, so yeah, install sysvinit just to init via OpenRC: That's how OpenRC is designed to be used, and /etc/inittab is OpenRC's way of doing respawns (unless OpenRC has recently acquired powers I don't know about). Second, it's quite a bit easier to run runit as a non-init supervisor, using sysvinit's PID1. All you do when you want sane supervision is: 1) Permanently disable the service from /etc/rc.d/init.d 2) Obtain a runit run script (from Void Linux?) 3) Spin up the service in runit: Mainly just install a symlink. The three preceding work equally well for s6, although I know of no distro defaulting to s6 so somebody has to write the run scripts. None of what we're talking about involves changes to current packaging, so we can respect the priorities Rick discussed. > > I note with interest and appreciation your suggestions about how runit > might be provided in better built packaging, but will leave it to > others (such as my friend Steve Litt) to comment. Daniel's wording > about a way to extend these ideals into a framework for other init > systems is particularly cheering, so thanks for posting that. My understanding is that the current Debian runit package is sufficient to use runit as a non-initting, non-PID1 *supervisor*. If this is true, why not run it (no pun intended) that way? We'd need a document stating best practices in turning off the daemon from /etc/rc.d/init.d, and we'd need to grab the run script from Void and make sure it works. Everyone knows I don't like sysvinit, because of the monstrous init scripts. But if supervision is done by runit, s6 or daemontools-encore, my entire objection goes away, because the sysvinit scripts aren't used. There's nothing wrong with the PID1 part of sysvinit. 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] OpenRC and Runit without SysVinit packages
On Fri, 12 Oct 2018 10:56:26 +0200 KatolaZ wrote: > On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote: > > On a related note, I think the best way of acquiring runit run > > files is to install Void Linux on a VM, install all the various > > daemons, and then view the run files in /etc/sv/$daemonname/run. > > > > Void has had enough time supporting runit that most of their run > > files work great. The exceptions usually assume device names that > > shouldn't be assumed. > > > > Devuan could thus acquire a whole bunch of run scripts and not have > > to beg the upstreams to do it. > > > > The main problem remains how to distribute those scripts, without > having to fork all the packages that provide a runit script and don't > have one in the corresponding Debian package. Who needs packages? Just have all the scripts on a website somewhere, downloadable. Anybody wanting to use runit just installs the runscript and makes the symlink. A simple document would tell them how. It's easier than package handling. [snip] > Also, we are not just talking of supporting either openrc or runit, > but to add support for runit *on top* of sysvinit and openrc. Yes! As a matter of fact, a good intermediate goal would be runit used only as a supervisor, on top of sysvinit or on top of sysvinit plus OpenRC. As such, it would stand alone as a tiny "do one thing and do it right" process. > We should definitely find a way through, but I can't see the optimal > one at the moment :\ I think we should start by enabling runit (and perhaps s6) as a supervisor only. We could curate runit run scripts mostly from Void Linux, and make documents on how to switch supervision of a process from /etc/rc.d/init.d to runit. When lots of people find out how easy and wonderful it is, the next step will reveal itself. 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] OpenRC and Runit without SysVinit packages
On Fri, 12 Oct 2018 09:44:14 -0400 Hendrik Boom wrote: > And while we're at it, we want not to support systemd. > But living with inert systemd scripts is at least tolerable. Huh? U mean systemd unit files? > Ideally there should be some systematic solution for all of this, > leaving the choices to the sysadmin, but I don't see it as easy. I think the sysadmin choice, if he wants systemd, is to quit Devuan and go to Debian. If we try to support systemd just a little, we start down a path which will be difficult to travel and even more difficult to back out of. 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 Fri, 12 Oct 2018 14:21:19 -0500 goli...@dyne.org wrote: > Greetings everyone, > > Something funny is going on with my networking. It's taking a very > long time to resolve host IPs across all browsers. It's been > happening for a week or two but I'm just now getting annoyed enough > to troubleshoot. Me too. I just noticed it about a month ago when I installed my own Unbound resolver instead of just sending all queries to 8.8.8.8. Somebody later in this thread mentions that you shouldn't judge resolution time by what the browser says. A few tests with dig and nslookup tell me that with most domains I've never hit before (or which have expired since I hit them), resolution usually takes less than a second. In my case, I'm temporarily assuming that before installing my own resolver I never noticed how much of slow browser loading was due to browser's inefficient dns operations. 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] OpenRC and Runit without SysVinit packages
On Sat, Oct 13, 2018 at 09:55:46AM -0400, Steve Litt wrote: > On Fri, 12 Oct 2018 09:44:14 -0400 > Hendrik Boom wrote: > > > > And while we're at it, we want not to support systemd. > > But living with inert systemd scripts is at least tolerable. > > Huh? U mean systemd unit files? yes. > > > Ideally there should be some systematic solution for all of this, > > leaving the choices to the sysadmin, but I don't see it as easy. > > I think the sysadmin choice, if he wants systemd, is to quit Devuan > and go to Debian. If we try to support systemd just a little, we start > down a path which will be difficult to travel and even more difficult > to back out of. Correct. We do not have the resources, and Debian, who might, isn't interested. It would be pleasant to quiet those who chant "Nyaa Nyaa Devuan isn't really about choice", but it's not worth the price we'd have to pay. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On 10/12/2018 01:56 AM, KatolaZ wrote: On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote: On Fri, 12 Oct 2018 03:24:44 + alecfeld...@disroot.org wrote: 1. Split the runit package into separate packages with alternate stage files. 2. Provide a configuration file for how runit should act. For instance, if openrc or sysvinit is installed, runit can depend on /etc/init.d and /etc/rc*.d scripts for booting. On a related note, I think the best way of acquiring runit run files is to install Void Linux on a VM, install all the various daemons, and then view the run files in /etc/sv/$daemonname/run. Void has had enough time supporting runit that most of their run files work great. The exceptions usually assume device names that shouldn't be assumed. Devuan could thus acquire a whole bunch of run scripts and not have to beg the upstreams to do it. The main problem remains how to distribute those scripts, without having to fork all the packages that provide a runit script and don't have one in the corresponding Debian package. Any concrete proposal is welcome there (but I know that most of the simple ones won't work, since people willing to use runit want their preferred service to work ootb and already have runit scripts, and only when they install that specific server...). Also, we are not just talking of supporting either openrc or runit, but to add support for runit *on top* of sysvinit and openrc. We should definitely find a way through, but I can't see the optimal one at the moment :\ My2Cents KatolaZ Why not a meta-package including all packages for each init? -- Jimmy Johnson Slackware64 14.2 - KDE 4.14.32 - AMD A8-7600 - EXT4 at sda9 Registered Linux User #380263 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
Man you guys have no idea how some of these SJW's operate and how much trumps election really brought out the evil on both sides. After the election I was yelled at and physically attacked at many times by them because I "look like a trump supporter"[1], the news media blamed poor white people for him getting elected[2] and the new money white commie kids lapped it up and went around in groups looking for people to harass and attack in my city. The road to hell is paved with good intentions and as someone who grew up poor I have been fucked over many times by "helpful" policies these people dreamed up. These rules only apply to some people not all - they are always bent to the advantage of whoever is in charge at the moment. [1]I don't even like him but they still hate me because I was not enthusiastic about hillary. [2]You can't win an election with the support of just one electoral block - the only people I know who wouldn't shut up about how great he is are hispanic. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [FULLSTOP!] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
Please stop this stupidity. This is a technical discussion list. Not a political/therapy session. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
Hi, El 07/10/18 a las 17:15, aitor_czr escribió: I've just started it: https://dev1galaxy.org/viewtopic.php?pid=12177#p12177 HTH, Aitor. I finished it: https://dev1galaxy.org/viewtopic.php?id=2405 Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On 13/10/18 at 16:31, Hendrik Boom wrote:
> On Sat, Oct 13, 2018 at 09:55:46AM -0400, Steve Litt wrote:
>> On Fri, 12 Oct 2018 09:44:14 -0400
>> Hendrik Boom wrote:
>>
>>
>>> And while we're at it, we want not to support systemd.
>>> But living with inert systemd scripts is at least tolerable.
>> Huh? U mean systemd unit files?
> yes.
Again: systemd's unit files are *not* scripts! Compare them with real
scripts:
~]$ /lib/systemd/system/zebra.service status
-bash: /lib/systemd/system/zebra.service: Permission denied
~]$ file /lib/systemd/system/zebra.service
/lib/systemd/system/zebra.service: ASCII text
~]$
~]$/etc/init.d/tinc status
Usage: /etc/init.d/tinc {start|stop|reload|restart|force-reload|alarm}
~]$ file /etc/init.d/tinc
/etc/init.d/tinc: POSIX shell script, ASCII text executable
~]$
Are new a newbie to GNU/Linux?
--
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] OpenRC and Runit without SysVinit packages
On Sat, 13 Oct 2018 10:31:33 -0400 Hendrik Boom wrote: > It would be pleasant to quiet those who chant "Nyaa Nyaa Devuan isn't > really about choice", but it's not worth the price we'd have to pay. Most anti-Devuan people are brainless, so if we were to (crazily) incorporate some systemd in Devuan, they'd invent another chant. My opinion is that as long as we keep supplying a sans-systemd OS, we fulfill our mission, and people with brains understand that. 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] What's the latest stable version?
Hi all, What's the latest stable version of Devuan? I'm going to set up a test VM to test runit on Devuan. 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] What's the latest stable version?
On Saturday 13 October 2018 at 21:49:30, Steve Litt wrote: > Hi all, > > What's the latest stable version of Devuan? I'm going to set up a test > VM to test runit on Devuan. "Devuan’s stable release is now 2.0.0 ASCII." https://devuan.org/ I'm surprised to see *you* ask a question like this, Steve... Antony. -- Please apologise my errors, since I have a very small device. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What's the latest stable version?
On Sat, 13 Oct 2018 22:01:34 +0200 Antony Stone wrote: > On Saturday 13 October 2018 at 21:49:30, Steve Litt wrote: > > > Hi all, > > > > What's the latest stable version of Devuan? I'm going to set up a > > test VM to test runit on Devuan. > > "Devuan’s stable release is now 2.0.0 ASCII." > > https://devuan.org/ > > I'm surprised to see *you* ask a question like this, Steve... Thanks! I'm downloading it now. 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 2018-10-13 09:05, Steve Litt wrote: On Fri, 12 Oct 2018 14:21:19 -0500 goli...@dyne.org wrote: Greetings everyone, Something funny is going on with my networking. It's taking a very long time to resolve host IPs across all browsers. It's been happening for a week or two but I'm just now getting annoyed enough to troubleshoot. Me too. I just noticed it about a month ago when I installed my own Unbound resolver instead of just sending all queries to 8.8.8.8. Somebody later in this thread mentions that you shouldn't judge resolution time by what the browser says. A few tests with dig and nslookup tell me that with most domains I've never hit before (or which have expired since I hit them), resolution usually takes less than a second. In my case, I'm temporarily assuming that before installing my own resolver I never noticed how much of slow browser loading was due to browser's inefficient dns operations. SteveT I have some food for thought to share but first an update. A technician came out today to check the line and setup. Line was clear and strong. Switched the modem and now getting 256 down. But . . . internet is still very slow to connect as verified by several of you. Once it gets to where it's going, it is really fast. So here's my conclusion . . . I think we are finally seeing the effects of the demise of Net Neutrality. Corporations are raking in a lot of money streaming videos to every imaginable device and the tech sites that I/we frequent are a low priority. So we are being bumped to the slow lane. Aaron Swartz and others saw this coming and it has finally arrived. Will be interesting to see just how bad it's going to get . . . HND golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
On Sat, 13 Oct 2018 19:59:29 +0200, aitor_czr wrote in message <2c806b56-0b9a-59ee-099a-fb629c520...@gnuinos.org>: > Hi, > > El 07/10/18 a las 17:15, aitor_czr escribió: > > I've just started it: > > > > https://dev1galaxy.org/viewtopic.php?pid=12177#p12177 > > > > HTH, > > > > Aitor. > > I finished it: > > https://dev1galaxy.org/viewtopic.php?id=2405 ..typo in your script: #!/bin/sh rm -rf conf #..I'd say "rm -rfv conf" etc to ease troubleshooting. rm -rf db rm -rf dists rm -rf pool mkdir confl #..typo, you meant "mkdir conf", I'd say "mkdir -vp conf" # etc to ease troubleshooting. Unless you launch a dozen # distros a day, this is not going to be run often, so # you wanna keep your repo setup scripts verbose and easy # to troubleshoot and maintain. echo \ "Origin: Devuan ..why the 2 different web servers??? One of them should do, and I'd say the proper way to number them, would be "1A." and "1B.", rather than "1." and "2." for apache and nginx. If one of them is much easier or significantly better etc than the other, then the best one should be numbered "1." just like you did, and the other(s) should be thrown into an "alternative webserver setups" section in an appendix. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ 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 Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote: > On 2018-10-13 09:05, Steve Litt wrote: > > On Fri, 12 Oct 2018 14:21:19 -0500 > > goli...@dyne.org wrote: > > > > > Greetings everyone, > > > > > > Something funny is going on with my networking. It's taking a very > > > long time to resolve host IPs across all browsers. It's been > > > happening for a week or two but I'm just now getting annoyed enough > > > to troubleshoot. > > > > Me too. I just noticed it about a month ago when I installed my own > > Unbound resolver instead of just sending all queries to 8.8.8.8. > > > > Somebody later in this thread mentions that you shouldn't judge > > resolution time by what the browser says. A few tests with dig and > > nslookup tell me that with most domains I've never hit before (or which > > have expired since I hit them), resolution usually takes less than a > > second. > > > > In my case, I'm temporarily assuming that before installing my own > > resolver I never noticed how much of slow browser loading was due to > > browser's inefficient dns operations. > > > > SteveT > > > > I have some food for thought to share but first an update. A technician > came out today to check the line and setup. Line was clear and strong. > Switched the modem and now getting 256 down. But . . . internet is still > very slow to connect as verified by several of you. Once it gets to where > it's going, it is really fast. So here's my conclusion . . . > > I think we are finally seeing the effects of the demise of Net Neutrality. > Corporations are raking in a lot of money streaming videos to every > imaginable device and the tech sites that I/we frequent are a low priority. > So we are being bumped to the slow lane. Aaron Swartz and others saw this > coming and it has finally arrived. Will be interesting to see just how bad > it's going to get . . . Have you tried timing connection time to sites that likely *are* in the fast lane? Do we eveen now what they are? -- hendrik > > HND > > golinux > > > > ___ > 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
Re: [DNG] Weird network issue - slow to resolve IPs
On 2018-10-13 20:59, Hendrik Boom wrote: On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote: On 2018-10-13 09:05, Steve Litt wrote: > On Fri, 12 Oct 2018 14:21:19 -0500 > goli...@dyne.org wrote: > > > Greetings everyone, > > > > Something funny is going on with my networking. It's taking a very > > long time to resolve host IPs across all browsers. It's been > > happening for a week or two but I'm just now getting annoyed enough > > to troubleshoot. > > Me too. I just noticed it about a month ago when I installed my own > Unbound resolver instead of just sending all queries to 8.8.8.8. > > Somebody later in this thread mentions that you shouldn't judge > resolution time by what the browser says. A few tests with dig and > nslookup tell me that with most domains I've never hit before (or which > have expired since I hit them), resolution usually takes less than a > second. > > In my case, I'm temporarily assuming that before installing my own > resolver I never noticed how much of slow browser loading was due to > browser's inefficient dns operations. > > SteveT > I have some food for thought to share but first an update. A technician came out today to check the line and setup. Line was clear and strong. Switched the modem and now getting 256 down. But . . . internet is still very slow to connect as verified by several of you. Once it gets to where it's going, it is really fast. So here's my conclusion . . . I think we are finally seeing the effects of the demise of Net Neutrality. Corporations are raking in a lot of money streaming videos to every imaginable device and the tech sites that I/we frequent are a low priority. So we are being bumped to the slow lane. Aaron Swartz and others saw this coming and it has finally arrived. Will be interesting to see just how bad it's going to get . . . Have you tried timing connection time to sites that likely *are* in the fast lane? Do we even now what they are? -- hendrik Well, I picked a few names at random. netflix pops up as soon as I hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram, reddit, snapchat and facebook. Redhat is in a slower lane as is the Linux Foundation. Even Ubuntu takes a while. But I don't get out much so maybe some of you know some popular destinations that I missed. It is incredibly annoying to be connected to a rather fast pipe yet have to travel on what feels like 56k connection to get to where I can benefit from it. golinux ___ 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 2018年10月14日 10:59:54 JST, Hendrik Boom wrote: >On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote: >> On 2018-10-13 09:05, Steve Litt wrote: >> > On Fri, 12 Oct 2018 14:21:19 -0500 >> > goli...@dyne.org wrote: >> > >> > > Greetings everyone, >> > > >> > > Something funny is going on with my networking. It's taking a >very >> > > long time to resolve host IPs across all browsers. It's been >> > > happening for a week or two but I'm just now getting annoyed >enough >> > > to troubleshoot. >> > >> > Me too. I just noticed it about a month ago when I installed my own >> > Unbound resolver instead of just sending all queries to 8.8.8.8. >> > >> > Somebody later in this thread mentions that you shouldn't judge >> > resolution time by what the browser says. A few tests with dig and >> > nslookup tell me that with most domains I've never hit before (or >which >> > have expired since I hit them), resolution usually takes less than >a >> > second. >> > >> > In my case, I'm temporarily assuming that before installing my own >> > resolver I never noticed how much of slow browser loading was due >to >> > browser's inefficient dns operations. >> > >> > SteveT >> > >> >> I have some food for thought to share but first an update. A >technician >> came out today to check the line and setup. Line was clear and >strong. >> Switched the modem and now getting 256 down. But . . . internet is >still >> very slow to connect as verified by several of you. Once it gets to >where >> it's going, it is really fast. So here's my conclusion . . . >> >> I think we are finally seeing the effects of the demise of Net >Neutrality. >> Corporations are raking in a lot of money streaming videos to every >> imaginable device and the tech sites that I/we frequent are a low >priority. >> So we are being bumped to the slow lane. Aaron Swartz and others saw >this >> coming and it has finally arrived. Will be interesting to see just >how bad >> it's going to get . . . > >Have you tried timing connection time to sites that likely *are* in the > >fast lane? Do we eveen now what they are? > >-- hendrik > >> >> HND >> >> golinux >> >> >> hi, a fast way if u re living in the EU would be to try a european site as net neutrality is still en vigueur there. if same phenomen there(net slow), then it s definitely smtg else. But personally i would try more troubleshooting first like : - ping all the gateways u found on ur traceroute results(starting w/ the nearest ur terminal) - try some options to traceroute or ping to get an answer even from the gateways that dont answer to icmp, like sending tcp or udp packets. hth ___ 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 2018-10-13 22:22, mett wrote: On 2018年10月14日 10:59:54 JST, Hendrik Boom wrote: On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote: On 2018-10-13 09:05, Steve Litt wrote: > On Fri, 12 Oct 2018 14:21:19 -0500 > goli...@dyne.org wrote: > > > Greetings everyone, > > > > Something funny is going on with my networking. It's taking a very > > long time to resolve host IPs across all browsers. It's been > > happening for a week or two but I'm just now getting annoyed enough > > to troubleshoot. > > Me too. I just noticed it about a month ago when I installed my own > Unbound resolver instead of just sending all queries to 8.8.8.8. > > Somebody later in this thread mentions that you shouldn't judge > resolution time by what the browser says. A few tests with dig and > nslookup tell me that with most domains I've never hit before (or which > have expired since I hit them), resolution usually takes less than a > second. > > In my case, I'm temporarily assuming that before installing my own > resolver I never noticed how much of slow browser loading was due to > browser's inefficient dns operations. > > SteveT > I have some food for thought to share but first an update. A technician came out today to check the line and setup. Line was clear and strong. Switched the modem and now getting 256 down. But . . . internet is still very slow to connect as verified by several of you. Once it gets to where it's going, it is really fast. So here's my conclusion . . . I think we are finally seeing the effects of the demise of Net Neutrality. Corporations are raking in a lot of money streaming videos to every imaginable device and the tech sites that I/we frequent are a low priority. So we are being bumped to the slow lane. Aaron Swartz and others saw this coming and it has finally arrived. Will be interesting to see just how bad it's going to get . . . Have you tried timing connection time to sites that likely *are* in the fast lane? Do we even now what they are? -- hendrik HND golinux hi, a fast way if u re living in the EU would be to try a european site as net neutrality is still en vigueur there. if same phenomen there(net slow), then it s definitely smtg else. But personally i would try more troubleshooting first like : - ping all the gateways u found on ur traceroute results(starting w/ the nearest ur terminal) - try some options to traceroute or ping to get an answer even from the gateways that dont answer to icmp, like sending tcp or udp packets. hth ___ Alas, I am in the belly of the beast of darkness. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What's the latest stable version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 14/10/18 07:01, Antony Stone wrote: > On Saturday 13 October 2018 at 21:49:30, Steve Litt wrote: >> What's the latest stable version of Devuan? I'm going to set up a >> test VM to test runit on Devuan. > > "Devuan’s stable release is now 2.0.0 ASCII." > > https://devuan.org/ > > I'm surprised to see *you* ask a question like this, Steve... Well there is a different answer to that. Sometimes stable is testing that has been testing long enough and is perhaps close enough to freezing that it is considered stable. ;-) Cheers A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8LfgQAKCRCoFmvLt+/i +9q3AQCtXjvfBzvjiyc4IB2dM+Tzu6artBw6Nh2/sU0+D3BstwD7Bj8gauCQZLvL o5yjI2QDuZOZ9Xh/AWMA+g8F+tsDl6Y= =IBkg -END PGP SIGNATURE- ___ 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
Quoting goli...@dyne.org (goli...@dyne.org): > Well, I picked a few names at random. netflix pops up as soon as I > hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram, > reddit, snapchat and facebook. Redhat is in a slower lane as is the > Linux Foundation. Even Ubuntu takes a while. But I don't get out > much so maybe some of you know some popular destinations that I > missed. I assume you mean using a Web browser. I would suggest starting your checks using 'dig'. But first, a brief interlude about _where_ your nameservice is coming from: If you look in /etc/resolv.conf, you'll see one or more 'nameserver' lines. Mine on my server is like this: $ cat /etc/resolv.conf search linuxmafia.com deirdre.org unixmercenary.net nameserver 127.0.0.1 nameserver 198.144.192.2 nameserver 198.144.192.4 #nameserver 198.144.195.186 $ (If you are getting your IP address using DHCP, you are extremely likely to be getting passed nameserver IP addresses with your IP address lease, resulting in the DHCP client software overwriting /etc/resolv.conf with, among other things, 'nameserver nnn.nnn.nnn.nnn' information. 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. In the case of _my_ /etc/resolv.conf, notice that the first address is the localhost IP addres, 127.0.0.1, which means 'resolve DNS questions locally'. This is because my server runs its own recursive nameserver daemon. Your first 'nameserver nnn.nnn.nnn.nnn' line will surely not be that, and will probably be an ISP-operated recursive nameserver reachable on the far end of your house's uplink. Following me so far? Now, we'll turn to basic use of 'dig'. The optional '@' parameter is where you can put which nameserver (specified by either fully qualified domain name = FQDN or IP address) this query should be sent to. In the example below, we will direct a query to out of the Google Public DNS recursive nameservers that Google offers for public benefit. $ dig ns1.linuxmafia.com @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55874 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: ns1.linuxmafia.com. 21599 IN A 198.144.195.186 $ 'dig' is using the default UDP-type datagram transport, and it got answer '198.144.195.186'. You can test exactly how long the question and answer cycle took by using the 'time' command as a wrapper: $ time dig ns1.linuxmafia.com @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: ns1.linuxmafia.com. 21519 IN A 198.144.195.186 real0m0.092s user0m0.008s sys 0m0.012s $ 'dig' can be badgered into using specifically TCP (instead of UDP) transport using a flag (+tcp) to that effect, or it can be told to use speciflcally only IPv4 or specifically only IPv6 using options to that effect (-4 and -6). 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. I hope that helps. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
