📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Creiamo un NAS LINUX con ZFS e "Versioni Precedenti" dei file - Home Cloud 1x04

morrolinux29:58

Transcription

Oggi creiamo un NAS con Linux. Ci sono almeno due modi per fare questa cosa, che vediamo tra poco. Ma comincio col dire che non ho finito di sperimentare con tipi di file system differenti e configurazioni RAID. Semplicemente proseguo parallelamente con l'installazione dei vari servizi. Oggi Samba, per condividere file in rete tra diversi host. Proprio perché chi non è interessato ai dettagli più di basso livello potrebbe avere l'impressione che altrimenti non si arriva mai al sodo. Comunque, mi vedrete portare altri contenuti in ambito storage molto presto.

Cominciamo con una breve panoramica che vi farà comodo a prescindere che decidiate di seguire passo passo il video di oggi oppure aspettare i prossimi sullo storage. Perché, come dicevo, installare un NAS in casa per condividere file in rete può essere fatto in almeno due modi. Una soluzione è più rifinita, ma richiede più risorse dedicate. L'altra soluzione è decisamente più scarna, ma è anche decisamente più leggera ed equamente funzionale. Tra poco vi spiego cosa ho scelto e perché.

La prima soluzione consiste nell'utilizzare TrueNAS, il successore di FreeNAS per chi se lo ricorda. Questa è una distribuzione ad uso NAS, che però fa anche da hypervisor, alla possibilità di utilizzare dei container, eccetera eccetera. Un po' come Proxmox, ma preferisco Proxmox per questo tipo di utilizzo. Mi sembra più maturo e ha delle funzionalità che TrueNAS non ha o non ha ancora. TrueNAS è in due versioni: per una CORE basata su FreeBSD e TrueNAS SCALE basata su Debian. Quest'ultima è ancora più carrozzata, ancora più pesante. Comunque, oltre che ricca di funzionalità, utilizzare TrueNAS solo per condividere qualche file e cartelle in rete locale in ambito domestico mi sembra un tantinello overkill, a prescindere che sia la CORE o la SCALE. Anche perché serve una macchina virtuale con almeno 8 GB di RAM e dei dischi dedicati, almeno un paio se vogliamo una ridondanza. Io, per questo progetto, vi ricordo che sto usando con 8 GB di RAM in tutto e non voglio utilizzare dischi dedicati soltanto per una VM, anche perché ne posso usare al massimo 6 con la carta di espansione. Se siete in uno scenario simile, quindi avete dei limiti su quanta RAM potete utilizzare, quanti dischi potete collegare, la seconda soluzione potrebbe essere più interessante.

E sto parlando di Samba LXC Toolbox. Rispetto a qualsiasi container Debian col suo installato il servizio Samba, questo ha di speciale di essere preconfigurato per esporre gli snapshot di ZFS come versioni precedenti. Se utilizzate Windows, questo funziona tramite Shadow Copy. Quindi, se avete installato Proxmox su ZFS come ho fatto io, ve la cavate con un semplice container. L'unico contro è che questo container sarà un container privilegiato. Quindi, dal punto di vista anche della sicurezza, non abbiamo le stesse garanzie di una sicurezza infrastrutturale di un container non privilegiato. Ancora, ancora una volta, acquista soluzione che si addice di più a un utilizzo domestico e personale che aziendale.

Ma passiamo all'azione. Oggi vi faccio vedere come installare questo servizio. Prima di tutto, sono sulla mia Proxmox. Non fate caso a questa tendina qua, probabilmente lo anonimizzata sfocandola, altrimenti lo sto dicendo adesso per ricordarmelo in fase di editing. Tutto ciò che dobbiamo fare è andare sulla pagina GitHub di Samba LXC Toolbox e seguire le istruzioni per l'installazione. Si tratta semplicemente di fare `apt update`, `apt install git` perché dobbiamo clonare il repository in questione. Sono proprio sulla shell del mio host Proxmox. Io ce l'ho già, quindi non me lo fa clonare giustamente. E poi ci spostiamo dentro a Samba LXC Toolbox, continuando a seguire le istruzioni. Quello che facciamo è copiare il file `conf samba.conf`.

[Musica]

E basta. Io l'ho già fatto, quindi non lo rifaccio, perché su questa copia andiamo a modificare le nostre impostazioni. La maggior parte di queste cose dovrebbero andare bene di default. Ad esempio, gli diamo 32 GB di storage per la sua root, impostiamo dove deve essere installato `local/zfs` nel mio caso, va bene così come `local` per i tempi storage. Questi sono i valori di default di Proxmox, quindi se non li avete cambiati andranno bene così. Un parametro particolarmente importante è questo qua: `share_fs_size`, cioè quanti GB deve essere grande il file system su cui andiamo a creare la condivisione. In parole semplici, diciamo che va a creare un disco virtuale di 1000 GB su cui risiederanno i file da condividere in rete. Vi faccio giusto dare una rapida occhiata ai valori che ho messo io, così vi fate un'idea di quello che potete cambiare anche voi. Qui decido già l'indirizzo IP che voglio dare alla macchina, per esempio, oppure che so, posso metterlo 251, quello che voglio. Definiamo la prima password che poi andremo a cambiare per il container LXC, per l'utente root. Vedete, si può fare veramente di tutto. Ad esempio, UTF-8. Ci vogliono 10 minuti in tutto a leggere questo file di configurazione, non è niente di che. Da qua in poi ci sono altri servizi che potremmo voler configurare, ma io non li configuro perché non li installerò nei file. Matrix, tutta roba che non c'entra già più niente. Vedete Nextcloud, perché l'autore si è un po' perso, ne vuole raggiungere sostanzialmente un sacco di altra roba. Comunque, non vi preoccupate, da lì in poi potete lasciarli non configurati. Salviamo ed usciamo.

A questo punto basta che lanciamo `install.sh`. Vedete qua ci chiede che cosa vogliamo installare. Mettiamo soltanto Samba. E a proposito di quello, abbiamo Samba AD che è un Domain Controller di Samba, Samba Member è una configurazione per essere membro di un Domain Controller, e Samba Standalone se non avete e non volete utilizzare un controller di dominio, che è il nostro caso perché siamo a casa nostra e non abbiamo nessun controller di dominio. Su via, quindi 13, invio. Guardate ora lui legge le possibilità di configurazione che abbiamo appena compilato e va a creare quello che ci serve. Guardate un po' qua sulla sinistra, è già comparso il container richiesto. Nella sezione risorse del container appena creato, vediamo che ha effettivamente rispettato i nostri parametri del file di configurazione: un disco da 32 GB e un disco per le condivisioni da 1000 GB. Il punto di mount è `/tank`. Inizialmente pensavo di gestire separatamente il container che abbiamo creato con il servizio di Samba e il dataset che contiene i dati da condividere. Alla fine, però, ho scelto di lasciare così com'è, quindi con un volume creato in questo ambito automaticamente da Proxmox, per diverse ragioni. La prima è una migliore integrazione con l'interfaccia web di Proxmox, quindi posso vederlo da qua, posso modificare anche le sue dimensioni. Voglio un action, resize, ad aggiungere altri 1000 GB, per esempio, e diventa un volume da due Tera, più o meno. La seconda è che in questo modo è più semplice gestire i backup tramite Proxmox Backup Server, che vedremo più andare avanti. Però, intanto, vi faccio vedere che qua dentro mi basta doppio cliccare, aggiungere al backup con una spunta, e ogni volta che farò il backup di questo container, viene fatto il backup deduplicato e incrementale anche dei dati condivisi tramite Samba. E la terza, ma non meno importante, è che questi volumi qua si possono facilmente spostare ovunque, quindi su un altro pool fisico, che siano i dischi rotazionali, eccetera eccetera, un NAS collegato in rete, la qualunque. E inoltre, con questa configurazione è più semplice migrare questo container su altre macchine, qualora creassimo un cluster di Proxmox, in modo che, a differenza di una macchina virtuale in cui facciamo il pass dei dischi e poi è un casino fare la migrazione perché ovviamente è collegata a quei dischi lì su quella macchina lì, qui è tutto in software, qui è tutto virtuale e quindi si sposta tutto con una grande facilità. È più versatile, insomma.

