Bash Days | Linux | DevOps

Вот не пойму, это оно мне жопу нарисовала или сиськи? Радоваться или плакать? Но похоже больше на жопу... ㅤ 🛠 #рабочиебудни #мониторинг — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Сегодня поделюсь историей, которая началась плохо, но закончилась хорошо. ㅤ 🔤🔤🔤🔤🔤🔤🔤 В общем, у меня домашний шлюз - mini PC на debian. А поскольку мощность для шлюза избыточна, приходится использовать ее не по прямому назначению. Поставил туда 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

Fedora Post Install ㅤ Набрёл тут на Bash поделку CRIMS0NH4T. В двух словах — делает за тебя необходимую рутину после чистой установки Fedora. — Настройка DNF — Установка RMP Fusion — Установка кодеков — GPU драйвера (Intel, Nvidia, AMD) — Тюнинг производительности — Оптимизация Gnome Как я понял, версия прям ранняя альфа-альфа и активно допиливается автором. Я бы минимально запатчил так:

- 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

🎥 Вебинар по Kubernetes: "Kubernetes для непрерывной поставки (CI/CD). Интеграция с CI-сервисом" ☝️ На вебинаре вы узнаете: - Как Kubernetes используется в качестве среды для доставки и масштабирования приложений. - Интеграция Kubernetes с GitLab CI, GitHub Actions и другими популярными CI/CD-сервисами. - Лучшие практики построения пайплайнов, работающих с k8s. - Деплой приложений в кластер: helm, kubectl, ArgoCD и другие инструменты. - Типичные ошибки при организации CI/CD в Kubernetes и как их избежать. 💪 В результате вебинара вы: - Поймёте, как связать Kubernetes с CI/CD и зачем это нужно. - Научитесь строить эффективные пайплайны доставки для микросервисных приложений. - Получите практические примеры конфигураций и инструментов, которые можно применить сразу после занятия. 🎁 Все участники вебинара получат специальные условия на полное обучение курса "Инфраструктурная платформа на основе Kubernetes" 👉 Для участия зарегистрируйтесь: https://vk.cc/cQnW2z Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Фиксим кривой Exit Code в docker Во время работы с docker контейнером наткнулся на неочевидный код выхода (exit code).

Про 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

📆DevOps-митап с докладами от Altenar и Флант — встречаемся в центре Питера и онлайн вечером 30 октября. Ребята из международного разработчика ПО Altenar расскажут, как устроена их гибридная инфраструктура и: • Сравнят три способа подружить секреты из Vault с Kubernetes, которые опробовали в продакшене, а также рассмотрят альтернативные подходы. • Поделятся, как построили и поддерживают секьюрити-пайплайн на базе SonarQube, Trivy Operator и DefectDojo силами одного инженера. А также представитель Фланта поделится не так часто освещаемым опытом: как подойти к процессу сборки и доставки приложений в закрытые Kubernetes-кластеры. 👉🏻Все что нужно — зарегистрироваться. 📍Участие бесплатное, число мест в зале ограничено. Все зарегистрировавшиеся получат ссылки на трансляции в день мероприятия.

Сколько линуксоида не корми, он все равно на винду поглядывает. Накопал я тут тебе WinBoat. Эта штука запускает Windows-приложения прямо в Linux с максимально «нативной» интеграцией: окна приложений — как обычные X/Wayland-окна, общий доступ к файлам и даже полноценный Windows-десктоп. Что в коробке - Запустит любое приложение, которое работает в Windows — в том числе коммерческие программы. Ради прикола запустил Excel, ну что сказать, минимум приседаний и танцев с бубном. Работает прям отлично. - Окна приложений интегрируются в рабочий стол Linux, не просто RDP в едином окне, а RemoteApp-композитинг. ㅤ - Автоматические инсталляции через GUI — выбираешь параметры, остальное делает WinBoat. - Файловая интеграция, домашний каталог монтируется в винду. - Полный Windows-десктоп по запросу (если нужно работать внутри полноценной виртуальной машины). Что под капотом Это Electron-приложение + сопутствующий «guest server». Windows запускается как VM внутри контейнера Docker. А между хостом и гостем общаются через WinBoat Guest Server. Затем для прорисовки отдельных окон используется FreeRDP + Windows RemoteApp — это и даёт ложное ощущение нативности. Штука интересная возможно бы я ее использовал, если бы плотно сидел на линуксе. Так что приглядись, глядишь установишь в хозяйстве приживется. 🛠 #утилиты #utilites #linux — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Сейчас я тебе покажу как «пиздато» организовать избранное в телеге. У меня оно начиналось как «личное избранное», теперь это стало что-то вроде CRM внутри компании. Каждый сотрудник имеет к такой группе доступ и может закинуть туда что-то своё. ㅤ Этакая база данных всяких полезных фич. Делается это банально. Создаешь приватную группу, включаешь в группе «топики», создаешь нужные топики. Всё! По необходимости добавляешь в группу людей, либо чисто используешь под свои цели. На скрине я создал тестовую группу, чтобы показать, как это визуально выглядит (реальную не стал закидывать, чтобы тебя не шокировать письками). В реалиях у нас эта группа имеет овер 20 топиков, для бухов, для креативщиков, для личных целей и многое другое. Кто-то посмотрел интересный фильм или увидел шортс который можно сконвертировать во что-то полезное — кидают это в топик.

