4Trabes Historias de una empresa en 100 metros cuadrados

El error completo es algo más largo:

ERROR:
ORA-01034: ORACLE not available
ORA-27121: unable to determine size of shared memory
segment
Linux Error: 13: Permission denied

Surge al intentar utilizar las herramientas de consola (sqlplus, imp) desde la propia máquina en la que está instalado el oracle. Las conexiones JDBC, asi como el interfaz web funcionan correctamente.

De otras batallas, tenemos claro que hay que fijar correctamente el ORACLE_HOME y el ORACLE_SID, pero el problema persiste. Tras un rato de búsquedas, llegamos a la solución: el instalador de oracle (al menos en nuestra plataforma que es linux) no "marca" como setuid $ORACLE_HOME/bin/oracle. Sabiendo esto, la solución es fácil:

$ cd $ORACLE_HOME/bin
$ chmod 6751 oracle

En la oficina tenemos montado un proxy reverso con Pound para acceder a varios servicios desde fuera, entre ellos un repositorio Subversion. El mecanismo es sencillo: el SVN está montado en un virtual host de Apache con mod_svn escuchando en el puerto 80 y un Pound proxificando las peticiones HTTPs que recibe en el 443.

Todo funcionaba hasta que se nos dió por hacer un tag (esto es, un svn copy). 502 Bad Gateway al canto. ¿Mande?

Investigando descubrimos que las operaciones MOVE y COPY de Webdav utilizan el valor Destination de los headers de la petición. Valor que el proxy deja intacto con lo que Apache recibe un Destination “https://xxx” y se hace un lío. Teóricamente Pound ofrece soporte para solventar este problema utilizando el parametro de configuración RewriteDestination. Al que no le funcione puede probar a pedirle amablemente a Apache que le arregle el problema, utilizando mod_headers y configurando el virtual host de turno:

  <VirtualHost *:80>
    Servername svn.acme.com
    RequestHeader edit Destination ^https http early
    ...    

Por cierto, si alguien quiere que postee un howto sobre SVN con HTTPs detrás de un Pound que levante la mano.

Viernes, 20 de febrero de 2009, cuatro y cuarto de la tarde.

Tras casi tres años de servicio ininterrumpido apagamos Ortega. Desaparece el siseo de sus 4 ventiladores y el zumbido de sus discos SCSI. Con el silencio el tiempo se para. Una parte de mi muere. Una avalancha de recuerdos me sepulta. Ortega ha estado ahí desde el principio: el primer Subversion, la base de datos MySQL, las carpetas compartidas Samba. Todo lo que Trabe ha hecho, todo lo que hemos sido, ha pasado por las tripas de esta máquina. Parece que ha pasado un siglo.

El vetusto IBM ZPro que compré en una tienda de segunda mano cuando esta empresa no era ni un sueño descansa ahora en el almacén. Las cosas cambian. Es inevitable.

El ruido del nuevo servidor vuelve a poner en marcha el tiempo. La vida sigue sin ortega.

En mi post de ayer propuse una solución parar requerir gemas de GitHub con estilo, sin embargo me olvidé de una cuestión importante que me ha recordado Asís: el código depende de ActiveSupport, por lo tanto, ciertos scripts (por ejemplo console) no funcionan bien. La solución rápida es requerir ActiveSupport. La solución buena es eliminar la dependencia. Nuevo pastie al canto.

Mea culpa. Disculpen ustedes.

Llevaba tiempo pensando en simplificar la definición de dependencias de gemas de GitHub en el environment.rb de nuestras aplicaciones, pero no encontraba el momento. El domingo estuve leyendo un post de Bruce Williams en su blog CodeFluency: A GitHubby config.gem hack, donde propone una solución para pasar de esto:

config.gem 'yfactorial-utility_scopes', :version => '0.2.2', 
  :lib => 'utility_scopes', :source => 'http://gems.github.com'

...a esto:

config.gem 'yfactorial-utility_scopes', :version => '0.2.2', :github => true

Había dos cosas en su solución que no me gustaban: 1) el uso de un flag y 2) que la implementación sobreescribe el método gem. Así que me he animado y acabo de montar una versión que intenta paliar esos dos problemas. El código no tiene nada de especial. Podéis cogerlo de este pastie. Sólo hay que tirarlo en lib y requerirlo en environment.rb. Y con esto ya podemos escribir bloques de dependencias con estilo:

config.gem 'authlogic', :version => '1.3.8'
config.gem 'faker', :version => '0.3.1'  
config.gem 'spreadsheet', :version => '0.6.2.1'  

config.gem.github 'yfactorial-utility_scopes', :version => '0.2.2'
config.gem.github 'mislav-will_paginate', :version => '2.3.6' 
config.gem.github 'rubyist-aasm', :version => '2.0.5'

Actualización

Esta versión del código depende de ActiveSupport. En este post podéis encontrar una versión actualizada del código que no depende de AS.

A petición de Asís he añadido a nuestro úlitmo proyecto el siguiente código en la configuración de Capistrano.

namespace :deploy do   
  before "deploy", "notes:show"
end

namespace :notes do  
  task :show do
    unless (notes = `$(which rake) notes`).to_a.length < 2
      Capistrano::CLI.ui.say notes
      answer = Capistrano::CLI.ui.ask "Do yo want to continue? [Y/n]"
      exit unless ['y','Y', ''].include?(answer)
    end
  end
end

Ahora es imposible hacer un despliegue sin ver todos los TODOs que nos hemos dejado sin hacer.

Autoflagelación

Actualización

Cosa que puede parecer sencilla, pero no lo es tanto.

$ git tag -d 1.0.0
$ git push origin :refs/tags/1.0.0

Mil gracias a So Many Schemes.

Cuando veas ese error en un firefox 2, es probable que estés intentando ver una imagen jpg con un espacio de color CMYK. Estos son algunos de los síntomas habituales en ese caso:

1. firefox 2 dice:

   No se puede mostrar la imagen “http:/xxxxxxxxxxxxx.com/yyyyy.jpg” porque contiene errores.

2. si tratamos de cargar la misma imagen en un explorer, obtendremos el clásico icono de "imagen no encontrada", ese que es como un cuadradito con una x roja dentro.
3. firefox 3 muestra la imagen sin ningún problema

Más información sobre este "problemilla" en el blog del gran Matt Cutts.