ServerAdmin.ru

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились.

⇨ Postgresus - удобный домашний бекап баз данных
Коротенький обзор веб панели программы для бэкапа PostgreSQL серверов. Выглядит удобно и полезно. Скорее всего тоже попробую и сделаю отдельный обзор. Бэкапы она делает только полные, так что подойдёт только для небольших баз. У меня есть сервера, где как раз куча небольших баз 1С. Возможно, с этой панелькой будет удобно их бэкапить и быстро восстанавливать.

⇨ Self-Host Your Own Automation Platform with n8n + Docker
Очередной обзор и примеры использования платформы для автоматизации n8n. Это очень популярная и функциональная штука. Я пару раз за неё садился и пытался к чему-нибудь приспособить, но ничего дельного не получалось. Её на самом деле с наскока трудно освоить, хоть она и позиционируется как простое no-code решение. Кто не знаком с ней, рекомендую посмотреть. Может приспособите её куда-то к себе.

⇨ Сжатие текста в Angie: статика, динамика, производительность
Обзор и тесты различных режимов сжатия в веб сервере. Я всё это неплохо знаю и в своё время тестировал и использовал различные алгоритмы: gzip, brotli, zstd. Про последний делал отдельную заметку с описанием настройки. Я лично почти везде включаю zstd на веб серверах.

⇨ Zabbix 7.4 Host Wizard Overview
Видео актуально, если вы не собираетесь обновляться до 7.4, но хотите посмотреть, как выглядит новый интерфейс добавления хостов в Zabbix Server.

⇨ OAuth 2.0 — Простым языком на понятном примере
Автор подробно и с примерами показал, как работает OAuth и OpenID Connect. Часто упоминаю эти технологии, когда рассказываю про тот или иной софт. Если не знаете, что это такое, то посмотрите видео.

⇨ Grafana Alloy, NEW log + metric collector replaces everything!
Обзор инструмента Grafana Alloy. Думал это что-то новое, но не особо то и новое. Год уже точно существует. Честно говоря, впервые услышал про этот продукт. Никогда не видел и не слышал. Он собирает логи и метрики. По сути это аналог promtail, opentelemetry collector и т.д.

⇨ ALT Linux 10 установка КриптоПРО 5 с поддержкой ключей от 4-й версии
Настройка работы КриптоПРО на рабочей станции ALT.

⇨ Устанавливаем Fedora Server 42 — Идеальный дистрибутив для self-hosting?
Практической пользы нет, но мне было любопытно посмотреть. Вообще не знал, что у Fedora есть сервер. После видео так и не понял, зачем он нужен.

⇨ Прямое подключение NAS к ПК по 10GbE
Видео простенькое, для обычных пользователей. Но мне было интересно посмотреть, что за адаптеры с подключением по usb-c используются для этого (цена ~6 т.р.), какие провода и т.д. На практике я вообще никогда не настраивал такие интерфейсы. Были кое-где на арендных серверах, но там настраивать ничего не надо. Сразу выдают настроенные.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#видео

У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:

⇨ Проверка безопасности Docker образов с помощью Trivy

Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.

TruffleHog поддерживает следующие источники информации:

◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры

И некоторые другие источники. Не стал их все перечислять.

Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.

Работает примерно так:

# trufflehog git https://github.com/trufflesecurity/test_keys

Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:

# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin

Можно просто в Docker запустить:

# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.

Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:

# trufflehog filesystem --config=$PWD/generic.yml /var/log

Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.

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

⇨ 🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops #cicd #security

Казалось бы, ну кто не знает в наше время, что нужно делать и проверять бэкапы? Куча инструментов есть, в том числе бесплатных. Но это всё слабо помогает. Через меня проходит много всевозможных историй, поэтому решил в очередной раз рассказать о них и напомнить про бэкапы.

1️⃣ Читал статью на хабре, как разработчик случайным запросом очистил базу пользователей и похоронил коммерческий проект, так как бэкап был месячной давности.

