La trappola

Ci siamo capitati quasi tutti.
“Se è gratis, il prodotto sei tu”, dice quello che ormai è divenuto un adagio, e ormai ne siamo tutti consapervoli: app, software e servizi gratuiti non sono certo beneficenza nei nostri confronti: Google e Facebook sicuramente non sono diventati colossi economici di livello mondiale facendo i buoni samaritani.
Eppure usiamo continuamente “quel servizio”, giochiamo a “quel giochino”, non facciamo più a meno di quella “app comodissima”, che anche se è gratis ha più di quanto ci serva.
Concediamo nostri dati personali? Non abbiamo nulla da nascondere – e poi a chi vuoi che davvero interessi quale cibo preferisco o chi frequento nel mio tempo libero?

Arriva poi un momento in cui la casella di posta elettronica smette di funzionare per un’intera giornata, oppure il servizio X smette di funzionare.

Calma, c’è il supporto tecnico, facilmente contattabile in un paio di click via chat (ma parlerai con un bot) oppure via mail, dove la prima risposta che riceverai sarà quella di un risponditore automatico:

Hello,


This is an automated message acknowledging your recent submission for help to XxXXXXX Care.
 
Please don't reply to this email, as this email address is used for outgoing mail only.
 
• If you reported abuse, we will investigate and take action where appropriate, and may be contacted if additional information is required to complete our investigation. We appreciate your efforts to make our community better.
 
• If you are submitting a request for assistance, or asking a question, a representative will respond as soon as possible.
 
Your Case Number is:xxxxxxxxxx

OK, fin qui ok.

Il giorno dopo arriva un sondaggio sul grado di soddisfazione del servizio clienti (avessi mai parlato con uno straccio di essere umano o fosse stato fatto un minuscolo intervento per risolvere il mio problema, ma nel frattempo sembra che stiano lavorando per me:

Hello,
Thank you for contacting XxXXXXX. We are very sorry for the trouble you are having. 
We'll get this over to our engineering team so they can get this fixed as soon as possible for you.
We apologize for the inconvenience and appreciate your patience in this matter. 
Have a good day and pleasant playing! Thank you for choosing XxXXXXX!
Thanks,

Silenzio.

Passano 10 giorni, risollecito: la risposta è tanto rapida quando disarmante:

Hi Enrico,

Thanks for getting back to us.
 I'm sorry, but it's taking longer than we expected to fix this. Rest assured, we’re focused on getting this corrected for you.
There are several factors that go into resolving this type of issue including diagnosing, troubleshooting, and implementing the fix. As such, we're unable to provide an estimated time for when this issue will be resolved.
We appreciate your continued patience while we work to get this fixed as quickly as possible.

Regards,

Poi in effetti ragiono: a che pro impegnare risorse per il supporto tecnico di un prodotto gratuito?
Non pago nulla, quindi perdere un cliente non comporta un immediato mancato introito e la società ha ormai una marea di miei dati a sua disposizione che potrà usare ormai indipendentemente dal mio grado di soddisfazione.
In ultimo, ho usato il servizio (e spesso anche molti altri della stessa società) per tempo sufficiente a rendermi dipendente da una sorta ecosistema e a rendere un eventuale abbandono molto dispendioso in termini di fatica, tempo e conservazione dei dati.

Risultato: niente servizio e tanta pazienza.

Gratis non è sempre bello.

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.

Passano gli anni, arrivano le pandemie, ma Windows…

In piena ansia da pandemia, continuiamo a ripeterci che niente sarà più come prima.
Invece qualcosa – dalle nostre prime avventure informatiche ad oggi – non ci ha abbandonato: il blue screen of death, la fatidica schermata blu che ogni utente Windows conosce.
Grazie per questa certezza in momenti così difficili.

Ricordiamo tutti i crash improvvisi quando semplicemente collegavamo un mouse USB a caldo o stavamo facendo la più banale delle operazioni.

Avremo perso dati, lavori importanti e ore del nostro tempo, ma non la sicurezza che Windows sarebbe sempre stato lì a regalarci il brivido dell’imprevisto, dal 1985 ad oggi, anche su Windows 10.

Libreoffice e MacOS Catalina: gioie con qualche dolore

L’introduzione di MacOS Catalina non è stata indolore per molti utenti: il definitivo abbandono delle applicazioni 32-bit ha costretto molti ad un po’ di lavoro extra, mentre alcune funzioni di sicurezza del nuovo sistema operativo Apple a volte creano qualche problema, soprattutto con le applicazioni provenienti da sviluppatori non certificati.

Questa ridda di cambiamenti nella piattaforma possono essere la causa di qualche bug, come nel caso di Libreoffice.
Una nuova installazione della versione 7.0 su un Macbook appena inizializzato aveva problemi nel salvataggio dei file: cliccando sull’icona di salvataggio il sistema sembrava andare in blocco per qualche secondo per poi tornare reattivo ma senza aver effettuato il salvataggio nè tantomeno aver fornito un messaggio di errore esplicativo.

Cercando in rete mi sono imbattuto nella segnalazione di questo bug, probabilmente dovuto all’installazione del language pack.

Seguendo le istruzioni, è bastato spostarsi nella cartella Applicazioni del mio Mac

$ cd /Applications

e digitare il comando:

$ codesign -vvv --deep --strict LibreOffice.app