Creare un veloce sito WordPress con Docker e Raspberry Pi

Mi è capitato di dover effettuare importanti modifiche ad un sito realizzato con WordPress e avere le necessità di condividere il lavoro con altre persone.
Invece di “pasticciare” sul server di produzione, ho pensato di utilizzare il Raspberry Pi 4 che ho in casa come server di sviluppo.
Siccome il Raspberry in questione svolge già una miriade di compiti, per non smanettare troppo ho deciso di usare Docker, così da avere un’istanza preconfigurata di WordPress facilmente installabile e rimovibile quando non mi servisse più.

Su Docker Hub esiste l’immagine ufficiale di WordPress, ma si appoggia ad un database MySQL che non sembra funzionare sull’architettura ARM del Raspberry Pi.
Ho quindi scelto un’immagine specifica per ARM e l’installazione è andata liscia.

Questo è il mio file docker-compose.yml:

version: '3.1'
 services:
 wordpress:
     image: wordpress:latest
     container_name: wordpress
     restart: always
     ports:
       - 8080:80 # il sito comunicherà con l'esterno attraverso la porta 8080, modificabile a piacere  
     environment:
       WORDPRESS_DB_HOST: db
       WORDPRESS_DB_USER: test
       WORDPRESS_DB_PASSWORD: password
       WORDPRESS_DB_NAME: test
     volumes:
       - /opt/docker/wordpress/data:/var/www/html #per comodità ho creato una cartella dove archiviare i file di WordPress
 db:
     image: biarms/mysql # ho modificato questa riga per utilizzare l'immagine MySQL di biarms per ARM
     restart: always
     environment:
       MYSQL_DATABASE: test
       MYSQL_USER: test
       MYSQL_PASSWORD: password
       MYSQL_RANDOM_ROOT_PASSWORD: '1'
     volumes:
       - db:/var/lib/mysql
 volumes:
   wordpress:
   db:

Non sono un esperto di Docker, quindi probabilmente tutto si potrebbe fare meglio di così, ma in questo modo nel giro di pochi minuti ho avuto un’istanza funzionante di WordPress raggiungibile all’indirizzo http://<IP_RASPBERRYPI>:8080 .

Perchè il sito fosse raggiungibile anche dall’esterno mi è bastato utilizzare il reverse proxy Nginx già presente nella mia configurazione (a voi il divertimento eventuale di configurarlo e aprire le porte del vostro router casalingo, sul web trovare migliaia di tutorial e how-to) aggiungendo queste righe al file .conf già presente in /etc/nginx/sites-enabled :

location /test/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://0.0.0.0:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;

Dopo aver riavviato Nginx

$ systemctl reload nginx.service

la mia installazione WordPress è raggiungibile digitando http://MIO_INDIRIZZO_IP/test .

Però si era detto che questo sarebbe stato un sito di prova e non è bello che sia accessibile da chiunque.
Per questo ci viene in soccorso la basic authentication di Nginx : basta creare gli utenti desiderati con il comando :

$ sudo htpasswd /etc/apache2/.htpasswd utente1

e poi editare ancora il precedente file .conf di Nginx :

...
 location /test/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://0.0.0.0:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;

        # authentication
        auth_basic           "Area di test - Accesso riservato";
        auth_basic_user_file /etc/apache2/.htpasswd;

Un altro $ systemctl reload nginx.service per caricare la nuova configurazione e voilà!

A questo punto è bastato fare una copia del sito originale con il plugin Duplicator per WordPress, cancellare il contenuto della cartella data e sostituirlo con i due file creati da Duplicator, un archivio e un installer.
Andando all’indirizzo http://MIO_INDIRIZZO_IP/test/installer.php ho avviato la procedura di migrazione e in pochi minuti ho avuto una perfetta replica del mio sito, pronta per essere modificata a piacimento.
Una volta soddisfatto delle modifiche, sempre utilizzando Duplicator, potrò compiere la migrazione in senso inverso, dal server di test a quello pubblico.

Canonscan 200 Lide con Debian

Cosa c’è di più ovvio da fare in questi giorni di quarantena che andare a frugare tra le vecchie cose con il velleitario intento di mettere un po’ di ordine?
Ecco che su uno scaffale a prendere polvere trovo un vecchio scanner Canon, un Canoscan 200 Lide.

Collegato all’ancor più vecchio iMac su cui è installata Debian Bullseye, viene riconosciuto immediatamente. Bingo!

La prima scansione di prova però presenta una barra nera che si estende verticalmente su tutta l’immagine, più o meno così:

https://i.stack.imgur.com/b3gij.jpg


Collegato a Mac OS lo scanner funziona invece regolarmente, così da poter escludere che sia un problema hardware.

Tornato a Linux, dopo aver installato sane riesco a far diventare la barra verticale da nera a semplicemente più chiara, ma sempre molto fastidiosa.

Qualche ricerca su Internet mi porta a ritenere che il problema sia nella versione più recente del pacchetto sane-backends, così decido di provare con l’ultima versione che sembra funzionare, la 1.0.25 .

Decido di provare con i sorgenti Debian con l’ultima versione disponibile, così come suggerito qui:

$ sudo apt-get source libsane

L’installazione potrebbe chiedere il pacchetto dpkg-dev, nel caso installatelo.

A questo punto dobbiamo editare un file

$ cd sane-backends-1.0.27/backend/

$ nano -c genesys.c

le righe da modificare sono quelle dalla 2075 alla 2077 e vanno modificate così (in neretto le modifiche da applicare):

if (dev->model->flags & GENESYS_FLAG_SHADING_REPARK && dev->model->cmd_set->slow_back_home)
    {
      status = dev->model->cmd_set->slow_back_home (dev, dev->model->flags );

Salviamo, usciamo dall’editor e compiliamo (installate eventuali dipendenze necessarie):


$ sudo apt-get build-dep libsane
$ cd sane-backends-1.0.27
$ dpkg-buildpackage -rfakeroot -uc -b

Qui il mio vecchio iMac di 12 anni ha lavorato per un po’, su un computer più recente la compilazione non dovrebbe richiedere troppo tempo.
Se tutto va come previsto, dovreste avere il pacchetto pronto da installare:

$ sudo dpkg -i libsane_1.0.27-3.2_amd64.deb

Se richiesto, nella stessa cartella troverete anche i .deb con le necessarie dipendenze.

Alla prima prova lo scanner funzionava già perfettamente, ma potrebbe essere opportuno un riavvio del sistema.

Non resta che impedire che il pacchetto venga sostituito con un aggiornamento successivo:

$ sudo apt-mark hold libsane

Comandare Raspberry Pi usando Telegram

Ho tirato fuori dalla polvere una vecchia Raspberry Pi e, grazie a motionEye, l’ho trasformata in un sistema di videosorveglianza artigianale più che adatto alle mie esigenze.
Usando il rilevatore di movimento combinato con Pushover, ho un sistema che mi avvisa nel caso qualcuno entrasse in casa mentre non ci sono. Fortunatamente fino ad adesso ho collezionato solo molti scatti dei viaggi del mio gatto fino alla sua ciotola e documentato i suoi invidiabili pisolini pomeridiani.

Disattivare però motionEye quando mi trovo in casa per evitare che scatti l’allarme ogni volta che passo dal soggiorno è abbastanza scomodo: devo loggarmi al Raspberry Pi via ssh e digitare ogni volta il comando di stop.
Stavo cercando se ci fosse il modo di creare un bottone fisico, quando mi sono imbattuto in un articolo che spiega come sia possibile impartire comandi a distanza usando il sistema di messaggistica Telegram.

La configurazione è abbastanza agevole, ma la parte di compilazione, su una board di prima generazione ha richiesto ben di più della classica pausa caffè.
(Se la compilazione non andasse a buon fine con un errore simile:

telegram-cli: tgl/mtproto-utils.c:101: BN2ull: Assertion 0' failed. SIGNAL received

date un’occhiata a questa soluzione, basta commentare una riga e ricompilare).

Una volta effettuati tutti i test del caso, ho voluto trovare il modo di automatizzare anche l’avvio di Telegram.
Le istruzioni di configurazione del demone mi hanno demoralizzato quasi subito, così ho optato per una soluzione meno elegante ed efficiente, ma decisamente più alla mia portata.

L’opzione -d permette di lanciare il client come demone, non resta quindi che farlo partire in automatico all’avvio e il gioco è fatto.

$ bin/telegram-cli -k tg-server.pub -d -v -s action.lua

Quindi usiamo cron per lanciare il comando all’avvio:

$ crontab -e
# lancia telegram demonizzato all'avvio
@reboot /home/pi/tg/bin/telegram-cli -k tg-server.pub -d -v -s action.lua

Editando poi il file action.lua è poi abbastanza facile creare tutti i comandi che si vogliono.

if (msg.text=='start-motion') then
   os.execute('systemctl start motioneye')
   send_msg (msg.from.print_name, 'motionEye avviato!', ok_cb, false)
end

Migrare i bookmark da Pocket a Shaarli

Nei miei continui disperati tentativi di affrancarmi il più possibile da servizi esterni con dubbio rispetto della privacy, mi sono imbattuto in Shaarli.
Dalle prime prove su strada sembra un ottimo strumento per salvare ed eventualmente condividere i propri segnalibri, un po’ come faceva il compianto Delicio.us.

Da tempo a questo scopo uso Pocket, relativamente tranquillizzato dal fatto che sia stato acquisito da Mozilla.

Volendo però provare un’installazione di Shaarli sul mio hosting, ho voluto provare a importare tutta la mia lista di Pocket.

La procedura di esportazione dei segnalibri in Pocket richiede un solo clic e genera un semplice file HTML, ma Shaarli si rifiuta di importarlo lamentandosi di un formato non corretto.
Cercando in rete ho trovato un template di una esportazione in formato Netscape.

Ho provato a modificare il file generato da Pocket come segue:

modificato il DOCTYPE (riga 1) come segue:

<!DOCTYPE NETSCAPE-Bookmark-file-1>

I segnalibri sono inclusi in una lista, ho modificato i tag così (qualsiasi editor di testo con la funzione trova & sostituisci sarà più che sufficiente):

<ul> ----> <dl>
</ul> ---> </dl>
<li> ----> <dl>
</li> ---> </li>
<tags> --> <TAGS> (in maiuscolo)

Una volta salvato il file verrà importato senza problemi da Shaarli con le tags correttamente impostate.

Utilizzare una vecchia Airport Express per estendere il segnale Wi-Fi

Una vecchia base Airport Express del 2007 trovata in una scatola di vecchiume informatico mi ha suggerito l’idea di utilizzarla per migliorare la ricezione del Wi-Fi nelle stanze della casa dove il segnale è più debole.
Nonostante abiti in un piccolo appartamento, basta allontanarsi dalla stanza dove è il router per notare bruschi cali nella potenza del segnale e nella velocità di connessione.
La possibilità di connettersi sia tramite Ethernet che wireless rende Airport Express ideale per lo scopo.

Una vecchia base Airport Express di Apple
Premetto che ho un cavo Ethernet che dal router attraversa la casa fino a raggiungere un angolo studio ricavato in camera da letto, e proprio a quel cavo ho collegato la base Airport Express in modo che abbia sempre una connessione stabile e veloce.

Il primo problema da risolvere è quello di configurare la base, visto che le versioni più recenti delli Utility Airport rilasciate da Apple non supportano più le vecchie basi Airport.
Inutile chiedersene il motivo, Apple ci ha ormai abituato a scelte apparentemente senza giustificazioni logiche, è la croce e delizia del cosidetto “giardino chiuso” dei prodotti della Mela.L’ultima versione di Utility Airport che supporta questa vecchia versione di Airport Express è la 5.6.1, ma per farla girare sulle versioni di OSX più recenti ho dovuto seguire questi utili consigli.

Una volta ottenuta una versione funzionante dell’Utility Airport, basta collegare la base direttamente al Mac tramite porta Ethernet e configurarla.
Io ho seguito queste istruzioni e tutto è andato liscio, anche se non ho collegato la base alla porta WAN ma ad una delle porte LAN del router.Una volta riavviata la base e collegata al router il gioco è fatto.

Nonostante questa vecchia base Airport non supporti le connessioni Wi-Fi più recenti e veloci, fornisce comunque un segnale 802.11g stabile e  forte abbastanza da permettere lo streaming di video.