inedit00

Fin de una era

noreply@blogger.com (inedit00) — Thu, 31 May 2012 11:23:00 +0000

Señores, gracias por haber estado aquí.

Hace mas o menos 15 días que decidí abrir un nuevo blog: www.krenel.org. La idea es la misma que este mismo blog pero con dos diferencias:

El dominio es mío. No quiero usar más blogger como plataforma. Por motivos personales me intento alejar lo mas que puedo de los productos de Google.
Está en inglés. Mira, seamos sinceros: mi inglés apesta. ¿Qué mejor que escribir un blog ténico en inglés para practicar un poco? (sisi, vale echarse una novia inglesa es mejor ¬¬' )

Pues estos dos puntos son el motivo de cambio y cese de este blog. No voy a cerrarlo porque hay artículos que creo son interesantes o alguien le puede sacar partido todavía, pero voy a dejar de escribir en él.

Éste es el post número 127. (2^7-1). Me parece un bonito número.

El primer post lo escribí hace unos tres añitos y estoy muy satisfecho con lo que he ido publicando hasta ahora. Y voy a seguir haciéndolo, pero en otro blog y en otra lengua.

De nuevo gracias y espero que algo de lo que he publicado os haya servido.

Un saludo, Jan.

Erlang (V) HTTP reverse proxy

noreply@blogger.com (inedit00) — Fri, 27 Apr 2012 15:41:00 +0000

[Repaso]
Repasemos la infraestrctura: Ahora mismo tenemos un servidor web hecho en Erlang, MochiWeb, que accepta mucha mucha carga.

Este servidor en si mismo no hace el trabajo, sino que deja que un Actor de Erlang (llamado Usuario) se encargue de gestionar la petición. Así conseguimos una concurrencia brutal y soportamos un montonazo de carga[1]. El actor usuario, en caso de recibir un mensaje de otro usuario, devolverá este mensaje al servidor web, que a su vez se lo mandará al usuario final y este lo recibirá en su navegador. Bien. También tenemos en un almacén de datos en memória la gestión de las sesiones (en mnesia): allí se asocia un ID de sessión HTTP con el ID de usuario.

Ahora mismo la arquitectura de la aplicación está pensada para ser ejecutada en una misma máquina, lo que supone algunos problemas: cuando toca reiniciar el equipo debido a actualizaciones de kernel y demás el chat debe permanecer "cerrado". No solo esto, si no que el usuario no recibiría un bonito mensaje de error que diga "We are under maintenance", sinó mas bien un "server not found" o algo así. Algo feo feo. Pero arreglarlo tampoco es algo fácil.

También hay otros pequeños problemas como por ejemplo el logueo de las peticiones HTTP (típico fichero access.log) y ofrecer HTTPS (SSL/TLS).

Veamos una imágen actual de la arquitectura de Gaab Web Chat:

Bien. Tenemos un único punto de entrada directamente al servidor de chat de Erlang. En si mismo esto no está mal, ya que el servidor accepta una concurrencia "que te cagas", pero tenemos los problemas comentados anteriormente. Parece que la solución más simple es (como casi siempre) añadir una capa mas de complejidad y añadir un: http reverse proxy.

[Cherokee]
No explicaré lo que es un reverse proxy (consúltese en la wikipedia, o léase este[2] artículo), pero sí explicaré por qué he elegido Cherokee. Aparte de por que en todos los bencharks tiene unos muy buenos resultados, tiene unos ficheros de configuración con una gestión muy clara, es relativamente nuevo pero tiene un gran comunidad y está publicado bajo GPL es porque el creador del servidor web es español. Si señor. Me ha salido la vena patriótica y me apetece apoyar (ummm... vale, con "apoyar" quizás me he pasado, digamos "usar") un proyecto hecho en casa. Y punto.

Y las primeras impresiones no pueden ser mejores: gestión vía web, creado un virtual host en menos de 1 minuto, creado el http proxy en 5 minutos. Amén. Así da gusto.

La idea es usar Cherokee como balanceador de carga entre diferentes aplicaciones GaabWebChat(Erlang+Mnesia+Aplicacion) que se estarían ejecutando en máquinas distintas. La carga de tráfico sería balanceada entre todas las máquina que pudiese tener la aplicación. En caso de que se tuviese que actualizar la plataforma, sería tan simple como decirle a Cherokee que no mandara más tráfico en aquella máquina, actualizarla tranquilamente, y después volver a dirigir tráfico a la misma.

La arquitectura quedaría algo así:

Mucho mas chula que antes, no? Así Cherokee se puede encargar de gestionar las conexiones HTTP/HTTPS, loguear todos los requests en un fichero "access.log", balancear la carga entre varias aplicaciones y servir contenido estático.

[Mejoras]
Esta plataforma todavía se puede mejorar ya que todavía hay un único punto de fallo, el servidor de Cherokee. Esto se podría remediar poniendo varios Cherokees en diferentes máquinas y balanceando la carga por DNS, por ejemplo. Pero esto ya queda (de momento) fuera del alacance de este post.

Esta solución aquí propuesta es un algo que puede que en un futuro pueda necesitar, pero des de luego no lo incluiré en la primera versión que ponga online, ya que MochiWeb puede soportar muucha carga (estoy seguro que ahora mismo por cada 500MiB de RAM que pueda conseguir en un hosting puede soportar a 5K usuarios).

Pues nada, señores. Un saludo.

P.D: Mierda de Blogger. Las imágenes quedan como el culo, pero tienen que tener este tamaño para que se vean claras. So sorry. Prometo cambiar pronto el blog de sitio :/

[1] Me faltan hacer un par de benchmarks para demostrar que esto es así, pero la pereza puede a uno.
[2] http://www.cherokee-project.com/doc/modules_handlers_proxy.html

Peticiones Ajax en IE8 y cachés: crap, crap, crap

noreply@blogger.com (inedit00) — Thu, 26 Apr 2012 17:53:00 +0000

IE8 apesta. Y por extensión Microsoft también.

[Problema]
Las peticiones por Ajax que lanza IE8 son cacheadas. Todas ellas. Si lanzas un requests por Ajax a la url "/check_mail_box" y el resultado de la petición dice que no tienes nuevos mails, tooodos los demás requests que hagas a esta URL estarán cacheados y realmente ni se volverá a lanzar una petición HTTP para comprobar nada. IE8 es inteligente (o almenos esto cree) y dice: ¿si ya tengo la información, para qué voy a volver a pedirla?

¡PUES PORQUE PUEDE HABER CAMBIADO, CACHO RETRASADO! ¡POR ESTO LANZO OTRA PETICIÓN! ¡PARA COMPROBARLO DE NUEVO!

Calémonos.

[Repasando las bases]

El protocolo HTTP hace AÑOS que se usa en el mundo Web. El cliente hace una petición de un recurso, el servidor busca el recurso y se lo devuelve al cliente. En caso de que se haga otra petición, el proceso se repite.

Hace hace años también que dejó de servirse contenido estático y ahora se están sirviendo contenidos dinámicos, generados por PHP, .NET, CGI y un largísimo ETC... Esto significa que si tu pides un recurso, como por ejemplo "/last_users_connected", el resultado de la petición HTTP puede cambiar en el tiempo, ya que es una información CALCULADA en la parte servidor.

Bien.

Ajax. Ha aparecido hace relativamente poco. Es lo mismo que una petición HTTP pero de manera asíncrona. ¿Qué significa esto? Pues que el usuario puede estar navegando tranquilamente mientras, en segundo plano, se descarga otra información. Muy cómodo para no tener que ir recargando la página cada dos por tres. Pero esto de Ajax es solo un artificio creado por el navegador. En realidad se lanzan peticiones HTTP como las "normales". Exactamente iguales. No hay diferéncia entre ellas.

[Acercándonos al problema]
Cada vez que el usuario entra en "www.facebook.com" el navegador lanza una petición HTTP pidiendo el recurso "/index.html". Bien. Si le damos a F5 (refrescar) o volvemos a abrir en otro Tab del navegador "www.facebook.com", vuelve a lanzar la petición y puede que los resultados del primer tab al segundo tab sean diferentes. Obvio.

Imaginemos que el navegador cachea la primera petición a "/index.html" y que a partir de ahora cada vez que entramos en www.facebook.com nos sirve la versión cacheada. Pues vaya inutilidad, verdad?

[Meollo]

Bien, pues esto es lo que hace IE8 con las llamadas de AJAX.

Se le tiene que decir explícitamente a IE8 que NO haga uso de la caché en las peticiones por Ajax par que funcione de un modo normal. Otro modo de decir lo mismo es que se tiene que instruir a IE8 para que funcione CORRECTAMENTE y como un usuario corriente y moliente esperaría. Va contra la lógica más básica: le estás diciendo al navegador que descargue una información de un servidor (pero de modo asíncrono), y el navegador -por que le sale de los cojones- te devuelve una versión antigua de la misma sin lanzar peticiones ni ostias. Fuck.

[Conclusión]

IE8 apesta.

Y por extensión Microsoft también.

Un saludo, Jan.

P.D: Me pregunto los miles de millones de euros que habrá costado esta decisión por parte del equipo de IE8. Pensadlo, la de librerías que se tienen que adaptar y la de programadores que tienen que aprender la gilipollez esta.

P.D2: He de decir que W7, y IE9 ya parecen SO/navegador decentes, y que parece que las ñapas que había estado haciendo Microsoft hasta ahora (W98, W2000, WMe, WVista, IE{5,6,7,8}) quedan en el pasado. Ya iba siendo hora.

Errores en el manual de bash

noreply@blogger.com (inedit00) — Mon, 09 Apr 2012 11:18:00 +0000

Me aburro. No os creáis, me pasa amenudo. Y no lo veo como algo malo, ya que normalmente para quitarme el aburrimiento hago lo que yo llamo "cosas productivas". Como leer el manual de bash, por ejemplo.

$ man bash

Así de fácil. Y la verdad que está bastante interesante y uno se entera de cosas que no sabia, o entiende cosas en las que hasta ahora dudaba. Pero estoy yo tan tranquilo leyendo el manualillo en mi Kindle[0] en el avión, cuando me encuentro con una cosa que no me ha acaba de gustar. En el apartado REDIRECTION, pone lo siguiente:

Bash handles several filenames specially when they are used in redirections, as described in the following table:

/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a TCP connection to the corresponding socket.

Bueno, hasta aquí no tengo ninguna queja. Estoy conforme con esto. Pero ya no me parece tan bien el siguiente bloque. ¡Ai señor! ¡Cuánto daño ha hecho el copy-paste!

/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number or service name, bash >>>attempts to open a UDP **connection**<<< to the corresponding socket.

O sea, exactamente igual que el bloque de anterior, pero cambiando TCP por UDP. Solo que estos dos protocolos no son lo mismo. Y dá la casualidad que en el protocolo UDP no se establecen conexiones. Y no es porque lo diga yo. Si hacemos un "man udp", podemos leer en la primera línea:

This is an implementation of the User Datagram Protocol described in RFC 768. It implements a **connectionless**, unreliable datagram packet service. Packets may be reordered or duplicated before they arrive.

Connectionless, sin conexiones. Por lo que el término "connection" al lado de UDP ya es incorrecto en si mismo, ya que las conexiones UDP no existen (si eso, se implementan en capas superiores en la pila TCP/IP, o sea, en la capa de Aplicación. Pero en el protocolo UDP no existen conexiones). Además, "attemps to open" también es incorrecto, ya que UDP no intenta "abrir" nada, sinó mas bien intenta mandar el paquete a la red. ¿Que el paquete llega? Bues bien. ¿Que no llega? Pues a UDP se la suda. De hecho el protocolo UDP no sabe ni si ha llegado el paquete[1], ni le importa. Repito, no existe el concepto de conexión en el protocolo UDP.

¿Qué todavía no me crees? Vaya, macho... a ver. RFC793, TCP[2]. Ocurrencias de la palabra connection: 271. RFC768, UDP[3]. Ocurrencias de la palabra connection: ninguna!!!

¿Qué propongo? Pues cambiar la frase a algo así:

If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to send a UDP datagram to the corresponding socket.

Ya he mandado un email al mantenedor del manual de bash, en mi perfecto inglés de mierda (gracias hermana por ayudarme a corregir mi inglesanalfabetismo). A ver que dice. Ya os diré cosas cuando conteste. A ver que le parece a él.

Un saludo, Jan.

[0] Noooo! Tranquilos!! No soy tan bruto como para inslarle Linux en un Kindle! Es simplemente que quería decir que me había comprado el juguetito ^_^

[1] no debería decir paquete sinó datagrama, para ser mas exacto, ya que lo que comunmente llamamos paquetes se trata siempre del nombre del PDU de Capa de Red, o sea, protocolo IP, y ahora estamos hablando de la capa de tranmisión de datos, donte tenemos datagramas en el caso de UDP y segmentos en el caso de TCP, pero bueno..... sé que diciendo paquete ya nos entendemos! Y recordemos que UDP es unreliable y por esto se la suda si llegan o no los paquetes.

[2] http://www.faqs.org/rfcs/rfc793.html

[3] http://www.faqs.org/rfcs/rfc768.html

Actualizando el microcódigo de la CPU (microcode.ctl)

noreply@blogger.com (inedit00) — Sat, 07 Apr 2012 08:32:00 +0000

[Explicación]

Los procesadores tienen un firmware, también llamado microcódigo. El firmware está situado entre el hardware y el lenguaje ensamblador. Mas o menos la cosa iría así:

hardware -> firmware (microcódigo) -> ensamblador -> kernel -> S.O. y aplicaciones

Es un bloque de instrucciones máquina que establece la lógica a más bajo nivel y que está fuertemente ligado a la electrónica subyacente. Pero así mismo, es un cacho de código. O sea, software.

Cuando compras una CPU en una tiena, o te compras un portátil estás adquiriendo un modelo concreto, que viene con una revisión (versión) de firmware concreta. Pero ¿Qué passa si Intel saca una nueva versión de firmware con mejoras, optimizaciones, uso de algoritmos mas eficientes y con menor consumo de energía, corrección de bugs, etc? Pues que no los puedes disfrutar, a menos que instales el firmware nuevo. Y...¿Cómo se consigue actualizar el microcódigo? Pues normalmente no te queda otra que actualizar la BIOS de tu máquina actualizando así el microcódigo de tu procesador.

Pero ya sabes que actualizar la BIOS no siempre es buena idea. Si mientras la estás actualizando se vá la corriente, puedes tirar el procesador directamente, que es irrecuperable. Es algo peligroso. Se puede hacer, pero no es algo que quieras hacer muy amenudo. Enserio.

Cagonlaputa. Entonces, ¿no hay alternativa posible? Si. Si la hay. Almenos en Linux si.

[Conociendo la herramienta]

Hay un hermoso paquete llamado microcode.ctl que hace éste trabajo por nosotros y que se encarga de cargar el microcódigo de manera dinámica en nuestro procesador. Esto significa que no flashea el procesador (no hace los cambios permanentes) sinó que actualiza el firmware del procesador al vuelo y en tiempo de ejecución cada vez que se inicia el S.O. Esto tiene varias ventajas:

Nada de actualizar la BIOS del modo tradicional, por lo que nos evitamos un procedimiento peligroso (y tedioso).
Se descarga automáticamente las nuevas versiones sacadas por Intel y las aplica en el próximo reinicio.
En caso de que se descargue una versión que por lo que sea falla y nos dá problemas, solo debemos desactivar el daemon que se encarga de actualizar el microcódigo del procesador cada vez que se inicia el sistema, y santas pascuas.

[Instalación]

Pff.... ¿enserio que tengo que hacer esta sección? Si las secciones de "instalación" siempre son iguales en Linux :/

$ sudo aptitude install microcode.ctl

...y a correr. En la instalación te pedirá si te quieres descargar también el paquete propietario intel-microcode que contiene las últimas versiones de los microcódigos. Obviamente la resuesta es SI, QUIERO. Y punto. Si vas a ver el fichero /var/log/syslog puede que te encuentres con estas bonitas líneas (pero dependen de la versión de firmware que tengas, claro):

microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2
microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2
microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2
microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2
microcode: Microcode Update Driver: v2.00 , Peter Oruba
microcode: CPU0 updated to revision 0x3, date = 2011-09-01
microcode: CPU1 updated to revision 0x3, date = 2011-09-01
microcode: CPU2 updated to revision 0x3, date = 2011-09-01
microcode: CPU3 updated to revision 0x3, date = 2011-09-01

Un saludo!

Gestor de portapapeles

noreply@blogger.com (inedit00) — Fri, 06 Apr 2012 10:46:00 +0000

Entrada rápida. Parcellite[1] es un gestor de portapapeles. Simplemente pulsando Control+Alt+H te aparece un listado con las últimas cosas que has copiado mediante Control+C, seleccionándolas con el ratón o mediante el teclado. Elige un elemento de la lista y para pegar pulsa una de las siguientes combinaciones de teclas:

Control+V
Shift+Insert
Control+Shift+V

Para programar con Vim es una monada. Pruebalo. Ya. Te encantará.

En mi configuración (a través de GTK) en la pestaña Behavior tengo marcadas solo las opciones:

Use Copy (Control-C)
Use Primary (Selection)
Syncronize clipboards
Save history

Y todo lo demás desactivado.

Un saludo.

[1] http://parcellite.sourceforge.net/

Erlang (IV) Semana 2

noreply@blogger.com (inedit00) — Thu, 05 Apr 2012 15:15:00 +0000

La Semana 1 construímos un core de servidor de chat que hacía bastante bien su trabajo. Ahora el paso lógico es:

Integrar este core con un servidor HTTP
Crear una User Interface (UI) bonita y amigable

[Servidor HTTP]

El primer punto, que al principio no acababa de ver claro, ha sido muy simple. Lo primero de todo era encontrar un servidor HTTP para Erlang. Mis requisitos eran:

Escrito 100% en Erlang. Para no liarnos con otras tecnologías
Que pueda soportar mucha concurrencia. Por motivos obvios en la aplicación que queremos crear.
Con un sistema muy simple de hacer dispatch de llamadas, con controladoras y todo el tinglado. Quería algo que ya te lo diese un poco mascado, pero que fuera altamente personalizable.

El servidor web MochiWeb cumple con todos los requisitos anteriores. El trabajo principal ha sido crear un pequeño dispacher para cada una de las llamadas, para poder ofrecer una interfície restful simple, limpia y clara pero que nos sirva para nuestros propósitos. Para saber exactamente cómo está implementado, que se mire el código (mas sobre esto al final), pero para dar una idea general os enseño la API REST que he creado:

Acción: /login Método: GET. Parámetros: N/A. Explicación: Renderiza la pantalla de login
Acción: /login Método: POST. Parámetros: username, password. Explicación: Loguea el usuario, en caso de que los datos sean correctos, mediante el establecimiento de una cookie.
Acción: /logout Método: GET. Parámetros: N/A. Explicación: Lo obvio
Acción: /msg Método: GET. Parámetros: N/A. Explicación: Éste es el mas importante de todos. Está pensado para ser llamado por AJAX y manetener la conexión abierta durante 20 segundos. Recibe como respuesta un JSON con los mensajes que puedan haber enviado enviado otros usuarios durante estos 20 segundos, la notificación de que otro usuario se ha logueado, etc... Más sobre esto, luego.
Acción: /msg Método: POST. Parámetros: msg, to Explicación: Envia el mensaje msg al usuario to. ¿Fácil, no?
Acción: /users_list Método: GET. Parámetros: N/A. Explicación: Devuelve un JSON con el listado de amigos conectados en este momento.

¿Simple, verdad?

La acción mas interesante es /msg per método GET. Vamos a explicarla un poquito mas. Como comentaba mas arriba, esta llamada devuelve un MIME-type application/json. Nada de XML ni líos, JSON nos va perfecto para este caso, ya que esto lo recibe la parte cliente y tiene que interpretarse en Javascript. Sabiendo que JSON significa JavaScript Object Notation, queda claro que para este caso ésta es la elección ideal. Esta acción está pensado para ser llamado por AJAX, pero también puede ser llamada por el método tradicional sin problemas. Cuando se cree la conexión, ésta permanecerá abierta durante 20 segunos. Durante este tiempo, si se produce algún evento en la parte servidor como por ejemplo recicibir un mensaje, se mandará el mensaje hacia el usuario a través de esta conexión. Si no hay nada que notificar en 20 segundos, se cierra la conexión y se espera que el cliente abra otra inmediatamente después, esperando así indefinidamente a recibir algún tipo de mensaje.

¿Qué tipo de información devuelve éste método? Pues información que tenga que ver con cambios de estado, mensajes de chat, notificaciones, etc... Veamos los JSON's de posibles resultados:

{"action":"message", "user":"inedit00", "msg": "Hello world!"}
{"action": "friend_logged", "name": "foo"}
{"action": "friend_unlogged", "name": "bar"}
....

Como podeis ver la interfície es muy clara y legible. El action determina qué tipo de mensaje es, y cada mensaje tiene los campos con la información necesaria. Procesar esto en JS es prácticamente un chiste. Mirad, así, en pseudo-javascript y para que os hagáis una idea:

MessageHandler = {
message: function(request) { alert(request.msg) },
friend_logged: function(request) {alert("The user " + request.name + "logged in")},
.....
}
var process_http_response = function(html) {
json = JSON.decode(html)
MessageHandler[json["action"]](json)
}

nada... un juego de niños. La ventaja de utilizar algo así es que para añadir una acción más, simplemente hay que mandar un mensaje distinto y crear su handler en el código JS. Obviamente el código JS está pensado para ignorar todos los mensajes con un action para los que no tiene handler.

Total, que con todo esto ya tenemos una manera de mandar mensajes a otros usuarios en el sistema des de la parte cliente (JavaScript) y que sean recibidos por otros usuarios mediante HTTP. Genial.

[User Interface]

Bueno, esto simplemente es HTML+CSS+JS. Aquí no hay mucho que contar. Si alguien se lo quiere mirar que vaya al repositorio y mire el código fuente de todo el percal (es poquito y simple). Os dejo con el número de líneas que he usado para cada una de las cosas, y un par de capturas de pantalla, y arreando....

Página principal /index 37 líneas de HTML
Página de login /login 31 líneas de HTML
Fichero con todos el CSS's del proyecto: 98 líneas
Fichero con todo el JS del proyecto 195 líneas. Incluye la creación, cambio de tamaño/posición de las ventanas de chat, control de las conexiones por AJAX al servidor y los handlers que procesan las respuestas (mensajes nuevos, usuarios conectados/desconectados, etc....)....

Nhá... ha quedado todo muy pequeñito y limpio. Por supuesto nada de estilos inline, ni CSS en bloques style dentro de los ficheros HTML, ni Javascript inline en atributos HTML (¡aberración!) ni demás guarradas varias en el código. Sabéis que si hacéis estas cosas vais a ser sodomizados por Diox durante toda la eternidad, ¿verdad?

En el HTML hay dos imports, uno al CSS y otro al fichero JS y palante toda. Y mas o menos el tema luce así (que siiiiiii, que sé que todo lo anterior que os he contado os la sudaaaa, que coméis por los ojos!! ):

Ahora mismo solo hay un usuario conectado con el que pueda hablar (yo mismo en otro navegador ¬¬'). En las ventana de chat soporta modificación de tamaño, ponerla donde quieras en la pantalla, cerrarla y puedes tener abiertas tantas conversaciones de chat como quieras (siempre que tengas mas amigos, obviamente). Para ser una primera versión sacada en una tarde (HTML+CSS), estoy muy contento con el resultado.

Y nada.... esto es básicamente todo lo que tiene que ver con UI. Los ficheros interesantes del repositorio que tienen que ver con UI son:

/templates/index.dtl
/temlates/login.dtl
/priv/www/js/gaab.js
/priv/www/css/gaab.css

[Repositorio]

¿Repositorio? ¿Quién dijo repositorio? Pues claro que si, hombre! Si trabajas con código y no lo versionas es que te gusta vivir peligrosamente. Seguramente tus hobbies puedan ser hacer puenting sin cuerda, hacer la danza de pescado crudo en playas infestadas de tiburones en Madagascar o intentar ligar con la chica buenorra con el novio culturista.... a saber.

Todal, que tengo todo este código subido a un repositorio de bitbucket para uso y disfrute de todo quien quiera verlo:

http://code.krenel.org/gaab

y esto es todo... quien quiera preguntar alguna cosa, sugerir alguna otra, pedirme que explique algo un poco mas o tenga curiosidad en lo que sea: que me mande una caja de cerveza...... digooooooooo..... que deje un comentario!

Un saludo!

Vim y sus plugins

noreply@blogger.com (inedit00) — Thu, 05 Apr 2012 09:06:00 +0000

Menos pizzas, Vim puede hacerte todo lo demás. Si tienes complejo de pulpo (aka te gustaría tener un par de manos mas para poder usar Emacs como es debido), este post no es para ti.

He empezado a programar con Erlang y hay un par de pluguins a instalar que son indispensables. Es importante recalcar la importancia que tiene tener un entorno de trabajo cómodo y eficiente, para que el trabajo salga mas rápido y mejor.

[Plugin para Erlang]
En el caso de erlang me he instalado vimerl[1] que entre sus muchas características como syntax highlight, code completion, auto-indent, etc... tiene una cosa que es una pasada que ellos llaman el QuickFix. Cada vez que guardas un fichero, comprueba si hay errores de sintaxis, variables no declaradas, variables no usadas, funciones no usadas, y demás... muy cómodo para no tener que hacer el proceso de: compilar, buscar errores en la consola, ver qué fichero y en qué línea han ocurrido, etc... E aquí un ejemplo. Fijaos que en la parte inferior de la pantalla nos pone una descripción del error en donde tenemos el cursor:

Los warnings los marca de color amarillento, mientras que los errores te los pone en rojo. Muy cómodo ya que cada vez que guardas el archivo puedes ver si tienes errores en el fichero o no. Muy chulo.

[Plugins generales]

Mas cosicas. Pues mira, uno que es básico, pero que hasta ahora no me gustaba mucho, es el NerdTree[2](vaya puto nombre feo le han puesto a la criatura). Le he dado una oportunidad y de momento va de lujo. Es un explorador de ficheros, con el que se puede navegar por la estructura de directorios des de Vim:

Cómodo y fácil de usar. Hay dos configuraciones que te pueden hacer la vida mas fácil. La primera es para poder ignorar ficheros, y que no aparezcan en el listado. Añadiendo en el .vimrc la siguiente línea, se consiguen omitir los resultados que hagan match a las expresiones regulares de la lista (en mi caso ignorar loc ficheros *.pyc )

let NERDTreeIgnore=['.*pyc$']

La segunda es añadir un keybinding para mostrar/ocultar el NerdTree. Esto se consigue añadiendo ésta línea en el .vimrc:

map :NERDTreeToggle

El pulsar F2, se abre/cierra el NerdTree. Muy cómodo también.

Y por último, un pluguin que complementa al NerdTree: CommandT[3]. Básicamente es un listado de tooodos los ficheros del proyecto y escribiendo un par de letras puedes abrir el fichero que quieras. Ejemplo:

Digamos que tenemos un fichero en www/back/back/controlers/dashboard.mako. Sería suficiente con escribir 'dash', como para que él ya te lo encuentre. Pero vamos a otro caso mas complicado en el que tenemos:

/www/back/back/templates/foo

/www/back/back/templates/bar

/www/back/back/templates/lala

/www/back/back/widget/foo/template.mako

/www/back/back/widget/bar/template.mako

En este caso, si quremos encontrar el fichero "/www/back/back/widget/foo/template.mako" será suficiente con escribir: "wifte", que se corresponde a:

"wi" de "widget"
"f" de "foo"
"te" de template

Aparte de mi burda explicación que he hecho aquí, recomiendo que mireis el screencast[4] hecho por el mismo creador del plugin.

También crearemos un keybinding para este plugin, de modo que la pulsar F3 se abra automáticamente CommandT. El comportamiento por defecto para ejecutar CommandT es pulsar la combinación t. La tecla es la tecla "\", que en teclado inglés está en una posición muy cómoda, pero en el teclado castellano está a tomar por culo. Para esto la mayoría de gente se redefine la tecla a la coma ",".

map :CommandT

let mapleader = "," " Change the key from \ fo ,

Con estos pluguins tenemos una combinación ideal, ya que si no sabemos qué buscamos, tenemos el NerdTree para navegar por los directorios y encontrar el fichero buscado. Si sabemos el nombre exacto, podemos usar CommantT para localizar el fichero, y palante toda. Por falta de recursos, que no sea.

He probado mas plugins (para buffers, tabs, cerrar paréntesis automáticamente, escribir html automáticament, etc..) pero ninguno de ellos me ha gustado. Pero la verdad que ha valido la pena encontrar estos tres plugins ya que mejoran mucho mi entorno de desarrollo.

Y nada mas por hoy. Un saludo, Jan.

[1] http://www.vim.org/scripts/script.php?script_id=3743 pero mejor descargar la útima versión de https://github.com/oscarh/vimerl

[2] http://www.vim.org/scripts/script.php?script_id=1658 pero otra vez recomiendo mejor bajar la última versión de https://github.com/scrooloose/nerdtree

[3] http://www.vim.org/scripts/script.php?script_id=3025 y digo lo mismo que con los otros dos https://github.com/wincent/Command-T

[4]https://wincent.com/products/command-t

Post relacionado http://inedit00.blogspot.com.es/2010/04/dandole-cana-vim.html . Ahora que lo veo me parece super elemental, pero oye, que de esto hace 2 años y digamos que esto ya lo tengo bastante "mascado", jeje.

Dig Your Own Hole

noreply@blogger.com (inedit00) — Mon, 26 Mar 2012 17:55:00 +0000

[Flame]

Linux es genial, maravilloso, chulo, rápido.... y asquerosamente inseguro. De hecho, cualquier SO de hoy en día lo es, pero cualquier distribución de Linux, por su naturaleza, es mas vulnerable.

[Introducción]
El mejor sysadmin que he conocido me enseñó algo: la seguridad física no existe. És algo muy fácil de entender: si alguien tiene acceso físico a tu máquina, no hay nada que hacer. Des de DoS apagando la misma (ya sea desenchufando el cable o pulsando una divertida combinación de teclas[1]), pasando por ataques de David Hasselhoff[2], borrado de archivos, escalado de privilegios (des de una shell o haciendo truquillos en el grub), poner backdoors o, en caso de que nos pongamos mas serios el mismo robo del equipo y posterior análisis de los datos del disco duro, ataques de red MITM (ARP poisoning, ICMP redirect), hijacking de cookies que viajan por redes WiFi sin protección, y un laaargo etc. El tema está que el ataque se puede producir en cuestión de minutos y hay pocas formas de protegerse contra el.

Una vez el sistema ha sido "tocado" físicamente por alguna otra persona que no seas tu mismo, la máquina deja de ser segura y no te puedes fiar nunca mas de ella. ¿Exagero? Esperad y veréis.

Bueno, vale. Volviendo a la primera frase-flame del post quiero aclarar (o acotar) un poco la afirmación: Todas las distribuciones de Linux por lo general tienen implementaciones de red seguras. Los bugs de software (tanto en los programas en general como en el kernel) son arreglados en muy poco tiempo y uno tiene la opción de ver el código fuente de la mayoría de programas para asegurar que no incluyen sopresas, etc.... y todo esto está genial. Si la máquina se mantiene actualizada es difícil encontrar zero-days o exploit para ganar privilegios. Pero todo esto no es necesario ya que existe algo que se llama consola. Que es muuy potente. Y que en manos de una persona agena (por no bloquear el portátil al ir a responder una llamada de móvil, o en un despiste tonto), y con muy pocos comandos, puede comprometer un sistema en un momentín. Y exactamente sobre esto va esta serie de posts.

Aquí se pretenden recopilar una série de comandos con los que se podrá comprometer un sistema en caso de tener acceso a una consola.

[Al lío]

Ejecutar en una consola:
$ alias sudo="sudo touch /root/owned && sudo"

Nótese que ya se ha `infectado` la consola actual. En caso de que ahora el usuario legítimo ejecute cualquier comando usando "sudo", se le pedirá la contraseña, se ejecutará un comando arbitrario con privilegios de administrador (en nuestro comando de ejemplo 'touch /root/owned'), y después se ejecutará el comando que el había puesto, sin que el usuario se percate que ha ejecutado un comando adicional. Para hacer permanente el cambio se puede ejecutar:

$ echo 'alias sudo="sudo touch /root/owned && sudo"' > ~/.bashrc
Y por ejecución de "comando adicional" podríamos entender: crear un usuario de sistema con privilegios de administrador, ejecutar un borrado de todo el disco, instalar un backdoor, programación de una tarea de descarga de un script remoto y ejecutarlo con privilegios de root o peor todavía: cambiar el fondo de pantalla[2].... Vamos, que tenemos privilegio de root y podemos hacer lo que nos dé la gana.

Ahora simplemente tenemos que esperar que el usuario teclee algo así como:

$ sudo aptitude update #por ejemplo

[sudo] password for inedit:

Y ya hemos comprometido el sistema. Bonito, ¿verdad?

$ ls -l /root/owned

-rw------- 1 root root 0 Mar 26 20:48 owned

Seguro que si alguien hace algo así en tu máquina no te hace tanta gracia.

[Prevención]

¿Modos de prevenir esto? Pues pocos, la verdad. El comando alias es un funcionalidad del bash (man bash) que puede ser desactivada mediante el comando:

$ shopt -u expand_aliases

Pero también puede ser activado por el mismo atacante con el comando ("shopt | grep expand_aliases" para ver el estado actual):

$ shopt -s expand_aliases

Este método sólo aplicaría a bash. Si se usara una consola xterm o ksh se tendría que buscar el modo concreto de hacerlo en estas otras consolas, pero seguro que existen vías similares (si no iguales)

[Moraleja]

Que nadie toque tu portátil/PC. Nadie. Y muchos menos si es alguien que tiene conocimientos medios en sistemas Unix-like. Os pueden hacer un traje. Cuando el PC/portátil queda desatendido, debe ser bloqueado de algún modo (pidiendo contraseña, etc...). Y aún así uno no puede estar seguro que salga un zero-day[3] (que en realidad era un feature!!!) y te jodan el tinglado de mientras vas a echar un meo. Los sistemas Linux son muy versátiles, pero esta versatilidad puede jugar en tu contra algunas veces. Si alguien ha tocado tu sistema, aunque no sepa la contraseña de root te puede tangar sin problemas. Y si no la sabe pero la quiere existen otros muchos recursos que ya veremos mas adelante.

Un saludo.

[1] http://inedit00.blogspot.com.es/2009/10/reset-en-linux.html
[2] http://www.seginformatica.net/2012/03/ataque-de-david-hasselhoff-evolucion.html

[3] http://seclists.org/oss-sec/2012/q1/191

Erlang (III) Semana 1

noreply@blogger.com (inedit00) — Sat, 17 Mar 2012 12:15:00 +0000

Semana 1

Después de hacer una Semana Cero* de: aprender, aprender, aprender, aprender, aprender.... he empezado el proyectito.

La primera semana simplemente es para jugar y hacer pruebas. Quería empezar creando una primera versión de mi chat. En realidad he rehecho el código 4 veces des de cero, mejorando cada vez la versión anterior. El objetivo primero era conseguir dar de alta usuarios (login), y que pudiesen mandarse mensajes entre ellos. Todo a través de la línea de comandos (intérprete de Erlang). Después también he pensado que estaría bien hacer un poquito de benchmark para probar si la idea básica funciona, o todavía necesito aprender más cosas antes de empezar.

Básicamente estas "iteraciones" de ir rehaciendo código y mejorándolo según los errores y problemas aprendidos ha sido algo así:

Escrito código 100% custom que se encarga de la gestión de mensajes, sin hacer uso de OTP. Básicamente se disponen de dos módulos: gaab_server y gaab_user. El primero sirve para saber qué usuarios que están registrados en el chat, el segundo módulo tiene todas las funcionalidades de un usuario, y dispone de funciones tales como send_message, receive_message, talk_with, ....
Reescrito el código ahora haciendo uso de records para manter el estado e implementando una interfície muy parecida a gen_server, pero todavía hecho todo 100% custom.
Usar gen_server tanto para el gaab_server como para gaab_user, quitar toda la funcionalidad custom que ya me dá gen_server.
Creado un Makefile, organizado el proyecto en las carpetas correspondientes (src, ebin,...) y demás.

[Cómo funciona]

Explico un poquito más cómo funciona el tema... Tenemos un agente de gaab_server que se encarga de almacenar los usuarios logeados. Básicamente el flujo normal será loguearnos en gaab_server y éste creará un agente de tipo gaab_user, y nos devolverá su Pid. El servidor también tiene una función llamada pidof/1 que devuelve el Pid del usuario pasado como parámetro. Simplemente se encarga de saber qué usuarios están logueados en el sistema.

El agente gaab_user tiene funciones para hablar con otros usuarios, y siempre está a la espera de recibir mensajes dirigidos hacia el, que imprime por pantalla. Todo muy simple, por ser una primera versión.

[Benchmarcks]

Vamos a lanzar un par de tests para comprobar que, efectivamente, el servidor soporte algo de carga. Se van a medir básicamente dos cosas: coste de CPU y coste de memória. Los dos parámtros con los que jugamos son básicamente dos: número de usuarios conectados al mismo tiempo y número de mensajes por segundo enviados entre usuarios. La máquina con la que trabajamos es la siguiente:

Memória RAM: 6GiB DDR (1066).

CPU: Intel i5 - M540 2.53GHz (2 cores + 2 de Hyperthreading)

Empezemos.

Prueba 1. Aumentar número de usuarios

1.1 - Número de Usuarios: 10K. Mensajes por segundo: 500.

Carga de CPU ~50% de carga en un core (~13% de el procesador).

Memória total del proceso: 46.336 Kbytes. Memória por usuario: 2,98 Kb.

1.2 - Número de Usuarios: 20K. Mensajes por segundo: 500.

Carga de CPU ~50% de carga en un core (~13% de el procesador).

Memória total del proceso: 78.656 Kbytes. Memória por usuario: 3.11 Kb

1.3 - Número de Usuarios: 30K. Mensajes por segundo: 500.

Carga de CPU ~50% de carga en un core (~13% de el procesador).

Memória total del proceso: 87.692 Kbytes. Memória por usuario: 2.37Kb

Prueba 2. Aumentar el número de mensajes/segundo

2.1 - Número de Usuarios: 10K. Mensajes por segundo: 500. (prueba 1.1 anterior)

Carga de CPU ~50% de carga en un core (~13% del procesador).

Memória total del proceso: 46.336 Kbytes.

2.2 - Número de Usuarios: 10K. Mensajes por segundo: 750.

Carga de CPU ~75% de carga en un core (~20% del procesador).

Memória total del proceso: 37.244 Kbytes.

2.3 - Número de Usuarios: 10K. Mensajes por segundo: 1000.

Carga de CPU ~85% de carga en un core (~23% del procesador).

Memória total del proceso: 30.366 Kbytes.

**Nota: El proceso de Erlang por si solo ocupa 16.508 KBytes.

[Conclusiones]
Pues todo exactamente como esperébamos. Crear muchos usuarios no tiene coste computacional, solo un coste de memória. Ahora mismo los actores son muy chiquititos y pesan unos 3Kbytes. Aún así esta cifra es muy subjetiva ya que dentro de poco la aplicación empezará a crecer, y los usuarios tendrán que guardar un poco más de información, pero no mucha mas. Esto significa que, a priori, con 1GB de RAM podemos tener unos 300K usuarios activos, en este momento ( ya veremos cuando pongamos conexiones TCP por enmedio, jeje... ). Si quisiéramos llegar a 1 millón de usuarios al mismo tiempo, con 4GB para los procesos de usuario, de momento debería ser suficiente (pero lo dicho, ya veremos).

Si los usuarios se mandan muchos mensajes entre ellos aumenta el consumo de CPU. Normal. A más mensajes, más carga. Hombre, 1.000 mensajes por segundo son unos cuantos, no está nada mal, pero prácticamente ocupan un core de CPU, por lo que el consumo no es nada despreciable. Tampoco tengo muy claro en aplicaciones grandes cual es el ratio de número_de_usuarios/número_de_mensajes_por_segundo. Pero bueno, ya lo descubriremos.

Pues nada. Este es el resumen de mi Semana 1. La próxima entrega incluye el servidor web MochiWeb, interfazes web, HTML+CSS+JS, AJAX y la integración de lo que hemos venido haciendo hasta ahora con todo lo anterior.

Un saludo, Jan.

* En realidad Semana Cero es un modo de hablar. Aprendiendo las bases de Erlang me ha llevado entre 2-3 semanas de una o dos horitas al día (cuando todavía trabajaba).

Post anterior: Erlang (II) Aprendiendo lo básico

Post siguiente: Erlang (IV) Semana 2

MOC ha muerto. Exaile sube al ring.

noreply@blogger.com (inedit00) — Tue, 13 Mar 2012 10:58:00 +0000

Pues esto, el reproductor de consola moc ha muerto. Me parece que ha sido después de una actualización de algún paquete de audio o algo así, que hace que moc no funcione bien; consume un 100% de CPU, no cierra el cliente de ncurses.... vaya, que me había quedado sin música.

Y esto no puede ser.

He intentado instalar el rhythmbox pero me ha dicho que tenía que descargar 60 paquetes, descargar 50,7MB y resolver chorrocientas dependencias. Já! Estás que instalo yo algo así. He buscado un poquitín y me he encontrado con el reproductor Exaile: liviano, muy simple de usar, controles muy simples y se puede pausar/pasar canción/etc des de el try-icon. Está en los repositorios de debian, por lo que mola. Una pena que no sea una aplicación por consola, pero bueno... me acostumbraré.

Aunque no sea un programa 100% por consola, no quita que no se le puedan pasar parámetros al programa por consola. Esto nos dá libertad total para crear shortcuts. Por ejemplo, hacer que Control-Alt-P ejecuten "exaile --play-pause" y así poder poner play/pause con una simple combinación de teclas (y evitamos tocar el ratón).

Pues nada, que me ha gustado. Cuando hagan el fix en moc, me vulevo a pasar a la aplicación de consola, pero de mientras iré tirando de exaile.

Edit1: Anónimo1 me ha propuesto probar cmus, y la verdad es que me ha molado. Mas complejo, pero está chulo. Todavía no he descubierto si tiene la capacidad de reproducir emisoras de radio...
Edit2: Parece ser que el bug de Moc que me llevó a escribir este post ya está arreglado. Puedo usar Moc de nuevo.... pero seguiré usando Cmus una temporada, que en la variedad está el gusto (es algo que mi exnovia no entendió)

Erlang (II) Aprendiendo lo básico

noreply@blogger.com (inedit00) — Thu, 08 Mar 2012 09:34:00 +0000

Erlang. Erlang. Erlang. ¿Por dónde empezar a aprender?

Pues por muchos sitios. Hay un montón de documentación disponible, y un montón de tutoriales. Es suficiente con buscar un poquitín, para encontrarse con material de mucha calidad. Hoy recopilaré las fuentes que me han ido ayudando a aprender lo poco que sé de Erlang.

He decicido no hacer otro manual de Erlang mas, ya que toda la informaicón que se puede encontrar en Internet es mas que suficiente, y lo único que estaría haciendo sería repetir contenido.

[¿Qué es erlang?]
Lo explico con mis palabras (seguro que con inexactitudes e imprecisiones) y después pongo un par de enlaces ineresantes y un poco mas serios. Erlang es un lenguaje de programación funcional, de propósito general y altamente enfocado a la concurrencia. Se creó por la compañía Ericsson para ser usado en temas relacionados con la telefonía (programación de PBX, etc). Una de las características de la telefonía es que necesita acceptar mucha concurrenicia (número de llamadas al mismo tiempo), tiene que ser tolerante a fallos (si una llamada ocasiona un problema, las demás llamadas deben continuar), tiene que tener un downtime mínimo por lo que implementa un sistema de cámbio de código "en caliente" (ya que siempre hay llamadas establecidas, y una parada de sistema significa dejara sin servicio a los clientes), no existen datos comparitos, ( de este modo se eliminan muchos problemas de concurrencia y bloqueos ), los procesos, también llamados Agentes o Actores, son partes de código que se ejecutan de modo independiente, y que se comunica entre otros procesos mediante mensajes (no son procesos de Sistema, estos "procesos" son gestionados por la máquina virtual de Erlang ). Crear Actores (o procesos) de Erlang es *muy* barato computacionalmente, o sea 1µs. En C# o Java crear un proceso (de sistema) tarda unos 300µs. En erlang se pueden crear literalmente millones de procesos, mientras que en Java/C# no se puede crear mas que unos 2.000. Otra característica muy chula del lenguaje es que estos Procesos-Erlang (o también llamados Agentes o Actores) se pueden ejecutar en cualquier Core o CPU de tu ordenador. De hecho, se pueden ejecutar en otra máquina especificando un parámetro adicional. Esto nos dá la libertad de poder escalar horizontalmente de una manera increíble. Normalmente el mismo Erlang ya hará uso de toda la capacidad de procesamiento de un mismo ordenador (usando todos sus cores), de manera transparente para el usuario y sin tener que programar un línea de código adicional. Pero si se añade una máquina más, es tan simple como decirle a Erlang "'ei! Te he añadido mas recursos. ¡Úsalos!".... y punto :)

Bueno, vayamos con las definiciones mas serias.

Obviamente tenemos la web de wikipedia, pero la vamos a usar sólo para echarle un vistazo general a las definiciones de qué es Erlang y ver un poquito cómo se vé el código en este lenguaje. Erlang es un lenguaje funcional, lo que quiere decir que hace uso intensivo de recursividad y demás. Las variables solo pueden ser asignadas una vez (sisi, literalmente. Solo una vez. Divertido, ¿verdad?). Que estos conceptos no te asusten. Es simplemente cambiar el chip. En uno de los manuales que enlazaré mas adelante se explica todo, y queda todo muy claro.

Después lo mejor será que el mismo Joe Armstrong, uno de los creadores principales de Erlang, nos cuente sus bondades (las de Erlang, no las suyas). Hay otra charla exactamente igual en contenido pero para un publico mas senior (o mas enterprise, no lo tengo muy claro) y por lo tanto menos divertida. Esta está muy chula.

[Empezando a jugar]
Para ir metiéndonos en tarea, podemos echarle un vistazo al curso de la web oficial de Erlang, que dicen que está un poco desfasado, pero está muy bien explicado cómo usar las features claves del lenguaje. Todo muy escueto, pero bastante útil para entender los conceptos básicos y saber qué nos vamos a encontrar. Hay cinco módulos: History, Sequential Programming, Concurrent Programming, Error handling y Advanced Topics. Recomiendo que se lean con calma e intentando entender todo lo que se pueda. También hay un apartado de ejercicios para practicar lo aprendido. Muy útil.

Y aquí viene el punto fuerte. La guía definitiva. Learn you some Erlang[1]. La polla en bicicleta. Cuando acabe de leerme la guía entera me voy a poner en contacto con el tío y le mandaré 50€ para que se vaya a tomar unas cervecitas al bar, porque la verdad que se lo ha currado. Son 30 capítulos. Cada uno explica una parte de Erlang. Empieza primero con la história, cómo instalar el intérprete de erlang, tipos de datos, los módulos, la sintaxis de las funciones y los pattern matching, recursividad, funciones de alto nivel, errores y excepciones, concurrencia, multiprocesos, y un laaaaaaargo etc. Una pasada, oye.

Ya en la introducción el autor dice que es necesario unos conocimientos básicos de programación en lenguajes imperativos (Python, C/C++, Java, Ruby...) y que no hace falta tener conocimientos de lenguajes funcionales (Scala, Haskel, CLisp, Clojure....). Vamos, que empieza des de cero y es muy fácil de ir siguiendo. Todo está con ejemplos de código que podemos ir siguiendo nosotros mismos ( y debemos hacerlo ), y hasta te dá los códigos fuente de todos los programillas que se van creando durante el curso/libro.

Otra cosa muy buena que tiene el autor es que te cuenta lo que es Erlang, y no te lo intenta vender. Te cuenta sus cosas buenas, y sus cosas malas. Para lo que sirve, y para lo que no sirve. Normalmente las guías siempre te dicen: "aprende a programar en el mejor leguaje de programación del mundo" ( yo almenos tengo dos libros en casa que en la portada aparece este lema, siendo lenguajes de programación distintos ). El autor siempre intenta explicarte las bondades del lenguaje, pero te dice cuáles son sus limitaciones. Muy chulo, la verdad.

[Otra información interesante]
Hay una pregunta en Stack Overflow sobre por qué los procesos de Erlang son mas eficientes que los Threads del SO que es muy interesante. También tenemos otra entrada (que sinceramente todavía no he probado[2]) sobre plugins de Erlang para el Vim (resaltado de sintaxis, introspección en los módulos, completion... lo típico, vamos).

Hay otra página, de un tal Richard Jones co-fundador de Last.fm, en donde explica cómo construir una aplicación de un millón de usuarios en Erlang. Son tres entradas muy muy interesantes. Yo me lo leí cuando empezaba con Erlang y me fascinó, aunque sinceramente me enteré de poco. Ahora cada vez lo entiendo mas, y lo utilizo como referéncia para ir cogiendo ideas y ver cómo ha solucionado algunos problemas.

Otro artículo interesante, aunque mucho mas específico, es un ejemplo práctico de cómo usar el framework web MochiWeb. Si quieres crear un servidor web, MochiWeb te puede solucionar la papeleta. Es muy ligero, y te dá todos los recursos necesarios para manejar los request/responses. En éste artículo te explican cómo crear un pequeño dispacher de los requests que llegan, y un modo de devolver las respuestas de manera simple.

Y nada, de momento esto es todo. Te animo a que le des una oportunidad. No es difícil: Es diferente. Pero muy divertido, y con el que se pueden hacer cosas realmente chulas. Yo estoy difrutando un montón. Para cualquier cosa, dudas, preguntas o aclaraciones, no dudes en dejar tu comentario.

Un saludo, Jan.

Edit: Añado otro vídeo muy chulo de Joe Armstrong.

Edit[2]: Vale, ya he probado el pluguin para el Vim y aquí están mis impresiones.

Siguiente post: Erlang (III) Semana 1

Post anterior: Erlang y WebChats (I)

[1] Hay un grupo en argentina que está traduciendo este magnífico trabajo, para al que no le vaya demasiado bien esto del inglés.

Generar una clave pública a partir de una clave privada (SSH)

noreply@blogger.com (inedit00) — Wed, 07 Mar 2012 23:04:00 +0000

Típica tontería. Tenemos la llave privada SSH en nuestro PC pero por lo que sea hemos perdido la llave pública de esta clave.
Solución? Pues generar la clave pública otra vez, que se puede recalcular a partir de la clave privada.
El comando es muy simple:

$ ssh-keygen -f ~/.ssh/key -y > ~/.ssh/key.pub

Nos pedriá la contraseña de la clave privada ( ¿por que que tenemos cifrada la clave privada, verdad? )
Y estamos listos.

Si quisiéramos sacar el fingerprint de la clave[1], sería tan fácil como ejecutar

$ ssh-keygen -l -f ~/.ssh/key.pub
2048 71:1a:34:94:1b:61:60:09:0c:00:54:e8:ad:17:97:ec key.pub (RSA)

[1] http://inedit00.blogspot.com/2009/11/comprobar-fingerprint-en-ssh.html

Erlang y WebChats (I)

noreply@blogger.com (inedit00) — Tue, 06 Mar 2012 22:03:00 +0000

[INTRODUCCIÓN]
¿Sabes esta sensación que te recorre el cuerpo cuando te miras a los ojos con otra persona y estás seguro de que es tu alma gemela, de que has encontrado el amor de tu vida, y que no quieres mas que pasar el resto de tu vida con ella?

Pues yo no.

Pero supongo que algo parecido me ha pasado con Erlang. Bromas aparte. Es un lenguaje de programación que me ha encantado y al que le pienso dedicar muchas horas en los próximos meses. No se si ha sido amor a primera vista, o que simplemente me pilla en un momento en el que me molan las cosas chungas, extrañas y muy diferentes.

[PROBLEMA]
Os explico de donde viene todo esto. Resulta a través de highscalability.com acabé en una página del blog de What'sApp[1] en donde pone algo tal que así:

[...] Over the past few months we have been making a lot of improvements to our servers to increase the performance, uptime and scalability. Today we have tuned some knobs, shifted some traffic around and achieved 1 million established tcp sessions on a single machine [...] For those curious how we did it, the technology on the backend is simple: FreeBSD + Erlang [...]

Un millón de conexiones TCP. En una sola máquina ¡Wow!

Justo cuando lo leí me entró muchísima de curiosidad por el tema. Las únicas pistas que daban eran FreeBSD (SO que Unix-like, que ya he probado en casa alguna vez) y.... Erlang. ¿Qué es Erlang? Pues de la wikipedia[2] sacamos (y marco las partes que me llamaron la atención):

Erlang es un lenguaje de programación concurrente. El subconjunto de programación secuencial de Erlang es un lenguaje funcional, con evaluación estricta, asignación única, y tipado dinámico. Fue diseñado en la compañía Ericsson para realizar aplicaciones distribuidas, tolerantes a fallos, soft-real-time y de funcionamiento ininterrumpido. Proporciona el cambio en caliente de código de forma que éste se puede cambiar sin parar el sistema. Originalmente, Erlang era un lenguaje propietario de Ericsson, pero fue cedido como software de código abierto en 1998.

Bueno, suena genial. Pues solo con esta información, o sea, sabiendo que WhatsApp había conseguido tener 1M de conexiones TCP en una misma máquina, y viendo mas o menos las caraterísticas principales de Erlang me dije: Si ellos han podido, yo también puedo.

[NUDO]
Umm.... si lo piensas así en frio puedes decir: cágate, lorito. Y entonces me comentarías:
- A ver, Jan. No sabes cuantos empleados tiene What'sApp. Ni la pasta que manejan. Ni los cracks que puedan tener contratados. Ni muchas otras cosas que pueden influir en el éxito de un proyecto así.... ¿No crees que te estás pasando un poquitín?
Y yo te voy a contestar:
- Pues no. Ellos han conseguido hacer un millón de conexiones TCP's a una sola máquina. Y si ellos pueden, yo también. Y punto.

[PRESENTACIÓN DEL PROBLEMA/EJECRCICIO]
Bien. Entonces necesito pensar en un proyectito que sea chulo, y con el que aprender Erlang. A la vez tiene que ser algo lo suficientemente simple como para que el problema no me sobrepase al inicio, pero que lo pueda ir complicando bastante a medida que vaya aprendiendo. Y, ¿en qué he pensado? Pues en un Web Chat!

¿Que qué es un web chat? Pues hombre, algo como "el chat de facebook" ( ¬¬' así seguro que todo el mundo lo entiendea).

Pues nada, la gracia es hacer un WebChat que soporte mucha carga. Se tendrá que desarollar tanto la parte cliente (HTML+CSS+JS), como el servidor web (en Erlang), así como proceso de chat en si mismo (en Erlang también) y el posible acceso a datos.

¿El objetivo cuál es? Pues conseguir un servidor de chat que soporte mucha carga. De momento me conformaré con tener 10.000 usuarios funcionando al mismo tiempo (problema C10K[3]). Después intentaremos mejorar lo posible para llegar a 100K usuarios, y si no veo muy negro el tema, el objetivo final será conseguir 1M de usuarios (conexiones TCP al mismo tiempo) contra una misma máquina y obviamente que puedan hablar de manera flúida entre ellos y demás.

[RETO]
Cagonlaputa. Resulta que los de WhatsApp me están retando. Seguro que lo han hecho aposta. Han publicado un nuevo post en el blog[4] titulado "1 million is so 2011". El artículo dice:

Happy 2012 everyone!
A few months ago we published a blog post that talked about our servers doing 1 million tcp connections on a single box[1].

Today we have an update for those keeping score at home: we are now able to easily push our systems to over 2 million tcp connections!

Vale. Ya está. Si ellos han conseguido 2M de conexiones TCP en una misma máquina, des de luego que yo puedo conseguir 1M. En el mismo artículo también comparten información sobre lo que ellos entienden por una misma máquina y..... bueno.... ejem

hw.machine: amd64hw.model: Intel(R) Xeon(R) CPU X5675 @ 3.07GHzhw.ncpu: 24hw.physmem: 103062118400

¡¡¡Alaaaaaa!!! ¡Vaya maquinón! 24 cores a 3.07GHz cada uno, y 103GB de memória RAM. ¡Trabajar así da gusto! Ya veremos si yo puedo acercarme o no... esto no me desanima, sino que hace que el reto sea mejor =)

[DESENLACE] (Hay desenlace porque a mi me contaron en el cole que tenía que haber siempre una presentación-nudo-desenlace)

Pues nada, que próximamente vendrán toda una serie de entradas sobre el tema. Aprender Erlang, ver sus cosas buenas y sus cosas malas, enlazar un motón de documentación útil, ver algunos ejercicios propuestos, ver qué es OTP, ver el enfoque que le damos al tema del WebChat, los benchmarks que van saliendo, las mejoras que se hacen y demás. Lo más seguro que el proyecto acabe siendo publicado en un repositorio de github/bitbucket con una licencia OpenSource ( mi primer proyecto OpenSource!! =) )

¿Que te mola el rollo? pues sigue el blog y las entradas que voy publicando. Te van a gustar. ¿Que no te mola?, no lo leas; me la suda[5].

Muy señores míos, un saludo!!

(haré como los de What's App, que queda super molón)
P.S. - Ahora mismo no busco trabajo pero las ofertas siempre son bienvenidas. Si estás interesado en contratarme, envia información de algún proyecto chulo a inedit00 [2] gmail [.] com. (Yo también busco becarias para hacer summer-interships ;)

[1]: http://blog.whatsapp.com/index.php/2011/09/one-million/
[2]: http://es.wikipedia.org/wiki/Erlang
[3]: http://www.kegel.com/c10k.html
[4]: http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/
[5]: http://inedit00.blogspot.com/2009/09/mi-primera-vez.html

Post siguiente: Erlang (II) Aprendiendo lo básico

Problemas con el ratón en ioquake3

noreply@blogger.com (inedit00) — Sun, 04 Mar 2012 10:46:00 +0000

Tengo un problema en mi Lenovo Think Pad X201 cuando intento jugar al ioquake3. Resulta que cuando abres el juego, el cursor aparece en la mitad de la pantalla.
Cuando, cuando mueves el cursor, todo va OK. Pero a los 5 segundos o eso, el cursor se vuelve a situar en el centro de la pantalla otra vez. Y así cada 5 segundos. Obviamente es imposible jugar normalmente. No se a que es debido, pero si que se la solución: antes de ejecutar el binario de ioquake3 teneis que ejecutar:

$ export SDL_VIDEO_X11_DGAMOUSE=0

Un saludo!

[fun] Se finí

noreply@blogger.com (inedit00) — Thu, 01 Mar 2012 09:16:00 +0000

Muy señores míos, hoy es fiesta en algunos lugares de España. Para mi es el primer día libre que disfrutaré de unas "vacaciones" que durarán los próximos 6 meses. Ayer, después de 3 días muy intensos que han parecieron un parto de un rinoceronte (sisi, con cuerno y todo), acabé el trabajo dejando todas las cosas posibles listas. Los últimos días, haciendo horas extras (por amor al arte) y jornadas de 11 horas, todavía me llamaba el jefe a última hora para decirme "si me podía mirar esto y lo otro" =)

En fin.

Ya está. He sobado 12 horas y ya estoy listo para ~~tocarme los cojones durante 6 meses~~ disfrutar de estas vacaciones merecidas. Estoy viendo infinitas horas de programación, proyectitos frikis, fiestas con los amigos, salir de marcha, cenas, paseos por la ciudad Condal, algún que otro viaje por estos mundos de dios y en definitiva disfrutar de la vida y ser feliz. Lo normal, vamos.

Como nota divertida os quiero dejar con una imagen muy curiosa. Algo que cuando te lo encuentras no sabes si descojonarte o volarte la cabeza. Obviamente me descojoné, ya que las cosas nos las tenemos que tomar siempre por el lado positivo. El programa protagonista es Microsoft Bussines Solutions Navision versión 3.7. Creo que el nombre en clave del proyecto en Microsoft era Super-Mega-Truño-Brutal-Anal-Coprofagicalmente-Fatal. Bueno, pues de mientras estás metido en el código, buscando un error tope chungo que no llegas a resolver, vas y te encuentras una función con este nombre:

jajajajajajajajajajajajajajajaja! No te echaré de menos, Navision. Hazme caso que no ;)

