Installation via apt on Vagrant machine is very slow #52
Comments
ihmels
changed the title
|
I think this is similar to #47, Px is trying to download everything into memory before sending back to you. 640103684 = 610MB so it's downloading the whole thing before sending anything. |
|
We encountered the same problem with Chocolatey. Installing a package with a big download (eg. jdk8, ~200MB) does not work if we are using a slower wifi connection. Chocolatey stops with a timeout after a minute or so. I'm not sure how much effort is needed to rework px. From a code perspective, the reading of the data is not really near the writing to the response stream in fwd_resp(). I think the refactoring needed is too much work for me currently :-( |
|
Just like you mentioned, it requires a full re-architect of the HTTP GET call. A workaround is to use HTTPS which totally bypasses Px for this work since client and server talk directly. It may not be always available though so does need to be fixed eventually. I'm still thinking how to best handle this. |
|
HTTPS is a good point. But now I'm wondering, why a bigger https download via chocolatey+px is also ending in the same timeout. That's strange. I'll try to debug this a little bit more. Maybe it's a bug in Chocolatey. Changing the timeouts did not help there :-( |
|
@ccbur I have also had the problems with HTTPS connections. So I think it’s not a bug in Chocolatey. |
|
Can you please post an HTTPS log for Px showing this problem? I don't see how it can be the same issue since Px doesn't get involved in any of the content length and size actions. Logs will help figure that out. |
|
I tried to download the Composer installer with Wget and got the following error: Logs of px: |
|
@ihmels, I just tried https://getcomposer.org/installer with my proxy and it worked fine. I don't know what's wrong and it's not possible to tell since everything Px has done in these logs matches mine. Once wget is tunneling through the proxy, Px is only passing encrypted data back and forth and has no clue. Can you try with curl or another SSL server for test purposes? |
|
This has been fixed in latest release posted. Please verify that it works as expected now. |
|
Unfortunately for me the problem is not solved. I ran the following command in the Cygwin Terminal on the Windows 7 host. $ wget https://www.google.com
--2018-08-29 11:30:45-- https://www.google.com/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:3129... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:3129... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.LogConfig: px.ini[proxy]
; NTLM server(s) to connect through. IP:port, hostname:port
; Multiple proxies can be specified comma separated. Px will iterate through
; and use the one that works. Required field unless --noproxy is defined. If
; remote server is not in noproxy list and proxy is undefined, Px will reject
; the request
server = proxy01.exmaple.test:8080
; IP interface to listen on - default: 127.0.0.1
listen = 127.0.0.1
; Port to run this proxy on - default: 3128
port = 3129
; Allow remote machines to use this proxy
; Overrides listen definition above and binds to all interfaces
gateway = 1
; Allow only local interfaces to use proxy. 0 or 1, default: 0
; Px allows all IP addresses assigned to local interfaces to use the service.
; This allows local apps as well as VM or container apps to use Px when in a
; NAT config. Px does this by listening on all interfaces and overriding the
; allow list.
hostonly = 0
; Allow connection from following subnets, comma separated - default: *.*.*.*
; Whitelist which IPs can use the proxy. --hostonly overrides any definitions
; unless --gateway mode is also specified
; 127.0.0.1 - specific ip
; 192.168.0.* - wildcards
; 192.168.0.1-192.168.0.255 - ranges
; 192.168.0.1/24 - CIDR
allow = *.*.*.*
; Direct connect to following subnets, comma separated
; Skip the NTLM proxy and connect directly like a regular proxy
; 192.168.0.* - wildcards
; 192.168.0.1-192.168.0.255 - ranges
; 192.168.0.1/24 - CIDR
noproxy =
; Override or send User-Agent header on client's behalf
useragent =
[settings]
; Number of parallel workers (processes)
workers = 2
; Number of parallel threads per worker (process)
threads = 5
; Idle timeout in seconds for HTTP connect sessions before closing the connection
idle = 30
; Timeout in seconds for connections before giving up
socktimeout = 20.0
; Time interval in seconds before refreshing proxy info. Valid int, default: 60
; Proxy info reloaded from a PAC file found via WPAD or AutoConfig URL, or
; manual proxy info defined in Internet Options
proxyreload = 60
; Run in foreground when frozen or with pythonw.exe. 0 or 1, default: 0
; Px will attach to the console and write to it even though the prompt is
; available for further commands. CTRL-C in the console will exit Px
foreground = 0
; Enable logging
; Logs are written to the same directory that Px is run and are over-written on startup
log = 1 |
|
If I'm running px as administrator, it does work sometimes and sometimes I ran into SSL errors. |
|
Per the logs, Px has authenticated the user and created a tunnel. Also, this code change was only for http, not https. Can you check to see if all ssl sites fail or just Google? Also, can you try curl and a browser as well? Could be an older version of wget or a tls version issue. |
|
The following block shows the log after trying to run
The sixth try was successful. |
|
I tried both curl and wget and both worked with my proxy. Am unsure what's going on here. My versions are from MSYS and as follows:- curl: 7.61.0 with OpenSSL 1.0.2c I also tried the latest version of curl linked with OpenSSL 1.1.0i and that worked too. What are your versions? Also, are you running the Px executable version posted or running with your own version of Python? If from source, can you try with the executable? Doubt this will make any difference since Px does nothing related to SSL. curl/curl#2294 suggests that |
|
I'm running the executable. My versions are: curl: curl 7.59.0 with OpenSSL/1.0.2p |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I want to install a package via apt on my Ubuntu 18.04 Vagrant machine. It takes very long until
[Waiting for headers]disappears and the installation begins. I'm running Windows 7 and the version 2018-05-19 of px. Sometimes apt prints the error messageConnection failed [IP: 10.0.2.2 3129]. The log then says:If I switch back to Cntlm everything works normal.
The text was updated successfully, but these errors were encountered: