La fonera funciona, pero...

Pero puede no valer para el centro tic, porque ahora mismo la fonera lo que hace es buscar el archivo shadow, y una vez encontrado busca una cadena de texto, en la línea del usuario root, que empiece por $ sigan varios caracteres y después ":", esa es la contraseña cifrada, y luego la elimina. Simple y sencillo, ahora mismo funciona bien tanto en mi servidor como en mi portátil, en unos 25 segundos arranque borra la contraseña y reinicia. El script al final ha quedado así:

PARTICIONES=$(ls /dev | grep "hd..")
mkdir /media
for i in $(echo $PARTICIONES)
do
mkdir /media/$i
mount /dev/$i /media/$i
SHADOW=$(ls /media/$i/etc/shadow)
SHADOW2=/media/$i/etc/shadow
if [ $SHADOW = $SHADOW2 ]; then
cp $SHADOW $SHADOW.bak
cat $SHADOW | grep root | sed -r 's/|[$][^:]+//g' > $SHADOW
cat $SHADOW.bak | grep -v root >> $SHADOW;
else umount /media/$i;
fi
done
shutdown -r now

Y lo he puesto lo antes que he podido para que el sistema pueda arrancar y funcionar, el fichero /etc/init.d/rcS ha quedado así:

. /etc/init.d/functions
switch_root_to_tmpfs
mount_dev_on_devfs
mount_devpts
mount_proc
delete_password
shellout

Bien, así ha funcionado todo, sin embargo puede ser que no funcione en el centro tic porque guadalinex por defecto tiene el usuario root deshabilitado, lo que se traduce como una configuración diferente en el fichero shadow, en lugar de una cadena de caracteres que representan la contraseña cifrada, aparece el carácter "*", por lo tanto mi comando sustitución con sed no funcionará. Así que tengo que volver a cambiar el script, porque a pesar de funcionar en muchas maquinas, no lo hará en las que tengan root deshabilitado.

PD: Puede que esto le interese a mas de uno, así que a lo mejor cuando acabe prepar mi propio firmware, o un paquete ipk, o algo para que cualquiera pueda configurar fácilmente su fonera tal y como está la mía.

La fonera casi esta lista

Llevo sin escribir desde el martes, y aunque desde hace dos días no me he dedicado mucho a la fonera desde mi último post ya ha llovido mucho, hasta el punto de que la fonera está casi lista para funcionar, está prácticamente acabada. Ya funciona el netboot, el script está hecho (aunque hay que cambiarle una cosa) y luego solo quedaría averiguar la parte idónea donde colocar el script, porque interesa que sea lo antes posible, para que así es proceso sea mas rápido. Os cuento un poco mas despacio como ha ido todo.

Lo primero que hice fue averiguar como era el funcionamiento del arranque pxe, viendo los archivos que descargué de ubuntu (netboot.tar.gz), averigüé como era (bueno y con unos conocimientos previos mínimos que adquirí gracias a google). Hacen falta 4 ficheros, os los pongo junto a una breve explicación de que son y para que sirven cada uno de ellos:

-pxelinux.0: esta es la piedra angular del pxe, es el archivo que llama el dhcp cuando recibe una solicitud de arranque vía red (tiene que estar configurado en el servidor dhcp, en mi caso, dnsmasq). Exactamente no puedo contaros el procedimiento que realiza ni nada porque no lo he averiguado.
-pxelinux.cfg/default: es el archivo de configuración, indica los parámetros del arranque y demás (bootsplash, si se muestra algún archivo, si pasa algo al pulsar las teclas f1, f2...). En esa carpeta se pueden configurar diferentes archivos si se quiere para cuando se reciba una petición de una determinada mac se use ese archivo. En mi caso no me interesa eso porque no conozco las MACs de los pc, además quiero que se válido con cualquier máquina. Luego comento este fichero mas despacio y las configuraciones que yo he usado.
-linux: este es el kernel linux que voy a usar, realmente se le puede poner cualquier nombre, pero tiene que estar configurado en el archivo anterior. El kernel que estoy usando yo lo he sacado de una imagen iso de guadalinex para instalación remota, para centros tic. En esa imagen hay tanto un kernel e initrd de v3 como de 2004.
-initrd.204: este es el fichero initrd, necesario para el arranque y que proporcionará un entorno de trabajo básico. Yo una vez mas he hecho uso del de guadalinex 2004, obtenido del mismo sitio que el kernel. Por qué se llama initrd.204? simplemente porque era el nombre que tenía en la imagen iso y no lo he cambiado, al contrario que el kernel que no lo cambié, realmente tanto el kernel como este archivo podéis llamarlos como queráis, eso si hay que configurar bien el pxelinux.cfg.

Bueno sabiendo eso solo queda saber como configurar el pxelinux.cfg/default. En la página web del autor se puede ver como se configura, en cualquier caso si sabéis usar syslinux también sabéis usar pxe, la sintaxis y los comandos son los mismos y es muy sencillo.

Os cuento como lo he configurado yo, la imagen iso de la que no paro de hablaros usa syslinux para su arranque, así que he usado el mismo fichero (no lo pongo aquí por su tamaño), pero le he cambiado algunas cosas, el timeout, que sea 0, es decir sin límite (tiempo de espera), el default local también lo quité, porque significa que cumplido el timeout arrancará desde el disco duro (local), y también elimine el label local, que es realmente quien indica lo del arranque local. Por último también eliminé el label Instalav3, porque no tengo ese kernel e initrd en la fonera. Lo demas lo dejé así. En cualquier caso, eso lo cambiaré. Dejaré una sola opción (default) que arranque el kernel y el initrd, y le pondré timeout 1, para que automáticamente cuando pase un segundo arranque el solo.

Ya solo falta una cosa para que la fonera sirve de pxe server, configurar en el servidor dhcp el archivo que tiene que enviar. Una vez mas editamos el archivo /etc/dnsmasq.conf, la línea que nos faltaba por terminar:

dhcp-boot=pxelinux.0

Simplemente tenemos que indicar el fichero, porque el servidor tftp ya esta configurado, así como su directorio raíz:

enable-tftp
tftp-root=/mnt/tftp

Con esa configuración yo ya lo tenía todo para la primera prueba, prueba que hice en el server, este initrd yo todavía no lo tenia modificado, así que no iba a quitar ninguna contraseña automáticamente, en este momento lo que me interesaba era probar si funcionaba o no, si podía arrancar desde la fonera, además lo hice en mi servidor porque yo sabía de antemano que no se me iba a borrar el disco duro ni nada parecido, ya que previamente había arrancado la imagen iso en vmware, y en cierto momento intentaba conectarse con rsync a 192.168.4.254, y esa ip no existe en mi red, por lo que ahí se paraba el arranque. Sabiendo eso conecté la fonera al server por ethernet y reinicio, el server comenzó a arrancar... desde la fonera!! funcionó! pero sabéis lo que pasó cuando llego ese momento en el cual se para el arranque? pues que me dio una shell! si una shell! así que yo monte la partición / y edité el fichero /etc/shadow y quité la contraseña de root, reinicio arrancando desde el disco duro y cuando llega la pantalla de login pongo root y ya esta! sin contraseña, funcionó! pude quitar la contraseña. También probé en el portátil y también le quité la contraseña, pero claro esto fue a mano, ejecutando comandos en esa shell, ahora se trata de hacer un script e integrarlo en el initrd, para que se ejecute todo automáticamente.

Ahora comienza otra odisea, en realidad todo sería muy sencillo con los conocimientos necesarios, pero en mi caso muchos de ellos los estoy adquiriendo especialmente para la ocasión, así que he tenido que ir poco a poco, a prueba y error. Ahora viene la parte de hacer el script y modificar el initrd, comencé con lo del script lógicamente. Hacer el script tenía una complicación añadida, tengo que averiguar en que partición se encuentra el archivo shadow, en mi prueba manual yo sabía que partición montar, pero el script tendrá que averiguarlo. Os voy a contar como lo hice la primera vez, y como lo estoy haciendo ahora.

