La ventaja de tener la home en una partición separada en estos casos tiene un gran valor.

Por otra parte los datos que quería conservar eran:

• Algunos ficheros de configuración (/etc)
• Mis bases de datos (/var/lib/mysql)
• Gemas, paquetes autogenerados, librerías ruby,… (/usr/local)

Antes de reinstalar saqué un listado de todos los paquetes que tenía instalados con el siguiente comando:

  $ sudo dpkg --get-selections > MY_PACKAGES

Ahora ya estaba preparado para reinstalar. Al reinstalar le dije que quería usar como home mi antigua partición, sin formatearla por supuesto

Una vez reinstalado el sistema, restauré los repositorios de paquetes y de pasó aproveché a hacer limpieza (quité ppas que no usaba), con copiar el directorio etc/apt de la copia valía.

Como solo tenía añadidos PPAs los añadí a mano con el siguiente comando:

  $ sudo add-apt-repository ppa:

Dejé que el sistema actualizara todos los paquetes y mientras copié el directorio /usr/local dentro del nuevo sistema. Aquí tengo todas las gemas y librerías de Ruby, además en /usr/local/src guardo los fuentes y paquetes generados por mi, así que solo tuve que instalarlos de nuevo.

Ahora ya podía reinstalar todos los paquetes, para ello usé el siguiente script:

  #!/bin/bash
  # Get MY_PACKAGES then reinstall every package
  # To generate MY_PACKAGES: sudo dpkg --get-selections > MY_PACKAGES
  for pkg in `cat MY_PACKAGES | egrep -v deinstall | awk '{print $1}' | egrep -v '(dpkg|apt|ruby|sphinx)'`;do
    aptitude -y install $pkg
  done

Notas:

• Le pongo el parámetro “-y” para que responda yes a todas las preguntas
• Hago install en vez de reinstall para instalar solo lo nuevo.
• El último “egrep” excluye los paquetes que me creé yo para que no me los pise con los de la distribución.

Al terminar la instalación de todos los paquetes solo me faltaba recuperar mis bases de datos. Para ello paré MySQL:

  $ sudo /etc/init.d/mysql stop

Copié todo directorio /var/lib/mysql al nuevo sistema y arranqué de nuevo mysql:

  $ sudo /etc/init.d/mysql start

Arrancó, pero me salía el error:

'Access denied for user 'debian-sys-maint'@'localhost'

Esto lo solucioné conectando con el cliente de MySQL y cambiándole el password a ese usuario:

$ mysql -u root

> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD '
' WITH GRANT OPTION

A veces toca hacer deployment de aplicaciones que no tienen nada que ver con rails, el caso mas claro unas páginas estáticas(solo subir ficheros, sin migration, ni restart).

Para eso Lee Hambley hizo la gema railsless-deploy, básicamente lo que hace es quitar las “railties” de Capistrano. Con esta gema y un pequeño cambio en tu fichero Capfile puedes “deployar” lo que quieras.

Por una vez no me voy a enrollar y a escribir paso a paso un ejemplo porque creo que con las explicaciones que hay en la página de la gema es suficiente.

“Solo puede deployar uno” – Los inmortales

Para entendernos, si el usuario iba a http://bar.com con su navegado en inglés debía redireccionarlo a http://en.foo.com pero sin cambiar la dirección del navegador.

Lo primero que probé fue el típico:

  RewriteCond %{HTTP:Accept-Language} ^en
  RewriteRule ^/$ http://en.foo.com [L]

  RewriteCond %{HTTP:Accept-Language} ^pt-BR
  RewriteRule ^/$ http://br.foo.com [L]

  RewriteCond %{HTTP:Accept-Language} ^pt
  RewriteRule ^/$ http://pt.foo.com [L]

  ...

  #Default Language
  RewriteRule ^/$ http://foo.com [L]

Esto hacía la redirección pero al ser a otro dominio la hacía como si le pasáramos el flag R (vamos que hacía: [R,L]). Mas info sobre esto aquí.

La solución vino del módulo mod_proxy, y lo que he hecho ha sido usar el parámetro P (force proxy). La cosa ha quedado así:

RewriteCond %{HTTP:Accept-Language} ^en
  RewriteRule ^/$ http://en.foo.com/ [P,L]

  RewriteCond %{HTTP:Accept-Language} ^pt-BR
  RewriteRule ^/$ http://br.foo.com [P,L]

  RewriteCond %{HTTP:Accept-Language} ^pt
  RewriteRule ^/$ http://pt.foo.com [P,L]

  ...

  #Default language
  RewriteRule ^/$ http://foo.com [P,L]

That’s all folks!

Un ejemplo de entorno multistage podría ser el siguiente:

• mi máquina de desarrollo
• un servidor de aceptación
• un servidor de producción

Supongamos que mi máquina de desarrollo la actualizo a mano y los otros dos stages los quiero hacer con Capistrano. Capistrano por defecto solo sabe “deployar” y no es capaz de diferenciar entre aceptación y producción. Para ayudarle a diferenciar entre los diferentes stages podemos seguir varias estrategias.

Vamos a empezar por el mas simple de los casos, supongamos que entre aceptación y producción lo único que cambian son los datos de los roles. Una solución muy simple podría ser añadir a nuestro deploy.rb lo siguiente:

  if ENV['DEPLOY'].upcase == 'PRODUCTION'
    puts "*** Deployando en producción"
    role :web, "www.production.com"
    role :app, "app.production.com"
    role :db,  "db.production.com", :primary => true
  else
    puts "*** Deployando en staging"
    role :web, "www.staging.com"
    role :app, "app.staging.com"
    role :db,  "db.staging.com", :primary => true
  end

El código añadido es bastante simple, si la variable de entorno DEPLOY tiene el string ‘PRODUCTION’ ejecutaremos el deploy en la máquina de producción, sino se irá a staging. La ejecución se haría de la siguiente manera:

  $ DEPLOY=production cap deploy

Para probarlo sin tener que subir toda una aplicación a nuestros servidores podemos crear una tarea simple y estúpida como esta:

  task :foo do
    run "uptime"
  end

Entonces ahora lo podemos probar de nuevo:

  $ DEPLOY=production cap foo
  *** Deployando en producción
  ...

  $ cap foo
  *** Deployando en staging
  ...

Vale, funciona pero me chirría un poco, ¿no sería mejor hacerlo en el idioma de Capistrano? -aquí es donde todos al unísono debéis decir: SÍIIIIIIII. Entonces vamos a hacer algo parecido encadenando las tareas.

Si recordáis el día del taller os expliqué que con Capistrano podíamos definir varias tareas y llamarlas una detrás de otra, eso es lo que vamos a hacer. Vamos a considerar la configuración de cada stage una tarea diferente:

  task :production do
    puts "*** Deployando en producción"
    role :web, "www.production.com"
    role :app, "app.production.com"
    role :db,  "db.production.com", :primary => true
  end

  task :staging do
    puts "*** Deployando en staging"
    role :web, "www.staging.com"
    role :app, "app.staging.com"
    role :db,  "db.staging.com", :primary => true
  end

Utilizando este método el deploy o la ejecución de tareas en un stage u otro se hace de manera mas natural(sin usar variables de entorno):

  $ cap staging foo
  * executing `staging'
*** Deployando en staging
  * executing `foo'
  * executing "uptime"
    servers: ["localhost"]
Password:
    [localhost] executing command
 ** [out :: localhost] 01:39:08 up  2:25,  5 users,  load average: 0.01, 0.07, 0.05
    command finished

Si nos fijamos en el log de Capistrano vemos que primero ejecuta la tarea “staging” y luego ejecuta la tarea “foo”, que es lo que comentaba del encadenamiento de tareas.

Esta estrategia a mi me parece muy útil cuando los cambios que se necesitan para desplegar en producción y staging son mínimos. Considerando un cambio mínimo el cambio de variables.

Sin embarbo, esta estrategia no me parece limpia si ya se cambian tareas,callbacks, etc. entre stages. En tal caso cambiaría la estrategía y usaría la gema/plugin capistrano-ext. Esta gema por dentro usa el mismo método que acabamos de utilizar pero llega un poco mas lejos.

Para usar este plugin solo hay que hacer 4 cosillas y una de ellas opcional

1. Hacer un require de capistrano-ext
2. Definir los stages que vamos a usar
3. Definir el stage por defecto **OPCIONAL**
4. Escribir nuestras recetas por cada stage dentro de config/deploy/<stage>.rb

Vamos a hacer el require y definir los stages, escribimos en el inicio de nuestro deploy.rb:

  require 'capistrano/ext/multistage'
  set :stages, %w(staging production)

No ha sido tan dificil ¿verdad?

Ahora siguiendo nuestro sencillo ejemplo vamos a escribir la receta de cada stage. En config/deploy/staging.rb escribimos:

  puts "*** Deployando en staging"
  role :web, "localhost"
  role :app, "localhost"
  role :db,  "localhost", :primary => true

Y en config/deploy/production.rb:

  puts "*** Deployando en producción"
  role :web, "localhost"
  role :app, "localhost"
  role :db,  "localhost", :primary => true

Lo probamos y vemos que funciona:

  $ cap production foo
  * executing `production'
*** Deployando en producción
    triggering start callbacks for `foo'
  * executing `multistage:ensure'
  * executing `foo'
  * executing "uptime"
    servers: ["localhost"]
Password:
    [localhost] executing command
 ** [out :: localhost] 02:22:19 up  3:08,  5 users,  load average: 0.11, 0.10, 0.07
    command finished

Si no le pongo stage falla miserablemente:

  $ cap foo
    triggering start callbacks for `foo'
  * executing `multistage:ensure'
No stage specified. Please specify one of: staging, production (e.g. `cap staging foo')

Para definir un stage por defecto entonces añadimos a nuestro deploy.rb:

  require 'capistrano/ext/multistage'
  set :stages, %w(staging production)
  set :default_stage, 'staging'

Y ahora comprobamos que usamos staging por defecto:

  $ cap foo
      triggering start callbacks for `foo'
    * executing `multistage:ensure'
  *** Defaulting to `staging'
    * executing `staging'
  *** Deployando en staging
    * executing `foo'
    * executing "uptime"
      servers: ["localhost"]
  Password:
      [localhost] executing command
   ** [out :: localhost] 02:29:17 up  3:15,  5 users,  load average: 0.03, 0.08, 0.08
      command finished

Esta última estrategia la recomiendo si hay demasiada diferencia a la hora de hacer un deploy entre los diferentes stages, por ej. si en staging tenéis montado el stack con mongrel y en producción con passenger. Otra situación podría ser cuando el deploy tiene muchas variables(además diferentes entre stages) y hace que se pierda la legibilidad de nuestro deploy.rb

Al usar esta estregia siempre procuro que las variables y tareas comunes se queden en el deploy.rb, y el resto vaya al fichero de configuración del stage. Si tuviésemos demasiadas tareas comunes las movería a otro fichero, todo sea por mantener la legibilidad. De todos modos cada cual lo puede hacer como le vaya bien

Nota: El deploy.rb que he usado para escribir este post solo contenía lo que os he ido indicado, para las pruebas que hemos hecho no es necesario definir la aplicación, el repositorio, tipo de scm,…

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Ahora que tenemos gemcutter el “awesome gem hosting” (tal como se describen ellos mismos) debemos hacer que nuestro origen principal de gemas sea este.

Esto lo hacemos de manera muy simple y en 3 pasos.

1. Actualizamos Rubygems a la última version:

$ sudo gem update –system

2. Instalamos la gema gemcutter:

$ sudo gem install gemcutter

3. Cambiamos el origen de las gemas con el comando:

$ sudo gem tumble

Esto es todo

Actualización:

Parece que eso no era todo.

Diego, un programador cualquiera , me ha recordado de que os avise que la orden para actualizar Rubygems(paso 1) se usan 2 guiones que Wordpress se ha emperrado en poner como si fuese uno largo.

Esperábamos algo de feedback y la verdad es que no ha llegado nada de nada.

Entonces desde aquí hago una llamada a toda la comunidad ror-es para que, por favor, probéis esta release y nos hagáis saber si os ha funcionado todo como debía o si la hemos “liao parda”.

Podéis reportar desde Lighthouse, mandándome un email(rgo en aspgems punto com) o por twitter a @leptom.

Para probarla tenéis actualizar net-ssh a la versión 2.0.14 y descargar la gema desde aquí e instalarla:

http://groups.google.com/group/capistrano/web/capistrano-2.5.9.gem

Para ver los cambios realizados en esta release:

http://capistrano.googlegroups.com/web/2.5.9-Release-Notes.txt.md

Gracias a todos!

Y luego está apidock.com, que es un proyecto dedicado a mejorar la interfaz de la documentación existente de Ruby, Rails y RSpec.

Juntando estos dos elementos he escrito estos comandos que nos sirven para usar el buscador de apidock.com desde Ubiquity:

Para usarlo tienes que invocar Ubiquity y después poner “rails <término_a_buscar>”, podemos sustituir rails por ruby o rspec.

Tips:

• Para acceder a un resultado sin tener que hacer click en el basta con pulsar Ctrl+Alt+[número] .
• Accediendo directamente al gist con Ubiquity instalado nos dirá si queremos instalar los comandos automáticamente.

Aparentemente está bien, pero no es así porque no cambia el código de la respuesta. Los clientes recibirán un 200 OK, indicando de que el servidor está funcionando como debe. El código de estado correcto debiera ser 503 Service Unavailable. Con un 503, conseguiremos prevenir que los motores de búsqueda indexen nuestra página de mantenimiento, a los que usan nuestra API les haremos la vida mas fácil, las peticiones AJAX pueden ser tratadas correctamente cuando el site se ha caído, etc.

La configuración de apache para realizar esto es la siguiente:

El flag redirect=503 parece un poco raro, aquí os pongo un extracto de la sección de flags de la documentación de mod_rewrite:

While this is typically used for redirects, any valid status code can be given here. If the status code is outside the redirect range (300-399), then the Substitution string is dropped and rewriting is stopped as if the L flag was used.

En definitiva, que a RewriteRule puedes ponerle como segundo argumento lo que sea y el flag last no es necesario porque se aplica automáticamente. Pongo como path ‘-’ y además el flag last a modo informativo de todos modos.

Nota: Esto es una traducción (muy) libre del artículo de Chris K. (http://www.shiftcommathree.com/articles/make-your-rails-maintenance-page-respond-with-a-503).

Con esta pequeña regla para apache evitamos que estén a la vista de fisgones: