​​Заметка для тех кому приходится разбираться на чужих серверах или перенимать полностью управление в свои руки. Для deb дистрибутивов есть инструмент debsums, живёт в базовых репах:

# apt install debsums

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

А вот проверить конкретно изменения в стандартных конфигурационных файлах бывает очень полезно. Например, если кто-то изменял стандартный конфиг /etc/ssh/ssh_config или /etc/default/ssh, то вы это увидите:

# debsums --config --changed
/etc/ssh/ssh_config
/etc/default/ssh

И так для всех стандартных конфигов, которые идут в составе пакетов, в том числе которые устанавливаются с базовой системой. Юниты systemd, конфиги в /etc/pam.d, /etc/grub.d, /etc/defaults и т.д. Всё будет проверяться.

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

#debian

​​Я по привычке всегда создаю ключи для SSH с использованием протокола RSA. Просто добавляю параметр для длины ключа 4096. Когда-то увидел информацию, что меньшая длина теоретически может быть небезопасной.

# ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)_$(date -I)"

OpenSSH сервер в очередном обновлении отказался от коротких RSA ключей: "Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.". А не так давно от него было предупреждение: "use RSA/SHA256 when testing usability of private keys as some systems are starting to disable RSA/SHA1 in libcrypto." Это всё информация из releasenotes.

Криптография не стоит на месте и постоянно развивается. Появился протокол Ed25519, который сейчас многие сервисы рекомендую использовать для SSH ключей, а если видят RSA, то выводят предупреждение. Не вижу причин его не использовать. Надо менять привычки.

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

# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"

# cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisnjwAAAKCDHZihgx2YoQAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisxjwAAAECp2CJm9zWAsi9TQ/T92h6maR7CkeZyXlR1EOC9IecDvCFB44opd6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGPAAAAGHJvb3RAZGViaWFuMTFfMjAyMy0xMi0yMAECAwQF
-----END OPENSSH PRIVATE KEY-----

# cat id_ed25519.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICFB44opv6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGP root@debian11_2023-12-20

Публичные ключи Ed заметно короче RSA, что банально практичнее. Они содержат всего 68 символов, в отличие от RSA 3072 с их длиной 544 символа.

Кто-то уже перешёл на Ed25519? Там нет каких-то подводных камней, в виде отсутствия поддержки в каком-то софте? По идее, такого уже не должно быть, так как алгоритм появился довольно давно. Хотя какой тут софт может быть? Подавляющее число подключений по SSH, это подключения к openssh серверу, который с 15-го года поддерживает Ed25519. Наиболее вероятно, что проблемы могут возникнуть на каком-то старом сетевом оборудовании, где версия openssh очень старая.

#ssh

​​Zabbix последнее время не сильно радует новостями или какими-то событиями. Как-будто у компании проблемы. Раньше регулярно были рассылки с множеством событий: обновления, статьи в блоге, ролики в ютубе, новые шаблоны, вебинары и т.д.

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

✔️ Рассказывают, что реализовали возможность передавать параметры к скриптам прямо из веб интерфейса. Если я правильно понял, то можно добавить какой-то скрипт, к примеру, для перезапуска службы. В случае необходимости, можно через веб интерфейс к нему обратиться и передать что-то в качестве параметра. Например, адрес сервера и/или имя службы. И скрипт выполнит перезапуск на целевом сервере. Подробного описания нет. Свою интерпретацию сделал на основе вот этих строк: "The latest alpha release introduces the ability to pass custom input to frontend scripts, enabling many new host administration scenarios directly from the Zabbix frontend." и картинки, что будет в конце публикации.

✔️ Посмотрел список остальных нововведений. Понравился новый тип проверки net.dns.perf. С его помощью можно проверять DNS записи. Это полезная штука, так как зачастую изменение записей может обрушить всю систему. За этим важно следить.

✔️ Ещё из полезного - добавили возможность пушить метрики через Zabbix API. Раньше для этого можно было только zabbix_sender использовать. Теперь можно без него обойтись. Это позволит быстро и просто передавать метрики из других систем через их вебхуки. В будущем обещают виджет на дашборд для ввода метрик вручную. Это, кстати, было бы полезно. Сейчас нет простых способов передать вручную в айтем значение.
▶️ Zabbix 7.0 - History Push API Feature
В видео в том числе можно увидеть новый интерфейс в Zabbix 7.0. Всё левое меню существенно изменилось.

✅ Также вышла новая версия Zabbix Server 6.0.25, в которой наконец-то исправили баг, когда не работали веб проверки сайтов в кодировке, отличной от utf8. В комментариях кто-то писал, что тоже заметил эту проблему. Так вот теперь её исправили. У меня наконец-то заработали проверки старых сайтов в кодировке Windows-1251. Раньше Битрикс по умолчанию в ней устанавливался и до сих пор успешно работает и обновляется с этой кодировкой.