Puertos abiertos en el router: mala idea.

noreply@blogger.com (inedit00) — Sat, 18 Feb 2012 14:43:00 +0000

[Introducción chorra]
Juer, vaya día. Estoy tan tranquilo hoy haciendo unas pruebicas con sockets TCP en mi red local, trabajando con el wireshark capturando los paquetes resultantes para ver si, haciendo un par de putadas a una conexión TCP, puedo llegar a romper algo. Nada, intentando explotar una idea que tuve hace dos días y viendo si dá para un post o no. Hasta aquí todo normal.

Resulta que en una de estas he encendido el Transmission ( http://www.transmissionbt.com ), para el que no lo sepa es un cliente de BitTorrent. Si no sabes que es BitTorrent dale ~~aquí~~ aqui . Para la gente con poca memória: P2P. Intercambio de ficheros. ¿Te suena ya?

Bien. Voy a Edit>Preferences>Network>Test Port. "Port closed". Genial. Tendré que crear una regla en el router.

Voy a la configuración del router, veo que ya hay una regla creada para exactamente esto, pero en una IP que no es la mia (es la de otro ordenador de casa, que ahora mismo está apagado). Pos fale. No problemo. Le digo que todo lo que venga por el puerto 61415 me lo mande a mi IP local: 192.168.1.35. Pongo una regla en la configuración del cortafuegos de mi portátil para que accepte conexiones entantes por el puerto 61415. La regla es así:

iptables -A INPUT -p TCP -m state --state NEW --dport 61415 -j ACCEPT

Nótese que el puerto por "defecto" es el 51413, pero como ya está configurado para que lo use otra máquina en mi red, yo estoy usando el 61415 (puerto que he elegido al tuntún). Pruebo otra vez: Edit>Preferences>Network. Cambio el puerto del 51413 al 61415. Le doy a Test Port: "Port open". Genial, ahora esto irá chuscado. Voy a por algo para picar (esto de abrir puertos hace que a uno le entre hambre). Cuando vuelvo la descarga ya está completada. Genial. Apago el Transmission, me pongo algo de música, pongo enmarcha el Wireshark para seguir haciendo pruebas y.... WTF!!!

[Paquetes, Paquetes Everywhere]
Joder, macho. Aún habiendo cerrado el Transmission hay muchísimo tráfico que viene de Internet hacia mi máquina. Pero a saco. Unos 3-4 requests por segundo.

Todas las peticiones son paquetes TCP tipo SYN. O sea, que des de Internet quieren establecer una conexión con mi máquina. Miro el puerto de destino de estas conexiones y es el 61415. Mi ordenador responde a cada una de ellas con un paquete TCP tipo RST, que les dice "ummm.... pos va a ser que no", ya que no tengo ningún servicio escuchando en este puerto.

Vale, tate. Esto es lógico. Hace un momento, cuando tenía el Transmission encendido la gente se conectaba a mi máquina para pillar archivos. He cerrado la aplicación de Transmission, pero esto es algo que la gente de Internet no sabe, por lo que intentan conectarse igualmente a mi PC para pillar ficheros (por esto mandan un TCP-SYN). Mi portátil como no tiene ningún programa escuchando en el 61414, contesta las peticiones con un TCP-RST diciendo... lo siento, no hay nada a lo que te puedas conectar (de esto se encarga el kernel). O sea, esto es normal, y no hay nada malo en que intenten conectarse a mi máquina sin conseguirlo. Esto te puede llegar a quitar bastante ancho de banda, pero bueno, supongo después de un rato el número de requests va disminuyendo hasta que finalmente pare.

Claro, yo quiero seguir haciendo pruebas con el wireshark, pero con tanto "ruido" no hay quién trabaje. Total, que me voy al router y borro la regla de redirección de puerto 61415 hacia mi máquina. A ver si ahora puedo trabajar tranquilo.

Recordemos que ya tenía otra regla en el router. La regla dice que redirija todo el tráfico al puerto 51413 a la IP 192.168.1.33 (otro host de mi red, ahora mismo apagado). No la he modificado porque quiero que la 192.168.1.33 siga pudiendo usar el Transmission sin cambiar la configuración.

[ARP-FLOOD]
Pongo enmarcha el wireshark otra vez. Fuck. Ahora hay alguien que me está inundando la puta red de paquetes ARP. Que majos todos.

Veamos, el router (192.168.1.1) pregunta quién tiene la IP 192.168.1.33, mediante paquetes ARP lanzados casi cada segundo. Pues vaya: NADIE TIENE ESA IP; es un host en mi red que ahora mismo está apagado, normal que nadie conteste. Pero ¿por qué el router intenta descubrir quién es 192.168.1.33? Quiero decir.. esta máquina ha estado parada durante días. ¿Qué tráfico tiene que ir a una máquina apagada hace días? ¿Quién quiere ponerse en contacto con una máquia apagada? WTF!

Pues alguien que esté usando BitTorrent y quiera un fichero que cree que yo tengo. Parece que algún hijo de delfín daltónico y chimpanzé fitofílico ha decidido hacer conexiones contra mi IP pública, al puerto 51413. Pero, ¿Por quéeee y para qué? Vale que este sea el puerto por defecto de Transmission, pero yo hoy no lo he usado para nada. Yo siempre he estado usando el 61415. ¿Con que derecho intenta acceder al puerto 51413? o sea.... ¿qué espera encontrar? Esto parece una mala implementación de un cliente de BitTorrent, o alguna comprovación que harán algunos servidores de torrents para comprobar si, además del puerto 61415, también tenemos abierto el 51413, digo yo. No lo sé, pero la verdad que no me mola mucho el tema.

Lo que está pasando, es que como tengo una regla en el router que dice "redirígeme todo el tráfico que venga al puerto 51413 a la IP 192.168.1.33", el router la palica siempre. Si o si. Y claro, para poder mandarle tráfico entrante al host 192.168.1.33 necesita saber primero quién es éste host (obtener la dirección MAC, para los menos entendidos en tema de ARP). Y es por esto que está mandando paquetes ARP a SACO en toda mi red. De echo, manda un paquete ARP por cada petición que le llega al puerto 51413. Una de las características de ARP es que son paquetes que se mandan a broadcast. O sea que lo reciben TODOS los hosts de mi red. Fuck. Obviamente como ninguno de ellos es 192.168.1.33, todo el mundo descarta el paquete y andando. Pero bueno, es un desperdicio de ancho de banda y no me mola el rollo.

[Cómo ver el tráfico que recibiría 192.168.1.33 en caso de estar encendido]
Pues como me da pereza infinita ir a encender el host 192.168.1.33, poner el wireshark y demás, vamos a ver el tráfico que recibiría este host ahora mismo des de mi portatil:

$ sudo ifconfig eth0:2 192.168.1.33

Ala. Hecho. Ahora mi portátil tiene la IP 192.168.1.35 y la 192.168.1.33 en una subinterfície (conocíais lo de las subinterfícies, verdad? ;) ). Mi host se indentifica como 192.168.1.33 y responde las peticiones ARP. Miro el wireshark y ala! Estamos como al principio: Hosts de Internet intentan establecer una conexión con mi equipo, y mi equipo contestando que "no, no tengo ningún servicio escuchando en el puerto donde me estás haciendo la petición. RST! RST! RST!".

