Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
Показати більше📈 Аналітичний огляд Telegram-каналу Bash Days | Linux | DevOps
Канал Bash Days | Linux | DevOps (@bashdays) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 23 782 підписників, посідаючи 5 701 місце в категорії Технології та додатки та 28 083 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 23 782 підписників.
За останніми даними від 22 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -224, а за останні 24 години на -6, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 26.21%. Протягом перших 24 годин після публікації контент зазвичай збирає 13.65% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 6 233 переглядів. Протягом першої доби публікація в середньому набирає 3 246 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 24.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як bashdays, linux, bash, docker, скрипт.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
Завдяки високій частоті оновлень (останні дані отримано 23 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
Поток “Kubernetes База” ➕ видеокурс “Мониторинг в Grafana” ➕ видеокурс "Ansible. Основы" ➕ видеокурс "Docker. Основы" 🔥70 000 ₽ (вместо 100 000 ₽) Промокод на скидку в боте до 20 сентября⭐️ОБНОВИЛИ ВЕСЬ КУРС в июле 2024 г. ✅Чему научим: - Основам работы с K8s, системой автоматизации развертывания, масштабирования и управления приложениями в контейнерах. - Запускать кластер, работать с базовыми абстракциями и подключать дополнительные компоненты - Запускать приложение в кластере, понимать принципы работы сети и настраивать CI/CD пайплан Старт потока 7 октября ➡️ 7 недель обучения ➡️ 63 часа практики ➡️ 5 встреч со спикерами ➡️ Итоговая сертификация 👉 Промокод и подробнее о курсе в боте Реклама ООО «Слёрм» ИНН 3652901451
Это пост изобилует грубыми и матерными выражениями и, в силу своего содержания, вообще не предназначен для просмотра лицам с нежной и хрупкой психикой.Всё бы хорошо, но в моменте пуша свеженького image docker в registry, я невзначай обнаружил, что в гитлабе его просто-напросто НЕТ! ㅤ Куда же он сука такая делся? В облачном есть, в self-hosted — хуй! Ну думаю щас галочку где-нибудь в настройках поставлю и все у меня получится. Перерыл всё что только возможно. Но гитлаб тот еще выблядок парижской потаскухи. Нет галочки… Хуй сосали на вокзале!
Да даже взять ситуацию перевода private репы в public.Кароче. Чтобы включить Container Registry, нужно зайти в конфиг
/etc/gitlab/gitlab.rb и…
Раскомментировать эту строчку:
gitlab_rails['registry_enabled'] = true
И после этого запустить:
gitlab-ctl reconfigure
gitlab-ctl restart
Пиздец, почему нельзя конфиг просто перечитать без перезагрузки всех сервисов и ожидания.
И о чудо! Заветный пункт меню Container Registry внезапно появляется. Тут и сказочки конец. НО НЕТ. При попытке зайти в этот новый пункт, получаем ошибку:
Docker connection error. We are having trouble connecting to the Container Registry. Please try refreshing the page. If this error persists, please review the troubleshooting documentation .Ебутся блохи в суматохе!!! Идем читать документацию!
Реестр контейнеров автоматически включается и становится доступным в вашем домене GitLab, если вы используете встроенную интеграцию Let's Encrypt.Fuck This Shit! Включаем поддержку Let's Encrypt в конфиге
gitlab.rb:
letsencrypt['enable'] = true
letsencrypt['auto_renew'] = true
Запускаем gitlab-ctl reconfigure && gitlab-ctl restart
Иииии… тадам, модуль registry запустился!
sudo gitlab-ctl status ok: run: registry: (pid 20114) 0sКвест успешно пройден, но мне пиздец как не понравилось! Поэтому сношу я этот sefl-hosted гитлаб к хуям и возвращаюсь в облачный. А на малинку пожалуй воткну gitea, надеюсь там такой хуйни не будет. Или будет? Ладно, в любом случае решение я тебе показал. Пользуйся! tags: #devops — 🔔 @bashdays➡️ @gitgate
Я себе в арсенал ее добавил, штука охуительная, при условии если знаешь зачем оно тебе и как этим пользоваться. Я пока не знаю, но обязательно разберусь. У хорошего девопса и бычий хуй веревка!Короче это хуйня на расте позволяет анализировать «Эльфов» (ELF бинарники).ㅤ - Статический анализ: изучение структуры бинарного файла, включая секции, сегменты, символы и релокации. - Динамический анализ: выполнение бинарного файла с отслеживанием системных вызовов и сигналов (strace/ltrace). - Извлечение строк: поиск полезных строк (например, паролей или URL) внутри бинарного файла. - Шестнадцатеричный дамп: просмотр содержимого файла в виде шестнадцатеричного кода с удобной визуализацией. Инструкция по установке тут, есть докеры-хуёкеры и т.п. Я собрал из исходников, делов 30 секунд:
cd /tmp
VERSION="0.1.0"
wget "https://github.com/orhun/binsider/releases/download/v${VERSION}/binsider-${VERSION}-x86_64-unknown-linux-gnu.tar.gz"
tar -xvzf binsider-*.tar.gz
cd "binsider-${VERSION}"
./binsider
➡️ Репка на гитхабе
➡️ Заценить на ютубе
Обязательно посмотри, рекомендую!
Ааа, еще всех вас с пятницей, хороших предстоящих выходных. Ну и самое главное — береги себя! Всех обнял 🙃
tags: #debug #linux #utils #utilites
—
🔔 @bashdays➡️ @gitgaterm и паре с find и зачищаешь ненужное гавно которое старше определенного времени.
А чо делать когда бекапы «правильно» заливаются в облако s3 по протоколу swift?
Там find с rm уже не прокатит. Можно конечно изгаляться, но я в рот ебал изобретать очередной велосипед.
Для этих целей отлично подходит rclone, кто бы блядь мог подумать.
Работает так:
/usr/bin/rclone --config ~/.config/rclone/rclone.conf \
--log-file /var/log/rclone-trasher.log \
-v delete selectel:backups/1c/ --min-age 3d --rmdirs
Показываем где лежит конфиг, конфиг представляет нечто такое:
[selectel] type = swift env_auth = false user = bashdays key = fuckyou auth = https://auth.selcdn.ru/ endpoint_type = internalПишем непотребства в лог файл, чтобы потом посмотреть что там в кроне навыполнялось. Указываем где чистим бекапы, задаем сколько бекапов нам оставить, в примере я оставляю за 3 последних дня. Бекапы у меня в каталогах по датам, добавляю ключик
rmdirs.
Вешаем на крон и идем дальше Я собрал докер имейдж, а контейнер вечно в ребуте либо вообще не запускается, чо делать и как отлаживать?Давай симулируем ситуацию и попробуем что-то с этим сделать. ㅤ Для начала соберем имейдж, это будет простой nginx + свой конфиг, который будет копироваться с локальной машины в имейдж. Создаем на хостовой машине пару файлов: Dockerfile:
FROM nginx:latest
WORKDIR /etc/nginx
COPY ./nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
nginx.conf
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name localhost;
location / {
return 200 'Hello, Docker!'
add_header Content-Type text/plain;
}
}
}
Собираем имейдж:
docker build -t my-nginx .
Ждем, на экране бежит куча всякого непотребства. Это нормально. Ждем…
Проверяем:
docker images
Ага, все ок, выплюнуло что-то вроде:
REPOSITORY TAG IMAGE ID CREATED SIZE
my-nginx latest b844ef77daa3 33 seconds ago 188MB
Запускаем:
docker run -d -p 80:80 my-nginx
Проверяем:
docker ps
Хуй там плавал. Ничо не стартануло… ошибок нет, куда смотреть?
Если контейнер вообще не запускается, то для начала смотрим логи:
1. Узнаем состояние контейнера:
docker ps -a
Видим хуй с маслом: Exited (1) 4 minutes ago
2. Смотрим логи:
docker logs --follow <id or name>
В <id or name> подставляем айдишник либо имя контейнера:
В логах видим ошибку:
invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:15
Вот! С ней уже можно работать. Получается мы посмотрели логи, даже для незапущенного контейнера. Пиздуем в nginx конфиг и видим, что в 14й строке проебали точку с запятой.
Дополнительно можно посмотреть коды выхода:
docker inspect <id or name>
Например, если код выхода ExitCode = 137, значит не хватило ресурсов, подкинь памяти и все взлетит. Наверное…
Это основные моменты отладки.
Ну а если контейнер все же запустился, но что-то не работает, сначала повторяем все вышенаписанное. Ну и дополнительно можешь подключиться к нему в интерактивном режиме:
docker exec -it <id or name> bash/sh
Подставляешь id/name контейнера и выбираешь шелл, частенько bash и коробки не установлен, поэтому как вариант запускаешь sh.
А для визуализации слоев используем утилиту dive
Установка dive:
DIVE_VERSION=$(curl -sL "https://api.github.com/repos/wagoodman/dive/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
curl -OL https://github.com/wagoodman/dive/releases/download/v${DIVE_VERSION}/dive_${DIVE_VERSION}_linux_amd64.deb
sudo apt install ./dive_${DIVE_VERSION}_linux_amd64.deb
Открываем имейдж на анализ:
dive <id or imagename>
Подставляем id или имя — ИМЕЙДЖА (не контейнера)
Смотрим, охуеваем, закрываем.
Еще можно глянуть конкретный файл в контейнере:
docker exec -it <id or name> cat /etc/nginx/nginx.conf
Либо скопировать его себе на локальную машину:
docker cp <id or name>:/etc/nginx/nginx.conf /tmp
Поправить и скопировать обратно в контейнер:
docker cp /tmp/nginx.conf <id or name>:/etc/nginx/nginx.conf
Перезапускаем контейнер с новым конфигом:
Прикол в том, что тебе не нужно билдить новый имейдж, ты делаешь правки прям в контейнере.
docker exec <id or name> nginx -s reload
Такие дела! Если знаешь еще хаки и способы отладки контейнеров/имеджей, пиши в комменты, будет полезно!
tags: #devops #debug #docker
—
➕ @bashdays ➕ @gitgateСтрелки, HOME, END... и особенно функциональные клавиши (F1-F12) генерят многобайтные коды.
3. Клавиши TAB ENTER SPACE вообще нихрена не выдают.
4. Коды нажатых клавиш зависят от терминала, который у вас эмулируется.
5. Очень много клавиш используется в качестве "горячих", поэтому их обработка производится раньше, чем их обработает bash.
В общем - если вы умный человек - не используйте bash для обработки функциональных клавиш.
А если похожи на меня - приведу функцию, которая помогает минимизировать проблемы.
Поскольку не все клавиши генерят печатные коды, я не придумал ничего более умного, чем конвертнуть коды в hex-последовательность. Поверьте, работать со строкой в 10 символов проще, чем с управляющими символами.
Понятней.
Программа более-менее обрабатывает совместное нажатие CTRL+, ALT+. Не обрабатывает нажатия нескольких клавиш.
#!/bin/bash
function GET_KEY(){
declare K1 K2 K=
declare -i i
read -rsn1 K1;read -rsn4 -t 0.001 K2
if [[ "$K1" != $'\x1b' ]];then
K2=
fi
K1="${K1}${K2}"
i=${#K1}
while ((i--));do
printf -v K2 "%02X" \"${K1:$i:1}\"
K=${K2}${K}
done
printf "%s" $K
}
clear
echo "TERMINAL="$TERM
KEY=1
while [ "$KEY" != "" ];do
KEY=$(GET_KEY)
echo $KEY
# echo -e "\x$KEY"
done
сохраните в файл key2hex.sh
chmod +x ./key2hex.sh
./key2hex.sh
Под закрытым текстом объяснения для начинающих.
Поскольку программа простая - сильно комментировать не буду.
read -rsn1 K1;read -rsn4 -t 0.001 K2 считывает 1 символ, потом возможно еще 4, но с малым временем ожидания. Если символ многобайтный - в буфере он уже есть.
Если символ начинается не с кода 1b (ESC) он должен быть однобайтным.
${#K1} -число символов в строке.
Далее в цикле while ((i--));do посимвольно преобразуем строку в hex, накапливая в переменной K
echo -e "\x$KEY" команда перевода hex в char привожу для примера.
Для прикола попробуйте выполнить программу в разных терминалах (LxTerminal и tty1) и посмотреть на F5.
Поясню, в tty1 можно перейти из GUI CTRL+ALT+F1, а вернуться обратно обычно ALT+F7
Ну, или не F7. посмотреть, куда возвращаться можно командой w . Даже маленькие разберутся.
В общем, терминал(ы) - штука сложная. И тот только теперь я начал немного понимать, нахрена нужна библиотека ncurses.
help read printf
man w printf
tags: #bash © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgateКак в gitlab registry чистить докер имейджы, а то там такая пиздец блядь каша после экспериментов.В gitlab есть встроенная херня, которая находится в Settings → Packages & Registries → Container Registry. Заранее не забудь выбрать нужный проект. Там есть раздел: Cleanup Policies, в нём нажимаешь кнопку Set cleanup rules иии видишь еще кучу какого-то гавна. Короче:
Run cleanup — выбираешь как часто запускать зачистку
Keep these tags — теги которые не нужно зачищать
Remove these tags — теги которые будем удалять
Remove tags older than — ну тут ежу понятно
В этих штуках работают регулярные выражения, примеры этих регулярок можешь глянуть тут.
Еще момент, если заполнить Keep these tags, то это даст протекцию тегам и даже если их прописать в Remove these tags имейджы не будут удалены.
Заполняешь, сохраняешь и оно автоматически будет тебе все подчищать.
✔ Дополнительные варианты зачистки:
- удаляешь мышкой в UI самого гитлаба
- удаляешь через API самого гитлаба (например баш скриптом)
- используешь утилиты типа regclient или docker-gc
Такие дела, надеюсь было полезно. Давай, хороших тебе предстоящих выходных и береги себя!
UPD: от Малахитовая Штукатурка
а еще можно так зачистить:
sudo gitlab-ctl registry-garbage-collect -m
tags: #devops
—
🔔 @bashdays➡️ @gitgatessh -i ~/.ssh/id_rsa user@xxx.xxx.xxx.xxx
Ключик можно автоматически добавлять в ssh-agent и тогда подключение будет выглядеть так:
ssh user@xxx.xxx.xxx.xxx
Чтобы это провернуть, прописываем в ~/.profile
if [ -z "$SSH_AUTH_SOCK" ]; then
eval $(ssh-agent -s) > ~/.ssh/ssh-agent
fi
ssh-add ~/.ssh/gitlab_rsa
ssh-add ~/.ssh/production_rsa
ssh-add ~/.ssh/home_rsa
Первый блок проверяет запущен ли SSH агент, а если нет — запускает его.
ㅤ
Второй блок добавляет нужные ключи в агент. Посмотреть все ключи в агенте можешь командой ssh-add -L, а удалить всё из агента можно командой ssh-add -D.
Вот и вся наука. Ну а теперь интерактивная часть.
Ну а чтоб тебе не скучно было, можешь написать башник и скинуть в комменты, который автоматически пробегается по всем ключам в папке ~/.ssh и добавляет их в агент.
Но учти что в этой папке могут быть косячные ключи, ключи с неправильными правами, да и всякие файлы вида config, known_hosts. Короче потребуется работа с эксепшенами.
Чей коммент с решением соберет больше всех реакций и будет заебись работать, закину приятный бонус. Поехали!
tags: #utilites #рабочиебудни #bash
—
🔔 @bashdays➡️ @gitgate
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
