Red Hat کی رجسٹریشن کام کرتی ہے، لیکن DNF پراکسی ڈاؤن لوڈز ناکام ہوتے ہیں

کامیاب رجسٹریشن صرف سبسکرپشن سروس تک رسائی کی تصدیق کرتی ہے۔ 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 درخواست کی سیٹنگز کی نشاندہی نہیں کرتے۔