Un maño entre gaúchos

En The Cocktail buscamos un Administrador de Sistemas Senior al que le apasione su trabajo y tenga habilidades y ganas para superar los desafíos del día a día.

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/

En The Cocktail buscamos un Administrador de Sistemas Junior al que le apasione su trabajo y tenga habilidades y ganas para superar los desafíos del día a día.

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

When I started playing with chef, I rapidly came to a question. How can I do to automate the new nodes registration on chef server when creating new virtual instances?
I have a few server images. All my images have chef-client and the necessary files to do a bootstrap client setup installed.
Besides these files I have a small “init” script and a config file for this script.
The script basically run the bootstrap chef-client set up with chef-solo and restart the chef-client. If the process goes well, it removes the server validation.pem stored in /etc/chef/ and makes sure that the script is not going to run anymore by setting a config variable.

Here is the config file:

and here is the “init” script:

I believe that there are a lot of approaches, and maybe better than mine. For example, mine is not valid if you are going to use it with public AMI in amazon. Even if these AMIs have chef-client installed you must provide your server validation.key. The best solution in this case would be to make a SSH connection to the new server right after it starts and copy the validation.pem and the necessary chef configurations.

Voy a dar un curso de sistemas el viernes 16 por la tarde de 16 a 20 horas y el sábado 17 por la mañana de 10 a 14 horas. Va a ser en el aula de las oficinas de The Cocktail en la C/ Salamanca, 17, Madrid.

El curso va a cubrir todo el proceso de puesta en marcha de una máquina con entorno Ruby on Rails en producción. Esto implica los siguientes puntos:
* Instalación y configuración de Debian
* Instalación del stack de Rails
* Estrategias de Deploy
* DNS
* Securización del servidor
* Backups
* Monitorización
* Configuración del servicio de mailing

Estos puntos implican tecnologías como Debian, SSH, DNS, Ruby, Rails, rubygems, rsync, Munin, Postfix, Apache, Passenger, MySQL, Iptables, Bash scripting, IDS, …

La idea es tratar todos estos puntos en cierta profundidad aunque intentando tocar lo justo de ficheros de configuración para no hacer aburrido el curso.

Voy a intentar que el curso sea para todos los niveles. Se tocarán diversos aspectos desde truquillos del día a día y conceptos básicos de todas las tecnologías hasta configuraciones complejas, de una forma más o menos gradual.
A ver si lo conseguimos.

Si tenéis alguna sugerencia es el momento de decírmelo. Estoy totalmente abierto.

Los que os queráis apuntar decídmelo mandándome un email a “luis.bosque ARROBA the-cocktail PUNTO com”. Solo
pido que los que os apuntéis sea porque tenéis claro que queréis asistir a este curso y no por apuntaros por que sí.
Por desgracia hay límite de plazas, por lo que no puedo garantizar que haya sitio para todos.

Estaba instalando algunos plugins adicionales en el munin para monitorizar el estado de las peticiones que entran por Apache.
He encontrado uno para monitorizar el uso de memoria pero se ha quedado anticuado con respecto a ciertos cambios que ha sufrido la salida del comando passenger-memory-stats. Por lo tanto ya no sirve.
Basándome en dicho plugin y en este otro, he hecho algunos cambios y el código resultante es el siguiente:

#!/usr/bin/env ruby

def output_config
  puts <<-END
graph_category Passenger
graph_title passenger memory stats
graph_vlabel megabytes

apache_memory.label apache_memory
passenger_memory.label passenger_memory
END
  exit 0
end

def output_values
  memory_stats_command = '/usr/bin/passenger-memory-stats'
  memory = {}

  apache_header = "Apache processes"
  passenger_header = "Passenger processes"
  nginx_header = "Nginx processes"
  section = nil

  `#{memory_stats_command}`.each_line do |line|
    if line.include?(apache_header)
      section = "apache"
    elsif line.include?(nginx_header)
      section = "nginx"
    elsif line.include?(passenger_header)
      section = "passenger"
    elsif /### Total private dirty RSS: (\d+\.\d+) MB/.match(line)
      memory[section] = $1
    else
      next
    end
  end

  puts "apache_memory.value #{memory['apache']}"
  puts "passenger_memory.value #{memory['passenger']}"
  #puts "nginx_memory.value #{memory['nginx']}"
end

if ARGV[0] == "config"
  output_config
else
  output_values
end

El plugin parsea los totales de memoria tanto de apache, como de nginx, como de apache passenger. En mi caso solo muestro los valores de apache y de passenger, pero si se quisiera mostrar los de nginx, bastaría con descomentar la linea:

puts "nginx_memory.value #{memory['nginx']}"

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

Revelation tiene la opción de exportar el fichero de contraseñas a texto plano. El problema es que la organización de las entradas no es demasiado buena, porque las pone en una sola columna sin indentación, por lo que resulta dificil ver el anidación de las contraseñas en caso de que se usen carpetas.

Necesitaba tener las contraseñas en texto plano de forma que pudiese ver a simple vista esta información y fuese más facil de mantener. Esto se puede hacer fácilmente con ruby y xml-simple:

require 'rubygems'
require 'xmlsimple'

PASSWORD_FILE="./passwords.xml"

config = XmlSimple.xml_in(PASSWORD_FILE)

ce = config

indent = ""
INDENT_SPACES = "  "

def stepin(ce, indent)
  if !ce.nil?
    indent = indent + INDENT_SPACES
  end

  ce['entry'].each { |item|
    puts indent + item['name'].to_s
    if !item['entry'].nil?
      stepin(item, indent)
    elsif item['entry'].nil? && item['type'] != 'folder'
      if item['description'] && !item['description'].to_s.empty?
        puts indent + INDENT_SPACES + "description: " + item['description'].to_s
      end
      item['field'].each { |field_type|
        if !field_type['content'].nil?
          puts indent +
               INDENT_SPACES +
               field_type.values[0].gsub("generic-", "") +
               ": " +
               field_type.values[1]
        end
      }
    end
  }
end

stepin(ce, indent)

Para que esto funcione basta tener instalado rubygems y xml-simple.

Al montar el deploy de una nueva máquina con capistrano he querido afinar un poco la carga de crontabs.
No me gusta poner las tareas de crontab en el /etc/crontab. Creo que es una muy mala práctica. En vez de eso prefiero que cada usuario tenga su propia tabla de crontabs y para ello hago uso del comando crontab.
En muchas ocasiones hace falta definir crontabs para más de un usuario. Para no andar añadiendo una linea en el script de deploy por cada fichero de crontab que se tenga doy por hecho que los nombres de todos los archivos con las tablas de crontab siguen el mismo formato, que es “crontab ..
El código pues para capistrano es:

task :app_deploy, :roles => [:app] do
  Dir["./appserver/etc/crontab.*"].each { |crontab|
    sudo "sh -c 'cat #{release_path}/#{crontab} | \
    crontab -u  #{File.extname(File.basename(crontab)).delete('.')} -"
  }
end

En este código hay varias cosas que explicar.
Primero se presupone pues que si quiero, por ejemplo, añadir el crontab para el usuario www-data simplemente lo crearé y lo guardaré en appserver/etc/crontab.www-data
En cuanto al código, por un lado el bloque lo que hace es cargar en un array los ficheros con un nombre que coincida con el patrón comentado anteriormente. Hay que tener en cuenta que el código en ruby se ejecuta en la máquina desde la que se lanza el deploy y lo que se le pasa al comando run o sudo es un comando unix que se va a ejecutar en la máquina en la que se quiera hacer el deploy.

Por otro lado está el hecho de que cuando se ejecutan con sudo dos comandos unidos por una tubería, el sudo se va a aplicar únicamente al primero.
Si se hace:

$ sudo echo '* * * * *  date > /tmp/date' | crontab -u root -

el sudo se va a aplicar únicamente al comando echo y no al comando crontab por lo que eso no funcionará ya que no tenemos privilegios suficientes.

Por lo tanto para no tener que repetir el comando sudo a los dos lados de la tubería y también para no complicar el comando en capistrano, lo que se puede hacer es englobar toda la sentencia en una subshell de la siguiente forma:

$ sudo sh -c 'echo "* * * * *  date > /tmp/date" | crontab -u root -'

Al intentar instalar passenger a partir de la gema, me he encontrado con un error rarísimo. He estado un rato intentando ver que podía ser.
Al final me he cansado y he probado a cambiar la versión de rubygems de la 1.0.1 a la 1.3.1 y se ha instalado correctamente.
El error era el siguiente:

# gem install --no-ri --no-rdoc passenger
Bulk updating Gem source index for: http://gems.rubyforge.org
Building native extensions.  This could take a while...
ERROR:  Error installing passenger:
	ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb install --no-ri --no-rdoc passenger
checking for fcgiapp.h... no
checking for fastcgi/fcgiapp.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/usr/bin/ruby1.8
	--with-fcgi-dir
	--without-fcgi-dir
	--with-fcgi-include
	--without-fcgi-include=${fcgi-dir}/include
	--with-fcgi-lib
	--without-fcgi-lib=${fcgi-dir}/lib

Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/fcgi-0.8.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/fcgi-0.8.7/ext/fcgi/gem_make.out

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