Bash Days | Linux | DevOps

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

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

Но как мы знаем, всё уже придумано за нас, так получилось и в моем случае. Порыскав на просторах вселенной, я нашел несколько сервисов, которые позволяли мышкой натыкать нужную конфигурацию цветов и получить готовый ANSI код. Самым топовым сервисом оказалась поделка ansicodes никому не известного разработчика. Собственно так и бывает, великие умы - славы не ищут. 💩 Сервис доступен по этой ссылке 🐱 Страница проекта на github Натыкиваешь мышкой нужную тебе конфигурацию цветов для консоли, по итогу получаешь готовый ANSI код, который вставляешь в свои скрипты и получаешь новогоднюю елку. Четко, быстро и без депрессий. Ну и можно на свой сервак воткнуть, там ничо сложного нет, обычный html + js. Есть альтернатива 🐱 ansi, выполнена в роле отдельной утилиты, которую можно воткнуть в систему. Проект известный, но опять же в узких кругах. Но тут есть зависимости, а я не люблю зависимости, предпочитаю использовать коробочные инструменты. Ну и всегда помни - если собираешься добавлять цвета в свой скрипт, всегда добавляй опцию —no-color, чтобы люди, анализирующие выходные данные скрипта, не испытывали к тебе ненависти. Вот такие пироги! tags: #linux #bash #utilites — 🟢 Подпишись: @bashdays

🚀Переезжаем в будущее! Мир IT меняется буквально каждый день и, чтобы оставаться в тренде, нужно постоянно обучаться. Изучите возможности, которые позволят вывести вашу разработку на новый уровень! 🔥На бесплатном открытом уроке «Переезжаем в EDT из Конфигуратора» от OTUS: регистрация На вебинаре онлайн-курса «DevOps 1C» мы обсудим: — Почему из Конфигуратора в EDT можно переходить уже сейчас. — Обзор возможностей, которые в корне изменят ваш процесс разработки. — Практика работы в EDT в Git. — Умение эффективно работать с ветками и лаконичное оформление истории своей работы в Git. Преподаватель Юрий Пасхин – программист-разработчик в компании ЕАЕ-Консалт. Это отличная возможность бесплатно протестировать формат обучения и задать преподавателю любые вопросы в режиме реального времени! 👉Пройдите бесплатное вступительное тестирование прямо сейчас и зарегистрируйтесь на событие: регистрация Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2VtzqvyHF39

Эх суету красоту навести охота! Привет. С помощью чего можно сделать красивые диалоговые боксы в скриптах и утилитах? Много всяких есть штук, но мне больше всего зашло использовать 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

Привет коллеги. Как-то нашел на просторах 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

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

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

⚡️ Узнайте свой уровень знаний K8s ⚡️ Пройдите квиз из 15 вопросов и узнайте свой уровень знаний, а также свою готовность к обучению на продвинутом онлайн-курсе — «Инфраструктурная платформа на основе Kubernetes». Обучение проходит на Kubernetes v1.24. ➡ ПРОЙТИ КВИЗ: https://clck.ru/35vXvg ❗️На курсе вы пройдете весь путь разработки инфраструктурной платформы на основе Kubernetes и получите все необходимые навыки, которые позволят вам вырасти до платформенного инженера. 🎁 Пройдете успешно квиз, бонусом получите доступ к записям прошедших вебинаров курса + демо-ролик о курсе. Курс доступен а рассрочку. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2Vtzqx7hzoc

Привет. Что-то мало мне было двух выходных, надеюсь хоть ты отдохнул от информационного шума. Ладно, к делу. В предыдущем посте мы с тобой рассмотрели линтер для bash. А сегодня познакомимся с утилитой shfmt. Это не очередной линтер (но то же умеет орать на ошибки), это утилита для форматирования и синтаксического анализа скриптов. Байда написана на golang и поддерживает оболочки POSIX, Bash и mksh. Так что утилита не ограничена одним лишь bash. Ставится из пакетного менеджера apt/yum install shfmt. Ну и запускается так же элементарно:

shfmt script.sh

Скармливаем утилите свой прекрасный скрипт, а на экран выводится приятный глазу отформатированный результат. Ну либо не выводится, если встречаются какие-то логические ошибки. Короче утилита выкашивает весь ненужный трешак, но сохраняет «наверное» работоспособность скрипта. Чтобы каждый раз не копипастить результат форматирования, у shfmt есть ключ -w, указав его, результат сразу перезапишется в файл над которым проводятся эксперименты. Какого-то жесткого кодстайла нет, всё настраивается через ключи, например можно указать количество пробелов и т.п. Закидываем в алиасы и пользуемся. Я обычно использую shfmt для подготовки скриптов для публикации в публичные репозитории github. Чтобы оупенсорц гуру гавном не закидывали на этапе плохого форматирования. По секрету скажу, что в личных проектах (да и не только) особо никто не придерживается какому-то определенному форматированию. Все пишут как курица лапой нравится, главное чтобы это работало. Практика плохая, ну лучше плохо чем вообще никак. Да и девчонки плохих любят. Вечером про отладку или обфускацию скриптов поговорим. На связи! tags: #linux #bash #utilites — 🟢 Подпишись: @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

‼ Как обезопасить свое веб-приложение от взлома? Узнать, где оно наиболее уязвимо. Приглашаем 4 октября в 20:00 по мск на открытый вебинар «Разбор уязвимостей OWASP Top 10 Web» от Отус. Вебинар является бесплатной частью полноценного онлайн-курса «Внедрение и работа в DevSecOps». Курс доступен в рассрочку. 🧐 На вебинаре мы рассмотрим самые часто встречающиеся веб-уязвимости и научимся классифицировать их согласно терминологии OWASP, включая Access Control, Cryptographic Failures и другие. 🟠 Посетив вебинар вы будет знать: - основы OWASP Top 10 Web; - практическое решение и эксплуатацию уязвимостей; - значение анализа уязвимостей для обеспечения безопасности вашего веб-приложения; Полученные знания помогут вам сделать свое веб-приложение безопасным и защищенным от возможных угроз! 👉🏻 Регистрация на вебинар: https://clck.ru/35t5xn Не упустите свой шанс научиться защищать свой проект! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2Vtzqw8RfFY

Пум пурум, сегодня еще один неочевидный способ восстановить удаленные файлы в 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

И снова привет. Есть такие утилиты 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

❓Хотите с нуля разобраться в cистемном администрировании систем Linux? Начните с инструмента LVM — менеджера логических томов. 👉 Приглашаем на открытый урок курса «Administrator Linux» Тема: Linux LVM для начинающих: разбираемся с системой управления томами На занятии мы разберем ключевые аспекты: - как работать с дисками и разделами - какие минусы в таблице разделов - что нам дает технология LVM 📌 Знания LVM просто необходимы для решения повседневных задач по распределению пространства на дисках Больше полезного о Linux вы узнаете на онлайн-курсе в OTUS. 👉 Зарегистрируйтесь, чтобы принять участие и получить запись https://otus.pw/PGaT/ Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: LjN8KWF9A

Не всегда есть возможность писать 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

Там кстати телега выкатила обнову, где позволяет смотреть сторисы от каналов. Если у тебя есть премиум подписка и вкатывает мой контент, бустани, это бесплатно 😎но предварительно нужно обновить клиента если не обновлен. Для открытия нового функционала нужно совсем немного, чтобы я вам годноты подогнал в формате сторис. ХЗ на сколько это зайдет, но было бы интересно попробовать. Всем заранее спасибо! Жму руку! 👇 🔉 BOOST 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

Приходила идея спарсить весь github? Мне нет! А вот некому чуваку такая идея пришла и он замутил интерактивную карту по открытым git репозиториям. По итогу коллекция составила более чем 400к репозиториев. Масштабно, ничего не скажешь. Ну собрал и собрал, нам то какое дело? Читай дальше! А самое главное тут, что под все эти данные, он сделал интерактивную онлайн карту. Каждая «страна» на карте это репозитории, написанные на одном языке или фреймворке. Например, Pythonia = Python, а Swiftoria - на Swift. Имена стран генерились с помощью chatgpt таким запросом:

Please analyze these repository and detect a common theme (e.g. programming language, technology, domain). Pay attention to language too (english, chinese, korean, etc.). If there is no common theme found, please say so. Otherwise, If you can find a strong signal for a common theme please come up with a specific name for imaginary country that contains all these repositories. Give a few options. When you give an option prefer more specific over generic option (for example if repositories are about recommender systems, use that, instead of generic DeepLearning)

Хм, буду теперь названия переменных придумывать таким способом, пусть проклятые роботы за меня пашут. И даже поиск работает, чудо 🍴 Можно натолкнуться на достаточно интересные штуки, которые известны лишь узкому числу лиц и особо нигде не пиарятся. Потыкать карту можешь: 🐱 тут. Страница проекта с подробностями: 🐱 тут. tags: #services #git — 🟢 Подпишись: @bashdays

Погрузитесь в мир 🐳 DevOps и станьте devops-инженером за рекордные 4 месяца с курсом от Merion Academy! Все, кому интересно, получат 🚀 2 бесплатных урока, где расскажут, кто такой DevOps-инженер, какие инструменты использует, куда и как развивает карьеру. Познакомитесь с Docker и контейнирезацией и закрепите знания. 🎁 Бонус – интенсив по развитию карьеры, где HR-эксперты расскажут как создавать сильные резюме и проходить собеседования. 📜 Плюс гайд по командам Docker. 🕺У ребят одна из самых доступных цен, которая в разы ниже, чем в других онлайн-школах, а еще есть рассрочка для тех, кто хочет учиться сейчас и платить по чуть-чуть ежемесячно. 👉 Регистрируйтесь по ссылке чтобы забирать бесплатные уроки, интенсив по карьере и гайд. Merion Academy – это экосистема доступного образования, которая включает в себя: 📍IT-базу знаний с полезными статьями. 📍Youtube-канал ,где простыми словами говорят о сложных вещах. 📍 IT-академию, где обучат востребованным направлениям по самым доступным ценам.

Возможно ли на 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

📈 Программисты Ruby имеют хорошие перспективы карьерного роста. Ruby и Ruby on Rails - это востребованные технологии, которые используют крупные сервисы и бренды. Умение разрабатывать собственные приложения, веб-сайты или стартапы на Ruby увеличит вашу ценность в глазах потенциальных работодателей. 🔝 Начните изучение Ruby on Rails на бесплатном открытом уроке «Тестирование в Ruby on Rails» от OTUS. На занятии рассмотрим технику разработки TDD (разработка через тестирование) в Ruby и преимущества такого подхода. Открытый урок подойдет людям, которые уже имеют опыт с каким-либо языком программирования. Это отличная возможность совершенно бесплатно протестировать формат обучения и задать преподавателю любые вопросы в режиме реального времени! 💻 Вебинар пройдёт 21 сентября в 20:00 мск в рамках курса «Ruby и Ruby on Rails Developer». Язык Ruby и фреймворк Ruby on Rails популярны во всем мире, включая Россию, благодаря своей гибкости и производительности в веб-разработке. 🔜 Регистрируйтесь бесплатно прямо сейчас и ставьте событие в календарь, чтобы ничего не пропустить. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru