WordPress: aggiornare il database da riga di comando

wordpress aggiornamento database

L’aggiornamento automatico di WordPress funziona alla grande nel 90% dei casi (ok, forse nell’80%…), ma una volta aggiornati i file (tutto sommato la parte più semplice della procedura di upgrade a una nuova versione) può venir richiesto un upgrade del database la prima volta che ci si collega alla schermata di login alla dashboard.

Accedendo a wp-login.php o wp-admin si viene reindirizzati alla URL “http://nomedominio/wp-admin/upgrade.php”, cioè lo script php di upgrade del database. E qui arrivano i dolori se il database da aggiornare non si limita a pochi MB ma arriva a pesare qualche GB. Con database molto pesanti il tempo di aggiornamento aumenta considerevolmente, il consumo di risorse di mysql (CPU e RAM) sulla macchina su cui si sta aggiornando schizza in alto e lo script upgrade.php può andare in timeout non riuscendo a terminare la procedura con successo. Una procedura di upgrade del database di WordPress che non si conclude in modo ottimale può comportare l’impossibilità di accedere ancora al backend del blog, con il messaggio “è necessario l’aggiornamento del database” che continua a riproporsi.

Aggiornamento database WordPress, come riaccedere al proprio blog

Le strade sono due per riaccedere al proprio WordPress: si accede via FTP o ssh al file /wp-includes/version.php e lo si modifica con un editor di testi cambiando il numero di versione del database inserendo l’identificativo della versione da cui si è effettuato l’upgrade. Ad esempio se aggiornavamo da WordPress 4.5.4 a WordPress 4.6.1 e non accediamo più al backend, la versione del database da inserire per poter accedere nuovamente al backend è la 36686, dovremo pertanto andare a togliere la versione del database relativa a WordPress 4.6.1 che è la 37965. La parte di codice interessata a questa modifica in version.php è la seguente:

Continua a leggere

slowhttptest: DoS contro Apache con la vulnerabilità range header (ma non solo)

Il 19 agosto scorso, sulla Full Disclosure Mailing List, è comparso un messaggio di Kingcope con allegato “killapache.pl” uno script PERL che ha messo a nudo una vulnerabilità in Apache in grado di consentire un DoS del webserver (dunque un DoS Layer 7 di cui ho già parlato in precedenza anche se mi riferivo a DDoS) open source. Basta che ad eseguire lo script da un solo PC per mettere in ginocchio Apache e la macchina che lo esegue a causa dell’elevato consumo di RAM e CPU. Lo script è tutt’altro che perfetto e non sempre affidabile nello sfruttare la vulnerabilità. Dai test che ho potuto effettuare spesso il bersaglio veniva riconosciuto come non vulnerabile pur essendolo.

A distanza di meno di una settimana dal messaggio di Kingcope la possibilità di sfruttare la vulnerabilità “range header handling” di Apache è stata inclusa nel tool slowhttptest versione 1.1. Il team di Apache ha rilasciato da pochi minuti una nuova release del web server, Apache HTTP Server 2.2.20, proprio per correggere la vulnerabilità, ma si può far ricorso comunque a slowhttptest per effettuare dei test sui propri web server o su server che non siano aggiornati (è probabile che le maggiori distribuzioni Linux includano l’aggiornamento tra le patch di sicurezza rilasciate nelle prossime ore). Vediamo come installarlo e utilizzarlo.

Installazione di slowhttptest:

$ tar -xzvf slowhttptest-1.1.tar.gz

$ cd slowhttptest-1.1

$ ./configure --prefix=/usr/local/
$ make

$ sudo make install

Per verificare la tenuta di Apache allo sfruttamento della vulnerabilità range header possiamo far riferimento alla documentazione presente su ApacheRangeTest, per esempio si potrà eseguire il seguente comando:

slowhttptest -R -u http://127.0.1.1/ -t GET -c 1000 -a 10 -b 3000 -r 500

Se invece avete necessità di verificare la resistenza di Apache a un “normale” DoS (una sorta di stress test un po’ brutale) basterà usare slowhttptest nel modo che segue:

./slowhttptest -c 1000 -B -g -o my_server_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u http://www.mioserverditest.com -x 10

Per il significato dei parametri passati rimando a slowhttptest installazione e uso.

Importante: evitate di lanciare attacchi DoS con slowhttptest su server che non siano di vostra proprietà, si tratta di azioni punibili penalmente.

Riferimenti:

Howto: Debian Squeeze+Nginx+WordPress

Nginx è uno tra i webserver open source che si sta diffondendo di più tra i sistemisti che ricerchino performance elevate e un consumo di risorse inferiore rispetto ad Apache (ma anche ad alternative “minimaliste” con Lighttpd). Il grosso neo di nginx è la poca documentazione, sul sito ufficiale c’è davvero poco, la cosa sarebbe in parte compensata da diversi articoli che però sono tutti più o meno imprecisi nella descrizione delle giuste configurazioni da apportare al webserver, soprattutto quando si vuole far funzionare WordPress. Quello che riporto è un howto, frutto dell’esperienza che ho avuto installando nginx su un VPS (sull’ottimo Quickweb), che spero sia di aiuto a quanti vogliano installare nginx su Debian Squeeze e servire pagine generate da WordPress.

La prima cosa da fare su Debian Squeeze è aggiungere il repository dotdeb al file “sources.list” per poter installare la versione 1.0 di nginx. Per farlo basterà dare da terminale come utente root i seguenti comandi:

nano /etc/apt/sources.list

aggiungiamo la seguente riga:

deb http://packages.dotdeb.org stable all

a questo punto dobbiamo aggiungere la chiave GnuPG così:

wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | sudo apt-key add -
rm dotdeb.gpg

aggiorniamo il tutto con APT:

apt-get update

Adesso possiamo installare php5, php5-fpm, cioè il FastCGI Process Manager che ci consentirà di servire pagine PHP attraverso nginx, e ovviamente nginx stesso:

apt-get install php-apc php-auth php-net-smtp php-net-socket php-pear php5 php5-cgi php5-cli php5-common php5-curl php5-dev php5-gd php5-imagick php5-imap php5-mcrypt php5-mysql php5-pspell php5-sqlite php5-suhosin php5-xmlrpc php5-xsl php5-fpm nginx

fatto questo potremo installare anche MySQL server e client (in fase di installazione di MySQL server dovremo scegliere una password da impostare per l’utente root)

apt-get install mysql-server mysql-client

Impostiamo delle configurazioni personalizzate a nginx andando a modificare alcuni valori nel file di configurazione nginx.conf:

nano /etc/nginx/nginx.conf

client_max_body_size 20M;
client_body_buffer_size 128k;

a questo punto possiamo rimuovere il virtual host di default di nginx e crearne uno nuovo per il sito che dovremo servire:

cd /etc/nginx/sites-enabled
rm default

creiamo un file per il nostro sito

nano /etc/nginx/sites-available/www.bufferoverflow.it

Incolliamoci la seguente configurazione:

server {
listen 80;
server_name www.bufferoverflow.it bufferoverflow.it;

access_log /var/log/bof.access_log;
error_log /var/log/bof.error_log;

root /var/www/htdocs/www.bufferoverflow.it;
index index.php index.htm index.html;

try_files $uri $uri/ /index.php?q=$uri&$args;
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/htdocs/www.bufferoverflow.it$fastcgi_script_name;
include fastcgi_params;
}
}

La riga “try_files $uri $uri/ /index.php?q=$uri&$args;” è fondamentale per il funzionamento di WordPress come anche le righe da “location ~ .php$ {” a “include fastcgi_params;” basilari per il funzionamento di php5-fpm.

Creiamo a questo punto un nuovo link simbolico per il virtual host creato sotto “sites-enabled“:

ln -s /etc/nginx/sites-available/www.bufferoverflow.it /etc/nginx/sites-enabled/www.bufferoverflow.it

Configuriamo php5-fpm andando a modificare il file “/etc/php5/fpm/pool.d/www.conf”, qui la scelta fondamentale da fare è se rendere FastCGI dinamico o statico, personalmente dovendo agire su un VPS con solo 300 MB di RAM ho preferito impostare come statico php5-fpm in modo tale da non trovarmi con un consumo di RAM eccessivo, inoltre ho limitato il numero di processi generati, questo è il valore da variare:

; Choose how the process manager will control the number of child processes.
; Possible Values:
; static - a fixed number (pm.max_children) of child processes;
; Note: This value is mandatory.
pm = static

inoltre ho variato il numero massimo di processi figli generati impostando “5”:

pm.max_children = 5

Molto importante è decidere se php5-fpm ascolterà su una porta o su un socket, personalmente ho optato al momento per farlo ascoltare sulla porta 9000, quella di default, su localhost, la riga è questa:

listen = 127.0.0.1:9000
;listen = /dev/shm/php-fastcgi.socket #l'ascolto su un socket dovrebbe migliorare le performance ma ancora non ho provato

Potete vedere il mio file di configurazione su Pastebin.

Apportate le dovute configurazioni dovrete riavviare sia nginx che php5-fpm.

Restart di nginx:

/etc/init.d/nginx restart

Restart php5-fpm:

/etc/init.d/php5-fpm restart

A questo punto dovremo installare WordPress, tralascio le operazioni da fare per l’installazione ma segnalo la procedura di creazione del database da linea di comando con MySQL client. La cosa importante per far funzionare adeguatamente i pretty permalink è ricorrere all’installazione di un plugin che consente di eliminare “index.php” dalle URL consentendo di lasciare la struttura di permalink scelta da noi, il plugin è nginx compatibility.

In conclusione, consiglio qualche link che mi ha aiutato notevolmente nell’installazione e configurazione di nginx:

  1. nginx + php-fpm + debian squeeze tutorial – the fastest way to host php!
  2. Howto nginx + wordpress + ubuntu shortest setup
  3. nginx wiki
  4. How To: Install NginX, PHP-FPM, MySQL, PHP 5.3.3 & WordPress on Ubuntu (Part 2)
  5. Installing Nginx With PHP5 And MySQL Support On Debian Lenny

Esportare e importare database MySQL di grosse dimensioni

Chi ospita il proprio sito su un hosting condiviso difficilmente ha la possibilità di avere accesso ad SSH e dunque poter utilizzare mysldump o mysql per l’esportazione e importazione di un database SQL. Inoltre, molto spesso phpMyAdmin non consente il backup di database che superino una certa dimensione (spesso il limite sono appena 2MB, Webperte ne è un esempio…) e soprattutto non ne consente l’importazione.

Nel tempo ho selezionato alcuni script e programmi che mi facilitano di molto quando ho la necessità di importare/esportare database MySQL di grosse dimensioni. Ecco la mia personale cassetta degli attrezzi:

Continua a leggere

Installare un sistema Slackware 12.2 minimale con i tagfiles

Può capitare a volte di voler installare un sistema Slackware minimale, privo di interfaccia grafica e di software accessori che non servono ad esempio per l’utilizzo server. Per portare a termine un’installazione minimale di Slackware 12.2 (e precedenti) è necessario soltanto il primo CD-ROM. Basta avviare l’installazione e al momento della scelta dei pacchetti selezionare soltanto le seguenti serie:

  • a
  • ap
  • d
  • e (opzionale se si vuole installare emacs)
  • l
  • n

Tuttavia per effettuare un’installazione automatizzata, cioè senza intervenire per confermare la scelta dei pacchetti, è necessario utilizzare i cosiddetti tagfiles. Si tratta di semplici file di testo presenti in ogni cartella del CD di Slackware contenente pacchetti tgz che danno istruzioni su cosa fare durante l’installazione.

Continua a leggere

Proteggere l’area amministrativa di WordPress con .htaccess

È vero che esiste un plugin apposito, AskApache Password Protect, che permette di proteggere l’accesso alla cartella “wp-admin” e lo fa in modo avanzato ma perché ricorrere a un plugin quando l’operazione è fattibile a mano in 4 semplici passi?

Ecco le operazioni da compiere per proteggere l’area amministrativa di WordPress (wp-admin) con un file .htaccess:

  1. Per prima cosa creiamo un file chiamato “test.php” e incolliamoci la seguente stringa “<?php phpinfo() ; ?>”. Fatto questo carichiamo il file con un client FTP nella root del nostro web server.
  2. Accediamo al file test.php nel nostro spazio web (es. www.nostrosito.net/test.php) e cerchiamo la riga “SCRIPT_FILENAME” e annotiamoci il percorso del file.
  3. Utilizziamo il servizio .htaccess generator. Inseriamo username e password scelte e nel campo PATH scriviamo il percorso visto in precedenza grazie a “test.php” aggiungendo alla fine “wp-admin”. Cliccando su “Generate .htaccess” verranno generati un file .htaccess e uno .htpasswd
  4. Carichiamo nella cartella “wp-admin” della nostra installazione di WordPress i file .htaccess e .htpasswd.

Se tutto è andato bene digitando “www.nostrosito.net/wp-admin” comparirà una maschera in cui dovremo inserire username e password scelte in fase di generazione del file .htaccess.
Oltre ad avere una doppia autenticazione all’area amministrativa, potremo proteggere quest’ultima da bot o visitatori troppo curiosi.

Da WordPress 2.1 a 2.1.1

Il vecchio adagio recita: RTFM (Read The Fucking Manual). E così ho fatto leggendomi accuratamente la pagina Upgrading WordPress.
Prima ho backuppato il db del blog con phpMyAdmin, quindi mi sono loggato all’amministrazione di WordPress e ho disattivato tutti i plugin, ho impostato il tema sul default (Kubrick) e per un eccesso di paranoia ho esportato tutti i post in un file xml (da Manage/Export). A questo punto con FileZilla ho fatto un backup di tutta la cartella httdocs sul mio spazio web posizionando il tutto su una partizione del mio pc.
Tranquillizato dal fatto di avere backup in abbondanza ho caricato i nuovi file di WP 2.1.1 sul mio spazio web sovrascrivendo i vecchi ad eccezione della cartella /wp-content/.
Ho effettuato l’upgrade del db tramite apposito script di WordPress, riattivato plugin e tema grafico e, come potete vedere, tutto è tornato a funzionare.
Insomma il mio primo aggiornamento a una nuova versione di WP è andato liscio 🙂