Очередные грабли на которые в LF многие наступили.
ㅤ
Есть nginx с такой конфигурацией:

server {
    listen 80;
    server_name _;

    location /app {
        proxy_pass http://localhost:5000;
    }
}

И есть приложение:

from flask import
Flask app = Flask(__name__)

@app.route('/')

def hello():
    return 'Привет, Linux Factory!'
    
if __name__ == '__main__':
    app.run(host='0.0.0.0', debug=True)

Плюс к нему Dockerfile:

FROM python:3.8-slim
WORKDIR /app COPY . 
/app RUN pip install -r requirements.txt 
EXPOSE 5000
CMD ["python", "app.py"]

Собираем и запускаем контейнер:

docker build -t bashdays .
docker run -d -p 5000:5000 bashdays

Идем в браузере на http://bashdays.ru/app и получаем хуй с маслом:

Not Found. The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.

Важно! Уже по этой ошибке можно сделать какие-то выводы, эт не стандартная ошибка от nginx, а значит запрос отлично доходит до приложения. Но где-то внутри приложения теряется. Тренируй насмотренность, у nginx ошибки обычно по центру выводятся, а тут align вправо.

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

А что случилось? Всёж верно? Локейшен в nginx прописан, прокси-пасс тоже присутствует, где ответ от приложения?

Все дело в слэшах!

 location /app {
        proxy_pass http://localhost:5000/;
    }

В конце порта 5000 ставим слэш и проверяем. Хуяк и оно начинает работать!

Что вообще происходит?

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

То есть приложение app.py получает роут /app а его там естественно нет. А есть просто корень /.

А когда мы добавляем слэш, nginx добавляет путь после /app к целевому урлу.

Короче опять заумно расписал, давай снова на котиках!

➡️ Без слэша запрос /app проксируется на http://localhost:5000/app, что не совпадает с маршрутом, настроенным в Flask.

➡️ С слэшем запрос /app проксируется на http://localhost:5000, и приложение Flask обслуживает его как корневой путь /.

В общем с конечным слэшем nginx «удаляет» часть пути /app и отправляет запрос на корень приложения Flask.

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

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

Вечерком еще чтива подвезу, случайно набрал интеграций, теперь отдуваюсь.

tags: #nginx #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Очередной распространенный вопрос - а схуяли нужно гитлаб изучать?
ㅤ
Почему не github / pornhub / gitea?

Ответ простой — Бесплатная версия GitLab (Community Edition) с открытым кодом даёт возможность изучить платформу без затрат. Для бизнеса это ещё и свобода от привязки к вендору.

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

Например, в вакансиях этот пункт про гитлаб будет в 99% случаев. Раньше еще можно было встретить Bitbucket, но эти письки съебали с РФ и поэтому все дружно послали atlassian в пешее эротическое.

Что не так с гитлабом?

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

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

Кто-то вообще умудряется превратить пайплайны в ООП. Это отдельный костяк отбитых инженеров, приверженцы бас-фактора.

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

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

Грубо говоря — нарисовал в голове блок схему, напрограммировал. Благо сейчас полно книжек — Java для детей, Golang - для бабушек и т.п. Читаешь книжку за пару дней, знакомишься с синтаксисом и пошел кодить. Функции, циклы, условия они везде одинаковые.

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

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

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

Такие дела!

tags: #рабочиебудни #devops
—
🔔 @bashdays➡️ @gitgate

Вчера многие обратили внимание на конструкцию в nginx:

server_name _;

Что это блядь за «чёрточка» вместо сервер_нейма?
ㅤ
Если техническим языком — это подстановочное имя хоста.

Пусть на сервере прописано так:

server {
    listen 80;
    server_name _;
    return 444;
}

server {
    listen 80;
    server_name bashdays.ru;
    return 200;
}

server {
    listen 80;
    server_name linuxfactory.ru;
    return 200;
}

Если в браузере откроем bashdays.ru или linuxfactory.ru, то получим статус 200.

А как получить 444, тот самый с «чёрточкой»?

Просто! Например, зайти на сервер по его IP адресу. Nginx не сможет сопоставить доменные имена, которые прописаны в конфиге и отдаст статус 444.

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

Обычно эту «чёрточку» прописывают в файле defaults, чтобы тем, кто попал на сервер по IP адресу увидел, то что ты захочешь, а не рандомный сайт который у тебя висит на сервере.

Короче если запрос приходит с именем хоста, которое не совпадает ни с одним из явно прописанных server_name, то он будет обрабатываться этим серверным блоком.

А в сочетании с return 444 (No Response) используется для закрытия нежелательных запросов или для обработки некорректных запросов.

Если «чёрточка» не используется, то вместо неё можно просто прописать default_server в директиве listen, и блок будет работать аналогично.

server {
    listen 80 default_server;
    return 444;
}

Символ _ не имеет специального значения в самом Nginx. Это просто удобное соглашение, принятое сообществом.

Вот так вот и живём, изучай!

tags: #nginx #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Сегодня будем запирать врата ада.
ㅤ
Ситуация: Есть физический сервер, на нём торчит само собой Linux, к нему подключен монитор и кнопки. Короче можно физически подойти к этой машине и ввести логин/пароль.

Ну или при желании понажимать ALT+F1, F2, F3 (чтобы переключать tty).

Надеюсь ты понял о чем я тебе говорю. Ну дак вот!

Задача: Нужно запретить физический вход по логину/паролю, но оставить вход по ssh с ключами.

Как настраивать все эти ключи можешь почитать в серии постов по тэгу: #linuxfactory

Давай теперь отключим физический доступ к tty.

Заходим на сервер и смотрим юниты

systemctl list-units | grep getty

В ответ получаем список активных tty

getty@tty1.service
getty@tty2.service
getty@tty3.service
getty@tty4.service

getty (сокращение от get tty) — это программа в Linux и Unix-подобных системах, которая отвечает за управление терминалами и логин-процессом для пользователей, подключающихся к системе через консоль.

Теперь запускаем команды:

systemctl disable getty@tty{1..10}.service
systemctl stop getty@tty{1..10}.service

