Un solo drop-in di OpenVPN ha cambiato ogni tunnel: istanza contro modello

Una politica di riavvio aggiunta per un tunnel inizia ad applicarsi a ogni tunnel della macchina. Non è un bug di systemd; è la differenza tra un drop-in d’istanza e un drop-in di modello. Il percorso sotto cui scrivi il file decide quanti servizi lo ereditano.

Scegli l’ambito prima dell’impostazione. Le due directory sembrano quasi identiche, e solo una di esse è limitata all’istanza che intendevi.

Il sintomo: una modifica, ogni tunnel

Un drop-in specifico dell’istanza vive sotto una directory intitolata all’istanza completa, per esempio [email protected]. Un drop-in di modello vive sotto [email protected], con il segno @ e nessun nome di istanza in mezzo. Il primo vale solo per office. Il secondo vale per ogni servizio istanziato da quel modello.

La forma modello non raggiunge un modello [email protected] separato e non raggiunge servizi non correlati che hanno openvpn nel nome.

Scegli la directory che corrisponde all’ambito

Entrambe le directory stanno sotto /etc/systemd/system/. Omettere l’ultimo componente system crea un percorso che systemd non legge come una sostituzione di sistema, ed è un modo silenzioso di far sì che un file dall’aria corretta non faccia nulla. Scrivi il percorso completo una volta e riusalo.

Un drop-in ha anche bisogno dell’intestazione di sezione giusta. Le impostazioni del servizio vanno sotto [Service]. Un file con impostazioni ma senza sezione viene ignorato o rifiutato, e l’unità continua a comportarsi come prima mentre il file se ne sta lì con aria autorevole.

Tieni lo scopo nel nome del file se aggiungi più di un drop-in. L’ordine lessicografico decide l’unione, e un nome che dice cosa fa il file rende quell’ordine leggibile.

Leggi l’unità unita prima di scrivere

Leggi l’unità unita prima di scrivere qualsiasi cosa. systemctl cat [email protected] stampa l’unità principale e ogni drop-in applicabile, in ordine di unione. Confrontala con una seconda istanza quando stai considerando un cambio di modello. Quel confronto mostra esattamente quali servizi erediterebbero la modifica.

Un file d’istanza non cancella le impostazioni del modello. Entrambi vengono uniti, quindi un valore del modello che hai dimenticato può essere ancora in vigore.

Partecipano anche altri drop-in con nome, impostazioni di runtime e configurazione fornita dai pacchetti. Non dare per scontato che il file modificato per ultimo sia tutta l’unità. L’output unito è l’unità.

Tieni la politica dell’unità fuori dal profilo

Tieni separate la politica dell’unità e la configurazione VPN. Una direttiva di profilo non diventa sintassi systemd valida perché sta sotto [Service]. Un’impostazione di riavvio non appartiene nemmeno a un file .ovpn.

Questa separazione è anche il motivo per cui una politica di riavvio non è la stessa cosa del recupero dei peer che OpenVPN fa da sé. Decidi quale comportamento vuoi prima di scegliere un ambito.

Applicalo e verifica l’istanza

Dopo la modifica, ricarica le definizioni del gestore con systemctl daemon-reload. Quel ricaricamento non riavvia il tunnel; rilegge solo i file delle unità. Poi applica l’azione del ciclo di vita che intendevi all’istanza esatta.

Verifica rileggendo l’unità caricata e osservando il comportamento che hai cambiato. Un riavvio che porta lavoro attivo merita un’interruzione pianificata, non un test rapido su un tunnel di produzione. Annota lo scopo e l’ambito della sostituzione accanto al deployment, così la persona successiva sa se il file doveva essere condiviso.

Se la politica è davvero condivisa, spostala deliberatamente nel modello e controlla una seconda istanza prima di dichiararla finita. La documentazione delle unità di systemd documenta la precedenza dei drop-in e l’ordine di unione.