Предупредувањето на OpenVPN за повеќе --up скрипти: работи само една

Предупредувањето за повеќе скрипти звучи како жалба за распоредување, затоа очигледното решение е да ги прередите редовите додека не исчезне. Но тоа не е жалба за распоредување. Подоцнежна дефиниција --up ја заменува командата веќе зачувана за таа фаза, и парсерот го кажува тоа, што значи дека од вашите две скрипти некогаш работела точно една. Другата не чека во ред зад неа; таа е исчезната.

Затоа предупредувањето заслужува внимание, иако не е фатално: тоа предвидува ажурирање на DNS или промена на рута што тивко престанала да се случува.

Предупредувањето не е за редоследот

OpenVPN чува една команда на корисничка скрипта за фазата up. Кога парсерот ќе сретне друга дефиниција, од профилот, вклучена датотека или командната линија, тој го заменува она што веќе го држел и го издава предупредувањето. Ништо не се спојува, ништо не се извршува двапати и прашање за редоследот не постои. Преживува командата што парсерот ја видел последна, затоа преместувањето на ред може да го смени победникот, а другата скрипта да остане мртва.

Истиот образец важи и за другите фази на скриптите: по една команда за секоја. Ако две работи треба да се случат и двете, им треба една влезна точка, а не две наредби што личат на список.

Најдете ги двете дефиниции во вистинското стартување

Започнете од она што демонот навистина го прими, а не од профилот што го уредивте. ps -ef и ExecStart на единицата ја покажуваат командната линија, во која контејнерската влезна точка или обвивката може да додадат --up; init-датотеката на дистрибуцијата може да го стори истото. systemctl cat openvpn-server@server открива што придонесува самата служба, а рекурзивниот grep низ конфигурациската папка ги наоѓа дефинициите на ниво на датотека. Дубликатите обично доаѓаат од различни слоеви и токму затоа уредувањето на една датотека не менува ништо.

Копирањето на скрипта во друга папка или преименувањето исто така не отстранува наредба. Парсерот брои дефиниции, не датотеки.

Нека еден hook ја поседува работата

Трајното решение е еден диспечер што ги извршува двете дејства во намерен редослед. Кратка shell скрипта со set -eu што ја повикува потребната интеграција, потоа локалното дејство и го пренесува "$@" за да опстанат границите на аргументите, го држи однесувањето на едно проверливо место. Пренесувањето аргументи само ги зачувува; тоа не докажува дека двата помошници очекуваат ист интерфејс, затоа прочитајте го договорот на секој. Одлучете што треба да направи грешката и дали делумните промени треба да се вратат.

Ако стартувачот нуди поддржан hook за проширување, претпочитајте го пред рачно изградениот синџир. Контејнерска слика или пакет на добавувач често има документирано место за дополнителна работа, и неговото користење спречува надградбата да го препише вашиот диспечер.

Чистењето припаѓа на соодветната down фаза. Up дејство што го препишува DNS или додава рути бара документирано враќање, а диспечер што се занимава само со стартување е половина дизајн.

Потврдете ја интеграцијата, не само тишината

Отстранувањето на дупликатот предупредување е лесниот дел; интеграцијата сепак мора да работи. Проверете ја состојбата на резолверот по поврзувањето со resolvectl status или со читање на /etc/resolv.conf, и потврдете ги рутите со ip route. Потоа исклучете се и поврзете се повторно, бидејќи набрзина поврзан hook обично остава нешто од претходната сесија. journalctl -u openvpn-server@server -b покажува дали вашиот диспечер работел и што испечатил.

Држете ги привилегиите на hook таму каде што им е местото. Зголемувањето на script-security или пуштањето на демонот со повеќе права не е поправка за заменет hook; тоа го проширува она што може да го прави секоја идна скрипта, вклучително и онаа што напаѓачот ќе ја именува.

Знакот дека поправката е вистинска не е тишината во дневникот. Тоа се DNS одговорот, записот за рута и чистењето, кои сите работат по две повторни поврзувања.