In questa seconda parte della guida illustrerò alcune configurazioni di base per i check di Nagios e l’uso dell’addon NRPE per check locali su sistemi remoti.

La struttura

In questa guida prenderò in considerazione la struttura qui si seguito che permette di illustrare vari tipi di configurazione:

Una panoramica sugli host e i servizi:

• Host A, server Linux con:
  • Server HTTP Apache
  • VMWare Server con una macchina virtuale E con un server Zimbra
• Host B, server Linux con:
  • Server HTTP Apache
  • Server MySQL

Quindi E dipende da C che a sua volta dipende da A. Invece D dipende da B.
Entrambi i server Apache rispondono sulle porte 80 e 443, l’interfaccia di amministrazione di VMWare Server risponde sulla porta 8333 (con SSL).
La macchina virtuale Zimbra fornisce i servizi SMTP, POP3 e le interfaccie di webmail e amministrazione (porta 7071).
Infine nella macchina B il server MySQL risponde solo sull’interfaccia locale, non è quindi possibile accedervi dall’esterno.

Negli esempi successivi gli elementi A, C ed E saranno del cliente Company A (dominio company-a.com) e B e D saranno del cliente Company B con dominio company-b.com.
I nomi host saranno i seguenti:

• A => web.company-a.com
  
• C (macchina virtuale) => mail.company-a.com
  
• B => web.company-b.com

Per un maggior dettaglio nella spiegazione delle singole configurazioni tenete sempre sott’occhio la guida ufficiale alla pagina Object Definitions.

Organizzazione dei file

Una volta installato Nagios seguendo la prima parte della guida, troverete tutte le configurazioni in /usr/local/nagios/etc. Il file che comanda è nagios.cfg il quale poi richiama tutti gli altri. È quindi possibile, e consigliabile, creare una gerarchia di file che possa poi più facilmente permettere di gestire tutte le configurazioni (senza perdersi per strada i vari pezzi).
Nel file nagios.cfg ci sono due direttive inerenti questo aspetto e sono cfg_file e cfg_dir. La prima indica direttamente un file da cui leggere ulteriori configurazioni, la seconda indica intere directory da cui saranno inclusi tutti i file che terminano con .cfg. Io consiglio di intervenire usando questa seconda direttiva, le cartelle che ho creato sono:

cfg_dir=/usr/local/nagios/etc/personalized_objects
cfg_dir=/usr/local/nagios/etc/servers
cfg_dir=/usr/local/nagios/etc/groups

Oltre alle due cartelle con le configurazioni dei server e dei gruppi, ho aggiunto una cartella in cui inserirò i template personalizzati, ad esempio con timeperiods o contact groups diversi da quelli standard.

Gruppi di host e servizi

È possibile definire dei gruppi di host (ad esempio a seconda dell’azienda di appartenenza o del tipo di hardware) e dei gruppi di servizi (server di posta, server web, ecc.). Personalmente inserisco queste configurazioni nella cartella groups.

Esempi di configurazione sono i seguenti:

define hostgroup{
    hostgroup_name     companyA-servers
    alias              Company A Servers
    members            mail.company-a.com,web.company-a.com
}
define hostgroup{
    hostgroup_name     companyB-servers
    alias              Company B Servers
    members            web.company-b.com
}
define servicegroup{
    servicegroup_name  web-servers
    alias              Web Servers
    members            web.company-a.com,HTTP,web.company-b.com,HTTP
}

In entrambi i casi gli host indicati in members devono ricalcare il nome con cui quegli host sono definiti (attributo host_name). Nel caso dei servizi, oltre al nome dell’host, deve essere indicato il nome del servizio (anche in questo caso deve essere uguale a quello inserito in service_description).

Definizione degli host

Iniziamo con la configurazione dei server. I file web.company-a.com.cfg, web.company-b.com.cfg e mail.company-a.com.cfg verranno creati nella cartella servers. Non c’è molto da spiegare, inserisco dei commenti direttamente nelle configurazioni:

web.company-a.com.cfg

define host {
    use             linux-server   ;   Template da cui ereditare
    host_name       web.company-a.com   ;   L'host name è ciò che viene usato per identificare l'host negli altri file
    alias           CompanyA Web Server
    address         1.2.3.4
    hostgroups      comapanyA-servers   ;   Come in hostgroup, tale configurazione può essere alternativa o in aggiunta
}

web.company-b.com.cfg

define host {
    use             linux-server
    host_name       web.company-b.com
    alias           CompanyB Web Server
    address         1.2.3.5
    hostgroups      comapanyB-servers
}

mail.company-a.com.cfg

define host {
    use             linux-server
    host_name       mail.company-a.com
    alias           CompanyA Web Server
    address         1.2.3.6
    hostgroups      comapanyA-servers
    parents         web.company-a.com   ;   L'host da cui questo host dipende
}

Definizione dei servizi

La definizione dei servizi è direttamente collegata ai plugin, ovvero usano questi ultimi per effettuare i check. In verità il valore dell’attributo check_command, anche se in genere ricalca il nome del plugin (i plugin sono nella cartella libexec), non lo indica direttamente ma ha una corrispondenza nel valore dell’attributo command_name nella definizione di un comando (file etc/objects/commands.cfg).

mail.company-a.com.cfg

define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     SMTP
 check_command           check_smtp!-t 5
}
define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     IMAP
 check_command           check_imap!-t 5
}
define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     POP3
 check_command           check_pop!-t 5
}

Nella direttiva check_command viene indicato il tipo di comando da eseguire. Dopo il punto esclamativo vengono indicati gli argomenti. Se date uno sguardo a etc/objects/commands.cfg vedrete che gli argomenti vengono passati al plugin con $ARG1$, $ARG2$, ecc. In alcuni è presente soltanto un argomento, quindi nella definizione del servizio, dopo il punto esclamativo, devono essere indicati tutti gli argomenti (tipo ./check_dummy -t pippo -x pluto) mentre in altri comandi sono presenti più argomenti, spesso associati ad una specifica opzione (tipo ./check_dummy -t $ARG1$ -x $ARG2$). Nella definizione del servizio, più argomenti possono essere indicati con più punti esclamativi (tipo check_dummy!pippo!pluto). Per avere più informazioni su un plugin lanciatelo con libexec/check_dummy –help.

Un esempio di check un po’ più complesso può essere, ad esempio, quello necessario per controllare se l’interfaccia di amministrazione di Zimbra sta girando correttamente (HTTPS sulla porta 7071):

mail.company-a.com.cfg

define service{
 use                             generic-service
 host_name                       mail.comapany-a.com
 service_description             ZimbraAdmin
 check_command                   check_http!"-H mail.company-a.com -p 7071 -w 5 -c 15 --ssl"
}

Com’è facile intuire, con check_http è possibile quindi monitorare ogni singolo sito presente su un server web.

Ecco gli altri file necessari per la nostra configurazione:

web.company-a.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-a.com
 service_description             HTTP
 check_command                   check_http   ;   Semplice check sulla porta 80
}

define service{
 use                             generic-service
 host_name                       web.company-a.com
 service_description             VMWareAdmin
 check_command                   check_http!"-H web.company-a.com -p 8333 -w 5 -c 15 --ssl"
}

web.company-b.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-b.com
 service_description             HTTP
 check_command                   check_http
}

NRPE

L’ultima cosa che rimane da controllare è lo stato del server MySQL. Dato che il servizio risponde soltanto sull’interfaccia locale non è possibile controllarne direttamente lo stato dal server Nagios. L’addon NRPE fa proprio questo: installato sulla macchina da controllare, esegue dei check locali quando interrogato da Nagios.Il plugin da usare sul server è check_nrpe e l’argomento da passargli è il nome del check definito nel client, il quale a sua volta dovrà associare questo nome ad un check locale (quindi sul client dobbiamo installare i plugin).

Su entrambe le macchine va compilato  l’addon:

tar xzf nrpe-2.12.tar.gz
cd nrpe-2.12/
./configure --enable-ssl
make all

A questo punto l’installazione tra host e client differisce. Per l’installazione nel client dei plugin seguite la prima parte della guida.

Host

make install-plugin

e quindi bisogna creare il template del comando:

commands.cfg

define command {
 command_name    check_nrpe
 command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Client

Se non è installato, installate xinetd:

apt-get install xinetd

Installate quindi il demone

make install-daemon
make install-daemon-config
make install-xinetd

Aggiungete NRPE al file /etc/services:

nrpe 5666/tcp # NRPE

Aggiungete l’ip del server Nagios al file /etc/xinetd.d/nrpe (in questo caso un fittizio 4.3.2.1):

only_from = 127.0.0.1 4.3.2.1

Infine riavviate il server xinetd e controllate che NRPE sia in ascolto:

~# /etc/init.d/xinetd restart
~# netstat -at | grep nrpe
tcp        0      0 *:nrpe                  *:*                     LISTEN

A questo punto si può testare il servizio in locale con:

~# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE v2.12

Controllare MySQL

Arriviamo al nostro obiettivo: controllare che il server MySQL stia correttamente girando. Creiamo un utente MySQL non privilegiato:

mysql> CREATE USER 'nagiosCheck'@'localhost' IDENTIFIED BY 'some_pass';

Il check, lanciato da linea di comando, sarà il seguente:

~# /usr/local/nagios/libexec/check_mysql -u nagiosCheck -p some_pass
Uptime: 1061012  Threads: 2  Questions: 192277  Slow queries: 0  Opens: 198  Flush tables: 1  Open tables: 64  Queries per second avg: 0.181

Inseriamo quindi tale check in /usr/local/nagios/etc/nrpe.cfg:

command[check_mysql]=/usr/local/nagios/libexec/check_mysql -u nagiosCheck -p some_pass

Da notare che nel server Nagios il nome dell’argomento da passare a check_nrpe sarà check_mysql come definito tra le parentesi quadre.
A questo punto dal server Nagios si può testare il check remoto:

~# /usr/local/nagios/libexec/check_nrpe -H tomcat.mailalyzer.com -c check_mysql
Uptime: 1061534  Threads: 2  Questions: 192280  Slow queries: 0  Opens: 198  Flush tables: 1  Open tables: 64  Queries per second avg: 0.181

Se è tutto ok non resta che inserirlo tra i servizi dell’host B:

web.company-b.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-b.com
 service_description             MySQL
 check_command                   check_nrpe!check_mysql
}

E questo conclude la configurazione della nostra rete di test. Nella prossima puntata spiegherò come configurare dei server slave per effettuare check passivi, necessari, ad esempio, in configurazioni di rete complesse in cui il server master non può direttamente raggiungere gli host da controllare (se l’host da controllare è all’interno di una LAN, per dirne una).

Leggi la prima parte della guida

Premesso che sono d’accordo con le motivazioni che hanno portato a far slittare il rilascio di una settimana, mi imbarazza un po’ vedere il banner del countdown del rilascio di Fedora 11 salire anziche’ scendere. E quindi non posso che essere d’accordo con Felipe quando afferma che il modello a rilasci fissi sia quantomeno imperfetto. Insomma, tutto sommato mi piace l’idea un po’ Debian-style di rilasciare una versione solo quando e’ pronta, sempre che non ci vogliano tre anni prima di decidersi a fare il passo…

gpg --keyserver subkeys.pgp.net --recv CHIAVE
gpg --export --armorCHIAVE | sudo apt-key add -

Et Volià…

Debian Etch installation

Let’s start installing Debian Etch from businesscard and unchecking all the default packages (Desktop environment and Base system). After the reboot install some basic package:

