martes, agosto 30, 2011

Waiting for /dev to be fully populated...

Desde hace algunos meses me venía mordiendo un bug extraño en la máquina de trabajo donde a partir del kernel linux 2.6.39 e incluyendo la versión 3.0.0 el sistema se bloqueaba al inicio (el clásico freeze on boot) justo después del mensaje

Waiting for /dev to be fully populated

Y luego de eso, nada. Curioso, ya que con 2.6.38 el arranque iba de lo más normal, además que el equipo es un clon de los más comunes:

Procesador: Intel(R) Pentium(R) D CPU 2.80GHz
Motherboard: Intel Corp. D102GGC2
VGA: ATI Technologies Inc RC410 [Radeon Xpress 200]
Memoria: 1 GB

Obviamente a esa altura del arranque no hay muchos dispositivos disponibles, por lo que logs como para diagnóstico no tenía ninguno, así que por un tiempo desistí la investigación y me mantuve con el 2.6.38, ya que había que trabajar.

Pero recientemente, aprovechando un día que llegué demasiado temprano, le dediqué unos minutos a este inconveniente que ya me tenía incómodo.

El primer sospechoso fue naturalmente udev, al fin y al cabo era el emisor del último mensaje que veía en pantalla. Diagnosticar problemas con udev es, digamos, un poco tedioso. Si leen el manual de udev encontrarán que en /etc/udev/udev.conf puede establecerse la variable udev_log en err, info o debug para definir la prioridad de los mensajes que serán mostrados en pantalla. Una vez hecho el cambio basta con reiniciar el equipo para ver los mensajes de información o diagnóstico correspondientes.

Desde ya es todo un pergamino de eventos el que va sucediendo en el arranque. Tantos eventos (y sin logging ni forma de recuperar los que ya pasaron) que me resultó imposible encontrar un patrón extraño o una pista siquiera de qué es lo que estaba sucediendo. Opté entonces por el clásico diagnóstico del pobre: conociendo dónde almacena udev las reglas (/lib/udev/rules.d/), fui desactivando las reglas y reiniciando el sistema tras cada cambio. Si el sistema continuaba el arranque luego del mensaje "Waiting for /dev ..." entonces las reglas activadas eran inocentes; si no, alguna de las reglas activadas es la culpable. En algunos inicios no tenía gráfica, en otros no tenía disco, y en la mayoría ni siquiera teclado.

Una especie de búsqueda dicotómica me llevó, en pocos reinicios, a encontrar el archivo presuntamente culpable: 80-drivers.rules. Incluso llegué a determinar que la línea responsable era la séptima. Sin embargo el avance no fue mucho, ya que esta línea carga un montón de módulos en el kernel entre los cuales estan los de teclado y ratón: se ampliaba la lista de sospechosos.

Hasta acá, apenas si moví un paso, pero al menos llegaba a arrancar y controlar el sistema mediante SSH. Entonces un gran compañero de laburo (hat tip a Leandro), iluminado por el conocimiento (o quizá cansado de mis improperios) me recomendó: "¿y si probás cargando los módulos que faltan, uno a uno?".

Entonces iniciamos el diagnóstico del pobre parte II. Haciendo un diff casero entre el lsmod del equipo iniciando con kernel 2.6.38 y uno iniciando con kernel 2.6.39 (sin 80-drivers.rules) llegamos a una lista de unos doce o quince módulos faltantes. Allí, tan cerca, login ssh y a probar cada uno de los módulos... pcspkr, evdev, psmouse, snd_hda_intel, todos cargaban bien... parport, fuse, ok... processor... chan! ahí se tildó todo.

AHA! El módulo processor! Pero ¿qué función cumple ese módulo? O mejor, ¿por qué sigue andando el sistema sin él?. Bueno, resulta que es el ACPI Processor Driver, que no es realmente necesario pero maneja cuestiones útiles tales como los estados de energía del procesador. Si lo recuerdan ACPI ya nos viene dando dolores de cabeza desde hace bastante.

Ya con esos datos, una búsqueda en Google reveló un dato fundamental, aunque se ve que no es nuevo: en ciertos equipos el sistema se cuelga a menos que uno cargue el módulo processor con el parámetro nocst=1.

Así que, de momento, agregué la línea

processor.nocst=1

a los parámetros de inicio del sistema y con eso estoy andando actualmente. ¿A qué se debe el bug? Ni idea, habría que hacer un bisect entre las versiones de kernel 2.6.38 y 2.6.39 para determinar cual es el commit jodido. En cualquier caso, queda como tarea para vacaciones...

martes, agosto 16, 2011

Livepass es una mierda

Me lo venía aguantando... Conocen el sitio de venta de entradas Livepass? No? Qué suerte que tienen! Yo lamentablemente lo conocí cuando intenté comprar entradas para el show de Roger Waters. Como un gran número de gente (llegó a trending topic en Twitter) encontré que no sólo es prácticamente imposible adquirir entradas por Internet, sino que por vía telefónica es más probable hablar con el rey de Francia a que te atienda algún operador de la empresa.

El sitio web se les cae a pedazos... evidentemente no han previsto y/o no tienen la más remota idea de como manejar un pico de tráfico... por si fuera poco está hecho con ASP en IIS, no me extrañaría que el backend sea una base de datos Access 2003... No sólo da time-outs y fallos a mitad de las transacciones; falla hasta el procesador de pagos (NPS, otro responsable del quilombo) incluso luego de haber cargado la tarjeta. Por si fuera barato el “cargo por servicio”, de qué servicio me están hablando?

Y si las caídas frecuentes no son suficiente escarnio, como medida “paliativa” se les ocurrió agregar una demora al ingreso:

Welcome! Por favor aguarde unos instantes, Ud. a ingresado a una sala de espera y sera redireccionado en unos minutos para poder adquirir sus entradas.

Welcome! ... Ud (H)A ingresado ... (y la traducción?? y el corrector ortográfico??!!) Además de que la demora no es otra cosa que un meta refresh que actualiza la página cada 20 segundos, es decir, el equivalente a pasársela apretando F5 todo el día, nada de cola de espera por orden de llegada ni un control más efectivo, acá gana el que tiene la latencia más baja y los hue*os más grandes. Si llego a conseguir UNA entrada, obviamente voy al recital con una remera que diga en grande ME CAGO EN LIVEPASS, LA PRÓXIMA VENDAN ENTRADAS PARA CARAMELITO.

Para colmo de males, a la mediatarde surge en twitter un detalle de la página de la empresa. Un video con el título “NO ANDA NADA WANDA NARA” y un enlace al video de Anonymous. Inside joke? I hope so! Pero que oportuno, me deja mucho más tranquilo saber que es una empresa que protege los datos de sus clientes igual que protege a su (paupérrima) infraestructura...

Update: parece que algunos usuarios han encontrado una mejor forma de expresar su cariño. Tienen todo mi apoyo.

Contra esto hay que quejarse. Informen de esta falta de respeto a la gente del show (help@rogerwaters.com / tickets@rogerwaters.com) que responden personalmente y a Defensa del Consumidor. Update: también recomiendan publicar su experiencia en tema abierto en el foro del artista e informarse sobre como denunciar estos abusos en Protectora.org.ar. Otro más: los que quieran saber hasta donde llega la estafa, lean este excelente (e indignante a la vez) post en T!.

En resumen, si quieren aprender cómo se hace una venta por internet para el orto, aprendan de Livepass. En el remoto caso de que algún productor de espectáculos llegue a leer este post, por favor le pido encarecidamente que evite contratar a esta empresa de novatos.

PD: me hicieron calentar... y no es que los demás sean mejores eh. He tenido dolores de cabeza similares con TicketPortal, Ticketek, EntradaPlus, y demás... todos tienen sistemas de venta hechos por los amiguitos de mi sobrino de 6 años. Aprendan a laburar, inútiles!

lunes, agosto 15, 2011

Sobre el bloqueo a leakymails

Hace unos días, Fabio publicó en su blog una buena nota de opinión sobre el bloqueo en Argentina al sitio LeakyMails. Yo que ya venía medio indignado con este tema, aproveché la ocasión para descargarme con el comentario que transcribo, que va a colación de otros sumamente interesantes. Sepan disculpar el auto-bombo...

A ver si alguno me puede aclarar algo... desde mi ignorancia puedo pensar en algunas formas de bloquear un sitio web, Uds. me podrán iluminar con muchas más:

1) bloquear la resolución DNS del nombre de dominio, lo que requiere que todos los servidores DNS de ISP de la Argentina deniegen tal solicitud, por lo que bastaría con apuntar los resolvers a los de OpenDNS u Google (8.8.8.8) para zafar.

2) bloquear el acceso a la dirección IP que hostea el sitio, que fue el *moco* que se mandó Telecom, bloqueando a su vez el acceso a buena parte de blogspot.com y,peor aún, mail-attachment.googleusercontent.com (que es desde donde gmail descarga los adjuntos)... Sí, señora, por eso Ud. no pudo bajar las fotos de su nieta estos días.

3) bloquear el acceso según la URL que aparece en la cabecera HTTP de cada paquete dirigido al puerto 80. Lo que implica que todo ISP de la Argentina tendrá que analizar cada una de las cabeceras de capa de aplicación de cada uno de los paquetillos que pasen por su red, por si registrar los sitios que visitamos y "caparnos" la velocidad no fuera agravio suficiente.

Ahora, y es mi opinión.. hay que ser muy bol^Wignorante para "DECRETAR PREVENTIVAMENTE el bloqueo por parte de los proveedores locales de servicios de Internet en el acceso..." sin tener la menor idea de cómo funciona la red por debajo. Cualquiera de estos métodos es un engorro para todo ISP, además que pueden aparecer mirrors del sitio cada dos días y medio, y así van a seguir jugando al gato y al ratón.

Pero aún así, es mayor el abuso del que estamos siendo víctimas los usuarios finales con este tipo de decisiones chabacanas. Este fallo ya ha sentado precedencia, y de esto a bloquear cualquier otro sitio por el motivo que se le cante a alguno de los del tope de la pirámide hay, lamento decirlo, pocas teclas de distancia.

Fíjense que acá no hablo siquiera del contenido del sitio, que para el caso podría haber sido de correos verdaderos, apócrifos, o de recetas de cocina tailandesa.