На канале было опубликовано много всевозможных прикладных bash скриптов, которые я сам постоянно использую. У меня они все в отдельном репозитории лежат. Решил их собрать для вашего удобства в отдельную публикацию.

▪️lynis.sh - проверка системы с помощью lynis и выгрузка результатов в Zabbix
▪️vps-audit.sh - аудит безопасности сервера
▪️dir_size.sh - определяет размер директорий и записывает результат вместе с датой замеров в файл
▪️postgres.sh - отдельные консольные команды postgresql сервера для использования в своих скриптах (pg_dump, createdb, reindexdb, vacuumdb и т.д.)
▪️copy-last.day.sh - передача с помощью rsync с одного сервера на другой бэкапы прошлого дня, более старые не трогает, забирает файлы со стороны стороннего сервера, а не исходного, где лежат файлы
▪️tg_mon.py - следит за заданными строками в лог файле и шлёт уведомления в telegram, когда их видит
▪️dates.sh - заготовка под работу с датами в скриптах
▪️copy-mysql-table.sh - копирование отдельной таблицы базы данных с одного сервера на другой
▪️wget-speedtest.sh - загружает интернет канал загрузкой данных с публичных Looking Glass
▪️findmnt.sh - проверка существования точки монтирования
▪️ps_mem.py - использование оперативной памяти программами (не процессами)
▪️check_nginx_running.sh - анализ работы веб сервера Nginx для экспорта в логи или мониторинг
▪️contry-block.sh - блокировка стран с помощью ipset и iptables
▪️mysql-stat.sh - оптимизация конфигурации MySQL сервера под имеющуюся оперативную память
🔥topdiskconsumer.sh - очень удобная статистика по занимаемому месту
▪️swap.sh - использование swap процессами
▪️trash.sh - самостоятельная реализация корзины при удалении файлов

📌 Софт для работы со скриптами:

◽️Rundeck - веб интерфейс для централизованного управления работой скриптов на серверах.
◽️Cronicle - система планирования и управления задачами серверов. Условно его можно назвать продвинутым Cron с веб интерфейсом.
◽️Task - утилита, написанная на Gо, которая умеет запускать задачи на основе конфигурации в формате yaml. Более простая и функциональная замена утилите make.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#script #подборка

Существует удобный и функциональный инструмент для добавления интерактива в shell скрипты под названием Gum. Я посмотрел несколько примеров, в том числе на ютубе, как люди решают те или иные задачи с его помощью. Синтаксис очень простой, особо разбираться не надо. Можно сходу брать и писать скрипт.

Я для примера решил сделать поиск по директории с выводом топ 10 самых больших файлов, из которых можно какие-то выбрать и удалить. Сделал просто в лоб на bash – сформировал список, отправил его в gum и добавил действие для выбранных файлов:

#!/bin/bash

DIR="/tmp/backup"
files=$(find "$DIR" -type f -exec du -b {} + 2>/dev/null | sort -nr | head -n 10 | awk '{print $2}')
selected=$(echo "$files" | gum choose --no-limit)
delete=$(echo -e "$selected")

if [[ -z "$delete" ]]; then
    echo "Ничего не выбрано."
    exit 0
fi

gum confirm "Удалить выбранные файлы?" &&
echo "$delete" | xargs -d '\n' rm -f && echo "Выбранное удалено."

Понял, что всё получилось и решил как-то это усложнить и сделать более удобным. Дай, думаю, попрошу Chatgpt что-то написать. На самом деле не рассчитывал на успех, так как это не особо популярный инструмент. Откуда ему взять навык написания скриптов для gum? Вряд ли их много в интернете можно найти.

Отправил ему адрес репозитория и попросил сделать 2 списка: один с самыми большими файлами, второй – с самыми старыми. Причём вывести их вместе на один экран, в списках отобразить размер файлов и их даты.

Задача не сильно сложная, но немного муторная, так как списки надо правильно сформировать, объединить, пункты выбора насытить дополнительной информацией в виде размера файлов и даты. Потом всё это надо очистить, чтобы передать на удаление только имя файла. Чтобы самому это сделать, надо потратить какое-то время.

Chatgpt меня удивил, когда практически сразу же выдал рабочее решение. Там были ошибки по части bash. Нужно было что-то экранировать, а что-то получше очистить. А вот в части непосредственно Gum он на удивление сразу же всё корректно оформил в соответствии с его возможностями. Я думал, что-то выдумает от себя нерабочее, но нет.

