openvpn --errors-to-stderr è un’opzione di avvio, non un errore

Una riga di comando che contiene --errors-to-stderr sembra un reclamo e non lo è. La parola appartiene al nome di un’opzione, proprio come il nome di un file di registro non dice nulla su ciò che il file contiene. Prima di modificare qualsiasi configurazione, stabilite che cosa state leggendo davvero.

La decisione ha tre rami: la riga è l’avvio stesso, la riga è output stampato dal programma, oppure la riga è testo che un wrapper ha ripetuto prima che il VPN partisse. Ogni ramo indica un punto diverso da controllare, e solo uno di essi è il messaggio del VPN stesso.

Il nome di un’opzione non è un messaggio di stato

Per Community OpenVPN, --errors-to-stderr indirizza l’output degli errori sull’errore standard invece che sull’output standard. È una scelta di flusso, non un filtro di gravità, e non crea alcun errore. Un --log o un --log-append successivo può reindirizzare gli stessi messaggi su un file, per questo l’effetto del flag dipende dal resto del comando. La documentazione di logging a monte definisce quell’ordine.

Dunque la presenza del flag dice dove andrebbero gli errori. Non dice che ne sia avvenuto uno.

Riga di avvio o output del processo

Cominciate chiedendovi chi ha stampato il testo. Un’unità di servizio, un bundle applicativo o un wrapper di shell spesso ripetono l’intero argv prima che il processo VPN scriva qualcosa. Quell’eco è indistinguibile da una riga di stato se vedete solo un frammento.

Se la riga viene dal wrapper, il VPN non è ancora stato eseguito e non ha nulla da segnalare. Cercate più in basso nell’output il primo messaggio che porta un timestamp o il nome di un sottosistema.

Se la riga viene dal processo VPN, è comunque solo l’invocazione. OpenVPN non stampa la propria riga di comando come errore, e i messaggi che contano arrivano dopo.

Trovate il processo e il suo risultato

Stabilite se il processo è ancora in esecuzione. Un client attivo che riprova è molto diverso da uno uscito subito, e la stessa riga di comando precede entrambi.

Poi leggete il risultato tramite il componente che possiede il processo. Con systemd è il journal dell’unità; in un’app desktop è il log o la console dell’app stessa. Lo stato di uscita e gli ultimi messaggi rispondono alla domanda che il nome dell’opzione solo suggerisce.

Un errore di analisi della configurazione, un file mancante, una credenziale rifiutata e un timeout del peer sono quattro eventi diversi. Arrivano sullo stesso flusso. Richiedono quattro correzioni diverse. Decidete quale avete prima di toccare il profilo, e citate il messaggio esatto quando chiedete aiuto.

Quando il flag merita il suo posto

Il flag merita il suo posto quando stdout trasporta dati e gli errori non devono contaminarlo, oppure quando un wrapper cattura i due flussi separatamente. In una sessione in primo piano in un terminale, entrambi i flussi arrivano davanti a voi. In quel caso la distinzione raramente cambia ciò che fate.

Tenete l’opzione se lo script circostante dipende dalla separazione. Rimuoverla perché il nome sembra allarmante cambia dove appaiono i messaggi e non corregge nient’altro.

Cosa non cambiare

Non trattate l’opzione come una fase di riparazione. Eliminarla non può correggere un certificato, una route o un errore di autenticazione.

Se l’invocazione contiene --config stdin, la configurazione viene fornita tramite l’input standard. È una decisione separata su come viene fornito il file. Cambiate una cosa alla volta, e rileggete il messaggio reale prima di cambiare la seconda.