[¿Cómo solucionar el problema?]
Bueno, no parece muy difícil llegar a la conclusión de que los puertos, si están cerrados, mejor. En caso de usar protocolos P2P, en necesario abrir los puertos para que el tema vaya flúido. Yo a partir de ahora voy a abrir/cerrar los puertos de mi router cada vez que me quiera descargar algo. No me mola que si a alguien le apetece enviarme un paquete al puerto por defecto de BitTorrent, esto se traduzca en chorrocientos paquetes ARP en mi red. Vale, tampoco hacen daño, pero no los quiero ahí.

[Notas finales]
En este post tampoco cuento nada extraño ni sofisticado. Todo funciona como es debido, y si se piensa bien, no hay problema de que las cosas funcionen así. Aún así para mi ha supuesto la primera prueba que tengo que respalde la afirmación que todo el mundo hace diciendo: "los puertos del router mejor cerrados!". Y tienen razón. Ahora veo que me estoy provocando ARP-Flooding en mi propia red, en el caso de que el host de destino esté apagado. O que en caso de que esté encendido, que el host tenga que responder a peticiones ( ni que sea para decir RST ) que provinenen de Internet. Mucho mejor que se encargue de hacer todo esto el router, y deje mis hosts de la LAN en paz.

También he vuelto a ver claro esto de que Internet es la selva, y que muchas veces el router nos hace de separación entre nuestra tranquila/estable/fiable red local, y la locura de Internet.

Un saludo, Jan.

TCP Sockets: TIME_WAIT y los puertos efímeros son poco amigos

noreply@blogger.com (inedit00) — Fri, 17 Feb 2012 18:05:00 +0000

Hoy vamos a explicar un poco qué es TIME_WAIT y cómo puede darte por culo un rato largo.

[INTRODUCCIÓN]
Todos sabemos que las conexiones TCP ( capa 4 en modelo OSI, también llamada capa de transmisió de datos ) tienen estados. Umm... bueno, igual no todos lo sabemos. Refresquemos un poco qué son esto de los estados TCP antes de empezar.

TCP establece la conexión a tres vías[1]. Cuando se intenta establecer la conexión del host A al host B, el host A manda un paquete tipo SYN al host B. La conexión pasa a estar en un estado SYN_SENT. Cuando el host B le contesta con un paquete ACK-SYN, la conexión para a un estado llamado SYN_RECV. Cuando la conexión por fin se establece pasa a estado ESTABLISHED. También hay el estado LISTEN, que es el estado que tienen servicios tales como apache, memcached o sshd, esperando nuevas conexiones. Total, con todo esto nos tenemos que quedar con la copla de que una conexión TCP pasa por diferentes estados desde que se establece hasta que se cierra.

La lista completa de estados se puede ver fácilmente haciendo un man netstat, y buscando el apartado State.

Bien, entonces tenemos que los dos estados mas comunes son: ESTABLISHED conexiones establecidas y LISTEN, en el caso de que estemos en un servidor con varios servicios activos. Para ver una lista de las conexiones abiertas en nuestra máquina podemos hacer un:

$ sudo netstat -pan --tcp | less

[SUPOSICIÓN]
Si ejecuto un script muy simple que haga peticiones HTTP contra mi servidor web local SUPONGO que no habrá ningún problema (jeje, los cojones). Tengo un servidor Apache escuchando en el puero 80 en localhost. Problemos a ejecutar el siguiente comando en 5 consolas diferentes.

$ while true; do curl localhost; done

El comando "curl" abre una conexión TCP, hace una petición HTTP, se le devuelve un resultado (que no nos importa lo mas mínimo, ahora mismo) y CIERRA LA CONEXIÓN TCP. O esto es lo que nosotros esperamos, vamos. Entiendo que tener 5 instancias del script haría que normalmente tuviese 5 conexiones en estado ESTABLISHED, pero esto, nunca debería ocasionar un problema a nivel de sistema.

Hagamos la prueba. Ejecutamos cinco veces el script en consolas separadas, y en otra terminal ejecutamos:

$ sudo watch -n 0.5 'netstat -pan --tcp | grep ESTABLISHED | wc -l'

Pues efectivamente, nunca pasamos de 5 conexiones al mismo tiempo en estado ESTABLISHED pero... Umm.... pero al cabo de un minuto de estar ejecutando los scripts, el comando "curl" empieza a dar un error:

curl: (7) Failed to connect to 127.0.0.1: Cannot assign requested address

[PROBLEMA]
WTF. A ver, tenemos tan solo 5 conexiones abiertas. El error del curl parece decirnos que no puede obtener un puerto de origen para establecer la conexión. Veamos porqué:
Ejecutemos los scripts anteriores y pongamos un filtro diferente en el netstat:

$ sudo netstat -pan --tcp | grep TIME_WAIT | wc -l
5329
$ sudo netstat -pan --tcp | grep TIME_WAIT | wc -l
13440
$ sudo netstat -pan --tcp | grep TIME_WAIT | wc -l
19348
$ sudo netstat -pan --tcp | grep TIME_WAIT | wc -l
21526
$ sudo netstat -pan --tcp | grep TIME_WAIT | wc -l
28214

COJONES! Por algún motivo estan quedando chorrocientos sockets abiertos en estado TIME_WAIT!

[QUÉ ES TIME WAIT]
Ahora que nos hemos puesto un poco en matéria vamos a ver para que se usa el estado TIME_WAIT, y como puede llegar a ser un problema. De la definición del man de nestat sacamos que:

TIME_WAIT: The socket is waiting after close to handle packets still in the network.

Umm... según esto parece que la conexión no se cierra hasta que pase un tiempo para poder capturar los paquetes que se habían "perdido" por la red debido a posibles problemas de enrutamiento. Jummm... explicación algo escueta. Sobre todo porque no dice cuanto vamos a tener que esperar. Vamos a investigar un poquito más sobre el tema...

El RFC 1122 en el apartado "Transport layer, TCP" [2] dice algo así como:
When a connection is closed actively, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).

Vaaaale. Ahora ya tenemos un poco mas de información. Resulta que tenemos que esperarnos 2xMSL antes de que una conexión pase de TIME_WAIT a CLOSED ( y se libere la conexión ). Genial. Y ahora... ¿Dónde coño puedo consultar el tamaño del Maximum Segment Lifetime? Pues ejecutando este comando:

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
30

Que en mi máquina Debian me da un resultado de 30 segundos. En máquinas con Ubuntu el valor acostumbra a ser 60, en máquinas Solaris acostumbra a ser 120. Entonces parece ser que, en mi máquina, tardaré 2*MSL, o sea 2*30=60 segundos en liberar una conexión. El problema que hemos experimentado antes es que hay muchos sockets (conexiones) abiertas en estado TIME_WAIT. Cuando llegamos al límite de conexiones efímeras del sistema, el kernel nos dá un error diciendo "umm... me sabe mal, pero no me quedan puertos efímeros". Esto se traduce en el error que nos saca el "curl". O sea, no es problema del comando "curl" que vaya dejando conexiones abiertas, ya que si no tendríamos muchas conexiones en estado ESTABLISHED, y no es el caso. Tampoco es problema del kernel, ya que éste implementa el RFC 1122 como dios manda.

[PUERTOS EFÍMEROS]
"Ei. Ei, espera. Cuando has empezado a hablar de puertos efímeros y toda esta mierda me he perdido. A ver si te explicas un poquito más, macho."
Veamos. Cuando establecemos una conexión TCP con nuestro navegador a un servidor Web, necesitamos un puerto de origen [3]. Estos puertos, se conocen como puertos efímeros. El protocolo TCP necesita definir un puerto origen y un puerto destino. En nuestro ejemplo, el puerto destino será el 80 (servidor web), y el puerto origen será un puerto efímero. El Kernel nos asigna un puerto efímero automáticamente cuando establecemos una conexión nueva. Para ver el rango de puertos efímeros que tenemos definido podemos ejecutar:

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000

Si hacemos 61000-32768 nos dá 28232. Si os fijais, es un número muy parecido al número de sockets en estado TIME_WAIT que teníamos cuando ha empezado a petar todo. Esto es debido a que un socket en estado TIME_WAIT todavía es un socket activo. Es lo mismo como si estuviese en estado ESTABLISHED, por lo que está ocupando un puerto efímero. Si acumulamos muchos sockets en estado TIME_WAIT, vamos agotando los puertos efímeros. Cuando llegamos al límite y tenemos reservados *todos* los puertos efímeros, al kernel no le queda otra que devolver error cada vez que se quiere crear un socket nuevo. Bonito, verdad?

[POSIBLES SOLUCIONES]
Bueno, una de ellas pasa por aumentar el número de puertos efímeros del sistema. Esto se puede conseguir simplemente ejecutando:
$ sudo su - root
$ echo "1025 61000" > /proc/sys/net/ipv4/ip_local_port_range

Hecho esto, ahora disponemos de 60K puertos efímeros y no solo 30K. En realidad esto no es una solución de nada. Simplemente tendremos que esperar 2 minutos y no 1 para que los procesos "curl" agoten el número de sockets. Estamos haciendo que el sistema aguante un poquito mas, pero ya está.

Otra solución parece que puede venir modificando el parámetro 2*MSL. Si disminuimos este valor del MSL, los sockets en estado TIME_WAIT deberían estar en este estado durante menos tiempo. El parámetro es ajustable mediante el comando comentado anteriormente:
$ sudo su -c 'echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout'

Si probais de aplicar este cambio vereis que en realidad las conexiones en estado TIME_WAIT no se cierran a los 10 segundos como sería lo esperado (2*MSL; 2*5=10), sino que se siguien cerrando a los 60 segundos. Por qué ocurre esto? Simple. El valor "60 segundos" está hardcoded en el kernel de linux. Así de bonito. Si miramos el fichero /include/net/tcp.h línea 105 del kernel de línux veremos algo tal que así:

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, about 60 seconds */

A partir de línea 202 del fichero /net/ipv4/tcp_minisocks.c vereis que hace uso intensivo de la variable TCP_TIMEWAIT_LEN, justo en la sección donde define el estado TCP_TIME_WAIT al socket TCP. Por lo que modificar a través de las sysctls el parámetro "tcp_fin_timeout" no va a servir de un carajo. Ni 2*MSL ni pollas. Harcoded en el código. (Esto vulnera el RFC 1122 y la regla 2MSL? Si alguien lo sabe que por favor comente! Gracias )

La última solución, que dista mucho de ser algo perfecto pasa por activar el tcp_tw_recycle y tcp_tw_reuse. Ambas directivas son bastante peligrosas, y vulneran explícitamente el RFC 1122. No deberían usarse en entornos de producción o sin saber muy bien qué se está haciendo. La documentación que he encontrado al respecto es [4] y [5].

TCP_TW_RECYCLE: It enables fast recycling of TIME_WAIT sockets. The default value is 0 (disabled). The sysctl documentation incorrectly states the default as enabled. It can be changed to 1 (enabled) in many cases. Known to cause some issues with hoststated (load balancing and fail over) if enabled, should be used with caution.
$ echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

TCP_TW_REUSE: This allows reusing sockets in TIME_WAIT state for new connections when it is safe from protocol viewpoint. Default value is 0 (disabled). It is generally a safer alternative to tcp_tw_recycle
Note: The tcp_tw_reuse setting is particularly useful in environments where numerous short connections are open and left in TIME_WAIT state, such as web servers. Reusing the sockets can be very effective in reducing server load.
$ echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

O sea, usadlos, pero con mucho cuidado.

La solución definitiva viene en forma de pregunta: ¿Qué coño haceis creando 30K conexiones TCP en menos de un minuto, criaturas del Señor?
Si habeis llegado aquí porque os habeis encontrado con el problema del TIME_WAIT en un servidor de producción cuando recibía bastante tráfico os tengo que decir algo que no os va gustar: algo estáis haciendo mal. En este caso no es suficiente con cerrar las conexiones a la BBDD, caches, o lo que sea cada, vez que se hace una consulta. La solución pasa por hacer pooling de conexiones y demás. REAPROVECHAR conexiones. Pero bueno, esto es otra guerra que se sale del alcance de este post. Aún así para dudas, ruegos y preguntas teneis los comentarios. Intentaré ayudar hasta donde pueda/sepa.

