»
S
I
D
E
B
A
R
«
Ubuntu LiveCD desde PXE
February 3rd, 2009 by Isma

PRELUDIO

Luego de lanzada una nave al espacio, lo único que realmente importa a todos quienes estan mirando, es el “timing”, la sincronización de todo lo que deba suceder.  El booteo es análogo al despegue, es cuando todo el hardware se enciende eléctricamente y empieza a funcionar como un sistema.

El inicio despliega todo el hardware disponible y en el extraño caso de que todo salga bien, lanza el cohete. Igual que en la NASA, puede pasar cualquier cosa, pero 99% de los casos son exitosos. Porque la tienen clara.

Entonces, como nos enseñaron en Sistemas Operativos, el hardware, que necesita ser rápido y preciso (por ende, escaso de espacio porque hasta hace poco, velocidad = 1/capacidad), le pasa el control a otro hardware mas versátil: el disco duro. De ahí en mas todo depende de él, incluso el hecho de tener un sistema operativo y bootearlo.

Otras formas de bootear un sistema operativo es de un medio extraíble como dispositivos de almacenamiento USB, unidades ZIP, unidades bizarras de iomega, el viejo y querido CD-ROM booteable, o el viejo y ya no querido diskette (nota: lo correcto sería “la vieja y ya no querida diskette”, porque diskette es el femenino de disk … una disca).

La última y la menos pensada ( ¡ con qué necesidá ! ) es el booteo PXE a través de la red.

Preboot eXecution Environment (PXE) es un sistema por el cual la tarjeta de red exije a una ubicación en la red a determinar, un sistema operativo interpretable para que lo levante la máquina en donde está ella colocada.

Es útil cuando no tenés un disco duro, cuando tenés muchas máquinas iguales en un mismo lugar que deberían correr las mismas cosas (atento cybercafés), o si quisieras que en tu red wifi solo usen tu sistema operativo (esto último es parte mentira porque las tarjetas wifi no hace PXE, pero me parece que se puede instrumentar y suena copado).

NECESIDAD

Tiene cara de hereje. Hace poco me regalaron a Alice, mi pc, y a Wendy (athlon xp 1.6ghz, 512mb) se la di a mi vieja. Le saqué una HP Vectra (PII 333 con 256mb) que se le arrastraba, y ahora está cumpliendo sus tareas prejubilatorias forzosas (está sirviendo dknuto).

La cosa es que si bien le puse una maquina muy superior, le deje el disco duro seagate de 4gb que estaba en la vectra, y que despues de un tiempo falló y a veces arranca y a veces no. Wendy se quedó sin disco duro.

En un futuro cercano me voy a comprar un disquito de un tera y le voy a pasar el de 80gb mio a wendy. Pero mientras eso no sucede….

INSTRUMENTACION

Necesitamos:

  • un cerebro
  • un livecd de ubuntu (preferentemente 8.04 u 8.10)
  • un servidor en linux medio pronto (yo voto por archlinux)
  • una red cableada (quizas… en un futuro … inalambrico)
  • una tarjeta de red que soporte PXE (la mayoría de las integradas lo hacen)
  • paciencia, mauri .. paciencia

Las siguientes líneas van a ser basadas en este texto, y en no comerme ni la punta.

Lo primero que debí hacer fue acercarme a NFS.. con miedo, como quien le va a sacar un cuchillo de la mano a alguien. Sabía que necesitaba una forma de almacenar y transferir en la red (luego me enteraría que necesito 2) y que samba no era lo suficientemente bueno.

Por suerte no fue para tanto,  # pacman -Sy nfs-utils resolvió mi primer problema.

Lo configuré con el webmin pero no voy a entrar en detalles. El módulo se llama “NFS exports”. La configuración implica que compartas un directorio previamente creado (ejemplo # mkdir /pxe ), y que cualquiera lo pueda escribir. Esto es asi porque en mi red lo puedo hacer. Si en tu red no está bueno, no lo hagas y mirá como se limita el servicio.

Listo el pollo, falta un servidor DHCP y TFTP. El protocolo trivial de transferencia de archivos (TFTP) es igual al ftp pero mas simple y unilateral. Consta del servidor que da y el cliente que recibe, así lo dijo Dios. Es un FTP heterosexual.

El servidor DHCP de tu casa no sirve. A menos que te las ingenies para configurarle una ruta TFTP. Que pasa: cuando DHCP asigna una IP, le envía pila de datos al cliente, 4 de ellos básicos: [tu ip], [tu servidor dhcp (o sea yo)], [tu gateway a otra red / internet] y [tu mascara de subred].

Cualquier servidor DHCP mediocre hace eso, y es por eso que necesitamos un servidor más elaborado. Uno que también pase un puntero a un servidor TFTP que puede ser el mismo o no.

Ejemplo: en este momento hay una tarjeta de red tratando de iniciar.

caso 1) agarra el dhcp request tu router inalámbrico casero común, le da una ip 10.0.0.5 , no le da un tftp, a la tarjeta le chupa un reverendo huevo y … nunca sale el cohete. ABORT

caso 2) agarra el dhcp request un demonio DNSMasq como el que voy a instalar en el proximo paso, le da una ip 10.0.0.5 y le dice que en 10.0.0.1 hay un servidor tftp. LAUNCH! la tarjeta bootea y levanta lo que hay en el tftp ===> esto quiero!

Mucha documentación habla que esto se hace con un servidor tftp como tftp-hpa y un demonio dhcp como dhcpd, pero e coisa do pasado como el beijo na boca. DNSMasq hace todo por ti. # pacman -S dnsmasq

Editando /etc/dnsmasq.conf hay poca cosa para hacer. Encontrar la línea dhcp-range=192.168.0.1,192.168.0.130,12h (mas o menos), descomentarla y ajustarla a tu red. Son las IP que va a asignar el servidor dhcp, formato [primer ip],[ultima ip],[tiempo de otorgacion (12h esta bien)].

Hay formas de limitar esto para hacerlo mas seguro y ajustado a tu caso. No me voy a inmiscuir, están detalladas en la misma configuración.

En mi red, el que routea sigue siendo el router pero dnsmasq no lo sabe. Hay que encontrar dhcp-option=3,192.168.0.1 (notese que son dos campos: [3],[ip.del.rou.ter] pero el tres es la configuración del gateway. Gracias a este foro lo pude entender). Descomentarla y cambiarlo para ajustarse a nuestra red.
Descomentar dhcp-boot=pxelinux.0 y setearlo de esa forma si no lo está (pe equis e linux punto cero).

Un par de párrafos debajo está enable-tftp que activa un servidor TFTP integrado. Descomente, por favor. Debajo, tftp-root tambien va descomentado y como en el ejemplo, el valor es /pxe

Con eso esta bien de dnsmasq. Reiniciar el servicio y ya está.

Ahora agarramos el CD de linux y le hacemos una imagen, supongamos ubuntu.iso . La llevamos al server y la montamos, pero antes debemos copiar del cd el archivo \casper\vmlinuz y \casper\initrd.gz en el servidor, en /pxe

#mkdir /mnt/imagen

#mount -o loop ubuntu.iso /mnt/imagen
Teóricamente, se puede trabajar con la imagen montada directamente en /pxe/ubuntu. Yo no lo intenté, pero en ese caso salteen los pasos siguientes. En caso de que montar en loop dé algún problema (en archlinux sucede) es probable que necesiten levantar el módulo loop # modprobe loop

#mkdir /pxe/ubuntu

#cp -a /mnt/imagen /pxe/ubuntu

#umount /mnt/imagen

Y ya pueden borrar la imagen.

pxelinux.0 es una especie de vmlinuz, un arrancador del sistema en codigo maquina que es medio general para todos los booteos pxe. Lo pueden descargar de aqui. Agréguenlo a /pxe

Luego hay que crear un directorio # mkdir /pxe/pxelinux.cfg

Dentro de ese directorio, crear un archivo llamado “default” que contenga lo siguiente:

default live-hardy-i386
SAY press return for menu
#TIMEOUT 50

LABEL live-hardy-i386
kernel /vmlinuz
append boot=casper netboot=nfs nfsroot=192.168.0.X:/pxe/ubuntu initrd=ubuntu/initrd.gz

Nótese que nfsroot tiene la ip del servidor NFS, que hay dos puntos antes de la ruta de la carpeta compartida, que la linea append es la última y no hay otra linea debajo sino a continuacion, y que tanto kernel como initrd tienen rutas relativas (nfsroot usa absoluta).

Debemos mover initrd.gz a /pxe/ubuntu

Eso debería funcionar. Cualquier duda comenten y vemos que podemos hacer.

EPILOGO

Si bien un cohete puede agarrar para cualquier lado cuando sale, debe agarrar para dos o tres lados posibles, porque sino pasan cosas feas. Todo depende de lo que se necesite hacer, porque la estación espacial donde van a poner los paneles solares está en un solo lugar… Con esto quiero llegar a que es sumamente importante la automatización exacta de los procesos para obtener un resultado óptimo.

He de decir que bootear el livecd desde una locación remota ha solucionado el tema de no poder guardar los cambios hechos en el sistema, pero ha mejorado en un 900% el rendimiento (comparado con el mismo livecd en la bandeja), siendo que yo no esperaba ver una mejora espectacular. Hay que probar mas con esto, ver que cosas se pueden hacer exactamente y usarlo de formas divertidas. Escucho ofertas.

http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/digg_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/stumbleupon_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/delicious_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/technorati_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/google_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/facebook_48.png http://dknuto.homelinux.net/wp-content/plugins/sociofluid/images/twitter_48.png

Leave a Reply

»  Substance: WordPress   »  Style: Ahren Ahimsa
Free counter and web stats