Virtualbox 4 Headless con Debian Squeeze

Se volete avere un’installazione headless di virtualbox 4.0 su debian squeeze (6.0) bisogna procedere come segue:

Installazione di virtualbox 4

Aggiungere il repository di virtualbox per squeeze alla vostra sources.list (/etc/apt/sources.list) come segue:

deb http://download.virtualbox.org/virtualbox/debian squeeze contrib non-free

quindi bisogna aggiungere la chiave pubblica di oracle per certificare i pacchetti quindi avere la certezza che questi siano quelli realmente forniti dal produttore.

wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add -

quindi procedere con l’installazione (ricordatevi prima di aggiornare i repository con un update altrimenti i nuovi pacchetti non vengono trovati).

sudo apt-get install virtualbox-4.0

è quindi necessario installare l’extension-pack scaricabile al seguente link http://www.virtualbox.org/wiki/Downloads ed eseguire il seguente comando per installarlo

sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.4-70112.vbox-extpack

Creazione della macchina virtuale

Creazione della macchina virtuale (viene creata nella vostra home). Il parametro ostype è facolattivo, ma impostandolo correttamente vengono impostati alcuni valori di default compatibili con il sistema selezionato.

VBoxManage createvm --name "Windows XP" --ostype WindowsXP --register

Qundi impostiamo alcuni parametri sulla nostra macchina quali ad esempio RAM, tipo di interfaccia di rete, periferica di boot, …

VBoxManage modifyvm "Windows XP" --memory 256 --acpi on --boot1 dvd --nic1 nat

Quindi creiamo il disco virtuale che conterrà la nostra macchina virtuale

VBoxManage createhd --filename "WinXP.vdi" --size 10000

Aggiungiamo il controller

VBoxManage storagectl "Windows XP" --name "IDE Controller" --add ide --controller PIIX4

adesso collegghiamo l’HD creato precedentemente alla macchina

VBoxManage storageattach "Windows XP" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium "WinXP.vdi"

Aggiungiamo la ISO contente l’OS da installare

VBoxManage storageattach "Windows XP" --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive --medium winXP.iso

configuriamo poi i parametri fondamentali per la gestione della connessione remota (attenzione che in questo esempio la connessione è possibile senza nessun tipo d’autenticazione)

VBoxManage modifyvm "Windows XP" --vrdeaddress 192.168.1.37
VBoxManage modifyvm "Windows XP" --vrdeauthtype null
VBoxManage modifyvm "Windows XP" --vrdeport 3389
VBoxManage modifyvm "Windows XP" --vrde on

procediamo con l’esecuzione della macchina virtuale

VBoxHeadless --startvm "Windows XP"

l’output dovrebbe essere il seguente:

root@debian6:~# VBoxHeadless --startvm "Windows XP"
Oracle VM VirtualBox Headless Interface 4.0.4
(C) 2008-2011 Oracle Corporation
All rights reserved.

VRDE server is listening on port 3389.

Connessione remota alla macchina virtuale

Arrivati a questo punto il gioco è fatto… è sufficiente utilizzare un qualsiasi client compatibile con RDP (il remote desktop di windows) e collegarsi alla macchina, si avrà quindi accesso al display in maniera remota.

Consiglio la lettura del seguente capitolo del manuale di VirtualBox

subversion con websvn e svnmanager

Vogliamo implementare un sistema di controllo versione con un interfaccia web (amministrazione e visualizzazione) sulla vostra distribuzione preferita? Vediamo come installare subversion, websvn su debian lenny.

Subversion (noto anche come svn, che è il nome del suo client a riga di comando) è un sistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, oramai considerato superato.

Come prerequisiti dobbiamo avere un server con installati apache2, php, mysql e pear funzionanti, se non avete questo potete facilemente reperire delle ottime guide (ad esempio su howtoforge.com). Procediamo con l’installazione di quanto necessitiamo (subversion, supporto ad apache2 come modulo a sv con webdav, libreria di PEAr per svnmanager), durante il processo rispondere “no” alla richiesta di configurazione di websvn:

apt-get install subversion libapache2-svn websvn
pear install -d preferred_state=alpha VersionControl_SVN

Procediamo con la creazione della struttura (directory e file di configurazione che non vengono generati automaticamente dall’applicazione) per contenente le nostre future repository (repos) e file di configurazione e diamo i privilegi compliti ad apache:

mkdir /var/lib/svn
cd /var/lib/svn
mkdir repos
mkdir sysconfig
touch passwdfile
touch accessfile
chown -R www-data:www-data /var/lib/svn

Ora bisogna modificare il file di configurazione del modulo webdav per svn di apache, che si trova al seguente indirizzo:

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

Dal file dobbiamo attivare le seguenti funzioni (decommentare le righe):

