Мониторинг

В процессе обсуждения точки присутствия в интернете (admin-less сервера), всплыла тема мониторинга.

Как показывает мой собственный опыт, известные средства мониторинга, вроде zabbix или open telemetry, могут быть крайне мощным инструментом в руках опытного админа, но абсолютно бесполезны при отсутствии такового.

Собственно проблема та же самая что и при настройке сервисов - мониторятся отдельные параметры, но не проводится никакой содержательной связи между ними, между расходом ресуросов и решаемыми задачами, не ведется автоматического анализа трендов и статистических выбросов, это все должен делать человек, любуясь на красивые графики, которые ему нарисовала система мониторинга.

А для этого человек должен хотя бы некоторое представление иметь о том, что делают подвластные ему сервера. Про проблему разделения ответственности между DBA и админом сервера я слушал разные байки десять лет, работая в фирме, которая помимо всего прочего занималась поддержкой баз данных. Сам, как пользователь сборочно-тестового кластера тоже неоднократно сталкивался с тем, что админы не понимают специфику задач и пытаются оптимизировать то, что отнимает от силы единицы процентов ресурсов, в ущерб тому, что требует 90%.

В наше время (началось это в эпоху Big Data, и продолжилось нейросетями) принято полагаться на алгоритмы обучения без учителя. Мол, если мы напихаем в некую "мясорубку данных" достаточно много данных, дальше она сама сообразит, какие закономерности можно по этим данным вывести.

Как ни странно, по-моему в области мониторинга этот подход может сработать. Если сначала проанализировать систему и более-менее правильно поставить автомату задачи, дальше тот может уже сам отслеживать тренды и ловить статистические флуктуации, не слишком вдаваясь в семантику. Хотя, конечно возможны такие ситуации, что вот система мониторинга выдает алерт, мол, количество отправляемых писем по электронной почте возросло за последнюю неделю в десять раз против обычного, проверьте не спамместкий ли троян сел, а юзер ему "У нас тут конференция на носу, так что вот до такого-то числа повышенная активность это нормально".

Впрочем, подозреваю что достаточно умная система анализаа почтовой статистики поймет, что подготовка конференции это легитимная активность. Видя, что количество входящей почты возросло пропроционально исходящей, и эта входящая не от MAILER-DAEMON.

С мониторингом свободного места на диске примерно то же самое. Достаточно умная система должна отследить как именно расходуется место, и не беспокоить пользователя алертами, если занято 90-95% дисков, но рост в таких пределах, что на ближайшие пару месяцев хватит. И наоборот, начать пугаться, даже если свободна четверть диска, но раз-два в сутки бывают такие задачи, которые временно отжирают почти все свободное место.

То есть можно пытаться состряпать такую систему анализа данных мониторинга системных ресурсов, которая бы выражала свои алерты в терминах, понятных не админу, а пользователю.

X-Post to LJ

О зашифрованных бэкапах

Помнится, еще давно-давно, лет чуть ли не 30 назад хитрый Толченов шифровал бэкапы gpg (или тогда еще pgp была?) собственным отрыкрым ключом. Т.е. запуститься бэкап мог в отсутствии админа, а вот для восстановления нужен был приватный ключ и админ с пассфразой.

В наше время когда бэкапы зачастую делаются на всякие s3 и прочие cloud services криптографиеская защита бэкапа еще более актуальна.

И тут возникает мысль шифровать бэкап открытым ключом ssh. А программа восстановления из бэкапа чтобы понимала протокол ssh-agent.(естественно на самом деле бэкап шифруется случайным симметричным сессиононным ключом, а уже тот с помощью RSA или с помощью общего ключа, выработанного на открытом ключе реципиента и приватном от эфемерной ключевой пары Cм описание EnveloedData )

Т.е. получается полностью прозрачная схема - при бэкапе используется содержимое authorized_keys админа(ов). А при восстановлении, если кто-то из тех чьи ключи были использованы при шифровании, заходит выполнять команду восстановления по ssh с agent forwarding, то ему даже и задуматься не придется о том, что бэкап расшифрован. А вот любому другому - хрен.

Правда, воспользоваться форматом cms не удастся. Ибо у нас тут не сертификаты x509, а ключи ssh, которые идентифицируются в агенте немножко по-другому. Ну так формат нарисовать дело нехитрое.

X-Post to LJ

Upd*: Как отметил tanriol ничего не получится. Нет в протколе ssh-agent команды session key decrypt. У gpg-агента есть, но у него с форвардингом сложности.

Единая база паролей

Тут призадумался о том, как бы избежать хранения одних и тех же паролей одних и тех же юзеров в пяти разных местах с тремя разными способами хэширования. Это не столько к гипотетическому проекту admin-less сервера, сколько к моему собственному серверу.

Сейчас у меня там есть dovecot и postfix. Postfix за аутентификацией ходит к dovecot. Соответственно, протоколы imap, sieve и smtp используют единую базу пользователей. web-мейл, естественно, тоже так как аутентифицируется об imap.

Кроме этого у меня есть несколько областей на веб-сервере, закрытых basic authentication (среди них прокси к radicale, но radicale не использует собственной аутентификации, полагаясь на апачесвкую) и matrix-synapse.

У matrix-synapse есть систеама аутентификационные плагины. А на pypi модуль dovecot который умеет аунтинфицироваться об dovecot'овский sasl. Правда, не обновлялся лет 15. Но в дистрибутиве есть пакет python3-radicale-dovecot-sasl, откуда можно выдрать несколько более свежий код аутентификации через dovecot sasl. Всего 6-летней давности.

Для apache тоже есть mod_authn_dovecot. Тоже не шибко активно развиваемый.

Так что по идее можно пересадить всех на использование dovecot-овского sasl. Я правда, несколько не уверен что это является наилучшим решением. Учитывая, что эти клиенты к довекотовскому sasl какие-то слишком не развивающиеся. В наше время это как-то подозрительно.

Но из других разумных вариантов, которые бы поддерижвались сразу dovecot, postfix, synapse и apache наблюдается по-моему только ldap, а ldap это немножко оверкилл для единственной машины с четырьмя сервисами.

Dovecot, кстати, у меня держит пароли в sqlite. И больше в этой базе не держит ничего.

Upd Подумал, что может быть наиболее правильным решением будет всех (кроме postfix, который с dovecot уже умеет договариваться) аутентифицировать непосредвтсвенно по sqlite-базе с которой работает dovecot, Для apache это точно решается штатными средствами. Если только используемое dovecot-ом шифрование совместимо с apr. А dovecot использует стандартный crypt(3), А для синапса так и так провайдер аутентификации писать.

X-Post to LJ