VPN जोडले जाते, अंतर्गत विकी ब्राउझरमध्ये लोड होते, आणि apt update अजूनही ज्या मिररवर पोहोचू शकत नाही त्यावर अडकलेले असते। त्या चित्रात बोगद्यात काहीही तुटलेले नाही। ब्राउझर आणि पॅकेज मॅनेजरने प्रॉक्सीचे दोन वेगवेगळे निर्णय घेतले, आणि त्यांपैकी फक्त एकच कॉन्फिगर केलेला होता।

कोणता निर्णय अयशस्वी झाला, हेच आधी ठरवण्यासारखी एकमेव गोष्ट आहे।

सेटिंगला हात लावण्यापूर्वी त्रुटी वाचा

प्रत्येक टप्पा वेगळा संदेश सोडतो। जे नाव कधीच सुटत नाही ते DNS, जे कनेक्शन कधीच पूर्ण होत नाही ते राउटिंग किंवा फायरवॉल, लगेच मिळणारा 407 प्रॉक्सी प्रमाणीकरण, प्रमाणपत्राबद्दलची तक्रार TLS पडताळणी, आणि स्वाक्षरीची चेतावणी रेपॉझिटरी मेटाडेटा। या पाच बिघडलेल्या गोष्टींसाठी पाच वेगळ्या दुरुस्त्या लागतात, आणि DNS समस्येवर चिकटवलेली प्रॉक्सी ओळ फक्त अडकण्याची जागा बदलते।

काहीही बदलण्यापूर्वी ती नेमकी ओळ आणि ती नाव देते ती रेपॉझिटरी कॉपी करा। „वेळ संपला“ अशी अस्पष्ट आठवण दहा मिनिटांच्या निदानाचे पूर्ण दुपारीत रूपांतर करते।

APT स्वतःच्या वेगळ्या प्रॉक्सी सेटिंग्ज ठेवते

APT /etc/apt/apt.conf.d/, मुख्य apt.conf आणि APT_CONFIG ने नाव दिलेली कोणतीही फाइल वाचते। ते डेस्कटॉप प्रॉक्सी प्रोफाइल, GNOME नेटवर्क सेटिंग किंवा ब्राउझर एक्स्टेंशन वाचत नाही। ट्रान्सपोर्ट मात्र प्रॉक्सी पर्यावरण चलांचे पालन करतो, म्हणून तुमच्या शेलमध्ये चालणारे export https_proxy=... दुसऱ्या पर्यावरणात चालणाऱ्या टाइमरबद्दल काहीही सिद्ध करत नाही।

अयशस्वी होणारी प्रक्रिया प्रत्यक्षात काय पाहते ते डंप करा: apt-config dump | grep -i proxy।

हे ज्या वापरकर्त्याखाली अयशस्वी क्रिया चालते त्याच्या रूपात चालवा। जर root दुसरा फाइलसंच वाचत असेल, किंवा systemd टाइमर दुसऱ्या पर्यावरणासह सुरू होत असेल, तर डंप वेगळा असेल, आणि तोच फरक तुमचे उत्तर आहे। दोन परस्परविरोधी प्रॉक्सी मूल्ये एका गहाळ मूल्यापेक्षा वाईट आहेत, कारण ट्रान्सपोर्ट सर्वात विशिष्ट जुळणीचे अनुसरण करतो।

प्रॉक्सी तिथे सेट करा जिथे कॉन्फिगरेशनचा मालक त्याची अपेक्षा करतो

प्रशासकाने मंजूर केलेल्या स्पष्ट प्रॉक्सीसाठी नवीन फाइलमधला छोटा तुकडा पुरेशी आहे:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

तिसरी ओळ हा तो भाग आहे जो बहुतेक उदाहरणे वगळतात। प्रति-होस्ट की सामान्य मूल्याला मागे टाकते, त्यामुळे बोगद्यातून पोहोचणारा अंतर्गत मिरर प्रॉक्सी वगळू शकतो जेव्हा बाकी सर्व अजूनही त्यातूनच जाते। DIRECT त्यासाठीचे दस्तऐवजीकृत मूल्य आहे, रिकामी स्ट्रिंग नाही।

तुकडा नवीन क्रमांकित फाइल म्हणून जोडा, उदाहरणार्थ /etc/apt/apt.conf.d/95proxy। वितरणाची फाइल ओव्हरराइट करणे म्हणजे पुढील पॅकेज अपडेट तुमचा बदल शांतपणे परत करेल।

क्रेडेन्शियल्स URI बाहेर राहतात

APT ट्रान्सपोर्ट संदर्भ प्रमाणीकरणासाठी apt_auth.conf कडे निर्देश करतो, आणि वापरकर्तानाव व पासवर्ड तिथेच जातात। ते प्रॉक्सी URI मध्ये एम्बेड केल्यास प्रक्रिया याद्या, शेल इतिहास आणि तिकिटात चिकटवलेल्या प्रत्येक कॉन्फिगरेशन डंपमध्ये पोहोचतात। प्रमाणीकरण फाइलला कडक परवानग्या लागतात, कारण ती क्रेडेन्शियल्सचा साठा आहे।

स्कीमही तपासा। HTTPS रेपॉझिटरीपर्यंत अजूनही HTTP प्रॉक्सीने पोहोचता येते; ट्रान्सपोर्ट मिररच्या URI स्कीमपेक्षा वेगळी निवड आहे।

ग्राफिकल सॉफ्टवेअर केंद्र वेगळा फ्रंट एंड आहे। जर ते PackageKit किंवा snap बॅकएंड वापरत असेल, तर APT चा तुकडा त्याच्यासाठी काहीही बदलत नाही, म्हणून अयशस्वी विनंती कोणत्या प्रक्रियेने केली हे तपासा।

मार्गाची खात्री करा, फक्त निर्गम कोडची नाही

तुकडा बसल्यावर हिरव्या निकालावर विश्वास ठेवण्याऐवजी विनंती पाहा। apt-get -o Debug::Acquire::http=true update कनेक्शनचा प्रयत्न, निवडलेली प्रॉक्सी आणि प्रतिसाद कोड छापते, जे चुकीच्या प्रॉक्सीला तुम्हाला नाकारणाऱ्या प्रॉक्सीपासून वेगळे करते।

मग जी परिस्थिती चालू नये ती तपासा। VPN तोडा आणि अंतर्गत मिरर उत्तर देणे थांबवतो याची खात्री करा; जर तो अजूनही डाउनलोड करत असेल, तर काहीतरी बोगद्याच्या बाजूने मार्गस्थ करत आहे किंवा जुना कॅश तुम्हाला सेवा देत आहे। मंजूर मार्ग अजूनही TLS पडताळतो आणि अजूनही रेपॉझिटरीच्या स्वाक्षऱ्या तपासतो याची खात्री करा, कारण रहदारी तपासणारी प्रॉक्सी यांपैकी काहीही बंद करण्याचे कारण नाही। तसेच अप्रमाणित क्लायंटला शांत कालबाह्यतेऐवजी स्पष्ट नकार मिळतो याची खात्री करा।

चालू तुकडा आणि अयशस्वी आउटपुट बदल नोंदीत एकत्र ठेवा। पुढच्या वेळी तोच अडकाट सहन करणारी व्यक्ती दोन ओळींचा फरक कोणत्याही स्पष्टीकरणापेक्षा वेगाने ओळखेल।

संबंधित लेख