Mostrando entradas con la etiqueta Sistemas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Sistemas. Mostrar todas las entradas

viernes, 26 de septiembre de 2014

Problemas de versiones de gemas en Ruby

Ante todo decir que no soy ni experto en Linux ni en Ruby ni en Redmine, pero tengo algo de experiencia en "pelearme" con los tres.

El caso que pongo me ocurrió al tratar de reparar un plugin en una versión de Redmine que habían actualizado de una muy antigua, y el plugin se había quedado a mitad instalar, aparecía en Redmine como instalado y se podía acceder a la página de configuración, pero a la hora de usarlo daba error de página no encontrada.

Lo primero fue verificar que eefectivamente en la base de datos no aparecían las tablas del plugin, por lo que realmente es como si no estuviese instalado.

Al tratar de lanzar los comandos rake para que terminase la instalación del plugin (después de haber actualizado con el correspondiente bundle update e instalado las gemas que indicaba que faltaban) surgían diversos errores (archivos no encontrado rich/helpers, Failed to build gem native extension, ) y acerca de que no se podía activar la versión 1.5.2 de la gema rack, .... Cada vez que solucionaba un problema aparecía otro, y luego volvía a empezar.

En este caso el problema es que había varias versiones de rake instaladas (se puede ver con el comando gem list) y nuestro proyecto no utilizaba la última versión del rake.

Si ocurre lo anterior puede ocurrir que al lanzar los comandos rake db:migrate de errores de diversos tipos (como los explicados inicialmente) que además no acaban de indicar que el problema está en el rake.

Para evitar esto, podemos intentar utilizar el comando bundle exec justo antes del rake, es decir:

bundle exec rake db:migrate RAILS_ENV=production
bundle exec rake redmine:plugins:migrate RAILS_ENV=production

De esta forma, lanzando esots comandos dentro de la carpeta de nuestro proyecto o aplicación,  el bundle exec permitirá que se "escoja" la versión de rake que nos haga falta de las que están instaladas y es muy probable que ya no surjan los errores antes comentados.


No confundir estos errores, con los que a veces devuelve el bundle update o bundle install que indican que faltan gemas o versiones de gemas por instalar en cuyo caso, con instalar esas gemas debería ser suficiente.

viernes, 28 de junio de 2013

Registrar DLL's de 32 bits en Windows de 64 bits

Generalmente cuando queremos registrar una DLL en Windows, usaremos el comando regsvr32 nombre_dll en la carpeta donde tengamos la DLL.

En los Windows de 64 bits hay que tener cuidado si ejecutamos el comando regsvr32, (no os dejéis "engañar" por el 32 del nombre del comando), estaremos utilizando el comando regsvr32 de 64 bits que se encuentra en System32, y si la DLL que queremos registar es de 32 bits, (algo bastante frecuente sobretodo si estamos migrando alguna aplicación desde un servidor viejo a uno más nuevo), puede devolver un error, que como suele ser habitual, es de todo menos descriptivo y claro con lo que realmente ocurre.

En estos casos, hay que abrir una ventana de símbolo de sistema y ejecutar:

      cd %SystemRoot%\Syswow64

      Para posicionarnos en la carpeta Syswow64 del sistema, generalmente C:\Windows\SysWOW64

      regsvr32 ruta_del_archivo\nombre_de_archivo.dll

      Con este comando, en la carpeta indicada anteriormente, estaremos ejecutando el comando regsvr32 de 32 bits y no deberíamos tener problemas con el registro de la DLL.

jueves, 13 de junio de 2013

Trasladar el repositorio del VisualSVN Server a otro servidor (Windows)

Bien, lo primero que hay que tener claro que "no vale" trasladar la carpeta del repositorio y esperar que el SVN lo reconozca por si solo.

Yo solo he probado una forma de hacer el traslado y que me ha funcionado perfectamente para trasladar 4 repositorios de un servidor a otro sin problemas.

Lo primero localizar el ejecutable svnadmin.exe en el servidor "viejo", abrimos una consola de comandos para ejecutar los comandos que nos harán falta y nos posicionamos en la carpeta donde hemos encontrado el ejecutable.

Lo primero que haremos será un dump, (backup), del repositorio que queremos trasladar. Hay que hacer un dump por cada uno de los repositorios que tengamos.
  • svnadmin dump /path/repositorio > repositorioSVN.dump
El /path se puede ver en las propiedades del servidor en la ventana de administración del VisualSVN Server, (en una instalación por defecto suele ser C:\Repositories\), y /repositorio es el nombre del repositorio que coincide con el nombre del directorio que estará dentro de /path.

Una vez tengamos los archivos dump los copiaremos al "nuevo" servidor.

Ahora solo falta importar los archivos dump, para eso, lo primero es crear el repositorio y luego cargar los datos
  1. svnadmin create /path/repositorio
  2. svnadmin load --force-uuid /path/repositorio < repositorioSVN.dump
Una vez tenemos todo montado, solo falta volver a crear los usuarios y configurar la seguridad.