В итоге минут за 15-20 со всеми тестами я получил рабочий вариант скрипта. Реально, был очень удивлён. Не так давно его мучал конфигурациями Nginx, по которым море примеров в сети, но так и не добился того, что хотел. А тут какой-то Gum и сразу всё заработало.

☝️ Какое в итоге резюме. Gum – прикольная штука, которую можно приспособить под какие-то свои задачи. Например, выбор подключений по SSH, работа с ветками GIT, работа со списками файлов и т.д. Тут уж каждому своё. А второй момент – используйте ИИ для своих задач. Где-то он мимо советует, а где-то сразу рабочий вариант даёт. Причём в таких небольших прикладных задачах он нормально работает. На bash пишет уверенно. Есть проблемы, но поправить после него намного проще, чем написать самому, вспомнив все возможности и ключи консольных утилит.

⇨ Итоговый скрипт

Использовать:

# ./cleanup-with-gum.sh /mnt/backup

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#bash #AI #script

Утром рассказал, как делаю бэкапы баз Postgresql с помощью скриптов и pg_dump. Сейчас покажу, как я их проверяю. Для этого обычно держу небольшой тестовый сервер с той же версией Postgresql. В идеале это должна быть копия прода, но не всегда это возможно. На нём же зачастую проверяю обновления.

Первым делом надо забрать дампы с исходного сервера. Для этого беру простой скрипт, который забирает по SSH только свежие файлы за прошлый день. Если забрать сразу только нужные файлы, то потом не придётся делать в них выборку:

#!/bin/bash

/usr/bin/rsync -av --progress --files-from=<(ssh root@10.20.5.10 '/usr/bin/find /var/lib/pgpro/backup -type f -mtime -1 -exec basename {} \; | egrep -v timestamp') root@10.20.5.10:/var/lib/pgpro/backup/ /data/backup/

Использую rsync, а список файлов для копирования формирую сразу в выражении ключа, подключившись к нужному хосту по SSH и отсортировав файлы по дате, взяв не старше суток. В данном случае файл timestamp через egrep -v добавлен в исключения. У меня там метка времени последнего бэкапа хранится для нужд мониторинга.

Ну а дальше дело техники. По очереди выполняю набор команд для удаления старой базы, создания новой, распаковки и заливки дампа. Перед первым запуском этого скрипта вручную создаю все восстанавливаемые базы и выборочно проверяю восстановление. Потом формирую итоговый список команд:

#!/bin/bash

BASES=`/opt/pgpro/1c-16/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
BACKUP_DIR="/data/backup"

for i in ${BASES};
  do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Drop database ${i}"
    /opt/pgpro/1c-16/bin/dropdb -U postgres ${i}
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Create database ${i}"
    /opt/pgpro/1c-16/bin/createdb -U postgres -T template0 ${i}
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start extract $i"
    /usr/bin/find /data/backup -type f -name *${i}* -exec /usr/bin/unpigz '{}' \;
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End extract $i"
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start restore $i"
    /opt/pgpro/1c-16/bin/psql -U postgres ${i} < ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}` 1>/dev/null
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End restore $i"
    echo "`date +"%Y-%m-%d_%H-%M-%S"` rm dump ${i}"
    /usr/bin/rm ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}`
done

Сразу говорю, что я тут ничего не оптимизировал, никаких проверок не делал. Если просто взять и запустить, то скорее всего у вас вывалятся какие-то ошибки или что-то пойдёт не так. Я просто показываю идею. У меня уже давно и структура каталогов одна и та же, и подход к именованию баз, бэкапов и т.д. Это всё сделано под меня и работает так уже много лет. Меня устраивает.

В данном скрипте нет никаких проверок успешной работы и оповещений, потому что это не последний этап проверок. Далее в зависимости от того, где эта база используется, запускаются свои проверки. Для баз 1С выполняется автоматическая выгрузка в dt с помощью отдельного скрипта. Если она проходит успешно, то считается, что дамп базы живой и нормально восстановился.

Если же это база от веб проекта, то параллельно из другого бэкапа восстанавливаются исходники в тестовый веб сервер, подключается восстановленная база и работает стандартная веб проверка в Zabbix Server, которая ищет какие-то данные на странице, которые без работающей базы не будут показаны. Если веб проверки проходят успешно, то считается, что база восстановилась, да и в целом бэкап живой.

Более сложные проверки в восстановленных базах я не делаю. Мой опыт в обслуживаемых инфраструктурах показывает, что этого достаточно. Ни разу не сталкивался, что всё прошло успешно, а с базой проблемы. Обычно проблемы возникают сразу в снятии дампа. Если он корректно выполнен, то дальше уже все отрабатывает нормально.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#backup #postgresql #script