Beschouw een headless server als deze: een typische x86-box op een externe locatie, die je op afstand kunt initialiseren met een standaard – zeg maar – Ubuntu-afbeelding. Nadat het is geïnitialiseerd, kun je alleen inloggen via ssh – of het op afstand resetten, dwz je hebt geen toegang tot het BIOS of de bootmanager-prompt (zeg Grub 1).
Misschien is er een soort KVM beschikbaar, maar het gebruik van KVM is erg duur en je moet het op uurbasis boeken.
In dit scenario kan men paranoïde worden over opstartproblemen. Bijvoorbeeld:
- Wat als een kernel-upgrade mislukt?
- hoe zit het met een fsck-prompt in het vroege opstartproces? Waarschijnlijk is ssh nog niet beschikbaar …
Zijn er andere valstrikken om op te letten?
Voor kernelupgrades configureer ik grub (de oude) zo dat de menu.lst preambule
default saved fallback 2 # counts from 0 en de eerste vermelding eindigt met:
savedefault fallback De eerste grub-vermelding is de geüpgradede kernel, en de derde is een bekende werkende. Zie ook de grub handleiding sectie over fallback boot .
Ik heb het opstartscript (op een Debian-achtig systeem) in die zin dat de standaardinvoer-instelling wordt gereset in het geval van een succesvolle boot:
grub-set-default 0 Deze grub-setup werkt, maar bv op Ubuntu is dit niet de standaard en men moet de menu.lst na elke kernelupdate handmatig aanpassen.
Ik lever
panic=60 als kernelparameter, zodat bijv in het geval van een verkeerde root= parameter of kapotte kernel, start het systeem automatisch opnieuw op in geval van een fout.
Over het fsck-probleem weet ik niet wat het beste is manier is. Op Debian-achtige systemen kunt u
FSCKFIX=yes in /etc/default/rcS instellen, wat fsck standaard vertelt om automatisch te repareren .
Maar als de automatische reparatie mislukt, krijg ik misschien nog steeds een prompt die ik niet op afstand kan openen?
Als alternatief zou ik fsck-checken kunnen uitschakelen via een nul in de zesde kolom van /etc/fstab – zou in het geval van een fs-fout het systeem gewoon opnieuw initialiseren en de back-ups herstellen – waardoor alle fsck-problemen worden vermeden?
Opmerkingen
- Zeer goede vraag. Een bare metal server zonder een externe console of een dure is een groot probleem.
Antwoord
Serieus, als uw provider geen gratis (of op zijn minst goedkope) handmatige assistentie biedt voor extreme gevallen, is het tijd om over te schakelen. Anders denk ik dat je redelijk goed bent met je setup.
Als je systeem zo kapot is dat fsck het niet kan repareren, is er niet veel anders te doen dan een volledige herinstallatie. Ik heb dit eigenlijk niet zien gebeuren, tenzij er een fatale hardwarefout was.
Een ding om op te merken. Kies voor een machine als deze een stabiele distributie (Debian, RHEL, SLES) en upgrade zeker alleen na een voldoende lange periode (nieuwe versie gestabiliseerd voor minimaal 6 maanden).
Antwoord
Je zou op zoek moeten zijn naar een hosting provider die seriële-over-ssh-toegang levert en uw Linux-installatie configureert om de (relevante) seriële poort als console te gebruiken (hoe u dit doet hangt af van of het systeem initialisering van het upstart- of sysV-type gebruikt). Houd er rekening mee dat er BIOS beschikbaar is die met een seriële poort communiceert in plaats van met het ingebouwde schermapparaat. Maar meestal ze komen alleen op dure hardware.
Je moet ook grub vertellen om de seriële poort te gebruiken als je deze via een DTE wilt bedienen .
Antwoord
Iets waar je naar zou kunnen kijken is het maken van een aangepaste initrd die dropbear zal bevatten (draait op een andere poort natuurlijk), genoeg logica om je netwerk op gang te krijgen en misschien een manier om, indien nodig, een aantal hersteltools te laden. Op basis hiervan zou je dan een herstelkernelconfiguratie kunnen maken die laadt met netwerkmogelijkheden en je in staat stelt om in te sshen, waardoor je terug op het systeem kunt komen en een herstelactie kunt proberen.
Opmerkingen
- Ja, het klinkt als een behoorlijk project. Ik zou me zelfs kunnen voorstellen een klein Linux-systeem te maken dat altijd als eerste wordt opgestart en als een bootmanager fungeert (terwijl het
ssh-access enscreen) – het zou dan de echte kernel kunnen opstarten via technieken zoals en.wikipedia.org/wiki/Kexec . Of je kunt naar servers kijken die worden geleverd met coreboot.org in plaats van een waardeloos BIOS uit de jaren 80. Maar zeker, dit alles is niets dat u binnen een paar uur betrouwbaar kunt instellen en onderhouden – op dit moment met een stabiele distributie. - Het lijkt erop dat u ' een deel van de moeite kunt besparen door naar deze pagina