internet, desarrollo, diseño web, sysadmin

El CERT ha publicado un documento alertando de deficiencias en el protocolo DNS que pueden permitir a un atacante el envenenamiento de las cachés. Es decir, el atacante podría reemplazar en el servidor afectado direcciones de sitios populares de internet por la dirección de un servidor malicioso.

Al parecer, estas deficiencias en el protocolo fueron descubiertas hace meses por Dan Kaminsky, de la empresa IOActive. Los proveedores de servidores de DNS fueron avisados y se pusieron a trabajar, en secreto, en parches para solucionar el problema.

El problema no se ha descrito con detalle todavía. La solución implementada en los parches consiste en aumentar el rango de puertos UDP posibles desde los que se pueden hacer consultas a los servidores de DNS. La única solución definitiva es utilizar DNSSEC, es decir, las extensiones de seguridad de DNS, lo cual no sería ni mucho menos trivial.

El revuelo que esta noticia ha causado tan grande que hasta la prensa generalista se ha hecho eco de ella.

Enlaces relacionados

• CERT: Multiple DNS implementations vulnerable to cache poisoning
• SecurityFocus: Alliance forms to fix DNS poisoning flaw
• ISC: DNS Cache Poisoning Issue
• 20 minutos: Un problema con las direcciones de las webs pone en riesgo la seguridad de internet
• El Mundo: Los gigantes de la Red se movilizan contra un grave agujero de seguridad
• El País: Un grave fallo de seguridad en la Red moviliza a las grandes compañías

Ilya Grigorik ha publicado un interesante post con 6 consejos para optimizar nuestro código Ruby si utilizamos el intérprete MRI.

Minimizar las búsquedas en el AST

Si utilizamos Ruby 1.8, nuestro MRI no generará bytecode. Por ello, cada llamada a un método, cada utilización de una variable, etc., realizará una búsqueda en el Abstract Syntax Tree (AST), es decir, en una estructura en árbol que representa la sintaxis de nuestro código fuente.

Debemos, por lo tanto, tener en cuenta que abusar de la metaprogramación puede hacer que el rendimiento de nuestra aplicación se vea degradado.

Optimizar para la caché

En relación con el punto anterior, para minimizar las búsquedas en el AST, Ruby MRI mantiene una caché de las variables locales. Es decir, utilizar variables locales será más rápido:

@var = "local variable, which is cached by Ruby, and requires a single lookup"
self.var = "requires walking the AST, and results in multiple lookups"

Mejor la interpolación que la concatenación

puts "This string embeds #{var1} and #{var2} through interpolation"  # faster
puts "This string concatenates " << var1 << " and " << var 2  # slower

Utilizar métodos destructivos

Cuando disponemos de un método no destructivo y su pareja destructiva, como gsub y gsub!, suele ser más eficiente utilizar el método destructivo. Los métodos no destructivos suelen ser más lentos ya que tienen que realizar copias de los objectos.

hash = {}
hash = hash.merge({1 => 2}) # duplicates the original hash
hash.merge!({1 => 2}) # equivalent to previous line, and faster

Utilizar bloques en lugar de Symbol.to_proc

@widget_ids = @widgets.map(&:id) # Symbol.to_proc method, order of magniture slower...
@widget_ids = @widgets.collect {|w| w.id } # faster and simpler

Compruebalo tú mismo

Si tienes dudas sobré qué código será más rápido, es sencillo comprobarlo:

require 'benchmark'
 
n = 100000
Benchmark.bm do |x|
   x.report('copy') { n.times do ; h = {}; h = h.merge({1 => 2}); end }
   x.report('no copy') { n.times do ; h = {}; h.merge!({1 => 2}); end }
end
copy  0.350000   0.060000   0.410000 (  0.419445)
no copy  0.250000   0.020000   0.270000 (  0.276030)

Si utilizamos subversion como software de control de versiones, cada vez que creemos un nuevo proyecto rails, habrá una serie de tareas que tendremos que llevar a cabo.

Supongamos que el repositorio está creado y accesible en la URL:

http://svn.misite.com/miproyecto

Lo primero que tendremos que hacer, siguiendo las buenas prácticas del control de versiones con subversion, es crear tres carpetas: trunk, tags y branches.

$ REPO=http://svn.misite.com/miproyecto
$ svn mkdir --message="Layout inicial" $REPO/trunk $REPO/tags $REPO/branches
Commit de la revisión 1.

Después creamos la aplicación rails como siempre:

$ rails miproyecto
      create  
      create  app/controllers
      create  app/helpers
      ...

Ahora, en lugar de hacer un svn import, lo recomendable es hacer un svn checkout del trunk en el directorio de la aplicación y a continuación añadir la estructura de directorios del proyecto. De esta manera podemos eliminar algunos ficheros del control de versiones antes de hacer el commit:

$ cd miproyecto
$ svn checkout $REPO/trunk .
Revisión obtenida: 1
$ svn add --force .
A         lib
A         lib/tasks
...

Los ficheros de log no necesitaremos que estén bajo el control de versiones:

