RAM-дағы VPN runtime журналдар туралы ештеңе айтпайды

Тек оқуға арналған бейнеден жүктелетін және жұмыс күйін tmpfs ішінде ұстайтын VPN сервері шынайы және пайдалы дизайн. Оны журналсыз деп сипаттау да оңай, бірақ дизайн мұны дәлелдемейді. Сақтау орны көшірменің қайда тұратынын анықтайды; жинау мен сақтау жазбаның бар-жоғын анықтайды, ал қайта жүктеу тек біріншісіне әсер етеді. Осы екеуін ажырату — бүкіл шолу.

Күй жаза алатын әрбір процесті тізіп шығыңыз: демон, аутентификация қызметі, журнал, кез келген мониторинг агенті және басқару құралдары.

Сақтау мен жинау — әртүрлі сұрақтар

Әр жазушының өз мақсаты мен өз саясаты бар. VPN демоны күй файлдарын жазады, аутентификация бэкенді аккаунт оқиғаларын жазады, журнал қызметтердің шығысын жинайды, ал мониторинг агенті метрикаларды мүлдем басқа жерге жібереді. Осылардың біреуін қайта жүктеуде жоғалтатын дизайн қалған үшеуі туралы ештеңе айтпаған. Әр жазушыны мақсатына дейін қадағалап, сол мақсаттың машинада бар-жоғын белгілеңіз.

Қолданбаға тән файлдар, жүктелген диагностика және сыртқы қызметтер де сол қатынасты қажет етеді. Таныс жергілікті журналдың болмауы қосылым немесе аккаунт жазбалары еш жерде жоқ деп дәлелдемейді; ол олардың қайда кететінін әлі таппағаныңызды дәлелдейді.

tmpfs — кепілдік емес

Linux tmpfs физикалық RAM дискісі емес. Ядро құжаттамасы беттердің mount рұқсат еткенде swap-қа жазылуы мүмкін екенін анық айтады, сондықтан tmpfs файлы қолданба оны ешқашан көшірмесе де дискіге жетуі мүмкін. mount swap-қа сүйенетін tmpfs-тің жұмыста екенін көрсетеді, ал басқа жад файлдық жүйелері тағы басқаша әрекет етеді. /run астындағы жол уақытшалықты білдіреді деп болжаудың орнына нақты mount параметрлерін оқыңыз.

Содан кейін адамдар ұмытатын тәсілдермен қайта жүктеуден аман қалатын нәрселерді түгендеңіз: тұрақты үстіңгі қабат, қосылған сақтауыш, гибернация бейнелері, апаттық дампілер және бүкіл VM-нің инфрақұрылымдық суреттері. Әрқайсысы сіз эфемер деп есептеген күй үшін ықтимал мақсат. Бұл тізім тексерілетін нәрсе, әрбір хостта бәрі бар деген мәлімдеме емес.

Journald-тың екі мақсаты және бір жіберушісі бар

Journald бөліністі әдемі көрсетеді. Уақытша сақтау жазбаларды /run/log/journal астында, тұрақты сақтау /var/log/journal астында ұстайды, ал автоматты режим екеуінің арасында таңдайды; қолданыстағы режим жұмыс істеп тұрған жүйеден келеді, бейненің сипаттамасынан емес. Уақытшаға ауысу бұрын тұрақты жазылғанды жоймайды. Жіберу де бөлек арна: жергілікті түрде ештеңе ұстамайтын сақтау параметрі де хабарламаларды басқа мақсатқа бере алады.

Қолданыстағы режимді журналдың өзінен немесе оның конфигурация файлынан оқыңыз, содан кейін жіберу мақсаттарын бөлек тексеріңіз, өйткені бір параметр екіншісін басқармайды.

Қайта жүктеуден не аман қалуы керек

Күйсіз runtime қайталанатын ауыстыруды қолдайды және қызмет өзі ойлап таба алмайтын конфигурация, авторизация және қалпына келтіру материалы үшін әдейі көздер қажет. Жергілікті жазбалар жоғалуы үшін жалғыз жұмыс істейтін тіркеу немесе кері қайтару күйін жоғалту — нашар мәміле және жиі кездеседі. Ненің әдейі аман қалуы керегін шешіңіз, содан кейін оның орындалатынын тексеріңіз.

Дәл сол логика операциялық жазбаларға да қатысты. Қауіпсіздік пен қызметті басқару шынымен қандай оқиғаларды қажет ететінін негізделген ауқыммен және сақтау мерзімімен шешіңіз, қалғанын минимумға келтіріңіз. Минимизациялау барлық диагностиканы өшірумен бірдей емес.

Қолданыстағы сақтау және жіберу конфигурациясын бірнеше зиянсыз оқиғамен салыстырыңыз, содан кейін машинаны қайта жүктеңіз немесе ауыстырыңыз және не қалғанын, қызмет күйін қайдан қалпына келтіргенін қайта тексеріңіз.