​​Вчера рассказал про сервис vulnersCom и кратко упомянул про его интеграцию с nmap. Сегодня хочу немного расширить эту тему. У компании cloudflare в их github репозитории есть небольшой продукт на основе nmap и скрипта vulners.nse - Flan. Он ничего особенного не делает, кроме небольшой автоматизации по передачи списка ip адресов для сканирования. Плюс, поддерживает разные форматы вывода результатов: html, json, xml, markdown. Также он умеет складывать результаты тестов в GCS Bucket или AWS S3 Bucket.

Описание Flan есть в блоге cloudflare. Проект старый и особо не развивается, но там и развивать нечего. Та функциональность, что в него заложена, нормально работает и не требует обновления. Покажу сразу на примере, как он работает и что делает.

Клонируем к себе репозиторий:

# git clone https://github.com/cloudflare/flan

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

Так что запуск сканирования выглядит следующим образом. Готовим список IP адресов в файле shared/ips.txt. Одиночные IP адреса нужно указывать без маски /32. Потом собираем контейнер. Все команды уже прописаны в Makefile, поэтому запускаем через него:

# make build

Чтобы всё получилось, Docker и make у вас должны стоять в системе. Если нет, то поставьте:

# curl -o - https://get.docker.com | bash -
# apt install make

Когда соберётся образ, можно запускать сканирование:

# make start

Результат будет выведен в консоль. Чтобы вывести его в html файл для удобного просмотра, запускаем так:

# make html

Результат будет в директории shared/reports. Можно запустить веб сервер, чтобы быстро посмотреть html файлы:

# cd ~/flan/shared/reports
# python3 -m http.server 80

Смотрим результат сканирования в удобочитаемом виде с активными ссылками на все CVE. Очень удобно. Можно этот процесс автоматизировать, поднять постоянный веб сервер и хранить результаты некоторое время.

Если не уважаете Docker, можете запускать без него. В Dockerfile всё показано, что надо сделать, для локального запуска. Надо поставить несколько пакетов, python модулей, забрать скрипты pthon и запускать run.sh.

Отдельно в репозитории рассказано, как всё это сканирование запускать в Kubernetes для проверки контейнеров.

#security #nmap

​​🎓 Не так давно известная обучающая платформа KodeKloud выпустила обновление своей бесплатной геймифицированной платформы для обучения системных администраторов и devops инженеров - engineer.kodekloud.com. Для тех, кто не знает, что это такое, поясню. Ранее я уже рассказывал об этой платформе, но было это несколько лет назад. С тех пор она прилично изменилась.

В KodeKloud Engineer вы регистрируетесь и начинаете работу в условной компании xFusionCorp, которая ведёт веб проект Nautilus. Регистрация бесплатная. Не нужны никакие подтверждения телефона и кредитки. Каждый день вы будете получать по одному новому заданию для решения какой-то задачи.

После регистрации зайдите сразу в раздел Project Details и посмотрите обзорное видео, где вам на индусском английском расскажут, как тут всё устроено. Можно послушать с переводом в Яндекс.Браузере. Будет всё понятно. Там же посмотрите схему всего проекта. В разделе Wiki откроется страница с текстовым описанием инфраструктуры, где в том числе будут перечислены все сервера, их ip адреса и учётные записи для подключения. Все подключения осуществляются через jumphost.

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

В проекте по Linux в первый день вам дадут выполнить 3 задания. Они простые. За каждое задание вам начисляют некоторое количество монет. Эти монеты можно потратить на открытие других заданий. Каждое новое задание открывается раз в день. Соответственно, тут же понятна монетизация - тариф PRO снимает это ограничение и вы можете проходить задания без задержек и накопления монет.

Помимо проекта Linux, там присутствуют задачи на тему Ansible, Docker, Kubernetes, Git, Jenkins. В бесплатном тарифном плане одновременно могут быть активны 2 проекта с заданиями.

Платформа прикольная. Обновление личного кабинета сделало её ещё более интересной. Ограничение в виде одного задания в день выглядит не сильно напрягающим. Можно не суетясь понемногу выполнять задания.

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

Вот примеры бесплатных курсов:
⇨ Linux Challenges
⇨ Shell Scripts for Beginners
⇨ Advanced Bash Scripting
⇨ Linux Professional Institute LPIC-1 Exam 101
⇨ Terraform Challenges
⇨ Docker Training Course for the Absolute Beginner
И т.д. Курсов много, с теорией, видео, лабораториями.

#обучение

​​Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.

Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:

# apt install privoxy

Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.

Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb
HTTP request sent, awaiting response... 403 Forbidden

Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:

# ssh -L 3128:localhost:8118 root@1.2.3.4

Проверяем, что порт проброшен:

# ss -tulnp | grep 3128
tcp  LISTEN 0   128    127.0.0.1:3128    0.0.0.0:*  users:(("ssh",pid=1350,fd=5))

Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:

use_proxy=yes
http_proxy=127.0.0.1:3128
https_proxy=127.0.0.1:3128

И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.

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

# mkdir -p /etc/systemd/system/docker.service.d
# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:3128"
Environment="HTTPS_PROXY=http://127.0.0.1:3128"

 # systemctl daemon-reload
 # systemctl restart docker

Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:

# systemctl show --property=Environment docker
Environment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128

Теперь можно забрать образ последней версии и запустить его:

# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2
# docker run -d -e "discovery.type=single-node" \
  -p 9200:9200 \
  -p 9300:9300 \
   docker.elastic.co/elasticsearch/elasticsearch:8.13.2

После того, как всё скачано и запущено, настройки прокси можно отключить.

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

#elk #ssh #docker

​​📱Для централизованного управления устройствами под Android существует бесплатная система с открытым исходным кодом Headwind MDM. В целом это облачная система с различными тарифными планами. Но если у вас есть желание установить систему управления на своё железо, то такая возможность тоже есть. Её функциональность будет ниже (возможности бесплатной версии), чем в платных тарифах облака, но в целом там много возможностей, которых многим может быть достаточно.

Когда я впервые посмотрел на Headwind MDM, инструкцию по установке и видео процесса, подумал, что тут придётся пуд соли съесть, чтобы настроить. Там в составе и tomcat, и postresql, и доменное имя нужно с сертификатом. Но на деле всё оказалось очень просто. Установил сходу с первого раза.

Для установки воспользовался инструкцией с сайта и повторил копипастом. Взял виртуалку с Ubuntu 22, настроил доменное имя, обновил DNS. Скрипт-установщик всё сделал сам. Все параметры я выбрал по умолчанию. Предварительные настройки сделал по инструкции. Веб панель заработала.

А вот дальше у меня получился затык. Идея этой системы такая. Вы сбрасываете смартфон к заводским настройками. Начиная с 7-й версии Android есть возможность после сброса настроек вызвать специальное меню для установки приложения администратора, которое сможет управлять устройством. Для этого надо на первом экране приветствия после сброса настроек нажать 7 раз на экран. Откроется сканер QR кода. Нужно отсканировать код, который можно получить в панели управления Headwind MDM.

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

У меня был свободен смартфон, который я хотел подключить к Headwind MDM, чтобы попробовать управление. К сожалению, этим смартфоном оказался Xiaomi Redmi с родным лаунчером MIUI, который блокирует установку приложения управления после сброса настроек. Другого смартфона не оказалось, который я смог бы сбросить. Так что возможность управления я не проверил. Но почему-то кажется, что там всё будет работать. Вот несколько видео, как всё это выглядит на практике:

▶️ Installing Headwind MDM on Google Pixel 5A (Android 13)
▶️ Управление корпоративными Android-приложениями в оболочке Headwind MDM
▶️ Headwind MDM Web Console: full UI overview

Для того, чтобы всё это попробовать, не обязательно разворачивать сервер у себя. Можно зарегистрироваться в облаке и потестировать на бесплатном тарифном плане. Главное, чтобы был смартфон, который можно обнулить, чтобы установить управляющее приложение. Можно и без него, воспользовавшись обычным apk приложением, установленным в системе. Но его возможности будут ограничены. Например, нельзя будет установить или удалить приложение без подтверждения пользователя.

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

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

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

#android

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

🟡 Установка Docker:

curl -o - https://get.docker.com | bash -

🟡 Запуск контейнера в режиме службы на конкретном порту с автоматическим запуском при загрузке сервера:

docker run -d -p 80:80 --restart always --name nginx-proxy nginx

🟡 Просмотр списка запущенных и всех контейнеров:

docker ps
docker ps -a

🟡 Удаление остановленного или работающего контейнера:

docker rm nginx-proxy
docker rm -f nginx-proxy

🟡 Остановить и удалить все контейнеры:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

🟡 Просмотр образов, удаление одного или сразу всех:

docker images
docker rmi nginx
docker rmi $(docker images -a -q)

🟡 Вход в консоль контейнера:

docker exec -it nginx-proxy bash

🟡 Просмотр всех логов контейнера, 100 последних строк или следить за ними:

docker logs nginx-proxy
docker logs -n 100 nginx-proxy
docker logs -f nginx-proxy

🟡 Статистика потребляемых ресурсов контейнера или группы контейнеров:

docker stats nginx-proxy
docker stats prometheus exporter
docker stats prometheus --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

🟡 Просмотр запущенных процессов в контейнере:

docker top nginx-proxy

🟡 Информация о контейнере и пример выборки из неё разными способами:

docker inspect nginx-proxy
docker inspect -f '{{ .NetworkSettings.Networks.bridge.IPAddress }}' nginx-proxy
docker inspect --format '{{json .Mounts}}' grafana | jq .

🟡 Проверить занимаемое место докером:

docker system df

🟡 Очистить неиспользуемые данные:

docker system prune

🟡 Скопировать файл с контейнера на хост и наоборот:

docker cp nginx-proxy:/etc/nginx/nginx.conf ~/nginx
docker cp ~/nginx/nginx.conf nginx-proxy:/etc/nginx

🟡 Экспорт файловой системы контейнера:

docker export nginx-proxy -o ~/nginx-proxy.tar.gz

📌 Заметки по теме:

🔥 Portainer - веб панель для Docker
▪️ Локальный репозиторий docker образов - Nexus
▪️ Работа Docker daemon через http proxy
▪️ Дебаг контейнеров с помощью Network-Multitool
▪️ Диагностика работы контейнеров с помощью cdebug
▪️ Доступ к Docker daemon socket извне
▪️ Посмотреть, с какими параметрами был запущен контейнер
▪️ Линтер для Dockerfile - Hadolint
▪️ Sinker - синхронизации образов Docker из одного репозитория в другой
▪️ Дамп mysql базы из докер контейнера

📊 Мониторинг одиночного хоста с Docker
📊 Сtop - top для контейнеров
📊 Мониторинг Docker с помощью Zabbix

🛡 Рекомендации CIS по настройке Docker
🛡 Автоматическое исправление уязвимостей с помощью Copacetic
🛡 Проверка образов на уязвимости с помощью Trivy
🛡 Проверка образов с помощью Dockle
🛡 Заблокировать на файрволе доступ к контейнерам извне

🎓 Основы Docker. Большой практический выпуск для новичков
🎓 Бесплатный тренажёр для изучения Docker
🎓 Отличия Docker от LXC

🗃️ Бэкап вольюмов с помощью Docker-volume-backup
🤔 Docker Desktop for Windows

#docker #подборка

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

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

А окончательно тебя добивает средство устранения неполадок, которое никогда ничего не исправляет. Или база знаний по ошибкам обновления Windows, которая по полученной ошибке никогда ничего не находит.

Складывается такое ощущение, что там сидит отдельный отдел по бесполезным штукам и внедряет их.

#мем

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

В феврале и марте я почти на 2 месяца уезжал лечить МФС в Кисловодск к Тарасенко Алексею. Я посчитал, что это лучший специалист по лечению мышц из тех, что я смог найти. Каждый будний день ходил к нему на процедуры. Всего прошёл в сумме 35 процедур миопрессуры.

Процедуры ОЧЕНЬ болезненные. Мышцы, поражённые триггерной болезнью, сильно реагируют на надавливание или проколы триггеров. Я такую боль никогда в жизни не испытывал. Иногда можно было терпеть, иногда не мог сдержать крик, особенно когда работали с поясницей. Приходил с самодельным кляпом. Примерно представить, как это выглядит, можно по этому фрагменту ролика. И так примерно 30-40 минут. В самые болючие дни подо мной лужа пота после процедуры оставалась.

Полностью посещение выглядит так. Тебе 30-40 минут очень интенсивно проминают мышцы, работая с проблемными зонами. Потом 10-15 минут прогревание проработанной зоны. Потом очень жёсткое растягивание. Задача - вернуть растяжку в физиологическую норму.

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

Лечение очень эффективное. Пожалуй, впервые за много лет я реально прошёл лечение, которое не сняло симптомы, не принесло временное облегчение, а реально помогло. Я как минимум избавился от всех болей. Очень сильно улучшилась растяжка. Самые большие проблемы у меня с шеей. Тут не удалось на 100% добиться желаемого результата, но он всё равно очень хороший. Почти полностью вернулся нормальный объём движений головой. Я спокойно поворачиваю головой в обе стороны без ограничений, могу заглянуть за спину. Почти достаю подбородком до груди. До лечения был сильно ограничен в движении. Часто подворачивал корпус, чтобы посмотреть в сторону.

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

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

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

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

Продолжение 👇👇👇

#разное #здоровье #спина

Продолжение. Начало 👆👆👆

Материала много в голове, но всё описывать довольно трудно. Надо много времени. К тому же всё уже описано и рассказано в интернете. Сейчас сделаю список ссылок на материалы по МФС или триггерной болезни мышц, которые смотрел сам и посчитал полезными.

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

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

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

Истории болезни:
◽Конкин Эдуард
◽Тарасенко Алексей (он сам бывший больной, я лечился у него)
◽Бобырина Наталья
◽Ожегов Дмитрий
◽Дания Доллинг (у неё показан хороший комплекс растяжек для дома)
◽Мельник Ирина
◽Мамедов Таир (тот, что из Камеди клаба)
◽Мурат Ушанов (сделал операцию по удалению грыжи, но вообще не помогло)
◽Максим, 2 видео: как лечился по Епифанову и Шишонину и что в итоге помогло
◽Козлов Евгений, 2 видео: как лечился официальной медициной (перечислил все диагнозы, медицинские заведения и врачей, список огромный 😮) и как вылечился (лечился в том числе у Алексея Тарасенко, как и я)
◽Котов Денис

На каналах представленных выше людей я просмотрел все видео, которые имеют отношение к МФС и лечению. Ниже дополню список теми людьми, которые занимаются лечением, и у которых тоже есть каналы с полезной информацией. Я просмотрел их все, полностью.

▪️ Лукьянов Андрей Петрович - тут структурированно и обоснованно дана вся база по триггерной болезни мышц. Изучение стоит начать отсюда, со старых видео. Я заказал и прочитал две его книги: Позвоночник. Величайшее заблуждение в медицине, Новый взгляд на идиопатический сколиоз. Практически все практикующие миопрессурщики пытаются работать по его методике с разной степенью успешности. Реальных учеников у него было немного. Тарасенко Алексей один из них. Они вместе работали в клинике около года.
▪️ Яковенко Владимир
▪️ Прошкин Евгений - тут очень много теории и практической информации по самостоятельному лечению. Он ещё любит всяких шарлатанов разоблачать. Вот его видео, где он ловит на противоречиях Епифанова. Я Епифанова немного смотрел, но потом понял, что он просто балаболит ни о чём. Прошкину врачи сделали 3 (❗️) операции по удалению грыжи, ни одна не помогла.
▪️ Александр, Барнаул
▪️ Эдуард, Елабуга

Думаю, этого достаточно. По этим ссылкам есть всё, что только можно узнать о МФС или триггерной болезни мышц и лечении.

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

❗️Если вам предлагают операцию по удалению грыжи, не соглашайтесь, пока не изучите представленные материалы. Хотя бы канал и книги Лукьянова прочитайте. Чаще всего операция по удалению грыжи не помогает решить проблему, но не всегда! (пример, где помогла и была обязательна)

#разное #здоровье #спина

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

У меня сайт чётко ориентирован на IT тематику. Нет никаких других тем. Случайный человек туда вряд ли зайдёт. Так что почти все посетители это айтишники. Это подтверждает и ТОП страниц по посещаемости. Там строго Linux и Mikrotik. Посмотрим, какие системы и браузеры они используют. Период возьму последний квартал.

📌 Операционные системы:
◽Windows - 64,6%
◽Android - 16,7%
◽Linux - 8,59%
◽MacOS - 5,01%
◽iOS - 5,08%

Так что большинство обычных айтишников сидят на винде. Но стоит отдать должное. Процент Linux немал. Среди обычных пользователей он будет значительно меньше.

📌 Браузеры:
◽Chrome - 38%
◽Яндекс.Браузер - 19,5%
◽Firefox - 9,73%
◽Chrome Mobile - 12,2%
◽Edge - 5,76%
◽Opera - 4,15%

Большой % пользователей Яндекс.Браузера. У меня это тоже основной браузер. Среди всех современных форков Chromium лично я считаю его самым самобытным (насколько может быть им форк) и функциональным. В нём много интересных решений, которых нет у других.

📌 Разрешение дисплея:
◽1920 - 43,4%
◽1536 - 8,35%
◽2560 - 6,32%
◽набор мобильных разрешений - 10,56%
◽1280 - 3,97%
.....................
◽3440 - 1,11%
.....................
◽3840 - 0,18%

К недавнему обсуждению мониторов. 4К разрешения почти не встречаются. Подавляющее большинство сидит либо на FullHD, либо на разных ноутах с ещё меньшим разрешением.

📌 Смартфоны (21,4% всех посещений):
◽Xiaomi - 6,17%
◽Apple - 4,93%
◽Samsung - 3,4%
◽Realme - 1,16%

Больше ничего интересного там не увидел. Выборка получилась довольно обширная, так как за квартал на сайт зашли ~255 000 уникальных пользователей.

#разное

​​Давно не писал ничего про Zabbix. Всё жду, когда выйдет обещанная 7-я версия, а её всё нет. Решил навести справки, почитать имеющуюся информацию. От Zabbix последнее время мало новостей, так что я и следить перестал.

🔹Основная новость в том, что Zabbix, как и многие другие open source проекты в последнее время, изменил свою лицензию. Об этом была заметка в блоге от владельца компании. Расскажу, в чём суть замены лицензии GPL на AGPL и что это означает на практике.

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

AGPL убирает такую возможность. Если вы продаёте какой-то сервис, к примеру, по модели saas, где используется продукт с лицензией AGPL, вы обязаны опубликовать исходники своего сервиса. В целом, выглядит вполне логично для авторов продукта. По такой же схеме в своё время меняли лицензию MongoDB, Elastic, HashiCorp, Redis. Там хоть и другие лицензии используются, но общий смысл такой же и по своей сути лицензии похожи друг на друга, но со своими нюансами. Основной посыл - запретить облачным сервисам предоставлять услуги на основе open source продуктов без покупки коммерческой версии или открытия своего кода.

🔹К другим новостям. Недавно вышла версия 7.0.0beta3. В целом, релиз движется к публикации. Думаю, к лету он состоится. Изначально стояла дата Q4 2023, потом перенесли на Q1 2024, сейчас уже на Q2 2024. В целом, ничего необычного. У Zabbix релизы всегда откладываются. Кто-то уже сейчас пользуется 7-й версией. Видел такие комментарии не раз. Я так понимаю, что она вполне стабильна. Если делать новую установку, то можно уже 7-ю версию ставить.

🔹Zabbix периодически проводит вебинары на русском языке. Ближайший назначен на 2 мая, тема - Расширение возможностей Zabbix. Речь там пойдёт про userparametres и плагины агента 2. Тема полезная, если с ней не знакомы.

🔹Из последних статей в блоге была одна реально полезная. Там рассказано, как сгенерировать самоподписанный сертификат, чтобы по HTTPS ходить на веб интерфейс по DNS имени или IP адресу и не получать предупреждения браузера. Там ничего особенного, просто все команды и конфиги собраны в одно место, что удобно. Надо будет оформить в небольшую заметку. Обычно лень с этим возиться и получаешь сертификаты от Let's Encrypt. Но зачастую проще и удобнее выпустить свои с условно бесконечным сроком действия и забыть про этот вопрос.

#zabbix

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

Я обычно работаю за ноутбуком либо с постоянным подключением к сети, либо только от батарей. Если рядом есть розетка, я всегда подключаюсь к ней, чтобы иметь максимальное быстродействие. У меня редко случается, что работаю от батарей, а потом включаюсь в сеть. Но иногда бывает.

Заметил, что при смене типа питания у ноутбука моргает экран и перезапускается Explorer. Последнее время глючил блок питания (оказалось, что в разъём попала небольшая соринка, теперь у меня 2 БП), пока я его не заменил, так что наблюдал это часто. В какой-то момент мне это надоело. Решил разобраться, почему так происходит. По идее, переход на питание от батарей и обратно должен проходить плавно без видимых изменений.

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

В системе Windows эти настройки живут в Параметрах в разделе Система ⇨ Дисплей ⇨ Расширенные параметры дисплея. Отключил сеть, зашёл в этот раздел, там стояла частота 48 Гц. Поменял на 60 Гц, как стоит при питании от сети, и экран перестал моргать при смене режима электропитания. По какой причине параметры стояли разные, как я уже сказал, не знаю. Специально так не настраивал.

#железо

​​Сейчас без HTTPS не хотят работать многие сервисы. А даже если и работают, то браузеры не дадут спокойно пользоваться. Поэтому приходится получать и настраивать сертификаты, даже если большой нужды в этом нет. Особенно если ты работаешь с ним один в локальной сети, либо вообще поднимаешь временно. Я обычно получаю сертификаты let's encrypt и копирую на нужный сервер, если к нему не проброшен доступ из интернета.

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

Будем выпускать сертификат для доменного имени zabbix.internal и IP адреса 172.30.245.222. Будет работать и так, и эдак.

Выпускаем ключ и сертификат для своего CA:

# mkdir ~/tls && cd ~/tls
# openssl ecparam -out myCA.key -name prime256v1 -genkey
# openssl req -x509 -new -nodes -key myCA.key -sha256 -days 9999 -out myCA.crt

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

# openssl genrsa -out zabbix.internal.key 2048
# openssl req -new -key zabbix.internal.key -out zabbix.internal.csr

Тут тоже зададут похожие вопросы. Отвечать можно всё, что угодно. Готовим конфигурационный файл:

# mcedit zabbix.internal.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 172.30.245.222
DNS.1 = zabbix.internal

Генерируем сертификат на его основе:

# openssl x509 -req -in zabbix.internal.csr -CA myCA.crt -CAkey myCA.key \
-CAcreateserial -out zabbix.internal.crt -days 9999 -sha256 -extfile zabbix.internal.ext

Копируем сертификат и ключ в директорию веб сервера:

# mkdir /etc/nginx/certs
# cp zabbix.internal.crt /etc/nginx/certs/.
# cp zabbix.internal.key /etc/nginx/certs/.

Создаём файл dhparam, который понадобится для конфигурации Nginx:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Добавляем в конфиг Nginx в целевом виртуальном хосте:

listen     443 http2 ssl;
server_name   zabbix.internal 172.30.245.222;
ssl_certificate /etc/nginx/certs/zabbix.internal.crt;
ssl_certificate_key /etc/nginx/certs/zabbix.internal.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Перезапускаем Nginx:

# nginx -t
# nginx -s reload

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

# cp myCA.crt /usr/local/share/ca-certificates/.
# update-ca-certificates

Теперь можно браузером заходить по доменному имени или IP адресу, будет работать самоподписанный сертификат на 9999 дней без каких-либо предупреждений.

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

#webserver

​​Для того, чтобы начать собирать логи в Elasticsearch не обязательно поднимать полный ELK stack. Я сейчас кратко покажу, как быстро запустить сбор логов из Nginx в Elasticsearch помощью Vector. А в качестве веб интерфейса для работы с еластиком буду использовать легковесный Elasticvue.

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

Запускаем Elasticsearch:

# docker run -d -p 9200:9200 -p 9300:9300 \
-e "http.cors.enabled=true" \
-e "http.cors.allow-origin=http://172.30.245.222:8080" \
-e "discovery.type=single-node" \
--name elastic \
elasticsearch:8.13.0

Здесь 172.30.245.222 - это IP адрес сервера, на котором будет запущен веб интерфейс Elasticvue. В моём случае это та же машина, где запускается еластик. Дожидаемся запуска контейнера и забираем из него конфиг службы:

# docker cp elastic:/usr/share/elasticsearch/config/elasticsearch.yml ~/

Всё, что касается настроек xpack.security заменяем true на false. Возвращаем изменённый конфиг:

# docker cp ~/elasticsearch.yml elastic:/usr/share/elasticsearch/config/elasticsearch.yml

Перезапускаем контейнер:

# docker restart elastic

Дожидаемся запуска и проверяем работу:

curl http://172.30.245.222:9200

Должны увидеть информацию о кластере elasticsearch. Его имя будет docker-cluster. Запускаем тут же в докере веб интерфейс:

# docker run -d -p 8080:8080 --name elasticvue cars10/elasticvue

Этот веб интерфейс может работать как приложение на десктопе или плагин браузера. Интересная штука, кто не знаком, посмотрите описание на сайте.

Идём в веб интерфейс по IP адресу сервера и порт 8080. Настраиваем подключение к кластеру. Указываем настройки:
◽No authorization
◽docker-cluster
◽http://172.30.245.222:9200

Убеждаемся, что всё работает.

Теперь ставим Vector, который будет отправлять логи Nginx в кластер. Он, соответственно, должен быть установлен на веб сервере. Для Debian установка из пакетов такая:

# bash -c "$(curl -L https://setup.vector.dev)"
# apt install vector

Открываем конфиг /etc/vector/vector.yaml и приводим к такому виду:

sources:
 nginx_access_logs:
  type: file
  include:
   - /var/log/nginx/access.log
sinks:
 elastic:
  type: elasticsearch
  inputs:
   - nginx_access_logs
  endpoints:
   - http://172.30.245.222:9200

Следите за форматированием файла yaml. При копировании в пост она ломается. У вектора очень хорошая документация. Там есть все примеры использования. Можно у меня заметки на канале посмотреть. Было несколько штук с его настройкой. Очень приятная и легковесная программа. Я последнее время почти всегда вектором собираю логи.

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

# systemctl restart vector

По умолчанию, он пишет логи в системный syslog. Проверьте на всякий случай, что он запустился и начал отправлять логи в elastic. Идём в его веб интерфейс. Там должен появиться индекс вида vector-2024.04.22, в нём строки из лога Nginx.

Простейшие действия по управлению кластером Elasticsearch можно делать в Elasticvue. Можно обойтись и без Kibana. Вот такая простая и быстрая настройка. Если вы не отключите HTTPS и аутентификацию, то вам придётся дополнительно сделать следующее:

◽Создать пароль для пользователя elastic через команду внутри контейнера /bin/elasticsearch-reset-password.
◽Соответственно во всех запросах использовать basic аутентификацию с этой учёткой.
◽Для работы Elasticvue вам нужно будет забрать сертификат Elasticsearch из /usr/share/elasticsearch/config/certs/http_ca.crt и добавить его в доверенные CA в том браузере, где вы его будете запускать. Далее нужно будет посмотреть, какие имена хоста указаны в сертификате сервера и добавить их в hosts, чтобы браузер не ругался на несоответствие имени в сертификате и адресной строке.

Я всё это настраиваю, если надо, но занимает чуть больше времени, поэтому упростил руководство.

#elk

​​Для тестирования производительности PostgreSQL есть относительно простая утилита pgbench, которая входит в состав установки PostgreSQL. Ставить отдельно не придётся. Даже если вы несильно разбираетесь в тюнинге СУБД и не собираетесь им заниматься, pgbench хотя бы базово позволит сравнить разные конфигурации VM, разных хостеров, разное железо. Например, сравнить, на какой файловой системе или на каком дисковом хранилище будут лучше показатели быстродействия. Просто создайте две разные виртуалки и сравните.

Тест выполняет на существующей базе данных. В ней создаются служебные таблицы и наполняются данными. Покажу, как это выглядит на практике. Ставим postgresql:

# apt install postgresql

Проверяем, что работает:

# systemctl status postgresql

Создаём базу данных:

# su - postgres
$ psql
$ create database test_db;
$ \q

Наполняем тестовую базу данными, увеличив стандартный набор в 10 раз:

$ pgbench -i test_db -s 10

Запускаем тест в 5 клиентов, в 2 рабочих потока, на 60 секунд с отсечкой результата каждые 5 секунд, чтобы в консоли интересно наблюдать было. Если будете в файл выводить результаты, то это делать не надо.

$ pgbench test_db -c 5 -j 2 -P 5 -T 60

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 5
number of threads: 2
maximum number of tries: 1
duration: 60 s
number of transactions actually processed: 219950
number of failed transactions: 0 (0.000%)
latency average = 1.362 ms
latency stddev = 0.661 ms
initial connection time = 8.368 ms
tps = 3665.930847 (without initial connection time)

СУБД обработала 219950 транзакций со средней скоростью 3665.930847 транзакций в секунду. Эти данные и стоит сравнивать.

По умолчанию pgbench запускает смешанный TPC-B (Transaction Processing Performance Council) тест, который состоит из пяти команд SELECT, UPDATE и INSERT в одной транзакции. Сценарий можно менять, создавая собственные скрипты для тестирования. Все возможности pgbench подробно описаны на русском языке в документации от postgrespro.

Из любопытства перекинул тестовую виртуалку с обычного одиночного SSD на RAID10 из 4-х HDD. Настройки в Proxmox те же, кэширование гипервизора отключено (Default (No cache)). Прогнал этот же тест.

tps = 2262.544160

Получилось на ~40% медленнее при идентичных настройках.

#postgresql

​​У браузера Firefox и всех остальных, что созданы на его основе, есть отличительная особенность, которая кому-то нравится, кому-то нет. Всё зависит от ситуации. У этого браузера своё собственное хранилище сертификатов, куда можно добавлять доверенные центры сертификации, минуя системное хранилище ОС. Для централизованного управления это скорее минус, а для индивидуального использования больше плюс.

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

Уже предвещаю комментарии на тему того, что надо настраивать ACME, создавать доменные имена и получать валидные сертификаты. Либо использовать какой-то обратный прокси для получения сертификатов и проксирования запросов.

Всё это можно сделать. Но, к примеру, у меня наберётся с десяток одиночных гипервизоров, где я не буду всего этого делать, потому что нет смысла. Доступ из интернета к ним открывать не буду. Я работаю с ними один, к ним нет доступа из интернета. Они принадлежат разным проектам и не объединены между собой. Мне проще забрать с этих гипервизоров pve-root-ca.pem, добавить в браузер, чтобы не засорять систему и сохранить учётки для быстрого входа. Доступ к ним всё равно закрыт списками IP адресов на файрволе.

Для того, чтобы настроить доверие для самоподписанного сертификата Proxmox, который создаётся во время установки гипервизора, надо зайти в веб интерфейсе в раздел System ⇨ Certificates. Выбрать сертификат pve-root-ca.pem, открыть его исходный текст. Скопировать и сохранить его в любой текстовый файл, указав ему расширение .crt.

Далее идём в браузер на основе Firefox. Я использую портированный LibreWolf. Переходим в Settings ⇨ Privacy & Security ⇨ Certificates ⇨ View Certificates. Там делаем Import сохранённого сертификата. Теперь из этого браузера при входе на веб интерфейс Proxmox не будет предупреждения. У вас появится возможность сохранить данные аутентификации.

#proxmox

​​Расскажу про очень простую и функциональную систему отправки уведомлений во все современные каналы - Apprise. Она представляет из себя консольное приложение, в которое через параметры командной строки можно передавать настройки для отправки уведомлений.

Apprise поддерживает Telegram, Discord, Mattermost, NextcloudTalk, Revolt, Rocket.Chat, Slack, WhatsApp и т.д. Помимо мессенджеров сообщения можно доставлять в Syslog, Pushover, ntfy, Mailgun, обычную почту и кучу других сервисов, в том числе пуши на комп можно отправлять. Они все перечислены в репозитории. Список очень большой.

Работает это примерно так. Ставим Apprise из pip:

# apt install python3-pip
# pip install apprise --break-system-packages

Открываем репозиторий и смотрим синтаксис необходимого вам направления. Пример для Telegram:

# uptime | apprise -vv \
  'tgram://1393668911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw/211805263'

От правили вывод утилиты uptime в Telegram. Формат конфигурации такой:

tgram://bottoken/ChatID

или для нескольких чатов

tgram://bottoken/ChatID1/ChatID2/ChatIDN

Понятно, что только для Telegram это не имеет смысла. Туда можно и напрямую слать. Идея в том, что у тебя один инструмент объединяет все каналы. Можно сделать конфиг, в котором будут указаны разные каналы. Отправив информацию в apprise, он сам разошлёт по всем указанным направлениям. Ну и как плюс, более простая настройка, так как формат настроек разных направлений примерно одинаковый. Это просто удобно.

С помощью Apprise легко настроить отправку пушей через сервис pushover.net. У него бесплатный тарифный план позволяет отправлять 10,000 в месяц. Для многих задач этого будет заглаза.

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

Система простая в настройке. Не надо изучать и разбираться с API сторонних сервисов. В Apprise они уже все собраны, а работа с ними унифицирована с помощью встроенного API или конфигураций. У продукта есть подробная wiki.

⇨ Исходники / Docker

#мониторинг

​​С момента перехода на Windows 11 я неизменно страдал (не сильно) от глючащего переключения раскладки клавиатуры. Оно по неведомой мне причине иногда не срабатывало. Как-то отследить и понять закономерность не получалось. То сразу переключает, то со второго или третьего раза.

