Login automatico su un Mac headless, e perché macOS 27 lo salta

Un Mac a noleggio deve superare un riavvio da solo. Non c’è nessuno davanti alla macchina a digitare una password. Il desktop nel browser del cliente si aggancia alla sessione di login grafica, quindi la macchina deve tornare con l’utente già connesso. Il login automatico headless su Apple Silicon è un mucchietto di dettagli precisi, e quattro di questi falliscono in silenzio. Uno è nuovo in macOS 27. Eccoli.

Le due impostazioni che lo attivano

Il login automatico ha due parti. Una preferenza che indica l’utente, e la password salvata dove la finestra di login può leggerla.

# who logs in automatically
defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser runner

# the password, XOR-obfuscated, in /etc/kcpassword
# (padded to a multiple of 12 bytes, keyed with a fixed vector)

/etc/kcpassword è offuscato con una chiave fissa, non cifrato. Chiunque possa leggere il file può recuperare la password. È accettabile solo perché la macchina è raggiungibile solo da una rete privata, mai dall’internet pubblica. Su una macchina con una porta aperta sarebbe una credenziale lasciata in bella vista.

I quattro blocchi silenziosi

FileVault

FileVault cifra il disco, e il disco va sbloccato prima che macOS possa far entrare qualcuno. Su una macchina con tastiera lo sblocco lo digita una persona. In headless non c’è nessuno a digitarlo. Quindi login automatico e FileVault si escludono a vicenda su una macchina che non puoi toccare. Noi teniamo FileVault disattivato e usiamo la rete privata come confine.

Il flag del blocco schermo

C’è una preferenza che blocca di nuovo lo schermo anche dopo il login automatico, pensata per le macchine che si bloccano quando il monitor va in stop. Se è impostata, la sessione parte ma lo schermo è bloccato, e chi guarda da remoto vede nero. Cancelliamo autoLoginUserScreenLocked ogni volta che attiviamo il login automatico.

Il flag di panic, che ci è costato un giorno

Quello sottile. Quando una sessione di login fallisce, macOS registra lastLoginPanic nelle preferenze della finestra di login. Poi salta di proposito il login automatico all’avvio successivo e mostra invece la schermata di login. È una funzione di sicurezza, così una macchina che va in crash al login non entra in un loop.

Su un Mac appena registrato, il primissimo avvio era occupato a indicizzare una grande copia di Xcode, con un load average sopra 160. Il login non si è completato in tempo e il flag è stato impostato. Da lì ogni avvio ha saltato il login automatico, su una macchina con una configurazione del tutto corretta.

sudo defaults delete /Library/Preferences/com.apple.loginwindow lastLoginPanic
sudo shutdown -r now

Cancellato su una macchina tranquilla, il login automatico ha funzionato subito, con la stessa password e le stesse impostazioni di sempre. Stavamo quasi per segnalarlo come un bug di una nuova release di macOS. Quella volta non lo era. La prova è stata un controllo di confronto: lo stesso sintomo è sparito appena la macchina non era più sovraccarica, e la configurazione non era mai stata sbagliata. Quella storia sta insieme alle altre in controlli che non possono fallire.

macOS 27: il flag a ogni avvio

Poi abbiamo registrato i nostri primi mini M6 con macOS 27, e il flag è tornato. Questa volta le macchine erano inattive e tranquille. Restavano comunque alla finestra di login dopo ogni riavvio, con lastLoginPanic impostato di nuovo ogni volta.

La nostra immagine include un LaunchAgent in /Library/LaunchAgents. Tiene in esecuzione un agente AI di coding nella sessione del cliente. Lo script al suo interno già non faceva nulla se il desktop non era attivo. Quindi sospettavamo il file, non lo script.

Il test è stato un controllo di confronto. Abbiamo preso due unità M6 identiche nello stesso stato. Una aveva il plist, l’altra no. Le abbiamo riavviate a tre secondi di distanza. Quella senza plist ha fatto il login. Quella con il plist è andata in panic e si è fermata alla finestra di login. Rimettere il plist su un’unità che aveva fatto il login senza problemi l’ha bloccata di nuovo all’avvio successivo. Quindi succede a ogni avvio, non solo al primo.

Su macOS 27, la finestra di login carica i LaunchAgent da /Library/LaunchAgents durante il login automatico. Sulle nostre macchine quel caricamento bastava a far fallire il login e a impostare il flag. Cancellare la chiave non aiuta, perché l’avvio successivo la imposta di nuovo.

# the fix: keep the plist out of the auto-load path
sudo mv /Library/LaunchAgents/dev.example.agent.plist /opt/example/launchd/

# then load it into the user's session after login, from a root daemon
launchctl bootstrap gui/$(id -u runner) /opt/example/launchd/dev.example.agent.plist

Abbiamo spostato il plist fuori da /Library/LaunchAgents. Ora un piccolo LaunchDaemon di root aspetta che esista la sessione dell’utente e che il Dock sia in esecuzione. Poi carica l’agente in quella sessione. Il login automatico funziona a ogni avvio, e l’agente parte circa un minuto dopo.

Lungo la strada ci hanno creato problemi altri due dettagli di macOS 27. Primo, macOS 27 blocca lo schermo pochi secondi dopo il login automatico. Quando è bloccato, /dev/console appartiene a root, quindi non usarlo per capire se qualcuno è connesso. Controlla invece il dominio gui/UID dell’utente e un Dock in esecuzione. Secondo, l’Impostazione Assistita del primo avvio è ancora agganciata alla sessione. Chiuderla a forza fa cadere l’intera sessione alla finestra di login e imposta di nuovo il flag. Disattivala con le sue chiavi di preferenza, e non chiuderla mai a forza.

La ricetta che funziona