Mac, который пускает вас внутрь и ничего не показывает

Клиент открывает свой Mac в браузере. Соединение устанавливается. Имя пользователя и пароль принимаются. А потом экран чёрный. Не ошибка и не обрыв связи. Просто чёрный, и по нему двигается курсор мыши.

Все логи говорят, что машина в порядке. Служба общего экрана запущена. Учётная запись проходит аутентификацию. Сессия разблокирована. Диск, CPU и память в норме. Нигде ничего не сообщает о проблеме.

Это стоило нам нескольких дней. Вот что это было на самом деле и почему очевидные способы проверки хуже, чем бесполезны.

Всё очевидное неверно

У Mac без монитора и с чёрным экраном есть привычный список подозреваемых. Мы прошли их все.

• Не подключён дисплей. Обычный совет: эмулятор HDMI-монитора. Мы их купили. Ничего не изменилось.
• Разрешение. Mac без монитора может стартовать с размером экрана, который не нравится некоторым клиентам. Дело было не в этом.
• Блокировка экрана. Заблокированная сессия может отдавать чёрный экран. Сессия была разблокирована.
• Сам дисплей. Мы подключили настоящий монитор к настоящему Mac mini. Физический экран тоже был чёрным.

Именно последний пункт изменил направление поиска. Машина не то чтобы не могла отправить картинку удалённому клиенту. Картинки не было вовсе.

Запущено не значит разрешено

Наш скрипт подготовки включает общий экран единственным способом, который работает без человека рядом:

launchctl enable system/com.apple.screensharing
launchctl bootstrap system   /System/Library/LaunchDaemons/com.apple.screensharing.plist

Это запускает службу. Начиная с macOS 14 собственный kickstart -activate от Apple отказывается работать без монитора, так что остаётся только это.

Но запустить службу не то же самое, что дать ей разрешение записывать экран. Запись экрана это привилегия TCC. macOS выдаёт её ровно двумя способами. Либо человек включает общий экран в Системных настройках и проходит аутентификацию. Либо MDM присылает профиль PPPC.

Без этого разрешения служба всё равно работает. Она по-прежнему слушает порт 5900. Она по-прежнему принимает ваш пароль. Просто ей нечего вам показать, на что у неё есть право.

macOS сама скажет об этом, если задать ей правильный вопрос:

$ sudo .../ARDAgent.app/Contents/Resources/kickstart     -configure -access -on -users runner -privs -all

Screen recording might be disabled. Screen Sharing or Remote
Management must be enabled from System Settings or via MDM.

Почему мы не нашли это раньше

Эту часть стоит передать дальше. Проблема была не в том, что ответ спрятан. А в том, что каждый дешёвый способ проверки говорил нам, что всё в порядке.

screencapture по SSH падает всегда. Запустите его в SSH-сессии, и TCC откажет. Неважно, выдана привилегия или нет. Он не отличает сломанную машину от рабочей, так что каждый его результат был для нас шумом.

Проверка через kickstart проходит, когда у неё нет прав. Без достаточных прав она вообще ничего не выводит. Код, который считает пустой вывод отсутствием предупреждения, видит в этом успех. Наш так и делал.

У обеих проверок одно общее свойство. Их вывод при сбое совпадает с выводом при успехе. Такая проверка не слабое доказательство. Это отсутствие доказательства, которое выдаёт себя за уверенность.

Измеряйте картинку

Единственная надёжная проверка это то, что видит клиент. Мы подключаемся как настоящий VNC-клиент, забираем один прямоугольник фреймбуфера и измеряем его. Чёрный рабочий стол это два цвета почти нулевой яркости. Рабочий выглядит иначе.

desktop        : Mac mini  1920x1080  32bpp depth24
sampled        : 273768 pixels from 1 rect(s)
mean brightness: 36.31%
distinct colours: 93828
RESULT: REAL PICTURE

Девяносто три тысячи разных цветов это рабочий стол. Два это сбой. Ничего не нужно толковать, и нет кода выхода, который можно понять неправильно. Теперь эта проверка идёт на каждой машине, прежде чем к ней подпустят клиента.

Исправление и его цена

На одной машине исправление занимает десять секунд. Откройте Системные настройки, Основные, Общий доступ. Выключите общий экран. Включите снова. Система спросит пароль администратора, и вся суть именно в этой аутентификации. Переключатель обычно уже выглядит включённым, ведь скрипт запустил службу. Но привилегию выдаёт именно это переключение.

Разрешение действует на уровне системы, поэтому переживает стирание машины между клиентами. Мы проверили это: стёрли машину и проверили снова.

Настоящая цена в том, что один раз нужен человек у машины. Это единственный ручной шаг в процессе, который в остальном полностью автоматизирован. В масштабе парка ответ это конфигурационный профиль MDM, который выдаёт привилегию заранее. Это правильное решение. И это единственное, что нельзя обойти скриптом на Mac, который ещё не зарегистрирован в MDM.

Если вы автоматизируете Mac

Отсюда стоит вынести две вещи, и только одна касается записи экрана.

Первая: в macOS есть категория состояния, до которой скрипт не дотянется. Привилегии TCC намеренно закрыты за человеком у клавиатуры или профилем MDM. Если ваша автоматизация считает, что может настроить всё, рано или поздно она выдаст машину, которая выглядит подготовленной, но таковой не является.

Вторая более общая. Прежде чем писать проверку, спросите себя, что она выведет, когда всё сломано. Если это совпадает с тем, что она выводит, когда всё работает, проверка ничего не стоит. Она отнимет больше времени, чем отсутствие проверки. У нас было две такие. Из-за них поиск занял дни, а не один вечер.