Parkito Weblog

A muchos les extrañará que escriba esta entrada, sabiendo que soy un defensor acérrimo de Linux, como ya demostré muchas veces, pero bueno, las verdades son verdades, sea para quien sea.

Linux viene bien para muchas cosas (en mi caso, para prácticamente todas), pero hay una en la cual flaquea un poco, y es si tenemos cierto hardware antiguo y nos dedicamos a actualizar todo el sistema. Por un lado es cierto que con Linux aprovechamos mejor el hardware, y al poder elegir el sistema de ventanas, podemos tener un sistema actual en un equipo no tan actual, pero por otro eso puede acarrear ciertos problemas. Por poner un ejemplo, cuando vamos actualizando el sistema, hay aplicaciones, algunos servicios, demonios y demás que sólo están soportados si tenemos el kernel relativamente actualizado (sobre todo si utilizáis cosas como servidores y demás). Sin embargo, estas últimas versiones a veces dejan de tener los drivers necesarios para algunas piezas de hardware, por considerarse obsoletas. En mi caso, me pasó en su día con la tarjeta gráfica, una nvidia, que dejó de estar soportada por el driver “normal”, y pasó a la rama “legacy”. Esto provocó que a posteriori hubiese incompatibilidades con las nuevas versiones de xorg. También me pasó con el scanner, un HP de hace más de 10 años, que dejó de estar soportado por el driver avision, lo que provocaba que los programas de escaneo se colgasen.

Es cierto que todos estos problemas se pueden solucionar parcheando cosillas aquí y allá, pero bueno, son soluciones que dan mucho trabajo, incluso para usuarios avanzados. Por ejemplo, lo del scanner conseguí solucionarlo simplemente editando una línea de un fichero, pero tardé varios días en averiguar cómo y dónde hacerlo.

En cualquier caso, dejar constancia que estos problemas sólo me ocurrieron en casos puntuales y con hardware con más de 10 años de antigüedad. Con sistemas windows sería impensable aguantar tanto tiempo con un sistema operativo actualizado .

Sabes que estás estresado y hasta las pelotas del ordenador cuando al sonar el despertador lo primero que te viene a la cabeza que está haciendo tu cerebro es:


INIT: version 2.84 booting

Iniciando cuerpo [ OK ]


Esto es algo que había hecho una vez en windows, y resultó tan sencillo como seleccionar los dos interfaces de red del equipo que iba a usar como pasarela y seleccionar la opción “establecer pasarela”, o algo similar (hace mucho que lo hice y hace mucho que no uso windows). En cualquier caso, me vi en la necesidad de hacer algo similar en linux, pero fue bastante más complicado de lo que pensé que sería. Aquí os pongo el proceso que tuve que seguir de forma muy detallada, para que no os perdáis. Difícil y nada sencillo, pero sí para toda la familia.

Bueno, pues eso, la configuración de la red es la siguiente:

Para poner correctamente la parte cableada, que es de lo que se trata aquí, configuramos las interfaces de los 3 equipos de la siguiente forma:

EQUIPO 1

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.5
netmask 255.255.255.0
gateway 192.168.0.1
up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.2
up route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.7
auto eth0

Aquí lo que hacemos es indicarle al equipo que la red wifi (subred 1) se encuentra a través de la puerta de enlace 0.2, y que la subred 2 se encuentra a través de la puerta de enlace 0.7

SERVIDOR

auto lo
iface lo inet loopback

iface eth0 inet static
address 192.168.0.7
netmask 255.255.255.0
gateway 192.168.0.1
up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.2
auto eth0

iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0
auto eth1

Aquí le indicamos al servidor que la red wifi se encuentra a través de la puerta de enlace 0.2, al igual que con el anterior equipo. A la conexión punto a punto no es necesario ponerle una puerta de enlace.

EQUIPO 2

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

allow-hotplug eth0
iface eth0 inet static
address 192.168.2.5
netmask 255.255.255.0
gateway 192.168.2.1
up route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.2.1
up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1
auto eth0

Aquí le indicamos al equipo que para acceder a las otras 2 subredes tiene que pasar por la puerta de enlace 2.1.

Una vez hecho ésto, tendremos acceso desde cada subred únicamente hasta el servidor, ya que éste no retransmitirá los paquetes de una de sus interfaces a la otra. Para solucionar ésto, es necesario introducir un script de iptables que fuerce esta retransmisión. El script sugerido es el siguiente:

