Åtvaringa frå OpenVPN om fleire --up-skript: berre éin køyrer

Åtvaringa om fleire skript høyrest ut som ei klage på planlegging, so den openberre løysinga er å omorganisere linjene til ho forsvinn. Det er ikkje ei klage på planlegging. Ein seinare --up-definisjon erstattar kommandoen som alt er lagra for det trinnet, og parsaren seier det, noko som tyder at av dei to skripta dine har nøyaktig eitt nokon gong køyrt. Det andre står ikkje i kø bak det; det er borte.

Difor fortener åtvaringa merksemd sjølv om ho ikkje er fatal: det ho føreser, er ein DNS-oppdatering eller ei ruteendring som stille slutta å skje.

Åtvaringa handlar ikkje om rekkjefølgje

OpenVPN lagrar éin einaste brukarskriptkommando for up-trinnet. Når parsaren møter ein annan definisjon, frå profilen, ei inkludert fil eller kommandolinja, erstattar han det han alt hadde, og sender åtvaringa. Ingenting vert samankopla, ingenting køyrer to gonger, og det finst ikkje noko rekkjefølgjespørsmål. Kommandoen som overlever, er den parsaren såg sist, og difor kan ei flytta linje endre vinnaren medan det andre skriptet blir verande dødt.

Same mønster gjeld for dei andre skripttrinna: éin kommando kvar. Viss to stykke arbeid begge må skje, treng dei eitt inngangspunkt, ikkje to direktiv som liknar ei liste.

Finn begge definisjonane i den verkelege oppstarten

Start med det daemonen faktisk fekk, ikkje med profilen du redigerte. ps -ef og ExecStart til eininga viser kommandolinja, som kan leggje til --up frå eit container-entrypoint eller ein wrapper; ei init-fil i ein distribusjon kan gjere det same. systemctl cat openvpn-server@server avdekkjer kva tenesta sjølv bidreg med, og ein rekursiv grep i konfigurasjonsmappa finn filnivådefinisjonane. Duplikat kjem ofte frå ulike lag, og det er nettopp difor redigering av éi fil ikkje endrar noko.

Å kopiere eit skript til ei anna mappe eller gje det nytt namn fjernar heller ikkje eit direktiv. Parsaren tel definisjonar, ikkje filer.

Lat éin hook eige arbeidet

Den varige løysinga er éin dispatcher som køyrer begge handlingane i ein medviten rekkjefølgje. Eit kort shell-skript med set -eu som kallar den naudsynte integrasjonen og deretter den lokale handlinga og videresender "$@" slik at argumentgrensene overlever, held åtferda på éin stad som kan reviderast. Å videresende argument bevarar dei berre; det beviser ikkje at dei to hjelparane ventar same grensesnitt, so les kontrakten til kvar av dei. Bestem kva ein feil skal gjere, og om delvise endringar må rullast tilbake.

Viss oppstartaren tilbyr ein støtta utvidingshook, føretrekk han framfor handlaga kjetting. Eit container-image eller ein leverandørpakke har ofte ein dokumentert stad for ekstra arbeid, og å bruke han hindrar ei oppgradering i å skrive over dispatcheren din.

Opprydding høyrer til det tilsvarande down-trinnet. Ei up-handling som skriv om DNS eller legg til ruter, treng ei dokumentert tilbakerulling, og ein dispatcher som berre handterer oppstarten, er eit halvt design.

Stadfest integrasjonen, ikkje berre stilla

Å fjerne duplikatåtvaringa er den enkle delen; integrasjonen må framleis verke. Sjekk tilstanden til resolveren etter tilkopling med resolvectl status eller ved å lese /etc/resolv.conf, og stadfest rutene med ip route. Kople so frå og til att, fordi ein raskt kjeta hook har ein tendens til å etterlate noko frå førre økt. journalctl -u openvpn-server@server -b viser om dispatcheren din køyrde, og kva han skreiv ut.

Hald rettane til hooken der dei høyrer heime. Å heve script-security eller køyre daemonen med fleire rettar er ikkje ei løysing på ein erstatta hook; det utvidar kva kvart framtidig skript kan gjere, inkludert eit som ein åtakar får namngje.

Teiknet på at rettinga er ekte, er ikkje stille i loggen. Det er DNS-svaret, ruteoppføringa og oppryddinga som alle verkar etter to gjenoppkoplingar.