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

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

12. Установка и настройка Letsencrypt Для того, чтобы сайт открывался без проблем, используя доступ по протоколу //https необходимо создать и установить SSL сертификат. Для этого используется Let’s Encrypt - бесплатный, автоматизированный и открытый Центр Сертификации, созданный на благо всего общества организацией Internet Security Research Group (ISRG) Имя сайта должно быть зарегистрировано и у компьютера должен быть статический IP Устанавливаем certbot и зависимости sudo apt install certbot python3-certbot-nginx -y Создаём сертификат sudo certbot --nginx -d <имя.вашего.домена>

Теория 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 сервер проверяет токен, прежде чем впустить пользователя или разрешить ему выполнять действия.

Справочник по 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.

Информация о версии PeerTube Вариант 1. cd /var/www/peertube/peertube-latest && node dist/server --version Вариант 2. cd /var/www/peertube/peertube-latest && yarn --cwd . peertube --version Информация о версии PostgreSQL psql --version

Справочник по установке, настройке и эксплуатации 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).

Инструкция: Интерактивная страница управления скриптами в 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, чтобы браузер загрузил новые файлы.

20 - Аналитическое полотно Аналитическое полотно Чтобы открыть аналитическое полотно, выберите вкладку «Тепловые карты» (Heatmaps) на странице обзора прототипа. Затем выберите одну из тепловых карт или нажмите кнопку «Аналитическое полотно» (Analytic Canvas) в правом углу. На панели инструментов аналитического полотна вы можете выбрать различные инструменты для визуализации поведения пользователей. Что такое тепловые карты Тепловые карты кликов визуализируют, где пользователи кликали. Чем чаще пользователи кликают в определённой области, тем «горячее» (краснее) она становится. Таким образом, элементы в этой области, вероятно, важны для пользователя. Тепловые карты кликов При анализе тепловых карт кликов их следует рассматривать в контексте ваших сценариев использования. Перед созданием интерфейса вы определили и приоритизировали задачи пользователей и разработали интерфейс соответственно. Основные элементы должны быть легко находимыми, и вы ожидаете, что ими будут часто пользоваться. Если основные элементы «горячие», ваша гипотеза, скорее всего, верна, и пользователи ведут себя так, как вы ожидали. Если основные элементы «холодные», это обычно указывает на проблему: пользователи могут не находить элементы или не хотят использовать функцию. Неожиданные горячие области указывают на то, что пользователи ведут себя иначе, чем вы предполагали. Поддерживается пять типов тепловых карт кликов: Все клики (All Clicks) дают хорошее представление о наиболее активных зонах вашего дизайна, а также помогают легко обнаружить области, которые не привлекли внимания пользователей. Первый клик (First Click) помогает понять, какие элементы больше всего привлекают внимание пользователей и куда они кликнули сразу после загрузки экрана. Первые три клика (First three Clicks) расширяют первый клик до трёх. Элементы, которые не были задействованы в течение трёх кликов, могут быть сложными для обнаружения пользователем. Пропущенные клики (Missed Clicks) показывают клики по неактивным элементам, например, когда пользователи кликают на фон экрана. Это может указывать на то, что пользователи допустили ошибку и не поняли предполагаемого взаимодействия. Тепловые карты курсора Тепловые карты курсора работают иначе, чем тепловые карты кликов. Чем дольше курсор находится над определённой областью экрана, тем «горячее» она становится. Исследования показывают некоторую корреляцию между движением курсора и взглядом пользователя. Это означает, что длительное наведение над конкретной областью может указывать на сильный интерес пользователя, но также может означать, что пользователь просто не двигал мышь. Часто эти тепловые карты являются результатом «паттерна чтения», который обычно принимает форму буквы F. Путь пользователя Путь пользователя (User Journey) показывает, как пользователи перемещались по прототипу. По умолчанию различные пути объединяются, и общие маршруты отображаются более тёплым цветом. Вы можете отключить опцию объединения на панели свойств, чтобы показать индивидуальные потоки. В разделе свойств также можно увидеть список всех пользовательских тестов. Вы можете переключать видимость и запускать записи экрана. Видимость прокрутки Видимость прокрутки (Scroll Visibility) показывает для каждого экрана, какие части экрана были видны пользователям. Это важно для длинных экранов. Части ниже «сгиба» (нижней границы экрана) обычно просматриваются реже и отображаются более холодными цветами. Видимость прокрутки помогает определить, исследовали ли пользователи весь экран. Время прокрутки Время прокрутки (Scroll Time) показывает, на каких частях экрана пользователи провели больше всего времени. Чем больше времени пользователи проводят в определённой секции, тем теплее становится цвет. Просмотры экрана Тепловая карта просмотров (Screen Views) показывает, сколько раз экран был просмотрен пользователями по сравнению с другими экранами. Холодные цвета указывают на то, что большинство пользователей не видели экран, что может быть признаком проблем с навигацией. Время пребывания Время пребывания (Dwell Time) указывает, сколько времени пользователи провели на экране. Например, если на экране нужно заполнить форму, он обычно будет «горячим». Ключевые показатели элементов При выборе виджета или экрана вы также можете увидеть определённые KPI, связанные с этим виджетом. Эти KPI включают: Клики по виджету Клики по виджету (Widget Clicks) показывают, сколько раз на определённый виджет кликнули. Этот KPI напрямую связан с тепловыми картами. Индикатор показывает абсолютное число кликов, а положение кольца — отношение к другим виджетам в прототипе. Пример: Во время теста 5 пользователей совершили 100 кликов. Виджет A был кликнут 20 раз. Относительная частота составляет 20%. Первые клики Первые клики по виджету (First Clicks) показывают, сколько раз на определённый виджет кликнули сразу после загрузки экрана. Первые клики показывают, какие элементы больше всего привлекают внимание пользователей. Индикатор показывает абсолютное число, а положение визуализирует отношение к загрузкам экрана. Пример: На экране два элемента, A и B. Экран был загружен 10 раз, и 4 раза сразу после этого кликнули на элемент B. Относительная частота составляет 40%. Время до клика Время до клика (Time before Click) показывает, сколько секунд в среднем пользователи тратили до первого взаимодействия с данным элементом. Обычно элементы вверху экрана имеют меньшее время, чем элементы внизу. Пример: Экран загружен, и через 10 секунд пользователь взаимодействует с элементом A. Во втором тесте пользователь кликнул на элемент через 2 секунды. Среднее время до клика составляет 15 секунд. Охват тестирования Охват тестирования (Test Coverage) показывает, сколько раз экран был протестирован. Этот показатель указывает, насколько легко найти экран. Индикатор показывает абсолютное число тестов экрана в центре, а положение кольца — относительное соотношение тестов. Пример: Ваш прототип имеет два экрана и был протестирован двумя пользователями. Первый пользователь видел оба экрана, второй — только первый. Это означает, что было два теста. Относительная частота первого экрана — 100%, так как его видел каждый пользователь, а второго — 50%. Время пребывания Среднее время пребывания (Dwell Time) показывает, сколько времени пользователи в среднем провели на экране. Высокое значение может указывать на то, что пользователям пришлось выполнить много взаимодействий, например, заполнить форму. Однако это также может означать проблемы, например, с поиском нужных элементов. Индикатор показывает абсолютное время пребывания и соотносит его с общей продолжительностью теста. Пример: Было проведено пять тестов, каждый длился ровно 60 секунд. Пользователи провели 20, 30, 30, 30 и 40 секунд на первом экране. Среднее время пребывания — 30 секунд, а относительное — 50% ((20 + 30 + 30 + 30 + 40) / (5*60)). Просмотры экрана Просмотры экрана (Screen Views) показывают, сколько раз экран был показан. Если это число значительно выше, чем «Тестовые просмотры», это указывает на то, что пользователи часто возвращались к этому экрану. Индикатор показывает абсолютное число в центре, а положение кольца — относительную частоту. Пример: Ваш прототип имеет два экрана и был протестирован двумя пользователями. Первый пользователь видел оба экрана, второй — только первый. Это означает, что было три загрузки экрана. Относительная частота первого экрана — 67%, второго — 33%. Клики по фону экрана Клики по фону экрана (Screen Background Clicks) показывают, сколько раз пользователи кликнули по экрану, а не по виджету. Высокое число часто указывает на проблемы, например, пользователи ожидают, что некоторые элементы будут кликабельными. Индикатор показывает абсолютное число, а положение — относительную частоту относительно всех кликов по экрану. Пример: Во время теста на экране A три пользователя совершили 100 событий. 10 событий были на экране A. Относительная частота — 10%. Клики по виджетам экрана Клики по виджетам экрана (Screen Widget Clicks) показывают, сколько раз пользователи кликнули по элементам. Это число указывает, сколько «работы» пользователи выполнили на определённом экране. Индикатор показывает абсолютное число, а положение — относительную частоту относительно всех кликов по экрану. Пример: Во время теста на экране A три пользователя совершили 100 событий. 90 событий были на пяти виджетах экрана. Относительная частота — 90%.

Подробная инструкция по добавлению универсального самоподписанного сертификата в Nginx Самоподписанный (self-signed) сертификат — это простой и эффективный способ обеспечить HTTPS-соединение для вашего сервера Nginx, особенно в случаях, когда вы работаете без доменного имени (например, по IP-адресу), для внутренних сетей, тестирования или личного использования. Он не требует внешних удостоверяющих центров (CA), но браузеры покажут предупреждение о небезопасности, поскольку сертификат не проверен доверенным CA. Шифрование при этом работает полноценно. Эта инструкция основана на стандартных практиках и подходит для большинства дистрибутивов Linux (например, Ubuntu/Debian, CentOS). Предполагается, что Nginx уже установлен и работает. Все команды выполняются с правами root (используйте sudo). Предварительные требования Nginx установлен и настроен (проверьте: nginx -v). Доступ к серверу по SSH или консоли. Если у вас несколько серверов или контейнеров (например, с Webmin), сертификат Nginx будет независим от их собственных сертификатов. Nginx будет обрабатывать SSL на внешнем уровне, а внутренний трафик может идти по HTTP. Для доступа по IP: укажите внешний IP в поле Common Name (CN) при генерации, чтобы минимизировать предупреждения в браузере. Если у вас домен, рассмотрите бесплатный сертификат от Let's Encrypt вместо self-signed (но это выходит за рамки инструкции). Шаг 1: Создание директории для сертификатов Создайте защищенную директорию для хранения сертификата и ключа. Это стандартное место для Nginx. sudo mkdir -p /etc/nginx/ssl sudo chmod 700 /etc/nginx/ssl mkdir -p: создает директорию, если она не существует. chmod 700: обеспечивает доступ только владельцу (root), для безопасности. Шаг 2: Генерация самоподписанного сертификата Используйте утилиту openssl (обычно предустановлена; проверьте: openssl version). Это создаст ключ и сертификат в одном шаге. sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/selfsigned.key \ -out /etc/nginx/ssl/selfsigned.crt Параметры объяснения: req -x509: создает самоподписанный сертификат. -nodes: не шифрует ключ паролем (упрощает использование в Nginx). -days 3650: срок действия 10 лет (можно изменить, например, на 365 для 1 года). -newkey rsa:2048: генерирует новый RSA-ключ длиной 2048 бит (рекомендуемая длина для безопасности). -keyout: путь к приватному ключу. -out: путь к сертификату. Во время выполнения вас спросят интерактивные вопросы (Subject fields): Country Name (2 letter code): Например, RU (можно пропустить, нажав Enter). State or Province Name: Например, Moscow. Locality Name: Например, Moscow. Organization Name: Например, My Company. Organizational Unit Name: Например, IT. Common Name (CN): Важно! Укажите ваш внешний IP-адрес (например, 203.0.113.50) или домен, если есть. Это должно совпадать с адресом, по которому доступен сервер, чтобы браузер не выдавал дополнительное предупреждение о несоответствии. Email Address: Опционально. Если нужно сгенерировать сертификат без вопросов (для автоматизации), добавьте -subj "/CN=your.ip.address". Шаг 3: Установка прав доступа Приватный ключ должен быть защищен, чтобы избежать утечек. sudo chmod 600 /etc/nginx/ssl/selfsigned.key chmod 600: только владелец (root) может читать/писать. Шаг 4: Настройка конфигурации Nginx Добавьте ссылки на сертификат в конфигурационный файл Nginx. Это можно сделать глобально (для всех серверов) или в конкретном server-блоке. Откройте или создайте конфиг-файл (например, /etc/nginx/conf.d/ssl.conf для глобальной настройки или в /etc/nginx/sites-available/default для конкретного сайта). Добавьте следующие строки вне server-блоков (для глобального использования) или внутри server-блока: ssl_certificate /etc/nginx/ssl/selfsigned.crt; ssl_certificate_key /etc/nginx/ssl/selfsigned.key; Если сертификат для нескольких портов или серверов: используйте один сертификат для всех (универсальный подход). В server-блоке добавьте listen с SSL: server { listen 443 ssl; # Или ваш порт, например 8443 ssl; server_name your.ip.address; # Или _ для wildcard # Другие настройки, например location / { ... } ssl_certificate /etc/nginx/ssl/selfsigned.crt; ssl_certificate_key /etc/nginx/ssl/selfsigned.key; } Если вы проксируете трафик (например, на контейнеры с Webmin): используйте proxy_pass http://internal-ip:port; внутри location. SSL терминируется на Nginx, внутренний трафик — HTTP (безопасно в локальной сети). Важно: Создайте сертификат до добавления этих строк, иначе Nginx выдаст ошибку при проверке. Шаг 5: Проверка и перезагрузка Nginx Проверьте конфигурацию на ошибки: sudo nginx -t Если ошибка "cannot load certificate": проверьте пути к файлам или создайте сертификат заново. Перезагрузите Nginx: sudo systemctl reload nginx Или sudo nginx -s reload (если не используете systemd). Шаг 6: Тестирование в браузере Откройте https://your.ip.address:port (например, https://203.0.113.50:8443). Браузер покажет предупреждение: "Соединение не защищено" (NET::ERR_CERT_AUTHORITY_INVALID). Нажмите "Дополнительно" > "Перейти на сайт" (или аналог в вашем браузере). Для постоянного доступа: добавьте исключение в настройках браузера (в Chrome: Settings > Privacy and security > Manage certificates > Import ваш .crt файл). Если доступ по домену: предупреждение будет слабее, если CN совпадает. Проверьте SSL: используйте curl -v https://your.ip.address:port или онлайн-инструменты вроде SSL Labs (но для self-signed тест покажет A-рейтинг с предупреждением о доверии). Возможные проблемы и решения Конфликт с другими сертификатами: Не возникает, если они в разных сервисах (например, Webmin использует свой miniserv.pem). Nginx обрабатывает свой сертификат независимо. Предупреждение в браузере не уходит: Нормально для self-signed. Для полного устранения — получите доверенный сертификат (Let's Encrypt для доменов; для IP — ограниченная поддержка с коротким сроком). Nginx не стартует: Проверьте логи (sudo journalctl -u nginx или /var/log/nginx/error.log). Ошибки часто в путях или правах. Доступ по нескольким портам: Один сертификат работает для всех listen с ssl. Обновление сертификата: Когда истечет срок, повторите Шаг 2–5. Безопасность: Self-signed подходит для внутренних/личных сценариев. Для публичного доступа используйте Let's Encrypt. Эта инструкция делает настройку универсальной: один сертификат для всего Nginx.

Создаём и запускаем службу 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

Почему в контейнере интернет / 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 Теперь интернет должен работать стабильно.

Увеличение размера файла подкачки (виртуальная память, 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

Чтобы сервер работал после закрытия терминала Вариант 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 скрипт, описанный выше.