Eén OpenVPN drop-in veranderde elke tunnel: instantie versus sjabloon

Een herstartbeleid dat voor één tunnel is toegevoegd, gaat gelden voor elke tunnel op de machine. Dat is geen systemd-bug; het is het verschil tussen een instantie-drop-in en een sjabloon-drop-in. Het pad waaronder je het bestand schrijft, bepaalt hoeveel services het erven.

Kies het bereik vóór de instelling. De twee mappen lijken bijna identiek, en slechts één ervan is beperkt tot de instantie die je bedoelde.

Het symptoom: één bewerking, elke tunnel

Een instantiespecifieke drop-in staat onder een map die naar de volledige instantie is genoemd, bijvoorbeeld [email protected]. Een sjabloon-drop-in staat onder [email protected], met het apenstaartje en zonder instantienaam ertussen. De eerste geldt alleen voor office. De tweede geldt voor elke service die uit dat sjabloon wordt geïnstantieerd.

De sjabloonvorm bereikt geen aparte [email protected]-sjabloon en bereikt ook geen ongerelateerde services met openvpn in de naam.

Kies de map die bij het bereik past

Beide mappen staan onder /etc/systemd/system/. Als je het laatste system-onderdeel weglaat, ontstaat een pad dat systemd niet als systeemoverschrijving leest, en dat is een stille manier om een correct uitziend bestand niets te laten doen. Schrijf het volledige pad één keer en hergebruik het.

Een drop-in heeft ook de juiste sectiekop nodig. Service-instellingen horen onder [Service]. Een bestand met instellingen maar zonder sectie wordt genegeerd of geweigerd, en de unit blijft zich gedragen zoals voorheen terwijl het bestand daar staat en gezaghebbend lijkt.

Houd het doel in de bestandsnaam als je meer dan één drop-in toevoegt. De lexicografische volgorde bepaalt de samenvoeging, en een naam die zegt wat het bestand doet, maakt die volgorde leesbaar.

Lees de samengevoegde unit voordat je schrijft

Lees de samengevoegde unit voordat je iets schrijft. systemctl cat [email protected] drukt de hoofdunit en elke toepasselijke drop-in af, in samenvoegvolgorde. Vergelijk die met een tweede instantie wanneer je een sjabloonwijziging overweegt. Die vergelijking laat precies zien welke services de bewerking zouden erven.

Een instantiebestand wist geen sjablooninstellingen. Beide worden samengevoegd, dus een sjabloonwaarde die je bent vergeten kan nog steeds van kracht zijn.

Andere benoemde drop-ins, runtime-instellingen en door pakketten geleverde configuratie doen ook mee. Ga er niet van uit dat het bestand dat je het laatst hebt bewerkt de hele unit is. De samengevoegde uitvoer is de unit.

Houd het unitbeleid buiten het profiel

Houd unitbeleid en VPN-configuratie gescheiden. Een profieldirectief wordt geen geldige systemd-syntaxis omdat het onder [Service] staat. Een herstartinstelling hoort ook niet in een .ovpn-bestand.

Die scheiding is ook de reden waarom een herstartbeleid niet hetzelfde is als de peer-herstel dat OpenVPN zelf doet. Bepaal welk gedrag je wilt voordat je een bereik kiest.

Pas het toe en verifieer de instantie

Na de wijziging laad je de definities van de manager opnieuw met systemctl daemon-reload. Dat herladen herstart de tunnel niet; het leest alleen unitbestanden opnieuw. Pas daarna de levenscyclusactie toe die je bedoelde op de exacte instantie.

Verifieer door de geladen unit opnieuw te lezen en het gedrag dat je hebt gewijzigd te volgen. Een herstart die actief werk draagt, verdient een geplande onderbreking, geen snelle test op een productietunnel. Noteer het doel en het bereik van de overschrijving naast de uitrol, zodat de volgende persoon weet of het bestand bedoeld was om te delen.

Als het beleid echt gedeeld is, verplaats het dan bewust naar het sjabloon en controleer een tweede instantie voordat je het af noemt. De systemd-unitreferentie documenteert drop-in-voorrang en samenvoegvolgorde.