টার্মিনালে ডাউনলোড কাজ করে, কিন্তু VPN-এ VS Code এক্সটেনশন ব্যর্থ হয়

কন্টেইনার টার্মিনালে সফল হওয়া ডাউনলোড ওই টার্মিনালের পরিবেশ সম্পর্কে বাস্তব প্রমাণ। সেগুলো এডিটর প্রসেস, এক্সটেনশন ইনস্টলার বা এক্সটেনশন পরে যে বাইনারি নামায় তা নিয়ে কিছুই বলে না। ওই তিনটির মধ্যে প্রক্সি ভেরিয়েবল কপি করা একটি ব্যর্থ অনুরোধকে সম্পর্কহীন সম্পাদনার এক বিকেলে পরিণত করে।

দুটি পরিবেশ সাধারণত ঠিক একটি দিকেই আলাদা হয়। সেই দিকটি খুঁজে পাওয়া প্রক্সি ডকুমেন্টেশন দুবার পড়ার চেয়ে দ্রুত।

কোন প্রসেস ব্যর্থ অনুরোধটি করেছিল

একটি ইনস্টলের সময় তিনটি অনুরোধ ব্যর্থ হতে পারে, আর প্রতিটির নিজস্ব নেটওয়ার্ক পরিচয় আছে। এডিটর Marketplace-এর কাছে মেটাডেটা ও প্যাকেজ URL চায়, তারপর প্যাকেজটি নামায়। কেবল তারপরই এক্সটেনশন হোস্ট এমন কোড চালায় যা একটি ভাষা সার্ভার বা নিজস্ব বাইনারি আনতে পারে। কোন ধাপটি ভেঙেছে তা ঠিক করে কোন প্রসেসের প্রক্সি দরকার, আর ত্রুটির পৃষ্ঠা ধাপটির নাম খুব কমই বলে।

কাজ করা টার্মিনাল প্রমাণ করে কন্টেইনার ইন্টারনেটে পৌঁছাতে পারে, এডিটর পারে তা নয়। এক্সটেনশন লগে শেষ যে URL-টি এটি চেষ্টা করেছিল তা পড়ুন। সেখানে উল্লিখিত হোস্ট প্রসেসটি এবং তার উপর প্রযোজ্য নীতি চিহ্নিত করে।

স্থানীয় এডিটর ও দূরবর্তী কন্টেইনার দুইটি আলাদা পরিবেশ

দূরবর্তী ওয়ার্কস্পেসে একটি এক্সটেনশন তার ধরন যে দিকে ঘোষণা করে সেদিকেই চলে। ইন্টারফেস এক্সটেনশন স্থানীয় এডিটরের সঙ্গে থাকে, আর ওয়ার্কস্পেস এক্সটেনশন কন্টেইনারে চলে। একটিতে সেট করা প্রক্সি অন্যটির কাছে অদৃশ্য, এবং পুনর্নির্মাণ কন্টেইনার পরিবেশটি তার কনফিগারেশন ফাইল থেকে তৈরি করে, আপনি শেলে যা এক্সপোর্ট করেছেন তা থেকে নয়। এই বিভাজন ব্যাখ্যা করে কেন একই এক্সটেনশন ল্যাপটপে ইনস্টল হয় আর SSH-এ একই প্রকল্পে ব্যর্থ হয়।

কিছু সম্পাদনা করার আগে ইনস্টলের অবস্থান পড়ুন। লগ যখন দূরবর্তী ইনস্টলের কথা বলে, তখন কন্টেইনারের পরিবেশটিই প্রাসঙ্গিক।

অনুরোধ যেখানে শুরু হয় সেখানে প্রক্সি রাখুন

সত্যিই HTTP প্রক্সি দরকার এমন Dev Container-এর জন্য ভেরিয়েবলটি কন্টেইনার কনফিগারেশনে থাকা উচিত, যাতে পুনর্নির্মাণ এটি পুনরুৎপাদন করে। নিচের খণ্ডটি সেই পরিবেশের জন্য এটি সেট করে। প্লেসহোল্ডার ঠিকানাটি আপনার নিজের গেটওয়ের প্রতিনিধি, আর বাদগুলো ঐচ্ছিক প্যাডিং নয়।

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

ভেরিয়েবলের নামটি গন্তব্য প্রোটোকল বর্ণনা করে, তাই HTTPS_PROXY-এর মান বৈধভাবে http দিয়ে শুরু হতে পারে। সমর্থিত পুনর্নির্মাণ পথে পরিবর্তনটি প্রয়োগ করুন এবং বাদগুলো রাখুন, কারণ অভ্যন্তরীণ হোস্ট আটকানো প্রক্সি কন্টেইনারের প্রয়োজনীয় সেবা ভেঙে দেয়।

বিশ্বাসের ব্যর্থতা ও পৌঁছানোর সক্ষমতা আলাদা করুন

যে প্রক্সি সংযোগ করে তারপর সার্টিফিকেট যাচাইয়ের ত্রুটি ফেরায়, সেটি সংযোগ প্রত্যাখ্যানকারীর চেয়ে পরবর্তী ধাপে পৌঁছেছে। প্রথম ব্যর্থতার জন্য সংস্থার অনুমোদিত বিশ্বাস উপাদান যে পরিবেশ অনুরোধটি করে সেখানে ইনস্টল থাকা দরকার। দ্বিতীয়টির জন্য দরকার পৌঁছানোযোগ্য ঠিকানা ও পোর্ট। দুটিকে এক সমস্যা হিসেবে দেখলে এমন সমাধান আসে যা কোনোটির জন্যই কাজ করে না।

যাচাই বন্ধ করা, বা উন্নত অধিকার নিয়ে এডিটর চালানো, অনুপস্থিত প্রক্সি বা অনুপস্থিত বিশ্বাস-শৃঙ্খলের মেরামত নয়। দুটোই দৃশ্যমান ত্রুটির বিনিময়ে নীরব ত্রুটি দেয়। এরপর একই এক্সটেনশন আবার চেষ্টা করুন এবং পরের যে URL ব্যর্থ হয় তা টুকে রাখুন।

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

ওয়ার্কস্পেসের কোন দিকটি ওই URL তৈরি করেছিল তা লিখে রাখুন। ধাপ, হোস্ট ও দিকের নাম দেওয়া একটি ছোট টীকা কেউ বদলে ফেলা সেটিংসের তালিকার চেয়ে বেশি মূল্যবান, কারণ পরের ব্যক্তি সেই টীকাটিই পুনরুৎপাদন করতে পারবে।