<Location /svn>
  DAV svn
  SVNParentPath /var/lib/svn/repos
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/lib/svn/passwdfile
  AuthzSVNAccessFile /var/lib/svn/accessfile
  Require valid-user
</Location>

In questo modo abbiamo abilittao il servizio, definito un percorso all’interno dei quali si troveranno i nostri repos ed un sistema di autenticazione a livello di accesso http e svn. Procedere quindi con il download di svnmanager (la versione al momento della scrittura di questo post è la 1.0.8). Scarichiamo (o carichiamo) sul server l’ultima versione in /var/www e procediamo con l’installazione:

unzip svnmanager-1.08.zip
ln -s svnmanager-1.08 svnmanager
cd svnmanager
cp config.php.linux config.php

Abbiamo definito un nome più semplice da ricordarsi (svnmanager) ed attivata la configurazione per piattaforma linux. Editiamo quindi il file di configurazione (config.php) ed andiamo a modificare quanto segue:

$svn_config_dir  = "/var/lib/svn/svnconfig";
$svn_repos_loc   = "/var/lib/svn/repos";
$svn_passwd_file = "/var/lib/svn/passwdfile";
$svn_access_file = "/var/lib/svn/accessfile";
$smtp_server     = "localhost";
$dsn             = "mysqli://svnmanager:PASSWORD@localhost/svnmanager"; // change PASSWORD with your password :-)

Come vedete abbiamo ripreso la struttura precedentemente creata e definito il nostro DSN (connettore al db attraverso un dbal). Procediamo quindi alla creazione in MySQL dell’account e del database come specificato nel DSN configurato precedentemente. Riavviamo quindi il servizio apache.

/etc/init.d/apache2 restart

Se vi collegate all’indirizzo del vostro server indicando la direcotory svnmanager la prima volta viene generata la struttura del DB ed in seguito avrete accesso all’interfaccia amministrativo di subversion.

http://your-ip/svnmanager

SVNManager - login

Accedete all’interfaccia amministrativa con l’accaunt definito nel file di configurazione e create un nuovo utente (date i privilegi amministrativi). Create quindi un progetto ed utilizzando il vostro tools prferito e caricate dei files. Accedete poi via browser e vedrete quanto caricato (previo autenticazione).

Mentre con un indirizzo di questo tipo:

http://your-ip/svn/repo-name

vi collegate (previo autenticazione) via webdav al vostro progetto.

Ora però vogliamo visualizzare tutto questo in una forma più consona al web, quindi avendo accesso alle informazioni in una maniera strutturata, potento utilizzare quei strumenti che ci permettono di capire l’evoluzione del nostro progetto (diff, formattazione, …). Procediamo quindi con la configurazione di websvn.

dpkg-reconfigure websvn

e procediamo con le scelte di default (chiaramente vogliamo configurare il servizio), afcendo però attenzione ad inserire i valori mostrati di seguito per quanto riguarda i repos di svn.

svn parent repositories: /var/lib/svn/repos
svn repositories: [nothing]

A questo punto potremmo già accedere alle nostre repository al seguente indirizzo:

http://your-ip/websvn/

websvn - home

ma vedete che non abbiamo nessun tipo di protezione/autenticazione. Possiamo implementare il medesimo meccanismo di autenticazione utilizzato per webdav, ma al momento senza un controllo diretto sui files, ma unicamente sull’accesso. Modifichiamo il seguente file:

/etc/websvn/apache.conf

e aggiungiamo all’interno della direttiva Directory

AuthType Basic
AuthName "Subversion Repository"
Require valid-user
AuthUserFile /var/lib/svn/passwdfile

Cosi facendo facciamo riferimento alla medesima lista di username/password (senza riferimenti ai repository). Per evitare questo andiamo a modificare il seguente parametro (in questo modo indichiamo al sistema di far riferimento anche agli accessi di subversion):

$config->useAuthenticationFile('/var/lib/svn/accessfile'); // Global access file

in

/etc/websvn/config.php

Se vogliamo rendere il tutto più sicuro dobbiamo implementare un’accesso tramite un protocollo sicuro, quindi l’unica soluzione che fa al nostro caso è quella di utilizzare https (quindi ssl). Procediamo quindi alla configurazione dei nostri certificati ed alla loro installazione/abilitazione nelle diverse configurazioni.

mkdir/etc/apache2/ssl
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

viene generato un certificato di tipo selfsigned (quindi siete voi l’authority). Attenzione che alla domanda del commonName dovete inserire esattamente il nome del vostro dominio, ad esempio svn.mioserver.com. Il certificato avrà come validità 10 anni. Editiamo di nuovo i files /etc/apache2/mods-available/dav_svn.conf e /etc/websvn/apache.conf ed aggiungiamo ad entrambi la direttiva

