WOL no funciona en ubuntu 10.04 LTS tras realizar la suspensión

septiembre 19, 2011 Deja un comentario

Hacía tiempo que no me encontraba con un problema difícil de resolver en Linux. Resulta que tenemos un bug reconocido por el cual la función Wake On LAN dejará de funcionar tras la primera suspensión / hibernación del equipo. Es decir, que puedes suspender y reiniciar la máquina mediante WOL una única vez; las sucesivas será imposible. Y como es de costumbre, google te muestra miles de resultados con gente que configura el WOL sin problemas, pero nadie que se encuentre en mi misma tesitura.

Investigando un poco me he encontrado con varios enlaces que sugerían diversas soluciones, ninguna de las cuales me ha servido. Sin embargo, si me han dado una pista de por donde empezar. El directorio /etc/pm/sleep.d/ contiene scripts que se ejecutan al suspender y restaurar el sistema, llevando a cabo las acciones necesarias, de forma parecida a los de System V. Además, en /usr/lib/pm/sleep.d/ hay otros tantos definidos que se también se ejecutan.

Ya puestos en situación, resulta que he descubierto (mediante el conocidísimo método informático ensayo-error) que es necesario “resetear” las interfaces de red para que funcione de forma adecuada el WOL, además de habilitarlo, pues se deshabilita en cada suspensión / apagado. Esto lo hago con el siguiente script que me he creado, y que he colocado en /etc/pm/sleep.d/10_wol:

#!/bin/bash

IFACE=eth0

resetif() {
 ifconfig $IFACE down
 ifconfig $IFACE up
 ethtool -s eth0 wol g
}

case "${1}" in
 suspend|hibernate)
 resetif
 ;;
 resume|thaw)
 resetif
 dhclient $IFACE
 ;;
esac

El inconveniente es que este script entra en conflicto con /usr/lib/pm/sleep.d/55NetworkManager; el susodicho para y restaura el NetworkManager de Ubuntu. Así que he borrado éste último para evitar que falle.

Por cierto, que también es necesario habilitar WOL tras reiniciar la máquina. Para ello basta con crear un script que lo haga en cada automáticamente, /etc/init.d/wol:

#!/bin/bash 
# 
# Enables Wake On LAN 

ethtool -s eth0 wol g 

Y habilitarlo para que se ejecute en cada inicio:

# update-rc.d wol defaults 

Y con esto ya tenemos nuestro Wake On LAN funcional.

Anuncios
Categorías:Informática Etiquetas: ,

ISOs híbridas

junio 17, 2011 Deja un comentario

Hace tiempo que no escribo aquí, pero es cuestión de que para noticias cortas estoy utilizando twitter. Pero no he abandonado el blog XD.

El tema que abordo hoy es de las isos híbridas; un formato de isos que se está popularizando últimamente en muchas de las distribuciones linux: supergrub lo usa, easy peasy también lo hace, igual que openSUSE, y ubuntu lo hará a partir de la versión 10.10.

Hace tiempo que me picaba la curiosidad por saber “cómo” se construyen estas ISOs híbridas para poder ser grabadas directamente en un pendrive. Investigando un poco, he descubierto una explicación bastante buena (aunque breve) en la wiki de easypeasy: el truco consiste en sustituir los primeros 512 bytes de la imagen, que en el formato ISO deben de ser ceros, por el “sector de arranque”  (MBR), lo que permite grabar la iso directamente en el pendrive (mediante dd) y poder arrancar el sistema.

Obviamente esto tiene dos consecuencias lógicas: que el sistema de ficheros que se graba en el pendrive es iso9660, que es de sólo lectura, y que, por tanto, para arrancar necesitamos que el cargador sea capaz de montar este sistema de ficheros (grub2 lo hace).

Categorías:Informática Etiquetas:

La importancia del login seguro (SSL-TLS)

marzo 23, 2011 4 comentarios

La seguridad informática es un tema apasionante y complejo, a la vez que descuidado en demasiadas ocasiones. A este respecto, algo que me preocupa en las aplicaciones web que utilizo / desarrollo es el envío de usuarios y contraseñas en texto plano a través de la red. Es una práctica bastante común, que puede comprometer fácilmente la seguridad de nuestro sistema.

 

SSL o TSL nos permite cifrar la conexión con el servidor de forma que todo el intercambio de datos vaya cifrado. Es la opción más segura porque protege todo el flujo de datos. No obstante, el tema que a mí me preocupa es simplemente la transmisión en plano del par usuario / contraseña; suficiente en las aplicaciones en las que la información que se transmite no es altamente confidencial. Por tanto, en estas ocasiones, se puede utilizar ssl únicamente para dicha operación, dejando el resto de la sesión libre de cifrado, y así no cargar al cliente ni al servidor innecesariamente. Es por ejemplo el caso de Facebook, que únicamente cifra dicho envío (aunque también permite el uso completo de la aplicación sobre ssl). Gmail, sin embargo, utiliza por defecto ssl desde que accedes al formulario de login.

Me suena haber visto algún día de pasada un complemento para Firefox que te advertía de los logins que utilizan ssl y los que no, a modo de protección contra este issue. El caso es que con la salida de Firefox 4.0, y aprovechando un rato de tiempo libre que he tenido esta tarde, me he puesto a buscar dicho complemento, pero lo único que he encontrado han sido complementos que fuerzan el uso de ssl cuando está disponible (por ejemplo, forzarían facebook siempre sobre ssl). Lo más parecido a lo que buscaba que he encontrado, ha sido Secure or Not, que te permite identificar con un simple click de ratón los enlaces y formularios seguros (usan ssl) de la página en la que te encuentres. Desde luego, lo recomiendo 100%. Quizás otra tarde que tenga tiempo me dedique a desarrollar un complemento para firefox que haga lo que yo deseo…

Como anécdota, cabe decir que se ha refrescado mi interés por el tema, dado que actualmente me encuentro trabajando en un centro de eduación que utiliza Moodle como plataforma de enseñanza y, como era de esperar, no utilizan ssl en los logins. Pero este problema de seguridad se ve aún más agravado con el hecho de que existe una red wifi abierta, sin ningún tipo de protección, que permite a cualquiera que se siente en un banco en la puerta del centro obtener de manera gratuita cientos de contraseñas. Lo más triste de todo es que advertí a la dirección sobre este problema hace meses, y no lo han solucionado. Y peor aún, mi alumnos ya conocen este fallo, pues hemos visto ssl en clase y han sido lo bastante inteligentes como para atar cabos…

Categorías:Informática Etiquetas: ,

CentOS 5.5 detectando discos sata como /dev/hda

febrero 12, 2011 1 comentario


En un post anterior escribía sobre cómo cargar CentOS con Ubuntu instalado en la máquina, ya que con el grub 2 no era capaz de cargar el CentOS; y ya he descubierto el porqué. Era muy sutíl el error y no había sido capaz de descubrirlo. Consistía en que CentOS estaba denominando /dev/hda al disco sata, que en Ubuntu es /dev/sda, por lo que en la directiva root del grub erróneamente ubuntu establecía root=/dev/sdax, mientras que CentOS ese dispositivo no existía, por lo que habría que ponerle root=/dev/hdax.

De todas formas, aunque ya sepa la solución a ese problema, no voy a volver a tenerlo, porque el que CentOS detecte los discos sata como /dev/hda tiene efectos colaterales. Yo ya había notado que CentOS iba muy lento, arrancando y funcionando, pero no había relacionado conceptos. El caso es que haciendo benchmarks con de discos para evaluar el rendimiento de Xen, detecté que la lectura / escritura era unas 10 veces más lenta de lo normal. Googleando encontré este HowTo en el que se explicaba que el problema de que el acceso a disco fuese muy lento era debido a que el DMA estaba desactivado. Los discos SATA no utilizan DMA, pero intuí que CentOS estaba detectando erróneamente los discos, probablemente debido a las características de emulación IDE de la placa base. Sólo tuve que buscar un poco más para encontrar la solución.

Para evitar que CentOS detecte erróneamente los discos SATA como PATA, sólo hay que pasarle al kernel el parámetro hda=noprobe para que haga correctamente la detección. También hay que indicarle que la partición raíz ahora es un sda y no un hda y, por último, actualizar el fichero /etc/fstab para cambiar los hda por sda. La línea en grub sería algo así:

module /boot/vmlinuz-2.6.18-8.1.4.el5xen ro root=/dev/sda2 hda=noprobe

Además, así evito el problema que tenía con que el grub 2 no cargaba CentOS, pues ya he detectado que el kernel panic estaba causado por culpa de que la línea de grub de Ubuntu ponía el root=/dev/sda2, mientras que CentOS esperaba root=/dev/hda2.

Fuente: http://www.linuxquestions.org/questions/linux-hardware-18/sda-drive-seen-as-hda-on-centos5-609483/

Categorías:Informática

Montar imagen de disco Xen

febrero 3, 2011 2 comentarios

Hoy me he encontrado con que no podía montar el disco virtual de uno de mis dominios virtualizados con Xen. Estoy acostumbrado a utilizar ficheros mapeados a los dispositivos de loop, pero hasta ahora los había utilizado directamente para formatearlos con un sistema de ficheros. El problema es que para el dominio Xen, ese fichero actúa como disco y, por tanto, le introduce la tabla de particiones al inicio, y dentro de las particiones crea los sistemas de ficheros.

Por ejemplo, en el caso de estar tratando con el disco /dev/sda, si directamente formateamos el disco como ext3 con

mkfs.ext3 /dev/sda

podríamos montarlo mediante

mount -t ext3 /dev/sda /mnt

Sin embargo, si tiene una tabla de particiones, el sistema de ficheros lo crearíamos, por ejemplo en la partición 1, con

mkfs.ext3 /dev/sda1

y lo montaríamos mediante:

mount -t ext3 /dev/sda1 /mnt

El problema con asociar un fichero a un dispositivo de loop es que cuando creas una tabla de particiones sobre /dev/loop0, no se crea de forma automática el /dev/loop0p1, sino que hay que hacerlo a mano. Para ello, debemos usar la herramienta kpartx:

kpartx -a -v disco_virtual.img

Con esto se nos habrá creado el dispositivo que nos da acceso a la partición en /dev/mapper/loop0p1, con lo cual ya podemos formatearlo y montarlo tranquilamente:

mkfs.ext3 /dev/mapper/loop0p1
mount -t ext3 /dev/mapper/loop0p1 /mnt

Me ha servido un poco de ayuda lo siguiente: Pasar de xen a kvm

Categorías:Informática Etiquetas: , , ,

Firefox se congela en Linux en el EeePc 901

enero 21, 2011 2 comentarios

Llevaba tiempo sufriendo este molesto problema; y es que firefox se congelaba durante unos segundos cada cierto tiempo. Hoy por fin he sacado un ratito para ponerme a investigar y he resuelto el problema.

Parece ser que firefox 3 usa sqlite y realiza constantemente fsync para mantener actualizada su base de datos en disco. Esto provoca que se congele en el eeepc, debido a que los discos SSD que lleva tienen ciertos problemas con las escrituras constantes de pocos datos.

El autor del post donde se analiza dicho problema, sugiere en este otro post crear una partición para firefox, pero yo he optado por utilizar un disco de ram, y así me ahorro el estar modificando las particiones. La idea es mantener en disco el directorio de firefox, llevarlo a ram para trabajar con él, y volver a volcarlo al disco cuando finalicemos.

Para ello, lo primero es añadir el punto de montaje del disco de ram al fichero /etc/fstab

none /mnt/ramdisk tmpfs defaults,size=200m 0 0

Si quieremos montar ya mismo el disco de ram, basta con ejecutar mount -a

A continuación, cambio el nombre del directorio de firefox por “firefoxram”, que será el que sirva de respaldo en disco.

mv /home/user/.mozilla/firefox /home/user/.mozilla/firefoxram

Ahora enlazo el directorio que realmente utiliza firefox con el disco de ram

ln -s /mnt/ramdisk /home/user/.mozilla/firefox

Tal y como está ahora mismo el sistema, cuando firefox se abra, creará su directorio en ram con los datos de navegación del usuario, pero al apagar el sistema, estos se perderán (porque sólo están en ram). Es por eso que necesitamos el directorio de respaldo en disco. Su finalidad es que se copie a ram antes de abrir firefox, y se vuelque a disco al cerrarlo. Para ello, vamos a cambiar el ejecutable /usr/bin/firefox por un script que realice dichas tareas:

mv /usr/bin/firefox /usr/bin/firefox-bin
touch /usr/bin/firefox
chmod +x /usr/bin/firefox

Ahora, editamos el script /usr/bin/firefox y añadimos las siguientes lineas:

#!/bin/bash

cp -r $HOME/.mozilla/firefoxram/* $HOME/.mozilla/firefox
firefox-bin
cp -r $HOME/.mozilla/firefox/* $HOME/.mozilla/firefoxram/

E voilá. Adiós a los cuelgues de firefox.

Categorías:Informática Etiquetas: , , ,

CentOS 5.5 y Ubuntu 10.10 dual boot

enero 15, 2011 2 comentarios

Tras varios intentos infructíferos de instalar CentOS por red (faltaban paquetes en el servidor), grabé la imagen del dvd en un disco e instalé a la antigua (advertencia: no cabe en un pendrive de 4GB). El problema es que la máquina en la que lo he instalado necesitaba también arrancar con Ubuntu 10.10, el cual ya estaba instalado. Y llegaron mis dolores de cabeza.

Mi primera idea fue no instalar gestor de arranque para CentOS, y utilizar el grub de Ubuntu en su lugar; así que hice un update-grub, y me detectó automáticamente la partición con CentOS. El problema fue que al arrancar, me daba el siguiente error

Error: Invalid magic number

Bastó un poco de investigación para comprobar que el error venía de que el núcleo que estoy instalando es para paravirtualización con Xen, y grub no sabe cómo arrancar este tipo de núcleos. Así que modifico la entrada del grub y pongo lo siguiente


multiboot /boot/xen.gz-2.6.18-194.el5
module 	  /boot/vmlinuz-2.6.18-194.el5xen root=/dev/hda6 ro quiet
moduel 	  /boot/initrd-2.6.18-194.el5xen.img

Pues sigue sin funcionar. Ahora me da el siguiente error:

PANIC on CPU0:
Could not setup DOM0 guest OS
Reboot in five seconds...

Parece ser que a CentOS no le caigo bien. Pero por mis c*j**es que lo hago funcionar. La siguiente opción que me queda es instalar el grub que trae CentOS en su partición de arranque y pasarle el control desde el grub de Ubuntu.


insmod ext2
chainload (hd0,6)+1

¡Bingo! Problema resuelto. Sólo me queda la espinita clavada de no saber por qué el grub 2 de Ubuntu no es capaz de arrancar CentOS.

¡¡¡ACTUALIZACIÓN!!!

 

¡Ya he descubierto el problema del Kernel Panic! Menos mal, porque odio no poder encontrar explicación de algún problema, cuando todos tienen la suya. El kernel panic estaba causado por culpa de que la línea de grub de Ubuntu ponía el root=/dev/sda2, mientras que CentOS esperaba root=/dev/hda2. Lo explico todo en este post.

Categorías:Informática Etiquetas: , , ,