Luați în considerare un server fără cap ca acesta: o cutie tipică x86 la o locație la distanță, pe care o puteți inițializa de la distanță cu o imagine stoc – să zicem – Ubuntu. După ce este inițializat, vă puteți conecta doar prin ssh – sau îl puteți reseta de la distanță, adică nu puteți accesa BIOS-ul sau promptul managerului de boot (să zicem Grub 1).

Poate că este disponibil un fel de KVM, dar utilizarea KVM este foarte scumpă și trebuie să o rezervați o dată pe oră.

Având în vedere acest scenariu, se poate ajunge paranoic cu privire la problemele de boot. De exemplu:

  1. Ce se întâmplă dacă un upgrade de kernel eșuează?
  2. Ce se întâmplă cu un prompt fsck în procesul de pornire timpuriu? Probabil, ssh nu este încă disponibil …

Există alte probleme de care trebuie să fii atent?

Pentru actualizările de nucleu configurez grub (cel vechi) astfel încât preambulul menu.lst să conțină 

default saved fallback 2 # counts from 0

și prima intrare se termină cu: 

savedefault fallback

Prima intrare grub este nucleul actualizat, iar a treia este unul cunoscut care funcționează. Consultați, de asemenea, secțiunea manuală grub despre boot-ul de rezervă .

Am schimbat scriptul de pornire /etc/rc.local (pe un sistem asemănător Debian) în sensul că setarea implicită a intrării este resetată în cazul unei porniri reușite: 

grub-set-default 0

Această configurare funcționează, dar de ex pe Ubuntu acest lucru nu este implicit și trebuie să reglați manual menu.lst după fiecare actualizare a nucleului.

Furnizez 

panic=60

ca parametru al nucleului astfel încât, de ex în cazul unui parametru root= greșit sau kernel defect, sistemul repornește automat în caz de eroare.

Despre problema fsck nu sunt sigur ce este cel mai bun cale este. Pe sistemele similare Debian puteți seta 

FSCKFIX=yes

în /etc/default/rcS, care îi spune fsck să repare automat în mod implicit .

Dar dacă repararea automată eșuează, poate primesc totuși o solicitare pe care nu o pot accesa de la distanță?

Alternativ aș putea dezactiva verificarea fsck printr-un zero în al șaselea coloana din /etc/fstab – în cazul unei erori fs, ar trebui doar să reinicializeze sistemul și să restabilească copiile de rezervă – evitând astfel toate problemele fsck?

Comentarii

  • Întrebare foarte bună. Un server bare metal fără consolă la distanță sau unul scump este o mare problemă.

Răspuns

Serios, dacă furnizorul dvs. nu oferă asistență manuală gratuită (sau cel puțin ieftină) pentru cazuri extreme, este timpul să comutați. În caz contrar, cred că sunteți aproape în regulă cu configurarea dvs.

Când sistemul dvs. este atât de stricat încât fsck nu poate rezolva problema, nu mai sunt multe de făcut, în afară de o reinstalare completă. De fapt, nu am văzut acest lucru decât dacă a existat o defecțiune hardware fatală.

Un lucru de remarcat. Pentru o mașină ca aceasta, alegeți o distribuție stabilă (Debian, RHEL, SLES) și cu siguranță faceți doar upgrade după o perioadă suficient de lungă (noua versiune stabilizată timp de cel puțin 6 luni).

Răspuns

Ar trebui să căutați o găzduire furnizor care va furniza acces serial-over-ssh și va configura instalarea Linux pentru a utiliza portul serial (relevant) ca consolă (modul în care faceți acest lucru depinde de dacă sistemul folosește inițializarea de tip upstart sau sysV). Rețineți că există BIOS disponibil care va vorbi cu un port serial mai degrabă decât cu dispozitivul cu ecran încorporat. vin doar pe hardware scump.

De asemenea, trebuie să îi spuneți grub să utilizeze portul serial dacă doriți să îl controlați printr-un DTE .

Răspuns

Ceva pe care l-ați putea privi este crearea unui initrd personalizat care să includă dropbear (care rulează pe un alt port, desigur), logică suficientă pentru a vă pune în funcțiune rețeaua și poate o modalitate de a încărca unele instrumente de recuperare, dacă este necesar. Pe baza acestui fapt, puteți face o configurare a nucleului de recuperare care se va încărca cu capacitatea de rețea și vă va permite să vă înscrieți, permițându-vă să reveniți în sistem și să încercați o recuperare.

Comentarii

  • Da, sună ca un proiect destul de mare. Mi-aș putea imagina să creez un mic sistem Linux care este întotdeauna pornit primul și care acționează ca un manager de pornire (oferind în același timp ssh -access și screen ) – ar putea porni apoi nucleul real prin tehnici precum en.wikipedia.org/wiki/Kexec . Sau se poate căuta în servere care vin cu coreboot.org în locul unor BIOS-uri nenorocite din anii 80. Dar sigur, toate acestea nu pot fi configurate și întreținute în mod fiabil în câteva ore – în acest moment cu o distribuție stabilă.
  • Se pare că ' veți putea depăși o parte din efort uitându-vă la această pagină

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *