Эта страница поможет, если вы не знаете, с чего начать. Схемы задают вопросы по порядку, и каждый ответ сужает круг причин, пока не приведёт к выводу с решением.
Если у вас есть текст ошибки, сначала найдите его в справочнике ошибок: так быстрее.
В схемах и командах «домен» — это адрес вашего сервера Ринго, например mdm.example.ru. Команды curl выполняйте из той сети, где находится проблемное устройство: на Windows вводите curl.exe.
1. Ринго работает? Выполните на любом компьютере:
curl -s https://<домен>/health
Ответ «да»: {"status":"ok","details":{"db":{"status":"up"}}}.
2. Проблема у всех устройств? Проверьте несколько устройств в разных сетях. Ответ «да»: проблема есть у всех проверенных устройств.
| Вывод | Где решение |
|---|---|
| С1. Сервер не работает | Первые 10 минут → сервер работает: что означает каждый ответ /health. |
| С2. Общая причина | Первые 10 минут: APNs-сертификат, TLS, адреса, связь с Apple, лицензия, время. Если всё перестало работать в определённый день, выясните, что изменилось: Настройки → Аудит-лог. |
1. Страница /enroll открывается и вход проходит? Откройте https://<домен>/enroll на устройстве и войдите учётной записью Ринго или LDAP. Ответ «да»: после входа страница предлагает скачать профиль или установщик.
4. Сервер ответил 402? Выполните на сервере:
docker logs roll-deploy-backend --since 30m 2>&1 | grep 'mdm/enroll/profile'
Ответ «да»: в строке POST /mdm/enroll/profile код 402.
5. Устройство появилось в Ринго? Найдите устройство в разделе Компьютеры или Мобильные устройства по серийному номеру.
7. Агент подключился? Выполните на сервере, подставив UDID устройства:
docker logs roll-deploy-backend --since 30m 2>&1 | grep -i '<udid>' | grep 'Agent connected'
Ответ «да»: есть строка Agent connected, udid: <udid>.
8. Установка агента завершилась успешно? Посмотрите последнюю запись лога установки: на Windows — в файле C:\ProgramData\Ringo\Logs\updater.log, на Linux — командой sudo tail -1 /opt/ringo/logs/updater.log. Ответ «да»: Ringo agent was installed successfully!.
| Вывод | Где решение |
|---|---|
| Р1. Страница регистрации | Регистрация → шаг 1 |
| Р2. Лицензия исчерпана | Регистрация → лицензия |
| Р3. Установка профиля прервалась | Регистрация → шаг 2. Текст ошибки на Mac — Диагностика на устройстве. |
| Р4. Регистрация не дошла до сервера | Регистрация → шаг 3 |
| Р5. Агент на Mac | Регистрация → шаг 4, затем схема Агент |
| Р6. Ошибка регистрации агента | Ошибки регистрации на странице ОС: Windows, Linux |
| Р7. Агент не на связи | Схема Агент |
Начните со статуса команды в карточке устройства, вкладка Управление → Команды. Схема разбирает статус «В очереди». Остальные статусы сразу указывают на причину, см. выводы М5–М9.
1. Команды «В очереди» у всех устройств? Откройте вкладку Управление → Команды у нескольких устройств. Ответ «да»: у всех новые команды остаются в статусе «В очереди».
2. Push доходит до устройства? На Mac нажмите в карточке устройства Отправка пустого Push и выполните на Mac:
sudo /System/Library/PrivateFrameworks/ApplePushService.framework/apsctl status | grep -A40 'mdmclient.daemon.push.production' | grep 'last incoming push'
Ответ «да»: время last incoming push сменилось на текущее.
3. /mdm/connect доступен из сети устройства? Выполните:
curl -s -X PUT -w '\n%{http_code}\n' https://<домен>/mdm/connect
Ответ «да»: код 400 и JSON с текстом «Отсутствует тело mdm запроса».
| Вывод | Где решение |
|---|---|
| М1. Сервер не отправляет push | Команды MDM → шаги 1–3 |
| М2. Push не доходит | Команды MDM → шаг 4, Сеть → от устройств до Apple |
М3. Блокировка /mdm/connect |
Команды MDM → шаг 5, Сеть → WAF |
| М4. Устройство не обращается к серверу | Команды MDM → «В очереди» |
| М5. Статус «Отложено» | Команды MDM → «Отложено» |
| М6. Статус «Отправлено», результата нет | Команды MDM → «Отправлено» |
| М7. Статус «Ошибка» | Команды MDM → «Ошибка» |
| М8. Статус «Отменено», хотя никто не отменял | Команды MDM → «Отменено» |
| М9. Статус «Выполнено», но настройка не действует | Команды MDM → «Выполнено» |
Команды проверки службы и расположение лога агента для каждой ОС приведены на страницах macOS, Windows и Linux.
1. Служба агента запущена? Выполните на устройстве команду для его ОС.
macOS:
launchctl print system/com.ringo.agent | grep state
Windows (PowerShell от имени администратора):
C:\ProgramData\Ringo\Agent\ringo.exe status
Linux:
sudo /opt/ringo/agent/ringo status
Ответ «да»: на macOS — state = running, на Windows и Linux — Service status: Running.
2. Агент прошёл авторизацию? Найдите в логе агента последнее подключение. Ответ «да»: на macOS — запись Auth verified successfully, на Windows и Linux — socket: auth:verified.
3. Агент часто переподключается? Выполните на сервере, подставив UDID устройства:
docker logs roll-deploy-backend --since 24h 2>&1 | grep -i '<udid>' | grep -cE 'Agent connected|Disconnected'
Ответ «да»: десятки и сотни записей за сутки у устройства, которое не покидало сеть.
4. В логе агента ошибка сертификата? Ответ «да»: на Windows и Linux в логе агента есть записи с x509. На Mac проверьте сертификат сервера командами со страницы Связь агента с сервером → шаг 3.
5. Сервер отклоняет агента? Выполните на сервере:
docker logs roll-deploy-backend --since 2h 2>&1 | grep -i '<udid>' | grep -E 'same udid|decrypt'
Ответ «да»: команда нашла записи. На Windows и Linux признак того же — запись sync: got 401 в логе агента.
6. Адреса агента доступны из сети устройства? Выполните:
curl -s -o /dev/null -w '%{http_code}\n' https://<домен>/agent/manifest
curl -s "https://<домен>/socket.io/?EIO=4&transport=polling"
Ответ «да»: 200, а второй ответ начинается с 0{"sid":.
| Вывод | Где решение |
|---|---|
| А1. Агент не запущен | Шаг 1 на странице ОС: macOS, Windows, Linux. На Mac агент устанавливается MDM-командой: если MDM-команды не выполняются, перейдите к схеме Команды MDM. |
| А2. Частые переподключения | Связь агента с сервером → шаг 2 |
| А3. Ошибка сертификата | Связь агента с сервером → шаг 3 |
| А4. Сервер не принимает агента | Шаг 3 на странице ОС: macOS, Windows, Linux |
| А5. Адреса агента закрыты | Связь агента с сервером → шаг 1, Сеть → адреса |
| А6. Websocket не устанавливается | Связь агента с сервером → шаг 2. На Windows и Linux проверьте также шаг 2 на странице ОС: агент не использует прокси. |
Запуски политики показаны на странице политики и в карточке устройства на вкладке Управление → Политики.
1. Запуск политики есть на вкладке устройства? Откройте карточку устройства, вкладку Управление → Политики. Ответ «да»: в списке есть запуск этой политики.
4. Пакет не загрузился? Откройте запуск политики и прочитайте вывод шага. Ответ «да»: в выводе есть Failed to download (macOS, Linux) или Failed to download application (Windows).
| Вывод | Где решение |
|---|---|
| П1. Политика не запускается | Политики и пакеты → политика не запускается |
| П2. Агент не на связи | Схема Агент |
| П3. Шаг выполняется | Дождитесь завершения. Если шаг не уложится в таймаут скрипта (Настройки → Конфигурация скриптов), сервер завершит запуск со статусом «Не удалось». См. Статусы запуска политики. |
| П4. Ошибка скрипта | Вывод шага в запуске политики. На Mac вывод записан также в лог агента: Диагностика на устройстве → агент. |
| П5. Точка распространения недоступна | Пакет не устанавливается, пункт 1 |
| П6. Формат или установщик | Пакет не устанавливается, пункты 2–4 |
Пустой Self Service, неполная инвентаризация ПО и отсутствие ключа FileVault описаны на странице Политики и пакеты.
Проверено на Ринго 3.0.5, октябрь 2026. Тексты ошибок — Справочник ошибок, термины — Термины.