[Lugge] R: Re: R: Re: Red Hat 7.2 kernel

  • From: "Stefano Roselli" <sroselli@xxxxxxxxxxxxxxxxxxxx>
  • To: <lugge@xxxxxxxxxxxxx>
  • Date: Thu, 17 Jan 2002 10:02:21 +0100

Grazie a tutti per le spiegazioni, nei prox giorni provo.
Saluti,
Ste.

> -----Messaggio originale-----
> Da: lugge-bounce@xxxxxxxxxxxxx [mailto:lugge-bounce@xxxxxxxxxxxxx]Per
> conto di Roberto A. Foglietta
> Inviato: giovedì 17 gennaio 2002 15.00
> A: lugge@xxxxxxxxxxxxx
> Oggetto: [Lugge] Re: R: Re: Red Hat 7.2 kernel
>
>
>
> Pachox katamail wrote:
>
> > Enterprise: dedicato ai server???
> >
> > bè, come minimo è un po' generico, non credi? del resto mi sa
> che pure il
> > multiprocessore qualcosa potrebbe averci a che fare con i server.
> > ma che saranno mai sti server???
> >
>
>
>   IMHO Sono definizioni di comodo rilasciate piu` dai commerciali che
> dagli sviluppatori. RH ad esempio usa la VM di Van Riel nonostante Linus
> abbia scelto la VM di Arcangeli perche` lo sa lui e perche` sebbene meno
> robusta di quella di Van Riel (non ho verificato mi attengo alle letture
> "canoniche" sull'argomento, ed intendo la VM di Van Riel con le patch di
> Alan Cox, senza le quali non era cosi` robusta, anyway...) nei computer
> dedicati ai desktop od al mercato soho e` piu` performante (dell'ordine
> del 10% credo).
>   Ecco quindi che delle definizioni puramente arbitrarie nascondo in
> realta` differenze a volte molto grandi, purche` si sappia apprezzare la
> differenza fra una VM e l'altra... (io mi sono limitato ad apprezzare le
> differenze teoriche di fondo non anche quelle che sono convinto vi siano
>   sulla differenza di scrittura di codice).
>   E` possibile (ma qui sto facendo delle congetture) che UP sia il
> kernel con la VM arcangeli (per desktop), il SMP per il multiprocessore
> ancora dal tree ufficiale e Enterprise sia un SMP con VM Van Riel.
>
>   I server sono, con linux, dei desktop a cui si e` avuto cura di:
>
>
>   1) compilare il kernel con solo i moduli necessari e possibilmente in
> forma monolitica (cosi` chi entra deve cambiare l'intero kernel il che
> implica un reboot, cosa non facile da nascondere, invece di un semplice
> modprobe trojan.o), compilazione che deve avvenire su altra macchina
> perche` sul server il compilatore non deve esserci altrimenti gli
> exploit-prg se li compilano direttamente sulla tua macchina (e poi il
> GCC e` troppo grande per essere sicuro) e ovviamente non servono
> i sorgenti.
>
>   1a) aver cura di scegliere Kernel dotati di VM robusta, cioe` in grado
> di operare efficientemente anche sotto grandi carichi di lavoro e
> scarsita` di RAM (per evitare DOS). Poiche` la variabilita` del carico
> di lavoro su queste macchine puo` anche essere molto grande e poiche` le
> prestazioni calano esponenzialmente oltre certi valori di carico, sono
> consigliabili macchine multiprocessore, una valanga di RAM e dischi
> SCSI/RAID ed unita` di backup a nastro (ovviamente tutto e` in relazione
> alla banda ed al servizio che si vuole offrire, se il servizio deve
> essere veloce e/o robusto, se e` di vitale importanza... etc).
> Alternativamente si puo` scegliere di ridondare il server invece di
> investire su uno solo pero` a quel punto occorre mettere a punto un
> sistema di switching automatico il che implica la possibilita` di
> monitorare il QOS = quality of service e la possibilita` di trasferire i
> processi da una macchina all'altra e/o tenerle sincronizzate, IMHO
> questo funziona solo per sopperire a sofferenze HW perche` se invece si
> vuole sopperire anche alla sofferenza  dovuta al carico di lavoro
> bisogna ricorrere alle tecniche di distribuzione del carico (traffico di
> rete, accessi DB, etc) e/o a tecniche di clustering. Tutto in relazione
> a quanto siano vitali i servizi offerti dal server.
>
>   2) eliminato tutte le interfaccie grafiche e possibilmente servizi
> quali ftp e telnet (ssh, ripeto, quando e` possibile li sostituisce).
>   Eliminati tutti i programmi inutili e magari anche quelli non
> necessari (quelli utili ma poi non cosi` necessari si possono sempre
> tenere in un'unita` non montata).
>
>   3) chiuderlo in una stanza (con temperatura, umidita` ragionevolmente
> controllate) non accessibile fisicamente ad alcuno (tranne admin) e
> collegato ad un UPS che sia in grado di comunicare lo stato delle
> batterie e di eventuali avaria al server (che al peggio va in halt
> piuttosto di essere messo down da un UPS).
>
>
>  4) tenere aggiornato il software soprattutto il SW che esporta servizi,
>
>  e poi anche quello locale per prevenire eventuali exploit locali.
>
>
>  Ma ultima ma non meno importante e` l'atteggiamento dell'admin che
>
> realmente differenzia la WS dal server.
>
>   Qualsiasi altro commento e` benvenuto, non essendo admin il mio
> mestiere (io sviluppo, attualmente, apps di controllo) ed essendo admin
> un mestiere molto vasto, abbastanza vasto da aver SEMPRE da imparare
> (meglio se si impara da un collega che da uno script-kid).
>   :D
>
>   P.S.: posso aver scritto Van Riel con una grafia sbagliata, non che
> non si meriti attenzione o per mancanza di rispetto... e` che sono certo
> non vi formalizzerete sul fatto se scrivo un nome con la grafia che mi
> pare di averlo letto (giusta o sbagliata che sia).
>   ;-)
>
>   Ciao,
> --
>    ,__    ,_     ,___    .-------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
>    ||_)   ||\    ||_    /     Proud Member & Master of the LUGGE    |
>    || \   ||¯\   ||¯      e-mail  : mailto:robang@xxxxxxxxx         |
>    ¯¯  ¯° ¯¯  ¯° ¯¯  °    linuxgrp: http://lugge.ziobudda.net       |
>    Roberto A. Foglietta   homepage: http://digilander.iol.it/robang |
>   \                       reg num : #219348 with the Linux Counter  |
>    `--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-'
>
>
> <========----------
>  Prima di scrivere in m-list per favore leggi il regolamento
>  http://lugge.ziobudda.net/benvenuto.html
>
>
>
>

<========----------
 Prima di scrivere in m-list per favore leggi il regolamento
 http://lugge.ziobudda.net/benvenuto.html



Other related posts:

  • » [Lugge] R: Re: R: Re: Red Hat 7.2 kernel