कौन-सी openvpn बाइनरी चल रही है? लॉन्च पथ जाँचें

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

उस पथ से शुरू करें जो सेवा लॉन्च करती है

टर्मिनल और systemd यूनिट निष्पादन-योग्य फ़ाइलों को एक ही तरह से हल नहीं करते। shell PATH में खोजता है; यूनिट कोई पथ नाम देती है, और drop-in अधिलेखन उसे उस फ़ाइल को छुए बिना बदल सकते हैं जिसे आप पढ़ रहे हैं। यही अंतर इस काम की अधिकांश उलझन को समझाता है। यह यह भी तय करता है कि आपकी मरम्मत को किस फ़ाइल को लक्ष्य बनाना है।

यूनिट से पूछें कि वह क्या चलाती है, उसे बदलने वाले drop-in सहित, और जिस अंश को आप प्रामाणिक मानते हैं उसके बजाय परिणामी ExecStart पंक्ति पढ़ें। फिर उस पथ का पालन किसी भी सांकेतिक लिंक से होते हुए अंतिम फ़ाइल तक करें। छिपी डायरेक्टरी में exec के साथ समाप्त होने वाला रैपर इन पुराने उपायों की आम व्यवस्था है।

कुछ भी बदलने से पहले हल किया गया पथ लिख लें।

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

कमांड के नाम की सेवा के पथ से तुलना करें

दोनों उत्तर अक्सर अलग होते हैं, और वह अंतर अपने आप कोई खराबी नहीं है। NetworkManager प्लगइन अपना पथ लॉन्च कर सकता है, और कोई कंटेनर किसी और को माउंट कर सकता है।

महत्वपूर्ण यह जानना है कि ट्रैफ़िक की सेवा करने वाली प्रक्रिया कौन-सा स्वामी लॉन्च करता है। अगर यूनिट /usr/local/sbin/openvpn-wrapper चलाती है जबकि आपका shell /usr/sbin/openvpn हल करता है, तो दूसरी फ़ाइल की मरम्मत सेवा में कुछ नहीं बदलती।

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

पैकेज फ़ाइलों के बारे में पैकेज डेटाबेस को बोलने दें

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

सत्यापन चलाएँ और खाली परिणाम को किसी बात का प्रमाण मानने के बजाय आउटपुट पढ़ें।

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

मरम्मत से पहले स्थिति दर्ज करें

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

पढ़ने से पहले रैपर की सामग्री किसी सहायता थ्रेड में पेस्ट न करें, क्योंकि ये स्क्रिप्ट कभी-कभी क्रेडेंशियल या गेटवे का विवरण लिए होती हैं।

काम करते समय दर्ज करें कि सेवा कौन-से प्रोफ़ाइल इस्तेमाल करती है और कौन जुड़ा है, क्योंकि टनल को फिर से शुरू करने से वह सत्र बाधित हो सकता है जिससे आप होस्ट का प्रशासन कर रहे हैं।

लॉन्च सत्यापित करें, फिर रैपर हटाएँ

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

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

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