Терпел я это долго, так как с наскока не получалось решить проблему. Причём переключение по комбинации клавиш win+пробел срабатывало всегда. А по настроенному мной левому ctrl+shift через раз. Так как я использую Punto Switcher, то выходил из ситуации относительно просто. Автоматом менял раскладку уже напечатанного текста, когда не сработало переключение.

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

⇨ https://www.elevenforum.com/t/horrible-keyboard-input-language-switch-lag-after-win-11-22h2-update.11418/

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

Адекватного решения проблемы средствами Windows, как я понял, не существует. Люди просто отключают переключение раскладки в винде и переключают раскладку сторонним софтом. Я так и сделал. Включил переключение раскладки по кнопке Caps Lock через Punto Switcher. Я всё равно её не использую. Так переключать даже удобнее. Уже привык.

Сколько сюрпризов и неудобств привнесла Windows 11. Если бы знал о них заранее, оставался бы на десятке. Я тут кое о чём писал уже. Например, о неработающей аутентификации с учётной записью Администратор, или о невозможности перенести панель задач на правую сторону экрана.

#windows

​​На днях вышло обновление Proxmox 8.2, в котором появилось несколько интересных нововведений. Самое полезное на мой взгляд - импорт виртуальных машин из VMware ESXi. Я не сразу понял, как это реализовано. Обновил тестовый гипервизор, всё там пересмотрел и не нашёл импорт. Полез в документацию.

1️⃣ Работает он следующим образом. В списке Storage, доступных для добавления, появился новый тип - ESXi. Для добавления нужно указать его адрес и рутовую учётку. После этого в списке этого хранилища будут отображаться виртуальные машины хоста ESXi, откуда можно быстро выполнить импорт. Сделано удобно с минимум необходимых телодвижений. Жду, когда то же самое появится для Hyper-V. Лично для меня это более актуально.

2️⃣ Второе значительное изменение - появилась возможность в качестве встроенного файрвола использовать nftables, а не iptables. Пока это надо явно включить. Переход на nftables только прорабатывают, собирают обратную связь. В будущих релизах он заменит iptables окончательно. Так что можно потихоньку переползать. Кто не знаком с nftables, у меня есть небольшая статья по базовым правилам.

3️⃣ Третье важное дополнение. В настройках встроенных бэкапов появилась новая вкладка Advanced с дополнительными настройками процесса снятия бэкапов. Туда переехали настройки по ограничению ширины канала при бэкапе. А также добавилась новая настройка Backup fleecing, которая включает режим буферизации на локальный диск. Перед передачей на внешнее хранилище, бэкап работающей машины может кэшироваться на отдельном локальном storage, который можно выбрать из подключенных. Это снизит нагрузку на работающую VM во время снятия бэкапа и в целом ускорит процесс, так как кэшировать можно на наиболее ненагруженное хранилище. Возможно будет иметь смысл выделить отдельное хранилище под это дело.

Остальные изменения не такие существенные, поэтому перечислю их кратко:
◽появилась утилита proxmox-auto-install-assistant для подготовки установочного образа с готовыми настройками для установки без участия человека;
◽в веб интерфейс добавлена возможность настройки проброса устройств в lxc контейнеры;
◽в настройках ACME можно добавить любой другой удостоверяющий центр, отличный от Let's Encrypt;
◽изменились некоторые настройки веб интерфейса: не активируется режим редактирования полей при попытке скопировать данные оттуда, актуально, к примеру, для поля Notes с описанием VM, также изменилось положение кнопки с отменой введённых настроек.

Посмотреть, как все изменения выглядят в веб интерфейсе, можно вот в этом видео:

▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/whats-new-in-proxmox-ve-8-2

Нравится, как команда Proxmox оформляет все свои обновления. Максимально подробно и текстом, и в виде роликов. Другим компаниям бы брать пример.

#proxmox

​​В продолжение темы с уведомлениями в Apprise. Есть продукт на его основе, который умеет конвертировать email сообщения в уведомления apprise. Называется Mailrise. По своей сути это SMTP gateway для apprise.

Он поднимается как обычный SMTP сервер. Принимает сообщения и переадресует их в зависимости от настроек в необходимые каналы уведомлений. И речь тут может идти не только об уведомлениях в мессенджеры, смс, пуши и т.д. Например, mailrise может отправить email в формате JSON через HTTP POST запрос. Может в Syslog сделать запись с заголовком и текстом письма, может переслать на другой SMTP сервер. Продукт универсальный.

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

Покажу на примере, как это работает. Для начала установим Mailrise. Сделать это можно либо через pip, либо запустить в Docker. Я беру второй вариант, поэтому сразу подготовим конфигурационный файл, который мы передадим в контейнер.

Я буду принимать почту и отправлять уведомление в Telegram и Syslog. Для этого готовлю такой конфиг mailrise.conf в формате yaml :

configs:
 telegram:
  urls:
   - tgram://1393668911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw/211805263
 rsyslog:
  urls:
   - rsyslog://172.30.245.222

Запускаю контейнер с указанным конфигом:

# docker run -d -p 8025:8025 --restart always \
-v ~/mailrise/mailrise.conf:/etc/mailrise.conf \
--name mailrise \
yoryan/mailrise

Почтовый сервер готов принимать почту на порту 8025. Отправляю тестовое сообщение. Проще всего это сделать через PowerShell:

> send-mailmessage -from "admin@local" -to "Telegram <telegram@mailrise.xyz>","Rsyslog <rsyslog@mailrise.xyz>" -subject "Message from Mailrise" -body "Test Message" -smtpserver 172.30.245.222 -port 8025

В данном случае адреса telegram@mailrise.xyz и rsyslog@mailrise.xyz вымышленные. Имеет значение только название перед @. Оно должно соответствовать названиям конфигов в mailrise.conf. То есть если отправить почту только на telegram@mailrise.xyz, то оповещение придёт только в Telegram. То есть вот так:

> send-mailmessage -from "admin@local" -to "Telegram <telegram@mailrise.xyz>" -subject "Message from Mailrise" -body "Test Message" -smtpserver 172.30.245.222 -port 8025

В Linux через консоль с указанием релея отправки проще всего использовать ssmtp. Для этого её надо установить и нарисовать простой конфиг:

# apt install ssmtp

В конфиг /etc/ssmtp/ssmtp.conf пишем:

root=admin@local
mailhub=172.30.245.222:8025
hostname=debian12.homelab.local

Отправляем почту через mailrise:

# echo "Test Message" | mail -s "Message from Mailrise" telegram@mailrise.xyz rsyslog@mailrise.xyz

Оповещение прилетит в Telegram и Rsyslog. В последнем будет примерно такая запись в логе:

2024-04-25T14:55:20.717270+03:00 172.17.0.2 - 1 - Message from Mailrise (admin@local): Test Message

Соответственно, можно указать отдельный facility и настроить в rsyslog.conf приём этих уведомлений в отдельный файл.

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

Если нужна аутентификация, то добавить её можно следующими настройками в конфиге:

smtp:
 auth:
  basic:
   user01: password01

⇨ Исходники / Видеообзор

#mailserver

​​Пока прошлые статьи писал про сертификаты и Proxmox, возник вопрос. А как добавить в доверенные сертификат от Proxmox Backup Server, чтобы браузер не ругался? У него почему-то нет CA сертификата в веб интерфейсе, как в VE, который можно добавить в доверенные.

Немного поискал информацию и нашёл в официальной wiki на эту тему отдельную статью. Меня в ней привлекло вот что. В самом конце рассматривается случай, когда PBS и VE стоят на одной машине (Using Certificates from Proxmox VE). Авторы предлагают для PBS использовать тот же сертификат, что и для VE.

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

Пошёл смотреть документацию по установке PBS. Там есть отдельный раздел Install Proxmox Backup Server on Proxmox VE. Так что технически никаких проблем нет. Можно ставить PBS на хост виртуализации. Есть единственное предупреждение:

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

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

В целом, я бы всё же не рекомендовал ставить на один хост и PBS, и VE. Мне кажется, лучше в виртуалке (или в lxc) поднимать. Я не сторонник что-то настраивать на самих гипервизорах. Тогда они становятся невзаимозаменяемыми. Если есть возможность, лучше всё переносить в виртуальные машины. Если умрёт сервер, то простое восстановление виртуальных машин из бэкапа вернёт всю функциональность. А если что-то на гипервизоре настроено, то надо восстанавливать, и предварительно бэкапить, его настройки. Где-то это может быть оправдано, где-то нет.

Я если что-то и делаю на гипервизоре, так это только iptables настраиваю с nat. Все настройки - это единственный конфиг для iptables. Нетрудно сохранить.

#proxmox

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

⇨ Протокол HTTP | Компьютерные сети 2024 - 10
Очередной урок с обновлённого курса по сетевым технологиям от Андрея Созыкина. Коротко, доступно и наглядно дана база.

⇨ Best Docker Containers in 2024
Обзор Docker контейнеров для дома, которые автор посчитал полезными в повседневной жизни. Среди них Plex, Pi-Hole, Dashy, Uptime Kuma, Mailrise, Adguard Home и другие.

⇨ Мониторинг веб-сервера Angie с помощью Prometheus
Разбор мониторинга Angie через готовый экспортер Angie и их же дашборда для Grafana. Очень простая и лёгкая настройка. Я его уже тоже попробовал и написал заметку.

⇨ Web logs are super easy with - GoAccess
Обзор удобной и функциональной утилиты GoAccess для просмотра логов веб сервера через веб интерфейс. Утилита известная, я делал про неё заметку. Если не знакомы - посмотрите и возьмите на вооружение. Логи в ней смотреть - одно удовольствие.

⇨ Prometheus - Все Основы Мониторинга, как всё это работает и зачем он вообще нужен?
⇨ Prometheus - Как установить Prometheus Сервер на Линукс?
⇨ Prometheus - Как установить Node Exporter на Linux серверах?
На канале ADV-IT вышли три ролика на тему Prometheus. Автор снимает отличные ролики. Так как живёт в Канаде и работает там же, большинство его проектов в облаке AWS, так что последнее время его видео были для меня неактуальны, не смотрел. А эти уже в тему. Посмотрел с удовольствием. Там база для новичков.

⇨ Zstd (Zstandard): новый стандарт сжатия текста. Полный тест
Стандарт сжатия zstd можно использовать на веб серверах. В Angie есть готовый модуль, так что настроить очень просто. В видео автор рассматривает этот метод, его настройку и сравнивает с существующими популярными методами gzip и brotli для динамического сжатия. Zsdt показал очень хороший результат. По этому ролику сделаю отдельную заметку.

⇨ Trigkey S7 Pro Review runs VMware and Proxmox perfectly // Home Lab Server
Обзор производительного неттопа на базе AMD Ryzen 7. Сначала подумал, что какая-то дорогая экзотика, но на самом деле нет. Голый, без памяти и дисков, на али стоит в районе 20 т.р. Хорошее решение для тестового гипервизора домой.

⇨ QoS: управление сетевым трафиком, маркировка и приоритизация
Длинный вебинар про QOS в Микротике. Я его не слушал, пролистал. Знаю, что у этого автора всегда хорошие видео, так что если вам интересная данная тема, в том числе и подробная теория по ней, то рекомендую.

⇨ More POWER for my HomeLab! // Proxmox Cluster
Автор первый раз собрал свой кластер Proxmox и рассказал об этом. Добавил вторую ноду к основному серверу. Рассказал, как разбирался, как настраивал, как ошибки исправлял. Показал, как работает живая миграция без остановки VM. Буквально 3 пакета ping теряются во время перехода с одной ноды на другую.

#видео