[ÚLTIMAS NOTAS]
Nótese que este problema es provocado por la conjunción de crear muchas conexiones por parte de un CLIENTE (importante este punto) durante un periodo muy corto de tiempo. Esto hace que se acumulen muchos sockets abiertos (bueno, o no-cerrados, para ser mas exactos) en estado TIME_WAIT. Cuando se llega al punto que la suma de todos los sockets en dicho estado es igual al número de puertos efímeros de la máquina, el kernel no es capaz de crear sockets nuevos hasta que no se liberan recursos, devolviendo un error a cualquier proceso que intente crear una conexión nueva (nótese que las conexiones ya establecidas seguirán funcionando normalmente).

Espero que les haya gustado el post. La zona de comentarios está disponible para hacer preguntas, o proponer soluciones alternativas al problema.

Un saludo, Jan.

[1] http://danred.wordpress.com/2009/09/28/establecimiento-de-conexion-tcp-de-3-vias/
[2] http://www.rfc-editor.org/rfc/rfc1122.txt página 87
[3] Recordemos que un socket está formado por un IP Origen - Puerto Origen - IP Destino - Puerto Destino.
[4] http://www.speedguide.net/articles/linux-tweaking-121
[5] http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

Wikipedia, querida. ¿Por qué no te preocupas por mi privacidad?

noreply@blogger.com (inedit00) — Sun, 12 Feb 2012 18:25:00 +0000

Lo veo y no me lo creo. Por Diox![1]...

Página de login de la www.wikipedia.org. Se accede des del link que aparece en la parte superior derecha que reza algo así como Log in / create account. Si nos fijamos en el tooltip de dicho botón pone: You are encouraged to log in; however, it is not mandatory. [alt-shift-o]

Oh. Resulta que incluso tenemos un shortcut para ir a la página de login: alt-shit-o. Curioso.

Pongo el nombre de usuario, pongo la contraseña y.... oh! Wait. Me fijo antes de darle al botón Log in que no estoy en una página segura. O sea, que no estoy con HTTPS. ¿Será posible? Miro los opciones de la página dándole al logo de la wikipedia, justo a la izquierda de la URL en firefox y me dice: "Your connection to this website is not encrypted". Mecagonlaputa.

Le doy a "More information" y me encuentro con esto:

Jumm.... parece que está claro. La página no está cifrada. Bueno, como todavía tengo la esperanza de que la propiedad "action" del form vaya a una URL segura (esto es posible? tendré que probarlo[2]). Hago una prueba simple:

Pongo enmarcha el "wireshark" capturando todo el tráfico. Le doy a "login" en la página de la Wikipedia y.... e voilá. Esto es lo que ha capturado el wireshark:

POST /w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page&campaign=ACP1 HTTP/1.1
Host: en.wikipedia.org
[...] # Borradas las demás cabezeras por no tener releváncia en este caso

wpName=jcarreras&wpPassword=ilovemiami&wpLoginAttempt=Log+in&wpLoginToken=c7b2dc6fc071c5fe3b6f96efb8ef6122

Que bonito! Si señor! Un POST de toda la vida que contiene dos variables llamadas wpName y wpPassword. Todo viajando en claro a través de la red. Con dos cojones.

Fijándome un poquito mas veo que justo debajo del login hay un apartado que pone: "Secure you account". El primer punto pone: "Consider logging in on the secure server." y tiene un enlace que te lleva a la misma página pero usando HTTPS. Mi pregunta es: ¡¿por que carajo éste no es el modo de hacer login por defecto?! Un login que mande una contraseña en claro SIEMPRE debe ir a través de un canal cifrado/seguro. Siempre.

Después continua tocando otros puntos sobre seguridad como:

If your password only contains letters or only numbers [...] consider changing it. Para qué? Si el password viaja en cleartext?! No tiene importancia la longitud de la misma si la contraseña viaja en texto plano.
To avoid becoming a victim of phishing, always verify that you are viewing Wikipedia's login page [...] Ummm... exactamente PARA ESTO sierve HTTPS y los certificados SSL. Aparte de cifrar todo el canal de información, verifican que el servidor és quién dice ser.
Do not give out your password to anyone. Jejeje, les falta decir: "nosotros lo haremos por tí, majo".

Pues vaya, esto simplemente haciendo un MITM con arpspoof+tcpdump o con Ettercap directamente y, ale, regalando tu contraseña a toda la gente que se encuentra en tu red local! Yuhuuu! Felicidad!

Un saludo, Jan.

[1] http://www.frikipedia.es/friki/Diox
[2] Me refiero poner en el action de un form, una url que sea algo así como https://foo.bar/login

Fin de una época... AKA adiós trabajo, adiós

noreply@blogger.com (inedit00) — Sun, 05 Feb 2012 11:46:00 +0000

A finales de este mes también acabo en mi trabajo =).

"Pobre Jan. ¿Te sacan? Puta crisis, afecta a todo el mundo..."
Ummm... Pues no. No me sacan. Ni mucho menos. Os cuento.

Resulta que a mi me encanta estudiar y aprender cosas nuevas. Acabé el Grado Superior de Administración de Sistemas Informáticos, hice las prácticas en eConcept y les molé. Me hicieron un contrato fijo, cobraba un suelo que no estaba mal y *aprendía un montón*. Esto para mí es lo más importante. Casi casi es lo que valoro más: aprender cosas nuevas. Esto es así porque: disfruto aprendiendo, me da un valor añadido, puedo ponerme nuevas metas, me mantengo al día y en definitiva todavía me considero un estudiante.

En la empresa somos muy poquitos. 6 técnicos en total: 4 programadores y 2 de sistemas. Todos son unos cracks: tenemos a un ex-empleado de Microsoft, otro compañero a estado trabajando en el Centro de Supercomputación de Barcelona, un sysadmin que aparte de su trabajo habitual también da clases de CISCO CCNA, y más de uno en el equipo a recibido ofertas por parte de Google para que trabajen para ellos. Trabajar con gente así es una pasada, ya que aprendes muchísimo, se te contagia el interés por las cosas más complicadas o supuestamente difíciles y.... buffff, es genial. Y aunque sean unos técnicos increibles son todavía mejores personas. Ha sido una pasada estar con ellos. Esto es lo que voy a echar de menos.

He estado en proyectos muy interesantes: telefonía de VozIP (con centralita propia y demás) haciendo todo el tema de tarificación y tarifas planas, así como prácticamente todo el backoffice para gestionar los clientes, extensiones, geográficos, etc... También me dieron un proyecto para mi solito sobre gestión de contratos de telefonía (VozIP, fija, móvil y ADSL) para que los comerciales puedan generar de manera electrónica los contratos en casa de los mismos clientes y mandarles el contrato rellenado y listo para firmar al email del cliente para que lo revisen cuando quieran. También he estado ayudando en el proyecto de www.nauticholidays.com haciendo un pequeño CMS, habilitar temas de SEO y me he estado encargando del mantenimiento del proyecto entero durante un par de meses. Todo muy chulo, la verdad.

Bueno, en realidad no todo ha sido *tan* chulo. He tenido que hacer cosas menos agradables como encargarme de mantener una aplicación de facturación (Microsoft Navision, una versión del año de la Pepa) que fallaba (falla) mas que una escopeta de feria... pero bueno. Mejor nos quedamos con las cosas buenas. =)

Básicamente me quedé en la empresa porque el tipo de trabajo era muy interesante, los compañeros eran geniales y sobretodo porque iba a aprender un montón. La otra opción era empezar la carrera de informática en la UPC de Barcelona. Lo planteé del siguiente modo: ahora trabajo, tendré experiència en el Mundo Real(tm), aprenderé un monton y ahorraré todo lo que cobre para poder ir a estudiar la carrera. Y esto he hecho.

El caso es que en la empresa durante el primer año aprendía un montón de cosas cada semana. Era exagerado. Python, SQLAlchemy, CSS, JavaScript, el framework de desarollo (pylons), cosas de sistemas, el modelo MVC, bases de datos no relacionales (MongoDB), colas asíncronas (beanstalk), repositorios (primero bazar y después mercurial), desnormalización de datos, caches, procesos de deploy super-rápidos, Scrum.... La 'putada' de aprender tanto es que al final del primer año alcanzé lo que llamo la "zona de confort".

Esta zona es peligrosa. Llegas a ella cuando empiezas a sentirte cómodo con todas las cosas nuevas que has ido aprendiendo. Llega un momento que ya sabes todo lo que necesitas para hacer tu trabajo de manera eficinente y solo de vez en cuando necesitas revisar la documentación o aprender algo nuevo. Esta zona no me gusta porque es aburrida. Aprender cosas nuevas mola. Aprendes cosas para poder trabajar. Cuando dejas de aprender lo único que haces es trabajar. Y yo todavía me considero un estudiante, no un trabajador. Tendré 40 años ( o mas ¬¬ ) para trabajar. Ahora que me gusta aprender: coño, tengo que aprovechar. O sea, esto es mi punto de vista. Para la empresa la "zona de confort" significa que tienen un trabajador que ya ha alcanzado el nivel de conocimientos que necesitan para que ocupe su puesto de trabajo sin necesidad de formarse o de ayuda externa, por lo que es ideal.

Durante el segundo año he estado trabajando. Sin mas. Aprendiendo muy poquito, pero asentando los conocimientos adquiridos. Y ahorrando, ahorrando mucho. No ha sido tan divertido y emocionante como el primero, pero también ha estado bien. El caso es que ahora he conseguido tener un colchón de dinerito suficiente para estudiar mas o menos tres añitos en Barcelona, por lo que me he preguntado: ¿Por qué seguir trabajando?

Y el tema ha estado claro. El simple hecho de tener esta duda hace que respuesta no pueda ser otra: me las piro. Entre esto y el hecho de que han habido un poco de lios familiares, un servidor se va a vivir a BCN dentro de un mesecito. Tendré 6 meses todos para mi, antes de que empiece la carrera de informática. Tengo ya un par de proyectitos personales pensados que me gustaría hacer y pienso estar con los amigos y familiares. Disfrutar la vida en general, así, por que si =)

A quien ésto no le de envidia, es que no tiene alma, jeje ;)

CISCO CCNA

noreply@blogger.com (inedit00) — Sun, 05 Feb 2012 11:42:00 +0000

El año pasado empecé el curso de CISCO CCNA, o sea Cisco Certified Networking Associate. Muy interesante, la verdad. Para el que no lo sepa la empresa CISCO es una multinacional norteamericana líder en el mercado de las redes (networking). Venden des de routers para hogares familiares ( los Lynksys, puede que tengas uno ), hasta el hardware que se utiliza para comunicar los diferentes continientes como Europa y América. O sea, el backbone de Internet funciona sobre hardware de CISCO. Tienen una gama de productos increíbles, y no sólo ofrecen productos, si no que también imparten formación. Hay lo que ellos llaman "la carrera de CISCO" que se basa en tres niveles con un curso principal en cada nivel, y otros 4 módulos de ampliación. Para verlo mas claramente tenemos el primer nivel que es el CCNA:

CCNA: Curso principal, normalmente de unas 260 horas, es el que yo estoy haciendo. Incluye:

Bloque 1- Aspectos básicos del networking: OSI, TCP/IP, direccionamiento, capa de enlace de datos/física, Ethernet, planificació de cableado, etc...
Bloque 2 - Conceptos y protocolos de enrutamiento: Enrutamiento estático, protocolos de enrutamiento dinámico (RIP, VLSM, CIDR, RIPv2, EIGRP, OSPF)
Bloque 3 - Conmutación y WLAN: Diseño de redes LAN, configuración de switches, VLAN, VTP, STP, enrutamiento entre VLAN, configuración de WLAN.
Bloque 4 - Acceso a redes WAN: PPP, FrameRelay, Seguridad en la red, ACL, VPN's, DHCP, DNS y resolución de problemas en la red.

CCNA Security. Unas 80 horas de curso. Es un módulo de ampliación.
CCNA QoS: 80 horas, va sobre Quality of Service (Calidad de servicio). Para poder distinguir el tráfico prioritario (VozIP, HTTP) y hacer que siempre llegue con una calidad mínima.
CCNA WiFi: 80 horas.
CCNA Service Provider Operation: ni puta idea =). 80 horas seguramente por ser un módulo expansión.

Todavía no he acabado el curso, me quedan dos o tres capítulos del bloque 4 para poderme presentar al último examen parcial, y después tendré que hacer acopio de toda mi voluntad y fuerzas y ponerme a estudiar muy fuerte para verme lo suficientemente preparado como para hacer el exámen final. Tienes que sacar más de un 80% de puntuación para poder aprovar, por lo que no es moco de pavo. Cada intento son unos 200€.

Bueno, este es mi primer motivo por el cual no he estado escribiendo mucho por aquí. Otra cosa que ha influído ha sido el trabajo. Después de hacer 8 horas de curro al día, llegas a casa con pogas ganas de investigar cosas nuevas (aunque algo se hace), pero ya no te quedan fuerzas para escribir nada interesante.

