I love Bookstack, actually I think it’s one of the best wiki project existing.

It’s well documented, it works like charm, the developer is very active (and he’s also a very kind person, which has nothing to do with the software, but it’s always a pleasure interact with him) and it has very nice features:

• a nice and responsive design
• drafts autosave
• MFA out of the box
• diagrams.net integration

It also works perfectly fine in a docker container, technically the official project do not offer a container image, but there are two groups building them and they’re referred directly in the official documentation.

Recently I started to sort things out on my beloved Raspberry PI 5, in particular I’m moving services so I can reverse proxy them on a single Apache httpd instance (you know I still love Apache :D ), today I moved around Bookstack, in particulare I did two things:

1. change Bookstack hostname (for example from https://site.domain.tld to https://newsite.domain.tld )
2. make Bookstack work under a specific url context (for example https://site.domain.tld/bookstack instead of https://site.domain.tld ).

On my environment I’m using the LinuxServer.io docker image, so check the project site for details, and also I’m using docker compose, if you’re not familiar with it start using it for Reorx’s sake.

Backup

First of all take a damn backup, it’s mandatory.

Seriously I’m not joking.

Stop the containers

cd /data/docker/bookstack ; docker compose down

Backup files with a simple tar, restic, kopia, whatever you want, but DO IT!

cd /data/docker/ ; tar -cpzf /backup/bookstack-backup.tar.gz bookstack

Change Bookstack hostname

This process is documented on the Bookstack documentation (LINK), but still I decided to mention it because the procedure is a little bit different on a docker container, so it’s worth spent a few words about it.

First of all you have to change the APP_URL configuration variable, in case of a docker container it’s enough to change the environment variable on the docker-compose.yaml file, so open the file and change the variable to the new url

Now you must replace the old url from the database record with the new one using the bookstack:update-url command, in case of a docker container you must identify where’s the Laravel framework artisan file and launch it accordingly to the documentation.

docker exec -it bookstack php /app/www/artisan bookstack:update-url https://site.domain.tld https://newsite.domain.tld

After that clear the cache using

docker exec -it bookstack php /app/www/artisan cache:clear

Restart the docker container to change the environment variable you previously changed with the new url.

cd /data/docker/bookstack ; docker compose down ; docker compose up -d

Done, now your Bookstack instance should be reachable to the new url.

Change Bookstack root context

This change is a little bit tricky, because it involves some webserver changes.

First of all you must repeat the same process used for changing the url hostname of your Bookstack instance, this time including the context you want to use (for example /bookstack ).

Let’s quickly review the steps:

1) Change the APP_URL environment variable in the docker-compose.yaml (APP_URL=https://newsite.domain.tld/bookstack in this case)

2) Replace the url in the database using the bookstack:update-url

docker exec -it bookstack php /app/www/artisan bookstack:update-url https://newsite.domain.tld https://newsite.domain.tld/bookstack

3) Clear Bookstack cache

docker exec -it bookstack php /app/www/artisan cache:clear

4) Restart the docker container to change the environment variable you previously changed with the new url.

cd /data/docker/bookstack ; docker compose down ; docker compose up -d

Now you must review the webserver configuration inside your docker container, in case of the LinuxServer.io container there’s a nginx instance running inside the container, you can fine its configuration inside the /config/nginx/ directory inside the container.

If you followed the LinuxServer.io recommendations the /config directory should be a persistent volume (or a persistent path on your docker host), so any changes in the nginx configuration files should not be lost in case of a container restart.

In my case the config persistent volume is located in the /data/docker/bookstack/bookstack-config directory, so the nginx configuration is located in the file /data/docker/bookstack/bookstack-config/nginx/site-confs/default.conf.

Apply this patch

wget https://tasslehoff.burrfoot.it/pub/bookstack-nginx.patch ; \
patch /data/docker/bookstack/bookstack-config/nginx/site-confs/default.conf < bookstack-nginx.patch

Reload nginx configuration

docker exec -it bookstack nginx -s reload

Done, now your Bookstack instance should work at the new url https://newsite.domain.tld/bookstack

As you may heard on march 10th a large fire destroyed part of a big datacenter in Strasbourg owned by OVH (maybe the biggest european service provider), and yes, this blog burned with it.

After the accident there was a huge discussion on the web, flames (sigh…) on Twitter and Reddit about this crazy provider which doesn’t have a disaster recovery plan or some sort of automagic backup, so people get stucked with no options other than start their site/service from scratch…

Some of you may think I’m mad about it and I would run away from this provider… well I’m not and I’ll remain with OVH.

The reasons are very simple, first of all as you can see the blog is back (maybe better than before, things like this always makes you think how can you improve stuff, or at least this is how they work for me) because (surprise surprise!) I had a backup every 6 hours on another location (thanks restic).
The second reason why I decided to stay with OVH is that their vps offer is perfect for my needs, it costs like a shared hosting service and runs so much better, and obviously I can do whatever I want with my private vps, instead of get stucked with only a wordpress hosting service.

And no, I’m not mad with OVH, because even without reading carefully the contract I signed, I knew from the beginning that I had to take care of backups, even if they were included in the service (and they’re not in my case).
Why? Because I want backup made on my way, so I can control them, I can check them, I can figure out the best recovery plan for me.

I understand those who were complaining about backups made in the same location where the burning happened, they payed for a service and it has a flaw (a big one, don’t get me wrong).
But from my perspective there was a bigger flaw, and it was their thinking “ok I paid someone to take care of the backup, job’s done”.
No… no…. NOOOOO!
If you own a service you have the responsibility to take care of the backup, to understand it, to figure out the recovery plan, and to test it; if their backups burned with servers it’s because they missed one, many or all those points.

That’s it, for me the case is closed.

Negli ultimi anni (in particolare in questo 2019 che si sta concludendo) uno dei temi su cui la PA ha più martellato è SPID, il cosidetto Sistema Pubblico di Identità Digitale promosso dal Mise insieme con Agid e il celebre team per la trasformazione digitale del governo.

In questo post vorrei esporre i motivi per cui a mio modestissimo parere non solo SPID è una colossale regressione rispetto al precedente sistema di autenticazione “strong”, ma anche perchè è PERICOLOSO per i soggetti interessati, aziende e soprattutto privati cittadini.

Cominciamo col definire cos’è appunto SPID, trattasi di un sistema di autenticazione strong, ovvero che permette di certificare che il soggetto che si registra è stato verificato da un altro soggetto considerato affidabile (che da ora in poi chiameremo identity provider o idp, in questa sede prenderemo in esame i tre principali, Aruba, TIM e Poste, gli altri si comportano in modo del tutto identico).
Già qui cominciano i distinguo, ovvero effettuare la login tramite SPID non certifica che il soggetto che si sta autenticando sia il soggetto titolare delle credenziali SPID, nulla vieta al soggetto Pippo di consegnare le credenziali SPID al soggetto Pluto, e costui non avrà alcun problema ad autenticarsi come se fosse Pippo.
Si obbietterà che questo vale per qualsiasi altro sistema di autenticazione remota, ed è assolutamente vero a meno che non siano previsti fattori biometrici, ma è sempre bene ricordarlo.

In secondo luogo chiariamo un dettaglio che può sembrare lessicale ma è SOSTANZIALE e che riprenderemo successivamente, l’acronimo SPID viene pubblicizzato come Sistema Pubblico di Identità Digitale, niente di più falso, semmai sarebbe il caso di ribattezzarlo Sistema PRIVATO di Identità Digitale in quanto di pubblico in SPID non c’è proprio nulla.
Già perchè ogni volta che vi loggate ad un servizio pubblico con SPID, in realtà effettuate una login presso un servizio PRIVATO, di una società PRIVATA, perchè tali sono gli identity providers, non ci credete? Controllate voi stessi direttamente sul sito Agid.

Già signore e signori, non esiste un idp pubblico, non è mai esistito dal lancio del servizio e non ci sono informazioni che facciano pensare al lancio di un idp pubblico (non mancherebbero di certo le risorse alla PA per istituirne almeno uno…), quindi semmai non ve ne foste resi conto le vostre credenziali SPID non stanno affatto sul sito del vostro comune, regione, provincia, INPS o Agenzia delle Entrate, ma risiedono fisicamente nelle banche dati di queste società private, e indovinate un po’… quei dati danno accesso a TUTTI I VOSTRI DATI PIU’ SENSIBILI E PIU’ PERSONALI: fascicolo sanitario con tutta la vostra storia clinica, fascicolo previdenziale, dichiarazioni dei redditi, multe, pagamenti, rette scolastiche e chi più ne ha più ne metta, tutto in mano a un unico soggetto che ha (giustamente) l’obbiettivo di fare utili, non certo di fornire un servizio pubblico.

Qualcuno obbietterà che SPID prevede una autenticazione di secondo livello, ovvero quella che si definisce 2FA (autenticazione multifattore), ovvero un ulteriore dato oltre alle classiche username e password per autenticarsi; questo è vero, è previsto ed è fornito tramite app mobile (es Aruba e Poste) o SMS (es TIM).
Pensateci un attimo però, chi fornisce i fattori di autenticazione di secondo livello (2FA), nel caso di Aruba è una app sviluppata da Aruba stessa, idem per Poste, nel caso di TIM il mittente dell’SMS è TIM stessa; ovvero il soggetto che detiene i primi due fattori di autenticazione (username e password) è lo stesso che fornisce il terzo fattore di autenticazione, non proprio una best practice in termini di sicurezza e riservatezza dei dati, non trovate?

Alquanto curiosa come soluzione considerando che esistono degli standard specifici per i dispositivi per l’autenticazione multifattore, ed esiste una discreta quantità di dispositivi software e hardware che le implementano (Google Authenticator, Microsoft Authenticator, Authy, FreeOTP, tanto per citare alcune delle più celebri); usare queste non avrebbe comportato alcun costo e avrebbe permesso di scorporare i fattori di autenticazione riducendo drasticamente la criticità rappresentata dagli idp.

Si può obbiettare che gli idp sono soggetti selezionati e che danno garanzie ben precise in termini di professionalità, onorabilità e sicurezza.
Ebbene, ricordiamoci che il pericolo può provenire dall’interno di queste organizzazioni, ma soprattutto dall’esterno, un data breach su questi dati e una manomissione dei meccanismi di autenticazione multifattore avrebbero conseguenze CATASTROFICHE, sia quantitativamente(si stanno concentrando questi dati ipercritici in pochissimi soggetti) e qualitativamente (come dicevo poco sopra, accesso ai dati più sensibili e personali che esistano).

Quali garanzie forniscono Agid e idp? Un pezzo di carta, e mi si lasci aggiungere, che vale meno della carta su cui è scritto.
Già perchè di fatto l’unica garanzia fornita all’utente è puramente formale, una convenzione stipulata tra idp e Agid (qui un esempio) che non varrà assolutamente nulla in termini pratici una volta che il danno sarà stato fatto (le informazioni trafugate non torneranno magicamente indietro con qualche risarcimento).

Passiamo ora ad un aspetto sicuramente meno importante, SPID in fin dei conti è gratis, a caval donato non si guarda in bocca, giusto?
Beh sì… ni… no.
La creazione di un account SPID viene pubblicizzata come gratuita, in realtà è in promozione gratuita a certe condizioni, ovvero solo per privati e solo se ci si identifica con un altro meccanismo di autenticazione strong (es CRS/CNS), in caso contrario in alcuni casi occorre recarsi fisicamente presso uno sportello dell’idp (es Poste o TIM) oppure identificarsi tramite webcam ad un costo che varia mediamente tra le 14 e le 20 €,
Sia chiaro che se si vogliono attivare ulteriori meccanismi di autenticazione (es livello 2 con token fisico o livello 3) occorre sborsare altra pecunia.

Qualcuno obbietterà che quella spesa (soldi o tempo perso allo sportello) è ben poca cosa rispetto ai vantaggi di SPID.
E se vi dicessi che in realtà tutto questo esisteva già da tempo (2007, forse prima) grazie alla Carta Regionale dei Servizi e Carta Nazionale dei Servizi?
E se vi dicessi che CRS/CNS:

• sono erogate esclusivamente da soggetti pubblici
• prevedono meccanismi di autenticazione materialmente diversi (certificato nella smartcard fisica e PIN)
• prevedono il possesso da parte dell’utente di entrambi i meccanismi di autenticazione (il PIN può essere modificato a piacimento da parte dell’utente)
• sono gratuite