$ svn revert log/*
Se revirtió 'log/development.log'
Se revirtió 'log/production.log'
Se revirtió 'log/server.log'
Se revirtió 'log/test.log'
$ svn propset svn:ignore "*.log" log
propiedad 'svn:ignore' asignada en 'log'

De la misma manera, como cada desarrollador puede tener un database.yml diferente, será una buena idea eliminarlo del control de versiones:

$ svn revert config/database.yml 
Se revirtió 'config/database.yml'
$ mv config/database.yml config/database.yml.sample
$ svn add config/database.yml.sample 
A         config/database.yml.sample
$ svn propset svn:ignore "database.yml" config
propiedad 'svn:ignore' asignada en 'config'
$ cp config/database.yml.sample config/database.yml

Asimismo, el fichero schema.rb, al ser generado dinámicamente por las migraciones, no tiene sentido tampoco que esté bajo el control de versiones:

$ svn propset svn:ignore "schema.rb" db
propiedad 'svn:ignore' asignada en 'db'

También interesará eliminar del control de versiones cualquier fichero que se genere en tmp:

$ svn propset svn:ignore "*" tmp
propiedad 'svn:ignore' asignada en 'tmp'

Ahora ya podremos hacer nuestro primer commit al repositorio:

$ svn commit -m "Nueva aplicación"

Entradas relacionadas

• Scripts útiles para subversion

Se hace raro verle en movimiento y oírle, pero si te encanta Dilbert, como a mí, seguramente vas a disfrutar mucho con su canal en YouTube.

Visto en El Blog Salmón.

A continuación voy compartir con vosotros cómo actualizar WordPress, el software de este blog, a la última versión disponible (la 2.5.1 en este momento). Me he basado en la documentación de la propia web de WordPress. Básicamente, los pasos son:

• Activar una página de mantenimiento.
• Realizar una copia de seguridad.
• Desactivar los plugins.
• Descargarse la nueva versión y actualizar los ficheros.
• Actualizar la estructura de la base de datos.
• Activar los plugins.
• Desactivar la página de mantenimiento.

Página de mantenimiento

Durante el proceso de actualización no es posible asegurar que el contenido del blog vaya a mostrarse correctamente. Por ello, es conveniente que cualquier contenido del blog apunte a una página estática que indique que el blog no está disponible por mantenimiento. En la documentación recomiendan el plugin Maintenance Mode, pero a mí me ha dado problemas. Leo aquí que les pasa algo parecido. Parece que el plugin no se lleva bien con el upgrade a las últimas versiones de WordPress.

Copia de seguridad

Necesitaremos hacer realmente dos copias de seguridad:

• del software propiamente dicho, incluyendo los plugins, los temas, etc.
• del contenido de la base de datos.

Supongamos que el blog está instalado en /var/www/miblog y que vamos a realizar la copia de seguridad de los ficheros en el directorio backups del directorio home del usuario. El backup lo podemos realizar con los siguientes comandos:

$ MIBLOG=/var/www/miblog
$ cd $MIBLOG
$ mkdir ~/backups
$ tar cvf ~/backups/miblog.tar .

Y para hacer la copia de seguridad de la base de datos simplemente haremos:

$ mysqldump -u user -p database -h host > ~/backups/miblog_database.dmp

Desactivación de los plugins

Es recomendable desactivar los plugins, ya que alguno podría dar problemas con la nueva versión. Supongo que si tenemos un entorno de pruebas (porque lo tenemos, ¿no?), no sería muy descabellado, si las pruebas han ido bien, no desactivar los plugins durante el proceso de actualización en producción.

Actualización de los ficheros

Primeramente nos descargaremos la última versión de WordPress y la descomprimimos:

$ cd /var/www
$ wget http://wordpress.org/latest.zip
$ unzip latest.zip
$ rm latest.zip

A continuación, borramos los directorios wp-includes y wp-admin de la versión antigua y copiamos los ficheros de la nueva versión:

$ cd $MIBLOG
$ rm -rf wp-includes wp-admin
$ cd wordpress
$ tar cvf - .  (cd $MIBLOG tar xvf -)

También es necesario comprobar si al aumentar la versión del software, debemos añadir alguna línea nueva en el fichero de configuración, wp-config.php. Para ello, a parte de leer la documentación de la nueva versión, algo siempre recomendable, podemos ver las diferencias entre nuestro wp-config.php y el fichero wp-config-sample.php que se habrá copiado de la nueva versión:

$ cd $MIBLOG
$ diff wp-config-sample.php wp-config.php

Por ejemplo, en la versión 2.5 se ha introducido la variable SECRET_KEY. Deberemos, por lo tanto, editar el fichero wp-config.php y añadir:

// Change SECRET_KEY to a unique phrase.  You won't have to remember it later,
// so make it long and complicated.  You can visit http://api.wordpress.org/secret-key/1.0/
// to get a secret key generated for you, or just make something up.
define('SECRET_KEY', 'put your unique phrase here'); // Change this to a unique phrase.

Actualización de la estructura de la base de datos

Si es necesaria una actualización de la estructura de la base de datos, al intentar acceder a la interfaz de administración, obtendremos una pantalla como la siguiente:

Al aceptar, se actualizará la estructura de la base de datos.

Activación de los plugins

Si hemos desactivado los plugins, los tendremos que volver a activar.

Desactivación de la página de mantenimiento

Si hemos activado una página de mantenimiento, la deberemos desactivar.