Qualsiasi programmatore che abbia sviluppato in team con altri sviluppatori si sarà reso conto della necessità di condividere pezzi di codice con gli altri elementi del gruppo e delle difficoltà legate a tale condivisione. Fortunatamente esistono software appositamente progettati per consentire a differenti sviluppatori di lavorare sugli stessi progetti controllando le modifiche apportate ed evitando sovrascritture accidentali degli stessi frammenti di codice.
Oltre al classico “SourceSafe” prodotto dalla Microsoft ed agli strumenti messi a disposizione nell’ultima, e molto costosa, suite Microsoft Visual Studio Team Edition, ha preso piede in questi ultimi tempi un sistema gratuito e molto affidabile chiamato SubVersion. Tale software sembra stia soppiantando nei gusti dei sistemi un po’ di tutto il mondo un software analogo di nome CVS (Concurrent Versions System) dal quale SubVersion prende le mosse.
In questo articolo vediamo come installare la parte server di SubVersion su di una distribuzione Linux Ubuntu. Nello specifico il tutto è stato provato con la versione 7.04.
Si presuppone che sul sistema sia installato Apache 2.
I pacchetti necessari per subversion sono “subversion” e “libapache2-svn”
Per cui procediamo alla loro installazione utilizzando il comando apt-get:
{geshibot lang=”bash”}#sudo apt-get install subversion libapache2-svn{/geshibot}
Il comando provvederà ad installare i moduli necessari, SubVersion e SVN per Apache.
Il modulo SVN dovrebbe essere automaticamente abilitato dopo l’installazione. Se così non fosse è possibile utilizzare il comando “a2enmod”, uno script che abilita il modulo specificato, ad esempio, nel nostro caso:
{geshibot lang=”bash”}#sudo a2enmod dav_svn{/geshibot}
Incidentalmente faccio notare che esiste un comando con funzione opposta, vale a dire per disabilitare un modulo: “a2dismod
[nome modulo]
“
Ancora un’osservazione sul modulo SVN: si tratta di un modulo che utilizza per la trasmissione dei dati con subversion il protollo WebDAV per cui può passare tranquillamente attraverso un firewall.
Configurazione del repository
A questo punto possiamo passare alla configurazione del repository. Sarebbe possibile apportare le modifiche del caso al file /etc/apache2/mods-enabled/dav_svn.conf, tuttavia ciò non è possibile nel caso di configurazione sulla macchina server di hosts virtuali (vhosts).
E’ questa la tipologia di configurazione che personalemtne prediligo per cui suggerisco la modifica dei file in /etc/apache2/sites-available/*
La cartella “/etc/apache2/sites-available/” contiene un file di configurazione per ogni sito virtuale disponibile sulla macchina. Ne esiste uno predefinito, con nome “default”. E’ possibile modificare direttamente questo file con le opportune proprie “customizzazioni” e, nel caso sia necessario rendere disponibile un nuovo sito virtuale, è possibile duplicare il file in questione (utilizzando un nome a piacimento) e modificarlo seconda necessità.
La cartella in questione elenca, come dice il nome stesso, i siti disponibili sulla macchina. Essere disponibile non è sufficiente: bisogna anche che il sito sia abilitato. A tale scopo esiste una utility “a2ensite” che abilita il sito specificato. Ciò che tale utility realizza è la creazione di un link simbolico nella cartella /etc/apache2/sites-enabled/ che punta al file di configurazione del sito specificato. Un utility complementare, “a2dissite”, consente di disabilitare momentaneamente uno specifico sito senza costringere a cancellare o rinominare il file di configurazione.
La lettura dei file “enabled”, cioè abilitati, è resa possibile dalla direttiva
{geshibot lang=”apache”}”Include /etc/apache2/sites-enabled/”{/geshibot}
presente nel file di configurazione principale di Apache.
Un tipico file di configurazione di un host sarà qualcosa del tipo: {geshibot lang=”apache”}<VirtualHost 192.168.1.1:80>
DocumentRoot /home/test/public_html
ServerName nomesito.tesseract.it
<Location /svntest>
DAV svn
SVNListParentPath on
SVNPath /home/test/repositories/test1
AuthType Basic
AuthName “Tesseract SVN test repository”
AuthUserFile /etc/apache2/users
AuthGroupFile /etc/apache2/groups
Require group developers
</Location>
</VirtualHost>{/geshibot}
Da notare che dovranno essere presenti nel file di configurazione generale (apache2.conf) le seguenti righe:
{geshibot lang=”apache”}NameVirtualHost 192.168.1.1:80{/geshibot}
Dove 192.168.1.1 è l’IP della vostra macchina server
{geshibot lang=”apache”}Include /etc/apache2/sites-enabled/{/geshibot}
Per includere I file edi configurazione degli host virtuali
Procediamo con la creazione delle directory per SubVersion: {geshibot lang=”bash”}#sudo mkdir svn
#cd svn
#sudo mkdir repositories{/geshibot}
Per creare il repository di test usiamo il comando “svnadmin” {geshibot lang=”bash”}# sudo svnadmin create –fs-type fsfs /home/svn/repositories/test1{/geshibot}
Impostiamo i permessi sulle direcory:
{geshibot lang=”bash”}#sudo chown -R www-data /home/svn{/geshibot}
Configurare Apache per il controllo degli utenti
Per memorizzare le informazioni relative agli utenti e relative password per l’accesso ai contenuti è necessario creare un apposito file.
Tale file, per ovvie ragioni di sicurezza, deve essere registrato in una posizione tale da non essere accessibile da web. Esso, inoltre, non può essere editato direttamente a mano; le password, infatti, sono registrate in forma cifrata.
Il programma utilizzato per tale gestione è “htpasswd”:
Per iniziare è necessario creare il file in questione indicando un primo nuovo utente da inserire nel file stesso:
{geshibot lang=”bash”}htpasswd -c /etc/apache2/users carlo{/geshibot}
Il comando, con l’opzione -c, crea il file “users” nella directory /etc/apache2/ chiedendo la password da associare all’utente (nel nostro caso, l’utente “carlo”).
Il contenuto del file “users” dovrebbe essere ora simile al seguente: {geshibot lang=”apache”}——————————————-
carlo: xx1LtcDbOY4/K
——————————————-{/geshibot}
dove si individua il primo campo contenente il nome utente ed il secondo campo, separato dal simbolo “:” contenente la password in forma cifrata.
Per inserire nuovi utenti all’interno del file riusiamo il comando htpasswd, omettendo ovviamente il flag -c in quanto il file è stato già creato; ad esempio, il comando:
{geshibot lang=”apache”}——————————————-
htpasswd /etc/apache2/users giuseppe
——————————————-{/geshibot}
aggiunge al file /etc/apache2/users l’utente “giuseppe”
Nella sezione “<Location></Location>” si utilizzano una serie di direttive per configurare i contenuti del repository ed i relativi accessi.
Vediamo in dettaglio le principali tra tali direttive:
SVNPath valorizzato nel nostr caso con il percorso “/home/test/repositories/test1” indica, appunto, il percorso fisico del repository. Tale percorso viene raggiunto tramite la redirezione impostata con “<Location /svntest>”.
In concreto l’URL http://nomeMacchina/svntest redirigerà il browser nel repository specificato dal valore impostato in “SVNPath”.
AuthName indica un nome per la zona, ovvero l’insieme di file e cartelle, per le quali si vuole controllare l’accesso. Esso rappresenta quello che in gergo tecnico viene definito “realm”. Un realm rappresenta, appunto, una zona del file system, generalmente una directory con eventuali sottodirectory che si intende proteggere. Una volta avvenuta l’autenticazione relativamente ad un certo realm questa viene conservata per la sessione corrente e sarà valida anche in una zona differente purchè avente lo stesso nome di realm.
AuthType indica il protocollo da utilizzarsi per l’autenticazione. Basic è quello predefinito.
AuthUserFile indica al server il nome e la posizione del file da contenente le credenziali di accesso.
Nel caso si volessero usare dei gruppi, anzichè gestire il singolo utente, è possibile utilizzare la direttiva AuthGroupFile
require indica gli utenti che possono avere accesso al realm specificato: Nel caso si voglia abilitare tutti gli utenti indicati nel file delle password è sufficiente valorizzare la direttiva require con il valore valid-user.
In caso contrario, nel caso si volesse autorizzare un sottoinsieme di utenti sarà sufficiente indicare i loro nomi dopo la direttiva stessa. Ad esempio:
{geshibot lang=”apache”}require user carlo giuseppe{/geshibot}
abilita all’accesso i soli utenti “carlo” e “giuseppe”
Nel caso di situazioni più complesse è possibile ricorrere alla gestione dei gruppi utilizzardo la direttiva AuthGroupFile e specificando il file contenente le informazioni sui gruppi stessi. Un file di tale tipo è organizzato in una sequenza di righe contenenti i nomi dei gruppi e, separati dal sibolo “:”, l’elenco degli utenti appartenenti allo specifico gruppo: {geshibot lang=”apache”}amministratori:carlo giuseppe
segreteria:anna isabella antonella{/geshibot}
Per l’autenticazione si può poi procedere, ad esempio, come segue: {geshibot lang=”apache”}require group amministratori segreteria
require user carlotta{/geshibot}
Tali direttive abilitano, dopo l’inserimento delle giuste credenziali, gli utenti dei gruppi “amministratori” e “segreteria” e l’utente “carlotta”, all’accesso alle risorse del realm.
Il client di accesso a SubVersion
Come client è possibile usare TortoiseSVN (http://tortoisesvn.net). Si tratta di un software gratuito per Windows che si integra perfettamente in “gestione risorse”.
Carlo Mazzone