Системное администрирование *

Ansible — система управления конфигурациями, написанная на языке программирования Python. Используется для автоматизации настройки и развертывания программного обеспечения. Обычно используется для управления Linux-узлами, но есть большая коллекция плагинов для подключения к другим устройствам и ОС. Наряду с Chef, Puppet и SaltStack считается одной из наиболее популярных систем управления конфигурациями для Linux. Главное отличие Ansible от аналогов — не нужна установка агента/клиента на целевые системы. С помощью Ansible можно развернуть, удалить или сконфигурировать любое ПО на удаленных серверах.

Одним из самых простых и эффективных способов оптимизировать размер почтовых ящиков на сервере является настройка времени хранения писем. Автоматическое удаление писем по истечении настроенного срока их хранения позволяет пользователям не превышать выделенную им квоту без дополнительных усилий с их стороны, а администратору точно прогнозировать размер данных хранящихся на сервере и, соответственно, верно рассчитывать время на резервное копирование и восстановление данных. В данной статье мы расскажем о том, как именно в Carbonio настраиваются политики хранения писем.

Недавно мы осуществили миграцию системы сбора наших инфраструктурных метрик с StatsD на Prometheus и остались весьма довольны результатами. Это была нелёгкая работа, но мы многому научились в процессе. Эта статья призвана рассказать, почему мы выбрали Prometheus, а также описать некоторые технические сложности, с которыми мы столкнулись.

Метрики — настолько важный и повсеместный компонент в современных распределенных системах, что легко забыть, что популярные протоколы метрик с открытым исходным кодом начали появляться только в последнее десятилетие.

Для умных дядь в статье ничего интересного, это статья про обычный туннель. Оно для самых маленьких, но отчаянно нуждающихся. Никаких wg-quick'ов тут, впрочем, не будет. :)

Когда я стал упорядочивать «знания» ввиде этой статейки, и понял, что в итоге получилось, то заметил, что информации по данной теме, оказывается, предостаточно (даже на Хабре), жаль, что осознал я это только уже когда всё сделал и понял, что мне, собственно, нужно было гуглить. В общем, пусть останется, дабы кто‑то, кто гуглит так же неправильно, мог случайно на эту статью наткнуться и что‑то полезное для себя почерпнуть. В процессе реализации я на каждом шаге споткнулся по нескольку раз, поэтому решил прокомментировать тут всё максимально подробно.

В этой статье я делюсь гибким архитектурным подходом к автоматизации сетей уровня сервис-провайдера и своим личным опытом отладки сигнального обмена.
Статья рассчитана не на новичков, а скорее тех, кто знаком с основными архитектурами и технологиями, используемыми в сетях уровня оператора и имеет в этом практический опыт.

Выход Windows Server 2025 запланирован на четвертый квартал 2024 года. Протестировать ее уже можно в облаке mClouds или скачав ISO-файл в Центре оценки Microsoft. А пока мы ждем выхода на рынок финального публичного релиза, давайте вместе разбираться, какие значимые улучшения обещают пользователям.

Проблема наблюдаемости (observability) возникает во всех организациях. Я помогу вам научиться не на своих, а на моих ошибках, подскажу, как обойти грабли и подводные камни. Здесь вы найдёте подборку антипаттернов, которая поможет избежать проблем в будущем.

Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.

Статья посвящена межсетевым экранам (МЭ) в 2024 году, их функционалу, архитектуре, и ключевым параметрам. Автор рассматривает функциональные возможности присущие межсетевым экранам на момент 2024 года без привязки к конкретным производителям. В статье рассмотрена архитектура и аппаратные компоненты, такие как процессоры, сетевые карты, оперативная память, и аппаратные ускорители, которые влияют на производительность. Особое внимание уделено реализации в МЭ задач позволяющих обеспечить надежность и управляемость решений.

В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.

Но как можно понять из наличия этой статьи, что-то пошло не так...

Всем привет! Меня зовут Дмитрий Мамонтов, я DevOps-инженер с опытом работы более пяти лет, а также наставник на курсе «DevOps для эксплуатации и разработки» и один из авторов курса «Эксплуатация и разработка в Kubernetes» в Яндекс Практикуме.

Представим, что у нас есть приложение, которое шлёт свои метрики в Yandex Monitoring, и стоит задача: масштабировать это приложение с помощью HPA в кластере Kubernetes в зависимости от метрики.

Есть два популярных варианта решения этой задачи:

В конце августа разработчики проекта OpenTofu приняли решение ограничить доступ к своему реестру для российских IP-адресов и удалить из GitHub-репозитория провайдеров российских облачных сервисов, таких как Yandex Cloud, Cloud.ru, Rustack Cloud Platform, VK Cloud и других.

​​Команда OpenTofu объяснила свои действия необходимостью соблюдать международные санкции против России, а технический лид проекта предоставил ссылки на политику безопасности и сводку заседания Технического руководящего комитета (TSC) от 20 августа 2024 года, на котором и было принято решение.

На протяжении двух месяцев команда OpenTofu не предоставляла развернутых пояснений касательно своих действий, что вызвало множество вопросов у сообщества. Дискуссии относительно дальнейшей судьбы реестра проводились на закрытых встречах, и информация относительно реестра не была доступна широкой аудитории. 

Сегодня, после очередного еженедельного митинга, проведенного Техническим руководящим комитетом, команда OpenTofu представила сообществу долгожданную политику работы с реестром. Эта политика должна стать основным руководством для дальнейшего принятия или удаления провайдеров из реестра OpenTofu.