Pero bueno, no desesperemos! El curso de CCNA prácticamente ya lo he acabado y dentro de poco tendré mucho tiempo libre. Os puedo anticipar que he empezado a jugar con el lenguaje de programación de Erlang, que me está encantando. Es un lenguaje funcional donde tenemos "variables invariables", que son variables pero que sólo pueden ser asignadas una vez (o sea, nada de "i++"). No existen las estructuras "while" o "for", ya que se usa recursividad como estructura iterativa, y las listas son el tipo de dato más común en el lenguaje. Una pasada! Ya os contaré lo que vaya aprendiendo y dónde quiero llegar con todo esto. Tengo un proyectito chulo chulo. Si todo sale bien será mi primer proyecto publicado como OpenSource!!

Dentro de un mesecito mas o menos tengo pensado volver a retomar el blog, y intentaré escribir 2 o 3 entradas semanales como en "mis tiempos mozos", por lo que estad preparados para lo que se avecina! =)

Un saludo, Jan.

Plugins Firefox II

noreply@blogger.com (inedit00) — Sat, 17 Dec 2011 12:55:00 +0000

Hace tiempo escribí una entrada sobre los plugins que venía usando en Firefox. Bueno, parece ser que he tirado hacia el minimalismo últimamente y resulta que ya no uso ninguno de los plugins mencionados. Ahora uso tan solo dos:
Adblock Plus: Te quita toooooda la publicidad de Internet. Dejas de verla. Incluso la propaganda que pone youtube.com antes de visualizar un video? Esta también dejas de verla. Es genial. Recomiendo a todo el mundo que se lo instale ni que sea para probar. Además, se va actualizando solo cada tanto, para mantener la base de datos de contenidos publicitaros que tu navegador no tiene que cargar. Super chulo.
ShareMeNot: Sirve para que todos aquellos botones "sociales" como por ejemplo el "Me gusta" de facebook, o el "+1" de Google, dejen de mandar información a Facebook/Google/Twitter sobre las páginas que visitas. Muy interesante para mantener la privacidad.

El ShareMeNot puede que requiera de una explicación adicional. Imaginemos que www.marca.com decide poner el botón "Me gusta" en todas sus páginas. Pues si estás logueado en facebook en el navegador y al mismo momento entras en www.marca.com, Facebook sabe que has entrado en esta página. Esto es debido a que automáticamente asocia el "Me gusta" con tu perfil. El problema es que Facebook sabe las páginas que vas visitando y lo va registrando. Y esto no mola. Por ejemplo, si la página web www.MeGustanLasGordasPelirrojas.com tiene un botón de "Me gusta" y estás logueado en facebook al mismo tiempo, Facebook a partir de ahora ya sabe "un poquito más" acerca de tí. Puede que a partir de ahora te haga publicidad de ciertas chicas con cierto problema de obesidad. Por esto está bien tener un plugin de firefox que te prevenga que se vaya mandando información sobre qué visito a todos los sitios web 2.0 y mantener así la privacidad de nuestros datos.

Y esto es todo por hoy. Un saludo!

Clase de buceo

noreply@blogger.com (inedit00) — Sun, 20 Nov 2011 11:18:00 +0000

En el post anterior[1] comentaba cómo configurar las PAM para desactivar el tiempo de espera en caso de haberte equivocado escribiendo un password. Este post explica el proceso que seguí para saber que no es posible establecer un tiempo de espera personalizado. Siempre te tienes que esperar dos segundos en caso de haberte equivocado de password, o puedes desactivar el tiempo de espera. Lo que no puedes hacer es decir, "espérate 5 segundos en caso de que me haya equivocado de password antes de volver a preguntarme".. También se puede ver lo bonito que es el OpenSource, y la de que el código fuente sea público.

[Preámbulo]

Resulta que en el fichero /etc/pam.d/login hay una opción que pone: "auth optional pam_faildelay.so delay=3000000". Un comentario al lado explica claramente lo que hace esto:

"Enforce a minimal delay in case of failure (in microseconds)". O lo que es lo mismo: Fuerza una pequeña espera en caso de fallo en la autenticación. 3 segundos, para ser mas exactos.

Pues parece obvio pensar que si cambio 3000000 a 1000000, el tiempo de espera cuado haga login fallido se reducirá a 1 segundo.

Probemos antes de hacer el cambio:
$ sudo echo 1 # Comando chorra, pero lo importante es que nos pida el password
[sudo] password for inedit: badpassword
--- pasan unos dos segundos, aproximadamente ---

Hacemos el cambio en el fichero, poniendo el parámetro "delay=1000000". Probamos de nuevo:
$ sudo echo 1
[sudo] password for inedit: badpassword
--- pasan unos dos segundos, aproximadamente. Lo mismo que antes... ---

mmmm... mierda, no funciona. Probemos lo propuesto en el post anterior, o sea, poner el parámetro nodelay en el fichero /etc/pam.d/common-auth:
auth [success=2 default=ignore] pam_unix.so nullok_secure nodelay

Probamos de nuevo:

$ sudo echo 1
[sudo] password for inedit: badpassword
--- inmediatamente despues nos dice que la contraseña es incorrecta y que lo intentemos de nuevo. Tiempo de espera: cero segunos ---

Genial. Parece que el parámetro "nodelay" funciona. Pero ¿Por qué no funciona el "delay=3000000"?

[Siguiendo pasos lógicos]
Vale, resulta que el parámetro "nodelay" se lo ponemos como parámetro a un fichero llamado "pam_unix.so". Ni idea de qué coño hace este fichero, pero busquemos a ver si existe ene el sistema:

$ locate pam_unix.so
/lib/x86_64-linux-gnu/security/pam_unix.so

Touché, existe. mmmm..... vale. ¿Ahora qué hacemos con el? Ni idea de que hace realmente el fichero. Lo he abierto y es un binario....mmmm.... Vale, ya lo tengo. Descubramos qué paquete ha creado este fichero:

$ dpkg-query -S /lib/x86_64-linux-gnu/security/pam_unix.so
libpam-modules: /lib/x86_64-linux-gnu/security/pam_unix.so

Con que libpam-modules, eh? Vaaaale, pues mira, estamos siguiendo la pista y no nos va mal. Ahora ¿cuál puede ser el siguiente paso? Pues descargar el código fuente y que hace realmente el código:
$ mkdir ~/killme
$ cd ~/killme
$ apt-get source libpam-modules

Esto nos habrá creado un par de ficheros en el directorio "killme" [2].

[Buceando en el código]
Vale, ahora tenemos el código de la "libpam". ¿Qué hacemos? Lo obvio, aquí sería buscar alguna referéncia a "pam_unix.so". Pero como los ficheros ".so" son compilados y nosotros nos hemos descargado el código fuente, vamos a probar lo siguiente:
$ find -name "pam_unix*"

Oh! Genial, tenemos resultados! Parece que existe una carpeta interesante: "./pam-1.1.3/modules/pam_unix"

Vale, ahora deberíamos buscar algo de utilidad dentro de esta carpeta. Juguemos con "grep", a ver si hay suerte:
$ cd ./pam-1.1.3/modules/pam_unix2
$ grep nodelay -i # -i es para hace "ignore-case". O sea, que no distinga entre mayúsculas y minúsculas.

pam_unix.8:\fBnodelay\fR
pam_unix.8.xml:
README:nodelay
support.c: if (off(UNIX_NODELAY, ctrl)) {
support.h:#define UNIX_NODELAY 16 /* admin does not want a fail-delay */
support.h:/* UNIX_NODELAY */ {"nodelay", _ALL_ON_, 0100000},

Tenemos resultados! Parecen interesantes los ficheros "support.c" y "support.h". Revisado el fichero "support.h" parece que solo hay la declaración del parámetro UNIX_NODELAY.
Veamos el fichero "support.c", a ver que contiene:

[...]
#ifdef HAVE_PAM_FAIL_DELAY
if (off(UNIX_NODELAY, ctrl)) {
D(("setting delay"));
(void) pam_fail_delay(pamh, 2000000); /* 2 sec delay for on failure */
}
#endif
[...]

Eureka! Lo hemos encontrado! Vale, yo no tengo ni idea de C. Nunca he programado nada serio en C, ni mucho menos una librería de sistema para Linux. Pero si hemos llegado hasta este fichero buscando cosas lógicas, ahora no nos va a detener un poco de código en C. Parece que es el código fuente de "pam_unix.so".

Vamos a intentar leer lo que pone este pedacito de código. La condición "if" parece que comprueba lo siguiente:
SI (el parámetretro UNIX_NODELAY és igual a falso) ENTONCES {
Espérate 2 segundos
}

Pues ya lo tenemos, señores. Resulta que no se puede definir un tiempo de espera, ya que el tiempo de espera está puesto de modo estático en el código. En ningún momento el código va a leer la variable "delay=3000000", por lo que si ponemos "delay=5000000" es normal que lo ignore.

[conclusión]
¿Cómo hemos podido sacar todo esto? Pues la respuesta es muy simple: porque es Software Libre y se puede conseguir el código fuente muy facilmente a través de Internet. Inspeccionando el código vemos claramente lo que hace ( y mejor todavía, lo que no hace ). En este punto, y si tuviese los conocimientos de C necesarios, podría reescribir el código fuente para que aceptara un parámetro "delay" y que pudiese ser definido des de la pam.d/login. Una vez hechos los cambios, podría mandarlos al mantenedor del paquete y en caso de gustarle dichos cambios, los incorporaría en el código de la libpam. Y el mundo sería un lugar mejor y lloverían gominolas del cielo :)

[1] Recomiendo que te lo leas, sinó este pot no tiene mucho sentido.
[2] Me gusta bastante crear directorios con el nombre "kill" o "killme" para usos temporales, ya que es un modo de saber si puedo borrar el directorio sin ni tan solo preocuparme de ver que contiene. En cambio, un directorio que llamado "temp" o "temporal".... bueno, si, son datos temporales. Pero hasta cuando? Servirá lo que hay dentro? Es algo lioso. Usando "killme" el tema está claro, puedes borrar la carpeta cuando quieras sin ningun problema, ya que el contenido de la misma no es importante ;)

Saber a qué paquete pertenece un fichero

noreply@blogger.com (inedit00) — Thu, 08 Sep 2011 21:39:00 +0000

Algunas veces hay ficheros con nombres curiosos, y uno se pregunta qué paquete debe haber instalado este fichero. Por ejemplo el fichero:

/usr/bin/pico

Yo me pregunto, ¿quién lo habrá puesto ahí?

Pues fácil:
$ sudo aptitude install dlocate -y
$ dlocate /usr/bin/pico
> perl: /usr/bin/piconv

Pues mira, ha sido el paquete "perl".

Esto también sirve para ficheros de configuración, así como carpetas del sistema. Todo lo que esté "trackeado" por dpkg, es suceptible de ser encontrado por dlocate.

Un saludo, Jan.

UPDATE: El comando "dpkg-query -S /usr/bin/see" también hace lo mismo.

"sudo su" sin espera ( nodelay )

noreply@blogger.com (inedit00) — Thu, 08 Sep 2011 21:02:00 +0000

Pues como hoy me he tirado 30 minutos buscando esta opción y considerando que hay poca información sobre ella ( y menos en castellano ), así va:

¡NODELAY en pam_unix.so!

[¿De qué va el tema?]
Pues se trata de optimización de tiempo y comodiad en la consola. Cuando ejecutamos un comando con "sudo", normalmente nos pide la contraseña ( a menos que lo hayamos desactivado ). Esto es la política de seguridad bastante recomendada, ya que si no cualquier persona te podria juankear el ordenador si lo dejas solo un momento sin bloquear.

[Total, dónde está el problema, entonces?]
Pues que si al ejectuar cualquier comando con sudo, te equivocas al picar tu password, te tienes que esperar 3 segundos para volverlo a picar. Y esto es un coñazo. Ejemplo:

inedit@tpad:~$ sudo echo 1
[sudo] password for inedit: foo
- espera de tres segundos -
Invalid password, please try again:
[sudo] password for inedit: bar
- espera otra vez de tres segundos -
....etc...

[HOWTO]
Total, que esta opción se puede desactivar a través de las PAM de linux del siguiente modo:

sudo vim /etc/pam.d/common-auth

Y modificar la lína donde pone:
auth [success=2 default=ignore] pam_unix.so nullok_secure>

Y cambiarla por:
auth [success=2 default=ignore] pam_unix.so nullok_secure nodelay

De este modo se desactiva totalmente el tiempo de espera entre logins. Cuando te equivoques al escribir tu password, automáticamente te volverá a preguntar la clave.

[Precaución]
Y uno se preguntará, ¿por qué puñetas no estaba desactivado esto ya? Pues por motivos de seguridad: previene que se lanzen ataques de fuerza bruta contra el PC, ya que el hecho de que te tengas que esperar 3 segundos tras cada intento fallido, limita mucho los ataques ( los hace inviables por la cantidad de tiempo que se necesita probar un número acceptable de claves ). Aplicando la regla anterior estamos quiando esta restricción. O sea que cuidadín en ejecutar algo así en una máquina de producción donde tenga SSH expuesto en Internet y demás. Quien avisa no es traidor.

[Nota final]
Como siempre, en un extremo tenemos seguridad, y en el otro tenemos comodidad. No podemos elegir ambos. Por lo que lo mejor es quedarse siempre en un punto medio.

Un saludo, Jan.

Posdata: Si alguien consigue sacar algo en claro sobre el fichero /etc/pam.d/login y su parámetro "pam_faildelayso delay=3000000", que por favor deje un comentario y así completamos la información. Yo no he sido capaz de ajustarlo a un segundo. Gracias de antemano.