Впервые увидел и попробовал очень удобную панель управления для OpenVPN. Если быть точным, то это скорее панель наблюдения за пользователями OpenVPN сервера. Речь пойдёт про проект openvpn-monitor.
С его помощью можно посмотреть следующую информацию о пользователях:
▪️имя пользователя;
▪️время подключения;
▪️внутренний и внешний IP пользователя;
▪️суммарный трафик;
▪️время подключения и соответственно время онлайна;
▪️расположение пользователя на географический карте.
При желании пользователя можно отключить через веб интерфейс.
Openvpn-monitor представляет из себя веб интерфейс, написанный на Python, запущенный через обычный веб сервер Nginx или Apache. Информацию о пользователях он берёт через стандартную management console сервера OpenVPN. Её надо включить. Для этого достаточно добавить в конфиг сервера:
или
Не забудьте ограничить доступ к консоли с помощью файрвола. Можно ещё паролем закрыть, но я бы не рассчитывал только на него. Лучше полностью скрыть. Также можно открыть доступ к ней через unix socket. Подробности в документации.
Openvpn-monitor можно запускать на любой машине, откуда будет доступ к открытой консоли. Проще всего запустить её в Docker, чтобы не устанавливать все пакеты и зависимости, хотя такая возможность тоже есть. Можно посмотреть в документации.
Я тестировал в Docker. Показываю сразу рабочий вариант, на котором я остановился:
Здесь указана широта и долгота Москвы как стартовая точка на карте и IP адрес VPN сервера. SITES_0 задаёт параметры одного сервера. Можно в одну панель добавить несколько, задавая настройки соответственно SITES_1_, SITES_2_ и т.д.
Это вся настройка. Теперь можно идти в IP интерфейс на порт 8181 и смотреть информацию о пользователях. Не забудьте его тоже скрыть от посторонних глаз либо за Firewall, либо за любой веб сервер с режимом обратного прокси. Встроенной аутентификации у openvpn-monitor нет.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#openvpn
С его помощью можно посмотреть следующую информацию о пользователях:
▪️имя пользователя;
▪️время подключения;
▪️внутренний и внешний IP пользователя;
▪️суммарный трафик;
▪️время подключения и соответственно время онлайна;
▪️расположение пользователя на географический карте.
При желании пользователя можно отключить через веб интерфейс.
Openvpn-monitor представляет из себя веб интерфейс, написанный на Python, запущенный через обычный веб сервер Nginx или Apache. Информацию о пользователях он берёт через стандартную management console сервера OpenVPN. Её надо включить. Для этого достаточно добавить в конфиг сервера:
management 127.0.0.1 5555или
management 0.0.0.0 5555Не забудьте ограничить доступ к консоли с помощью файрвола. Можно ещё паролем закрыть, но я бы не рассчитывал только на него. Лучше полностью скрыть. Также можно открыть доступ к ней через unix socket. Подробности в документации.
Openvpn-monitor можно запускать на любой машине, откуда будет доступ к открытой консоли. Проще всего запустить её в Docker, чтобы не устанавливать все пакеты и зависимости, хотя такая возможность тоже есть. Можно посмотреть в документации.
Я тестировал в Docker. Показываю сразу рабочий вариант, на котором я остановился:
# docker run -d --name openvpn-monitor \ -e OPENVPNMONITOR_DEFAULT_DATETIMEFORMAT="%%d/%%m/%%Y" \ -e OPENVPNMONITOR_DEFAULT_LATITUDE=55 \ -e OPENVPNMONITOR_DEFAULT_LONGITUDE=37 \ -e OPENVPNMONITOR_DEFAULT_MAPS=True \ -e OPENVPNMONITOR_DEFAULT_MAPSHEIGHT=500 \ -e OPENVPNMONITOR_DEFAULT_SITE=Test \ -e OPENVPNMONITOR_SITES_0_ALIAS=UDP \ -e OPENVPNMONITOR_SITES_0_HOST=97.145.145.233 \ -e OPENVPNMONITOR_SITES_0_NAME=OVPN-UDP \ -e OPENVPNMONITOR_SITES_0_PORT=5555 \ -e OPENVPNMONITOR_SITES_0_SHOWDISCONNECT=True \ -p 8181:80 ruimarinho/openvpn-monitorЗдесь указана широта и долгота Москвы как стартовая точка на карте и IP адрес VPN сервера. SITES_0 задаёт параметры одного сервера. Можно в одну панель добавить несколько, задавая настройки соответственно SITES_1_, SITES_2_ и т.д.
Это вся настройка. Теперь можно идти в IP интерфейс на порт 8181 и смотреть информацию о пользователях. Не забудьте его тоже скрыть от посторонних глаз либо за Firewall, либо за любой веб сервер с режимом обратного прокси. Встроенной аутентификации у openvpn-monitor нет.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#openvpn
Для тех, кто много работает с базами данных, есть простой и удобный инструмент для их проектирования – dbdiagram.io. Мы не разработчики, тем не менее, покажу, как этот сервис может быть полезен. У него удобная визуализация структуры базы данных. Намного удобнее, чем, к примеру, в привычном phpmyadmin.
Можно выгрузить обычный дам из СУБД без данных и загрузить его в dbdiagram. Получите наглядную схему базы. При желании, её можно отредактировать, или просто экспортнуть в виде картинки. Покажу на примере MySQL. Выгружаем дамп базы postfix без данных, только структуру:
Передаём к себе на комп полученный дамп. В dbdiagram.io открываем Import ⇨ From MySQL ⇨ Upload .sql ⇨ Submit. Наблюдаем схему базы данных со всеми связями. Причём она сразу отформатирована по таблицам так, что все их наглядно видно.
При желании можно что-то изменить в структуре и выгрузить новый sql файл уже с изменениями. Если выбрать Export ⇨ To PNG, то сразу же получите аккуратную картинку со схемой, без лишних вопросов. Очень быстро и удобно, если нужно куда-то приложить схему базы данных.
⇨ 🌐 Сайт
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #postgresql
Можно выгрузить обычный дам из СУБД без данных и загрузить его в dbdiagram. Получите наглядную схему базы. При желании, её можно отредактировать, или просто экспортнуть в виде картинки. Покажу на примере MySQL. Выгружаем дамп базы postfix без данных, только структуру:
# mysqldump --no-data -u dbuser -p postfix > ~/schema.sqlПередаём к себе на комп полученный дамп. В dbdiagram.io открываем Import ⇨ From MySQL ⇨ Upload .sql ⇨ Submit. Наблюдаем схему базы данных со всеми связями. Причём она сразу отформатирована по таблицам так, что все их наглядно видно.
При желании можно что-то изменить в структуре и выгрузить новый sql файл уже с изменениями. Если выбрать Export ⇨ To PNG, то сразу же получите аккуратную картинку со схемой, без лишних вопросов. Очень быстро и удобно, если нужно куда-то приложить схему базы данных.
⇨ 🌐 Сайт
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #postgresql
Когда разбирался с контейнером openvpn-monitor, про который вчера писал, пришлось немного его подебажить, так как он никак не хотел подключаться к консоли OpenVPN сервера. Писал стандартную ошибку в веб интерфейсе - connection timeout и адрес с портом сервера. Я и так, и сяк адреса и доменные имена пробовал, ни в какую.
Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.
Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:
Подключаемся к нашему контейнеру:
Оказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.
Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.
С помощью cdebug можно подключаться к подам кубера. В докере можно пробрасывать новые порты из контейнера на хост без перезапуска контейнера. Можно подцепить к контейнеру образ с tshark на борту и собрать трафик изнутри контейнера. Очень простая и удобная программа. Если работаете с контейнерами, рекомендую сохранить и освоить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.
Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:
# mkdir ~/cdebug && cd ~/cdebug# wget https://github.com/iximiuz/cdebug/releases/download/v0.0.18/cdebug_linux_amd64.tar.gz# tar xzvf cdebug_linux_amd64.tar.gzПодключаемся к нашему контейнеру:
# ./cdebug exec -it openvpn-monitorОказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.
Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.
С помощью cdebug можно подключаться к подам кубера. В докере можно пробрасывать новые порты из контейнера на хост без перезапуска контейнера. Можно подцепить к контейнеру образ с tshark на борту и собрать трафик изнутри контейнера. Очень простая и удобная программа. Если работаете с контейнерами, рекомендую сохранить и освоить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Telegram
ServerAdmin.ru
При работе с Docker контейнерами часто хочется зайти туда и посмотреть, что происходит. Но не всегда это возможно. В некоторых контейнерах нет вообще ничего - ни оболочки, ни утилит для диагностики.
Для решения этой задачи создана программа cdebug. С её…
Для решения этой задачи создана программа cdebug. С её…
❓Возник вопрос вчера на тему OpenVPN. Можно как-то собирать статистику по подключениям пользователей и выводить отчёт? В целом, задача эта решаема, так как OVPN сервер выдаёт всю статистику о своём состоянии и пользователях как через встроенную консоль управления, так и через лог файл, который задаётся параметром status в конфигурационном файле.
Расскажу, как эту задачу решаю я. Вроде бы в контексте именно статистики по пользователям я про неё не писал. В интернете можно найти много вариантов настройки мониторинга за пользователями OpenVPN. Я лично по старинке использую тот, что когда-то давно попробовал и внедрил. Видел варианты более элегантные и удобные. Я уже просто привык к своему, он нормально работает, так что использую:
⇨ Мониторинг openvpn подключений пользователей в zabbix
Идея сбора статистики в том, что при подключении пользователя срабатывает триггер, при отключении он гаснет. И всё. Zabbix сам собирает всю статистику. Потом по ней можно какой-то отчёт сделать и выгрузить его в CSV. Триггерам можно повесить отдельный тэг и самую низкую важность, чтобы они больше нигде не отсвечивали.
Тут получается немного нецелевое использование системы мониторинга, но зато ничего самому по аналитике делать не надо: искать какую-то панель для этого, агрегировать данные и т.д.
Дополнительно можно сделать отдельный Dashboard с информацией об активных сессиях. Там же добавить виджет с историей подключений и отключений и т.д. В целом удобно и заменяет многие простые панели без непосредственно управления. При этом лично мне именно в Zabbix функциональность подобного рода нравится больше, чем примерно то же самое, но в Grafana с метриками от какого-нибудь экспортера Prometheus. По крайней мере из тех, что я видел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #openvpn
Расскажу, как эту задачу решаю я. Вроде бы в контексте именно статистики по пользователям я про неё не писал. В интернете можно найти много вариантов настройки мониторинга за пользователями OpenVPN. Я лично по старинке использую тот, что когда-то давно попробовал и внедрил. Видел варианты более элегантные и удобные. Я уже просто привык к своему, он нормально работает, так что использую:
⇨ Мониторинг openvpn подключений пользователей в zabbix
Идея сбора статистики в том, что при подключении пользователя срабатывает триггер, при отключении он гаснет. И всё. Zabbix сам собирает всю статистику. Потом по ней можно какой-то отчёт сделать и выгрузить его в CSV. Триггерам можно повесить отдельный тэг и самую низкую важность, чтобы они больше нигде не отсвечивали.
Тут получается немного нецелевое использование системы мониторинга, но зато ничего самому по аналитике делать не надо: искать какую-то панель для этого, агрегировать данные и т.д.
Дополнительно можно сделать отдельный Dashboard с информацией об активных сессиях. Там же добавить виджет с историей подключений и отключений и т.д. В целом удобно и заменяет многие простые панели без непосредственно управления. При этом лично мне именно в Zabbix функциональность подобного рода нравится больше, чем примерно то же самое, но в Grafana с метриками от какого-нибудь экспортера Prometheus. По крайней мере из тех, что я видел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #openvpn
Небольшая справочная заметка для тех, кто пользуется Prometheus. Речь пойдёт про простенький и быстрый в настройке обратный прокси для метрик - exporter-exporter. Я вообще не знал про его существование, хотя пользоваться им удобно, настраивается быстро. Плюс, живёт в базовых системных репозиториях. По крайней мере в Debian и Ubuntu он есть, искать по имени prometheus-exporter-exporter. Есть даже версия под Windows, можно запустить как службу.
По своей сути exporter-exporter обычный бинарник на Go. Заменяет настройку любого другого обратного прокси на базе полноценного веб-сервера, типа Nginx или Traefik. Пригодится, когда у тебя несколько экспортеров и ты хочешь использовать для них единую точку входа, скрывая реальные адреса экспортеров.
У exporter-exporter небольшой конфиг в формате yaml. Экспортер поддерживает 3 эндпоинта:
◽️/ - отображает список всех экспортеров, которые на нём настроены;
◽️/proxy - через этот эндпоинт можно обратиться к конкретному экспортеру, настроенному через отдельный module в конфиге;
◽️/metrics - показывает метрики самого exporter-exporter.
Настройка примерно такая для двух разных экспортеров, локального и внешнего:
А вот так их добавляем в Prometheus вместе с метриками самого exporter-exporter, запущенного на сервере 192.168.101.2:
В примере репозитория exporter-exporter не сразу понял, как добавить внешний экспортер. Там были примеры только для localhost. Спросил об этом DeepSeek, перед этим уточнив, знаком ли он с этим продуктом. Ответил, что знаком и выдал совершенно нерабочий конфиг для службы, просто придумав различные несуществующие параметры. Такой вот он помощник. Пришлось самому разбираться.
Для тех, кто не видел, у меня была серия публикаций по запуску полноценного мониторинга на связке prometheus+grafana+alertmanager:
⇨ Запуск Prometheus + Grafana
⇨ Добавление туда Alertmanager
⇨ Полная автоматизация запуска и эксплуатации по принципу IaC
Данная заметка их хорошо дополняет. Удобно использовать именно exporter-exporter в связке с Prometheus, а не какой-то другой обратный прокси. Тут всё в едином формате, легко автоматизировать настройку и запуск.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#prometheus
По своей сути exporter-exporter обычный бинарник на Go. Заменяет настройку любого другого обратного прокси на базе полноценного веб-сервера, типа Nginx или Traefik. Пригодится, когда у тебя несколько экспортеров и ты хочешь использовать для них единую точку входа, скрывая реальные адреса экспортеров.
У exporter-exporter небольшой конфиг в формате yaml. Экспортер поддерживает 3 эндпоинта:
◽️/ - отображает список всех экспортеров, которые на нём настроены;
◽️/proxy - через этот эндпоинт можно обратиться к конкретному экспортеру, настроенному через отдельный module в конфиге;
◽️/metrics - показывает метрики самого exporter-exporter.
Настройка примерно такая для двух разных экспортеров, локального и внешнего:
modules:
node_exporter_loc:
method: http
http:
port: 9100
path: '/metrics'
node_exporter_ext:
method: http
http:
address: 172.20.4.15
port: 9100
path: '/metrics'
А вот так их добавляем в Prometheus вместе с метриками самого exporter-exporter, запущенного на сервере 192.168.101.2:
- job_name: 'exp_exp_metrics'
scrape_interval: 5s
static_configs:
- targets: ['192.168.101.2:9999']
- job_name: 'exp_exp-local'
scrape_interval: 5s
metrics_path: /proxy
params:
module:
- node_exporter_loc
static_configs:
- targets: ['192.168.101.2:9999']
- job_name: 'exp_exp-external'
scrape_interval: 5s
metrics_path: /proxy
params:
module:
- node_exporter_ext
static_configs:
- targets: ['192.168.101.2:9999']
В примере репозитория exporter-exporter не сразу понял, как добавить внешний экспортер. Там были примеры только для localhost. Спросил об этом DeepSeek, перед этим уточнив, знаком ли он с этим продуктом. Ответил, что знаком и выдал совершенно нерабочий конфиг для службы, просто придумав различные несуществующие параметры. Такой вот он помощник. Пришлось самому разбираться.
Для тех, кто не видел, у меня была серия публикаций по запуску полноценного мониторинга на связке prometheus+grafana+alertmanager:
⇨ Запуск Prometheus + Grafana
⇨ Добавление туда Alertmanager
⇨ Полная автоматизация запуска и эксплуатации по принципу IaC
Данная заметка их хорошо дополняет. Удобно использовать именно exporter-exporter в связке с Prometheus, а не какой-то другой обратный прокси. Тут всё в едином формате, легко автоматизировать настройку и запуск.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#prometheus
GitHub
GitHub - QubitProducts/exporter_exporter: A reverse proxy designed for Prometheus exporters
A reverse proxy designed for Prometheus exporters. Contribute to QubitProducts/exporter_exporter development by creating an account on GitHub.
Решил на днях одну необычную задачу на базе Zabbix. У меня есть сервера, которыми управляю не только я. В частности возьмём веб сервер. Я хотел узнавать, когда кто-то вносит изменения в конфигурацию сервера и виртуальных хостов.
У Zabbix есть функция vfs.file.cksum для проверки контрольной суммы файла. Для одного-двух файлов можно вручную настроить и не париться. А когда файлов много, хочется автоматизировать этот процесс.
Также у Zabbix есть функция vfs.dir.get. С её помощью можно рекурсивно получить информацию о всех файлах и каталогах. Указываем каталог веб сервера, в моём случае
Дальше этот вывод можно распарсить в правиле автообнаружения, настроить макросы, добавить прототипы элементов данных и триггеры.
На выходе я получил айтемы для каждого файла из директории
Дополнительно сделал триггер, который сработает, если для айтема не поступают данные. Это случится, если файл удалят.
Обращаю внимание на описание триггеров в шаблоне. Там показан пример, как в описание выводить данные из айтемов. Я прямо в описании вывожу последнее заначение хэша и предыдущее. По аналогии туда можно выводить значения из разных айтемов, которые будут полезны в информации о триггере.
Настроить подобное меня надоумила вот эта запись в блоге File Integrity Monitoring with Zabbix. Там только сама идея описана в общих словах, без точной реализации. Я уже по мотивам сделал шаблон и потестировал.
В шаблоне нужно будет поменять единственный элемент данных - Check dir. Указать в нём свой каталог. А дальше правило автообнаружения все айтемы на основе файлов создаст само.
При желании сюда же можно контроль за именем файла и изменением прав доступа прикрутить, но мне особо не нужно это.
Если у кого-то есть вопросы по мониторингу тех или иных вещей в Zabbix, задавайте. Чем смогу, помогу. Я чего только в нём не мониторил.
⇨ Ссылка на шаблон
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix
У Zabbix есть функция vfs.file.cksum для проверки контрольной суммы файла. Для одного-двух файлов можно вручную настроить и не париться. А когда файлов много, хочется автоматизировать этот процесс.
Также у Zabbix есть функция vfs.dir.get. С её помощью можно рекурсивно получить информацию о всех файлах и каталогах. Указываем каталог веб сервера, в моём случае
/etc/angie и получаем информацию обо всех файлах в директории в формате json. Примерно такую:[ { "basename": "angie.conf", "pathname": "/etc/angie/angie.conf", "dirname": "/etc/angie", "type": "file", "user": "root", "group": "root", "permissions": "0644", "uid": 0, "gid": 0, "size": 5910, "time": { "access": "2025-01-27T22:12:26+0300", "modify": "2024-08-19T16:04:34+0300", "change": "2024-08-19T16:04:34+0300" }, "timestamp": { "access": 1738005146, "modify": 1724072674, "change": 1724072674 } }, { "basename": "angie.conf.orig", "pathname": "/etc/angie/angie.conf.orig", "dirname": "/etc/angie", "type": "file", "user": "root", "group": "root", "permissions": "0644", "uid": 0, "gid": 0, "size": 1230, "time": { "access": "2024-10-01T19:11:57+0300", "modify": "2023-11-20T20:42:55+0300", "change": "2024-08-19T15:43:30+0300" }, "timestamp": { "access": 1727799117, "modify": 1700502175, "change": 1724071410 } }]Дальше этот вывод можно распарсить в правиле автообнаружения, настроить макросы, добавить прототипы элементов данных и триггеры.
На выходе я получил айтемы для каждого файла из директории
/etc/angie. По ним собирается информация о размере, датах, правах и т.д. Если меняется контрольная сумма, то срабатывает триггер. Плюс отдельно сделал для примера айтемы, где хранится размер файлов. Это просто вам для демонстрации возможностей, чтобы этот же шаблон можно было использовать для мониторинга за бэкапами или какими-то другими файлами, где нужно следить ещё и за размером. Там логика триггеров будет другая, но сама идея с автообнаружением и прототипами триггеров такая же. Дополнительно сделал триггер, который сработает, если для айтема не поступают данные. Это случится, если файл удалят.
Обращаю внимание на описание триггеров в шаблоне. Там показан пример, как в описание выводить данные из айтемов. Я прямо в описании вывожу последнее заначение хэша и предыдущее. По аналогии туда можно выводить значения из разных айтемов, которые будут полезны в информации о триггере.
Настроить подобное меня надоумила вот эта запись в блоге File Integrity Monitoring with Zabbix. Там только сама идея описана в общих словах, без точной реализации. Я уже по мотивам сделал шаблон и потестировал.
В шаблоне нужно будет поменять единственный элемент данных - Check dir. Указать в нём свой каталог. А дальше правило автообнаружения все айтемы на основе файлов создаст само.
При желании сюда же можно контроль за именем файла и изменением прав доступа прикрутить, но мне особо не нужно это.
Если у кого-то есть вопросы по мониторингу тех или иных вещей в Zabbix, задавайте. Чем смогу, помогу. Я чего только в нём не мониторил.
⇨ Ссылка на шаблон
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix
Повторю одну давнюю историю на тему того, почему не надо бездумно копировать и вставлять что-то в консоль сервера.
Настраивал iptables на одном из серверов. Надо было просто базовый набор правил сделать с заделом на будущее, если вдруг что-то понадобится ограничить. Я обычно за основу беру свой же список правил из статьи https://serveradmin.ru/centos-nastroyka-servera/#Nastraivaem_firewall
Просто копирую набор правил в bash скрипт и запускаю. Пользуюсь статьей уже несколько лет, поэтому точно знаю, что проблем с правилами быть не должно. Достаточно только заменить ip адрес и имя интерфейса. Но в этот раз что-то пошло не так. Применил правила, получил кучу ошибок синтаксиса iptables и меня отрубило от сервера.
Я знаю заветное правило. Настройка firewall без доступа к консоли – к дальней дороге. Подключился по vnc к серверу и посмотрел, в чем проблема. Оказывается, после какого-то обновления движка сайта, он двойные тире -- стал заменять на одинарные и пробел. Соответственно, обычный копипаст правил с сайта приводит к тому, что правила не работают так, как задумывалось. Успевают примениться начальные правила блокировки, а до разрешений дело не доходит.
К чему я всё это написал? Чтобы лишний раз напомнить, не надо лезть в настройки файрвола, если нет доступа напрямую к консоли сервера, чтобы откатить настройки в случае проблем. Не надо копипастить команды сразу в консоль. А файрвол лучше вообще не править через консоль, но я не могу изжить в себе эту привычку. Хожу и правлю. Можно взять, к примеру, готовую роль Ansible и использовать её. Там и более наглядное управление, и проверка конфигурации и другие дополнения. Подобных готовых ролей много. Я и свои писал, но не пользуюсь. Серверами, которые обслуживаю, чаще всего управляю только я, поэтому мне контроль версий и какие-то дополнительные проверки не нужны. Что поломаю, сам же и исправляю.
Кстати, предвидя подобные проблемы, в своей статье по настройке iptables (https://serveradmin.ru/nastroyka-iptables-v-centos-7/) я все правила сделал в виде картинок, а в конце привел текстовый файл с полным набором показанных правил. За такую заботу о людях получил немного негатива в комментах. Не все поняли такую заботу.
Тут тоже всегда ставлю # перед командами, чтобы нельзя было скопировать и сразу выполнить в консоли. Мало ли, что там в буфер в итоге приедет, а из него в консоль.
#совет
Настраивал iptables на одном из серверов. Надо было просто базовый набор правил сделать с заделом на будущее, если вдруг что-то понадобится ограничить. Я обычно за основу беру свой же список правил из статьи https://serveradmin.ru/centos-nastroyka-servera/#Nastraivaem_firewall
Просто копирую набор правил в bash скрипт и запускаю. Пользуюсь статьей уже несколько лет, поэтому точно знаю, что проблем с правилами быть не должно. Достаточно только заменить ip адрес и имя интерфейса. Но в этот раз что-то пошло не так. Применил правила, получил кучу ошибок синтаксиса iptables и меня отрубило от сервера.
Я знаю заветное правило. Настройка firewall без доступа к консоли – к дальней дороге. Подключился по vnc к серверу и посмотрел, в чем проблема. Оказывается, после какого-то обновления движка сайта, он двойные тире -- стал заменять на одинарные и пробел. Соответственно, обычный копипаст правил с сайта приводит к тому, что правила не работают так, как задумывалось. Успевают примениться начальные правила блокировки, а до разрешений дело не доходит.
К чему я всё это написал? Чтобы лишний раз напомнить, не надо лезть в настройки файрвола, если нет доступа напрямую к консоли сервера, чтобы откатить настройки в случае проблем. Не надо копипастить команды сразу в консоль. А файрвол лучше вообще не править через консоль, но я не могу изжить в себе эту привычку. Хожу и правлю. Можно взять, к примеру, готовую роль Ansible и использовать её. Там и более наглядное управление, и проверка конфигурации и другие дополнения. Подобных готовых ролей много. Я и свои писал, но не пользуюсь. Серверами, которые обслуживаю, чаще всего управляю только я, поэтому мне контроль версий и какие-то дополнительные проверки не нужны. Что поломаю, сам же и исправляю.
Кстати, предвидя подобные проблемы, в своей статье по настройке iptables (https://serveradmin.ru/nastroyka-iptables-v-centos-7/) я все правила сделал в виде картинок, а в конце привел текстовый файл с полным набором показанных правил. За такую заботу о людях получил немного негатива в комментах. Не все поняли такую заботу.
Тут тоже всегда ставлю # перед командами, чтобы нельзя было скопировать и сразу выполнить в консоли. Мало ли, что там в буфер в итоге приедет, а из него в консоль.
#совет
В настоящее время есть много технологий VPN, с помощью которых можно объединять подсети и подключать к ним внешних клиентов. Речь идёт не о блокировках и всем, что с этим связано, а об условно корпоративных VPN. Определённую популярность набрали сервисы на основе WireGuard, которые строят с его помощью mesh сети. Это не чистый WG, а программная обвязка вокруг него на дополнительном ПО. Примеры: Nebula, Tailscale, ZeroTier, Netmaker.
Я же хочу рассказать про старый добрый OpenVPN, который несмотря на все прочие современные реализации VPN остаётся актуален и удобен. И это не привычка и нежелание переходить на что-то новое, а объективное удобство. Перечислю несколько основных фактов, которые держат на OpenVPN.
1️⃣ Первый и самый главный – OpenVPN сервер умеет передавать клиенту во время подключения различные настройки, в том числе сетевые маршруты. Например, клиент подключается и мы ему тут же сообщаем, что он весь свой трафик должен завернуть в VPN. А когда нам это не нужно, перечисляем только список подсетей, которые заворачиваются в VPN.
Например, у меня есть несколько VPN серверов с внешними IP. Я их использую для доступа к закрытым ресурсам, куда разрешён доступ только мне. На этих VPN серверах перечислены по IP адресам те серверы, куда я должен подключаться через VPN. В момент моего подключения к OVPN серверу я получаю список маршрутов до этих IP адресов через VPN сервер. И только туда. Весь остальной трафик будет ходить напрямую.
Помимо маршрутов можно передавать и другие настройки. Несколько примеров:
- настройка своего внутреннего DNS сервера;
- разрешение клиентов взаимодействовать друг с другом;
- настройки внутреннего IP адреса;
- разрешение, запрет на подключение;
- разрешение, запрет сжатия трафика;
- и многие другие.
Всё это управляется централизованно на сервере. На клиентах никаких настроек менять не надо. Один раз передали конфиг с зашитыми сертификатами и всё.
2️⃣ Помимо передачи маршрутов клиентам внутри OVPN сети есть своя реализация динамической маршрутизации. Если у вас филиальная сеть объединена с помощью OVPN, вы у пользователей весь нужный трафик направляете в VPN туннель. А на OVPN сервере управляете, какие подсети какой филиал обслуживает. Добавился новый филиал - добавили его в список маршрутов и указали, что за новую подсеть отвечает новый сервер в филиале. Настройки клиентов трогать не надо, пускать поверх VPN сети ospf и bgp тоже. Реализация очень простая в настройке и управлении. Возможно для очень больших сетей этого будет недостаточно, но для малых и средних вполне.
3️⃣ Гибкость в возможностях аутентификации. Вы можете использовать традиционную для OVPN аутентификацию по сертификатам, можно оставить только логин с паролем, можно подключать внешний скрипт для аутентификации, а там уже реализовывать любую логику.
Можно всё убрать и настроить простой туннель вообще без какой-либо аутентификации и шифрования:
Всё, серверы видят друг друга по указанным внутренним IP адресам.
4️⃣ OVPN сервер поддерживает оба протокола TCP и UDP, можно использовать любой порт. Вкупе с предыдущим пунктом, одна технология VPN покрывает очень широкий спектр задач. Вы можете все потребности закрывать только с помощью OpenVPN.
5️⃣ Есть клиенты под все системы. Сервер очень старый, есть куча инструкций, понятны параметры, много специалистов. Всё расписано и изучено за многие годы.
6️⃣ Проблему с производительностью решили отдельным модулем ядра для OpenVPN. Я не слежу за его изменениями. Приехал он уже или нет в ядро или хотя бы в виде пакета в базовые репозитории. Но уже года два его можно скачать и самостоятельно установить, если сильно нужно.
Заметка получилась большая. Написал сходу, какие мысли пришли в голову. Я OpenVPN люблю и использую давно. При этом другие реализации и настраиваю, и использую. Как минимум WG и L2TP использую постоянно, а раньше ещё PPTP.
#openvpn
Я же хочу рассказать про старый добрый OpenVPN, который несмотря на все прочие современные реализации VPN остаётся актуален и удобен. И это не привычка и нежелание переходить на что-то новое, а объективное удобство. Перечислю несколько основных фактов, которые держат на OpenVPN.
Например, у меня есть несколько VPN серверов с внешними IP. Я их использую для доступа к закрытым ресурсам, куда разрешён доступ только мне. На этих VPN серверах перечислены по IP адресам те серверы, куда я должен подключаться через VPN. В момент моего подключения к OVPN серверу я получаю список маршрутов до этих IP адресов через VPN сервер. И только туда. Весь остальной трафик будет ходить напрямую.
Помимо маршрутов можно передавать и другие настройки. Несколько примеров:
- настройка своего внутреннего DNS сервера;
- разрешение клиентов взаимодействовать друг с другом;
- настройки внутреннего IP адреса;
- разрешение, запрет на подключение;
- разрешение, запрет сжатия трафика;
- и многие другие.
Всё это управляется централизованно на сервере. На клиентах никаких настроек менять не надо. Один раз передали конфиг с зашитыми сертификатами и всё.
Можно всё убрать и настроить простой туннель вообще без какой-либо аутентификации и шифрования:
# openvpn --remote 1.2.3.4 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2# openvpn --remote 4.3.2.1 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1Всё, серверы видят друг друга по указанным внутренним IP адресам.
Заметка получилась большая. Написал сходу, какие мысли пришли в голову. Я OpenVPN люблю и использую давно. При этом другие реализации и настраиваю, и использую. Как минимум WG и L2TP использую постоянно, а раньше ещё PPTP.
#openvpn
Please open Telegram to view this post
VIEW IN TELEGRAM
Перелопачиваю старые публикации в своём Telegram канале. Дошёл до 4,5 годичной давности. Читаю как в первый раз, очень отдалённо вспоминаю написанное. Когда постоянно пишешь или что-то делаешь, информация из памяти вымывается уже через пол года, а через год можно вообще забыть, что ты что-то делал и через поиск найти свой же материал и удивиться, что с подобным уже сталкивался. Это не только мои наблюдения, но и авторов других каналов, сайтов.
Так вот, наткнулся на одну старую публикацию, с которой решил поделиться без изменений, так как там добавить нечего. История жутковатая, так как от проблем с электричеством никто не застрахован и УПС может не спасти. Я тоже сталкивался с тем, что какие-то проблемы пробивали через УПС и вырубали сервера. Причём всё это в рамках одной стойки с двумя УПСами. Через первый УПС пробило, а через второй – нет. Я даже не могу описать, что реально происходит в сети, когда возникают странные проблемы. Советовался потом с электриками – тоже руками разводят. Мало ли, что там могло быть. Но тоже говорили, что так бывает и УПС не панацея.
Еще раз про бэкапы. Заглянул на днях человек в чат и рассказал историю о том, что скачок электричества грохнул УПС и сам сервер. В итоге он не стартует. Интерфейс у дисков SAS, ему воткнуть их некуда. Бэкап на сервере, все по классике 🙂 Но призадумался я вот над чем. А ведь такой скачок может и бэкап сервер грохнуть, если он с основными серверами в одной серверной и от одной линии питается. Так что удаленные бэкапы обязательно должны быть. У меня у одного заказчика как-то пожар был и вообще всё сгорело. Переехали в другой офис и восстановили деятельность. До сих пор работают. Данные не потеряли.
Так вот, наткнулся на одну старую публикацию, с которой решил поделиться без изменений, так как там добавить нечего. История жутковатая, так как от проблем с электричеством никто не застрахован и УПС может не спасти. Я тоже сталкивался с тем, что какие-то проблемы пробивали через УПС и вырубали сервера. Причём всё это в рамках одной стойки с двумя УПСами. Через первый УПС пробило, а через второй – нет. Я даже не могу описать, что реально происходит в сети, когда возникают странные проблемы. Советовался потом с электриками – тоже руками разводят. Мало ли, что там могло быть. Но тоже говорили, что так бывает и УПС не панацея.
Еще раз про бэкапы. Заглянул на днях человек в чат и рассказал историю о том, что скачок электричества грохнул УПС и сам сервер. В итоге он не стартует. Интерфейс у дисков SAS, ему воткнуть их некуда. Бэкап на сервере, все по классике 🙂 Но призадумался я вот над чем. А ведь такой скачок может и бэкап сервер грохнуть, если он с основными серверами в одной серверной и от одной линии питается. Так что удаленные бэкапы обязательно должны быть. У меня у одного заказчика как-то пожар был и вообще всё сгорело. Переехали в другой офис и восстановили деятельность. До сих пор работают. Данные не потеряли.
🔥Central Log Management for Docker + Linux // Grafana Loki
Хорошее подробное видео от очень жизнерадостного блогера на тему установки и настройки централизованного хранилища для сбора логов Loki. Тут будет и теория, и установка, и сбор логов. Полный комплект.
⇨ Получаем бесплатные TLS-сертификаты: обычные и wildcard
Подробное руководство по настройке получения бесплатных сертификатов от Let's Encrypt с использованием certbot (простые сертификаты) и acme.sh (для widlcard-сертификатов). Я, кстати, немного попользовался acme.sh и вернулся обратно на certbot. Последний показался всё же более удобным, несмотря на его зависимости и более сложную структуру по сравнению с acme.sh.
⇨ Beszel - Simple, Powerful Server Monitoring!
Простая и лёгкая в настройке система мониторинга Beszel. На вид понравилась. Надо будет развернуть, попробовать и написать обзор.
⇨ Erugo: A Better Alternative to WeTransfer (Self-Hosted!)
Обзор open source системы Erugo для передачи файлов между пользователями, которую можно развернуть на своём сервере. Не скажу, что она мне сильно понравилась на обзоре, но так как аналогов особо не знаю, решил написать, чтобы если что потом попробовать, если понадобится.
⇨ Запуск Deepseek-v3 671b на своем сервере
В прошлой подборке было видео с обзором нового сервера под ИИ, а в этой автор запускает на нём топовую open source модель Deepseek-v3 671b.
⇨ VDO.Ninja - Open Source, Powerful P2P Online Meetings
Подробный обзор, установка с настройкой open source системы VDO.Ninja для проведения видео и аудио конференций, которая в том числе умеет записывать видео с камеры и экран компьютера. То есть можно свои ролики записывать с её помощью. Впервые услышал про эту систему. Судя по всему, это аналог BigBlueButton, Jitsi, MiroTalk P2P.
⇨ Kafka: Зачем она нужна и какие проблемы решает?
Наглядное повествование на тему того, что такое Kafka. Интересно будет только тем, кто не знает, что это такое.
⇨ Протокол DNS в Wireshark | Компьютерные сети 2025 - 20
⇨ Типы записей DNS | Компьютерные сети 2025 - 21
Очередные уроки с курса по сетям от Созыкина Андрея.
🔥Convert VMware to Proxmox // Use Veeam Community Edition for Migration
Перенос виртуалок с VMware в Proxmox с помощью бесплатной программы Veeam Backup & Replication Community Edition. Автор отдельно отметил, что в Proxmox есть встроенный инструмент для переноса виртуалок с VMware, но он очень медленный и с ним есть проблемы. А Veeam поддерживает оба гипервизора, так что просто бэкапим виртуалку с одного и восстанавливаем на другом.
⇨ OPNsense Transparent Filitering Bridge Прозрачный фильтрующий мост
У автора есть серия качественных роликов про программный шлюз OPNsense. Это один из них на тему, даже не знаю, какую тему. Я по названию не понял, о чём будет речь. А речь там по сути про настройку firewall.
Отдельно отмечу, что канал DevOps Channel выложил кучу записей с прошлогодней конференции DevOpsConf. Там очень много выступлений. Каждый может подобрать себе то, что его интересует. Я пока ничего не смотрел.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Заметка выходного дня. Прослушал старую песню времён блокировок Telegram от группы Дореволюционный советчик. Удивительно, как получилось. В наши дни эта песня стала актуальна даже больше, чем в то время, когда записывалась. Это своего рода гениальность и заявка на классику.
Например, за репосты раньше чисто гипотетически можно было пострадать, а сейчас готова полноценная юридическая база под это дело. Есть реестр блогеров с 10к+ подписчиками. Если какой-то канал не добавил себя в этот реестр, то репостить его публикации нельзя. Какие там ссанкции уже не помню, но они чётко обозначены без неоднозначных толкований.
Ожидаем блокировки Вотсапъ и Порнхабъ. Пишу, кстати, из деревни, VPN включен. У песни отличное исполнение и текст. Мне очень нравится.
Которыя сутки не грузитъ страницы,
Процессоръ скрипитъ, словно старый сарай.
Настройте же прокси, креаторъ Голицынъ,
Админъ Оболенскій, раздайте вай-фай.
Сидятъ черезъ SOCKS баринъ и пролетарій -
Народъ на Руси оказался непростъ,
Но въ чатахъ публичныхъ не спятъ комиссары,
И могутъ тебя посадить за репостъ.
Но какъ же намъ, право, безъ дѣвичьей ласки,
Безъ теплыхъ эмодзи, шальныхъ телеграмъ?
Манагеръ Голицынъ, а можетъ быть въ Аську?
Генъ. диръ. Оболенскій, давайте въ ТАМЪ-ТАМЪ.
Сатрапы режима, холопы системы
Заблочатъ Вотсапъ и закроютъ Порнхабъ,
Куда теперь постить забойные мемы
И кто проорётся съ моихъ фотожабъ…
Сидимъ съ VPN-номъ въ глухой деревенькѣ.
На синемъ экранѣ сіяютъ скрипты.
Предатель Голицынъ раздайте печеньки,
Масонъ Оболенскій, пишите посты.
#юмор
Например, за репосты раньше чисто гипотетически можно было пострадать, а сейчас готова полноценная юридическая база под это дело. Есть реестр блогеров с 10к+ подписчиками. Если какой-то канал не добавил себя в этот реестр, то репостить его публикации нельзя. Какие там ссанкции уже не помню, но они чётко обозначены без неоднозначных толкований.
Ожидаем блокировки Вотсапъ и Порнхабъ. Пишу, кстати, из деревни, VPN включен. У песни отличное исполнение и текст. Мне очень нравится.
Которыя сутки не грузитъ страницы,
Процессоръ скрипитъ, словно старый сарай.
Настройте же прокси, креаторъ Голицынъ,
Админъ Оболенскій, раздайте вай-фай.
Сидятъ черезъ SOCKS баринъ и пролетарій -
Народъ на Руси оказался непростъ,
Но въ чатахъ публичныхъ не спятъ комиссары,
И могутъ тебя посадить за репостъ.
Но какъ же намъ, право, безъ дѣвичьей ласки,
Безъ теплыхъ эмодзи, шальныхъ телеграмъ?
Манагеръ Голицынъ, а можетъ быть въ Аську?
Генъ. диръ. Оболенскій, давайте въ ТАМЪ-ТАМЪ.
Сатрапы режима, холопы системы
Заблочатъ Вотсапъ и закроютъ Порнхабъ,
Куда теперь постить забойные мемы
И кто проорётся съ моихъ фотожабъ…
Сидимъ съ VPN-номъ въ глухой деревенькѣ.
На синемъ экранѣ сіяютъ скрипты.
Предатель Голицынъ раздайте печеньки,
Масонъ Оболенскій, пишите посты.
#юмор
На днях разбирался с одной относительно простой задачей, но из-за того, что затупил, потратил на неё очень много времени. Так как проделал множество всевозможных операций, решил всё подробно описать. Пригодится в других похожих историях.
Есть MySQL сервер, у которого, как мне показалось, очень большая нагрузка по CPU. Проект немного стух, записи в базу должно быть мало и мне было странно видеть высокую нагрузку от СУБД. Решил разобраться, в чём там дело.
Для начала просто посмотрел нагрузку через
В таких случаях часто помогает strace. Можно подцепиться к процессу и посмотреть, что он пишет:
В моём случае я не получил результата. В выводе просто было пусто. Я не понял, почему. Стал разбираться дальше. Смотрю потоки процесса:
Вижу, что CPU нагружает сильно больше всех остальных один поток с SPID 19547. Смотрю по нему информацию:
В выводе только цифры и отсылка к основному потоку mysqld. То есть вообще не понятно, что там реально происходит.
Тут до меня доходит подцепиться к потоку через strace:
Вижу системные вызовы futex (синхронизацией потоков), io_submit (асинхронные операции ввода-вывода) и некоторые другие.
Смотрю, в какие файлы пишет mysqld:
Это
А на серваке выполнялись десятки простых SELECT за считанные миллисекунды или ещё быстрее. Не отслеживал. И они тупо не попадали в вывод. И я думал, что запросов мало, а их было дохрена. Они и давали нагрузку на CPU.
Запросы увидел так. Не перезапуская сервер выполнил в консоли mysql:
Так же это было видно в выводе:
В разделе I/O. Эти потоки отвечают за асинхронные операции ввода-вывода (AIO).
Достаточно было на несколько секунд запустить, чтобы понять всю картину. Потом сразу отключил, чтобы не нагружать диски.
Осталось разобраться, а что на диск то записывается. Вроде как файлы
xb_doublewrite - это некий буфер InnoDB для повышения надёжности хранения, отключать не рекомендуется, хотя можно.
В общем, время я по сути потратил впустую, если не считать вот эту заметку итоговым результатом. Думаю, она мне ещё понадобится. Времени уже не оставалось дальше разбираться с этой историей. В целом, нагрузка там рабочая, абсолютно некритичная, так что разбираться с ней дальше большой нужды не было. Но я всё равно планирую подумать, как её снизить. И вообще не совсем понятно, почему её так много, с учётом того, что сайт активно кэшируется. Надо будет разбираться.
Отдельно отмечу, что очень активно нагружал этой темой DeepSeek, но он особо не помог. Да, много всякой информации давал и анализировал мои результаты, но фактически я сам догадался в чём причина. Он как-то больше по кругу ходил и всякие команды накидывал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #perfomance
Есть MySQL сервер, у которого, как мне показалось, очень большая нагрузка по CPU. Проект немного стух, записи в базу должно быть мало и мне было странно видеть высокую нагрузку от СУБД. Решил разобраться, в чём там дело.
Для начала просто посмотрел нагрузку через
top. Mysql почти постоянно кушает одно ядро и периодически остальные дёргает. Дополнительно смотрю в iotop и pidstat и вижу постоянно запись со стороны службы mysqld с pid 19535:# iotop -obPat# pidstat -p 19535 -d 1В таких случаях часто помогает strace. Можно подцепиться к процессу и посмотреть, что он пишет:
# strace -e trace=write -p 19535В моём случае я не получил результата. В выводе просто было пусто. Я не понял, почему. Стал разбираться дальше. Смотрю потоки процесса:
# ps -L -o spid,%mem,%cpu,cmd 16005Вижу, что CPU нагружает сильно больше всех остальных один поток с SPID 19547. Смотрю по нему информацию:
# cat /proc/19535/task/19547/stat# cat /proc/19535/task/19547/statusВ выводе только цифры и отсылка к основному потоку mysqld. То есть вообще не понятно, что там реально происходит.
Тут до меня доходит подцепиться к потоку через strace:
# strace -p 19547Вижу системные вызовы futex (синхронизацией потоков), io_submit (асинхронные операции ввода-вывода) и некоторые другие.
Смотрю, в какие файлы пишет mysqld:
# inotifywait -m /var/lib/mysqlЭто
ib_logfile0 и xb_doublewrite. Никак не могу понять, почему он туда активно пишет, когда запросов к базе особо нет. И вот тут я как раз и затупил. Я смотрел запросы через mytop и SHOW FULL PROCESSLIST; И там их было очень мало. Эти команды показывают запросы в моменте.А на серваке выполнялись десятки простых SELECT за считанные миллисекунды или ещё быстрее. Не отслеживал. И они тупо не попадали в вывод. И я думал, что запросов мало, а их было дохрена. Они и давали нагрузку на CPU.
Запросы увидел так. Не перезапуская сервер выполнил в консоли mysql:
> SET GLOBAL general_log = 'ON';> SET GLOBAL general_log_file = '/var/log/mysql/general.log';Так же это было видно в выводе:
> SHOW ENGINE INNODB STATUS;В разделе I/O. Эти потоки отвечают за асинхронные операции ввода-вывода (AIO).
Достаточно было на несколько секунд запустить, чтобы понять всю картину. Потом сразу отключил, чтобы не нагружать диски.
Осталось разобраться, а что на диск то записывается. Вроде как файлы
ib_logfile0 это файлы журналов транзакций InnoDB, а разве SELECT вызывает транзакции? Я тут сильно не погружался, но мельком глянул информацию и понял, что всякие очистки устаревших данных, обновление статистики, индексов, хэшей могут тоже провоцировать запись, а точнее обновление этого файла.xb_doublewrite - это некий буфер InnoDB для повышения надёжности хранения, отключать не рекомендуется, хотя можно.
В общем, время я по сути потратил впустую, если не считать вот эту заметку итоговым результатом. Думаю, она мне ещё понадобится. Времени уже не оставалось дальше разбираться с этой историей. В целом, нагрузка там рабочая, абсолютно некритичная, так что разбираться с ней дальше большой нужды не было. Но я всё равно планирую подумать, как её снизить. И вообще не совсем понятно, почему её так много, с учётом того, что сайт активно кэшируется. Надо будет разбираться.
Отдельно отмечу, что очень активно нагружал этой темой DeepSeek, но он особо не помог. Да, много всякой информации давал и анализировал мои результаты, но фактически я сам догадался в чём причина. Он как-то больше по кругу ходил и всякие команды накидывал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #perfomance
Продолжаю пересматривать старые заметки. Нашёл показательную новость от 2020 года, которую скорее всего все уже позабыли.
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
Увидел недавно видеообзор простой бесплатной системы для организации видео и аудио конференций VDO.Ninja, которую можно развернуть на своём сервере. На первый взгляд может показаться, зачем всё это надо, если есть куча бесплатных. Но с другой стороны все эти бесплатные системы требуют регистрацию, персональные данные, часто с подтверждением аккаунта по номеру телефона.
Допустим, у вас переговорная комната. Чья учётка там должна быть введена? Всем участникам нужно будет где-то аккаунты заводить. Проще, когда у вас будет своя система, всегда готовая к работе. Если пользуетесь редко, то покупать платную не имеет большого смысла.
Отдельный разговор какие-нибудь небольшие учебные заведения, где тоже нет денег на платные системы. В общем, бесплатные конференции типа BigBlueButton, Jitsi, MiroTalk P2P имеют право на жизнь. VDO.Ninja из их числа. Решил её развернуть и попробовать в работе.
В основе VDO.Ninja, как и почти всех подобных современных программ, лежит протокол WebRTC. Все конференции проходят в браузере, дополнительные программы устанавливать не нужно. Причём это же относится и к мобильным устройствам. Отдельно отмечу, что с помощью VDO.Ninja можно постоянно транслировать поток с видеокамеры в интернет, в том числе используя свой смартфон в качестве камеры.
Для быстрого запуска VDO.Ninja можно воспользоваться готовым контейнером Docker:
Достаточно указать URL с настроенной DNS записью для того, чтобы автоматически получит TLS сертификат. После запуска контейнера он будет получен и установлен. Буквально через минуту можно идти и использовать сервис. Для того, чтобы его посмотреть, разворачивать у себя не обязательно. Это будет точная копия, 1 в 1, как и публичный сервис на сайте https://vdo.ninja.
Я развернул и немного потестировал. Никаких сложностей не возникло. Всё сразу заработало. Отмечу некоторые особенности:
▪️Конференции сразу работают в браузере смартфона. Можно подключить любую камеру в качестве источника картинки. То есть можем получить беспроводную мобильную камеру.
▪️Можно открыть доступ к экрану смартфона, но для этого придётся установить мобильное приложение. Браузер такой режим не поддерживает.
▪️Сервис работает без аутентификации. Каждый может получить доступ по ссылке (конференция или комната может закрываться паролем). Придётся внедрять какую-то стороннюю аутентификацию через проксирование, или закрывать файрволом.
▪️Поддерживается запись видео как организатором, так и участниками.
▪️Можно делать постоянные ссылки для конференций.
▪️Можно создавать общую комнату для входа и потом в ручном режиме раскидывать подключившихся по другим комнатам.
▪️Удобный интерфейс организатора. Он может управлять гостями, раскладкой, выключать, приглушать или увеличивать звук гостя, открывать отдельной ссылкой поток гостя, включать запись, управлять качеством, в том числе и гостей и т.д.
▪️Пригласительные ссылки могут быть в виде QR кодов.
▪️Можно открывать доступ к отдельной вкладке браузера или запущенного приложения.
Приложение очень понравилось – простое и функциональное. Есть всё, что можно только придумать для такого рода сервисов. Не хватает только какой-то базовой аутентификации, чтобы ограничить доступ к главной странице. По умолчанию каждый может на неё зайти и создать конференцию.
⇨ 🌐 Сайт / Исходники / Docker
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#видеоконференции
Допустим, у вас переговорная комната. Чья учётка там должна быть введена? Всем участникам нужно будет где-то аккаунты заводить. Проще, когда у вас будет своя система, всегда готовая к работе. Если пользуетесь редко, то покупать платную не имеет большого смысла.
Отдельный разговор какие-нибудь небольшие учебные заведения, где тоже нет денег на платные системы. В общем, бесплатные конференции типа BigBlueButton, Jitsi, MiroTalk P2P имеют право на жизнь. VDO.Ninja из их числа. Решил её развернуть и попробовать в работе.
В основе VDO.Ninja, как и почти всех подобных современных программ, лежит протокол WebRTC. Все конференции проходят в браузере, дополнительные программы устанавливать не нужно. Причём это же относится и к мобильным устройствам. Отдельно отмечу, что с помощью VDO.Ninja можно постоянно транслировать поток с видеокамеры в интернет, в том числе используя свой смартфон в качестве камеры.
Для быстрого запуска VDO.Ninja можно воспользоваться готовым контейнером Docker:
# docker run -dit -p 80:80 -p 443:443 --restart=unless-stopped --name vdo.ninja -e SERVER_URL=$HOSTNAME -e EMAIL_ADDRESS=emailforcert@domain.com umlatt/vdo.ninjaДостаточно указать URL с настроенной DNS записью для того, чтобы автоматически получит TLS сертификат. После запуска контейнера он будет получен и установлен. Буквально через минуту можно идти и использовать сервис. Для того, чтобы его посмотреть, разворачивать у себя не обязательно. Это будет точная копия, 1 в 1, как и публичный сервис на сайте https://vdo.ninja.
Я развернул и немного потестировал. Никаких сложностей не возникло. Всё сразу заработало. Отмечу некоторые особенности:
▪️Конференции сразу работают в браузере смартфона. Можно подключить любую камеру в качестве источника картинки. То есть можем получить беспроводную мобильную камеру.
▪️Можно открыть доступ к экрану смартфона, но для этого придётся установить мобильное приложение. Браузер такой режим не поддерживает.
▪️Сервис работает без аутентификации. Каждый может получить доступ по ссылке (конференция или комната может закрываться паролем). Придётся внедрять какую-то стороннюю аутентификацию через проксирование, или закрывать файрволом.
▪️Поддерживается запись видео как организатором, так и участниками.
▪️Можно делать постоянные ссылки для конференций.
▪️Можно создавать общую комнату для входа и потом в ручном режиме раскидывать подключившихся по другим комнатам.
▪️Удобный интерфейс организатора. Он может управлять гостями, раскладкой, выключать, приглушать или увеличивать звук гостя, открывать отдельной ссылкой поток гостя, включать запись, управлять качеством, в том числе и гостей и т.д.
▪️Пригласительные ссылки могут быть в виде QR кодов.
▪️Можно открывать доступ к отдельной вкладке браузера или запущенного приложения.
Приложение очень понравилось – простое и функциональное. Есть всё, что можно только придумать для такого рода сервисов. Не хватает только какой-то базовой аутентификации, чтобы ограничить доступ к главной странице. По умолчанию каждый может на неё зайти и создать конференцию.
⇨ 🌐 Сайт / Исходники / Docker
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#видеоконференции
Хочу сделать предостережение, основанное на личном опыте. Делал рядовое обновление сервера, которое требовало перезагрузку. Сервер далеко, в необслуживаемой серверной. То есть там никого нет вечером, кто смог бы хоть что-то сделать. Как обычно, время выбрал позднее, так как на сервере полезная нагрузка. Его активно используют люди в течении рабочего дня. И кто бы мог подумать, что сервер не выйдет из перезагрузки.
Нет проблем. Сервер Supermicro, там IPMI, сейчас посмотрим консоль и поймем, в чём там дело. И тут начинаются танцы. Сервер старый, версия BMC древняя. Для подключения к консоли нужна java какой-то старой версии. Апплет не запускается, так как блочится настройками безопасности из-за отсутствия сертификата и актуальной версии TLS. В общем, мрак. Думаю тем, кто используют старые Supermicro, хорошо знакома эта тема. Я давно их не покупаю. Если брать б.у., то предпочту Dell. Там BMC удобный.
Проблемы в итоге решил, подключился и всё сделал. А мораль тут такова – перед перезагрузкой сервера, проверьте, есть ли у вас доступ к консоли, так что для меня reboot – это всегда потенциальная возможность потерять доступ к серверу. Обязательно проверяю бэкапы перед этим и доступ к консоли сервера. И всегда держу в голове схему, что я буду делать, если сервер не поднимется. А после установки обновления это не такая уж и большая редкость. Я столько всяких историй проходил. Было много примеров, некоторые описывал в статьях:
◽️Yum после обновления упал с ошибкой и не пересобрал initramfs под новое ядро. Спасла загрузка на старом.
◽️У сервера уменьшили на лету размер корневого раздела. После перезагрузки grub его потерял.
◽️Как-то раз просто на всякий случай зашёл в админку хостера проверить, есть ли доступ к консоли. А её не оказалось, просто чёрный экран. Через техподдержку решили вопрос. Был глюк.
◽️У GRUB2 как-то раз вышло обновление, которое приводило к невозможности загрузки.
◽️Как-то раз сервер с большим диском запустил проверку файловой системы во время загрузки. Длилась она пару часов. Останавливать не решился, сидел и ждал, чем закончится. Причём счетчика времени не было. Думал уже что всё, данным кирдык.
◽️Один хостер с арендным сервером высылал доступ к консоли по VNC в момент оформления. Заказчик благополучно всё это где-то потерял, а когда нужно было срочно подключиться, пришлось искать и восстанавливать эти доступы через тех. поддержку. А для этого ещё и VPN настраивать надо было.
Это только то, что бегло вспомнил. Были и другие истории. Если сталкивались с чем-то подобным, то поделитесь своими инцидентами. Можно будет подборку сделать. Мне кажется, их может много набраться.
#совет
Нет проблем. Сервер Supermicro, там IPMI, сейчас посмотрим консоль и поймем, в чём там дело. И тут начинаются танцы. Сервер старый, версия BMC древняя. Для подключения к консоли нужна java какой-то старой версии. Апплет не запускается, так как блочится настройками безопасности из-за отсутствия сертификата и актуальной версии TLS. В общем, мрак. Думаю тем, кто используют старые Supermicro, хорошо знакома эта тема. Я давно их не покупаю. Если брать б.у., то предпочту Dell. Там BMC удобный.
Проблемы в итоге решил, подключился и всё сделал. А мораль тут такова – перед перезагрузкой сервера, проверьте, есть ли у вас доступ к консоли, так что для меня reboot – это всегда потенциальная возможность потерять доступ к серверу. Обязательно проверяю бэкапы перед этим и доступ к консоли сервера. И всегда держу в голове схему, что я буду делать, если сервер не поднимется. А после установки обновления это не такая уж и большая редкость. Я столько всяких историй проходил. Было много примеров, некоторые описывал в статьях:
◽️Yum после обновления упал с ошибкой и не пересобрал initramfs под новое ядро. Спасла загрузка на старом.
◽️У сервера уменьшили на лету размер корневого раздела. После перезагрузки grub его потерял.
◽️Как-то раз просто на всякий случай зашёл в админку хостера проверить, есть ли доступ к консоли. А её не оказалось, просто чёрный экран. Через техподдержку решили вопрос. Был глюк.
◽️У GRUB2 как-то раз вышло обновление, которое приводило к невозможности загрузки.
◽️Как-то раз сервер с большим диском запустил проверку файловой системы во время загрузки. Длилась она пару часов. Останавливать не решился, сидел и ждал, чем закончится. Причём счетчика времени не было. Думал уже что всё, данным кирдык.
◽️Один хостер с арендным сервером высылал доступ к консоли по VNC в момент оформления. Заказчик благополучно всё это где-то потерял, а когда нужно было срочно подключиться, пришлось искать и восстанавливать эти доступы через тех. поддержку. А для этого ещё и VPN настраивать надо было.
Это только то, что бегло вспомнил. Были и другие истории. Если сталкивались с чем-то подобным, то поделитесь своими инцидентами. Можно будет подборку сделать. Мне кажется, их может много набраться.
#совет
Server Admin
Kernel panic not syncing: VFS: Unable to mount root fs |...
Решение проблемы, когда сервер не загружается и показывает ошибку Kernel panic not syncing: VFS: Unable to mount root fs.
К одной из старых заметок про панель панель управления сервером поступил комментарий в ВК про незнакомую мне панель Homarr. Автор её похвалил. Глянул быстро в github, там очень мало звёзд. Думаю, какая-то новая непопулярная панель, незаслуживающая пока внимания. Подобных проектов много.
Зацепился взгляд за забавный слоган, который раньше не доводилось встречать: Easy and fast app management - No YAML / JSON configurations are involved. Обычно конфигурации в этих форматах преподносятся как удобство и унификация, а тут всё наоборот. Отсутствие этих форматов преподносится как преимущество и упрощение управления. В общем, решил панель посмотреть.
Итак, что такое Homarr? Это web страница с виджетами, которые через встроенные интеграции показывают различную информацию от поддерживаемых сервисов, либо допускают управление ими. Например, виртуалками Proxmox, контейнерами Docker. Можно просто смотреть статус различных сервисов: устройств в Home Assistent, блокировок в Pi-Hole или Adguard, загрузки в торрент клиентах, состояние медиасерверов и т.д. Также туда можно какие-то RSS ленты выводить, погоду, часы, ссылки и т.д. Есть виджеты для простого мониторинга – доступность хостов, коды HTTP ответов.
По описанию понятна сфера применения – управление личным хозяйством в домашней лаборатории. На работе подобные панели ставить не стоит. Хотя, если у вас в управлении небольшой бизнес, который вы обслуживаете в одно лицо, то почему и нет, если вам так будет удобнее. С другой стороны, там есть API, а следовательно возможность автоматизировать создание виджетов, например, со ссылками на веб ресурсы, где будет автоматически проверяться код ответа. Если у вас проект с набором отдельных веб-ресурсов, можно быстро собирать дашборд со статусом. Зелёный виджет – всё ОК, красный – проблемы. Плюс, я знаю, что некоторые люди делают такие дашборды со ссылками на внутренние ресурсы компании для пользователей.
Homarr поставляет в преднастроенном контейнере Docker, так что разворачивается в пару действий. Потом всё управление только через веб интерфейс. Никаких конфигураций и консоли. Про запуск не буду рассказывать, чтобы не загромождать заметку тем, что есть в документации.
📌 Особенности Homarr:
▪️Как я уже сказал, всё управление через веб интерфейс.
▪️Есть аутентификация пользователей, в том числе из LDAP.
▪️Можно создавать публичные панели, доступные без аутентификации.
▪️У пользователя может быть несколько разных панелей.
▪️Есть тёмная светлая тема, русский язык.
▪️Можно добавлять свои иконки для сервисов.
▪️Проект живой с большим, активным сообществом, постоянные обновления.
▪️Есть API.
Аналоги:
- Dashy
- Heimdall
- Homepage
Heimdall я пользовался немного, но забросил. Лично у меня нет потребности в подобных панелях. У меня всё подобное в Zabbix + Grafana живёт. Но я просто умею их настраивать. Чтобы всякие разные визуализации и интеграции делать надо хорошо во всём этом разбираться. А в подобной панели доступная функциональность настраивается мышкой в веб интерфейсе за вечер, но в пределах возможных интеграций.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#dashboard
Зацепился взгляд за забавный слоган, который раньше не доводилось встречать: Easy and fast app management - No YAML / JSON configurations are involved. Обычно конфигурации в этих форматах преподносятся как удобство и унификация, а тут всё наоборот. Отсутствие этих форматов преподносится как преимущество и упрощение управления. В общем, решил панель посмотреть.
Итак, что такое Homarr? Это web страница с виджетами, которые через встроенные интеграции показывают различную информацию от поддерживаемых сервисов, либо допускают управление ими. Например, виртуалками Proxmox, контейнерами Docker. Можно просто смотреть статус различных сервисов: устройств в Home Assistent, блокировок в Pi-Hole или Adguard, загрузки в торрент клиентах, состояние медиасерверов и т.д. Также туда можно какие-то RSS ленты выводить, погоду, часы, ссылки и т.д. Есть виджеты для простого мониторинга – доступность хостов, коды HTTP ответов.
По описанию понятна сфера применения – управление личным хозяйством в домашней лаборатории. На работе подобные панели ставить не стоит. Хотя, если у вас в управлении небольшой бизнес, который вы обслуживаете в одно лицо, то почему и нет, если вам так будет удобнее. С другой стороны, там есть API, а следовательно возможность автоматизировать создание виджетов, например, со ссылками на веб ресурсы, где будет автоматически проверяться код ответа. Если у вас проект с набором отдельных веб-ресурсов, можно быстро собирать дашборд со статусом. Зелёный виджет – всё ОК, красный – проблемы. Плюс, я знаю, что некоторые люди делают такие дашборды со ссылками на внутренние ресурсы компании для пользователей.
Homarr поставляет в преднастроенном контейнере Docker, так что разворачивается в пару действий. Потом всё управление только через веб интерфейс. Никаких конфигураций и консоли. Про запуск не буду рассказывать, чтобы не загромождать заметку тем, что есть в документации.
📌 Особенности Homarr:
▪️Как я уже сказал, всё управление через веб интерфейс.
▪️Есть аутентификация пользователей, в том числе из LDAP.
▪️Можно создавать публичные панели, доступные без аутентификации.
▪️У пользователя может быть несколько разных панелей.
▪️Есть тёмная светлая тема, русский язык.
▪️Можно добавлять свои иконки для сервисов.
▪️Проект живой с большим, активным сообществом, постоянные обновления.
▪️Есть API.
Аналоги:
- Dashy
- Heimdall
- Homepage
Heimdall я пользовался немного, но забросил. Лично у меня нет потребности в подобных панелях. У меня всё подобное в Zabbix + Grafana живёт. Но я просто умею их настраивать. Чтобы всякие разные визуализации и интеграции делать надо хорошо во всём этом разбираться. А в подобной панели доступная функциональность настраивается мышкой в веб интерфейсе за вечер, но в пределах возможных интеграций.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#dashboard