Bash Days | Linux | DevOps

Сегодня необычный скрипт, который позволит тебе сгенерировать пароль состоящий из пробелов и прочих невидимых символов. Что-то из оперы Шрёдингера — ты никогда не узнаешь гениально это или ужасно, пока сам не попробуешь. От этой штуки тестировщики разбегаются в ужасе. А веб-сайты на которых ты попытаешься использовать такой пароль, просто-напросто порвутся и выпустят 500ю соплю. Забрать и потыкать этот прекрасный скрипт можешь из нашей репы. Не знаю где это можно применить, но идея с паролем которого не видно, очень интересная. Я попробовал сохранить то, что получилось в bitwarden, отлично сохранился. Да, пароль получается с симметричной защитой 128 бит. tags: #linux #bash #utils — 💩 @bashdays

​​Многие тут уже в курсе, что я перелез с хакинтоша на винду + wsl. Ну дак вот. В макоси я привык работать в iTerm который работал по принципу - нажал F1 у меня сверху вниз вылез терминал. Нажал еще раз и он залез обратно. Прекрасный режим и называется он quake mode. В линуксах он тоже есть, пользовался им постоянно. Пересев на винду я сказал в слух - пу, пу, пу.... И как жить дальше с этим Windows Terminal (Preview)? Как мне вернуться в зону комфорта и quake mode? Оказалось достаточно просто. Добавляем в settings.json (от Windows Terminal) такую фигню:

"command":
   {
       "action": "globalSummon",
       "desktop": "toCurrent",
       "dropdownDuration": 5,
       "monitor": "any",
       "name": "_quake",
       "toggleVisibility": true
   },
       "keys": "f1"
   },

Сохраняем. И теперь по нажатию F1 у меня выезжает терминал, поверх всех окон, с любого рабочего пространства. А кнопку F1 можешь заменить на любое удобное тебе сочетание. Так, но радость была не долгая. Терминал то выезжает, но нет TABов и чо мне делать с одним гавном окном? Мне то надо 10 серверов открыть и бегать по вкладкам. Тут решение тоже неочевидное. Создаешь вкладку сочетанием CTRL+SHIFT+T. Открывается новый терминал, НО предыдущий куда-то исчезает! Да ёбтвоюмать! Короче утро вечера мудренее и с утра я это тему победил. Для переключения вкладок нужно нажать CTRL+TAB, выпадет список всех открытых вкладок, между которыми можно переключаться. Уже хорошо, НО!!!! Как без этих контролтабов визуально видеть какие вкладки у меня открыты? Утро вечера мудренее... Пофиксил и это! Нажимаем в терминале CTRL+SHIFT+P, открывается хрен пойми какая-то менюшка. Набираем Toggle focus mode и активируем. Опа! Вкладочки появились! Теперь можно мышкой по ним кликать. Уверен что можно в settings.json этот focus включить по умолчанию. Ура! Зона комфорта возвращена! Еще был дискомфорт, что терминал выезжает лишь до середины экрана, но я сильно не стал заморачиваться и растянул его мышкой. Но всяко есть способ через конфиг сделать чтобы он на весь экран открывался. Если знаешь, маякни в комментах. Вообще quake mode охренительно разгоняет продуктивность, а эффективность повышается. Терминал на расстоянии вытянутого пальца. Всем рекомендую подсесть на это иглу, потом слезть с нее просто так не получится. Ну удобно чо. А почему я променял макось на винду, расскажу в следующих постах. Пока пока и хорошего вечера! tags: #рабочиебудни — 💩 @bashdays

7 декабря, 19:30 Selectel Admin Meetup. Управляй, упрощай, автоматизируй! Ребята из @SelectelCareers проводят митап для системных администраторов и девопсов. Спикеры расскажут про управление инфраструктурой, упрощение работы администратора, автоматизацию процессов и, конечно, про ChatGPT (куда без него). Темы докладов: ◽️ «Ускоряемся с GitOps: автоматизация рабочих процессов», Антон Алексеев, Selectel В докладе Антон расскажет, как оптимизировать узкие горлышки с помощью GitOps. А также, как они в Selectel автоматизировали настройку инфраструктуры и ускорили ее в 20 раз. ◽️ «Рефакторим Ansible плейбуки с помощью ChatGPT», Мария Портнова, Selectel Когда у вас большой Ansible плейбук, бывает сложно читать код, а тем более дебажить его. В докладе Мария поделится опытом рефакторинга такого плейбука, а также расскажет, как использовала ChatGPT для решения проблем. ◽️ «Service discovery в Prometheus — это не страшно», Владимир Дроздецкий, Магнит Владимир расскажет про service discovery в Prometheus: как он устроен и как сделать интеграцию с Consul. А также не обойдет стороной тему, как строить красивые дашборды в Grafana. Приглашаем в офис Selectel всех, кто в Санкт‑Петербурге: https://slc.tl/u1blr А если не сможете присоединиться лично, подключайтесь онлайн: https://slc.tl/2h7rb Реклама ООО «Селектел» erid 2VtzqwcAg8p