Mi primera idea fue esta, os pongo el script que la plasma y ahora os la describo:

#!/bin/bash
PARTICIONES=$(ls /dev | grep "hd..")
mkdir /media
for i in $(echo $PARTICIONES)
do
mkdir /media/$i
mount /dev/$i /media/$i
done
SHADOW=$(find /media -name shadow | grep "/media/hd../etc/")
cp $SHADOW $SHADOW.bak
cat $SHADOW | grep root | sed -r 's/|[$][^:]ls /dev | grep hd | grep "hd.."+//g' > $SHADOW
cat $SHADOW.bak | grep -v root >> $SHADOW

Lo primero que hace es ver las particiones que tiene el sistema, y lo almacena en la variable PARTICIONES, mira en el directorio /dev, y filtra la salida con grep a lo que sea hd**, explico, como todos sabéis en linux los discos duros son ficheros que están en /dev, por ejemplo /dev/hda, y las particiones se indican, añadiendo un número al nombre del disco duro, así pues la primera partición del primer disco duro será /dev/hda1. Y esto a que viene? pues que un disco duro no lo puedes montar, montas sus particiones, por eso en vez de hacer un grep hd, que filtraría tanto discos duros como particiones, lo que hago es filtrar solo las particiones, mandando a grep que solo seleccione lo que empiece por hd y sigan dos carácteres cualesquiera, de esta forma entraría hda2 pero no hda, por lo que me ahorro errores a la hora de montar.

Después crea el directorio /media, donde se montaran todas las particiones. A continuación viene un bucle (for) que va tomando uno por uno todos los valores de la variable PARTICIONES, crea un directorio con ese nombre y monta ahí esa partición y se repite hasta que ha acabado con la variable PARTICIONES. Ejemplo, coge el primer valor hda1, crea el directorio /media/hda1 y monta en la partición /dev/hda1.

Ahora viene la parte clave del script, la que localiza el archivo shadow y lo edita. Lo primero que hace es asignarle un valor a la variable SHADOW, ese valor es la ruta del archivo /etc/shadow, para encontrarlo lo que hace es buscar en /media algo que se llame shadow, realmente así buscamos en todo el disco duro, porque todas las particiones están montadas en ese directorio, mas tarde esto supondrá un problema, pero lo veremos después. Lo siguiente que hace es un backup del fichero. Y las dos ultimas líneas son las que modifican el fichero y quitan el password de root, es posible y probable que haya un procedimiento mejor que el que yo he usado, pero no he sabido hacerlo de otra manera. Lo que hace la primera de las dos líneas es pasarle a sed la línea del fichero que corresponde a root, este último comando selecciona la parte de la contraseña y la elimina, el resultado va al propio fichero shadow, después para añadir las líneas correspondientes a los demás usuarios del sistema hago un grep -v root, consiguiendo que devuelva como resultado todo excepto la línea de root, para acabar se añade (>>) al fichero shadow.

Ese era el primer script que se me ocurrió, y en teoría parecía buena idea (al menos a mi), y parecía que funcionaría. Sin embargo yo no contaba con una cosa, en el caso de mi servidor el find busca en mas de 110 GB, y en el caso de mi portátil en unos 75 GB, cuando se ejecutó el script tardó increíblemente en acabar, y además no funcionó, pero de todas formas no me moleste en intentar arreglarlo, porque no se cuanta información almacenaran las laptops del instituto, pero no puedo estar 5 minutos esperando a que find termine de rastrear el disco duro, así que toca cambiar el algoritmo.

Al igual que antes os pongo el nuevo script y luego comento:

#!/bin/bash
PARTICIONES=$(ls /dev | grep "hd..")
mkdir /media
for i in $(echo $PARTICIONES)
do
mkdir /media/$i
mount /dev/$i /media/$i
SHADOW=$(ls /media/$i/etc/shadow)
SHADOW2=/media/$i/etc/shadow
if [ $SHADOW ==$SHADOW2 ]
then
cp $SHADOW $SHADOW.bak
cat $SHADOW | grep root | sed -r 's/|[$][^:]+//g' > $SHADOW
cat $SHADOW.bak | grep -v root >> $SHADOW
else
done
fi
done
shutdown -r now

Las primeras líneas son claras, se crea el directorio /media y se asigna un valor a la variable PARTICIONES, después viene un bucle for igual que antes, pero cambia la tarea que realiza, el procedimiento es este: crea un directorio, monta la partición en ese directorio, luego crea la variable SHADOW, lo que hace es un ls en busca del archivo shadow, si devuelve resultado es que el fichero existe, y la ruta se almacena, si no hay resultado el fichero no existe y la variable se queda en blanco. Lo siguiente es una "variable de control" que nos permitirá ver si $SHADOW tiene el valor correcto, simplemente es la ruta que debería tener el fichero shadow en caso de que existiera. A continuación mediante un if se comprueba si SHADOW es igual a SHADOW2, si es igual se deduce que el fichero shadow existe en esa partición, si no son iguales entonces no hay shadow. Si no hay shadow se acabó, si hay shadow se le quita el password y se le hace un backup con el mismo procedimiento que en el script anterior. Lo único que cambia en este script es el procedimiento de búsqueda del shadow. Cuando acaba reinicia la máquina.

Tengo que aclarar que el script no funciona, se ejecuta aparentemente bien, pero alguna parte debe fallar porque luego cuando se reinicia root sigue con pass, tendré que averiguar que parte va mal, pero el algoritmo yo creo que esta bien pensado, pienso que es un problema de implementación, habré codeado algo mal, ya pensaré como lo arreglo.

Por último vamos a ver la parte que nos falta, como se modifica el initrd. Un initrd normal está comprimido al máximo con gzip, por lo tanto lo primero que hay que hacer es descomprimirlo:

gzip -dc initrd.204 > initrd.204.img

Con eso tendremos nuetro initrd descomprimido en el fichero initrd.204.img. Ver su contenido es muy sencillo, simplemente lo montamos con la opción loop:

mount initrd.204.img /mnt -o loop

Con eso podremos ver en /mnt el contenido de nuestro fichero, sin embargo tenemos un problema, no podemos modificarlo, no dirá que es un sistema de ficheros de solo lectura, y razón lleva, el initrd tiene un sistema de ficheros cramfs, y este sistema es de solo lectura. Entonces que hacemos? pues es sencillo copiar todo el contenido a otra carpeta, modificarlo a nuestro gusto y después empaquetarlo todo y crear nuestro propio initrd. Este procedimiento (el de copia) primero pensé en hacerlo con cp, el comando para copiar archivos, sin embargo se me complico porque no copiaba los enlaces simbólicos, por lo tanto yo obtenía un resultado diferente al original y que seguramente no funcionaría bien después, así que descarté esta opción, es posible que hubiera alguna opción de cp que lo solucionara, pero a mi se me ocurrió otra cosa, usar rsync, si un paquete que te crea una copia literal del original, vamos que "sincroniza" los directorios origen y destino, esta era la mejor solución, el comando que ejecuté fue este:

rsync -av /mnt /media/almacen/pxe/initrd/

Y se copió todo. Hecho esto me fui al directorio que contiene los script de inicio (/etc/init.d) y añadí mi script en el lugar adecuado. A ver os cuento, hay dos ficheros, functions y rcS, el primero contiene las funciones propiamente dichas, yo añadí la mía al final:

# delete root's password
delete_password() {
aqui va mi script
}

Y el fichero rcS es el que llama las funciones, simplemente es una lista con las funciones, yo coloqué la mía justo antes de la que paraba el arranque (la que ejecutaba un rsync, que al no poderse hacer se paraba todo):

[...]
if [ ! -z $FLAMETHROWER_DIRECTORY_PORTBASE ]; then
get_flamethrower_directory
fi

delete_password

get_boel_binaries_tarball
beep
[...]

Hecho esto guardo los cambios y ahora me tocaba averiguar como crear el initrd propiamente dicho, porque yo ahora mismo lo que tengo es un árbol de directorios con una serie de ficheros... nada que ver con un initrd que es un sólo fichero cramfs. Lo primero que se me ocurrió fue usar mkinitrd, comando que se usa para eso, para crear ficheros initrd, lo ejecuté:

mkinitrd -r initrd/ -o initrd.204

El -r indica el directorio que tiene que usar y el -o el fichero de salida. Aparentemente todo bien, pero ya me doy cuenta de que algo ha ido mal cuando que el fichero de salida pesa mas de 5 MB!!! y el del cga era de unos 500k!! diez veces menos! pensé que comprimiendo a lo mejor, pero me parecía excesivo que se fuera a reducir tanto:

gzip -9 initrd.204

Seguía pesando 5MB! bueno pues entonces lo monté para ver que tenía que lo había hecho crecer 10 veces, porque yo solo le añadí tres o cuatro líneas en un script, no era lógico ese aumento de tamaño. Lo monté y me encontré con algo que no esperaba para nada, muchas cosas repetidas: bin/, bin2/, dev/, dev2/; scripts que antes no había: linuxrc, linuxrc.conf, script. En fin que no se parecía en nada al oringal, y mucho menos a lo que yo tenía en mi directorio /media/almacen/pxe/initrd/.

Que hago ahora? pues caballeros, lo que se me ocurrió fue hacer uso de 2 libertades que me otorga el software libre: acceso al código fuente, y modificación del mismo. Realmente puede que exista alguna opción que simplemente creara el sistema de ficheros cramfs sin modificar nada, pero yo no la encontré, así que mediante apt (apt-cache show initrd-tools) averigüé donde esta el paquete initrd-tools, que es el que contiene la utilidad mkinitrd, veo la ruta del fichero en el repositorio, y con firefox me voy a la url del repositorio, a la ruta correspondiente y me bajo el código fuente del paquete. Descomprimo el paquete (es un tar.gz), y veo el paquete mkinitrd, ejecuto file mkinitrd para ver que es eso y es un script, así que nada, less mkinitrd y a leer, veo que para crear el sistema de ficheros cramfs usa el paquete mkcramfs, el script ademas comprueba algunas cosas, añade ficheros... el caso es que yo ya tenía la solución ante mis ojos, simplemente tengo que usar el paquete mkcramfs para que cree el sistema de ficheros y ya está, sin que altere nada. Ejecuto:

mkcramfs initrd/ initrd.204

Con lo que indico que tome los ficheros del directorio initrd/ y cree el archivo initrd.204. Hecho esto ya estaba todo solucionado, se lo mando a la fonera y puedo empezar a hacer pruebas. Cada vez que quiero cambiar algo simplemente lo modifico en initrd/, creo de nuevo el initrd con mkcramfs y lo subo a la fonera.

Pues lo único que me queda ahora es conseguir que el script funcione bien, seguiré investigando y trabajando con el, creo que acabaré pronto, lo que pasa es que estos dos últimos días no he hecho casi nada porque tenia en mldonkey descargando a toda velocidad y no quería pararlo, y hacer muchas pruebas en el portátil tampoco me gusta porque mientras no puedo hacer nada, si las hago en el server mientras arranca, reinicia, vuelve arrancar, vuelve a fallar... puedo seguir con el portátil haciendo cosas.

Y nada mas, solo decir que gracias a los que hayáis llegado hasta aquí, porque este post me ha salido bastante largo :P

PD: Intentaré publicar posts mas cortos con mas frecuencia, en vez de post tan largos cada cierto tiempo, porque la verdad este post es muy largo y creo que su lectura puede hacerse pesada.

Progresos con la fonera

Grandes y buenas noticias sobre la fonera, ya he conseguido que el tftp "funcione" y el dhcp también va bien. Ya solo me queda preparar los ficheros del pxe y estará todo listo. Voy a contaros todo con detalle, empezaré con el tftp:

El tftp es lo primero que he conseguido hacer funcionar, aunque me ha dado algún que otro problema, finalmente ha funcionado lo necesario. En mi fichero de configuración dnsmasq.conf, las líneas relativas al tftp son estas:

enable-tftp
tftp-root=/mnt/tftp

Lo que viene a decir simplemente que el servidor tftp esta activado y su directorio raíz es /mnt/tftp. Ah, bueno antes de continuar decir que aquel error que me daba dnsmasq al ejecutarlo:

dnsmasq: failed to create listening socket: Address already in use

Era debido a que dnsmasq se ejecuta al inicio del sistema, y al ya estar ejecutándose me daba error. Me di cuenta porque ejecute top para ver que hacía mi fonera y vi el proceso, así que ahora simplemente cuando quiero probar los efectos de alguna configuración simplemente mato el proceso y vuelvo a iniciarlo.

Tras ese breve paréntesis sigo con el tftp, realmente yo desde el principio tuve esa configuración en mi tftp, y podía conectarme, pero cada vez que quería enviar/recibir un archivo me daba error, os describo la situación, me conecto por tftp a la fonera e intento copiarme el fichero test (situado lógicamente en /mnt/tftp), que no es mas que un archivo de texto plano, también recibo el error si intento enviar un archivo (test2, también texto plano). Os pego la sesión:

$ tftp fonera
tftp> get test
Error code 4: unsupported request from 192.168.0.11
tftp> put test2
Error code 4: unsupported request from 192.168.0.11
tftp>

Investigando un poco en google y tras rastrear en la lista de correo de dnsmasq, bueno realmente me baje todos los logs (archivos de texto comprimidos), y busqué con grep, no encontré nada. Siguiente paso, rastrear en google, y tras buscar y buscar encontre una lista de errores de tftp (no tengo el link) y decía que para solucionar mi problema tenía que ponerlo en binary mode (hay dos, binary, y ascii), así que nada me voy al terminal ejecuto man tftp y veo que para ponerlo en binary mode simplemente tengo que poner "binary". Lo hice y funcionó, bueno parcialmente:

$ tftp fonera
tftp> binary
tftp> get test
Received 34 bytes in 0.0 seconds
tftp> put wep.txt
Error code 4: unsupported request from 192.168.0.11
tftp>

Recibo pero no envío. La verdad es que no es un problema que me moleste especialmente porque la verdad no necesito enviar archivos por tftp, para el arranque vía red solo necesito enviar archivos así que a no ser que mas adelante me ocasione algún problema serio (vamos que no me funcione nada) no me molestaré en arreglarlo. Pues lo dicho, lo que necesito del tftp ya lo tengo, así que ya me puse con el dhcp.

El dhcp, antes las líneas que tenía sobre el dhcp eran estas:

dhcp-authoritative
dhcp-leasefile=/tmp/dhcp.leases
dhcp-range=vlan0,192.168.0.20,192.168.0.50,255.255.255.0

La primera línea según el debe usarse cuando dnsmasq es el único servidor dhcp de la red y en mi caso, cuando vaya usarlo será así, ya que en la red a la que esto está destinado es mi fonera y un portátil, conectados por ethernet. La segunda simplemente es para que guarde un log de las ips asignadas. La última línea indica el rango de ips a usar. Para hacer la prueba lo que hice fue conectar la fonera a la segunda tarjeta de red de mi servidor (eth1) e intenté que se le asignara una ip con dhcp, utilizando dhclient: dhclient eth1, sin resultados útiles, no se le asigno ip. El servidor dhcp no funcionaba, probé con otros rangos de ips, con el mismo de la fonera... pero nada. Sin embargo, hoy al releer estas líneas que vienen por defecto en el archivo de configuración de dnsmasq decidí que si probara a usarlas a lo mejor funcionaba:

