SubVersion con Apache 2 su Linux Ubuntu 11.10

Di seguito una revisione di un articolo già pubblicato relativo alla versione Ubuntu 7.04.

Hope this helps.

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 11.10.

Si presuppone che sul sistema sia installato Apache 2.

Il pacchetto indispensabile per subversion è semplicemetne “subversion”

Per cui procediamo alla sua installazione utilizzando il comando apt-get:

$ sudo apt-get install subversion

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:

$ sudo a2enmod dav_svn

Incidentalmente faccio notare che esiste un comando con funzione opposta, vale a dire per disabilitare un modulo: “a2dismod [nome modulo]”

CREAZIONE DEL REPOSITORY SVN

Installeremo il repository in /svn

Creiamo come prima cosa il gruppo ‘subversion’

$ sudo groupadd subversion

Aggiungiamo l’utente Apache, ovvero www-data, al gruppo subversion appena creato.

$ sudo usermod -G subversion www-data

Da notare come con il comando $ groups www-data sia possibile verificare il successo del comando precedente.

Passiamo ora alla creazione della cartelle fisiche sul file system per i repository:

$ sudo mkdir /home/svn

Spostiamoci nella cartella appena creata e creaiamo una ulteriore nuova cartella per il nostro primo progetto:

$ cd /home/svn

$ sudo mkdir tesseract

A questo punto passo alla creazione dle repository vero e proprio

$ sudo svnadmin create /home/svn/tesseract

Passiamo ora alla corretta impostazion dei permessi:

$ cd /home/svn

$ sudo chown -R www-data:subversion tesseract

Dove, con l’ultimo comando, impostiamo per la cartella ‘tesseract’ ed in maniera ricorsiva per tutte le sottocartelle come prorietrartio l’utente ‘www-data’ e come gruppo ‘subversion’

Ed infine:

$ sudo chmod -R g+rws tesseract

Per abilitare lettura e scrittura (rw) per il gruppo. Da notare il flag ‘s’. Questo, detto di norma setuid e’ necessario in quanto svnadmin deve creare i file durante operazioni tipo  commit.

CONFIGURARE L’ACCESSO A SVN

I repository di SVN possono essere gestiti tramite vari protocolli (file, http, https, svn+ssh, …). Sicuramente, il piu’ semplice è l’accesso via protocollo WebDAV (http://).

Per utilizzare questo protocollo è necessario configurare correttamente Apache. Si presuppone quindi l’installazione del pacchetto libapache2-svn:

$ sudo apt-get install libapache2-svn

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:

“Include /etc/apache2/sites-enabled/”

presente nel file di configurazione principale di Apache.

Un tipico file di configurazione di un host sarà qualcosa del tipo:

<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>

Da notare che dovranno essere presenti nel file di configurazione generale (apache2.conf) le seguenti righe:

NameVirtualHost 192.168.1.1:80

Dove 192.168.1.1 è l’IP della vostra macchina server

Include /etc/apache2/sites-enabled/

Per includere i file di configurazione degli host virtuali.

Per aggiornare il server al nuovo stato dare il comando:

sudo /etc/init.d/apache2 reload

APACHE E 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:

htpasswd -c /etc/apache2/users carlo

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:

——————————————-

carlo: xx1LtcDbOY4/K

——————————————-

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:

——————————————-

htpasswd /etc/apache2/users giuseppe

——————————————-

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:

require user carlo giuseppe

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:

amministratori:carlo giuseppe

segreteria:anna isabella antonella

Per l’autenticazione si può poi procedere, ad esempio, come segue:

require group amministratori segreteria

require user carlotta

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!
         

Il successo di un tipo di dati: il casting delle variabili in C

di Carlo A. Mazzone

Il nome dell’articolo potrebbe suggerire un qualcosa collegato al mondo dello spettacolo: niente di più lontano dalla verità. Il casting, nel contesto informatico, non ha assolutamente a che fare con la selezione di un certo sviluppatore come attore in un qualche film ma piuttosto con l’attribuzione del tipo di dati più adatto ad una data variabile per una determinata circostanza implementativa.

Inizio con una semplice constatazione: talvolta il risultato di certe operazioni tra tipi di dati può dare risultati del tutto inaspettati. Ma andiamo con ordine ponendoci questa domanda: cosa accade quando assegno ad una variabile il valore di un’altra variabile appartenente ad un tipo di dati diverso?

Mi spiego meglio; quando scrivo qualcosa del tipo:

x=y;

se x ed y sono dello stesso tipo, semplicemente il valore di y viene copiato in x. Tuttavia, se x è ad esempio di tipo intero ed y di tipo float inevitabilmente la parte frazionaria di y verrà persa nell’assegnazione del valore ad x, al limite con un avvertimento (warning) da parte del compilatore.

Ad esempio, il seguente codice:

int main(int argc, char *argv[])

{

int x;

float y=5.5;

x=y;

printf(“Il valore di x e’: %d\n”, x );

printf(“Il valore di y e’: %.2f\n”, y );

return 0;

}

produrrà come output:

Il valore di x e’: 5

Il valore di y e’: 5.50

In generale, infatti, le uniche conversioni che non generano problemi sono quelle che consentono di ampliare la dimensione di una variabile. Ad esempio, nessun problema, ovviamente, nel caso contrario quello appena visto in cui assegniamo un intero ad una variabile float ottenendo come risultato che la variabile float avrà come parte intera il valore intero del numero assegnato e come parte frazionaria il valore zero.

Il valore di x e’: 6

Il valore di y e’: 6.00

Questi tipi di conversione vengono detti conversioni implicite in quanto realizzate automaticamente dal compilatore. In altri casi, però, è necessario “forzare” un tipo di variabile ad essere diversa da quella che risulterebbe in maniera naturale: si parla allora di conversione esplicita. Tali conversioni vengono definite in modo gergale cast oppure casting, ed usando a volte espressioni come “castare una variabile”.

Vi propongo allora una situazione tipica:

int main(int argc, char *argv[])

{

int x=7, y=2;

float d;

d=x/2;

printf(“Il valore di d e’: %.2f\n”, d );

return 0;

}

poiché d è stata dichiarata come float ci si aspetterebbe come risultato il valore 3,5. Sbagliato! L’operazione di divisione tra due interi viene appunto intesa come un fatto “privato” tra interi che da come risultato un valore intero, nel nostro caso il valore 3, che solo successivamente viene assegnato alla variabile con la virgola d. Tale problema è comunissimo e si verifica ad esempio nel caso in cui si deve calcolare la media di un dato numero di elementi interi per il quali, nonostante si prevede una variabile di tipo float si otterrà comunque un numero intero. Per risolvere la situazione si usa allora il casting di cui vi dicevo con la seguente sintassi:

(tipo_dati) espressione

Ad esempio, nel nostro caso sarà sufficiente scrivere:

d=(float)x/2;

per ottenere in stampa il valore desiderato ed atteso di 3,5.

Supportaci condividendo sui social il nostro articolo!
         

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!