ServerAdmin.ru

Одним из самых популярных репозиториев на github (21-е место по кол-ву звёзд) является репозиторий с ohmyzsh. Это фреймворк для создания конфигураций оболочки zsh. Для тех, кто не понимает, что это такое, скажу просто. Это сильно прокачанный по функциональности bash.

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

Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:

# apt install zsh
# wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
# sh install.sh

Дальше поверх этого делаются различные настройки

Основные возможности ohmyzsh:

◽️Поддержка тем для консоли и промта в частности. Причём тем не только по изменению внешнего вида, но и в плане функциональности: отображение ветки git, таймер выполнения текущей команды и другие возможности.

◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.

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

С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.

А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.

#terminal #linux

Есть небольшой и неприметный сервис, который может очень существенно помочь в отладке различных HTTP запросов. В контексте тематики канала он может помочь в создании и отладке мониторинга. Речь пойдёт о httpbin.org. Это публичный сервис, который можно использовать как по указанному адресу, так и запустить у себя локально:

# docker run -p 80:80 kennethreitz/httpbin

По главной странице сервиса не совсем понятно, как его использовать. Я покажу сразу на примерах. Допустим, вы настраиваете мониторинг сайта или API. Вам нужно проверить работу различных триггеров. Например, на код ответа 404. Чтобы получить от httpbin код ответа 404, обращаемся к нему по адресу:

# curl -I "https://httpbin.org/status/404"
HTTP/2 404

Соответственно, если вам нужен другой код, то просто меняете его:

# curl -I "https://httpbin.org/status/501"
HTTP/2 501

Аналогично можно тестировать ответы с заданными заранее заголовками. Проверяем ответ с заголовком Server=httpbin

# curl "https://httpbin.org/response-headers?Server=httpbin"
{
 "Content-Length": "92",
 "Content-Type": "application/json",
 "Server": "httpbin"
}

Идём далее. Тестируем триггер на время ответа сервиса. Например, проверяем работу при задержке более 3-х секунд:

# curl "https://httpbin.org/delay/3"

Получите тестовый ответ с задержкой в 3 секунды. Можно проверить с помощью time.

# time curl "https://httpbin.org/delay/3"

Учимся принимать поток из нескольких строк. В данном случае трёх:

# curl "https://httpbin.org/stream/3"

Получите 3 разных строки с json.

Принимаем картинку:

# curl "https://httpbin.org/image/png"
# curl "https://httpbin.org/image/png" --output picture.png

Сервис много всего умеет. Посмотрите на главной странице, открывая раскрывающиеся списки. Я привёл самые ходовые на мой взгляд примеры при настройке типового мониторинга. А так там поддерживаются и разные методы, и динамические списки, и разное сжатие, и куки, и кодирование и т.д.

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

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

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

#мониторинг

С системным временем в Linux с одной стороны всё просто - установил и запустил какую-то службу для синхронизации и дальше всё работает автоматически. Например службу systemd-timesyncd, chrony или ntp. А с другой - есть множество нюансов, которые в основном связаны с особенностями systemd.

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

Заметил ещё такую особенность. Служба chrony в Debian как правило со своими стандартными настройками запускается и отрабатывает раньше всех, а вот в Ubuntu - нет, хотя настройки юнитов вроде как схожи. Но я не разбирался детально. В systemd не так просто разобраться. Много нюансов и ссылок с зависимостями юнитов, таргетов и т.д. А если взять службу systemd-timesyncd, то она по умолчанию может довольно поздно запуститься. Я последнее время именно её использую, чтобы не ставить лишних пакетов в систему, но по факту chrony удобнее и функциональнее.

Эту проблему частично можно решить простым хаком в лоб. Ставим chrony и создаём службу, которая будет стартовать раньше всех остальных, один раз запускать синхронизацию и выключаться. А дальше уже всё остальное будет загружаться как обычно. Не нужно будет лезть в потроха systemd и разбираться в настройках и зависимостях стандартных служб.

# apt install chrony
# systemctl edit --full --force chrony-once-sync.service

[Unit]
Description=Chrony one time sync and exit
Wants=network-online.target
After=network-online.target
Before=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/chronyd -t 10 -q
RemainAfterExit=True
[Install]
WantedBy=multi-user.target

# systemctl enable chrony-once-sync.service

Можно посмотреть зависимости служб:

# systemctl list-dependencies --after

Chrony-once-sync.service должна стоять первой в списке multi-user.target. Перезагружаемся и проверяем. Смотрим, как отработала служба:

# journalctl -u chrony-once-sync

Также можно посмотреть весь лог загрузки и убедиться, что chrony-once-sync.service отработала раньше всех остальных. Практически сразу после активации сети.

# journalctl

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

[Unit]
After=chrony.service

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

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

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

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

#systemd

Не так давно (в декабре 2024) на свет появилось любопытное ПО, которое условно можно назвать аналогом Apache Guacamole. Речь пойдёт о Termix – open source шлюзе и менеджере подключений к удалённым системам. Я его попробовал. Понравились идея и реализация, так что решил написать о ПО, хотя оно ещё по сути в стадии разработки и использовать его можно только для тестов или каких-то локальных контуров. Пишу о нём, чтобы не забыть и потом вернуться к более зрелым версиям.

Идея Termix следующая. Вы устанавливаете и настраиваете веб приложение, в которое добавляете удалённые соединения к серверам и другим системам. В настоящий момент работает только SSH, но в планах у автора VNC, RDP, SFTP. В браузере логинитесь в личный кабинет и оттуда получаете доступ к своим соединениям, которые работают там же в браузере. Причём у вас есть возможность делиться доступом к соединениям с другими пользователями. То есть это по сути групповой менеджер соединений с управляемым доступом.

Проект уже рабочий, можно попробовать. Запускаем через docker compose:

# mkdir ~/termix && cd ~/termix
# touch docker-compose.yml

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - mongodb-data:/data/db
    environment:
      SALT: "2v.F7!6a!jIzmJsu|[)h61$ZMXs;,i+~"

volumes:
  mongodb-data:
    driver: local

# docker-compose up -d

Идём по IP адресу сервера на порт 8080 и создаём нового пользователя. Далее добавляем соединения и подключаемся. Как я уже сказал, пока доступен только протокол SSH и аутентификация по паролю или ключу.

Сделано всё максимально просто и удобно, не то, что Apache Guacamole. Я его не очень люблю. Функционально он нормально сделан, но в плане установки и настройки немного геморройно. Постоянно приходится вспоминать формат конфигов, решать какие-то мелкие проблемы.

А тут всё просто. Запустил и пошёл в веб интерфейс создавать подключения. Сразу всё получилось без каких-то нюансов.

Автор планирует добавить разные темы терминалам, управление правами доступа на основе пользователей и групп, SSH туннелирование, 2FA ну и другие протоколы, которые я уже упоминал. Надеюсь у него всё получится. Мне кажется, продукт будет востребован. Да, такого рода софт уже есть, но он более сложен и масштабен. А вот такого простого, чтобы зашёл, быстро настроил, расшарил по пользователям и начал пользоваться, нет.

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

⇨ 🌐 Исходники / ▶️ Обзор

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

#remote

Я постоянно смотрю интервью с умными, успешными людьми. Это не потому, что сам хочу стать успешным или добиться чего-то особенного. У каждого своя судьба и свой успех. Не могу сказать, что это прям как-то особенно мне помогает в жизни, но кое-что откладывается в голове. Просто сформировалось такое хобби. Мне нравится, доставляет некоторое удовольствие возможность послушать умного и добившегося в какой-то сфере успеха человека. Когда гуляю, куда-то еду, включаю и слушаю. Тематика очень разная, не только IT. Чаще как раз это что-то из другой сферы, но здесь подсвечиваю только IT.

Сейчас хочу обратить ваше внимание на два интервью очень своеобразных, умных и известных практически на весь мир IT специалистов родом из России. Интервью записаны 6 лет назад, но посмотрел я их только недавно. Какие-то технические вещи уже устарели или стали очевидны, но это ничего принципиально не меняет, так как мне в первую очередь понравились мысли людей о развитии, обучении, выборе профессии, работы и т.д.

