​​На днях случилась необычная ситуация, с которой раньше не сталкивался. На ноутбук прилетели обновления. Среди них было:

▪️ Intel Software Guard Extensions Device and Software
▪️ Intel Management Engine Firmware
▪️ BIOS Update

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

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

"Не было печали, апдейтов накачали".

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

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

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

Любопытно, на что браузеры так отреагировали. На обновление биоса или каких-то интеловских примочек?

#разное

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

1️⃣ Скопировать файлы с одного сервера сначала к себе, а потом от себя на второй сервер. Я летом часто работаю по 4G, мне такой вариант не подходит. Как подвариант этого же варианта, копировать файлы на какой-то промежуточный сервер со скоростным интернетом.

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

Выйти из этой ситуации можно относительно просто без лишних телодвижений на серверах. На помощь придёт ssh-agent, который входит в состав ssh-client. Отдельно ставить не надо. Если его просто запустить, то он выведет свои переменные в терминал:

# ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXm7P5A8/agent.259; export SSH_AUTH_SOCK;
SSH_AGENT_PID=260; export SSH_AGENT_PID;
echo Agent pid 260;

Нам нужно их загрузить в оболочку для последующего использования. Сделаем это так:

# eval `ssh-agent`
Agent pid 266

Проверяем переменные:

# env | grep SSH_
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXrrbmpN/agent.265
SSH_AGENT_PID=266

Теперь добавим свои ключи из ~/.ssh в ssh-agent:

# ssh-add

Посмотреть все добавленные ключи можно командой:

# ssh-add -l

Почти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл ~/.ssh/config параметр для каждого сервера, к которому будем подключаться. Сервер можно указать как по ip адресу, так и по имени, в зависимости от того, как вы будете подключаться:

Host 1.2.3.4
ForwardAgent yes

Host srv-01
ForwardAgent yes

Всё, теперь можно подключаться:

# ssh root@1.2.3.4

Вы должны подключиться к серверу с пробросом агента. Проверьте это, зайдя в /tmp подключенного сервера. Там должен быть сокет агента:

root@1.2.3.4# ls /tmp | grep ssh-
ssh-vSnzLCX7LW

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

root@1.2.3.4# rsync -av /var/www/ root@5.6.7.8:/var/www/

Данные с сервера 1.2.3.4 будут скопированы на сервер 5.6.7.8 с использованием сертификата с вашей рабочей машины. Прямой аутентификации с 1.2.3.4 на 5.6.7.8 настроено не будет.

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

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

#ssh

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

#!/bin/bash

# Дамп базы с заменой общего комплексного параметра --opt, где используется ключ --lock-tables на набор отдельных ключей, где вместо lock-tables используется --single-transaction
/usr/bin/mysqldump --add-drop-database --add-locks --create-options --disable-keys --extended-insert --single-transaction --quick --set-charset --routines --events --triggers --comments --quote-names --order-by-primary --hex-blob --databases database01 -u'userdb' -p'password' > /mnt/backup/sql/"$(date +%Y-%m-%d)"-database01.sql

# Из общего дампа вырезаю дамп только данных таблицы table01. Общий дамп тоже оставляю, потому что он нужен для других задач
/usr/bin/cat /mnt/backup/sql/"$(date +%Y-%m-%d)"-database01.sql | /usr/bin/awk '/LOCK TABLES `table01`/,/UNLOCK TABLES/' > /mnt/backup/sql/"$(date +%Y-%m-%d)"-table01.sql

# Сжимаю оба дампа
/usr/bin/gzip /mnt/backup/sql/"$(date +%Y-%m-%d)"-database01.sql
/usr/bin/gzip /mnt/backup/sql/"$(date +%Y-%m-%d)"-table01.sql

# Копирую дамп таблицы на второй сервер, аутентификация по ключам
/usr/bin/scp /mnt/backup/sql/"$(date +%Y-%m-%d)"-table01.sql.gz sshuser@10.20.30.45:/tmp

# Выполняю на втором сервере ряд заданий в рамках ssh сессии: распаковываю дамп таблицы, очищаю таблицу на этом сервере, заливаю туда данные из дампа
/usr/bin/ssh sshuser@10.20.30.45 '/usr/bin/gunzip /tmp/"$(date +%Y-%m-%d)"-table01.sql.gz && /usr/bin/mysql -e "delete from database01.table01; use database01; source /tmp/"$(date +%Y-%m-%d)"-table01.sql;"'

# Удаляю дамп
/usr/bin/ssh sshuser@10.20.30.45 'rm /tmp/"$(date +%Y-%m-%d)"-table01.sql'

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

Отдельно отмечу для тех, кто не в курсе, что можно вот так запросто тут же после подключения по ssh выполнять какие-то команды в автоматическом режиме. Это удобно и часто пригождается.

#mysql #bash #script

​​Несмотря на то, что существует много инструментов для сканирования узлов в сети, лично я всегда использую Nmap. И при этом никогда не помню точно, какие ключи применить для скана (как и в tcpdump). Использую либо свои заметки, либо Zenmap GUI, который установлен на винде.

Я когда-то давно уже показывал небольшую подборку как раз из своих заметок. Решил обновить и актуализировать. В интернете есть популярный материал по этой теме:

⇨ Nmap Cheat Sheet 2024: All the Commands & Flags

Он как раз недавно обновился. Там наглядно и аккуратно структурированы команды для Nmap. Он у меня давно в закладках, иногда пользуюсь. Для удобства, решил его в сокращённой форме подготовить здесь, плюс добавить свои примеры и комментарии.

✅ Простое и быстрое сканирование только открытых портов до 1024 без подробностей:

nmap 192.168.1.1
nmap 192.168.1.1 192.168.2.1
nmap 192.168.1.1-254
nmap 192.168.1.0/24

✅ Полное сканирование всех открытых портов:

nmap 192.168.1.1 -p- 

Ключ -p позволяет задавать диапазон портов в различных форматах. Например -p 21 или -p 21-100, -p http,https В примере выше сканируются абсолютно все порты. Проверка получается значительно дольше предыдущего примера без указания полного диапазона.

✅ Скан хоста, не отвечающего на пинг. Без этого ключа не отвечающий на пинг хост игнорируется в сканировании, как находящийся вне сети.

nmap 192.168.1.1 -Pn

✅ Основные техники сканирования:

nmap 192.168.1.1 -sS - TCP SYN, значение по умолчанию
nmap 192.168.1.1 -sT - TCP connect
nmap 192.168.1.1 -sU - UDP сканирование

Обычно полное сканирование TCP и UDP портов запускают так (будет очень долго длиться):

nmap 192.168.1.1 -sS -sU -p-

✅ Обнаружение хостов в сети, без скана портов. Поиск с помощью пинга. Постоянно использую, когда надо получить список живых хостов в сети:

nmap 192.168.1.1/24 -sn

Если используете сложные списки хостов, или просто хотите быстро получить текстовый список какого-то набора IP адресов, то можно воспользоваться nmap:

nmap 192.168.1.1-15 -sL

Выведет список всех IP адресов в текстовом виде.

✅ Поиск хостов ARP запросами в локальной сети:

nmap 192.168.1.1/24 -PR

В локальной сети поиск хостов ARP запросами проходит в разы быстрее обычных. Подробно об этом и других техниках поиска хостов рассказано на сайте nmap. ❗️Данный метод используется принудительно в локальных сетях, даже если указать другой.

✅ Определение сервисов и их версий на открытых портах. Быстрая проверка с наглядным выводом всей информации, где 1 порт - одна строка. Удобно для визуального восприятия глазами:

nmap 192.168.1.1 -sV

Комбинированный ключ, который вызывает проверки ОС, версий сервисов, сканирование скриптами и использование traceroute. Более подробная и долгая проверка по сравнению с той, что выше. Вывод не очень нагляден для беглого просмотра:

nmap 192.168.13.1 -A

Команда выше универсальная и подойдёт для комплексного анализа хоста по портам до 1024. Это позволяет ей отрабатывать относительно быстро. Если запускать её по всем портам, то будет долго выполняться. Но можно сделать небольшой трюк, который я применяю на практике. Сначала ищем открытые порты, а потом на них выполняем полную проверку с ключом -A. Это значительно быстрее полной проверки по всем портам.

#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1

Использовать:

./nmap.sh 192.168.1.1

✅ Различные скорости и интенсивности проверок:

-T0 - paranoid (паранойдный)
-T1 - sneaky (хитрый)
-T2 - polite (вежливый)
-T3 - normal (обычный)
-T4 - aggressive (агрессивный)
-T5 - insane (безумный)

Описание этих шаблонов сканирования есть в документации. По умолчанию используется -T3, в локалке иногда повышают до -T4. Чем ниже режим, тем меньше потоков, меньше пакетов, ниже скорость сканирования, но и заметность меньше.

По факту получилось, что из статьи ничего и не взял. Все примеры свои привёл, а подробности смотрел в man и на сайте nmap.

⇨ Полная шпаргалка по nmap в формате PDF.

#nmap

Словил вчера необычный глюк, когда подключал новый сервер в стойке. Купили бушный Dell PowerEdge R730. Я, кстати, люблю эти сервера. Если нужен обычный сервер общего назначения, то всегда сначала эти смотрю подходящих конфигураций. Туда и памяти, и дисков можно много поставить. И стоит всё это дёшево по сравнению с новым железом. А для каких-нибудь файловых серверов, бэкапов, почтовых, мониторингов и логов его за глаза хватает. Плюс, удалённое управление через iDRAC удобное. Есть хороший шаблон под Zabbix для мониторинга по SNMP. Настраивается за 5 минут.

Возвращаюсь к глюку. В стойке для серверов стоит старенький управляемый гигабитный свитч D-link DGS-1500-20. В этой компании вообще все свитчи этой фирмы. И на удивление, они нормально работают. На моей памяти ни один не сломался. Хотя я если подбираю свитчи, то стараюсь что-то подороже брать, например HPE. Не знаю, можно ли их сейчас купить. Давно не брал.

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

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

Я даже как-то растерялся. Не смог в голове составить картинку, что вообще происходит. Решил даже схему нарисовать, кто кого видит, а кого нет. Никакой системы не смог распознать. Посмотрел в логи серверов, там ничего интересного нет. В веб интерфейсе свитча никаких ошибок на портах тоже не увидел. Запустил tcpdump, посмотрел трафик. Ничего необычного не заметил.

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

