Kumokonekta ang VPN, naglo-load ang internal na wiki sa browser, at apt update ay nakabitin pa rin sa isang mirror na hindi niya maabot. Sa larawang iyon, walang sira sa tunnel. Ang browser at ang package manager ay gumawa ng dalawang magkaibang desisyon sa proxy, at isa lang sa kanila ang na-configure.

Kung aling desisyon ang nabigo ang tanging bagay na sulit tiyakin muna.

Basahin ang error bago kang humawak ng setting

May iba't ibang mensaheng iniiwan ang bawat yugto. Ang pangalang hindi kailanman nag-resolve ay DNS, ang koneksyong hindi kailanman natapos ay routing o firewall, ang agarang 407 ay authentication ng proxy, ang reklamo tungkol sa certificate ay pagpapatunay ng TLS, at ang babala sa lagda ay metadata ng repository. Kailangan ng limang kabiguang iyon ng limang magkaibang pagtatama, at ang linyang proxy na idinikit sa ibabaw ng problema sa DNS ay naglilipat lang ng paghinto.

Kopyahin ang eksaktong linya at ang repository na pinapangalanan nito bago ka magbago ng kahit ano. Ang malabong alaala ng „nag-time out“ ang siyang nagpapalit ng sampung minutong diagnosis tungo sa isang buong hapon.

May sariling setting ng proxy ang APT

Binabasa ng APT ang /etc/apt/apt.conf.d/, ang pangunahing apt.conf at anumang file na pinapangalanan ng APT_CONFIG. Hindi nito binabasa ang proxy profile ng desktop, setting ng network sa GNOME o extension ng browser. Iginagalang naman ng transport ang mga environment variable ng proxy, kaya ang gumaganang export https_proxy=... sa shell mo ay walang pinapatunayang anuman tungkol sa timer na tumatakbo sa ibang environment.

I-dump ang aktuwal na nakikita ng bumabagsak na proseso: apt-config dump | grep -i proxy.

Patakbuhin iyon bilang ang user na pinagpapatakbo ng bumabagsak na operasyon. Kung ibang set ng file ang binabasa ng root, o may timer ng systemd na nagsisimula sa ibang environment, magkakaiba ang dump, at ang pagkakaibang iyon ang sagot mo. Ang dalawang magkasalungat na halaga ng proxy ay mas masama kaysa isang kulang na halaga, dahil sinusundan ng transport ang pinakamatiyak na tugma na makikita nito.

Itakda ang proxy sa lugar kung saan inaasahan ito ng may-ari ng configuration

Para sa tahasang proxy na inaprubahan ng administrator, sapat na ang maliit na tipak sa bagong file:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

Ang ikatlong linya ang bahaging iniiwan ng karamihang halimbawa. Ang susi sa bawat host ay nananaig sa pangkalahatang halaga, kaya ang internal na mirror na maaabot sa pamamagitan ng tunnel ay makakalampas sa proxy habang ang lahat ng iba ay dumadaan pa rin dito. Ang DIRECT ang nakadokumentong halaga para doon, hindi walang-lamang string.

Idagdag ang tipak bilang bagong file na may numero, halimbawa /etc/apt/apt.conf.d/95proxy. Ang pag-overwrite sa file ng distribution ay nangangahulugang babalik nang tahimik ng susunod na update ng package ang binago mo.

Nananatili sa labas ng URI ang mga kredensyal

Ang sanggunian sa transport ng APT ay tumuturo sa apt_auth.conf para sa authentication, at doon dapat naroon ang username at password. Ang paglalagay sa kanila sa URI ng proxy ay naglalagay sa kanila sa listahan ng proseso, sa kasaysayan ng shell at sa bawat dump ng configuration na idinikit sa ticket. Kailangan ng auth file ang mahigpit na pahintulot, dahil imbakan ito ng kredensyal.

Suriin din ang scheme. Ang repository na HTTPS ay naaabot pa rin sa pamamagitan ng HTTP proxy; hiwalay na pagpipilian ang transport sa URI scheme ng mirror.

Hiwalay na front end ang graphical software center. Kung gumagamit ito ng PackageKit o snap backend, wala itong binabago sa tipak ng APT, kaya tiyakin kung aling proseso ang gumawa ng bigong kahilingan.

Tiyakin ang landas, hindi lang ang exit code

Kapag nakalagay na ang tipak, panoorin ang kahilingan sa halip na magtiwala sa berdeng resulta. Ipinapakita ng apt-get -o Debug::Acquire::http=true update ang pagtatangkang kumonekta, ang piniling proxy at ang response code, na siyang naghihiwalay ng maling proxy sa proxy na tumanggi sa iyo.

Pagkatapos ay subukan ang kaso na hindi dapat gumana. Idiskonekta ang VPN at tiyaking tumigil sa pagsagot ang internal na mirror; kung nagda-download pa rin, may nagruruta sa paligid ng tunnel o may lumang cache na naglilingkod sa iyo. Tiyaking nagpapatunay pa rin ng TLS ang pinapayagang landas at nagsusuri pa rin ng lagda ng repository, dahil ang proxy na sumisiyasat ng trapiko ay hindi dahilan para patayin ang alinman sa dalawa. Tiyakin din na ang kliyenteng hindi authenticated ay nakakakuha ng malinaw na pagtanggi sa halip na tahimik na timeout.

Itabi nang magkasama ang gumaganang tipak at ang bigong output sa talaan ng pagbabago. Ang susunod na taong makakatagpo ng parehong paghinto ay mas mabilis makikilala ang pagkakaiba ng dalawang linya kaysa sa anumang paliwanag.

Kaugnay na mga artikulo