Папярэджанне OpenVPN пра некалькі скрыптоў --up: выконваецца толькі адзін

Папярэджанне пра некалькі скрыптоў гучыць як скарга на планаванне, таму відавочнае рашэнне — перастаўляць радкі, пакуль яно не знікне. Але гэта не скарга на планаванне. Наступнае вызначэнне --up замяняе каманду, ужо захаваную для гэтага этапу, і парсер сам пра гэта паведамляе, а значыць, з двух вашых скрыптоў выконваўся роўна адзін. Другі не чакае ў чарзе за ім; ён знік.

Менавіта таму папярэджанне варта ўвагі, нават калі яно не фатальнае: яно прадказвае абнаўленне DNS або змену маршруту, якія ціха перасталі адбывацца.

Папярэджанне не пра парадак

OpenVPN захоўвае адну каманду карыстальніцкага скрыпта для этапу up. Калі парсер сустракае іншае вызначэнне — з профілю, уключанага файла або каманднага радка, — ён замяняе тое, што ўжо трымаў, і выводзіць папярэджанне. Нічога не аб’ядноўваецца, нішто не выконваецца двойчы, і пытання пра парадак не існуе. Застаецца тая каманда, якую парсер убачыў апошняй, таму перамяшчэнне радка можа змяніць пераможцу, пакінуўшы другі скрыпт мёртвым.

Той жа прынцып дзейнічае і для іншых этапаў скрыптоў: па адной камандзе на кожны. Калі дзве працы павінны адбыцца абедзве, ім патрэбна адна кропка ўваходу, а не дзве дырэктывы, якія нагадваюць спіс.

Знайдзіце абодва вызначэнні ў рэальным запуску

Пачніце з таго, што фактычна атрымаў daemon, а не з профілю, які вы рэдагавалі. ps -ef і ExecStart юніта паказваюць камандны радок, у які могуць дадаць --up з пункту ўваходу кантэйнера або з абгорткі; init-файл дыстрыбутыва можа зрабіць тое ж. systemctl cat openvpn-server@server паказвае, што дадае сама служба, а рэкурсіўны grep па каталогу канфігурацыі знаходзіць вызначэнні на ўзроўні файлаў. Дублікаты звычайна прыходзяць з розных слаёў, і менавіта таму рэдагаванне аднаго файла нічога не змяняе.

Капіраванне скрыпта ў іншы каталог або перайменаванне таксама не выдаляе дырэктыву. Парсер лічыць вызначэнні, а не файлы.

Хай адзін хук валодае працай

Трывалае рашэнне — адзін дыспетчар, які выконвае абедзве дзеі ў свядома выбраным парадку. Кароткі shell-скрыпт з set -eu, які выклікае патрэбную інтэграцыю, а затым лакальную дзею, перадаючы "$@", каб межы аргументаў захаваліся, трымае паводзіны ў адным месцы, якое можна праверыць. Перадача аргументаў іх толькі захоўвае; яна не даказвае, што два памочнікі чакаюць аднолькавага інтэрфейсу, таму прачытайце кантракт кожнага. Вырашыце, што павінна рабіць памылка і ці трэба адкочваць частковыя змены.

Калі запускальнік прапануе падтрыманы хук пашырэння, аддайце перавагу яму перад самаробным ланцугом. Вобраз кантэйнера або пакет пастаўшчыка часта мае дакументаванае месца для дадатковай працы, і выкарыстанне яго не дазваляе абнаўленню перазапісаць ваш дыспетчар.

Прыборка належыць адпаведнаму этапу down. Дзея up, якая перапісвае DNS або дадае маршруты, патрабуе дакументаванага адкату, а дыспетчар, які займаецца толькі запускам, — гэта палова дызайну.

Пацвердзіце інтэграцыю, а не толькі цішыню

Прыбраць папярэджанне пра дублікат — лёгкая частка; інтэграцыя ўсё яшчэ павінна працаваць. Праверце стан рэзалвера пасля падключэння з дапамогай resolvectl status або прачытаўшы /etc/resolv.conf, і пацвердзіце маршруты з дапамогай ip route. Затым адключыцеся і падключыцеся зноў, бо паспешліва злучаны хук звычайна пакідае нешта ад папярэдняй сесіі. journalctl -u openvpn-server@server -b пакажа, ці запусціўся ваш дыспетчар і што ён надрукаваў.

Трымайце прывілеі хука там, дзе ім належыць. Павышэнне script-security або запуск daemon з большымі правамі — не рашэнне для замененага хука; гэта пашырае магчымасці кожнага будучага скрыпта, у тым ліку таго, які назваў зламыснік.

Прыкмета сапраўднага выпраўлення — не цішыня ў журнале. Гэта адказ DNS, запіс маршруту і прыборка, якія працуюць пасля двух перападключэнняў.