RPM-proxyindstillinger til URL-baserede pakkedownloads
Kontroller RPMs egne proxyindstillinger til URL-hentning, når en direkte fjernpakke-kommando opfører sig anderledes end DNF.
rpm -Uvh https://packages.example.net/example.rpm indeholder et trin, hvor filen hentes over netværket. Før pakken kan verificeres eller installeres, skal RPM have fat i filen.
En fungerende DNF-proxykonfiguration fastlægger ikke de indstillinger, som netop det separate kald bruger. RPMs manual dokumenterer --httpproxy og --httpport til dens HTTP-hentningsvej. Den installerede RPM-version og dens URL-hjælpeprograms opbygning bestemmer detaljerne. RPM 6s oversigt over fælles valgmuligheder markerer disse netværkshentningsvalg som forældede og anbefaler i stedet et dedikeret henteværktøj som curl eller GNU Wget.
For et arbejdsforløb, du vedligeholder, skal du først fastslå, hvilket lag der henter URL'en. For et nyt forløb undgår en udtrykkeligt godkendt download efterfulgt af lokal pakkeverifikation og -installation at afhænge af disse forældede hentningsvalg.
Behold felterne i deres dokumenterede format. Gæt ikke på, at enhver version accepterer en URL med legitimationsoplysninger overalt, hvor der bedes om et proxy-værtsnavn, og rediger ikke en distributions globale makrofil, blot fordi et gammelt svar gjorde det.
Find fejltrinnet: kunne hentningen nå proxyen, blev godkendelsen accepteret, og returnerede pakkens endepunkt den tilsigtede fil? En senere signatur- eller afhængighedsfejl er et andet problem end en fastlåst proxyforbindelse.
Bevar den normale pakkeverifikation. At få downloadvejen til at virke er ikke grund til at slå signaturkontroller fra, installere en ikke-betroet fil eller tage en vellykket DNF-kommando som bevis for, at denne RPM-hentning fulgte samme vej.