Синхронизируем настройки Pi-Hole между инстансами.
ㅤ
У меня в сети живет несколько нод с pi-hole, которые раскиданы по разным устройствам (proxmox, raspberry pi и т.п.). И сразу встала необходимость, чтобы все ноды с pi-hole имели одинаковые настройки.

Pi-hole — это сетевой DNS‑фильтр и блокировщик рекламы с открытым исходным кодом. Он работает как свой DNS‑сервер, перехватывает DNS‑запросы от устройств в локальной сети и блокирует домены из списков рекламы, трекеров и вредоносных сайтов, возвращая «пустой» ответ вместо IP‑адреса рекламного ресурса.

Стратегия такая, одна нода будет master, где производятся все основное настройки, затем все эти настройки раскатываются на другие ноды (slave).

Раньше такой кейс разруливали с помощью Orbital Sync, Nebula Sync и т.п. Но одно сдохло, другое работает через хуй-пизда-копыто. Короче нужно рабочее решение.

Пишем свой велосипед

#!/usr/bin/env bash

set -euo pipefail

PRIMARY_PIH_DIR="/etc/pihole"

SECONDARY_USER="root"
SECONDARY_PIH_DIR="/etc/pihole"
SECONDARY_HOSTS=(
  "192.168.10.97"
  "192.168.10.98"
  "192.168.10.99"
)

RSYNC_EXCLUDES=(
  "--exclude=pihole-FTL.db"
  "--exclude=macvendor.db"
  "--exclude=*.log"
)

echo "[pihole-sync] $(date): start"

for host in "${SECONDARY_HOSTS[@]}"; do
  echo "[pihole-sync] ---- host ${host} ----"

  rsync -az \
    "${RSYNC_EXCLUDES[@]}" \
    "${PRIMARY_PIH_DIR}/" \
    "${SECONDARY_USER}@${host}:${SECONDARY_PIH_DIR}/"

  echo "[pihole-sync] ${host}: restart dns"
  ssh "${SECONDARY_USER}@${host}" "pihole restartdns >/dev/null 2>&1" || \
    echo "[pihole-sync] ${host}: FAILED to restart dns"

done

echo "[pihole-sync] $(date): done"

В SECONDARY_HOSTS забиваем айпишники slave инстансов, этакий массив. На этом настройка скрипта закончена. Весь лишний мусор вроде логов и статистики синхронизироваться не будет.

Сохраняем, чмодим, кидаем в крон (а лучше в systemd с таймерами):

Про таймеры подробно писал тут и тут.

crontab -e
*/5 * * * * /usr/local/sbin/pihole-sync.sh >> /var/log/pihole-sync.log 2>&1

Не забываем прокинуть ssh ключи с master на slave, чтобы скрипт не уперся рогом в логин и пароль.

Вроде мелочь, а полезная, да еще и на bash. Хороших тебе предстоящих выходных и береги себя!

🛠 #bash #linux #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Volume VS Bind в Docker

Сегодня рассмотрим, как и в каких случаях правильно использовать bind или volume при запуске docker контейнеров.

Пересмотрев кучу docker compose файлов, можно сделать вывод — большинство даж не понимают что они делают. Что печально, прожжённые девопс-инженеры продолжают харкодить и творить дичь. Видимо придерживаются методологии — у меня работает, остальное похуй.

Вообще есть правило:

- Если нужно редактировать файлы руками с хоста, используешь Bind Mount.

- Если данные нужны только приложению (БД, логи, кэш) используешь Volumes.
ㅤ
Шпаргалка, что есть что:

# Это docker volume, данные хранятся в
# /var/lib/docker/volumes/

volumes:
  - nginx_data:/etc/data

# Это bind mount, данные хранятся рядом
# с файлом docker-compose.yml

volumes:
  - ./data:/etc/data

Ну и никто не запрещает это совмещать, но старайся разделять. Тем более при работе с volumes, в docker есть удобные команды, ну и через midnight commander можешь физически потыкать файлы, при условии если есть рутовый доступ к файловой системе.

