Categoria: Self Hosting

  • RaspberryPi Nas? Meglio di no

    Ho recentemente acquistato a scopo di test e senza ancora una destinazione finale, un RaspberryPi 5 4GB ad un prezzo abbastanza conveniente. Diciamo che sono un grande fan del Raspberry, oltre questo ho un rev. 2, un ver. 2, uno Zero (non 2W), un OrangePi Zero 2W, ma ciò che mi incuriosiva di più di questa nuova versione è la presenza di una porta PCIe 1x utilizzabile.

    Questa novità permette il collegamento al Raspi 5 di una serie di periferiche che possono espanderne gli ambiti di utilizzo, c’è anche chi ha provato ad installarci su una GPU discreta, spoiler alert, senza grossi risultati.

    Ciò però che mi intrigava di più era la possibilità di utilizzarlo come NAS, ma ho abbandonato questa idea quasi subito, dopo averne studiato le caratteristiche. Infatti, a mio modo di vedere, un NAS deve avere sicuramente una serie di caratteristiche fondamentali:

    1. Alemeno 8GB di RAM;
    2. Un boot da disco NVME, magari due;
    3. Possibilità di installare almeno due dischi da 3,5”, da configurare in ZFS su TrueNAS;
    4. Almeno una porta 2,5Gbps;
    5. Almeno una porta SFP+.

    Inoltre per convincermi ad assemblare un NAS basato su Raspberry Pi 5 deve sicuramente convenire economicamente rispetto a soluzioni alternative.

    Ma analizziamo tutto per punti.

    La RAM

    Il Raspberry Pi, notoriamente, non permette l’espansione della memoria, acquisti il modello da 4GB ed hai 4GB, acquisti il modello da 8GB ed hai 8GB. Rispetto alle alternative quindi non c’è storia.

    Il disco NVME

    E qui entra in gioco il PCIe e le prime considerazioni su di esso, che poi rappresenteranno uno degli argomenti di maggiore interesse di tutte le valutazioni. Diamo qualche dato che ci servirà anche a rispondere ai punti successivi. Si tratta di un PCIe 2.0 x1, forzabile a gen. 3, questo significa un massimo di 8 GT/s che equivalgono a circa 985 MB/s. Possiamo quindi installarci un NVME per il boot, anche se le velocità degli NVME gen. 3 arrivano a 2.400MB/s in lettura e 1.100MB/s in scrittura, quindi lo slot rappresenta il collo di bottiglia per il funzionamento a velocità piena.

    Le altre unità

    Per poter installare però unità alternative non è sufficiente installare una porta M.2 per l’installazione dell’NVME di boot, in quanto andremmo ad occupare tutte (o quasi) le porte più utili. Ci sono quindi disponibili sul mercato degli adattatori M.2 sdoppiati ed anche quadruplicati, questo significa però che il bus PCIe 1x andrà suddiviso per il numero di unità che andremo ad installare, per cui potremo installare o 2 unità M.2 o 4 unità M.2, ma nel primo caso trasformandole tutte in PCIe gen. 2, nel secondo caso addirittura gen. 1, con velocità massime rispettivamente di 500 MB/s e 250 MB/s. Come avrete sicuramente già capito il tutto è abbastanza inutile, in quanto un’interfaccia SATA 3.0 ha una velocità di 600MB/s, quindi lo slot andrà in ogni caso a fare da collo di bottiglia per tutte le unità.

    La porta 2,5Gbps

    Riguardo il NIC 2,5Gbps, per quanto già detto, sarebbe impensabile installarlo sullo slot PCIe, per cui l’unica soluzione che vedo è quella di usare un adattatore USB 3.0, e da quel che leggo online le velocità sono abbasta buone, ma qualcuno lamenta un leggero aumento dei consumi in idle.

    Lo slot SFP+

    L’installazione di uno slot SFP+ su RaspberryPi 5, richiedendo 10Gbps è praticamente impossibile.

    Il fattore economico e le alternative

    Parliamo ora di prezzi e di convenienza. Per poter assemblare un NAS basato su RaspberryPi dovrò limitarmi sull’uso della memoria, sulla velocità e la quantità degli hard disk meccanici, sulla quantità delle unità NVME, sulla disponibilità di una porta SFP+, sulla quantità di NIC 2,5Gbps. I prezzi, escludendo quello degli hard disk meccanici, sono i seguenti:

    • RaspberryPi 5: 89,00€
    • Alimentatore 27W: 17,00€
    • Dissipatore con ventola: 11,00€
    • Adattatore NVME x 2: 28,00€
    • NVME 256GB: 25,00€
    • Adattatore SATA 3: 40,00€
    • Adattatore USB 3 to NIC 2,5Gbps: 22,00€

    Totale 232,00€

    Tutto sommato però dobbiamo anche considerare che con una porta di rete 1 Gigabit, come quelle presenti sulla maggior parte delle schede madri in vendita, si raggiungono massimo trasferimenti di 110MB/s, per cui a conti fatti il vero collo di bottiglia è la rete, nemmeno il resto dell’hardware. Anche con l’installazione di un adattatore 2,5Gbps, come quello previsto nell’elenco precedente, la velocità della rete è comunque inferiore alla velocità massima di lettura e di scrittura, sempre che sulla rete non vi sia più di una macchina che accede al NAS in contemporanea. Quindi direi che qualcuno potrebbe anche accettare il compromesso.

    Sul mercato, però si trovano alternative ben più valide e sicuramente più economiche del RaspberryPi, come ad esempio i vari NUC basati su Intel N100. Hanno più RAM e la possibilità di espanderla e spesso sono dotati di base di 2 o più NIC 2,5Gbps o, in alternativa, di porte SATA 3. Anche il prezzo è inferiore, perché spesso non si superano i 200,00€. Hanno inoltre spesso anche una porta PCIe più veloce di quella del RaspberryPi.

    Conclusione

    Dal mio punto di vista, quindi, il RaspberryPi rimane un bel giocattolino, ma per farci altro. Se stai pensando di creare un NAS io consiglierei di valutare opzioni alternative, o anche di acquistare un NAS già assemblato. Il RaspberryPi 5 è comunque ottimo in altri ambiti, come Docker, Home Assistant o sicuramente per l’emulzione di giochi retro, grazie agli ottimi RetroPie, Batocera e simili.

  • Vedere il NAS su un contenitore LXC senza privilegi

    Ammetto di averci perso un bel po’ di tempo a risolvere questo problema, che inizialmente pensavo fosse di poco conto. Ho deciso di trasportare Docker su un contenitore LXC di Proxmox, rimuovendolo quindi dalla macchina virtuale Ubuntu su Proxomx sulla quale risiedeva da ben 2 anni. Mi sono convinto a fare questo switch per vari motivi, ma prevalentemente per gestire meglio le risorse ed a conti fatti questa sembra la soluzione migliore. Anche se la best practice indicata sulla documentazione di Proxmox suggerirebbe di lanciare Docker su una Virtual Machine piuttosto che su un contenitore LXC, come anche io ho fatto fino ad ora, invece grande parte della comunità non la pensa allo stesso modo, e con loro anche io. Un motivo su tutti? l’utilizzo della GPU. Infatti se effettuiamo il passthrough della GPU potremmo utilizzarla solo su una VM (tecnicamente sarebbe possibile farla funzionare su più macchine virtuali ma da molti test si evince come le performance si riducano drasticamente in questo scenario) mentre se la lasciamo sull’host potremo usarla tranquillamente sui contenitori LXC (sì sto parlando della trascodifica di Plex e di Jellyfin).

    Il problema è che installando Docker su un contenitore LXC senza privilegi sarà abbastanza complicato andare vedere, da quella macchina, un eventuale NAS. Ho fatto diverse prove ma senza successo. Alla fine ho trovato un post del forum ufficiale di Proxmox che proponeva una procedura che non funzionava completamente per le mie esigenze (il NAS era visto sul contenitore LXC ma non sulle istanze di Docker), ma mi ha aperto alla soluzione.

    In pratica bisogna prima di tutto montare il NAS sul file fstab di Proxmox, poi bisogna aggiungere un mount point sul contenitore LXC che punti al mount del NAS sull’host. La particolarità è che il NAS sull’host deve essere montato con UID 101000 e GID 101000, questo perché i contenitori Docker di default impostano UID 1000 e GID 1000 (ovviamente se li avete personalizzati vanno cambiati).

    # TrueNAS
    //192.168.1.50/share /mnt/truenas/share cifs _netdev,noatime,username=user,password=pass,uid=101000,gid=101000,dir_mode=0770,file_mode=0770,x-systemd.automount 0 0

    Infatti l’utente root senza privilegi dei contenitori LXC ha sempre UID 100000 e quindi l’utente default del contenitore Docker diventa 101000.

    Per rendere le cose più semplici

    Per rendere le cose più semplici utilizzo una particolare procedura. Dopo aver aggiunto il mount point sul file fstab, sul contenitore lxc creo un gruppo lxc_shares, di utenti che hanno accesso al NAS.

    # Nel caso il contenitore sia privileged
    groupadd -g 101000 lxc_shares
    
    # Nel caso il contenitore sia unprivileged
    groupadd -g 1000 lxc_shares

    In questo modo se voglio dare accesso al NAS ad un determinato utente non devo far altro che aggiungerlo al gruppo ed il gioco è fatto. Facendo un esempio con Plex su contenitore lxc

    # Verifico l'utente proprietario del servizio
    systemctl show -pUser,UID plexmediaserver

    In questo modo scopro che l’utente plex è il proprietario del servizio plexmediaserver. Aggiungo quindi l’utente plex al gruppo lxc_shares

    # Aggiungo l'utente al gruppo
    usermod -aG lxc_shares plex

    In questo modo potrò accedere al NAS da Plex.

  • Installazione di TeslaMate: una seconda instanza di Grafana?🤨

    Installazione di TeslaMate: una seconda instanza di Grafana?🤨

    Oggi ho finalmente installato sul mio home server TeslaMate, il datalogger per chi possiede una Tesla. Questo tool permette di avere una comoda dashboard con innumerevoli dati relativamente al vostro veicolo elettrico ed una delle caratteristiche più interessanti è la connessione con Grafana, che permette di visualizzare tutti i dati raccolti sulla nota applicazione per la visualizzazione e l’analisi interattiva dei dati.

    Ho quindi consultato la documentazione e dato uno sguardo alla guida per l’installazione su Docker: è previsto un file docker-compose.yml, io uso portainer, creo quindi uno stack TeslaMate e vi incollo il contenuto del file, ma… mi accorgo che TeslaMate include una versione modificata di Grafana e di Mosquitto già configurate al 100%, ed io (come tanti presumo) ho già un’istanza di Grafana funzionante e presto un’istanza di Mosquitto.

    Dovrei lanciare una seconda istanza di Grafana su una porta differente? abbastanza sporca come soluzione, ma la documentazione di TeslaMate non propone valide alternative, per cui mi fiondo su Google e cerco se qualcuno si è già trovato dinanzi a questo dubbio, intanto rimuovo dal file docker-compose.yml le parti relative a Grafana e Mosquitto e lancio l’installazione dei container rimanenti, ovvero l’app vera e propria ed il suo database PostgreSQL.

    Su Google trovo due pagine, entrambe su GitHub, “Best Practice: A second Grafana and Mosquitto?” e “Update install document for existing grafana instance” ma entrambe le soluzioni proposte mi lasciano qualche perplessità ed onestamente ad un primo test non hanno nemmeno funzionato. In particolare la seconda pagina prevede una modalità automatica con uno script che promette di svolgere parte del lavoro, ma devo ammettere che soluzioni di questo tipo mi lasciano un po’ perplesso se non è chiaro fino in fondo cosa svolgano tali script, per cui inizio a studiarlo per capire più a fondo le operazioni che effettua.

    In pratica questo script imposta 3 volumi aggiuntivi su Grafana, copia un file di configurazione relativo al dataset e tutte le dashboard in formato json presenti all’interno della cartella grafana di TeslaMate… ma perché fare tutto questo attraverso uno script, che per giunta non funziona?

    Come ho risolto

    Capito quindi il meccanismo ho deciso di configurare TeslaMate su Grafana manualmente, attraverso l’interfaccia grafica di Grafana. Questa soluzione mi permette di avere tutte le modifiche sotto controllo, mi permette di aggiornare le dashoboard facilmente quando uscirà un aggiornamento di TeslaMate, mi permetterà di svolgere tutte queste operazioni anche in remoto se ho accesso a Grafana e non alla macchina e soprattutto mi permette di poter disinstallare tutto e ripristinare Grafana pulito qualora decidessi di farlo. Vediamo quindi come ho fatto.

    I passaggi per collegare TeslaMate a Grafana

    Prima di tutto su Portainer ho collegato Grafana alla stessa rete di TeslaMate, questo per rendere possibile il collegamento di Grafana al database di Teslamate.

    Grafana si collega alla stessa rete di TeslaMate

    Successivamente ho aggiunto sul container di Grafana una nuova variabile di ambiente, che permette di installare i plugin necessari al funzionamento della dashboard di TeslaMate:

    GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=natel-discrete-panel,pr0ps-trackmap-panel,panodata-map-panel,natel-plotly-panel

    A questo punto ho avviato Grafana ed accedendo alla console direttamente sul container ho installato i plugin necessari con il seguente comando:

    grafana-cli --pluginsDir /var/lib/grafana/plugins plugins install pr0ps-trackmap-panel 2.1.2 &&
             grafana-cli --pluginsDir /var/lib/grafana/plugins plugins install natel-plotly-panel 0.0.7 &&
             grafana-cli --pluginsDir /var/lib/grafana/plugins --pluginUrl https://github.com/panodata/panodata-map-panel/releases/download/0.16.0/panodata-map-panel-0.16.0.zip plugins install grafana-worldmap-panel-ng

    Questo è il momento in cui è possibile creare il dataset. Andiamo quindi sulla pagina di configurazione dei dataset e scegliamo come sorgente PostgreSQL. Impostiamo TeslaMate come nome del dataset, poi host, username, database name e password impostati su TeslaMate, disabilitiamo “TLS/SSL Mode”, clicchiamo su “Save & test” per verificare se la connessione funziona. Se Grafana non riuscisse a collegarsi al database di TeslaMate significa che qualcuno dei dati inseriti non è corretto oppure che Grafana non si trova sulla stessa rete di TeslaMate.

    A questo punto possiamo creare le dashboard, clicchiamo su “New” ed aggiungiamo una nuova cartella dal nome “TeslaMate”, una dal nome “Internal” ed un’ultima dal nome “Reports”, prendendo spunto dalla configurazione vista sulla versione completa di TeslaMate. Scarichiamo quindi TeslaMate da GitHub ed estraiamo la cartella “grafana”. Al suo interno ci saranno una serie di file json e due cartelle, internal e reports appunto. Clicchiamo quindi su “New” > “New Dashboard” ed import, selezioniamo uno alla volta tutti i file json presenti nella cartella grafana. Al termine spostiamo tutte le dashboard nella cartella “TeslaMate” in modo da raggrupparle. Rimangono quindi le dashboard presenti in Internal e quella presente in Reports, ripetiamo lo stesso procedimento spostando poi le dashboard nelle relative cartelle. Al termine ci ritroveremo con una struttura di questo tipo:

    TeslaMate dashboard su Grafana

    L’ultimo passaggio necessario a questo punto è di impostare l’url di Grafana sulle impostazioni di TeslaMate.

    Abbiamo visto quindi come installare TeslaMate e collegarlo ad un’istanza di Grafana già esistente e funzionante, ma Mosquitto? Al momento non ho ancora installato Mosquitto ma sono sicuro che si presenterà lo stesso problema quando sarà il momento. Vi terrò aggiornati!😉