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

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

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

Ниже традиционный для уходящего месяца рейтинг публикаций. До связи в новом году 🎄

📌 Больше всего просмотров:
◽️ Новость про почту для домена в Яндексе (7478)
◽️ Видео с обзором, установкой и настройкой passbolt (7275)
◽️ Система OnCall от Grafana (7253)

📌 Больше всего комментариев:
◽️ Новость про почту для домена в Яндексе (153)
◽️ Регулярные взломы LastPass (121)
◽️ Почтовый сервер Postfix + Dovecot (114)
◽️ Обновление сервера 1С на Linux (75)

📌 Больше всего пересылок:
◽️ Курсы от VK Teem по Linux (595)
◽️ Репозиторий devops-interview (501)
◽️ Онлайн сервисы для проверки почтовых серверов (444)

📌 Больше всего реакций:
◽️ Почтовый сервер Postfix + Dovecot (241)
◽️ Проброс портов в Windows (137)
◽️ Курсы от VK Teem по Linux (131)
◽️ Покупка ноутбука ThinkPad T480 (126)
◽️ Алиасы и функции в bash (113)

#топ

​​Не знаю, как у вас, а у меня не получается полноценно отключаться от забот. Вчера впервые с 30-го числа открыл почту и проверил оповещения мониторинга. Ничего критичного не случилось, просто решил посмотреть обстановку. Есть много систем, за которыми кроме меня, никто не следит. И хоть от меня и не требуется оперативная реакция в выходные дни (никогда на это не подписываюсь), я всё равно проверяю почту, потому что в случае проблем, решать их всё равно придётся рано или поздно мне. Поэтому лучше проверить заранее, когда есть время.

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

Раз уже речь зашла о мониторинге, поделюсь небольшим советом. Я люблю настраивая важные оповещения от Zabbix в Telegram, насыщать их emoji. Использую стандартный шаблон с Webhook. Как минимум добавляю в заголовок сообщения с проблемой что-то вроде ⚠️ или 🔥, а в решение проблемы ✅ или 🟢. Столкнулся с тем, что с некоторыми emoji стандартный шаблон не работает. Конкретно заметил на 🔥, но есть и другие. Сейчас точную ошибку не скажу, не записывал, но помню, что потратил некоторое время, пока не разобрался, в чём проблема с отправкой. Ошибка была неинформативная, в итоге случайно догадался проверить разные emoji.

А как у вас обстоят дела с отдыхом? Получается полноценно уходить на длинные выходные или отпуск, не проверяя рабочую почту и мессенджеры?

#разное

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

1️⃣ Первым делом обновляю репозитории и устанавливаю все обновления. Очень часто у хостеров типовые шаблоны несвежие. Лучше сразу же всё обновить.
2️⃣ Проверяю сетевые настройки. В основном это нужно, чтобы понять, как они управляются. У разных хостеров и в разных системах могут быть большие отличия. Иногда меняю DNS серверы. В РФ чаще всего ставлю DNS от Яндекса. Меняю, если нужно, hostname.
3️⃣ Устанавливаю привычные утилиты и программы: htop, iftop, screen, mc, net-tools, bind9-dnsutils (bind-utils).
4️⃣ Проверяю настройки времени, часовых поясов, автообновления. Настраиваю, если что-то не сделано. Обязательно проверяю, что обновление времени работает. Некоторые хостеры блокируют ntp порты в том числе и на выход.
5️⃣ Меняю настройки службы SSH. В основном это смена порта с 22 на любой другой, либо разрешение/запрет аутентификации под root или по паролю. Либо всё вместе, либо по отдельности, в зависимости от потребностей.
6️⃣ Увеличиваю глубину хранения history терминала, настраиваю мгновенную запись команды в историю, а не после выхода из сеанса. Также добавляю сохранение времени выполнения команд.
7️⃣ Если за севером постоянного наблюдения и обслуживания не будет, то ставлю пакеты и настраиваю автоматическую установку обновления безопасности. Подключаю swap, если его нет.
8️⃣ Делаю настройку системной почты для root. Либо просто алиас с нужным ящиком добавляю, либо делаю полноценную настройку отправки через внешний smtp сервер.
9️⃣ В завершении настраиваю Firewall, либо отключаю, если не нужен.
🔟 После всех настроек обязательно перезагружаю сервер и убеждаюсь, что он нормально стартует с заданными настройками, что все службы запущены (ntpd, sshd, подключается swap и т.д.). В основном это нужно, чтобы проверить настройки Firewall и сети, если они менялись.

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

#linux

​​С появлением Docker стали бурно развиваться контейнеры. Одним из главных преимуществ по сравнению с виртуальными машинами была скорость запуска и размер контейнеров, а также экономия ресурсов хостовой машины. Разработчики активно начали развивать идею с размером образов. Насколько маленьким он может быть?

Сначала по привычке использовали образы на основе традиционных Linux систем - Debian, Centos и т.д. Потом появился очень маленький Alpine, затем пустой образ scratch. Сейчас дошли до distroless образов, где вообще нет привязки к какой-то конкретной системе. Насколько я могу понять архитектуру подобных образов, там только ядро Linux, а из user space вырезано вообще всё (пакетный менеджер, оболочки и т.д.), что не требуется для запуска приложения.

В погоне за минимализмом как-то стали забывать о производительности. Я встречал информацию, что некоторые приложения в образах Alpine работают заметно медленнее. Разница с типовым образом на Debian может достигать 20-30%. А ещё все эти минимальные образы очень неудобно отлаживать. В итоге экономия места оборачивается повышенной тратой рабочего времени разработчиков и поддержки.

Насколько я понимаю, вся эта тема с минимализмом актуальна на очень больших инфраструктурах с сотнями серверов и тысячами контейнеров. Первые distroless образы анонсировал Google. У него есть несколько базовых образов для python, java, nodejs. Сейчас эту тему подхватили и начали развивать. Например, есть большая коллекция готовых distroless образов у chainguard. Там не только среда исполнения для различных языков, но и distroless образы nginx, php, posgresql и т.д.

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

#docker #devops

Вчера сделал публикацию с настройкой сервера. Заметил, что многие поинтересовались подробностями на тему настройки системной почты в Linux. Решил вынести это в отдельную публикацию и пояснить. Ранее не писал об этом заметок.

По умолчанию известные мне дистрибутивы Linux (Debian, Centos, Ubuntu) системную почту для пользователя root записывают в директорию /var/spool/mail. Там создаётся файл для каждого системного пользователя, для которого было отправлено хотя бы одно письмо. Почта для root может складываться в файл root или другого пользователя, который был создан во время установки системы.

Узнать, куда точно отправляется почта для root, можно в файле с алиасами - /etc/aliases. В строке root: посте двоеточия будет указано, куда отправлять почту суперпользователя. Это может быть как обычный локальный пользователь:
root: user01
так и сам root:
root: root

Если вы хотите отправлять эту почту на какой-то внешний ящик, то можно его указать в алиасе:
root: user@mail.example
После редактирования алиасов, нужно обновить локальную базу данных с ними:
# newaliases

Для того, чтобы отправить почту, вы должны установить локальный почтовый клиент или сервер. Например, postfix, либо любой другой (exim, msmtp и т.д.). Без дополнительной настройки этот почтовый сервер будет пытаться самостоятельно отправить почту. Если не выполнить предварительно настройку DNS, то с большой долей вероятности отправленное письмо попадёт в спам. В целом, это не проблема, если письмо получаете вы сами. Сделаете исключающее правило и можно больше ничего не настраивать.

Сейчас всё чаще отправка почты блокируется хостерами. Разрешить отправку по 25 порту либо вообще невозможно, либо нужно написать в тех. поддержку и объяснять, зачем вам это нужно. В большинстве случаев для системной почты заниматься этим не имеет смысла. Лучше использовать какой-то сторонний сервер для доставки почты. Для этого вам нужно настроить локальный почтовый клиент (либо сервер, работающий как клиент) на работу через внешний сервер. Настройка будет зависеть от типа сервера, который вы установите.

У меня есть статья с примером настройки почтового сервера postfix для отправки системной почты через внешний сервер. Отдельно я рассмотрел вопрос отправки почты через почту Яндекса, где нужно учесть один важный нюанс. Адрес отправителя должен совпадать с логином в почтовой системе. Рассказываю, как в postfix его изменить, потому что по умолчанию отправка будет идти от локального пользователя сервера.

Реализаций отправки системной почты может быть много. Подойдёт любой локальный почтовый клиент или сервер с возможностью отправки через внешний сервер. Я всегда использую postfix, потому что умею его настраивать. Но у него не самая простая и очевидная настройка для таких задач. Проще взять msmtp. Там вся настройка в одном файле. Вот пример для Debian.

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

#mailserver #linux

​​Почтовые сервера условно можно разделить на 3 типа по сфере применения:
◽ для переписки пользователей;
◽ для отправки сообщений с сайтов и веб серверов;
◽ для массовых рассылок.

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

