L’avviso di OpenVPN su più script --up: solo uno viene eseguito

L’avviso su più script suona come una lamentela sulla pianificazione, quindi la correzione ovvia è riordinare le righe finché non scompare. Non è una lamentela sulla pianificazione. Una definizione successiva di --up sostituisce il comando già memorizzato per quella fase, e l’analizzatore lo dice, il che significa che dei vostri due script se n’è mai eseguito esattamente uno. L’altro non è in coda dietro di esso; è sparito.

Ecco perché l’avviso merita attenzione anche se non è fatale: ciò che prevede è un aggiornamento DNS o un cambio di rotta che ha smesso silenziosamente di avvenire.

L’avviso non riguarda l’ordine

OpenVPN memorizza un solo comando di script utente per la fase up. Quando l’analizzatore incontra un’altra definizione, dal profilo, da un file incluso o dalla riga di comando, sostituisce ciò che già teneva ed emette l’avviso. Nulla viene concatenato, nulla viene eseguito due volte e non esiste alcuna questione di ordine. Il comando che sopravvive è quello visto per ultimo dall’analizzatore, per questo spostare una riga può cambiare il vincitore lasciando l’altro script morto.

Lo stesso schema vale per le altre fasi di script: un comando ciascuna. Se due lavori devono entrambi accadere, hanno bisogno di un unico punto di ingresso, non di due direttive che somigliano a un elenco.

Trovate entrambe le definizioni nell’avvio reale

Partite da ciò che il demone ha realmente ricevuto, non dal profilo che avete modificato. ps -ef e la ExecStart dell’unità mostrano la riga di comando, che può aggiungere --up da un punto di ingresso di un container o da un wrapper; un file init di una distribuzione può fare lo stesso. systemctl cat openvpn-server@server rivela ciò che il servizio stesso apporta, e un grep ricorsivo nella directory di configurazione trova le definizioni a livello di file. I duplicati di solito provengono da livelli diversi, ed è proprio per questo che modificare un solo file non cambia nulla.

Copiare uno script in un’altra directory o rinominarlo non elimina neanche una direttiva. L’analizzatore conta le definizioni, non i file.

Che un solo hook si occupi del lavoro

La soluzione duratura è un unico dispatcher che esegue entrambe le azioni in un ordine deliberato. Un breve script shell con set -eu che chiama l’integrazione richiesta e poi l’azione locale, passando "$@" perché i confini degli argomenti sopravvivano, mantiene il comportamento in un unico posto verificabile. Passare gli argomenti li preserva soltanto; non dimostra che i due aiutanti si aspettino la stessa interfaccia, quindi leggete il contratto di ciascuno. Decidete cosa deve fare un errore e se le modifiche parziali vanno annullate.

Se l’avviatore offre un hook di estensione supportato, preferitelo all’incatenamento fatto a mano. Un’immagine di container o un pacchetto del fornitore ha spesso un luogo documentato per lavoro aggiuntivo, e usarlo impedisce a un aggiornamento di sovrascrivere il vostro dispatcher.

La pulizia appartiene alla fase down corrispondente. Un’azione up che riscrive il DNS o aggiunge rotte ha bisogno di un annullamento documentato, e un dispatcher che gestisce solo l’avvio è mezzo progetto.

Confermate l’integrazione, non solo il silenzio

Rimuovere l’avviso di duplicato è la parte facile; l’integrazione deve comunque funzionare. Controllate lo stato del resolver dopo la connessione con resolvectl status o leggendo /etc/resolv.conf, e confermate le rotte con ip route. Poi disconnettete e riconnettete, perché un hook incatenato in fretta tende a lasciare qualcosa della sessione precedente. journalctl -u openvpn-server@server -b mostra se il vostro dispatcher è stato eseguito e cosa ha stampato.

Tenete i privilegi dell’hook dove devono stare. Alzare script-security o eseguire il demone con più diritti non è una soluzione per un hook sostituito; amplia ciò che può fare ogni script futuro, incluso uno che un attaccante potrà nominare.

Il segno che la correzione è reale non è il silenzio nel registro. È la risposta DNS, la voce di rotta e la pulizia che funzionano tutte dopo due riconnessioni.