Gözetimsiz Bir Windows Sunucusunda Soğuk Reboot Sonrası Kendi Kendine Kurtarma

Part 5, box’ın soğuk bir reboot’tan sağ çıkabildiğini kanıtlamıştı: sshd kilit ekranında yanıt veriyordu, PIN girilmemişti, klavyenin başında kimse yoktu. Gerçek bir ilerlemeydi, ama makinenin ancak yarısıydı. sshd, Tailscale ve GPU power-limit görevi, biri login olmadan önce çalıştığı için temiz bir şekilde geri geliyordu. WSL2’nin içinde duran her şey — yani dockerd ve üstündeki container’lar — karanlıkta kaldı. WSL, ortada bir desktop session olmadan uyanmıyor; bir Windows Update reboot’unun ardından da bunu görecek kimse yokken, kilitli ekrana PIN yazmaya yürüyecek biri yoktu.

O boşluğu kapatmak, gözetimsiz gerçek bir desktop login’i sağlamak demekti; bunun için de önce hesabı düzeltmek gerekiyordu.

Hesabın yerel hale gelmesi gerekiyordu

Box’taki birincil hesap bir Microsoft hesabıydı — Part 5’te üzerine RDP şifresi koymaya çalıştığımda beni tıkayan, 8646 hatasını veren hesap türünün aynısı: şifre Microsoft’un sunucularında tutuluyor, yerel makinenin onu okumaya ya da ayarlamaya yetkisi yok. Auto-login de farklı bir açıdan aynı duvara toslıyor. Windows’un, hesabın şifresini yerelde tutup her boot’ta logon sürecine teslim etmesi gerekiyor; Microsoft hesabıysa ona tutacak hiçbir şey vermiyor. Yani çözüm de Part 5’in zaten bulduğuyla aynıydı: hesabı, makinenin doğrudan sahip olduğu bir şifreyle yerel hesaba dönüştürmek.

Bu, Part 5’te oluşturulan özel RDP login’inden ayrı bir hesap. Yazının geri kalanının dayandığı desktop session’ın sahibi olan birincil hesabın ta kendisi.

İnsan olmadan giriş yapmak

Yerel hesap devredeyken, Windows’un boot sırasında logon ekranını tümüyle atlamak için belgelenmiş bir mekanizması var: bir kez ayarlıyorsun, desktop o hesabın altında, kimse bir şey yazmadan açılıyor. Sonradan eklenmiş bir şey değil, standart bir Windows özelliği; üstelik yalnızca boot anında fiziksel konsolda devreye giriyor. Part 5’teki RDP hesabıysa hâlâ her seferinde kendi kimlik bilgilerini istiyor.

BitLocker bunların hepsinden önce kendi kendini açıyor

Disk hâlâ bir PIN istemi arkasında bekliyorsa yukarıdakilerin hiçbirinin önemi yok. Box’taki iki sürücü de, C: ve D:, diskte dururken BitLocker ile şifreli; ikisi de hiçbir key’e elle dokunmadan açılıyor. C:, TPM’e bağlanıyor: temiz bir boot’ta çip boot zincirini ölçüyor, hiçbir şeyin değişmediğini görüyor ve volume key’i kendiliğinden bırakıyor — fTPM 2.0, PIN yok. D:’nin kendine ait bir TPM bağlaması ise hiç yok. Autounlock koruyucusu bunun yerine C:’nin açılışına bağlı; yani C: açılır açılmaz D: de onunla birlikte açılıyor, ikinci bir istem yok, yönetilecek ikinci bir sır yok. Her iki sürücünün recovery key’i de makinenin dışında, bir password vault’ta duruyor — TPM kontrolünün kendisinin patladığı gün için.

Zincir, tetiklendiği sırayla

Elektrik geri geliyor. Part 1’de ayarlanan AC-Back, anakartı kendi kendine ayağa kaldırıyor.
TPM, C:’yi açıyor; D: de C:’nin key’ine yolcu oluyor. Windows daha hiçbir şey göstermeden her iki volume de okunabilir hâle geliyor.
SYSTEM kapsamındaki zamanlanmış görevler, hiçbir session olmadan tetikleniyor: Ollama servisi, Part 1’deki GPU power-limit’in yeniden uygulanması ve Part 4’teki Tailscale-ve-sshd watchdog’u. Part 5’in kilit ekranında zaten ulaşılabilir olduğunu kanıtladığı katman bu.
Desktop, birincil hesabın altında otomatik açılıyor.
Ancak şimdi bir keep-alive görevi, WSL2 Ubuntu dağıtımının içindeki dockerd’yi başlatıyor.
adımın en sona gelmesi şart; bu sıralamada isteğe bağlı hiçbir şey yok. Bir WSL2 dağıtımı bir kullanıcı oturumuna bağlı; SYSTEM onu, Ollama’yı başlattığı gibi ne görebiliyor ne de başlatabiliyor. Yani dockerd, gerçek bir logon’un varlığını bekliyor. Auto-login’in neden şart olduğunun — box’ı Part 5’teki gibi kilit ekranında bırakmak yerine neden gerçekten devreye girmesi gerektiğinin — bütün sebebi de bu. Görevin kendisi normal bir servis değil, bir döngü; çünkü WSL, boşta kalan bir dağıtımı bir timeout’un ardından kendiliğinden kapatıyor:

wsl -d Ubuntu -u root -- systemctl start docker; tail -f /dev/null

tail -f /dev/null hiçbir zaman çıkış yapmıyor, yani görev çalışır durumda kalıyor, bu da dağıtımı bağlı ve WSL’in idle-shutdown saatinin dışında tutuyor, bu da altındaki dockerd’yi ayakta tutuyor.

Takas

Gözetimsiz kurtarma, uptime uğruna biraz yerel güvenlikten feragat ediyor; bu da bilerek verdiğim bir karardı. Kendi diskini kendi açan, her boot’ta kendi login olan bir makine, durup şifre bekleyen bir makineye kıyasla fiziksel erişim açısından daha zayıf: o aralıkta makinenin başına geçen herkes, benimle aynı desktop’ı açık buluyor. Bu takası bilerek göze aldım — bir elektrik kesintisinin ardından kimse yokken kendi kendine geri gelmesi gereken bir box için.

Neyi kanıtladı

Auto-login ayarını doğrulayan aynı geçiş, Ollama, GPU, watchdog ve WSL görevleri için Get-ScheduledTask‘ı, her iki volume için de Get-Tpm‘i çekti. Sonra asıl test geldi: Part 5’teki gibi tam bir soğuk güç döngüsü, sonrasında da kendi hâline bırakma. Olması gerektiği gibi geri geldi; yukarıdaki zinciri adım adım izleyerek, kimse tek bir karakter yazmadan.

Box artık bir reboot’u — planlı ya da elektrik kesintisinin dayattığı — sorunsuz kaldırıyor ve kendi kendine geri geliyor: zamanlanmış görevler ve container’lar zaten çalışıyor, diskler hâlâ şifreli, odada kimse yok. Onu ayakta tutmak artık çözülmüş bir problem. Geriye kalan iş, üzerinde çalışan modele, indirilmiş hiçbir checkpoint’in bilmediği bir şeyi öğretmek.