Il Mac che ti fa entrare e non ti mostra niente

Un cliente apre il suo Mac nel browser. La connessione riesce. Nome utente e password vengono accettati. Poi lo schermo è nero. Non un errore, non una disconnessione. Nero, con un cursore del mouse che si muove.

Ogni log dice che la macchina sta bene. Il servizio di condivisione schermo è attivo. L’account si autentica. La sessione è sbloccata. Disco, CPU e memoria sono normali. Nessuno segnala un problema.

Ci è costato diversi giorni. Ecco cos’era davvero, e perché i modi ovvi di verificarlo sono peggio che inutili.

Tutte le ipotesi ovvie sono sbagliate

Un Mac headless con lo schermo nero ha una lista nota di sospetti. Li abbiamo esaminati tutti.

• Nessun monitor collegato. Il consiglio solito è un dummy plug HDMI. Li abbiamo comprati. Nessun cambiamento.
• Risoluzione. Un Mac headless può partire con una risoluzione che alcuni client non gestiscono bene. Non era quello.
• Il blocco schermo. Una sessione bloccata può mostrare nero. La sessione era sbloccata.
• Lo schermo stesso. Abbiamo collegato un vero monitor a un vero Mac mini. Anche lo schermo fisico era nero.

È quest’ultima prova che ha cambiato la direzione della ricerca. La macchina non stava fallendo nell’inviare un’immagine a un client remoto. Non c’era proprio nessuna immagine.

Attivo non vuol dire autorizzato

Il nostro script di provisioning attiva la condivisione schermo nell’unico modo che funziona senza una persona presente:

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

Questo avvia il servizio. Da macOS 14 il comando di Apple kickstart -activate si rifiuta di funzionare headless, quindi resta solo questo.

Ma avviare il servizio non equivale a dargli il permesso di registrare lo schermo. La registrazione dello schermo è un privilegio TCC. macOS lo concede in due soli modi. O una persona attiva la condivisione schermo in Impostazioni di Sistema e si autentica, o un MDM invia un profilo PPPC.

Senza quel permesso il servizio gira lo stesso. Ascolta ancora sulla porta 5900. Accetta ancora la tua password. Solo che non ha niente che gli sia permesso mostrarti.

macOS te lo dice, se gli fai la domanda giusta:

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

Perché non l’abbiamo trovato prima

Questa è la parte che vale la pena condividere. Il problema non era che la risposta fosse nascosta. Era che ogni modo rapido di controllare ci diceva che andava tutto bene.

screencapture via SSH fallisce sempre. Eseguilo in una sessione SSH e TCC lo blocca, che il privilegio sia concesso o no. Non distingue una macchina rotta da una che funziona, quindi ogni risultato che ci ha dato era rumore.

La verifica con kickstart passa quando non ha privilegi. Senza diritti sufficienti non stampa nulla. Il codice che tratta un output vuoto come assenza di avvisi lo legge come un successo. Il nostro faceva così.

I due controlli hanno una cosa in comune: l’output in caso di errore è identico a quello in caso di successo. Un controllo così non è una prova debole. Non è una prova, travestita da rassicurazione.

Misura l’immagine

L’unico test affidabile è ciò che vede il cliente. Ci colleghiamo come un vero client VNC, prendiamo un rettangolo del framebuffer e lo misuriamo. Un desktop nero ha due colori con luminosità quasi zero. Uno funzionante no.

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

Novantatremila colori distinti sono un desktop. Due sono un guasto. Non serve interpretare nulla, e non c’è un exit code da leggere male. Ora questo controllo gira su ogni macchina prima che un cliente possa avvicinarsi.

La soluzione, e quanto costa

Su una macchina la soluzione richiede dieci secondi. Apri Impostazioni di Sistema, Generali, Condivisione. Disattiva Condivisione schermo. Riattivala. Ti chiede una password di amministratore, e quell’autenticazione è tutto il punto. Di solito l’interruttore sembra già acceso, perché lo script ha avviato il servizio. È proprio spegnerlo e riaccenderlo che concede il privilegio.

Il permesso è a livello di sistema, quindi sopravvive alla cancellazione della macchina tra un cliente e l’altro. L’abbiamo verificato cancellando un’unità e controllando di nuovo.

Il costo vero è che serve una persona davanti alla macchina, una volta. È l’unico passaggio manuale in un processo per il resto tutto scriptato. Su una flotta la risposta è un profilo di configurazione MDM che concede il privilegio in anticipo. È la soluzione giusta. Ed è l’unica cosa che non puoi aggirare con uno script su un Mac che non hai ancora registrato.

Se automatizzi dei Mac

Ci sono due lezioni da portarsi a casa, e solo una riguarda la registrazione dello schermo.

La prima è che macOS ha una categoria di stato che uno script non può raggiungere. I privilegi TCC sono volutamente riservati a una persona alla tastiera o a un profilo MDM. Se la tua automazione dà per scontato di poter configurare tutto, prima o poi produrrà una macchina che sembra pronta e non lo è.

La seconda è più generale. Prima di scrivere un controllo, chiediti cosa stampa quando la cosa è rotta. Se è uguale a quello che stampa quando funziona, il controllo non vale nulla. Ti costerà più tempo che non averne nessuno. Noi ne avevamo due, ed è per questo che ci sono voluti giorni invece di un pomeriggio.