Бросил tmux и написал свой инструмент
Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.
Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

Существует несколько различных протоколов, предназначенных для обеспечения бесперебойной работы сети на канальном уровне. Сегодня мы рассмотрим Ethernet Ring Protection Switching – технологию, обеспечивающую высокую доступность и отказоустойчивость в кольцевых топологиях.

Привет, Хабр! Меня зовут Никита Чубаров. По трудовому договору я инженер-эксперт по разработке и сопровождению сервисов, а по факту DevOps-инженер с фокусом на доставку в платформенных командах, которые поставляют общие решения для десятка дочерних команд. Со временем эта доставка перестала быть прозрачной и предсказуемой, и всё больше напоминала космолёт, в котором пилот перед каждым запуском вручную подключает провода, проверяет давление в контурах и по списку нажимает десятки кнопок. Пока запусков мало, это ещё можно представить, но когда их становится сотни, а кораблей — десятки, такая схема быстро превращается в источник ошибок и выгорания.
Примерно в таком состоянии у нас находился Bootstrap Namespaces. В статье я расскажу, как мы прошли путь от сложной CI-оркестрации к декларативному управлению Bootstrap Namespaces через Argo CD и GitOps, какие проблемы это позволило убрать и какие новые ограничения пришлось принять.

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

В этой статье мы продолжаем разбирать возможности веб‑сервера Angie по борьбе с DoS (и немного DDoS) атаками. В предыдущей части мы разобрали стандартные средства, а в этой обсудим возможности сторонних модулей и системы Fail2Ban.

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Исходя из моего опыта, могу сказать, что большинство обладателей OpenWrt-роутеров используют для настройки беспроводных интерфейсов достаточно удобный веб-интерфейс LuCI. И только продвинутые пользователи рискуют править конфиги вручную. Но, как правило, даже они часто ограничиваются лишь указанием основных данных: типа стандарта, канала и, собственно, настроек самой Wi-Fi сети. И совершенно зря, так как wireless-конфиг имеет множество самых разнообразных параметров, позволяющих при правильном использовании увеличить покрытие сети или скорость в несколько раз. В этой статье разберем точную настройку файла /etc/config/wireless в OpenWrt, направленную на создание максимально стабильного покрытия Wi-Fi сети. И посмотрим на предрассудки, которые сложились относительно некоторых параметров. Особенно подчеркну, что мы не будем разбирать все параметры (их действительно очень много), а ограничимся только обозначенной задачей.

Привет, Хабр.
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен» — системы учета и контроля ИТ-инфраструктуры. В этой статье хочу разобрать одну из самых устойчивых и при этом недооцененных проблем корпоративных ИТ — несанкционированную установку программного обеспечения, Shadow IT.
Во многих компаниях такие установки до сих пор воспринимаются как частный вопрос дисциплины: кто-то поставил лишнее, кто-то обошел регламент. На практике это не отдельные инциденты, а системное явление, которое напрямую влияет и на безопасность, и на управляемость инфраструктуры.
По нашим наблюдениям, в значительной части организаций сотрудники самостоятельно устанавливают рабочий софт, не проходящий централизованное согласование. Причем речь идет не только о специализированных инструментах, но и о вполне привычных вещах: офисных приложениях, утилитах для обмена файлами, удаленного доступа, аналитики и совместной работы.
Важно понимать: в большинстве случаев здесь нет злого умысла. Причины почти всегда лежат в устройстве процессов. Бизнес развивается быстрее, чем ИТ-регламенты, и людям нужно решать задачи здесь и сейчас. При этом согласование нового ПО может занимать дни или недели. Отдельный фактор — работа с подрядчиками, которые устанавливают их в инфраструктуре заказчика привычные им инструменты.
Еще один распространенный сценарий — передача техники между подразделениями. Устройство меняет владельца, а установленное ранее ПО остается без пересмотра. В результате в инфраструктуре постепенно накапливается слой неучтенного и неавторизованного программного обеспечения.

Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.
У компании были современные импортные станки с проприетарным софтом, дорогим обслуживанием. Непрерывное круглосуточное производство. Но собственная IT-инфраструктура была слаба – всего несколько разработчиков, а аналитики бизнесовые. Всё же бизнесу нужно было следить за оборудованием: кто работает, кто простаивает, кто отключает датчики. Крайне необходимо было снизить вероятность поломок и простаивания.
В статье расскажу, как «на коленке» собрали многомодульную систему.
На почти каждой Linux-машине в мире живёт один маленький бинарник. Весит несколько мегабайт, несколько десятков тысяч строк кода, поставляется со своим собственным конфигурационным языком, и CVE-шек за ним накопилось столько, что хватит на хорошую таблицу с фильтрами. Большинство из нас запускает его по десятку раз в день, не задумываясь.
Этот бинарник — sudo.
В мире Docker-контейнеров, эфемерных CI-раннеров и Kubernetes-подов, которые живут тридцать секунд и умирают без предупреждения, большая часть того, что умеет sudo, попросту не нужна для той работы, ради которой мы его вообще вызываем.
Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

Монолит без тестов.
Деплой только ночью.
Пять минут гарантированного простоя на каждом релизе.
Логи — в файле.
О проблемах узнаём от клиента.
Малый/средний бизнес МФО, без отдельного DevOps-инженера.
“Специально обученный тимлид”, который знает, какие костыли подпирают систему.
Рассказываю, как из этого получился production baseline: Kubernetes, GitLab CI/CD и наблюдаемость, после которых релизы стали скучными.

Продолжим разбирать тему параллелизма для баз 1С, но сегодня разговор будет не о MS SQL, а о PostgreSQL. Принципы работы тут отличаются, поэтому нужно пояснение.

Три года назад я написал статью “Интернет-цензура и обход блокировок: не время расслабляться”. Перечитывая ее сейчас, спустя три года, не могу избавиться от двоякого чувства: с одной стороны я почти во всем оказался прав касательно того, как будут развиваться события, усиливаться блокировки, и регулироваться законодательство. С другой стороны, кое в чем я тогда серьезно ошибся.
А именно: слишком уж я надеялся на то, что доблестные фильтраторы интернета будут заботиться об уменьшении побочных эффектов и так называемого collateral damage, и поэтому будут вынуждены изобретать более сложные технологии детектирования, продолжая увлекательную игру в кошки-мышки. Реальность же оказалась гораздо прозаичнее: зачем думать, когда в руке кувалда? В результате чего имеем следующее: часть детектирования откровенно тупая (например, блок нескольких параллельных подключений к одному IP, что решается использованием gRPC-транспорта для VLESS или XHTTP-транспорта с правильными настройками мультиплексирования), а часть - еще тупее, а именно, никакого детектирования, а тупо бан популярных хостеров и облачных провайдеров целыми подсетями /16 и даже /8 - в результате чего или нельзя подключиться по TLS вообще, или можно, но соединение фризится после передачи примерно 16 килобайт данных, или же блок срабатывает на целую подсеть после случайного обращения к какому-нибудь “плохому” IP-адресу. За анализ огромное спасибо товарищу @0ka и его статьям “РКН создали белый список для 72 AS, но пострадали 391 AS (>225 млн IP адресов)” и “РКН создали список подозрительных айпи адресов (динамическая блокировка 47 AS)”.

Хостинговые компании России устранили старые проблемы. Большинство хостингов стабильно держат соединения с крупными интернет-провайдерами (BGP-сессии с аплинками) и правильно объявляют свои IP-адреса в глобальной сети (route-объекты). Клиенты получают сервис высокого уровня без лагов.
Однако все эти достижения могут в один момент разлететься на кусочки.

Когда почта ложится — ложится всё. Переписка, задачи, согласования, доступы — всё завязано на почтовый сервер. А если под ним единственный PostgreSQL без резервирования, то между вами и катастрофой — один сбойный диск или зависший процесс.
В этой статье — пошаговый рецепт: собираем отказоустойчивый кластер PostgreSQL на базе Patroni, используем etcd для консенсуса и HAProxy как единую точку входа. Три виртуальные машины — и ваша почта RuPost переживёт падение ноды без потери писем и без ручного вмешательства.

Продление договора — через три месяца, но поставщик уже знает, что вы никуда не уйдете. Это и есть vendor lock-in — зависимость от вендора. С ней сталкиваются гораздо чаще, чем принято думать.
Конечно, ITAM-специалисты могут заметить надвигающуюся проблему: у них на руках данные по активам и договорам, статистика использования и календарь продлений. Проблема в том, что зависимость от вендора чаще всего не воспринимается как риск, пока не становится поздно что-либо менять. Тогда простая процедура закупки ПО на замену текущему превращается в крупный проект, который требует отдельного бюджета и многоэтапного плана миграции.
Это руководство поможет выявить, разложить по полочкам и взять под контроль зависимость от вендора — до того, как она начнет управлять вашим бюджетом.

Трудно представить современный компьютер или смартфон без тысяч файлов, хранящих в себе различную информацию. Иногда возникает необходимость что‑то найти в этом многообразии, причем критерии для поиска могут быть совсем не тривиальными.
В качестве одного из возможных инструментов для поиска может применяться утилита grep. Grep (сокращение от global/regular expression/print) является одним из самых мощных и часто используемых инструментов в арсенале системного администратора и разработчика. На первый взгляд, её задача проста — найти строки в тексте, соответствующие шаблону. Например, вхождение какого‑либо слова в текстовом файле Однако истинная мощь grep раскрывается при использовании регулярных выражений (regex).
В этой статье мы разберём три основных типа регулярных выражений, используемых в экосистеме grep: Basic (BRE), Extended (ERE) и Perl‑compatible (PCRE) и рассмотрим несколько практических примеров.

Всем привет! Меня зовут Эрик, я инженер технической поддержки в Ринго.
Если вы администрируете Mac в корпоративной среде, то рано или поздно сталкиваетесь с загадочными сущностями: Secure Token, Bootstrap Token, volume owner, OIK, KEK, VEK.
Проблема в том, что официальная документация Apple описывает их корректно, но сухо и редко объясняет, как всё это связано между собой на практике. В итоге админ узнаёт о Secure Token не из документации, а когда:
— пользователь не появляется на экране FileVault,
— MDM не может включить FileVault или выполнить Erase All Content,
— обновление macOS требует «volume owner»,
— а Recovery внезапно никого не пускает менять настройки загрузки.
Постараемся разобраться поэтапно, что такое Secure Token, что лежит внутри, как он связан с Bootstrap Token и при чем тут MDM.
Статья подготовлена на основе документации Apple, включая Apple Platform Security, доклада Арека Дрейера на конференции MacSysAdmin и ряда дополнительных источников.

Ровно 19 лет назад, 30 января 2007 года, Microsoft выпустила Windows Vista — систему, которую технологическое сообщество постаралось забыть как страшный сон. Медленный, глючный, требующий огромной вычислительной мощи, которой не было ни у кого, сон. Ну, во всяком случае так казалось тогда. Хотя, если честно, то и сейчас кажется. Мем про медлительность Vista по праву стал частью IT-истории – на одном уровне с KDE2 и FreeBSD. Но стоит копнуть чуть глубже, и начинаешь понимать, что все было не так однозначно.

Привет, Хабр!
Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Несколько лет назад, пока облако росло, интеграционный слой между сервисами и брендами естественным образом усложнялся. Каждый новый сценарий требовал отдельного решения — и со временем стало понятно, что нужен общий подход.
В этой статье расскажу, какие решения мы приняли, от чего отказались и где сознательно не стали усложнять систему.

VMware не идеальная система. Исторических костылей там столько, что впору писать отдельную статью, и некоторые архитектурные решения заставляют задуматься о количестве пива на той встрече, где их принимали. Но за двадцать пять лет VMware сделала штуку, которую пока никто не повторил: собрала экосистему, в которой сложное выглядит простым. А когда сложное выглядит простым, люди забывают, насколько оно сложное, и начинают рисовать план миграции на квартал.
Broadcom купила VMware в конце 2023-го за 61 миллиард и перекроила лицензирование. Рынок зашевелился. Каждый второй вендор выпустил пресс-релиз про «замену VMware». Прошло два года. Полностью мигрировали 4%. Четыре процента. Аналитики прогнозируют, что к 2028-му уйдёт 35% рабочих нагрузок — не компаний, а нагрузок. Большинство организаций, даже уходя, будут жить с VMware на части инфраструктуры ещё годы. Эта статья про то, почему четыре.
Я проектирую и эксплуатирую enterprise-платформы виртуализации и VDI, и мне есть что сказать про то, как оно устроено на самом деле.