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

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

Такая тема хорошо работает, когда оповещений немного. Буквально 3-5, может 7. Если больше, то уже теряется смысл, так как легко что-то пропустить. У меня их уже много стало. И тут мне видятся 2 решения проблемы:

1️⃣ Убрать всё лишнее или как-то скомбинировать уведомления, чтобы их снова стало мало. Это не всегда возможно.
2️⃣ Сделать какую-то аналитику по почте. Например, собрать все такие письма в отдельный ящик и там считать количество в день или считать письма с различным содержимым. Можно как-то на дашборд графаны это вывести в красные/зелёные плитки, но опять же, теряется смысл, так как в эти дашборды никто постоянно не смотрит.

Городить аналитику по почте не хочется. Это надо какие-то костыли писать, которые будут по imap в ящик ходить. В целом, это не сказать, что сильно сложно. Тот же curl умеет ходить по imap и делать всё, что угодно. Но всё равно не очень хочется с этим связываться. Сейчас эти оповещения отправляются штатно различными программами, которые это умеют делать: Veeam, Proxmox и т.д.

Может кто-то уже решал такие задачи и есть простые идеи. Вы вообще шлёт себе успешные уведомления? Я честно говоря особо не видел у других этих тем. Обычно настраивают о неудачах, что видится логичным с точки зрения отсечения лишних отвлекающих уведомлений. Но есть определённый риск проспать проблему, с чем лично я сам сталкивался и не раз. Например, Veeam терял доступ к MSSQL и тупо не запускались его службы. Соответственно, он ничего не слал. Мониторинг службы на хосте то ли не был настроен, то ли не работал, то ли был отключен, уже не помню. Заметил случайно, что бэкапы не делаются несколько дней. А в почте был привычный молчок, как-будто всё в порядке.

#мониторинг

На канале было опубликовано много всевозможных прикладных bash скриптов, которые я сам постоянно использую. У меня они все в отдельном репозитории лежат. Решил их собрать для вашего удобства в отдельную публикацию.

▪️lynis.sh - проверка системы с помощью lynis и выгрузка результатов в Zabbix
▪️vps-audit.sh - аудит безопасности сервера
▪️dir_size.sh - определяет размер директорий и записывает результат вместе с датой замеров в файл
▪️postgres.sh - отдельные консольные команды postgresql сервера для использования в своих скриптах (pg_dump, createdb, reindexdb, vacuumdb и т.д.)
▪️copy-last.day.sh - передача с помощью rsync с одного сервера на другой бэкапы прошлого дня, более старые не трогает, забирает файлы со стороны стороннего сервера, а не исходного, где лежат файлы
▪️tg_mon.py - следит за заданными строками в лог файле и шлёт уведомления в telegram, когда их видит
▪️dates.sh - заготовка под работу с датами в скриптах
▪️copy-mysql-table.sh - копирование отдельной таблицы базы данных с одного сервера на другой
▪️wget-speedtest.sh - загружает интернет канал загрузкой данных с публичных Looking Glass
▪️findmnt.sh - проверка существования точки монтирования
▪️ps_mem.py - использование оперативной памяти программами (не процессами)
▪️check_nginx_running.sh - анализ работы веб сервера Nginx для экспорта в логи или мониторинг
▪️contry-block.sh - блокировка стран с помощью ipset и iptables
▪️mysql-stat.sh - оптимизация конфигурации MySQL сервера под имеющуюся оперативную память
🔥topdiskconsumer.sh - очень удобная статистика по занимаемому месту
▪️swap.sh - использование swap процессами
▪️trash.sh - самостоятельная реализация корзины при удалении файлов

📌 Софт для работы со скриптами:

◽️Rundeck - веб интерфейс для централизованного управления работой скриптов на серверах.
◽️Cronicle - система планирования и управления задачами серверов. Условно его можно назвать продвинутым Cron с веб интерфейсом.
◽️Task - утилита, написанная на Gо, которая умеет запускать задачи на основе конфигурации в формате yaml. Более простая и функциональная замена утилите make.

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

