Pubblicato il

Errore in Plesk: Recipient address rejected: User unknown in virtual mailbox table

Se si ottiene l’errore in Plesk per Linux:

è probabile che lo schema delle mailbox sul sever sia corrotto o contenga errori. In pratica, questo avviene quando Postfix cerca di inviare una mail ad un dominio che è sullo stesso server. Avviene infatti al momento dell’invio (cioè non “ci torna indietro”, ma non viene affatto inviata) proprio perché l’SMTP pensa che il destinatario abbia una casella sullo stesso server di chi invia. Se non è così, c’è chiaramente un problema di configurazione.

Dovrebbe, infatti, essere inviato dal nostro server SMTP al server di destinazione basandosi semplicemente sul record DNS MX del destinatario. Postfix va a leggere un file che contiene le “caselle locali”, cioè proprio quelle sullo stesso server. Teniamo questo file sotto controllo e verifichiamo che non vi siano errori. Vediamo come fare controllando il file:

In alcuni casi ci troveremo con una situazione simile a questa:

Questo è palesemente un errore, in quanto “1” non è un indirizzo formalmente valido. Quello che dobbiamo fare è editare questo file cancellando la corrispondenza. Per prima cosa, facciamo una copia di backup di questo file, non si sa mai.

Poi, creiamo un file temporaneo, che andremo a modificare direttamente:

A questo punto possiamo editare il file con il nostro editor preferito, come vi  e cancellare la riga, come detto in precedenza:

Creiamo un nuovo database basato su questo file appena editato:

e infine sovrascriviamo il file principale con questo, nuovo e corretto:

 

Fatto. Dovremmo aver risolto il problema.

Pubblicato il

Atom permette di collaborare al codice in real-time con Teletype

Fin dal suo lancio, avvenuto tre anni fa, l’editor Atom di GitHub è una delle migliori scelte open source per quanto riguarda gli editor di codice, l’unico in grado di competere con Sublime Text. Personalmente l’ho eletto subito come mio editor preferito e lo uso quotidianamente. Se invece voi non l’avete scelto come editor principale, magari con questa nuova feature, chiamata Teletype, vi farà cambiare idea.

Teletype è la nuova funzione, gratuita, che permette di seguire o scrivere codice in contemporanea con uno o più colleghi o collaboratori. L’idea è che ognuno “crei un portale” per condividere il proprio spazio di lavoro: ogni tab sarà automaticamente condivisa con gli invitati che potranno effettuare modifiche. Il tutto in real time, senza latenza.

Per cominciare, scaricate gratuitamente Atom dal sito ufficiale ed installate il package teletype . A questo punto clicchiamo sull’icona dell’antenna in basso a destra, sulla status bar e procediamo ad aprire un portale. Non ci resta che condividere l’ID appena ottenuto con i nostri colleghi.

Viceversa, per joinare un portale, l’operazione è inversa, incolliamo il codice del portale:

Pubblicato il

Configurare i servizi al boot con chkconfig

Spesso dopo un riavvio, ci accorgiamo che postfix non è in esecuzione, rendendo impossibile l’invio delle email via SMTP. Spesso (se siamo certi che la configurazione si OK) postfix potrebbe non essere presente tra i servizi che vengono avviati al boot. I sistemi basati su Red-Hat, come CentOS o Amazon Linux si affidano all’utility chkconfig per gestire i servizi all’avvio.

Verifichiamo i servizi presenti

Per vedere quali servizi sono attualmente configurati (quelli da /etc/init.d/  o xinetd ) diamo il comando chkconfig --list :

Ogni linea consiste nel nome del servizio seguita dal suo status (on oppure off) per ognuno dei sette livelli. Nel nostro esempio, SpamAssassin è attivo sul runlevel 2,3,4 e 5. I servizi xinetd invece hanno semplicemente uno stato on oppure off.

Verificare un singolo servizio

Per conoscere rapidamente lo status di un singolo servizio (nel nostro esempio postfix), diamo il comando:

Se otteniamo un status vuoto, il nostro servizio non è configurato per l’avvio!

Aggiungiamo un servizio

Aggiungiamo un servizio alla configurazione attuale come segue:

Ri-verifichiamo che il servizio sia adesso presente usando la sintassi

