Jeden drop-in OpenVPN zmienił każdy tunel: instancja kontra szablon

Zasada ponownego uruchamiania dodana dla jednego tunelu zaczyna obowiązywać każdy tunel na maszynie. To nie błąd systemd; to różnica między drop-inem instancji a drop-inem szablonu. Ścieżka, pod którą zapisujesz plik, decyduje o tym, ile usług go odziedziczy.

Wybierz zakres przed ustawieniem. Oba katalogi wyglądają niemal identycznie, a tylko jeden z nich jest ograniczony do instancji, którą miałeś na myśli.

Objaw: jedna zmiana, każdy tunel

Drop-in właściwy dla instancji leży w katalogu nazwanym od pełnej instancji, na przykład [email protected]. Drop-in szablonu leży w [email protected], ze znakiem @ i bez nazwy instancji pomiędzy. Pierwszy dotyczy tylko office. Drugi dotyczy każdej usługi utworzonej z tego szablonu.

Forma szablonu nie sięga osobnego szablonu [email protected] ani nie dotyczy niepowiązanych usług z openvpn w nazwie.

Wybierz katalog, który pasuje do zakresu

Oba katalogi znajdują się pod /etc/systemd/system/. Pominięcie ostatniego składnika system tworzy ścieżkę, której systemd nie czyta jako nadpisania systemowego, a to cichy sposób, by poprawnie wyglądający plik nic nie robił. Zapisz pełną ścieżkę raz i używaj jej ponownie.

Drop-in potrzebuje też właściwego nagłówka sekcji. Ustawienia usługi należą pod [Service]. Plik z ustawieniami, ale bez sekcji, jest ignorowany lub odrzucany, a jednostka nadal zachowuje się jak wcześniej, podczas gdy plik leży i wygląda dostojnie.

Zachowaj cel w nazwie pliku, jeśli dodajesz więcej niż jeden drop-in. O scaleniu decyduje kolejność leksykograficzna, a nazwa mówiąca, co robi plik, czyni tę kolejność czytelną.

Przeczytaj scaloną jednostkę przed zapisaniem

Przeczytaj scaloną jednostkę, zanim cokolwiek zapiszesz. systemctl cat [email protected] wypisuje jednostkę główną i każdy pasujący drop-in w kolejności scalania. Porównaj ją z drugą instancją, gdy rozważasz zmianę szablonu. To porównanie pokazuje dokładnie, które usługi odziedziczyłyby zmianę.

Plik instancji nie wymazuje ustawień szablonu. Oba są scalane, więc zapomniana wartość szablonu może nadal obowiązywać.

Uczestniczą też inne nazwane drop-iny, ustawienia czasu działania i konfiguracja dostarczana przez pakiety. Nie zakładaj, że ostatnio edytowany plik to cała jednostka. Scalony wynik jest jednostką.

Trzymaj politykę jednostki poza profilem

Trzymaj politykę jednostki i konfigurację VPN osobno. Dyrektywa profilu nie staje się poprawną składnią systemd dlatego, że leży pod [Service]. Ustawienie ponownego uruchamiania też nie należy do pliku .ovpn.

To rozdzielenie jest także powodem, dla którego zasada ponownego uruchamiania nie jest tym samym co odzyskiwanie partnerów, które OpenVPN robi sam. Zdecyduj, jakiego zachowania chcesz, zanim wybierzesz zakres.

Zastosuj to i zweryfikuj instancję

Po zmianie przeładuj definicje menedżera za pomocą systemctl daemon-reload. To przeładowanie nie restartuje tunelu; tylko ponownie czyta pliki jednostek. Następnie zastosuj zamierzoną akcję cyklu życia do dokładnej instancji.

Zweryfikuj, czytając ponownie załadowaną jednostkę i obserwując zmienione zachowanie. Restart, który niesie aktywną pracę, zasługuje na zaplanowaną przerwę, a nie szybki test na tunelu produkcyjnym. Zapisz cel i zakres nadpisania obok wdrożenia, aby następna osoba wiedziała, czy plik miał być współdzielony.

Jeśli zasada naprawdę jest wspólna, przenieś ją świadomie do szablonu i sprawdź drugą instancję, zanim uznasz to za skończone.Dokumentacja jednostek systemd opisuje pierwszeństwo drop-inów i kolejność scalania.