pull-filter टेक्स्ट का मिलान करता है, सबनेट का नहीं: इसे प्रीफ़िक्स की तरह पढ़ें

इरादा एक भेजा गया रूट हटाने का था। बदलाव के बाद कोई दूसरा रूटिंग विकल्प ग़ायब है, या क्लाइंट लूप में फिर से जुड़ता है। दोनों नतीजे फ़िल्टर को सबनेट नियम के रूप में पढ़ने से आते हैं, जबकि वह टेक्स्ट की तुलना करता है। क्लाइंट देखता है कि कोई भेजा गया विकल्प आपके दिए अक्षरों से शुरू होता है या नहीं, और किसी भी चरण में पते का तर्क शामिल नहीं है।

फ़िल्टर वास्तव में क्या तुलना करता है

हर भेजा गया विकल्प एक नाम और उसके आर्ग्युमेंट से बनी पंक्ति के रूप में आता है। फ़िल्टर आपके अक्षरों की तुलना उस पंक्ति की शुरुआत से करता है, किसी पते के पार्स होने से पहले और किसी रूट के इंस्टॉल होने से पहले। इसलिए किसी नाम के लिए लिखा नियम उन अक्षरों से शुरू होने वाले हर विकल्प को पकड़ता है, केवल उसे नहीं जिसे आप देख रहे थे। इसी कारण फ़िल्टर अलग से सही दिख सकता है और फिर भी कुछ असंबंधित हटा सकता है।

नेटवर्क रेंज जैसी दिखने वाली स्ट्रिंग फिर भी केवल अक्षर हैं। वह कोई प्रीफ़िक्स नहीं चुनती, नेटवर्क बिट्स पर कोई गणना नहीं करती और गंतव्यों का समूह नहीं बता सकती। जब ऐसा नियम काम करता दिखे और बाद में रुक जाए, तो भेजा गया टेक्स्ट आमतौर पर आकार बदल चुका होता है।

एक जगह मिलान का समूह बदल देती है

वही विकल्प नाम अंत में विभाजक के साथ और उसके बिना अलग-अलग पंक्तियाँ चुनता है। विभाजक के बिना मिलान खुला रहता है, जबकि उसके साथ आर्ग्युमेंट शुरू होने से पहले विकल्प नाम ठीक वहीं ख़त्म होना चाहिए।

pull-filter ignore "route"
pull-filter ignore "route "

खुली रूप वाले मिलान में वे विकल्प भी आते हैं जो केवल उन्हीं अक्षरों से शुरू होते हैं, और इस तरह असंबंधित रूटिंग व्यवहार उस रूट के साथ ही ग़ायब हो जाता है जिसे आप हटाना चाहते थे। फ़िल्टर लिखने से पहले लॉग से भेजी गई पंक्ति कॉपी करें। संपादित प्रोफ़ाइल के साथ बिना बदले हुए प्रोफ़ाइल की प्रतिलिपि रखें, क्योंकि व्यापक मिलान को फ़ाइल से पलटना याददाश्त से आसान है।

क्रम और क्रिया अलग लक्षण पैदा करते हैं

नियम क्रम में आँके जाते हैं और पहला मिलान नतीजा तय करता है, इसलिए जल्दी रखा व्यापक नियम हर बाद के विशिष्ट नियम को अगम्य बना देता है। क्रिया भी ख़राबी बदलती है: मिलान को नज़रअंदाज़ करने पर विकल्प हट जाता है और सत्र जारी रहता है, जबकि अस्वीकार करने पर ऐसी त्रुटि उठती है जो कनेक्शन फिर शुरू कर देती है। इसलिए बार-बार भेजी जाने वाली पंक्ति अस्वीकार करने वाली क्रिया के साथ मिलकर पुनः कनेक्शन का चक्र बनाती है। उस चक्र को नेटवर्क ख़राबी समझ लेना आसान है, और मिले हुए विकल्प का नाम बताने वाली लॉग पंक्ति ही दोनों को अलग करती है।

नोट करें कि कौन-सी पंक्ति मिली और कौन-सी क्रिया चली। हटाया गया रूट और पुनः शुरू होने का चक्र अलग मरम्मत चाहते हैं, और नोट को बताना चाहिए कि दोनों में से क्या हुआ, बजाय दोनों को खुला छोड़ने के।

देखें कि होस्ट ने क्या इंस्टॉल किया

फिर से जुड़ने के बाद लागू किए गए रूट पढ़ें और उस गंतव्य को भी जाँचें जिसे आप बनाए रखना चाहते थे तथा उसे भी जिसे हटाना चाहते थे। भेजा गया रूट हटाने से कोई विकल्प नहीं मिलता, इसलिए अवांछित रूट चले जाने के बाद कोई संसाधन दूसरे रास्ते से अगम्य हो सकता है। यदि कोई नाम अब कहीं और हल होता है, तो देखें कि भेजा गया रिज़ॉल्वर विकल्प उसी व्यापक प्रीफ़िक्स में पकड़ा गया है या नहीं। जो बदलाव आपकी चलाई परीक्षा पास करे पर जिस परीक्षा का इरादा था उसमें असफल हो, यहाँ वही सामान्य नतीजा है।

वह अंतर टिकट में रखें: जो रूट आपने हटाया, जो रूट आप बनाए रखने की उम्मीद कर रहे थे, और तालिका अब क्या दिखा रही है। अगला बदलाव उसी रिकॉर्ड के आधार पर आँका जाएगा।

इसे भरोसे की सीमा न मानें

टेक्स्ट पर फ़िल्टर कॉन्फ़िगरेशन की सुविधा है, उस सर्वर के विरुद्ध नियंत्रण नहीं जिस पर आप भरोसा नहीं करते। केवल फ़ॉर्मैट के भेद ही इसे हरा देते हैं, इसीलिए मैनुअल उस दावे को सीमित रखता है। जब सर्वर आपके संगठन का हो, तो स्थानीय अपवाद जमा करने के बजाय पुश नीति सुधारना अधिक स्पष्ट है।

लिखें कि स्थानीय फ़िल्टर आख़िर क्यों मौजूद है, ताकि अगला व्यक्ति तय कर सके कि इसकी अब भी ज़रूरत है या नहीं। कारण ख़त्म होने के बहुत बाद तक फ़िल्टर जमा होते रहते हैं।