apt-get install build-essential vim openssh-server psmisc autoconf file

OpenSSH is just an optional server, but i’m working on a VMWare virtual machine and an ssh console is more comfortable than the VMWare console :)

Softwares

Now download all the needed packages into /usr/src:

• OpenSSL 0.9.8i
• BerkeleyDB 4.6.21 (version 4.7 is unsupported from OpenLDAP)
• OpenLDAP 2.4.11
• Apache 2.2.9
• IMAP 2007b
• PHP 5.2.6
• Postfix 2.5 Patchlevel 5
• Dovecot 1.1.3

OpenSSL

~$ cd /usr/src/openssl
~$ ./config --openssldir=/usr/local/openssl --prefix=/usr/local/openssl
~$ make
~# make install


BerkeleyDB

~$ cd /usr/src/db/build_unix
~$ ../dist/configure --prefix=/usr/local/BerkeleyDB
~$ make
~# make install


OpenLDAP

~# ln -s /usr/local/BerkeleyDB/include/db.h /usr/include/
~$ CPPFLAGS="-I/usr/local/BerkeleyDB/include/" LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB/lib" LD_LIBRARY_PATH="/usr/src/db-4.6.21.NC/build_unix/.libs/" ./configure --prefix=/usr/local/openldap --enable-crypt
~$ make depend
~$ make
~$ make test
~# make install


For this howto i’ll use dc=example,dc=com. Edit /usr/local/openldap/etc/openldap/slapd.conf including some schemas and setting the password for cn=Manager,dc=example,dc=com

include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema


Rename /usr/local/openldap/var/openldap-data/DB_CONFIG.example to /usr/local/openldap/var/openldap-data/DB_CONFIG and type:
/usr/local/openldap/libexec/slapd
to start the server.

Then create an ldif file (base.ldif) for the initial user:
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: example
dc: example

dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager


and add it to the database:
/usr/local/openldap/bin/ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f base.ldif


Now let’s create some users, i’ll use these objects:
objectClass: inetOrgPerson
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount


An example:
dn: cn=tommaso,ou=utenti,dc=example,dc=com
cn: Tommaso
gidNumber: 10001
homeDirectory: /mail/tommaso
sn: Visconti
uid: tommaso
uidNumber: 10001
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
loginShell: /bin/bash
givenName: Tommaso
mail: tommaso@example.com
shadowWarning: 7
shadowMax: 99999
shadowLastChange: 14121
labeledURI: pippo
employeeType: active
userPassword: {CRYPT}cfBmIgztxLBh6


If you want to set these users as system users install libnss-ldap
apt-get install libnss-ldap
and edit /etc/nsswitch.conf
passwd: compat ldap
group: compat ldap
shadow: compat ldap

and create the group:
groupadd -g 10001 users

You can verify with:
getent passwd

Apache

~$ cd /usr/src/apache2

~$ ./configure --prefix=/usr/local/apache2 --enable-so --with-ssl=/usr/local/openssl/ --enable-ssl
~$ make
~# make install


Edit /usr/local/apache2/conf/apache.conf and launch with:
/usr/local/apache2/bin/apachectl -k start

IMAP

The IMAP library is needed from PHP to send email from the webmail.
~$ wget ftp://ftp.cac.washington.edu/imap/imap.tar.Z
~$ cd /usr/src
~$ tar xvzf imap.tar.Z
~$ cd imap-2007b
~$ make slx SSLTYPE=none
~$ mkdir -p /usr/local/imap/lib
~$ mkdir /usr/local/imap/include
~$ cp c-client/*.h /usr/local/imap/include/
~$ cp c-client/*.c /usr/local/imap/lib/
~$ cp c-client/c-client.a /usr/local/imap/lib/libc-client.a


PHP

First, download and unzip the mysql client libraries, then:
~$ apt-get install libjpeg-dev libpng-dev libxml2-dev libmcrypt-dev libmagic1
~$ cd /usr/src/php
~$ ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/local/apache2/bin/apxs --with-gettext --with-~$ mcrypt --with-iconv --enable-mbstring=all --enable-mbregex --with-gd --with-png-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-mime-magic=/usr/share/file/magic.mime --with-sqlite --with-ldap=/usr/local/openldap/ --with-imap=/usr/local/imap --with-mysql=/usr/src/mysql-5.0.67-linux-i686/ --with-mysqli=/usr/src/mysql-5.0.67-linux-i686/bin/mysql_config
~$ make
~$ make install


Edit apache.conf adding index.php to the default pages; if not present add this too:
<filesmatch \.php$>
SetHandler application/x-httpd-php
</filesmatch>


Postfix

Create /etc/ld.so.conf.d/my_libraries.conf:
/usr/local/openssl/lib
/usr/local/BerkeleyDB/lib
/usr/local/openldap/lib

and launch ldconfig!

~# ln -s /usr/local/BerkeleyDB/lib/libdb.so /usr/lib
~# addgroup --system postfix
~# adduser --system -ingroup postfix --home /mail --no-create-home --disabled-password postfix
~# addgroup --system postdrop
~# addgroup --gid 800 maildeliver
~# adduser --system --uid 800 --gid 800 --home /mail --disabled-password --no-create-home maildeliver
~$ export LD_LIBRARY_PATH="/usr/local/openldap/lib:/usr/local/BerkeleyDB/lib/"
~$ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/usr/local/postfix/etc\" -DDEF_COMMAND_DIR=\"/usr/local/postfix/sbin\" -DDEF_DAEMON_DIR=\"/usr/local/postfix/libexec\" -DDEF_MANPAGE_DIR=\"/usr/local/postfix/man\" -DDEF_SENDMAIL_PATH=\"/usr/local/postfix/bin/sendmail\" -DDEF_MAILQ_PATH=\"/usr/local/postfix/bin/mailq\" -DDEF_DATA_DIR=\"/usr/local/postfix/lib\" -DHAS_DB -I/usr/local/BerkeleyDB/include -DHAS_LDAP -I/usr/local/openldap/include' AUXLIBS='-llber -L/usr/local/BerkeleyDB/include/ -ldb -lldap -L/usr/local/openldap/lib'
~$ make
~# make install
~# ln -s /usr/local/postfix/etc/aliases /etc/
~# /usr/local/postfix/sbin/postfix -c /usr/local/postfix/etc/ set-permissions
~# chown -R postfix /usr/local/postfix/lib


The gid and user 800 will be used for the virtual transport.

This is main.cf:
queue_directory = /usr/local/postfix-2.5.5/spool
command_directory = /usr/local/postfix-2.5.5/sbin
daemon_directory = /usr/local/postfix-2.5.5/libexec
data_directory = /usr/local/postfix-2.5.5/lib
mail_owner = postfix
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/local/postfix-2.5.5/sbin/sendmail
newaliases_path = /usr/local/postfix-2.5.5/bin/newaliases
mailq_path = /usr/local/postfix-2.5.5/bin/mailq
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/local/postfix-2.5.5/man
readme_directory = no
smtpd_banner = Benvenuti ai puri di cuore
biff = no
append_dot_mydomain = no
myhostname = mail.example.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 192.168.0.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
virtual_transport = virtual
virtual_uid_maps = static:800
virtual_gid_maps = static:800
virtual_mailbox_base = /mail
virtual_mailbox_maps = ldap:/usr/local/postfix-2.5.5/etc/ldap-accounts.cf
virtual_mailbox_domains = example.com
virtual_alias_maps = hash:/etc/aliases
relay_domains = localhost

ldap-accounts.cf:
server_host = localhost
search_base = ou=utenti,dc=example,dc=com
query_filter = mail=%s
result_attribute = uid
version = 3
bind = yes
bind_dn = cn=Manager,dc=example,dc=com
bind_pw = pippo


Remember to create an user for bindings and edit Postfix and Dovecot configurations to use it.
To verify the ldap file use postmap:
~$ postmap -q tommaso.visconti@example ldap:/usr/local/postfix/etc/ldap-aliases.cf
tommaso

Start postfix with:
~# /usr/local/postfix/sbin/postfix start

Dovecot

~$ cd /usr/src/dovecot
~$ LDFLAGS="-L/usr/local/openldap/lib -L/usr/local/openssl/lib" CPPFLAGS="-I/usr/local/openldap/include -I/usr/local/openssl/include/" ./configure --prefix=/usr/local/dovecot --with-ldap=yes --with-ssl=openssl
~$ make
~# make install
~# adduser --system -ingroup mail --home /usr/local/dovecot/lib --no-create-home --shell /bin/false --disabled-password dovecot


This is dovecot.conf:
protocols = imap imaps pop3 pop3s
mail_uid = 800
mail_gid = 800
listen = *
disable_plaintext_auth = no
shutdown_clients = yes
log_path = /var/log/dovecot.log
info_log_path = /var/log/mail.log
log_timestamp = "%Y-%m-%d %H:%M:%S "
syslog_facility = mail
ssl_listen = *
ssl_disable = no
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem
login_chroot = yes
login_greeting = Welcome to my mail server.
login_log_format_elements = user=< %u> method=%m rip=%r lip=%l %c
login_log_format = %$: %s
mail_location = maildir:/mail/%n
mail_full_filesystem_access = no
mail_debug = no
first_valid_uid = 800
last_valid_uid = 800
first_valid_gid = 800
last_valid_gid = 800
protocol imap {
}
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}
auth_verbose = no
auth_debug = no
auth_debug_passwords = no
auth default {
mechanisms = PLAIN LOGIN
passdb ldap {
args = /usr/local/Dovecot-1.1.3/etc/dovecot-ldap.conf
}
userdb ldap {
# Path for LDAP configuration file, see /etc/dovecot/dovecot-ldap.conf for example
args = /usr/local/Dovecot-1.1.3/etc/dovecot-ldap.conf
}
user = mail_deliver
}
dict {
}
plugin {
}


and dovecot-ldap.conf:
hosts = localhost
dn = cn=Manager,dc=example,dc=come
dnpass = pippo
ldap_version = 3
base = ou=utenti, dc=example, dc=com
deref = never
scope = subtree
user_attrs = homeDirectory=home
user_filter = (&(employeeType=active)(mail=%u))
pass_attrs = mail=user@domain,userPassword=password
pass_filter = (&(employeeType=active)(mail=%u))
default_pass_scheme = CRYPT


Start dovecot with /usr/local/dovecot/sbin/dovecot

Webmail

I suggest Horde Framework or Roundcube

Webography

• OpenSSL
• BerkeleyDB
• OpenLDAP
• Apache
• IMAP
• PHP
• PHPLdapAdmin
• Postfix
• Dovecot

Fattostà che il mondo linux ha come sempre reagito con rapidità e sono fioccati gli aggiornamenti di sicurezza. In particolare Debian ha anche aggiunto il pacchetto openssl-blacklist in cui sono elencate una serie di chiavi vulnerabili. Fin qui tutto bene, non fosse che la chiave con cui accedevo via ssh al mio server sia stata simpaticamente messa in blacklist, col risultato che adesso sono allegramente chiuso fuori casa…

…e mi sono anche meritatamente preso di niubbo da Alessandro :(

Edit:

Aggiungo questa vignetta fantastica di Dilbert sulla randomizzazione secondo Debian :D

Edit 2:

Sembra che a quelli di Debian proprio non vogliano fargliela passare liscia :D

English version

L’idea è semplice: utilizzare una base sicura (e meglio “aggeggiabile”) come Debian Etch con cui virtualizzare Windows Server 2003 (per alcuni servizi che non si possono far girare altrimenti) utilizzando VirtualBox.
Tutto sommato non è stato così difficile, ecco qua cosa ho fatto.

Installazione

Ho effettuato l’installazione del “sistema standard” aggiungendo poi ai repository quello di virtualbox come descritto nella pagina ufficiale di download.
Il pacchetto da installare è virtualbox che si porta dietro un bel po’ di dipendenze:

I seguenti pacchetti NUOVI (NEW) saranno installati:
cpp cpp-4.1 defoma fontconfig fontconfig-config libasound2 libaudio2 libdirectfb-0.9-25 libexpat1 libfontconfig1
libfreetype6 libglib2.0-0 libice6 libicu36 libidl0 libjpeg62 liblcms1 libmng1 libpng12-0 libqt3-mt libsdl1.2debian
libsdl1.2debian-alsa libsm6 libsvga1 libsysfs2 libx11-6 libx11-data libxalan110 libxau6 libxcursor1 libxdmcp6
libxerces27 libxext6 libxfixes3 libxft2 libxi6 libxinerama1 libxrandr2 libxrender1 libxt6 psmisc svgalibg1
ttf-dejavu virtualbox x11-common

Quindi aggiungete al gruppo vboxusers l’utente che poi lancerà la macchina virtuale (eventualmente createlo prima, io ho usato winserver2003).

Se volete lanciare la GUI VirtualBox per la configurazione della macchina virtuale o per utilizzarla in locale e’ necessario installare anche i pacchetti xorg (o quelli che ritenete più opportuni per poter lanciare X e xterm) e libxalan110. Questi pacchetti non sono invece necessari se la macchina sara’ configurata da console (o su un’altra macchina) e se sara’ necessario solo l’accesso remoto.

ATTENZIONE
Puo’ capitare che la compilazione del modulo vboxdrv fallisca, in questo caso verificate di aver installato il pacchetto linux-headers-vostrokernel ed, eventualmente, build-essential, dopodiche’ rilanciate

 ~# /etc/init.d/vboxdrv setup

Creazione e configurazione della macchina virtuale con la GUI

A questo punto si può lanciare X con startx (dall’utente appena aggiunto al gruppo vboxusers) e da xterm si lancia virtualbox col comando VirtualBox. Creare una macchina virtuale è molto semplice e potete far riferimento alle tantissime risorse già presenti su internet. L’unica nota è non attivare il server RDP presente in VirtualBox (funziona malissimo!), se necessario meglio usare quello di Windows.

La macchina virtuale puo’ essere creata su un pc e poi spostata nel server finale (dove, magari, non e’ installato l’ambiente grafico) semplicemente spostando (e impostando poi i giusti permessi) la cartella ~/.VirtualBox.

Configurare la rete

La procedura consiste nel creare una scheda di rete virtuale vbox0 e un bridge tra essa e la scheda fisica su cui, per comodità, ho creato un ip alias per gestire meglio le richieste.

Ecco quindi il file /etc/network/interfaces col quale imposto l’ip primario e un alias che assocerò alla macchina virtuale:

# Interfaccia fisica
auto eth0
iface eth0 inet static
        address 192.168.2.60
        netmask 255.255.255.0
        gateway 192.168.2.254
        dns-nameservers 208.67.222.222 208.67.220.220

# Interfaccia virtuale
auto eth0:1
iface eth0:1 inet static
        address 192.168.2.61
        netmask 255.255.255.0

Poi, dopo aver installato bridge-utils, bisogna creare il bridge br0 tra eth0:1 e vbox0, io ho creato uno script che faccio avviare all’inizio, ovvero /etc/init.d/bridge linkato in /etc/rc.2/S20bridge.
ATTENZIONE: è fondamentale che parta PRIMA che virtualbox abbia creato vbox0, altrimenti br0 non viene trovato, ovvero prima dei files S20vboxdrv e S20vboxnet.

Ecco quindi /etc/init.d/bridge:

#!/bin/bash
brctl addbr br0
ifconfig br0 10.1.1.1 netmask 255.255.255.0 up

# Regole per far funzionare PASV mode in FTP
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp

echo 1 > /proc/sys/net/ipv4/ip_forward

# Giro tutte le richieste su .61 alla macchina virtuale
iptables -t nat -A PREROUTING -p tcp -d 192.168.2.61 -j DNAT --to 10.1.1.2

# Con queste regole si possono girare singole porte
# HTTP
#iptables -t nat -A PREROUTING -p tcp -d 192.168.2.61 --dport 80 -j DNAT --to 10.1.1.2:80
# HTTPS
#iptables -t nat -A PREROUTING -p tcp -d 192.168.2.61 --dport 443 -j DNAT --to 10.1.1.2:443
# Desktop Remoto
#iptables -t nat -A PREROUTING -p tcp -d 192.168.2.61 --dport 3389 -j DNAT --to 10.1.1.2:3389

# Permetto alla macchina virtuale di navigare
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.2 -j MASQUERADE

Infine creo l’interfaccio vbox0, prima però è meglio riavviare la rete per aggiornare gli indirizzi ip (attenzione se cambiate l’ip e siete connessi via SSH) ed eseguire lo script /etc/init.d/bridge per creare il bridge (altrimenti verrà mostrato un errore che si risolverà al riavvio del pc).

/etc/init.d/netrworking restart
chmod +x /etc/init.d/bridge
/etc/init.d/bridge

Il comando qui di seguito crea vbox0 e salva la cui configurazione nel file /etc/vbox/interfaces):

VBoxAddIF vbox0 nomeutente br0

Al posto di nomeutente ho usato winserver2003.
Ricordatevi di impostare su Windows l’ip a 10.1.1.2/24 e il gateway a 10.1.1.1

Avvio automatico all’accensione del pc

Per avviare con l’interfaccia grafica ho usato gdm con login automatico dell’utente con cui lancio la macchina virtuale e nel file .bashrc ho inserito il comando necessario a lanciare la macchina da console:

VBoxSDL -fullscreen -vm WinServer2003

Se invece volete soltanto l’accesso remoto alla macchina il comando e’:

VBoxVRDP -startvm WinServer2003

Per l’avvio automatico ho creato il file /etc/init.d/VBoxAutostart linkato in /etc/rc.2/S99VBoxAutostart come questo qui sotto:

#!/bin/bash

echo -e ""
echo -e "### AVVIO DELLA MACCHINA VIRTUALE ###"
echo -e ""
su winserver2003 -c 'VBoxVRDP -startvm WinServer2003 &'
sleep 5
echo -e ""

In alternativa e’ possibile creare uno script contenente

VBoxVRDP -startvm WinServer2003 &

da lanciare poi con start-stop-daemon sempre nel file /etc/init.d/VBoxAutostart

#!/bin/bash
start-stop-daemon --start -c winserver2003 --exec /path/script.sh

Cose che capitano…
Ho avuto modo di provare più volte la procedura descritta qui sopra e di correggerla altrettante volte a causa di qualche “svista”. Alcuni fallimenti nella creazione/avvio della macchina virtuale però non sono relativi alla procedura da me descritta ed ho quindi deciso di elencarli per cercare di esservi d’aiuto.

Se, ad esempio, la macchina da linea di comando non si avvia con l’errore Invalid machine name! non è proprio detto che sia sbagliato il nome della macchina. Nel mio caso infatti mi ero scordato di creare la cartella /home/winserver2003/scambio che avevo impostato come cartella di scambio tra il sistema host e quello virtuale.

Altri errori sui permessi, ad esempio, dell’uso del cdrom o altre periferiche li ho risolti aggiungendo l’utente ai gruppi relativi (audio, cdrom, floppy, plugdev, ecc.)

continua… :D