dicembre 31st, 2009 by J3njy

1 Stella2 Stelle3 Stelle4 Stelle5 Stelle6 Stelle7 Stelle8 Stelle9 Stelle10 Stelle (1 voti, media: 9,00 di 10)
Loading ... Loading ...
Invia tramite Email questo articolo ad un amico Invia tramite Email questo articolo ad un amico

Postato in Recensioni Musicali | No Commenti »

dicembre 30th, 2009 by J3njy

Oggi mi sono trovato a risolvere un problema piuttosto fastidioso riguardo il sito di un mio cliente basato su Drupal 6.
Detto in parole povere questo sito era hostato su una Linux Centos 5.4 con la versione ufficiale di PHP ovvero la 5.1.6 e si piantava in maniera poco ortodossa restituendo nall’error_log la seguente dicitura : Call to undefined function: date_format()

Facendo una breve ricerca ho letto che questa funzione è presente sin dalla versione 5.1 del PHP e dunque non avrebbe dovuto esserci alcun problema anche se nella pratica il problema c’era eccome.
Leggendo su vari forum ho notato che tutti consigliavano il passaggio alla versione 5.2.6 di PHP tramite l’utilizzo di repository non ufficiali come quello di REMI ad esempio rischiando comunque di “rompere” le dipendenze tra i vari pacchetti e sopratutto di destabilizzare un server in produzione.
La realtà invece era ben diversa e non immaginabile a priori (purtroppo).
Le funzioni PHP in questione sono incluse infatti di default dalla versione 5.2 del PHP, MA … (MA) sono incluse come funzioni SPERIMENTALI nella versione 5.1.6 e disabilitate di default.
Onde evitare di passare molto pericolosamente alla versione 5.2 ho scelto dunque di abilitare queste funzioni “sperimentali” ricompilando il pacchetto RPM di PHP 5.1.6

Ecco una breve guida per i sistemisti che vogliano ovviare in un modo molto elegante (e anche macchinoso) a questo fastidiosissimo problema.

Prerequisiti : Accesso Root tramite SSH al sistema.

1) Scarica il pacchetto SRPMS della versione PHP corrente (rpm -qa | grep php) da rpm.pbone.net o da un relativo mirror :

wget ftp://mirror.switch.ch/pool/3/mirror/centos/5.3/updates/SRPMS/php-5.1.6-23.2.el5_3.src.rpm

2) Crea la tua area per ricompilare il pacchetto RPM (da un utente NON root)

echo "%_topdir /home/nomeutentecorrente/src/rpm" >> ~/.rpmmacros
mkdir -p ~/src/rpm/
cd ~/src/rpm
mkdir BUILD RPMS RPMS/i386 SOURCES SPECS SRPMS

3) Installa il pacchetto SRPM (sempre da utente non root)

rpm -ivh php-5.1.6-23.2.el5_3.src.rpm

Questo comando metterà il tarball sorgente e le patch nella dir SOURCES e lo specfile (istruzioni per la compilazione) in SPECS

4) Editare lo SPEC chiamato php.spec
Trovare una linea in cui c’è scritto : CFLAGS=”RPM_OPT_FLAGS -fno-strict-aliasing -Wno-pointer-sign” ed aggiungere -DEXPERIMENTAL_DATE_SUPPORT=1
deve essere modificata esattamente in :

CFLAGS="RPM_OPT_FLAGS -fno-strict-aliasing -Wno-pointer-sign -DEXPERIMENTAL_DATE_SUPPORT=1"

In questo modo si passano i flag al compilatore GCC abilitando le feature sperimentali sulle date.

5) Ricompilare il PHP ricreando il file .rpm (da utente non root)

rpmbuild -ba SPECS/php.spec

E’ possibile che sia necessario installare alcuni pacchetti addizionali (solitamente quelli di sviluppo almeno) per soddisfare tutte le dipendenze.
Il sistema compilerà PHP e potrà richiedere anche una 20ina di minuti su sistemi non troppo performanti, motivo per cui si consiglia di effettuare l’operazione di notte o in regimi di non produttività.

Una volta finito il pacchetto corretto sarà creato dentro a RPMS/i386

6) Estratte i binari dai pacchetti RPM generati.
Troverete diversi file .rpm all’interno di questa cartella ma a noi interessa solo quello chiamato php-5.1.6-23.2.i386.rpm
Prendiamo il file e scompattiamolo in una cartella ad esempio chiamata pippo sotto /tmp

mkdir /tmp/pippo
mv php-5.1.6-23.2.i386.rpm /tmp/pippo
rpm2cpio php-5.1.6-23.2.i386.rpm | cpio -idmv

7) Sostituzione File. (da root)
Troveremo essenzialmente un albero di directory all’interno di questa cartella che rispecchia a grosso modo l’albero del sistema corrente :
/usr/bin
/usr/lib
Sostituiamo i seguenti file del sistema correnti con questi appena scompatatti :

/usr/lib/httpd/modules/libphp5.so
/usr/bin/php
/usr/bin/php-cgi

Ripristiniamo i permessi e i proprietari corretti per i seguenti file cambiati e riavviamo Apache. Voilà … problema risolto.

PICCOLA NOTA :
Ma non è ora che Redhat (da cui deriva CentOS) non dedichi un po’ più di tempo agli aggiornamenti del suo software e agli upgrade delle versioni ?
Mi sembra assurdo che una distribuzione che si vanta di avere un lifecycle di ben 7 anni abbia la faccia tosta di lasciare i propri clienti con versioni a mio avviso obsolete di PHP e MySQL, sopratutto in ambiente di virtualhosting dove le abitudini dei programmatori e le applicazioni php installate dai clienti sono piuttosto eterogene.
Un modo nativo e ufficiale per poter supportare i continui aggiornamenti e il progredire di PHP 5 senza rompere la retrocompatibilità no eh ?
Dato che siamo nel periodo natalizio e non ho chiesto ancora nulla a Babbo Natale … speriamo che il regalo (magari per il prossimo anno) sia proprio una tecnologia simile.

1 Stella2 Stelle3 Stelle4 Stelle5 Stelle6 Stelle7 Stelle8 Stelle9 Stelle10 Stelle (2 voti, media: 8,50 di 10)
Loading ... Loading ...
Invia tramite Email questo articolo ad un amico Invia tramite Email questo articolo ad un amico

Postato in Information Tecnology | No Commenti »

dicembre 25th, 2009 by J3njy

1 Stella2 Stelle3 Stelle4 Stelle5 Stelle6 Stelle7 Stelle8 Stelle9 Stelle10 Stelle (2 voti, media: 10,00 di 10)
Loading ... Loading ...
Invia tramite Email questo articolo ad un amico Invia tramite Email questo articolo ad un amico

Postato in Personali | No Commenti »