martes, 27 de mayo de 2008

¡Feliz Cumpleaños, Vale!


Ya hace tres años que nació la personita más importante de mi vida. Tiene un carácter dificil (sobre todo cuando está cansada), pero es generosa y buena compañera. Elegí como nombre para ella el de una heroína creada por Robert E. Howard, quien se hiciera famoso por las historias de Conan el Cimmerio, Kull el Conquistador, y Solomon Kane. Valeria es una guerrera, poderosa e imbatible con la espada. Así me la imaginé a ella, y creo que no me equivoqué por mucho.

Todavía me acuerdo de aquellos indescriptibles diez segundos cuando la ví por primera vez, saliendo del vientre de su mamá y sentí aquella sensación tan extraña, tan increíble... Por un momento me pareció estar en otro lugar, presenciando algo imposible... me invadió un sentimiento de compasion, amor y humildad que nunca hubiera creído ser capaz de sentir.

Supongo que de eso se tratan los hijos, de inspirarnos y de hacernos ver el mundo de otra manera. Lamento no poder ser constante en eso y que mi vida esté plagada de nimiedades y cosas sin importancia que opacan ese momento y que a veces me hacen olvidar las cosas realmente importantes.

¡Feliz cumpleaños, Valeria!

De parte del papá más feliz del mundo :-)

Lo barato sale caro. Lo gratis, también.

Hace algún tiempo que tenemos como cliente a una pequeña empresa del ramo de la maquinaria y equipos de producción y de control (así se presentan). Una de las particularidades de esta empresa es un eficiente y minimalista manejo de los recursos monetarios, a tal grado que las decisiones que involucren inversiones de cualquier tipo o que afecten de alguna manera la economía de la empresa en fracciones de unidad son siempre un tema de discusión y de debate acalorado en la mesa directiva. Creo que así ilustro bastante claramente el concepto.

Cuando empezamos con ellos, les diseñé un sitio web en el cual utilicé modelos en 3D realizados con programas de modelado y de manejo de gráficos, lo cual me permitió comenzar a esbozar la idea que me habían dado originalmente cuando nos reunimos la primera vez: la tecnología y la innovación. El diseño preliminar no gustó para nada y fué descartado sin más, pero no por un problema en cuanto al diseño, sino a preconceptos de uno de los dueños, pasando ellos a realizar su propio diseño, convirtiéndome yo en "implementador" de sus conceptos, mas no diseñador como originalmente era.

Finalmente, después de varios trajines, se terminó el diseño del sitio, el cual no me satisfizo para nada, pero como era lo que el cliente quería (y también era lo que pensaba pagar), así fué como quedó. Por supuesto que mis ideas de dinamizar el sitio con el uso de lenguajes de scripting del lado del servidor, para agregar reactividad y movimiento, fueron descartadas también por resultar demasiado caras para el cliente, sobre todo teniendo en cuenta que este tipo de empresarios tienden a comparar elementos incomparables sin tener experiencia ni capacidad para hacerlo. No importaba si presupuestábamos con opción a pago en varias y accesibles cuotas o no. El tiempo que se invierte en hacer el trabajo tiene un costo, el cual es siempre inaceptable para las empresas como este cliente. Y así prevaleció el precio y la "razón del cliente" por sobre todo lo demás.

Tengo la particularidad de ser bastante exigente en cuanto a mi trabajo, sobre todo en lo que respecta al diseño de conceptos gráficos y de elementos funcionales. No soy un gran diseñador, pero cuando me propongo algo, trato de hacer lo mejor posible y quedar contento con el trabajo hecho. En este caso, fué todo lo contrario. El sitio web terminado era la antítesis de lo que yo quería lograr, era demasiado pobre y poco interesante, y solo respondía a la necesidad de "estar en internet", no a la necesidad de "tener una buena imagen en internet", que era mi objetivo al principio. Pero lo que sí tenía, era que había salido barato, que aparentemente era el objetivo principal del cliente.

El tiempo pasó, y esta gente empezó a darse cuenta de que necesitaban que el sitio tuviera e hiciera más cosas, pero todo sale caro cuando uno no quiere invertir absolutamente nada, así que todo presupuesto fué rechazado, a lo cual simplemente el sitio fué quedando como una reliquia infame e indigente, juntando polvo en el cyberespacio.

Hace poco, este cliente me contactó de nuevo para decirme que iban a rediseñar el sitio. Naturalmente que consiguieron alguien cuyo presupuesto era imbatible, lo cual no es raro en un país donde hay tanto desempleo, a pesar de que en el área informática, si no tenés empleo hoy día es porque no estas a la altura del trabajo que se ofrece, dado que abundan las opciones y la demanda de mano de obra calificada. Así que me limité a esperar y ver el resultado. Solo gratis podía ser más barato que lo que nosotros habíamos cotizado, así que no esperaba un gran despligue de solidez y buena calidad.

Y el resultado no se hizo esperar...

Primero, tuve que explicarle a la persona que desarrollaba el sitio, que existe un protocolo llamado F.T.P., mediante el cual se podía publicar el nuevo sitio en el servidor donde estaba el anterior, algo que aparentemente el desarrollador no sabía. Pero además de eso, los desarrolladores (eran en realidad varios estudiantes de una academia que se presenta como instituto universitario) parecen haberse salteado gran parte de la escuela primaria, donde enseñan a escribir palabras con todas las letras (y donde también enseñan a poner éstas llamadas "letras" en las posiciones correctas). Y ni que hablar que ninguna de las páginas del sitio tiene título (bueno, tienen un título que dice "Documento sin título"...), sin contar tampoco que el formulario de contacto (el cual también tenía el sitio que yo había diseñado originalmente y que le daba la poca utilidad que éste último tenía, dado que recibían bastantes consultas a través de él) no hace absolutamente nada cuando uno lo llena y presiona el botón "Enviar". Me dá miedo pensar en qué podría pasar si ese formulario se habilita finalmente (asumo que el sitio está de alguna manera sin terminar) y este "experimentado" equipo de desarrolladores decide que se procesen esos datos a través de un programa en el servidor...

Hay que agradecer a DINAMYPE por poner al alcance de los empresarios como mi cliente, esta "mano de obra calificada" a un precio razonable, así quienes no quieren la calidad, la funcionalidad y la seriedad que proveemos quienes cobramos por nuestro trabajo, pueden tener productos de la calidad que se merecen, sin tener que arriesgar nada más que su imagen, que por lo pronto parece ser el pasivo al que menos valor le dan.

