Script sostitutivo di Dropbox

[mirko.pagliai]

Salve a tutti,

sto scrivendo uno scriptino bash per i computer della mia lan affinché, con la presenza di un piccolo serverino domestico targato Debian che sia di appoggio, venga emulata grosso modo la funzionalità offerta da Dropbox.

Non vi posto lo script, perché è ancora parziale e perché il quesito che pongo è solo concettuale. Vi dico però che ho deciso di ricorrere all'accoppiata rsync+ssh. Probabilmente potrei utilizzare il demone di rsync, ma se ho capito bene (soltanto in quest'occasione mi sono fatto una lettura approfondita del manuale, nonostante lo utilizzi da un bel po') il risultato è identico, cambiano solo gli agenti nel contesto.

Il mio dilemma nasce dal funzionamento di rsync. Che (se ho ben capito, correggetemi):
1) permette di sincronizzare indefinite sorgenti con una e una sola destinazione;
2) permette di sincronizzare le sorgenti con la destinazione (e non e, cioè è a senso unico, solo la destinazione può essere aggiornata).

Qui sta la questione. Ne consegue che quella che dovrebbe essere chiamata "sincronizzazione" è in realtà una fase "di lettura" più una fase "di scrittura" (per ora non puntualizzo sull'ordine tra le due). Cioè sincronizzo dal server (perché altri client potrebbero aver apportato cambiamenti) e sincronizzo verso il server (per apportare i miei cambiamenti).

Primo problema. Si suppone che per comodità sul server sia presente un'unica directory (es: /var/backup/) per accogliere tutti i file in questione.
Sincronizzando verso il server il problema non si pone: posso indicare tutti i file sorgente che desidero e come destinazione la sola /var/backup/.
Il problema si pone invece al contrario, cioè sincronizzando dal server: posta che la sorgente sarà /var/backup/, cosa imposto come destinazione, sapendo che ne posso impostare una e soltanto una?
Posso impostare solo un'unica cartella, appunto e appunto come mi pare avvenga con Dropbox (ammesso che tutti i file da sincronizzare non siano anche nel client in un'unica). Sì che posso creare dei link simbolici nell'unica cartella, ma altre soluzioni? Possibile non ce ne sia?

Secondo problema, il più grave. Prima la fase "di lettera" ("dal server") o prima la fase "di scrittura" ("verso il server")?
Il problema qui sta nell'opzione --delete, che cancella nella destinazione i file non più presenti nella/e sorgente/i e che è necessario per una vera sincronizzazione. Si traduce così:
1) se viene prima la fase "di lettura" -> i client sono tutti sincronizzati. Da un client cancello un file, ovviamente lo stesso dovrà accadere prima sul server, poi sugli altri client (è quello che mi aspetto). Ma se eseguo prima la fase "di lettura", andrò a riscaricare quel file, quindi nella "fase di scrittura" verrà confermato e quindi rimarrà intoccato;
2) se viene prima la fase "di scrittura" -> i client sono tutti sincronizzati. Da un client cancello un file, quindi questo verrà correttamente cancellato sul server perché avviene prima la fase "di scrittura".
Ma quando andrò a sincronizzare un secondo client, questo andrà a riscrivere il file (perché ancora presente), perché avviene prima la fase "di scrittura", e poi verrà confermato nella fase "di lettura" (certo, è stato ricreato sul server da un altro client!).

Suggerimenti? Indizi? Non ho capito niente io? Come si può organizzare un simile lavoro?

Grazie :-)

[pmate]

Perchè rsync e non unison?

Ti segnalo comunque questo thread. Si fa riferimento ad un progetto hostato su sourceforge che si prefigge i medesimi tuoi obiettivi.

Per quanto riguarda le questioni che hai posto:

Il problema si pone invece al contrario, cioè sincronizzando dal server: posta che la sorgente sarà /var/backup/, cosa imposto come destinazione, sapendo che ne posso impostare una e soltanto una?

Con rsync puoi usare il parametro -R per specificare il path delle directory che ti interessano.
Se l'albero dei file/dir da sincronizzare lo specifichi in quel modo esso verrà rispettato a destinazione *sotto* la dir di destinazione (c'è anche il parametro --include-from=file ma non so se faccia la stessa cosa).

Sul server finiresti per avere qualcosa del genere:

Codice: Seleziona tutto

/var/backup/file1
/var/backup/etc/resolv.conf
/var/backup/home/mirko/pippo.txt



Ma non credo che sia molto pratico per quello che ti serve.

Dai un'occhiata a rsyncbackup, potrebbe essere d'ispirazione.

Secondo problema, il più grave. Prima la fase "di lettera" ("dal server") o prima la fase "di scrittura" ("verso il server")?

Unison!

Rsync a mio parere è utilissimo quando sincronizzi lungo una sola direttrice (ad esempio per procedure di backup).
Quando invece hai bisogno di un sync bidirezionale (come credo di aver capito) forse è meglio (sempre a mio parere) ricorrere ad altro.

Ciao,
pmate

[mirko.pagliai]

Perchè rsync e non unison?

Ne avevo sentito parlare. Avevo datto un'occhiata "superficiale", arrivando alla conclusione che "è un clone di rsync". Evidentemente mi sbaglio, studierò ancora :-)

Ti segnalo comunque questo thread. Si fa riferimento ad un progetto hostato su sourceforge che si prefigge i medesimi tuoi obiettivi.

Sì, visto che questo, sto seguendo anche se non ho ancora dato un'occhiata ai sorgenti. Ad ogni modo, non è questo il problema, tant'è che continuerò ad utilizzare Dropbox per il più delle cose. La scrittura di questo script è dovuta a:
1) esercitazione;
2) oltre Dropbox, oltre altri prodotti (basta cercare per trovare, alcuni anche open) mi rimangono una manciata di MB di file con contenuti riservatissimi (quello criptato di keepassx con password e carte di credito, documenti aziendali, la configurazione di filezilla che contiene le password ftp, ecc. ecc.) che vorrei venissero sincronizzati con una procedura a me nota al 100%, per avere tutte le certezze del caso.
Sì, certo, per quanto riguarda il punto 2) basterebbe utilizzare uno dei tanti prodotti open a disposizione, mentre per il punto 1) ci sono tanti ambiti cui applicarsi per esercitarsi con bash e *unix. L'unione delle due cose mi ha portato a questo lavoretto :-)

Il problema si pone invece al contrario, cioè sincronizzando dal server: posta che la sorgente sarà /var/backup/, cosa imposto come destinazione, sapendo che ne posso impostare una e soltanto una?

Con rsync puoi usare il parametro -R per specificare il path delle directory che ti interessano.
Se l'albero dei file/dir da sincronizzare lo specifichi in quel modo esso verrà rispettato a destinazione *sotto* la dir di destinazione (c'è anche il parametro --include-from=file ma non so se faccia la stessa cosa).

Sul server finiresti per avere qualcosa del genere:

Codice: Seleziona tutto

/var/backup/file1
/var/backup/etc/resolv.conf
/var/backup/home/mirko/pippo.txt



Ma non credo che sia molto pratico per quello che ti serve.

Sperimenterò. Ma credo non risolva comunque il problema, ma semmai sia l'ennesimo escamotage per aggirarlo, piuttosto che per risolverlo.

Secondo problema, il più grave. Prima la fase "di lettera" ("dal server") o prima la fase "di scrittura" ("verso il server")?

Unison!

Rsync a mio parere è utilissimo quando sincronizzi lungo una sola direttrice (ad esempio per procedure di backup).
Quando invece hai bisogno di un sync bidirezionale (come credo di aver capito) forse è meglio (sempre a mio parere) ricorrere ad altro.

Come avevo intuito e come avevo temuto. Evidentemente è proprio rsync che non fa al caso mio, visto che necessito appunto un sync bidirezionale, come tu affermi. Vedrò se unison fa al caso mio.

Intanto, grazie mille :-)

[mirko.pagliai]

Ti segnalo comunque questo thread. Si fa riferimento ad un progetto hostato su sourceforge che si prefigge i medesimi tuoi obiettivi.

Sì, visto che questo, sto seguendo anche se non ho ancora dato un'occhiata ai sorgenti.

Ecco infatti cosa fa il programma in questione (direttamente dal sorgente):

Codice: Seleziona tutto

   rsync -avz --delete -e ssh $USERNAME@$SERVER:~/MyBox/ $MYBOX
   rsync -avz --delete -e ssh $MYBOX $USERNAME@$SERVER:~/MyBox/


Come si sospettava! :-)


EDIT: oggi ho visto anche altri programmi. E sono arrivato a una conclusione: probabilmente non esiste un'alternativa a Dropbox. Che faccia lo stesso lavoro, dico.
Tutti gli script che si propongono come tali - non me ne voglia nessuno, per carità - non hanno nulla a che vedere con Dropbox: loro sincronizzano un client con un server, mentre Dropbox sincronizza dei client tramite un server. Che è una cosa un po' diversa.

E che io non riesco ancora a capire come sia possibile. Concettualmente, dico, lasciamo perdere per un attimo le righe di codice...

Il sospetto è quello che l'approccio alla questione (sono due giorni che mi sto bruciando il cervello su questa cosa) è che sia proprio sbagliato. È lo schema logico ad essere proprio un altro...

[GipPasso]

Non penso sia nulla che un buon software di gestione delle versioni possa fare. Ci sono software come rdiff-backup che consentono proprio di avere copie incrementali fino a un tempo indietro specificato (per non fare esplodere la dimensione) e che usano rsync alla base.

Dropbox, a parte cose come quelle citate nella sua pagina su wikipedia

In early July 2011 Dropbox revised their Terms of Service several times after first including language that appeared to give them an unrevokable license to any material uploaded. They subsequently clarified that language in response to the maelstrom of criticism and concern that resulted from artists and corporate users with confidential data.[79]

non fa altro che sincronizzare sui client quello che è sincronizzato precedentemente sul server. È esattamente quello che fanno git, rsync (con le opportune opzioni).

Bisogna semplicemente sincronizzare il client su cui si sta per avviare l'applicazione a cui servono i dati aggiornati, in tempo utile. Si possono per esempio far girare script di aggiornamento all'autenticazione (con pam) o dopo una certa azione dell'utente (magari quando si chiude l'ultima finestra del browser con le donnine e si sta finalmente cominciando a lavorare...).

Se siete interessati si può usare questa discussione per ricostruire con software accettabile le caratteristiche di quell'obbrobrio. Sarebbe d'interesse e si genererebbe una bella guida. Se si arrivasse a pubblicare qualcosa sull'argomento, intimo fin d'ora, non dovrà essere mai citato quella cloaca dove la gente deposita anche pagando ciò che ha di più prezioso. Un buon sistema di sincronizzazione non è "simile a ...", è, puramente, un buon sistema di sincronizzazione.
Io per iniziare sponsorizzo lo spulciare il manuale di rsync, perché penso ci siano molte opzioni poco conosciute che fanno da sole, ciò che serve alla sincronizzazione su server di dati modificate da più fonti (a livello semplice, non certo come i fork di git).

N.B.: scusate se sono livoroso, ma odio questi servizi che si appropriano dei dati dei gonzi che ce li mettono su, come quelli di moda anni fa per le foto o la posta.

GipPasso

[Risca]

Se siete interessati si può usare questa discussione per ricostruire con software accettabile le caratteristiche di quell'obbrobrio. Sarebbe d'interesse e si genererebbe una bella guida. Se si arrivasse a pubblicare qualcosa sull'argomento, intimo fin d'ora, non dovrà essere mai citato quella cloaca dove la gente deposita anche pagando ciò che ha di più prezioso. Un buon sistema di sincronizzazione non è "simile a ...", è, puramente, un buon sistema di sincronizzazione.
Io per iniziare sponsorizzo lo spulciare il manuale di rsync, perché penso ci siano molte opzioni poco conosciute che fanno da sole, ciò che serve alla sincronizzazione su server di dati modificate da più fonti (a livello semplice, non certo come i fork di git).

Pronto a partecipare!

Il problema secondo me non è tanto nella parte del programma dedicata alla sincronizzazione (pensa rsync o tutti quelli che si basano su esso come il mitico unison) quando alla sincronizzazione lanciata in automatico o all'aggiunta di un file o al salvataggio/modifica di un file. Secondo me si potrebbe risolvere il problema con un opportuno scriptino in cron oppure utilizzando una interfaccia in python per la gestione della cartella da sincronizzare. Che ne dite?
Secondo me la soluzione migliore sarebbe utilizzare un demone, proprio come fa Dropbox.

Quando si inizia?

note: unison è già una soluzione al problema siccome, basandosi su rsync, fa già quanto descritto da GipPasso in modo più che ottimale. Infatti lo sto già datempo utilizzando con la stessa logica di dropbox: sincronizzazione tra diversi computer passando per un server centrale.

[Stemby]

Segnalo che c'era già aperta anche questa discussione: viewtopic.php?f=15&t=43653

Ciao!

[mirko.pagliai]

Non penso sia nulla che un buon software di gestione delle versioni possa fare. Ci sono software come rdiff-backup che consentono proprio di avere copie incrementali fino a un tempo indietro specificato (per non fare esplodere la dimensione) e che usano rsync alla base.
[...]
Bisogna semplicemente sincronizzare il client su cui si sta per avviare l'applicazione a cui servono i dati aggiornati, in tempo utile. Si possono per esempio far girare script di aggiornamento all'autenticazione (con pam) o dopo una certa azione dell'utente (magari quando si chiude l'ultima finestra del browser con le donnine e si sta finalmente cominciando a lavorare...).

Ho spulciato con attenzione il manuale di rsync, ma non ne sono venuto a capo.
Ammetto d'altronde di non conoscere approfonditamente altro software da te citato in questa discussione. Motivo per cui dovrò documentarmi a dovere :-)

Se siete interessati si può usare questa discussione per...

Più che interessato. E disponibile a un lavoro di gruppo, semmai si prospettasse questa possibilità.

Io per iniziare sponsorizzo lo spulciare il manuale di rsync, perché penso ci siano molte opzioni poco conosciute che fanno da sole, ciò che serve alla sincronizzazione su server di dati modificate da più fonti (a livello semplice, non certo come i fork di git).

Qui ribadisco: per quanto riguarda Rsync, non sono arrivato a nulla di utile. Anzi, sono giunto alla conclusione che non è lo strumento più adeguato per questo genere di necessità. Ma - chiaro - posso sbagliarmi o aver svolto una ricerca mal impostata.

[skizzhg]

Però nessuna soluzione mi pare alla pari con dropbox, anche SparkleShare non è male ma chi è in grado, può o ha voglia di tirarsi su un server http per tenere una cosa del genere? E se così fosse non vedo ragione di usare un sistema simile.
Lo scopo di dropbox e altri è quello di avere qualcosa facile da usare con due click e uno spazio remoto, c'è chi dirà "io non mi fido di far tenere roba ad altri"; e allora insieme al vostro server locale muore qualsiasi concezione di hosting remoto (ce ne sono a ciuffi basati su git ad esempio), che non deve essere l'unico backup ma può esserne uno aggiuntivo in caso di catastrofe, flumini, terremoti, disastri aerei.

[Risca]

Lo scopo di dropbox e altri è quello di avere qualcosa facile da usare con due click e uno spazio remoto, c'è chi dirà "io non mi fido di far tenere roba ad altri"; e allora insieme al vostro server locale muore qualsiasi concezione di hosting remoto (ce ne sono a ciuffi basati su git ad esempio), che non deve essere l'unico backup ma può esserne uno aggiuntivo in caso di catastrofe, flumini, terremoti, disastri aerei.

Si potrebbe comprare un server personale da dedicare allo scopo oppure utilizzarne uno (fosse anche quello di dropbox) ma criptando tutto da lato client, ossia rendendo di fatto inaccessibili i dati a terzi. Ed ecco così che risca salvò il concetto di hosting remoto...

[pmate]

Il problema secondo me non è tanto nella parte del programma dedicata alla sincronizzazione (pensa rsync o tutti quelli che si basano su esso come il mitico unison) quando alla sincronizzazione lanciata in automatico o all'aggiunta di un file o al salvataggio/modifica di un file.

Quello non è un gran problema.
Ci sono tools come incron (Edit--- o come inosync oppure lsyncd) che cadono assolutamente a fagiolo (esempio).
Bastano due-righe-due di script che si occupi della sincronizzazione tra la directory locale e quella remota (con rsync, con unison, etc.) e che venga invocato appunto da incron ad ogni modifica della directory locale.

Credo che "costruirsi" un aldiavolodropbox.deb sfruttando gli strumenti di cui si sta parlando non sia affatto complicato e che possa soddisfare con poco sforzo l'esigenza all'origine di questa discussione.


pmate

[mirko.pagliai]

Quindi, se ho capito bene, a questo punto fase di lettura e fase di scrittura sarebbero tra loro indipendenti, nel senso che l'una non invoca l'altra. Ma:

1) fase di scrittura: un demone verifica i cambiamenti sul filesystem. Quando rilevati, la fase viene avviata;
2) fase di lettura: lanciata semplicemente tramite cron, a scelta dell'utente.

[pmate]

Ni:
1) fase di lettura ---> all'avvio del programma sync della dir locale con la dir sul server
2) fase di scrittura ---> ad ogni cambiamento nel filesystem sync con la dir sul server

Con incron+unison risulta molto semplice, basterebbe inserire (fase 2) con incrontab -e questa riga:

Codice: Seleziona tutto

/path/dir/locale IN_ALL_EVENTS /usr/bin/unison [args] /path/dir/locale /path/dir/remota


Ad ogni cambiamento nella dir locale viene eseguito il comando relativo ad unison.
Se a questo accoppi una istruzione che (ad esempio) all'avvio della sessione utente lanci questo comando:

Codice: Seleziona tutto

/usr/bin/unison [args] /path/dir/locale /path/dir/remota


ti ritrovi sin dall'inizio con le dir sincronizzate e con incron che è lì che aspetta eventuali cambiamenti per propagarli alla dir remota.

Intendevi fare questo?

pmate

[mirko.pagliai]

Sì, però:

1) fase di lettura ---> all'avvio del programma sync della dir locale con la dir sul server

Che succede se, mentre il programma è in esecuzione, quindi è già stato lanciato, quindi ha già fatto al sincronizzazione all'avvio, un altro client apporta modifiche al server?
Dovrei aspettare fino al successivo riavvio del programma (probabilmente il successivo riavvio della macchina) prima di essere nuovamente sincronizzato, no?

[pmate]

Ah ok, non avevo colto: devi prevedere la possibilità che più client in contemporanea accedano a quella dir sul server.
Beh, così di getto mi verrebbe da pensare ad una istruzione incron anche sul server: non appena qualcosa cambia nella dir si avvia una istruzione unison che faccia il sync delle directory.

Certamente in questo caso la cosa un pizzico si complica e deve essere studiata con un pò più di attenzione ma ritengo che quella di incron+unison o magari di lsyncd siano delle strade più che percorribili.

Domanda (causa mia ignoranza in materia): con dropbox è possibile che più client siano autenticati contemporaneamente?


pmate