status=200/CHDIR: systemd nigdy nie uruchomił OpenVPN

Usługa zawodzi, logi wspominają o spawn i katalogu, a pierwszy odruch każe sprawdzić konfigurację VPN. Z tego pliku nie odczytano jeszcze niczego. systemd zawiódł podczas przygotowywania procesu, zanim uruchomił się plik wykonywalny, więc nie skonsultowano żadnego parsera, żadnego certyfikatu ani żadnego zdalnego hosta. Odczytanie kodu statusu jako stwierdzenia o systemd, a nie o OpenVPN, zamienia to w krótkie śledztwo.

Przeczytaj kod statusu przed aplikacją

Kod numeryczny po nazwie usługi nazywa etap, który zawiódł. Błąd katalogu jest raportowany jako status CHDIR, natomiast plik wykonywalny, którego nie udało się uruchomić, to zupełnie inny kod. Oba wyglądają podobnie w wierszu podsumowania i nie mają nic wspólnego w swoich przyczynach.

To rozróżnienie ma znaczenie, ponieważ poprawki są w różnych plikach. Błąd CHDIR dotyczy ścieżki i tego, jak widzi ją usługa. Błąd exec dotyczy pliku binarnego, jego interpretera lub niezwiązanego montowania. Zmiana zdalnego punktu VPN, listy szyfrów lub ścieżki certyfikatu nie rozwiąże żadnego z nich.

Potwierdź, że błąd występuje przy starcie, a nie po udanym uruchomieniu. Jeśli usługa działała wczoraj, a teraz zawodzi na tym samym etapie, coś zmieniło się w katalogu, jego uprawnieniach lub samym unicie, i ta zmiana jest dowodem, którego szukasz.

Zapytaj unit, gdzie chce być

Czytaj efektywny unit, a nie plik, który uważasz za zainstalowany, ponieważ drop-iny mogą nadpisać katalog roboczy, nawet jeśli nigdy nie edytowałeś głównego unitu. Wyjście show odpowiada na pytanie bezpośrednio:

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

W szablonie serwera upstream katalog roboczy to katalog konfiguracji serwera, a nazwa instancji wybiera profil w nim. Instancja o nazwie branch oczekuje więc własnego pliku w tym samym katalogu, a profil umieszczony gdzie indziej w ogóle nie spełnia wymogu katalogu roboczego.

Porównaj to, czego wymaga unit, z tym, co istnieje. Ścieżka, która kiedyś istniała, dowiązanie symboliczne wskazujące teraz gdzie indziej lub nazwa instancji, która nie pasuje już do katalogu, to zwykłe zmiany, które powodują dokładnie ten błąd.

Sprawdź ścieżkę tak, jak widzi ją usługa

Twój shell i usługa nie dzielą tego samego widoku systemu plików. Skonfigurowany katalog główny lub obraz główny zmienia znaczenie ścieżki bezwzględnej wewnątrz unitu, a ścieżka, która jest oczywiście obecna na hoście, może nie istnieć w tej przestrzeni nazw. Przeczytaj ustawienia unitu, zanim zaufasz testowi ręcznemu.

Uprawnienia pogarszają problem. Usługa działa jako określony użytkownik, a ten użytkownik musi móc przejść przez każdy katalog nadrzędny, aby dotrzeć do celu, a nie tylko odczytać sam cel. Katalog czytelny dla roota i nieprzechodni dla użytkownika usługi powoduje błąd, który wygląda jak brakująca ścieżka.

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

Ustawienia hartowania również są częścią tego obrazu. Unit, który ukrywa katalogi domowe lub czyni część systemu plików tylko do odczytu, robi dokładnie to, do czego został skonfigurowany, a katalog roboczy musi znajdować się tam, gdzie sandbox wciąż go udostępnia.

Napraw właściciela, potem oczekuj innego błędu

Popraw układ lub unit za pośrednictwem osoby, która jest właścicielem tej konfiguracji. Przeniesienie profilu do oczekiwanego katalogu jest uzasadnioną poprawką, gdy układ jest zły, ale nie wyjaśnia katalogu, do którego nie można wejść, więc nie traktuj tego jako ogólnej odpowiedzi.

Oprzyj się pokusie rozszerzenia uprawnień w drzewie konfiguracji lub usunięcia sandboxa. Oba sprawiają, że objaw znika, jednocześnie usuwając zabezpieczenia, które zostały tam umieszczone celowo, a następny błąd będzie trudniejszy do zinterpretowania.

Uruchom instancję ponownie i odczytaj następne zdarzenie, zamiast zakładać sukces. Prawdopodobny następny błąd to brak możliwości otwarcia pliku konfiguracyjnego przez OpenVPN, co jest postępem: wszedł w katalog roboczy i parser już działa. Śledź stamtąd rzeczywiste mapowanie plików unitu, zamiast wracać do rozwiązywania problemów sieciowych.

Dokumentacja wykonywania systemd określa, jak katalog roboczy jest interpretowany razem z katalogami głównymi i sandboxingiem. Wzorzec do zapamiętania jest prosty: każdy kod statusu nazywa inny etap, a tylko własne błędy aplikacji opisują aplikację.