RPM-Proxyoptionen für URL-basierte Paketdownloads
Prüfen Sie die eigenen URL-Abruf-Proxyoptionen von RPM, wenn ein direkter Befehl für entfernte Pakete sich anders als DNF verhält.
rpm -Uvh https://packages.example.net/example.rpm enthält einen Schritt, in dem über das Netzwerk abgerufen wird. Bevor das Paket geprüft oder installiert wird, muss RPM die Datei beschaffen.
Eine funktionierende DNF-Proxykonfiguration legt nicht die Einstellungen fest, die dieser getrennte Aufruf verwendet. RPMs Handbuch dokumentiert --httpproxy und --httpport für seinen HTTP-Abrufpfad. Die installierte RPM-Version und die Anordnung ihres URL-Helfers bestimmen die Einzelheiten. Die Referenz der allgemeinen Optionen von RPM 6 kennzeichnet diese Netzwerkabrufoptionen als veraltet und empfiehlt stattdessen ein eigenes Abrufwerkzeug wie curl oder GNU Wget.
Bei einem Arbeitsablauf, den Sie pflegen, stellen Sie zuerst fest, welche Schicht die URL abruft. Bei einem neuen Ablauf vermeidet ein ausdrücklich genehmigter Download mit anschließender lokaler Paketprüfung und Installation die Abhängigkeit von diesen veralteten Abrufoptionen.
Halten Sie die Felder in ihrem dokumentierten Format. Nehmen Sie nicht an, dass jede Version eine URL mit Anmeldedaten überall akzeptiert, wo ein Proxy-Hostname verlangt wird, und bearbeiten Sie keine globale Makrodatei einer Distribution, nur weil eine alte Antwort es so gemacht hat.
Bestimmen Sie die Fehlerstufe: Konnte der Abruf den Proxy erreichen, wurde die Authentifizierung akzeptiert und gab der Paketendpunkt die beabsichtigte Datei zurück? Ein späterer Signatur- oder Abhängigkeitsfehler ist ein anderes Problem als eine hängende Proxyverbindung.
Bewahren Sie die normale Paketprüfung. Ein funktionierender Downloadweg ist kein Grund, Signaturprüfungen abzuschalten, eine nicht vertrauenswürdige Datei zu installieren oder einen erfolgreichen DNF-Befehl als Beweis zu werten, dass dieser RPM-Abruf denselben Weg genommen hat.