Resulta extrañamente alarmante que el representante del instituto evoque esta "exitosa" operación con un dejo de orgullo y pompa, lo cual es una clara demostración de falta de información y de exceso de confianza en un proceso que tiende a alimentar el concepto de que principiantes sin experiencia y mal capacitados pueden producir desarrollos válidos y viables en un área súmamente competitiva y donde hay altos standards técnicos que contemplar y respetar, no solo por una cuestión de imagen, sino también por una cuestión de seguridad. No solo hablamos de producir algo que se vea bien, sino de producir algo que también funcione y se comporte bien.

Todavía hay "empresarios" que siguen creyendo que la inversión real en productos de buena calidad es un gasto inaceptable, y que lo barato o lo gratis es realmente barato o gratis, siempre que no se vea salir dinero de sus bolsillos.

Como dice el comercial de la conocida tarjeta de crédito:

Ver una empresa hacer el ridículo por no querer pagar por un trabajo bien hecho, no tiene precio. Para todo lo demás, está MasterCard.


:x

jueves, 22 de mayo de 2008

Spam de Panda Security

De todas las empresas de antivirus que existen en el mundo, no hay ninguna más engañiza y sensacionalista que Panda Security.

Cuando sacaban los reportes de virus por televisión (en un noticiero local), las amenazas eran increíbles, super destructivas y muchas veces rivalizaban en inteligencia incluso con Skynet. Le escuché decir a una chica que presentaba la lista semanal de amenazas de seguridad, que uno de los virus se comprimía a si mismo en más de 350 formatos distintos para pasar desapercibido, y recuerdo haberme preguntado si un programa capaz de utilizar esa cantidad de formatos de compresión (cuidado, la presentadora habló de "formatos de compresión", no de polimorfismo aleatorio) no sería acaso demasiado grande como para pasar realmente desapercibido, incluso por un usuario inexperto, y eso sin contar que probablemente no existan tantos formatos de compresión disponibles (no quiero aventurar números, por las dudas).

La cosa es que estos personajes cayeron aún más bajo esta semana enviandome nada menos que SPAM. Les publico el cuerpo del mensaje para que vean por ustedes mismos que esto es una tomada de pelo realmente patética de parte de esta gente hacia los internautas:


Dear user,

At Panda we want to keep our users up-to-date at all times regarding our products and services to ensure they have maximum protection.

For this reason we are currently checking all our mailing lists to be able to communicate with all customers that want us to do so, and to update the list of those that do not want to receive communications from us.

If you don’t want to continue receiving information from us via email, please click here.
Otherwise, we will assume that you want to continue receiving information about our products, new versions, news, etc.

We apologize for any inconvenience caused. Thank you for choosing Panda Security.

Customer Services Department


Estimado usuario,

Desde Panda queremos mantener a nuestros usuarios puntualmente informados de las novedades en materia de productos y servicios para facilitar así al máximo la labor de protección de sus equipos.

En este sentido estamos trabajando en la comprobación de nuestras listas para poder llegar a informar a todos aquellos clientes que así lo desean y para asegurar una actualización de aquellos que no quieren recibir nuestras comunicaciones por e-mail, en la que hemos detectado algunos errores.

Si éste es su caso y no desea continuar recibiendo información por e-mail, por favor, pulse aquí. De lo contrario entenderemos que desea continuar recibiendo información sobre nuestros productos, nuevas versiones, noticias de interés, …

Disculpe las molestias que le hayamos podido causar. Gracias por confiar en Panda Security.

Dpto. de Atención al Usuario


Por si no lo leyeron bien, están actualizando la lista de usuarios que NO quieren recibir correo de ellos, y no al revés, que sería lo lógico para una empresa seria que esté haciendo un "e-mail marketing". ¿Y porqué digo que están haciendo eso y no lo que dice la primera parte de la frase? Por una razón muy simple: Yo nunca fuí cliente de Panda (¿se acuerdan de que no uso antivirus?) ni les pedí ninguna información a través de la cuenta de correo en la que recibí este spam, así que no sé de donde sacaron que podían mandarme correo excusándose en que están revisando sus listas (en las que "detectaron errores").

Y lo peor es que me tengo que desuscribir para no recibir más su basura, lo cual es un indicativo más que fiel de que se trata de propaganda NO solicitada.

Claro, "detectaron errores" (según la versión en español, ya que la versión en inglés no dice eso) en su base de datos. Los errores deben ser que tiene más registros de usuarios que no quieren aceptar su basura que los que ellos quisieran que hubiera. Para mi el error que cometieron es creer que le pueden mandar SPAM a un usuario que los odia acérrimamente.

Ya los deploraba por lo lamentable de su propaganda terrorista y desinformativa, pero ahora me caen aún peor... ¿a ustedes no?

:w ~gcp/basura_de_panda.txt
:q

martes, 20 de mayo de 2008

Receta del mes: Pastel de pescado al curro... digo, al curry

Bueno, para este mes tenemos un plato semi tradicional que preparo en casa bastante seguido (nos gusta mucho el pescado). No es dificil, así que espero que lo disfruten.

Ingredientes:



  • 1 Kg. de filetes de pescado sin espinas (cazón, merluza, lenguado, etc.)

  • 1/2 Kg. de papas

  • 1 litro de leche

  • 300 g. de harina

  • 300 g. de muzarella en fetas

  • 300 g. de tomate fresco o de lata (tomates "perita") picado

  • 200 g. cebolla picada

  • 100 g. de morron verde picado

  • 4 hojas de laurel

  • 2 cdtas. de curry

  • 1/2 cdta. de pimienta negra molida

  • 1 pizca de Adobo

  • 1 pizca de Orégano

  • 30 g. de Manteca

  • 3 cdas. de Aceite de oliva



Preparación:

Se ponen a hervir las postas de pescado junto con 3 hojas de laurel hasta que estén cocidas. Este proceso lleva poco tiempo, dado que el pescado se cocina rápidamente y si se hierve demasiado, se deshace, complicando la preparación posteriormente.

Mientras hierve el pescado, se pelan las papas y se cortan en rodajas de aproximadamente entre 7 y 8 milímetros cada una (ojo con el calibre, que desafila la cuchilla...).

