OpenVPN se waarskuwing oor veelvuldige --up-skrips: net een loop

Die waarskuwing oor veelvuldige up-skrips lees soos ’n klag oor skedulering, so die ooglopende oplossing is om die lyne te herrangskik totdat dit verdwyn. Dit is nie ’n klag oor skedulering nie. ’n Latere --up-definisie vervang die opdrag wat reeds vir daardie stadium gestoor is, en die ontleder sê so, wat beteken dat presies een van jou twee skrips ooit geloop het. Die ander een wag nie daaragter in ’n tou nie; dit is weg.

Daarom verdien die waarskuwing aandag, selfs al is dit nie noodlottig nie: wat dit voorspel, is ’n DNS-opdatering of ’n roeteverandering wat stilweg opgehou het om te gebeur.

Die waarskuwing gaan nie oor ordening nie

OpenVPN stoor ’n enkele gebruikerskrip-opdrag vir die up-stadium. Wanneer die ontleder ’n ander definisie teëkom, uit die profiel, ’n ingeslote lêer of die opdraglyn, vervang dit wat dit reeds gehou het en lewer die waarskuwing. Niks word saamgevoeg nie, niks loop twee keer nie, en daar bestaan geen ordeningsvraag nie. Die opdrag wat oorleef, is die een wat die ontleder laas gesien het, en daarom kan die verskuif van ’n lyn die wenner verander terwyl die ander skrip dood bly.

Dieselfde patroon geld vir die ander skripstadia: een opdrag elk. As twee stukke werk albei moet gebeur, het hulle ’n enkele intreepunt nodig, nie twee riglyne wat soos ’n lys lyk nie.

Vind albei definisies in die werklike lansering

Begin by wat die daemon werklik ontvang het, nie by die profiel wat jy geredigeer het nie. ps -ef en die eenheid se ExecStart wys die opdraglyn, wat --up kan byvoeg vanaf ’n houer-intreekpunt of ’n wikkelaar; ’n verspreiding se inislêer kan dieselfde doen. systemctl cat openvpn-server@server onthul wat die diens self bydra, en ’n rekursiewe grep oor die konfigurasiegids vind die lêervlakdefinisies. Duplikate kom gewoonlik uit verskillende lae, en dit is presies waarom die redigering van een lêer niks verander nie.

Om ’n skrip na ’n ander gids te kopieer of dit te hernoem, verwyder ook nie ’n riglyn nie. Die ontleder tel definisies, nie lêers nie.

Laat een haak die werk besit

Die blywende oplossing is ’n enkele verspreider wat albei aksies in ’n doelbewuste orde uitvoer. ’n Kort skulpkrip met set -eu wat die vereiste integrasie en dan die plaaslike aksie aanroep en "$@" deurstuur sodat argumentgrense behoue bly, hou die gedrag op een plek wat ouditeerbaar is. Om argumente deur te stuur bewaar hulle net; dit bewys nie dat die twee helpers dieselfde koppelvlak verwag nie, so lees elkeen se kontrak. Besluit wat ’n fout moet doen, en of gedeeltelike veranderinge omgekeer moet word.

As die lanseerder ’n ondersteunde uitbreidingshaak bied, verkies dit bo handgemaakte koppeling. ’n Houerbeeld of ’n verskafferspakket het dikwels ’n gedokumenteerde plek vir ekstra werk, en as jy dit gebruik, keer ’n opgradering nie jou verspreider oorskryf nie.

Opruiming hoort in die ooreenstemmende down-stadium. ’n Up-aksie wat DNS herskryf of roetes byvoeg, het ’n gedokumenteerde terugdraai nodig, en ’n verspreider wat net die opstart hanteer, is ’n halwe ontwerp.

Bevestig die integrasie, nie net die stilte nie

Om die duplikatwaarskuwing te verwyder is die maklike deel; die integrasie moet steeds werk. Kontroleer die oplosser se toestand nadat jy gekoppel het met resolvectl status of deur /etc/resolv.conf te lees, en bevestig roetes met ip route. Koppel dan los en weer, want ’n haastig gekoppelde haak laat gewoonlik iets van die vorige sessie agter. journalctl -u openvpn-server@server -b wys of jou verspreider geloop het en wat dit gedruk het.

Hou die haak se voorregte waar dit hoort. Om script-security te verhoog of die daemon met meer regte te laat loop, is nie ’n oplossing vir ’n vervange haak nie; dit verbreed wat elke toekomstige skrip kan doen, insluitend een wat ’n aanvaller mag benoem.

Die teken dat die oplossing werklik is, is nie stilte in die logboek nie. Dit is die DNS-antwoord, die roete-inskrywing en die opruiming wat almal werk ná twee herverbindings.