Error en la fonera

Ayer sometiendo a la fonera a una batería de pruebas detecte un par de errores, uno de ellos es que empieza antes de tiempo a ejecutarse, la comprobación que puse en el script no funcionaba como debía, porque a veces esa condición (estar asociado al access-point) se cumplía y todavía la fonera no tenía ip, por lo que los scaneos a f0 (el primero en ser scaneado) eran erróneos, ya que la conexión no era posible aún. Y como los sucesivos scaneos a f0 se basan en el primero (para ahorrar tiempo) todos los datos sobre f0 eran inválidos. Hablo de esto:

while [ -e $(iwconfig ath0 | grep Not_Associated)];
do main
exit;
done

El segundo problema era en el "scaneo de versiones" de nmap (nmap -sV) y es que yo mediante un bucle for intentaba pasarle solo los puertos que nmap detectó abiertos al principio, pero como ese mismo trozo de código se usa para el scaneo a c0, la variable que almacena los puertos a scanear está "contaminada" del scaneo anterior, por también hice que se limpiara la variable antes de usarla, pero lo puse en mal sitio, dentro del bucle for, entonces lo que hacia era acabar con un único puerto, el último. El código erróneo era este:

for i in $(grep ^[0-9] $FILE'.nmap' | cut -d"/" -f1);
do
PUERTOS=""
PUERTOS="$PUERTOS$i,";
done

La solución al segundo problema es obvia, simplemente poner la tercera línea antes del for. El otro error si me ha tenido mas atareado estuve ayer probando de todo y no funcionaba, aunque eso si al final lo he conseguido arreglar. La idea era que yo tenía era sencilla, en vez de comprobar con iwconfig que estaba asociado al AP, debía comprobar con ifconfig si ath0 tenía dirección ip. Como no sé que ip tendré no puedo basarme en un numero para hacer la comprobación, pero si hay otras cosas que me pueden valer. Antes de obtener ip por dhcp al ejecutar ifconfig ath0 devuelve algo parecido a esto:

ifconfig ath0
ath0 Link encap:Ethernet HWaddr 00:18:84:10:B5:9D
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:116 (116.0 B) TX bytes:0 (0.0 B)

En cambio cuando ya esta conectado con su ip devuelve esto otro:

ifconfig ath0
ath0 Link encap:Ethernet HWaddr 00:18:84:10:B5:9D
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1531 (1.4 KiB) TX bytes:1651 (1.6 KiB)

Blogger como de costumbre deforma las cosas, se supone que al principio de cada linea hay unos espacios. También comprobé que por alguna extraña causa el supuesto bucle while no funcionaba como yo esperaba y a pesar de cambiar lo del iwconfig por lo de ifconfig no conseguí que funcionase bien. Me di cuenta de que necesitaba until en vez de while, pero tampoco me funcionaba. Pensé en hacer una función recursiva, que comprueba si tiene ip, si la tiene ejecuta main y si no la tiene se llama a si misma de nuevo y así hasta que tuviese ip y se ejecutara main. En algo fallaría porque tampoco conseguí llevarlo a la práctica.

Finalmente puse esto:

START=$(ifconfig ath0 | grep "inet addr" | cut -c11-15)
while [ "1" == "1" ];
do
if [ $START == "inet" ];
then date >> /mnt/logs/date
main;
else
START=$(ifconfig ath0 | grep "inet addr" | cut -c11-15);
fi;
done

Traducido: mientras 1 sea igual a 1 (siempre :P) comprueba si $START es igual a "inet", condición que solo se cumplirá si ath0 tiene ip, en caso afirmativo apunta la hora y luego ejecuta la función principal (main) y cuando ésta acabe se acaba el script (eso lo he añadido a la función main), si la igualdad no se cumpliera se reasignaría el valor de $START y se repetiría todo, así hasta que fuera afirmativo y se ejecutara main.

Con esos cambios el script queda así (también lo he puesto aquí):

#!/bin/bash
date > /mnt/logs/date
F0=192.168.0.1
C0=192.168.0.2
TARGET=$F0
FILE="/mnt/logs/f0"
START=$(ifconfig ath0 | grep "inet addr" | cut -c11-15)

x0scan() {
PUERTOS=""
nmap -sT -n -p- -oA $FILE -P0 $TARGET
amap -A -bvq -i $FILE'.gnmap' -o $FILE".amap"
for i in $(grep ^[0-9] $FILE'.nmap' | cut -d"/" -f1);
do
PUERTOS="$PUERTOS$i,";
done
nmap -sV -n -P0 $TARGET -p $PUERTOS -oA $FILE'v'
TARGET=$C0
FILE="/mnt/logs/c0"
}

main() {
ifconfig -a > /mnt/logs/ifconfig
iwconfig > /mnt/logs/iwconfig

x0scan
x0scan

#routes and other scans
nmap -sL 192.168.0.1-255 -oA /mnt/logs/dnsscan
nmap -sP -PR 192.168.0.1-255 -oA /mnt/logs/arpping
nmap --iflist -oN /mnt/logs/nmaproute
traceroute f0 > /mnt/logs/trace
traceroute c0 >> /mnt/logs/trace
traceroute 64.233.183.104 >> /mnt/logs/trace

#dns zone transfer
host -l dominio.es 192.168.0.1 > /mnt/logs/dnstransfer
date >> /mnt/logs/date
tar -czvf /mnt/logs/logs.tar.gz /mnt/logs/*
wput /mnt/logs/logs.tar.gz ftp://user:pass@neobius.es
exit
}

while [ "1" == "1" ];
do
if [ $START == "inet" ];
then date >> /mnt/logs/date
main;
else
START=$(ifconfig ath0 | grep "inet addr" | cut -c11-15);
fi;
done

Sin embargo todavía nos faltan un par de cosas por hacer que no hice cuando acabe el último post, tenemos que hacer que el script se ejecute al inicio, y como es lógico mejor si es después del wpa-supplicant. Este último ya lo configuramos, en mi caso use el archivo /etc/init.d/test. Tras hacer pruebas para que el script se ejecute al inicio me di cuenta de una cosa, todo lo que iba después del wpa supplicant no arrancaba, si ponía mi script tras él, no funcionaba. La solución fue sencilla, viendo el manual de wpa-supplicant vi una interesante opción:

-B = run daemon in the background

Correr el demonio en background! era justo lo que necesitaba, así que le añadí la opción al archivo de inicio y ya está:

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

START=50
start(){
wpa_supplicant -dd -D wext -c /etc/wpa_supplicant.conf -i ath0 -B
}

stop(){
killall test
}

Esta parte esta lista, ahora el script en si, yo lo he hecho a través del fichero /etc/init.d/script, con este contenido:

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

START=51
start(){
sh /mnt/backup/script.sh > /mnt/logs/dump
}

stop(){
killall script
}

Ejecuta el script después de haberse ejecutado wpa-supplicant y además guarda como log el resultado de la ejecución en /mnt/logs/dump, por si hubiera algún error al ejecutar un comando que no se guardara en los logs independientes que guardará cada uno de los comandos.

Además de eso he hecho dos cosas más deshabilitar del inicio automático cron y dnsmasq, cron simplemente porque no lo uso y dnsmasq porque si la pongo en modo cliente y dnsmasq está corriendo no me funciona el dns. Para ello simplemente hay que quitarle los permisos de ejecución:

chmod -x /etc/init.d/cron
chmod -x /etc/init.d/dnsmasq

Y por último he hecho otro cambio, la conexión ethernet la puesto con dhcp porque si la dejo estática crea una ruta fija y si luego se conecta por wifi y tiene otro rango de ip o simplemente el router tiene una dirección diferente de la especificada se producirá un conflicto de rutas y los paquetes no tendrán muy claro por donde ir, vamos que la conexión fallará casi seguro. Así he cambiado mi fichero /etc/config/network y lo he dejado así:

config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0

config interface lan
option ifname eth0
option proto dhcp

config interface vlan1
option ifname ath0
option proto dhcp

Con todo esto ahora si puedo afirmar con seguridad: la fonera está lista. Ya lo he probado de todas las maneras posibles y ha funcionado así que el día que vaya al instituto no debería haber ningún problema, a no ser que falle la propia red del instituto.

PD: Hay algo que me hace sospechar que puede no funcionar del todo bien, la web de mi instituto da un 404 así que a lo mejor están haciendo cambios en el servidor, vamos a ver como sale el experimento...

El script de la fonera

Como ya os he dicho todo esta listo para el primer día (bueno todo no, tengo que comprar pilas :P ). Esta es una importante parte del puzzle, pero creo que al final ha quedado mas o menos bien, antes contar nada os pongo el script y luego os comento, por si aquí no se ve bien también lo he puesto en mi servidor, aquí:

#!/bin/bash
date > /mnt/logs/date
F0=192.168.0.1
C0=192.168.0.2
TARGET=$F0
FILE="/mnt/logs/f0"

x0scan() {
nmap -sT -n -p- -oA $FILE -P0 $TARGET
amap -A -bvq -i $FILE'.gnmap' -o $FILE".amap"
for i in $(grep ^[0-9] $FILE'.nmap' | cut -d"/" -f1);
do
PUERTOS=""
PUERTOS="$PUERTOS$i,";
done
nmap -sV -n -P0 $TARGET -p $PUERTOS -oA $FILE'v'
TARGET=$C0
FILE="/mnt/logs/c0"
}

main() {
ifconfig -a > /mnt/logs/ifconfig
iwconfig > /mnt/logs/iwconfig

x0scan
x0scan

#routes and other scans
nmap -sL 192.168.0.1-255 -oA /mnt/logs/dnsscan
nmap -sP -PR 192.168.0.1-255 -oA /mnt/logs/arpping
nmap --iflist -oN /mnt/logs/nmaproute
traceroute f0 > /mnt/logs/trace
traceroute c0 >> /mnt/logs/trace
traceroute 64.233.183.104 >> /mnt/logs/trace

#dns zone transfer
host -l dominio.es 192.168.0.1 > /mnt/logs/dnstransfer
date >> /mnt/logs/date
tar -czvf /mnt/logs/logs.tar.gz /mnt/logs/*
wput /mnt/logs/logs.tar.gz ftp://user:password@neobius.es
}

while [ -e $(iwconfig ath0 | grep Not_Associated)];
do main
exit;
done

Explico, al principio del script defino unas variables, c0, f0, target, y file. Se que las dos primeras podría haberlas omitido, pero he preferido dejarlo así, esas dos indican las ips de los servidores c0 y f0. La variable $TARGET indica a quien se va a scanear, y $FILE el prefijo para lo nombres de los archivos logs.

El script esta dividido en funciones, la función main y la función x0scan, además también hay un bucle que comprueba si la fonera se ha conectado a la red inalámbrica y hasta que no lo haya hecho no se ejecuta nada mas.

Lo primero que se hace es esa comprobación, que es mediante las ultimas líneas del script, con el while, cuando se ejecuta iwconfig si no esta conectado pondrá Not_Associated, si lo pone sigue esperando hasta que deje de ponerlo y si no lo pone llama a la función main y se acaba la comprobación.

La función main guarda en un log la configuración de la red y del wifi (ifconfig y iwconfig), a continuación llama dos veces a la otra función, x0scan.

x0scan se encarga del scaneo a los servidores, de ahí su nombre (los servidores son f0 y c0). Empieza con nmap, analizando con sondeos TCP los 65535 puertos del servidor f0, sin enviar ping previo y sin búsqueda inversa dns, estas medidas son para ahorrar tiempo. Todo se guarda en logs en todos los formatos (3), he elegido todos porque todos tienen sus ventajas. Lo siguiente es amap, analiza todos los puertos que nmap ha encontrado abiertos y guarda el correspondiente log, todo se registra.

También he averiguado leyendo el manual de nmap que éste también puede detectar que servicio corre y su versión, así que también se ejecutará, ya que es mejor tener dos resultados que uno. Solo se ejecutará a los puertos que nmap haya detectado abiertos al principio, para nuevamente ganar tiempo. Por último, se cambia el contenido de las variables $TARGET y $FILE para así poder ejecutar de nuevo la misma función pero hacia el servidor c0.

Tras ejecutar nuevamente x0scan, la función main busca host a través de dns en el mismo rango de ips que los servidores, quizas los routers o algo tengan nombres. Luego busca hosts vivos a traves de pings arp, he elegido pings arp porque puede ser que los pings icmp estén bloqueados por algún firewall.

Nmap guarda también las rutas que usa, me valdrá para conocer la ip de un router. También ejecuta 3 traceroutes, a c0 a f0 y a google.es (he puesto la ip por si me falla el dns), confío en que me valga para trazar un mapa aproximado de la red, que espero ir perfeccionando según tenga los datos.

Pero esto todavía no ha acabado, ahora toca intentar una transferencia de zona dns. Este proceso se hace cuando un servidor dns secundario pide al primario toda la información que tenga sobre un dominio para así actualizarse, pero a veces no esta restringido a ese servidor secundario y cualquiera puede hacerlo, así que también voy a intentar esto.

Por último y por simple seguridad, para tener un backup, se crea un tar.gz con todos los logs y lo envía por ftp a mi cuenta en el servidor de 1and1.es. Obviamente no usaré mi usario normal, he creado uno especial para la ocasión con acceso a un directorio determinado en el que no hay nada, protegido de acceso http y al que cambiaré la contraseña (no me he complicado con ella, es un solo uso...). Todo esto es por si a los del CGA les da por poner un sniffer que es muy fácil coger el password... Pensé en hacerlo con scp o con sftp, pero no, porque no se como pasarle el password de forma automática.

La idea inicial también incluía snifar un poco, pero al final no lo voy a hacer en esta primera conexión, ya pensaré cuando y como lo hago.

Ah! y otra cosa que se me pasó decir antes, también apunta la hora a la que empieza y la hora a la que acaba, que aunque la fonera no esté en hora sirve para saber cuanto tiempo tarda en completarse todo. Probándolo en mi red tarda unos 20-25 minutos, por lo que las pilas deberían aguantar sobradamente.

Por último esta es una idea de última hora que se me ha ocurrido, podría también aprender a controlar el diodo led de la fonera el de network o el de wlan (que esta en desuso) para que con algún código me diera a entender lo que hacía, por ejemplo si esta conectada a la red wifi y el script esta en funcionamiento que este 5 segundos encendida, se apague, otros 5 segundos, se apague, etc. Esta idea se me acaba de ocurrir ahora mismo, pero no se como de fácil/difícil será, de todas formas no es necesario.

PD: Algunos datos los he cambiado en el script, por ejemplo, mi usuario y contraseña del ftp

PD2: No se se si es del todo buena idea ponerlo porque puede ser que ahora en el CGA preparen algo para que no me funcione, de todas formas no importa, sea como sea será bueno, si todo va bien conseguiré los datos. Si hay algun firewall estricto o algo parecido pues tendré que agudizar el ingenio y utilizar otras técnicas :)

Amap en la fonera

Como ya os conté en el post "Compilando para la fonera" me interesa tener la herramienta amap en la fonera y en aquel post la compilé, pero daba error porque faltaban algunos archivos, yo supuse que con poner esos archivos en el directorio adecuado sería suficiente, y así era. El problema es que yo quería tenerlos en otro directorio, a mi me interesa que sea en el directorio /usr/share/amap. Por qué? simplemente porque el otro directorio no existía y muchas aplicaciones guardan en la carpeta que yo he dicho sus archivos, y prefiero que este también sea así. Conseguirlo no ha sido muy fácil, he tardado bastante, busque en el configure y en el Makefile, cambié de todo pero no funcionaba... al final lo conseguí, pero hay un problema... no recuerdo que fichero modifiqué :'(

La buena noticia es que he hecho un paquete ipk para la fonera, para poder instalar amap con el gestor de paquetes de la fonera. Os cuento como lo he hecho, necesitamos un directorio dedicado para esto no debe haber mas cosas en él, en éste creamos una carpeta llamada CONTROL y la estructura de archivos que queremos, yo he puesto /usr/bin/amap y /usr/share/amap/aquí_hay_3_archivos. Dentro de la carpeta CONTROL hay que poner un archivo de texto llamado control con es siguiente contenido (este es el mio, vosotros cambiáis lo que necesitéis):

Package: amap
Version: 5.2
Depends:
Source: http://freeworld.thc.org/thc-amap/
Section: net
Priority: optional
Maintainer: Neobius
Architecture: mips
Description: Amap allows you to know what service is running on each port, independently of the number of the port.

Yo creo que esta bastante claro lo que hay que poner en cada sitio no?

Después para crear el paquete ipk podemos usar una utilidad llamada ipkg-build (es un script), lo podéis bajar de aquí.

La forma de usarlo es sencilla, ejecutáis el script indicándole la carpeta que contiene los archivos del paquete ipk, y si queréis la carpeta donde ha de guardarse el archivo ipk, si no lo hacéis se guardará en la carpeta en la que estéis.

En cualquier caso a mi no me funcionó, cuando lo probaba en la fonera no podía instalarlo, ipkg me daba un error. Entonces mire un poco el script y sabiendo que los paquetes deb se construyen con ar y que ipkg está basado en dpkg busque ar en el script y vi esto:

outer=ar

Y lo cambié por el que incluye el toolchain de la fonera:

outer=mips-linux-uclibc-ar

Luego probé de nuevo y funcionó, si alguien quiere el paquete ipk lo puede encontrar aquí.

Fonera en modo cliente con WPA-PSK

Ya tengo la fonera lista para que haga unos scaneos y me proporcione información útil sobre la red y los servidores. Para no escribir una entrada interminable voy a contarlo por partes, en este post escribiré sobre como la he puesto en modo cliente para que se conecte a la red wifi del centro tic.

Para ello no basta solo con las herramientas por defecto que tiene OpenWrt, la conexión wifi se configura en /etc/config/wireless, desde ese archivo podemos configurarla en modo cliente, tanto para redes abiertas, wep o wpa, pero no como yo necesitaba, os explico, yo tengo la clave de la red inalámbrica del centro tic, pero cifrada, no tengo el pass en claro. La teoría es esta: una red wifi cifrada con wpa-psk tiene su essid y su frase de paso en claro que tiene entre 8 y 63 caracteres, luego a partir de esos dos mediante un algoritmo de cifrado se obtiene una nueva clave de 64 caracteres la cual se puede usar para conectarse a la red wifi y no se puede obtener la frase de paso en claro a partir de ella. Yo dispongo de esa clave cifrada, la he sacado del fichero /etc/wpa_supplicant.conf, el problema es que estas claves cifradas no se pueden usar en OpenWrt a través de su archivo normal de configuración, o al menos yo no he podido y en el foro de openwrt tampoco ha sabido ayudarme nadie. La solución es recurrir a herramientas independientes del sistema operativo, wpa-supplicant, y como yo ya tenía el fichero de configuración de un portátil pues no iba a ser muy complicado conseguirlo, creé el fichero /etc/wpa_supplicant.conf y el puse esto:

ap_scan=1
fast_reauth=1
network={
ssid="essid_de_la_red"
scan_ssid=0
proto=WPA
key_mgmt=WPA-PSK
psk=clave_cifrada_de_la_red
}

Luego para comprobar si funcionaba ejecuté este comando:

wpa_supplicant -dd -D wext -c /etc/wpa_supplicant.conf -i ath0

Ah! Como es lógico hay que tener instalado wpa-supplicant, si no es así ejecutar:

ipkg install wpa-supplicant

Lo que decía, tras ejecutar aquel comando, funcionó, bueno tuve que abrir otra conexión ssh a la fonera para comprobarlo y si, así fue, todo iba bien, un paso mas para mi objetivo ya estaba conseguido :)

Ya que he investigado y leído tantas paginas de documentación voy a contaros también como configurar la fonera en modo cliente para que se conecte a una red abierta, a una con clave wep y a una con wpa usando al passphrase en claro.

La clave esta en los ficheros /etc/network/wireless y /etc/config/network, en el segundo yo he añadido una opción para el wifi:

config interface vlan1
option ifname ath0
option proto dhcp

Y en el primero varía según sea la red a la que nos conectemos, os pongo el fichero entero y luego indico las opciones que hay que cambiar en cada caso:

config wifi-device wifi0
option type atheros
# option channel 5
# option diversity 1
# option txantenna 0
# option rxantenna 0
# option distance 2000
# disable radio to prevent an open ap after reflashing:
option disabled 0

config wifi-iface
option device wifi0
option network vlan1
option mode sta
option ssid essid
option hidden 0
# option txpower 15
# option bgscan enable
option encryption psk
option key clave_de_la_red

Ese es un fichero para wpa-psk, solo tenéis que cambiar el ssid y la clave (option key clave_de_la_red) para que os funcione. Si usa cifrado wep cambias psk por wep y la clave (clave_de_la_red) por la clave wep, y si es una red abierta la ultima línea borrarla y cambiar psk por none, o al menos creo que era así, si hay algún problema dejarme un comentario ;)

De todas formas todavía falta un detalle... que nada mas arrancar se conecte a la red wifi, esto editando el fichero /etc/config/wireless no supone mayor problema, ya que se hará así, pero si es, como en mi caso, con wpa-supplicant? hay que añadir un script que se ejecute al inicio. Yo tenía ya uno que "autoreparaba" la fonera en caso de que la red estuviera mal configurada y así me evitaba flashear, simplemente lo he modificado, porque ya no lo necesito, y ha quedado así:

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

START=50
start(){
wpa_supplicant -dd -D wext -c /etc/wpa_supplicant.conf -i ath0
}

stop(){
killall test
}

Y ya está. Si vosotros lo acabáis de crear tendréis que darle permisos de ejecución y habilitarlo:

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

Con eso la fonera se conectará automáticamente a la red wifi cada vez que arranque.

Ahora escribire mas post contando el resto del proceso, como he conseguido que amap funcione bien y también os pondré el script y lo comentaré. La fonera ahora mismo está esperando al primer día de instituto, ese mismo día scaneará :D

Compilando para la fonera

Para conseguir mi objetivo con la fonera, (lo del modo monitor), necesito algunas herramientas que no existen como paquetes precompilados para la fonera, tengo que compilarlos yo. Realmente tampoco me he puesto muy en serio con el tema todavía y solo se me ha ocurrido una herramienta que compilar, se trata de amap, que averigua que servicio corre en cada puerto, nmap simplemente ve que puertos están abiertos, mira en su base de datos de puertos conocidos y te pone el servicio que debería ir ahí, por ejemplo, si tu tienes un ftp en el puerto 80 nmap te dirá que el puerto esta abierto, pero pondrá http, no ftp. Amap trabaja de otra manera, esta herramienta mira como responden los servicios que tras esos puertos y te dice que es lo que hay, incluso puede llegar a decirte el programa y su versión, no simplemente dice es un servidor ftp, puede que te diga que servidor es y su versión. Vamos una herramienta muy útil.

Recapitulando un poco, a mi me daba un error de ld al intentar compilar cualquier cosa, ya fuera compilación normal o compilación cruzada. Pregunté en un foro y me dijeron que tenía el ld de mi sistema y otro que había compilado yo (supongo que hice algo mal durante el lfs). Así que eliminé el que yo compile ya que no me valía para nada y ya funcionó, ahora si puedo compilar tanto de forma normal como cruzada. Aquí esta el hola mundo, que al fin funcionó:

# gcc test.c -o test
# ./test
¡Hola, mundo!

Ahora veamos como compilar nuestro hola mundo para que funcione en OpenWrt en mi fonera, luego veremos como compilar amap para la fonera. Lo primero que necesitamos es el toolchain (herramientas de desarrollo) de openwrt para nuestra arquitectura (de la maquina donde compilaremos), yo me bajé i686, también hay para x86_64. La versión para i686 ahora mismo no la encuentro en la web oficial, en su día me costo encontrar el enlace, así que la subo yo y si la queréis os la bajáis de aquí. Lo primero, como es lógico, es descomprimirlo, luego tenemos que añadir la ruta de los archivos para compilar al path. Dichos archivos se encuentran en OpenWrt-SDK-atheros-2.6-for-Linux-i686/staging_dir_mips/bin. Para hacerlo estando en el directorio donde descomprimimos, en mi caso /media/almacen/toolchain/, ejecutamos:

export PATH=`pwd`/OpenWrt-SDK-atheros-2.6-for-Linux-i686/staging_dir_mips/bin:$PATH

Ahora para comprobar que todo ha salido bien ejecutamos echo $PATH, en el resultado tiene que estar nuestro directorio:

/media/almacen/toolchain/OpenWrt-SDK-atheros-2.6-for-Linux-i686/staging_dir_mips/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Queda un poquito largo, no importa, mientras funcione. Ya podemos probar, compilando, por ejemplo nuestro hola mundo:

# mips-linux-gcc test.c -o test

Si ahora intentamos ejecutarlo, no podremos, eso es porque el ejecutable es para otra arquitectura:

# ./test
-bash: ./test: cannot execute binary file

Sin embargo si lo ejecutamos en la fonera la cosa cambiará, para pasarlo a la fonera hay varias maneras, yo suelo hacerlo mediante netcat o mediante http. Como tengo un servidor http en el server simplemente lo he copiado a /var/www (luego lo haremos con netcat). Luego en la fonera lo descargamos y ejecutamos:

# wget http://debian/test
# chmod +x test
# ./test
¡Hola, mundo!

Funciona! vale, ya sabemos como compilar cosas "sencillas", ahora vamos a intentar compilar algo se hace con el clásico ./configure... amap nos servirá. Lo primero es tener el código de amap, aquí nuevamente he perdido el enlace, así que os lo subo yo también, aquí. La forma normal de compilarlo es la normal de estos paquetes:

# tar -xzvf amap-5.2.tar.gz
# cd amap-5.2
# ./configure
# make
# make install

Con eso lo tenemos para usar en nuestra maquina local, que yo también lo he hecho porque es muy útil. Ahora veamos como hacemos para que se compile usando los archivos de nuestro SDK (Software Development Kit), es decir, para usar el compilador de la fonera. Me imagino que habrá distintas formas de hacer esto, investigaré un poco para ver cual es la mejor y mas cómoda. A me se me ocurren tres, una es modificar el configure, otra es modificar el Makefile y la última que no se si será posible: en alguna parte del sistema tiene que estar escrito que compilador se usa, si cambio esa configuración y en vez de gcc pongo mips-linux-gcc estaría todo solucionado. Yo he optado por modificar el (los) Makefile, porque en el configure no he encontrado donde hacer los cambios. He hecho esto:

# ./configure

Y después he modificado los dos Makefiles que hay. Si os fijáis hay uno en el directorio en el que estamos (amap-5.2/) y otro dentro de pcre-3.9/. En el primero de ellos solo he cambiado la variable CC, he puesto esto:

CC=mips-linux-uclibc-gcc

Y en el segundo he cambiado CC, RANLIB y STRIP, todos ellos hay que cambiarlos por los de la fonera:

CC = mips-linux-uclibc-gcc
RANLIB = mips-linux-uclibc-ranlib
STRIP = mips-linux-uclibc-strip

Puede que os preguntéis porque he cambiado esas variables, y que como vais a saber que variables cambiar cuando tengáis que compilar otro programa. Existe un conjunto de programas (binutils) que son el compilador, el linkador, etc. El compilador gcc de mi debian i386 no valdrá para la fonera, y tampoco valdrá el linkador ld de mi fonera en mi server. Entonces yo he mirado los nombres de las binutils de la fonera en OpenWrt-SDK-atheros-2.6-for-Linux-i686/staging_dir_mips/bin, y veo los nombres, por ejemplo: gcc, ar, as, c++, ld... De esta manera cuando yo en el Makefile vea gcc lo cambio por mips-linux-gcc, ar lo cambio por mips-linux-ar, etc. Estoy seguro de que debe existir algún método mejor, que intentaré averiguar, pero mientras no lo sepa esta es mi única solución.

Después de haber hecho los cambios precisos compilamos:

make

Si ahora intentamos ejecutar el archivo tampoco podremos, es para la fonera, no para un x86:

# ./amap
-bash: ./amap: cannot execute binary file

Sin embargo si lo pasamos a la fonera, esta vez con netcat, funcionará. Ejecutamos en el server:

# cat amap | nc fonera 9999

En la fonera:

# nc -l -p 9999 > amap

Y ya podemos darle permisos y ejecutarlo. De todas formas todavía no funcionara bien, porque para comprobar que servicio está en cada puerto compara la respuesta con una base de datos, también tiene que estar en la fonera. Supongo que sera cosa de añadirlo al directorio adecuado, todavía no lo he hecho, en cualquier caso pienso hacer un paquete ipk por cada programa que vaya a usar, seguiré trabajando con este hasta tenerlo todo listo. En cualquier caso, lo que me he interesa ya lo he conseguido: esta compilado.

Ahora buscaré un método mas cómodo, rápido y sencillo para hacer compilación cruzada, aprenderé a hacer paquetes ipk, y me pondré a programar el script que me haga un análisis de la red.

No puedo compilar en el server

La última vez que compile en el servidor fue cuando estuve con el LFS, luego como sabéis conseguí reparar la fonera y me puse a trabajar con ella, ya que era mi principal objetivo. Como ya queda poco para que empiece el curso, porque no es en octubre como muchos creíamos, es sobre el 20 de este mes, tengo que preguntar cuando es exactamente, bueno que me voy del tema, como queda poco estoy preparando ya el ultimo experimento (lo del modo cliente), y quería compilar una herramienta para la fonera, se trata de amap, un paquete que averigua que servicio corre en cada puerto abierto (no, nmap no lo hace), antes de hacer la compilacion cruzada probé a compilarlo para mi servidor también, pero ejecuto el ./configure y me da este error:

# ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking for gcc... gcc
checking whether the C compiler (gcc ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

Entonces, yo para comprobar que pasaba intenté compilar algo, porque ahí pone que gcc no puede crear ejecutables (WTF!), creé un fichero (test.c) que no es mas que un hola mundo y lo intenté compilar:

# gcc test.c -o test
/usr/local/bin/ld: opción `--hash-style=both' no reconocida
/usr/local/bin/ld: use la opción --help para información de modo de empleo
collect2: ld returned 1 exit status

No compila y la verdad es que no se que hacer, he googleado y no he encontrado nada, he buscado en todas partes pero no ha habido manera, así que he preguntado en un foro, esdebian.org, a ver si alguien puede ayudarme. Luego la idea sería hacer compilación cruzada y compilarlo con el toolchain de openwrt.

Mientras se soluciona ese contratiempo voy a seguir por otro frente, voy a configurar la red inalámbrica de mi otro router con wpa, y voy a intentar que la fonera se conecte a él, ya que la red wifi de mi instituto esta cifrada con wpa, aunque como ya he dicho en otras ocasiones tengo el fichero de configuración con la clave, así que no debería serme mayor problema.

Yo por último un comentario sobre el pendrive, hoy se cumplen las 48 horas, debería llegarme...

Otra prueba de autonomía

Como ya conté en el último post tenía pensado hacer otra prueba con la fonera, ver la autonomía que tiene la fonera con el wifi a máximo rendimiento. Ya he hecho la prueba y la verdad es que el resultado no me ha decepcionado, está bastante bien. Al final os digo el tiempo...

Para hacer la prueba lo que se me ocurrió fue hacer que se conectara a mi red wifi, cosa que hizo perfectamente y luego desde el servidor enviarle una cantidad ingente de datos, suficiente como para que pudiera estar recibiendo datos por un período de 3 o 4 horas a 1 MB/s. Mientras, ejecutar un par de scripts iguales que el de la prueba anterior, uno sería exactamente igual, para hacer pings a la fonera vía ethernet, y el otro le cambiaría la ip para que ejecutara los pings vía wifi. Porque dos pings diferentes? pues la idea era comprobar con pings si la fonera estaba viva, pero entonces pensé que quizás el wifi podría tener un fallo puntual mientras la fonera seguir viva, y entonces mi script simplemente apuntaría la hora del fallo y se detendría, sin embargo si también ejecuto los pings via ethernet, si el wifi fallara en estos pings quedaría registrado como fallo y no como "muerte" de la fonera. No se si se lo he explicado bien, lo dig de otra manera, la fonera, para mi prueba va a estar conectada por wifi y por ethernet, por ello tendrá dos interfaces de red activas con dos ips diferentes, por ello si ejecuto pings a ambas ips y una no responde y la otra si, podemos deducir que se trata de un fallo puntual de esa interfaz, y no que se haya apagado la fonera.

Los scripts que controlan el tiempo ya los tenemos listos, solo los queda preparar el flujo de datos que hará que el wifi de la fonera no pare hasta que no se apague la fonera. Para esto tenía dos opciones, una crear un archivo muy grande para pasarselo a la fonera (o en su defecto idear un bucle con uno pequeño que se enviara constantemente) la otra opción era utilizar algún fichero grande que tuviera a mano. Yo dispongo en mi servidor de las imágenes de los tres DVDs de debian etch, que son de 4.4 GB, 4.4 GB y 4.3 GB. En total 13.1 GB, que teniendo en cuenta que la velocidad del wifi de la fonera no ha pasado de 1.1 MB/s en pruebas previas, dan para 3.39 horas. Sabiendo que sin wifi aguantó un poco mas de cuatro horas y que con el wifi aguantará menos creo que con esos datos tendré suficiente. Ahora ya la cuestión técnica, como le paso los datos a la fonera? pues of course, con netcat, lo instalo en un momento en la fonera mediante ipkg (no, por defecto no lo trae). Entonces le pongo las pilas a la fonera, pongo los dos scripts a funcionar y envío los datos, ejecutando el primer comando en la fonera y el segundo en el servidor:

nc -l -p 9999 > /dev/null
cat debian-40r0-i386-DVD-* | nc 192.168.0.11 9999

Hecho eso solo toca esperar a que la fonera se apague:

mié ago 29 17:33:04 CEST 2007
mié ago 29 20:09:09 CEST 2007

Lo que significa 2 horas 36 minutos, que para mi es bastante. Por ultimo señalar una curiosidad, realmente no esperaba que la fonera se apagara justo cuando cayera la red, de hecho cuando los pings no fueron respondidos, el led de red empezó a parpadear, luego se apagó, después el led de power empezó a brillar cada vez menos, hasta que 25 minutos mas tarde se apagó!! 25 minutos!!!

Nada mas, ahora solo me queda pensar el script que ejecutara la fonera para analizar la red del centro tic.

PD: La prueba como dije la hice con la fontenna conectada.

Autonomía de la fonera con pilas

Ayer hice la primera prueba para ver cuanto aguantaba la fonera con pilas, para ello desde luego no pensaba quedarme mirando los leds con un cronómetro en la mano esperando a que se apagaran las luces, hice un script para el servidor. La idea era sencilla, conectar la fonera con las pilas, entonces el servidor apunta la hora a la que comienza la prueba y le hace un ping a la fonera, cuando deje de responder la damos por muerta y apuntamos la hora de nuevo, con una cosa así de sencilla conseguimos que el servidor sea quien este pendiente de la fonera y no yo. El script es este:

#!/bin/bash
date > tiempo.txt
PING=""
while [ 1 == 1 ] ;
do
if [ -e $PING ]; then
PING=$(ping -c 2 fonera | grep "100% packet loss");
else
date >> tiempo.txt;
exit
fi;
done

Es muy simple, primero apunta la hora y la fecha en el archivo tiempo.txt, después creamos la variable PING sin ningún valor. Lo siguiente es un bucle que en principio no tiene fin, porque se hace siempre que 1 se igual a 1. Dentro de este bucle hay un if, que comprueba la variable PING, si esta vacía envía dos pings a la fonera y comprueba si ha recibido como resultado que el 100% de los paquetes se han perdido, el resultado a la variable PING. En caso contrario añade la nueva fecha al fichero tiempo.txt y se acabó el script. Todo se repite de nuevo, hasta que por fin la fonera no responda y se apunte la nueva hora.

El script funcionó a la perfección y el resultado, el fichero tiempo.txt es este:

lun ago 27 15:31:35 CEST 2007
lun ago 27 19:23:29 CEST 2007

Casi cuatro horas!!! y ojo, que a ese tiempo hay que sumarle como unos 15 0 20 minutos, de las pruebas que hice hace unos días para comprobar que todo funcionaba bien en la fonera cuando se usaban las pilas. En total mas de 4 horas.

Hay que decir un par de cosillas mas, la fonera en ese tiempo no tenía ninguna actividad, excepto recibir/enviar pings constantemente. La actividad wifi era nula. Y como yo a la fonera le voy a dar dos usos, uno de pocos segundos, que ira con cable ethernet (el de las contraseñas) y el otro, el de ponerla en modo cliente y demás, que todo será por wifi, voy a hacer otra prueba. Será con unas pilas recién sacadas de su caja e iguales a las de la primera prueba, solo que en esta ocasión funcionará con el wifi a pleno rendimiento, para ver si hay mucha diferencia y para estimar cuanto tiempo podría aguantar en el centro tic. Y por último, no sé si la antena influirá en el consumo, pero la prueba la voy a hacer con la fontenna, porque es la antena que llevara la fonera en el instituto.

La fonera con pilas

Hoy he estado avanzando con la fonera, a parte de unas configuraciones para ponerla en modo cliente y unas modificaciones en mi red para que se parezca un poquito mas a la del centro tic, lo que he hecho ha sido soldar el portapilas al conector que usaré, algunas pruebas para comprobar que todo funciona, y me he dado cuenta de lo que tarda la fonera en arrancar. Ahora os contaré todo con detalle.

La fonera la he configurado en modo cliente para que se conecte a mi router, que ahora mismo tiene cifrado wep (si ya se que no vale para nada, pero nunca he tenido ganas de cambiarlo :P ). Ha sido muy sencillo, un rápido vistazo al wiki de openwrt, aquí podéis ver como se hace, esta perfectamente claro, te pone como tienes que configurar los ficheros /etc/config/network y /etc/config/wireless, obviamente hay que ponerlos según tu configuración, en el network pones tu ip y demás y en el wireless deberías poner tu clave wep y el essid de tu red.

Eso en cuanto a software de la fonera. Ahora voy a hablaros sobre los cambios en mi red, como sabéis tengo 2 routers iguales, uno que le compré a orange y otro que me regaló orange. He instalado el segundo router, conectado a un puerto ethernet del primero, con intencion de crear una subred. Éste segundo router lo configuraré con wpa y será al que se conecte la fonera para luego scanear la red. Ahora mismo la conexión con el segundo router funciona mas o menos bien, desde él tengo acceso a toda mi red y a internet, pero me falla el dns, tengo que meter ips a mano, a ver si lo soluciono hoy.

Y por último el tema estrella del día, ayer soldé el portapilas al conector y funciona!!! puse la fonera a funcionar con pilas y quitó las contraseñas del portátil. Primero unas fotos y después os cuento las cosas de las que me he dado cuenta, las fotos no se ven muy bien, son con el móvil, pero mas o menos...


Ayer cuando estuve probándola con las pilas me di cuenta de que al principio no funcionaba, luego volví a intentarlo y funcionó, fue ahí cuanto pensé que la fonera necesitaba un tiempo para estar lista para funcionar desde que se le conecta la corriente, dicho tiempo tenía que conocerlo, por lo que me puse a hacer unas medidas. Medí tanto usando el cable como usando las pilas, porque no tenía la certeza de que las pilas proporcionasen la energía idónea. Las mediciones que hice fueron el tiempo que tardaba en responder a un ping, el tiempo que tarda en tener el ssh listo para que alguien se conecte (suponiendo que los demás servicios tardarían mas o menos lo mismo), el tiempo que tarda en responder a un ping con el wifi desactivado, el tiempo necesario para que el pxe este listo para funcionar y el tiempo de la operación del borrado de contraseñas, desde el arranque hasta que se reinicia. Los tiempos fueron los mismos para el cable y para las pilas si no tenemos en cuenta los fallos humanos a la hora de cronometrar, por ello solo pongo un tiempo:

-Boot (ping): 1'37''
-Boot (ssh): 1'48''
-Boot (sin wifi): 1'35''
-Boot (pxe): 2'03''
-Borrar pass: 36''

Según esos datos tengo que encender la fonera 2 minutos antes de querer usarla para lo de las contraseñas. Y luego tardará medio minuto en hacer su trabajo. hay que decir que a lo mejor con una fonera recién flasheada a lo mejor tarda unos segundos menos, porque es cierto que yo instalé un par de paquetes en la fonera, pero para la prueba elimine todos los que recordé, en cualquier caso no creo que ganara mucho, pocos segundos quizás.

Por último añadir que he pensado que es mejor tener la fonera primero lista para lo del modo cliente, porque los primeros días de clase tengo serias dudas de que vayamos a coger alguna máquina, por ello si la fonera se conecta y me va scaneando los servidores pues algo que hemos ganado no?

Ah! y otra cosa, también pienso hacer unas pruebas de autonomía con pilas, para ver cuanto aguanta la fonera.

Harto del LDAP

Pues si el LDAP ha estado a punto de destrozarme el ubuntu del portátil, bueno en realidad lo ha hecho, pero mas o menos he podido recomponerlo todo.

Como sabéis mi plan era montar ldap en mi server (que esta hecho y funciona, o eso creo...) y luego poner la fonera como cliente para que luego se conecte a mi cuenta en el servidor del centro tic y utilice el espacio del que dispongo para almacenar lo que necesite.

He configurado el server y el portátil siguiendo las diferentes informaciones que he encontrado esperando que alguna funcionara, pero no lo he conseguido. Lo único que conseguí fue poder loguearme como ldaptest (el usuario que cree en ldap para mis pruebas), mediante su. No puedo poneros mis ficheros de configuración porque para solucionar el problema tuve que desinstalar los paquetes que instalé y se borraron los archivos de configuración. Estos son los tutoriales que intente seguir, no he podido con ninguno...

http://es.tldp.org/COMO-INSFLUG/COMOs/LDAP-Linux-Como/LDAP-Linux-Como.html#toc3
http://www.grulic.org.ar/eventos/charlas/ldap-2005-04.html
http://bulma.net/body.phtml?nIdNoticia=1991
http://bulma.net/body.phtml?nIdNoticia=1371
http://n1mh.org/papeles/gdm2.html
http://misitio.homelinux.com/wiki/index.php/Nfs_Pam_Ldap
http://publib.boulder.ibm.com/infocenter/tssfsv21/index.jsp?topic=/com.ibm.sanfs22.doc/fog0_t_config_openldap_client.html
http://www.terminator.net/ldapconf/manual/ldapclient.html

En vista de que ninguno me valió para nada tendré que aprender exactamente para que sirve cada parámetro de los archivos de configuración y los crearé a mi medida.

Lo que me ocurrió fue que antes de ayer estuve intentando configurarlo y se ve que deje algún fichero mal configurado y entonces, al día siguiente cuando me levanté y encendí el portátil tardaba muchísimo en arrancar, luego tuve problemas para loguearme, aunque al final no se como, pude hacerlo, después el network manager no funcionaba, el escritorio tardaba una eternidad en cargarse por completo, vamos que era totalmente inservible. Después de probar de todo, restaurar ficheros del ldap a partir de backups anteriores al desastre, reiniciar, cambiar configuraciones, buscar en google, ubuntu-es, ubuntuforums, etc. Arranqué desde un live cd de ubuntu y restauré los ficheros de configuración afectados a partir de los que había en el live cd. Reinicié y tampoco funcionó, total que al final me decidí a desinstalar todos los paquetes relativos al ldap que había instalado yo. Desde el live cd, ejecute:

dpkg -l | grep ldap

Para ver que paquetes incluye ubuntu por defecto para el ldap, y luego lo ejecute en la ubuntu instalada en el portátil pero desde el live cd, mediante chroot, porque arrancar el portátil era un infierno, tardaba una cosa mala. Desinstalé con apt-get remove --purge (para que borre también lo archivos de configuración) todos los paquetes menos libldap2, que es el único que tenía el live cd. Tras eso reinicié y ubuntu funcionaba mas o menos bien, y digo mas o menos porque network manager seguía sin funcionar y los datos del /etc/hosts era como si no existieran, por ejemplo, según ese archivo debian es 192.168.0.6 (mi servidor) pero ese nombre no se usaba, si ejecutaba ping debian, me decía unknown host.

El problema del network manager lo solucione simplemente reinstalandolo, y lo del /etc/hosts, fue gracias a la ayuda de Castigador (gracias ;-) ) por lo visto era problema del /etc/nsswitch.conf, que sencillamente yo no lo tenía, el me paso el suyo y asunto solucionado.

No os puedo hablar mucho mas sobre el ldap porque no tengo nada hecho, seguiré el consejo de Castigador, leeré los manuales y creare mis archivos de configuración, no me limitaré a copiar los ejemplos de los artículos como he hecho hasta ahora.

Antes de acabar quiero comentaros otra cosa, la fonera ya puede montar un sistema de archivos nfs. Solo hacía falta instalar el paquete kmod-fs-nfs. Después ya se puede montar con tranquilidad:

ipkg install kmod-fs-nfs
mount 192.168.0.6:/media/home /mnt/test -t nfs -o nolock

Y ya esta montado, ahora la fonera tiene 55 GB :D

Ya no tengo nada mas que decir, estos días no he avanzado mucho, he estado leyendo sobre ldap, intentando configurarlo.... y ademas he redescubierto a un asesino de la productividad: armagetron y hoy he perdido bastante tiempo jugando. Seguiré avanzando, ya os contaré...

PD: El pendrive con U3 creo que me llegara sobre finales de la semana que viene, porque cuando lo compre no me fije en un detalle, alternate tiene unos iconos que indican el tiempo que tarda en enviarse un pedido, y hoy lo he mirado y el que yo compre pone "de 8 a 10 días", y yo lo pedi el domingo de la semana pasada.

El libro y mas fonera

El libro me acaba de llegar ahora mismo, luego empezaré a leerlo, pero conociendo la primera parte y habiendo hojeado éste, creo que ha sido una buena compra. Una foto:

Al margen de ese tema que ya no hay mucho mas que comentar, voy a hablaros sobre como va la fonera. Ya sabéis en que consiste el proyecto actual, ponerla en modo cliente, etc. todavía no he pensado exactamente que va a hacer la fonera, solo tengo en mente dos o tres herramientas, pero vamos que eso se piensa en un momento, luego quedaría hacer el script y probarlo, no puedo llegar al instituto a ciegas, sin haber probado el script. Por ello necesito crear un entorno que se asemeje un mínimo a lo que hay en el centro tic, para el tema de la red inalámbrica usaré mi segundo router, porque el que esta uso prefiero no tocarle la configuración, me ahorro trabajo cogiendo el otro, así ademas el portátil podrá seguir conectándose a mi red tan tranquilo mientras duren las pruebas. Y por otro lado mi servidor hará de... servidor xD La idea que tuve el otro día de que la fonera se conecte a mi cuenta en el servidor y utilice mi espacio nfs me ha gustado, y pienso montarlo, para conseguirlo estoy intentando que en mi server funcione el nfs (conseguido) y ahora estoy leyendo la documentación de LDAP, para tener ese sistema de usuarios remoto, por llamarlo de alguna manera, para crear un usuario desde el cual accederá la fonera y utilizará el espacio nfs asignado.

El LDAP como es lógico no puedo todavía contaros como se instala, configura, etc. porque no lo he hecho, sin embargo si que lo he hecho con el nfs, así que como de costumbre voy a contaros como lo he hecho.

En el servidor necesitamos instalar el servicio, yo solo instalé mediante apt el paquete nfs-kernel-server:

# apt-get install nfs-kernel-server

Ahora solo queda configurarlo, lo imprescindible es el archivo /etc/exports, donde configuraremos el directorio que se podrá montar remotamente, quien podrá hacerlo, que privilegios tiene... Ademas también, para ganar en seguridad, se pueden editar los ficheros /etc/hosts.allow y /etc/hosts.deny. Yo solo me he limitado al /etc/exports, esto es lo que he puesto en él:

/media/home 192.168.0.0/255.255.255.0(rw)

Lo primero es el directorio que quiero que se pueda montar desde otros pc, después he puesto que cualquier ip del rango 192.168.0.1-255 pueda hacerlo, y por último que se pueda leer y escribir. También le cambie los permisos a dicho directorio, porque al principio no podía escribir en el, desde mi laptop. Al final le di 777 al directorio y ya funcionaba bien. (una configuración mas restrictiva también lo hubiera hecho seguramente, pero yo le puse esa):

# chmod 777 /media/home

Con eso el servidor ya está listo, ahora solo nos queda configurar el cliente. Yo por ahora solo he configurado mi laptop con ubuntu, la fonera no la preparado todavía. En ubuntu por defecto no he podido montarlo, he instalado el paquete nfs-common y ya funcionó todo:

# apt-get install nfs-common

Y después ya lo pude montar:

# mount debian:/media/home /mnt

Donde debian es el nombre del servidor o su ip, lo siguiente es el directorio remoto y el local donde lo montaremos. Hasta ahora es lo que he hecho, si queréis mas detalles sobre como configurar el nfs os dejo estos dos links:

http://nfs.sourceforge.net/nfs-howto/
http://bulma.net/body.phtml?nIdNoticia=1255

Mis siguientes pasos serán conseguir que la fonera pueda montar utilizar nfs, preferiblemente sin tener que compilar un kernel. Y también configurar el ldap en mi server. Os seguiré contando...

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).