Proudly debugging the system since 1981
Note to self: quando le richieste websocket non funzionano in una applicazione proxata con Apache 2 questa pagina può essere di aiuto : https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
In caso in futuro non sia più disponibile la configurazione che che ho usato e’
ProxyPass / http://example.com:9080/
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "ws://example.com:9080/$1" [P,L]N8n è un bel progettino per realizzare workflow automatizzati, mettendoci dentro un po di AI.
Come da esperienze precedenti ho provato a farlo funzionare utilizzando il meno possibile servizi su cloud, più che altro per essere consapevole di come funziona ogni passaggio.
Per cui, primo passo installo N8N con una immagine che gira in locale su docker. Niente di difficile. Le istruzioni sul repository sono facili. N8N parte, richiede una mail di registrazione per sbloccare un po’ di funzionalità in modo gratuito. Va bene, anche se non ho verificato bene la differenza tra con e senza registrazione.
A questo punto mi pongo il problema di cosa fargli fare. Ce ne sarebbero mille ma di cose ma provo ad implementare una trascrizione di audio mediante telegram. L’obbiettivo è avere facilmente la trascrizione di messaggio audio provenienti da varie piattaforme di messaggistica, non necessariamente solo telegram.
Qualche aggiornamento di medio periodo. PhotoPrism di per se va bene, ma ha esposto un problema latente nel mio Raspberry PI, ovvero che i dischi dati erano formattati in NTFS. E che il supporto in scrittura di NTFS su linux fa abbastanza schifo. Nel senso che finché leggi va bene. Se fai “poche” scritture forse te la cavi, ma lo usi per appoggiarci un database e i millemila file che genera PhotoPrism il file system degradata molto rapidamente.
Tempo due giorni il file del database era corrotto. Sgancio il disco USB, lo attacco a un PC Windows e trovo una infinita di errori, più o meno aggiustati tutti ma ho seriamente rischiato di perdere due terabyte di dati personali. Foto, video etc…
Nel nuovo assetto i due dischi gemelli del Raspberry sono ora un in ExFAT e uno EXT4. Per ora non danno problemi.
Continuo la serie di segnalazioni di software con PhotoPrism. La ricerca di un software migliore per gestire il mio personale archivio di foto e’ nata dalla consapevolezza delle capacita’ dell’ AI di categorizzare le foto dopo un meetup di Codemotion.
Con tutte le evoluzioni avvenute negli ultimi 20 anni e’ davvero riduttivo avere un archivio di foto il cui unico indice e’ la data in cui la foto e’ stata scattata.
PhotoPrism, in modo assolutamente semplice permette di aggiungere il luogo (dati EXIF), la persona nella foto e alcuni tag basati sul contenuto delle foto.
La categorizzazione AI delle foto incide sugli ultimi due aspetti, riconoscimento dei volti, e riconoscimento delle situazioni e dei contenuti delle foto.
Il primo e’ ragionevolmente efficace, il secondo qualche spazio di miglioramento sicuramente ce lo ha ma già da un buon contributo.
L’istanza che ho messo in piedi gira sul Raspberry Pi 5, insieme a molte altre cose tra cui anche il recentemente citato Jellyfin, e si e’ scansionato 32000 foto e 1000 video in meno di 24 ore utilizzando solo la potenza di calcolo del Raspberry, senza utilizzare servizi esterni a supporto ma solo il modello locale di AI installato con PhotoPrism. Unica accortezza: dargli un po’ swap su disco (2-4 giga), essendo il mio con solo 4 giga di ram. Nei modelli con 8 giga si può evitare.
Qualche riferimento:
P.S.: Come ho scoperto PhotoPrism? Ho chiesto a Gemma.
Segnalo questo simpatico progetto che permette di trasformare l’esportazione di wordpress in una collezione di file markdown, più facilmente utilizzabili per altri scopi: https://github.com/lonekorean/wordpress-export-to-markdown
Piccolo bonus: scarica anche tutte le immagini referenziate nelle pagine e nei post in modo da avere una sorta di copia offline.
Posso confermare che la soluzione descritta qualche post fa, in Da Plex a Jellyfin, funziona correttamente per il mio utilizzo. Unica aggiunta, per la musica, consiglio il player Finamp, disponibile per Android e IOS, che rispetto al client ufficiale permette di scaricare sul dispositivo mobile alcune canzoni o anche intere playlist, cosa molto utile in viaggio fuori dall’Europa o in aereo.
Per quanto riguarda altri client l’ho provato direttamente via web, sul telefono Android col client nativo, su una FireTV e su una SmarTV sempre android sempre con risultati uguali o migliori di Plex, che presto verrà disinstallato.
Oggi ho scoperto Watchtower: è un’applicazione che monitora i container Docker in esecuzione e controlla le modifiche alle immagini da cui quei container sono stati originariamente avviati. Se Watchtower rileva che un’immagine è stata modificata, il container viene riavviato automaticamente utilizzando la nuova immagine.
Con Watchtower è possibile aggiornare la versione in esecuzione di un’applicazione containerizzata semplicemente caricando una nuova immagine su Docker Hub o su un registro immagini. Watchtower scarica la nuova immagine, arresta con grazia il container esistente e lo riavvia con le stesse opzioni utilizzate al momento del suo deployment iniziale.
Il tema non mi è nuovo, aumento di complessità, stack che diventano troppo profondi, impossibilità di conoscere tutto, almeno ad un livello di efficienza lavorativa in tempi accettabili e conseguente frustrazione, frammentazione dei framework, dei linguaggi e delle metodologie.
Sono incappato in una riflessione e conseguente proposta/lancio di un software per risolvere il problema dello sviluppo software (sembra un gioco di parole).
Le riflessioni sono interessanti.
“Every team’s setup is a unique snowflake. Even within the same programming language ecosystem, different teams will set up their dev process completely differently. Completely different build, test, packaging logic. Completely different runtime versions. Completely different eng culture. So on and so forth. This craziness is now the norm.”
“You can’t have strong innovation without freedom. You can’t have high-quality engineering and security without standardization.”
https://earthly.dev/blog/lunar-launch
Che poi la soluzione passi attraverso una verifica automatica ho qualche dubbio.
Ho deciso di provare questo progetto di intelligenza artificiale, Second Me, perché va oltre la “semplice” RAG ma effettua un training effettivo sui contenuti forniti e volevo verificarne l’efficacia. Il RAG e’ interessante ma spesso poco efficace quando si tratta di fare compiti per i quali il modello originale non era particolarmente bravo o competente.
Second Me pero’, purtroppo, e’ ancora molto immaturo. Al momento c’è un evidente bug che impedisce di allenare un modello diverso da quello da 0.5B di parametri (https://github.com/mindverse/Second-Me/issues/256) cosa che produce un risultato veramente deludente. Ho provato ad aggirare il problema mettendo il modello da 3B nella cartella di quello da 0.5B, sembra finire ma poi non parte.
Riproverò quando il progetto sarà un po più maturo.
Informazioni potenzialmente utili per altri ricavate dalle prime prove:
La configurazione di default prevede l’embedding e il modello di supporto utilizzando le API di open-ai ma si può benissimo usare ollama in locale su una buona GPU. Io ho usato nomic-embed-text:latest per l’embedding e gemma3:latest per il supporto. In teoria poteva girare anche gemma3:12b sulla mia GPU ma usando embedding e supporto insieme si rallentava parecchio e ho preferito un modello più piccolo.
Usando Second Me su docker e Ollama sulla macchina fisica i parametri per le API sono:
API Key: ollama
API Endpoint: http://host.docker.internal:11434/v1
e ovviamente il modello scelto…
La preparazione dei dati, embedding e memorie e quant’altro avviene effettivamente sulla GPU (di fatto lo fa ollama…), mentre il training avviene sulla CPU per cui credo manchi qualche cosa…
Il tempo complessivo con un po’ di memorie (i post degli ultimo due anni sul blog… poca roba) complessità media e modello 0.5B stanno circa sull’ora, ora e mezza con una 3060.
Risultati… veramente brutti :D. Ma riproverò tra un paio di settimane.
Plex tra un po’ ( 29 Aprile 2025 ) cambia alcuni prezzi.
Quello che interessa a me e’ che fino ad oggi era possibile fare streaming dei propri media, siano essi foto, musica o video, anche fuori dalla rete locale, sulle app o via web senza pagare un abbonamento. Bastava aprire un paio di porte sul proprio router e il cloud di Plex faceva la magia. L’unico costo era per la sola app per smartphone e si trattava di un costo singolo per avere lo streaming dei media fuori dalla rete locale.
Ora invece per poter fare streaming fuori dalla propria rete bisogna pagare un abbonamento. E per ascoltare o vedere le MIE cose mi sembra un po’ un’assurdità.
L’alternativa che ho trovato, e parzialmente sperimentato e’Jellyfin. Che e’ completamente open source e non dovrebbe iniziare a monetizzare sui suoi utenti solo perché qualche stratega aziendale dice che e’ il modo giusto di fare.
Che poi va anche bene far pagare un servizio, ma nel caso di Plex si tratta di poco più un dynamic dns venduto a 2 dollari al mese.
Ritornando a JellyFin si installa facilmente su Raspberry PI ma per avere i propri media accessibili ovunque la faccenda e’ un po’ più complicata non avendo un cloud a supporto.
Prima cosa bisogna individuare un servizio di DNS dinamico, dando per scontato che la maggior parte degli utilizzatori domestici non ha un IP statico e che quindi ad ogni riavvio del router questo cambia.
FREEDNS.afraid.org ha una interfaccia orribile anni 90, ma funziona con un semplice script curl pianificabile nella crontab del Raspberry.
E questo punto esponendo le porte di Jellyfin sul router (8096 e 8920) siamo quasi a posto.
Rimane qualche raccomandazione, essendo esposti su internet settiamo una password bella complicata e NON utilizziamo la connessione in http per farla passare o qualcuno potrebbe intercettarla.
E qua iniziano i problemi un po’ piu’ complicati. Jellyfin espone un servizio https sulla 8920 ma non ha un certificato e non e’ integrato con LetsEncrypt per l’aggiornamento automatico.
La soluzione che ho adottato io e’ di generare un certificato selfsigned di durata molto lunga, di creare un sottodominio sul mio VPS, agganciare questo al rinnovo automatico di LetsEncrypt e di fare reverse proxy verso Jellyfin. In questo modo i client si trovano un certificato firmato e valido, mentre tra i due server (VPS e Jellyfin) la comunicazione e’ comunque protetta da crittografia e in internet non passano password in chiaro.
Per far digerire ad Apache2 un certificato selfsigned solo per il virtualhost dedicato a Jellyfin ho inserito le direttive:
SSLProxyVerify none
SSLProxyCheckPeerName off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off
Il tutto fa un giro un po strano, mi consuma la banda del VPS (che pero’ tanto non pago a consumo), ha una difficoltà tecnica che non e’ proprio per tutti pero’ funziona.
© 2025 b0sh.net
Tema di Anders Noren — Su ↑