I grattacapi arrivano quando si ha a che fare con PhpMyAdmin per Plesk, dove le suddette modifiche sembrano venir ignorate dal sistema.

Come mai succede ciò?

La risposta è molto semplice: PhpMyAdmin è installato nella parte “admin” di Plesk e per quest’ultima esiste uno specifico php.ini.

E’ questo il file che dobbiamo andare a modificare, situato nella directory /usr/local/psa/admin/conf (dove /usr/local/psa/ è la cartella in cui è installato il vostro Plesk).

Andando ad editare i valori del file quello che ci interessa modificare è questa riga in particolare:

post_max_size = 2147483647

La riga qui sopra ci indica che la dimensione massima accettata in POST è di 2MB. Se vogliamo aumentarla a 16MB, ad esempio, possiamo modificarla in questo modo:

post_max_size = 16M

E questo è tutto!

Mi capita spesso di dover cambiare i permessi ricorsivamente ma dovendo cambiarli solo alle cartelle (escludendo i files) o solo ai files (escludendo le cartelle).

I comandi non sono poi così complessi, ma ogni volta devo andarli a cercare quindi li posto qui.

Chmod 755 solo per la cartelle, ricorsivo:
find . -type d -exec chmod 755 {} \;

Chmod 644 solo per i files, ricorsivo:
find . -type f -exec chmod 644 {} \;

As simple as that!

Se avete bisogno di modificare a mano la configurazione dell’FTP del vostro server dovete andare a editare il file di configurazione che si trova al percorso

/etc/proftpd.conf

A dire la verità, fin qui niente di anormale. Il problema arriva quando dovete fare un restart o un reload del demone e vi accorgete che non è possibile farlo con il classico comando

/etc/init.d/proftpd reload (oppure restart)

Ecco la soluzione: se avete Plesk installato dovete reloadare/restartare il servizio xinetd per rendere effettive le vostre modifiche alla configurazione di ProFTP o comunque per riavviare il servizio FTP:

/etc/init.d/xinetd reload (oppure restart)

Tutti noi (?) abbiamo protetto delle cartelle utilizzando l’.htaccess, ma è posibile proteggere dei singoli file?

Certo che sì. Ecco come fare.

Per proteggere una cartella avremo al suo interno un .htaccess come questo:


AuthUserFile /percorso/assoluto/dell/.htpasswd
AuthType Basic
AuthName "Cartella protetta"
Require valid-user


Per proteggere un singolo file avremo invece un .htaccess come quello qui sotto, nel quale la richiesta di un user valido viene fatta solo se il file corrisponde a quello

AuthUserFile /percorso/assoluto/dell/.htpasswd
AuthType Basic
AuthName "Cartella protetta"
<Files "file-da-proteggere.html">
  Require valid-user
</Files>


Per la creazione dell’.htpasswd il procedimento è ovviamente lo stesso di quello effettuato per la normale protezione delle directory.

Durante l’installazione delle prime versioni di OpenX non erano pochi gli utenti che incontravano sul loro cammino una malefica pagina bianca durante le operazioni di installazione.

Da OpenX 2.7 in poi, però, il demone contro cui molti devono misurarsi è costituito dal seguente errore:

Menu System Error: ::10 Not Found For The Current User

I più fortunati potranno risolvere il problema con la cancellazione del contenuto di queste due directory:

openx/var/cache
openx/var/templates_compiled

Ovviamente non è stato il mio caso e ci sono voluti 2 giorni per riuscire a trovare una soluzione, soluzione che voglio condividere pensando a quelli che in questo momento stanno sbattendo la testa contro questo problema.

Create un file .htaccess all’interno della directory di openx e copiateci dentro queste due direttive php:

php_value display_errors 1
php_value zend.ze1_compatibility_mode Off

Ed ecco sparito l’errore.

P.S. Ricordatevi in ogni caso di alzare il memory_limit del PHP a 128M prima di procedere all’installazione!

Perché attivare la compressione

Al giorno d’oggi le pagine servite dai siti web sono sempre più pesanti, per non parlare del carico di elementi esterni che si portano dietro tra css, javascript, immagini e compagnia bella. Attivando la compressione gzip è possibile ridurre notevolmente la dimensione degli elementi inviati da Apache al browser, così da ottimizzare i tempi di caricamento della pagina per utente e server.

Mod_deflate

Il modulo deflate di Apache non è l’unico modo per abilitare la compressione degli elementi. E’ sicuramente il modo più facile, immediato e non crea problemi di sorta per cui è quello che ho usato e che andrò a descrivere.

Se attivato, il mod_deflate viene inserito tra i filtri (gli output filters) utilizzati da Apache nel rendere disponibili i contenuti. Sono diverse le opzioni di configurazione disponibili per questo modulo, come ad esempio le restrizioni su quali tipi di file devono essere compressi o il livello di compressione da utilizzare.

Attivare il mod_deflate su Debian/Ubuntu

Il modulo è già presente nell’installazione di Apache e deve essere attivato. Dopo aver verificato che il modulo è effettivamente presente nella directory “mods-available” di Apache (solitamente /etc/apache2/mods-available/), creiamo due link simbolici nella cartella “mods-enabled” per attivare il mod_deflate e la rispettiva configurazione:
ln -s /etc/apache2/mods-available/deflate.load /etc/apache2/mods-enabled/deflate.load
ln -s /etc/apache2/mods-available/deflate.conf /etc/apache2/mods-enabled/deflate.conf

Ricarichiamo poi la configurazione di Apache:

/etc/init.d/Apache2 reload

Attivare il mod_deflate su CentOS/Fedora/RedHat

Per attivare il modulo è necessario decommentare la seguente riga nel file di configurazione di Apache (solitamente /etc/httpd/conf/httpd.conf). All’interno di questo file decommentare la seguente riga:

LoadModule deflate_module modules/mod_deflate.so

Creiamo il file di configurazione (maggiori dettagli più sotto):

nano /etc/httpd/conf.d/deflate.conf

Ricarichiamo poi la configurazione di Apache:

service httpd reload

La configurazione del modulo

Sia per Debian che su CentOs ho parlato di un file deflate.conf. E’ il file da creare/modificare per specificare le opzioni di compressione del modulo deflate.

Ecco il mio file deflate.conf:

# Insert filter
SetOutputFilter DEFLATE
# Escludiamo i browser problematici
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
# Non comprimere le immagini
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
# Non comprimere i file compressi
SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI .pdf$ no-gzip dont-vary

Come potete vedere, al modulo viene detto di comprimere tutti i files richiesti dal client, con alcune esclusioni:

• Il metodo non verrà utilizzato con i browser che hanno alcuni problemi con il supporto della compressione gzip
• Non verranno compresse le immagini: supponendo che siano già ottimizzate per il web sarebbe uno spreco di CPU andare a ricomprimerle
• Non verranno compressi i file già compressi (es. rar, zip) per ovvi motivi.

Verificare che la compressione funzioni

Utilizzando questo tool online potete inserire l’indirizzo web per il quale volete verificare se la compressione gzip è effettivamente attiva. Il sito permette inoltre di controllare se il vostro browser supporta questa modalità.