Всё! Песда! Терминал становится черным, интерактивность потеряна.

Пробуем понажимать ALT+F1, F2, F3 — хуй там плавал!

Перезагружаем сервер и НИЧЕГО! Черная дыра! Пробуем подключиться к серверу по ssh — ХА! Работает сучка!

При отключении getty для терминалов tty1–tty10, это не повлияет на SSH-доступ, так как SSH-сервер работает независимо от getty.

Теперь даже имея физический доступ к серверу, ты нихуя с ним сделать не сможешь. Максимум загрузиться в Recovery mode и починить:

sudo mount /dev/sdXn /mnt
sudo chroot /mnt
sudo systemctl enable getty@tty{1..10}.service
sudo systemctl start getty@tty{1..10}.service

Вот такие приколюхи! Как и где это применять решай сам. Развлекайся.

Про Magic SysRq в Linux писал тут.

Чем терминал отличается от консоли писал тут

tags: #linux #devops
—
🔔 @bashdays➡️ @gitgate

Использовать ssh ключи очень удобно, при условии если у тебя в наличии 2-5-10 серверов

А как жить в ситуации когда у тебя 100500 серверов и еще 100500 пользователей?
ㅤ
Этож нужно за всем этим следить, обновлять и отзывать неактуальны (проёбанные) ключи. Всё скатывается в ужасную рутину.

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

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

Центр сертификации (CA).

Работает он так:

1. Ты настраиваешь CA которому доверяют все твои 100500 серверов.
2. Сертификат подписывает ключи пользователей с указанием сроков действия и ограничений.
3. Если сотрудник покидает команду, ты просто отзываешь сертификат, а не удаляешь ключи с каждого сервера.

Давай замутим:

Берем какуюнить линукс машину и делаем из него CA.

ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_ca -C "SSH Certificate Authority"

Описывать за что отвечают параметры не буду, всё это уже разжевали, читай посты по тегу #linuxfactory

По итогу получаем 2 ключа, ssh_ca (приватный) и ssh_ca.pub (публичный).

Дальше чтобы сервера могли доверять сертификатам, подписанным нашим CA, добавляем публичный ключ CA (ssh_ca.pub) на все 100500 серверов.

Тут уже сам автоматику организуй, либо баш скриптом, либо ансибл ролью либо еще как-то. Попробуй ради интереса изобрести своё решение.

Покажу в рамках одного сервера:

scp ~/.ssh/ssh_ca.pub user@bashdays:/etc/ssh/

Теперь заходим на этот самый сервер куда ты скопировал публичную часть ключа.

Открываем конфиг /etc/ssh/sshd_config

И пишем в него:

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

Не забываем хуйнуть:

sudo systemctl restart ssh

Теперь сервер будет доверять сертификатам подписанным CA.

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

Для этого копируем на CA машину свой локальный публичный ключ. Тот что у тебя на машине лежит и который ты прописывал ранее в authorized_keys на удаленных серверах.

Подписываем публичный ключ и превращаем его в сертификат.

ssh-keygen -s ~/.ssh/ssh_ca -I "user_cert" -n user -V +1w /tmp/user_key.pub

В ответ получаем нечто такое:

Signed user key /tmp/user_key-cert.pub: id "user_cert" serial 0 for username valid from 2025-02-16T12:02:00 to 2025-02-23T12:02:59

И в папке /tmp появляется файл user_key-cert.pub

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

 error: Certificate invalid: name is not a listed principal

Забираем себе на локальную машину подписанный ключ и пробуем подключиться:

ssh -i ~/.ssh/id_rsa -o CertificateFile=~/.ssh/user_key-cert.pub root@bashdays.com

Вуаля, я залетаю на сервер с подписанным ssh ключом, а на удаленном сервере вижу в логах:

2025-02-16  sshd[958704]: Accepted publickey for root from 11.11.11.11 port 35528 ssh2: RSA-CERT SHA256:Q4SKZ5cRycm79w0SyvRhAQR8 ID user_cert (serial 0) CA RSA SHA256:PtNBUw/+4/gGz4rc/ybu/uNHngcI

Если что-то не получается или не даёт зайти, пиздуешь на сервер к которому подключается и смотришь логи var/logs/auth.log. В этом файле тебе очень информативно подскажут что погуглить.

И да, на удаленном сервере можно снести файл ~/.ssh/authorized_keys от тебе больше не пригодится. Потому что сервак начинает доверять всем ключам, которые подписаны через CA.

Ну а теперь давай отзовем сертификат с ключа

На сервере к которому ты настраивал подключение:

touch /etc/ssh/revoked_certs

В файле /etc/ssh/sshd_config добавляем:

RevokedKeys /etc/ssh/revoked_certs

Добавляем серт в этот файл с отзывами:

ssh-keygen -k -f /etc/ssh/revoked_certs -z 1 user_key-cert.pub

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

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

Завтра про Vault Hashicorp расскажу, в нем все проще делается

tags: #linux #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Здрасти, сегодня продолжаем издеваться над ssh.

Давай прикрутим 2FA.
ㅤ
Идем на сервер к которому хотим подключmся по ssh и ставим пакеты:

sudo apt update
sudo apt install libpam-google-authenticator

Запускаем конфигуратор:

google-authenticator

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

После запуска конфигуратора, получишь по ебалу:

Do you want authentication tokens to be time-based (y/n)

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

Можно еще всякие ключики использовать:

google-authenticator -t -f -d -w 3 -e 5 -r 3 -R 60

Если интересно: google-authenticator --help

Всю эту инфу куданить себе скопируй чтоб не проебаться.

Дальше сканируем этот QR код, либо берем секретный ключ который он тебе выплюнул и вставляем в vaultwarden в TOTP или на телефоне в апку добавляем.

Тот самый секретный ключ:

Your new secret key is: MAIY4KDCXKWHPDCI

В общем нужно получить шестизначный код, вернуться в терминал (где ты запускал конфигуратор) и вставить его. Логика аналогична подключению 2FA в любых сервисах.

После этого оно выплюнет тебе рекавери коды, ну и спросит:

Do you want me to update your "/root/.google_authenticator" file?

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks

и другие

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

В файл /root/.google_authenticator сохранится секретный ключ и коды восстановления. Этот файл не трогаем, без него тоже нихуя не заработает.

Теперь открываем файл /etc/pam.d/sshd

И добавляем в него строчку:

# @include common-auth
auth required pam_google_authenticator.so

По необходимости комментим common-auth если ничего не работает. Есть вариант не комментить, но тогда нужно правильно настроить common-auth, но у нас сегодня не про это.

Закомментировав этот модуль ты отключаешь стандартные механизмы аутентификации и даешь зеленый свет на использование pam_google_authenticator.

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

Дальше добавляем в конфиг: /etc/ssh/sshd_config

UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
PubkeyAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Вот и всё, настройка 2FA завершена.

Рестартим:

sudo systemctl restart ssh

И пробуем подключиться по ssh к этому серверу:

ssh root@bashdays.ru

(root@bashdays.ru) Verification code:

Ха! А что вводить? Это и есть 2FA, сюда вводим одноразовый код который выплюнул тебе vaultwarden либо аппка на телефоне.

Всё! Залетаем спокойно на сервер. Без кода и ключа хуй ты теперь чо сделаешь.

Как использовать резервные коды?

Да также при запросе в Verification code. НО из файла /root/.google_authenticator они будут отлетать. Тут тоже аккуратнее.

Также можешь включать 2FA для конкретных пользователей, в конфиге /etc/ssh/sshd_config

Match User <имя юзера>
      AuthenticationMethods publickey,keyboard-interactive

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

А как работать с 2FA и QR кодами из консоли, можешь почитать тут.

Главное не спеши и делай всё вдумчиво, чтобы не проебать доступ к серверу. Ну а если все проебал, да и хуй с ним, ебани кофейка и мультики посмотри.

tags: #linux #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Ребята с LF порой интересуются — а нахуя в nginx нужна поддержка lua? Можно какой-то пример, но только не Hello World?
ㅤ
Конечно можно!

Понадобилось мне как-то реализовать продвинутый basic auth, чтобы nginx сходил в mysql базу и сопоставил введенные учетные данные.

А как блядь это сделать?

Тут-то и пригодится Lua!

Для начала создаем базу (nginx_auth) и табличку users. Ну и в ней колонки username и password. В username храним имя пользователя, в password захэшированный пароль:

SHA1('$UpperPa$$word')

Эту команду выполняешь в mysql, в ответ он выплюнет тебе хэш, его и нужно будет заебенить в колонку password.

Дальше конфигуряем nginx:

    location / {
        content_by_lua_file /etc/nginx/lua/auth.lua;
    }

    location @authenticated {
        root /var/www/bashdays/htdocs/site;
        index index.html;
    }

В nginx само собой добавляем модуль Lua, Как его собрать можешь в гугле посмотреть, ну либо взять какойнить openresty.

Ну и сам скрипт кидаем в /etc/nginx/lua/auth.lua;

local mysql = require "resty.mysql"
local sha1 = require "resty.sha1"
local resty_string = require "resty.string"
local db, err = mysql:new()

-- Установка таймаута
if not db then
    ngx.log(ngx.ERR, "failed to create mysql object: ", err)
    return ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
end

db:set_timeout(1000)

-- Подключение к базе данных
local res, err = db:connect{
    host = "db",
    port = 3306,
    database = "nginx_auth",
    user = "nginx_user",
    password = "password",
    charset = "utf8",
}

if not res then
    ngx.log(ngx.ERR, "failed to connect to MySQL: ", err)
    return ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
end

-- Извлекаем данные из заголовков Authorization
local auth = ngx.var.http_authorization

if not auth or not auth:find("Basic ") then
    ngx.header["WWW-Authenticate"] = 'Basic realm="Restricted Area"'
    return ngx.exit(ngx.HTTP_UNAUTHORIZED)
end

-- Парсим Basic Auth заголовок
local encoded = auth:sub(7)  -- Убираем "Basic " из начала
local decoded = ngx.decode_base64(encoded)

if not decoded then
    ngx.header["WWW-Authenticate"] = 'Basic realm="Restricted Area"'
    return ngx.exit(ngx.HTTP_UNAUTHORIZED)
end

-- Разделяем строку на имя пользователя и пароль
local username, password = decoded:match("([^:]+):(.+)")

if not username or not password then
    ngx.header["WWW-Authenticate"] = 'Basic realm="Restricted Area"'
    return ngx.exit(ngx.HTTP_UNAUTHORIZED)
end

-- Хешируем пароль
local sha1_obj = sha1:new()
sha1_obj:update(password)
local password_hash = resty_string.to_hex(sha1_obj:final())

-- Проверяем пользователя и пароль в базе данных
local sql = string.format("SELECT * FROM users WHERE username = '%s' AND password = '%s'", username, password_hash)
local res, err = db:query(sql)

if not res or #res == 0 then
    ngx.header["WWW-Authenticate"] = 'Basic realm="Restricted Area"'
    return ngx.exit(ngx.HTTP_UNAUTHORIZED)
end

-- Передаем управление Nginx для загрузки страницы
ngx.exec("@authenticated")

Всё! Релоадим nginx и получаем прокаченный Basic Auth.

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

Теперь nginx лезет в базу и при успешном исходе кидает пользователя в локейшен @authenticated.

Да, скрипт работает на mariadb. Для всяких перкон и т.п. возможно нужно будет переделать SELECT.

Вот такие пироги, вот тебе и заебачее применение Lua!

➡️ Кстати, если увидел вектор атаки, поделись в комментах.

tags: #linux #devops #lua #nginx
—
🔔 @bashdays➡️ @gitgate

Такс, как и обещал притаранил тебе рабочий пайплайн для авто деплоя mkdocs через gitea.
ㅤ
Чтобы всё это заработало, в проекте тебе нужно создать структуру:

.gitea/workflows/deploy.yml

Файл можешь обозвать как угодно.

