Про шлюх и CodeFest

Привет, хотел про рабочие будни, падших женщин и CodeFest рассказать, но это скучно. Как-нибудь в другой раз.

А сегодня рассмотрим интересную команду — compgen.

С помощью compgen можно вывести список всех консольных команд, которые вообще доступны в твоём Linux дистрибутиве.

✔️ Запускаем:

compgen -c

И наблюдаем. Да, это полный список команд, мне выплюнуло аж 3490. Поверь там ОЧЕНЬ много интересного.

✔️ Секрет успеха

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

А через месяц ты настолько преисполнишься в своем сознании, что аж пиздец. Я на полном серьезе!

Кстати по аналогии, я каждый день читаю по 10-20 слов из словаря Ожегова. Отлично расширяет словарный запас. Рекомендую.

У compgen есть еще масса ключей, некоторые из них:

-a = выведет список алиасов
-b = список всех bash модулей
-k = вывод ключевых слов
-A function = вывод всех функций

Ладно, что еще можно с compgen сделать:

✔️ Генерация списков

files=( $(compgen -f) )
echo "${files[@]}"

На экран выведется список файлов в текущем каталоге.

✔️ Анализ окружения

variables=( $(compgen -v) )
echo "${variables[@]}"

Выведется весь список переменных окружения.

✔️ Генерация динамических списков

users=( $(compgen -u) )
echo "${users[@]}"

Скрипт динамически создаст список всех пользователей в Linux.

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

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

Ну и вот. Пойду дальше диван давить, изучай. Увидимся!

tags: #bash #linux

@BАSHDАYS | BАSHDАYS.CОM

Если пишешь говнокод, неважно куда он попадет, в GIT репозиторий или унитаз. Суть одна.

Привет отдыхающим. Нашел на github неплохую пепяку «config-file-validator», которая из консольки валидирует файлы в форматах:

Apple PList XML, CSV, ENV, HCL, HOCON, INI, JSON, Properties, TOML, XML, YAML

Работает на всём, линуксы, винда, макоська, малина. Надо только установить. В репах увы её нет. Написано на golang.

✔️ Репа с рейтингом, люди пользуются, форкают.

Я качнул с репозитория zip’ник и закинул в /usr/local/sbin

cd /tmp
wget https://github.com/Boeing/config-file-validator/releases/download/v1.6.0/validator-v1.6.0-linux-amd64.tar.gz
tar -xf validator-v1.6.0-linux-amd64.tar.gz
mv validator /usr/local/sbin

А если любишь docker, то можно прям контейнер подтянуть с этим валидатором.

Теперь в каталоге с файлами запускаем: validator и смотрим:

root@dev:# validator
    × bashdays.json
        error: Error at line 3 column 2: invalid character '"' after object key:value pair
    ✓ bashdays.yml
Summary: 1 succeeded, 1 failed

Отличное решение, когда лень или нет возможности запускать IDE. Быстро, просто, бесплатно.

Люблю такие тулзы, вроде нихера не делают, но пользу приносят. Взял к себе на вооружение. Рекомендую.

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

tags: #utils

@BАSHDАYS | BАSHDАYS.CОM

А у тебя спина белая!

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

Самый лучший тренажер это конечно же VIM. Это аксиома.

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

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

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

✔️ Оригинальная версия
✔️ С поддержкой RU языка

tags: #games

@BАSHDАYS | BАSHDАYS.CОM

Мишки на сервере

Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.

Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!

А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.

Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇

✔️ https://t.iss.one/bashday

Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.

У кого писька длиннее

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

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

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

А дальше… а дальше цирк с конями. Я сделал второй мини продакшен из 5ти серверов (балансировщик, вебноды, базы, админки, демоны), подключил его к мониторингу, прикрутил домен. И позиционировал этот продакшен как основной.

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

А теперь разъебон!

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

✔️Самое главное повышать градус и писать в слак — ааа, все сломалось, когда почините? какие прогнозы?

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

Скажу так, тест дай бог проходят 2-3 из 10 человек. Последние 2 кандидата спустя 4 часа дебага, сказали — мы не можем это починить, мы не знаем что это такое. А вот если бы мы знали, что это такое, мы бы починили. Умываем руки, чините сами.

Ну и нахуй такие сеньоры нужны? Вот упадет основной прод и чо? Мне самому его чинить чтоли? За что я плачу 500к?

Причем есть и документация к проектам и карта инфры + лог сервер + все что нужно, вникни и реши вопрос. Хули ты целый месяц делал?

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

По итогу все эти специалисты уходят по-собственному, так как не согласны жить в таком стрессе. Ну а как?

Айти это как бы про работу, а большие деньги это результат этой работы.

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

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

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

А потом иду и все поднимаю за пару минут. Главное всё делать с холодной головой. Чем больше суеты, тем больше потратишь времени на восстановление.

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

Букв много получилось, но всё по делу. Давай, увидимся завтра.

tags: #рабочиебудни

@BАSHDАYS | BАSHDАYS.CОM

Сбилдил дед репку

С утра рефакторил свой говно-скрипт, который ждал создания определенного файла + проверял, что файл не пустой. И затем выполнял нужные действия. Обычно для такого херачат циклы через for и while, справедливо.

Но всегда хочется большего и правильного. А в bash как раз есть третий способ реализовать подобный цикл. Называется Until.

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

#!/bin/bash

file=/tmp/bashdays

until [ -s "$file" ]
do
    sleep 1
done

echo "вот и всё"

Ключ -s как раз проверяет, существует ли файл и не пустой ли он.

У metallica есть такая песенка «until it sleeps»

А чтобы скрипт крутился НЕ бесконечно, а с определенным таймаутом, делаем так:

#!/bin/bash

file=/tmp/bashdays
timeout=10
SECONDS=0

until [ -s "$file" ] || (( SECONDS >= timeout ))
do
    SECONDS=$((SECONDS+1))
    sleep 1
done

[ -s "$file" ] || exit 1 

echo "вот и всё"

Спустя 10 секунд скрипт завершит свою работу даже если файл /tmp/bashdays отcутствует либо пустой. Ну а если все ок, то выполнится полезная нагрузка «вот и всё».

✔️ Таймауты полезны, если запускаешь скрипт по крону. Чтобы форки не плодились.

timeout=10 - задаем таймаут в секундах
SECONDS=0 - инициализируем встроенный счетчик

Встроенная переменная SECONDS в Bash является специальной переменной, которая автоматически инкрементируется на количество секунд, прошедших с начала выполнения текущего скрипта или текущей подобной конструкции. Как только скрипт начинает выполнение, `SECONDS` начинает отсчитывать время с 0 и увеличивается на 1 каждую секунду. Это позволяет удобно отслеживать время выполнения скрипта или определенной части кода.

Минусы конечно же есть, например время таймаута 10 секунд, файл был создан через 3 секунды, НО записывается 60 секунд. В этом случае скрипт выполнится все равно успешно. Этот момент стоит сразу учитывать и закладывать изначально адекватные значения.

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

Конец!

tags: #bash #linux

@BАSHDАYS | BАSHDАYS.CОM

У самурая нет тестов, только прод

Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.

if [ -f /.dockerenv ]; then
    echo "I'm inside docker";
else
    echo "I'm living in real world!";
fi

Банально проверяем наличие файла .dockerenv и всё! Да, так просто. Способ самый универсальный и используется разработчиками в 99% случаев.

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

А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:

if [ -n "$(grep 'kthreadd' /proc/2/status 2>/dev/null)" ]; then
    echo "I'm living in real world!"
else
    echo "I'm inside container";
fi

Тут суть такая, во всех хост-системах PID(2) == kthreadd.

Запускаем на хостовой машине:

ps -p 2

PID TTY TIME CMD
2 ? 00:00:00 kthreadd

Запускаем в контейнере:

ps -p 2
PID TTY TIME CMD
хуй с маслом

✔️ Может зафакапить, так как не установлен пакет procps.

Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:

docker commit <ID> <name>

<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый

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

Ладно, погнали дальше спасать этот прекрасный мир.

tags: #linux #bash

@BАSHDАYS | BАSHDАYS.CОM

Без скрипта не выловишь и рыбку из пруда

你好! Познакомился вчера на созвоне с китайцем, зовут его что-то вроде АнХуй. Смешной персонаж. Что-то мне 40 минут втирал на сломанном английском. Я ни слова не понял, но уверено махал головой как обезьяна на бананы. 🅰️

По итогу встречи я выучил слова «Нихао» и «Херанука», а он всяко выучил — «ты, заебал» и «пиздец». Вот так и работаем. Айти объединяет.

Ну чо, поехали двигать пингвинов

Сегодня изучаем — setsid

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

Это гарантирует, что если родительский процесс получит сигнал SIGHUP, то запущенный скрипт через setsid продолжит работу. Nohup? Почти.. Поехали в практику.

Пишем башник bashdays.sh

#!/bin/bash

echo "Starting..."
sleep 200
echo "Finished..."

✔️ Скрипт будет нихуя не делать 200 секунд.

Запускаем:

setsid ./bashdays.sh

Сразу видим, что оболочка продолжила работать в интерактивном режиме. Можно вводить команды и продолжать работу. А что со скриптом bashdays.sh? Давай запустим pstree и визуально глянем.

Это скрипт запущен через setsid

 ├─sshd─bash
        ├─sshd─bash─pstree
        └─sshd─sshd
 ├─bashdays.sh─sleep

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

А это скрипт bashdays.sh запущен напрямую, без setsid

├─sshd─bash
      ├─sshd─bash─bashdays.sh─sleep

Видим цепочку, скрипт работает в текущей оболочке bash. Если закрыть оболочку, то и скрипт прекратит свою работу.

Давай сравним setsid и nohup

Если запустить так:

nohup ./bashdays.sh &

Наблюдаем такую картину:

├─sshd─┬─sshd─bash─pstree
       ├─sshd─bash─bashdays.sh─sleep

Пишем exit и видим уже такое:

├─sshd─sshd─bash─pstree
├─bashdays.sh─sleep

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

Теперь запускаем setsid ./bashdays.sh

├─sshd─┬─sshd───bash───pstree
       └─sshd───bash
├─bashdays.sh─sleep

А тут сразу процесс отделился от оболочки и стал корневым. Даже если написать exit и закрыть терминал, sleep продолжит работу.

Хм. Не велика разница. Но она все же есть. Команда setsid более прямой способ создания нового сеанса, тогда как nohup просто игнорирует сигнал SIGHUP.

Изучай.

tags: #bash #linux

@BАSHDАYS | BАSHDАYS.CОM

Как величать сервера

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

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

Помню когда начинал играть на гитаре, не знал что аккорды имеют название. Поэтому сам придумывал эти названия (mt-1/sl-4/sep-7). Производные от Metallica, Slayer, Sepultura и т.п.

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

Короче все зависит от твоего облачного провайдера, твоей инфры и вообще всё индивидуально. У меня инфра в основном вся в Selectel. Там есть разграничение по проектам. В каждом проекте можешь заводить любое количество инстансов. Ну я думаю везде что-то похожее, в яндексе по крайней мере также. В aws уже не помню, в DO тоже есть.

✔️ Моя схема как давать погоняла железякам.

База данных = db1
Редиска = rd1
Вебнода (nginx + php) = w1
Админки (nginx + php) = a1
Реплика БД = r1
Микросервисы = d1 (daemons)
Стораджи = st1
Балансировщик = b1

По итогу имею примерно такое:

bashdays-b1 (балансировщик)
bashdays-w1 (вебнода 1)
bashdays-w2 (вебнода 2)
bashdays-w3 (вебнода 3)
bashdays-a1 (админки 1)
bashdays-r1 (реплика БД)
bashdays-st1 (могильник файлов)
bashdays-st2 (реплика могильника)
bashdays-db1 (база данных)
bashdays-r1 (редиска)
bashdays-d1 (микросервисы, демоны)

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

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

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

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

Хоть «ебанутый-носорог-1» назови, главное чтобы тебе комфортно было.

Знаешь же поговорку — Никого не слушай, НО прислушивайся! Хороших выходных тебе, увидимся.

Кстати расскажи в комментах как ты называешь свои сервера, очень интересно послушать. Всё, теперь точно до завтра!

tags: #bash #linux

@ВАSНDАYS | BАSHDАYS.CОM

🙂 Мухаха, наебнёмка SSH

Вводные: У клиента есть сервак с авторизацией по ssh ключам. С виду все настроено верно. Катают ансиблом.

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

Проблема на самом деле распространенная. Для отладки открываем логи авторизаций и смотрим что происходит. И да, никто блядь не читает логи, а сразу начинают искать суслика, которого нет. ЧИТАЙ ЛОГИ!

Понятно дело, в логах видим ошибку:

message repeated 4 times: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys

С этой ошибкой ты всяко бодался. Смотрим права. И действительно, на файле authorized_keys стоят 3 топора (777). А должно быть 600. Как фиксить, ежу понятно.

✔️ \033[1m Но сейчас про другое \033[0m

Как сказать пингвину, чтобы он забил хуй на проверку прав для этих ключей?

А вот так, добавляем в /etc/ssh/sshd_config строчку:

StrictModes no

Ну и рестартим демона systemctl restart sshd

Всё. Теперь можешь играться с правами ключей. Хоть 000 выстави. Права проверяться не будут и тебя успешно пропустят без пароля.

Когда StrictModes установлено в no, SSH сервер не будет так строго проверять права доступа к этим файлам и каталогам. Это означает, что, например, если домашний каталог пользователя имеет права доступа, которые обычно не допускаются (например, другие пользователи могут читать каталог), SSH сервер все равно будет работать.

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

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

Финк диферент!

tags: #linux #debug

@ВАSНDАYS | BАSHDАYS.CОM

Event loop из семи залуп.

✔️ Сегодня запускаем bash скрипт из nginx по локейшену.

Идея такая, при открытии урла в браузере https://bashdays.com/bashdays.sh запускается bash скрипт, который лежит на сервере в папке /tmp/bashdays.sh.

А зачем это нужно? Элементарно — чтобы запустить Bash скрипт!

Но никогда так не делай.

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

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

Ставим врапер:

apt install fcgiwrap

Закидываем скрипт в /tmp/bashdays.sh

#!/bin/bash

echo "Content-type: text/html"
echo ""
echo "<h1>Hello Bashdays</h1>"
echo "<p>This is a test bash script.</p>"

echo "hello bashdays" > file.txt

В конфиге nginx городим локейшен:

location /bashdays.sh {
    fastcgi_pass  unix:/var/run/fcgiwrap.socket;
    fastcgi_param  SCRIPT_FILENAME /tmp/bashdays.sh;
    include fastcgi_params;
}

Заранее убедись что сокет fcgiwrap создался и лежит в нужном месте. На этом собственно всё. Да, надо сделать еще nginx reload.

Открываем https://bashdays.com/bashdays.sh и лицезрим «Hello Bashdays This is a test bash script.».

Но это еще не все. В папке /tmp появился файл file.txt. Как видишь все получилось. Дальше включай фантазию и твори.

Для lua это будет выглядеть как-то так:

location /bashdays.sh {
    content_by_lua_block {
    os.execute("/tmp/bashdays.sh")
  }
}

Я этот код не проверял, он всяко не работает, на коленке накидал, но думаю главное тут суть.

Кстати через php наверное тоже можно башник дернуть, там сокет так же подкинуть и через «хуй-пизда-лопата» запустить скрипт.

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

tags: #linux #nginx #bash

@ВАSНDАYS | BАSHDАYS.CОM

✔️ Сделаем за час в течение недели

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

Тестирование проводилось на кандидатах, которые претендовали на роль бэкенд разработчика. Ща будет жара!

Короче всем кандидатам назначалось одно время для собеса. Собиралось 5-10 человек. Всем вручали кубик-рубика. Включали таймер на 15 минут и понеслась пизда по кочкам.

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

А дальше была битва на ножах? Неа! Брали на испытательный сразу двух человек и выживал только один (как в фильме Горец), самый скилловый, который за 3 месяца меньше всего нафакапил и принес больше денег фирме.

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

Я проработал там 5 лет и ни разу у меня не было root доступа. Как я работал без рута? Шеф вводил пароль и сидел рядом пока я пилил таски. Пиздец…

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

Есть тут доля правды, ради интереса поспрашивал своих бэкендеров, сука, все как один сказали — да, мы можем собрать кубик, похуй хоть 3x3 хоть 13x13. Демоны какие-то )))

Задал этот же вопрос фронтэндерам, в ответ получил — Рома, ты ёбнутый, мы кнопочки двигаем, а не в кубики играем.

Вот и выводы. Если ты не умеешь собирать кубик-рубика, то ты не можешь быть бэкендером. Можешь конечно, но недостаточно хорошим.

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

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

tags: #рабочиебудни

@ВАSНDАYS | BАSHDАYS.CОM

Трудно быть багом

Тыдыжь! Может, башнем? Обязательно башнем. И не раз. Весь прод в труху.

✔️ Сегодня трём за экспорты.

Имеется задача: нужно создать переменную в bash и затем отменить её экспорт. НО чтобы переменная не сбросилась. Она должна быть доступна в текущей оболочке, но не подпроцессам.

Вроде все очевидно, а нихуя! Погнали в лабораторию.

1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. _BASHDAYS=$BASHDAYS
4. unset BASHDAYS
5. BASHDAYS=$_BASHDAYS

Пример выше, демонстрирует как это делают ВСЕ! Ну хуита прям полная. Никогда не делай такую блевотню.

Чо происходит:

1. Задали переменную (не доступна в подпроцессах)
2. Экспортировали (доступна в подпроцессах)
3. Скопировали переменную в другую (не доступна в подпроцессах)
4. Ансетнули первую переменную (не доступна нигде)
5. Задаем переменную (не доступна в подпроцессах)

А можно красивее? Конечно, для этого существует typeset.

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

Давай перепишем код:

1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. typeset +x BASHDAYS

1. Задаем переменную (не доступна в подпроцессах)
2. Экспортировали (доступна в подпроцессах)
3. Удаляем атрибут экспорта (не доступна в подпроцессах)

Красиво? Да охуенно! Избавились от говнища и добились желаемого.

Что значит доступна в подпроцессах?

1. BASHDAYS="hello bashdays"
2. export BASHDAYS
3. bash
4. echo $BASHDAYS
5. hello bashdays
6. exit
7. typeset +x BASHDAYS
8. bash
9. echo $BASHDAYS
10. хуй с маслом

В пятой строчке вывелось значение переменной, после запускаем bash внутри bash (подпроцесс), выводим переменную, а она пустая. Хотя если сделать exit, то переменная выводится.

Если совсем грубо — родительский процесс выводит переменную, дочерний нет. То есть export на глобальном уровне задает переменную, которая доступна в любых подпроцессах (дочерних).

Всё это справедливо для оболочки Bash, во всяких zsh и т.п. поведение может быть другое.

Есть альтернативы typeset

declare +x BASHDAYS

export -n BASHDAYS

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

Typeset это альтернативный синтаксис для declare предоставленный для совместимости с другими оболочками. Я предпочитаю использовать именно typeset, привычка наверное.

Давай краба, изучай!

tags: #linux #bash

@ВАSНDАYS | BАSHDАYS.CОM

Открытие костыльного цеха

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

Но моя ебанца покоя не даёт, вот и в этот раз сижу, думаю — а хули так долго все сжимается, у меня 32 ядра на сервере с репликой, диск не самый плохой. А оно еле ворочается.

Пошел ковырять кишочки, оказывается у меня gzip хуярит на одном ядре. Не понял. Так и есть. Говорят что с версии 1.7 все изменилось и оно само подстраивается под железо. НИХУЯ, у меня 1.10. Из коробки работает одно ядро.

Хм, может для gzip есть какой-то ключ? Бегло пробежался, в хелпах про threads ничего нет.

Ну раз так. Расчехляем свиней. PIGZ!

PIGZ (Parallel Implementation of GZIP) - это утилита для сжатия файлов, которая использует параллельные вычисления для ускорения процесса сжатия данных.

Ставится из репы: apt install pigz, а где-то уже сразу установлен.

Давай затестим. Создаем 10ти гигабайтный файл.

truncate -s 10G bashdays

Запускаем тесты:

time gzip -k -c bashdays > /dev/null

real 0m46.590s

time pigz -k -c bashdays > /dev/null

real 0m8.535s

Хуясе да! PIGZ сжал 10гигабайт за 8 секунд. А gzip понадобилось аж 46 секунд. Разница ОЩУТИМА! Понятно тесты синтетические, но мне их достаточно.

Ради интереса открыл htop, всё верно. Gzip усирается на одном ядрышке. А «свиньи» сразу жрут всё с костями. Прекрасно!

✔️ Теперь pigz нужно подружить с tar

С этим все просто, через пайп:

tar cf - bashdays | pigz -k -c > bashdays.tar.gz

Либо как вариант через ключ --use-compress-program

tar --use-compress-program="pigz --best --recursive" -cf bashdays.tar.gz bashdays

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

tar cf - bashdays | pigz -k -c | pv > bashdays.tar.gz

Тут используется утилита pv, про нее писал в этом посте.

Короче pigz прям тема и гибко конфигуряется. Я в восторге. Например, можешь сказать ей чтобы использовала только 2 ядра и 2 потока. Почитай хелпину если интересно. Основное я тебе рассказал. Изучай.

Увидимся! Пойду адаптировать под свои бэкапы.

tags: #linux #utils

@ВАSНDАYS | BАSHDАYS.CОM

Лишаем Linux девственности

Доброе утро друзья. Сейчас покажу как попасть в секретный каталог в Linux. И в 99%, ты никогда раньше в нём не был.

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

Запускам Bash и вводим:

cd //

Опа-опа, нихуя!

user@server:/$ cd //
user@server://$

Видишь два слеша в промте? Поздравляю, дефлорация прошла успешно. Даже не нужно было вводить IDDQD, чтобы активировать «годмод».

И где это мы? В пизде! Ну а чо гадать, давай посмотрим:

user@server:/$ cd //
user@server://$
user@server:/$ pwd
//

Хм, понятнее не стало… Давай посмотрим что находится у нас в этом каталоге, делаем ls -la.

И что же мы видим? А видим мы содержимое корневой директории. Для чистоты эксперимента можешь запустить так ls -la /////// и получишь такой же результат.

Получается никакого секретного каталога нет? Получается так. Нас наебали? Расходимся. Не совсем.

✔️ Почему так? Откуда берется второй слэш?

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

Что такое POSIX, писал в этом посте.

И сделано это для исторической совместимости. Некоторые версии Unix во времена динозавров использовали пути вида: //hostname/path для доступа к path на сервере //hostname.

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

Пример: если в Cygwin выполнить cd // а затем ls, получишь ошибку:

ls: reading directory '.': Permission denied

Потому что Cygwin использует корень из // для определения //имени хоста/пути. А убунта с этим нормально уживается и выводит содержимое корневой директории.

А все что более 2х слешей, должно рерайтиться на один слеш. Такие дела!

Всех с пятницей и хороших выходных! Да и на выходные будут посты. На связи!

tags: #linux #utils

@ВАSНDАYS | BАSHDАYS.CОM