Considera un server headless come questo: un tipico box x86 in una posizione remota, che puoi inizializzare da remoto con unimmagine di Ubuntu. Dopo che è stato inizializzato puoi accedere solo tramite ssh – o resettarlo da remoto, cioè non puoi accedere al BIOS o al prompt del boot manager (diciamo Grub 1).
Forse è disponibile un qualche tipo di KVM, ma luso di KVM è molto costoso e devi prenotarlo su base oraria.
Dato questo scenario, si può diventare paranoici riguardo ai problemi di avvio. Ad esempio:
- Cosa succede se un aggiornamento del kernel fallisce?
- Che ne dici di un prompt di fsck nel processo di avvio iniziale? Probabilmente, ssh non è ancora disponibile …
Ci sono altri trucchi a cui prestare attenzione?
Per gli aggiornamenti del kernel configuro grub (quello legacy) in modo tale che il preambolo menu.lst contenga
default saved fallback 2 # counts from 0 e la prima voce termina con:
savedefault fallback La prima voce di grub è il kernel aggiornato e la terza è uno noto funzionante. Consulta anche la sezione del manuale di grub sullavvio di fallback .
Ho cambiato lo script di avvio /etc/rc.local (su un sistema simile a Debian) in modo che limpostazione della voce di default venga ripristinata in caso di avvio riuscito:
grub-set-default 0 Questa configurazione di grub funziona, ma ad es su Ubuntu questa non è limpostazione predefinita e si deve regolare manualmente menu.lst dopo ogni aggiornamento del kernel.
Fornisco
panic=60 come parametro del kernel tale che, ad es in caso di un parametro root= errato o di un kernel danneggiato, il sistema si riavvia automaticamente in caso di errore.
Riguardo al problema di fsck non sono sicuro di quale sia il migliore il modo è. Su sistemi simili a Debian puoi impostare
FSCKFIX=yes in /etc/default/rcS, che dice a fsck di riparare automaticamente per impostazione predefinita .
Ma se la riparazione automatica fallisce, forse ricevo ancora un messaggio a cui non posso accedere da remoto?
In alternativa potrei semplicemente disabilitare il controllo fsck tramite uno zero nel sesto colonna di /etc/fstab – in caso di errore fs, reinizializzerebbe semplicemente il sistema e ripristinerebbe i backup, evitando così tutti i problemi di fsck?
Commenti
- Domanda molto buona. Un server bare metal senza una console remota o costoso è un grosso problema.
Rispondi
Seriamente, se il tuo provider non offre assistenza manuale gratuita (o almeno economica) per casi estremi, è ora di cambiare. Altrimenti, penso che tu stia abbastanza bene con la tua configurazione.
Quando il tuo sistema è così guasto che fsck non può ripararlo, non cè molto altro da fare, oltre a una reinstallazione completa. In realtà non lho visto accadere a meno che non si sia verificato un guasto hardware irreversibile.
Una cosa da notare: per una macchina come questa, scegli una distribuzione stabile (Debian, RHEL, SLES) e aggiorna solo definitivamente dopo un periodo adeguatamente lungo (nuova versione stabilizzata per almeno 6 mesi).
Risposta
Dovresti cercare un hosting provider che fornirà laccesso seriale su SSH e configurerà la tua installazione di Linux per utilizzare la porta seriale (pertinente) come console (come fai dipende da se il sistema utilizza linizializzazione di tipo upstart o sysV). Nota che sono disponibili BIOS che parlerà con una porta seriale anziché con il dispositivo dello schermo integrato. Ma di solito vengono solo su hardware costoso.
Devi anche dire a grub di usare la porta seriale se vuoi controllarla tramite un DTE .
Risposta
Qualcosa che potresti esaminare è creare un initrd personalizzato che includa dropbear (in esecuzione su unaltra porta, ovviamente), logica sufficiente per far funzionare la tua rete e forse un modo per caricare alcuni strumenti di ripristino se necessario. Sulla base di ciò si potrebbe quindi creare una configurazione del kernel di ripristino che verrà caricata con funzionalità di rete e consentirà di accedere a ssh, consentendo di tornare sul sistema e tentare un ripristino.
Commenti
- Sì, sembra un bel progetto. Potrei anche immaginare di creare un piccolo sistema Linux che viene sempre avviato per primo e agisce come un gestore di avvio (fornendo al contempo
ssh-access escreen) – potrebbe quindi avviare il kernel reale tramite tecniche come en.wikipedia.org/wiki/Kexec . Oppure si può esaminare i server forniti con coreboot.org invece di qualche scadente BIOS degli anni 80. Ma certo, tutto questo non è niente che puoi configurare e mantenere in modo affidabile in poche ore, a questo punto con una distribuzione stabile. - Sembra che ' sarai in grado di risparmiare parte dello sforzo guardando questa pagina