PrivateTmp: हुकने फाइल लिहिली, मग ती कुठे गेली?

हुक यशाची नोंद देतात, आणि तोच मार्ग शेलमधून अजूनही रिकामा दिसतो। दोन्ही विधाने एकाच वेळी खरी असू शकतात, कारण systemd सेवा स्वतःच्या माउंट नावजागेत खाजगी तात्पुरत्या डिरेक्टरीसह राहू शकते। हे समजल्यावर मनोरंजक प्रश्न असा होतो की लिहिणे अजिबात यशस्वी झाले का।

दोन तात्पुरत्या डिरेक्टऱ्या, एकच मार्ग

विलगीकरणाची सेटिंग युनिटला तात्पुरत्या डिरेक्टऱ्यांचे खाजगी दृश्य देते, त्या फक्त-वाचनीय बनवण्याऐवजी। युनिटबाहेरील प्रक्रिया तिथे काय लिहिले जाते ते पाहू शकत नाहीत, आणि युनिट थांबल्यावर मागे राहिलेले सर्व टाकून दिले जाते। म्हणून हुकने छापलेला मार्ग आणि शेलमधून तपासलेला मार्ग एकाच नावाच्या वेगळ्या वस्तूंकडे निर्देश करू शकतात।

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

अदृश्याला अलिखितीयापासून वेगळे करा

यशस्वी लिहिणे आणि अयशस्वी उघडणे वेगळे पुरावे देतात, आणि हाच फरक दुरुस्ती ठरवतो। जर हुक म्हणतो फाइल तयार झाली पण बाहेरील वाचकाला ती सापडत नाही, तर तुमच्याकडे नावजागेचा प्रश्न आहे। जर हुक परवानगीची त्रुटी किंवा अयशस्वी उघडणे नोंदवतो, तर फाइल कधीच लिहिली गेली नाही आणि नावजागेतील कोणताही बदल मदत करणार नाही।

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

प्रक्रिया-मूळ मार्ग सेवेचे स्वतःचे फाइलसिस्टम दृश्य दाखवतो, जे ती प्रक्रिया चालू असताना तिच्यावरील परवानगी तपासण्यांच्या अधीन असते। त्याच सत्रात युनिटचा जर्नल वाचा, कारण कोणी आधीच कारण ठरवले असेल तर लिहिण्याची त्रुटी आणि गहाळ फाइल एकत्र करणे सोपे आहे।

सामायिक डेटाला स्पष्ट स्थान द्या

फक्त सेवेला आवश्यक असलेला डेटा तिच्या खाजगी तात्पुरत्या डिरेक्टरीत असतो। दुसऱ्या प्रक्रियेने वाचायचा डेटा दोघांसाठी निश्चित केलेला मार्ग मागतो, ज्यात मालक, मोड आणि मुदत नमूद असते। युनिट संपादित करण्यापूर्वी तुमच्याकडे दोनपैकी कोणती स्थिती आहे ते ठरवा। ह्या घटनांपैकी बहुतेक खाजगी फाइलला सामायिक फाइल मानण्यातून येतात।

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

रनटाइम डिरेक्टरी फोल्डर सिस्टमच्या रनटाइम भागाखाली ठेवते, युनिटच्या कॉन्फिगर केलेल्या वापरकर्ता व गटासाठी ती तयार करते आणि युनिट थांबल्यावर ती काढून टाकते। पॅकेजचे युनिट अभंग राहावे म्हणून ती drop-in द्वारे जोडा, नंतर मॅनेजर पुन्हा लोड करा आणि ती इन्स्टन्स पुन्हा सुरू करा, तिचे क्लायंट पुन्हा जोडतील हे स्वीकारून।

इन्स्टॉल केलेल्या युनिटला आधीच आवश्यक असलेली कोणतीही रनटाइम डिरेक्टरी ठेवा। यादीत भर घालण्याऐवजी ती बदलणे हा बदलाशी कोणीही जोडत नसलेले असंबंधित वैशिष्ट्य तोडण्याचा सामान्य मार्ग आहे।

दोन विशेषाधिकार स्तर असहमत होऊ शकतात

सेवा मॅनेजर युनिटच्या कॉन्फिगर केलेल्या वापरकर्त्यासाठी डिरेक्टरी तयार करतो, तर VPN डेमन कनेक्शन हुक चालवण्यापूर्वी वेगळे स्वतःच्या खात्यावर उतरू शकतो। हे वेगळे स्तर आहेत, आणि ते वेगळ्या ओळखी सांगू शकतात।

प्रतिबंधक मोड असलेली root-मालकीची डिरेक्टरी आधीच विशेषाधिकार सोडलेल्या डेमनला पूर्णपणे दिसते, आणि तरीही त्याला तिथे लिहिता येत नाही। मग त्रुटी परवानगीची समस्या म्हणून वाचली जाते, जरी मार्ग नक्की तिथे आहे जिथे तुम्ही अपेक्षा केली होती। डिरेक्टरीच्या मालकाची तुलना हुक जी ओळख नोंदवतो तिच्याशी करा। ती वेगळी असतील तर मोड कधीच प्रश्न नव्हता।

मालकी बदलण्यापूर्वी हुक प्रत्यक्षात कोणत्या ओळखीने चालतो ते तपासा। डिरेक्टरी दुरुस्त करण्यासाठी सेवेचा अंमलबजावणी वापरकर्ता बदलल्यास इतरत्र उपकरण प्रवेश आणि नेटवर्क विशेषाधिकार बदलू शकतात, जे छोट्या समस्येसाठी मोठी किंमत आहे।

संपूर्ण हस्तांतरण तपासा

एकाच वेळी चार गोष्टी निश्चित करा: हुक त्याच्या खऱ्या ओळखीने लिहितो, इच्छित वाचक फाइल वापरू शकतो, असंबंधित वापरकर्ते वापरू शकत नाहीत, आणि युनिट थांबवल्यावर रचनेनुसार स्वच्छता होते। होस्टच्या सामायिक तात्पुरत्या डिरेक्टरीत फाइल दिसणे ही अट नाही, आणि सहसा ते असे सूचक असते की देवघेवीला कधीच स्वतःचा मार्ग मिळाला नाही। पुन्हा सुरू केल्यावर वाचकाची चाचणी करा, फक्त पहिल्या वेळी चालवताना नाही। स्वच्छतेचे वर्तन रचनेचा भाग आहे, म्हणून गृहीत धरण्याऐवजी ते निरीक्षण करा।

कायमची स्थिती अशा ठिकाणी असावी जिथे आयुष्य जुळते, कारण रनटाइम डिरेक्टरी नाहीशी होण्यासाठीच बनवलेली आहे। जागा सोयीनुसार नव्हे तर आयुष्यानुसार निवडा। ही सवय याच तपासणीची पुढील आवृत्ती टाळते।