SSLRequireSSL

in modo da richiedere la presenza del protocollo SSL, quindi l’accesso avverrà tramite https, al momento dell’autenticazione. A questo punto configurate il vostro dominio (usando il commonName definito nella creazione del vostro certificato SSL) per configuare il vostro dominio namebased, di seguito un esempio per la condivisione della /var/ww:

<VirtualHost your-ip:443>
  ServerName commonNAme
  ServerAdmin email@domain
  DocumentRoot "/var/www/"
  <Directory /var/www/>
    Options -Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
  </Directory>
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/apache.pem
  ErrorLog "/var/logs/ssl.error.log"
  CustomLog "/var/logs/ssl.access.log" combined
</VirtualHost>

Non vi basta che riavviare apache e questo punto avrete messo in sicurezza l’accesso a svn (ed ai tools per gestirlo). E questo è tutto, se avete domande, migliorie o commenti fatemi sapere.

Munin per monitorare le risorse

Munin è un progetto decisamente interessante per la sua semplicità d’uso, d’installazione e configurazione e per la sua versatilità. Di cosa si tratta? Di un sistema per monitorare le risorse utilizzate dalla (o dalle) vostre macchine quali:

  • CPU
  • Disco
  • Rete
  • Servizi vari (MySQL, Dovecot, Apache, …)

Ha un architettura di tipo client/server dove abbiamo un Master il quale raccoglie e mostra attraverso grafici generati con RRDTool i dati provenienti da uno o più nodi (che chiaramente posso essere distribuiti su macchine diverse).

muninVediamo ora una semplice configurazione di Munin prendendo come requisiti per il nostro sistema i seguenti punti:

  • Piattaforma Debian 5.0 (Lenny) ma dovrebbe funzionare anche su versioni precedenti
  • Master e nodo sono la stessa macchina

Procediamo con l’installazzione dei pacchetti necessari a far funzionare il servizio, per installare munin utilizzate il seguente comando:

apt-get install munin

Se volete avere un elenco più preciso di quello che sta per fare mettete l’opzione -s al comando e vedrete quali pacchetti verranno installati (e quali potrebbe essere interessante aggiungere, suggested). L’installazione provvederà anche ad attivare il servizio.

A questo punto il Master ed il Nodo sono sulla stessa macchina ma non viene ancora monitorizzato nessun servizio, periferica o quantaltro. Procediamo quindi con la configurazione dei servizi che riteniamo opportuno monitorare. La seguente istruzione

munin-node-configure --suggest

stampa un elenco di plugin attivabili sul nostro server in base alla configurazione, disponibilità, …

apache_volume              | no   | [LWP::UserAgent not found]
courier_mta_mailqueue      | no   | [spooldir not found]
courier_mta_mailstats      | no   | [could not find executable]
courier_mta_mailvolume     | no   | [could not find executable]
cpu                        | no   | yes
cupsys_pages               | no   | [could not find logdir]
df                         | no   | yes
df_inode                   | no   | yes

Dove i campi rappresentano il nome, se è attiva ed eventuali note (attivabile, errori, …). Una volta configurato il sistema per essere compatibile con le nostre esigenze di monitoraggio possiamo eseguire il seguente comando:

munin-node-configure --suggest --shell

attraverso il quale abbiamo l’elenco delle istruzione da eseguire (tramite copia/incolla) per attivare le plugin.

ln -s /usr/share/munin/plugins/cpu /etc/munin/plugins/cpu
ln -s /usr/share/munin/plugins/df /etc/munin/plugins/df
ln -s /usr/share/munin/plugins/df_inode /etc/munin/plugins/df_inode
ln -s /usr/share/munin/plugins/entropy /etc/munin/plugins/entropy
ln -s /usr/share/munin/plugins/forks /etc/munin/plugins/forks
ln -s /usr/share/munin/plugins/if_ /etc/munin/plugins/if_eth0
ln -s /usr/share/munin/plugins/if_err_ /etc/munin/plugins/if_err_eth0

Questo non fa altro che generare un link sombolico della plugin in /usr/share/munin/plugins in /etc/munin/plugins ed è poi possibile configuare ulterioremente il comportamento in :/etc/munin/plugin-conf.d

Una volta configurato riavviamo il servizio cosi da ricaricare la configurazione e le diverse plugin, a questo punto i dati vengono registrati:

/etc/init.d/munin-node restart

Il servizio è ora attivo e funzionante, è possibile (e auspicabile) però ad esempio implementare un meccanismo di sicurezza sull’accesso (attraverso IP o autenticazione) alle statistiche.

Se si vogliono monitorare dati di applicazioni o servizi al momento non implementati si può verificare se è disponibile una plugin per questo al seguente indirizzo:

Link interessanti: