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 ಅನ್ನು ಆ ಟಿಪ್ಪಣಿಯೊಂದಿಗೆ ಹೋಲಿಸಿದರೆ ಸರಿಪಡಿಸುವಿಕೆ ಇನ್ನೂ ಅಗ್ಗವಾಗಿರುವಾಗಲೇ ಮರುಸ್ಥಾಪನೆ ಸಿಕ್ಕಿಬೀಳುತ್ತದೆ.