И на старуху бывает проруха...
ㅤ
🔤🔤🔥🔤🔤🔤🔤

Сегодня решил поделиться отрицательным опытом. Код, приведенный в статье лучше не использовать.

У меня возникла необходимость распарсить файл типа:

xxx yy "zz zz zz zz"

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

А на bash - вроде просто:

set -- xxx yy "zz zz zz zz"
echo $# $1 $2 $3

# 3 xxx yy zz zz zz zz

Проверил — вроде работает. Классно, пишу цикл, проверяю на файле — не работает. Упрощаю код до минимума.

REC='xxx yy "zz zz zz zz"'
set -- $REC
echo $# $1 $2 $3

# 6 xxx yy "zz

Очевидно, разбились по пробелам. Перепробовал кавычки — не выходит. Не придумал ничего лучшего, как использовать конструкцию:

REC='xxx yy "zz zz zz zz"'
eval "set -- $REC"
echo $# $1 $2 $3

# 3 xxx yy zz zz zz zz

Все работает как надо.

После этого я решил распарсить реальный лог apache.

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

Там была инъекция:

$(ping${IFS}-c${IFS}6${IFS}aa.bb.cc.dd)

Переменная IFS использовалась вместо пробела. Короче, команда выглядела так:

ping -c 6 aa.bb.cc.dd

Ничего страшного. Просто пинг 6 раз на адрес. И этот пинг ИСПОЛНЯЕТСЯ, вызывая задержку. Но команда могла быть и другой. Спасибо дядям за доброту.

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

В общем, если я раньше считал оператор eval — бесполезным, то теперь я считаю его вредным.

Вот такой опыт.

tags: #bash #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

Вот всё трём мы с тобой за бест-практики, но практически ничего не разбираем по бэд-практикам.
ㅤ
Давай это исправлять в контексте Bash скриптов.

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

Естественно будет серебряная пуля — как сделать правильно.

Ну чё, готов? Тогда поехали!

Почему при копировании файлов, необходимо использовать кавычки?

Допустим, у тебя есть переменная $file, в которой как ни странно хранится имя файла. И есть $target, в ней мы указываем путь куда скопировать файл.

Если мы пишем:

cp $file $target

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

file="You can suck my dick.avi"

Команда превращается в такое:

cp You can suck my dick.avi /tmp

И это воспримется интерпретатором как копирование нескольких файлов:

You
can
suck
my
dick.avi

Дальше. Если в имени файла ($file) будут символы *, ?, [ ], то это интерпретируется как шаблон для поиска файла.

Так называемое — Pathname Expansion.

Ага. Теперь если в имени файла содержится символ -, к примеру твой файл называется: -bashdays.txt, то команда cp расценит, что ты указал флаг и выебет тебя в глаз.

cp -bashdays.txt /tmp

cp: ну ты ебать инвалид -- 'h'
Try 'cp --help' for more information.

Как правильно?

Вот так:

cp -- "$file" "$target"

Кавычки в данном контексте предотвратят разделение на пробелы и ошибочное расширение подстановок.

Но если сделать так:

cp "-bashdays.txt" "/tmp"

cp: еще и баран -- 'h'
Try 'cp --help' for more information.

Чтобы не быть «инвалидом и бараном» нужно после cp вхерачить --.

Эти два тире напомнят cp что дальше идут только файлы, а никакие-то флаги.

Каков итог?

Думаю ты и сам выводы сделал. Всегда пиздярь кавычки вокруг переменных в Bash.

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

Например твой скрипт будет выполняться в другом окружении, где $IFS (разделитель слов) изменён или файлы содержат пробелы и спецсимволы.

В общем сразу мотай на ус эту тему, подстели соломку и пиши скрипты как профи.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Продолжаем погружаться в Бэд-Практики!
ㅤ

предыдущие посты о том, что это такое ищи по тегу #badpractices

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

Как это победить мы с тобой уже знаем, завернуть в кавычки и кинуть два дефиса:

cp -- "$file" "$target"

Что означают 2 дефиса опять же смотри предыдущие посты по тэгу #badpractices

Ок. Минус этого метода — его нужно сука запомнить и не забывать использовать каждый раз при передачах файлов. Вообще не интуитивно.

Второй способ разруливания этой ситуации — указать путь к файлу.

Смотри. Если перед именем файла добавить ./ (означает текущую папку), то даже если файл называется -bashdays.txt он будет передан в команду правильно.

for i in ./*.txt; do
    cp "$i" /tmp
done

В этом случае cp не затроит и выполнит задуманное.

Ну и еще вариант на закуску.

Можно просто ебануть ./ перед именем файла при передачах в команду:

for i in *.txt; do
    cp "./$i" /tmp
done

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

Выводы

Лучший вариант — всегда указывать путь к файлу (относительный ./ или полный /home/user/...). Это избавит тебя от большинства проблем с файлами которые начинаются с дефиса.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Привет друзья, наш товарищ Sf1nk5 подготовил внушительную статью про CrowdSec. За что ему объявлена благодарность.

CrowdSec — это система защиты от кибератак, которая использует анализ поведения и коллективную защиту. Она похожа на Fail2Ban, но более мощная и современная.

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

Так что запасаемся кофеём/пивком и камон 👇

➡️ Всё что нужно знать про CrowdSec

tags: #security
—
🔔 @bashdays➡️ @gitgate

Вчера после статьи про CrowdSec много ребят обратились с вопросом — мужик, а чё за движок такой у твоего блога?

Отвечу сразу всем. Это не движок, это статика. И сделана она при помощи фреймворка MKDocs + Material.
ㅤ
Суть там простая, верстаешь статейки в markdown, пушишь в гит репу, оно собирается в статику и автоматом выкатывается в прод.

Скорость работы по сравнению с wordpress просто ебейшая (статика хули). Сейчас занимаюсь SEO оптимизацией, роботсы, сайтмепы и т.п.

Порог вхождения прям минимальный.

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

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

Базовый файл requirements.txt выглядит так:

mkdocs
mkdocs-material
mkdocs-material-extensions

В моём случае я просто подключил нативный плагин блога в mkdocs.yml и немного его сконфигурял.

plugins:
  - search
  - tags
  - blog:
      blog_dir: .
      blog_toc: false
      archive_name: Архив
      archive_toc: false
      archive_date_format: yyyy
      archive_url_date_format: yyyy
      authors_file: "{blog}/.authors.yml"
      post_url_format: "{slug}"
      post_date_format: short
      pagination: true
      pagination_per_page: 5
      draft: true
      draft_on_serve: true
      post_readtime_words_per_minute: 300

Больше боли мне доставило написать пайплайн для gitea, но я поборол этого босса и вечерком скину наработки. Глядишь под гитхаб адаптируешь, там синтаксис почти один в один.

Gitea использую для личных проектов, без всяких наворотов, встроенного CI/CD и раннера вполне хватает.

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

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

Кстати в GitGate оно как-то от Димы уже прилетало, но там про material не упоминалось.

Ладно, не смею тебя больше отвлекать, вечерком еще увидимся.

tags: #рабочиебудни #frameworks
—
🔔 @bashdays➡️ @gitgate

Такс, как и обещал притаранил тебе рабочий пайплайн для авто деплоя mkdocs через gitea.
ㅤ
Чтобы всё это заработало, в проекте тебе нужно создать структуру:

.gitea/workflows/deploy.yml

Файл можешь обозвать как угодно.

name: Build and Deploy Bashdays Blog

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: super-runner
    container:
        image: catthehacker/ubuntu:act-22.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Install dependencies and build
        run: |
          pip install -r requirements.txt
          mkdocs build

      - name: Deploy to Server
        uses: https://gitea.com/aquelle1/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-rlgoDzvc -i --delete" 
          SOURCE: "site/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Давай пробежимся:

Триггер on: push: запускается если что-то запушено в ветку main.

Почему в main а не в master? Читай тут.

Следом запускается джоба build на раннере super-runner, не забываем зарегать себе раннер, без него нихуя не получится.

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

Дальше используем адаптированный контейнер с убунтой 22.04 специально адаптированный под тестирование GitHub Actions через act.

Почему GitHub Actions? Потому что gitea унаследовало синтаксис и пайплайны в теории могут переносится между системами.

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

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

После сборки идет секция с деплоем, я использую этот экшен. Основан он на rsync поверх ssh.

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

SSH_PRIVATE_KEY = Приватный ssh ключ с которым раннер пойдет на твой сервер и подключиться по ssh к нему. Соответственно публичная часть ключа должна быть прописана у пользователя на сервере в файле ~/.ssh/authorized_keys.

Как работать с ssh ключами, читай по тегу #linuxfactory

ARGS = Аргументы для rsync, рекурсивное копирование, сохранение прав доступа, удаление файлов которые не в локальной версии.

SOURCE = Какой каталог со статикой отправляем. В Mkdocs статика генерится по умолчанию в папку site.

REMOTE_HOST & REMOTE_USER = Айпишник или домен продакшена на который деплоим + имя пользователя под которым подключаемся к серверу.

TARGET = В какую папку на проде скинуть содержимое папки site.

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

Вот и всё. Теперь при пуше в main ветку, автоматически запустится пайплайн и на прод выкатятся изменения.

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

Короче хорошего тебе вечера, теперь уже до завтра!

tags: #devops #cicd
—
🔔 @bashdays➡️ @gitgate

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

Ну, то есть ты ОДИН фронт/бекендер/девопс/qa и т.п. Тимлида в такой ситуации обычно не бывает, максимум есть СТО (техдир) и то он родственник CEO.
ㅤ
Возникает ситуация — ты что-то закомитил, прод уебался. С кого спрос?

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

А техдир давно не советчик (не помощник), по причине — максимальная деградация и просиживание штанов на созвонах.

Всё что ты получишь:

Алёша, ты чё блядь Супер Марио? Об грибок уебался?

Что делать с упавшим продом? Естественно чинить самому!

В этой ситуации ты можешь положиться только на себя. Ты тот самый Брюс Уиллис, который полетел в космос и выебал астероид.

Тут уже никто не спрашивает — можешь ты это починить или нет. Ты обязан с этим разобраться и починить. А как? Вообще никого не ебет — предоставьте результат.

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

Ну и надеешься чтобы на ретро тебя в жопу не выебали.

Ситуация вторая

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

Что ты делаешь? Пытаешься починить, не выходит, еще раз пытаешься, гуглишь, используешь нейросети, становится только хуже…

Следующий твой шаг — делегируешь свой факап своему коллеге (коллегам, тегаешь всех @channel), у них опыта больше, наверное посоветуют, разберутся.

Это сразу провальный вариант!

➡️ Если что-то сломал — чини сам! Это аксиома!

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

Короче вывод такой — никогда ни на кого не надейся!

Сразу в башке носи мысль — ты один и разбираться с этим тебе одному.

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

Как только ты станешь самостоятельным, тебе будет похер вообще на всё и на всех, ты будешь Альфа-Ктулху, который решит любую проблему!

Такие дела, нового ничего не сказал, рабочие будни.

tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

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

[ $foo = "bar" ]

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

[ = "bar" ]

bash: [: =: unary operator expected

Логично вылезет ошибка, потому что «=» ожидает два значения. Чтобы избежать этой ситуации, на помощь приходят — кавычки.

[ "$foo" = "bar" ]

Теперь всё в поряде. Ошибки никакой нет.

Но Bash не пальцем деланный, поэтом сравнить две переменные можно иначе.

[[ $foo == bar ]]

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

Есть еще легаси способ:

[ x"$foo" = x"bar" ]

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

Если $foo пустая, то без x получится:

[ = bar ]

А с x будет:

[ x = xbar ]

В [[ ... ]] переменные не разделяются на слова, даже если содержат пробелы.

foo="hello bashdays"
[[ $foo = "hello bashdays" ]]

А если сделать так:

foo="hello bashdays"
[ $foo = "hello bashdays" ]

Получишь ошибку: bash: [: too many arguments

Все это справедливо для Bash. Если пишешь под sh, то твой путь это одинарные скобки [...].
ㅤ
А еще в двойных скобках можно использовать шаблоны:

foo="hello bashdays"
[[ $foo == h* ]]

Вернёт true, потому что foo начинается с «h».

Либо написать сложное условие:

[[ $foo = "bar" || $bar = "baz" ]]

В одинарных кавычках это выглядело бы так:

[ "$foo" = "bar" -o "$bar" = "baz" ]

Выводы:

Всё что тебе нужно знать это первые два способа:

[ "$foo" = "bar" ]
[[ $foo == bar ]]

Это трувей, бестпрактика и мастхев.

Изучай.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Представь что у тебя есть переменная:

f="My Documents/file.txt"

И в скрипте мы делаем так:

cd $(dirname "$f")

Это ошибочный вариант, бэд мать его практика.

Команда cd $(dirname "$f") должна вернуть путь к папке, где лежит файл.
ㅤ
НО! Результат этой команды разбивается на части, если в нём есть пробелы.

Например:

dirname "My Documents/file.txt"

Выдаст: My Documents

А если так:

cd My Documents

Логично, получаем ошибку:

cd: No such file or directory: My

Bash думает что это два отдельных слова, а не один путь.

➡️ Бест-практика

cd -P -- "$(dirname -- "$f")"

1. Кавычки защищают результат команды от разбиения.
2. И cd получит целый путь, даже если в нём есть пробелы.

Как работают кавычки

- Когда Bash видит $(...), он воспринимает это как отдельную область, некий «уровень».

- Кавычки внутри $(...) работают только внутри.

- Кавычки снаружи не объединяются с внутренними.

Наглядно, можно представить так:

cd "$( dirname "$f" )"

Внутренние кавычки "$f" защищают переменную f

Внешние кавычки "" защищают результат dirname "$f"

Теперь даже если переменная будет содержать пробелы команда не разобьётся на части.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Представь, что у тебя есть две коробки. На одной написано «хуи дрочёны», а на другой «пики точены».

Ты хочешь проверить:
ㅤ
— В первой коробке хуи?
— Во второй коробке пики?

Если оба условия верны, ты говоришь — заебись!.

Бэд практика:

[ "хуи" = "коробка1" -a "пики" = "коробка2" ]

Тут -a (И) считается устаревшим и в некоторых случаях это работать не будет. Так что если такое видишь или пишешь, сразу сноси, это хуйня!

Одна из проблем с [ A = B -a C = D ] (или -o) в том, что POSIX не определяет, как должна работать команда [ ... ], если у неё больше 4 аргументов.

Бест-практика:

Разделяем на две проверки:

[ "коробка1" = "хуи" ] && [ "коробка2" = "пики" ]

Сначала проверяется первое условие, затем второе.

Если оба верны — команда выполнится.

Либо делаем конкретно под Bash:

[[ "коробка1" = "хуи" && "коробка2" = "пики" ]]

Здесь можно использовать &&, всё будет работать правильно.

Выводы:

Если используешь [ ... ], то делай две отдельные проверки.

Если [[ ... ]], то можно писать всё внутри.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Если написать так [[ $foo > 7 ]], то далеко не факт что это правильно отработает.
ㅤ
Двойные скобки [[ ... ]] в Bash предназначен для проверки условий, но не для работы с числами. Для чисел лучше хуячить (( ... )).

➡️ Бест-практика

(( foo > 7 ))

А если хочется прям строго соответствовать POSIX, делай так:

[ "$foo" -gt 7 ]

Теперь давай разберемся почему с [[ $foo > 7 ]] словишь ошибку.

Символ > в [[ ... ]] сравнивает строки, а не числа. Например, "10" < "7", потому что 1 идёт раньше 7 в алфавите.

В [...] символ > вообще означает «перенаправление вывода», и создаст файл с именем 7 в текущей папке.

Еще пример:

case $foo in
    ("" | *[!0123456789]*) echo "Ошибка: foo не число!" && exit 1 ;;
    *) [ "$foo" -gt 7 ] ;;
esac

Если $foo содержит что-то вроде $(rm -rf /), то при определённых условиях это может привести к пиздецу. Поэтому перед проверкой лучше убедиться, что $foo — это число.

Код выше проверяет, является ли переменная $foo числом, и если да, сравнивает её с 7.

case $foo in — конструкция для проверки значений переменной $foo по шаблонам.

"" — пустая строка (если $foo пустое).

("" | *[!0123456789]*) — строка, содержащая хотя бы один символ, который не цифра (например, abc, 12a3).

Если условие выполняется, выводится сообщение "Ошибка: foo не число!", и скрипт завершает работу с кодом 1 (exit 1).

* — означает «всё остальное» (то есть, если $foo не попал под первый шаблон).

[ "$foo" -gt 7 ] — проверяет, больше ли $foo чем 7.

Выводы: для работы с числами используем (( ... )) или [ "$foo" -gt 7 ], а переменные перед проверкой лучше очищать от лишних символов.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Продолжаем делать правильно.
ㅤ
Этот код выглядит вполне нормально:

grep foo bar.txt | while read -r; do ((count++)); done

Он считает, сколько строк в файле bar.txt содержат слово foo.

Здесь главная проблема — переменная count не изменится вне цикла while, потому что в Bash каждая команда в пайплайне (|) запускается в отдельной оболочке (subshell). То есть count++ происходит «внутри», и снаружи этого не видно.

Если простым языком: Каждая часть, разделённая |, запускается в отдельной «коробке» (subshell). То есть while работает внутри своей коробки. B всё что там происходит, не видно снаружи.

Некоторые оболочки ksh93 или Bash с включённой настройкой shopt -s lastpipe работают по-другому — цикл выполняется в той же оболочке, и тогда count изменится.

count=0
echo -e "one\ntwo\nthree" | while read line; do ((count++)); done
echo $count

Этот код вернет 0, несмотря на count++, а вот например в zsh вернется 3.

Как быть?

Первый вариант:

shopt -s lastpipe

Эта штука говорит интерпретатору — что последний элемент конвейера будет выполнен в окружении текущей оболочки.

Второй вариант:

Вообще избавиться от while и всё сделать через grep:

count=$(grep -c foo bar)
echo $count

Можно еще наколхозить и передавать значения через временный файл, но это прям пиздец шляпа и костыль.

Выводы

Нужно просто посчитать строки:

count=$(grep -c foo bar)

Нужно обрабатывать строки:

while read line; do ...; done < bar

Хочешь использовать pipe:

shopt -s lastpipe

Вот и вся наука.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Вот те на!

if [ false ]; then echo "HELP"; fi

Большинство думает, что [ — это часть команды if как скобки в других языках программирования. Но нихуя!
ㅤ
В Bash if просто запускает команду. Команда [ ... ] — это обычный бинарник, аналогично команде test, а не специальный синтаксис.

Скобка ] нужна только для красоты и завершения команды [.

Команда выше напечатает HELP, потому что строка "false" — непустая, а значит, условие считается истинным.

Теперь о главном

Если хочешь использовать grep в if, не надо писать скобки!

Плохая практика:

if [ grep -q "foo" myfile ]; then
  echo "Найдено!"
fi

[... ] — ожидает условие, а не команду

grep — это команда, а не логическое выражение

Внутри [ запускать команды нельзя — это приведёт к ошибке

Хорошая практика:

if grep -q "foo" myfile; then
  echo "Найдено!"
fi

if просто запускает grep

Если grep нашёл совпадение, он вернёт 0 (успех), и выполнится then

И Всё работает как надо, без лишних скобок!

[ — это как калькулятор, а grep — это поиск. В калькуляторе искать бесполезно!

Выводы

Никогда не пиши if [ grep ... ] — это ошибка!

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

if работает с командами. [ — это тоже команда, но не синтаксис.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

С пятницей ребят. Бест-практики по башу уже знатно подзаебали, держись осталось немного, там за дебаг затрем, подкопилось у меня знатной дичи.
ㅤ
Сегодня поделюсь с тобой почему я стал использовать блокировку экрана перед тем как отойти от экрана.

Нет, не от злых черно-шляпных, смысла в этом мало, блокировка тут не решает. Собаку съели.

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

Кота тревожить не стал, уважительная причина не ходить на работу. Взял ноут и получил в аську 100500 алертов в nagios.

Да, в те времена в тренде были nagios и заббиск. Но заббикс всем казался пиздец сложным, поэтому халявили и втыкали нагиос.

Ну дак вот. Суть.

Когда кот устраивался, он первой лапой нажал на стрелочку вверх, потом еще раз нажал пузаном и на фаталити ёбнул яйцами по Enter.

Ему то чё, он хуй за мясо не считает.

А в хистори с профилактических выходных оставалась команда shutdown -h now, до которой добрался кот и успешно её исполнил.

В те времена мелкий бизнес особо за аптайм не переживал и ретроспективы только зарождались, в жопы не ебали.

Но опыт был получен.

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

Вот после этого, я всегда жму WIN + L или CMD + Q.

Даже если кот и сын спят, все равно прожимаю эту комбинацию.

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

Видимо детская травма.

А ты прожимаешь WIN + L / CMD + Q если отходишь от своей рабочей лошадки?

Камон в комменты делиться своими факапами.

tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

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

TENV Ёпта!

Если кратко, TENV это консольный менеджер для управления версиями Terraform, Terragrunt, OpenTofu, Atmos.
ㅤ
TENV написан на гошке, не требует дополнительных зависимостей и может быть запущен под любой операционкой. Удобно чё.

Ты скажешь — блядь, да есть же например tfenv и asdf, зачем очередной велосипед?

Во-первых, автора TENV зовут Александр, а не «Аннадурай Сатьямурти Чидамбарампиллаи». А это уже о чем-то говорит!

Ну и, во-вторых, все эти утилиты не поддерживают OpenTofu, Terragrunt и т.п. К тому же, требуют много консольных костылей/зависимостей и хуёва работают НЕ на Linux.

asdf не поддерживает автоматическое переключение версий на базе спецификации версии Terraform / OpenTofu внутри проекта с помощью HCL файлов. В целом, asdf скорее переключалка по запросу, а tenv более заточен под OpenTofu/Terraform проекты.

Установка:

LATEST_VERSION=$(curl --silent https://api.github.com/repos/tofuutils/tenv/releases/latest | jq -r .tag_name)
curl -O -L "https://github.com/tofuutils/tenv/releases/latest/download/tenv_${LATEST_VERSION}_amd64.deb"
sudo dpkg -i "tenv_${LATEST_VERSION}_amd64.deb"

Сейчас лично потыкал, всё работает как часики. После установки запускаем tenv, выбираем из списка (стрелочками и на пробел) что установить и жмем ENTER.

НО, так как хашикорпы — письки (This content is not currently available in your region), в РФ надо трафик прогнать через одно место, чтобы вытащить бинари терраформа.

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

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

В общем рекомендую потыкать и поддержать проект звездами. Годнота!

➡️ Страница проекта и документация

tags: #utilites #devops
—
🔔 @bashdays➡️ @gitgate

Позволил себе пару дней ничего не делать, кроме конечно проверки LF домашек. Лежал, исследовал дырки в axiom verge, гулял. Мне понравилось!
ㅤ
Буду почаще практиковать. Но есть и жирный минус, сегодня пришлось себя прям заставлять что-то сделать по работе. К хорошему привыкаешь быстро.

Ладно, лирика. Давай дальше бест-практики тыкать.

Команда if [ bar = "$foo" ]; проверяет, равны ли два значения.

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

Неправильно:

[bar="$foo"] 
[ bar="$foo" ]
[[bar="$foo"]]

1. Нельзя слеплять всё вместе. Это хуёва даже в плане кодстайла.
2. Нет пробела вокруг знака «=».
3. Аналогично, всё слеплено.

Правильный синтаксис:

if [ bar = "$foo" ]; then

или

if [[ bar = "$foo" ]]; then

Почему?

Потому что [, =, ] это отдельные символы, первая скобка вообще команда test. А если ты все слепляешь, Bash посчитает тебя долбаёбом и отправит в пешее эротическое.

Главное правило — всегда ставь пробелы между каждым элементом в условии.

tags: #bash #badpractices #bestpractices
—
🔔 @bashdays➡️ @gitgate

Кругом грабли!
ㅤ
Потребовалось мне сегодня поднять один серверный линукс дистрибутив на базе debian (чуть позже расскажу какой). Задача не тривиальная. Но по итогу как обычно подкинули граблей.

Раньше всегда был уверен, что если сделать машину с параметрами 1 CPU, 512МБ RAM, 5ГБ диск. То debian залетит только в путь.

До сегодняшнего момента. Грузимся с исошника, нажимаем Install и получаем черный экран с мигающим курсором. Ни ошибок, нихуя!

Попробовал и так и сяк, на виртуалку, на proxmox, в облаке. Взял чистый debian, такая же история. Чёрный экран и курсор.

ХМ!!! И тут я вспомнил, что полгода назад ставил ubuntu и она просто висла на выборе часового пояса.

А решил я эту проблему увеличением памяти до 1024 МБ. Причем методом тыка это натыкал, без дебага.

Попробовал с debian иии… это помогло. То есть в какой-то момент всё пошло по пизде и 512 МБ нам теперь мало.

Пошел, почитал требования к debian bookworm и действительно, требуется 1024 МБ. Ну ёб вашу мать!

Ок, будем знать и брать с запасом. На ровном месте какая-то хуйня вечно лезет. Писало быть хоть — долбаёб, у тебя памяти не хватает!

tags: #рабочиебудни
—
🔔 @bashdays➡️ @gitgate

И снова здравствуйте!
ㅤ
Давно хотел реализовать функцию на Bash, чтобы красиво выводить какие-то значимые уведомления в терминал по типу как это сделано в npm.

Обычное echo уже не возбуждает, ничего не поделаешь. Да и всякие Gum тоже ставить не хочется.

Хуяк-хуяк и получился очередной ебальник-убивальник.

#!/bin/bash

bashdays_box() {
    local headertext="$1"
    local message="$2"

    local white=$'\e[38;5;007m'
    local reset=$'\e[0m'
    local color

    case "$headertext" in
        INFO)  color=$'\e[38;5;39m' ;;
        OK)    color=$'\e[38;5;34m' ;;
        DONE)  color=$'\e[38;5;34m' ;;
        WARN)  color=$'\e[38;5;214m' ;;
        ERROR) color=$'\e[38;5;196m' ;;
        DEBUG) color=$'\e[38;5;244m' ;;
        TASK)  color=$'\e[38;5;141m' ;;
        NOTE)  color=$'\e[38;5;45m' ;;
        *)     color=$'\e[38;5;244m' ;;
    esac

    local headerpadding=$(( ${#message} - ${#headertext} ))
    local header=${message:0:headerpadding}

    echo -e "\n${color}╭ ${headertext} ${header//?/─}────╮" \
        "\n│   ${message//?/ }   │" \
        "\n│   ${white}${message}${color}   │" \
        "\n│   ${message//?/ }   │" \
        "\n╰──${message//?/─}────╯${reset}"
}

bashdays_box "INFO" "Hello from https://xn--r1a.website/bashdays"
bashdays_box "ERROR" "Swap is enabled — this may affect performance"
bashdays_box "WARN" "Certificate expires in 5 days"
bashdays_box "DEBUG" "Using config file: /etc/myapp/config.yml"
bashdays_box "DONE" "All services started"

Всё просто! Передаем тип алерта и сообщение которое нужно выводить в рамке.

А чё, красиво получилось! Забирай себе, глядишь когда-нибудь пригодится.

➡️ Box-drawing characters

tags: #bash
—
🔔 @bashdays➡️ @gitgate