El equipo técnico de The Cocktail desarrolla y administra varias de las aplicaciones Ruby on Rails con más tráfico de España.
Trabajamos en un entorno joven y distendido, con un alto nivel de profesionalidad, donde se fomenta la responsabilidad individual.

Si eres la persona indicada para este equipo seguro que te encanta trabajar con todo esto:

• Virtualización y Cloud Computing
• Automatización e integración de sistemas
• Fine tunning (nginx, mysql, TCP/IP,…)
• Backups
• Alta disponibilidad
• Seguridad de servidores
• Scripting
• Monitorización
• Diagnósticos e interpretación de gráficas de sistemas

Requisitos:

• Mínimo 3 años de experiencia con sistemas web basados en Linux
• Experiencia con sistemas webs de alto rendimiento y balanceo de carga
• Experiencia con servidores web Apache y Nginx
• Conocimientos avanzados de TCP/IP y concretamente de HTTP
• Experiencia con algún sistema de configuración de servidores (Chef, Puppet, cfengine, …)
• Experiencia con alguna tecnología de virtualización (Xen, KVM, …)
• Experiencia con MySQL Server
• Experiencia en el trato con proveedores de infraestructura
• Experiencia con servicios comunes de internet como DNS, SMTP, …
• Experiencia con sistemas de control de versiones (SVN, GIT, …)
• Facilidad para desarrollar scripts (Bash, Ruby, Python, Perl, …)
• Indispensable tener buenas cualidades para el trabajo en equipo
• Buenas cualidades para resolución de problemas
• Proactividad, carácter y decisión.
• Interés por el Open Source
• Buen nivel de inglés leído y escrito

Bonus:

• Experiencia administrando sistemas Ruby on Rails

Si te gusta lo que has leído no dudes en mandarnos tu CV a:
jobs ARROBA the-cocktail PUNTO com

Si no nos conoces y quieres saber un poco más, puedes hacerlo en http://the-cocktail.com/

El equipo técnico de The Cocktail desarrolla y administra varias de las aplicaciones Ruby on Rails con más tráfico de España.
Trabajamos en un entorno joven y distendido, con un alto nivel de profesionalidad, donde se fomenta la responsabilidad individual.

Si eres la persona indicada para este equipo seguro que te encanta trabajar con todo esto:

• Virtualización y Cloud Computing
• Automatización e integración de sistemas
• Fine tunning (nginx, mysql, TCP/IP,…)
• Backups
• Alta disponibilidad
• Seguridad de servidores
• Scripting
• Monitorización
• Diagnósticos e interpretación de gráficas de sistemas

Requisitos:

• Que te sientas agusto con una shell Linux delante. Va a ser tu medio de trabajo la mayor parte del tiempo. Debería de gustarte y saber desenvolverte bien con ella y con las herramientas necesarias para la administración Linux del día a día.
• Conocimientos básico de Linux internals. Casi el 100% de nuestros servidores son Linux, principalmente Debian. Debes de saber al menos lo básico del funcionamiento de un servidor Linux.
• Conocimientos básicos de TCP/IP y concretamente del protocolo HTTP. Aquí, al final, tratamos básicamente con aplicaciones web. Es necesario saber, al menos, lo básico sobre el protocolo y sobre servidores web.
• Scripting. No importa si estás acostumbrado a hacer scripts de Bash, Ruby, Python, Perl o lo que sea. La cuestión es que tengas soltura manejando scripts.
• Interés por el open source. Casi todas las herramientas que usamos para montar nuestros servidores son open source. Nos gusta el open source y también solemos colaborar de varias formas.
• Facilidad con el inglés. Como mínimo has de saber leer y escribir en inglés.
• Team player. Somos un equipo. Ya de paso, como también desarrollamos en equipo es bueno conocer algún sistema de control de versiones (SVN, Git,..)
• Proactividad, carácter y decisión.

Bonus:

• Conocer Ruby on Rails. Si tienes algo de experiencia con este framework, ya sea a nivel de administración o de desarrollo es un gran extra point.
• Experiencia con alguna herramienta de automatización de servidores (chef, puppet, cfengine,…)
• Experiencia con sistemas web distribuidos

Si te gusta lo que has leído no dudes en mandarnos tu CV a:
andrea.hidalgo ARROBA the-cocktail PUNTO com

o a través de nuestra página:
http://the-cocktail.com/es/jobs/administrador-de-sistemas-junior-21

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

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

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.

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

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.

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.

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 (ya no existe el site).

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 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.

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.