[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
A fianco del problema della realizzazione di una riproduzione speculare di informazioni pubblicate sulla rete, c'è anche quello di gestire un sistema di copia remota tra elaboratori, per dati che non sono messi a disposizione del pubblico, soprattutto allo scopo di mantenerli allineati.
Per questo tipo di problema, non avrebbe senso utilizzare il protocollo FTP, come sarebbe necessario per un sito speculare standard. Piuttosto, si fa uso di script o programmi che si basano sui servizi di una shell per l'accesso remoto, come rsh o ssh (capitoli 206 e 279), oppure su protocolli appositi.
Rsync (1) è un sistema di copia tra elaboratori (o anche all'interno del file system dello stesso sistema locale), in grado di individuare e trasferire il minimo indispensabile di dati, allo scopo di allineare la destinazione con l'origine. L'uso di questo programma è molto semplice ed è simile a quello di rcp (Remote shell copy) o anche di scp (Secure shell copy).
L'aggiornamento dei dati, in funzione delle opzioni utilizzate, può basarsi sul confronto delle date di modifica, delle dimensioni dei file e anche sul calcolo di un codice di controllo (checksum). In linea di principio, a meno di utilizzare opzioni che specificano qualcosa di diverso, non conta il fatto che i dati siano più recenti o meno, basta che questi siano diversi per ottenerne il trasferimento.
Rsync può utilizzare diverse modalità di trasferimento dei file, a seconda delle circostanze e delle preferenze. Per la precisione si distinguono tre possibilità fondamentali.
Copia locale.
In tal caso, la copia, o l'allineamento, avviene all'interno dello stesso sistema, dove l'origine e la destinazione sono riferite semplicemente a posizioni differenti nel file system. In questa circostanza, Rsync viene utilizzato come metodo evoluto di copia.
Copia tra elaboratori attraverso rsh o simili.
Si tratta di un'operazione che coinvolge due elaboratori differenti, anche se uno dei due deve essere necessariamente quello locale, in cui il trasferimento dei dati avviene attraverso rsh o un suo equivalente (come ssh), utilizzando una copia del programma rsync anche nell'elaboratore remoto.
Copia tra elaboratori attraverso un protocollo specifico di Rsync.
Si tratta di un sistema di copia tra elaboratori, dove in quello remoto si trova in funzione una copia del programma rsync, avviata in modo che resti in ascolto della porta TCP 873. In questo caso, la connessione tra elaboratore locale ed elaboratore remoto avviene direttamente senza l'utilizzo di una shell per l'accesso remoto.
La forma utilizzata per esprimere l'origine e la destinazione permette di distinguere anche la modalità con cui si vuole che la copia (l'allineamento) sia eseguita.
L'indicazione dei percorsi merita attenzione. Per prima cosa si può dire che valgono regole simili a quelle della copia normale; per cui, si può copiare un file singolo, anche indicando espressamente il nome che si vuole nella destinazione (che potrebbe essere diverso da quello di origine); inoltre si possono copiare uno o più file e directory in una destinazione che sia una directory.
Quando l'origine è locale, si possono indicare diversi percorsi, anche con l'aiuto di caratteri jolly che poi vengono interpretati opportunamente ed espansi dalla shell locale. L'esempio seguente, mostra il comando necessario a copiare o ad allineare i file che terminano per .sgml
, della directory corrente, con quanto contenuto nella directory /tmp/prove/
del nodo roggen.brot.dg
.
$
rsync *.sgml roggen.brot.dg:/tmp/prove
[Invio]
Quando l'origine è remota, si possono indicare diversi percorsi, anche con l'aiuto di caratteri jolly, che poi vengono interpretati opportunamente ed espansi dalla shell utilizzata nell'utenza remota. La differenza sta nel fatto che i caratteri jolly utilizzati non devono essere interpretati dalla shell locale, per cui è bene usare delle tecniche di protezione adatte. Probabilmente, ciò non è indispensabile, perché alcune shell come Bash ignorano l'espansione dei nomi se questi non possono avere una corrispondenza nel file system locale.
L'esempio seguente, mostra il comando necessario a copiare o ad allineare i file che terminano per .sgml
, della directory /tmp/prove/
del nodo roggen.brot.dg
, con quanto contenuto nella directory corrente dell'elaboratore locale.
$
rsync 'roggen.brot.dg:/tmp/prove/*.sgml' .
[Invio]
Quando l'origine fa riferimento a una directory, ma non si utilizza la barra obliqua finale, si intende individuare la directory, come se fosse un file normale. La directory di origine viene copiata nella directory di destinazione, aggiungendola a questa. Per cui, l'esempio seguente serve a copiare la directory locale /tmp/ciao/
nella directory remota /tmp/prove/
, generando /tmp/prove/ciao/
e copiando al suo interno i file e le sottodirectory che fossero eventualmente contenuti nel percorso di origine.
$
rsync -r /tmp/ciao roggen.brot.dg:/tmp/prove
[Invio]
Quando l'origine fa riferimento a una directory e si utilizza la barra finale, si intende individuare tutto il contenuto della directory, escludendo la directory stessa. Per cui, l'esempio seguente serve a copiare il contenuto della directory locale /tmp/ciao/
nella directory remota /tmp/prova/
, generando eventuali file e sottodirectory contenuti nella directory di origine.
$
rsync -r /tmp/ciao/ roggen.brot.dg:/tmp/prove
[Invio]
È diverso copiare il contenuto di una directory dal copiare una directory intera (assieme al suo contenuto); nel primo caso, si rischia di perdere la copia dei file «nascosti», ovvero quelli che iniziano con un punto. |
Come è possibile vedere in seguito, quando si utilizzano le opzioni -o (--owner) e -g (--group), si intende fare in modo che nella destinazione sia mantenuta la stessa proprietà dei file (dell'utente o del gruppo) che questi hanno nell'origine.
Per ottenere questo risultato, si confrontano generalmente i nomi degli utenti e dei gruppi, assegnando i numeri UID e GID necessari. Quando questa corrispondenza dovesse mancare, viene utilizzato semplicemente lo stesso numero ID. In alternativa, con l'uso dell'opzione --numeric-ids, si può richiedere espressamente l'uguaglianza numerica di UID o GID, indipendentemente dai nomi utilizzati effettivamente.
Il programma eseguibile rsync è quello che svolge tutte le funzioni necessarie ad allineare una destinazione, in base al contenuto di un'origine. Per questo si può avvalere di rsh, di un'altra shell per l'accesso remoto o di un servente Rsync remoto.
rsync [opzioni] origine destinazione |
L'origine e la destinazione possono essere riferite indifferentemente al nodo locale o a un nodo remoto. Quello che conta è che almeno una delle due sia riferita al nodo locale.
|
Segue la descrizione di alcuni esempi.
$
rsync -r /tmp/prove roggen.brot.dg:/tmp/prove
[Invio]
Copia la directory /tmp/prove/
del nodo locale, assieme a tutto il suo contenuto, nel nodo roggen.brot.dg
, generando lì, la directory /tmp/prove/prove/
contenente tutto ciò che discende dall'origine.
Si osservi che questa copia non riproduce le informazioni data-orario dei file e delle directory (opzione -t), pertanto, se dovesse essere ripetuto il comando, si otterrebbe nuovamente il trasferimento di tutti i file. |
#
rsync -a /tmp/prove roggen.brot.dg:/tmp/prove
[Invio]
Copia la directory /tmp/prove/
del nodo locale, assieme a tutto il suo contenuto, nel nodo roggen.brot.dg
, generando lì, la directory /tmp/prove/prove/
contenente tutto ciò che discende dall'origine. La copia viene fatta riproducendo il più possibile le caratteristiche originali, comprese informazioni data-orario dei file e delle directory, così che un utilizzo successivo dello stesso comando trasferirebbe solo quanto necessario ad aggiornare la copia.
#
rsync -a /tmp/prove/ roggen.brot.dg:/tmp/prove
[Invio]
Copia il contenuto della directory /tmp/prove/
del nodo locale nel nodo roggen.brot.dg
, nella directory /tmp/prove/
. La copia viene fatta riproducendo il più possibile le caratteristiche originali e la ripetizione del comando in momenti successivi trasferisce solo il necessario.
$
rsync -R prove/mie/*.txt roggen.brot.dg:/home/tizio
[Invio]
Copia i file che terminano per .txt
della directory prove/mie/
, discendente da quella attuale, nella directory /home/tizio/prove/mie/
del nodo dinkel.brot.dg
.
Si osservi che questa copia non riproduce le informazioni data-orario dei file e delle directory (opzione -t), pertanto, se dovesse essere ripetuto il comando, si otterrebbe nuovamente il trasferimento di tutti i file. |
#
rsync -a -z -v /tmp/prove/ roggen.brot.dg:/tmp/prove
[Invio]
Copia il contenuto della directory /tmp/prove/
del nodo locale nel nodo roggen.brot.dg
, nella directory /tmp/prove/
. La copia viene fatta riproducendo il più possibile le caratteristiche originali, trasferendo dati compressi e visualizzando le operazioni compiute.
#
rsync -azv -e ssh /tmp/prove/ roggen.brot.dg:/tmp/prove
[Invio]
Come nell'esempio precedente, ma utilizza ssh come shell per l'accesso remoto.
#
rsync -rlptD -zv /tmp/prove/ tizio@roggen.brot.dg:/tmp/prove
[Invio]
Come nell'esempio precedente, ma utilizza la shell predefinita per l'accesso remoto e accede come utente tizio. Per questo, non tenta di riprodurre la proprietà dei file (utente e gruppo proprietario).
#
rsync -rlptD -zv --progress
\
\/tmp/prove/ tizio@roggen.brot.dg:/tmp/prove
[Invio]
Come nell'esempio precedente, aggiungendo informazioni sul trasferimento dei singoli file.
#
rsync -rlptD -zv --progress
\
\/tmp/prove/ tizio@roggen.brot.dg::prove
[Invio]
Questo esempio è simile a quello precedente, con la differenza che nella destinazione si fa riferimento al modulo prove. I moduli di Rsync vengono descritti nelle sezioni seguenti, in occasione della presentazione delle funzionalità di servente di Rsync.
#
rsync -rlptD -zv --progress
\
\/tmp/prove/ rsync://tizio@roggen.brot.dg/prove
[Invio]
Esattamente come nell'esempio precedente, usando una notazione differente per la destinazione.
#
rsync -rlptD -zv --progress
\
\/tmp/prove/varie/ rsync://tizio@roggen.brot.dg/prove/varie
[Invio]
Come nell'esempio precedente, con la differenza che si intende allineare solo una sottodirectory, precisamente /tmp/prove/varie/
, con la sottodirectory corrispondente nel modulo prove.
$
rsync --recursive
\
\ --compress
\
\ --links
\
\ --perms
\
\ --times
\
\ --partial
\
\ --checksum
\
\ --verbose
\
\ --progress
\
\ rsync://roggen.brot.dg/prove/varie/ /home/prove/varie
[Invio]
In questo caso si vuole aggiornare il contenuto della directory locale /home/prove/varie/
con il contenuto della directory varie/
del modulo prove presso l'elaboratore roggen.brot.dg
che offre un accesso Rsync anonimo.
Come si può osservare dalle opzioni, si fa in modo di avere informazioni abbastanza dettagliate sullo svolgimento dell'operazione, per la presenza di --verbose e di --progress; inoltre, viene richiesto espressamente di verificare sempre i file da trasferire con un codice di controllo (opzione --checksum) e di conservare i trasferimenti parziali (in modo da ridurre il lavoro di un aggiornamento successivo, in caso di interruzione della comunicazione).
Si osservi che la presenza dell'opzione --checksum richiede un impiego maggiore di risorse da parte di entrambi gli elaboratori coinvolti nel trasferimento, che si traduce in tempi di attesa più lunghi. |
$
rsync rsync://roggen.brot.dg
[Invio]
Con questo comando ci si limita a interrogare il servente Rsync remoto sulla sua disponibilità di moduli. Si osservi però che alcuni o anche tutti i moduli possono risultare nascosti, cioè non visibili in questo elenco, in base alla configurazione del servente stesso.
Quando è richiesta l'autenticazione attraverso una parola d'ordine l'uso della variabile di ambiente RSYNC_PASSWORD può essere molto utile per automatizzare le operazioni di sincronizzazione dati attraverso Rsync.
Quello che si vede sotto, potrebbe essere uno script personale di un utente che deve aggiornare frequentemente il modulo prove nel nodo roggen.brot.dg
(identificandosi come tizio). Quando il servente remoto richiede la parola d'ordine, il cliente locale rsync la legge direttamente dalla variabile RSYNC_PASSWORD:
|
In alternativa alla variabile di ambiente RSYNC_PASSWORD, si può usare un file esterno, con permessi di accesso limitati, specificando l'opzione --password-file, come nell'esempio seguente:
|
Naturalmente, se Rsync non ottiene la parola d'ordine in uno di questi modi, la chiede in modo interattivo all'utente.
Se si vuole utilizzare Rsync per trasferire dati tra elaboratori differenti, senza usare una shell remota, occorre attivare nell'elaboratore remoto un servente Rsync. Si tratta in pratica dello stesso programma rsync, ma avviato con l'opzione --daemon.
Il servente Rsync può essere avviato in modo indipendente, in ascolto da solo sulla porta TCP 873, oppure sotto il controllo del supervisore dei servizi di rete. In questa modalità di funzionamento è necessario predisporre un file di configurazione: /etc/rsyncd.conf
.
Nel caso si voglia avviare il servente Rsync in modo autonomo dal supervisore dei servizi di rete, basta un comando come quello seguente:
#
rsync --daemon
[Invio]
Se si vuole inserire Rsync nel controllo del supervisore dei servizi di rete (cosa di sicuro consigliabile), occorre intervenire nel file /etc/services
per definire il nome del servizio:
|
Inoltre occorre agire nel file /etc/inetd.conf
(nel caso specifico di Inetd) per annunciarlo al supervisore dei servizi di rete:
|
Durante il funzionamento del servente Rsync si può avvertire un carico eccessivo del sistema operativo, causato dalla procedura di scansione dei file per il confronto con la copia remota da sincronizzare. Quando questo fatto diventa un problema, si può cercare di ovviare all'inconveniente avviando il programma rsync controllandone la priorità di esecuzione. Per fare questo conviene realizzare uno script, simile a quello seguente:
|
Supponendo che questo script corrisponda al file /etc/script/rsync-slow
, si può modificare così la riga che riguarda tale servizio nel file /etc/inetd.conf
:
|
Naturalmente, questo script va bene anche se si intende gestire il servente Rsync al di fuori del controllo del supervisore dei servizi di rete.
Rsync utilizzato come servente si avvale del file di configurazione /etc/rsyncd.conf
per definire una o più directory che si vogliono rendere accessibili attraverso il protocollo di Rsync, come una sorta di servizio FTP. Come nel caso dell'FTP, è possibile offrire l'accesso a chiunque, in modo anonimo, oppure si può distinguere tra utenti definiti all'interno della gestione di Rsync. Questi utenti sono potenzialmente estranei all'amministrazione del sistema operativo in cui Rsync si trova a funzionare, per cui occorre aggiungere un file di utenti e parole d'ordine specifico.
Rsync definisce moduli le aree che mette a disposizione (in lettura o anche in scrittura a seconda della configurazione). Quando si vuole accedere a un modulo di Rsync si utilizza una delle due notazioni seguenti:
[utente_rsync@]nodo::modulo[/percorso_successivo] |
rsync://[utente_rsync@]nodo/modulo[/percorso_successivo] |
Quando si accede a un modulo, il servente Rsync può eseguire un chroot() nella directory a cui questo fa riferimento, più o meno come accade con l'FTP anonimo. Per fare un esempio concreto, se il modulo prova fa riferimento alla directory /home/dati/ciao/
nel nodo dinkel.brot.dg
, l'indirizzo dinkel.brot.dg::prova/uno/mio
, oppure rsync://dinkel.brot.dg/prova/uno/mio
, fa riferimento al percorso /home/dati/ciao/uno/mio
in quell'elaboratore.
Il file di configurazione di Rsync, /etc/rsyncd.conf
, serve solo nel caso lo si voglia utilizzare come servente. Se si intende fare affidamento sul servizio di rsh o di ssh, non c'è alcun bisogno di preoccuparsene.
Il contenuto del file di configurazione è organizzato in moduli, ognuno dei quali descrive le impostazioni riferite a una directory del file system sottostante.
Ogni riga descrive un tipo di informazione. Le righe vuote, quelle bianche e ciò che è preceduto dal simbolo # viene ignorato. È ammessa la continuazione nella riga successiva utilizzando la barra obliqua inversa (\) alla fine della riga.
I moduli vengono identificati da un nome racchiuso tra parentesi quadre e la loro indicazione occupa tutta una riga; le informazioni riferite a un modulo sono costituite da tutte le direttive che appaiono nelle righe seguenti, fino all'indicazione di un altro modulo. Le direttive che descrivono i moduli sono delle opzioni che definiscono dei parametri e sono in pratica degli assegnamenti di valori a questi parametri. Alcuni tipi di parametri possono essere collocati prima di qualunque dichiarazione di modulo e si tratta in questo caso di opzioni globali che riguardano tutti i moduli (alcuni parametri possono apparire solo all'inizio e non all'interno della dichiarazione dei moduli).
Le opzioni globali sono quelle direttive (o parametri) che si collocano prima della dichiarazione dei moduli. Alcuni parametri possono essere collocati solo in questa posizione, mentre gli altri, le opzioni dei moduli, pur essendo stati preparati per la descrizione dei singoli moduli, possono essere usati all'inizio per definire un'impostazione generale. L'elenco seguente mostra solo l'uso di alcuni parametri delle opzioni globali.
|
|
Segue la descrizione di alcuni esempi.
|
Questo esempio, preso da rsyncd.conf(5), rappresenta una configurazione minima allo scopo di definire il modulo ftp che consenta l'accesso in sola lettura alla directory /home/ftp
per qualunque utente. In pratica, si vuole permettere l'accesso all'area FTP anche attraverso Rsync. Si osservi in particolare l'uso dei parametri uid e gid, all'inizio del file, in modo che Rsync utilizzi i privilegi dell'utente e del gruppo nobody per la lettura dei file.
|
Si tratta di una variante dell'esempio precedente, in cui i parametri uid e gid sono stati collocati all'interno del modulo. In questo caso, dal momento che non ci sono altri moduli, l'effetto è lo stesso.
|
L'esempio mostra la descrizione del modulo pippo all'interno di un file di configurazione che potrebbe contenerne anche altri. In pratica, gli utenti che Rsync identifica come caio e sempronio, possono scrivere all'interno della directory /opt/pippo/
, generando eventualmente anche delle sottodirectory, utilizzando i privilegi dell'utente e del gruppo tizio (secondo quanto definito dal sistema operativo di quell'elaboratore). Il file delle parole d'ordine necessario a identificare gli utenti caio e sempronio è /etc/rsyncd.secrets
.
|
Questo è un esempio abbastanza completo. Nella parte iniziale, le direttive globali servono a: specificare il file da usare per annotare il numero del processo elaborativo (PID); richiedere che venga utilizzata la funzione chroot() all'inizio di ogni modulo; consentire un accesso in sola lettura; consentire la visualizzazione dell'elenco dei moduli disponibili; a far funzionare il programma servente con i privilegi dell'utente e del gruppo rsync (ma all'avvio il programma deve avere i privilegi dell'utente root e con questi privilegi va poi a leggere il file contenenti le parole d'ordine); specificare quale sia il file contenente le parole d'ordine e che questo non deve risultare accessibile ad altri utenti; ignorare i file che non risultano leggibili, come se non ci fossero; annotare il trasferimento di tutti i file nel registro; infine l'ultima direttiva pone una scadenza alle connessioni sospese di tre ore al massimo.
Dopo le direttive globali appare un solo modulo, denominato a2dist, nel quale si indica: una descrizione del modulo; il limite massimo di connessioni (sette); il percorso del modulo (la directory /home/a2dist/distribution/
); gli utenti autorizzati ad accedere al modulo.
Bisogna osservare che l'opzione max connections definisce la quantità massima di connessioni simultanee, in senso complessivo, anche quando la si utilizza all'interno dei moduli. In questo senso, mancherebbe la possibilità di stabilire una quantità massima di accessi simultanei riferiti al modulo e non a tutto l'insieme. Tuttavia, per tenere traccia del numero di connessioni, si utilizza un file, definibile con l'opzione lock file; pertanto, per distinguere le connessioni massime, modulo per modulo, basta cambiare nome a questo file:
|
L'esempio mostra la suddivisione in tre moduli per l'accesso agli stessi dati, ma da parte di tre utenti differenti, ognuno dei quali ha la disponibilità di un solo accesso simultaneo.
Nasce la necessità di impedire che un utente possa accedere per più di una volta, simultaneamente, quando la sincronizzazione richiede tempi lunghi. Per esempio, se Tizio configura il proprio sistema Cron per eseguire la sincronizzazione una volta al giorno, ma ci vuole più di un giorno per aggiornare tutto, si rischia di riavviare una seconda sincronizzazione errata. |
Quando si utilizza Rsync come servente e si richiede una forma di autenticazione agli utenti che accedono, è necessario predisporre un file di testo contenente dei record secondo la sintassi seguente:
nome_utente:parola_d'ordine_in_chiaro |
Dal momento che normalmente il file viene letto da Rsync con i privilegi dell'utente root, è sufficiente che questo file abbia il permesso di lettura per l'amministratore del sistema.
Rsync non stabilisce quale sia la collocazione e il nome di questo file; è il parametro secrets file del file di configurazione a definirlo volta per volta. In generale, nella documentazione originale si fa l'esempio del file /etc/rsyncd.secrets
. L'esempio seguente mostra il caso degli utenti caio e sempronio, a cui sono state abbinate rispettivamente le parole d'ordine tazza e ciao.
|
È bene ribadire che questo file non ha alcun nesso con il file /etc/passwd
(né con /etc/shadow
). Gli utenti di Rsync possono non essere stati registrati (nel modo consueto) nell'elaboratore presso cui accedono.
Rsync è un sistema molto sofisticato per la sincronizzazione dei dati, che consente anche l'esecuzione del lavoro a più riprese, persino su file singoli (opzione --partial), con il minimo traffico di rete possibile.
Questa parsimonia nella gestione delle risorse di rete ha però un effetto indesiderato, in quanto si possono creare dei tempi morti, anche lunghi, in cui la connessione TCP rimane aperta senza il passaggio di alcun pacchetto. Tale situazione si può verificare in modo particolare quando si trasmettono file di grandi dimensioni attraverso dei tentativi successivi, perché ogni volta i due elaboratori coinvolti devono ricalcolare i codici di controllo di questi, per stabilire se la porzione presente nella destinazione possa essere utilizzata o meno: durante questo calcolo il traffico della connessione rallenta fino a sospendersi.
Anche se la sospensione della comunicazione non dovrebbe portare conseguenze per la connessione, bisogna ricordare questo fatto quando si utilizza la direttiva timeout (o l'opzione --timeout), in modo da lasciare un tempo sufficiente allo svolgimento delle operazioni necessarie. Inoltre, anche senza imporre alcun limite, ci potrebbero essere dei componenti tra i due elaboratori che non sono al corrente dell'esigenza di avere delle pause molto lunghe nelle connessioni. Potrebbe trattarsi di un router-NAT, che deve seguire tutte le comunicazioni che richiedono la trasformazione degli indirizzi e delle porte, introducendo anche per questo un problema di «scadenza» delle connessioni, che così si può manifestare con delle interruzioni inspiegabili della sincronizzazione dei dati attraverso Rsync.
Quando l'uso appropriato della direttiva timeout o dell'opzione --timeout non porta a risolvere il problema, può essere necessario evitare l'uso dell'opzione --partial.
Rdist (2) è un sistema di copia che permette di mantenere l'allineamento di uno o più elaboratori (host), mantenendo le informazioni relative alla proprietà, ai permessi e alla data di modifica dei file coinvolti.
L'aggiornamento dei dati si basa sul confronto delle date di modifica e delle dimensioni dei file. In linea di principio, non conta il fatto che i dati siano più recenti o meno, basta che siano diversi. Naturalmente, è possibile istruire Rdist in modo che aggiorni solo i file più recenti, così come si possono definire altri dettagli.
L'operazione di allineamento delle copie parte dall'elaboratore che contiene i dati originali, contattando i vari nodi presso cui si trovano le copie da allineare. In questo senso va inteso il nome di Rdist: Remote distribution, ovvero, distribuzione remota.
Rdist si avvale di due eseguibili per stabilire il collegamento necessario al trasferimento dei dati da allineare: rdist dalla parte dell'elaboratore utilizzato come punto di partenza per la distribuzione dei file (l'origine) e rdistd dalla parte degli elaboratori contenenti le copie da allineare (le destinazioni).
Tuttavia questo non basta. È necessario anche l'uso di rsh; inoltre l'accesso remoto relativo deve essere configurato in modo che l'utente, generalmente root, possa accedere agli elaboratori da allineare senza l'inserimento di alcuna parola d'ordine.
In pratica, si utilizza rdist per ordinare l'allineamento dei dati; questo utilizza rsh per connettersi con uno degli elaboratori remoti coinvolti, allo scopo di avviare lì il programma rdistd. Quindi, attraverso la connessione tra rdist e rdistd, ottenuta per mezzo di rsh, avviene la verifica delle corrispondenze e il trasferimento dei dati necessari.
Dalla descrizione fatta, dovrebbe essere chiaro che Rdist non è un servizio di rete, nel senso che non esiste un demone in ascolto su una certa porta TCP/IP. Rdist si avvale del servizio reso da rsh, che da solo (probabilmente anche con rcp) non basterebbe a risolvere il problema dell'allineamento delle copie remote.
Generalmente, quando si indicano i dati da allineare, si fa riferimento a un'origine, rappresentata da un percorso del file system locale, e a una destinazione composta semplicemente dal nome del nodo. In questa situazione, si intende che il percorso indicato come origine sia lo stesso nel file system del nodo di destinazione.
Per esempio, se si vuole allineare la directory /tmp/prove/ciao/
del file system locale, con il nodo remoto linux.brot.dg
, senza specificare una directory remota, si intende che debba trattarsi della stessa anche in quel file system.
Se invece si specifica anche la directory remota, la destinazione diventa esplicita, così che questa può essere anche una posizione diversa da quella del nodo di origine.
Prima ancora di vedere come si utilizza e si configura Rdist, è utile analizzare alcune delle modalità di funzionamento. La loro conoscenza permette di comprendere le possibilità di Rdist e il senso di ciò che si fa.
Come è possibile vedere meglio più avanti, la modalità di funzionamento viene definita attraverso una o più parole chiave, fornite per mezzo dell'opzione -o. Segue l'elenco di alcune di queste parole chiave.
|
Le operazioni da compiere con Rdist possono essere inserite in un file di configurazione. Se attraverso le opzioni non si fa riferimento a qualcosa di diverso, o comunque non si vuole ignorare questo file, il nome predefinito è distfile
, oppure, in sua mancanza, Distfile
, collocato nella directory corrente.
La struttura di questo file di configurazione è un po' strana. Come accade spesso, il simbolo # introduce un commento che termina alla fine della riga; inoltre, le righe vuote sono ignorate.
All'interno del file è possibile dichiarare delle variabili, attraverso le quali, il resto delle direttive può diventare più semplice da leggere. La loro dichiarazione avviene in direttive che utilizzano la sintassi seguente:
nome_variabile = valore |
La loro espansione avviene con la notazione seguente, dove le parentesi graffe (che in questo caso vanno intese letteralmente) sono necessarie per fare in modo che il nome della variabile venga preso in considerazione per intero (diversamente si utilizzerebbe solo il primo carattere).
${nome_variabile} |
Nelle direttive che definiscono l'allineamento tra origine e destinazione, si fa spesso riferimento a elenchi di nomi. Questi possono essere indicati raggruppandoli attraverso l'uso di parentesi tonde, come mostrato nella sintassi seguente:
nome | ( [nome [nome]...] ) |
Come si vede, quando l'elenco è formato da un nome soltanto, non occorrono parentesi, anche se queste si possono usare comunque. L'elenco tra parentesi è spaziato semplicemente, senza bisogno di altri simboli di separazione; inoltre è possibile indicare l'elenco nullo.
Questi raggruppamenti possono essere assegnati a delle variabili che successivamente possono essere usate per rappresentarli. In questo senso, si possono eseguire delle operazioni elementari che si richiamano vagamente alla teoria degli insiemi.
elenco + elenco |
elenco - elenco |
elenco & elenco |
La prima espressione restituisce un elenco che contiene tutti gli elementi dei due elenchi; in pratica, rappresenta l'unione dei due. La seconda restituisce un elenco contenente gli elementi presenti nel primo insieme, che non si trovano nel secondo. La terza restituisce l'intersezione dei due insiemi, cioè un elenco di elementi presenti in entrambi i raggruppamenti.
Gli elenchi di file possono essere definiti attraverso caratteri jolly, ma solo quando questi sono riferiti all'elaboratore locale (quello di origine). Sono ammissibili i caratteri jolly della shell C (csh); in pratica sono validi: l'asterisco (*), il punto interrogativo (?), le parentesi quadre e le parentesi graffe, con lo stesso significato che hanno anche con la shell Bash.
Il tipo di direttiva più importante è quello che definisce l'allineamento di un gruppo di file o directory nell'origine con un gruppo di nodi di destinazione. Anche se la sintassi seguente mostra una struttura scomposta su più righe, in realtà tutto potrebbe apparire su una riga sola, a discapito della leggibilità.
[etichetta:] origine -> destinazione [comando;]... |
L'etichetta è un nome facoltativo, terminato da due punti (:), a cui si può fare riferimento per selezionare un gruppo ristretto di azioni; l'origine è un elenco di file e directory; la destinazione è un elenco di nodi rappresentati per nome o attraverso l'indirizzo IP, con l'eventuale aggiunta di un prefisso costituito dal nominativo-utente da utilizzare per l'accesso remoto; infine, i comandi sono delle indicazioni aggiuntive che definiscono in particolare l'operazione da compiere e permettono di stabilire delle modalità dell'allineamento dei dati.
La destinazione può essere composta da un elenco di nomi che rispettano la sintassi seguente. L'utente, rappresenta il nome utilizzato per l'accesso attraverso rsh.
[utente@]nodo |
I comandi possono essere di tipo differente e così utilizzano sintassi differenti. Segue la descrizione di questi comandi.
|
Di seguito vengono mostrati e descritti alcuni esempi riferiti alla configurazione di Rdist attraverso il file distfile
oppure Distfile
.
|
Dichiara la variabile GRUPPO_HOST a cui viene attribuito l'elenco di nodi composto da roggen.brot.dg
e da linux.brot.dg
specificando anche il nominativo-utente root, da utilizzare per accedere presso questo ultimo nodo.
|
Dichiara la variabile GRUPPO_ORIGINE a cui viene attribuito l'elenco di file e directory da duplicare nella destinazione remota. Vengono specificate le directory /usr/
e /opt/
.
|
Dichiara la variabile GRUPPO_ESCLUSO a cui viene attribuito l'elenco di file e directory da escludere dalla duplicare nella destinazione remota. Vengono specificati tutti i file e le directory che corrispondono al modello /usr/src/linux*
e la directory (o il file) /opt/marameo
.
|
Dichiara l'allineamento tra un gruppo di file e directory dell'elaboratore di origine, espresso dalla variabile GRUPPO_ORIGINE, con un gruppo di nodi di destinazione, espresso dalla variabile GRUPPO_HOST, utilizzando gli stessi percorsi nelle varie destinazioni, attivando le modalità remove e ignlnks. In particolare vengono esclusi dall'allineamento i file e le directory rappresentati dalla variabile GRUPPO_ESCLUSO e anche quanto contenuto nella directory /usr/share/games/
(si presume che sia una directory, ma questo non è indicato esplicitamente). Infine, quando viene aggiornato il file /opt/pippo/etc/configura
, viene avviato il programma /opt/pippo/bin/rigenera
nella destinazione (probabilmente serve a ricostruire altri file in funzione del contenuto del file modificato).
|
Dichiara l'allineamento tra i file e le directory che corrispondono al modello /usr/src/linux*
con il nodo linux.brot.dg
(utente root), nella directory /usr/local/src/
. Al termine dell'allineamento, viene inviato un messaggio a tizio@linux.brot.dg
e a daniele@dinkel.brot.dg
.
L'eseguibile rdist è quello attraverso il quale si ottiene l'allineamento tra un elaboratore di origine e uno o più elaboratori di destinazione. rdist si avvale normalmente di un file di configurazione, indicato espressamente attraverso l'opzione -f, oppure rappresentato dal file ./distfile
, o da ./Distfile
. Se si vuole selezionare una o più etichette all'interno del file di configurazione, si possono indicare i nomi di queste alla fine della riga di comando.
rdist [opzioni] [etichetta...] |
rdist [opzioni] -c origine... [utente_remoto@]nodo_destinazione[:directory_destinazione] |
In alternativa all'uso del file di configurazione, si può indicare l'operazione di allineamento nella riga di comando, con l'opzione -c. In tal caso, sarebbe come se fosse stato usato il file di configurazione seguente:
( origine... ) -> [utente_remoto@]nodo_destinazione install [directory_destinazione] ; |
Il programma rdist si avvale di rsh per avviare nell'elaboratore remoto il suo «collega», rdistd, nel modo seguente:
rsh -l utente_remoto rdistd -S |
|
Segue la descrizione di alcuni esempi.
#
rdist -f ~/distfile
[Invio]
Avvia rdist per eseguire le direttive contenute nel file ~/distfile
.
#
rdist -f ~/distfile prova
[Invio]
Avvia rdist, utilizzando il file di configurazione ~/distfile
, specificando di voler eseguire esclusivamente l'etichetta prova.
#
rdist -f ~/distfile -p /usr/sbin/rdistd
[Invio]
Avvia rdist per eseguire le direttive contenute nel file ~/distfile
, indicando precisamente il percorso assoluto del programma rdistd negli elaboratori remoti.
#
rdist -n -f ~/distfile -p /usr/sbin/rdistd
[Invio]
Come nell'esempio precedente, ma limitandosi a simulare le operazioni.
#
rdist -c /usr/lib root@roggen.brot.dg
[Invio]
Aggiorna il nodo roggen.brot.dg
in modo che la directory /usr/lib/
contenga le stesse cose di quello locale.
#
rdist -c /usr/lib root@roggen.brot.dg:/usr/local/lib
[Invio]
Aggiorna il nodo roggen.brot.dg
in modo che la directory remota /usr/local/lib/
contenga le stesse cose della directory locale /usr/lib/
.
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
2) Rdist software non libero: non è consentita la riproduzione fisica della documentazione e la vendita di assistenza; inoltre la modifica non è consentita esplicitamente
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome trasferimento_e_sincronizzazione_di_dati_attraverso_la_rete.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]