Script sostitutivo di Dropbox

[pmate]

A quanto detto nel messaggio precedente a questo aggiungo un paio di considerazioni:

l'istruzione di sync è

Codice: Seleziona tutto

unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto


a mio parere si potrebbe evitare la scelta di una directory arbitraria da parte del client, un pò come in dropbox.
Se il software lo si chiama (ad esempio) fud (acronimo, la d finale sta per dropbox... cosa significheranno mai f e u? ), quell'istruzione potrebbe diventare:

Codice: Seleziona tutto

unison $HOME/Fud ssh://$USER@$SERVER:$PORT/$RPATH -logfile $LOGFILE $boptions -batch -auto


eliminando anche le variabili $LPATH e $LPATHOPTION. Insomma, qualcosa di vincolante.

Altra cosa, il check della raggiungibilità del server viene fatto tramite ping.
Io lo eviterei visto che (ad esempio) diversi server droppano/rifiutano il ping. Magari il check può essere effettuato direttamente cercando di montare la risorsa remota. Se il mount fallisse il messaggio d'errore sarebbe genericamente riferito a problemi di connessione.

Va da sè, infine, che se la scelta ricade su soluzioni tipo sshfs, curlftpfs e similari anche il blocco # Check if a ssh connection is available and if unison is installed on server non ha più motivo di esistere così come quello # Check if ssh is installed.
Al loro posto ci dovrebbe essere il check dell'esistenza dei pacchetti sshfs oppure curlftpfs oppure etc. etc.


pmate

[mirko.pagliai]

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

Ma tu che dici, è il caso di montare anche quando non strettamente necessario, come ad esempio per ssh? Credo sia soprattutto una questione di performance e credo che il mount debba essere l'ultima spiaggia.

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.

Quindi, se ho capito bene, la tua proposta è di verificare l'esito di unison (che comunque ha un tot di tentativi utili da eseguire) all'interno del while e regolarsi di conseguenza.
Ma se poi la connessione torna attiva? :-D

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...

Provvedo.

a mio parere si potrebbe evitare la scelta di una directory arbitraria da parte del client, un pò come in dropbox.
Se il software lo si chiama (ad esempio) fud (acronimo, la d finale sta per dropbox... cosa significheranno mai f e u? ), quell'istruzione potrebbe diventare...

Fuck you Dropbox? :-D
Sì, volendo è possibile. Ma credo sia una questione di comodità personale: io ad esempio non lo sopporto, tant'è che sono costretto ad andare di link simbolico in link simbolico e di tenerli regolarmente sott'occhio. Ovviamente se devo aggiungere un nuovo client sai che succede? È un casino:
- faccio sincronizzare, ovvero faccio scaricare tutto. Dropbox ovviamente scarica tutto nella sua cartella, perché sugli altri client vede così (anche se non è);
- devo fermare Dropbox, altrimenti mentre faccio le successive modifiche va in confusione (giustamente...);
- devo riordinare i file che mi ha scaricato nella sua cartella;
- devo ricreare i link simbolici come sugli altri client, altrimenti al riavvio di Dropbox andrà anche in questo caso in confusione (giustamente...);
- faccio ripartire Dropbox.

Potremmo invece procedere come segue: prevedere una directory arbitraria come default. Ovvero un eventuale script d'installazione (che ho già messo in conto), crea la cartellina Fud e crea il file sorgenti inserendoci solo quella.
Poi chi come me vuole agire diversamente, modifica.

Altra cosa, il check della raggiungibilità del server viene fatto tramite ping.
Io lo eviterei visto che (ad esempio) diversi server droppano/rifiutano il ping. Magari il check può essere effettuato direttamente cercando di montare la risorsa remota. Se il mount fallisse il messaggio d'errore sarebbe genericamente riferito a problemi di connessione.

Giustamente. D'altronde già adesso con ssh verifica la connessione e verifica la disponibilità di unison sul server.



Ho una domanda. Perché non funziona nessuno dei tre?

Codice: Seleziona tutto

unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse | grep "Synchronization complete at"

Codice: Seleziona tutto

unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse | notify-send

Codice: Seleziona tutto

unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse | grep "Synchronization complete at" | notify-send

Il terzo è ovviamente il risultato che voglio raggiungere, ma in tutti e tre i casi tutto ciò che viene dopo la prima pipeline viene completamente ignorato. Unison stampa sempre il suo output e lo stampa completamente.
p.s. il grep è solo un primo passaggio, poi con una regex devo togliere un po' di altra roba. Ma penso che per la notifica sia sufficiente un "sincronizzati 4 file", dato che si trova appunta nella riga che comincia per "Synchronization complete at"

[pmate]

Ho una domanda. Perché non funziona nessuno dei tre?

Prova così:

Codice: Seleziona tutto

echo `unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse | grep 'Synchronization complete at'`


Occhio ai backslash!

Fuck you Dropbox? :-D

Bingo!!!

A dopo per le considerazioni su quanto hai scritto.

Ciao,
pmate

[mirko.pagliai]

Nisba, continua come se nulla fosse :-/

EDIT: io non capisco. Persino facendo così:

Codice: Seleziona tutto

   OUTPUT=`unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse`

Stampa $OUTPUT di propria iniziativa :-|

EDIT2: dipendeva dall'output stream utilizzato da unison. Risolto così:

Codice: Seleziona tutto

unison $HOME ssh://$USER@$SERVER:$PORT/$RPATH $LPATHOPTION -logfile $LOGFILE $boptions -batch -auto -terse 2>&1 | grep "Synchronization complete at"

[mirko.pagliai]

Sto riprendendo lo sviluppo, per domani un nuovo aggiornamento.
Sono arrivato alla conclusione che è comunque sempre opportuno montare, così che sia possibile con inotify controllare anche i file sul server e quindi ottimizzare così tutto il processo di sincronizzazione.

Intanto una piccola chicca:

[mirko.pagliai]

Ecco l'aggiornamento! :-)
http://pastebin.com/Zqc2bhCp [VEDI MESSAGGIO SUCCESSIVO]
Domani darò maggiori istruzioni d'uso (per chi non avesse il tempo di desumere dal codice). Ad ogni modo.

1) come avevo già accennato:

Sono arrivato alla conclusione che è comunque sempre opportuno montare, così che sia possibile con inotify controllare anche i file sul server e quindi ottimizzare così tutto il processo di sincronizzazione

Ora si monta sempre. Quindi per ssh si utilizzerà sshfs;
2) [rullo di tamburi] supporto per ftp tramite curlftpfs, anche se è da testare attentamente :-)
3) notifiche a schermo delle sincronizzazioni tramite notify-send, come ho già mostrato:

Attualmente il codice per estrarre queste informazioni (nello script alla riga 98) è davvero "sporco". Ho aperto un'altra discussione per trovare una regex adatta;
4) ho aggiunto a Unison l'opzione confirmbigdel, perché ho notato che in modalità verbosa, nel momento in cui si cancellava una directory contenente altra roba, non sincronizzava e dava questo errore:

The following paths have been completely emptied in one replica:
'dirprova'
Unison may delete everything below these paths in the other replica.

(Set the 'confirmbigdel' preference to false to disable this check.)

Un paio di dubbi:
1) c'è la certezza che sia sshfs che curlftpfs mantengano la directory remota montata, anche in caso di inattività?
2) che succede se lo script viene interrotto, la directory remota rimane montata, quindi lo script viene rilanciato? Si trova la cartella già montata e quindi:
2a) non controllo il corretto mount di questa (e quindi, verificata che è già montata, do tutto per buono);
2b) dovrei smontarla, là dove necessario, a inizio script, ma come fare senza i privilegi di root?
2c) altro?

p.s. per utilizzare ftp configurare come di consueto. In questo caso, la password deve essere indicata in chiaro.

[mirko.pagliai]

C'erano parecchi errori nella precedente versione.
Sistemati: http://pastebin.com/Fq0K0TZR

Ho testato personalmente: ho appena sincronizzato i miei pc utilizzando un banalissimo dominio con accesso ftp :-D :-D :-D

EDIT:

NOTE:
1) ho notato che inotifywait non riesce a monitorare/mnt/fud, ovvero la cartella remota montata in locale. In altri termini, collegando tramite Filezilla e apportando modifiche da lì, inotify non fa partire la sincronizzazione. Lanciano inotify se stante, ho notato che i cambiamenti in questi caso vengono rilevati così (qui cancello un file, che sarebbe l'unico presente):

Codice: Seleziona tutto

mirko@mirko-desktop:~/fud$ inotifywait -r -m /mnt/fud
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/mnt/fud/ OPEN,ISDIR
/mnt/fud/ CLOSE_NOWRITE,CLOSE,ISDIR
/mnt/fud/ OPEN,ISDIR
/mnt/fud/ CLOSE_NOWRITE,CLOSE,ISDIR

Aggiungendo l'evento "open" tutto funziona correttamente, ma non sono sicuro di aver fatto le cose fatte per bene. Anche perché l'evento avrebbe luogo anche sulla cartella locale, e insomma...
2) sono ancora dell'idea che bisogna ciclare lo script o qualcosa del genere: utilizzando ftp, ad esempio, a volte fa fatica a montare la cartella "al primo colpo", apparentemente per motivi sconosciuti, ed è quindi necessario far ripartire lo script;
3) si verifica un fastidioso problema (che avevo già proposto, a mio parere, di risolvere con qualche sleep o timeout) nella modifica "troppo veloce" dei file monitorati. Insomma, basta andare a creare un nuovo file, senza nemmeno aver digitato il nome, che parte la sincronizzazione, perché frattempo ho visto che Gnome crea effettivamente un file chiamato "nuovo file", in attesa che l'utente digiti appunto il nome del file (non so se è chiaro questo meccanismo...).
Succede anche che parta la sincronizzazione di "nuovo file", nel mentre si inserisce il nome voluto e la sincronizzazione fallisce.
Per ora ho messo un sleep tra inotify e unison, ma anche qui non sono convinto di aver scelto la soluzione migliore. Probabilmente bisognerebbe anche verificare l'exit di unison...

[mirko.pagliai]

Ragazzi, ma oltre pmate, non c'è nessun altro che si vuole aggregare allo sviluppo di questo coso? :-)

[mm-barabba]

Ragazzi, ma oltre pmate, non c'è nessun altro che si vuole aggregare allo sviluppo di questo coso? :-)

come coder sono una schiappa e ai fini pratici il vostro grande lavoro non mi è utile per ora.
Però ammiro l'impegno nello sviluppo che seguo e leggo con attenzione.

[Risca]

Ragazzi, ma oltre pmate, non c'è nessun altro che si vuole aggregare allo sviluppo di questo coso? :-)

Anche a me, pur non essendo un coder, piacerebbe collaborare. Purtroppo ciò che mi frega adesso è il tempo...

Consiglierei magari di adottare una piattaforma più consona per sviluppare il codice, ad esempio GIT o SVN...

[mirko.pagliai]

Consiglierei magari di adottare una piattaforma più consona per sviluppare il codice, ad esempio GIT o SVN...

Sì, guarda caso ci stavo pensando giusto ieri. Però non saprei a quale servizio rivolgermi, visto che è la prima volta che mi occupo io di una cosa del genere.
Stavo vedendo sourceforge e mi pare supporti git. Altrimenti? Consigli migliori?

[Risca]

Or come ora mi sembrerebbe che GIT stia avendo la meglio su SVN, in ogni caso sono entrambi sufficientemente noti ed utilizzati. Ti consiglierei di scegliere quello che preferisci e quindi trovare un posto dove hostare il codice. Tra i tanti consiglierei (ma ce ne sono altrettanti di validi):

• http://en.wikipedia.org/wiki/GNU_Savannah
• http://en.wikipedia.org/wiki/GitHub

Per un manuale su GIT o SVN ti consiglio di cercare in rete, comunque quando apri un progetto dovrebbero fornirti la documentazione necessaria per utilizzarlo proficuamente.

[mirko.pagliai]

GitHub lo conosco. Ora lo hosto su questo, purché mi permetta di aggiungere anche qualche paginetta descrittiva.
Intanto sto mettendo mano allo script di auto-configurazione.

[Stemby]

GitHub assolutamente.

Ciao!

[mirko.pagliai]

https://github.com/mirkop88/Fud
Mi confermate che ho capito il funzionamento? :-D