सफल दर्ताले सदस्यता सेवामा पहुँच मात्र पुष्टि गर्छ। DNF रिपोजिटरी मेटाडेटा र प्याकेज डाउनलोडले फरक सेटिङ र होस्टनाम प्रयोग गर्न सक्ने हुँदा रिपोजिटरी ID, प्रभावकारी URL र असफल कार्यको पहिलो त्रुटिबाट सुरु गर्नुहोस्।

subscription-manager का लागि, /etc/rhsm/rhsm.conf को सर्भर खण्डले छुट्टै फिल्ड प्रयोग गर्छ:

[server]
proxy_hostname = proxy.example.net
proxy_port = 8080
proxy_user = service-account
proxy_password = REPLACE_WITH_MANAGED_SECRET

यी मानहरू विद्यमान कन्फिगरेसनमा बदल्नुहोस् र वास्तविक गोप्य कुरा भएको फाइल सुरक्षित राख्नुहोस्। proxy_hostname ले होस्टनाम लिन्छ, प्रमाणहरू सहितको पूरा URL होइन।

DNF का लागि, प्रभावित रिपोजिटरी र मुख्य कन्फिगरेसन जाँच्नुहोस्। यसको proxy विकल्प एउटा URL हो; proxy_username, proxy_password र proxy_auth_method छुट्टाछुट्टै विकल्प हुन्। एउटा रिपोजिटरीले विश्वव्यापी मानलाई अगाडि बढाउन सक्छ। प्रोक्सी विकल्प नभएमा वातावरणमा खोज्न अनुमति दिन सकिन्छ, जबकि स्पष्ट रूपमा खाली मानले त्यो खण्डका लागि कन्फिगर गरिएको अभिभावक मान अक्षम गर्छ। स्थापित DNF पुस्ताको सन्दर्भ पालना गर्नुहोस्। DNF 4 का लागि: रिपोजिटरी वंशानुक्रमलाई वातावरण बाइपास नियमबाट अलग गर्नुहोस्।

रिपोजिटरी फाइल सदस्यता उपकरणले बनाएको भए, सम्पादन गर्नुअघि त्यो मालिक पहिचान गर्नुहोस्। रिफ्रेसमा पुनःलेखिने परिवर्तन समर्थित कन्फिगरेसन स्रोतमा हुनुपर्छ, आउटपुट फाइलको बारम्बार मर्मतमा होइन।

त्यसपछि पहिलो असफलताको वर्गीकरण गर्नुहोस्। प्रोक्सीसँगको जडान दुवै सेवाको खाता जाँचभन्दा अघि आउँछ। 407 ले प्रोक्सी प्रमाणीकरण माग्छ; TLS त्रुटि असफल हुँदै गरेको जडानको विश्वाससँग सम्बन्धित छ; मूलबाट अस्वीकृति सदस्यता वा रिपोजिटरी पहुँचसँग सम्बन्धित छ। प्याकेज CDN होस्टहरू दर्ता होस्टहरूभन्दा फरक हुन सक्छन्, त्यसैले एउटाका लागि अनुमति सूचीले अर्कोमा पहुँच स्थापित गर्दैन।

प्रत्येक तुलनामा प्रभावकारी अन्त्यबिन्दु, छानिएको प्रोक्सी र खाता पहिचानकर्ता राख्नुहोस्, गोप्य कुरा बाहेक। rhn_register र /etc/sysconfig/rhn/up2date भएका पुराना विधिहरूले अर्को उपकरण पुस्ताको वर्णन गर्छन् र वर्तमान RHSM वा DNF अनुरोधका सेटिङ पहिचान गर्दैनन्।

सम्बन्धित लेखहरू