lunes, 26 de marzo de 2012

Dig Your Own Hole

[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

sábado, 17 de marzo de 2012

Erlang (III) Semana 1

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í:
  1. 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, ....
  2. 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.
  3. Usar gen_server tanto para el gaab_server como para gaab_user, quitar toda la funcionalidad custom que ya me dá gen_server.
  4. 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 siguiente: Erlang (IV) Semana 2

martes, 13 de marzo de 2012

MOC ha muerto. Exaile sube al ring.

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

jueves, 8 de marzo de 2012

Erlang (II) Aprendiendo lo básico

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)

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

martes, 6 de marzo de 2012

Erlang y WebChats (I)

[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: amd64
hw.model: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
hw.ncpu: 24
hw.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

domingo, 4 de marzo de 2012

Problemas con el ratón en ioquake3

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!

jueves, 1 de marzo de 2012

[fun] Se finí

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