OpenVPN het begin maar niks gedruk: kyk eerste na log-append
Stilte by 'n handmatige bekendstelling is nie 'n fout nie. Lees log en log-append in die gelaaide profiel en pas dan die lêer en sy tydstempels by die proses.
Jy begin OpenVPN vanuit 'n dop met 'n konfigurasielêer, en die terminaal sit daar sonder enige uitset. Geen banier, geen fout, geen opdragprompt nie. Die instink sê die bekendstelling het misluk, so jy begin nog 'n kopie, dan nog een, en die masjien eindig met verskeie halfgekonfigureerde instansies. Voordat jy dit doen, kyk in die profiel na 'n opdrag wat die log reeds elders heen gestuur het. Stilte is 'n eienskap van die konsole, nie van die proses nie.
Stilte het twee baie verskillende verklarings
Die eerste is dat die proses goed loop en na 'n lêer skryf waarna jy nie kyk nie. Die tweede is dat dit dadelik afgesluit het met 'n fout wat in dieselfde lêer aangeteken is.
Albei laat 'n leë terminaal, en een vraag skei hulle: is daar nou 'n proses, en wat staan in die lêer waarna dit geskryf is. Beantwoord dit voordat jy weer aan die konfigurasie raak. Om weer te begin net om uitset te kry, is hoe twee instansies oor een tonneltoestel en dieselfde poort begin veg, wat foute lewer wat niks met die oorspronklike probleem te doen het nie.
Vind die opdrag, vind dan die proses.
ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf
Vind die bestemming wat die lopende proses gebruik
Lees die profiel waarmee die proses werklik begin is, nie die een wat jy geredigeer het nie. 'n Diensbestuurde instansie laai gewoonlik 'n ander pad en loop met 'n ander werkgids, so 'n relatiewe lêernaam beland op 'n plek wat jy nie verwag het nie.
'n Eksplisiete cd-opdrag maak daardie onderskeid skerper, want die relatiewe pad skuif saam met die gidsverandering. As jy hierdie konfigurasie geërf het, kan die lêer op 'n plek sit waar niemand dit nou sou soek nie.
Vergelyk die lêer se wysigingstyd met die oomblik toe jy begin het. 'n Log van verlede week is bewyse oor verlede week. Lees dan die laaste reëls van die lêer wat verander het, en beskou wat daar staan as die beginboodskap wat jy misgeloop het.
log teenoor log-append: bewyse en uitwissing
log-append voeg by wat reeds in die lêer is. log maak die lêer oop vir skryf en sny dit af, so om tussen die twee te wissel kan die loop wat jy wou lees, uitwis.
As iemand die opdrag tydens ontfouting verander het, is die vorige bewyse reeds weg en sal die lêer se grootte verdag klein lyk. Dit is goed om te weet voordat jy twee lopies vergelyk en aflei dat iets verander het. Vee 'n log doelbewus uit, of hou dit, maar weet watter een jy gedoen het. Bewyse wat jy opsetlik verwyder het, is makliker om te beredeneer as bewyse wat jy per ongeluk verloor het.
Nie een van die twee opsies skep ontbrekende ouergidse nie, en nie een gee toegang deur lêerstelselregte of 'n dienssandbox nie. 'n Pad wat in die konfigurasie korrek lyk, kan steeds onskryfbaar wees vir die rekening waaronder die daemon loop, en dan kan die daemon misluk voordat dit enigiets kan rapporteer. Kyk of die gids bestaan en wie die eienaar is voordat jy aanneem die lêernaam is die probleem.
Wanneer 'n diensomslag die uitset vasvang
Onder systemd gaan standaarduitset en -fout na die joernaal, tensy 'n eksplisiete lêeropdrag voorrang kry, en 'n verskafferomslag kan hulle heeltemal elders vasvang.
Dit is hoekom dieselfde profiel anders optree vanuit 'n dop en vanuit 'n eenheid. Die eenheid se omgewing, sy werkgids en sy standaardstrome verskil almal van jou interaktiewe dop. 'n Relatiewe pad kan in een konteks oplos en in die ander nêrens beland nie. Lees die eenheidsdefinisie wanneer die twee verskil, nie die profiel nie.
Vergelyk die twee bekendstellingsreëlings in plaas daarvan om af te lei dat een van hulle stukkend is. Lees die eenheid se opdraglyn en sy omgewing, en lees dan die joernaal vir dieselfde tydvenster. As die omslag uitset na sy eie lêer herlei, is daardie lêer nou jou log, en die OpenVPN-opdragte is irrelevant vir waar die boodskappe heen gegaan het.
Draai breedsprakigheid eers op nadat jy dit kan lees
Om breedsprakigheid te verhoog voordat jy die bestemming vind, lewer net meer teks op 'n plek waarna jy nie kyk nie.
Sodra jy weet waar die uitset beland, wys 'n matige vlak dat die profiel ontleed en die verbinding probeer word. Twee of drie is genoeg vir 'n beginprobleem. Hoër vlakke verdien hulle plek wanneer die fout 'n onderhandelingsbesonderheid is, en hulle laat die lêer ook vinnig groei.
Lees dan die werklike fout. 'n Stille terminaal bewys niks oor of die tonnel opgekom het nie, en die fout wat in die lêer aangeteken is, is die een wat die moeite werd is om reg te maak.