RPM:s proxyalternativ för URL-baserade paketnedladdningar
Kontrollera RPM:s egna proxyalternativ för URL-hämtning när ett direkt fjärrpaketkommando beter sig annorlunda än DNF.
rpm -Uvh https://packages.example.net/example.rpm innehåller ett steg där filen hämtas över nätet. Innan paketet verifieras eller installeras måste RPM skaffa filen.
En fungerande DNF-proxykonfiguration fastställer inte de inställningar som det separata anropet använder. RPM:s handbok dokumenterar --httpproxy och --httpport för sin HTTP-hämtningsväg. Den installerade RPM-versionen och uppbyggnaden av dess URL-hjälpare avgör detaljerna. Översikten över gemensamma alternativ i RPM 6 markerar dessa nätverkshämtningsalternativ som föråldrade och rekommenderar i stället ett eget hämtverktyg som curl eller GNU Wget.
För ett arbetsflöde du underhåller, fastställ först vilket lager som hämtar URL:en. För ett nytt flöde undviker en uttryckligen godkänd nedladdning följd av lokal paketverifiering och -installation att vara beroende av dessa föråldrade hämtningsalternativ.
Behåll fälten i deras dokumenterade format. Anta inte att varje version accepterar en URL med inloggningsuppgifter överallt där ett proxyvärdnamn begärs, och redigera inte en distributions globala makrofil bara för att ett gammalt svar gjorde det.
Fastställ feletsteget: kunde hämtningen nå proxyn, accepterades autentiseringen och returnerade paketets slutpunkt den avsedda filen? Ett senare signatur- eller beroendefel är ett annat problem än en fastlåst proxyanslutning.
Bevara den normala paketverifieringen. Att få nedladdningsvägen att fungera är ingen anledning att stänga av signaturkontroller, installera en icke betrodd fil eller ta ett lyckat DNF-kommando som bevis för att denna RPM-hämtning följde samma väg.