Самое главное не делай так:

Про этот случай я и писал в начале поста, вроде человек 20 лет отрубил в айтишке, а пишет хуйню.

volumes:
  - /home/anus/conf.d:/etc/nginx/cond.f
  - /home/anus/data/logs:/var/log/nginx

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

Я лично предпочитаю volumes и порой даже конфиги в нем храню, потому что этот volume можно легко примаунтить к любому другому контейнеру и получить доступ к этим файлам.
Банально возьмем связку nginx + php-fpm, используем один общий volume и php скрипты корректно выполняются.

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

А еще есть полезный флаг: «RO», используется в ситуациях, когда тебе нужно что-бы приложение в контейнере не перезаписывало данные в примонтированном каталоге. Удобно для отладки или для каких-то ограничений.

Пример:

services:
  web:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./logs:/var/log/nginx

При всём желании, конфиг nginx.conf нельзя модифицировать из приложения в контейнере. Это можно сделать только на хостовой машине. Второй же bind mount по умолчанию - «RW».

Ну и пожелания:

- Используйте именованные тома, вместо анонимных томов (которые выглядят как длинный хеш 4f32a...) всегда давайте томам осмысленные имена: db_data, app_uploads

- Придерживайся принципа - «Один контейнер — один вольюм». Старайтесь не монтировать один и тот же вольюм в 10 разных контейнеров на запись. Если нужно делиться данными, один контейнер должен быть «владельцем» (RW), а остальные — «потребителями» (RO).

- Бэкап: Правило «3-2-1». Volume — это не бэкап, это просто место хранения. Если ты случайно ёбнешь вольюм командой prune, данные исчезнут.

Используйте временный контейнер для создания архива:

docker run --rm -v db_data:/data -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data

- Docker со временем накапливает «висячие» (dangling) вольюмы — это те, что остались от удаленных контейнеров. Периодически запускай docker volume prune. Оно удалит только те тома, которые не подключены ни к одному контейнеру (включая остановленные).

- Разницы в скорости между Bind и Volume почти нет, оба работают напрямую через ядро. Но это зависит от операционной системы, если у тебя винда и 100500 абстракций, то будут тормоза.

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

🛠 #docker #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Почтовый сервер у себя дома

Вчера решал интересную задачку. У меня в интернетах крутится собственный почтовый сервер на домене, сервер ежемесячно поджирает стабильно около 2к рублей. Хотя за месяц от силы я получаю 10-20 писем.
ㅤ
Избыточно в плане инфраструктуры и затрат? Конечно! Разумно перетащить его к себе на домашний proxmox и избавиться от одной статьи расходов.

Во время проектирования миграции, было много вопросов и самый главный — у меня нет белого IP в домашнем сегменте, как быть? DynDNS я ебал, да и с микротиком возиться не хочется.

Всё оказалось достаточно просто. Создаем условно за 100 рублей сервер в интернетах с белым IP, втыкаем на него angie с модулем stream, объединяем этот сервер с домашней сетью с помощью netbird или другой технологией. И просто проксипасим все запросы в домашний сегмент.

Про MX, SPF, DKIM писать не буду, все это настраивается отдельно, не сложно.

Звучит логично. Но на практике пришлось поебстись и почитать спецификации всей этой кухни.

Конфиг для angie получился такой, он работает при условии наличия модуля stream.

nginx
upstream imap_backend {
server 100.106.7.8:993;
}

upstream smtp_backend {
server 100.106.7.8:587;
}

upstream sieve_backend {
server 100.106.7.8:4190;
}

server {
listen 993;
proxy_pass imap_backend;
proxy_timeout 1h;
proxy_connect_timeout 30s;
}

server {
listen 587;
proxy_pass smtp_backend;
proxy_timeout 1h;
proxy_connect_timeout 30s;
}

server {
listen 4190;
proxy_pass sieve_backend;
proxy_timeout 1h;
proxy_connect_timeout 30s;
}