name: Build and Deploy Bashdays Blog

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: super-runner
    container:
        image: catthehacker/ubuntu:act-22.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies and build
        run: |
          pip install -r requirements.txt
          mkdocs build

      - name: Deploy to Server
        uses: https://gitea.com/aquelle1/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc -i --delete" 
          SOURCE: "site/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Давай пробежимся:

Триггер on: push: запускается если что-то запушено в ветку main.

Почему в main а не в master? Читай тут.

Следом запускается джоба build на раннере super-runner, не забываем зарегать себе раннер, без него нихуя не получится.

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

Дальше используем адаптированный контейнер с убунтой 22.04 специально адаптированный под тестирование GitHub Actions через act.

Почему GitHub Actions? Потому что gitea унаследовало синтаксис и пайплайны в теории могут переносится между системами.

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

Потом идут шаги speps, клонируется репозиторий с проектом в контейнер, устанавливаются необходимые зависимости через «пипку», ну и билдится финальная статика.

После сборки идет секция с деплоем, я использую этот экшен. Основан он на rsync поверх ssh.

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

SSH_PRIVATE_KEY = Приватный ssh ключ с которым раннер пойдет на твой сервер и подключиться по ssh к нему. Соответственно публичная часть ключа должна быть прописана у пользователя на сервере в файле ~/.ssh/authorized_keys.

Как работать с ssh ключами, читай по тегу #linuxfactory

ARGS = Аргументы для rsync, рекурсивное копирование, сохранение прав доступа, удаление файлов которые не в локальной версии.

SOURCE = Какой каталог со статикой отправляем. В Mkdocs статика генерится по умолчанию в папку site.

REMOTE_HOST & REMOTE_USER = Айпишник или домен продакшена на который деплоим + имя пользователя под которым подключаемся к серверу.

TARGET = В какую папку на проде скинуть содержимое папки site.

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

Вот и всё. Теперь при пуше в main ветку, автоматически запустится пайплайн и на прод выкатятся изменения.

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

Короче хорошего тебе вечера, теперь уже до завтра!

tags: #devops #cicd
—
🔔 @bashdays➡️ @gitgate

Привет, один из наших подписчиков попросил анонсировать его пепяку. Она уже пролетала в gitgate, но ничего страшного, пусть и тут полежит. Тем более штука маст-хэвная.

TENV Ёпта!

Если кратко, TENV это консольный менеджер для управления версиями Terraform, Terragrunt, OpenTofu, Atmos.
ㅤ
TENV написан на гошке, не требует дополнительных зависимостей и может быть запущен под любой операционкой. Удобно чё.

Ты скажешь — блядь, да есть же например tfenv и asdf, зачем очередной велосипед?

Во-первых, автора TENV зовут Александр, а не «Аннадурай Сатьямурти Чидамбарампиллаи». А это уже о чем-то говорит!

Ну и, во-вторых, все эти утилиты не поддерживают OpenTofu, Terragrunt и т.п. К тому же, требуют много консольных костылей/зависимостей и хуёва работают НЕ на Linux.

asdf не поддерживает автоматическое переключение версий на базе спецификации версии Terraform / OpenTofu внутри проекта с помощью HCL файлов. В целом, asdf скорее переключалка по запросу, а tenv более заточен под OpenTofu/Terraform проекты.

Установка:

LATEST_VERSION=$(curl --silent https://api.github.com/repos/tofuutils/tenv/releases/latest | jq -r .tag_name)
curl -O -L "https://github.com/tofuutils/tenv/releases/latest/download/tenv_${LATEST_VERSION}_amd64.deb"
sudo dpkg -i "tenv_${LATEST_VERSION}_amd64.deb"

Сейчас лично потыкал, всё работает как часики. После установки запускаем tenv, выбираем из списка (стрелочками и на пробел) что установить и жмем ENTER.

НО, так как хашикорпы — письки (This content is not currently available in your region), в РФ надо трафик прогнать через одно место, чтобы вытащить бинари терраформа.

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

Александр, добавь для нас такую возможность, буду прям лично твоей штукой пользоваться, достаточно удобно!

В общем рекомендую потыкать и поддержать проект звездами. Годнота!

➡️ Страница проекта и документация

tags: #utilites #devops
—
🔔 @bashdays➡️ @gitgate

Proxmox post install in 2025 (часть 1)
ㅤ
Давай разберемся, что нужно сделать после установки proxmox.

Как вариант сразу накатить эту штуку Proxmox VE Post Install, но процесс не прозрачный.

Наш путь — это всё сделать ручками, чтобы было понимание и контроль над процессом.

Для начала пиздуем сюда:

/etc/apt/sources.list

И добавляем дополнительные репозитории:

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
deb http://security.debian.org/debian-security bookworm-security main contrib

Затем отключаем интерпрайзный репозиторий в файле:

/etc/apt/sources.list.d/pve-enterprise.list

В нем комментируем одну строчку:

# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Следом отключаем платный ceph, идем в файл:

/etc/apt/sources.list.d/ceph.list

Комментируем и добавляем халявную репу:

# deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise
deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription

После этого выполняем:

apt update && apt upgrade
reboot

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

Дальше выполняем в терминале proxmox:

sed -Ezi.bak "s/(Ext.Msg.show\(\{\s+title: gettext\('No valid sub)/void\(\{ \/\/\1/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

Эта команда отключит No valid subsciption, сообщение о том, что у нас отсутствует подписка на интерпрайз. Довольно нозящая и заёбистая тема.

Чтобы изменения вступили в силу, скинь кэш в браузере. Всё, больше это информационное окошко тебя не побеспокоит.

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

Этот момент рассмотрим во второй части (завтра в 14:13 МСК залетит, пост в отложке), там похитрее всё.

🛠 #proxmox #devops
—
✅ @bashdays / @linuxfactory / @blog

Proxmox post install in 2025 (часть 2)

Такс, следующим этапом после установки proxmox необходимо настроить проброс реальных устройств в виртуальные машины.
ㅤ

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

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

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

Открываем на редактирование файл: /etc/default/grub

И правим GRUB_CMDLINE_LINUX_DEFAULT, должно получиться так:

Если у тебя Intel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on pt=on"

Если у тебя AMD

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on pt=on"

iommu=on — включает IOMMU (Input-Output Memory Management Unit) для процессоров. Этот механизм позволяет изолировать устройства ввода-вывода, повышая безопасность и управление памятью.

pt=on — включает поддержку PCI passthrough для виртуализации, позволяя передавать устройства (например, видеокарты или другие PCI-устройства) непосредственно в виртуальные машины.

Сохраняем изменения и обновляем загрузчик:

update-grub
reboot

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

Загружаем модули:

Открываем на редактирование: /etc/modules

И прописываем:

vfio
vfio_iommu_type1
vfio_pci

С версии ядра 6.2 модуль vfio_virqfd больше нахуй не нужен.

Сохраняем и запускаем:

update-initramfs -u -k all
reboot

Здесь обязательно нужен ребут, без ребута нихуя НЕ заработает!

Проверяем:

dmesg | grep -e DMAR -e IOMMU or dmesg | grep -e DMAR -e IOMMU

И ищем строчку: Interrupt remapping enable

Если нашел, то поздравляю, у тебя всё получилось! Если же нет, то еще раз внимательно выполни все шаги и не забудь про ребут.

На закуску

Чтобы изолировать GPU карточку от хостовой системы, нужно еще с бубном побегать.

lspci -nn

Узнаём ID карточки, а дальше подставляем этот ID в эту команду:

echo "options vfio-pci ids=10de:____,10de:____ disable_vga=1" > /etc/modprobe.d/vfio.conf

И пиздярим блеклисты:

echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf 
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf 
echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf 
echo "blacklist nvidiafb" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia_drm" >> /etc/modprobe.d/blacklist.conf
echo "blacklist i915" >> /etc/modprobe.d/blacklist.conf

Ну и само собой отправляем proxmox в ребут.

Проброс HDD

ls -n /dev/disk/by-id/

Узнаём ID диска и выполняем команду:

/sbin/qm set [VM-ID] -virtio2 /dev/disk/by-id/[DISK-ID]

Вот и вся наука. Всё лично протестировано и работает как часы, включая проброс видюхи.

Если есть чего добавить, велком в комменты.

🛠 #proxmox #devops
—
✅ @bashdays / @linuxfactory / @blog

Бомбардиро крокодило!
ㅤ
Я выспался, можно продолжать радовать вас всякой «нужной» хуйней.

Давно про nip.io ничего не слышал, но всё чаще встречаю его у ребят с Linux Factory.

Суть этого сервиса — автоматически разрешать поддомены в IP адреса без необходимости поднимать свой DNS сервер.

Сейчас как мы делаем, локально редактируем файл /etc/hosts, прописываем в него какие-то свои локальные айпишники на вымышленные домены.

Например:

192.168.0.10 nginx.local
192.168.0.11 grafana.local

И если перейти по адресу nginx.local попадаешь на виртуалку с айпишником 192.168.0.10. Это всё очевидно.

Но опять же как оказалось про манипуляции с hosts файлом многие не знали.

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

Вот и прописываешь себе в hosts этот домен, указываешь айпишник нового прода, идешь тестишь, если все ок, то меняешь A запись.

Вернемся к nip.io, суть там такая же, прописываешь айпишники и нужные домены и по итогу получаешь такое:

nginx.192.168.0.10.nip.io → 192.168.0.10
app.192.168.0.11.nip.io → 192.168.0.11
test.192.168.0.12.nip.io → 192.168.0.12

Теперь открыв nginx.192.168.0.10.nip.io ты попадешь на 192.168.0.10 без редактирования своего hosts файла.

Давай потыкаем

У меня на IP 192.168.10.6 в локалке висит малина со всякими открытыми портами.

Пингуем:

ping 192.168.10.6.nip.io

В ответ я получаю такую картинку:

Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: 192.168.10.6.nip.io
Address: 192.168.10.6

Отлично, пинг прошел, вернулся локальный айпишник. То есть мы пинганули какой-то глобальный домен, а он привел нас на локальный сервис.

Теперь я направляюсь в браузер и открываю url:

http://192.168.10.6

Мне открывается стартовая страница nginx. Тут всё понятно и логично. А теперь давай сделаем так.

http://nginx.192.168.10.6.nip.io

Хуяк и видим предупреждение:

Для сайта 192.168.10.6.nip.io не поддерживается защищенное подключение

Ну клёвое же. Запрос прошел через глобальный домен и перенаправил запрос в мою локальную сеть. Без необходимости что-то прописывать в hosts файле.

Просто жмем «продолжить» и попадаем снова на стартовую страницу nginx.

Еще вариант с портами:

http://sync.192.168.10.6.nip.io:8384

На порту 8384 у меня висит syncthing и всё отлично открывается. То есть можно пробрасывать запросы через домен прям на порты или в докер контейнеры.

А можно прям кучу поддоменов плодить:

http://a.b.c.d.192.168.10.6.nip.io/

И всё будет работать.

А еще можно на такие домены получить SSL сертификаты, но у тебя должен быть белый айпишник.

sudo certbot certonly --standalone -d nginx.204.0.115.50.nip.io

Хуяк и у тебя готовый SSL для домена nginx.204.0.115.50.nip.io. Ну а если не хочется возиться с certbot можно воспользоваться алтернативами, например acme.sh или caddy.

Минусы nip.io:

1. Не поддерживает wildcards, но в большинстве случаев они избыточны. Инструмент заточен больше на удобное тестирование при разработке.

2. SSL работает только с публичными IP. Для 127.0.0.1.nip.io или 192.168.x.x.nip.io Let's Encrypt не выдаст сертификат.

У nip.io есть альтернативы: xip.io или sslip.io

В общем я показал, а тебе уже самому решать где это применить или не применить.

Хорошо тебе провести эти выходные. Ну а я пошел фиксить баги.
Увидимся!

🛠 #devops #networks
—
✅ @bashdays / @linuxfactory / @blog

У Hashicorp Vault есть прикольная фишка со встроенным ssh враппером и подписными ключами.
ㅤ
То есть ты не напрямую подключаешься к серверу:

ssh root@server

А подключаешься к серверу через сервер с Vault, получается что-то вроде бастиона. Vault подписывает ключи и запускает тебя в нужное место.

Настраивается эта штука так:

На сервере с Vault выполняем:

vault secrets enable -path=ssh ssh
vault write ssh/config/ca generate_signing_key=true

Создаём под это дело отдельную роль:

vault write ssh/roles/devops -<<"EOH"
{
  "allow_user_certificates": true,
  "allowed_users": "*",
  "allowed_extensions": "permit-pty,permit-port-forwarding,permit-agent-forwarding,permit-user-rc,permit-X11-forwarding",
  "default_extensions": [
    {
      "permit-pty": ""
    }
  ],
  "key_type": "ca",
  "default_user": "root",
  "ttl": "30m0s"
}
EOH

На сервере к которому хотим подключаться, делаем:

curl -o /etc/ssh/trusted-user-ca-keys.pem https://vault.bashdays.ru:8200/v1/ssh/public_key

Добавляем в конфиг /etc/ssh/sshd_config строчку:

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

И перезапускаем: systemctl restart sshd

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

export VAULT_TOKEN="token"

vault write -address='https://vault.bashdays.ru:8200' ssh/sign/devops public_key=@$HOME/.ssh/id_rsa.pub

Этой командой подписываем свой публичный ключ через vault сервер. В ответ получаем кучу всякой хуйни типа: serial_number и signed_key.

Сохраняем на локальную машину подписанный ключ:

export VAULT_TOKEN="token"

vault write -address='https://vault.bashdays.ru:8200' --field=signed_key ssh/sign/devops public_key=@$HOME/.ssh/id_rsa.pub > ~/.ssh/id_rsa_signed_key.pub

Смотрим параметры получившегося ключа:

ssh-keygen -Lf /Users/user/.ssh/id_rsa_signed_key.pub`

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

Теперь подключаемся:

ssh -i ~/.ssh/id_rsa_signed_key.pub -i ~/.ssh/id_rsa root@server

Ну и вишенка, подключаемся через враппер:

vault ssh -address='https://vault.bashdays.ru:8200' -private-key-path=~/.ssh/id_rsa -public-key-path=~/.ssh/id_rsa.pub -mode=ca -role=devops -user-known-hosts-file=/dev/null root@server

В этом случае подписывать ключ не обязательно.

Доступ к серверам контролирует Vault. Можно быстро накручивать необходимые права, забирать и отзывать ключи. Ну и там много чего еще можно сделать.

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

Что-то вроде центра сертификации, писал как-то отдельный пост на эту тему.

Нашел еще видос у пиндоса на эту тему, можешь визуально глянуть и проникнутся.

Такие дела!

🛠 #linux #devops
—
✅ @bashdays / @linuxfactory / @blog

Как оказалось многие испытывают неистовые жопные боли при настройке angie со встроенной поддержкой SSL сертификатов от Lets Encrypt.
ㅤ
Сегодня покажу как избавиться от боли и на лету получать SSL для angie. Без всяких там certbot и acme.sh. Довольно удобно реализовано.

Для чистоты эксперимента я взял чистый, прерываемый сервер, без nginx’ов и т.п. на базе Ubuntu 24.04.

angie это аналог nginx, но на стероидах, у меня он крутится на уроках для LinuxFactory и в блоге. Подкупил он меня нативной поддержкой LUA и кучей модулей включая авто-получение SSL сертов.

Устанавливаем angie:

sudo curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg https://angie.software/keys/angie-signing.gpg

echo "deb https://download.angie.software/angie/$(. /etc/os-release && echo "$ID/$VERSION_ID $VERSION_CODENAME") main" | sudo tee /etc/apt/sources.list.d/angie.list > /dev/null

sudo apt-get update
sudo apt-get install -y angie

Начиная с Angie 1.3.0, модуль ACME (http_acme_module) включён по умолчанию в основной пакет angie.

Открываем айпишник сервера в браузере и убеждаемся что все работает. Если всё заебись, получишь стартовую страницу angie. Дефолтная страница практически один в один повторяет дефолтную страницу от nginx.

Дальше у меня есть домен two.su который живет в Cloudfalre. В настройках DNS я прописываю A запись и указываю айпишник нового сервера. Весь трафик идет напрямую, без фильтрации самого Cloudfalre.

Конфигуряем angie на домен two.su.

Создаем файл two.su.conf в /etc/angie/httpd.d/ с таким содержимым.

    server {
        listen 443 ssl;
        server_name two.su www.two.su;

        acme letsencrypt;
        ssl_certificate $cert_letsencrypt;
        ssl_certificate_key $cert_key_letsencrypt;

        location / {
            root /var/www/html;
        }
    }

А в файле /etc/angie/angie.conf в секцию http добавляем:

    acme_client letsencrypt https://acme-v02.api.letsencrypt.org/directory;
    resolver 127.0.0.53;

    map $acme_cert_letsencrypt $cert_letsencrypt {
        ''       /etc/angie/ssl-self-signed/cert.pem;
        default  $acme_cert_letsencrypt;                                                            
    map $acme_cert_letsencrypt $cert_key_letsencrypt {
        ''       /etc/angie/ssl-self-signed/key.pem;
        default  $acme_cert_key_letsencrypt;
    }

Если angie у тебя работает в докере, то в resolver пропиши: 127.0.0.11.

Проверяем: angie -t и в ответ получаем:

angie: the configuration file /etc/angie/angie.conf syntax is ok
angie: configuration file /etc/angie/angie.conf test is successful

Полученный сертификат и соответствующий ключ будут доступны в конфигурации через переменные $acme_cert_<имя> и $acme_cert_key_<имя>.

Перезапускаем: systemctl reload angie

Если получил ошибку, закинь сертификаты заглушки в /etc/angie

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj "/C=RU/O=Bashdays/CN=LinuxFactory"

У меня никаких ошибок не возникло.

В папке: /var/lib/angie/acme/letsencrypt появились ключи и серты.

Захожу в браузере на two.su и вижу зеленый замочек. Что и требовалось доказать. SSL сертификат был автоматически получен и в дальнейшем будет автоматически продляться. Без всяких кронов, клиентов, API ключей и хуйни.

Единый сертификат будет получен для всех доменных имён, которые были перечислены в директиве server_name. А директива acme указывает, какой ACME-клиент должен использоваться.

Меня вся эта кухня полностью устраивает. Понятно дело есть Nginx Proxy Manager, но я привык работать без гуёвых штук и мордочек.

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

По крайней мере меня так учили и я с этим полностью согласен.

🛠 #linux #devops #angie #ssl
—
✅ @bashdays / @linuxfactory / @blog

Распространенный случай в пайплайнах, как ребята пишут в LF:

deploy:
  stage: deploy
  script:
    - ssh ${USER}@${HOST} "docker pull"
    - ssh ${USER}@${HOST} "docker down"
    - ssh ${USER}@${HOST} "docker up -d"
    - ssh ${USER}@${HOST} "....."

🔥 Как и обещал. С сегодняшнего дня в Linux Factory действуют летние скидки. Кто ждал, велком.

То есть на каждую команду, создается отдельная SSH сессий. В большинстве случаев у тебя всё будет работать, но порой можно наступить на грабли.
ㅤ
На сервере может быть установлены лимиты в ssh_config — MaxSessions, а плюсом еще работает Fail2ban или нечто подобное.

И по итогу пайплайн будет вечно делать хуйню, внезапно падать и т.п.

Что делать?

Передать команды в рамках одной сессии.

Например, так:

script:
  - |
      ssh ${USER}@${HOST} << EOF
      docker pull ...
      docker down ...
      docker up -d ...
      ...
    EOF

В YAML, конструкция | перед блоком многострочного текста указывает, как обрабатывать переносы строк. | означает: сохраняй все переносы строк, как они написаны.

Либо пропихать так:

script:
  - ssh ${USER}@${HOST} "docker pull ...; docker down ...; ..."

Но предпочтительнее первый вариант, он консистентный и более читаемый.

Учись сразу делать нормально и учитывать такие моменты.

Ну и с праздником тебя и твоих ребятишек!

🛠 #devops #linuxfactory #cicd
—
✅ @bashdays / @linuxfactory / @blog

Довольно частый вопрос с LF — Как жить с gitlab раннерами?

Да просто там всё. Если у тебя основная инфра в кубе, то в кубе и крутим.
ㅤ
Ну а если ламповые сервера, без всей этой кубовой хуйни, то вариантов не много.

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

Здесь важно раздуплить себе какой-нибудь гарбаж коллектор, либо башник в крону накидать.

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

Это хуёвая практика, на продакшене такого быть не должно. Лишь поэтому мы и поднимаем отдельный сервер под раннеры.

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

Раннеры можно зарегать на один токен:

Сервер 1

gitlab-runner register \
  --url https://gitlab.com/ \
  --registration-token ABCDEFG123456 \
  --executor docker \
  --description "runner-1"

Сервер 2

gitlab-runner register \
  --url https://gitlab.com/ \
  --registration-token ABCDEFG123456 \
  --executor docker \
  --description "runner-2"

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

Раннер 1

--description "runner-fast"
--tag-list "docker"

Раннер 2

--description "runner-slow"
--tag-list "docker"

В .gitlab-ci.yml у нас так:

build:
  script: echo "Building"
  tags:
    - docker

Задание пойдет на тот раннер, который раньше освободится. Если оба свободны — гитлаб рандомно сделает выбор, приоритетности нет.

Если важна приоритетность, можно поиграть в юните с параметром GITLAB_RUNNER_PRIORITY.

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

А как деплоить?

Тоже всё просто, ssh/rsync в помощь, раннер подключается к нужному серверу, например по ssh и выполняет все необходимые команды. Затаскивает новый докер образ, стопорит старый, запускает новый.

Как-то так:

deploy:
  stage: deploy
  script:
    - |
      ssh $SSH_USER@$SSH_HOST << EOF
        docker pull $IMAGE_NAME
        docker stop my_app || true
        docker rm my_app || true
        docker run -d -p 5000:5000 --name my_app $IMAGE_NAME
      EOF

Подключаемся под юзером из переменной $SSH_USER к хосту из переменной $SSH_HOST. Ну и запускаем команды.

Важно!

Если у тебя 100500 раннеров — ты с ними заебешься, поэтому на моменте регистрации, сделай себе табличку, пропиши в них теги раннеров и на каких серверах они у тебя живут. Опять же это можно сделать через ансибл-роль, либо скриптом генерить. Тут уже сам наколдуешь.

Основное рассказал, если что-то еще вспомню, накидаю. Если у тебя есть мысли, пиши в комментарии, будем обсуждать.

🛠 #devops #linuxfactory #cicd
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

GIT для девопс-инженера

Многих git пугает разнообразием команд, но 99% его функционала тебе никогда не пригодится. Это как MS Word или Excel, где ты используешь ну от силы 0000.1% всего задуманного в нём.
ㅤ
Да, разработчикам посложнее, надо разруливать мердж-конфликты, делать какие-то ебаные черепики и ребейзы. Но для программистов на yml, достаточно основной базы.

Стянул-закомитил-запушил. Не пушится? Похуй — push force!

Теорию по git опустим, ты и сам знаешь для чего оно всё нужно — для удобства.

Я к примеру в гите храню базу obsidian и совсем недавно это спасло все мои заметки. Я установил плагин для синка с seafile и оно мне нахуй всё стерло. У меня сука глаз выпал, овер 3к заметок проебало за секунду.

Но в гите у меня все это осталось, склонировал, восстановил. Бекап который однажды пригодился. Удобно.

К сути. Как я сказал выше, тебе достаточно базы:

git pull
git commit -m "ебал я вашу буравую, несите книжку трудовую"
git push

К этому можно еще добавить clone, checkout и init, но этим ты будешь пользоваться очень редко.

Как все работает в реальности

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

git clone git@git.bashdays.ru:shubin/obsidian.git

ВСЁ! Репа у тебя на руках.

Создаешь новую ветку от мастера:

git checkout -b 010825

И уже в нее говнокодишь. Когда говна достаточно, комитишь, делаешь пулл-реквест (мердж-реквест). После того как тимлид заапрувит твой реквест, правки вольются в мастер. А ветку 010825 можно закрывать.

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

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

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

А как настроить ключи и т.п. я писал много постов, поищи по тегу #linuxfactory

А тут разбирали почему порой главная ветка называется main а не master.

🛠 #git #devops
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Про яйца и балансировщик нагрузки

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

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

Это можно решить проще — например перенаправлять запросы случайно.

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

Какой-то замкнутый круг, печаль и говнище.

А чё делать?

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

Вроде мелочь, но работает этот подход прям заебись! И что интересно у этого подхода есть официальная формулировка — Power of Two Choices или «Сила двух выборов».

Почему это заебись?

На просторах есть задачка «яйца и корзины», в оригинале там конечно не «яйца», а шары.

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

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

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

Все просто! Тоже самое и с серверами:

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

Давай на котиках:

Представь, что у тебя есть куча серверов, и на четверти из них пришло по 4 запроса.

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

- Если я выбираю два сервера и беру менее загруженный — вероятность того, что оба окажутся с нагрузкой 4, уже всего 6,25% (1/16).

Получается, что вероятность перегрузки падает очень быстро. А дальше — ещё быстрее: чтобы нагрузка выросла до 5, 6 и так далее, нужно каждый раз «удачно» попасть в редкие перегруженные сервера, и шанс становится ничтожным.

Видишь, математика нужна не только бекендерам, но и в девопсе можно применить.

Что получаем на практике:

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

Такой подход - простой и элегантный. Как говорится — без хуйни!

Формулы и расчеты визуально можешь глянуть тут. Там как раз разбирается способ с яйцами, но уже с углубленной математикой и формулами.

Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).

Cuckoo hashing (кукушкино хеширование) — алгоритм разрешения коллизий значений хеш-функций в таблице с постоянным временем выборки в худшем случае.

Как реализовать в nginx

upstream backend {
    random two; # Power of 2 Choices
    server app1.bashdays.ru;
    server app2.bashdays.ru;
    server app3.bashdays.ru;
}

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

Этот же принцип используют, например, в cuckoo hashing (структура данных для хранения ключей).

Мотай на ус, глядишь сгодится в хозяйстве.

🛠 #devops #nginx
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Фиксим кривой Exit Code в docker

Во время работы с docker контейнером наткнулся на неочевидный код выхода (exit code).

Про exit codes (коды выхода) писал тут

ㅤ
Суть проблемы: Когда программа внутри контейнера падает с abort(), Docker возвращает неправильный код выхода. Вместо ожидаемого 134 (128 + SIGABRT), контейнер отдаёт 139 (128 + SIGSEGV).

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

Давай проверим:

#include <cstdlib>

int main() {
    std::abort();
    return 0;
}

Пишем Dockerfile:

FROM ubuntu:22.04

RUN apt-get update \
    && apt-get -y install \
        build-essential \
    && rm -rf /var/lib/apt/lists/*

COPY ./ /src/
WORKDIR /src/
RUN g++ main.cpp -o app

WORKDIR /
CMD ["/src/app"]

Собираем и запускаем:

docker build -f ./Dockerfile -t sigabort_test:latest .
docker run --name test sigabort_test:latest ; echo $?

А на выходе у нас код: 139.

В примере выше код выхода — 139 = 128 + 11, где 11 соответствует SIGSEGV (ошибка сегментации), а не 134 = 128 + 6, что был бы SIGABRT (аварийное завершение).

Чтобы это пофиксить, нужно захерачить хак:

CMD ["bash", "-c", "/src/app ; exit $(echo $?)"]

docker run --name test sigabort_test:latest ; echo $?
bash: line 1: 6 Aborted /src/app
134

После этого контейнер будет возвращать корректный код 134.

Вариант рабочий, но костыльный. Правильнее использовать ключ --init.

Если запустить контейнер с флагом --init, используя исходную команду CMD ["/src/app"], мы получим ожидаемый 134 код. Что нам и нужно.

docker run --init --name test sigabort_test:latest ; echo $?

134

Почему init все починил?

Давай копнём глубже. В Linux процесс с PID 1 (init) имеет нестандартную семантику сигналов:

- Если у PID 1 для сигнала стоит действие «по умолчанию» (никакого обработчика), то сигналы с действием terminate игнорируются ядром. Это сделано, чтобы случайным SIGTERM/SIGINT нельзя было «уронить» init.

- PID 1 должен забирать зомби-процессы (делать wait() за умершими детьми). Если этого не делать, накопятся зомби.

- PID 1 обычно пробрасывает сигналы дальше — тому «настоящему» приложению, которое оно запускает.

Когда мы запускаем контейнер без --init, приложение становится PID 1.

Большинство обычных приложений (на C/C++/Go/Node/Java и т.д.) не написаны как «инит-системы», они не настраивают обработку всех сигналов, не занимаются «реапингом» детей и не пробрасывают сигналы. В результате вылазиют баги.

Наш сценарий с abort() (который поднимает SIGABRT) упирается именно в правила для PID 1. abort() внутри процесса поднимает SIGABRT.

Для обычного процесса с PID ≠ 1 это приводит к завершению с кодом 128 + 6 = 134. Но если процесс — PID 1, ядро игнорирует «терминирующие» сигналы при действии по умолчанию. В результате стандартные ожидания вокруг SIGABRT ломаются.

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

На практике это может приводить к тому, что ты видишь 139 (SIGSEGV) вместо ожидаемого 134 (SIGABRT).

И тут проблема не в docker, а в том, что приложение неожиданно оказалось в роли init-процесса и попало под его особые правила.

Вот и вся наука. Изучай.

🛠 #docker #devops #linux #debug
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Как прокачать Minecraft сервер с помощью Angie

Накидал пост о том, как мы мигрировали minecraft сервер на выделенный сервер и защитились от ботов с помощью Angie, просто и эффективно.

Сюда по классике не влезло, всё в блоге 👇

Читать: https://two.su/bieb4

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