martes, 29 de septiembre de 2015

A servidor NFS muerto, servidor NFS puesto.

Gran problema la otra mañana, y es que el Servidor NFS quería dejar de estar con nosotros....
No es que estuviera muerto, sino más bien como en el chiste:

- ¡¡¡ Mamá, mamá¡¡ Papá se ha muerto encima de la criada.
- Pero, ¿está muerto ' del to'?
- No, .... Todavía 'colea un poquino'

 Pues eso, al parecer la fuente de alimentación no quería trabajar de forma continua y se apagaba el servidor de vez en cuando.
Como mientras no esté levantado el servidor lo se pueden logear los usuarios en los ordenadores de aulas y departamentos, ni obtener direcciones ip por dhcp, se paraliza el centro.
El proceso lógico según las instrucciones que tenemos sería, creo recordar restaurar imágen del servidor squeeze y pasarle un script para la migración a wheezy, pero me dió por probar el cambiar directamente los discos duros del servidor a otro equipo (cosa que sí me había funcionado en otro tipo de equipos). Quizá no estaría del todo optimizado, pero hacer el mínimo perjuicio sería lo más rápido.
Lógicamente guardamos copias de seguridad, pero al igual que con los discos duros, son archivos de instalación en otro equipo, por lo que la restauración desde las copias de seguridad plantearían los mismos problemas.

Si yo fuera una persona más capaz, como la mayoría de mis compañeros, montaría un servidor debian y añadiría los servicios y configuraciones, pero bastante que me da la cabeza para intercambiar discos....


Bueno proceso:


- Cojo el servidor de aula de la biblioteca que es el que menos perjuicio causará.
- Desconecto el disco duro del servidor nuevo, para cuando me llegue el repuesto del servidor NFS volver a dejar todo como estaba.
- Pincho los discos duros del antiguo servidor NFS al nuevo. En mi caso son dos, ya que al disco donde estaba todo(disco IDE), le añadí otro exclusivo para los home de los usuarios, ya así aumentaba espacio almacenamiento y velocidad ( es un WD rápido y SATA).
- Entro en bios del equipo y modifico la secuencia de arranque, Tengo que arrancar desde el disco IDE, pero éste no me aparece en la lista de dispositivos. marco el SATA y luego en el apartado de la bios de Discos Duros ya si que me aparece que está como primera opción el SATA, lo cambio por el IDE y de esta forma ya me aparece en el listado de secuencia de arranque.
- Arranco. En principio todo bien funciona todo perfecto.
- Problema: después de unas horas funcionando me empieza a escupir mensajes el syslog y termina bloqueándose con mensajes de problemas de kernel.
- Pruebo a iniciarlos desde otra entrada del grub con otro kernel diferente. La que está por defecto era con kernel 3.14. Pruebo con un kernel inferior, con el 3.2.
- Para que si hay un corte de corriente vuelva a arrancarme con este kernel, cambio la entrada por defecto en el grub, en /boot/grub.d/grub.cfg cambio "set default="0"" por "set default="2""

- De momento probando, pero con buena pinta......



lunes, 29 de junio de 2015

Backup completo de los servidores

Tal y como comentaba en la entrada de tareas de inicio de curso:

http://iesomatiasrmtnez.blogspot.com/2014/08/tareas-de-inicio-de-curso.html

a parte de las copias de seguridad incrementales que se hacen de manera automática en el servidorweb, suelo hacer una copia de seguridad completa de los siguientes servidores:

- Servidor LDAP
- Servidor NFS
- ServidorWeb

Para ello utilizo un script similar al que utilizo para las copias incrementales con el siguiente contenido:

#cat backupCompleto.sh 
DESTINO=/media/CopiaSeguridad/JUNIO2015 
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin 
install -d $DESTINO
install -d $DESTINO/servidor 
install -d $DESTINO/servidorweb 
install -d $DESTINO/ldap 
rsync --force --ignore-errors --delete --delete-excluded --excludefrom=/usr/local/bin/backup/servidor.excluded.completo 
                                --log-file=$DESTINO/completo.log -av root@servidor:/ $DESTINO/servidor/ $DESTINO/Error.log 
rsync --force --ignore-errors --delete --delete-excluded --excludefrom=/usr/local/bin/backup/servidorweb.excluded.completo                                 --log-file=$DESTINO/completo.log -av /  $DESTINO/servidorweb/ 2>$DESTINO/Error.log 
rsync --force --ignore-errors --delete --delete-excluded --exclude-from=/usr/local/bin/backup/ldap.excluded.completo 
                              --log-file=$DESTINO/completo.log -av root@ldap:/ $DESTINO/ldap/ 2>$DESTINO/Error.log

Lo que hace es lo siguiente:
- Establece el destino de la copia de seguridad en /media/CopiaSeguridad que es donde estará montado el disco duro donde realizo las copias.
- 4 órdenes install para crear el directorio raiz donde se guardarán las copias de seguridad del año y los tres directorios donde se almacenarán las copias, uno para servidor nfs, otro para ldap y otro para servidorweb
-3 órdenes rsync para cada una de las copias de seguridad.
Obsérvese que hay dos archivos de log para que quede constancia.
El primero completo.log donde se van a guardar la salida de ejecución de rsync y el otro Error.log donde se redireccionan los errores.

miércoles, 15 de abril de 2015

Cambiar sesión de inicio de gdm. Update-alternatives en Debian

En el artículo de Esteban Navas sobre update-alternatives en Debian, nos enseñaba las principales opciones de update-alternatives.
En este caso yo me quiero asegurar que por defecto todos los usuarios comiencen su sesión en gnome, a menos que ellos de forma intencionada elijan iniciar en otra sesión.
Si queremos ver qué alternativa está configurada por defecto lo podemos hacer con la opción --display :

root@servidorweb:/# update-alternatives --display x-session-manager
x-session-manager - modo manual
 el enlace apunta actualmente a /usr/bin/gnome-session
/usr/bin/gnome-session - prioridad 50
 esclavo x-session-manager.1.gz: /usr/share/man/man1/gnome-session.1.gz
/usr/bin/gnome-session-fallback - prioridad 100
 esclavo x-session-manager.1.gz: /usr/share/man/man1/gnome-session.1.gz
/usr/bin/startxfce4 - prioridad 50
 esclavo x-session-manager.1.gz: /usr/share/man/man1/startxfce4.1.gz
/usr/bin/xfce4-session - prioridad 40
 esclavo x-session-manager.1.gz: /usr/share/man/man1/xfce4-session.1.gz
Actualmente la «mejor» versión es `/usr/bin/gnome-session-fallback'.



Esto se hace con el siguiente comando: update-alternatives --config x-session-manager , que nos da como salida las diferentes opciones que hay y con un asterisco muestra cual es la predeterminada.
root@servidorweb:/# update-alternatives --config x-session-manager
Existen 4 opcioens para la alternativa x-session-manager (que provee /usr/bin/x-session-manager).

  Selección   Ruta                             Prioridad  Estado
------------------------------------------------------------
  0            /usr/bin/gnome-session-fallback   100       modo automático
  1            /usr/bin/gnome-session            50        modo manual
  2            /usr/bin/gnome-session-fallback   100       modo manual
  3            /usr/bin/startxfce4               50        modo manual
* 4            /usr/bin/xfce4-session            40        modo manual

Pulse <Intro> para mantener el valor por omisión [*] o pulse un número de selección:

Por defecto está el entorno XFCE, si queremos pasarla a gnome pulsaríamos 1 y le damos a enter.

El problema es que esta forma es interactiva, y por ello no podríamos meterlo en ningún script o en tarea puppet.
Esto lo podemos solucionar con la opción --set, que nos pone un valor determinado.
Así si ejecutamos:
update-alternatives --set x-session-manager /usr/bin/gnome-session
update-alternatives: utilizando /usr/bin/gnome-session para proveer /usr/bin/x-session-manager (x-session-manager) en modo manual
nos cambiaría la opción por defecto.









miércoles, 18 de marzo de 2015

Montaje de disco USB por nfs

Van a venir a hacer unas pruebas con esta idea:
Tienen una aplicación que funciona en linux para esta prueba. Los niños tendrían que utilizar esa aplicación para responder los que se les plantea.
Quieren que montemos un usb en una máquina de tal forma que la aplicación pueda escribir los resultados en dicho pendrive.
Tienen mucho interés en que no podamos copiar los archivos, por lo que quieren que se monte pero no que copiemos el contenido para compartirlo.

Por ello he utilizado el sistema de compartición por nfs que tenemos para montarlo, aunque en vez de montarlo en el servidor nfs voy a hacerlo en el servidorweb, un ltsp-server que tengo. Para ello la única operación previa es instalar nfs-kernel-server.

       1 . Enganchar el usb e identificar cual es el dispositivo:
root@servidorweb:~# ls /dev/sd*
/dev/sda   /dev/sda2  /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde
/dev/sda1  /dev/sda3  /dev/sdb1  /dev/sdc1  /dev/sdd1  /dev/sde1
en mi caso es el último, /dev/sde1.

     2. Crear un directorio donde vamos a montar el usb:

root@servidorweb:~# mkdir /mnt/clone

     3. Montar el usb con opciones escribible.

root@servidorweb:~# mount -o rw,defaults,umask=0000 /dev/sde1 /mnt/clone/

     4. Para compartir el directorio por nfs especificamos en /etc/exports con qué máquinas y qué directorios:
root@servidorweb:~# cat /etc/exports 
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/mnt/clone 172.XX.XX.X/255.255.255.0(rw,async)
en este caso digo que quiero compartir a todos los equipos del rango 172.XX.XX.X en modo escribible y asincrono. Con esto ya está finalizada la configuración del servidor. 
Ahora queda configuración en los clientes.
     5. En archivo /etc/master dice los ficheros en que tiene que mirar para montar directorios por nfs en arranque con autofs.
root@cliente:~# cat /etc/auto.master
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
#/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# "nosuid" and "nodev" options unless the "suid" and "dev"
# options are explicitly given.
#
#/net -hosts
#
# Include /etc/auto.master.d/*.autofs
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master
/homeInst /etc/auto.instituto

en nuestro caso dice que monte en /homeInst lo que le indica el archivo /etc/auto.instituto
     6. /etc/auto.instituto
root@cliente:~# cat /etc/auto.instituto
aulas -fstype=nfs,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 servidor:/home/aulas
personal -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,nobrowse,rsize=8192 servidor:/home/profesor/$USER
instituto -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,nobrowse,rsize=8192 servidor:/home/instituto
departamento  -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,nobrowse,rsize=8192 servidor:/home/profesor/dpto
prueba -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,nobrowse,rsize=8192 servidorweb:/mnt/clone
en nuestro caso ya tenía 4 carpetas para que se montaran: aulas, personal, instituto y departamento, yo añado la de prueba que le indica que la tiene que montar del servidorweb carpeta /mnt/clone.
Es decir la carpeta se montará en /homeInst/prueba
     7. La carpeta sólo se montará cuando intentemos acceder a ella, y lo podemos hacer de dos formas:
           a) Desde un terminal el usuario escribe :
                              usuario@cliente:~# nautilus /homeInst/prueba

           b) Creamos un script  y un lanzador que lo ejecute cuando pulsemos sobre el. En este caso añado el script /usr/bin/pruebaInst con el siguiente contenido:
root@jmmedinac03-hptablet:~# cat /usr/bin/pruebainst 
#!/bin/sh

esta=`ping servidorweb -c 1 -w 2 2>/dev/null |grep  "1 received"`
if [ "$esta" ]; then
cd /homeInst/prueba
nautilus /homeInst/prueba
else
 zenity --info \
--text "No está conectado a la red de su IES, por tanto los
directorios del instituto no se encuentran disponibles"
fi
Comprueba si está accesible el servidor web y abre la carpeta con nautilus. Si no está accesible muestra ventana con error.
     8. Crear el lanzador llamando al script.

viernes, 13 de marzo de 2015

Tarea Puppet para crear archivos de pkgsync en Workstations

Como ya sabemos, gestionamos los paquetes instalados en los sistemas mediante pkgsyn, puedes verlo en el siguiente post de Esteban Navas:
http://enavas.blogspot.com.es/2013/12/compartir-la-gestion-de-paquetes.html?m=0

He creado la siguiente tarea para adaptar los workstations a este sistema.
La tarea comprueba que esté instalado el paquete pkgsync y creadas sus carpetas correspondientes, cambia el script pkgsync por el modificado por Esteban Navas para la gestión compartida (.ies), y descarga y mantiene actualizados los ficheros musthave, mayhave y maynothave que nos ponen desde la Consejería y que no podemos modificar.


class   workstation-pkgsync {

package { "pkgsync-workstation-directorio":
name => pkgsync,
ensure => installed,
}

file { "pkgsync-workstation":
path => "/etc/pkgsync",
owner => root, group => root, ensure => directory,
require => Package["pkgsync"],
# before => File[["pkgsync-workstation"],["pkgsync_backup"],["musthave-workstation"],[mayhave-workstation],[maynothave-workstation]],
}

        file { "pkgsync-bin-workstation":
path => "/usr/sbin/pkgsync",
        owner => root, group => root, mode => 755,
        source => "puppet:///modules/workstation-pkgsync/pkgsync",
}
        file { "pkgsync_backup":
path => "/usr/sbin/pkgsync_BACKUP ",
        owner => root, group => root, mode => 644,
        source => "puppet:///modules/workstation-pkgsync/pkgsync_BACKUP",
}
        file { "musthave-workstation":
path => "/etc/pkgsync/musthave",
        owner => root, group => root, mode => 644,
        source => "puppet:///files/workstation-wheezy/musthave",
}

file { "mayhave-workstation":
path => "/etc/pkgsync/mayhave",
owner => root, group => root, mode => 644, 
source => "puppet:///files/workstation-wheezy/mayhave",
#require => File["pkgsync-workstation"],
       }

file { "maynothave-workstation":
path => "/etc/pkgsync/maynothave",
        owner => root, group => root, mode => 644,
source => "puppet:///files/workstation-wheezy/maynothave",
        #require => File["pkgsync-workstation"],
}

}


Tarea puppet para gestionar ficheros .ies de pkgsync

Como ya sabemos, gestionamos los paquetes instalados en los sistemas mediante pkgsyn, puedes verlo en el siguiente post de Esteban Navas:
http://enavas.blogspot.com.es/2013/12/compartir-la-gestion-de-paquetes.html?m=0

La siguiente tarea es para que los diferentes equipos creen y mantengan actualizados los ficheros .ies de pkgsync.
La tarea, establece los nombres de las variables mayhaveIes, musthaveIes y maynothaveIes según el tipo de equipo donde se esté ejecutando la tarea. Esa es la ruta donde deben estar colocados los archivos dentro del servidor puppet. Así el mayhave.ies para un workstation lo tendré creado en la carpeta /etc/puppet/files(..../lo que pone en $mayhave) /workstation-wheezy/mayhave.ies
Lo único que hay que hacer antes de pasar la tarea es crear los tres ficheros de cada tipos de equipo en su ruta correspondiente.
El contenido del manifests/init.pp es el siguiente:

class   comunes-pkgsync-ies {

case $use {
       "portatil-profesor-wheezy": {   $mayhaveIes="miniportatil-wheezy/mayhave.ies.profesor"
$musthaveIes="miniportatil-wheezy/musthave.ies.profesor"
$maynothaveIes="miniportatil-wheezy/maynothave.ies.profesor"
}
       "portatil-alumno-wheezy": {   $mayhaveIes="miniportatil-wheezy/mayhave.ies.alumno"
$musthaveIes="miniportatil-wheezy/musthave.ies.alumno" 
$maynothaveIes="miniportatil-wheezy/maynothave.ies.alumno"
}
       "workstation-wheezy": { $mayhaveIes="workstation-wheezy/mayhave.ies" 
$musthaveIes="workstation-wheezy/musthave.ies" 
$maynothaveIes="workstation-wheezy/maynothave.ies"
}
       "ltsp-wheezy": { $mayhaveIes="ltsp-wheezy/mayhave.ltsp-wheezy.ies" 
$musthaveIes="ltsp-wheezy/musthave.ltsp-wheezy.ies" 
$maynothaveIes="ltsp-wheezy/maynothave.ltsp-wheezy.ies" 
}

#        default: { }

       }

file { "mayhave.instituto":
path => "/etc/pkgsync/mayhave.ies",
owner => root, group => root, mode => 644, 
source => "puppet:///files/$mayhaveIes",
       }

file { "maynothave.instituto":
path => "/etc/pkgsync/maynothave.ies",
        owner => root, group => root, mode => 644,
source => "puppet:///files/$maynothaveIes",
}

file { "musthave.instituto":
path => "/etc/pkgsync/musthave.ies",
        owner => root, group => root, mode => 644,
source => "puppet:///files/$musthaveIes",
}

}

Script para añadir paquetes a ficheros de Pkgsync

Para mantener los paquetes deseados en los equipos usamos Pkgsync. Se gestiona con tres ficheros uno donde introducimos los paquetes que deben estar obligatoriamente, otro los que se permite que estén y otro los que no deben estar, así cuando el sistema se actualiza mediante pkgsync  instalará los necesarios, desinstalará los que no deben estar y dejará instalados aquellos que sí pueden estar.
Por otro parte estamos usando una modificación de Esteban Navas para compartir esos ficheros de manera que por cada uno tenemos tres: el que nos ponen desde la Consejería, otro el que ponemos nosotros(.ies) y con esos dos se forma el tercero y definitivo(.all) que es el que pkgsync utilizará.
Puedes verlo en el siguiente enlace de Esteban Navas:

http://enavas.blogspot.com.es/2013/12/compartir-la-gestion-de-paquetes.html?m=0

Así como tenemos diferentes equipos en el centro: miniportátiles(para alumnos y profesores), LTSP-Servers y Workstations  tenemos que gestionar esos tres archivos, los .ies que son los que podemos gestionar desde el centro, para cada uno de los tipos de equipo.
Ya los hemos colocado en los equipos con una tarea puppet :
 https://www.blogger.com/blogger.g?blogID=2361837138647093212#editor/target=post;postID=5095385512043461757;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=1;src=postname
Así si quiero introducir un paquete para que se instale en todos los equipos tendría que ir añadiéndolo uno a uno a los cuatro archivos musthave correspondientes, cada uno en una ruta distínta..
Para facilitar esto he creado un script, un tanto burdo, pero que me permite añadir estos ficheros, los llamo diciendo que fichero quiero modifica: mayhave, musthave o maynothave y si lo quiero añadir a todos los equipos o sólo a Workstation, LTSP o miniportátil.

#!/bin/bash
#como parámetro se pasa el archivo a introducir dentro de musthave
if ([ $# -ne 3 ] || ([ "$1" != "-y" ] && [ "$1" != "-s" ] && [ "$1" != "-t" ])|| ([ "$2" != "-a" ] && [ "$2" != "-w" ] && [ "$2" != "-l" ] && [ "$2" != "-m" ])); then

echo "Parámetros insuficientes o incorrectos "
        echo "escriba anadeAPkgsync [-y (para mayhave.ies)|-t (para maynothave.ies)|-s (para musthave.ies)] -[a(para todos)|w(para workstations)|-l(para ltsps)|m para miniportátiles nombre_de_paquete"
        exit 0
else

        if ([ "$2" = "-a" ]  ||  [ "$2" = "-l" ]); then
#añadimos en ltsp
                if [ "$1" = "-y" ]; then
#añadimos a mayhave de ltsp
echo "$3" >> /etc/puppet/files/ltsp-wheezy/mayhave.ltsp-wheezy.ies
echo "$3 añadido a mayhave.ltsp-wheezy.ies"
                 else
                        if [ "$1" = "-s" ]; then
#añadirmos a musthave
echo "$3" >> /etc/puppet/files/ltsp-wheezy/musthave.ltsp-wheezy.ies
echo "$3 añadido a musthave.ltsp-wheezy.ies"
                        else
#añadimos a maynothave
echo "$3" >> /etc/puppet/files/ltsp-wheezy/maynothave.ltsp-wheezy.ies
echo "$3 añadido a maynothave.ltsp-wheezy.ies"
fi
fi
fi
if ([ "$2" = "-a" ]  ||  [ "$2" = "-w" ]); then
                #añadimos a workstation
       if [ "$1" = "-y" ]; then
#añadimos a mayhave
echo "$3" >> /etc/puppet/files/workstation-wheezy/mayhave.ies
echo "$3 añadido a mayhave.ies de workstation"
                else
                        if [ "$1" = "-s" ]; then
#añadirmos a musthave
echo "$3" >> /etc/puppet/files/workstation-wheezy/musthave.ies
echo "$3 añadido a musthave.ies de workstation"
                        else
#añadimos a maynothave
echo "$3" >> /etc/puppet/files/workstation-wheezy/maynothave.ies
echo "$3 añadido a maynothave.ies de workstation"
fi
fi
fi
if ([ "$2" = "-a" ]  ||  [ "$2" = "-m" ]); then
                #añadimos a miniportatiles
       if [ "$1" = "-y" ]; then
#añadimos a mayhave
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/mayhave.ies.alumno
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/mayhave.ies.profesor
echo "$3 añadido a mayhave.ies de portatil de alumno y de profesor"
                else
                        if [ "$1" = "-s" ]; then
#añadirmos a musthave
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/musthave.ies.alumno
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/musthave.ies.profesor
echo "$3 añadido a musthave de portatil alumno y profesor"
                        else
#añadimos a maynothave
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/maynothave.ies.alumno
echo "$3" >> /etc/puppet/files/miniportatil-wheezy/maynothave.ies.profesor
echo "$3 añadidoa maynothave de alumnos y profesores"
fi
fi

        fi

fi

lunes, 23 de febrero de 2015

Recuperar sectores defectuosos de Disco Duro

Tengo algunos discos que me dan errores de E/S.
Quiero ver si se pueden recuperar o no, por lo tanto he buscado y encontrado el siguiente artículo:
http://blog.desdelinux.net/reparar-sectores-recuperar-hdd-linux/

Básicamente ver cual es la unidad, en mi caso sde.
root@servidorweb:~$ badblocks -s -v -n -f /dev/sde
 esto nos encuentra y repara sectores defectuosos.

Luego podemos hacer reparación de sistema de archivos:

root@servidorweb:~$ e2fsck -p -v -y /dev/sde1

lunes, 9 de febrero de 2015

Error "lpadmin: Tubería rota" al añadir impresora.

Tengo una tarea puppet con la cual añado las impresoras a los equipos.
Hoy me ha dado el siguiente error al ejecutarse: "lpadmin: Tubería rota".
En la siguiente página he encontrado la solución:

https://forum.zentyal.org/index.php?topic=21853.0


y tal como dice es suficiente con comentar en el archivo /etc/cups/cupsd.conf la línea:

 #Listen /var/run/cups/cups.sock


martes, 20 de enero de 2015

Virtualización de máquinas en Servidor de Aula con KVM

Necesitamos crear una máquina virtual con otro sistema operativo para correr un determinado programa de otra plataforma.
Como hemos probado con VirtualBox y no va bien, me han dejado la tarea de probar con KVM que al no ser emulador y correr sobre el propio kernel parece que va mejor.

Inicialmente tiré del siguiente tutorial:

Aunque después me he servido de la siguiente presentación, bastante completa donde se va indicando todo.
http://www.gonzalonazareno.org/cloud/material/KVM.pdf

Y ésta también es una muy buena guía, de la cual he sacado la mejora de tarjeta gráfica y aceleración 2D y 3D.
http://www.makeinstall.es/2011/04/virtualizar-con-la-maquina-virtual-del.html

He comprobado que el procesador con el que vienen equipados los servidores de aula, intel i3, viene con la tecnología intel-vt, tan sólo es necesario activarla en la bios, si no está activada.
La he podido habilitar entrando en la bios y  en la pestaña que pone Advanced, allí menú CPU CONFIGURATIÓN  (en otro ordenador, me la he encontrado en  Overclocking dentro de ella vamos a CPU FEATURES )  y una vez allí ponemos la opción Intel Virtaulization Tech a enable.

Ya después de arrancar el sistema podemos ver si ha arrancado correctamente los módulos:

root@servidorweb:/# lsmod|grep kvm
kvm_intel             138825  0 
kvm                   404853  1 kvm_intel
root@servidorweb:/# 

Instalamos paquetes kvm:

root@a09-pro:~# apt-get install qemu-kvm libvirt-bin bridge-utils

 y después paquetes para aplicaciones auxiliares:

apt-get install virtinst virt-manager ubuntu-vmbuilder
virt-viewer

entre ellas virt-manager que nos va a ofrecer una interfaz gráfica para poder gestionar nuestras máquinas virtuales.

Para poder utilizar las máquinas virtuales el usuario debe pertenecer a los grupos: libvirtd y kvm.
En nuestro sistema, como los usuarios los tenemos en ldap, tenemos dos opciones:
1.- Añadirlos en el archivo de grupos: /etc/groups. Añado usuario en esos dos grupos después de los dos puntos. El sistema ya se encarga de meter mi usuario en esos grupos.

  GNU nano 2.2.6            Fichero: /etc/group                    Modificado  

clamav:x:129:
firebird:x:128:
kvm:x:130:usuario
libvirt:x:131:usuario
libvirt-qemu:x:132:libvirt-qemu
vde2-net:x:133:

2.- Creamos en ldap un nuevo grupo en la rama Groups y le añadimos los usuarios que deseemos.

Como de estas dos formas, me he encontrado, no sé el motivo, con problemas de autentificación de los usuarios, he decidido crear un usuario local con :

useradd  -D -m -d /homeInst/prueba -g kvm,libirt -p prueba prueba

Con este comando crea tanto usuario como su home, le mete la contraseña indicada y también lo mete dentro de los grupos que necesitamos.
Y luego lo añadimos como miembro de los grupos libvirt y kvm en el caso de que no se haya añadido al crearlo.

Creamos y definimos el pool de almacenamiento tal y como indica en la página 41 del pdf.
root@a09-pro:~# nano /tmp/pool-default.xml 

 GNU nano 2.2.6                   Fichero: /tmp/pool-default.xml                                              

<pool type='dir'>
<name>default</name>
<target>
<path>/var/lib/libvirt/images</path>
</target>
</pool>

root@a09-pro:~# virsh pool-autostart default
Pool default marked as autostarted

root@a09-pro:~# virsh pool-list --all
Name                 State      Autostart 
-----------------------------------------
default              inactive   yes       

root@a09-pro:~# virsh pool-start default
Pool default started

root@a09-pro:~# virsh pool-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes       

root@a09-pro:~# 


Idem con la red en página 44:

root@a09-pro:~# virsh net-start default
Network default started

root@a09-pro:~# virsh net-autostart default
Network default marked as autostarted

root@a09-pro:~# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes       

root@a09-pro:~#


Ya hemos finalizado con la instalación del software necesario, ya sólo nos quedaría crear las máquinas virtuales que necesitemos.

Lo podemos realizar mediante el comando virt-install  o directamente en modo gráfico desde virt-manager. Yo he utilizado esta forma que es más intuitiva.

Abrimos virt-manager y pulsamos el icono de máquina virtual nueva.
Ponemos nombre  y en Medio de instalación local le ponemos la dirección del ISO con la imagen del SO que queremos instalar, tipo de SO, memoria, procesadores, etc... (todo esto lo podremos modificar más adelante) y dejamos que comience y finalice la instalación.
La máquina virtual nos crea una imagen del disco duro virtual que crea(archivo .img), lo almacena en /var/lib/libvirt/images/   y por otra parte nos guarda la configuración de la máquina virtual (procesadores, memoria, gráfica, etc...) en el directorio /etc/libvirt/qemu/ un archivo xml por máquina virtual creada.
Como en mi caso queremos la máquina para trabajar con un programa de diseño gráfico y es muy importante que funcione muy bien la gráfica y tenga aceleración, se lo ponemos a mano directamente en este archivo xml en la etiqueta de video, cambiando vga por vmvga, aumentando la vram y poniendo la aceleración:
.    <video>
      <model type='vmvga' vram='131072' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
      <acceleration accel2d='yes' accel3d='yes'/>
    </video>
Ya por último, y como lo que estoy utilizando es un cliente windows, queríamos que todo funcionara lo mejor posible y habíamos leído que virtio mejoraba la fluídez, para eso añadimos un nuevo cdrom con la iso de virtio, desde Editar/Detalles de la máquina virtual con la máquina virtual seleccionada, y en información (símbolo de la bombilla) añadir nuevo hardware.


Para ello desde el administrador de dispositivos de Windows le dimos a actualizar controlador de tarjeta de red, bus pci, etc... y también los dispositivos no reconocidos, indicándole instalar desde el cdrom  o disco duro que hemos añadido.

Creo que ya poco más, la verdad es que el resultado es impresionante, y parece funcionar más rápido que una máquina real....
¿Cuál es el secreto?

lunes, 12 de enero de 2015

whatsapp en pc con pidgin

Necesitamos tener whatsapp en el instituto para hacer llegar comunicaciones por este medio.
Me puse a ver en internet y encontré que es posible hacerlo siguiendo las indicaciones de, entre otras, la siguiente página:

http://blog.desdelinux.net/como-usar-whatsapp-en-linux-con-pidgin/

más a la hora de solicitar la contraseña con yowsup, me encontre que daba error ya que la versión ha cambiado.
Después de entrar en la página del proyecto:

https://github.com/tgalal/yowsup/wiki/yowsup-cli-2.0

vi que ha cambiado un poco la filosofía del script yowsup-cli y en vez de solicitar dicho registro con la órden que indica el tutorial:

./yowsup-cli -c whatsapp_config.txt --requestcode sms

ahora se realiza en dos pasos, tal y como indica la documentación de yowsup-cli:

yowsup-cli registration --requestcode sms --phone 49XXXXXXXX --cc 49 --mcc 123 --mnc 456
yowsup-cli registration --register 123456 --phone 49XXXXXXXX --cc 49
en donde cc y mcc son los códigos de país y operadora que se pueden encontrar en el siguiente enlace de la wikipedia:
https://en.wikipedia.org/wiki/Mobile_country_code#National_operators

Ya nos da el siguiente resultado:

jmmedi-hpt yowsup # ./yowsup-cli registration --requestcode sms --phone 34XXXXXX --cc 34 --mcc 214 --mnc 03
INFO:yowsup.common.http.warequest:{"status":"sent","length":6,"method":"sms","retry_after":1805}

status: sent
retry_after: 1805
length: 6
method: sms
jmmedina-hpt yowsup # ./yowsup-cli registration --register 115-070 --phone 34XXXXXXX  --cc 34
INFO:yowsup.common.http.warequest:{"status":"ok","login":"34XXXXXXX","pw":"RoqW8JhFo4laFi2tdR3fIvxFxeE=","type":"existing","expiration":1448664009,"kind":"free","price":"0,89 \u20ac","cost":"0.89","currency":"EUR","price_expiration":1423994449}

status: ok
kind: free
pw: RoqW8JhFo4laFi2tdheE=
price: 0,89 €
price_expiration: 1423994449
currency: EUR
cost: 0.89
expiration: 1448664009
login: 346ÇXXXXXXX
type: existing
jmmedinac03-hpt yowsup # 

Si queremos tener un archivo con la configuración podemos hacer los siguiente:

 yowsup # ./yowsup-cli demos --help-config > whatsapp-config.txt

############# Yowsup Configuration Sample ###########
#
# ====================
# The file contains info about your WhatsApp account. This is used during registration and login.
# You can define or override all fields in the command line args as well.
#
# Country code. See http://www.ipipi.com/help/telephone-country-codes.htm. This is now required.
cc=49
#
# Your full phone number including the country code you defined in 'cc', without preceding '+' or '00'
phone=491234567890
#
# You obtain this password when you register using Yowsup.
password=NDkxNTIyNTI1NjAyMkBzLndoYXRzYXBwLm5ldA==
#######################################################

y cambiamos los campos cc, phone y password por nuestros datos.

Si queremos más información sobre las opciones de yowsup-cli, en este caso demos, lo podemos ver con:

yowsup # ./yowsup-cli demos -h
usage: demos [-h] [-v] [-d] [--help-config] [-l phone:b64password | -c CONFIG]
             [-m] [-y] [-e] [-s phone message]

Run a yowsup demo

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         Print version info and exit
  -d, --debug           Show debug messages
  --help-config         Prints a config file sample

Configuration options for demos:
  -l phone:b64password, --login phone:b64password
                        WhatsApp login credentials, in the format
                        phonenumber:password, where password is base64
                        encoded.
  -c CONFIG, --config CONFIG
                        Path to config file containing authentication info.
                        For more info about config format use --help-config
  -m, --moxie           Enable experimental support for the new WhatsApp
                        encryption

Command line interface demo:
  -y, --yowsup          Start the Yowsup command line client

Echo client demo:
  -e, --echo            Start the Yowsup Echo client

Send client demo:
  -s phone message, --send phone message
                        Send a message to specified phone number, wait for
                        server receipt and exit


Y ya como indica el tuturial, abrir pidgin y crear una cuenta nueva de whatsapp con login número de teléfono(346XXXXXX) y password el código recibido como pw:.........

Probado y funcionando.