Un maño entre gaúchos

Estos días tenía la necesidad de hacer que nginx mandase sus logs al syslog local.
Nginx no tiene soporte nativo para usar syslog. Puede escribir los logs o en fichero o mandarlos a un pipe.
Estuve bsucando y encontré un parche de la versión 0.6.31 que resuelve el problema. Aquí habla también un poco del parche.

A pesar de que en ese último link explica por encima como hacerlo, lo voy a contar yo también.

• Bajamos la versión 0.6.31 de nginx en http://sysoev.ru/nginx/nginx-0.6.31.tar.gz. Según el comentario de Marlon (el creador del parche) debería funcionar también con las versiones 0.6.30 y 0.6.29, y mirando los changelogs pienso que tambíen debería funcionar en la última que es la 0.6.32. Si alguien lo prueba que me lo diga.
• Descomprimimos:
  # cd /usr/src/
# tar xvzf nginx-0.6.31.tar.gz
• Bajamos el parche:
  # wget http://bugs.gentoo.org/attachment.cgi?id=153345 -O nginx_syslog.patch
• Parcheamos:
  # patch -p0 < nginx_syslog.patch
• Compilamos e instalamos nginx:
  # cd nginx-0.6.31
# ./configure –with-syslog
# make
# make install

En mi caso antes de compilar he tenido que hacer un cambio en una linea de los fuentes del nginx. He tenido que substituir en el fichero auto/cc/gcc la siguiente linea:
CFLAGS="$CFLAGS -Werror"
por:
CFLAGS="$CFLAGS"

Esto únicamente hace que no se rompa la compilación al encontrar algun warning. En mi caso los warning que lanza la compilación se pueden ignorar tranquilamente, por lo que resulta seguro continuar con ellos.

Si todo ha ido bien deberíamos de tener funcionando nginx. Faltaría unicamente configurarlo y ponerlo en marcha. En el fichero de configuración no hace falta indicar nada para que mande correctamente los logs al syslog. Por defecto los manda a la facility daemon.

Yo lo he probado ya en servidores en producción y por el momento funciona estupendamente.

Desde aquí agradezco el esfuerzo a Marlon de Boer, que no he conseguido encontrar un blog suyo donde hacerlo.

A los que usáis ubuntu, os habrá pasado que instaláis el sistema con un usuario y una pass y un día decidís cambiar la contraseña de vuestro usuario (lo más normal del mundo). Es cuando intentáis acceder al depósito de claves o Gnome Keyring Manager que se os queda cara de WTF porque al meter vuestra contraseña del usuario, le da por no aceptarla. Eso es porque han hecho mal el depósito de claves y utiliza su contraseña a parte. Al acceder por primera vez al mismo, te pide una contraseña que normalmente es la que usas en tu usuario. Lo que ocurre esque el keyring manager guarda esta contraseña en su fichero de configuración de gconf y no comparte la contraseña de sistema del usuario. Así que para acceder, basta con acordarse de la contraseña que se puso en su momento.

Para los que no les da la gana de seguir usando una contraseña antigua para el depósito y quieren cambiarla, lo pueden hacer de la siguiente forma:

• Instalar el seahorse que es principalmente un depósito de claves GPG.
  # apt-get install seahorse
• Abres seahorse y vas a Editar -> Preferencias -> Depósito de claves. Una vez ahí pones la contraseña del depósito que será la que pusiste en un comienzo y luego le pones la nueva contraseña y listo.

Hay otra solución que sirve para no tener que ni siquiera introducir ninguna contraseña para abrir el depósito y que se abra automaticamente al iniciar la sesión. Es fácil y rápido de hacer. Se puede ver aquí.

Buscando como hacer todo esto vi un buen número de animalicos diciendo que para hacer eso había que cargarse el fichero de gconf del gnome-keyring-manager y así la siguiente vez que se fuese abrir pediría una contraseña nueva. Eso es matar moscas a cañonazos, ya que junto con la contraseña esto se carga el depósito en si, y con él todas las claves que hay guardadas. En mi opinión es un método aceptable si lo que ocurre es que no te acuerdas de la contraseña que pusiste en un comienzo para el depósito.

