Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Lug 7 2008

Automatizzare le operazioni del cPanel da shell unix con i comandi wget, ftp e curl: download automatico del DB Mysql e monitorare la banda disponibile

Posted by Antonio Troise
Tweet

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

mentre, per scaricare solo una pagina con tutti i link interni:

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

In realtà la sintassi completa è:

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

cPanel Bandwidth

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

avremo questo risultato:

Output Textedit

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Tag:automator, awk, backup, banda, bandwidth, bash, cpanel, curl, database, download, ftp, grep, html, ksh, Mac os x, Mysql, password, sed, shell, unix, url, wget
CONTINUE READING >
5 comments
Apr 8 2008

Nuove modalità per risparmiare banda con WordPress 2.5: addio alla compressione Gzip direttamente da WordPress e comprimere del 60% il file prototype.js v1.6.0

Posted by Antonio Troise
Tweet

Tempo fa scrissi un paio di guide su come risparmiare banda sul proprio sito comprimendo tutte le pagine con Gzip e riducendo le dimensioni del file javascript prototype. Le operazioni che, però, avevo descritto in quei tutorial non sono più del tutto valide in WordPress 2.5. Ecco, in particolare, cosa è cambiato e come agire di conseguenze.

Addio alla compressione Gzip da WordPress

Su WordPress 2.3, per attivare la compressione delle pagine web, era sufficiente andare nel Pannello di Controllo di WordPress e, nella sezione Opzioni/Lettura (Options/Reading per la versione in lingua inglese), spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“. Questo permetteva, in tutta semplicità, di comprimere in formato Gzip (attivando la compressione HTTP) prima di inviarlo al browser, in modo da alleggerire la dimensione della pagina (risparmiando quasi il 70% di dimensioni in una pagina di puro testo) e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

Ora, con WordPress 2.5, tutto questo non è più possibile. Sono andato a vedere in tutti i menu e sottomenu dell’Area di Amministrazione di WordPress, ma della voce per la compressione del contenuto delle pagine web tramite gzip, non ve ne era più traccia. Ho trovato la conferma anche qui: pare che in In WordPress 2.5 questa opzione non sia più presente!

Pare che la spiegazione, data da Ryan Boren, sia quella che era nata nel Team di Sviluppo di WordPress, l’esigenza di voler spostare la decisione della compressione delle pagine web al server stesso; infatti, oramai, qualsiasi webserver è in grado di gestire la compressione del contenuto, e la maggioranza dei piani di hosting prevede questa funzione, sia abilitata per default, sia opzionale (come nel caso di cPanel). Evidentemente questo dovrebbe avere ovvi vantaggi prestazionali, anche se non ho ben chiaro quanto possa essere.

Riattivare la compressione gzip da php

Se, però, il vostro webserver è tra i pochi che non supporta la compressione gzip (sul mio per esempio no ho trovato la funzione), potete verificare, come suggerisce Elliott C. Back, se almeno il vostro interprete php offre le funzioni di controllo dell’output, e attivarle tramite .htaccess con queste due righe di comando:

Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:

Attenzione, però: se attivate la compressione via php, dovrete modificare il file tiny_mce_config.php (in wp-includes) come suggerito da Andrew Ozz nella lista wp-testers, e disabilitare la compressione in questo file, altrimenti l’editor visuale verrà compresso due volte!

Riattivare la compressione gzip con un plugin per WordPress

Se, però, come immagino, non volete mettere mano ai file php e non potete comunque attivare la compressione sul vostro webserver, potete allora installare il plugin realizzato da Sergej Müller. Si chiama Compress for WordPress 2.5, ed è un plugin che agisce pressoché allo stesso modo descritto nel capitolo precedente senza, però, richiedere alcuna modifica manuale. Purtroppo è in tedesco ma è abbastanza chiaro quello che fa: è sufficiente attivarlo e lui comprimerà e vostre pagine web da php.

Wordpress Content-Encoding Gzip
Come verificare che il plugin Compress for WordPress 2.5 svolga il suo lavoro

Di solito mi fido delle descrizioni che gli autori danno dei propri plugin, ma siccome, in questo caso, ci troviamo di fronte ad un plugin che non rilascia alcun feedback su quello che fa e risulta essere del tutto trasparente a tutti tranne che al browser, ho deciso di verificare se Compress for WordPress 2.5 funzionava correttamente, anche perché non volevo segnalare qualcosa di cui non ero neanche io certo sul suo funzionamento!

Per farlo ho installato una comoda estensione per Firefox, Live HTTP Headers 0.13.1, che permette di catturare e analizzare l’headers delle pagine HTTP che il browser visualizza. Infatti, l‘informazione che ci dice se la pagina è stata compressa, è contenuta in una variabile: Content-Encoding.

Se, quindi, attivo il plugin Compress for WordPress 2.5, e ricarico l’homepage del mio sito, vedrò che la maschera di Live HTTP Headers (raggiungibile da Firefox dal menu Strumenti/Live HTTP Headers) mostra il parametro suddetto settato come:

Content-Encoding: gzip

Se, invece, disabilito il plugin, il parametro di Content-Encoding non viene neanche passato e, l’unica cosa che è possibile trovare (e che si trova anche nel caso) precedente, è il parametro “Accept-Encoding: gzip,deflate” che sta ad indicare che il nostro browser è in grado di gestire i contenuti compressi.

Quindi, in soli due minuti, abbiamo verificato che il plugin svolgesse correttamente il suo lavoro!

Compressione del 150% del file prototype.js 1.6.0

Per quanto riguarda, invece, la compressione del voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, non è cambiato molto se non la versione da utilizzare. Infatti, rispetto a WordPress 2.3, che usava la versione 1.5.1.1, la nuova release di WordPress 2.5 usa la versione 1.6.0.
Potete controllarlo voi stessi: basterà leggere la prima riga del file wp-includes/js/prototype.js

Quindi, se non volete comprimere voi stessi il file javascript (che di per sé è grande 121 KB), con un dei tanti tool online che ho descritto in precedenza, dovete fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi tutte le versioni di Prototype.

Quello che dovrete fare voi, quindi, è scaricare il file protopack_v2.19b.zip dal sito Prototype: Core (nel vecchio tutorial era il protopacked_v2.17.zip), scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous.
In particolare questo package contiene le release 1.4, 1.5, 1.5.1.2 e 1.6.0.2 di Prototype e la release 1.7.1_beta3, 1.8.1 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora potete far riferimento direttamente al file Protoculous (esistono le versioni 1.5.1.2 + 1.7.1_beta3 e 1.6.0.2 + 1.8.1), che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, nel nostro caso sarà sufficiente scegliere la versione compressa del file prototype.js. Quindi, una volta scaricato e scompattato il pacchetto zip protopack_v2.19b.zip, aprite la cartella “files” e vi troverete 3 cartelle: qui aprite la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.6.0.2“ (non è esattamente la stessa versione rilasciata con WordPress 2.5, ma i cambiamenti sono davvero minimi e comunque compatibili con una release inferiore).
Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

prototype-1.6.0.2-packer.js : compresso con Dean Edward’s Packer 3 \w con le opzioni “Base62 encode” e “Shrink variables”
prototype-1.6.0.2-shrinkvars.js : compresso con Dean Edward’s Packer 3 \w con la sola opzione “Shrink variables”.

La differenza, sostanzialmente, sta nelle dimensioni: il prototype-1.6.0.2-packer.js è grande 48 KB (la versione 1.5.1.1 compresso, che si usava con WordPress 2.3, invece, era grande solo 40 KB) mentre prototype-1.6.0.2-shrinkvars.js arriva fino a 76 KB.
Io, per il mio sito, ho usato prototype-1.6.0.2-packer.js (risparmiando oltre il 60% di spazio) che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file (magari fatene un backup per sicurezza).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5
CONTINUE READING >
12 comments
SeguiPrezzi - Risparmia con Amazon.it

Categorie

Commenti Recenti

  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Fioredicollina on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Emanuele on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Luca on iDatabase: la valida alternativa di Bento per macOS e iOS per i database personali

Meta

  • Accedi
  • Entries RSS
  • Comments RSS
  • WordPress.org

Friends Link

  • GamerTagMatch
  • SeguiPrezzi.it – Risparmia con Amazon.it
  • Trendy Nail

Seguimi su:

  • facebook
  • twitter
  • rss
Creative Commons License
Levysoft by Antonio Troise is licensed under a Creative Commons Attribuzione-Non commerciale 2.5 Italia License.
© Copyright 2004 - 2014 - Levysoft by Antonio Troise