Ho pensato di analizzare i log di Mirth e rappresentarli con una applicazione Kibana per poter avere una visione d’insieme del funzionamento dei canali.In questo articolo, esploreremo la soluzione a un problema riscontrato durante l’elaborazione …
TLDR – buildare una immagine docker può richiedere parecchio tempo e può risultare pesante dal punto di vista del volume occupato. Il post contiene lcuni suggerimenti su come fare prima e aumentare a compattezza.
Ho trovato un metodo per personalizzare l’elenco dei bookmark in Nautilus, consentendo di organizzare i segnalibri per qualsivolgia criterio. L’elenco dei segnalibri che mi presentava Nautilus era divenuto pian piano molto confuso e trovare i …
TLP è un sistema per Linux che aiuta a prolungare la durata della tua batteria. Utilizzando TLP, potrai ottimizzare le impostazioni del sistema per ridurre il consumo energetico e massimizzare l’efficienza energetica. Con TLP, potrai …
Nel mio ultimo computer ho voluto tenere un dual boot con GRUB essendo obbligato in alcune situazioni ad utilizzare una macchina Windows genuina per connettermi ad alcune VPN. Stamattina, eseguendo gli aggiornamenti del sistema operativo …
Ho pensato di analizzare i log di Mirth e rappresentarli con una applicazione Kibana per poter avere una visione d’insieme del funzionamento dei canali. In questo articolo, esploreremo la soluzione a un problema riscontrato durante l’elaborazione dei log di Mirth usando Filebeat per la’anlidi dei log e l’invio a Elasticsearch, evidenziando le cause dei fallimenti e le azioni risolutive adottate.
Lo stack Elastic: Filebeat – Elasticsearch – Kibana
Kibana, Filebeat ed Elasticsearch sono componenti chiave all’interno dello stack Elastic, e ognuno di essi svolge un ruolo cruciale nel ciclo di gestione e visualizzazione dei log.
Filebeat: È il primo elemento della catena e si occupa della raccolta dei log da varie fonti (file di log, syslog, ecc.). Filebeat legge i log e li invia a Elasticsearch per l’indicizzazione, seguendo specifiche configurazioni e pipeline di elaborazione (tokenizer, dissect, ecc.). Nel nostro caso, Filebeat è stato configurato per raccogliere i log di Mirth, applicare un tokenizer, e inviare i dati elaborati a Elasticsearch.
Elasticsearch: Una volta che Filebeat invia i log, Elasticsearch li indicizza, rendendoli ricercabili e pronti per essere visualizzati. Elasticsearch archivia i dati e fornisce capacità di ricerca e analisi avanzate. Ogni documento inviato da Filebeat viene elaborato attraverso pipeline di indicizzazione per aggiungere campi e strutturare i dati in modo ottimale per le query successive.
Kibana: È l’interfaccia visiva per esplorare i dati indicizzati in Elasticsearch. Con Kibana, è possibile creare dashboard, eseguire ricerche avanzate, analizzare i log in tempo reale e visualizzare metriche. Nel nostro caso, abbiamo utilizzato Kibana per verificare se i campi tokenizzati da Filebeat (come logtime e loglevel) venivano indicizzati correttamente e per monitorare i risultati della pipeline di Filebeat.
La relazione tra questi componenti è stretta: Filebeat raccoglie ed elabora i dati, Elasticsearch li indicizza e li rende disponibili per la ricerca, e Kibana fornisce gli strumenti per visualizzarli e analizzarli. Quando uno dei componenti non funziona correttamente, come nel nostro caso con Filebeat, l’intero flusso di dati ne risente, e il troubleshooting può diventare complesso. Tuttavia, una volta che il flusso è ripristinato, l’integrazione tra questi strumenti offre una piattaforma potente e scalabile per la gestione e l’analisi dei log.
Risolvere l’Errore “Failed to Access State” in Filebeat
Recentemente, abbiamo affrontato un problema critico con Filebeat che non riusciva a partire, ripetendo continuamente un errore legato all’accesso al file di stato meta.json.
# journalctl -u filebeat -b
ott 03 17:08:00 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:01 poleni systemd[1]: filebeat.service: Scheduled restart job, restart counter is at 1.
ott 03 17:08:01 poleni systemd[1]: Stopped Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:01 poleni systemd[1]: Started Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:01 poleni filebeat[33176]: Exiting: Failed to access state when attempting take over: failed to open store 'filebeat': open /var/lib/filebeat/registry/filebeat/meta.json: no such file or directory
.....
ott 03 17:08:01 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Scheduled restart job, restart counter is at 5.
ott 03 17:08:02 poleni systemd[1]: Stopped Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Start request repeated too quickly.
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:02 poleni systemd[1]: Failed to start Filebeat sends log files to Logstash or directly to Elasticsearch..
Anche arrestando il servizio, lo stato continuava a rimanere “failed” invece di passare a “dead“, complicando la risoluzione del problema:
root@poleni:/etc/filebeat# systemctl stop filebeat
root@poleni:/etc/filebeat# systemctl status filebeat
× filebeat.service - Filebeat sends log files to Logstash or directly to Elasticsearch.
Loaded: loaded (/lib/systemd/system/filebeat.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2024-10-03 17:02:03 CEST; 5min ago
Docs: https://www.elastic.co/beats/filebeat
Main PID: 31207 (code=exited, status=1/FAILURE)
CPU: 104ms
Sintomi
Ogni volta che si tentava di avviare Filebeat, nel log appariva il seguente messaggio:
Exiting: Failed to access state when attempting take over: failed to open store 'filebeat': open /var/lib/filebeat/registry/filebeat/meta.json: no such file or directory
Questo errore si ripeteva rapidamente fino a raggiungere il limite di tentativi, facendo fallire il servizio dopo cinque ripartenze consecutive.
Diagnosi e Risoluzione
File di Stato Corrotto: Il problema principale risiedeva nel file di stato /var/lib/filebeat/registry/filebeat/meta.json, che risultava corrotto o mancante. Anche arrestando il servizio, lo stato non passava a “dead” come ci si aspettava.
Eliminare il File di Stato: La svolta è arrivata quando abbiamo eliminato completamente la directory del registro di stato con il comando:
sudo rm -rf /var/lib/filebeat/registry/filebeat
Questo ha forzato Filebeat a ricreare il file di stato da zero, rimuovendo ogni traccia di configurazioni o stati corrotti.
Riavvio del Servizio: Una volta eliminata la directory di stato, abbiamo riavviato correttamente il servizio:
sudo systemctl start filebeat
Verifica del Funzionamento: Dopo il riavvio, Filebeat ha creato correttamente un nuovo file meta.json, e il servizio ha iniziato a funzionare normalmente senza più ripetere l’errore.
Lezioni Apprese
Stati Persistenti: Filebeat utilizza lo stato per tenere traccia dei file e delle loro posizioni, ma se lo stato diventa corrotto, può impedire il corretto avvio del servizio.
Controllare lo Stato del Servizio: Anche quando si arresta il servizio, è fondamentale verificare che lo stato sia passato correttamente a “dead” e non rimanga bloccato in “failed”. In questo caso, l’errore ripetuto era dovuto al tentativo automatico di Filebeat di riavviarsi.
Ripulire Manualmente lo Stato: Quando Filebeat non si avvia e continua a fallire ripetutamente, eliminare lo stato può essere una soluzione rapida e efficace.
Ho fatto una sintesi delle strategie per ottimizzare una immagine Docker. Di seguito trovate le considerazioni per rendere più efficiente la costruzione delle immagini.
Come ridurre la dimensione delle immagini Docker e migliorare i tempi di build
Ottimizzare una immagine Docker è essenziale per ridurre i tempi di build, migliorare l’efficienza e risparmiare spazio su disco. Le immagini più piccole sono più rapide da scaricare e distribuire, facilitando il deployment nei vari ambienti. In questo articolo ti spiegherò alcune strategie efficaci per ottenere immagini Docker più leggere e migliorare le performance di build.
1. Eliminare la documentazione dei software
Nei container Docker, la documentazione (come manuali o pagine man) raramente è necessaria. Se hai bisogno di consultare la documentazione, puoi farlo direttamente online, quindi non ha senso mantenerla all’interno delle immagini. Rimuovere la documentazione può liberare un discreto quantitativo di spazio.
Come farlo:
Puoi configurare apt per evitare di installare la documentazione. Ad esempio:
Con questa configurazione, non verranno installati manuali, pagine man o altra documentazione inutile.
2. Evitare ripetizioni inutili di apt update
Quando esegui apt update, Docker scarica l’elenco aggiornato dei pacchetti dai repository. Tuttavia, eseguire più volte questo comando senza un motivo valido non solo rallenta la build, ma aumenta inutilmente la dimensione dell’immagine.
Inoltre può essere utile raggruppare il più possibile in una sola istruzione multiriga molte istruzioni Docker perché ad ogni riga viene aggiunto un layer.
Quando eseguire apt update:
Necessario: Prima di eseguire un’installazione (apt install) o subito dopo aver aggiunto un repository con add-apt-repository. Ogni volta che aggiungi nuovi repository, è importante aggiornare l’elenco dei pacchetti per includere le nuove fonti.
Non necessario: Se hai già eseguito apt update e devi solo installare nuovi pacchetti in momenti diversi. Non è necessario ripetere l’aggiornamento finché i repository non cambiano.
3. Cosa sono i layer in Docker?
Le immagini Docker sono costituite da una serie di layer impilati uno sopra l’altro. Ogni istruzione in un Dockerfile (come RUN, COPY, ADD) crea un nuovo layer. Questi layer sono immutabili e vengono memorizzati nella cache. I layer inferiori rappresentano l’immagine base, mentre quelli superiori contengono le modifiche. Ridurre il numero di layer e ottimizzarli aiuta a migliorare i tempi di build e a ridurre la dimensione dell’immagine.
Ad esempio raggruppare queste tre istruzioni
RUN apt update
RUN apt install -y
RUN build-essential
RUN procps
RUN systemd
consnte di aggiungere un solo layer anziché 4 migliorando la performance di build.
4. Pulire i file temporanei e la cache di apt
Una volta che hai installato tutto il necessario, puoi ridurre ulteriormente la dimensione della tua immagine Docker rimuovendo i file temporanei e la cache di apt. Questo passaggio aiuta a ridurre la dimensione del layer finale del container.
Comando da eseguire:
RUN apt clean && rm -rf /var/lib/apt/lists/*
Questo comando rimuove la cache di apt, che non è più necessaria una volta che i pacchetti sono stati installati. La cache può occupare una quantità significativa di spazio e non ha utilità all’interno del container.
5. Multi-stage build: attenzione agli aggiornamenti tra gli stage
Se stai usando una multi-stage build, dove hai più istruzioni FROM nel tuo Dockerfile, è importante ricordare che ogni FROM avvia un nuovo stage completamente separato. Se esegui comandi di installazione di pacchetti in più stage, dovrai eseguire apt update in ciascuno di essi.
Esempio:
FROM ubuntu:22.04 AS base
RUN apt update && apt install -y curl
FROM ubuntu:22.04 AS final
RUN apt update && apt install -y nginx
Ogni volta che utilizzi FROM, inizia un nuovo contesto, quindi dovrai aggiornare i pacchetti separatamente.
6. Evitare di copiare file non necessari
Un’altra pratica comune che può ridurre la dimensione dell’immagine è l’uso del file .dockerignore per evitare di copiare file inutili nel container. File come .git, documentazione o altri file non essenziali possono essere esclusi.
Esempio di .dockerignore:
.git
*.md
In questo modo, Docker ignorerà questi file durante il build.
Conclusione
Seguendo queste best practice, puoi migliorare significativamente la velocità di build e ridurre la dimensione delle immagini Docker. Ecco un riepilogo delle strategie:
Eliminare la documentazione dei software: Imposta apt per non scaricare documenti e pagine man.
Non ripetere apt update inutilmente: Fai apt update solo quando necessario.
Pulizia della cache: Usa apt clean e rimuovi i file temporanei per minimizzare lo spazio occupato.
Multi-stage build: Ricorda che ogni FROM richiede un aggiornamento separato.
Usa .dockerignore: Escludi file non necessari durante il build.
Con queste tecniche, puoi ottenere immagini Docker più piccole, più efficienti e più veloci da costruire.
Ho trovato un metodo per personalizzare l’elenco dei bookmark in Nautilus, consentendo di organizzare i segnalibri per qualsivolgia criterio.
L’elenco dei segnalibri che mi presentava Nautilus era divenuto pian piano molto confuso e trovare i link relativi a risorse SFTP o Samba di rete locale mia o di qualche cliente era diventato un problema.
Divide et impera
Per prima cosa ho fatto un po’ di ordine. L’elenco dei bookmark di Nautilus si trova sotto
~/.config/gtk-3.0/bookmarks
Avevo anche il problema di sincronizzare questo elenco in tutti i miei pc, per cui sistemato un file, lo propago a tutti i computer.
Raccogliere e mescolare tutti i segnalibri
Nel tempo ho collezionato segnalibri diversi nei vari pc, occorre fare un merge. Mi porto tutti i file bookmarks di tutte le macchine in un pc ed effettuo il merge:
Il risultato è buono. In particoalre ho fatto un sort e ho estratto 1 sola ripetizione per segnalibro (con l’opzione -u, “unique”). Ora però devo raggruppare in modo diverso i segnalibri
Organizzare i segnalibri per server
Per prima cosa raggruppo i segnalibri per server (perdendo l’ordine alfabetico che è del tutto inessenziale, utile solo per il merge dei file)
Cercando in rete non ho trovato un modo per separare i vari gruppi con una linea orizzontale, però ho trovato che posso aggiungere delle icone includendo dei caratteri UTF-8 con un semplice copia/incolla.
Posso aggiungere delle scritte oltre alle icone utilizzando la sintassi
1# Server 1 Nautilus sostituirà ogni occorrenza di “#1″ con la scritta ” Server 1 “. Questio comportamento è stato un po’ criptico da individuare perché commentando ogni linea con
# Server 1 ... # Server 2
quello che vedevo in nautilus era sempre
# Server 1 ... # Server 1
Quindi i separatori vanno marcati con un carattere seguito da #, la cosa più pratica è un numero seguito da # e ne possiamo fare quanti vogliamo:
1# Server 1 ... 2# Server 2
L’aspetto finale è il seguente (non so se sia possibile migliorarlo ulteriormente, ma mi basta così):
Ubuntu: Personalizzare i bookmark su Nautilus
Ovviamente se clicco sui segnaposto, Nautilus dà un errore, ma mi sono capito io…
TLP è un sistema per Linux che aiuta a prolungare la durata della tua batteria. Utilizzando TLP, potrai ottimizzare le impostazioni del sistema per ridurre il consumo energetico e massimizzare l’efficienza energetica. Con TLP, potrai godere di una maggiore durata della batteria per il tuo sistema Linux.
TLP, tool per Batteria Laptop
Installazione di TLP
Su Ubuntu 22.04 Jammy Jellyfish:
$ sudo apt install tlp
Dopodiché basta avviarlo manualmente, dal prossimo boot (a meno di indicazioni contrarie) partirà da solo.
Va preventivamente avviato il servizio:
$ sudo systemctl enable tlp.service
Synchronizing state of tlp.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable tlp
insserv: script ypbind: service ypbind already provided!
...
Created symlink /etc/systemd/system/multi-user.target.wants/tlp.service → /lib/systemd/system/tlp.service.
Quindi lo avviamo:
$ sudo tlp start
TLP started in AC mode (auto).
Possiamo vedere le statistiche
$ tlp-stat -s
--- TLP 1.5.0 --------------------------------------------
+++ System Info
System = Acer V1.20 TravelMate P216-51
BIOS = V1.20
OS Release = Ubuntu 22.04.4 LTS
Kernel = 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64
/proc/cmdline = BOOT_IMAGE=/boot/vmlinuz-6.8.0-40-generic root=UUID=1e25e923-e1cf-4a4c-a3de-1793b4a682a4 ro quiet splash vt.handoff=7
Init system = systemd v249 (249.11-0ubuntu3.12)
Boot mode = UEFI
+++ TLP Status
State = enabled
RDW state = enabled
Last run = 09:40:40, 10 sec(s) ago
Mode = AC
Power source = AC
TLP ci consente (ad esempio) di agire manualmente sui livelli di carica e scarica, ci consente cioè di impostare la carica minima al di sotto della quale parte la ricarica e la carica massima al di sopra della quale la ricarica viene interrotta. Ad esempio:
$ sudo tlp setcharge 70 90 BAT0
applica le soglie 70% – 90% alla batteria BAT0.
BAT0 seleziona la batteria principale/interna, BAT1 la batteria ausiliaria/Ultrabay da scaricare
Letteralmente, dal sito di TLP:
What does TLP stand for?
TLP is not an acronym, it’s just a three-letter name.
Nel mio ultimo computer ho voluto tenere un dual boot con GRUB essendo obbligato in alcune situazioni ad utilizzare una macchina Windows genuina per connettermi ad alcune VPN. Stamattina, eseguendo gli aggiornamenti del sistema operativo Windows 11, qualcosa è andato storto ed è stato danneggiato il GRUB che mi permette all’avvio della macchina di avviare Ubuntu 22.04 oppure Windows11
Unified Extensible Firmware Interface
Cos’è GRUB
GRUB (Grand Unified Bootloader) è un bootloader, ovvero un programma che viene eseguito all’avvio di un computer per caricare il sistema operativo. È particolarmente comune nei sistemi basati su Linux, ma può essere utilizzato anche per avviare altri sistemi operativi come Windows.
Funzioni principali di GRUB:
Selezione del sistema operativo:
GRUB permette di scegliere quale sistema operativo avviare se ne hai installato più di uno sullo stesso computer (dual-boot). Ad esempio, se hai sia Ubuntu che Windows installati, GRUB ti presenterà un menu all’avvio dove puoi scegliere quale sistema operativo avviare.
Caricamento del kernel:
GRUB carica il kernel del sistema operativo scelto in memoria e lo avvia. Il kernel è il cuore del sistema operativo e gestisce tutte le interazioni tra l’hardware e il software.
Configurabilità:
GRUB è altamente configurabile. Puoi modificarne le impostazioni per cambiare l’aspetto del menu, aggiungere o rimuovere opzioni di avvio, impostare quale sistema operativo deve essere avviato di default, e molto altro.
Compatibilità con diversi file system:
GRUB supporta una vasta gamma di file system, il che significa che può leggere i file necessari per avviare un sistema operativo indipendentemente dal file system utilizzato.
Modalità di recupero:
Se un sistema operativo non riesce ad avviarsi correttamente, GRUB può fornire opzioni per avviare il sistema in modalità di recupero (recovery mode) o per passare parametri speciali al kernel per aiutare a risolvere problemi.
GRUB e UEFI
UEFI e BIOS: GRUB funziona sia con sistemi UEFI (che è il firmware moderno presente nei computer più recenti) sia con sistemi BIOS (che è il firmware più vecchio).
Secure Boot: In sistemi UEFI con Secure Boot abilitato, GRUB deve essere firmato digitalmente per poter essere avviato. Questo garantisce che solo software approvato possa essere eseguito all’avvio, migliorando la sicurezza.
Versioni di GRUB
GRUB Legacy: La versione più vecchia di GRUB, che è meno usata oggi.
GRUB 2: La versione più recente e quella più comunemente utilizzata oggi. GRUB 2 offre molte più funzionalità rispetto a GRUB Legacy, incluso un sistema di configurazione più potente e un supporto esteso per diversi tipi di file system e dispositivi di avvio.
Tentativo di soluzione manuale
La prima operazione da fare è creare una chiavetta USB di avvio contenente la stessa versione di Ubuntu che ho a bordo del PC, la 22.04 Jammy Jellyfish.
Creazione di un USB disk di avvio
Per fare questo occorre scaricare dal sito di Ubuntu l’immagine ISO di questa versione; una volta scaricata l’ISO utilizzare l’utility di creazione dischi:
Crea disco di avvio
Selezionare quindi l’immagine scaricata e avviare la creazione del disco
Installazione dell’USB di avvio
Alla fine verrà mostrato l’avviso di creazione eseguita
Creazione USB disk completata
Come è stato partizionato il disco?
Occorre innanzitutto chiarire come è stato partizionato il disco quando è stato installato Ubuntu.
Per fare questo esistono due comandi di ispezione che sono lsblk e fdisk.
Questo è l’output di lsblk per il mio disco
$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 4K 1 loop /snap/bare/5
loop1 7:1 0 10,1M 1 loop /snap/canonical-livepatch/278
...
loop54 7:54 0 447,3M 1 loop /snap/telegram-desktop/6117
nvme0n1 259:0 0 953,9G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
├─nvme0n1p2 259:2 0 16M 0 part
├─nvme0n1p3 259:3 0 464,3G 0 part
├─nvme0n1p4 259:4 0 1G 0 part
└─nvme0n1p5 259:5 0 488,3G 0 part /var/snap/firefox/common/host-hunspell
E questo è l’output per fdisk
$ sudo fdisk -l
[sudo] password di marco:
Disk /dev/loop0: 4 KiB, 4096 bytes, 8 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
...
Disk /dev/nvme0n1: 953,87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: WD PC SN740 SDDQNQD-1T00-1014
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8C2BBF42-DC93-4D6C-A305-9C00B93C5816
Dispositivo Start Fine Settori Size Tipo
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 974311423 973744128 464,3G Microsoft basic data
/dev/nvme0n1p4 1998311424 2000408575 2097152 1G Windows recovery environment
/dev/nvme0n1p5 974311424 1998311423 1024000000 488,3G Linux filesystem
Partition table entries are not in disk order.
Interpretazione di lsblk e fdisk -l
Dispositivi loop:
I dispositivi loop che vengono mostrati (loop0, loop1, ecc.) sono immagini montate temporaneamente dal sistema live che si sta utilizzando. Non hanno a che fare con il mio disco fisso, quindi li possiamo ignorare.
Disco sda:
Questo sembra essere il supporto USB o il CD/DVD da cui ho avviato il sistema live. Anche questo possiamo ignorarlo per ora.
Disco nvme0n1:
Questo è il mio SSD principale da 953,87 GiB (1 Terabayte), suddiviso in diverse partizioni:
Partizione
Tipo
Dimensione
/dev/nvme0n1p1
EFI System (Partizione EFI)
260M
/dev/nvme0n1p2
Microsoft Reserved
16M
/dev/nvme0n1p3
Microsoft basic data (Windows)
464,3G
/dev/nvme0n1p4
Windows recovery environment
1G
/dev/nvme0n1p5
Linux filesystem (Ubuntu)
488,3G
Quindi le partizioni più importanti sono
/dev/nvme0n1p1 che è quello dall’UEFI (l’ex BIOS)
/dev/nvme0n1p3 la partizione Windows
/dev/nvme0n1p5 la partizione Linux
Procedura per ripristinare GRUB
Ora che abbiamo identificato le partizioni, si può procedere con il ripristino di GRUB montando manualmente dal sistema di avvio USB la partizione di Ubuntu e reinstallando GRUB.
1. Montare la partizione di Ubuntu
Monto la partizione di Ubuntu, che nel mio caso è /dev/nvme0n1p5, con il seguente comando:
sudo mount /dev/nvme0n1p5 /mnt
2. Montare le directory necessarie
Dopo aver montato la partizione di Ubuntu, devo montare anche le altre directory necessarie:
sudo mount –bind /dev /mnt/dev
sudo mount –bind /proc /mnt/proc
sudo mount –bind /sys /mnt/sys
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
Il comando per montare /dev/nvme0n1p1 nella directory /mnt/boot/efi è necessario perché questa partizione contiene i file di avvio EFI.
3. Accedere alla mia installazione con chroot
Ora, entro nel sistema Ubuntu installato utilizzando chroot (in questo momento sono nella chiavetta USB!):
sudo chroot /mnt
4. Reinstallare GRUB
Reinstallo GRUB sul SSD principale (che è /dev/nvme0n1):
Dopo il riavvio, dovrei vedere il menu di GRUB e poter scegliere tra Ubuntu e Windows.
Ma non funziona
Però quanto fatto non funziona: si avvia sempre automaticamente la partizione Windows e non vedo più Linux.
In realtà la partizione c’è: avviando UEFI (premendo F2 all’avvio) vedo correttamente le due partizioni e modificando l’ordine a mano parte sia Windows che Linux ma non parte più il GRUB.
Tra le varie opzioni trovate da ChatGPT 4, preferisco andare direttamente all’opzione che mi consiglia di installare boot-repair.
Ripristino del bootloader con Boot-Repair
Avvio nuovamente il sistema con un live CD/USB di Ubuntu.
Un estratto della procedura di riparazione dell’UEFI è questa (mi viene generato un pastebin che verrà conservato per un mese. Me lo trascrivo in locale):
============================= Boot Repair Summary ==============================
modprobe: FATAL: Module efivars not found in directory /lib/modules/6.5.0-18-generic
Recommended repair: ____________________________________________________________
The default repair of the Boot-Repair utility will reinstall the grub-efi-amd64-signed of
nvme0n1p5,
using the following options: nvme0n1p1/boot/efi
Additional repair will be performed: unhide-bootmenu-10s use-standard-efi-file
Mount /dev/nvme0n1p1 on /mnt/boot-sav/nvme0n1p5/boot/efi
Unhide GRUB boot menu in nvme0n1p5/etc/default/grub
============ Reinstall the grub-efi-amd64-signed of /dev/nvme0n1p5 =============
In sostanza credo che l’aggiornamento di Windows abbia in qualche modo causato una corruzione del file efi nella partizione destinata a EFI.
Tuttavia questa operazione fatta da boot-repairrisolve completamente il problema e il dual boot ricomincia a funzionare, lo provo per un po’ di volte per essere sicuro.
Ho risolto un problema che mi ha disturbato per un po’ di tempo: volendo pulire la cache di Laravel con il comando
$ php artisan cache:clear
ne risultava immancabilmente un errore
ERROR Failed to clear cache. Make sure you have the appropriate permissions.
Apparentemente tutte le assegnazioni sulla proprietà e sull’operatività (R/W) sulle varie cartelle erano corrette. Anche le interazioni con ChatGpt non davano i suggerimenti sperati.
Ma una cosa mancava. La faccio breve, mancava questa directory che ho quindi creato a mano con il mio user marcob:
$ cd <APP-ROOT> $ mkdir storage/framework/cache/data $ php artisan cache:clear INFO Application cache cleared successfully.
Un piccolo esercizio che studia la serie di Madhava, o Madhavan, trovato nel capitolo sui cicli del bel libro di Christian Hill, Learning Scientific Programming with Python, second edition, 2020, Cambridge University Press, ha risvegliato la mia passione per la matematica.
Mi diverto ancora a ristudiare i fondamentali della programmazione, un po’ come un buon pianista che non smette di esercitarsi con l’Hanon.
È un algoritmo eccezionale che converge con velocità esponenziale per trovare le cifre di \pi.
L’algoritmo di Madhava, noto anche come serie di Madhava-Leibniz (anche se quella di Leibniz è posteriore e peggiorativa rispetto a questa, per cui mi pare più corretto chiamarla di Madhava e basta), è uno dei metodi storici per calcolare il valore di π.
Prende il nome dal matematico indiano Madhava di Sangamagrama, che visse tra il XIV e il XV secolo, – un periodo intermedio tra i nostri Leonardo Pisano “Fibonacci” e Scipione del Ferro – ed è considerato uno dei precursori del calcolo infinitesimale.
Nell’articolo che segue, c’è la descrizione dell’algortimo, la dimostrazione della convergenza, l’analisi della velocità convergenza e l’implementazione in Python con Matplotlib.
Piccolo tutorial su come configurare un accesso cifrato con SSL per un sito web. Sia myserver il nome sia dell’host che del dominio: ovviamente in questo tutorial non utilizzeremo il DNS, stiamo solo facendo esperimenti in rete locale per cui basta specificare il nome dell’host.
SSL
Ingredienti
una chiave privata
una richiesta di certificato
un certificato SSL
un virtualhost Apache
molta pazienza
Chiave SSL
Utilizzando OpenSSL generiamo una chiave privata RSA. Dalla directory in cui si desidera salvare la chiave privata (tipicamente /etc/ssl/private/) si esegue il seguente comando:
$ sudo openssl genrsa -out myserver.key 2048
Richiesta di firma
Utilizzando la chiave privata appena generata, creiamo una richiesta di firma del certificato (CSR).
Importante: Assicuriamoci di inserire correttamente il nome del dominio locale quando richiesto.
Muoviamoci adesso in un directory standard che contiene tutti i certificati SSL: /etc/ssl/certs/
Configuriamo ora Apache per utilizzare il certificato SSL per il sito “myserver”.
Apriamo il file di configurazione di Apache (apache2.conf, lavorando con una distribuzine Ubuntu) , o un file specifico per il sito: io per esempio ho un file in cui configuro tutti i virtualhost per le mie applicazioni Laravel che si chiama laravel.conf) e aggiungiamo il seguente blocco di configurazione:
<VirtualHost *:443>
ServerName myserver
DocumentRoot /var/www/myserver
SSLEngine on
SSLCertificateFile /etc/ssl/certs/js.crt
SSLCertificateKeyFile /etc/ssl/private/js.key
# Opzionale: Specifica il file di catena dei certificati (CA bundle) se necessario
# SSLCertificateChainFile /percorso/verso/ca-bundle.crt
# Altri settaggi del virtual host...
ErrorLog ${APACHE_LOG_DIR}/error_ssl.log
CustomLog ${APACHE_LOG_DIR}/access_ssl.log combined
</VirtualHost>
Abbiamo configurato anche i file di log che conterranno accessi ed errori al virtual host https://myserver.
Non abbiamo invece specificato alcuna catena di autorità (CA bundle) proprio perché è un certificato autofirmato che non fa riferimento ad alcuna Autorità di certificazione standard.
Se una stessa porta è utilizzata da altri virtualhost il sistema non funzionerà. Capire che è questo il problema può comportare un po’ di tempo.
I sintomi per questo tipo di errata configurazione sono parecchi:
Il browser lamenta genericamente un ERR_SSL_PROTOCOL_ERROR
Client e server abilitati antrambi a versioni di TLS compatibili
Porta crittografica non correttemente impostatata
analizzando il traffico anche con Wireshark si nota che non si ha nessun Server Hello in conseguenza al Client Hello e la risposta del server contiene un errore 400 Bad Request
Un controllo fatto con openssl da qualche informazione:
40F7C74FFA7F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 316 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
Per sistemare queste cose ho impostato:
Nella configurazione del Virtualhost bisogna scegliere porte diverse per Virtualhost diversi: replicare una stessa porta per virtualhost diversi porta a errori.
Scegliere porte che non siano già utilizzate da altri software oltre Apache (ad esempio nel mio muletto Netxgen si è già occupato la porta 8443)
Nella configurazione generale di Apache vanno aggiunte tutte le porte che si vuole ascolti; per fare questo editare il file ports.conf:
<IfModule ssl_module>
Listen 443
Listen 9443 <--- ho aggiunto questa
</IfModule>
Nel file di configurazione del virtualhost scegliere la porta scelta per ports.conf
<VirtualHost *:9443>
In questo stesso blocco abilitare le versioni di TLS supporate da Apache che verranno comunicate al clinet:
Start Time: 1716285423 Timeout : 7200 (sec) Verify return code: 18 (self-signed certificate) Extended master secret: no Max Early Data: 0 --- read R BLOCK closed
Ultima cosa: il certificato è autofirmato e quindi non è collegato a nessuna Certification Authority, dunque in ogni caso il browser ci avverte:
errore scambio certificato https
Una volta data l’autorizzazione a scaricare il certificato autofirmato, posso vedere in Wireshsrk tutte le transazioni:
Client Hello
Server Hello
Change Cipher Spec
È istruttivo vedere il frammento di conversazione TCP/IP in cui il server comunica al client al versione di TLS che intende usare, il session ID, l’algoritmo di cifratura simmetrica per stabilire la chiave simmetrica DH con i parametri lunghezza e chiave:
Frammento dell’handshake (Server hello) con lo scambio dei parametri DH
Adozione di un certificato Let’s Encrypt
Un certificato Let’s Encrypt risolve ottimamente e senza costi il problema della verifica del certificato da parte dei browser, ma in questa fase mi interessava sapere come funzionano le cose, essendo queste delle prove eseguite in un ambiente isolato.
Mi serve una installazione Oracle sul mio Linux Ubuntu 22.04. Dai vari link vedo che c’è qualche difficoltà a trovare pacchetti di installazionde diversi da distribuzioni Suse e RedHat. Per cui decido di utlizzare un container Docker al fine di sorpassare questi problemi di compatibilità, per lo sviluppo può andare più che bene.
Ho trovato un aiuto nel link citato nei Riferimenti
Creo il container e lo avvio (attenzione che con l’istruzione di creazione definisco la password di system!):
$ docker container create -it --name oracle-devel -p 1521:1521 -e ORACLE_PWD=welcome123 container-registry.oracle.com/database/express:21.3.0-xe
5640b42ae4387deffad2594fb0f9a391e13a53ed8e9bc8cc87cf17e41e445be2
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5640b42ae438 container-registry.oracle.com/database/express:21.3.0-xe "/bin/bash -c $ORACL…" About a minute ago Created oracle-devel
$ docker start oracle-devel
oracle-devel
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5640b42ae438 container-registry.oracle.com/database/express:21.3.0-xe "/bin/bash -c $ORACL…" 2 minutes ago Up 2 seconds (health: starting) 0.0.0.0:1521->1521/tcp, :::1521->1521/tcp oracle-devel
Alla fine mi connetto con Sqldeveloper in localhost specificando
nome utente: system
password
nome host: localhost
porta host: 1521
SID: xe
La connessione funziona (Stato: operazione riuscita):
Utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Lo facciamo per migliorare l'esperienza di navigazione e per mostrare annunci personalizzati. Il consenso a queste tecnologie ci consentirà di elaborare dati quali il comportamento di navigazione o gli ID univoci su questo sito. Il mancato consenso o la revoca del consenso possono influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.
Commenti recenti