apt purge VPN നീക്കി, പക്ഷേ സേവനം ബൂട്ടിൽ ഇപ്പോഴും ആരംഭിക്കുന്നു

apt purge പാക്കേജ് പോയി എന്ന് പറയുന്നു, എന്നിട്ടും ഓരോ തുടക്കത്തിലും ടണൽ വീണ്ടും ഉയരുന്നു. journal വളരുന്നു, റൂട്ടുകൾ തിരിച്ചുവരുന്നു, യന്ത്രം ഒന്നും നീക്കാത്തതുപോലെ പെരുമാറുന്നു. വെണ്ടറിന്റെ ഇൻസ്റ്റാളർ പാക്കേജ് മാനേജർ ഒരിക്കലും രേഖപ്പെടുത്താത്ത ഫയലുകൾ എഴുതാം, അതിനാൽ പാക്കേജ് നീക്കുന്നതും ഉൽപ്പന്നം നീക്കുന്നതും വ്യത്യസ്ത ജോലികളാണ്. താഴെയുള്ള runbook രണ്ട് രേഖകളെ വേർതിരിച്ച് നീക്കം ബോധപൂർവം പൂർത്തിയാക്കുന്നു.

രണ്ട് ഇൻസ്റ്റാളർ, രണ്ട് വ്യത്യസ്ത രേഖകൾ

Debian പാക്കേജുകൾ ഫയൽ പട്ടിക സൂക്ഷിക്കുന്നു, purge ആ പട്ടിക പേരിടുന്നതും പാക്കേജ് ക്രമീകരണവും മാത്രം മായ്ക്കുന്നു. ഷെൽ ഇൻസ്റ്റാളറോ .run ബണ്ടിലോ അത്തരം പട്ടിക സൂക്ഷിക്കുന്നില്ല; അത് ഇഷ്ടമുള്ളിടത്ത് എഴുതുന്നു, സാധാരണയായി /opt, /usr/local, /etc/systemd/system എന്നിവയിൽ. ആ വഴികളൊന്നും ഏതെങ്കിലും പാക്കേജിന്റെ ഫയൽ പട്ടികയിൽ കാണുന്നില്ല, അതിനാൽ dpkg അവ അറിയുന്നുമില്ല, റിപ്പോർട്ട് ചെയ്യുന്നുമില്ല. അവസാനം ഒരു ഫയൽ സിസ്റ്റത്തിൽ രണ്ട് ഇൻസ്റ്റാളേഷൻ ഉടമകൾ ഉണ്ടാകും, അവരിൽ ഒരാൾ മാത്രം കണക്ക് സൂക്ഷിക്കുന്നു.

മായ്ക്കുന്നതിന് മുൻപ് ആ നിർദ്ദിഷ്ട വഴിയെക്കുറിച്ച് dpkg-യോട് ചോദിക്കുക. അത് നിഷേധിക്കുന്ന വഴി നിങ്ങളുടേതാണ് നീക്കാൻ, അതേ ഉത്തരം പിന്നീടുള്ള അപ്ഗ്രേഡ് അത് തിരികെ കൊണ്ടുവരുമോ എന്നും പറയുന്നു.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

unit ഉം അതിന്റെ wants ലിങ്കും വേറിട്ട ഫയലുകളാണ്

പ്രവർത്തനക്ഷമമാക്കൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിൽ നിന്ന് വേറിട്ട പ്രവൃത്തിയാണ്. unit അതിന്റെ [Install] വിഭാഗത്തിൽ ലക്ഷ്യബന്ധങ്ങൾ പ്രഖ്യാപിക്കുന്നു, systemctl enable ആ പ്രഖ്യാപനങ്ങളെ ഓരോ ലക്ഷ്യത്തിന്റെയും .wants/ ഡയറക്ടറിയിലെ പ്രതീകാത്മക ലിങ്കുകളാക്കുന്നു. ഇപ്പോൾ രണ്ട് വഴികളുണ്ട്: unit ഫയലും, അതിനെ ബൂട്ട് ലക്ഷ്യത്തിലേക്ക് വലിക്കുന്ന ലിങ്കും. ഫയൽ മാത്രം മായ്ച്ചാൽ ലിങ്ക് ഒന്നിനെയും ചൂണ്ടുന്നില്ല, ഇത് ബൂട്ടിൽ പരാതി ഉണ്ടാക്കുന്നു; ലിങ്ക് മാത്രം മായ്ച്ചാൽ unit പേരിൽ ആരംഭിക്കാവുന്നതായി തുടരും. രണ്ടും പോകണം.

അവ ക്രമത്തിൽ നീക്കി പിന്നീട് വീണ്ടും ലോഡ് ചെയ്യുക, systemd പഴയ നിർവചനങ്ങൾ മെമ്മറിയിൽ സൂക്ഷിക്കുന്നത് നിർത്താൻ.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

സ്ഥാനം അനുമാനിക്കാതെ FragmentPath വായിക്കുക, കാരണം വെണ്ടർ /etc-ന് പകരം /usr/lib/systemd/system അല്ലെങ്കിൽ /lib/systemd/system-ൽ എഴുതിയിരിക്കാം. പ്രതീക്ഷിച്ച പകർപ്പ് മായ്ച്ചാൽ ഫലപ്രദമായത് പ്രവർത്തിക്കുന്നത് തുടരും, അടുത്ത വീണ്ടും ലോഡ് വരെ തിരുത്ത് വിജയകരമായി തോന്നും. ലോഡ് കഴിഞ്ഞ് unit ഫയലുകൾ വീണ്ടും പട്ടികപ്പെടുത്തി പേര് ഇനി കാണുന്നില്ലെന്ന് ഉറപ്പാക്കുക.

ഈ ക്രമീകരണത്തെ ജീവനോടെ നിർത്തുന്ന ബൈനറി കണ്ടെത്തുക

പ്രവർത്തനക്ഷമമായ unit പാക്കേജ് ഡാറ്റാബേസ് എന്ത് കരുതിയാലും ഡീമൺ ആരംഭിക്കുന്നത് തുടരും. ആ പ്രക്രിയ ടണൽ തിരികെ കൊണ്ടുവരാം, റൂട്ടുകൾ വീണ്ടും ചേർക്കാം, അല്ലെങ്കിൽ kill-switch നിയമം പുനഃസ്ഥാപിക്കാം, ക്രമീകരണം പരിശോധിക്കുന്നത് വരെ പെരുമാറ്റം അമാനുഷികമായി തോന്നും. ExecStart വഴി പിന്തുടർന്ന് ബൈനറി ഇപ്പോഴും അവിടെയുണ്ടോ നോക്കുക, കാരണം /opt-ന് കീഴിൽ ശേഷിക്കുന്ന എക്സിക്യൂട്ടബിൾ ഫയൽ ഈ ക്രമീകരണത്തിന് വേണ്ടതെല്ലാം. unit മായ്ച്ചാൽ നിശ്ചയിച്ച തുടക്കം നിലയ്ക്കും; അത് പ്രോഗ്രാം മായ്ക്കുന്നില്ല.

സ്റ്റേറ്റ് ഡയറക്ടറികളെയും അതേ ശ്രദ്ധയോടെ കാണുക. അക്കൗണ്ട് ടോക്കണുകൾ, സൃഷ്ടിച്ച പ്രൊഫൈലുകൾ, കാഷെ ചെയ്ത സെർവർ പട്ടികകൾ /var/lib-ന് കീഴിലോ ഹോം ഡയറക്ടറിയിലോ കഴിയുന്നു, അവ ക്രെഡൻഷ്യലുകളാണ്, വലിച്ചെറിയാൻ പാകം ചെയ്ത കാഷെയല്ല. സേവനം നിർത്തിയ ശേഷം അവ ബോധപൂർവം നീക്കി എന്താണ് എടുത്തതെന്ന് എഴുതിവയ്ക്കുക.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

ബൂട്ടിന്റെ ഒരു ഉടമയെ തിരഞ്ഞെടുത്ത് പരീക്ഷിക്കുക

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

യന്ത്രം റീബൂട്ട് ചെയ്ത് മൂന്ന് സ്വതന്ത്ര വസ്തുതകൾ നോക്കി പരീക്ഷിക്കുക: unit അവസ്ഥ, പ്രോസസ് പട്ടിക, നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന എന്തിനോടെങ്കിലുമുള്ള പുതിയ ബന്ധം. കീറിംഗ് അല്ലെങ്കിൽ സംവേദനാത്മക ലോഗിൻ ആവശ്യപ്പെടുന്ന ക്ലയന്റ് ശരിയായ unit ഫയൽ ഉണ്ടായാലും ബൂട്ടിൽ പരാജയപ്പെടും, സേവന അവസ്ഥ മാത്രമല്ല, journal വായിച്ചാൽ അത് പറയും.

ഒന്നുകിൽ ചോദ്യമില്ലാതെ പ്രവർത്തിക്കുന്ന ക്രെഡൻഷ്യൽ ക്ലയന്റിന് നൽകുക, അല്ലെങ്കിൽ സൈൻ ഇൻ സമയത്ത് അത് ആരംഭിക്കുക. രണ്ടും ന്യായീകരിക്കാം, രണ്ടും ചേർക്കുമ്പോഴാണ് ഒരു ടണലിന് അതിനായി കലഹിക്കുന്ന രണ്ട് ഉടമകൾ ഉണ്ടാകുന്നത്.

അടുത്ത purge എന്ത് പ്രതീക്ഷിക്കണം എന്ന് എഴുതുക

ഏതെങ്കിലും കൈകൊണ്ട് നീക്കിയ ശേഷം രണ്ട് വസ്തുതകൾ രേഖപ്പെടുത്തുക: ഏത് ഇൻസ്റ്റാളർ ഈ ക്രമീകരണം ഉണ്ടാക്കി, ഇപ്പോൾ ഏത് ഉടമ അത് ആരംഭിക്കുന്നു. ആ കുറിപ്പ് അടുത്ത purge-നെ അത്ഭുതത്തിൽ നിന്ന് ചെക്ക്‌ലിസ്റ്റിലെ ഒരു ഇനമാക്കി മാറ്റുന്നു, ജോലി ചെയ്ത വ്യക്തിയെക്കാൾ അത് നീണ്ടുനിൽക്കുന്നു.

വ്യക്തിഗത ഡയറക്ടറിയിലല്ല, സേവന ക്രമീകരണത്തിന് അടുത്ത് അത് സൂക്ഷിക്കുക, തീയതി ചേർക്കുക, കാരണം വെണ്ടർ അപ്ഡേറ്റ് നിങ്ങൾ മായ്ച്ച unit പുനഃസ്ഥാപിച്ചേക്കാം. ഓരോ കുറച്ച് മാസത്തിലും systemctl list-unit-files ആ കുറിപ്പുമായി താരതമ്യം ചെയ്താൽ തിരുത്ത് ഇപ്പോഴും വിലകുറഞ്ഞപ്പോൾ പുനഃസ്ഥാപനം പിടികൂടാം.