ServerAdmin.ru

Это ваше приглашение на Deckhouse User Community meetup #4 Кому: инженерам, которые работают с Kubernetes Когда: 26 февраля Где: Москва, офлайн На митапе узнаете о запуске Kubernetes поверх любых операционных систем, о реальном опыте эксплуатации платформы в одиночку, о домашней виртуализации на бюджетном железе и о практичном подходе к безопасности. Киллер-фича события — интерактивная зона «Попробуй сам» с развёрнутым кластером Deckhouse Kubernetes Platform Community Edition. Протестируйте платформу своими руками, а инженеры Deckhouse помогут разобраться. Регистрация

Файлы к предыдущей заметке по настройке сбора логов Postfix в Loki с помощью Alloy. Здесь представлен дашборд для Grafana и настройки Alloy в качестве сборщика текстового лога на почтовом сервере.

Продолжу одновременно две темы, которые развиваю последнее время - почтовый сервер на базе Postfix и сбор логов в Loki. Покажу, как очень просто и быстро собирать логи Postfix в Loki с базовым анализом содержимого и простенькой визуализацией в дашборде. Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся. Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики: ◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы ◽️Статистика по доменам внешних получателей писем от нас ◽️Статистика по полученным письмам локальных доменов нашего сервера ◽️Статистика по отклонённым письмам в разрезе ошибок и доменов Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д. Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут. Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:

    
        loki.write "default" {
  endpoint {
    url = "http://195.20.47.169:3100/loki/api/v1/push"
  }
  external_labels = {}
}

local.file_match "postfix" {
 path_targets = [{
  __address__ = "localhost",
  __path__  = "/var/log/mail.log",
  instance  = constants.hostname,
  job     = string.format("%s-maillog", constants.hostname),
 }]
}

loki.source.file "postfix" {
 targets  = local.file_match.postfix.targets
 forward_to = [loki.write.default.receiver]
}{}
    

После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка -maillog. В моём случай это будет mail.zeroxzed.ru-maillog. На картинках другое название, но это мне показалось более удачное. Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел grafana/dashboards/, файл Postfix Delivery Status.json. Его нужно скачать и импортировать в Grafana. Во время импорта в качестве источника данных укажите свой Datasource с Loki. Если он не подцепится автоматически, то после импорта зайдите в настройки дашборда, раздел Variables, укажите его явно в переменной DS_LOKI. Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах. Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось. Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории. Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX #loki #logs #mailserver #postfix

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились. ⇨ Termix — Возьмите управление сервером в свои руки. Обзор интересной системы для доступа к серверам через браузер. Это аналог Apache Guacamole. Я писал о нём год назад, когда он только вышел. Сейчас посмотрел, изменений не так много. Продукт выглядит удобным, но местечковым, не для большого прода, скорее для себя или небольшого коллектива. ⇨ ALT Linux 11 сервер видеонаблюдения zoneminder + MySQL + apache Инструкция по настройке бесплатного софтового видеорегистратора Zoneminder. Я лично себе настроил Frigate и очень доволен. Разобрался в нюансах, постоянно пользуюсь. Думаю, сделаю ещё одну заметку по нему. ⇨ Восстановление GRUB и MBR в Linux Автор ломает таблицу разделов, соответственно, загрузку, а потом всё восстанавливает с помощью загрузочного ISO и утилиты testdisk. Я когда-то давно писал статью на эту тему. ⇨ Восстановление GPT, GRUB, NVRAM в режиме UEFI (без Secure Boot) в Linux Продолжение и усложнение предыдущей темы. ⇨ Установка ALT Linux 11 на Repka Pi4 Установка ОС на известный в нашей стране одноплатник Repka Pi4. Всё руки не доходят написать производителям. Может подарят мне тоже на обзор. Покупать смысла нет, а так, поиграться и заметку сделать можно было бы. У Альта сборка есть под этот одноплатник. ⇨ ALT Linux 11 обновление PVE с 8 на 9 Наглядная процедура обновления PVE на Альте. Если я правильно понял, это платная редакция виртуализации от Альта, потому что все используемые репозитории в видео его же. ⇨ Настройка Eltex ESR-15VF для двух провайдеров в режиме балансировки Ни разу в руках не держал и не работал с устройствами этой фирмы. Было любопытно посмотреть, что они из себя представляют. Автор в режиме реального времени всё настроил. Настройка выглядит простой. На рабочем столе тестового компа ярлык на игру Мир Танки 😁. ⇨ Разбор инфраструктуры реального проекта. Стоит ли внедрять Kubernetes? Интересное видео. Заголовок привлёк, а на деле там переводят в режим HA магазин на Wordpress, который сейчас работает на одиночном сервере. Мне эта тема хорошо знакома, новое для себя не вынес, но было интересно послушать автора. Забавно увидеть, как заказчика с инфры за 15к рублей в месяц хотели пересадить в кубер за 195к + оплата работы и поддержки. ⇨ Dockhand. Лучший докер менеджер!? Я уже упоминал ранее про этот менеджер. Внешне и функционально он выглядит интереснее Portainer. ⇨ ASUS GX10 (NVIDIA DGX Spark): честный тест для инференса нейросетей Обзор NVIDIA DGX Spark (ASUS GX10), компактного компьютера для нейросетей с 128 ГБ памяти и его тесты на реальных задачах. Цена в России сейчас ~ 350 000₽. ⇨ Всё закончилось, работ нет. Ухожу из АйТи после 20 лет. Серия первая ⇨ Конец АйТи в Америке. Работы кончились. Вторая серия ⇨ Из программиста в короля мусора в Америке! Третья серия ⇨ Из программиста в грузчика на пикап траке, 4 серия Сериал от русского программиста Романа Пушкина из Сан-Франциско. Я уже как-то упоминал его у себя на канале. Он уже давно не может найти нормальную работу по специальности, поэтому купил пикап и начинает подрабатывать переездами и вывозом мусора. Не знаю, насколько соответствует действительности всё то, что он рассказывает, но как минимум мне смотреть интересно. А как максимум заставляет задуматься, что кризис в ИТ нас настигнет в ближайшем будущем. И его признаки видны уже сейчас. Работы всё меньше - резюме всё больше. 10 раз подумайте, прежде чем увольняться сейчас и искать что-то другое. Можно и не найти. Тенденция общемировая, не только наша. У нас наоборот всё это с запозданием идёт из-за региональной специфики и отсутствия мигрантов-айтишников со знанием русского языка. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX #видео

🔝 ТОП постов за прошедший месяц январь. Публикаций было немного, но решил не нарушать порядок, чтобы что-то интересное не затерялось. Я пересмотрел своё отношение к ведению канала и решил снизить активность. Поднадоело за столько лет, переключусь на другие дела. Несколько лет практически без перерыва публиковал по 1-2 заметки каждый день, причём по нарастающей в плане проработки материала и его объёма. Перечитываю заметки за 20-21-е года. Это небо и земля по сравнению с сегодняшними. Подумать только, я уже 5+ лет пишу сюда каждый будний день 😱. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025. Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin. 📌 Больше всего пересылок: ◽️2FA в виде OTP для RDP соединений в Windows (629) ◽️Как вернуть IE в Windows 11 (530) ◽️Сетевой сканер Scanopy (486) ◽️Игра Tower Networking Inc. - симулятор провайдера (467) ◽️Выпуск сертификатов Let's Encrypt для IP адресов (437) 📌 Больше всего комментариев: ◽️Опрос на тему Desktop Environment в Linux (208) ◽️Выпуск сертификатов Let's Encrypt для IP адресов (134) ◽️Обзор DNS сервера Technitium DNS (63) 📌 Больше всего реакций: ◽️Как вернуть IE в Windows 11 (287) ◽️Выпуск сертификатов Let's Encrypt для IP адресов (213) ◽️2FA в виде OTP для RDP соединений в Windows (211) 📌 Больше всего просмотров: ◽️Как вернуть IE в Windows 11 (11880) ◽️Проблемы с песочницей Windows (9350) ◽️Сертификаты для аутентификации в Angie (9200) #топ

Приключилась со мной на днях неприятная история. Расскажу о ней. Возможно, кому то это позволит сохранить время и нервы в похожей ситуации. Был вечер, закончил все свои дела, собирался потихоньку спать. Приходит уведомление в Telegram, что недоступен один из сайтов. Потом второй. В Телеграме у меня очень мало уведомлений, только ключевые о конечных точках так сказать. Подобные уведомления должны сопровождаться более многочисленными оповещениями от Zabbix в почту. Захожу туда, там пусто. Проверяю сайты - реально недоступны, соединения сбрасываются. Пробую зайти в мониторинг по доменному имени, не получается. Поясню, что сайты, мониторинг, некоторая другая инфраструктура располагаются в ЦОД на своих серверах на услуге colocation. Там пачка внешних IP адресов, софтовый шлюз на Linux и для подстраховки ещё один физический в стойке на Mikrotik. Подключаюсь к шлюзу по VPN (OpenVPN), попадаю во внутреннюю инфраструктуру. Всю её вижу, никаких проблем с доступностью. Открываю Zabbix по локальному IP адресу машины, где он работает, попадаю в веб интерфейс. Там всё красное, куча алертов на разные темы. Невозможно понять, что происходит. Обращаю внимание на растущую очередь сообщений на почтовом сервере, они не уходят. Это в основном уведомления от мониторинга. Запускаю у себя почтовый клиент, нормально подключаюсь к серверу, вижу новую почту. Посмотрел выборочно некоторые логи сервисов, у кого-то что-то работает, у кого-то нет. Не понимаю, что происходит. Пытаюсь сфокусироваться на какой-то одной проблеме, чтобы её решить. Параллельно замечаю, что по внешнему IP адресу шлюза не могу подключиться к нему по SSH ни из одной локации, добавленной в белый список. То есть по внутреннему адресу через VPN я на него захожу, а по внешнему не получается. Соединение происходит, получаю приветствие от SSH сервера, а дальше сеанс не открывается. То есть с сетевой связностью проблем нет. Телнетом я нормально подключаюсь к SSH порту. В первую очередь захотел разобраться с сайтами. На шлюзе стоит проброс порта на Nginx Proxy, с него уже на веб сервер. В логах прокси пусто, запросы не приходят. При этом на шлюзе я вижу, что по правилам проброса через NAT летят пакеты, счётчики растут. Ситуация странная. В первую очередь подумал на шлюз, что с ним какие-то проблемы. Там старая уже неподдерживаемая система CentOS 7. Аптайм ОЧЕНЬ большой. Всю эту структуру когда-то давно настроил я, но последние несколько лет развитием и обновлением не занимался. Задач и финансов под это дело не было. Шлюз полностью скрыт от посторонних глаз и доступ туда сильно ограничен, так что реальных проблем это не доставляло. Проверил у шлюза логи, таблицу conntrack на переполнение, сетевые соединения, нагрузку, что-то ещё. Уже не помню точно. Ничего подозрительного не заметил. Нигде ничего не переполнено, не нагружено, ошибок нет. Шлюз как-будто бы в порядке. Перезапустил сервис iptables - не помогло. Внешне всё выглядит так, как-будто соединения где-то внутри iptables или сервера застревают. Решил, что от большого аптайма системе стало плохо и её надо перезагрузить. Так как это шлюз и точка входа в инфраструктуру, сделать это надо аккуратно. Все IPMI тоже скрыты за VPN, прямого доступа нет. Проверил на всякий случай резервный шлюз. Предупредил администратора, который на месте (офис и ЦОД - одно здание) всё это поддерживает, чтобы он был готов если что утром приехать пораньше и начать разбираться с проблемой. Перезагрузка не помогла, а точнее вообще всё развалила. Не поднялись VPN с филиалами, которые до перезагрузки работали. Мониторинг покраснел ещё сильнее. Всё, что не работало, так и продолжало не работать. При этом я лично нормально подключился по VPN. Плюс, видел по логам VPN сервера, что некоторые клиенты тоже подключились, в том числе из-за границы. Была ночь за окном, на термометре -35. Всё это меня вообще сбило с толку, и я взял паузу, чтобы обдумать ситуацию. А как я её решил, читайте ниже. Тут лимит на длину публикации исчерпан. 👇👇👇👇👇👇👇👇 #история #цод

