Всем привет. Опять решил поделиться опытом своих провалов.

🔤🔤🔥🔤🔤🔤🔤

Вобщем, как-то раз я решил написать самоучитель по bash.

По традиции все учебники либо в html, либо в pdf. Я решил остановиться на pdf. Я начал писать в libreoffice, там есть экспорт в pdf. Пока писал - познакомился с markdown. И вдруг подумалось, markdown - такой классный, напрямик можно в гитхаб запихнуть. И в pdf конвертнуть с помощью pandoc можно. Вобщем, решил верстать в markdown.
ㅤ
Для начала познакомился с редакторами, которые умеют подсвечивать markdown (pluma, mousepad, geany) Вобщем, жить можно, но подсвечивается не всё.

После этого попробовал Apostrophe. Он уже умеет дополнительно показывать результат. Но работает медленно. Особенно на больших документах.

В общем - перепопробовал, - не нравится. Решил писать в mousepad, а потом конвертить с помощью pandoc.

Написал скрипт для удобства пользования - меняется дата файла - автоматом резервная копия версии и конвертация в фоне.

Начал работать и тут вскрылась куча недостатков markdown;

1. Нет нормального форматирования (заголовок нельзя центрировать)
2. Нет нормальных таблиц, один ущерб какой-то.
3. Проблема с кирилицей (решаемая), но с помощью дополнительного tex-файла настроек.

\usepackage{longtable}\setlength{\LTleft}{2em}
\setmainfont{Liberation Serif}
\setsansfont{Liberation Sans}
\setmonofont{Liberation Mono}
\newfontfamily\cyrillicfont{Liberation Sans}
\defaultfontfeatures{Scale=MatchLowercase, Mapping=tex-text}
\usepackage{polyglossia}
\setmainlanguage{russian}
\setotherlanguage{english}

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

Единственный плюс - подсветка синтаксиса bash.

В общем, после 19 главы я понял, что моего терпения не хватит закончить работу. Вернулся к libreoffice. За два дня освоил работу со стилями, и все пошло как по маслу. Кстати, экспорт в pdf тоже быстрее, на мой взгляд.

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

Замечания и комментарии приветствуются.

С результатом можно ознакомиться здесь 👇

🅰️🅰️
➡️ https://github.com/tagd-tagd/self-instruction
🅰️🅰️

🛠 #bash #linux #utilites #markdown
—
✅ @bashdays / @linuxfactory / @blog

Сегодня будем убивать неугодные сервисы. Нет, тут будет не про kill и т.п. а будет все тот же systemd.

Короче в юните можно указать параметр RuntimeMaxSec, в нем задаём время жизни сервиса. Если сервис работает дольше указанного времени, то ему песда. Systemd принудительно завершит его.
ㅤ
Удобно применять для сервисов, которые не должны жить вечно. Нет ничего вечного! Например, временные задачи, вспомогательные демоны, скрипты и т.п.

[Service]
RuntimeMaxSec=30s

0s, 5min, 1h, 2d — интервалы
infinity — отключение лимита

А что будет если время вышло?

Как и написал выше — будет песда! Systemd пошлет SIGTERM. А если сервис сука живучий и не завершился, то в ход пойдет тяжелая артиллерия через TimeoutStopSec, тут уже будет послан SIGKILL. Но его нужно предварительно прописать.

TimeoutStopSec= — это время ожидания корректного завершения сервиса после того, как systemd послал ему сигнал SIGTERM.

[Service]
ExecStart=/usr/bin/python3 /opt/scripts/bashdays-task.py
RuntimeMaxSec=60

Этот сервис будет убит через 60 секунд после запуска — даже если скрипт ещё не завершился.

[Service]
ExecStart=/usr/bin/bashdays-daemon
RuntimeMaxSec=60
TimeoutStopSec=10

Если bashdays-daemon работает дольше 60 секунд → SIGTERM
Ждём до 10 секунд → если не завершился → SIGKILL

Частый паттерн

RuntimeMaxSec=300
TimeoutStopSec=5
Restart=on-failure

Сервис работает максимум 5 минут, и если завис — systemd подождёт 5 секунд на аккуратное завершение, а потом прибьёт его нахуй.

А нахуя тут Restart=on-failure?

Оно говорит — «если сервис завершился аварийно — перезапусти его» А завершение по SIGKILL из-за превышения времени жизни это и есть failure.

Если не указать TimeoutStopSec, будет использоваться значение по умолчанию: 90 секунд — порой это дохуя, поэтому предпочтительнее задать его руками.

Важный нюанс!

Если в юните используется Restart=always, то после убийства, сервис будет перезапущен и возможно сразу «помрёт» если не изменит своё поведение.

Такие дела, изучай!

🛠 #linux #tricks #debug #systemd #bash
—
✅ @bashdays / @linuxfactory / @blog

reexec VS reload

Порой народ путает команды systemctl daemon-reload и systemctl daemon-reexec.
ㅤ
С виду вроде похожие, но нет. Спросил тут на досуге товарища — а ты знаешь чем они отличаются?

Да, ответил товариш, reexec это старая версия перечитывания сервисов и юнитов. Я обычно делаю так:

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable node_exporter
systemctl start node_exporter

Неее… так не нужно! Это хуйня! По крайней мере первая команда тебе тут не нужна для перезапуска и обновления сервисов.

Команда systemctl daemon-reexec перезапускает сам systemd, это нужно например при обновлении бинарников systemd, но никак не для перезапуска юнитов и сервисов.

После редактирования *.service / *.timer / *.mount файлов, достаточно сделать daemon-reload, эта команда перечитает unit-файлы.

Обычно проходится по каталогам:

/etc/systemd/system/
/lib/systemd/system/
/usr/lib/systemd/system/
/run/systemd/system/

То есть она перезагружает только конфигурацию юнитов, без перезапуска сервисов.

Так что не путай, в большинстве случаев тебе достаточно daemon-reload.

🛠 #linux #tricks #debug #systemd
—
✅ @bashdays / @linuxfactory / @blog

Хочется двухфакторную аутентификацию, но внутренний параноик запрещает пользоваться сторонними сервисами аутентификации.

🔤🔤🔥🔤🔤🔤🔤

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

Итак, идея проста.

1. Прописываем shell-скрипт пользователю в качестве shell. Или группе в ForceCommand в sshd_config.
ㅤ
2. После первого уровня (пароль или ключ) запускается скрипт.

3. Скрипт выводит на экран код и отправляет на почту/телегу админу сообщение о попытке аутентификации (ведь первый уровень аутентификации пройден) пользователя с UID (чтобы не светить логины на сторонних ресурсах.)

4. Сам скрипт никаких дополнительных действий от пользователя не требует, и завершается через некоторое время (3-15 минут) если от пользователя нет кода.

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

6. Скрипт, периодически проверяя почту/телегу, при получении нужного кода передает управление bash. УРА, Я В ДОМИКЕ.

7. Если код не пришел, в лог записывается инфа, timestamp username. Если кто-то попытается досить - другой скрипт (нужны права) может банить.

8. В качестве дополнительной ограничительной меры в /etc/passwd в поле 5 GECOS можно прописать мыло или номер tg-чата, с которого ожидается код.

9. Скрипт завершается при любой ошибке.

Ну и конечно, Пользователь отправляет код с телефона, а не того компа, с которого подключается по ssh :-)

🛠 #вопросвзал
—
✅ @bashdays / @linuxfactory / @blog

Имена файлов удаляются с помощью системных вызовов unlink, unlinkat.
ㅤ
Ну дак вот. Когда счетчик ссылок (имен) становится равен нулю — файл удаляется.

Физическое удаление (блоки маркируются свободными) происходит когда больше никто не удерживает файл. То есть процесс закрыл последний дескриптор ассоциированный с файлом.

Давай попробуем поймать (открыть файл) до того, как запустится вызов unlink.

Создаем искусственный временный файл:

printf '%s\n' {a..z} > /tmp/sh-thd-bashdays

Создаем и запускаем скрипт:

#!/bin/bash

file=/tmp/sh-thd-bashdays
exec 3< "$file"  
rm -vf "$file"      # Имени уже нет 
read -N 4096 -ru 3  # Но мы читаем  
printf '%s' $REPLY  # Выводим
exec 3>&-  
exit

Что тут происходит?

exec 3< - файл открывается на чтение, привязывается к дескриптору 3 и с этого момента файл начинает жить в «памяти» в open file table ядра, даже если мы его ёбнем удалим. Дескриптор 3 теперь указывает на открытый файл, независимо от имени.

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

read -N 4096 - читаем до 4096 байт из открытого файла через дескриптор 3.

exec 3>& - закрываем дескриптор 3 и после этого файл окончательно исчезнет, если его больше никто не держит, а ядро высвобождает ресурсы.

Итоги:

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

Это классическая Unix-модель: имя файла — не сам файл, а просто ссылка.

Если держишь дескриптор — файл всё ещё существует.

А тут как-то рассказывал, как восстанавливать удаленные файлы, в том числе и запущенные.


Чтиво почитать:

man 2 unlink
man 2 unlinkat

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

Напозырить и ужаснуться

50 GNU Commands VS 50 PowerShell Commands
ㅤ
🛠 #bash #powershell
—
✅ @bashdays / @linuxfactory / @blog

CRON в первый рабочий день месяца
ㅤ
Да, ключевой момент тут именно в «рабочий день».

Задачка вроде не тривиальная, но как оказалось cron нихуя не умеет определять рабочий сегодня день или нет. И systemd timer тоже не умеет. Никто ничо блядь не умеет.

Мы с тобой не пальцем деланы, изобретем свой велосипед!

Чтобы реализовать желаемое, я изобрел такую кишку:

0 8 1-3 * * [ "$(date +\%u)" -lt 6 ] && [ "$(curl -s https://isdayoff.ru/$(date +\%Y\%m\%d))" = "0" ] && /usr/local/sbin/bashdays.sh

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

Что тут происходит?

Короче…

0 8 1-3 * * — Запуск 1–3 числа месяца в 08:00. Потому что первый рабочий день месяца может выпасть на 1-е число, если это будний день. 2-е число, если 1-е — выходной. 3-е число, если 1-е и 2-е — выходные (например, сб + вс).

[ "$(date +%u)" -lt 6 ] — Проверяем, что сегодня будний день (1–5 = Пн–Пт). Пусть тебя здесь 6ка не смущает. Она означает: день меньше 6, т.е. 1, 2, 3, 4, 5 — это будни (Пн – Пт).

curl ... = "0" — Проверка, что сегодня рабочий день по календарю РФ, выполняется через АПИху производственного календаря.

&& /opt/scripts/first-workday.sh — Выполняем только если сошлись оба условия.

То есть АПИха возвращает 0 если сегодня будни. Если выходной, то оно вернет что-то другое.

Тут еще бы для curl и date указать что-то вроде CURL=$(which curl), а то крон частенько залупается и не знает откуда запускать эти команды.

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

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

Если знаешь еще какие-то способы, велком в комментарии.

UPD: более корректные алгоритмы решения этой задачи смотрим в комментах, всем спасибо!

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

Порой заёбываешь подбирать свободный домен для собственных нужд, но на любую хотелку уже есть утилита.
ㅤ
Сегодня тыкаем domain-check. Как раз вышла новая версия v0.6.0. Проект молодой, но достаточно перспективный, а самое главное с отрытым исходным кодом.

Установка простая:

curl https://sh.rustup.rs -sSf | sh
. "$HOME/.cargo/env"
cargo install domain-check

Либо качаем отсюда бинарник под свою ОС.

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

domain-check linuxfactory -t ru,com,io,dev

Опа, опа, нихуя се!

linuxfactory.dev AVAILABLE
linuxfactory.ru TAKEN
linuxfactory.com TAKEN
linuxfactory.io AVAILABLE

Summary: 2 available, 2 taken, 0 unknown (processed in 0.9s)

Выбираем свободный и по желанию регаем. У domain-check дохера ключей и методов подбора/проверки.

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

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

🛠 #utilites
—
✅ @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

Довольно частый вопрос с 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

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

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

♉️ Телец

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

♊️ Близнецы

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

♋️ Рак

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

♌️ Лев

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

♍️ Дева

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

♎️ Весы

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

♏️ Скорпион

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

♐️ Стрелец

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

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

♒️ Водолей

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

♓️ Рыбы

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

🛠 #гороскопыотромана
—
✅ @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

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

🔤🔤🔥🔤🔤🔤🔤

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.
ㅤ
Соединение с 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