Una vez hervido el pescado, se sacan las postas con una espumadera y en la misma agua se hierven las papas, con cuidado de que no se pasen. Esto tiene un doble propósito, dado que la papa se impregna con el sabor del pescado y se cocina también más rápidamente (¡ahorremos energía y tiempo!).

Por otro lado, se saltea la cebolla y el morrón en una olla pequeña con aceite de oliva hasta que la cebolla se haya vuelto casi transparente. Se agrega el tomate picado y se prepara una salsa, agregando una hoja de laurel, una cucharadita de azucar (para quitar el ácido al tomate), dos cucharaditas de sal y una pizca de adobo a la mezcla para condimentarla. Esta salsa toma unos 15 minutos aproximadamente en hacerse.

En otra olla se derrite la manteca, se la mezcla con la harina, se la mezcla con sal y se vierte lentamente la harina y la leche para hacer una salsa blanca liviana, a la cual se le agregará el curry y la pimienta. El curry cambia el color y el sabor de esta salsa, dejándola agradable a la vista y al gusto.

Una vez que tenemos todo esto preparado, procedemos a tomar una asadera de unos 35 cm. x 20 cm. y le volcamos una capa de la salsa con curry, luego ponemos una capa de papas, un poco de salsa de tomates, apenas para colorear la papa, luego acomodamos todo el pescado sobre las papas, una capa de salsa de curry nuevamente, otra vez papas, el resto de la salsa de curry y terminamos con el grueso de la salsa de tomates por encima de la salsa de curry, tapando finalmente toda la asadera con las fetas de muzzarella y espolvoreamos por encima un poco de orégano.

Llevamos la asadera al horno durante unos minutos hasta que se funda la muzzarella y ya está listo.

Emplatado:

Bueh... no es tan complicado... Cortalo en porciones suculentas y servilo solo, con una buena rodaja de pan y un buen vinito tinto (no siempre el vino blanco es lo mejor para el pescado y mucho menos para cuando viene adentro de ESTE pastel...).

Bon apéttit!

lunes, 19 de mayo de 2008

¿Quien lee este blog?

Si, a vos que estás sentado ahora frente a la pantalla leyendo esto... ¿quien sos?...

Puse una encuesta abajo preguntando algo así como esto: "¿Cómo calificaría a Windows Vista?" y todo parece indicar (sobre una base de 7 votos al dia de hoy), por lo menos dos cosas:

1) Casi todos los usuarios que han entrado al blog y han votado odian acérrimamente a Windows Vista.

2) Por lo menos un usuario no lo conoce, pero como usa Linux, no tiene necesidad de semejante incursión hacia la vía dolorosa del Opus Bill (donde usan como cilicio un cable UDMA con el logo "Designed for Windows Vista").

Eso me dá para pensar que el perfil de visitantes de este blog es bastante técnico y experimentado, aunque siempre me puedo equivocar...

Por otro lado, conozco a muchos visitantes personalmente, pero no a todos, así que me gustaría que quienes anden perdiendo el tiempo por este rincón del cyberDespacio, dejen un comentario que me dé una idea de quienes son. No tienen que poner el nombre si no quieren, pero dejen algo que me ayude a reconocerlos, así sé para quienes estoy escribiendo y puedo ajustar mis artículos para el público que viene seguido.

Quien sabe, ¡capaz que hasta empiezo a escribir con dedicatoria y todo! :-P

:x

miércoles, 14 de mayo de 2008

Tutorial: Probar un proxy a través de un tunel SSH

Inicio hoy una serie de tutoriales que espero sean del agrado de los visitantes. La verdad, no quería que este blog terminara siendo un típico recetario técnico, pero como habrán visto en mis últimos cuatro artículos, es casi en lo que se ha convertido... A mis lectores no técnicos, les prometo publicar algo divertido en breve.

A los técnicos, espero que disfruten de este tutorial, y espero tener tiempo de agregar alguno que otro sobre otras nimiedades similares de vez en cuando.

Tutorial: Probar un proxy a través de un túnel SSH

¿A quién no le ha pasado que un cliente le mande un mensaje de correo que dice "no tengo internet", y no le dá más pistas que "me aparece un cartelito en el internet explorer y no puedo abrir ningún sitio..."?

(Si, dije bien, el usuario dice NO tener internet, pero manda un mensaje de correo avisando del problema... (¿¡!?) recuerden que se trata de un pobre usuario, quien seguramente no sabe que para poder enviar correo, necesita internet, y el extraño hecho de que pueda enviar dicho mensaje de forma exitosa no sirve para demostrarle que en realidad el problema NO es que no tiene internet...)

Bueno, cuando eso pasa, ya sabemos (por simple razonamiento deductivo o por descarte) que el problema está en otra parte. Como el usuario no nos envió el mensaje que aparece en el "cartelito del internet explorer", tenemos que deducir que no es capaz tampoco de realizar un diagnóstico apropiado, aún indicándole telefónicamente cuales pasos debe seguir (de hecho, he intentado explicarle a un usuario como intentar un diagnóstico basándome en herramientas simples y técnicas sobrádamente fáciles de ejecutar, como por ejemplo, hacer un telnet al puerto 80 de www.sitioquefalla.com, teclear "HEAD / HTTP/1.0" y apretar dos veces seguidas la tecla ENTER, obteniendo como único e invariable resultado la pérdida de tiempo más atróz y el más terrible y atormentador de los sentimientos de defraudación e impotencia que haya sentido...), he terminado siempre recurriendo a técnicas totalmente unilaterales (sé que yo no me voy a equivocar en mis propias instrucciones), de las cuales siempre el resultado es el deseado: saber qué pasa sin ayuda ninguna del usuario.

Y bueno, en este caso, veremos cómo hacer para saber si el problema en cuestión es causado por el proxy, haciendo lo mismo que hace un usuario de la red detrás del firewall que vamos a diagnosticar.

Normalmente, utilizo SSH para conectarme a los firewalls de los clientes remotamente, lo cual me permite diagnosticar casi de primera mano cualquier problema de la red, incluso en algunos casos problemas físicos. En este caso, el firewall es un linux al cual me conecto remotamente vía SSH.

Esta vez, para poder diagnosticar el proxy una vez conectado, necesito saber qué implementación es, así que me conecto al firewall del cliente y reviso los procesos del mismo:


root@fw-cliente:~ # ps xa
[...]
10508 ? Ss 0:00 squid
10510 ? R 1:03 (squid)
[...]


Bueno, tenemos Squid como implementación, lo cual es bastante común en mis instalaciones. Además, es altamente relevante el hecho de que el proxy está en ejecución en este momento, así que puedo descartar un fallo de funcionamiento que lo haya hecho caer. También deduzco, por el tiempo real de ejecución, que no está generando demasiada carga en el sistema, lo cual también es un indicativo de buena salud del proceso.

Reviso los logs, los cuales no parecen mostrar ningún problema, así que el misterio se complica. Normalmente, todos los problemas que pueda tener el proxy, suelen quedar registrados en los logs (en la mayoría de las implementaciones de Squid están el /var/log/squid/), lo cual terminaría rápidamente con el diagnóstico (y con este tutorial), pero en este caso, resulta que el usuario no puede entrar al sitio http://support.microsoft.com (si leyeron mi artículo anterior, se darán cuenta de qué hablo), y en los logs no queda ningún registro del problema, sino que, al contrario de lo que pudieramos pensar, los logs demuestran que el proxy vive despreocupadamente su vida totalmente ignorante de la situación lamentable de los servidores de Microsoft... así que tengo que seguir investigando.

Ahora veamos en qué puerto está configurado este squid, para lo cual tenemos dos opciones, o revisar la configuración, o ver qué puerto está "escuchando" este programita. Opto por la segunda opción, que me resulta más rápida y entretenida:

root@fw-cliente:~ # netstat -npl --inet
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:50393 0.0.0.0:* LISTEN 5347/sshd
tcp 0 0 192.168.0.1:3128 0.0.0.0:* LISTEN 10510/(squid)
[...]


Y luego, dependiendo de en qué sistema operativo estoy en ese momento (si estoy en la casa de algún amigo o en un cybercafé, probablemente no tenga muchas opciones...), veo de configurar una segunda conexión SSH, pero declarando un túnel en la misma que apunte al puerto del proxy.

En Windows, utilizo PuTTY (de Simon Tatham, el mismo autor de Palm Puzzles, un adictivo set de puzzles que entretienen mis momentos de ocio cuando estoy en viajes), un excelente programa Open Source para varias plataformas y que maneja conexiones SSH y Telnet.


Así que configurar un túnel en PuTTY es tán simple como especificar en "Source port" el puerto que quiero (uso el mismo que usa el proxy, dado que no está ocupado en la máquina en la que estoy trabajando), y en "Destination", pongo la dirección IP y el puerto del proxy, separado por ":". Luego presiono el botón "Add" y ya está listo. Si ya teníamos la conexión con el firewall abierta y realizamos una "reconfiguración", no hay que hacer más nada, de lo contrario, si estamos configurando una nueva conexión, una vez aplicada la configuración del túnel, debemos conectarnos al firewall para que surta efecto.

En Linux/Unix, con OpenSSH la cosa es simple:

gcp@ereshkigal~: $ ssh -p 50393 -L 3128:192.168.0.1:3128 ops@fw-cliente.cliente.net
Password:
Last login: Wed May 14 11:32:47 2008 from gcpsite.homelinux.net
Welcome to FW-Cliente (There's no place like 127.0.0.1!)
ops@fw-cliente:~ $


Ese garabato significa algo así como: conectarse vía SSH al equipo "fw-cliente.cliente.net" utilizando el usuario "ops", a través del puerto 50393 (vean arriba el listado que resulta de la ejecución del netstat para darse cuenta de en qué puerto escucha el sshd), y crear un túnel Local desde el puerto origen 3128 de mi equipo, hacia el puerto destino 3128 de la dirección remota 192.168.0.1.

Una vez configurado el tunel, simplemente configuro el navegador que tenga a mano para que utilice el proxy local. En Internet Exploder:


En Firefox:



Nótese que uso la dirección "localhost" (que es "mi punta" del túnel) y el puerto 3128, que es el mismo que configuré en el PuTTY/SSH. Esto significa que cuando intente navegar con esa configuración, estaré utilizando en realidad el proxy del firewall remoto, lo cual me ayudará a probarlo como si estuviera en la misma red de los usuarios detrás de dicho firewall. De eso se trata todo esto... :-)

Luego, ponemos a desplegar los logs del Squid en una consola del firewall para poder verlos avanzar mientras intentamos navegar (y descubrir otros potenciales problemas) y comenzamos la prueba:

root@fw-cliente:~ # tail -f /var/log/squid/access.log | grep " 192.168.0.1 "
1210813210.057 2386 192.168.0.1 TCP_MISS/200 34612 GET http://support.microsoft.com/ - DIRECT/65.54.166.122 text/html
1210813212.191 1615 192.168.0.1 TCP_MISS/200 49840 GET http://support.microsoft.com/common/script/gsfx/common.js? - DIRECT/65.54.166.122 application/x-javascript
1210813214.227 548 192.168.0.1 TCP_MISS/200 11558 GET http://support.microsoft.com/common/script/gsfx/search.js? - DIRECT/65.54.166.122 application/x-javascript
[...]


Nótese que la dirección IP del cliente del proxy (nosotros) es la misma dirección interna del firewall, dado que el túnel termina allí. Esto puede resultar útil para el filtrado de la salida del tail (lo que hice con el grep) y así evitar que la consola se vea plagada de mensajes que le corresponden a conexiones de otras direcciones IP de la red lan que también están navegando y que no queremos ver en ese momento.

También hay que tomar en cuenta que cuando usamos políticas extremadamente restrictivas, la IP del mismo proxy podría no estar en la ACL donde se definen las IP de la LAN permitidas, así que si ven mensajes TCP_DENIED/400 durante la prueba, el problema probablemente sea que la IP interna del firewall no está en la lista de control de acceso que tiene permiso de navegar... Supongo que se darán cuenta de otros detalles cuando ejecuten la prueba.

Ah, un detalle más: Esta técnica se puede utilizar para cualquier servicio y para cualquier proxy que se quiera diagnosticar de la misma forma. Las posibilidades son inagotables, así que no duden en jugar con los túneles para lograr otras formas de "entretenimiento" basadas en esta técnica.

Y bueno, por ahora es todo. Creo que es un buen comienzo y espero que les haga provecho.

Happy hacking!

Squid y el sitio de soporte de Microsoft no se llevan...

Hace unos días me llamó un cliente diciendo que no podía entrar en http://support.microsoft.com. Yo podía entrar perfectamente desde mi enlace, así que este cliente podía tener un problema con su propio enlace o con su solución de filtrado de contenido web. El está utilizando un firewall que tiene instalado un Squid como proxy/cache, y además, está autenticando a sus usuarios vía NTLM, así que me dediqué a chequear los logs en busca de algo que me iluminara.

Los logs no indicaban ningún problema evidente, así que me decanté por una captura de tráfico en la interfaz lan del firewall para poder "ver" qué podía estar pasando entre el navegador del usuario y el proxy. Todo aparentaba estar normal cuando se intentaba acceder al sitio, pero entonces ví que el sitio contestaba de una forma bastante peculiar.

El RFC-2616 (HTTP/1.1) especifica que los servidores web pueden declarar una directiva denominada transfer-encoding en la cabecera de los mensajes para especificar que es necesaria una transformación de los mismos (NO del contenido transportado DENTRO de los mensajes, sino de los mensajes en sí) para asegurar el transporte seguro de estos a través de la red. Esto significa que si el servidor hace una modificación del mensaje para codificarlo de alguna manera, el mismo debe declarar que dicho mensaje fué modificado y especificar dicha transformación, de forma tal que los clientes puedan reconstruir o decodificar el mensaje para poder extraer su contenido posteriormente.

Básicamente, el sitio de soporte de Microsoft trata de forzar el encoding de sus mensajes siempre, independientemente de que la consulta se haga vía HTTP/1.0 (que es la forma en la que Squid hace sus consultas). O sea, a ver si queda claro: el servidor de Microsoft fuerza el transfer-encoding a pesar de que según el RFC (ver sección 3.6.1 del RFC-2616), declarar el transfer-encoding hacia clientes HTTP/1.0 está explícitamente prohibido (¿Microsoft rompiendo standares? ¡Increíble!)

Claro, los usuarios que utilizan Squid como proxy/cache creerán que el problema es de Squid, aunque la realidad es que el problema es del servidor de los "Genios de Seattle"TM...

Para resolver este problema, hay dos opciones posibles:


  • Si el usuario utiliza Internet Explorer, puede ir a las Opciones de Internet, y en Avanzadas, y desmarcar la opción que dice "Usar HTTP1.1 para conexiones a través de proxy" (lo cual no es muy bien visto por los administradores de redes de más de dos o tres equipos...)

  • Modificar la configuración de Squid para que deniegue el encoding que intenta forzar el servidor, para lo cual hay dos opciones:

    1. Si está utilizando Squid 2.6.X, deberá agregar una configuracion similar a esta:

      acl msbroken dstdomain support.microsoft.com
      header_access Accept-Encoding deny msbroken

    2. Si está utilizando Squid 3.X, deberá agregar una configuración similar a esta:

      acl msbroken dstdomain support.microsoft.com
      reply_header_access Accept-Encoding deny msbroken
      request_header_access Accept-Encoding deny msbroken


La razón de la diferencia entre versiones es que la directiva header_access de la versión 2.6.X se reemplazó por las directivas reply_header_access y request_header_access (ver http://wiki.squid-cache.org/Squid-3.0.PRE4-ReleaseNotes) en las versiones 3.X.

Tomen en cuenta que para poder utilizar estas directivas, no se debe configurar la compilación del Squid con la opción --disable-http-violations, ya que sino, dichas directivas no estarán disponibles para ser configuradas e intentar agregarlas a la configuración de Squid generará errores.

Happy hacking!

sábado, 10 de mayo de 2008

Courier-authlib ya no soporta authvchkpw(!)

Houston, ¡tenemos un problema!

Courier-Authlib es una librería de autenticación perteneciente al servidor de correo Courier-MTA, del cual utilizo algunos módulos para poder integrar IMAP en mi implementación de QMail.

Lamentablemente, la última versión de esta librería (0.60.4) ya no soporta authvchkpw, que es el módulo de autenticación que permite a dicha librería autenticar usuarios de VPopMail.

Por suerte, al tratarse de Open Source, una solución está en camino, pero por ahora quienes implementen Courier-IMAP en sus nuevos servidores de correo basados en QMail y VPopMail, van a tener que seguir usando versiones de Courier-Authlib anteriores a 0.60.4.

Be careful!

UPDATE: Aparentemente, todo el mundo se volcó de lleno a resolver el problema cambiándose de Courier-IMAP a Dovecot, el cual es muy seguro y tiene soporte de VPopMail incluído. Obviamente, ya estoy en eso yo también :-)

Goodbye, Courier-IMAP... it was nice while it lasted!
:wq

SFTP y chroot(): Al fin una forma fácil con OpenSSH

Las últimas versiones de OpenSSH (5.0/5.0p1 actualmente) liberada hace poco, posée la capacidad de permitir configurar jaulas selladas para los usuarios a través de una nueva función de chroot() incorporada.

Normalmente, configurar una jaula "chrooted" es un trabajo tedioso y bastante complejo, y aún lo es más cuando tenemos que configurar acceso SSH hacia dicha jaula. Por otro lado, dependiendo de las herramientas y funciones que pongamos a disposición de los usuarios dentro de la jaula, la misma puede ser vulnerada de diversas formas. Todos saben que dejando un compilador C y permitiendo ejecutar chroot() dentro de la jaula (solo root puede hacerlo, pero si en la jaula dejamos usuarios con acceso shell, y dejamos servicios o ejecutables vulnerables y que permitan escalado de privilegios, seguramente la jaula va a ser vulnerada. También puede serlo si dejamos comandos SETUID accesibles), se puede escapar fácilmente de la misma casi sin esfuerzo.

La idea detrás de esta capacidad de OpenSSH es poder limitar el acceso de usuarios a descargar archivos desde una parte del disco del servidor anfitrión, evitando que puedan navegar por cualquier lado cuando usando SFTP.

Hasta hace relativamente poco tiempo, no era posible dar acceso SFTP a través de OpenSSH sin dar acceso shell. Esto significa que cuando creábamos una cuenta para un usuario que solo debía acceder a un directorio para subir o bajar archivos, le estábamos dando también acceso shell, lo cual es una bomba de tiempo. Con el servidor interno de SFTP de OpenSSH de la versión 4.8 (se puede declarar el uso de este servidor en el sshd_config con la directiva Subsystem internal-sftp) se puede resolver ese dilema.

Para configurar el acceso SFTP chrooted con OpenSSH entonces, se crea un directorio en el servidor, y se le asignan privilegios de solo lectura:

root@server:~ # mkdir /var/jaula
root@server:~ # chmod a=rx /var/jaula
root@server:~ # ls -la /var/jaula
total 8
dr-xr-xr-x 2 root root 4096 May 10 06:39 .
drwxr-xr-x 4 root root 4096 May 10 06:39 ..

Luego se crea un grupo de usuarios que tendrá acceso de solo lectura a dicho directorio:

root@server:~ # groupadd sftponly

Después se crean usuarios dentro de este grupo, los cuales no deberán tener shell asignado:

root@server:~ # useradd -g sftponly -G sftponly -s /bin/false usuario1
root@server:~ # passwd usuario1
Changing password for usuario1.
New Password:
Reenter New Password:
Password changed.

Y por último, editamos la configuración del OpenSSH (en la mayoría de los linux es en /etc/ssh/sshd_config) para que enjaule a los usuarios que pertenecen al grupo sftponly en el directorio definido anteriormente:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /var/jaula

Una vez hecho esto, recargamos la configuración del OpenSSH y ¡voilá!

Cuando un usuario perteneciente al grupo sftponly se loguee utilizando su cliente sftp, no podrá salir del directorio /var/jaula, así que podremos darle acceso a descargar archivos en forma segura sin que sus datos viajen en texto plano por la red de redes.

No es necesario cargar ningún archivo o subdirectorio especial en /var/jaula, lo cual rivaliza con una jaula chrooted tradicional.

Lamentablemente, esta configuración no sirve para ser utilizada con scp, así que solo podremos contentarnos con dar acceso SFTP, pero ya esto solo es mucho más fácil de hacer que antes.

¡Disfrútenlo! :-)

EOF

jueves, 8 de mayo de 2008

XEN: Peripecias virtuales

Y finalmente me puse a probar la virtualización. Sé que llego tarde, pero como un potencial cliente nos pidió un proyecto donde el anterior asesor decidió (por quien sabe qué motivo en realidad) crear una infraestructura virtualizada (9 servidores virtuales repartidos en 2 equipos físicos), tuve que poner manos a la obra y actualizarme un poco...

Ya supongo que todos saben qué es "virtualizar", pero para los que no, la idea es tomar un equipo y particionar los recursos físicos del mismo en forma virtual, creando varias instancias de máquinas virtuales que se comportan como si fueran equipos físicos, pero que ocupan el mismo espacio. Dentro de cada instancia, se puede ejecutar un sistema operativo completo e independiente del sistema base que actúa como anfitrión. Los recursos pueden entonces administrarse de forma tal de que sea posible asignar la capacidad ociosa de una de las instancias a otra que la requiera, en forma dinámica y transparente. El concepto no es nuevo, pero ha evolucionado mucho, en parte debido al hecho de que los fabricantes de procesadores han diseñado tecnologías que hacen que se pueda ejecutar la virtualización con niveles de performance nunca antes alcanzados.

De entre todas las posibilidades existentes para virtualizar (VMWare, VirtualBox, KVM, XEN, etc.), decidí usar XEN, que es el que me parece más apropiado para el caso por ser flexible, relativamente simple y facil de usar. Además, con hardware apropiado es múy rápido y además, por si fuera poco, es Open Source (que quede claro que no es el único en la lista).

Como contrapartida, para usar XEN es necesario tener un kernel compilado especialmente para poder ejecutarlo, aunque eso no es un problema dado que todas las distros medianamente decentes (y algunas no tan decentes) tienen kernels de stock ya preparados para ejecutar XEN.

Y bueno, como no tenía una superpoderosa máquina a mano, tuve que utilizar un viejo Pentium III de 500 Mhz, con 256 Mb de RAM y un disco de 8 Gb. (¿qué es ese ruido?... ¿escucho acaso unas risas de fondo?... ¿cómo que nadie usa ya esos equipos para investigación en este milenio?...) Como software base de prueba, decidí usar el OpenSuSE 10.2. (¿más risas?... hmmm...)

Y bueno... ahí comienza la peripecia.

Antes que nada, hay que aclarar que no es necesario tener una Cray para intentar la virtualización. Estaremos obviamente limitados por el hardware que tenemos, pero eso no significa que no se pueda hacer o que no sea usable. Para poder virtualizar en forma correcta con XEN, necesitamos un equipo que soporte IVT (Intel Virtual Technology, solo presente en los últimos procesadores de Intel, of course) o AMD-V (Advanced Micro Devices Virtualization, solo presente en los últimos procesadores AMD 64 bits, of course too)... y la última vez que miré, el Pentium III no tiene ninguna de esas dos tecnologías disponibles.

Bueno, eso no impide que podamos virtualizar de todas maneras, aunque con algunas limitaciones, a saber:

1) No se puede virtualizar realmente, sino "paravirtualizar", lo cual significa que solo podremos instalar en la máquina virtual resultante el mismo sistema operativo que tenemos en el sistema host (puede ser otra distribución, pero no puede ser otro "tipo" de sistema operativo).
2) No tendremos emulación completa del hardware en la máquina virtual, lo cual puede representar un problema a la hora de administrar recursos, aunque no es realmente tan grave.

Como solo esas dos cuestiones quedaron como secuelas, me dispuse a instalar mi "matrioska", solo para empaparme un poco en el tema, y de paso probar que se podía hacer realmente. Para mejorar la situación, la instalación del XEN la hice desde mi casa en un equipo a 25 kilómetros de donde estaba, conectado a un VNC a través de un tunel SSH, ejecutándose en el servidor host (XEN y la virtualización requieren de interfaces gráficas, así que no se puede jugar sin X11), así que no podía hacer mucho si explotaba. Es lo que se dice un "juego con handycap" :-)

Instalé un OpenSuSE 10.2 base en el equipo que mencioné arriba y empecé a prepararlo para que fuera el host servidor (en XEN también llamado "Dom0"). Leí algo de documentación e intenté hacer unas pruebas. Como toda cosa nueva, tardé en entender cómo funcionaba y como debía ser montada, aunque después de varias pruebas infructuosas con distintas variantes, decidí dejar de perder tiempo y pedir ayuda al amistoso módulo de gestión de virtualización de YaST2 (que si bien facilita la configuración, no permite gran flexibilidad hasta tener lista la máquina virtual).

El YaST2 me dió información interesante referente a la falta de memoria para el primer host virtual, lo cual no me sorprendió en lo más mínimo (OpenSuSE 10.2 apenas se instala en 128 Mb. de RAM, y solo si se le dá algo de swap para entretenerse), así que habiendo aumentado la memoria del equipo a 384 Mb (toda una hazaña, dado que recursos como DIMMs de memoria ECC con paridad para viejas máquinas IBM Netfinity 3000 no son precisamente abundantes en estas épocas), me decidí a volver a intentar.

Una vez que arrancó la máquina virtual (luego de explicarle al YaST como era que la quería configurada, definiendo 150 Mb. de RAM y una imagen de disco de 2GB), intenté iniciar la instalación. El linuxrd virtualizado (primera etapa de la instalación) se quejó de falta de memoria de nuevo y me pidió algo de swap... y como el YaST2 solo crea la imagen de disco sin asignar particiones (cuidado, crea una imagen de disco en un archivo, no una imagen de una partición destino) ni nada que se le parezca, además de no poder acceder a una consola para poder manejar el particionamiento (talvés de burro, puesto que seguramente alguna forma debía haber ya que recuerdo haberlo hecho antes en máquinas "no virtuales", pero que para este caso no encontré manera), no tenía de donde sacar espacio de disco para el swap que el maldito engendro me pedía.

Básicamente, fuí vencido por la paradoja del huevo y la gallina (necesito swap para instalar el sistema operativo, pero como no tengo particion de swap porque no tengo instalado el sistema operativo todavía, no tengo de donde darle el swap...).

Un intento después, modificando la memoria asignada a la máquina virtual tampoco fué satisfactorio, así que decidí explorar mis opciones. Lo único que encontré de interés, fué que podía intentar cargar en la VM el CD de rescate... lo cual podría serme útil.

Y así fué. Cargué el CD de rescate y pude bootear dentro de la VM sin problemas. Y lo que hice fué simplícimo: cree las particiones necesarias dentro de la imagen de disco de la VM, una para el / y otra para el swap. Formatée la particion de swap y la probé para asegurarme de que funcionaba. Una vez hecho esto, volví a bootear la VM para arrancar la instalación, y resulta ser que AHORA SÍ TENÍA de donde sacar swap :-), así que continué la instalación hasta tener una máquina virtual con un OpenSuSE 10.2 adentro de otro, el cual a su vez corría en una máquina de hace casi 10 años atrás... ¡Victoria!

Y bueno, pude probar la virtualización. Manejé el host Dom0 y modifiqué la configuración para reasignar dinámicamente recursos, agregué otro disco al servidor virtual (algo entretenido, dado que hay que crear un archivo del tamaño deseado (con dd se hace rápidamente), formatearlo con el FS que se desée, declararlo en la máquina virtual y montarlo... ¡todo un relajo!) y hasta pude jugar a reventar la máquina virtual por gusto a ver si volvía a levantar. ¡No me había divertido tanto desde que instalé mi primer Linux from Scratch!

¿Qué me queda de todo esto? La verdad que algo de desconcierto... La virtualización parece algo interesante para algunos casos, pero no creo que sea la panacea absoluta. Con tecnologías como blade servers disponible y los precios del hardware en caída libre, lo único que puede obligar a un implementador a virtualizar es el tema del aprovechamiento del espacio y la energía... y ahí me parece que es donde más puede "pegar" este asunto. El consumo energético de un data center es todo menos despreciable, así que ya puedo ver aparecer varios VISP (Virtual Internet Service Provider) por ahí con un solo servidor, un router y un enlace a Internet, sirviendo a varios clientes en un espacio reducido y un consumo mínimo de energía eléctrica... lo cual significa menos costos operativos, felices facturas de U.T.E. y buenas ondas de parte de organizaciones ambientalistas (de las de verdad, no como la de Gualeguaychú).

En definitiva, virtualizar es ecológico y divertido. ¡No dejen de probarlo!

:wq

miércoles, 7 de mayo de 2008

Síndrome de Sumo: No sé lo que quiero, pero lo quiero ya...

Casi puedo escuchar al pelado Luca Prodan gritando como desesperado cada vez que un cliente encarga un nuevo desarrollo.

La programación, como tantas otras ramas de la informática, es una ciencia compleja y extensa. Si bien gran parte de la ingeniería de software es una ciencia inexacta dada la cantidad de factores implicados, la programación ya es otro tema, dado que implementar una solución ya analizada es relativamente fácil, si uno conoce los lenguajes necesarios y la metodología de trabajo apropiada.

Para el cliente, esto es "bullshit", como dicen los yankees. El cliente quiere que todo le funcione, y no solo no tiene idea de cómo se hará, sino que tampoco quiere tener idea. Lo más cerca que el cliente estará del código de su sistema, será cuando le aparezca una pantalla de error que contenga cualquier cadena de texto con por lo menos cuatro o cinco letras y o números que no podrá reconocer como una palabra en su propio idioma, y eso implica que tampoco será capaz de recordar siquiera cuales eran esas letras cuando el programador le pregunte "¿Que decía la pantallita con el error?"...

Un cliente seguro se sentará frente a nosotros con ideas talvés brillantes para su sistema de gestión, y hasta demostrará que conoce a la perfección su negocio al proponer herramientas que hagan las cosas más interesantes e increíbles que se hayan visto, pero lo que sí es seguro, es que no tiene idea de la dificultad que representa en realidad el implementar esas ideas, y además, probablemente haya mencionado algún concepto de forma vaga (a pesar de estar seguro de que está clarísimo para él mismo) y crea que en realidad sabe qué es lo que necesita, aunque nosotros nos demos cuenta de que en verdad no tiene la más remota idea de qué es.

Muchos clientes no tendrán palabras para expresar lo que desean y tratarán de utilizar analogías del mundo real, lo cual no es una mala táctica, siempre y cuando dicha analogía sea aplicable y su resultado sea consistente en cuanto al efecto que se desea lograr. Este tipo de situaciones pueden incluso ser útiles como termómetro para medir la temperatura del cliente durante la fase de desarrollo, si es que nos tardamos más de la cuenta en proveerle una respuesta satisfactoria. Si en lugar de usar hábiles metáforas utiliza eufemismos, talvés sea un buen momento para tratar de cambiar el rumbo de la conversación.

La realidad es que los clientes no siempre tienen la razón. Ese equívoco del marketing y de los negocios no vá muy bien con la informática. Es una verdad tan absoluta como que no se necesita ser un excelente técnico para ganar mucho dinero en la informática. Solo hace falta saber venderle a un cliente algo que supuestamente le resolverá todos sus problemas.

Y ahí parece residir el meollo de la cuestión. El cliente no sabe qué es lo que quiere en realidad, por lo menos no en términos técnicos claros y bien definidos, pero lo que sí quiere es algo que resuelva sus problemas. No importa si basamos nuestra estrategia en conceptos como alta calidad, vanguardia tecnológica, diseño de última generación o técnicas estandarizadas, el resultado debe solucionar los problemas del cliente, y eso es muy dificil de lograr. A veces pueden pasar meses antes de poder llegar a encontrar los problemas reales que el cliente tiene, y muchas veces, cuando lo encontramos nos damos cuenta de que derivan siempre del factor humano, y no de las computadoras, ni de la infraestructura informática que cliente posée.

La resistencia al cambio y a lo nuevo está marcado a fuego en el ADN de los usuarios. Lucharán con eso hasta el cansancio y tratarán de boicotear cualquier intento de que la nueva implementación tenga éxito. No importa si es mejor, si es más rápido o si es más nuevo, es diferente, y solo por eso, se merece el odio acérrimo de quienes deberían utilizarlo. En las multinacionales, el usuario tiene que adaptarse, pero en las pequeñas empresas, suele ser al revés, y de hecho, los usuarios terminan teniendo más poder que el dueño, que es quien paga los sueldos y también intenta mejorar la gestión de su empresa implementando el nuevo sistema en cuestión.

Pero esto se vá del tema. La realidad es que el gerente/director/encargado o quien sea que adquiere el sistema, no sabe cómo funciona ni sabe que es exactamente lo que quiere, pero una cosa es clara, quiere una solución definitiva e inmediata a sus problemas, aunque no sepa expresarla de forma que un técnico capaz de implementarla lo entienda.

Si tan solo yo también supiera cual es esa solución, ya mismo me pondría a producirla...

CTRL+S

domingo, 4 de mayo de 2008

Y la revolución finalmente llegó a Cuba...

Hace ya un mes, Raul Castro levantó las restricciones que impedían a los cubanos adquirir unidades de DVD, comprar legalmente teléfonos celulares, alquilar automóviles, quedarse en hoteles reservados para turistas, iniciar pequeñas empresas, plantar en suelos improductivos pertenecientes al gobierno y hasta comprar computadoras.

Incluso parece que se van a empezar conversaciones con U.S.A. para que finalmente se levante el bloqueo económico y político. Quien sabe... ¿Se imaginan Guantánamo convertida en la nueva Embajada Estadounidense en Cuba?...

Las restricciones tenían como objetivo evitar la aparición de "nuevas desigualdades", algo que en un sistema totalitario e igualitario es malo, sobre todo por lo dificil de controlar que se vuelven los que empiezan a prosperar y darse cuenta de que el mundo es diferente a lo que están acostumbrados a ver en su idílica y utópica isla natal.

Los problemas actuales no van a ser no poder comprar cosas porque es ilegal, sino no poder comprarlas porque es caro. En un país donde el sueldo promedio no supera los U$S 20 mensuales, adquirir por ejemplo computadoras nuevas a U$S 800 es un verdadero desafío. Esperemos que con la nueva libertad de iniciar pequeñas empresas, este problema se resuelva solo.

El acceso a Internet también es un problema, dado que aún sigue restringido. La excusa que dá el gobierno sobre tal restricción es que no hay suficiente ancho de banda como para permitir a toda la población acceder. Ya Chavez está trabajando para tirar un cable hasta la isla para darles el preciado ancho de banda que hoy los cubanos no tienen, aunque no está claro si esa mejora va a realmente resultar en un levantamiento de las restricciones de acceso.

Parece que el igualitarismo por el que tanto se luchó en los sesentas (el cual se logró en base al "redondeo para abajo") y del que tanto se jactan los que siguen viendo a Cuba como el "modelo de país socialista y un ejemplo a seguir" va a desaparecer finalmente, junto con todos los sueños de libertad, independencia, dignidad e igualdad social que hasta hace poco "disfrutaban" los cubanos.

Parece entonces que ahora la paradisíaca isla caribeña se va a llenar de consumistas y capitalistas, algo que Fidel no quería que pasara. Si un cubano se las dá de empresario y resulta que tiene éxito, sus ingresos van a aumentar. Va a poder comprar cosas que hoy no tiene y va a poder consumir cosas que antes no podía consumir. Va a crecer la demanda de objetos que estaba prohibido comerciar y va a renacer la importación, naturalmente que desde países que no tienen acuerdos especiales con los Estados Unidos, of course. Seguramente, como muchos nuevos ricos que aparecen, estos empresarios cubanos no van a saber qué hacer con tanto dinero y se van a empezar a drogar, a emborrachar, a tener orgías desenfrenadas... Bueno, no era tan malo esto del igualitarismo, ¿no?...

Y pensar que aquel triunfo de Fidel el 1º de Enero de 1959 fué el que desató la gran ola de intentos revolucionarios en toda latinoamérica (en Uruguay, llevada a cabo por el MLN), los cuales finalmente no tuvieron el éxito esperado. Esa historia todos la conocemos, a pesar de que muchas veces se insiste en cambiar de posición el huevo y la gallina para que la paradoja resulte menos negativa para los que hoy son considerados como heroes por las mayorías olvidadizas.

Nuestros "revolucionarios" son gobierno hoy, votados democráticamente, aunque hay que ver que las diferencias eliminadas por Castro durante la Revolución Cubana aquí siguen en pié. Son las cosas raras que nadie entiende, como en una de las últimas canciones del Cuarteto de Nos, pero al revés, el cambio que no cambió nada. ¡Menos mal!

¿Estaría yo viviendo de lo que vivo si la historia en Uruguay hubiera sido otra?... Supongo que no. Menos mal que la "revolución" acá tuvo tiempo de madurar (o talvés diluírse), así yo todavía puedo usar mi computadora para escribir estas idioteces en Internet.

Por lo pronto, me alegro de que los cubanos ahora tengan algunas libertades de las que gozamos los otros latinoamericanos, aunque lamento que el igualitarismo social no haya funcionado como Marx hubiera querido. La idea no era del todo mala, solo que es imposible de aplicar en el mundo real sin destruir lo que somos como seres humanos en el proceso. Las pruebas están a la vista... para todo el que quiera mirar y sobre todo, ver.

¡Requiescat in pace, revolución!

 
Gustavo Castro

Crea tu insignia