ServerAdmin.ru
Open in Telegram
Авторская информация о системном администрировании. Информация о рекламе: @srv_admin_reklama_bot Автор: @zeroxzed Второй канал: @srv_admin_live Сайт: serveradmin.ru Ресурс включён в перечень Роскомнадзора
Show more📈 Analytical overview of Telegram channel ServerAdmin.ru
Channel ServerAdmin.ru (@srv_admin) in the Russian language segment is an active participant. Currently, the community unites 32 353 subscribers, ranking 4 145 in the Technologies & Applications category and 19 963 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 32 353 subscribers.
According to the latest data from 12 July, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 45 over the last 30 days and by -4 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 22.60%. Within the first 24 hours after publication, content typically collects 12.75% reactions from the total number of subscribers.
- Post reach: On average, each post receives 7 310 views. Within the first day, a publication typically gains 4 124 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 70.
- Thematic interests: Content is focused on key topics such as linux, docker, мониторинг, контейнер, serveradmin.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Авторская информация о системном администрировании.
Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed
Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Ресурс включён в перечень Роскомнадзора”
Thanks to the high frequency of updates (latest data received on 13 July, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
32 353
Subscribers
-424 hours
+37 days
+4530 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
July '26
July '26
+98
in 0 channels
June '26
+298
in 1 channels
Get PRO
May '26
+400
in 1 channels
Get PRO
April '26
+311
in 2 channels
Get PRO
March '26
+472
in 4 channels
Get PRO
February '26
+367
in 0 channels
Get PRO
January '26
+312
in 0 channels
Get PRO
December '25
+251
in 0 channels
Get PRO
November '25
+320
in 1 channels
Get PRO
October '25
+316
in 2 channels
Get PRO
September '25
+265
in 2 channels
Get PRO
August '25
+333
in 2 channels
Get PRO
July '25
+366
in 1 channels
Get PRO
June '25
+465
in 1 channels
Get PRO
May '25
+531
in 2 channels
Get PRO
April '25
+513
in 0 channels
Get PRO
March '25
+456
in 2 channels
Get PRO
February '25
+478
in 1 channels
Get PRO
January '25
+644
in 5 channels
Get PRO
December '24
+548
in 0 channels
Get PRO
November '24
+547
in 0 channels
Get PRO
October '24
+710
in 1 channels
Get PRO
September '24
+688
in 2 channels
Get PRO
August '24
+624
in 0 channels
Get PRO
July '24
+496
in 1 channels
Get PRO
June '24
+508
in 1 channels
Get PRO
May '24
+572
in 2 channels
Get PRO
April '24
+590
in 0 channels
Get PRO
March '24
+759
in 3 channels
Get PRO
February '24
+746
in 2 channels
Get PRO
January '24
+697
in 0 channels
Get PRO
December '23
+940
in 7 channels
Get PRO
November '23
+416
in 1 channels
Get PRO
October '23
+1 760
in 2 channels
Get PRO
September '23
+626
in 0 channels
Get PRO
August '23
+1 119
in 0 channels
Get PRO
July '23
+506
in 0 channels
Get PRO
June '23
+507
in 0 channels
Get PRO
May '23
+455
in 0 channels
Get PRO
April '23
+483
in 0 channels
Get PRO
March '23
+802
in 0 channels
Get PRO
February '23
+390
in 0 channels
Get PRO
January '23
+519
in 0 channels
Get PRO
December '22
+432
in 0 channels
Get PRO
November '22
+422
in 0 channels
Get PRO
October '22
+432
in 0 channels
Get PRO
September '22
+482
in 0 channels
Get PRO
August '22
+449
in 0 channels
Get PRO
July '22
+353
in 0 channels
Get PRO
June '22
+400
in 0 channels
Get PRO
May '22
+475
in 0 channels
Get PRO
April '22
+485
in 0 channels
Get PRO
March '22
+956
in 0 channels
Get PRO
February '22
+443
in 0 channels
Get PRO
January '22
+372
in 0 channels
Get PRO
December '21
+560
in 0 channels
Get PRO
November '21
+589
in 0 channels
Get PRO
October '21
+433
in 0 channels
Get PRO
September '21
+610
in 0 channels
Get PRO
August '21
+632
in 0 channels
Get PRO
July '21
+456
in 0 channels
Get PRO
June '21
+815
in 0 channels
Get PRO
May '21
+545
in 0 channels
Get PRO
April '21
+528
in 0 channels
Get PRO
March '21
+630
in 0 channels
Get PRO
February '21
+784
in 0 channels
Get PRO
January '21
+747
in 0 channels
Get PRO
December '20
+6 161
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 13 July | +8 | |||
| 12 July | +10 | |||
| 11 July | +7 | |||
| 10 July | +6 | |||
| 09 July | +7 | |||
| 08 July | +7 | |||
| 07 July | +5 | |||
| 06 July | +4 | |||
| 05 July | +14 | |||
| 04 July | +4 | |||
| 03 July | +10 | |||
| 02 July | +8 | |||
| 01 July | +8 |
Channel Posts
Вернулся из небольшого отпуска. Последняя публикация была на эту тему не просто так. На прошлой неделе скомканное расписание получилось, потому что пришлось заранее всё в планировщик добавить в более сжатом формате. Когда постоянно работаешь, привыкаешь. И если работа тебе не ненавистна, то в целом всё нормально. А вот после отпуска вкатываться в рабочий график - прям мучение. Иногда кажется, что лучше совсем не ходить в него, чтобы потом не приходилось привыкать обратно.
Для разгона решил закончить свою старую тему с ИБП, так как лично для меня она получилась поучительной. Напомню, для тех, кто не читал прошлую публикацию. Я подключил сервер, у которого блок питания с Active PFC к линейно-интерактивному ИБП. В итоге при переходе на батареи сервер аварийно выключался и не мог стартовать при работе от батарей, уходил в циклическую перезагрузку.
Существуют разные мнения на этот счёт. Насколько я понял проблему, суть там вот в чём. В линейно-интерактивном ИБП при переходе на питание от батарей происходит кратковременное снижение и в моменте пропадание напряжения, на которое БП с APFC реагирует резким повышением потребляемого тока. И если в ИБП нет достаточного запаса по мощности, либо если переключение чуть увеличено от базовых значений, он выключается. Это основная причина проблем, а не плохой синус, как считал я, и как писали некоторые люди, а так же ИИ.
Пришёл именно к этому мнению, потому что видел довольно много отзывов, когда у людей сервера нормально работали от линейно-интерактивных ИБП. Думаю, что там либо запаса по мощности хватало, либо БП не так активно увеличивали ток из-за более кратковременного перехода, поэтому и не происходило отключение. Но в любом случае однозначная рекомендация - сервера с APFC должны быть запитаны от онлайн ИБП.
Я в итоге и купил (за 13700 р.) один из таких, практически самый дешёвый - FinePower MIX ONLINE 1000VA, он же DEXP MIX ONLINE 1000VA. Он же и под другими брендами продаётся, но внешний вид у них у всех один и тот же. Я его уже настроил, протестировал. Работает нормально. Выбрал именно его, потому что дешёвый, и потому что не увидел каких-то явно плохих отзывов. В целом у всех он работает нормально. Проблема лично у меня возникла с софтом под Linux. У меня не получилось его завести, хотя я видел отзывы, когда у людей получалось. В зависимости от бренда, под которым он продаётся, у него может быть разная прошивка и протокол обмена данными. У меня ни через NUT, ни через его родной софт под Linux, он не заработал.
Немного помучался и завёл всё через виртуальную машину на винде. У меня он всё равно к гипервизору подключен. Там софт нормально работает. Он тушит по SSH гипервизор. Мою супермикру этот ИБП держит в районе 15-20 минут. Если верить его дисплею, то нагрузка обычно ~150Вт. Для моих задач этого ИБП достаточно. Рекомендовать его не буду из-за кривого софта, но за эти деньги другой не купить. Плюс, он шумит вентилятором, но мне не критично, так как стоит в нежилом помещении. Если бы не этот вентилятор, то был бы отличный вариант для домашнего онлайн ИБП для компьютера под виндой.
В итоге сервер работает от этого онлайн ИБП, а остальные компьютеры - от линейно-интерактивных. И всё в порядке. То есть проблемы в явном виде с этим ИБП не было. Он просто не совместим с конкретным сервером, как и большинство его собратьев такого же типа.
———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#железо
| 2 |  Смотрю иногда ютуб канал Будни сантехника. Не знаю зачем, просто нравится. Кое-что полезное узнал - как правильно наматывать фум ленту и сантехническую нить, как канализацию правильно делать и т.д. Живущим в частном доме эта информация не лишняя, особенно если у них всё на полипропилене 😁.
Так вот, послушал выступление этого сантехника на слёте сантехников (прикиньте, такие тоже бывают). Он там рассказал забавную вещь. Автор называет себя настоящим фанатом своего дела и рассказывает, как приезжая на отдых, он уже на второй день смотрит, как у него радиатор подключен в номере, заглядывает в ревизионные люки, проверяет кондиционер и т.д. Постоянно думает о своей работе и делах - как что улучшить, общается в чатах и т.д. Сделал себе мастерскую, краны там крутит, тестирует.
Послушал выступление и увидел в этом сантехнике себя, который тоже не умеет толком отдыхать. Сделал себе дома серверную, чтобы как на работе, где всё шумит, гудит и греется, со стеллажами и комплектующими. Во всяких местах если подключаюсь к Wifi, смотрю маршруты, на каком железе настроено, кто ещё есть в сети, что и как заблокировано и т.д. Отдыхать уже не умею. Он на этом сделал акцент, что надо заставлять себя отдыхать, потому что это важно.
Я давно знаю эту свою проблему. Разучился отдыхать. Надо заново учиться. Всё время в делах, заботах, что-то делаю, придумываю, планирую и т.д. Это не сказать, что плохо, но уже крайность, от которой надо уходить обратно в сторону нормы. Как минимум для сохранения здоровья. Часто ночами засиживаюсь, настраивая что-то в своей серверной. Прикиньте, каким надо быть фанатом, чтобы весь день настраивать сервера на работе, а перед сном - у себя дома.
Если вы такой же фанат-трудоголик, как этот сантехник и я, то писните что-нибудь интересное на эту тему в комменты. Я для забавы снизу прикрепил картинку, как я как-то раз зашёл на сайт, вроде бы мебельного магазина, и увидел протухшый сертификат. Не смог пройти мимо.
———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#мысли | 6 909 |
| 3 |  Знаете ли вы, как устроены сетевые балансировщики нагрузки?
За термином «отказоустойчивость» на деле стоит сложная архитектура, определяющая, устоит ли приложение под наплывом пользователей. Чтобы разобраться в этих механизмах, приглашаем вас в реалити-проект для разработчиков «Создавая облако»: выпуск, посвящённый балансировщикам.
Вы узнаете:
● какие задачи решает балансировщик и как они влияют на его архитектуру;
● как балансировщик интегрирован с overlay-сетью и какие компоненты участвуют в обработке трафика;
● какие концепции Google Maglev мы взяли за основу при разработке собственного алгоритма распределения запросов;
● как работают внешний и внутренний балансировщики, включая health-checks и обработку трафика.
А что на практике? Приходите посмотреть, что у нас получилось: регистрируйтесь в облаке MWS Cloud Platform и попробуйте превью-версию нового балансировщика, мы как раз только что её запустили.
Попробовать балансировщик в MWS Cloud Platform | 6 992 |
| 4 | Синхронизация двух разнесённых хранилищ с файлами - нетривиальная задача, особенно если они состоят из десятков и сотен тысяч файлов. Сделать копию данных и регулярно синхронизировать - полдела. Нужно ещё как-то их сравнивать, чтобы убедиться в том, что данные в обоих местах идентичны. Мало того, что при передаче данные могут повредиться, так они ещё и со временем могут протухать из-за bit rot (битовое гниение на хранилищах) или silent corruption (повреждения из-за памяти, контроллеров, неисправных кабелей и т.д.)
С 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: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#backup | 6 178 |
| 5 |  Где этой осенью будут обсуждать ИТ не в теории, а по-настоящему?
На IT Elements 2026 — конференции для инженеров, архитекторов, безопасников и руководителей технических команд, которые отвечают за устойчивость критических ИТ-систем бизнеса.
Здесь не пересказывают тренды и не показывают “идеальные схемы”. Здесь разбирают, как в реальности строят инфраструктуру, мигрируют с иностранных решений, защищают системы, восстанавливают сервисы после инцидентов и обеспечивают работу ИТ под нагрузкой.
Что ждет участников:
📌 реальные инженерные кейсы из крупных компаний;
📌 лаборатории, технические воркшопы и практические разборы;
📌 дискуссии про отказоустойчивость, безопасность и эксплуатацию;
📌 общение с инженерами, архитекторами и ИТ/ИБ-руководителями.
Формат: офлайн в Москве и онлайн.
Участие бесплатное.
Регистрация уже открыта — оставляйте заявку на сайте конференции. | 4 888 |
| 6 | Небольшой практический совет для тех, кто собирает или планирует собирать логи 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. Примерно так:
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, то этот драйвер будет в самый раз.
Но у такого подхода есть существенные минусы, с которыми я столкнулся:
1️⃣ Сам по себе драйвер - отдельная сущность. И если в нём будут ошибки, то у вас не запустятся контейнеры, которые от него зависят. И я эти ошибки ловил. Не всегда и не везде, но иногда было так, что этот драйвер по какой-то причине не запускался. Причём быстро выяснить причину не удавалось. Просто не запускался автоматически loki.sock после перезагрузки хоста. Лечилось ручным запуском. Причина была не в том, что Loki недоступен.
2️⃣ За плагином надо отдельно следить и обновлять. Причём обновление требует перезапуска самой службы Docker со всеми вытекающими последствиями в виде остановки или перезапуска контейнеров в зависимости от их настроек. Это если у вас не включен параметр live-restore. С ним контейнеры не будут перезапускаться вместе со службой. По умолчанию этот параметр не активен. С ним есть свои нюансы.
Для более надёжной и стабильной работы логи докера лучше вынести в текстовый файл и забирать сборщиком логов, который вы обычно используете. Он и так скорее всего будет установлен для сбора системных логов, так что добавить в него сбор ещё одного текстового лога будет не очень накладно. А если нужно фильтровать контейнеры, для которых нужен сбор логов, можно в них добавлять отдельную метку для этого. Тот же Alloy без проблем отфильтрует контейнеры по этой метке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#docker #logs #loki #совет | 5 228 |
| 7 |  Десять CLI, SDK и Terraform-провайдеров — из одной OpenAPI-спецификации?
21 июля в 17:00 в новом выпуске реалити-проекта «Создавая облако» от MWS Cloud Platform технический руководитель платформы Дмитрий Новиков покажет, как устроена внутренняя кухня автоматизации облака.
Что будет в эфире:
• тотальный dogfooding: почему внутренние команды работают теми же инструментами, что и клиенты;
• как устроен декларативный API: манифест → reconcile → desired state;
• пять инструментов автоматизации — UI, CLI, Terraform, Golang SDK и Packer, — зачем нужен каждый;
• как один кодогенератор из единой спецификации кормит десять артефактов;
• почему Packer остаётся осознанным исключением и пишется руками.
Выпуск будет интересен backend-разработчикам, DevOps- и SRE-инженерам, platform-инженерам, техническим лидам и архитекторам.
➡️ Зарегистрироваться | 5 343 |
| 8 |  +5У меня основной инструмент взаимодействия с ИИ - агент 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 | 5 484 |
| 9 |  Kuber Community Day возвращается
30 июля в Москве все неравнодушные к технологии встречаются на инженерной конференции Kuber Community Day.
На сцене выступят практики из Ænix, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Почтатех», «Инфосистемы Джет», Hilbert Team и других компаний.
Что вас ждет:
◾️доклады без маркетинга: 30 спикеров расскажут об использовании ИИ в Kubernetes, мониторинге контейнеров, обзоре инструментов экосистемы, получении сертификаций и пр.;
◾️мастер-класс по созданию Kubernetes-оператора: в конце все участники задеплоят его в кластер Yandex Managed Kubernetes;
◾️arch dating: короткие встречи с опытными специалистами, где можно обсудить технические и карьерные вопросы;
◾️научпоп: рассказ о кибернетическом подходе к управлению сложностью от Александра Нозика, директора центра научного программирования.
Форматы: офлайн и онлайн.
Участие бесплатное, регистрация обязательна. | 5 661 |
| 10 | 🔝 ТОП постов за прошедший месяц июнь. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 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 😩
#топ | 6 394 |
| 11 |  Размышлял тут на днях над судьбой сайта и статей на нём. Наткнулся на любопытный комментарий. Не припоминаю, чтобы он раньше привлекал моё внимание. Странно, что пропустил. Как вам такое мыслеизливание:
Капец, по вашей инструкции сбросил настройки на заводские и всё пинги не получаю от маршрутизатора! Спасибо за отличную статью и микротик говно для задротов с хвостиками, заваленными джинсами с кучей корманов и пивными животами! Маршрутизатор не советую, берите zyxel с keenetic os! Всё для людей сделано!
По-моему любой роутер после сброса настроек на заводские теряет в том числе и сетевые настройки. Это как бы база. Неужели в Зухеле по-другому?
———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#юмор #mikrotik | 7 356 |
| 12 |  😑 Дешевле - не значит выгоднее. Почему выбор по цене в итоге обходится дороже?
Когда выбирают серверы, обычно сравнивают железо: ядра, память, диски, цена за стойку. Инструменты управления уходят на второй план — и зря. Именно они определяют, сколько часов админ потратит на обслуживание в ближайшие 3–5 лет.
✔️На сайте сравнили сервера Dell и Supermicro.
Спешим поделиться их отличиями в:
ℹ️ Прошивках и BIOS
ℹ️ Телеметрии и интеграции
ℹ️ Конфигах и масштабах
ℹ️ Безопасности
✨ Позаботьтесь о вашем сисадмине сегодня, чтобы он не уволился завтра
🖥 Полное сравнение с цифрами и таблицами — читайте у нас на сайте
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJ7Xv4q | 6 816 |
| 13 |  Практически всегда, когда стоит вопрос покупки жёсткого диска для различных задач, я отдаю предпочтение линейке 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 продаваемого диска.
#железо | 7 017 |
| 14 | Среди бесплатных серверов с реализацией протокола 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 | 6 652 |
| 15 |  📑 От метрик к прогнозированию: как бизнес и ИИ меняют мониторинг
Сегодня мониторинг — больше чем техническая задача. Этот инструмент напрямую влияет на успех бизнеса. Но как не потеряться в потоке данных и предсказать сбои до их появления?
Приглашаем на вебинар, где ответим на этот вопрос и покажем, как выглядит новый стандарт наблюдаемости.
📅 9 июля | 11:00 (по Мск)
В программе вебинара
⏺ Эволюция инструментов: расскажем, почему старые подходы не работают и как выбрать современное решение.
⏺ Бизнес-драйверы: обсудим, как бизнес-задачи определяют тренды развития мониторинга.
⏺ Эпоха ИИ: покажем, как ИИ помогает автоматизировать процессы и анализировать данные.
⏺ «Астра Мониторинг»: продемонстрируем решение, которое позволяет не просто видеть, а предвидеть.
Приходите, чтобы узнать, как сделать ваши ИТ-системы прозрачными, управляемыми и надежными.
🔗 Зарегистрироваться на вебинар
Реклама, ООО "РусБИТех-Астра", ИНН 7726388700 | 6 009 |
| 16 |  У устройств 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 | 5 647 |
| 17 |  ☁️ Как перенести инфраструктуру в облако без потерь?
Для бизнеса облако — это скорость и гибкость. Но чем сложнее инфраструктура, тем выше риск допустить критическую ошибку при миграции. Баланс между скоростью запуска и сохранностью данных — это главный вызов для руководителей ИТ и ИБ.
На вебинаре Анжелика Захарова, руководитель практик 1С и Кибербезопасности К2 Cloud, и Арина Ашотян, руководитель направления консалтинга К2 Кибербезопасность, разберут реальные кейсы и расскажут:
🟦 Как объективно оценить необходимость перехода в облако
🟦 На что обращать внимание при планировании миграции
🟦 Какие контрольные точки обеспечат безопасный переход в облачную среду
Мероприятие будет полезно CISO и директорам по ИБ, CIO и руководителям ИТ-инфраструктуры, а также инженерам и техническим специалистам в области ИБ.
Дата: 16 июля
Время: 11.00
Онлайн
📆 Не пропустите — регистрация по ссылке. | 6 134 |
| 18 |  Небольшая заметка, которая у кого-то вызовет непонимание, как автор мог такого не знать. По факту не знал за столько лет работы с различной техникой.
Некоторое время назад я купил домой ИБП 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 😩
#железо | 5 825 |
| 19 |  +1Не так давно пришло уведомление от NewReleases.io. Удобный, кстати, сервис. Я так с тех пор им постоянно пользуюсь, читаю уведомления. Так вот, там было уведомление об обновление утилиты Labean. Я уже когда-то давно писал про него. Это простой сервис, который выполняет настроенные действия при посещении того или иного url. Он до сих пор поддерживается и время от времени обновляется.
Например, обращаемся на 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 knocker
After=network.target
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/labean /etc/labean/labean.conf
Restart=on-failure
[Install]
WantedBy=multi-user.target
Запускаю:
# systemctl daemon-reload
# systemctl start labean
Проверяю:
# ss -tulnp | grep 9191
tcp 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: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#security #gateway | 6 783 |
| 20 |  📍Есть два типа систем:
1️⃣ те, в которых уже используют Redis
2️⃣ и те, в которых пока не поняли, зачем он нужен
30 июня команда Cloud.ru проведет вебинар о том, где Redis действительно помогает ускорять приложения, а где может создать новые проблемы.
Что вы узнаете:
▶️задачи, для решения которых Redis подходит лучше всего
▶️стратегии кеширования и выбор подхода под разные сценарии
▶️типичные ошибки в инвалидации и способы снижения рисков
▶️защита от «горячих» ключей и всплесков нагрузки на базу
▶️оценка эффективности кеша и ситуации, когда он маскирует проблемы
Будет точно полезно бэкенд-разработчикам, техлидам и инженерам эксплуатации, которые занимаются оптимизацией производительности.
👉 Регистрируйтесь — участие бесплатное 👈
А если вы пропустили предыдущие «серии» — они доступны по ссылкам:
1️⃣ Эволюция приложения в облаке: как навести порядок в артефактах и образах
2️⃣ Эволюция приложения в облаке: как запустить микросервисы в Managed Kubernetes
3️⃣ Эволюция приложения в облаке: как обеспечить стабильность баз данных при росте проекта и нагрузок | 7 360 |
