Én OpenVPN drop-in endret hver tunnel: instans mot mal
En drop-in under instanskatalogen berører én tunnel; malkatalogen berører alle. Les den sammenslåtte enheten før du velger en sti.
En omstartspolicy som ble lagt til for én tunnel, begynner å gjelde for hver tunnel på maskinen. Det er ikke en systemd-feil; det er forskjellen mellom en instans-drop-in og en mal-drop-in. Stien du skriver filen under, avgjør hvor mange tjenester som arver den.
Velg omfanget før innstillingen. De to katalogene ser nesten identiske ut, og bare én av dem er begrenset til instansen du mente.
Symptomet: én endring, hver tunnel
En instansspesifikk drop-in ligger under en katalog som er oppkalt etter den fulle instansen, for eksempel [email protected]. En mal-drop-in ligger under [email protected], med @-tegnet og uten instansnavn mellom. Den første gjelder bare for office. Den andre gjelder for hver tjeneste som opprettes fra den malen.
Malformen når ikke en separat [email protected]-mal, og den når ikke urelaterte tjenester med openvpn i navnet.
Velg katalogen som passer til omfanget
Begge katalogene ligger under /etc/systemd/system/. Hvis du utelater den siste system-komponenten, oppstår en sti som systemd ikke leser som en systemoverstyring, og det er en stille måte å få en riktig utseende fil til å gjøre ingenting. Skriv den fulle stien én gang og bruk den på nytt.
En drop-in trenger også riktig seksjonsoverskrift. Tjenesteinnstillinger hører under [Service]. En fil med innstillinger, men uten seksjon, ignoreres eller avvises, og enheten fortsetter å oppføre seg som før mens filen ligger der og ser autoritativ ut.
Behold formålet i filnavnet hvis du legger til mer enn én drop-in. Leksikografisk rekkefølge avgjør sammenslåingen, og et navn som sier hva filen gjør, gjør den rekkefølgen lesbar.
Les den sammenslåtte enheten før du skriver
Les den sammenslåtte enheten før du skriver noe. systemctl cat [email protected] skriver ut hovedenheten og hver drop-in som gjelder, i sammenslåingsrekkefølge. Sammenlign den med en annen instans når du vurderer en malendring. Den sammenligningen viser nøyaktig hvilke tjenester som ville arve endringen.
En instansfil sletter ikke malinnstillinger. Begge slås sammen, så en malverdi du har glemt kan fortsatt være i kraft.
Andre navngitte drop-ins, kjøretidsinnstillinger og konfigurasjon fra pakker deltar også. Ikke anta at filen du redigerte sist, er hele enheten. Det sammenslåtte resultatet er enheten.
Hold enhetspolicyen utenfor profilen
Hold enhetspolicy og VPN-konfigurasjon atskilt. Et profildirektiv blir ikke gyldig systemd-syntaks fordi det står under [Service]. En omstartsinnstilling hører heller ikke hjemme i en .ovpn-fil.
Den atskillelsen er også grunnen til at en omstartspolicy ikke er det samme som den peer-gjenopprettingen som OpenVPN gjør selv. Bestem deg for hvilken atferd du vil ha, før du velger et omfang.
Bruk det og verifiser instansen
Etter endringen, last inn lederens definisjoner på nytt med systemctl daemon-reload. Den innlastingen starter ikke tunnelen på nytt; den leser bare enhetsfiler på nytt. Bruk deretter livssyklushandlingen du mente, på den nøyaktige instansen.
Verifiser ved å lese den innlastede enheten på nytt og ved å følge med på atferden du endret. En omstart som bærer aktivt arbeid fortjener en planlagt avbrytelse, ikke en rask test på en produksjonstunnel. Noter overstyringens formål og omfang ved siden av utrullingen, slik at neste person vet om filen var ment å deles.
Hvis policyen virkelig er delt, flytt den bevisst til malen og kontroller en annen instans før du kaller det ferdig.systemd-enhetsreferansen dokumenterer drop-in-forrang og sammenslåingsrekkefølge.