Fellow humans, we have a peculiar network setup in our infrastructure that forces us to use ipv6 for pretty much every machine, except for those few that really need to be reachable by the outside world. because we've been putting off to setup our own nat64 gateway, we're using a public one, but it's *slooooow*, like a really slow thing. we can feel this particularly with package downloads which are not available via ipv6 (ppa.launchpad.net and many others…).
but that's a known and easily solved problem! we can just put traffic server as forward proxy to cache our package downloads! well, yesno… for particularly large packages traffic server seems to abort the connection (transaction?) pkg02% curl --keepalive-time 900 -ivx http://pkg.esat:3142 http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb >/dev/null * Hostname was NOT found in DNS cache % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2a01:4f8:211:9d6::126... * Connected to pkg.esat (2a01:4f8:211:9d6::126) port 3142 (#0) > GET > http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb > HTTP/1.1 > User-Agent: curl/7.35.0 > Host: repos.azulsystems.com > Accept: */* > Proxy-Connection: Keep-Alive > < HTTP/1.1 200 OK < x-amz-id-2: qGbKzSL/PzHYeKH7ZrBB4dpV/fEEIhjUoIenhl7/0RtvjPFJgiCoExSDCR04oKFI < x-amz-request-id: 1010A0D32A1AE6B2 < Date: Wed, 18 Feb 2015 08:15:49 GMT < x-amz-meta-s3cmd-attrs: uid:10116/gname:eroper/uname:eroper/gid:10116/mode:33188/mtime:1422558044/atime:1422558044/md5:7d5b314849fbba47ddcaeccf257ca4 e7/ctime:1422558044 < Last-Modified: Thu, 29 Jan 2015 20:59:35 GMT < ETag: "7d5b314849fbba47ddcaeccf257ca4e7" < Content-Type: application/x-debian-package < Content-Length: 77361366 * Server ATS/5.2.0 is not blacklisted < Server: ATS/5.2.0 < Age: 1 < Proxy-Connection: keep-alive < Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uScMsSf pSeN:t cCMi p sS]) < { [data not shown] 1 73.7M 1 1057k 0 0 8686 0 2:28:26 0:02:04 2:26:22 0* transfer closed with 76278642 bytes remaining to read 1 73.7M 1 1057k 0 0 8645 0 2:29:08 0:02:05 2:27:03 0 * Closing connection 0 curl: (18) transfer closed with 76278642 bytes remaining to read pkg02% the squid.blob then reads: 1424247473.770 125226 2a01:4f8:211:9d6::126 ERR_READ_ERROR/200 638 GET http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb - TIMEOUT_DIRECT/repos.azulsystems.com application/x-debian-package note that curl does *not* abort, when i download this without -x proxy. but it does take about 25~ minutes to download. the following changes have shown neither positive or negative effect: proxy.config.http.transaction_no_activity_timeout_out => 120 # default 30 proxy.config.http.down_server.abort_threshold => 30 # default 10 i've also tried using tspush to push the artefact into traffic server's cache (after changing proxy.config.http.push_method_enabled to 1), with no success: pkg02% perl tspush -f zulu1.8.0_31-8.5.0.1_amd64.deb -u http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb -s http://127.0.0.1:3142 HTTP/1.0 400 Response Not Cachable Date: Wed, 18 Feb 2015 09:02:57 GMT Via: http/1.1 <proxy_name> (ApacheTrafficServer/5.2.0 [uEc s f p eH:t cC i p s ]) Server: ATS/5.2.0 Cache-Control: no-store Content-Type: text/html Content-Language: en Content-Length: 207 and from the logs: 20150218.09h02m57s RESPONSE: sent 127.0.0.1 status 400 (Response Not Cachable) for 'http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb' 1424250177.091 0 127.0.0.1 ERR_INVALID_REQ/400 477 PUSH http://repos.azulsystems.com/ubuntu/pool/main/zulu1.8.0_31-8.5.0.1_amd64.deb - NONE/- text/html -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: [email protected] URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
