Мишки на сервере

Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.

Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!

А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.

Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇

✔️ https://t.iss.one/bashday

Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.

У кого писька длиннее

Я порой нанимаю людей в штат для других компаний, в основном это девопс инженеры и SRE мальчики. 98% кандидатов это зажравшиеся морды, которые нихуя не умеют, но требуют 200-500к в месяц.

Хотя в резюме практически всегда написана тонна технологий, все сеньоры, куда деваться. Технические собеседования это хорошо, но я встречал 2х умельцев, которые подключали GPT и просто читали с экрана ответы. Ну хуйня же.

Поэтому пришлось сделать проще. Кандидат проходит техническое собеседование, даем оффер, испытательный срок 3 месяца, ЗП на старте ниже той, которую обсуждали. Заранее оговариваем этот момент с кандидатом. После испытательного ЗП вырастает на ту, что была указана в вакансии.

А дальше… а дальше цирк с конями. Я сделал второй мини продакшен из 5ти серверов (балансировщик, вебноды, базы, админки, демоны), подключил его к мониторингу, прикрутил домен. И позиционировал этот продакшен как основной.

Хотя на самом деле, это фейковый продакшен. Все запросы которые на него приходят, это просто дубли запросов с основного прода. Логи наполняются, траффик бежит, но по сути это просто затычка.

А теперь разъебон!

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

✔️Самое главное повышать градус и писать в слак — ааа, все сломалось, когда почините? какие прогнозы?

Суть этой диверсии — посмотреть как будет реагировать инженер и как быстро он все это дело отремонтирует. Ну и если отремонтирует, то нужен отчет, где была проблема, как починил и как её избежать в будущем.

Скажу так, тест дай бог проходят 2-3 из 10 человек. Последние 2 кандидата спустя 4 часа дебага, сказали — мы не можем это починить, мы не знаем что это такое. А вот если бы мы знали, что это такое, мы бы починили. Умываем руки, чините сами.

Ну и нахуй такие сеньоры нужны? Вот упадет основной прод и чо? Мне самому его чинить чтоли? За что я плачу 500к?

Причем есть и документация к проектам и карта инфры + лог сервер + все что нужно, вникни и реши вопрос. Хули ты целый месяц делал?

Да и диверсия там простая, закрываем порты через iptables и балансировщик не может достучаться до других серверов. Ну либо файл с апстримами сносим, который можно забрать в корпоративном git репозитории.

По итогу все эти специалисты уходят по-собственному, так как не согласны жить в таком стрессе. Ну а как?

Айти это как бы про работу, а большие деньги это результат этой работы.

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

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

Но я обычно беру паузу 10-15 минут, пусть полежит, может сам поднимется, это уже произошло, чо нервничать. А пока идут эти 10-15 минут, я спокойно накидываю идеи, куда я сейчас пойду и что проверю.

А потом иду и все поднимаю за пару минут. Главное всё делать с холодной головой. Чем больше суеты, тем больше потратишь времени на восстановление.

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

Букв много получилось, но всё по делу. Давай, увидимся завтра.

tags: #рабочиебудни

@BАSHDАYS | BАSHDАYS.CОM

Сбилдил дед репку

С утра рефакторил свой говно-скрипт, который ждал создания определенного файла + проверял, что файл не пустой. И затем выполнял нужные действия. Обычно для такого херачат циклы через for и while, справедливо.

Но всегда хочется большего и правильного. А в bash как раз есть третий способ реализовать подобный цикл. Называется Until.

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

#!/bin/bash

file=/tmp/bashdays

until [ -s "$file" ]
do
    sleep 1
done

echo "вот и всё"

Ключ -s как раз проверяет, существует ли файл и не пустой ли он.

У metallica есть такая песенка «until it sleeps»

А чтобы скрипт крутился НЕ бесконечно, а с определенным таймаутом, делаем так:

#!/bin/bash

file=/tmp/bashdays
timeout=10
SECONDS=0

until [ -s "$file" ] || (( SECONDS >= timeout ))
do
    SECONDS=$((SECONDS+1))
    sleep 1
