ServerAdmin.ru

Недавно прочитал статью про настройку Fwknop. Впервые услышал про этот инструмент, как и подход в целом, хотя он не нов. Идея в том, что вы отправляете специальный зашифрованный пакет с клиента на сервер, а сервер вам открывает доступ на подключение. Открытие доступа может выражаться в разных действиях, но в общем случае - это разрешающее правило на файрволе. Получается аналог port knocking, но принцип действия немного другой, со своими плюсами и минусами. Сразу перечислю плюсы и минусы: ➕ Достаточно отправить только 1 пакет, что позволяет обойтись без лишней логики в настройках файрвола ➕ Отправка осуществляется с помощью программы-клиента, что позволяет унифицировать использование ➕ С точки зрения безопасности это лучше, чем набор случайных нешифрованных сетевых пакетов в обычном port knocking. ➖ Пакет для аутентификации может блокироваться в каких-то сетях, то есть это менее надёжно, чем набор стандартных icmp или tcp пакетов ➖ Для корректной работы криптографии не должно быть больших расхождений по времени между клиентом и сервером ➖ Для доступа к инфраструктуре надо устанавливать и настраивать клиента Из описания сразу понятно, что это всё своего рода костылинг. Но в современных условиях это может быть очень актуально, так как никогда не знаешь, в какой момент тот или иной vpn заблокируют и придётся искать другие способы подключения к инфраструктуре. Архитектурно fwknop и port knocking выглядят очень просто и надёжно, пока не заходит речь о разделении доступа по пользователям. Это вносит существенные ограничения на применение такого подхода. У меня есть виртуальная инфраструктура, закрытая шлюзом на Debian с Iptables. Я сразу на нём и проверил работу fwknop для проброса портов во внутреннюю инфраструктуру. Ставим сервер и создаём ключи: # apt install fwknop-server # fwknopd --key-gen KEY_BASE64: tTxUvTOxidZdK3tTkXbgk1T0fbMyR8= HMAC_KEY_BASE64: 4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA== Рисуем конфиг доступа /etc/fwknop/access.conf:

SOURCE       ANY
KEY_BASE64     tTxUvTOxidZdK3tTkXbgk1T0fbMyR8=
HMAC_KEY_BASE64   4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA==
HMAC_DIGEST_TYPE  sha256
CMD_CYCLE_TIMER  60
CMD_CYCLE_OPEN   /usr/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080
CMD_CYCLE_CLOSE  /usr/sbin/iptables -t nat -D PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080

Здесь я на 60 секунд создаю правило проброса портов с внешнего интерфейса на 10.100.1.250:8080. Для разных пользователей можно использовать разные ключи и действия со своими наборами правил. Рисуем конфиг fwknopd.conf самой службы:

ENABLE_NFQ_CAPTURE     N;
NFQ_INTERFACE        ens19;
NFQ_PORT          62201;

Запускаем службу: # systemctl start fwknop-server Проверьте, что служба слушает порт udp 62201, и откройте к ней доступ на файрволе. В качестве клиента я взял Fwknop-gui. Клиенты есть под разные системы, как с gui, так и без. Ему нужно передать ключи KEY_BASE64 и HMAC_KEY_BASE64. ☝️ Очень внимательно их копируйте и переносите. Я где-то хапнул лишний символ или пробел и очень долго разбирался, почему аутентификация не работает. В виндовом клиенте rijndael key = KEY_BASE64, а HMAC_KEY имеет идентичное именование. Пример настроек на картинке ниже. У меня в итоге всё заработало с этими настройками, но не скажу, что настройка была простая. Примеров не так много, ИИ тоже слабо помог. Разбирался сам с помощью статьи выше. Документацию тоже всю просмотрел, но там в основном интеграция с файрволом через свой скрипт управления правилами, что мне не подходит, поэтому я сами правила записал в выполнение команды. А вообще клиент сам может выполнять разные команды на сервере после прохождения аутентификации. То есть правила для файрвола можно и в клиенте прописать, но надо на сервере разрешить исполнение. Мне схема как у меня показалась наиболее простой и удобной. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #security #gateway

🔝 ТОП постов за прошедший месяц май. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025. Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin. 📌 Больше всего пересылок: ◽️Моя подборка бесплатного софта для небольшой инфраструктуры (821) ◽️Использование wstunnel для SOCKS5 ппрокси (420) ◽️Ролики с женщинами на админскую тематику (379) ◽️Настройка CrowdSec как замена Fail2Ban (271) 📌 Больше всего комментариев: ◽️Моя подборка бесплатного софта для небольшой инфраструктуры (130) ◽️Новая профессия - ИИ-инженер (100) ◽️Надёжность Яндекс.Диска (94) 📌 Больше всего реакций: ◽️Моя подборка бесплатного софта для небольшой инфраструктуры (276) ◽️Перенос процесса в другую сессию SSH с помощью reptyr (179) ◽️Проблема с ядром 7-й версии в PVE (174) 📌 Больше всего просмотров: ◽️Ролики с женщинами на админскую тематику (11400) ◽️Новая профессия - ИИ-инженер (9075) ◽️XFS и EXT4, какую ФС выбирать (7930) ◽️Забавные моменты из сериала Кремниевая долина (7700) Хотел себе парсер написать для автоматического анализа всего канала и с удивлением обнаружил, что метрики просмотров в клиенте и веб версии не совпадают. Причём расхождения приличные. Если кто-то знает, почему так и где данные более точные, подскажите. #топ

Как автоматизировать работу с выделенными серверами без слез и костылей Разбираемся на бесплатном вебинаре от Selectel. Присоединяйтесь, чтобы узнать, как работать с Terraform на выделенных серверах, чем подход Infrastructure as Code может быть полезен для бизнеса и как устроен Bare Metal Cloud в Selectel. Все участники вебинара получат промокод на 3000 бонусов в панели Selectel. 📍 Онлайн ⏰ 16 июня в 12:00 Регистрируйтесь ➡️ https://slc.tl/c1foi Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь! Реклама. АО "Селектел". erid:2W5zFJF8FLd

Решил вынести в отдельную заметку видео про Proxmox, которое мне показалось полезным, потому что некоторые советы из него я применяю сам, но никогда не собирал их в одну публикацию: ▶️ 5 полезных настроек Proxmox, которые стоит внедрить Речь там идёт вот о чём: 1️⃣ Включить настройку Discard в свойствах диска виртуальной машины, если у вас хранилище на базе SSD дисков. По умолчанию она выключена. Я всегда так делаю, а гостям в cron ставлю команду: # fstrim -av После её выполнения образ диска занимает ровно столько места, сколько реально занято в системе в госте, а не весь его объём. Это существенно экономит место на хранилище. Писал об этом подробную заметку. 2️⃣ Использование стандартных настроек CPU, которые поддерживаются всеми узлами кластера. Часто хочется указать тип host, и я так делаю, чтобы использовать все возможности ядра. Но в таком случае миграция не работает, если у вас узлы кластера с разными процессорами. Придётся установить что-то, что поддерживается всеми, типа x86-64-v2-AES, x86-64-v2 или kvm64. Тут уже по месту смотрите, из чего у вас собран кластер. 3️⃣ Автор предлагает использовать SDN вместо ручных настроек сети даже в самых простых ситуациях. Совет, конечно же логичный, но я пока костылю настройки сам без SDN. Надо бы переучиваться для унификации и переносимости. 4️⃣ Динамическая балансировка нагрузки в кластере. Она появилась в свежей версии 9.4 и автор предлагает её использовать. Собственно, почему бы и нет. Лишнее напоминание тем, кто пропустил новости с обновлением. 5️⃣ Последний совет на любителя - использовать различные панели управления и визуализации, типа Pulse или PegaProx. Я Pulse в пару мест поставил, где несколько хостов PVE. Выглядит красиво и удобно, но не сказать, что сильно надо. Можно и обойтись. Некоторые дополнительные советы от меня по первоначальной настройке PVE: ◽️Сразу через веб интерфейс отключаю enterprise репозиторий ◽️Готовлю простенький шаблон с системой для раскатки через cloude-init. ◽️Если не будет настраиваться ограничение доступа к веб интерфейсу через файрвол, то делаю его в настройках pveproxy через указание доверенных IP. ◽️Настраиваю отправку уведомлений (email, gotify) ◽️Если используется zfs, настраиваю лимит использования памяти ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #proxmox

И в продолжение утренней темы про переезд серверной. Как уже сказал, один из серверов не завёлся. Там был гипервизор Hyper-V. Раньше я постоянно использовал его бесплатную редакцию, потому что удобно и много инструментов для бэкапов. Последние несколько лет ставлю везде Proxmox. Тут поленился сделать заранее переезд на новый гипервизор, за что и поплатился. С виндовым терминальным сервером пришлось повозиться. В общем случае переезд с Hyper-V на Proxmox у меня выглядел просто: 1️⃣ Импортировал VHDX образ диска из Veeam Backup & Replication в файл. 2️⃣ Подмонтировал в Proxmox шару с файлом и забрал на гипервизор. # mount -t cifs //192.168.0.7/backup /mnt/fileserver -o user=backup,password=pass123 3️⃣ Создал новую машину в PVE без дисков. 4️⃣ Сконвертирал и сразу подключил диск к новой машине: # qm importdisk 107 /mnt/fileserver/terminal.vhdx local Формат команды следующий: # qm importdisk <vmid> <source> <storage> Система была без EFI, так что никаких лишних заморочек. Но дальше начались свои приключения, с которыми пришлось разбираться, так как у меня почти нет практики восстановления Windows. Если в Linux мне всё понятно - загрузчик grub, стартовый образ initramfs и дальше основная система, то винда - тёмный лес. Хорошо, что для таких случаев есть ИИ, который хоть и не давал точных ответов без ошибок, но направление было понятно. В системе не было драйверов virtio, соответственно, система не загрузилась, потому что загрузчик не нашёл диск, с которого надо грузиться. Дальше в целом понятно, что надо делать, но когда ты делаешь это в первый раз, возникает очень много нюансов, а основное неудобство в том, что работать приходится с консолью виртуальной машины, в которой не работает копирование и вставка. Всё приходилось набирать руками. И до кучи в здании не было интернета, потому что туда провели оптику, вроде как всё проверили, но когда я заехал по факту был обрыв волокна. Приехал по заявке монтажник почему-то без оборудования для варки, потому что подумал, что повреждён оптический патчкорд. В общем, всё как обычно 😱 Рассказываю суть, как чинить загрузку Windows систем при переезде в Proxmox, если про какой-то причине вы заранее не установили туда драйвера. 1️⃣ Загружаемся в режиме восстановления и запускаем cmd. 2️⃣ Запускаем diskpart, вводим команду list volume, чтобы узнать букву диска, где стоит система, и букву диска с драйверами virtio. Диск с Windows VirtIO Drivers надо скачать и подключить к машине. 3️⃣ С помощью dism можно интегрировать в неработающую систему нужные драйвера (viostor для ide и vioscsi для scsi). Для меня это было новым знанием: > dism /image:C:\ /add-driver /driver:D:\viostor\w10\amd64\viostor.inf 4️⃣ Далее оказалось, что интеграции драйверов недостаточно, их нужно то ли активировать, то ли добавить в загрузку. К сожалению, команд не сохранил, потому что смотрел их со смартфона. В общем, надо добавить ключ в реестр, чтобы драйвер загружался. Это тоже всё делается в cmd. 5️⃣ Опять с загрузкой провал. Система не грузится и ругается на неподписанный драйвер. Это ограничение можно обойти либо опять же командой в аварийной консоли, либо выбрав режим загрузки Windows, который есть в списке вместе с различными вариантами безопасной загрузки, который позволяет использовать неподписанные драйвера. 6️⃣ После всех описанных действий система загрузилась. Всё это заняло много времени и может показаться, что путь нерациональный с точки зрения того, что ничего не было подготовлено заранее. У меня на самом деле был подменный сервер с Hyper-V, куда бы я мог всё восстановить, но раз уж случилось, решил сразу переехать на Proxmox, чтобы потом опять не заниматься этой задачей. По ходу дела уже думал развернуть бэкап на Hyper-V, установить драйвера и вернуть на PVE, но не захотелось по сети гонять огромный образ диска. Решил вопрос на месте. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #proxmox #hyperv

🫣 Вы ведь не переносите вручную данные из сервис деска в другую систему и обратно, правда? 4 июня в 11:00 МСК приглашаем на вебинар «Как подружить ITSM 365 с другими сервисами: 4 способа настройки интеграций под ваши задачи» Особенно ждем тех, кто копирует и вставляет хочет улучшить автоматизацию сервисных процессов и узнать, что предлагает ITSM 365 в плане взаимодействия со сторонними системами. А нам есть что предложить: 3 базовых варианта и 1 альтернативный способ. 📶 Готовые интеграции — легко подключить, просто управлять 📶 Интеграции через JSON RPC — для тех, кто хочет сделать сам 📶 Настройка вендором — мы реализуем, вы пользуетесь 📶 Реализация с помощью low-code платформы — весь процесс внутри ITSM 365, без всяких там внешних сервисов Приходите, расскажем в подробностях! 🔗 Зарегистрироваться на вебинар Реклама, ООО Смартнат, ИНН 6658396257, erid: 2SDnjevC3xe

На днях перевозил небольшую серверную на новое место. Там всего 5 серверов и сетевая обвязка вокруг них. Не люблю это дело. Оборудование, которое работает годами, очень не любит, когда его выключают и куда-то перевозят. В данном случае на 100% актуален принцип - работает, не трогай. Собрал всё на новом месте - один сервер не запустился. Сервер старый - 12 лет, ещё на SAS дисках 10k формата SFF (2.5") и железном контроллере LSI MegaRAID. Вот он то и подвёл. Просто перестал определятся. Соответственно, сам сервер работает, но диски не видит. Я и так, и сяк его покрутил, повертел, потряс, повтыкал - ничего не помогает. Сервер хоть и старый, но жаль его, свою работу он выполнял, и его 8 дисков в одном юните были очень кстати. Это известная тема, когда выходит из строя рейд контроллер. Её всегда приводят в пример, когда спорят на тему, нужен ли он, или лучше использовать программную реализацию. Конкретно в этом споре мне довод о том, что рейд контроллер может сломаться, кажется нелепым. Сломаться может всё, что угодно. В любом случае должны быть бэкапы, чтобы не переживать за железо. У меня бэкапы были, уже развернул. Не без приключений, но всё получилось. Отдельно об этом расскажу. Для меня выбор между железным рейдом и софтовым даже сейчас не очевиден. Да, рейд контроллер - это ещё одна точка отказа и его функциональность почти полностью может заменить программный рейд. Но в то же время отвязка системы хранения от ОС с управлением и мониторингом через BMC (Baseboard Management Controller), плюс, простая и понятная горячая замена дисков, тоже выглядят удобным. Если всё нормально настроено, сбойный диск просто начинает мигать красным. Ты его вынимаешь, заменяешь и запускается ребилд, либо диск встаёт в резерв, а ребил уже был выполнен резервным диском. Всё максимально просто, даже сервер выключать не надо. В итоге я каждый раз ломаю голову при заказе нового сервера, брать нормальный рейд контроллер или нет, прокидывать диски в систему напрямую. А вы что предпочитаете? По поводу переезда серверов лишний раз хочу напомнить, что если выключаете, а тем более перевозите оборудование, которое много лет работает онлайн, всегда держите в голове, что что-то может не включиться. Я много раз с этим сталкивался. Чем старее железо, тем больше вероятность, что оно не включится. И хорошо, если будет понятно, что вышло из строя, а это не всегда так. Там банально пластик пересыхает в проводах, пропадает контакт или становится нестабильным. Конечно, хорошо полностью отвязаться от железа и арендовать облачные ресурсы. Но если взять, к примеру, этот сервер, который проработал 12 лет, и арендовать эти же ресурсы в облаке на такой же срок, то не ошибусь, если предположу, что расходов будет на порядок больше - раз в 10-20. #железо

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились. 🔥 Proxmox с 0 до 100%. Всё, что нужно знать! Автор серьёзно заморочился и записал 5-ти 😱 часовое видео по настройке Proxmox, где есть всё: виртуалки, контейнеры, кластер, SDN, CEPH, бэкапы и т.д. Я всё не смотрел, так как это знаю. Но видео у автора всегда качественные, так что рекомендую тем, кто хочет изучить эту тему. ⇨ AGENTS.md и CLAUDE.md: как готовить? Короткое видео с описанием и примерами настройки указанных файлов для ии-агентов. ⇨ Создаём Agent skills | Навыки агента Ещё одно коротенькое наглядное видео с описанием и созданием скилов для ии-агентов. У автора классное повествование, люблю его короткие ролики, где только суть. ⇨ Почему DevOps не могут найти работу в 2026 году? Что я увидел на собеседованиях Любопытный опыт собеседований автора, когда куча кандидатов накручивают опыт и врут. А вообще с работой в IT сейчас не очень. Так что не разбрасывайтесь ею и не делайте резких необдуманных движений. ⇨ Pi: Open-Source AI Agent Terminal Set-Up Обзор ии-агента Pi. Очень похож на Opencode, которым пользуюсь я. Как я понял, основная фишка Pi - максимальная лёгкость и экономия контекста, что наиболее актуально для локальных моделей, если хочется экономить токены и повышать общую производительность. ⇨ СРАВНЕНИЕ топовых Harness на локальных моделях:Opencode, Pi, Hermes, OpenClaw Короткое видео с результатами тестов агентов на реальных задачах. Кому не интересно смотреть, сразу скажу, что агенты несильно отличаются друг от друга, но чуть лучше других показали себя opencode и openclaw. ⇨ Я заставил 9 нейросетей решать задачи — победила самая дешёвая Ещё одни тесты, только уже открытых нейронок. Победил DeepSeek V4-Flash. Сами результаты тестов не особо интересны. Больше интересно посмотреть на примеры конкретных задач, которые они решают. ⇨ Один инструмент для всего доступа в homelab — NetBird Пример настройки Netbird - сервера для mesh сети из устройств на базе WireGuard. Автор разворачивает его на внешнем VPS и демонстрирует новую функциональность этого сервера, которая позволяет публиковать веб ресурс из внутренней сети с аутентификацией на базе Netbird. В этом плане Netbird стал похож на Pangolin, у которого публикация веб ресурсов - основная функциональность. ⇨ Pangolin — зачем он нужен твоему homelab? И тут же обзор Pangolin с решением той же задачи - публикация веб приложения из закрытой сети в интернет через внутреннюю mesh сеть. ⇨ Technitium: The Self-Hosted DNS Server You Should Run Подробный разбор функционального DNS сервера Technitium, как замену Bind или Dnsmasq для небольших сетей. Сервер классный, мне очень понравился, когда тестировал его. ⇨ Выбираем NAS для дома в 2026 году и не только Автор просто фанат насов. У него чего только не было - Synology, Terramaster, Aoostar, Zimaboard. Может ещё какие, я не особо слежу за этой темой. Если вы подбираете себе NAS, то имеет смысл его послушать. Он по умолчанию рекомендует Synology, как эталон беспроблемной системы для NAS. Я, кстати, с ним полностью. согласен. Если нет желания разбираться во всём этом и есть деньги, то берите Synology и не забивайте себе голову. У меня XPEnology уже 15 лет работает, всем устраивает. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #видео

Проверьте свои знания о безопасности облачной инфраструктуры и получите 1 000 бонусов в панели Selectel, чтобы протестировать облачные сервисы на практике. Узнать, где правда → https://slc.tl/n5s7i?erid=2W5zFK2beYh

На днях на хабре видел статью под названием "Стек российского сисадмина в 2026". Статья в корпоративном блоге, написана для продвижения своего продукта. Содержание мне не особо понравилось, поэтому ссылку не привожу. Понравилась сама идея. Я подумал, что мне есть что сказать по этой теме. Через меня столько софта проходит в рамках ведения этого канала и сайта, что я даже не представляю, у кого есть такая же насмотренность. Я буквально знаю почти весь софт, про который смотрю ролики или читаю статьи. Причём не просто знаю, а я его скорее всего разворачивал, тестировал, обсуждал в комментариях, а что-то и сам стал использовать после написания заметки. Итак, моя субъективная подборка бесплатного софта для системного администратора небольшой или средней компании. Ни на что не претендую. Просто сел, подумал, какой софт вспомнил для той или иной задачи, такой и указал. Подробностей не пишу, потому что по каждому продукту ссылка на мою заметку, либо он и так очень известный. 🔹Виртуализация. Сейчас без вариантов - Proxmox. Закрывает вопрос и одиночных серверов, и кластеров, в том числе с HA. Но если прям совсем его не хочется, то XCP-ng. Заметка с бурным обсуждением этой темы. 🔹Шлюз. В зависимости от ситуации и предпочтений - Mikrotik или программный шлюз на базе OPNSense, VyOS, IPFire. Если планируется настраивать какую-то экзотику из нестандартных протоколов и туннелей, то своя сборка на базе Linux. Для соответствия требованиям регуляторов можно взять ИКС. 🔹Статистика по трафику: Akvorado, Elastiflow, Arkime, GoFlow2. 🔹Обнаружение (IDS) и предотвращение (IPS) вторжений: Suricata, Clear NDR (SELKS), Zenarmor. 🔹SIEM-система: Wazuh, RvSIEM. 🔹Шлюз удалённых подключений внутрь инфраструктуры: Nexterm, Infrax, Apache Guacamole. 🔹Удалённый доступ к пользователям: Infrax, Aspia, OpenRPort, MeshCentral, RustDesk. 🔹VPN. Для меня без вариантов - OpenVPN, веб интерфейсы для него. 🔹Мониторинг. База для полноценного мониторинга: Zabbix, Prometheus (Prom++), VictoriaMetrics, Netdata, Checkmk. Более простые решения: Infrax, Gatus, Uptime Kuma, Beszel. 🔹Почтовый сервер. Самосбор на Linux, готовые сборки: Carbonio CE, Mailu, Mailcow, Poste.io, Mail-in-a-Box, Stalwart Mail Server. 🔹Файловый сервер. Я предпочитаю настраивать Samba. Готовые решения: TrueNAS, OpenMediaVault, Cloudreve, SFTPGo, Seafile, ownCloud Infinite Scale, OpenCloud. 🔹Сбор логов: ELK Stack, Loki, VictoriaLogs. Перечислены от сложного к более простому. 🔹Бэкапы. База для бэкапа виртуалок - Proxmox Backup Server + Client для сбора файлов у клиентов (Windows только через WSL или сторонний клиент). Альтернатива - Veeam Backup & Replication Community Edition, если умещаетесь в рамки бесплатной версии. Бэкап на клиентах - Veeam Agent for Windows или Linux Free. Прочие системы для бэкапа разрозненной информации с GUI: Hasleo Backup Suite Free, AOMEI Backupper Standard, с веб интерфейсом: Zerobyte, Minarca Backup, Duplicati, UrBackup, BackupPC, ElkarBackup и без него: ReaR, Restic, Borg, Rclone, Rsync. 🔹Чат-сервер. Больше всего работал с Rocket.Chat. Все бесплатные серверы - это те или иные компромиссы. Выбирать приходится из того, что больше нравится, подходит: Mattermost, Zulip, TrueConf Server Free, Nextcloud Talk. Остальные платформы менее распространены. 🔹Телефония. Рекомендую покупать, как сервис. Если всё же хочется своего, то ванильный Asterisk, либо MikoPBX. 🔹Совместная работа. Для совместной работы у меня однозначный лидер - Onlyoffice. Наиболее близкий аналог - Nextcloud с дополнением Onlyoffice DocumentServer. 🔹HelpDesk системы: Zammad, OTRS, GLPI, osTicket, UVDesk. 🔹Инвентаризация: Snipe-IT, GLPI, Tactical RMM, NetBox. 🔹Хранение паролей: Vaultwarden, Bitwarden, Passbolt, Bearpass, Psono. Если пропустил какой-то класс программ, подскажите. Постарался максимально широко охватить всё, что может пригодиться в работе. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #подборка

Вчера на прогулке прослушал длиннющий вебинар на тему, которую я никак не мог пропустить. Она тут на канале обсуждалась раз 10 в разное время: ⇨ Zabbix vs Prometheus на практике Особо чего-то полезного и интересного, чего бы не знал, я не услышал. Автор сразу признался, что с Zabbix не работает, знает его приблизительно по старой памяти, когда сталкивался с ним по работе много лет назад. Из-за этого был в некоторых местах необъективен и никто не поправил в чате. Например, он открыл из какого-то шаблона Zabbix старые графики, которые никто уже не использует, которые выглядят, как графики из начала двухтысячных и показал, как он мог бы быстро и удобно создать дашборд с визуализацией в Grafana в противовес тому, что он увидел на этих графиках. А факт в том, что в Zabbix в современных дашбордах можно получить так же быстро точно такой же дашборд ровно с такими же виджетами, как в его примере. Так же был продемонстрирован как пример удобства - сквозной запрос в Prom по какой-то метрике в разрезе сразу всех узлов. Zabbix тоже в какой-то момент после смены синтаксиса научился так делать. Не то, чтобы я защищаю Zabbix. Он в этом не нуждается. Я и то, и другое активно использую и более-менее прилично знаю. Это инструменты под свои разные задачи. Я тут за объективность. Пишу заметку, чтобы акцентировать внимание на ключевом отличии с точки зрения автора вебинара между этими двумя системами. Никогда не смотрел на них под этим ключом. В Zabbix всё крутится вокруг айтема, который привязан к метрике и по сути ей и является. Тебе обязательно надо подготовить систему мониторинга и конкретно узел, создав на нём тем или иным способом айтем - вручную, через шаблон, через правило автообнаружения или ещё как-то. И только после этого ты можешь принимать данные. Без этого ничего не получится. В Prometheus принципиально другой подход - туда без всякой подготовки можно лить разные метрики. На сервере под каждую метрику не нужно создавать никаких сущностей. Хочешь 10 метрик отправляй, хочешь через минуту - 100. Серверу всё равно, он примет все без какой-либо донастройки. Это экономит время и организационно выглядит проще, что имеет решающее значение для динамических сред при выборе инструмента сбора метрик. Архитектурно всё так и есть, это отличие ключевое. Я обычно на этот вопрос смотрю с точки зрения пользовательского опыта и воспринимаю Zabbix как полноценную систему мониторинга, где из коробки есть всё, что для неё нужно с удобной панелью управления. А Prometheus больше похож на фреймворк, который только собирает метрики, вокруг которого тебе предстоит самому из разных компонентов создать систему мониторинга. Как по мне - это ключевое отличие. Просто взгляд на продукты под другим углом. Сколько лет прошло, а это принципиальное отличие не меняется. Из-за него у Prometheus появилось несколько совместимых взаимозаменяемых продуктов, которые можно безболезненно менять местами в системе мониторинга, не трогая остальные компоненты. А Zabbix как был сам собой, так и остался. Никто его не форкнул, не доработал, не написал совместимую замену. Были попытки, но все они остались местечковыми и не получили широкого распространения. Второе заметное отличие с точки зрения практической работы с ним - Prometheus полностью совместим с подходом IaC, Zabbix - нет. Ну и ещё один полезный момент. На вебинаре кто-то в чате написал, что активные агенты меньше нагружают сервер, так как сами шлют метрики, что упрощает процесс сбора. На самом деле это не так. Пассивные проверки архитектурно проще и если есть возможность забирать метрики сервером, то лучше делать именно так. Сервер обратился к агенту и забрал метрики. Если агент сам их отправляет, то он сначала стучится к серверу, забирает у него набор настроенных для него метрик и потом только их отправляет. Это больше итераций. Плюс, под нагрузкой у сервера меньше вариантов разрулить её, когда на него постоянно валится поток данных. Проще самому им управлять. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #zabbix #prometheus

🔔 Прокачайте навыки работы с 1С на ежегодной технической конференции 1C‑RarusTechDay 2026! Полезное событие для всех, кто работает с платформой: от новичков до опытных специалистов. В программе: • честный разговор профессионалов; • разбор случаев из практики специалистов 1С; • ответы на вопросы в чате онлайн. 📌 Когда: 16 июля 2026 г. в 09:00 🌐 Формат: онлайн, бесплатно 👉 Присоединяйтесь к конференции, чтобы прокачать практические навыки и применять их в своих проектах. ▶️ Регистрация открыта #RarusTechDay

Продолжу тему с Immich, так как плотно занялся настройкой. Подробной практической информации по настройке я почти не встречал, так что со всем разбирался сам. Чтобы не забыть и помочь тем, кто будет настраивать, зафиксирую основные моменты. ▪️Сам сервис Immich для просмотра фотографий требует немного ресурсов. Я запустил на 4 CPU старого i3, 4 ГБ оперативы, RAID1 на 2 HDD. Выделил 200 ГБ под его базу данных и миниатюры. На 110 000 фоток (500 ГБ) миниатюры заняли примерно 80 ГБ. Параметры миниатюр можно настроить. ИИ анализирует только миниатюры, а не реальные фото. Так что от них зависит качество аналитики. ▪️Всю аналитику на базе LLM можно вынести на другую машину, что я и сделал. Берём секцию из docker-compose.yml для контейнера immich-machine-learning и запускаем его на любой производительной машине, желательно с видеокартой. Потом в разделе Settings ⇨ Machine learning settings добавляем url этой машины, примерно так - http://192.168.137.29:3003. Я рассчитывал, что добавив несколько серверов, можно будет параллелить задачи, но это так не работает. Выполняется проверка доступности всех добавленных серверов. Какой первый по списку будет доступен, туда и пойдут все запросы. Если сервер становится недоступен, запросы идут на следующий. То есть имеет смысл добавить один внешний сервер и для подстраховки за ним оставить локальный. Если удалённый становится недоступен, запросы пойдут на локальный. Основная нагрузка идёт в момент добавления новых файлов. После того, как всё обработается, LLM почти не проявляет активность. Если вы никуда не торопитесь, то можно не заморачиваться с производительной LLM. ▪️Модели для поиска и распознавания лиц можно выбирать там же в настройках ML. По умолчанию для поиска используется простая LLM, которая даже русского языка не знает. Выбрать модель с поддержкой русского можно тут. Все поддерживаемые для всех задач модели перечислены здесь, можно выбрать более качественные. Я для поиска выбрал среднюю модельку ViT-L-16-SigLIP2-256__webli. Меня качество поиска на русском языке устроило. Без проблем находит, к примеру, море, лес, собак, кошек, самолёты и прочие предметы. Мне этого достаточно. ▪️По умолчанию запускаются сразу все задачи по обработке - создание миниатюр, поиск метаданных, поисковой индекс, поиск и распознавание лиц, поиск дубликатов. Если разом залить много фоток или подключить большую внешнюю библиотеку, всё это будет выполняться медленно и мешать друг другу в битве за ресурсы. Лучше включать всё последовательно: сначала миниатюры, потом метаданные, а дальше по потребностям. С миниатюрами хотя бы можно будет просматривать фотки и формировать альбомы. ▪️В веб интерфейсе по умолчанию отключен просмотр медиа через обозреватель файлов в файловой системе, а это удобно, если у вас там уже выстроена структура. Включить его можно в настройках профиля пользователя, в разделе Features. ▪️По умолчанию все загружаемые файлы складываются в иерархию со случайными именами папок и файлов, что неудобно, так как структура жёстко привязана к потрохам immich. Это можно исправить, задав шаблон для архива. Настраивается в Settings ⇨ Storage Template. Шаблон по умолчанию будет вида /library/admin/2026/2026-03-24, что лично меня вполне устроило. Просто включил его. Даты файлов берутся не из времени заливки, а из метаданных, если они там есть. ☝️ Шаблон можно менять и потом конвертировать текущую структуру в новый формат. ▪️Поиск дубликатов работает средствами LLM, и работает хорошо. Можно либо вручную с ними разбираться, либо автоматом убрать все дубликаты. Система оставляет файл наибольшего размера и с наибольшим количеством метаданных. Если внешняя библиотека подключена в режиме rw, то дубликаты могут быть физически удалены. Система мне понравилась, когда вник во все нюансы, особенно с настройками LLM. Реализовано так или иначе всё, что мне нужно от подобной системы. Это хороший пример того, как небольшие локальные модели могут эффективно решать поставленные задачи. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #fileserver

Предупреждение для тех, кто использует облачные хранилища файлов, как основные. Как я уже не раз говорил, у меня используется Яндекс.Диск, но исключительно, как резервное хранилище. Основное у меня дома на NAS. Оно копируется ещё в одно место локально, и в облако. Объём основной полезной информации в районе 1,5 ТБ и это ~175 тыс. файлов. Я провёл несколько экспериментов с облачным хранилищем, о которых хочу рассказать. Если у вас там хранится важная информация, то рекомендую обратить на это внимание. 1️⃣ Взял чистую систему, установил туда клиент Яндекс.Диска и запустил синхронизацию, чтобы проверить, сколько времени займёт загрузка облачного архива. Канал в интернет - 100 мегабит, размер файлов в облаке - 1,1 ТБ. В идеальных условиях это должно качаться 25-30 часов. У меня в итоге ушла неделя. Большую часть времени клиент что-то обрабатывал и не занимал канал, и компьютер тоже особо не нагружал. Он не был узким местом. Если храните там какие-то важные бэкапы, которые нужно будет быстро забрать в случае аварии, имейте ввиду, что не факт, что получится это сделать. 2️⃣ Взял примерно полугодовалую локальную копию и сравнил MD5 хэши с тем, что скачалось из облака. Примерно у 500 файлов хэши не совпали, при полном совпадении всех остальных атрибутов. То есть без сверки хэшей разницу не заметить. Бегло проверил несколько из них. Это были фотки. На них наглядно видно повреждения. Проблемы были именно в облачных файлах. Где они побились - не понятно. Может во время хранения, может во время загрузки в облако или скачивания. 3️⃣ Примерно у 80% файлов были неверные даты создания. Сравнивал с основным хранилищем. Когда и почему они изменились - не знаю. Раньше никогда не обращал на это внимание. Размеры файлов одинаковые, а даты - разные. Это не сказать, что критично, но может создавать неудобства. И не понятно, как исправить, кроме как заливать туда заново все файлы с изменёнными датами. 4️⃣ Отдельно добавлю, о чём уже ранее писал. У меня был случай, когда часть файлов в Яндекс.Диске пропала. Заметил не сразу и только благодаря локальным копиям с большой глубиной хранения. Я не знаю, как обстоят дела у других облаков, но мне кажется, плюс-минус примерно так же. Стоимость хранения везде относительно низкая для такого рода услуг. Обеспечивать надёжный сервис за эти деньги вряд ли получится, поэтому могут случаться накладки. Используйте их как один из дополнительных бэкапов, но не как основное хранилище. У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней. Все сравнения и синхронизации обычно делаю с помощью программы Goodsync. #fileserver

Стрим о защите контейнеров, который нельзя пропустить Kind reminder о том, что контейнеры вообще-то тоже атакуют. Разберем актуальные угрозы и не менее актуальные технологии защиты. Конечно же, никуда без ИИ — покажем, как работает первый в российских решениях ассистент по анализу образов. Это и не только — в онлайн-дискуссии с участием экспертов «Лаборатории Касперского» и платформы «Штурвал» 28 мая в 11:00. Чтобы не пропустить, регистрируйтесь.

У меня наконец-то дошли руки заняться семейным видеоархивом. Он так разросся, что вручную его вести затруднительно. Решил подключить технологии машинного обучения в лице хранилища Immich. Это известный open source продукт, который постоянно обозревают блогеры. Посмотреть обзор - это одно, а реально попользоваться - другое дело. Меня всегда останавливало от поднятия какого-то сервиса для медиа то, что у тебя параллельно возникает ещё один архив, куда надо загружать новые файлы. Можно столкнуться с тем, что при каких-то проблемах с сервисом, можно потерять либо саму структуру файлов в нём, либо вообще сами файлы, так как они превратятся в кашу. Сейчас у меня архив хранится в сетевой папке с ручной разбивкой по событиям, датам и т.д. Это просто и надёжно, но хлопотно в плане каталогизации, потому что поток новых файлов большой, времени в нём разбираться нету. В итоге последние года всё валится в папки "Разобрать", "2025", "Старый смартфон" и т.д. Никто туда не заходит и ничего не разбирает. Всё это дело копируется в Яндекс.Диск и в ещё один локальный бэкап. Яндекс диск в целом прост и неприхотлив. По расписанию туда копируются все изменения. Файлы при желании можно посмотреть в браузере. Из аналитики только временная шкала и некоторый интеллектуальный поиск, но не понятно, как и чем он строится. Иногда могу что-то быстро найти, иногда нет. К примеру, по запросу "деревянный дом" вижу фотки своего дома. Довольно удобно. Но иногда что-то ищу, но нахожу. В итоге развернул Immich и скормил ему свой архив. Расскажу по пунктам, чем он привлёк и как там всё работает: 🔥Самое главное, почему решил его использовать - в Immich можно подключить свой уже существующий архив в виде внешнего хранилища. Для меня это ключевое преимущество. Я по прежнему всё сгружаю в сетевую папку, при желании распределяю по директориям, как мне нравится, бэкаплю по той же схеме, чтобы в случае потери Immich у меня не пострадал сам архив. Immich в него ходит в режиме чтения. 🔹Поверх моего архива Immich делает следующее: ◽️Создаёт миниатюры фотографий для просмотра в браузере. ◽️Извлекает метаданные из фоток для поиска по ним. ◽️Распознаёт содержимое фоток для поиска. К примеру, я могу найти все фотографии, где есть море, коричневая футболка, деревянный дом и т.д. Примерно так же, как в Яндекс Диске. Качество среднее. Что-то находит, что-то нет. Это всё калибруется настройками локальной LLM и качеством миниатюр, по которым ведётся поиск. ◽️Поиск дубликатов по содержимому, а не метаданным. ◽️Обнаружение и распознавание лиц. Это то, что понравилось больше всего. Распознаёт лица нормально, даже детей. Где-то после 2-3 лет детей уже не путает. Грудничка и трехлетку видит как разных детей, но это решается ручным объединением. ◽️Распознаёт текст. Я особо не проверял, как работает, у меня почти нет текста на фотках. ◽️ Кодирует видео в заданные форматы и разрешения. Я не стал это делать, не хочу плодить дубликаты файлов. То, что надо, сжимаю сам в изначальном архиве. ◽️По геометкам, если они есть, отображает на карте фотографии. Благодаря метаданным, геометкам, распознаванию содержимого и лиц можно выполнять расширенный поиск. Например, вывести все фотки какого-то ребёнка в конкретный год. Под аналитику можно использовать как встроенные небольшие локальные модели, так и подключать внешние. Не тестировал, как это работает. Из своих данных Immich генерирует миниатюры и хранит всё своё состояние в PostgreSQL. Основную ценность представляет она, если вы фотки подключаете из внешнего хранилища. Миниатюры, если что, можно пересоздать, как и переиндексировать всю медиатеку. Это процесс небыстрый, но и потеря данных некритична, если что. Пару тройку дней можно подождать, если нужно будет заново разметить. Я пока остановился на том, буду вести архив как раньше, а Immich использовать только для аналитики. Загружать фото непосредственно в него, например, через приложение на смартфоне, не буду. Это удобно, но будет приводить к раздвоению архива. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #fileserver

Кремниевая долина - наиболее мемный сериал на IT тематику, из которого есть куча нарезок и различных переводов. Особенно нарезок с Гилфойлом. С момента его выхода ничего лучше так и не сняли. Предлагаю к просмотру три наиболее забавных с моей точки зрения момента, касающихся напрямую IT и наших повседневных задач: 1️⃣ Удаление данных. Это вообще самый топ. Там можно присмотреться к консоли и увидеть реальную систему, не бутафорию. 2️⃣ Собеседование с Гилфойлом, когда его брали на работу, где он выдал великолепный монолог. 3️⃣ Обыгран популярный мем на тему табов или пробелов. Ричард бортанул подругу, когда увидел, что она ставит пробелы вместо табов. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #юмор

Как гарантировать сохранность данных ❓

Рынок резервного копирования переполнен инструментами, но наличие бэкапа не равно спокойствию за инфраструктуру. Сегодня бизнесу важно не просто делать копии, а гарантированно работать даже при сбоях. Но без грамотной стратегии и связки «интегратор + вендор» даже современные технологии становятся источником головной боли.

На вебинаре 26 мая эксперты Cloud․ru и ОБИТ закроют этот пробел. Вы узнаете:

▶️ какие тренды и актуальные практики резервного копирования существуют;

▶️ почему классическая стратегия бэкапа 3-2-1 может не работать;

▶️ почему offsite backup (внешнее резервное копирование) — одно из самых актуальных решений;

▶️ на что влияет опыт интегратора решения для резервного копирования;

▶️ что дает бизнесу взаимодействие интегратора и вендора и какие кейсы это доказывают.

👉 Зарегистрироваться 👈

Когда разбирался с файловыми системами, увидел возможность EXT4, про которую раньше не знал. Можно сделать дамп метаданных файловой системы, без непосредственно самих данных. То есть вы получаете список всех файлов с размером, правами и прочими атрибутами. Этот дамп можно примонтировать, как обычный диск, и посмотреть структуру. Всё будет выглядеть, как обычная файловая система, только самих данных не будет. Выглядит это примерно так. Работает даже для примонтированной системы. Но для надёжности, конечно, лучше отмонтировать, если есть возможность: # e2image -rf /dev/sda1 fs_raw.img # mkdir -p /mnt/fs_metadata # mount -t ext4 -o ro,noload fs_raw.img /mnt/fs_metadata В данном случае я сделал образ метаданных корневого раздела диска и примонтировал его в /mnt/fs_metadata. На практике это может быть полезным для сравнения больших разнесённых хранилищ файлов. Например, можно снять дамп метаданных, перенести его на другой сервер, там смонтировать и очень быстро найти различия с помощью того же rsync. По сети такое сравнение для больших хранилищ может длиться очень долго. А через такой дамп быстрее в разы. Выглядит это примерно так: # rsync -ani --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp --exclude=/mnt / /mnt/fs_metadata/ В данном случае --exclude используются, потому что я сравниваю корень. Оставил их для примера, если нужно будет тоже сделать какие-то исключения. На выходе получите листинг изменённых файлов, где будет указан тип файла f / d / l (файл / директория / симлинк) и чем различаются: s - размер, p - права, o - владелец и т.д. По этим меткам, соответственно, можно грепнуть и вывести только нужные различия. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #linux

При переходе на Linux с Freebsd, я почти сразу пересел на Centos, где по умолчанию была файловая система XFS. Я особо не заморачивался, и везде использовал её. Каких-то нюансов или проблем у меня с ней не было. По мере того, как стал потихоньку использовать другие ОC, в частности Ubuntu и Debian, где по умолчанию используется EXT4, стал появляться вопрос, а какую файловую систему использовать? Можно выбрать и ту, и другую. Первое, что приходит в голову, RedHat - крупная именитая компания с огромным количеством различных разработок. Если она рекомендует и по умолчанию использует XFS, почему бы просто не довериться ей. Я уже поднимал когда-то давно эту тему на канале и было много отзывов по этим ФС. Решил для себя и вас актуализировать этот вопрос, прочитав обсуждения на эту тему, некоторые статьи и поспрашивав ИИ. Вот что в итоге вынес для себя. 📌 На основе комментариев в канале и нескольких обсуждений на Reddit: ◽️XFS архитектурно более сложная система, восстановить с неё данные, если что-то пойдёт не так, намного сложнее, чем с EXT4. ◽️Аварийные выключения с гораздо большей вероятностью приведут к сбоям XFS. На эту тему прям много отзывов. ◽️XFS не получится уменьшить в размере, в отличие от EXT4. ◽️В EXT4 количество доступных inodes задаётся в момент создания, либо используется значение по умолчанию, и их вполне реально все исчерпать. Я лично с этим сталкивался. В XFS такой проблемы нет, они выделяются динамически. ◽️Из-за активного развития XFS, в разных системах могут быть разные версии ФС, так что не получится примонтировать том из одной системы в другую, где отличаются версии ФС в ядре. Это в основном актуально при подключении томов из новых версий в старые. Например, том из Centos 7 можно примонтировать в Centos 9, а наоборот - нет. Даже из Centos 8 в 9-ю версию не примонтировать. С точки зрения пользовательского опыта, EXT4 проще, универсальнее, надёжнее. 📌 Теперь набор архитектурных отличий: ◽️У XFS есть так называемые Allocation Groups (AG) - независимые группы, на которые разбита файловая система. Каждая AG работает как отдельная мини файловая система. Благодаря этому XFS более эффективно работает с параллельной нагрузкой по чтению-записи по сравнению с EXT4. Это их основное архитектурное отличие. Важно понимать, что разница эта будет заметна только при больших нагрузках на больших же хранилищах. ◽️В XFS есть поддержка Reflink - позволяет нескольким файлам использовать одни и те же блоки данных, что экономит место на диске. Она основана на механизме копирования при записи (Copy-on-Write, CoW). И ещё важный нюанс. В 2020 году вышла известная статья со сравнением производительности XFS и EXT4 в контексте использования под MySQL сервер. С учётом изменений в MySQL того времени и тестам, автор сделал однозначный вывод, что с XFS работа значительно быстрее, так что он рекомендовал использовать именно её. С тех пор было много обновлений, в том числе и EXT4 и такой разницы в производительности больше нет. Так что та рекомендация потеряла актуальность. Если верить современным тестам, то разница между этими файловыми системами в смешанной нагрузке стала минимальна. ❓ Какой я в итоге для себя сделал вывод? - Для смешанной нагрузки в различных VPS использовать EXT4 и не забивать себе голову. - XFS рассматривать только в больших хранилищах, собранных в RAID, например под видеонаблюдение, образы VM или бэкапы. Последнее наиболее актуально. Например, Veeam поддерживает технологию reflink, что существенно экономит место и увеличивает производительность хранилища с бэкапами. У меня есть одна такая большая хранилка с Veeam и там, к сожалению, EXT4. Надо было раньше эту заметку писать. Так что имейте это в виду. Я на тот момент не стал заморачиваться и сделал всё по умолчанию. И теперь Synthetic Full длится часами, а мог бы за минуты выполняться. ❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки. ——— ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩 #fileserver