VPN टूल की सेटिंग्स: लॉन्च के समय का वातावरण या हुक में एक्सपोर्ट?
हुक अपने खुद के चाइल्ड प्रोसेस शुरू करता है, वह शेल नहीं जो आप पहले से खोल चुके हैं। लॉन्च के समय का वातावरण निजी एंडपॉइंट को सिर्फ़ उसी एक कमांड पर रखता है जिसे उसकी ज़रूरत है।
API एंडपॉइंट एक्सपोर्ट करने वाला VPN हुक उन प्रोसेस का वातावरण बदलता है जिन्हें वह शुरू करता है, उस टर्मिनल का नहीं जो टनल उठते समय पहले से खुला था। यही एक अंतर «टूल अब भी सार्वजनिक एंडपॉइंट को कॉल कर रहा है» वाली ज़्यादातर रिपोर्ट समझाता है। सेटिंग रखने की दो व्यावहारिक जगहें हैं, और चुनाव इस पर निर्भर करता है कि इसे कौन इस्तेमाल करता है और यह कितनी बार बदलती है। एक और स्टार्टअप स्क्रिप्ट जोड़ने से पहले दोनों की तुलना करें।
सेटिंग रह सकती है ऐसी दो जगहें
पहला विकल्प कमांड पर ही एक प्रीफ़िक्स है: मान सिर्फ़ उसी एक कॉल के लिए होता है और उसके साथ गायब हो जाता है। दूसरा विकल्प कनेक्शन हुक के अंदर एक्सपोर्ट है, जो उस बिंदु के बाद हुक जो भी प्रोसेस शुरू करता है, हर एक तक पहुँचता है। ये पहुँच और जीवनकाल में अलग हैं, सिंटैक्स में नहीं, और यही अंतर ज़्यादातर विफलताएँ तय करता है।
| Property | Prefix on the command | Export from the hook |
|---|---|---|
| Who receives it | That invocation only | Children the hook starts |
| Lifetime | Until the process exits | Until the hook's own session ends |
| Leakage | Scoped to one command | Applies to later commands in that session |
| Repeat cost | Every invocation | Once per connection |
| Works for an open editor | No, unless the editor is started with it | No |
तालिका हुक को सस्ता दिखाती है और असली बिल छिपाती है: यह उन कमांड के लिए भी निजी एंडपॉइंट चुनती है जिनका काम से कोई संबंध नहीं है। हर पंक्ति को पसंद नहीं, बाध्यता की तरह पढ़ें। अगर एंडपॉइंट हर काम के साथ बदलता है, तो एक कीस्ट्रोक की क़ीमत चुकाकर भी प्रीफ़िक्स सटीकता में जीतता है।
हुक पहले से खुले शेल तक क्यों नहीं पहुँच सकता
प्रोसेस की इमेज बनते समय एनवायरनमेंट वेरिएबल प्रोसेस को दिए जाते हैं। कनेक्शन से पहले शुरू हुआ शेल अपनी मिली नकल रखता है, और हुक के अंदर चलाया गया एक्सपोर्ट मशीन की हर प्रोसेस में प्रसारण नहीं है। सिर्फ़ हुक के अपने चाइल्ड इसे विरासत में पाते हैं। शेल के अपने चाइल्ड वह लेते हैं जो शेल के पास उनके शुरू होने के क्षण में है, इसीलिए एक ही कमांड एक टर्मिनल में काम कर सकता है और दूसरे में विफल रह सकता है।
यही बात ग्राफ़िकल एडिटर पर भी लागू होती है। इसका एक्सटेंशन होस्ट, अंतर्निहित टर्मिनल और पृष्ठभूमि का भाषा सर्वर लॉन्च के समय अलग हुए थे और अपनी नकलें रखते हैं। फ़ोल्डर दोबारा खोलने से वे चाइल्ड ज़रूरी नहीं कि फिर शुरू हों, इसलिए आपकी जोड़ी सेटिंग फिर भी कभी नहीं पहुँचती।
सबसे सस्ता परीक्षण यह है कि वेरिएबल उस जगह से छापें जहाँ विफलता होती है, उस शेल से नहीं जो काम करता है। अगर विफल होने वाली प्रोसेस टनल से पहले शुरू हुई थी, तो एक्सपोर्ट के पास कोई मौक़ा नहीं था।
प्रति-कमांड रूप, लिखा हुआ
प्रीफ़िक्स चुनाव को उसी कमांड में दिखाई देता रखता है जो इसे इस्तेमाल करता है, जो तब मदद करता है जब एंडपॉइंट कामों के बीच बदलता है:
env INTERNAL_API='https://internal-api.example.net:8443' my-work-toolकमांड उदाहरण मात्र है: my-work-tool एक प्लेसहोल्डर है और INTERNAL_API कोई VPN मानक नहीं है, इसलिए उस प्रोग्राम की प्रलेखित सेटिंग डालें जिसे आप वास्तव में चलाते हैं और अपना स्वीकृत होस्ट। एक ही पंक्ति में टोकन या पासवर्ड न रखें, क्योंकि वह शेल के इतिहास में चला जाता है।
जब कई कमांड एक ही काम के हों, तो एक छोटी समीक्षित रैपर स्क्रिप्ट वेरिएबल सेट करती है और फिर उन्हें शुरू करती है। इससे एक ही परिभाषा बनी रहती है, बिना मान को टर्मिनल की हर भावी कमांड के लिए वैश्विक बनाए।
फिर से लोड करें, फिर से शुरू करें या छोड़ दें
पहले से चल रहे टूल के लिए, उसका अपना पुनःलोड या वर्कस्पेस प्रोफ़ाइल हो तो उसे प्राथमिकता दें। वरना काम सहेजें और वह घटक फिर से शुरू करें जो सेटिंग पढ़ता है, जो अक्सर भाषा सर्वर होता है, एडिटर की विंडो नहीं। विंडो फिर से शुरू करके यह मानना कि चाइल्ड प्रोसेस उसके पीछे आ गए, वही कारण है जिससे पुनःलोड काम न करता हुआ दिखता है।
डिस्कनेक्शन एक अलग निर्णय है। रोकना, बंद करना या फिर से जुड़ना एप्लिकेशन का काम है, और एंडपॉइंट वेरिएबल इसे नियंत्रित नहीं करता। वेरिएबल को ऐसी कॉन्फ़िगरेशन मानें जो पता चुनती है, न कि इस बारे में नियम कि बाद में कौन-सा नेटवर्क ट्रैफ़िक इस्तेमाल हो सकता है, और दोनों मामले अलग-अलग रहते हैं।