http://www.digium.com/en/products/ivr/audio-converter.php

Otras formas de convertir las locuciones es con la utilidad del propio CLI:

rasterisk -x 'file convert /var/lib/asterisk/sounds/es/prueba.wav /var/lib/asterisk/sounds/es/prueba.gsm'


O con el comando sox, lame y mpg123

# apt-get install sox mpg123 lame

Convertir WAV a SLIN:
# sox entrada.wav -t raw -r 8000 -c 1 -w -s salida.slin


Sin embargo como podéis ver, la más útil y simple es la herramienta online de Digium.
De esta forma servimos las locuciones en el formato adecuado y evitamos sobrecargar la CPU al hacer transcoding.

Para hacernos una idea de que va la cosa podemos empezar por leer:
http://dev.mysql.com/doc/refman/5.0/es/ndbcluster.html
y
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html

Como véis hay un MGM o Management node (que ejecuta el demonio “ndb_mgmd”) y los Nodos (ejecutando el servicio ndbd).
Después de un tiempo leyendo y habiendo aprendido los conceptos generales, empezamos:

Instalación MGM o Management node

Para instalar el MGM en ubuntu, teóricamente tendría que ser tan fácil como hacer:
# apt-get install mysql-server
# apt-get install mysql-cluster-server


No obstante instalar el paquete ‘mysql-cluster-server’ en Lucid 10.04 LTS3 (a día de hoy) es tarea de locos por temas de dependencias incumplidas.
Si hacemos eso, al instalar mysql-cluster-server-5.1 nos sale este error:

dpkg: error al procesar /var/cache/apt/archives/mysql-cluster-client-5.1_7.0.9-1ubuntu7_amd64.deb (--unpack):
 intentando sobreescribir `/usr/bin/mysql', que está también en el paquete mysql-client-core-5.1 0:5.1.41-3ubuntu12.10
dpkg-deb: el subproceso copiado fue terminado por la señal (Tubería rota)
Seleccionando el paquete mysql-cluster-server-5.1 previamente no seleccionado.
Desempaquetando mysql-cluster-server-5.1 (de .../mysql-cluster-server-5.1_7.0.9-1ubuntu7_amd64.deb) ...
dpkg: error al procesar /var/cache/apt/archives/mysql-cluster-server-5.1_7.0.9-1ubuntu7_amd64.deb (--unpack):
 intentando sobreescribir `/usr/bin/my_print_defaults', que está también en el paquete mysql-server-core-5.1 0:5.1.41-3ubuntu12.10
dpkg-deb: el subproceso copiado fue terminado por la señal (Tubería rota)
Seleccionando el paquete ssl-cert previamente no seleccionado.
Desempaquetando ssl-cert (de .../ssl-cert_1.0.23ubuntu2_all.deb) ...
Seleccionando el paquete postfix previamente no seleccionado.
Desempaquetando postfix (de .../postfix_2.7.0-1ubuntu0.2_amd64.deb) ...
Seleccionando el paquete bsd-mailx previamente no seleccionado.
Desempaquetando bsd-mailx (de .../bsd-mailx_8.1.2-0.20090911cvs-2ubuntu1_amd64.deb) ...
Seleccionando el paquete mysql-cluster-client previamente no seleccionado.
Desempaquetando mysql-cluster-client (de .../mysql-cluster-client_7.0.9-1ubuntu7_all.deb) ...
Seleccionando el paquete mysql-cluster-server previamente no seleccionado.
Desempaquetando mysql-cluster-server (de .../mysql-cluster-server_7.0.9-1ubuntu7_all.deb) ...
Procesando disparadores para ureadahead ...
Se encontraron errores al procesar:
 /var/cache/apt/archives/mysql-cluster-client-5.1_7.0.9-1ubuntu7_amd64.deb
 /var/cache/apt/archives/mysql-cluster-server-5.1_7.0.9-1ubuntu7_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

