Устранение неполадок

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

Ошибка подключения SSH

Убедитесь, что можете подключиться вручную: ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.50
Выполните rdc config machine scan-keys -m server-1 для обновления ключей хоста
Проверьте соответствие порта SSH: --port 22
Проверьте простой командой: rdc term connect -m server-1 -c "hostname"

Несоответствие ключа хоста

Если сервер был переустановлен или его SSH-ключи изменились, вы увидите “host key verification failed”:

rdc config machine scan-keys -m server-1

Справочник CLI: rdc config machine scan-keys

Эта команда получает новые ключи хоста и обновляет вашу конфигурацию.

Ошибка настройки машины

Убедитесь, что SSH-пользователь имеет доступ sudo без пароля, или настройте NOPASSWD для необходимых команд
Проверьте доступное дисковое пространство на сервере
Запустите с --debug для подробного вывода: rdc config machine setup --name server-1 --debug

Проблемы настройки, специфичные для дистрибутива

Пять официально поддерживаемых серверных ОС (Ubuntu 24.04, Debian 13, Fedora 43, openSUSE Leap 16.0, Oracle Linux 10) поставляются с различными политиками безопасности и пакетными менеджерами. Большинство установок проходит без проблем; приведённые ниже случаи охватывают исключения.

Отказы SELinux (Fedora 43, Oracle Linux 10)

Обе системы запускают SELinux в режиме принудительного применения (enforcing). rdc setup не устанавливает кастомную политику SELinux; демон Docker для каждого репозитория работает в стандартном контексте container_t. Если настройка завершается сбоем из-за отказов AVC, проверьте журнал аудита и определите домен:

sudo ausearch -m AVC -ts recent | head -40
# Или:
sudo tail -f /var/log/audit/audit.log | grep AVC

Если отказ указывает на бинарный файл renet или конкретный путь к файлу, решением почти всегда является повторная маркировка (restorecon -v /path), а не отключение SELinux. В качестве временного решения во время расследования sudo setenforce 0 переводит систему в разрешительный режим. Повторно включите принудительный режим командой sudo setenforce 1, как только убедитесь, что повторная маркировка сохранилась.

Отказы AppArmor (Ubuntu 24.04, openSUSE Leap 16.0)

Обе системы используют AppArmor по умолчанию; демон Docker для каждого репозитория использует стандартный профиль контейнера. Если контейнер внутри репозитория блокируется:

dmesg | grep -i apparmor
sudo aa-status

CRIU является известным случаем, который сталкивается с AppArmor. Renet автоматически устанавливает security_opt: apparmor=unconfined для контейнеров с меткой rediacc.checkpoint=true. Для всего остального настраивать профили AppArmor вручную не требуется. Смотрите заметки о CRIU в Правила Rediacc.

Сигнатуры ошибок пакетного менеджера

ОС	Пакетный менеджер	Типичная ошибка	Решение
Ubuntu / Debian	apt-get	`File has unexpected size (N != M). Mirror sync in progress?`	Кэш Cloudflare на границе отстаёт от источника. Повторите `apt-get update` через ~15 с; проверка целостности пройдёт при следующем опросе.
Fedora / Oracle	dnf	`Problem: nothing provides rediacc-cli`	Метаданные репозитория RPM в кэше на диске устарели. Выполните `sudo dnf clean all && sudo dnf makecache`.
openSUSE	zypper	`Repository 'rediacc' needs to be refreshed.`	Выполните `sudo zypper refresh rediacc` один раз; последующие установки должны пройти успешно.

Отсутствующий модуль btrfs (RHEL 10 / Rocky Linux 10 / AlmaLinux 10)

Если rdc config machine setup или renet system check-btrfs завершается с ошибкой:

Module btrfs not found

…сервер работает на стандартном ядре RHEL 10, которое поставляется без встроенного модуля btrfs. Это не ошибка Rediacc; RHEL 10 намеренно исключил btrfs. Решением является использование Oracle Linux 10. Oracle 10 по умолчанию использует Unbreakable Enterprise Kernel (UEK), который сохраняет btrfs. Смотрите Требования — Почему UEK? для полного объяснения.

Ошибка создания репозитория

Убедитесь, что настройка завершена: директория хранилища данных должна существовать
Проверьте дисковое пространство на сервере
Убедитесь, что бинарный файл renet установлен (при необходимости повторите настройку)

Сервисы не запускаются

Проверьте синтаксис Rediaccfile: он должен быть корректным Bash
Убедитесь, что ваш Rediaccfile использует renet compose -- (а не docker compose)
Проверьте доступность Docker-образов (рассмотрите renet compose -- pull в up())
Просмотрите логи контейнеров через Docker-сокет репозитория:

rdc term connect -m server-1 -r my-app -c "docker logs <container-name>"

Справочник CLI: rdc term connect

Или просмотрите все контейнеры:

rdc machine containers --name server-1

Справочник CLI: rdc machine containers

Ошибки отказа в доступе

Операции с репозиториями требуют root-доступа на сервере (renet запускается через sudo)
Убедитесь, что ваш SSH-пользователь состоит в группе sudo
Проверьте правильность прав доступа к директории хранилища данных

Проблемы с Docker-сокетом

У каждого репозитория свой собственный Docker daemon. При ручном выполнении Docker-команд необходимо указать правильный сокет:

# С помощью rdc term (настроено автоматически):
rdc term connect -m server-1 -r my-app -c "docker ps"

# Или вручную с указанием сокета:
docker -H unix:///var/run/rediacc/docker-2816.sock ps

Справочник CLI: rdc term connect

Замените 2816 на идентификатор сети вашего репозитория (можно найти в rediacc.json или через rdc repo status).

У `docker run` нет сети, `apt update` падает, `curl` зависает

Внутри оболочки репозитория запуск контейнера без --network host даёт изолированный контейнер только с loopback-интерфейсом, без DNS и без исходящего сетевого подключения. Команды вроде apt update, pip install, curl https://... или любое сетевое обращение немедленно завершатся ошибкой DNS.

Так задумано. Сетевая модель Rediacc использует host-сеть для каждого сервиса, обеспечиваемую через renet compose. Стандартный мост Docker с NAT обошёл бы ядерную изоляцию loopback, которая не даёт одному репозиторию обращаться к сервисам другого, поэтому демон Docker каждого репозитория настроен с "bridge": "none" и "iptables": false. Для обычного контейнера docker run просто нет маршрутизируемого моста, к которому можно подключиться.

Чтобы получить доступ к сети в разовом контейнере, используйте host-сеть:

# Inside a repository shell (rdc term connect -m <machine> -r <repo>)
docker run --rm --network host -it ubuntu bash
# Now apt update, curl, pip install all work.

Для production-сервисов используйте Rediaccfile с renet compose вместо прямого docker run. renet compose автоматически внедряет network_mode: host, метки IP сервисов и метки маршрутизации Traefik. Подробнее см. Сервисы.

Permission Denied для файлов sandbox в VS Code

При подключении через rdc vscode connect -m <machine> -r <repo> после предыдущего сеанса VS Code вы могли видеть ошибки вроде scp: .../.vscode-server/vscode-cli-*.tar.gz: Permission denied. Причиной была смешанная принадлежность файлов внутри каталога sandbox, где хранились файлы, записанные как вашим SSH-пользователем, так и внутренним пользователем rediacc.

Современные версии renet исправляют это следующим образом:

Создают рабочее пространство sandbox каждого репозитория (/mnt/rediacc/.interim/sandbox/<repo>/) с группой rediacc и установленным битом set-group-ID (режим 2775), поэтому каждый записываемый ниже файл наследует правильную группу.
Применяют umask 002 внутри среды выполнения sandbox, поэтому новые файлы создаются с правом записи для группы (0664/0775).
При запуске нормализуют существующее поддерево .vscode-server/, чтобы устаревшие файлы, оставшиеся до исправления, автоматически починились.

Если вы всё ещё видите ошибки доступа, один раз перезапустите демон Docker репозитория командой sudo systemctl restart rediacc-docker-<network-id> из оболочки на машине, чтобы выполнился проход нормализации, затем повторите rdc vscode connect.

Демон не запускается после обновления renet

Перед каждым запуском renet daemon start-foreground перезаписывает daemon.json и containerd.toml в каталоге конфигурации репозитория на основе актуальных шаблонов, поэтому репозиторий, чья конфигурация была сгенерирована более старой версией renet, автоматически подхватит новый формат. Вам не нужно запускать какие-либо команды миграции и не нужно вручную пересоздавать systemd-юнит. Достаточно перезапустить сервис:

sudo systemctl restart rediacc-docker-<network-id>

Если юнит всё ещё не стартует, проверьте журнал на конкретную ошибку:

sudo journalctl -u rediacc-docker-<network-id> --no-pager -n 50

Контейнеры созданы на неправильном Docker daemon

Если ваши контейнеры появляются на Docker daemon хост-системы вместо изолированного daemon репозитория, наиболее распространённая причина состоит в использовании sudo docker внутри Rediaccfile.

sudo сбрасывает переменные окружения, поэтому DOCKER_HOST теряется и Docker использует системный сокет (/var/run/docker.sock) по умолчанию. Rediacc блокирует это автоматически, но если вы столкнулись с этой проблемой:

Используйте docker напрямую, функции Rediaccfile уже выполняются с достаточными привилегиями
Если необходимо использовать sudo, используйте sudo -E docker для сохранения переменных окружения
Проверьте ваш Rediaccfile на наличие команд sudo docker и удалите sudo

Терминал не работает

Если rdc term не может открыть окно терминала:

Используйте встроенный режим с -c для прямого выполнения команд:
```
rdc term connect -m server-1 -c "ls -la"
```
Справочник CLI: rdc term connect
Принудительно используйте внешний терминал с --external, если встроенный режим вызывает проблемы
На Linux убедитесь, что установлен gnome-terminal, xterm или другой эмулятор терминала

Запуск диагностики

rdc doctor

Справочник CLI: rdc doctor

Эта команда проверяет вашу среду, установку renet, конфигурацию и статус аутентификации. Каждая проверка сообщает OK, Warning или Error с кратким пояснением.