# other useful options:
# default route(s): dhcp-option=3,192.168.1.1,192.168.1.2
# dns server(s): dhcp-option=6,192.168.1.1,192.168.1.2

Otras opciones útiles, y una es para configurar la dirección del router y otra para configurar la dirección del dns. Activé las opciones y en ambas puse la dirección de la propia fonerame quedó así:

dhcp-option=3,192.168.0.5
dhcp-option=6,192.168.0.5

Y nada después de añadir esas opciones volví a probarlo y... funcionó!! si, funcionó! la conecté al server, dhclient eth1... y 192.168.0.28!! configuró perfectamente mi tarjeta de red. Otro objetivo conseguido.

Bien ya tengo todo lo necesario para el netboot, bueno todo no, me falta preparar los ficheros clave, los que se ejecutaran en el portátil del centro tic y lo dejaran si contraseña. A ver este tema no lo domino mucho, vamos de hecho pienso aprenderlo especialmente para la ocasión, cuando se me ocurrió la idea realmente no tenía ni idea de como llevarla a cabo, sin embargo me puse a investigar el tema y vi lo del servidor dhcp, el tftp y mas o menos los archivos necesarios, pero esa parte no la he visto todavía del todo clara. Me he descargado el paquete netboot.tar.gz de ubuntu (dapper), que contiene los archivos necesarios para hacerlo con ubuntu , yo los adaptaré para que arranquen con mi kernel y mi initrd... en fin para que me sirvan, porque no pienso instalar ubuntu un laptop (a parte no cabe en la fonera). Ah, bueno, también me falta otra cosa a parte de preparar los archivos, se trata de configurar dnsmasq en la parte que le toca este tema, se hace con la línea:

#dhcp-boot=vlan0

Pero como podéis ver no esta terminada la línea (por eso está comentada), pero no la voy a configurar hasta no tener todos los archivos puestos en su sitio.

Bueno os cuento, el archivo netboot.tar.gz que me baje de ubuntu, contiene un par de enlaces simbólicos (a archivos de la carpeta) y una carpeta. La carpeta, ubuntu-installer, tiene i386/ y luego por fin vemos:

boot-screens/
initrd.gz
linux
pxelinux.0
pxelinux.cfg/
pxelinux.cfg.serial-9600/

La primera carpeta contiene los respectivos archivos de texto que te muestran las opciones, cuando vas pulsando f1, f2, f3... explica diferentes opciones que se pueden usar... vamos aparentemente nada útil. Son instrucciones de uso para el que vaya a bootear de esta forma, no para quien quiera hacer su propia versión del tema. Luego tenemos el initrd (initrd.gz) y el kernel (linux), después el archivo clave del netboot, me parece que es el que se tiene que enviar y por tanto configurar el dhcp para ello. Y por último dentro de los dos directorios hay un par de archivos, ambos default, y contienen la configuración de arranque (del kernel) y demás. Hombre no voy a pegar aquí el archivo entero, pero leerlo es un buen ejercicio para comprender como funciona el tema. Yo creo que con eso acompañado con los scripts del cga (y lo que hay en guadalinex) tengo bastante para estudiar bien el tema. Yo he mirado poco, pero el que mas me ha gustado ha sido el de guadalinex 2004, entre el kernel y el initrd son unos 2.5 mb (la mitad de los 5 que tengo). El de ubuntu son mas de 6 o 7 y guadalinex v3 también. Así que lo intentaré con la 2004.

Pero claro ahora queda un aspecto muy importante, donde meto mi script. Tiene que ser un script que se arranque con el kernel, una cosa muy básica que se haga lo mas pronto posible durante el arranque. Simplemente se trata de detectar la partición /, montarla, backup de /etc/shadow, y luego editar la línea de root y quitarle el password, desmontar y se para el arranque, rebooteo, o simplemente halt. El script aún no lo he preparado, mañana lo haré. La parte que queda es donde meter el script. Al principio no tenía idea de donde hacerlo, recordé que yo había arrancado ese kernel con ese initrd en vmware y se me paro en una parte determinada, cuando intentaba conectarse mediante rsync a cierta inexistente en mi red virtual de vmware, por lo que se paraba. Así que monté el initrd (tras descomprimirlo) en /mnt (hablo de mi server, no de la fonera):

gzip -dc initrd.204 > initrd204.img
mount initrd204.img -o loop /mnt

Así que mediante grep busque la cadena rsync en todos los ficheros en /mnt (ergo en initrd.204), y os pondría el resultado pero con la poca anchura de la plantilla de mi blog, el resultado sería bastante malo, así que os lo cuento yo, había varias coincidencias, el propio rsync, en /etc/services, en /etc/init.d/rcS se le menciona en una línea, y en /etc/functions están los comandos completos que se ejecutan. Por lo que deduzco que principalmente es en este ultimo archivo, de hecho he comprobado que ahí están la mayoría de todos los scripts de inicio (por no decir todos), y el archivo /etc/init.d/rcS tengo que examinarlo y averiguar que tiene. Realmente mañana voy a averiguar para que sirven exactamente esos dos archivos, también voy a preparar el script, y lo situaré en la parte óptima de fichero (me interesa lo antes posible para que sea una cosa muy rápida).

Y nada mas, eso son mis progresos, ya os seguiré contando mis avances según vayan teniendo lugar. Y perdón por estos post tan largos, pero prefiero hacer algunas cosas y luego contarlas a hacer una cosa y escribir un post de 4 líneas e incompleto para actualizarlo constantemente cada 5 minutos rompiendo mi ritmo de trabajo constantemente, para eso twitter (que yo no lo uso :D).

Preparando la fonera

A estas alturas todos sabéis que es lo que quiero hacer con mi fonera, podéis ver las ideas aquí y aquí. Bueno el caso que ya tengo la fonera operativa, así que puedo ponerme manos a la obra con el proyecto y empezar a prepararlo todo. Pienso llevar a cabo ambas ideas, aunque tienen objetivos muy parecidos, sin embargo aunque el conseguir que una funcione bien elimina la utilidad de la otra, haré las dos. Como es lógico hay que preparar la fonera de dos formas, una para el primer experimento, y otra para el segundo, porque dispone de muy poco espacio (~5 MB), así que no se pueden hacer las dos cosas a la vez. Lo que pienso hacer es preparar la fonera para una cosa, comprobar que funciona y luego hacer un backup de la memoria flash. Luego flasheo y con la fonera desde cero preparo lo otro y de nuevo hago backup de la flash. Así cuando llegue el curso lo tendré todo listo, solo tendré que restaurar a partir del backup que me interese usar. Pero bueno hemos ido muy lejos, todavía estoy en el principio, os cuento:

Tras flashear la fonera, lo primero que hice fue configurar la red acorde con mi red, es decir, la puse en el mismo rango de ips, configure el gateway, dns y poco mas. Después mi intención era empezar montando el servidor de netboot para conseguir que uno de los portátiles del centro tic arrancara desde el y se quitara el password de root, dejando un backup del fichero original para poder restaurarlo posteriormente. Para conseguir este objetivo principalmente hacen falta 3 cosas, un servidor dchp, un servidor tftp y los archivos que se enviaran a la maquina cliente que requiera el netboot. Para el primer paso me di una vuelta por el repositorio de openwrt, a pesar de que podía haberlo hecho mediante ipkg, su gestor de paquetes, y encontré el paquete dhcp-server, lo instalé: ipkg install dhcp-server. Después intenté configurarlo, edité el archivo de configuración y todos los archivos que pedía, pero no funcionó, no puedo poner textualmente el mensaje de error porque no lo tengo anotado, pero en esencia venía a decir que verificara si había algún otro servicio dhcp, que el recurso ya estaba en uso, mas o menos eso era. Después navegando por el wiki de openwrt, fonera.info y los foros de fon (bueno aquí llegue vía google), encuentro un paquete perfecto, dnsmasq, es exactamente lo que necesito, es un paquete que incluye dns, servidor dhcp, y servidor tftp. Todo lo que hace falta para lograr mi objetivo está ahí. Ya está incluido, por lo que no tuve que instalarlo, lo que si tuve que hacer fue leerme la página man entera, para poder configurarlo correctamente. Dnsmasq por defecto busca la configuración en el archivo /etc/dnsmasq.conf, aunque se puede cambiar, o se puede no usar archivo de configuración, es un programa muy configurable, se adapta a las necesidades del usuario, aunque yo todavía no he podido correrlo. Lo que pasa es que yo entro a mi fonera por ssh a través del puerto ethernet, es decir la fonera está conectada a mi router (por ethernet) y yo desde el portátil me conecto vía wifi a la red inalámbrica de mi router, y conectado vía wifi a mi lan accedo por ssh a la fonera. Esto tiene un inconveniente obvio, a mi me interesa configurar el servidor dhcp para que funcione en la interfaz ethernet ya que será la que conecte a la laptop del centro tic, y si esta en uso conectada al router y enviando y recibiendo datos, puede ser que no funcione el servidor dhcp (como de hecho es), y ademas mi router no piensa pedirle una dirección a la fonera, en todo caso sería al revés. Como ya os he dicho antes no he podido hacerlo funcionar, mi archivo de configuración es este:

# filter what we send upstream
domain-needed
bogus-priv
filterwin2k
localise-queries

resolv-file=/tmp/resolv.conf.auto
dhcp-leasefile=/tmp/dhcp.leases

dhcp-range=vlan0,192.168.1.10,192.168.1.50,255.255.255.0

interface=eth0

enable-tftp
tftp-root=/mnt/tftp

#dhcp-boot=vlan0

Las primeras líneas, tal y como dice ese comentario, son para filtrar lo que se le envía al servidor dns (ahora explico), venían por defecto, y tras leer el man me pareció bien, así que las deje, a pesar de que el dns no es algo a lo que vaya a darle mucho uso, a mi me interesa el dhcp y el tftp. Lo que he dicho antes que iba a explicar, dnsmasq no incorpora realmente un servidor dns (bueno si pero no, según se mire), lo que hace es usar el /etc/hosts como dns "local" y las peticiones dns de otras maquinas se envían al servidor dns que este configurado en el archivo correspondiente, se especifica con el parámetro resolv-file. Después he indicado el rango de ips que quiero que asigne la fonera a los clientes. A continuación defino la interfaz sobre la que quiero que corra. Lo siguiente es el tftp y el directorio que usa. La última línea no la he terminado de configurar todavía, por eso la he comentado, es la que indica los paramétros del netboot, el archivo que se envía...

Bueno esa es mi configuración, y con ella puesta ejecuto dnsmasq pero me suelta esto:

dnsmasq: failed to create listening socket: Address already in use

Y obviamente deja de ejecutarse. Este es el problema que estoy intentando solucionar ahora, la idea que tengo es que a lo mejor no puede funcionar el dhcp porque la interfaz de red eth0 está en uso (de hecho mantiene una sesión ssh conmigo), lo que he pensado para solucionarlo era configurar el wifi (por defecto esta desactivado) en modo ap, para conectarme via wifi a la fonera, y desde su propia red inalámbrica conectarme a ella por ssh para poder controlarla, consiguiendo así tener el puerto ethernet libre, después conectarla a la segunda tarjeta de red de mi servidor e intentar que dnsmasq funcione, de ser así prepararía los archivos para el netboot y luego lo probaría en el portátil, en el sobremesa y en el server, si funcionara haría el backup de la flash, reflashearía y me pondría con el otro experimento (el de ponerla en modo cliente y que scanee de forma autónoma la red tic).

Eso último es la teoría, en la práctica me está resultando mas complejo. He activado el wifi e intenté conectarme, no conseguía ip, tuve que conectarme y asignarme manualmente la ip y ya funcionó. Sin embargo después mirando el archivo de configuración probé con otras opciones y conseguí que asignara dhcp por wifi y me conecté bien, pero a través de la lan cerró el ssh, lo sé porqué via ssh intente conectarme vía ssh vía ethernet a la fonera y no se podía, solo abrío el puerto 22 a la red que daba por la interfaz wifi (sin configuré las interfaces para que fueran por dos redes distintas). Pensé que ya valía así, pero quise ponerle cifrado a la red wifi, opté por lo mas rápido, wep, solo había que cambiar dos líneas, y ademas tampoco me interesaba que fuera la red mas segura, simplemente alejar a los curiosos. Lo hice, rebooteo la fonera (al contrario que firmware de fon, este si rebootea en condiciones, ejecutas reboot y se reinicia, con fon si ejecutabas reboot ya te podías quedar esperando, porque hasta que no desenchufaras/enchufaras no ibas a conseguir nada) una vez reiniciada (cuando comprobé que respondía a los pings, cuando reinicio la fonera ejecuto ping fonera, y al principio muestra sus últimas señales de vida, responde, luego pasa unos segundos muerta y cuando vuelve a responder es obvio que es porque ya está viva) intenté conectarme a la red wifi, pero no podía!! tras muchos intentos me di cuenta que estaba de nuevo en la misma situación al principio, pero esta vez tenía mi as en la manga, podía flashear muy fácilmente, redboot me espera 10 segundos cada arranqué, así que flasheé.

Tras este nuevo "borrón y cuenta nueva" configure de nuevo la red y trasteando con el wifi, la ip, dhcp... me volvió a pasar lo mismo, me quedé de nuevo sin conexión, así que a flashear de nuevo. Está vez tras la configuración básica del la red no toqué nada más. Me he creado un script que recupera la fonera en caso de que yo vuelva a configurar mal la red. Os explico, la configuración del wifi y de la red está en dos archivos, /etc/config/network y /etc/config/wireless, así yo lo que he hecho a sido guardar una copia de seguridad de cada uno de ellos ahora que estan bien puestos, en /mnt. Y la salvación viene por aquí, he creado un script que se ejecuta al inicio que lo que hace es esperar 3 minutos, y después restaurar el backup de los dos archivos. De esta forma yo cuando quiera probar una nueva configuración de la red edito los archivos, hago un backup de ellos (para que luego cuando mi script funcione si los sobreescribe y han funcionado poder tenerlos guardados) y reinicio. Si la nueva configuración ha funcionado podré conectarme a la fonera, si no lo ha hecho simplemente me espero 3 minutos (porque? no se, me pareció una buena cifra) y reinicio manualmente la fonera (con el cable). Así conseguiré de nuevo acceso a la fonera. El script en cuestión es /etc/init.d/test, y su contenido es este (blogger desconfigura los espacios, grrr!):

#!/bin/sh /etc/rc.common
# Copyright (C) 2006 OpenWrt.org

START=50
start(){
sleep 180
cp /mnt/network /etc/config/
cp /mnt/wireless /etc/config
}

stop(){
killall test
}

Con ese sencillo script (y con los backups) conseguiremos no tener que volver a flashear por culpa de una mala configuración de la red. Por cierto he comprobado que funciona bien, a los backups les añadí un comment (#test) reinicié espere los 3m y efectivamente mis ficheros network y wireless cambiaron, ahora tenían el comment. Por último decir que para que funcione el script hay que darle permisos de ejecución y habilitarlo:

chmod +x /etc/init.d/test
/etc/init.d/test enable

Y ya no me acuerdo de mas cosas que haya hecho, he estado leyendo todo lo que he encontrado acerca de openwrt y de la fonera y espero que esto vaya progresando.

Ya funciona la fonera!!!

Como sabéis estos últimos días he estado haciendo alguna cosilla con el LFS y también tenía pendiente la reparación de la fonera, ya que con ella pensaba desarrollar mi principal proyecto del verano. Bueno los que seguís el blog sabéis la historia de mi fonera, la flasheé, para hacer con ella algunas cosas en el centro tic, pero luego la deje sin conexión, desconfiguré la red y la deje totalmente aislada, pero podía recuperarla utilizando el cable serie que o bien lo montaba yo mismo, cosa que no fui capaz de hacer, o bien lo compraba montado, que también lo hice. Sin embargo cuando llegó intente usarlo pero fracasé y creo que fue debido a mi gran habilidad para soldar. Entonces ya la dejé abandonada una temporada... hasta ayer.

Lo que pasa es que hablando en el irc Uticox me preguntó por mi fonera, le dije que seguía bricked, que yo ahora estaba con el LFS, el me respondió que yo hacía muchas cosas pero no acababa ninguna y que el que mucho abarca... Y lleva toda la razón del mundo, la fonera que era mi gran proyecto para el verano lo había dejado simplemente porque había surgido un problemilla que no fui capaz de solucionar tras varios intentos, así que le dije, hoy estoy con el LFS y quiero seguir con él, pero mañana mismo me pongo con la fonera y la arreglaré. Bueno cuando llego "mañana" (antes de ayer) no seguí con la fonera, porque estuve en la playa y luego por la tarde salí un rato y luego quería leerme los feeds del día. Pero ayer si que cogí la fonera y dije de hoy no pasa, hoy la arreglo, y si no me pongo a trabajar con ella hasta que funcione, no puede ser que yo no pueda repararla. Así que cogí los materiales electrónicos, la fonera, el cable serie, y el manual para conectarlo todo.

Cuando fui a empezar ya tuve el primer problema, los pines que hay que soldarle al circuito estaban mal soldados, a parte de que la soldadura tenía un aspecto muy feo, tenía algunas grietas, y un pin estaba soldado junto con el de al lado, por poquísimo, pero hacía contacto, así que nada a quitar todo esto y a soldarlo de nuevo. Bastó con mover un poco los pines para que todo el estaño se despegara, se rompiera y se cayera (podéis imaginaros la calidad de mi soldadura xD), así que nada a soldar de nuevo, cogí el estaño y un soldador, pero antes de usarlo busqué un manual de como soldar, ponía que hay que calentar el componente y poner el estaño al lado, para tratar de que sea el componente quien derrita el estaño. Así que nada lo intento, pero mas problemas, espero, espero, sigo esperando, pero no soy capaz de recrear lo que pone en el manual, se ve que el soldador sera muy malo y no se calienta lo suficiente. Entonces recuerdo que en casa hay dos soldadores, voy a buscar el otro... y lo intento de nuevo, pero este se calienta demasiado!! pongo el soldador tocando el pin y por el otro lado del pin pongo el estaño para que se derrita cuando el pin tenga la temperatura adecuada, pero entonces empieza a oler a quemado y el pin se mueve, hasta el punto de se sale, le doy la vuelta al circuito (lo tenia bocabajo para soldar) y veo que el plástico negro que une los 6 pines esta deformado y un poco quemado. Y ahora que hago? un soldador no calienta y el otro calienta demasiado...

Intenté practicar con cables, si, soldando cables, y salía mas o menos bien. Intenté de nuevo con el circuito, cogí seis pines nuevos (porque los otros ya era para tirar), pero tampoco fue bien, con el primer soldador no había manera, no se llegaba a calentar lo necesario (pero si le ponía el estaño directamente en la punta lo fundía al instante), probé con el otro de nuevo, pero con intención de ponerlo muy poco tiempo para que lo pines no se derritieran, fracasé.

Cambio de estrategia, si no soy capaz de hacerlo por hardware vamos a seguir intentándolo por software. Se me ocurrieron varias cosas, pero para empezar la conecté al router y la enchufé, porque a lo mejor por algún fenómeno físico-cuántico la fonera funcionaba bien. Ahora paso una cosa un poco rara, la fonera creo una red inalámbrica abierta con essid OpenWrt, me conecto a ella y tengo acceso a internet, un traceroute para que ver que pasa y WTF! lo primero que aparace es mi router (192.168.0.1), intento conectarme a mis otras máquinas y puedo perfectamente, tengo acceso a mi red local, es decir, que la fonera es un puente invisible entre mi router y yo. Próximo paso? pues se me ocurren dos cosas una muy sencilla, y otra mas compleja, la primera es conectar la fonera a mi laptop y snifar a ver que pasa, la otra es montar una segunda tarjeta de red en mi server y convertirlo en un router, el plan es que mi server este conectado al router y a la fonera, y que el trafico de la fonera lo pase por la otra tarjeta de red hasta el router y de ahí a internet. La parte interesante es que la fonera creara su red OpenWrt, yo me conectaré a ella con la laptop navegaré un poco y todo el tráfico pasara por mi server, donde podré snifarlo todo y ver que huellas deja la fonera en los paquetes tcp, si tuviera un router con linux no tendría tantas complicaciones... Siguiente problema: no se como convertir mi server en un router, así que al amigo google y a buscar un poco. Pero en ese momento recordé que en fonera.info hay un tutorial de como recuperar una fonera mal flasheada, y pensé que mejor releerlo antes de seguir con este complejo (y seguramente inútil) plan. Leo que redboot puede iniciarse al arranque y esperar una conexión durante unos segundos y luego seguir con el arranque normal (redboot se usa para flashear la fonera). Pero chicos, se hace tarde, mañana por la mañana comprobaré si mi fonera arranca el redboot e ese modo, en cuyo caso podré reflashearla y asunto solucionado!

Hoy cuando me he levantado, como de costumbre me acerco enciendo el router, y el servidor, pero esta vez también cogí la fonera, el alimentador, y un cable cruzado. Me tiro en el sofá con el portátil, lego poco los feeds y luego ya me dispuse a probar lo de la fonera. Configuro mi tarjeta de red ethernet con ip 192.168.1.166, netmask 255.255.255.0 y sin gateway. También desactive el wifi para evitar problemas. Después conecto la fonera al portátil con el cable cruzado, abro un terminal con dos pestañas y en una pongo ejecuto un ping a 192.168.1.254 y en la otra dejo preparado un telnet 192.168.1.254 9000 para ejecutarlo en cuanto esa ip responda al ping. A continuación conecto la fonera a la corriente eléctrica, y al poco empiezo a ver que responde a los pings! raudo y veloz ejecuto el telnet y se conecta, pero me suelta un bonito mensaje:

== Executing boot script in 8.723 seconds - enter ^C to abort

Yo no se exactamente a que se refiere con ^C, pero yo lo interpreté como crtl+c, no sirvió, lo intenté de nuevo y tampoco valió para nada. Entonces, como en todos los manuales hablaba de putty, decidí intentarlo con putty, y esta vez el resultado fue diferente, el propio putty se encargó del tema, esto fue lo que apareció en el terminal de putty:

== Executing boot script in 8.723 seconds - enter ^C to abort
^C
RedBoot>

Ya tenía el prompt de reboot!! y yo todavía conservo el servidor tftp en mi portátil, el mismo que monte en su día cuando la flasheé por primera vez, y en el todavía tengo los archivos necesarios para el flasheado, así que comencé a introducir los comandos y tras un rato ya tenía la fonera flasheada de nuevo con openwrt. Sobre como flashearla ya escribí un post.

Una vez se ha acabado el flasheo hay que reiniciar la fonera y conectarse por telnet a la ip 192.168.1.1, y tendremos una shell de la fonera, en la cual hay que setear un password para root y partir de ahí las próximas conexiones serán por ssh. Mi problema ahora fue que no podía contactar con 192.168.1.1, y acaba de flashear! bueno tras varios intentos fallidos volví a flashear y tampoco podía conectar de ninguna forma con la fonera, pero entonces puse el wireshark a funcionar y reinicié la fonera, después vi que la fonera preguntaba por 192.168.1.254, y entonces pensé, y si me pongo esa ip, al mejor ya puedo conectarme a ella, lo hice y funcionó, hice el telnet, le puse el password y volví a reiniciar, ahora para probar que todo estaba bien conecté por ssh a la fonera y funcionó, por último configure una cosa, la ip de la fonera, porque mi red no está en ese rango, así que le puse la que le correspondía, 192.168.0.5, apago, la conecto al router y ya es visible para toda mi red. Ya funciona bien, y lo mejor no es eso, lo mejor es que aunque se me vuelva a estropear, lo puedo solucionar de la misma forma, porque redboot esta configurado para escuchar durante el arranque en la ip 192.168.1.254 puerto 9000 durante 10 segundos, así que si me vuelvo a cargar el sistema operativo puedo reflashear con toda la tranquilidad del mundo y sin cable serie!!! Por cierto quien quiera conseguir esto que lea este tutorial (aunque a mi tras flashearla la primera vez se me puso esa configuración): Configurar el Redboot para poder entrar por telnet

Bueno ya para acabar comentar que la inactividad de los últimos días ha sido por culpa de la playa, de los cazadores de mitos, de alguna salida, y del lfs. Ahora espero estar ocupado con la fonera, os iré contando mis avances con ella. Y el LFS para cuando este lista la fonera, porque no esta de mas recordar que era un proyecto de "relleno" para entretenerme mientras no tenía fonera.

El meme de las ocho cosas

Desde Vidas en red me llega un meme, así que vamos a responderlo :)

Reglas:
A. Cada jugador comienza con un listado de 8 cosas.
B. Tienen que escribir esas 8 cosas en su blog y junto con las reglas del juego.
C. Tienen que seleccionar a 8 personas mas invitar a jugar y anotar sus nombres o el nombre de su blog.
D. No Olviden dejar un comentario en sus blogs respectivos de que han sido invitados a jugar, refiriendo al post de tu blog “EL JUEGO” o “El meme de las 8 cosas”

Amor: Ya llegara el mio... si alguna geek en la audiencia que sepa que estoy soltero :D

Los videojuegos: Pocos, tipo GTA, y a veces alguno de simulación.

Lectura: No leo casi nada, algunos libros técnicos que tardo mucho tiempo en terminar, y literatura muy poca. Si vas a regalarme algo mejor algún gadget.

La vida: Muy corta y muchas cosas que hacer.

Mi pelo pantene: Negro.

Dinero: Útil y necesario, pero por ahora no tengo que ganarmelo.

Trabajar: Ya lo haré cuando sea necesario... ahora con los estudios hay bastante...

Alimentación: Chocolate.

Se lo paso a... no se, a cualquiera que lea esto y quiera seguirlo, porque la verdad no se quien de mis lectores es blogger.

Seguimos con el centro tic (sin fonera)

Perdonar por no haber posteado en tantos días (desde el lunes), pero es que los astros se han alineado para que no me haya sido posible, bueno tonterías a parte, lo que ha pasado es que esta semana entre playa, alguna que otra quedada y adicción a Cazadores de Mitos no he hecho nada relativo a la informática (bueno los dos últimos días si), ni a la fonera, ni a nada, estos días solo he leído los feeds en google reader, descargado alguna cosilla y poco más, así que no tenía nada que contar.

Sin embargo si hay dos o tres cosillas que contaros, básicamente actualizar la información sobre el estado de mis proyecto y contaros una idea que se me ocurrió ayer.

Vamos a empezar por lo primero, la fonera no la he tocado, todavía sigue exactamente igual de inútil, seguramente hoy haga algún intento más, sobre el script para rapidshare... pues tampoco lo he hecho, al final descargué todas haciendo el proceso a mano, cuando acababa una descarga cambiaba la ip y descargaba la siguiente. De todas formas todavía no he acabado porque algunos enlaces estaban mal puestos, por ejemplo ponía que era el programa 2x14 y en realidad era el 2x13, así que tengo que descargar dos o tres capítulos de nuevo (buscare otra fuente) además de alguno que no estaba en la lista de enlaces. Y creo que ya no hay mas cosas pendientes, así que vamos con otro tema, mi última idea:

Pensando en mi centro tic recordé un viejo proyecto que tenía respecto a él, montar un servidor f0 en mi red lo mas parecido posible al del instituto para hacer instalar después en una maquina virtual un sistema igual al que tienen las laptops del centro tic, es decir hacer netboot en la maquina virtual y luego instalar el sistema a partir de la imagen del servidor. Para ello yo contaba con algunos scripts que se encuentran en el ftp de f0, scripts interesantes que son sobre la instalación del sistema, sin embargo con eso no es suficiente además en e mismo ftp había un repositorio, en cuya carpeta dist había una carpeta llamada breezy, por lo que se deduce que es un repositorio de ubuntu breezy (seguramente con algunos paquetes especiales). Entonces el primer paso que se me ocurrió dar fue montar un repositorio en mi servidor, porque con un solo script no vamos a ningún lado, hace falta también los paquetes que instalar, y que mejor sitio para obternerlos que nuestro repositorio, así que nada busqué un poco como montar un repositorio, leí algo sobre apt-mirror, pensé en copiar un repositorio con wget... pero entonces llegó la solución mas sencilla, mirando la web del repositorio oficial de guadalinex, vi un link que pone las normas para hacer un mirror oficial... tener un servidor con capacidad, 1mb/s, ftp/http... pero lo mas interesante es la parte que pone como conseguir los datos para el mirror, la forma es mediante rsync, la url es esta: rsync://pool.guadalinex.org, y ahora copy&pasteo una parte:

Al conectar con las URL's especificadas arriba podrán verse los directorios que pueden sincronizarse. El contenido es el siguiente:

/guadalinex-toro: Repositorio de la versión 4 de Guadalinex (~1,5 GB)
/guadalinex-flamenco: Repositorio de la versión 3 de Guadalinex (~3 GB)
/guadalinex-descargas: Contiene ficheros relativos a Guadalinex como imágenes ISOs, documentación, portadas, etc.
/guadalinex: Repositorio de las versiones 1.0 y 2004 de Guadalinex (~31 GB)
/mirror: Mirror congelado de Debian usado en las versiones 1.0 y 2004 de Guadalinex  (~38 GB)
/ubuntu: Mirror de Ubuntu en sus versiones breezy, dapper y edgy. Utilizado por las versiones 3 y 4 de Guadalinex (~85 GB) 

