Avertismentul despre mai multe scripturi sună ca o plângere legată de planificare, așa că soluția evidentă este să reordonezi liniile până dispare. Nu este o plângere despre planificare. O definiție ulterioară --up înlocuiește comanda deja stocată pentru acea etapă, iar parserul spune asta, ceea ce înseamnă că dintre cele două scripturi ale tale exact unul a rulat vreodată. Celălalt nu stă la coadă în spatele lui; a dispărut.

De aceea avertismentul merită atenție chiar dacă nu este fatal: ceea ce prevestește este o actualizare DNS sau o schimbare de rută care a încetat în tăcere să se întâmple.

Avertismentul nu este despre ordine

OpenVPN păstrează o singură comandă de script de utilizator pentru etapa up. Când parserul întâlnește o altă definiție, din profil, dintr-un fișier inclus sau din linia de comandă, înlocuiește ce avea deja și emite avertismentul. Nimic nu este concatenat, nimic nu rulează de două ori și nu există nicio întrebare despre ordine. Comanda care supraviețuiește este cea pe care parserul a văzut-o ultima, de aceea mutarea unei linii poate schimba câștigătorul în timp ce celălalt script rămâne mort.

Același tipar este valabil pentru celelalte etape de script: câte o comandă pentru fiecare. Dacă două lucrări trebuie să se întâmple amândouă, au nevoie de un singur punct de intrare, nu de două directive care seamănă cu o listă.

Găsiți ambele definiții în lansarea reală

Începeți cu ce a primit de fapt daemonul, nu cu profilul pe care l-ați editat. ps -ef și ExecStart al unității arată linia de comandă, care poate adăuga --up dintr-un punct de intrare de container sau dintr-un wrapper; fișierul init al unei distribuții poate face același lucru. systemctl cat openvpn-server@server dezvăluie ce adaugă serviciul însuși, iar un grep recursiv în directorul de configurare găsește definițiile la nivel de fișier. Duplicatele provin de obicei din straturi diferite, și exact de aceea editarea unui singur fișier nu schimbă nimic.

Copierea unui script în alt director sau redenumirea lui nu elimină nici o directivă. Parserul numără definiții, nu fișiere.

Lăsați un singur hook să dețină munca

Soluția durabilă este un singur dispecer care execută ambele acțiuni într-o ordine deliberată. Un script shell scurt cu set -eu care apelează integrarea necesară și apoi acțiunea locală, transmițând "$@" pentru ca limitele argumentelor să supraviețuiască, ține comportamentul într-un singur loc auditabil. Transmiterea argumentelor doar le păstrează; nu dovedește că cei doi auxiliari așteaptă aceeași interfață, așa că citiți contractul fiecăruia. Decideți ce trebuie să facă o eroare și dacă modificările parțiale trebuie anulate.

Dacă lansatorul oferă un hook de extensie acceptat, preferați-l în locul înlănțuirii făcute manual. O imagine de container sau un pachet de furnizor are adesea un loc documentat pentru muncă suplimentară, iar folosirea lui împiedică o actualizare să suprascrie dispecerul.

Curățarea aparține etapei down corespunzătoare. O acțiune up care rescrie DNS sau adaugă rute are nevoie de o anulare documentată, iar un dispecer care se ocupă doar de pornire este jumătate de design.

Confirmați integrarea, nu doar liniștea

Eliminarea avertismentului de duplicat este partea ușoară; integrarea tot trebuie să funcționeze. Verificați starea resolverului după conectare cu resolvectl status sau citind /etc/resolv.conf, și confirmați rutele cu ip route. Apoi deconectați-vă și reconectați-vă, pentru că un hook înlănțuit în grabă tinde să lase ceva din sesiunea anterioară. journalctl -u openvpn-server@server -b arată dacă dispecerul a rulat și ce a afișat.

Păstrați privilegiile hook-ului acolo unde le este locul. Ridicarea script-security sau rularea daemonului cu mai multe drepturi nu este o soluție pentru un hook înlocuit; extinde ce poate face fiecare script viitor, inclusiv unul pe care un atacator ajunge să-l numească.

Semnul că remedierea este reală nu este liniștea în jurnal. Sunt răspunsul DNS, intrarea de rută și curățarea, care funcționează toate după două reconectări.

Articole similare