На прошлой неделе была рассылка от Zabbix. В ней анонсировали запуск Zabbix Cloud. Я сразу предположил, что они запустят свой облачный сервис после недавней замены лицензии GPL на AGPL. Так и случилось. Решил проверить, что это такое и как работает.
После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.
По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.
Каких-то особых фишек и возможностей не увидел, кроме автоматического обновления до новых версий сервера. Причём отказаться от такого обновления вы не сможете. Автоматические бэкапы обещают раз в неделю. Чаще можно делать вручную через веб панель управления нодой. Выгрузить свой бэкап за пределы облака нельзя, как и загрузить туда версию своего сервера. Восстановление из бэкапа только там. Наверняка есть какой-то тюнинг СУБД, чтобы всё это работало побыстрее, чем дефолтная установка.
В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.
Вторая идея - преднастроенные агенты. Скачиваешь из веб интерфейса сервера дистрибутив агента с уже зашитыми настройками подключения к серверу и некоторых параметров. По идее это нетрудно сделать, а удобство развёртывания сильно повышается. Не надо свои инструменты придумывать для быстрой раскатки агентов с подстановкой нужных конфигов.
#zabbix
После регистрации ждал примерно день, пока активируют учётную запись. Судя по всему, вручную это делают. После подтверждения на email создания личного кабинета, зашёл в него и активировал trial на 5 дней. Выбрал ноду во Франкфурте и развернул её.
По своей сути я получил обычный Zabbix Server, развёрнутый на серверах облака. Мне дали адрес веб интерфейса, логин, пароль. Внутри самый обычный Zabbix Server, к которому я могу подключать агентов. Он ничем не отличается от такого же, который я могу развернуть на арендованном сервере.
Каких-то особых фишек и возможностей не увидел, кроме автоматического обновления до новых версий сервера. Причём отказаться от такого обновления вы не сможете. Автоматические бэкапы обещают раз в неделю. Чаще можно делать вручную через веб панель управления нодой. Выгрузить свой бэкап за пределы облака нельзя, как и загрузить туда версию своего сервера. Восстановление из бэкапа только там. Наверняка есть какой-то тюнинг СУБД, чтобы всё это работало побыстрее, чем дефолтная установка.
В таком виде вообще не увидел никакого смысла в saas. Развернуть голый Zabbix Server - дело 10-ти минут. Возможно в будущем появятся какие-то дополнительные возможности и удобства. Например, какой-то механизм автоматического обновления шаблонов. Это прям тяжёлая для меня тема, когда нужно обновить стандартный шаблон на новую версию. Нет простого способа это сделать без удаления старого, очистки всех метрик и добавления нового шаблона. Не хватает какого-то механизма сравнения и склеивания шаблонов для обновления до свежей версии.
Вторая идея - преднастроенные агенты. Скачиваешь из веб интерфейса сервера дистрибутив агента с уже зашитыми настройками подключения к серверу и некоторых параметров. По идее это нетрудно сделать, а удобство развёртывания сильно повышается. Не надо свои инструменты придумывать для быстрой раскатки агентов с подстановкой нужных конфигов.
#zabbix
Для автоматизации установки и настройки виртуальных машин в Proxmox я рассказывал про Cloud-Init. С помощью этой технологии можно создать преднастроенный образ, который включает в себя базовые настройки системы, такие как сеть, пользователи, установка пакетов и некоторые другие.
Если хочется пойти дальше в автоматизации и развернуть сразу набор виртуальных машин определённой конфигурации, то для этого можно воспользоваться Terraform. Для Proxmox есть провайдер (terraform registry доступ через vpn, github). Это самый популярный. Есть ещё один, который очень активно развивается и допиливается - terraform registry и github.
Кратко поясню, для тех, кто не знает, что такое Terraform и для чего он может быть полезен в связке с Proxmox. Terraform был разработан как решение по управлению в стиле IaC (Infrastructure as Code, IaC) - инфраструктура как код. В первую очередь это касается управления ресурсами облачных провайдеров. Вы описываете в Terraform, что хотите получить на выходе, запускаете шаблон и получаете набор виртуальных машин, сетей и прочих облачных ресурсов. Причём вы можете оперативно как развернуть инфраструктуру, так и потушить. Это актуально для динамических сред с плавающей нагрузкой. Часто Terraform работает в связке с Ansible. Первый разворачивает инфраструктуру, второй её настраивает.
Proxmox не является инструментом для построения динамичных облачных инфраструктур. Его область применения - одиночные гипервизоры или небольшие кластеры на несколько серверов. По моим представлениям в проде на базе Proxmox нет большой нужды использовать Terraform. Он может быть актуален для каких-то тестовых задач как по изучению самого Terraform, так и для разворачивания тестового окружения в Proxmox. Можно разом развернуть какую-то лабораторию и потом так же в одно действие от неё избавиться.
Использование Terraform с Proxmox выглядит примерно следующим образом. Это не будет готовой инструкцией, так как в формат заметки не уместить. Все подробности без проблем гуглятся, так как тема живая. В целом, Terraform относительно простой инструмент. Чтобы начать им пользоваться достаточно небольшой инструкции или видео. Можно брать готовые шаблоны из статей или документации и править под себя.
1️⃣ Готовится образ с использованием Cloud-Init, на базе которого будет разворачиваться инфраструктура.
2️⃣ Создаётся отдельный пользователь и токен для него, который будет использовать Terraform.
3️⃣ Устанавливается Terraform или Opentofu (форк).
4️⃣ Создаётся конфигурация с провайдером и планон разворачивания инфраструктуры. Будут 2 файла: provider.tf и vm-debian12.tf. Содержимое прикреплю следующим сообщением. По желанию можно все переменные вынести в отдельный файл.
Пример конфигурации можно посмотреть в репозитории. После подготовки конфигурации, её можно проверить:
Посмотреть, что будет создано:
Если всё ОК, то создаём описанное:
Когда всё это будет не нужно, удаляем:
В моём примере была одна виртуальная машина. По аналогии, вы можете описать любое необходимое количество. Поместить их в одну или разные сети, посадить в разные хранилища и т.д.
Как я уже говорил, инструмент относительно простой. Я быстро во всём разобрался и протестировал. Единственный неприятный нюанс - репозитории terraform и opentofu заблокированы для РФ. Пришлось трафик через VPN пускать. У меня всё автоматизировано для этого. Отправил домены registry.terraform.io, apt.releases.hashicorp.com и registry.opentofu.org через VPN на шлюзе.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #iac #terraform
Если хочется пойти дальше в автоматизации и развернуть сразу набор виртуальных машин определённой конфигурации, то для этого можно воспользоваться Terraform. Для Proxmox есть провайдер (terraform registry доступ через vpn, github). Это самый популярный. Есть ещё один, который очень активно развивается и допиливается - terraform registry и github.
Кратко поясню, для тех, кто не знает, что такое Terraform и для чего он может быть полезен в связке с Proxmox. Terraform был разработан как решение по управлению в стиле IaC (Infrastructure as Code, IaC) - инфраструктура как код. В первую очередь это касается управления ресурсами облачных провайдеров. Вы описываете в Terraform, что хотите получить на выходе, запускаете шаблон и получаете набор виртуальных машин, сетей и прочих облачных ресурсов. Причём вы можете оперативно как развернуть инфраструктуру, так и потушить. Это актуально для динамических сред с плавающей нагрузкой. Часто Terraform работает в связке с Ansible. Первый разворачивает инфраструктуру, второй её настраивает.
Proxmox не является инструментом для построения динамичных облачных инфраструктур. Его область применения - одиночные гипервизоры или небольшие кластеры на несколько серверов. По моим представлениям в проде на базе Proxmox нет большой нужды использовать Terraform. Он может быть актуален для каких-то тестовых задач как по изучению самого Terraform, так и для разворачивания тестового окружения в Proxmox. Можно разом развернуть какую-то лабораторию и потом так же в одно действие от неё избавиться.
Использование Terraform с Proxmox выглядит примерно следующим образом. Это не будет готовой инструкцией, так как в формат заметки не уместить. Все подробности без проблем гуглятся, так как тема живая. В целом, Terraform относительно простой инструмент. Чтобы начать им пользоваться достаточно небольшой инструкции или видео. Можно брать готовые шаблоны из статей или документации и править под себя.
Пример конфигурации можно посмотреть в репозитории. После подготовки конфигурации, её можно проверить:
# terraform init# terraform validateПосмотреть, что будет создано:
# terraform planЕсли всё ОК, то создаём описанное:
# terraform applyКогда всё это будет не нужно, удаляем:
# terraform destroyВ моём примере была одна виртуальная машина. По аналогии, вы можете описать любое необходимое количество. Поместить их в одну или разные сети, посадить в разные хранилища и т.д.
Как я уже говорил, инструмент относительно простой. Я быстро во всём разобрался и протестировал. Единственный неприятный нюанс - репозитории terraform и opentofu заблокированы для РФ. Пришлось трафик через VPN пускать. У меня всё автоматизировано для этого. Отправил домены registry.terraform.io, apt.releases.hashicorp.com и registry.opentofu.org через VPN на шлюзе.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #iac #terraform
Please open Telegram to view this post
VIEW IN TELEGRAM
С уходом Atlassian с рынка РФ для некоторых компаний возникла масштабная задача по переходу на какие-то другие продукты в качестве замены Jira, Confluence, кому-то возможно и Trello. У меня, кстати, последний до их пор работает. Когда-то давно поменял email на гугловский и спокойно пользуюсь по сей день.
Так вот по поводу перехода. В настоящий момент эту тему особо не обсуждают, так как пик замены пришёлся на 2022 и 2023 год. Сейчас уже всё устаканилось. В качестве замены есть вариант использовать китайский продукт ZenTao. У него есть встроенный инструмент для автоматического импорта данных из Jira. Про него не очень много информации, но я нашёл отзыв реального человека, где он дал положительную оценку продукту после годового использования. У ZenTao есть вполне функциональная open source версия, так что я решил написать про него. Возможно кому-то это будет полезно. На первый взгляд продукт выглядит неплохо.
В рунете информации о ZanTao очень мало. В основном это материалы от компании GlowByte, которая занимается продажами продукта в РФ. Ссылки на статьи:
⇨ Что такое ZenTao и как установить его на Windows за 5 минут
⇨ Как устроен модуль «Документы» в ZenTao и может ли он заменить Confluence от Atlassian
⇨ Дзен в управлении продуктами
А вот материал от неизвестного мне блогера, который написал свой отзыв после внедрения и использования продукта в течении года:
⇨ Система управления проектами ZenTao
Статья не очень большая, но информативная. Там самая суть, картинки из реальной рабочей системы и вывод после года использования:
Спустя почти год использования системы уже можно говорит о том, что мнение о системе ZenTao сложилось. Даже в бесплатной версии система управления проектами ZenTao – это тот продукт, на который стоит обратить внимание. Особенно с учетом того, что его прямые конкуренты в виде MS Project, JIRA и Trello сейчас не так легко приобрести (если вообще возможно). А с учетом стоимости и получаемого набора функций в платных версий, на мой взгляд, получается очень гуманная цена.
В ходе эксплуатации системы мы уже несколько раз устанавливали обновления, т.е. продукт активно развивается. Причем, после каждого обновления мы находили какие-то интересные опции. Например, рабочие процессы, новый раздел для обучения (Academy) и т.д.
Отдельно хочу отметить стабильность работы системы – за весь период эксплуатации не было ни одного внепланового простоя системы. Это прям очень порадовало.
Порекомендовал бы я систему ZenTao в качестве системы управления проектами? Несомненно. Хотя бы попробуйте поработать с бесплатной версией программы. И тогда вы точно сможете понять – подходит ли эта система именно вашей методологии работы с проектами или нет.
Посмотреть на ZenTao можно либо в публичном Demo, либо развернуть у себя. Есть готовые установщики под Windows и Linux, а также Docker версия. Хотел воспользоваться последней, но там всё описание на китайском. Не стал разбираться. Запустил версию под Linux:
В общем-то и всё. Приложение написано на php + mysql. Рабочий стек: Apache, PHP, MariaDB. Разработчики как-то упаковали весь стек в архив и запускают его через bash скрипт. Можно идти в веб интерфейс по IP адресу сервера и смотреть.
Различия между open source и платными редакциями можно посмотреть на отдельной странице. Приятно, что в бесплатной версии оставлена интеграция с git, gitlab, jenkins, возможность настроить ci/cd и другие штуки. Весь раздел DevOps представлен. Так же оставлена возможность вести базовую документацию. LDAP, как обычно, только в платных редакциях.
Бесплатная редакция на русском языке отсутствует, есть английский. А вот платные переведены на русский язык.
⇨ 🌐 Сайт /4️⃣ Исходники / 📺 Русскоязычная группа в TG
Бесплатные аналоги ZenTao можете посмотреть по соответствующему тэгу снизу.
#itsm #управление_проектами
Так вот по поводу перехода. В настоящий момент эту тему особо не обсуждают, так как пик замены пришёлся на 2022 и 2023 год. Сейчас уже всё устаканилось. В качестве замены есть вариант использовать китайский продукт ZenTao. У него есть встроенный инструмент для автоматического импорта данных из Jira. Про него не очень много информации, но я нашёл отзыв реального человека, где он дал положительную оценку продукту после годового использования. У ZenTao есть вполне функциональная open source версия, так что я решил написать про него. Возможно кому-то это будет полезно. На первый взгляд продукт выглядит неплохо.
В рунете информации о ZanTao очень мало. В основном это материалы от компании GlowByte, которая занимается продажами продукта в РФ. Ссылки на статьи:
⇨ Что такое ZenTao и как установить его на Windows за 5 минут
⇨ Как устроен модуль «Документы» в ZenTao и может ли он заменить Confluence от Atlassian
⇨ Дзен в управлении продуктами
А вот материал от неизвестного мне блогера, который написал свой отзыв после внедрения и использования продукта в течении года:
⇨ Система управления проектами ZenTao
Статья не очень большая, но информативная. Там самая суть, картинки из реальной рабочей системы и вывод после года использования:
Спустя почти год использования системы уже можно говорит о том, что мнение о системе ZenTao сложилось. Даже в бесплатной версии система управления проектами ZenTao – это тот продукт, на который стоит обратить внимание. Особенно с учетом того, что его прямые конкуренты в виде MS Project, JIRA и Trello сейчас не так легко приобрести (если вообще возможно). А с учетом стоимости и получаемого набора функций в платных версий, на мой взгляд, получается очень гуманная цена.
В ходе эксплуатации системы мы уже несколько раз устанавливали обновления, т.е. продукт активно развивается. Причем, после каждого обновления мы находили какие-то интересные опции. Например, рабочие процессы, новый раздел для обучения (Academy) и т.д.
Отдельно хочу отметить стабильность работы системы – за весь период эксплуатации не было ни одного внепланового простоя системы. Это прям очень порадовало.
Порекомендовал бы я систему ZenTao в качестве системы управления проектами? Несомненно. Хотя бы попробуйте поработать с бесплатной версией программы. И тогда вы точно сможете понять – подходит ли эта система именно вашей методологии работы с проектами или нет.
Посмотреть на ZenTao можно либо в публичном Demo, либо развернуть у себя. Есть готовые установщики под Windows и Linux, а также Docker версия. Хотел воспользоваться последней, но там всё описание на китайском. Не стал разбираться. Запустил версию под Linux:
# wget https://www.zentao.pm/dl/zentao/20.6/ZenTaoALM-20.6-zbox_amd64.tar.gz# tar -zxvf ZenTaoALM-20.6-zbox_amd64.tar.gz -C /opt# /opt/zbox/zbox startВ общем-то и всё. Приложение написано на php + mysql. Рабочий стек: Apache, PHP, MariaDB. Разработчики как-то упаковали весь стек в архив и запускают его через bash скрипт. Можно идти в веб интерфейс по IP адресу сервера и смотреть.
Различия между open source и платными редакциями можно посмотреть на отдельной странице. Приятно, что в бесплатной версии оставлена интеграция с git, gitlab, jenkins, возможность настроить ci/cd и другие штуки. Весь раздел DevOps представлен. Так же оставлена возможность вести базовую документацию. LDAP, как обычно, только в платных редакциях.
Бесплатная редакция на русском языке отсутствует, есть английский. А вот платные переведены на русский язык.
⇨ 🌐 Сайт /
Бесплатные аналоги ZenTao можете посмотреть по соответствующему тэгу снизу.
#itsm #управление_проектами
Please open Telegram to view this post
VIEW IN TELEGRAM
Запустил вчера старый ноут с Windows 10, который несколько месяцев пролежал выключенным. Он как с цепи сорвался. Минут 30 жужжал вентилятором на максимальных оборотах и что-то проверял, вычислял, качал, отправлял (?).
Просто жесть. Устройством пользоваться невозможно. Когда каждый день пользуешься ноутом, не замечаешь как-то, что система всё сливает в сеть.
А вот если она постоит, то у меня создаётся впечатление, что она тут же, пока её не успели выключить, стремится как можно больше собрать информации, тут же её всю отправить и загрузить к себе новые инструкции. Не может подождать даже минут 10-15, чтобы можно было хотя бы начать пользоваться системой.
Я уже привык, что старые устройства надо включить и оставить полежать, чтобы они отправили и получили всё, что им надо, а потом можно работать. С Android устройствами такая же история. Мне в данном случае не понятно одно - зачем делать это так агрессивно и прямо сразу после запуска. Можно же выдать пользователю плашку на тему того, мол хотите обновиться прямо сейчас или подождём минут 30? Тут прям сразу без вопросов всё накатили и предложили перезагрузку, которая ещё минут 10 длилась. Эта проблема, кстати, актуальна для различных устройств в переговорных комнатах, которые редко включают, а потом при запуске приходится ждать обновлений.
Или ещё пример из жизни. Ко мне как-то монтажники в один офис приезжали настроить направленную антенну. Они это не часто делают. Для настройки используют какой-то небольшой ноут, который удобно с собой возить и на коленке настраивать. Он маломощный. Приехали они ко мне, запустили его и он начал обновления качать и ставить. Прождали наверное около часа, пока он всё закончит. А у них рабочий день.
Не знаю, зачем я всё это написал. И так понятно, что все виндузятники и яблочники под плотным колпаком. Не хотел специально об этом писать, но прям зацепила эта тема.
Я убеждён, что вся информация (или выжимка) об использовании устройств и данных на них практически в режиме реального времени куда-то утекает, индексируется, каталогизируется и хранится. Для чего конкретно - хз, можно только догадываться. Не успел заскринить, а там ещё служба криптографии долго что-то вычисляла, писала на диск и отправляла по сети. Минут через 5 после запуска к процессу автообновления подключились и браузеры: яндекс и брейв. Эти поскромнее оказались, дали немного времени после загрузки системы. Буквально минут 5. Потом тоже обновились в фоне.
Можно, конечно, уповать на то, что есть Linux и надо использовать его. Но глобально это ни на что не повлияет. Как только доля Linux устройств у людей перевалит за какую-то значимую величину, там тоже начнут собирать данные. Если уже не собирают. Технически всё готово для этого - systemd. На него уже различные компании, связанные с безопасностью жалуются, что он очень переусложнён, что делает затруднительным анализ исходного кода. Сдаётся мне, что переусложнили его и внедрили во все дистрибутивы на базе Linux неспроста.
Такой вот вечер паранойи и шапочки из фольги получился. Что думаете об этом? Я перегибаю палку в теории заговора или согласны плюс-минус со мной?
#разное
Просто жесть. Устройством пользоваться невозможно. Когда каждый день пользуешься ноутом, не замечаешь как-то, что система всё сливает в сеть.
А вот если она постоит, то у меня создаётся впечатление, что она тут же, пока её не успели выключить, стремится как можно больше собрать информации, тут же её всю отправить и загрузить к себе новые инструкции. Не может подождать даже минут 10-15, чтобы можно было хотя бы начать пользоваться системой.
Я уже привык, что старые устройства надо включить и оставить полежать, чтобы они отправили и получили всё, что им надо, а потом можно работать. С Android устройствами такая же история. Мне в данном случае не понятно одно - зачем делать это так агрессивно и прямо сразу после запуска. Можно же выдать пользователю плашку на тему того, мол хотите обновиться прямо сейчас или подождём минут 30? Тут прям сразу без вопросов всё накатили и предложили перезагрузку, которая ещё минут 10 длилась. Эта проблема, кстати, актуальна для различных устройств в переговорных комнатах, которые редко включают, а потом при запуске приходится ждать обновлений.
Или ещё пример из жизни. Ко мне как-то монтажники в один офис приезжали настроить направленную антенну. Они это не часто делают. Для настройки используют какой-то небольшой ноут, который удобно с собой возить и на коленке настраивать. Он маломощный. Приехали они ко мне, запустили его и он начал обновления качать и ставить. Прождали наверное около часа, пока он всё закончит. А у них рабочий день.
Не знаю, зачем я всё это написал. И так понятно, что все виндузятники и яблочники под плотным колпаком. Не хотел специально об этом писать, но прям зацепила эта тема.
Я убеждён, что вся информация (или выжимка) об использовании устройств и данных на них практически в режиме реального времени куда-то утекает, индексируется, каталогизируется и хранится. Для чего конкретно - хз, можно только догадываться. Не успел заскринить, а там ещё служба криптографии долго что-то вычисляла, писала на диск и отправляла по сети. Минут через 5 после запуска к процессу автообновления подключились и браузеры: яндекс и брейв. Эти поскромнее оказались, дали немного времени после загрузки системы. Буквально минут 5. Потом тоже обновились в фоне.
Можно, конечно, уповать на то, что есть Linux и надо использовать его. Но глобально это ни на что не повлияет. Как только доля Linux устройств у людей перевалит за какую-то значимую величину, там тоже начнут собирать данные. Если уже не собирают. Технически всё готово для этого - systemd. На него уже различные компании, связанные с безопасностью жалуются, что он очень переусложнён, что делает затруднительным анализ исходного кода. Сдаётся мне, что переусложнили его и внедрили во все дистрибутивы на базе Linux неспроста.
Такой вот вечер паранойи и шапочки из фольги получился. Что думаете об этом? Я перегибаю палку в теории заговора или согласны плюс-минус со мной?
#разное
На днях на одном из серверов VPN с IP 175.115.158.81 заметил странные строки в логе:
Внимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:
Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.
Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:
Соединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:
Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:
1778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:
А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.
Получилась мини-инструкция по диагностике исходящих соединений. В принципе, можно было сразу запустить tcpdump, но я по памяти не помню ключи и синтаксис выборки для него. Приходится куда-то лезть за подсказками. Мне казалось, что я делал по tcpdump заметку с популярными командами, но нет, не нашёл. Надо будет при случае исправить это.
#linux #terminal
ovpn-server[3742533]: TCP connection established with [AF_INET] 95.145.141.246:58560ovpn-server[3742533]: 95.145.141.246:58560 Connection reset, restarting [0]ovpn-server[3742533]: 95.145.141.246:58560 SIGUSR1[soft,connection-reset] received, client-instance restartingВнимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:
# ps axf Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.
Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:
# ss -ntuСоединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:
# tcpdump -nn 'dst host 175.115.158.81'Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:
14:29:38.706375 IP 172.17.0.4.58700 > 175.115.158.81.17781778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:
# docker ps -q | xargs -n 1 docker inspect --format '{{ .NetworkSettings.IPAddress }} {{ .Name }}' | sed 's/ \// /'...........172.17.0.4 gatus...........А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.
Получилась мини-инструкция по диагностике исходящих соединений. В принципе, можно было сразу запустить tcpdump, но я по памяти не помню ключи и синтаксис выборки для него. Приходится куда-то лезть за подсказками. Мне казалось, что я делал по tcpdump заметку с популярными командами, но нет, не нашёл. Надо будет при случае исправить это.
#linux #terminal
Очень простой и быстрый способ измерить ширину канала с помощью Linux без установки дополнительных пакетов. Понадобится только netcat, который чаще всего есть в составе базовых утилит. По крайней мере в Debian это так.
Берём условный сервер 10.20.1.50 и запускаем там netcat на порту 5201:
Идём на другую машину и запускаем netcat в режиме клиента, передавая туда 10 блоков размером 10 мегабайт:
Когда измерял так скорость, немного усомнился в достоверности результатов. Решил провести одинаковые тесты с помощью netcat и iperf3. На скоростях до 1 Gbits/sec замеры показывают одинаковые числа, плюс-минус в районе погрешности измерений. Можно смело использовать netcat. Это реально работает для быстрой проверки канала до какой-то VPS.
А вот в сетях в рамках гипервизора, где скорости значительно больше, идут большие расхождения. Iperf3 показывает раза в 4 больше скорость (~15.0 Gbits/sec), чем netcat (~4.0 Gbits/sec). Гипервизор объявляет скорость своего бриджа в 10 Gbits/sec. И тут уже трудно судить, кто ближе к истине. Корректно выполнить замеры на реальных данных затруднительно, так как много факторов, которые влияют на итоговый результат.
Напомню, что у меня есть хорошая заметка про netcat с различными практическими примерами применения этой утилиты.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network
Берём условный сервер 10.20.1.50 и запускаем там netcat на порту 5201:
# nc -lvp 5201 > /dev/nullИдём на другую машину и запускаем netcat в режиме клиента, передавая туда 10 блоков размером 10 мегабайт:
# dd if=/dev/zero bs=10M count=10 | nc 10.20.1.50 5201Когда измерял так скорость, немного усомнился в достоверности результатов. Решил провести одинаковые тесты с помощью netcat и iperf3. На скоростях до 1 Gbits/sec замеры показывают одинаковые числа, плюс-минус в районе погрешности измерений. Можно смело использовать netcat. Это реально работает для быстрой проверки канала до какой-то VPS.
А вот в сетях в рамках гипервизора, где скорости значительно больше, идут большие расхождения. Iperf3 показывает раза в 4 больше скорость (~15.0 Gbits/sec), чем netcat (~4.0 Gbits/sec). Гипервизор объявляет скорость своего бриджа в 10 Gbits/sec. И тут уже трудно судить, кто ближе к истине. Корректно выполнить замеры на реальных данных затруднительно, так как много факторов, которые влияют на итоговый результат.
Напомню, что у меня есть хорошая заметка про netcat с различными практическими примерами применения этой утилиты.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network
Я уже давно использую заметки с канала как свои шпаргалки. Всё полезное из личных заметок перенёс сюда, плюс оформил всё это аккуратно и дополнил. Когда ищу какую-то информацию, в первую очередь иду сюда, ищу по тегам или содержимому.
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
Если запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
Или только конкретный:
📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
Комбинация порта и адресата:
Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
Протокол IP, адрес источника и порт > адрес получателя и его порт.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network #tcpdump
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
-nn, чтобы не резолвить IP адреса в домены и не заменять номера портов именем протокола. Мне это мешает. 📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
# tcpdump -DЕсли запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
# tcpdump -nn -i anyИли только конкретный:
# tcpdump -nn -i ens3📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
# tcpdump -nn -i any port not 22По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
# tcpdump -nn dst 8.8.8.8# tcpdump -nn dst 8.8.8.8 or dst 8.8.4.4Комбинация порта и адресата:
# tcpdump -nn dst 8.8.8.8 and port 53Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
# tcpdump arp -nn -i any# tcpdump not arp -nn -i any# tcpdump not arp and not icmp -nn -i anyНа этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
# tcpdump -nn -i any > ~/tcpdump.txtНа основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
# tcpdump -nn -i tun4 src 10.1.4.23 and dst 10.1.3.205 and port 5060Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
IP 10.8.2.2.13083 > 10.8.2.3.8118Протокол IP, адрес источника и порт > адрес получателя и его порт.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network #tcpdump
Если у вас нет глубоких знаний о работе современных процессоров, а вы хотите получить хотя бы примерное представление, как на них работают программы, то у меня для вас необычная рекомендация. Есть целый сайт по этой теме:
⇨ https://cpu.land
Особенность его в том, что текст для него написан 17-ти летней девочкой-подростком, которая стала разработчиком. Материал воспринимается очень легко, написан простым языком. Я прочитал его в автоматическом переводе Яндекс.Браузера. Просто открыл все главы на одной странице, перевёл и прочитал. Иногда переключался на оригинал, чтобы уточнить какой-то переведённый термин.
Чтиво буквально на 15-20 минут, но после прочтения у вас будет представление, как совершается компьютерная магия, которая превращает нолики и единички в работающие программы на ОС с ядром Linux.
В материале раскрываются следующие темы:
▪️Как в принципе устроен процессор, как он работает с оперативной памятью
▪️Ядро операционной системы и системные вызовы
▪️Процессорные архитектуры и инструкции
▪️Аппаратные прерывания, многозадачность
▪️Разбор последовательных действий, которые происходят после вашего запуска программы в ОС
▪️Отдельно автор прошлась по скриптам, оболочкам и шебангам
▪️Разбор ELF файлов, что это такое и для чего нужны
▪️Динамические библиотеки .so
▪️Основные и дочерние процессы
Отдельно мне понравилась ремарка автора насчёт использования ChatGPT:
Я довольно много общался с GPT-3.5 и GPT-4 во время написания этой статьи. Хотя они много лгали мне и большая часть информации была бесполезной, иногда они были очень полезны для решения проблем. Помощь LLM может быть исключительно положительной, если вы знаете об их ограничениях и крайне скептически относитесь ко всему, что они говорят.
Мне понравился лёгкий и весёлый слог автора, несмотря на то, что читал перевод. Прям увидел и ощутил новый взгляд на обучающий материал, каким он может быть. Наверное, так написать мог только подросток. Рекомендую, если вы интересуетесь самообразованием.
❗️ Надеюсь, я заинтересовал вас и убедил не просто сохранить ссылку, но и прочитать её. В этом плане мы можем быть полезны друг другу. Если бы мне не нужно было писать эту заметку, то скорее всего я бы не стал читать материал, а просто добавил бы его куда-нибудь на будущее и никогда бы не вернулся. Собственно, я изначально так и сделал. Эта ссылка лежала у меня год 😁
#обучение
⇨ https://cpu.land
Особенность его в том, что текст для него написан 17-ти летней девочкой-подростком, которая стала разработчиком. Материал воспринимается очень легко, написан простым языком. Я прочитал его в автоматическом переводе Яндекс.Браузера. Просто открыл все главы на одной странице, перевёл и прочитал. Иногда переключался на оригинал, чтобы уточнить какой-то переведённый термин.
Чтиво буквально на 15-20 минут, но после прочтения у вас будет представление, как совершается компьютерная магия, которая превращает нолики и единички в работающие программы на ОС с ядром Linux.
В материале раскрываются следующие темы:
▪️Как в принципе устроен процессор, как он работает с оперативной памятью
▪️Ядро операционной системы и системные вызовы
▪️Процессорные архитектуры и инструкции
▪️Аппаратные прерывания, многозадачность
▪️Разбор последовательных действий, которые происходят после вашего запуска программы в ОС
▪️Отдельно автор прошлась по скриптам, оболочкам и шебангам
▪️Разбор ELF файлов, что это такое и для чего нужны
▪️Динамические библиотеки .so
▪️Основные и дочерние процессы
Отдельно мне понравилась ремарка автора насчёт использования ChatGPT:
Я довольно много общался с GPT-3.5 и GPT-4 во время написания этой статьи. Хотя они много лгали мне и большая часть информации была бесполезной, иногда они были очень полезны для решения проблем. Помощь LLM может быть исключительно положительной, если вы знаете об их ограничениях и крайне скептически относитесь ко всему, что они говорят.
Мне понравился лёгкий и весёлый слог автора, несмотря на то, что читал перевод. Прям увидел и ощутил новый взгляд на обучающий материал, каким он может быть. Наверное, так написать мог только подросток. Рекомендую, если вы интересуетесь самообразованием.
#обучение
Please open Telegram to view this post
VIEW IN TELEGRAM
Putting the "You" in CPU
Curious exactly what happens when you run a program on your computer? Learn how multiprocessing works, what system calls really are, how computers manage memory with hardware interrupts, and how Linux loads executables.
Немного информации для тех, кто имеет дело с обычными веб серверами под php сайты. Вчера провозился несколько часов с одним сайтом, который передали разработчики для публикации. Причём провозился из-за ерунды. Это был немного навороченный мультиязычный сайт на базе Wordpress, но с полностью самописной темой.
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
В коде этого сайта были конструкции типа
Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
<?xml.В коде этого сайта были конструкции типа
<? вместо <?php, а для их корректной работы как раз и нужен параметр short_open_tag. Есть проекты, где явно пишут, что надо включить этот параметр. А тут мне никто ни слова насчёт него не сказал. Включил параметр и всё заработало. Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
<?xml version="1.0"?>Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
⇨ ProxMox Cluster 2 Nodes + Q-Device. Кластер просто. Для дома и офиса.
Пример настройки бюджетного HA кластера из двух нод и "арбитра" на Raspberry Pi для кворума. Хранилища локальные на базе zfs. Второй сервер будет содержать клоны VM c первого и заменит его в случае выхода из строя.
⇨ Best Docker Container Server Setup // Docker Swarm, CephFS, and Portainer
Очень любопытное видео на тему перечисленных выше технологий. Автор рассмотрел простую отказоустойчивую замену кластера Kubernetes. Видео небольшое, но ёмкое по объему информации и практике. Не знаю, имеет ли смысл подобная сборка, но посмотреть и послушать интересно.
⇨ Linux - Как легко создать свой DEB package на Линукс
Пошаговая инструкция на заданную тему от Дениса Астахова и его полезного канала ADV-IT. Смотреть видео большого смысла нет, если у вас нет задачи по сборке пакетов. А вот сохранить ссылку имеет смысл, чтобы быстро найти, когда задача такая возникнет. Можно и мою инструкцию на эту тему сохранить.
⇨ ПРОБРОС СЕТЕВОЙ КАРТЫ ИЛИ LINUX BRIDGE? ИЛИ ВИРТУАЛЬНЫЙ РОУТЕР С 2 ЛАН ПОРТАМИ
Полезное видео на тему организации сети в Proxmox. Я лично всегда и везде использую бриджи. Это удобно, плюс виртуалки получают лучшую переносимость.
⇨ Dockge - выкинь Portainer немедленно
Кликбейтный заголовок, а по сути автор рассказывает про минусы Portainer и показывает, что можно использовать в качестве замены. Я лично не проникся этой заменой.
⇨ Docker always up to date! (and more) Renovate Tutorial
Рекламное видео на тему программы Renovate, которая умеет автоматически проверять и обновлять в исходниках версии используемых образов докера, пакетов, указанных в ваших репозиториях. У Renovate есть бесплатная self-hosted Community версия, так что видео может быть полезным. В нём настраивают и тестируют именно эту версию.
⇨ OpenRPort - Remote Management Tool with Secure Tunneling!
Бесплатная программа для удалённого управления компьютерами. Сделана на базе RealVNC. Есть веб интерфейс с 2FA аутентификацией. Впервые услышал об этой программе. Было интересно посмотреть. Надо будет попробовать в деле. Наличие VNC под капотом немного расстраивает, так как скорее всего картинка будет лагучей, как это обычно бывает с VNC через интернет на слабых каналах.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
ProxMox Cluster 2 Nodes + Q-Device. Кластер просто. Для дома и офиса.
ProxMox Cluster 2 Nodes + Q-Device. Создание кластера.
Proxmox cluster 3 Nodes: https://www.youtube.com/watch?v=Owyrz9D_pZQ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Буду очень благодарен за поддержку в виде чашечки ☕️:
https://www.buymeacoffee.com/RomNero
~…
Proxmox cluster 3 Nodes: https://www.youtube.com/watch?v=Owyrz9D_pZQ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Буду очень благодарен за поддержку в виде чашечки ☕️:
https://www.buymeacoffee.com/RomNero
~…
Периодически в комментариях возникают вопросы на тему личного хранилища информации. Кто, как и где хранит. Я сколько веду свою трудовую деятельность, столько и делаю записи по различным темам. Начинал всё с простого сохранения html страниц. Они, кстати, до сих пор у меня хранятся. Упаковал в архив, так и лежат с тех пор. В конце будет ссылка на один подобный архив по теме. Может кому интересно будет поностальгировать по прошлым временам. Там будет цикл статей по настройке почтового сервера на Freebsd, по которому я учился.
Сейчас вся моя база знаний переехала в этот канал. Как раньше сайт, так и сейчас канал я лично использую почти каждый день в своих делах. В том числе и поэтому я аккуратно и ответственно всё составляю, оформляю, готовлю к публикации, делаю подборки. Всегда держу в голове момент, как я буду потом искать эту информацию. Ищу либо по тэгами, либо по названиям конкретных программ. В целом могу сказать, что такой поиск меня устраивает. Обычно нахожу то, что нужно.
В дополнение к этому, я в Joplin веду все свои проекты, не только по работе, но и личные, типа стройки, ремонта, сайта и т.д. Когда делаю что-то значимое, что хочу сохранить для использования в будущем, делаю заметку по этой теме в свободной форме. Покажу на конкретных примерах.
Есть компания, где используются сайты на Битриксе. У меня там в том числе есть такие записи:
◽️Bitrix. Тут хранится общая информация обо всём, с чем сталкиваюсь. Например, была ошибка, я записал текст ошибки и тут же решение текстом или ссылку на материал, который использовал. Не занимаюсь никаким особым оформлением. Просто записываю, чтобы потом найти.
◽️Переезд веб сервера. Тут пишу всё, что касается переезда. Уже не раз меняли провайдера, сервера, услуги. Каждый раз кажется, что это в последний раз так переезжаем масштабно, но на деле, каждые 2-3 года что-то случается. Заметка очень помогает быстро составить план переноса.
◽️Заражение. Тут описана история заражения одного сайта. Что пролезло, какие признаки были, как лечил.
◽️Ошибки обновления. Сайты периодически обновляют, пишу, с чем сталкиваемся, чтобы потом быстрее обсудить с разработчиками очередное обновление.
❗️Важный момент. Я не трачу много времени на эти записки. Просто копирую информацию и всё. Если оформлять, дополнять, то на это тратится время, будешь лениться или откладывать. В итоге забудешь. А так всё записано. Потом это пригождается и в других проектах, так как с Bitrix приходится много где работать. Даже такие отрывочные данные сильно упрощают решение задачи, когда с ней повторно сталкиваешься.
По личным делам всё то же самое. Вот несколько примеров записей по даче:
◽️Техника. Записываю модели всей купленной техники и всё, что с ней связано.
◽️Обслуживание инженерки. Пишу, что, где, когда и как надо делать: проверить расширительный бак, заменить фильтр, закрыть уличный кран на зиму и т.д.
◽️Строительные компании. С какими компаниями работал, кто что делал.
◽️Серверная. Оборудование в серверном шкафу.
◽️Спросить у специалиста. Список вопросов, на которые мне нужен совет специалиста.
◽️Перед отъездом. Список того, что надо проверить перед отъездом: закрыть окна, отключить насос, выключить тёплый пол, забрать мусор и т.д. Не нужно каждый раз ломать голову и вспоминать, ничего ли я не забыл. Этот список, кстати, распечатан и висит перед выходной дверью.
Примерно так. Не знаю, насколько это будет полезно вам. Такие вещи очень индивидуальны. У меня простое правило - всё должно быть записано. Если не записал, через пол года уже ничего не помнишь. Вспоминать очень накладно и долго. Найти в своих заметках - дело пары минут. Главное не упарываться в оформление. Пусть будет свалка. С помощью поиска и в свалке быстро найдешь, если данные записаны.
Как вы можете увидеть, снизу есть тэг. По нему вы найдёте все мои записи по этой теме. Например, как планирую свои дела и какой планировщик использую.
Обещанный архив: postfix.7z
#заметки
Сейчас вся моя база знаний переехала в этот канал. Как раньше сайт, так и сейчас канал я лично использую почти каждый день в своих делах. В том числе и поэтому я аккуратно и ответственно всё составляю, оформляю, готовлю к публикации, делаю подборки. Всегда держу в голове момент, как я буду потом искать эту информацию. Ищу либо по тэгами, либо по названиям конкретных программ. В целом могу сказать, что такой поиск меня устраивает. Обычно нахожу то, что нужно.
В дополнение к этому, я в Joplin веду все свои проекты, не только по работе, но и личные, типа стройки, ремонта, сайта и т.д. Когда делаю что-то значимое, что хочу сохранить для использования в будущем, делаю заметку по этой теме в свободной форме. Покажу на конкретных примерах.
Есть компания, где используются сайты на Битриксе. У меня там в том числе есть такие записи:
◽️Bitrix. Тут хранится общая информация обо всём, с чем сталкиваюсь. Например, была ошибка, я записал текст ошибки и тут же решение текстом или ссылку на материал, который использовал. Не занимаюсь никаким особым оформлением. Просто записываю, чтобы потом найти.
◽️Переезд веб сервера. Тут пишу всё, что касается переезда. Уже не раз меняли провайдера, сервера, услуги. Каждый раз кажется, что это в последний раз так переезжаем масштабно, но на деле, каждые 2-3 года что-то случается. Заметка очень помогает быстро составить план переноса.
◽️Заражение. Тут описана история заражения одного сайта. Что пролезло, какие признаки были, как лечил.
◽️Ошибки обновления. Сайты периодически обновляют, пишу, с чем сталкиваемся, чтобы потом быстрее обсудить с разработчиками очередное обновление.
❗️Важный момент. Я не трачу много времени на эти записки. Просто копирую информацию и всё. Если оформлять, дополнять, то на это тратится время, будешь лениться или откладывать. В итоге забудешь. А так всё записано. Потом это пригождается и в других проектах, так как с Bitrix приходится много где работать. Даже такие отрывочные данные сильно упрощают решение задачи, когда с ней повторно сталкиваешься.
По личным делам всё то же самое. Вот несколько примеров записей по даче:
◽️Техника. Записываю модели всей купленной техники и всё, что с ней связано.
◽️Обслуживание инженерки. Пишу, что, где, когда и как надо делать: проверить расширительный бак, заменить фильтр, закрыть уличный кран на зиму и т.д.
◽️Строительные компании. С какими компаниями работал, кто что делал.
◽️Серверная. Оборудование в серверном шкафу.
◽️Спросить у специалиста. Список вопросов, на которые мне нужен совет специалиста.
◽️Перед отъездом. Список того, что надо проверить перед отъездом: закрыть окна, отключить насос, выключить тёплый пол, забрать мусор и т.д. Не нужно каждый раз ломать голову и вспоминать, ничего ли я не забыл. Этот список, кстати, распечатан и висит перед выходной дверью.
Примерно так. Не знаю, насколько это будет полезно вам. Такие вещи очень индивидуальны. У меня простое правило - всё должно быть записано. Если не записал, через пол года уже ничего не помнишь. Вспоминать очень накладно и долго. Найти в своих заметках - дело пары минут. Главное не упарываться в оформление. Пусть будет свалка. С помощью поиска и в свалке быстро найдешь, если данные записаны.
Как вы можете увидеть, снизу есть тэг. По нему вы найдёте все мои записи по этой теме. Например, как планирую свои дела и какой планировщик использую.
Обещанный архив: postfix.7z
#заметки
Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:
С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
Используем его:
Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
Объединил для удобства оба протокола. Ключевой момент тут в настройке
Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
server { listen 80 default_server; server_name _; return 404;}С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
server { listen 443 ssl default_server; server_name _; return 404;}То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crtИспользуем его:
server { listen 443 ssl default_server; server_name _; ssl_certificate /etc/nginx/certs/nginx.crt; ssl_certificate_key /etc/nginx/certs/nginx.key; return 404;}Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
server { listen 80 default_server; listen 443 ssl default_server; server_name _; ssl_reject_handshake on; return 404;}Объединил для удобства оба протокола. Ключевой момент тут в настройке
ssl_reject_handshake on. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name. Тут у нас в этой директиве _, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия. Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
Интересные дела происходят с замедлением youtube. Пару недель назад заметил, что на домашнем интернете замедление прекратилось. У меня в Москве провайдер Ростелеком. Ещё в августе началось жёсткое замедление, так что смотреть ютуб было нереально.
Я принял ряд организационных мер и направил трафик ко всему гуглу по IP адресам на VPN. Это нормально работает. Дома особо никто не пользуется услугами гугла, так что каких-то неудобств, связанных с тем, что весь трафик идёт в VPN, не было. Стало даже удобно, так как детям можно было отключить ютуб, пока они не сделают уроки.
В какой-то момент заметил, что замедление перестало работать. VPN отключен, а ютуб нормально работает. Стал разбираться, почему так. Для начала решил промаркировать весь трафик, который можно было по доменам или IP адресам идентифицировать как ютубовский. Смотрю видео в максимальном разрешении, а трафика по этим маркировкам нет. Что-то есть, но очень мало.
Посмотрел внимательнее, откуда грузится видео. Оказалось, что с IP адреса 77.37.252.140. Проверяю этот адрес:
Неплохо, кэш гугла работает. А чей же это айпишник:
Ростелекомовский. Поспрашивал знакомых, у кого-то работает замедление, у кого-то нет.
Такая вот странная история выходит с этим замедлением. У меня оно работать перестало. Основной трафик идёт через кэширующий сервер гугла, который стоит в Ростелекоме. По идее последний без проблем может его отключить и снова замедлять.
Теперь думаю, как мне снова замедлить ютуб, чтобы дети не смотрели, пока уроки не сделают. С появлением кэширующих серверов, адреса которых неизвестны, задача усложнилась. cache.google.com - это PTR запись для IP адресов. Сам домен не пингуется, DNS записей для него нет. У Ростелекома много подобных серверов, IP периодически меняются.
У кого-то есть идеи, как теперь обратно всё замедлить при таких вводных? Я не совсем понимаю, в какой момент происходит перенаправление запросов на локальный кэширующий сервер провайдера и какие конкретно запросы перенаправляются, чтобы их как-то отследить. Весь гугл банить или замедлять не вариант. Во время воспроизведения даже одного и того же видео поток иногда идёт напрямую из USA с гугловских IP, а иногда из кэширующего сервера.
У вас вообще как с замедлением? Работает или нет? У меня по факту ни на мобильном интернете, ни на проводном замедления нет. Спокойно всё смотрю в высоком качестве.
#замедление
Я принял ряд организационных мер и направил трафик ко всему гуглу по IP адресам на VPN. Это нормально работает. Дома особо никто не пользуется услугами гугла, так что каких-то неудобств, связанных с тем, что весь трафик идёт в VPN, не было. Стало даже удобно, так как детям можно было отключить ютуб, пока они не сделают уроки.
В какой-то момент заметил, что замедление перестало работать. VPN отключен, а ютуб нормально работает. Стал разбираться, почему так. Для начала решил промаркировать весь трафик, который можно было по доменам или IP адресам идентифицировать как ютубовский. Смотрю видео в максимальном разрешении, а трафика по этим маркировкам нет. Что-то есть, но очень мало.
Посмотрел внимательнее, откуда грузится видео. Оказалось, что с IP адреса 77.37.252.140. Проверяю этот адрес:
# host 77.37.252.140140.252.37.77.in-addr.arpa domain name pointer cache.google.com.Неплохо, кэш гугла работает. А чей же это айпишник:
# ipa 77.37.252.140{ "ip": "77.37.252.140", "ip_decimal": 1294335116, "country": "Russia", "country_iso": "RU", "country_eu": false, "region_name": "Moscow Oblast", "region_code": "MOS", "zip_code": "140185", "city": "Zhukovsky", "latitude": 55.597, "longitude": 38.1151, "time_zone": "Europe/Moscow", "asn": "AS42610", "asn_org": "Rostelecom", "hostname": "cache.google.com"}Ростелекомовский. Поспрашивал знакомых, у кого-то работает замедление, у кого-то нет.
Такая вот странная история выходит с этим замедлением. У меня оно работать перестало. Основной трафик идёт через кэширующий сервер гугла, который стоит в Ростелекоме. По идее последний без проблем может его отключить и снова замедлять.
Теперь думаю, как мне снова замедлить ютуб, чтобы дети не смотрели, пока уроки не сделают. С появлением кэширующих серверов, адреса которых неизвестны, задача усложнилась. cache.google.com - это PTR запись для IP адресов. Сам домен не пингуется, DNS записей для него нет. У Ростелекома много подобных серверов, IP периодически меняются.
У кого-то есть идеи, как теперь обратно всё замедлить при таких вводных? Я не совсем понимаю, в какой момент происходит перенаправление запросов на локальный кэширующий сервер провайдера и какие конкретно запросы перенаправляются, чтобы их как-то отследить. Весь гугл банить или замедлять не вариант. Во время воспроизведения даже одного и того же видео поток иногда идёт напрямую из USA с гугловских IP, а иногда из кэширующего сервера.
У вас вообще как с замедлением? Работает или нет? У меня по факту ни на мобильном интернете, ни на проводном замедления нет. Спокойно всё смотрю в высоком качестве.
#замедление
В начале октября была новость от Microsoft, что в новых версиях своего сервера они откажутся от поддержки протоколов PPTP и L2TP для организации VPN соединений. Про первый очень давно известно, что он небезопасен и в целом его уже не используют. А вот насчёт второго я немного удивился. Связка L2TP + Ipsec вполне надёжна и безопасна. Я на Микротиках по умолчанию именно её всегда использовал, так как легко и быстро настраивается.
В новости нет пояснений на тему того, почему от L2TP + Ipsec принято решение постепенно отказываться. Поясню, что прекращение поддержки в данном случае не означает, что эти протоколы не будут работать и их будет невозможно настроить в Windows. Пока всё останется как есть, просто никакие новые возможности и нововведения, связанные с этими технологиями, не будут добавляться. Ну а со временем, скорее всего, и использование будет прекращено. Думаю, что это случится нескоро, так что сильно напрягаться по этому поводу не стоит.
Взамен Microsoft предлагает использовать SSTP и IKEv2. Про последний есть отдельное пояснение, что этот протокол особенно удобен и эффективен для мобильных пользователей. После прочтения решил проверить, а что вообще предлагает мой Android 14 из встроенных средств для настройки VPN. Оказалось, что только IKEv2. Так что в этом плане как минимум у Microsoft нет расхождений с Google насчёт VPN для смартфонов.
Если есть возможность выбирать, то я в первую очередь в качестве сервера использую OpenVPN, иногда в простых случаях Wireguard, в Микротиках - L2TP. Решил посмотреть, а что вообще есть в качестве сервера на Linux для организации VPN на базе IKEv2. Кстати, поделитесь в комментариях, что вы используете для этих целей, если пользуетесь.
Стоит сказать, что IKEv2 в связке с IPsec поддерживают все современные системы. Для настройки клиентского соединения не нужно устанавливать никакой дополнительный софт. Аутентификация возможна с использованием только имени пользователя и пароля. Это огромный плюс для больших сетей, где настройка и поддержка клиентов может занимать значительные ресурсы.
Я немного погуглил. Для настройки IKEv2 в связке с IPsec, можно использовать реализацию на базе strongswan. Всё необходимое есть в пакетах дистрибутивов:
Настраивается относительно просто. Примерно так же, как и OpenVPN. Для идентификации клиентов IKEv2 нужны сертификаты. Этот вопрос решает пакет strongswan-pki. Запускаете свой CA, выпускаете сертификат для сервера. Клиентов можете аутентифицировать как по сертификатам, так и просто по логину с паролем. Хранить их можно в обычном текстовом файле на сервере. Дополнительной защитой будет служить то, что клиенты должны будут доверять сертификату VPN сервера. Для этого ваш CA нужно будет добавить в доверенные сертификаты, либо изначально использовать доверенный сертификат для сервера (можно использовать от let's encrypt).
Основное неудобство подобного сервера по сравнению с тем же OpenVPN - нет возможности со стороны сервера управлять маршрутами клиентов. То есть либо всё отправляем в VPN туннель, либо как-то по-другому настраиваем на клиенте маршруты. Ну а плюс я уже назвал - нативная поддержка со стороны всех современных ОС. Не нужно ставить дополнительный софт.
Для простых site-to-site соединений, то есть для объединения офисов или других распределённых сетей можно использовать только пакет strongswan, который позволяет организовать обычный ipsec канал без использования сертификатов. Просто два конфига ipsec на обоих серверах и секрет для шифрования.
#vpn #IKEv2 #ipsec
В новости нет пояснений на тему того, почему от L2TP + Ipsec принято решение постепенно отказываться. Поясню, что прекращение поддержки в данном случае не означает, что эти протоколы не будут работать и их будет невозможно настроить в Windows. Пока всё останется как есть, просто никакие новые возможности и нововведения, связанные с этими технологиями, не будут добавляться. Ну а со временем, скорее всего, и использование будет прекращено. Думаю, что это случится нескоро, так что сильно напрягаться по этому поводу не стоит.
Взамен Microsoft предлагает использовать SSTP и IKEv2. Про последний есть отдельное пояснение, что этот протокол особенно удобен и эффективен для мобильных пользователей. После прочтения решил проверить, а что вообще предлагает мой Android 14 из встроенных средств для настройки VPN. Оказалось, что только IKEv2. Так что в этом плане как минимум у Microsoft нет расхождений с Google насчёт VPN для смартфонов.
Если есть возможность выбирать, то я в первую очередь в качестве сервера использую OpenVPN, иногда в простых случаях Wireguard, в Микротиках - L2TP. Решил посмотреть, а что вообще есть в качестве сервера на Linux для организации VPN на базе IKEv2. Кстати, поделитесь в комментариях, что вы используете для этих целей, если пользуетесь.
Стоит сказать, что IKEv2 в связке с IPsec поддерживают все современные системы. Для настройки клиентского соединения не нужно устанавливать никакой дополнительный софт. Аутентификация возможна с использованием только имени пользователя и пароля. Это огромный плюс для больших сетей, где настройка и поддержка клиентов может занимать значительные ресурсы.
Я немного погуглил. Для настройки IKEv2 в связке с IPsec, можно использовать реализацию на базе strongswan. Всё необходимое есть в пакетах дистрибутивов:
# apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-pluginsНастраивается относительно просто. Примерно так же, как и OpenVPN. Для идентификации клиентов IKEv2 нужны сертификаты. Этот вопрос решает пакет strongswan-pki. Запускаете свой CA, выпускаете сертификат для сервера. Клиентов можете аутентифицировать как по сертификатам, так и просто по логину с паролем. Хранить их можно в обычном текстовом файле на сервере. Дополнительной защитой будет служить то, что клиенты должны будут доверять сертификату VPN сервера. Для этого ваш CA нужно будет добавить в доверенные сертификаты, либо изначально использовать доверенный сертификат для сервера (можно использовать от let's encrypt).
Основное неудобство подобного сервера по сравнению с тем же OpenVPN - нет возможности со стороны сервера управлять маршрутами клиентов. То есть либо всё отправляем в VPN туннель, либо как-то по-другому настраиваем на клиенте маршруты. Ну а плюс я уже назвал - нативная поддержка со стороны всех современных ОС. Не нужно ставить дополнительный софт.
Для простых site-to-site соединений, то есть для объединения офисов или других распределённых сетей можно использовать только пакет strongswan, который позволяет организовать обычный ipsec канал без использования сертификатов. Просто два конфига ipsec на обоих серверах и секрет для шифрования.
#vpn #IKEv2 #ipsec
TECHCOMMUNITY.MICROSOFT.COM
PPTP and L2TP deprecation: A new era of secure connectivity | Microsoft Community Hub
Start transitioning to SSTP and IKEv2 from PPTP and L2TP protocols on Windows Server
Существует популярная панель для управления сервером с прицелом на персональное использование в качестве некоего домашнего сервера. Речь пойдёт про CasaOS - популярный open source проект. Ставится поверх обычного дистрибутива Linux. Я установил на Debian и попробовал его для решения некоторых задач. В частности своего личного WireGuard сервера в связке с AdGuard Home для блокировки рекламы на компьютерах или смартфонах.
Не знаю, за что CasaOS снискала свою популярность. Скорее всего за лёгкий и красивый веб интерфейс. Похожие проекты существую давно. Например, Runtipi, про который я ранее уже писал. Там, кстати, в комментариях как раз CasaOS упоминали. По своей сути это просто веб интерфейс поверх работающих Docker контейнеров, которые устанавливаются из встроенного магазина преднастроенных приложений.
Можно было бы предположить, что это продукт для тех, кто не умеет и не хочет уметь работать с консолью Linux, ничего не знает, а хочет просто мышкой потыкать и получить настроенный сервер. Но на самом деле с CasaOS это так не работает. Без знаний особенностей работы Docker контейнеров настроить нормальную работу всех сервисов скорее всего не получится. В консоль ходить не обязательно, но некоторые настройки контейнеров после установки нужно будет делать.
Сразу приведу список приложений, которые можно установить в CasaOS. Вообще, их огромное количество. Есть всё, что только можно. Сообщество насоздавало своих магазинов, которые регулярно поддерживаются и обновляются. Вот самые популярные:
◽️big-bear-casaos
◽️CasaOS-LinuxServer-AppStore
◽️CasaOS-Coolstore
◽️CasaOS-HomeAutomation-AppStore
Получается внушительный набор. Для личного сервера есть всё необходимое: FileBrowser, Nginx Proxy Manager, WireGuard, AdGuard Home, Syncthing, Transmission, Nextcloud и многое другое.
Установить CasaOS очень просто. Берём чистый сервер и ставим:
На выходе получаем работающий веб интерфейс по IP адресу сервера. При первом входе нужно будет создать учётку. Дальше я настроил и потестировал прикладную связку из WireGuard + AdGuard. Сначала установил AdGuard Home. Первый вход из админки запускает стандартный установщик AdGuard, который в том числе настраивает доступ к веб интерфейсу. По умолчанию это будет 80-й порт, но он уже занят интерфейсом самого CasaOS. Поэтому после установки контейнера, надо зайти в настройки AdGuard Home и добавить проброс ещё одного порта к уже существующим: 8080 ⇨ 80. Теперь по IP адресу сервера и порту 8080 можно попасть в веб интерфейс AdGuard.
Потом установил WireGuard Easy. После установки зашёл в настройки приложения и отредактировал некоторые параметры. В переменной PASSWORD установил свой пароль. В переменной WG_HOST указал IP адрес сервера, в WG_DEFAULT_DNS указал IP адрес контейнера с AdGuard Home. Так как он устанавливался первым, IP адрес у него 172.17.0.2.
Ну и всё. Дальше зашёл в веб интерфейс WG-Easy, создал пользователя. Импортировал конфиг в смартфон и подключился. Смартфон автоматом весь трафик завернул в туннель, а в качестве DNS сервера стал использовать контейнер AdGuard Home. А в нём можно настроить различные блокировки как по спискам рекламы, так и целые сервисы. Например, можно заблокировать полностью Youtube или VK. Таким же образом WG можно подключить на компьютере (проверил, работает) или на роутере. Причём на роутере не обязательно весь трафик заворачивать в туннель. Можно использовать только DNS сервер от AdGuard Home для блокировки рекламы.
Эту связку можно использовать для различных задач. Не буду подробно на этом останавливаться, так как за это уже начали наказывать. Пока в виде предупреждений. Авторы сайтов и ютуб каналов уже получают уведомления от Роскомнадзора. Так что если вы автор контента, имейте ввиду.
В целом, панель приятная. Если понимаешь особенности работы контейнеров, проблем не будет. Можно быстро всё настроить и связать друг с другом.
⇨ Сайт / Исходники / Demo (casaos / casaos)
#linux
Не знаю, за что CasaOS снискала свою популярность. Скорее всего за лёгкий и красивый веб интерфейс. Похожие проекты существую давно. Например, Runtipi, про который я ранее уже писал. Там, кстати, в комментариях как раз CasaOS упоминали. По своей сути это просто веб интерфейс поверх работающих Docker контейнеров, которые устанавливаются из встроенного магазина преднастроенных приложений.
Можно было бы предположить, что это продукт для тех, кто не умеет и не хочет уметь работать с консолью Linux, ничего не знает, а хочет просто мышкой потыкать и получить настроенный сервер. Но на самом деле с CasaOS это так не работает. Без знаний особенностей работы Docker контейнеров настроить нормальную работу всех сервисов скорее всего не получится. В консоль ходить не обязательно, но некоторые настройки контейнеров после установки нужно будет делать.
Сразу приведу список приложений, которые можно установить в CasaOS. Вообще, их огромное количество. Есть всё, что только можно. Сообщество насоздавало своих магазинов, которые регулярно поддерживаются и обновляются. Вот самые популярные:
◽️big-bear-casaos
◽️CasaOS-LinuxServer-AppStore
◽️CasaOS-Coolstore
◽️CasaOS-HomeAutomation-AppStore
Получается внушительный набор. Для личного сервера есть всё необходимое: FileBrowser, Nginx Proxy Manager, WireGuard, AdGuard Home, Syncthing, Transmission, Nextcloud и многое другое.
Установить CasaOS очень просто. Берём чистый сервер и ставим:
# curl -fsSL https://get.casaos.io | sudo bashНа выходе получаем работающий веб интерфейс по IP адресу сервера. При первом входе нужно будет создать учётку. Дальше я настроил и потестировал прикладную связку из WireGuard + AdGuard. Сначала установил AdGuard Home. Первый вход из админки запускает стандартный установщик AdGuard, который в том числе настраивает доступ к веб интерфейсу. По умолчанию это будет 80-й порт, но он уже занят интерфейсом самого CasaOS. Поэтому после установки контейнера, надо зайти в настройки AdGuard Home и добавить проброс ещё одного порта к уже существующим: 8080 ⇨ 80. Теперь по IP адресу сервера и порту 8080 можно попасть в веб интерфейс AdGuard.
Потом установил WireGuard Easy. После установки зашёл в настройки приложения и отредактировал некоторые параметры. В переменной PASSWORD установил свой пароль. В переменной WG_HOST указал IP адрес сервера, в WG_DEFAULT_DNS указал IP адрес контейнера с AdGuard Home. Так как он устанавливался первым, IP адрес у него 172.17.0.2.
Ну и всё. Дальше зашёл в веб интерфейс WG-Easy, создал пользователя. Импортировал конфиг в смартфон и подключился. Смартфон автоматом весь трафик завернул в туннель, а в качестве DNS сервера стал использовать контейнер AdGuard Home. А в нём можно настроить различные блокировки как по спискам рекламы, так и целые сервисы. Например, можно заблокировать полностью Youtube или VK. Таким же образом WG можно подключить на компьютере (проверил, работает) или на роутере. Причём на роутере не обязательно весь трафик заворачивать в туннель. Можно использовать только DNS сервер от AdGuard Home для блокировки рекламы.
Эту связку можно использовать для различных задач. Не буду подробно на этом останавливаться, так как за это уже начали наказывать. Пока в виде предупреждений. Авторы сайтов и ютуб каналов уже получают уведомления от Роскомнадзора. Так что если вы автор контента, имейте ввиду.
В целом, панель приятная. Если понимаешь особенности работы контейнеров, проблем не будет. Можно быстро всё настроить и связать друг с другом.
⇨ Сайт / Исходники / Demo (casaos / casaos)
#linux