На этой неделе навожу порядок в личных файлах. Собрал новый NAS на базе старого системника, где в материнке 8 SATA портов. Для холодных данных дома - идеальное устройство, только 2,5Gbps не хватает. Поставил туда Xpenology. Встала, как родная. Думаю, отдельно потом об этом расскажу.
Так вот, прежде чем переносить данные, решил навести в них порядок. Очень утомительное занятие, когда ты много лет просто всё (музыка, фильмы, игры, фотки, документы, картинки) складируешь на всякий случай, в надежде разобраться когда-нибудь потом. Вот этот потом и случился.
Разбирал папку с разными скриншотами и наткнулся на эти два из далёкого 2021 года. Причём это не фейки. Я лично скрины делал. Это вроде бы из Linkedin и Facebook. Помните, какая жизнь была всего лишь 5 лет назад? Жуткий дефицит кадров в IT. Все пытаются их нанять, переманить. Онлайн школы пачками штампуют джунов, которые тут же находят работу.
Мне недавно старый знакомый позвонил и попросил совета. Говорит, его подруга (25 лет) хочет сменить деятельность и пойти в IT. Просил посоветовать онлайн-школу, где можно купить базовое обучение. Технической вышки у неё нет. Она якобы в компах понимает и умеет Windows устанавливать. Они оба вообще не в теме и думали, что сейчас всё так же, как и несколько лет назад - заканчиваешь какие-нибудь курсы и устраиваешься на работу. Обрисовал ему картину, как есть, призадумался.
У вас как с работой? Меняли в последние полгода? Реально трудно найти работу или в России волна увольнений ещё не набрала свои обороты? Я слышал, что новичкам трудно найти работу, а так, чтобы с опытом люди сидели без работы, не слышал.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#разное
Так вот, прежде чем переносить данные, решил навести в них порядок. Очень утомительное занятие, когда ты много лет просто всё (музыка, фильмы, игры, фотки, документы, картинки) складируешь на всякий случай, в надежде разобраться когда-нибудь потом. Вот этот потом и случился.
Разбирал папку с разными скриншотами и наткнулся на эти два из далёкого 2021 года. Причём это не фейки. Я лично скрины делал. Это вроде бы из Linkedin и Facebook. Помните, какая жизнь была всего лишь 5 лет назад? Жуткий дефицит кадров в IT. Все пытаются их нанять, переманить. Онлайн школы пачками штампуют джунов, которые тут же находят работу.
Мне недавно старый знакомый позвонил и попросил совета. Говорит, его подруга (25 лет) хочет сменить деятельность и пойти в IT. Просил посоветовать онлайн-школу, где можно купить базовое обучение. Технической вышки у неё нет. Она якобы в компах понимает и умеет Windows устанавливать. Они оба вообще не в теме и думали, что сейчас всё так же, как и несколько лет назад - заканчиваешь какие-нибудь курсы и устраиваешься на работу. Обрисовал ему картину, как есть, призадумался.
У вас как с работой? Меняли в последние полгода? Реально трудно найти работу или в России волна увольнений ещё не набрала свои обороты? Я слышал, что новичкам трудно найти работу, а так, чтобы с опытом люди сидели без работы, не слышал.
———
ServerAdmin:
#разное
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍61👎4
🔥Полная и подробная установка Opnsense 26.1
Самое полное и свежее руководство по настройке программного шлюза на базе Opnsense. На сегодняшний день это самый актуальный и популярный бесплатный программный шлюз.
⇨ DevSecOps | Хранения Секретов с SOPS и использование в TERRAFORM
Практический пример настройки и использования open source системы SOPS (Secrets OPerationS) для хранения секретов в шифрованном виде в git. Вообще никогда не слышал про эту систему. Автор на практике показал, как с ней работать. Создал ключ, зашифровал его и закинул в git.
⇨ Полезные советы по Zabbix: задержка операций действий
Короткое видео с демонстрацией возможностей в Zabbix по отложенным действиям. Я почти всегда их использую для оповещений. Самый простой способ избавить от спама повторяющихся уведомлений - сделать задержку на отправку в 3-5 минут. Это сразу решает проблему для всех спамных триггеров. Иначе придётся перенастраивать именно их, а это намного дольше и более трудоёмко.
⇨ Garage S3 - Ваше личное объектное хранилище.
Обзор open source сервера Garage для S3 совместимого хранилища. Из особенностей - лёгкий, написан на Rust.
⇨ ZimaOS - лучшая NAS OS? Обзор операционной NAS системы.
Очередной обзор ZimaOS. Их уже много было, я смотрел некоторые. Если не знакомы, можете посмотреть. Мне лично для NAS больше всего нравится Synology DSM.
⇨ Cockpit: The Easiest Way to Manage Linux Servers
Обзор одной из самых популярных веб панелей для управления Linux сервером - Cockpit. Автор подробно разобрал её практическое использование, а не просто сделал обзор с возможностями. Мне лично из подобных панелей больше всего нравится Webmin. Она и внешне приятнее, и функциональности больше.
⇨ Я больше не следую этим популярным советам по домашним лабораториям
Видео с разбором шаблонных рекомендаций в виде покупки брендового железа, настройки HA, постоянных обновлений на свежее ПО и т.д. По содержанию ничего особенного, но мне понравилось то, что я по всем пунктам согласен с автором.
⇨ Вещаю про Coddy Agent на Podlodka
Авторский обзор написанного им агента Coddy Agent для работы с различными LLM. Я не пробовал, так как некогда, но обзор посмотрел, показалось интересным. Основные преимущества - удобное управление через веб, простота (один бинарник под все системы) и поддержка локальных моделей.
⇨ Vibe Coding на практике: от первой команды до деплоя на сервер
Длинное видео, которое я быстро просмотрел с перемоткой, потому что почти всё, что автор рассказал, знаю и понимаю. Но если вы не знакомы с темой, то это будет актуальное руководство, чтобы быстро въехать в тему с нуля и что-то попробовать навайбкодить.
⇨ My HomeLab Monitoring Rules // feat. Checkmk
Небольшой обзор мониторинга Checkmk. Он у нас не особо популярен, но лично мне очень понравился. Я два раза делал про него заметки с разницей в несколько лет. Оба раза разворачивал и пробовал. Я уже намертво прирос к Zabbix и что-то другое вряд ли буду где-то внедрять. Но если вам у себя надо просто поднять мониторинг, а не изучить Zabbix или Prometheus, чтобы подтянуть свои компетенции по ним, то посмотрите на Checkmk. У него свои подход и архитектура, не похожие на Zabbix и Prom, унаследованные от Nagios.
⇨ Claude Fable 5 хоронит Adobe: собрал Sony Vegas с нуля за 72 часа — новый видеоредактор Kadr
Автор сел и навайбкодил кроссплатформенный редактор видео Kadr с автоматическим созданием субтитров и интеграцией агента сразу в редактор. Агента можно просить что-то сгенерировать для ролика и сразу вставить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Полная и подробная установка Opnsense 26.1
#nas, #opnsense, #truenas, #proxmox, #ubuntu
https://prohomelab.com/posts/opnsense-26.1/ - статья на сайте
Полная установка и настройка OpnSense 26.1 для защиты домашней сети. Пошаговое руководство по созданию беспрецедентного уровня безопасности хомлаб.…
https://prohomelab.com/posts/opnsense-26.1/ - статья на сайте
Полная установка и настройка OpnSense 26.1 для защиты домашней сети. Пошаговое руководство по созданию беспрецедентного уровня безопасности хомлаб.…
👍69👎1
Очередная подборка статей авторов, которые согласились в ней участвовать. Кто не понимает, о чём идёт речь, может прочитать прошлые публикации по этой теме (раз, два).
⇨ Vane: Запускаем собственный AI поисковик на локальных моделях
Установка и настройка собственного поисковика на базе SearxNG и локальной модели в Ollama. У меня была заметка про Vane. Запускал в связке с LM Studio.
⇨ Arkeep - Централизованный Backup сервер с агентами, на базе Restic и Rclone
Подробная статья про установку и настройку бэкап сервера на базе Restic и Rclone с веб панелью для управления и агентами на хостах. Выглядит удобно и функционально. Проект совсем новый. Надо будет подождать полгодика и потом попробовать.
⇨ Serena MCP: Ассистент для твоего агента разработки
Обзор сервера Serena MCP для построения структуры связей проекта, чтобы ии-агенту было проще в нём ориентироваться, экономить токены и контекст. Автор не только установил и настроил, но и провёл тесты с Serena и без. ☝️ Использование заметно экономит контекст.
⇨ How to synchronize data between S3 storages
Синхронизация данных между S3 хранилищами с помощью rclone. Очень функциональная программа для синхронизации файлов. Чего она только не умеет.
⇨ strongSwan
Обзор проекта strongSwan, с помощью которого можно настраивать связку IKEv2 + IPsec для построения VPN сетей. После того, как Microsoft объявили прекращение поддержки протоколов PPTP и L2TP в будущих версиях своих систем, эта связка стала особенно актуальна. Статья будет дорабатываться.
⇨ mkcert - Валидные самоподписанные TLS сертификаты за 3 команды в терминале Linux
Простая утилита из репозитория Debian для генерации сертификатов на базе собственного CA.
⇨ Bash: Генерация конфигов через envsubst, here document и here string
Набор инструментов для велосипединга и костылинга на bash - инструмента настоящего линуксового админа.
⇨ RustFS - Установка и настройка S3-совместимого хранилища
Обзор современного хранилища на базе S3. Аналог MinIO и Ceph. Выглядит интересно и перспективно. Надо будет тоже попробовать. А то так и не решил, что теперь вместо Minio использовать.
⇨ NetBird - приватная сеть и публикация сервисов во внешний мир без белого айпи
Статья и одноимённое видео автора по настройке NetBird для организации сетевой связности и настройки маршрутизации разрозненных узлов и сетей. Последнее время очень популярная платформа для условного VPN, хотя её функциональность шире, чем просто объединение сетей. Работает на базе WireGuard. Так что сразу скажу, что это не для обхода блокировок.
⇨ Proxmox Backup Server 4.2.0: установка, настройка и резервное копирование Proxmox VE
Подробная статья и видео автора по настройке PBS.
❗️Кстати, автор - ещё один человек, пострадавший от перехода PVE на новое ядро 7-й версии. Только ему откат обратно на 6-ю тоже не помог, пришлось переустанавливать всю ноду. Так что будьте аккуратны с этим обновлением.
⇨ Dockhand: удобное управление Docker через веб-интерфейс с Traefik
Очередной обзор Dockhand - панели управления Docker контейнерами. Я одно время пользовался Portainer, когда запускал все контейнеры в отдельной виртуальной машине. Последнее время практикую другой подход - каждый контейнер или проект в отдельном LXC контейнере в PVE. Не так удобно управлять, зато более оптимально по ресурсам и быстродействию. Убрал лишнюю прослойку в виде виртуальной машины. Перешёл на эту схему, когда практически везде осталась только виртуализация на базе PVE.
⇨ GLPI
Установка GLPI - бесплатной открытой системы управления ИТ-инфраструктурой. По сути инвентаризация и helpdesk в одной системе.
Если у вас есть сайт подходящей тематики и вы хотите присоединиться к этой подборке, то пишите мне в личные сообщения.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#статьи
⇨ Vane: Запускаем собственный AI поисковик на локальных моделях
Установка и настройка собственного поисковика на базе SearxNG и локальной модели в Ollama. У меня была заметка про Vane. Запускал в связке с LM Studio.
⇨ Arkeep - Централизованный Backup сервер с агентами, на базе Restic и Rclone
Подробная статья про установку и настройку бэкап сервера на базе Restic и Rclone с веб панелью для управления и агентами на хостах. Выглядит удобно и функционально. Проект совсем новый. Надо будет подождать полгодика и потом попробовать.
⇨ Serena MCP: Ассистент для твоего агента разработки
Обзор сервера Serena MCP для построения структуры связей проекта, чтобы ии-агенту было проще в нём ориентироваться, экономить токены и контекст. Автор не только установил и настроил, но и провёл тесты с Serena и без. ☝️ Использование заметно экономит контекст.
⇨ How to synchronize data between S3 storages
Синхронизация данных между S3 хранилищами с помощью rclone. Очень функциональная программа для синхронизации файлов. Чего она только не умеет.
⇨ strongSwan
Обзор проекта strongSwan, с помощью которого можно настраивать связку IKEv2 + IPsec для построения VPN сетей. После того, как Microsoft объявили прекращение поддержки протоколов PPTP и L2TP в будущих версиях своих систем, эта связка стала особенно актуальна. Статья будет дорабатываться.
⇨ mkcert - Валидные самоподписанные TLS сертификаты за 3 команды в терминале Linux
Простая утилита из репозитория Debian для генерации сертификатов на базе собственного CA.
⇨ Bash: Генерация конфигов через envsubst, here document и here string
Набор инструментов для велосипединга и костылинга на bash - инструмента настоящего линуксового админа.
⇨ RustFS - Установка и настройка S3-совместимого хранилища
Обзор современного хранилища на базе S3. Аналог MinIO и Ceph. Выглядит интересно и перспективно. Надо будет тоже попробовать. А то так и не решил, что теперь вместо Minio использовать.
⇨ NetBird - приватная сеть и публикация сервисов во внешний мир без белого айпи
Статья и одноимённое видео автора по настройке NetBird для организации сетевой связности и настройки маршрутизации разрозненных узлов и сетей. Последнее время очень популярная платформа для условного VPN, хотя её функциональность шире, чем просто объединение сетей. Работает на базе WireGuard. Так что сразу скажу, что это не для обхода блокировок.
⇨ Proxmox Backup Server 4.2.0: установка, настройка и резервное копирование Proxmox VE
Подробная статья и видео автора по настройке PBS.
❗️Кстати, автор - ещё один человек, пострадавший от перехода PVE на новое ядро 7-й версии. Только ему откат обратно на 6-ю тоже не помог, пришлось переустанавливать всю ноду. Так что будьте аккуратны с этим обновлением.
⇨ Dockhand: удобное управление Docker через веб-интерфейс с Traefik
Очередной обзор Dockhand - панели управления Docker контейнерами. Я одно время пользовался Portainer, когда запускал все контейнеры в отдельной виртуальной машине. Последнее время практикую другой подход - каждый контейнер или проект в отдельном LXC контейнере в PVE. Не так удобно управлять, зато более оптимально по ресурсам и быстродействию. Убрал лишнюю прослойку в виде виртуальной машины. Перешёл на эту схему, когда практически везде осталась только виртуализация на базе PVE.
⇨ GLPI
Установка GLPI - бесплатной открытой системы управления ИТ-инфраструктурой. По сути инвентаризация и helpdesk в одной системе.
Если у вас есть сайт подходящей тематики и вы хотите присоединиться к этой подборке, то пишите мне в личные сообщения.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#статьи
Please open Telegram to view this post
VIEW IN TELEGRAM
👍51👎1
Не так давно пришло уведомление от NewReleases.io. Удобный, кстати, сервис. Я так с тех пор им постоянно пользуюсь, читаю уведомления. Так вот, там было уведомление об обновление утилиты Labean. Я уже когда-то давно писал про него. Это простой сервис, который выполняет настроенные действия при посещении того или иного url. Он до сих пор поддерживается и время от времени обновляется.
Например, обращаемся на url https://service.example.com/tuktuk/ssh/on, а Labean выполняет проброс порта на нужный сервер. То есть выполняет конкретное действие на сервере:
Или любое другое в зависимости от того, какой файрвол используете. Зашли и закрыли за собой дверь - https://service.example.com/tuktuk/ssh/off:
Проброс порта - частный случай, когда с помощью Labean реализуется принцип port knocking. Тут он удобен тем, что работает по HTTP и с большой долей вероятности не будет блокироваться, в отличии от некоторых других методов.
Можно выполнять и любые другие действия: снимать дамп с базы, перезаливать dev, обновлять контейнеры и т.д. Такой вот костылинг на небольших инфраструктурах и задачах.
Так как это HTTP, перед Labean можно поставить любой прокси типа Angie / Nginx / Traefik и т.д. и настроить там по желанию какие-то дополнительные проверки, логирования, ограничения, аутентификации и т.д.
По своей сути Labean - одиночный бинарник на Go и конфигурационный файл в формате JSON. Проще всего запускать через systemd на хосте, либо собрать свой Docker контейнер, но в данном случае не вижу большого смысла, если действия будут выполняться на хосте, а не внутри группы контейнеров, к которым его можно присоседить.
Работает Laben примерно так. Ставлю:
Создаю конфигурацию
Создаю юнит для systemd - /etc/systemd/system/labean.service:
Запускаю:
Проверяю:
Открываю в браузере url 192.168.137.29:9191/tuktuk/ssh/on, на сервере выполняется команда:
где 192.168.137.200 - адрес, с которого я делал запрос.
Это я показал максимально простой пример для демонстрации возможностей. Если будете использовать в реальной ситуации, то слушать надо "listen": "127.0.0.1:9191", а внешние запросы принимать на прокси. В репозитории есть примеры для nginx и caddy. Там же пример конфигурации и юнита systemd.
Настройка простая и интуитивная. Я сходу настроил и запустил на тестовой сервере. Сразу всё корректно отработало. Как я уже сказал, так можно выполнять любые действия. Из наиболее актуальных - открывать доступ к vpn/rdp, запускать/перезапускать/останавливать службы, добавлять/удалять маршруты и т.д. В общем, тут кто во что горазд в костылинге.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#security #gateway
Например, обращаемся на url https://service.example.com/tuktuk/ssh/on, а Labean выполняет проброс порта на нужный сервер. То есть выполняет конкретное действие на сервере:
iptables -t nat -A PREROUTING -p tcp --dport 31001 \
-i ens18 -s {clientIP} -j DNAT --to 10.30.51.4:22Или любое другое в зависимости от того, какой файрвол используете. Зашли и закрыли за собой дверь - https://service.example.com/tuktuk/ssh/off:
iptables -t nat -D PREROUTING -p tcp --dport 31001 \
-i ens18 -s {clientIP} -j DNAT --to 10.30.51.4:22Проброс порта - частный случай, когда с помощью Labean реализуется принцип port knocking. Тут он удобен тем, что работает по HTTP и с большой долей вероятности не будет блокироваться, в отличии от некоторых других методов.
Можно выполнять и любые другие действия: снимать дамп с базы, перезаливать dev, обновлять контейнеры и т.д. Такой вот костылинг на небольших инфраструктурах и задачах.
Так как это HTTP, перед Labean можно поставить любой прокси типа Angie / Nginx / Traefik и т.д. и настроить там по желанию какие-то дополнительные проверки, логирования, ограничения, аутентификации и т.д.
По своей сути Labean - одиночный бинарник на Go и конфигурационный файл в формате JSON. Проще всего запускать через systemd на хосте, либо собрать свой Docker контейнер, но в данном случае не вижу большого смысла, если действия будут выполняться на хосте, а не внутри группы контейнеров, к которым его можно присоседить.
Работает Laben примерно так. Ставлю:
# wget https://github.com/noiseonwires/labean/releases/download/v260531/labean-linux-amd64# chmod +x labean-linux-amd64# mv labean-linux-amd64 /usr/local/bin/labeanСоздаю конфигурацию
/etc/labean/labean.conf:{ "listen": "192.168.137.29:9191", "url_prefix": "tuktuk", "real_ip_header": "X-Real-IP", "allow_explicit_ips": false, "tasks": [ { "name": "ssh", "timeout": 30, "on_command": "iptables -A INPUT -i ens18 -s {clientIP} -p tcp --dport 22 -j ACCEPT", "off_command": "iptables -D INPUT -i ens18 -s {clientIP} -p tcp --dport 22 -j ACCEPT" } ]}Создаю юнит для systemd - /etc/systemd/system/labean.service:
[Unit]Description=Labean HTTP port knockerAfter=network.target[Service]Type=simpleUser=rootExecStart=/usr/local/bin/labean /etc/labean/labean.confRestart=on-failure[Install]WantedBy=multi-user.targetЗапускаю:
# systemctl daemon-reload# systemctl start labeanПроверяю:
# ss -tulnp | grep 9191tcp LISTEN 0 4096 192.168.137.29:9191 0.0.0.0:* users:(("labean",pid=1324,fd=7))Открываю в браузере url 192.168.137.29:9191/tuktuk/ssh/on, на сервере выполняется команда:
iptables -A INPUT -i ens18 -s 192.168.137.200 -p tcp --dport 22 -j ACCEPTгде 192.168.137.200 - адрес, с которого я делал запрос.
Это я показал максимально простой пример для демонстрации возможностей. Если будете использовать в реальной ситуации, то слушать надо "listen": "127.0.0.1:9191", а внешние запросы принимать на прокси. В репозитории есть примеры для nginx и caddy. Там же пример конфигурации и юнита systemd.
Настройка простая и интуитивная. Я сходу настроил и запустил на тестовой сервере. Сразу всё корректно отработало. Как я уже сказал, так можно выполнять любые действия. Из наиболее актуальных - открывать доступ к vpn/rdp, запускать/перезапускать/останавливать службы, добавлять/удалять маршруты и т.д. В общем, тут кто во что горазд в костылинге.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#security #gateway
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍77👎2
Небольшая заметка, которая у кого-то вызовет непонимание, как автор мог такого не знать. По факту не знал за столько лет работы с различной техникой.
Некоторое время назад я купил домой ИБП Ippon Kirpich 1050. Нормальный бесперебойник для дома. Рабочий комп минут 20 от него проработал. Мне столько не надо, я сразу выключаю, как только свет пропал, оставил себе попроще старый. Подключил к Кирпичу кучу всего - NAS, сервак с PVE, свитч с камерами, роутер, оптический модем. Всё нормально.
Последнее время дома основательно перетряхиваю всё своё IT хозяйство. Под это дело решил таки приобрести сервер под условно продовые свои потребности - immich, frigate, zabbix, loki, opencode и некоторые другие виртуалки, в том числе тестовые. Мне есть, куда его поставить, и где он не будет мешать своим шумом. Взял б.у. платформу Supermicro на DDR4. Набил её памятью, sas sff дисками, поставил контроллер для проброса дисков напрямую в систему.
Платформа старая, комплектующие все серверные, поэтому их можно относительно дёшево купить на Авито, что я и сделал. К примеру, планка памяти 32GB DDR4 ECC REG стоит 9300, а диск HDD SAS 2,5 1,2TB hgst 10K - 3900. Купил комплектухи по потребностям. Мне хватило 128 GB памяти.
Решил я этот сервер запитать от Kirpich. По мощности его с запасом, так что проблем не ожидал. Подключил, настроил софт, автовыключение. Подвоха не заметил. Всё было нормально несколько дней. Пока не выключили свет😄 Сервак тоже тут же выключился и начал циклично влючаться и выключаться. Выключил ИБП, дождался, когда со светом всё нормализуется и стал разбираться.
Подумал, что с ИБП проблемы. Поменял батарею. У меня была новая запасная. картина та же. Что самое интересное, софт для диагностики и управления стоит на сервере, нормально видит ИБП. Заходишь туда, нажимаешь тест батареи, сервак вырубается, тест не проходит.
Расстроился, подумал, что брак. Попробовал обратно вернуть его на прошлую нагрузку. На удивление, там всё нормально. Тут то я и заподозрил, что чего-то не понимаю. Пошёл разбираться.
Оказывается, серверные блоки питания отличаются от десктопных (кто бы мог подумать 🙄) тем, что там применяется технология с активным корректором коэффициента мощности (Active PFC). У этой технологии свои требования к выходному напряжению, а Kirpich - линейно-интерактивный ИБП, который этим требованиям не соответствует. Для этого нужен онлайн ИБП.
То, что ИБП отличаются, я знаю. Но вся моя практика такова, что в серверную всегда покупались серверные ИБП, а для десктопов - десктопные. И они никогда не пересекались. Впервые это пересечение произошло у меня дома и я узнал про эту несовместимость. На работе мне в голову не приходило питать сервера от интерактивных ИБП.
В общем, пришлось в очередной раз раскошелиться и заказать онлайн ИБП. Взял самый дешман за 14 000, поэтому не пишу, какой именно. Сначала получу, попробую, если всё будет ок, то расскажу. Уже и так поистратился на это всё, жаль стало денег на нормальный онлайн ИБП. Они от 30 000 стоят.
"Век живи, век учись".
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#железо
Некоторое время назад я купил домой ИБП Ippon Kirpich 1050. Нормальный бесперебойник для дома. Рабочий комп минут 20 от него проработал. Мне столько не надо, я сразу выключаю, как только свет пропал, оставил себе попроще старый. Подключил к Кирпичу кучу всего - NAS, сервак с PVE, свитч с камерами, роутер, оптический модем. Всё нормально.
Последнее время дома основательно перетряхиваю всё своё IT хозяйство. Под это дело решил таки приобрести сервер под условно продовые свои потребности - immich, frigate, zabbix, loki, opencode и некоторые другие виртуалки, в том числе тестовые. Мне есть, куда его поставить, и где он не будет мешать своим шумом. Взял б.у. платформу Supermicro на DDR4. Набил её памятью, sas sff дисками, поставил контроллер для проброса дисков напрямую в систему.
Платформа старая, комплектующие все серверные, поэтому их можно относительно дёшево купить на Авито, что я и сделал. К примеру, планка памяти 32GB DDR4 ECC REG стоит 9300, а диск HDD SAS 2,5 1,2TB hgst 10K - 3900. Купил комплектухи по потребностям. Мне хватило 128 GB памяти.
Решил я этот сервер запитать от Kirpich. По мощности его с запасом, так что проблем не ожидал. Подключил, настроил софт, автовыключение. Подвоха не заметил. Всё было нормально несколько дней. Пока не выключили свет
Подумал, что с ИБП проблемы. Поменял батарею. У меня была новая запасная. картина та же. Что самое интересное, софт для диагностики и управления стоит на сервере, нормально видит ИБП. Заходишь туда, нажимаешь тест батареи, сервак вырубается, тест не проходит.
Расстроился, подумал, что брак. Попробовал обратно вернуть его на прошлую нагрузку. На удивление, там всё нормально. Тут то я и заподозрил, что чего-то не понимаю. Пошёл разбираться.
Оказывается, серверные блоки питания отличаются от десктопных (кто бы мог подумать 🙄) тем, что там применяется технология с активным корректором коэффициента мощности (Active PFC). У этой технологии свои требования к выходному напряжению, а Kirpich - линейно-интерактивный ИБП, который этим требованиям не соответствует. Для этого нужен онлайн ИБП.
То, что ИБП отличаются, я знаю. Но вся моя практика такова, что в серверную всегда покупались серверные ИБП, а для десктопов - десктопные. И они никогда не пересекались. Впервые это пересечение произошло у меня дома и я узнал про эту несовместимость. На работе мне в голову не приходило питать сервера от интерактивных ИБП.
В общем, пришлось в очередной раз раскошелиться и заказать онлайн ИБП. Взял самый дешман за 14 000, поэтому не пишу, какой именно. Сначала получу, попробую, если всё будет ок, то расскажу. Уже и так поистратился на это всё, жаль стало денег на нормальный онлайн ИБП. Они от 30 000 стоят.
"Век живи, век учись".
———
ServerAdmin:
#железо
Please open Telegram to view this post
VIEW IN TELEGRAM
👍127👎6
У устройств Synology есть особый тип дисковых пулов под названием Synology Hybrid RAID (SHR). С его помощью можно создавать отказоустойчивое хранилище из дисков разного объёма. Сами они описывают его вот так:
Synology Hybrid RAID (SHR) - это автоматизированная система управления RAID от компании Synology. SHR позволяет пользователям создавать гибкие решения для хранения данных с оптимизированной емкостью и производительностью.
SHR основана на системе управления Linux RAID и предназначена для ускорения и упрощения развертывания системы хранения по сравнению с классическими системами RAID. Это делает его особенно подходящим для пользователей, которые не знакомы с технологией RAID.
Мне всегда было интересно посмотреть реализацию. Покажу на простом примере, как это работает. Допустим, у вас есть 3 диска 2ТБ и 3 диска 3ТБ. Вы хотите сделать хранилище, которое без потери данных переживёт отказ одного или двух дисков. В классических моделях RAID у вас только один вариант - отрезать от дисков 3ТБ по 1ТБ, превратив их в 2ТБ диски и собрать RAID 5 или 6 из всех дисков.
Synology предлагает ничего не отрезать и использовать весь объём дисков. Я недавно настраивал Xpenology, поэтому смог посмотреть, как они это делают. Там на самом деле одновременно всё просто и всё сложно. Synology точно так же отрезает от дисков в 3ТБ куски по 1ТБ и создаёт RAID5 с помощью всё того же MDADM, который уже лет 10 хоронят, но он живее всех живых, потому что это максимально простая и надёжная софтовая реализация отказоустойчивых хранилищ.
Из оставшихся трёх отрезков в 1ТБ от трехтерабайтных дисков опять же с помощью MDADM собирают отдельный RAID5 из трёх дисков. В итоге мы имеем:
▪️RAID5 из шести дисков с разделами по 2ТБ
▪️RAID5 из трёх дисков с разделами в 1ТБ
И потом оба эти раздела объединяются в общий Volume Group (VG) с помощью LVM. А дальше создаётся либо один логический том на всю ёмкость, либо несколько. Всё это делается через веб панель. От пользователя реализация скрыта. Он в конце сможет выбрать файловую систему: ext4 или btrfs.
Контроль целостности файлов реализуется через возможности btrfs. Что интересно, разработчики Synology не стали использовать возможности btrfs по созданию raid, а доверились проверенному mdadm.
Я многократно слышал мнение, что mdadm устарел и подлежит замене более современными решениями, потому что у него нет контроля целостности. Не согласен с этим мнением и неоднократно об этом писал и приводил примеры. Контроль за содержимым - не задача устройства хранения, коим является mdadm. Он решает ровно одну задачу - создание отказоустойчивых, надёжных массивов. А за файлами можно следить другими инструментами - btrfs, ceph, linux dm-integrity или множеством реализаций на уровне контроля за файлами.
Подход Synology не нов и не уникален. Я ещё лет 10 назад делал подобное на железном контроллере, который позволял делить диски. Точно так же отрезал куски от больших дисков и объединял их в отдельные массивы. Основной объём дисков объединял в RAID10 для горячих данных, а отрезанные куски в RAID1 для холодного хранения.
Посмотрев на всё это, не стал в Xpenology объединять разные диски. У меня как раз было 3 по 2ТБ и 4 по 3 ТБ. Сделал два пула, объединив одинаковые диски (на скрине внизу, как это выглядит на уровне системы). В целом, всё это вполне надёжно, но не знаю, насколько хорошо все ситуации обыграли инженеры Synology. Не хочется в случае ошибок получить проблемы на таком огромном пуле с разными дисками. Решил не усложнять.
Вообще, мне нравится Synology как раз тем, что ничего особо не выдумывает, а использует проверенные линуксовые решения. Да и под капотом там обычный Linux. У меня как-то были проблемы с одиночным диском, перестал определяться в Synology, слетела таблица разделов. Я без проблем подкцепил диск к обычной системе с Linux, восстановил таблицу и забрал оттуда данные. Писал об этом статью в своё время.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Synology Hybrid RAID (SHR) - это автоматизированная система управления RAID от компании Synology. SHR позволяет пользователям создавать гибкие решения для хранения данных с оптимизированной емкостью и производительностью.
SHR основана на системе управления Linux RAID и предназначена для ускорения и упрощения развертывания системы хранения по сравнению с классическими системами RAID. Это делает его особенно подходящим для пользователей, которые не знакомы с технологией RAID.
Мне всегда было интересно посмотреть реализацию. Покажу на простом примере, как это работает. Допустим, у вас есть 3 диска 2ТБ и 3 диска 3ТБ. Вы хотите сделать хранилище, которое без потери данных переживёт отказ одного или двух дисков. В классических моделях RAID у вас только один вариант - отрезать от дисков 3ТБ по 1ТБ, превратив их в 2ТБ диски и собрать RAID 5 или 6 из всех дисков.
Synology предлагает ничего не отрезать и использовать весь объём дисков. Я недавно настраивал Xpenology, поэтому смог посмотреть, как они это делают. Там на самом деле одновременно всё просто и всё сложно. Synology точно так же отрезает от дисков в 3ТБ куски по 1ТБ и создаёт RAID5 с помощью всё того же MDADM, который уже лет 10 хоронят, но он живее всех живых, потому что это максимально простая и надёжная софтовая реализация отказоустойчивых хранилищ.
Из оставшихся трёх отрезков в 1ТБ от трехтерабайтных дисков опять же с помощью MDADM собирают отдельный RAID5 из трёх дисков. В итоге мы имеем:
▪️RAID5 из шести дисков с разделами по 2ТБ
▪️RAID5 из трёх дисков с разделами в 1ТБ
И потом оба эти раздела объединяются в общий Volume Group (VG) с помощью LVM. А дальше создаётся либо один логический том на всю ёмкость, либо несколько. Всё это делается через веб панель. От пользователя реализация скрыта. Он в конце сможет выбрать файловую систему: ext4 или btrfs.
Контроль целостности файлов реализуется через возможности btrfs. Что интересно, разработчики Synology не стали использовать возможности btrfs по созданию raid, а доверились проверенному mdadm.
Я многократно слышал мнение, что mdadm устарел и подлежит замене более современными решениями, потому что у него нет контроля целостности. Не согласен с этим мнением и неоднократно об этом писал и приводил примеры. Контроль за содержимым - не задача устройства хранения, коим является mdadm. Он решает ровно одну задачу - создание отказоустойчивых, надёжных массивов. А за файлами можно следить другими инструментами - btrfs, ceph, linux dm-integrity или множеством реализаций на уровне контроля за файлами.
Подход Synology не нов и не уникален. Я ещё лет 10 назад делал подобное на железном контроллере, который позволял делить диски. Точно так же отрезал куски от больших дисков и объединял их в отдельные массивы. Основной объём дисков объединял в RAID10 для горячих данных, а отрезанные куски в RAID1 для холодного хранения.
Посмотрев на всё это, не стал в Xpenology объединять разные диски. У меня как раз было 3 по 2ТБ и 4 по 3 ТБ. Сделал два пула, объединив одинаковые диски (на скрине внизу, как это выглядит на уровне системы). В целом, всё это вполне надёжно, но не знаю, насколько хорошо все ситуации обыграли инженеры Synology. Не хочется в случае ошибок получить проблемы на таком огромном пуле с разными дисками. Решил не усложнять.
Вообще, мне нравится Synology как раз тем, что ничего особо не выдумывает, а использует проверенные линуксовые решения. Да и под капотом там обычный Linux. У меня как-то были проблемы с одиночным диском, перестал определяться в Synology, слетела таблица разделов. Я без проблем подкцепил диск к обычной системе с Linux, восстановил таблицу и забрал оттуда данные. Писал об этом статью в своё время.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
👍113👎3
Среди бесплатных серверов с реализацией протокола S3 долгое время безоговорочным лидером был MinIO. Он был простой, функциональный, с открытым исходным кодом. Для базовых задач self-hosted размещения все брали его и не забивали себе голову. Разработчики сначала урезали возможности бесплатной версии, а потом и вовсе перестали её разрабатывать и поддерживать. И теперь однозначного лидера нет, и что выбирать - не понятно.
Я попробовал разобраться с этим вопросом, причём не только с помощью ИИ, но и изучив некоторые материалы самостоятельно, банально погуглив и почитав материалы, обсуждения.
🔹Первое, что приходит на ум - Ceph. Это мощное, зрелое, кластерное решение от трёх узлов и до десятков, а возможно и сотен. Хотя можно и на один узел развернуть. Там есть в том числе S3, но сравнить его с MinIO язык не поворачивается. Это разного масштаба и архитектуры системы.
🔹SeaweedFS - относительно старый для этой ниши продукт. Я про него слышал ещё лет 5 назад как альтернативу MinIO. Он вполне стабильный и зрелый. По функциональности не уступает MinIO. Есть много статей с внедрением SeaweedFS в крупных компаниях, либо с его использованием как основы для своего самописного решения. Можно без особых опасений брать и пользоваться, но есть одно НО. Это фактически продукт одного человека. Будет ли кто-нибудь дальше поддерживать этот проект, если автору в какой-то момент всё это надоест - неизвестно.
🔹RustFS - свежий продукт, который начали активно пилить после ограничений MinIO. На основе некоторых тестов считается, что он очень быстрый. Написан же на Rust 😎. На деле у него совсем недавно был вот такой вот нюанс - в коде открытого проекта RustFS обнаружен предопределённый токен доступа. Сразу понятен подход к разработке и выкатке релизов. Официально всё ещё в бете. Пишут китайцы. Как по мне, пока всё это выглядит не очень. Надо хотя бы стабильного релиза подождать и посмотреть, что в итоге навайбкодят китайцы.
🔹Garage - более зрелый продукт по сравнению с RustFS. Пишется небольшой французской компанией с 2020 года. Тоже, кстати, на Rust. Легко разворачивается, настраивается как для маленького проекта на одной ноде, так и в небольшой кластер из нескольких. Есть веб интерфейс для управления, оператор для кубера, поддерживается фактор репликации, сжатие, дедупликация. То есть выглядит всё это как простое стабильное решение с базовой функциональностью для этой задачи. Мне показалось это на текущий момент оптимальное решения для замены MinIO.
Отдельно отмечу то, что тоже рассматривал, но не стал включать в список, так как показалось не очень актуальным. Но может кому-то приглянётся:
- S3 на базе Vitastor.
- Zenko CloudServer, Vitastor его использует, про cloudserver я ранее писал заметку.
- s4core - свежий проект навайбкоденный одним человеком, по описанию всё красиво, на практике не понятно, как будет работать, отзывов не нашёл.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#s3
Я попробовал разобраться с этим вопросом, причём не только с помощью ИИ, но и изучив некоторые материалы самостоятельно, банально погуглив и почитав материалы, обсуждения.
🔹Первое, что приходит на ум - Ceph. Это мощное, зрелое, кластерное решение от трёх узлов и до десятков, а возможно и сотен. Хотя можно и на один узел развернуть. Там есть в том числе S3, но сравнить его с MinIO язык не поворачивается. Это разного масштаба и архитектуры системы.
🔹SeaweedFS - относительно старый для этой ниши продукт. Я про него слышал ещё лет 5 назад как альтернативу MinIO. Он вполне стабильный и зрелый. По функциональности не уступает MinIO. Есть много статей с внедрением SeaweedFS в крупных компаниях, либо с его использованием как основы для своего самописного решения. Можно без особых опасений брать и пользоваться, но есть одно НО. Это фактически продукт одного человека. Будет ли кто-нибудь дальше поддерживать этот проект, если автору в какой-то момент всё это надоест - неизвестно.
🔹RustFS - свежий продукт, который начали активно пилить после ограничений MinIO. На основе некоторых тестов считается, что он очень быстрый. Написан же на Rust 😎. На деле у него совсем недавно был вот такой вот нюанс - в коде открытого проекта RustFS обнаружен предопределённый токен доступа. Сразу понятен подход к разработке и выкатке релизов. Официально всё ещё в бете. Пишут китайцы. Как по мне, пока всё это выглядит не очень. Надо хотя бы стабильного релиза подождать и посмотреть, что в итоге навайбкодят китайцы.
🔹Garage - более зрелый продукт по сравнению с RustFS. Пишется небольшой французской компанией с 2020 года. Тоже, кстати, на Rust. Легко разворачивается, настраивается как для маленького проекта на одной ноде, так и в небольшой кластер из нескольких. Есть веб интерфейс для управления, оператор для кубера, поддерживается фактор репликации, сжатие, дедупликация. То есть выглядит всё это как простое стабильное решение с базовой функциональностью для этой задачи. Мне показалось это на текущий момент оптимальное решения для замены MinIO.
Отдельно отмечу то, что тоже рассматривал, но не стал включать в список, так как показалось не очень актуальным. Но может кому-то приглянётся:
- S3 на базе Vitastor.
- Zenko CloudServer, Vitastor его использует, про cloudserver я ранее писал заметку.
- s4core - свежий проект навайбкоденный одним человеком, по описанию всё красиво, на практике не понятно, как будет работать, отзывов не нашёл.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#s3
Please open Telegram to view this post
VIEW IN TELEGRAM
Garage
The Garage team - An S3 object store so reliable you can run it outside datacenters
7👍76👎1
Практически всегда, когда стоит вопрос покупки жёсткого диска для различных задач, я отдаю предпочтение линейке WD Red. Она периодически меняет свой состав. С появлением моделей Red Pro отдаю предпочтение именно им. Хотя сейчас имеет смысл внести поправочку. Раньше отдавал предпочтение. Сейчас посмотрел цены, вопросов стало больше. Разница между Plus и Pro существенная. Но в целом это всё равно будет линейка WD Red.
На картинке выше пример одного сервера под бэкапы, где стоят эти диски. У некоторых наработка 13+ лет. Один из таких начал сыпать в мониторинг Current_Pending_Sector. 14 штук уже набралось, решил поменять его, заодно посмотрел статистику остальных дисков. Они там собраны в RAID6. Самые старые диски уже 2 переезда на новое железо пережили. Менялась платформа, а диски оставались. Рейд, собранный в mdadm, спокойно переезжает на новое железо. Просто переносишь диски и инициализируешь массив. Mdadm видит собранный массив на старых дисках и просто запускает его. Все разделы, данные, сохраняются.
В целом, это типичная картинка для этих дисков. Они чаще всего работают долго, стабильно, надёжно. Если проблемы возникают, то в смарте они как правило тоже присутствуют. Не припоминаю, чтобы хоть раз подобный диск отработал меньше 3-4 лет. Вроде было разок, но тогда ещё работал их сервисный центр, гарантийный диск менялся без вопросов на новый. Можно было курьером отправить. А гарантия была вроде бы 5 лет. Сейчас, к сожалению, такой гарантии производителя уже нет, только от магазина 1-2 года. Там уже как повезёт с заменой.
Единственное, на что обращаю внимание - это чтобы тип записи точно был CMR, а не SMR. Был один момент с этими дисками, когда производитель начал жулить и врать про тип записи и скорость вращения. Но быстро одумался и вроде бы больше эта история не повторялась.
Эти диски можно брать б.у., если продавец демонстрирует SMART продаваемого диска.
#железо
На картинке выше пример одного сервера под бэкапы, где стоят эти диски. У некоторых наработка 13+ лет. Один из таких начал сыпать в мониторинг Current_Pending_Sector. 14 штук уже набралось, решил поменять его, заодно посмотрел статистику остальных дисков. Они там собраны в RAID6. Самые старые диски уже 2 переезда на новое железо пережили. Менялась платформа, а диски оставались. Рейд, собранный в mdadm, спокойно переезжает на новое железо. Просто переносишь диски и инициализируешь массив. Mdadm видит собранный массив на старых дисках и просто запускает его. Все разделы, данные, сохраняются.
В целом, это типичная картинка для этих дисков. Они чаще всего работают долго, стабильно, надёжно. Если проблемы возникают, то в смарте они как правило тоже присутствуют. Не припоминаю, чтобы хоть раз подобный диск отработал меньше 3-4 лет. Вроде было разок, но тогда ещё работал их сервисный центр, гарантийный диск менялся без вопросов на новый. Можно было курьером отправить. А гарантия была вроде бы 5 лет. Сейчас, к сожалению, такой гарантии производителя уже нет, только от магазина 1-2 года. Там уже как повезёт с заменой.
Единственное, на что обращаю внимание - это чтобы тип записи точно был CMR, а не SMR. Был один момент с этими дисками, когда производитель начал жулить и врать про тип записи и скорость вращения. Но быстро одумался и вроде бы больше эта история не повторялась.
Эти диски можно брать б.у., если продавец демонстрирует SMART продаваемого диска.
#железо
👍78👎7
Когда выбирают серверы, обычно сравнивают железо: ядра, память, диски, цена за стойку. Инструменты управления уходят на второй план — и зря. Именно они определяют, сколько часов админ потратит на обслуживание в ближайшие 3–5 лет.
Спешим поделиться их отличиями в:ℹ️ Прошивках и BIOSℹ️ Телеметрии и интеграцииℹ️ Конфигах и масштабахℹ️ Безопасности
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJ7Xv4q
Please open Telegram to view this post
VIEW IN TELEGRAM
1👎10👍7
Размышлял тут на днях над судьбой сайта и статей на нём. Наткнулся на любопытный комментарий. Не припоминаю, чтобы он раньше привлекал моё внимание. Странно, что пропустил. Как вам такое мыслеизливание:
По-моему любой роутер после сброса настроек на заводские теряет в том числе и сетевые настройки. Это как бы база. Неужели в Зухеле по-другому?
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#юмор #mikrotik
Капец, по вашей инструкции сбросил настройки на заводские и всё пинги не получаю от маршрутизатора! Спасибо за отличную статью и микротик говно для задротов с хвостиками, заваленными джинсами с кучей корманов и пивными животами! Маршрутизатор не советую, берите zyxel с keenetic os! Всё для людей сделано!
По-моему любой роутер после сброса настроек на заводские теряет в том числе и сетевые настройки. Это как бы база. Неужели в Зухеле по-другому?
———
ServerAdmin:
#юмор #mikrotik
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍121👎4
🔝 ТОП постов за прошедший месяц июнь. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.
В этот раз в топ по реакциям (отрицательным) попала рекламная публикация. Это вообще первый раз за всю историю ведения канала (9 лет). Обычно рекламу проматывают и не реагируют на неё. Для тех, кто не совсем понимает эту кухню немного поясню, как на деле выглядит публикация рекламы.
Крупных брендов чаще всего представляют рекламные агентства. С ними в обязательном порядке заключается договор. Некоторые договора на несколько публикаций в течении нескольких месяцев. Иногда договор действует до полугода. У меня есть определённые требования к тексту рекламы, чтобы она выглядела нормально, но всё не учесть. Иногда бывают перфомансы, которые маркетологи считают заслуживающими внимания. Просто так отказаться от публикации нельзя.
Я всех рекламодателей и рекламу пропускаю через свой фильтр. Публикую только то, что строго соответствует тематике канала и может быть интересным, полезным. Всё нетематическое я отсекаю.
📌 Больше всего пересылок:
◽️5 полезных настроек Proxmox (323)
◽️PatchMon для контроля за обновлениями (225)
◽️Обновление сертификатов Microsoft в UEFI (218)
◽️Обновление BIOS в Supermicro (213)
📌 Больше всего комментариев:
◽️Реалии найма в IT (292)
◽️Let's Encrypt следует ссанкциям США (166)
◽️Переезд серверной и отказ оборудования (97)
◽️ExplorerPatcher для Windows 11 (88)
📌 Больше всего реакций:
◽️Проблемы с запуском KeePass (221)
◽️Помехи с сигналом в Ethernet от наводок 380В (216)
◽️Обновление BIOS в Supermicro (205)
📌 Больше всего просмотров:
◽️Прикол в настройке Asterisk (10260)
◽️Let's Encrypt следует ссанкциям США (10135)
◽️Настройка Fwknop (9115)
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#топ
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.
В этот раз в топ по реакциям (отрицательным) попала рекламная публикация. Это вообще первый раз за всю историю ведения канала (9 лет). Обычно рекламу проматывают и не реагируют на неё. Для тех, кто не совсем понимает эту кухню немного поясню, как на деле выглядит публикация рекламы.
Крупных брендов чаще всего представляют рекламные агентства. С ними в обязательном порядке заключается договор. Некоторые договора на несколько публикаций в течении нескольких месяцев. Иногда договор действует до полугода. У меня есть определённые требования к тексту рекламы, чтобы она выглядела нормально, но всё не учесть. Иногда бывают перфомансы, которые маркетологи считают заслуживающими внимания. Просто так отказаться от публикации нельзя.
Я всех рекламодателей и рекламу пропускаю через свой фильтр. Публикую только то, что строго соответствует тематике канала и может быть интересным, полезным. Всё нетематическое я отсекаю.
📌 Больше всего пересылок:
◽️5 полезных настроек Proxmox (323)
◽️PatchMon для контроля за обновлениями (225)
◽️Обновление сертификатов Microsoft в UEFI (218)
◽️Обновление BIOS в Supermicro (213)
📌 Больше всего комментариев:
◽️Реалии найма в IT (292)
◽️Let's Encrypt следует ссанкциям США (166)
◽️Переезд серверной и отказ оборудования (97)
◽️ExplorerPatcher для Windows 11 (88)
📌 Больше всего реакций:
◽️Проблемы с запуском KeePass (221)
◽️Помехи с сигналом в Ethernet от наводок 380В (216)
◽️Обновление BIOS в Supermicro (205)
📌 Больше всего просмотров:
◽️Прикол в настройке Asterisk (10260)
◽️Let's Encrypt следует ссанкциям США (10135)
◽️Настройка Fwknop (9115)
———
ServerAdmin:
#топ
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
🎄🔝 Под конец года имеет смысл подвести некоторые итоги. В повседневной жизни я не привык это делать. Обычно только доходы/расходы анализирую. А вот в разрезе канала было интересно посмотреть итоги.
Я подготовил ТОП публикаций за прошедший год. Это было…
Я подготовил ТОП публикаций за прошедший год. Это было…
1👍40👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Kuber Community Day возвращается
30 июля в Москве все неравнодушные к технологии встречаются на инженерной конференции Kuber Community Day.
На сцене выступят практики из Ænix, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Почтатех», «Инфосистемы Джет», Hilbert Team и других компаний.
Что вас ждет:
◾️доклады без маркетинга: 30 спикеров расскажут об использовании ИИ в Kubernetes, мониторинге контейнеров, обзоре инструментов экосистемы, получении сертификаций и пр.;
◾️мастер-класс по созданию Kubernetes-оператора: в конце все участники задеплоят его в кластер Yandex Managed Kubernetes;
◾️arch dating: короткие встречи с опытными специалистами, где можно обсудить технические и карьерные вопросы;
◾️научпоп: рассказ о кибернетическом подходе к управлению сложностью от Александра Нозика, директора центра научного программирования.
Форматы: офлайн и онлайн.
Участие бесплатное, регистрация обязательна.
30 июля в Москве все неравнодушные к технологии встречаются на инженерной конференции Kuber Community Day.
На сцене выступят практики из Ænix, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Почтатех», «Инфосистемы Джет», Hilbert Team и других компаний.
Что вас ждет:
◾️доклады без маркетинга: 30 спикеров расскажут об использовании ИИ в Kubernetes, мониторинге контейнеров, обзоре инструментов экосистемы, получении сертификаций и пр.;
◾️мастер-класс по созданию Kubernetes-оператора: в конце все участники задеплоят его в кластер Yandex Managed Kubernetes;
◾️arch dating: короткие встречи с опытными специалистами, где можно обсудить технические и карьерные вопросы;
◾️научпоп: рассказ о кибернетическом подходе к управлению сложностью от Александра Нозика, директора центра научного программирования.
Форматы: офлайн и онлайн.
Участие бесплатное, регистрация обязательна.
👍8👎1
У меня основной инструмент взаимодействия с ИИ - агент OpenCode. Мне в целом привычна и удобна работа в консоли, особенно для решения конкретных прикладных задач. Я тут же могу проверить решение - запустить, подключиться к другому серверу и т.д. Но иногда не хватает веб интерфейса для некоторых задач. У opencode есть свой встроенный веб интерфейс, но он мне совершенно не понравился. Неудобный.
Не так давно я смотрел обзор агента Coddy от автора. Мне он показался интересным, запомнил. И вот дошли руки попробовать. Сразу скажу, что он мне понравился и я оставил его себе для работы. К сожалению, у меня нет возможности пользоваться и сравнивать разные агенты, коих сейчас выходит очень много. В Coddy просто есть сразу всё, что лично мне нужно.
Что понравилось в Coddy и что он умеет:
▪️Простой инструмент из одного бинарника, конфига и папок со скилами, сессиями, кроном и т.д. Его легко запускать, переносить, обновлять.
▪️Три режима работы: ACP (взаимодействие агентов), HTTP (работаете в браузере), Gateway (взаимодействие через Telegram или другой мессенджер). Все три режима используют единое хранилище сессий. Например, в браузере можно посмотреть, что вы делали в других сессиях.
▪️Куча основных инструментов уже встроены: чтение файлов, запуск команд, ssh соединения, поиск через поисковики, анализ сайтов и т.д.
▪️Простой и лаконичный веб интерфейс. Ничего лишнего.
▪️Можно подключать все популярные llm, в том числе локальные.
▪️Нормально работает с локальными моделями, так как по умолчанию почти не расходует контекст на свою работу.
▪️Вся функциональная современная база есть: rules, sheduler, skills, mcp, long-term memory между сессиями или глобальная.
- По умолчанию всегда спрашивает, прежде чем что-то выполнять.
Что не понравилось:
◽️Не показывает статистику по генерации ответа. Не видно, какая была скорость генерации токенов для локальных моделей.
◽️Добавлять настройки через веб интерфейс неудобно.
◽️Результат работы планировщика можно посмотреть только в консоли, либо я не понял, где и как искать результаты работы в веб интерфейсе.
◽️Запросы на выполнение той или иной команды иногда почему-то выводятся где-то вверху в чате, хотя сам чат уже уехал вниз. Похоже на какой-то баг.
В общем, мне этот агент показался удобным, чтобы в одном месте собрать всю работу с llm. Поставил coddy на постоянку, буду использовать вместе с opencode, первого для работы в браузере, второго - в консоли.
На картинках мои примеры работы с локальной моделькой omnicoder-9b. Я её долго мучал. Она шустро у меня работает и не сказать, что сильно тупая. Если аккуратно подойти к настройке, то многие админские задачи сможет выполнять. Например, проверять регулярно какие-то логи с хостов и формировать отчёт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#ai
Не так давно я смотрел обзор агента Coddy от автора. Мне он показался интересным, запомнил. И вот дошли руки попробовать. Сразу скажу, что он мне понравился и я оставил его себе для работы. К сожалению, у меня нет возможности пользоваться и сравнивать разные агенты, коих сейчас выходит очень много. В Coddy просто есть сразу всё, что лично мне нужно.
Что понравилось в Coddy и что он умеет:
▪️Простой инструмент из одного бинарника, конфига и папок со скилами, сессиями, кроном и т.д. Его легко запускать, переносить, обновлять.
▪️Три режима работы: ACP (взаимодействие агентов), HTTP (работаете в браузере), Gateway (взаимодействие через Telegram или другой мессенджер). Все три режима используют единое хранилище сессий. Например, в браузере можно посмотреть, что вы делали в других сессиях.
▪️Куча основных инструментов уже встроены: чтение файлов, запуск команд, ssh соединения, поиск через поисковики, анализ сайтов и т.д.
▪️Простой и лаконичный веб интерфейс. Ничего лишнего.
▪️Можно подключать все популярные llm, в том числе локальные.
▪️Нормально работает с локальными моделями, так как по умолчанию почти не расходует контекст на свою работу.
▪️Вся функциональная современная база есть: rules, sheduler, skills, mcp, long-term memory между сессиями или глобальная.
- По умолчанию всегда спрашивает, прежде чем что-то выполнять.
Что не понравилось:
◽️Не показывает статистику по генерации ответа. Не видно, какая была скорость генерации токенов для локальных моделей.
◽️Добавлять настройки через веб интерфейс неудобно.
◽️Результат работы планировщика можно посмотреть только в консоли, либо я не понял, где и как искать результаты работы в веб интерфейсе.
◽️Запросы на выполнение той или иной команды иногда почему-то выводятся где-то вверху в чате, хотя сам чат уже уехал вниз. Похоже на какой-то баг.
В общем, мне этот агент показался удобным, чтобы в одном месте собрать всю работу с llm. Поставил coddy на постоянку, буду использовать вместе с opencode, первого для работы в браузере, второго - в консоли.
На картинках мои примеры работы с локальной моделькой omnicoder-9b. Я её долго мучал. Она шустро у меня работает и не сказать, что сильно тупая. Если аккуратно подойти к настройке, то многие админские задачи сможет выполнять. Например, проверять регулярно какие-то логи с хостов и формировать отчёт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍64👎5
Небольшой практический совет для тех, кто собирает или планирует собирать логи Docker контейнеров в Loki. У меня был подробный цикл заметок по этой теме:
1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них
4️⃣ Сбор журналов Windows.
5️⃣ Приём логов Syslog с помощью Vector
6️⃣ Отключение сбора статистки в Alloy
Также есть общая статья со всеми этими темами. Мне нравится эта система. Я её сейчас постоянно использую. Скорее всего больше не буду настраивать ELK, так как для моих задач мне Loki хватает, хотя она и менее функциональная, но проще в настройке и меньше требует ресурсов.
Во время изучения Loki собирал логи с помощью встроенного плагина докер - grafana/loki-docker-driver. Он удобен в первую очередь тем, что можно в каждом конкретном контейнере указать, что логи отправляются в Loki. Примерно так:
Благодаря этому можно выбирать, какой контейнер и куда отправляет логи. Если вам нужны логи только от одного контейнера, а у вас их крутится 10, то этот драйвер будет в самый раз.
Но у такого подхода есть существенные минусы, с которыми я столкнулся:
1️⃣ Сам по себе драйвер - отдельная сущность. И если в нём будут ошибки, то у вас не запустятся контейнеры, которые от него зависят. И я эти ошибки ловил. Не всегда и не везде, но иногда было так, что этот драйвер по какой-то причине не запускался. Причём быстро выяснить причину не удавалось. Просто не запускался автоматически loki.sock после перезагрузки хоста. Лечилось ручным запуском. Причина была не в том, что Loki недоступен.
2️⃣ За плагином надо отдельно следить и обновлять. Причём обновление требует перезапуска самой службы Docker со всеми вытекающими последствиями в виде остановки или перезапуска контейнеров в зависимости от их настроек. Это если у вас не включен параметр live-restore. С ним контейнеры не будут перезапускаться вместе со службой. По умолчанию этот параметр не активен. С ним есть свои нюансы.
Для более надёжной и стабильной работы логи докера лучше вынести в текстовый файл и забирать сборщиком логов, который вы обычно используете. Он и так скорее всего будет установлен для сбора системных логов, так что добавить в него сбор ещё одного текстового лога будет не очень накладно. А если нужно фильтровать контейнеры, для которых нужен сбор логов, можно в них добавлять отдельную метку для этого. Тот же Alloy без проблем отфильтрует контейнеры по этой метке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#docker #logs #loki #совет
Также есть общая статья со всеми этими темами. Мне нравится эта система. Я её сейчас постоянно использую. Скорее всего больше не буду настраивать ELK, так как для моих задач мне Loki хватает, хотя она и менее функциональная, но проще в настройке и меньше требует ресурсов.
Во время изучения Loki собирал логи с помощью встроенного плагина докер - grafana/loki-docker-driver. Он удобен в первую очередь тем, что можно в каждом конкретном контейнере указать, что логи отправляются в Loki. Примерно так:
logging: driver: loki options: loki-url: "http://192.168.137.30:3100/loki/api/v1/push" loki-retries: 2 loki-max-backoff: 800ms loki-timeout: 1s keep-file: "true" mode: "non-blocking"Благодаря этому можно выбирать, какой контейнер и куда отправляет логи. Если вам нужны логи только от одного контейнера, а у вас их крутится 10, то этот драйвер будет в самый раз.
Но у такого подхода есть существенные минусы, с которыми я столкнулся:
Для более надёжной и стабильной работы логи докера лучше вынести в текстовый файл и забирать сборщиком логов, который вы обычно используете. Он и так скорее всего будет установлен для сбора системных логов, так что добавить в него сбор ещё одного текстового лога будет не очень накладно. А если нужно фильтровать контейнеры, для которых нужен сбор логов, можно в них добавлять отдельную метку для этого. Тот же Alloy без проблем отфильтрует контейнеры по этой метке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#docker #logs #loki #совет
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство…
1👍56👎1
Синхронизация двух разнесённых хранилищ с файлами - нетривиальная задача, особенно если они состоят из десятков и сотен тысяч файлов. Сделать копию данных и регулярно синхронизировать - полдела. Нужно ещё как-то их сравнивать, чтобы убедиться в том, что данные в обоих местах идентичны. Мало того, что при передаче данные могут повредиться, так они ещё и со временем могут протухать из-за bit rot (битовое гниение на хранилищах) или silent corruption (повреждения из-за памяти, контроллеров, неисправных кабелей и т.д.)
С bit rot я лично сталкивался, так что это не гипотетическая ситуация. Хотя в моём случае это не приводило к каким-то проблемам, так как протухали очень старые данные, которые по сути никому уже и не нужны, а хранятся просто так, на всякий случай. Но где-то это может быть критично.
По моему опыту хранилища на несколько терабайт данных с сотнями тысяч файлов быстрее всего синхронизировать с помощью rsync. Я так обычно и делаю. У меня много заметок на этот счёт в канале. Особенность rsync в том, что он умеет быстро сравнивать хранилища и находить только изменившиеся файлы, учитывая размер файла и mtime. На основе этих данных формирует список разнящихся файлов и копирует только их.
Такой подход не страхует от повреждения файлов во время передачи. Хотя сетевые протоколы содержат собственные механизмы контроля целостности, файлы могут повредиться, например, из-за неисправной памяти, контроллеров или других аппаратных сбоев. Даже если ваше хранилище защищено от bit rot, гарантировать поступление точной копии файла оно не может. Нужны дополнительные проверки.
Rsync, как и некоторые другие подобные программы, могут сверять контрольные суммы файлов. Но это очень длительный процесс, если хранилище большое. В момент передачи данных делать это нецелесообразно. Процесс может растянуться на дни. Не так давно я в локальной сети сравнил два хранилища объёмом в 1ТБ, где хранятся ~100 тыс. файлов. У меня процесс длился в районе 20-ти часов.
Подсчитывать контрольные суммы для сравнения логичнее локально и отдельно от передачи, разнеся эти процессы по времени. Если синхронизация выполняется раз в день, то сравнение можно делать раз в неделю/месяц. Для этого есть много различных программ. Я недавно увидел анонс одной из них - precizer, поэтому и решил написать об этой теме. Ранее мне был знаком скрипт bitrot, который делает примерно то же самое, но не так изящно.
Precizer для максимального быстродействия написана на чистом Си, компилируется в одиночный бинарник, проста в использовании. Производительность в основном зависит от работы дисковой подсистемы, так как файлы приходится полностью читать. Обычно это узкое место. Результаты анализа файлов хранит в SQLite. Если её прервать, а потом запустить снова, она продолжит работу, не потеряв всё то, что сделала ранее. Это отличный инструмент для фоновой проверки хранилищ по расписанию.
Работает примерно так:
В базах share1.db и share2.db хранится относительный путь файла, его хэш SHA512 и метаданные (размер, ctime и mtime). Последующие запуски для обновления базы выполняются с ключом
Решений подобной задачи может быть несколько. Передача и сравнение файлов - только одно из них. Можно передавать снепшоты файловых систем, или систем хранения, если они это поддерживают. Например, снепшоты zfs или lvm и потом их сравнивать. Можно хранить данные в формате чанков, как это делает, к примеру, restic или borg и делать проверки на уровне чанков. Итоговое решение нужно выбирать по месту в зависимости от того, какая архитектура хранения и бэкапов используется. Уровень файлов имеет свои недостатки, но удобен, так как вы в случае чего сразу имеете живую копию данных, которую сможете использовать без преобразования или каких-то ещё дополнительных действий.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#backup
С bit rot я лично сталкивался, так что это не гипотетическая ситуация. Хотя в моём случае это не приводило к каким-то проблемам, так как протухали очень старые данные, которые по сути никому уже и не нужны, а хранятся просто так, на всякий случай. Но где-то это может быть критично.
По моему опыту хранилища на несколько терабайт данных с сотнями тысяч файлов быстрее всего синхронизировать с помощью rsync. Я так обычно и делаю. У меня много заметок на этот счёт в канале. Особенность rsync в том, что он умеет быстро сравнивать хранилища и находить только изменившиеся файлы, учитывая размер файла и mtime. На основе этих данных формирует список разнящихся файлов и копирует только их.
Такой подход не страхует от повреждения файлов во время передачи. Хотя сетевые протоколы содержат собственные механизмы контроля целостности, файлы могут повредиться, например, из-за неисправной памяти, контроллеров или других аппаратных сбоев. Даже если ваше хранилище защищено от bit rot, гарантировать поступление точной копии файла оно не может. Нужны дополнительные проверки.
Rsync, как и некоторые другие подобные программы, могут сверять контрольные суммы файлов. Но это очень длительный процесс, если хранилище большое. В момент передачи данных делать это нецелесообразно. Процесс может растянуться на дни. Не так давно я в локальной сети сравнил два хранилища объёмом в 1ТБ, где хранятся ~100 тыс. файлов. У меня процесс длился в районе 20-ти часов.
Подсчитывать контрольные суммы для сравнения логичнее локально и отдельно от передачи, разнеся эти процессы по времени. Если синхронизация выполняется раз в день, то сравнение можно делать раз в неделю/месяц. Для этого есть много различных программ. Я недавно увидел анонс одной из них - precizer, поэтому и решил написать об этой теме. Ранее мне был знаком скрипт bitrot, который делает примерно то же самое, но не так изящно.
Precizer для максимального быстродействия написана на чистом Си, компилируется в одиночный бинарник, проста в использовании. Производительность в основном зависит от работы дисковой подсистемы, так как файлы приходится полностью читать. Обычно это узкое место. Результаты анализа файлов хранит в SQLite. Если её прервать, а потом запустить снова, она продолжит работу, не потеряв всё то, что сделала ранее. Это отличный инструмент для фоновой проверки хранилищ по расписанию.
Работает примерно так:
# precizer --progress --database=share1.db /mnt/share1# precizer --progress --database=share2.db /mnt/share2# precizer --compare share1.db share2.dbВ базах share1.db и share2.db хранится относительный путь файла, его хэш SHA512 и метаданные (размер, ctime и mtime). Последующие запуски для обновления базы выполняются с ключом
--update, чтобы заново не пересчитывать хэши к неизменившимся файлам. Решений подобной задачи может быть несколько. Передача и сравнение файлов - только одно из них. Можно передавать снепшоты файловых систем, или систем хранения, если они это поддерживают. Например, снепшоты zfs или lvm и потом их сравнивать. Можно хранить данные в формате чанков, как это делает, к примеру, restic или borg и делать проверки на уровне чанков. Итоговое решение нужно выбирать по месту в зависимости от того, какая архитектура хранения и бэкапов используется. Уровень файлов имеет свои недостатки, но удобен, так как вы в случае чего сразу имеете живую копию данных, которую сможете использовать без преобразования или каких-то ещё дополнительных действий.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому…
1👍71👎2