linux user group brescia

(scusate ma in un primo momento avevo inviato il msg solo ad MP)
----- Original Message -----
From: Luca Coianiz <lcoianux a digitalbrixia.it>
To: Maurizio Paolini <paolini a dmf.bs.unicatt.it>
Sent: Sunday, February 04, 2001 2:28 AM
Subject: Re: Upgrade sistema (solo info preliminari)


====8<==== DISCLAIMER ====8<====
 Se siete stanchi, affaticati, "nun è 'a jurnata" o l'argomento non
v'interessa NON leggete il seguito di questo messaggio: dato l'argomento è
un mattone di quelli tosti.
 In generale è un messaggio che volevo scrivere almeno dall'agosto scorso ma
che ho lasciato riposare nella speranza di capirci da solo qualcosa (ed
evitarvi la tortura).
 Se decidete di leggerlo comunque... non prendetevela poi con me: io vi ho
avvertito. ;-)
====8<==== DISCLAIMER ====8<====

----- Original Message -----
From: Maurizio Paolini <paolini a dmf.bs.unicatt.it>
>>  In effetti l'avevo notato (sulla distro che m'ha fatto vedere un amico).
>> Quello che m'interessava di più sapere è se ci si poteva fidare di questi
>> upgrade automatici e, soprattutto, se rispettano le configurazioni
>> preesistenti (ma come fanno ?).
>>  Traduco: dato che mi pare sia previsto che un utente/sysadmin effettui
>> delle implementazioni ai file di configurazione (eh eh) l'upgrade
>> funziona come un rullo compressore ricoprendole, in caso i file in
>> questione siano modificati dalla versione precedente a quella in cui si
>> cerca di arrivare, le salva in file *.backup, le "integra" nei nuovi
>> file, ... ?

> NOTA: non prendete per oro colato quello che mi accingo a dire :-)

 ;-)))

ok, anche perchè parli di RedHat mentre io ho SuSE (anche se entrambe,
fortunatamente, usano RPM).
Mi pare che se c'è un punto in cui le distribuzioni differiscono veramente è
proprio sull'upgrade.

>Per quanto riguarda la RedHat un upgrade automatico e' (in massima parte)
> una sequenza di "rpm -U ..." (aggiornamento di singoli pacchetti).

 Quindi nel caso TU dovessi aggiornare il sistema non potresti appoggiarti
ad un prodotto di aggiornamento globale (o anche solo ad una check-list) ?
(parlo ovviamente di rimanere nei "limiti" della stessa distribution).

 Sei costretto a mantenere aggiornato un qualche "memo" (presumibilmente
esterno a Linux) sulla configurazione "currently running" (servizi/funzioni
attivate, configurazioni, ecc.) in modo da effettuare a mano tutte le
modifiche necessarie ? (anche se via RPM)

 Rendendomi conto che, forse, sono partito col piede sbagliato ad affrontare
l'argomento, ritengo sia a questo punto necessaria una

====8<==== NOTA PER MAGGIOR CHIAREZZA ====8<====
 Per chiarezza (nei confronti di tutti i frequentatori della ML): NON sto
cercando un qualche magico programma che mi permetta di "tenere il cu£0 nel
burro" (come fanno, ad esempio, gli utenti di Windows) e far fare tutto, in
modo automatico, al software senza dovermi preoccupare di nulla (tipo
doppio-click su setup.exe per intenderci). A parte che i problemi ci sono
anche lì: pensate a passare da Win98, con una quindicina di prodotti
installati (alcuni del calibro di AutoCAD o Visual-C, pesantemente
parametrizzati), ad un Win/ME: suicidio. :-|

 Ad ogni modo la mia esigenza non è quella occasionale dell'utente che passa
"perchè ne ha voglia", poniamo, dal kernel 2.0.36 al 2.4.x e che può stare
lì a piallare tutto più volte nella speranza o nel tentativo di arrivare un
giorno (forse) a capirci qualcosa.

 Sto cercando, fin tanto che posso parlarne tranquillamente senza l'obbligo
stringente della necessità, di mettermi nell'ottica del SysAdmin della
(piccola) azienda che, avendo una configurazione funzionante (tramite la
quale eroga servizi "24h" ai clienti), sente la necessità di effettuare un
upgrade generale del software (ed OS) del/dei propri sistemi, magari per
tappare uno dei tanti security holes o, come nel mio caso, per passare da un
"ambiente" (kernel, librerie, prodotti e servizi) del '98 ad uno più
moderno.

 Cerco quindi di capire se il discorso attuale (che mi pare "un pò
avventuroso", quando non del tipo "prova e vedi quello che succede") può
essere affrontato con una certa professionalità (magari con l'aiuto di
esperti del settore, se ce ne sono), seguendo una metodologia precisa...
oppure in materia di upgrade è ancora tutto fermo al "try & pray" ?

 Sono BEN CONSCIO che l'upgrade dell'OS non è una cavolata qualunque da
prendere sottogamba: ho lavorato per alcuni anni come sistemista nel CED di
una banca bresciana e, pur non essendovi direttamente coinvolto (ero
sistemista di rete: IBM/SNA), ho visto abbastanza da vicino le varie
operazioni che venivano compiute quando era necessario effettuare
l'aggiornamento dell'OS del/dei ns. Host (ad es. MVS/XA -> MVS/ESA su
S/390): oltre ai sistemisti MVS (tre miei colleghi) veniva invariabilmente
ad assisterci un sistemista IBM specificatamente esperto in upgrade.

 Anche se penso che aggiornare un server Linux sia un tantino meno complesso
che aggiornare un S/390 che gira 24h (e più la notte, col batch, che di
giorno, con c.ca 4000 utenti collegati), vorrei vedere se è possibile
seguire la suddetta "metodologia" (anche creandola, nel caso, ex novo) in
modo da poter ripartire, dopo l'upgrade, con tutti (o buona parte) i
servizi, le configurazioni e le utilities precedentemente attive E con il
minor downtime possibile.

 Questo è un problema che, fra l'altro, si presenterà in modo ricorrente:
c.ca ogni due/tre anni, trattandosi di OS (forse anche meno).

 Per questo mi chiedevo se, per caso, nel mondo Linux (e nel ns. LUG, per
questioni geografiche) c'era qualcuno esperto in particolar modo di upgrade
e che potesse darmi delle dritte abbastanza sicure e/o insegnarmi qualcosa
(anche a pagamento se è il caso)... o anche RTFM, ma con "M" ben chiari:
l'Upgrade-howto (sia IT che EN) che ho letto diceva quasi testualmente
"l'upgrade è una brutta bestia: fatelo solo se indispensabile..." e comunque
richiedeva di fare tabula rasa dell'installazione attuale per "resuscitarla"
in un secondo momento (e, infine, "non prendetevela con l'autore se qualcosa
va male"). :-(

 Ah... la mia esigenza è REALE (anche se non (ancora) pressante). Non voglio
prendere per i fondelli nessuno: vorrei arrivare, in tempi non troppo
lunghi, ad aprire un nodo Internet (inizialmente di solo test, via ADSL, ma
poi anche operativo) ove spostare la mia attività commerciale (relativa a
DigitalBrixia, che al momento gira su un server americano FreeBSD).

 Penso che i due problemi più "duri" che dovrò affrontare saranno UPGRADE e
SECURITY (tralascio per il momento SYSTEM AVAILABILITY, DISASTER RECOVERY,
SCHEDULED BACKUP, ecc. ecc.): il primo "una volta ogni tanto" (es. SuSE
6.0 -> SuSE 7.0), quando non se ne può proprio più fare a meno, ed il
secondo praticamente day-by-day.

 Ovviamente questi discorsi mi serviranno, opportunamente "ridotti", anche
in ambito "home" (è una questione di metodologia, non di volumi). :-)
 Ma vorrei partire dall'osso duro (il discorso azienda) prima che da quello
"facile" (l'upgrade "try & pray" casalingo).
====8<==== NOTA PER MAGGIOR CHIAREZZA ====8<====

 Scusate per l'inciso(ne) (e grazie per la pazienza). :-)

> Ora un "rpm -U" dovrebbe controllare che i files che vengono rimossi
> (del vecchio pacchetto) non siano stati modificati, e prende varie
> possibili azioni nel caso in cui invece SONO stati modificati.  Pero'
> la mia personale impressione e' che tale controllo si limiti ai files
> che potremmo chiamare "di configurazione", cioe' quelli che effettivamente
> ci si aspetta che vengano modificati dall'utente.

 Nel mio caso l'utente E' il SysAdmin: ho installato pochissimo software
"user oriented" ed uso la macchina quasi solo come server (principalmente
HTTP, per lo sviluppo in locale di siti web).
 L'upgrade di Tetris non mi spaventa (se perdo gli high-scores posso
sopravvivere) ed aggiorno a mano le release di SETI: quello che mi
preoccupa è invece perdermi parametri e config di Apache ed altre cosette
(SAMBA per esempio) costate sudore ed ore notturne di lavoro.

> E' a mio avviso buona norma evitare a tutti i costi di modificare files
> che NON siano di configurazione.  Questi ultimi vengono in genere
> piazzati in /etc, con nomi del tipo "pippo.conf".

 Una domanda a proposito del (famoso) discorso Open Source: se, come si dice
sempre, per esigenze mie modifico, poniamo, il source di un modulo di Apache
(o di Perl)... quando aggiorno il sistema non rischio di mangiarmi la
modifica ?
 E' un esempio puramente teorico dato che NON sono nemmeno lontanamente in
grado di fare una cosa del genere: era solo per capire come si integra il
discorso Open Source con le esigenze di upgrade. In linea nemmeno troppo
teorica si dovrebbe tener conto che il sistema potrebbe essere stato
modificato in OGNI sua parte (anche moduli del kernel per esempio).

 Ad ogni modo, se la risposta è troppo lunga o complessa, non rompiamoci la
testa su questo argomento (per me ancora di là da venire): vorrei rimanere
focalizzato sul discorso upgrade.
(nel caso lo si ritenesse utile si può aprire un thread apposito su "Open
Source e necessità di upgrade non distruttivo").

> Nel caso in cui si
> sia costretti a modificare altri files, io in genere faccio le seguenti
> operazioni:
>
>    mv file file.orig
>    cp file.orig file.local
>    ln -s file.local file
>
> e poi faccio le modifiche del caso in "file.local".  Cosi':
> 1. un "rpm -e" NON mi cancella il file con le mie correzioni.
> 2. posso sempre recuperare l'originale.

 Io di solito copio "file.conf" in "file.conf.originale" (dato che
l'estensione ".orig" è usata anche dal sistema di aggiornamento di SuSE e
non vorrei ci fossero fraintendimenti tra le mie modifiche e quelle di YAST,
il configuratore SuSE) ed edito direttamente "file.conf".
 All'interno del file lascio sempre commenti ad hoc (ad es. # 20010203 LC:
modified to use the new feature xyz) e posso sempre recuperare il
"file.conf.originale".

 Un buon motivo, oltre a quanto suggerisci, per seguire la tua modalità è
che, se voglio sapere al volo quali file ho cambiato, mi basta fare un
"find *.local" (o qualcosa di simile), anche se forse sarebbe più indicato
"marcare" i file in un'altra maniera: ad es. file.conf.20010203-01.mod
(beninteso creando sempre il softlink al "file.conf" originale).

 Già che se ne parla: i file "veri" (non i link) mi consigli di tenerli
nella stessa directory dei softlink oppure, per maggior sicurezza (nei
confronti di un eventuale rm -f *), di spostarli in un albero "parallelo"
(ad es. da /etc/httpd/httpd.conf a /mods/etc/httpd/httpd.conf) ?

 Che tu sappia, il sistema può avere dei significativi peggioramenti
nelle performances a livello di filesystem, dovendo effettuare due ricerche
per ogni file modificato, magari anche in directories diverse (ammesso che
sia così, con i simlink) ?
 E comunque: vale la pena di appesantire (eventualmente) un pò il sistema
per guadagnare in sicurezza ?
(anche se, trattandosi di configurazioni, non è che vengano lette ogni
decimo di secondo: magari ogni minuto, nel caso di Crond)

 Ah... side-effect: per caso ci sono problemi con il backup se i file "veri"
li sposto in /mods/* ?
(del tipo "non vengono visti/archiviati" o altro)

> Non sono sicuro che "rpm" avvisi di una situazione di questo tipo al
> momento dell'aggiornamento.

 Ulp.  =:-O

> Invece, nel caso che venga modificato un file di configurazione, possono
> avvenire due cose quando si aggiorna il pacchetto:
>
> 1. Se il nuovo file di configurazione non e' cambiato (molto) rispetto
> al file di configurazione originario del vecchio rpm, allora viene tenuto
> il file modificato.  Il nuovo file di configurazione viene creato con
> l'aggiunta di ".rpmnew" al suo nome.

 Quindi dovrò andare a mano a "copiarne" le novità nel mio file.
 Poco male: mi pare una cosa corretta (specie se viene creata una check-list
dei file da "ritoccare").

> 2. Se invece (piu' frequentemente) il nuovo file di configurazione
> contiene novita' importanti, allora il file di configurazione precedente,
> modificato dall'utente, viene salvato in un file di nome "<nomefile>.
> rpmsave".

 Quindi, al contrario di prima, dovrò andare in *.rpmsave e vedere se i miei
parametri hanno ancora senso con la nuova versione del file (e nel caso
copiarli nei nuovi file).

> In questi casi viene presentato un messaggio a video che avvisa del fatto.
>
> In caso di "upgrade" della distribuzione, viene creato un file con un nome
> che ora non ricordo (forse "upgrade.qualchecosa") in /tmp, con i messaggi
> risultanti dai vari "rpm -U".

 E' la famosa "check-list" di cui parlavo sopra ?

> Nota: un upgrade della distribuzione e' SEMPRE una operazione delicata,
> soprattutto se uno ha pesantemente messo mano ai vari files di sistema.

 Di questo ne ero già ben conscio: si tratta di dare uno scrollone al
sistema dalle fondamenta.
 Quello che mi stupiva un pò era che, fino ad ora, non ho visto nulla di
"scientifico" che curi questo aspetto: un sacco di "si dice" e "non si dice"
per quanto riguarda i singoli pacchetti, programmi o files ma niente che
riguardi l'intera installazione, se non addirittura l'intero "ambiente" (nel
senso del sistema informativo, che può riguardare anche numerosi server, ad
es. nel caso si usi NSF o YP).

 Mi pare strano che un prodotto "filosoficamente stagionato" (parlo
quantomeno di Unix, se non proprio di Linux) usato da aziende anche non
piccole (Sun, Oracle, IBM, ecc.) non preveda "procedure di upgrade" più che
collaudate: soprattutto se si tiene conto che è una delle operazioni più
delicate sia per il sistema che per l'azienda stessa (ma probabilmente è una
MIA ignoranza).

 Ho come l'impressione che per molti versi la mentalità sia ancora rivolta
alla singola macchina/server, che puoi aggiornare scratchando tutto e
reinstallando ex novo e, se la cosa non funziona, sbackuppare il sistema
precedente e riprovare in un secondo tempo (cose a cui ci ha abituato
Microsoft per esempio, ma non solo).

 Scusa(te) se sono noioso ma, almeno per l'upgrade di tutto il SO, penso
all'azienda che lo deve fare e DEVE poi ripartire senza troppi problemi: è
abbastanza normale che ci siano dei piccoli aggiustamenti da fare (tuning)
in seguito al "grande salto", anche solo perchè per certe funzionalità è
cambiata proprio la filosofia nel tempo (ad es., mi pare, il modo di fare
firewalling da un kernel 2.0.x ad un 2.4.x), ma l'azienda non credo possa
permettersi il "try & pray"... che diventa "try & cry" in caso di fallimento
(avevamo calcolato, per esempio, che il down del ns. S/390 di produzione
sarebbe costato c.ca 2.5 milioni al minuto, questo nel '92-'93).

>>  Ah... domanda forse più interessante (e che m'è venuta in mente adesso):
>> per passare dalla 6.0 alla 7.0 è meglio aggiornare passo-passo (6.0 ->
>> 6.1 -> 6.4 -> 7.0) oppure YAST se ne frega della versione dalla quale
>> vieni e ti porta comunque alla 7.0 ?
> Attenzione (per RedHat) mi pare che NON sia possibile l'upgrade da 6.2 a
> 7.0...

 In che senso ? Devi fare gli upgrade "periodici" ogni volta che esce una
nuova versione della distro ?
 Oppure non è possibile punto & basta ?

 Lo chiedevo perchè ricordo più o meno come si aggiornavano i pacchetti
sull'S/390 (tramite un prodotto spposito: SMP/E, per alcuni versi simile ad
RPM): ogni tanto (c.ca una volta ogni due/tre mesi) ci arrivava qualche
nastro (o cassetta) di patch da applicare al sistema. Quindi, fino ad un
aggiornamento generale, avevi il S.O. (o il singolo sottosistema) versione
xx.yy.zz/patchlevel-uu.vv.ww.
 Poi, una volta c.ca ogni due/tre anni (ma NON troppo spesso, dato il casino
che comportava) avveniva l'aggiornamento ad una nuova major release (tramite
CBIPO: una serie di parecchi nastri/cassette con TUTTO il nuovo OS ed i
nuovi pacchetti, confezionato su misura per il ns. CED da IBM).
 Di solito seguivano alcuni giorni di "sistemazione dei piccoli casini" che
sorgono generalmente in questi casi. ;-)

 Il succo di tutto il discorso era che, a meno di un aggiornamento globale
(in cui veniva rinfrescato tutto), non era possibile passare da una versione
x.y.3 ad una x.y.5 se non eri passato per la x.y.4: mancavano degli
aggiornamenti nei moduli (ed il sistema d'aggiornamento SMP/E rifiutava la
modifica).

 Magari in Unix/Linux non sarà così... ma il ricordo di quegli aggiornamenti
(e la delicatezza degli stessi) non manca mai di preoccuparmi (la sensazione
che qualche parte dell'OS o di un prodotto non vada perchè mi sono lasciato
dietro qualcosa d'importante).

 Vabbè... scusa il mattone: prima o poi dovevo scriverlo.  ;-)
 E' un pò che 'sta cosa mi preoccupa ed il non avere riferimenti e
indicazioni precise ha fatto sì che io restassi alla mia distro originale,
senza aggiornarla mai (ed installando anche poco software in generale per
paura di non riuscire ad aggiornarlo/manutenerlo).

 Spero piuttosto d'aver dato voce anche ai dubbi di qualcun altro e che
l'eventuale soluzione non serva solo a me. :-)

        Bye
        Sky

Linux reg. user #136925 / machine #59766 (http://counter.li.org)
PGP public key available @ http://www.digitalbrixia.it/lcoianiz.asc
Fingerprint: B511 BED4 FA52 F118 F480  B74F E987 BD50 6C6D 3254