apt purge وی‌پی‌ان را حذف کرد، اما سرویس هنوز هنگام بوت شروع می‌شود

apt purge می‌گوید بسته رفته است، و با این حال در هر شروع یک تونل دوباره بالا می‌آید. ژورنال مدام بزرگ می‌شود، مسیرها برمی‌گردند و ماشین طوری رفتار می‌کند که گویی چیزی حذف نشده است. نصب‌کننده فروشنده می‌تواند فایل‌هایی بنویسد که مدیر بسته هرگز ثبت نکرده است، بنابراین حذف یک بسته و حذف یک محصول دو کار متفاوت‌اند. رانبوک زیر دو سابقه را از هم جدا می‌کند و حذف را آگاهانه به پایان می‌رساند.

دو نصب‌کننده، دو سابقه متفاوت

بسته‌های 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 را بخوانید، چون فروشنده ممکن است در /usr/lib/systemd/system یا /lib/systemd/system نوشته باشد نه /etc. پاک کردن نسخه‌ای که انتظار داشتید، نسخه مؤثر را در حال اجرا باقی می‌گذارد و تعمیر تا بازخوانی بعدی موفق به نظر می‌رسد. پس از پایان بازخوانی فایل‌های 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

یک مالک بوت انتخاب کنید و آن را بیازمایید

سه نامزد می‌توانند بوت را ادعا کنند و نصب هر سه به‌جای ایمنی مضاعف یک مسابقه ایجاد می‌کند. فایل شروع خودکار دسکتاپ فقط پس از ورود کسی اجرا می‌شود، unit سیستم‌دی زودتر اجرا می‌شود اما به کلاینتی نیاز دارد که بدون نمایشگر کار کند، و ورودی cron از نوع @reboot بر اساس زمان‌بندی‌ای فعال می‌شود که ممکن است برای کلاینت شبکه اشتباه باشد. CLI فروشنده ممکن است آرگومان سرور هم بخواهد، چون در بوت نشست قبلی برای ادامه وجود ندارد. نامزدی را انتخاب کنید که با شیوه احراز هویت کلاینت می‌خواند و بقیه را کنار بگذارید.

با راه‌اندازی مجدد ماشین و نگاه به سه واقعیت مستقل بیازمایید: وضعیت unit، فهرست فرایندها، و اتصال تازه به چیزی که بتوانید بررسی کنید. کلاینتی که به دسته‌کلید یا ورود تعاملی نیاز دارد حتی با فایل unit درست در بوت شکست می‌خورد، و ژورنال این را می‌گوید اگر آن را بخوانید نه فقط وضعیت سرویس را.

یا به کلاینت اعتبارنامه‌ای بدهید که بدون پرسش کار کند، یا آن را هنگام ورود شروع کنید. هر دو قابل دفاع‌اند و ترکیبشان راهی است که یک تونل دو مالک پیدا می‌کند که بر سرش می‌جنگند.

بنویسید purge بعدی باید چه انتظاری داشته باشد

پس از هر حذف دستی دو واقعیت را یادداشت کنید: کدام نصب‌کننده این چیدمان را ساخته و اکنون کدام مالک آن را شروع می‌کند. آن یادداشت purge بعدی را از غافلگیری به یک بند در چک‌لیست تبدیل می‌کند و از کسی که کار را انجام داده بیشتر عمر می‌کند.

آن را کنار پیکربندی سرویس نگه دارید نه در پوشه شخصی، و تاریخ بزنید، چون به‌روزرسانی فروشنده می‌تواند unitی را که پاک کرده‌اید بازگرداند. مقایسه systemctl list-unit-files با آن یادداشت هر چند ماه بازگردانی را وقتی تعمیرش هنوز ارزان است می‌گیرد.