…que no se soluciona ni con un ‘apt-get -f install’ tal y como dice.
No se porque sucede esto y si alguien sabe por que pasa o sabe solucionarlo mejor agradecería que me lo comentase .
Como lo slucioné yo fue haciendo un: ‘dpkg -l mysql*’ y “purgando” todos los paquetes relacionados con mysql instalados o a medio instalar:
# apt-get purge mysql-client-core-5.1 mysql-cluster-client mysql-cluster-client-5.1 mysql-cluster-server mysql-cluster-server-5.1 mysql-common mysql-server-5.1 mysql-server-core-5.1 libmysqlclient16 libdbd-mysql-perl


Luego un:
# apt-get autoremove


y ya finalmente nos deja instalarlo correctamente:
# apt-get install mysql-cluster-server


Una vez instalado configuramos el MGM. Creamos el archivo /etc/mysql/ndb_mgmd.cnf y ponemos:

[NDBD DEFAULT]
NoOfReplicas=2
DataMemory=256M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
# For DataMemory and IndexMemory, we have used the
# default values. Since the "world" database takes up
# only about 500KB, this should be more than enough for
# this example Cluster setup.
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]
# Section for the cluster management node
[NDB_MGMD]
# IP address of the management node (this system)
HostName=192.168.2.210

# Section for the storage nodes
[NDBD]
# IP address of the first storage node
HostName=192.168.2.211
DataDir=/var/lib/mysql-cluster
BackupDataDir=/var/lib/mysql-cluster/backup
DataMemory=512M

[NDBD]
# IP address of the second storage node
HostName=192.168.2.212
DataDir=/var/lib/mysql-cluster
BackupDataDir=/var/lib/mysql-cluster/backup
DataMemory=512M

# one [MYSQLD] per storage node
[MYSQLD]
[MYSQLD]

Como véis definimos la ip del mgm (la 2.210) y la de los dos nodos que vamos a poner (2.211 y 2.212).

Creamos los dirs de los backups:
# mkdir -p /var/lib/mysql-cluster/backup
# chown -R mysql:mysql /var/lib/mysql-cluster


Nodos

Instalamos 2 máquinas virtuales mínimas para los 2 Nodos.
Instalamos mysql-server con soporte ndb en cada uno de los nodos:
# apt-get install mysql-server
# apt-get install mysql-cluster-server


Si da el error de arriba de dependencias, ya sabéis…

Confuguramos los nodos. Editamos el archivo /etc/mysql/my.cnf de cada uno de ellos y añadimos:
- En la sección [mysqld] añandimos:
ndbcluster
# IP address of the cluster management node
ndb-connectstring=192.168.2.210


- Y al final del archivo añadimos:
[MYSQL_CLUSTER]
ndb-connectstring=192.168.2.210


Iniciamos el cluster

En el admin iniciamos el demonio ndb-mgmd:
# /etc/init.d/mysql-ndb-mgm restart


En cada uno de los nodos el demonio ndbd:
# /etc/init.d/mysql restart
# /etc/init.d/mysql-ndb restart


Comprobaciones

Comprobamos que todo ha ido bien.
En el manager ‘mgm’ ejecutamos:
# ndb_mgm


y en el prompt ejecutamos:
ndb_mgm> show;


Tendríamos que ver que los dos nodos están conectados:

Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=2    @192.168.2.211  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)
id=3    @192.168.2.212  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.2.210  (mysql-5.1.39 ndb-7.0.9)

[mysqld(API)]   2 node(s)
id=4    @192.168.2.211  (mysql-5.1.39 ndb-7.0.9)
id=5    @192.168.2.212  (mysql-5.1.39 ndb-7.0.9)

Probando el cluster

Creamos una database por ejemplo en el nodo1:

# mysqladmin -u username -p create mysqlclustertest


Hay que tener en cuenta que las tablas que se creen en la database han de ser creadas con el parámetro ‘ENGINE=NDBCLUSTER’ para que puedan ser replicadas entre los nodos

mysql>
USE mysqlclustertest;
CREATE TABLE testtable (I INT) ENGINE=NDBCLUSTER;
INSERT INTO testtable () VALUES (1);
SELECT * FROM testtable;
quit;

Al momento si vamos al nodo2 y hacemos un show databases; veremos que ya está creada.

Ahora una prueba de fuego. Vamos al nodo1 y lo paramos:
/etc/init.d/mysql-ndb stop


Si vamos a la consola del mgm y hacemos un show veremos que ese nodo está parado:

ndb_mgm> show;
Cluster Configuration
---------------------
[ndbd(NDB)]	2 node(s)
id=2 (not connected, accepting connect from 192.168.2.211)
id=3	@192.168.2.212  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)

[ndb_mgmd(MGM)]	1 node(s)
id=1	@192.168.2.210  (mysql-5.1.39 ndb-7.0.9)

[mysqld(API)]	2 node(s)
id=4	@192.168.2.211  (mysql-5.1.39 ndb-7.0.9)
id=5	@192.168.2.212  (mysql-5.1.39 ndb-7.0.9)

Ahora en el nodo dos si hacemos un:

mysql> SELECT * FROM testtable;
+------+
| I    |
+------+
|    1 |
+------+
1 rows in set (0.00 sec)

Veremos que la tabla sigue disponible aunque el primer nodo esté caído.
Vamos a insertar un campo mas en el nodo2 con el uno caído:
mysql> INSERT INTO testtable () VALUES (2);


Si volvemos a hacer una consulta:

mysql> SELECT * FROM testtable;
+------+
| I    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

Ahora arrancamos el nodo1 de nuevo:
# /etc/init.d/mysql-ndb start


…veremos que en la consola del mgm ya aparecerá como disponible y si hacemos una consulta veremos que ya están los datos replicados:

mysql> SELECT * FROM testtable;
+------+
| I    |
+------+
|    2 |
|    1 |
+------+
2 rows in set (0.00 sec)

Apagando o reiniciando el cluster

Para apagarlo en orden, en la consola del mgm ejecutamos:

ndb_mgm> shutdown;
Node 2: Cluster shutdown initiated
Node 3: Cluster shutdown initiated
Node 3: Node shutdown completed.
Node 2: Node shutdown completed.
2 NDB Cluster node(s) have shutdown.
Disconnecting to allow management server to shutdown.

Y vemos como apaga el servicio ndb de los dos nodos. De echo si vamos a cada nodo y ejecutamos un:
# ps aux | grep ndbd | grep -iv grep


…veremos que no hay ningún servicio corriendo. (Ojo, mysql si que sigue corriendo en cada nodo pero sin soporte ‘ndbcluster’).

Ahora ya podríamos hacer un shutdown de los nodos y del mgm.

La forma de reinicio de los servers, sería primero el mgm y luego ir iniciando los nodos

Si no hemos reinciiado las máquinas, para volver a conectar los nodos iniciamos primero en ndb-mgm en el mgm:
# /etc/init.d/mysql-ndb-mgm start


Y luego los servicios ndb en cada nodo:
# /etc/init.d/mysql-ndb start


Nuevamente con un show en el mgm comprobamos que todo ha ido bien y veulvan a estar conectados.

Dimensionamiento