A mi lo que me interesaba era ubuntu así que creé en mi server un directorio para el objetivo, /media/almacen/repo, y luego ejecute el comando adecuado para la sincronización de directorios: rsync -av --stats pool.guadalinex.org::ubuntu /media/almacen/repo. Lo tuve dos días sincronizando (en total conseguí unos 5 o 6 GB), y ya me extrañó un poco que tardara tanto y recordé que en el wiki de guadalinex pone cuando pesa cada directorio del repositorio
y vi que eran 85 GB!!! entonces cancelé la operación y borre lo hecho porque antes de esa pequeña descarga prefería investigar otras cosas. Pensé que antes de correr la instalación y deja que instalara en la maquina virtual lo que le diera la gana, que descargara del repositorio lo que quisiera... sería mejor, mas constructivo y me serviría para aprender más investigar todos y cada uno de los archivos de instalación, mirarlo todo, y ver paso a paso que va a hacer durante la instalación en cada instante. Entonces lo que hice fue leer los 4 o 5 scripts que descargué en su día de ftp://f0. Vale cuando acabé no saque nada muy útil, crea las particiones, se conecta al server, configura apt y llama un par de scripts, uno de ellos llama otro que detecta la tarjeta de red que se usa, otro detecta la gráfica. El que detecta la gráfica lo único que hace es ver si tiene nvidia, y si es así instala el paquete mediante apt-get el paquete cga-portatil-toshiba (por eso dije lo de paquetes especiales en el repositorio). El de detección de red detecta la interfaz de red y la configura adecuadamente, por cierto en este archivo también esta la clave wpa de la red y essid de la red, channel, en fin aquí esta todo lo que se puede encontrar en /etc/network/interfaces, así que aunque se le quiten permisos de lectura (que los tenía, de hecho yo lo copié y conseguí la clave wpa), se pueden seguir leyendo esos datos, ya que este script de detección de red es público, está en el ftp de f0 y puede acceder cualquiera. Bueno así a grosso modo los scripts no hacen nada más... eso es poca información, yo tengo constancia de que para hacer la instalación en red de guadalinex en el centro tic hay tres formas (o cuatro, según se mire), mediante netboot (pxe) con un servidor que lo proporcione todo, desde un cd mínimo de arranque que proporciona un kernel y la configuración para conectarse al server f0 y obtener los famosos script para la instalación, y por último mediante un pendrive bootable, pero este método que yo sepa no sirve con las laptops (o al menos yo no conseguí en su día arrancar por usb, bueno este método tiene dos variantes, el pendrive puede ser con grub o con syslinux. El problema es que yo solo tenía a mano la imagen del cd, pero también quiero examinar las imagenes del usb, así que me fui a la guía para centros tics y en el anexo sobre como hacer la instalación en red pone como conseguir las imagénes para cualquiera de los dos métodos, así que descargué las dos imágenes para pendrives (la de grub y la de syslinux).

Vamos a empezar a analizar los métodos por el principio, el de netboot no puedo hacerlo, porque no tengo el servidor tftp con los archivos adecuados, así que nada este método de entrada tengo que descartarlo.

El método del cd, hmmm, este tiene buena pinta, lo primero que hago fue montar la imagen del cd en un directorio multiusos (uno que tengo reservado para este tipo de experimentos) /media/test, y me encuentro con un par de kernels y con un par de initrd's. También hay un archivo útil, isolinux.cfg, con la configuración de arranque, el cd cuando arranca ofrece un prompt y le tienes que poner la palabra clave adecuada para la acción que quieras, las posibilidades son Instalav3, Instala, Actualiza, Instalatoshiba y Actualizatoshiba. Con el kernel linux.v3, solo arranca la primera opción, se deduce que es la única para instalar guadalinex v3. Todas las demás van con linux.204, seguramente será para guadalinex2004. La primera opción configura algunas cosas y apunta al script ftp://f0/install.cfg, a partir de ahí ya he leído los scripts, un vistazo rápido a las siguientes opciones muestra que clarisimamente es un kernel compilado por quién se haya encargado de crear guadalinex, porque no creo que el CGA haya creado un nuevo kernel para guadalinex, que puede, pero no lo veo... Esta última deducción la hago en base a los parámetros que se le pasan al kernel: actualiza, imagen=guadalinex2004-act1-wifi y imagen=guadalinex2004-act1-toshiba2. Además hay un directorio en el cd, se llama i386, luego standard/, y por último hay un archivo: boel_bin.tgz. Vale, y ahora que hacemos? pues a mi se me ocurrió examinar los initrd, no se si iba a servir para algo, pero lo hice, primero tenemos que descomprimirlo, y luego montar el archivo en algún directorio:

gzip -dc initrd.v3 > /home/neobius/ies/netb/initrdv3.img
mount /home/neobius/ies/netb/initrdv3.img /media/test2 -o loop

Vale hecho, ahora me fui al directorio donde estaba montado y estuve mirando que había, la verdad es que no encontré nada útil, aunque también es verdad que ni miré mucho ni sabía muy bien que mirar. Hice lo mismo con el initrd.204 pero tampoco me valió para nada.

Entonces me acorde del aquel fichero tgz que estaba en la única carpeta del cd, así que lo copio a mi directorio de trabajo, y lo descomprimo. Contiene varios directorios (etc, usr, bin, lib y sbin), y dentro de ellos había algunos ejecutables, librerías y un archivo de configuración de ssh. Vale muy bien, pero tampoco me ha servidor para nada.

El siguiente paso que se me ocurrió fue arrancar el cd en una maquina virtual y probar las distintas opciones para ir viendo el arranque a ver que pasaba. La primera opción no la use porque ya se lo que pasa, probé todas las demás y a primera vista los arranques de todas las otras opciones son iguales, o al menos iguales hasta el punto en el que se para, y se para porque intenta hacer un rsync a una dirección que no existe en mi red. Transcribo:

rsync -av 192.168.4.254::/boot/i386/standard/boel_binaries.tgz /tmp/boel_binaries

Por ahora hemos acabado con el cd, que de todas formas me ha dado algo de información, ahora mismo mi lista mental de cosas que tengo en el centro tic es conectarme por tftp a f0 pero realmente no se para que, porque que yo sepa este protocolo no tiene ningún comando para listar los archivos del servidor (vamos un ls), la otra cosa que tengo que hacer es probar el rsync a los dos servidores y a la dirección arriba puesta, bueno realmente la lista es mas larga, pero las cosas nuevas que se me han ocurrido son esas dos.

Ahora vamos con el usb, ambos archivos era imágenes que hay que copiar mediante dd al pendrive, así que cogí un pendrive de 256 mb que tengo por aquí e hice la operación con el de syslinux, había cuatro archivos: initrd, ldlinux.sys, linux y syslinux.cfg. Esto lo que hace es lo mismo que la primera opción del cd, instala v3 de la misma forma.

Entonces probé con la otra imagen, la de grub, la copie mediante dd:

dd if=llavero_arranque_grub.iso of=/dev/sdb

Y luego le echamos un vistazo, hay una carpeta boot, que ahora veremos y sorprendentemente hay otra carpeta, pero no una carpeta cualquiera, una carpeta que proporciona un nombre de usuario (y parte de uno real), no voy a poner el nombre entero, pero ese así: .Trash-xxxxxx, vamos que el usuario que creo esta imagen borró un archivo pero no su carpeta .Trash. Por cierto xyyyyy es así: x es la inicial del nombre e yyyyy el primer apellido. El archivo que hay dentro de esa carpeta es ESFW30.BIN, que la verdad no se que es.

Dentro de la carpeta i386 nos encontramos varios archivos: initramfs, initrd, linux y vmlinuz. Ademas de una carpeta, grub. Con un menu.lst, cuanto menos curioso, os pongo los títulos de cada una de las entradas:

EducaTICC USB normal
EducaTICC USB configuracion limpia
EducaTICC USB montar dispositivos escritura
EducaTICC USB qemu
EducaTICC USB modo texto
Instalar Guadalinex V3 especial para centros TIC
Guadalinex USB qemu con param. extend

Las dos últimas si tienen los mismos parámetros que el v3 del cd, llama al install.cfg de f0. Lo de EducaTICC es la primera vez que lo leo, luego arrancare el pendrive a ver que hace.

Ya no he hecho nada mas, he sacado algunas conclusiones, [¿]xyyyy trabaja en el cga[?], aunque realmente eso no me vale para nada. He aumentado la lista de cosas que tengo que hacer cuando me siente delante de un portátil del centro tic (rsync, tftp) y que necesito aprender mas sobre linux, porque, por ejemplo, durante el arranque del cd netinstall, de vez en cuando suelta algunos mensajes, y ejecuta algunas cosas, esas cosas yo no se donde se configuran, así que solo me queda una opción: LFS. Si voy a meterme en el proyecto lfs, acabo de bajarme el pdf y vy a leerlo, tengo que aprender mas, y ademas eso creo que me vendrá bastante bien el día que arregle la fonera y la prepare para que los portátiles puedan bootear desde ella, a ver cuando la arreglo... porque es la base de mi plan, tengo que hacerla funcionar.