SVN ed il controllo degli accessi 2: la vendetta

E’ possibile rendere più fine il controllo degli accessi sui repository di SVN che utilizzano Apache 2 rispetto alle impostazioni standard che prevedono che un utente possa semplicemente accedere in lettura e scrittura ad uno specifico repository nella sua globalità.

Ad esempio, potrebbe essere possibile, in caso di necessità, voler consentire ad un dato utente l’accesso in lettura ad un repository e l’accesso in lettura e scrittura su di un altro repository. Ancora, potrebbe essere richiesto, relativamente ad uno stesso repository di abilitare la lettura o la scrittura su specifiche sottodirectory.

Per ottenere questa maggiore granularità di controllo con SVN è possibile modificare la configurazione del file di Apache rimuovendo, se presente, la riga: 

AuthGroupFile /etc/apache2/groups

che gestisce i gruppi “classici” ed aggiungere la direttiva:          

Require valid-user

che richiederà la validazione per tutti gli utenti che tenteranno di accedere al repository. Ovviamente /etc/apache2/groups è un file  specifico di un esempio specifico e potrebbe avere un nome differente in base a scelte personali.    

A questo punto è possibile aggiungere una riga come la seguente:

AuthzSVNAccessFile /etc/apache2/svnaccessfile

che indica il file sul quale verranno impostati i permessi di accesso.

In definitiva avremo qualcosa del tipo:

<Location /miorepo>
DAV svn
SVNListParentPath on
SVNPath /percorso/miorepo
AuthType Basic
AuthName “SVN repository”
AuthUserFile /etc/apache2/users
Require valid-user
AuthzSVNAccessFile /etc/apache2/svnaccessfile
</Location>


Il file in questione, /etc/apache2/svnaccessfile,  è un file di testo come il seguente:

[groups]
readers = michele
devs = carlo, marco, luigi, simone, daniele

[miorepo:/]
@readers = r
@devs = rw

#abilitazione-disabilitazione selettiva sottodirectory
[miorepo:/trunk/ProgettoX/cartellaY/cartellaZ]
carlo = rw

La direttiva [groups]  indica, così come ci aspetteremmo, i gruppi di utenti. Tali utenti sono ovviamente quelli inseriti con la normale procedura nel file  /etc/apache2/users

Le successive direttive, banalmente individuabili grazie al fatto di essere identificate da parentesi quadre specificano qualcosa del tipo:

[repository:percorso]

dove “repository” è ovviamente il nome del repository che si intende gestire e percorso è la cartella del repository stesso. Ad esempio:

[miorepo:/]

indica nella sua totalità il repository  “miorepo”.
I permessi specifici andranno inseriti nelle righe di seguito come ad esempio:

[miorepo:/]
@readers = r
@devs = rw

Si intuisce che ogni riga di abilitazione è formata da due sezioni separate dal simbolo “=”. Nel caso specifico ho inserito i nomi dei gruppi definiti nella sezione apposita. Si intuisce anche che per indicare i gruppi si antepone al nome del gruppo il simbolo della chiocciolina.
I simboli “r” e “rw” stanno ovviamente, rispettivamente, per sola lettura e lettura scrittura. Oltre ai nomi dei gruppi è possibile indicare i nomi dei singoli utenti, così come il carattere jolly * ad indicare tutti gli utenti.

Come detto è possibile settare i permessi di lettura/scrittura anche su di una specifica sottodirectory come segue:

[miorepo:/trunk/ProgettoX/cartellaY/cartellaZ]
carlo = rw

dove /trunk/ProgettoX/cartellaY/cartellaZ è il percorso nel repository che si vuole gestire in maniera differente rispetto alle restanti sezioni.

Per chiudere segnalo il seguente link di sicuro interesse:
http://svnbook.red-bean.com/en/1.1/ch06s04.html

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

Router Wireless su macchina Linux

Realizzazione di un hotspot wireless basato su di una macchina Linux, scheda di rete PCI  ed il demone hostapd (di Carlo A. Mazzone)

