Un sol drop-in d’OpenVPN va canviar tots els túnels: instància versus plantilla

Una política de reinici afegida per a un túnel comença a aplicar-se a tots els túnels de la màquina. No és un error de systemd; és la diferència entre un drop-in d’instància i un drop-in de plantilla. El camí sota el qual escrius el fitxer decideix quants serveis l’hereten.

Tria l’abast abans de la configuració. Els dos directoris semblen gairebé idèntics, i només un d’ells està limitat a la instància que volies.

El símptoma: una edició, tots els túnels

Un drop-in específic d’instància viu sota un directori que porta el nom complet de la instància, com ara [email protected]. Un drop-in de plantilla viu sota [email protected], amb el signe @ i sense cap nom d’instància entremig. El primer s’aplica només a office. El segon s’aplica a tots els serveis instanciats a partir d’aquesta plantilla.

La forma de plantilla no arriba a una plantilla [email protected] separada ni arriba a serveis no relacionats amb openvpn al nom.

Tria el directori que coincideix amb l’abast

Tots dos directoris són sota /etc/systemd/system/. Si ometes el component final system, crees un camí que systemd no llegeix com una substitució del sistema, i aquesta és una manera silenciosa de fer que un fitxer d’aspecte correcte no faci res. Escriu el camí complet una vegada i reutilitza’l.

Un drop-in també necessita la capçalera de secció correcta. La configuració del servei va sota [Service]. Un fitxer amb configuració però sense secció s’ignora o es rebutja, i la unitat continua comportant-se com abans mentre el fitxer és allà amb aspecte d’autoritat.

Mantén el propòsit al nom del fitxer si afegeixes més d’un drop-in. L’ordre lexicogràfic decideix la fusió, i un nom que diu què fa el fitxer fa llegible aquest ordre.

Llegeix la unitat fusionada abans d’escriure

Llegeix la unitat fusionada abans d’escriure res. systemctl cat [email protected] imprimeix la unitat principal i cada drop-in que s’aplica, en ordre de fusió. Compara-la amb una segona instància quan estiguis considerant un canvi de plantilla. Aquesta comparació mostra exactament quins serveis heretarien l’edició.

Un fitxer d’instància no esborra la configuració de la plantilla. Tots dos es fusionen, així que un valor de plantilla que has oblidat encara pot estar en vigor.

Altres drop-ins amb nom, configuració d’execució i configuració subministrada pels paquets també hi participen. No assumeixis que el fitxer que vas editar últim sigui tota la unitat. La sortida fusionada és la unitat.

Mantén la política de la unitat fora del perfil

Mantén separades la política de la unitat i la configuració de VPN. Una directiva de perfil no es converteix en sintaxi systemd vàlida pel fet de ser sota [Service]. Una configuració de reinici tampoc no pertany a un fitxer .ovpn.

Aquesta separació és també la raó per la qual una política de reinici no és el mateix que OpenVPN la seva pròpia recuperació d’igual. Decideix quin comportament vols abans de triar un abast.

Aplica-ho i verifica la instància

Després del canvi, recarrega les definicions del gestor amb systemctl daemon-reload. Aquesta recàrrega no reinicia el túnel; només rellegeix els fitxers d’unitat. Després aplica l’acció de cicle de vida que volies a la instància exacta.

Verifica-ho rellegint la unitat carregada i observant el comportament que has canviat. Un reinici que porta treball actiu mereix una interrupció planificada, no una prova ràpida en un túnel de producció. Anota el propòsit i l’abast de la substitució al costat del desplegament perquè la propera persona sàpiga si el fitxer s’havia de compartir.

Si la política és realment compartida, mou-la deliberadament a la plantilla i comprova una segona instància abans de donar-ho per fet.La referència d’unitats de systemd documenta la precedència dels drop-ins i l’ordre de fusió.