Samba & secure backup(s)

Shotokan - venerdรฌ 22 febbraio

Avete una macchina linux con dischi in raid1 o altro su cui salvate i dati in modo ‘lossless’?
Creare una samba share e’ una buona soluzione per permettere agli utenti nella lan di salvare i dati in modo sicuro.
..Ma che succede se invece di avere problemi di perdita dati ‘hardware-related’ e’ proprio il software che stiamo usando (un gestionale? un downloader per .gif di gattini su icanhas.cheezburger.com?) che magari salva i dati su dei database .sqlite ad avere problemi di stabilita’?
Salvare i dati in una sola copia equivarrebbe a perdere tutti i dati, ma salvarli in multiple copie e lasciare all’utente la possibilita’ di eliminarli e’ altrettanto stupido.
Vediamo un sistema per creare dei backup sicuri ed accessibili all’utente ๐Ÿ˜‰

Samba secure backup

Situazione iniziale:
Samba installato, e password inserite per gli utenti samba.
(smbpasswd -a user)
Ok, iniziamo ๐Ÿ˜‰

L’utente che andremo a prendere in considerazione e’ l’utente ‘test’, con home (share samba) situato in /home/test .
La prima cosa da ricordarsi, in caso di dominio con accesso SSH e’ di negare l’accesso all’SSH per gli utenti samba (a meno che non sia esplicitamente richiesto!)
Una buona soluzione sarebbe bloccare direttamente il gruppo degli ‘utenti samba’ tramite l’sshd_config, ma potrebbe rompere in caso di eccezioni, e se non avete voglia di toccare quel config una soluzione semplice e rapida e’ disabilitare l’accesso alla shell direttamente da /etc/passwd.

Vediamo di default a cos’ha accesso il nostro utente test:


utente test, con home in /home/test ed accesso alla shell /bin/sh.
apriamo il file /etc/passwd e semplicemente sostituiamo a quella riga:


con:


(al posto di /bin/sh potrebbe esserci /bin/bash o altro, sostituiteli in ogni caso con /bin/false)

Ottimo, ora l’utente non puo’ connettersi via SSH: ora vediamo di impostare un backup sicuro ๐Ÿ˜‰
Presupponiamo che l’utente tenga nel disco di rete numerosi file, tra video, mp3 ed altro.
Ha senso effettuare un backup ogni volta degli stessi file? No.

  1. i file non vengono riaperti in scrittura ogni volta, ergo non abbiamo dovremmo avere corruzione dati software-related.
  2. effettuare un backup di un HDD pieno di video e’ insensato, e riempirebbe il raid in poco tempo.

Lasciamo quindi all’utente la sua cartella ~ per caricarsi tutti i file che vuole, andremo a fare il backup solo di una sottocartella (dove l’utente puo’ salvare documenti importanti, ecc)

ATTENZIONE: TUTTI I PROSSIMI COMANDI SONO DA ESEGUIRE COME UTENTE ROOT.
TUTTI.

Ok, procediamo col creare una sottodirectory dove memorizzare la directory con i dati importanti, e la directory con i backup.


Ottimo, ora l’utente test ha pieno accesso a ~/secure ed ~/secure/data, mentre ha solo accesso in lettura/esecuzione per i file presenti in ~/secure/dailybk (che ha come owner root)

Ora supponiamo di voler eseguire un backup ogni ora ma salvando solo una copia per giorno, tenendo i backup per massimo una settimana. (i file delle 16:00 sovrascriveranno i file delle 15:00, i file del lunedi’ sovrascriveranno i file del lunedi’ precedente etc..)
Ecco qui uno script che ho scritto appunto per quest’evenienza:


…ed andiamo a salvarlo in /home/test/secure/dailybk/ come ‘backupper’ (importante! in un’altra directory l’utente potrebbe cancellarlo per errore!)

Lo script salva i dati in delle cartelle numerate da 0 a 6 (domenica=0, lunedi’=1…sabato=6) sovrascrivendoli in automatico all’evenienza.

diamogli quindi i permessi di esecuzione (non quelli di scrittura!!!):


Ora bisogna aggiungere lo script in esecuzione automatica ogni ora, in modo che esegua i backup in modo automatizzato.
Per farlo eseguite:


vi si aprira’ una schermata di nano, scorretela fino in basso con PAG↓ e inserite alla fine della pagina questa riga:


che verra’ semplicemente eseguita ogni ora (0 *).
Ottimo!
Cosa vedra’ ora l’utente?

Accedendo al suo share samba trovera’ tutti i suoi dati, e la cartella share.
Accedendo alla cartella share potra’ aggiungere e modificare dati in share/data/ ma NON in share/dailybk/ dove il sistema gli restituira’ un tristo permission denied ๐Ÿ˜‰ (il crontab in questo caso viene eseguito da root, ergo i file creati sono di proprieta’ di root e con una maschera 755 ovvero: -rwxr-xr-x.
I permessi dell’utente test sui file di backup saranno quindi:
r-x (read, execute)

Njoy ๐Ÿ˜‰

Theme made by Koala