Appunti – Pagina 4 – Simone Zanella

500 Internal server error durante l’aggiornamento del database di WordPress

Un errore durante l’aggiornamento all’ultima versione di WordPress (4.2.1) mi ha causato un grosso problema su un sito: nel dettaglio provando ad accedere alla bacheca di amministrazione compare il messaggio (tipico dopo gli aggiornamenti più importanti di WordPress):

E’ richiesto l’aggiornamento del database:
WordPress è stato aggiornato! Prima di proseguire, dobbiamo aggiornare il database alla nuova versione.

e dopo aver lanciato l’aggiornamento, il server restituisce dopo un po’ di minuti l’errore “500 Internal Server Error”. Il tutto si ripete ad ogni tentativo di aggiornamento, rendendo impossibile accedere alla bacheca di WordPress.

Dopo aver consultato a fondo la guida di WordPress, l’unica soluzione trovata (nella rete si trovano diverse guide, ma sono quasi tutte legate a WordPress installati su hosting commerciali tipo Aruba) è stata modificare manualmente nel database la versione del database corrente. Se avete accesso al pannello di gestione del database del vostro sito (tipicamente phpMyAdmin o simili), dovete cercare nella tabella wp_options il campo db_version:

il valore numerico sostituendolo con il valore che trovate a questa pagina, in cui si trovano i codici relativi alla versione del database rapportati alla versione corrente di WordPress (ovvero quella cui avete aggiornato prima dell’errore).

Dopo aver effettuato la modifica, WordPress ha ripreso a funzionare perfettamente, sono stati provati ulteriori aggiornamenti di WordPress, temi e plugin con successo.

Versione di WordPress pre-aggiornamento: 4.2 Italiano

Versione dell’aggiornamento: 4.2.1 Italiano

Problema Plesk: “New configuration files for the Apache web server were not created due to the errors in configuration templates: mkdir: cannot create directory …”

Ecco un problema che si è presentato su Plesk (versione 12.0.18) rinominando, in una sottoscrizione, un dominio utilizzando la scheda Hosting Settings presente in Websites and Domains. Per esempio ipotizzeremo di rinominare il dominio simonezanella.com in simonezanella.it:

Dopo l’operazione, Plesk mostra questo errore:

New configuration files for the Apache web server were not created due to the errors in configuration templates: mkdir: cannot create directory `/var/www/vhosts/system/simonezanella.it/conf': No such file or directory mktemp: failed to create file via template `/var/www/vhosts/system/simonezanella.it/conf/httpd.conf.XXXXXX': No such file or directory Can not create temporary file . Detailed error descriptions were sent to you by email. Please resolve the issues and click here to generate broken configuration files once again or here to generate all configuration files.

Cliccando come suggerito i problemi non vengono corretti, ma si visualizza il seguente errore:

Unable to configure the web server: Execution failed. Command: httpdmng Arguments: Array ( [0] => --reconfigure-all ) Details: Error occured while sending feedback. HTTP code returned: 502 Error occured while sending feedback. HTTP code returned: 502 Execution failed. Command: httpdmng Arguments: Array ( [0] => --reconfigure-domains [1] => simonezanella.com,simonezanella.it )

Anche rinominando la sottoscrizione originaria il problema rimane. Se non si ha a disposizione un backup della sottoscrizione in Plesk (ripristinandola il problema si risolve automaticamente), si seguono questi passi (verificare che il vostro problema sia esattamente lo stesso) una volta loggati via SSH al vostro server:

si verifica che la directory radice (root directory) per il dominio simonezanella.com non esiste, ovvero: “/var/www/vhosts/simonezanella.com/httpdocs” non è presente sul server, mentre la root directory per il dominio simonezanella.it invece esiste:
“/var/www/vhosts/simonezanella.it” ma manca la cartella httpdocs, ovvero: “/var/www/vhosts/simonezanella.it/httpdocs”

in /var/www/vhosts/simonezanella.it/ bisogna ora lanciare i seguenti comandi:

mkdir httpdocs
chown simone:psaserv httpdocs
chmod 750 httpdocs

mettendo al posto di simone ovviamente il vostro utente per la cartella, poi bisogna settare i valori corretti nel database del server nelle tabelle “hosting” e “sys_users” del database “psa”:

mysql> update hosting set www_root='/var/www/vhosts/simonezanella.it/httpdocs' where dom_id=3;
mysql> update sys_users set home='/var/www/vhosts/simonezanella.it' where id=2;

(verificate gli id nel database, i valori indicati sono di esempio, potete anche farlo direttamente da Plesk via PHPMyAdmin)
dopodichè si lancia il comando di riconfigurazione dominio:

/usr/local/psa/admin/bin/httpdmng --reconfigure-domain simonezanella.it

se tutto è stato fatto correttamente, il problema dovrebbe essere risolto.

Problema virus / malware Napolitano su router DLink, iPhone, WiFi, cellulari

Iniziano a capitarmi frequenti richieste di assistenza su “apparenti” infezioni del “virus di Napolitano”, come comunemente chiamato dagli utenti meno esperti. La famosa pagina di Napolitano e della Polizia di Stato che vi invitano ad espiare le vostre colpe sul web inviando denaro a degli sconosciuti si presenta su computer infetti da virus, e molti rimangono sorpresi a vederla comparire anche su cellulari, iPhone, iPad e computer Linux e Mac, che in genere vivono abbastanza tranquilli da infezioni di questo genere. Tuttavia in questo caso il problema non è legato a un virus, ma alla vulnerabilità di una gran serie di modelli di modem/router per la connessione ADSL casalinga, tra le cui marche spiccano D-Link, Hamlet, TP-Link, Kraun e non solo). Tale vulnerabilità consente di modificare dall’esterno le impostazioni del router in modo che gli utenti siano costretti a visitare la famigerata pagina mentre navigano da un qualsiasi connesso via cavo o WiFi al dispositivo “hackerato”.

Prima di perdere tempo quindi cercando di trovare il virus nei vostri dispositivi, occorre concentrarsi sul proprio modem router.

Per chi è un po’ più esperto, può inizialmente tentare un test del proprio apparecchio andando alle pagine: http://upnp-check.rapid7.com/ e http://rom-0.cz/ anche se i risultati non sono sufficienti ad escludere al 100% la vulnerabilità.
Per risolvere il problema, è meglio innanzitutto resettare alle impostazioni di fabbrica il router, e cercare un aggiornamento (upgrade) del firmware (se esiste), in genere disponibile sul sito della casa produttrice. L’operazione di aggiornamento del firmware non è difficile ma è delicata. Dopodichè si consiglia di disabilitare la possibilità di amministrare a distanza il router (tipicamente sotto la voce REMOTE ACCESS MANAGEMENT o simile).
Se non siete particolarmente pratici di impostazioni dei router, e se IP, DNS, LLC, PPOE sono sigle a voi sconosciute è meglio rivolgersi a un centro di assistenza.

Riprendere una installazione con YUM su server Linux

Nel caso si interrompa una installazione con il gestore di pacchetti YUM su un server Linux, si può riprendere utilizzando un apposito comando fornito col pacchetto YUM-utils, che va installato con la riga di comando:

install yum-utils

dopodichè è sufficiente lanciare il comando:

yum-complete-transaction

Rimuovere certificati e chiavi SSH dal terminale di MacOS

Nel caso sia necessario dover rimuovere dei certificati di accesso a server in remoto via SSH attraverso il terminale di MacOS (ad esempio un certificato è cambiato e viene rifiutata la connessione), sempre da terminale bisogna cercare la cartella:

/Users/*******/.ssh/

dove al posto degli asterischi c’è il nome dell’utente corrente; all’interno della cartella .ssh si trova il file:

known_hosts

da cui con l’editor VI si possono rimuovere le righe interessate (ognuna inizia con l’IP del server di cui si è memorizzata la chiave), oppure si può cancellare tutto il file.