Hay que leer la documentación para ver cuantos nodos podemos poner hasta que el sistema se degrade, ya que no podemos poner nodos infinitamente. Aunque repito que si esto os pasa seguramente es que no necesitéis leer esto.
También hay que tener en cuenta que todos los datos de los nodos van sobre RAM, así que hace falta mucha RAM. Se puede aplicar esta ecuación:
(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

Así que si tienes una database de 1GB, necesitarás 1.1GB de RAM en cada nodo.

Para acabar

IMPORTANTE: Ojo, esta arquitectura es mínima. El LoadBalancer y el MGM son dos puntos de fallo crítico, así que estos servidores deberían de ir en HA con por ejemplo Heartbeat + Drdb y si cae alguno de los dos se levante el secundario. Así que una instalación fiable de un cluster mysql sería como mínimo 6 máquinas (2xLoadBalancer + 2xMGM + 1xNodo + 1xNodo).

Y todo esto está muy bien, pero con esta arquitectura cada servicio tendría que atacar a cada nodo mysql por separado y estamos en las mismas. Así que nos quedaría configurar un LoadBalancer con una ip virtual a la que atacar desde nuestro servicio y este reparta las peticiones entre los nodos disponibles.

El Lodabalancer y heartbeat están explicados en otros posts, aunque siempre podéis contratar los servicios de consultoría de servidor, que vive de esto …

Fuentes:
http://dev.mysql.com/doc/refman/5.0/es/ndbcluster.html
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html
http://bieg.wordpress.com/2008/08/03/mysql-clustering-ubuntu/
http://www.awven.com/q141-crear-un-cluster-mysql-ubuntu-server-1104/
http://www.monkeedev.co.uk/blog/2009/04/01/setting-up-mysql-50-cluster-on-debian-and-ubuntu/
http://www.howtoforge.com/loadbalanced_mysql_cluster_debian
http://www.howtoforge.com/setting-up-a-loadbalanced-mysql-cluster-with-mysql5.1-p2

...
'"9994"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"9995"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"9996"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"9997"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"9998"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"9999"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found
[Nov 10 15:51:37] NOTICE[2979]: chan_sip.c:XXXXX handle_request_register: Registration from '"10000"' failed for 'XXX.XXX.XXX.XXX' - No matching peer found

Es por eso que hay que tener cuidado de tener bien configurado el dialplan y las extensiones para no llevarte una sorpresita algún día de una factura de miles de euros.

Para prevenir estos ataques podemos usar fail2ban para que cuando detecte un cierto nº de registros erróneos banee esa ip.

Instalmos fail2ban:
# apt-get install fail2ban


Esto ya te instala iptables.
Los archivos de config están en /etc/fail2ban
Editamos /etc/fail2ban/jail.conf que es donde se definen los diferentes servicios que queremos banear y lo que queremos hacer en caso de que intenten atacar ese servicio. Podemos echar un vistazo al de ssh para crear el nuestro.
Yo he definido al final uno tal que así:

# Asterisk
[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
           sendmail-whois[name=ASTERISK, dest=gonzalo@loquesea.com, sender=loquesea.com]
logpath  = /var/log/asterisk/messages
maxretry = 5
bantime = 259200

omo veis es muy simple. Define una regla que bloquea el acceso por iptables a esa ip si lo intenta de forma errónea mas de 5 veces (maxretry) y la banea durante 72 horas (259200 secs).
También nos envía un mail con el whois de la ip y lo guarda en los logs.

Al prinicpio de este archivo quizás queramos definir también las ip’s que no serán baneadas, por si algún día banea la nuestra propia (separadas por espacios):
ignoreip = 127.0.0.1 192.168.1.10 192.168.1.2


A continuación editamos las reglas del servicio asterisk en el archivo /etc/fail2ban/filter.d/asterisk.conf
ACTUALIZACION para Asterisk 1.8. La configuración que ponen en la mayoría de los sitios NO FUNCIONA. Incluso no funciona la del libro oficial de Asterisk Asterisk – The definitive guide. Si no, pruébalo tu mismo desde casa. Así que porque no te estén llegando mails de avisos del servicio fail2ban no es porque todo vaya bien y se hayan olvidado de ti. De echo, todo lo contrario, es muy mala señal. Así que ahí va un filter que realmente funciona en Asterisk 1.8:

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf                                                                                 

[Definition]

#_daemon = asterisk                                                                                   

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P\S+)
# Values:  TEXT
#                                                                                                     

failregex = NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - No matching peer found
            NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - Wrong password
            NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - Username/auth name mismatch
            NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - Device does not match ACL
            NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - Peer is not supposed to register
            NOTICE.* .*: Registration from '\".*\".*' failed for '(:[0-9]{1,5})?' - ACL error (permit/deny)
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - No matching peer found
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - Wrong password
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - Username/auth name mismatch
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - Device does not match ACL
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - Peer is not supposed to register
            NOTICE.* .*: Registration from '.*' failed for '(:[0-9]{1,5})?' - ACL error (permit/deny)
            NOTICE.*  failed to authenticate as '.*'$
            NOTICE.* .*: No registration for peer '.*' \(from \)
            NOTICE.* .*: Host  failed MD5 authentication for '.*' (.*)
            NOTICE.* .*: Failed to authenticate user .*@.*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Esta nueva configuración es porque ahora Asterisk 1.8 incluye el puerto ’192.168.200.100:36998′ y las expresiones regulares de la antigua config no las matchea bien.

De hecho fail2ban no es del todo fiable para un sistema “muy” crítico y donde se busca la seguridad ante todo (ver explicación en info sobre fail2ban y en más info). Por eso recomiendo al final de este post que siempre que sea posible denegar todas las IP’s con iptables y habilitar solo las extrictamente necesarias.
O utilizar otros métodos…

Antes de reiniciar asterisk, hay que cambiar el formato de la fecha que se pone en los logs, si no fail2ban será incapáz de parsearla y hacer un matching. Para ello editamos el archivo de asterisk /etc/asterisk/logger.conf y descomentamos en la sección [general] la línea:
dateformat=%F %T
y:
console => notice,warning,error
messages => notice,warning,error

y ejecutamos en el CLI> de asterisk:

CLI> logger reload


Ahora ya podemos reiniciar el servicio:
# service fail2ban restart
* Restarting authentication failure monitor fail2ban [ OK ]


Ups!, un cliente cojonero se ha baneado, ¿cómo lo desbaneo?

Comprobamos que ip’s están bloquedadas con iptables:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ASTERISK  tcp  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       0    --  loquesea.net         anywhere
RETURN     0    --  anywhere             anywhere

Podemos ver que loquesea.net está bloqueada, así que para desbloquearla ejecutaremos:
# iptables -D fail2ban-ASTERISK 1


Si ejecutamos iptables -L de nuevo veremos que ya no está.

Bloquear todo lo que no venga de mi troncal de vozip

Aunque si no tenemos ningún cliente externo, seguramente lo mas seguro sea banear a todo el mundo que no sea la IP de nuestro troncal SIP. Para ello nada mejor que iptables, donde cerraríamos todo y habilitamos tan solo la conexión de nuestro proveedor o del troncal:
iptables -I INPUT 10 -p tcp --dport 5060 -s XX.XX.XX.XX -j ACCEPT


También estaría bien seguir otras directrices de seguridad tales y como se comenta en el libro de “Asterisk 3rd Ed – The definitive guide” o en el blog de Elío http://www.sinologic.net/blog/
Avisados estáis. Estamos hablando de un tema serio que puede acarrear un grave problema económico a la empresa…

Fuentes:
http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
http://www.fail2ban.org/wiki/index.php/Asterisk
http://hgeorge123.blogspot.com/2011/01/seguridad-en-asterisk-fail2ban.html
http://www.voip-info.org/wiki/view/Asterisk+firewall+rules

Servidor Munin

Funciona con arquitectura cliente/servidor. Hay dos paquetes ‘munin’ y ‘munin-node’. El primero lo instalaremos en el servidor y el segundo en los diferentes nodos/servers que queremos que monitorice.
Instalamos munin en el que va a hacer de servidor:

# apt-get install munin


Editamos /etc/munin/munin.conf y ponemos:

dbdir /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir /var/run/munin
#
# Where to look for the HTML template
tmpldir /etc/munin/templates

# a simple host tree
[services.loquesea.com]
address 127.0.0.1
use_node_name yes


En htmldir definimos que el dir de apache va a ir en /var/cache/munin/www y definimos también el nombre de dominio de nodo (porque el server va a hacer como nodo y servidor) dentro del servicdor de munin [services.loquesea.com]

También deberíamos editar el propio archivo del servidor para que cuando actúe como nodo (de si mismo) solo escuche de si mismo (loopback) y no en todas las interfaces de red. Editamos el archivo munin-node.conf y ponemos y cambiamos el valor ‘host’ a:

host 127.0.0.1


A continuación editamos el archivo apache.conf para definir el alias que le vamos a dar y darle protección para que nos pida usuario y contraseña:

Alias /munin /var/cache/munin/www

Order allow,deny
# Allow from localhost 127.0.0.0/8 ::1
Allow from all
Options None

# This file can be used as a .htaccess file, or a part of your apache
# config file.
#
# For the .htaccess file option to work the munin www directory
# (/var/cache/munin/www) must have "AllowOverride all" or something
# close to that set.
#

AuthUserFile /etc/munin/munin-htpasswd
AuthName "admin"
AuthType Basic
require valid-user

# This next part requires mod_expires to be enabled.
#

# Set the default expiration time for files to 5 minutes 10 seconds from
# their creation (modification) time. There are probably new files by
# that time.
#
ExpiresActive On
ExpiresDefault M310

Yo he definido que el username sea ‘admin’, así que creamos este usuario con htpasswd:

# htpasswd -c munin-htpasswd admin


Otro parámetro que queramos definir es el acceso. Yo he puesto:

# Allow from localhost 127.0.0.0/8 ::1
Allow from all


Que permite acceder desde cualquier sitio. Si solo quisiésemos acceder desde uestra red local podríamos poner algo así:

Allow from localhost 192.168.1.0/24 ::1


Por último reiniciamos munin y apache:

# service munin-node restart
# service apache2 restart


Ahora ya podemos acceder a las estadísticas en services.loquesea.com/munin
Tardarán un tiempo en estar llenas.

Cliente Munin

Ya tenemos el servidor corriendo con si mismo como el primer cliente. Para añadir nuevos clientes instalmos tan solo el paquete munin-node en otro servidor:

# apt-get install munin-node


Ahora tan solo tenemos que editar el archivo munin-node.conf y definir:

#
# Example config-file for munin-node
#

log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid

background 1
setsid 1

user root
group root

# Regexps for files to ignore

ignore_file ~$
#ignore_file [#~]$ # FIX doesn't work. '#' starts a comment
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$

# And which port
port 4949


Descomentamos ‘host_name’ y ponemos el nombre de dominio de este nodo.
En ‘allow’ ponemos la ip del servidor munin
En ‘host’ ponemos la ip de este nodo

Ahora vamos de vuelta otra vez al servidor y definimos en el archivo munin.conf este nodo:

[nombre.loquesea.com]
address 192.168.XX.XXX
use_node_name yes


Reiniciamos munin en el servidor y en el nodo:

# service munin-node restart


Y ya nos aparecerá en unos segundos en el interfaz web.

Es extensible con plugins y demás.
Los plugins se activan mediante enlaces en el dir /etc/munin/plugins a /usr/share/munin/plugins
Si vemos que es demasiada información y tan solo nos interesa el espacio en disco, red y dos cosas mas, podemos borrar los enlaces que queramos de /etc/munin/plugins y reiniciar el nodo (siempre tarda unos secs en actualizarse).

Como véis es un poco cutre y minimalista, pero muy útil si administras unas decenas de servidores.

Luego podríamos quedarnos con el primer número de la variable $TELF y decidir si sale por un lado o por otro:

exten => s,1,NoOp(Definimos si es una llamada a la exten SIP/moviles o SIP/fijos)
   same => n,ExecIf($[${TELF:0:1} = 9]?Set(SIPTRUNK=SIP/fijos):Set(SIPTRUNK=SIP/moviles))
   same => n,Dial(${SIPTRUNK}/${TELF},20)

Explico:

Fácil, no?

La última iso de estos drivers se puede encontrar aqui:

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

En concreto me bajo las versiones:
- virtio-win-1.1.16.iso
- virtio-win-1.1.16.vfd

Para hacer una instalación de Windows con estos drivers por ej en un Windows XP haremos así:

virt-install -c qemu:///system --virt-type kvm --name winxp --vcpus 1 --ram 1024 --os-variant winxp \
--disk /var/lib/libvirt/images/guests/winxp.img,size=30,sparse=false,bus=virtio \
--disk /var/lib/libvirt/images/isos/windows/virtio-win-1.1.16.vfd,device=floppy \
--cdrom /var/lib/libvirt/images/isos/windows/virtio-win-1.1.16.iso \
--cdrom /var/lib//libvirt/images/isos/windows/winxp.iso \
--network bridge:br0,model=virtio \
--vnc

Y en la instalación nos instalará estos drivers.

Mas fuentes sobre el tema:
http://cloud.ubuntu.com/2011/03/fast-win7-kvm-virtiodisk-net-install/
http://www.todosconsoftwarelibre.es/instalacion-de-windows-7-sobre-kvm-en-ubuntu-server-10-04-1/
http://bderzhavets.wordpress.com/2011/01/20/virtio-install-windows-7-kvm-x64x86-on-ubuntu-10-04-1-server-via-dnjl-ppa/
http://blog.allanglesit.com/2011/03/kvm-guests-install-virtio-drivers-for-windows-guests/
http://kahdev.wordpress.com/2011/05/30/using-virtio-drivers-in-a-kvm-windows-guest-vm/

Si hacemos un ‘lspci’ en nuestra máquina virtual, debemos ver un que los interfaces de red y de los discos son ‘virtio’:

00:03.0 Ethernet controller: Qumranet, Inc. Virtio network device
00:04.0 SCSI storage controller: Qumranet, Inc. Virtio block device


y nuestro disco duro aparecerá como ‘/dev/vda’ en vez de ‘/dev/sda’.

La diferencia es abismal. Si hacemos un ‘iperf’ en el guest en modo servidor:

# iperf -s


y otro en el host apuntando a la ip del guest:

# iperf -c 192.168.x.x -i2

Las tasas son superiores al gigabit, de host a guest y de gigabit de guest a guest (ojo, también depende de la calidad del servidor que estéis usando como host).

Y si los drivers virtio para un guest linux son muy importantes, para los guest windows, son vitales!. Sobre todo si se nos ha ocurrido la mala idea de virtualizar un sql server por ej y queremos que se menee.
Eso en el próximo post.

Ahora ya puedes hacer desde consola para que apague correctamente un:
# virsh shutdown guest

1- Primero hacemos un volcado del archivo xml de ese guest guardando ya el nuevo xml como queramos que se llame:
# virsh dumpxml winxp > windozer.xml

2- Editamos el nuevo xml y ponemos al principio en el tag el nuevo nombre.

3- Desgraciadamente tenemos que apagar la máquina. Así que ya podemos aprovechar para cambiar el nombre de host dentro del guest si también era necesario:
# virsh shutdown winxp

Una vez apagado el guest ya podemos cambiar el nombre del disco (normalmente está en /var/lib/libvirt/images/), en mi caso de winxp.img a windozer.img y editamos nuevamente el nuevo xml y cambiamos el nombre en el tag donde se defina ese disco.

4- Hacemos un undefine del nombre del guest antiguo para que lo borre de /etc/libvirt/qemu. Este ‘undefine’ no nos borrará el disco que acabamos de renombrar en /var/lib/libvirt/images/:
# virsh undefine winxp

5- Ahora hacemos un define de nuestro nuevo archivo xml para que lo coloque en /etc/libvirt/qemu:
# virsh define windozer.xml

6- Por último ya podemos arrancar el nuevo guest:
# virsh start windozer

En el cual comenta que la mas fiable para usar en mi caso sería la nueva fuente (de la 1.6.2 en adelante) res_timing_timerfd.
Para poder usarla debemos cumplir estos requisitos:
asterisk > 1.6.2
kernel > 2.6.27
glibc > 2.8

y comprobar que tememos el módulo cargado:
ompruebo que lo tengo cargado:

*CLI> module show like timing
Module
Description Use Count
res_timing_timerfd.so Timerfd Timing Interface 1
res_timing_dahdi.so DAHDI Timing Interface 0
res_timing_pthread.so pthread Timing Interface 0
3 modules loaded


Si no está cargado nos aseguramos que lo tenemos en /usr/lib/asterisk/modules
Pues bien, ahora tan solo tenemos que indicarle a asterisk que use el timing interno descomentando la siguiente línea en el archivo asterisk.conf:

internal_timing = yes