1) Scaricare pacchetto e scompattare sul desktop (versione NON TS):
http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_win_nonts_x86.zip

2) Copiare il file
ioncube_loader_win_5.2.dll in:
C:\Programmi\Zend\ZendServer\lib\phpext

3) Aprire il file con editor testuale:
C:\Programmi\Zend\ZendServer\etc\php.ini
Sopra la riga:
zend_extension=”C:\Programmi\Zend\ZendServer\lib\ZendExtensionManager.dll”
Inserire queste due righe:
zend_extension=”C:\Programmi\Zend\ZendServer\lib\phpext\ioncube_loader_win_5.2.dll”
zend_extension_ts=”C:\Programmi\Zend\ZendServer\lib\phpext\ioncube_loader_win_5.2.dll”

Salvare e riavviare apache.

Verificare in phpinfo() se l’estensione viene caricata correttamente.

Per prima cosa, installiamo freetds:
yum install freetds

Dopo procediamo a installare l’estensione mssql di ZS che non è fornita di default:
yum install php-mssql-zend-ce

L’estensione sarà attivata da sola. Meglio comunque riavviare lo zend server.

Andare all’interno di /etc/freetds.conf

Mettere:
# Myserver
[mysqlserver]
host = 192.168.X.X
port = 1433
tds version = 8.0

A questo punto per connettersi da php utilizzare:

mssql_connect(“192.168.X.X”, “login”, “pwd”) or die (“Failed”);

E il gioco è fatto.

http://www.addedbytes.com/apache/mod_rewrite-cheat-sheet/

Segnalo una problematica di sicurezza abbastanza importante per coloro che utilizzano adodb utilizzando il driver mysqli (le nuove funzioni di connessione con mysql native in php 5).

In sostanza le nuove funzioni mysqli consentono mediante la seguente funzione: mysqli_multi_query di poter eseguire più statement SQL in mysql come ad esempio:

SELECT * FROM TBL1 WHERE id = 1; DROP table TBL2;

Questa query utilizzando le vecchie librerie mysql (es. mysql_connect) dava errore.
La possibilità di eseguire più query SQL è supportata su mysql 5.0.x anche da command line, non saprei se anche vecchie versioni lo consentivano.

Questo significa che se per esempio utilizziamo in php una query del tipo:

$sql = “SELECT * FROM tbl1 WHERE id = $_GET['id']“; // (Premesso che venga come minimo fatto l’escape dei caratteri come ‘ o “)

Possiamo rischiare che qualche burlone passi in GET il seguente valore:
“1; DROP TABLE tbl2;”
Il che comporterebbe che l’SQL eseguito sia:

SELECT * FROM TBL1; DROP table TBL2;

Di fatto quindi con AdoDB con driver mysqli, la seconda query viene effettivamente eseguita.

Diventa quindi essenziale fare un controllo sull’input dell’utente per $_GET['id']. Ad esempio verificando che sia un numero intero.

La soluzione più rapida è quella di cambiare la connect di AdoDB dicendogli di usare il driver mysql anziché mysqli, la soluzione migliore e da fare comunque resta in ogni caso il filtraggio di tutti i dati in input.

Benchmark apache 2.2.x VS Lighttpd 1.4.x

Se qualcuno fosse a conoscenza di qualche modo (da firebug non lo capisco) per individuare da client se un server utilizza mod_deflate e me lo segnala farà cosa ben gradita.

Spero di poter ottenere una maggiore rapidità nelle pagine visto che di fatto il blog è composto tutto da html, css etc…

[UPDATE] A quanto pare l’entry che ho messo nell’.htaccess viene ignorata… infatti con questo tool:
http://www.gidnetwork.com/tools/gzip-test.php

Pare che le pagine del blog non siano zippate, mentre ad esempio quelle di www.190.it si…

[FONTE]: http://news.netcraft.com/archives/2008/04/14/april_2008_web_server_survey.html

Di primo acchito avevo pensato ad una crescita importante di Lighttpd… (che comunque cresce al punto che la linea verde inizia a intravedersi) e invece eccoti Microsoft che fa un balzo in avanti notevole in trend di crescita da ormai due anni…

Da notarsi anche Google, in grande ascesa…

Insomma, brutti tempi per il server web re indiscusso? Ai posteri l’ardua sentenza…

Per fare questo si può utilizzare un fantastico modulo di apache, mod_deflate.

FUNZIONAMENTO

Prima di tutto comprendiamo il funzionamento di mod_deflate e cosa fa. Questo modulo si occupa di comprimere html, documenti, immagini e quantaltro prima di servirle al client.
In tal modo otterremo una diminuzione nell’utilizzo della banda e il sito sarà in parte più rapido anche per quei navigatori che dispongono di connettività non a banda larga o comunque non eccelsa.

QUANDO UTILIZZARLO E COME

E’ importante però comprendere quando possiamo utilizzarlo e soprattutto se non sarà un boomerang che ci torna sulla faccia. Per farlo bisogna quindi analizzare il problema.

A) Contenuto del sito web

Nel caso in cui il nostro sito web sia composto prevalentemente da elementi testuali (CSS, HTML, XML etc…) otterremo un’effetto eccezionale comprimendo tali contenuti. Nel caso invece il sito sia composto da Flash, immagini pesanti etc… l’effetto sarà praticamente nullo.

B) Il nostro server ha abbastanza processore?

Un altro aspetto è legato alla potenza del server, infatti se da un lato si ottiene un miglioramento sull’aspetto della banda, avremo come controindicazione un impatto sul carico della CPU che per ogni richiesta deve comprimere il file prima di inviarlo al client. Se ne evince quindi che in caso di poca potenza rischiamo di risolvere i problemi di banda e causarne sull’HW del server web.

ATTIVAZIONE DEL MODULO

Se apache come di default su CentOS 5.1 (presa in esame per l’articolo) ha già incluso il modulo, bisogna solo scommentare la riga relativa:

LoadModule deflate_module modules/mod_deflate.so

CAMBIO CONFIGURAZIONE SERVER WEB

A questo punto dobbiamo definire in apache come e dove utilizzare il modulo.
Per fare questo è davvero inutile andare a sprecare bit su questo articolo , per cui vi rimando direttamente alla parte di configurazione sul sito di apache stessa:

MOD_DEFLATE CONF

Una nota importante da fare, prima di chiudere l’articolo, è relativa alla possibilità di escludere alcuni browser che non supportano pagine zippate e di poter escludere file come ZIP, Immagini, flash etc… (visibile da docs su apache)

Infatti se mentre sotto piattaforma Windows una URL che fa riferimento a: http://www.miosito.tld/immagine.html apre regolarmente l’eventuale file  IMMagine.html, sotto Linux otterremo un bel NOT FOUND 404.

Naturalmente la soluzione drastica di sistemare tutte le URL o i nomi dei files è abbastanza complicata, lunga, laboriosa e inutile. Per ovviare al problema in apache ci viene incontro il modulo mod_speling attivo o comunque presente su quasi tutti gli apache rilasciati con le varie distribuzioni.

Per poterlo utilizzare verificate con in httpd.conf vi sia scommentata e presente la riga:
LoadModule speling_module modules/mod_speling.so

Nel caso questa riga fosse commentata,  decommentatela e riavviate il server web.

Per default (giustamente) tale modulo è disattivo. Quindi sarà sufficiente definire per la directory o per il virtual host desiderato che tale modulo sia attivo. Per fare ciò è ad esempio possibile inserire queste semplici righe:
<Directory “DOCUMENT ROOT SITO WEB”>
CheckSpelling on
</Directory>

Riavviate il web server e tutto dovrebbe funzionare al meglio.

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

La variabile presente nel php.ini denominata memory_limit ha il compito di limitare il consumo di memoria massimo per uno script php in modo tale da evitare potenziali problemi al server web stesso in caso di cattiva gestione dello script o per qualche loop.
Per default tale valore è impostato ad 8 Mbyte, valore secondo me più che ragionevole.

In pratica Sugar Force richiede la bellezza di 32 Mbyte di memoria (se non erro) per poter funzionare.

Fatto sta che il provider in questione (giustamente) aveva l’impostazione di memory limit globale settata a 8 Mbyte e non funzionava una mazza…

Dubbioso sul poter realmente variare tale impostazione sono andato sul sito di php e nell’appendix ho scoperto quello che MAI mi sarei aspettato:

PHP_INI_ALL per intenderci indica che il valore è variabile da QUALUNQUE script php! Nemmeno come PHP_INI_PERDIR che indica invece che il valore è variabile o per directory da configurazione generale di apache o da .htaccess (se consentito Override da apache).

Insomma, nel caso specifico mi è anche andata bene perchà© ho potuto comodamente caricare in .htaccess “php_value memory_limit 64M” per poter far funzionare il CRM  perà questa cosa per me ha aperto un forte dubbio su tale scelta fatta dagli sviluppatori di php e in particolare dalla Zend.

Fortunatamente la soluzione è abbastanza facile, è infatti sufficiente disabilitare l’Override di apache ([per altro impostazione di default] non rendendo effettive le direttive di .htaccess che vengono quindi ignorate) e disattivando da php.ini la possibilità  di utilizzare la funzione ini_set().

Perà per un provider che eroga hosting per chiunque acquista uno spazio web (magari a prezzi stracciati) diventa limitativo e restrittivo.
Penso che un approccio diverso da parte della Zend e degli sviluppatori di php in merito a tale configurazione sarebbe più opportuno… almeno per le nuove versioni e configurazioni di default.

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com