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

Из основных нововведений отмечу парочку самых значимых:
◽Появился Marketplace интеграций, где их уже более 800.
◽Добавили удобный обзор логов systemd journal.

Посмотреть на этот мониторинг можно через публичный Demo:
⇨ https://app.netdata.cloud/spaces/netdata-demo

Покажу на примере, как быстро и легко установить Netdata на одиночный сервер. Устанавливаем на любой Linux:
# curl https://my-netdata.io/kickstart.sh > /tmp/netdata-kickstart.sh
# sh /tmp/netdata-kickstart.sh
Установка будет из deb/rpm пакетов, если они есть под вашу систему. Если нет, будут использованы static builds или сборка из исходников.

После установки можно сразу идти браузером на ip сервера и порт 19999. По умолчанию аутентификации нет. Сразу же увидите базовые метрики. Можно оценить, как это выглядит и работает.

Допустим, у вас на этом сервере работает Nginx и мы хотим его мониторить. Идём в раздел Integration и ищем Nginx. Видим подробную инструкцию. Нам надо включить вывод статистики Nginx через модуль ngx_http_stub_status_module. Для этого добавляем в конфиг Nginx виртуального хоста default:

location = /basic_status {
stub_status;
}

Перечитываем конфигурацию:
# nginx -s reload

Настраиваем Netdata:
# cd /etc/netdata && ./edit-config go.d/nginx.conf

Можно ничего не редактировать, а сохранить конфиг как есть. Перезапускаем Netdata:
# systemctl restart netdata

Идём в веб интерфейс, открываем хост local, справа в столбце Overview выбираем раздел Nginx и смотрим доступные метрики.

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

Поддержка Windows тоже есть. Работает она следующим образом. На Windows ставится Prometheus exporter for Windows. На любом Linux хосте с установленным Netdata настраиваем:
# cd /etc/netdata && ./edit-config go.d/windows.conf
Добавляем в самый конец:
jobs:
 - name: win_server1
  vnode: win_server1
  url: http://172.27.49.225:9182/metrics
Указанный url это метрики экспортера. После установки он автоматически запускается, можно проверить браузером, только не забудьте файрвол настроить. Далее создаём файл /etc/netdata/vnodes/vnodes.conf
- hostname: win_server1
 guid: fda4c985-1ce4-4e74-aaec-93a5365bac36
guid смотрим на Windows в консоли poershell:
> [guid]::NewGuid()

Перезапускаем netdata и видим в веб интерфейсе новый Windows сервер в разделе Nodes. Получилась краткая инструкция по настройке Netdata. Можно сохранить.

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

#мониторинг #netdata

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

При этом для Linux такого изобилия не припоминаю. Из того, что использовал лично - Frenzy во времена Freebsd. Связано это скорее всего с тем, что практически любой образ c Linux можно загрузить в режиме Live CD и сделать всё, что нужно. То есть берём базовый ISO для Debian, загружаемся в Live режиме. Если есть сеть, настраиваем её, и устанавливаем необходимый софт. Для реанимации системы чаще всего ничего устанавливать не надо, так как обычно достаточно проверить диски, загрузчик, пересобрать initramfs, обновить или установить какой-то драйвер.

Отмечу один известный мне загрузочный образ на базе Linux, ориентирующийся на восстановление системы - SystemRescue. Его часто можно увидеть у хостеров как один из вариантов загрузки системы, если загрузка с основного диска не работает и система не стартует.

По сути это обычный Linux с предустановленным набором софта, который может понадобиться для восстановления работы системы или восстановления данных. Полный список установленных пакетов представлен на сайте. Например, упоминаемый ранее whdd там тоже присутствует, как и clonezilla, memtest86, rclone и многие другие.

SystemRescue собран на базе Arch Linux, в качестве графического окружения используется xfce. В составе сборки есть сервер x11vnc, так что можно загрузиться и предоставить доступ к окружению по сети, если ssh будет недостаточно.

Данный образ можно использовать не только для систем на базе Linux, но и для Windows. Например, можно загрузиться, настроить сеть, подмонтировать (примонтировать?) ntfs диски и скопировать куда-то информацию. Или ту же проверку дисков сделать с помощью whdd.

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

#linux #restore

​​Популярный вопрос по поводу OpenVPN. Как на одном сервере с несколькими внешними IP адресами настроить независимую работу VPN на каждом IP адресе. Сделать это очень просто. Фактически, это штатная работа службы OpenVPN, даже ничего колхозить не придётся.

Настраиваете OpenVPN как обычно для одного IP адреса. Допустим, вся конфигурация у вас описана в /etc/openvpn/server/server1.conf. Запускаете вы этот сервер так (если установили в Debian из базовых реп):
# systemctl start openvpn-server@server1.service

Теперь добавим ещё один сервер и запустим 2 экземпляра OpenVPN, каждый на своём внешнем ip. Для этого в конфигурацию server1.conf добавляем параметр local, указав внешний IP адрес, и сразу обозначим tun интерфейс, на котором он будет работать и адресное пространство этого туннеля:
local 1.2.3.4
dev tun1
server 10.8.1.0 255.255.255.0

Копируем этот конфиг для запуска второго сервера:
# cp server1.conf server2.conf
В него добавляем свои параметры:
local 4.3.2.1
dev tun2
server 10.8.2.0 255.255.255.0

Все остальные настройки могут быть как идентичными первому серверу, в том числе использовать те же сертификаты и CA, так и совершенно разными. Они между собой никак не будут связаны. Это будут два отдельных сервера OpenVPN. Запускаем второй сервер:
# systemctl start openvpn-server@server2.service

Проверяем:
# ip a | grep 'global tun'
  inet 10.8.1.1/24 scope global tun1
  inet 10.8.2.1/24 scope global tun2

# netstat -tulnp | grep openvpn
udp    0   0 1.2.3.4:1194     0.0.0.0:*              1330/openvpn     
udp    0   0 4.3.2.1:1194   0.0.0.0:*              1321/openvpn     

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

#openvpn #vpn

На днях увидел любопытную новость: Сисадмин оборонного предприятия получил условный срок за использование бесплатного ПО. Заинтересовался темой. Сразу скажу, что заголовок не отражает сути уголовного дела. Условку сисадмин получил не за бесплатное ПО. Его тут приплели только для кликбейтного заголовка. Я посмотрел материалы дела и расскажу вам, что там было на самом деле. Тема любопытная, её полезно знать.

На оборонном предприятии использовался Cisco Secure ACS. Руководитель поручил в 2020 году сисадмину проработать вопрос замены этого программного продукта. Инфраструктура, с которой работал сисадмин, относилась к критической информационной инфраструктуре Российской Федерации с определёнными правилами доступа. Прямого подключения к интернету не имела. То есть была изолированным сегментом сети.

Сисадмин взял роутер Mikrotik, подключил его в стойке к кабелю с доступом в интернет. Поставил на свой компьютер Winbox, настроил на Микротике доступ в интернет, и на своём компьютере соответственно. Далее скачал из интернета Centos 8 (почему-то через torrent клиент), развернул его на виртуальной машине во внутренней сети, а конкретно на своём компьютере, установил туда free-RADIUS. Далее на этой виртуалке прописал прокси сервер, который поднял на Микротике, и выходил в интернет через него. Доступ к Микротику был также настроен из его дома.

В оригинале приговора всё это подробно описано, в том числе объяснения самого сисадмина. Было любопытно почитать столько технических подробностей в судебных документах. К примеру, там было и вот это:

Также, Есин А.Е. использовал чат для связи с супругой на своем служебном компьютере посредством программного обеспечения Lite Manager Free. Из полученных от Есина А.Е. объяснений следовало, что он настроил на маршрутизаторе MikroTik № веб-приложение, выступающее в роли посредника для доступа к сети Интернет с закрепленного за ним ПЭВМ №. Имея расширенные административные права на вышеуказанном ПЭВМ, Есин А.Е. установил По Lite Manager Free для обмена мгновенными сообщениями с супругой. Таким образом, Есин А.Е. нарушил требование главы 6 положения «О порядке работы в ИВС» от ДД.ММ.ГГГГ

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

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

#разное

​​В заметке про программы для рисования схем инфраструктуры посоветовали сервис excalidraw.com. Я про него не знал, но когда посмотрел, увидел, что подобные схемы мне знакомы. Я видел этот стиль, но не знал, где они нарисованы.

Мне понравилось, как выглядят схемы, нарисованные в excalidraw.com. Сразу решил попробовать в деле и нарисовал частичную схему одного из проектов. Результат смотрите в приложенной картинке. Мне лично нравится, как получилось. Возможно кому-то покажется это несерьёзной, мультяшной стилистикой. Дело вкуса и места применения. Для моих задач такие схемы вполне уместны.

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

Как вам такая схема?

#схемы

​​Я давно слышал информацию об Альт Сервер Виртуализации, но до конца не понимал, что это такое. Решил разобраться. Из описания не совсем понятно, что на практике из себя представляет этот продукт. В описании видно, что он почти полностью состоит из open source компонентов и это не скрывается. Но при этом продаётся за деньги, хоть и относительно небольшие.

Я решил развернуть его у себя в редакции кластер виртуализации PVE. Помимо него есть ещё три:
◽базовый гипервизор KVM;
◽облачная виртуализация OpenNebula;
◽контейнерная виртуализация (LXC/LXD, Docker/Podman).

Установщик полностью на русском языке. Используется один ISO образ для всех редакций, которые можно выбирать в процессе установки. Помимо основных пакетов, можно выбрать дополнительные. Например, сразу установить агент мониторинга различных систем, или, к примеру, nginx сервер для проксирования, rsyslog, HAProxy для отказоустойчивого веб интерфейса и некоторый другой популярный софт.

У установщика есть широкие возможности по разбивке диска, что встречается не так часто. Можно установить систему на одиночный диск, на mdadm массив, на LVM, на BTRF. ZFS почему-то в списке не было. На разделы, соответственно, тоже можно вручную разбить.

После установки я увидел обычный Proxmox. В последней версии alt-server-v-10.1 версия PVE 7.2. Из примечательного, в alt используется пакетный менеджер apt-get, а пакеты rpm. Подключены только репозитории alt. То есть привязки к инфраструктуре компании Proxmox нет. Я так понял, что все пакеты в репозитории alt собираются разработчиками дистрибутива.

Отдельно отмечу хорошую документацию по продукту на русском языке. Если вы хотите посмотреть документацию на русском языке по Proxmox или OpenNebula, можно воспользоваться этой.

Собственно, становится понятно, за что нужно будет заплатить в коммерческом использовании (для физических лиц всё бесплатно). Если вам нужен Proxmox или OpenNebula с возможностью использования там, где можно брать только отечественное ПО, то Альт Сервер Виртуализации — это ваш случай. Он есть в реестре отечественного ПО, он привязан к репозиториям alt и по идее устойчив ко всяким санкциям, ограничениям и т.д. Также можно купить техподдержку.

⇨ Сайт / Загрузка / Обзор (кластер)

#виртуализация #отечественное #proxmox

​​Вы знали, что php в своём составе имеет собственный веб сервер? Для быстрого запуска php скриптов в браузере не нужно ничего, кроме непосредственно php на сервере. Покажу сразу на примере.

Допустим, вам нужно временно запустить phpmyadmin, но не хочется для него настраивать веб сервер. Его может не быть, либо просто не хочется что-то менять в работе уже настроенного. Нет ничего проще.

Устанавливаем php и модуль mysqli для работы с mysql:
# apt install php php-mysqli

Качаем и распаковываем phpmyadmin:
# wget https://files.phpmyadmin.net/phpMyAdmin/5.2.1/phpMyAdmin-5.2.1-all-languages.tar.gz
# tar xzvf phpMyAdmin-5.2.1-all-languages.tar.gz

Запускаем веб сервер:
# cd phpMyAdmin-5.2.1-all-languages
# php -S 172.27.50.130:8080

Идём по адресу http://172.27.50.130:8080 и видим веб интерфейс phpmyadmin. Если он ещё не настроен, то надо зайти в директорию /setup/ и выполнить начальную настройку подключения. Как минимум, адрес сервера указать. Если это не первое подключение, то сразу же подключаемся к базе.

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

#php #webserver

​​Почти год назад я вам рассказывал про бесплатную open source систему контроля доступа к сервисам и системам — Teleport. У неё недавно вышло несколько крупных обновлений 13-й версии, так что я решил посмотреть на неё повнимательнее и проверить в работе.

Кратко расскажу, в чём суть этой системы. Это условно точка входа в вашу инфраструктуру. Работает в виде службы, веб сервиса и клиентов. Вы ставите Teleport на управляющий сервер, создаёте там пользователей, подключаете другие системы и сервисы. Используя двухфакторную аутентификацию с помощью OTP authenticator пользователь логинится в систему. Это может быть либо браузер, либо консольный клиент. Далее пользователь прямо через браузер может подключиться к SSH разрешённого сервера, либо с помощью специального консольного SSH клиента. Все сессии логируются и записываются. Помимо SSH поддерживаются и другие виды подключений.

Кратко покажу, как это всё развернуть и запустить в работу. Для начала устанавливаем Teleport на Linux сервер:
# curl https://goteleport.com/static/install.sh | bash -s 13.3.2

Создаём самоподписанные сертификаты для домена teleport.local, так как в примере я использую сервер в локальной сети. Можно взять бесплатные сертификаты от Let's Encrypt.
# cd /var/lib/teleport
# openssl req -x509 -newkey rsa:4096 -keyout privkey.pem \
-out fullchain.pem -sha256 -days 3650 -nodes \
-subj "/C=RU/ST=Russia/L=Moscow/O=Homelab/OU=ITdep/CN=*.teleport.local"

На выходе получите два файла privkey.pem и fullchain.pem. Используем их для создания файла конфигурации:
# teleport configure -o file \
  --cluster-name=teleport.local \
  --public-addr=teleport.local:443 \
  --cert-file=/var/lib/teleport/fullchain.pem \
  --key-file=/var/lib/teleport/privkey.pem

Запускаем службу:
# systemctl start teleport

Все клиенты должны иметь DNS запись teleport.local, чтобы обращаться к серверу Teleport только по доменному имени. Откройте в браузере страницу https://teleport.local. Если увидите окно аутентификации, значит сервис запустился. Идём обратно в консоль сервера и добавляем туда администратора системы с именем teleport-admin, разрешая ему использовать пользователя root для своих подключений. Если подключаетесь не под root, укажите своего пользователя, или перечислите их через запятую.
# tctl users add teleport-admin --roles=editor,access --logins=root

В ответ получите ссылку вида https://teleport.local/web/invite/296a7fab9182d7525a6f3f456ed3b074. Пройдите по ней. Тут нам понадобится любой OTP аутентификатор со сканером QR кода. Я стандартно взял Google Authenticator, но можно использовать любой другой. Сканируем QR код смартфоном и вводим код в поле регистрации. Пользователь teleport-admin добавлен.

Теперь можно зайти в веб интерфейс и подключиться по SSH к управляющему серверу, который по умолчанию уже добавлен. В разделе Management ⇨ Session Recordings будут записи сессий. Записывается всё, в том числе работа в MC.

Расскажу, как использовать консольный клиент для подключений по SSH. Он есть под все системы. Показываю пример с Linux. Ставим клиента:
# curl -O https://cdn.teleport.dev/teleport-v13.3.2-linux-amd64-bin.tar.gz
# tar -xzf teleport-v13.3.2-linux-amd64-bin.tar.gz
# cd teleport
# ./install

Проходим аутентификацию на сервере Teleport:
# tsh login --proxy=teleport.local --user=teleport-admin --insecure
Тут опять понадобится аутентификатор от гугла и одноразовый код. После успешной аутентификации, можно подключаться по SSH к серверу teleport.local:
# tsh ssh teleport.local

Список доступных серверов для вашей учётной записи можно посмотреть вот так:
# tsh ls
Информацию об аутентификации и время её жизни так:
# tsh status

Таким образом можно организовать безопасный и контролируемый доступ к закрытой инфраструктуре без VPN и пробросов портов. Но лучше Teleport тоже скрыть от посторонних глаз.

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

#security #управление #devops

​​Пятничная подборка на тему Хуяк-хуяк, и в продакшн.

1️⃣ Начнём с грустного артхауса. История о том, как люди стремятся всё делать хорошо и правильно, а получается как всегда и к чему это приводит:
⇨ https://www.youtube.com/watch?v=ir5rj2yYH_8

2️⃣ Переходим к теме повеселее. Неавторский клип на известную песню НТР. Видеоряд прикольный, как и песня в целом:
⇨ https://www.youtube.com/watch?v=F2skk6RFFos
Мне особенно нравится строчка:
Лет пять назад уже потерян всякий стыд - 
Мы делаем дело. Пусть криво, но стоит.

3️⃣ Анекдот с bashorg:
xxx: Мы тут случайно выяснили, что если фразу "хуяк хуяк и в продакшен" прогнать через гуглтранслейт на хинди и обратно, то получится "дураки на производстве"
yyy: СЛУЧАЙНО

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

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

#юмор

​​Последнее время всё чаще и чаще появляется информация о блокировках тех или иных VPN соединений. При этом я ни разу не слышал, чтобы уже реально блокировали технологию Shadowsocks. В связи с этим хочу вам напомнить об одном простом и удобном приложении для построения личных VPN сетей на базе Shadowsocks. Речь пойдёт про Outline-Server и Outline-Client. Добавил эти пояснения, так как при поиске Outline отсвечивает другой, более популярный продукт с таким же именем, который является менеджером заметок.

Основное удобство Outline в том, что его очень легко настроить и использовать. Для установки своего сервера достаточно взять в аренду любую VPS. Скачать себе на компьютер приложение Outline-Manager, которое автоматически подключит VPS и всё там настроит.

После этого вам достаточно установить клиент на любое своё устройство (Windows, Linux, MacOS, Android, iOS), прописать туда настройки своего сервера и пользоваться. Клиент будет автоматически заворачивать весь трафик в туннель. На выходе будет IP адрес вашего сервера. Можно купить несколько VPS в разных странах, развернуть там Outline Server, добавить их к себе в клиент и переключаться.

Справиться с настройкой сможет практически любой человек, который способен взять в аренду VPS и подключиться к нему по SSH. Outline можно рекомендовать разным людям, не только айтишникам.

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

1️⃣ Арендуем где угодно VPS. Я могу от себя лично порекомендовать хостеров serverspace.ru или ruvds.com. Не буду говорить, что они лучше других. Просто я сам их использую и меня они устраивают.

2️⃣ Скачиваем Outline Manager под свою систему. Я использовал Windows. После запуска приложения, установка будет выполнена автоматически в профиль текущего пользователя в AppData\Local\Programs\outline-manager.

3️⃣ После запуска приложения добавьте туда свой сервер. Для этого выберите самый последний пункт Настройте Outline где угодно. Вы увидите команду, которую нужно запустить по SSH в консоли VPS.

4️⃣ После завершения установки на сервере, в консоли увидите ключевую строку, которую нужно скопировать и вставить в Outline Manager. Сервер добавлен.

5️⃣ Скачайте и установите на другое устройство Outline Client. Создайте в Outline Manager для него ключ и скопируйте его в клиент. Он автоматически добавит ваш сервер. Теперь к нему можно подключаться и пользоваться.

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

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

#vpn #shadowsocks

​​На практике регулярно приходится собирать Nginx с дополнительными модулями. Чаще всего это модули brotli, vts или lua. У меня когда-то была статья для Centos по этой теме, но она уже неактуальна. Решил сделать мини-инструкцию по сборке своего пакета Nginx для Debian на примере добавления туда модуля статистки vts. А завтра отдельной публикацией покажу, как с его помощью очень быстро организовать мониторинг Nginx.

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

Устанавливаем необходимые зависимости, которые понадобятся для сборки Nginx и упаковки в deb пакет:
# apt install dpkg-dev devscripts quilte quivs wget dh-make build-essential \
git libpcre++-dev libssl-dev libgeoip-dev libxslt1-dev zlib1g-dev libpcre2-dev

Скачиваем файлы, которые нам понадобятся: исходники и настройки:
# mkdir build && cd build
# wget http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.24.0-1~bullseye.debian.tar.xz
# wget http://nginx.org/download/nginx-1.24.0.tar.gz

Распаковываем всё и удаляем архивы, чтобы не мешали:
# tar xvf nginx_1.24.0-1~bullseye.debian.tar.xz
# tar xzvf nginx-1.24.0.tar.gz
# rm -rf nginx_1.24.0-1~bullseye.debian.tar.xz nginx-1.24.0.tar.gz

Создаём директорию для модулей:
# mkdir debian/modules

Копируем туда исходники nginx-module-vts:
# cd debian/modules
# git clone https://github.com/vozlt/nginx-module-vts

Возвращаемся обратно в build и переносим директорию debian/ в папку с исходниками:
# cd ../../
# mv debian ./nginx-1.24.0
# cd nginx-1.24.0

Редактируем некоторые файлы. Начинаем с debian/changelog. Добавьте в начало по аналогии новую запись с описанием нового пакета. Примерно так:
nginx (1.24.0-1~bullseye) bullseye; urgency=low

 * 1.24.0-1
 * Add nginx-module-vts

 -- Serveradmin <root@serveradmin.ru> Fri, 18 Aug 2023 10:03:46 +0300

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

Далее вам может понадобиться файл debian/control, где можно добавить зависимости. В моём случае новых зависимостей не появится. А если вы, к примеру, захотите добавить модуль с lua, то там нужно будет пару пакетов в систему установить. Просто добавьте их в Build-Depends.

Открываем файл debian/rules и добавляем туда:
MODULESDIR = $(CURDIR)/debian/modules
Можете эту строку добавить сразу же после строки с BASEDIR. Далее ищем строки с ./configure и добавляем к ним в конец дополнительный параметр:
--add-module=$(MODULESDIR)/nginx-module-vts
Здесь же можете удалить лишние модули, которые вам точно не понадобятся.

Удаляем файл debian/source/format. Он не даст собрать пакет.
# rm -rf debian/source/format

Сохраняем файл и собираем архив с настройками пакета:
# dh_make --copyright gpl -s -e root@serveradmin.ru --createorig -y -p nginx_1.24.0
В директории build должен появиться файл nginx_1.24.0.orig.tar.xz.

Собираем пакет:
# dpkg-buildpackage -rfakeroot

В директории build должен появиться в том числе файл с пакетом nginx_1.24.0-1~bullseye_amd64.deb. Его можно установить и проверить:
# dpkg -i nginx_1.24.0-1~bullseye_amd64.deb

Проверяем, есть ли там наш модуль:
# nginx -V
В самом конце должно быть
--add-module=/root/build/nginx-1.24.0/debian/modules/nginx-module-vts

На этом всё. Таким образом можно собирать любые сборки Nginx под свои потребности и размещать их в своих репозиториях. Например, с помощью Nexus, aptly, apt-offline и т.д.

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

#debian #nginx

​​Популярный вопрос к моим статьям и заметкам по настройке проксирования HTTP запросов с Nginx куда-то на backend. Нужно ли настраивать HTTPS и как вообще правильно это сделать. Поясню, о чём идёт речь.

Допустим, у вас есть какой-то сервер Nginx, работающий в режиме proxy_pass и раскидывающий соединения к разным доменам по разным серверам или контейнерам. Либо это один большой сайт с несколькими бэкендами. Очевидно, что соединение клиента с этим Nginx настроено по HTTPS. А от Nginx до остальных серверов нужно ли настраивать по HTTPS?

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

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

Некоторые примеры подобных ошибок и их решения я публиковал на сайте (phpmyadmin, wordpress). Точно надо что-то делать с Bitrix, если проксируешь его по HTTP. Сейчас уже не помню, что именно. Не записывал. Каждый раз по месту разбираюсь.

А вы как считаете? Нужно ли в этом случае настраивать HTTPS, при условии, что запросы гуляют по нашей внутренней сети, которая считается доверенной? Если речь идёт про проксирование через сторонний сервис, тот же Cloudflare, или другую систему защиты от DDOS, то HTTPS я всегда настраиваю.

#nginx #webserver

​​Я вчера рассказал, как собрать Nginx с модулем статистики vts. Расскажу теперь, как его настроить и собрать метрики в систему мониторинга Prometheus.

Для настройки статистики вам достаточно добавить в основной файл конфигурации nginx.conf в секцию http:
vhost_traffic_status_zone;

И в любой виртуальных хост ещё один location. Я обычно в default добавляю:

server {
  listen    80;
  server_name localhost;
.........................
location /status {
vhost_traffic_status_display;
  vhost_traffic_status_display_format html;
}
..................

Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.

Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
# mkdir prom_data && cd prom_data && touch prometheus.yaml

global:
 scrape_interval:   5s
 evaluation_interval: 5s

rule_files:

scrape_configs:
 - job_name: prometheus
  static_configs:
   - targets: ['localhost:9090']

 - job_name: nginx_vts
  metrics_path: '/status/format/prometheus'
  static_configs:
   - targets: ['10.20.1.56:80']

Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
# docker run -p 9090:9090 -d --name=prom \
-v ~/prom_data/prometheus.yaml:/etc/prometheus/prometheus.yml \
prom/prometheus

Идём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.

Теперь ставим Grafana, можно на этот же хост с Prometheus:
# docker run -p 3000:3000 -d --name=grafana grafana/grafana
Идём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.

Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.

Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.

На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.

#nginx #мониторинг #prometheus #grafana

​​Решил создать небольшую шпаргалку по информации о файлах в Linux. Я очень часто сам путаюсь в некоторых понятиях. Например, в modify и change. Вроде одно и то же, но на самом деле нет.

Посмотреть информацию о файле можно с помощью утилиты stat:

# stat file.txt
 File: file.txt
 Size: 3      Blocks: 8     IO Block: 4096  regular file
Device: fe00h/65024d Inode: 657571   Links: 1
Access: (0644/-rw-r--r--) Uid: (  0/  root)  Gid: (  0/  root)
Access: 2023-08-22 00:31:39.446518364 +0300
Modify: 2023-08-22 00:30:55.460753550 +0300
Change: 2023-08-22 00:30:55.460753550 +0300
Birth: 2023-08-22 00:30:45.778142819 +0300

1️⃣ Birth (crtime). С временем создания всё понятно. Это время создания иноды файла. Нужно обязательно учитывать файловую систему. Не везде stat показывает эту информацию. Я в заметке буду иметь ввиду ext4 и xfs.

2️⃣ Access (atime). С доступом вроде бы тоже всё просто. Если вы откроете файл для просмотра и проверите его после этого командой stat, время доступа изменится на момент открытия файла. Но тут есть существенные нюансы. Метка atime зависит от опций, с которыми смонтирована файловая система.
▪ noatime, если указан этот параметр, то время доступа к файлу не обновляется при просмотре.
▪ relatime, с этим параметром обновление поля access будет только если atime меньше времени последнего изменения файла или если с предыдущего обновления прошло больше 24 часов. Этот параметр включён в набор defaults, который используется по умолчанию для монтирования файловых систем. То есть фактически вы время доступа знать не будете, если оно было чаще одного раза в последние 24 часа. Проверить это легко. Создайте файл и проверьте atime. Далее откройте файл один раз и проверьте ещё раз. Время изменится. А вот если вы проверите ещё один раз, то время не изменится, а останется то же, что было при первом просмотре.

3️⃣ Modify (mtime) - время последнего изменения содержимого файла.

4️⃣ Change (ctime) - время последнего изменения метаданных файла в файловой системе. Например, после использования утилиты chown или chmod для изменения прав и владельца файла, ctime изменится, но при этом изменения содержимого не происходит. Если в каталоге создать новый подкаталог, то ctime исходного изменится.

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

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

#linux

​​Не откладывая на потом, продолжу вчерашнюю тему с значениями даты файла. Я уже когда-то частично касался этой темы, когда рассказывал про утилиту touch. С её помощью можно менять atime и mtime. Например так:

# touch -a test.file
# touch -m test.file

Это мы поменяли atime и mtime на текущие. А можно любую дату задать явно:

# touch -m -a -t 201003211751 test.file 

Установили дату atime и mtime — 21 марта 2010 года 17:51. Формат даты в команде - YYMMDDhhmm. 

Единственное, что не умеет менять touch — дату создания файла (Birth, crtime). С ней есть объективные сложности. Для изменения даты создания файла, надо изменить дату создания иноды для этого файла. А это можно сделать только залезая в файловую систему напрямую. Поможет нам в этом утилита debugfs.

# debugfs -w -R 'set_inode_field /tmp/test.file crtime 201003211751' /dev/sda2
# echo 2 > /proc/sys/vm/drop_caches

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

Кстати, через debugfs и set_inode_field вы можете поменять, как и в touch, все остальные значения atime, ctime, mtime.

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

#linux

​​Расскажу одну историю, которая случилась со мной на днях. Это будет наглядный пример закона подлости и надежды на авось. У меня есть два старых неттопа, которые я время от времени использую. По характеристикам они до сих пор вполне актуальны: i3 cpu + 8GB ram + ssd. Там стоят Windows 10. Один вообще не используется, там чистая настроенная система, второй немного используется и его настройки терять не хочется.

Тот, который используется, бэкапится с помощью Veeam Agent for Windows Free. Архив порядка 100 GB весит. В какой-то момент система начала глючить и периодически виснуть при загрузке. Приходилось систему жёстко выключать, она запускалась снова, проводила какую-то свою диагностику и в итоге загружалась. При этом в журнале ничего информативного. Не понятно, что же не так.

Мне это надоело, решил как-то исправить проблему. Я сразу подумал на железо, поэтому для экономии времени просто перекинул жёсткий диск на второй неттоп. Через некоторое время проблема повторилась. Более того, спустя несколько дней система вообще перестала загружаться, тупо зависая в процессе.

Тогда я почему-то решил, что проблема в жёстком диске, потому что всё остальное я поменял. Взял второй изначально работающий неттоп и решил на него восстановить бэкап нужного. Загрузился с загрузочного диска Veeam, оказалось, что он не видит расшаренные сетевые диски. Пришлось искать внешний диск. Нашёл старый USB-HDD, там USB-2.0. Пару часов копировал на него бэкап.

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

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

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

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

❗️Отсюда можно сделать 2 важных коротких вывода:

1️⃣ Надо проверять скорость восстановления бэкапа. В моём случае если бэкап весил бы 500 Гб, то его сутки пришлось бы копировать и восстанавливать.

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

p.s. Бэкап глючной системы постараюсь починить в виртуалке. Очень интересно узнать, что там случилось. По результатам напишу потом.

#backup

Недавно рассказывал про open source систему контроля доступа к сервисам и системам Teleport. На днях как по заказу вышел подробный ролик с описанием его установки за проксируемым сервером Traefik. Это, кстати, фича последних версий. Раньше Teleport не удавалось разместить за прокси.

⇨ Installing Teleport + Traefik (Letsencrypt TLS certs)

Видео наглядное и подробное. Автор на наших глазах разворачивает всё хозяйство в Docker и настраивает. В качестве примера Application настраивает доступ к серверу Proxmox. Всё как мы любим. Не хватает только Mikrotik. Доступ через web, при желании, к нему настраивается по аналогии. Мне очень интересно узнать, записывает ли Teleport сессии к Application так же как к серверам по SSH. На своём стенде забыл это проверить.

Если не понимаете на слух английский, включите субтитры или синхронный перевод от Яндекса. Я с ним слушал, всё понятно. Качество перевода приемлемое. Я бы даже сказал хорошее, если бы он "teleport" не переводил как "телепортация".

#security #управление #devops

​​Многие, наверное, уже слышали, что некоторое количество бывших разработчиков Nginx создали форк и начали его развивать под названием Angie. Я видел эту новость давно, но не вникал в подробности. Сейчас решил разобраться и посмотреть, что в итоге получилось. Событие необычное.

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

Вообще, Angie появился примерно год назад в виде open source проекта. А весной 2023 года появилась коммерческая версия Angie Pro. Он имеет сертификаты совместимости с отечественными операционными системами РЕД ОС, Astra Linux Special Edition и Альт Сервер 10. Авторы говорят про него: "Angie PRO – единственный коммерческий веб-сервер разработка которого локализована в России."

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

При этом никто не мешает вам уже сейчас начать использовать Angie. Он доступен на операционных системах Alma Linux 8 и 9 версий, Alpine 3.18, Centos 7, 8 и 9 версий, Debian 12 и Ubuntu 23.04. Для них подготовлены репозитории от разработчиков. Я установил на Debian 12:

# curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
https://angie.software/keys/angie-signing.gpg
# echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
| tee /etc/apt/sources.list.d/angie.list > /dev/null
# apt update && apt install angie

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

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

Помимо обычного веб сервера, разработчики работают над Angie Ingress Controller (ANIC) для Kubernetes. Его, как Angie Pro, можно приобрести с услугой внедрения и технической поддержки.

#отечественное #nginx #webserver

​​На днях в комментариях посоветовали необычный open source проект для обхода блокировок от иранских и китайских разработчиков — Hiddify. Это набор различных инструментов и технологий для маскировки трафика в интернете. Всё это собрано и организовано в единую веб панель для управления настройками и клиентами.

Для установки есть bash скрипт под Ubuntu 20 или 22. Я воспользовался им и развернул Hiddify на своём VPS. Подробности приводить не буду, они все есть в инструкции. Всё устанавливается автоматически. После работы скрипта вам предоставят ссылку на веб интерфейс. Также в консоли будет меню управления сервисами с базовыми возможностями (посмотреть статусы, логи, перезапустить и т.д.). Установщик в том числе корректно всё настроит с вашим доменным именем, а не только с IP адресом.

Я даже не знаю, на чём конкретно остановиться, рассказывая об Hiddify. Он умеет кучу всего. В основе используется протокол XTLS и его реализация в сервере Xray. Он поддерживает все современные популярные реализации шифрованных протоколов: vmess, vless, v2ray, shadowsocks, trojan. Я так понял, это всё в основном придумано китайцами для обхода своих блокировок.

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

Пользователь на своей персональной странице может проверить скорость соединения с вашим сервером через локальный speedtest. Это сделано для того, чтобы можно было наглядно оценить разницу между прямым подключением и шифрованным. Там же есть тест работы DNS over HTTPS.

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

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

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

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

#vpn #xray

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

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

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

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

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

#мем #мысли

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

1️⃣ Angie это не пересборка Nginx для перепродажи в России. Над развитием продукта работают разработчики. Изменения вносятся в том числе в open source версию и это будет продолжаться. Angie Pro не копия Nginx Plus. Это другой продукт.

2️⃣ Другой сайт будет. То, что сейчас на Тильде, это временно. Сейчас фокус на сам продукт, его код и другие организационные моменты.

3️⃣ У Angie есть свой Telegram канал - https://t.me/angie_software.

4️⃣ На сайте после моей заметки появилась обзорная статья: Сходства и различия Angie и nginx. (nginx почему-то с маленькой буквы, а Angie с большой 😁) Основные моменты оттуда (что-то в сокращении):

🔹в Angie нет кода NGINX Plus, закрытой коммерческой версии nginx; более того, у нас нет цели сделать наш платный веб-сервер, Angie PRO, стопроцентной функциональной копией NGINX Plus

🔹Angie сознательно ориентируется на платформы, для которых “официальный” nginx будет собираться еще нескоро: это такие сертифицированные в России ОС, как ALT Linux, Astra Linux SE и РЕД ОС, а также процессоры “Байкал” и “Эльбрус”.

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

Последнее прокомментирую, так как это важно. Разработчики Angie решили сами собирать популярные динамические модули веб сервера, чтобы упростить жизнь пользователям. Недавно у меня была публикация, где я рассказывал, как собрать Nginx с нужными модулями. А здесь разработчики озаботились и решили эту проблему сами. Список готовых модулей можно посмотреть на сайте. Там всё наиболее популярное присутствует (brotli, lua, geoip и т.д.) Не нашёл только vts. Думаю, разработчикам имеет смысл обратить на него внимание тоже. Все модули собраны в пакеты и доступны из репозитория. Вообще, это существенный плюс в пользу того, чтобы поставить Angie вместо Nginx, если тебе нужен какой-то модуль.

🔹Следующий фактор, на который мы обращаем внимание в своей работе, — ускорение работы самого веб-сервера за счет устранения лишних задержек. Мы:
◽добавили API-интерфейс динамической конфигурации и средства адаптивной DNS-адресации;
◽реализовали механизм привязки пользовательских сессий к проксируемому серверу;
◽внедрили активные проверки работоспособности проксируемых серверов, уменьшающие вероятность отправки реального запроса на неработающий сервер;
◽создали возможность сегментировать прокси-кэш, тем самым более эффективно задействуя все ресурсы сервера.

🔹Еще одна область, в которой мы хотим добиться улучшений, — это гибкость и удобство настройки веб-сервера. Мы:
◽добавили для групп проксируемых серверов упомянутый выше API-интерфейс динамической конфигурации;
◽предоставили ряд других настроек, менее масштабных, но весьма полезных.

🔹Наконец, важным для нас аспектом развития Angie является мониторинг состояния самого веб-сервера и проксируемых серверов. Мы:
◽реализовали в API-интерфейсе возможность получения базовой информации о веб-сервере, а также статистики по всем основным аспектам его функционирования в популярных современных форматах;
◽внедрили уже упомянутые активные проверки проксируемых серверов, самостоятельно следящие за их работоспособностью;
◽добавили семейство настроек для сбора статистики по сессиям передачи данных и запросам разрешения адресов.

Спасибо за подробные комментарии и описание отличий. Все эти изменения выглядят очень привлекательно для эксплуатации. Наглядно видно развитие и фокус внимания на реальные потребности пользователей. Обязательно попробую этот веб сервер в деле.

#webserver #nginx #angie #отечественное