Lite Upgrade (3.4 to 3.6) via a proxy server doesn't work

[WytWun]

Attempted to use Lite Upgrade to update a 3.4 system to 3.6 and get an error message:

"Linux Lite Upgrade Utility was unable to establish a connection with the Linux Lite master repository.  Please check your internet connection and try again."

This system can only access the internet via a web proxy, for which the details have been set in environment variables in /etc/environment and APT configuration options in /etc/apt/apt.conf.  The Install Updates utility works normally and I had run this (and successfully applied some updates) and rebooted before attempting to run Lite Upgrade.  I've also successfully installed Lite Software packages on this system.

I can therefore only conclude that Lite Upgrade is not respecting any of the proxy settings in place.

If Lite Upgrade can be convinced to do the upgrade via a proxy, how do I set the proxy details?  If it doesn't support a proxy, is it a script I can look at modifying? (I understand shell scripts and Python ok, Perl not so much)

Thanks.

[valtam]

There's a wget proxy statement in the code. I'm not at my computer right now so I can't test whether or not removing it would still work. Probably better for ralphy to answer why it's there. Line 495 in /usr/bin/lite-upgrade-series3

Sent from my Mobile phone using Tapatalk

[humdinger70]

I'm getting the same error and I'm NOT on a proxy server. I did the lite update and it worked OK. Should I have done a reboot after the update before doing the upgrade? I don't think I did that in the past (when I went from 3.2 to 3.4).

I have the mintupdate from Ralphy installed but I used the regular update tools for the 3.4 to 3.6 conversion.

Is the master repository down or undergoing maintenance right now? FYI, I'm trying to do the upgrade at 1:05 AM Pacific Daylight Time from Southern California.

[WytWun]

There's a wget proxy statement in the code. I'm not at my computer right now so I can't test whether or not removing it would still work. Probably better for ralphy to answer why it's there. Line 495 in /usr/bin/lite-upgrade-series3

Thanks Jerry - the wget man page makes clear that the --no-proxy option would result in the behaviour I'm seeing.  Before editing this option out I'd prefer to know why it's set

FWIW I didn't have any problems with the upgrade on another system that isn't behind a proxy.

humdinger70: If I correctly understand the options to the wget command Jerry identified, the connectivity check only makes 2 attempts to connect to the Linux Lite repositories and will bail out if any network transaction doesn't succeed within 1 second.  If for some reason your network connection is via a service with heavily congested communications links or subject to very high latency, including for DNS queries, I could see you getting this message.

[ralphy]

Ralphy  <==  Blame this guy!

The --no-proxy statement should be removed, but a timeout should be there anyways (maybe a little higher) since that prevents anomalies like hanging reads and infinite connects. High latency shouldn't necessary be a problem with the current 2 attempts. We went as far as testing with dnscrypt-proxy and no cache to ensure that we could get the timeout as low as possible without failures. If there are DNS queries taking over 1000ms in a network, maybe that's what should be addressed in the first place.


It was left there unintentionally (like I said, blame that guy)... I was testing the new widget updates and didn't want to get a cached version from the local proxy; that's how it got there . It will undoubtedly cause issues if a web proxy is required to access the outside world in your network. Besides, the proxy settings should be respected regardless.

[humdinger70]

OK, ralphy, saw your response. Question  anything I can do to fix it at my end?

FYI, I thought at 1:00 AM Pacific time, most people would be off their systems and be asleep or something. Now 7:35 AM on 09/01 and I still get the problem (even did a machine reboot).

[ralphy]

OK, ralphy, saw your response. Question  anything I can do to fix it at my end?


FYI, I thought at 1:00 AM Pacific time, most people would be off their systems and be asleep or something. Now 7:35 AM on 09/01 and I still get the problem (even did a machine reboot).

hmmm... you said you are not behind a proxy so it is not a proxy issue for you. Try running from terminal something like:

Code:

wget -nv -t2 -T1 --ignore-length --max-redirect=1  --spider http://repo.linuxliteos.com/linuxlite/db/version

if the communication succeeds it should give you an OK response:

Code:

2017-09-01 14:29:26 URL: http://repo.linuxliteos.com/linuxlite/db/version 200 OK

You can also use ping, dig, traceroute, etc. to find out whether you can reach the repo or not.

[humdinger70]

I ran the commands - the link does exist, but wget doesn't like it.

larry@larry-ThinkPad-X220:~$ wget -nv -t2 -T1 --ignore-length --max-redirect=1  --spider http://repo.linuxliteos.com/linuxlite/db/version
wget: unable to resolve host address ‘repo.linuxliteos.com’
larry@larry-ThinkPad-X220:~$ ping repo.linuxliteos.com
PING repo.linuxliteos.com (142.54.171.138) 56(84) bytes of data.
64 bytes from 142.54.171.138: icmp_seq=1 ttl=45 time=91.7 ms
64 bytes from 142.54.171.138: icmp_seq=2 ttl=45 time=74.3 ms
64 bytes from 142.54.171.138: icmp_seq=3 ttl=45 time=74.2 ms
64 bytes from 142.54.171.138: icmp_seq=4 ttl=45 time=72.6 ms
64 bytes from 142.54.171.138: icmp_seq=5 ttl=45 time=73.2 ms
64 bytes from 142.54.171.138: icmp_seq=6 ttl=45 time=73.0 ms
64 bytes from 142.54.171.138: icmp_seq=7 ttl=45 time=110 ms
^C
--- repo.linuxliteos.com ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6007ms
rtt min/avg/max/mdev = 72.667/81.418/110.629/13.498 ms
larry@larry-ThinkPad-X220:~$ traceroute repo.linuxliteos.com
traceroute to repo.linuxliteos.com (142.54.171.138), 30 hops max, 60 byte packets
1  homeportal (192.168.1.254)  4.362 ms  4.757 ms  4.751 ms
2  99-109-80-1.lightspeed.sndgca.sbcglobal.net (99.109.80.1)  91.447 ms  92.709 ms  121.214 ms
3  71.148.118.102 (71.148.118.102)  26.124 ms  26.765 ms  27.338 ms
4  75.20.78.180 (75.20.78.180)  28.751 ms  31.191 ms  31.183 ms
5  75.20.78.129 (75.20.78.129)  30.082 ms  31.134 ms  31.132 ms
6  12.83.70.149 (12.83.70.149)  30.333 ms 12.83.70.141 (12.83.70.141)  21.111 ms 12.83.70.149 (12.83.70.149)  21.643 ms
7  ggr2.la2ca.ip.att.net (12.122.129.105)  27.114 ms  25.723 ms  25.097 ms
8  10ge2-18.core1.lax2.he.net (216.218.185.169)  23.932 ms  26.532 ms  25.776 ms
9  100ge9-2.core1.den1.he.net (184.105.222.114)  86.398 ms  85.597 ms  85.913 ms
10  100ge14-1.core1.mci3.he.net (184.105.64.50)  74.120 ms  74.766 ms  71.882 ms
11  10ge4-1.core1.mci2.he.net (184.105.213.37)  73.535 ms  75.430 ms  74.288 ms
12  wholesale-internet-inc.10gigabitethernet1-3.core1.mci2.he.net (216.66.78.90)  72.786 ms  82.150 ms  80.843 ms
13  * lag-to-oak.edge-a.clay1.mci.us.as32097.net (69.30.209.163)  71.533 ms lag-to-oak.edge-b.clay1.mci.us.as32097.net (69.30.209.138)  81.383 ms
14  lag-core-a.dist-2-6-a.clay1.mci.us.as32097.net (192.187.107.43)  73.386 ms  76.181 ms lag-core-b.dist-2-6-a.clay1.mci.us.as32097.net (208.110.88.43)  76.527 ms
15  142.54.171.138 (142.54.171.138)  77.300 ms  79.684 ms  79.208 ms
larry@larry-ThinkPad-X220:~$

[humdinger70]

Weird thing - a direct connection via Firefox to the repo in the 'wget' command (to view the file) works just fine.

[ralphy]

[member=6217]humdinger70[/member], that's interesting; your machine is not doing DNS resolution with "wget" while it does with a "web browser".

Few things, try to run the same test without a timeout... from terminal:

Code:

wget -v --spider http://repo.linuxliteos.com/linuxlite/db/version

If wget still cannot resolve the host, then try curl for example:

Code:

curl -i http://repo.linuxliteos.com/linuxlite/db/version

If wget and curl are unable to return anything then you may need to look at nsswitch.conf or something I assume, something DNS related in my opinion.