pull-filter ले पाठ मिलाउँछ, सबनेट होइन: यसलाई उपसर्गका रूपमा पढ्नुहोस्

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

फिल्टरले वास्तवमा के तुलना गर्छ

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

नेटवर्क दायराजस्तो देखिने स्ट्रिङ अझै पनि केवल अक्षर हो। यसले कुनै उपसर्ग छान्दैन, नेटवर्क बिटमा गणना गर्दैन र गन्तव्यहरूको समूह व्यक्त गर्न सक्दैन। यस्तो नियम काम गरिरहेको देखिएर पछि रोकिएमा, धकेलिएको पाठले सामान्यतया आकार बदलेको हुन्छ।

एउटा खाली ठाउँले मिलान समूह बदल्छ

उही विकल्प नाम अन्तिम विभाजकसहित र त्यसबिना फरक लाइन छान्छ। विभाजकबिना मिलान खुला रहन्छ, विभाजकसहित भने आर्गुमेन्ट सुरु हुनुअघि विकल्प नाम ठ्याक्कै त्यहीँ अन्त्य हुनुपर्छ।

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

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

क्रम र कार्यले फरक लक्षण उत्पन्न गर्छन्

नियमहरू क्रममा मूल्याङ्कन हुन्छन् र पहिलो मिलानले परिणाम तय गर्छ, त्यसैले चाँडै राखिएको फराकिलो नियमले पछिका प्रत्येक विशिष्ट नियमलाई पहुँचविहीन बनाउँछ। कार्यले पनि दोष बदल्छ: मिलान बेवास्ता गर्दा विकल्प हट्छ र सत्र जारी रहन्छ, तर अस्वीकार गर्दा जडान पुनः सुरु गर्ने त्रुटि उठ्छ। त्यसैले बारम्बार धकेलिने लाइन अस्वीकार गर्ने कार्यसँग मिलेर पुनःजडान चक्र बनाउँछ। त्यो चक्रलाई नेटवर्क दोषका रूपमा पढ्न सजिलो हुन्छ, र मिलेको विकल्पको नाम दिने लग लाइनले दुवैलाई छुट्याउँछ।

कुन लाइन मिल्यो र कुन कार्य चल्यो लेख्नुहोस्। हटाइएको मार्ग र पुनः सुरु हुने चक्रले फरक मर्मत चाहन्छ, र टिप्पणीले दुवै खुला छोड्नुको सट्टा कुन भयो भन्नुपर्छ।

होस्टले के इन्स्टल गरेको छ जाँच्नुहोस्

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

त्यो फरक टिकटमा राख्नुहोस्: तपाईंले हटाएको मार्ग, जोगाउने अपेक्षा गरेको मार्ग, र तालिकाले अहिले के देखाउँछ। अर्को परिवर्तन त्यही अभिलेखका आधारमा मूल्याङ्कन हुनेछ।

यसलाई विश्वासको सीमा नमान्नुहोस्

पाठमाथिको फिल्टर कन्फिगरेसनको सुविधा हो, तपाईं विश्वास नगर्नुहुने सर्भरविरुद्धको नियन्त्रण होइन। केवल ढाँचाका भिन्नताले यसलाई हराउँछन्, त्यसैले पुस्तिकाले त्यो दाबी सीमित गर्छ। सर्भर तपाईंको संस्थाको हुँदा स्थानीय अपवाद जम्मा गर्नुभन्दा पुश नीति सुधार्नु स्पष्ट हुन्छ।

स्थानीय फिल्टर किन अस्तित्वमा छ लेख्नुहोस्, ताकि अर्को व्यक्तिले यसको अझै आवश्यकता छ कि भनेर निर्णय गर्न सकोस्। कारण सकिएको धेरैपछि पनि फिल्टरहरू थुप्रिन्छन्।