OVH on fire

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.


Dell iDrac java patch

Every now and then people ask me which is my favorite server producer, and every time I honestly don’t know how to reply because they all work pretty well.
What really changes between competitors are technical support and some of the small bits that many people consider irrelevant, but Imho they are very important, one of them, maybe the most important, it the lights-out management interface (LOM).
Every server producer has it’s own LOM interface, but my favorite (and one of the reasons why I prefer Dell servers) is the Dell Drac.

One of the most common problems with Dell Drac is the virtual console which requires Java JRE and obviously this makes people angry because… well basically because people are lazy, most of the time leave the brain turned off and don’t read errors and exceptions…

If you search online “dell drac java error” you’ll find a whole bunch of forums, thread, reddit posts, also useless Chrome extentions for make the damn virtual console work, sometimes those sources are crap, sometimes they contain small bits of the solution, which is changing because there are several versions of Drac devices and obviously they evolved during the years.
These errors always came from the java.security settings, Drac encrypt data transmissions, and old Drac cards use old encryption protocols and cypher suites, so I decided to make a simple patchfile for the java.security file for a quick change and rollback (it’s not a good idea to turn on old unsecure protocols for you JRE).

First of all you have to identify your java.security file, which is inside you JAVA_HOME/lib/security, after that apply this java.security patchfile.

After that open you java settings and add the url of your Drac web interface to the “Security > site exception” list.

That’s all, now you’ll be able to open the vitual console even on an old Drac 5 with the latest JRE (tested right now with JRE 1.8.0_261).


Eve Online SOTA part 1

It’s been a while since a wrote something about Eve, and to be honest this is not a State Of The Alliance (SOTA) because… well I’m not an alliance executor and not even a corp CEO, I’m just a regular grunt, as my Twitter bio says I’m just another kender exploring New Eden.

This is not only a post about Eve, in some sense this is a milestone for me because my main character reached the symbolic objective of 100.000.000 skill points; If I sum all the skill points of all my toons I’m reaching about 400.000.000 SP, but you know… the first char is always the most beloved.

Last time I wrote something about Eve I was starting to train one of my biggest and most precious objective, the JF pilot, It was exactly 4 years ago, I reached that goal and despite all the other big objectives (dread and carrier pilots well trainer, two maxed rorqual toons, one almost maxed industrial an reprocessing toon, 6 maxed pi toons, etc etc…) that JF was one of the sweetest and maybe the most precious.

The Italian Alliance I started with died almost 6 months after I joined because of too many elite-pvp players inside, with the core group we joined CO2 back in Tribute, I was part of one of the epic siege of M-OEE8, we fought hard, we lost the first real fought Keepstar citadel and became history.
Then with the entire alliance I moved to Catch and Impass, where we suffered the biggest betrayal in the history of Eve aka “the Judgement Day”.

Thanks to some good friends (and awesome human beings) we moved to Test Alliance Please Ignore in Esoteria, one of the most remote regions of the Eve universe.
We spent almost a year in Test and I have to admit that I loved it, my time in CO2 was great, but the alliance really changed during the years, it became more obsessed on pvp and revenge, almost closed to new players, at some point CO2 became the only alliance without allies and against everyone, and honestly I didn’t like it…
Test was really different, even today I think it’s the most organized alliance I ever seen, awesome wiki, doctrines extremely well documented, very friendly for noobs, everything was great for regular grunts like me, can’t say the same thing for our CEO because Test leadeship seems quite… how can I say… tricky.

After that experience our corp moved into another historic alliance, The Initiative. I always heard about them as smaller but more pvp focused alliance, some kind of elite pvp group inside the Imperium coalition.
At first I was not sure at all and was tempted to leave my corp and stay in Test, but I decided to have faith in our former CEO (I repeat an awsome person) so I jumped into Init.
We started living between Querious (which was the first null region when I started playing Eve) and Fountain, It was tough at first because we lost our habits (we made a lot of huge industrial production in Esoteria) but then I found an equilibrium and things started to work pretty well.

After about six months into the trial alliance Initiative Mercenaries we were promoted as full members of The Initiative, and I have to admit that I was really proud of it, we were parte of one of the most skilled and active groups in the history of Eve.
With Init we made history again, we archived something that everyone in the game considered impossibile, something called the “siege of Rage” which took an entire year of work and preparation and concluded with the destruction of the first Keepstar citadel ever built in the game, we made history, again.

Living in Init is quite different from every other alliance I lived before, in Init I found great fleet commanders, awesome people always helpful and willing to do everything, but it’s a more mature alliance, you must be able to get your stuff, you must be more independent from a logistic point of view, don’t expect the alliance will run for you providing everything you need, you asked to be part of Init, not the opposite.

Now I continue to play, yesterday I lost my first capital into a huge brawl (I used them several times during the years but never lost one) that made almost 1 trillion isk in lost ships, It was awsome.
During the last year I had moments when I really never played, when I thought to leave the game, months spent mainly doing PI, putting skills in the queues and nothing else; it was not an alliance fault, nor my corp fault, it was simply the consequence of huge CCP mistakes, but that’s a different story for a new SOTA rant.



AWS EC2 instance migration

Recently I received some complanings about load problems on an AWS EC2 t2.medium instance with CentOS 7, despite being a development environment it was under heavy load.
I checked logs and monitoring and excluded any kind of attack, after a speech with the dev team it was clear that the load was ok for the applications running (some kind of elasticsearch scheduled bullshit).

The load was 100% from cpu but I noticed some interesting behavior since a couple of weeks with a lot of steal load.

Looking to EC2 CPU Credits it was crystal clear that we ran out of cpu credits, which turned on some heavy throttling.

Since the developers can’t reduce the load from the applications and the management won’t move from EC2, the solution I suggested was to move to a different kind of instance specifically designed for heavy computational workloads and without cpu credits.

So I made some snapshots and launched a new C5 instance, piece of cake, right?
Well no… as soon as I started the new instance it won’t boot, and returned “/dev/centos/root does not exist” on the logs. :\

So what’s going on here?
Pretty simple, there are significant hardware differences between each type of EC2 instance, for example EC2 C type instances have NVMe SSD storage which require a specific kernel module, same for the network interface with ENA module.

The goal here is to make a new init image with these two modules inside, so during the boot the kernel could use these devices, and find a usable volume for boot and nic for network; the only problem is that we can’t simply boot the system using a live distro and build a new init image with those modules already loaded, remember we’re on AWS not on a good old Vmware instance (sigh…).

First of all I terminated the new instance, it was basically useless, and got back to the starting T2 instance.
Check which kernel version you’re using with “uname -a” and build a new init image including nvme and ena modules using mkinitrd, for example:

mkinitrd -v --with=nvme --with=ena -f /boot/initramfs-3.10.0-1062.18.1.el7.x86_64-nvme-ena.img 3.10.0-1062.18.1.el7.x86_64

Using lsinitrd you can check that your new init image has nvme and ena module files inside.

Now you have to edit your grub config file (/boot/grub2/grub.cfg) and change your first menu entry switching from the old init image to the new one.

Save /boot/grub2/grub.cfg file, CHECK AGAIN YOU HAVE A GOOD SNAPSHOT OR AN AMI, and reboot, nothing should have changed.

Now you can make a new snapshot or AMI and build a new instance from it, choose a C type instance and now it should be able to boot properly.

As you can see the new C5 instance have different storage device names, it has a new nic driver (ena) and it has ena and nvme modules loaded.

Life should be easier without the cloud… again.


SPID… grazie ma no grazie

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? :\

« Post precedenti | Post successivi »