Script sostitutivo di Dropbox

mirko.pagliai · Messaggio da **mirko.pagliai** » 07/09/2011, 12:02

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

Sì, certo :-) È necessario un account per poter utilizzare il servizio, ma lo stesso discerne perfettamente tra più client autenticati con le stesse credenziali. In altri termini, ad un'unica autenticazione è possibile associare più di un client e l'autenticazione può avvenire contemporaneamente.

Infatti, quello che sostenevo fin dall'inizio è che Dropbox non fa una "sincronizzazione tra un client e un server", per la quale probabilmente basterebbe anche solo rsync e che è quello che fanno (o meglio: a cui si limitano) tutti gli altri programmi che si propongono come alternativa a Dropbox, bensì una "sincronizzazione tra più client", dove il server fa solo "da appoggio".

pmate · Messaggio da **pmate** » 07/09/2011, 12:22

mirko.pagliai ha scritto:Infatti, quello che sostenevo fin dall'inizio è che Dropbox non fa una "sincronizzazione tra un client e un server", per la quale probabilmente basterebbe anche solo rsync e che è quello che fanno (o meglio: a cui si limitano) tutti gli altri programmi che si propongono come alternativa a Dropbox, bensì una "sincronizzazione tra più client", dove il server fa solo "da appoggio".

Mah, che io sappia in dropbox il server conserva fisicamente i dati oltre che a fungere da appoggio. Non mi sembra marginale e non si spiegherebbero altrimenti le limitazioni di spazio e le differenziazioni tra account free e a pagamento.
Esistono prodotti che questa architettura la evitano a prescindere (ovvero nessun server centrale), ad esempio tonido. Dropbox non mi sembra della stessa tipologia.

La sincronizzazione tra due directory certamente la puoi fare semplicemente con rsync+cron ma se hai bisogno dell'istantaneità, della sincronizzazione giusto un attimo dopo che una modifica a quella porzione di filesystem si è verificata... hai bisogno anche di altro. Stesso discorso se necessiti di sincronizzazione "bidirezionale".

pmate

mirko.pagliai · Messaggio da **mirko.pagliai** » 07/09/2011, 12:27

No no, con "di appoggio" intendevo dire che la finalità è *anche* (dico anche perché ovviamente si è anche liberi di utilizzarlo per backup) quella di sincronizzare i client e che quindi questo compito viene svolto dal server, eventualmente anche conservando i file, come infatti avviene con Db. C'eravamo capiti, non intendevo strettamente "i dati si limitano solo a passare da lì" ;-)
Nei prossimi giorni comincio a buttare giù qualche riga intanto.

Sarebbe carino prevedere oltre al più classico ssh anche l'ftp, visto che tanti hanno a disposizione un qualche dominio con solo accesso ftp. Se possibile, ovviamente.

mirko.pagliai · Messaggio da **mirko.pagliai** » 07/09/2011, 17:47

Cominciamo.
Qualche risorsa:
http://www.cis.upenn.edu/~bcpierce/unis ... anual.html

In particolare, guardare quanto dice a proposito dei socket, per vedere se si può andare oltre ssh:
http://www.cis.upenn.edu/~bcpierce/unis ... socketmeth

A proposito delle opzioni:
http://www.cis.upenn.edu/~bcpierce/unis ... html#prefs

A proposito dei profili (utilità mooolto interessante):
http://www.cis.upenn.edu/~bcpierce/unis ... ml#profile

E soprattutto a proposito delle path da sincronizzare:
http://www.cis.upenn.edu/~bcpierce/unis ... l#pathspec
(a me piacerebbe offrire un file del tipo source-files.list, in cui l'utente può elencare - una per riga - le directory da sincronizzare. Il file deve poi essere letto dallo script)

Infine non ci si dimentichi di (tutto il materiale elencato è anche disponibile nella nostra shell):

Codice: Seleziona tutto

man unison
unison --help
unison -doc tutorial | more
unison -doc basics | more
unison -doc failures | more
unison -doc running | more

Questo vorrebbe essere (aehm aehm) una bozza script per la sincronizzazione:
http://pastebin.com/nXT8me1d
Sincronizza dirprova con backup su un server remoto (che in questo è localhost).

Questa è una prova di funzionamento (e funziona...):
http://pastebin.com/cQm9i2AM
(c'è anche la stampa del file di log generato)

Adesso devo tornare a casa e poi andare a una cena. Appena posso... tutte le considerazioni e gli appunti del caso.

p.s. ah, sì. Quegli if annidati sono da snidare. Basta usare exit.

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 11:08

Aggiornamento:
http://pastebin.com/iRbZguf2

Il contenuto di source-files.list, cioè le dir da sincronizzare sul client:

Codice: Seleziona tutto

mirko@mirko-laptop:~$ cat source-files.list 
dirprova
dirprova2

Creo nella mia home la cartella backup, dove verrà appunto fatto il backup, e le cartelle dirprova e dirprova2 (con qualche file dentro) da backuppare:

Codice: Seleziona tutto

mirko@mirko-laptop:~$ mkdir backup
mirko@mirko-laptop:~$ mkdir dirprova
mirko@mirko-laptop:~$ mkdir dirprova2
mirko@mirko-laptop:~$ touch dirprova/file1
mirko@mirko-laptop:~$ mkdir dirprova/a
mirko@mirko-laptop:~$ touch dirprova/a/file2
mirko@mirko-laptop:~$ touch dirprova2/file3

Lancio lo script:

Codice: Seleziona tutto

mirko@mirko-laptop:~$ mirko@mirko-laptop:~$ ./sincro.sh 
mirko@localhost's password: 
Contacting server...
mirko@localhost's password: 
Connected [//mirko-laptop//home/mirko -> //mirko-laptop//home/mirko/backup]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
	/home/mirko
	//mirko-laptop//home/mirko/backup
This can happen either
because this is the first time you have synchronized these roots, 
or because you have upgraded Unison to a new version with a different
archive format.  

Update detection may take a while on this run if the replicas are 
large.

Unison will assume that the 'last synchronized state' of both replicas
was completely empty.  This means that any files that are different
will be reported as conflicts, and any files that exist only on one
replica will be judged as new and propagated to the other replica.
If the two replicas are identical, then no changes will be reported.

If you see this message repeatedly, it may be because one of your machines
is getting its address from DHCP, which is causing its host name to change
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME
environment variable for advice on how to correct this.

Donations to the Unison project are gratefully accepted: 
http://www.cis.upenn.edu/~bcpierce/unison

Press return to continue.[<spc>]   Waiting for changes from server
Reconciling changes

local          mirko-laptop       
dir      ---->            dirprova  [f] 
dir      ---->            dirprova2  [f] 

Proceed with propagating updates? [] y
Propagating updates


UNISON 2.32.52 started propagating changes at 12:09:52 on 08 Sep 2011
[BGN] Copying dirprova from /home/mirko to //mirko-laptop//home/mirko/backup
[BGN] Copying dirprova2 from /home/mirko to //mirko-laptop//home/mirko/backup
[END] Copying dirprova2
[END] Copying dirprova
UNISON 2.32.52 finished propagating changes at 12:09:52 on 08 Sep 2011


Saving synchronizer state
Synchronization complete at 12:09:52  (2 items transferred, 0 skipped, 0 failed)

La cartella backup ora aggiornata:

Codice: Seleziona tutto

mirko@mirko-laptop:~$ ls -R backup/
backup/:
dirprova  dirprova2

backup/dirprova:
a  file1

backup/dirprova/a:
file2

backup/dirprova2:
file3

Il file di log creato:

Codice: Seleziona tutto

mirko@mirko-laptop:~$ cat .rsyncremote/080911120937.log 


UNISON 2.32.52 started propagating changes at 12:09:52 on 08 Sep 2011
[BGN] Copying dirprova from /home/mirko to //mirko-laptop//home/mirko/backup
[BGN] Copying dirprova2 from /home/mirko to //mirko-laptop//home/mirko/backup
[END] Copying dirprova2
[END] Copying dirprova
UNISON 2.32.52 finished propagating changes at 12:09:52 on 08 Sep 2011


Synchronization complete at 12:09:52  (2 items transferred, 0 skipped, 0 failed)

pmate · Messaggio da **pmate** » 08/09/2011, 11:23

Ottimo inizio!

Io ho pensato (rielaborando quanto da te scritto) che il tutto potrebbe avere uno schema del genere (lato client ovviamente): http://paste.debian.net/128829/

La struttura dello script è a funzioni, c'è il ricorso ad inotify (incron su una macchina lenta un pò impallava ma non ho approfondito) e ad un file di configurazione (è molto più semplice per l'utente finale impostare lì i parametri).
Ho anche aggiunto il parametro -batch ad unison per evitare le domande... e ho preliminarmente impostato le chiavi ssh affinchè non ci sia nessuna richiesta di password.
Anche se stilisticamente non è proprio una bellezza (anche qui if a iosa

) e le funzioni siano assolutamente migliorabili, i test sono andati benone.
Mancano ovviamente ancora tante cose e tante altre possono essere migliorate/riscritte ex-novo.

My 2 cents,

pmate

Edit---
mi accorgo solo ora che avevi postato un altro messaggio dopo quello di ieri.
Ciò che ho appena scritto si riferisce a questo: viewtopic.php?f=13&t=44380&p=138502#p138457

Edit2---
alla funzione writeconfig va aggiunta la riga:

Codice: Seleziona tutto

echo 'dirserver="/some/dir/onserver"' >> $HOME/.rsyncremote/config

e conseguentemente nella funzione syncdirs il comando che invoca unison diventa:

Codice: Seleziona tutto

unison $localdir ssh://$user@$server:$port/$dirserver -logfile $logfile -terse $boptions

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 12:25

Grande! :-D Più tardi vedrò io di aggiungere altro.

Una cosa:

pmate ha scritto:Ho anche aggiunto il parametro -batch ad unison per evitare le domande...

In realtà temo che qui ci sia un problema. Facendo qualche prova, mi sembra di capire che -batch evita domande quando non ci sono scelte multiple. Quando invece queste ci sono (es.: dopo la sincronizzazione, prova a cancellare un file dal server, vedrai che poi ti chiede se rinviarlo al server o cancellarlo anche sul client), con -batch salta del tutto e non apporta nessuna modifica (ovvero, nell'esempio di prima, lascia il file solo sul client).

Qui bisogna lavorarci... ho spulciato un po' di manuali, guide e forum ma non ne sono ancora venuto a capo.

pmate · Messaggio da **pmate** » 08/09/2011, 12:42

Uhm, sicuro?

Ho appena fatto un tentativo e guarda che succede:

Codice: Seleziona tutto

pmate@debian:~/scripts$ ./rsyncremote
Setting up watches.  
Watches established.
/home/pmate/test1/ CREATE ciccio.txt
new file ---->            ciccio.txt  
         <---- deleted    filedel.txt  
[BGN] Copying ciccio.txt from /home/pmate/test1 to //debian//home/pmate/test2
[END] Copying ciccio.txt
[BGN] Deleting filedel.txt from /home/pmate/test1
[END] Deleting filedel.txt
Synchronization complete at 13:40:16  (2 items transferred, 0 skipped, 0 failed)
Setting up watches.  
Watches established.

Ecco i passaggi:
- avviato rsyncremote
- creato il file filedel.txt --> replica ok
- stoppato rsyncremote
- cancellato filedel.txt dalla dir test2 (server)
- avviato rsyncremote (qui parte il log in cima a questo post)
- creato file ciccio.txt (giusto per lanciare unison visto che ancora non abbiamo parlato dello script lato server)
- replica ok && rimosso filedel.txt dalla dir test1 (client)

Il tutto senza alcuna domanda aggiuntiva...
Però magari ho capito male quello che intendevi... se così fosse non farci caso: è l'età che galoppa!

pmate

Edit---
Sempre se non ho capito male quello che intendevi, basta trasformare l'ultimo blocco così:

Codice: Seleziona tutto

# Check if it is first execution
firstexecution
teststuff
syncdirs

# Go go go baby!
while inotifywait -e modify -e create -e delete $localdir; do
    syncdirs 
done

e il problema si risolve visto che all'avvio del programma si avvia una sincronizzazione col server.

Ecco il log di quello che succede:

Codice: Seleziona tutto

pmate@debian:~/scripts$ rm /home/pmate/test2/pippo.txt
pmate@debian:~/scripts$ ./rsyncremote
         <---- deleted    pippo.txt  
[BGN] Deleting pippo.txt from /home/pmate/test1
[END] Deleting pippo.txt
Synchronization complete at 14:13:30  (1 item transferred, 0 skipped, 0 failed)
Setting up watches.  
Watches established.

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 14:19

No no, era proprio questo che intendevo! Boh, strano allora, avrò combinato io qualche errore con i test. Stasera farò un controllò più approfondito delle casistiche possibili.

pmate · Messaggio da **pmate** » 08/09/2011, 15:24

Ok, vediamo che succede allora.

Tra l'altro mi sono accorto di una cosa: inotify va bene per monitorare una directory ma non le sue subdirectory. In pratica se crei una subdirectory la replica è ok ma se subito dopo in quella subdirectory crei un file non succede niente. Il sync avviene solo al successivo avvio dello script.
Il che ovviamente non va bene.

Alternative:
- lsyncd (sempre che sia appropriato per file di grosse dimensioni)
- incron (sempre che non rallenti il sistema --> sospetto però che sia stato il mio muletto/rottame a dare problemi e non incron...)

pmate

Edit---

Aaaaaaargh!

Codice: Seleziona tutto

man inotifywait
-r, --recursive
              Watch  all  subdirectories of any directories passed as arguments.  Watches will be set up recursively to an unlim‐
              ited depth.  Symbolic links are not traversed.  Newly created subdirectories will also be watched.

come non detto... ;D

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 19:40

Ok, aggiornamento della serata.
1) create una cartella. Al suo interno create il file

Codice: Seleziona tutto

source-files.list

Per ogni riga, indicate un file o una directory da sincronizzare con il server, relativamente alla home utente;
2) nella cartella, inserite questi due file:
http://pastebin.com/VTfnh0Cx
http://pastebin.com/eVxwy0fa
Il secondo è il file di configurazione e va settato a dovere.
Il primo è l'eseguibile, bisogna dargli permessi di esecuzione.
Impostate la chiave ssh, sennò impazzite (la variabile per la password, che permette di indicare la password in chiaro, per ora non è ancora supportata. Sta lì soprattutto per ricordarmene...)

Le modifiche più importanti:
- in boptions ho lasciato solo le opzioni "potenzialmente" modificabili dall'utente. Quindi, per intenderci, -auto e -batch le ho tolte da lì, visto che senza queste lo script non funziona;
- una sincronizzazione va lanciata prima di inotify, altrimenti non ci sarà nessuna sincronizzazione prima di una modifica locale successiva al lancio dello script (ad esempio, cosa accadrebbe diversamente se apportassi modifiche prima di lanciare lo script? Non verrebbero subito sincronizzate!);

Per il resto, ho ripulito lo script qua e là.

Qualche nota:
- tralascerei la creazione di un file di configurazione. Se ne potrebbe occupare l'installer, no? Anche se così, uno file per tutto il sistema... boh, non saprei. Una soluzione "più pulita" secondo me sarebbe necessaria. Si potrebbe ad esempio creare uno script ad-hoc per la configurazione, come accade con wvdialconf. Magari interattivo!;
- inotify non rileva correttamente le rinominazioni, che comunque vengono correttamente aggiornate da unison quando lanciato dalla successiva rilevazione funzionante;*
- bisogna aggiungere un po' di output e soprattutto filtrare l'output di unison, per dare all'utente solo le informazioni strettamente necessarie, ovvero solo le nuove sincronizzazioni (in vista di integrare un supporto di notifiche, ad esempio zenity);
- abbiamo detto che puntiamo al .deb. Quindi direi si può togliere il controllo del software installato (anche perché potremmo aggiungere altro, vedi zenity) e per il momento fornire istruzioni sui pacchetti da installare manualmente.

p.s. per quanto avevo temuto qui ha ragione pmate, non ci sono problemi.
p.p.s. che pirla, inotify ha l'opzione --fromfile, quindi non c'era bisogno di "elaborare" il file e passagli i path da controllare. Si può quindi rimuovere qualcosa... domani verificherò.
p.p.p.s. forse è il caso di utilizzare anche l'opzione --timeout? Potrebbe essere utile per far respirare un po' il client - metti caso si fanno larghe modifiche tramite batch, almeno non rischia di impazzire

*
EDIT:
per le rinominazione, modificare (riga 102):

Codice: Seleziona tutto

while inotifywait -r -e modify -e create -e delete $LPATH &> /dev/null; do

in

Codice: Seleziona tutto

while inotifywait -r -e modify -e create -e move -e delete $LPATH &> /dev/null; do

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 20:03

Idea! Chiedo conferma...

Non dovrebbe essere necessario uno script per inviare le modifiche (questo) e un altro da mettere in cronjob per controllare che altri client non abbiano apportato modifiche (da realizzarsi).
Dovrebbe essere invece sufficiente ciclare o quando inotify rileva qualcosa (come accade ora) o dopo uno sleep. Poi unison fa il resto.

Può andare?

pmate · Messaggio da **pmate** » 08/09/2011, 21:11

mirko.pagliai ha scritto:Idea! Chiedo conferma...

Non dovrebbe essere necessario uno script per inviare le modifiche (questo) e un altro da mettere in cronjob per controllare che altri client non abbiano apportato modifiche (da realizzarsi).

A mio parere un secondo script in cronjob non è necessario ma avevo pensato a qualcosa di diverso lato server.
La mia idea è che dopo l'istruzione unison (parliamo lato client) deve seguire un'altra istruzione che esegua uno script sul server (ad esempio in /usr/local/bin) al quale passare dei parametri.

In pratica:

dal client parte unison [param] e avviene il sync
alla connessione ssh e prima del sync (sul server) partirà il file /etc/ssh/sshrc (man sshd) che scrive la coppia di valori utente:ipsorgente (se non esiste già) in uno specifico file del server (ad esempio /etc/rsyncremote/ipconnected.log)
dal client parte la seconda istruzione che lancia lo script in /usr/local/bin del server il quale:
- controlla se in /etc/rsyncremote/ipconnected.log esistono altre coppie valori con lo stesso utente ma con ip diversi (ergo altri client -- stesso utente)
- se esistono tira fuori gli ip e procede al sync per quegli ip

In questo modo è inutile inotify sul server visto che sarebbero i client ad invocare il sync.
Ovviamente in ipconnected.log potrebbero esserci ip in quel momento non attivi ma per questo basta far precedere un controllo al sync degli ip.

mirko.pagliai ha scritto:- una sincronizzazione va lanciata prima di inotify, altrimenti non ci sarà nessuna sincronizzazione prima di una modifica locale successiva al lancio dello script (ad esempio, cosa accadrebbe diversamente se apportassi modifiche prima di lanciare lo script? Non verrebbero subito sincronizzate!);

Sì sì, l'avevo specificato prima nell'edit di questo messaggio: viewtopic.php?f=13&t=44380&p=138534#p138511

mirko.pagliai ha scritto: - tralascerei la creazione di un file di configurazione. Se ne potrebbe occupare l'installer, no? [..] Magari interattivo!;

Sul client ogni utente dovrebbe avere un suo file di configurazione.
La creazione fatta dal mio script era a titolo esemplificativo ma potrebbe anche essere utile nel caso di cancellazione accidentale da parte dell'utente.
Ottima idea l'interattività.

- inotify non rileva correttamente le rinominazioni, che comunque vengono correttamente aggiornate da unison quando lanciato dalla successiva rilevazione funzionante;*

Uh! Non me ne ero accorto.
Ho visto la tua soluzione e mi sembra perfetta.

- bisogna aggiungere un po' di output e soprattutto filtrare l'output di unison, per dare all'utente solo le informazioni strettamente necessarie, ovvero solo le nuove sincronizzazioni (in vista di integrare un supporto di notifiche, ad esempio zenity);

Filtrare l'output nei log? Concordo.
Per il resto a tempo debito (come giustamente dici) ci penseranno le notifiche eventualmente ad avvisare l'utente.

- abbiamo detto che puntiamo al .deb. Quindi direi si può togliere il controllo del software installato (anche perché potremmo aggiungere altro, vedi zenity) e per il momento fornire istruzioni sui pacchetti da installare manualmente.

Concordo ma secondo me al momento gli script devono funzionare "a prescindere".
Alle rifiniture si potrà pensare quando tutto funzionerà per come deve. E quella che proponi è una rifinitura sacrosanta.

pmate

mirko.pagliai · Messaggio da **mirko.pagliai** » 08/09/2011, 23:29

pmate ha scritto: A mio parere un secondo script in cronjob non è necessario ma avevo pensato a qualcosa di diverso lato server.
La mia idea è che dopo l'istruzione unison (parliamo lato client) deve seguire un'altra istruzione che esegua uno script sul server (ad esempio in /usr/local/bin) al quale passare dei parametri.

Io però volevo scartare in modo assoluto qualsiasi lavoro da relegare al server :-D
Per un semplice motivo: limiteresti tutto alla presenza di un server ssh, mentre secondo me è essenziale offrire almeno il supporto ftp, se non poi ad altri come samba o nfs.
Nel caso di ftp - pensavo - sarebbe sufficiente montare in locale prima della sincronizzazione e quindi procedere come se si trattasse di una sincronizzazione (appunto) locale.
L'esigenza si spiega così: la prima necessità che deve offrire lo script è quella di "appoggiarsi" a una propria macchina o presunta tale. E mentre siamo in pochissimi ad avere a disposizione un server (effettivo) con accesso ssh, sono in molti ad avere uno spazio web con solo accesso ftp. Fermo restando che per l'occasione, visto che in questo caso le esigenze sono limitate e per queste esigenze (spazio+ftp), i prezzi sono abbordabilissimi (almeno per chi è disposto a spendere qualche eurino per la propria privacy...) anche per chi non ne ha uno e vuole provvedere.

Comunque, la registrazione degli accessi è cosa che - a prescindere da quanto detto fin'ora - va fatta e credo fattibile, anche nel caso dell'ftp. Ovviamente anche questa andrebbe svolta dal clipeato, che scriverebbe su un apposito file, quindi non proprio attendibilissima. Ma a caval donato...

pmate ha scritto:Sul client ogni utente dovrebbe avere un suo file di configurazione.
La creazione fatta dal mio script era a titolo esemplificativo ma potrebbe anche essere utile nel caso di cancellazione accidentale da parte dell'utente.

Sì sì. Lo script di configurazione interattivo andrebbe lanciato effettivamente dall'utente. Mentre lo script di sincronizzazione, nel momento in cui rileva che non è presente una configurazione, potrebbe chiamare il primo.

pmate ha scritto: Filtrare l'output nei log? Concordo.

Pensavo a filtrare tutto. Unison di suo è molto "verboso" :-D anche se ho aggiunto l'opzione -terse e ho notato che così si limita solo alle informazioni effettive sui file sincronizzati. Informazioni che comunque restano troppo abbondanti.
Lo script di default non dovrebbe stampare nessun output, ma volevo comunque prevedere un'opzione tipo -verbose per permettergli di farlo su richiesta dell'utente, a fini di debug. È proprio per questo che ho messo la funzione printScreen, per regolare a monte l'output a video. Lo stesso vale ovviamente per le attività di logging.

pmate ha scritto: Concordo ma secondo me al momento gli script devono funzionare "a prescindere".
Alle rifiniture si potrà pensare quando tutto funzionerà per come deve. E quella che proponi è una rifinitura sacrosanta.

D'accordo ;-)

p.s. cosa succede se lo script viene lanciano, inotify resta "di guardia" e - per un qualsiasi motivo, anche per scelta dell'utente - cade la connessione? Credo che tutto lo script vada ciclato all'infinito, con una buona pausa (60/120 sec) tra un ciclo e l'altro (tanto verrebbe applicata solo in casi simili), anche perché così lo script potrebbe ripartire dai controlli che includono anche la verifica della connessione.

pmate · Messaggio da **pmate** » 09/09/2011, 8:26

mirko.pagliai ha scritto: Io però volevo scartare in modo assoluto qualsiasi lavoro da relegare al server :-D
Per un semplice motivo: limiteresti tutto alla presenza di un server ssh, mentre secondo me è essenziale offrire almeno il supporto ftp, se non poi ad altri come samba o nfs.

Hai ragione, affidare il tutto al solo protocollo ssh è limitativo.
Non potere contare però su alcune azioni lato server limita molto il raggio di movimento ma l'intento è quello di rendere il tutto il più fruibile possibile ergo azioniamo le meningi e troviamo qualcosa di decente.

Nel caso di ftp - pensavo - sarebbe sufficiente montare in locale prima della sincronizzazione e quindi procedere come se si trattasse di una sincronizzazione (appunto) locale.

Non solo nel caso di ftp ma anche di ssh (per dirne una).
curlftpfs e/o sshfs (+ fuse) fanno egregiamente il proprio lavoro.

Sì sì. Lo script di configurazione interattivo andrebbe lanciato effettivamente dall'utente. Mentre lo script di sincronizzazione, nel momento in cui rileva che non è presente una configurazione, potrebbe chiamare il primo.

D'accordo.

Pensavo a filtrare tutto. Unison di suo è molto "verboso" :-D anche se ho aggiunto l'opzione -terse e ho notato che così si limita solo alle informazioni effettive sui file sincronizzati. Informazioni che comunque restano troppo abbondanti.
Lo script di default non dovrebbe stampare nessun output, ma volevo comunque prevedere un'opzione tipo -verbose per permettergli di farlo su richiesta dell'utente, a fini di debug. È proprio per questo che ho messo la funzione printScreen, per regolare a monte l'output a video. Lo stesso vale ovviamente per le attività di logging.

D'accordo anche su questo.

p.s. cosa succede se lo script viene lanciano, inotify resta "di guardia" e - per un qualsiasi motivo, anche per scelta dell'utente - cade la connessione? Credo che tutto lo script vada ciclato all'infinito, con una buona pausa (60/120 sec) tra un ciclo e l'altro (tanto verrebbe applicata solo in casi simili), anche perché così lo script potrebbe ripartire dai controlli che includono anche la verifica della connessione.

I controlli sull'esistenza del file di configurazione e della connessione potrebbe farli lo script di sincronizzazione stesso.
Inotify resta attivo fin tanto che il programma non lo si ferma (while serve proprio a quello). Quando rileva una modifica tenta il sync. Se fallisce riprova il mount della directory remota. Se ha successo, esegue il sync altrimenti avvisa l'utente di controllare la connessione ed esce interrompendo il while.
Una volta sistemata la connessione, al successivo riavvio del programma avviene il sync.
Secondo me è preferibile demandare queste azioni allo script di sincronizzazione piuttosto che prevedere una pausa tra un ciclo e l'altro.

pmate

p.s. il file source-files.list lo chiamerei server.conf oppure remote.conf o qualcosa del genere; così com'è mi ricorda troppo il file relativo ai repository... ah, l'arteriosclerosi... 8)

Debianizzati.Org

Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox

Re: Script sostitutivo di Dropbox