Inicieu OpenVPN des d'una shell amb un fitxer de configuració, i el terminal es queda sense cap sortida. Ni bàner, ni error, ni prompt. L'instint diu que la inicialització ha fallat, així que inicieu una altra còpia, després una altra, i la màquina acaba amb diverses instàncies mig configurades. Abans de res, reviseu el perfil per si hi ha una directiva que ja ha redirigit el registre a un altre lloc. El silenci és una propietat de la consola, no del procés.

El silenci té dues explicacions molt diferents

La primera és que el procés funciona bé i escriu en un fitxer que no mireu. La segona és que ha sortit immediatament amb un error anotat en aquest mateix fitxer.

Totes dues deixen un terminal buit, i una sola pregunta les separa: hi ha un procés ara, i què hi ha al fitxer on se li va dir que escrivís. Responeu això abans de tocar de nou la configuració. Reiniciar per obtenir sortida és com dues instàncies acaben barallant-se per un dispositiu de túnel i el mateix port, cosa que produeix errors que no tenen res a veure amb el problema original.

Trobeu la directiva i després trobeu el procés.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Trobeu la destinació que fa servir el procés en execució

Llegiu el perfil amb què es va iniciar realment el procés, no el que heu editat. Una instància gestionada per un servei normalment carrega un camí diferent i s'executa amb un directori de treball diferent, així que un nom de fitxer relatiu es resol en un lloc que no esperàveu.

Una directiva cd explícita fa més aguda aquesta distinció, perquè el camí relatiu es mou amb el canvi de directori. Si heu heretat aquesta configuració, el fitxer pot ser en un lloc on ara ningú no el buscaria.

Compareu l'hora de modificació del fitxer amb el moment en què el vau iniciar. Un registre de la setmana passada és una prova sobre la setmana passada. Després llegiu les últimes línies del fitxer que ha canviat i tracteu qualsevol cosa que hi hagi com el missatge d'inici que us havíeu perdut.

log versus log-append: prova i esborrat

log-append afegeix al que ja hi ha al fitxer. log obre el fitxer per escriure-hi i el trunca, així que canviar entre tots dos pot esborrar l'execució que anàveu a llegir.

Si algú ha canviat la directiva mentre depurava, la prova anterior ja ha desaparegut i la mida del fitxer semblarà sospitosament petita. Val la pena saber-ho abans de comparar dues execucions i concloure que alguna cosa ha canviat. Esborreu un registre deliberadament o conserveu-lo, però sapigueu què heu fet. Una prova que heu eliminat expressament és més fàcil d'interpretar que una prova que heu perdut per accident.

Cap de les dues opcions crea directoris pares que faltin, ni dona accés a través de permisos del sistema de fitxers o d'una sandbox de servei. Un camí que a la configuració sembla correcte pot continuar sent no escrivible pel compte amb què s'executa el dimoni, i aleshores el dimoni pot fallar abans de poder informar de res. Comproveu que el directori existeixi i qui n'és el propietari abans de suposar que el problema és el nom del fitxer.

Quan un embolcall de servei captura la sortida

Sota systemd, la sortida estàndard i l'error van al journal tret que una directiva de fitxer explícita tingui prioritat, i un embolcall del fabricant pot capturar-los en un lloc completament diferent.

Per això el mateix perfil es comporta de manera diferent des d'una shell i des d'una unitat. L'entorn de la unitat, el seu directori de treball i els seus fluxos estàndard difereixen de la vostra shell interactiva. Un camí relatiu es pot resoldre en un context i no arribar enlloc en l'altre. Llegiu la definició de la unitat quan els dos discrepin, no el perfil.

Compareu les dues maneres d'iniciar-lo en lloc de concloure que una de les dues està trencada. Llegiu la línia d'ordres de la unitat i el seu entorn, i després llegiu el journal per a la mateixa finestra de temps. Si l'embolcall redirigeix la sortida al seu propi fitxer, aquest fitxer és ara el vostre registre, i les directives d'OpenVPN no tenen res a veure amb on han anat els missatges.

Apugeu la verbositat només quan ja la pugueu llegir

Augmentar la verbositat abans de trobar la destinació només produeix més text en un lloc que no mireu.

Un cop sapigueu on va a parar la sortida, un nivell moderat mostra que el perfil s'està analitzant i que s'intenta la connexió. Dos o tres són prou per a un problema d'inici. Els nivells més alts es guanyen el lloc quan la fallada és un detall de la negociació, i també fan créixer el fitxer de pressa.

Després llegiu l'error real. Un terminal silenciós no demostra res sobre si el túnel ha pujat, i la fallada anotada al fitxer és la que val la pena arreglar.

Articles relacionats