La presente procedura consente la realizzazione di un hotspot wireless basato su di una macchina Linux ed il demone hostapd (http://w1.fi/hostapd/).

La macchina è dotata di due schede di rete: una prima eth standard ed una seconda scheda PCI wireless.

La scheda eth0 ha come default gateway l’IP del router di uscita su Internet ed nel nostro caso un IP di classe C sulla rete 192.168.0.0 mentre la scheda wireless avrà un indirizzo 192.168.1.1 e quindi su di un’altra classe C intranet.

Sarà compito del software iptables far ruotare i pacchetti dalla rete wireless verso quella wired e quindi verso Internet.

La prima fase prevede una classica installazione della versione server di Linux. La prova è stata effettuata con Ubuntu 10.10 server 32 bit.
E’ consigliabile l’installazione di un server ssh per la gestione da remoto della macchina in oggetto.

Passiamo ora alla configurazione dei parametri di rete. Se durante l’installazione sono già stati indicati i parametri di rete per la eth0 (IP, netmask, …) sarà necessario agire solo quelli relativi alla scheda wireless. Se invece durante l’installazione è stato individuato un server DHCP sarà necessario modificare a mano i parametri di rete nel classico file /etc/network/interfaces

Di seguito il file di configurazione rete

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 192.168.0.11
netmask 255.255.255.0
gateway 192.168.0.1


Per apportare le modifiche senza riavviare la macchina è sufficiente dare il comando:

sudo /etc/init.d/networking restart

Passiamo ora ad esaminare la situazione della scheda wireless. Alcuni comandi ci possono venire incontro per individuare le caratteristiche precise della scheda in oggetto. Ad esempio:

sudo lshw

oppure in maniera ancora più dettagliata relativamente alla componentistica di rete:
sudo lshw -C network

dal quale, nel nostro caso otteniamo:

description: Wireless interface
product: AR5413 802.11abg NIC
vendor: Atheros Communications Inc.

e su di una linea successiva la seguente dicitura:

capabilities: pm bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation

che, tra le altre cose, ci rassicura sul fatto che la nostra scheda supporta la modalità MASTER, ovvero la possibilità di funzionare come hotspot.

Un altro possibile comando che ci conforta sulla nostra dotazione hardware è:

sudo lspci
che produce il seguente output:

01:09.0 Ethernet controller: Atheros Communications Inc. AR5413 802.11abg NIC (rev 01)

Se avessimo utilizzato una scheda di tipo USB avremmo potuto usare il comando: lsusb

Il comando: sudo iwconfig
potrà chiarirci meglio la situazione della nostra scheda di rete. Per poterlo utilizzare deve essere stato precedentemente installato il pacchetto wireless-tools eventualmente così come segue:

sudo apt-get install wireless-tools

Nel nostro caso l’output di iwconfig sarà:

lo        no wireless extensions.
eth0      no wireless extensions.
wlan0     IEEE 802.11bg  ESSID:off/any
Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm
Retry  long limit:7   RTS thr:off   Fragment thr:off
Encryption key:off
Power Management:off


Scopriamo così che il nome della scheda è wlan0 ed utilizziamo allora tale informazione per configurare la scheda stessa nel file /etc/network/interfaces con le seguente impostazioni:

# wireless settings
auto wlan0
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0

ed a questo punto anche la scheda wireless dovrebbe essere pronta e funzionante.

E’ ora finalmente giunto il momento di installare il software necessario al funzionamneto della scheda come access point, ovvero il demone hostapd.

Diamo allora il comando: sudo apt-get install hostapd

Il demone hostapd richiede, al momento del lancio, un file di testo con la configurazione da utilizzare. Supponendo di voler utilizzare una protezione di tipo wpa chiamiamo il file di configurazione  wpa.conf (ma potrebbe chiamarsi pippo.conf e le cose non cambierebbero di un bit ;). Per la creazione del file possiamo utilizzare il comando touch.

Di seguito presento il file in questione.

File di configurazione per hostapd (protetto)

interface=wlan0
driver=nl80211
ssid=RETE_DI_PROVA
channel=1
hw_mode=g
auth_algs=3
wpa=3
wpa_passphrase=qui_va_la_password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
rsn_pairwise=CCMP

Volendo fare una veloce prova si può utilizzare un file con il contenuto seguente che abilita un access point senza protezione. Il tutto ovviamente da utilizzare per breve tempo per ragioni di sicurezza al solo scopo di provare velocemente una configurazione il più semplice possibile:

File di configurazione per hostapd (aperto)

interface=wlan0
driver=nl80211
ssid=Fly_OPEN
channel=1

Un altro passo indispensabile è ora quello di configurare un demone DHCP per assegnare un IP dinamico alle macchine che si collegheranno in modalità wireless al nostro access point. Procediamo allora con l’installazione del dhcp:

$sudo apt-get install dhcp3-server

Il file di configurazione è:

/etc/dhcp3/dhcpd.conf

Come di consueto conviene fare una copia di backup del file in questione:

$sudo cp dhcpd.conf dhcpd.conf_orig

Una possibile configurazione potrebbe essere la seguente:

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.2 192.168.1.254;
option routers 192.168.1.1;
}

Per completare non resta che abilitare il routing con iptables. Le seguenti righe di configurazione possono essere inserite nel file rc.local per un avvio in automatico al boot della macchina.

#INIZIO rc.local
#Autorizzo l’interfaccia wlan0 ad accettare nuove connessioni e la istruisco a forwardarle verso l’esterno attraverso l’interfaccia eth0
iptables -A FORWARD –in-interface wlan0 –out-interface eth0 –source 192.168.0.0/255.255.255.0 -m state –state NEW -j ACCEPT
iptables -A FORWARD -m state –state ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state –state RELATED -j ACCEPT

#NATTING per mascherare gli ip della lan
iptables -t nat -A POSTROUTING -j MASQUERADE

#Attivo il packet forwarding a livello kernel
echo 1 > /proc/sys/net/ipv4/ip_forward

#Lancio demone per access point
hostapd /etc/hostapd/wpa.conf

#FINE  rc.local

Di seguito alcuni riferimenti interessanti:
https://help.ubuntu.com/community/WifiDocs/MasterMode
http://w1.fi/hostapd/

Carlo A. Mazzone

Supportaci condividendo sui social il nostro articolo!

System Rescue Cd 1.3.0

SystemRescueCd è un sistema  basato su Linux per il recupero di hard disk “rovinati” disponibile come CD avviabile o su penna USB. Risulta di eccezionale utilità  per per l’amministrazione  e la riparazione di sistemi dopo un crash.

Il suo scopo è di fornire un modo semplificato per creare ed editare partizioni dell’hard disk. E’ dotato di diversi tools  di sistema come parted, partimage, fstools ed altri classici e basilari come midnight commander.  Il kernel supporta svariati tipi di file system (ext2/ext3/ext4, reiserfs, reiser4, btrfs, xfs, jfs, vfat, ntfs, iso9660)ma anche network filesystems (samba and nfs).

Supportaci condividendo sui social il nostro articolo!

Aggiornamento di un sistema Ubuntu Server

L’aggiornamento (detto anche upgrade) di un software è importante; fondamentale quando il software in questione è un sistema operativo.
Di seguito riporto qualche indicazione per l’upgrade di Ubuntu relativamente alla versione server.

Come noto le versioni di Ubuntu vengano rilasciate ogni 6 mesi e riportano un numero di versione del tipo aa.mm
dove aa è l’anno di rilascio e mm il mese.
Ad esempio Ubuntu 9.04 è la versione rilasciata nell’aprile dell’anno 2009.
Di tanto in tanto vengono rilasciate delle patch per aggiornare la versione corrente.

Per aggiornare la propria versione corrente con tali ultime patch si può procedere come segue:

$sudo apt-get update (per aggiornare la sources.list per nuovi pacchetti)
$sudo apt-get upgrade


L’aggiornamento ad una nuova versione (release) è invece una cosa diversa. Questa, infatti, consiste nel passare letteralmente alla versione successiva.
Ad esempio dalla versione 8.10 alla 9.04. Oppure dalla 8.04 alla versione 9.04. E qui c’è però da fare una precisazione importante: è assolutamente sconsigliato aggiornare direttamente da una versione ad un’altra saltando gli aggiornamenti intermedi. Al contrario bisogna procedere aggiornandosi prima alle versioni immediatamente successive fino ad arrivare all’ultima disponibile oppure, in alternativa, effettuare una clean/fresh install (cioè una NUOVA installazione).

Canonical Ltd,  società fondata e gestita dall’imprenditore sudafricano Mark Shuttleworth, che è dietro al progetto Ubuntu, sa quanto può essere oneroso un aggiornamento continuo a nuove versioni di un sistema operativo e su questa considerazione rende disponibili delle specifiche versioni, denominate LTS (Long Time Support) che prevedono rilasci specifici di patch per un lungo periodo di tempo.

Attualmente, ad esempio, è disponibile per il download, oltre alla versione 9.04, la versione Ubuntu 8.04 LTS Server: rilasciata ad Aprile 2008 e supportata fino ad Aprile 2013.

Per aggiornare un sistema ad una nuova release conviene in ogni caso consultare il sito ufficiale di ubuntu (www.ubuntu.com) per seguire le istruzioni relative alla specifica versione. A titolo di esempio di seguito riporto la procedura, in questo caso semplice e minimale, da seguire per aggiornare ubuntu server dalla versione 8.10 alla versione 9.04: 

1. Installare update-manager-core: sudo apt-get install update-manager-core
2. Aprire il programma di aggiornamento: sudo do-release-upgrade
3. Seguire le istruzioni

Chiudo con una nota importante: per verificare la versione attualmente installata sul proprio sistema è possibile utilizzare il seguente comando:
$lsb_release -a

Carlo Mazzone

PS
Ovviamente Murphy con la sua legge è sempre in agguato per cui il consiglio è sempre quello di evitare aggiornamenti critici il venerdi (non vorrete mica passare l’intero fine settimana in azienda ?!)

Supportaci condividendo sui social il nostro articolo!

Installazione di un FTP Server su Ubuntu con ProFTPD

FTP (File Transfer Protocol) è un protocollo utilizzato per lo scambio di file tra computers operante in modalità client/server.
All’interno della distribuzione Linux Ubuntu è disponibile di default il server vsftpd. la sua installazione è molto semplice:

#sudo apt-get install vsftpd

Il file di configurazione è /etc/vsftpd.conf ed il demone (così si definisce un “servizio” sotto Linux) è avviabile con il comando:

#sudo /etc/init.d/vsftpd start

Per ragioni di sicurezza, stabilità e scalabilità preferiamo l’installazione di un server ftp alternativo: ProFTPD

Per l’installazione utilizziamo il seguente comando:

#sudo apt-get install proftpd

Dopo il tempo necessario allo scaricamento del pacchetto la procedura di installazione chiede se si desidera una configurazione che giri da inetd o standalone.

Per semplicità lo installiamo come “standalone”. Per funzionamento standalone (autonomo) si intende che il demone si pone in ascolto su di una specifica porta e deve preoccuparsi in proprio delle varie funzionalità connesse al proprio funzionamento tra le quali quelle relative alla gestione degli accessi non autorizzati. In caso contrario è il “super server” inetd a lanciare lo specifico demone solo in caso di effettiva necessità ed a gestire un ulteriore sistema di controllo attraverso un altro programma: il tcpd.

Dunque selezioniamo la voce  standalone e procediamo.

Il file di configurazione standard è:

/etc/proftpd.conf (oppure /etc/proftpd/proftpd.conf)

Procediamo ora alla modifica di una serie di voci del file in questione per “customizzare” la nostra installazione in particolare per quanto riguarda la sicurezza dell’installazione stessa.

ServerName – Imposta il nome visualizzato agli utenti che si connettono al server

ServerName “Test server”

ServerIdent – Imposta il messaggio da mostrare agli utenti che si connettono

ServerIdent on “Benvenuto sul nostro server ftp”

Nel caso in cui ServerIdent sia off verrà mostrato un messaggio di default

UseReverseDNS – Imposta, se su on, una ricerca del DNS reversal. Si consiglia di impostarlo su off.

UseReverseDNS off

DefaultRoot – Imposta la root di default dell’utente connesso.
ATTENZIONE: è molto importante decommentare la seguente linea per impedire la navigazione all’interno dell’intero file system da parte degli utenti connessi.
Non a caso il commento alla linea in questione all’interno del file di configurazione è: “# Use this to jail all users in their homes”

DefaultRoot ~

Per un elenco completo delle direttive è possibile fare riferimento al sito ufficiale di ProFTPD all’URL http://www.proftpd.org/

Dopo la modifica del file di configurazione è necessario far ripartire il demone per rendere effettive le modifiche apportate:

sudo /etc/init.d/proftpd restart

Nota: e’ possibile effettuare  un test relativo alla sintassi utilizzata all’interno del file di configurazione proftpd.conf utilizzando il seguente comando:

sudo proftpd -td5

Supportaci condividendo sui social il nostro articolo!

Configurazione di SubVersion con Apache 2 su Ubuntu 7.04

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

www.tesseract.it

Supportaci condividendo sui social il nostro articolo!