Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
Mostrar más📈 Análisis del canal de Telegram Bash Days | Linux | DevOps
El canal Bash Days | Linux | DevOps (@bashdays) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 23 810 suscriptores, ocupando la posición 5 710 en la categoría Tecnologías y Aplicaciones y el puesto 28 118 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 23 810 suscriptores.
Según los últimos datos del 15 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -195, y en las últimas 24 horas de -10, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 23.79%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 11.52% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 5 664 visualizaciones. En el primer día suele acumular 2 744 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 25.
- Intereses temáticos: El contenido se centra en temas clave como bashdays, linux, bash, docker, скрипт.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 16 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
- Каждому лектору в жопу по вектору - Лучше в жопу сунуть глобус чем у ЦУМА сеть в автобус - Если ты не голубой нарисуй вагон другойНовый бренд чтоль мутитиль - Сёледка под Шубой? Ладно хули, рутина. Дела, люди всем двором на LF идут, устраивают челеджи, кто на какой задачке вперед сдохнет )) Всех с пятницей, хороших тебе предстоящих выходных, ну и по классике — береги себя! 🛠 #рабочиебудни — 💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
New Encrypt Note, забиваешь туда пароль, подсказку. Создается исходный файл в формате mdenc, а не нативный mardown с расширением .md.
Внутри исходного файла json`чик вида:
{
"version": "2.0",
"hint": "My Hint",
"encodedData": "tH/epIAOSgeGQQtO7FTcM="
}
Что прикольно, ты можешь зашифровать не всю заметку, а только её часть либо критические данные в каком-нибудь пайплайне. Выделяешь эти данные и слева жмешь иконку — Ecrypt Selection.
Теперь этот файл .mdenc заливает в git и не зная правильного пароля хуй кто прочтет твою заметку, даже если её спиздят. Аналогично с заметками где ты зашифровал часть данных.
Шифрованная часть внутри заметки выглядит так:
🔐β 💡My Hint💡ls92E5jV+HlAfZMML== 🔐
Короче полет нормальный. Хер знает насколько сильный там энкрипт, но от лишних глаз эта штука защищает.
В одном из issue в репе есть комментарий — «I have reviewed the code and noticed that it uses AES-GCM with a fixed IV and a password-derived key.»
Ну и по коду могу сказать что работает примерно так:
⚪ Пользователь задаёт пароль для шифрования.
⚪ Ключ генерится на основе пароля, скорее всего это PBKDF2.
⚪ Шифрование проходит по схеме AES-GCM. Шифр AES, режим Galois/Counter Mode с поддержкой аутентификации (В коде есть тэг MAC).
⚪ Не уверен, но возможно используется фиксированный IV инициализационный вектор.
Автор плагина походу сам не знает, что он написал. Поэтому подстраховался и добавил в ридми — «Use at Your Own Risk», мол идите нахуй, если вас подломят я тут не причем.
Присмотрись, штука довольно полезная. В хозяйстве сгодится.
🛠 #encrypt #obsidian #utilites
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 BlogКстати потом следом пошел и еще одну компанию разъебал, давно хотел, тоже впарили услугу, но услугу не предоставили. Сегодня уже возврат упал на карточку.Как говориться — с миру по нитке. Не давай себя в обиду 😲 🛠 #рабочиебудни — ✅ @bashdays ✅ @linuxfactory ✅ @blog
Звучит хуёва, знаю, может ничего и не получится. Но я постараюсь применить все свои знания в маркетинге и поделиться с тобой. Да и это бесплатно для тебя. План надежный, как швейцарские часы.Все шаги буду подробно описывать, можешь повторять и глядишь сможешь выйти на пассивный доход. 😇🙂🙃😉😌😍🥰😘 😗😙😚😋😛😝😜🤪 🤨🧐🤓😎🤩🥳😏😒 😞😔😟😕🙁☹️😣😖 😫😩🥺😢😭😤😠😡
Кстати сегодня закинул пост про создание канала без наличия 10к подписчиков. Пока хак работает, так что не проебись.Если интересно понаблюдать за движухой, подписывайся, вместе веселее. Там и комменты глядишь подключим и лося выебем. Подписаться: Макс на Максимум
Можешь на ютубе глянуть, там обзорчики уже наснимали.🛠 #utilites #backup — ✅ @bashdays ✅ @linuxfactory ✅ @blog
transmission-daemon, и рулю в консоли через transmission-remote.
Сами понимаете, что каждый раз в консоли набирать transmission-remote да еще с ключами — кнопки сотрутся, поэтому пользуюсь алиасами.
И вот сегодня я накосячил с алиасом настолько знатно, что bash упал и я покинул чат. И после этого не смог подключиться по ssh.
Если бы я правил sshd_config, я бы, конечно, подключился двумя сессиями, и все восстановил. Кто ж знал, что правка .bashrc тоже опасна.
Думал уже придется лезть на чердак, снимать миниписюк и править файлы локально, но все оказалось гораздо проще. Оказывается есть даже два способа, чтобы поправить ситуацию.
1. Выполнить ssh user@host -t /bin/sh
Вместо /bin/sh можно указать любую оболочку (их примерный список можно глянуть в /etc/shells). Понятно, что оболочка должна быть установлена на удаленной машине.
2. Подключиться по sftp, скачать .bashrc, локально отредактировать и залить обратно.
В общем, все сработало нормально. Алиас исправил. Все работает.
А подключился бы, как положено, при правке важных файлов двумя ssh-сессиями. И не было бы этой статьи.
Кстати, использование именно первого пункта позволяет обходить тривиальные защиты ssh (типа скриптовой двухфакторной аутентификации или использование sleepshell для пользователя, которому только разрешен проброс портов), основанные на простой замене оболочки пользователя в /etc/passwd.
При выполнении скрипта, хакер уже аутентифицирован в системе, и может просто заменить оболочку.
🛠 #linux #ssh #fix
—
✅ @bashdays ✅ @linuxfactory ✅ @blog- set -u
+ set -euo pipefail
+ IFS=$'\n\t'
- readonly LOG_FILE="/tmp/crimsonhat_$(date +%Y%m%d_%H%M%S).log"
+ LOG_FILE="$(mktemp /tmp/crimsonhat.XXXXXX.log)"
+ readonly LOG_FILE
- run_with_progress() { local message="$1" shift log INFO "$message" if "$@" >/dev/null 2>&1; then return 0 else return 1 fi }
+ run_with_progress() {
+ local message="$1"; shift
+ log INFO "$message"
+ if "$@" >>"$LOG_FILE" 2>&1; then
+ return 0
+ else
+ return 1
+ fi
+}
- disk_type=$(lsblk -d -o name,rota | awk 'NR==2 {print $2}')
- primary_disk=$(lsblk -d -o name,rota | awk 'NR==2 {print $1}')
+ read -r primary_disk disk_type < <(lsblk -dn -o NAME,ROTA | head -n1)
...
- current_scheduler=$(cmd < "$scheduler_path" 2>/dev/null | grep -o '\[.*\]' | tr -d '[]')
+ current_scheduler=$(tr -d '\n' < "$scheduler_path" | sed -n 's/.*\[\(.*\)\].*/\1/p')
Хотя set -euo pipefail тут конечно спорный вариант, можно наступить на грабли.
pipefail заставляет конвейер возвращать ошибку, если любая команда в скрипте упала. Так что применив set -u автор обезопасил себя от неочевидных багов.Как концепт, вполне можно форкнуть и подсмотреть какие-то штуки, возможно в своих поделках тебе что-то сгодится. 🛠 #linux #tweaks — ✅ @bashdays ✅ @linuxfactory ✅ @blog
Про exit codes (коды выхода) писал тутㅤ Суть проблемы: Когда программа внутри контейнера падает с
abort(), Docker возвращает неправильный код выхода. Вместо ожидаемого 134 (128 + SIGABRT), контейнер отдаёт 139 (128 + SIGSEGV).
То есть контейнер маскирует реальную причину падения приложения. Соответственно дальнейший дебаг не имеет смысла, потому что код выхода не соответствует действительности.
Давай проверим:
#include <cstdlib>
int main() {
std::abort();
return 0;
}
Пишем Dockerfile:
FROM ubuntu:22.04
RUN apt-get update \
&& apt-get -y install \
build-essential \
&& rm -rf /var/lib/apt/lists/*
COPY ./ /src/
WORKDIR /src/
RUN g++ main.cpp -o app
WORKDIR /
CMD ["/src/app"]
Собираем и запускаем:
docker build -f ./Dockerfile -t sigabort_test:latest .
docker run --name test sigabort_test:latest ; echo $?
А на выходе у нас код: 139.
В примере выше код выхода — 139 = 128 + 11, где 11 соответствует SIGSEGV (ошибка сегментации), а не 134 = 128 + 6, что был бы SIGABRT (аварийное завершение).
Чтобы это пофиксить, нужно захерачить хак:
CMD ["bash", "-c", "/src/app ; exit $(echo $?)"]
docker run --name test sigabort_test:latest ; echo $?
bash: line 1: 6 Aborted /src/app
134
После этого контейнер будет возвращать корректный код 134.
Вариант рабочий, но костыльный. Правильнее использовать ключ --init.
Если запустить контейнер с флагом --init, используя исходную команду CMD ["/src/app"], мы получим ожидаемый 134 код. Что нам и нужно.
docker run --init --name test sigabort_test:latest ; echo $?
134
Почему init все починил?
Давай копнём глубже. В Linux процесс с PID 1 (init) имеет нестандартную семантику сигналов:
- Если у PID 1 для сигнала стоит действие «по умолчанию» (никакого обработчика), то сигналы с действием terminate игнорируются ядром. Это сделано, чтобы случайным SIGTERM/SIGINT нельзя было «уронить» init.
- PID 1 должен забирать зомби-процессы (делать wait() за умершими детьми). Если этого не делать, накопятся зомби.
- PID 1 обычно пробрасывает сигналы дальше — тому «настоящему» приложению, которое оно запускает.
Когда мы запускаем контейнер без --init, приложение становится PID 1.
Большинство обычных приложений (на C/C++/Go/Node/Java и т.д.) не написаны как «инит-системы», они не настраивают обработку всех сигналов, не занимаются «реапингом» детей и не пробрасывают сигналы. В результате вылазиют баги.Наш сценарий с
abort() (который поднимает SIGABRT) упирается именно в правила для PID 1. abort() внутри процесса поднимает SIGABRT.
Для обычного процесса с PID ≠ 1 это приводит к завершению с кодом 128 + 6 = 134. Но если процесс — PID 1, ядро игнорирует «терминирующие» сигналы при действии по умолчанию. В результате стандартные ожидания вокруг SIGABRT ломаются.
Ну а дальше вступают в силу детали реализации рантайма/сишной библиотеки, как именно контейнерный рантайм считывает статус.
На практике это может приводить к тому, что ты видишь 139 (SIGSEGV) вместо ожидаемого 134 (SIGABRT).
И тут проблема не в docker, а в том, что приложение неожиданно оказалось в роли init-процесса и попало под его особые правила.
Вот и вся наука. Изучай.
🛠 #docker #devops #linux #debug
—
✅ @bashdays ✅ @linuxfactory ✅ @blogНапример, мемы для @devopsina по сути набираются регулярно в отдельный топик. Каждый день редактор забирает трендовые видосы, обрабатывает их, повышает качество, делает из шакальных - нормальные, генерит в своей голове какие-то айтишные подписи. GPT не используем.У меня например там есть топик - Гитара, если натыкаюсь на что-то интересное, сохраняю туда. Потом когда появляется желание что-то изучить новое, иду в топик, выбираю что хочу поучить и развлекаюсь. Короче бери на заметку, эта штука у меня живет уже как 2-3 года. Первые год использовал в одну харю, а потом расшарил на сотрудников. Прижилось.
А еще в телеге есть чеклисты нативные и отдельный топик под это. Опять же когда надо что-то закупить, делаем общий чеклист и потом все это визуально видно, кто что закупил.Такие дела. Попробуй мож зайдет и ты наведешь порядок в своем хаосе. 🛠 #рабочиебудни — ✅ @bashdays ✅ @linuxfactory ✅ @blog
А сколько раз ты нарушил закон и репостнул из таких каналов мемчики?Чтобы тебя за жопу не взяли, я сделал все как требуется, все по правилам. Теперь ты можешь репостить и делиться этим с коллегами. Обезопасил твою задницу. Под эту тему все мы пошли и зарегистрировались в РКН, да, еще в 2024 году. В описании каналов и групп ты мог видеть ссылку на сайт госуслуг, который это подтверждает. Но большинство на это не обратило внимания. Зря. Я к чему, почти год ты сидишь в таких каналах и с удовольствием поглощаешь контент. А как только увидел A+ — бежать! Ничего же не изменилось, все что нужно, про тебя и так все давно уже знают. К 2026 году 99% площадок будут ходить с этой меткой, чтобы следовать закону, чтобы была возможность размещать партнерские посты и как-то конвертировать полезный контент в хлеб с маслом. Так что не ссы, если хочешь быть в безопасности — отключи у себя интернет, выкинь телефон и завернись в фольгу. Ну и обязательно почитай матчасть как все это работает изнутри. Для тебя ничего не изменилось. А для меня изменилось, стало больше геморроя с отчетностью, с дополнительными налогами и т.п. Но так или иначе я продолжу делать своё дело и буду делать его хорошо. Поэтому не устраивай бои с тенью и не будь «тревожным». Если живешь правильно и прозрачно, никто за тобой следить не будет. Не руби с плеча, разберись и думай своей головой, а не головкой персонажа, который нагнал на тебя жути в каких-то пабликах. Как-то так. Мотай на ус. Всех обнял! 🛠 #рабочиебудни — ✅ @bashdays ✅ @linuxfactory ✅ @blog
nmon, top/htop. nmon даже позволяет записывать данные в лог, и есть программа, которая позволяет генерить html с отчетами, но там все интегрально. По системе. А хочется по процессам.
Остановился на пакете sysstat. Это такой консольный zabbix. Он позволяет собирать статистику по процессам. Анализировать можно память, проц, диск, стэк. Причем по каждому PID в отдельности и прямо в консоли. В общем, все, что нужно. Для большего удобства я набросал скрипт.
#!/bin/bash
# 20251005
# apt install sysstat gawk
# работа с 9 до 18, запись с 8:30 до 18:30
# запуск через cron
# 30 8 * * * /root/work/stat/stat.sh &
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -i INTERVAL_SEC=10
declare -i COUNT=3600 # итого 10 часов
declare -i WEEK_DAY;printf -v WEEK_DAY "%(%-u)T"
declare LOG="$0_${WEEK_DAY}.csv"
pidstat -r -l -d -H -h -U -u $INTERVAL_SEC $COUNT |
gawk 'NR<4;$2=="usr1cv83"||$2=="postgres"{$1=strftime("%Y%m%d_%H%M%S",$1);print}'>"$LOG"
Он собирает статистику каждые 10 сек по двум пользователям postgres (PG) и usr1cv83 (1С) в csv-лог (разделитель пробел, но это можно исправить).
Поскольку лог текстовый, дальше его можно вертеть с помощью awk/sort или просто в LibreOffice Calc.
pidstat ключи:
-r - память
-l - командная строка процесса
-d - диск
-h - табличный режим
-H - время unix
-U - username
-u - проц
gawk ключи:
NR<4 - заголовок (легенда) из трех строк
$2=="usr1cv83"||$2=="postgres" - фильтрация по username
$1=strftime("%Y%m%d_%H%M%S",$1) - удобный формат времени.
LOG="$0_${WEEK_DAY}.csv" - Недельная ротация. По одному на день.
🛠 #debug #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
