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

Goaccess есть в стандартных репозиториях популярных дистрибутивов.

# apt install goaccess

Также его можно запустить в Docker, образ allinurl/goaccess. Это позволит быстро получить самую свежую версию. В репозиториях она не всегда таковая.

Чтобы понять, о чём пойдёт речь, можно быстро посмотреть образец отчётов на основе логов веб сервера: https://rt.goaccess.io. Регистрация не требуется, сразу всё видно.

Для того, чтобы получить такую красоту у себя, достаточно сделать вот так:

# goaccess access.log -o report.html --log-format=COMBINED

или так:

# touch report.html
# cat access.log | docker run --rm -i -v ./report.html:/report.html -e LANG=$LANG allinurl/goaccess -a -o report.html --log-format=COMBINED -

Получили статичную страничку. Можно тут же её посмотреть через веб сервер на python:

# python3 -m http.server

Идём браузером на порт 8000 и смотрим там файлик report.html. Это статистика, которая формируется после ручного запуска goaccess. Можно запустить его в режиме обновления этой статистики онлайн:

# goaccess access.log -o report.html --log-format=COMBINED --real-time-html

То же самое c Docker:

# tail -F access.log | docker run -p 7890:7890 --rm -i -e LANG=$LANG allinurl/goaccess -a -o report.html --log-format COMBINED --real-time-html -

При этом информация в браузере будет обновляться автоматически. Даже страницу перезагружать не надо.

В goaccess можно отправлять вывод через пайп, а значит перед этим его можно грепнуть, причём как для статики, так и в режиме реального времени. Например, можно собрать статистику по конкретному IP адресу. Разово:

# cat access.log | grep '1.2.3.4' | goaccess --log-format=COMBINED -o report.html -

И то же самое в режиме реального времени:

# tail -f -n +0 access.log | grep -i --line-buffered '1.2.3.4' | goaccess -o report.html --log-format=COMBINED --real-time-html -

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

Я видел, что некоторые парсят логи nginx-ingress в Kubernetes с помощью goaccess. Автор собрал простенький скрипт на python, который рисует отдельные дашборды для каждого сервиса.

Если запустить goaccess без параметров, то статистика откроется прямо в терминале:

# goaccess access.log

Инструмент простой, удобный, функциональный. Если не знали о нём, то берите на вооружение.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver

В последнее время Proxmox практически безальтернативно занял нишу одиночных хостов и небольших кластеров виртуализации на базе QEMU+KVM. Но не Проксмоксом единым живо это направление. Я застал времена, когда Proxmox только начал развиваться и не был распространён.

В то время знакомство c KVM я начинал с управления через консоль с помощью libvirt. А подключение к консоли непосредственно виртуалок осуществлялось по VNC. Потом перешёл на Virt-Manager и какое-то время пользовался им. Позже уже перешёл на Proxmox.

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

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

📌 Основные возможности Incus:

▪️Запуск LXC, Docker контейнеров, виртуальных машин на базе QEMU+KVM.
▪️Использование образов контейнеров и виртуальных машин на базе проекта linuxcontainers.org.
▪️Создание кластера из десятков хостов. Сразу скажу, что кластер не тестировал, хотя хочется. Но на это надо много времени.
▪️Управление через веб-интерфейс как одиночными хостами, так и кластером.
▪️Поддержка всевозможных хранилищ: директория на хосте, zfs, lvm, btrfs, ceph, cephfs, linstor, truenas.
▪️Поддержка сетевых технологий: Linux Bridge, OVN, Macvlan, SR-IOV.
▪️Incus может сам управлять IP адресами (IPAM) на базе dnsmasq, сам реализует NAT для выхода виртуалок и контейнеров во внешнюю сеть.
▪️Устанавливается поверх любой Linux системы, может запускаться в Docker.

Я установил Incus на одиночный хост с Debian 13. Установка максимально простая:

# apt install incus incus-base qemu-system

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

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

После установки нужно выполнить инициализацию. Для управления Incus можно создать отдельного пользователя и запуcкать всё от него, но я всё сделал от root:

# incus admin init

Вам зададут несколько вопросов на тему сети и хранилища. Я выбрал настройки по умолчанию: обычный bridge с именем incusbr0 и хранилище в локальной директории, по умолчанию это /var/lib/incus/storage-pools.

Теперь можно посмотреть, какие готовые образы мы можем использовать:

# incus image list images:

Образов много. Более конкретно можно посмотреть так:

# incus image list images:debian
# incus image list images:alt
# incus image list images:ubuntu

и т.д.

