Ostrzeżenie OpenVPN o wielu skryptach --up: działa tylko jeden

Ostrzeżenie o wielu skryptach brzmi jak skarga na planowanie, więc oczywistym rozwiązaniem jest przestawianie wierszy, aż zniknie. To nie jest skarga na planowanie. Późniejsza definicja --up zastępuje polecenie już zapisane dla tego etapu, a parser to mówi, co oznacza, że z twoich dwóch skryptów kiedykolwiek działał dokładnie jeden. Drugi nie czeka w kolejce za nim; on zniknął.

Dlatego ostrzeżenie zasługuje na uwagę, choć nie jest fatalne: zapowiada aktualizację DNS albo zmianę trasy, która po cichu przestała się dziać.

Ostrzeżenie nie dotyczy kolejności

OpenVPN zapisuje jedno polecenie skryptu użytkownika dla etapu up. Gdy parser napotka inną definicję, z profilu, dołączonego pliku lub wiersza poleceń, zastępuje to, co już trzymał, i emituje ostrzeżenie. Nic nie jest łączone, nic nie działa dwa razy i nie istnieje pytanie o kolejność. Przetrwa polecenie, które parser widział ostatnio, dlatego przeniesienie wiersza może zmienić zwycięzcę, a drugi skrypt pozostaje martwy.

Ten sam wzorzec dotyczy pozostałych etapów skryptów: po jednym poleceniu. Jeśli dwa zadania mają się oba wydarzyć, potrzebują jednego punktu wejścia, a nie dwóch dyrektyw przypominających listę.

Znajdź obie definicje w rzeczywistym uruchomieniu

Zacznij od tego, co demon faktycznie otrzymał, a nie od profilu, który edytowałeś. ps -ef i ExecStart jednostki pokazują wiersz poleceń, do którego punkt wejścia kontenera lub wrapper może dodać --up; plik init dystrybucji może zrobić to samo. systemctl cat openvpn-server@server ujawnia, co wnosi sama usługa, a rekurencyjny grep w katalogu konfiguracji znajduje definicje na poziomie plików. Duplikaty zwykle pochodzą z różnych warstw i właśnie dlatego edycja jednego pliku niczego nie zmienia.

Skopiowanie skryptu do innego katalogu lub zmiana jego nazwy też nie usuwa dyrektywy. Parser liczy definicje, a nie pliki.

Niech jeden hook zajmie się pracą

Trwałym rozwiązaniem jest jeden dyspozytor, który wykonuje oba działania w przemyślanej kolejności. Krótki skrypt shell z set -eu, który wywołuje wymaganą integrację, a następnie lokalne działanie i przekazuje "$@", by granice argumentów przetrwały, trzyma zachowanie w jednym miejscu, które można zaudytować. Przekazywanie argumentów tylko je zachowuje; nie dowodzi, że oba pomocniki oczekują tego samego interfejsu, więc przeczytaj kontrakt każdego. Zdecyduj, co ma zrobić błąd i czy częściowe zmiany trzeba wycofać.

Jeśli launcher oferuje obsługiwany hook rozszerzenia, preferuj go zamiast ręcznego łańcucha. Obraz kontenera lub pakiet dostawcy często ma udokumentowane miejsce na dodatkową pracę, a jego użycie nie pozwala aktualizacji nadpisać twojego dyspozytora.

Czyszczenie należy do odpowiedniego etapu down. Działanie up, które przepisuje DNS lub dodaje trasy, wymaga udokumentowanego wycofania, a dyspozytor, który zajmuje się tylko startem, to połowa projektu.

Potwierdź integrację, nie tylko ciszę

Usunięcie ostrzeżenia o duplikacie to łatwa część; integracja nadal musi działać. Sprawdź stan resolvera po połączeniu za pomocą resolvectl status lub czytając /etc/resolv.conf, i potwierdź trasy za pomocą ip route. Potem rozłącz się i połącz ponownie, bo pośpiesznie połączony hook zostawia zwykle coś z poprzedniej sesji. journalctl -u openvpn-server@server -b pokazuje, czy twój dyspozytor działał i co wypisał.

Trzymaj uprawnienia hooka tam, gdzie ich miejsce. Podnoszenie script-security lub uruchamianie demona z większymi prawami nie jest naprawą zastąpionego hooka; poszerza to, co może zrobić każdy przyszły skrypt, w tym taki, który nazwie atakujący.

Znakiem, że poprawka jest prawdziwa, nie jest cisza w logu. To odpowiedź DNS, wpis trasy i czyszczenie, które działają po dwóch ponownych połączeniach.