status=200/CHDIR: systemd ni nikoli zagnal OpenVPN

Storitev odpove, dnevnik omenja spawn in mapo, prvi nagon pa je preveriti konfiguracijo VPN. V tej datoteki še ni bilo nič prebranega. systemd je odpovedal med pripravo procesa, preden se je izvršljiva datoteka zagnala, zato ni bil vprašan noben razčlenjevalnik, nobeno potrdilo in noben oddaljeni gostitelj. Branje statusne kode kot izjave o systemdu namesto o OpenVPN je tisto, kar to spremeni v kratko preiskavo.

Preberite statusno kodo pred aplikacijo

Številčna koda za imenom storitve poimenuje stopnjo, ki je odpovedala. Napaka mape se sporoči kot status CHDIR, medtem ko je izvršljiva datoteka, ki je ni bilo mogoče zagnati, povsem druga koda. Obe sta si v povzetku podobni in v vzrokih nimata nič skupnega.

Ta razlika je pomembna, ker so popravki v različnih datotekah. Napaka CHDIR se nanaša na pot in na to, kako jo storitev vidi. Napaka exec se nanaša na binarno datoteko, njen tolmač ali nepovezan priklop. Sprememba oddaljene točke VPN, seznama šifer ali poti potrdila ne more rešiti nobene od njiju.

Potrdite, da je napaka ob zagonu in ne po uspešnem delovanju. Če je storitev včeraj delovala, zdaj pa odpove v isti stopnji, se je nekaj spremenilo pri mapi, njenih dovoljenjih ali samem unitu, in ta sprememba je dokaz, ki ga iščete.

Vprašajte unit, kje želi biti

Preberite učinkoviti unit, ne datoteke, za katero mislite, da je nameščena, ker lahko drop-in datoteke prepišejo delovno mapo, ne da bi kdaj uredili glavni unit. Izhod show neposredno odgovori na vprašanje:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Pri predlogi strežnika upstream je delovna mapa mapa konfiguracije strežnika, ime instance pa izbere profil v njej. Instanca z imenom branch zato pričakuje svojo datoteko v isti mapi, profil, postavljen drugam, pa zahteve po delovni mapi sploh ne izpolnjuje.

Primerjajte, kaj unit zahteva, s tem, kar obstaja. Pot, ki je nekoč obstajala, simbolna povezava, ki zdaj kaže drugam, ali ime instance, ki se ne ujema več z mapo, so običajne spremembe, ki povzročijo natanko to napako.

Preverite pot tako, kot jo vidi storitev

Vaš shell in storitev si ne delita istega pogleda na datotečni sistem. Nastavljena korenska mapa ali root image spremeni pomen absolutne poti znotraj unita, pot, ki je očitno prisotna na gostitelju, pa lahko v tem imenskem prostoru manjka. Preberite nastavitve unita, preden zaupate ročnemu preizkusu.

Dovoljenja težavo še poslabšajo. Storitev teče kot določen uporabnik, ta uporabnik pa mora lahko preide skozi vsako nadrejeno mapo, da doseže cilj, ne le prebrati cilja samega. Mapa, berljiva za root in neprehodna za uporabnika storitve, povzroči napako, ki je videti kot manjkajoča pot.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Nastavitve utrjevanja so tudi del te slike. Unit, ki skrije domače mape ali del datotečnega sistema naredi samo za branje, dela natanko to, za kar je nastavljen, in delovna mapa mora živeti nekje, kjer jo peskovnik še izpostavlja.

Popravite lastnika, nato pričakujte drugo napako

Popravite postavitev ali unit prek tistega, ki ima to konfiguracijo. Premik profila v pričakovano mapo je upravičen popravek, kadar je postavitev napačna, ne pojasni pa mape, v katero ni mogoče vstopiti, zato tega ne obravnavajte kot splošen odgovor.

Uprite se bližnjici razširitve dovoljenj na konfiguracijskem drevesu ali odstranitve peskovnika. Oboje odpravi simptom, hkrati pa odstrani zaščite, ki so bile tam nameščene namerno, in naslednjo napako bo težje razložiti.

Znova zaženite instanco in preberite naslednji dogodek, namesto da bi predpostavili uspeh. Verjetna naslednja napaka je, da OpenVPN ne more odpreti svoje konfiguracijske datoteke, kar je napredek: v delovno mapo je bilo vstopjeno in razčlenjevalnik zdaj deluje. Od tam sledite dejanskemu preslikavanju datotek unita, namesto da bi se vrnili k omrežnemu odpravljanju težav.

Referenca systemd za izvajanje določa, kako se delovna mapa razlaga skupaj s korenskimi mapami in peskovnikom. Vzorec, ki si ga velja zapomniti, je preprost: vsaka statusna koda poimenuje drugo stopnjo in le lastne napake aplikacije opisujejo aplikacijo.