В своих заметках и статьях про почтовый сервер я ни разу не касался темы резервного сервера, который в рамках возможностей DNS записей вида MX реализуется очень просто. Для каждого домена могут быть указаны несколько почтовых серверов, используя разные приоритеты. Например: # dig 1c.ru MX +short 20 relay.1c.ru. 30 mx1-ksmg.1c.ru. Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер. На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина. Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам: 1️⃣ По хорошему, вам нужно синхронизировать информацию о ящиках и пользователям между двумя серверами. Можно этого не делать и собирать всю почту в один ящик-ловушку для всех писем домена, но потом придётся каким-то образом раскладывать её по пользователям. 2️⃣ В случае, если ваш основной сервер по каким-то причинам был недоступен и письма попали на резервный, вам придётся потом каким-то образом вернуть эти письма на основной в ящики пользователей. Решения для этого есть - тот же fetchmail. Он может на основании адреса получателя раскладывать письма по пользователям. Но всё это надо поддерживать в актуальном состоянии, следить, что нормально работает. На практике это не так то просто реализовать, если это не какое-то готовое решение. 3️⃣ На резервный MX сервер спамеры могут слать спам вопреки более высокому приоритету основного сервера. Это отдельные хлопоты по администрированию. Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше. При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами. Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление. Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно. ❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX #mailserver

Очередная подборка статей авторов, которые согласились в ней участвовать. Кто не понимает, о чём идёт речь, может прочитать прошлые публикации по этой теме (раз, два). ⇨ Initramfs в Astra Linux на практике. Загрузка по USB ключу. Хороший пример для практического понимания принципа загрузки ОС на базе Linux. Эти знания пригодятся, когда надо будет разобраться, почему система не грузится, к примеру, после восстановления или переноса на другом гипервизоре. Автор настроил запрет загрузки ОС, если не уставлена определённая флешка. Отдельно отмечу, что очень приятно видеть mcedit на скринах 😁. ⇨ Настройка восстановления пароля в Authentik ⇨ Настройка процессов регистрации и приглашений пользователей в Authentik ⇨ Настройка двухфакторной аутентификации в Authentik ⇨ Настройка Cloudflare Turnstile для защиты формы входа в Authentik без CAPTCHA Очередные статьи про настройку Authentik. У автора большой цикл статей и видео на эту тему. Тема непростая для самостоятельного изучения, так что материалы вам сильно помогут, если осваиваете этот продукт. ⇨ Сети в Docker ⇨ Docker Compose — установка и базовое использование Тоже продолжение цикла на заявленную тематику. У автора несколько заметок про основы докера. ⇨ Как установить Passbolt на Ubuntu 24.04 ⇨ Passbolt: базовая настройка и начало работы Установка и настройка бесплатного менеджера паролей Passbolt с открытым исходным кодом. Он позволяет совместно вести базу данных с паролями, управлять учётными записями для доступа к ним. ⇨ Linux. Утилиты. Нестандартные. convert Пример конвертации изображений из директории в единый pdf файл с помощью консольной утилиты. ⇨ FreeBSD. Установка ⇨ FreeBSD. Первоначальная настройка Краткие инструкции по установке и настройке FreeBSD. Мне уже очень давно хочется сесть и написать цикл статей по FreeBSD. Нравилась эта система, скучаю по ней. Я её неплохо знал, так как не просто интересовался, а поднимал и администрировал реальные сервисы на ней - почтовый, веб, шлюз, мониторинг и т.д. Делал у заказчиков миграции с FreeBSD, когда они ещё попадались, на Linux. ⇨ SSH Pilot - Современный менеджер SSH сессий для Linux Linux не балует пользователей удобными менеджерами подключений. Это обзор на один из них. ⇨ PostgreSQL. Troubleshooting. Data corrupted: 7 ERROR: invalid page in block Решение очень неприятной ошибки, когда в логе ты видишь Data corrupted. Часто это означает, что надо расчехлять бэкапы. В данном случае обошлось без этого. Как я понял, данные не пострадали, просто невозможно было записать новые. Если кто-то из авторов хочет присоединиться к этой подборке, то пишите мне в личные сообщения. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX #статьи

Конфигурация к заметке выше 👆👆👆👆👆👆👆👆 То же самое есть в репозитории: https://gitflic.ru/project/serveradmin/grafana-loki