Login automático em um Mac sem monitor, e por que o macOS 27 pula esse login

Um Mac alugado precisa sobreviver sozinho a um reinício. Não tem ninguém na frente da máquina para digitar uma senha. A área de trabalho no navegador do cliente se conecta à sessão gráfica logada, então a máquina precisa voltar já logada. O login automático sem monitor no Apple Silicon é um pequeno monte de detalhes específicos, e quatro deles falham sem avisar. Um é novo no macOS 27. Aqui estão eles.

As duas configurações que ativam o login

O login automático tem duas peças. Uma preferência com o nome do usuário, e a senha guardada onde a janela de login consegue ler.

# 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)

O /etc/kcpassword é ofuscado com uma chave fixa, não criptografado. Quem consegue ler o arquivo recupera a senha. Isso só é aceitável porque a máquina só é acessível por uma rede privada, nunca pela internet pública. Em uma máquina com uma porta aberta, seria uma credencial largada à vista.

As quatro paradas silenciosas

FileVault

O FileVault criptografa o disco, e o disco precisa ser desbloqueado antes de o macOS fazer login de alguém. Em uma máquina com teclado, uma pessoa digita o desbloqueio. Sem monitor, não há ninguém para digitar, então login automático e FileVault não convivem em uma máquina em que você não pode mexer. Rodamos com o FileVault desligado e usamos a rede privada como fronteira.

A flag de bloqueio de tela

Existe uma preferência que bloqueia a tela de novo mesmo depois do login automático, pensada para máquinas que bloqueiam quando o monitor dorme. Se ela estiver ligada, a sessão sobe mas a tela fica bloqueada, e quem vê remotamente enxerga preto. Apagamos o autoLoginUserScreenLocked sempre que ativamos o login automático.

A trava de panic, que nos custou um dia

A mais sutil. Quando uma sessão de login falha, o macOS grava lastLoginPanic nas preferências da janela de login. Depois ele pula de propósito o login automático na próxima inicialização e mostra a tela de login. É um recurso de segurança, para que uma máquina que trava no login não fique em loop.

Em um Mac recém registrado, a primeiríssima inicialização estava ocupada indexando uma cópia grande do Xcode, com load average acima de 160. O login não terminou a tempo e a trava foi gravada. Todas as inicializações seguintes pularam o login automático, em uma máquina com a configuração totalmente correta.

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

Apagada com a máquina já calma, o login automático funcionou na hora, com a mesma senha e as mesmas configurações que estavam lá o tempo todo. Quase descrevemos isso como um bug de uma nova versão do macOS. Daquela vez não era. A prova foi um teste de controle: o mesmo sintoma sumiu quando a máquina não estava sobrecarregada, e a configuração por baixo nunca tinha estado errada. Essa história está junto com as outras em verificações que não podem falhar.

macOS 27: a trava em toda inicialização

Depois registramos nossos primeiros minis M6 no macOS 27, e a trava voltou. Desta vez as máquinas estavam paradas e calmas. Mesmo assim ficavam na janela de login depois de todo reinício, com o lastLoginPanic gravado de novo a cada vez.

Nossa imagem traz um LaunchAgent em /Library/LaunchAgents. Ele mantém um agente de IA de programação rodando na sessão do cliente. O script dentro dele já não fazia nada se a área de trabalho não estivesse no ar. Então suspeitamos do arquivo, não do script.

O teste foi um controle. Pegamos duas unidades M6 idênticas, no mesmo estado. Uma tinha o plist, a outra não. Reiniciamos as duas com três segundos de diferença. A que não tinha o plist fez login. A que tinha entrou em panic e parou na janela de login. Colocar o plist de volta em uma unidade que tinha feito login normalmente travou essa unidade de novo na inicialização seguinte. Então é em toda inicialização, não só na primeira.

No macOS 27, a janela de login carrega LaunchAgents de /Library/LaunchAgents durante o processo de login automático. Nas nossas máquinas, esse carregamento bastava para o login falhar e a trava ser gravada. Apagar a chave não adianta, porque a próxima inicialização grava de novo.

# 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

Tiramos o plist de /Library/LaunchAgents. Um pequeno LaunchDaemon de root agora espera a sessão do usuário existir e o Dock estar rodando. Depois carrega o agente nessa sessão. O login automático funciona em toda inicialização, e o agente inicia mais ou menos um minuto depois.

Mais dois detalhes do macOS 27 nos pegaram no caminho. Primeiro, o macOS 27 bloqueia a tela alguns segundos depois do login automático. Quando ela está bloqueada, o /dev/console pertence ao root, então não use isso para verificar se alguém está logado. Verifique o domínio gui/UID do usuário e um Dock rodando. Segundo, o Assistente de Configuração da primeira execução continua ligado à sessão. Matar esse processo derruba a sessão inteira para a janela de login e grava a trava de novo. Desative o assistente pelas chaves de preferência dele, e nunca mate o processo.

A receita que funciona