Заголовки играют важную роль в работе веб-приложений. Они уточняют свойства запроса или ответа, управляют кэшированием, отвечают за безопасность и помогают отслеживать проблемы. В этой статье посмотрим, как можно управлять заголовками запросов и ответов в сервере Angie.
Слышит ли вас робот прямо сейчас? А если микрофон «отвалился» — как быстро вы об этом узнаете?
Штатный микрофон гуманоида Walker Tienkung предполагает, что оператор стоит в полутора метрах перед работающей машиной ростом 173 см — неудобно и небезопасно. Мы взяли недорогую беспроводную петличку и думали, что задача решается за вечер: воткнул USB, написал pip install, готово. Реальность: выведенный наружу порт нашёлся только на другом бортовом компьютере, звук пришлось гнать по сети, а приёмник в случае любой неисправности отвечает одинаково — молча шлёт нули. Сел аккумулятор, выключили передатчик, выдернули донгл — для софта всё это неотличимо.
Рассказываем, как мы научили робота самому замечать, что он оглох, и говорить об этом голосом: диагностика по тишине, пять состояний аудиотракта, подсказки оператору, которые пришлось переписывать, потому что «технически верно» и «понятно человеку» — разные вещи. И как починили переподключение за десять секунд вместо двух из-за системного сервиса.
Каждый, кто работает в терминале, держит открытыми сразу несколько вкладок: в первой смотрит логи, во второй следит за списком запущенных процессов через htop, в третьей работает с Git, в четвертой запускает миграции базы данных. При переключении между вкладками легко запутаться, закрыть нужную, а при обрыве связи — потерять запущенные процессы и сессии.
Привет! Я Саломея, продуктовый технический писатель в Selectel. В этой статье поделюсь своим опытом, как с помощью tmux упорядочить этот хаос и сделать работу удобнее. Разделим окно терминала на панели, запустим сессию, которая не прервется при закрытии окна, автоматизируем настройку рабочего пространства. Посмотрим, как выполнять команду сразу на нескольких серверах.
Эта статья является прямым продолжением этой статьи, посвящённой декларативной разметке диска через disko.
Что мы будем делать сегодня?
Мы с вами составим минимально-рабочий конфиг для нашей системы. Под "минимально-рабочим" я имею в виду: без графического окружения(XFCE, GNOME и прочее), углублённых настроек(установка zsh, например). Мы настроим: загрузчик, сеть, пользователя, звук, локализацию, подключим наш файл disko-config.nix.
Я уже рассказывал, как можно собрать минимальный Linux под различные архитектуры. Также я описывал свой эмулятор известной игры «Ну, Погоди!». В этой статье я хочу рассказать, как создать дистрибутив Linux с моим эмулятором, который будет работать в режиме киоска.
Вы сталкивались с операционными системами, работающими в режиме киоска, когда снимали деньги в банкомате, взвешивали продукты в супермаркете или покупали товар на кассе самообслуживания.
В твиттере уже несколько дней не утихают споры по поводу Omarchy — Linux дистрибутива от создателя фреймворка Ruby on Rails. Дистрибутив недавно получил крупное обновление 4.0 Quattro, но не оно стало причиной дискуссий. Создатель основал некоммерческую организацию Omacom Foundation и привлёк 8 миллионов долларов (уже 10) на развитие и поддержку дистрибутива. Проект уже объявил[1][2], что будет спонсировать разработку двух проектов, на которых основан — Hyprland и quickshell чтобы их создатели могли свободно продолжать работу над своими проектами, не думая об источнике финансирования.
Это вызвало споры в сообществе о полезности дистрибутива:
Энтузиасты считают, что дистрибутив создаёт импульс, который приведёт в Linux новых пользователей
Скептики указывают на отсутствие фундаментальной ценности в дистрибутиве (Arch Linux с предустановленными настройками и приложениями) и наличие уязвимостей.
Так кто же из них прав? Сначала приведу короткую информацию о дистрибутиве, аргументы обеих сторон, которые видел, и в конце приведу своё мнение по поводу полезности дистрибутива для сообщества. Сразу скажу - я не пробовал Omarchy, но настольным Linux пользуюсь больше 10 лет и вопросы, поднимаемые в этой дискуссии, не специфичны для дистрибутива, просто он спровоцировал новый виток их обсуждения.
Каждый, кто хоть раз устанавливал Linux вручную, знает этот ритуал: загрузиться с Live‑образа, запустить fdisk или parted, создать таблицу разделов, отформатировать их в btrfs/ext4, создать субтома, а затем вручную примонтировать всё это в /mnt.
Конечно, такой подход можно использовать и при установке NixOs. Но вопрос — зачем?
Это не только полностью противоречит самой сути NixOS — системы, где всё должно быть описано декларативно в коде, но и существенно влияет вообще на удобство использования этой системы в будущем. Стоит вам захотеть развернуть точно такую же конфигурацию на другом сервере или ноутбуке, и весь ручной процесс разметки приходится повторять заново, вспоминая точные флаги монтирования вместо того, чтобы написать всего лишь одну команду.
В этой статье мы этим вопросом и займёмся, а поможет нам в этом известная утилита disko. Мы напишем чистый декларативный конфигурационный файл в ДВУХ вариантах:
Рука промахивается на Ctrl+Shift+W — и окно с полусотней вкладок закрывается без вопросов. Единственное, что заставляет Яндекс Браузер переспросить, — активная загрузка. Так что теперь systemd кормит мой браузер загрузкой, которая не кончается никогда: 0,4 МБ памяти, 64 КБ на диске, один байт по loopback раз в пять минут. Как я до этого дошёл, почему не спасают настройки и расширения и как тесты чуть не убили то, что защищали, — под катом.
Привет, Хабр! В работе почти каждого, кто плотно сидит в Linux, есть один недостаток: одни и те же команды забываются с завидной регулярностью. Я, например, иногда по десять раз лезу в историю, чтобы уточнить - «так как в rsync директорию исключить, но структуру оставить?»
Можно, конечно, вести свои заметки. Можно - дрессировать Ctrl+R. А можно установить небольшую утилиту, которая будет жить в трее и выдавать нужную подсказку за полсекунды. Именно о такой утилите сегодня и расскажу - DevToolbox Cheats.
Многие знают и используют контрольную панель ispmanager для управления сервером, но, возможно, не всем известно, что функционал работы панели можно расширить самостоятельно и адаптировать для выполнения своих специфических задач.
В этой статье я хочу показать, как можно расширить возможности ispmanager — с помощью механизма плагинов. Они позволяют добавлять в панель собственный функционал: новые пункты меню, формы, отчёты, автоматизированные действия до и после стандартных операций, а также выводить данные из внешних систем прямо в интерфейс панели.
Предлагается доработать ispmanager, а именно:
Уже второй сезон я строю дом. На этапе подведения коммуникаций появилась идея сразу проложить оптику от провайдера, чтобы потом не курочить стены. Сказано — сделано. Подключив пустую коробку к Интернету, я сразу задумался о том, что это отличный испытательный полигон для разных датчиков и подобного оборудования умного дома. Пока там никто не живёт, отвал или глюки датчиков никаких неудобств не вызовет, а скорее даст полезную информацию и опыт внедрения. Опять же, пока стены не отделаны, никаких проблем "быстро и грязно" протянуть кабели для Ethernet и RS-485 по месту в целях тестирования оборудования.
Сервер отвечает с задержкой, сайт еле открывается, а причина нагрузки неочевидна. В статье разберём пошаговую диагностику Linux‑сервера: как проверить CPU, память и диск с помощью top, free, vmstat, iostat и iotop, найти процесс‑виновник и понять, куда копать дальше.
Переменные в сервере Angie используются для расширенного управления обработкой запросов, более гибких конфигураций, а также получения подробной информации о клиентах и запросах. Постараемся разобраться со всем спектром возможностей переменных в Angie.
Всем привет! Меня зовут Илья, я frontend‑разработчик.
Но сегодня хочу поговорить не о JavaScript, а о терминале.
Несмотря на то, что я уже много лет работаю разработчиком, активно пользоваться терминалом я начал всего около года назад. До этого терминал для меня был просто местом, где запускается сборка проекта, немного Git и иногда еще пара команд. Думаю, у многих так же.
Обычно мысли о терминале вызывают ступор. Кажется, что это что‑то непонятное, черно‑зеленое и предназначенное только для «настоящих программистов», и на практике большинство ограничивается npm run dev, git status и на этом все.
В этом гайде я хочу показать, как можно превратить терминал в красивую и удобную среду разработки, которая не уступает IDEA и другим редакторам.
Сразу оговорюсь: речь пойдет исключительно о терминале, а не о NeoVim.
NeoVim — это отдельная большая тема.
Добавляете нового пира на сервер WireGuard — и у соседнего в wg show вместо префикса появляется allowed ips: (none). Команда отработала успешно, dmesg пуст, wg-quick промолчал, туннель up, handshake свежий. А если бы у нового пира маска была /32 вместо /24, ничего бы не произошло.
Это ловят снова и снова: в трекере VyOS с 2020-го (закрыто как Invalid — «так делает ядро»), в OPNsense в 2025-м, на форуме OpenWrt каждый раз, когда к серверу добавляют второй телефон.
Разбор по drivers/net/wireguard/ мейнлайна, тег v6.12: почему AllowedIPs вообще не хранится у пира, что делает list_move_tail в allowedips.c:201, почему симптом «пропало у одних пиров, но не у всех» объясняется одной строкой parent->cidr == cidr, и откуда берётся ping: sendmsg: Required key not available, если вы его когда-нибудь видели и решили, что это про ключи шифрования.
И заодно: то же самое лежит в FreeBSD, OpenBSD, BoringTun, wireguard-go и в драйвере под Windows — шесть кодовых баз, пять разных структур данных, один и тот же молчаливый контракт. А MikroTik, который запрет прямо задокументировал, сам его не проверяет: на CHR оба пира показывают префикс, трафик идёт одному, и вернуть его второму можно только записью того же самого значения обратно.
Плюс способ проверить самому: настоящий allowedips.c из ядра, собранный в userspace одним gcc. Без модуля и без root.
В этой статье я покажу, как настроить свой почтовый сервер для аккаунтов локальных пользователей без веб-морд, docker-ов, телеграм-помоек и LLM-высеров.
Всем привет! Сегодня я хочу вам рассказать о Peertube — некоммерческой децентрализованной видеоплатформе с открытым исходным кодом. В нем есть возможность загрузки контента, комментирования, поиска, а также изменения видео, когда оно уже опубликовано.
Peertube основан на технологии P2P (peer-to-peer) для обмена видео по принципу всех известных торрентов. Исторически PeerTube использовал WebTorrent, но уже несколько лет (начиная с версии 6.0) проект полностью перешел на протокол HLS в связке с WebRTC.
Что лучше — централизация или децентрализация? Что такое Fediverse? И наконец — как создать свой инстанс-сайт для сохранения видео на случай, например, блокировки ютуба? Давайте-ка погрузимся в теорию и практику!
В конце концов мы опубликуем свой децентрализованный видеохостинг!
Пока идёт бинарный апгрейд nginx, systemctl reload nginx не применяет конфиг так, как вы думаете: в лучшем случае к половине процессов сервера, в худшем — вообще никуда. Код возврата ноль в обоих случаях, в error.log пусто. Что именно у вас — решает одна строчка в юните: -s reload бьёт по pid-файлу, а он после USR2 принадлежит новому мастеру; kill -s HUP $MAINPID бьёт по старому, а тот конфиг вообще не перечитывает, и это описано в документации nginx — в разделе про обновление исполняемого файла, куда по другому поводу не заходят.
Это первая из пяти проверок. Я взял пять ходовых утверждений про reload в nginx, померил каждое на стенде — и получил результаты по обе стороны: три подтвердились, два развалились. Развалившиеся оказались интереснее.
Не работают ровно те страшилки, что про слушающий сокет: listen ... reuseport бесшовность не ломает (inode’ы сокетов до и после reload одни и те же — их держит мастер, а не воркер), паузы в accept при reload не существует вовсе (msleep(100) стоит ПЕРЕД QUIT), а значит и арифметика про переполнение backlog на reload — про нагрузку, а не про reload.
Зато подтвердилось то, о чём почти не пишут. keepalive_min_timeout оставляет уходящего воркера в живых, и тот обслуживает запросы, которых в момент reload ещё не существовало — по старому конфигу. А ngx_close_idle_connections не различает направление соединения, поэтому каждый reload сбрасывает пул keepalive к бэкендам — и с 1.29.7 это касается всех, у кого есть блок upstream: пул там включён по умолчанию, 32 соединения на воркер.
Правило из первой части — «соединение, открытое до reload, нового конфига не увидит» — приходится переформулировать: держится старого конфига не соединение, а процесс.
В конце — Traefik, у которого reload’а нет вовсе, и который умеет не применить конфиг своим способом: кольцевой буфер на одно сообщение и двухсекундный дроссель.
nginx release-1.31.3, traefik v3.7.10, все опыты в репозитории, запуск одной командой.
Деплой делает nginx -s reload. Команда возвращает ноль, nginx -T показывает новый конфиг, в error.log ровно одна строка — reconfiguring. А keep-alive соединение, открытое секундой раньше, в этот момент закрывается.
Само по себе это не ошибка: сервер вправе закрыть простаивающий keep-alive когда угодно. Ошибку даёт гонка — FIN уходит в тот момент, когда клиент уже записал в сокет следующий запрос. Идемпотентный он повторит, POST — нет.
Разбор по исходникам на фиксированных тегах: nginx release-1.31.3, httpd 2.4.68, traefik v3.7.10, плюс замер всех четырёх (с HAProxy) на одном стенде в одном прогоне. Выясняется, что мастер nginx конфиг не перечитывает вообще: он строит новый цикл целиком и форкает новых воркеров, а старым остаётся ровно то, что у них было. Apache приходит к тому же контракту через счётчик поколений, HAProxy — через замену процесса. А у одного из четырёх второй запрос в том же самом сокете возвращает уже новый конфиг — и причина не та, о которой вы подумали.
Внутри: почему документация nginx сама создаёт половину недоразумения; почему WebSocket и SSE не попадают под ngx_close_idle_connections и держат старого воркера сколько угодно долго, а HTTP/2 попадает всегда и получает GOAWAY; как сигнал родителя у Apache доезжает до конкретного соединения через пять звеньев; и таблица из двенадцати клеток, в которой четыре реализации расходятся ровно в одной.
Со стендом (один docker build, один docker run), полными выводами ps и тремя claims-*.tsv, где каждое утверждение о коде проверяется скриптом.
Cегодня мы опишем сценарий развёртывания КОМПАС-3D для технических специалистов, работающих с операционной системой «Альт Рабочая Станция 11». В нашем материале эта система будет использоваться как для сервера локального репозитория, так и для клиентских машин.
Мы покажем последовательность действий на примере КОМПАС-3D, но общий сценарий сработает и для других приложений. В частности, точно таким же способом можно поставить любые доступные в публичном репозитории продукты Комплекса АСКОН.
Мы разыграем полноценный сценарий развёртывания приложений в закрытой сети в два этапа. В первой части имитируем работу из внешней сети: покажем репозитории-источники приложений, разберём их подключение и выгрузим все необходимые пакеты на внешний носитель. Далее этот внешний носитель пройдёт воображаемую проверку безопасности, и его содержимое будет передано в закрытый контур.
Затем мы завершим наш сценарий из внутренней сети: развернём локальный репозиторий с полученными пакетами и установим приложения на машину в закрытом контуре нашего воображаемого предприятия.