У Zabbix изменились сроки поддержки не LTS версий, то есть версий X.2 и X.4. Теперь это будет 6 месяцев полной поддержки и 6 месяцев исправлений критичных багов и проблем с безопасностью. То есть поддержка будет 1 год со времени выхода нового релиза. Напомню, что у LTS версии поддержка 5 лет. Я обычно на LTS версиях сижу. Редко обновляю на промежуточные релизы. Только если интересно потестить какие-то нововведения.
⇨ Zabbix Life Cycle and Release Policy.

Ждём версию 7.0. Пока что только alpha, потом ещё несколько месяцев будут beta выходить. К весне, наверное, зарелизятся.

#zabbix

​​Не так давно я рассказывал про простую и надёжную систему для бэкапов - rdiff-backup на базе rsync. Система хорошая, сам её использовал. Один из читателей поделился информацией про продукт Minarca. Это клиент-серверное приложение с веб интерфейсом на основе rdiff-backup. Я его установил и немного потетисровал. Понравилась идея и реализация.

Установить сервер очень просто. Для DEB дистрибутивов есть репозитории. На Debian ставим так:

# curl -L https://www.ikus-soft.com/archive/minarca/public.key | gpg --dearmor > /usr/share/keyrings/minarca-keyring.gpg
# echo "deb [arch=amd64 signed-by=/usr/share/keyrings/minarca-keyring.gpg] https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/minarca.list
# apt update
# apt install minarca-server

И всё, можно идти в веб интерфейс на порт 8080. Учётка по умолчанию: admin / admin123.

Для того, чтобы что-то забэкапить, надо скачать и установить агента. Есть версия под Windows, Linux, MacOS. Можно всех бэкапить под одной учёткой, либо под разными. Дальше будет понятно, в чём отличие. Устанавливаем клиента, указываем адрес сервера, логин, пароль.

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

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

Каких-то особенных возможностей нет, но в базе по бэкапам есть всё необходимое. При желании, можно настроить 2FA и спрятать сервис за прокси. Отмечу ещё раз, что под капотом там rdiff-backup, соответственно, все возможности по хранению там те же: бэкап только на уровне файлов, дедупликации, бэкапа дисков и всей системы нет. Хранятся инкрементные бэкапы в экономичном формате с помощью линуксовых hard links. Репозитроий для хранения - обычная директория Linux на сервере. По умолчанию - /backups.

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

⇨ Сайт / Исходники / Demo / Видеообзор

#backup

Бодрое видео на тему того, почему Linux лучше Windows:

▶️ Why I use Linux

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

А вот прикол с touch CON и ls CON не понял. Кто-то может пояснить, к чему это было?

#юмор

Я уже не раз делал заметки про Gitea - легковесную open source систему для управления git репозиториями. Изначально это был просто веб интерфейс для git, который можно было сделать с помощью соответствующей темы очень похожей на github. Написана Gitea на Go и по своей сути это просто бинарник, поэтому с установкой и настройкой никаких проблем. Бонусом гошечки идёт очень быстрая работа и отзывчивость веб интерфейса.

Как я уже сказал, Gitea была создана просто для работы с кодом, без какой-либо автоматизации. Для построения конвейера для сборки, деплоя и хранения образов я предлагал связку: Gitea + Drone CI + Docker Registry.

С недавних пор в Gitea завезли Gitea Actions, которые полностью совместимы с GitHub Actions. То есть она превратилась в полноценную CI/CD систему с собственным Package Registry и Gitea Runner. Получился аналог gitlab на минималках.

Подробно посмотреть обзор всех этих возможностей, а также инструкцию по настройке, можно в серии из двух видеороликов:
▶️ Gitea-01: домашний github (+ actions)
▶️ Gitea-02: домашний github (+ actions)

#git #devops #cicd

​​Я делал несколько заметок на тему systemd, где встроенные возможности этой системы управления службами заменяют функциональность других линуксовых программ и утилит:

◽Systemd timers как замена Cron
◽Journald как замена Syslog
◽Systemd-journal-remote - централизованное хранение логов
◽Systemd-journal-gatewayd - просмотр логов через браузер
◽Systemd-mount для монтирования дисков
◽Есть ещё timesyncd как замена ntp или chrony.

Сегодня расскажу про ещё одну такую службу, которая заменяет локальный кэширующий DNS сервер - systemd-resolved. Изначально я научился настраивать DNS сервер Bind ещё в те времена, когда было привычным делом держать свою зону на своих серверах. Везде использовал его, даже в простых случаях, где нужно простое кэширование без поддержки своих зон. Потом познакомился с Dnsmasq и для обычного кэширования стал использовать его, так как настроить быстрее и проще. На пути к упрощению решил попробовать systemd-resolved. Он выступает в роли локального кэширующего сервера, то есть обрабатывает только запросы сервера, где он установлен, и его приложений.

В каких-то дистрибутивах systemd-resolved может быть в составе systemd. В Debian 12 это не так, поэтому придётся поставить отдельно:

# apt install systemd-resolved

Далее открываем конфиг /etc/systemd/resolved.conf и приводим его примерно к такому виду:

[Resolve]
DNS=77.88.8.1 1.1.1.1 8.8.8.8
FallbackDNS=77.88.8.8 8.8.4.4
Cache=yes

Это минимальный набор настроек для локального кэширующего сервера. Сервера из списка FallbackDNS будут использоваться в случае недоступности основного списка.

Перезапускаем службу:

# systemctl restart systemd-resolved

После установки systemd-resolved удаляет /etc/resolv.conf и заменяет ссылкой на /run/systemd/resolve/stub-resolv.conf. Проверить работу службы можно разными способами. Например так:

# resolvectl query ya.ru

или так:

# dig @127.0.0.54 ya.ru

То есть локальный DNS сервис имеет адрес 127.0.0.54. Он же и указан в виде nameserver 127.0.0.53 в resolv.conf.

Посмотреть статус службы можно так:

# resolvectl status

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

# systemctl edit systemd-resolved

Добавляем параметр:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Перезапускаем службу и смотрим логи:

# systemctl restart systemd-resolved
# journalctl -f -u systemd-resolved

Если ответа нет в кэше, то вы увидите информацию о том, что был запрос к публичному DNS серверу. Если в кэше есть запись об этом домене, то увидите строку:

Positive cache hit for example.com IN A

Посмотреть статистику по запросам:

# resolvectl statistics

Очистить локальный кэш:

# resolvectl flush-caches

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

#systemd #dns

Один читатель рассказал про свой репозиторий на github:

⇨ https://github.com/Lifailon

Там очень много всего написано за много лет продуктивной деятельности. Автор захотел поделиться с аудиторией. Может кому-то будет полезно. Человек занимался в основном администрированием на Windows, поэтому большая часть работ на PowerShell, но не только.

Я посмотрел репу и сразу честно сказал, что это лютые костыли, которые решали конкретные задачи на конкретном рабочем месте, поэтому слабо применимы для широкой аудитории. Тем не менее, некоторые полезные вещи я увидел и для себя:

▪ Windows-User-Sessions - шаблон и скрипты к Zabbix для мониторинга за терминальными сессиями на сервере.

▪ ACL-Backup - небольшой скрипт с формой ввода, который позволяет сделать полный backup списка прав доступа (ACL) файловой системы NTFS в txt-файл с возможностью восстановления из этого списка. Я тоже писал и использовал скрипты для решения этой же задачи. Когда бэкаплю виндовые шары, записываю на них же списки прав доступа, чтобы можно было восстановить, если что-то пойдёт не так.

▪ PS-Commands - описание с примерами PowerShell cmdlets на русском языке.

▪ Remote Shadow Administrator - практически полноценная программа на PowerShell для управления терминальными серверами и подключения к текущим RDP-сессиям с помощью Shadow-подключения. Написана только с помощью PowerShell и Windows Forms. Если управляете терминальниками, то может быть очень полезным.

В репозитории ещё много всего необычного. Посмотрите, может найдёте что-то полезное для себя.

#windows

Много раз писал про различные возможности SSH на сервере, в том числе для использования в роли jumphost. Да и сам нередко использовал эту возможность. При этом либо в 2 этапа подключался к требуемому хосту, то есть вручную - сначала на jumphost, потом уже на целевой. Либо запускал команду на подключение к целевому хосту внутри команды на подключение к jumphost:

# ssh -t user@jumphost "ssh user@server01"

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

Мимо моего внимания прошла возможность ssh напрямую подключаться со своего хоста на server01 через jumphost. То есть это выглядит вот так:

# ssh -J user@jumphost:22 user@server01

Для этого даже отдельный ключ есть -J. Это принципиально другой тип подключения, так как при этом пробрасывается TCP порт через jumphost. Подключение происходит напрямую с твоей машины. Ключ, соответственно, проверяется только у тебя.

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

📌 Ссылки по теме:
▪ Логирование ssh активности с помощью: Tlog, snoopy, log-user-session, PROMPT_COMMAND
▪ Уведомления в Telegram о ssh сессиях
▪ Переадресация портов через ssh
▪ VPN туннели с помощью ssh
▪ Ограничение на выполнение команд по ssh
▪ Псевдографическое меню для jumphost
▪ Поддержание постоянного ssh соединения с помощью Autossh

#ssh

Есть куча публичных сервисов по определению твоего внешнего ip адреса, в том числе через консоль. Например, ifconfig.co или ifconfig.me/ip.

Если вам постоянно нужна такая функциональность для каких-то своих проверок, то разумнее всего поднять свой сервис. Сделать это проще простого с помощью Nginx или Angie. Просто добавьте на любой виртуальный хост location:

location /ip { default_type text/plain; return 200 $remote_addr; }

И всё, больше ничего не надо. Можете хоть браузером, хоть консолью смотреть свой ip. Если запросы на ip адрес сервера не закрыты, то добавив location в стандартный виртуальный хост default.conf, смотреть свой ip можно так:

Bash:
# curl https://1.2.3.4/ip

Powershell:
> Invoke-RestMethod https://1.2.3.4/ip

#сервис

​​Существует довольно старая система мониторинга под названием Sensu. Ей лет 10 точно есть. Изначально она была написана на Ruby. На этом же языке писались и самостоятельные проверки, дополнения и т.д. Судя по всему в какой-то момент разработчики поняли, что это не самая удачная реализация и переписали всё на Go, а язык для проверок реализовали на JavaScript.

По сути сейчас это новая система мониторинга, полностью заточенная на реализацию подхода IaC в виде его уточнения - Monitoring-as-Code. Я изучил сайт, посмотрел возможности, обзорное видео, инструкцию по разворачиванию. Выглядит современно и удобно. Сами они себя позиционируют как инструмент для DevOps и SRE команд. При этом я вообще нигде и никогда не видел упоминание про этот мониторинг ни в современных статьях, ни где-то в выступлениях на тему мониторинга.

Базовый продукт open source. То есть можно спокойно развернуть у себя. Sensu состоит из следующих компонентов:

◽Sensu Backend - основной компонент, который собирает, обрабатывает и хранит данные.
◽Sensu API - интерфейс для взаимодействия с бэкендом.
◽Sensuctl - CLI интерфейс для взаимодействия с бэкендом через API.
◽Sensu Agent - агенты, которые устанавливаются на конечные хосты для сбора и отправки данных.

Из архитектуры понятно, что это агентский мониторинг. Реализован он немного необычно, с акцентом на простоту и скорость разворачивания агентов. Все правила по сбору метрик вы настраиваете на сервере. Каждое правило - отдельный yaml файл. Когда вы разворачиваете агент, указываете только url апишки и набор подписок на сервере. Всё, на агенте больше ничего настраивать не надо.

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

# sensuctl create -f metric-storage/influxdb.yaml
# sensuctl create -f alert/slack.yaml
# sensuctl create -r -f system/linux/cpu

Создали конфигурацию хранилища, добавили оповещения и метрику для сбора информации о нагрузке на cpu. Теперь настройки этой метрики можно опубликовать, а агенты на неё подпишутся и будут отправлять данные. После каждой выполненной команды будет создан соответствующий yaml файл, где можно будет настроить параметры. Sensu поддерживает namespaces для разделения доступа на большой системе. Примерно так, как это реализовано в Kubernetes. Sensu вообще в плане организации работы сильно похожа на кубер.

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

Сам сервер Sensu под Linux. Есть как deb и rpm пакеты, так и Docker контейнер. Агенты тоже есть под все Linux, а также под Windows. У Sensu много готовых интеграций и плагинов. К примеру, он умеет забирать метрики с экспортеров Prometheus или плагинов Nagios. Может складывать данные в Elasticsearch, InfluxDB, TimescaleDB. Имеет интеграцию с Grafana.

В комплекте c бэкендом есть свой веб интерфейс, где можно наблюдать состояние всей системы. Всё, что вы создали через CLI и Yaml файлы, а также все агенты будут там видны.

По описанию и возможностям система выглядит очень привлекательно. Разработчики заявляют, что она покрывает всё, от baremetal до кластеров Kubernetes. Мне не совсем понятна её малая распространённость и известность. Может это особенность русскоязычной среды. Я вообще ничего не знаю и не слышал про этот мониторинг. Если кто-то использовал его, поделитесь информацией на этот счёт.

⇨ Сайт / Исходники / Видеообзор

#мониторинг

​​Пересчёт олдов. На днях искал в поиске что-то и на 3-м месте в выдаче выскочил сайт lissyara.su со статьей то ли 2007, то ли 2008 года. Я очень удивился, что такая старая информация всплывает в поиске. Ну а заодно и поностальгировал.

Этот сайт я очень активно изучал и использовал, когда начинал свой путь админом FreeBSD. Тогда ещё особо не была распространена должность Администратор Linux, потому что FreeBSD была распространена сильнее. Да и в целом не было явного разделения на администраторов различных систем.

Когда я принял решение, что помимо Windows надо изучать что-то ещё, узнал, что бОльшая часть серверов Яндекса на FreeBSD, поэтому решил, что стоит изучать эту систему. Ну и стал на работе и дома настраивать и разбираться. Сначала со шлюзом ковырялся, потом с веб сервером, потом с почтовым. В принципе, все азы современного Linux я получил тогда на FreeBSD. Настройка на самом деле не сильно отличается. Сейчас спокойно мог бы вернуться на FreeBSD без каких-то проблем.

Читая статьи на lissyara.su, я думал, какой нужен мозг, чтобы во всём этом разбираться и писать статьи. Причём авторы там так походя всё упоминали. Типа искал такой-то инструмент, нашёл его в портах (аналог базового репозитория linux), почитал описание, настроил, написал статью. А оказалось это дело техники. Поднабрался опыта и стал делать так же.

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

Вообще, у меня небольшая мечта есть. Когда появится свободное время и не будет необходимости всё время бежать вперёд, настроить всю свою инфру на FreeBSD. Её наверное сейчас уже и не ломают, и уязвимости не ищут ввиду малой распространённости. В экзотику выродилась. Я уже лет 6-7 её в проде ни у кого не видел.

#freebsd

​​Нечасто бывает так, что пишешь о чём-то, что тебе реально понравилось. В этот раз будет именно такая заметка. Речь пойдёт о новом для меня менеджере SSH соединений - XPipe. Раньше о нём не слышал, что неудивительно, так как появился он в 2023 году. Не скажу, что это прям что-то такое, что вау, но лично мне нравится разбираться и изучать программы, с которыми взаимодействуешь каждый день. Иногда такое нововведение существенно изменяет качество ежедневной рутины в лучшую сторону.

Как я уже сказал, программа в целом мне понравилась, хотя иногда в ней что-то подглючивало и она подвисала. Провозился с ней пару часов. Изучал возможности, смотрел обзор, пробовал пользоваться. Настроил в ней соединения к своим серверам. Буду пользоваться и изучать. Программа кроссплатформенная, потому что на Java (слышу вздохи разочарования). Есть под Windows, Linux, MacOS.

Далее по порядку обо всём расскажу.

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

🟢 Интеграция с Windows Shell. Все соединения открываются во вкладках стандартного виндового терминала. Мне нравится его внешний вид и поведение, так что для меня это плюс. Во многих других программах отталкивает именно терминал.

🟢 В отдельной вкладке программы можно открыть обзор файлов удалённого сервера, а сами файлы, соответственно, сразу открывать в VSCode. Не нужны никакие сторонние scp клиенты. На практике это удобно, особенно для контейнеров, которые XPipe автоматически находит на хосте и добавляет для каждого из них отдельное подключение.

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

🟢 Можно напрямую подключаться к СУБД, к Docker контейнерам, к локальным экземплярам WSL.

🟢 Есть встроенная поддержка jumphost и SSH подключений через него. Настраиваете соединение к jumphost, а в остальных подключениях указываете его в качестве шлюза.

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

🟢 Есть портабельные версии программы, что удобно для переносимости между рабочими машинами.

🟢 Есть мастер пароль для шифрования всей чувствительной информации о соединениях.

🟢 Умеет хранить и синхронизировать своё состояние через git репозиторий.

Базовая программа бесплатная без каких-либо ограничений. Более того, она open source. За деньги продаются отдельные плюшки в виде интеграции с коммерческими системами, такими как Google Kubernetes Engine, Red Hat OpenShift, Docker Enterprise и т.д. Полный список тут. В него же входят и коммерческие ОС Linux, с точки зрения разработчиков, а это Amazon Linux, RHEL, SUSE Enterprise Linux, Oracle Linux (!) и другие.

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

Если кто-то ещё не знает, чем пользуюсь я сам, хотя писал об этом много раз, то повторю. Для SSH соединений использую очень старую бесплатную версию xShell 5, а для RDP - mRemoteNG. Последняя тоже очень старая, так как в новых версиях ничего существенно по возможностям не добавили, но работает она медленнее.

⇨ Сайт / Исходники / Видеообзор

#менеджеры_подключений

​​Часто слышал выражение, что трафик отправляют в blackhole. Обычно это делает провайдер, когда вас ддосят. Вас просто отключают, отбрасывая весь адресованный вам трафик. А что за сущность такая blackhole, я не знал. Решил узнать, заодно и вам рассказать.

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

# ip route add blackhole 1.2.3.4

Проверяем:

# ip r | grep blackhole
blackhole 1.2.3.4

Все пакеты с маршрутом до 1.2.3.4 будут удалены с причиной No route to host. На практике на своём сервере кого-то отправлять в blackhole большого смысла нет. Если я правильно понимаю, это провайдеры отправляют в blackhole весь трафик, адресованный какому-то хосту, которого ддосят. Таким образом они разгружают своё оборудование. И это более эффективно и просто, чем что-то делать на файрволе.

Если я правильно понимаю, подобные маршруты где-то у себя имеет смысл использовать, чтобы гарантированно отсечь какой-то исходящий трафик в случае динамических маршрутов. Например, у вас есть какой-то трафик по vpn, который должен уходить строго по определённому маршруту. Если этого маршрута не будет, то трафик не должен никуда идти. В таком случае делаете blackhole маршрут с максимальной дистанцией, а легитимные маршруты с дистанцией меньше. В итоге если легитимного маршрута не будет, весь трафик пойдёт в blackhole. Таким образом можно подстраховывать себя от ошибок в файрволе.

#network

🔝 В этот раз ТОП постов за месяц выйдет немного пораньше, потому что завтра будет ещё топ за год.

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

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

Отдельно отмечу цикл моих заметок про спину. Всё, что я там описал, реально работает. Своё состояние улучшил значительно. Можно сказать, что функционально вернулся в состояние среднестатистического здорового человека буквально за пару месяцев. Как минимум, ничего уже не болит. Разобрался в причинах проблем, в лечении, в профилактике. Кто не читал, но имеет проблемы с опорно-двигательным аппаратом, крайне рекомендую ознакомиться (хэштег #спина).

📌 Больше всего просмотров:
◽️Подборка бесплатных обучающих материалов (10373)
◽️Сервис по слежению за torrent раздачами (10195)
◽️Обучающие материалы по сетям (9497)

📌 Больше всего комментариев:
◽️Заметка про детей (305)
◽️Заметка про выбор пути, чтобы войти в IT (141)
◽️Домашняя серверная блоггера Techno Tim (132)

📌 Больше всего пересылок:
◽️Подборка обучающих материалов (1192)
◽️Обучающие материалы по сетям (512)
◽️Сервис по слежению за torrent раздачами (368)
◽️Программа LocalSend для передачи файлов (366)

📌 Больше всего реакций:
◽️Заметка про детей (518)
◽️Моя история про боли в спине (310)
◽️Отладка bash скриптов с помощью set -x (212)

#топ

​​▶️ Канал DevOps Channel перед праздниками опубликовал все выступления с прошедшей в марте 2023 года конференции DevOpsConf. Это чтобы нам не скучно было на выходных. Я аж устал список записей просматривать. Там очень много всего и на разные темы.

Я часто смотрю записи с подобных мероприятий и могу сразу сказать, что практической пользы для подавляющего числа слушателей там нет. Лично мне просто нравится это слушать как развлекательное видео. А если ещё и полезное что-то узнаю, то вдвойне хорошо. Как минимум, расширяется кругозор. Так что я включаю в фоне во время прогулок или когда на машине куда-то еду.

Добавил себе на просмотр следующие выступления:

🔹Топ некритичных ошибок в инфраструктуре, приводящих к критичным проблемам
▪ Как перестать быть YAML-разработчиком. Переходи на сторону CUE
🔹TechTalk "Выбор CI/CD-системы"
▪ Vault — интеграция куда угодно
🔹Гид автостопщика по HashiCorp Vault
▪ Как управлять базой знаний и не сойти с ума
🔹Мимо тёщиного дома я без метрик не хожу
▪ Ваши админы за 10 лет так и не смогли стать девопсами. Разработчики смогли
🔹Хочешь расти в DevOps, но не знаешь как? Приходи, расскажу!
▪ DevOps — путь на социальное дно, или Пробиваем дно DevOps-колодца
🔹Практика применения DevOps-аутсорса на разных этапах жизненного цикла продукта

#видео

​​🎄🔝 Под конец года имеет смысл подвести некоторые итоги. В повседневной жизни я не привык это делать. Обычно только доходы/расходы анализирую. А вот в разрезе канала было интересно посмотреть итоги.

Я подготовил ТОП публикаций за прошедший год. Это было трудоёмко сделать, потратил много времени. Надеюсь, вам это будет интересно и полезно. Мне было любопытно почитать, что я там за год написал. Материала подготовлена уйма. Всё собственноручно, без какой-либо помощи или заимствования. Конечно, список получился с перекосом - чем старше материал, тем выше у него метрики. Что-то осеннее со временем запросто может обогнать весеннее. Но как есть.

🙏🏻 Хочу поблагодарить всех читателей за активность и внимание к моему каналу. Без вас ничего бы не было. Хочется думать, что это взаимовыгодное сотрудничество. Я внимательно и ответственно готовлю материалы, переживаю за качество, вы терпеливо и деятельно смотрите рекламу 😀 У меня много отзывов (все сохраняю) от рекламодателей на тему того, что у меня очень лояльная и отзывчивая аудитория. Это позволяет мне фокусироваться на контенте и не тратить время на поиск рекламодателей. Они находят канал сами и потом остаются на постоянное сотрудничество.

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

4 года назад поставил себе цель — развить этот канал, создавая по 2 материала в день. С тех пор так и придерживаюсь этого. Упорство и ежедневный труд всегда дают результат, чем бы вы ни занимались: работой, хобби, обучением, воспитанием, саморазвитием и т.д. Желаю вам эффективно потрудиться в новом году над саморазвитием и достижением своих целей.

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

📌 Больше всего пересылок:
◽️Подборка бесплатных обучающих материалов (1236)
◽️Сисадмин предприятия получил условный срок (931)
◽️Система видеонаблюдения Insentry (919)
◽️Панель управления VPN сервером Hiddify (794)
◽️Скрипт topdiskconsumer (749)
◽️Примеры использования lsof (689)
◽️Связка R-Studio и HDDSuperClone (643)
◽️Подборка youtube каналов по ИТ (635)
◽️Подборка на тему консольных утилит и команд (609)
◽️Проект по безопасности workbench.cisecurity.org (593)

📌 Больше всего комментариев:
◽️Замена бесплатной почты для домена от Яндекс (381)
◽️Использование сборок Windows (322)
◽️Заметка про детей (321)
◽️Пробивка публичной инфы при приёме на работу (256)
◽️Новый Mikrotik L009UiGS-2HaxD-IN (239)
◽️Проблемы со спиной при сидячей работе (209)
◽️Информация по вакансиям в IT (199)
◽️OPNsense vs pfSense (168)
◽️Мифы про Astra Linux (154)
◽️Заметка про выбор пути, чтобы войти в IT (141)

📌 Больше всего реакций:
◽️Заметка про детей (521)
◽️Заметка про продуктивность с личными примерами (346)
◽️Мои мысли на тему подбора работы (312)
◽️Моя история про боли в спине (311)
◽️Заморозка списка процессов в диспетчере задач (293)
◽️Прикольный мем про Linux (268)
◽️Инфантильность в IT (264)
◽️Где и как я работал (257)
◽️Заметка про сон и ранний подъём (243)
◽️Мем с собакой и дропом таблицы (240)

📌 Больше всего просмотров:
◽️Сисадмин предприятия получил условный срок (31221)
◽️Обход блокировки бесплатной версии Anydesk (12907)
◽️Мемчик с блатным шансоном для админа (12896)
◽️Случай на конференции с iftop (12447)
◽️Мем про бэкап Шрёдингера (12159)
◽️Прикольный мем про Linux (11940)
◽️Заметка про ownCloud Infinite Scale 4.0 (11687)
◽️Утилита CFSSL для управления собственным CA (11682)
◽️Шутка про Kubernetes (11410)
◽️Песни группы the CI/CD band (11199)

#топ

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

Сторонним разработчикам, нанятым незадолго до НГ, нужна была копия сайта для разработки. Пока с ними договаривались (не я), обсуждали детали, наметили план, наступило 28-е, четверг. В пятницу я уже не успел ничего сделать и благоразумно отложил решение всех вопросов на рабочие дни после праздников, так как не предполагал, что в праздники кто-то будет что-то делать. Но разработчики очень попросили всё сделать заранее, так как планировали начать работы уже 2-го января. Вот ещё категория трудоголиков, которая любит работать в праздники.

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

Основная проблема в том, что сайт относительно большой, а свободных мощностей у компании мало. Все арендованные и дорогие. Нужно порядка 400 Гб места на дисках под сам сайт и база данных mysql примерно 10 гигов. Да ещё и сайт планировали с php 7.4 перенести на 8.0, так что нужна была отдельная виртуалка, где можно будет обновлять пакеты и будет полный доступ у разработчиков. Я перед началом работ прикинул и понял, что развернуть копию на длительное время тупо негде.

Что-то докупать или заказывать в праздники не получится, потому что нужно согласовывать расходы, оплачивать и заказывать. Начал искать варианты. У сайта есть директория с пользовательскими прикреплёнными файлами. Для разработки они не нужны, так что решил поднимать без них. Нашёл сервер, где было немного свободного места. Развернул там виртуалку, скопировал сайт без лишних файлов. Начал разворачивать базу, не хватает места. И сам дамп большой, и во время разворачивания надо много места.

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

Решил таким образом. Все данные таблицы в дампе располагаются между строк Dumping data for table нужной таблицы и Table structure, где начинается новая таблица. Вывел все такие строки в отдельный текстовый файл:

# grep -n 'Table structure\|Dumping data for table' dump.sql > tables.txt

Нашёл там нужную таблицу и номера первой и второй указанных строк. И потом вырезал всё, что между ними с помощью sed. Первое число — номер строки Dumping data for table, которую нужно удалить и всё, что за ней. Второе — номер строки, предшествующей записи Table structure, так как эту строку нужно оставить. Она относится к структуре новой таблицы.

# sed '22826,26719 d' dump.sql > cleanup.sql

Таким образом можно очистить все ненужные таблицы, оставив только их структуру.

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

❓Кто ещё работает в праздники? Чем занимаетесь? Я обычно что-то обновляю, переношу, пока никто не мешает. Но на этот НГ ничего не планировал. Столько лет всегда что-то делаю, что решил в этот раз отдохнуть.

#webserver

​​Уже много лет веду свои дела в сервисе todoist.com. Начал это делать ещё до того, как прочитал книгу Тайм-менеджмент для системных администраторов. При этом мне всегда было достаточно бесплатной версии. Правда есть один нюанс. Когда-то давно в сервисе не было ограничения на 5 проектов для бесплатного тарифа. У меня была создана куча проектов, которые до сих пор остались. Я не могу добавить новых, но все старые на месте и мне их хватает.

С нового года сервис выкатил очень крутое обновление. Появилось полноценное отображение проектов в виде календаря с нанесёнными на него задачами. Не понимаю, почему они так долго существовали без этого. Мне приходится использовать связку todoist.com + planyway.com. Первый для задач, второй для календаря и тех задач, что мне важно видеть на календаре. Это закрывает все мои потребности, но очевидно, что 2 сервиса это хуже, чем один, где всё это в единой базе.

И вот у Todoist появился очень похожий календарь. Такое ощущение, что они его с Planyway и скопировали, так как сильно похож и внешне и по возможностям. К сожалению, этот календарь доступен только в платных тарифах. Оплатить из РФ их сейчас невозможно. Прежде чем платить, хотелось лично попробовать, а триал у меня давно уже закончен. Нашёл в инете промокод 6K94QXHTQ6 на 2 месяца тарифа Pro (активировать тут), который на удивление сработал. У Todoist периодически появляются рекламные промокоды, но все, что я нашёл, уже не действовали, кроме этого. Так что если давно пользуетесь сервисом и хотите ещё на какое-то время получить платный тариф, можно воспользоваться. Даже если потом не надумаете покупать, можно себе проектов добавить, сколько нужно, чтобы они потом остались.

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

Я пробовал огромное количество сервисов и программ для ведения календаря. Ничего удобнее Planyway так и не нашёл. Продолжаю использовать его на бесплатном тарифе. Мне возможностей хватает. Если Todoist реализует возможность отображения завершённых задач, перейду на него, так как замкнуть всё на один сервис будет намного удобнее, чем вести два. Есть неплохие календари в yonote, но мне ещё один сервис заводить не хочется. Кто с нуля себе подбирает что-то для заметок, календаря, списка дел, то обратите внимание. Сервис неплохой.

#заметки

​​Пока ещё не закончились праздники, а отдыхать уже надоело, есть возможность изучить что-то новое. Например, OpenStack 🤖 Для тех, кто не в курсе, поясню, что это модульная open source платформа, реализующая типовую функциональность современных облачных провайдеров. Установить её можно самостоятельно на своих мощностях. А для изучения есть упрощённые проекты для быстрого разворачивания.

Одним из таких проектов является snap пакет MicroStack от компании Canonical. С его помощью можно развернуть учебный OpenStack на одном хосте. Поставляется он в виде готового snap пакета под Ubuntu, так что ставится в пару действий. Внутри живёт Kubernetes, а MicroStack разворачивается поверх него. Установить можно даже в виртуальную машину на своём рабочем ноуте.

Cистемные требования MicroStack, заявленные на его сайте:
◽4 CPUs
◽16G Memory
◽50G Disk

Сама установка выполняется в пару команд:

# snap install microstack --beta
# microstack init --auto --control

Минут 10 будет длиться инициализация. Когда закончится, можно идти в веб интерфейс по ip адресу сервера. Логин - admin, а пароль смотрим так:

# snap get microstack config.credentials.keystone-password

Если у вас в браузере указан русский язык, то вы получите 502 ошибку nginx после аутентификации. Так было у меня. Чтобы исправить, нужно залогиниться в систему, получить 502-ю ошибку, зайти по урлу https://10.20.1.29/identity/, он должен нормально открыться. В правом верхнем углу будут настройки пользователя. Нужно зайти туда и выбрать язык интерфейса English. После этого нормально заработает.

В консоли можно работать с кластером через клиента microstack.openstack. К примеру, смотрим список стандартных шаблонов:

# microstack.openstack flavor list

Можно использовать стандартный openstackclient. Для этого там же в настройках пользователя в веб интерфейсе в выпадающем списке качаем OpenStack RC File. Ставим стандартный openstack client:

# apt install python3-openstackclient

Читаем скачанный файл с переменными окружения:

# source ./admin-openrc.sh

Теперь можно использовать консольный клиент openstack, добавляя опцию --insecure, так как сертификат самоподписанный:

# openstack --insecure project list

Если не хочется каждый раз вводить пароль администратора, можно добавить его явно в admin-openrc.sh в переменную OS_PASSWORD.

На этом собирался закончить заметку, но всё же кратко покажу, как с этой штукой работать. Чтобы запустить виртуалку нам нужно:

1️⃣ Создать проект и добавить туда пользователя.
2️⃣ Создать сеть и подсеть в ней.
3️⃣ Создать роутер и связать его с бриджем во внешнюю сеть.
4️⃣ Создать виртуальную машину с бриджем в этой подсети.
5️⃣ Создать группу безопасности и правило в ней для разрешения подключений по ssh.
6️⃣ Связать эту группу безопасности и виртуалку.

Команды приведу кратко, без описаний, опустив в начале openstack --insecure, так как лимит на длину публикации:

# project create LAB01
# role add --user admin --project LAB01 admin
# network create LAB01-NET
# subnet create --network LAB01-NET --subnet-range 192.168.100.0/24 --allocation-pool start=192.168.100.10,end=192.168.100.200 --dns-nameserver 77.88.8.1 LAB01-SUBNET
# router create LAB01-R
# router set LAB01-R --external-gateway external
# router add subnet LAB01-R LAB01-SUBNET
# floating ip create external
# server create --flavor m1.tiny --image cirros --network LAB01-NET --wait VM01
# server add floating ip VM01 596909d8-5c8a-403f-a902-f31f5bd89eae
# security group create LAB01-SG
# security group rule create --remote-ip 0.0.0.0/0 --dst-port 22:22 --protocol tcp --ingress LAB01-SG
# server add security group VM01 LAB01-SG

То же самое можно сделать руками через веб интерфейс. Можно подключиться к новой виртуалке через её floating ip из диапазона 10.20.20.0/24, который будет сопоставлен настроенному IP из 192.168.100.0/24. В веб интерфейсе все настройки будут отражены. Там же и консоль VM.

Поздравляю, теперь вы админ OpenStack. Можете развернуть для собственных нужд и тренироваться.

#виртуализация