status=200/CHDIR: a systemd soha nem indította el az OpenVPN-t

A szolgáltatás meghiúsul, a naplók spawnról és könyvtárról beszélnek, és az első ösztön a VPN-konfiguráció ellenőrzése. Abból a fájlból még semmit nem olvastak be. A systemd a folyamat előkészítése közben hibázott, mielőtt a végrehajtható fájl elindult volna, így sem parser, sem tanúsítvány, sem távoli gazdagép nem került lekérdezésre. A státuszkódot a systemdről, nem pedig az OpenVPN-ről szóló állításként olvasni az, ami rövid vizsgálattá teszi ezt.

A státuszkódot az alkalmazás előtt olvassa el

A szolgáltatásnév utáni numerikus kód nevezi meg a meghiúsult szakaszt. A könyvtárhiba CHDIR-státuszként jelenik meg, míg a nem futtatható végrehajtható fájl teljesen más kód. A kettő hasonlónak tűnik egy összegző sorban, és semmi közös nincs az okaikban.

Ez a különbség azért számít, mert a javítások különböző fájlokban vannak. A CHDIR-hiba egy útvonalról és a szolgáltatás annak látásmódjáról szól. Az exec-hiba a binárisról, annak értelmezőjéről vagy egy nem kapcsolódó mountról szól. A VPN távoli pontjának, a rejtjelek listájának vagy a tanúsítvány útvonalának módosítása egyiket sem oldja meg.

Erősítse meg, hogy a hiba az indításkor történik, és nem egy sikeres futás után. Ha a szolgáltatás tegnap működött, és most ugyanabban a szakaszban hibázik, valami megváltozott a könyvtárban, annak engedélyeiben vagy magában az unitban, és ez a változás a keresendő bizonyíték.

Kérdezze meg az unitot, hol akar lenni

Az effektív unitot olvassa, ne a fájlt, amelyet telepítettnek hisz, mert a drop-inek felülírhatják a munkakönyvtárat anélkül, hogy valaha szerkesztené a fő unitot. A show kimenete közvetlenül válaszol a kérdésre:

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

Az upstream szerver sablonnál a munkakönyvtár a szerver konfigurációs könyvtára, és az instance név választja ki a benne lévő profilt. A branch nevű instance tehát a saját fájlját várja ugyanabban a könyvtárban, és a máshol elhelyezett profil egyáltalán nem teljesíti a munkakönyvtár-követelményt.

Hasonlítsa össze, mit kér az unit azzal, ami létezik. Egy korábban létező útvonal, egy most máshova mutató szimbolikus link vagy egy könyvtárral már nem egyező instance név mind olyan szokásos változások, amelyek pontosan ezt a hibát okozzák.

Ellenőrizze az útvonalat úgy, ahogy a szolgáltatás látja

A shellje és a szolgáltatás nem ugyanazt a fájlrendszer-nézetet osztja. Egy beállított gyökérkönyvtár vagy root image megváltoztatja, mit jelent egy abszolút útvonal az uniton belül, és egy a gazdagépen nyilvánvalóan létező útvonal hiányozhat abból a névtérből. Olvassa el az unit beállításait, mielőtt megbízik egy kézi tesztben.

Az engedélyek súlyosbítják a problémát. A szolgáltatás egy meghatározott felhasználóként fut, és ennek a felhasználónak minden szülőkönyvtáron át kell tudnia haladni a cél eléréséhez, nem csak magát a célt olvasni. Egy root számára olvasható, de a szolgáltatás felhasználója számára nem bejárható könyvtár olyan hibát okoz, amely hiányzó útvonalnak tűnik.

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

A megerősítési beállítások is részei ennek a képnek. Az az unit, amely elrejti a home könyvtárakat vagy a fájlrendszer egy részét csak olvashatóvá teszi, pontosan azt teszi, amire beállították, és a munkakönyvtárnak ott kell lennie, ahol a sandbox még láthatóvá teszi.

Javítsa a tulajdonost, aztán várjon másik hibát

Javítsa az elrendezést vagy az unitot azon keresztül, akié az a konfiguráció. Egy profil áthelyezése a várt könyvtárba jogos javítás, ha az elrendezés rossz, de nem magyarázza meg a beléphetetlen könyvtárat, ezért ne kezelje általános válaszként.

Álljon ellen a konfigurációs fa engedélyeinek kiszélesítése vagy a sandbox eltávolítása kínálta rövidítésnek. Mindkettő eltünteti a tünetet, miközben eltávolítja a szándékosan oda helyezett védelmet, és a következő hibát nehezebb lesz értelmezni.

Indítsa újra az instance-t, és olvassa el a következő eseményt, ne feltételezze a sikert. A valószínű következő hiba az, hogy az OpenVPN nem tudja megnyitni a konfigurációs fájlját, ami előrelépés: belépett a munkakönyvtárba, és a parser most fut. Onnan az unit tényleges fájlleképzését kövesse, ne térjen vissza a hálózati hibakereséshez.

A systemd végrehajtási referenciája meghatározza, hogyan értelmezik a munkakönyvtárat a gyökérkönyvtárakkal és a sandboxszal együtt. A megjegyzendő minta egyszerű: minden státuszkód más szakaszt nevez meg, és csak az alkalmazás saját hibái írják le az alkalmazást.