Installare e configurare un server SVN su CentOS

Questa guida mostra come installare, configurare e testare un server Subversion (SVN) su CentOS 6.4, con esempi pratici per creare repository, utenti, regole di accesso tramite Apache (mod_dav_svn) e test su client Linux e Windows (TortoiseSVN). Include procedure operative, controllo privilegi, risoluzione dei problemi e consigli di sicurezza.

Important: CentOS 6.4 è una release datata. Per ambienti di produzione valutare CentOS Stream, RHEL o alternative più recenti e aggiornare le versioni di Subversion e Apache.

Obiettivo e varianti di intento

Obiettivo primario: installare e configurare un repository SVN accessibile via HTTP(S) su CentOS. Varianti utili (parole chiave correlate): installare SVN su CentOS, configurare mod_dav_svn, creare repository Subversion, gestire permessi SVN, usare TortoiseSVN con CentOS.

Sommario rapido (che troverai in questa guida)

• Requisiti e note preliminari
• Installazione dei pacchetti: httpd, subversion, mod_dav_svn
• Creazione del repository e utenti
• Configurazione di authz e integrazione con Apache
• Test da client Linux e Windows (TortoiseSVN)
• Playbook operativo, checklist ruoli, casi di test e criteri di accettazione
• Alternative e modelli mentali, hardening e considerazioni GDPR
• Troubleshooting comune e rollback

1. Nota preliminare

Questa guida è stata realizzata usando CentOS 6.4 a 32 bit come sistema di esempio. I comandi e i percorsi mostrati sono riproducibili su sistemi analoghi; le parti rilevanti sono facilmente adattabili a distribuzioni più recenti.

Definizione rapida: SVN (Subversion) è un sistema di controllo versione centralizzato, pensato per tracciare modifiche di file e cartelle e gestire controlli di accesso a livello di repository.

2. Installazione di SVN e moduli Apache

Per un server SVN accessibile via HTTP(S) useremo Apache (httpd) con il modulo mod_dav_svn. In alternativa è possibile usare svnserve o altri web server (nginx con plugin), ma qui seguiamo l’integrazione con Apache.

Esempio: verificare IP e interfacce (output di ifconfig per riferimento):

ifconfig

(Esempio di output del sistema usato per la guida; non eseguire copy/paste dei valori di rete senza adattarli al tuo ambiente.)

Installare httpd:

yum install -y httpd

Output di esempio dell’installazione (ridotto):

[root@SVNSVR641 ~]# yum install -y httpd
Loaded plugins: refresh-packagekit, security
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package httpd.i686 0:2.2.15-26.0.1.el6 will be installed
--> Finished Dependency Resolution
Installed:
  httpd.i686 0:2.2.15-26.0.1.el6
Complete!

Installare subversion:

yum install -y subversion

Installare il modulo Apache per Subversion:

yum install -y mod_dav_svn

Nota: su sistemi moderni potresti trovare pacchetti più aggiornati e nomi di pacchetto diversi (es. httpd vs apache2). Se usi una repo aziendale, adatta i comandi yum/dnf al tuo gestore pacchetti.

3. Configurazione del repository SVN

Creare una directory dedicata per i repository (buona pratica per isolamento e backup):

mkdir -p /data/svn

Creare il primo repository chiamato repo1 e assegnarne la proprietà al processo web (apache) così che Apache possa accedervi:

svnadmin create /data/svn/repo1
chown -R apache:apache /data/svn/repo1

Contenuto tipico dopo la creazione:

cd /data/svn/repo1
ls
# output: conf db format hooks locks README.txt

3.1 File di configurazione principali

Dentro /data/svn/repo1/conf troverai almeno questi file: authz, passwd, svnserve.conf

Esempio di svnserve.conf (per svnserve; lasciato per completezza):

[general]
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz

Questo file imposta che gli utenti anonimi non hanno accesso e che l’autenticazione usa il file passwd e authz.

3.2 Creare utenti locali (file passwd)

Usiamo htpasswd per creare utenti che Apache userà per l’autenticazione Basic.

htpasswd -c /data/svn/repo1/conf/passwd jay
htpasswd /data/svn/repo1/conf/passwd fikri
htpasswd /data/svn/repo1/conf/passwd farid

Esempio di output (solo username:hash mostrati a scopo illustrativo):

[root@SVNSVR641 conf]# cat passwd
jay:14hCNCmBZY/qA
fikri:/hlooqJMfYLkw
farid:P7Zvu6B3HyFGo

Important: htpasswd salva hash; non conservare file passwd in luoghi non protetti. Per ambienti a maggiore sicurezza preferire autenticazione via LDAP/SSO o HTTPS con certificati client.

3.3 Controllo degli accessi (file authz)

Definizione semplice di regole di accesso per repo1:

vi /data/svn/repo1/conf/authz

Aggiungere:

[repo1:/]
farid = r
fikri = rw
* =

Interpretazione: farid ha solo lettura (r), fikri può leggere e scrivere (rw), tutti gli altri (*) non hanno accesso.

4. Configurare Apache per esporre il repository

Assicurarsi che httpd includa la directory conf.d (di solito è già presente in /etc/httpd/conf/httpd.conf):

Include conf.d/*.conf

Modificare il file /etc/httpd/conf.d/subversion.conf (o crearne uno nuovo) con questa configurazione:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so


DAV svn
SVNPath /data/svn/repo1
Authtype Basic
AuthName "My Repository"
AuthzSVNAccessFile /data/svn/repo1/conf/authz
AuthUserFile /data/svn/repo1/conf/passwd
Require valid-user

Spiegazione rapida: la Location /repo1 sarà servita da mod_dav_svn e risolverà sul filesystem il repository configurato in SVNPath. L’autenticazione è Basic con utenti definiti in AuthUserFile e autorizzazioni prese da AuthzSVNAccessFile.

Riavviare Apache per applicare le modifiche:

service httpd restart

Verificare che httpd parta senza errori.

5. Fase di test: client Linux

Su una macchina client Linux (es. CentOS Desktop) installare subversion e fare checkout:

yum install -y subversion
mkdir repo_client
svn co http://192.168.43.101/repo1 repo_client

Esempio di interazione: il client richiederà username e password. Se usi l’utente fikri (rw) potrai creare directory e committare.

Comandi prova:

cd repo_client
svn mkdir first_dir
svn commit -m "My first folder"
# output: Committed revision 1.

Nota: il client potrebbe avvertire che la password verrà salvata in chiaro. Per sicurezza, configurare la crittografia delle credenziali o usare chiavi/SSO.

6. Fase di test: client Windows (TortoiseSVN)

Apri il browser o TortoiseSVN e punta a:

http://192.168.43.101/repo1

Alt immagine: Finestra di autenticazione HTTP per repository SVN che richiede username e password

Se esegui il login con un utente non autorizzato otterrai accesso negato:

Alt immagine: Pagina di accesso negato (403 Forbidden) mostrata dal browser

Usando TortoiseSVN: crea una cartella locale, fai Right-click → SVN Checkout e inserisci l’URL del repository.

Alt immagine: Finestra di dialogo di TortoiseSVN per inserire l’URL del repository e il percorso di checkout

Login via TortoiseSVN con utente (es. farid per test read-only):

Alt immagine: Prompt di autenticazione di TortoiseSVN che richiede credenziali

Dopo il checkout vedrai i file e le cartelle (creati da altri utenti):

Alt immagine: Finestra di dialogo che indica il completamento del checkout del repository SVN

Lista directory locale con il contenuto del repository:

Alt immagine: Vista del file manager Windows che mostra la cartella locale popolata dal checkout SVN

Test di scrittura per utente read-only (farid): creare una cartella SECOND_DIR dentro FIRST_DIR, Add → Commit.

Alt immagine: Creazione di una nuova cartella locale dentro la working copy di TortoiseSVN

Aggiungere la directory alla working copy (TortoiseSVN → Add) e poi Commit. Al momento del commit, perché farid ha solo permessi r, il server risponderà con accesso negato:

Alt immagine: Errore di TortoiseSVN che mostra “Write access has been denied” per un utente con sola lettura

Questo conferma che le regole in authz sono applicate correttamente.

7. Procedura operativa (SOP) sintetica per mettere in produzione

1. Pianificare: scegliere host, backup e policy di accesso.
2. Preparare OS: aggiornare pacchetti di sistema e firewall.
3. Installare pacchetti: httpd, subversion, mod_dav_svn.
4. Creare struttura /data/svn e repo iniziali con svnadmin.
5. Configurare file passwd (o integrazione LDAP) e authz.
6. Configurare Apache con Location e abilitare HTTPS (consigliato).
7. Riavviare Apache e testare da client.
8. Abilitare backup regolari (dump o filesystem snapshot) e monitoraggio.

Criteri di accettazione

• Il repository risponde su HTTP(S) all’URL previsto.
• Gli utenti validi si autenticano correttamente.
• Le regole di authz restituiscono lettura/scrittura secondo la policy.
• Backup automatizzato e test di restore documentati.

8. Checklist per ruolo

Amministratore di sistema

• Configurare firewall e SELinux (o disabilitare solo se strettamente necessario)
• Abilitare HTTPS e redirect da HTTP a HTTPS
• Pianificare backup e test di restore

Sviluppatore

• Avere credenziali funzionanti
• Verificare accesso in lettura e/o scrittura richiesti
• Usare client aggiornati (svn client, TortoiseSVN)

Manager/Release

• Confermare policy di branching/releases su SVN (trunk/branches/tags)
• Validare che i commit passino review se richiesto

9. Alternative e quando preferirle

• svnserve (protocollo svn://): più leggero, utile per network chiusi o prestazioni migliori. Non integra facilmente permessi per path granulari via Apache.
• Accesso su HTTPS: raccomandato per produzione (Auth over TLS). Configure SSL in Apache e aggiornare URL di accesso a https://
• Migrare a Git: per progetti distribuiti moderni considerare Git; SVN rimane utile per repository centralizzati e grandi file binari se ben gestito.

Counterexample: se serve una collaborazione offline e branching pesante, SVN potrebbe risultare meno flessibile di Git.

10. Hardening (raccomandazioni di sicurezza)

• Abilitare HTTPS e disabilitare l’accesso HTTP non cifrato.
• Integrare autenticazione centralizzata (LDAP/AD) se disponibile.
• Proteggere i file passwd e authz con permessi filesystem stretti (chmod 640) e proprietà apache:apache.
• Tenere aggiornata la versione di Subversion e mod_dav_svn.
• Limitare gli IP che possono accedere al servizio tramite firewall.
• Monitorare i log di Apache per tentativi di accesso falliti.

11. Backup e ripristino essenziali

Strategia semplice di backup: usare svnadmin dump e compressione

svnadmin dump /data/svn/repo1 > /backup/repo1-$(date +%F).dump
gzip /backup/repo1-$(date +%F).dump

Per il ripristino:

svnadmin create /data/svn/repo1-restored
svnadmin load /data/svn/repo1-restored < /backup/repo1-2025-01-01.dump

Nota: testare periodicamente i restore in ambienti di staging.

12. Troubleshooting comune

Problema: “403 Forbidden” dal browser

• Controllare AuthzSVNAccessFile e AuthUserFile nei file di configurazione Apache.
• Verificare permessi filesystem: apache deve poter leggere la repository e i file conf.

Problema: “Write access has been denied”

• Controllare file authz per il path specifico.
• Controllare che l’utente autenticato corrisponda esattamente a quello elencato (case sensitive).

Problema: credenziali memorizzate in chiaro (avviso client)

• Configurare ~/.subversion/servers con store-plaintext-passwords=no e usare agent di credenziali o keyring appropriati.

13. Casi di test e criteri di accettazione (esempi)

Test 1: Login e lista repository

• Azione: visitare http:///repo1
• Atteso: prompt credenziali, dopo login la directory radice viene listata per utenti con permesso r.

Test 2: Commit utente rw

• Azione: checkout con utente fikri, creare file, svn add, svn commit
• Atteso: commit completato senza errori.

Test 3: Commit utente r

• Azione: checkout con utente farid, tentativo di commit
• Atteso: errore di autorizzazione e nessuna modifica sul server.

Test 4: Utente non presente

• Azione: login con utente non elencato
• Atteso: accesso negato (403) o autenticazione fallita.

14. Ridefinizione: migrazione e compatibilità

• Da SVN <-> Git: usare strumenti come git-svn per migrare la storia; valutare perdita di metadati specifici di SVN.
• Versione Subversion: attenzione a compatibilità formato repository (svnadmin upgrade/downgrade richiesti se si sposta tra versioni major).

15. Mini-glossario (1 riga per termine)

• Repository: archivio centrale dove Subversion memorizza la storia dei file.
• Checkout: copia locale di una revisione del repository.
• Commit: invio delle modifiche locali al server SVN.
• Authz: file che definisce autorizzazioni per repository e path.
• htpasswd: utility per gestire utenti e password in formato compatibile con Apache.

16. Rischi principali e mitigazioni

• Rischio: esposizione HTTP non cifrata → Mitigazione: forzare HTTPS e certificati validi.
• Rischio: perdita dati → Mitigazione: backup regolari e verifica dei restore.
• Rischio: permessi errati → Mitigazione: testare ruoli e policy in staging.

17. Esempio rapido di playbook (rollback)

Rollback di una commit problematica (amministratore):

1. Identificare la revisione problematica (svn log)
2. Creare reverse-merge nella working copy: svn merge -c -REV .
3. Testare localmente e poi svn commit -m “Revert rREV”

Se il rollback fallisce, ripristinare da dump o snapshot del filesystem.

18. Note GDPR e privacy

• Se il repository contiene dati personali, assicurarsi di avere base giuridica per trattarli e implementare controlli di accesso stretti.
• Proteggere i backup con cifratura se contengono dati personali.

19. Riepilogo e passaggi successivi

In questa guida hai visto come:

• Installare httpd, subversion e mod_dav_svn su CentOS
• Creare un repository e utenti con htpasswd
• Definire autorizzazioni granulari con authz
• Esporre il repository via Apache e testarlo con client Linux e Windows

Passaggi consigliati dopo l’installazione:

• Abilitare HTTPS
• Integrare autenticazione centralizzata se disponibile
• Automatizzare backup e monitoraggio

Note finali

Important: verifica sempre i permessi dei file, mantieni aggiornati i pacchetti e preferisci ambienti di test per validare le modifiche di configurazione prima della produzione.

Grazie per aver seguito questa guida. Se vuoi, posso generare uno script di installazione automatica (Ansible/ Bash) o un file di esempio per Apache configurato con HTTPS.