¿Qué activos se van a comprar? Activos que actualmente son ilíquidos y que nadie quiere comprar. Dicen que no van a ser activos tóxicos, pero, si no son tóxicos, ¿por qué van a querer los bancos quitárselos de encima?

Básicamente, se comprarán activos hipotecarios, es decir, los contribuyentes vamos a comprar las casas que los bancos han financiado y no ahora no se venden. ¿A qué precio? Seguramente el precio será algo más barato que el precio alcanzado en el pico de la burbuja, pero, ¿podremos recurperar ese dinero en un plazo razonable?

¿Para qué va a servir la medida? ¿Para reactivar la economía? No lo creo. Sólo va a servir para paliar la deuda de los bancos y cajas, pero no para que se concedan más créditos. Es decir, los contribuyentes vamos a acabar pagando, por ejemplo, enjendros como “Pocerolandia”.

¿Estamos locos? ¿Está actúando el gobierno en beneficio de los ciudadanos? ¿Por qué no ha habido un debate en el Parlamento? ¿Cuál es la opinión de los partidos de la oposición?

¿No será mejor construir un nuevo sistema? ¿Vamos a dejar que se premie de esta manera la avaricia?

La crisis tal vez sea una oportunidad para mejorar. Reflexionemos y pensemos sobre ello.

Actualización: Aquí os dejo un excelente artículo sobre el mismo tema:

• Plan de recompra de activos: más sombras que luces (GurusBlog).

La primera edición fue la del 2006, la del descubrimiento. Para los que ya sabíamos lo que se puede disfrutar programando en Rails, fue el descubrimiento de que había mucha otra gente programando con este framework tan poco conocido por entonces. Para los que se acercaban por primera vez a Rails, fue el descubrimiento del framework en sí. Fue todo un éxito porque no sabíamos si seríamos más de 20 y acabamos siendo unos 150.

La segunda edición, la del 2007, fue la de la consolidación. Sabíamos de antemano que el interés por Rails existía y aquí vimos que dicho interés era creciente, que las empresas estaban adoptando la tecnología y que el framework maduraba.

¿Cómo será la próxima edición? Por lo pronto, hay un gran interés por patrocionar el evento, con lo que veo que el negocio en torno a Rails está creciendo. Por otro lado, parece que va a ser posible traer a varios gurús a nivel mundial. Este año también se reducirá el número de ponencias, para así ofrecer las de mayor calidad.

Por cierto, ¿todavía no has presentado tu propuesta de ponencia? El plazo termina el 29 de septiembre. No lo dejes para el último día.

• Vulnerabilidad por denegación de servicio en la librería REXML.
• Qué nos espera en Ruby 1.9.
• daemon_controller: una librería para gestionar demonios.
• Rails 2.2 será “thread safe”.
• Ventajas en incovenientes de GitHub y RubyForge como repositorios de gemas.

• La infraestructura DNS estaba expuesta a una grave vulnerabilidad.
• La investigación en seguridad está entrando en una nueva era, ya que las aplicaciones están sumamente interrelacionadas a través de internet.
• La actualización de aplicaciones online puede verse comprometida debido a la vulnerabilidad de DNS. Por ejemplo, un atacante podría hacerse pasar por el sitio del cual nos descargamos las actualizaciones del sistema operativo.
• SSL no aporta mucho, ya que en última instancia la cadena de autoridades certificadoras depende de DNS.
• Las redes internas tampoco están totalmente a salvo, ya que siempre acaba habiendo alguna dependencia con el exterior.

Ha sido publicado también un curioso video elaborado por Clarified Networks en el que puede verse cómo se ha propagado la instalación del parche en los servidores DNS:

Rojo — Sin parchear
Amarillo — Parcheado, pero el NAT embrolla las cosas
Verde — OK

• Se anuncia Rails Summit Latin America 2008.
• Engine Yard consigue $15 millones de financiación.
• Se publica libxml-ruby 0.8.0, con una gran mejora del rendimiento en el parseo de XML.
• Se lanza JRuby 1.1.3.
• Open Flash Chart ahora como plugin para Rails.
• Se lanza RedCloth 4.0.
• Disponible el calendario de la RailsConf Europe 2008.
• La internacionalización llega a Rails Edge.

Los resultados pueden verse en la anterior gráfica. El 83.3% de los usuarios de Firefox tienen su browser actualizado, frente a sólo el 47.6% de los usuarios de Internet Explorer.

Para configurar el cluster hacemos:

$ mongrel_rails cluster::configure -e production -p 8000 -N 4 -c /var/miaplicacion/current -a 127.0.0.1
** Ruby version is not up-to-date loading cgi_multipart_eof_fix
Writing configuration file to config/mongrel_cluster.yml.

Este comando habrá creado el fichero config/mongrel_cluster.yml. Lo editamos y añadimos al final sendas líneas indicando el usuario y el grupo que ejecutarán los mongrels. Como ya indicamos, será un usuario no privilegiado el que ejecute tanto el servidor web como los mongrels:

cwd: /var/www/miaplicacion/current
log_file: log/mongrel.log
port: "8000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 4
user: usuario
group: usuario

Añadiremos el cluster de mongrels al arranque de la máquina:

sudo mkdir /etc/mongrel_cluster
sudo ln -s /var/www/miaplicacion/current/config/mongrel_cluster.yml /etc/mongrel_cluster/miaplicacion.yml
sudo cp /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d
sudo chmod +x /etc/init.d/mongrel_cluster
sudo /usr/sbin/update-rc.d -f mongrel_cluster defaults
sudo ln -s /usr/bin/ruby1.8 /usr/bin/ruby

Y ya podremos arrancar y parar el cluster de mongrels:

$ sudo /etc/init.d/mongrel_cluster start
$ sudo /etc/init.d/mongrel_cluster stop

Ahora sólo nos queda apuntar el servidor web nginx a los mongrels. Para ello, editaremos el fichero /usr/local/nginx/conf/nginx.conf. Éste es un ejemplo básico del cual podemos partir.

user              miusuario miusuario;
worker_processes  4;
 
events {
    worker_connections  1024;
}
 
http {
    include           mime.types;
    default_type      application/octet-stream;
    sendfile          on;
    keepalive_timeout 65;
    gzip              on;
 
    upstream miaplicacion {
        server 127.0.0.1:8000;
        server 127.0.0.1:8001;
        server 127.0.0.1:8002;
        server 127.0.0.1:8003;
    }
 
    server {
        listen       80;
        server_name  midominio.com;
 
        root   /var/www/miaplicacion/current/public;
        index  index.html;
 
        location / {
          proxy_set_header  X-Real-IP  $remote_addr;
          proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_redirect false;
 
          if (-f $request_filename/index.html) {
            rewrite (.*) $1/index.html break;
          }
 
          if (-f $request_filename.html) {
            rewrite (.*) $1.html break;
          }
 
          if (!-f $request_filename) {
            proxy_pass http://miaplicacion;
            break;
          }
        }
 
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

En la sección “upstream” apuntamos hacia los mongrels. En ella, “miaplicacion” es una etiqueta, la misma que usamos más abajo en la línea:

proxy_pass http://miaplicacion;

En la sección “server” cabe destacar que “root” apunta al directorio public de mi aplicación.

Rearrancamos nginx para que la nueva configuración surta efecto:

$ sudo /etc/init.d/nginx stop
$ sudo /etc/init.d/nginx start

Y ahora sí, por fin, tenemos que poder abrir desde nuestro navegador la URL:

http://midominio.com/

y acceder a nuestra aplicación. Si no tenemos configurado todavía la entrada en DNS, tendremos que poner la IP.

Como una última prueba, probaremos una vez más a rearracar la máquina y ver que todo arranca correctamente.

Tutorial completo

• Rails en producción - Parte 1 - Introducción
• Rails en producción - Parte 2 - Configuración del servidor debian
• Rails en producción - Parte 3 - MySQL, Ruby y Rails
• Rails en producción - Parte 4 - Servidor web nginx
• Rails en producción - Parte 5 - Mongrels e instalación de nuestra aplicación
• Rails en producción - Parte 6 - Cluster de mongrels

Mongrel será el encargado de atender las peticiones HTTP que lleguen del servidor web y ejecutar nuestra aplicación en el intérprete de Ruby.

Para instalar mongrel simplemente haremos:

$ sudo gem install mongrel mongrel_cluster --include-dependencies --no-rdoc --no-ri

Instalación de nuestra aplicación

Supondré que tenemos nuestra aplicación en un repositorio de subversion. En este caso, antes de poder hacer un export de la aplicación desde el repositorio, necesitaré instalar subversion:

$ sudo aptitude install subversion -y

Ahora ya podré transferir una copia de mi aplicación al servidor de producción. Supondré que la aplicación la vamos a instalar, por ejemplo, en /var/www/miaplicacion/current.

$ sudo chown usuario:usuario /var/www
$ mkdir /var/www/miaplicacion
$ cd /var/www/miaplicacion
$ svn export http://svn.midominio.com/miaplicacion/trunk current

Necesitamos crear una base de datos para la aplicación:

$ mysql --user=root -p
mysql> grant all on miaplicacion_production.* to miaplicacion@localhost identified by 'miaplicacion';
mysql> flush privileges;
mysql> create database miaplicacion_production;

Es decir, hemos creado una base de datos llamada “miaplicacion_production” y un usuario “miaplicacion”, con idéntica password, que dispone de todos los permisos en “miaplicacion_production”.

Normalmente, tendremos que configurar el fichero config/database.yml de nuestra aplicación para que apunte a la base de datos que acabamos de crear:

production:
  adapter: mysql
  database: miaplicacion_production
  username: miaplicacion
  password: miaplicacion
  socket: /var/run/mysqld/mysqld.sock
  host: localhost
  encoding: utf8

Antes de poder arrancar nuestra aplicación deberemos instalar todas las gemas que utilicemos y que no hayamos instalado. Si no nos acordamos podemos intentar arrancar la aplicación y ver los errores. Leyendo el log de errores suele ser fácil identificar si nos falta alguna gema. Una que siempre viene bien será:

$ sudo gem install rake

Hay que tener en cuenta que si no especificamos la versión, gem install instalará la última versión disponible en el repositorio. Esto quiere decir que en el entorno de desarrollo y en el de test, si instalamos las gemas hace tiempo, las versiones pueden ser inferiores, y por lo tanto, nos podemos encontrar con problemas de compatibilidad. Para ver las gemas instaladas en una máquina y sus versiones podemos ejecutar:

$ gem list

Ahora ya puedo arrancar mi aplicación. De momento, para probar, arrancaremos un único proceso mongrel. Todavía no hemos configurado el servidor web para que apunte a los mongrels, así que no podremos comprobar con un navegador que funciona. Simplemente, veremos que arranca correctamente leyendo el fichero log/production.log:

$ cd /var/www/miaplicacion/current
$ mongrel_rails start -d -e production -p 8000 -P log/mongrel8000.pid

Si en el fichero de log vemos que la aplicación ha arrancado, podríamos incluso comprobar que sirve peticiones:

$ cd
$ wget http://localhost:8000/

Esto me guardaría en el directorio raíz del usuario un fichero llamado index.html con el HTML de la página raíz de mi aplicación. En el fichero de log debería poder ver la petición. ¿Quién necesita un browser?

En el último capítulo configuraremos un cluster de mongrels y apuntaremos el servidor web hacia ellos. Por eso, ahora, paramos el mongrel que hemos arrancado como prueba:

$ mongrel_rails stop -P log/mongrel8000.pid

Tutorial completo

• Rails en producción - Parte 1 - Introducción
• Rails en producción - Parte 2 - Configuración del servidor debian
• Rails en producción - Parte 3 - MySQL, Ruby y Rails
• Rails en producción - Parte 4 - Servidor web nginx
• Rails en producción - Parte 5 - Mongrels e instalación de nuestra aplicación
• Rails en producción - Parte 6 - Cluster de mongrels