[Lugge] R: aggiornamento kernel in remoto

  • From: "gianlu]{a" <theblackangel@xxxxxxxx>
  • To: <lugge@xxxxxxxxxxxxx>
  • Date: Mon, 10 Jan 2005 10:59:54 +0100

 
>ciao a tutti,
>oggi sono alle prese con un problema che mi affligge da anni e forse
qualcuno di voi ha qualche brillante idea per farmi dormire sonni
tranquilli... il problema si 
>presenta ogni volta che decido di aggiornare il kernel dei 3 server che ho
in housing a milano (io vivo a genova, ovviamente...). Sono 3 macchine in
produzione, quindi >il system-down è punibile con la pena capitale, e ogni
volta che aggiorno il kernel passo 10 minuti di inferno per decidermi a dare
invio al "reboot" e nell'attesa che >la macchina in effetti si riavvii
correttamente. 

Ti capisco, oh come ti capisco ;)

>I servers sono 3 slackware, il kernel (monolitico) è ovviamente compilato
dai sorgenti, e se per qualunque motivo il nuovo kernel non dovesse andare
non avrei altra 
>scelta che saltare di corsa in macchina e volare a milano (considerando che
in genere i kernel li aggiorno di notte, potete immaginare quanto ne sarei
felice!).
>Immagino che questo problema affligga un bel numero di sysadmin nel mondo,
e mi chiedevo se non esistesse un modo efficace per testare il nuovo kernel
(diverso da 
>quello di comprarmi 4.000 euro di server e tenermelo in cantina per fare le
prove prima di andare online) o se esiste un tool per fare in modo che in
caso di kernel 
>panic la macchina riparta con il kernel precedente.
>Qualcuno ha qualche idea in merito ?


Potrei dirti, io ce l'ho ma te lo dico solo se mi pubblichi come fotografo
genovese emergente nel tuo sito, però non lo farò :D
Ti faccio una domanda perchè non ho capito bene la situazione, il system
down di una macchina è critico perchè ti cadono dei servizi diversi o per il
traffico che va sulle altre due ? ( A parte per il viaggio che ti devi
fare.... ) Pura curiosità ;)

A parte la soluzione da te citata, che corrisponde alle cosidette soluzioni
da manuale del sysadmin enterprise, ovvero avere un ambiente di sviluppo
"pari" all'ambiente di deployment anche per ovvie ragioni di security, su
queste ultime di solito gli ambienti di sviluppo non si mettono, direi che
ci sono alternative valide.
Un'idea potrebbe essere quella di avere + kernel di boot, ovvero salvare il
vecchio per poterlo poi far ripartire magari con lilo -r label.
Ovvero avvia il nuovo kernel una sola volta, al primo reboot.
L'unico problema è cosa succede se si inchioda il kernel?
C'è un omino a milano che pigia un bottone e rebootta la macchina, oppure
usi hardware dedicato.
Un esempio? http://www.berkprod.com/
Qui ti mostrano una watchdog card, ovvero una scheda che fa il reboot
automatico in caso di fallimento hardware o software. Quindi in caso di
kernel panic la macchina si riavvia con il vecchio kernel. 
http://www.pcwd.de/ Qui un software per linux per la scheda sopracitata.

Su certi server fujitsu ci sono delle feature watchdog integrate nella
mainboard, forse anche su altri server ma di + nin so.

Questa *potrebbe* essere una soluzione per il mondo reale, ben diverso dal
famigerato mondo della teoria.
Gian 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005
 



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 asa, giardino, arredamento e...trovi tutto con un solo click!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid(50&d-1
========----------

 Archivio delle e-mail postate in lista
 //www.freelists.org/archives/lugge/

 Prima di scrivere in m-list per favore leggi il regolamento
 http://www.lugge.net/index.php?mod=cosa_facciamo/gruppo_di_discussione

 Modifica dell'account sulla lista LUGGe
 http://www.lugge.net/index.php?mod=cosa_facciamo/gruppo_di_discussione#list



Other related posts: