Riprendiamo l'installazione del server Subversion dalla precedente
Parte 3.
La parte 3 è stata un intermezzo; il discorso più importante è stato lasciato in sospeso alla fine della
Parte 2.
Ci occorre restringere opportunamente le possibilità di azione degli utenti del nostro server Subversion. Non vogliamo che i nostri utenti possano accedere liberamente ai file del repository, agli script che andremo a creare. Dovranno solo poter accedere ai dati contenuti nel repository stesso attraverso Subversion.
Vediamo come possiamo realizzarlo.
Torniamo a collegarci al nostro server con l'utente subversion.
Ci occorre creare uno script attraverso il quale automatizzare l'accesso esclusivo di Subversion al nostro repository.
Verifichiamo, sul nostro sistema Linux, dove si trova l'eseguibile del server di subversion, digitando
which svnserve.
In Debian, l'eseguibile si trova in /usr/bin. Dobbiamo crearne un
wrapper, che imposti la umask e restringa l'accesso alla directory contenente i repository (E' qui dove molte guide suggeriscono di rinominare il file svnserve e creare, un /usr/bin, uno script che richiami il binario con il nuovo nome. A noi questo non piace, vero?).
Per fare ciò creiamo una directory
bin all'interno della home dell'utente subversion, digitando
mkdir ~/bin. Entriamoci digitando
cd ~/bin.
Creiamo quindi il wrapper digitando
vi ~/bin/svnserve.
Digitiamo le seguenti righe:
#!/bin/sh
umask 0077
/usr/bin/svnserve -r /home/subversion/repo/ "$@"
Chiudiamo il file e salviamo (tasto ESC seguito da :wq).
Rendiamo il file eseguibile digitando:
chmod u+rwx ~/bin/svnserve
Abbiamo creato un eseguibile "svnserve" che imposta la directory da servire nella nostro repository.
A questo punto non ci resta che tornare al nostro file
~/.ssh/authorized_keys e far sì che l'utente svn01, al collegamento, sia 'forzato' ad accedere direttamente a svnserve.
Per fare questo digitiamo
vi ~/.ssh/authorized_keys e aggiungiamo, in testa alla riga contenente la chiave pubblica dell'utente svn01:
command="~/bin/subversion-server -t --tunnel-user=svn01",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
Il risultato finale é il seguente:
Concludiamo il post verificando il corretto funzionamento del nostro server di Subversion.
Su una macchina Windows (più avanti proveremo anche un client su un Desktop Environment Linux e su un ambiente di sviluppo, come Eclipse e Visual Studio) installiamo
TortoiseSVN (
http://tortoisesvn.net/).
Una volta installato, proviamo a collegarci al nostro repository. TortoiseSVN è una shell extension: posizioniamoci, per esempio, sul desktop e clickiamo con il tasto destro, selezionando TortoiseSVN -> Repo Browser.
Nella finestra che apparirà, digitiamo
svn+ssh://svn01.subversion.homeserver/Repo01.
Se tutto è andato bene, non ci verrà chiesta alcuna password, e vedremo questo risultato:
Naturalmente, il repository è vuoto. Ma se vi compare questa finestra, vuol dire che avete eseguito correttamente tutti i passaggi.
Se vi state chiedendo come mai non vi è stata richiesta alcuna password, la risposta sta nella
Parte 3, e nel tool Pageant. Quando avete caricato la chiave privata, vi è stata chiesta la password. Una volta fornita, la chiave è aperta, e TortoiseSVN si avvale di PuTTY e Pageant per connettersi al server.
Se invece non avete ottenuto altro che finestre che richiedono la password, probabilmente la vostra chiave non è al momento caricata in Pageant (magari, avete riavviato il PC!). Avviate Pageant se non è ancora attivo e caricate la chiave come descritto nella
Parte 3, e riprovate!
Nella prossima parte proveremo ad aggiungere un utente, e verificare che, nonostante l'utente Linux sia uno solo, i file appartengono agli utenti da noi creati (svn01, svn02 e così via).
Si prosegue con la
Parte 5, ricca di screenshot!
Cito la fonte da cui ho attinto informazioni utili per questa guida:
http://tortoisesvn.net/ssh_howto.html