Вчера не по своей воле дебажил веб апликуху на laravel, в 500ку сопливило. Нашел что не существует путь, куда оно хочет записать сессию, кэш и т.п. шляпу. Типа такого app/data/storage/data. Path not found. Плюсом там еще вывалило кучу вложенных папок которых не существует для нормальной работы. Ок, уже есть с чем работать. В идеальном мире обычно разработчики сами чекают такие директории и автоматически их создают, но это в идеальном мире. На деле все иначе. Время допиливать нет, поэтому скинем эту задачу на девопсов, пусть закостылят какой-нибудь скрипт. А как создать структуру папок из скрипта? Можно и так:

mkdir /var/www/app/storage
mkdir /var/www/app/storage/data
mkdir /var/www/app/storage/data/public
mkdir /var/www/app/storage/data/view
mkdir /var/www/app/storage/data/view/public/html
mkdir /var/www/app/storage/data/meta
mkdir /var/www/app/storage/data/meta/bundle

Вполне читаемо. Но если ты не знаешь, у mkdir есть аргумент, который создаст полностью структуру несуществующих папок. А если оно существует, то лишний раз орать не станет. Работает это так:

mkdir -p /var/www/app/storage/{data/public,data/view,data/public/html,data/meta/bundle}

-p, --parents = no error if existing, make parent directories as needed Заметь что я отдельно не создаю папку meta и view/public, они создаются в момент создания конченных папок bundle и html. Если посмотреть strace, то видим с какими параметрами запустился mkdir

