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), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
Да, когда ты будешь заливать файлы в своё облако, данные будут реплицироваться на все 3 сервера. Поэтому сервера рекомендую держать в разных регионах или вообще у разных провайдеров. Например, если сгорит один дата центр, то ты не проебешь свои данные. Удобно и надёжно. Ну и смотри в сторону дискового места, если на одном сервере выделил 50 гигов под бакет, то на остальных серверах выдели столько же, чтобы не возникало коллизий.Прицепом воткнем балансировщик нагрузки, чтобы по домену всё работало. И да, запускать будем в докере. Поехали настроим это безобразие. Демон докера надеюсь у тебя уже установлен, поэтому заострять внимание на этом не будем. Заходим на первый сервер и мутим мутки: Файл
compose.yaml:
services:
garage:
image: dxflrs/garage:v2.3.0
ports:
- "3900:3900" # S3 API
- "3901:3901" # RPC
- "3902:3902" # Web (optional)
- "3903:3903" # Admin API
volumes:
- ./garage.toml:/etc/garage.toml:ro
- ./meta:/var/lib/garage/meta
- ./data:/var/lib/garage/data
Думаю, вопросов не должно возникнуть. Банальный композник, порты я тебе все подписал. Версию гаража можешь глянуть в интернете, на момент написания статьи последняя v2.3.0. Да буква «v» тут важна и latest тут не канает.
Читать продолжение: https://two.su/3qjfl
🛠 #devops #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 BlogБаза данных — это сердце приложения, но самостоятельное администрирование быстро превращает заботу о нем в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.На вебинаре 28 апреля эксперт Cloud.ru разберет, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках. В программе:
▶️
сравнение managed- и self-hosted PostgreSQL;
▶️
ключевые метрики базы данных: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;
▶️
настройка автоматического резервного копирования и политики восстановления данных;
▶️
реализация схемы разделения трафика на чтение и запись.На демо покажут, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении, и проведут нагрузочное тестирование, чтобы сравнить показатели до и после оптимизации. Зарегистрироваться
awk.
🔤🔤🔤🔤🔤🔤🔤
Не много осталось админов, которые парсят текстовые логи. Вся молодежь и даже пОдростки перешли на JSON. Ну да, это удобно. Но иногда awk быстрее. Особенно на больших файлах и файлах и простых фильтрах.
ㅤ
Но я сегодня не в настроении устраивать холивар.
При использовании логов очень часто возникает проблема — очень большое количество полей. А awk зачастую использует именно номер поля.
Так вот, чтобы немного упростить задачу я написал маленький скрипт, который разбирает строку и нумерует поля. Это здорово экономит время.
Сам скрипт:
#!/bin/awk -f
BEGIN{printf "INPUT field separator "
getline
FS=$0
printf "INPUT test line\n"
getline
printf "\n\n"
for (i=1;i<=NF;i++)print i, $i
}
Как обычно сохраняем fields.awk и делаем исполняемым:
chmod +x fields.awk
./fields.awk
Как это работает:
1. Сначала вводим разделитель.
2. Затем строчку лога и получаем разбивку по полям.
Ввод разделителя нужен, потому что иногда уже внутри кода приходится использовать оператор split и другой разделитель. Да и логи бывают разных форматов.
Рассмотрим такой пример:
<134>1 2026-04-17T16:51:47+03:00 OPNsense.internal filterlog 18074 - [meta sequenceId="2054702"] 111,,,4b75111111111111111111111111cb1d,eno1,match,block,in,4,0x0,,64,27367,0,DF,6,tcp,60,192.168.2.125,192.168.7.14,60248,22,0,S,1539242113,,65535,,mss;sackOK;TS;nop;wscale
В этом случае, если нужно одновременно вытащить и дату и IP с портами, проще в качестве основного разделителя использовать ",", а потом первое поле:
<134>1 2026-04-17T16:51:47+03:00 OPNsense.internal filterlog 18074 - [meta sequenceId="2054702"] 111
Здесь, если мы разбить по пробелам (split($1,f," ")), то f[2] будет содержать дату. Которую в свою очередь можно путем нехитрых манипуляций превратить в unuxtime, для удобства машинной обработки.
Всем кода без багов.
🛠 #bash #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 BlogЯ пользуюсь первым, как-то более интуитивно понятно правила настраиваются, в отличие от второго. Но тут больше вкусовщина, возможно ты оверхед монстр и спокойно стихи на регулярках перед сном читаешь своему ребенку.СТОП! Яж про другое… Пойдем дальше, на этом сайте я увидел рейтинги настройки серверов и вспомнил, когда я 100 лет назад поднимал инстанс с собственным mastodon сервером, я упарывался в безопасность и прям активно соблюдал эти рейтинги. Потом это всё забылось и сегодня решил проверить свой основной блог и мягко говоря прихуел. Мой социальный рейтинг по SSL был на уровне «D» — да вы батенька не девопс-инженер, вы пидор ебаный! Дела, дела! Надо это исправлять. Чё значит этот рейтинг? Сервис Mozilla Observatory смотрит не на код приложения, а на то, насколько правильно настроен твой сервер и заголовки безопасности.
A / A+ = всё настроено пиздато B / C = терпимо, но ты все равно долбаёб D / F = хуйня, переделать, серьёзные дыры, почти нет защитыКстати опять же пентестеры активно применяют это в своей работе, чтобы быстренько проверить безопасность конфигурации и по возможности найти лазейку к твоему шоколадному бекенду с последующим проникновением без вазелина. Если кратко — это линтер безопасности, а рейтинг всего лишь сводная оценка качества настроек и твоих компетенций. Основные категории проверки: 1. HTTP-заголовки безопасности 2. HTTPS и TLS 3. Cookies 4. Защита от известных атак Хули, давай это исправим, мне пришлось добавить такое в свою конфигурацию, чтобы добить рейтинг в более-менее вменяемую зону и получить заветную букву «B». Чтобы получить «A» мне придется немного перекроить работу с javascript, но пока мне лень. Собственно конфиг:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-src 'self' https://video.bashdays.ru https://t.me; connect-src 'self' https://api.rss2json.com https://bashdayz.ru;" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
⚪ Это защита от XSS атак и внедрения чужого контента. Я прописал доверенные сайты с которыми работаю. Но узкой дыркой осталось «unsafe-inline», с помощью него я разрешил inline JS, чтобы мои статусы из mastodon корректно передавались. Вот эту штуку и нужно будет допилить, чтобы получить text/plain, браузер мог бы «догадаться» и выполнить. Теперь хуй, ничего не выполнит.
⚪ Контролирует, что отправляется в Referer, хороший баланс приватности и аналитики.
Если подытожить, получаем — грузи ресурсы только отсюда, не доверяй подозрительной хуйне, всегда используй https и не давай сайту быть встроенным куда попало.
На этом собственно и всё, можешь пойти и проверить свои компетенции в настройке.
Поделись в комментах своим социальным рейтингом, хоть позавидуем.
🛠 #security #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blogecho first >first.txt
echo second >second.txt
ln -s first.txt second.txt
# Выведет: ln: cannot create symbolic link from 'first.txt' to 'second.txt': File exists
mount --bind first.txt second.txt
# А так работает.
cat second.txt
#Выведет first.
Наверное можно еще через cgroups замутить, или через eBPF понаделать хуки на системный вызов open, openat, туда же mount overlay...
🛠 #shitcode #bash
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 BlogРазбираем механику DNS Amplification атак и выясняем, почему использование ANY-запросов превращает твой сервер в инструмент для DDoS. Узнай, как работают векторы усиления трафика и как правильно настроить защиту на BIND и Unbound.В DNS есть такая прикольная штука, как ANY запрос, его суть — выдать тебе сразу все DNS записи по нужному домену. ㅤ Запрос вида:
dig chklst.ru ANY
Я встречал много Bash скриптов, которые на этом запросе завязаны, да чё греха таить, вчера буквально обратился товарищ (малваря-аналитик) с запросом — всё пропало, не работает, ааааа!!!
dig chklst.ru ANY
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 21 (Not Supported): (Type ANY Queries not supported here, RFC8482)
;; QUESTION SECTION:
Хотя раньше всё работало из коробки и Bash скрипты вели себя предсказуемо. Но опять же, в зависимости от DNS сервера, результаты могли разница. Тебе могли отдать данные, которые в предыдущем запросе были совсем другими.
Логично. Провайдеры рано или поздно приходят к этому, начинают блокировать подобные запросы. Всё это связано с дидос атаками. Погоды эти ANY запросы не делают, но создают большую проблему и головную боль. Основная проблема — DDoS amplification.
Самый адекватный способ борьбы с этим — отключить всё нахуй и поломать возможный вектор атаки. Короче непредсказуемость ANY запроса это плохая практика. Запрос ANY никогда не был стандартизирован, как «получить всё».
Читать продолжение: https://two.su/dzg0a
🛠 #security #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blogrsync:
rsync -ncrv /old1c /1c
-n (--dry-run) — только тестирование
-c (--checksum) — по содержимому
-r (--recursive) — рекурсивно
-v (--verbose) — подробности
Вот только ставить на клиентскую машину rsync ради одного сравнения, так себе идея. Да и если забыть ключик -n, можно убить данные. Решил сделать все костылями:
find /old1c /1c -type f -printf "%f " -exec md5sum {} \; |
awk '{print $2,$1}'|sort |uniq -c|awk '$1%2'
-type f — только файлы
-printf "%f " — печатаем basename
-exec md5sum {} \; — для каждого файла вычисляем md5
|awk '{print $2,$1}' — сначала md5, потом файл (не принципиально, но красивее)
|sort |uniq -c — на первой позиции - число уникальных записей. Без sort uniq не работает.
|awk '$1%2' — печатаем только строки, с нечетным числом записей.
Поскольку сравниваем два предположительно одинаковых каталога, то в идеале, файлы должны быть в четном количестве. Если у файлов c одинаковыми basename разная md5, то их число будет нечетным.
В общем, как я и предполагал, нашлись файлы с разной контрольной суммой. Значит повреждение было на диске. Ну, и после переустановки 1с, проблема ушла.
На самом деле проблема не такая редкая. Дело в дисках. Есть такая характеристика как Неисправимых ошибок чтения/прочитанных бит.
Например, на wd blue 1E-14, на wd gold 1E-15, на SSD Micron 7450 MAX 1e-17. То есть серверный ssd в 1000 раз надежней, чем бюджетный hdd. Просто не всегда эти ошибки одинаково заметны.
Кстати, rsync работает значительно быстрее. Если данных много — используйте его.
Всем работы без багов.
🛠 #debug #devops
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 BlogРекомендую ознакомиться, столько интересного и неочевидного раскопал. Возможно это подтолкнет тебя к переезду с docker в podman.Healthcheck инструментами Podman → https://two.su/3kcvf 🛠 #devops #dev — 💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
А еще можно скачать нечто подобное с вебархива, там около 2х гигов, глядишь где-то сгодится.🛠 #services #music — 💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