Dovrei poter fare login. Invio, perché si era incantata con l'utente root e la password specificata nel file di configurazione, quindi sempre Morro Linux. E qui lui mi dice: "Guarda, io ho una webcam console per la gestione tramite questo indirizzo, oppure tramite indirizzo IP direttamente". Quindi andiamo direttamente qua. Ovviamente questo è un certificato self-signed HTTPS, quindi dobbiamo accettare il rischio e continuare.

Ed eccolo qua. Possiamo fare login con `admin` e la password che abbiamo impostato nel file di configurazione. Quello che vedete è la web UI cockpit. Non è specifica di questa soluzione, è una web UI abbastanza scarna, ma comunque funzionale per fare tutte le varie robe principali, tra cui configurare il servizio Samba senza ricorrere alla riga di comando. Però, per fare qualsiasi modifica, dobbiamo prima sbloccare i permessi amministrativi. Facciamo qua e guardate un po'. Ah, come mai non sta funzionando bene? Perché questo, no, questo non ve lo dicono, però lo so io perché ci sono già passato. Bisogna aggiungere l'utente `admin` al gruppo `sudo`, e poi `sudo` e anche da installare, in realtà, perché non era preinstallato, mi sa. Installo `sudo`, e poi `usermod -aG sudo admin`. Voilà. Facciamo prima logout e rifacciamo login. Voilà, fatto.

