कंटेनर में vpnc रूट-फ्लश चेतावनी क्यों आती है
रूट कैश फ्लश उस कर्नेल का अवशेष है जो अब वह कैश नहीं रखता; केवल-पढ़ने वाली त्रुटि टनल से नहीं, कंटेनर के माउंट से आती है।
नए कंटेनर लॉग अक्सर /proc/sys/net/ipv4/route/flush के बारे में Read-only file system शिकायत पर समाप्त होते हैं, और उस पंक्ति पर ऐसी टनल का दोष मढ़ा जाता है जो पूरी तरह स्वस्थ हो सकती है। उसके पीछे का लेखन कर्नेल की उस प्रविष्टि को लक्षित करता है जो IPv4 रूट कैश जाने के बाद अब कोई उपयोगी काम नहीं करती। कंटेनर के अंदर /proc/sys केवल-पढ़ने के रूप में माउंट होता है, इसलिए कोई मान पहुँचने से पहले ही रीडायरेक्शन अस्वीकार कर दिया जाता है और शेल वह अस्वीकृति छापता है। काम करने वाली टनल तब तक यह चेतावनी छाप सकती है जब तक पुरानी पंक्ति स्क्रिप्ट में रहती है, और --privileged लेखन को कभी सार्थक नहीं बनाता।
स्क्रिप्ट क्या फ्लश करना चाहती थी
पुरानी कनेक्शन स्क्रिप्ट कैश सफ़ाई के साथ समाप्त होती थीं: कर्नेल की नियंत्रण फ़ाइल में मान लिखना और IPv4 स्टैक से अपना राउटिंग कैश छोड़ने को कहना, ताकि बासी प्रविष्टियों के पुराने होने की प्रतीक्षा किए बिना नया टनल रूट चुना जाए। फ़ाइल /proc/sys/net/ipv4/ के अंतर्गत संबोधित थी, जिसने क्रिया को राउटिंग कमांड के बजाय शेल रीडायरेक्शन बना दिया। कर्नेल 3.6 ने वह कैश हटा दिया, और उसके साथ फ्लश के होने का कारण भी। मौजूदा डेटा पथ में कुछ भी उस लेखन पर निर्भर नहीं है।
प्रविष्टि स्वयं एक पुरानी केवल-लेखन फ़ाइल के रूप में बची रही, इसलिए जो स्क्रिप्ट अब भी उसमें लिखती है वह वास्तविक पथ और वास्तविक अनुमति-जाँच तक पहुँचती है। होस्ट पर लेखन सफलता लौटाता है और कुछ नहीं बदलता। कंटेनर में वही रीडायरेक्शन केवल-पढ़ने वाले /proc/sys से टकराता है और EROFS के साथ विफल होता है, जिसे शेल केवल-पढ़ने वाले फ़ाइलसिस्टम संदेश के रूप में छापता है। जिन कर्नेल पर पथ वास्तव में अनुपस्थित है वहाँ शब्दावली No such file or directory हो जाती है, और निष्कर्ष नहीं बदलता।
दोनों त्रुटियाँ अलग बातें कहती हैं, और अंतर स्पष्ट रखना उचित है। Read-only file system का अर्थ है कि कर्नेल किसी प्रविष्टि तक पहुँचा और लेखन से इंकार किया; No such file or directory का अर्थ है कि प्रविष्टि चली गई। कोई भी संदेश टनल उपकरण, रूट या नाम-हल के बारे में रिपोर्ट नहीं करता, इसलिए कोई भी अधिक विशेषाधिकार को न्यायसंगत नहीं ठहरा सकता।
क्रम ही संदेश को कारण-जैसा दिखाता है। कनेक्शन स्क्रिप्ट अंत में सफ़ाई तक पहुँचने से पहले रूट स्थापित करती है, इंटरफ़ेस अवस्था बदलती है और नाम-हल फिर से लिखती है, इसलिए अंतिम छपी पंक्ति वही होती है जिसे लोग उद्धृत करते हैं, तब भी जब हर महत्वपूर्ण चरण सफलता लौटा हो। जो टनल स्थापित होती है और यह चेतावनी छापते हुए ट्रैफ़िक ढोती है, वह ऊपर के तंत्र से ठीक मेल खाती है।
विशेषाधिकार जोड़ने से पहले माउंट और रूट जाँचें
तीन पठन सतही चेतावनी को वास्तविक विफलता से अलग करते हैं: क्या स्थापित स्क्रिप्ट अब भी पंक्ति रखती है, /proc/sys कैसे माउंट है, और ऐप्लिकेशन का ट्रैफ़िक वास्तव में कहाँ जाता है। इन्हें उसी कंटेनर नेमस्पेस में या उस होस्ट पर चलाएँ जहाँ चेतावनी दिखी, क्योंकि असंबंधित मशीन पर जाँच किसी दूसरे प्रश्न का उत्तर देती है।
grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10grep का उत्तर जितना दिखता है उससे कमज़ोर है, क्योंकि मिलना यह सिद्ध करता है कि पंक्ति मौजूद है, यह नहीं कि वह बिना रक्षा के चलती है; अनुरक्षित स्क्रिप्ट लेखन को ऐसी रक्षा के भीतर रख सकती है जो उसे छोड़ देती है। findmnt -no OPTIONS /proc/sys माउंट को सीधे तय करता है, और उस आउटपुट में ro का अर्थ है कि उस बिंदु के नीचे हर लेखन अस्वीकार है, स्क्रिप्ट कुछ भी करे। फिर रूट लुकअप दिखाता है कि ऐप्लिकेशन को जरूरी गंतव्य टनल इंटरफ़ेस से हल होता है या कंटेनर के डिफ़ॉल्ट गेटवे से। डिफ़ॉल्ट गेटवे चुनने वाला लुकअप का अर्थ है कि टनल ऊपर आई और उसमें कुछ रूट नहीं हो रहा, जो राउटिंग समस्या है, विशेषाधिकार की नहीं।
सुधार वास्तव में कहाँ से आता है
अनुरक्षित सुधार कंटेनर फ़्लैग में नहीं, स्क्रिप्ट में रहता है। upstream vpnc-script ने इस क्रिया को संभालने का तरीका बदला है, इसलिए इमेज के भीतर की प्रति की वर्तमान upstream से तुलना करें और जो पैकेज या इमेज बिल्ड इसे देता है उसके माध्यम से अद्यतन करें। चल रहे कंटेनर के भीतर हाथ से संपादित फ़ाइल समीक्षा-योग्य नहीं है और अगले बिल्ड तक नहीं टिकेगी।
--privileged को सभी क्षमताओं और व्यापक डिवाइस पहुँच देने वाला बताया गया है, जो कुछ न बदलने वाले संदेश के लिए बड़ी रियायत है, इसलिए यदि सचमुच कोई क्षमता गायब है तो उसका नाम लें। अद्यतन के बाद रूट लुकअप दोहराएँ और ऐप्लिकेशन को टनल इस्तेमाल करने दें, क्योंकि शांत लॉग और काम करता कनेक्शन अलग परिणाम हैं।