RPM-proxyopties voor URL-gebaseerde pakketdownloads
Controleer de eigen proxyopties van RPM voor URL-ophalen wanneer een directe opdracht voor een pakket op afstand zich anders gedraagt dan DNF.
rpm -Uvh https://packages.example.net/example.rpm bevat een stap waarbij het bestand via het netwerk wordt opgehaald. Voordat het pakket wordt geverifieerd of geïnstalleerd, moet RPM het bestand verkrijgen.
Een werkende DNF-proxyconfiguratie legt niet de instellingen vast die die afzonderlijke aanroep gebruikt. De handleiding van RPM documenteert --httpproxy en --httpport voor het HTTP-ophaalpad. De geïnstalleerde RPM-versie en de opzet van de URL-hulptool bepalen de details. Het overzicht van algemene opties van RPM 6 markeert deze netwerk-ophaalopties als verouderd en raadt in plaats daarvan een toegewijde ophaaltool aan, zoals curl of GNU Wget.
Bepaal voor een werkstroom die u onderhoudt eerst welke laag de URL ophaalt. Voor een nieuwe werkstroom voorkomt een expliciet goedgekeurde download, gevolgd door lokale pakketverificatie en installatie, afhankelijkheid van deze verouderde ophaalopties.
Houd de velden in hun gedocumenteerde formaat. Ga er niet van uit dat elke versie een URL met inloggegevens accepteert overal waar een proxyhostnaam wordt gevraagd, en bewerk het globale macrobestand van een distributie niet alleen omdat een oud antwoord dat deed.
Stel de fase van de fout vast: kon het ophalen de proxy bereiken, werd de authenticatie geaccepteerd en gaf het eindpunt van het pakket het bedoelde bestand terug? Een latere fout in de handtekening of afhankelijkheden is een ander probleem dan een vastgelopen proxyverbinding.
Behoud de normale pakketverificatie. Een werkende downloadroute is geen reden om handtekeningcontroles uit te schakelen, een niet-vertrouwd bestand te installeren of een geslaagde DNF-opdracht te zien als bewijs dat dit RPM-ophalen dezelfde route volgde.