Вторая часть перевода лекции Карсона Андерсонa, в котором представлен подробный разбор принципов работы SaltStack, а именно модулей их вариаций, методов взаимодействия с ними и многого другого. Всех заинтересованных прошу под кат. Должен предупредить: под катом много текста, а также много GIF'ок.
SaltStack Deconstructed. Часть 1.
Перевод лекции Карсона Андерсонa, в котором представлен подробный разбор принципов работы SaltStack - первая часть. В ней рассматривается работа миньона, мастера, транспортного уровня между ними и скриптов. Всех заинтересованных прошу под кат. Должен предупредить: под катом много текста, а также много GIF'ок.
Привет, Хабр! Меня зовут Александр, я лидер команды DevSup (это как DevOps, только с функцией поддержки больших клиентов которым Saas не подходит) в IT-компании ПравоТех. Мы создаем ИТ-решения для автоматизации юридической функции.
Будучи разработчиком таких систем, мы понимаем, что наши клиенты предъявляют высокие требования к информационной безопасности. Это закономерно отражается в договорах — целыми разделами об обработке данных, сроках обновления информации и многом другом.
Работая в такой среде, мы постоянно размышляем о культуре ИБ. Разработчики, тестировщики, DevOps и сисадмины, как правило, хорошо осведомлены об угрозах и осторожны. Но безопасность компании — это общее дело. Злоумышленники часто ищут лазейки там, где их меньше всего ждут, целенаправленно атакуя сотрудников, чья повседневная работа не связана напрямую с техническими деталями. Именно такие коллеги, в силу специфики своих задач и доверия к другим внутри компании, могут невольно стать мишенью для изощрённых атак.
Как эффективно донести до всех сотрудников суть современных киберугроз? Как сформировать не просто список «что нельзя делать», а глубокое понимание тактик злоумышленников, их уловок и масок?
Вместе с нашей командой обучения (Tutors) мы нашли формат — короткие художественные истории. Они показывают, как обычные рабочие (и не только) ситуации могут обернуться серьёзными инцидентами безопасности. Эти истории легли в основу нашего курса по информационной безопасности.
Сегодня публикуем вторую историю из серии — «Уволившийся сотрудник». О буднях техподдержки для крупных клиентов которые ведут себя порой очень противоречиво.
Старый, но рабочий сервер Dell R210 II стоял без дела. Мы решили использовать его повторно и перепрофилировать в резервный бэкап-сервер для внутренних задач. Однако возникла проблема: диски объёмом 8 ТБ, которые мы хотели подключить, не распознавались контроллером. Разбираемся, как это обошли.
ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.
В условиях ограничений на использование зарубежного ПО все больше российских компаний начинают масштабные проекты по переходу на отечественные решения. Один из таких кейсов — пилотное внедрение нашей системой управления каталогом Dynamic Directory в территориально распределенной организации с десятками филиалов и тысячами рабочих мест.
В этой статье мы расскажем о технической стороне проекта: как была устроена инфраструктура заказчика, как мы проектировали пилот, какие решения принимали на ходу и какие технические возможности Dynamic Directory помогли достичь результата.
Что общего у систем видеоконференцсвязи (ВКС), финансовых транзакций и авиаперевозок? Все они должны работать всегда, когда нужны людям. Сегодня расскажем, как мы строили георезервирование для инфраструктуры, что пошло не так и какие выводы сделали. Перед вами — true story, как мы помогаем одному из наших заказчиков сопровождать инфраструктуру большого критичного сервиса.
Привет, Хабр! Это Никита Турцаков и Алексей Кузьмин из К2.
В этой статье расскажем:
• зачем и для чего нужно георезервирование для системы ВКС;
• как мы подошли к выбору архитектуры;
• с чем столкнулись при реализации;
• и что бы сделали по-другому, если бы начинали сейчас.
Готовьтесь: будет много практики и немного боли — потому что как без неё в масштабных и амбициозных задачах.
Привет, Хабр! Я Максим, инженер по тестированию Selectel. Недавно мы провели технический воркшоп по работе с Kubernetes на выделенных серверах. Под катом — подробный текстовый разбор. Рассмотрим создание кластера через панель управления, деплой приложения, настройку внешнего доступа и подключение облачной базы данных с тестовым запросом прямо из пода.
Привет, Хабр! На связи Алексей Ежков из из Cloud4Y. Один внешний IPv4, десятки пользователей Exchange и растущий трафик портала — звучит как головоломка? В этой статье я покажу, как мы решили её, заведя всё хозяйство за единственным IP и обеспечив максимальную защиту.
ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных
27 июля 2025 года Линус Торвальдс представил релиз ядра Linux 6.16 под кодовым названием Baby Opossum Posse. Новый релиз вышел спустя два месяца после версии 6.15, строго по графику, и включает множество улучшений, оптимизаций и поддержку нового оборудования. Релиз Linux 6.17 ожидается в октябре 2025 года и станет основой для дистрибутивов, таких как Ubuntu 25.10 и Fedora 43. Исходный код Linux 6.16 доступен на kernel.org, а коммит релиза можно найти на GitHub и в Makefile.
В Linux 6.16 принято 15 924 исправления от 2 145 разработчиков, размер патча составил 50 МБ: изменено 13 793 файлов, добавлено 655 451 строк кода, удалено 316 441 строк. По сравнению с Linux 6.15 (15 945 исправлений, 59 МБ), изменения чуть менее объемные, но затрагивают ключевые подсистемы. Около 45% изменений связаны с драйверами, 16% — с архитектурным кодом, 13% — с сетевым стеком, 4% — с файловыми системами и 3% — с внутренними подсистемами ядра. Исходный код включает 38,4 миллиона строк в 78,4 тысячах файлов (по данным cloc).
Одновременно выпущено ядро Linux-libre 6.16-gnu, очищенное от несвободных компонентов. В нём нейтрализована загрузка блобов в новых драйверах, таких как Intel QAT 6xxx crypto, ST vd55g1 sensor, ath12k AHB WiFi, Aeonsemi AS21xxx и MediaTek 25Gb Ethernet. Также обновлена чистка блобов в драйверах Nova Core, Nouveau, Realtek r8169 Ethernet, Qualcomm Iris, Venus, Mediatek mt7996 WiFi, Qualcomm ath11k и ath12k WiFi, Texas Instruments tas2781 и Renesas R-Car gen4 PCIe.
В свете ситуации, случившейся с крупнейшим авиаперевозчиком России, приведшей к огромным потерям десятков тысяч пассажиров в первую очередь и самого перевозчика во вторую, уместно порассуждать о "как это было на самом деле", и "что если бы".
Начну с "как это было на самом деле".
Следуя устоявшемуся квартальному ритму выпуска значимых релизов, мы выпустили стабильные версии Angie и Angie PRO 1.10 — форка nginx, развиваемого в основном бывшими ключевыми разработчиками оригинального проекта.
Как и в прошлый раз, расскажем подробнее о нововведениях, приводя примеры. Вы узнаете, в чём ключевая фишка нового релиза (картинка под заголовком намекает); также слегка приоткроем завесу тайны над тем, что у нас припасено на будущее.
А пока — краткий список нововведений, которые будут разобраны ниже:
— автоматическое проксирование и балансировка веб-сервисов в Docker-контейнерах (или Podman);
— автоматическое получение TLS-сертификатов для потокового модуля (stream);
— прием соединений Multipath TCP (MPTCP);
— контроль перегрузки CUBIC в QUIC-соединениях;
— привязка сессий с внешним хранилищем в модуле stream;
— новые режимы привязки сессий при проксировании HTTP-запросов;
— режим постоянного перехода на резервную группу в модуле stream.
Привет, Хабр! Меня зовут Максим Сыропятов, я отвечаю в Arenadata за безопасную разработку. В этой статье расскажу, как мы перенесли систему лицензирования инструмента статического анализа SVACE в облако — без костылей, туннелей и физического железа. Поделюсь, какие ограничения нам пришлось обойти, зачем это вообще понадобилось и что дало такое решение в контексте безопасности и стабильности разработки.
SVACE позволяет проводить углублённый анализ зависимостей функций и путей, через которые данные могут попасть в программу. Само решение и предлагаемый функционал вполне нас устраивают, но в то же время есть нюансы, связанные с системой лицензирования — по умолчанию лицензия приезжает на HASP-ключе. Мы подробно разберем процесс миграции в облако OEM-лицензии, трудностях, с которыми мы столкнулись, и преимуществах, которые это решение дало для тестирования и разработки.
Привет, Хабр!
На связи сервисная команда «Инфосистемы Джет». Сегодня хотим рассказать про один из технических кейсов. На его решение должна была уйти пара часов. Вместо этого он съел четыре дня нашей жизни. Спустя почти десяток лет он регулярно вспоминается в обсуждениях за обедом как один из непростых в диагностике. На днях обсуждали его — почему бы теперь не рассказать о нем вам? :) Приступим.
Продолжаем разбираться в OpenSource генераторе трафика от Cisco - TRex. При разработке и внедрении сетевого оборудования критически важно проводить его тщательное тестирование. Маршрутизаторы и коммутаторы должны выдерживать заявленную нагрузку, правильно обрабатывать трафик на разных уровнях.
Стандартизированные методики (например, RFC 2544) определяют, как измерять пропускную способность устройства без потерь и другие метрики. Ранее для таких испытаний широко применялись дорогостоящие аппаратные генераторы трафика (Ixia, Spirent и т. д.). Однако в условиях ограниченной доступности коммерческих решений всё более актуальными становятся открытые альтернативы.
Одной из наиболее доступных и при этом мощных опций является бесплатный Open Source генератор трафика Cisco TRex. В продолжение предыдущей статьи рассмотрим, как с помощью Cisco TRex 3.06 провести комплексное тестирование производительности и функциональности сетевых устройств.
Итак, вы столкнулись с проблемой расширения традиционных систем хранения данных. С одной стороны, не хочется терять уже функционирующие внешние хранилища, с другой — модернизация требует значительных инвестиций и зачастую привязана к поддержке вендоров, которые больше не присутствуют на рынке. Функциональность, получившая название Unified Storage, решает эти проблемы.
Как можно догадаться из названия, речь идет о доступе к слою хранения, который уже существует внутри виртуальной инфраструктуры, но теперь его можно предоставлять внешним потребителям. Проще говоря, теперь мы можем «одолжить» место из существующих пулов и отдать его физическим хостам или другим виртуальным машинам внутри нашей инфраструктуры.
Давайте подробнее рассмотрим, как работает эта технология.
Посмотрев два видео PewDiePie, в которых он узнал об установке Arch (задача эта считается довольно сложной даже для любителей Linux) и о создании трёх проектов (камеры для собаки, устройства для получения информации о погоде/напоминания о питьевом режиме/медитаций и кто знает, что будет ещё) из опенсорсных напечатанных на 3D-принтере деталей, я стал размышлять о самостоятельном проектировании, своём хостинге и технологической независимости. Эти темы уже давно очень близки мне.
Когда меня спрашивают, как начать писать блог или как получить работу, я всегда говорю, что сначала нужно купить домен. Во-вторых, нужно хостить собственный веб-сайт блога, если вы обладаете техническими навыками (впрочем, сегодня это уже несложно). Я говорю так потому, что всё накапливается со временем. Разумеется, вы можете начать с готового блога и не принадлежащего вам URL, но если вы хотите заниматься этим на долгосрочной основе, то что будет дальше? Я видел, как многие люди скачут с WordPress на Medium, потом на Substack, потом на Ghost. Иногда они не выполняют миграцию своих постов, на написание которых было потрачено много времени, а просто создают новые.
Каждый раз они переходят на новый домен. Меня это очень печалит. Да, можно сказать, что они многому научились и что иногда лучше начинать с нуля, но представьте, что всё это происходило в течение десяти лет. Сравните это с десятилетним блогом, имевшим один и тот же домен, хранящим все накопленные трудами обратные ссылки, демонстрирующим долговременные вложения автора благодаря наличию старых постов, пусть и не столь хороших, чем современные. Мне кажется, разница может быть поразительной.
Я уже долгое время занимаюсь хостингом собственных трудов и каждый год добавляю что-то новое, поэтому решил, что стоит написать об этом краткую статью.
Изначально DevOps — специалист на стыке двух миров: разработки (DEVelopment) и эксплуатации (OPerations). Его задача — развертывать приложения и обеспечивать их бесперебойную работу, что включает в себя также заботу об инфраструктуре.
Я наблюдаю за развитием DevOps уже 13 лет. IT активно растет, девопсов требуется все больше. Так что сюда потянулись коллеги из смежных областей. Но в чистом виде ни одна из других специальностей не содержит полный набор требуемых навыков.
Сегодня размышляю, что так и что не так с разработчиками и сисадминами, которые устремились в DevOps (ну помимо идеи, что каждый должен заниматься своим делом).
В прошлом году мы сделали встроенную поддержку отказоустойчивости в Postgres Pro Enterprise — BiHA. Наше решение позволяет разворачивать отказоустойчивый кластер Postgres, в котором в случае сбоя пишущего узла новый пишущий узел (лидер) будет выбран автоматически.
В новой версии BiHA появилась возможность зарегистрировать пользовательские функции, которые будут вызваны при возникновении таких событий в кластере, как смена лидера, добавление/удаление ноды и других. Этот механизм мы назвали пользовательские колбэки. Разработчик программного обеспечения Postgres Professional Наталия Кокунина расскажет, как реализованы колбэки, и обсудит особенности их использования.