Ora che abbiamo sbloccato i superpoteri, possiamo modificare qualche parametro di configurazione. Ora vi faccio vedere come si configura una nuova condivisione Samba qui da cockpit, e per ogni cosa che sto per fare, ovviamente, c'è anche la versione da riga di comando. Senza questa web UI, che comunque è comoda da avere, vi faccio vedere un po' entrambe le cose. Sostanzialmente, state con me. Qui avete i log, che non ci servono a niente in questo momento. Le condivisioni Samba, tra cui c'è una già creata che era definita nel file di configurazione, ricordate `share` su `tank`, `share`. Le impostazioni generali di Samba e gli utenti Samba. Prima di andare a creare qualunque nuova condivisione, voglio però modificare un paio di cose a livello di permessi. Quindi vado su account e vado a creare un gruppo e uno o più utenti designati ad accedere a varie condivisioni. Qui vedete che sono elencati utenti e gruppi. Posso creare un nuovo gruppo al volo, ad esempio chiamo `tankshare` e sarà il gruppo di tutti gli utenti che possono accedere alla condivisione `/tank/share`, che abbiamo visto prima, quella di default, insomma. Comprimiamo un attimo questo. Andiamo sugli utenti, vado a creare un nuovo utente, ad esempio `morro`, con una password super segretissima. Create. Sì, sì, sì, sì, sì, va bene. Creiamo con la password come ti pare. E adesso andiamo ad aggiungere questo utente al gruppo. Edit user, groups, `tankshare`. Perfetto. Torniamo indietro. Perfetto. Questa cosa qua, anziché da interfaccia web, si poteva fare anche da riga di comando. Ve lo faccio vedere giusto per completezza. Bastava andare qua: `groupadd tankshare` (che esiste già e perché l'ho creata prima), `useradd morro` (che esiste già perché l'ho creato prima), `usermod -aG tankshare morro` (che andava eseguito con sudo, ma comunque ne facevo già parte in realtà). Posso confermare con `id morro` e vedete che fa parte del gruppo `tankshare`. Tank, tank, la qualunque, non importa.

Ultima cosa che rimane da fare, in realtà, se facciamo tutto quanto da riga di comando, è impostare una password per l'utente Samba. `smbpasswd` con il parametro `-a`, oltre a con la password, va anche ad aggiungere un corrispettivo utente Samba mappato sull'utente Unix appena creato. Quindi `smbpasswd -a morro`. In un colpo solo mi fa impostare la password Samba, che è diversa dalla password Unix dell'utente specificato, però la devo digitare tutte e due le volte nella stessa maniera, che altrimenti non funziona. Perfetto. Ho ripetuto gli stessi passaggi che avete visto da interfaccia web. Il vantaggio è che questa roba qua è automatizzabile, perché sono cinque righe, le mettete in uno script e ogni volta che c'è da creare un nuovo utente, bam! In questo momento c'è un utente Unix chiamato `morro` che verrà utilizzato per confrontare i permessi a livello di file system, e un utente Samba sempre col nome analogo che verrà utilizzato per gestire i permessi a livello di condivisioni Samba. Ve lo faccio vedere subito. Se io vado qua sotto Samba Shares, non sembrano cliccabili, ma queste voci sono cliccabili. Quindi vado sulla riga della condivisione, questa qui, TAC. Lui condivide questo percorso che è il disco da due Tera che abbiamo impostato da Proxmox. In realtà, questo è il disco da due Tera, poi c'è una cartella `share` che è quella che va a condividere. Ha già diversi permessi e diverse opzioni, tra cui lo owner può leggere e scrivere, ma non può eseguire. Il gruppo può leggere e scrivere, ma non può eseguire, e gli altri non possono fare niente. Però, a tal proposito, qui nel campo `users` dobbiamo definire quali sono gli utenti che possono accedere. Io qui posso scrivere `morro`, oppure posso specificare un gruppo semplicemente con il nome del gruppo preceduto da una chiocciola, ad esempio `tank@share`, che è il gruppo che ho creato prima, di cui `morro` fa parte. Comunque, andiamo a fare `update`, `apply changes`. In questo modo, qualunque utente che faccia parte del gruppo `tankshare` potrà accedere a questa condivisione. Però, che succede se provo ad accedere ora così com'è? Vediamo. Controlla le. Per abilitare la modalità inserimento, scrivo `\\samba\share`. Eccolo qua. Inserisci la password. Però vedete che continua a dire "accesso negato". Come accesso negato? Io sono `morro`, faccio parte del gruppo `tankshare`, quindi perché diavolo non mi fa entrare? E la ragione sono i privilegi a livello di file system che non abbiamo ancora aggiustato.

Diamo un'occhiata che permessi a `/tank`. Perfetto, per aprire tutto a root. La cartella `share` che andrà a essere condivisa a partire da `admin` e del gruppo `root`. In tutto questo, nessun degli utenti che io sto utilizzando per Samba è appartenente al gruppo `root`, e non sto usando l'utente `admin` per collegarmi. Quindi, a livello di file system, quando viene il confronto sui permessi Unix, questi non passano. Questa roba qua, che abbiamo il proprietario `root`, `-R` maiuscola, può essere ad esempio dell'utente `root`, non importa, ma almeno il gruppo deve essere `tankshare`. Ora, ovviamente, come al solito, con `sudo` davanti. Perfetto. Andiamo a vedere. Questo ci piace già di più, perché adesso a livello di file system vengono applicati i permessi del gruppo, che in questo caso sono uguali a quelli dell'utente proprietario. L'abbiamo visto prima. A questo punto, se io ci riprovo, vediamo. Eccolo qua, perfetto. Lo posso creare io una cartella qua dentro. Vedete, non mi ha dato nessun errore. In realtà, io sto già proprio modificando il contenuto. Posso creare quello che mi pare e ho permessi di lettura e di scrittura. Infatti, se vado qua dentro, vediamo cosa c'è in questo momento. Sono l'utente `admin` e `root`, che non sono né il proprietario a livello di utente né di gruppo. Quindi, utilizzare un ottimo `sudo` per dare un `ls` è una cosa stupida, ma va bene. Vedete i permessi su questa roba che ho creato sono effettivamente quelli dell'utente Unix potente `morro`, gruppo analogo. Quindi, se io condivido questa cartella con altri utenti sempre facenti parte del gruppo `tankshare`, però comunque verranno creati i loro rispettivi file con i permessi adeguati di ciascun utente. E questo è esattamente quello che volevamo.

Ora, l'ultima cosa che manca, se proprio vogliamo chiudere il cerchio, sarebbe quella su come rimuovere un utente. Qui cockpit dà la possibilità di rimuovere un utente in questa maniera qua. In ogni caso, questo è l'utente Unix e non so se a livello di Samba poi funzioni correttamente tutto quanto, cioè se venga eliminato correttamente. Per eliminare anche l'utente Samba, insomma, io faccio così: `smbpasswd -x morro`, `userdel morro`, e poi eventualmente, se voglio eliminare anche il gruppo, faccio `groupdel tankshare`. Vabbè, però non lo faccio perché ha lavorato tanto.

Ora andiamo a creare una nuova condivisione, giusto così per chiudere il cerchio. Vado sotto Samba e premo qua sopra. Sì, lo so, non è per niente intuitivo. Per fare una nuova condivisione Samba o aggiungere qualcosa di nuovo, sostanzialmente bisogna prendere quel cosettino qua minuscolo. La condivisione la voglio chiamare `cacca`, perché non mi viene un nome migliore. Dove voglio `tank/cacca`. Commento `caccona`. Gli utenti voglio soltanto gruppi, l'utente `admin`. In questo caso, boh. Create, apply. Ora, fra l'altro, qua negli utenti Samba non mi ha neanche elencato `morro`. Fammi provare a refreshare la pagina. Sì, era tutto qua. Ed eccolo qua. Adesso le due condivisioni che abbiamo: `share` e `cacca`. Ora, ovviamente, dovrebbe esserci una cartella sotto `tank` chiamata `cacca`, che ora non c'è, quindi la vado a creare al volo. Sì, e li vado anche a mettere i permessi giusti: `admin:root tank/cacca`. Questa roba qua dovrei poterla accedere perché comunque l'utente Unix corrisponde. Vediamo se è vero. `admin@indirizzo_ip/cacca`. Andiamo. Password `admin`. E voilà, è una cartella vuota. Come prima, però io posso andare a creare qualcosa. Eccetto che, a quanto pare, cockpit può bloccarsi, inchiodarsi e scrivere file di configurazione incompleti, perché fino a pochi secondi fa queste due righe qua non c'erano. Ho dovuto semplicemente spippolare qua un attimino, attaccare, attaccare e staccare e fare `update` per sovrascrivere la configurazione. In sostanza, in modo che anche queste colonne fossero completate, perché prima questa configurazione non era valida ai fini della condivisione Samba. Comunque, a questo punto posso crearci quello che mi pare a me. E voilà. Stesso discorso.

Comunque, questa qui è l'occasione perfetta per farvi vedere ciò di cui stiamo parlando quando dico che questo è un file di configurazione di Samba sotto formato HTML. Vi faccio vedere il file di configurazione `/etc/samba/smb.conf`, dove se ci fate caso, qui ci sono esattamente gran parte, se non tutte, le impostazioni generali che vedevamo nel pannello di prima. E poi abbiamo le condivisioni. Ora, a parte questo `[home]`, `[printers]`, `[print$]`, `[bum]`, `[bam]`, guardate qua: `[shares]`, quello che abbiamo detto prima, commento, browser, bla bla bla bla, `mask`, e poi l'altra condivisione. Ogni condivisione ha questa sintassi qua. Ho fatto un sacco di anni fa, forse più di 12 anni fa, un video su come si configurava Samba semplicemente tramite file di configurazione, senza interfaccia grafica e senza niente di che. In gran parte ancora valido. Comunque, questo è il file di configurazione che viene modificato quando modifichiamo qualcosa dalla interfaccia web.

Questo container è preconfigurato per mostrare ai client Windows le versioni precedenti dei file attraverso gli snapshot di ZFS. Prima di tutto, per fare gli snapshot su ZFS non serve nessun software in particolare. Basta scrivere `zfs snapshot` qualcosa del genere. Però possiamo fare di meglio. Possiamo utilizzare dei tool policy-driven come `sanoid`, che gestiranno automaticamente la pianificazione e la creazione degli snapshot, così come la pulizia dei vecchi archivi. In questo caso, dovremmo lavorare sulla shell di Proxmox direttamente e non su un container. E installiamo `sanoid`. `apt install sanoid`. Io l'ho già fatto, quindi non devo installare nulla. Andiamo a creare la cartella `sanoid` sotto `/etc`. Io l'ho già creata prima. E infine, copiamo `user/share/sanoid/sanoid.defaults.conf` all'interno di `/etc/sanoid/sanoid.defaults.conf`. Sì, allo stesso nome. E per chi se lo sta chiedendo, questo file di configurazione contiene le impostazioni di default. Che l'avrebbe mai detto che bere leggete voi con calma. Io non sono un manuale, però sostanzialmente ci sono impostazioni su quanta capacità utilizzare sullo storage, se monitorare oppure no lo stato, e bla bla bla bla, quanto spesso fare gli snapshot, quanti conservarne, eccetera eccetera. Questo non è il nostro file di configurazione, però. Adesso creiamo un file di configurazione per `sanoid` che deve contenere le impostazioni di snapshot che vogliamo utilizzare per ogni specifico volume di ZFS. Io scrivo `zfs list`. Lui mi elenca tutti i suoi volumi, dataset, elenca tutto. E guardate qua, il mio container Samba con servizio Samba per condividere bla bla è il numero 205. Qui sotto abbiamo due dischi: il `disk 0` da 32 GB che è la root di quel file system, e il `disk 1` da 2 Tera che è il volume delle condivisioni, che è quello che vogliamo snapshotare periodicamente. Quindi, io questo nome qua me lo copio, perché adesso vado a modificare `/etc/sanoid/sanoid.conf`, dove, fra l'altro, c'è già la mia attuale configurazione per il NAS che ho già in produzione, che ho fatto prima di registrare questo video. E guardate un po'. Stessa cosa, tra parentesi quadra, il percorso completo. E poi possiamo dirgli, ad esempio, di usare un template `production`. Qui sotto specifichiamo i vari template che vogliamo, ad esempio, questo dice di tenere 36 backup orari, 30 giornalieri e tre mensili. Potete creare altri template se volete altre regole, oppure specificare direttamente sotto ciascuno di questi volumi delle regole specifiche per quello. Però vi rimando alla documentazione ufficiale di `sanoid`, perché è enorme. Comunque, salvo ed esco.

E l'ultima cosa che devo fare per rendere effettivi questi snapshot periodici è invocare `sanoid` periodicamente. E questo lo faccio modificando `/etc/crontab`. Lo saprete benissimo da tutti i miei corsi, compreso il corso LPI 101 e 102, o il corso Linux Sessions, forse ne parlo anche lì, e sicuramente ne parlo anche nel mio corso Arch Linux per comuni mortali. Questa è una delle poche argomenti che sono talmente mainstream che se non me ne avete già visto parlare in altri 100 video su YouTube, sicuramente è parte comune di tutti i miei corsi, che diversamente sarebbero molto diversi come programma. Arch Linux per comuni mortali è molto orientato al desktop e al troubleshooting, a come acquisire una metodologia per risolvere i problemi. Quelli marchiati LPI sono orientati alle certificazioni professionali, più nello specifico, l'LPIC Essentials è per uso professionale, però come utente. Mentre LPIC 1 è per System Administrator di primo livello. Quindi sono percorsi abbastanza ortogonali tra di loro. E qualcuno ogni tanto mi chiede: "Come scegliere il mio livello di partenza? Come scegliere il corso?". E quant'altro. Fatevi un giro su corsolinux.com, perché verso in fondo alla pagina, dopo aver presentato tutti i corsi, ci sono un paio di schemi che vi aiuteranno a decidere il percorso, determinare quello che fa più per voi. Però questo per dire, dato che ho divagato abbastanza, che `crontab` è una di quelle competenze che acquisite in qualunque percorso, perché sono proprio le basi basi basi dell'utilizzo di un sistema Linux. Ma sono sicuro che molti di voi, se mi seguono da un po' più di un paio di settimane, mi avranno visto utilizzarlo in altri momenti. Ciò nonostante, facciamo una piccola panoramica di questo file, che può sembrare strano a livello di sintassi, ma è commentato anche qui e quindi un pochino aiuta. Ci sono una serie di numerini, di asterischi, separati da degli spazi. Ognuno di questi si riferisce a un intervallo di tempo diverso, ad esempio: minuto per la prima colonna, ora seconda colonna, giorno del mese, mese, giorno della settimana, l'utente che deve eseguire il comando, e comando da eseguire. Cosa significa questo comando qua, lo spiego nei miei corsi, ma non è importante in questo momento. Quello che invece è importante in questo momento è questo qui, quello che andiamo a inserire noi, che dice che ogni minuto, ogni ora, ogni giorno della settimana, eccetera eccetera eccetera. Se fate caso che non è proprio allineato a regola d'arte, non fa niente. L'utente `root` esegue `sanoid --cron`. `sanoid` invocato con `--cron` dice: "Guarda, ti sto chiamando da cron per eseguire le operazioni pianificate". Niente di più, niente di meno. E questo `TZ=UTC` significa `timezone=UTC`. Hanno scelto di impostare questa variabile in modo che non venga fatta distinzione tra ora solare e ora legale quando c'è il passaggio.

Salviamo ed usciamo. E a questo punto non ci resta che aspettare, oppure potremmo forzare la cosa scrivendo `sanoid --cron` la prima volta, in modo da triggerare il primo evento in cui effettivamente verrà creato il primo snapshot. E poi, a seconda di come l'abbiamo configurato, ad esempio qua: massimo 36 backup orari, andrà a creare uno snapshot ogni ora, mantenendo gli ultimi 36. Quindi, se adesso faccio `zfs list -t snapshot` (che si poteva abbreviare con `snap`, by the way), ecco che per tutti i volumi per cui ho impostato lo snapshot, questo che c'è da prima, e questo qua che ho creato adesso, sono già stati creati relativi snapshot. Ovviamente, quello orario, quello giornaliero, quello mensile corrispondono e coincidono perché è la prima istanza. Poi ne vedremo molti più orari che non gli altri, come anche in questo caso. E fate caso a come si chiamano questi snapshot. Hanno una nomenclatura molto particolare: `auto-snap-mese-giorno_ora:minuti:secondi-tipologia` (mensile, giornaliero, orario, eccetera eccetera). Perché ve lo sto dicendo? Perché è importante per il passaggio successivo, ovvero configurare Samba per dirgli: "Guarda, gli snapshot si trovano qui, hanno questa nomenclatura".

Per fare ciò, dobbiamo ovviamente spostarci a questo punto nel container Samba e andiamo a modificare il file `/etc/samba/smb.conf`. In cima a tutto quanto, possiamo andare ad aggiungere direttamente sotto `[global]` una serie di voci: `vfs objects = shadow_copy2`, e `catia`. `catia` lo usiamo per configurare dei mapping nei nomi, perché purtroppo nella nomenclatura che vi ho fatto vedere c'erano dei due punti. Vi ricordate? Quelli lì sono dei nomi che non sono compatibili con i path di Windows, vanno a creare il casino. Quindi dobbiamo sostituire i due punti con dei trattini bassi o qualcos'altro che sia compatibile. E questa roba qua, ovviamente, la copio incollata da qualche parte sull'internet. Se ritrovo la sorgente, ve lo metto in descrizione. Ma sostanzialmente dice di sostituire, appunto, questi caratteri. E poi configuriamo il modulo `shadow_copy`. Diciamo: "Lo `snapdir` è appunto `zfs-snapshot`". Non ci credete? Ve lo faccio vedere in un attimo. Vi ricordate `zfs list`? Perfetto. Se io vado in uno di questi percorsi, ci vado per davvero, diciamo. Questo ultimo che abbiamo creato `/tank/share/cacca`. Perfetto. Mi ci sposto dentro. Ora, io qua anche con `ls -la` non vedo niente, ma in realtà ZFS ha un trucchetto. Ha una cartella così nascosta che non si vede neanche con `ls -la`. Infatti, se faccio `ls .zfs` (che non si vedeva qua), in realtà guardate un po': `shares` e `snapshot`. Vediamo cosa contiene `snapshot`. Voilà, esattamente la stessa nomenclatura che vi ho fatto vedere prima, con questi qua che Windows non li capirà mai e dobbiamo sostituirli con `catia`. Quindi, sì, è corretto dire che rispetto alla radice del volume, `.zfs/snapshot` è il percorso dove si trovano gli snapshot. Sono pedissequo perché voglio che capiamo quello che stiamo facendo. Abbiamo usato uno script per buttar su tutto il container, che abbiamo risparmiato abbastanza tempo, perché quello ormai è una parte che recupero banale, visto che l'ho coperta in mille altri corsi e video precedenti. Però almeno quello che c'è di nuovo, lo spieghiamo, così se qualcosa si dovesse rompere, sapete come funziona sotto la scocca, sapete, avete già un'idea del perché potrebbe essersi rotto e sapete dove mettere le mani per iniziare a ripararlo. Il resto dei parametri ve li incolla la veloce, così facciamo un po' prima. Qui non è importantissimo. Ordinamento discendente, e vabbè. Formato, questo è importante perché deve corrispondere alla nomenclatura dei nostri snapshot. Guardate, c'è un prefisso `auto-snap`, ed effettivamente ce l'abbiamo. Poi c'è trattino, ce l'abbiamo. Anno, perfetto. Trattino, mese, ok. Trattino, giorno, trattino, ore, minuti, secondi. E in questa maniera qua, lui riesce a capire che questi sono da presentare a Windows tramite Shadow Copy.

Quindi, salviamo questa configurazione e usciamo. Ultima cosa: riavviamo il servizio di Samba. E questo è tutto. Ora abbiamo gli snapshot configurati. Ogni ora viene creato un nuovo snapshot e se modifichiamo dei file in una condivisione Samba da qualunque client Windows, possiamo andare a esplorare le versioni precedenti, aprire al volo o ripristinarle a una versione precedente. Ovviamente, la stessa cosa si può fare anche con Linux, è più semplice sul file system in sé che non tramite una condivisione Samba. Lasciamo stare per una volta. Riconosco che mi piacerebbe davvero avere un'interfaccia simile su Linux, ma si fa quel che si può.

Io spero che questo video vi sia stato utile. Se è così, mettete mi piace, condividete, fate tutte quelle classiche cose che si fanno sui social per supportarmi. Grazie per essere stati con me e ci vediamo al prossimo video.

[Musica]