URL-आधारित पैकेज डाउनलोड के लिए RPM प्रॉक्सी विकल्प
जब कोई सीधा दूरस्थ पैकेज कमांड DNF से अलग व्यवहार करे, तो RPM के अपने URL-फ़ेच प्रॉक्सी विकल्प जाँचें।
rpm -Uvh https://packages.example.net/example.rpm में नेटवर्क से फ़ेच करने का चरण शामिल है। पैकेज का सत्यापन या इंस्टॉलेशन करने से पहले RPM को फ़ाइल प्राप्त करनी होती है।
कार्यशील DNF प्रॉक्सी कॉन्फ़िगरेशन उस अलग कॉल द्वारा उपयोग की जाने वाली सेटिंग्स तय नहीं करता। RPM का मैनुअल अपने HTTP पुनर्प्राप्ति पथ के लिए --httpproxy और --httpport का दस्तावेज़ीकरण करता है। इंस्टॉल किया गया RPM संस्करण और उसके URL सहायक की व्यवस्था विवरण तय करती है। RPM 6 का सामान्य-विकल्प संदर्भ इन नेटवर्क-फ़ेच विकल्पों को अप्रचलित बताता है और इसके बजाय curl या GNU Wget जैसे समर्पित फ़ेच टूल की सलाह देता है।
आप जिस कार्यप्रवाह को बनाए रख रहे हैं, उसके लिए पहले तय करें कि कौन-सी परत URL फ़ेच करती है। नए कार्यप्रवाह के लिए, स्पष्ट रूप से स्वीकृत डाउनलोड और उसके बाद स्थानीय पैकेज सत्यापन व इंस्टॉलेशन इन अप्रचलित फ़ेच विकल्पों पर निर्भरता से बचाता है।
फ़ील्ड्स को उनके दस्तावेज़ित प्रारूप में रखें। यह न मानें कि हर संस्करण प्रॉक्सी होस्टनाम माँगे जाने वाले हर स्थान पर क्रेडेंशियल वाला URL स्वीकार करता है, और केवल इसलिए किसी डिस्ट्रीब्यूशन की वैश्विक मैक्रो फ़ाइल संपादित न करें कि किसी पुराने उत्तर ने ऐसा किया था।
विफलता का चरण पहचानें: क्या फ़ेच प्रॉक्सी तक पहुँच सका, प्रमाणीकरण स्वीकार हुआ, और पैकेज एंडपॉइंट ने इच्छित फ़ाइल लौटाई? बाद में आने वाली हस्ताक्षर या निर्भरता त्रुटि अटकी हुई प्रॉक्सी कनेक्शन से भिन्न समस्या है।
सामान्य पैकेज सत्यापन बनाए रखें। डाउनलोड मार्ग को कार्यशील बनाना हस्ताक्षर जाँच बंद करने, अविश्वसनीय फ़ाइल इंस्टॉल करने या सफल DNF कमांड को इस बात का प्रमाण मानने का कारण नहीं है कि इस RPM फ़ेच ने वही मार्ग अपनाया।