BashTex | Linux

Bash-лайфхак: комментирование команд прямо в истории Когда вы часто экспериментируете в терминале, история превращается в хаос - одинаковые команды, тестовые прогоны, случайные опечатки… И вот через месяц вы смотрите на history | grep rsync и думаете: "А что это я тут хотел сделать?" или какая из этих команд рабочая.. Но тут есть один простой трюк - добавляете комментарий прямо к команде, и он сохранится в истории. 🌟 Как это работает? В bash можно писать так:

    
        
rsync -av --delete /data/ /backup/  # бэкап данных на внешний диск{}
    

В истории будет сохранена вся строка. И когда через Ctrl+R или history | grep backup вы ищете - строка находится по тексту комментария тоже! ▪️ Примеры

    
        
ssh user@host  # тест сервера
docker exec -it web bash  # залезть внутрь контейнера nginx
find /var/log -type f -size +100M  # поиск больших логов{}
    

▪️ Полезные фишки Можно делать свои теги:

    
        
apt update && apt upgrade  # [system-maintenance]{}
    

А потом искать:

    
        
history | grep "\[system-maintenance\]"{}
    

BashTex 📱 #bash

🚀 Стань мастером Docker с Docker Ninja 🚀   Как говорил великий классик: "Порхай как бабочка, жаль, что ты до сих пор не подписан на канал Docker Ninja. Уже давно стал бы профессионалом в docker!" На канале ты найдешь: 📚 Краткие и ёмкие посты: Каждое сообщение — это выжимка полезной информации без лишних сложностей, которая сразу же пригодится в работе.  👨‍🏫 Авторский подход: Изучайте Docker с помощью советов и инсайтов от опытного девопса. 💡 Практические кейсы: Поймете, когда и как применять команды Docker, с примерами из реальной практики. 🎯 Интересные детали: Узнаете интересные аспекты Docker, которые сделают вашу работу еще увлекательнее. Присоединяйтесь к сообществу Docker Ninja по ссылке и начните свой путь к мастерству с Docker уже сегодня! 🐳🥷

systemd timers: сценарии, которые cron не умеет Часто cron хватает для простого раз в день, но когда расписание становится хитрым - systemd timers выигрывают. Покажу несколько кейсов, которые на cron делать больно, а здесь - просто. 1️⃣ Только в рабочие дни, с 9:00 до 18:00. Хотим, чтобы скрипт мониторинга нагрузки запускался каждые 15 минут в будни, но не ночью и не в выходные: /etc/systemd/system/load-check.timer

    
        
[Timer]
OnCalendar=Mon..Fri *-*-* 09..18/15:00{}
    

Mon..Fri - только будни; 09..18/15:00 - каждые 15 минут с 9:00 до 18:00. Аналог на cron выглядел бы как несколько строк с костылями. 2️⃣ Persistent=true - выполнение пропущенных задач. Задача должна выполняться раз в день, даже если сервер был выключен ночью.

    
        
[Timer]
OnCalendar=daily
Persistent=true{}
    

Если сервак в оффлайне, при старте systemd увидит пропущенное выполнение и запустит задачу. У cron такого поведения нет - выключил машину, задача пропала. 3️⃣ Замороченные расписания - раз в час, но не в обед. Допустим, хотим запускать скрипт синхронизации каждые 60 минут, но исключить обеденный перерыв (с 12 до 13):

    
        
[Timer]
OnCalendar=Mon..Fri *-*-* 09..11:00,13..18:00{}
    

Здесь мы задали диапазоны часов с дыркой. 4️⃣ Несколько расписаний для одной задачи. Хочется иметь и ночной запуск (2:00), и дополнительный в пятницу вечером:

    
        
[Timer]
OnCalendar=*-*-* 02:00:00
OnCalendar=Fri *-*-* 19:00:00{}
    

В одном таймере можно указать несколько OnCalendar. 5️⃣ Контроль за пропусками и сбоями. Если критичный скрипт не отработал, мы хотим это видеть. Добавим OnFailure: /etc/systemd/system/backup.service

    
        
[Unit]
Description=Nightly backup job
OnFailure=alert.service{}
    

Если бэкап упадет, то сразу вызовется alert.service (например, отправка сообщения в телегу). BashTex 📱 #bash #utils

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Новосибирске и поборись за призовой фонд 800 000 рублей! Когда: 23–26 октября Формат: онлайн + финал на площадке Участвуй, если ты: 🔹обучаешься на технической или ИТ-специальности; 🔹развиваешься в направлении разработки, аналитики, CV, ML или DevOps; 🔹сможешь быть в Новосибирске 26 октября. Выбери свой кейс:

✴️Цифровой дресс-код: фон, который выделяет вас. Создай локальный ML-модуль сегментации видео и генератор персонализированных фонов. ✴️CodeMetrics: метрики, которые помогают расти. Разработай систему автооценки эффективности команд через анализ Git-метрик.

Почему стоит участвовать: 🔘Кейс в портфолио и полезная обратная связь от менторов Т1; 🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний; 🔘Реальный опыт командной работы; 🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси. Регистрация открыта! ➡️ Успей до 21 октября по ссылке. erid: 2Vtzqwmd32u

Оптимизация чтения больших файлов Когда работаешь с большими логами (гигабайты), вопрос «как читать быстрее и без лишнего расхода памяти?» становится критичным. Сегодня рассмотрим два подхода: ▪️ Подход 1: Чтение чанками (построчно или блочно). Классический цикл:

    
        
while IFS= read -r line; do
    # обработка строки
done < big.log{}
    

➕ Память не забивается (читается построчно). ➖ Медленно при миллионах строк (много системных вызовов read). Для ускорения можно читать чанками (например, по 1 МБ):

    
        
while chunk=$(dd bs=1M count=1 status=none); do
    # обработка блока текста (можно разбить на строки)
    echo "$chunk" | grep "ERROR"
done < big.log{}
    

➕ Гораздо меньше обращений к диску. ➕ Можно параллелить обработку чанков. ➖ Нужно дополнительно резать блоки на строки (grep, awk, cut). ▪️ Подход 2: mapfile / readarray. Современный и удобный способ загрузить файл в массив:

    
        
mapfile -t lines < big.log
echo "Первая строка: ${lines[0]}"{}
    

➕ Удобно: сразу доступ по индексам, можно обрабатывать батчами. ➕ Быстро для средних файлов (< 100–200 МБ). ➖ Огромные файлы (> 1 ГБ) забьют память. Можно ограничить число строк:

    
        
mapfile -t -n 1000 lines < big.log  # только первые 1000 строк{}
    

А для потоковой обработки чанками:

    
        
exec 3< big.log
while mapfile -t -n 1000 batch <&3 && ((${#batch[@]})); do
    printf '%s\n' "${batch[@]}" | grep "ERROR"
done
exec 3<&-{}
    

➕ Работает как буферизация: читаем батчами по N строк. ➕ Ускоряет обработку за счёт снижения количества вызовов read. В итоге получаем, что: Для огромных логов (>1 ГБ) → читайте чанками (dd) или батчами (mapfile -n). Для средних файлов → mapfile дает лучший баланс. Для онлайн-потоков (tail -f) → старый добрый while read. BashTex 📱 #bash

Автоматическое создание LVM-снапшотов с очисткой старых копий LVM (Logical Volume Manager) - это не только удобное управление дисковыми разделами, но и инструмент для снапшотов. С их помощью можно «заморозить» состояние тома, сделать бэкап или провести тестовые изменения. Но если такие снапшоты создавать регулярно, нужно и контролировать их «уборку». 🛠 Пример скрипта

    
        
#!/bin/bash

VG="vg0"              # имя volume group
LV="data"             # исходный LV
SNAP_SIZE="2G"        # размер снапшота
KEEP=5                # сколько последних снапшотов хранить
DATE=$(date +%Y%m%d-%H%M)
SNAP_NAME="${LV}_snap_${DATE}"

# 1. Создаём снапшот
lvcreate -L "$SNAP_SIZE" -s -n "$SNAP_NAME" "/dev/$VG/$LV"
echo "[+] Snapshot создан: $SNAP_NAME"

# 2. Список снапшотов, сортировка по дате
SNAPS=$(lvs --noheadings -o lv_name $VG | grep "${LV}_snap_" | sort)

# 3. Если снапшотов больше $KEEP - удаляем старые
COUNT=$(echo "$SNAPS" | wc -l)
if (( COUNT > KEEP )); then
    REMOVE=$(echo "$SNAPS" | head -n $((COUNT - KEEP)))
    for s in $REMOVE; do
        echo "[-] Удаляем старый снапшот: $s"
        lvremove -f "/dev/$VG/$s"
    done
fi{}
    

▪️ Как использовать Положите скрипт, например в /usr/local/bin/auto-lvm-snapshot.sh Сделайте его исполняемым:

    
        
chmod +x /usr/local/bin/auto-lvm-snapshot.sh{}
    

Добавьте в cron, например, раз в день в 02:00:

    
        
0 2 * * * root /usr/local/bin/auto-lvm-snapshot.sh >> /var/log/lvm-snapshot.log 2>&1{}
    

▪️ Важные моменты 📍Снапшоты занимают место: при изменении данных в оригинальном LV они растут. Размер -L должен быть с запасом. 📍Если снапшот «переполнится» - он станет невалидным. 📍Для бэкапа можно монтировать снапшот в отдельный каталог, а после копирования - удалять его.

BashTex 📱 #bash

Открыл книгу, а закрыть не получается.. BashTex 📱 #юмор

Встраивание мини-HTTP-сервера на netcat + bash (для локальных API) Иногда хочется быстро поднять легковесный API без Nginx/Apache, чтобы протестировать интеграцию или выдавать системные данные в JSON. Для этого достаточно bash + netcat.

Общая идея такова: 📍netcat слушает порт (например, 8080); 📍bash скрипт парсит запрос и отвечает заголовками + данными; 📍результат можно использовать для локальных API-запросов (например, мониторинг).

🛠 Минимальный пример

    
        
#!/bin/bash
PORT=8080

while true; do
  # Принимаем одно соединение
  { 
    # Читаем первую строку HTTP-запроса
    read request
    echo ">>> $request"

    # Отправляем HTTP-ответ
    echo -e "HTTP/1.1 200 OK\r"
    echo -e "Content-Type: application/json\r"
    echo -e "\r"
    echo -e '{"status": "ok", "time": "'$(date +%T)'"}'
  } | nc -l -p $PORT -q 1
done{}
    

▪️ Запуск

    
        
chmod +x mini-http.sh
./mini-http.sh{}
    

Теперь можно открыть в браузере: http://localhost:8080 ▪️ Возможности 📍отдавать системные метрики:

    
        
echo -e '{"load": "'$(uptime | awk "{print \$10}")'"}'{}
    

📍простой healthcheck для Docker: curl localhost:8080/health 📍мини-API для локальных скриптов (например, статус бэкапа). Такой подход позволяет собрать сверхлегкий REST-like API прямо из bash - без сторонних веб-фреймворков. BashTex 📱 #bash #utils

⚡️ На Stepik вышел курс по Linux Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой). Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами. После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 20% по промокоду «LINUX_ADMIN»: открыть курс на Stepik