Артемий Кропачев:
▶️ Red Hat эксперт №1 в мире | RHCA сертификация | Вакансии в США
▶️ Red Hat эксперт №1 в мире | Как построить успешную карьеру в ИТ | Вакансии

Денис Зуев:
▶️ Из геймера в IT-супермена | Из России в США | 65 сертификатов Cisco, Red Hat, Juniper Network и др
▶️ Кому платят $400 000 в IT | Что ждет сисадминов в будущем

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

📌 Упорство и труд всегда дают результат. Оба специалиста из неприметной российской глубинки (Тюмень и Киров). Добились всего сами своим упорным трудом. Артемий привёл хорошие примеры, когда его знакомые и родственники, вообще далёкие от IT, меняли сферу деятельности, готовились к сертификации, проходили её и получали работу. Да, кому-то было тяжело, кому-то сильно тяжело, не все получили высокооплачиваемую работу. Но суть в том, что каждый, кто работал над собой и учился, получил результат.

📌 По словам Артемия уже в 2018 году без автоматизации (Ansible) и контейнеризации (Docker) ловить в топовом IT нечего. Это база для всех, и админов, и девопсов. Важнее уметь быстро масштабировать или перезапустить сервис в новом месте, нежели лезть в системные дебри и разбираться, в чём проблема. Это стоит делать, только если первое не помогло.

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

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

📌 Теория без практики – пустая трата времени. Если хотим что-то изучить, сначала берём и делаем, потом закапываемся в теорию по ходу дела, чтобы углубить знания.

📌 Резюме должно быть коротким. Всё основное в виде ключевых слов по технологиям должно быть на первой странице.

Если у кого-то есть рекомендации по похожим интервью, с удовольствием приму их и посмотрю.

#разное #совет

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

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

⇨ Как взломать #Go приложение? Разбираю #CTF таск #GOTchaberg
Очередной разбор взлома площадки с CTF задачами по хакингу от Mekan Bairyev. Как всегда интересное информативное видео.

⇨ ЗАРПЛАТА DevOps 2025 г. Что с ними произошло?
Автор провёл опросы по зарплатам на своих публичных ресурсах и подбил итоги с конкретными цифрами. Было интересно познакомиться с ними. Ожидал увидеть чуть более высокие медианные зарплаты. Нужно только не забывать, что это срез конкретно его подписчиков, а не средние цифры по отрасли. Хотя скорее всего они должны быть +- такими же.

⇨ GPU passthrough in Fedora VM (Проброс видеокарты в виртуальную машину на базе Fedora)
Автор виртуализировал своё рабочее место и рассказал об этом в контексте проброса видеокарты в виртуальную машину. Он решил перейти с Windows на виртуальное рабочее место под Linux. Для этого сделал виртуалку, пробросил туда клавиатуру, мышку, видеокарту и сел за гипервизор, как за обычное рабочее место. Мне даже и в голову не приходило, что так можно. Удобно получается.

⇨ Nginx — Простым языком на понятном примере
Автор неплохо разложил и описал работу веб сервера Nginx. Сам он разработчик и записал видео для разработчиков, но если для вас актуальна эта тема, то можете тоже посмотреть. Даётся база, если вы Linux админ и поднимали веб сервера, смотреть смысла нет.

⇨ Termix: An Early Look - See the Future of Self-Hosting
Краткий обзор настраиваемого терминала с вкладками в браузере. Удобное и функциональное решение для тех, кому это необходимо. Сделаю по нему отдельный обзор.

⇨ Self-Host a local AI platform! Ollama + Open WebUI
Интересное и подробное видео на тему того, как автор настраивал у себя локальные модели ИИ. Какие ресурсы нужны, как он всё это запускал в Proxmox, как настраивал веб интерфейс и т.д.

⇨ Итеративный и рекурсивный режимы DNS | Компьютерные сети 2025 - 24
⇨ Транспортный уровень | Компьютерные сети 2025 - 25
Очередные уроки обновлённого курса по сетям.

⇨ Warp AI Terminal: Best Terminal for DevOps and HomeLab!
Обзор терминала с интегрированным ИИ и разными моделями на выбор для подсказок команд и другой теории. Было любопытно посмотреть, но лично мне это не показалось удобным.

#видео

Решил для удобства собрать все бесплатные почтовые сервера, что упоминались на моём канале. Разбил их по категориям.

🟢 Свой почтовый сервер на базе Postfix + Dovecot – моя статья по настройке типового почтового сервера на Linux.

Серверы только в виде Docker контейнеров:

🟢 Mailu – классический стек на базе Postfix + Dovecot + Roundcube + Rspamd + Clamav и т.д. Свой удобный веб интерфейс администратора. Для установки есть готовый конфигуратор, который формирует docker-compose.yml и .env для запуска. Хорошее решение для тех, кому нужен стандартный почтовый сервер, запущенный в Docker.

🟢 Mailcow – похожий на Mailu почтовый сервер на базе того же стека, но чуть более функциональный. В качестве веб клиента используется SOGo, есть ActiveSync, интеграция с Netfilter, поддержка TFA и TOTP. У проекта более навороченная админка, где можно управлять не только почтовым сервером, но и самой системой, контейнерами.

☝️Оба сервера хороши. Кому нужно попроще, берём Mailu, кому понавороченней - Mailcow.

▪️Docker Mailserver – ещё один стандартный стек на базе Postfix + Dovecot. Особенность сборки - максимальная простота и минимум своих наработок. СУБД не используется, пользователи хранятся в файлах, все сервисы используют стандартные конфиги. Потребление ресурсов минимальное.

▪️Poste.io – тоже на базе Dovecot + Roundcube и т.д., только вместо Postfix используется Haraka. Админка своя, уникальная. Весь проект упакован в один контейнер. Есть отдельно платная PRO версия, куда перенесена часть полезной функциональности. Я не увидел у него преимуществ перед Mailu и Mailcow, поэтому рекомендую их.

Серверы под Windows:

▪️hMailServer – очень простой в настройке почтовый сервер. Проект старый и популярный. Особых наворотов нет, только базовые возможности почтового сервера. Подойдёт для тех, кому нужен простой бесплатный сервер под Windows, для настройки которого не нужны особые навыки. Есть интеграция с AD.

Серверы на базе Postfix и системных пакетов:

▪️Iredmail – классическая сборка на базе Postfix + Dovecot и всего остального по списку. В плане функциональности бесплатная версия не представляет из себя ничего интересного, но проект популярен за счёт своего возраста. На момент появления имел автоустановщик в виде готового скрипта и веб интерфейс администратора. Сейчас при наличии других бесплатных серверов не вижу особого смысла в его использовании.

▪️Mail-in-a-Box – по сути аналог Iredmail, только без ограничений бесплатной версии. Установка через скрипт под Ubuntu. Пользователи хранятся в sqlite, админка - PostfixAdmin. Простой стандартный стек на базе open source компонентов. Минус - проект одного человека.

🟢 Modoboa – ещё одна стандартная сборка со своей админкой и веб клиентом на Python. Приятная особенность - встроенный мониторинг и отчёты.

Собственные разработки почтовых серверов:

▪️Stalwart Mail Server – современный и очень функциональный почтовый сервер. Есть поддержка протокола JMAP. Единая админка для бесплатной и коммерческой версии, где перемешаны возможности. Неинтуитивная настройка, малая известность. Один из самых функциональных open source решений.

▪️Carbonio CE – сервер от компании Zextras, которая писала и продавала расширения для Zimbra. После того, как последняя перестала собирать свои бесплатные бинарные сборки, Zextras решили сделать свой сервер и перенести свои наработки. Несмотря на то, что он построен на базе Postfix и Dovecot, вынес его в свою разработку, так как он сильно разбавлен кодом в виде расширений самой Zextras и Zextras Webmail (форк Zimbra Webmail). По сути это не только почтовый сервер, а проект для совместной работы. Отзывов про него мало, в основном не очень.

🟢 Mox – почтовый сервер из одного бинарника на Go. Максимально простая и быстрая настройка. Только базовая функциональность почты. Подойдёт для небольших или разовых задач.

Серверы только для рассылок:

◽️Mailman
◽️Cuttlefish
◽️Postal

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

#подборка #mailserver

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

Но сейчас я наглядно вижу, что стоимость многой техники подешевела в рублях. Даже мой моник, который купил в апреле прошлого года, сейчас стоит дешевле. Весь инструмент CAT, купленный в декабре, заметно подешевел. Особенно обидно за комплект с дрелью. Взял за 24, а сейчас он 18 стоит. Заказал себе ещё 3 позиции (запасной аккум, мощный фонарь и винторез), раз уж такая история. Микрот, купленный в ноябре, тоже сейчас немного дешевле. Я ещё много бытовой техники брал по ходу года, она тоже немного сбавила, что вообще невиданно. Много последний год-два покупаю, так как дом надо обставить, плюс почти весь инструмент купил, и всегда всё только дорожало.

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

#железо

У меня остался нерассмотренным из закладок один многообещающий почтовый сервер – Stalwart Mail Server. Посмотрел сайт, документацию, репозиторий на github. Показалось вначале, что это прям то, что надо. Прикинул, что бесплатная версия может заменить ушедшую Zimbra. Полноценно подготовил тестовый домен, сделал все DNS записи, развернул и стал тестировать. Изначально решил его не только для теста, но и на постоянку развернуть, если всё будет ОК.

Привлекли в первую очередь следующие возможности:

◽️Новый протокол JMAP.
◽️Огромный список бэкендов для хранения почты: RocksDB, FoundationDB, PostgreSQL, mySQL, SQLite, S3-Compatible, Azure, Redis, ElasticSearch. Такого просто нигде не видел.
◽️Полнотекстовый поиск на 17-ти языках. Нигде не видел полный список, но когда выбирал ru, ошибок не получал. Вроде как поддерживается.
◽️Аутентификация через OpenID, LDAP, OIDC, SQL, дополнительно 2FA-TOTP, отдельные пароли для аутентификации приложений.
◽️Всё остальное присутствует в полном объёме - все протоколы TLS, борьба со спамом, многодоменность, права доступа на основе групп, лимиты и ограничения, возможность гибко настраивать все этапы обмена сообщениями на уровне протокола и т.д.

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

Развернул я сервер по инструкции в Docker:

# docker run -d -ti -p 443:443 -p 8080:8080 \
  -p 25:25 -p 587:587 -p 465:465 \
  -p 143:143 -p 993:993 -p 4190:4190 \
  -p 110:110 -p 995:995 \
  -v /var/lib/stalwart-mail:/opt/stalwart-mail \
  --name stalwart-mail stalwartlabs/mail-server:latest

Сразу скажу, что не понравилось:

# docker logs stalwart-mail

В выводе пусто. Логи так не посмотреть.

Дальше я начал очень долго возиться с тем, чтобы просто подцепиться к серверу через Thunderbird. Нигде в документации не указано, что для этого нужно. Методом проб и ошибок выяснил, что:

1. Проходить аутентификацию нужно только указав пользователя, а не полный почтовый ящик. Не очень понял, как это будет работать, если у пользователя будет несколько ящиков в разных доменах.
2. По умолчанию сервер запускается без TLS и вроде как работает. Thunderbird автоматом подбирает его настройки без шифрования. Но где-то в глубинах сервера в настройках smtp стоит параметр не разрешать аутентификацию без TLS. Включил TLS, запустил на самоподписанном сертификате, заработало.
3. Правильные настройки, с которыми я в итоге подключился: imap 143 STARTTLS, smtp 587 STARTTLS.
4. Логи сервера, которые можно посмотреть через веб панель администратора вообще никак не помогли решить проблему. Они неинформативны в части ошибок.
5. В веб интерфейсе администратора смешаны бесплатные и платные возможности.
6. Нигде нет простого способа посмотреть, от кого и к кому отправлено письмо, кроме как парсить общий лог.
7. У меня иногда не доставлялись письма от себя к себе. В логах пусто. Не стал разбираться с этой ошибкой.

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

Отдельно скажу пару слов про JMAP. Протокол по описанию неплох. Письма и другие сущности обернули в json и отдают по HTTP через запросы к API. Модно и современно, но нужна поддержка клиентов. Особой популярности он пока не приобрёл. Из популярных клиентов поддерживает K-9 Mail, есть плагин для Roundcube.

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

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

#mailserver

Продолжу тему насчёт невнимательности и ошибок. И речь будет опять про rsync. Один раз он меня очень жёстко наказал за ошибку. С тех пор я внимательно проверяю и перепроверяю все его параметры.

Чаще всего rsync используется с ключом --delete для того, чтобы получить актуальную копию источника. Если на приёмнике какие-то файлы устарели, или на источнике уже удалены, на приёмнике они тоже удалятся. И горе вам, если вы перепутаете местами источник с приемником, особенно при первой синхронизации, когда у вас приёмник пустой. Речь вот о чём:

# rsync -av --delete /mnt/backup/data/ root@10.20.1.5:/data/

Одной командой с rsync вы обнулите источник на 10.20.1.5, если директория /mnt/backup/data/ пустая. Причём удаляет rsync очень быстро. Я как-то проводил тестирование и делал заметку по этому поводу. Rsync с пустым приёмником чуть ли не быстрее всех удаляет большое файловое хранилище. Времени опомниться и остановить процедуру у вас практически не будет, особенно если это будет выполняться локально. По SSH ещё есть шансы, если сразу остановите.

Я в голове всегда произношу мантры, когда настраиваю rsync: "Откуда копирую и куда". У него сначала идёт источник, а потом приёмник. Казалось бы, это очевидное поведение, но на самом нет. Сбивает с толку другой софт. Например, в tar сначала указываешь куда сжимать, а потом уже что сжимать:

# tar -czvf files.tar.gz /data/files

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

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

#rsync

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

Я очень часто использую rsync для бэкапа. В том числе с ключами  --backup и --backup-dir, о которых отдельно рассказывал не так давно в заметке. Эти ключи позволяют хранить изменения за день, если бэкап выполняется раз в сутки. У меня они лежат в таких директориях:

/mnt/backup/increment/2025-03-15
/mnt/backup/increment/2025-03-16
/mnt/backup/increment/2025-03-17

Сам бэкап делаю так:

# /usr/bin/rsync -av --delete back_user@10.20.5.5:/data/mail/virtual/ /mnt/backup/mailsrv --backup --backup-dir=/mnt/backup/increment/`date +%Y-%m-%d`/ >> /var/log/rsync/mailsrv-`date +%Y-%m-%d`.log

Иногда я эти директории автоматически сжимаю для экономии места. И тогда они превращаются в файлы. Файлы удобно чистить примерно так:

# /usr/bin/find /mnt/backup/increment/ -type f -mtime +100 -exec rm -rf {} \;

Просто удаляем всё, что старше 100 дней. Я клонировал один проект и настраивал там бэкапы. Изменения сжимать не стал, оставил их в виде директорий. А команду на очистку оставил такой же, с -type f.

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

На следующий день захожу на сервер с бэкапами и понимаю, что файлов нет. Чистил старые файлы, они все были старше 100 дней. Судя по всему сначала они были сложены все в одну директорию в соответствии с ключами --backup и --backup-dir, а потом команда find их все удалила. При этом сами директории, в том числе вложенные, но уже без файлов остались.

Я сначала не мог понять, в чём тут дело. Вся иерархия папок сохранилась, но файлов нет. Точнее некоторые файлы были, как я уже потом понял, которые моложе 100 дней, но большей части нет. Не мог долго понять, почему так получилось. Начал грешить на сам rsync и подумывал заменять его на restic или borg. Но смысл в том, что rsync в данном случае мне удобнее и привычнее.

В итоге просто чуйка помогла. Ещё раз всё внимательно посмотрел и понял, что команда на чистку не та. Это не rsync сглючил, а я ошибочно удалил файлы уже после его работы. Если используются директории, то чистить надо так:

# /usr/bin/find /mnt/backup/increment/ -maxdepth 1 -type d -mtime +100 -exec rm -rf {} \;

❗️На самом деле уже не первый раз натыкаюсь на то, что ошибка с find приводит к неожиданным проблемам. С ним, да и любым подобным софтом для очистки данных, нужно очень аккуратно обращаться, всё проверяя по 10 раз. Одна ошибка и данные можно безвозвратно потерять.

#rsync

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

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

⇨ Резервное копирование ClickHouse с clickhouse-backup
Пример использования утилиты clickhouse-backup для бэкапа одноименной СУБД. В статье пример конфигурации с загрузкой бэкапов в S3.

⇨ Telegram бот для проверки ссылок в сообщениях
Автор написал бота, который проверяет ссылки через API сервиса VirusTotal. В статье сам бот и инструкция по запуску.

⇨ OpenSnitch – ручной контроль сетевой активности Linux приложений
Подробный обзор программы для контроля за сетевой активностью. Актуально для тех, у кого рабочая станция на Linux. Управление с помощью графического интерфейса.

⇨ Вышло накопительное обновление 15 для Exchange Server 2019! 
⇨ Как определить версию Exchange Server с помощью PowerShell?
Небольшие информационные заметки для тех, кто эксплуатирует Exchange Server.

🔥 Как установить MikroTik RouterOS на VPS сервер
Установка Cloud Hosted Router (CHR) на VPS. Это версия RouterOS для установки на немикротиковское железо. Автор на примере конкретного провайдера показал, как поверх изначальной системы накатить CHR.

⇨ Как настроить базовые правила фаервола в MikroTik RouterOS
Базовая настройка файрвола в MikroTik RouterOS. Сюда же относится и ранее установленный CHR.

⇨ Пишем функцию быстрого доступа к сложным командам для Zsh и Bash
Расширение функциональности алиасов, если их уже не хватает. Создание функции для быстрого выбора и выполнения преднастроенных консольных команд. Интересная реализация. Не видел ранее подобных. Для серверов наверное будет избыточно. Больше актуально для пользователей рабочих машин под Linux.

🔥 Kasm Workspaces — строим свою лабораторию для обучения и тестов
Подробная статья по настройке Kasm Workspaces — платформы для удаленного доступа к рабочим столам, построенная на базе Docker контейнеров.

⇨ Маршрутизация на MikroTik с RouterOS 7
Очень подробный разбор маршрутизации в RouterOS: обычная маршрутизация, policy-based routing, два маршрута по умолчанию и два провайдера.

⇨ Как присоединить компьютер с Windows 11 к домену
В статье разобраны три способа подключения к домену: через графический интерфейс, с помощью PowerShell, через командную строку.

⇨ Настройка логирования вывода скриптов Bash
Принципы и нюансы логирования стандартных потоков stdout и stderr в bash скриптах.

⇨ Обнаружение дисков в Zabbix и просмотр по ним температуры
Обнаружение в Linux дисков sata и nvme и получение их температуры с помощью утилит hddtemp и nvme.

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

▪️https://r4ven.me
▪️https://wiki-it.ru
▪️https://www.gurin.ru
▪️https://sysadminhub.ru
▪️https://devopslife.ru
▪️https://bite-byte.ru
▪️https://sysadminium.ru
▪️https://desoft.ru
▪️https://www.pc360.ru
▪️https://bafista.ru
▪️https://it-experience.ru
▪️https://blogadminday.ru
▪️https://marukhin.ru
▪️https://blog.mons.ws
▪️https://lytkins.ru
▪️https://sysops.host

#статьи

Я уже как-то рассказывал про утилиту sshfs, которая позволяет монтировать удалённую файловую систему через SSH. То есть просто монтируете сетевой диск, используя только SSH соединение. Это не очень быстро, так как подключение выполняется в пространстве пользователя, да и в целом по SSH не очень быстрые соединения. Но для некоторых задач это бывает удобно. Доступ по SSH есть практически всегда.

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

Ставим sshfs:

# apt install sshfs

Генерируем и копируем на удалённую машину ключ:

# ssh-keygen -t ed25519
# ssh-copy-id root@10.20.1.6

Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.

Всё готово, монтируем д иректорию /etc/letsencrypt с сервера 10.20.1.6 к себе в /mnt/letsencrypt:

# sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt

Проверяем:

# df -h | grep 10.20.1.6
root@10.20.1.6:/etc/letsencrypt  20G 1.8G  17G 10% /mnt/letsencrypt

Размонтировать можно вот так:

# fusermount -u /mnt/letsencrypt

Создаём службу systemd:

# systemctl edit --force --full sshfs.service

[Unit]
Description=Mount sshfs
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true

ExecStart=sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencrypt
ExecStop=fusermount -u /mnt/letsencrypt

[Install]
WantedBy=multi-user.target

Сохраняем, запускаем, добавляем в автозагрузку:

# systemctl start sshfs.service
# systemctl enable sshfs.service

Если хотим отмонтировать, то просто останавливаем:

# systemctl stop sshfs.service

Я показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры

User=sftp-user
Group=sftp-user

Можно в systemd указать пользователя, под которым всё это будет монтироваться.

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

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

#ssh #fileserver

Как только поднимается тема контейнеров, неизменно начинается обсуждение производительности. Что туда можно засунуть, что нет и т.д. Особое внимание уделяют СУБД. Когда-то давно я увидел тесты работы форка MySQL - Percona:

⇨ Measuring Percona Server Docker CPU/network overhead

Там запускают СУБД в разных режимах. Приведу сразу результаты:

1️⃣ Железо - 7100 транзакций в секунду. Это максимум. 
2️⃣ БД в контейнере, подключение с хоста через замапленный tcp порт - 2200 транз/c. Самый слабый результат, так как подключение идет через проброс порта в iptables. 
3️⃣ БД в контейнере, который подключен напрямую в сеть хоста через net=host, подключение с хоста. Результат - те же самые 7100 транз/c.
4️⃣ БД в контейнере, подключение из другого контейнера. Контейнеры соединены между собой через docker bridge. Результат - 6300 транз/c.

Судя по этим тестам, сама по себе работа в контейнере никакого статистически значимого штрафа производительности не добавляет. Накладные расходы появляются там, где возникают дополнительные промежуточные звенья в виде NAT или Bridge, что в общем то логично. Запуск через docker run -p 8080:8080, добавляет новую прослойку в виде iptables и его проброса портов через DNAT. Надо ещё понимать, что эти же прослойки и вне контейнера возникнут, если у вас нагрузка, например, распределена между виртуальными машинами.

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

▶️ Насколько тормозит Docker? Тестируем сетевые режимы

Там автор провёл прикладные тесты таких же режимов работы, только для веб сервера Angie с разными статическими страницами (большая и маленькая). Результаты немного другие:

- Запуск на хосте - 100% производительности
- Docker c net=host - 67% и 79% от хоста в зависимости от страницы
- Docker с -p 8080:80 45% и 54%

Картина уже совсем другая. И даже с net=host разница с запуском на хосте значительная. При этом плавает от характера нагрузки. Чем больше rps, тем более заметна разница.

При этом нельзя выделить какую-то универсальную величину, на которую можно ссылаться при вычислении накладных расходов. Они очень сильно разнятся от характера нагрузки. В тестах с СУБД, насколько я понимаю, основная нагрузка была на CPU при выполнении сложных запросов. А в веб сервере отдавались несжатые данные маленькими объёмами, нагрузки на CPU было меньше, а вот системных вызовов в разы больше.

Так что с контейнерами не всё так однозначно, чтобы можно было сказать, что штраф незначительный, можно не учитывать. Где-то может быть значительный. Тот же прокси сервер для веб проектов имеет смысл запускать не в контейнере, а напрямую на хосте. Никаких особых проблем с деплоем и настройкой не будет, но сходу можно получить 20-30% прироста производительности на ровном месте.

И в завершении подытожу, что если с контейнерами хотите получить максимальную производительность, то точно нужно использовать сетевой режим host.

#docker #devops