Installare un server Subversion - Parte 4

Riprendiamo l'installazione del server Subversion dalla precedente Parte 3.

La parte 3 è stata un intermezzo; il discorso più importante è stato lasciato in sospeso alla fine della Parte 2.
Ci occorre restringere opportunamente le possibilità di azione degli utenti del nostro server Subversion. Non vogliamo che i nostri utenti possano accedere liberamente ai file del repository, agli script che andremo a creare. Dovranno solo poter accedere ai dati contenuti nel repository stesso attraverso Subversion.
Vediamo come possiamo realizzarlo.

Torniamo a collegarci al nostro server con l'utente subversion.

Ci occorre creare uno script attraverso il quale automatizzare l'accesso esclusivo di Subversion al nostro repository.
Verifichiamo, sul nostro sistema Linux, dove si trova l'eseguibile del server di subversion, digitando which svnserve.
In Debian, l'eseguibile si trova in /usr/bin. Dobbiamo crearne un wrapper, che imposti la umask e restringa l'accesso alla directory contenente i repository (E' qui dove molte guide suggeriscono di rinominare il file svnserve e creare, un /usr/bin, uno script che richiami il binario con il nuovo nome. A noi questo non piace, vero?).
Per fare ciò creiamo una directory bin all'interno della home dell'utente subversion, digitando mkdir ~/bin. Entriamoci digitando cd ~/bin.

Creiamo quindi il wrapper digitando vi ~/bin/svnserve.
Digitiamo le seguenti righe:


#!/bin/sh
umask 0077
/usr/bin/svnserve -r /home/subversion/repo/ "$@"

Chiudiamo il file e salviamo (tasto ESC seguito da :wq).
Rendiamo il file eseguibile digitando: chmod u+rwx ~/bin/svnserve

Abbiamo creato un eseguibile "svnserve" che imposta la directory da servire nella nostro repository.
A questo punto non ci resta che tornare al nostro file ~/.ssh/authorized_keys e far sì che l'utente svn01, al collegamento, sia 'forzato' ad accedere direttamente a svnserve.
Per fare questo digitiamo vi ~/.ssh/authorized_keys e aggiungiamo, in testa alla riga contenente la chiave pubblica dell'utente svn01:

command="~/bin/subversion-server -t --tunnel-user=svn01",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty

Il risultato finale é il seguente:

Concludiamo il post verificando il corretto funzionamento del nostro server di Subversion.
Su una macchina Windows (più avanti proveremo anche un client su un Desktop Environment Linux e su un ambiente di sviluppo, come Eclipse e Visual Studio) installiamo TortoiseSVN (http://tortoisesvn.net/).
Una volta installato, proviamo a collegarci al nostro repository. TortoiseSVN è una shell extension: posizioniamoci, per esempio, sul desktop e clickiamo con il tasto destro, selezionando TortoiseSVN -> Repo Browser.

Nella finestra che apparirà, digitiamo svn+ssh://svn01.subversion.homeserver/Repo01.
Se tutto è andato bene, non ci verrà chiesta alcuna password, e vedremo questo risultato:

Naturalmente, il repository è vuoto. Ma se vi compare questa finestra, vuol dire che avete eseguito correttamente tutti i passaggi.
Se vi state chiedendo come mai non vi è stata richiesta alcuna password, la risposta sta nella Parte 3, e nel tool Pageant. Quando avete caricato la chiave privata, vi è stata chiesta la password. Una volta fornita, la chiave è aperta, e TortoiseSVN si avvale di PuTTY e Pageant per connettersi al server.

Se invece non avete ottenuto altro che finestre che richiedono la password, probabilmente la vostra chiave non è al momento caricata in Pageant (magari, avete riavviato il PC!). Avviate Pageant se non è ancora attivo e caricate la chiave come descritto nella Parte 3, e riprovate!

Nella prossima parte proveremo ad aggiungere un utente, e verificare che, nonostante l'utente Linux sia uno solo, i file appartengono agli utenti da noi creati (svn01, svn02 e così via).

Si prosegue con la Parte 5, ricca di screenshot!

Cito la fonte da cui ho attinto informazioni utili per questa guida:
http://tortoisesvn.net/ssh_howto.html

Installare un server Subversion - Parte 3

Rieccoci per la terza parte (Parte 1 - Parte 2).

In questo breve post è descritto un passo preliminare che consentirà l'autenticazione automatica (cioè, inserendo la password del proprio utente di Subversion una sola volta per sessione) su un sistema Windows.

Occorre utilizzare il tool Pageant di PuTTY. Una volta avviato, troviamo una icona nell'area di notifica. E' quella che sembra un computer con sopra un cappellino.

Clickandoci sopra con il tasto destro e selezionando "View Keys", appare una finestra di questo tipo:

Non ci resta che aggiungere la chiave che abbiamo precedentemente creato, utilizzando ovviamente il tasto "Add Key". Navigate fino alla cartella dove avete salvato la chiave, selezionatela e clickate "Open". Ci viene chiesta la password, che è quella che avete digitato su PuTTYgen quando avete creato la vostra chiave pubblica.

Digitate la password e clickate OK. Se tutto è andato bene, a video non succede nulla, ma la chiave è aperta e pronta per essere utilizzata. Verificate di nuovo clickando con il tasto destro sulla icona di Pageant nella tray. Dovrebbe apparire una finestra simile a questa:

Ricordate: ogni utente di subversion dovrà caricare la propria chiave! Potete anche aggiungere Pageant all'avvio automatico aggiungendo come parametro il path della vostra chiave (vi verrà richiesta la password a ogni avvio di Windows).


Avanti con la Parte 4...

Installare un server Subversion - Parte 2

Proseguiamo sulla creazione di un server Subversion, iniziato con la Parte 1.

Supponiamo di voler creare una utenza subversion per un sistema Windows. Per fare ciò, occorrerà installare il programma Putty su ognuno dei client. Suppongo che tutti i lettori di questo post lo sappiano fare, quindi non sarà qui descritto.

Fatto ciò, occorre creare una coppia di chiavi (pubblica e privata). Lo si può fare sfruttando il tool PuTTYgen, incluso nel pacchetto di PuTTY.

Creiamo la chiave per il nostro primo utente, per esempio "svn01", cliccando sul tasto Generate.

Seguiamo le istruzioni a video, quindi muoviamo un po' il mouse per aiutare la creazione di una chiave casuale. Fatto ciò, modificate il campo "Key comment" con qualcosa di più significativo, tipo "svn01"; inserite e confermate la vostra password.


Ricordatevi, in un ambiente 'live', di utilizzare una password complessa e sicura! Potrete cambiare questa password senza impatti sulla sua pubblica e senza dover ripetere le operazioni che seguono. Per la fase di test, vi consiglio invece una password semplice, tanto per non aggiungere complicazioni inutili, ma ricordatevi di cambiarla se l'ambiente di test diventa, di fatto, l'ambiente 'live'.


Salvate la chiave con il pulsante "Save private key". Non chiudete ancora la finestra di PuTTYgen!

Siamo a buon punto con la creazione del primo utente Subversion.

Ora però occorre far sì che l'utente che utilizza questa chiave possa collegarsi al nostro server.

Apriamo PuTTY e colleghiamoci al server con l'utenza di amministrazione di subversion creata durante la parte 1. In questa guida l'utente è "subversion".

Occorre creare la cartella .ssh, che conterrà le chiavi autorizzate ad accedere all'utenza subversion.

Digitiamo

mkdir ~/.ssh

cd ~/.ssh

La directory .ssh non deve avere permessi troppo elevati. Se avete seguito correttamente la Parte 1, impostando il comando umask in fondo al file .bashrc, la cartella .ssh avrà i permessi di lettura, scrittura ed esecuzione riservati al solo utente subversion. Al gruppo e al resto degli utenti non è consentito fare nulla con questa cartella. Questo è importante, perché permessi troppo elevati impediranno il collegamento con autenticazione tramite coppia di chiavi.

Se vi siete ricordati di aver saltato la parte riguardante umask, niente paura: per cambiare i permessi della cartella .ssh appena creata, digitate:

chmod u+rwx,go-rwxs ~/.ssh

Ricordatevi poi di eseguire i passi della Parte 1, con particolare attenzione all'aggiunta del comando umask nel file ~/.bashrc

Ora, copiamo il contenuto della casella "Public key..." selezionando il testo e premendo la combinazione di tasti CTRL-C.

Torniamo sul server e digitiamo:

vi ~/.ssh/authorized_keys

premete il tasto "i" per inserire, e fate click con il tasto destro nella finestra. Voilà!

Digitiamo e poi :wq per uscire da vi salvando il file.

Abbiamo quasi finito con il primo utente.

Se vogliamo verificare il funzionamento, creiamo con PuTTY una sessione dal nome (per esempio) svn01.subversion.homeserver (sostituite homeserver con il nome o l'indirizzo del vostro server).

Andate nella scheda Connection -> SSH -> Auth e impostate il percorso della vostra chiave privata nella casella "Private key file for authentication:".

Impostiamo il nome utente nella scheda Connection -> Data, casella "Auto-Login Username". Ricordiamoci, ci colleghiamo sempre con l'unico utente "subversion".
Non dimenticate di salvare la sessione, che dovrebbe essere simile a quella dell'immagine qui sopra.
Proviamo ad aprirla. Se tutto è andato bene, vi verrà chiesta la password dell'utente svn01 (si tratta di quella che avete inserito in PuTTYgen).

Finito? No, mancano ancora un po' di cose. Per esempio, il problema più grave è che l'utente svn01, di fatto, è un amministratore del nostro server subversion, al pari dell'utente subversion stesso. Questo non è accettabile! Provvederemo nelle prossime parti.


Avanti con la Parte 3...

Installare un server Subversion - Parte 1

L'obiettivo di questo post è descrivere l'installazione e la configurazione di un server subversion. Ci sono già in giro decine di guide a riguardo, perché un'altra?

Beh, molte di queste, seppure funzionanti, non danno suggerimenti proprio ortodossi: alcune richiedono di rinominare eseguibili (svnserve) per crearne dei wrapper; alcune suggeriscono di creare un server sempre attivo, con password salvate in chiaro e (ops...) con trasmissione dei dati in chiaro; altre suggeriscono di creare coppie di chiavi pubblica/privata rigorosamente senza password, lasciando credere che non sia possibile utilizzare una chiave protetta da password. Beh, come vedremo, non è così.

Inoltre, nella maggior parte dei casi, richiedono di creare un nuovo utente (con tanto di home) sul server per ogni utente di subversion. Questo può anche non essere un grosso problema se abbiamo pochi utenti. Ma se fossero decine, o centinaia?
Eviteremo anche di usare l'autenticazione tramite apache, non perché non vada bene ma semplicemente per ridurre i requisiti minimi. Ci piace installare solo lo stretto necessario sul nostro server, giusto?

Oggi cominciamo con l'installazione di subversion su un server linux. Usiamo Debian stable (ad oggi: Squeeze), ma quello che faremo si applica con minime modifiche a tutte le distribuzioni.

Installazione

Su Debian, per installare subversion, occorre digitare l'esoterico comando:

apt-get install subversion

avendo cura di farlo dall'utente root o tramite sudo, se lo avete configurato.

Definiamo l'utente dedicato a subversion. Su debian, possiamo usare lo script "adduser", che si occupa di creare anche una home directory e di impostare la password.

Sempre da root/sudo, digitiamo:

adduser subversion

impostiamo la password, il "Full Name" se ne abbiamo voglia.

Dovremmo ottenere una output di questo tipo:

root@homeserver:~# adduser subversion

Adding user `subversion' ...

Adding new group `subversion' (1003) ...

Adding new user `subversion' (1004) with group `subversion' ...

Creating home directory `/home/subversion' ...

Copying files from `/etc/skel' ...

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for subversion

Enter the new value, or press ENTER for the default

Full Name []: Subversion Administrator

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] y

Ottimo. D'ora in poi non avremo più bisogno dell'utente privilegiato (root o accesso tramite sudo). Non ci serve più l'amministratore del server, che quindi può essere svincolato dall'amministratore di Subversion. Come vedremo, non ci servirà più nemmeno per creare i nuovi utenti dei nostri repository di Subversion.

Colleghiamoci al server con il nuovo utente (se siete sul server stesso, potete fare logout e riconnettervi con le nuove credenziali; se vi collegate da remoto basta aprire una nuova sessione ssh. Se utilizzate PuTTY da Windows, rimuovete il flag "Attempt authentication using Pageant" e salvate la sessione. Questo dovrà rimanere il nostro account di amministrazione di subversion).

Il server di subversion sarà utilizzato solo dall'utente subversion, quindi non c'è ragione che i files abbiano maggiori privilegi. Digitiamo quindi

umask 0077

e restringiamo l'accesso dei nuovi file/directory che creeremo al solo utente subversion.

Mettiamo anche quest'ultima istruzione nel file .bashrc, così che non dovremo ogni volta ricordarci di fare questa operazione. Digitiamo quindi:

echo umask 0077 >> ~/.bashrc

Creiamo ora la directory che ospiterà i repository subversion. Chiamiamola "repo".

mkdir ~/repo

e entriamoci

cd ~/repo

Creazione del repository

Ora creiamo il nostro primo repository. Lo potremmo chiamare "Repo01", digitiamo quindi:

svnadmin create ~/repo/Repo01

Se avete eseguito correttamente tutte le operazioni, digitando

ls -la ~/repo/Repo01

dovreste ottenere:

subversion@homeserver:~/repo/Repo01$ ls -la ~/repo/Repo01

total 32

drwx------ 6 subversion subversion 4096 Mar 3 00:23 .

drwx------ 3 subversion subversion 4096 Mar 3 00:22 ..

drwx------ 2 subversion subversion 4096 Mar 3 00:22 conf

drwx--S--- 6 subversion subversion 4096 Mar 3 00:23 db

-r-------- 1 subversion subversion 2 Mar 3 00:23 format

drwx------ 2 subversion subversion 4096 Mar 3 00:22 hooks

drwx------ 2 subversion subversion 4096 Mar 3 00:22 locks

-rw------- 1 subversion subversion 229 Mar 3 00:22 README.txt

C'è qualche simbolo "S" nei permessi, servono nel caso di voglia permettere l'accesso al repository a più utenti linux, che appartengano allo stesso gruppo. A noi non servirà. Se desiderate eliminare questa concessione, digitate:

chmod g-rwxs -R ~/repo/Repo01/*

Ricontrollate con il comando precedente: i flag "S" dovrebbero essere spariti.

Ok, per la prima parte è sufficiente.

Abbiamo:

1) Installato subversion

2) Creato l'utente amministratore e ristretto i permessi di accesso dei file da esso creati.

3) Creato il primo repository.

A domani per la Parte 2.

Remotizzazione applicazioni sul vostro home server

Quindi, anche voi state cercando di far lavorare un po' il vostro server, e lasciare libero il vostro desktop, ma vi è capitato di voler "remotizzare" una applicazione che richiede la GUI.

Nulla è perduto, si può fare in diversi modi, io ve ne illustro uno che prevede l'utilizzo di VNC e FluxBox.

I comandi che seguono sono validi per le distribuzioni linux debian-based (quindi anche ubuntu server).

Cominciamo aggiornando il sistema:

> sudo apt-get update

> sudo apt-get upgrade

Quindi installiamo l'ambiente grafico fluxbox

> sudo apt-get install fluxbox

Io ho installato anche i pacchetti "suggeriti":

> sudo apt-get install fluxconf fbpager fbdesk

Fateci caso: questi pacchetti non richiede l'installazione dei driver grafici. L'ambiente X sarà fornito dal server vnc. Andiamo a installarlo:

> sudo apt-get install vnc-server

A domani per il secondo capitolo!

NAS Server - Backup

Un'altra frontiera di utilizzo del NAS è il backup. Finora si è pensato al nas come a un sistema di storage esterno alle workstation, ma possiamo anche fare in modo di automatizzare il backup dei dati contenuti nelle proprie workstation in maniera molto efficiente.
Anzi, si può pensare di costruire un NAS online e un NAS di backup. Nel prossimo articolo approfondisco...

NAS Server - Subversion (Parte 3)

Un NAS/Server disponibile in casa dà la possibilità di centralizzare il salvataggio e la sicurezza dei documenti.
Io ho optato per Subversion (via http).

In pratica, ho 3 repository:

docs
development
photos

A cui accedo da kdesvn (da kde su linux), eSvn (se uso un linux con gnome) e da tortoise svn se usassi windows (questo succede in ufficio dove ho comunque un repository linux-based e client windows e linux).

Subversion non è semplicemente un sistema di backup, ma è un sistema di versionamento. Può tenere traccia di tutte le versioni di un qualsiasi file che sia stato aggiunto al suo controllo. Le operazioni di base sono semplici: se si crea un nuovo file, occorre fare una "add" dopodiché una "commit". Se si aggiorna un file esistente, per riversarlo sul repository, è sufficiente la "commit".

Tutti i software sono gratuiti, compreso il client per windows (Link). Inoltre, sono disponibili sempre gratuitamente degli ottimi plug-in per gli ambienti di sviluppo più diffusi (tra tutti Eclipse e Visual Studio).

NAS Server - Hardware (Parte 2)

Ecco l'elenco dei componenti che ho utilizzato per la realizzazione del NAS.

Mainboard: Intel Little Falls 2 D945GCLF2, basata su intel atom 330 (dual core a basso consumo)
Memoria: Kingmax DDR2-667, 2GB (1 modulo)
Controller S-ATA II: Promise SATA300 TX4

Hard Disk
1) Sistema operativo: Seagate 320GB 7200.12 (può bastare anche un disco di capacità molto inferiore)
2) Storage: Alcuni hard disk serial ata II già in mio possesso.

Alimentatore: Corsair VX450, molto silenzioso.

Lettore DVD: non ricordo, ma è servito solo per l'installazione, ed ora è stato destinato ad altri usi.

Case Nokia Style vecchio, già in mio possesso. In attesa della scelta di un case più adatto.

Router/Firewall (Parte 1)

Dopo aver cablato la casa, mi si è aperta la possibilità di liberarmi del router wireless che avevo acquistato un paio d'anni fa. Diciamo che le performance non erano eccellenti, soprattutto quando si utilizzava Skype (la comunicazione cadeva spesso e volentieri, sia con un telefono ad-hoc, sia con un PC e il programma Skype attivo).

Certo, potevo andare in un negozio di elettronica qualsiasi e comperare un nuovo router di qualità superiore. Ma è molto meglio costruirne uno da se'. Anche questa volta Linux ci viene in aiuto, con una certa scelta di distribuzioni specializzate in grado di svolgere tutte le funzioni di un router/firewall, e molto di più. Ho provato anche con una distribuzione generica e a configurarla per ottenere lo stesso risultato: funziona tutto bene, ma in caso di reinstallazione, il tempo perso secondo me é troppo: l'esperimento è riuscito, é stato interessante, ma ora uso ClarkConnect, in versione Community 4.3.

Cosa serve? Un vecchio PC, preferibilmente dai consumi modesti, un hd da pochi GB, 512MB di RAM, 2 schede di rete. Con alcune distribuzioni, i requisiti di memoria possono essere più bassi (per esempio con IPCop, che però é basato su FreeBSD) e in alcuni casi è possibile utilizzare una Compact Flash al posto dell'hard disk.

Io utilizzo un vecchio Pentium 3 da 866MHz, con 512MB di hd e 20GB di hd da 2.5". La mainboard non ha alcuna scheda di rete, così ho acquistato un paio di Realtek Gigabit a pochi euro ciascuna. Il lettore cd è servito solo durante l'installazione.
Anche questo sistema è ovviamente headless!

L'installazione è semplice, in 15 minuti si ha a disposizione un sistema perfettamente funzionante. Funziona ormai da qualche mese senza alcun problema, e con una occupazione di CPU bassissima.

Appena possibile posterò qualche immagine e fornirò qualche dettaglio in più!

NAS Server - Introduzione (Parte 1)

Per far fronte alle crescenti necessità di archiviazione, ho creato il mio primo vero NAS server. Per chi non lo sapesse, NAS è l'acronimo di Network Attached Storage: per una breve descrizione, fate riferimento a questo articolo di wikipedia, in italiano: http://it.wikipedia.org/wiki/Network_Attached_Storage

Il mio NAS è basato su una mainboard Intel Little Falls 2 (D945GCLF2), che è dotata del processore Atom 330 (dual core) a 1.6GHz. Il processore non ha certo performance irresistibili ma il sistema risultante risulta più che adeguato alle attuali necessità.

Come sistema operativo, ho optato per Ubuntu Server 9.04 "Jaunty Jackalope" a 32bit. Visto che sulla mainboard non supporta più di 2GB di RAM, non ci sono particolari ragioni per utilizzare la versione a 64bit, che invece utilizzo con soddisfazione sul desktop.

Oltre all'immancabile Samba per la condivisione dei file verso client Windows e Linux, e alla classica funzionalità LAMP (Linux Apache MySQL Php), ho installato un server Subversion per l'archiviazione di progetti e documenti.

Gran parte della gestione delle attività avviene attraverso Webmin, una comoda interfaccia web. Il server è ovviamente "headless", cioé senza tastiera, monitor e mouse.

Vista l'esiguo numero di porte s-ata della mainboard che ho utilizzato, ho dovuto aggiungere una scheda Promise SATA300 TX-4, che mi fornisce 4 ulteriori porte.

Di RAID, non se ne parla. A mio parere è solo pericoloso (l'unico che prenderei in considerazione è il RAID1).

Nel prossimo post trovare l'elenco dei componenti hardware utilizzati per la realizzazione del sistema.