2️⃣ Мне в личные сообщения написал человек и попросил помочь. У него умер рейд массив на контроллере домена. Он бэкапился встроенным резервным копированием винды. При восстановлении оказалось, что ничего не восстанавливается, система пишет, что не видит бэкапа в указанном месте.

В обоих случаях бэкапы вроде бы и делались, но не проверялись. По факту оказалось, что их нет.

3️⃣ Эта история более насыщенная, так как я в ней лично поучаствовал. Обратился старый заказчик, которому я несколько лет назад настраивал инфраструктуру. Но не поддерживал её. Если кому-то что-то настраиваю, то сразу предупреждаю, что поддерживать не буду. У меня нет такой возможности. Всё аккуратно передаю и объясняю, чтобы дальше без моего участия можно было вести дела.

Но тут сделал исключение. Был поздний вечер, уже собирался спать, всё выключил. Ну и как обычно проверил Telegram. А там умер виндовый сервер с кучей баз 1С. Утром придут люди и «прибьют меня».

Базы были как файловые, так и в MSSQL. Бэкапы файловых баз были, скульных – свежих нет. Но бэкап это пол дела. Системы то самой нет. Надо всё с нуля поднимать и настраивать, восстанавливать лицензии, делать публикации. На дворе ночь, подменного сервера нет.

Сервер вёл себя странно. Он нормально загружался до своей заставки с часами. А дальше ни на что не реагировал. Если раз 10 нажать CTRL+ALT+Delete, падает в чёрный экран и больше ни на что не отвечает. Но при этом курсор двигается, активен порт RDP, но удалённые соединения не устанавливаются. Залогиниться не получалось даже локально.

Загрузился в режиме восстановления, успешно зашёл в систему. Весь системный лог в ошибках. Службы не запускаются, какие-то файлы недоступны, на диске ошибки. Но при этом sfc /scannow и DISM /Online /Cleanup-Image /RestoreHealth ошибок не показывают.

Запускаю chkdsk C: /f /r и перезагружаю. Во время проверки долго висит на 15%, по графикам VM видно, что очень активно шерстит NVME дисками. В итоге проверка до конца не доходит, аварийно вырубается и система заново загружается с теми же проблемами.

Я не верил, что эту систему можно оживить. Слишком много каких-то неведомых проблем. Заказчик предложил удалить программу Обновлятор-1С, так как впервые система зависла и начались проблемы во время её работы. Я знаю эту программу. Она довольно старая и известная. Cам не раз пользовался. Каких-то глобальных проблем с ней не видел. Стояла купленная лицензионная версия.

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

☝️ Мораль тут какая? Бэкапить надо не только данные, но и системы. Иначе в час ИКС ты просто не будешь знать, что тебе делать. Надо искать и железо, и систему восстанавливать. А потом на неё данные накатывать. Это очень долго. Наверняка окажется, что и версий подходящих нет. Я практически всегда делаю бэкап и виртуальной машины и отдельно данных. Ну и по возможности всё это проверяю. Если не проверять, то очень велика вероятность, что в час ИКС ничего восстановить и не получится. Бэкапы могут месяцами не создаваться или создаваться битыми. Для баз данных это очень актуальная тема.

Кстати, описанная инфраструктура была построена примерно вот так. Уже не первый раз убеждаюсь, что это работает просто и надёжно. И почти не требует обслуживания. Главное, бэкапы данных и виртуальных машин делать.

#backup

📊 2 недели назад проводил опрос на тему использования операционных систем на рабочих машинах и серверах. Было интересно сравнить с такими же опросами в прошлом году.

На удивление, за год существенных изменений нет. Результаты очень близкие с учётом погрешности. Единственный момент – я ошибся в TG с опросом ОС на серверах. В прошлом году разрешил выбрать несколько вариантов, а в этом только один. Из-за этого в лоб сравнить 2 года не получится, но по общей картине видно, что изменений там особо нет.

Ожидал, что доля Linux на рабочих машинах подрастёт, а MacOS снизится, но этого не произошло. Также думал, что заметно снизится доля Windows серверов. В результатах TG это заметно, но очень незначительно, что на такой выборке выглядит как погрешность. А в VK вообще без изменений.

