PrivateTmp: ഹൂക്ക് ഫയൽ എഴുതി, പക്ഷേ അത് എങ്ങോട്ട് പോയി?

ഹൂക്കുകൾ വിജയം റിപ്പോർട്ട് ചെയ്യുന്നു, എന്നിട്ടും അതേ പാത ഷെല്ലിൽ നിന്ന് ഇപ്പോഴും ശൂന്യമായി കാണുന്നു. രണ്ട് പ്രസ്താവനകളും ഒരേ സമയം ശരിയാകാം, കാരണം ഒരു systemd സേവനം സ്വകാര്യ താൽക്കാലിക ഡയറക്ടറിയുള്ള സ്വന്തം mount നാമസ്ഥലത്ത് ജീവിക്കാം. അത് മനസ്സിലായിക്കഴിഞ്ഞാൽ, എഴുത്ത് ഒട്ടും വിജയിച്ചോ എന്നതാണ് രസകരമായ ചോദ്യം.

രണ്ട് താൽക്കാലിക ഡയറക്ടറികൾ, ഒരു പാത

വേർതിരിവ് ക്രമീകരണം യൂണിറ്റിന് താൽക്കാലിക ഡയറക്ടറികളുടെ സ്വകാര്യ കാഴ്ച നൽകുന്നു, അവയെ വായനയ്ക്ക് മാത്രമാക്കുന്നതിനു പകരം. യൂണിറ്റിന് പുറത്തുള്ള പ്രോസസുകൾ അവിടെ എന്താണ് എഴുതുന്നതെന്ന് കാണാനാകില്ല, യൂണിറ്റ് നിൽക്കുമ്പോൾ അവിടെ ബാക്കിയാകുന്നതെല്ലാം ഉപേക്ഷിക്കപ്പെടുന്നു. അതിനാൽ ഹൂക്ക് പ്രിന്റ് ചെയ്യുന്ന പാതയും ഷെല്ലിൽ നിന്ന് പരിശോധിക്കുന്ന പാതയും ഒരേ പേരുള്ള വ്യത്യസ്ത വസ്തുക്കളെ സൂചിപ്പിക്കാം.

ഇത് കാഴ്ചയുടെ പ്രശ്നമാണ്, ഇത് ഡാറ്റ നഷ്ടത്തിന്റെ പ്രശ്നമായി തോന്നുന്നു. ഒന്നും ഇല്ലാതാക്കിയിട്ടില്ല, കാരണം ഫയൽ ഷെൽ അംഗമല്ലാത്ത ഒരു നാമസ്ഥലത്ത് മാത്രമാണ് ഉള്ളത്. ഒരേ കമാൻഡ് യൂണിറ്റിനുള്ളിൽ പ്രവർത്തിപ്പിക്കുമ്പോൾ വ്യത്യസ്തമായി പെരുമാറുന്നു, ആ നിരീക്ഷണമാണ് സാധാരണയായി തർക്കം തീർക്കുന്നത്. എഴുത്തിനെക്കുറിച്ച് എന്തെങ്കിലും നിഗമനത്തിലെത്തുന്നതിന് മുമ്പ് യൂണിറ്റിന്റെ ക്രമീകരണങ്ങൾ വായിക്കുക.

കാണാത്തതിനെ എഴുതാനാകാത്തതിൽ നിന്ന് വേർതിരിക്കുക

വിജയകരമായ എഴുത്തും പരാജയപ്പെട്ട തുറക്കലും വ്യത്യസ്ത തെളിവുകൾ നൽകുന്നു, ആ വ്യത്യാസമാണ് അറ്റകുറ്റപ്പണി നിർണ്ണയിക്കുന്നത്. ഹൂക്ക് ഫയൽ സൃഷ്ടിച്ചു എന്ന് പറയുന്നുവെങ്കിലും പുറത്തുള്ള വായനക്കാരന് അത് കണ്ടെത്താനാകുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് നാമസ്ഥലത്തിന്റെ ചോദ്യമുണ്ട്. ഒരു പക്ഷേ ഹൂക്ക് അനുമതി പിശകോ പരാജയപ്പെട്ട തുറക്കലോ റിപ്പോർട്ട് ചെയ്താൽ, ഫയൽ ഒരിക്കലും എഴുതിയിട്ടില്ല, നാമസ്ഥലത്തിന്റെ ഒരു മാറ്റവും സഹായിക്കില്ല.

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 ഉടമസ്ഥതയിലുള്ള ഡയറക്ടറി ഇതിനകം പദവികൾ ഉപേക്ഷിച്ച ഡീമണിന് പൂർണ്ണമായി കാണാം, എന്നിട്ടും അതിന് എഴുതാനാകില്ല. അപ്പോൾ പിശക് അനുമതി പ്രശ്നമായി വായിക്കപ്പെടുന്നു, പാത നിങ്ങൾ പ്രതീക്ഷിച്ച അതേ സ്ഥലത്ത് തന്നെയുണ്ടെങ്കിലും. ഡയറക്ടറിയുടെ ഉടമയെ ഹൂക്ക് റിപ്പോർട്ട് ചെയ്യുന്ന ഐഡന്റിറ്റിയുമായി താരതമ്യം ചെയ്യുക. അവ വ്യത്യസ്തമാകുമ്പോൾ, മോഡ് ഒരിക്കലും ചോദ്യമായിരുന്നില്ല.

ഉടമസ്ഥത മാറ്റുന്നതിന് മുമ്പ് ഹൂക്ക് യഥാർത്ഥത്തിൽ ഏത് ഐഡന്റിറ്റിയിലാണ് പ്രവർത്തിക്കുന്നതെന്ന് പരിശോധിക്കുക. ഡയറക്ടറി ശരിയാക്കാൻ സേവനത്തിന്റെ പ്രവർത്തന ഉപയോക്താവിനെ മാറ്റുന്നത് മറ്റിടങ്ങളിൽ ഉപകരണ പ്രവേശനവും നെറ്റ്വർക്ക് പദവികളും മാറ്റിയേക്കാം, ഇത് ചെറിയ പ്രശ്നത്തിന് വലിയ വിലയാണ്.

മുഴുവൻ കൈമാറ്റവും പരിശോധിക്കുക

ഒരേ സമയം നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: ഹൂക്ക് അതിന്റെ യഥാർത്ഥ ഐഡന്റിറ്റിയിൽ എഴുതുന്നു, ഉദ്ദേശിച്ച വായനക്കാരന് ഫയൽ ഉപയോഗിക്കാം, അസംബന്ധമായ ഉപയോക്താക്കൾക്ക് കഴിയില്ല, യൂണിറ്റ് നിർത്തുമ്പോൾ രൂപകൽപ്പന പ്രകാരം വൃത്തിയാക്കുന്നു. ഹോസ്റ്റിന്റെ പങ്കിട്ട താൽക്കാലിക ഡയറക്ടറിയിൽ ഫയൽ പ്രത്യക്ഷപ്പെടുന്നത് ആവശ്യകതയല്ല, അത് സാധാരണയായി കൈമാറ്റത്തിന് ഒരിക്കലും സ്വന്തം പാത ലഭിച്ചില്ലെന്ന സൂചനയാണ്. പുനരാരംഭത്തിന് ശേഷം വായനക്കാരനെ പരീക്ഷിക്കുക, ആദ്യ പ്രവർത്തന സമയത്ത് മാത്രമല്ല. വൃത്തിയാക്കൽ സ്വഭാവം രൂപകൽപ്പനയുടെ ഭാഗമാണ്, അതിനാൽ അനുമാനിക്കുന്നതിനു പകരം അത് നിരീക്ഷിക്കുക.

സ്ഥിരമായ അവസ്ഥ ആയുസ്സ് യോജിക്കുന്ന ഇടത്തിൽ വേണം, കാരണം റൺടൈം ഡയറക്ടറി അപ്രത്യക്ഷമാകാൻ ഉദ്ദേശിച്ചതാണ്. സ്ഥലം സൗകര്യത്തിനു പകരം ആയുസ്സ് അനുസരിച്ച് തിരഞ്ഞെടുക്കുക. ആ ശീലം ഇതേ അന്വേഷണത്തിന്റെ അടുത്ത പതിപ്പ് തടയുന്നു.