O Mac que deixa você entrar e não mostra nada

Um cliente abre o Mac dele no navegador. A conexão funciona. O usuário e a senha são aceitos. Aí a tela fica preta. Não é um erro, não é uma desconexão. É preto, com um cursor de mouse que se mexe.

Todo log diz que a máquina está bem. O serviço de Compartilhamento de Tela está rodando. A conta autentica. A sessão está desbloqueada. Disco, CPU e memória estão normais. Nada em lugar nenhum aponta um problema.

Isso nos custou vários dias. Veja o que era de verdade, e por que os jeitos óbvios de testar são piores do que inúteis.

Tudo o que é óbvio está errado

Um Mac sem monitor com a tela preta tem uma lista conhecida de suspeitos. Passamos por todos.

• Nenhum monitor conectado. O conselho de sempre é um plugue HDMI falso. Compramos. Nada mudou.
• Resolução. Um Mac sem monitor pode subir em um tamanho que alguns clientes não aceitam. Não era isso.
• O bloqueio de tela. Uma sessão bloqueada pode mostrar preto. A sessão estava desbloqueada.
• O próprio monitor. Ligamos um monitor de verdade em um Mac mini de verdade. A tela física também estava preta.

Esse último mudou o rumo da busca. A máquina não estava falhando ao mandar uma imagem para um cliente remoto. Não havia imagem nenhuma.

Rodando não é o mesmo que permitido

Nosso script de provisionamento liga o Compartilhamento de Tela do único jeito que funciona sem uma pessoa presente:

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

Isso inicia o serviço. Desde o macOS 14, o próprio kickstart -activate da Apple se recusa a rodar sem monitor, então é o que sobra.

Mas iniciar o serviço não é o mesmo que dar a ele permissão para gravar a tela. Gravação de tela é um privilégio TCC. O macOS concede esse privilégio de exatamente dois jeitos: uma pessoa liga o Compartilhamento de Tela nos Ajustes do Sistema e se autentica, ou um MDM envia um perfil PPPC.

Sem essa concessão, o serviço continua rodando. Continua escutando na porta 5900. Continua aceitando sua senha. Só não tem nada que tenha permissão para mostrar a você.

O macOS conta isso, se você fizer a pergunta certa:

$ 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.

Por que não achamos antes

Esta é a parte que vale passar adiante. O problema não era a resposta estar escondida. Era que todo jeito barato de verificar dizia que estava tudo bem.

O screencapture por SSH sempre falha. Rode em uma sessão SSH e o TCC nega, com ou sem o privilégio concedido. Ele não distingue uma máquina quebrada de uma que funciona, então todo resultado que ele nos deu era ruído.

O teste com kickstart passa quando não tem privilégio. Sem direitos suficientes, ele não mostra nada. Um código que trata saída vazia como ausência de aviso lê isso como sucesso. O nosso lia.

As duas verificações têm uma coisa em comum: a saída de falha é idêntica à saída de sucesso. Uma verificação assim não é uma prova fraca. Não é prova nenhuma, fantasiada de tranquilidade.

Meça a imagem

O único teste confiável é aquilo que o cliente vê. Conectamos como um cliente VNC de verdade, puxamos um retângulo do framebuffer e medimos. Uma área de trabalho preta tem duas cores com brilho perto de zero. Uma que funciona, não.

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

Noventa e três mil cores diferentes são uma área de trabalho. Duas são uma falha. Não precisa de interpretação, e não há código de saída para ler errado. Agora isso roda em toda máquina antes de um cliente chegar perto dela.

A solução, e quanto ela custa

Em uma máquina, a solução leva dez segundos. Abra Ajustes do Sistema, Geral, Compartilhamento. Desligue o Compartilhamento de Tela. Ligue de novo. Ele pede uma senha de administrador, e essa autenticação é o ponto todo. A chave normalmente já aparece ligada, porque o script iniciou o serviço. Alternar mesmo assim é o que concede o privilégio.

A concessão é no nível do sistema, então sobrevive à limpeza da máquina entre um cliente e outro. Confirmamos isso limpando uma unidade e verificando de novo.

O custo real é que precisa de uma pessoa na máquina, uma vez, e esse é o único passo manual em um processo que no resto é todo em script. Em escala de frota, a resposta é um perfil de configuração MDM que concede o privilégio de antemão. Essa é a solução certa, e é a única coisa que você não contorna com script em um Mac que ainda não foi registrado.

Se você automatiza Macs

Vale levar duas lições, e só uma delas é sobre gravação de tela.

A primeira é que o macOS tem uma categoria de estado que um script não alcança. Os privilégios TCC ficam de propósito atrás de uma pessoa no teclado ou de um perfil MDM. Se a sua automação supõe que consegue configurar tudo, uma hora ela vai entregar uma máquina que parece provisionada e não está.

A segunda é mais geral. Antes de escrever uma verificação, pergunte o que ela mostra quando a coisa está quebrada. Se isso for igual ao que ela mostra quando a coisa funciona, a verificação não vale nada. Ela vai custar mais tempo do que não ter verificação nenhuma. Tínhamos duas assim, e elas são o motivo de isso ter levado dias em vez de uma tarde.