Mga Opsyon sa Proxy ng RPM para sa Pag-download ng Pakete Batay sa URL

rpm -Uvh https://packages.example.net/example.rpm ay may hakbang ng pagkuha sa pamamagitan ng network. Bago i-verify o i-install ang pakete, kailangang makuha ng RPM ang file.

Ang gumaganang configuration ng proxy ng DNF ay hindi nagtatakda ng mga setting na ginagamit ng hiwalay na pagtawag na iyon. Dokumentado ng manwal ng RPM ang --httpproxy at --httpport para sa landas ng pagkuha nito sa HTTP. Ang naka-install na bersyon ng RPM at ang ayos ng katulong nito sa URL ang tumutukoy sa mga detalye. Minarkahan ng reperensya ng mga karaniwang opsyon ng RPM 6 ang mga opsyon sa pagkuha sa network na ito bilang lipas na at inirerekomenda sa halip ang isang dedikadong kasangkapan sa pagkuha tulad ng curl o GNU Wget.

Para sa isang workflow na pinapanatili mo, alamin muna kung aling layer ang kumukuha ng URL. Para sa bagong workflow, ang hayagang inaprubahang pag-download na sinusundan ng lokal na pag-verify at pag-install ng pakete ay umiiwas sa pagdepende sa mga lipas nang opsyon sa pagkuha na ito.

Panatilihin ang mga field sa kanilang dokumentadong format. Huwag ipagpalagay na tinatanggap ng bawat bersyon ang URL na may mga kredensyal saanman hinihingi ang pangalan ng host ng proxy, at huwag i-edit ang global na macro file ng isang distribusyon dahil lang ginawa iyon ng lumang sagot.

Tukuyin ang yugto ng pagkabigo: nakarating ba ang pagkuha sa proxy, tinanggap ba ang pagpapatotoo, at ibinalik ba ng dulo ng pakete ang intended na file? Ang mamaya na error sa lagda o dependency ay ibang problema kaysa sa natigil na koneksyon sa proxy.

Panatilihin ang normal na pag-verify ng pakete. Ang pagpapagana ng ruta ng pag-download ay hindi dahilan para patayin ang mga pagsusuri sa lagda, mag-install ng hindi pinagkakatiwalaang file, o ituring ang matagumpay na utos ng DNF bilang patunay na ang pagkuha ng RPM na ito ay sumunod sa parehong ruta.