Configurare un server SVN su Mac OS X

Questo secondo Q&A è sponsorizzato da me stesso, che dopo aver messo su un piccolo server col MacMini e Mac OS X 10.6 Server ho deciso che sarebbe stato interessante dedicare una partizione alla realizzazione di piccolo SVN Server.

SVN o Subversion è un software molto usato per lo sviluppo di documenti in team; spesso si tende giustamente ad associare subversion alla gestione del codice sorgente ma di questo utilissimo strumento possono farne uso anche tutti coloro che lavorano in altri ambiti dove si lavora in gruppo (o comunque nel momento in cui si vuole avere uno storico sempre consultabile dei cambiamenti effettuati).

Il principio è molto semplice: ogni file ha una versione associata e ogni utente ha due tipi di privilegi, lettura e/o scrittura. Di solito per progetti opensource esso viene configurato in modo tale che qualsiasi utente anonimo possa consultare i documenti (privilegi di lettura) mentre soltanto i membri attivi (gli sviluppatori) hanno anche la possibilità di effettuare modifiche su file o aggiungerne altri.

Se siete interessati ad approfondire SVN spaghettilinux ha una ottima guida in PDF scaricabile da questo link.

SCEGLIERE IL SERVER SVN CHE FA PER NOI

Ci sono due diversi modi di configurare un server svn; utilizzando il pacchetto binario svnserve (la soluzione migliore se non si ha a disposizione una macchina con OS X Server) oppure tramite il modulo mod_dav_svn. Entrambi le configurazioni lavorano alla stessa maniera rispetto all’utente, tuttavia differiscono molto per scalabilità e performance.

Generalmente si utilizza svnserve per piccoli ambienti multi utente dove la comunicazione con l’esterno alla rete non è indispensabile. svnserve è pre-installato nella versione Server di Mac OS X, mentre è necessario avere XCode Tools nel caso si fosse sotto l’ambiente client/consumer.

Dei due, svnserve inoltre offre migliori performance di rete rispetto al modulo Apache.

L’unica pecca è che, a meno di una particolare accortezza (che descriveremo dettagliatamente più avanti ma che comunque non è molto consigliata), svnserve comunica senza una connessione criptata inviando dati e informazioni di login in chiaro.

L’altra soluzione è utilizzare svn server come modulo di Apache (mod_dav_svn); spesso questa soluzione è preferita quando l’ambiente di lavoro è estremamente ampio e la comunicazione con l’esterno della rete è un fattore indispensabile.

Per utilizzare questa soluzione nella maniera più veloce possibile è consigliabile avere a disposizione Mac OS X Server (tuttavia lavorando con i file di configurazione è possibile ottenere gli stessi risultati su un qualunque ambiente supportato da Apache, sia server che client).

Per configurare il server faremo uso dell’applicazione Workgroup Manager (gestione degli account svn con supporto per SSL); essendo parte del pacchetto WebDav (mod_dav) questa soluzione offre anche indubbi vantaggi nella gestione degli utenti e dei permessi (per questo useremo invece l’utility Server Admin).

Un altro vantaggio della scelta di Apache è la possibilità di visionare la gerarchia del server svn direttamente da http (quindi da un qualunque browser) senza costi aggiuntivi.

Ovviamente tutte queste belle cose hanno un prezzo che si fa sentire sia come una maggiore difficoltà nel momento della configurazione (ci impiegheremo circa 30 minuti) che come diminuzione delle performance sulla rete (le connessioni http richiedono frequenti step di connessione/disconnessione che si tramutano poi in overhead per i server per via del maggiore volume di traffico scambiato).

Se siete interessati ad informazioni più dettagliate su questi due tipi di server c’è un interessante capitolo che fa per voi nella guida al Version Control con SVN.

CREARE UN REPOSITORY SVN

Questa parte prescinde dal tipo di server che abbiamo scelto; si tratta di configurare dei repository, ovvero dei contenitori, dove verranno conservati i nostri file. Il server svn si occuperà poi di tenere queste cartelle aggiornate, consultabili per numero di versione etc. Gli utenti saranno in grado, a seconda dei privilegi loro assegnati, di generare una cosidetta working copy – checkout – (ovvero una copia locale dei file del progetto) e di sincronizzare/inviare le proprie modifiche – commit.

