Сегодня будем хакать Proxmox и создавать работоспособный кластер из 2х нод.
ㅤ
Ты скажешь - фии… Легкотня! Да, добавить ноду в кластер легко, но если у тебя всего 2 ноды в кластере, ни о каком кворуме речь не идет. Кворум предполагает наличие 3х нод. Либо Q-Device сервера.
Если выключить одну из нод, то например при попытке сделать бекапы ты получишь ошибку — твой кластер пошел по пизде, сначала пофикси эту проблему и лишь потом я сделаю бекапы.
Да, если кластер развален, то файловая система переходит в режим R/O. И хуй ты че с этим сделаешь.
Прям вызов! И че делать? Очевидно вернуть ноду в кластер и произвести некие манипуляции пока кластер не развален.
Мыж с тобой не пальцем деланные, давайнаебем хакнем эту поеботу. И подтасуем результаты кворума в нашу пользу.
Сразу скажу — так делать нельзя!
Включаем ноду, чтобы кластер восстановился. Заходим по ssh на proxmox ноду, которая включена 24/7 (у меня она называется
В файле видим описания кластера:
Видим
И ниже в блоке
Чтобы проверить, запускаем:
И видим что нода
Поздравляю, теперь ты можешь прокачать свою домашнюю лабораторию и выключать ненужные узлы кластера как тебе вздумается.
Развлекайся!
🛠 #selfhosting #proxmox #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
ㅤ
Ты скажешь - фии… Легкотня! Да, добавить ноду в кластер легко, но если у тебя всего 2 ноды в кластере, ни о каком кворуме речь не идет. Кворум предполагает наличие 3х нод. Либо Q-Device сервера.
Если выключить одну из нод, то например при попытке сделать бекапы ты получишь ошибку — твой кластер пошел по пизде, сначала пофикси эту проблему и лишь потом я сделаю бекапы.
Да, если кластер развален, то файловая система переходит в режим R/O. И хуй ты че с этим сделаешь.
Если кластер потерял кворум, /etc/pve автоматически монтируется только для чтения, и никакие chmod/chown/chattr не помогут, т.к. это не обычный ext4/xfs.
Прям вызов! И че делать? Очевидно вернуть ноду в кластер и произвести некие манипуляции пока кластер не развален.
Мыж с тобой не пальцем деланные, давай
Сразу скажу — так делать нельзя!
Включаем ноду, чтобы кластер восстановился. Заходим по ssh на proxmox ноду, которая включена 24/7 (у меня она называется
pvx). vim /etc/pve/corosync.conf
Да, предварительно не забудь забекапить все файлы, в которые вносишь изменения. Вообще никогда не забывай этого делать, особенно на проде. В будущем это спасет тебе жизнь и сохранит кучу нервных клеток.
В файле видим описания кластера:
nodelist {
node {
name: pvx
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.10.60
}
node {
name: wenom
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.10.55
}
}Видим
quorum_votes. Это и есть ключевая опция для хака. Для pvx ноды я меняю 1 на 2. То есть искусственно присваиваю два голоса без кворума.И ниже в блоке
totem меняем параметр config_version: c 2 на 3. Все! Ничего перезагружать не нужно.Чтобы проверить, запускаем:
pvecm status
Membership information
----------------------
Nodeid Votes Name
0x00000001 2 192.168.10.60 (local)
0x00000002 1 192.168.10.55
И видим что нода
pvx получила 2 голоса. Теперь если выключить вторую ноду. Файловая система не перейдет в режим R/O и всё будет работать, как и раньше с одной нодой.Поздравляю, теперь ты можешь прокачать свою домашнюю лабораторию и выключать ненужные узлы кластера как тебе вздумается.
Развлекайся!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
11 58
Синхронизируем настройки Pi-Hole между инстансами.
ㅤ
У меня в сети живет несколько нод с pi-hole, которые раскиданы по разным устройствам (proxmox, raspberry pi и т.п.). И сразу встала необходимость, чтобы все ноды с pi-hole имели одинаковые настройки.
Стратегия такая, одна нода будет master, где производятся все основное настройки, затем все эти настройки раскатываются на другие ноды (slave).
Раньше такой кейс разруливали с помощью Orbital Sync, Nebula Sync и т.п. Но одно сдохло, другое работает через хуй-пизда-копыто. Короче нужно рабочее решение.
Пишем свой велосипед
В
Сохраняем, чмодим, кидаем в крон (а лучше в systemd с таймерами):
Не забываем прокинуть ssh ключи с master на slave, чтобы скрипт не уперся рогом в логин и пароль.
Вроде мелочь, а полезная, да еще и на bash. Хороших тебе предстоящих выходных и береги себя!
🛠 #bash #linux #devops #selfhosting
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
ㅤ
У меня в сети живет несколько нод с 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. Хороших тебе предстоящих выходных и береги себя!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
5 32
Stop Using Pi-Hole – Technitium DNS Is Better
В комментах к посту про «ПИ-ДЫРКУ» ребята посоветовали присмотреться к Technitium DNS. Ну вот я и присмотрелся, прислушался к авторитетному мнению.
ㅤ
Ключевым фактором стало — кластеризация и синхронизация из коробки, без велосипедов на Bash скриптах. Да и по интерфейсу нет ебанутых новогодних ёлок и гирлянд.
Поднял я это у себя на 2х нодах в докерах, одну на малине, другую в proxmox, ну и на роутере прописал чтобы по DHCP раздавались DNSки в локальную сеть.
Поднимается элементарно:
Если нужны енвы или порты, расскоментируй строчки по потребностям, мне хватило минимальных вмешательств.
Затем заходим в морду:
Зоны добавляются в разделе Zones, после добавления зоны, создаешь «A» запись например для домена
Создаём кластер
Чтобы создать кластер, идем во вкладку Administration → Cluster. Создаем кластер, а на второй ноде в этом же разделе жмем кнопку Join Cluster. Заполняем очевидные поля, явки, пароли и радуемся синхронизации.
Теперь при добавлении новой зоны на первой ноде, эта зона улетит на вторую ноду. Главное не забыть выбрать Catalog Zone при добавлении зоны.
Никаких танцев с бубном. Ааа.. Есть танцы, возможно ты столкнешься с ошибкой, что 53 порт уже занят. Это нормально, фиксим:
Если у тебя какие-то другие резолверы стоят, то:
Собственно на этом всё. Базу я тебе показал, дальше сам. А всем кто привел меня к этому решению - спасибо и премного благодарен! Скрасил воскресный вечер не за кружкой бухла, а за полезным занятием.
Изучай!
🛠 #selfhosting #proxmox #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
В комментах к посту про «ПИ-ДЫРКУ» ребята посоветовали присмотреться к Technitium DNS. Ну вот я и присмотрелся, прислушался к авторитетному мнению.
ㅤ
Ключевым фактором стало — кластеризация и синхронизация из коробки, без велосипедов на Bash скриптах. Да и по интерфейсу нет ебанутых новогодних ёлок и гирлянд.
Поднял я это у себя на 2х нодах в докерах, одну на малине, другую в proxmox, ну и на роутере прописал чтобы по DHCP раздавались DNSки в локальную сеть.
Поднимается элементарно:
services:
dns-server:
container_name: technitium-dns1
hostname: technitium-dns1
image: technitium/dns-server:latest
ports:
- 5380:5380/tcp # Web console (HTTP)
- 53:53/udp # DNS service
- 53:53/tcp # DNS service
- "53443:53443/tcp" # Web console (HTTPS)
# Optional ports - uncomment as needed:
# - "853:853/udp" # DNS-over-QUIC
# - "853:853/tcp" # DNS-over-TLS
# - "443:443/udp" # DNS-over-HTTPS (HTTP/3)
# - "443:443/tcp" # DNS-over-HTTPS (HTTP/1.1, HTTP/2)
# - "67:67/udp" # DHCP service
# environment:
# - DNS_SERVER_DOMAIN=dns.local
# - DNS_SERVER_FORWARDERS=10.1.149.10
# Production options:
# - DNS_SERVER_ADMIN_PASSWORD=your_secure_password
# - DNS_SERVER_PREFER_IPV6=false
# - DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
volumes:
- technitium-dns-data:/etc/dns
restart: unless-stopped
sysctls:
- net.ipv4.ip_local_port_range=1024 65000
volumes:
technitium-dns-data:
driver: local
networks: {}
Если нужны енвы или порты, расскоментируй строчки по потребностям, мне хватило минимальных вмешательств.
Затем заходим в морду:
http://<IP>:5380 и конфигурируем по необходимости. Зоны добавляются в разделе Zones, после добавления зоны, создаешь «A» запись например для домена
nextcloud.local и прописываешь IP своего nginx proxy manager (далее NPM), ну а дальше в NPM разруливаешь на нужные IP адреса и порты.Создаём кластер
Чтобы создать кластер, идем во вкладку Administration → Cluster. Создаем кластер, а на второй ноде в этом же разделе жмем кнопку Join Cluster. Заполняем очевидные поля, явки, пароли и радуемся синхронизации.
Теперь при добавлении новой зоны на первой ноде, эта зона улетит на вторую ноду. Главное не забыть выбрать Catalog Zone при добавлении зоны.
Никаких танцев с бубном. Ааа.. Есть танцы, возможно ты столкнешься с ошибкой, что 53 порт уже занят. Это нормально, фиксим:
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Если у тебя какие-то другие резолверы стоят, то:
sudo systemctl stop dnsmasq
sudo systemctl disable dnsmasq
sudo systemctl stop bind9
sudo systemctl disable bind9
Собственно на этом всё. Базу я тебе показал, дальше сам. А всем кто привел меня к этому решению - спасибо и премного благодарен! Скрасил воскресный вечер не за кружкой бухла, а за полезным занятием.
Изучай!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5 53
Volume VS Bind в Docker
Сегодня рассмотрим, как и в каких случаях правильно использовать bind или volume при запуске docker контейнеров.
Пересмотрев кучу docker compose файлов, можно сделать вывод — большинство даж не понимают что они делают. Что печально, прожжённые девопс-инженеры продолжают харкодить и творить дичь. Видимо придерживаются методологии — у меня работает, остальное похуй.
Вообще есть правило:
- Если нужно редактировать файлы руками с хоста, используешь Bind Mount.
- Если данные нужны только приложению (БД, логи, кэш) используешь Volumes.
ㅤ
Шпаргалка, что есть что:
Ну и никто не запрещает это совмещать, но старайся разделять. Тем более при работе с volumes, в docker есть удобные команды, ну и через midnight commander можешь физически потыкать файлы, при условии если есть рутовый доступ к файловой системе.
Самое главное не делай так:
Про этот случай я и писал в начале поста, вроде человек 20 лет отрубил в айтишке, а пишет хуйню.
Тут идет жесткая привязка к путям и после запуска наступишь на грабли, либо получишь по ебалу от бедолаги который это запустит. Короче так не делай!
Bind mount удобен при разработке и отладки. Ты монтируешь папку с исходным кодом проекта. Правишь код в IDE на хосте и изменения мгновенно подхватываются приложением внутри контейнера.
А еще есть полезный флаг: «RO», используется в ситуациях, когда тебе нужно что-бы приложение в контейнере не перезаписывало данные в примонтированном каталоге. Удобно для отладки или для каких-то ограничений.
Пример:
При всём желании, конфиг
Ну и пожелания:
- Используйте именованные тома, вместо анонимных томов (которые выглядят как длинный хеш
- Придерживайся принципа - «Один контейнер — один вольюм». Старайтесь не монтировать один и тот же вольюм в 10 разных контейнеров на запись. Если нужно делиться данными, один контейнер должен быть «владельцем» (RW), а остальные — «потребителями» (RO).
- Бэкап: Правило «3-2-1». Volume — это не бэкап, это просто место хранения. Если ты случайно ёбнешь вольюм командой
Используйте временный контейнер для создания архива:
- Docker со временем накапливает «висячие» (dangling) вольюмы — это те, что остались от удаленных контейнеров. Периодически запускай
- Разницы в скорости между Bind и Volume почти нет, оба работают напрямую через ядро. Но это зависит от операционной системы, если у тебя винда и 100500 абстракций, то будут тормоза.
Вот такие пироги, если есть чё добавить, жду тебя в комментариях.
🛠 #docker #linux #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Сегодня рассмотрим, как и в каких случаях правильно использовать 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 абстракций, то будут тормоза.
Вот такие пироги, если есть чё добавить, жду тебя в комментариях.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
6 65
Почтовый сервер у себя дома
Вчера решал интересную задачку. У меня в интернетах крутится собственный почтовый сервер на домене, сервер ежемесячно поджирает стабильно около 2к рублей. Хотя за месяц от силы я получаю 10-20 писем.
ㅤ
Избыточно в плане инфраструктуры и затрат? Конечно! Разумно перетащить его к себе на домашний proxmox и избавиться от одной статьи расходов.
Во время проектирования миграции, было много вопросов и самый главный — у меня нет белого IP в домашнем сегменте, как быть? DynDNS я ебал, да и с микротиком возиться не хочется.
Всё оказалось достаточно просто. Создаем условно за 100 рублей сервер в интернетах с белым IP, втыкаем на него angie с модулем stream, объединяем этот сервер с домашней сетью с помощью netbird или другой технологией. И просто проксипасим все запросы в домашний сегмент.
Звучит логично. Но на практике пришлось поебстись и почитать спецификации всей этой кухни.
Конфиг для angie получился такой, он работает при условии наличия модуля stream.
Суть тут такая, все запросы на определенные порты, перенаправляются в netbird сеть, а
Получилась банальная прокся. Великолепно то, что angie автоматом получает SSL сертификаты и в почтовых программах с этим заморачиваться не нужно, просто указываем домен, порт и всё работает как часы.
Да, в роле почтового сервера у меня установлен docker-mailserver. Штука классная, установил, пару тычек выписал в конфиг и оно работает. Морды в ней нет, чисто логическая часть, что-то вроде бекенда.
Еще нюанс в конфиге docker-mailserver я прописал SSL сертификаты, эти сертификаты я взял в angie после того как он мне их выдал. В этом плане нужно еще придумать, как организовать передачу этих сертов к себе в proxmox.
Ну и важное уточнение, отправлять почту во вне, тебе в нынешних реалиях никто не даст (25 порт на отправку везде заблочен), поэтому используем какой-нибудь relay для этого. Благо есть полно таких, кто дает отправить 10-15к писем в месяц легально и бесплатно. Я пользуюсь этим сервисом несколько лет.
Что еще. Возможно будут проблемы с SPF, но если оно тебе в хуй не уперлось, то отключаем в конфиге docker-mailserver -
Ну и SIEVE включается там же через
Плюсом можешь воткнуть mail archiver и вообще горя не знать. Теперь все твоиписьки письма под контролем и ты сам себе хозяин этой суеты. Ну и дополнительная экономия на избыточной инфраструктуре.
На этом всё, изучай. Концепт я тебе показал, нюансы рассказал, так что дерзай, всё решаемо.
🛠 #selfhosting #proxmox #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 и вообще горя не знать. Теперь все твои
На этом всё, изучай. Концепт я тебе показал, нюансы рассказал, так что дерзай, всё решаемо.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
3 55
Многих эта тема обошла стороной, дело привычки берет своё.
ㅤ
Я про
Современный docker давно перешел на
Теперь docker в приоритете ищет файл
Наверное ты уже замечал, что если в
Это нужно было указывать раньше, чтобы docker понимал какие поля разрешены и как вообще интерпретировать файл. Теперь это легаси и docker автоматически определяет версию, чтобы избавиться от зоопарка версий: v2, v2, v3.7, v3.9. Получаем один формат → одна логика → меньше гемора.
Но опять же если у тебя древняя ОС, выбора особо не будет, придется прописывать версии и поддерживать это наследие.
Пример с version или подстава. Создавалась это не для docker compose, а для docker swarm. В
Хм… 512 говоришь, хуй те! Эй OOM давай к нам, у нас тут пациент!
Ну и про
На сколько помню
Возможно ошибаюсь, поправьте в комментах.
🛠 #docker #linux #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 символа, опять же наследие прошлого. Возможно ошибаюсь, поправьте в комментах.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
5 61
Получаем SSL сертификат на IP адрес.
ㅤ
Вот и случилось, теперь ты можешь сгенерить валидный SSL сертификат для айпишника. Не самоподписанный, а прям настоящий от Lets Encrypt.
Единственный момент, такой серт будет валиден несколько дней (160 часов), поэтому придется почаще его выпускать, сейчас ставят 5 дней для обновления, как золотую середину. НЕ рекомендуется ставить 6, иначе можешь словить граблю. Вообще acme сам всё в кроне должен прописать, но это не точно.
Пока это может делать только acme, все остальные (certbot, angie) совсем скоро к этому придут.
Да, для домаших айпишников увы, такая чача не проканает, при попытке получить такой серт, получаем ошибку:
Ну оно и логично, спецификации никто не отменял.
Я буду генерить для
Приступим:
Не забудь подставить своё мыло, а то меня спамом завалит и я буду материться на кота.
Конфигурируем
Создаем структуру папок и релоадим:
Выписываемпиздюлей сертификат:
Отлично, сертификат получили, устанавливаем:
Добавляем дополнительный блок в
Перезапускаем:
И радуемся, теперь у тебя есть валидный SSL на голом айпишнике:
Дело в шляпе, что сказать? Пиздато! Порой ОЧЕНЬ не хочется привязывать домен, чтобы обзавестись SSL сертификатом, теперь выход есть. Глядишь найдется хак, чтобы сгенерить подобное для 192.168.0.1, но наверное это из оперы моих влажных фантазий.
🛠 #linux #devops #ssl
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
ㅤ
Вот и случилось, теперь ты можешь сгенерить валидный 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, но наверное это из оперы моих влажных фантазий.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
12 47
Контекстная конфигурация в git
При работе с git репозиториями, частенько попадаешь в просак с таким:
Один раз забил свои явки-пароли и затем git при любом коммите или пуше будет подставлять эти данные. То есть в историю коммитов будет забиваться
ㅤ
Но если у тебя смешаны личные и рабочие репозитории, начинается цирк с конями. Я тысячу раз комитил в рабочую репу под личным
Из этой ситуации можно выйти по-разному, кто-то изобретает безумные Bash скрипты или пишет хуки, кто-то постоянно правит конфиги перед пушем. Короче костыль на костыле. Но есть решение лучше и нативнее.
Расчехляем хоумлабу!
У нас будет 2 папки:
Настраиваем основной конфиг:
Нюанс:
Создаем рабочий конфиг
На этом танцы с бубном закончились, проверяем:
Ага, видим что для личных проектов будет применяться
Да твоюж мать! Видим
Всё, мы успешно разделили контекст между личными и рабочими проектами. Таких инклудов ты можешь насоздавать сколько угодно. Самое главное это работает без костылей и каких-то лишних обвесов вокруг git.
Git скрывает очень много интересного и не всегда это очевидно. Такие дела, изучай!
🛠 #devops #linuxfactory #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
При работе с 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 скрывает очень много интересного и не всегда это очевидно. Такие дела, изучай!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
1 97
Как кубер и докер дебажить???
Ладно, выдеру кусок из будущего сезона LF, s4e18 пусть побудет публичным, ради тебя ничего не жалко.
ㅤ
…
Зачастую используются «тулбоксы», это такие специальные docker контейнеры, которые содержат в себе все самые необходимые утилиты для этого самого дебага. Такие «тулбоксы» можно делать самостоятельно, а можно воспользоваться готовыми.
Один из самых популярных, это netshoot, в него включено свыше 50ти консольных утилит на все случаи жизни. Основной упор сделан на диагностику сетевой хуйни.
Например:
Теперь можно выполнить:
Или зайти в network namespace pod:
Короче если какой-то сервис не работает, запускается
Довольная удобная штука, ничего выдумывать не нужно. Аналогично создаются другие «тулбоксы» со своим содержимым и утилитами.
У каждого уважающего себя девопс-инженера, должен быть такой image под рукой, рано или поздно он обязательно пригодится и сослужит службу.
Чем еще подебажить:
- k8s-toolbox
- Busybox
- dnsutils
- Network Multitool
А в новых версиях куба активно используют Ephemeral containers, как раз тот самый
Кстати «тулбоксы» можно использовать не только в кубере, они отлично ложатся на обычный докер, опять-же сеть потыкать, покурлить и помяукать. Так что если у тебя нет куба, похуй, пригодится и для обычного докера.
Ну а теперь давай создадим искусственную проблему и попытаемся её диагностировать с помощью этих самых «тулбоксов».
….
На этом всё, изучай!
🛠 #devops #debug #docker #k8s
—
💬 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.Кстати «тулбоксы» можно использовать не только в кубере, они отлично ложатся на обычный докер, опять-же сеть потыкать, покурлить и помяукать. Так что если у тебя нет куба, похуй, пригодится и для обычного докера.
Ну а теперь давай создадим искусственную проблему и попытаемся её диагностировать с помощью этих самых «тулбоксов».
….
На этом всё, изучай!
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет. А у тебя спина белая 🥳
Недавно упоминал в чатике про цикл статей которые я написал про Podman, лови следующую.
Healthcheck инструментами Podman → https://two.su/3kcvf
🛠 #devops #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Недавно упоминал в чатике про цикл статей которые я написал про Podman, лови следующую.
Рекомендую ознакомиться, столько интересного и неочевидного раскопал. Возможно это подтолкнет тебя к переезду с docker в podman.
Healthcheck инструментами Podman → https://two.su/3kcvf
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Диагностика проблем через контрольные суммы
🔤 🔤 🔤 🔤 🔤 🔤 🔤
Всем привет.
ㅤ
У меня на этой неделе случилась беда. На одной машине пользователя стала глючить 1с. Уже и кэши очищали, и машину перезагружали - глючит и все. Пало подозрение на повреждение самой 1с.
Можно было бы просто переставить, и забыть. Но мне хотелось именно убедиться, что проблема на диске.
Нужно просто рекурсивно сравнить два каталога по содержимому файлов. Каталог со старой установкой переименовал, поставил заново и начал сравнивать.
Проще всего это сделать с помощью
-n (--dry-run) — только тестирование
-c (--checksum) — по содержимому
-r (--recursive) — рекурсивно
-v (--verbose) — подробности
Вот только ставить на клиентскую машину
Поскольку сравниваем два предположительно одинаковых каталога, то в идеале, файлы должны быть в четном количестве. Если у файлов c одинаковыми
В общем, как я и предполагал, нашлись файлы с разной контрольной суммой. Значит повреждение было на диске. Ну, и после переустановки 1с, проблема ушла.
На самом деле проблема не такая редкая. Дело в дисках. Есть такая характеристика как Неисправимых ошибок чтения/прочитанных бит.
Например, на wd blue 1E-14, на wd gold 1E-15, на SSD Micron 7450 MAX 1e-17. То есть серверный ssd в 1000 раз надежней, чем бюджетный hdd. Просто не всегда эти ошибки одинаково заметны.
Кстати,
Всем работы без багов.
🛠 #debug #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Всем привет.
ㅤ
У меня на этой неделе случилась беда. На одной машине пользователя стала глючить 1с. Уже и кэши очищали, и машину перезагружали - глючит и все. Пало подозрение на повреждение самой 1с.
Можно было бы просто переставить, и забыть. Но мне хотелось именно убедиться, что проблема на диске.
Нужно просто рекурсивно сравнить два каталога по содержимому файлов. Каталог со старой установкой переименовал, поставил заново и начал сравнивать.
Проще всего это сделать с помощью
rsync:rsync -ncrv /old1c /1c
-n (--dry-run) — только тестирование
-c (--checksum) — по содержимому
-r (--recursive) — рекурсивно
-v (--verbose) — подробности
Вот только ставить на клиентскую машину
rsync ради одного сравнения, так себе идея. Да и если забыть ключик -n, можно убить данные. Решил сделать все костылями:find /old1c /1c -type f -printf "%f " -exec md5sum {} \; |
awk '{print $2,$1}'|sort |uniq -c|awk '$1%2'-type f — только файлы-printf "%f " — печатаем basename-exec md5sum {} \; — для каждого файла вычисляем md5|awk '{print $2,$1}' — сначала md5, потом файл (не принципиально, но красивее)|sort |uniq -c — на первой позиции - число уникальных записей. Без sort uniq не работает.|awk '$1%2' — печатаем только строки, с нечетным числом записей.Поскольку сравниваем два предположительно одинаковых каталога, то в идеале, файлы должны быть в четном количестве. Если у файлов c одинаковыми
basename разная md5, то их число будет нечетным.В общем, как я и предполагал, нашлись файлы с разной контрольной суммой. Значит повреждение было на диске. Ну, и после переустановки 1с, проблема ушла.
На самом деле проблема не такая редкая. Дело в дисках. Есть такая характеристика как Неисправимых ошибок чтения/прочитанных бит.
Например, на wd blue 1E-14, на wd gold 1E-15, на SSD Micron 7450 MAX 1e-17. То есть серверный ssd в 1000 раз надежней, чем бюджетный hdd. Просто не всегда эти ошибки одинаково заметны.
Кстати,
rsync работает значительно быстрее. Если данных много — используйте его.Всем работы без багов.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Как превратить DNS-сервер в пушку для DDoS-атаки
В DNS есть такая прикольная штука, как ANY запрос, его суть — выдать тебе сразу все DNS записи по нужному домену.
ㅤ
Запрос вида:
Я встречал много Bash скриптов, которые на этом запросе завязаны, да чё греха таить, вчера буквально обратился товарищ (малваря-аналитик) с запросом — всё пропало, не работает, ааааа!!!
Хотя раньше всё работало из коробки и Bash скрипты вели себя предсказуемо. Но опять же, в зависимости от DNS сервера, результаты могли разница. Тебе могли отдать данные, которые в предыдущем запросе были совсем другими.
Логично. Провайдеры рано или поздно приходят к этому, начинают блокировать подобные запросы. Всё это связано с дидос атаками. Погоды эти ANY запросы не делают, но создают большую проблему и головную боль. Основная проблема — DDoS amplification.
Самый адекватный способ борьбы с этим — отключить всё нахуй и поломать возможный вектор атаки. Короче непредсказуемость ANY запроса это плохая практика. Запрос ANY никогда не был стандартизирован - «как получить всё».
Читать продолжение: https://two.su/dzg0a
🛠 #security #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Разбираем механику DNS Amplification атак и выясняем, почему использование ANY-запросов превращает твой сервер в инструмент для DDoS. Узнай, как работают векторы усиления трафика и как правильно настроить защиту на BIND и Unbound.
В DNS есть такая прикольная штука, как ANY запрос, его суть — выдать тебе сразу все DNS записи по нужному домену.
ㅤ
Запрос вида:
dig chklst.ru ANY
Я встречал много Bash скриптов, которые на этом запросе завязаны, да чё греха таить, вчера буквально обратился товарищ (малваря-аналитик) с запросом — всё пропало, не работает, ааааа!!!
dig chklst.ru ANY
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 21 (Not Supported): (Type ANY Queries not supported here, RFC8482)
;; QUESTION SECTION:
Хотя раньше всё работало из коробки и Bash скрипты вели себя предсказуемо. Но опять же, в зависимости от DNS сервера, результаты могли разница. Тебе могли отдать данные, которые в предыдущем запросе были совсем другими.
Логично. Провайдеры рано или поздно приходят к этому, начинают блокировать подобные запросы. Всё это связано с дидос атаками. Погоды эти ANY запросы не делают, но создают большую проблему и головную боль. Основная проблема — DDoS amplification.
Самый адекватный способ борьбы с этим — отключить всё нахуй и поломать возможный вектор атаки. Короче непредсказуемость ANY запроса это плохая практика. Запрос ANY никогда не был стандартизирован - «как получить всё».
Читать продолжение: https://two.su/dzg0a
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Твой сайт — решето! Или как не обосраться
Недавно я показывал тебе как настроить свой собственный поисковый движок на SearXNG, ну так вот, нашел на просторах агрегатора, который собирает такие публичные поисковики в табличку. И по сути можно на чужих серверах устроить себе полноценный поиск по интернету.
ㅤ
Ссылка: https://searx.space/
Зачем? Ну к примеру нужно тебе что-то быстро анонимно поискать, а своё детище поднимать в хуй не упёрлось. Открываешь такой публичный поисковик и ебешь его в хвост и в гриву. Но естественно не забываем предварительно включить КВН или соксы.
Для браузеров есть пиздатые плагины: Zero Omega и FoxyProxy.
СТОП! Яж про другое…
Пойдем дальше, на этом сайте я увидел рейтинги настройки серверов и вспомнил, когда я 100 лет назад поднимал инстанс с собственным mastodon сервером, я упарывался в безопасность и прям активно соблюдал эти рейтинги. Потом это всё забылось и сегодня решил проверить свой основной блог и мягко говоря прихуел.
Мой социальный рейтинг по SSL был на уровне «D» — да вы батенька не девопс-инженер, вы пидор ебаный!
Дела, дела! Надо это исправлять.
Чё значит этот рейтинг?
Сервис Mozilla Observatory смотрит не на код приложения, а на то, насколько правильно настроен твой сервер и заголовки безопасности.
Кстати опять же пентестеры активно применяют это в своей работе, чтобы быстренько проверить безопасность конфигурации и по возможности найти лазейку к твоему шоколадному бекенду с последующим проникновением без вазелина.
Если кратко — это линтер безопасности, а рейтинг всего лишь сводная оценка качества настроек и твоих компетенций.
Основные категории проверки:
1. HTTP-заголовки безопасности
2. HTTPS и TLS
3. Cookies
4. Защита от известных атак
Хули, давай это исправим, мне пришлось добавить такое в свою конфигурацию, чтобы добить рейтинг в более-менее вменяемую зону и получить заветную букву «B». Чтобы получить «A» мне придется немного перекроить работу с javascript, но пока мне лень.
Собственно конфиг:
⚪ Это защита от XSS атак и внедрения чужого контента. Я прописал доверенные сайты с которыми работаю. Но узкой дыркой осталось «unsafe-inline», с помощью него я разрешил inline JS, чтобы мои статусы из mastodon корректно передавались. Вот эту штуку и нужно будет допилить, чтобы получить по ебалу рейтинг «A+».
⚪ Всегда используй протокол https, включая поддомены.
⚪ Предоставляет защиту от clickjacking, разрешает вставку сайта в iframe только с того же домена, но у меня уже это прописано в первом заголовке. Похуй, оставляем. Кстати он уже устаревший, но все еще используется.
⚪ Запрещает браузеру угадывать тип файла, например сервер отдал JS как
⚪ Контролирует, что отправляется в Referer, хороший баланс приватности и аналитики.
Если подытожить, получаем — грузи ресурсы только отсюда, не доверяй подозрительной хуйне, всегда используй https и не давай сайту быть встроенным куда попало.
На этом собственно и всё, можешь пойти и проверить свои компетенции в настройке.
Поделись в комментах своим социальным рейтингом, хоть позавидуем.
🛠 #security #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Недавно я показывал тебе как настроить свой собственный поисковый движок на SearXNG, ну так вот, нашел на просторах агрегатора, который собирает такие публичные поисковики в табличку. И по сути можно на чужих серверах устроить себе полноценный поиск по интернету.
ㅤ
Ссылка: https://searx.space/
Зачем? Ну к примеру нужно тебе что-то быстро анонимно поискать, а своё детище поднимать в хуй не упёрлось. Открываешь такой публичный поисковик и ебешь его в хвост и в гриву. Но естественно не забываем предварительно включить КВН или соксы.
Для браузеров есть пиздатые плагины: Zero Omega и FoxyProxy.
Я пользуюсь первым, как-то более интуитивно понятно правила настраиваются, в отличие от второго. Но тут больше вкусовщина, возможно ты оверхед монстр и спокойно стихи на регулярках перед сном читаешь своему ребенку.
СТОП! Яж про другое…
Пойдем дальше, на этом сайте я увидел рейтинги настройки серверов и вспомнил, когда я 100 лет назад поднимал инстанс с собственным mastodon сервером, я упарывался в безопасность и прям активно соблюдал эти рейтинги. Потом это всё забылось и сегодня решил проверить свой основной блог и мягко говоря прихуел.
Мой социальный рейтинг по SSL был на уровне «D» — да вы батенька не девопс-инженер, вы пидор ебаный!
Дела, дела! Надо это исправлять.
Чё значит этот рейтинг?
Сервис Mozilla Observatory смотрит не на код приложения, а на то, насколько правильно настроен твой сервер и заголовки безопасности.
A / A+ = всё настроено пиздато
B / C = терпимо, но ты все равно долбаёб
D / F = хуйня, переделать, серьёзные дыры, почти нет защиты
Кстати опять же пентестеры активно применяют это в своей работе, чтобы быстренько проверить безопасность конфигурации и по возможности найти лазейку к твоему шоколадному бекенду с последующим проникновением без вазелина.
Если кратко — это линтер безопасности, а рейтинг всего лишь сводная оценка качества настроек и твоих компетенций.
Основные категории проверки:
1. HTTP-заголовки безопасности
2. HTTPS и TLS
3. Cookies
4. Защита от известных атак
Хули, давай это исправим, мне пришлось добавить такое в свою конфигурацию, чтобы добить рейтинг в более-менее вменяемую зону и получить заветную букву «B». Чтобы получить «A» мне придется немного перекроить работу с javascript, но пока мне лень.
Собственно конфиг:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-src 'self' https://video.bashdays.ru https://xn--r1a.website; connect-src 'self' https://api.rss2json.com https://bashdayz.ru;" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
text/plain, браузер мог бы «догадаться» и выполнить. Теперь хуй, ничего не выполнит.Если подытожить, получаем — грузи ресурсы только отсюда, не доверяй подозрительной хуйне, всегда используй https и не давай сайту быть встроенным куда попало.
На этом собственно и всё, можешь пойти и проверить свои компетенции в настройке.
Поделись в комментах своим социальным рейтингом, хоть позавидуем.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Свой S3 или пошаговая настройка Garage
Здрасти, здрасти. Теперь по выходным у меня полнейший «цифровой детокс», а причина этому — дача. Круче всякого спортзала прокачивает, а заодно прочищает голову. Физический труд всегда в почёте.
ㅤ
Ладно, это детали… сегодня будем поднимать собственный S3 и да, без хуйни вроде minio и ceph.
А на помощь к нам приходит «Гараж», в котором мы и будем хранить наши «Вёдра». Garage ориентирован на маленький и средние кластера, домашние сервера и распределенные ноды. И да, он полностью в opensource и не просит денег. Для self-host пиздатейшее решений, да и морда есть из коробки.
Я возьму 3 своих рандомных сервера и сделаю из них кластер. Сервера не пустые, на них что-то крутится и вертится, просто рядышком впендюрю еще одну хуёвинку.
Почему именно 3 сервера? Кластерная классика, если один из серверов пойдёт по пизде, то 2 других соберут кворум и отдадут тебе твои данные. То есть тебе не нужно иметь заранее подготовленные машины, можно взять какойнить хлам и из него запилить кластер под бекапы. И всё это дело будет работать нативно через API S3.
Прицепом воткнем балансировщик нагрузки, чтобы по домену всё работало. И да, запускать будем в докере.
Поехали настроим это безобразие.
Демон докера надеюсь у тебя уже установлен, поэтому заострять внимание на этом не будем. Заходим на первый сервер и мутим мутки:
Файл
Думаю, вопросов не должно возникнуть. Банальный композник, порты я тебе все подписал. Версию гаража можешь глянуть в интернете, на момент написания статьи последняя v2.3.0. Да буква «v» тут важна и
Читать продолжение: https://two.su/3qjfl
🛠 #devops #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Здрасти, здрасти. Теперь по выходным у меня полнейший «цифровой детокс», а причина этому — дача. Круче всякого спортзала прокачивает, а заодно прочищает голову. Физический труд всегда в почёте.
ㅤ
Ладно, это детали… сегодня будем поднимать собственный S3 и да, без хуйни вроде minio и ceph.
А на помощь к нам приходит «Гараж», в котором мы и будем хранить наши «Вёдра». Garage ориентирован на маленький и средние кластера, домашние сервера и распределенные ноды. И да, он полностью в opensource и не просит денег. Для self-host пиздатейшее решений, да и морда есть из коробки.
Я возьму 3 своих рандомных сервера и сделаю из них кластер. Сервера не пустые, на них что-то крутится и вертится, просто рядышком впендюрю еще одну хуёвинку.
Почему именно 3 сервера? Кластерная классика, если один из серверов пойдёт по пизде, то 2 других соберут кворум и отдадут тебе твои данные. То есть тебе не нужно иметь заранее подготовленные машины, можно взять какойнить хлам и из него запилить кластер под бекапы. И всё это дело будет работать нативно через API S3.
Да, когда ты будешь заливать файлы в своё облако, данные будут реплицироваться на все 3 сервера. Поэтому сервера рекомендую держать в разных регионах или вообще у разных провайдеров. Например, если сгорит один дата центр, то ты не проебешь свои данные. Удобно и надёжно. Ну и смотри в сторону дискового места, если на одном сервере выделил 50 гигов под бакет, то на остальных серверах выдели столько же, чтобы не возникало коллизий.
Прицепом воткнем балансировщик нагрузки, чтобы по домену всё работало. И да, запускать будем в докере.
Поехали настроим это безобразие.
Демон докера надеюсь у тебя уже установлен, поэтому заострять внимание на этом не будем. Заходим на первый сервер и мутим мутки:
Файл
compose.yaml:services:
garage:
image: dxflrs/garage:v2.3.0
ports:
- "3900:3900" # S3 API
- "3901:3901" # RPC
- "3902:3902" # Web (optional)
- "3903:3903" # Admin API
volumes:
- ./garage.toml:/etc/garage.toml:ro
- ./meta:/var/lib/garage/meta
- ./data:/var/lib/garage/data
Думаю, вопросов не должно возникнуть. Банальный композник, порты я тебе все подписал. Версию гаража можешь глянуть в интернете, на момент написания статьи последняя v2.3.0. Да буква «v» тут важна и
latest тут не канает.Читать продолжение: https://two.su/3qjfl
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Такс, S3 кластер на Garage в предыдущем посте мы с тобой сообразили, самое время накрутить обвесов и сделать всё по взрослому. Как ты любишь — без хуйни.
ㅤ
Для начала установим балансировщик. То есть входная точка у кластер всегда будет одна, а дальше балансировщик будет раскидывать запросы по 3м нашим серверам в кластере. Если одна из нод пойдет по пизде, балансировщик это прозрачно разрулит и отдаст тебе файл в любом случае, даже без правки конфигов.
Проверяем наш кластер:
Работает. Дальше берем еще один сервер, который будет выступать балансировщиком. Для теста я создам в Selectel нищую виртуалочку и впихарю на нее
Устанавливаем haproxy:
Домен для кластера я буду использовать
Правим конфиг
Проверяем валидность конфиги:
Ага, хуй там плавал. Давай создадим SSL сертификат. Я конечно предпочитаю angie, чтобы он сам это сделал, но у нас haproxy, поэтому придется немного пострадать...
Читать продолжение: https://two.su/aaahd
🛠 #devops #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
ㅤ
Нежных сразу — нахуй, остальным велком.
Для начала установим балансировщик. То есть входная точка у кластер всегда будет одна, а дальше балансировщик будет раскидывать запросы по 3м нашим серверам в кластере. Если одна из нод пойдет по пизде, балансировщик это прозрачно разрулит и отдаст тебе файл в любом случае, даже без правки конфигов.
Проверяем наш кластер:
docker exec -it garage-garage-1 /garage status
Работает. Дальше берем еще один сервер, который будет выступать балансировщиком. Для теста я создам в Selectel нищую виртуалочку и впихарю на нее
haproxy.Устанавливаем haproxy:
apt install haproxy
Домен для кластера я буду использовать
s3.linuxfactory.ru, соответственно во всяких rclone нужно будет прописать его в параметре endpoint.Правим конфиг
/etc/haproxy/haproxy.cfg:global
log /dev/log local0
maxconn 4096
defaults
mode tcp
timeout connect 5s
timeout client 1m
timeout server 1m
option http-server-close
timeout http-request 10s
timeout queue 1m
frontend garage_front
bind *:443 ssl crt /etc/ssl/garage.pem
option http-buffer-request
default_backend garage_back
backend garage_back
balance roundrobin
server node1 95.123.123.116:3900 check
server node2 152.44.71.205:3900 check
server node3 145.83.116.20:3900 check
Проверяем валидность конфиги:
haproxy -c -f /etc/haproxy/haproxy.cfg
Приучи себя всегда это делать, будь то nginx либо что-то другое. Однажды это спасет твою жопу от пенетрации.
Ага, хуй там плавал. Давай создадим SSL сертификат. Я конечно предпочитаю angie, чтобы он сам это сделал, но у нас haproxy, поэтому придется немного пострадать...
Читать продолжение: https://two.su/aaahd
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Относительная нумерация
Частенько народ интересуется, а почему у меня в виме такая странная нумерация. Да, этим вопросом и я в своё время задавался. Называется это «Относительная нумерация».
ㅤ
Главная идея здесь — быстрое перемещение по коду с клавиатуры.
Например, курсор стоит у меня в 27 строке. Если я сейчас выполню комбинацию:
Аналогично работает и в других направлениях. В редакторе ZED это включается через конфиг:
В виме же по классике в конфиге:
Честно, если ты пользуешься мышкой, это бесполезная настройка. Для новичков это совсем неочевидная фича и возможно даже вредная. Короче у этой фичи целая философия:
➡️ Мышление расстояниями. В заурядной жизни, ты будешь думать — ага, мне бы на строку 15 попасть. А если ты адепт вима, твоё мышление такое — мне бы на 6 строчек ниже.
➡️ Ускорение всех count-команд. Тут не только клавиши
Ты сразу видишь нужное число, сразу прожимаешь нужную комбинацию.
➡️ Сильно уменьшает мысленную математику. Без — так… я на 120 строке, мне нужно на 133… это +13. С ней — вижу 13 →
Мозги по сути вообще ничего не считают. Это плюс. Думаешь не головой, а жопой.
➡️ Работает лучше с большими файлами. Когда у тебя файл на 1000+ строк, абсолютные номера создают шум, а относительные прям в тему. Ты ориентируешься вокруг курсора, а не во всём файле.
Минусы? Да конечно!
➡️ Поначалу выламывает тебя, перестраивает, больно
➡️ Плохо подходит для дебага с конкретными строками
В общем относительная нумерация, это не про цифры, она про то, чтобы перестать искать строки и моментально перепрыгивать в нужное место.
Если есть чё добавить, камон в комменты, будет интересно почитать.
🛠 #devops #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Частенько народ интересуется, а почему у меня в виме такая странная нумерация. Да, этим вопросом и я в своё время задавался. Называется это «Относительная нумерация».
ㅤ
Главная идея здесь — быстрое перемещение по коду с клавиатуры.
Например, курсор стоит у меня в 27 строке. Если я сейчас выполню комбинацию:
6j, то курсор у меня встанет на строку: Не забудь подставить своё мыло. Такая нумерация показывает расстояние до строки от курсора, а не её абсолютный номер.Аналогично работает и в других направлениях. В редакторе ZED это включается через конфиг:
relative_line_numbers": "enabled"
В виме же по классике в конфиге:
set number
set relativenumber
Честно, если ты пользуешься мышкой, это бесполезная настройка. Для новичков это совсем неочевидная фича и возможно даже вредная. Короче у этой фичи целая философия:
hjkl задействованы, ты можешь выполнять ряд других операций. Например:5dd — удалить 5 строк
3yy — скопировать 3 строки
4> — сдвинуть 4 строки вправо
2} — прыгнуть на 2 абзаца
Ты сразу видишь нужное число, сразу прожимаешь нужную комбинацию.
13j. Мозги по сути вообще ничего не считают. Это плюс. Думаешь не головой, а жопой.
Минусы? Да конечно!
В общем относительная нумерация, это не про цифры, она про то, чтобы перестать искать строки и моментально перепрыгивать в нужное место.
Если есть чё добавить, камон в комменты, будет интересно почитать.
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Hugo за 30 секунд. Мой пайплайн на Gitea Actions
Наконец-то дошли руки до оптимизации пайпа для сборки Hugo в Gitea, да, есть куда еще стремиться, но там уже с жирными файлами нужно поработать.
ㅤ
Пост больше для энтузиастов и для тех кто хочет посмотреть, как всё происходит под капотом. Можешь взять мою болванку и под свои проекты переделать.
Читать: https://two.su/942is
🛠 #devops #dev
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Наконец-то дошли руки до оптимизации пайпа для сборки Hugo в Gitea, да, есть куда еще стремиться, но там уже с жирными файлами нужно поработать.
ㅤ
Пост больше для энтузиастов и для тех кто хочет посмотреть, как всё происходит под капотом. Можешь взять мою болванку и под свои проекты переделать.
Читать: https://two.su/942is
—
Please open Telegram to view this post
VIEW IN TELEGRAM
Docker кеш без боли
ㅤ
Давай поговорим про docker и кеширование, тема вроде поверхностная, но как оказалось многие в ней плавают и особо не понимают почему их сборка каждый раз занимает 100500 минут.
А занимает она столько минут, по одной причине — копировать исходники нужно в последнем слое. Механизм тут простой, если какой-то слой изменился, то следующие слои будут пересобраны. Логично, что если ты копируешь исходники так:
Тебе пезда! Всё будет пересобираться каждый раз с нуля, никаким кешированием тут и не пахнет. Так делают многие, ведь оно работает и пофигу что долго.
В примере выше, команда
Ключевой момент тут исходники, которые меняются.
Получаем:
- заново устанавливает npm зависимости
- заново качает пакеты
- заново rebuild native modules
- тратит минуты в CI
Хотя зависимости вообще не менялись. Мрак! Фиксим:
Теперь если что-то изменить в коде проекта, пересобирается только:
А
Бест-практика простая: От самого стабильного → к самому изменяемому.
- base image
- системные пакеты
- lock-файлы зависимостей
- install dependencies
- исходники
- build
- startup
Короче думай паттерном, а не жопой — «Какие файлы меняются редко?» и выносить их максимально вверх Dockerfile.
Каждый
Вот и вся наука.
🛠 #devops #docker
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
ㅤ
Давай поговорим про docker и кеширование, тема вроде поверхностная, но как оказалось многие в ней плавают и особо не понимают почему их сборка каждый раз занимает 100500 минут.
А занимает она столько минут, по одной причине — копировать исходники нужно в последнем слое. Механизм тут простой, если какой-то слой изменился, то следующие слои будут пересобраны. Логично, что если ты копируешь исходники так:
FROM node:22
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["node", "dist/index.js"]
Тебе пезда! Всё будет пересобираться каждый раз с нуля, никаким кешированием тут и не пахнет. Так делают многие, ведь оно работает и пофигу что долго.
В примере выше, команда
COPY копирует весь проект. Представь, что ты изменил одну букву в конфиге и приехали. Кеш инвалидировался, сборка пошла по новой и RUN npm install доставит много удовольствия. Ключевой момент тут исходники, которые меняются.
Получаем:
- заново устанавливает npm зависимости
- заново качает пакеты
- заново rebuild native modules
- тратит минуты в CI
Хотя зависимости вообще не менялись. Мрак! Фиксим:
FROM node:22
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]
Теперь если что-то изменить в коде проекта, пересобирается только:
COPY . .
RUN npm run build
А
RUN npm ci возьмется из кеша. Аналогично и в питончике и гошке:COPY . .
RUN pip install -r requirements.txt
COPY . .
RUN go mod download
Бест-практика простая: От самого стабильного → к самому изменяемому.
- base image
- системные пакеты
- lock-файлы зависимостей
- install dependencies
- исходники
- build
- startup
Короче думай паттерном, а не жопой — «Какие файлы меняются редко?» и выносить их максимально вверх Dockerfile.
Каждый
RUN, COPY, ADD это новый слой. Docker пытается переиспользовать уже существующие слои из кеша. Если инструкция и все предыдущие слои не изменились — слой не пересобирается. Docker сбрасывает кеш начиная с измененного слоя.Вот и вся наука.
—
Please open Telegram to view this post
VIEW IN TELEGRAM