Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268027 > unrolled thread

electrons/the Internet doesn't like question authority niggahs?, or is it that I like to eat raw garlic, ...

Back to article view | Back to linux.debian.user

Contents

  electrons/the Internet doesn't like question authority niggahs?, or  is it that I like to eat raw garlic, ... Albretch Mueller <lbrtchx@gmail.com> - 2024-03-04 17:40 +0100
    Re: electrons/the Internet doesn't like question authority niggahs?,  or is it that I like to eat raw garlic, ... Andy Smith <andy@strugglers.net> - 2024-03-04 18:00 +0100
      Re: electrons/the Internet doesn't like question authority niggahs?,  or is it that I like to eat raw garlic, ... Albretch Mueller <lbrtchx@gmail.com> - 2024-03-05 01:40 +0100
    Re: electrons/the Internet [...] <tomas@tuxteam.de> - 2024-03-04 18:00 +0100
    Re: electrons/the Internet doesn't like question authority niggahs?,  or is it that I like to eat raw garlic, ... David Christensen <dpchrist@holgerdanske.com> - 2024-03-04 21:40 +0100
      resolv.conf (was Re: electrons/the Internet [racism redacted]) Greg Wooledge <greg@wooledge.org> - 2024-03-04 22:20 +0100
        Re: resolv.conf (was Re: electrons/the Internet [racism redacted]) Jeffrey Walton <noloader@gmail.com> - 2024-03-04 22:30 +0100
        Re: resolv.conf (was Re: electrons/the Internet [racism redacted]) Markus Schönhaber <debian-user@list-post.mks-mail.de> - 2024-03-04 23:30 +0100
        Re: resolv.conf (was Re: electrons/the Internet [racism redacted]) David Christensen <dpchrist@holgerdanske.com> - 2024-03-05 00:50 +0100
      Re: electrons/the Internet doesn't like … that I like to eat raw garlic, ... David Wright <deblis@lionunicorn.co.uk> - 2024-03-05 01:10 +0100
        Re: electrons/the Internet doesn't like … that I like to eat raw garlic, ... David Christensen <dpchrist@holgerdanske.com> - 2024-03-05 04:10 +0100
    Re: electrons/the Internet doesn't like question authority niggahs?,  oris it that I like to eat raw garlic, ... gene heskett <gheskett@shentel.net> - 2024-03-05 01:50 +0100
      Re: electrons/the Internet doesn't like question authority niggahs?,  oris it that I like to eat raw garlic, ... <tomas@tuxteam.de> - 2024-03-05 06:40 +0100
        Re: electrons/the Internet doesn't like question authority  niggahs?,oris it that I like to eat raw garlic, ... gene heskett <gheskett@shentel.net> - 2024-03-05 09:20 +0100

#268027 — electrons/the Internet doesn't like question authority niggahs?, or is it that I like to eat raw garlic, ...

spend days on end reading, coding and thinking about Math?

As part of turning society/the world as a whole into an "all tangible
things" panopticon they have turned the Internet into a
"freedom-loving" gulag for which they are even using "AI"; so, they
don’t even need to use V-Leute. Those minitrue folks are so smart!

Something that shouldn't be happening at all is that after I use
traceroute once, it doesn't work again and my Internet access speed
describes like a sinus curve which amplitude remains for the most part
under 16KiB per second and for more than one second as 0B per second.

_LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
Entry(1)_20210618043317.pdf"

 1) is the file actually there?:

wget -q --spider "${_LINK}"; _WGETQ=$?
echo "// __ \$_WGETQ: |$_WGETQ|"

echo "// __ $_WGETQ: |0|"

 2) As one of the recommendations I found which might relate to this
problematic:

$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 204 Mar  3 18:59 /etc/resolv.conf
$

$ cat /etc/resolv.conf
# Generated by NetworkManager
# nameserver 192.168.1.254
# nameserver 192.168.68.1

# https://serverfault.com/questions/76421/wget-cant-resolve-host
# RED 2013-03-31
nameserver 8.8.8.8
nameserver 8.8.4.4
$

$ ls -l /etc/nsswitch.conf
-rw-r--r-- 1 root root 613 Mar  3 12:57 /etc/nsswitch.conf
$

$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files
group:          files
shadow:         files
gshadow:        files

#hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

hosts:          files dns mdns4_minimal [NOTFOUND=return] dns myhostname

networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

 3) dig, ping, traceroute and wget log:

$ ls -l christuniversity.in_*.*
-rwxrwxrwx 1 user user  617 Mar  4 05:42
christuniversity.in_20240304112021.846262299_dig.txt
-rwxrwxrwx 1 user user  219 Mar  4 05:42
christuniversity.in_20240304112021.846262299_ping.txt
-rwxrwxrwx 1 user user 1081 Mar  4 05:42
christuniversity.in_20240304112021.846262299_traceroute.txt
-rwxrwxrwx 1 user user  522 Mar  4 05:42
'christuniversity.in_EComp_21-25_Lateral
Entry1_20210618043317_20240304112021.846262299_wget.log'
-rwxrwxrwx 1 user user    0 Mar  4 05:20
'christuniversity.in_EComp_21-25_Lateral Entry1_20210618043317.pdf'
$

// __ christuniversity.in_20240304112021.846262299_dig.txt


; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> +time christuniversity.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49715
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;christuniversity.in.		IN	A

;; ANSWER SECTION:
christuniversity.in.	60	IN	A	103.105.225.131
christuniversity.in.	60	IN	A	111.93.136.229

;; Query time: 327 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Mar 04 05:42:58 CST 2024
;; MSG SIZE  rcvd: 80


real	0m0.428s
user	0m0.040s
sys	0m0.046s

// __ christuniversity.in_20240304112021.846262299_ping.txt

PING christuniversity.in (103.105.225.131) 56(84) bytes of data.

--- christuniversity.in ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3080ms


real	0m13.445s
user	0m0.000s
sys	0m0.015s

// __ christuniversity.in_20240304112021.846262299_traceroute.txt

traceroute to christuniversity.in (111.93.136.229), 30 hops max, 60 byte packets
 1  _gateway (192.168.68.1)  16.964 ms  15.714 ms  17.508 ms
 2  * 192.168.1.254 (192.168.1.254)  18.381 ms *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  ix-be-39.ecore1.ct8-chicago.as6453.net (66.198.27.4)  64.819 ms
64.547 ms  64.685 ms
10  if-ae-44-2.tcore1.ct8-chicago.as6453.net (63.243.129.56)  80.053
ms  81.180 ms  85.409 ms
11  if-ae-26-2.tcore3.nto-newyork.as6453.net (216.6.81.28)  86.478 ms
*  81.806 ms
12  if-ae-34-14.tcore4.njy-newark.as6453.net (66.198.111.26)  81.795
ms if-ae-34-15.tcore4.njy-newark.as6453.net (66.198.111.58)  84.297 ms
 82.801 ms
13  if-ae-1-3.tcore3.njy-newark.as6453.net (216.6.57.5)  97.965 ms
88.660 ms  89.184 ms
14  66.198.70.10 (66.198.70.10)  306.240 ms *  301.191 ms
15  * * *
16  * * *
17  * * *
18  111.93.136.229 (111.93.136.229)  307.868 ms  313.512 ms  306.604 ms
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

real	0m21.725s
user	0m0.016s
sys	0m0.025s

// __'christuniversity.in_EComp_21-25_Lateral
Entry1_20210618043317_20240304112021.846262299_wget.log'

failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
failed: Connection timed out.
// __ [69/691):
https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
Entry(1)_20210618043317.pdf|christuniversity.in_E&Comp_21-25_Lateral
Entry(1)_20210618043317.pdf|

real	22m36.412s
user	0m0.114s
sys	0m0.131s
~
 lbrtchx

[toc] | [next] | [standalone]

#268028 — Re: electrons/the Internet doesn't like question authority niggahs?, or is it that I like to eat raw garlic, ...

Hi,

On Mon, Mar 04, 2024 at 10:37:28AM -0600, Albretch Mueller wrote:
> spend days on end reading, coding and thinking about Math?

Please could you rephrase your entire email to only contain
coherent, direct questions at least tenuously about Debian.

If this results in an empty email, this is an indication that this
mailing list was not the correct place to send it to in the first
place.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#268042 — Re: electrons/the Internet doesn't like question authority niggahs?, or is it that I like to eat raw garlic, ...

On 3/4/24, Andy Smith <andy@strugglers.net> wrote:
> Please could you rephrase your entire email to only contain
> coherent, direct questions at least tenuously about Debian.

 I am downloading one by one a bunch of (relatively small) documents I
need (I work on corpora research) and the critical part of my bash
script looks like:

   wget --no-check-certificate --server-response --no-verbose
--continue --user-agent="${ua}" --keep-session-cookies --execute
robots=off --waitretry=1 --tries=5  --output-document="${opdf}"
--output-file="${log}" "${pdf}"
   if [[ $? -ne 0 ]]; then
    echo "// __ [$_ix/$_lns): ${pdf}|${dmn}_${bn}| *~ download failed"
 >> "${failed_log}" 2>&1
    ping="${odir}/${dmn}_${dt}_ping.txt"; time ( ping -c 4 "${dmn}" >
"${ping}" 2>&1 ) >> "${ping}" 2>&1
    trace="${odir}/${dmn}_${dt}_traceroute.txt"; time( sudo traceroute
--debug --tcp "${dmn}" > "${trace}" 2>&1 ) >> "${trace}" 2>&1
    dig="${odir}/${dmn}_${dt}_dig.txt"; time ( dig +time=5 "${dmn}" >
"${dig}" 2>&1 ) >> "${dig}" 2>&1
   fi

 Most connections attempts are either missed or dropped even though I
am testing first that the data is there. Maybe you know a better way
you would share?
 When I use brave/private/TOR (which apparently uses its own DNS
strategy) things become a lot less problematic (even if noticeably
slower than it already is), so it seems I may have to run brave
through Selenium ...
 I have never been able to see a traceroute log in all its integrity.
I would not go:
 sudo service networking restart
 after every traceroute run, because I am using my employers Internet
and I don't want to risk "electrons" getting even angrier with me.
 lbrtchx

[toc] | [prev] | [next] | [standalone]

#268029 — Re: electrons/the Internet [...]

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 04, 2024 at 10:37:28AM -0600, Albretch Mueller wrote:
> spend days on end reading, coding and thinking about Math?

Sorry. Try again. The whole post doesn't make much sense to
me.

I just tried this:

  curl -LI "https://christuniversity.in/uploads/course/E&Comp_21-25_LateralEntry(1)_20210618043317.pdf"

(the L is because you first get a 302) and the whole thing
says "403 Forbidden", so it may just be you need some kind
of credentials. But hey, as I said, I didn't understand much
of what you are tryig.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268031 — Re: electrons/the Internet doesn't like question authority niggahs?, or is it that I like to eat raw garlic, ...

On 3/4/24 08:37, Albretch Mueller wrote:
> <rant>


Yes, networking problems are infuriating.


> Something that shouldn't be happening at all is that after I use
> traceroute once, it doesn't work again and my Internet access speed
> describes like a sinus curve which amplitude remains for the most part
> under 16KiB per second and for more than one second as 0B per second.
> 
> _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
> Entry(1)_20210618043317.pdf"


I have AT&T Internet service in Tracy, California.


My daily driver is:

2024-03-04 10:47:12 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a
11.9
Linux laalaa 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) 
x86_64 GNU/Linux


When I click the above link in my mail client (Thunderbird), my browser 
(Firefox) attempts to open the URL.  But, the URL is mangled by mail 
client line wrap and/or indentation (?), and the connection times out:

https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral

An error occurred during a connection to christuniversity.in.

     The site could be temporarily unavailable or too busy. Try again in 
a few moments.
     If you are unable to load any pages, check your computer’s network 
connection.
     If your computer or network is protected by a firewall or proxy, 
make sure that Firefox is permitted to access the web.


The following URL's also time out (see DNS comments, below):

http://christuniversity.in/
http://103.105.225.131/
http://111.93.136.229/

https://christuniversity.in/
https://103.105.225.131/
https://111.93.136.229/


>   1) is the file actually there?:
> 
> wget -q --spider "${_LINK}"; _WGETQ=$?


I refrain from spidering web sites -- being blackholed is not good.


> $ ls -l /etc/resolv.conf
> -rw-r--r-- 1 root root 204 Mar  3 18:59 /etc/resolv.conf


2024-03-04 10:50:49 dpchrist@laalaa ~
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 83 Mar  4 09:50 /etc/resolv.conf


> $ cat /etc/resolv.conf
> # Generated by NetworkManager
> # nameserver 192.168.1.254
> # nameserver 192.168.68.1
> 
> # https://serverfault.com/questions/76421/wget-cant-resolve-host
> # RED 2013-03-31
> nameserver 8.8.8.8
> nameserver 8.8.4.4


2024-03-04 10:51:32 dpchrist@laalaa ~
$ cat /etc/resolv.conf
# Generated by NetworkManager
search tracy.holgerdanske.com
nameserver 192.168.5.1


I believe Debian rewrites /etc/resolv.conf on every boot.


Hard coding Google Public DNS servers should work, but letting your 
gateway do it for your LAN is easier to manage, is faster, and conserves 
WAN bandwidth.  I would revert your changes.


And, Google is watching you.


STFW for DNS privacy:

https://avoidthehack.com/best-dns-privacy


I think I will configure my gateway to use Quad9:

https://www.quad9.net/service/locations/


The next level up would be DNS over TLS (DoT), DNS over HTTPS (DoH), 
DNSCrypt, etc.:

https://en.wikipedia.org/wiki/DNS_over_TLS


> $ ls -l /etc/nsswitch.conf
> -rw-r--r-- 1 root root 613 Mar  3 12:57 /etc/nsswitch.conf


2024-03-04 10:52:04 dpchrist@laalaa ~
$ ls -l /etc/nsswitch.conf
-rw-r--r-- 1 root root 542 Jan  9  2022 /etc/nsswitch.conf


> $ cat /etc/nsswitch.conf
> # /etc/nsswitch.conf
> #
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc-reference' and `info' packages installed, try:
> # `info libc "Name Service Switch"' for information about this file.
> 
> passwd:         files
> group:          files
> shadow:         files
> gshadow:        files
> 
> #hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
> 
> hosts:          files dns mdns4_minimal [NOTFOUND=return] dns myhostname
> 
> networks:       files
> 
> protocols:      db files
> services:       db files
> ethers:         db files
> rpc:            db files
> 
> netgroup:       nis


2024-03-04 10:56:37 dpchrist@laalaa ~
$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis


It appears my /etc/nsswitch.conf has not been touched since 
installation.  I would revert your changes.


> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> +time christuniversity.in
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49715
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;christuniversity.in.		IN	A
> 
> ;; ANSWER SECTION:
> christuniversity.in.	60	IN	A	103.105.225.131
> christuniversity.in.	60	IN	A	111.93.136.229
> 
> ;; Query time: 327 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
> ;; WHEN: Mon Mar 04 05:42:58 CST 2024
> ;; MSG SIZE  rcvd: 80


Please post complete console sessions with a useful PS1 to provide 
context, the exact command issued, and the exact output displayed (with 
redactions indicated):

2024-03-04 10:57:52 dpchrist@laalaa ~
$ dig christuniversity.in

; <<>> DiG 9.16.48-Debian <<>> christuniversity.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39687
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;christuniversity.in.		IN	A

;; ANSWER SECTION:
christuniversity.in.	60	IN	A	103.105.225.131
christuniversity.in.	60	IN	A	111.93.136.229

;; Query time: 248 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)
;; WHEN: Mon Mar 04 11:10:24 PST 2024
;; MSG SIZE  rcvd: 80


Note that there are two A records for christuniversity.in.


> PING christuniversity.in (103.105.225.131) 56(84) bytes of data.
> 
> --- christuniversity.in ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3080ms


Your ping went to the first A record IPv4 address.  I get the same result:

2024-03-04 11:41:50 dpchrist@laalaa ~
$ ping -c 3 103.105.225.131
PING 103.105.225.131 (103.105.225.131) 56(84) bytes of data.

--- 103.105.225.131 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2045ms


If I use the FQDN, I can ping the second A record IPv4 address:

2024-03-04 11:10:24 dpchrist@laalaa ~
$ ping -c 3 christuniversity.in
PING christuniversity.in (111.93.136.229) 56(84) bytes of data.
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=1 ttl=49 time=272 ms
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=2 ttl=49 time=272 ms
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=3 ttl=49 time=272 ms

--- christuniversity.in ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 271.856/272.182/272.371/0.231 ms


I suggest trying to ping 111.93.136.229.


> traceroute to christuniversity.in (111.93.136.229), 30 hops max, 60 byte packets
>   1  _gateway (192.168.68.1)  16.964 ms  15.714 ms  17.508 ms
>   2  * 192.168.1.254 (192.168.1.254)  18.381 ms *
>   3  * * *
>   4  * * *
>   5  * * *
>   6  * * *
>   7  * * *
>   8  * * *
>   9  ix-be-39.ecore1.ct8-chicago.as6453.net (66.198.27.4)  64.819 ms
> 64.547 ms  64.685 ms
> 10  if-ae-44-2.tcore1.ct8-chicago.as6453.net (63.243.129.56)  80.053
> ms  81.180 ms  85.409 ms
> 11  if-ae-26-2.tcore3.nto-newyork.as6453.net (216.6.81.28)  86.478 ms
> *  81.806 ms
> 12  if-ae-34-14.tcore4.njy-newark.as6453.net (66.198.111.26)  81.795
> ms if-ae-34-15.tcore4.njy-newark.as6453.net (66.198.111.58)  84.297 ms
>   82.801 ms
> 13  if-ae-1-3.tcore3.njy-newark.as6453.net (216.6.57.5)  97.965 ms
> 88.660 ms  89.184 ms
> 14  66.198.70.10 (66.198.70.10)  306.240 ms *  301.191 ms
> 15  * * *
> 16  * * *
> 17  * * *
> 18  111.93.136.229 (111.93.136.229)  307.868 ms  313.512 ms  306.604 ms
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *


Using the first A record IPv4 address:

2024-03-04 11:42:34 dpchrist@laalaa ~
$ traceroute 103.105.225.131
traceroute to 103.105.225.131 (103.105.225.131), 30 hops max, 60 byte 
packets
  1  ubnttracyholgerdanskecom (192.168.5.1)  0.370 ms  0.520 ms  0.687 ms
  2  attlocal.net (192.168.1.254)  2.763 ms  3.142 ms  3.641 ms
  3  76-201-76-1.lightspeed.frokca.sbcglobal.net (76.201.76.1)  21.651 
ms  22.421 ms  23.062 ms
  4  71.147.234.9 (71.147.234.9)  26.820 ms  30.000 ms  27.644 ms
  5  * * *
  6  * * *
  7  32.130.91.81 (32.130.91.81)  35.002 ms  35.741 ms  36.905 ms
  8  192.205.32.182 (192.205.32.182)  41.690 ms  30.204 ms  27.039 ms
  9  cablewireless-ic-382397.ip.twelve99-cust.net (62.115.46.249) 
27.853 ms  29.772 ms  30.216 ms
10  ae15-xcr1.tyo.cw.net (195.2.20.125)  136.239 ms  137.968 ms  137.056 ms
11  195.2.10.193 (195.2.10.193)  201.657 ms  202.155 ms  205.131 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


Using the FQDN:

2024-03-04 11:14:07 dpchrist@laalaa ~
$ traceroute christuniversity.in
traceroute to christuniversity.in (111.93.136.229), 30 hops max, 60 byte 
packets
  1  ubnttracyholgerdanskecom (192.168.5.1)  0.375 ms  0.522 ms  0.689 ms
  2  attlocal.net (192.168.1.254)  2.925 ms  3.659 ms  4.147 ms
  3  76-201-76-1.lightspeed.frokca.sbcglobal.net (76.201.76.1)  22.249 
ms  23.117 ms  25.102 ms
  4  71.147.234.9 (71.147.234.9)  28.279 ms  29.195 ms  30.719 ms
  5  * * *
  6  * * *
  7  32.130.91.81 (32.130.91.81)  38.078 ms  39.616 ms *
  8  64.86.160.14 (64.86.160.14)  46.002 ms  27.525 ms  26.610 ms
  9  64.86.160.3 (64.86.160.3)  38.830 ms * *
10  * if-ae-20-2.tcore2.sv1-santaclara.as6453.net (66.198.101.132) 
44.654 ms *
11  * * *
12  * * *
13  66.110.59.114 (66.110.59.114)  273.586 ms  274.232 ms  277.765 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


I do not see any meaningful clues in any of the traceroute(8) outputs.


I suspect there could be two root causes -- conflicting DNS A records 
and the web server is down and/or broken by the DNS issue.


Doing a whois lookup, christuniversity.in does not provide contact 
information; only email@publicdomainregistry.com:

https://www.whois.com/whois/christuniversity.in


David

[toc] | [prev] | [next] | [standalone]

#268032 — resolv.conf (was Re: electrons/the Internet [racism redacted])

On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
> I believe Debian rewrites /etc/resolv.conf on every boot.

This is not correct.  It's *partly* correct if you ignore a lot of
complicating factors.

Short version: read <https://wiki.debian.org/resolv.conf>.

Long version follows:

If you have a static network interface configuration, defined in
/etc/network/interfaces, with no DHCP client, no VPN stuff going on,
etc. then your /etc/resolv.conf will not be changed.  You can edit the
file and put whatever you want in it, and it'll remain as you wish it
to be.

Unfortunately, almost *nobody* has a setup like this any more.

In a more typical environment, you get your IP address via DHCP, which
means you're running a DHCP client daemon.  Most DHCP client daemons
will rewrite the /etc/resolv.conf file every time they refresh their
DHCP lease.  This may indeed happen at boot time, but it'll also happen
a couple times a day during normal operations.

So, a simple instruction like "edit /etc/resolv.conf" is no longer
possible.  Even worse, there's no single *alternative* either.  You can't
even say "do ___ instead".

To put the correct values into your /etc/resolv.conf file nowdays, you
have to select a *strategy*.  You need to find an indirect way to put
the right content into some *other* place, in such a way that it will
eventually find its way into /etc/resolv.conf every time the file is
rewritten.  And there are *lots* of strategies that will work, so you
can't even say "obviously this one is best".  Life is not that simple.

Or, you could use chattr +i to make the /etc/resolv.conf file immutable,
so DHCP clients and other programs cannot overwrite it.

Either way, you take ownership of whatever strategy you decide to use,
together with its pros and cons.  You'll have to understand that on *this*
system, you went with *this* strategy, and remember where to put your
changes, and how to make them.  Or at the very least, you'll need to be
*aware* of all the strategies you've got in play on all of your systems,
and know how to identify which one is in use on any given system.

All of this is documented on <https://wiki.debian.org/resolv.conf>
but it's a virtual certainty that nobody in this thread will read that
wiki page and select a strategy and implement it and be happy.  Instead,
we will have another hundred-message argument, in which half the
participants will have no idea what the issue is (but will chime in loudly
anyway), and the second half will simply attack whatever strategies the
third half have selected.

And in another month or two, we'll do it all again.

[toc] | [prev] | [next] | [standalone]

#268033 — Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

On Mon, Mar 4, 2024 at 4:12 PM Greg Wooledge <greg@wooledge.org> wrote:
>
> On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
> > I believe Debian rewrites /etc/resolv.conf on every boot.
>
> This is not correct.  It's *partly* correct if you ignore a lot of
> complicating factors.
> [...]
>
> All of this is documented on <https://wiki.debian.org/resolv.conf>
> but it's a virtual certainty that nobody in this thread will read that
> wiki page and select a strategy and implement it and be happy.  Instead,
> we will have another hundred-message argument, in which half the
> participants will have no idea what the issue is (but will chime in loudly
> anyway), and the second half will simply attack whatever strategies the
> third half have selected.

Lol... so true. The internet never misses an opportunity to argue!

> resolv.conf (was Re: electrons/the Internet [racism redacted])

And I think I hear someone approaching with the Mjölnir hammer.
Someone might be plonked over the head.

Jeff

[toc] | [prev] | [next] | [standalone]

#268035 — Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

04.03.24, 22:11 +0100, Greg Wooledge:

> Instead,
> we will have another hundred-message argument, in which half the
> participants will have no idea what the issue is (but will chime in loudly
> anyway), and the second half will simply attack whatever strategies the
> third half have selected.

You made my day :-)

-- 
Regards
  mks

[toc] | [prev] | [next] | [standalone]

#268037 — Re: resolv.conf (was Re: electrons/the Internet [racism redacted])

On 3/4/24 13:11, Greg Wooledge wrote:
> On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
>> I believe Debian rewrites /etc/resolv.conf on every boot.
> 
> This is not correct.  It's *partly* correct if you ignore a lot of
> complicating factors.
> 
> Short version: read <https://wiki.debian.org/resolv.conf>.
> 
> Long version follows:
> 
> If you have a static network interface configuration, defined in
> /etc/network/interfaces, with no DHCP client, no VPN stuff going on,
> etc. then your /etc/resolv.conf will not be changed.  You can edit the
> file and put whatever you want in it, and it'll remain as you wish it
> to be.
> 
> Unfortunately, almost *nobody* has a setup like this any more.
> 
> In a more typical environment, you get your IP address via DHCP, which
> means you're running a DHCP client daemon.  Most DHCP client daemons
> will rewrite the /etc/resolv.conf file every time they refresh their
> DHCP lease.  This may indeed happen at boot time, but it'll also happen
> a couple times a day during normal operations.
> 
> So, a simple instruction like "edit /etc/resolv.conf" is no longer
> possible.  Even worse, there's no single *alternative* either.  You can't
> even say "do ___ instead".
> 
> To put the correct values into your /etc/resolv.conf file nowdays, you
> have to select a *strategy*.  You need to find an indirect way to put
> the right content into some *other* place, in such a way that it will
> eventually find its way into /etc/resolv.conf every time the file is
> rewritten.  And there are *lots* of strategies that will work, so you
> can't even say "obviously this one is best".  Life is not that simple.
> 
> Or, you could use chattr +i to make the /etc/resolv.conf file immutable,
> so DHCP clients and other programs cannot overwrite it.
> 
> Either way, you take ownership of whatever strategy you decide to use,
> together with its pros and cons.  You'll have to understand that on *this*
> system, you went with *this* strategy, and remember where to put your
> changes, and how to make them.  Or at the very least, you'll need to be
> *aware* of all the strategies you've got in play on all of your systems,
> and know how to identify which one is in use on any given system.


Thank you for the clarification.  Thankfully, my gateway DHCP server and 
my Debian instances work together.


David

[toc] | [prev] | [next] | [standalone]

#268040 — Re: electrons/the Internet doesn't like … that I like to eat raw garlic, ...

On Mon 04 Mar 2024 at 12:36:54 (-0800), David Christensen wrote:
> On 3/4/24 08:37, Albretch Mueller wrote:

> > _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
> > Entry(1)_20210618043317.pdf"
> 
> When I click the above link in my mail client (Thunderbird), my
> browser (Firefox) attempts to open the URL.  But, the URL is mangled
> by mail client line wrap and/or indentation (?), and the connection
> times out:
> 
> https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
> 
> An error occurred during a connection to christuniversity.in.

I ignored the filename, and pasted https://christuniversity.in/uploads/course/
into FF. Here's the text copy/pasted off the page that was displayed.
It was accompanied by the image that is displayed at
https://christuniversity.in/images/cour-btch-bnnr.jpg

✄✄✄✄✄✄✄✄

    Alumni
    Careers
    IQAC
    International
    Centres&Cells
    Accreditation

    About Us
    Academics
    Research
    Student Life
    E - Services
    Campuses
    Visitors

Programme Details

    Open From :
    Open Until :

CHRIST
(Deemed to be University)

Dharmaram College Post, Hosur Road, Bengaluru - 560029,
Karnataka, India

Tel: +91 804012 9100 / 9600

Fax: 40129000

Email: mail@christuniversity.in

Web: http://www. christuniversity.in
Vision

EXCELLENCE AND SERVICE
Mission

CHRIST (Deemed to be University) is a nurturing ground for an individual's holistic development to make effective contribution to the society in a dynamic environment.

    UBA
    FCRA
    Alumni
    IQAC
    Careers

    Library
    Centres
    Research
    Admission
    Course Index

Copyright © CHRIST (Deemed to be University) 2020 | Privacy Policy
Website Developed by Cloud Business Pages from INI Technologies Pvt Ltd., Kochi, India

✄✄✄✄✄✄✄✄

Just a data point.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268050 — Re: electrons/the Internet doesn't like … that I like to eat raw garlic, ...

On 3/4/24 16:06, David Wright wrote:
> On Mon 04 Mar 2024 at 12:36:54 (-0800), David Christensen wrote:
>> On 3/4/24 08:37, Albretch Mueller wrote:
> 
>>> _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
>>> Entry(1)_20210618043317.pdf"
> 
> I ignored the filename, and pasted https://christuniversity.in/uploads/course/
> into FF. Here's the text copy/pasted off the page that was displayed.
> It was accompanied by the image that is displayed at
> https://christuniversity.in/images/cour-btch-bnnr.jpg
> ...
> Just a data point.


Testing ping again:

2024-03-04 17:31:14 dpchrist@laalaa ~
$ ping -c 3 christuniversity.in
PING christuniversity.in (111.93.136.229) 56(84) bytes of data.
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=1 ttl=49 time=273 ms
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=2 ttl=49 time=272 ms
64 bytes from 111.93.136.229 (111.93.136.229): icmp_seq=3 ttl=49 time=273 ms

--- christuniversity.in ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 271.914/272.406/272.725/0.352 ms

2024-03-04 17:31:23 dpchrist@laalaa ~
$ ping -c 3 103.105.225.131
PING 103.105.225.131 (103.105.225.131) 56(84) bytes of data.

--- 103.105.225.131 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2060ms

2024-03-04 17:31:41 dpchrist@laalaa ~
$ ping -c 3 111.93.136.229
PING 111.93.136.229 (111.93.136.229) 56(84) bytes of data.
64 bytes from 111.93.136.229: icmp_seq=1 ttl=49 time=277 ms
64 bytes from 111.93.136.229: icmp_seq=2 ttl=49 time=280 ms
64 bytes from 111.93.136.229: icmp_seq=3 ttl=49 time=276 ms

--- 111.93.136.229 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 276.118/277.636/280.041/1.719 ms


So, same results as before -- one IP works, the other does not, and I 
got lucky with the FQDN (a previous test got the wrong IPv4 address and 
timed out).


Testing Firefox:

https://christuniversity.in/uploads/course/

https://103.105.225.131/uploads/course/

https://111.93.136.229/uploads/course/


All three time out.


Doing whois searches on the A record IP addresses:

1.  https://www.whois.com/whois/103.105.225.131


The IPv4 address holder appears to be a small ISP with 4 @ IPv4 class C 
ranges (1,024 addresses).  It appears nothing is connected to the 
christuniversity.in IPv4 address.


2. https://www.whois.com/whois/111.93.136.229


The IPv4 address holder appears to be a larger ISP with 1 @ IPv4 class B 
range (65,535 addresses).  It appears there is a host connected to the 
christuniversity.in IPv4 address, but I cannot connect to its web server.


STFW for information about DNS A (Address) records, I see:

https://www.cloudflare.com/learning/dns/dns-records/dns-a-record/

What is a DNS A record?
...
The vast majority of websites only have one A record, but it is possible 
to have several. Some higher profile websites will have several 
different A records as part of a technique called round robin load 
balancing, which can distribute request traffic to one of several IP 
addresses, each hosting identical content.


So, two DNS A records for the same FQDN is allowed and can be useful.


Searching for all DNS records for christuniversity.in :

https://www.whatsmydns.net/dns-lookup?query=christuniversity.in&server=opendns


I see the two A (address) records that we have been discussing:

id 21430, opcode QUERY, rcode NOERROR, flags QR RD RA
;QUESTION
christuniversity.in. IN A
;ANSWER
christuniversity.in. 60 IN A 111.93.136.229
christuniversity.in. 60 IN A 103.105.225.131
;AUTHORITY
;ADDITIONAL


I see five MX (mail exchanger) records:

id 52477, opcode QUERY, rcode NOERROR, flags QR RD RA
;QUESTION
christuniversity.in. IN MX
;ANSWER
christuniversity.in. 60 IN MX 1 aspmx.l.google.com.
christuniversity.in. 60 IN MX 5 alt1.aspmx.l.google.com.
christuniversity.in. 60 IN MX 5 alt2.aspmx.l.google.com.
christuniversity.in. 60 IN MX 10 alt3.aspmx.l.google.com.
christuniversity.in. 60 IN MX 10 alt4.aspmx.l.google.com.
;AUTHORITY
;ADDITIONAL


I see two NS (nameserver) records:

id 57399, opcode QUERY, rcode NOERROR, flags QR RD RA
;QUESTION
christuniversity.in. IN NS
;ANSWER
christuniversity.in. 60 IN NS ns1.christuniversity.in.
christuniversity.in. 60 IN NS ns2.christuniversity.in.
;AUTHORITY
;ADDITIONAL


I find it strange that there are no A records for:

ns1.christuniversity.in
ns2.christuniversity.in


And yet dig(1) can find them:

2024-03-04 17:56:59 dpchrist@laalaa ~
$ dig @9.9.9.9 ns1.christuniversity.in

; <<>> DiG 9.16.48-Debian <<>> @9.9.9.9 ns1.christuniversity.in
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40331
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ns1.christuniversity.in.	IN	A

;; ANSWER SECTION:
ns1.christuniversity.in. 60	IN	A	111.93.136.227

;; Query time: 284 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Mon Mar 04 17:59:17 PST 2024
;; MSG SIZE  rcvd: 68

2024-03-04 17:59:17 dpchrist@laalaa ~
$ dig @9.9.9.9 ns2.christuniversity.in

; <<>> DiG 9.16.48-Debian <<>> @9.9.9.9 ns2.christuniversity.in
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42915
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns2.christuniversity.in.	IN	A

;; ANSWER SECTION:
ns2.christuniversity.in. 59	IN	A	103.105.225.129

;; Query time: 276 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Mon Mar 04 17:59:48 PST 2024
;; MSG SIZE  rcvd: 68


Those IPv4 addresses do match the existing A record addresses.


I see one SOA (Start of Authority) record:

id 18177, opcode QUERY, rcode NOERROR, flags QR RD RA
;QUESTION
christuniversity.in. IN SOA
;ANSWER
christuniversity.in. 60 IN SOA ns1.christuniversity.in. 
admin.christuniversity.in. 2010101511 10800 900 604800 86400
;AUTHORITY
;ADDITIONAL


Perhaps admin at christuniversity.in is a working e-mail address?


I see six TXT (Text) records:

id 21594, opcode QUERY, rcode NOERROR, flags QR RD RA
;QUESTION
christuniversity.in. IN TXT
;ANSWER
christuniversity.in. 60 IN TXT "MS=ms82463954"
christuniversity.in. 60 IN TXT "0tdv84q1587b1vq8z6g6lhxbbjzsd2jf"
christuniversity.in. 60 IN TXT "ZOOM_verify_95Xn7cn5cTBX0YsQ9COsZy"
christuniversity.in. 60 IN TXT "MS=61A57F802201FA74460EE120E17085C57609A1C4"
christuniversity.in. 60 IN TXT "v=spf1 include:_spf.google.com 
include:zcsend.in ~all"
christuniversity.in. 60 IN TXT 
"adobe-idp-site-verification=7b1f2b5d56e53e37d862a4dd5fc9e9308acd04ed7ddd7b669dd9dbb91cab183a"
;AUTHORITY
;ADDITIONAL


AIUI TXT records are tied to authentication and authorization for 
various Internet services.


Doing the same lookup for my domain (holgerdanske.com), I only see a 
portion of the DNS records that I see via my hosting provider's control 
panel.  So, there could be more DNS records for christuniversity.in that 
we are not seeing.


David

[toc] | [prev] | [next] | [standalone]

#268043 — Re: electrons/the Internet doesn't like question authority niggahs?, oris it that I like to eat raw garlic, ...

On 3/4/24 11:42, Albretch Mueller wrote:
> spend days on end reading, coding and thinking about Math?
[...]
Your traceroute might be your isp throttling things as traceroute 
demands an answer from every machine it passes thru to get to the 
destination. Some ISP's might frown on that as its a huge traffic burst.

> _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
> Entry(1)_20210618043317.pdf"

This above is busted and will continue to be until you replace the " " 
wrapping it up with left & right arrows like: <https://path/to/file> 
which unless your email agent is truly Jurassic, will protect the link 
from line wrapping. It can then be wrapped in transit and still work. It 
has been a std for 2 decades or more.

[...]

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268055 — Re: electrons/the Internet doesn't like question authority niggahs?, oris it that I like to eat raw garlic, ...

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 04, 2024 at 07:44:41PM -0500, gene heskett wrote:
> On 3/4/24 11:42, Albretch Mueller wrote:
> > spend days on end reading, coding and thinking about Math?
> [...]
> Your traceroute might be your isp throttling things as traceroute demands an
> answer from every machine it passes thru to get to the destination. Some
> ISP's might frown on that as its a huge traffic burst.
> 
> > _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
> > Entry(1)_20210618043317.pdf"
> 
> This above is busted and will continue to be until you replace the " "
> wrapping it up with left & right arrows like: <https://path/to/file>

Sorry, Gene -- this is nonsense (at several levels).

The quotes (") prevent the shell from splitting the thing into two pieces.
You'll have to make sure to quote the expansion like so "$_LINK" if you
want to prevent it being split again where it's used (e.g. as an arg to
wget or curl, or...)

That hasn't changed.

The angle brackets may quote in very specific contexts (e.g. an email
body). Or they may not. That depends on all the mail handling tidbits
in their way.

For the shell, the angle brackets HAVE A TOTALLY DIFFERENT MEANING
(sorry for raising my voice). They might redirect your stdin/stdout
or kill all kitten in your household, depending on context.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268056 — Re: electrons/the Internet doesn't like question authority niggahs?,oris it that I like to eat raw garlic, ...

On 3/5/24 00:34, tomas@tuxteam.de wrote:
> On Mon, Mar 04, 2024 at 07:44:41PM -0500, gene heskett wrote:
>> On 3/4/24 11:42, Albretch Mueller wrote:
>>> spend days on end reading, coding and thinking about Math?
>> [...]
>> Your traceroute might be your isp throttling things as traceroute demands an
>> answer from every machine it passes thru to get to the destination. Some
>> ISP's might frown on that as its a huge traffic burst.
>>
>>> _LINK="https://christuniversity.in/uploads/course/E&Comp_21-25_Lateral
>>> Entry(1)_20210618043317.pdf"
>>
>> This above is busted and will continue to be until you replace the " "
>> wrapping it up with left & right arrows like: <https://path/to/file>
> 
> Sorry, Gene -- this is nonsense (at several levels).
> 
> The quotes (") prevent the shell from splitting the thing into two pieces.
> You'll have to make sure to quote the expansion like so "$_LINK" if you
> want to prevent it being split again where it's used (e.g. as an arg to
> wget or curl, or...)
> 
> That hasn't changed.
> 
> The angle brackets may quote in very specific contexts (e.g. an email
> body). Or they may not. That depends on all the mail handling tidbits
> in their way.
> 
> For the shell, the angle brackets HAVE A TOTALLY DIFFERENT MEANING
> (sorry for raising my voice). They might redirect your stdin/stdout
> or kill all kitten in your household, depending on context.
> 
> Cheers

I'll summerize, Tomas, it works for me. I use FF as a browser, and 
prefer bash as a shell. Currently t-bird for email but its buggier than 
a 10 day old road kill in the filter to mailbox category. Its a full 
time job keeping the mail filters that sort mail to local stash working 
at a 50% catch rate.  Old school? Guilty.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web