E’ interessante far notare che, ad ogni aggiornamento, il server svn salverà soltanto le modifiche effettuate ai singoli file, evitando quindi di consumare spazio inutile.

Per creare un nuovo repository, dove poter inserire le directory dei nostri progetti, dobbiamo far uso del Terminale. Abbiamo deciso di riservare al repository una partizione del nostro hard disk, quindi digitiamo:

mkdir -p /Volumes/development/repository

Dobbiamo ora creare, usando i tool di amministrazione di subversion, una nuova directory per il nostro progetto (la chiameremo ‘progetto1′); subversion si occuperà di popolarla con i file di configurazione necessari:

svnadmin create /Volumes/development/repository/progetto1

Prima di poter importare i file di progetto all’interno, sarà necessario importare uno scheletro di cartelle all’interno della directory progetto1 che comporrà la comune struttura di un repository. Si tratta delle cartelle standard trunk, branches e tags (per saperne di più vi rimando nuovamente alla guida di svn).

Creiamole in una cartella tmp temporanea:

mkdir -p /tmp/progetto1/trunk /tmp/progetto1/branches /tmp/progetto1/tags

importiamole ora nel nostro repository utilizzando il comando:

svn import /tmp/progetto1/ file:///Volumes/development/repository/progetto1 -m "Creazione struttura svn"

Possiamo ora cancellare la cartella tmp:

rm -rf /tmp/progetto1

Infine per evitare problemi di sicurezza limitiamo l’accesso al repository intero al solo web server (se si utilizza la soluzione con Apache) e ai membri del team:

sudo chown -R www:admin /Volumes/development/repository/repository
sudo chmod -R ug+rwX,o= /Volumes/development/repository/repository

Se si utilizza la soluzione di svnserve allora è possibile associare i privilegi all’amministratore del computer:

sudo chown -R root:admin /Volumes/development/repository
sudo chmod -R ug+rwX,o= /Volumes/development/repository

AVVIARE IL SERVER SVNSERVE

Se si è scelto come server il pacchetto svnserve su ssh allora siamo già pronti ad utilizzare il nostro repository. Basterà infatti avviare sshd (il demone di ssh sul quale gira automaticamente svnserve) spuntando il checkbox “Remote Login” dal pannello “Sharing” delle preferenze di sistema.

CONFIGURARE IL SERVER APACHE

Come abbiamo già accennato in precendenza configurare il server Apache è un’operazione più delicata, ma tutto sommato agevole. Apriamo l’utility Server Admin e connettiamoci al nostro server (a meno di configurazioni particolari ne dovremmo avere soltanto uno in lista). Se il Web Server non è ancora attivo, avviamolo spuntando la voce “Web” nel pannello “Services” come in figura; poi premiamo Save (non dobbiamo assolutamente avviare/riavviare il server prima della fine della procedura di configurazione).

Il prossimo passo consiste nell’abilitare il modulo mod_dav_svn (parte di web_dav) che ci consentirà di abilitare le funzionalità di file sharing del server Apache. Insieme questi due moduli permetteranno ai client Subversion di leggere e scrivere sui repository tramite il protocollo http (semplificando quindi notevolmente la comunicazione con ambienti esterni).

Per abilitare mod_dav_svn clicchiamo sul pannello “Modules” del nostro server e dalla lista spuntiamo il checkbox dav_svn_module (non sarà necessario abilitare authz_svn_module a meno di non volere usare i directory services per l’autenticazione).

Con il modulo subversion abilitato, Leopard Server e Apache lavorano con il repository come fanno con un normale server WebDAV; la configurazione quindi è molto semplice: Creiamo allora un nuovo website sicuro (secure website) cliccando il pannello Sites dalla toolbar di Server Admin. Dalla lista clicchiamo il pulsante + per aggiungere un nuovo virtual host Apache; questo ci permetterà di definire un hostname univoco per il server, una porta ed eventualmente una cartella di root per il sito. Una volta configurati i parametri abilitiamo l’host spuntando il relativo checkbox dalla lista.

Se si fa da host per il solo subversion questa procedura è molto agevole. Differente è il caso in cui il server ospiti altri siti; sebbene generalmente un hostname univoco sia più che sufficiente ad evitare problemi, è bene comunque dare uno sguardo alla guida Web Technologies Admin per evitare possibili conflitti.

Come da figura, vediamo le impostazioni minime necessarie per l’hostname:

Domain Name: Se si ha un dominio qualificato si può inserire questo, altrimenti è possibile lasciare questo campo vuoto.
Description: Una breve descrizione del servizio (anche qui non succede nulla a lasciare bianco)
IP Address: Va impostato su “any”
Port: Va impostato sulla porta 443, che è quella di default per le connessione web sicure (SSL – vedremo più avanti come abilitarla).

Sempre dal pannello Sites alla voce “Options” abilitiamo il server WebDAV spuntando il relativo checkbox come da figura:
Il passo successivo è abilitare SSL utilizzando il certificato di default oppure, se lo si ha, il proprio.

L’utilizzo di SSL è fondamentale poichè permette di abilitare l’autenticazione sicura al repository tramite sessione HTTP.

Sarà ora necessario specificare quali cartelle mettere in condivisione tramite WebDav; lo facciamo spostandocinel tab “Realms” di “Sites” e cliccando il pulsante +.

La configurazione è la seguente:

Realm Name: "subversion"
Authentication: Basic.
Folder/Location Pop-up menu: selezioniamo 'Location' dal menu e nel campo scriviamo "/svn/ (ci servirà per reindirizzare il traffico sul modulo svn anzichè dentro una directory specifica) Più avanti faremo in modo che il server punti alla cartella scelta all'inizio per il nostro repository.

Sempre da Realms utilizziamo il pulsante + sotto la lista degli Utenti e Gruppi per agiungere tutti i membri del team che dovranno avere accesso al nostro repository (browse+read/write per gli sviluppatori, browse per chi non è membro attivo). E’ inoltre importante disabilitare i permessi per Everyone (ovvero l’accesso anonimo).

Una volta finito clicchiamo su Save in basso a destra.

Prima di poter avviare il server c’è un ultimo passo da compiere. Nascondiamo per un momento l’applicazione Server Admin e andiamo sul Terminale. Apriamo il file “0001_any_443_.conf” (se abbiamo configurato un hostname particolare, come ad esempio “miosito.com”, il file apparirà come “0001_any_443_miosito.com.conf”:

sudo vi /etc/apache2/sites/0001_any_443_.conf

Cerchiamo all’interno del file il blocco /svn/ (che con molta probabilità sarà alla fine del file) e aggiungiamo queste due line dopo “”:

DAV svn
SVNParentPath /Volumes/development/repository

La prima linea si occuperà di indirizzare le richieste per l’URI /svn/ verso il modulo apache; la seconda invece specificherà la directory del repository.

Se più avanti incontreremo problemi nell’accedere al nostro server, torniamo su questo file e cerchiamo se è presente l’istruzione “DAV no”: rimuoviamola e tentiamo nuovamente (riavviando il server).

Possiamo ora tornare a Server Admin, selezionare Web nella lista dei servizi e cliccare “Start Web” (o Restart se il server era già running).

CONCLUSIONI

Il nostro subversion repository sarà ora accessibile all’url:

https://your.hostname/svn/Project1

Una volta autenticati avremo anche la possibilità di accedervi e inserire i nostri file.

Se si fa uso di un client svn e si vuole accedere al repository:

- con svnserve [svn+ssh]: svn+ssh://accountname@hostname/Volumes/development/repository/progetto1

- con apache [https]: https://accountname@hostname/svn/progetto1

il tipo di connessione da configurare è https:// non svn. Se si è scelto di utilizzare svnserve invece èè svn+ssh://).

E questo è tutto!

Vi consiglio infine un paio di client svn molto buoni: si tratta di Cornerstone (probabilmente il più costoso, ma sicuramente il migliore sotto OS X) e, alternativa free, SVNx.

Se invece volete utilizzare l’SMC integrato di XCode, qui c’è una guida utile.