En enda OpenVPN drop-in ändrade varje tunnel: instans mot mall

En omstartspolicy som lagts till för en tunnel börjar gälla för varje tunnel på maskinen. Det är inte en systemd-bugg; det är skillnaden mellan en instans-drop-in och en mall-drop-in. Sökvägen du skriver filen under avgör hur många tjänster som ärver den.

Välj omfånget före inställningen. De två katalogerna ser nästan identiska ut, och bara en av dem är begränsad till instansen du menade.

Symtomet: en ändring, varje tunnel

En instansspecifik drop-in ligger under en katalog som är uppkallad efter den fullständiga instansen, till exempel [email protected]. En mall-drop-in ligger under [email protected], med @-tecknet och utan instansnamn mellan. Den första gäller bara för office. Den andra gäller för varje tjänst som skapas från mallen.

Mallformen når inte en separat [email protected]-mall och når inte orelaterade tjänster med openvpn i namnet.

Välj katalogen som matchar omfånget

Båda katalogerna ligger under /etc/systemd/system/. Om du utelämnar den sista system-komponenten skapas en sökväg som systemd inte läser som en systemöverskridning, och det är ett tyst sätt att få en korrekt utseende fil att göra ingenting. Skriv den fullständiga sökvägen en gång och återanvänd den.

En drop-in behöver också rätt sektionsrubrik. Tjänsteinställningar hör under [Service]. En fil med inställningar men utan sektion ignoreras eller avvisas, och enheten fortsätter att bete sig som tidigare medan filen ligger där och ser auktoritativ ut.

Behåll syftet i filnamnet om du lägger till mer än en drop-in. Lexikografisk ordning avgör sammanslagningen, och ett namn som säger vad filen gör gör den ordningen läsbar.

Läs den sammanslagna enheten innan du skriver

Läs den sammanslagna enheten innan du skriver något. systemctl cat [email protected] skriver ut huvudenheten och varje drop-in som gäller, i sammanslagningsordning. Jämför den med en andra instans när du överväger en malländring. Den jämförelsen visar exakt vilka tjänster som skulle ärva ändringen.

En instansfil raderar inte mallinställningar. Båda slås samman, så ett mallvärde du glömt kan fortfarande gälla.

Andra namngivna drop-ins, körtidsinställningar och konfiguration från paket deltar också. Anta inte att filen du redigerade sist är hela enheten. Den sammanslagna utdata är enheten.

Håll enhetspolicyn utanför profilen

Håll enhetspolicy och VPN-konfiguration åtskilda. Ett profildirektiv blir inte giltig systemd-syntax för att det står under [Service]. En omstartsinställning hör inte heller hemma i en .ovpn-fil.

Den uppdelningen är också anledningen till att en omstartspolicy inte är samma sak som den peer-återställning som OpenVPN gör själv. Bestäm vilket beteende du vill ha innan du väljer ett omfång.

Tillämpa det och verifiera instansen

Efter ändringen, ladda om hanterarens definitioner med systemctl daemon-reload. Den omladdningen startar inte om tunneln; den läser bara om enhetsfiler. Tillämpa sedan livscykelåtgärden du avsåg på den exakta instansen.

Verifiera genom att läsa den inlästa enheten igen och följa beteendet du ändrade. En omstart som bär aktivt arbete förtjänar ett planerat avbrott, inte ett snabbtest på en produktionstunnel. Anteckna överskridningens syfte och omfång intill utrullningen så att nästa person vet om filen var avsedd att delas.

Om policyn verkligen är delad, flytta den medvetet till mallen och kontrollera en andra instans innan du kallar det klart.systemd-enhetsreferensen dokumenterar drop-in-företräde och sammanslagningsordning.