status=200/CHDIR: hindi kailanman sinimulan ng systemd ang OpenVPN
Ang pagkabigo ng CHDIR ay nangangahulugang hindi nakapasok ang systemd sa isang direktoryo, hindi na hindi nabasa ng OpenVPN ang isang profile. Basahin ang unit bago hawakan ang configuration ng VPN.
Nabigo ang serbisyo, binanggit ng mga log ang isang spawn at isang direktoryo, at ang unang instinto ay suriin ang configuration ng VPN. Wala pang nababasa sa file na iyon. Nabigo ang systemd habang inihahanda ang proseso, bago tumakbo ang executable, kaya walang parser, walang sertipiko at walang remote na host ang nakonsulta. Ang pagbasa sa status code bilang pahayag tungkol sa systemd sa halip na tungkol sa OpenVPN ang dahilan kung bakit nagiging maikling imbestigasyon ito.
Basahin ang status code bago ang aplikasyon
Pinapangalanan ng numeric na code pagkatapos ng pangalan ng serbisyo ang yugtong nabigo. Ang pagkabigo ng direktoryo ay iniuulat bilang CHDIR status, samantalang ang executable na hindi natakbo ay ganap na ibang code. Magkamukha sila sa isang summary line at wala silang pagkakapareho sa mga sanhi.
Mahalaga ang pagkakaibang iyon dahil nasa magkaibang file ang mga pagwawasto. Ang pagkabigo ng CHDIR ay tungkol sa isang landas at kung paano ito nakikita ng serbisyo. Ang pagkabigo ng exec ay tungkol sa binary, sa interpreter nito o sa isang mount na walang kaugnayan. Ang pagbabago ng remote ng VPN, listahan ng cipher o landas ng sertipiko ay hindi makakapag-ayos ng alinman sa dalawa.
Kumpirmahin na ang pagkabigo ay sa pagsisimula at hindi pagkatapos ng matagumpay na pagtakbo. Kung gumana ang serbisyo kahapon at nabigo ngayon sa parehong yugto, may nagbago sa direktoryo, sa mga pahintulot nito o sa unit mismo, at ang pagbabagong iyon ang ebidensyang hahanapin.
Tanungin ang unit kung saan niya gustong naroon
Basahin ang epektibong unit sa halip na ang file na inaakala mong naka-install, dahil ang mga drop-in ay maaaring palitan ang working directory nang hindi mo kailanman in-edit ang pangunahing unit. Ang output ng show ay direktang sumasagot sa tanong:
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
Para sa upstream server template, ang working directory ay ang direktoryo ng configuration ng server at pinipili ng pangalan ng instance ang profile sa loob nito. Ang instance na tinatawag na branch ay umaasa sa sarili nitong file sa parehong direktoryo, at ang profile na inilagay sa ibang lugar ay hindi tumutugon sa pangangailangan ng working directory.
Ihambing ang hinihingi ng unit sa kung ano ang umiiral. Ang landas na dating umiiral, symbolic link na ngayon ay tumuturo sa ibang lugar, o pangalan ng instance na hindi na tumutugma sa isang direktoryo ay pawang karaniwang pagbabago na nagdudulot ng eksaktong pagkabigong ito.
Suriin ang landas gaya ng nakikita ng serbisyo
Hindi pareho ang pananaw ng iyong shell at ng serbisyo sa filesystem. Ang naka-configure na root directory o root image ay nagbabago sa kahulugan ng absolute path sa loob ng unit, at ang landas na malinaw na naroroon sa host ay maaaring wala sa namespace na iyon. Basahin ang mga setting ng unit bago magtiwala sa manu-manong pagsubok.
Pinapalala ng mga pahintulot ang problema. Tumakbo ang serbisyo bilang isang partikular na user, at ang user na iyon ay dapat makadaan sa bawat parent directory upang maabot ang target, hindi lamang mabasa ang target mismo. Ang direktoryo na nababasa ng root at hindi madaanan ng user ng serbisyo ay nagdudulot ng pagkabigo na mukhang nawawalang landas.
namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths
Bahagi rin ng larawang ito ang mga setting ng hardening. Ang unit na nagtatago ng mga home directory o gumagawa ng bahagi ng filesystem na read-only ay ginagawa ang eksaktong nakonfigura para gawin, at ang working directory ay dapat manatili sa lugar kung saan pa ito inilalantad ng sandbox.
Ayusin ang may-ari, pagkatapos asahan ang ibang error
Itama ang layout o ang unit sa pamamagitan ng may-ari ng configuration na iyon. Ang paglipat ng profile sa inaasahang direktoryo ay lehitimong pagwawasto kapag mali ang layout, ngunit hindi nito ipinapaliwanag ang direktoryo na hindi mapasok, kaya huwag itong ituring na pangkalahatang sagot.
Labanan ang shortcut ng pagpapalawak ng mga pahintulot sa configuration tree o pag-alis ng sandbox. Inaalis ng dalawa ang sintomas habang inaalis ang mga proteksiyong sadyang inilagay doon, at ang susunod na pagkabigo ay magiging mas mahirap bigyang-kahulugan.
I-restart ang instance at basahin ang susunod na pangyayari sa halip na ipalagay ang tagumpay. Ang malamang na susunod na error ay hindi mabuksan ng OpenVPN ang configuration file nito, na isang pag-unlad: napasok ang working directory at tumatakbo na ang parser. Sundan mula roon ang tunay na file mapping ng unit sa halip na bumalik sa network troubleshooting.
Tinutukoy ng systemd execution reference kung paano binibigyang-kahulugan ang working directory kasama ng mga root directory at sandboxing. Simple ang pattern na dapat tandaan: pinapangalanan ng bawat status code ang ibang yugto, at tanging ang sariling error ng aplikasyon ang naglalarawan sa aplikasyon.