Настройка Linux *

В этой статье я покажу, как настроить свой почтовый сервер для аккаунтов локальных пользователей без веб-морд, 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, но общий сценарий сработает и для других приложений. В частности, точно таким же способом можно поставить любые доступные в публичном репозитории продукты Комплекса АСКОН.

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

Затем мы завершим наш сценарий из внутренней сети: развернём локальный репозиторий с полученными пакетами и установим приложения на машину в закрытом контуре нашего воображаемого предприятия.

server a.internal weight=10 max_fails=2; — десять к одному. Ночью бэкенд на пару секунд отвалился, к утру давно жив и из ротации не выведен. А первые полсотни запросов рабочего дня распределяются не 10:1, и среди них есть места, где два запроса подряд уходят на сосед с весом единица.

Ни один лог об этом не скажет, в документации по upstream такого объяснения нет. Есть — в двух строках ngx_http_upstream_round_robin.c.

Разбираем по тегу release-1.31.3, со ссылками файл:строка: smooth weighted round-robin и его восемь копий в исходниках; effective_weight, которого нет в документации, и то, как max_fails втихую им управляет; почему least_conn сравнивает не число соединений; почему ip_hash не работает на unix-сокетах. Плюс sticky и least_time, приехавшие в open source несколько месяцев назад.

Обзоров VPS на Хабре хватает, но почти все сделаны Windows-утилитами и сводятся к тому, какой диск показал «отличный результат». Мне же нужна была батарея, которую можно прогнать по SSH на любой машине, и понимание, что конкретно означает каждое число.

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

Поэтому в этой статье: сначала стенд и методика, потом грабли по ходу замера, потом результаты. Ну и длинный список оговорок в конце.

Весь мой путь в Linux начался в студенческие годы, в момент, когда я получил предложение о работе от своего преподавателя в универе. Оказалось, что помимо преподавательской работы он также трудился в IT-компании, которая на тот момент искала интернов.

Собеседование заняло 10 минут, без единого вопроса про системы хранения или задачи с кодом. Мы просто поздоровались, технический директор Павел выдал мне доступы и объяснил суть: за полгода мне нужно пройти три модуля, по два месяца на каждый, удаленно с возможностью работать из офиса — путь от «понять, как устроено ядро» до «написать драйвер под реальное железо и собрать прошивку под FPGA».

Я дважды стирал себе диск, ради стажировки купил трехкилограммовый ноутбук за $50, потом воевал с Arch ради одной проприетарной программы — и в итоге вернулся туда же, откуда начинал, на Ubuntu. Это не история моего поражения (как некоторым хотелось бы), а притча об осознании. Осознании чего?

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

Приветствую всех читателей Хабра. В этой статье я расскажу как сделать маршрутизатор из компьютера на Linux. На самом деле, сделать такой роутер несложно. Для реализации этого проекта подойдет любое устройство на Debian/Ubuntu Server, имеющее парочку сетевых карт и возможность раздавать Wi-Fi. Важно учесть, использует ли ваш провайдер PPPoE, т. к. статья не описывает настройку девайса для работы с этим протоколом. У x86 роутера есть плюс: он может стать полноценным домашним сервером, ведь вы можете запускать другие сервисы на нем, а маршрутизация становится еще одной задачей для относительно мощного x86 железа.

Мой игровой ПК с 5800×3D переехал в шкаф в прихожей и стал домашним сервером, а играю я теперь на телевизоре, Steam Deck и ноутбуке — стримом с него же. В этой статье расскажу, почему мне не подошла привычная связка Sunshine + Moonlight и как вместо неё поднять Wolf из проекта Games on Whales, о котором на русском, кажется, ещё не писали: свой виртуальный дисплей под каждого клиента, несколько сессий одновременно и никакого Steam на хосте. Отдельно — про главные грабли: с Wolf не работает официальный проброс NVIDIA‑драйвера, и после каждого обновления стриминг молча умирал, пока я не научил сервер чинить себя сам.

В Linux с давних пор киллерфичей была возможность централизованного управления (поиск, установка, удаление, обновление, разрешение зависимостей) софтом при помощи пакетных менеджеров (apt, yum, pacman и т.д.).

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

Когда таких программ накапливается достаточное количество, их сопровождение превращается в настоящий цирк.

Я решил для себя этот вопрос создав собственный apt репозиторий.

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

В первой части мы собирали свой собственный минимально необходимый образ системы с рабочим столом Mate и остановились на собраном архиве mate-rootfs.sqfs.

Во второй части мы сделаем установку образа на основной диск, произведём разметку диска, и сделаем загрузку нашего ядра Linux без посредников в виде grub, systemd-boot

Привет Хабр, меня зовут Данила Гуляев, я — методист Linux-решений в АСКОН, и это вторая статья из серии о развёртывании программных продуктов в условиях предприятий с закрытыми внутренними сетями. Первую можно прочитать здесь.

Сегодня мы опишем сценарий развёртывания КОМПАС-3D в операционной системе РЕД ОС 8. В нашем материале эта операционная система будет использоваться как для сервера локального репозитория, так и для клиентских машин.

Когда на экране терминала появилось приглашение #, Flipper Zero уже сложно было назвать просто устройством для работы с радиопротоколами, NFC и инфракрасными пультами. Передо мной находился маленький Unix-подобный компьютер: с ядром, процессами, командной оболочкой и файловой системой на microSD.

Всё началось не с мечты про «поисковик нового поколения». Мне понадобился быстрый self-hosted Tavily-compatible API для собственных рабочих и личных AI-решений: без оплаты за каждый запрос, без внешнего сервиса в обязательной цепочке и с индексом, содержимое которого контролирую я сам.

Тут я вспомнил про YaCy. Когда-то я уже поднимал его ноду. Идея мне нравилась, а реализация — заметно меньше: Java, тяжёлая машина и примерно шесть секунд ожидания ответа на моей тогдашней установке. Для человека, который один раз нажал Enter, это ещё можно пережить. Для агента, делающего несколько поисков, уточнений и extract подряд, это превращает один шаг в минутный перекур.

Поэтому вместо ещё одной обёртки над чужим поиском я оставил от YaCy сетевой протокол и начал собирать поисковую ноду заново: на Go, с отдельным краулером, embedded storage, нормальным API и ranking pipeline из современных работ по information retrieval.

Под катом — немного сетевой археологии, Bleve, bbolt, gRPC, BM25, LambdaMART и рассказ о том, как задача «дайте локальный endpoint для AI-агентов» постепенно превратилась в реинкарнацию YaCy.

В прошлой статье я писал как поднять себе LLM для экспериментов, но сейчас полез чистить «Понравившееся», плейлист на YouTube Music — а часть треков оттуда просто исчезла: где-то удалили клип, где-то канал в бане, где-то правообладатель передумал. Плейлист, который я собирал годами, тихо усыхал, и меня не спросили. Причем у меня есть подписка. Ну и обойдусь, а как, написано в статье.

Известный в Linux-сообществе автор технической литературы Роб Кеннеди опубликовал историю создания Linux.org — одного из первых веб-сайтов, посвящённых Linux, — а также рассказал о его недавнем возрождении.

Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию.

Если вы не читали первую часть, лучше начать с неё: в ней разобрали принципы расследования, изоляцию хоста, trusted toolkit, фиксацию исходного состояния, сетевые соединения и процессы. Без этого контекста часть команд и логика дальнейшего анализа будут менее понятны.

Первая часть здесь.

В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.