Un Grub maestro, varios Esclavos

A raíz de la entrada “Un solo Grub para todos tus Linux” del magnífico blog de FORAT, en el que explica cómo crear entradas a mano en GRUB cuando instalas varios sistemas operativos y quieres mantener el GRUB original, voy a permitirme por una vez estar en desacuerdo con él y poner por escrito aquí mi forma de hacerlo, que creo que es un poco más sencilla ;)

Y para ello voy a poner el ejemplo de Windows XP.

Cuando tenemos instalado Linux y XP en una misma máquina, lo que tenemos en el MBR es el gestor de arranque GRUB, y dentro de éste una entrada con título como por ejemplo “XP”. Si editamos esa entrada ( pulsando “e” ) desde GRUB, vemos estas líneas:

root (hd0,0)

chainloader +1

makeactive

Estas líneas lo que hacen es pasarle el control al gestor de arranque del XP, que en vez de estar en el MBR está en la partición 1, de ahí el (hd0,0).

Pues eso mismo lo podemos hacer para linux. Pongámonos en un escenario típico:

• 1ª partición hda1 –> Windows XP ( Con su gestor de arranque en la partición hda1
• 2ª partición hda2 –> Linux Ubuntu ( Con su gestor de arranque GRUB en el MBR, ya que es nuestro sistema operativo principal )
• 3ª partición hda3 –> Instalaremos Debian Lenny que acaba de salir como estable y queremos probarla.

Lo que haríamos sería iniciar la instalación de Debian Lenny normalmente, y cuando nos pregunte dónde instalar el gestor de arranque GRUB le decimos que en vez de en el MBR lo haga en la misma partición dónde instalamos Debian, es decir en hda3.

Al reiniciar, cuando nos salga el GRUB vemos que sólo nos aparecen las entradas del XP y de Ubuntu. Iniciamos Ubuntu, y como root editamos el fichero /boot/grub/menu.lst , y abajo de todo tendremos algo así:

title Ubuntu jaunty (development branch), kernel 2.6.28-8-generic
root (hd0,1)
kernel /boot/vmlinuz-2.6.28-8-generic root=UUID=09dd0c85-868a-457f-a25c-0f20c1707f28 ro splash vga=794
initrd /boot/initrd.img-2.6.28-8-generic
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This entry automatically added by the Debian installer for a non-linux OS
title Microsoft Windows XP Professional
root (hd0,0)
savedefault
makeactive
chainloader +1

Pues justo debajo de la entra para Windows XP creamos una nueva para nuestra Debian:

title Debian Lenny

root (hd0,2)

chainloader +1

makeactive

Guardamos, y al reiniciar y cargar el GRUB del MBR que es el de Ubuntu, nos saldrán tres entradas

• Ubuntu
• Windows XP
• Debian Lenny

Si pulsamos Debian Lenny lo que hace es cargarnos el GRUB de Debian de la partición hda3, pinchamos en el kernel por defecto y listo.

Yo le veo 2 ventajas a este método:

1. Podemos instalar varios Sistemas Operativos, teniendo el GRUB del que más nos guste en el MBR, y a través de éste cargamos los GRUB de los otros Sistemas Operativos.
2. No nos tenemos que preocupar por las actualizaciones. Si sale un nuevo kernel debian y nos actualiza el GRUB no pasa nada, nos lo hace bien. De la otra forma, tendriamos que volver a editar el menu.lst con el nuevo kernel.

Aunque todo es mejorable por supuesto. Acepto sugerencias y críticas. Criticar, criticar …

Nota: Cuando me refiero a (hd0,0) hd0 se refiere al disco 1, y 0 a la particion 1. Por eso cuando instalamos Debian Lenny en hda3, en grub es (hd0,2) hd0 –> disco 1, 2 –> partición 3).

Openvz Bug Nfs

Hace un par de meses se me pidió exportar un directorio de un servidor de ficheros a un EV ( máquina virtual de openvz ) por nfs.

Lo primero que hice fué mirar en la wiki de openvz si estaba implementado, y qué pasos había que seguir.

Como podéis comprobar los pasos son sencillos, bien explicados, pero a mi no me funcionaba. Hacía todo bien, no me daba error, pero no me cargaba el sistema de ficheros nfs en el EV.

Para saber los sistemas de ficheros que soporta tu EV lo puedes ver dentro del EV editando el fichero /proc/filesystems

Al final abrí un hilo en el foro de openvz ( no os riáis de mi inglés ), y ahí dimos con un bug.

Resulta que con el kernel que estaba utilizando ( Linux openvz1 2.6.26-1-openvz-686 ) no era posible cargar el sistema de ficheros nfs en el EV, por lo que tuve que bajarme el kernel estable de openvz para que funcionase.

El problema con el kernel estable es que es un poco antiguo, y en mi caso en un Dell PowerEdge T100 no me detecta una de las dos tarjetas de red, por lo que ahora me queda por conprobar si desde hace dos meses se corrigió este bug con los nuevos kernels.

Ya os contaré.

Error en Placa Asus P5Q Deluxe + Intel Q9300

 

Hace poco renové mi ordenador de casa, ya que el anterior que tenía  se me quedaba pequeño para juga … para trabajar.

Me decanté por montármelo yo mismo por piezas porque tengo una amiga que es proveedora de hardware.

Me decanté entre otras cosas por:

• Placa base Asus P5Q Deluxe
• Micro Intel Core2Quad Q9300

El problema surgió al querer instalar xp. Resulta que hay una incompatibilidad entre estos 2 componentes que hace que la instalación de windows se bloquee, o si llega a instalarse, que aparezcan pantallazos azules a tutiplén.

Mirando en foros vi que había remedios complicadísimos que probaba la gente, y a unos les funcionaba y a otros no.

Al final tuve suerte, porque una semana después de estar peleándome con el pc, asus sacó una actualización de la bios que resolvía este problema.

La actualización es la versión 1406, aunque a día de hoy hay una nueva, la 1702.

Actualizar la bios en esta placa es un proceso sumamente fácil, y es dónde vemos que se trata de una placa decente y que vale la pena invertir un poco más de dinero en ciertas cosas que nos hacen la vida más fácil.

No necesitamos disquetera para nada. Entrando en la propia bios hay un apartado específico para flashearla, que nos introduce en una especie de entorno ms-dos, y lo más increíble es que nos detecta el pendrive, por lo que sólo tenemos que elegir el firm de la bios en el pendrive y flasssssh.

Bueno, y rezar para que no se vaya la luz durante el proceso, claro ;)

Al final del proceso reiniciamos y ya podemos instalar xp sin ningún tipo de problema.

Tengo que decir, y no es por presumir …, bueno en  realidad sí es por presumir, que xp en este equipo va de lujo.

Me queda pendiente instalar vista 64 para aprovechar los 4GB Ram, y Ubuntu 64.

Ya os contaré.

Etiquetas de Technorati: Software,Hardware

Ordenador muy muy rápido

- rinnnnnnng
acort: si?
boss: mira, que no tengo red.
boss: yo creo que es porque encendí el ordenador demasiado rápido!
acort: ?
boss: sabes a qué me refiero no?
acort: eeeh, claro claro.
boss: y eso que es vista, conoces el vista no?
acort: si si
boss: bueno y qué hago? no tengo red
acort: ( encender el ordenador más despacio? ) Pues lo mismo que le dije ayer, no conectar a la vez a la red por cable y por wifi, porque su ordenador se queda bloqueado.
boss: qué complicados sois los informáticos!

Si, es que somos muuuuuy complicados.

Recordatorio I

No usar ettercap en el firewall en producción.
Y si lo haces busca una buena excusa para cuando tus usuarios llamen diciendo que no tienen internet.

Hay que cargárselos

Hace unos días en mi empresa, en la cafetería, intentando no mancharme con la napolitana y el café, se me acerca un jefazo a darme conversación, dejando un razonamiento bestial antes de largarse por dónde había venido:

- Que el paro está aumentando. Qúe va a aumentar. El problema es que la mayoría de esos parados son obreros, gente sin preparación académica. A esos, a esos ... a esos había que eliminarlos y punto. Así ya no habría tanto paro.

Si amigos, trabajo con gente así.

Correspondencia Legal en ThePirateBay

Si eres tan friki como yo (no va por ti scirius, tu lo eres de otro tipo), entiendes un poco el inglés escrito, y tienes tiempo libre, pásate por http://thepiratebay.org/legal y lee las amenazas legales que han recibido por parte de discográficas y empresas de entretenimiento, y sus correspondientes respuestas a éstas.

Un ejemplo de una respuesta a Prophecy House:

