apt purge VPN-ийг устгасан ч үйлчилгээ ачаалах үед ажилласаар байна

apt purge багц алга болсон гэж хэлдэг ч ачаалах бүрт туннель дахин босдог. Journal өсөөр байна, маршрутууд буцаж ирнэ, машин юу ч устгагдаагүй мэт аашилна. Нийлүүлэгчийн суулгагч нь багц менежер хэзээ ч бүртгээгүй файлуудыг бичиж болох тул багц устгах, бүтээгдэхүүн устгах нь хоёр өөр ажил. Доорх runbook хоёр бичлэгийг ялгаж, устгалтыг зориуд дуусгана.

Хоёр суулгагч, хоёр өөр бичлэг

Debian багцууд файлын жагсаалт хадгалдаг ба purge нь тэр жагсаалтад нэрлэгдсэн зүйл болон багцын тохиргоог л устгана. Shell суулгагч эсвэл .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-ыг тэр тэмдэглэлтэй харьцуулбал засвар хямд байх үед сэргээлтийг барьж авна.