В продуктах Proxmox не так давно появилась возможность использовать сторонние SMTP сервера для отправки уведомлений. Точнее, стало возможно через веб интерфейс настроить аутентификацию на внешнем сервере. В PVE вроде бы с 8-го релиза появилась эта настройка, в PBS не помню точно.

В разделе меню Notification обоих продуктов появился новый тип уведомлений SMTP, где можно указать привычные параметры внешних почтовых серверов. Тем не менее, если для отправки используется бесплатный почтовый сервис типа Yandex, Mail или Gmail, я предпочитаю настраивать по старинке через локальный Postfix, который так же использует внешний SMTP сервер с аутентификацией.

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

Настройка Postfix простая. Не помню, устанавливается ли он в свежих версиях PVE и PBS по умолчанию, но если нет, то надо поставить:

# apt install postfix

И затем добавить в конфиг /etc/postfix/main.cf, например, для Яндекса:

relayhost = smtp.yandex.ru:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_generic_maps = hash:/etc/postfix/generic

Если эти же параметры где-то выше уже объявлены, то закомментируйте их там. Создаём файл /etc/postfix/sasl_passwd такого содержания:

smtp.yandex.ru user01@yandex.ru:userpass123

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

Создайте файл /etc/postfix/generic:

root@pve user01@yandex.ru

Здесь мы настраиваем, чтобы все письма от локального пользователя root сервера с именем pve отправлялись с заменой адреса отправителя на user01@yandex.ru. Иначе Яндекс не примет письмо к отправке. У других почтовых сервисов может не быть таких ограничений и этот шаг можно будет пропустить.

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать postfix, и перезапускаем его:

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Можно проверять отправку. Проще всего это сделать в веб интерфейсе PVE. Для этого идём в раздел Datacenter ⇨ Notification. Там по умолчанию уже есть способ отправки типа sendmail с указанным Target mail-to-root. Это как раз отправка почты с помощью Postfix на ящик системного пользователя root@pam. Ящик для него можно указать в настройках пользователя: Datacenter ⇨ Permissions ⇨ Users ⇨ root ⇨ E-Mail.

Выбираем способ отправки sendmail и жмём Test. Можно сходить в консоль сервера и проверить лог отправки. Если всё прошло успешно, то в /var/log/mail.log будет примерно следующее:

pve postfix/pickup[941603]: 4C81718E07A1: uid=0 from=<user01@yandex.ru>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<user01@yandex.ru>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<superadmin@yandex.ru>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=0.48, delays=0.03/0.02/0.17/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net 1724185545-jPUEPlgXtGk0-KOiggjh6)
pve postfix/qmgr[941604]: 4C81718E07A1: removed

Сервер успешно использовал relay=smtp.yandex.ru и отправил с его помощью письмо superadmin@yandex.ru, получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

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

#proxmox

Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

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

#sso #nginx

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

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

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

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

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

Формирую набор правил именно в таком виде, потому что он мне кажется удобным и наглядным. Можно быстро оценить все правила, оставить комментарии, что-то добавить.

#proxmox #iptables

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

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

⇨ Настройка DNS over HTTPS в OPNsense
Небольшой ролик про DNS over HTTPS для тех, кто не знает, что это такое и как работает. Тут автор кратко рассказал о технологии и на практике показал, как это работает и как настраивается на своём софтовом шлюзе OPNsense.

⇨ Netbird Update - How to add the new "Relays" feature to your netbird install.
Рассказ про бесплатную, open source платформу для построения VPN сетей - netbird.io. Вышло крупное обновление продукта. Автор рассказал, как его установить и что в нём нового. Вообще, это интересный продукт. Я видел его обзор у разных блогеров, писал заметку про него. Один из лучших open source проектов из этой области.

⇨ Vinchin - Backup система для ВСЕГО!
Обзор системы для бэкапа Vinchin. Автор прошёлся по основным возможностям. Я в своё время примерно то же самое оформил в отдельную статью на сайте. Система, в принципе, неплохая. Мне понравилась.

⇨ Building a Low-Power, Fully Loaded Plex Server
Подробное описание сборки сервера под популярный медиасервер Plex для дома. Автор поставил задачу собрать тихий и маломощный в плане потребления электричества сервер на базе Mini ITX. Интересно посмотреть, что у него в итоге получилось.

⇨ Администрирование Линукс. Стабильность и безопасность системы
Короткое видео с наглядным примером эксплуатации уязвимости ярда Linux CVE-2024-1086. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.

#видео

Когда только начинал работать с виртуализацией на Linux, очень хотелось сесть за сервер и прямо на нём что-то сделать. Но на тот момент ни XenServer, ни VmWare не позволяли это сделать. На экране сервера был небольшой список простых действий типа настроек сети или перезагрузки. И ничего, что относилось бы к управлению виртуальными машинами. После экспериментов с VMware Workstation и Hyper-V было как-то непривычно и неудобно.

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

В Proxmox решить эту задачу очень просто. Под капотом там обычная система Debian, на которую можно установить графическую оболочку. Более того, как это сделать, рассказано в официальной Wiki проекта. Там это названо так:

⇨ Developer Workstations with Proxmox VE and X11

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

Выполняем непосредственно гипервизоре:

# apt install xfce4 chromium lightdm

Добавляем пользователя, от имени которого мы будем заходить и подключаться к веб интерфейсу:

# adduser webuser

Запускаем графическую оболочку:

# systemctl start lightdm

Можно подключать монитор к серверу, заходить в систему и подключаться к локальному веб интерфейсу по адресу https://localhost:8006.

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

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

#proxmox