Запустим контейнер:

# incus launch images:debian/13 debian-ct --storage default

Он будет автоматически подключен к incusbr0, ему будет выдан IP адрес из диапазона внутренней сети, он будет иметь доступ к интернету. Зайти в контейнер можно так:

# incus exec debian-ct -- bash

То же самое для виртуальной машины Ubuntu или Alt:

# incus launch images:ubuntu/noble ubuntu-vm --vm --storage default
# incus launch images:alt/Sisyphus alt-vm --vm --storage default

Заходим в виртуалки так же:

# incus exec ubuntu-vm -- bash

Другие полезные команды:

# incus ls
# incus info ubuntu-vm
# incus profile show default
# incus storage list
# incus network list

Для управления простой конфигурацией веб интерфейс не особо нужен, так как тут через консоль хоста и так проваливаешься во внутреннюю консоль как контейнера, так и виртуалки, если использовать встроенные образы, а не внешние ISO.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

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

Продолжаю тему с Incus. В первой заметке я разобрал запуск и управление через CLI. Теперь разберу веб интерфейс.

Изначально я пошёл по сложному пути и запустил веб интерфейс через найденный контейнер Docker. Использовал простой Docker-Compose:

services:
  lxconsole:
   image: 'penninglabs/lxconsole:latest'
   restart: unless-stopped
   ports:
   - '80:5000'
   volumes:
   - ./backups:/opt/lxconsole/backups
   - ./certs:/opt/lxconsole/certs
   - ./server:/opt/lxconsole/instance

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

Я какое-то время помучался и нашёл более удобный и простой вариант для одиночного сервера. Есть репозиторий Zabbly со всеми пакетами для incus:

⇨ https://pkgs.zabbly.com/incus/stable/pool/main/i/incus/

Можно скачать одиночный пакет с веб интерфейсом и установить. Примерно так:

# wget https://pkgs.zabbly.com/incus/stable/pool/main/i/incus/incus-ui-canonical_6.17-debian11-202510101456_amd64.deb
# dpkg -i incus-ui-canonical_6.17-debian11-202510101456_amd64.deb

Либо подключить репозиторий и установить оттуда:

# curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
# sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-lts-6.0.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/lts-6.0
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc

EOF'
# apt install incus-ui-canonical

После установки добавляем в юнит systemd настройку веб интерфейса:

# systemctl edit incus.service

[Service]
Environment = INCUS_UI=/opt/incus/ui/

Сохраняем, перечитываем конфиг и перезапускаем:

# systemctl daemon-reload
# systemctl restart incus

Разрешаем подключаться к incus извне:

# incus config set core.https_address :8443

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

Покажу пример, как настроить проброс порта внутрь виртуалки. Для примера возьму VM ubuntu24 c IP 10.253.116.184. Проброшу в неё порт 80 с внешнего IP адреса ноды 192.168.137.14.

Иду в раздел Networks, выбираю бридж incusbr0, перехожу на вкладку Forwards. Добавляю Forward:

◽️Listen address: 192.168.137.14
◽️Listen port: 80, Protocol: TCP
◽️Target address: 10.253.116.184
◽️Target port: 80

То же самое через консоль:

# incus network forward port add incusbr0 192.168.137.14 TCP 80 10.253.116.184 80

Сравните с тем, как это выглядит в Proxmox.

Проект в целом мне понравился. Причём без каких-то компромиссов. Для одиночного хоста он удобнее Proxmox. Тут более простой и наглядный IPAM, с которым не надо разбираться. Раздача IP адресов и NAT работают сразу. Проброс портов внутрь виртуалок тоже делается очень просто через веб интерфейс. В Proxmox всё это настраивается сложнее. Причём заметно сложнее. Для проброса портов придётся писать правила для iptables.

Если у вас есть жирная виртуалка с включённой вложенной виртуализацией, а она у некоторых хостеров включена, то вы можете на ней развернуть Incus и запускать виртуалки с контейнерами.

Мой цикл из двух заметок полностью описывает запуск и базовую настройку Incus. Можно разворачивать и пользоваться. Я целостного материала по этой теме не нашёл, поэтому пришлось самому разбираться, читать документацию. Сюда бы ещё добавить подключение LVM или ZFS пулов для дисков виртуалок, а так же бэкапы, но уже лимита по длине заметки не хватает.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

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

Расскажу про одну простую настройку в Nginx/Angie, которую использую постоянно, но с некоторыми нюансами, про которые возможно кто-то не знает. По крайней мере я не сразу об этом узнал. Речь пойдёт про basic_auth.

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

# sh -c "echo -n 'user01:' >> /etc/nginx/.htpasswd"
# sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

Создали файл .htpasswd, куда добавили пользователя user01 и задали ему интерактивно пароль. Теперь настраиваем Nginx/Angie, добавляя в секцию server или отдельной location настройку:

location / {
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

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

Таким способом очень удобно скрывать различные непубличные сервисы или технические панели. Например, я всегда так закрываю публикацию баз 1C, доступ в Phpmyadmin, Zabbix, Grafana, Apache Guacamole, какую-нибудь веб панель для управления, если используется и т.д. В общем, всё, что не для широкой публики лучше скрыть от посторонних глаз.

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

location / {
satisfy any;
allow 192.168.137.0/24;
deny all;
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

В этом примере пользователи из подсети 192.168.137.0/24 зайдут на ресурс напрямую без аутентификации, а всем остальным нужно будет ввести пароль. Это удобно для той же публикации 1С, когда люди из офиса ходят напрямую в локальную базу, а снаружи с аутентификацией. В случае публикации на внешнем сервере удобно разрешить доступ с внешнего IP адреса офиса прямой доступ, а всем остальным с паролем.

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

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

allow 192.168.0.0/24;
allow 10.20.5.0/24;
allow 185.25.48.189;

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

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#nginx #angie

На днях в комментариях посоветовали отечественный open source продукт платформы виртуализации Open vAIR. Впервые о нём услышал, поэтому решил попробовать. Чтобы сразу было понятно, что это такое, назову его условным аналогом Proxmox и других подобных продуктов. Это полностью бесплатная платформа для запуска виртуальных машин от компании Aerodisk.

Сразу перечислю особенности Open vAIR:

◽️Это не дистрибутив, а софт, который ставится поверх системы. Разработчики рекомендуют Ubuntu. Я попробовал поставить на Debian, не получилось, не все зависимости установились автоматически. В планах поддержка отечественных дистрибутивов.
◽️Система построена на базе open source: FastAPI, PostgreSQL, RabbitMQ, QEMU, KVM, libvirt, Vue, OpenVSwitch, Restic.
◽️Умеет запускать только виртуальные машины, контейнеров нет.
◽️Поддерживает в качестве хранилищ: локальные диски, NFS, iSCSI и Fibre Channel.
◽️Сетевые возможности: Bridge, VLAN, порт-группы.
◽️Резервное копирование реализовано через Restic.
◽️Развитый REST API для управления.

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

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

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

Запуск виртуалки выглядит следующим образом:

1️⃣ Добавляем хранилище. Им может выступать диск по NFS, локальный диск, или его раздел. Директория на уже используемом диске не поддерживается (почему? 🤷🏼‍♂️).
2️⃣ Создаём виртуальный диск. Поддерживаются форматы raw или qcow2. Диск можно создать заранее или в процессе создания виртуалки.
3️⃣ Загружаем ISO образ.
4️⃣ Создаём виртуальную машину. Для сети выбираем бридж, который создан автоматически в момент установки Open vAIR.

Функциональность пока очень простая - создание и запуск виртуалок. Больше ничего.

Теперь о проблемах, с которыми столкнулся. У меня не заработал VNC клиент для подключения к консоли виртуалки. Сначала думал, что браузер блокирует всплывающие окна. Отключил блокировку - не помогло. Потом подумал, что проблема в самоподписанном сертификате. Добавил в исключения, тоже не помогло. Пробовал в разных браузерах, везде одно и то же.

Открыл консоль браузера, там видно, что сервер возвращает 500-ю ошибку на нажатие на кнопку с VNC. Отловил запрос и запустил отдельно. Увидел в тексте ошибки упоминание о том, что нет lsof. Установил lsof на хост и VNC консоль заработала. Неочевидная ошибка. Не каждый догадается о решении.

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

Сами бэкапы представляют из себя бэкап всех дисков виртуалок и дамп системной sql базы средствами Restic. Без каких-то изысков. Просто всё летит в репозиторий Restic. Мне не видится в таком виде это надёжным решением для запущенных VM. Не увидел создание снепшотов дисков во время бэкапа.

Впечатления от Open vAIR - продукт сырой и по функциональности очень куцый. В таком виде я не вижу ему применения, так как тот же Incus намного функциональнее, не говоря уже о Proxmox. Могу только пожелать разработчикам удачи в разработке, поддержке и добавлении функциональности.

Из плюсов отмечу приятный интерфейс и русский язык. Ну и то, что это в принципе open source продукт.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

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