[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
Questo capitolo riprende la descrizione del funzionamento del sistema CVS per ciò che riguarda l'uso attraverso la rete e altri particolari che sono stati ignorati nel capitolo introduttivo, senza comunque esaurire il problema. Si vedano in particolare i riferimenti bibliografici alla fine del capitolo.
Sia il deposito CVS, sia la copia di lavoro di ogni collaboratore, utilizzano dei file amministrativi che generalmente possono essere ignorati, essendo gestiti da CVS in modo trasparente. Nel primo caso si tratta in modo particolare dei file contenuti nella directory CVSROOT/ che discende immediatamente dalla radice del deposito; nel secondo si tratta di quanto contenuto nella directory CVS/ che si attacca a ogni modulo e sottomodulo.
|
I file contenuti nella directory |
Quando un file di un modulo viene eliminato, questo viene conservato nel deposito nella directory Attic/, discendente dalla directory del modulo a cui apparteneva il file. Ciò permette di recuperare quel file quando si preleva una revisione precedente alla quale questo file appartiene.
Gli accessi al deposito devono essere regolati in modo da impedire la lettura o la scrittura in momenti inopportuni. Si distinguono due tipi di operazione: lettura, che si ha per esempio quando un collaboratore preleva una copia di un modulo, e scrittura, che avviene quando un collaboratore sottopone le sue modifiche.
Mentre è in corso un'operazione di lettura all'interno di un modulo, possono avvenire altre operazioni di lettura da parte di altri utenti, ma non possono essere eseguite delle operazioni di scrittura: se fosse consentito, i dati prelevati da qualcuno potrebbero essere incoerenti.
Mentre è in corso un'operazione di scrittura non è consentita nessun'altra operazione di lettura o scrittura.
Il meccanismo di questi semafori è un po' complicato, ma vale la pena di conoscerlo per sapere come comportarsi in caso di avaria.
Lettura del contenuto di un modulo:
viene tentata la creazione della directory #cvs.lock/ discendente dalla directory del modulo all'interno del quale si intende intervenire;
se l'operazione fallisce (perché esiste già la directory), viene atteso un intervallo di tempo e viene ritentata;
se nella directory del modulo non ci sono file che iniziano per #cvs.wfl* si procede con il punto successivo;
si crea un file il cui nome deve iniziare per #cvs.rfl e continuare con altre informazioni in modo da poterlo distinguere da altri con la stessa radice;
viene eliminata la directory #cvs.lock/;
viene svolta l'operazione di lettura;
viene eliminato il file #cvs.rfl*
Scrittura di dati all'interno di un modulo:
viene tentata la creazione della directory #cvs.lock/ discendente dalla directory del modulo all'interno del quale si intende intervenire;
se l'operazione fallisce (perché esiste già la directory), viene atteso un intervallo di tempo e viene ritentata;
se nella directory del modulo non ci sono file che iniziano per #cvs.rfl*, si procede con il punto successivo;
si crea un file il cui nome deve iniziare per #cvs.wfl e continuare con altre informazioni in modo da poterlo distinguere da altri con la stessa radice;
la directory #cvs.lock/ viene lasciata lì;
viene svolta l'operazione di scrittura;
viene eliminato il file #cvs.wfl* e la directory #cvs.lock/.
È importante osservare la differenza nell'uso della directory #cvs.lock/. È la sua presenza a impedire l'accesso in lettura da parte di chiunque altro ed è per questo che viene lasciata quando si procede con una modifica dei dati.
|
Da quanto esposto, si nota che un accesso in lettura al contenuto di un modulo implica in pratica la scrittura all'interno della directory corrispondente. Quindi, le directory dei moduli devono concedere la scrittura anche agli utenti che intendono semplicemente prelevare una copia del contenuto. |
Il sistema di semafori descritto sopra riguarda una sola directory. Per impedire l'accesso a una directory e a tutte le sue sottodirectory, occorre inserire i semafori in ognuna di queste, comprese le «soffitte» e altre eventuali sottodirectory amministrative.
Quando un collaboratore non può accedere a causa dei semafori, il messaggio che gli comunica questa situazione è simile a quello seguente:
|
In questo esempio un collaboratore non riesce ad accedere alla directory /var/radice-cvs/esercizi/c/ a causa di un blocco che appartiene all'utente caio. Di solito è sufficiente attendere fino a che il blocco viene liberato e CVS fa tutto da solo.
Alle volte può succedere per qualche motivo che i file di un blocco rimangano senza che ce ne sia più bisogno. Sapendo che si tratta di file che iniziano per #cvs.rfl* o #cvs.wfl* e della directory #cvs.lock/, è facile verificare se l'utente a cui appartengono questi file sta lavorando effettivamente con CVS; se non è così, è sufficiente rimuoverli per ripristinare l'accesso al deposito.
La maggior parte dei file contenuti nella directory CVSROOT/ che discende dalla radice di un deposito CVS, serve per configurare in qualche modo il funzionamento del deposito a cui si riferisce. Data la sua natura può sembrare strano che si voglia concedere la modifica di queste informazioni a più di una persona, eppure la logica di CVS è proprio quella del lavoro di gruppo, per cui per accedere a questa directory occorre comportarsi come se si trattasse di un modulo: si deve fare una copia di lavoro e poi si devono sottoporre le modifiche.
$ cvs checkout CVSROOT[Invio]
$ cvs commit CVSROOT[Invio]
Comunque, trattandosi di file di configurazione, in deroga al meccanismo generale dei moduli, nella directory CVSROOT/ del deposito si trovano sia i soliti file con estensione ,v che i file normali frutto delle ultime modifiche.
|
È bene ribadire che non si possono modificare questi file in modo diretto, ma occorre farsene una copia e inviarne l'aggiornamento attraverso il comando cvs commit. |
I file amministrativi nelle copie di lavoro sono raccolti nelle directory CVS/. Al loro interno, i file più comuni sono:
Volendo fare riferimento alla situazione di esempio mostrata nel capitolo precedente, la directory ~/esercizi/c/CVS/ dell'utente tizio potrebbe avere questi file con il contenuto seguente.
|
In generale, i file descritti e anche gli altri file che possono apparire in queste directory, non vanno toccati. Tuttavia, ci può essere la convenienza di modificare Root e Repository nel caso in cui il deposito venga spostato per qualche motivo. Infatti, in quella situazione, oltre che modificare il contenuto della variabile di ambiente CVSROOT occorrerebbe intervenire all'interno di questi file, a meno di voler prelevare nuovamente il contenuto dei moduli a cui si è interessati.
Per fare una copia di sicurezza di un deposito, conviene agire su tutto l'albero, perché se si scindono i moduli, al momento del recupero si rischia di avere parte di questi che non sono allineati alla stessa revisione. Un altro particolare a cui fare attenzione è il fatto che non siano in corso accessi al deposito; eventualmente si potrebbe creare la sottodirectory #cvs.lock/ in tutte le directory dei moduli, compresa CVSROOT/, in modo da impedire gli accessi durante le operazioni (naturalmente, dopo un recupero dalle copie, occorrerebbe eliminare queste sottodirectory).
La copia di un deposito CVS, a partire dalla sua radice, può essere riprodotto dove si vuole senza dover modificare alcun file amministrativo della directory CVSROOT/. Nello stesso modo, lo spostamento di un deposito non ha controindicazioni, a parte il fatto che questo dovrebbe avvenire in un momento in cui nessuno vi accede, esattamente come nel caso della copia.
Quando si sposta un deposito, le directory di lavoro dei collaboratori devono essere riprodotte nuovamente, oppure occorre che vengano modificati i file CVS/Root e CVS/Repository.
L'organizzazione di un deposito CVS accessibile attraverso la rete costituisce un problema in più per la sicurezza, come qualunque servizio di rete che venga aggiunto. In questo documento viene trascurato il problema, lasciando agli amministratori di considerare le implicazioni di una scelta rispetto a un'altra.
I metodi più comuni per offrire l'accesso a un deposito CVS sono l'uso di una shell remota, come rsh e ssh, oppure l'avvio di una copia del programma cvs in qualità di servente in ascolto di una certa porta TCP.
Dal punto di vista operativo, nel momento in cui è tutto pronto per garantire la connessione al deposito CVS è sufficiente aggiungere un'indicazione in più al percorso che rappresenta la radice del deposito stesso. In pratica, se prima i collaboratori dovevano predisporre la variabile di ambiente CVSROOT indicando il percorso assoluto della directory radice del deposito, adesso devono aggiungere anteriormente l'informazione sul modo in cui si vogliono collegare al deposito:
:metodo_di_accesso:utente@nodo:directory |
Il metodo di accesso è costituito da una parola chiave che viene mostrata nelle sezioni seguenti. In particolare, per fare riferimento esplicitamente a un deposito locale, si può specificare il metodo local; per esempio:
|
La connessione attraverso rsh richiede che i collaboratori siano stati registrati come utenti nell'elaboratore che ospita il deposito CVS. Inoltre, è necessario verificare che il programma cvs del sistema remoto sia accessibile senza doverne indicare il percorso. In pratica, nel momento in cui si utilizza rsh si avvia una sessione di lavoro temporanea in un altro elaboratore e in quel periodo di tempo l'utilizzatore dipende dall'impostazione che ha quell'utente nel sistema remoto. In particolare è importante la variabile PATH: questa deve contenere il percorso necessario ad avviare cvs in quel sistema.
Per specificare che si intende raggiungere un deposito ospitato presso un elaboratore remoto attraverso rsh, si utilizza la notazione seguente per indicare la radice CVS:
:ext:utente@nodo:directory |
L'utente è il nominativo necessario per accedere al sistema remoto; se non viene indicato, rsh utilizza lo stesso nome che ha l'utente nel sistema locale. L'esempio seguente fa riferimento alla directory /var/radice-cvs/ nel nodo dinkel.brot.dg, in cui l'utente deve accedere con il nominativo tizio:
|
A seconda di come è organizzata la connessione con rsh, può darsi che venga richiesto all'utente l'inserimento della parola d'ordine, oppure anche no, ma da questa politica non dipende CVS che si limita a utilizzare rsh così com'è.
Se si vuole usare un programma compatibile con rsh che abbia però un nome differente, lo si può indicare nella variabile di ambiente CVS_RSH. Per esempio, per usare ssh, basta che il collaboratore che intende farne uso predisponga questa variabile in modo simile a quello seguente (che si riferisce a comandi adatti a una shell di Bourne):
|
La modalità pserver rappresenta una soluzione leggermente più evoluta rispetto all'uso di rsh; richiede l'avvio di una copia di cvs in ascolto di una porta TCP attraverso il controllo del supervisore dei servizi di rete. La porta in questione è la numero 2 401, a meno che si decida qualcosa di diverso per qualche motivo. Per fare le cose per bene, occorrerebbe modificare il file /etc/services in modo da aggiungere la denominazione cvspserver:
|
Nel file /etc/inetd.conf occorre aggiungere un record come quello seguente, che appare spezzato su due righe per motivi tipografici.
|
L'opzione --allow-root serve per limitare l'accesso alla directory radice del deposito CVS; se necessario si possono indicare anche più directory utilizzando più volte questa opzione.
I collaboratori che intendono accedere al deposito CVS attraverso questo metodo devono indicare la directory radice del deposito attraverso la forma seguente:
:pserver:utente@nodo:directory |
Per esempio,
|
fa riferimento alla directory /var/radice-cvs/ nel nodo dinkel.brot.dg, in cui l'utente deve accedere con il nominativo tizio.
Tuttavia, quando un collaboratore intende accedere a un certo deposito CVS utilizzando questo metodo per la prima volta, è necessario predisporre (o aggiornare) il file ~/.cvspass attraverso il comando cvs login.
$ cvs login[Invio]
|
Il comando richiede che sia già stata predisposta la variabile CVSROOT. Lo scopo di questo comando è ottenere dall'utente la parola d'ordine da utilizzare per accedere al sistema remoto; questa viene annotata in modo cifrato nel file ~/.cvspass.
Generalmente, il metodo di accesso pserver fa riferimento agli utenti e alle parole d'ordine del sistema che ospita il deposito CVS. Dal momento che in questo modo tali informazioni si trovano a viaggiare attraverso la rete, potrebbe essere facile per un aggressore annotare questi dati, permettendogli in seguito di accedere a quell'elaboratore utilizzando le informazioni sulle utenze scoperte. Per ridurre questo tipo di problema è possibile utilizzare delle parole d'ordine diverse ed eventualmente anche degli altri nominativi per accedere al deposito CVS. Per ottenere questo risultato occorre predisporre il file CVSROOT/passwd contenente record composti di due o tre campi, secondo lo schema seguente:
nominativo_cvs:password_cifrata[:nominativo_locale] |
Il primo campo rappresenta il nominativo usato per accedere al deposito CVS; la parola d'ordine cifrata viene ottenuta nello stesso modo in cui si fa per il file /etc/passwd, attraverso la funzione crypt(); l'ultimo campo serve nel caso in cui il nominativo indicato nel primo non corrisponda a un utente del sistema e serve per indicare a chi corrisponda questo utente CVS. L'esempio seguente indica che l'utente tizio esiste anche nel sistema operativo in cui è ospitato il deposito CVS, solo che probabilmente la parola d'ordine è differente:
|
L'esempio seguente, invece, indica che chi accede come tizio attraverso CVS, corrisponde all'utente maramao nell'elaboratore che ospita il deposito.
|
Eventualmente, è possibile anche impedire un'autenticazione basata sugli utenti e le parole d'ordine del sistema che ospita il deposito, cioè si può imporre che il riconoscimento avvenga attraverso le indicazioni del file CVSROOT/passwd. Per questo si deve agire nella configurazione del file CVSROOT/config, con la direttiva SystemAuth=no.
Signum Support AB, Version Management with CVS, Per Cederqvist et al, 1993
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome cvs_la_rete_e_altre_annotazioni.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
