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

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

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