База знаний (кластер NBICS)

Создаём и запускаем службу NodeBB в SystemD 1. Создаём пользователя NodeBB (как и любой Node.js-сервис) никогда не должен работать от root. Поэтому нужно создать непривелегированного пользователя. adduser --disabled-password --gecos "" nodebb Эта команда создает минимальную, непривилегированную и неинтерактивную учетную запись с именем nodebb, которая идеально подходит для безопасного запуска веб-приложений. 2. Меняем владельца каталога nodebb Допустим, вы работаете в LXC-контейнере, и каталог nodebb находится в корневом каталоге виртуальной системы. Заходим туда, и сначала останавливаем форум: cd /nodebb ./nodebb stop Далее меняем владельца каталога chown -R nodebb:nodebb /nodebb chown: Изменить владельца. -R: Рекурсивно (применить ко всем файлам и подкаталогам внутри /nodebb). nodebb:nodebb: Новый владелец (пользователь:группа). /nodebb: Директория форума NodeBB. После этого пользователь nodebb сможет безопасно запускать приложение, и вы сможете правильно указать его в вашем файле Systemd-службы (например, в директивах User=nodebb и Group=nodebb). 3. Создание файла для systemd Заходим в каталог cd /etc/systemd/system/ Создаём файл touch nodebb.service Вносим в этот файл следующий текст: # /etc/systemd/system/nodebb.service [Unit] Description=NodeBB Forum Documentation=https://docs.nodebb.org After=network.target mongod.service Wants=mongod.service [Service] Type=simple User=nodebb Group=nodebb WorkingDirectory=/nodebb Environment=NODE_ENV=production # Это самый важный момент — запускаем напрямую loader.js ExecStart=/usr/bin/node /nodebb/loader.js --no-silent --no-daemon ExecStop=/usr/bin/node /nodebb/app.js --stop # или просто kill, но так аккуратнее Restart=always RestartSec=10 # Логи StandardOutput=journal StandardError=journal # Ограничения (по желанию) MemoryMax=600M CPUQuota=90% [Install] WantedBy=multi-user.target 4. Запуск сервиса sudo systemctl daemon-reload sudo systemctl enable nodebb sudo systemctl start nodebb

Увеличение размера файла подкачки (виртуальная память, Swap) # Пример создания swap-файла 2 ГБ (если нет раздела) sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Теория JWT-аутентификации JWT (JSON Web Token) — это безопасный и удобный способ передачи данных между разными системами. JWT часто используется для аутентификации пользователей или передачи информации о правах доступа. Это как пропуск на мероприятие. Когда вы заходите на концерт, вам дают билет с уникальным кодом, который подтверждает, что вы купили билет и имеете право зайти. JWT выполняет ту же роль, только для систем. Создание токена Когда вы или ваше приложение авторизуетесь, сервер создаёт токен (то есть «пропуск»), в котором хранится информация, например: - Кто вы (имя пользователя или ID). - Какие у вас права (например, "может записывать звонки"). - Когда истекает срок действия этого токена (чтобы нельзя было использовать его вечно). Эта информация кодируется в виде строки (набора символов) и подписывается с помощью специального "секретного ключа". Подпись нужна, чтобы никто не мог подделать токен. Использование токена Когда вы хотите что-то сделать на сервере (например, войти в конференцию в Jitsi), ваше приложение отправляет этот токен серверу. Сервер проверяет токен: - Не изменён ли он. - Действителен ли он. - Есть ли у вас право делать то, что вы хотите. Почему JWT удобен? Не нужно хранить сессии на сервере. Всё, что нужно, — это проверить подпись токена. Это облегчает работу сервера. Токен — это всего лишь текстовая строка, которую можно легко передавать через Интернет. Как выглядит JWT? JWT состоит из трёх частей, разделённых точками (.): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImpvaG4iLCJyb2xlIjoiYWRtaW4iLCJleHBpcmUiOjE2MzAxMzc2MDB9.N9RXgZG8ghJDU4Zfbl9h7syNDcKXoZVgCkKb-Pouhyo Заголовок (Header): Указывает тип токена и метод шифрования. { "alg": "HS256", "typ": "JWT" } Полезная нагрузка (Payload): Содержит данные, например имя пользователя, роль и срок действия. { "username": "sidorov", "role": "admin", "expire": 1630137600 } Подпись (Signature): Гарантирует, что токен не был изменён. Как это используется в Jitsi? Создание токена: Система управления, например Jitsi Admin, создаёт токен, когда пользователь пытается подключиться. В токене прописываются его права: например, кто он и может ли он создавать конференции. ​ Проверка токена: Jitsi Meet сервер проверяет токен, прежде чем впустить пользователя или разрешить ему выполнять действия.

Разные вопросы и нюансы 1. Как часто серверы «опрашивают» основной? FRP работает не совсем как «опрос» (poll), а как постоянное TCP-соединение. Принцип: Клиент (frpc) устанавливает соединение с сервером (frps) при старте и удерживает его открытым. Это не «запрос-ответ», а «труба», которая всегда открыта. Heartbeat (пульс): Чтобы соединение не разрывалось из-за бездействия или NAT-таймаутов, внутри FRP есть механизм heartbeat. По умолчанию он отправляет маленькие контрольные пакеты примерно каждые 30 секунд. Это минимальная нагрузка на сеть — доли килобайт. Настройка: Вы можете регулировать это в frpc.toml параметром heartbeatInterval (в секундах). Если сеть очень нестабильная, можно поставить меньше, если всё хорошо — оставить по умолчанию. 2. Сколько серверов можно «повесить» на один основной? Здесь всё зависит от ресурсов Сервера Б (Стабильного). FRP крайне эффективен, так как написан на Go. Оперативная память (RAM): Один клиент frpc потребляет очень мало (от 5 до 20 МБ в зависимости от количества прокси). Если у вас 1 ГБ ОЗУ на Сервере Б, вы легко можете держать сотни (200–500+) подключенных серверов. Процессор (CPU): Пока туннели простаивают, нагрузка близка к нулю. Она вырастает только тогда, когда по туннелю идет реальный трафик (например, вы копируете файлы через SSH или передаёте данные). Сетевой канал (Bandwidth): Это узкое место. Если 50 серверов начнут одновременно качать гигабайты данных через Сервер Б, он станет "бутылочным горлышком". Есть ли предел? Технического лимита внутри FRP практически нет, но есть ограничения операционной системы (Linux): Лимит файлов (File Descriptors): Каждое соединение — это открытый файл. В Linux по умолчанию лимит обычно 1024, но его легко поднять в настройках ulimit или через системные настройки sysctl. Суммарная пропускная способность: Один мощный сервер (например, с 2–4 ядрами и 4 ГБ ОЗУ) легко "переварит" 1000+ туннелей в режиме ожидания. Итого: Нагрузка на сеть: Мизерная (контрольные пакеты раз в 30 секунд). Масштабирование: Можно цеплять сотни клиентов. Совет: Если планируете более 50–100 серверов, обязательно добавьте в настройки [common] параметр maxPoolCount на Сервере Б, чтобы управлять пулом соединений и не забить все порты. Если планируете подключать целую «ферму» из десятков серверов, лучше заранее выделить отдельный конфиг для каждого или использовать динамическую конфигурацию (когда frps берет настройки из БД или отдельной папки), чтобы не раздувать один файл до бесконечности.

