Установка и службы в macOS

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

Системная службаКопировать ссылку на заголовок

sudo sh ./install.sh --service

Устанавливается launchd LaunchDaemon, который запускается при загрузке системы без интерактивного входа. Это системная служба от root, а не пользовательский LaunchAgent.

Существующая конфигурация сохраняется, включая нестандартный сокет управления. Демон заново создаёт каталог сокета при запуске. Для старых конфигураций без явно указанного сокета среда службы задаёт /var/run/oci-mirror-proxy/admin.sock.

Стандартный системный сокет управления доступен всем локальным пользователям без sudo. Его каталог принадлежит root и имеет права 0711, а сокет — 0666; эти права восстанавливаются при каждом запуске. Через API управления локальные пользователи могут как просматривать состояние, так и менять конфигурацию прокси. Не используйте этот режим системной службы на хостах с недоверенными локальными учётными записями. Частные экземпляры и нестандартные пути сокетов сохраняют доступ только владельцу.

sudo launchctl print system/com.runui.oci-mirror-proxy
oci-mirror-proxy status
sudo launchctl kickstart -k system/com.runui.oci-mirror-proxy

Для обновления и перезапуска службы, установленной скриптом, используйте update --service. Без --service обновление не перезапускает существующую службу. Нестандартные или отредактированные определения служб не перезаписываются. При сбое настройки launchd установщик пытается восстановить прежний исполняемый файл и определение службы; конфигурация никогда не откатывается. Проверьте предупреждения о восстановлении и журналы.

Docker DesktopКопировать ссылку на заголовок

Shell-установщик с --service также пытается подключить Docker Desktop, если не указан --skip-docker. Он не перезапускает Docker автоматически; завершите активацию по его указаниям. Для службы Homebrew, вручную установленной службы или ручного восстановления выполняйте интеграцию с Docker Desktop от вошедшего в систему пользователя, без sudo:

oci-mirror-proxy dockerd plan
oci-mirror-proxy dockerd apply --restart
oci-mirror-proxy doctor
docker pull hello-world:latest

--restart перезапускает Docker Desktop и прерывает работающие контейнеры. Без него настройки сохраняются, но ожидают активации. Для отмены управляемых инструментом настроек используйте dockerd revert --restart.

Явный --restart работает и тогда, когда файл уже корректен, но Engine ещё не загрузил его.

В отличие от интеграции containerd в Linux, Docker Desktop настраивает Docker Hub через registry-mirrors; маршруты других реестров автоматически не настраиваются. CLI предупреждает о пропущенных реестрах.

Настройки Engine и успешная загрузка образа не доказывают, что трафик проходил через прокси. Проверяйте поведение Docker Desktop/containerd для установленной версии: сравните счётчики запросов прокси до и после загрузки некешированного образа либо перехватите трафик прокси. doctor проверяет конфигурацию и доступность, но не фактический маршрут загрузки. Если счётчики не изменились, не считайте ускорение работающим даже при успешных проверках.

В неинтерактивных SSH-сеансах /usr/local/bin может отсутствовать в PATH, даже если он доступен в обычном терминале. Перед использованием CLI или интеграции с Docker задайте PATH явно:

export PATH="/usr/local/bin:$PATH"

Клиентские команды обнаруживают работающие службы без чтения файлов конфигурации. Если одновременно работают пользовательский экземпляр и системная служба, выберите системную службу через --admin-socket /var/run/oci-mirror-proxy/admin.sock.

Удаление службыКопировать ссылку на заголовок

Если Docker использует этот прокси, сначала выполните oci-mirror-proxy dockerd revert --restart, пока служба работает, и убедитесь, что восстановленные настройки активны. Перезапуск прерывает работающие контейнеры. Затем остановите и отмените регистрацию службы, не удаляя конфигурацию и исполняемые файлы:

sudo launchctl bootout system/com.runui.oci-mirror-proxy
sudo rm /Library/LaunchDaemons/com.runui.oci-mirror-proxy.plist

Отказ в доступе к пользовательской конфигурацииКопировать ссылку на заголовок

Старые установки с повышенными правами или ручной запуск sudo oci-mirror-proxy serve могли оставить файлы root в пользовательском каталоге конфигурации или кеша. Обычный пользователь не может открыть частный файл config.yaml.lock, принадлежащий root.

Перед исправлением прав остановите все процессы прокси, использующие эту конфигурацию. Сначала проверьте владельца:

ls -ld "$HOME/Library/Application Support/oci-mirror-proxy"
ls -la "$HOME/Library/Application Support/oci-mirror-proxy"
ls -ld "$HOME/Library/Caches/oci-mirror-proxy"

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

sudo chown -R "$(id -un):$(id -gn)" "$HOME/Library/Application Support/oci-mirror-proxy"
sudo chown -R "$(id -un):$(id -gn)" "$HOME/Library/Caches/oci-mirror-proxy"
oci-mirror-proxy serve

Не применяйте эти команды к конфигурации системной службы или ко всему каталогу Library. Не используйте chmod 777 и не удаляйте файл блокировки: конфигурация может содержать секреты, а постоянный файл блокировки координирует параллельные процессы. Установщик не меняет владельца существующих пользовательских данных автоматически.