Vegyünk egy ilyen fej nélküli szervert: Egy tipikus x86-os doboz egy távoli helyen, amelyet távolról inicializálhat egy állomány – mondjuk – Ubuntu képpel. Az inicializálás után csak az ssh-n keresztül lehet bejelentkezni – vagy távolról is alaphelyzetbe állítani, azaz nem lehet hozzáférni a BIOS-hoz vagy a rendszerindító kezelőhöz (mondjuk a Grub 1-hez).

Talán valamilyen KVM elérhető, de a KVM használata nagyon drága, és óránként kell lefoglalnia.

Ezt a forgatókönyvet figyelembe véve paranoid lehet a rendszerindítási problémákkal kapcsolatban. Például:

  1. Mi van, ha a kernel frissítése sikertelen?
  2. Mi a helyzet az fsck-promptdal a korai indítási folyamatban? Valószínűleg az ssh még nem érhető el …

egyéb figyelemre méltó gotchák?

A rendszermag frissítéseihez úgy állítom be a grub-ot (a régit), hogy a menu.lst preambulum 

default saved fallback 2 # counts from 0

és az első bejegyzés a következővel végződik: 

savedefault fallback

Az első grub bejegyzés a frissített kernel, a harmadik pedig ismert működő. Lásd még a grub kézikönyv szakaszát a tartalék rendszerindításról .

Megváltoztattam az indítási parancsfájlt /etc/rc.local (egy Debian-szerű rendszeren) annak érdekében, hogy az alapértelmezett bejegyzés beállítása egy sikeres indítás esetén visszaálljon: 

grub-set-default 0

Ez a grub-setup működik, de pl az Ubuntuban ez nem az alapértelmezett, és minden egyes kernelfrissítés után manuálisan kell beállítania a menu.lst -t.

Szállítom 

panic=60

kernelparaméterként, amely pl hibás root= paraméter vagy megszakadt kernel esetén a rendszer hiba esetén automatikusan újraindul.

Az fsck problémáról nem tudom, mi a legjobb módja van. A Debian-szerű rendszereken beállíthat 

FSCKFIX=yes

a /etc/default/rcS fájlba, amely az fsck-nek alapértelmezés szerint automatikus javítást ad .

De ha az automatikus javítás meghiúsul, talán mégis kapok egy olyan kérdést, amelyhez nem férek hozzá távolról?

Alternatív megoldásként egyszerűen letilthatom az fsck-ellenőrzést a nulla segítségével a hatodikban /etc/fstab oszlop – fs-hiba esetén csak újra inicializálja a rendszert és visszaállítja a biztonsági másolatokat – ezzel elkerülve az fsck összes problémáját?

Megjegyzések

  • Nagyon jó kérdés. Nagy probléma egy csupasz fém szerver távoli konzol vagy drága nélkül.

Válasz

Komolyan, ha szolgáltatója szélsőséges esetekben nem kínál ingyenes (vagy legalábbis olcsó) kézi segítséget, ideje váltani. Egyébként úgy gondolom, hogy nagyjából rendben van a beállításokkal.

Ha a rendszered annyira meghibásodott, hogy az fsck nem tudja kijavítani, akkor a teljes újratelepítésen kívül nincs sok más teendő. Valójában nem láttam, hogy ez bekövetkezne, kivéve, ha végzetes hardverhiba történt.

Egy dolgot meg kell jegyezni. Egy ilyen géphez válasszon stabil terjesztést (Debian, RHEL, SLES), és mindenképpen csak frissítsen megfelelő hosszú idő után (az új verzió legalább 6 hónapig stabilizálódott).

Válasz

Tárhelyet kell keresnie szolgáltató, aki biztosítja a soros over-ssh hozzáférést és konfigurálja a Linux telepítést, hogy az (releváns) soros portot használja konzolként (ennek módja ) hogy a rendszer upstart vagy sysV típusú inicializálást használ-e.) Vegye figyelembe, hogy léteznek BIOS , amelyek soros porttal beszélnek, nem pedig a beépített képernyő eszközzel. De általában csak drága hardvereken érkeznek.

Azt is meg kell mondania a grub -nak, hogy használja a soros portot, ha azt DTE-n keresztül szeretné vezérelni. .

Válasz

Valami, amit megvizsgálhat, egy olyan egyedi initrd készítése, amely tartalmazni fogja a dropbear-t (természetesen egy másik porton fut), elegendő logika a hálózat működéséhez, és esetleg egy helyreállítási eszköz betöltésének módja, ha szükséges. Ez alapján elkészítheti a helyreállítási kernel konfigurációját, amely betöltődik a hálózati képességekkel, és lehetővé teszi az ssh beírását, lehetővé téve, hogy visszatérjen a rendszerhez és megpróbálja helyreállítani.

Megjegyzések

  • Igen, eléggé projektnek hangzik. El is tudnám képzelni egy olyan kis Linux rendszer létrehozását, amelyet mindig először indítanak el, és úgy viselkedik, mint egy rendszerindító (miközben ssh -access és screen ) – ezután olyan technikákkal indíthatja el a valódi kernelt, mint a hu.wikipedia.org/wiki/Kexec . Vagy megnézheti azokat a szervereket, amelyek a coreboot.org -val érkeznek, a 80-as évekből származó gagyi BIOS helyett. De biztos, hogy mindezt nem lehet megbízhatóan beállítani és fenntartani néhány óra alatt – ebben a pillanatban, stabil elosztással.
  • Úgy tűnik, hogy ' képes leszel spórolni az erőfeszítések egy részével, ha megnézed ezt az oldalt

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük