Archivo del sitio

Subir de Debian Lenny a Squeeze: modo sano y paranóico

Actualización: Pueden acceder a una guía limpia de migración en > http://phenobarbital.gnu.org.ve/doku.php/linux:debian

En la mayoría de los casos, el subir un equipo de Lenny a Squeeze basta con ejecutar:

aptitude dist-upgrade

y listo (esto te lo podría jurar cualquier debianita), pero a veces no es el caso (de hecho, la mayoría de las veces no lo es), la mayoría de los errores que te podrías encontrar son:

  • Inconsistencia entre paquetes
  • Problemas de las llaves de Debian, errores en repositorios
  • Fallo de la actualización del udev al montar un nuevo kernel
  • Que se quedan algunos paquetes en -lenny
  • Inconsistencias del grub

En mi caso, se trataba de mi Desktop, que se encontraba en Lenny desde hace ya bastante tiempo por lo que hice una guía “paranóica y cuidada” para subir de Lenny a Squeeze sin absolutamente ningún problema (la probé al menos unas 5 veces con unas instalaciones limpias de Lenny subidas a Squeeze en mi laptop).

Actualizando repositorios

NOTA: Como lo notara mi amigo Milton (aka Milmazz), es cierto que deberíamos contar con un sistema actualizado en la última versión de Lenny *antes* de intentar subirlo, para ello ejecutamos:

aptitude safe-upgrade

Luego, actualizaremos el repositorio a Squeeze, este paso lo debe conocer cualquier debianita, simplemente editamos el sources.list (/etc/apt/sources.list) y todo lo que apunta a (stable|lenny) lo cambiamos a (testing|squeeze)

UPDATE: para los “no debianitas”, una línea en el source.list tiene la forma:

deb URL distribución (secciones)

donde:

URL: ruta al repositorio, ejemplo: http://ftp.us.debian.org/debian/

Distribución: versión de Debian (stable = lenny, testing = squeeze, unstable = sid)

Sección: Tipos de paquete a instalar, main (principal libre), contrib (contribuciones externas), non-free (paquetes y binarios no libres)

Un ejemplo sería:

deb http://ftp.us.debian.org/debian/ squeeze main contrib non-free

NOTA: Es bueno, comentar las líneas que hacen referencia a volatile-debian y a security-debian cuando vayamos a hacer un upgrade.

Guardamos el archivo source.list y ejecutamos:

apt-get update

Luego de actualizado el repositorio a Squeeze, limpiamos la caché de APT (para ahorrar espacio y eliminar todos esos paquetes lenny que están ahí):

apt-get autoclean

Actualizando paquetes, primera fase

Luego, y para evitar problemas en la inconsistencia de los paquetes, instalamos:

apt-get install apt aptitude dpkg debian-keyring

Esto actualizará a Squeeze los paquetes encargados de la instalación.

ACTUALIZACION: Ahora bien, algunas personas podrían experimentar problemas con el sys.rc si hacen el dist-upgrade ahora, más que todo cuando corres servidores y tienes muchos servicios ejecutándose; ahora que estas con repositorios en squeeze, es bueno “subir” esas aplicaciones conflictivas (como mysql, exim, postfix, postgresql, proftpd, samba y/o openldap).

un ejemplo sería:

aptitude install mysql-server postgresql exim4-base locales tzdata

(Gracias a Octavio Rossell “TR0N” por probar la receta y darse cuenta de este fallo).

Actualizando el Kernel

Si tienes una versión muy vieja de kernel, podrías tener conflicto durante el dist-upgrade, puesto que este necesita instalar una versión de kernel muy nueva (2.6.32) y con esta una versión nueva de las udev (158-1), cambiar las udev de una versión a otra superior a 150 es básicamente IMPOSIBLE, así que por seguridad, es preferible que subamos primero el kernel a una nueva versión:

Lo buscamos:

aptitude search linux-image

Y lo instalamos:

aptitude install linux-image-2.6.32-5-686

NOTA: deben instalar el que sea para su arquitectura y si acaso no la saben, ejecuten:

aptitude install linux-image-$(uname -r)

NOTA: Gracias a Milmazz por la acotación.

Luego de instalado el kernel, reinician.

reboot

Subir la distribución, fase 1

Ahora sí, a subir la distribución (primera vez):

apt-get dist-upgrade

Esta “primera subida” causará que todo suba, salvo algunos paquetes asociados al kernel, porque aunque subirán las udev, paquetes asociados a la misma no se “subirán” hasta que la versión squeeze (158-1) esté en ejecución; es también en esta fase donde subirán a GRUB2.

NOTA: como lo comentó Milton (aka Milmazz), si el sistema tiene entorno gráfico (léase Gnome, LXDE o KDE) es bueno hacer la actualización ya sea desde una terminal (tty) o sin sistema X cargado, yo detuve gnome:

/etc/init.d/gdm stop

Y luego bajé a init 3:

init 3

Así evitamos que aplicaciones o entornos como GNOME estén en ejecución durante la actualización.

Reiniciamos el equipo:

reboot

Subir la distribución (fase 2)

Y ejecutamos ahora un full-upgrade, verán que el aptitude bajará aún más paquetes e instalará algunas cosas específicas de Debian Squeeze, además eliminará todo lo que había lenny, incluyendo las udev.

aptitude full-upgrade

Veremos cosas como esta:

Configurando udev (158-1) ...
...
Configurando linux-image-2.6.32-5-686 (2.6.32-18) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-686

Y volvemos a reiniciar …

reboot

Pasos finales

Veremos como se ha actualizado a grub2 (desde grub1), aunque seguirá levantando usando grub1 (menu.lst), para eliminar definitivamente a grub1 ejecutamos:

upgrade-from-grub-legacy

El cual preguntará en cual dispositivo (si en /boot o en el MBR del disco /dev/sda) se instalará, en mi caso como no tengo otro S.O lo monté en /dev/sda.

Volvemos a reiniciar (solo para comprobar que ahora solo tenemos grub2)

reboot

Y ya, por último, comprobamos la salud del Squeeze:

aptitude update && aptitude dist-upgrade

(no debería instalar nada más)

cat /etc/debian_version

Debería retornar “squeeze/sid”
y ya (si queremos ahorrar espacio) podemos limpiar nuevamente el cache con:

apt-get autoclean

Y ahora, si estamos (sin inconvenientes de ningún tipo) en Debian Squeeze!.

NOTA: con especial dedicación a aquellos que insisten en que pasar de Debian Lenny a Squeeze es un simple “dist-upgrade” sin contar con las implicaciones de diversas configuraciones, arquitecturas y programas instalados, yo probé esta receta en muchos equipos y funcionó (donde un simple dist-upgrade dejaba en sistema inconsistente) y Octavio (aka [TR0N]) me ayudó a depurarla probándola en un servidor propio.

Espero que más personas prueben la receta y me indiquen posibles cambios.

[ Weyu / Xen ] Los trucos de la doñita para Xen

He creado dentro del Wiki un apartado que recopila trucos, detalles de configuración y resolución de problemas básicos (y no tan básicos) usando la virtualización con Xen.

Trucos simples desde como migrar una VM de máquina o las combinaciones alternativas de la consola hvc0, hasta crear bonding y bridging para optimizar el uso de los recursos de red de nuestra institución, además de un apartado de resolución de problemas comunes, han sido incorporados acá.

Se incorporarán más a medida que vaya madurando el wiki y vaya obteniendo “feedback e ideas” de los contribuyentes.

Espero los ayude tanto como a mí.

El enlace acá: http://phenobarbital.gnu.org.ve/doku.php/weyu:xen:faq

[Xen] Moviendo máquinas virtuales entre hosts

La utilidad de mover una máquina virtual (VM) entre dos servidores con Xen permite contar con copias de seguridad, servidores stand-by, copias físicas en disco (para almacenarlas de manera segura) o para crear copias de servicios para redundancia.

Como parte del proyecto Weyuü y gracias al apoyo incondicional del proyecto GNU, los manuales (howto) estarán de ahora en adelante en el wiki de proyecto GNU phenobarbital.gnu.org.ve y por ende por acá solo colocaré la referencia y espacio para comentarios (mientras no pueda activar el plugin de comentarios en el Wiki).

Es mi primer artículo colaborativo en el wiki de GNU, espero encontrar algún plugin para wordpress que me permita vía RSS “colocar” las nuevas páginas acá.

Mientras, podrán encontrar el enlace al wiki-manual acá: Migrando con Xen.

Exportando dispositivos PCI a una VM con Xen y Debian Lenny

Por lo general en un entorno virtualizado, el hypervisor se encarga de gestionar el acceso a los recursos de hardware de las distintas máquinas virtuales; sin embargo, en algunas ocasiones deseamos que una VM (máquina virtual) tenga acceso *directamente* a un dispositivo físico (PCI-USB) de nuestra máquina.

Usando PCI-back

PCI back es un módulo del kernel Xen que nos permite “ocultar” un dispositivo al dom0 (máquina base) para ser “expuesto” o “exportado” a alguna de las máquinas o VM (de manera exclusiva).

PCI-Back no es un módulo que se encuentre activo (al menos en la versión de kernel que tengo de Xen para Debian Lenny), pero activarlo es bastante fácil.

Habilitando PCIback en Debian Lenny

Para habilitar PCIback bastará con agregar este módulo a la lista de módulos gestionados por el initramfs:

echo pciback >> /etc/initramfs-tools/modules

Luego, creamos un nuevo initrd, esta vez con pciback habilitado, de manera que podamos obviamente, arrancar sin PCIback:

mkinitramfs -o /boot/initrd.img-`uname -r`-pciback `uname -r`

Esto, generó un initrd llamado:

initrd.img-2.6.26-2-xen-amd64-pciback

y edito el menu.lst (en grub2 sería el grub.cfg o editar las reglas correspondientes):
de:

module /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/sda1 ro console=tty0
module /boot/initrd.img-2.6.26-2-xen-amd64

a:

module /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/sda1 ro console=tty0
module /boot/initrd.img-2.6.26-2-xen-amd64-pciback

Al reiniciar el dom0, ya tendremos habilitado PCIback.

Y reiniciamos el dom0.

Exportando una tarjeta de red en exclusiva para un VM

En mi caso, tengo una infraestructura para un servidor de correo, como la planteada en la figura:

No hemos creado un bridge con la eth1, ya que disponemos de una sola IP asignada por el ISP a través de un Frame Relay y no se compartirá dicha interfaz, para optimizar el rendimiento (un 35% mejor) y otras razones, la eth1 se “ocultará” y será entregada a la dom1 (que será un servidor de correo, con dos interfaces, una pública y otra privada).

Creando nuestro archivo pcibind:

Vamos a crear un archivo PCIbind, que se ejecutará al inicio, con este, podremos configurar qué dispositivos PCI se ocultarán, además podemos “apagar” la configuración en cualquier momento (a diferencia de usar pciback.hidden() en el grub, que requiere reiniciar el equipo dom0).

El archivo tiene la siguiente forma:

#!/bin/bash
# /etc/init.d/pcibind  <graham@vpac.org> Nov 2008. Rev: 20081202
#
# description: Bind a device to the PCI Backend's list

case "$1" in
 start) cat /etc/pcibind.conf 2>/dev/null |
 awk '{if ($1 !~ /#/) if($NF > 1) print $0}' |
 while read PCI ; do
 SLOT=`echo "$PCI" | awk '{print $1}'`
 DRVR=`echo "$PCI" | awk '{print $2}'`
 echo -n $SLOT > /sys/bus/pci/drivers/$DRVR/unbind
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
 done                                                   ;;
 stop ) cat /etc/pcibind.conf 2>/dev/null |
 awk '{if ($1 !~ /#/) if($NF > 1) print $0}' |
 while read PCI ; do
 SLOT=`echo "$PCI" | awk '{print $1}'`
 DRVR=`echo "$PCI" | awk '{print $2}'`
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/unbind
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/remove_slot
 echo -n $SLOT > /sys/bus/pci/drivers/$DRVR/bind
 done                                                   ;;
 * ) echo "Usage: $0 {start|stop}"; exit 2                  ;;
esac
exit 0

El archivo va en /etc/init.d/pcibind y busca un archivo de configuración en /etc/pcibind.conf.

Luego de creado, le damos privilegios a root sobre el archivo, lo hacemos ejecutable y lo agregamos a rc.d

chmod 0750 /etc/init.d/pcibind
update-rc.d pcibind defaults

Con esto, ya tenemos pcibind listo para “ocultar” los dispositivos PCI que le indiquemos.

Descubriendo las NIC Ethernet

Cuando ejecutamos:

ifconfig -a

Vemos la información de la eth1:

eth1      Link encap:Ethernet  HWaddr 00:ab:fe:85:25:55  
 inet6 addr: fe80::218:feff:fe83:2450/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:10779 errors:0 dropped:0 overruns:0 frame:0
 TX packets:56975 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:698027 (681.6 KiB)  TX bytes:3653233 (3.4 MiB)
 Interrupt:26

Nos interesa la MAC Address de la tarjeta de red; ahora descubriremos su PCI-id y el módulo del kernel que la gestiona:

para ello ejecutamos:

lspci -v

Y en su salida encontraremos algo como esto:

03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet (rev 10)
 Subsystem: Compaq Computer Corporation NC7771 Gigabit Server Adapter (PCI-X, 10,100,1000-T)
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 29
 Memory at fdde0000 (64-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at c4210000 [disabled] [size=64K]
 Capabilities: [40] PCI-X non-bridge device
 Capabilities: [48] Power Management version 2
 Capabilities: [50] Vital Product Data <?>
 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
 Kernel driver in use: tg3
 Kernel modules: tg3

Si desean, pueden ejecutar primero con lspci -v | grep Ethernet

03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703  Gigabit Ethernet (rev 10)

El primer valor (en negrillas) es el PCI-id

Con esto descubrimos que la tarjeta eth1 es una Broadcom, PCI-id: 03:02.0 y la gestiona el módulo del kernel tg3.

Ocultando la tarjeta al dom0

Para ocultar cualquier dispositivo PCI, simplemente lo agregamos como un línea en el archivo /etc/pcibind.conf:

# /etc/pcibind.conf
# SLOT        DRIVER

0000:03:02.0  tg3  # MAC=00:ab:fe:85:25:55

Hemos puesto el PCI-id (slot PCI), el módulo del kernel (tg3) y como comentario recordatorio, la mac-address de la tarjeta.

Al ejecutar

/etc/init.d/pcibind start

Veremos que el dispositivo eth1 “desaparece” y ya no es accedido por el equipo local.

Si deseamos “reaparecerlo” (la VM que lo tenga asignado debe estar apagada) simplemente ejecutamos:

/etc/init.d/pcibind stop

Asignado el recurso PCI a una VM

Para asignar el recurso a una VM debemos editar el archivo /etc/network/interfaces (antes que nada) para que la máquina al reiniciar pueda hacer uso de la tarjeta NIC, simplemente agregamos:

hwaddress ether 00:AB:FE:85:25:55

Quedando:

iface eth1 inet static
address 200.105.240.254
netmask 255.255.255.248
gateway 200.105.240.249
dns-search cantv.net
dns-nameservers 200.44.32.12
hwaddress ether 00:AB:FE:85:25:55

Apagamos la VM luego de agregar esa opción en el /etc/network/interfaces

Luego, en el archivo de configuración de la VM en Xen (/etc/xen/vmcorreo.cfg) agregamos la siguiente opción:

pci = [ “03:02.0″ ]

Que representa el dispositivo (o los dispositivos) PCI que vamos a asignar a la VM:

Quedando:

#
#  Networking
#
vif         = [ 'ip=172.16.80.20,mac=00:16:3E:CF:3F:AA,bridge=brlocal' ]
pci         = [ "03:02.0" ]

Cuando iniciemos la VM (xm create vmcorreo.cfg) veremos que tendremos 2 interfaces de red, una virtual (eth0) que sale por el bridge del dom0, y una eth1, que será físicamente nuestra interfaz a Internet.

Como nota adicional, recuerden instalar todos los módulos en su domU:

apt-get install linux-modules-`uname -r`

Sobre todo si tienen una NIC u otro hardware PCI que requiera módulos especiales del kernel para ser detectado.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.220 seguidores

A %d blogueros les gusta esto: