Środowisko VPN w RAM nie mówi nic o logach

Serwer VPN uruchamiany z obrazu tylko do odczytu i trzymający stan działania w tmpfs to realny i użyteczny projekt. Łatwo też opisać go jako pozbawiony logów, czego projekt nie dowodzi. Miejsce przechowywania decyduje, gdzie żyje kopia; gromadzenie i przechowywanie decydują, czy rekord w ogóle istnieje, a restart dotyczy tylko pierwszego. Rozdzielenie tych dwóch rzeczy to cały przegląd.

Zacznij od wypisania każdego procesu, który może zapisywać stan: demon, usługa uwierzytelniania, dziennik, dowolny agent monitorujący i narzędzia zarządzające.

Przechowywanie i gromadzenie to różne pytania

Każdy zapisujący ma własny cel i własną politykę. Demon VPN zapisuje pliki stanu, backend uwierzytelniania zapisuje zdarzenia konta, dziennik gromadzi wyjście usług, a agent monitorujący wysyła metryki zupełnie gdzie indziej. Projekt, który sprawia, że jedno z nich znika przy restarcie, nie powiedział nic o pozostałych trzech. Śledź każdego zapisującego do celu i zanotuj, czy ten cel jest w ogóle na maszynie.

Pliki specyficzne dla aplikacji, przesłana diagnostyka i usługi zewnętrzne wymagają takiego samego podejścia. Brak znanego lokalnego dziennika nie dowodzi, że rekordy połączeń lub kont nie istnieją nigdzie; dowodzi, że jeszcze nie znalazłeś, dokąd trafiają.

tmpfs nie jest gwarancją

Linux tmpfs nie jest fizycznym dyskiem RAM. Dokumentacja jądra wprost stwierdza, że strony mogą być zapisywane do swapu, gdy montowanie na to pozwala, więc plik tmpfs może trafić na dysk, mimo że aplikacja nigdy go tam nie skopiowała. mount pokazuje, czy w grze jest tmpfs wspierany przez swap, a inne systemy plików w pamięci zachowują się jeszcze inaczej. Czytaj rzeczywiste opcje montowania, zamiast zakładać, że ścieżka pod /run oznacza ulotność.

Następnie zinwentaryzuj rzeczy, które przeżywają restart w sposób, o jakim ludzie zapominają: trwała warstwa nadrzędna, dołączona pamięć masowa, obrazy hibernacji, zrzuty awarii i migawki infrastruktury całej VM. Każda z nich jest potencjalnym celem dla stanu, który uważałeś za efemeryczny. Ta lista jest czymś do sprawdzenia, a nie twierdzeniem, że każdy host ma je wszystkie.

Journald ma dwa cele i przekaźnik

Journald ładnie ilustruje podział. Pamięć ulotna trzyma wpisy w /run/log/journal, trwała w /var/log/journal, a tryb automatyczny wybiera między nimi; obowiązujący tryb pochodzi z działającego systemu, a nie z opisu obrazu. Przełączenie na ulotny nie usuwa tego, co już zapisano trwale. Przekazywanie to także osobny kanał: nawet ustawienie pamięci, które lokalnie nic nie trzyma, może przekazać komunikaty innemu celowi.

Odczytaj obowiązujący tryb z samego dziennika lub jego pliku konfiguracyjnego, a następnie osobno sprawdź cele przekazywania, bo jedno ustawienie nie steruje drugim.

Co musi przetrwać restart

Środowisko bezstanowe pozwala na powtarzalną wymianę i potrzebuje świadomych źródeł konfiguracji, autoryzacji i materiału do odzyskiwania, którego usługa nie potrafi wymyślić. Utrata jedynego działającego stanu rejestracji lub odwołania, aby lokalne zapisy zniknęły, to zły interes, i częsty. Zdecyduj, co ma świadomie przetrwać, a potem sprawdź, że przetrwa.

To samo rozumowanie dotyczy zapisów operacyjnych. Zdecyduj, których zdarzeń bezpieczeństwo i zarządzanie usługami naprawdę wymagają, z uzasadnionym zakresem i przechowywaniem, a resztę zminimalizuj. Minimalizacja to nie to samo co wyłączenie całej diagnostyki.

Porównaj obowiązującą konfigurację przechowywania i przekazywania z kilkoma nieszkodliwymi zdarzeniami, następnie zrestartuj lub wymień maszynę i jeszcze raz sprawdź, co zostało i skąd usługa odzyskała swój stan.