Ранее я чаще всего касался темы почтового сервера для переписки пользователей. Сейчас хочу рассказать про сервер для отправки почты с сайта или приложения и частично массовых рассылок. Речь пойдёт про open source проект Postal. Это бесплатный аналог таких сервисов, как  Sendgrid, Mailgun, Postmark и т.д. с возможностью установки на своем железе.

Postal умеет:
▪ Использовать встроенный API для приёма почты к отправке.
▪ Использовать разные домены и учётные записи для отправки.
▪ Собирать и отображать в виде графиков статистику по отправке и получению писем.
▪ Отображать очередь отправки.
▪ Использовать вебхуки для просмотра информации о доставке в режиме реального времени.
▪ Отслеживать корректность настроек DNS для добавленных доменов.
▪ Управлять политиками хранения писем.
▪ Логировать все этапы создания и доставки письма.
▪ Искать письма с заданными параметрами по всему почтовому серверу.
▪ Временно задержать отправку сообщений.
▪ Пересылать входящую почту на другие smtp серверы или почтовые ящики.
▪ Пересылать входящую почту в приложение по HTTP в виде JSON.
▪ Определять спам с помощью SpamAssassin и вирусы с помощью ClamAV.

Почтовый сервер Postal запускается с помощью docker-compose, а настраивается и управляется с помощью набора скриптов. То есть вам не придётся запускать самому контейнеры, указывать переменные и т.д. Достаточно будет передать параметры скрипту, он сам всё настроит и запустит. Процесс установки и настройки описан в документации. Достаточно один раз в консоли всё настроить и запустить. Дальнейшее управление через веб интерфейс. Ходить в консоль больше не придётся. Отдельно нужно будет аккуратно настроить DNS записи, получив информацию о DKIM и SPF записях в веб интерфейсе.

Под капотом у Postal веб сервер Caddy, сервер баз данных MariaDB для хранения информации, RabbitMQ для управления сообщениями между рабочими процессами. Насколько я понял, реализация непосредственно smtp сервера в Postal своя, написанная на Ruby.

Аналогом Postal является Cuttlefish. Более простой сервер для отправки почты с удобным веб интерфейсом. Тоже написан на Ruby, под капотом привычный Postfix.

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

#mailserver

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

Сработал только один триггер на Mikrotik. У Zabbix в стандартном шаблоне есть реакция на температуру устройства ниже 5°C. Я решил проверить температуру серверов. По процессорам всё более ли менее нормально: 12-16°C, для них, как я понимаю, это не проблема. А вот с дисками я не так оптимистичен. Обычные показали 10-12°C, а вот SSD 0-2°C 😱. Надеюсь это их не убьёт.

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

#zabbix #мониторинг

​​Подготовил сжатый список действий, которые я всегда выполняю при настройке Zabbix Server. Тут нет ничего особенного, пригодится просто чтобы ничего не забыть и разом всё сделать. Все настройки относятся к веб интерфейсу и выполняются там.

1️⃣ Первым делом сразу же создаю нового администратора с другим именем, старого удаляю. Старому админу принадлежат некоторые готовые объекты в виде дашбордов или карт сетей. Чтобы их удалить, нужно назначить владельцем нового админа.

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

3️⃣ Иду в шаблоны оповещений и настраиваю шаблон на проблему и на восстановление. Обычно просто удаляю некоторые поля, которые мне не нужны (например, problem ID). Добавляю в тему оповещения макрос {HOST.NAME}, чтобы всегда в заголовке видеть имя хоста, где произошло событие. Иногда перевожу шаблон на русский язык. Там быстро, всего несколько фраз.

4️⃣ В настройках веб интерфейса изменяю "Макс. количество элементов отображаемое в ячейке таблицы" с 50 на 100. Мне так удобнее.

5️⃣ В разделе настроек Опции отображения триггеров меняю значения "Отображать триггеры в состоянии ОК в течении" и "Мигание триггеров при изменении состояния" на 1 минуту. Мне не нравится, когда триггеры на дашборде долго мигают, либо висят уже закрытые.

6️⃣ Удаляю с основного дашборда все виджеты, вместо них добавляю два обязательных: тип "Проблемы". В первом показываю актуальные проблемы, во втором историю проблем. Всё остальное по желанию. Иногда ничего другого на главном дашборде нет. Всё остальное во вкладках. Раньше делал отдельные дашборды, но как только появились вкладки, стал всё делать на основном в них.

7️⃣ Дальше иду в шаблоны и там меняю их в зависимости от объектов мониторинга. Если есть Windows машины, то 100% отключаю в шаблоне правило обнаружения служб. Толку от него мало, а спама будет море. То же самое относится к обнаружению сетевых интерфейсов. Обнаружение в Zabbix шаблоне находит десятки служебных сетевых интерфейсов и все добавляет их в мониторинг. Это ведёт к лишней нагрузке на мониторинг. А данные эти чаще всего не нужны.

На этом всё. Основные настройки сделал. Дальше уже в зависимости от ситуации. Чаще всего настраиваются оповещения в Telegram. Раньше использовал какие-то сторонние скрипты, но последнее время надоело с ними разбираться. Использую стандартный шаблон от разработчиков. Он очень простой и малофункциональный, например, не умеет графики отправлять, использовать markdown разметку. Но мне обычно это и не нужно. Добавляю emoji в шаблон, немного редактирую его, убирая лишнее и пользуюсь.

#zabbix

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

💡Для тех, кто не знаком с Ceph, поясню, что это программная объектная отказоустойчивая сеть хранения данных. Если по-простому, то это кластер для хранения данных. Причём он может отдавать данные как обычные файлы через свою распределённую файловую систему cephfs, так и в виде блочных устройств. Первое актуально для кластеров, к примеру, под бэкапы или S3, а второе для файловых томов Kubernetes.

Ceph довольно навороченная система и с наскока её не осилить. В статье я постарался дать основную теорию и практику в виде установки кластера и примеров по работе с ним. Если у вас есть базовые навыки работы с Linux, то по статье вы сможете развернуть кластер и попробовать его в деле. Желательно, конечно, и Ansible понимать. Хотя бы на уровне чтения плейбуков и ошибок.

Один из вариантов использования Ceph - вместе с кластером Kubernetes. Достаточно купить любые 3 дешёвые дедика. Поставить туда Proxmox, нарезать виртуалки. На них раскатать Ceph и Kubernetes. Получится очень дешёвый тестовый кластер, который сможет сэкономить кучу денег. Он будет стоит в 3-5 раз дешевле, чем managed kubernetes. И при этом будет выдерживать выход одной ноды из строя. То есть вполне стабильное решение. Кто-то и прод таким образом строит.

⇨ https://serveradmin.ru/ustanovka-i-nastrojka-ceph

#ceph #devops

Заметил любопытную особенность в работе DHCP с которой раньше не был знаком. Когда клонировал виртуальные машины, заметил, что они получают одни и те же IP адреса, хотя я менял у сетевых интерфейсов MAC адреса. Я всегда был уверен, что выдача IP зависит от мака. Оказывается, что не только.

В качестве DHCP сервера выступал Mikrotik. Несмотря на изменение маков, он выдавал один и тот же IP адрес разным виртуалкам. Я выяснил, что выдача у него привязана к Client ID. Пока не изменить его, адрес не изменится.

В Linux этот ID указан в файле /etc/machine-id. Для того, чтобы его изменить, надо его удалить и сгенерировать заново:

# rm -f /etc/machine-id
# dbus-uuidgen --ensure=/etc/machine-id

Таким образом, после клонирования виртуальной машины нужно:

1️⃣ Изменить MAC адрес сетевого интерфейса.

2️⃣ Изменить hostname:
# hostnamectl set-hostname server-clone

3️⃣ Отредактировать файл /etc/hosts, изменив там имя сервреа.

4️⃣ Сгенерировать новый machine-id.

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

#dhcp

​​Некоторое время назад я рассказывал про любопытный сервис под названием Tailscale. Возвращаюсь к нему вновь, чтобы рассказать тем, кто про него не знает, о его существовании. А так же поделиться любопытными новостями, связанными с ним.

Кратко поясню, что это вообще такое. Очень условно Tailscale можно назвать аналогом популярного Hamachi. Его можно использовать в том же качестве, как и Хамачи, но не только. Это децентрализованная VPN-сеть, построенная на базе опенсорсного VPN-клиента WireGuard по принципу mesh-сети.

Для работы с Tailscale, вы ставите клиента на свои устройства (поддерживаются все популярные системы), и они объединяются в единую VPN сеть. Ничего настраивать не надо, работает максимально просто для пользователя. Всё взаимодействие с сетью происходит через сервер управления и веб интерфейс разработчиков. А вот это уже закрытый функционал, который продаётся за деньги. Есть бесплатный тариф для индивидуального использования с 20-ю устройствами.

Для личного использования бесплатного тарифа за глаза. Я проверял его, очень удобно. Недавно вышло нововведение - Tailscale SSH. Это встроенный в браузер SSH клиент, с помощью которого можно подключаться к своим серверам прямо из веб интерфейса. Реализовано удобно. Посмотреть, как работает, можно в демонстрационном ролике.

Со временем появилась open source реализация управляющего сервера - Headscale. Причём разработчики Tailscale отнеслись к нему благосклонно и помогают в разработке. Информируют об изменениях протокола. Палки в колёса не ставят. Проект очень живой, постоянно обновляется.

Мы имеем open source реализацию клиентов Tailscale от самих разработчиков, и серверную часть Headscale, которую можно развернуть на своих серверах. Отдельно есть репозиторий с веб интерфейсом для Headscale - headscale-ui. То есть практически весь функционал платного сервиса можно поднять бесплатно на своих серверах. В сети уже есть описания и руководства (пример 1, 2).

На вид всё это выглядит очень удобно и функционально. Если Headscale на практике без багов и особых проблем реализует функционал Tailscale, то такая система будет актуальна для больших установок. Там есть и внешняя аутентификация, и управление доступом на основе ACL, и управление маршрутами. Много всего, что требуется для больших коллективов.

⇨ Сайт / Исходники Tailscale / Headscale / Headscale-ui

#vpn #tailscale

​​Чтобы два раза не вставать, продолжу тему Tailscale. Покажу пару конкретных примеров личного пользования на базе бесплатного тарифного плана. Оба примера могут использоваться одновременно.

1️⃣ По умолчанию Tailscale заворачивает в VPN туннель только трафик своей сети. Но вы можете сделать так, что подключенное устройство весь свой внешний трафик (например, сёрфинг в интернете) будет заворачивать на одно из устройств сети.

К примеру, у вас есть какой-то внешний сервер для обхода блокировок. Вы добавляете все свои устройства в Tailscale, а для внешней виртуалки указываете настройку exit node. Выбранные вами устройства (например, смартфоны) после подключения будут заворачивать весь свой трафик на эту виртуалку по умолчанию. Описание настройки.

2️⃣ Если вы используете блокировщики рекламы, то можно настроить свой собственный сервер Pi-hole и использовать его возможности. Для этого надо добавить машину с настроенным Pi-hole. Далее в настройках Tailscale добавить DNS сервер, указав внутренний IP адрес Pi-hole сервера. И отдельно указать, что подключенным клиентам надо заменять их локальный DNS сервер на настроенный.

При сёрфинге с подключенным Tailscale все DNS запросы будут проходить через ваш Pi-hole и очищаться от рекламных доменов. Особенно это актуально для смартфонов. Если блокировку надо отключить, то просто отключаетесь от Tailscale. Описание настройки.

Ещё больше примеров и готовых инструкций можно посмотреть в документации в разделе How-to Guides.

Показанные выше примеры без проблем можно реализовать с помощью OpenVPN. Он умеет и настройки DNS, и маршруты передавать клиенту. Я неоднократно это настраивал. Но всё это делается в консоли, а для этого нужно хорошее понимание и знание работы OpenVPN. С Tailscale всё это делается за 5-10 минут через настройки в веб интерфейсе. Единственное, что надо будет настроить — включить маршрутизацию трафика на exit node. Но есть одно очень важное принципиальное отличие. OpenVPN весь трафик пропускает через себя, а Tailscale напрямую соединяет устройства. Трафик между ними идёт минуя управляющий сервер.

#vpn #tailscale

​​Хочу вас познакомить с очередной готовой сборкой почтового сервера, которую я развернул и потестировал лично. Результат мне понравился, так что делюсь подробностями. Речь пойдёт о сборке Mail-in-a-Box.

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

📌 Mail-in-a-Box состоит из следующих компонентов:
◽традиционные Postfix + Dovecot
◽веб интерфейс Roudcube + адресная книга от Nextcloud
◽z-push для Exchange ActiveSync
◽spamassassin и postgrey для борьбы со спамом
◽остальные компоненты: OpenDKIM, сертификаты от Let's Encrypt, duplicity для бэкапов, ufw в качестве фаервола, fail2ban, munin в качестве мониторинга, nsd4 в качестве DNS сервера.

Полная схема взаимодействия всех компонентов

Ставится всё это традиционно из пакетов, без Docker. Есть простой скрипт установщик, который всё это дело разворачивает на голой Ubuntu 22.04. Я на ней и проверял. Не знаю, заработает ли корректно автоматическая установка на других системах. Из всех настроек спросят только имя почтового сервера.

После установки всё управление выполняется через веб интерфейс. Сервер автоматически проверит все DNS записи, а также возможность отправки через 25-й порт. Если у вас провайдер его блокирует, то сразу об этом узнаете. Из настроек доступно только управление TLS сертификатами, в том числе автоматическое получение и установка Let's Encrypt, а также бэкапы, которые можно передавать с помощью rsync на любой сервер по SSH, либо складывать на S3 совместимое хранилище.

