Стара заобиколна мярка премести изпълнимия файл на OpenVPN другаде и остави shell обвивка на първоначалния път. Месеци по-късно пристига актуализация и отмяната на мярката се превръща в игра на догадки кой файл всъщност е клиентът. Името на командата, конфигурираният в услугата изпълним файл и собственият инвентар на пакета могат да сочат към различни обекти и поправянето на един от тях без другите дава хост, който изглежда оправен и се държи по-зле.

Започнете от пътя, който услугата стартира

Терминалът и systemd юнитът не разрешават изпълними файлове по един и същ начин. Shell търси в PATH; юнитът посочва път и drop-in заместванията могат да го сменят, без да пипат файла, който четете. Тази разлика обяснява по-голямата част от объркването в тази задача. Тя също решава кой файл трябва да е целта на поправката ви.

Попитайте юнита какво изпълнява, включително drop-in файловете, които го променят, и четете получения ред ExecStart, а не фрагмента, който приемате за авторитетен. След това проследете този път през всяка символна връзка до крайния файл. Обвивка, която завършва с exec в скрита директория, е обичайно решение от тези стари поправки.

Запишете разрешения път, преди да промените каквото и да е.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Сравнете името на командата с пътя на услугата

Двата отговора често са различни и тази разлика не е автоматично дефект. Плъгин на NetworkManager може да стартира свой път, а контейнер може да монтира още един.

Важно е да знаете кой собственик стартира процеса, който обслужва трафика. Ако юнитът изпълнява /usr/local/sbin/openvpn-wrapper, докато вашият shell разрешава /usr/sbin/openvpn, поправката на втория файл не променя нищо в услугата.

Попитайте кой пакет притежава всеки кандидат, след което решете дали файлът се управлява от пакета, или е поставен локално. Файл без притежаващ пакет е файл, който някой е поставил там умишлено, и той заслужава име, собственик и причина, преди да бъде изтрит. Обратната грешка също е честа: презаписване на файл от пакет със стар запазен двоичен файл, защото публикация във форум е използвала същата директория.

Оставете базата данни на пакетите да говори за файловете на пакета

Когато софтуерът е дошъл от Debian пакет, базата данни на пакетите може да ви каже дали файловете му още съвпадат с инсталираното. Това е тесен въпрос за цялост, не присъда за сигурност, и разликата е важна, когато решавате какво да поправите. Несъответствието означава, че файлът се е променил след инсталацията, което може да е вашата стара заобиколна мярка или законна локална редакция. Резултатът не решава кое от двете, затова го четете като указание, а не като заключение.

Стартирайте проверката и прочетете резултата, вместо да приемате празен резултат като доказателство за каквото и да е.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Ръководството на dpkg документира, че проверката сравнява инсталираните файлове с локално записани метаданни, използвайки запазени контролни суми, където има такива. Тя забелязва променен файл от пакет и не може да ви каже дали вместо него не се стартира друг двоичен файл.

Запишете състоянието преди поправката

Съберете разрешения път на стартиране, връзката на файла с пакета, местоположението на обвивката и записа за промяна, който я е въвел. Копирайте обвивката на защитено място, ако съдържа интеграционна работа, която ще е нужна по-късно.

Не поставяйте съдържанието на обвивката в тема за поддръжка, преди да го прочетете, защото тези скриптове понякога носят идентификационни данни или подробности за шлюз.

Запишете кои профили използва услугата и кой е свързан, докато работите, защото рестартирането на тунела може да прекъсне сесията, с която администрирате хоста.

Проверете стартирането, след това премахнете обвивката

След поправката стартирайте услугата и потвърдете, че процесът работи по пътя, който сте предвидили. Ръчна заявка за версия доказва, че файлът работи; тя не доказва, че юнитът го използва.

След това свържете отново клиент и проверете, че профилът все още се удостоверява, защото подмяна на двоичен файл, която игнорира оригиналните опции, ще се провали по начин, който изглежда като проблем със сертификат.

Премахнете изместената обвивка чрез същия запис за промяна, който я е въвел. Завършената поправка казва кой изпълним файл работи, защо и кой файл е бил премахнат; възстановяването на име на файл и надеждата не са едно и също нещо.

Подобни статии