#script #подборка

Для тех, кто ещё не слышал или не знает, расскажу новости про ограничения на загрузку образов из Docker Hub. Вышла какая-то непонятная история, поэтому решил разобраться. Компания Docker анонсировала внедрение новых лимитов на загрузку образов из их хранилища, причём довольно суровых. Обещали только 10 загрузок в час для неаутентифицированных пользователей. То есть сделали в час 10 docker pull и получили временный бан, пока лимит не сбросится.

Ограничение довольно суровое даже для каких-то личных историй с тестами локально, не говоря уже об использовании в пайплайнах. Прогнал несколько отладочных тестов и всё. Для аутентифицированных пользователей, даже бесплатных, обещали 100 запросов в час, что в целом уже приемлемо и можно пользоваться, как прежде.

Я собрался рассказать, как по-быстрому настроить аутентификацию как локально, так и в том же Gitlab. Последние уже запланировали изменение в веб интерфейсе, чтобы можно было легко указать учётные данные для Docker. Также хотел упомянуть про локальные хранилища образов, которые можно развернуть у себя.

Зашёл на днях на страничку с лимитами и удивился, так как никаких новых лимитов там нет, можно не суетиться. Хотя я своими глазами видел, что они были, и даже отдельно была выделена новость, что с 1-го апреля они изменились. По факту сейчас всё так же, как и было: 100 запросов за 6 часов без аутентификации и 200 с ней. Протёр глаза и понял, что мне не мерещится. Реально изменений нет.

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

April 8, 2025: No changes to Docker Hub rate limits at this time

Не знаю, по какой причине, но они передумали вводить новые лимиты. И пообещали, что если опять надумают, то предупредят минимум за 6 месяцев.

Для того, чтобы не зависеть от каких-либо ограничений со стороны Docker Hub, можно использовать свои registry. Настроить их очень просто и быстро. Вообще никаких проблем:

▪️Nexus
▪️Harbor
▪️Gitlab Registry
▪️Docker Registry + UI

Для того, чтобы туда автоматом закидывать образы с Docker Hub, можно воспользоваться, к примеру, Sinker. Или чем-то ещё. Таких утилит много. Можно настроить обращения к Docker Hub так, чтобы не выходить за лимиты, и держать свой локальный registry с актуальными образами.

#docker #devops

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

Всё время, что работал администратором Windows, и будучи пользователем Windows, смотрел список сохранённых паролей в системе через Панель управления ⇨ Учетные записи пользователей ⇨ Диспетчер учетных данных.

А если в командной строке ввести команду:

> rundll32.exe keymgr.dll,KRShowKeyMgr

То откроется другой интерфейс для управления этими же сохранёнными данными. Я его на днях увидел вообще впервые.

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

Для того, чтобы не пропускать такие простые и не совсем очевидные вещи полезно сертифицироваться, даже если вам сертификат формально не нужен. Обычно вот такие примочки во время подготовки и узнаешь. Хотя у меня есть сертификат Microsoft Certified Professional (MCP), но уже не помню, было там такое или нет. Получал очень давно. Обратил тогда внимание, что узнал много таких вещей, о которых даже слышать не приходилось на учёбе или работе.

#windows

Небольшой практический совет во время отладки в консоли Linux. Иногда хочется узнать, в каком окружении работает то или иное приложение. Поти вся информация о процессах в Linux живёт в /proc/<pid>, в том числе и об его окружении. Посмотреть можно так:

# cat /proc/816/environ

LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binHOME=/var/lib/zabbixLOGNAME=zabbixUSER=zabbixSHELL=/sbin/nologinCONFFILE=/etc/zabbix/zabbix_agentd.conf

Всё в одну строчку. Не воспринимается глазами вообще. Можно ещё вот так посмотреть:

# ps e -ww -p 816

Тоже не очень наглядно. Так как у нас консоль и bash, то вывод можно как угодно обрабатывать, чтобы было удобно. Проще всего взять xargs, так как у него есть ключ --null, который позволяет разделять строку, используя разделителем так называемый NULL character. Я уже как-то раз писал про него. Иногда его удобно использовать, в том числе в find с ключом -print0.

# cat /proc/816/environ | xargs --null --max-args=1

или то же самое, но немного по-другому:

# xargs --null --max-args=1 echo < /proc/816/environ
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
HOME=/var/lib/zabbix
LOGNAME=zabbix
USER=zabbix
SHELL=/sbin/nologin
CONFFILE=/etc/zabbix/zabbix_agentd.conf

Я уже болен cat-офилией и привык везде её использовать. Уже даже не пытаюсь переучиться. Вместо grep постоянно делаю cat | grep. Вы выбирайте, что вам легче запоминается.

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

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

#linux #bash

Я периодически использую Rocket.Chat. На текущий момент это хоть и не без недостатков, но тем не менее наиболее функциональное бесплатное решение для сервера чата, установленного на своих серверах. В целом, работает нормально, но утомляет его постоянное обновление. Нет LTS версии, минимум раз в пол года, а обычно и чаще, надо обновлять сервер с ненулевой вероятностью получить проблемы.

Рассказать я хотел не о нём. Чтобы не держать постоянно запущенным клиента Rocket.Chat, решил поднять для него шлюз в Telegram, чтобы пересылал туда сообщения. Нашёл довольно популярный проект Matterbridge, который поддерживает очень много популярных чатов:

◽️Discord
◽️IRC
◽️Matrix
◽️Mattermost
◽️Microsoft Teams
◽️Nextcloud Talk
◽️Rocket.chat
◽️Slack
◽️Telegram
◽️Twitch
◽️VK
◽️WhatsApp
◽️XMPP
◽️Zulip

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

Сразу скажу, что у меня не получилось настроить передачу из рокета в телегу. Я не знаю прочему. Бился пару часов, решить не смог, бросил. Получал постоянно ошибку, с которой справиться не смог. Но в целом, судя по описанию, вещь вполне рабочая и настраивается относительно легко. Покажу свой конфиг, который с точки зрения синтаксиса сделан правильно. Можно взять его за основу. Имя файла matterbridge.toml:

[rocketchat]
  [rocketchat.myrocketchat]
  Server="https://serveradmin.rocket.chat:443"
  Login="[email protected]"
  Password="topsecret"
  PrefixMessagesWithNick=false
  RemoteNickFormat="[{PROTOCOL}] <{NICK}> "

[telegram]
  [telegram.mytelegram]
  Token="13992116911:BBHtEAKqxUHYt45PoWwxKfvH5TR6-vdNw"
  RemoteNickFormat="<{NICK}>  " 
  MessageFormat=""
  QuoteFormat="{MESSAGE} (re @{QUOTENICK}: {QUOTEMESSAGE})"
  QuoteLengthLimit=46
  IgnoreMessages="^/"

[[gateway]]
name="Serveradmin_gateway"
enable=true

  [[gateway.inout]]
  account="telegram.mytelegram"
  channel="-1001331797787"

  [[gateway.inout]]
  account="rocketchat.myrocketchat"
  channel="test-room"

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

Запускаем шлюз через простенький docker-compose.yml:

services:
 matterbridge:
  image: 42wim/matterbridge:stable
  restart: unless-stopped
  volumes:
  - ./matterbridge.toml:/etc/matterbridge/matterbridge.toml:ro

# docker compose up

Если в конфигурации будут ошибки, об этом будет информация и контейнер завершит работу.

Описание настроек для всех поддерживаемых чатов есть в wiki. Можно указывать разные направления пересылок, как в одну, так и в другую сторону, или двустороннюю пересылку. Также можно сообщения пересылать в несколько разных приёмников. Например, из группы Телеграм в несколько разных чатов. Если будете настраивать пересылку в или из Telegram, внимательно прочитайте последовательность действий в wiki. Обязательно отключить боту Privacy mode и после этого вывести его из группы и завести снова. Я пока последнее не сделал, не работало ничего в телеге.

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

⇨ 🌐 Исходники

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

#chat