Например, мемы для @devopsina по сути набираются регулярно в отдельный топик. Каждый день редактор забирает трендовые видосы, обрабатывает их, повышает качество, делает из шакальных - нормальные, генерит в своей голове какие-то айтишные подписи. GPT не используем.

У меня например там есть топик - Гитара, если натыкаюсь на что-то интересное, сохраняю туда. Потом когда появляется желание что-то изучить новое, иду в топик, выбираю что хочу поучить и развлекаюсь. Короче бери на заметку, эта штука у меня живет уже как 2-3 года. Первые год использовал в одну харю, а потом расшарил на сотрудников. Прижилось.

А еще в телеге есть чеклисты нативные и отдельный топик под это. Опять же когда надо что-то закупить, делаем общий чеклист и потом все это визуально видно, кто что закупил.

Такие дела. Попробуй мож зайдет и ты наведешь порядок в своем хаосе. 🛠 #рабочиебудни — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Много шума наделала метка A+. Как оказалось эта иконка очень страшная для «тревожных». ㅤ А «страшная» она тем, что в интернетах нагнали жути, мол тотальная слежка, слив данных и т.п. Сейчас я тебе расскажу правду, что происходит. Яж всегда с тобой был честен. 1 ноября 2024 года в силу вступил закон, об обязательной регистрации блогеров, у которых > 10к подписчиков. Все блогеры были обязаны пойти в РКН и зарегистрировать свои каналы, группы, площадки. Отдав взамен свои номера телефонов, явки и пароли. Если этого не сделать, нельзя размещать партнерские посты, из таких каналов нельзя делать репосты. То есть если ты делаешь репост из такого канала, который не зарегистрирован в РКН — ты нарушаешь закон.

А сколько раз ты нарушил закон и репостнул из таких каналов мемчики?

Чтобы тебя за жопу не взяли, я сделал все как требуется, все по правилам. Теперь ты можешь репостить и делиться этим с коллегами. Обезопасил твою задницу. Под эту тему все мы пошли и зарегистрировались в РКН, да, еще в 2024 году. В описании каналов и групп ты мог видеть ссылку на сайт госуслуг, который это подтверждает. Но большинство на это не обратило внимания. Зря. Я к чему, почти год ты сидишь в таких каналах и с удовольствием поглощаешь контент. А как только увидел A+ — бежать! Ничего же не изменилось, все что нужно, про тебя и так все давно уже знают. К 2026 году 99% площадок будут ходить с этой меткой, чтобы следовать закону, чтобы была возможность размещать партнерские посты и как-то конвертировать полезный контент в хлеб с маслом. Так что не ссы, если хочешь быть в безопасности — отключи у себя интернет, выкинь телефон и завернись в фольгу. Ну и обязательно почитай матчасть как все это работает изнутри. Для тебя ничего не изменилось. А для меня изменилось, стало больше геморроя с отчетностью, с дополнительными налогами и т.п. Но так или иначе я продолжу делать своё дело и буду делать его хорошо. Поэтому не устраивай бои с тенью и не будь «тревожным». Если живешь правильно и прозрачно, никто за тобой следить не будет. Не руби с плеча, разберись и думай своей головой, а не головкой персонажа, который нагнал на тебя жути в каких-то пабликах. Как-то так. Мотай на ус. Всех обнял! 🛠 #рабочиебудни — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Здесь: я как-то поднимал проблему с торможением 1c на postgres. 🔤🔤🔥🔤🔤🔤🔤 Благодаря нашему коллеге @ovchinnikovmy, дело сдвинулось с мертвой точки. Спасибо ему большое за консультации и рекомендации по PG. ㅤ Мы начали попытки оптимизировать работу postgres для нашей задачи. И сразу столкнулись с проблемой. Ну, оптимизировали. А насколько? Улучшение есть, а кто был виноват в тормозах PG или 1С? Все может прекрасно работать в тестах, и становится колом, когда идет интенсивная работа в нескольких базах одновременно. Где горлышко бутылки - число ядер, частота или скорость диска, или может пора памяти добавить? Там маленькая конторка. Фактически один сервак. Не будешь же zabbix ради этого ставить. Онлайн можно посмотреть через 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

