Drupal 6.0 e PHP 5.1.6 su Centos 5 : Call to undefined function: date_format()

[J3njy]

Questo tutorial pubblicato anche sul mio blog è frutto di un pomeriggio di bestemmie e tentativi vari di installare Drupal 6.0 su Centos 5.* :

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....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 ?

[Kuro]

sarò ignorante, ma non è, oltre che controproducente, anche pericoloso mantenere una versione così datata di php? mi pare venga più aggiornata da molto tempo dagli sviluppatori php

Oltretutto non capisco perchè ti ostini ad usare quella versione, w4w (tanto per citarne uno) ha 5.2.x su macchine centos e non mi pare abbia problemi (lato software intendo)

[J3njy]

Tuttaltro !

Avere versioni UFFICIALI significa avere anche delle garanzie non indifferenti in termini di compatibilità e stabilità.

PHP 5.2 ad esempio installato coattamente tramite repository di terze parti (vedi REMI ad esempio) non ha a corredo tutto quelle estensioni che normalmente ho installato con la versione ufficiale 5.1.6

Non è assolutamente pericoloso mantenere una versione datata in quanto non significa che non sia aggiornata in termine di bugfixes, ma semplicemente freezata al ramo 5.1.6 e non aggiornata alla 5.2

Il problema delle security patches dunque è un non problema.

Non so cosa faccia w4w, ma credo che a questo punto sarebbe stato molto più SAGGIO utilizzare altre distribuzioni per dotarsi di PHP 5.2 ;D

[Kuro]

Non è assolutamente pericoloso mantenere una versione datata in quanto non significa che non sia aggiornata in termine di bugfixes, ma semplicemente freezata al ramo 5.1.6 e non aggiornata alla 5.2

Il problema delle security patches dunque è un non problema.

che io sappia il ramo 5.1.x è proprio morto. Non fanno più manutenzione e/o bugfixing (ufficiale php.net intendo) almeno dal 2007, veramente non capisco come faccia ad essere sicuro ...

Non so cosa faccia w4w, ma credo che a questo punto sarebbe stato molto più SAGGIO utilizzare altre distribuzioni per dotarsi di PHP 5.2 ;D

Le loro politiche aziendali non mi interessano, ma una cosa è certa: se w4w non avesse avuto la 5.2.x non lo avrei scelto. I miei script girano solo su 5.2.x

[J3njy]

Bè diciamo che essenzialmente quando escono gli advisory su securityfocus ad esempio si procede al bugfixing in casa RedHat che ha moneta e tempo per farli a "manina".

Il problema purtroppo a mio avviso come hai GIUSTAMENTE sottolineato tu è che si rischia di tagliare fuori una bella fetta di clienti non mettendo a disposizione PHP 5.2 ma volendosi fermare appunto alla 5.1 come dichiarato chiaramente da RedHAT.

Adesso non ho in previsione quando uscirà il ramo 6 della nota distribuzione ma ahimè la vedo dura aspettare ancora magari uno o 2 anni con la 5.1.6 quando magari PHP sarà già alla versione 6