Среди российских дистрибутивов неожиданно было увидеть высокую долю Red OS, очень близкую к Alt. Честно говоря, думал, что в лидерах будет именно он, а не Astra. На деле Астра – безоговорочный лидер.

Свёл результаты обоих лет на картинках снизу с разбивкой на Telegram и VK.

#опрос

На днях почувствовал себя пользователем vi или vim, который не знает, как из него выйти. Установил на винду консольный редактор MSEdit:

> winget install Microsoft.Edit

Подсказали в прошлой заметке про sudo в Windows. Честно говоря вообще впервые про него услышал. Это что-то из далёкого прошлого. Редактор из системы MS-DOS. Я её не застал. Сознательный возраст встретил с Windows 95.

Запускается в командной строке:

> edit readme.txt

Зашёл, а выйти не могу. Понятно, что в Windows всё намного проще. Можно просто окно закрыть. Тем не менее, стал перебирать различные комбинации. Ничего из привычного не подошло. Я не понял ни как выйти, ни как открыть верхнее меню. Комбинации клавиш не совпадают с теми, к которым привык в Linux.

В верхнее меню можно попасть через Alt и любую из указанных клавиш. А можно просто мышкой туда тыкнуть. Как оказалась, в этот консольный редактор добавили поддержку мышки.

Для винды выглядит максимально непривычно. Не знаю, будет ли это кому-то удобно. Мне кажется, оживили проект больше по приколу, нежели для развития какой-то функциональности, в отличии от sudo. Я пользоваться точно не буду, потому что горячие клавиши непривычны. Автоматом жму Ctrl + X или F10, чтобы выйти. А первая комбинация в edit вырезает строку.

#windows

Вопрос управлением памятью в Linux непростой. У меня уже были в разное время заметки по этой теме. Причём он не только технический, но и организационный. Как раскидать сервисы по виртуалкам и контейнерам? Всегда придётся искать баланс, потому что максимально всё подробить не обязательно будет удобно и эффективно. Но при любом раскладе нужно будет настраивать сами приложения. Покажу на нескольких примерах, как это выглядит на практике у меня.

1️⃣ Начну с MySQL. В качестве калькулятора при подборе настроек я использую MySQLTuner. Он много всего может проверить и посоветовать, но без глубокого понимания работы СУБД, лучше лишний раз не трогать настройки.

Мне главное понять, сколько памяти съест СУБД, если её максимально нагрузить при текущих параметрах. Это MySQLTuner как раз наглядно покажет. Подробно все настройки, на которые стоит обратить внимание в этом контексте, я разбирал в отдельной заметке. Не буду повторяться. Надо настроить так, чтобы MySQL не запросила памяти больше, чем есть на сервере, либо можно позволить выделить с учётом других сервисов, если они там есть. Параметры подбираются по ситуации.

Для PostgreSQL есть много конфигураторов, которые по заявленным характеристикам сервера сами посоветуют параметры, в том числе относящиеся к потреблению памяти. Мне больше всего нравится pgconfigurator.cybertec.at (хостится за CF, нужен VPN).

Есть софт попроще в плане настроек потребления памяти. Например, в Elasticsearch, Redis, Memcached можно одним параметром ограничить память, которую приложение будет использовать.

2️⃣ Дальше у нас идут приложения, которые в зависимости от нагрузки запускают разное количество экземпляров. Наглядным примером тут выступает php-fpm. Его нужно ограничить по количеству процессов, которые он может запустить в пределах отведённой ему памяти. Для этого надо понять, а сколько памяти в текущих условиях занимает один процесс?

Вопрос этот нетривиальный, так как у нас есть общая память, виртуальная память, реальная память. Форки одного процесса частично используют общую память и поэтому в лоб посмотреть в top или htop, сколько один процесс использует реальной памяти, не получится. Хотя для грубого подсчёта может и сойти. Более точно это можно определить с помощью pmap. У меня была подробная заметка, где я на конкретном примере показал, как это сделать. Это руководство подойдёт для всех подобных приложений.

3️⃣ Отдельно идут приложения, которые не имеют своих настроек потребления памяти. Плюс, они не форкаются под выросшей нагрузкой. Наглядные примеры таких приложений - Nginx, Postfix, Dovecot. Сюда же можно отнести какие-то самописные скрипты, или тот же Fail2Ban. Последнего надо обязательно ограничивать, так как он легко может повесить сервер под нагрузкой.

Если мы хотим для таких приложений настроить ограничения, то можем воспользоваться настройками systemd. Их там несколько, можно очень гибко всё настроить. При определённом лимите можно ограничивать выделение памяти, а если не поможет, то перезапустить сервис или прибить. Тоже подробно это описывал ранее.

☝️ Может показаться, что контейнеры как раз и придумали в том числе для того, чтобы изолировать приложения друг от друга и ограничивать в ресурсах, и не тратить время на тонкую настройку. Частично да, в том числе для этого и придумали. Третий тип приложений отлично ограничивается на уровне выделенных ресурсов, но первые два, особенно СУБД, всё равно для стабильной работы нужно предварительно настроить под выделенные ресурсы.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#perfomance

Какое-то дёрганное лето получается. Новые проблемы сыпятся, как из рога изобилия. Жара что ли на сервера так влияет? Расскажу историю очередной проблемы, с которой столкнулся. Там есть несколько поучительных моментов.

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

Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.

У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.

В настройках systemd юнита Redis указан параметр Restart=always. Подробно на эту тему я делал отдельную заметку. Рекомендую ознакомиться, если не знаете. Данный параметр означает, что при любой причине завершения работы службы будет попытка поднять её. Я упоминал в той заметке, что не всегда это бывает полезно. И это как раз мой случай.

Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.

В общем случае с параметром Restart=always служба должна подняться автоматически. Я потестировал немного на отдельной виртуалке. Если Редису дать команду SIGSEGV, то он так же, как у меня вышло, скидывает свой трейс в лог, завершает работу и запускается заново. Проверить можно так:

# kill -SIGSEGV $(pidof redis-server)

Но как я уже сказал, у меня что-то пошло не так. В данном случае было бы лучше, если бы он тихо помер и не мучал больше сервер. Помогло в итоге то, что я туром проснулся, вручную остановил его и запустил заново:

# systemctl stop redis-server
# systemctl start redis-server

Так что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.

Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром Restart.

Я в итоге снизил потребление памяти у некоторых служб, чтобы избежать ситуаций, когда память вся закончится. Буду наблюдать. Надеюсь, что проблема не повторится.

#linux #systemd #ошибка

Небольшая зарисовка-совет из моего недавнего опыта по настройке шаблона в Zabbix Server. В настройках айтема можно использовать предобработку, которая называется Отбрасывать не изменившееся. По названию уже понятно, что она делает – не записывает новое значение, если оно не отличается от прошлого. Я везде, где можно, использую эту предобработку, потому что она существенно экономит место в базе данных, особенно если речь идёт про какие-то длинные строки в логах или другие редко изменяемые данные.

В то же время в функциях триггеров есть функция nodata, которая проверяет время последнего поступления данных. И если данные не поступали дольше заданного периода, она активирует триггер. Эта функция проверяет поступление данных на основе последней записи айтема в базе, а не самого факта поступления данных от агента. И если предобработка отбрасывает не изменившееся значение, функция nodata считает, что его не было.

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

Эта два значения надо правильно подобрать, чтобы проверка работала корректно. У предобработки время периодического контроля, когда значение в любом случае будет записано, даже если не изменилось, должно быть меньше, чем интервал в прошлое у функции nodata. Тогда всё это будет корректно работать.

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

Если не знаете и не используете описанную функциональность в мониторинге, советую обратить внимание. Предобработка существенно экономит место в базе, а функция nodata страхует вас от ситуации, когда новые данные просто не приходят, а вы думаете, что у вас всё в порядке, потому что на основе старых данных триггер не видит проблем. А на деле, к примеру, бэкапы просто не выполняются.

