Очередной распространенный вопрос - а схуяли нужно гитлаб изучать?
ㅤ
Почему не 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

[email protected]
[email protected]
[email protected]
[email protected]

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 [email protected]

Вуаля, я залетаю на сервер с подписанным 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 [email protected]

([email protected]) 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

🔥 Скрытые данные в эмодзи/символах

Тут некий деятель Paul Butler, запиздярил штуку, которая позволяет при помощи последовательностей ZWJ (Zero Width Joiner) закодировать в один эмодзи неограниченный объём данных.
ㅤ
Да чо далеко ходить, идем сюды, выбираем эмодзи или букву алфавита, пишем текст который нужно спрятать и готово.

Копируем получившийся эмодзи/символ и отправляем по назначению. На этом же ресурсе можно расшифровать, то что получилось.

Unicode представляет текст как последовательность кодовых точек — чисел, которым присвоено определённое значение. Каждая кодовая точка записывается в формате U+XXXX, где XXXX — это шестнадцатеричное число в верхнем регистре.

Для латинских символов каждой кодовой точке соответствует конкретный символ на экране. Например, кодовая точка U+0067 обозначает букву "g".

Однако в некоторых системах письма один видимый символ может состоять из нескольких кодовых точек. Например, символ "की" в деванагари формируется из кодовых точек U+0915 и U+0940, соединённых вместе.

Где можно применить?

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

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

В комменты закину такой смайлик на потыкать. Перешли себе в Избранное и от туда уже правой мышкой - копировать текст.

🅰️🅰️

➡️ Технический подробности глянуть тут.

➡️ Исходники кодера/декодера на гитхабе.

Надо на Bash такую пепяку сделать, ради прикола.

tags: #security #crypt
—
🔔 @bashdays➡️ @gitgate

Как обычно люди используют screen:

screen
cd /usr/local/sbin
./db_import.sh

И потом закрывают терминал, а скрипт db_import.sh продолжает где-то там шуршать и делать свои делишки.
ㅤ
Потом возвращаются спустя время и делают:

screen -list

3393.pts-3.dev (Attached)

screen -x 3393.pts-3.dev

или

screen -r 3393.pts-3.dev

Убеждаются что скрипт завершил свою работу, ну и выходят, порой даже не закрывая screen сессию (3393.pts-3.dev).

Чем отличается -r и -x

-r (resume) = подключаемся к сессии которая в данный момент отсоединена, то есть к ней не подключены другие юзеры.

-x (multi-user mode) = подключаемся к сессии к которой уже кто-то подключен, то есть несколько пользователей могут мешать друг другу в рамках одной сессии.

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

Но есть такой вариант:

screen -dmS имя_сессии bash /путь/к/скрипту.sh

dmS это параметры для запуска screen в фоновом режиме (detached mode) с именем сессии.

d = запускает сессию в отключенном (detached) режиме.

m = создаёт новую сессию, даже если она существует.

S = имя сессии

Команда выше создаст сессию screen и запустить скрипт в фоновом режиме. А самое главное отпустит терминал и ты сможешь дальше в нём работать.

И самая киллер-фича — после отработки скрипта, screen сессия автоматически закроется и после выполнения команды: screen -list список будет пуст.

Еще можно так:

screen -X -S "script0$scriptID" stuff "^C"

script0$scriptID = указывает на сессию с именем, здесь $scriptID это переменная, содержащая идентификатор или значение, которое будет подставлено в команду.

stuff = передаёт текст или последовательность символов в сессию screen, как если бы их ввел пользователь.

На закуску.

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

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

Все просто, прожимаем CTRL+A и затем «d». Ты отключаешься от сессии, переходишь в интерактивный режим с терминалом, а скрипт продолжает шуршать в фоне.

А как посмотреть выхлоп скрипта если сессия закрыта?

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

Буквально вчера увидел как инженер с утра запустил распаковку базы на сервере, через пару часов у него мигнул интернет, ssh сессия с сервером превратилась в тыкву! Начинайте сначала!

Если запускаешь на сервере что-то очень долгое и не хочешь быть к этому привязан, используй screen! Это мастхев для подобных процедур. По крайней мере сохранишь время и нервы.

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

tags: #linux #utilites #bash
—
🔔 @bashdays➡️ @gitgate

По умолчанию папка для временных файлов расположена в корне /tmp.

В некоторых дистрибах эта папка монтируется в память. Но если оперативки мало, а чья-то софтина активно пишет в нее, есть смысл перенести папку /tmp куда-нибудь на диск.

Ну а если папка /tmp лежит на корневом разделе, а на разделе нет места, то это тоже проблема.
ㅤ
Самый распространенный и быстрый вариант:

1. Смонтировать новый диск в /mnt/tmp
2. Прокинуть симлинкой /mnt/tmp → /tmp

Но в некоторых случаях софт упоротый и скажет — я ебал писать в симлинку, давай мне нормальный локейшен в /tmp.

Упоротый софт в моем случае была некая многопоточная конвертилка pdf файлов, которая раздувала папку tmp до — я ебёшь! И пока она не сделает свои дела, за собой не уберет.

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

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

Монтируют новый диск в /mnt/tmp

sudo mkdir /mnt/tmp
sudo chmod 1777 /mnt/tmp

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

Создаем файл и пишем в него: /etc/systemd/system/mnt-tmp.mount

[Unit]
Description=Mount tmpfs on /mnt/tmp

[Mount]
What=tmpfs
Where=/mnt/tmp
Type=tmpfs
Options=mode=1777,size=10G

[Install]
WantedBy=multi-user.target

Название файла не может быть любое, у нас есть путь /mnt/tmp в этом случае файл называем mnt-tmp.mount.

Если было бы /mnt/tmp/bashdays, то файл нам нужно обозвать mnt-tmp-bashdays.mount.

Ага, вот такие нюансы, иначе оно грязно выругается и нассыт тебе в глаз.

По юниту все интуитивно понятно, расписывать не буду.

А потом, как обычно:

sudo systemctl daemon-reload
sudo systemctl enable mnt-tmp.mount
sudo systemctl start mnt-tmp.mount

Да, чтобы процессы использовали новый каталог, в файле /etc/environment указываем переменную.

TMPDIR=/mnt/tmp

Не забываем применить:

source /etc/environment

Проверяем и зачищаем старье:

echo $TMPDIR
df -h /mnt/tmp
sudo rm -rf /tmp/*

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

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

Заголовок для привлечения внимания
ㅤ
А сегодня мы с тобой будем проверять на bash существует ли git репозиторий и есть ли к нему доступ.

В основе лежит команда git ls-remote, которая получает список ссылок (references) из удалённого репозитория.

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

Сразу к делу:

#!/bin/bash

# Проверяем, что указан репозиторий
if [ -z "$1" ]; then
  echo "Ошибка: Необходимо указать адрес репозитория."
  echo "Использование: $0 <адрес_репозитория>"
  exit 1
fi

REPO_URL="$1"

# Выполняем команду git ls-remote для проверки доступа
if git -q ls-remote "$REPO_URL" &> /dev/null; then
  echo "Репозиторий доступен: $REPO_URL"
else
  echo "Ошибка: Репозиторий не существует или нет доступа: $REPO_URL"
  exit 1
fi

Переменная окружения GIT_TERMINAL_PROMPT=0 отключает любые запросы ввода имени пользователя и пароля. То есть если репа запросит логин/пароль, то вернется ошибка (без ожидания ввода).

Чмодим на +x и запускаем:

./git-check.sh https://github.com/bashdays/only.git

Репозиторий доступен: https://github.com/bashdays/only.git

./git-check.sh https://github.com/bashdays/zalupka.git

Ошибка: Репозиторий не существует или нет доступа: https://github.com/bashdays/zalupka.git

Есть минусы, скрипт работает только с https ссылками (открытые репозитории), со ссылками вида git@ оно вернет ошибку если у тебя не будет добавлен в ssh ключ.

Обработать этот эксепшен можно как-то так:

#!/bin/bash

# Проверяем, что указан репозиторий
if [ -z "$1" ]; then
  echo "Ошибка: Необходимо указать адрес репозитория."
  echo "Использование: $0 <адрес_репозитория>"
  exit 1
fi

REPO_URL="$1"

# Функция проверки доступа
check_repo_access() {
  local url="$1"
  
  # Проверяем репозиторий с помощью git ls-remote
  if git -q ls-remote "$url" &> /dev/null; then
    echo "Репозиторий доступен: $url"
    return 0
  else
    echo "Ошибка: Репозиторий не существует или нет доступа: $url"
    return 1
  fi
}

# Определяем, является ли URL SSH или HTTP/HTTPS
if [[ "$REPO_URL" == git@*:* ]]; then
  # Если SSH, проверяем доступ через SSH
  ssh_host=$(echo "$REPO_URL" | awk -F':' '{print $1}' | awk -F'@' '{print $2}')
  if ssh -T "$ssh_host" &> /dev/null; then
    check_repo_access "$REPO_URL"
  else
    echo "Ошибка: SSH-доступ к $ssh_host не настроен или нет прав."
    exit 1
  fi
else
  # Для HTTP/HTTPS проверяем репозиторий
  check_repo_access "$REPO_URL"
fi

Где применить решать тебе, можешь взять этот концепт за основу и что-то своё накидать.

У меня кое-где в пайплайнах есть такие проверки, перед тем как делается git clone. Ну и еще есть парсер репозиториев, загоняешь ему список и он по нему проходится, мертвые репы пишет в файл.

В общем обычная рутина. Я принес, показал, а ты уже сам решай надо оно тебе или нет.

tags: #bash #git
—
🔔 @bashdays➡️ @gitgate

Первые восемь раз надежда все еще не была потеряна

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

А вечерком будем думать в комментах (пост в отложке) над ситуацией — всё пропало, я проебал потерял приватный ssh ключ.

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

Что делать если я проебал приватный ssh ключ?

Самое главное не ссать!

Если ты рядовой разработчик/qa/cto/шлюха, напиши своему девопс инженеру чтобы прописал новый публичный ключик.

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

Пусть знают с кем связались — бабуины прямоходящие! 🙈

Человек как меч, либо делает свою работу либо тупой.

Тебя конечно же проклянут, но спустя какое-то время ключик пропишут. Доступ к серверам восстановлен. Профит чо!

Это прям идеальный исход событий.

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

Пеню, все решаемо, напомню — не ссать!

Варианты решения:

➡️ Вариант №1

Если ты осел и у тебя все еще включен доступ по паролю, то зайди на сервер по паролю. Но в 99999999% ты пароль не записал, либо просто его не знаешь/проебал.

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

У Селектела и AEZA такая возможность есть.

Но с этим паролем ты сможешь войти только через KVM, то есть опять же через веб морду. Потому что если ты в ssh конфиге (на сервере) отключил вход по паролю, то через ssh root@server у тебя нихуя не выйдет.

Через KVM сразу можешь отредачить ssh конфиг и включить доступ по паролю, потом комфортно подключиться к серверу так ssh root@server и добавить свои новые ключики.

Это самый трушный вариант, но работает не всегда + иногда требуется перезагрузка сервера, а это не допустимо.

Про ssh ключи, конфиги и прочее читай по тегу #linuxfactory

➡️ Вариант №2

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

Тут все просто, заходим, прописываем новые ключики, меняем конфиги, восстанавливаем доступы.

➡️ Вариант №3

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

➡️ Вариант №4

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

Но также у меня есть и ноут (нет, не в тот что кот насрал), на ноуте я обычно работаю в сортире и созваниваюсь в постельке. На ноуте у меня тоже есть этот приватный ключик.

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

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

➡️ Вариант №5

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

Физический доступ к сервакам обычно редкость, но опять же в Селектеле я такое делал много раз через веб-морду, там прям есть пунктик — Rescue Mode. Про аезу не скажу (аеза нас читает, пусть прокомментирует), пока не приходилось с этим сталкиваться.

Минус — придется перезагружать сервер. Будет даун тайм и тебя за это очень быстро выебут (если это какойнить прод).

➡️ Вариант №6

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

Как говорится — Хуем в ладошку и вперёд в путь дорожку!

🙃 Если хочешь проникнуться Ансиблом/Гитлабом/Докером — велком в наш пантеон.

➡️ Вариант №7

➡️ А это твой вариант, напиши про него в комменты.

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

Спасибо за внимание и хороших предстоящих выходных!

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

Service или Systemctl?

Каждый стартует или стопает процессы как привык. Во времена динозавров когда еще не существовало systemd, всё сводилось к командам:

service apache restart

Сейчас мир изменился, появился systemd, но привычки остались прежними.
ㅤ
Теперь сервисами рекомендуется управлять через systemctl.

Но какая в хуй разница как управлять сервисам?

И service и systemctl выполняют по сути одно и тоже и ты по итогу получаешь ожидаемый результат.

На самом деле сейчас команда service это обёртка вокруг systemctl.

Давай убедимся:

strace -f service nginx restart 2>&1 | grep execve

По итогу ты получишь:

execve("/usr/bin/systemctl", ["systemctl", "restart", "nginx.service"])

То есть service обратился к systemctl и произвел перезапуск nginx.

А если глянуть исходник service:

cat /usr/sbin/service

То ты увидишь обычный bash скрипт в котором и происходит вся эта магия.

Если система использует SysVinit или Upstart (например, старые версии Debian, CentOS 6, Ubuntu 14.04), то service будет работать напрямую со скриптами /etc/init.d/.

По бест-практикам старайся использовать systemctl. Но опять же service никто не запретит тебе использовать.

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

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

Кроме systemctl и service есть такие штуки для управления процессами:

/etc/init.d/nginx restart
rc-service nginx restart
sv restart nginx
s6-rc -d change nginx
supervisorctl restart nginx

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

ps -p 1 -o comm=

Вот и вся наука.

А как ты рулишь сервисами? Как скуф или как современный молодой человек?

tags: #linux #debug #strace
—
🔔 @bashdays➡️ @gitgate

Щас бы яблочко куснуть, выпить пива и уснуть

На повестке сегодня проект PDFLinux.
ㅤ
Если коротко, то вот тебе pdf файл, открой его в браузере (на базе Chromium, Firefox) и у тебя загрузится Linux.

Нихуя се! А как так? В PDF файлах обычно размещаются статические документы, но также у pdf формата есть поддержка javascript. Дада, тот самый, который: 1+1=11.

Вот javascript и позволяет всё это проделать, но конечно же с ограничениями.

Помню в Adobe Acrobat там вот полная поддержка js была, вот это прям была кладезь для экспериментов.

Проект основан на эмуляторе RISC-V.

Запуск в браузере осуществляется через движок PDFium. А чтобы потыкать в интерактивном режиме, есть виртуальная клавиатура.

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

Пентестеры, берите на вооружение, возможно замутите свою pdf’ку, но уже с полезной нагрузкой.

Уточнение — с полезной, а не деструктивной, у нас не инкубатор черношляпых.

Разработчик кстати и Doom запихал в PDF, можно погонять тут.

Исходники и инструкции по сборке доступны в публичной репе на гитхабе.

Посмотри, мож придумаешь где применить.

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

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

Ну дак вот. Цепляю этот диск к 11й винде по USB иии… хуй там плавал!
ㅤ

Эт всё понятно, но я почему-то думал что в 2025 году винда научилась с таким жить. Не научилась.

Ну мыж с тобой не пальцем деланные, если есть wsl значит оно может ext4 теоретически прочитать.

Покопавшись некоторое время в куче говна и применив приёмчики от Чака Норриса мне удалось это победить.

Показываю!

Запускаем powershell, я запускал под суперадмином, хуй знает мож и от юзера прямоходячего сработает.

В павершеле пишем:

wmic diskdrive list brief

В ответ получаем список доступных дисков, в том числе подключенных по usb.

Caption DeviceID Partitions
WDC     \\.\PHYSICALDRIVE2 1
ADATA   \\.\PHYSICALDRIVE1 3          
WD10    \\.\PHYSICALDRIVE0 1

Заебись! Я вижу свой usb диск, зовется он PHYSICALDRIVE2.

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

Дальше. Если у тебя не стоит wsl, ставим:

wsl --install

Да, это все делаем в повершеле в винде. После установки запусти wsl с убунтой и задай пароль для рута, пусть там все инициализируется.

Если всё сделал правильно, запускаем:

wsl --mount \\.\PHYSICALDRIVE2 --bare

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

Ключ bare монтирует диск в "сыром" виде, без автоматического создания файловой системы или попытки её определения. Это полезно, если вы хотите работать с диском на низком уровне, например, для восстановления данных, анализа структуры диска или выполнения других операций, которые требуют прямого доступа к данным на диске.

Ага, примонтировали, ну и теперь идем в свою убунту которая в wsl кружится и делаем финальный маунт:

mount -t ext4 /dev/sdd1 /mnt/sdd

Папку /mnt/sdd нужно создать ручками. А раздел диска (sdd1) подсмотреть командой blkid.

Всё, usb винт успешно примонтирован в wsl убунты, файлы доступны. Теперь их можно копировать на ntfs и радоваться.

400 гигов с ext4 на ntfs копировалось 3 часа.

Хуй знает на сколько я изобрел велосипед, но поставленную задачку решил без всяких парагонов и прочего внешнего софта. ЗБС!

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

Вот те еще одна забавная игрушка — про компьютерного мастера, который за установку каждого драйвера берет по 100500к и ёбет всех вжопы!
ㅤ
PC Building Simulator 1-2

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

Любишь ковыряться с железками или хочешь научиться собирать компы? Игруля для тебя!

Учитесь чинить, собирать и настраивать компьютеры и стройте собственную империю. В игре более глубокая симуляция, улучшенный режим карьеры и новые возможности персонализации. Постройте величайший ПК в своей жизни из реалистичных комплектующих более 40 настоящих марок!

Что имеем:

1. Ебанутые клиенты
2. Проёбанные/спизженные детали
3. Неправильная диагностика
4. Во время ремонта всё сгорело
5. Поставщик прислал нерабочую хуйню
6. Уронил паяльник на яйца
7. Вендор ебет мозги и не оплачивает ремонт
8. Инженер забил хуй и забухал
9. Перманентный визит пожарников/налоговой
10. Пыль и тараканы
11. Клиент слился

И много другое…

Первая версия в стиме

Там как раз скидки под 80%. Но это нам ничего не дает, в РФ эта стимовская залупа не работает.

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

Ну и самое главное — берегите себя!

tags: #hardware #games
—
🔔 @bashdays➡️ @gitgate

Как не волноваться на собесах?

или зачем на самом деле нужны HRы?
ㅤ
Ответ простой — нужно иметь финансовую подушку. Тогда спокойно думаешь «ну не возьмут, так и в рот их ебать, по дороге домой возьму пиваса и потуплю в сериальчик».

А лучше просто иметь дохуя денег и никогда не ходить на собеседования!

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

Банально если пишут — знание кубера. Почитай что такое кубер, что такое поды, что такое helm. Чисто теорию.

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

Меня как-то спросили что такое - декоратор в питоне? А я ебу чтоли? Я на девопса иду!

Ответил честно — хуй знает, я к вам не питон писать пришел, а программировать на yaml.

Ямл макаки на острие атаки!

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

За прозрачность и честность, оффер в кармане!

Но это было раньше…

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

HRы далбаёбы зажрались! Они тупо проёбывают деньги компании, показывают видимость работы, жонглируют кандидатами. У них нет цели взять тебя, у них есть цель — подольше поискать, подольше поебать мозги.

В 99% случаев HRы вообще не шарят за айти.
🅰️🅰️

Беседовал ща с девочкой HR знакомой из крупного рекрутингово агентства, задал ей вопросы:

1. Я присылаю тебе резюме, что дальше?
2. Какие вопросы ты задаешь на собесе?
3. Как гарантировано устроиться к вам?

Больше вопросов задать не успел, она пиздец занятая, чаю сам себя не выпьет. Извини Лера, ты мне разрешила заинсайдить!

Ответы:

1. Ничего, когда ты первый присылаешь резюме на почту или делаешь отклик на ХЕХЕ, ты просто очередной лох из списка. Сопоставляем твоё резюме с вакансией. Если в вакансии прописано k8s, а у тебя в резюме нет этого слова — ты идешь нахуй! Хотя в компании нет этого самого k8s, а что это вообще?

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

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

3. Пока я не захочу, ты не устроишься!

Вот и кризис! Кризис создают некомпетентные HRы, которым это выгодно. За всех HRов естественно не говорю, есть и толковые, но их единицы.

План простой:

1. Выгоняем всех HRов нахуй на улицу
2. Повышаем ЗП девопсу/разработчику/qa или кто там еще
3. Даем им учетку на ХЕХЕ
4. Ставим задачу — найди толкового человека

Профит! Этот план лично испытал несколько раз, работает на 100500%, толковый человек находится за 1-7 дней, без хуйни и без ЗП на HRов.

Каков вывод? Правильно — HRы нахуй не нужны!

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

tags: #рабочиебудни
—
🔔 @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

Эпиграф: "А кому-то и Почты России лавры покая не дают."

🔤🔤🔥🔤🔤🔤🔤

Хочу поделиться болью и спросить совета у Народа.
ㅤ
Мы уже много лет нормально работаем с 1С серверами + Postgres на Linux.

Все стабильно работает. Архивы создаются и нормально восстанавливаются, но тут пришла БЕДА.

После обновления конфигурации, 1С начала очень сильно тормозить. Я лично не видел - но пользователи говорят, что скорость определенных операций упала в 3-4 раза.

Поговорили с коллегами и выяснили, что торможение происходит на Postgres, а на MS SQL работает нормально. Решили потестировть лично. Оказывается MS выпустила свой SQL для Linux.

Только я собрался разворачивать - 1с-ники говорят, что на сайте 1с написано, что 1с не работает с MS SQL for linux.

Ладно. Качаю MS SQL для Windows, поднимаю, настраиваю. Пытаемся создать базу на сервере 1с под linux и получаем сообщение, что сервер 1с тоже должен быть на Windows.

Я, честно говоря, не понял. В интерфейсе 1с сервера на linux возможность выбрать тип сервера MS SQL есть. А по факу (я не опечатался) нет.

Может мне кто-нибудь объяснить, что происходит?

— Почему приложения, которые раньше нормально работали начали тормозить?

— Почему тормозить начали только на Postgres?

— Почему 1с сервер на Linux может работать с Postgres и на Windows и на Linux, а с MS оба продукта должны быть на Windows"

— И главное - народ, что делать?

Может кто-то уже нашел решение данной проблемы.

Поделитесь мнением и советами в комментах.

tags: #вопросвзал
—
🔔 @bashdays➡️ @gitgate

Вот те очередная пепяка, которую я обнаружил в bash скрипте у коллеги. Сначала не понял, а потом как понял.

Называется — aria2.
ㅤ
Короче это консольная мильти-кончалка, поддерживает протоколы HTTP(S), FTP, SFTP, BitTorrent и Metalink. Реализована многопоточность и работает с чанками.

Видал да!

Авторы софтины обещают x10 к скорости скачивания даже если у тебя интернет работает как гавно и теряются пакеты.

Ну хуй знает, у меня и так интернет быстрый, попробую потом на 3g потестить.

Можно алиас сделать типа:

alias wget="aria2 -x 10 $1"

И заменить вегетину на эту вертихвостку c 10тью потоками.

Помимо скачивания, с помощью ключей можно чёрта накрутить, всякое сжатие, проксирование и т.п.

Больше инфы тут:

➡️ Официальный сайт
➡️ Репка на гитхабе

Потыкай, с виду штука годная, почти 40к звезд на гитхабе.

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