Migración servidor munin de 64b a 32b, problemas con ficheros rrd

Hola a todos de nuevo, buenos díasfoto de Eloy Mier Pérez

En este articulo vamos a echar un vistazo a munin (http://munin-monitoring.org/). Para aquellos que no lo conozcan munin es una aplicación que permite monitorizar máquinas en la red. Para ello munin se compone de 2 componentes completamente diferenciados, que son el nodo munin y el server. Para que una máquina pueda ser monitorizada por el server se requiere en esa máquina la instalación del software de nodo y además se requiere que el servidor la tenga agregada al fichero de configuración y que por supuesto el server pueda conectar con el nodo en el puerto definido (instalación por defecto 4949).

Como una imagen vale mas que mil palabras aquí tenéis un par de pantallazos para el server munin corriendo:

En esta imagen podéis apreciar la página de nivel superior generada por el servidor a partir de la información recopilada de los nodos:

Como podéis apreciar en la imagen superior, en mi red, y dentro de la plataforma de monitorización se encuentran 4 máquinas:

  • acerX3900 es un servidor vmware y antiguo servidor munin (64b)
  • odisea es la máquina de mi mujer un simple ordenador de escritorio (32b)
  • princesa es mi máquina personal, ordenador de escritorio (64b)
  • ubuntueeebox es el nuevo servidor munin (32b).

Si selecciono ubuntueeebox para ver los gráficos que obtiene el server podremos apreciar algo similar a:

Y si pincho en un gráfico para ver el detalle, lo que obtengo es el gráfico de días + semanas + meses + año:

Para obtener la información que se ha mostrado en los gráficos anteriores, munin-node, hace uso de una serie de scripts en el nodo. Si esos scripts (pluggins) están habilitados y son capaces de obtener la información que se supone que deben obtener entonces el server recibe dicha información y la pinta. Si por el contrario desactivamos el pluggin, el server simplemente no pinta el gráfico asociados. En el caso de que el pluggin este habilitado y no sea capaz de obtener la información necesaria, el servidor simplemente pinta el gráfico vacío. Un caso típico por ejemplo de esta última casuística es el siguiente: en el nodo tenemos habilitado el pluggin de monitorización de HD pero no tenemos instaladas las herramientas de bajo nivel necesarias (smartmoontools) y por lo tanto el nodo munin no es capaz de enviar al servidor información de monitorización de los discos.

Hoy vamos a tratar un tema cuanto menos curioso, que es la migración de un servidor munin de arquitectura 64b a arquitectura 32b. Inicialmente cuanto me plantee el cambio de servidor para munin, la verdad, es que no pensaba que requeriría ningún proceso especial para realizarla. Una vez montado munin server en la nueva máquina, con el servicio corriendo y los ficheros de datos(rrd) instalados resulta que viendo que no actualiza dichos ficheros me paso por el log (/var/log/munin) del server y veo un mensaje similar a:

El fichero no ha podido ser actualizado por que procede de otra arquitectura distinta a la actual. El mensaje exacto es

This RRD was created on another architecture

Bien, parece ser que los ficheros rrd que usa el servidor munin son dependientes de la arquitectura de la máquina, no tenia ni idea. Así que me puse a investigar un poco sobre cómo poder portar los ficheros existentes, mas que nada por no perder la información histórica de las máquinas.

Finalmente di con la solución, el proceso que debemos seguir es:

  1. Exportación en el servidor 64b de los ficheros rrd a xml usando la herramienta rrdtool dump.
  2. Copia de los ficheros exportados (xml) a la máquina con la nueva arquitectura, en mi caso ubuntueeebox, que es el nuevo servidor munin.
  3. Importación de los ficheros xml a ficheros rrd pero en arquitectura 32b. Uso de la herramienta rrdtool restore.
  4. Copia de los nuevos ficheros rrd en el directorio de datos munin (en mi caso /var/lib/munin/casamier)
  5. Ahora ya podemos arrancar de nuevo el servidor de munin, no deberíamos recibir mas errores de arquitectura.

Bien, puesto que en el servidor tengo bastantes ficheros rrd y la herramienta rrdtool no acepta un comodín, pues no queda mas remedio que hacer un par de scripts para la exportación e importación. Los scripts que he escrito son muuuuy simples, no reciben parámetros y deben ser ejecutados desde el directorio que contiene los rrd y los xml.

Script para el paso numero 1 (exportacion a xml) en el servidor origen:

eloy@ubuntueeebox:~/casamier$ cat exportarRRD
#!/bin/bash
for file in $( ls *.rrd ); #recorremos solo los ficheros rrd
do
orig=$file
dest=$(echo $file | sed -e “s/.rrd/.xml/”)
rrdtool dump $orig $dest
done
exit 0

Script para el paso número 3 (importación a rrd) en el servidor destino:

eloy@ubuntueeebox:~/casamier$ cat importarRRD
#!/bin/bash
for file in $( ls *.xml ); #recorremos solo los ficheros xml
do
orig=$file
dest=$(echo $file | sed -e “s/.xml/.rrd/”)
rrdtool restore -r -f $orig $dest
done
exit 0

Bueno, pues hasta aquí la historieta de hoy. Para un proximo articulo, a ver si puedo mostraros la configuración del server y de los nodos.  Espero que tengáis buen día todos. Saludos y hasta la próxima.

Simplificando las reinstalaciones

Eloy Mier 02Es muy habitual para mi hacer una reinstalación del sistema operativo cada 6 meses mas o menos (ahora estoy un poco zángano pero bueno). Los principales motivos son dos, la reinstalación limpia todo el sistema y requiere de mi únicamente 10 minutos delante del PC . Notad que he dicho “delante del PC”, la máquina hace todo el trabajo por mi mediante unos scripts “artesanales” especiales de bash.

Si alguna vez necesitases reinstalar tu sistema Linux, lo mejor que puedes hacer ahora mismo son unos cuantos deberes. Escribete tranquilamente unos scripts de bash que te automaticen la mayor parte del trabajo. Esta es la unica manera de que no tengas que perder demasiado tiempo delante del PC durante las reinstalaciones. A menudo comienzo el proceso de instalación, me voy a ver una película, después corro algunos guiones bash cuando el instalador ha acabado y me piro a comer mientras el script hace el trabajo por mi. Nunca hago loggin en xorg hasta que todos los scripts han terminado. Simplemente inicio sesión en el terminal1(tty1), ejecuto el script de sistema y me largo con la película.

Yo mantengo la mayor parte de los paquetes, documentos, etc., en un segundo disco duro pero estos elementos podrían almacenarse en una unidad de cd/dvd, simplemente debiéramos montar el volumen en el script de sistema y permitir que el propio script guarde los elementos seleccionados en ese punto de montaje.

Script de sistema

El script de sistema debe contener únicamente comandos que modifiquen las preferencias del mismo y los contenidos. Notaras que estos scripts no contienen ningún comando apt-get . La razón es que creo que el superusuario debe estar presente y echar un ojo en cualquier instalación/eliminación de software que se realiza en la máquina para poder solventar cualquier problema que pueda surgir. Por supuesto, que el lector puede hacer lo que le de la gana en sus máquinas.

unix
Ten presente que este script es solo un ejemplo para mostrar que parte del trabajo necesario puede ser automatizado y asi evitar estar sentados delante de la máquina demasiado tiempo. Mi script de sistema es algo mas detallado que el que a continuación se muestra, edítalo y aplialo a tu antojo.

#!/bin/bash

# verificación de los premisos necesarios para ejecución del script
if [ $UID != 0 ]
then
exit
fi

# hace copia de seguridad de los ficheros de sistema por si las moscas
mkdir /etc/master_copies
cp /boot/grub/menu.lst /etc/fstab /etc/apt/sources.list /etc/sudoers /etc/X11/xorg.conf /etc/master_copies

# creacion de directorios necesarios
mkdir /mnt/sdb1 /mnt/iso

# Montar los sistemas de ficheros necesarios
mount /dev/sdb1 /mnt/sdb1

# Hacer modificaciones en los ficheros necesarias
cat /mnt/sdb1/system-files/fstab-entries >> /etc/fstab

# comentar el agente ssh agent en Xsession.options
sed 's/use-ssh-agent/# use-ssh-agent/g' /etc/X11/Xsession.options

# añadir lista de repositorios adicionales
cat /mnt/sdb1/system-files/sources.list >> /etc/apt/sources.list

# Instalacion de los temas para su uso global en el sistema
dpkg -i /mnt/sdb1/packages/my-theme.deb /mnt/sdb1/packages/my-icons.deb
cp /mnt/sdb1/graphics/wallpapers/* /usr/share/backgrounds

# Limpiar el sistema
apt-get clean
updatedb

#hecho
exit

Y esto es todo para el script de sistema. Cuando vuelvo de comer, el sistema debe estar listo para ejecutar los comandos apt-get necesarios. En este momento puedo verificar la lista de software a ser instalado, comenzando la instalación y dejando al sistema hacer su trabajo.

Hacer el backup de los ficheros importante es un paso FUNDAMENTAL. Seria incapaz de contar las veces que este paso me ha salvado el “trasero” después de editar incorrectamente el fichero xorg.conf. Todavía no entiendo como las instalaciones de Linux en sus distintas distribuciones no incluyen un paso tan importante como este en sus instalaciones, este tipo de procesos podrían ahorrar muchísimo tiempo y frustración al nuevo usuario de Linux. Recuperar el fichero perdido sources.list es tan sencillo como montar el sistema de ficheros con un LiveCD y copiar el fichero desde master_copies a su ubicación original.

Script de usuario

Este script solo debe contener comandos que modifican preferencias y contenidos en $HOME. De nuevo, este script es solo un ejemplo para mostrarte que parte del trabajo puede automatizarse para evitar que estes sentado delante del PC como un tonto durante horas. Mi script de usuario es mas detallado que el que aqui se muestra, edítalo y amplíalo como te interese a tu caso.

#!/bin/bash

# Asegurarnos de que estamos en $HOME
cd $HOME

# hacer copias de seguridad de los ficheros importantes. Tantas lineas como sean necesarias
mkdir .master_copies
cp algunos-ficheros .master_copies

# Copiar los ficheros necesarios a $HOME
mkdir -p Documents
cp -r /mnt/sdb1/office-files/* Documents
cp -r /mnt/sdb1/settings/GNUstep .

# Crear los enlaces simbolicos necesarios
ln -s /dev/null .adobe
ln -s /dev/null .macromedia

# instalar los temas
tar -xzf /mnt/sdb1/packages/infinity-theme.tar.gz .themes
tar -xzf /mnt/sdb1/packages/infinity-icons.tar.gz .icons
tar -xzf /mnt/sdb1/packages/myfonts.tar.gz .fonts

# hacer los ajustes de sistema que nos de la gana
gconftool-2 --type string --set /apps/metacity/general/theme "Infinity"
gconftool-2 --type string --set /desktop/gnome/interface/gtk_theme "Infinity"
gconftool-2 --type string --set /desktop/gnome/interface/font_name "MyFont 12"
gconftool-2 --type bool --set /apps/nautilus/desktop/home_icon_visible true
gconftool-2 --type bool --set /apps/nautilus/preferences/always_use_location_entry true
gconftool-2 --type integer --set /apps/panel/toplevels/bottom_panel_screen0/size 24
gconftool-2 --type integer --set /apps/panel/toplevels/top_panel_screen0/size 24

# hecho
exit

Y esto es todo para el script de usuario. La reinstalación del sistema esta completada y ajustada a mis gustos y puedo hacer un reinicio del mismo. Una vez realizado el reinicio, el sistema esta listo para usar por mi y he gastado un total de 10 minutos enfrente del PC gracias a los scripts.

El comando gconftool-2 es muy útil aquí y puede ayudar mucho a establecer las preferencias del sistema para ajustarlas a tus necesidades.

Saludos a tod@s y hasta la próxima.

Montar sistemas de ficheros NFS

Hola a todos.ubuntu
redhat01 icon
Hoy me he visto en la necesidad de montar un sistema de ficheros de red y voy a documentar los pasos necesarios de forma general para todo aquel que lo necesite.
Para el montaje se necesita en el sistema el paquete nfs-common. Así que lo instalamos sin mas problema con:

sudo aptitude install nfs-common

root@ubuntuEEEBox:/var/lib/vmware/VirtualMachines# aptitude install nfs-common
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes… Hecho
Se instalarán los siguiente paquetes NUEVOS:
libevent1{a} libgssglue1{a} libnfsidmap2{a} librpcsecgss3{a} nfs-common portmap{a}
0 paquetes actualizados, 6 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 351kB de ficheros. Después de desempaquetar se usarán 1171kB.
¿Quiere continuar? [Y/n/?]
Escribiendo información de estado extendido… Hecho
Des:1 http://es.archive.ubuntu.com intrepid/main portmap 6.0-6ubuntu1 [36,2kB]
Des:2 http://es.archive.ubuntu.com intrepid/main libevent1 1.3e-3 [44,7kB]
Des:3 http://es.archive.ubuntu.com intrepid/main libgssglue1 0.1-2 [22,3kB]
Des:4 http://es.archive.ubuntu.com intrepid/main libnfsidmap2 0.20-1 [23,2kB]
Des:5 http://es.archive.ubuntu.com intrepid/main librpcsecgss3 0.18-1 [32,4kB]
Des:6 http://es.archive.ubuntu.com intrepid-updates/main nfs-common 1:1.1.2-4ubuntu1.1 [192kB]
Descargados 351kB en 1s (234kB/s).
Preconfigurando paquetes …
Seleccionando el paquete portmap previamente no seleccionado.
(Leyendo la base de datos …
167883 ficheros y directorios instalados actualmente.)
Desempaquetando portmap (de …/portmap_6.0-6ubuntu1_i386.deb) …
Seleccionando el paquete libevent1 previamente no seleccionado.
Desempaquetando libevent1 (de …/libevent1_1.3e-3_i386.deb) …
Seleccionando el paquete libgssglue1 previamente no seleccionado.
Desempaquetando libgssglue1 (de …/libgssglue1_0.1-2_i386.deb) …
Seleccionando el paquete libnfsidmap2 previamente no seleccionado.
Desempaquetando libnfsidmap2 (de …/libnfsidmap2_0.20-1_i386.deb) …
Seleccionando el paquete librpcsecgss3 previamente no seleccionado.
Desempaquetando librpcsecgss3 (de …/librpcsecgss3_0.18-1_i386.deb) …
Seleccionando el paquete nfs-common previamente no seleccionado.
Desempaquetando nfs-common (de …/nfs-common_1%3a1.1.2-4ubuntu1.1_i386.deb) …
Procesando activadores para man-db …
Configurando portmap (6.0-6ubuntu1) …
* Starting portmap daemon…                                                                                                                              [ OK ]

Configurando libevent1 (1.3e-3) …

Configurando libgssglue1 (0.1-2) …

Configurando libnfsidmap2 (0.20-1) …

Configurando librpcsecgss3 (0.18-1) …

Configurando nfs-common (1:1.1.2-4ubuntu1.1) …

Creating config file /etc/idmapd.conf with new version

Creating config file /etc/default/nfs-common with new version
Añadiendo usuario del sistema `statd’ (UID 119) …
Agregando nuevo usuario `statd’ (UID 119) con grupo `nogroup’ …
No se crea el directorio de inicio ‘/var/lib/nfs’.
* Starting NFS common utilities                                                                                                                           [ OK ]

Procesando activadores para libc6 …
ldconfig deferred processing now taking place
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes… Hecho
Escribiendo información de estado extendido… Hecho

Para el montaje del sistema de ficheros NFS usaremos el comando mount desde la máquina en la que lo queremos montar. Doy por supuesto que teneis otra máquina en la que el sistema de ficheros esta disponible, tal y como es mi caso.

mount naslocal01.local:/isos /mnt/naslocal01/isos
Warning Aviso
El punto de montaje de la máquina local DEBE existir previamente al montaje (en este caso /mnt/naslocal01/isos)

En el comando que acabamos de indicar, naslocal01.local es el nombre de la máquina que tiene el sistema de ficheros NFS, /isos es el sistema de ficheros que naslocal01 exporta y por ultimo /mnt/naslocal01/isos es la ubicación en mi máquina local donde quiero montar el sistema de ficheros remoto. Después de que el comando mount ha sido ejecutado (y el cliente tiene los permisos adecuados en el servidor naslocal01) el usuario puede lanzar sin problema el comando ls /mnt/naslocal01/isos para ver la lista de ficheros de /isos de naslocal01.

Montando sistemas de ficheros NFS usando /etc/fstab

Después de realizar con éxito el paso anterior, para mi es interesante que el sistema monte automáticamente el sistema de ficheros NFS en la ubicación indicada, asi que tendremos que usar como siempre el /etc/fstab y agregar la linea correspondiente. Esta linea debe indicar el nombre del servidor NFS, el directorio que el servidor esta exportando y el directorio en la máquina local en la que queremos que se monte. No olvidemos que para modificar el fichero /etc/fstab debemos ser root.

La linea agregada es:

naslocal01.local:/isos    /mnt/naslocal01/isos   nfs    rsize=8192,wsize=8192,timeo=14,intr    0     0

El punto de montaje /mnt/naslocal01/isos, como ya hemos comentado con anterioridad, debe existir en la máquina cliente. Después de añadir la linea al fichero /etc/fstab en la máquina cliente, lanzando el comando mount /mnt/naslocal01/isos en el shell de sistema veremos que monta sin problemas /isos desde el servidor.

root@ubuntuEEEBox:/var/lib/vmware/VirtualMachines# mount /mnt/naslocal01/isos/
root@ubuntuEEEBox:/var/lib/vmware/VirtualMachines# mount
/dev/mapper/vg1-lv_sistema on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
lrm on /lib/modules/2.6.27-14-generic/volatile type tmpfs (rw,mode=755)
/dev/mapper/vg1-lv_home on /home type ext3 (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/sdc1 on /var/lib/vmware/VirtualMachines type ext3 (rw,_netdev)
naslocal01.local:/isos on /mnt/naslocal01/isos type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,addr=192.168.2.20)

Montando sistemas de ficheros NFS usando autofs (teórico por que no uso esta funcionalidad)

Una tercera opcion para el montaje de un sistema de ficheros NFS es usar autofs. Autofs usa el demonio auto automount para gestionar los puntos de montaje dinamicamente en el moento en el que se accede a ellos.

Autofs consulta el fichero /etc/auto.master para determinar los puntos de montaje definidos. En este momento Autofs lanza un proceso automount con los parámetros apropiados para cada punto de montaje. Cada una de las lineas del fichero define un punto de montaje y un fichero externo (map) que define el sistema de ficheros para montar por debajo de ese punto. Por ejemplo, el fichero /etc/auto.misc deberia definir un punto de montaje en el directorio /mnt/naslocal01/isos; esta relacion será definida en el fichero maestro /etc/auto.master.

Cada entrada en el fichero auto.master tiene tres campos. El primero de ellos es el punto de montaje. El segundo de los campos es la localizacion del fichero de descripcion del sistema de ficheros a montart. El tercero de los campos es opcional y contiene las opciones que queramos asociar al montaje.

Por ejemplo , para montar el directorio /isos de la máquina naslocal01.local en el punto de montaje /mnt/naslocal01/isos en nuestra máquina, deberiamos añadir la siguiente linea a nuestro fichero auto.master:

/mnt/naslocal01   /etc/auto.misc --timeout 60

Debemos añadir la linea al fichero mapeo /etc/auto.misc:

isos  -rw,soft,intr,rsize=8192,wsize=8192   naslocal01.local:/isos

El primero de los campos en el fichero /etc/auto.misc es el nombre del subdirectorio en /mnt/naslocal01. Este directorio será creado automaticamante por automount. El directorio no debe existir ya en la máquina cliente. El segundo de los campos contiene las opciones de montaje como ejemplo rw para permitir lectura/escritura a los usuarios. El tercero de los campos es la declaracion de la exportacion NFS que incluye nombre de host y directorio.

Note Nota
El directorio /mnt/naslocal01 debe existir en el sistema de ficheros del cliente.

Autofs es un servicio. Para levantar el servicio en el shell podemos escribir:

/etc/init.d/autofs restart

Para ver los puntos de montaje actuales:

/etc/init.d/autofs status

Como siempre, si modificamos el fichero de configuración /etc/auto.master mientras autofs está corriendo, debemos decirle al demonio de automount que lo recargue con:

/etc/init.d/autofs reload

Pues nada mas señores, hasta aqui hemos llegado por hoy.
Solo como comentario, la ultima perte de automount no la he probado, pues es un servicio que no tengo instalado en mi máquina, así que con cautela.

¿Como añadir la papelera de reciclaje en el escritorio de Ubuntu?

Hola a todosubuntu

Esta cuestión se me ha planteado en un montón de ocasiones. Información en Internet hay mucha sobre el asunto pero muy dispersa para aquellos que comienzan con este fantástico sistema operativo.

Bien, para poder tener la papelera de reciclaje en el escritorio de Ubuntu, la cosa es muy sencilla. Debemos abrir una aplicación llamada gconf-editor.

Una vez abierta en el entorno gráfico tenemos que irnos a la siguiente ruta usando el arbol que se puede ver en la parte izquierda de la ventana: / -> apps -> natilus -> desktop.

Aquí os muestro un pantallazo de la aplicación en la rama indicada:

gconf-edit01

Ahora simplemente tenemos que seleccionar en el panel de la derecha aquellos elementos que queremos hacer visibles en el escritorio, en el caso que nos ocupa trash_icon_visible.

Después de la selección, simplemente cerramos la ventana de la aplicación y deberíamos poder ver el icono seleccionado en el escritorio.

Saludos a todos.

Configuración Logitech dinovo Media Desktop en Ubuntu 8.10

Hola a todos de nuevo, hoy voy a comentar en este articulo cómo instalar el teclado Logitech Dinovo Media Desktop en Ubuntu 8.10.

Después de unos días de búsquedas por internet, al final he logrado por lo menos que el teclado sea operativo en el arranque del sistema. Hay que decir que el teclado es operativo según lo instalas el problema es que según Ubuntu arranca, parece que no consigue activar la red BT con el teclado.

En la configuración que muestro en el articulo se consigue que el teclado responda correctamente excepto el botón de “media” y la rueda de control, que de momento no hacen nada, creo que el resto de elementos son operativos, y lo que es mas importante desde mi punto de vista, segun arranca el sistema cuando tocamos el primero de los botones del teclado, automáticamente monta la red quedando operativo de forma instantanea y eliminando la necesidad de desconectar y volver a conectar el hub Bluetooth proporcionado con el teclado.

Bien, los ficheros que debemos modificar para que funcionen los distintos componentes del teclado son:

  • /etc/default/bluetooth
  • /etc/bluetooth/hcid.conf

El fichero bluetooh es el fichero general de sistema para el servicio, en el que se indica que BT va a estar activado en el arranque y en que modo lo hará. El contenido de mi fichero es el siguiente:

# Defaults for bluez

# start bluetooth on boot?
# compatibility note: If this variable is not found bluetooth will
# start
BLUETOOTH_ENABLED=1

# This setting will switch HID devices (e.g mouse/keyboad) to HCI mode, that is
# you will have bluetooth functionality from your dongle instead of only HID.
# Note that not every bluetooth dongle is capable of switching back to HID
# mode, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355497
HID2HCI_ENABLED=0      # !!!!! 1 here then keyboard is not able to connect at startup
HID2HCI_UNDO=0

HIDD_ENABLED=1
HIDD_OPTIONS=”–master –connect 00:07:61:D7:0D:58 –connect 00:07:61:D6:E9:7C –connect 00:07:61:D7:0E:44 –server”

Es muy importante el valor HID2HCI_ENABLED=0,que por defecto en el sistema se encontraba con el valor 1. Con el valor 1 el teclado no conecta en el arranque correctamente, haciendose necesario la reconexion del hub usb. Con el valor 0 el teclado se comporta de la forma deseada.

El fichero hcid.conf es el encargado del registro de los dispositivos disponibles mediante BT en el sistema. El contenido de mi fichero es el siguiente:

#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none – Security manager disabled
# auto – Use local PIN for incoming connections
# user – Always ask user for a PIN
#
security auto;

# Pairing mode
# none – Pairing disabled
# multi – Allow pairing with already paired devices
# once – Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey “1234″;
}

# Default settings for HCI devices
device {
# Local device name
# %d – device id
# %h – host name
name “%h-%d”;

# Local device class
class 0×000100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;
discovto 0;

# Default link mode
# none – no specific policy
# accept – always accept incoming connections
# master – become master on incoming connections,
# deny role switch on outgoing connections
lm accept;
# Default link policy
# none – no specific policy
# rswitch – allow role switch
# hold – allow hold mode
# sniff – allow sniff mode
# park – allow park mode
lp rswitch,hold,sniff,park;
}

device 00:07:61:D7:0D:58 {
name “Logitech diNovo Keyboard”;
auth enable;
encrypt enable;
}

device 00:07:61:D6:E9:7C {
name “Logitech Mediapad”;
auth enable;
encrypt enable;
}

device 00:07:61:D7:0E:44 {
name “Logitech Mx1000 Laser”;
}

Como podeis ver, cada uno de los elementos que componen el teclado, se encuentra perfectamente dado de alta en el fichero.
Como detalle en este teclado, la direccion de cada componente la podeis encontrar en la parte posterior del mismo.

Bueno, aqui dejo una foto del teclado funcionando con Ubuntu 8.10.

Logitech dinovo media desktop con Ubuntu 8.10

Entre la fuentes de información que me han ayudado destacan:

Saludos a todos y hasta la próxima.