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

Как говорится - чтобы что-то спрятать, нужно поместить это на видное место.

Начнём со спойлера:

ls -l /tmp/box

-rw---x--- 
-rw----r--
-rwx--xr--
-rw-r-----
-rw--w----
-rw----r--
-rwxr--r--
-rwx--xr--

Пока ничего не понятно, а если я сделаю так:

./mode2char /tmp/box

-rw---x---     (610)
 1100010 (98)  ('b')

-rw----r--     (604)
 1100001 (97)  ('a')

-rwx--xr--     (714)
 1110011 (115) ('s')

-rw-r-----     (640)
 1101000 (104) ('h')

-rw--w----     (620)
 1100100 (100) ('d')

-rw----r--     (604)
 1100001 (97)  ('a')

-rwxr--r--     (744)
 1111001 (121) ('y')

-rwx--xr--     (714)
 1110011 (115) ('s')

bashdays

Сечешь фишку? Это и называется стеганография. Я спрятал в правах файлов скрытое сообщение «bashdays». Вот тут нам и пригодилась тема с правами доступа и всякими этими системами счислений. Давай разбираться как это работает.

Сами bash скрипты mode2char и char2mode закину в конце поста на гитхаб.

В примере выше у меня сопоставляются права доступа с диапазоном символов 32..126 (ASCII). Если номер 7ми битной кодировки ASCII сдвинуть на два бита, то получаем как раз те самые 9 бит прав доступа.

Давай подвигаем!

Распечатаем диапазон ACSII символов 32..126 в восьмеричном формате:

for i in 10 {32..126} ; do printf '%03o\n' $(( i << 2 )) ; done

На экран вывалится куча всего, что-то похожее на права доступа:

372
376
380

Чтобы преобразовать в обратную сторону делаем так:

for i in 440 524 545 ; do echo $(( 8#$i >> 2 )) ; done

То есть сдвигаем вправо на 2 бита. Из цифр 440, 524, 545 - получили 72, 85, 89.

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

for i in 440 524 545 ; do printf -v hex '\\x%x' $(( 8#$i >> 2 )) ; echo -e "$hex" ; done

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

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

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

Запускается так:

./char2mode /tmp/box 'Welcome to bashdays'

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

Конечно есть нюансы. Скрипт будет орать если что-то не так. Существующие файлы не перезаписываются. Именование файлов соответствуют лексикографическому порядку сортировки. Это нужно для того, чтобы получить ту же последовательность файлов, что и при создании. Скрипт декодирования получает имена используя globbing, который сортирует именно так.

Сам скрипт декодирования лежит тут, запускается аналогично:

./mode2char /tmp/box

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

Выбор велик:

printf '%s\n' {0..7}{0..7}{0..7}
printf '%s\n' {r,-}{w,-}{x,-}{r,-}{w,-}{x,-}{r,-}{w,-}{x,-}

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

Сложно? Конечно! Но думаю общую идею ты понял. Изучай! Увидимся совсем скоро.

tags: #linux #bash
—
💩 @bashdays

Bash скрипт который смог...

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

tags: #bash #hokku
—
💩 @bashdays

Зашел тут разговор, а зачем люди делают touch, перед тем, как что-то записать в файл? Причем так делает большинство, да и в учебниках повсюду это пихают. Но какой в этом смысл, если при записи все равно будет создан файл? Я имею в виду такую ситуацию:

touch file.txt
vim file.txt
:w

все же проще:

vim file.txt
:w

И не нужно никакого touch. Так откуда взялась эта дурная привычка? И дурная ли она? Почему мы не делаем тогда типа такого?

dd if=/dev/zero of=newfile bs=1 count=0

Оно ведь тоже создает новый файл…

На самом деле правильного ответа нет. Единственно что нужно знать, это — используя touch ты всегда будешь уверен, что сможешь записать свои данные в файл.

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

Да и еще touch используется для обновления даты модификации. Кстати очень удобная штука. Например, ты редактировал конфиг nginx в прошлом году, но всем нужно показать что вчера, делаешь touch nginx.conf и проставляется актуальная дата и время. И в bash скриптах можно использовать, если есть какая-то логика с lock файлами, таймштампами и т.п.

А как правильно создавать файлы? А просто! Правильный способ для создания файлов, это любая команда, которая использует системный вызов create или open (с флагом O_CREATE). Таких команд и программ дофига.

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

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

Кстати есть еще такой древний строковый редактор, называется ed. Идет в коробке почти со всеми дистрибутивами. Этот редактор изначально требовал наличия файла перед его редактированием. И да, из этого редактора выйти намного сложнее чем из vim. Попробуй ради интереса.

Как-то так. А как ты создаешь файлы?

tags: #linux
—
💩 @bashdays

Привет, сейчас покажу интересную bash фичу. Которая ну совсем уж не очевидная и про нее мало кто знает.

В bash скрипте можно хранить данные, закодированные в base64. Выглядит это следующим образом:

#!/bin/bash

read_data() {
  mapfile -t DATASET < <(sed '1,/^DATASET/d' "$0" | base64 -d)
}

read_data

echo ${DATASET[@]}

exit 0

DATASET
SGVsbG8gQmFzaERheXM=

Функция read_data считывает данные из самого скрипта. С помощью sed удаляются строки от начала файла до строки DATASET. А затем происходит декодирование оставшихся данных. В конце всё сохраняется в массив DATASET с помощью mapfile и выводится через echo.

Красота! Мой скрипт по итогу выведет на экран «Hello BashDays». Где это можно применить, понятия не имею. Возможно тебе удастся это куда-нибудь приспособить.

Еще в этом скрипте мне не нравится exit 0, если есть мысли как от него избавиться, велком в комментарии. Я чет покопался вчера, но так пока и не победил. Если убрать exit 0, оно будет работать, но в конце грязно выругается.

Бери на вооружение, возможно твой стартап нуждается в этом. Увидимся!

tags: #bash
—
💩 @bashdays

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

Клиенты это обычные пользователи, которые заходят по ssh и пытаются на практике изучать bash и linux. Короче студенты какого-то крупного ВУЗа, а сервер выступает подопытным стендом для всяких лабораторных работ.

Клиентов дофига (человек 800) предупредить о технических работах нет никакой возможности. А если бы и была, то 99% не увидят электронных писем с важной информацией и начнут долбать саппорт.

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

На самом деле тут все просто. Создаем пустой файл /etc/nologin. Теперь только root сможет авторизоваться по ssh. Да, предварительно нужно разрешить вообще заходить под root’ом.

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

Для этого воспользуемся утилитой wall.

Wall — утилита командной строки, которая отображает сообщение на терминалах всех вошедших в систему пользователей.

Запускаем команду:

wall "Быстренько сохраняемся и валим с сервера. В 10:15 сервер уходит в запой."

Все кто был подключен к серверу, получают сообщение:

Broadcast message from root@dev (pts/0) (Sun Dec 17 11:38:21 2023):
Быстренько сохраняемся и валим с сервера. В 10:15 сервер уходит в запой.

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

Ну все, ответственность с себя сняли. В 10:15 запускаем ассасина:

pkill -9 -u `who | awk '{print $1}'| grep -v root|head -1

Вот так вот грубо мы выгнали всех с сервера, кроме root’а. Вот и все, спокойно проводим технические работы, удаляем /etc/nologin и радуемся какие мы молодцы.

Wall можно заменить например на такое:

echo "Hello from BashDays" | write user

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

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

Ну либо так:

echo "Hello from BashDays" > /dev/pts/1

Пытался сделать так /dev/pts/[0-9]*, но чет не проканало, заорала как потерпевшая. Ну это всё костыли, в общем неважно.

Ладно, хорошо тебе провести остаток выходного, увидимся завтра.

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

Тишина у каждого своя, у всех в душе свои оркестры…

Как мы с тобой знаем, в начале скрипта принято использовать строку shebang/hashbang. Это то самое, которое #!/bin/bash. Конечно его не обязательно ставить, но рекомендуется. Ранее этот вопрос разбирался здесь.

Так, но порой вместо привычной нам конструкции, можно встретить нечто подобное:

#!/usr/bin/env bash
#!/usr/bin/env python
#!/usr/bin/env python3

Да, с питончиком тоже такая чача бывает. Но что это за сракафак и зачем? В нашем случае такое хитрое указание интерпретатора имеет смысл.

Основная идея env bash это улучшение переносимости. Никто не может гарантировать, что интерпретатор находится по захардкоженому пути.

Указал ты допустим в скрипте #!/bin/bash, закинул скрипт на сервер, а эндпоинта bin/bash нет. По этой причине господа ребята используют хак с env bash. Использование env позволяет снизить риски за счет запуска команды на основе данных из переменной среды PATH.

Ну и используя env в скрипте можно указывать любые версии интерпретатора. Возможно у тебя стоит две версии bash, ну или как распространено с питончиком. Деприкейтед 2.7 и трёшка. Думаю мысль ты уловил. Чтобы не править скрипты, можно подменять версии интерпретаторов и даже сами интерпретаторы.

Давай посмотрим на практике.

mkdir ~/bin
cp /bin/sh ~/bin/bash
export PATH=~/bin:$PATH
env bash

1. Создаем папку bin в домашнем каталоге
2. Копируем интерпретатор sh в ~/bin, но обзываем его bash
3. Экспортируем новый путь ~/bin в PATH
4. Запускам bash через env

Дела… у нас запустился интерпретатор sh. То есть ~/bin/bash (обращаем внимание на знак ~ = домашняя директория пользователя) был найден раньше, чем просто /bin/bash.

Если посмотреть PATH мы увидим следующее:

echo $PATH
/root/bin:/root:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Наш домашний каталог с бинарниками стал приоритетным. И если теперь в скриптах указать #!/usr/bin/env bash то запустится sh из ~/bin. Ничего сложного. Но на практике обычно никто такой хераборой не занимается. Чисто для примера, ну или для совсем уж костылей, когда нужно быстро и вчера.

Преимущества c env:

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

Недостатки:

- Путь /usr/bin/env банально может не существовать. Но обычно существует.

Ну и если используешь env, в него можно прокинуть параметры, делается через ключик -S:

#!/usr/bin/env -S var1=a var2=b bash --help

Venv в Python работает по такому же принципу, реврайтит PATH и позволяет использовать разные версии.

> index.py
python3 -m venv .venv
source .venv/bin/activate
import sys
print(sys.executable)

/tmp/.venv/bin/python

Если посмотреть PATH (echo $PATH) при активации venv, то увидим совершенно другой PATH:

/tmp/.venv/bin:/home/user/bin:/usr/local/opt/libpcap/bin:/home/user/.pyenv/bin:/opt/homebrew/opt/openjdk/bin

То есть к нашему PATH добавился каталог /tmp/.venv/bin, который стал приоритетнее чем /home/user/bin.

Вот так вот это всё и работает под капотом. Я эти env по большей части никогда не использую, хреначу #!/bin/bash и погнали, пока всегда и везде работало. Конец!

tags: #bash #linux
—
💩 @bashdays

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

На этот случай у нас есть утилита tee, которая как раз этой хераборой и занимается.

command | tee log.txt

На картинке хорошо видно, откуда произошло название tee, это буква T в произношении. Вывод затекает сверху слева и вытекает в двух направлениях. Ты видишь происходящее на экране, а параллельно это происходящее записывается и в файл. Удобно.

Вот как нужно называть утилиты! Взял произношение буквы и можно в коробку упаковывать. Кстати пока писал, вспомнил что английская «H», взяло название от Eighth - то есть восьмая буква алфавита. Короче никто особо не заморачивался с неймингом.

Ну а еще есть подобная утилита, называется просто script. Она позволяет записать всё происходящее на экране сразу в файл. Работает даже в интерактивном режиме. Запустил ты ее и работаешь в консоли, а она пишет все твои действия в кабачок.

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

Я ни tee ни script не использую, потому что всё время про них забываю, да и особой необходимости нет.

Такие дела. Вечерком закину еще чтива, увидимся!

tags: #bash #utils
—
💩 @bashdays

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

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

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

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

А решается эта задача через cgroups.

cgroups (Control Groups) представляют собой механизм в ядре Linux для ограничения, изоляции и управления ресурсами, предоставляемыми группам процессов. Они предоставляют интерфейс для создания и управления группами процессов, а затем накладывают ограничения на ресурсы, потребляемые этими группами.

Сначала ставим необходимые пакеты, если они не стоят:

apt-get install cgroup-tools

Создаем отдельную группу asshole, в нее будем добавлять приложения, которые нужно оградить от swap:

cgcreate -g memory,cpu:/asshole

Запрещаем вытеснять процессы в swap:

echo 0 | tee /sys/fs/cgroup/asshole/memory.swap.max

Добавляем процесс в группу asshole:

cgclassify -g memory,cpu:/asshole/ $(pidof nginx)

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

Дополнительно для группы asshole отключим OOM:

echo 1 | tee /sys/fs/cgroup/asshole/memory.oom.group

Вот и всё, теперь приложение не будет уходить в swap и OOM (Linux Out-Of-Memory Killer) обломается. Ну и как вариант: всё нахуй встанет раком, продакшен издаст последний вздох и упадет в новогодние праздники. Но тут, как говорится — хозяин барин! Хотели отключить, отключили.

Все настройки производились на ubuntu 22.04, в других версиях есть различия на названия memory.swap.max, memory.oom.group и прочее.

После создания группы, зайди, посмотри что у тебя там создалось. И от туда уже пляши. У меня этот способ не сработал на виртуальных серверах в Селектеле (permissions denied), но прекрасно сработал в Digital Ocean и на локальной виртуалке.

Экспериментируйте! Кстати после перезагрузки, cgroups слетят и по возможности создавай юнит в systemd, типа такого:

/etc/systemd/system/asshole.service

[Unit]
Description=My cgroup configuration

[Service]
ExecStartPre=/bin/mkdir -p /sys/fs/cgroup/asshole
ExecStartPre=/bin/mount -t cgroup -o memory asshole /sys/fs/cgroup/asshole
ExecStart=/bin/echo 1 > /sys/fs/cgroup/asshole/memory.oom.group

[Install]
WantedBy=default.target

systemctl daemon-reload
systemctl start asshole
systemctl enable asshole

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

tags: #linux
—
💩 @bashdays

Вчера в комментариях к посту про «set -k», задали вопрос про решение задачи. Чтобы понять какие опции включены в оболочке bash через «set», достаточно выполнять команду:

echo $-

В этой команде «$-» представляет текущие опции командной строки.

На экран выведется, что типа такого:

hikmBHs

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

Ну или через скрипт, как мы любим:

if [[ $- == *k* ]]; then
  echo "Опция -k установлена."
else
  echo "Опция -k не установлена."
fi

Про «$-» мало кто знает, в книжках я про неё никогда не встречал. В оболочке zsh эта штука тоже фурычит. Такие дела.

tags: #bash
—
💩 @bashdays

Привет, всех с Новым Годом! Праздники праздниками, но пора уже входить в рабочий поток и разгрести локальный техдолг. На этот раз решаем задачку с тремя известными: Windows + WSL + VirtualBox.

Суть такая. Понадобилось мне вхреначить на локальную машину VirtualBox с убунтой, для тестирования фичи, которую писал в этом посте. Фича не хотела заводиться на виртуальных серверах Селектела, хотя и должна была. Потребовалось убедиться, что дело не в моих кривых руках. Ладно, лирика…

Короче цепануться к убунте из wsl по ssh к VirtualBox из коробки не получилось. Да и понятно, подсети разные. Пришлось временно воспользоваться powershell и через ssh проверить гипотезу с cgroup. Винда видит подсеть виртуалки и с этим проблем нет. Проверил, забыл.

Но вопрос остался открытым: как блять/дь малой кровью из WSL (с ubuntu 22.04) подключиться напрямую к виртуалке c ubuntu 22.04 по ssh? И не задрачиваться с таблицами роутинга? Рассказываю!

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

В общем, пиздуем в настройки VirtualBox: Сеть, Адаптер1. В нем по умолчанию включен NAT. Открываем пункт - Дополнительно, видим кнопку: Проброс портов. Заходим и начинаем заниматься очередной хуитой магией.

Сначала роутим на виндовую машину:

Имя: ssh_win
Протокол: tcp
Адрес хоста: 127.0.0.1
Порт хоста: 2222
Адрес гостя: пусто
Порт гостя: 22

Так, теперь в powershell я могу цепануться к виртуалке так:

ssh -p2222 user@127.0.0.1

Оно и ежу понятно, теперь усложняем задачу:

Имя: ssh_win_host
Протокол: tcp
Адрес хоста: 192.168.31.100
Порт хоста: 22
Адрес гостя: пусто
Порт гостя: 22

Этой хернёй разрешаем подключение из powershell по такому принципу:

ssh user@192.168.31.100

Ага, айпишник 192.168.31.100 это адрес, который выдал роутер моей виндовой машине. Как видим уже используется 22 порт. Посмотреть айпишник можно командой ipconfig в терминале powershell. Да простят меня адепты линукса.

Ну и теперь финальный штрих, прикручиваем WSL:

Имя: ssh_wsl
Протокол: tcp
Адрес хоста: 172.21.20.123
Порт хоста: 2222
Адрес гостя: пусто
Порт гостя: 22

Айпишник 172.21.20.123 выдан убунте в WSL, смотрим его через ifconfig. А дальше заходим в сам WSL и подключаемся к VirtualBox как к обычному серверу:

ssh user@192.168.31.100

То есть цепляемся в виндовой/хостовой машине на 22 порт, который уже проброшен. Закидываем public ключи, делаем алиасы для быстрого коннекта. Всё! Дело в шляпе! Мы подключились из WSL (ubuntu) по ssh к виртуальной машине в VirtualBox.

Есть нюанс, у меня дополнительно поднят VPN через wireguard, там еще один фактор с подсетью. Поэтому я добавил еще мусора:

Имя: ssh_vpn
Протокол: tcp
Адрес хоста: 10.66.64.55
Порт хоста: 22
Адрес гостя: пусто
Порт гостя: 22

Теперь при активации VPN, подключение к VirtualBox через WSL будет выглядеть так:

ssh user@10.66.64.55

Логично, адрес виндовой/хостовой машины меняется с 192.168.31.100 на 10.66.64.55. Но это детали. Еще есть тема, что при включении/выключении VPN вся это тягомотина с пробросом портов подхватывается не сразу. Имей это ввиду.

Я себе сделал 2 алиаса в wsl ~/.zshrc:

alias box1="ssh user@192.168.31.100"
alias box2="ssh user@10.66.64.55"

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

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

Ладно, самое время включить режим «День-Тюлень». Еще раз всех с НГ. Увидимся!

tags: #linux #wsl #windows #network
—
💩 @bashdays

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

Приходит новый девопс-инженер и начинает ныть — ой, мама, какой у вас тут ужас, предыдущий девопс явно был дурак и рукожопая бестолочь. Ну как так можно было делать? Я сейчас все переделаю правильно! Ну и делает. А через год увольняется.

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

Ну и самый сок. Беру к себе на парт-тайм девопса, чтобы мою личную инфраструктуру обслуживал. Где крутятся около сотни пет-проектов. Всё отлично, работа прет, задачи пилятся. Но в какой-то момент пытаюсь самостоятельно законектится по ssh на сервак, а оно мне — не, мы тебя не знаем дядя, давай до свидания!

Хм… задаю вопрос Василию. Василий — а чо меня это, на мой же сервак не пускает? А Василий — а не пустит, у вас там предыдущий девопс такой херни намутил, дурак какой-то, я всё под себя переделал и по уму, бест-практики!

И да! Теперь авторизация осуществляется через Teleport. Но доступ я вам не дам, так как вам там нечего делать, еще сломаете моё детище! Ну и я поднял дополнительный сервер с Teleport, там 20$ лишних в месяц теперь нужно платить…

Дела… То есть я самостоятельно настроил инфраструктуру, но она никак не вяжется с мировоззрением таких Василиев. Со старой школой намного проще работать, но тоже не всегда. Порой люди прикипают к FTP и SVN и дальше развиваться не хотят, но просят при этом 100500$ в час непонятно за что.

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

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

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

Всегда стремись — упрощать! Научись адаптироваться, держать баланс и всё у тебя будет в жизни хорошо... 😂 наверное.

PS: Кстати рекомендую попробовать Teleport, офигительная штука!

Teleport - это инструмент с открытым исходным кодом для обеспечения доступа к серверам и облачным приложениям с помощью SSH. Он позволяет отказаться от использования VPN, предоставляя единый шлюз для доступа к вычислительной инфраструктуре через SSH, кластерам Kubernetes и облачным приложениям через встроенный прокси.

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

Привет. Все таки сложно отойти от праздников и заставить себя работать. Придется подключать для разгона «Красный Халат». Погнали.

Начнем этот спринт с буферов обмена в Linux. Обычно при работе в терминале у нас с тобой есть аж три буфера.

При правильных манипуляциях, можно воспользоваться всеми тремя.

Clipboard Buffer

Копировать : CTRL+SHIFT+C
Вставить   : CTRL+SHIFT+V  
Вырезать   : CTRL+SHIFT+X  
Или контекстное меню

Primary Buffer

Копировать : Выделить, копируется само
Вставить   : Средняя клавиша мыши

Application Buffer

Вставить   : Зависит от приложения
Вырезать   : Зависит от приложения
Копировать : Зависит от приложения

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

Clipboard Buffer
Выделяешь и копируешь CTRL+SHIFT+C

Primary Buffer
Выделаешь, копируется автоматически

Application Buffer (Оболочка Bash)
Курсор в конце строки, вырезаем CTRL+W

Так, буферы заполнили. Очищаем экран: CTRL+L и начинаем вставлять:

1. CTRL+SHIFT+V
2. Средняя кнопка мыши
3. CTRL+Y

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

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

Ладно. Всем легкой недели. Увидимся!

tags: #linux #bash
—
💩 @bashdays

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

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

Вот и вчера. Ситуация: какой-то php скрипт при создании файла на диске, выставляет корявые права на этот файл. Грубо говоря, нужно поставить 777, а у файла права по факту 01411. Конечно, проблема в сервере! Пусть дядя Рома с этим разбирается. Ладно, за монету и корку хлеба можно и покопаться.

Блин, как я давно с php дел не имел. Пришлось вспоминать всю эту лапшу с ООП.

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

<?php

chmod('test.txt', '777');

?>

Для простоты восприятия, адаптировал под наши с вами реалии. Вроде всё корректно, тошноты пока нет. Чо этой собаке надо? Запускаю скрипт, хм… снова получаю вместо 777 какую-то фигню 01411.

А если уберем кавычки? Вдруг это как string воспринимается:

<?php

chmod('test.txt', 777);

?>

Метод тыка не помог, но терпим до последнего. В документацию по chmod в php не лезем. Нас же НЕ просили исправить баг, нас поставили перед фактом — проблемы на сервере. Вот мы и пытаемся доказать обратное.

Расчехляем strace

strace php app.php

В самом конце видим:

read(3, "<?php\n\nchmod('test.txt', 777);\n\n"..., 4096) = 35
chmod("test.txt", 01411) = 0

Видим знакомое 01411. Доказательства собрали. С серверами всё хорошо, на лицо баг в коде. Несем эту информацию тимлиду, пусть учит разработчика читать документацию и дает ему по шапке.

А что все-таки не так с php скриптом, почему 01411? Вообще это не наше дело. Но если коротко:

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

📌А откуда берется 01 перед 1411?? А давай ты сам подумаешь и в комментариях напишешь. А мы тебе дружно лайк поставим.

Ошибка была в том, что в php скрипте число 777 передается как строка. Неважно в скобках оно или нет.

Фикс тут простой, просто вставляем 0 перед 777:

<?php

chmod('test.txt', 0777);

?>

Ну а если хочется без ведущего нуля, то так:

<?php

chmod('test.txt', intval('777', 8));

?>

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

Пусть лучше лишние полчаса погуглит, посмотрит, зато самостоятельно заполнит свою дофаминоваю яму. И потешет ЭГО новой победой над багом.

Ладно, увидимся, давай!

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

Привет, далеко ходить не будем, сегодня более интересный кейс с отладкой php-fpm который непонятным образом, рандомно вставал раком. Да, будем использовать наш любимый strace, как ты любишь.

Проблема: На сервере крутится php-fpm, в любой момент времени процесс начинает зависать, то есть перестаёт обрабатывать любые запросы.

В какой-то момент может очухаться, а может и нет. В любом случае проблема решается перезапуском systemctl restart php-fpm. Ну и в логах ничего криминального нет, даже в дебаг режиме. По факту имеем пятьсот две плохих шлюхи (502 Bad Gateway).

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

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

Так и жили пока дядя Рома не соизволил разобраться в ситуации, ну и разобрался.

Расчехляем strace

Для начала ты должен знать, что php использует модель master/slave. Главный процесс использует воркеры (workers) для обработки входящих запросов. Запрос может выполниться на любом из воркеров, поэтому нужно сказать strace чтобы мониторил все воркеры. Для этого будем использовать связку с командой pidof ну и приправим это sed’ом.

strace -f $(pidof php-fpm | sed 's/\([0-9]*\)/\-p \1/g') -epoll

Sed обрезает лишнюю херню и оставляет только pid в голом виде, ну и затем эти пиды закидываем в strace.

А после запуска команды и зависания php, я увидел такое:

[pid 1234] poll([{fd=10 ...]) = 0 (Timeout)
[pid 1234] poll([{fd=10 ...]) = 0 (Timeout)
[pid 1234] poll([{fd=10 ...]) = 0 (Timeout)
[pid 1234] poll([{fd=10 ...]) = 0 (Timeout)

Ага, уже есть с чем работать. Какой-то таймаут. И файловый дескриптор fd=10. Хм. Теперь надо понять, что это за таймаут и дескриптор fd=10. Для этого сделаем так:

lsof -p 1234

Эта команда выдаст список всех файлов, которые открыты процессом, включая сокеты.

php 0u IPv4 13193 0t0 TCP :8000 (LISTEN)
php 1u CHR 1,4 0t0 4728 /dev/null
php 2u CHR 1,4 0t0  4728 /dev/null
php 3ur REG /tmp/.RedPem.Hte (deleted)
php 4u IPv4 TCP :8000->:5042 (ESTABLISHED)
php 5uW REG sessions/sess_tmh0dls75
php 6u 0000 0,9 0 4842 anon_inode
php 7u unix 0t0 25714 socket
php 8u unix 0t0 25714 socket
php 9u TCP l->l:11210 (ESTABLISHED)
php 10u TCP host->10.0.0.100:9200 (SYN_SENT)

Смотрим самую последнюю строку как раз с fd=10. Видим что у нас проблема с подключением к 10.0.0.100:9200. Очень интересно. Что это вообще за айпишник такой.

Не останавливаемся и копаем дальше.

В большинстве случае порт 9200 принадлежит ElasticSearch. Роем в эту сторону и обнаруживаем, что в php проекте используется библиотека ElasticSearch PHP.

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

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

Такие дела. Я прям уверен — если пройтись с помощью strace по всяким популярным php движкам, там столько дерьма вылезет. Кстати с помощью strace можно вполне удачно разгонять проекты, банально фиксишь то, что вызывает таймауты.

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

В общем изучай и бери на вооружение, опыт полезный. Увидимся!

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