дополнительные порты сам добавь, сюда всё не влезло

Суть тут такая, все запросы на определенные порты, перенаправляются в netbird сеть, а 100.106.7.8 это IP адрес как раз моего LXC контейнера с почтовым сервером в домашнем proxmox.

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

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

Я использую nextcloud mail, и там есть поддержка sieve из коробки. Потыкал еще roundcube для морды, но чёт не зашла, топорная какая-то штука, хотя рабочая.

Да, в роле почтового сервера у меня установлен docker-mailserver. Штука классная, установил, пару тычек выписал в конфиг и оно работает. Морды в ней нет, чисто логическая часть, что-то вроде бекенда.

Еще нюанс в конфиге docker-mailserver я прописал SSL сертификаты, эти сертификаты я взял в angie после того как он мне их выдал. В этом плане нужно еще придумать, как организовать передачу этих сертов к себе в proxmox.

environment:
  - SSL_TYPE=manual
  - SSL_CERT_PATH=/tmp/dms/custom-certs/certificate.pem
  - SSL_KEY_PATH=/tmp/dms/custom-certs/private.key
    
volumes:
  - ./ssl:/tmp/dms/custom-certs/:ro

Банально можно через scp копировать, но в идеале поднять vault hashicorp и хранить серты там и по необходимости дергать от туда в любое место.

Ну и важное уточнение, отправлять почту во вне, тебе в нынешних реалиях никто не даст (25 порт на отправку везде заблочен), поэтому используем какой-нибудь relay для этого. Благо есть полно таких, кто дает отправить 10-15к писем в месяц легально и бесплатно. Я пользуюсь этим сервисом несколько лет.

Что еще. Возможно будут проблемы с SPF, но если оно тебе в хуй не уперлось, то отключаем в конфиге docker-mailserver - ENABLE_POLICYD_SPF=0.

Ну и SIEVE включается там же через ENABLE_MANAGESIEVE=1.

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

На этом всё, изучай. Концепт я тебе показал, нюансы рассказал, так что дерзай, всё решаемо.

🛠 #selfhosting #proxmox #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Многих эта тема обошла стороной, дело привычки берет своё.
ㅤ
Я про docker-compose.yaml. Так вот, в современных дистрибутивах не обязательно называть так файл, достаточно обозвать его compose.yaml и всё будет работать. Но при условии если у тебя не допотопная ОС со старой версией docker’a.

Современный docker давно перешел на compose.yaml.

docker-compose — это отдельный python-инструмент
docker compose — встроенный плагин docker cli

Теперь docker в приоритете ищет файл compose.yaml и только потом старый docker-compose.yaml. И так и так все будет работать. Оно пока на это не ругается, но рано или поздно к этому придут.

Наверное ты уже замечал, что если в yaml указать version: 3.9 оно скажет — ты ебанутый? Я пожалуй это проигнорирую.

Это нужно было указывать раньше, чтобы docker понимал какие поля разрешены и как вообще интерпретировать файл. Теперь это легаси и docker автоматически определяет версию, чтобы избавиться от зоопарка версий: v2, v2, v3.7, v3.9. Получаем один формат → одна логика → меньше гемора.

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

Но опять же если у тебя древняя ОС, выбора особо не будет, придется прописывать версии и поддерживать это наследие.

Пример с version или подстава. Создавалась это не для docker compose, а для docker swarm. В version:3 Docker Compose просто молча игнорировал: mem_limit, cpu_shares, cpus, restart_policy, depends_on. Не было ни ошибок, ни предупреждений. Просто ничего не происходило. Контейнер запускался, но не как ожидалось.

version: "3"
mem_limit: 512m

Хм… 512 говоришь, хуй те! Эй OOM давай к нам, у нас тут пациент!

version:3 — Swarm-спека

Ну и про yaml и yml пару строк. Можно писать так и так, оба варианта равноправны. Но всё же рекомендуется yaml, потому что это полное официальное расширение, так пишется в спецификациях и документациях. Плюсом это единый стиль Kubernetes, GitHub Actions, Helm и т.п.

На сколько помню yml пошел со старых систем, когда было ограничение в 3 символа, опять же наследие прошлого.

Возможно ошибаюсь, поправьте в комментах.

🛠 #docker #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Получаем SSL сертификат на IP адрес.
ㅤ
Вот и случилось, теперь ты можешь сгенерить валидный SSL сертификат для айпишника. Не самоподписанный, а прям настоящий от Lets Encrypt.

Не путать с mkcert, это совсем другое.

Единственный момент, такой серт будет валиден несколько дней (160 часов), поэтому придется почаще его выпускать, сейчас ставят 5 дней для обновления, как золотую середину. НЕ рекомендуется ставить 6, иначе можешь словить граблю. Вообще acme сам всё в кроне должен прописать, но это не точно.

Пока это может делать только acme, все остальные (certbot, angie) совсем скоро к этому придут.

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

Cannot issue for \"192.168.10.91\": IP address is in a reserved address block: [RFC1918]: Private-Use"

Ну оно и логично, спецификации никто не отменял.

Я буду генерить для 178.72.129.181 на котором у меня установлен nginx. Виртуалка прерываемая, так что денег практически не жрет, для тестов в настоящем облаке — милое дело.

Приступим:

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

curl https://get.acme.sh | sh -s email=shubkin@bashdayz.ru

Конфигурируем default в nginx:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location ~ ^/.well-known/(acme-challenge|pki-validation)/ {
        add_header Content-Type text/plain;
        root /var/www/letsencrypt;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Создаем структуру папок и релоадим:

mkdir -p /var/www/letsencrypt
mkdir -p /etc/nginx/ssl
nginx -t
nginx -s reload

Выписываем пиздюлей сертификат:

acme.sh --issue --server letsencrypt -d 178.72.129.181 -w /var/www/letsencrypt --certificate-profile shortlived --days 3

Отлично, сертификат получили, устанавливаем:

acme.sh --install-cert -d 178.72.129.181 --key-file /etc/nginx/ssl/ip.key --fullchain-file /etc/nginx/ssl/ip.crt --ca-file /etc/nginx/ssl/ip.ca.crt --reloadcmd "systemctl restart nginx"

Добавляем дополнительный блок в default в nginx:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    return 403;
    ssl_certificate /etc/nginx/ssl/ip.crt;
    ssl_certificate_key /etc/nginx/ssl/ip.key;
}

Перезапускаем:

nginx -t
nginx -s reload

И радуемся, теперь у тебя есть валидный SSL на голом айпишнике:

Общее имя (ЦС)  YE1
Организация  Let's Encrypt
Дата выдачи: 29 января 2026 г.
Срок действия: 5 февраля 2026 г.

Дело в шляпе, что сказать? Пиздато! Порой ОЧЕНЬ не хочется привязывать домен, чтобы обзавестись SSL сертификатом, теперь выход есть. Глядишь найдется хак, чтобы сгенерить подобное для 192.168.0.1, но наверное это из оперы моих влажных фантазий.

🛠 #linux #devops #ssl
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Контекстная конфигурация в git

При работе с git репозиториями, частенько попадаешь в просак с таким:

git config --global user.name
git config --global user.email

Один раз забил свои явки-пароли и затем git при любом коммите или пуше будет подставлять эти данные. То есть в историю коммитов будет забиваться user.name и user.email. Это логично и понятно.
ㅤ
Но если у тебя смешаны личные и рабочие репозитории, начинается цирк с конями. Я тысячу раз комитил в рабочую репу под личным user.name и user.email и получал за это по рукам. Получал конечно сам от себя.

Потому что смешивать личное и рабочее — фуфу!

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

Расчехляем хоумлабу!

У нас будет 2 папки:

mkdir -p ~/projects/personal
mkdir -p ~/projects/work

Настраиваем основной конфиг:

vim ~/.gitconfig

[user]
    name = Roman Shubin
    email = shuba@bashdayz.ru

[includeIf "gitdir:~/projects/work/"]
    path = ~/.gitconfig_work

Нюанс: / в конце work обязателен. Git интерпретирует gitdir: как префикс пути к каталогу .git.

Создаем рабочий конфиг ~/.gitconfig_work

[user]  
  name = Linux Factory
  email = exe@linuxfactory.ru

На этом танцы с бубном закончились, проверяем:

mkdir -p ~/projects/personal/app  
cd ~/projects/personal/app  
git init

git config user.email
git config --show-origin user.email

Ага, видим что для личных проектов будет применяться shuba@bashdayz.ru и берется он из ~/.gitconfig. Последние 2 команды, как раз выводят эту информацию в терминал. Хорошо, теперь:

mkdir -p ~/projects/work/app  
cd ~/projects/work/app  
git init

git config user.email
git config --show-origin user.email

Да твоюж мать! Видим Linux Factory и exe@linuxfactory.ru. Что и требовалось доказать, данные берутся из файла ~/.gitconfig_work.

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

Git скрывает очень много интересного и не всегда это очевидно. Такие дела, изучай!

🛠 #devops #linuxfactory #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Как кубер и докер дебажить???

Ладно, выдеру кусок из будущего сезона LF, s4e18 пусть побудет публичным, ради тебя ничего не жалко.
ㅤ
…

Чуть раньше я уже писал подобный пост для докера «основные методы отладки», но там освещены не все моменты.

Зачастую используются «тулбоксы», это такие специальные docker контейнеры, которые содержат в себе все самые необходимые утилиты для этого самого дебага. Такие «тулбоксы» можно делать самостоятельно, а можно воспользоваться готовыми.

Один из самых популярных, это netshoot, в него включено свыше 50ти консольных утилит на все случаи жизни. Основной упор сделан на диагностику сетевой хуйни.

Например:

kubectl run netshoot --rm -it --image=nicolaka/netshoot

Теперь можно выполнить:

dig service.bashdays.svc.cluster.local  
curl http://service:8080

Или зайти в network namespace pod:

kubectl debug pod/myapp -it --image=nicolaka/netshoot

Короче если какой-то сервис не работает, запускается netshoot делается DNS проверка dig service, проверка TCP nc service 5432, смотрим пакеты tcpdump -i any port 5432 и т.п.

Довольная удобная штука, ничего выдумывать не нужно. Аналогично создаются другие «тулбоксы» со своим содержимым и утилитами.

У каждого уважающего себя девопс-инженера, должен быть такой image под рукой, рано или поздно он обязательно пригодится и сослужит службу.

Самое важное здесь, разместить этот образ на РФ серверах, чтобы рядышком был и никакие блокировки бы его не касались. Да и тот же `netshoot` желательно к себе утащить в норку.

Чем еще подебажить:

- k8s-toolbox
- Busybox
- dnsutils
- Network Multitool

А в новых версиях куба активно используют Ephemeral containers, как раз тот самый kubectl debug. Можно внедрить debug container прямо в pod.

Кстати «тулбоксы» можно использовать не только в кубере, они отлично ложатся на обычный докер, опять-же сеть потыкать, покурлить и помяукать. Так что если у тебя нет куба, похуй, пригодится и для обычного докера.

Ну а теперь давай создадим искусственную проблему и попытаемся её диагностировать с помощью этих самых «тулбоксов».
….

На этом всё, изучай!

🛠 #devops #debug #docker #k8s
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Здрасти, кого не видел. Потыкал я короче хвалёный Warp Terminal в рамках автоматизации с гитом, кодом и инфраструктурой. Сюда не влезло, да и скудно тут с форматированием.

Поэтому камон сюда читать → https://two.su/zvubi

🛠 #devops #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Привет. А у тебя спина белая 🥳

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

Рекомендую ознакомиться, столько интересного и неочевидного раскопал. Возможно это подтолкнет тебя к переезду с docker в podman.

Healthcheck инструментами Podman → https://two.su/3kcvf

🛠 #devops #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog