Ну чо, расчехляем 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 [email protected]

Если все сделал правильно, то поздравляю, ты изолировал пользователя в системе и должен увидеть командную строку и что-то вроде -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 [email protected] << 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

Большинство утилит/программ/скриптов и т.п. работают с временными файлами. Сначала они создают этот временный файл, пишут в него какие-то данные, а на выходе отдают готовый результат, будь то файл с выгрузкой либо что-то другое. А временный файл с которым производилась работа, естественно зачищается.

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

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

Этот случай я успешно отдебажил. Временный файл удалялся ДО того как стать файлом выгрузки. Почему? Потому что процесс удаления временного файла работал в отдельном потоке (thread) и удалял временный файл спустя 30 секунд.

А так как выгрузка с каждым годом становилась все больше, 30ти секунд стало мало. По итогу временный файл удалялся, а на выходе создавался пустой файл без каких либо данных. Естественно никакой обработки эксепшенов в бинарнике не было, вечный статус - завершено успешно! Файл же есть на выходе, значит успешно. Не поспоришь.

На такие ёбнутые случаи и нужен strace, чтобы хоть немного понять, что происходит.

Короче расчехляем нашу лабораторию и создаем скрипт. Бинарники мучить не будем, bash скрипта будет достаточно для понимания.

#!/bin/bash

echo $UID > /tmp/test.txt
unlink /tmp/test.txt

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

1. Записываем во временный файл /tmp/test.txt этот самый UID.
2. Удаляем временный файл.

Почему не rm а unlink? Потому что в моём случае это был именно unlink, который я нашел просматривая лог strace. Чем отличается unlink от rm, расскажу в следующих постах.

Так, подопытный скрипт есть. Запускаем так:

strace -yfe inject=unlink:error=EACCES ./script.sh

В этой конструкции мы говорим strace, чтобы проинжектил наш системный вызов unlink и передал ему насильно ошибку EACCES (Permission denied).

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

[pid 677954] unlink("/tmp/test.txt") = -1 EACCES (Permission denied) (INJECTED)

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

По умолчанию инъекция будет сделана всем системным вызовам unlink, но есть возможность указать диапазон или конкретный индекс срабатывания. В этом посте можешь глянуть как узнать конкретный индекс (смотри строчку с when=4+).

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

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

Вот такие приключения порой случаются. Изучай. Хорошего дня!

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

Привет. Чем отличается команда rm от unlink? Давай смотреть. Обе эти команды умеют удалять, но в 99% ты используешь именно rm, потому что про unlink ты либо не слышал, либо тебе rm с головой хватает.

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

Как устроен процесс удаления файлов в linux, расскажу в следующих постах, сегодня у нас битва rm vs unlink.

У unlink есть всего лишь два ключа запуска help и version. Очень ограниченный инструмент, но чем инструмент проще, тем проще его синтаксис.

# unlink /tmp/hardlink
# unlink /tmp/file

Софтина очень молчаливая — как мужик. После удаления, она промолчит и ничего не выведет на экран.

Команда unlink использует системную команду unlink, в то время как команда rm использует системный вызов unlinkat. Оба системных вызова практически одинаковы.

Unlink не умеет работать с wildcard и globbing шаблонами. Так же ты не сможешь с помощью нее удалить каталог.

Короче одни минусы. А нахрена тогда она нужна? Ооо брат, сейчас расскажу. Запускаем команду и пытаемся насильно удалить файл которого нет в каталоге:

rm -f test.txt

И получаем - НИЧЕГО. То есть rm -f не вернуло ошибку, что файл отсутствует. А если сделать так:

unlink test.txt

получаем ошибку:

unlink: cannot unlink 'test.txt': No such file or directory

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

Короче с unlink можно гибче обрабатывать эксепшены в скриптах. А еще при использовании команды unlink отсутствует проверка безопасности. Она удалит файл, защищенный от записи. Хотя современная версия rm теперь тоже так умеет.

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

chattr +i test.txt

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

Ключ i - сделает файл неизменяемым. Чтобы снять с файла этот аттрибут, в команде которая выше, замени знак «+» на «-».

Подытожим. Для большинства повседневных задач конечно rm мастхев, но если ты пишешь софт для каких-то критичных систем, стоит не упускать из виду unlink.

Увидимся вечером.

tags: #linux #bash
—
💩 @bashdays

Писал писал я вам интересный пост на вечер, про очередные офигительные циркули gpt+terminal+bash, а потом понял, что эта сука денег через какое-то время хочет. Собственно, как и любая AI херовина, наивный. Короче заскамили мамонта. Форс мажор. Ну бывает… Раз не сложилось, давай так:

shopt -s cdspell

shopt — встроенная команда оболочки, управляет опциями. Изменяет значение внутренних конфигурационных параметров оболочки.

Далее делаем:

cd /va
cd /otp
cd /Home

Ха! Мы попадаем в каталог var/opt/home. Понял/а? Эта надстройка в терминале исправляет ошибки. Из коробки. Клёва!

Призываем древнейшее зло:

shopt -s autocd

Теперь вводим:

/etc/cron.d
~root
..
~-

1. Переход в директорию /etc/cron.d
2. Переход в хоумдир рута
3. Переход в папку на уровень выше
4. Переход в предыдущую директорию

Заметь что я не писал команду cd! Оно само…

Хз на сколько это вообще практично, но как видишь такое возможно. Изучай, может станешь фанатом этой фичи )

tags: #linux #bash
—
💩 @bashdays

Привет, о че нашел: пасхалка в текстовом редакторе nano.

1. Запусти редактор nano
2. Перейди на новую строку
3. Нажми CTRL+X, а затем Y
4. Назови файл: zzy и нажми Enter

Сочетание ^X + Y + zzy, вероятно, является ссылкой на xyzzy, чит-код, первоначально использовавшийся в Colossal Cave Adventure.

Получается из nano нельзя будет сохранить файл с названием zzy.

Там телега скоро запилит нормальное форматирование кода (в бете 4.10.4 уже работает). Наконец-то дождались, так что скоро все будет по красоте и без костылей. Я себе воткнул, уматно вообще!

tags: #linux #трудовыебудни
—
💩 @bashdays