L’unica criticità storica di CRS/CNS è legata al dispositivo materiale (smartcard) che richiede un lettore dedicato e del relativo software, criticità vere con le quali mi sono scontrato io stesso, ma facilmente risolvibili cambiando il formato del dispositivo (da smartcard a pendrive usb? Magari micro o type-C e comunque compatibile con smartphone?) o con un miglior supporto software, tutte cose che avrebbero un costo irrisorio rispetto alla montagna di soldi spesi con SPID per rifare (MALE) qualcosa che già esisteva e funzionava (BENE).

Last but not least faccio presente che tutti i principali servizi pubblici, zitti zitti stanno gradualmente bandendo ogni meccanismo di autenticazione strong differente da SPID, resiste ancora qualche baluardo con CNS/CRS ma le amministrazioni stanno facendo di tutto per nasconderlo agli utenti e prevedono di eliminarlo a breve (es Comune di Roma): RESISTANCE IS FUTILE!

Lasciatemi concludere questa piccola rassegna degli orrori di SPID con un simpatico scambio che ho avuto su Twitter con Team Digitale, alla mia richiesta di chiarimento sulle criticità relative a sicurezza, riservatezza dei dati, fattori di autenticazione etc etc mi è stato risposto che: SPID è sicuro perchè gli identity providers verificano tramite webcam la registrazione degli utenti, non vi sentite più sicuri ora? :\

I don’t know what do you think about containers and orchestration tools, but for me it’s been a while since I started discussing on those topics on forum and various platforms, and I can’t say It’s an easy discussion.
To be honest I’m quite tired of repeating the same concepts so I thought this blog could be help me to express my point of view, at least in future I only have to copy and paste this post url and not waste time anymore :)

For someone my point of view on containers and microservices could sound a bit grumpy, but I can assure that I’m not against them, or think they are bad or simply some nasty trend.

First of all It’s imperative to distinguish between two main scenarios: development/test and production environment.

For the first one containers are wonderful, they are the Nirvana and Shangri-La all together, they give developers the opportunity to setup dev environment in no time, no setups, no hard requirements, everything is perfectly consistent and works in the same way as the tools they are familiar with (think about git or other versioning softwares), everything is perfectly reproducible on whatever platform, their work pc, home pc, a server, a laptor, everything.

For production… well It’s not the same.
First of all: the most important requirement for a production environment is reliability, then comes security, then everything else.
Literature, research, experience and logic taught us that these two basic requirements could be reached only following the KISS principle (Keep It Simple Stupid) which is not a joke, It’s real, It’s true and It works, period.
Second, when your application moves from development to production It moves from developers to sysadmins, It’s the sysadmin the guy which must maintain It, that must provide resources and guarantee that the application (and all its requirements) are working, are reliable and kept secure.
Third: if you think about the lifecycle of an application most of It is in production, an application could require a few months of development but will remain online for years, and usually the more It will require for the development the more It will remain in production.

Following the KISS principle means REDUCE COMPLEXITY, containers ADD COMPLEXITY :\
This may sound strange to containers users because “well it’s a piace of cake, launch a couple of commands and you’re ready to go”, well stop for a moment and think about it.

• On a “legacy” environment you have, applications (your site, your database, etc etc) on top of services (webservers, application servers, rdbms, etc etc shared by several applications) on top of an OS (shared by several services) on top of some sort of hardware (which could be very complex in production, and could be shared between several OSs if you’re using virtual machines).
• With containers and orchestrators (like Kubernetes or Openshift) you have a LOT more complexity, you still have your applications, on top of services (which are the same as before for instance…), on top of containers, on top of a container environment (for example Docker), on top of orchestrators, on top of a OS (usually installed on a vm, so add also the hypervisor complexity) on top of hardware.

More complexity means less reliability and less security, or a least a lot more work and variables to manage to reach the same level of those requirements.

Like everything there are pros and cons, and someone could argue that beside that added complexity containers and orchestrators give you a lot of benefits, mainly:

1. reproducibility
2. horizontal scalability (adding more “nodes” and distribute load across them).

We already talked about the first before, It’s awsome for a developer, but for a sysadmin on a production environment?
Well, not really, simply we don’t need it because move an application between different environments is really rare (in 20+ years of IT consultant work It happened to me only one time, moving and Oracle 10g rdbms from Windows Server 2003 to RHEL) and usually any service have its own backup and restore procedures to accomplish this goal.

Scalability is another story, in theory it’s an awsome thing, in real world it’s not a big deal in 99% of companies or services.
The idea of having some black magic that will add more and more instances of your application and distribute the load on those is good and managers love it, they simply think this is the solution for every problem because, let’s be honest, they don’t understand the complexity behind an application and they think that all the problems come from lack of resources.

In the real world any experienced sysadmin can confirm that usually resources are enough and when an application have problems it’s all about some bug, exception, unmanaged situations (for example the application use a third party service which doesn’t work and the application does not manage it), all those things can lead to a slow or unresponsive application even if you have a lot of resources available.
Adding more and more application instances and balance load across them will lead to a simple result: more and more exceptions.

Ok, let’s ride our fantasy horse and think about a bug free application, can we scale up with containers with no worries?
Sure you can, but do you really need it?
For 99% of companies nowadays it’s really rare that an application don’t have enough resources, or have such a huge amount of requests to run out of resources.
If you are Google, Facebook, Netflix, Amazon or any other global huge company maybe you really need horizontal scalability, so orchestrators and containers are very useful (it’s not surprising that one of the most popular orchestrators, Kubernetes, came from Google), otherwise… well no, you don’t need it.

So that’s all?
No, there are a lot of smaller pros and cons (most cons to be honest imho…) on this topic, like security, access on third party resources, logging, service redundancy vs consolidation and many more.
Most of these are huge problems with containers (and most of the times they are ignored) while with a traditional architecture they simply aren’t, even a simple stdout append on a log is a pain in the ass with containers, and require to add a lot of complexity to reach this simple goal (remember KISS principle).

Let me add a small personal thought on this subject that can be extended in many other areas of the IT universe.
As you probably understood I think that containers are a really good tool for developers and not a good one for sysadmins, containers are born from developers for developers.
Why people always think that a development tool should work for production?
Why people don’t think from a production perspective when they develope tools for production?

If you are a developer and you’re working on a tool that will be used in production, please ask your sysadmin what does he think about it, what’s its requirements, what are the problems that he usually have in production and he need to fix.
Maybe if we start to develope tools from the right perspective we’ll have better results, otherwise we will continue to have always the same problems.

[EDIT 23/04/2021]
Let me just add a little contribute from John Carmack, one of the greatest developers of all times, the father of DooM and Quake, and in general of modern FPS videogames.

Dopo tanto tempo ho deciso di scrivere uno post in italiano sperando che possa agevolarne la diffusione tra gli utenti del nostro Paese che si accingono ad aderire alle varie offerte di connettività propinate dai diversi operatori tlc.

Nel mio caso si tratta di Wind, operatore con il quale ho iniziato ad avere rapporti nel 2007 dopo una iniziale esperienza con NGI.
A onor del vero devo confessare di non aver mai avuto problemi catastrofici, la mia vecchia linea ADSL (seppur limitata a 4Mbps in downstream) si è sempre dimostrata stabile, affidabile e con una latenza decisamente superiore alla media.
A parte il feedback tecnico (variabile da zona a zona a causa dell’infrastruttura spesso in stato di abbandono) quello che mi ha favorevolmente impressionato è la flessibilità di Wind nell’applicare profili di connettività differenti da quelli proposti come standard, nel mio caso alzando la banda di upstream da 128Kbps a 512Kbps.

Poco meno di un anno fa scopro di avere copertura FTTC, viste la tariffe vantaggiose e il buon rapporto maturato decido di rimanere con questo operatore, tutto perfetto fino allo scorso agosto, quando noto un sensibile rallentamento nel downstream e un drastico aumento nella latenza.
Provo a lanciare qualche test con Speedtest.net utilizzando il server per me più affidabile (Fastweb Milano) e ottengo un ping aumentato da 5/6 a 25 ms e una banda in downstream diminuita da 60/70Mbps a 15/20Mbps.

Ripeto il test ogni giorno e ottengo lo stesso risultato, schedulo un test ogni 15 minuti utilizzando l’ottimo speedtest-cli da cui emerge un evidente problema di saturazione nelle ore serali, con qualche anticipo pomeridiano nel week end,  questo è il risultato, giudicate voi.