Al conectar la segunda impresora, exactamente igual que la primera, la detección fue también satifactoria. Aunque surgió un pequeño gran problema: al imprimir sobre ésta última, la impresión se realizaba sobre la primera. Observando la configuración de ambas, me percaté de que tenían exactamente el mismo Device URI.

La solución fue bastante rápida: editar el archivo /etc/cups/printers.conf, y cambiar el device URI, que era algo así como “usb:/Samsung…” por “file:/dev/usblp0″, y la otra impresora por “file:/dev/usblp1″. Con esto el problema fue resuelto y todo comenzó a funcionar como uno esperaba. Aunque no tardó en surgir otro inconveniente.

Después de un tiempo de estar funcionando todo de mil maravillas, la cajera me comenta un día que, para sorpresa de ella, las facturas A se imprimían en la impresora para las facturas B, y viceversa. Me había comentado que no fue mucho problema, ya que simplemente cambió las hojas y tema resuelto. Pero desde ese mismo instante no me quedé muy tranquilo.

Después de un tiempo recibo una nueva llamada: las impresoras estaban enloquecidas. Todos los días, al encender la PC, los puertos se cambiaban. Lo que en el principio era una pequeña molestia, ahora se estaba transformando en una situación bastante irritante. No estaba seguro cómo solucionarlo, así que por lo tanto intenté una actualización del sistema, lo que en apariencias lo había solucionado. Duró uno o dos meses más hasta que el problema reapareció.

Entonces esa vez me puse a buscar un poco más, a preguntar, y me encontré con udev. Este componente del kernel Linux, encargado de gestionar dispositivos, permite, entre muchas cosas, crear reglas para: nombrarlos de una forma distinta (cambiar “sda1″ por “mi_disco”), agregar links simbólicos cuando se cumplan ciertas condiciones, ejecutar comandos ante ciertos eventos, y mil cosas más.

Lo que tuve que hacer, entonces, es buscar algún tipo de información en los atributos de cada impresora, que sea único para la misma. Para esto utilicé el comando udevadm:

$ udevadm info -a -p  $(udevadm info -q path -n /dev/usblp0)

[...]

  looking at parent device '/devices/pci0000:00/0000:00:1d.3/usb5/5-2':
    KERNELS=="5-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="c0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="1368"
    ATTRS{idVendor}=="04e8"
    ATTRS{idProduct}=="3301"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="16"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="5"
    ATTRS{devnum}=="2"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Samsung Electronics Co., Ltd."
    ATTRS{product}=="ML-1660 Series"
    ATTRS{serial}=="Z526BKDZ800022B."

El atributo serial es el que difiere en cada impresora, por lo tanto utilicé éste para crear un archivo /etc/udev/rules.d/impresoras.rules con las siguientes reglas:

SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKAZ301606A.", SYMLINK+="impr_fa"
SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKDZ800022B.", SYMLINK+="impr_fb"

Una vez guardado el archivo, hacen un “service udev reload”, desenchufan y vuelven a enchufar las impresoras, y verán que aparecen los dispositivos “impr_fa” e “impr_fb”. Ahora estos serán siempre fijos y aputarán siempre al mismo dispositivo físico (en teoría, les cuento en unos meses). Tal cual lo que estaba buscando. Si hacemos un “ls” vemos:

$ ls -l /dev/impr*
lrwxrwxrwx 1 root root 7 2011-02-22 07:34 /dev/impr_fa -> usb/lp1
lrwxrwxrwx 1 root root 7 2011-02-22 10:25 /dev/impr_fb -> usb/lp0

Pueden encontrar más información sobre cómo escribir reglas udev en este link. A mí me vino muy bien para las impresoras, pero se podrían hacer cosas interesantes con pendrives y otros dispositivos.

Cuando les mostré esto a César y a Nacho, nos preguntábamos si en Windows será posible hacer algo similar. Una de las respuestas fue: “estas cosas [impresoras enloquecidas] no pasan en Windows” y “seguramente debe tener alguna forma de configurarlo”. Solo por curiosidad: ¿alguien tiene alguna información al respecto?

Arquitectura de Buildbot

Buildbot permite configurar de varias formas el modo en que va a obtener el código fuente del proyecto y cómo realizará las actualizaciones subsiguientes. Por ejemplo, el modo “update” hace que las operaciones de checkout/update se ejecuten en el directorio de trabajo, y no en uno independiente, como en el modo “copy” o “clobber”, que mantienen un directorio separado y limpio del repositorio (en el caso de Mercurial, “copia de trabajo” en el caso de Subversion) y hacen una copia del mismo para realizar la compilación (esto asegura que siempre se compile todo y que no influyan archivos generados en procesos anteriores, además de otros problemas menos comunes pero que existen).

El problema que estuve teniendo es cuando utilizo Mercurial. Al intentar traer el código fuente, Buildbot entra en un bucle infinito donde realiza el checkout (clone), borra el directorio, otra vez clone y asi… me pareció rarísimo el comportamiento. Versiones anteriores de Buildbot con versiones anteriores de Mercurial funcionan bien.

En uno de los pasos para realizar el checkout/update, Buildbot verifica si ha cambiado la URL del repositorio. Si esto es así, entonces hace clobbering, o sea, vuelve a bajar todos los cambios (checkout) y obviamente no realiza un update, aunque el modo no sea “clobbering”. Para saber si dicha URL ha cambiado, ejecuta un “hg paths default” en el directorio de trabajo y lo compara con la URL asignada en el archivo de configuración central del Build Master.

El bug está en que al ejecutar “hg paths default” Mercurial 1.3.1 devuelve el password oculto con asteriscos:

$ hg paths default 

http://miltondp:***@url.mi_proyecto.com/path/al/repo

… y, obviamente, la URL asignada en el archivo de configuración está completa (sin el password oculto). Al compararse ambas, son distintas, y por lo tanto siempre se hace clobbering.

Rápidamente me fijé si Mercurial poseía alguna opción para mostrar el password en la salida de “hg paths”. No posee dicha opción por lo visto, pero me encontré con un parche que alguien envió alguna vez, el cual parece que nunca fue incluido. El mismo agrega la opción “–show-passwords” para mostrar la URL completa al ejecutar “hg paths”. Lo pueden bajar aquí. El archivo a parchear es “/usr/lib/pymodules/python2.6/mercurial/commands.py”.

También hay que parchear Buildbot para que utilice esta nueva opción al comparar los repositorios. Este otro parche lo pueden bajar desde este lugar. Tener en cuenta que el archivo a parchear tiene el mismo nombre que el de Mercurial. El path del mismo es “/usr/lib/python2.6/dist-packages/buildbot/slave/commands.py”

No se olviden de reiniciar el servicio de Buildbot, y de borrar los archivos .pyc de Python (por lo visto a veces funciona aunque no lo borremos). Ahora el ciclo funciona como uno espera:

$ sl
El programa «sl» no está instalado actualmente.  Puede instalarlo escribiendo:
sudo apt-get install sl
bash: sl: orden no encontrada

La primera vez que lo vi me pareció extraño, así que instalé el paquete “sl” como me sugería. La descripción del paquete es esta:

Correct you if you type `sl' by mistake
Sl is a program that can display animations aimed to correct you
if you type 'sl' by mistake.
SL stands for Steam Locomotive.

Me imagino que tendrán ahora la intriga de qué es lo que pasa si ejecutan “sl”. Simplemente tengan cuidado

Escenario

La máquina que tendrá el servidor DHCP, TFTP y compartirá Internet es mi notebook, que se llama wasabi (a mí si me gusta el nombre ). La PC target se llamará tellus. Desde mi notebook me conecto a un router via wifi (el cual me brinda Internet), y a tellus por cable. La interfaz de la primer conexión es wlan0, y la de la segunda eth0.

Procedimiento

wasabi

• En wasabi solamente es necesario tener dnsmasq instalado (hará de servidor DHCP y además tiene un server TFTP incluido).
• La IP de wasabi será 192.168.0.1
• Editamos las opciones en /etc/dnsmasq.conf. Agregamos las siguientes lineas (asegúrense de que el archivo no tenga otras opciones conflictivas activadas):

listen-address=192.168.0.1
interface=eth0

dhcp-no-override
dhcp-range=192.168.0.30,192.168.0.60,12h

dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/ftpd

• Coloquen el CD de Ubuntu Server (o la versión que sea) en su lectora, y copien los archivos necesarios para realizar la instalación por red:

$ sudo cp -ar /media/cdrom0/install/netboot/* /var/ftpd

• Otra opción al paso anterior es bajarse los archivos desde Internet, para Intrepid o para Jaunty por ejemplo.
• # sudo service dnsmasq restart
• En este punto ya tenemos andando dnsmasq, como servidor DHCP, DNS y TFTP.
• Activamos IP Masquerading:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

• Como les dije, tellus no puede bootear directamente por red, así que es necesario crear un disquette con gPXE. Tienen que elegir el modelo de placa de red exacto de la máquina target (tellus en este caso) para poder bootear, traer la imagen desde wasabi y arrancar la instalación. Una vez bajada, pueden grabarla en un disquette (que difícil conseguir un disquette estos días… y uno que ande) con dd en GNU/Linux o rawwritewin en Windows.

tellus

• Colocan el disquette creado y bootean desde él. Deberían ver cómo la máquina target pide una IP y arranca el instalador de Ubuntu.

Listo, eso es todo. Un inconveniente que tuve fue resuelto con la opción “dhcp-no-override” que les mostré arriba, para dnsmasq. Resulta que en modo normal no arma paquetes DHCP del todo estándar, y que hacían tellus no pueda encontrar la opción de “archivo de booteo” al recibir el paquete DHCP.

Intenté agregarles el número de página con OpenOffice.org, usando el plugin pdfimport. Parece que el funcionamiento consiste en convertir el PDF a un documento de Draw. El problema es que no encontré, por lo menos en forma directa, cómo agregar un pie de página en esta aplicación.

Me encontré con una solución que explica cómo hacer todo con un script (usa pdftk) y un poco de OpenOffice.org. No se si es la solución más rápida, directa y obvia, pero ahora mi PDF tiene los números de página.

Estas son algunas de las cosas interesantes que vimos:

Transferir paquetes .deb hacia otras máquinas

Mariano comentó esto, y lo investigamos un poquito. Es una idea para los usuarios de Ubuntu que tienen que actualizar cada 6 meses. Cuando lo hacen, tienen que instalarse los paquetes que usaban, y eso lleva tiempo. Pero el problema es que uno instala los que se acuerda, después cuando necesita urgentemente editar un archivo SVG, recuerda que no instaló Inkscape, y sumado a una conexión no muy rápida (o si uno está con la notebook en un lugar sin acceso a Internet), se vuelve molesto.

Otra aplicación podría ser en un evento como la FLISOL: Sería bueno tener una instalación con todos los codecs y demás cosas necesarias que no vienen por default. Una vez hecho, se pasarían los paquetes a las demás instalaciones, así quedan iguales.

En la máquina que tiene todos los paquetes instalados ejecutamos:

$ dpkg --get-selections > selecciones

Tomamos el archivo selecciones y lo llevamos a las demás máquinas. Allí ejecutamos:

$ sudo dpkg --set-selections < selecciones
$ sudo apt-get dselect-upgrade

De esta forma se instalan los paquetes que estaban en la instalación original. Si queremos que estén instalados exactamente los mismos paquetes, podemos hacer:

$ sudo dpkg --clear-selections
$ sudo dpkg --set-selections < selecciones
$ sudo apt-get dselect-upgrade

El --clear-selections marca a todos los paquetes no esenciales para desinstalar. Así, al hacer un --set-selections marcamos los paquetes que queremos instalar, por lo tanto quedarán los mismos que en la instalación original.

Cabe aclarar que todo esto es teoría Para no estar bajando los paquetes de Internet en todas las máquinas (por ejemplo en la FLISOL), y si no se ha configurado un servidor donde adquirirlos, entonces podríamos bajarlos primero en una máquina. Los mismos se almacenan en /var/cache/apt/archives. Luego, en las demás máquinas, copiamos los archivos .deb en la misma ubicación.

Transferencia de archivos fácil

Si tienen dos máquinas conectadas a una red, y no han instalado/configurado Samba, ni SSH, ni NFS... ¿cómo transfieren un archivo? Bueno, una solución es usar netcat. Ejecutamos esto en la máquina que lo va a recibir:

$ nc -l -p 8080 > archivo.tar.bz2

Y esto en la máquina que lo va a enviar:

$ nc ipDestino 8080 < archivo.tar.bz2

Por supuesto, no hay barras de progreso ni nada. Hay que ir viendo con un ls -l el tamaño del archivo en la máquina destino. Cuando éste deja de crecer, entonces la transferencia ha finalizado

Investigué un poco (sólo un poco) sobre los discos duros modernos. Los nuevos discos tienen una tecnología “load/unload”, en contraposición con CSS (Contact Start-Stop). En ésta última, las cabezas de los discos, al no estar éste en uso, quedan sobre la superficie del disco. Si hay movimiento de la laptop cuando ésta está encendida por ejemplo, esas cabezas pueden dañar el disco, entre otros problemas que tiene esta tecnología. En cambio con “load/unload”, la cabeza se mueve a un área especial, reduciendo el riesgo de dañar la superficie. En una laptop (móvil) esto es beneficioso. Otras ventajas son una mayor densidad de datos en los discos, mayor durabilidad (lo que dije antes) y menor consumo de energía.

Hay un límite en la cantidad de estos movimientos que un disco puede hacer, después del cual pueden aparecer problemas. Generalmente los discos duros actuales soportan unos 600.000 (más algunos, menos otros).

En la página del bug de Ubuntu, se menciona la experiencia de una persona con GNU/Linux y estos discos duros. Fea experiencia. En aproximadamente 2 años, usando dos laptops, una como servidor y la otra como workstation, tuvo que cambiar el disco rígido 4 veces. Otro tipo, como se puede leer en este comentario, perdió su disco en sólo 7 meses.

Recién estaba en Ubuntu Gutsy, la distro que utilizo, y el disco realizaba estos movimientos bastante seguido (no saqué cuentas, pero era mucho). Hay veces que parece tranquilizarse un poco, pero en algunos momentos, en un período de 10 minutos, realiza aproximadamente 20 de estos movimientos. Reinicié en Windows Vista Home Premium (que vino con la compra de la laptop), y ahora estoy escribiendo el post allí. El disco se encuentra mucho más tranquilo. Realiza esos movimientos de la cabeza, pero no tan exageradamente. Además la temperatura se mantiene normal (45-48 grados). Todo esto me da un poco de bronca, la verdad.

Bueno, creo que este post será más que interesante para los que usan el sistema operativo del pingüino en sus laptops.

Al parecer GNU/Linux no se lleva bien con estos discos. Realiza este parkeo, pero rápidamente la cabeza vuelve sobre la superficie (debido quizá a algún logger, o proceso que frecuentemente accede al disco), lo que causa una cantidad exagerada de estos movimientos en un tiempo determinado, y que lleva a reducir bastante la vida útil de los discos duros. Habrán visto que el bug está confirmado en varias distribuciones, y en el caso de Ubuntu la importancia es crítica.

Un usuario, en los innumerables comentarios, deja constancia de que no tiene ese problema en Hardy Heron. Dice que no sufre de los parkeos excesivos (que no aumentan), pero no dice nada sobre la temperatura. Ahora, la solución real a este problema (como dice alguien allí), no es que no se realicen estos movimientos de la cabeza del disco, sino que no se hagan en forma tan excesiva como en GNU/Linux. Las soluciones que se ofrecen son, en vez de soluciones reales o fixes, workarounds. La gente de Debian, por ejemplo, a “corregido” este error de esta forma.

Así que mientras esperamos una solución verdadera, podemos aplicar el fix que se meciona aquí, como indica la descripción del bug en Ubuntu (que por cierto, deberían leerla antes de hacer algo).

Notarán que los parkeos se detienen totalmente (por lo menos en mi disco), pero la temperatura del mismo aumenta. Este aumento también podría afectar la vida útil del disco si llega a ser muy excesivo. Esto es porque se deshabilita APM (Advanced Power Management) en el disco rígido.

Estaría bueno que si alguien con una laptop está usando Ubuntu Hardy Heron, nos de más información al respecto, ya que esto parece más un problema del kernel que otra cosa, y quizá en la nueva versión se haya corregido.

Me animé a instalarlo. Ahora mi router Linksys WRT54GL v1.1 (los que comienzan su número de serie con CL7B) corre una distribución GNU/Linux, OpenWrt. Cuando comencé a averiguar sobre la posibilidad de cambiar mi firmware por un GNU/Linux, me topé con varias cositas que hacían abstenerme. Por ejemplo, en la página oficial animaban a actualizarlo vía web, diciendo que era lo más fácil… pero en otros lugares, como en Linux.com, recomendaban utilizar este método fácil sólo para los impacientes y valientes Aunque en el ejemplo no utilizaban exactamente este modelo, y el artículo es un poco viejo.

Luego me topé con esta otra página. El tipo simplemente decía que si tenés un WRT54GL y querés instalarle OpenWrt Kamikaze (la última versión liberada), lo hagas por la interfáz web y listo. Nada de tftp, ni boot_wait. Así que me animé. Me bajé esta imagen (notar que tiene la versión 2.4 del kernel, ya que la 2.6 tiene problemas con wireless), chequeé que el md5 sea correcto, fui a la página para actualizar el firmware, elegí el archivo, y Upgrade…

Mientras la barra de progreso aumentaba, yo rogaba que no se corte la luz o algo así. Fue lindo ver el mensaje “Successfully upgraded” al final. Sin embargo eso no me dejó del todo tranquilo. Intenté ingresar via web, pero no funcionó… luego recordé que esta imagen oficial no trae webif. Como decían las instrucciones, me conecté via telnet a la dirección del router. Anduvo perfectamente. Así que cambié el password del root y automáticamente se activó ssh y se desactivó telnet.

Tuve que desenchufar y volver a conectar la energía en el modem, ya que aparentemente cambió la MAC del router, y no se conectaba a Internet. Después de eso todo anduvo perfectamente.

El paso siguiente fue activar, inmediatamente, boot_wait. Es una opción del router, que activa algo así como un boot loader. Tarda un poco más en bootear, pero nos habilita a cambiar fácilmente (en teoría) el firmware via TFTP.

OpenWrt tiene un manejador de paquetes tipo APT: ipkg. Con “ipkg install algo” instalan los programas, igual que en cualquier distro basada en Debian. De esta forma instalé webif, ya que la imagen que me bajé (la oficial) no lo traía por defecto. Si quieren una imagen que sí lo traiga, pueden pegarle un vistazo a esta web. Son las imágenes del proyecto X-Wrt.

Si bien todavía no está estable para Kamikaze, webif está muy bueno. Pueden ver algunos screenshots acá. Desde aquí se pueden acceder a gráficas, estado, manejo de paquetes, reglas iptables, logs, cron, opciones generales del sistema, de la red, edición de archivos, etc… muy completo. También es posible tenerlo en varios lenguajes, simplemente instalando los paquetes correspondientes.

Sin embargo, aunque todavía no lo he explorado mucho, el firmware oficial de Linksys parecía brindar más facillidad para realizar algunas tareas como, por ejemplo, filtrado por MAC. En OpenWrt también se puede, obviamente, pero me refiero a webif: no parece facilitar las cosas para realizar ese tipo de filtrado.

Configuración

Esta buena la idea de bridging. Pero complicó, por lo visto, algunas cosas. Digo “por lo visto” porque no tengo muchos conocimientos de configuración de redes. Cuando quería filtrar tráfico de la interfaz wl0 (wireless) no funcionaba. Después de una serie de pruebas concluí que el bridge complicaba las cosas, por lo tanto lo quité, y simplemente ruteo los paquetes entre la red cableada a la inalámbrica. Ahora las reglas iptables funcionan.

Mis archivos de configuración cambiados son:

/etc/config/network:

#### VLAN configuration
config switch eth0
        option vlan0    "0 1 2 3 5*"
        option vlan1    "4 5"

#### Loopback configuration
config interface loopback
        option ifname   "lo"
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

#### LAN configuration
config interface lan
        #option type    bridge
        option ifname   "eth0.0"
        option proto    static
        option ipaddr   192.168.1.1
        option netmask  255.255.255.0

#### WiFi configuration
config interface wifi
        option ifname   wl0
        option proto    static
        option ipaddr   192.168.2.1
        option netmask  255.255.255.0

#### WAN configuration
config interface        wan
        option ifname   "eth0.1"
        option proto    dhcp

/etc/config/wireless:

config wifi-device  wl0
        option type     broadcom
        option channel  5
        option distance 10
        option disabled 0

config wifi-iface
        option device   wl0
        option network  wifi
        option mode     ap
        option ssid     wasabi-depto
        option encryption       psk2
        option key      laClave
        option hidden   0
        option isolate  0
        option bgscan   0

/etc/config/dhcp:

config dhcp
        option interface        wifi
        option start    100
        option limit    150
        option leasetime        12h

config dhcp
        option interface        lan
        option start    100
        option limit    150
        option leasetime        12h

config dhcp
        option interface        wan
        option ignore   1

Entre otras cosas, para permitir forward entre la red wireless e Internet y la red cableada, agregamos al archivo /etc/firewall.user esto:

### WLAN Forwarding
# Entre clientes de la red wireless
iptables -A FORWARD -i wl0 -o wl0 -j ACCEPT

# Acceso a Internet desde la red wireless
iptables -A FORWARD -i wl0 -o eth0.1 -j ACCEPT

# Acceso a los hosts de la red cableada y viceversa
iptables -A FORWARD -i wl0 -o eth0.0 -j ACCEPT
iptables -A FORWARD -i eth0.0 -o wl0 -j ACCEPT

Una cosita que no encontré (en las opciones de webif) es el bloqueo de la interfaz web a todo lo que venga desde la conexión wireless, como sí está en el firmware oficial. Eso no es un problema, ya que al contar con iptables, simplemente bloqueo el acceso a webif y también a SSH:

iptables -A input_rule -p tcp -i wl0 --dport 22 -j DROP
iptables -A input_rule -p tcp -i wl0 --dport 80 -j DROP

En el firmware oficial, esta protección está en nivel de aplicación, no a niver kernel como aquí.

Otras cositas que hice fue quitar los paquetes relacionados con ppp, ya que no los necesito. A esto se lo puede hacer desde la interfaz web, es muy sencillo:

En la misma sección se listan todos los paquetes disponibles que se pueden instalar. También es posible agregar nuevos repositorios o instalar un paquete remotamente.

Algunos problemas y sus soluciones

Para poder acceder a las opciones del router a través de webif o SSH desde la facultad u otro lugar con acceso a Internet, utilizaba updatedd. En la sección “DynDNS” de webif se prepara todo automáticamente al indicar qué servicio queremos utilizar. Yo utilizo FreeDNS, y no está disponible para este servicio. No me había preocupado mucho por esto, así que simplemente saqué una cuenta en DynDNS y listo.

Tengo que aclarar que esto no funcionó muy bien. Las opciones que setea automáticamente webif no son las correctas. Sin embargo, una vez corregido el problema, aparentemente updatedd no se fija, antes de actualizar, si la IP realmente cambió. De esta forma realiza actualizaciones innecesarias, y así la gente de DynDNS terminó por bloquear mi cuenta temporalmente. Dudo que al cambiar la IP realice la actualización, simplemente parece ejecutarse al inicio y no queda ningún proceso en background…

La solución fue directamente quitar updatedd y utilizar un simplemente script desde cron:

#!/bin/sh
#FreeDNS updater script

UPDATEURL="http://freedns.afraid.org/dynamic/update.php?TjdnR25nZTBWNXhlTEN0OXJrMks6MjM1Mzc2MA=="
DOMAIN="router.miltonpividori.com.ar"

registered=$(nslookup $DOMAIN|tail -n2|grep A|sed 's/Address: //g'|cut -f1 -d ' ')
current=$(ifconfig eth0.1 | sed -e '/inet/!d' -e 's/.*addr://' -e 's/[ ].*//')

[ "$current" != "$registered" ] && {
        wget -q -O /dev/null $UPDATEURL
        logger "IP actualizada en freedns.afraid.org"
}

Otras cosas interesantes

Otras de las cositas que me interesaron es un cliente NTP. De esta forma al iniciar el router la hora es sincronizada. No funciona si se utiliza simplemente el comando date para setearla: se borrará al reiniciar el router. Me pareció interesante este servicio, así en los logs, por ejemplo, queda registrada la hora correcta de los accesos, fallas, y demás cositas.

Finalmente, aclaro que hay bastante documentación al respecto. Por ahí no es tan exacta, y cuesta encontrarla, sobre todo porque Kamikaze es un versión bastante nueva, y a veces al leer algunas instrucciones se ve que todavía no fueron actualizadas para esta versión.

Sin embargo no están recomendados por AMD para, por ejemplo, placas Mobility (la que tengo en mi laptop). Pero no importa… funcionan en lo esencial (ya les muestro los resultados), y además el mes que viene sale Gutsy Gibbon (o sea, reinstalación). Los posibles problemas que pueden haber, como con la salida de TV, no me asustan mucho. En todo caso volveré a los anteriores, pero valió la pena comprobar que realmente han mejorado mucho.

Antes de comenzar con todo el proceso de instalación (que pueden encontrar en ésta guía), hice unas pruebas con los drivers viejos (8.34.8) que vienen en Feisty, con la utilidad fgl_glxgears y glxgears. Con la primera, la media de cuadros por segundo fue de 320, con la ventana en tamaño normal. Con los drivers nuevos los valores suben a 490 fps. Una mejora del 53% aproximadamente.

Con la utilidad glxgears las mejoras son del 60%. Muy buena la ganancia en el desempeño. Y encima ahora AMD ha liberado las especificaciones, y esta desarrollando un driver libre con Novell. Fue un gran acierto adquirir un placa ATI