Correggere l’errore [500 internal server error: mod_fcgid: read data timeout]

L’errore xxx è molto frequente e dipende dal parametro FcgidIOTimeout di Apache e si verifica quando PHP è eseguito come componente FastCGI. Difatti, questo parametri indica il timeout in secondi dopo il quale l’esecuzione di uno script FastCGI viene interrotta. Ci troveremo nel file /var/www/vhosts/devdev.it/logs/error_log  degli errori simili a questi:

Se abbiamo degli script PHP come questi che superano il valore di FcgidIOTimeout , dobbiamo modificarlo impostandolo ad un tempo di alto. Vediamo come.

Apriamo il file /etc/httpd/conf.d/fcgid.conf e cerchiamo  FcgidIOTimeout 45. Una volta individuato modifichiamo semplicemente questo valore, ad esempio:

FcgidIOTimeout 120

A questo punto riavviamo Apache e ricordiamoci infine che questo setting funzionerà su tutti i vhost configurati.

Controllare se il servizio SMTP è attivo

Per testare se il servizio SMTP in locale è in funzione, la cosa più semplice da far è controllare innanzitutto che sul nostro server un servizio sia in ascolto sulla porta 25:

Nel nostro caso, un servizio locale è in ascolto e accetta connessioni da tutti gli indirizzi. A questo punto possiamo testare che il server SMTP funzioni:

In questo caso, il servizio è attivo: l’MTA Postfix ci risponde senza battere ciglio. Nel caso invece il servizio non fosse attivo avremmo avuto una risposta come questa:

 

 

Migrare facilmente Livezilla su un nuovo server

Livezilla è uno dei più diffusi sistemi di live chat open source. Il suo livello di completezza e la documentazione disponibile ne fanno uno dei sistemi più gestibili ed affidabili.

Ci potrà capitare, di dover spostare un sistema Livezilla già installato da un dominio all’altro oppure su un server diverso. Per entrambi i casi dovremmo dividere lo spostamento in 3 fasi principali: spostamento dei file, migrazione del database, riconfigurazione. Per ragioni tecniche, queste operazioni non possono essere effettuate tramite interfaccia grafica (GUI), perciò dovremmo affidarci ad una procedura più basilare. Vediamo come fare.

Spostamento e backup dei dati

Per prima cosa dovremmo spostare l’intera directory di installazione di Livezilla da uno server all’altro. Non c’è un modo unico di procedere, ma vi consiglio, se non siete troppo esperti, di utilizzare un client FTP per scaricare l’intera directory e successivamente eseguirne l’upload sul nuovo server. Nel frattempo, avrete ottenuto sulla vostra macchina una copia di backup per ogni evenienza.

Migrare il database

Una volta messa al sicuro la directory principale di Livezilla, non ci resta che creare una copia di backup del database mySQL. Anche qui non esiste una soluzione che vale per tutti: la più semplice è quella di connettersi al pannello phpMyAdmin che il vostro hoster vi fornisce ed effettuare un’Esportazione completa di tutte le tabelle in un file che scaricherete. Per ogni evenienza conservate questo file.

Non ci resta che recarci nel nuovo database e Importare il backup appena creato.

Riconfigurazione

A questo punto, rechiamoci nella directory di Livezilla sul nuovo server. Entriamo nella directory _config  ed apriamo il file config.inc.php  per modificarlo. Scorrete il file fino a trovare le voci elencate:

A questo punto basta sovrascrivere i valori relativi al vecchio database con quelli nuovi. Ma attenzione, i valori vanno indicati in base64. Per convertirli velocemente, potete usare uno strumento online come questo.

A questo punto salvate il file.

 

[PLESK] Visualizzare le password di ciascuna casella email

Per le normali operazioni di monitoring e manutenzione, spesso ci serve sapere conoscere le password email degli account creati sul nostro Pannello Plesk dirt and quick. Queste password sono conservate nelle tabelle specifiche del db mysql, tuttavia Plesk mette a disposizione uno script per visualizzarle da shell in modo molto comodo. Vediamo come fare.

Visualizzare le password email per un dominio

Assicurandoci di lanciare il comando come root, eseguiamo:

Visualizzare le password email dell’intero server

 

Fatto.

 

Come eseguire un backup FTP con wget

Spesso abbiamo la necessità di spostare un sito o un progetto web tra due server o scaricarlo in locale. Per farlo, potremmo usare un comune client FTP e scaricare manualmente i file presenti sul server. Esiste però una via più comoda da utilizzare via shell di comando, utilizzando il comando unix wget .

Molto frequentemente uso questa procedura per scaricare un sito in produzione da una macchina di test. Insomma, è utile anche per effettuare lo spostamento di un progetto web tra due server remoti. È possibile farlo in vari modi, ma con wget  l’operazione risulta particolarmente semplice.

Anatomia del comando

Vediamo la sintassi del comando:

Innanzitutto vediamo che è fondamentale usare l’opzione -m  che dice al comando wget di prepararsi ad un’operazione di mirroring. Questo significa che wget applicherà automaticamente le seguenti opzioni:

  • recursion, cioè scenderà in profondità in ogni directory che incontrerà
  • timestamping, rispetterà la data di modifica dei file, cioè la riporterà sul nuovo server esattamente come l’ha trovata
  • relative links, cioè seguirà i link simbolici all’interno del filesystem
  • inf, cioè eseguirà infiniti tentativi di ricorsione
  • –no-remove-listing, non cancellerà il file temporaneo .listing  trovato sul server

Se ad esempio avessimo questi dati:

Username: admin

Password: 12345678 (non usatela davvero, per favore)

Server: ftp.miodominio.it

Il comando diventerebbe

Fatto. Vedrete a video il download di ogni singolo file.

Password con caratteri speciali

Se la password del server FTP contiene caratteri speciali, il comando potrebbe venire troncato e restituirvi un errore come questo:

Come spesso accade nelle password auto-assegnate, alcuni caratteri vengono letti dall’interprete come “segni particolari” e non come semplici caratteri.  Per risolvere questo problema è possibile usare la forma estesa del comando base. Ipotizziamo di avere un #  tra i caratteri della password abcd#ef :

 

Spostare dei commit su un nuovo ramo in Git

Molto spesso ci troviamo davanti a questo tipo di problema: per errore o inesperienza, eseguiamo dei commit  mentre ci troviamo sul ramo sbagliato. Come facciamo a spostare gli ultimi commit su un nuovo ramo o su un ramo preesistente?

Ci troviamo in una situazione analoga a questa:

Dove gli ultimi due commit, cioè af65fcd  e e577582  sono quelli da spostare su un branch diverso. Vogliamo, cioè arrivare ad una situazione analoga a questa:

 

Muovere commit su un nuovo ramo

Nel caso volessimo spostare gli ultimi commit  su un nuovo branch , l’operazione è abbastanza semplice e non dovrebbe dare problemi.

Il comando centrale di questa procedura è

che dice sostanzialmente di spostarsi indietro di 2 commit: possiamo indicare il numero di commit che ci serve scavalcare. In alternativa, possiamo indicare l’hash del commit, se lo conosciamo, ad esempio:

Non perderemo alcun commit, semplicemente li abbiamo staccati e associati al ramo nuovoramo.

Muovere commit su un ramo esistente

Il metodo precedente è basato sul fatto che nuovoramo è appunto un ramo creato per l’occasione. Ma se volessimo spostare gli ultimi n commit su un ramo già esistente?

In questo caso dovete effettuare prima un git merge  tra il ramo e il master  prima di eseguire il git reset  come nell’esempio precedente. Se non lo fate perderete il vostro lavoro. Vediamo come eseguire questa procedura:

 

Evitare l’hotlinking dei file javascript con .htaccess

Uno dei classici problemi dei tanti copia-incollatori seriali di internet, è che – magari a loro insaputa – incollano pure gli indirizzi dei nostri script. A tutti gli effetti richiedono questi file javascript direttamente dal nostro server e in sostanza abusano delle nostre risorse. Questo fenomeno è chiamato hotlinking e possiamo aggirarlo facilmente. Magari pure essendo un po’ cattivi.

Uno dei casi più diffusi è sicuramente quello delle immagini, per il quale potete leggere l’articolo su come prevenire l’hotlinking delle immagini. Un secondo caso, dicevamo, è quello dei file javascript. Per bloccarne l’hotlink è sufficiente aggiungere una regola nel file .htaccess come questa:

Naturalmente è necessario sostituire NOSTRO_DOMINIO.IT con il nostro dominio reale. Queste regola, in sostanza, significa:

[Se il chiamante è diverso da vuoto ed è diverso dal nostro dominio, con o senza www, e il file richiesto termina con .js, non rispondere alla richiesta]

A tutti gli effetti, quindi, il sistema non invierà il file al chiamante. Ma c’è una variante un po’ più cattivella, certamente più divertente! Potremmo, anziché non rispondere come nell’esempio precedente, servire un file javascript specifico.

Come vedete, abbiamo modificato l’ultimo rigo, dicendo al sistema di servire il file hotlink.js, nel quale possiamo decidere di mettere questo codice:

Appena qualcuno proverà a fare un hotlink di un nostro file javascript, il browser dell’utente verrà reindirizzato al nostro sito.

Come evitare la cache dei CSS e Javascript

Spesso è indispensabile evitare che il browser degli utenti che visitano il nostro sito usi una versione vecchia dei fogli di stile CSS o dei file Javascript. Capita, quindi, che le modifiche apportate non vengano poi effettivamente visualizzate o eseguite dai nostri utenti. La cache, però, resta un fattore fondamentale per l’ottimizzazione delle prestazioni di un sito.

Come possiamo evitare la cache del browser?

Spesso lato server la cache viene gestita in modo molto conservativo, con la conseguenza che si tende a forzare troppo la scadenza troppo lunga dei contenuti, e da qui il problema di servire al browser file vecchi.

Supponiamo che la cache del CSS principale del sito abbia una durata di 7 giorni, ma abbiamo appena rilasciato un piccolo aggiornamento. Non potendo dire al browser dei visitatori “Svuota la cache!”, il trucco più semplice è fargli credere che il CSS sia diverso, modificando il nome dei file e quindi l’URL della risorsa chiamata.

https://miosito.it/css/screen.css  diventa https://miosito.it/css/screen.css?v2

Cambiando il nome del file, quindi, il browser, scaricherà una nuova copia di screen.css  e la metterà in cache, secondo le regole di durata preimpostate dal server. Quindi, se abbiamo intenzione di avere versioni future (ad esempio v3, v4, etc.) dovremmo ripetere l’operazione, cambiando nuovamente il nome del file.

Questo discorso vale per tutti i file statici, come javascript, HTML, file di testo, etc.

Evitare automaticamente il caching

Abbiamo capito, quindi, che basta cambiare il nome del file aggiungendo dei parametri fittizi del tipo screen.css?v2  per forzare il browser a scaricare una nuova versione di screen.css . Come possiamo automatizzare questo processo? Cambiando sistematicamente il nome del file ad ogni aggiornamento.

In questo esempio, screen.css  viene parametrato automaticamente con una stringa basata sulla data di modifica del file stesso. La funzione PHP filemtime restituisce l’ultima data di modifica del file in formato Unix timestamp. Ogni volta che pubblicheremo un nuovo screen.css , l’URL sarà diverso, evitando la cache.

La risorsa effettivamente chiamata sarà di conseguenza simile a questa:

screen.css?1489427332

Lo stesso principio, come detto, vale per tutti i tipi di file statici, come ad esempio script javascript