Праца VPN у RAM нічога не кажа пра журналы

Сервер VPN, які загружаецца з вобраза толькі для чытання і трымае стан працы ў tmpfs, — гэта рэальны і карысны дызайн. Яго таксама лёгка апісаць як «без журналаў», чаго дызайн не даказвае. Месца захоўвання вызначае, дзе жыве копія; збор і захаванне вызначаюць, ці існуе запіс наогул, а перазагрузка ўплывае толькі на першае. Раздзяленне гэтых двух і ёсць увесь агляд.

Пачніце з пераліку ўсіх працэсаў, якія могуць запісваць стан: дэман, служба аўтэнтыфікацыі, журнал, любы агент маніторынгу і інструменты кіравання.

Захоўванне і збор — розныя пытанні

Кожны запісвальнік мае ўласнае месца прызначэння і ўласную палітыку. Дэман VPN запісвае файлы стану, сэрвіс аўтэнтыфікацыі запісвае падзеі ўліковага запісу, журнал збірае вывад службаў, а агент маніторынгу адпраўляе метрыкі цалкам у іншае месца. Дызайн, які робіць адзін з іх зніклым пры перазагрузцы, нічога не сказаў пра астатнія тры. Прасачыце кожнага запісвальніка да яго месца прызначэння і адзначце, ці гэтае месца наогул на машыне.

Файлы, спецыфічныя для праграм, загружаная дыягностыка і знешнія службы патрабуюць такога ж падыходу. Адсутнасць звыклага лакальнага журнала не даказвае, што запісаў злучэнняў або ўліковых запісаў няма нідзе; яна даказвае, што вы яшчэ не знайшлі, куды яны ідуць.

tmpfs — гэта не гарантыя

Linux tmpfs — не фізічны RAM-дыск. Дакументацыя ядра ясна кажа, што старонкі могуць быць запісаны ў падмену, калі мантаванне гэта дазваляе, таму файл tmpfs можа дасягнуць дыска без таго, каб праграма калі-небудзь капіравала яго туды. mount паказвае, ці задзейнічаны tmpfs з падтрымкай падмены, а іншыя файлавыя сістэмы ў памяці паводзяць сябе яшчэ інакш. Чытайце фактычныя параметры мантавання, а не мяркуйце, што шлях у /run азначае нетрываласць.

Затым праінвентарызуйце рэчы, якія перажываюць перазагрузку так, як людзі забываюць: пастаянны верхні пласт, далучанае сховішча, вобразы гібернацыі, дампы збояў і інфраструктурныя здымкі ўсёй VM. Кожнае з іх — патэнцыйнае месца прызначэння для стану, які вы лічылі эфемерным. Гэты спіс — тое, што трэба праверыць, а не сцвярджэнне, што ў кожнага хоста ёсць усё.

У Journald два месцы прызначэння і перасыльнік

Journald добра ілюструе гэтае раздзяленне. Энергазалежнае сховішча трымае запісы ў /run/log/journal, пастаяннае — у /var/log/journal, а аўтаматычны рэжым выбірае паміж імі; рэжым, які дзейнічае, бярэцца з працуючай сістэмы, а не з апісання вобраза. Пераключэнне на энергазалежнае не выдаляе тое, што ўжо было запісана пастаянна. Перасылка — таксама асобны канал: нават налада сховішча, якая нічога не трымае лакальна, можа перадаць паведамленні іншай мэце.

Чытайце дзеючы рэжым з самога журнала або яго файла канфігурацыі, потым асобна праверце мэты перасылкі, бо адна налада не кіруе другой.

Што павінна перажыць перазагрузку

Працоўнае асяроддзе без стану падтрымлівае паўторную замену, і яму патрэбныя наўмысныя крыніцы для канфігурацыі, аўтарызацыі і матэрыялаў аднаўлення, якія служба не можа выдумаць. Страціць адзіны працоўны стан рэгістрацыі або адклікання, каб лакальныя запісы зніклі, — дрэнная здзелка, і частая. Вырашыце, што павінна застацца наўмысна, потым праверце, што так і ёсць.

Тыя ж развагі тычацца аперацыйных запісаў. Вызначце, якія падзеі бяспека і кіраванне службамі сапраўды патрабуюць, з абгрунтаваным аб'ёмам і тэрмінам захавання, а астатняе мінімізуйце. Мінімізацыя — гэта не тое ж самае, што выключэнне ўсёй дыягностыкі.

Параўнайце дзеючую канфігурацыю сховішча і перасылкі з некалькімі бясшкоднымі падзеямі, потым перазагрузіце або заменіце машыну і зноў праверце, што засталося і дзе служба аднавіла свой стан.