Лига сисадминов

Главный корпоративный навык: сказать "мы", когда накосячил сам😏 #ит_юмор #ai #claude

Два опенсорс-проекта приносят в 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

ИИ-агенты против Kubernetes: кому какое место в цикле управления ИИ-агенты рассуждают, а операторы Kubernetes исполняют. Разбираемся, как совместить когнитивность и детерминированные циклы управления ради более безопасных кластеров. https://telegra.ph/II-agenty-protiv-Kubernetes-komu-kakoe-mesto-v-cikle-upravleniya-10-26 #ит_статьи #devops #kubernetes #karpenter #argocd #aiagents

📘 На 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 курсов бесплатно — доступны после регистрации

Автоматическое обновление шаблонов 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

Мы не знаем что мы хотим, и когда мы хотим, но нужны было сделать это вчера #ит_юмор #deadline

Коммитьте секреты в Git, зашифрованными, с SOPS и age Почти у каждого проекта, которого я касался, один и тот же флоу: создать .env, забить туда пароль от базы и API-ключи и тут же добавить файл в .gitignore, чтобы в репозиторий он не попал никогда. Безопасностью при таком подходе конечно особо не пахнет. Какое-то время назад я искал что-то получше и наткнулся на git-crypt, который хотя бы возвращал секреты в репозиторий. Работало, но всегда было слегка не то (зашифрованные файлы превращаются в непрозрачные бинарные блобы, а диффы становятся бесполезными). Я искал дальше, и сейчас держу секреты внутри Git двумя маленькими утилитами, которые справляются куда лучше: SOPS и age. Если вы ведёте homelab или небольшую инфру и не хотите (или вам не нужно) поднимать целый стек управления секретами только чтобы спрятать пароль от базы, эта заметка для вас. #ит_статьи #devops #linux #sops #age #secrets

Когда 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

Правильный способ запускать shell-команды из Python Python часто берут, чтобы автоматизировать всё подряд, в том числе задачи системного администрирования и всё, где нужно запускать другие программы или общаться с операционной системой. Способов сделать это в Python, впрочем, много, и большинство из них, пожалуй, плохие. Поэтому в этой статье разберём все варианты запуска чужих процессов, которые у вас есть в Python: плохие, хорошие и, самое главное, правильный способ это делать. https://telegra.ph/Pravilnyj-sposob-zapuskat-shell-komandy-iz-Python-10-22 #ит_статьи #devops #linux #python #shell

Как работают файловые системы Linux-контейнеров Эта небольшая статья поможет разобраться в вопросе, откуда у контейнера берётся файловая система, и как она организована. https://telegra.ph/Kak-rabotayut-fajlovye-sistemy-Linux-kontejnerov-10-20 #ит_статьи #devops #linux #docker #overlayfs

Никогда такого не было, и вот опять #ит_юмор #скрипты #код

Может ли языковая модель работать в 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

Шпаргалка по протоколу SNMP #ит_заметки #network #snmp #cheatsheet

Краткая история 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

Новая технология 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

Файл самому себе, только без мессенджера: присматриваемся к 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

Друзья, Kuber Conf переносится на 23 ноября АОТ создана для того, чтобы объединять инженеров и компании, развивать и распространять облачно-ориентированные технологии. Сейчас, без преувеличения, все специалисты нашей индустрии работают на пределе возможностей. Мы сосредоточены на самом необходимом — стабильной работе инфраструктуры и решении текущих проблем.  Поэтому 22 октября мы не сможем провести конференцию такой, как её задумывали, и приняли решение перенести её на 23 ноября. Kuber Conf — это не только доклады и технические дискуссии, но и возможность встретиться, обменяться опытом и укрепить связи внутри сообщества. Нам хочется, чтобы у всех была возможность полноценно включиться в этот разговор.  Все купленные билеты остаются действительными на новую дату.

Решения о маршрутизации в ядре 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

Когда VPS уже тесноват, а мощный сервер пока избыточен Для нескольких сайтов, интернет-магазина или корпоративного портала может хватить бюджетного выделенного сервера с SSD. У Рег.облака есть конфигурация на Xeon E3-1270v3 с 32 ГБ RAM и двумя SSD по 480 ГБ за 8 750 ₽/мес. Можно разместить несколько проектов на одной машине и не делить ресурсы с другими клиентами. Что ещё предлагают при заказе: • бесплатную миграцию; • бесплатную установку BitrixEnv; • установку ISPmanager 6 от 349 ₽/мес. Подобрать конфигурацию под свои задачи можно на странице распродажи.

Решения о маршрутизации в ядре 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