We don't have the same laws here.
You know, in Sweden, it's still legal to do a lot of things.
Elks can have sex with eachother without being prosecuted
for instance. And people are allowed to copy.
It's quite natural, both of them, don't you think?

Eso es humor friki en estado puro.

OpenVZ en Ubuntu Hardy

Aprovechando el nuevo equipo de Empresa tuve que migrar los EV ( entornos virtuales ) del viejo equipo al nuevo, y estuve pensando en postearlo, pero como lo de la migración a secas es una gilipollez, pues voy a postear la instalación y configuración de OpenVZ y un EV ( Entorno Virtual ) que será Debian Etch.

OpenVZ según la wikipedia es una tecnología de virtualización en el nivel de sistema operativo basada en el núcleo y sistema operativo Linux.
OpenVZ permite que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos como Servidores Privados Virtuales (SPV) o Entornos Virtuales (EV). Más info aquí.

Objetivo: Instalación de OpenVZ y un EV Debian Etch

Escenario: Ubuntu Hardy. En debian acaba de portarse a lenny, pero hardy lo tenía más a mano. De todas formas, los EV pueden migrarse fácilmente si después se quiere integrar en Lenny.

Pasos:

- Instalar el último núcleo de OpenVZ y sus utilidades:
aptitude install linux-image-2.6.24-19-openvz vzctl vzquota

- Reiniciar y arrancar con el núcleo de OpenVZ

- Tenemos que hacer unos cambios en el fichero /etc/sysctl.conf, entre otras cosas para que haga forward y nuestros EV tengan red:
net.ipv4.ip_forward=1
Guardamos y ejecutamos este comando para que se apliquen los cambios:
sysctl -p

- Instalación del EV Debian Etch a través de una plantilla:
Podéis encontrar plantillas de varias distribuciones linux aquí:
Nosotros bajamos debian-4.0-amd64-minimal.tar.gz y la copiamos en /var/lib/vz/templates/cache
Yo bajé debian para amd64 porque mi ubuntu es de 64bits, si utilizáis ubuntu de 32bits, bajar debian-4.0-i386-minimal.tar.gz

Ahora vamos a crear el EV. Cada EV se identifica por un Id que le asignamos al crearlo.
Por defecto, la máquina anfitriona es el Id 0. Además OpenVZ se reserva los Ids del 0 al 100 para cuestiones internas ( actualizaciones, etc ) por lo que empezaremos asignando Ids a nuestros EV a partir del 101.
Para la creación de un EV, y asignación de recursos, cuotas, etc ( mirar man ) se usa el comando vzctl.

Creamos el EV Debian Etch con el Id 101 a partir de la plantilla
debian-4.0-amd64-minimal:
vzctl create 101 --ostemplate debian-4.0-amd64-minimal

- Configuracion del EV:

* Que se inicie en el arranque:
vzctl set 101 --onboot yes --save

* Parámetros de Red:
vzctl set 101 --hostname nombre.del.host --save
vzctl set 101 --ipadd le.damos.una.ip --save
vzctl set 101 --nameserver ip.del.dns --save

* Especificar clave de root para el EV:
vzctl set 101 --userpasswd root:pass

- Operaciones Básicas con el EV:

* Arrancar el EV:
vzctl start 101

* Detener el EV:
vzctl stop 101

* Reiniciar el EV:
vzctl restart 101

* Eliminar el EV:
vzctl destroy 101

* Entrar en el EV:
vzctl enter 101

* Ejecutar un comando desde fuera del EV en el EV:
vzctl exec 101 comando
Ej: vzctl exec 101 /etc/init.d/ssh start

* Listar los EVs del sistema:
vzlist -a

- Ahora podéis conectaros de 2 formas, entrando en él
vzctl enter 101
o a través de ssh
ssh -l root ip.EV



- Migración de EV 101 de Server1 a Server2:

Migrar un EV de un server con OpenVZ a otro con, lógicamente, OpenVZ, es lo más sencillo del mundo.
Sólo se necesita un requisito, que el acceso por ssh sea sin contraseña, ya que la migración se realiza por medio de este servicio.

Hay dos tipos de migración:

* Migración online:
Server1: vzmigrate --online ip.Server2 101

* Migración offline:
Server1: vzmigrate ip.Server2 101


Las ventajas que yo le veo a OpenVZ es su sencillez en la instalación, tanto del propio OpenVZ como de los EVs. Además de lo fácil que resulta migrar los EVs
de un servidor que se nos quedó pequeño a otro con más potencia.

