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 791 suscriptores, ocupando la posición 5 701 en la categoría Tecnologías y Aplicaciones y el puesto 28 125 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 791 suscriptores.
Según los últimos datos del 18 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -216, y en las últimas 24 horas de -5, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 22.75%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 12.90% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 5 413 visualizaciones. En el primer día suele acumular 3 068 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 21.
- 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 19 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.
/etc/systemd/system/bashdays.service
[Unit]
Description=Bashday service
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/bashdays.sh
[Install]
WantedBy=multi-user.target
Тип сервиса = камшот, сервис будет запущен один раз и завершится после выполнения задачи. ExecStart = какой внешний Bash скрипт будем передёргивать. WantedBy = не обращай внимания, это базовый таргет.Теперь сам скрипт
bashdays.sh 👇
#!/bin/bash
unix_time=$(date +%s)
> /tmp/$unix_time
Скрипт будет создавать в папке tmp файл с именем равным Unixtime.
Проверяем:
systemctl daemon-reload
systemctl start bashdays
systemctl status bashdays
Всё, видим что все успешно отработало. А в папке tmp появился файл с именем 1713409747 (у тебя будет другое).
Так. Теперь нужно сделать таймер, чтобы запускать сервис в нужные промежутки.
Уже начинаешь понимать в какой блуд заводят таймеры?
Создаем файл /etc/systemd/system/bashdays.timer
[Unit]
Description=Bashdays timer
[Timer]
OnCalendar=*:*:00
[Install]
WantedBy=timers.target
Срабатывает каждую минуту. Запускаем:
systemctl start bashdays.timer
systemctl status bashdays.timer
Видим: Active: running + Triggers: bashdays.service
Поздравляю, ты добавил одну таску в «крон» через таймеры. Теперь в папке tmp каждую минуту будут появляться файлы.
Но это еще не всё. Нужно добавить таймер в автозагрузку:
systemctl enable bashdays.timer
А вот теперь всё, можно перезагрузить сервер и файлы в tmp продолжат создаваться.
Теперь смотри, в одном большом Интернет магазине, у клиента в кроне подвешено около 150 скриптов. Ладно, не скриптов, дергается консольная ларавелька с нужными php параметрами. Не суть.
Ну дак вот! Ты будешь создавать 150 сервисов + 150 таймеров?
Да это ЕБОБО! 300 файлов! И все это никак не группируется. Извините, но проще через нативный cron сделать.
Понятно дело, если у тебя 2 таски, то можно повыебываться с таймерами. Но для масштабных приключений, увы.
Тут либо автоматизацию пилить, либо ручками страдать.
✔️ Да, таймеры гибкие, это бест-практики, их можно тонко настраивать, их легче дебажить через journalctl -u bashdays.service.
Но в большинстве случаев они избыточны.
Я остаюсь преданным крону, но таймеры выбрасываю на помойку не буду, авось когда-нибудь пригодятся.
Тему таймеров я затрагивал ранее в этом посте, в нем мы разбирали как с помощью sshfs надежно замонтировать сетевые диски, чтобы они не отваливались.А ты используешь таймеры? Чо думаешь? tags: #linux #bash @ВАSНDАYS | BАSHDАYS.CОM
nginx.conf, птички поют, коты ебутся, весна!
Запускаю nginx reload, хм, ничего не изменилось… Лезу в nginx.conf, а в нем все мои локейшены, которые я добавил — apt install etckeeper git
cd /etc
git remote add origin git@github.com:bashdays/etc.git
В git репе в разделе Deploy Keys, добавляем public root ключик с галочкой Allow write access.
А затем применяем бест практику и пушим в мастер:
git push -u origin master
Всё Initial Commit почти со всем содержимым, запушен в репу. Красотища!
✔️ Но перед пушем не забываем поправить файлик .gitignore и добавить в него например всякие shadows и т.п.
Я этой хуйнёй не занимаюсь, ну спиздят у меня хеши паролей, да ради бога. Репа приватная. Да и на серваке у меня вход по паролям всегда отключен, только ключи.Ну а теперь пробуем отредактировать какой-нибудь fstab и добавить новую строчку. Добавил? Ок, запускай!
etckeeper commit "поправил fstab" && git push
Всё! Правки в git репе. Ну и по желанию всё это дело можно откатить, либо пачкой, либо один файл.
Делается так, смотрим список коммитов:
etckeeper vcs log --pretty=oneline
e36f279 (HEAD -> master, origin/master)
9c24a66 поправил fstab
c1ee020 Initial commit
Теперь откатываем правленый fstab:
etckeeper vcs checkout 9c24a66 /etc/fstab
Ееее! Откатилось. Ну и не забываем, что после отката нужно зафиксировать все изменения.
etckeeper commit "вернул как было"
git push
Вот и всё! Функционал etckeeper намного шире, я рассказал про основное и саму концепцию. А если будет интересно думаю ты и сам найдешь всю нужную информацию в гугле.
Вообще можно и через Bash скрипт такое размутить, не устанавливая никакой софт, но иногда проще сделать apt install чем отлаживать баги в своем коде.
Я как-то на коленке изобретал нечто подобное для nginx, писал в этом посте.Отслеживать изменения можно через incron и автоматически коммитить:
incrontab -e
/etc IN_MODIFY /usr/bin/etckeeper commit "modified $@/$#"
Incron запускает таски не по временным меткам, а по событиям.
Добавить больше нечего. Хорошего тебе дня!
tags: #linux #utils
@ВАSНDАYS | BАSHDАYS.CОMКогда мне давали подобные задачи, я честно говорил — я не буду это делать, потому что я ебал! Не я себя продаю, а вы пришли ко мне и позвали на собес. Поэтому не несите хуйню и давайте задачу связанную с моей будущей ролью. А если нет таких задач, извините, я пошел дальше мультики смотреть.Обычно после этого, оффер у меня всегда был в кармане. Ну любят они кандидатов с яйцами. Не все правда, но большинство. Диктуй свои правила, не нужно бояться этих рекрутеров, рви им
if [[ $(date +%u) -gt 5 ]]; then
echo 'А вот и нет! У меня выходной!'
exit 0
fi
Вот прям сейчас возьми и встрой это во все свои поделки на проде. И ни один крон не заставит их работать по выходным.
✔️ Скрипты тоже должны отдыхать!
С праздниками посложнее будет, но если добавить и их в логику, привязать например к производственному календарю, тогда тебя точно на ретроспективе похвалят и дадут пизды премию. Правда посмертную.
А если ты живешь в жопе мира, например в племенах Масаи и спишь под кустом, естественно скрипт нужно немного адаптировать. Ведь у тебя выходные дни будут выпадать на другие дни недели. Учти это!
Ну красота же! Прям рубрика «Вредные советы» получилась. Экспериментируй.
tags: #linux #bash
@ВАSНDАYS | BАSHDАYS.CОMcore.xxx, порой их бывает прям дохуя. Обычно их все сносят и не задумываются чо это за высер такой.
А этот высер можно либо отключить, либо залезть в него рукой и поковырять. На самом деле все эти «Корки», очень полезный материал для изучения и отладки падающих приложений.
✔️ Что такое «Корки»
Нет это не порода собаки. Всё просто, это файл, который содержит дамп памяти процесса в моменте, когда он уебался. То есть произошел segmentation fault.
Имея этот файл на руках, можно запатчить, забагфиксить либо понять откуда растут ноги у ошибки.
Как включить core файлы.
Хуй знает. Обычно это делается через файл /etc/sysctl.conf, добавляем:
kernel.core_pattern=core
Либо из консоли брякнуть:
sysctl -w kernel.core_pattern=core
В этом случае, если процесс/программа уебалась, то в папке с этим приложением появится файл core.xxx.
Важно! Выполняем:
ulimit -c
Если вернуло 0, то хуй те, а не «корка». Чтобы все сработало, выполняем команду:
ulimit -c unlimited
Так. У нас всё готово, по идее «корки» теперь будут создаваться. Если не создаются, то ты что-то сделал не так, либо в твоем дистрибутиве это делается иначе. Но я думаю это везде одинаково. Пробуй.
Пишем простой код на СИськах
#include <stdio.h>
int main() {
int *ptr = NULL;
*ptr = 10;
return 0;
}
Компилируем:
gcc -g -o bashdays bashdays.c
Ключ -g включает отладочную информацию. Без этого ключа хуй мы чо отдебажим.
В коде выше, я пытаюсь присвоить значение 10 по адресу, на который указывает указатель ptr, но ptr не инициализирован и содержит значение NULL. В попытке разыменования указателя на NULL мы получим segmentation fault.Сложно? Забей, нам важно понять как работать с «корками» и дебажить. Так. Запускаем бинарник.
./bashdays
Хуяк и словили Segmentation fault (core dumped). Видишь в скобках core dumped? ВОТ ОНО! Рядом с бинарником появился файл core.1302. Полезли копаться в этом высере!
Запускаем отладчик:
gdb ./bashdays core.1302
``
Происходит магия. Чето там бежит и льется. Без паники! Смотрим несколько последних строчек:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000563ebf37f13d in main () at coretest.c:5
5 *ptr = 10;
Тааак… и видим из-за чего была вызвана ошибка. Даже строчку показывает, которая справедлива для исходника, хотя мы смотрим бинарник.
Проверяем указатель ptr, вводим в отладчике:
(gdb) print ptr
$1 = (int *) 0x0
И видим что указатель ptr имеет значение NULL (0x0). Это и вызвало ошибку сегментации при попытке разыменования.
Теперь когда у нас есть эта инфа, мы знаем, что проблема заключается в попытке доступа к памяти по-нулевому указателю и можно это забагфиксить.
Самое простое решение, это добавить проверку и убедиться, что указатель ptr указывает на допустимую область памяти. Прежде чем разыменовывать его. Выделяем память для ptr с помощью функции malloc().
#include <stdio.h>
#include <stdlib.h>
int main() {
int *ptr = malloc(sizeof(int)); // выделяем память для указателя
if (ptr != NULL) { // если память выделена, присваиваем значение
*ptr = 10;
free(ptr); // освобождаем память
} else {
printf("Алярма! Память не выделяется\n");
}
return 0;
}
Вот и забагфиксили, компилируем, запускаем.
Ошибка сегментации исчезла. Улыбаемся и в очередной раз гордимся - какие же мы охуительные.
Но не достаточно! Чтобы прям вообще преисполниться, нужно запатчить бинарник через hex редактор.
Как это сделать, покажу совсем скоро, а то пост пиздец толстый получился.
У меня всё. Изучай.
tags: #linux #debug
@ВАSНDАYS | BАSHDАYS.CОMcd //
Опа-опа, нихуя!
user@server:/$ cd //
user@server://$
Видишь два слеша в промте? Поздравляю, дефлорация прошла успешно. Даже не нужно было вводить IDDQD, чтобы активировать «годмод».
И где это мы? user@server:/$ cd //
user@server://$
user@server:/$ pwd
//
Хм, понятнее не стало… Давай посмотрим что находится у нас в этом каталоге, делаем ls -la.
И что же мы видим? А видим мы содержимое корневой директории. Для чистоты эксперимента можешь запустить так ls -la /////// и получишь такой же результат.
Получается никакого секретного каталога нет? Получается так. Нас наебали? Что такое POSIX, писал в этом посте.И сделано это для исторической совместимости. Некоторые версии Unix во времена динозавров использовали пути вида:
//hostname/path для доступа к path на сервере //hostname.
Короче вся ответственность по двум слешам ложится на плечи дистрибутивов. И каждый дистрибутив в праве делать с ними всё что захочет.
Пример: если в Cygwin выполнить cd // а затем ls, получишь ошибку:
ls: reading directory '.': Permission deniedПотому что Cygwin использует корень из
// для определения //имени хоста/пути. А убунта с этим нормально уживается и выводит содержимое корневой директории.
А все что более 2х слешей, должно рерайтиться на один слеш. Такие дела!
Всех с пятницей и хороших выходных! Да и на выходные будут посты. На связи!
tags: #linux #utils
@ВАSНDАYS | BАSHDАYS.CОMPIGZ (Parallel Implementation of GZIP) - это утилита для сжатия файлов, которая использует параллельные вычисления для ускорения процесса сжатия данных.Ставится из репы:
apt install pigz, а где-то уже сразу установлен.
Давай затестим. Создаем 10ти гигабайтный файл.
truncate -s 10G bashdays
Запускаем тесты:
time gzip -k -c bashdays > /dev/null
real 0m46.590s
time pigz -k -c bashdays > /dev/null
real 0m8.535s
Хуясе да! PIGZ сжал 10гигабайт за 8 секунд. А gzip понадобилось аж 46 секунд. Разница ОЩУТИМА! Понятно тесты синтетические, но мне их достаточно.
Ради интереса открыл htop, всё верно. Gzip усирается на одном ядрышке. А «свиньи» сразу жрут всё с костями. Прекрасно!
✔️ Теперь pigz нужно подружить с tar
С этим все просто, через пайп:
tar cf - bashdays | pigz -k -c > bashdays.tar.gz
Либо как вариант через ключ --use-compress-program
tar --use-compress-program="pigz --best --recursive" -cf bashdays.tar.gz bashdays
Но мне первый больше нравится. А чтобы видеть прогресс, можешь запустить так:
tar cf - bashdays | pigz -k -c | pv > bashdays.tar.gz
Тут используется утилита pv, про нее писал в этом посте.
Короче pigz прям тема и гибко конфигуряется. Я в восторге. Например, можешь сказать ей чтобы использовала только 2 ядра и 2 потока. Почитай хелпину если интересно. Основное я тебе рассказал. Изучай.
Увидимся! Пойду адаптировать под свои бэкапы.
tags: #linux #utils
@ВАSНDАYS | BАSHDАYS.CОM1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. _BASHDAYS=$BASHDAYS
4. unset BASHDAYS
5. BASHDAYS=$_BASHDAYS
Пример выше, демонстрирует как это делают ВСЕ! Ну хуита прям полная. Никогда не делай такую блевотню.
Чо происходит:
1. Задали переменную (не доступна в подпроцессах)
2. Экспортировали (доступна в подпроцессах)
3. Скопировали переменную в другую (не доступна в подпроцессах)
4. Ансетнули первую переменную (не доступна нигде)
5. Задаем переменную (не доступна в подпроцессах)
А можно красивее? Конечно, для этого существует typeset.
Мне иногда кажется, что на любой самописный велосипед, найдется нативная утилита, которую можно найти в коробке.
Давай перепишем код:
1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. typeset +x BASHDAYS
1. Задаем переменную (не доступна в подпроцессах)
2. Экспортировали (доступна в подпроцессах)
3. Удаляем атрибут экспорта (не доступна в подпроцессах)
Красиво? Да охуенно! Избавились от говнища и добились желаемого.
Что значит доступна в подпроцессах?
1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. bash
4. echo $BASHDAYS
5. hello bashdays
6. exit
7. typeset +x BASHDAYS
8. bash
9. echo $BASHDAYS
10. хуй с маслом
В пятой строчке вывелось значение переменной, после запускаем bash внутри bash (подпроцесс), выводим переменную, а она пустая. Хотя если сделать exit, то переменная выводится.
Если совсем грубо — родительский процесс выводит переменную, дочерний нет. То есть export на глобальном уровне задает переменную, которая доступна в любых подпроцессах (дочерних).
Всё это справедливо для оболочки Bash, во всяких zsh и т.п. поведение может быть другое.
Есть альтернативы typeset
declare +x BASHDAYS
export -n BASHDAYS
Получим тот же ожидаемый результат. Что конкретно ты будешь использовать, это уже от твоих предпочтений зависит.
Typeset это альтернативный синтаксис для declare предоставленный для совместимости с другими оболочками. Я предпочитаю использовать именно typeset, привычка наверное.
Давай краба, изучай!
tags: #linux #bash
@ВАSНDАYS | BАSHDАYS.CОMhttps://bashdays.com/bashdays.sh запускается bash скрипт, который лежит на сервере в папке /tmp/bashdays.sh.
А зачем это нужно? Элементарно — чтобы запустить Bash скрипт!
Но никогда так не делай.
Чтобы подобное реализовать, тебе понадобится fcgiwrap либо lua. Из обычного nginx, который в коробке, это сделать невозможно. Политика безопасности, вся хуйня.
Я возьму fcgiwrap, не хочу компилить модуль lua. Если у тебя есть lua, можешь через него подобное реализовать. Примеры ниже.
Ставим врапер:
apt install fcgiwrap
Закидываем скрипт в /tmp/bashdays.sh
#!/bin/bash
echo "Content-type: text/html"
echo ""
echo "<h1>Hello Bashdays</h1>"
echo "<p>This is a test bash script.</p>"
echo "hello bashdays" > file.txt
В конфиге nginx городим локейшен:
location /bashdays.sh {
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME /tmp/bashdays.sh;
include fastcgi_params;
}
Заранее убедись что сокет fcgiwrap создался и лежит в нужном месте. На этом собственно всё. Да, надо сделать еще nginx reload.
Открываем https://bashdays.com/bashdays.sh и лицезрим «Hello Bashdays This is a test bash script.».
Но это еще не все. В папке /tmp появился файл file.txt. Как видишь все получилось. Дальше включай фантазию и твори.
Для lua это будет выглядеть как-то так:
location /bashdays.sh {
content_by_lua_block {
os.execute("/tmp/bashdays.sh")
}
}
Я этот код не проверял, он всяко не работает, на коленке накидал, но думаю главное тут суть.
Кстати через php наверное тоже можно башник дернуть, там сокет так же подкинуть и через «хуй-пизда-лопата» запустить скрипт.
Вообще промышлять таким - фу! Если ты кому-то расскажешь, то тебя выгонят ссаными тряпками. Всё чисто ради экспериментов. Изучай!
tags: #linux #nginx #bash
@ВАSНDАYS | BАSHDАYS.CОM
¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
