Задался вопросом какая же все-таки оболочка быстрее? У меня на серверах можно встретить такой зоопарк: sh, bash, ksh, mksh, posh, zsh. Почему так много? Не знаю, сервера достались по наследству, видимо остатки от давно сгинувших девопсов по реке Стикс.

На своей локальной машине использую исключительно zsh со всякими наворотами:

🐱 Oh My Zsh - прибомбасина для zsh
🐱 autosuggestions - автокомплит

На серверах алогично Oh My Zsh + autosuggestions ну и нативный bash для скриптов, все остальное — неведомая хрень.

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

Дополнительно из плагинов включаю 🐱 zsh-syntax-highlighting чтобы красивенько было. Ну а чтобы каждый раз не указывать ssh ключи при подключении к серверам, использую встроенный плагин ssh-agent.

plugins=(git zsh-syntax-highlighting zsh-autosuggestions ssh-agent)
zstyle :omz:plugins:ssh-agent agent-forwarding on
zstyle :omz:plugins:ssh-agent identities home_rsa work_rsa2 her_rsa3
zstyle :omz:plugins:ssh-agent lifetime

Вернемся в теме - кто быстрее. Очевидно же что bash! Давай убедимся.

Запустим этот скрипт в bash:

for i in $(seq 1 1000);
do bash -c ":" ;
done

Запускаем через time: time bash speed.sh

time - оценивает по времени производительность любой задачи, выводя после её завершения затраченное время: реальное, пользователя и системы. Через time можешь оценивать производительность по времени любых своих скриптов.

После запуска получаю: 0m1.242s

Скрипт отслеживает точное время открытия шелла 1000 раз без выполнения каких-либо операций.

Ок, теперь давай запустим этот скрипт в zsh: time zsh speed.sh

Результат: 0m1.344s

Не такие и большие различия. Даже можно сказать ничтожные. Но это всего лишь один тест. Чтобы получить какие-то средние значения воспользуемся утилитой:

🐱 shellbench

Устанавливаем и запускаем:

git clone https://github.com/shellspec/shellbench.git .
shellbench -s bash,zsh sample/*

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

Хм, в совокупности тестов получается что zsh где-то прям намного шустрее, да даже ни где-то, а прям почти лидирует в производительности.

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

Вывод: По результатам тестов, zsh оказался быстрее чем bash, но не везде. Опять-же тут все индивидуально.

Кстати когда запускаешь на macos midnight commander + zsh в роле оболочки, то mc запускается прям кое как, секунды три наверное. Поэтому с mc я использую bash, можно конечно этот момент отдебажить, но мне лень. Если когда-нибудь руки дойдут, напишу как пофиксил.

А вообще самая быстрая оболочка это Dash (Debian Almquist Shell). Это POSIX-совместимая реализация Bourne Shell. Она заменяет /bin/sh в скриптах по умолчанию и обеспечивает улучшенную скорость, потребляя при этом меньше ресурсов. Dash превосходит bash/zsh по производительности, но его нельзя использовать, так как он не предназначен для взаимодействия.

❓ А какую оболочку используешь ты и почему?

Кстати всем привет! Надеюсь твои выходные прошли без проишествий. Увидимся!

tags: #linux #utils
—
💩 @bashdays

Возможно ли на bash отрендерить какой-нибудь шаблон? Например, как в ansible? Конечно возможно! Сейчас покажу.

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

Создаем шаблон: nginx.tpl

user ${nginx_user};
worker_processes auto;
pid ${pid_path};
include /etc/nginx/modules/*.conf

Всё то, что нужно отрендерить, располагаем в ${параметр}.

Создаем скрипт с логикой:

>> nginx_gen.sh && chmod +x nginx_gen.sh

Символы «>>» означают - создать новый файл. А чмодиком делаем файл покорным и исполняемым.

Еще есть фича с созданием файла через touch nginx_gen.sh. Если запустить команду с touch повторно, то файл не перетрется, НО у него обновится дата и время создания. Иногда бывает полезно обновлять дату и время каким-нибудь файлам, которые выполняют роль флагов.

Так, поехали рендерить:

#!/bin/bash

function render {
  export nginx_user=$1 pid_path=$2
  cat nginx.tpl | envsubst > /etc/nginx/nginx.conf
}

if [[ $(hostname) == "production" ]]; then
  nginx_user="www-data"
  pid_path="/run/nginx.pid"
  render $nginx_user $pid_path

else
  nginx_user="nginx"
  pid_path="/var/run/nginx.pid"
  render $nginx_user $pid_path
fi

Разбираем портянку. Логика простая, если hostname равен production, то присваиваем одни переменные. Во всех других случаях присваиваем другие переменные.

Далее вызываем функцию render и передаем в нее nginx_user и pid_path. Функция render всё это дело экспортирует в переменные окружения, а затем с помощью envsubst заменяет их в шаблоне. Готовый конфиг сразу попадает в папку с nginx. Охуенно! Кайф!

envsubst - заменяет переменную окружения новым значением в формате строки оболочки командной строки. Переменные могут быть заменены в формате ${var} или $var

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

Собственно на этом можно и заканчивать. В 99% случаев все используют какой-то вонючий perl, sed, eval и т.п. Но решение с envsubst намного гибче и элегантнее.

Есть еще вариант с Heredoc. Heredoc-синтаксис — способ определения строковых переменных в исходном коде программ.

Пример скрипта, делает то же самое. Логику добавлять не стал:

#!/bin/bash

nginx_user="www-data"
pid_path="/var/run/nginx.pid"

cat > /etc/nginx/nginx.conf << EOF
user ${nginx_user};
worker_processes auto;
pid ${pid_path};
include /etc/nginx/modules-enabled/*.conf;
EOF

Отрендерится как нужно, но мне все же ближе вариант с envsubst. Нагляднее чтоли. Выбор лишь за тобой, на каком велосипеде кататься. Вот такие пироги. Ладно, побежал я дальше работу работать. Будьте здоровы! Увидимся!

tags: #linux #bash
—
💩 @bashdays

Всем доброе утро, день, вечер, ночь. Наконец-то выходные и слак с моттермостом немного подзаткнулись. Сегодня рассмотрим ситуацию, когда ты случайно/специально удалил исполняющийся bash скрипт.

Ситуация: У меня в фоне на сервере крутится bash скрипт, который отслеживает какие-то процессы. Работает годами, но приходит коллега и случайно/специально зачищает папку /usr/local/sbin. Опа и скрипта моего больше нет. Мне чо его заново что ли писать? Блять! Жопа!

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

Ладно. Скрипт мой сгинул, в git я его не положил. Чо делать? Так. Скрипт удалён с диска, но продолжает крутиться в фоне, это уже хорошо. Значит его можно как-нибудь восстановить. Сейчас покажу как.

Давай создадим подопытный скрипт: touch /tmp/script.sh и закинем в него такое:

#!/bin/bash
sleep 1000
exit

Делаем исполняемым chmod +x /tmp/script.sh и запускаем в фоне /tmp/script.sh &

Символ & может служить разделителем между командами command & command, две команды выполнятся параллельно.

Так, скрипт запустили, он крутится у нас фоне, давай теперь удалим сам файл:

rm -f /tmp/script.sh ключ -f = force, удалит без лишних вопросов.

Окей. Файл удалили. Как восстановить? Выполняем:

lsof -c 'script.sh'

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

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
script.sh 261899 root 255r REG 8,1 51 130773 /tmp/script.sh

Берем PID = 261899, берем FD = 255 и делаем сальто-мортале:

cat /proc/261899/fd/255

Опачки, что мы видим? Исходник скрипта, который мы удалили:

File: /proc/261899/fd/255
#!/bin/bash
sleep 1000
exit

Копипастим, вставляем, сохраняем и гордимся своими охренительными скиллами.

Почему это возможно? А почему бы и нет! В следующих постах расскажу про общую концепцию удаления файлов в Linux и все станет прозрачным.

Про восстановление файлов на диске, я как-то ранее уже писал тут, но там была немного другая история (когда мы знаем physical_offset).

☑️ читать:

man 5 proc # /proc/[pid]/fd/
man lsof 

Всем хороших выходных и берегите себя!

tags: #linux #bash
—
💩 @bashdays

И снова привет. Есть такие утилиты base64/base32/basenc которые кодируют/декодируют информацию, наверняка ты про них знаешь. Так вот, если утилита встречает во входных данных некорректный символ, она прекращает свою работу. Например:

echo '!0LPQsNCy0L3Qvg==' | base64 -d
base64: invalid input

А как она понимает какой корректный символ, а какой нет? А тот который входит в алфавит кодирования. Символ новой строки, также входит в этот алфавит и просто игнорируется утилитой, где бы этот символ не находился.

Алфавит кодирования содержит латинские символы A-Z, a-z, цифры 0-9 (всего 62 знака) и 2 дополнительных символа.

В приведенном выше примере, символ «!» не входит в этот алфавит. Чтобы декодировать данные, можно удалить символ восклицательного знака. Но мы с вами калачи тертые и любим всё необычное. Поэтому просто указываем ключ -i и все символы, которые не входят в алфавит кодирования, просто-напросто будет проигнорирован. Заебись! Хорошо!

echo '!0LPQsNCy0L3Qvg==' | base64 -di

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

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

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

Типа того (вставил ! в середину строки):

echo '0LPQsNC!y0L3Qvg==' | base64 -di

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

echo 'Съешь ещё этих мягких французских булок и разжирей 0YXRg9C5' | base64 -di

Текст в игнор, а данные раскодируются.

Таким образом можно защищать передаваемые данные между фронтом и бэкендом по API. Отловил кто-то POST запрос, выудил из него закодированную строку base64, а расшифровать не получается.

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

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

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

Ладно, надеюсь было познавательно, всем добра!

tags: #linux #utilites
—
💩 @bashdays

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

Валяется у меня скриптик ~/fs.sh, приходит жопарукий Петя и удаляет его через rm -rf ~/fs.sh. Козлина! Ни о какой корзине речь и идти не может.

Но я примерно помню, что было внутри. А было там нечто подобное:

#!/bin/bash
echo "Fucking"
exit 1

Что делать? Ну во первых прописываем прицельную двоечку в безмозглую кабину Пете. Ну а если ты на удаленке, то просто пишем в корпоративную аську — Пётр, вы 3.14дарасина.

Во вторых запускаем команду:

grep -a -C 200 -F 'Fucking' /dev/sda1

Оно там подумает какое-то время и начнет вываливать на экран всякий мусор. Ну а среди этого мусора будет удалённый исходник скрипта. Копипастим/Вставляем и снова радуемся своим скиллам.

Теперь по ключам:

-a = осуществляем поиск в бинарных файлах.
-C = сколько строк выводить ДО и ПОСЛЕ каждого совпадения строки.

То есть у меня совпала строка Fucking, если я не укажу -С 200, то увижу в выводе только echo "Fucking". А нам то нужно восстановить весь скрипт полностью. Поэтому и нужно сказать грепу, давай еще выведи 200 строк до и 200 после.

Кстати с ключом -C удобно грепать логи какого нибудь php, где нужно посмотреть контекст ошибки, обычно она на несколько строк простилается.

-F = строка, по которой будем искать.

Естественно указываем свой раздел диска, у меня это /dev/sda1, у тебя может быть что-то совсем другое. Учти этот момент.

Почему это работает? Если коротко - мы воспользовались философией Unix, которая гласит — Всё есть файл!

Такие дела. Чётко и полезно, забирай в копилку знаний. Вечерком еще что-нибудь интересное напишу, пока правда не знаю про что. На связи!

tags: #linux #recovery
—
💩 @bashdays

В прошлом посте я затронул тему с grep, так вот. У grep есть хороший ключик -q. При указании этого ключа, утилита прекращает свою работу, как только нашлась заданная подстрока. Это правильная оптимизация и ей нужно пользоваться если нужно проверить наличие подстроки в файле.

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

head -c 1G /dev/urandom > /tmp/large

Если head не понимает буковку G в размере, то указываем явный размер файла: -c 1073741824.

Так, файл размером 1G готов /tmp/large, дальше запускаем:

strace -P /tmp/large -ye read grep -q 's' /tmp/large

Ключи:
-P = путь до файла
-y = выводит имя пути до файла
-e = команда которую дебажим

Через секунду, на выходе получаем нечто подобное:

read(3</tmp/large>, "v\310*A\307\16\324m&V8H\202\326\177\244\3059\27}00_\274\300<\245.X\27\310`"..., 98304) = 98304
+++ exited with 0 +++

То есть с опцией -q, grep не стал читать полностью весь гигабайтный файл, а сделал лишь один системный вызов read(3</tmp/large) и тут же завершил работу. Искомая строка нашлась, вернулся статус 0. Про статусы выхода я писал в этом посте.

Делаем то же самое без strace и проверяем статус выхода, все ли идентично:

grep -q 's' /tmp/large
echo $?

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

Если коротко, некоторые версии grep с ключом -q могут вернуть статус выхода 2. Так что на разных системах работать может по-разному. Если в своих скриптах проверяешь эти статусы, логика может сломаться, будь аккуратнее с этим.

Еще нюанс, можно добиться такого же поведения grep, но без ключа -q. Это сработает, если вывод перенаправлен в /dev/null. Ну это и логично, нам не нужен никакой вывод на экран и нет никакого смысла продолжать читать огромный файл если подстрока уже найдена.

strace -P /tmp/large -ye read grep 's' /tmp/large > /dev/null

Утилита grep (без ключа -q) так же сделает один системный вызов read и прекратит свою работу, как только найдет первое совпадение.

Вроде не сложно рассказал, по крайней мере попытался. Ладно, рад всех видеть, побежал дальше работу работать, сумасшедший какой-то день. Пока пока!

tags: #linux #bash #debug
—
💩 @bashdays

Привет. Что-то мало мне было двух выходных, надеюсь хоть ты отдохнул от информационного шума. Ладно, к делу. В предыдущем посте мы с тобой рассмотрели линтер для bash. А сегодня познакомимся с утилитой shfmt.

Это не очередной линтер (но то же умеет орать на ошибки), это утилита для форматирования и синтаксического анализа скриптов. Байда написана на golang и поддерживает оболочки POSIX, Bash и mksh. Так что утилита не ограничена одним лишь bash.

Ставится из пакетного менеджера apt/yum install shfmt. Ну и запускается так же элементарно:

shfmt script.sh

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

Чтобы каждый раз не копипастить результат форматирования, у shfmt есть ключ -w, указав его, результат сразу перезапишется в файл над которым проводятся эксперименты.

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

Я обычно использую shfmt для подготовки скриптов для публикации в публичные репозитории github. Чтобы оупенсорц гуру гавном не закидывали на этапе плохого форматирования.

По секрету скажу, что в личных проектах (да и не только) особо никто не придерживается какому-то определенному форматированию. Все пишут как курица лапой нравится, главное чтобы это работало. Практика плохая, ну лучше плохо чем вообще никак. Да и девчонки плохих любят.

🐱 Страница проекта на github

Вечером про отладку или обфускацию скриптов поговорим. На связи!

tags: #linux #bash #utilites
—
💩 @bashdays

Ну чо, расчехляем strace и погнали ковыряться в кишках. Сегодня будем проводить эксперимент над утилитой mktemp, которая входит в состав пакета coreutils.

mktemp, создает временный файл (по умолчанию) или директорию и возвращает имя созданного файла. Я ее использую для хранения промежуточных данных, когда нужно создать какую-то рандомную папку или файл и положить туда какой-нибудь мусор.

Задача - понять что произойдет если временный файл или папка уже существует. Будет ли mktemp создавать папку или файл с другим именем и сколько раз она это будет делать.

Для начала надо узнать с помощью какого системного вызова создается файл, запускаем:

strace -Yyf mktemp

Y = выводим команды с привязкой к PIDs
y = выводим пути привязанные к дескрипторам файла
f = мониторим форки процессов

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

openat(AT_FDCWD</root>, "/tmp/tmp.V0051oIfmC", O_RDWR|O_CREAT|O_EXCL, 0600) = 3</tmp/tmp.V0051oIfmC>

Ага, отловили openat. Идем сюда читать список ошибок которые возвращает openat.

Меня интересует:

EEXIST pathname already exists and O_CREAT and O_EXCL were used.

Если были заданы флаги O_CREAT и O_EXCL и файл существует, то возвращается ошибка EEXIST.

Дополнительно нужно выяснить с какого по счету системного вызова будем перехватывать и возвращать ошибку. Суть в том, что при запуске mktemp есть несколько вызовов openat. Их делает динамический загрузчик. Если их перехватить, то программа просто не запустится. Также нужно избавиться от нескольких вызовов openat которые совершает система языковых переводов. Для этого нужно установить значения переменной LC_ALL в POSIX.

Выводим все openat которые делает утилита:

LC_ALL=POSIX strace -Yyfe openat mktemp

У меня получилось 4 строки:

openat(AT_FDCWD</root>, "/etc/ld.so.cache")
openat(AT_FDCWD</root>, "/lib/x86_64-linux)
openat(AT_FDCWD</root>, "/dev/urandom")\
openat(AT_FDCWD</root>, "/tmp/tmp.eyg53MQ1c2")

Вызов создающий временный файл у меня по счету 4й. Выпускаем кракена:

LC_ALL=POSIX strace -YCyfe inject=openat:error=EEXIST:when=4+ mktemp

Вот это поворот! Ждем какое-то время и наблюдаем, как на экране бежит какая-то дичь. Это твои личные файлы зашифровываются. Шутки за 300.

Короче дождались пока оно там просрется и выведет табличку с результатами. Смотрим в колонку errors для системного вызова в openat и видим число 238328.

Вот собственно столько раз утилита mktemp будет пытаться создать файл с новым именем, после того как системный вызов будет возвращать ошибку, означающую что файл существует. Получается количество попыток 62**3 = 238328.

Упрямая утилита! Эксперимент завершен, результат получен, мы молодцы!

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

tags: #linux #debug #utilites
—
💩 @bashdays

Привет коллеги. Как-то нашел на просторах github, интересную утилиту под названием Kill Port. Утилита написана bash.

Kill Port - инструмент командной строки для уничтожения процесса, запущенного на определенном порту.

Ситуация. Запускаю я например какое-нибудь nodejs приложение или gunicorn, а оно начинает орать - а у тебя порт уже занят. Начинается беготня с выяснением, а кто это сделал?

Особенно актуально при локальной разработке, где-то в фоне что-то висит и радуется. Естественно никогда не можешь вспомнить, что нужно набрать в консоли, чтобы узнать, какой процесс занимает порт (конечно кроме 80 и 443, все и так знают что это nginx).

Лезешь в гугол, находишь в очередной раз lsof -i :3000, киляешь все это в надежде. И так далее.

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

Можно форкнуть проект и добавить туда известные процессы, тот же nginx и gunicorn, чтобы корректно их завершать, а не килить через -9 (SIGKILL). Хотя это лишнее. Kill Port работает из коробки, что еще нужно.

Есть нюанс при установке, там чет у него в инсталляторе напутано, поэтому просто клоним скрипт killport, кидаем в /usr/local/sbin с атрибутом +x.

Для macos, утилита тоже работает, ставится через brew install killport.

Killport может не завершить процесс в случае определенных процессов работающие на уровне ядра, к примеру nfs / portmapper / wireguard. К ним не прикреплен соответствующий PID, но это крайние случаи. Для большинства сценариев, Killport успешно прикончит процесс.

🐱 Страница проекта на github

tags: #linux #utilites
—
💩 @bashdays

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

А зачем вообще красивые диалоговые окна в консоли? Можно же через read в bash всё прекрасно запрашивать. Да! Справедливо! Но это скучно, гораздо интереснее получить какой-нибудь мало-мальски красивый и интуитивный интерфейс.

Например, когда ты устанавливаешь mysql, оно тебе выводить красивый инпут где нужно ввести root пароль. Либо устанавливаешь linux и нужно выбрать галочками, какие пакеты ты хочешь установить. Ну короче ты понял. Некий GUI.

Вот whiptail и позволяет сделать этот GUI с минимальными усилиями + интегрировать его в свои скрипты.

Устанавливается банально: apt/yum install whiptail, но обычно уже идет из коробки в дистрибутиве.

После установки, можно творить. Синтаксис очень простой:

whiptail --yesno "читаешь @bashdays?" 10 50

Откроется диалоговое окно с двумя кнопками yes/no, с текстом + высотой и длиной.

Помимо инпута yes/no имеется ряд других опций:

msgbox - информативное окно с кнопкой OK
infobox - херня какая-то, мигает и закрывается
inputbox - поле для ввода текста
passwordbox - поле для ввода пароля, скрыт звездочками
textbox - выводит содержимое файла в окне
menu - реализация меню
checklist - чекбоксы
radiolist - радиобатоны
gauge - прогрессбар

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

Теперь про то, как все это замешать в bash скрипты.

Логика простая. Если пользователь выбирает Yes, то whiptail вернет 1. Если No, то вернет 0. Если возникла ошибка, либо принудительное завершение, будет возвращен код -1.

Например:

if (whiptail --yesno "Choose Yes or No" 10 60)  then
     echo "You chose Yes. Exit status was $?"
else
     echo "You chose No. Exit status was $?"
fi

Дефолные кнопки Yes/No можно зареврайтить с помощью опций --yes-button и --no-button.

whiptail --yes-button "Fuck" --no-button "Yeee" --yesno  "What?" 10 60

Теперь вместо Yes/No наблюдаем Fuck/Yeee.

Ну а как получать данные, которые ввели руками? А вот так:

NAME=$(whiptail --inputbox "What is your name?" 10 60 3>&1 1>&2 2>&3)

exitstatus=$?
if [ $exitstatus = 0 ]; then
     echo "Your name is:" $NAME
else
     echo "You chose Cancel"
fi

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

Реализация меню:

OPTION=$(whiptail --menu "Choose" 15 60 2 "1" "Linux" "2" "Windows" 3>&1 1>&2 2>&3)
 
exitstatus=$?
if [ $exitstatus = 0 ]; then
     echo "Your chosen:" $OPTION
else
     echo "You chose Cancel."
fi

В остальных случаях всё делается идентично. Но что такое 3>&1 1>&2 2>&3? Это магия и скучная теория.

Перенаправление ввода-вывода stdin/stdout/stderr. Если коротко, без этого ничего не заработает. Скучная теория. В будущем расскажу про все эти перенаправления stdin/stdout/stderr на котиках. Пока просто делай как написано.

На закуску лови реализацию прогрессбара, тут хоть что-то происходит и движется:

{
  for ((i = 0 ; i <= 100 ; i+=20));  do
     sleep 1
     echo $i
  done
} | whiptail --gauge  "Loading..." 6 60 0

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

💩 Картиночки собрал тут, чтобы визуально оценить масштабы всей этой суеты.

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

tags: #linux #bash #utilites
—
💩 @bashdays

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

Типа такого:

echo -e "\x1b[39;42mBashdays"

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

Самым топовым сервисом оказалась поделка ansicodes никому не известного разработчика. Собственно так и бывает, великие умы - славы не ищут.

💩 Сервис доступен по ссылке
🐱 Страница проекта на github

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

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

Ну и всегда помни - если собираешься добавлять цвета в свой скрипт, всегда добавляй опцию —no-color, чтобы люди, анализирующие выходные данные скрипта, не испытывали к тебе ненависти.

Вот такие пироги!

tags: #linux #bash #utilites #services
—
💩 @bashdays

Коллеги порой интересуются: Роман, а как ты слез с VSCode и пересел на vim? Есть какие-то мануалы и тренажеры?

А зачем тебе перелазить на vim? Чтобы что? Мануалов и тренажеров пруд пруди. Но всё это пустая трата времени. Самый эффективный способ пересеть на vim, это практика.

Просто открываешь vim и начинаешь писать в нем код. По ходу дела у тебя возникают вопросы:

1. А почему ничего не печатается?
2. А как сохранить то, что я напечатал?
3. А есть ли файловый браузер в сайдбаре?
4. А как какать?
5. А как искать нужную мне строчку?
6. А как отсюда выйти без перезагрузки процессора?
и т.п.

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

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

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

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

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

На главный вопрос — А зачем я перелез на vim? Чтобы что? Увы, ты правильно ответить не сможешь. Возможно потешить своё ЭГО, повыебываться перед коллегами, отказаться от мыши, увеличить скорость работы. Всё спорно и относительно. Миграция на vim сопоставимо вопросу — а в чем смысл жизни?

Если ты с детства не приобщился к vim, подумай хорошо, а нужно ли тебе оно? В зависимости от твоего выбора, зависит твоя дальнейшая судьба. Остаться собой или познать нирвану.

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

А за что ты любишь vim?

tags: #рабочиебудни
—
💩 @bashdays

В этот прекрасный осенний выходной, будем компилировать bash скрипт в бинарный файл. Да, да! И такое возможно.

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

Встречаем Shc (Shell Script Compiler)

Shc принимает скрипт, который указан в командной строке и создает исходный код на C. Затем сгенерированный исходный код компилируется. Утилита shc сама по себе не является компилятором, она кодирует и шифрует сценарий оболочки.

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

На выходе получаешь исходник на сях и готовый бинарник. Ставится все это дело так:

apt/yum install build-essential gcc
apt/yum install shc 

Давай создадим бинарник:

shc -f test.sh

Рядом с файлом появятся еще 2 файла: test.sh.x и test.sh.x.c (первый это бинарник, второй исходник).

Проверяем:

file test.sh.x

test.sh.x: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c265ebae7158a2c51461e890c15fdacb1cc81cb1, for GNU/Linux 3.2.0, stripped

У shc есть множество ключей, к примеру ты можешь задать триальный период и бинарник будет превращаться в тыкву после определенной даты. Либо повысить уровень евристики и запутать реверс-инженера.

Минус тут один, это не golang и бинарник будет работать на схожих linux системах. Но это не страшно, пишешь в readme требования к запуску и снимаешь с себя ответственность.

🐱 Страница проекта на github

Вечером увидимся, далеко не убегай. Давай 🤝

tags: #linux #bash #utilites
—
💩 @bashdays

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

Для этого понадобится chroot, заходим под рутом и готовим подопытную папку env:

cd / && mkdir env
mkdir /env/{bin,lib,lib64}

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

Папку создали, ок, теперь давай закинем в нее сам интерпретатор bash. После того, как пользователь зайдет на сервер по ssh, запустится bash в изолированной среде.

Чтобы определить, какие библиотеки использует утилита, воспользуемся утилитой ldd.

ldd /bin/bash

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

На экран вывелись библиотеки, которые использует bash

libtinfo.so.6 => /lib/libtinfo.so.6
libc.so.6 => /lib/libc.so.6
/lib64/ld-linux.so.2

Их нужно закинуть в папку env, вот так:

cp /usr/bin/bash /env/bin
cp /lib/libtinfo.so.6 /env/lib
cp /lib/libc.so.6 /env/lib
cp /lib64/ld-linux.so.2 /env/lib64

Всё. Базовая изоляция готова. Для того чтобы после авторизации на сервере, пользователь попал в изолированную папку, делаем так:

Добавляем в конфиг: /etc/ssh/sshd_config



Match User user
ChrootDirectory /env

В первой строке, в конце указывает имя пользователя, которого будем изолировать, у меня в системе есть пользователь user, я его и указываю.

Далее дергаем systemctl restart sshd и пробуем залогиниться на сервер под пользователем:

ssh user@bashdayz.ru

Если все сделал правильно, то поздравляю, ты изолировал пользователя в системе и должен увидеть командную строку и что-то вроде -bash-5.1$.

Самый сок, в том, что никакие команды сейчас не работают, чтобы ты не вводил. Ты можешь лишь посмотреть версию bash --version или другие ее ключи.

Для того чтобы добавить в эту клетку другие утилиты, повторяешь трюк с ldd, копируешь бинарник и библиотеки.

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

Давай закрепим и добавим утилиту ls в нашу клетку:

ldd /usr/bin/ls

cp /usr/bin/ls /env/bin
cp /lib/libselinux.so.1 /env/lib/
cp /lib/libc.so.6 /env/lib/
cp /lib64/ld-linux.so.2 /env/lib64
cp /lib/libpcre2-8.so.0 /env/lib/libpcre2-8.so.0

Смотрим зависимости через ldd и копируем их в нашу изолированную папку env. Теперь возвращаемся в терминал к пользователю user и пробуем запустить ls. Опа! Работает! Прекрасно! Попробуй теперь посмотреть файловую систему с помощью ls и убедись в наличии клетки.

Тема с chroot очень клевая, помимо того, что мы с тобой сейчас провернули, в chroot можно устанавливать полноценные дистрибутивы linux (возможно у тебя был сексуальный опыт с gentoo). Либо примонтировать proc/sys/dev/run с хостовой машины и сделать работу в chroot идеальной. Но это не совсем безопасно, тут уже тебе выбирать, удобство или параною.

А можно сделать 10 папок и 10 пользователей и в каждую папку воткнуть свой дистрибутив. Логинишься под user1 и попадаешь в kali, логинишься под user2 и попадаешь в centos. Ну ты понял.

Ладно, изучай, надеюсь было читабельно. Увидимся завтра!

tags: #linux #bash #utilites
—
💩 @bashdays

Работа с архивами и архиваторами, порой добавляет лишнюю головную боль. На уровне ДНК я помню как распаковать zip архив, но никак не могу отрастить нейроны, чтобы запомнить ключи и синтаксис распаковки tar, gz, 7z и т.п.

А запомнить не получается, по причине — я сталкиваюсь с архивами раз в пару недель или реже. Это как в программировании, если на какое-то время сделал паузу, то потом нужно заново проходить экспресс курс. Года два назад я очень хорошо знал JS и angular, сейчас я на них смотрю как баран на новые ворота.

Чтобы раз и навсегда избавиться от боли в работе с архивами я подсел на утилиту atool, которая чёрта лысого распакует/запакует/перепакует и не нужно заниматься лишней возней. Все просто.

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

Работает элементарно, скармливаем утилите архив, а она его распаковывает.

atool -x shell.zip
atool -x shell.tar.gz
atool -x shell.7z
atool -x shell.rar

Не нужно вспоминать никакие ключи и т.п. Указал ей -x или -X и погнали, а если еще и alias сделать, так вообще можно ничего не указывать. Клёва!

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

Давай создадим разные архивы:

atool -a -e -F .tar.gz shell
atool -a -e -F .zip shell
atool -a -e -F .7z shell
atool -a -e -F .rar shell

Да, тут аж 3 ключа, но как я писал ранее, загоняй их в alias и можно потом вообще про это не париться.

По итогу получили 4 архива не вспоминая синтаксис архиваторов. Главное чтобы эти архиваторы были установлены в системе.

Развлекайся! Вечером наверное еще увидимся, посмотрим как по рабочей нагрузке будет. Хорошего тебе понедельника!

tags: #linux #utilites
—
💩 @bashdays

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

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

Bashunit это минималистичная библиотека тестирования Bash. Тестируйте свои bash-скрипты самым быстрым и простым способом.

Давай посмотрим как это работает и напишем первый тест:

Устанавливаем:

curl -s https://bashunit.typeddevs.com/install.sh | bash
ln ~/lib/bashunit /usr/local/sbin/bashunit

Все это добро залетит в папку: ~/lib/bashunit. Ну и симлинк сделаем для удобства. Если посмотреть исходник bashunit, то увидим что, оно тоже написано на bash. Bash тестирует bash, красиво.

✅ Кто не знал, символ ~ означает домашнюю директорию текущего пользователя. А то сейчас начнешь искать, куда же эта тварь установилась.

Теперь создаем папку где будем складывать тесты: mkdir ~/tests. В этой папке создаем файл first_test.sh и закидываем в него такой код:

#!/bin/bash

var="hello"

function test_var_equals_hello() {
assert_equals "hello" $var
}

Запускаем:

cd ~/
bashunit ./tests

Получаем результат теста: All tests passed

bashunit - 0.8.0
Running first_test.sh
✓ Passed: Var equals hello

Tests: 1 passed, 1 total
Assertions: 1 passed, 1 total
All tests passed
Time taken: 133 ms

Assert_equals принимает 2 параметра, первый = ожидаемый результат, второй = фактический результат.

Получается такое: Переменная var у меня равна «hello», ожидаемый результат в тесте тоже «hello». Происходит сравнение и успешное завершение. Но если поменять значение var на что-то другое, то получим ошибку.

bashunit - 0.8.0
Running first_test.sh
✗ Failed: Var equals hello
Expected 'hello'
but got 'fuck'

Tests: 1 failed, 1 total
Assertions: 1 failed, 1 total
Some tests failed
Time taken: 128 ms

Помимо assert_equals, есть куча других методов проверки: assert_contains, assert_empty, assert_matches, assert_exit_code, assert_array_contains, assert_successful_code, assert_general_error, assert_command_not_found, assert_file_exists, assert_is_file и т.п.

Весь список можешь посмотреть в официальной документации с наглядными примерами.

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

Если ты девопс и делаешь какое-нибудь тестовое задание связанное с написанием скриптов. Добавь автотесты и твои шансы получить оффер намного повысятся. Техдиры такое любят. Сразу видно, что человек следует бест-практикам и работает на результат, а не за деньги 📺

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

💩 Официальный сайт фреймворка
🐱 Страница проекта на github
🐱 Старенькая альтернатива shunit2

Увидимся!

tags: #linux #bash #qa
—
💩 @bashdays

Давай замутим ченить свое, простое и полезное. В этом посте изобретем шаринг файлов/папок с серверов прямо к себе в телеграм. Будем использовать bash и API телеграма.

Задача:

1. Нужно создать tar.gz архив файл/папку на сервере.
2. Закинуть этот архив себе в телеграм.
3. Почистить за собой.

Для начала сделаем телеграм бота, идем в @BotFather и получаем токен, вида: 11223344:HUYPIZDADJIGURGA. Я назову бота bashdayz_bot.

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

Так, токен есть. Теперь нужно узнать ID своего пользователя в телеграм. Опять идем в бота, но в другого @RawDataBot, запускаем и смотрим поле: "chat": {"id": 1234567890}.

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

Накидываем прототип скрипта shellshare

#!/bin/bash

chat_id=""
bot_token=""

stamp=$(date +%d%m%Y_%H%M%S)
filename=$1-$stamp.tar.gz

tar -czvf $filename "$@"

curl -F chat_id="${chat_id}" -F parse_mode="HTML" -F document=@"$filename" https://api.telegram.org/bot${bot_token}/sendDocument

rm $filename

В переменную chat_id закидываешь id, который забрал у RawDataBot. А в переменную bot_token пишешь токен, который забрал у БотБати.

Так, все готово. Теперь нужно запустить своего бота. Идем в телегу и ищем @bashdayz_bot которого создали в самом начале поста. Запускаем его. Ну вот и все, проверяем.

./shellshare /var/log/nginx/
shellshare access.log error.log

Создастся tar.gz архив, с названием одноименной папки/файла и прилетит тебе в бота @bashdayz_bot (но бот у тебя естественно будет с другим именем). После отправки, архив зачистится с сервера, чтобы место не занимать.

В скрипте использует нативное API телеграма через curl. А символ "$@" означает что скрипту можно передавать несколько папок/файлов, то есть массив. Но если в этом скрипте передать массив, то имя архива будет с именем первой папки, пусть тебя это не смущает. Если нужно будет, зафиксишь под свои нужды, мы делаем лишь прототип.

По желанию можешь сменить архиватор, впендюрить шифрование имен и установить пароль. Либо вообще через gpg криптануть.

Можно еще в curl передать caption, тогда в телеграм тебе придет архив с подписью, чтобы потом можно было ориентироваться что это такое.

curl ... -F caption="${caption}" ...

В переменную caption передай текст, который нужен для подписи к архиву.

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

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

Тема с ботами интересная и много где применяется, у меня мониторинг на такое завязан да и куча еще всего. Даже если ты не делаешь бэкапы в телеграм, то знать как взаимодействовать с API телеги, необходимо. Однажды пригодится, когда начальник поставит задачу, а ты уже имеешь прокаченный скилл и понимание как это работает. Банально отправлять сообщения из gitlab при успехе/факапе отработки пайплайна.

Дорабатывай, изучай. Удачи!

tags: #linux #bash
—
💩 @bashdays

сегодня на изи, картинка...

tags: #рабочиебудни
—
💩 @bashdays