Así a bote pronto la mayoría de la gente posiblemente no sabrá quien era este hombre.
Si buscáis alguna foto en google os acordaréis al momento de esta persona que compartía las aventuras de MacGyver o que hacía el papel de Major Garland Briggs en Twin Peaks.

Además de aparecer en muchas películas y series de TV, algunos (más frikis) lo tendrán reciente por interpretar el papel del General S. Hammond en la serie de TV Stargate. Yo sigo esta serie desde hace varios años y la verdad es que me encanta. En mi opinión es la mejor serie de TV que he visto (y sigo viendo). Concretamente Don S. Davis interpretaba un papel que llegaba al público y al que le cogías cariño enseguida. Me parece un grandísimo actor.

Buscando un poco he desccubierto que además de sus dotes interpretativas, tenía una intensa vida familiar y tenía grandes dotes artísticas, las cuales se pueden ver en este site.

Así que como amante del cine, series y los buenos profesionales, siento mucho su perdida. No obstante ha dejado cosas suficiente como para disfrutar toda la vida.

Ayer por la noche se sustituyó en producción el site del Centenario do Inter que estaba funcionando desde Marzo.
Las características destacables de esta nueva versión son:

• Interfaz totalmente renovada. La versión anterior estaba basada en tablas y tenía muchísimas imagenes que podían ser sustituidas perfectamente por texto con estilo.
• Galería de fotos. Del mismo estilo que la sección de historias, un usuario puede mandar una foto e indicar una descripcción de la misma. Otros usuarios podrán ver las fotos y votarlas.
• Pronto habrá una sección “Quiz” en el que todo el mundo podrá participar y demostrar sus conocimientos del club.

Todos estos cambios se han realizado con la intención de acercar más el site al usuario y mejorar la interacción. También gracias a esta nueva versión resultará más facil ir incorporando nuevas funcionalidades de forma rápida y menos costosa.

Por supuesto esta versión sigue estando desarrollada en Ruby on Rails y demuestra una vez más que es una de las mejores tecnologías para el desarrollo web, independientemente del proposito o del tamaño del proyecto.

Como hasta ahora este proyecto ha sido fruto de un esfuerzo conjunto con e21, la cual sigue demostrando que es capaz de crear estrategias de marketing y publicidad adaptadas al entorno digital.

Copiado de Puro egocentrismo

Hace un tiempo me cogí un VPS (Virtual Private Server) de Slicehost.
Había oido hablar de esta empresa por medio de algunos colegas de trabajo, y tenía buenas referencias.

En un principio me pillé el 512 slice y lo he estado usando hasta ahora como servidor de producción del site del centenario del Internacional de Porto Alegre.

Hace un par de semanas decidí coger otro slice para usarlo como servidor de desarrollo con control de versiones y entorno de pruebas. En un principio elegí el slice 256. Al cabo de unos días vi que iba a terminar metiendole un poco más de caña y con el de 256 me iba a quedar corto. Así que decidí ampliarlo al de 512.
Estoy gratamente sorprendido con el resultado. A través de la web y con un par de clicks, se realizó automáticamente el cambio. Estando el servidor en caliente (es mejor asumir un downtime por si acaso), y con una barra de progreso en la web, vi como en cuestión de 10 minutos el servidor estaba funcionando perfectamente y con su memoria y disco incrementados hasta los valores del 512. En cuanto al incremento de precio, según las explicaciones de la web, realizan un prorateo de los dias que faltan hasta acabar el ciclo de facturación y te lo cargan, por lo tanto no te cobran nada de más.

Aunque como todo, hay cosas que se pueden mejorar, estoy realmente contento con el servicio ofrecido por esta empresa, tanto por la calidad técnica, precios y facilidad de uso.

Ahora es cuando tengo que aprender de ellos y hacer que los Xen de la empresa estén tan currados y automatizados como los de Slicehost. Dentro de poco…

Si lo que quieres es almacenar las contraseñas de usuarios de OpenLDAP encriptadas con el algoritmo MD5, hay que tener en cuenta tres cosas.
La primera es que muchos clientes utilizan un recurso para saber de forma automática en que algoritmo está encriptada la contraseña contra la que van a intentar autenticarse. Este recurso, es añadir el nombre del algoritmo delante de la contraseña, por ejemplo:
{MD5}OFj2IjCsPJFfMAxmQxLGPw==

Si no se le fuerza al cliente a que use un algoritmo u otro para autenticarse, mirará (si el cliente está bien implementado) si la contraseña de LDAP tiene entre llaves el nombre del algoritmo y usará en consecuencia ese algoritmo para enviar la contraseña.

Otro tema a tener en cuenta, es el tipo de encriptación MD5. Normalmente la mayoría de librerías de MD5 permiten la encriptación de una cadena en formato hexadecimal y en binario. Para OpenLDAP, no nos sirve ninguno de los dos formatos a pelo. Lo que debemos hacer para que la contraseña esté en el formato correcto en el árbol LDAP, es encriptarla en MD5 binario y codificarla después en Base64 para que sea legible. La implementación de esto en ruby, y más concretamente en un modelo de Rails sería así:

require 'digest/md5'
require 'base64'
class User < ActiveLdap::Base
  before_save :encrypt_password

  def encrypt_password
    self.userPassword = "{MD5}" + Base64.encode64(Digest::MD5.digest(self.userPassword))
  end
end

De ActiveLDAP hablaré un poco otro día.

Lo último a tener en cuenta es que el hecho de guardar contraseñas en MD5 en el árbol LDAP no quiere decir que nuestro sistema sea seguro. Sin contar con todos esos temas de desencriptación por fuerza bruta y todo eso, está el tema del envío de la contraseña por un medio no seguro. Si nuestro cliente (podría ser en este caso una web), no está en la misma máquina que el árbol LDAP, al autenticarse con el método SIMPLE, la contraseña viajará en claro por la red hasta el LDAP.
Para evitar esto tenemos dos opciones. O hacemos que las autenticaciones sean con el método SASL (con DIGEST-MD5 por ejemplo) o simplemente le damos soporte SSL/TLS al slapd, de forma que todo tipo de flujo de paquetes entre el servidor y el cliente vayan encriptados.

En The Cocktail estamos buscando nuevas mentes brillantes (con que sean un poco perturbadas es suficiente). Concretamente andamos detrás de maquetadores y programadores Ruby on Rails. No hace falta que seas un gurú, pero sí que le eches ganas.

No me voy a extender mucho. Solo puedo decir que hace poco más de 4 meses que estoy aquí y no me he arrepentido ni un poquico.

Hacemos un trabajo de calidad, para clientes de calidad. Trabajamos con las últimas tecnologías del entorno web y primamos la innovación y las ganas. Tenemos un gran equipo, agradable y también tenemos galletas de chocolate y de limón.

Así que si te mola el plan o sabes de alguien a quien le vaya a molar, ponte en contacto con nosotros.

PD.: Mejor si no tienes alergia a los perros.

El martes día 24 de Mayo se celebra el 2º Barcamp de Movilidad en la Escuela Técnica Superior de Ingenieros de Telecomunicación de la Universidad Politécnica de Madrid.

¿Por qué debería interesarme?
Pues porque quieres estar a la última sobre las tendencias en desarrollo para móviles. Quieres conocer qué cosas interesante se están haciendo sobre este tipo de plataforma. Quieres conocer el SDK del IPhone o de OpenMovilForum. Quieres saber exactamente qué es eso de Android, lo que vas a poder hacer con él en un futuro y en qué va a mejorar tu vida. Quieres participar en talleres relacionados con todas estas tecnologías.

Bueno, tampoco hace falta ir hasta allí. Ya buscaré información sobre estos temas en Google
Puedes hacerlo, pero ni google va a resolver tus dudas ni te lo va a saber explicar tan bien como los profesionales que va a haber en el BarCamp. (Aunque va por buen camino)

Tú vas? Nos vemos ahí?
Aunque me gustan este tipo de cosas más que a un tonto un lápiz, no voy a poder. Pero te vas a encontrar a alguno que otro de la Corporación.

Que lo disfrutéis