Пару недель назад прочитал полезную статью на хабре:

⇨ Бросил tmux и написал свой инструмент

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

Вроде основную задачу по сохранении сессии SSH при разрыве соединения решают и screen, и tmux, но пользоваться ими неудобно. Я последние года стал пользоваться повсеместно tmux вместо screen, но всё равно из-за разных глюков делал это редко и только для долгоиграющих процедур, типа обновления, которые крайне нежелательно прерывать. Во всех остальных случаях я отключал мультиплексор и работал напрямую в консоли. А разделение сессий на одном экране реализовывал с помощью менеджера соединений, а не мультиплексора.

В итоге автор написал небольшую утилиту atch на С, которая работает идеально, если вам нужно просто сохранять сессию при разрыве соединения и потом обратно в неё подключаться. Нет никакой эмуляции терминала, как в screen или tmux. Atch ничего не парсит, не перекодирует, поэтому нет проблем со скролом мышки, пропаданием истории терминала, глюками с OSC-последовательностями.

Работает atch так, как надо, без каких-либо дополнительных настроек. Я попробовал, очень понравилось. В репозитории есть собранный бинарник, его достаточно скачать:

# curl -Lo atch.tgz https://github.com/mobydeck/atch/releases/latest/download/atch-linux-amd64.tgz
# tar -xzf atch-linux-amd64.tgz atch
# mv atch /usr/local/bin/

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

Дальше создаём сессию work:

# atch work

И работаем в ней. Если соединение разорвалось, то подключаемся заново по SSH и заходим в сессию:

# atch work

Видим тут же в терминале всю историю терминала, которая была до отключения!!! Она пишется в ~/.cache/atch/ сразу же в момент вывода. И потом воспроизводится при повторном подключении к сессии. Ничего не теряется. Ты попадаешь в тот же вывод терминала, откуда тебя отключило. Это очень удобно.

Смотрим список сессий:

# atch list

Всё интуитивно и просто. Запоминать команды не нужно. Этого достаточно, чтобы пользоваться, для моих задач. Я после перехода из screen в tmux постоянно вспоминаю, как посмотреть список сессий.

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

# atch start deploy ./deploy.sh

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

Если много работаете в консоли, используете screen или tmux, рекомендую попробовать atch. Вам должно понравиться. Давно мне не попадались утилиты, которые бы так порадовали своей простой и удобством. Казалось бы, уже всё давно придумано, но, как видим, ещё нет.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux #terminal

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

Убеждать никого не хочу, а просто поделюсь некоторыми реальными историями, которые были в моей практике. Сразу поясню, что всё это относится к небольшим инфраструктурам, где с каждым отдельным сервером работают руками. Речь не про кластеры с HA сервисами. Хотя там бы я тоже действовал так же.

1️⃣ У меня была ситуация была, когда сглючила память в сервере и он постоянно перезагружался. Сервер Dell почему-то не отключил её сам, пришлось идти в ЦОДе к серверу и вынимать физически. На сервере работал гипервизор с кучей виртуальных машин. Если бы они автоматом стартовали, то там 100% что-нибудь бы умерло. Он аварийно перезагружался каждые 5-10 минут и сделал это раз 10, пока сотрудник не добрался до ЦОД и не поменял память.

2️⃣ Ещё один пример. ЦОД обесточили, была серьезная авария с электропитанием. Как это обычно бывает, резервное оборудование под реальной нагрузкой никто не проверял, так как подобные отключения бывают крайне редко, а проверять хлопотно. В итоге электричество то появлялось, то пропадало, падал генератор под нагрузкой. Оборудование несколько раз включилось и выключилось.

3️⃣ В промзонах часто отключают электричество. Иногда надолго. Его могут вернуть, а потом опять отключить через 1-2 минуты. Сталкивался с этим десятки раз, так как много работал и работаю с реальным производством. Для меня это вообще обыденность. Стартующие сервера на пустых батареях аварийно падают. Это всё приводит к проблемам. У меня, кстати, и дома, такая же история бывала не раз.

В таких случаях считаю, что лучше перестраховаться и вручную всё запустить в случае аварии, нежели пускать процессы на самотёк. Во всех описанных случаях автозапуск виртуалок никак не помог бы восстановить нормальную работу. А вот организовать дополнительные проблемы - запросто. Лучше 5-10 минут подождать и всё запустить по своей команде, нежели отдать на откуп автоматическому запуску. Разумеется, если есть что-то, что должно сразу стартануть, типа шлюза, то его хочешь, не хочешь, а в автозагрузку придётся поставить. А всё остальное уже потом, когда можно будет удалённо отправить команду на запуск.

#совет

❔Ищете простой и стабильный хостинг для сайта?

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

🔄 На практике такие проблемы часто связаны с качеством хостинга.

Виртуальный хостинг Majordomo обеспечивает стабильную работу сайта и подходит для разных типов проектов: сайтов компаний, блогов, лендингов и интернет-магазинов. Поддерживает популярные CMS — WordPress, 1С-Битрикс, Joomla и другие.

Majordomo входит в топ-10 лучших хостингов России и для эффективной работы вашего бизнеса предлагает:

✅ удобную панель управления;
✅ автоматические бэкапы;
✅ защиту от DDoS;
✅ бесплатные SSL-сертификаты;
✅ поддержку 24/7.

Стоимость — от 179 ₽ в месяц.
❕ При оплате от 3 месяцев домен .RU или .РФ в подарок.

Попробовать бесплатно↖️

Реклама, ООО «Адвлайн», ИНН 7810543400.

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

У strace и её производных (ltrace, latrace) есть ключ -o, через который настраивается вывод результата в файл. При этом вместо файла может выступать pipe, а не обычный файл. Покажу сразу на примере. Тут будет видно явное удобство такого подхода.

Strace много всего умеет и обычно используется при дебаге. Я про него часто упоминал в различных заметках в основном в контексте анализа дисковой активности процессов. Например, какие файлы читает процесс, в какие пишет. Вот сразу реальный и полезный пример с Angie/Nginx.

Если у вас навороченная конфигурация, где куча всего подключается из разных директорий, что бывает часто (привет настройкам Nginx в Bitrixenv), то хочется быстро посмотреть, а что реально из какой-то конкретной директории подключается в момент запуска веб сервера. Проще всего это сделать, анализируя активность процесса во время выполнения команды nginx -t. В этот момент конфигурация проверяется на ошибки, соответственно, она должна быть прочитана.

Можно просто посмотреть все системные вызовы openat, которые отвечают за чтение:

# strace -zf -e trace=openat nginx -t

В выводе будет много всего лишнего - библиотеки, логи, системные файлы и т.д. Можно попробовать грепнуть:

# strace -zf -e trace=openat nginx -t | grep /etc/nginx

У вас, кстати, ничего не получится. Это особенность nginx, про которую просто надо знать. Вывод этой команды улетает не в стандартный поток stdout, а в stderr. Не знаю, почему так, но в Nginx это исторически сложилось. А grep не грепает stderr. Вам нужно будет как минимум сделать вот так:

# strace -zf -e trace=openat nginx -t 2>&1 | grep /etc/nginx

То есть направить поток stderr в stdout. Тогда он грепнется. Но вывод всё равно будет не очень красивый и наглядный. И тут можно использовать вот такой трюк:

# strace -o "| grep -Eo '/etc/nginx/[^\"]+'" -zf -e trace=openat nginx -t
/etc/nginx/nginx.conf
/etc/nginx/modules-enabled
/etc/nginx/mime.types
/etc/nginx/conf.d
/etc/nginx/sites-enabled
/etc/nginx/sites-enabled/default

На выходе получили аккуратный обработанный список директорий и файлов в /etc/nginx, которые веб сервер прочитал. Смысл того, что мы сделали в том, что через ключ -o вывод отправили не в файл, а в пайп, где он сразу же был обработан тем же grep, который вывел только то, что было между " ", а это как раз путь в файловой системе. Вся остальная информация не нужна и только мешает.

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

# strace -zf -e trace=openat nginx -t 2>&1 | grep -Eo '/etc/nginx/[^\"]+'

Тут обязательно перенаправление 2>&1.

Подобная обработка вывода через pipe актуальна для анализа каких-то интерактивных программ. Например, iftop:

# strace -o "| grep -Eo '/[^\"]+'" -zf -e trace=openat iftop

Запускаем и сразу закрываем iftop. В консоли видим список файлов, которые она прочитала. В данном случае команда:

# strace -zf -e trace=openat iftop | grep -Eo '/[^\"]+'

уже не сработает. До grep дело не дойдёт, так как сначала вывалится портянка strace, а потом запустится iftop. В первом случае мы сразу же обрабатываем вывод в strace, выводим его в консоль и потом запускается iftop.

Можно посмотреть, где живёт конфигурация mc, запущенная под рутом:

# strace -o "| grep -Eo '/root[^\"]+'" -zf -e trace=openat mc
/root/.config/mc/ini
/root/.bash_history

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#bash #linux #terminal

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

Во всём мире раскручивается спираль инфляции, в том числе долларовой, про рубль и говорить не приходится. Мы это всё наблюдаем постоянно, да ещё и с ускорением в последние несколько лет. Так что вопрос индексации и увеличения зарплаты стоит остро. Мои советы:

1️⃣ Когда устраиваетесь на новую работу, сразу, либо на собеседовании, либо при успешном приёме, оговорите тему повышения или индексации зарплаты. Как это происходит: автоматически раз в год или нужно самому к кому-то обращаться на пересмотр, какие процедуры на этот счёт. Если обсудите всё в самом начале, потом проще будет вести такие разговоры. Просто сошлётесь на эти договорённости. Это такая база, которую в обязательном порядке надо обсуждать. Она существенно упростит хотя бы в моральном плане задачу, если вам тяжело вывозить такие разговоры.

2️⃣ Постоянно отслеживайте среднюю зарплату по отрасли и следите за набором наиболее востребованных навыков. Подтягивайте их хотя бы минимально, если на работе не используете какой-то популярный стек. Проще всего подписаться на рассылку вакансий в hh, настроив подходящие параметры.

3️⃣ Если видите, что ваша зарплата упала ниже рынка, выходите на разговор с руководством, которое отвечает за индексацию и пересмотр зарплат. Не тяните, не копите обиду, не начинайте искать новое место, если на текущем устраивает всё, кроме зарплаты. Чаще всего нормальному руководителю нет смысла терять хорошего для себя сотрудника (вы же хороший сотрудник?). Спокойно объясните, почему вы считаете, что вам пора поднять зарплату. У вас должны быть чёткие аргументы, а не только желание получать больше денег.

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

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

❗️И ещё важно понимать. Компенсация инфляции - это не повышение зарплаты. Некоторые руководители преподносят индексацию, как повышение и увеличивают требования, нагрузку. Надо спокойно пояснить, если просите именно индексацию, что речь про повышение не идёт. Они сами это понимают, просто используют такую манипуляцию.

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

☝️ Только действуйте аккуратно и оценивайте трезво свои шансы и возможности если что найти другую работу. Сейчас с этим могут быть проблемы. Я бы в такой истории не блефовал.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#совет

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились.

⇨ Автоматические TLS-сертификаты в Angie с модулем ACME
Очень подробно разобрана тема работы встроенного клиента ACME в веб сервере Angie. Он давно уже умеет сам получать и регулярно обновлять бесплатные сертификаты. Делал об этом заметку.

⇨ Chrome DevTools: полный разбор для ускорения сайтов
Очень подробный разбор DevTools в контексте анализа быстродействия и загрузки сайта. Нигде ранее не встречал такой подробной информации на эту тему. Если для вас актуальна история с быстродействием сайтов, то обязательно посмотрите. Автор очень хорошо разбирается в этой теме.

⇨ What’s Actually Running in My Homelab? (50+ Self-Hosted Services)
Очень любопытное видео от популярного блогера на тему того, что он использует. Я давно его смотрю и в целом всё это уже видел. Там по идее стандартный набор: Proxmox, TrueNAS, Traefik, Pi-hole, Prometheus, Uptime Kuma, n8n, NetbootXYZ и т.д. Практически всё из его списка было в то или иное время у меня на канале.

⇨ Cloud-init - развертывание виртуальных машин за секунды. Автоматизация Proxmox
Хорошая инструкция по настройки Cloud-init для автоматизации запуска виртуалок в Proxmox.

⇨ Защищаем приложения на своем сервере - безопасность Homelab и VPS
Хорошее наглядное видео, где автор специально сделал уязвимое приложение и на его примере показывает работу WAF (Web Application Firewall), а конкретно SafeLine.

⇨ Инструменты, которые незаметно обеспечивают работу моей домашней лаборатории Proxmox в 2026 году.
Автор пишет про некоторые программы под Proxmox, которые он использует. Среди них PegaProx и ProxCenter, про которые я вообще впервые услышал. Надо будет попробовать. А помимо них там речь идёт про Netdata, Pulse, ProxMenuX.

⇨ MCP Inspector | Протокол MCP - 02
⇨ Структура протокола MCP | Протокол MCP - 03
Продолжение нового курса от известного преподавателя Созыкина Андрея по теме MCP - протокола для взаимодействия с языковыми моделями (LLM).

⇨ Сервисы заметок для самохостинга. Альтенративы Google Keep
Очередное видео на тему хостинга текстовых заметок на своём сервере. Не знаю, остались ли ещё люди, у которых таких сервисов нет? 😁 На них постоянно выходят обзоры и сравнения. Автор основательно подошёл к теме и даже сравнительную таблицу составил. Если кому интересно, то сам я уже несколько лет использую Joplin.

⇨ Uptime Kuma v2 is HERE // Breaking Changes & Safe Upgrade Checklist
Популярный бесплатный мониторинг Uptime Kuma обновился до новой версии v2, где много изменений по сравнению с первой версией. Надо будет тоже её попробовать.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#видео