Справочник по Matrix Synapse (Пункты 301–374) Сборный: сетевые проблемы в контейнерах, продвинутая диагностика, API, сравнение установок и практические советы Incus/LXD, Docker и Сетевые Конфликты Incus/LXD создает изолированную сеть для контейнеров, что приводит к двойному NAT (Double NAT) и усложняет прохождение WebRTC-трафика. В отличие от нативной установки, в контейнере Incus сервис (Synapse/Coturn) видит только свой внутренний IP (например, 10.214.97.46), а не реальный внешний IP хоста. Это требует обязательной настройки external-ip в Coturn в формате external-ip=ВНЕШНИЙ_IP/ВНУТРЕННИЙ_IP (например, external-ip=91.221.70.18/10.214.97.46). Docker и Incus на одном хосте часто конфликтуют, так как оба активно управляют цепочками iptables, вставляя свои правила в самый верх. Конфликт с Jitsi — частая проблема, так как Jitsi Videobridge по умолчанию использует порт 10000 UDP и может перехватывать трафик, предназначенный для Matrix. Проверить, какие UDP-порты заняты Docker-контейнерами, можно командой: sudo ss -lupn | grep docker-proxy. Чтобы избежать конфликтов, необходимо разносить диапазоны портов для разных сервисов (например, Jitsi — 10000, Matrix — 49152-65535). При использовании Incus стандартные пробросы портов через incus config device add неэффективны для больших диапазонов UDP, требуется прямое вмешательство в iptables на хосте. Правила iptables, добавленные вручную, живут только в памяти и исчезают после перезагрузки, если их не сохранить. Команда для сохранения правил iptables: sudo netfilter-persistent save (требуется пакет iptables-persistent). Просмотр сохраненных правил: cat /etc/iptables/rules.v4. Глубокая Диагностика Сети и Пакетов Если tcpdump внутри контейнера показывает входящие пакеты от клиента, а Coturn в логах молчит — значит, Coturn отклоняет пакеты на уровне приложения. Самая частая причина такого молчания — блокировка подсети клиента через директиву denied-peer-ip в turnserver.conf. Для контейнеров с IP в диапазоне 10.x.x.x критически важно закомментировать строку denied-peer-ip=10.0.0.0-10.255.255.255. Пакеты могут "стучаться" в порт 3478, но Coturn не считает их валидными STUN-запросами из-за несовпадения realm или отсутствия fingerprint. Ошибка "401 Unauthorized" в логах Coturn при попытке звонка — явный признак несовпадения static-auth-secret в Coturn и turn_shared_secret в Synapse. Для детальной диагностики WebRTC-соединения в браузере (Element) нужно открыть инструменты разработчика (F12) и изучить вкладку "Network" и "Console". Поиск в консоли по словам "ICE", "TURN", "STUN" покажет, какие серверы пытается использовать клиент. Если в консоли нет упоминаний вашего TURN-сервера, значит Synapse не отдал клиенту его настройки (проблема в секции turn_uris). Команда для проверки, что Synapse "видит" свой TURN-сервер изнутри контейнера: curl http://localhost:8008/_matrix/client/versions (это не проверит TURN, но проверит работу Synapse). API Администратора (Практические Примеры) Получение короткого токена администратора одной строкой (замените admin и password TOKEN=$(curl -s -X POST "http://localhost:8008/_matrix/client/r0/login" -H "Content-Type: application/json" -d '{"type":"m.login.password","user":"admin","password":"ПАРОЛЬ"}' | jq -r '.access_token') Создание алиаса для удобного получения токена: alias matrix-token='curl -s -X POST http://localhost:8008/_matrix/client/r0/login -d '\''{"type":"m.login.password","user":"admin","password":"ваш_пароль"}'\'' | jq -r .access_token' Получение списка всех комнат на сервере (осторожно, может быть много): curl -s "http://localhost:8008/_synapse/admin/v1/rooms?limit=100" -H "Authorization: Bearer $TOKEN" | jq '.rooms[].room_id' Удаление комнаты (очистка данных): curl -X DELETE "http://localhost:8008/_synapse/admin/v1/rooms/!room_id:domain" -H "Authorization: Bearer $TOKEN" Получение статистики по медиафайлам: curl -s "http://localhost:8008/_synapse/admin/v1/statistics" -H "Authorization: Bearer $TOKEN" | jq . Просмотр активных сессий пользователя: curl -s "http://localhost:8008/_synapse/admin/v1/whois/@user:domain" -H "Authorization: Bearer $TOKEN" | jq .devices Блокировка сервера на уровне федерации (Server ACL) через API — сложная задача, проще через интерфейс комнаты. Сброс пароля пользователя через API одной командой (функция оболочки): ``` matrix-passwd() { TOKEN=$(matrix-token) curl -X PUT "http://localhost:8008/_synapse/admin/v2/users/$1" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d "{\"password\": \"$2\"}" } ``` Сравнение Способов Установки Нативная установка (Debian/Ubuntu) — максимальная простота, лучшая производительность, легкая интеграция с Coturn, но "засоряет" систему и сложнее в изоляции. Установка в Docker — хорошая изоляция, легкие обновления, но сложнее с пробросом UDP-портов и работой WebRTC. Установка в Incus/LXD — отличная изоляция, удобные снапшоты, но самые большие проблемы с WebRTC из-за двойного NAT. YunoHost — максимальная простота для новичков, все работает "из коробки", включая звонки, но меньше гибкости и контроля. Вывод: для продакшена с видео/звонками лучше всего подходит нативная установка на хост. Контейнеры хороши для тестов и изолированных сред без VoIP. Проблемы с PostgreSQL и Базами Данных Проверить, использует ли Synapse PostgreSQL, можно командой ss -antp | grep 5432 | grep python. Наличие ESTAB соединений — признак использования PostgreSQL. Если в логах нет ошибок, но база данных не растет, возможно, Synapse все еще пишет в SQLite. Проверьте дату изменения файла /var/lib/matrix-synapse/homeserver.db. Конфликт между настройками БД в homeserver.yaml и conf.d/ может привести к тому, что Synapse не запустится с ошибкой Duplicate key. При миграции с SQLite на PostgreSQL дамп SQLite требует ручной корректировки (удаление команд, специфичных для SQLite, например, BEGIN TRANSACTION может дублироваться). Параметр cp_min и cp_max в конфиге БД управляют размером пула соединений. Для больших серверов cp_max можно увеличить до 20-30. Практические Команды Администратора (Продолжение) Быстрый просмотр последних ошибок в логах Synapse: journalctl -u matrix-synapse -n 50 -f | grep -i error Проверка, слушает ли Coturn нужные порты внутри контейнера: ss -ulnp | grep 3478 (UDP) и ss -tlnp | grep 3478 (TCP). Проверка версии Synapse из командной строки: dpkg -l | grep matrix-synapse (для пакетной установки) или docker exec synapse pip show matrix-synapse. Просмотр переменных окружения внутри контейнера Docker: docker exec synapse env. Интерактивный вход в контейнер Docker: docker exec -it synapse /bin/bash. Просмотр логов конкретного контейнера Docker с временными метками: docker logs -t synapse. Остановка всех контейнеров Docker разом (для теста конфликтов): docker stop $(docker ps -q). Поиск файлов конфигурации Coturn: find / -name "turnserver.conf" 2>/dev/null. Просмотр открытых файлов процессом Coturn: lsof -p $(pgrep turnserver). Теория NAT и WebRTC (Почему это сложно) STUN позволяет клиенту узнать свой внешний IP и порт, чтобы сообщить их собеседнику для прямого соединения. TURN используется, когда прямое соединение невозможно (симметричный NAT, корпоративные файерволы). Сервер ретранслирует трафик. ICE — это протокол, который собирает все возможные кандидаты (STUN, TURN, локальные адреса) и пытается установить соединение, перебирая их. В контейнере Incus Coturn видит только свой внутренний IP (10.214.97.46). Без external-ip он сообщит клиенту именно его, и клиент не сможет подключиться. Эффект "пробитого NAT" (UDP Hole Punching) — когда после успешного прохождения одного пакета NAT "запоминает" маршрут и временно открывает его для обратного трафика. Именно поэтому иногда "вчера не работало, а сегодня работает": таблица трансляции адресов (conntrack) могла очиститься или, наоборот, зафиксировать успешный проход. Разное Важное При использовании внешнего реверс-прокси (Nginx) в конфиге Synapse обязателен параметр x_forwarded: true в секции listeners. Для корректной работы федерации server_name в Synapse должен быть именно доменом, а не поддоменом (если вы хотите короткие ID @user:domain.com). Иначе используйте .well-known делегирование. Параметр max_upload_size измеряется в байтах. 50M = 50 * 1024 * 1024 = 52428800. При изменении server_name на уже работающем сервере все существующие пользователи и комнаты "сломаются", так как их ID привязаны к старому имени. Synapse поддерживает ротацию логов. Настройки ротации находятся в /etc/logrotate.d/matrix-synapse. Для мониторинга можно использовать готовый дашборд Grafana для Synapse (например, из официального репозитория). Ошибка "Connection refused" при попытке curl с хоста в контейнер почти всегда означает, что сервис внутри контейнера слушает только 127.0.0.1, а не 0.0.0.0. Команда для изменения bind_addresses в Synapse внутри контейнера: отредактировать файл в /conf.d/ или изменить основной конфиг. Файл /etc/matrix-synapse/conf.d/server_name.yaml создается автоматически при установке из пакета и содержит только server_name: "ваш.домен". Не рекомендуется редактировать этот файл, если вы уже указали домен при установке. Для изменения домена проще переустановить сервер. Параметр enable_registration_captcha включает капчу при регистрации. Требует настройки ReCaptcha от Google. Для использования капчи нужно получить ключи на сайте Google ReCaptcha и указать их в конфиге. Модули Synapse (spam checker, 3pid providers) расширяют функциональность сервера и настраиваются в секции modules. Официальная документация Synapse — лучший источник информации: https://element-hq.github.io/synapse/latest/. Сообщество Matrix в Telegram (@matrix_ru) — отличное место для получения помощи на русском языке. Итоговые проверки работоспособности Финальная проверка федерации без внешних тестеров: с одного сервера пригласить пользователя с другого сервера и отправить сообщение. Финальная проверка звонков: позвонить с пользователя на одном сервере пользователю на другом сервере. Проверка логирования: убедиться, что логи пишутся и не забивают диск. Проверка автоматического запуска: systemctl is-enabled matrix-synapse и systemctl is-enabled coturn. Проверка открытых портов снаружи: использовать онлайн-сервисы вроде yougetsignal.com или portchecker.co. Проверка валидности SSL-сертификата: openssl s_client -connect matrix.domain.com:443 -servername matrix.domain.com < /dev/null 2>/dev/null | openssl x509 -text | grep -A2 Validity.

Справочник по установке, настройке и эксплуатации Mailcow (Пункты 101–200) Docker и управление контейнерами docker compose exec <имя_контейнера> <команда> позволяет выполнить команду внутри работающего контейнера. Пример: sudo docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} ${DBNAME} проверяет подключение к базе данных. Контейнер nginx-mailcow выступает в роли обратного прокси внутри стека Mailcow для всех веб-сервисов. Контейнер php-fpm-mailcow обрабатывает PHP-логику веб-интерфейса Mailcow. Контейнер mysql-mailcow (MariaDB) хранит все настройки, домены, пользователей и пароли. Контейнер dovecot-mailcow отвечает за доставку писем в ящики пользователей (IMAP/POP3). Контейнер postfix-mailcow — это MTA (Mail Transfer Agent), принимающий и отправляющий почту. Контейнер rspamd-mailcow — мощная система фильтрации спама и проверки писем. Контейнер clamd-mailcow — антивирус, проверяющий вложения на вредоносный код. Контейнер unbound-mailcow — локальный DNS-резолвер для повышения производительности и безопасности. Контейнер redis-mailcow используется для кэширования и очередей задач. Контейнер sogo-mailcow предоставляет веб-почту (Roundcube) и CalDAV/CardDAV функционал. Контейнер acme-mailcow автоматически получает и обновляет SSL-сертификаты Let's Encrypt. Контейнер watchdog-mailcow отслеживает состояние других контейнеров и перезапускает упавшие. Контейнер netfilter-mailcow управляет правилами файервола внутри Docker-сети. Проблемы с сетью и портами Ошибка failed to bind host port for 0.0.0.0:443: address already in use означает, что порт 443 занят. Для освобождения порта 443 нужно остановить сервис, который его занимает (nginx, apache, другой Docker-контейнер). При использовании внешнего прокси порты 80 и 443 на хосте должны принадлежать прокси, а не Mailcow. В этом случае в файле .env нужно указать альтернативные порты для Mailcow, например HTTP_PORT=8080 и HTTPS_PORT=8443. Команда sudo ss -tulpn | grep 443 показывает все процессы, использующие порт 443 с их PID. Если порт занят процессом с PID 1 (systemd), значит служба настроена на системном уровне. После изменения портов в .env может потребоваться полный перезапуск: docker compose down && docker compose up -d. Конфликт портов может возникнуть не только с внешними сервисами, но и с другими контейнерами Docker. Для просмотра всех Docker-сетей используется команда docker network ls. Для детальной информации о сети: docker network inspect <имя_сети>. Стандартная сеть Docker bridge использует подсеть 172.17.0.0/16, что может конфликтовать с Mailcow. Если несколько проектов Docker Compose используют одинаковые подсети, возникает конфликт. Решение конфликта сетей — изменить IPV4_NETWORK в .env на уникальный диапазон. Настройка внешнего Nginx (Reverse Proxy) Внешний Nginx должен быть настроен на проксирование трафика на внутренние порты Mailcow. Для HTTP-трафика: proxy_pass http://127.0.0.1:8080; (если HTTP_PORT=8080). Для HTTPS-трафика: proxy_pass http://127.0.0.1:8080; также, так как SSL терминируется на внешнем Nginx. Заголовок proxy_set_header X-Forwarded-Proto https; критически важен для правильной работы Mailcow за прокси. Без этого заголовка Mailcow будет думать, что все запросы идут по HTTP, и пытаться редиректить на HTTPS. Заголовок proxy_set_header Host $host; сохраняет оригинальное имя хоста при проксировании. Заголовок proxy_set_header X-Real-IP $remote_addr; передает реальный IP-адрес клиента. Для поддержки WebSocket (нужен SOGo для уведомлений) необходимы настройки: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; Директива client_max_body_size 0; отключает ограничение на размер загружаемых файлов (важно для вложений). В конфиге внешнего Nginx должен быть отдельный блок server для порта 80 с редиректом на HTTPS. Редирект делается директивой return 301 https://$host$request_uri;. Без этого редиректа пользователи, заходящие по HTTP, будут видеть ошибки или страницу Mailcow без стилей. Certbot и SSL-сертификаты Certbot — это клиент Let's Encrypt для автоматического получения и обновления SSL-сертификатов. Команда sudo certbot --nginx автоматически получает сертификат и настраивает Nginx. При первом запуске Certbot создает временный файл в /.well-known/acme-challenge/ для проверки домена. Для этого порт 80 должен быть открыт и доступен из интернета. Если Certbot находит существующий сертификат, он предлагает опции: переустановить или обновить. Выбор 2: Renew & replace the certificate гарантирует получение свежего сертификата и обновление конфига. Certbot автоматически добавляет в конфиг Nginx строки ssl_certificate и ssl_certificate_key. Также добавляются include /etc/letsencrypt/options-ssl-nginx.conf; и ssl_dhparam.... Ошибка "We were unable to restart web server" означает, что Certbot не смог перезапустить Nginx из-за ошибок в конфиге. В этом случае нужно исправить конфиг Nginx вручную и выполнить sudo certbot install --cert-name <домен>. Сертификаты Let's Encrypt действительны 90 дней, Certbot автоматически их обновляет через cron/systemd timer. После обновления сертификата Nginx перезагружается для применения новых сертификатов. Диагностика и отладка sudo docker compose logs -f <контейнер> позволяет следить за логами в реальном времени (аналог tail -f). sudo docker compose logs --tail=50 mysql-mailcow показывает последние 50 строк логов MySQL. Лог-сообщение mariadbd: ready for connections. означает, что MySQL готов к работе. Циклическое повторение Waiting for SQL... в логах PHP-FPM указывает на проблемы с подключением к MySQL. Ошибка connect() failed (111: Connection refused) в логах Nginx означает, что бэкенд (PHP-FPM) не отвечает. Команда sudo docker compose restart <контейнер> перезапускает конкретный контейнер. sudo docker compose restart nginx-mailcow перезапускает только Nginx, что полезно после изменения конфигов. Проверка доступности порта изнутри контейнера: docker exec -it <контейнер> nc -zv 127.0.0.1 <порт>. Для проверки DNS внутри контейнера: docker exec -it <контейнер> dig google.com. Логирование ошибок PHP можно включить в конфигурации PHP-FPM, монтируя файл логов. Все контейнеры Mailcow используют один и тот же внутренний часовой пояс из переменной TZ. Настройка DNS и почтовые протоколы Помимо веб-интерфейса, Mailcow использует стандартные почтовые порты: 25 (SMTP), 465 (SMTPS), 587 (Submission). IMAP (для чтения почты) работает на портах 143 (STARTTLS) и 993 (SSL/TLS). POP3 (устаревший протокол) работает на портах 110 и 995. Sieve (для фильтрации почты) работает на порту 4190. Для нормальной работы почты эти порты должны быть открыты в файерволе сервера. Проверить доступность порта извне можно на mxtoolbox.com (Diagnostics -> SMTP Test). При использовании внешнего прокси, почтовые порты должны быть открыты напрямую на сервере (прокси их не трогает). SUBMISSION_PORT=587 в .env позволяет изменить стандартный порт для отправки почты клиентами. SMTPS_PORT=465 — порт для устаревшего SMTPS (не путать с STARTTLS на порту 587). IMAPS_PORT=993 и POP3S_PORT=995 — защищенные версии протоколов доступа к почте. Для каждого добавленного почтового домена нужно настроить отдельные DNS-записи (MX, SPF, DKIM, DMARC). DKIM-ключи генерируются отдельно для каждого домена в панели Mailcow. Селектор DKIM по умолчанию в Mailcow — dkim (запись выглядит как dkim._domainkey.domain.tld). DMARC-политика p=quarantine рекомендована для начальной настройки, p=reject — для полной защиты. Адрес для DMARC-отчетов (rua=mailto:...) должен существовать и быть доступным. Безопасность Встроенный watchdog (USE_WATCHDOG=y) автоматически перезапускает упавшие контейнеры. WATCHDOG_NOTIFY_EMAIL позволяет настроить отправку уведомлений о проблемах на email. WATCHDOG_NOTIFY_BAN включает уведомления о забаненных IP-адресах. WATCHDOG_EXTERNAL_CHECKS=n отключает внешние проверки на open relay (по умолчанию выключено). Переменная SKIP_CLAMD=n включает антивирус ClamAV (рекомендуется, но требует ресурсов). SKIP_SOGO=n включает веб-почту SOGo (рекомендуется оставить включенным). SKIP_FTS=n включает полнотекстовый поиск в Dovecot (полезно, но нагружает сервер). FTS_HEAP=128 ограничивает память для индексации писем (можно увеличить при наличии ресурсов). FTS_PROCS=1 ограничивает количество процессов индексации (можно увеличить на мощных серверах). ALLOW_ADMIN_EMAIL_LOGIN=n запрещает администраторам входить в почтовые ящики пользователей без пароля. ACL_ANYONE=disallow запрещает создание общих папок для всех аутентифицированных пользователей. ENABLE_SSL_SNI=n отключает поддержку отдельных сертификатов для разных доменов (если не нужно). ENABLE_IPV6=false отключает IPv6 (если не настроен на сервере). Почтовые ящики и квоты MAILDIR_GC_TIME=7200 определяет время (в минутах) хранения удаленных ящиков в корзине (здесь 5 дней). MAILDIR_SUB=Maildir — стандартное имя директории для хранения писем в формате Maildir. SOGO_EXPIRE_SESSION=480 — время сессии в веб-почте SOGo в минутах (480 = 8 часов). SOGO_URL_ENCRYPTION_KEY — ключ шифрования для URL в SOGo (генерируется автоматически). DOVECOT_MASTER_USER и DOVECOT_MASTER_PASS — мастер-аккаунт для доступа к любым ящикам (использовать осторожно). LOG_LINES=9999 — количество сохраняемых строк логов в Redis для каждого сервиса. SPAMHAUS_DQS_KEY — ключ для Spamhaus Data Query Service (если ваш IP в заблокированной ASN). API и автоматизация Mailcow имеет полноценный REST API для управления доменами, ящиками, алиасами и настройками. Для использования API нужно создать ключ в разделе Access → API и разрешить доступ с нужных IP (API_ALLOW_FROM).

Справочник по DNS и почтовой инфраструктуре Mailcow (Пункты 201–300) Глубокое погружение в PTR и обратную зону Запись in-addr.arpa — это специальная доменная зона, используемая для обратного DNS-запроса (PTR). Полное имя для PTR-записи IP 91.221.70.18 выглядит так: 18.70.221.91.in-addr.arpa. Тот факт, что в статусе PTR указан провайдер (dedic-center.ru), означает, что зона контролируется им, и запись нужно менять через него. FCrDNS (Forward-confirmed reverse DNS) — это ситуация, когда прямое (A) и обратное (PTR) сопоставления совпадают и указывают друг на друга. FCrDNS является золотым стандартом для почтовых серверов и сильно повышает доверие. Если PTR указывает на что-то вроде dedic-center.ru, а A-запись — на postmail.nbics.net, FCrDNS не работает, и письма идут в спам. Проверить FCrDNS можно двумя командами: dig -x <IP> и dig <hostname> A. Отсутствие PTR не только ухудшает доставляемость, но и может стать причиной длительных таймаутов при соединении. Детали работы MX-приоритетов Приоритет MX (preference) — это целое число от 0 до 65535. Стандарт RFC 5321 требует наличия приоритета в MX-записи. Если у домена два MX-сервера с приоритетами 10 и 20, все письма сначала идут на сервер с приоритетом 10. Переключение на резервный сервер (приоритет 20) происходит только после того, как основной (10) не ответил в течение определенного времени (обычно несколько минут). Наличие двух MX-записей с одинаковым приоритетом означает, что нагрузка будет распределяться между ними случайным образом. Запись MX 0 postmail.nbics.net технически возможна, но 0 обычно зарезервирован для особых случаев и не рекомендуется для единственного сервера. Указывать в MX имя, для которого нет A-записи (как в случае с mail.books.nbics.net), — фатальная ошибка, почта теряется. Gmail, Яндекс и Outlook могут по-разному обрабатывать отсутствие приоритета: от помещения в спам до полного отказа в доставке. Расширенный синтаксис SPF Механизм a в SPF (a:postmail.nbics.net) проверяет все A- и AAAA-записи указанного домена. Механизм mx в SPF проверяет все IP-адреса серверов, перечисленных в MX-записях домена. v=spf1 mx -all — более короткий и элегантный способ записи для типовой конфигурации. Механизм ip4 позволяет явно перечислить разрешенные IPv4-адреса: ip4:91.221.70.18. Квалификатор -all означает "жесткий провал" (hard fail) — письмо должно быть отклонено. Квалификатор ~all означает "мягкий провал" (soft fail) — письмо принято, но помечено как подозрительное. Квалификатор ?all означает "нейтрально" — ничего не говорит о подлинности письма. В 2025 году для максимальной защиты рекомендуется использовать -all. Если в будущем вы будете отправлять письма через сервис вроде Mailchimp, его нужно будет добавить в SPF через include:_spf.mailchimp.com. Нюансы DKIM Селектор (s=email в твоей записи) позволяет иметь несколько DKIM-ключей для одного домена (например, для разных почтовых серверов или ротации ключей). Тег t=s означает, что данный ключ нельзя использовать для подписывания писем от поддоменов. DKIM-подпись гарантирует не только то, что письмо от вас, но и что оно не было изменено в пути. Публичный ключ (p=...) — это длинная строка в base64, которую нельзя обрезать или изменять. Mailcow автоматически создает пару ключей (приватный и публичный) для каждого нового домена. Приватный ключ хранится в конфигурации Mailcow и никогда не должен быть опубликован. Проверить валидность DKIM-записи можно с помощью онлайн-инструментов, введя селектор и домен. Срок действия DKIM-ключа не ограничен, но рекомендуется менять его раз в год или два для усиления безопасности. DMARC: Политики и Отчеты Тег pct=100 означает, что политика применяется к 100% писем. Можно начать с меньшего процента, чтобы протестировать. Тег rua=mailto: указывает адрес для получения агрегированных отчетов (XML). Тег ruf=mailto: указывает адрес для получения форензик-отчетов (данные о каждом провалившемся письме). Тег fo=1 означает, что форензик-отчет должен быть отправлен, если провалилась хотя бы одна из проверок (SPF или DKIM). Тег aspf=s включает строгий режим проверки SPF (домен в конверте должен точно совпадать с доменом в заголовке From). Тег adkim=s включает строгий режим проверки DKIM. Отчеты DMARC отправляют не только Gmail, но и Яндекс, Mail.ru, Outlook и многие другие, если домен отправляет им много писем. DMARC-отчеты нужны не для мгновенного чтения, а для долгосрочного мониторинга и выявления проблем. Если ящик для отчетов (rua) переполнится или станет недоступен, отправители (Gmail и др.) просто перестанут слать отчеты, на доставку писем это не повлияет. Политика p=reject — самая строгая и говорит принимающему серверу: "Отклони письмо навсегда, не пытайся отправить в спам". Политика p=quarantine говорит: "Отправь в спам". Политика p=none говорит: "Ничего не делай, но пришли отчет". Autodiscover/Autoconfig: Как это работает изнутри Outlook, пытаясь найти autodiscover, обращается по URL: https://autodiscover.books.nbics.net/Autodiscover/Autodiscover.xml. Thunderbird обращается по URL: https://autoconfig.books.nbics.net/mail/config-v1.1.xml. Если CNAME-записи нет, клиент может пробовать "умные" догадки, например, обращаться к https://books.nbics.net/.well-known/autoconfig/mail/config-v1.1.xml. Наличие правильно настроенных autodiscover/autoconfig записей избавляет пользователей от необходимости знать разницу между IMAP и SMTP. SRV-запись для autodiscover — это запасной механизм на случай, если прямое HTTPS-соединение не удалось. Архитектурные Решения и Best Practices Разделение на "человеческий" (books.nbics.net) и "мусорный" (trash.nbics.net) домены позволяет применять к ним разные политики безопасности. Например, для "мусорного" домена можно выставить DMARC p=quarantine, а для "человеческого" — p=reject. Технический хостнейм (postmail.nbics.net) не должен фигурировать в поле "From" отправляемых писем. Адреса техподдержки и обращения к людям должны идти только с "человеческого" домена. При масштабировании (например, добавлении второго почтового сервера) вы просто создаете вторую MX-запись с более высоким приоритетом (например, 20). Стратегия "мусорного домена" копирует подход крупных корпораций, использующих отдельные домены для уведомлений (например, amazonses.com). Управление Почтовыми Ящиками и Лимитами Поле "Полное имя" (Display Name) для технических ящиков вроде dmarc-reports может быть любым понятным, например, "DMARC Aggregated Reports". Это поле не влияет на техническую функциональность и нужно только для идентификации ящика в веб-интерфейсе. В Mailcow лимиты отправки можно настроить как на уровне всего домена, так и на уровне отдельных ящиков. Если оставить лимиты отправки пустыми или равными 0, значит, они не ограничены. Параметр "Ретрансляция всех получателей" используется только в конфигурациях, где Mailcow выступает в роли промежуточного ретранслятора (relay). Для обычного почтового сервера, который доставляет почту в свои же ящики, все опции ретрансляции должны быть отключены. Сравнение и Выбор Технологий (LDAP vs Keycloak) OpenLDAP — это "телефонная книга", а Keycloak — это "пропускная система с регистратурой". Keycloak умеет "федерировать" пользователей, то есть работать как единая точка входа для множества приложений (SSO). Keycloak поддерживает не только локальную регистрацию, но и вход через аккаунты Google, GitHub и другие. OpenLDAP хранит только атрибуты пользователя (имя, пароль, email), Keycloak управляет еще и сессиями, правами доступа и ролями. Для интеграции с Mailcow через OpenLDAP потребуется настраивать маппинг атрибутов (что соответствует чему в почтовой системе). Интеграция с Keycloak через OpenID Connect (OIDC) проще и современнее: пользователь просто перенаправляется на страницу входа Keycloak. Выбор между OpenLDAP и Keycloak зависит от задачи: если нужно просто хранить пользователей — OpenLDAP, если нужна саморегистрация и SSO — Keycloak. Решение Проблем с Почтовыми Клиентами Если Thunderbird не может найти настройки автоматически, проблема часто в кэше DNS или в том, что autoconfig запись еще не распространилась. Ошибка "Done is inactive" почти всегда решается повторной проверкой (Re-test) после ручного ввода правильных портов и метода аутентификации. Указание неверного порта для SMTP (например, 993) — самая распространенная ошибка при ручной настройке. Если пароль не принимается, убедитесь, что в качестве имени пользователя используется полный email, а не его часть. Outlook может кэшировать неудачные попытки autodiscover, поэтому после исправления DNS может потребоваться время или перезагрузка. Безопасность и "Прогрев" IP "Холодный" IP — это IP-адрес, который ранее не использовался для отправки почты или использовался для сомнительных целей. Даже идеально настроенный сервер с холодного IP будет получать задержки от крупных провайдеров. Процесс "прогрева" IP заключается в постепенном увеличении объема легитимной почты для накопления положительной репутации. Отправка слишком большого количества писем с нового IP в первый же день может привести к его мгновенной блокировке. Жалобы на спам (abuse reports) — самый быстрый способ убить репутацию и IP, и домена. Feedback Loop (FBL) — это механизм, при котором провайдер (например, Mail.ru) возвращает отправителю информацию о том, что получатель пометил письмо как спам. Практические Команды (продолжение) host -t PTR <IP-адрес> — альтернативная команда для проверки PTR. nslookup -type=mx <домен> — проверка MX-записей в Windows. systemctl status postfix в контейнере или на сервере позволяет увидеть, работает ли почтовая служба. docker exec -it <имя_контейнера> bash — команда для входа внутрь контейнера Mailcow для детальной диагностики. postqueue -p (внутри контейнера postfix) показывает очередь писем, которые не могут быть доставлены. tail -f /var/log/mail.log (путь может отличаться) — просмотр логов почты в реальном времени. swaks — мощная командная утилита для тестирования SMTP-серверов и отправки тестовых писем. Различные Нюансы из Переписки Если провайдер не дает PTR для домашнего статического IP, это делает невозможным использование его для серьезного почтового сервера. Использование Cloudflare Tunnel или других решений не решит проблему с 25-м портом, так как это требование к IP, а не к домену. Даже если вы никому не отправляете почту, многие сервисы (банки, соцсети) все равно будут пытаться доставить вам письма, и им нужен ваш работающий MX. Закрытая корпоративная почта внутри компании на своем сервере может прекрасно работать и без PTR, если вся переписка идет внутри. Технические ящики вроде dmarc-reports лучше создавать с включенным сборщиком мусора или периодически чистить, чтобы они не переполняли диск. "Закрашивание" ключей звездочками в посте — обычная практика безопасности при публикации скриншотов. Приоритеты в SRV-записи (0 1 443) означают: приоритет 0 (самый высокий), вес 1 (для распределения нагрузки), порт 443. TLSA-запись для порта 25 нужна, только если вы хотите, чтобы другие серверы проверяли ваш TLS-сертификат через DANE. Mailcow не позволит вам создать почтовый домен, который совпадает с хостнеймом, если это не было сделано специальным образом. YunoHost скрывает сложность от пользователя, но под капотом использует те же самые принципы разделения. Понимание разницы между postmail.nbics.net (сервер) и mail.nbics.net (веб-интерфейс) помогает в диагностике проблем. Если кнопка "Done" в Thunderbird не активна, проверьте, не осталось ли предупреждение (желтый треугольник) после нажатия Re-test. Идеальная настройка DNS для почты — это когда ни один из онлайн-чекеров (mxtoolbox, mail-tester) не показывает ошибок, а только зеленые галочки.

10. Позволяем в контейнере запускать команду sudo reboot без пароля Откройте терминал и запустите редактор sudoers специальной командой (это безопаснее, чем редактировать файл вручную): sudo visudo Найдите в файле строку, которая отвечает за права вашего пользователя (обычно в конце файла), или добавьте туда следующую строку. Если ваш пользователь называется username, добавьте:username ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown Если ваш пользователь состоит в группе sudo (или wheel), вы можете добавить правило для всей группы, чтобы разрешить всем в ней перезагрузку без пароля:%sudo ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown (В разных дистрибутивах группа может называться sudo или wheel. Посмотрите, как написано у других пользователей в этом же файле). Сохраните файл и выйдите (в visudo обычно это Ctrl+X, затем Y для подтверждения, либо :wq если открылся vim). Результат: Теперь команда sudo reboot будет перезагружать компьютер сразу, без запроса пароля. Внимание ! В файле есть важная строка: #includedir /etc/sudoers.d Лучше добавить ваши правила до этой строки (сразу после %sudo ALL=(ALL:ALL) ALL), а не после. Хотя технически они могут работать и в конце, правильнее размещать их выше директивы #includedir. Вот как должен выглядеть блок: # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # Разрешение на перезагрузку без пароля username ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown %sudo ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d После сохранения файла, выйдите из контейнера, зайдите снова и проверьте: sudo reboot Пароль больше не должен запрашиваться.

Чтобы сервер работал после закрытия терминала Вариант 1: Использование systemd (Linux - рекомендуется) Создайте сервисный файл: sudo nano /etc/systemd/system/port7711.service Вставьте это (измените пути на свои): [Unit] Description=Простой HTTP сервер на порту 7711 After=network.target [Service] Type=simple User=ваше_имя_пользователя WorkingDirectory=/home/ваше_имя_пользователя/port7711 ExecStart=/usr/bin/python3 -m http.server 7711 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target Запустите сервис: # Перезагрузить systemd sudo systemctl daemon-reload # Запустить сервис sudo systemctl start port7711 # Добавить в автозагрузку sudo systemctl enable port7711 # Проверить статус sudo systemctl status port7711 Вариант 2: Использование screen (Linux/Mac) Установите screen: # Ubuntu/Debian sudo apt-get install screen # Mac brew install screen Запустите сервер в screen сессии: # Создайте новую screen сессию screen -S webserver # Перейдите в папку с файлом cd ~/port7711 # Запустите сервер python3 -m http.server 7711 # Отсоединитесь от сессии: Ctrl+A, затем D Вариант 3: Использование nohup (Linux/Mac) # Перейдите в папку cd ~/port7711 # Запустите с nohup nohup python3 -m http.server 7711 > server.log 2>&1 & # Запомните PID процесса echo $! > server.pid Вариант 4: Использование Windows Service (Windows) Создайте файл run_server.vbs: CreateObject("Wscript.Shell").Run "python -m http.server 7711", 0, False Или используйте NSSM (Non-Sucking Service Manager): # Скачайте nssm с https://nssm.cc/ nssm install MyWebServer "C:\Python39\python.exe" "-m http.server 7711" nssm set MyWebServer AppDirectory C:\port7711 nssm start MyWebServer Вариант 5: Docker контейнер (универсальный) Создайте Dockerfile: FROM python:3-alpine WORKDIR /app COPY index.html . EXPOSE 7711 CMD ["python", "-m", "http.server", "7711"] Запустите: # Соберите образ docker build -t web7711 . # Запустите контейнер docker run -d -p 7711:7711 --name web7711 --restart always web7711 Как остановить сервер Для systemd: sudo systemctl stop port7711 sudo systemctl disable port7711 # убрать из автозагрузки Для screen: # Подключиться к сессии screen -r webserver # Остановить сервер: Ctrl+C # Закрыть сессию: exit Для nohup: # Найти процесс ps aux | grep http.server # Убить процесс (замените PID на реальный) kill -9 PID # Или если сохранили PID kill -9 $(cat server.pid) Для Windows (VBS): # Найти процесс tasklist | findstr python # Убить процесс taskkill /F /IM python.exe Для Docker: docker stop web7711 docker rm web7711 Простой скрипт для управления (Linux/Mac) Создайте файл manage.sh: #!/bin/bash case "$1" in start) cd ~/port7711 nohup python3 -m http.server 7711 > server.log 2>&1 & echo $! > server.pid echo "Сервер запущен с PID $(cat server.pid)" ;; stop) if [ -f server.pid ]; then kill -9 $(cat server.pid) rm server.pid echo "Сервер остановлен" else echo "PID файл не найден" fi ;; status) if [ -f server.pid ]; then if ps -p $(cat server.pid) > /dev/null; then echo "Сервер работает" else echo "Сервер не работает (PID файл устарел)" fi else echo "Сервер не запущен" fi ;; *) echo "Использование: ./manage.sh {start|stop|status}" ;; esac Сделайте скрипт исполняемым: chmod +x manage.sh ./manage.sh start ./manage.sh stop ./manage.sh status Самый простой способ для начала Для Linux/Mac используйте screen: screen -S webserver cd ~/port7711 python3 -m http.server 7711 # Ctrl+A, D для отсоединения # screen -r webserver для возврата Для Windows используйте VBS скрипт, описанный выше.

Если нужно одновременно на том же компьютере зайти под разными профилями - допустим один ваш профиль на сервере domain1.tld а другой на сервере domain2.tld Для Windows (на компьютере). Скопируйте ярлык Element на рабочем столе. Будет два ярлыка Element Каждый ярлык переименуйте как-то, чтобы не запутаться На первом ярлыке нажмите правой кнопкой мыши, и внизу меню выберите пункт "Свойства" Откроется окно, там есть поле "Объект:" В этом поле есть строка, в ней записан путь к самой программе. Нужно в самом конце этой строки поставить пробел, а затем написать - -profile имя Вместо слова "имя" вставьте любое слово латинскими буквами Может получиться примерно так: --profile work Нажмите Ok Такие же шаги повторите для второго ярлыка, только там напишите, к примеру, -- profile personal Теперь каждый ярлык открывает свой экземпляр программы Element, и в каждом экземпляре можно отдельно

Команда synadm user Использование: synadm user [ОПЦИИ] КОМАНДА [АРГУМЕНТЫ]... Просмотр, добавление, изменение, деактивация/удаление пользователей, сброс паролей. Опции: -h, --help Показать это сообщение и выйти. Команды: 3pid Найти пользователя по его Third Party ID (3PID, например email или телефон). auth-provider Найти пользователя по его идентификатору в провайдере аутентификации. deactivate Деактивировать пользователя или полностью удалить его данные в соответствии с GDPR. deactivate-regex Деактивировать или удалить по GDPR аккаунты, соответствующие регулярному выражению. details Показать подробную информацию об аккаунте пользователя. list Показать список пользователей, выполнить поиск по пользователям. login Получить access-токен для указанного пользователя. media Показать все локальные медиафайлы, загруженные пользователем. membership Показать список всех комнат, в которых состоит пользователь. modify Создать нового локального пользователя или изменить существующего. password Изменить пароль пользователя. prune-devices Удалить устройства пользователя и аннулировать все его access-токены. redact Удалить (redact) события, созданные пользователем (локальным или удалённым). redact-status Получить статус операции удаления (redaction) событий пользователя. search Быстрый способ вызвать 'synadm user list -d -g -n <поисковый_термин>'. shadow-ban Включить или отключить shadow-ban (теневой бан) для пользователя. suspend Приостановить аккаунт (запретить любые действия). whois Показать информацию об активных сессиях пользователя. Краткое описание каждой команды Команда Что делает Самые частые сценарии использования 3pid Поиск пользователя по email, телефону или другому 3PID Найти аккаунт по привязанной почте auth-provider Поиск пользователя по ID в LDAP/SSO/OIDC и т.п. Работа с внешней аутентификацией deactivate Деактивация (отключение входа) или полное стирание аккаунта по GDPR Удаление спам-аккаунтов, уход пользователя deactivate-regex Массовое отключение/удаление пользователей по шаблону имени Чистка ботов или спамеров с похожими именами details Полная информация об аккаунте (создание, статус, устройства, 3PID и т.д.) Диагностика проблем с конкретным пользователем list Список всех пользователей с фильтрами и поиском Обзор всех аккаунтов на сервере login Получить access-токен по логину/паролю Скрипты, автоматизация, отладка media Список всех медиафайлов, загруженных пользователем Проверка, что пользователь загружал (для модерации) membership Список всех комнат, где состоит пользователь Узнать, в каких комнатах сидит человек modify Создать нового пользователя или изменить параметры существующего Ручная регистрация, смена имени/админа/пароля password Сменить пароль пользователя Самый частый запрос от пользователей prune-devices Удалить все устройства и аннулировать токены пользователя При компрометации аккаунта, принудительный выход со всех устройств redact Удалить (redact) все или некоторые сообщения пользователя Удаление спама, оскорблений, утечек данных redact-status Показать прогресс операции redact Контроль долгого процесса удаления сообщений search Быстрый поиск по имени пользователя Удобный алиас для list -n shadow-ban Теневой бан — пользователь не видит, что забанен, но не может ничего делать Борьба с троллями без их оповещения suspend Полная приостановка аккаунта (нельзя входить, отправлять сообщения) Временная блокировка нарушителя whois Показать активные сессии, устройства и токены пользователя Проверка, с каких устройств залогинен человек Это одна из самых мощных и часто используемых групп команд в synadm — почти всё администрирование пользователей делается именно через synadm user.

Настройка Synadm Сразу после установки запустите настроку утилиты с помощью команды: synadm config Вот подробное описание вопросов, которые задаст мастер настройки: 1. Synapse admin user name []: Что это Локальная часть имени администратора (без @ и домена). Т.е. если в Synapse есть администратор с логоном root, то полный MXID будет @root:ваш.домен.tld. Зачем нужен synadm использует это имя для формирования запросов к Admin API, когда нужно указать, от чьего имени выполняется действие. Это поле помогает synadm понять, чей именно access token вы используете. В некоторых командах (например synadm user details) это имя подставляется автоматически, если не указан другой пользователь. Взаимосвязь Прямо влияет на поле Homeserver name (см. ниже) — если вы выбрали auto-retrieval, synadm попытается узнать домен именно из этого MXID. Если имя указано неправильно → команды с --user-id по умолчанию могут не сработать. Рекомендация Указывайте реальное имя существующего администратора. Если введёте выдуманное — потом можно изменить через synadm config -u. 2. Synapse admin user token [NOT SET]: Что это Access token администратора (строка вида syt_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX). Зачем нужен Это основной способ аутентификации synadm при обращении к Admin API Synapse. Без правильного токена почти все команды будут возвращать 401 Unauthorized. Взаимосвязь Токен привязан к конкретному пользователю (который вы указали в поле 1). Если токен от другого пользователя → команды выполнятся от его имени (если у него есть права). Токен должен быть действующим и принадлежать пользователю с правами администратора. Что делать, если токена пока нет Можно ввести любой текст на первом этапе (чтобы пройти wizard), а потом обновить: synadm config -t "syt_настоящий_токен" Где взять Element → Настройки → Справка и о программе → Access Token. 3. Synapse protocol (http, unix) [http]: Что это Протокол, по которому synadm будет подключаться к Synapse. Варианты http — обычное http-подключение (по TCP, например http://localhost:8008) unix — подключение через unix-сокет (файл на диске, например /var/run/synapse.sock) Взаимосвязь Определяет, как интерпретировать следующее поле — Synapse base URL. Если выбрали unix → в следующем поле нужно будет указать путь к сокету, а не URL. Рекомендация Оставляйте http — это стандарт для большинства установок Synapse (особенно в deb-пакете). 4. Synapse base URL (or path to socket) [http://localhost:8008]: Что это Адрес, по которому synadm будет обращаться к серверу Synapse. Варианты http://localhost:8008 — стандартный порт Client-Server API в deb-пакете https://matrix.ваш.домен.tld — если у вас настроен reverse-proxy с TLS /var/run/synapse.sock — если используете unix-сокет Взаимосвязь Должен соответствовать настройкам listeners в homeserver.yaml Synapse. Если Synapse слушает только на 127.0.0.1 — localhost подойдёт идеально. Если вы указали https — следующий параметр Verify certificate станет важным. Рекомендация Для контейнера и локального доступа — оставляйте http://localhost:8008. 5. Synapse Admin API path [/_synapse/admin]: Что это Базовый путь к Admin API на вашем сервере. Зачем Synapse по умолчанию использует именно /_synapse/admin. Некоторые форки или кастомные сборки могут иметь другой путь. Взаимосвязь synadm добавляет этот путь ко всем запросам. Например: http://localhost:8008/_synapse/admin/v2/users Рекомендация Оставляйте дефолтное значение — /_synapse/admin. 6. Matrix API path [/_matrix]: Что это Базовый путь к стандартному Matrix Client-Server API. Зачем Некоторые команды synadm (особенно из группы matrix) используют обычный Matrix API, а не Admin API. Взаимосвязь Используется для команд типа synadm matrix whoami, synadm matrix login и т.д. Рекомендация Оставляйте дефолт — /_matrix. 7. Default output format (yaml, json, minified, human, pprint): Что это Формат, в котором synadm будет показывать результаты по умолчанию. Варианты human — красивые таблицы/списки в терминале (самый читаемый) yaml — структурированный, удобно копировать в конфиги json — обычный JSON minified — сжатый JSON (для скриптов) pprint — красивый вывод через Python pprint Взаимосвязь Можно переопределить в любой команде флагом --output или -o, например: synadm user list -o json Рекомендация human — лучший выбор для работы в терминале. 8. Default http timeout [30]: Что это Сколько секунд synadm будет ждать ответа от Synapse перед тем, как выдать ошибку таймаута. Взаимосвязь Если сервер очень медленный (например, через интернет с большим пингом) — можно увеличить до 60–120. Для localhost — 30 секунд более чем достаточно. Рекомендация Оставляйте 30. 9. Homeserver name ("auto-retrieval" or the domain part in your MXID) [auto-retrieval]: Что это Домен вашего сервера (server_name в Synapse). Варианты auto-retrieval — synadm сам спросит у сервера (через .well-known или /_matrix/versions) конкретный домен — например matrix.example.com Взаимосвязь Если вы выбрали auto-retrieval → следующий параметр Server discovery mode становится активным. Используется для формирования правильных путей и проверки токена. Рекомендация Оставляйте auto-retrieval — это самый надёжный вариант. 10. Verify certificate [True]: Что это Включена ли проверка SSL/TLS-сертификата при подключении по https. Взаимосвязь Если вы используете http://localhost:8008 — проверка не применяется (игнорируется). Если укажете https://... → при True synadm будет проверять сертификат (и может упасть, если он самоподписанный). Рекомендация Оставляйте True. Если используете самоподписанный сертификат — потом можно изменить на False через synadm config -u. 11. Server discovery mode (used with homeserver name auto-retrieval) (well-known, dns) [well-known]: Что это Способ, которым synadm узнаёт настоящий домен сервера, если выбран auto-retrieval. Варианты well-known — через файл /.well-known/matrix/server или /.well-known/matrix/client (рекомендуемый) dns — через SRV-записи в DNS (_matrix._tcp.example.com) Взаимосвязь Работает только если Homeserver name = auto-retrieval. well-known — это то, что используют почти все клиенты и инструменты. Рекомендация Оставляйте well-known. Итоговая взаимосвязь (коротко) admin user name → используется для формирования MXID и привязки токена ↓ admin user token → основной ключ аутентификации ↓ protocol + base URL → куда именно synadm подключается ↓ Admin API path + Matrix API path → правильные пути внутри URL ↓ output format → как показывать результаты ↓ timeout → сколько ждать ответа ↓ Homeserver name + discovery mode → помогает правильно формировать запросы и проверять окружение ↓ Verify certificate → безопасность при использовании https После завершения wizard все эти параметры сохраняются в файле /root/.config/synadm.yaml и используются по умолчанию во всех командах. Если захотите что-то поменять позже — просто выполните synadm config -u (обновление интерактивно) или измените файл вручную.

Почему в контейнере интернет / apt может не работать В обычной системе (не в контейнере) всё обычно работает «из коробки», потому что там сеть настраивается автоматически. В контейнере всё немного по-другому: Контейнер получает интернет через хост-машину (компьютер, на котором запущен Incus). DNS (то, что превращает google.com в IP-адрес) тоже должен приходить от хоста. Очень часто в новых Debian/Ubuntu внутри контейнера включается штука под названием systemd-resolved — она пытается сама настроить DNS, но в контейнере у неё это получается плохо или вообще не получается. В итоге в файле /etc/resolv.conf оказывается либо пусто, либо только строка nameserver 127.0.0.53, либо вообще ничего полезного → интернет не работает, apt update зависает или очень медленно идёт. Это одна из самых частых проблем у новичков с контейнерами. Самый простой и надёжный способ исправить (для большинства случаев) Зайдите в контейнер и выполните эти 4 команды подряд: # 1. Отключаем систему, которая мешает systemctl disable --now systemd-resolved # 2. Удаляем старый (неправильный) файл rm -f /etc/resolv.conf # 3. Создаём нормальный файл с публичными DNS-серверами echo "nameserver 8.8.8.8" > /etc/resolv.conf echo "nameserver 1.1.1.1" >> /etc/resolv.conf # 4. (опционально) Защищаем файл от перезаписи chattr +i /etc/resolv.conf После этого сразу попробуйте: ping 8.8.8.8 ping google.com apt update Должно заработать почти мгновенно. Почему именно эти DNS-сервера 8.8.8.8 → Google Public DNS 1.1.1.1 → Cloudflare DNS Они быстрые, надёжные, находятся по всему миру и почти никогда не падают. Что будет после перезагрузки контейнера? Если вы не поставили chattr +i, то после перезапуска контейнера файл /etc/resolv.conf может снова стать неправильным. Тогда просто повторите команды 1–3 заново (или сделайте маленький скрипт, который запускается при старте). Короткая памятка (скопируйте и сохраните) # Быстрый фикс DNS в контейнере Debian/Ubuntu systemctl disable --now systemd-resolved rm -f /etc/resolv.conf echo "nameserver 8.8.8.8" > /etc/resolv.conf echo "nameserver 1.1.1.1" >> /etc/resolv.conf # Чтобы не слетало после перезагрузки: chmod 644 /etc/resolv.conf # Проверка ping google.com apt update Теперь интернет должен работать стабильно.

Для нормального мониторинга и управления сетью на Linux (в частности Debian/Ubuntu) в 2025–2026 годах большинство администраторов ставят следующий набор утилит. Уровни: must-have (ставят почти всегда), очень полезные (80–90% случаев) и специализированные (по ситуации). Must-have (базовый набор, ставьте всегда) sudo apt update sudo apt install -y \ iproute2 # ip, ss, tc — современная замена ifconfig/netstat/route net-tools # ifconfig, netstat, route (ещё часто нужны для старых скриптов) iputils-ping # ping (иногда не стоит по умолчанию) traceroute # классический traceroute dnsutils # dig, nslookup whois curl # тестирование HTTP/HTTPS/API wget tcpdump # захват и анализ пакетов (самый мощный CLI сниффер) ethtool # просмотр и настройка параметров сетевой карты Очень полезные (рекомендуется ставить почти всегда) Эти утилиты дают реальное понимание «что сейчас происходит в сети». sudo apt install -y \ iftop # топ потребителей трафика в реальном времени (по соединениям) nethogs # топ потребителей трафика по процессам (очень удобно!) nload # красивый график входящего/исходящего трафика bmon # ещё один монитор пропускной способности vnstat # статистика трафика по дням/месяцам (сохраняет историю) iptraf-ng # интерактивный монитор (IP-трафик, TCP/UDP и т.д.) mtr # комбинация ping + traceroute в реальном времени speedtest-cli # тест скорости интернета (ookla) iperf3 # тестирование пропускной способности между двумя точками Для глубокого анализа и отладки sudo apt install -y \ wireshark # GUI-анализатор пакетов (tshark — консольная версия) tshark # только консольная версия wireshark (без GUI) ngrep # grep для сетевых пакетов lsof # посмотреть, какие процессы держат порты/соединения netcat-openbsd # nc — швейцарский нож для TCP/UDP socat # более мощный аналог nc nmap # сканирование портов, обнаружение устройств Минимальный «стартовый» набор одной командой (самое популярное в 2025–2026) sudo apt install -y \ iproute2 net-tools dnsutils tcpdump ethtool \ iftop nethogs nload mtr iperf3 speedtest-cli \ curl wget traceroute whois \ nmap lsof Краткая шпаргалка — для чего что используют чаще всего Задача Основные утилиты Альтернативы / продвинутые Посмотреть IP, маршруты, интерфейсы ip a, ip r, ip link ifconfig, route (устаревшие) Активные соединения ss -tuln, ss -tunap netstat Кто жрёт трафик прямо сейчас iftop, nethogs iptraf-ng, bmon История трафика за день/месяц vnstat — Захват пакетов tcpdump tshark, wireshark Тест скорости до интернета speedtest-cli fast-cli Тест между двумя серверами iperf3 -s / iperf3 -c — Путь пакетов + задержки mtr 8.8.8.8 traceroute + ping DNS-отладка dig +short, dig @1.1.1.1 nslookup, drill Настройки сетевой карты ethtool eth0 — Если вы работаете с серверами → добавьте vnstat + nethogs + iftop + mtr — это золотой стандарт 2025–2026 годов для быстрого понимания ситуации. Если мониторите много серверов → смотрите в сторону Netdata, Prometheus + node_exporter, Zabbix-agent или Cockpit (с плагином network).

Сильные плюсы Jitsi Meet по сравнению с TrueConf Server Jitsi Meet выделяется как open-source решение, которое предлагает большую гибкость и контроль без компромиссов, характерных для проприетарных продуктов вроде TrueConf. Вот ключевые преимущества, которые делают его сильнее в определенных сценариях (особенно для тех, кто ценит свободу, кастомизацию и отсутствие скрытых ограничений): Полностью open-source и бесплатный без ловушек: В отличие от TrueConf, где free-версия требует ежегодного продления и ограничивает конференции до 10 участников, Jitsi не имеет лицензионных ограничений, vendor-lock-in или скрытых платежей. Вы можете использовать его вечно без активации, и весь код доступен для аудита или модификации. Полный контроль над данными и приватностью: Само-хостинг позволяет держать все данные на вашем сервере, без облачных зависимостей. Это идеально для compliance (GDPR, HIPAA) и конфиденциальных сред, где TrueConf free все равно требует интернета для активации и имеет лимиты на внешние подключения (1 гость, 1 SIP). Браузерный доступ без установки: Участники присоединяются по ссылке через любой браузер (WebRTC), без нужды в клиенте. Это упрощает использование для внешних пользователей, в то время как TrueConf требует установки приложений для полного функционала, что может быть барьером. Гибкость интеграций и расширяемость: Легко интегрируется с Matrix для persistent чатов, Rocket.Chat, SIP/H.323 (без лимитов в free), и другими системами. Активное сообщество предлагает плагины для AI (шумоподавление, фон), записи, стриминга — вещи, которые в TrueConf доступны только в paid-версиях. Масштабируемость через аппаратные ресурсы: Без искусственных лимитов — до 75+ участников в HD с правильной настройкой (Jitsi Videobridge для распределения нагрузки). Для больших групп можно кластеризовать серверы, что делает его подходящим для крупных событий, где TrueConf free ограничен 10 участниками. Активное сообщество и низкие затраты на поддержку: Тысячи пользователей (market share 14.38% vs 0% у TrueConf), форумы, GSoC-проекты для новых фич. Это снижает зависимость от вендора — в отличие от TrueConf, где enterprise-кастомизация платная. Лучшая производительность в малых/средних группах: Адаптивное качество видео, низкие требования к bandwidth. Идеально для команд до 10-20 человек, где не нужна 4K, но важна стабильность без браузерных лимитов TrueConf. Эти плюсы особенно сильны для разработчиков, малого бизнеса или организаций с IT-командой, где кастомизация важнее "из коробки" фич. Можно ли сделать Jitsi лучше TrueConf, и как это сделать Jitsi можно сделать лучше TrueConf в большинстве аспектов, благодаря open-source природе — вы не ограничены вендором и можете добавить любые фичи, превзойдя даже платные версии TrueConf (например, по масштабу, интеграциям или кастомным workflow). TrueConf закрытый, так что улучшения там только через апгрейд, в то время как Jitsi позволяет бесконечную эволюцию. Вот пошаговый план, как это реализовать (на основе документации и практик сообщества): Базовая установка и оптимизация сервера: Начните с self-hosting на Linux (Ubuntu/Debian). Используйте Nginx как фронтенд для обработки веб-запросов (снижает нагрузку на Java). Перейдите на JRE11 для jicofo и videobridge — это повысит производительность. Добавьте TURN-сервер для лучшей NAT-прохождения. Это уже сделает Jitsi стабильнее TrueConf free в сетях с проблемами. Кастомизация конфигурации: Редактируйте config.js (в /etc/jitsi/meet/) для базовых улучшений: отключите ненужные фичи (AEC, NS для аудио), добавьте startWithAudioMuted=true для приватности, настройте интерфейс (удалите брендинг, кнопки). Используйте URL-параметры для динамических ссылок (например, bypass pre-join экран). Это сделает UI чище и удобнее, чем в TrueConf. Добавление продвинутых фич через API и SDK: Используйте iFrame API для встраивания в ваш сайт с кастомным контролем (events, user access). React SDK для мобильных/веб-приложений — добавьте кастомный UI, опросы, реакции. Lib-jitsi-meet для полного перестроения: создайте свой фронтенд с 4K-поддержкой, AI (интегрируйте библиотеки вроде TensorFlow для шумоподавления или фона). Это позволит превзойти TrueConf в enterprise-фичах, как удаленное управление или транскрипция, без платных апгрейдов. Масштабирование и интеграции: Добавьте несколько Videobridge для распределения нагрузки (кластеринг) — поддержка 100+ участников без лимитов. Интегрируйте с Matrix для persistent чатов, PBX для SIP/H.323 (неограниченно), или DLP для security. Для AI — подключите внешние сервисы (например, для транскрипции). Это сделает Jitsi мощнее TrueConf Enterprise в многопользовательских сценариях. Улучшение security и брендинга: Внедрите MFA, шифрование E2EE, кастомные зоны. Для брендинга: измените CSS/JS для логотипов, тем. Используйте сообщество (форум jitsi.org) для плагинов — добавьте вещи вроде webinar-регистрации или мониторинга, как в TrueConf paid. Затраты: Время разработчика (Node.js, React), но бесплатно. Если нет команды — нанимайте фрилансеров или используйте форки вроде eduMeet. В итоге Jitsi станет "вашим" продуктом, превосходящим TrueConf по гибкости, стоимости и масштабу.

Инструкция: Интерактивная страница управления скриптами в Cockpit Цель Создать страницу, где можно: запускать скрипты от root вводить параметры через поля формы (логины, пароли, имена БД и др.) видеть потоковый вывод скрипта с автоскроллингом полностью работать через интерфейс, без терминала 1️⃣ Структура модуля /usr/share/cockpit/mybutton2/ ├── manifest.json ├── index.html ├── main.js └── style.css 2️⃣ manifest.json { "version": 0, "tools": { "mybutton": { "label": "Управление сервисом", "path": "index.html" } } } 3️⃣ index.html — страница с формой <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <script src="../base1/cockpit.js"></script> <link rel="stylesheet" href="style.css"> <script src="main.js"></script> </head> <body> <h2>Настройка сервиса</h2> <form id="configForm"> <label>Имя пользователя: <input type="text" id="username" required></label><br> <label>Пароль: <input type="password" id="password" required></label><br> <label>Имя БД: <input type="text" id="dbname" required></label><br> <button type="submit">Запустить скрипт</button> </form> <div id="terminal">Готов к запуску</div> </body> </html> 4️⃣ style.css — стили #terminal { background: black; color: #00ff00; font-family: monospace; padding: 10px; height: 300px; overflow-y: auto; white-space: pre-wrap; margin-top: 10px; } form label { display: block; margin-bottom: 5px; } form input { margin-bottom: 10px; } button { padding: 5px 15px; } 5️⃣ main.js — логика интерактивной формы document.addEventListener("DOMContentLoaded", function () { const form = document.getElementById("configForm"); const terminal = document.getElementById("terminal"); form.addEventListener("submit", function (event) { event.preventDefault(); // предотвращаем стандартное обновление страницы // получаем данные из формы const username = document.getElementById("username").value; const password = document.getElementById("password").value; const dbname = document.getElementById("dbname").value; terminal.textContent = "Запуск скрипта с параметрами...\n"; // запускаем скрипт от root cockpit.spawn( ["/usr/local/bin/myscript2.sh", username, password, dbname], { superuser: "require", err: "out", pty: true } ) .stream(function(data) { terminal.textContent += data; terminal.scrollTop = terminal.scrollHeight; // автоскролл }) .done(function() { terminal.textContent += "\n[Скрипт завершён]"; terminal.scrollTop = terminal.scrollHeight; }) .fail(function(error) { terminal.textContent += "\n[Ошибка]\n" + error; terminal.scrollTop = terminal.scrollHeight; }); }); }); 6️⃣ Скрипт принимает аргументы Пример /usr/local/bin/myscript2.sh: #!/bin/bash USERNAME=$1 PASSWORD=$2 DBNAME=$3 echo "Создаём пользователя: $USERNAME" sleep 1 echo "Устанавливаем пароль: $PASSWORD" sleep 1 echo "Создаём БД: $DBNAME" sleep 1 echo "Настройка завершена!" Сделаем скрипт исполняемым: sudo chmod +x /usr/local/bin/myscript2.sh 7️⃣ Перезапуск Cockpit sudo systemctl restart cockpit 8️⃣ Использование Открыть Cockpit в браузере Перейти в Управление сервисом Заполнить форму (логин, пароль, имя БД) Нажать Запустить скрипт Смотреть вывод скрипта в терминале прямо на странице Автоскролл покажет новые строки автоматически, даже если скрипт выводит много информации. Советы Любые проверки и валидацию данных лучше делать на стороне скрипта. Не храните пароли в открытом виде в JS или HTML — Cockpit защищён, но безопасность критична. Используйте pty: true для корректного отображения потокового вывода. После изменений JS и CSS делайте Ctrl+Shift+R, чтобы браузер загрузил новые файлы.

Как узнать на каком порту слушает SSH Узнать, на каком порту слушает SSH, можно несколькими способами. Вот самые надежные и наглядные методы для Debian и других Linux-систем. Способ 1: Проверка активных слушающих портов (Самый надежный) Этот метод показывает, какие порты в данный момент реально открыты и ожидают подключений. Используем ss (современная замена netstat) sudo ss -tulpn | grep sshd Разберем ключи: -t (tcp) — показывать TCP-порты -u (udp) — показывать UDP-порты -l (listening) — только слушающие порты -p (process) — показать процесс, который слушает порт -n (numeric) — не резолвить имена (показывать цифры, работает быстрее) Пример вывода: tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1234,fd=4)) В этом примере SSH слушает порт 22 на всех интерфейсах (IPv4 и IPv6). Если вы меняли порт на 2222, вывод будет таким: tcp LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* users:(("sshd",pid=1234,fd=3)) Альтернатива с netstat Если ss не установлен или вы привыкли к netstat: sudo netstat -tulpn | grep sshd Если netstat не найден, установите его: sudo apt install net-tools Способ 2: Проверка конфигурационного файла Этот метод показывает, что написано в конфиге, но не гарантирует, что SSH реально слушает именно эти порты (например, если конфиг содержит ошибку или сервис не перезапущен). Основной конфиг grep -E "^Port" /etc/ssh/sshd_config Вывод покажет что-то вроде: Port 22 Если строка закомментирована (#Port 22), значит используется значение по умолчанию — порт 22. Проверка дополнительных конфигов (Debian 12+) В современных версиях Debian настройки могут лежать в отдельных файлах внутри каталога: grep -E "^Port" /etc/ssh/sshd_config.d/*.conf Это покажет все порты, заданные в пользовательских конфигах. Например: /etc/ssh/sshd_config.d/port.conf:Port 2222 Способ 3: Просмотр активных SSH-соединений Если кто-то уже подключен к серверу, можно увидеть, на каком порту они подключились: sudo ss -tunp | grep ESTAB | grep ssh Или: sudo netstat -tunp | grep ESTABLISHED | grep ssh Способ 4: Использование lsof Утилита lsof (list open files) тоже отлично показывает открытые порты: sudo lsof -i :22 -sTCP:LISTEN Замените 22 на любой порт, который хотите проверить. Если порт слушается, вы увидите процесс sshd. Или посмотреть все слушающие порты SSH: sudo lsof -i -sTCP:LISTEN | grep ssh Что делать, если порт не совпадает с ожидаемым? Если вы изменили порт в конфиге, перезапустили SSH, но ss показывает старый порт: Проверьте, нет ли синтаксических ошибок в конфиге: sudo sshd -t Если есть ошибки, команда укажет на них. Проверьте, запущен ли SSH: sudo systemctl status ssh Посмотрите логи — там часто пишут, на каких портах запустился SSH: sudo journalctl -u ssh | grep "listening on" Резюме: самый быстрый способ Просто запомните эту команду — она сработает в 99% случаев: sudo ss -tulpn | grep :22 Замените 22 на предполагаемый порт, если меняли его. Если порт найден, вы увидите строку с LISTEN и процессом sshd.

Снятие ограничений для Docker в Incus на Debian 13 Введение При запуске Docker внутри контейнера Incus (LXC) на Debian 13 можно столкнуться с ошибкой: OCI runtime create failed: open sysctl net.ipv4.ip_unprivileged_port_start file: permission denied Эта ошибка возникает не из-за Docker, а из-за ограничений безопасности LXC-контейнера. В данной статье объясняется, что именно блокируется и почему команда: incus config set incus-jitsi security.privileged true incus restart incus-jitsi решает проблему. Архитектура по умолчанию Стандартная схема: Host Debian 13 └── Incus container (unprivileged) └── Docker └── Docker containers По умолчанию Incus создаёт непривилегированные контейнеры (unprivileged). Это означает: UID 0 внутри контейнера ≠ root на хосте используется user namespace запрещена запись в ряд файлов /proc/sys запрещены некоторые операции с cgroups ограничены сетевые sysctl Почему Docker не запускался Docker использует: namespaces cgroups overlayfs изменение sysctl runtime runc При запуске контейнера runc применяет стандартные параметры OCI, включая попытку изменить: /proc/sys/net/ipv4/ip_unprivileged_port_start В unprivileged LXC: доступ к этому sysctl запрещён запись блокируется механизмами user namespace + AppArmor Docker получает permission denied Даже если внутри контейнера вы root — это "виртуальный" root. Что делает security.privileged true Команда: incus config set incus-jitsi security.privileged true переключает контейнер в privileged режим. После перезапуска: incus restart incus-jitsi контейнер: больше не использует user namespace UID 0 внутри контейнера = UID 0 на хосте получает расширенные права к /proc может изменять sysctl получает доступ к большему набору kernel capabilities снимаются ограничения на часть cgroup операций Фактически контейнер становится максимально близким к полноценной виртуальной машине по правам (но без собственного ядра). Почему это помогло Docker После включения privileged: runc смог записать sysctl не произошло блокировки при reopen fd container init завершился успешно Docker-контейнер стартовал То есть проблема была не в Docker, а в том, что LXC запрещал операции, необходимые для запуска вложенной контейнеризации. Что именно было снято При переходе в privileged режим: Ограничение До После User namespace включён отключён UID mapping remapped прямой Запись в /proc/sys ограничена разрешена Kernel capabilities урезаны расширены Работа Docker частично блокируется работает Важное предупреждение security.privileged=true снижает безопасность. Контейнер: получает почти полный root-доступ к хосту может потенциально повлиять на систему не изолирован так строго, как unprivileged Для production-систем рекомендуется: использовать security.nesting=true вместо privileged или запускать Docker в Incus VM (--vm) или запускать Docker непосредственно на хосте Когда допустимо использовать privileged лабораторные стенды тестовые окружения разработка домашний сервер Для публичных сервисов (например, Jitsi Meet) лучше рассмотреть VM. Итог Команда: incus config set <container> security.privileged true снимает ограничения user namespace и расширяет права контейнера до уровня, необходимого для полноценной работы Docker внутри Incus. Это решает проблему запуска, но делает контейнер менее безопасным. Оптимальный баланс между работоспособностью и безопасностью — security.nesting=true без privileged режима.

Приложение Основная функция Категория Статус в YunoHost (2026) Краткое пояснение / альтернативы / зачем ставить Vaultwarden Лёгкая реализация Bitwarden-сервера (пароль-менеджер) Password Manager Официальный (очень популярен, 126+ установок) Самый удобный self-hosted Bitwarden. E2E-шифрование, приложения на всех платформах. Diagrams.net Веб-редактор диаграмм (flowcharts, UML, network, org-charts) Diagramming Официальный Бывший draw.io. Отличная интеграция с Nextcloud/BookStack. Codi.md Коллаборативный Markdown-редактор (реал-тайм) Collaborative Notes Официальный Простой HedgeDoc-подобный инструмент для совместных заметок. Etherpad Реал-тайм совместное редактирование текста (как Google Docs для простого текста) Collaborative Editing Официальный Классика для быстрых совместных черновиков, плагины. My Mind Личный knowledge base / заметки с тегами и поиском Personal Notes Нет / wishlist Минималистичный, но мощный инструмент (не в каталоге сейчас). CryptPad Полноценный E2E-шифрованный офис (docs, sheets, kanban, whiteboard, forms) Encrypted Collaboration Официальный Самый приватный collaborative suite. OnlyOffice Офисный пакет (docs, sheets, presentations) с совместным редактированием Office Suite Официальный Интеграция с Nextcloud/File Browser, альтернатива Collabora. Reveal.js HTML-фреймворк для презентаций (Markdown, темы, экспорт PDF) Presentations Официальный Для технарей: презентации в браузере без PowerPoint. GLPI IT-Asset Management / Helpdesk (инвентаризация, тикеты, контракты) IT Service Management Официальный / community Для компаний/админов: учёт оборудования, заявки, SLA. PeerTube Remote Runner Удалённый runner для транскодирования видео в PeerTube Media Processing Нет / community Помогает разгрузить основной PeerTube-сервер (транскодинг на другом железе). Pixelfed Федеративная фото-социальная сеть (как Instagram + ActivityPub) Social / Fediverse Официальный Фотошеринг с подписками, фильтрами, приватностью. Forgejo Лёгкая альтернатива Gitea/GitHub (git-хостинг + CI) Code Hosting Официальный Форк Gitea, более community-driven. Gitea Самостоятельный git-сервер (репозитории, issues, wiki, CI) Code Hosting Официальный Лёгкий GitHub-клон, очень популярен. GitLab Полноценная DevOps-платформа (git + CI/CD + issues + wiki) Code Hosting / DevOps Официальный (но тяжёлый) Самый мощный, но жрёт ресурсы. GitLab Runner Runner для GitLab CI/CD (выполняет пайплайны) CI/CD Нет / manual Обычно ставят отдельно в Docker/контейнере. Cockpit Веб-панель управления сервером (мониторинг, systemd, storage, users) Server Management Официальный Удобный "пульт" для Linux-сервера. NodeRED Визуальный редактор потоков / IoT-автоматизация Automation / IoT Официальный Соединяет устройства, API, сервисы (IFTTT-like). n8n No-code/low-code workflow automation (Zapier self-hosted) Automation Официальный 300+ интеграций, мощный, но требует ресурсов. Documize Современная корпоративная wiki / knowledge base Documentation Нет / wishlist Красивый, с интеграциями, но не в каталоге. Dokuwiki Простая файловая wiki (без БД) Wiki Официальный Лёгкая, надёжная, плагины. BookStack Красивая wiki / knowledge base с книгами, полками, страницами Documentation Официальный Markdown + WYSIWYG, интеграция Diagrams.net. Wiki.js Современная Node.js wiki (Markdown, Git-backend, поиск) Wiki Официальный Очень гибкая, темы, аутентификация. Language Tool Server Сервер проверки грамматики/орфографии (для LibreOffice, браузеров) Writing Tools Официальный / community Альтернатива Grammarly self-hosted. Dolibarr ERP/CRM для малого бизнеса (учёт, счета, склад, контакты) ERP / CRM Официальный Полноценная система для компаний. FunkWhale Федеративный музыкальный сервис (как SoundCloud + Subsonic) Music Streaming Официальный Подкасты, альбомы, плейлисты, federation. MediaWiki Движок Википедии (самая мощная wiki) Wiki Официальный Для больших знаний-баз, расширений. Omeka S Платформа для цифровых коллекций / музеев / архивов Digital Collections Нет / community Метаданные, выставки, OAI-PMH. XWiki Очень мощная enterprise-wiki (структурированные данные, приложения) Wiki / Knowledge Base Официальный Для сложных корпоративных баз знаний. Jitsi Meet Видеоконференции (WebRTC, комнаты, запись) Video Conferencing Официальный Самый популярный open-source Zoom-заменитель. MiroTalk Простой WebRTC-видеочат (альтернатива Jitsi, легче) Video Conferencing Нет / manual Минималистичный, без сервера медиа. NodeBB Современный форум (реал-тайм, мобильный, плагины) Forum Официальный Красивый, быстрый, как Discourse. PhpBB Классический PHP-форум (темы, расширения) Forum Официальный Стабильный, но старомодный дизайн. RoundCube Веб-почта (IMAP-клиент) Webmail Официальный Классика, плагины, интеграция с YunoHost почтой. SOGo Groupware (почта + календарь + контакты + ActiveSync) Groupware / Webmail Официальный Полноценный Outlook-подобный клиент. Synapse Admin Админ-панель для Matrix Synapse (управление пользователями, комнатами) Matrix Admin Официальный Удобный GUI для модерации Matrix-сервера. Element Основной веб/мобильный клиент для Matrix Matrix Client Официальный Чистый фронтенд, без БД, лёгкий. Trilium Notes Иерархический note-taking с скриптами и клонированием Personal Knowledge Base Официальный / community Очень мощный для заметок + базы знаний. TLDraw Коллаборативный whiteboard / рисовалка (как Excalidraw) Whiteboard Нет / manual Простой, реал-тайм, экспорт SVG. Whitebophir Ещё один whiteboard (fork Excalidraw) Whiteboard Нет / manual Похож на TLDraw, иногда стабильнее. SVG-edit Веб-редактор SVG-графики Graphics Editor Нет / community Простой векторный редактор в браузере. OpenProject Project management (Gantt, задачи, wiki, форум, time-tracking) Project Management Официальный Полноценный Redmine/Asana-заменитель. Snipe-IT Управление IT-активами (hardware/software лицензии, чек-ин/аут) Asset Management Официальный Для админов: учёт ноутбуков, серверов, ПО. Redirect Прокси/редирект + плитка в портале YunoHost Proxy / Portal Официальный (очень популярен) Идеально для внешних контейнеров (твой случай!). Stirling PDF Веб-инструменты для PDF (merge, split, compress, OCR, sign) PDF Tools Официальный Всё, что нужно с PDF без Adobe. Linkwarden Bookmark-менеджер с архивацией страниц и тегами Bookmarks Нет / wishlist Как Raindrop.io self-hosted. Readeck Read-it-later + RSS (сохранение статей, чтение оффлайн) Read Later / RSS Нет / community Wallabag-подобный. Peertube Федеративная видео-платформа (YouTube + P2P) Video Platform Официальный Твой основной сервис, тяжёлый, но мощный.

Предположим, контейнер называется cont-incus-yuno-1 Вот самый простой и надёжный способ перенести контейнер cont-incus-yuno-1 на другой компьютер с помощью Incus (работает для контейнеров, даже запущенных): На исходном сервере (где контейнер сейчас работает) Создайте экспорт (рекомендуется остановить контейнер для консистентности, но можно и на живую): Вариант А — остановить (самый безопасный): incus stop cont-incus-yuno-1 incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz incus start cont-incus-yuno-1 # можно сразу запустить обратно, если нужно Вариант Б — на живую (быстрее, но есть небольшой риск несогласованности файловой системы): incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz Полезные флаги (добавляйте по желанию): --instance-only — очень рекомендуется, если не нужны снапшоты (файл будет намного меньше и быстрее создаваться) --optimized-storage — если хранилище позволяет (zfs/btrfs), делает ещё меньше размер Пример с флагами (самый популярный вариант): incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz --instance-only --optimized-storage Получится файл cont-yuno-backup.tar.gz (или как вы его назовёте) размером от нескольких сотен МБ до десятков ГБ — зависит от содержимого контейнера. Перенесите файл на другой компьютер любым удобным способом: scp rsync флешка / внешний диск облако (если объём позволяет) # пример через scp scp cont-yuno-backup.tar.gz user@новый-ip:/home/user/ На целевом сервере (куда переносите) Убедитесь, что Incus установлен и работает той же или новее версии (экспорт с более новой версии на старую часто не работает). Если контейнер использует нестандартные профили (кроме default), создайте их заранее на новом сервере: incus profile list # посмотреть, какие профили есть # если нужно — скопируйте конфиг профиля и создайте: incus profile create myprofile incus profile edit myprofile Импортируйте: incus import cont-yuno-backup.tar.gz cont-incus-yuno-1 Или с другим именем, если хотите: incus import cont-yuno-backup.tar.gz yuno-new Запустите: incus start cont-incus-yuno-1 # или incus start yuno-new Проверьте, что всё работает: incus list incus console cont-incus-yuno-1 # или incus exec ... -- bash Полезные замечания Если после импорта контейнер не стартует из-за MAC-адреса → удалите/сгенерируйте новый: # 1. Посмотреть, какой именно MAC "застрял" в базе Incus incus info incus-yuno-std | grep volatile.eth0.hwaddr # или полная картина incus config show incus-yuno-std --expanded | grep hwaddr # 2. Самый простой и безопасный способ — попросить Incus сгенерировать новый MAC incus config unset incus-yuno-std volatile.eth0.hwaddr # или явно задать новый (можно опустить — сам сгенерирует) # incus config set incus-yuno-std volatile.eth0.hwaddr 00:16:3e:xx:yy:zz # 3. Попробовать запустить incus start incus-yuno-std Если на новом сервере другое хранилище (например, был zfs, стал dir или btrfs) — импорт обычно проходит нормально, но иногда нужно указать пул: incus import cont-yuno-backup.tar.gz cont-incus-yuno-1 --storage default Размер файла и время создания/переноса — главный ограничивающий фактор. Если контейнер очень большой (>20–30 ГБ) — подумайте, не лучше ли воспользоваться rsync содержимого или incus copy по сети (если есть хоть какая-то связь между серверами).