done

[ -s "$file" ] || exit 1 

echo "вот и всё"

Спустя 10 секунд скрипт завершит свою работу даже если файл /tmp/bashdays отcутствует либо пустой. Ну а если все ок, то выполнится полезная нагрузка «вот и всё».

✔️ Таймауты полезны, если запускаешь скрипт по крону. Чтобы форки не плодились.

timeout=10 - задаем таймаут в секундах
SECONDS=0 - инициализируем встроенный счетчик

Встроенная переменная SECONDS в Bash является специальной переменной, которая автоматически инкрементируется на количество секунд, прошедших с начала выполнения текущего скрипта или текущей подобной конструкции. Как только скрипт начинает выполнение, `SECONDS` начинает отсчитывать время с 0 и увеличивается на 1 каждую секунду. Это позволяет удобно отслеживать время выполнения скрипта или определенной части кода.

Минусы конечно же есть, например время таймаута 10 секунд, файл был создан через 3 секунды, НО записывается 60 секунд. В этом случае скрипт выполнится все равно успешно. Этот момент стоит сразу учитывать и закладывать изначально адекватные значения.

Ну либо навешать пиздюлей через inotify или incron, чтобы определять точное время, когда был закрыт файл. И тогда проблем можно избежать. Но это лишнее звено.

Конец!

tags: #bash #linux

@BАSHDАYS | BАSHDАYS.CОM

У самурая нет тестов, только прод

Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.

if [ -f /.dockerenv ]; then
    echo "I'm inside docker";
else
    echo "I'm living in real world!";
fi

Банально проверяем наличие файла .dockerenv и всё! Да, так просто. Способ самый универсальный и используется разработчиками в 99% случаев.

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

А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:

if [ -n "$(grep 'kthreadd' /proc/2/status 2>/dev/null)" ]; then
    echo "I'm living in real world!"
else
    echo "I'm inside container";
fi

Тут суть такая, во всех хост-системах PID(2) == kthreadd.

Запускаем на хостовой машине:

ps -p 2

PID TTY TIME CMD
2 ? 00:00:00 kthreadd

Запускаем в контейнере:

ps -p 2
PID TTY TIME CMD
хуй с маслом

✔️ Может зафакапить, так как не установлен пакет procps.

Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:

docker commit <ID> <name>

<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый

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

Ладно, погнали дальше спасать этот прекрасный мир.

tags: #linux #bash

@BАSHDАYS | BАSHDАYS.CОM

Без скрипта не выловишь и рыбку из пруда

你好! Познакомился вчера на созвоне с китайцем, зовут его что-то вроде АнХуй. Смешной персонаж. Что-то мне 40 минут втирал на сломанном английском. Я ни слова не понял, но уверено махал головой как обезьяна на бананы. 🅰️

По итогу встречи я выучил слова «Нихао» и «Херанука», а он всяко выучил — «ты, заебал» и «пиздец». Вот так и работаем. Айти объединяет.

Ну чо, поехали двигать пингвинов

Сегодня изучаем — setsid

Эта такая штука… короче с помощью нее можно запускать команды и скрипты в новых сеансах и группах процессов. Скрипт запущенный через setsid будет независим от родительского процесса.

Это гарантирует, что если родительский процесс получит сигнал SIGHUP, то запущенный скрипт через setsid продолжит работу. Nohup? Почти.. Поехали в практику.

Пишем башник bashdays.sh

#!/bin/bash

echo "Starting..."
sleep 200
echo "Finished..."

✔️ Скрипт будет нихуя не делать 200 секунд.

Запускаем:

setsid ./bashdays.sh

Сразу видим, что оболочка продолжила работать в интерактивном режиме. Можно вводить команды и продолжать работу. А что со скриптом bashdays.sh? Давай запустим pstree и визуально глянем.

Это скрипт запущен через setsid

 ├─sshd─bash
        ├─sshd─bash─pstree
        └─sshd─sshd
 ├─bashdays.sh─sleep

Видишь, он не является частью процессов bash, а работает самостоятельно, в общем дереве процессов. Запущенный скрипт не привязан к текущему терминалу.

А это скрипт bashdays.sh запущен напрямую, без setsid

├─sshd─bash
      ├─sshd─bash─bashdays.sh─sleep

Видим цепочку, скрипт работает в текущей оболочке bash. Если закрыть оболочку, то и скрипт прекратит свою работу.

Давай сравним setsid и nohup

Если запустить так:

nohup ./bashdays.sh &

Наблюдаем такую картину:

├─sshd─┬─sshd─bash─pstree
       ├─sshd─bash─bashdays.sh─sleep

Пишем exit и видим уже такое:

├─sshd─sshd─bash─pstree
├─bashdays.sh─sleep

Процесс отделился от закрытой оболочки и попал в корень всех процессов. В данный момент он продолжает работу.

Теперь запускаем setsid ./bashdays.sh

├─sshd─┬─sshd───bash───pstree
       └─sshd───bash
├─bashdays.sh─sleep

А тут сразу процесс отделился от оболочки и стал корневым. Даже если написать exit и закрыть терминал, sleep продолжит работу.

Хм. Не велика разница. Но она все же есть. Команда setsid более прямой способ создания нового сеанса, тогда как nohup просто игнорирует сигнал SIGHUP.

Изучай.

tags: #bash #linux

@BАSHDАYS | BАSHDАYS.CОM

Как величать сервера

Мне часто задают этот вопрос, всем одно и тоже отвечать заёбисто. Поэтому вот вам пост, буду ссылку потом на него всем скидывать.

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

Помню когда начинал играть на гитаре, не знал что аккорды имеют название. Поэтому сам придумывал эти названия (mt-1/sl-4/sep-7). Производные от Metallica, Slayer, Sepultura и т.п.

Но спустя год оказалось, что все стандартизировано и пришлось мучительно переучиваться. Да, в те времена мы еще на ZX спектрумах кодили, про интернет и не знали. А спросить за музыку было не у кого. Все методом тыка, всё на слух. Эх, это было прекрасное время.

Короче все зависит от твоего облачного провайдера, твоей инфры и вообще всё индивидуально. У меня инфра в основном вся в Selectel. Там есть разграничение по проектам. В каждом проекте можешь заводить любое количество инстансов. Ну я думаю везде что-то похожее, в яндексе по крайней мере также. В aws уже не помню, в DO тоже есть.

✔️ Моя схема как давать погоняла железякам.

База данных = db1
Редиска = rd1
Вебнода (nginx + php) = w1
Админки (nginx + php) = a1
Реплика БД = r1
Микросервисы = d1 (daemons)
Стораджи = st1
Балансировщик = b1

По итогу имею примерно такое:

bashdays-b1 (балансировщик)
bashdays-w1 (вебнода 1)
bashdays-w2 (вебнода 2)
bashdays-w3 (вебнода 3)
bashdays-a1 (админки 1)
bashdays-r1 (реплика БД)
bashdays-st1 (могильник файлов)
bashdays-st2 (реплика могильника)
bashdays-db1 (база данных)
bashdays-r1 (редиска)
bashdays-d1 (микросервисы, демоны)

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

Если уж и надо глянуть регион, лезу в панельку селектела и смотрю в каком ДЦ у меня все это лежит. Но обычно это требуется когда пишешь тикет в саппорт. А так нахер надо. Учись упрощать!

Про балансировщик нагрузки писал в этом посте, как заебись его организовать и полезный пост по заголовкам и проксипасам. Мастрид.

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

Хоть «ебанутый-носорог-1» назови, главное чтобы тебе комфортно было.

Знаешь же поговорку — Никого не слушай, НО прислушивайся! Хороших выходных тебе, увидимся.

Кстати расскажи в комментах как ты называешь свои сервера, очень интересно послушать. Всё, теперь точно до завтра!

tags: #bash #linux

@ВАSНDАYS | BАSHDАYS.CОM

🙂 Мухаха, наебнёмка SSH

Вводные: У клиента есть сервак с авторизацией по ssh ключам. С виду все настроено верно. Катают ансиблом.

Проблема: При подключении к серверу, продолжает запрашиваться пароль. Хотя явно указан ключ для подключения, а на сервере прописан публичный ключ клиента в authorized_keys.

Проблема на самом деле распространенная. Для отладки открываем логи авторизаций и смотрим что происходит. И да, никто блядь не читает логи, а сразу начинают искать суслика, которого нет. ЧИТАЙ ЛОГИ!

Понятно дело, в логах видим ошибку:

message repeated 4 times: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys

С этой ошибкой ты всяко бодался. Смотрим права. И действительно, на файле authorized_keys стоят 3 топора (777). А должно быть 600. Как фиксить, ежу понятно.

✔️ \033[1m Но сейчас про другое \033[0m

Как сказать пингвину, чтобы он забил хуй на проверку прав для этих ключей?

А вот так, добавляем в /etc/ssh/sshd_config строчку:

StrictModes no

Ну и рестартим демона systemctl restart sshd

Всё. Теперь можешь играться с правами ключей. Хоть 000 выстави. Права проверяться не будут и тебя успешно пропустят без пароля.

Когда StrictModes установлено в no, SSH сервер не будет так строго проверять права доступа к этим файлам и каталогам. Это означает, что, например, если домашний каталог пользователя имеет права доступа, которые обычно не допускаются (например, другие пользователи могут читать каталог), SSH сервер все равно будет работать.

Установка StrictModes no уменьшает уровень безопасности, так как позволяет некоторым нежелательным правам доступа с точки зрения безопасности, но это может быть полезно в некоторых сценариях, например, при развертывании на тестовых серверах или в средах, где безопасность не является приоритетом.

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

Финк диферент!

tags: #linux #debug

@ВАSНDАYS | BАSHDАYS.CОM

Event loop из семи залуп.

✔️ Сегодня запускаем bash скрипт из nginx по локейшену.

Идея такая, при открытии урла в браузере https://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

✔️ Сделаем за час в течение недели

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

Тестирование проводилось на кандидатах, которые претендовали на роль бэкенд разработчика. Ща будет жара!

Короче всем кандидатам назначалось одно время для собеса. Собиралось 5-10 человек. Всем вручали кубик-рубика. Включали таймер на 15 минут и понеслась пизда по кочкам.

Как ты понял, нужно было за 15 минут собрать эту шайтан игрушку. В лучшем случае из 10 человек, успешно собирали двое. Всех остальных вышвыривали обратно на мороз с фразой — мы вам перезвоним.

А дальше была битва на ножах? Неа! Брали на испытательный сразу двух человек и выживал только один (как в фильме Горец), самый скилловый, который за 3 месяца меньше всего нафакапил и принес больше денег фирме.

Вот такие вот эксперименты над людьми. Думаю они до сих пор это практикуют, так как, там напрочь отбитое начальство. Не удивлюсь если девопсов начали проверять на детекторе лжи.

Я проработал там 5 лет и ни разу у меня не было root доступа. Как я работал без рута? Шеф вводил пароль и сидел рядом пока я пилил таски. Пиздец…

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

Есть тут доля правды, ради интереса поспрашивал своих бэкендеров, сука, все как один сказали — да, мы можем собрать кубик, похуй хоть 3x3 хоть 13x13. Демоны какие-то )))

Задал этот же вопрос фронтэндерам, в ответ получил — Рома, ты ёбнутый, мы кнопочки двигаем, а не в кубики играем.

Вот и выводы. Если ты не умеешь собирать кубик-рубика, то ты не можешь быть бэкендером. Можешь конечно, но недостаточно хорошим.

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

А ты умеешь собирать кубик? Я вот нет, да и в бэкендеры не особо хочу. Но один раз по мануалу собрал, удовольствия особого не испытал.

tags: #рабочиебудни

@ВАSНDАYS | BАSHDАYS.CОM

Трудно быть багом

Тыдыжь! Может, башнем? Обязательно башнем. И не раз. Весь прод в труху.

✔️ Сегодня трём за экспорты.

Имеется задача: нужно создать переменную в bash и затем отменить её экспорт. НО чтобы переменная не сбросилась. Она должна быть доступна в текущей оболочке, но не подпроцессам.

Вроде все очевидно, а нихуя! Погнали в лабораторию.

1. 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ОM

Открытие костыльного цеха

Привет. Все бэкапы, как и полагается я сжимаю через tar + gzip. Ну повелось так. Можно сказать это устоявшийся стандарт.

Но моя ебанца покоя не даёт, вот и в этот раз сижу, думаю — а хули так долго все сжимается, у меня 32 ядра на сервере с репликой, диск не самый плохой. А оно еле ворочается.

Пошел ковырять кишочки, оказывается у меня gzip хуярит на одном ядре. Не понял. Так и есть. Говорят что с версии 1.7 все изменилось и оно само подстраивается под железо. НИХУЯ, у меня 1.10. Из коробки работает одно ядро.

Хм, может для gzip есть какой-то ключ? Бегло пробежался, в хелпах про threads ничего нет.

Ну раз так. Расчехляем свиней. PIGZ!

PIGZ (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ОM

Лишаем Linux девственности

Доброе утро друзья. Сейчас покажу как попасть в секретный каталог в Linux. И в 99%, ты никогда раньше в нём не был.

Для этого тебе понадобится портал, который уже есть в твоем дистрибутиве.

Запускам Bash и вводим:

cd //

Опа-опа, нихуя!

user@server:/$ cd //
user@server://$

Видишь два слеша в промте? Поздравляю, дефлорация прошла успешно. Даже не нужно было вводить IDDQD, чтобы активировать «годмод».

И где это мы? В пизде! Ну а чо гадать, давай посмотрим:

user@server:/$ cd //
user@server://$
user@server:/$ pwd
//

Хм, понятнее не стало… Давай посмотрим что находится у нас в этом каталоге, делаем ls -la.

И что же мы видим? А видим мы содержимое корневой директории. Для чистоты эксперимента можешь запустить так ls -la /////// и получишь такой же результат.

Получается никакого секретного каталога нет? Получается так. Нас наебали? Расходимся. Не совсем.

✔️ Почему так? Откуда берется второй слэш?

POSIX в своём описании, говорит, что три и более слешей могут быть заменены на один слеш. Нужно это для канонизации текущего рабочего каталога.

Что такое 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ОM

Привет отдыхающим. Хош не хош, а постом вас нужно порадовать и желательно интересным. Вот сейчас и порадую, самое время.

Сегодня будем дебажить и багфиксить. Узнаем что такое core файлы в Linux и как с ними взаимодействовать.

Иногда в Linux появляются какие-то странные файлы, с названием core.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ОM

Привет, этот пост должен был выйти вчера, но тупоголовые боты видимо прислушались к моему совету и решили устроить себе выходной.

Если ты не уверен, что сегодня выходной, этот Bash скрипт тебе поможет:

if [[ $(date +%u) -gt 5 ]]; then
    echo 'А вот и нет! У меня выходной!'
    exit 0
fi

Вот прям сейчас возьми и встрой это во все свои поделки на проде. И ни один крон не заставит их работать по выходным.

✔️ Скрипты тоже должны отдыхать!

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

А если ты живешь в жопе мира, например в племенах Масаи и спишь под кустом, естественно скрипт нужно немного адаптировать. Ведь у тебя выходные дни будут выпадать на другие дни недели. Учти это!

Ну красота же! Прям рубрика «Вредные советы» получилась. Экспериментируй.

tags: #linux #bash

@ВАSНDАYS | BАSHDАYS.CОM

Флюгегехаймен

Ну а что тут ответить, живи теперь с этим. С вас 50 тыщ рублей! В психологи что ли пойти. У меня прям получается 🫥

Чем круче контора, тем больше будет хуйни на собесах. «Канализационные люки» и «Дом для семьи жирафов на луне» никто не отменял.

Прикинь если на собесах такую дичь спрашивают, какого тебе будет работать в такой компании?

Будешь пилить задачи в стол которые не имеют смысла. Такого ты себе желаешь? Конечно нет!

Голову не грей, в 99% случаев все эти собесы сделаны так, чтобы посмотреть — как быстро ты психанешь и убежишь в слезах.

Ну любят эти черти HRы своё ЭГО потешить и ЧСВ лишний раз размять.

Когда мне давали подобные задачи, я честно говорил — я не буду это делать, потому что я ебал! Не я себя продаю, а вы пришли ко мне и позвали на собес.

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

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

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

✔️ Они как собаки, чувствуют страх. Испугался — тебе песда!

Не взяли, ну и хер с ними. Значит эта компания — не твоё! В любом случае у тебя копится ценный опыт, со временем обрастаешь кожей, перестанешь на весь этот цирк обращать внимание.

Ты же в айти крутишься, тут и не такое бывает.

А самое главное, чем раньше начнешь копить финансовую подушку, тем увереннее будешь чувствовать себя на собесах.

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

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

Всегда иди туда, где страшно!

Ну и челендж — сможешь написать Bash скрипт на поиск Акронимов и устроиться в Яндекс? Кидай в комментарии, будет интересно!

tags: #рабочиебудни

@ВАSНDАYS | BАSHDАYS.CОM

⚡️ 14-летний школьник из Москвы сошел с ума собирая KDE из исходников

Сижу в потоке, правлю nginx.conf, птички поют, коты ебутся, весна!

Запускаю nginx reload, хм, ничего не изменилось… Лезу в nginx.conf, а в нем все мои локейшены, которые я добавил — похерены отсутствуют.

Почесываю свою лысую кабину. Ага, значит какой-нибудь puppet агент тут крутится или ансибл.

Смотрю процессы, паппета нет, смотрю логи auth на момент подключения ансибла. Да блядь. Пусто! Смотрю логи крона и сам крон, ничо нет. В логах нет — нихуя!

Списываю всё на глюки симуляции этого мира и магнитные бури. Добавляю еще раз локейшены, перезапускаю nginx, сука! Локейшенов нет ))

Курю, бегаю по каталогам, размеренно думаю. Ииии замечаю забавнейшую вещь. В корне каталога etc есть директория .git!!! Вот и сложился пазл. Картина маслом.

Как я и думал, здесь установлен ETCKeeper.

Эта такая херабора, которая отслеживает изменения в каталоге etc. Если что-то изменилось, оно это откатывает из git репозитория.

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

Штука довольно интересная, в своё время я ее втыкал где только можно. Очень полезна от криворуких разработчиков/тестировщиков с рутом. Которые ломают и потом утверждают, что они ничего не делали.

А ты просто смотришь диффы в git и тыкаешь их носом как нагадивших в макбук котяток.

Ставится эта штука очень просто, через apt, ну а дальше почти из коробки работает, достаточно сказать с каким репозиторием ей взаимодействовать и по желанию добавить всякие конфиденциальные файлы в .gitignore.

Давай позабавимся:

apt install etckeeper git
cd /etc
git remote add origin [email protected]: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

➡️ Пока ты дочитаешь этот пост, в мире умрёт 100+ человек. И они никогда уже не узнают про Linux таймеры.

А ты узнаешь!

Тыж всяко в курсе, что планировать регулярные таски в Linux можно не только через cron и его форки, а еще и через systemd + таймеры.

Каждый уважающий себя админ, пытается навязать мне эти таймеры. Мол, Роман ты заебал, нужно использовать таймеры, зачем тебе этот легаси cron. На дворе 2024 год, нужно идти в ногу со временем.

Справедливо? Неа!

Чтобы добавить таску в крон, мне потребуется секунд 15, а то и меньше. А чтобы провернуть это с таймерами, придется знатно упороться.

Давай сделаем простой таймер. Для начала создадим сервис, который будет запускать bash скрипт.

Создаем файл /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

Как говорится: «Дай человеку рыбу — он будет сыт целый день. Научи его пользоваться Linux и он будет сыт этим дерьмом всю оставшуюся жизнь»

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

Есть Bash скрипт:

#!/bin/bash

case $1 in
    3)
        echo "Уровень 3"
        ;&
    2)
        echo "Уровень 2"
        ;&
    1)
        echo "Уровень 1"
        ;;
    a)
        echo "Уровень A"
        ;&
    b)
        echo "Уровень B"
        ;&
    c)
        echo "Уровень C"
        ;;
esac

Что непонятного в этом скрипте? Правильно, где-то используется конструкция «;&», где-то «;;» а еще может быть «;;&».

✔️ Ватафак? Поехали разбираться.

Все эти конструкции влияют на логику работы оператора case.

И, как обычно, этот синтаксис вводит в заблуждение, а порой даже разрывает жопы у бывалых инженеров. Но на самом деле все просто.

Запускаем скрипт с параметрами:

./bashdays.sh 3

Получаем:

Уровень 3
Уровень 2
Уровень 1

Понял что произошло? Скрипт нашел тройку в параметре и отработал до символа «;;», выведя на экран все 3 кейса. То есть получается символ «;&» отработал как «ДАВАЙ ДАЛЬШЕ», а символ «;;» как BREAK.

Аналогично если запустим так:

./bashdays.sh a

То получим второй кусок кейса, который выведет:

Уровень A
Уровень B
Уровень C

Просто? Просто! Погнали дальше.

Если забить хуй в параметре например «двойку», то получим такое:

Уровень 2
Уровень 1

Уровень 3 уже пролетает как фанера над Парижем.

С этими кейсами нужно быть особо аккуратным, так как это тонкий лед и нужно не запутаться в логике. Есть еще «;;&» но он почти идентичен «;&», про него чуть ниже.

У меня с этим вечная проблема, но я нашел годный лайкфак — сначала рисую логику на бумажке и потом по ней уже пишу скрипт. Работает кстати хорошо и для всяких ИФов.

Получается так:

;; - Обозначение конца блока для текущего случая case. Когда интерпретатор bash встречает «;;» он завершает выполнение текущего блока и переходит к следующему ветвлению (если оно есть).

;& - Обозначение «проваливания» (fallthrough) в case операторе. Когда интерпретатор bash встречает «;&», он продолжает выполнение следующего блока кода без остановки, даже если условие не соответствует.

;;& - аналогично «;&», за исключением того, что после выполнения кода текущего случая, интерпретатор также завершает текущий блок кода и продолжает выполнение следующего случая.

;) а это просто подмигивающий смайлик.

Можно кстати еще аналог wildcard использовать в case:

case $1 in
    ba*)
        echo "все что начинается на ba"
    ;&

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

С пятницей, всем хороших предстоящих выходных, берегите себя!

tags: #linux #bash

@ВАSНDАYS | BАSHDАYS.CОM

Linux всем надоел?

Привет. Сегодня поговорим про полезную утилиту, которой я лично пользуюсь для поиска всякого говна на Linux серверах.

В контексте говна выступает всё то, что не должно быть на серваке. К примеру собранные их исходников древние артефакты и т.п.

Короче софтина ищет все файлы, которые попали на сервак в обход пакетного менеджера. Ну и которые были установлены из левых источников, либо созданные самими пользователями.

✔️ Называется Сruft, ставится через апт, или чего там у тебя.

apt install cruft

cruft - Check the filesystem for cruft (missing and unexplained files)

А дальше запускаем. НО из коробки она будет въедливо и долго шуршать. Поэтому заранее сообщаем ей, какие директории нужно проигнорировать.

Например, я знаю что установлен docker и мне в отчете это видеть не обязательно. Справедливо и для всяких mysql и т.п.

cruft --ignore /boot --ignore /sys --ignore /home --ignore /var/lib/docker -r ~/bashdays-report.txt

Тем самым ты уменьшишь свой отчет и потратишь меньше времени на анализ.

Отчет выглядит примерно так:

cruft report: Fri Apr 19 10:00:07 UTC 2024

---- unexplained: / ----
    /usr/local/sbin/fuck.sh
    /usr/local/sbin/growroot
    /usr/local/sbin/ttyd
    /usr/local/sbin/validator
    /usr/local/share/fonts/.uuid

В отчете ты найдешь ОЧЕНЬ много интересного, особенно если это сервак клиента или ты устроился на новую работу и нужно въехать в инфраструктуру. А может найдешь какую-нибудь хитро запрятанную малварю.

Из отчета выше я вижу какой-то Bash скрипт /usr/local/sbin/fuck.sh о котором не знал. А оказывается я его писал очень давно и совсем про него забыл. Опа. А если я бы похерил сервер, то и скрипт бы похерился. Обидно. А еще вон какой-то validator затесался, явно тоже самописная приблудина.

Короче очень удобно искать подобные вещи, о которых ты не подозреваешь или забыл.

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

Советую присмотреться, ни раз мою жопу выручал во время миграций со старых серваков на новые.

Давай! Не смею больше отвлекать 🥳

tags: #linux #utils

@ВАSНDАYS | BАSHDАYS.CОM

Почему 99% девопсов жирные?

Ну ясно понятно, из-за стресса, а не из-за того, что много жрут и ведут сидячий образ жизни.

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

✔️ Утилита называется — debsums

Она предназначена для проверки целостности файлов, которые установлены пакетным менеджером. Вроде хуйня, а НЕТ! Инструмент — мастхэв.

Из названия уже понятно, что проверка целостности пакетов будет проходить на основе контрольных хэш сумм.

Откуда берутся эталонные хэши?

При установке пакетов и т.п. все эталонные, контрольные суммы попадают в «базу данных», которая находится тут: /var/lib/dpkg/info.

В ней содержатся файлы с данными, которые и использует debsums для проверки.

Например, nginx-common.md5sums

dba41b  system/nginx.service
17d6d7  package-hooks/source_nginx.py
9e33ba  nginx-common/NEWS.Debian.gz
6c278a  nginx-common/README.Debian

Ну дак вот. Debsums либо идет сразу в коробке, либо ставится через пакетный менеджер.

У меня в Селектел на убунте 22 уже была предустановлена, хотя локально её не было. Имей это ввиду.

Запускаем так

debsums -a

В этом случае, будут проверяться все хэш суммы, всех файлов. Это дохуя долго, но иногда полезно если разбираешься с сервером, на который через php залили крипто-майнер или нечто подобное.

Если нужно проверить только измененные:

debsums -ac

Опять же очень полезно при миграциях с сервера на сервер.

А для проверки только конфигов:

debsums -ae

Например, я в душе не ебал что файл php.ini кто-то правил, а debsum мне это подсказал. И я не зафакапил.

После отработки команды, имеем список измененных файлов:

/etc/crontab
/sbin/start-stop-daemon
/etc/modprobe.d/blacklist.conf
/etc/nginx/sites-available/default
/etc/php/8.1/fpm/pool.d/www.conf
/etc/sysctl.conf
/etc/sudoers
/etc/pam.d/sudo
/etc/systemd/zram-generator.conf

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

Указав ключ -x весь её высер можно сразу выгрузить в файл. В отчет попадут только измененные файлы.

Из минусов — пиздец долго всё ищет (при полной проверке). Запускаем и идем пить кофе/смотреть мультики. Но это приятное ожидание, плюсы покрывают минусы.

Рекомендую взять на вооружение, утилита довольно пиздатая и достойна твоего внимания.

Подобных утилит много, из тех что я знаю: AIDE, Tripwire, rkhunter, chkrootkit, ossec, Lynis. Присмотрись и к ним, возможно найдешь среди них что-то интересное под свои задачи.

Ну вот и всё. Пойдука я чайку хапну. Хорошего тебе дня!

tags: #linux #utils

@ВАSНDАYS | BАSHDАYS.CОM