Newsgroup: it.comp.os.linux.sys
Titolo: update in tranquillità?

Mi sembra una cosa banale ma non ho trovato info a riguardo,(su ubuntu 
server/debian) come si fa a tornare indietro alla versione precedente in 
caso un aggiornamento abbia "rotto" qualcosa?
E i security updates sono solo per la versione LTS? Non è possibile fare 
"upgrade di prova" automatici, che se il software non riparte rimette la 
vecchia versione??
O sono tutte preoccupazioni inutili dato che saranno più che testati?

andrea ha scritto:

E' una domanda così strana/insensata?


insensata, no.
sullo "strana", bisognerebbe definire "strana" :-)
In generale, un aggiornamento è sempre a rischio di "rottura" del
sistema, ecco perché va fatto con cautela e, come dicevano alcuni vecchi
professori, facendo finta che il tasto invio (o analogo di conferma) sia
fatto di metallo rovente.
Le fisime del tipo «oddio, devo aggiornare questo, ma mi chiede di
aggiornare anche mezzo sistema. Devo continuare?» non sono mai troppo
paranoiche (questa è la mia idea).
Comunque, terminate le considerazioni personali, partiamo dalla parte
più semplice: gli update di sicurezza.
Questi vengono rilasciati principalmente per le versioni dichiarate
stabili (nel caso di Debian, si parla di Etch, Sarge, Woody, Potato.
Adesso non mi ricordo se Woody e Potato sono ancora supportate, comunque
il senso è quello). Per le versioni in fase di sviluppo, quelle attive
(sempre parlando di Debian, visto che lo conosco meglio, sono ad esempio
Lenny e Sid, ossia Testing e Unstable) ci possono essere sia rilasci di
nuove versioni (quindi nei repo "normali") che rilasci di sicurezza.
La regola non la so, una occhiata sul sito di Debian dovrebbe fugare
ogni dubbio. Ti posso dire con certezza che il repo con gli update di
sicurezza di Lenny è molto piccolo, ma c'è.
Arriviamo ora alla possibilità di un passo indietro.
Personalmente preferisco guardare avanti prima di fare un passo,
piuttosto che tornare indietro, quindi utilizzo aptitude dicendo:
1) di *non* marcare automaticamente il sw raccomandato. Mi viene
comunque proposto e posso selezionarlo io in un secondo tempo.
2) in caso di installazione di un pacchetto, guardo tutte le dipendenze
prima di marcarlo (o marcandolo, tanto fintanto che non gli dico di
procedere non c'è problema) e analizzo uno ad uno tutti i conflitti
3) in caso di conflitti o richieste di aggiornamento di una libreria
verifico chi la usa (con le reverse dependencies) per sapere se è un
potenziale problema (leggi come: mi può mandare in palla un programma
installato) o se è abbastanza isolato.
4) in caso di aggiornamenti "sospetti", guardo il changelog del
pacchetto per avere una idea un po' più precisa.
Soprattutto il punto 3 sembra un po' troppo "pesante", ma dopo un po' ci
si fa la mano e si impara a riconoscere alcuni pacchetti.
Se proprio devo, poi aggiornare, cerco di farmi un backup completo o mi
salvo i pacchetti (se ce li ho ancora nella cache) alla versione
corrente in modo da poter tornare indietro (non mi è mai capitato di
dover tornare indietro).
Altro metodo è quello di avere un muletto dove fare tutte le prove.
Soprattutto in caso di server, è meglio sperimentare dove non si possono
fare danni. :-)
Spero di aver risposto alle tue domande.
Luca

Luca Pascali ha scritto:

Sì hai ampiamente risposto e mi sembra un'ottimo sistema il tuo.
Per il muletto avresti anche ragione, però giustamente la configurazione 
non sarà mai uguale (nè hw nè sw) quindi non hai comunque la certezza.
Per il resto devo studiarmi un po' come funziona il packaging debianesco.
La cosa che mi lascia sempre un po' diciamo perplesso, è, su un ambiente 
di produzione, perché devo aggiornare un pacchetto (a meno che non sia 
un'update di sicurezza) quando tutto funziona e non ho bisogno di altre 
features.
Forse per evitarsi rotture di balle basterebbe fare un upgrade quando 
qualcosa di veramente utile e "nuovo" viene inserito in un certo 
programma, ma questo implicherebbe una attenta lettura dei changelog e 
un'ottima conoscenza di tutti i programmi.
Dal punto di vista pratico comunque mi interssa più che altro qualche 
metodo per "tornare indietro". Apt si arrabbia se cerco di installare un 
deb più vecchio dell'attuale?

 deb più vecchio dell'attuale?
Ecco, io non uso praticamente mai apt nudo e crudo, ma sempre aptitude.
Intanto, come apt, lavora in testuale (ergo gestibile tranquillamente
anche via ssh).
Poi ti permette di verificare in modo molto più facile e completo tutta
una serie di cose, come le dipendenze dei pacchetti (dirette o inverse,
ossia "questo pacchetto dipende da" e "chi dipende da questo
pacchetto"), ti permette di selezionare tra le varie versioni
disponibili di quel pacchetto (quindi anche downgrade, qualora fosse
disponibile la versione precedente) e fare tutta una serie di ricerche
con espressioni regolari con il nome del pacchetto, la descrizione, la
versione e così via.
Ultima cosa, ti permette di verificare tutto (pacchetti da installare,
rimuovere o aggiornare) prima di effettuare la reale installazione.
Da quello che ho potuto vedere io, è altamente probabile che un
downgrade possa generare una serie di conflitti. Anche in questo caso
Aptitude ti viene incontro poiché grazie al fatto di mostrarti in
anteprima lo scenario che si sta andando a creare, ti permette di
decidere se fare il downgrade o darti la possibilità di procurarti una
serie di pacchetti tali per cui il downgrade è possibile.
Dimenticavo un'ultima soluzione che io adotto:
Mi sono fatto un piccolo repository mio locale dove metto i file deb che
creo io (dai miei programmi, dalla compilazione dei moduli, dalla
compilazione tramite checkinstall, o da pacchetti deb che ho scaricato e
che voglio installare senza passare direttamente da dpkg) e mi genero i
file Packages e Release (in coda al messaggio c'è il mio Makefile per
generare gli indici del mio repo).
Dalla directory di cache, a meno che non la svuoti con un
# apt-get clean
o
# aptitude clean
ti trovi i vecchi file deb.
Al limite li sposti nel tuo repo personale e da lì verifichi se puoi
effettuare il downgrade, aggiungendo al repo, se necessario, tutti i
pacchetti che non sono altrimenti disponibili, ma che sono necessari per
 completare il downgrade.
Quest'ultimo modo è un po' overkilling, però. ;-)
Luca
8<--Makefile----------------------------------->8
#!/usr/bin/make -f
all:
        rm -f Packages.gz Sources.gz Release *.gpg
        dpkg-scanpackages . /dev/null > Packages
        dpkg-scansources . > Sources
        gzip -9c Packages > Packages.gz
        gzip -9c Sources > Sources.gz
        echo Archive: testing >> Release
        echo Component: main >> Release
        echo Origin: PasckyArts >> Release
        echo Label: Unofficial Pasckosky Packages >> Release
        echo Date: `date` >> Release
        echo Architecture: i386 >> Release
        echo Description: This repository is mostly free >> Release
        echo MD5Sum: >> Release
        md5sum Packages Packages.gz Sources Sources.gz >> Release
        echo SHA1: >> Release
        sha1sum Packages Packages.gz Sources Sources.gz >> Release
        chmod +r *
8<--Fine Makefile------------------------------>8

andrea wrote:

Se il server e' una macchina virtuale, puoi fare uno snapshot prima
dell'upgrade e tornare allo snapshot se qualcosa va male.

 features.
Bravo.
Se tutto funziona, e non hai bisogno di altre features, NON AGGIORNARE
nulla, se non e' per security.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 nulla, se non e' per security.
Dipende dal software. Se ad esempio ti serve un software che ancora non ha
raggiunto una buona maturita`, aggiornare all'ultima versione puo` essere
il male minore. Personalmente mi sto ritrovando questo problema con KVM
Enrico

 vecchia versione??
Tieni presente una cosa: se parli di un client quelle di cui parli sono
tutte menate legittime. Se parli pero` di un server, allora spero che ti
stai riferendo ad un server non critico o ad un server configurato in modo
particolare e specifico
Enrico

 serie di pacchetti tali per cui il downgrade è possibile.
In che senso mostrarti in anteprima?
Oltre a vedere cosa ti installerebbe dipendenze comprese che altro fa?

Interesante vedrò di capirci qualcosa...

 
Ecco ma come si vede se un upgrade è per security oppure no?
Con un safe-upgrade vedo i pacchetti da installare ma non ci sono info 
aggiuntive.
Tipo adesso avrei queste cose:
aptitude safe-upgrade
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Reading state information... Fatto
Reading extended state information
Initializing package states... Fatto
Building tag database... Fatto
The following packages will be upgraded:
   avahi-daemon bind9 bind9-doc bind9-host clamav-base clamav-daemon 
clamav-freshclam cupsys-client cupsys-common
   dnsutils ghostscript gs gs-esp libavahi-client3 libavahi-common-data 
libavahi-common3 libavahi-compat-libdnssd1
   libavahi-core5 libbind9-30 libclamav2 libcupsimage2 libcupsys2 
libdb4.4 libdns32 libgs8 libisc32 libisccc30
   libisccfg30 liblwres30 libpq5 libsnmp-base libsnmp10 libxfont1 
libxml2 openssh-client openssh-server snmp snmpd
   syslog-ng
39 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 24,6MB of archives. After unpacking 4096B will be used.
Do you want to continue? [Y/n/?]
Ho trovato, aptitude changelog, ottimo!

Enrico 'Henryx' Bianchi ha scritto:

Giusto, tra l'altro volendo sono proprio pochi i software vitali, 
postfix samba dovecot fetchmail openvpn openssh e slapd, gli altri sono 
comunque importanti ma non così vitali.

Enrico 'Henryx' Bianchi ha scritto:

Dipende cosa intendi per critico, ogni minuto down sono bestemmie che 
volano e tempo perso in azienda.
Gli utenti sono pochi per fortuna, ma se non va quel server si girano i 
pollici.

 Oltre a vedere cosa ti installerebbe dipendenze comprese che altro fa?
Beh, ti permette di eseguire una ulteriore selezione e/o deselezione dei
vari elementi o di scegliere tra le versioni disponibili di ciascun
pacchetto per vedere se, almeno a livello di dipendenze e conflitti,
avresti uno stato coerente. Inoltre si blocca in caso di conflitti.
Rispetto all'interfaccia di apt o quella di synaptic è un notevole passo
avanti.
Purtroppo non simula l'installazione :-) (ma forse ci arriveranno)
[...]
Luca

 raggiunto una buona maturita`, aggiornare all'ultima versione puo` essere
Ma non e' quello che c'e' scritto li' sopra:
*se tutto funziona, e non hai bisogno di altre features*.
Che sia maturo o no, il fatto che funzioni, non abbia buchi di sicurezza
e abbia le features che mi servono, mi porta a diventare un retrogrado
conservatore.


 Ho trovato, aptitude changelog, ottimo!
Vedi, un sistema, restando in casa debian e derivate, l'hai trovato.
[*] Si parlava di macchine in produzione.


 volano e tempo perso in azienda.
Per critico intendo tutto cio` che rischia di compromettere seriamente la
produzione. Ad esempio, uno switch che collega due tronconi della rete
aziendale per me e` un componente critico, mentre un server svn lo reputo
di una criticita` minore (previo ovviamente un backup aggiornato e
costante)
Enrico
P.S. ovviamente tutti gli ambienti di sviluppo e di test hanno una
criticita` pressoche` nulla

 conservatore.
Questo dipende dai casi. Come ho detto, ad esempio, un aggiornamento di KVM
lo ritengo importante e degno di considerazione, in quanto tale software si
trova ancora in uno stadio di sviluppo avanzato (anche se si puo`
considerare pienamente funzionante)
Enrico

andrea ha scritto:

Ho notato che guardando nel changelog dei pacchetti da upgradare ho 
anche l'urgenza (sempre low in quelli attuali).
Non sarebbe male valutare l'upgrade dei soli pacchetti con urgenza alta, 
non trovo però strumenti di report in questo senso, devo fare a mano?