RPM-proxyvalg for URL-baserte pakkenedlastinger
Sjekk RPMs egne proxyvalg for URL-henting når en direkte fjernpakke-kommando oppfører seg annerledes enn DNF.
rpm -Uvh https://packages.example.net/example.rpm inneholder et trinn der filen hentes over nettverket. Før pakken verifiseres eller installeres, må RPM skaffe filen.
En fungerende DNF-proxykonfigurasjon fastsetter ikke innstillingene som det separate kallet bruker. RPMs håndbok dokumenterer --httpproxy og --httpport for HTTP-hentingsveien. Den installerte RPM-versjonen og oppbyggingen av URL-hjelperen bestemmer detaljene. Oversikten over felles valg i RPM 6 merker disse nettverkshentingsvalgene som utdaterte og anbefaler i stedet et eget henteverktøy som curl eller GNU Wget.
For en arbeidsflyt du vedlikeholder, fastslå først hvilket lag som henter URL-en. For en ny flyt unngår en uttrykkelig godkjent nedlasting, etterfulgt av lokal pakkeverifisering og -installasjon, å være avhengig av disse utdaterte hentevalgene.
Behold feltene i dokumentert format. Ikke anta at hver versjon godtar en URL med påloggingsinformasjon overalt der et proxyvertsnavn kreves, og ikke rediger en distribusjons globale makrofil bare fordi et gammelt svar gjorde det.
Finn feiltrinnet: kunne hentingen nå proxyen, ble autentiseringen godtatt, og returnerte pakkens endepunkt den tiltenkte filen? En senere signatur- eller avhengighetsfeil er et annet problem enn en fastlåst proxyforbindelse.
Behold den vanlige pakkeverifiseringen. At nedlastingsveien virker er ikke grunn til å slå av signaturkontroller, installere en ikke-klarert fil eller ta en vellykket DNF-kommando som bevis for at denne RPM-hentingen fulgte samme vei.