Un singur drop-in OpenVPN a schimbat toate tunelurile: instanță versus șablon

O politică de repornire adăugată pentru un tunel începe să se aplice tuturor tunelurilor de pe mașină. Nu este o eroare systemd; este diferența dintre un drop-in de instanță și un drop-in de șablon. Calea sub care scrii fișierul decide câte servicii o moștenesc.

Alege domeniul înainte de setare. Cele două directoare arată aproape identic, și doar unul dintre ele este limitat la instanța pe care o aveai în minte.

Simptomul: o singură modificare, toate tunelurile

Un drop-in specific instanței stă sub un director numit după instanța completă, de exemplu [email protected]. Un drop-in de șablon stă sub [email protected], cu semnul @ și fără nume de instanță între ele. Primul se aplică doar la office. Al doilea se aplică fiecărui serviciu creat din acel șablon.

Forma de șablon nu ajunge la un șablon [email protected] separat și nu ajunge la servicii nelegate care au openvpn în nume.

Alege directorul care corespunde domeniului

Ambele directoare sunt sub /etc/systemd/system/. Dacă omiți ultima componentă system, se creează o cale pe care systemd nu o citește ca suprascriere de sistem, iar aceasta este o modalitate tăcută de a face un fișier care arată corect să nu facă nimic. Scrie calea completă o dată și refolosește-o.

Un drop-in are nevoie și de antetul de secțiune corect. Setările serviciului aparțin sub [Service]. Un fișier cu setări dar fără secțiune este ignorat sau respins, iar unitatea continuă să se comporte ca înainte în timp ce fișierul stă acolo și pare autoritar.

Păstrează scopul în numele fișierului dacă adaugi mai mult de un drop-in. Ordinea lexicografică decide fuziunea, iar un nume care spune ce face fișierul face acea ordine lizibilă.

Citește unitatea fuzionată înainte de a scrie

Citește unitatea fuzionată înainte de a scrie orice. systemctl cat [email protected] tipărește unitatea principală și fiecare drop-in aplicabil, în ordinea fuziunii. Compar-o cu o a doua instanță când iei în considerare o schimbare de șablon. Acea comparație arată exact ce servicii ar moșteni modificarea.

Un fișier de instanță nu șterge setările șablonului. Ambele sunt fuzionate, deci o valoare de șablon pe care ai uitat-o poate fi încă în vigoare.

Participă și alte drop-in-uri numite, setări de rulare și configurația furnizată de pachete. Nu presupune că fișierul editat ultima dată este întreaga unitate. Ieșirea fuzionată este unitatea.

Ține politica unității în afara profilului

Ține separat politica unității și configurația VPN. O directivă de profil nu devine sintaxă systemd validă pentru că stă sub [Service]. Nici o setare de repornire nu aparține unui fișier .ovpn.

Această separare este și motivul pentru care o politică de repornire nu este același lucru cu recuperarea partenerilor pe care o face OpenVPN singur. Decide ce comportament vrei înainte de a alege un domeniu.

Aplică-l și verifică instanța

După modificare, reîncarcă definițiile managerului cu systemctl daemon-reload. Acea reîncărcare nu repornește tunelul; doar recitește fișierele de unitate. Apoi aplică acțiunea de ciclu de viață dorită instanței exacte.

Verifică recitind unitatea încărcată și observând comportamentul pe care l-ai schimbat. O repornire care duce muncă activă merită o întrerupere planificată, nu un test rapid pe un tunel de producție. Notează scopul și domeniul suprascrierii lângă implementare, ca următoarea persoană să știe dacă fișierul trebuia partajat.

Dacă politica este într-adevăr partajată, mută-o deliberat în șablon și verifică o a doua instanță înainte de a o declara gata.Referința unităților systemd documentează precedența drop-in-urilor și ordinea fuziunii.