linux user group brescia

- - - 8<- - - CUT HERE - - - 8<- - -

Avvertenza x Mav: non (ripeto NON) leggere questo messaggio.  ;-)))))))))

- - - 8<- - - CUT HERE - - - 8<- - -

#DEFINE  FLAME  NO

----- Original Message -----
From: Luca Giuzzi <giuzzi a dmf.bs.unicatt.it>

 Ciao Luca,

 Ho letto con MOLTO interesse (ed anche con MOLTO ritardo) gli sviluppi in
ML sul mio messaggio originale: siamo partiti dal concetto di "update ed
upgrade" per arrivare, dopo dissertazioni sui fs e su features che avrebbero
comportato o meno il reboot del sistema, addirittura a parlare di Intercal.

 Avrei voglia di rispondere o d'inserire almeno una nota in ogniuno dei c.ca
50 messaggi che ho letto sull'argomento ma, a parte il fatto che per me è
(quasi) sempre valida la #define flame off, sarebbe credo uno spreco di
tempo per tutti.

 Quindi risponderò solo a questa mail (con buona pace di Mav, che m'invita
ad essere più stringato), che considero la più significativa. :-)

> Il problema dell'upgrade e' che dipende strettamente dalla distribuzione
>  piuttosto che dal kernel `linux' (o bsd, o hurd o quello che si vuole).

 Io, per motivi "storici", ho una SuSE, ma solo perchè la mia "persona di
riferimento" al momento della prima installazione, aveva preso quella, mica
perchè mi facciano schifo RedHat, Caldera, Debian o altre (a parte forse
Slackware, che m'aveva dato qualche dispiacere anni fa).

 Come vedi NON sono motivi talmente forti da bloccarmi su SuSE: nel caso
salti fuori che per far girare un server come si deve è meglio usarne
un'altra sono disponibile anche al cambiamento (ci mancherebbe altro).

> Distinguiamo due casi:
>  1) applicazione di patches
>  2) upgrade globale di sistema.

 Mi sembra giusto (e quantomeno professionale) fare questa distinzione.

> Il caso 1 e' quello piu' tranquillo e quasi (ripeto: QUASI) automatico
>  per tutte le distribuzioni. Osserviamo che le patches dovrebbero
> SOLAMENTE
>  risolvere problemi noti (di sicurezza o stabilita') e non introdurre
> nuove
>  funzionalita'... in particolare una upgrade del kernel da 2.2 a 2.4
>  NON e' una patch.

 Da quanto ne sò (su Host IBM, con MVS, manutenevo un paio di prodotti di
gestione della rete del ns. CED) le cose stanno ESATTAMENTE così (IBM
docet).

 In genere il sistema (o anche il singolo prodotto: ad es. l'HTTP server) va
patchato, per risolvere i problemi riscontrati, finchè E' patchabile: quando
le "toppe" sono troppe e costituiscono una buona parcentuale del prodotto (o
del sistema) è consigliabile un UPGRADE che stabilizza e "ripulisce" il
tutto.

>  Le patches per un server VANNO  (non e' una raccomandazione, e' una
>  regola) seguite dal system administrator... altrimenti i problemi
>  sono garantiti.

 Assolutamente d'accordo: ci mancherebbe che i singoli utenti si mettessero
a patchare i prodotti. :-)

 Questo ovviamente sempre su sistemi multiutente ove c'è una netta
distinzione di ruoli (e, tendenzialmente, anche su Linux se il discorso è
serio): sul ns. Host le utenze erano del tipo:

- "sistemista" (con varie sfumature: di OS, di rete, di dBase, di sicurezza,
di sottosistema applicativo, ecc.),

- "programmatore" (SENZA possibilità di applicare patches a tutto quanto il
sistema ma "solo" ai programmi applicativi),

- "schedulatore" (modifica dei job batch ma NON dei programmi applicativi o
di sistema),

- "operatore" (controllo a runtime del sistema ma assouta impossibilità di
modificare batch o programmi),

- "utente" (praticamente data-entry e poco altro, anche se erano la
maggioranza: c.ca 2000 contro 60/70 degli altri).

> Fortunatamente sistemi tipo apt o rpm consentono di
>  automatizzare quasi completamente l'operazione (non conosco up2date e non
>  l'ho mai usato... si tratta, in pratica, di un ftp+rpm pero').
>  Una nota: la applicazione di patches e' prevista da tutti i sistemi e
>  utilizza formati vari. La cosa `carina' e' che in fase di installazione
>  il sistema identifica files di configurazione modificati (tramite un
>  checksum) e chiede cosa si vuol fare(debian)/li preserva (rh... il file
>  nuovo e' un .rpmorig)/li sostituisce (rpm... file nuovo=.rpmsave).

 Immagino che per l'applicazione di patches si debba (a meno di non voler
andare fuori standard) seguire il formato adottato dal distributore (ad es.
RPM per RedHat/SuSE/Mandrake, DEB per Debian, ecc.) e, meglio, scaricarle
direttamente dal suo sito: ho visto che SuSE, come altri, mette a
disposizione una sezione di sito apposita per l'update dell'OS e dei vari
prodotti.

> L'upgrade globale di sistema, come detto nel documento citato e'
>  "una brutta bestia". Innanzitutto una premessa: NON E' POSSIBILE
>  fra distribuzioni diverse, anche se il formato dei pacchetti e' lo stesso
>  (ad es. SuSE, RH e Mandrake usano tutte e 3 pacchetti in formato .rpm
>   ma non e' possibile fare una upgrade automatica dall'una all'altra.

 Ecco una cosa che inizialmente mi sono domandato spesso mentre da qualche
tempo ero quasi sicuro che fosse così: anche se il sistema è "più o meno" lo
stesso, proprio quel "più o meno" rende difficile (anche se non userei
l'espressione "impossibile") passare da una distro ad un'altra.
 O almeno... immagino che il buon Torvalds ci riuscirebbe senza soverchi
problemi.  ;-))))
(inutile dire che IO non ho intenzione di provarci: voglio gestire un
server, mica un jukebox). ;-)

>   In effetti non e' molto furbo nemmeno installare gli rpm di RH sotto
>   SuSE o viceversa... le dipendenze sono diverse).

 Lo immaginavo. Ad ogni modo apprezzo (__MOLTO__) questa conferma.

>  L'upgrade di una distribuzione puo' essere relativamente facile o un
>   incubo a seconda di come e' disegnato il sistema dei pacchetti e del
>   numero di bachi all'interno dell'installer (RH7.0 ne aveva, per la
>   cronaca). Il punto essenziale e' che si tratta di una installazione di
>   un nuovo sistema operativo e, sebbene non fatta ex-novo, non ci sono
>   garanzie che (ad es.) il vecchio hardware sia ancora supportato
>   piuttosto che il comando `ls' si comporti al medesimo modo
>   [la faccenda hw si riferisce soprattutto ai moduli `solo binari' per
>    alcune periferiche... d'altro canto e' anche vero che esistono schede
>    video supportate solamente da XF3 piuttosto che XF4].

 Nel mio caso, salvo eventuali sviluppi, NON ho intenzione di andare a
"giocare" con distribuzioni instabili o difficilmente upgradabili.

 Al contrario: accetto consigli su quale distro può essere considerata la
"migliore" (le virgolette DOVREBBERO servire a smorzare eventuali religion
war: uscite dai VOSTRI panni per un momento e mettetevi nei miei) in
merito ad argomenti come "manutenibilità", "aggiornabilità" e "security":
tenete in mente che io NON ci voglio giocare (per quello uso già Windows
;-))), non ci voglio programmare (se non brevi utilities) ma vorrei usare il
mio sistema soprattutto come HTTP e Mail server.

 Questo soprattutto nel caso riuscissi a connetterlo ad Internet via ADSL:
ho intenzione di sperimentare per un annetto o giù di lì ed in seguito
decidere se spostare l'attività commerciale di DigitalBrixia in locale...
ovviamente su server Linux.
 Nel caso cercherei di attivare una macchina "vuota" (trovando un 386/486 da
qualche parte) che gestisce SOLO l'aspetto security+routing e la macchina
xyz-server (ove xyz = HTTP, mail, file, ecc.).

 Quindi, a seconda di cosa è "meglio" per i vari aspetti, potrei anche
gestire più d'una distro all'interno della rete (come mi pare già facciano
alcuni di voi).

>  Ci possono essere alcune comode regole per mantenere un controllo della
>   consistenza del sistema (ad es. tenere copia dei files modificati da
>    qualche parte nella partizione /usr/local; installare i pacchetti
>    nuovi sotto /opt e creare links simbolici opportuni; fare un
>    backup periodico di /etc e /var/nomepaccheti) ma dipendono
>    da come il sistemista si sente a suo agio e non ci sono regole fisse.

 Immagino però ci siano, da qualche parte, delle "guidelines" che si possano
seguire.

 Tornando al mio passato riconosco che IBM ha fatto scuola, in argomento
sistemistico, ben al di fuori del suo ambito commerciale: parecchi
costruttori o implementatori di tecnologie seguivano le linee guida
tracciate da IBM proprio in quanto le stesse venivano da studi approfonditi
(costati spesso centinaia di milioni) ed era inutile riscoprire l'acqua
calda.

 Ad esempio, guardando il formato dei pacchetti RPM e sentendo parlare delle
"dipendenze" m'è tornato in mente SMP/E, lo strumento che utilizzavo per
aggiornare i prodotti che gestivo (NetView, VTAM, ACF/NCP, NetSpy,
NetMaster): stessi concetti e stesse risposte agli stessi problemi, anche se
implementazioni leggermente diverse (differenze dovute soprattutto alle
particolarità dell'OS: MVS).

>   In un mondo ideale tutto verrebbe gestito in automatico dal meccanismo
>    di aggiornamento... in realta' le cose sono un po' diverse.

 Mah... onestamente sono (diventato) abbastanza dubbioso riguardo
all'automatizzare certe attività: finchè si tratta di modificare un paio di
file di testo mi può stare anche bene, ma quando si tratta di un prodotto o
di un OS non metterei la mano in bocca al leone: c'è il caso che sia
affamato. ;-))

 Rimango parecchio stupito, di solito, dalla "semplicità" con cui la gente
tratta di solito, soprattutto (quasi inutile dirlo) in ambito Windows,
l'argomento update/upgrade: la cosa viene quasi sempre presentata come
"basta un doppio click su Setup.exe e via".
 Lo stupore termina quando vengo a sapere che poi si reinstalla quasi una
volta al mese "per dargli una bella pulita" l'intero OS (e ovviamente tutte
le applicazioni).
 Personalmente cerco sempre di portarmi dietro la mia antica mentalità
sistemistica: io Win98 l'ho installato quando ho cambiato l'HD (cogliendo
l'occasione di passare da Win98 a Win98SE), uno o due anni fa. Le
installazioni "alla come viene viene" cerco di evitarle e, quando non posso,
le faccio "pedinare" da CleanSweep (che mi tiene traccia di TUTTO, altro che
l'installer di Windows o InstallShield).

 Vorrei fare lo stesso in ambito Linux: partire da un'installazione pulita
(magari la prossima), con tutte le sue belle partizioni al posto giusto
(adesso sono in monopartizione), e "seguirla" nel tempo con i vari update
fino al prossimo upgrade "per cause naturali": l'hw non più supportato che
citavi tu poco fa o la troppa differenza tra i prodotti (o le funzionalità
del kernel) attuali, anche se patchati, e quelli nuovi.

 Vorrei anche fare tutto (quel che posso) a mano, per rendermi conto di quel
che succede, automatizzando solo quelle funzioni che col tempo conoscerò
bene e non riterrò necessario seguire sempre manualmente.

 La cosa che mi interessa di più sono quindi proprio le "guidelines" di cui
parlavi sopra riferendoti alle "comode regole per mantenere un controllo
della consistenza del sistema": se voglio diventare un passabile sysadmin (e
netadmin) devo anche imparare (da qualcuno) come si fa.
 Se sarò costretto andrò anche a qualche corso (mi piacerebbe un sacco ma
costano parecchio... sigh), SuSE o IBM, ma DEVO imparare: per questo contavo
MOLTO sul LUG.

>  [d'altro canto un server deve essere solitamente `patch-ato' piuttosto
>   che reinstallato, se funziona... i passaggi SunOS/solaris o
>   OSF1/Digital Unix/Tru64 non sono stati indolori, anzi...

 Infatti: NON siamo nell'ambito del "bel giochino". Il discorso server va
affrontato in modo professionale.

>   non credo che una upgrade da windows95 a NT4 consenta di mantenere i
>   files di configurazione...]

 Direi che stai sparando sulla Croce Rossa.  ;-))))

        Bye
        Sky