Лига сисадминов
Открыть в Telegram
Статьи, переводы статей, заметки, и юмор на тему системного администрирования. Написать администратору: @s_league_admin_bot КНД: https://clck.ru/3Fy4kQ
Больше📈 Аналитический обзор Telegram-канала Лига сисадминов
Канал Лига сисадминов (@sysodmins_league) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 13 335 подписчиков, занимая 9 517 место в категории Технологии и приложения и 48 650 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 13 335 подписчиков.
Согласно последним данным от 26 октября, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило 105, а за последние 24 часа — -1, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 14.02%. В первые 24 часа после публикации контент обычно набирает 7.30% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 1 869 просмотров. В течение первых суток публикация набирает 973 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 18.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как linux, ит_статьи, kubernetes, devops, docker.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Статьи, переводы статей, заметки, и юмор на тему системного администрирования.
Написать администратору: @s_league_admin_bot
КНД: https://clck.ru/3Fy4kQ”
Благодаря высокой частоте обновлений (последние данные получены 27 октября, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
13 335
Подписчики
-124 часа
+217 дней
+10530 дней
Архив постов
13 334
Главный корпоративный навык: сказать "мы", когда накосячил сам😏
#ит_юмор #ai #claude
13 334
Два опенсорс-проекта приносят в Proxmox хранилище в духе VMware VMFS
Одна из вещей, за которые я всегда ценил VMware vSphere, - возможности по storage. Особенно если у вас к кластеру подключена обычная SAN. По сути, вы просто отдаёте хранилище на ESXi по iSCSI или Fibre Channel LUN сразу нескольким хостам, форматируете его в VMFS - и вот вам общий датастор. Готово. У Proxmox есть отличные варианты storage, вроде Ceph, NFS и shared LVM. Но что-то вроде VMFS, мне всегда казалось, было бы отличным дополнением к тому, что Proxmox уже умеет. Два недавних проекта, которые я увидел, зацепили меня: они пытаются сделать так, чтобы альтернатива VMFS для Proxmox всё-таки появилась.
https://telegra.ph/Dva-opensors-proekta-prinosyat-v-Proxmox-hranilishche-v-duhe-VMware-VMFS-10-26
#ит_статьи #devops #proxmox #cetrafs #meshxfs #homelab
13 334
ИИ-агенты против Kubernetes: кому какое место в цикле управления
ИИ-агенты рассуждают, а операторы Kubernetes исполняют. Разбираемся, как совместить когнитивность и детерминированные циклы управления ради более безопасных кластеров.
https://telegra.ph/II-agenty-protiv-Kubernetes-komu-kakoe-mesto-v-cikle-upravleniya-10-26
#ит_статьи #devops #kubernetes #karpenter #argocd #aiagents
13 334
📘 На Mentorix вышел курс — «Terraform: инфраструктура как код»
Хотите не просто писать .tf-файлы, а собирать инфраструктуру кодом, с которой работает вся команда? Этот курс — полный путь от первого apply до пайплайна, который применяет только проверенный план.
• Основы: HCL, init → plan → apply, провайдеры и lock-файл
• Переменные: типы, коллекции, валидация, sensitive
• Ресурсы: граф зависимостей, count и for_each, lifecycle
• State: дрейф, state mv и moved, импорт существующего
• Модули: контракты, композиция, версии
• Окружения: workspaces, tfvars, бэкенды S3/GCS/Yandex
• Проверки: preconditions, check-блоки, terraform test
• CI/CD: GitLab CI и GitHub Actions, дрейф-детект
• Капстоун: платформа из трёх стеков с dev и prod
🎓 Сертификат — добавьте в резюме или LinkedIn
🏷 Скидка 50%, действует 48 часов
12 990 ₽ → 6 495 ₽
➜ Пройти курс на Mentorix
Ещё 25 курсов бесплатно — доступны после регистрации
13 334
Автоматическое обновление шаблонов cloud-init в Proxmox с помощью Ansible
У меня был небольшой Ubuntu cloud-init шаблон в Proxmox. Он работал хорошо, особенно когда мне нужно было развернуть несколько виртуальных машин с помощью Terraform.
Но была одна проблема. Каждая новая виртуальная машина по-прежнему требовала обновления своих пакетов после создания. Когда я развернул три виртуальные машины, весь процесс занял более шести минут, и около половины этого времени ушло на обновление пакетов.
В ближайшие месяцы я буду использовать этот шаблон довольно часто для создания кластеров Kubernetes. Обновление каждой виртуальной машины после каждого развертывания быстро бы стало рутиной, поэтому я решил автоматизировать пересборку шаблона вместо этого.
Цель простая: регулярно пересобирать Ubuntu cloud-init шаблон с последним cloud образом, чтобы новые виртуальные машины начинались с более актуального базиса.
https://telegra.ph/Avtomaticheskoe-obnovlenie-shablonov-cloud-init-v-Proxmox-s-pomoshchyu-Ansible-10-24
#ит_статьи #devops #proxmox #cloud_init #ansible #ubuntu #semaphore_ui
13 334
Мы не знаем что мы хотим, и когда мы хотим, но нужны было сделать это вчера
#ит_юмор #deadline
13 334
Коммитьте секреты в Git, зашифрованными, с SOPS и age
Почти у каждого проекта, которого я касался, один и тот же флоу: создать .env, забить туда пароль от базы и API-ключи и тут же добавить файл в .gitignore, чтобы в репозиторий он не попал никогда.
Безопасностью при таком подходе конечно особо не пахнет. Какое-то время назад я искал что-то получше и наткнулся на git-crypt, который хотя бы возвращал секреты в репозиторий. Работало, но всегда было слегка не то (зашифрованные файлы превращаются в непрозрачные бинарные блобы, а диффы становятся бесполезными). Я искал дальше, и сейчас держу секреты внутри Git двумя маленькими утилитами, которые справляются куда лучше: SOPS и age. Если вы ведёте homelab или небольшую инфру и не хотите (или вам не нужно) поднимать целый стек управления секретами только чтобы спрятать пароль от базы, эта заметка для вас.
#ит_статьи #devops #linux #sops #age #secrets
13 334
Когда unix way в Linux даёт сбой: NFS
В мире open source давно живёт никем не оспариваемая аксиома: лучшие приложения - маленькие, и у каждого одна-единственная задача (aka unix-way). Если вам нужен инструмент, убирающий фон с фотографии, - у вас должна быть маленькая терминальная программа, которая получает фотографию на входе и выдаёт фотографию без фона. Если нужно переименовать файлы, добавив метку времени, - маленькая терминальная программа, которая получает файл и выдаёт переименованный файл. И тогда, если вы хотите убрать фон и добавить к фотографиям метку времени, вы можете соединить эти программы конвейером - и по факту получите новый инструмент в шелле Linux.
Это как получить ящик с разными инструментами, которые можно комбинировать, чтобы сделать работу. Работа может быть настолько сложной, что ни один инструмент из ящика сам по себе с ней не справится. Инструменты могут быть вовсе не рассчитаны на неё. Но вместе они дают нечто, о чём создатели инструментов и не помышляли, - нечто, что при известной смекалке решит вашу сложную задачу. Это и есть философия unix way.
Однако практика показывает, что не ко всему подряд можно и нужно применять unix way. NFS, на ранних стадиях своего развития, стал одним из таких неудачных примеров.
https://telegra.ph/Kogda-unix-way-v-Linux-dayot-sboj-NFS-10-23
#ит_статьи #linux #nfs #smb #unixway
13 334
Правильный способ запускать shell-команды из Python
Python часто берут, чтобы автоматизировать всё подряд, в том числе задачи системного администрирования и всё, где нужно запускать другие программы или общаться с операционной системой. Способов сделать это в Python, впрочем, много, и большинство из них, пожалуй, плохие.
Поэтому в этой статье разберём все варианты запуска чужих процессов, которые у вас есть в Python: плохие, хорошие и, самое главное, правильный способ это делать.
https://telegra.ph/Pravilnyj-sposob-zapuskat-shell-komandy-iz-Python-10-22
#ит_статьи #devops #linux #python #shell
13 334
Как работают файловые системы Linux-контейнеров
Эта небольшая статья поможет разобраться в вопросе, откуда у контейнера берётся файловая система, и как она организована.
https://telegra.ph/Kak-rabotayut-fajlovye-sistemy-Linux-kontejnerov-10-20
#ит_статьи #devops #linux #docker #overlayfs
13 334
Может ли языковая модель работать в Linux eBPF?
Может ли Linux eBPF выполнить настоящую языковую модель? Эксперимент с Qwen3-0.6B показывает, какая именно работа идет в ядре, насколько это быстро и почему INT4 и память arena остаются открытыми компромиссами.
Программы Linux eBPF обычно следят за работой, которая делается в другом месте, или влияют на нее: трассируют системный вызов, фильтруют пакет или выбирают политику планирования. qwen3-ebpf задает другой вопрос. Может ли верифицированная BPF-программа выполнить численную работу настоящей языковой модели, а не просто следить за сервером модели?
Эксперимент прогоняет 28 слоев декодера Qwen3-0.6B в Linux eBPF, считает оценку для каждого из 151 936 токенов словаря и выбирает следующий токен внутри ядра. Еще он держит KV-кэш для последующих токенов. Это работающий прямой проход, а не годная замена движку инференса на CPU или GPU: один токен в замере на тестовом хосте все еще занимает около 1,2 секунды, а загрузка модели, работа с текстом и вызов BPF-операторов остаются на C.
https://telegra.ph/Mozhet-li-yazykovaya-model-rabotat-v-Linux-eBPF-10-20
#ит_статьи #devops #linux #kernel #eBPF #qwen
13 334
Краткая история Unix-команд на Windows: CoreUtils
Если вы сегодня пользуетесь Windows и набираете в терминале ls, cat, grep или awk, есть хороший шанс, что произойдёт что-то полезное. Так было не всегда. Большую часть истории персональных компьютеров Unix/Linux и Windows жили по разные стороны культурной границы. У юниксоидов были пайпы, маленькие компонуемые утилиты, шелл-скрипты, make, sed, awk, grep, tar и идея, что всё есть файл. У пользователей Windows были буквы дисков, обратные слэши, COMMAND.COM или cmd.exe и API, которому было почти всё равно, что там думает POSIX.
И всё же спрос на Unix-утилиты под Windows был всегда. Часть его шла от программистов, которым хотелось одни и те же скрипты сборки везде. Часть - от администраторов, которые скучали по grep и awk. Часть - от компаний, которые пытались портировать большие Unix-приложения на NT, не переписывая их все. В итоге вышла длинная странная история слоёв Unix-на-Windows, тулкитов, компромиссов и совместимости «почти, но не совсем».
https://telegra.ph/Kratkaya-istoriya-Unix-komand-na-Windows-CoreUtils-10-18
#ит_статьи #linux #windows #coreutils #cygwin #wsl
13 334
Новая технология Linux сжимает память в RAM, как RAM, с ускорением в 452 раза - метод CRAM дает гигантский прирост при чтении сжатой памяти
Новый метод дает доступ по стандартной семантике памяти, а не как к блочному устройству, и резко поднимает производительность.
Новая модель сжатия под названием CRAM предлагает другой путь к сжатию: она вообще обходится без swap, держа сжатые данные в памяти, и по производительности обходит ZRAM до 452 раз. В 1990-е я был ребенком, и идея казалась мне очень простой: файлы я могу сжать PKZIP, так почему нельзя сделать то же самое с RAM? Я, разумеется, не единственный гений, и та же мысль была у многих других, так что сжатие памяти давно есть в большинстве операционных систем. В Linux самые ходовые варианты - zswap и ZRAM, но оба по сути фичи слоя swap. CRAM - новый заход, который заявляет о неимоверном приросте производительности.
https://telegra.ph/Novaya-tehnologiya-Linux-szhimaet-pamyat-v-RAM-kak-RAM-s-uskoreniem-v-452-raza---metod-CRAM-daet-gigantskij-prirost-pri-chtenii--10-17
#ит_статьи #linux #kernel #zram #zswap #cram #numa
13 334
Файл самому себе, только без мессенджера: присматриваемся к flipflop
Знакомый всем способ перекинуть файл с телефона на ноутбук — скинуть самому себе в телеграму: быстро и работает отовсюду, где есть интернет. Но если файлы между своими устройствами ходят каждый день, хочется чего-то попрямее — без облака, без вкладки, без лишнего посредника. На эту роль претендует flipflop — маленькая опенсорс-утилита, «файлшаринг для эпохи meatspace», как описывает её сам автор.
Идея такая. Один раз соединяете два или больше устройств в доверенный тоннель — и дальше можно слать друг другу файлы, ссылки и просто текст, как сообщения в чате. Работает это через Bluetooth, локальную сеть или обычный интернет. Под капотом — библиотека Iroh: у каждого устройства адрес-публичный ключ, соединение устанавливается напрямую, с пробиванием дырок в NAT, а если прямой путь не сложился — через публичные релеи.
Написано на Rust (ну куда нынче без него), лицензия GPL-3.0, версии есть под Linux, macOS, Windows и Android — Android в виде APK, всё с GitHub releases. Версии для iOS нет: автор пишет, что не может публиковать её для iPhone. На Windows при первом запуске появится системное предупреждение — об этом предупреждает сам README. Проект молодой, репозиторий открытый.
Ниша понятная: не замена облачным дискам, а «мессенджер» для собственных устройств — телефон, ноутбук, комп родителей в другом городе. Насколько это удобно в быту, каждый проверит на своём железе — установка несложная, исходники открыты.
#ит_заметки #linux #android #filesharing #opensource #github
13 334
Друзья, Kuber Conf переносится на 23 ноября
АОТ создана для того, чтобы объединять инженеров и компании, развивать и распространять облачно-ориентированные технологии. Сейчас, без преувеличения, все специалисты нашей индустрии работают на пределе возможностей. Мы сосредоточены на самом необходимом — стабильной работе инфраструктуры и решении текущих проблем.
Поэтому 22 октября мы не сможем провести конференцию такой, как её задумывали, и приняли решение перенести её на 23 ноября. Kuber Conf — это не только доклады и технические дискуссии, но и возможность встретиться, обменяться опытом и укрепить связи внутри сообщества. Нам хочется, чтобы у всех была возможность полноценно включиться в этот разговор.
Все купленные билеты остаются действительными на новую дату.
13 334
Решения о маршрутизации в ядре Linux - часть 2.2: кэширование
Завершаем серию статей о том, как ядро Linux ищет маршрут и что потом делает с пакетом. В первой части был lookup и путь пакета по стеку. В прошлой разобрали, откуда берётся готовое решение: старый routing cache, кэш на nexthop и исключения к нему. Здесь обещанное завершение. На пути отправки решение не прикрепляется к пакету внутри lookup, его кэшируют в сокете. Дальше early demux на приёме, hint для пачек пакетов и то, как весь этот кэш сбрасывают, когда маршруты меняются.
https://telegra.ph/Resheniya-o-marshrutizacii-v-yadre-Linux---chast-22-kehshirovanie-10-14
#ит_статьи #linux #kernel #routing #ipv4 #netfilter
13 334
Когда VPS уже тесноват, а мощный сервер пока избыточен
Для нескольких сайтов, интернет-магазина или корпоративного портала может хватить бюджетного выделенного сервера с SSD.
У Рег.облака есть конфигурация на Xeon E3-1270v3 с 32 ГБ RAM и двумя SSD по 480 ГБ за 8 750 ₽/мес. Можно разместить несколько проектов на одной машине и не делить ресурсы с другими клиентами.
Что ещё предлагают при заказе:
• бесплатную миграцию;
• бесплатную установку BitrixEnv;
• установку ISPmanager 6 от 349 ₽/мес.
Подобрать конфигурацию под свои задачи можно на странице распродажи.
13 334
Решения о маршрутизации в ядре Linux - часть 2.1: кэширование
В предыдущей статье я много говорил про решение о маршрутизации. Его представляют внешняя struct rtable и внутренняя struct dst_entry, и оно прикрепляется к сетевому пакету skb по результату routing lookup. Но одну очень важную тему я намеренно оставил в стороне... кэширование. Если вы смотрите, как пакет обрабатывается по прикреплённому решению о маршрутизации, то неважно (по крайней мере на первый взгляд), откуда это прикреплённое решение на самом деле взялось. Может, его выделили специально под этот сетевой пакет, а может, оно пришло из какого-то кэша... неважно. Обработка пакета от этого не меняется. Но от этого тема кэширования не становится менее важной. На самом деле она очень важна, особенно для производительности, а история у неё непростая, так что я решил: ей стоит отдельная статья. Вы, наверное, то тут, то там слышали термин routing cache, да? Настоящий полноценный routing cache был в старых ядрах, и его убрали в v3.6. Но это не значит, что кэширование от этого исчезло совсем. После удаления в ядро добавили другие механизмы кэширования и оптимизации вокруг решений о маршрутизации. А кое-что из уже существовавшего оставили. В интернете полно статей и документации, где упоминается какой-нибудь routing cache. Но из-за бурной истории во всей этой, местами противоречивой, информации очень легко запутаться. По крайней мере у меня в начале так и было. Эта статья - попытка разложить эту информацию и поставить в контекст, как было в старых ядрах и как на самом деле есть в современном ядре вроде v5.14. Оно конечно уже тоже старовато, но основные принципы с тех пор не претерпели существенных изменений.
https://telegra.ph/Resheniya-o-marshrutizacii-v-yadre-Linux---chast-21-kehshirovanie-10-14
#ит_статьи #linux #kernel #routing #ipv4 #netfilter