Что это было, даже не знаю. Идей нет. Только на глюки конкретного порта могу списать. Обычно если встречаешься с такими странностями, то либо в сети видишь спам пакетами от кого-нибудь, либо в статистике портов видно ошибки, либо тот же спам пакетами. Тут ничего подозрительного не увидел. У кого-то есть идеи, что это может быть?

#железо

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

С помощью Cloud-Init в Proxmox можно автоматически добавить в виртуальную машину:

- пользователей, пароли, ключи для SSH
- настройки DNS
- сетевые настройки
- выполнить принудительное обновление пакетов

Технически это выглядит следующим образом.

1️⃣ Вы настраиваете виртуальную машину так, как вам нужно. Ставите нужные пакеты, настраиваете ПО, если надо. Отдельно устанавливаете пакет с cloud-init:
# apt install cloud-init
Можно использовать готовые образы уже с cloud-init внутри:
https://cloud.debian.org/images/cloud/
https://cloud-images.ubuntu.com/
https://dl.astralinux.ru/ui/native/mg-generic/alse/cloud/
Proxmox поддерживает готовые образы, сформированные для OpenStack.

2️⃣ Из этой виртуальной машины делаете эталонный шаблон средствами Proxmox (пункт меню convert to template).

3️⃣ Создаёте из этого шаблона виртуальную машину. Добавляете к ней отдельное устройство Cloudinit Drive.

4️⃣ В настройках виртуальной машины есть отдельный раздел Cloud-init, где можно индивидуально для конкретной машины задать перечисленные выше настройки.

Без Cloud-Init пришлось бы руками лезть в новую виртуалку и менять эти параметры. А так они аккуратно задаются через интерфейс управления и потом применяются. Работает просто и удобно. Настраивается тоже без проблем.

Описанная выше инструкция с техническими подробностями есть в Wiki Proxmox. Там же FAQ по этой теме:

- Cloud-Init Support
- Cloud-Init FAQ

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

#proxmox

Я давно знаю и работаю с программой для бэкапа виртуальных сред Veeam Backup & Replication. Как всем известно, этот бренд ушёл из России, заблокировал доступ к своим ресурсам, не осуществляет продажи и не оказывает тех. поддержку. Полноценных аналогов с такой же функциональностью не так много. Я даже затрудняюсь назвать их, хотя наверняка есть, но мне не знакомы. То есть не работал с ними. Отечественные решения, насколько я знаю, по возможностям пока не дотягивают до Veeam.

Есть китайский аналог Vinchin Backup & Recovery. Я года два назад про него узнал, когда начались всевозможные санкции. Были пару обзоров от наших интеграторов КРОК и ГК ЛАНИТ. Причём отзывы вполне нормальные. В то же время на меня выходили сами разработчики и хотели какой-то кооперации: статьи, заметок в telegram, анонсов вебинаров и т.д. Был необычный опыт, так как общаться приходилось явно с не русскоязычным человеком, но мы понимали друг друга. Но всё как-то не срасталось по срокам и форматам.

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

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

📌 Vinchin Backup & Recovery умеет бэкапить:

◽Виртуальные машины на различных гипервизорах и системах виртуализации. Список там очень внушительный, перечислю наиболее популярные и актуальные: zVirt, ROSA Virtualization, RED Virtualization, Hyper-V, Proxmox, VMware, Citrix, XCP-ng, oVirt, OpenStack
◽Базы данных популярных СУБД: MS SQL, MySQL, Oracle, PostgreSQL, MariaDB
◽Файлы в операционных системах Windows и Linux с помощью установленных агентов. Есть поддержка Astra Linux и RED OS.
◽Целиком операционные системы Windows и Linux, либо отдельные диски в них.
◽Сетевые диски, подключаемые по протоколам CIFS и NFS.
◽Microsoft Exchange как локальной установки, так и облачной.
◽Виртуальные машины облачного провайдера AWS EC2

Получается, он покрывает все варианты информации. Тут и виртуальные машины, и сервера через агентов, и сетевые диски, и СУБД.

Я развернул у себя эту систему. Ставится автоматически из готового ISO образа. Всё управление через веб интерфейс. Попробовал забэкапить и восстановить виртуальные машины на Hyper-V и Proxmox, а также сетевой диск.

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

⇨ Обзор Vinchin Backup & Recovery

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

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

#backup

Видео про весёленький денёк у сисадмина - лучший юмористический ролик, что я знаю про сисадминские будни. Столько времени прошло, но ничего веселее и оригинальнее я не видел. Для тех, кто не знает (завидую таким), речь идёт вот об этом:

▶️ https://www.youtube.com/watch?v=uRGljemfwUE - оригинал
▶️ https://www.youtube.com/watch?v=W4uGoFBL-GM - субтитры на русском

Если знаете английский, смотрите оригинал, если нет - в русских субтитрах. Там забавные голоса.

А если хотите по-новому посмотреть этот шедевр, попробуйте включить онлайн озвучку в Яндекс.Браузере. Видео заиграет новыми красками 😁 Я искренне в очередной раз посмеялся при просмотре.

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

The Website is Down #2: Excel Hell
⇨ https://www.youtube.com/watch?v=1SNxaJlicEU

🔥The Website is Down #3: Remain Calm
⇨ https://www.youtube.com/watch?v=1XjKnxOcaO0

The Website is Down Episode #4: Sales Demolition (NSFW)
⇨ https://www.youtube.com/watch?v=v0mwT3DkG4w

Episode #4.5: Chipadmin
⇨ https://www.youtube.com/watch?v=s8QjArjcjbQ

#юмор

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

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

Игра, если что, есть на торрентах. Не знаю, можно ли сейчас в стиме что-то покупать. Стоит, как чашка кофе.

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

▶️ ВОТ ТАК РАБОТАЮТ НАСТОЯЩИЕ ПРОФИ ( Cyber Attack )

У него ещё пара роликов с этой игрой есть. Игра, как я понял, чисто почилить пару часиков в бутафории. Покачать немного навыки в стиле игр на развитие 90-х, 2000-х годов, где вы копите деньги, качаете скилы, покупаете новое оборудование и т.д.

#игра

Я много раз упоминал в заметках, что надо стараться максимально скрывать сервисы от доступа из интернета. И проверять это, потому что часто они туда попадают случайно из-за того, что что-то забыли или неверно настроили. Решил через shodan глянуть открытые Node Exporter от Prometheus. Они часто болтаются в открытом виде, потому что по умолчанию никаких ограничений доступа в них нет. Заходи, кто хочешь, и смотри, что там есть.

И первым же IP адресом с открытым Node Exporter, на который я зашёл, оказалась чья-то нода Kubernetes. Причём для меня она сразу стала не чей-то, а я конкретно нашёл, кому она принадлежит. Мало того, что сам Node Exporter вываливает просто кучу информации в открытый доступ. Например, по volumes от контейнеров стало понятно, какие сервисы там крутятся. Видны названия lvm томов, точки монтирования, информация о разделах и дисках, биос, материнка, версия ОС, система виртуализации и т.д.

На этом же IP висел Kubernetes API. Доступа к нему не было, он отдавал 401 Unauthorized. Но по сертификату, который доступен, в Alternative Name можно найти кучу доменов и сервисов, которые засветились на этом кластере. Я не знаю, по какому принципу они туда попадают, но я их увидел. Там я нашёл сервисы n8n, vaultwarden, freshrss. Не знаю, должны ли в данном случае их веб интерфейсы быть в открытом доступе или нет, но я в окна аутентификации от этих сервисов попал.

Там же нашёл информацию о блоге судя по всему владельца этого хозяйства. Плодовитый специалист из Бахрейна. Много open source проектов, которые он развивает и поддерживает. Там же резюме его как DevOps, разработчика, SysOps. Нашёл на поддоменах и прошлую версию блога, черновики и кучу каких-то других сервисов. Не стал уже дальше ковыряться.

Ссылки и IP адреса приводить не буду, чтобы не навредить этому человеку. Скорее всего это какие-то его личные проекты, но не факт. В любом случае, вываливать в открытый доступ всю свою подноготную смысла нет. Закрыть файрволом и нет проблем. Конечно, всё это так или иначе можно собрать. История выпущенных сертификатов и dns записей хранится в открытом доступе. Но тем не менее, тут всё вообще в куче лежит прямо на активном сервере.

Для тех, кто не в курсе, поясню, что всю историю выпущенных сертификатов конкретного домена со всеми поддоменами можно посмотреть тут:

⇨ https://crt.sh

Можете себя проверить.

#devops #security

​​Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.

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

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

То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:

# journalctl --vacuum-size=256M

Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.

Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.

Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.

#proxmox #backup

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

Для проксирования запросов в Docker контейнеры очень удобно использовать Traefik. Удобство это в первую очередь проявляется в тестовых задачах, где часто меняется конфигурация контейнеров с приложениями, их домены, а также возникают задачи по запуску нескольких копий типовых проектов. Для прода это не так актуально, потому что он обычно более статичен в этом плане.

Сразу покажу на практике, в чём заключается удобство Traefik и в каких случаях имеет смысл им воспользоваться. Для примера запущу через Traefik 2 проекта test1 и test2, состоящих из nginx и apache и тестовой страницы, где будет указано имя проекта. В этом примере будет наглядно виден принцип работы Traefik.

Запускаем Traefik через docker-compose.yaml:

# mkdir traefik && cd traefik
# mcedit docker-compose.yaml

services:
  reverse-proxy:
    image: traefik:v3.0
    command: --api.insecure=true --providers.docker
    ports:
      - "80:80"
      - "8080:8080"
    networks:
      - traefik_default
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
networks:
    traefik_default:
      external: true

# docker compose up

Можно сходить в веб интерфейс по ip адресу сервера на порт 8080. Пока там пусто, так как нет проектов. Создаём первый тестовый проект. Готовим для него файлы:

# mkdir test1 && cd test1
# mcedit docker-compose.yaml

services:
  nginx:
    image: nginx:latest
    volumes:
    - ./app/index.html:/app/index.html
    - ./default.conf:/etc/nginx/conf.d/default.conf
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nginx-test1.rule=Host(`test1.server.local`)"
      - "traefik.http.services.nginx-test1.loadbalancer.server.port=8080"
      - "traefik.docker.network=traefik_default"
    networks:
    - traefik_default
    - test1

  httpd:
    image: httpd:latest
    volumes:
    - ./app/index.html:/usr/local/apache2/htdocs/index.html
    networks:
      - test1

networks:
  traefik_default:
    external: true
  test1:
    internal: true

# mcedit default.conf 

server {
    listen 8080;
    server_name _;

    root /app;
    index index.php index.html;

    location / {
        proxy_pass http://httpd:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

# mcedit app/index.html

It's Container for project test1

Запускаем этот проект:

# docker compose up

В веб интерфейсе Traefik, в разделе HTTP появится запись:

Host(`test1.server.local`) http nginx-test1@docker  nginx-test1

Он по меткам в docker-compose проекта test1 автоматом подхватил настройки и включил проксирование всех запросов к домену test1.server.local в контейнер nginx-test1. При этом сам проект test1 внутри себя взаимодействует по своей внутренней сети test1, а с Traefik по сети traefik_default, которая является внешней для приёма запросов извне.

Теперь можно скопировать проект test1, изменить в нём имя домена и имя внутренней сети на test2 и запустить. Traefik автоматом подцепит этот проект и будет проксировать запросы к test2.server.local в nginx-test2. Работу этой схемы легко проверить, зайдя откуда-то извне браузером на test1.server.local и test2.server.local. Вы получите соответствующую страницу index.html от запрошенного проекта.

К Traefik легко добавить автоматическое получение TLS сертификатов от Let's Encrypt. Примеров в сети и документации много, настроить не составляет проблемы. Не стал показывать этот пример, так как не уместил бы его в формат заметки. Мне важно было показать суть - запустив один раз Traefik, можно его больше не трогать. По меткам в контейнерах он будет автоматом настраивать проксирование. В некоторых ситуациях это очень удобно.

#webserver #traefik #devops

Файловая система ext4 при создании резервирует 5% всего объёма создаваемого раздела. Иногда это очень сильно выручает, когда система встаёт колом и нет возможности освободить место. А без этого она не может нормально работать (привет zfs и lvm-thin). Тогда можно выполнить простую операцию:

# tune2fs -m 3 /dev/mapper/root
или
# tune2fs -m 3 /dev/sda3

Вместо 5% в резерв оставляем 3%, а высвободившееся место остаётся доступным для использования. На больших разделах 5% может быть существенным объёмом. Очень хочется этот резерв сразу поставить в 0 и использовать весь доступный объём. Сделать это можно так:

# tune2fs -m 0 /dev/sda3

Сам так не делаю никогда и вам не рекомендую. Хотя бы 1% я всегда оставляю. Но чаще всего именно 3%, если уж совсем место поджимает. Меня не раз и не два выручал этот резерв.

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

Создаём swap размером в гигабайт и подключаем:

# dd if=/dev/zero of=/swap bs=1024 count=1000000
# mkswap /swap
# chmod 0600 /swap
# swapon /swap

Если вдруг решите, что своп вам больше не нужен, отключить его так же просто, как и подключить:

# swapoff -a
# rm /swap

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

# fallocate -l 10G /big_file

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

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

#linux

​​Подписчик поделился информацией об одном любопытном проекте по созданию инфраструктуры рабочих мест на базе Kubernetes, где рабочие места поднимаются в подах. По сути это получается open source аналог Citrix Workspace. Разумеется, с большой натяжкой, так как это всего лишь небольшой бесплатный проект с открытым исходным кодом.

Речь идёт об webmesh-vdi. Основные возможности этой системы:

◽Запуск операционных систем в подах Kubernetes. Соответственно, поддерживается только то, что работает в контейнерах на Linux хосте.
◽Доступ к системам через браузер с поддержкой микрофонов и звуков, передачей файлов.
◽Поддержка MFA через zitadel.
◽Локальная аутентификация пользователей, через LDAP или OpenID.
◽Helm чарт, чтобы всё это быстро развернуть.

Запустить всё это хозяйство можно в существующем кластере Kubernetes через готовый helm chart. Если у вас его нет, а попробовать хочется, то можно запустить на k3s, развёрнутым локально как standalone kubernetes на базе одной ноды. Для этого нужна любая система с установленным docker и пакетом dialog:

# curl https://get.docker.com | bash -
# apt install dialog
# curl -JLO https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/architect/kvdi-architect.sh
# bash kvdi-architect.sh

Можно ничего не настраивать, а оставить по умолчанию. После установки можно сразу скачать шаблоны ОС:

# k3s kubectl apply -f https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/examples/example-desktop-templates.yaml

Установятся 3 шаблона:

▪️ ubuntu-xfce
▪️ ubuntu-kde
▪️ dosbox

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

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

# kubectl get pod

NAME                   READY  STATUS
prometheus-operator-8545786465-zdt97 1/1   Running
kvdi-manager-57d84fcd49-pbc6l      2/2   Running
kvdi-app-df5c78cc7-kdfrt         2/2   Running
prometheus-kvdi-prometheus-0       3/3   Running
ubuntu-kde-qqjmc             2/2   Running

Все компоненты webmesh-vdi запущены в подах, в том числе и рабочее место на базе ubuntu-kde, которое я создал из шаблона.

Интересный проект. Мне понравился своей относительной простотой и реализацией. Ниже список других упоминаемых мной проектов, на базе которых можно построить инфраструктуру vdi:

- Ravada VDI
- OpenUDS
- PVE-VDIClient
- Termidesk

Если кому любопытно, моё отношение к Kubernetes. А если вы никогда не работали с Кубером, но хотите погонять этот проект, то вот моя статья с базовым описанием команд и в целом по работе с кластером Kubernetes. Этой информации хватит, чтобы хоть немного ориентироваться в том, что там происходит.

#vdi #kuber

В продолжение утренней темы про удалённые рабочие места. Есть интересный проект n.eko по запуску различных браузеров в Docker контейнере с доступом к нему по протоколу WebRTC.

На практике это может выглядеть так. Вы арендуете где-то VPS, ставите туда Docker и запускаете необходимый вам браузер из готового образа neko. Далее со своего рабочего места в браузере открываете этот браузер. Благодаря возможностям WebRTC всё работает быстро в том числе с передачей звука и видео. Спокойно можно смотреть ютуб или любое другое видео.

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

Работает это максимально просто и быстро. Создаём compose.yaml с нужным браузером:

services:
  neko:
    image: m1k1o/neko:google-chrome
    restart: unless-stopped
    shm_size: 3gb
    ports:
      - 8080:8080
      - 52000-52100:52000-52100/udp
    cap_add:
      - SYS_ADMIN
    environment:
      NEKO_SCREEN: 1920x1080@30
      NEKO_PASSWORD: neko
      NEKO_PASSWORD_ADMIN: admin
      NEKO_EPR: 52000-52100
      NEKO_NAT1TO1: 10.20.1.36

И запускаем:

# docker compose up -d

В данном примере NEKO_NAT1TO1: 10.20.1.36 - адрес сервера в локальной сети, где я запускаю neko. Если это будет VPS с внешним ip адресом, ничего указывать не надо. Адрес будет определён автоматически.

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

NEKO_PASSWORD: neko - пароль для пользователей, которые смогут только смотреть.
NEKO_PASSWORD_ADMIN: admin - пароль для пользователя admin. То есть заходить админом вам надо будет с учёткой admin / admin.

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

Neko можно запустить по HTTPS или через обратный прокси. В документации есть примеры настроек для этого. Для прокси удобно использовать упомянутый ранее Traefik. Для него тоже пример конфигурации представлен.

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

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

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

Отдельно есть проект по управлению виртуальными комнатами с запущенными браeзерами neko - neko-rooms.

⇨ Сайт / Исходники / Neko-rooms

#vdi

​​Ушла эпоха. Сервис icq завершил свою работу.

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

Нашёл у себя основной клиент для ICQ, которым больше всего пользовался. Это портабельная версия Miranda. Очень приятный софт был с кучей плагинов. При этом минималистичный, не жрущий ресурсы, и работающий без установки. Запустил его, работает, как и прежде, только подключиться к серверам, само собой, не может. Вся история сохранилась, с ней удобно работать. Посмотрел переписку. В 2017 году последние записи. Довольно долго у меня продержалась. В это время уже параллельно со Skype использовал. А потом полностью на Telegram перешёл.

Меня удивляет, что после Miranda была куча мессенджеров, и все они хуже её. Неужели нельзя было посмотреть и сделать нечто похожее? По удобству работы с историей переписки ничего близко нет и сейчас. Я буквально пару лет назад потушил последний сервер с Jabber, где в качестве клиента использовалась Miranda. Людей она полностью устраивала, хоть возможности как сервера, так и клиента морально устарели. Не хватало статуса прочтения сообщений, гибкой передачи и хранения файлов на сервере. Но меня в качестве админа очень устраивало такое решение, так как почти не тратило время на обслуживание. Просто всегда работало. С современными чат серверами типа Rocket.Chat или Zulip хлопот гораздо больше. А Jabber + Miranda просто работали.

История в Миранде осталась с 2008 года. Почитал немного, как в другую жизнь попал. Самая большая группа с пользователями - Lineage 😎 Ничего уже не помню из того времени. Не знаю, зачем я всё это храню. Привычка, закреплённая в генах - всё хранить. Вдруг пригодится. Я ещё прадеда застал, который всё хранил, и отец мой такой же. Наверное это полезный навык для крестьян, потомком которых я являюсь. Но сейчас это больше мешает. Хотя кто знает, как жизнь повернётся.

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

#разное

Как быстро прибить приложение, которое слушает определённый порт?

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

# ss -tulnp | grep 8080
tcp LISTEN 0 5 0.0.0.0:8080 0.0.0.0:* users:(("python3",pid=5152,fd=3))
# kill 5152

Но быстрее и проще воспользоваться lsof:

# lsof -i:8080
COMMAND PID USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
python3 5156 root  3u IPv4 41738   0t0 TCP *:http-alt (LISTEN)
# kill 5152

Или вообще в одно действие:

# lsof -i:8080 -t | xargs kill

Lsof могучая утилита. Я как-то особо не пользовался ей, кроме как для файлов, пока не подготовил заметку год назад с примерами использования. С тех порт и для сетевых соединений стал активно применять. Особенно вот в таком виде:

# lsof -i
# lsof -i TCP:25
# lsof -i TCP@1.2.3.4

Возвращаюсь к открытым портам. Есть утилита killport, которая делает то же самое, что я делал выше, только в одну команду:

# killport 8080

В стандартных репах её нет, придётся качать бинарник из репозитория. Если для Linux это не сильно надо, так как там много инструментов для подобных действий, что я продемонстрировал выше, то для Windows это будет более актуально. Killport есть и под винду (❗️) Использовать можно примерно так:

> killport 445 --dry-run
Would kill process 'System' listening on port 445

То есть сначала смотрим, что будет прибито, а потом только делаем.

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

#terminal #bash

​​Вчера новость прилетела от Onlyoffice, что вышла новая версия Docs 8.1. Я сначала прохладно отнёсся к ней, так как не так давно был релиз 8.0 и я о нём писал. В этот раз бегло посмотрел анонс нововведений. И меня там очень привлекло то, что они внедрили редактирование pdf файлов. Это на самом деле востребованная функциональность, так что я решил сразу её попробовать.

Про Onlyoffice я много писал на канале, есть статьи на сайте, так что не буду подробно про него рассказывать. Это сервис для совместной работы и онлайн редактирования документов. Я сам постоянно использую этот продукт в работе. Внедрил его в нескольких компаниях для работы с документами, а сам там веду документацию и некоторые другие записи совместно с другими сотрудниками.

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

Попробовать очень просто. Даже никаких настроек не надо. Нужна только виртуалка с 8 Гб оперативной памяти и  4 vCPU. Делаем вот так:

# wget https://download.onlyoffice.com/install/workspace-install.sh
# bash workspace-install.sh

Выбираем установку в Docker и дожидаемся завершения. После этого можно сразу идти в веб интерфейс по IP адресу сервера, создавать администратора и начинать пользоваться. Детальные настройки можно потом сделать. Для попробовать ничего делать больше не нужно. Редактор документов уже будет работать.

Я сразу закинул туда несколько pdf файлов и попробовал редактировать. Работает всё, кроме редактирования текста. Похоже на какой-то баг OCR (распознавания текста). Нажимаю Редактировать текст и документ падает с ошибкой. Помогает только закрытие и открытие документа. В логах контейнера с Docserver появляется неинформативная ошибка, так что не понятно, с чем связано. С учётом того, что релиз был вчера, думаю, что поправят.

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

Так что рекомендую для тех, кому нужна подобная функциональность. Onlyoffice Docs может работать как в составе другого продукта этой компании Workspace, так и в интеграции со сторонними продуктами. Например, в Nextcloud. Это наиболее распространённое использование этого движка. А так он интегрируется со всеми популярными платформами для совместной работы. Есть даже плагин для Wordpress, чтобы в админке этой CMS работать с документами.

⇨ Новость о релизе / ▶️ Обзор нововведений

#onlyoffice #docs

▶️ Всем хороших тёплых летних выходных. Желательно уже в отпуске в каком-то приятном месте, где можно отдохнуть и позалипать в ютуб. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными.

⇨ Установка Opnsense в Proxmox
Обзор популярного программного шлюза OPNsense, аналога pfSense. Практики в видео почти нет, в основном разговоры о самой системе и о софтовых шлюзах. Автор просто выполнил установку и самую начальную настройку.

⇨ Best operating system for Servers in 2024
Небольшой обзор современных гипервизоров и систем для решения различных задач. Интересно для расширения кругозора, если с чем-то не знакомы. Автор кратко рассказывает о VMware ESXi, Nutanix AHV, Proxmox VE, XCP-ng, Talos Linux, Flatcar Container Linux, Fedora CoreOS, Windows Server, TrueNAS Scale, Ubuntu, Debian, Qubes OS, Tails OS, Kali Linux.

⇨ Установка Kubernetes
Название ролика не соответствует содержанию. Самой установки там нет, но есть содержательная беседа трёх специалистов на тему Кубернетиса. Можно просто послушать, не смотреть, где-то в машине или метро.

⇨ Vaultwarden Свой менеджер паролей
Обзор популярного менеджера паролей для совместной работы с ними. Писал про него заметку. По ссылке подборка всех менеджеров паролей, что я обозревал.

⇨ The terminal WARS begins! // Warp vs Wave
Какие-то супер навороченные терминалы. Не слышал ни про первый, ни про второй. Да и пользоваться ими не буду. Навскидку, чтобы ими начать пользоваться, надо изучать, как Vim. Они его, кстати, заменяют. Не вижу большого смысла во всём этом для администрирования серверов. Но посмотреть было интересно. Там и шаринг кода, и AI помощник, и общие хранилища, и много всяких других фишек, помимо базовых. Позже выяснил, что их под винду и нет. Сборки только для Linux и MacOS.

⇨ Zabbix workshops: Zabbix proxy high-availability and load balancing
⇨ Zabbix workshops: New web monitoring features in Zabbix 7.0
Два больших ролика (~по часу) на заданные темы. Показаны практические примеры по настройке. То есть специалист сидит, настраивает на реальном мониторинге и нам рассказывает. Люблю такой формат, потому что тут конкретика. Смотреть просто так смысла нет, но если будете настраивать эти вещи, то видео очень пригодятся.

⇨ Meet ChangeDetection - A Self-Hosted Website Change Detector!
Подробный обзор очень интересной бесплатной системы мониторинга за сайтами, их состоянием и контентом. Заинтересовался этой штукой. Запланировал попробовать и написать заметку. Это не просто мониторинг, но и отслеживание изменений контента для различных задач. Например, можно следить за ценами, погодой, курсами и т.д.

#видео

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

Вообще, у меня обширный опыт работы в формате фриланса и удалёнки. Я точно помню, когда уволился с постоянной работы по найму. Это был 2014-год. То есть уже полных 10 лет. В 2018 я открыл ИП. А до этого работал по трудовой, с совмещением, по договорам ГПХ. Вообще говоря, я стал специалистом в этой области не меньше, чем в IT. Возможно об этом было бы интереснее читать, чем мои настройки чего-либо, потому что о них много кто пишет. Трудовая деятельность и моя жизнь в целом необычная и интересная.

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

Иногда приезжаю в офис для разнообразия. Есть компания, с которой работаю уже 9 лет, почти с момента увольнения с постоянной работы. Есть свободные рабочие места, можно посидеть. Эффективность труда там низкая, постоянно отвлекаешься. А кто-то постоянно так работает. Мне не нравится. Я в основном потрындеть, попить кофе приезжаю, на метро прокатиться. После 18-ти, когда все уезжают, занимаюсь своими делами.

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

Днём перехватываю различные краткосрочные дела, основной объём делаю вечером после 21-22, когда уложу детей. Где-то до часа-двух ночи работаю. В таком графике нахожусь довольно долго. Он уже устоялся. Для здоровья позднее укладывание не слишком полезно, но по-другому не получается выйти на стабильный график. Практиковал ранний подъём, но в 7 уже встают дети, жена, начинают отвлекать. Даже если вставать в 5, а я так делал, остаётся слишком маленький промежуток спокойного времени, плюс нет запаса по времени на случай нештатных ситуаций. Ночью, хоть и не часто, но бывает что задержишься из-за каких-то проблем.

Не думаю, что такого рода мой опыт будет кому-то полезен, так как он очень индивидуален из-за большого количества детей и семейных дел. Так что я вас просто развлёк этой заметкой. Помимо семьи у меня пожилые родители, моя дача, их дача. Всё это требует постоянного моего участия: то котёл потёк, то скважина забилась, то бассейн позеленел, то высаженные туи пожелтели, то косить, то строить, то ещё что-то. Параллельно семейным делам я ещё и стройкой руководил несколько лет, пока участок обустраивал и дом строил. Во всё приходится вникать и разбираться. Не представляю, как бы я вообще со всем управлялся, если бы была постоянная работа с 9 до 18. Детей бы точно столько не было.

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

Всем хороших выходных. Спасибо, что читаете и лайкаете 👍🏻

#разное

Вчера вечером сел за компьютер посмотреть почту, в том числе сообщения от мониторинга. Всегда это делаю вечером в воскресенье, чтобы оценить состояние инфраструктуры перед понедельником. Привлёк внимание триггер от Zabbix с одной виртуалки. Там в течении почти 6-ти часов было высокие метрики по Load Average. Потом прошло.

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

Когда-то давно я придумал решение этой задачи в лоб:

1️⃣ Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.

2️⃣ Разрешаю на zabbix agent запуск внешних команд.

3️⃣Настраиваю на Zabbix Server действие при срабатывании триггера на загрузку CPU. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.

# ps aux --sort=-pcpu,+pmem | head -10

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

Описал этот способ в статье:

⇨ Мониторинг списка запущенных процессов в Zabbix

Способ рабочий, я им одно время пользовался, а потом забил по нескольким причинам:

1️⃣ По возможности стараюсь не использовать скрипты на хостах, потому что это усложняет настройку, неудобно быстро разворачивать и переносить настройки.

2️⃣ Настройка EnableRemoteCommands=1 потенциально небезопасна. По возможности её лучше не использовать. А если используешь, то надо и за фаерволом следить, и за tls. А если что-то от root запускаешь, то через мониторинг тебе вообще всю инфру положить могут.

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

В Zabbix Server 6.2 появился новый айтем:

◽proc.get[<name>,<user>,<cmdline>,<mode>]

С его помощью можно вывести подробную информацию либо обо всех процессах системы, либо о заданных. Описание параметров есть в документации. Посмотреть через консоль, как он работает и что выводит, можно так:

# zabbix_agentd -t proc.get[zabbix_server,,,]
# zabbix_agentd -t proc.get[zabbix_server,,,summary]
# zabbix_agentd -t proc.get[]

Вся информация в json. Теоретически её можно собрать обо всех процессах, обработать, отсортировать по CPU или различным метрикам памяти и как-то вывести. Но наглядность будет сильно хуже, чем отсортированный вывод ps aux. Плюс, не совсем понимаю, как всё это организовать в рамках Zabbix Server без скриптов на хосте с привязкой к триггеру, чтобы не постоянно это всё собирать, а только когда нужно.

Если у кого-то есть идеи, поделитесь. Ну а кому интересно подобное настроить, то решение в статье вполне рабочее. Нужно только сделать поправку на то, что статья писалась давно, а интерфейс Zabbix Server с тех пор изменился. Некоторые настройки изменили своё положение. Но сам подход через скрипт и EnableRemoteCommands сработает и сейчас.

#zabbix