Qualche giorno fa uno dei computer dell’ufficio non si è acceso per bene: è partito grub2 e ha dato l’errore grub_file_filters not found.
Internet è decisamente prolifica nel trovare situazioni analoghe, ma per lo più si tratta di narrazioni di troubleshooting, senza indicare esattamente quali siano il problema e la soluzione.

E allora diciamolo chiamaramente: il problema è che la versione di grub scritta nell’MBR, cioè dentro il disco, non corrisponde a quella dei moduli presenti in /boot/grub. Questo può succedere per vari motivi: nel mio caso avevo installato grub sull’MBR di tutti i dischi del server (per poter fare il boot anche in caso di guasto di un disco), ma non avevo configurato correttamente questa cosa in debconf, sicché dopo gli aggiornamenti di grub, solo l’MBR del disco principale era stato aggiornato, lasciando gli altri MBR con la vecchia versione di grub. Questo era successo perché il sistema era stato installato con un solo disco e poi ampliato con gli altri. Appena si è rotto il disco principale, il BIOS ha letto grub dal secondo disco, grub ha caricato i moduli dalla directory /boot/grub che era su un RAID, ma la versione non combaciava.

La soluzione è quella di avere sempre grub allineato: ogni volta che si aggiorna il pacchetto si deve riscrivere grub su tutti i dischi dove è stato installato. Per farlo si può semplicemente riconfigurare grub con il comando

dpkg-reconfigure grub-pc

La documentazione di barman non è sempre semplice da consultare, quindi aggioungo qui alcune note relative al comando di ripristino.

Creazione del file system per il ripristino, su macchina nomehost, aggiornato con tutti i WAL: barman recover --remote-ssh-command 'ssh postgres@nomehost' nome-master backup-id /path/destinazione/su/nomehost

Creazione del file system per il ripristino, su macchina nomehost, che verrà aggiornato con tutti i WAL scaricati all’avvio di postgres. Il comando per scaricare i WAL dal server barman è nel file recovery.conf: barman recover --remote-ssh-command 'ssh postgres@nomehost' --get-wal nome-master backup-id /path/destinazione/su/nomehost

Creazione del file system per il ripristino, su macchina nomehost, che verrà configurato come standby (che rimarrà sempre in recovery, attendendo sempre nuovi WAL). Il comando per la configurazione è nel file recovery.conf: barman recover --remote-ssh-command 'ssh postgres@nomehost' --standby-mode nome-master backup-id /path/destinazione/su/nomehost

Creazione del file system per il ripristino, su macchina nomehost, che verrà configurato come standby e messo in attesa per potervvi accedere. Il comando per la configurazione è nel file configurato come standby. Il comando per la configurazione è nel file recovery.conf: barman recover --remote-ssh-command 'ssh postgres@nomehost' --standby-mode --target-action pause nome-master backup-id /path/destinazione/su/nomehost

Creazione del file system per il ripristino, su macchina nomehost, aggiornato con tutti i WAL fino a data e orario specifico. La directory barman_wal conterrà i WAL necessari, il file recovery.conf i comandi necessari per il PITR: barman recover --remote-ssh-command 'ssh postgres@nomehost' --target-time '2022-06-15 16:58' nome-master backup-id /path/destinazione/su/nomehost

Per fare poi ripartire il database in modalità standby, nel caso che la versione di postgresql sia 12 o superiore, il file recovery.conf non viene usato e, anzi, blocca l’avvio di postgresql. I comandi vanni presi da quel file e integrati nel file postgresql.conf principale (dettagli qui).

Altra cosa importante: per fare ripartire postgresql (12 o superiore) in modalità recovery deve esistere il file chiamato standby.signal. In caso negativo, il cluster non partirà in maniera recovery, ma si aprirà normalmente alle connessioni in lettura e scrittura.

Queste sono note veloci da sistemare, ma possono già aiutare eventualmente altri, quindi le pubblico qui. Per semplicità la password dei keystore e delle chiavi è sempre la stessa, ma in alcuni casi deve essere veramente la stessa, ad esempio quando si deve usare il keystore generato in un connettore di Apache Tomcat.

Le cose importanti da notare sono: il certificato della CA deve avere il BasicConstraint che indica che è una CA. Non si tratta di un vincolo tecnico, ma i browser potrebbero poi non accettarlo come affidabile. Il certificato del server deve avere il KeyUsage corretto, altrimenti anche lui potrebbe essere scartato. Il comando per la generazione del certificato iniziale del server avrà quindi varie -ext .... per aggiungere le estensioni, che dovranno essere ricopiate identiche nel punto dell’emissione del certificato per il server da parte della CA.

• Creazione di chiave privata e certificato radice per l’autorità, valido 7350 giorni (circa 20 anni). Questo viene messo nel keystore predefinito di java, nella home dell’utente, in un file chiamato .keystore e protetto da una password relativamente semplice. Il comando è: keytool -alias root -dname "CN=RootCA, OU=La mia unità organizzativa, O=La mia società, L=La mia località, ST=La mia provincia, C=IT" -genkeypair -storetype PKCS12 -storepass fs35623_WE -keypass fs35623_WE -keyalg RSA -keysize 4096 -validity 7350 -ext BasicConstraints=ca:true,PathLen:2 -ext KeyUsage=digitalSignature,keyEncipherment,keyCertSign -ext ExtendedKeyUsage=serverAuth,clientAuth
• Creazione di chiave privata e certificato radice per il server, valido 7350 giorni (circa 20 anni). Questo viene messo nel keystore chiamato server.pfx e protetto da una password relativamente semplice. Il comando è: keytool -alias server -dname "cn=server.example.com, OU=La mia unità organizzativa, O=La mia società, L=La mia località, ST=La mia provincia, C=IT" -genkeypair -storetype PKCS12 -storepass fs35623_WE -keystore server.pfx -keypass fs35623_WE -keyalg RSA -keysize 4096 -validity 7300 -ext SAN=DNS:server.example.com -ext ExtendedKeyUsage=serverAuth -ext KeyUsage=digitalSignature,keyEncipherment
• Copia temporanea del certificato della CA dal keystore predefinito di java a quello nel quale c’è il certificato del server. Il comando è: keytool -export -alias root -storetype PKCS12 -storepass fs35623_WE | keytool -import -alias root -storetype PKCS12 -keystore server.pfx -storepass fs35623_WE -noprompt -trustcacerts
• Generazione della richiesta di firma del serve del certificato, che viene poi passata al comando per l’emissione del certificato da parte della CA, che viene poi passato al keystore origiario per essere memorizzato. Il comando è: keytool -alias server -certreq -storetype PKCS12 -storepass fs35623_WE -keyalg RSA -keystore server.pfx | keytool -alias root -gencert -storetype PKCS12 -storepass fs35623_WE -keyalg RSA -ext SAN=DNS:server.example.com -ext ExtendedKeyUsage=serverAuth -ext KeyUsage=digitalSignature,keyEncipherment -validity 7300 | keytool -alias server -importcert -storetype PKCS12 -storepass fs35623_WE -keyalg RSA -keystore server.pfx -noprompt -trustcacerts
• Rimozione del certificato della CA dal keystore del server. Il comando è: keytool -delete -alias root -storetype PKCS12 -keystore server.pfx -storepass fs35623_WE
• Esportazione del certificato della CA in un file, da importare nei sistemi che dovranno considerarlo affidabile. Il comando è: keytool -export -alias root -storetype PKCS12 -storepass fs35623_WE -rfc > root.pem