Un maño entre gaúchos

The Cocktail es una consultora de internet, enfocada en la experiencia de usuario y diseño de producto, especialista en traducir objetivos de negocio en productos digitales innovadores, usables, atractivos y rentables.

Queremos incorporar a nuestro equipo de trabajo un Administrador de Sistemas Junior con experiencia en manejo de sistemas Linux, redes TCP/IP , y especialmente interés y compromiso por el open source. Realizará las siguientes tareas:

• Administración de servidores *nix – Particularmente Debian.
• Instalación y despliegue de nuevos servidores en producción y en desarrollo. Compilación de software.
• Monitorización y backups.
• Configuración de routers, switches, firewalls y balanceadores de carga.
• Mantenimiento de la red local, accesos remotos VPN y políticas de acceso a recursos.

Los requisitos mínimos son:

• Experiencia administrando sistemas Linux.
• Experiencia con Debian – GNU/Linux, MySQL, Apache.
• Conocimientos sobre redes TCP/IP.
• Interés y compromiso por el open source.
• Facilidad para trabajar en equipo. Auto-disciplina y atención a los detalles. Iniciativa y proactividad.
• Conocimiento e interés por Ruby On Rails y lenguajes de programación dinámicos.
• Experiencia con varias de las siguientes tecnologías: Apache, MySQL, Bash, Ruby, Samba, Postfix, Nagios, Xen, Iptables, Subversion, Git, Rsync, LDAP

Y por supuesto el mayor de los requisitos es que crea que es capaz de desempeñar este trabajo, teniendo en cuenta las responsabilidades arriba mencionadas.

El trabajo es de carácter presencial en las oficinas de Madrid en horario de jornada partida.

Si estás interesado, envía tu CV a: andrea.hidalgo ARROBA the-cocktail PUNTO com

En The Cocktail Experience, empresa dedicada a la consultoría web, estamos interesados en contratar becarios para el área de sistemas. Gente con muchas ganas de trabajar y aprender.

El perfil que estamos buscando es el siguiente:

• Experiencia con sistemas GNU/Linux.
• Conocimientos básicos de scripting
• Conocimientos básicos de servidores web y servidores de bases de datos (por ejemplo MySQL, Apache….)
• Posibilidad de realizar convenio de prácticas

Si estás interesado, envía tu CV a: andrea.hidalgo ARROBA the-cocktail PUNTO com

Pongamos la clásica funcionalidad web en la que un usuario lee una noticia y tiene el típico enlace “Mandar la noticia a un amigo” de forma que dicho amigo va a recibir un mail enviado por un servicio de noticias, pero va a saber que quien se lo ha querido enviar es su colega. Lo que necesito entonces es poder mandar emails desde rails que cumplan las siguientes condiciones:

• La dirección de origen que aparezca en el email, es decir la cabecera From ha de ser una genérica asociada al servicio, como por ejemplo noreply@example.com.
• El Reply-To ha de ser otra dirección, pongamos la del usuario que ha querido enviar el mail a su amigo.
• Quiero estar seguro de que cada email que se envía desde este servicio se envía correctamente y si no lo hace, al menos conocer la razón de porque no ha sido así. Por lo tanto necesito que si falla el envío, el servidor SMTP donde ha fallado sea capaz de devolverme una respuesta para que mi sistema pueda ir parseando emails de respuesta de envios fallidos. Eso sí lo que no quiero es que estas respuestas vayan a parar al buzón del sistema del usuario con el que está arrancada la aplicación web, ya que se me pueden mezclar en ese buzón un montón de cosas y no solo las respuestas de esos envíos concretos de correo. Por lo tanto necesito poder indicarle a rails esa dirección de respuesta de errores. La cabecera que se encarga de proporcionarle está información a los servidores de correo es la de Return-Path. Pongamos que está dirección es fail@example.com

Así que el código de ejemplo de un envío de este tipo sería el siguiente:
En el config/environments/production.rb:

config.action_mailer.delivery_method = :sendmail

y en la clase del ActionMailer::Base:

class MessageMailer < ActionMailer::Base
  def message_email(email_data)
    recipients  email_data[:recipient]
    from        "noreply@example.com"
    headers     "Return-Path" => "fail@example.com"
    reply_to    email_data[:sender_email]
    subject     email_data[:subject]
    body        :body => email_data[:body]
  end
end

Si se tienen en la aplicación muchos métodos de envío de correos diferentes, para no tener que indicar siempre el header de Reply-To, se puede poner a mano en el environment como parametro de sendmail:

  config.action_mailer.delivery_method = :sendmail
  config.action_mailer.sendmail_settings = {
    :location => '/usr/sbin/sendmail',
    :arguments => '-i -t -f fail@example.com'
  }

Ya están disponibles para descargar los videos de las charlas de la Conferencia Rails de este año.
Se pueden bajar desde aquí:
http://isabel.dit.upm.es/component/option,com_docman/task,cat_view/gid,128/Itemid,74/

Están divididos por día (fueron 2 días) y por la sala de cada charla.

Concretamente la que charla que dimos Daniel Blanco, Fernando Blat y yo se puede descargar desde:
http://isabel.dit.upm.es/component/option,com_docman/task,doc_download/gid,843/Itemid,74/

En The Cocktail Experience, empresa dedicada a la consultoría web, estamos interesados en contratar becarios para el área de sistemas. Gente con muchas ganas de trabajar y aprender.

El perfil que estamos buscando es el siguiente:

• Experiencia con sistemas GNU/Linux, especialmente Debian
• Conocimientos básicos de scripting (en algún interprete tipo bash, ruby, perl, python, ….)
• Conocimientos básicos de servidores web y servidores de bases de datos (por ejemplo MySQL, Apache….)
• Interés y compromiso por el software libre
• Estudios relacionados (Informática, Telecomunicaciones….)

Si estás interesado, envía tu CV a: andrea.hidalgo ARROBA the-cocktail PUNTO com

Mientras intentaba implementar el soporte de vacaciones con gnarwl y postfix en una aplicación Rails de gestión de usuarios en LDAP me he encontrado con una situación que no me esperaba.

Primero he de comentar por encima en que consiste gnarwl. Se trata de un script al que se le pasa por la entrada standard un correo en texto plano, con su remitente y destinatario. Después el script busca el destinatario del correo en el árbol LDAP donde está guardada toda su información y comprueba si el atributo vacationActive está activado. Si lo está, le envía al remitente del correo un mail con el texto indicado en el atributo vacationInfo.

Al grano. En el modelo del usuario, gracias a ActiveLDAP, tenía indicado que uno de los objectClass que definen a todo usuario en esta aplicación en concreto es el objectClass Vacation.

ldap_mapping :dn_attribute => 'uid', :prefix => 'ou=Usuarios',
             :classes => ['top', 'person', 'qmailUser', 'inetOrgPerson', 'Vacation']

Como no quería sobrecargar el formulario de creación de usuario con un campo/checkbox “Vacaciones”, he metido un callback before_create en el modelo del usuario, de la siguiente forma:

before_create :set_vacation

def set_vacation
  self.vacationActive = false
end

De esta forma, la propia definición de objectClass Vacation del usuario se iba a encargar de asignarle ese objectClass y el before_create se iba a encargar de crear el atributo vacationActive y de ponerlo a false.

Cual ha sido mi sorpresa al ir a crear un usuario nuevo y recibir un mensaje típico de validación que no esperaba:

1 error prohibited this user from being saved

There were problems with the following fields:

    * vacationActive is required attribute by objectClass 'Vacation'

Al principio me ha despistado un poco, pero al final he visto cual era el problema.
Obviamente sabía que cuando una entrada en LDAP tiene el objectClass Vacation, se exige que como mínimo tenga también el atributo vacationActive definido. Lo que no sabía era que ActiveLDAP genera las validaciones en tiempo real consultando primero los objectClass de esa entrada y generandose su lista con los atributos de los que dependen esos objectClass.

Por lo tanto el before_create añadido anteriormente no sirve, ya que es necesario crear ese atributo antes de la validación. Lo correcto sería:

before_validation_on_create :set_vacation

Además de este detalle se había juntado otro problema que hacía que me costase un poco con la solución. Este problema es que ActiveLDAP no acepta una definición de un booleano de la forma clásica:

vacationActive = false

ActiveLDAP acepta valores booleanos de la siguiente en forma de cadenas de la forma “TRUE” o “FALSE”.
Mirando un poco las tripas de ActiveLDAP he visto que tiene una función para normalizar los valores en el caso de que se le pase true o false. No obstante parece que no aplica esa función a nivel interno, por lo que resulta totalmente inutil en caso de desconocimiento del programador, como en este caso me ha pasado a mi.

Por lo tanto, el callback correcto en esta situación no sería el que he indicado anteriormente, sino que sería este:

before_validation_on_create :set_vacation

def set_vacation
  self.vacationActive = "FALSE"
end

Hoy me han llegado al correo varias notificaciones de excepciones del site del Centenario do Inter. Estos errores se han generado por no indicar el parámetro page del will_paginate, de la siguiente forma:

http://localhost:3000/fotos?page=

El código de will_paginate no contempla eso, por lo que tenía dos opciones. Una poner un filtro en mis controladores para asegurarme de que hubiese algún número de pagina. Esa opción es muy poco DRY, así que he hecho el siguiente cambio en el collection.rb del plugin de will_paginate:

Index: vendor/plugins/will_paginate/lib/will_paginate/collection.rb
===================================================================
--- vendor/plugins/will_paginate/lib/will_paginate/collection.rb        (revisión: 65)
+++ vendor/plugins/will_paginate/lib/will_paginate/collection.rb        (copia de trabajo)
@@ -16,7 +16,7 @@
     # populating the collection using the +replace+ method.
     #
     def initialize(page, per_page, total = nil)
-      @current_page = page.to_i
+      @current_page = !page.blank? && page != 0 && page.to_i != 0 ? page.to_i : 1
       @per_page     = per_page.to_i

       self.total_entries = total if total

La verdad es que no se, ni si eso está contemplado en versiones posteriores a la que estoy usando, ni si es una buena solución, pero a mi me ha servido para resolver el problema rápidamente y sin tirar apenas código.
Con ese cambio, además de asegurarme de que la aplicación no de 500 al no poner ningún número en el parámetro page, también me aseguro de que no se rompa por poner un parámetro que no sea un número, como por ejemplo:

http://localhost:3000/fotos?page=foobar

Pos eso.

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.

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.