ServerAdmin.ru
28.9K subscribers
303 photos
35 videos
13 files
2.63K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Я не раз поднимал на канале тему видеонаблюдения, преимущественно бесплатного и на Linux. При этом всё время обходил стороной старый российский проект Xeoma, у которого давняя история (с 2004 года) и много хороших отзывов. Я просто сам ни разу с ним не сталкивался, нигде не видел и не настраивал. А это один из старых серверов, у которого очень давно есть версия под Linux.

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

У Xeoma есть сервер видеонаблюдения под Linux (в том числе под архитектуру ARM) и Android(❗️). Причём как с графической оболочкой, так и без. Если устанавливать на сервер с графической оболочкой, там же будет установлен и клиент для настройки и управления. Если сервер без графики, то ставится только серверная часть, а клиент в любое другое место, например на систему с ОС Windows или на смартфон. Версии ОС клиента и сервера могут не совпадать.

Сервер распространяется в формате AppImage, то есть одиночный файл с расширением .app. Установка простая и быстрая, описана в документации. Просто запускаем сервер с ключами и подключаемся к нему клиентом для настройки.

У Xeoma есть бесплатная версия с ограниченной функциональностью. Основное ограничение - только 4 камеры для записи в архив и хранение в архиве - 5 дней. Подключать и просматривать в режиме реального времени можно сколько угодно. То есть это вариант для небольшой дачи или квартиры. Для доступа к своему серверу можно использовать сервис Ретранслятор. Подробно возможности бесплатной версии описаны в статье.

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

Думаю, в комментариях найдётся много тех, кто использует данный сервер. Я постоянно видел его упоминание.

#видеонаблюдение #отечественное
​​У меня до сих пор осталось некоторое количество серверов под управлением Centos 7. Совсем уже отвык от этой системы. Последние пару лет все новые сервера только Debian. Соответственно, они уже почти везде. Где-то делал миграцию с Centos на Debian, но Centos всё равно остались. Всё работает, обновления приходят, поэтому нет смысла суетиться и делать лишнюю работу.

Поддержка Centos 7 закончится 30 июня 2024 года. В принципе, ещё есть время подготовиться. Но тут основной вопрос, на какую систему в итоге перейти. Когда конвертировал 8-ю версию, как раз пару лет назад, выбрал Oracle Linux и сконвертировал системы в него. Думаю, что ошибся, надо было на AlmaLinux переходить. В тот момент не был уверенности, что этот форк получит хорошее развитие. К примеру, анонсированный VzLinux от Virtuozzo в итоге быстро стух и больше не развивается. По факту AlmaLinux стал наиболее распространённым форком. А вы что думаете на этот счёт?

Если решите в итоге Centos 7 сконвертировать в AlmaLinux, то у них есть хорошая инструкция, как получить сразу актуальную 9-ю версию. Я проверил, получилось без проблем. Я скорее всего на этом варианте остановлюсь. Только обязательно тестируйте такое обновление, так как 9-я версия требует дополнительный набор процессорных команд, обозначаемых как x86-64-v2 (SSE4.2, SSSE3, POPCNT и возможно что-то ещё). Иногда может потребоваться дополнительная настройка виртуальных машин. Хорошо, если гипервизор свой. А если арендованный, то обновление не установится. Не пройдёт проверку требований к железу. В PVE достаточно тип процессора с kvm64 заменить на host. Это актуально для всех форков RHEL9.

#centos #almalinux
​​У меня дома есть NAS и на всех компах и ноутах подключены сетевые папки. Домашние слабо представляют, как всё это работает. На смартфоне использую TotalCommander с плагином для доступа к тем же сетевым папкам. Жена наверное через TG или VK перекидывает файлы. По-другому вряд ли умеет. Детям это пока не надо.

Есть простое и удобное open source решение для этого вопроса - LocalSend. Поддерживает все операционные системы, в том числе на смартфонах. Это небольшое приложение, которое запускается на определённом порту (53317), принимает входящие соединения и с помощью нескольких методов (описание протокола, в основе поиска Multicast UDP, если не помогает, то POST запрос на все адреса локальной сети) осуществляет поиск таких же серверов в локальной сети. Передача данных осуществляется по протоколу HTTP.

На практике всё это работает автоматически. Приложение под Windows можно поставить, к примеру, через wingwet или скачать portable версию. На смартфоне ставим через Google Play, F-Droid или просто качаем apk. Работает всё в локальной сети, без необходимости каких-то внешних сервисов в интернете. Запускаем на обоих устройствах приложение, они сразу же находят друг друга. Можно передавать файлы. При этом можно на том же компе настроить такой режим, чтобы он автоматом принимал файлы со смартфона и складывал в определённую директорию.

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

Мне иногда надо сыну передать со своего смартфона из родительского чата информацию от учителя с пояснениями по домашке. Я для этого делал скриншот чата, клал его на NAS, на компе с NAS копировал сыну. Через приложение передать в разы удобнее. Запустил прогу и перекинул на комп с именем СЫН. Всё. Мессенджеров и соц. сетей у него пока нет.

Это приложение, которое я попробовал и сразу развернул на всех устройствах. Жене очень понравилось.

Отдельно отмечу, что приложение написано на языке программирования Dart. Впервые о нём услышал. Сначала показалось, что это типичное приложение на JavaScript под NodeJS. Но смутил небольшой размер. После этого и пошёл смотреть, на чём написано. Оказалось, что этот язык программирования разрабатывает Google как раз для замены JavaScript, взяв от него всё лучшее, но исправив недостатки. В целом, выглядит всё это неплохо.

Сайт / Исходники

#fileserver
​​Один из читателей канала давно мне скидывал информацию про скрипт для Zabbix, который отправляет оповещения с графиками в Telegram. Он его сам написал. У меня как-то затерялась эта информация и только сейчас дошли руки посмотреть. Я проверил, всё работает нормально. В целом, таких скриптов немало, я сам пользуюсь и в статье рассказываю про настройку. Тут отличие в том, что он полностью на Bash, в то время как я использую решения, написанные на Python. Вариант с башем лично для мне выглядит более привлекательным.

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

Отмечу несколько моментов, с которыми сам столкнулся.
1️⃣ Скрипт по умолчанию пишет лог файл в директорию /usr/lib/zabbix/alertscripts, владельцем которой является root, соответственно у скрипта нет прав на запись туда. Либо сделайте владельцем пользователя Zabbix, либо вынесите лог куда-то в другое место.

2️⃣ Второй момент - когда будете добавлять новый способ оповещений (media type), не забудьте добавить туда шаблоны. По умолчанию они не создаются. Я забыл об этом и не сразу догадался, почему ошибку при отправке через этот тип сообщений получаю.

3️⃣ Для айтема должен существовать график, чтобы он прилетел в оповещения. Иначе графика не будет. Если что-то не будет получаться, то почитайте комментарии к статье. Там автор подробно объясняет нюансы и показывает, как дебажить отсутствие графиков

#zabbix
​​Заметка для тех кому приходится разбираться на чужих серверах или перенимать полностью управление в свои руки. Для 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
This media is not supported in your browser
VIEW IN TELEGRAM
Бодрое видео на тему того, почему 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 http://1.2.3.4/ip

Powershell:
> Invoke-RestMethod http://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-аутсорса на разных этапах жизненного цикла продукта

#видео
Please open Telegram to view this post
VIEW IN TELEGRAM