Newsgroup: it.comp.os.linux.sys
Titolo: Server di sviluppo in produzione.

Gestisco un certo numero di server il cui scopro principale è quello di 
ospitare applicazioni scritte in php e in j2ee.
Il sistema operativo utilizzato è ubuntu server. Sono utilizzati i seguenti 
software: apache2, php5, mysql e la versione java della sun.
I software sono quelli inclusi nella distribuzione Linux e sono aggiornati 
sistematicamente, come tutta la distribuzione.
Ultimamente il mio boss ha espresso dubbi sulla validità di tale pratica.
Mi si contesta il fatto che le applicazioni potrebbero avere problemi a 
seguito dell' aggiornamento del software.
Quindi le possibili alternative sono le seguenti:
1) Non utilizzare i software (apache2, php5, etc etc) propri della 
distribuzione, ma installarli a partire dai sorgenti. Aggiornare la 
distribuzione regolarmente. Aggiornare a mano i software in seguito ad 
upgrade di sicurezza, dopo aver verificato che tutto funzioni.
2) Utilizzare i software (apache2, php5, etc etc) propri della 
distribuzione, ma aggiornare prima una versione di pre-produzione, testare 
che tutto funzioni e poi passare alla versione di produzione. A causa della 
mancanza di personale questo si traduce però nel tenere la distribuzione non 
aggiornata per diverse settimana.
3) Utilizzare i software propri della distribuzione ed aggiornare sempre.
Quale pensate che sia l'opzione migliore ?
Grazie 

 seguito dell' aggiornamento del software.
se parli di problemi di sicurezza, direi che se ce ne sono sono nelle 
vostre applicazioni
se parli di possibili incompatibilità tra le nuove versioni dei servizi e 
le vostre applicazioni, se il server è di sviluppo è li apposta..
come ultima ipotesi c'è anche da considerare il fatto che chi parla e 
muove appunti non sa di cosa sta parlando
S.


IMHO cambiare boss...
Ma chi ti scrive ti risponde in base a ciò che legge e non a esperienze 
personali, se non riferite al fatto che anch'io amministro un server 
(molto personale) e le versioni "server" delle distro si differenziano 
dalle altre proprio perché le applicazioni che ci girano sono già 
considerate "stable" e quindi già testate.
Ciao, Davide.

 Quale pensate che sia l'opzione migliore ?
4) lancia aptitude, scegli il pacchetto che non vuoi aggiornare, apri
il menu "Pacchetto" e scegli la voce "Blocca" (sorry ma ho tutto in
italiano. Questo funziona solo con aptitude. Per farlo funzionare con
apt-get leggo che devi fare così:
echo "tuo_pacchetto hold"|dpkg --set-selections
Questo secondo suggerimento credo che andrebbe provato un attimo.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 La 2.
effettivamente mo' ho letto meglio e pure io sono d'accordo.
Tutte le azienda "civilizzate" è bene che abbiano un server di test/preproduzione.


 Quale pensate che sia l'opzione migliore ?
4) il problema non si pone perchè, se ubuntu server funziona come debian 
stable, il software della distribuzione NON cambia MAI[1] a meno di 
passare alla distribuzione successiva che, con debian, puoi permetterti 
di farlo più o meno ogni 4 anni.
(quindi al limite questa opzione si tramuta in "passa a debian" se ubuntu 
server ha tempi di rilascio inferiori)
[1] ad eccezione dei fix di sicurezza che puoi permetterti di applicare 
sia un produzione che in testing seduta stante, perchè nulla cambia nelle 
"features" e pure nei "bug" non di sicurezza del software che si sta 
aggiornando.


la 2) è come funziona dovunque si facciano le cose con un minimo di
criterio.
bye!

 test/preproduzione.
Perfettamente d'accordo. Solo che nella nostra realtà la 2 si traduce anche 
in "tenere la distribuzione non aggiornata fino alla fine dei test in 
preproduzione", ovvero per settimane.
Essendo io sviluppatore-sistemista devo decidere se rischiare che una 
applicazione smetta di funzionare in seguito all'aggiornamento o che mi 
buchino il server.
Fino ad ora ho preferito aggiornare sempre la distribuzione, contando sul 
fatto che gli aggiornamenti, che su ubuntu server dovrebbero essere solo di 
sicurezza, non modificano le funzionalità del software.
Adesso la cosa è stata messa in discussione dal boss. 

 Adesso la cosa è stata messa in discussione dal boss.
Cambia boss...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/


Forse nel mio caso questa è la soluzione migliore.
Potrei bloccare apache2, mysql e php dall'aggiornamento di routine ed 
aggiornarli solo dopo aver avuto la possibilità di testare le applicazioni.
Ci proverò, grazie. 

 ha scritto nel messaggio 
news:i62ab7$bql$1...@nnrp.ngi.it...

Questo è quello che ho pensato io negli ultimi due anni.
Poi c'è stato un malfunzionamento di una applicazione php, che è stato 
imputato all'aggiornamento della distribuzione (cosa molto opinabile) ed il 
boss mi ha detto testualmente: "non esiste che aggiorni cose come mysql in 
un sito di produzione senza testare prima il tutto su pre-produzione".
La cosa avrebbe anche un senso, se ci fosse qualcuno che ha il tempo di 
testare le applicazioni ad ogni aggiornamento di sicurezza dei software di 
supporto alle applicazioni (mysql, apache2 etc. etc.)
Ciao 

 all'aggiornamento della distribuzione (cosa molto opinabile)
Non è opinabile.
E' verificabile e bisognerebbe verificarlo.

 opinabile) 
precisa: avanzamento di ditribuzione vuol dire che sei passato ad una
release successiva di Ubuntu, e non che hai fatto un semplice apt-get
dist-upgrade ?
Beh, in questo caso ti confermo che il passaggio a php5.3, che è
avvenuto con l'ultima distribuzione, ha creato problemi su alcune
applicazioni (una tra tutte joomla).
Ma mi pare *ovvio* che il passaggio a distribuzione successiva devi
farlo prima in test. A quel punto ti scrivi uno scenario di test, se è
il caso lo automatizzi. Non è un gran lavoro, anzi, ti evita un lavoro
BEN PEGGIORE.



Sicuro.
Ma se non si è in condizione di farlo (quale che sia la ragione),
aggiornare la distribuzione è assai meglio che lasciarla non patchata,
IMHO...


 portare a grattacapi.
Quel workaround l'hai messo tu, non loro.
Loro non rompono (teoricamente) nulla. (talvolta capita, pochissimo ma 
capita).
Se hai messo un workaround per problemi di sicurezza sei conscio che 
quando aggiorni il paccheto è bene rimuovere il workaround.
Se hai messo quel workaround per un bug qualsiasi non di sicurezza, stai 
tranquillo che il bug rimane.
http://www.debian.org/security/faq#oldversion

 dist-upgrade ?
un semplice aptitute upgrade.
Utilizzo Ubuntu Server LTS e cambio release solo quando scade il supporto.
Ciao 

 IMHO...
Il ragionamento non fa una piega, il problema e` che manca un presupposto 
non indifferente per capire cosa sia successo: che tipo di aggiornamento e` 
stato fatto? Nel senso, e` stato eseguito un aggiornamento da una release 
della distribuzione alla successiva oppure e` stato eseguito un 
aggiornamento di bug fixing? In base a questo secondo me si puo` dire se e 
quanto e` giusto aggiornare una distribuzione senza prima assicurarsi che 
funzioni tutto
Enrico

 dist-upgrade ?
Uhmmm...
Io non so niente, eh, però un dist-upgrade non lo darei a cuor leggero
su un server in produzione.
Upgrade, in caso di conflitti, non aggiorna. Dist-upgrade cerca
"intelligentemente" di risolvere i conflitti, aggiornando quel che
ritiene più opportuno aggiornare a scapito di altra roba che magari
vien pure disinstallata.
Ecco, io a naso starei al massimo sull'upgrade lisssio, quanto ad
automazione. E, se ci fossero conflitti, ci penser... ehm... chiamerei
qualcuno che ci pensasse. ;)
--
Bye, Lem
Ceterum censeo ISLAM esse delendum

 qualcuno che ci pensasse. ;)
Ecco, GIUSTO!
Fare un avanzamento di distribuzione con "upgrade" invece di "dist-
upgrade" (che è fatto apposta) è il modo corretto per mettere il culo 
davanti alla pedata!


Un dist-upgrade IMHO non va MAI fatto su un server in produzione senza test.

 test.
concordo.
Un "upgrade" cambiando la distribuzione non va mai fatto, sempre e 
comunque, a maggior ragione in produzione.

 davanti alla pedata!
E chi diamine ha parlato di fare un avanzamento di distribuzione?
BTW usare dist-upgrade direttamente NON è nemmeno modo standard di
fare un avanzamento di distribuzione su ubuntu.


 aggiornamento di bug fixing?
Probabilmente mi sono spiegato male.
Io ho sempre parlato di aggiornamento intendendo un aggiornamento di bug 
fixing.
Ho Ubuntu 8.04 LTS e la terro' fino alla scadenza del supporto.
Ciao 

 davanti alla pedata!
Probabilmente mi sono spiegato male.
Io non ho mai inteso un avanzamento di distribuzione, ma semplicemente 
l'aggiornamento di bug fixing.
Ciao 

 ha scritto

Giusto per curiosità: mi pare che aver capito che php ti ha creato
problemi. Che versione avevi e che versioni ti ritrovi adesso?


 problemi. Che versione avevi e che versioni ti ritrovi adesso?
Il fattaccio è successo prima dell'estate e non sono in grado di controllare 
i diversi numeri di versione.
Ti posso però dire che il software che ha datto problemi è il crm vtiger, la 
cui procedura di login è stata modificata per integrarlo in SSO.
Comunque io non ho mai creduto che il problema fosse l'aggiornamento... in 
seguito a quel problema è nata la discussione con il boss sulla gestione 
degli aggiornamenti.
Per la cronaca il problema è stato risolto con una piccola modifica del 
codice, ma non sono in grado di dare ulteriori info.
Ciao