#zabbix

Часто слушал эту прикольную песенку НТР. Такой подход к делу и материшну в целом не одобряю, но песня забавная. И при этом особо не обращал внимание на вступление.

Плиз коммит ченджес иммидиатли, асап.

Тут вроде понятно, о чём идёт речь, хотя что такое асап тоже не знал. А дальше думал, идёт какой-то набор слов просто для красного словца.

Сума сандаран cамалан бабан.

И только недавно я понял, что тут речь идёт об имени и фамилии какого-то индуса Сумасандаран Самаланбабан. Увидел где-то обсуждение индусских имён и вспомнил, что в песне был не набор бессмысленных слов, а индусское имя 😀

То есть полностью вступление звучит так:

Please, commit changes immediately asap (As Soon As Possible),
Sumasandaran Samalanbaban.

Что означает в вольном переводе: "Пожалуйста, внесите исправления немедленно, Сумасандаран Самаланбабан."

#юмор #музыка

Дискуссионная пятничная тема. Недавно общался с человеком, который просил помощи с Windows Server и Hyper-V. И приводил свои ошибки из логов на русском языке. Те, кто много работал с Windows серверами, наверное уже поняли, о чём пойдёт речь.

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

Не так давно столкнулся с тем, что если в консоли Linux стоит русская локаль, то Mariadb начинает в лог писать ошибки на русском языке. По ним ничего дельного потом не найти. Это очень неудобно. То же самое с PostgreSQL. Если СУБД стоит на одном сервере с сервером 1С, который требует русскую локаль, то тоже все логи PostgreSQL будут на русском языке. Хотя конкретно в PostgreSQL перевод очень качественный, но так бывает не везде.

Язык современной техносферы – английский и с этим приходится считаться. Если у вас возникает какая-то ошибка, то в англоязычном интернете, пока он ещё доступен, вы найдете в разы больше материала по ней.

Русский язык обычно нужен пользователям, которые работают с системой. Некоторые начинающие инженеры тоже ставят русский язык в надежде, что это упростит им настройку и эксплуатацию. Но на деле он только осложнит, если начнутся какие-то проблемы и ошибки. Так что рекомендую везде использовать английский.

#разное

Ранее я упоминал про утилиту Lynis, а также то, как я её использую в связке с Zabbix для предупреждения о каких-то проблемах на хостах. С момента написания статьи я немного поменял подход к сбору данных. Расскажу кратко, как это у меня сейчас работает. Я с тех пор постоянно использую эту связку. Мне нравится, как она работает.

Кратко поясню суть того, что делаю и для чего. Утилита Lynis есть в стандартных репах. Она делает некоторый набор проверок системы и пишет отчёт в лог. Конкретно меня от неё интересуют две вещи:

◽️Вывод предупреждений. Например, о том, что систему надо перезагрузить после обновления ядра, либо о том, что есть уязвимые пакеты.
◽️Список пакетов с уязвимостями, для которых доступны обновления.

С помощью Zabbix я анализирую лог Lynis и прямо на почту отправляю текст замечаний и уязвимых пакетов, если они есть. Реализую это следующим образом:

1️⃣ Делаю простой скрипт, который запускает Lynis и анализирует код завершения работы. У этой программы он ненулевой, если есть какие-то замечания. Завожу эти замечания в переменную и отправляю данные с помощью zabbix_sender на Zabbix Server. Если код выхода 0, то отправляю строку All is OK.

Сам скрипт очень простой:

#!/bin/bash

/usr/sbin/lynis audit system -q
exitcode=$?
result="0"
if [ $exitcode != 0 ]; then
  result=$(/usr/bin/grep "Warning:\|Found vulnerable package" /var/log/lynis.log)
else
  result="All is OK"
fi
zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k "lynis.check" -o "$result"

Ставлю скрипт в cron или timers на выполнение раз в 2-3 часа. Чаще большого смысла нет.

2️⃣ В Zabbix Server делаю простой шаблон с одним элементом данных типа Zabbix траппер. Его настройки есть на скриншоте снизу. К айтему делаю два триггера. Один на поиск строки All is OK. Если в последнем полученном значении её нет, то срабатывает триггер. И второй - проверка, что данные приходят. Если в течении дня ничего не приходило, то он срабатывает. Настройки триггера тоже ниже.

3️⃣ В итоге если Lynis что-то находит, отправляет информацию в Zabbix Server. Срабатывает триггер, в описании которого будет текст из айтема со всеми замечаниями и списками уязвимых пакетов, которые надо обновить. Пример письма с информацией тоже есть ниже на картинке.

Всё это настраивается относительно просто. Не нужны никакие отдельные системы и сторонние пакеты. Всё ставится из базовых репозиториев, а система мониторинга скорее всего уже есть. Мне для базовых проверок такой информации достаточно.

Сам шаблон не прикрепляю, так как там всего один айтем и два триггера, содержимое которых и так есть на скринах. Воспроизвести нетрудно. Работать будет на любых версиях Zabbix сервера. Если не устанавливали на хосты zabbix_sender, то поставьте его. Он идёт в отдельном пакете:

# apt install zabbix-sender

Такая вот простая и функциональная система с предупреждениями об обновлениях и некоторых других вещах. Lynis делает много проверок, можно почитать о нём отдельно. В рамках этой заметки не стал на этом делать акцент.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#zabbix #security

На днях увидел новость, что в Windows появилась утилита sudo 😳, как в Linux, для повышения пользовательских привилегий до административных. Было очень удивительно это увидеть и организационно, и по идентичному названию, которое в Windows выглядит инородно. Назвали бы PrivAdm, AdminUp, RunAsAdmin или что-то в этом роде. А тут линуксовое sudo.

Я особо не слежу за обновлениями Windows. У меня 11-я версия. Обновляется сама, когда ей вздумается. Открыл cmd, набрал sudo и увидел:

Sudo отключен на этом компьютере. Чтобы включить его, перейдите в раздел Developer Settings page в приложении "Параметры".

Сходил в раздел Система ⇨ Для разработчиков, переключил галочку для Включить sudo. Снова вернулся в терминал, набрал sudo и увидел ключи запуска.

Теперь для запуска чего-либо с правами администратора не надо открывать новую консоль от администратора. Можно в этой же использовать sudo. На самом деле удобно.

> netstat -ab
Запрошенная операция требует повышения.
> sudo netstat -ab

Открывается новый терминал с выполненной командой. Кстати, команда полезная, показывает открытые соединения.

Любопытно, что у утилиты для Windows открыт исходных код, который лежит на github:

⇨ https://github.com/microsoft/sudo

Не знаю, что там Microsoft мелочится. Выкладывали бы уже весь код системы Windows в open source, как RedHat. Вот это был бы номер 😁 Представляю, сколько бы новых вирусов появилось на основе анализа исходников системы.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#windows

Продолжение утренней темы с Mysql. Не стал всё в одной публикации делать, чтобы не смешивать темы. У меня необычная ситуация возникла, с которой столкнулся впервые. Я ранее уже делал заметку по ошибке с базой данных. Это её продолжение.

Напомню, что в базе Mysql с движком InnoDB внезапно появляется ошибка такого вида:

[ERROR] InnoDB: Index corruption: rec offs 12361 next offs 0[page id: space=33355, page number=1250], index `PRIMARY` o
f table `dbname01`.`table_01`. Run CHECK TABLE. You may need to restore from a backup, or dump + drop + reimport the table.
[ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, 
in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace.
[ERROR] Got error 126 when reading table './dbname01/table_01'
[ERROR] mariadbd: Index for table 'table_01' is corrupt; try to repair it

При этом сама база работает нормально, данные пишутся, читаются. Просто спотыкается чтение определённых строк в проблемной таблице. Это становится заметно при снятии дампа, так как он останавливается на этих строках.

Никакие рекомендованные процедуры лично мне не помогли восстановить таблицу. Пришлось восстанавливать из бэкапа.

А странность тут вот в чём. Ещё когда первый раз я с этим столкнулся, то восстановил всю виртуалку из бэкапа на другой сервер. Запустил её там и спокойно всё прочитал в таблицах, снял дамп. Никаких повреждений данных, всё на месте. То есть данные на самом деле не пострадали.

И вот эта история повторилась на том же сервере спустя более чем полгода. Опять побилась таблица. Развернул ночной бэкап виртуалки – там всё в порядке. Все данные на месте. Делают тут же без остановки ещё один бэкап проблемной виртуалки с помощью PBS, восстанавливаю на другом сервере, снимаю дамп. Опять всё в порядке, все данные на месте.

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

Мне непонятен такой момент. Если с памятью проблемы, то данные по идее должны всё же биться и теряться. А тут восстанавливаешь глючащую виртуалку в другом месте и с ней вдруг всё становится в порядке, данные на месте. СУБД обычно чувствительна к таким сбоям, база теряет свою целостность. А тут всё в порядке.

У кого-то есть ещё идеи по этой ошибке? Может кто-то сталкивался с подобным. А то сервер сдам и больше не узнаю, что с ним было. Особо нет времени и возможности полноценно тестировать чужой сервер, не имея к нему полного доступа.

#mysql #ошибка

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

1️⃣ Я обычно использую следующий набор ключей при снятии дампа с помощью mysqldump:

# mysqldump -v --add-drop-database --add-locks --create-options --disable-keys --extended-insert --single-transaction --quick --set-charset --routines --events --triggers --comments --quote-names --order-by-primary --hex-blob --databases dbname01 > dbname01.sql

Не буду их все пояснять, можно у ИИ спросить. Сделаю акцент на --single-transaction. Этот ключ позволяет избежать блокировок при снятии дампа, в отличие от ключа --opt, который используется по умолчанию и включает в том числе --lock-tables. Пришлось от него отказаться и вручную перечислить некоторые его ключи, убрав блокировку.

Если какая-то таблица из-за ошибок не бэкапится и останавливает процесс снятия дампа, её можно исключить из дампа ключом --ignore-table=dbname01.table_01.

2️⃣ В таком дампе из-за ключа --add-drop-database в начале идёт команда на удаление базы данных: DROP DATABASE IF EXISTS `dbname01`;и создание новой: CREATE DATABASE IF NOT EXISTS `dbname01`; Я использую этот ключ, потому что удобно автоматически восстанавливать исходники и дамп базы по расписанию на каком-то тестовом сервере. Не нужно менять никакие настройки, не надо удалять старую базу и создавать новую. Берём бэкапы с прода и восстанавливаем их в неизменном виде.

Но это создаёт неудобство, если нужно из бэкапа восстановить копию базы на проде. Если забыть об этом, то при восстановлении базы данных, исходная удаляется. Поэтому перед восстановлением нужно заменить в дампе имя базы данных. Это нетривиальная задача, если дамп очень большой. Нельзя просто открыть его и вручную изменить имя базы. Сделать это проще всего с помощью sed. Меняем dbname01 на dbname01_copy, везде, где встречается:

# sed -i 's/`dbname01`/`dbname01_copy`/g' dbname01.sql

После этого можно создавать базу данных dbname01_copy и восстанавливать в неё содержимое дампа:

# mysql
> CREATE DATABASE dbname01_copy;
> use dbname01_copy;
> source ~/dbname01.sql;

Получили рядом копию рабочей базы.

3️⃣ Проще и удобнее делать полный дамп базы, особенно если в ней очень много таблиц. Можно бэкапить потаблично, но лично я так почти никогда не делаю. Из полного дампа легко получить бэкап отдельной таблицы, если это потребуется. Поможет awk:

# cat dbname01.sql | /usr/bin/awk '/CREATE TABLE `table_01`/,/UNLOCK TABLES/' > /tmp/table_01.sql

Теперь можно восстановить отдельную таблицу.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#mysql