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

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

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

1. Rextester - bash version: 4.4.20
2. Mycompiler - bash version: 5.1.16
3. Leetcode - bash version: 5.0.17

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

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

Что прикольно, через скрипт можно создать какой-нибудь подопытный файл например echo "test" >> /tmp/test.txt и потом с ним продолжить работу прям из скрипта cat /tmp/test.txt. То есть редакторы позволяют работать с файловой системой и не ограничены лишь компиляцией.

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

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

tags: #services #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

Привет! При работе с длинными консольными командами, возникает некий дискомфорт. Буквально вчера пришлось запускать docker контейнер без всяких композов и прочих обвязок. Команда получилась НУ 3.14здец длинной и не читаемой.

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

Вставляешь в инпут свою монструозную команду и на выходе получаешь человеческое чтиво, разделенное символам переноса. Короче тулза ништяк все это форматирует и по итогу не надо самостоятельно бегать и тыкать 100500 раз кнопку Enter. Скопипастил себе в блокнотик и редактируешь в своё удовольствие.

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

💩 Сервис в онлайне
🐱 Исходники на github

Можно на свой сервак поставить, если есть желание, там typescript. Но думаю тебе и онлайн сервиса за глаза хватит.

Вечером поговорим наверное про хердок «HEREDOC» или про что-то другое. Увидимся! Лови котиков 🥺 👍 🏃‍♂️

Ну и всем лёгкой рабочей пятницы и хороших предстоящих выходных!

tags: #bash #services
—
💩 @bashdays

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

Что это такое? Ну смотри, допустим ты пишешь башник и оказываешься в ситуации, когда тебе нужно передать многострочный кусок текста, какой-нибудь команде типа cat, tee, ssh и т.п.

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

cat << EOF
SUKA BLYA CURRENT DIR: $PWD
YOU ARE LOGGED IN ASS: $(whoami)
EOF

В этом примере я передаю команде cat две строки текста, в первой есть переменная среды PWD, во второй команда whoami.

По итогу выхлоп будет такого плана:

SUKA BLYA CURRENT DIR: /home/user
YOU ARE LOGGED IN ASS: user

Как видишь PWD и $(whoami) автоматически подставились. Ну и главная фича, что я не использовал для вывода команду echo. При другом раскладе код был бы таким:

echo "SUKA BLYA CURRENT DIR:" $PWD
echo "YOU ARE LOGGED IN ASS:" $(whoami)

Согласись, что с «хердоком» это выглядит более лаконичным. Не нужно писать 100500 echo. Хердокаешь и меньше говнокода становится.

Теперь давай выполним такой код:

cat << "EOF"
SUKA BLYA CURRENT DIR: $PWD
YOU ARE LOGGED IN ASS: $(whoami)
EOF

Заключив EOF в кавычки, я запретил заменять переменные, команды и спецсимволы.

Короче на экран выведется такая шляпа:

SUKA BLYA CURRENT DIR: $PWD
YOU ARE LOGGED IN ASS: $(whoami)

Видал да? PWD и $(whoami) не заменились, а остались в прежнем виде. Заебись Хорошо!

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

cat <<- EOF
    Hello
    Bitch
EOF

В первой строке я добавил символ «-».

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

Перед «Привет» и «Пляж» я нажал TAB. Короче символ «-» позволяет делать отступы в коде с лидирующим Табом.

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

Теперь запускаем такое:

cat << EOF > output.txt
SLUNI DO POLU $PWD
HERANUKA PO ROYALU $(whoami)
EOF

А чо произошло? Хе… а весь выхлоп, который должен был вывестись на экран — сохранился в файл output.txt. Вот такая магия! Если файл не существует, то создастся новый.

Ну а если хочешь файл дополнить, то вместо «>» используй двойные символы «>>», но думаю ты это и так знаешь.

Передавать поток, можно не только в файл, но и в другие команды. Давай возьмем sed:

cat <<'EOF' | sed 's/i/ee/g'
Rich
Bitch
EOF

По итогу получим, что все символы «i» заменятся на «ee». На экран выведется:

Reech
Beetch

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

Ну и как обычно на закуску, практическое применение этого самого «хердока»:

ssh -T user@bashdayz.ru << EOF
ls -la
date
apt update
uptime
cat /etc/issue
EOF

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

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

На этой ноте, собственно всё. Больше тут и рассказать нечего.

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

Давай! Еще раз хороших тебе выходных, увидимся!

tags: #bash #linux
—
💩 @bashdays

Купил сегодня вентилятор для малины (raspberry pi) на 12v и только потом понял, что на борту платы есть лишь 3v и 5v. Короче собрал из старого и нового один рабочий, взлетело, хорошо быть инженером.

Ладно, давай про strace. Сегодня научимся смотреть что запускает программа и с какими параметрами она это запускает.

Возьмем для испытаний программу man и распотрошим её.

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

Екзекутим такую штуку:

strace -o logs -s1024 -fe execve man bash

Ага, запустилось. Перед тобой открылась страница помощи bash. Что дальше. Дальше нажимаешь клавишу «q», все это дело закрывается.

Давай теперь по ключам, а потом уже разберемся что произошло.

s = длина выводимой строки
f = отслеживаем дочерние процессы
e = какой системный вызов отслеживаем
o = куда сохраним результаты трассировки

Если не указывать ключ «o», то результаты запишутся в стандартный поток STDERR.

И чо? А ничо, давай смотреть результаты, которые записались в файл с именем logs.

cat logs

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

Вот таким образом мы узнали какие утилиты и с какими аргументами запускается программа man для распаковки и форматирования man страниц.

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

Ладно, пойду дальше пиво пить. Не отвлекаю, увидимся!

UPD: Кстати чтобы сделать cat красивым, как на картинке, читай это.

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

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

Наверняка ты знаешь, что при нажатии сочетания клавиш CTRL+D завершится текущая интерактивная оболочка. То есть если ты сидишь на сервере по ssh и нажал CTRL+D, сессия прервется. ОК.

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

Как еще можно завершить сессию с командной оболочкой? Ну например установить значение переменной TMOUT больше нуля. Цифра будет означать секунды.

# TMOUT=5

Текущая сессия закроется через 5 секунд.

Следующий вариант это активировать параметр оболочки «t» с помощью команды set.

set -t 

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

set -t ; read

Выход произойдет, только после нажатия клавиши Enter. А в примере ниже:

set -t ; read -t3

Выход будет произведен после нажатия Enter ИЛИ по прошествию 3х секунд.

Так. Еще есть вариант с параметром «e». Указав его оболочка завершает работу после возникновения ошибки. Например:

set -e ; false

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

Более человеческий пример:

set -e ; Паравозблять

И снова выкинуло. Потому что вернулась ошибка - Паравозблять: command not found.

Что еще упустили… Упустили команду exec. Подвешиваем на стандартный ввод устройство /dev/null.

exec </dev/null

При чтении этого устройства оболочка получит признак конца файла и успешно завершится.

Ааа, еще же exit есть. Не буду его обижать, пусть тоже в этом посте присутствует.

Ну и как обычно, на закуску.

stty eof $'\t'

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

stty (Set Teletype) - Эта команда управляет настройками терминала и позволяет пользователю вносить изменения в терминал и отображать его характеристики.

Всё, стоп! После обеда покажу, как с помощью strace можно инжектить в системные вызовы процессов для отладки некоторых ёбнутых случаев. Увидимся!

tags: #bash #linux
—
💩 @bashdays