Actualizando Alfresco cuando no es posible actualizarlo

Lo se, estoy comenzando al revés por una razón, y es que la memoria es tan vaga como el administrador de sistemas cuando decide documentar un proceso que probablemente jamás volverá  a necesitar. Internet está lleno de foros y saber extraer la información adecuada no es un proceso sencillo.

No se si alguna vez os he comentado que por razones laborales he pasado de la era pre-Google a otra completamente distinta donde Google parece la fuente del saber. Entre medias estuve trabajando en el sector de la electro-medicina, un campo muy interesante pero menos amplio que el de sistemas, para ejemplo sirve el que los ecógrafos por entonces no usaban (y quizás siga siendo así) bases de datos relacionales y el indexado de las pruebas se convierte en un caos cuando crece el número de pacientes.

A más de uno os habrá pasado que ante una migración se extiende una sensación de miedo ante lo desconocido, especialmente si estamos hablando de sistemas en producción con decenas de personalizaciones que a saber si funcionarán en el nuevo motor del producto que sea, pero es inevitable, tarde o temprano es necesario migrar a una nueva versión que no sólo ofrece mayor rendimiento o funcionalidad, si no que también actualiza los componentes que garantizan la seguridad y estabilidad necesarios para toda empresa que se precie.

El pasado mes de agosto sufrí lo indecible para migrar Alfresco Community de la 4.2c a la 5.0a, saltándome varias versiones por en medio. Ha sido una decisión sabia pues la 4.2c daba bastantes problemas con Kerberos y la integración con Google Docs era pésima.

El escenario en el que me muevo es un servidor físico (Windows 2008 Server R2) con Hyper-V y una máquina virtual que hemos llamado ALFRESCO.
No se si lo sabéis, pero hay un método muy majo para crear una nueva máquina virtual a partir de la copia de seguridad de un VHD existente que consiste en simplemente haber exportado previamente una máquina virtual, lo cual es un proceso largo y tedioso pero, una vez que lo hagamos, ya dispondremos de una fichero .exp que contiene en formato XML todos los parámetros necesarios para poner en funcionamiento la misma máquina virtual en un entorno de pruebas.

Es muy sencillo: a partir de la última copia de seguridad del servidor virtual (porque me imagino que haréis copia… ¿verdad?) extraeremos el VHD y sustituiremos el VHD obtenido en la exportación que en su día hicimos. Con esto hecho importamos la máquina con el nuevo VHD y listo. Así la máquina de producción la mantendremos en funcionamiento constante hasta que tengamos una de pruebas con el nuevo Alfresco operativo 100% . Para evitar la piratería Microsoft genera un identificador único, no lo mováis porque eso supone mover la licencia de un servidor a otro.

Como la máquina importada es «gemela» de ALFRESCO tendrás que iniciarla aislada de la red para según arranque sacarla del dominio y modificar su nombre. En mi caso le puse ALFRESCOTEST y tan contentos.

Con esto ya tenemos una nueva máquina de pruebas a la que sólo queda reconfigurar cualquier fichero de propiedades o XML en donde haya alguna URL o nombre de host de la máquina que tenemos en producción. Un consejo evidente es que siempre que modifiquéis cualquier fichero de configuración hagáis de inmediato una copia del mismo para mantenerlo a salvo de cualquier incidente y que os permita reconfigurar fácilmente Alfresco en caso de migraciones, porque así sabréis que ficheros habéis personalizado. Si tenéis la suerte de tener la versión «enterprise» supongo que podréis trabajar directamente en la GUI vía web.

http://docs.alfresco.com/4.0/concepts/ch-upgrade.html

Bien, aquí tenemos la teoría, parece hasta sencilla, pero a la hora de la verdad es improbable que desde ciertas versiones podáis migrar a otras debido a los cambios de estructura de la base de datos, ya que Google Docs 1.0 introduce ciertos aspectos no compatibles con versiones posteriores: https://issues.alfresco.com/jira/browse/ALF-20086 , todo está documentado y aún así no existe parche, al menos para Community.

Con este panorama y un Alfresco totalmente funcional con SSL, certificado de dominio, Kerberos operativo, sincronización con directorio activo, varios sitios activos y un sistema de reglas para el envío automatizado de nóminas me sentía con pocas ganas de cambiar de versión pero, el mundo no es de los cobardes, así que me puse en marcha:

Lo primero es comprobar que el servidor de pruebas funciona. Alfresco permite que coexistan dos versiones sin mayor problema que renombrar el «dir.root», este en una instalación normal es: C:\Alfresco, así que basta con renombrar C:\Alfresco a C:\Alfresco.old  e instalar la versión a la que queremos migrar, con esto la «suite» completa se instalará sin mayor problema. Lo segundo que os recomiendo es ir poco a poco editando todos los ficheros personalizados, para mi la herramienta fundamental es Notepad++ y el «plugin» Compare, ya que nos permite ver las diferencias entre el fichero original y el que hemos personalizado en la vieja instalación de Alfresco, dicho lo cual nos ponemos a reconfigurar nuestro nuevo Alfresco hasta que funcionen las características que personalizamos (https, AD, Kerberos…)

Para esta tarea de personalización nos servirán los tutoriales que prepararé de aquí a diciembre según me quede tiempo (más bien poco), pero si quieres migrar es que ya tienes una instalación, así que de momento puedes ir tirando con lo que ya tienes instalado.

Cuando la base de datos no es posible migrarla y parchearla para la nueva versión de Alfresco, lo mejor es partir de cero y utilizar los ficheros «.ACP», que son los que me salvaron la vida. Básicamente son el «copia/pega» de Alfresco. Entrando como administrador en nuestro servidor iremos a la Consola de Administración donde tenemos las herramientas de exportación. No es excesivamente complicado pero si poco intuitivo porque hemos de ir primero a lo que queremos exportar y luego pinchar el icono de la consola. Si lo hacemos bien veremos por ejemplo:

Desde ahí cuando pulsemos en exportar veremos que tenemos la opción de «Exportar ‘Sitios’ «, y si, es así de sencillo porque podremos marcar que exporte desde el espacio actual incluyendo los hijos, con lo que el ACP tendrá todo el contenido empaquetado y listo para importar en la nueva instalación. No olvides seleccionar un destino que es el lugar del repositorio donde el fichero ACP será situado para que luego puedas rescatarlo vía interfaz web, WebDAV o CIFS.

Todo este proceso sólo tiene un «pequeño» defecto, o al menos yo no di con la tecla adecuada, y es que perdí el versionado de los ficheros y sólo se copió la última versión de cada fichero en la biblioteca de documentos de los respectivos sitios. Sin embargo las reglas se conservaron (con matices) y me supuso muchísimo menos trabajo que haber tenido que regenerar todo el árbol de sitios y ficheros. Eso si, si alguien ha pasado por esta experiencia y ha logrado una migración satisfactoria cuando esa migración no es posible mediante el proceso de «upgrade», somos todo oídos.

Tengo muy claro que para empresas que estén hasta arriba de sitios, espacios personales y demás, pues puede ser un infierno, pero si has tenido la suerte de que la instalación que tenías se ha usado para cuatro cosas mal contadas, al menos podrás disfrutar de tu nueva versión de Alfresco en un plazo razonable. Sólo una curiosidad: pregunté a un consultor experto en Alfresco el coste normal de una migración en una mediana empresa con la versión «Enterprise», y, os sorprenderá saber (o no) que cobran del orden de 10.000 €. Os garantizo que por mucho menos podemos ir poco a poco trasladando por esta vía todo los espacios de datos.

Respecto a los permisos y demás… pues bien, también perdí los usuarios, pero tampoco me preocupaba mucho porque a cambio Kerberos funcionaba a la perfección en el «Share» ¡sin haber tocado nada!, simplemente trasladé la configuración desde una instalación a otra y me sorprendí cuando de repente probando por probar vi que «Share» cogía automáticamente las credenciales (utilizamos Chrome Bussiness). Bastó con mandar una circular interna para que pincharan el enlace (aproveché para utilizar el puerto https estándar ya que no lo tenemos publicado en Internet) y enseguida tuve a todos los usuarios con sus respectivos espacios personales a los que les pude trasladar los datos con facilidad desde el viejo Alfresco.

Para otra ocasión hablaremos del necesario «keystore» y https. Existen varios detalles muy mal documentados a la hora de añadir https, procuraré en una sola entrada resumiros los puntos críticos del proceso, para el resto de cosas ya existe múltiple y variada documentación.