Subversion è un meraviglioso VCS (Version Control System) open source, spesso però non è utilizzato al meglio delle sue capacità. Parlando di configurazione e setup del servizio un modo semplice e tuttavia efficace di mettere in piedi Subversion è quello di utilizzare il protocollo svn+ssh:// anzichè il semplice svn://.
La versione sicura del protocollo nativo di Subversion è abbastanza semplice da configurare e consente:
Innanzitutto è preferibile generare delle host key per ciascun client in modo da evitare la richiesta continua di username e password visto che il client SVN non è in grado di cachare le credenziali di accesso di SSH (è SSH infatti che in questa configurazione ha l'incarico di gestire l'autenticazione).
Iniziamo con l'aprire (o creare se non esiste già) il file svn_user_home/.ssh/authorized_keys (dove svn_user_home indica la home folder dell'utenza con cui svnserve viene eseguito) ed andiamo ad aggiungere una riga per ciascun client in questo formato:
dove xxx è lo username che volete attivare mentre TYPE e KEY fanno riferimento al tipo ed all'hash della chiave generata per quell'utente... un momento: non abbiamo ancora generato la chiave! Facciamolo subito come indicato in questa mini guida.
Ovviamente nel file authorized_keys dovremo andare a mettere solamente la chiave pubblica, mentre la chiave privata dovrà essere consegnata all'utente che dovrà connettersi a Subversion.
A questo punto non resta che creare lo script svnserve.sh che andrà ad impostare una umask corretta (suggerisco 002) per l'utilizzo di SVN...
Dal punto di vista autorizzazione possiamo orientarci con l'utilizzo dei gruppi: suggerisco la creazione di almeno un gruppo per ogni progetto SVN, in questo modo i permessi di accesso al singolo progetto potranno essere gestiti aggiungendo o togliendo l'utente dal gruppo di riferimento (è a questo che serve il settaggio della umask).
Volendo essere precisi si può pensare di creare, per ciascun progetto, un gruppo per gli sviluppatori, un gruppo per i tester ed un gruppo per gli amministratori:
La versione sicura del protocollo nativo di Subversion è abbastanza semplice da configurare e consente:
- l'utilizzo di LDAP o RADIUS per lo storage degli utenti attraverso i moduli PAM di SSH;
- la gestione dei permessi di accesso ai diversi rami/progetti all'interno di uno stesso repository attraverso i permessi del filesystem;
- maggiore sicurezza nella comunicazione grazie alla crittografia del canale;
- maggiore velocità e semplicità di configurazione rispetto al protocollo https:// che necessita dell'integrazione con Apache.
Innanzitutto è preferibile generare delle host key per ciascun client in modo da evitare la richiesta continua di username e password visto che il client SVN non è in grado di cachare le credenziali di accesso di SSH (è SSH infatti che in questa configurazione ha l'incarico di gestire l'autenticazione).
Iniziamo con l'aprire (o creare se non esiste già) il file svn_user_home/.ssh/authorized_keys (dove svn_user_home indica la home folder dell'utenza con cui svnserve viene eseguito) ed andiamo ad aggiungere una riga per ciascun client in questo formato:
command="svnserve.sh", TYPE KEY xxx@domain.com
dove xxx è lo username che volete attivare mentre TYPE e KEY fanno riferimento al tipo ed all'hash della chiave generata per quell'utente... un momento: non abbiamo ancora generato la chiave! Facciamolo subito come indicato in questa mini guida.
Ovviamente nel file authorized_keys dovremo andare a mettere solamente la chiave pubblica, mentre la chiave privata dovrà essere consegnata all'utente che dovrà connettersi a Subversion.
A questo punto non resta che creare lo script svnserve.sh che andrà ad impostare una umask corretta (suggerisco 002) per l'utilizzo di SVN...
Dal punto di vista autorizzazione possiamo orientarci con l'utilizzo dei gruppi: suggerisco la creazione di almeno un gruppo per ogni progetto SVN, in questo modo i permessi di accesso al singolo progetto potranno essere gestiti aggiungendo o togliendo l'utente dal gruppo di riferimento (è a questo che serve il settaggio della umask).
Volendo essere precisi si può pensare di creare, per ciascun progetto, un gruppo per gli sviluppatori, un gruppo per i tester ed un gruppo per gli amministratori:
- prj-devels (lettura e scrittura su branches e trunk del progetto)
- prj-testers (lettura su tutto il progetto)
- prj-admins (lettura e scrittura su tutto il progetto)
