На GitVerse стала доступна среда разработки GigaIDE Cloud со встроенным AI-ассистентом

СберТех представил российскую облачную среду для разработки GigaIDE Cloud, встроенную в платформу для работы с исходным кодом GitVerse.

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

Также пользователи получили доступ к обновлённой версии интегрированной среды разработки GigaIDE Desktop, которую можно скачать на GitVerse. Десктопная версия стала стабильнее и производительнее, а еще добавились новые инструменты для анализа и навигации по элементам крупнейших фреймворков для Java.

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

Начать пользоваться GigaIDE Cloud — по ссылке

Читать полностью…

Заголовок для привлечения внимания
ㅤ
А сегодня мы с тобой будем проверять на 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

Читать полностью…

По умолчанию папка для временных файлов расположена в корне /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

Читать полностью…

Как обычно люди используют 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

Читать полностью…

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

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

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

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

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

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

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

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

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

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

🅰️🅰️

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

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

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

tags: #security #crypt
—
🔔 @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

Читать полностью…

Сегодня будем запирать врата ада.
ㅤ
Ситуация: Есть физический сервер, на нём торчит само собой 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

Читать полностью…

Вчера многие обратили внимание на конструкцию в 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

Читать полностью…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такие дела!

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

Читать полностью…

Очередные грабли на которые в 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

Читать полностью…

Здрасти мои хорошие!

Рассмотрим ситуацию — злодеи устроили нагрузочное тестирование и натравили на твой ламповый стартап какой-нибудь «яндекс-танк».
ㅤ
😲 Подключить DDosGuard или Кратор!

Эт я пеню, ценник на такие услуги — моё почтение, да и по функционалу там очень даже всё урезано. А cloudflare по регламенту компании запрещен. Замкнутый круг.

Ну так что делать то?

Да блядь nginx затюнить и отбить всю эту хуйню-муйню. Понятно дело оно особо при дидосах не спасет, но со сканерами и «танками» заебись справится.

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

Поехали настраивать.

Создаем файл /etc/nginx/conf.d/assholes.conf

geo $limited {  
    default 1;  
    192.168.1.1 0;  # Этот IP не лимитируется
    10.0.0.0/24 0;  # 10.0.0.0/24 тоже без ограничений  
}
  
map $limited $limit {  
    1 $binary_remote_addr;  
    0 "";  
}  

limit_req_zone $limit zone=bashdays:20m rate=200r/s; 

limit_req_zone - ключ для отслеживания запросов.

$binary_remote_addr - системная переменная nginx, внутри хранит ip адрес клиента.

zone=bashdays:20m - произвольное имя зоны, 20m это объём памяти в мегабайтах для хранения данных. В этой зоне хранятся данные о количестве запросов от каждого уникального клиента.

rate=200r/s - ограничение равное 200 запросов в секунды с одного ip клиента.

Для рейта есть такая табличка:

Сценарий                    rate      burst
-------------------------------------------
API с высокой нагрузкой     100r/s    200
Средний веб-сайт            50r/s     100
Анти-DDoS защита            10r/s     20
CDN или кеширующий прокси   500r/s    1000

тестируем так:

ab -n 1000 -c 50 http://bashdays.ru/
wrk -t4 -c100 -d10s http://bashdays.ru/

И смотрим нет ли ошибок 503 Слишком дохуя запросов и корректно ли отрабатывает лимит.

🅰️🅰️
Сука! А как рассчитать эту 20m памяти? Щаа…

Максимальное количество клиентов = размер зоны в байтах / размерзаписинаклиента

Пардон, хуйню сморозил, давай на котиках:

Пример расчёта для 20m (20 мегабайт = 20 × 1024 × 1024 = 20 971 520 байт):

20 971 520 / 128 = 163 840

То есть, зона 20m может хранить лимиты примерно для 163 тысяч уникальных клиентов одновременно.

А откуда взялось 128?

Как я написал выше nginx хранит каждого уникального клиента (ключ $binary_remote_addr или другое значение) в зоне, используя примерно 128 байт на запись.

Есть такая табличка:

< 20 000 = 4m
~80 000 = 10m
~160 000 = 20m
500 000+ = 64m

Да, еще можно настроить burst для резких пиков. burst позволяет временно превышать rate, прежде чем включится жёсткий лимит.

Например:

limit_req zone=bashdays burst=400 nodelay;

Клиенту разрешается до 400 мгновенных запросов, а затем он попадает в ограничение 200r/s.

nodelay означает, что первые 400 запросов проходят сразу, а потом начинается строгий лимит.

Теперь по мапингам и гео хуйне.

В первом блоке про гео:

1. Все пользователи получат $limited = 1 (по умолчанию).
2. Те, кто с 192.168.1.1 или из 10.0.0.0/24, получат $limited = 0 и не будут ограничены.

Во втором блоке про мапинг:

1. Если $limited = 1, то $limit = $binary_remote_addr (IP-адрес клиента).
2. Если $limited = 0, то $limit = "", и клиент не попадает в limit_req_zone.

Короче делаем что-то вроде белого списка и кто в него не входит — идёт нахуй! Надеюсь понятно объяснил.

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

location / {  
  limit_req zone=bashdays burst=10 nodelay;  
  try_files $uri $uri/ /index.php?$args;  
}  

Про burst и nodelay выше уже рассказывал.

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

location / {  
    limit_req_status 429;
    limit_req zone=bashdays burst=10 nodelay;  
    try_files $uri $uri/ /index.php?$args;  
}

Возвращаем 429 Слишком дохуя запросов, вместо стандартного 503.

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

➡️ Ну и сыпь в комменты свои варианты!

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

Читать полностью…

А у нас тут это — ssh_commander

Эта штука позволяет запускать команды по ssh на нескольких серверах одновременно.

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

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

В коробке много еще всяких фишек, посмотри на досуге ради интереса, авось в хозяйстве сгодится.

➡️ Проект на гитхабе

Заявлена поддержка винды, маков, хуяков.

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

Читать полностью…

Как проверить tar.gz без распаковки?
ㅤ
Да все просто, для начала создаем архив:

tar -czvf bashdays.tar.gz /etc

На выходе получаем годный bashdays.tar.gz. Теперь нужно проверить, что этот архив действительно годный и случайно не побился.

Для этого запускаем:

tar -tzf bashdays.tar.gz

Ключ «t» как раз и запускает необходимый тест. Если все хорошо, то команда вернет статус: echo $? ага выдаёт 0. Отлично!

Теперь ломаем архив:

truncate -s -10 bashdays.tar.gz

И после проверки получаем:

tar -tzf bashdays.tar.gz

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now

А echo $? ага выдаёт 2. Ага. Зная это ты можешь тестировать архивы без распаковки и затем заливать их например в s3.

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

gzip -t bashdays.tar.gz

Ну или банально распаковать в дев/нуль:

tar -xzf bashdays.tar.gz -O > /dev/null

Bash скрипт для проверки может выглядеть так:

#!/bin/bash

# Проверяем, передан ли аргумент
if [ $# -ne 1 ]; then
    echo "Использование: $0 <файл архива>"
    exit 1
fi

ARCHIVE="$1"

# Проверяем, существует ли файл
if [ ! -f "$ARCHIVE" ]; then
    echo "Ошибка: файл '$ARCHIVE' не найден!"
    exit 2
fi

# Определяем тип архива
if [[ "$ARCHIVE" == *.tar.gz || "$ARCHIVE" == *.tgz ]]; then
    echo "Архив '$ARCHIVE' определён как tar.gz"
    FORMAT="tar.gz"
elif [[ "$ARCHIVE" == *.tar ]]; then
    echo "Архив '$ARCHIVE' определён как tar"
    FORMAT="tar"
else
    echo "Ошибка: неподдерживаемый формат архива!"
    exit 3
fi

# Проверяем целостность архива
echo "Проверка содержимого архива..."
if ! tar -tzf "$ARCHIVE" &>/dev/null; then
    echo "Ошибка: tar.gz архив повреждён!"
    exit 4
fi

if [[ "$FORMAT" == "tar.gz" ]]; then
    echo "Дополнительная проверка gzip..."
    if ! gzip -t "$ARCHIVE" &>/dev/null; then
        echo "Ошибка: gzip-архив повреждён!"
        exit 5
    fi
fi

echo "Архив '$ARCHIVE' проверен: ошибок не обнаружено."
exit 0

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

chmod +x check_tar.sh
./check_tar.sh bashdays.tar.gz

Такие дела.

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

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

Читать полностью…

Хотите пиздатого девопса?

Отдаю вам в хантинг проверенного девопс-специалиста. Хантим на удалёнку, офис — мимо!

Если твой бюджет ниже 150к можешь даже не писать, а если ты деловой человек, то милости просим.

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

- Девопс ин де хаус
- Программист на yaml
- Широчайшие познания в aws
- Пайпы, ансиблы, докеры и вся байда
- Сети, роутинг, фаерволы
- Опыт работы в иностранных компаниях
- Часовой пояс? Наверное похуй!
- Linux, мониторинг, golang, java, bash…

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

Макс прошел LF и по его скиллам скажу так — моё почтение, снимаю шляпу! Работа на максимальный результат. Было бы у меня 150к я бы без раздумий забрал его кубы котам крутить.

А вы говорите кадровый голод. Собеседуйте, делитесь с HRами, личная рекомендация. Полное резюме скинет сам. 👇

Контакт с Максом: @neva_eva

tags: #HR #хантим
—
🔔 @bashdays➡️ @gitgate

Читать полностью…

Еще один частый вопрос с LF — а нужно ли менять дефолтный ssh (22) порт на какой-то другой?
ㅤ
Нет! Ну а нахуя? Сократить в логах количество записей про неудачные попытки подломить твой девственный сервак?

В логи ты ходишь — практически никогда! Тем более там logrotate работает и место диске сильно не забьется.

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

ssh -p2222 user@server

Охуеть как удобно! Ты скажешь - дак можно же в ~/.ssh/config все это прописать и всё вернуть на свои места.

Host bashdays.ru
    HostName bashdays.ru
    User user
    IdentityFile ~/.ssh/shuba
    Port 2222

Справедливо. Но зачем жертвовать своим удобством?

У тебя на серверах уже отключен вход по паролю, только ключи, рут тоже запрещен.

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

Да и боты сейчас умные, если они видят закрытый 22 порт, они сделают nmap -Pn, по итогу получат твой 2222 и продолжат долбиться.

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

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

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

- отключи вход по паролю
- перейди на ssh ключи
- запрети вход для рута

За всю свою практику я встретил только одну компанию, где меняли 22 порт на какой-то другой, но никакой смысловой нагрузки в этом не было. Так и так эту компанию подломили и спиздили базу данных.

Да, еще был компания, где 22 порт открывался через port knocking. То есть нужно было предварительно стукнуться на 3 определенных порта и если последовательность была соблюдена, то открывался 22 порт.

Ну тоже такое себе решение в ущерб удобства. Любят люди из пушки по воробьям стрелять.

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

Такие дела, изучай!

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

Читать полностью…

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

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

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

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

Читать полностью…

🚀 Инженерная команда нового облака МТС Web Services продолжает рассказывать о разработке сервисов платформы.
В третьем выпуске проекта Building the Cloud поговорим про новый Object Storage.

🔑 Вы узнаете:
● какую архитектуру выбрали для нашего S3-совместимого хранилища данных;
● как обеспечиваем масштабируемость и надёжность хранения;
● как мы реализовали слои данных и метаданных;
● как работает асинхронная репликация данных между дата-центрами, и как используем erasure coding

💡 Для тех, кто пропустил первые выпуски: мы уже рассказали о создании сервисов Compute и IAM. Посмотреть можно здесь.

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

📅 Дата: 3 марта, 11:00
🌐 Регистрация

Читать полностью…

Как развернуть приложение в кластере Managed Kubernetes on Bare Metal
 
20 февраля в 16:00 Selectel проведет воркшоп, где покажет, как с помощью готового сервиса Managed Kubernetes сделать выделенные серверы частью экосистемы облачной платформы. Обсудим лучшие практики использования нового сервиса Selectel Managed Kubernetes on Bare Metal и его преимущества: изоляцию ресурсов, повышение производительности и сокращение расходов на IT-инфраструктуру до 40%.
Покажем процесс создания и работы с кластером Kubernetes на выделенных серверах. Отдельно рассмотрим интеграцию продукта с такими облачными сервисами как:  Container Registry, Балансировщик нагрузки и Базами данных.
 
Воркшоп подойдет: DevOps-  и SRE-инженерам, разработчикам, системным администраторам, архитекторам, руководителям IT-проектов и всем, кто работает с Kubernetes
 
Смотрите программу и регистрируйтесь на воркшоп по ссылке
 
Реклама. АО «Селектел», ИНН 7810962785, erid: 2VtzqvhCJ5a

Читать полностью…

Посвящаю тебя в Куборыцари! 🐈⚔️

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

Пока вы в поисках такого человека, другие уже проходят «Kubernetes для разработчиков»: разрабатывают приложение под k8s и запускают его в кластере.

Как они этому учатся?

👉 80% времени — это практика, реальные задачи и работа со стендами.
👉 Постоянная поддержка — консультации экспертов на встречах и в общем чате.
👉 Финальный этап — сертификация, подтверждающая твои навыки.

Может, и вам пойти этим путём?

➡️ Старт — 3 марта.
➡️Забирайте место по ссылке

Реклама ООО «Слёрм» ИНН 3652901451

Читать полностью…

🔔 CI/CD: 90 минут практики от платформы до конвейера

20 февраля в 20:00 мы покажем весь путь CI/CD — от пустого проекта до работающей платформы. За 100 секунд — реальный запуск конвейера, а потом разберём каждый этап: пайплайны, тестирование, деплой, обработка ошибок и масштабирование.

Для кого открытый вебинар?

• DevOps-инженерам — разберётесь, как быстро настраивать CI/CD.
• Разработчикам — поймёте, как автоматизировать тестирование и деплой.
• Архитекторам — увидите, как строить отказоустойчивые CI/CD-процессы.

Спикер Кирилл Казаков — DevOps Lead в Simplinic.

⏺ Регистрируйтесь на урок прямо сейчас, чтобы не пропустить: https://vk.cc/cIHrTR

Посетителям урока отправим чек-лист по теме на e-mail.
Бонус: скидка на большое обучение «Инфраструктурная платформа на основе Kubernetes» для участников! Промокод Kuber_5 , действует до 28.02 для тех, кто пройдет вступительное тестирование на курс.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Читать полностью…

Использовать 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

Читать полностью…

Хочу стать DevOps-инженером. С чего начать?

➡️ С автоматизации, развертывания, масштабирования и управления приложениями в контейнерах, конечно же.

17 февраля Слёрм запускает новый поток курса «Kubernetes: База» для инженеров.

🔸Научим разворачивать инфраструктуру k8s, обслуживать кластер и его сервисы
🔸Подготовим к работе в DevOps-проектах
🔸Расскажем, как поддерживать k8s, находить неисправности и решать проблемы
🔸Покажем, как внедрить CI/CD, настраивать мониторинг и управлять контейнеризированными приложениями

Программа курса обновлена в июле 2024 года. Внутри:

👉 6 недель обучения
👉 73% практики и работы со стендами
👉 5 онлайн-встреч со спикерами
👉 итоговая сертификация

Узнать подробности и занять место на потоке — по ссылке ⬅️

Реклама ООО «Слёрм» ИНН 3652901451

Читать полностью…

Автопентест от Positive Technologies: запуск нового продукта

🔴 Хотите проводить пентесты, но нет возможности делать это постоянно?
🔴 Нужно быть уверенным, в том, что защита хорошо работает?
🔴 Необходимо выявлять бреши в безопасности, которыми злоумышленники могут воспользоваться в первую очередь?

Positive Technologies запускает новый продукт, который поможет решить эти задачи. PT Dephaze — это система, использующая тактики и техники реальных хакерских группировок для автоматической проверки возможности захвата критичных систем.

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

Регистрация на онлайн-запуск уже открыта.

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

Ждем вас 27 февраля в 14:00!

Читать полностью…

Хорошо смеётся тот, кто успел забронировать место на Deckhouse Conf 2025

Это день с продвинутым DevOps-комьюнити. С хардкорными докладами, кейсами по автоматизации инфраструктурных задач и безопасности. С полезным нетворкингом и общением с экспертами и коллегами.

27 марта в Москве.

Читать полностью…

Освойте Linux с Selectel
 
Вы начинающий DevOps-инженер, системный администратор или разработчик? Или только думаете над тем, чтобы начать освоение Linux?
 
Selectel запускает бесплатный курс «Администрирование Linux с нуля». Проходите в комфортном для себя темпе и проверяйте полученные знания на реальных задачах.
 
Чему вы научитесь:
 
– Управлять пакетами и обновлениями программного обеспечения
– Настраивать сети, SSH-соединения и мониторинг системы
– Управлять пользователями, файлами и правами доступа
– Работать с командной строкой Linux и основными утилитами
– Анализировать логи и устранять инциденты
 
Зарегистрируйтесь на курс «Администрирование Linux с нуля» по ссылке
 
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2Vtzqwgy3ek

Читать полностью…

Связываем облачные и необлачные ресурсы ⚡️

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

13 февраля облачный провайдер Cloud.ru расскажет, как организовать сетевую связность между виртуальными машинами разных VPC, а еще между облаком и on-premise инфраструктурой.

Что круто: это не лекция, а демо, где покажут, как работают разные сервисы сетевой связанности и объяснят, когда их применять. А после — ответят на ваши вопросы.

➡️ Зарегистрироваться можно здесь

Читать полностью…

❓ Хотите научиться запускать сайты на Linux с нуля?

На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.

💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.

⭐️ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.

⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.

👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://vk.cc/cIoj0b

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Читать полностью…

❔ Ваши релизы застревают на старте? Пора ускорить их до сверхзвука с Kubernetes!

CI/CD и GitOps — ваша формула успеха: автоматизация, стабильность, контроль. Все прямо в кластере!

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

Спикер Михаил Чугунов — ведущий DevOps-инженер.

⏺️Встречаемся 13 февраля в 20:00 мск. Участники получат скидку на большое обучение «Инфраструктурная платформа на основе Kubernetes».

👍 Регистрация открыта: https://vk.cc/cIfz0I

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Читать полностью…

Админы делятся на три категории:
ㅤ
1. Те, кто не делает архивы,
2. Те, кто уже делает архивы,
3. Те, делает и уже проверяет.

🔤🔤🔥🔤🔤🔤🔤

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

У меня на СХД валится куча разных архивов и их приходится проверять, чтобы ускорить процесс можно использовать gnu parallel. Мне так не удобно, потому что архивы шифрованные, причем пароли у них разные, удобнее проверять скриптом.

Вот тут Роман набросал рыбу, для использования многопоточности. Я немного упростил. (до 7 необходимыx строк)

#/bin/bash

declare -x PATH="/usr/local/bin:/usr/bin:/bin"
declare -i JOB_NUM=$(nproc)
declare  DELAY=0.5
exec >&2
for i in {1..50};do # это цикл по всем заданиям
  # это команда, выполняемая в фоне
  ( sleep $(($SRANDOM % 3 +1)); echo ${SECONDS}_sec ) &
  while [[ $(jobs -r -p |wc -l) -ge $JOB_NUM ]];do
    sleep $DELAY
    echo $i
  done
done
echo end loop
wait
echo TOTAL $SECONDS sec 

Ну, и небольшая пояснялка:

nproc - число "ядер"

DELAY - задержка между проверками окончания выполнения фоновых заданий. Если задание выполняется долго (проверка архива) - можно смело ставить 10-30 секунд.

exec >&2 перенаправили весь вывод на stderr. В реалном скрипте можно убрать. (Как и все echo).

for - основной цикл по списку всех заданий.

sleep $(($SRANDOM % 3 +1)) - собственно фоновое задание. В данном случае пауза 1-3 сек.

echo ${SECONDS}_sec - ввел для примера, чтобы показать, что команд в фоновом задании может быть несколько.

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

echo end loop - как только основной цикл закончился - скрипт можно завершать (но некоторые задания еще могут долго работать).

wait - ожидать окончания всех фоновых заданий.

echo TOTAL $SECONDS sec - время полного выполнения скрипта.

На данный момент все задания завершены. Можно отправлять лог.

man nproc wc
help exec jobs wait

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

Читать полностью…

Еще немного про отладку ssh ключей, но уже в контексте интеграции со всякими гитлабами/гитхабами.
ㅤ
Чтобы работать с приватными репами ты добавляешь в настройки гитлаба/гитхаба свою публичную часть ключа.

Хорошо если такой ключ один, запутаться особо негде.

Но что если добавлено 20-100 ключей?

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

Ты проверяешь, видишь в табличке «Заголовок» — gitlab-runner-1 и вроде всё хорошо, ключ прописан и в раннере его приватная часть есть. Чо за хуйня?

Тут нам и пригодится команда:

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa

Выполняем ее для ключа с которым подключаемся (работает и для приватной и публичной части одинаково).

И по итогу видим фингерпринт, отпечаток:

2048 MD5:03:62:23:ca:ce:1b:8c:ad:60:1f:66:16:05:43:d8:a7 shuba@server (RSA)

Сравниваем этот отпечаток с тем что прописан в гитлабе/гитхабе и видим что он НЕ совпадает.

А это значит что твой раннер использует не тот приватный ключ для подключения.

Фиксим и радуемся. Как фиксить? Прописать актуальную публичную часть ключа в гитлаб/гитхаб. Дело закрыто.

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

Читать полностью…