Una de las curiosidades que me he encontrado leyendo la documentación, es cómo la gente aprovecha OpenVZ no para el principal fin para el que fué
creado, tener varias máquinas virtuales en un único servidor para sacarle el máximo rendimiento al hardware, sino que muchos únicamente tienen un
único EV en el servidor, que tiene asignado el máximo de recursos de éste.
¿ Por qué ? Pues precisamente para aprovecharse de la facilidad de
migración, y ser independiente del hardware. De esta forma, si tienes un servidor crítico que te está dando fallos, no tienes que volver a instalar
todo de 0, migras el EV a otro servidor, y en 10 minutos está todo funcionando otra vez.

Como véis las ventajas son muchas.

En este enlace tenéis el Open-VZ-Users-Guide.pdf del que saqué esta información ( está en inglés ), y dónde podéis entrar en más detalle sobre la
asignación y modificación de recursos al EV ( cpu, memoria, disco, etc ).

Espero que no haya sido un tostón.

Actualización 1:

Asignar máximo de recursos a un EV

Para asignar el máximo de recursos a un EV y que éste aproveche al máximo el hardware del equipo anfitrión tendremos que hacer varias cosas:

1. Asignar CPU al límite:

Ejecutamos vzcpucheck para ver la utilización de la cpu y el poder real:
Current CPU utilization: 2000
Power of the node: 122225

Para cambiar los valores usamos cpuunits, que indica el minimo de cpu garantizado para nuestro EV; y cpulimit que indica el máximo en porcentaje de uso del cpu.

Vamos a poner que nuestro EV 101 use el 90% de nuestra cpu con un minimo de 120000, ya que sólo vamos a tener este EV en el anfitrion:

vzctl set 101 --cpuunits 120000 --cpulimit 90 --save

2. Tamaño de disco:
Por defecto el tamaño de disco por defecto es 1GB. Tendremos que aumentarlo al valor que queramos:

vzctl stop 101
vzctl set 101 --diskspace 50000000:55000000 --save
vzctl start 101

Esto nos asigna un tamaño de 50GB con un margen de 5GB.

Nuevo Ordenador De Empresa

Ayer recibí el nuevo equipo de sobremesa para sustituir al viejo Pentium4.
El pobre había resistido como un campeón, y aún lo aprovecharé para otros menesteres, pero debido a que tengo que virtualizar bastante tanto con vmware u openvz, la sustitución era necesaria y urgente.

Y el cambio ha sido brutal, he pasado de arrastrar el vmware con 2 máquinas virtuales corriendo, a tener 3 o 4 abiertas y navegar y leer el correo sin pestañear.
El nuevo modelo es un Core2Duo E6750  @ 2.66GHz con 4MB de caché, 2GB de Ram, y una Ati  HD 2400 XT.
No es un modelo para jugar, evidentemente, y 4GB para virtualizar irían mejor pero ... vaya cambio !!

Estoy contento como un orco al que le hayan pagado una operación de cirugía estética.

Acceder Mediante SSH Sin Contraseña

Sí, vale, lo reconozco, ya sé que hay tropecientas mil páginas dónde cuentan como se hace. Pero también es verdad que siempre que lo necesito hacer estoy 10 minutos buscando, así que lo pongo aquí y lo tengo a mano. Además que este blog no lo lee nadie, así que iros a protestar a otro lado.

Objetivo: Entrar como usuario root ( sí, que vale otra vez, que no se debe entrar como root, que pesados que sois ) desde server2 a server1 sin contraseña.

Método:

En server2, como usuario root ejecutar:
ssh-keygen -t rsa y dar a enter las veces que haga falta.
Esto creará:

• /root/.ssh/id_rsa --> Clave privada

• /root/.ssh/id_rsa.pub --> Clave publica

Si en el server1, en la ruta /roo/.ssh/ no existe el fichero authorized_keys:

• Copiamos el archivo de server2 /root/.ssh/id_rsa.pub y lo pegamos en server1 en /root/.ssh/ con el nombre authorized_keys

Si ya existe el fichero authorized_keys en server1:

• Copiamos el archivo de server2 /root/.ssh/id_rsa.pub a /tmp en server1 y lo agregamos a authorized_keys con:

cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys desde server1

Si ahora entramos desde server2 por ssh como root, no nos debería pedir contraseña.