Компонент Postgrey реализует функционал Greylisting для новых отправителей. Я лично не люблю его и обычно не использую. Через веб интерфейс настроек никаких нет, но можно строку в конфиге postfix убрать, и он работать не будет. Ещё мне остался непонятен механизм управления spamassasin. Вообще ничего на нашёл на этот счёт. Автоматически подключен список zen.spamhaus.org для проверки отправителей. Отключить можно только через конфигурацию postfix.

Всё остальное сделано удобно. Через админку можно добавлять почтовые ящики, либо DNS записи. Настроенный сервер может выступать в качестве DNS сервера. Для пользователей доступны веб интерфейсы Roundcube для работы с почтой и Nextcloud для календаря и контактов. Поддерживаются почтовые адреса вида you+anythinghere@yourdomain.com. То есть к ящику you@yourdomain.com через + добавляется любая маска, а все письма с разными масками попадают в ящик you@yourdomain.com.

Дополнительно на сервере можно хостить статические страницы добавленных доменов. Там как веб интерфейс и так работает на веб сервере (nginx), плюс тут же есть управление DNS, разработчики решили добавить возможности простенького хостинга. Отдельно отмечу, что есть API для управления почтовыми ящиками.

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

Сборка мне понравилась. Опыта эксплуатации, понятное дело, у меня нет. Но я не вижу тут каких-то подводных камней, так как под капотом там типовые компоненты. Продукт известный, сообщество большое, идёт постоянное развитие и обновление. В репозитории большая активность. Из тех сборок, что мне известны на текущий момент, я бы рекомендовал именно эту. Она мне понравилась больше, чем бесплатная версия Iredmail.

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

#mailserver

​​▶️ Для тех, кому любопытно получить объяснение и принципы работы машинного обучения (ML, Machine Learning), рекомендую видео Дениса Астахова. Там он очень доступно даёт теорию по этой теме. Я так понял, что он начал изучать какой-то курс по ML, поэтому решил записать ролик на эту тему.

⇨ Основы Машинного Обучения на примере Распознавание Кота на картинке | MACHINE LEARNING

Для тех, кто не знает Дениса, рекомендую посмотреть его канал. Я раньше все его видео смотрел, пока не появился цикл про AWS, который в наше время для жителей РФ стал не актуален. Его пропускаю.

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

Меня позабавил один момент в его ролике. Он сам, если не ошибаюсь, родился в Крыму, потом переехал в Израиль. Жил там и работал несколько лет, знает иврит. Потом переехал в Канаду. Живёт и работает там уже много лет, общается, как я понимаю, на английском. А диск в его компьютере называется RAZNOE, как и у меня 😀 Не Various, не Разное, а Raznoe.

Как я уже сказал, на канале много полезных обучающих роликов, объединённых в законченные циклы обучения. Посмотреть их можно в плейлистах. Обращаю внимание на Terraform, Ansible, Jenkins, Git.

Отдельно отмечу ролики общей тематики, которые понравились мне лично:
◽Junior, Middle, Senior Девопс Инженер - Настоящие Примеры Задач
◽Чем пользуется DevOps Инженер на Работе: Tools, Software, Hardware
◽Как стать DevOps Инженером с Нуля, что учить и в каком порядке

#видео #обучение #devops

​​🎓 Мне на глаза попалась очень интересная русскоязычная научная публикация белорусского издания на тему:

Исследование производительности различных имплементаций Ingress контроллеров в кластере Kubernetes
⇨ http://www.vsbel.by/Portico/2021/3/130_Шуляк.pdf

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

Выводы тоже получились интересными. Сравнивали обратные прокси серверы в дефолтных настройках:
◽Traefik;
◽NGINX;
◽NGINX Inc.;
◽Envoy (управляющий слой Contour);
◽HAProxy.
Я так понял, что NGINX Inc. это платная версия Nginx.

💡Выводы получились следующие:

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

Зарекомендовавшие себя на рынке Ingress-контроллеры на базе обратных прокси-серверов NGINX имеют наихудшие показатели в стандартной конфигурации без модификаций.

❗️Так что если не умеете крутить настройки прокси, то разумнее всего выбрать HAProxy и не ломать голову над выбором.

#webserver

​​Существует простой и эффективный метод борьбы со спамом — Greylisting. Его переводят на русский как серый список. Расскажу вам простыми словами, как он работает, а также поделюсь своим опытом его использования.

Принцип работы Greylisting очень прост. Когда на сервер поступает письмо от нового адресата, с которым он ещё не взаимодействовал, письмо отклоняется с временным кодом ошибки 4ХХ, обычно 450. Согласно rfc5321, отправитель, получив такую ошибку, должен выполнить повторную отправку через некоторое время. В rfc оно указано как не менее 30 минут, если я правильно понял (the retry interval SHOULD be at  least 30 minutes). На практике обычно это время меньше. В postfix по умолчанию оно равно 3 минутам.

Вот тут и кроется главная проблема. Не все серверы делают повторную отправку через 3 минуты. Это всё может настраиваться индивидуально, а rfc не указывает конкретные значения. В итоге может так получиться, что пользователь в течении 10-20 минут не сможет получить письмо от нового контрагента, что очень раздражает. Случается такое не часто, но бывает.

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

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

Во многих готовых почтовый сборках этот механизм включён по умолчанию. Например в Iredmail или Mail-in-a-Box. Я лично всегда его отключают, потому что даже задержка письма на 5-10 минут хотя бы раз в месяц вынудит пользователя сообщить поддержке, что с доставкой какие-то проблемы. И надо будет разбираться, объяснять в чём тут дело. Популярна ситуация, когда пользователь разговаривает с кем-то по телефону и тут же обменивается почтой. И письмо не приходит сразу. Для разговора в режиме реального времени задержка в 3 минуты значительна и раздражает. Приходится ждать, обновлять ящик, отправлять ещё раз и т.д.

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

#mailserver

​​Для быстрой и простой проверки Docker образов на уязвимости существует популярный Open Source инструмент — Trivy. Я покажу на примере, как им пользоваться. Получится готовая мини инструкция по установке и использованию.

Установить Trivy можно разными способами: из репозитория с пакетами, собрать с помощью Nix, воспользоваться bash скриптом, запустить в Docker. Все способы описаны в документации. Я установлю в Debian из репозитория.

# apt install wget apt-transport-https gnupg lsb-release
# wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \
| gpg --dearmor | tee /usr/share/keyrings/trivy.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] \
https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" \
| tee -a /etc/apt/sources.list.d/trivy.list
# apt update
# apt install trivy

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

# docker pull mcr.microsoft.com/oss/nginx/nginx:1.21.6
# trivy image --vuln-type os --ignore-unfixed \
-f json -o nginx.1.21.6.json mcr.microsoft.com/oss/nginx/nginx:1.21.6

Результат проверки будет в файле nginx.1.21.6.json, что удобно для последующего автоматического анализа. Можно наглядно посмотреть результат в консоли:

# trivy image --vuln-type os \
--ignore-unfixed mcr.microsoft.com/oss/nginx/nginx:1.21.6

Trivy отлично подходит для автоматической проверки образов перед их отправкой в registry. Да и просто для быстрого анализа созданного или скачанного образа. Помимо проверки образов, он умеет сканировать git репозитории, файлы с зависимостями (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock).

Следующей будет заметка с описанием автоматического исправления уязвимостей в образах на основе отчётов trivy.

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

#security #docker #devops

Хотите научиться работать в DevSecOps проектах?

⚡️ Приглашаем 19 января в 20:00 мск на бесплатный вебинар «Сервисная сетка на базе Istio в Kubernetes». 

На занятии мы:
✅ Рассмотрим один из базовых инструментов для обеспечения безопасности Kubernetes-кластеров — сервисная сетка (service mesh) на базе opensource-инструмента Istio. 
✅ Посмотрим, из каких компонентов состоит сервисная сетка, как устроен инструмент Istio (control и data plane, sidecar, envoy), как осуществляется и внедряется термин наблюдаемости (observability). 
✅ Продемонстрируем, как развернуть k3d-кластер, проинсталировать Istio и добавить в сервисную сетку свое первое приложение, развернутое в Kubernetes-кластер. 

👉🏻 Регистрация на вебинар: https://otus.pw/GYpK/

​​Продолжаю тему безопасности Docker контейнеров. С помощью Trivy можно проверить образ на уязвимости. Теперь расскажу, как их автоматически исправить. Для этого нам понадобится Copacetic. Он будет брать информацию из отчётов Trivy. Для запуска copa cli нам нужно:

1️⃣ Установить Go v1.19 или новее.
2️⃣ Собрать и установить runc.
3️⃣ Установить buildkit v0.10.5 или новее.
4️⃣ Собрать и установить copa.

Я кратко без пояснений покажу как это сделать на примере Debian. Все подробности есть в самих репозиториях программ.

✅ Устанавливаем GO.
# wget https://go.dev/dl/go1.19.5.linux-amd64.tar.gz
# tar -C /usr/local -xzf go1.19.5.linux-amd64.tar.gz
# ln -s /usr/local/go/bin/go /usr/bin/go
# go version

✅ Устанавливаем runc.
# apt install make git gcc build-essential pkgconf libtool libsystemd-dev \
libprotobuf-c-dev libcap-dev libseccomp-dev libyajl-dev libgcrypt20-dev \
go-md2man autoconf python3 automake
# git clone https://github.com/opencontainers/runc
# cd runc
# make
# make install

✅ Устанавливаем buildkit.
# wget https://github.com/moby/buildkit/releases/download/v0.11.0/buildkit-v0.11.0.linux-amd64.tar.gz
# tar -C /usr -xzf buildkit-v0.11.0.linux-amd64.tar.gz

✅ Устанавливаем copacetic.
# git clone https://github.com/project-copacetic/copacetic
# cd copacetic
# make
# mv dist/linux_amd64/release/copa /usr/local/bin/

Все необходимые компоненты установили. Теперь патчим уязвимый контейнер. Для этого предварительно в фоне запускаем buildkitd:
# buildkitd &
# copa patch -i mcr.microsoft.com/oss/nginx/nginx:1.21.6 -r nginx.1.21.6.json -t 1.21.6-patched

Copa не перезаписывает старый образ, а создаёт новый с тэгом patched. Можете сразу его посмотреть и проверить:
# docker images
# docker history mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

Ну и убедиться, что он нормально запускается:
# docker run -it --rm --name nginx-test mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

Copa, используя информацию о версиях пакетов из отчёта Trivy, обновила все уязвимые системные пакеты в образе. Можете проверить уже пропатченный образ:
# trivy image --vuln-type os --ignore-unfixed mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

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

⇨ Исходники Copacetic

#security #docker #devops

​​Все или почти все системные администраторы знают такой инструмент как Nmap. Если не знаете, познакомьтесь. Я сам не раз писал о нём на канале. Основной его минус — медленное сканирование. Есть альтернативная программа — Zmap, где проблема скорости решена, но и функционал у программы намного беднее.

А если хочется сканировать ещё быстрее? Чем вообще сканируют весь интернет? Сейчас это обычное дело. Для этого используют тоже open source программу — masscan. Она написана изначально под Linux, но можно собрать и под другую систему. В репозитории нет готовых сборок, но, к примеру, в Debian, поставить можно из стандартного репозитория:
# apt install masscan

Дополнительно понадобится библиотека Libpcap для анализа сетевых пакетов:
# apt install libpcap-dev

Masscan очень быстрый за счёт того, что использует свой собственный TCP/IP стек. Из-за этого он не может ничего делать, кроме как выполнять простое сканирование. В противном случае будут возникать проблемы с локальным TCP/IP стеком операционной системы. Для быстрого сканирования используются массовые асинхронные SYN пакеты только для обнаружения. А чтобы собирать полноценную информацию, как умеет Nmap, нужно устанавливать полноценные TCP соединения и ждать информацию.

Вот пример сканирования в сети 80-го порта с ограничением в 100 пакетов в секунду:
# masscan -p80 192.168.13.0/24 --rate=100
Scanning 256 hosts [1 port/host]
Discovered open port 80/tcp on 192.168.13.2                   
Discovered open port 80/tcp on 192.168.13.50

Вся сеть просканирована за пару секунд. А теперь немного ускоримся до 10000 пакетов в секунду и просканируем весь диапазон портов в той же сети:
# masscan -p0-65535 192.168.13.0/24 --rate=10000
На это уйдёт примерно 30 минут. Нагрузка на железо будет значительная, так что аккуратнее. Лучше начинать с более низких значений. Виртуалка на Proxmox без проблем переварила 10000 пакетов в секунду, а вот если запустить на рабочем ноуте в виртуалке HyperV, то начинает подтормаживать хостовая система.

Процесс сканирования можно в любой момент прервать по CTRL + C. Результат будет сохранён в файл paused.conf. Возобновить сканирование можно следующим образом:
# masscan --resume paused.conf
Если получите ошибку
CONF: unknown config option: nocapture=servername
то это баг более старой версии. В репах Debian именно она. Строку с nocapture = servername надо просто удалить из файла и всё заработает.

Если будете сканировать через NAT, то не забудьте, что существует ограничение на количество возможных одновременных соединений в роутере. Это если надумаете сканировать весь интернет с домашнего компьютера😀 Быстро всё равно не получится. За обещанные 5 минут не уложитесь. Если вы всё же настроены просканировать весь интернет, то в отдельной доке есть подсказки, как это лучше сделать.

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

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

#network