🎉 Результаты розыгрыша: 🏆 Победители: 1. Jull (@sun_jumper) 2. Алексей (@hapy_hex) 3. Александр (@khodzh97) ✔️Проверить результаты

Привет, очередная халява. Каждый год я отдаю 3 проходки-билета (скидка 100%) на онлайн-конференцию «Подлодка». Если есть желание посетить сие онлайн-мероприятие, кликай кнопку ниже. Через пару дней опубликуются результаты. Ну а дальше с вами свяжется я или Макс и раздадим ништяки. Такие дела! Условия розыгрыша: подписаться на канал @bashdays, @gitgate, @devopsina

Антипаттерны не щадят даже лучших. С 13 по 17 октября пройдет новый сезон Podlodka Techlead Crew “Архитектурные антипаттерны”. Обсудим ошибки, которые ломают архитектуру, и как их избежать. В программе: 🛠 Модульный монолит: убийца микросервисов. Какие плюсы микросервисов реально доступны и без них и как монолит снижает сложность и экономит ресурс — Денис Цветцих 📑 Дизайн-доки — инженерная культура в FAANG. Как обсуждать архитектуру до кода, избегать холиваров и делать дизайн-доки полезными — Дмитрий Волыхин ⚡️ Error Handling: от боли к порядку. Стандарты обработки ошибок вместо хаоса при интеграциях через API — Евгений Лукьянов 🔍 Круглый стол. Архитектурные антипаттерны: как вовремя распознать. Первые звоночки анти‑паттернов, практические примеры и стратегии их предотвращения — Алексей Кашин, Салих Фахрутдинов, Андрей Шарапов 🧠 Всё, что обсудим, реально применимо и пригодится уже в следующем спринте Подробности и билеты: https://podlodka.io/techcrew Реклама. ИП Толстая Е. П., ИНН: 507503278104

Привет друзья, Масим Братковский запилил для нас техническую статейку. ㅤ Сюда по классике не влезло, опубликовал в блоге. Идем читать. Что делать если postman остопиздил, а надо тестировать SOAP API. Комментарий автора: Если вам интересно, давайте обратную связь, буду рад продолжить серию статей. 🛠 #dev #qa — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Возьмем на поддержку ваш Zabbix и/или обучим работе на официальных курсах Gals Software — команда сертифицированных экспертов с многолетним опытом работы с Zabbix и с командой техподдержки Zabbix. Наши специалисты освобождают руки администраторов систем и дают им уверенность в надежности мониторинга. 💼Техподдержка 1,2 и 3 линии (описание на сайте): 🧭 проводим аудит и оптимизацию архитектуры (сервер, прокси, БД) 🧩 настраиваем шаблоны: стандартные и кастомные под ваш стек (Linux/Windows, СУБД, сеть, бизнес-метрики) 🔕 снижаем событийный шум: нормализация триггеров, пороги, зависимые элементы 🔗 интегрируем Zabbix с Telegram, почтой, ITSM/CMDB, веб-хуками и внешними API 📈 строим понятные дашборды для бизнеса и техподдержки (Grafana по желанию) ⬆️ безопасно обновляем версии, мигрируем и масштабируем 🧑‍🏫 обучаем вашу команду и делимся практиками 🎓 Тренинги от создателей Zabbix на русском с получением официального сертификата: 📅 Zabbix сертифицированный специалист 7.0 (ZCS 7.0) 17-21 ноября 2025 📅 Zabbix сертифицированный эксперт 7.0 (ZCE 7.0) 24-28 ноября 2025 📅 Zabbix сертифицированный профессионал 7.0 (ZCP 7.0) 15-17 декабря 2025 ❗️Полное расписание тренингов. Интенсивы, в отличие от многомесячных тренингов, позволяют максимально быстро погрузиться в тему и начинать работу с Zabbix сразу после прохождения тренинга. Подробную информацию о наших услугах вы можете запросить, написав @galssoftware или через почту hello@gals.software. Подписывайтесь на наши телеграм-каналы: 🚀 @zabbix_ru — Zabbix и ничего кроме Zabbix 🚀 @elasticstack_ru — ElasticSearch/OpenSearch и логирование 🚀 @monitorim_it — мониторинг ИТ-систем 🚀 @usr_bin_linux — лайфхаки по работе с Linux-системами Реклама. ООО Галс Софтвэр, ИНН 5047195298, erid 2VtzqvsS2oX

Сегодня коллега, который проводит дохрена технический собесов поделился инсайдом. Мол кандидаты из Южной Америки часто называют временные переменные aux, а вот кандидаты из Восточной Европы - temp. Такая вот этнография. ㅤ Прикольно. Для меня aux это дырка в которую можно что-то вставить. А в чем дело-то? Причины могут быть в языке и в традициях обучения. Южная Америка и «aux» Во многих странах Латинской Америки (а также в Испании и Португалии) обучение программированию ведётся на родном языке. Слово auxiliar (испанское) или auxiliar/auxiliaridade (португальское) переводится как «вспомогательный». Поэтому сокращение aux — это естественный выбор для временной переменной. Многие учебники и преподаватели прямо используют aux в примерах. Восточная Европа и «temp» В странах Восточной Европы (Россия, Польша и др.) учебные материалы часто брались с английских источников или напрямую переводились, но при этом терминология частично сохранялась. В англоязычных книгах традиционное имя временной переменной — temp (от temporary). В итоге это закрепилось как привычка. Ещё один фактор — русскоязычные (и в целом восточноевропейские) программисты исторически чаще учились по книгам на английском, чем по локализованным методичкам. Хотя и методичек особо таких и не было.

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

Давай разберем другие страны Китай - В учебниках и коде часто встречается tmp (это короче чем temp). - arr почти всегда вместо array. - Булевые переменные часто называются flag. - Комментарии «中英混合» — смесь китайских и английских терминов:

// 计算 sum
total = total + arr[i];

- В олимпиадном коде часто встречается ans и vis (visited). Западная Европа / США - Стандартные учебные названия: temp, foo, bar, baz. - В учебниках на джава и питоне для временных значений часто используют value или val. - В научном и численном коде — переменные x, y, z, dx, dy (от физики и математики). Ну тут классика, аналогично Мистер и Миссис Стоговы из учебников по инглишу. Ближний Восток - В арабоязычных странах иногда встречается mosa3ed (مساعد = помощник), но чаще используют англоязычные temp/aux. - Комментарии миксуют латиницу и арабицу, например:

// calculate المجموع
// check if الشرط
// temp متغير

В целом получаем: - Испаноязычные/португалоязычные — aux. - Восточная Европа — temp/buf/cnt/res. - Англоязычные — temp/foo/bar. - Китай/Индия — tmp/flag/arr/ans. Короче вся это тема — маленькие «акценты» кода. Про 1Сников писать уж не буду, сам все знаете как они переменные называют. Не смею больше отвлекать, хороших тебе выходных! 🛠 #рабочиебудни #dev — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Быть в тренде = быть на DevOps Meetup по Platform Engineering! ⚙️ Платформенный подход — новый тренд в IT, и кто первый его подхватит — тот сможет масштабироваться, ускорить и улучшить разработку, без потери контроля и безопасности. 🎤 На митапе спикеры из Сбера, Т-Банка и Cloud․ru поделятся практическим и честным опытом внедрения Platform Engineering. 📍 Москва, офис Сбера ⏰ 6 октября, 18:30 👉 Онлайн+офлайн Регистрируйся по ссылке.

Чем глубже пропасть, в которую падаешь, тем больше шансов научиться летать. На подходе новый закон о глобальном запрете мата в сети, поэтому к нему нужно подготовиться. Переебашивать каждый пост в блоге — проблематично, да и лень. ㅤ Поэтому, как обычно, будем изобретать велосипед. Суть идеи — налету в DOM менять маты на синонимы. То есть в момент отдачи контента, контент будет насильно зацензурен.

Хуйня == Фигня, Пезда == 3.14зда ну и в таком духе.

А там уже можно будет добавить регулярки и гибко всё затюнить, мало ли, может можно будет звездочками разбавлять такой контент. 😀😃😄😁😅😂🤣😊 😇🙂🙃😉😌😍🥰😘 😗😙😚😋😛😝😜🤪 🤨🧐🤓😎🤩🥳😏😒 Реализация За основу я возьму angie (форк nginx) с модулем LUA. Я давно на это решение пересел, так как всё из коробки работает, включая генерацию SSL. Не нужно ебстись с компиляций модулей и страдать.

Как настроить автополучение SSL в angie, писал в этом посте.

Если LUA не установлен, ставим:

apt install angie-module-lua

В /etc/angie/angie.conf добавляем:

load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;
load_module modules/ngx_stream_lua_module.so;

В /etc/angie/sites-available/bashdays.ru.conf добавляем в корневой локейшен:

location / {
    root /var/www/bashdays.ru/htdocs;
    index index.html;
    gzip off;

    body_filter_by_lua_block {
        local replacements = dofile("/etc/angie/wordmap.lua")

        local chunk = ngx.arg[1]
        if chunk then
            for _, pair in ipairs(replacements) do
                chunk = ngx.re.gsub(chunk, pair[1], pair[2], "ijo")
            end
            ngx.arg[1] = chunk
        end
    }
}

Ну и создаем файл /etc/angie/wordmap.lua который будет содержать шаблоны замены:

return {
    {"хуйня", "фигня"},
    {"хуй", "писька"},
    {"говн%w*", "ерунда"},
    {"еба%w*", "плохой"},
}

Проверяем: angie -t и если всё ок, можно сделать systemctl restart angie. Открываем сайт и видим что все маты зацензурились согласно шаблону в файле /etc/angie/wordmap.lua. Если всё осталось по-прежнему, скинь кеш, в 99% дело в нем. Давай разберемся как это работает. body_filter_by_lua_block — перед отправкой ответа клиенту, запустится Lua-скрипт, который изменит тело ответа. dofile("/etc/angie/wordmap.lua") — загружает Lua-файл со словарём замен. ngx.arg[1] — текущий кусок (chunk) ответа (HTML, JSON и т.п.), который angie собирается отправить клиенту. Ответ приходит потоками. for _, pair in ipairs(replacements) — перебор всех замен из словаря. ngx.re.gsub(chunk, pair[1], pair[2], "ijo") — регулярная замена, [1] что искать, [2] на что заменить. "ijo" — флаги: i — без учёта регистра, j — dotall (точка матчится на \n), o — оптимизация. ngx.arg[1] = chunk — возвращаем изменённый кусок, который уйдёт клиенту. И получаем — блок берёт HTML-страницу, проходит по каждому чанку тела ответа, и заменяет в нём «запрещённые» слова из словаря на синонимы. Ааа, еще в словаре {"говн%w*", "ерунда"} есть символы %w* это регулярка. Любая буква, цифра или подчёркивание ([0-9A-Za-z_]). В UTF-8 оно обычно ловит только латиницу, а кириллицу нет. Поэтому лучше сделать как-то так: {"говн[А-Яа-яЁё]*", "ерунда"}. Короче тут тебе карты в руки, сам натыкай паттерны. LUA — сила! Рекомендую хоть раз потыкать, проникнешься и уже не сможешь без этого модуля жить. Костыли клепать милое дело.

Есть конечно нюансы, например — Если слово вдруг разорвётся между чанками (например, ху в одном чанке и йня в другом) — фильтр его не заменит. Для надёжности нужно буферизовать весь ответ. Ну и с кириллицей надо вопрос дофиксить, но это я реализую чуть позже. Главное концепт. Всё остальное реализуемо.

Как вариант, позже еще запилю «специальный» заголовок, при передаче которого angie будет отключать цензуру и выводить посты в оригинале.

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

Ну заебись же! Осталось придумать, как зацензурить 1000 постов в телеге. 🛠 #angie #nginx #tricks — ✅ @bashdays ✅ @linuxfactory ✅ @blog

Генерация изображений, работа в телекоме и... ваш будущий коллега? 🤖 Сбер приглашает погрузиться в мир реального ИИ — не фантастики, а рабочих инструментов, которые уже сегодня творят чудеса. Ждем на митапе всех, кто хочет быть на острие технологий! Общение, нетворкинг и кофе-брейк прилагаются😉 Встречаемся 9 октября в 18:30 в Технохабе Сбера! Регистрация на митап

Настройка core dump в Docker Цель этого поста — дать тебе общее руководство по включению и сбору core dumps для приложений, работающих в docker контейнере. Настраиваем хост для сохранения дампов Для начала надо сконфигурировать хостовую машину, чтобы сохранять такие дампы в нужное место. Нет, не в жопу. ㅤ Универсальный способ — задать шаблон core pattern. Шаблон определяет путь и информацию о процессе который наебнулся.

echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

Кратенько: %e — имя процесса %p — pid процесса

Более подробно о конфигурации core pattern можешь почитать в man-странице ядра Linux.

Как вариант, можно настроить host изнутри контейнера через CMD или ENTRYPOINT. Но контейнер в этом случае должен запускаться в privileged mode, что хуева с точки зрения безопасности. Пример хуёвого приложения

#include <cstdlib>
void foo() {
    std::abort();
}

int main() {
    foo();
    return 0;
}

После компиляции и запуска, приложение наебнется с ошибкой. Пишем Dockerfile это для этого приложения

FROM ubuntu:22.04

# Install tools
RUN apt update \
    && apt -y install \
    build-essential \
    gdb \
    && rm -rf /var/lib/apt/lists/*

# Build the application
COPY ./ /src/
WORKDIR /src/
RUN g++ main.cpp -o app

CMD ["/src/app"]

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

Запускаем контейнер с нужными опциями:

docker run \
    --init \
    --ulimit core=-1 \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    application:latest

Разбираем опции: --init — гарантирует корректную обработку сигналов внутри контейнера --ulimit — устанавливает неограниченный размер core dump для процессов внутри контейнера --mount — монтирует /tmp из хоста в контейнер, чтобы дампы, создаваемые внутри контейнера, были доступны после его остановки или удаления Здесь важно: путь source на хосте должен совпадать с тем, который задан в шаблоне core pattern. После того как приложение наебнется, core dump будет сохранён на хостовой машине в директории /tmp.

ls /tmp/core*
# /tmp/core.app.5

Анализируем дамп с помощью gdb Такс, мы получили core dump и он у нас лежит на хостовой машине, но рекомендуется открыть его внутри контейнера. Контейнер должен быть из того же образа, в котором компилилось приложение. Это поможет убедиться, что все зависимости (библиотеки и прочая хуитень) доступны.

docker run \
    -it \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    application:latest \
    bash

Если в образе нет исходного кода, можно допом смаунтить исходники:

docker run \
    -it \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    --mount type=bind,source=<путь_к_исходникам_на_хосте>,target=/src/ \
    application:latest \
    bash

Теперь внутри контейнера запускаем:

gdb app /tmp/core.app.5

После загрузки дампа можно выполнить команду bt (backtrace), чтобы увидеть трассировку стека:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f263f378921 in __GI_abort () at abort.c:79
#2  0x000055f9a9d16653 in foo() ()
#3  0x000055f9a9d1665c in main ()

Команда поможет определить, где именно произошел факап. Давай быстренько разберем ошибку. #0 и #1 показывают, что процесс получил сигнал 6 (SIGABRT) и завершился через abort() #2 — вызов произошёл внутри функции foo() #3 — main() вызвал foo() В исходнике было:

void foo() {
    std::abort();
}

То есть ошибка здесь не баг компиляции или рантайма, а намеренно вставленный вызов std::abort(), который и приводит к аварийному завершению и генерации core dump. Если у тебя docker-compose, то все флаги (--init, --ulimit, --mount и т.д.) применимы и для него. То есть отладку можно легко адаптировать. Хуй знает чё еще написать, завтра тему дебага продолжим, чет в конце года много траблшутинга навалило разнообразного. 🛠 #linux #debug #dev — ✅ @bashdays ✅ @linuxfactory ✅ @blog