Bash Days | Linux | DevOps

Кстати у нас есть внутренняя темка — написал технический авторский пост от 2500-4000 знаков, скинул Максу, получил 1000р на РФ карту. Несколько человек активно пишут. Кому все эти розыгрыши в хуй не уперлись, можете подколымить.
ㅤ
Но писать нужно из личного опыта, а не из пальца высасывать, азы баша, команды линукса и прочая хуйня — мимо. А вот какие-то личные наблюдения, замечания, разработки и т.п. прям приветствуются.

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

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

До 01.09.25 потестируюм такой формат в паблике, дальше видно будет.

Заваливать постами НЕ нужно, максимум 1-2 поста в неделю от одного человека.

🛠 #людипишут
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Короче я тут в чатике про баланс-борд от Selectel как-то заикнулся. Мне оно опасно, а тебе мож пригодится. Давай наконец-то покончим с этим.
ㅤ
🔥 🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤 🔥

Прочь тоска, под ногами доска!

Условия розыгрыша:

1. Пишешь техническую статью, тема в формате канала.
2. Никакой копипасты (проверяем), пишешь сам, вдумчиво.
3. 1 сентября подводим итоги и отправляем СДЭКом.

За второе и третье место, закинем 5000 и 3000 рублей на РФ карту.

И дополнительное призовое место от нашего коллеги DevUps, обещает задонатить кругленькую сумму за пост, который произведет впечатление на него лично.

Критерии оценки:

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

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

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

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

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

Даже если тебе кажется, что твой пост будет гавном — никого не слушай, самые очевидные и простые вещи, обычно самые стреляющие. Например, как этот в @gitgate.

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

Ну чё сисю мять, поехали!

🛠 #балансбатл #технобордач #пишунепадаю
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Забавная ситуёвина с ubuntu 24. После того, как человек поменял в файле /etc/ssh/sshd_config порт с 22 на 2222 и сделал systemctl restart ssh - ничего не произошло.

По-прежнему слушался порт 22. Хм... Хуйня какая-то.
ㅤ
Всё оказалось прозаичнее. В новых версиях дистрибутива, ssh демон стал использовать сокетовую модель для подключения клиентов. Как раз недавно мы разбирали systemd и его функционал, поищи по тегу #systemd

Ну так вот. Если подключиться к консоли дистрибутива (не по ssh), то обнаружим, что никакой ssh сервис не запущен. Однако...

Но если выполнить: ss -tln то увидим:

tcp LISTEN 0 4096 *:22 *:*

Да ёбтвою мать! Разбираемся.

Суть такая. Для ssh используется не ssh.service юнит, а ssh.socket. А как мы знаем юнит socket не держит процесс постоянно запущенным. Экономия ресурсов и т.п. А вот когда кто-то обращается к порту 22, запрос улетает на сокет systemd, который уже и запускает сервис ssh.service..

Пиздец конечно конструкция. Если посмотреть файл ssh.socket, в нём будет:

[Unit]
Description=OpenBSD Secure Shell server socket
Before=sockets.target ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Socket]
ListenStream=0.0.0.0:22
ListenStream=[::]:22
BindIPv6Only=ipv6-only
Accept=no
FreeBind=yes

[Install]
WantedBy=sockets.target
RequiredBy=ssh.service

Смотрим на ListenStream, вот тебе и 22 порт.

А чё блядь делать?

Снимать штаны и бегать. А если серьезно, то решается это просто. После правки конфига /etc/ssh/sshd_config делаем:

systemctl daemon-reload
systemctl restart ssh.socket

Перезапускаем именно юнит сокета. После этого порт изменится. А в файле ssh.socket будет такое:

[Socket]
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222

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

Делается это так:

systemctl disable --now ssh.socket
rm -f /etc/systemd/system/ssh.service.d/00-socket.conf
rm -f /etc/systemd/system/ssh.socket.d/addresses.conf
systemctl daemon-reload
systemctl enable --now ssh.service

Способ описан на официальном сайте бубунты.

Вот такие пироги.

Ну а чем отличается ssh_config от sshd_config я описывал в этом посте.

🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Ремонтировал внешний диск, в моменте отвалился от малины и я получил RAW вместо ext3. Печалька. Бекапы естественно я никакие не делал, хотя 5 лет собирался этим заняться.

Как говорится - пока гром не грянет мужик не перекрестится.

Велосипед я изобретать не стал, а так же не стал брать сразу какие-то продвинутые инструменты для восстановления. Решил воспользоваться нативным fsck, чем чёрт не шутит.
ㅤ
Пошел погуглил синтаксис, не каждый же день этой хернёй пользуешься. А там блядь:

fsck -y /dev/sdb
fsck.ext3 -y /dev/sdb

Хмм... помимо fsck.ext3 есть еще и fsck.ext4 и еще несколько штук. Ёбтвою мать. Отправляемся ресерчить, чем эта поебота отличается от обычного fsck.

TL:DR: НИЧЕМ!

Ща, расскажу. Короче в чистом виде fsck это обёртка, универсальная оболочка, которая автоматом определяет тип файловой системы и затем уже запускает условно fsck.ext3, ну или какая там у тебя на дисках.

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

Чтобы узнать, что запустит fsck делаем так:

fsck -N /dev/sda1

В результате получишь:

[/usr/sbin/fsck.ext4 (1) -- fsck.ext4 /dev/sda1

А еще у fsck нет ключа - [-E extended-options]. В нее можно передать:

-E discard - Включает TRIM (удаление неиспользуемых блоков на SSD) во время проверки. Аналог fstrim, но в процессе fsck.

-E journal_only - Проверяет только журнал ext3/ext4, не сканируя всю ФС. Быстро, но полезно только в определённых сценариях.

-E frag - Проводит анализ фрагментации. Полезно, если интересует дефрагментация ext4.

-E bmap2extent - Преобразует старые "indirect" блоки в extent-формат (для старых ext4).

-E test_fs - Включает особое поведение для тестирования (не используется в продакшене).

Пример:

fsck.ext4 -f -E discard /dev/sda1

Принудительная проверка + удаление "мусорных" блоков на SSD.

# Как fsck определяет тип файловой системы

Порядок определения:

1. Смотрит в /etc/fstab и выгребает третий столбец.
2. Если в fstab хуй, то оно запускает blkid /dev/sda1
3. Если определить не получилось, пиздует в /etc/filesystems, но в большинстве случаев такого файла в современных дистрибутивах нет. Этот файл опционален.

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

Ну и чтобы на каждую ошибку не вводить y, пропиши автофикс:

fsck -y /dev/sda1

Оно там само пошуршит, все исправит и будет тебе счастье. Изучай.

🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

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

Тренажер содержит 77 вопросов. Вполне достаточно чтобы заебаться.

Я даж успешно прошел первую задачку, правда по-олдскульному и затронул все бед-практики, которые только существуют.
ㅤ
Установка простая:

cd /tmp
python3 -m venv textual_apps
cd textual_apps
source bin/activate
pip install cliexercises
cliexercises

Здесь я использовал tmp папку и venv, чтобы систему всяким гавно не засорять, а чисто поиграться.

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

Сможешь выбить все 77 вопросов без подсказок?

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

🛠 #linux #bash
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

GIT для девопс-инженера

Многих git пугает разнообразием команд, но 99% его функционала тебе никогда не пригодится. Это как MS Word или Excel, где ты используешь ну от силы 0000.1% всего задуманного в нём.
ㅤ
Да, разработчикам посложнее, надо разруливать мердж-конфликты, делать какие-то ебаные черепики и ребейзы. Но для программистов на yml, достаточно основной базы.

Стянул-закомитил-запушил. Не пушится? Похуй — push force!

Теорию по git опустим, ты и сам знаешь для чего оно всё нужно — для удобства.

Я к примеру в гите храню базу obsidian и совсем недавно это спасло все мои заметки. Я установил плагин для синка с seafile и оно мне нахуй всё стерло. У меня сука глаз выпал, овер 3к заметок проебало за секунду.

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

К сути. Как я сказал выше, тебе достаточно базы:

git pull
git commit -m "ебал я вашу буравую, несите книжку трудовую"
git push

К этому можно еще добавить clone, checkout и init, но этим ты будешь пользоваться очень редко.

Как все работает в реальности

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

git clone git@git.bashdays.ru:shubin/obsidian.git

ВСЁ! Репа у тебя на руках.

Создаешь новую ветку от мастера:

git checkout -b 010825

И уже в нее говнокодишь. Когда говна достаточно, комитишь, делаешь пулл-реквест (мердж-реквест). После того как тимлид заапрувит твой реквест, правки вольются в мастер. А ветку 010825 можно закрывать.

Пункт с реквестами опять-же маловероятен, если компания не большая и ты там царь и бог девопса. Сразу хуяришь в мастер и никого не слушаешь. Отпадает необходимость создавать ветки и т.п. Ведь ты же всегда все делаешь идеально.

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

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

А как настроить ключи и т.п. я писал много постов, поищи по тегу #linuxfactory

А тут разбирали почему порой главная ветка называется main а не master.

🛠 #git #devops
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Вайб-кодинг

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

Программировать естественно я ничего не хотел, я уже стар для этого дерьма.

И тут я вспомнил про «Вайб-кодинг», сука! ЧатГПТ аналогично приказал долго жить (лень оплачивать), поэтому выбор пал на «дикпик».

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

Ну и через несколько минут получил готовый кусок говна. Но нет!

Пробежавшись по коду, хм, вполне вменяемо, даж базу данных прикрутил, систему банов, антифлуд и т.п. Реализовало оно мне на python + aiogram.

И это не спиздеть заняло 2-3 минуты с моими дополнительными промтами с правками.

Работает?

Охуенно работает! И даже с первого раза, «дикпик» прям удивил. Запросил у него еще Dockerfile и пайплайн для gitea, запушил, раздеплоил. Потыкал, да, всплыли некоторые баги, но они не критичные, они больше от моего кривого ТЗ. Потом пофикшу, хотя вряд ли, ебал я.

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

Быстро и бесплатно. Ни в коем образе не призываю так делать, но если пиздец лень и нужно срочно, почему бы и нет?

За такого бота с меня вчера запросили 150к и месяц на реализацию. Хуйня какая-то. Потом бы я еще месяц бегал чтобы баги поправили.

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

Подтверждаю, «Вайб-кодинг» работает и весьма неплохо, но в рамках разумного!

🛠 #develop
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Модель OSI

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

🔤🔤🔥🔤🔤🔤🔤

Модель OSI выглядит как показано на фото к посту.

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

Поговорим на самом деле о другом:

А зачем это учат если это не видно?

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

А сделано это для того чтоы четко определять стандарт работы.

То есть каждый уровень может строится на разных технологиях, НО эти уровни не должны затрагивать другие.

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

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

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

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

Первое — горит ли лампочка на сетевушке, arpping — видимость мак адресов вокруг, ping любого адреса в 127 сетке — проверка стека, просмотр таблицы маршрутизации, пинг ближайшего шлюза, трасерт нужного адреса, проверка через dig или nslookup dns и потом проверка порта на нужном сервере.

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

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

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

Именно поэтому если запретить хождение через обратную петлю на компьютере графическая система упадет.

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

То есть этим решили вопрос совместимости по драйверам и сделали возможность модульной архитектуры. Работать с разными видео-картами для отрисовки картинки.

Я сильно подозреваю что и wayland работает по тому же принципу, но, честно говоря я пока еще его не смотрел.

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

Именно поэтому надо понимать модель OSI и на каком уровне у тебя работает тот или иной протокол.

upd: велком в комменты, давайте спорить

🛠 #networks
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Я в телевизоре 👆😜

Какое будущее ждет сисадминов в эпоху AI? Спойлер: великое 🎉

Всю неделю мы готовили тематический контент для профессионального развития сисадминов. Пришло время заглянуть в будущее: что случится, если автоматизировать всю работу с помощью ИИ? Ведь он неплохо справляется с DevOps-задачами…

Роман Шубин, CTO и автор канала Bash Days, рассказал, почему без инженеров никак. Читайте его мнение в Академии и ставьте реакции, если согласны!

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

Сопроцессы. Практика. Часть Третья.

🔤🔤🔥🔤🔤🔤🔤

Это уже больше не сопроцессы, а про то, как принять почту в скрипте bash.
ㅤ
Соединение с POP3 сервером есть. Аутентификация тоже. Осталось написать что-нибудь полезное.

# возвращает число писем в ящике
function POP3_STAT(){
  declare -a AREC
  declare REC
  SEND_CMD "STAT"
  read -ert 2 -u ${POP3_CONN[0]} REC
  read -ra AREC <<<${REC//$'\r'/}
  if [[ ${AREC[0]} == "+OK" ]];then
    echo ${AREC[1]} # число сообщений
    return 0
  else
    echo 0
    return 1
  fi
}
#Помечает к удалению указанное письмо
function POP3_DELE(){
  declare -i MSG_NUM=${1:-1} # по умолчанию первое
  declare -a AREC
  declare REC
  SEND_CMD "DELE $MSG_NUM" #удаляем указанное сообщение
  read -ert 2 -u ${POP3_CONN[0]} REC
  read -ra AREC <<<${REC//$'\r'/}
  if [[ ${AREC[0]} == "+OK" ]];then
    return 0
  else
    return 1
  fi
}
# читает письмо с заголовками
function POP3_RETR(){
  declare -i MSG_NUM=${1:-1} # по умолчанию первое
  declare -a AREC
  declare  REC
  SEND_CMD "RETR $MSG_NUM" #читаем указанное сообщение
  read -ert 2 -u ${POP3_CONN[0]} REC
  read -ra AREC <<<${REC//$'\r'/}
  if [[ ${AREC[0]} == "+OK" ]];then
    while read -r -t 2 -u ${POP3_CONN[0]} REC ; do
      REC=${REC//$'\r'/}
      echo "$REC"
      if [[ "$REC" == "." ]];then
        return 0 # msg end
      fi
    done
  else
    return 1
  fi
}
# читает указанное число строк письма
function POP3_TOP(){
  declare -i MSG_NUM=${1:-1} # по умолчанию первое
  declare -i STR_NUM=${2:-1} # по умолчанию одна строка
  declare -a AREC
  declare  REC
  #читаем указанное сообщение
  SEND_CMD "TOP $MSG_NUM $STR_NUM"
  read -ert 2 -u ${POP3_CONN[0]} REC
  read -ra AREC <<<${REC//$'\r'/}
  if [[ ${AREC[0]} == "+OK" ]];then
    while read -ert 2 -u ${POP3_CONN[0]} REC ; do
      REC=${REC//$'\r'/}
      echo "$REC"
      if [[ "$REC" == "." ]];then
        return 0
      fi
    done
  else
    return 1
  fi
}

Финальный код

#!/bin/bash

SERVER="server"
PORT=995
USER="user@server"
PASS="StrongPass"

coproc POP3_CONN { openssl s_client -connect "${SERVER}:${PORT}" -quiet 2>/dev/null;}

POP3_LOGIN && echo POP3_LOGIN OK
MSG_NUM=$(POP3_STAT)
#цикл перебора сообщений
while ((MSG_NUM));do
  POP3_TOP $MSG_NUM 1 # Заголовки + 1 строку сообщения
# POP3_RETR $MSG_NUM  # сообщения целиком
# POP3_DELE $MSG_NUM  # помечаем к удалению.
  ((--MSG_NUM))
done

POP3_QUIT

help coproc
help read
man openssl

🛠 #bash #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Сопроцессы. Практика. Часть Вторая.

🔤🔤🔥🔤🔤🔤🔤

coproc хорошо подходит для общения в клиент-серверном режиме. Для примера попробуем подключиться к POP3 серверу с шифрованием ssl прямо из bash-скрипта.
ㅤ
Сам ssl несколько сложноват для bash, поэтому в качестве посредника будем использовать openssl s_client.

Протокол и команды POP3 лучше посмотреть на википедии.

1. Cоздим сопроцесс. Для этого запустим openssl в режиме s_client. При этом из дескриптора POP3_CONN[0] можно читать данные от сопроцесса.

В дескриптор POP3_CONN[1] можно писать для сопроцесса.

При записи используем перенаправление >&${POP3_CONN[1] . При чтении тоже можно использовать перенаправление, но поскольку у команды read есть ключ -u красивее воспользоваться им.

2. Аутентифицируемся

3. Закроем сессию и дескрипторы.

# Функция для отправки команд серверу
function SEND_CMD() {
  sleep 0.3
  echo "$@" >&${POP3_CONN[1]}
  sleep 0.3
}

# аутентификация. Обычный логин
function POP3_LOGIN() {
  declare REC
  declare -a AREC
  # проверка соединения
  read -ert 2 -u ${POP3_CONN[0]} REC
  read -ra AREC <<<${REC//$'\r'/}
  if [[ "${AREC[0]}" == "+OK" ]];then
    # Отправляем логин
    SEND_CMD "USER $USER"
    read -ert 2 -u ${POP3_CONN[0]} REC
    read -ra AREC <<<${REC//$'\r'/}
    if [[ "${AREC[0]}" == "+OK" ]];then
      # Отправляем пароль
      SEND_CMD "PASS $PASS"
      read -ert 2 -u "${POP3_CONN[0]}" REC
      read -ra AREC <<<${REC//$'\r'/}
      if [[ "${AREC[0]}" == "+OK" ]];then
        return 0 # аутентификация успешна
      else
        return 3 # не правильный пароль
      fi
    else
      return 2 #не правильный login
    fi
  else
    return 1 # ошибка соединения с сервером
  fi
}

#Выход и закрытие дескрипторов.
function POP3_QUIT(){
  SEND_CMD "QUIT"
  # Закрываем coproc
  exec ${POP3_CONN[0]}<&-
  exec ${POP3_CONN[1]}>&-
}

Задержки 0.3 секунды при отправке нужны для того, чтобы сервер успел сформировать ответ.

Ошибки -ERR не обрабатывал. В случае чего команда read завершится по таймауту в 2 сек. (-t 2)

${REC//$'\r'/} конструкция удаляет cr, потому что POP3 сервер отвечает c lfcr.

#!/bin/bash

SERVER="server"
PORT=995
USER="user@server"
PASS="StrongPass"

# создаем сопроцесс и соединяемся с сервером pop3
coproc POP3_CONN { openssl s_client -connect "${SERVER}:${PORT}" -quiet 2>/dev/null;}
POP3_LOGIN
POP3_QUIT

help coproc
help read
man openssl
вики POP3

🛠 #bash #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Сопроцессы. Теория. Часть первая.

🔤🔤🔥🔤🔤🔤🔤

Надеюсь все знают, что в bash можно запустить любую программу в фоновом режиме. Для этого после команды достаточно указать &. Например: sleep &
ㅤ
В этом случае программа начинает жить своей жизнью а переменная $! получает PID последнего запущенного процесса, чтобы можно было отследить завершение фонового процесса, а при крайней необходимости сказать знаменитую фразу Тараса Бульбы.

Для контроля и управления фоновыми заданиями служат команды jobs bg fg .

Если будет интересно - напишите комменты - рассмотрю их подробнее. Сейчас не об этом. В bash, начиная с четвертой версии появились сопроцессы (coproc). Иногда их называют копроцессы, но мне слово не нравится. Чем то оно попахивает.

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

Форма запуска:

coproc [NAME] command [redirections]

NAME - имя индексного массива, в котором содержатся дескрипторы command. Если NAME не задано, по-умолчанию используется COPROC .

COPROC[0] связан с stdout command , COPROC[1] - с stdin. И с помощью этих дескрипторов мы сможем взаимодействовать с command, не смотря на то, что программа работает в фоновом режиме.

Сразу хочу обратить внимание. Если задано NAME - вместо command необходимо использовать группировку, даже из одной команды:

coproc [NAME] { command [redirections];}

Иначе coproc поймет NAME - как команду, а command как ее параметры. И да, при группировке пробелы и точка с запятой очень важны. Добро пожаловать в bash. :-)

Пока все не так просто, как хочется, но практика все расставит по местам, а заодно научимся принимать почту от POP3 сервера с ssl.

🛠 #bash
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

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

♈️ Овен
ㅤ
Твой код будет работать… но только после пятого ребута. Энергия прет, как процессор без кулера. Береги нервы и жопу, не пуш в прод в эту пятницу.

♉️ Телец

Не обновляй стабильную систему — всё сломается и накроется пиздой. И в жизни, и на сервере. Упорство — твоя сила: скрипт на баше доведёт твою поделку до состояния шедевра.

♊️ Близнецы

Твоё многозадачное мышление работает как браузер с 32 вкладками. Всё открыто, но ничего не завершено. Сосредоточься на одном проекте — и багов станет меньше. Либо забей хуй, тогда багов совсем не будет.

♋️ Рак

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

♌️ Лев

Ты — Тимлид своей жизни. Код красиво не только работает, но и читается. Главное — не выгорай. Логи ошибок всё равно никому не интересны, всем похуй. Расслабься и чиль всю эту неделю. Только у тебя будет всё хорошо. Не выебут.

♍️ Дева

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

♎️ Весы

Конфликты в Git? Хуй с ними! Рузрулишь как и всегда, свалив их на коллегу. Ты — мастер мерджа без слёз. Хорошая неделя для командной работы и пулл-реквестов без ревью-драмы.

♏️ Скорпион

Секреты в .env — это про тебя. Мистика и безопасность идут рука об руку. На этой неделе можно раскрыть баг, который скрывался с 2016 года. Но в этом расследовании, ты выйдешь сам на себя. Так что подумай, баг ли это, либо всё-же фича. Не хочешь быть выебан — молчи!

♐️ Стрелец

Твоё желание уехать в Digital Nomad — стабильно. Отличная неделя для изучения нового фреймворка, но не начинай десятый пет-проект. Старый тоже хочет внимания. Посвяти эту неделю себе, побухай, поспи, подумай где же твоя жизнь пошла по пизде.
ㅤ
♑️ Козерог

План — цель — результат. Ты, как крон-задача, всё делаешь вовремя, но постоянно проёбываешься. Дай себе один выходной — даже CI/CD иногда падает и стоит на пол шестого. Выходной посреди недели маст-хев и бест-практика.

♒️ Водолей

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

♓️ Рыбы

Рыб обычно не ебут, ебут пироги. Плыви по потоку коммитов. Главное — не задуши себя и своего вялого своим перфекционизмом. Сложные абстракции — твоё всё, но не забывай о простых радостях — hello world тоже прекрасен.

🛠 #гороскопыотромана
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Сижу вчера втыкаю в домашки LF, звонок в домофон:

— Роман?
— Я не Роман, я Олег!
— Вам посылка!
— Хм… ну ок, заносите…

Вроде ничего не заказывал, думаю мож супруга покушать намутила — неа!

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

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

То блядь набор для варки шоколада пришлют, то машинку для интимной стрижки. Хуй знает чем вообще работодатели руководствуются. Всякую шляпу на ДР вечно дарят. Я ебал шоколад варить!

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

В этот раз что-то пошло не так и я распаковал «контейнер», любопытство взяло своё. А там — Селектел и что-то про балансировку.

Ну думаю — сбылась мечта идиота, теперь у меня есть Ти-Рекс в полный рост!

Сяду на него и буду балансировать. Ну либо как минимум бумажная документация по управлению облаками и провайдерами терраформа.

По факту удивили. Сначала я нихуя не понял что это, какая-то доска и бочка, в бочке явно не пиво… гуси какие-то на картинках…

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

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

Сюрприз удался! Во-первых — неожиданно, во-вторых это не набор для варки шоколада и т.п.

Это ебать — борд! Вот бы мне такой в 16 лет!

Спасибо всем причастным к этому сюрпризу, отдельное спасибо Ксении, Анне, Марии. Ну и девочкам из саппорта, которым пришлось пережить все мои безумные тикеты касаемо SelectOS.

Фотосы прикладываю, там еще приглашение на Day-Off халявный, но я увы не в Питере, но в онлайне схожу позырю, мож чё нового расскажут. Можешь тоже сгонять, фоном попырить.

Короче все запечатлел, поделился. Всем спасибо и хороших предстоящих выходных, берегите себя и своих близких!

🛠 #рабочиебудни
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Довольно частый вопрос с LF — Как жить с gitlab раннерами?

Да просто там всё. Если у тебя основная инфра в кубе, то в кубе и крутим.
ㅤ
Ну а если ламповые сервера, без всей этой кубовой хуйни, то вариантов не много.

Заводим себе отдельный сервер/сервера, чисто под раннеры. Заводим с учетом на то, что на этих серверах будут собираться докер образы. Со временем место будет забиваться.

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

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

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

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

Раннеры можно зарегать на один токен:

Сервер 1

gitlab-runner register \
  --url https://gitlab.com/ \
  --registration-token ABCDEFG123456 \
  --executor docker \
  --description "runner-1"

Сервер 2

gitlab-runner register \
  --url https://gitlab.com/ \
  --registration-token ABCDEFG123456 \
  --executor docker \
  --description "runner-2"

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

Раннер 1

--description "runner-fast"
--tag-list "docker"

Раннер 2

--description "runner-slow"
--tag-list "docker"

В .gitlab-ci.yml у нас так:

build:
  script: echo "Building"
  tags:
    - docker

Задание пойдет на тот раннер, который раньше освободится. Если оба свободны — гитлаб рандомно сделает выбор, приоритетности нет.

Если важна приоритетность, можно поиграть в юните с параметром GITLAB_RUNNER_PRIORITY.

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

А как деплоить?

Тоже всё просто, ssh/rsync в помощь, раннер подключается к нужному серверу, например по ssh и выполняет все необходимые команды. Затаскивает новый докер образ, стопорит старый, запускает новый.

Как-то так:

deploy:
  stage: deploy
  script:
    - |
      ssh $SSH_USER@$SSH_HOST << EOF
        docker pull $IMAGE_NAME
        docker stop my_app || true
        docker rm my_app || true
        docker run -d -p 5000:5000 --name my_app $IMAGE_NAME
      EOF

Подключаемся под юзером из переменной $SSH_USER к хосту из переменной $SSH_HOST. Ну и запускаем команды.

Важно!

Если у тебя 100500 раннеров — ты с ними заебешься, поэтому на моменте регистрации, сделай себе табличку, пропиши в них теги раннеров и на каких серверах они у тебя живут. Опять же это можно сделать через ансибл-роль, либо скриптом генерить. Тут уже сам наколдуешь.

Основное рассказал, если что-то еще вспомню, накидаю. Если у тебя есть мысли, пиши в комментарии, будем обсуждать.

🛠 #devops #linuxfactory #cicd
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Слыхал про with-lock-ex, flock, lckdo?

Если коротко, это штуки, которые не дают запустить второй экземпляр скрипта/программы, если первый ещё работает.
ㅤ
Всё это и многое другое входит в пакет moreutils, в убунтах из коробки я их не нашел, пришлось ставить. Но это детали. В этот пакет входит еще дюжина полезных хуёвин.

Например (нажми на спойлер):

sudo apt install moreutils

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

combine — логические операции над двумя файлами (как `sort` + `comm`, но проще).

errno — выводит описание кода ошибки (EACCES 13 Permission denied).

ifdata — dыводит информацию о сетевых интерфейсах в скриптабельном виде.

ifne — выполняет команду только если предыдущая команда что-то вывела (if-not-empty).

isutf8 — проверяет, является ли файл валидным UTF-8.

и так далее…

Вернемся к lckdo (Lock and Do). Это обёртка вокруг flock. Как и написал выше, оно не позволяет запуститься второму экземпляру программы/скрипты.

Допустим у тебя что-то запустилось по крону, не успело завершиться и через промежуток снова запускается. Наплодилось 100500 процессов, сервак встал раком, а потом и тебя поставили раком.

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

Давай на практике!

В первом терминале запускаем:

lckdo /tmp/bashdays.lock bash -c 'echo start; sleep 60; echo done'

Во втором терминале запускаем:

lckdo /tmp/bashdays.lock echo "Hello bashdays"

И получаем: lckdo: lockfile /tmp/bashdays.lock' is already locked

По умолчанию lckdo ничего не ждет, если нужно, чтобы он ждал до освобождения блокировки, добавляем -w.

lckdo -w /tmp/bashdays.lock echo "I'm free"

Теперь когда файл /tmp/bashdays.lock будет отпущен, отработает команда и выведет на экран I'm free.

Как lckdo работает с lock-файлом.

1. Файл /tmp/bashdays.lock сам по себе ничего не блокирует.

2. Блокировку держит процесс, который открыл файл и вызвал flock/lckdo на него.

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

Даже если файл /tmp/bashdays.lock остаётся на диске — он больше не заблокирован, и lckdo снова сможет его использовать.

Всё логично, вот еще одни пример с кроном:

* * * * * lckdo /tmp/bashdays.lock /usr/local/bin/bashdays.sh

Скрипт не будет запущен, если предыдущий запуск не завершился.

Такие дела. Бери на вооружение, возможно где-то в хозяйстве сгодится.

🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog