status=200/CHDIR: systemd het OpenVPN nooit begin nie

Die diens misluk, die logs noem 'n spawn en 'n gids, en die eerste instink is om die VPN-konfigurasie na te gaan. Niks in daardie lêer is nog gelees nie. systemd het misluk terwyl dit die proses voorberei het, voordat die uitvoerbare program geloop het, so geen ontleder, geen sertifikaat en geen afgeleë gasheer is geraadpleeg nie. Om die statuskode te lees as 'n uitspraak oor systemd eerder as oor OpenVPN is wat dit in 'n kort ondersoek verander.

Lees die statuskode voordat jy na die toepassing kyk

Die numeriese kode ná die diensnaam noem die stadium wat gefaal het. 'n Gidsfout word as 'n CHDIR-status gerapporteer, terwyl 'n uitvoerbare lêer wat nie uitgevoer kon word nie 'n heeltemal ander kode is. Dié twee lyk soortgelyk in 'n opsomming en het niks in gemeen in hul oorsake nie.

Daardie onderskeid is belangrik omdat die regstellings in verskillende lêers is. 'n CHDIR-fout gaan oor 'n pad en die diens se siening daarvan. 'n Exec-fout gaan oor die binêre lêer, sy interpreteerder of 'n onverwante mount. Om die VPN-afgeleë punt, die syferlys of die sertifikaatpad te verander kan nie enige van die twee aanspreek nie.

Bevestig dat die fout by die begin is en nie ná 'n suksesvolle loop nie. As die diens gister gewerk het en nou by dieselfde stadium misluk, het iets omtrent die gids, sy regte of die unit self verander, en daardie verandering is die bewys waarna jy moet soek.

Vra die unit waar hy wil wees

Lees die effektiewe unit eerder as die lêer wat jy dink geïnstalleer is, want drop-ins kan die werkende gids oorskryf sonder dat jy ooit die hoof-unit wysig. Die show-uitvoer antwoord die vraag direk:

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

Vir die opstroom-bediener-sjabloon is die werkende gids die bedienerkonfigurasiegids en die instansienaam kies die profiel daarbinne. 'n Instansie genaamd branch verwag dus sy eie lêer in dieselfde gids, en 'n profiel wat elders geplaas is, voldoen glad nie aan die werkende-gids-vereiste nie.

Vergelyk wat die unit vra met wat bestaan. 'n Pad wat vroeër bestaan het, 'n simboliese skakel wat nou elders wys, of 'n instansienaam wat nie meer by 'n gids pas nie, is almal gewone veranderinge wat hierdie presiese fout veroorsaak.

Kontroleer die pad soos die diens dit sien

Jou skulp en die diens deel nie dieselfde lêerstelsel-aansig nie. 'n Gekonfigureerde wortelgids of wortelbeeld verander wat 'n absolute pad binne die unit beteken, en 'n pad wat duidelik op die gasheer bestaan, kan in daardie naamruimte afwesig wees. Lees die unit se instellings voordat jy 'n handmatige toets vertrou.

Regte vererger die probleem. Die diens loop as 'n spesifieke gebruiker, en daardie gebruiker moet elke ouergids kan deurkruis om die teiken te bereik, nie net die teiken self kan lees nie. 'n Gids wat deur root leesbaar is en nie deur die diensgebruiker deurkruisbaar nie, veroorsaak 'n fout wat soos 'n ontbrekende pad lyk.

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

Hardening-instellings is ook deel van hierdie prentjie. 'n Unit wat tuisgidse wegsteek of 'n deel van die lêerstelsel lees-alleen maak, doen presies wat dit gekonfigureer is om te doen, en die werkende gids moet êrens woon waar die sandput dit steeds blootstel.

Maak die eienaar reg, verwag dan 'n ander fout

Korrigeer die uitleg of die unit deur wie ook al daardie konfigurasie besit. Om 'n profiel na die verwagte gids te skuif is 'n geldige regstelling wanneer die uitleg verkeerd is, maar dit verduidelik nie 'n gids wat nie betree kan word nie, so moenie dit as die algemene antwoord behandel nie.

Weerstaan die kortpad om regte op die konfigurasieboom te verbreed of die sandput te verwyder. Albei laat die simptoom verdwyn terwyl die beskermings wat doelbewus daar geplaas is, verwyder word, en die volgende fout sal moeiliker wees om te interpreteer.

Herbegin die instansie en lees die volgende gebeurtenis eerder as om sukses te aanvaar. Die waarskynlike volgende fout is dat OpenVPN nie sy konfigurasielêer kan oopmaak nie, wat vordering is: die werkende gids is betree en die ontleder loop nou. Volg die unit se werklike lêertoewysing van daar af eerder as om terug te keer na netwerk-foutsoeking.

Die systemd-uitvoeringsverwysing definieer hoe die werkende gids saam met wortelgidse en sandputting geïnterpreteer word. Die patroon om te onthou is eenvoudig: elke statuskode noem 'n ander stadium, en net die toepassing se eie foute beskryf die toepassing.