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

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

К счастью, вы можете собрать его из практически всего, что можно хоть в какой-то степени назвать компьютером.

Реализация стандарта 6G находится на ранних этапах — Международный союз электросвязи, консорциум 3GPP и коммерческие компании все еще занимаются разработкой спецификации. Но регуляторы и телекомы уже готовятся к запуску, не желая повторять ошибки, допущенные при реализации сетей пятого поколения. При этом ожидается, что сети и устройства 6G будут плотно интегрированы с системами ИИ.

Недавно позвонил мне знакомый — у них в организации возникла потребность в файловом сервере. Первым делом я, конечно, предложил что-то проверенное, вроде готового решения от Synology. У меня уже был опыт настройки таких NAS — всё понятно, удобно и стабильно работает.

Правда, был ещё опыт с файловыми помойками на Windows Server — и, честно говоря, удовольствия от них немного. Всё как-то через одно место, да и смысла в этом особо не вижу, особенно для небольших задач.

Но тут всплыла старая добрая классика — «а можно подешевле?». Бюджет у организации ограничен, поэтому от идеи покупки NAS пришлось отказаться. Вместо этого предложил использовать уже имеющийся в офисе компьютер и собрать на нём свой файловый сервер.

Начал искать self-hosted решения. Наткнулся на TrueNAS — слышал о нём раньше, но не пробовал вживую. Решил развернуть тестовый вариант у себя в Proxmox: один виртуальный диск для системы, два других — под зеркалирование (RAID1). Немного покопался — и понял: вот оно.

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

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

Рациональное зерно в этом, конечно, есть. Случайные VPN-сервисы - особенно бесплатные, непрозрачные и обещающие «полную анонимность в один клик» - действительно могут оказаться сомнительным выбором. Когда весь ваш трафик идет через неизвестно чью инфраструктуру, вопрос доверия перестает быть теоретическим.

Но дальше обычно начинается привычная подмена. Из тезиса «не стоит пользоваться чем попало» очень быстро пытаются перейти к тезису «не стоит пользоваться ничем вообще». И вот это уже больше похоже не на заботу о безопасности, а на очередную попытку объяснить, что ограниченный интернет - это и есть нормальный интернет.

На практике все работает ровно наоборот. Чем больше ограничений, тем выше спрос на инструменты обхода. И если уж выбирать между случайным коммерческим VPN, бесплатным приложением с мутной моделью монетизации и собственным сервером, то self-hosted-вариант выглядит как минимум достойным внимания.

Поэтому дальше речь пойдет не о том, почему VPN - это страшно, а о том, как сделать его своим: развернуть self-hosted AmneziaWG с помощью install-скрипта и дополнить его веб-интерфейсом для управления пользователями.

Когда мы запускаем контейнер, в большинстве случаев предварительно нужно указать настройки: порт, пароль, режим работы, адрес базы и т. д. Зачастую такие параметры жестко прописывают в самом коде, но это плохой стиль и вообще идея так себе. В будущем вы можете «затроить» и все это слить в git-репозиторий. А как мы знаем, хранить чувствительные данные в там нельзя.

Удобнее и гибче использовать переменные окружения. Те самые, которые environment variables. С помощью переменных можно настраивать поведение контейнера, использовать разные конфигурации (dev/stage/prod), безопасно передавать чувствительные данные. Как видите, одни плюсы.

Работа с переменными в Podman строится практически так же, как в Docker. Есть некоторые нюансы, но о них расскажу чуть позже. Сейчас давайте потыкаем на практике и посмотрим, что же происходит.

Один AI-агент на базе Claude Sonnet закрывает 100% моих DevSecOps-задач. Без фреймворков, без оркестраторов, без векторных баз. Только LLM, операционная система и markdown-файлы. Рассказываю архитектуру, которая за этим стоит.

Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.

Я не собирался делать этот проект.
Просто однажды сломал систему — и понял, что rollback на ext4 не такая простая вещь, как кажется.

В итоге собрал своё решение на rsync: быстрый и предсказуемый откат без смены файловой системы.

Кода тут минимум — он на GitHub. В статье — про сам подход: проблему, попытки решения и итог.

После ухода с рынка исторических лидеров в области складского оборудования выбор терминала сбора данных (ТСД) стал сложной практической задачей. Появилось множество новых брендов и моделей, и оценивать их только по техническим характеристикам из каталогов оказалось недостаточно. Потребовалась система оценки, основанная на понимании реальных складских процессов.

Мы, INTEKEY, с 2017 года автоматизируем склады. Наш опыт работы с лидерами рынка позволил сформировать чёткий стандарт требований к оборудованию. Когда привычные решения стали недоступны, мы последовательно применили этот стандарт для поиска и тестирования новых партнёров. 

В этой статье разберем:

- наш метод оценки ТСД, основанный на анализе поведения устройства в реальных рабочих условиях

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

- какой путь мы прошли, выбирая партнеров после ухода с рынка исторических лидеров, и на каких брендах остановились

- примеры моделей под разные роли на складе;

- практические аспекты интеграции: какие особые требования появляются при работе с маркировкой «Честный знак»

Представьте: у компании 300 подразделений по всей стране или пять производственных площадок от Москвы до Дальнего Востока. Как узнать, сколько реально ноутбуков в омском филиале, где они находятся и в каком статусе принтер, купленный два года назад: используется, неисправен, в ремонте или уже подлежит списанию? Если данные приходят через мессенджеры или эксельные файлы, присланные раз в квартал — вы уже в зоне риска.

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Недавно я написал две статьи, посвящённые настройке /etc/config/wireless в OpenWrt. В одной я разобрал настройки секции wifi-device, а в другой wifi-iface. Но этого оказалось мало, и в комментариях меня спрашивали о тонкостях настройки mesh-сети. Что ж, спешу выполнить эту просьбу и представляю на ваш суд наиболее полный гайд, посвящённый сборке и настройке Wi-Fi mesh-сетей на базе OpenWrt.

Но прежде чем перейти к повествованию, хочу сделать важные оговорки.

Первое. Из комментариев я заметил, что, говоря о mesh-сети, пользователи имеют в виду несколько разных вещей. Поэтому эта статья будет написана от простого к сложному от самых азов к тонкостям настройки. В начале я немного по‑теоретизирую, расскажу о mesh-сетях и топологии, о том, как их лучше спроектировать и расположить роутеры, и уже дальше перейду к тонкой настройке конфигурационных файлов. Поэтому если вы считаете себя опытным пользователем, смело пропускайте начало статьи и сразу переходите ко второй её половине.

Второе. Статья получилась достаточно большая и может вас утомить. Я долго сомневался, стоит ли делать большую статью или всё же разделить на разные темы. Например, вынести отдельно часть про роуминг и отдельно про настройку конфигов. Но в итоге решил, что полезнее будет иметь полное руководство в одном месте. В конце концов, главная цель этой статьи показать, что при должном уровне настройки беспроводные mesh-сети ничуть не уступают кабелю. Мне по роду занятий часто приходится слышать замечания коллег, которые говорят: «Да всё беспроводное и mesh это фигня, нет ничего лучше кабеля. Вот я купил домой mesh-систему всего из трёх узлов, а она не работает как нужно». Забегая вперёд, хочу сказать, что если всё сделать как надо, можно добиться небывалой производительности. Не без гордости могу заявить, что в моём арсенале есть mesh-сети, состоящие из более чем 50 узлов, построенные исключительно на OpenWrt и без использования внешних контроллеров.

31 марта 2026 года наружу буквально вывалились исходники Claude Code (через sourcemap в npm‑пакете). История уже сама по себе комичная: продукт, который помогает писать код и в теории должен быть особенно аккуратен с публикацией артефактов, случайно публикует не просто кусок дебажной информации, а почти анатомический атлас самого себя.

Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос: что там внутри? Если убрать обычное для таких случаев «вау, утекло», остаётся более интересная интонация: ну‑ка, посмотрим, что тут у нас (или «там у них»?) и нормально ли там написан код.

Привет, Хабр! Мы — команда Cozystack, open-source платформы для построения облаков на своём железе. Хотим рассказать, почему мы решили целиться в направление игровых серверов и что из этого вышло.

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

Я понимаю, что это прозвучит максимально странно в тексте, посвящённом протоколам и архитектурным решениям. Но вот в чём дело: организационная сторона таких сетей важнее технической. Истинная, глубинная природа компьютерных сетей — социальная. Всегда.

Чтобы пакет добрался из точки А в точку Б через государственную границу — через барьер, через фильтр, через ограничение — по ту сторону должен быть кто-то, кто готов его принять. Узел. Человек. Связь. Сеть держится не на протоколах — она держится на доверии между людьми, которые решили её построить. Протокол — это язык. Но прежде чем говорить, нужно захотеть слушать друг друга.

Если вы читаете эту статью в поисках готового рецепта построения защищенной приватной и устойчивой к обнаружению сети — должен вас разочаровать. У меня его нет.

Всё, что у меня есть — это базовое понимание того, как устроены компьютерные сети. Всё, о чём я пишу в этих статьях, — не тайное знание, не инсайт от внутренних источников и не результат секретных исследований. Всё это можно прочитать в любом учебнике «Компьютерные сети» — прямо сейчас, во всех магазинах страны.

Единственно стоящим вариантом, чувствовал я, будет зарегистрироваться на Хабре, обдолбаться до озверения, proxyярить по вайбкодингу и сделать репортаж.

Всем привет! Меня зовут Эрик, я инженер технической поддержки в Ринго. Сегодня поговорим об истории операционной системы macOS. О том, как она развивалась с 1989 года и стала одной из самых технологически зрелых ОС на рынке и что происходит с ней прямо сейчас.

macOS — операционная система для компьютеров Mac, разрабатываемая Apple с начала 2000-х годов. macOS лежит в основе всей экосистемы Apple на стороне рабочих станций. Она тесно интегрирована с iOS, iPadOS, watchOS и tvOS, а её архитектурные решения напрямую влияют на то, как устроены iPhone и iPad.

Если коротко, macOS — это Unix-подобная операционная система с открытым ядром, богатой историей архитектурных переходов и одной из самых строгих в индустрии политик обратной совместимости. 

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок.

В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене.

Классическая архитектура сетевой безопасности строилась вокруг одной предпосылки: существует чёткая граница между «внутри» и «снаружи». Межсетевой экран нового поколения (NGFW) стоит на этой границе и инспектирует трафик. Модель работала, пока сотрудники сидели в офисе, приложения — в корпоративном ДЦ, а удалённый доступ оставался исключением из правил.

Сегодня, особенно в эпоху «после ковида» и во времена рассвета облаков, это уже не так. Мы в Айдеко сами живем «гибридной» реальности с 2021-го года: работая полностью распределенной по всей России командой 300+ сотрудников в гибридной цифровой среде (где множество сервисов в облаках, но есть и локальные устройства и серверы связанные с необходимостью работы с «железом» ПАК‑ми, стендами для нагрузочного тестирования NGFW и т.п.).

Наша цель — предоставить корпорациям решение для организации безопасной работы с современной ИТ‑инфраструктурой где бы не находились сотрудники: на удаленке, в командировке, в офисе или других странах.

Классический NGFW в таких условиях остается необходимым — но его одного уже недостаточно.

Ответом индустрии стала архитектура SASE (Secure Access Service Edge), предложенная Gartner в 2019 году. SASE объединяет сетевые и security‑функции в единую облачную платформу. Глобальные вендоры уже перестроили свои продуктовые линейки: Palo Alto Networks развивает Prisma SASE, Fortinet — FortiSASE, Zscaler выстраивает cloud‑native SSE‑платформу. По данным Gartner, к 2028 году 50% SASE‑развёртываний будут базироваться на решении одного вендора — с 30% в 2025 году. Консолидация ускоряется.