In un sistema Linux, capita molto spesso di dover eseguire un certo file, un particolare comando oppure una serie di operazioni in uno specifico momento della giornata. Un caso classico è rappresentato da operazioni di backup dei dati da effettuarsi preferibilemente in orario notturno.

Per realizzare tali scopi i sistemi Linux mettono a disposizione il demone cron che, opportunamente istruito tramite specifici file di configurazione, è in grado di mandare in esecuzione tutto ciò di cui necessitiamo.

Il nome cron deriva probabilmente dal dio greco del tempo Chronos. In realtà l’origne del nome non è certa ed esso potrebbe anche essere l’acronimo derivante dalle espressioni “Commands Run On Notice” oppure “Commands Run Over Night”. In ogni caso il nostro demone legge uno specifico file noto come crontab (ovvero cron table) ed esegue alle temporizzazioni in esso indicate i comandi corrispondenti.

Un prima verifica dello stato del nostro sistema può essere effettuata usando l’apposito comando, chiamato appunto crontab, come mostrato di seguito:

carlo@foo:~$ crontab -l

dove carlo è (ovviamente) il nome dell’utente collegato al sistema e foo il nome della macchina.

L’opzione –l (ovvero il trattino seguito dalla lettera elle) consente di “listare” il contenuto del file di configurazione associato all’utente che lancia il comando in oggetto. Nel nostro caso, e nella situazione in cui il sistema non è ancora stato istruito ad eseguire comandi, dovremmo vedere in output un messaggio del tipo:

no crontab for carlo

Sebbene sia possibile editare direttamente i file di configurazione per i nostri job (attività da eseguire) è conveniente richiamare il file attraverso il comando crontab accodando l’opzione –e, come mostrato di seguito:

carlo@foo:~$ crontab -e

Tale comando aprirà un editor di testi per la modifica di un file predefinito. La prima volta che si richiama il comando in oggetto sarà possibile indicare l’editor di propria preferenza da una lista minimale all’interno della quale si suggerisce l’uso dell’editor nano. Il file di default visualizzato sarà il seguente:

 

# Edit this file to introduce tasks to be run by cron.

#

# Each task to run has to be defined through a single line

# indicating with different fields when the task will be run

# and what command to run for the task

#

# To define the time you can provide concrete values for

# minute (m), hour (h), day of month (dom), month (mon),

# and day of week (dow) or use ‘*’ in these fields (for ‘any’).#

# Notice that tasks will be started based on the cron’s system

# daemon’s notion of time and timezones.

#

# Output of the crontab jobs (including errors) is sent through

# email to the user the crontab file belongs to (unless redirected).

#

# For example, you can run a backup of all your user accounts

# at 5 a.m every week with:

# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

#

# For more information see the manual pages of crontab(5) and cron(8)

#

# m h dom mon dow command

 

Ovviamente le linee che inziano con il simbolo di cancelletto non sono eseguite in quanto tale simbolo introduce un commento. L’ultima riga indica quale deve essere il formato da utilizzarsi per inserire i comandi da far eseguire al nostro demone. Come si può osservare nelle prime due posizioni indichiamo il minuto (tra 0 e 59) e l’ora (tra 0 e 59) in cui si vuole far eseguire il comando. Successivamente indichiamo il giorno del mese (tra 1 e 31) e il mese dell’anno (tra 1 e 12). Infine, prima del nome del comando possiamo indicare il giorno della settimana in cui verrà eseguito il comando, usando un numero da 0 a 6, dove 0 indica la domenica, 1 il lunedì e così a seguire con il 6 che indica il sabato.

Se si vuole eseguire un dato comando in un giorno qualsiasi è possibile usare un asterisco. Ad esempio la seguente riga:

00 01 * * * /sbin/miocomando

Eseguirà il comando indicato all’una di notte di tutti i giorni della settimana.

Una volta inserita la sequenza di comandi all’interno del file sarà sufficiente salvare il file con CTRL+O e una volta usciti dall’editor (CTRL+X) sarà tuttavia necessario riavviare il demone cron per fargli leggere la nuova configurazione. A tal fine usaremo il comando:

sudo /etc/init.d/cron restart

In alcuni casi, soprattutto quando si è in fase di testing della configurazione può essere utile porsi in ascolto sul log di sistema a caccia di eventuali errori che potrebbero verificarsi. A tal fine useremo il comando:

tail -f /var/log/syslog

A volte è sarà necessario schedulare delle attività che richiedono i permessi di root. In questo caso dovremo lanciare l’editing del file crontab con il prefisso sudo (superuser do) come mostrato di seguito:

carlo@foo:~$ sudo crontab -e

Una volta effettuate le modifiche del caso si procederà con il normale salvataggio prima dell’uscita dall’editor. Volendo visualizzare quindi il file di configurazione specifico per il superutente sarà sufficietne richiamare il comando crontab con l’opzione –l facendo però precedere tale comando dal sudo, come mostrato di seguito:

carlo@foo:~$ sudo crontab -l

Come è intuibile, le opzioni di configurazione sono molteplici. Ad esempio è possibile specificare orari multipli indicandoli separati da una virgola. Nello specifico la riga:

0,15,30,45 * * * * /sbin/miocomando

Schedula il comando per l’esecuzione ogni quarto di ora di ogni ora di ogni giorno.

Infine è possibile utilizzare il simbolo del trattino per indicare specifici intervalli di tempo. Ad esempio:

00 08 * * 1-5 /sbin/miocomando

Schedula il nostro comando per essere eseguito alle otto di mattina di tutti i giorni dal lunedì al venerdì.

 

Carlo A. Mazzone

Può essere interessante in ambito laboratoriale o di sviluppo all’interno di un dato gruppo di lavoro abilitare su di una macchina Linux con web server Apache la possibilità per i singoli account utente di utilizzare una specifica cartella per i propri file html e php.
Per farlo è necessario innanzitutto abilitare il modulo userdir con lo specifico comando:

sudo a2enmod userdir

Analizzando il file di configurazione

/etc/apache2/mods-enabled/userdir.conf

si noterà come la cartella nella quale ci si aspetterà di organizzare i file è public_html.

II singolo utente creerà dunque i suoi file nella cartella /home/nomeutente/public_html/
Ovviamente dovrà innanzitutto creare tale cartella, trovandosi nella propria home, con il comando:

mkdir public_html

Per accedere via web con il proprio browser a tali file si userà l’URL:

http://127.0.0.1/~nomeutente/

sostituendo l’indirizzo localhost 127.0.0.1 con l’IP o il nome della macchina in questione.

Gestione PHP
Per abilitare all’esecuzione di script PHP è necessario editare il file:

/etc/apache2/mods-available/php5.conf

In esso bisogna commentare le righe seguenti:
#
#
# php_admin_value engine Off
#
#

Ovviamente bisognerà riavviare apache:

sudo service apache2 restart

Happy coding.

Carlo A. Mazzone

La presente brevissima guida descrive in estrema sintesi l’installazione e configurazione di un server DHCP su di una macchina Linux Ubuntu.  Come dovrebbe essere noto il DHCP, ovvero Dynamic Host Configuration Protocol, è un protocollo di rete utilizzato per configurare in maniera dinamica, potremmo dire “al volo”,   le schede di rete al fine di minimizzare gli sforzi necessari per manutenere configurazioni di tipo statico. In soldoni, invece di definire manualmente l’indirizzo IP, la netmask, il gateway di default, DNS, ecc. ecc. necessari per consentire alla specifica macchina di “navigare”    in rete, demandiamo il tutto al server DHCP. E’ intuitivo riflettere sull’utilità di tale approccio soprattutto quando i dispositivi in questione sono di tipo mobile.

Partiamo come di consueto con l’installazione sul server, nel mio caso un Ubuntu 12.04.1 LTS, del pacchetto richiesto:

$sudo apt-get install isc-dhcp-server

Per chi avesse già installato in tempi precedenti un server DHCP c’è da considerare la possibilità di andare in confusione. Infatti, il pacchetto che utilizzavamo un po’ di tempo fa, ovvero dhcp3-server  è stato rinominato in isc-dhcp-server.  In realtà anche se dessimo il comando:

$sudo apt-get install dhcp3-server

il risultato dovrebbe essere lo stesso. Ciò è testimoniato dal fatto che in risposta al comando:

$ apt-cache search dhcp3-server

otteniamo:

isc-dhcp-server – ISC DHCP server for automatic IP address assignment
dhcp3-server – ISC DHCP server (transitional package)
isc-dhcp-server-ldap – DHCP server able to use LDAP as backend

In buona sostanza i due pacchetti sono la stessa cosa.

A voler fare i “precisini”, e chi mi conosce spesso mi mette in questa categoria, il prefisso “isc” nel nome del pacchetto fa riferimento all’ Internet Systems Consortium(ISC), un’organizzazione che sviluppa e manutiene  una varietà di software tra cui  BIND, INN ed appunto una implementazione del DHCP. Per comprendere l’importanza di tale organizzazione pensate che il suo sito web, www.isc.org, ha un page rank Google di 7 che è di tutto rispetto.

Nel caso in cui sul server fossero presenti più schede di rete è possibile “bindare”, cioè legare, ad una specifica eth del server il demone in questione. Tutto ciò è possibile grazie al file:

/etc/default/isc-dhcp-server

Il file di configurazione principale è /etc/dhcp/dhcpd.conf

Al solito, prima di metterci le mani sopra e modificarlo, è saggio farsi una copia di backup dello stesso:

sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf_BAK

Dunque per la modifica si può procedere con:

sudo nano /etc/dhcp/dhcpd.conf

Di seguito una configurazione minimale ma funzionante del suddetto file:

# (configurazione minimale per lan interna )

ddns-update-style none;

option domain-name “example.org”;
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.130 192.168.0.254;
}

Per riavviare:

sudo service isc-dhcp-server restart

Nota finale:  per verificare i lease è possibile usare il comando:

sudo tail /var/lib/dhcp/dhcpd.leases

Hope this helps 😉

Carlo A. Mazzone

La prima volta che feci conoscenza con il pacchetto Usermin fu quando ero in cerca di un sistema per consentire agli utenti, gestiti tramite una macchina Linux, di poter cambiare la propria password senza costringerli all’uso della shell testuale tramite un brutale passwd.

Usermin, una interfaccia web molto simile a Webmin, consente questa e tante altre possibilità.

Infatti Usermin consente ad utenti non amministratori (non root) di macchine Unix like di eseguire operazioni che dovrebbero essere normalmente realizzate tramite il prompt della shell. La similarità con Webmin è dovuta al fatto che gli autori sono gli stessi per entrambi i pacchetti mentre al differenza sostanziale, come avreste dovuto già intuire, è data dal fatto che Webmin è indirizzato agli  utenti che si loggano come root, essendo amministratori del sistema, mentre Usermin è dedicato agli utenti normali.

Tra le varie possibilità messe a disposizione da Usermin al “normal user” loggato via web mi viene da citare l’interfaccia webmail, la possibilità di configurare il proprio  Procmail per la gestione del forwarding e dello spam, la gestione di database  MySQL e PostgreSQL e la modifica del file .htaccess.

Ovviamente l’amministratore può definire un controllo molto fine su quali di queste operazioni risultano disponibili all’utente in questione.

Dopo questo ampio preambolo credo proprio sia il caso di passare all’azione.

La procedura descritta è stata verifica su di una macchina Linux Ubuntu ed il modo migliore  che consiglio in tale contesto  per installare ed aggiornare Usermin è quello di usare APT (Advanced Packaging Tool).

La prima operazione è richiesta è dunque quella di modificare il file  /etc/apt/sources.list aggiungendo la riga seguente:

deb http://download.webmin.com/download/repository sarge contrib

Attenzione che questa riga è la stessa richiesta per Webmin per cui se quest’ultimo lo  si  è già installato non è necessario aggiungerla. Installare preventivamente Webmin è proprio quello che vivamente consiglio in quanto l’amministrazione di tutte le funzionalità di Usermin saranno gestite appunto tramite l’interfaccia web di Webmin in maniera del tutto naturale. L’alternativa consisterebbe nell’editing diretto dei file di  configurazione nella directory /etc/usermin.

Procediamo dunque con l’installazione di Usermin lanciando i seguenti comandi:

apt-get update
apt-get install usermin

Tutte le dipendenza richieste dovrebbero essere risolte in maniera automatica.

Se tutto sarà andato per il verso giusto sarà sufficiente loggarsi con la userid e la password di un qualsiasi utnte Unix all’URL seguente:

https://serverip:20000/

Dove 20000 è il numero di porta utilizzato da Usermin rispetto al numero 10000 utilizzato da Webmin.

A questo punto l’ultima cosa che che mi sento di segnalare è che per poter selezionare ed indicare quali tra i vari moduli di Usermin devono essere visibili  agli utenti è sufficiente accedere alla sezione “Avalilable Modules” accessibile dopo un clic sulla voce “Usermin Configuration” della sezione Webmin nella treeview di amministrazione.

Alla prossima.

Carlo A. Mazzone

Webmin è un utilissimo strumento di amministrazione per server Linux. Esso consente tramite un semplice accesso via web di configurare ed amministrare svariati servizi: apache, dns, dhcp  solo per citarne alcuni. Webmin consente inoltre  di gestire account e lavorare sul file system del server sul quale è installato. Ma anche questo è un elenco estremamente riduttivo delle sue possibilità. In definitiva in un solo ambiente è possibile avere sotto le proprie dita un intero sistema server.

Il presente scritto vuole essere una veloce guida alla sua installazione.

Dunque partiamo. La prima operazione da portare a termine è la modifica del file  /etc/apt/sources.list

Per farlo usate il vostro editor preferito; il mio, da un po’ di tempo a questa parte,  è “nano”. Quest’ultimo lo sto preferendo al vecchio “vi” essendo ormai disponibile di default in varie distribuzioni Linux. Ed a proposito di distribuzione la procedura qui descritta è stata provata su di una distro Linux Ubuntu server 12.04 64 bit.

Procediamo allora con:

$ sudo nano /etc/apt/sources.list

Il file in questione  è utilizzato dal gestore di pacchetti APT per contenere la lista delle “sorgenti” dalle quali il sistema può attingere i pacchetti stessi.

Andiamo dunque ad aggiungere al file in questione le seguenti due righe di testo:

deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib

Salviamo il file ed usciamo.

A questo punto è necessario  importare la chiave GPG per validare il pacchetto webmin. In caso contrario potreste ricevere durante l’installazione un errore come il seguente:
“Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile”

Lanciamo dunque i seguenti comandi:

$ wget http://www.webmin.com/jcameron-key.asc
$ sudo apt-key add jcameron-key.asc

Aggiorniamo dunque la source list:

$ sudo apt-get update

e finalmente possiamo procedere all’installazione di webmin:

$ sudo apt-get install webmin

E dunque ci siamo; per accedere al pannello di controllo è sufficiente raggiungere l’URL:

https://serverip:10000/

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

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