#!/bin/sh

echo Aplicando Reglas de Firewall...

## FLUSH de reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F

## Establecemos politica por defecto
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables -A FORWARD -i eth1 -d 192.168.0.0 -j ACCEPT
iptables -A FORWARD -i eth1 -d 192.168.1.0 -j ACCEPT
iptables -A FORWARD -i eth0 -d 192.168.2.0 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

Aquí hacemos lo siguiente: lo primero es eliminar las anteriores configuraciones de iptables si las hubiese (si tenéis alguna otra cosa, evidentemente tendréis que cambiar ésto).
Posteriormente se establece la política por defecto como aceptación de todos los paquetes (es inseguro. Si os preocupa la seguridad tendréis que cambiar el script para denegarlos por defecto).
A continuación, introducimos una línea para enmascarar la conexión procedente de la subred 2 hacia el exterior. Esta línea es importante, ya que de no ponerla, no podremos conectarnos al router, y por tanto, no habrá acceso hacia internet ni hacia la subred 1.
Después viene el grueso del script. En estas 3 líneas se redireccionan los paquetes, a saber: lo que llega por el interfaz 1 y se dirige a la red 0 se reenvía. Lo mismo para lo que llega por el interfaz 1 y se dirige a la red 1 y para lo que llega por el interfaz 0 y se dirige a la red 2.
Por último ponemos a 1 el bit que activa el ip-forwarding (muy importante. De lo contrario, el script no hará nada).

Una vez hecho ésto, basta con añadir el script a /etc/init.d/ e introducirlo en el arranque del sistema para que se active siempre.

Servidor de descargas con mldonkey (III)

SEPTIMO PROBLEMA: tenía lowID. La solución es sencilla, una redirección de puertos en el router. Sin embargo, no son únicamente los puertos de los servidores a los que nos conectemos. El mldonkey utiliza algunos puertos más para gestionar la conexión (podemos verlos en el fichero de configuración downloads.ini).

Bueno, una vez instalado todo y configurado el mldonkey en el equipo viejo para poder gestionarlo desde toda la red (así se puede poner a bajar desde cualquier ordenador de la casa, y siempre se descarga en el equipo viejo), sólo faltaba un script que pasase ficheros a mi equipo en cuanto estuviesen descargados, por aquello de no llenar aquel disco duro. Como ese ordenador va a estar siempre encendido, lo más cómodo es que el script esté en mi ordenador, y cada cierto tiempo, monte la unidad de red del viejo, compruebe si hay ficheros y, si los hay, los transifera aquí con wget. El script es algo tan sencillo como ésto:

#!/bin/bash

directorio_local="*directorio donde queremos las descargas*"

mkdir $directorio_local/temporal

mount *directorio NFS*
cd *directorio NFS*/incoming/files

for i in * ; do
    cd $directorio_local/temporal

    wget -c ftp://*ip del servidor*/incoming/files/"${i}" --user=*usuario FTP* --password=*password del usuario FTP*

    tamanho1=`ls -l "${i}"`
    tamanho1=`echo $tamanho1 | cut -d\  -f5`
    tamanho2=`ls -l *directorio NFS*/incoming/files/"${i}"`
    tamanho2=`echo $tamanho2 | cut -d\  -f5`

    if [ "$tamanho1" = "$tamanho2" ] ; then
	rm -f *directorio NFS*/incoming/files/"${i}"
	mv "${i}" ../
    fi
done

umount *directorio NFS*

Como veis, en el script se hace uso de todo, del servidor ftp y del directorio NFS. Monta la unidad NFS, comprueba si hay ficheros y luego descarga cada uno por ftp. Para eso es necesario tener un servidor ftp instalado (recordad que lo instalamos al principio “para lo que pudiese hacer falta” ). Una vez descargado cada fichero, se comprueba si el tamaño de origen y destino coincide (está entero) y si coinciden, se borra del origen. Además, está implementado un pequeño sistema de seguridad. Los ficheros se descargan inicialmente a un directorio temporal, y cuando la descarga está completa, se mueve al directorio principal. Ésto es así por si reiniciamos el equipo mientras se está copiando algo. De esta forma, sabemos que todo lo que tenemos en el directorio principal está terminado. Tampoco pasa nada por interrumpir una transferencia, porque el parámetro -c del wget continua las descargas incompletas.

Para que se ejecute de vez en cuando, basta con añadirlo al cron (para eso hay múltiples tutoriales por ahí, nada del otro mundo). Además, se puede automatizar un poquito más. Mldonkey permite establecer usuarios, por lo que si queremos colas de descarga separadas, creamos distintos usuarios no administradores, e indicamos un directorio de ficheros descargados distinto para cada uno, indicándole al script de cada usuario que se haga con los ficheros del directorio correspondiente. No es complicado utilizando el gestor web del mldonkey.

En fin, eso es todo. Nada fácil y nada sencillo, pero al menos sí para toda la familia

Servidor de descargas con mldonkey (II)

Ahora la fonera tenía millones de posibilidades más de las que tenía antes, y había que configurar todo de nuevo. Me pasé un buen rato hasta que di con una configuración que funcionase, porque según lo que pongamos, perdemos el acceso de unas redes a otras, perdemos el acceso de unas redes a internet, perdemos la posibilidad de conectarnos por ip fija… en fin, una locura. La configuración con la que me funcionó es ésta:

Configuración 1
Aquí podemos ver lo básico. La fonera está configurada para conectarse a la red con una ip fija, con su máscara y sus dns correspondientes. Debajo vemos la configuración del interfaz wifi, tambiéncon su ip fija, y especificando como puerta de enlace la ip del router (de lo contrario, no hay acceso a internet).

Configuración 2
Tenemos varios modos de funcionamiento para la fonera. Como ya hay un router actuando de puerta de enlace, si nos fiamos de la ayuda, deberíamos poner la fonera como router y no como puerta de enlace. Sin embargo, si hacemos ésto perdemos la conexión a internet de todos los dispositivos que se conecten a la fonera. Es necesario configurarla como puerta de enlace.

Configuración 3
En cuanto al modo de funcionamiento, debe ser como punto de acceso. En el tipo de red, podría haber puesto b sin problemas, porque sigue siendo superior a la velocidad del USB del ordenador viejo. Sin embargo, ésto limitaría a todos los demás equipos que se pudiesen conectar, por lo que preferí dejarla en mixed, con los rates en auto.

Configuración 4
Ésto es MUY importante. Debemos desactivar el firewall. De lo contrario, no devuelve ni los pings.

Bueno, una vez configurado el firmware nuevo, intenté dejar las redes como estaban y acceder de una red a la otra. Sorpresa, todavía no funcionaba y recibía el mismo mensaje de paquetes filtrados de antes. Aquí ya tenía un nudo cerebral, pero tras intentar varias cosas, se me ocurrió establecer rutas estáticas, y resultó ser la solución. Establecí ésta en el router:

                       Menu 12.1.1 - Edit IP Static Route

                    Route #: 2
                    Route Name= mldonkey
                    Active= Yes
                    Destination IP Address= 192.168.1.5
                    IP Subnet Mask= 255.255.255.0
                    Gateway IP Address= 192.168.0.2
                    Metric= 1
                    Private= No

Con ésto desde windows ya podía acceder desde una red a la otra, pero desde linux no. Evidentemente el problema residía en que en linux había que establecer la misma ruta para el sistema, que en windows se hace automáticamente (punto a favor). Fácil, simplemente añadir ésto en /etc/network/interfaces, en el campo donde configuráis vuestra tarjeta de red:

up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.2

Esto significa que para acceder a cualquier elemento de la red 1, se debe pasar por 0.2, que es el interfaz cableado de la fonera.

Con ésto ya podía acceder por red desde el equipo nuevo al viejo y viceversa. Ahora había que montar los directorios del viejo en red dentro del nuevo, preferiblemente como una carpeta, para aumentar la comodidad. Ésto se hace de forma muy sencilla con NFS. Basta con seguir este tutorial. Una vez hecho ésto ya podía acceder desde este ordenador al viejo, a sus ficheros y demás.

SEXTO PROBLEMA: al acceder de esta forma e intentar copiar un fichero de un equipo a otro, no me da problemas siempre que los ficheros sean inferiores a 5 megas. Cuando intento transferir ficheros mayores, empieza a transmitir a saco, satura la red… Pensé que podría ser culpa del equipo viejo, porque tiene 10 años y el receptor está conectado a un puerto USB1.0 (ni siquiera es 1.1), por lo que la velocidad de transferencia está limitada a 1.5Mbps (no llega a 200 kB/s), y quizás se saturaba con el flujo entrante. Para descartarlo, probé a transmitir un fichero desde el equipo viejo al nuevo, y la red se saturaba igual, así que el problema es de la red en sí. Estuve indagando mecanismos de control de flujo, para limitar la velocidad, etc, pero no encontré nada que lo pudiese hacer de forma sencilla. Sin embargo me di cuenta de que con wget, podía transferir ficheros de un equipo a otro reduciendo considerablemente la saturación. Va bastante lento, aproximadamente a 1/3 de la velocidad que podría dar de sí la red (va a una media de unos 50 kB/s), pero bueno, al menos funciona, y supongo que con un equipo de hace 10 años, otro de hace 6, una fonera y dos paredes de por medio, no puedo pedir mucho más.

Una vez hecho todo ésto, instalé en el equipo antiguo el mldonkey

Servidor de descargas con mldonkey (IV)

Servidor de descargas con mldonkey (I)

Una vez configurada la red, comprobé que con el otro ordenador tenía internet. Efectivamente, el ordenador viejo ya hacía pings a google como un campeón. Le instalé un servidor ssh para poder controlarlo (sin pantalla ni teclado, sería un poco complicado xD) y un servidor ftp para lo que pudiese hacer falta. Los configuré (para más ayuda, google es el camino) y andando. Luego reinicié el cacharro y configuré la bios para que no parase el arranque ante ningún error (por razones de fecha [ese cacharro tiene la pila de la bios gastada], teclado [press F1 to continue, y no hay teclado] y demás), y una vez hecho todo ésto, intenté acceder desde éste al viejo. Tacháaaaaaaaaaan.

CUARTO PROBLEMA: no había acceso desde una red a la otra. Ningún ordenador de la red 0 podía comunicarse con ninguno de la red 1, ni siquiera para hacer pings (el mensaje era que los paquetes estaban siendo filtrados):

fenix:/home/sparkster# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.153.1 icmp_seq=1 Packet filtered

Lo extraño es que desde la red 1 sí tenía acceso a la 0. Tras trastear con varias posibilidades (cambiar máscaras de subred [estaban todas a 255.255.255.0], intentar con la misma red [se me iba al carajo la conexión a internet, cosas de la fonera], cambiar la red 0 por la 1 y la 1 por la 2, etc), supuse que el problema de todo estaba en la fonera, así que decidí la solución más salomónica, más peligrosa, que me dio más problemas y que a la larga era la única solución posible para evitar problemas futuros: flashear la fonera.

Los que tengáis una fonera, sabréis que es una mierda. El firmware que trae es una cacadelavaca, con muy pocas posibilidades, muy capado… Además cada vez que enchufas la fonera, se conecta a internet, cambia el firmware ella solita y hace las de dios. Además leí que el firmware que anda rulando por ahí, de dd-wrt, es bastante completo, lo que ya me hizo decidirme de todo.

QUINTO PROBLEMA: todos los tutoriales que hay para flashear la fonera (TODOS, ABSOLUTAMENTE TODOS) están mal, tienen errores, están incompletos… Vamos, que fue una odisea. Pensé que había estropeado la fonera 3 o 4 veces, porque no se resseteaba, no podía acceder a ella, no servía con desenchufarla… Y resulta que era otro paso de esos “complicados” que no figuran en los tutos… No voy a enlazar ningún tutorial porque no recomiendo intentar flashearla a menos que estéis muy familiarizados con redboot, con telnet y con ssh, además de haber flasheado ya cosas con anterioridad, porque es muy fácil que por culpa de toda esa morralla incompleta que hay por ahí os quedéis sin fonera. En cualquier caso, los pasos que tuve que seguir yo para flashearla son los siguientes (no servirá para que hagáis nada, pero os hacéis una idea).

1. Entrar en la fonera para verificar la versión del firmware. Era una avanzada, por lo que había que downgradearla
2. Resetear la fonera para downgradear el firmware (pulsando reset entre 30 y 40 segundos)
3. Una vez reseteada, configurar la interfaz cableada poniéndola con ip fija (ya la tenía así, pero al resetear se pierde la configuración)
4. No permitir que la fonera se conecte a internet para que no se actualice el firmware, abrir un script que hay por la web para hacerle un chanchullo al cacharro y que me permita acceder por ssh
5. Acceder por ssh y cambiar unos cuantos parámetros para que me permita el acceso por redboot y que no se actualice el firmware
6. Acceder por telnet para cargar los ficheros del redboot y alguna cosilla más. Reiniciar la fonera
7. Acceder por redboot para cargar parte del firmware nuevo
8. Enchufar la fonera, esperar 5 segundos, abrir una sesión telnet antes de que pasen 8, cancelar el arranque para que no se cuelgue (flipa) y cargar más cosillas del firmware
9. Reiniciar la fonera con el firmware nuevo

Algunos de esos pasos, como ya dije, estaban incompletos, erróneos o directamente no aparecían en los tutoriales (como esa sesión telnet antes de 8 segundos tras enchufar la fonera), por lo que pensé que la había jodido varias veces (tras algunos de esos pasos intermedios, la fonera deja de funcionar correctamente, y ya no es accesible de forma normal).

Servidor de descargas con mldonkey (III)

Por razones que no vienen al caso, me vi en casa con mi PII 400MHz aburrido y más parado que un avión de mármol, así que me decidí a buscarle utilidad. Pregunté a la gentuza del foro de teleco y la solución que más me gustó fue la de montar un servidor de descargas. Ya había hecho algo parecido tiempo atrás, pero no había terminado de cuajar la idea.

En fin, vamos al turrón. Hasta ahora la red de mi casa era algo tal que así:

Como veis, había 2 ordenadores cableados conectados a un router, con las ips 5 y 6 de la red 0, así como una fonera. La fonera tenía la ip 2 de la red 0 para la interfaz cableada, y la ip 3 de la misma red para la interfaz wifi. A la fonera se conectaba una nintendo DS configurada mediante DHCP. El router, con la ip 1 era el encargado de proveer acceso a internet a todos los elementos de la red.

Pues bien, me puse al tajo. Lo primero fue instalar el sistema operativo en el otro equipo. Tenía pensado que este cacharro estuviese a pelo, con el mínimo número de programas instalados, por lo que decidí instalar como sistema Linux Debian (mentira cochina, eso ya tenía pensado hacerlo ) y tenerlo sin entorno gráfico ni monitor ni teclado ni nada. Pues nada, me hice con el disco de debian stable netinstall y me puse a ello.

PRIMER PROBLEMA: tenía que conseguir que el cacharro utilizase un receptor wifi USB en modo texto, sin ningún tipo de asistente. Una vez instalado, estuve un rato trasteando con ifconfig e iwconfig, y me salían unas cosas más bien raras, a pesar de que el receptor era detectado sin problemas. Lo que ocurría era que a pesar de que lo detectaba, le faltaban los drivers del mismo, ya que el kernel de linux no incluye los drivers de los receptores ralink. Pues nada, no es problema, me hice a través del otro ordenador con los módulos adecuados, los metí en un pendrive y los cargué en el equipo viejo.

SEGUNDO PROBLEMA: los módulos para el receptor son de la rama testing, y en el ordenador antiguo había instalado la rama stable. Al intentar meterlos, me salió un laberinto de dependencias incumplidas que, a pesar de intentarlo, no conseguí solucionar. Al final opté por replantearme la situación, formateé e instalé debian testing (me tuve que bajar el disco entero, no me valía la netinstall). Una vez hecho ésto, sólo tuve que instalar aparte el firmware del receptor (sólo el firmware, nada más), y el paquete wireless-tools.

TERCER PROBLEMA: esta vez el receptor funcionaba correctamente (lo probé instalando el aircrack para hacer un esnifado del aire en sí xD [descargado desde el otro equipo, claro]), pero no tenía muy claro cómo hacer para que se conectase a la fonera sin ningún asistente. Tras un par de consultas a google y a un par de colegas, di con la solución. Lo que hay que hacer es poner ésto en /etc/network/interfaces

iface *dispositivo* inet static
address *ip para el dispositivo*
netmask *mascara de subred*
gateway *ip de la interfaz wifi de la fonera*
wireless-essid *nombre de la red wifi*
auto *dispositivo*

En mi caso, decidí hacer unos cambios a la red. Puse la red cableada como red 0, y la red wifi como red 1, por lo que ahora la fonera pasaba a tener la ip 192.168.1.1 como interfaz wifi. La red ahora tenía ésta pinta:

Por tanto, mi fichero quedó tal que así:

iface wlan0 inet static
address 192.168.1.5
netmask 255.255.255.0
gateway 192.168.1.1
wireless-essid wlan
auto wlan0

Servidor de descargas con mldonkey (II)

Los que como yo seáis linuxeros probablemente conoceréis (al menos os sonará) el initram. No voy a saber definiros exactamente cuál es la función de esta cosa, pero bueno, grosso modo carga el arranque del sistema en memoria. De hecho, para que el arranque sea más rápido, podemos hacer una imagen initram del kernel, que se cargará durante el mismo. En cualquier caso, la funcionalidad del initram no es lo que me trae hoy aquí, sino ésto:

¿Mensaje oculto? ¿Publicidad subliminal? ¿Patrocinio secreto? ¿Serendipia?
Quizás la respuesta a la duda es: otra forma de perder el tiempo

Los que me conocéis informáticamente hablando, sabéis que, como dice Elrohir, soy un linux terminal cowboy, o lo que es lo mismo, un oscuro adorador de la línea de comandos. Si puedo hacer algo por línea de comandos, por norma general lo prefiero antes que hacerlo a golpe de ratón, porque es mucho más rápido, más eficiente y, para mí, más cómodo. Ya demostré muchas veces ante amigos que este método nos facilita mucho la vida si tenemos que hacer tareas repetitivas, y una vez más volví a demostrarlo. Al turrón.

Después de unos cuantos años me di cuenta de que el método que uso para nombrar los vídeos y fotos que grabo no es el más adecuado a la hora de almacenarlos en el ordenador. Hasta ahora usaba nombres del tipo lugarexacto, lugargeneral, dd-mm-aaaa (tema).jpg, poniendo el mes en números romanos. Por ejemplo, Restaurante Candilejas, Vigo, 9-II-2005 (Pepito de los palotes y su prima).jpg. Este nombre tiene varios problemas. El primero es que si sacamos una foto el día 23 en el mismo sitio, esa foto saldrá antes, ya que el 2 va alfabéticamente antes que el 9. Además, si sacamos una foto el 8 de cualquier mes o cualquier año, seguirá yendo antes que ese 9 de febrero. Otro inconveniente es que al poner el mes en números romanos, septiembre (IX para los no duchos xD) irá antes que mayo (V). Para solucionarlo, la mejor forma sería poner los nombres con el formato lugarexacto, lugargeneral, aaaa-mm-dd (tema).jpg, con el mes en decimal. Pero claro, es muy fácil decirlo, pero agobia un poco más si tenemos en cuenta que entre vídeos y fotos tenía almacenados unos 3500, y eso son muchos nombres de dios para cambiar.

¿Qué hacemos? ¿Nos pegamos un tiro porque no podemos cambiar todo ésto ni en 2 años? Nada más lejos de la realidad. En 4 minutos me curré un script que cambió todos esos nombres por mi, y en sólo unos minutos ya tenía todo con los nombres con el formato que quería. Es una de las ventajas de ser un linux terminal cowboy, estas cosas están a la orden del día . Aquí os dejo el script, que aunque no vayáis a hacer esto en concreto, seguro que podéis retocarlo para algo que necesitéis (Por supuesto, es mejorable, pero lo único que quería era acabar cuanto antes xD).


#!/bin/bash

mv salida/* .
rm -fr salida


Si os preguntáis por qué copio los ficheros en lugar de directamente renombrarlos, tiene una explicación muy sencilla. Si por casualidad alguno de esos ficheros no tuviese el formato de fecha deseado, podríamos perder datos que tenemos en ese nombre y que no querríamos perder por nada del mundo. De esta forma siempre tenemos los ficheros originales con su nombre y demás.

Bueno, tras un tiempo utilizando el iPod, creo que ya tengo una opinión bastante depurada en cuanto al reproductor de apple. Para los que estéis un poco desconectados, me habían tocado un iPod shuffle y un iPod video 80GB en un concurso hace unos meses, y desde entonces me dediqué a hacer experimentos diversos para comprobar qué podía y qué no podía hacer con ellos (siempre en el sentido de las cosas usuales; no probé linux en el ipod ni le metí ninguno de esos programas para cambiar el interfaz).

Antes de nada decir que el soporte para los que utilizamos Linux es peor que deficiente. Está más que claro que apple intenta barrer para casa con este cacharro y que la gente se pase a mac+macOS, porque si no, no me lo explico. Los pocos programas que hay por norma general funcionan bastante mal, pero bueno, eso ya lo había comentado. Pasamos al despotrique.

El iPod es un buen reproductor en el sentido de que reproduce las cosas bien, pero tiene MUCHOS inconvenientes. Para empezar, los formatos. No reproduce wma, no reproduce ogg, no reproduce nada que no sea mp3, aac o wav. En cuanto a video, no reproduce prácticamente nada. Solamente mov y mp4, y aún así el mp4 con muchísimas limitaciones. Además reproduciento video la batería vuela (nada que no sepáis). Dura muchísimo más la batería de la Nintendo DS reproduciendo a 2 pantallas que la del ipod reproduciendo a una sola (siempre con el brillo al mínimo, claro). En fin, el disco duro es lo que tiene, es un fagocitador de batería. Por otro lado, con esta basurilla no funciona el drag and drop. Si queremos meter algo, cualquier tipo de contenido, a la fuerza tenemos que pasar por software que edite la base de datos. Si no, el cacharro no sabe qué es lo que tiene metido.

En cuanto a reproducción, la reproducción es correcta en lo poco que soporta y una vez que nos volvimos locos para meterlo dentro. La calidad de los mp3 es impecable, los videos se ven perfectamente y las fotografías también. La verdad es que la pantalla tiene una calidad asombrosa para su tamaño, y presenta más resolución de la que pueda parecer (320×240, que en ese tamaño es muy aceptable).

Y ahora vamos a prestar un poco de ayuda a los atormentados usuarios de linux que os estéis volviendo locos con esta cosa. Para introducir canciones en el iPod, nada más sencillo que usar el amarok. Está perfectamente preparado para la tarea y no da ningún problema. Con las fotografías, la cosa está un poco más complicada. Hay un programa llamado Gpixpod que funciona de una forma bastante sencilla y es relativamente fácil ponerlo a andar. Sin embargo tiene una gran limitación. Si metemos en el iPod una gran cantidad de imágenes (del orden de 3 gigas) tarda exageradamente a la hora de leer la base de datos (del orden de hora y media). Para solucionar esto tenemos que activar la opción de crear las previsualizaciones en el equipo y no en el ipod. Esto hace que se cree una réplica de lo que mete en el iPod en nuestro disco duro (no sé por qué), así que estaremos ocupando en el ordenador 3 gigas de forma totalmente estúpida. La alternativa a este programa tan desastroso es el tripod. Es un programa realmente sencillo que funciona sin problemas, pero a mí me costó instalarlo debido a que me daba un buen montón de errores. Ahora no puedo ayudaros con ésto porque no recuerdo qué problemas me daba, pero podéis ir apañándoos si tiráis de google a cada error. Con 3 o 4, el programa está instalado xD.

Y ahora vamos a la parte dolorosa, el video. Para meter los videos en el iPod, un programa muy sencillo de utilizar es el gtkPod. Los videos se meten como si fuesen canciones y no dan ningún tipo de problema. El problema viene a la hora de convertir los videos para que funcionen en el iPod. Por más que busqué no encontré nada que funcionase, así que me curré un pequeño script que a más de uno le solucionará la vida. Para que funcione, tenéis que instalar el ffmpeg con soporte para xvid y aac. Para eso, vais a la página de ffmpeg e instaláis la versión SVN

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

Una vez hecho ésto, compiláis el programa con soporte para xvid y aac. Para eso, podéis ver las opciones disponibles con ./configure –help. Creo que para el soporte para esas dos, era algo así como ./configure –include-libxvid –include-libfaac. En cualquier caso, verificadlo.
Una vez compilado e instalado, lo único que tenéis que hacer es meter todos los videos que queráis convertir en el mismo directorio. El script crea 2 directorios, procesados y salida, e introduce los videos originales en “procesados” y los aptos para el iPod en “salida”. Hay un pequeño número de videos con el que da error y el fichero de salida es de 0 bytes. Es debido a algún tipo de compatibilidad con el formato original del video, pero bueno, pasa con muy pocos y no parece algo fácil de solucionar, así que preferí dejarlo así. Para dudas, consultas, insultos y mejoras del scirpt, ya sabéis dónde estoy.


#!/bin/bash
mkdir procesados
mkdir salida
for i in [ *.asf *.avi *.mov *.mp2 *.mpg *.mpeg *.ram *.swf *.wmv ] ; do
ID1=$i
ID2=`echo $i | cut -d. -f1`
ffmpeg -i "${ID1}" -acodec libfaac -vcodec libxvid -b 300kb -s 320x240 -f mp4 "${ID2}".tmp
mv "${ID1}" procesados
mv "${ID2}".tmp salida/"${ID2}".mpg
done