execve("/usr/bin/mkdir", ["mkdir", "-p", "/var/www/app/storage/data/public", "/var/www/app/storage/data/view", "/var/www/app/storage/public/html", "/var/www/app/storage/data/meta/b"...

А можно вынести все пути в отдельный файл, а потом через цикл прогнать. Но я бы не стал по файлам раскидывать, сделал бы какой-нибудь массив путей и передал на съедение mkdir. Как я и сказал выше, в данном контексте задачи - это костыль. Но если вернуть эту задачу на разработчиков, 100% вернется техдир и скажет - уважаемый, не делай мне нервы, СОЗДАЙ НУЖНЫЕ ПАПКИ САМ!!! Это проблема на сервере, а не в коде. В этом споре победителей не будет. Если команда хочет костылей, она их получает. Но я все же придерживаюсь поговорки - Нормально делай, нормально будет. Хотя по большей части это справедливо лишь для моих личных проектов, где я всегда найду время и на юнит-тесты и на рефакторинг. Хорошего вторника и увидимся вечерком. tags: #linux #bash #рабочиебудни — 💩 @bashdays

Привет еще раз, извиняй что поздно, так нужно. Сегодня моя продуктивность явно зашкаливает, завтра видимо пластом буду лежать как тюлень. Ладно. Давай по теме. Знал ли ты про такую команду в linux как - «yes»? Сейчас про нее и пойдет речь. Команда yes служит для вывода в стандартный поток (stdout) строки «y» или любой другой строки. Если ее запустить по умолчанию, команда будет бесконечно сыпать строку «y». А если указать аргумент и запустить так: yes hues (да - пизда) в stdout насыпет строку «hues». Интересно? Ну такое себе... давай дальше возбуждать интерес. К примеру есть у тебя какая-нибудь консольная команда, которая во время своей работы будет запрашивать подтверждение, типа - а ты точно уверен, что удаляешь тестовую базу данных? Вот на такие случаи и нужна команда «yes», чтобы не руками вводить подтверждение, а делегировать это действие. Полезно для пайплайнов. Бывает такое, что у программы нет ключей типа apt -y install, а подтверждать как-то в автоматическом режиме нужно. Синтаксис проброса стандартный, через систему пайпов:

yes | apt install nginx

В примере выше, когда пакетный менеджер попросит нажать Y, команда «yes» автоматически это заапрувит и начнется процесс установки. Красота! Не забываем, про передачу аргументов, если внешняя программа например хочет чтобы ты ввел слово: «ъyъ» делаем так:

yes ъуъ | apt install nginx

Но обычно на практике, в 99% случаев команда «yes» запускается без аргументов, так как большинство запрашивает именно Yes. POSIX стандарты? 🫥 Прикол еще. Раз есть команда «yes» значит должна быть и «no». Но увы, обделили! Так вот если нужно отнекиваться, передай в «yes» аргументом строку «no». Прям лайкфак! Ааа, еще нюанс. Порой что-то может запросить простого нажатия Enter, например когда gpg ключ добавляешь для репозитория. Как послать Enter? А вот так:

yes "" | <твоя команда>

Почему это сработает как Enter? Потому, что команда «yes» выводит в stdout не просто сроку Y, но еще и завершает ее в конце символом Enter. Вот именно поэтому при запуске чистого «yes», строчки на экране будут идти столбиком. Собственно это всё что тебе нужно знать про «yes». Бери на вооружение, мне пару раз пригодилась, именно в gitlab пайплайнах. Давай, доброй ночи, завтра обязательно увидимся! tags: #linux #utilites #bash — 💩 @bashdays

Когда-нибудь задумывались, как DevOps можно подружить с продуктовым подходом? Именно об этом одиннадцатый выпуск подкаста «Магнитное Поле», в гостях у которого Владимир Пашковский, тимлид DevOps ритейлера Магнит. В этом выпуске много интересных инсайтов на тему того, какие стандартные и фреймворки использует в продуктовой интеграции DevOps, как выстроить взаимодействие между членами команды и стейкхолдерами, как может помочь паттернизация, какую политику релизов используют в Магните, как обрабатывают фичер-реквесты, кто отвечает за SLA, а еще как не выгореть на работе или как коммерциализировать внутренний энтерпрайз-софта. Это уже одиннадцатый выпуск подкаста «Магнитное Поле», который совместно делает проект @zavtracast и IT-команда ритейлера Магнит. В нем рассказывается про разные аспекты работы огромной технологической компании с тысячами сотрудников – в предыдущих выпусках обсудили data governance, CJM, дизайн-системы, IT HR, зачем нужен agile, geo BI, ecommerce и многое другое с кучей классных спикеров. 🎧Послушать 📹Посмотреть Реклама. Сейфельмлюков Т.А, ИНН 771672614871, erid: 2Vtzqx7pkBr

Мы часто встречаемся с этим загадочным словом, например в контексте - Posix Shell. Но что такое этот POSIX? POSIX =  Portable Operating System Interface. Хорошо, ок, понятнее не стало. Короче это такой стандарт типа ГОСТа. Разработали его в бородатые 80е года, а название придумал Ричард Столлман. Тот самый основатель ГНУтого движения. Задумка POSIX заключается в том, что разработчик должен создать приложение, которое будет работать в любой системе. Естественно система должна соответствовать этому стандарту. На сегодняшний момент большинство linux дистрибутивов официально не сертифицированы POSIX. Причина одна — это дофига стоит, а у всяких создателей BolgenOS на это банально нет денег. Да и нафига? С другой стороны большинство этих дистрибутивов стараются придерживаться POSIX. Так что когда кто-то говорит Posix Shell, это значит то, что оно соответствует стандартам. Написав скрипт который корректно запускается и работает в оболочке sh, ты можешь быть уверен, что этот скрипт будет работать — на всех линуксах. Если подытожить: для рядовых пользователей linux вся эта кухня избыточна. Мы как велосипедили, так и продолжим. Главное чтобы все работало. По сути, POSIX предназначен для проектировщиков операционных систем и разработчиков программного обеспечения, но как пользователи системы мы подвержены влиянию POSIX, осознаем мы это или нет. Вот теперь и ты знаешь, что такое этот POSIX. Увидимся! tags: #linux — 💩 @bashdays

[[ ]] vs [ ] Как оказалось не каждый знает чем, отличается использование двойных квадратных скобок в скриптах от одинарных. В контексте «не каждый», из 10 человек которых я опросил, правильно ответили лишь двое и то с присказкой - мне кажется и наверное. Я тоже одно время не обращал на это внимание. Просто писал где-то одинарные, где-то двойные, наверное от погоды зависело. Но в какой-то момент меня это начало ковырять. Пришлось разобраться. В общем как оказалось все просто. Скрипты с двойными скобками будут работать нативно в bash и ksh. А вот во всяких POSIX оболочках таких, как например sh (и в других на основе sh) - выпадет ошибка. А еще в двойных скобках можно использовать операторы: ||, &&, <, ==, =~. А вот с sh такое провернуть не получится. При использовании оператора < в двойных скобках, экранирование не нужно.

#/bin/sh
[ "$s < abc" ]

#/bin/bash
[[ abc < abc ]]

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

#/bin/bash

s="abc123"
[[ "$s" == abc* ]]         # true (globbing)
[[ "$s" == "abc*" ]]       # false (literal matching)
[[ "$s" =~ [abc]+[567]+ ]] # true (regular expression)
[[ "$s" =~ "abc*" ]]       # false (literal matching)

Если заменить первую строчку на #/bin/sh, то после запуска вылетит ошибка [[: not found. Короче говоря, если хочешь чтобы твои скрипты работали везде, используй синтаксис с одинарными скобками. Но в свою очередь использование двойных скобок и связанных с ними фич, делают код более читаемым и ясным для понимания. В общем я забил на переносимость между системами и теперь всегда использую только двойные скобки. Это как с табами и пробелами, главное однажды сделать выбор и потом этого выбора придерживаться. Всем привет и увидимся! tags: #linux #bash — 💩 @bashdays

Чем более сложные задачи можешь решить быстро и эффективно, тем выше твой командный рейтинг, тем более интересную работу можешь выбрать, тем выше она оплачивается. Одна из самых сложных IT-задач для QA, разработчиков, DevOps и других специалистов - локализация дефектов в сложных серверных приложениях. Он же траблшутинг. Умение быстро и без привлечения половины команды найти причину сложной неисправности - это то, что отличает столь ценных для работодателя спецов от малоопытных новичков. В прямых эфирах препарируем и обсуждаем сложные кейсы системной инженерии, требующие неплохого знания архитектуры, Linux и сетей. В очередном прямом эфире траблшутим и разбираем 3 сложных кейса, которые могут испортить рабочую неделю всей команде. 🧠 Главный хирург: строгий Федор Кулишов. Ведущий эксперт по безопасности в Acronis (CH), ментор по Linux, сетям и траблшутингу. В IT с 2005 года. Рекомендуется для не желающих закисать: - Middle+ QA, разработчикам и системным аналитикам - Middle DevOps и админам Ближайший стрим - 22 ноября в 19:00 МСК. Ссылка на стрим появится в телеграм-канале за 10 минут до начала. Реклама. ООО «Менторпис» ИНН 01058908, erid: 2VtzqvEKNyv

Мои студенты недавно интересовались, как и чем я делаю запись экрана с терминала. Поделюсь и с вами. Начнем с того, что я не записываю терминал в реальном времени. Сначала я создаю сценарий, который в автоматическом режиме будет печатать нужные мне команды. А на выходе получается полноценный gif файл. Софтина называется VHS. Позволяет ЧЕРЕЗ КОД записать gif файл. VHS написана на модном golang. Для начала устанавливаем. Есть под все операционки, в документации найди свой дистрибутив и накопипасти в терминал. Я ничего не устанавливал, а пользуюсь docker версией, мне так удобнее, все зависимости упакованы в контейнер. Но если от докера тебя выворачивает, можешь всегда собрать всё это из исходников. Создаем файл сценария bashdays.tape

vim bashdays.tape

И пишем код:

Output bashdays.gif
Require echo

Set Shell "bash"
Set FontSize 32
Set Width 1920
Set Height 1080

Type "echo 'Hello this is BashDays'" Sleep 500ms  Enter
Type "apt install -f nginx" Sleep 500ms Enter

Sleep 5s

Думаю тут все интуитивно понятно, откроется оболочка bash, настроятся шрифты, высота, длиннота и сообщение которое будет напечатано. Либо команда, которая будет выполнена. Настроек там дофига, но как обычно 90% никем не используются. После того как сценарий готов, запускаем:

docker run --rm -v $PWD:/vhs ghcr.io/charmbracelet/vhs bashdays.tape

Наблюдаем за процессом создания и на выходе получаем файл bashdays.gif. В котором будет вывод строки через echo и процесс установки nginx. Получившийся gif файл можно не отходя от кассы сразу зашарить на какой-то расшаренный сервер. Вот такой командой:

docker run --rm -v $PWD:/vhs ghcr.io/charmbracelet/vhs publish bashdays.gif

По итогу получишь прямую ссылку вида: https://vhs.charm.sh/vhs-62gl16v.gif Ну а дальше уже втыкай свои гифки в корпоративные wiki, или куда там ты их втыкаешь. Короче штука ОФИГИТЕЛЬНАЯ. Всем рекомендую! 🐱 Сраница проекта на github Всех с пятницей, хороших предстоящий выходных и береги себя! 🤩 tags: #linux #utilites — 💩 @bashdays

🗓 21 ноября, 16:00 📌Kubernetes Workshop: как развернуть сайт с помощью Terraform Присоединяйтесь на практический вебинар от @Selectel, на котором коллеги расскажут, как развернуть сайт в Kubernetes. При работе будут использованы сервисы Container Registry, Managed Kubernetes, менеджер секретов и DNS-хостинг. Во второй части вебинара вас ждут ответы на вопросы и разбор интересных кейсов по работе с Kubernetes. Основные темы: ▫️Создание в Terraform кластера Kubernetes и реестра для хранения образов контейнеров ▫️Настройка интеграции между Managed Kubernetes и Container Registry ▫️Добавление домена в DNS-хостинг Selectel ▫️Разбор кейсов по работе с Kubernetes и ответы на вопросы Регистрируйтесь на мероприятие и участвуйте в розыгрыше приза за лучший вопрос: https://slc.tl/z39vp Реклама ООО «Селектел» erid 2Vtzqx5Jv9E

Тут недавно у нас в чатике пролетал способ как скрыть процессы в Linux от других пользователей. Пожалуй этот момент стоит поподробнее просветить и тут. Тема интересная. К примеру есть многопользовательский сервер. Юзера конектятся к нему по ssh. И я не хочу чтобы какой-нибудь там Василий Волоёбович знал, что у меня запущена порнокачалка. По идее если запустить pstree, ps, htop и др. То мы увидим процессы не только свои, но также системные и пользовательские. Чтобы скрыть свои процессы от других пользователей, всего лишь нужно перемонтировать /proc с опцией hidepid. Работает только с пользователями, рут будет по-прежнему в курсе запущенной порнокачалки. Параметр hidepid определяет какую информацию о процессах мы ограничим для пользователей, которые не являются владельцами этих процессов. Параметры которые можно задать: hidepid=0 - Включена по умолчанию, все видят всё, полный доступ к /proc/PID/. hidepid=1 - Разрешает обращаться к информации только о своих процессов. Часть файлов в каталоге /proc/PID/ защищена от любопытных морд. hidepid=2 - Это тот же самый hidepid=1 + всё в /proc/PID будет невидимо для других пользователей. Граница на замке. Чтобы убедиться, что ты видишь процессы других, запусти от обычного пользователя например htop. В левой колонке будут имена пользователей, root, грут, пруд, фрукт, daemon, syslog и т.п. Давай теперь закроем этот «бэкдор». Запускаем от рута:

mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

Теперь снова запускаем от обычного пользователя htop и наблюдаем интересную картину маслом. Портянка из процессов пропала, у меня осталось лишь 2 штуки, bash и htop. Красота! Естественно после ребута сервера, вся эта красота сгинет. А чтобы этого не произошло, зафигач монтирование /proc в fstab. Вставляем в /etc/fstab

proc /proc proc defaults,nosuid, nodev, noexec,relatime,hidepid=2 0 0

Вот и всё. Но есть одно НО. Встречаются приложения которые могут отвалиться. Для этого нужно захотфиксить маунт с опцией gid=VALUE. Значением gid параметра может быть имя группы в системе, членам которой доступ к процессам будет разрешён. И затем маунтить /proc таким образом:

proc /proc proc defaults, hidepid=2, gid=bashdays 0 0

Добавляем пользователя от имени которого будет работать приложение/демон в эту группу и проверяем — если всё сделано верно, то зафакапленное приложение заработает как обычно. Такие дела. Изучай. На связи! tags: #linux #utilites — 💩 @bashdays

Доброе всем! Я как ценитель всяких бумажных Bullet Journal и подобных ежедневников, в какой-то момент перегорел. Стало лень писать ручкой, заполнять задачки и планировать рабочий день. Не знаю по какой причине это произошло. Но скорее всего по причине — если ты спланировал свой день, 100% все пойдет попизде не по плану. Это как со скрам спринтами, спланировали спринт, тут же прибежала озабоченная обезьяна и насувала в кабину «очень» срочных задач. Понятно дело, это на подсознании отлично демотивирует. Но без личного таск-трекера опять же никуда. Носить в голове 100500 задач, рабочих, бытовых и т.п. не вариант. Сейчас ты помнишь, что нужно было оплатить домен, а через секунду уже не помнишь. Классика. Я так недавно промотал оплату корпоративного VPN и пришлось в срочном порядке платить со своей личной карты. Естественно потом мне бабки никто не вернул. Бюрократия. Игра не стоит свеч. По крайней мере у меня так. Поэтому я стараюсь все выгружать из головы в одно место. Нет, не в жопу. Раньше на бумагу, а теперь прям в консольный TaskWarrior. Щас расскажу, что это за пепяка такая. TaskWarrior это консольный трекер-задач с открытым исходным кодом. Черношляпы еще его называют ТуДу-ВуДу лист для хакеров. Короче, открываем консольку…

У меня вообще с этим отлично реализовано в iTerm. Консолька открывается в Drop-down режиме по нажатию F1. То есть сверху вниз, поверх всех окон выезжает мой основной рабочий инструмент. Ну и также закрывается. Привык, ОЧЕНЬ удобно! Под линуксы и винду такое тоже реализуемо и есть из коробки. Отдельный пост про это надо будет запилить.

Давай создадим в TW первую таску:

task add "Написать пост про taskwarrior"

Всё! Задачка в бэклоге и про нее уже не забудешь, можно смело выкидывать из головы и торжествовать. Конечно же предварительно taskwarrior нужно установить, есть под все операционки и дистрибутивы. Дока по установке тут. Ставится на уровне пакетных менеджеров, но можно и через исходники скомпилировать если ты любитель прекрасного. Как говорится на этом можно и закончить. Но хотелось бы еще посмотреть список всех задачек, которые мы создали. Для этого фигачим:

task ls

И получаем желаемый список Ну а чтобы пометить таску как выполненную, делаем:

task done 1/2/3/4/5

Подставляем индекс таски, которую нужно закрыть. Всё! Это основное. Простота и удобство! Не думай что TW на столько ущербен, там из коробки просто нереальный функционал. Но я использую наверное процента два от всего возможного. Дополнительно у меня создано 2 проекта, home и work. По ним раскидываю задачи, которые относятся к домашним делам и рабочим. Чтобы было проще ориентироваться и выводить нужные на экран. Чтобы синхронизировать заметки и задачи между устройствами, нужно поднять свой ламповый сервер. Будет единая точка входа с базой данных. А там уже цепляйся к нему хоть с писюка хоть с андроида/ios, и крути педали. Удобнее конечно через docker-compose все поднимать. Для удобства я сделал себе несколько алиасов, теперь мне не нужно каждый раз писать task и название проекта.

alias th="task project:home add "
alias tw="task project:work add "
alias tlh="task project:home ls "
alias tlw="task project:work ls "

В общем в TW полный минимализм и отличная кастомизация для всех любителей консольных штук. Еще можно настроить цвета, приоритеты, поглядеть отчеты и многое другое. Но мне хватает коробочного варианта. В общем всем советую потыкать. 💩страница проекта 🐱 страница на гитхабе 💩 клиент для андроида и тут 💩 клиент для айфона Как это выглядит визуально, можешь глянуть тут, подзалил нативно картичночки. А тут крутой sheets по tw. Ладно, убежал. Если бухгалтерию разгребу, вечерком чего-нибудь забашим или обсудим! tags: #linux #utilites #рабочиебудни — 💩 @bashdays

Давай повелосипедим и напишем таймер на со-процессах, без использования каких-то внешних команд типа sleep и т.п.

#!/bin/bash

coproc read 
read -t 0.10 -u "${COPROC[0]}"
echo 'new velosiped' 
read -t 11 -u "${COPROC[0]}"
exit

1. Создаем фоновый со-процесс read 2. Спим 0.10 секунды 3. Выводим на экран new velosiped 4. Опять спим, но уже 11 секунд 5. Выходим За указания задержки, как раз отвечает параметр -t. А параметр -u говорит что чтение данных нужно осуществлять с файлового дескриптора запущенного в фоне со-процесса. Белиберда? Еще какая! В sleep, кстати тоже можно указывать миллисекунды: sleep 0.10 Со-процессинг это одновременное выполнение двух процедур, одна из которых считывает вывод другой. Чтобы запустить со-процесс, используется зарезервированное слово coproc. Доступ к этому со-процессу осуществляется посредствам массива COPROC. ${COPROC[0]} - для записи ${COPROC[1]} - для чтения В реализации такого таймера есть и подводные камни. Таймер может отставать как механические часы, это зависит от загруженности самой системы. Если запустить одну команду coproc read, на экран выведется PID запущенного в фоне процесса [1] 126594. Чтобы посмотреть список запущенных в фоне команд, выполняем jobs и видим список:

[1] Running coproc COPROC read &
[2] Running coproc COPROC read &
[3] Running coproc COPROC read &

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

coproc awk '{print $2;fflush();}'
echo bom bim bom >&${COPROC[1]}
read -ru ${COPROC[0]} var
echo $var

По итогу получаем вывод на экран, слово: bim Давай попробуем попроще:

coproc (echo $(whoami))
read -r user <&"${COPROC[0]}"
echo $user

1. Создаем со-процесс, который в фоне выполнит whoami 2. Прочитаем в переменную user, то что вывел со-процесс 3. Выводим на экран, у меня отобразилось root Фуф, тут вроде более понятно получилось объяснить. Ну а если не понял, значит оно нахер тебе и не нужно. Короче без бутылки тут не разобраться, это из оперы «высший пилотаж» и брейнфак. Зачем это нужно и где применять? Понятия не имею. Я обычно не лезу в со-процессы, это усложняет скрипт, а коллеги которые не в теме, вообще не смогут его поддерживать. Ну и на закуску, совсем уж упороться: Несколько команд, которые помогут понять, как вся эта шляпа реализована.

coproc read
echo "${COPROC[@]}"
ls -l /proc/$$/fd | grep 'pipe'
ls -l /proc/$COPROC_PID/fd | grep 'pipe'

1. Создаем со-процесс 2. Выводим содержимое массива COPROC 3. Выводим каналы текущей оболочки. 4. Выводим каналы со-процесса. Смотрим на имена, биты разрешений (r/w) ссылок и на что они указывают. Как сказал один западный эксперт:

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

Вот такие пироги, изучай. tags: #linux #bash — 💩 @bashdays

Как не только заметить ошибку в системе, но и понять ее причины? Расскажем на бесплатном открытом уроке «O11y (Observability) - что это? Почему Observability != Monitoring?» от OTUS. На эфире: - изучим основные принципы и практики наблюдаемости; - научимся применять современные инструменты для мониторинга и анализа состояния систем; - узнаем, как настраивать и использовать Prometheus, Grafana, Jaeger и Elasticsearch; - познакомимся с методами трейсировки, экспортом данных мониторинга и настроенными алертами; - рассмотрим примеры использования этих методов на практике. 🗓 Занятие состоится 15 ноября в 20:00 мск в рамках курса «SRE практики и инструменты». После урока вы сможете продолжить обучение в рассрочку. 🌐 Для бесплатного участия в открытом уроке и получения записи регистрируйтесь прямо сейчас, чтобы ничего не пропустить: https://vk.cc/csjaBD

Привет. Не будем нарушать воскресных традиций. Утреннее чтиво. Давай покумекаем, чем отличаются файлы .bashrc .bash_profile .profile и т.п. Вообще про это особо никто не задумывается, если что-то требуется сделать, обычно запихивают всё в .bashrc. Но почему именно туда? А нахрена тогда нужен .profile? Основное различие этих конфигурационных файлов заключается в том, что некоторые из них читаются только оболочками входа (login). Например, при входе в систему с другого хоста или при входе в текстовую консоль локальной unix-машины. Используются файлы .login .profile .zlogin. Зависит от того какая у тебя оболочка. Далее идут конфигурационные файлы, которые читаются «интерактивными» оболочками. То есть подключенными к терминалу или псевдотерминалу. Это файлы с именами .bashrc, .tcshrc, .zshrc и т.д. Файл .bashrc читается только интерактивной и non-login оболочкой, поэтому большинство людей в конечном итоге инклудят в файле .bash_profile чтение файла .bashrc, например:

[[ -r ~/.bashrc ]] && . ~/.bashrc

Другие оболочки ведут себя по-другому. Например, в zsh, файл .zshrc всегда читается для интерактивной оболочки, независимо от того, является ли она login или нет. А файл .profile, это просто сценарий входа в систему. И изначально использовался в /bin/sh. Оболочка Bash, будучи обратно совместимым с sh, будет читать .profile, если он конечно же существует. Пример файла .profile

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

Как видим, при login’е заинклудится файл .bashrc. Классически ~/.profile используется в Bourne Shell. И вероятно, поддерживается Bash как устаревшая мера. Опять же ~/.login и ~/.cshrc использовались оболочкой CShell (csh). В дистрибутивах семейства Debian сначала выполняется .profile, а потом уже .bash_profile. А вот в дистрибах производных от RHEL, сначала выполняется .bash_profile, а уже потом .profile. Ну вот прям каша!  Короче как обычно развели зоопарк, одно читает другое, чтобы заработало третье. Масло-масляное. А есть же еще всякие .environment, у которого ноги растут из Korn Shell (ksh). Вот по этой причине никто особо и не вникает, почему все манипуляции обычно производятся в файле .bashrc. Этот файл обычно есть везде и всегда, а большего и не нужно. В документации bash хорошо объясняется, при каких обстоятельствах читается каждый файл. И поведение на разных машинах в целом одинаково. Выжимка из man bash:

/bin/bash - The bash executable
/etc/profile - The systemwide initialization file, executed for login shells
/etc/bash.bashrc - The systemwide per-interactive-shell startup file
/etc/bash.bash.logout - The systemwide login shell cleanup file, executed when a login shell exits
~/.bash_profile - The personal initialization file, executed for login shells
~/.bashrc - The individual per-interactive-shell startup file
~/.bash_logout - The individual login shell cleanup file, executed when a login shell exits
~/.inputrc - Individual readline initialization file

Если есть чего добавить, велком в комментарии. Ладно, вечерком затроним какую-нибудь техническую часть, а может быть и подебажим. На связи! tags: #linux #bash — 💩 @bashdays

Всем привет кого не видел и новеньким. Нас тут уже овер 10к единомышленников, растем! Вопрос из зала — я бывший java разработчик, подался в девопсы, теперь неспешно изучаю bash. Подскажите, если какая-то альтернатива конструкции try/catch? Начнем с того, что бывших разработчиков не бывает. Даже если ты выйдешь из айти и начнешь ловить крабов, айти не выйдет из тебя. Проверено многолетним опытом и не только моим. Ну а по делу, try/catch в bash — нет. На этом можно было бы и закончить, но увы... давай обсудим. Аналогичного поведения можно добиться используя логический оператор ||. Например:

command1 || command2

Если первая команда вывалит ошибку, то отработает вторая команда. Ну чем не try/catch, Даже лучше! Правда концепция работы не такая как в других языках. На практике это выглядит так:

false || echo "error, returned false"

Сейчас сработает catch и выведет «error, returned false», так как команда false всегда возвращает ошибку. Статус: exit 1. А если false заменить на true, но сработает try и в терминале ничего не отобразится. Бесподобно. Итоговая конструкция будет такой:

#!/bin/bash

{ # try
    echo "hello bashdays"
    false
    
} || { # catch
    echo "error, returned false"
}

Для catch можно сделать отдельную функцию. Которая будет автоматически включать режим дебага (sex -x) либо какие-то другие свистоперделки для отладки. Вообще это больше относится к костылям и подобное можно реализовать с таким же успехом на IF’ах. А можно банально проверять статус выхода, если > 0 то кирдык. Я такие конструкции не использую, максимум втыкаю в начала скрипта set -e. Если статус команды будет > 0, то немедленно всё выпадет в осадок. Тут нет правильных и неправильных решений. Как говорится если работает, то уже хорошо. Остальное детали. Если есть чего добавить, велком в комментарии. Возможно у тебя есть секретный модуль для bash с try/catch. tags: #linux #bash — 💩 @bashdays

Привет, друзья! Есть у меня какой-то долгоиграющий скрипт, который я по дурости запустил в терминале, без nohup и применения screen. Ждать завершения скрипта не вариант, но и завершать его принудительно нельзя. Как быть? Сейчас покажу, поехали. Сделаем подопытный образец, который в цикле будет писать в файл числа от 1 до 10000, чтобы визуально понимать что происходит. Ну и паузу впендюрим 2 секунды, для чистоты эксперимента.

#!/bin/bash

for i in {1..10000}
do
 echo $i >> /tmp/log.txt
 sleep 2
done

Запускаем, ага. Теперь открываем второй терминал и пишем:

tail -f /tmp/log.txt

Видим как файл log.txt постепенно наполняется циферками. Всё прекрасно. Что нужно сделать дальше. А дальше жми сочетание клавиш ctrl+z в первом терминале, где ты запустил скрипт. Комбинация клавиш Ctrl + Z посылает процессу сигнал, который приказывает ему остановиться. Это значит, что процесс остается в системе, но как бы замораживается. Ловим такое:

[1]+ Stopped ./script.sh

Видим что скрипт остановил свою работу. А во втором терминале с tail, цифры перестали заполнять файл log.txt. Ключевое слово - остановил, но не прекратил. Окей, мы на верном пути. А теперь в первом терминале запускай команду bg, в ответ ты увидишь такое:

[1] + ./script.sh & 

Видишь в конце закорючку &, наталкивает на мысли? 🤒 Команда bg предназначена для возобновления исполнения остановленной задачи в фоновом режиме в командных оболочках. Скрипт продолжил работу в фоне, с того момента где ты его приостановил. Идем во второй терминал с tail и видим, что цифры продолжили заполнять файл. Круто! Но это пока еще не все, если закрыть первый терминал, скрипт прекратит свою работу, нужно его как-то отвязать от текущей сессии и демонизировать. Запускаем финалочку:

disown %1

Команда disown блокирует отправку системного сигнала SIGHUP с помощью командной оболочки и исполняющемуся в фоновом режиме процессу при завершении работы командной оболочки. Теперь в первом терминале пишем exit либо просто закрываем его нахрен. Ха! А во втором терминале работа скрипта продолжается. Магия! Вот таким образом ты можешь легко отвязать уже запущенный скрипт от терминальной сессии и уйти по своим делам, пощелкать впн и т.п. Кстати работает не только со скриптами. Наверное есть еще варианты провернуть подобное. Я показал способ которым пользуюсь сам. Ключевые слова для самостоятельного гугления: bg, fg, jobs, disown, nohup. Да, после того как нажал ctrl+z, можно все откатить назад, запускаешь команду fg и ловишь флешбек. Такие вот дела. Хорошего тебе вторника и не болей! tags: #linux #bash — 💩 @bashdays

Сейчас за кружкой чая, кореш задал вопрос - Ромыч, а расскажи мне, что означает 2>&1? Хм… Нашел время, а так хорошо сидели. Расскажу и тебе, понятно дело, что это магия со стандартными потоками вывода. Как мы знаем, потоки вывода имеют файловые дескрипторы: stdout = 1 (общий поток вывода) stderr = 2 (поток с ошибками) Получается (2>&1) = stderr > stdout. То есть направляем поток с ошибками, в стандартный поток вывода. Ошибки будут выводиться на экран в терминале. Логичным было бы сделать конструкцию: 2>1. Но увы, эта схема отработает другую логическую операцию. Поток с ошибками stderr будет писать все данные в файл, у которого название будет 1. Вот для этого и требуется указать символ & (амперсанд) перед stdout. Это будет интерпретировано как файловый дескриптор, а не обычный файл. А почему тогда не &2>&1. Логично же? Но нет! Символ & интерпретируется как файловый дескриптор только в контексте перенаправления. Операция command &2>&1 анализируется так: command & 2>&1. То есть команда command будет выполнятся в фоновом режиме. А затем начнет выполнятся команда 2 с перенаправлением на стандартный вывод stdout. Вот такие дела. А еще есть альтернатива с оператором |&. |& это сокращенный вариант от 2>&1 | Пример:

script.sh |& tee -a /var/log/script.log

Все что script.sh выведет в потоки stdout и stderr, будет перенаправлено в файл script.log. В официальной документации этот момент хорошо расписан, но я расписал тебе еще проще. Как говорится — мы из рощи, мы попроще! Всё, не смею тебя больше отвлекать, спасибо за внимание. Увидимся скорее всего в понедельник или вторник. Если чо пиши в чатик, мы там завсегда тебе рады! tags: #linux #bash — 💩 @bashdays