Nel nostro caso:

Perfetto, il nostro servizio verrà lanciato al boot.

 

Nota per gli utenti Plesk 12 e Onyx su Linux

A quanto apprendiamo, questo è un bug noto nelle versioni precedenti alla 17.5. Un ripristino delle impostazioni o un repair può togliere postfix dagli elementi dell’avvio. Questa guida vale anche per voi utenti Plesk.

Pubblicato il

Creare un server FTP usando Amazon S3

 

In questo post vedremo come tirare un server FTP utilizzando una istanza Amazon EC2 che sincronizza automaticamente  i dati verso un bucket Amazon S3. Questa soluzione dirty-cheap sfrutta la libreria s3fs che ci permette in sostanza di montare un bucket S3 come un volume locale, usando il celebre FUSE e di eseguire letture/scritture senza alcun problemi, proprio come se i file fossero in locale. Configureremo successivamente un server FTP basato sul collaudato vsftpd  per interagire dall’esterno con l’istanza EC2.

Perché S3?

Amazon S3 è una garanzia, un pilastro del cloud object storage ed offre una durabilità del 99,999999999% (ci basta?) e ci permette di non avere alcun limite di storage. Costruiremo, in effetti, un backup server FTP con storage illimitato.

Perché FTP?

FTP non è un protocollo sicuro, ma è stabile, perfettamente compatibile con App di qualsiasi genere. A fornire maggiore protezione ci penseremo noi sfruttando le potenzialità dei Security Group di Amazon EC2. Per il momento concentriamoci sulla costruzione del servizio, pensando in futuro all’implementazione di un FTP-sicuro (FTPS) oppure un SFTP via SSH.

Come funziona s3fs

Gli hard disk locali, SAN o iSCSI conservano le informazioni come blocchi. Questo significa che potenzialmente, ogni memoria di questo tipo potrebbe funzionare universalmente con un sistema operativo Unix. Amazon S3, invece, è costruita sul concetto di object storage, per questo non direttamente compatibile con un sistema operativo standard.

La libreria s3fs risolve questo problema: si occupa di emulare come un filesystem locale (sul quale possiamo creare, cancellare, rinominare i file, etc.) un object storage remoto.

Ci siamo, abbiamo capito come trasferire i file sulla nostra istanza EC2, tramite il protocollo FTP, e come poi spostare questi file su Amazon S3, tramite la libreria s3fs. Procediamo allora.

Installiamo e configuriamo s3fs

Come root, procediamo all’installazione dei pacchetti di supporto:

Scarichiamo e compiliamo s3fs:

A questo punto, aggiungiamo le nostre credenziali AWS al file auto-discovery:

Creiamo una directory, che sarà quella automaticamente sincronizzata con un bucket S3:

La nostra directory /home/ec2-user/s3mount , quindi, farà la magia.

Procediamo quindi a montare, come fosse un comune volume, il nostro bucket backupBucket (che abbiamo creato in precedenza) puntandolo proprio a questa directory:

Controlliamo che il volume sia montato correttamente:

Perfetto. Facciamo una piccola prova. Creiamo un file vuoto e controlliamo dalla console AWS S3 che questo file ci sia:

Installiamo vsftpd

Sempre come root, installiamo il pacchetto vsftpd :

Procediamo subito alla sua configurazione editando il file vsftpd.conf :

Impostiamo il file come segue. Possiamo configurarlo a piacimento, ma ricordiamoci di impostare local_enable=YES : permetterà a tutti gli utenti locali di accedere all’FTP.

Salviamo il file e lanciamo vsftpd:

Lanciamo vsftp al boot

Per sopravvivere al reboot, configuriamo il lancio all’avvio:

Apriamo le porte necessarie

Ricordiamoci di aprire le porte 20-21 e il range 15393-15592 nel Security Group dell’istanza! Decidiamo se “aprire a tutto il mondo” o stringere l’accesso ad uno o più indirizzi IP.

Creiamo un utente FTP

A questo punto, non ci resta che creare l’utente FTP con il quale effettueremo il login sul server FTP:

Impostiamo quindi i permessi sulla sua directory per evitare problemi:

Fatto. A questo punto, proviamo a collegarci all’IP pubblico della nostra istanza EC2 e proviamo ad eseguire l’upload di un file, lo troveremo nel nostro bucket Amazon S3!

Pubblicato il

Interrompere un backup di Plesk

La gestione dei backup di Plesk è uno strumento molto utile, per questo vi consiglio di tenerlo sempre attivo su macchine di qualsiasi grandezza. Anche se può non sembrare, è un task che impegna molta CPU, soprattutto su VPS (Virtual Private Server) dove tale risorsa è di solito limitata. Spesso, può riempirci il disco e causare un sacco di problemi: vediamo come fermare un processo di backup in corso su Plesk.

Questa piccola guida funziona su Plesk Linux 11, 12 e Onyx.

La prima domanda è, dove mette i backup Plesk? Per farlo, andiamo a vedere cosa contiene la variabile di sistema DUMP_TMP_D  nel file psa.conf :

Abbiamo capito, quindi che temporaneamente i backup saranno nella directory /usr/local/psa/PMM/tmp. Andiamoci:

Vediamo cosa c’è:

Le directory che iniziano con “repo_” contengono backup non finiti.

Se non c’è un backup in corso, possiamo cancellarle usando

Cancellare un backup completato

Per cancellare un backup già completato, invece, dobbiamo andare nella directory indicata dalla variabile DUMP_D  nel file psa.conf . Il procedimento è quasi identico a quanto già fatto in precedenza:

Andiamo, quindi, in /var/lib/psa/dumps :

Possiamo adesso cancellare senza problemi il backup che intendiamo eliminare definitivamente.

Pubblicato il

Immagini responsive in CSS con background-image

Nella quasi totalità dei casi, quando parliamo di immagini responsive, ci riferiamo alle immagini inline in HTML. Questo perché prima del tag <picture> o dell’attributo srcset , era l’unica soluzione possibile. Con i CSS, potremmo usare le media-query, quindi non ci dovremmo preoccupare.. anzi no.

Adesso è tempo di mettere di nuovo mano a questa tecnica, usandone una più avanzata: il background image-set.

image-set() e risoluzione

Proprio come facciamo per le immagini inline, lasciamo che il browser scelga l’immagine di grandezza più adatta in base alla densità dello schermo dell’utente (o alla rete, o ad altri fattori). Vediamo rapidamente come usare la sintassi image-set:

Avrete sicuramente notato le similitudini tra questa sintassi e quella di srcset , che si basa difatti proprio su questa!

Due righe di storia

image-set() è stata il primo storico miglio per le responsive images ed è stato proprio lui a servire come base per l’attributo <img srcset=""> , che oggi è sicuramente più diffuso. Poi sono arrivate le CSS media queries e image-set è stato completamente ignorato, perfino dallo stesso Responsive Images Community Group.

Nonostante il supporto sia in fase di sviluppo, non tutti i browser supportano pienamente image-set() . Mentre scriviamo questo articolo IE, Edge e Firefox non lo supportano affatto, mentre per tutti gli altri è necessario usare il prefisso -webkit  in questo modo

Per tutti gli altri casi, e per una maggiore compatibilità, è consigliato usare le CSS media queries.

Media queries e risoluzione

Se vogliamo quindi supportare le immagini con una risoluzione più alta per gli schermi che lo consentono, il modo che offre maggiore compatibilità è quello delle media queries con un parametro di densità:

La prima cosa da notare è che abbiamo di nuovo dovuto usare un attributo con il prefisso -webkit , necessario per la retrocompatibilità. Abbiamo poi indicato l’attributo min-resolution  con una risoluzione di 192dpi, soltanto gli schermi con questa densità maggiore o uguale a questa saranno coinvolti.

Come possiamo notare, questo sistema è più potente del precedente perché ci permette di gestire più facilmente le risoluzioni. Nell’esempio precedente di background:image-set() , infatti, abbiamo dovuto indicare la densità con “1x” o “2x”, che non ci dicono davvero nulla.

 

 

Pubblicato il

Preparare le immagini per Lazyload JS in WordPress

In un precedente articolo, abbiamo visto come integrare il caricamento on scroll delle immagini con Lazyload JS. Possiamo naturalmente applicare lo stesso meccanismo ad un tema WordPress.

Nella pagina di un post, quindi ad esempio nel file single.php , WordPress posizionerà le immagini contenute nell’articolo come responsive images e lo farà usando la tecnica dell’attributo srcset del tag <img> . Se non conoscete questo meccanismo, è molto semplice: all’interno del tag <img> sono presenti diverse dimensioni della stessa immagine e la loro larghezza (width). Il browser selezionerà automaticamente quella adatta alla densità (leggi DPI) dello schermo dell’utente.

Vediamo un esempio di <img> responsive generata da WordPress:

In questo esempio è ben chiaro che l’immagine è presente in varie misure, dalla più piccola, larga appena 300px (300w) alla più grande da 1280px di larghezza (1280w). Quello che chiediamo al browser è di prendere dal server e mostrarci la più adatta alla densità del nostro schermo.

Adesso facciamo andare d’accordo Lazyload con le responsive image.

Come abbiamo visto nell’articolo relativo a LazyLoad JS, esso si basa sull’attributo data-srcset  e non sul srcset  di default per le immagini. Vediamo allora come far generare correttamente i tag delle immagini dei nostri post per farli processare allo script. Ricordate che questo processo è retroattivo: la modifica funzionerà automaticamente per tutti i nostri post!

Iniziamo aggiungendo questo codice al file functions.php  del nostro tema.

La function replace_img_src()  si occuperà di modificare automaticamente tutti i tag <img> presenti nel contenuto del post e riscriverà, per ciascuno, gli attributi data-srcset , scrset  e src. A questo punto, dobbiamo includere lo script Lazyload e inizializzarlo.

Il modo più semplice per farlo è incollare questo codice all’interno del file footer.php  del nostro tema, subito prima della chiusura del tag <body> :

Fatto, happy (lazy) loading!

Pubblicato il

Lazyload JS: caricamento immagini progressivo on scroll

Lazyload JS (chiamato anche vanilla-lazyload) è uno script che permette il caricamento delle immagini allo scroll della pagina (effetto detto appunto “lazy load”). Perché lo facciamo? Innanzitutto per velocizzare il caricamento della pagine e poi per fornire una migliore User Experience: soltanto le immagini che effettivamente sono visibili nel viewport saranno richieste al server e mostrate all’utente.

Sembra banale ma.. perché richiedere risorse al server che non verranno mai usate? Questo porta anche ad un secondo vantaggio: risparmiare risorse e banda consumata. Se usiamo un servizio CDN risparmieremo decisamente molte richieste.

Lazyload è uno script di soli 3Kb che non ha dipendenze, cioè può essere usato senza includere jQuery o altre librerie. È scritto in javascript “liscio” (detto vanilla) e ha un moltissime di opzioni di configurazione che vedremo in questo articolo.

Includiamo lo script

Innanzitutto includiamo lo script nelle nostre pagine. Il consiglio è quello di farlo attraverso un CDN, in modo da non caricare nessun file sul nostro server e sfruttare l’ottimizzazione di Cloudflare:

 

A questo punto ci sono vari modi per sfruttare le sue potenzialità. Tutto dipende da come sono posizionate le immagini nel nostro codice e che obiettivo vogliamo raggiungere. Vediamo tre esempi pratici:

Caso 1: immagini in-line

Usiamo questo semplice esempio per il caso più diffuso, cioè un immagine da caricare una volta che è “nello schermo”:

HTML

Javascript

Caso 2: immagini responsive con srcset

In questo caso usiamo la tecnica delle misure srcset , sostituendolo con l’attributo data-original-set :

HTML

Javascript

Caso 3: con il tag <picture>

Se usiamo il tag <picture> per le immagini responsive, possiamo usare un codice analogo a questo:

HTML

Javascript

Caso 4: immagini di sfondo CSS

Se volessimo applicare l’effetto lazyload a immagini posizionate come background-image  in CSS, possiamo farlo in questo modo:

HTML

Javascript

Ulteriori vantaggi

È SEO-friendly perché non nasconde le immagini ai motori di ricerca.

Funziona anche in presenza di altri script, come jQuery, Angular, React o Vue.

È molto più veloce del famoso jQuery lazyload: si stima infatti che sia circa 6 volte più veloce.

Pubblicato il

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.

Pubblicato il

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: