status=200/CHDIR: systemd neniam lanĉis OpenVPN

La servo malsukcesas, la protokoloj mencias spawn kaj dosierujon, kaj la unua instinkto estas kontroli la VPN-agordon. Nenio en tiu dosiero ankoraŭ estis legita. systemd malsukcesis dum ĝi preparis la procezon, antaŭ ol la plenumebla dosiero ekfunkciis, do neniu analizilo, neniu atestilo kaj neniu fora gastiganto estis konsultitaj. Legi la statuskodon kiel aserton pri systemd prefere ol pri OpenVPN estas tio, kio igas ĉi tion mallonga enketo.

Legu la statuskodon antaŭ la programo

La nombra kodo post la serva nomo nomas la etapon, kiu malsukcesis. Dosieruja malsukceso estas raportata kiel CHDIR-statuso, dum plenumebla dosiero, kiun oni ne povis ruli, estas tute alia kodo. La du aspektas similaj en resuma linio kaj havas neniom komunan en siaj kaŭzoj.

Tiu distingo gravas, ĉar la riparoj estas en malsamaj dosieroj. CHDIR-malsukceso temas pri vojo kaj pri kiel la servo vidas ĝin. Exec-malsukceso temas pri la binara dosiero, ĝia interpretilo aŭ sendependa muntado. Ŝanĝi la VPN-foran punkton, la ĉifran liston aŭ la atestilan vojon povas solvi nek unu nek la alian.

Konfirmu, ke la malsukceso okazas ĉe la starto kaj ne post sukcesa rulo. Se la servo funkciis hieraŭ kaj nun malsukcesas ĉe la sama etapo, io ŝanĝiĝis pri la dosierujo, ĝiaj permesoj aŭ la unit-o mem, kaj tiu ŝanĝo estas la pruvo, kiun vi serĉu.

Demandu la unit-on, kie ĝi volas esti

Legu la efektivan unit-on anstataŭ la dosieron, kiun vi supozas instalita, ĉar drop-in-oj povas anstataŭigi la laboran dosierujon sen ke vi iam redaktu la ĉefan unit-on. La eligo de show respondas la demandon rekte:

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

Por la supraĵa servila ŝablono, la labora dosierujo estas la servila agorda dosierujo, kaj la nomo de la kazo elektas la profilon interne. Kazo nomata branch do atendas sian propran dosieron en tiu sama dosierujo, kaj profilo metita aliloke tute ne plenumas la postulon pri la labora dosierujo.

Komparu, kion la unit-o postulas, kun tio, kio ekzistas. Vojo, kiu antaŭe ekzistis, simbola ligilo, kiu nun montras aliloken, aŭ kaza nomo, kiu ne plu kongruas kun dosierujo, estas ĉiuj ordinaraj ŝanĝoj, kiuj produktas ĝuste ĉi tiun malsukceson.

Kontrolu la vojon tiel, kiel la servo vidas ĝin

Via ŝelo kaj la servo ne dividas la saman vidadon de la dosiersistemo. Agordita radika dosierujo aŭ radika bildo ŝanĝas, kion absoluta vojo signifas ene de la unit-o, kaj vojo, kiu estas evidente ĉeesta en la gastiganto, povas manki en tiu nomspaco. Legu la agordojn de la unit-o antaŭ ol fidi manan teston.

Permesoj plimalbonigas la problemon. La servo ruliĝas kiel specifa uzanto, kaj tiu uzanto devas povi trapasi ĉiun superan dosierujon por atingi la celon, ne nur legi la celon mem. Dosierujo legebla de root kaj netrapasebla de la serva uzanto produktas malsukceson, kiu aspektas kiel mankanta vojo.

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

Hardigaj agordoj ankaŭ estas parto de ĉi tiu bildo. Unit-o, kiu kaŝas hejmajn dosierujojn aŭ faras parton de la dosiersistemo nurlegebla, faras ĝuste tion, por kio ĝi estis agordita, kaj la labora dosierujo devas troviĝi ie, kie la sablujo ankoraŭ elmontras ĝin.

Riparu la posedanton, poste atendu alian eraron

Korektu la aranĝon aŭ la unit-on per tiu, kiu posedas tiun agordon. Movi profilon en la atendatan dosierujon estas laŭleĝa ripeto, kiam la aranĝo estas malĝusta, sed ĝi ne klarigas dosierujon, en kiun oni ne povas eniri, do ne traktu ĝin kiel la ĝeneralan respondon.

Rezistu la fuŝsolvon larĝigi permesojn ĉe la agorda arbo aŭ forigi la sablujon. Ambaŭ malaperigas la simptomon dum ili forigas la protektojn, kiuj estis metitaj tie intence, kaj la sekva malsukceso estos pli malfacile interpretebla.

Restartu la kazon kaj legu la sekvan okazaĵon anstataŭ supozi sukceson. La verŝajna sekva eraro estas, ke OpenVPN ne povas malfermi sian agordan dosieron, kio estas progreso: oni eniris la laboran dosierujon kaj la analizilo nun funkcias. Sekvu per la reala dosiera mapado de la unit-o de tie anstataŭ reveni al reta problemoserĉado.

La systemd-referenco pri plenumado difinas, kiel la labora dosierujo estas interpretata kune kun radikaj dosierujoj kaj sablujo. La ŝablono memorinda estas simpla: ĉiu statuskodo nomas alian etapon, kaj nur la propraj eraroj de la programo priskribas la programon.