Как отмечается в сводках заседаний Технического руководящего комитета (TSC) от 15 октября 2024 года и Технического руководящего комитета (TSC) от 23 октября 2024 года, Технический лидер проекта готов ответить на вопросы касательно политики для существующих issues и pull request'ов на GitHub, включая обсуждения в официальном Slack проекта. Тем не менее, в настоящее время команда не планирует принимать какие-либо действия по ранее предпринятым шагам, например, возвращать ранее удаленные провайдеры в реестр.

Когда был создан SMTP, он работал, передавая данный в открытом виде, поскольку тогда мы ещё не разработали решение для безопасной передачи данных, то, что мы называем сейчас «безопасность транспортного уровня» (transport layer security, TLS). Когда TLS наконец-то был готов, нам потребовалось придумать способ поэтапного внедрения TLS. Был создан STARTTLS, предлагающий шифрование «по возможности». По сути, почтовый сервер отправителя мог спросить почтовый сервер получателя: «Поддерживашь ли ты шифрование?», и, если ответ был положительным, устанавливалось TLS-соединение с использованием сертификата, предоставленного сервером. Если нет, использовалось SMTP-соединение с передачей данных в открытом виде.

Любой, кто знаком с темой сетевой безопасности, увидит здесь проблему. Активно действующий злоумышленник, осуществляющий атаку «атакующий посередине» (attacker-in-the-middle, AitM), может подставить свой собственный ответ, указывая, что шифрование не поддерживается, и обманом заставить отправителя использовать открытый текст, что позволит злоумышленнику перехватывать сообщения. Это классическая атака понижения версии.

Так исторически сложилось, что задача организации простого и понятного резервного копирования в мире PostgreSQL до сих пор не решена. Есть набор комьюнити утилит, у каждой из которых есть некие плюсы, но всегда в нагрузку будет прорва минусов (тут нет инкрементных копий, там нет внятного расписания, это может только весь сервер вместо конкретной базы увозить и так далее). Да, есть тяжёловесный энтерпрайзный софт за много денег, зачастую требующий странного и работающий по какой-то своей логике, но это тоже не панацея. А вот чтобы просто и понятно, без головных болей организовать прозрачный процесс банального бекапа с инкрементами, работающим расписанием и восстановления только того что надо - вот такого нет.

Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.

А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.

Привет, Хабр! Рассказываем об одном из вариантов применения Open Source инструментов Software Supply Chain Security. Коллеги по цеху попросили выложить небольшой его обзор сюда:)

Эта статья является краткой текстовой версией моего доклада с конференции PHD2. Если тема вас заинтересует, можете посмотреть полное выступление по ссылкам: [RuTube] / [YouTube].

В этой статье мы рассмотрим процесс создания кастомного scheduler'а для Kubernetes, ориентируясь на Kubernetes Scheduling Framework.

Обычно для назначения подов на вычислительные узлы используется стандартный планировщик, который, проанализировав различные параметры, автоматически выполнит оптимальное размещение (например, распределит поды таким образом, чтобы не размещать их на вычислительных узлах с недостаточными ресурсами).

В одном из наших проектов, где мы использовали оператор Strimzi для развёртывания кластеров Kafka, заказчик выдвинул специфические требования по размещению данных, резервному копированию и восстановлению.
Одним из ключевых пунктов стал вопрос строгой привязки экземпляров приложения к вычислительным узлам.
Для этого нам пришлось создать кастомный scheduler, учитывая нюансы инфраструктуры, особенности приложения и требуемые правила размещения.

Меня всё чаще в комментариях и ПМ спрашивают, как установить так рекомендуемую мной Windows IoT Enterprise LTSC поверх существующей инсталляции (будь то Windows 7, Windows 10 или Windows 11) с сохранением всех приложений, данных и настроек. Я уже писал подробную статью об установке ОС как апгрейда – Как правильно сделать апгрейд ОС — установить Windows 11 поверх существующей с сохранением приложений и настроек / Хабр (habr.com), где рассказывал о разных сложностях, встречающихся на пути установки ОС – новых требованиях к железу, разных языках и, конечно, о несовместимости изданий, не позволяющих обновиться с сохранением приложений и данных пользователя. Но методы редактирования реестра для многих читателей оказались сложными.

И я вообще не затронул тогда Windows Server – как обновиться с Server Core до Server с рабочим столом, как обновить AzureStackHCI до Server Datacenter Azure Edition, и как обновляться с Annual Cycle изданий Windows Server AC (например, 23H2) до LTSC (например, 24H2) и наоборот с LTSC до AC (в 2025 году нас ждёт только ServerDatacenterACorCore).

За пару месяцев с прошлой заметки на форумах MyDigitalLife было выпущено два новых проекта, позволяющих очень упростить процедуру апгрейда, и ниже я расскажу как раз об этом. Мы сможем подготовить образ Windows 11 24H2 IoT Enterprise LTSC так, что с любого издания Windows 7/8/8.1/10 вы сможете обновиться до него без потери данных. Ну и научимся обновлять Windows Server.

Для примеров ниже я буду рассказывать о трёх сценариях:

Друзья, сегодня мы погрузимся в мир Pydantic 2 – мощного инструмента для валидации данных в Python! Узнаем, почему эта библиотека стала незаменимой в 30% Python-проектов и как она упрощает работу с данными. От базовых концепций до продвинутых техник – мы охватим всё, что нужно знать современному Python-разработчику. Готовьтесь к практике – ведь только так можно по-настоящему освоить Pydantic и сделать ваш код более надёжным и эффективным.