Contenidos, metadatos y las fugas de información

Llevo un tiempo escribiendo algunas cosas sobre seguridad y Alfresco (que iré publicando), una de los temas que más interés me despierta es la fuga de información, concretamente mediante datos que no vemos directamente pero que están ahí, que están en los contenidos, es decir, en los metadatos ocultos (o no tan ocultos) de los ficheros. De esto se ha hablado mucho, por ejemplo en España contamos con Chema Alonso que ha escrito gran cantidad de información al respecto en http://www.elladodelmal.com.

¿Quién no recuerda el famoso “Caso Blair”? Se publicó un fichero sobre la Guerra de Irak y las armas de destrucción masiva y se demostró (mediante los datos ocultos en el fichero) que había sido manipulado por gente de su gabinete y por lo tanto mentía en cuanto a la procedencia de la información. Más información en inglés y en español.

¿De qué estoy hablando? Voy a aclarar algunos conceptos para no liarnos y ponernos en situación.

Cualquier fichero contiene la información del mismo fichero, por ejemplo, un fichero foto.jpg contendrá una imagen, pero también contiene más información que no se ve a simple vista, son los metadatos o propiedades de dicho fichero que nos aportan más información sobre el mismo. En esos metadatos de la foto se pueden ver datos sobre la cámara con la que se ha realizado, fecha en la que se hizo, software con la que se ha editado, una miniatura, información sobre la localización donde se tomó y muchos datos más. Propiedades parecidas también se encuentran en ficheros Adobe PDF, MS Office, Open Office y un largo etcétera. En el caso de ficheros DOC o DOCX incluso podríamos extraer información sobre las personas que lo han editado, nombres de usuario, impresoras donde se ha enviado, recursos compartidos accedidos, etc. Por lo tanto, analizando esas propiedades podemos extraer mucha información valiosa.

Gracias a Google u otros buscadores es muy fácil localizar los ficheros publicados en internet por parte de una organización concreta, tan fácil como buscar algo así: “inurl:dominio.com filetype:pdf”

Hay millones de webs que publican esta información sin tratar previamente, sin saber realmente que información están dejando visible al resto del mundo. Incluso en España está contemplado el borrado o limpieza de esta información en el Esquema Nacional de Seguridad pero tras hacer unos cuantos escaneos de webs españolas de referencia es evidente parece que no tiene mucho éxito.

Fijaros si es importante este concepto que organizaciones como la NSA (National Security Agency de los Estados Unidos) o SANS, han publicado informes sobre los riesgos que supone este problema. Podéis acceder a los mismos aquí:

http://www.nsa.gov/ia/_files/app/pdf_risks.pdf

http://www.sans.org/reading_room/whitepapers/privacy/document-metadata-silent-killer_32974

¿Cómo puedo ver todo esto que comentas? Existen varias herramientas que nos permiten extraer este tipo de datos, analizarlos y poder averiguar cierta información que podrían permitir realizar intrusiones, uso fraudulento de la misma u otras actividades “interesantes”. Voy a enumerar algunas:

FOCA, también con versión online.

libextractor.

Metagoofil.

Exiftool.

Maltego.

Sin lugar a dudas, la más completa y además con sabor español es FOCA, escrita por la empresa Informatica64, tiene una versión gratuita y funciona sobre Windows. Esta herramienta nos permite extraer toda la información oculta en los ficheros, analizarlos y recolectar la información de forma gráfica e intuitiva, incluso puede dibujar un mapa de red con los datos extraídos como direcciones IP o nombres de máquinas. En este enlace se puede ver una conferencia en la DEFCON que es auto explicativa (merece la pena verla entera). Cabe recordar que FOCA nació para hacer auditorías y recolección de datos, y la extracción de metadatos es una de las muchas cosas que hace esta herramienta.

¿Y cómo puedo prevenir este tipo de situaciones? ¿Cómo limpio los archivos que voy a sacar fuera de mi ordenador o que voy a publicar en alguna página en internet? Hay algunas herramientas que nos permiten hacerlo y generalmente es una tarea totalmente manual que debe hacer el usuario por su cuenta (con lo que eso conlleva).

Con OOMetaextractor podemos borrar los metadatos de los documentos de OpenOffice. En el propio MS Office 2007 y versiones superiores hay una opción al guardar que nos permite borrar la información personal, para versiones anteriores hay un plugin que permite hacerlo. En el caso de PDF, para eliminar toda la información interna debemos usar Adobe Acrobat 8.0 o un plugin para versiones anteriores o con la herramienta Exiftool mencionada anteriormente. En ficheros gráficos del tipo JPG, PNG, etc, se puede eliminar algunos de estos datos con Adobe Photoshop o también con Exiftool. Aunque esta herramienta no está orientada precisamente a un usuario final.

Las fotos almacenan esa información en metadatos EXIF, IPTC y otros, los ficheros PDF en XMP, hay muchos más tipos de metadatos en los ficheros, en la web de Exiftool podéis aprender mucho sobre este tema.

Aquí vemos un ejemplo de los datos extraídos de una foto que me han enviado por correo electrónico:

Aquí los metadatos de una presentación en Power Point:

Como veis, en ambos casos hay información muy interesante, en la foto la localización exacta donde se hizo la foto, altitud, el teléfono con el que se hizo la foto, incluso podríamos acceder a la imagen en miniatura si la tuviera (que puede ser algo sorprendente porque puede no ser exactamente igual) y mucha información más. En el fichero PowerPoint podemos ver el usuario que está trabajando actualmente con el fichero, el usuario que lo hizo, fechas de creación, tiempo que se ha tardado en realizar el documento, etc. Toda esta información está muy bien siempre y cuando el usuario quiera que sea pública o que esté disponible, pero generalmente el usuario final no sabe nada de esto ni las consecuencias que puede tener.

Imaginad el impacto que puede tener la publicación de un documento que ha escrito una empresa “amiga” con un RFP y que posteriormente ha publicado otra empresa u organismo, si no se limpian los metadatos se podría demostrar e impugnar una asignación de un proyecto ya que se podría demostrar quien ha escrito el documento y quien lo ha publicado. Eso ocurre y ha ocurrido en muchas ocasiones, por eso esto es muy crítico.

¿Y qué relación tiene todo esto con Alfresco? Gran parte de estos metadatos que residen en múltiples formatos de documentos son utilizados por los extractores de Alfresco para nutrir sus contenidos de información adicional y evitar que el usuario deba rellenar a mano algunos de ellos, esta tarea se hace gracias a las librerías Apache Tika incorporadas en el repositorio. Por lo tanto, si subimos un fichero a Alfresco, se extraen los metadatos más conocidos automáticamente y podemos acceder a ellos en las propiedades de cada contenido, esto no significa que desaparezcan del propio fichero. A efectos de un ECM esto es normal ya que una vez que un fichero está en un ECM éste es el encargado de gestionar la información alrededor del fichero y poder dotar a los contenidos de más información y posibilidades que el propio contenido en si mismo.

En esta captura podemos ver como se muestran las propiedades extraídas (y ahora almacenadas en la BBDD de Alfresco) de una foto:

Entonces ¿qué ocurre si publico mis contenidos en servidores web con acceso público, o si tengo integrado mi portal cuyos contenidos están almacenados en Alfresco? ¿Qué pasa con los metadatos internos de los ficheros que se ponen a disposición de cualquiera en internet pero residen en el repositorio o salen de él?

Eso lo veremos en el próximo artículo, donde explicaré como defendernos de posibles fugas de información mediante metadatos usando Alfresco.

Video del webinar “Novedades en Alfresco 4.0”

Descubre las novedades en Alfresco 4 Enterprise. En este webinar de una hora de duración veremos las nuevas características de la versión 4 de Alfresco Enterprise y varias demos de estas nuevas funcionalidades.

Entre ellas están:

  • Posibilidad de utilizar las herramientas de productividad que deseen (Microsoft Office, Google Docs, iWork de Apple en el iPad, QuickOffice y Adobe Creative Suite) con integración inteligente en Alfresco.
  • Conectarse sin dificultades y publicar contenido de servicios en la nube, tales como YouTube, SlideShare, Twitter, Facebook y Flickr.
  • Mayor facilidad de uso.
  • Características sociales mejoradas y adaptadas a las organizaciones.
  • Despliegue y administración más cómodo.
  • Mejoras en rendimiento, escalabilidad, búsquedas y personalización.

Alfresco 4 continúa aportando seguridad, rendimiento y flexibilidad a las TI necesarios para ofrecer valor a los negocios con importantes mejoras en la indexación, administración y posibilidades de extender.

Recuerda revisar las Release Notes de esta versión, puedes descargarlas del Portal de Soporte de Alfresco en http://support.alfresco.com y también revisar la matriz de compatibilidad de la versión.

Video del webinar “Alfresco Social Publishing Framework”

Desde la versión 4.0 Alfresco incorpora el nuevo Social Publishing Framework que nos permite publicar contenidos en diferentes canales como Facebook, Twitter, Slideshare, Linkedin, Flickr o Youtube. En este webinar vamos a ver como funciona el framework y como podemos ampliarlo en base a nuestras necesidades para otros canales, gracias a la ayuda de nuestro Partner Gold atSistemas. Aprende en este webinar a formar parte del Cloud Connected Content!

Seguridad en las comunicaciones de Alfresco

En este artículo quiero hablar sobre las comunicaciones en Alfresco. Como buenos administradores debemos saber qué puertos utiliza la aplicación de entrada (tráfico inbound: servicios que publica Alfresco) y de salida (tráfico outbound: servicios externos a los que accede Alfresco). De esa forma podemos configurar apropiadamente el firewall local del servidor y también el firewall perimetral de la organización. Otro aspecto a tener en cuenta es la seguridad de los servicios que publicamos, las comunicaciones tipo cliente-servidor y entre capas de una instalación, es decir, la posibilidad de cifrar el tráfico de los servicios que publicamos y de los servicios que se usan entre las capas o entre nodos en caso de cluster.

Listado de puertos, servicios y origen/destino del tráfico

  • En el listado siguiente podemos ver puertos de servicio que se usan o se pueden usar en Alfresco. Posiblemente veréis alguno más de los que pensábais, cuento con que tenemos Alfresco Repository (alfresco.war) y Alfresco Share (share.war) desplegado en el mismo servidor de aplicaciones y la base de datos, LDAP y almacenamiento en servidores remotos, aunque como sabéis, estos servidores también podrían estar en local en caso de desarrollo o pruebas. Todos estos puertos son los que se establecen por defecto, y como veremos, algunos no están activados por defecto:
Protocolo Puerto TCP/UDP IN/OUT Activo Comentarios
HTTP 8080 TCP IN Si Incluye WebDav
FTP 21 TCP IN Si Modo pasivo
SMTP 25 TCP IN No
CIFS 137,138 UDP IN Si
CIFS 139,445 TCP IN Si
IMAP 143 TCP IN No
Share Point  Protocol 7070 TCP IN Si
Tomcat Admin 8005 TCP IN Si
Tomcat AJP 8009 TCP IN Si
SOLR admin 8443 TCP IN Si Hay que instalar cert en navegador
NFS 111,2049 TCP/UDP IN No
Lotus Quickr 6060 TCP IN No
RMI 50500-50507 TCP IN Si Usado por EHCache entre nodos de cluster y para gestión JMX
JGroups 7800 TCP IN No Cluster discovery entre nodos
JGroups 7801-7802 TCP IN No Comunicación Ehcache RMI entre nodos de cluster
OpenOffice 8100 TCP IN Si Sólo en localhost, no hay que abrirlo
  • Como hemos visto, los puertos indicados anteriormente son todos los que podría utilizar Alfresco en una instalación con todas las funcionalidades activadas y en cluster, en una instalación para producción deberemos arrancar el servidor de aplicaciones con un usuario no privilegiado (en caso de Linux), por lo tanto no podremos levantar los puertos por debajo del 1024, deberemos cambiarlos en la configuración para que sean por encima del puerto 1024 y posteriormente hacer una redirección con el firewall local. Aquí podéis ver un ejemplo.
  • Para controlar el tráfico de salida, es decir, la actividad que genera o sistemas a los que se conecta nuestro servidor, deberíamos crear reglas para controlar el tráfico. En muchos casos no sería necesario limitar la información de salida, pero si quieres realmente controlar todo lo que sale del sistema y tus requisitos de seguridad son elevados, controlar el tráfico de salida es vital:
Protocolo Puerto TCP/UDP IN/OUT Activo Comentarios
SMTP 25 TCP OUT No Configurado hacia tu MTA. Usado para enviar notificaciones.
DB – PostgreSQL 5432 TCP OUT Si* Depende de la BBDD usada
DB – MySQL 3306 TCP OUT Si* Depende de la BBDD usada
DB – MS SQL Server 1433 TCP OUT Si* Depende de la BBDD usada
DB – Oracle 1521 TCP OUT Si* Depende de la BBDD usada
DB – DB2 50000 TCP OUT Si* Depende de la BBDD usada
LDAP 396 TCP OUT No Hay que activar autenticación/sincronización
LDAPS 636 TCP OUT No Hay que activar autenticación/sincronización
docs.google.com 443 TCP OUT No
OpenOffice 8100 TCP OUT No Sólo si se usa OpenOffice externo
JGroups 7800-7802 TCP OUT No Entre nodos del cluster
NFS 111,2049 TCP/UDP OUT No Sólo si se usa un almacenamiento NFS remoto para contentstore
Kerberos 88 TCP/UDP OUT No Sólo si tenemos SSO con Kerberos
DNS 53 UDP OUT Si Si queremos que el servidor resuelva nombre
  • Seguro que hay otros puertos de salida a tener en cuenta, he destacado los necesarios para que funcione el servidor. Por ejemplo, habría que permitir el tráfico a servicios remotos de Facebook, Twitter, LinkedIn, Slideshare, Youtube, Flickr o Blogs, en caso de usar el Publishing Framework. En este caso, y dado que los puertos de salida comentados en el listado anterior pueden variar, lo más rápido sería abrir hacia internet todo el tráfico del servidor, capturar el tráfico y analizarlo. Hecho eso podremos abrir realmente el tráfico saliente que necesitamos. Claro, todo ese control de tráfico de salida habría que hacerlo si estás muy obsesionado con la seguridad, ahí tienes ideas.
  • Si usas autenticación externa, contra un LDAP, procura usar la conexión segura LDAPS (puerto 636 TCP).
  • Otro aspecto a tener en cuenta son las personalizaciones que utilizan o consumen información de otros servidores remotos, como es lógico, no está contemplado en el listado anterior.
  • Tampoco está contemplado en las tablas de arriba otros puertos y tráfico saliente con destino a servidores remotos en caso de usar Transfer/Replication Services de Alfresco, FSR (Alfresco File System Receiver), Liferay, Drupal, etc. En el caso del Replication Service es muy recomendable usar HTTPS y no realizar las transferencias con el usuario admin.
  • Recuerda: tener un firewall (o cuatro firewalls) bien configurado no es sinónimo de seguridad, es sólo un proceso continuo más que debemos llevar a cabo para controlar lo que ocurre en nuestras redes y en nuestros servidores.

Cifrado de la información:

Si no usamos cifrado en las comunicaciones, las contraseñas y los contenidos viajan en sin cifrar, por lo que esa información podría ser interceptada y usada sin nuestro consentimiento, con el grave perjuicio que eso conlleva.

Y de los servicios que publica Alfresco ¿cuales puedo hacer seguros? Vamos a ver los más importantes de cara al usuario y dónde consultar para aprender a configurarlos apropiadamente:

  • HTTP -> HTTPS:

De esta forma cifraríamos la comunicación (http y webdav) entre el navegador del usuario hasta Alfresco o hasta el frontal web que proteja al servidor de aplicaciones.

Para hacer seguro el acceso web a Alfresco Share, Explorer y webdav, podríamos hacerlo de tres formas:

  1. Usando un balanceador que soporte SSL offloading, en cuyo caso no se necesita configurar nada en el servidor web o servidor de aplicaciones.
  2. Activando HTTPS en el frontal web (Apache) y conectando a Alfresco por AJP (mod_proxy_ajp) o mod_Jk, en este caso deberíamos desactivar el acceso al puerto 8080 de Alfresco para evitar accesos no cifrados y obligar a los usuarios de la red local que accedan por el frontal web. Más información sobre los conectores aquí y como activar SSL en Apache aquí aunque hay miles de recurso en Internet disponibles para configuralo.
  3. Activando HTTPS en Tomcat o en el servidor de aplicaciones que tengas, para Tomcat también hay muchos recursos disponibles, por ejemplo aquí, y en este blog (sección CONFIGURING SSL FOR ALFRESCO TOMCAT). Si Alfresco Share está en una capa por delante de Alfresco habría que hacer la tarea en el frontal de Share y opcionalmente en el repositorio y cambiar la configuración de Share para el acceso a los puertos SSL del repositorio. Este artículo te ayudará a entender como separar en capas y su configuración.

Otra recomendación interesante en este punto puede ser el uso en el frontal web del módulo de Apache mod_security, que es un Web Application Firewall que permite filtrar y eliminar cierto tráfico malicioso hacia nuestro servidor como tráfico SQL injection o XSS e infinidad de otros ataques. Aquí un buen recursos para aprender a implementarlo:

http://www.jpereira.net/gestion-documental/alfresco-y-apache-proxy-security

  • FTP -> FTPS:

Permitiremos a los usuarios conectar mediante FTP cifrando la autenticación y la transferencia de contenidos. Es importante que el cliente FTP soporte FTPS, algo que la gran mayoría de clientes lo tienen superado. Es muy sencilla su configuración está bien explicada en la documentación oficial.

  • SharePoint -> SharePoint SSL:

Como comenté en el correspondiente webinar, la implementación Share Point de Alfresco se hace mediante un servidor de aplicaciones embebido en Alfresco llamado Jetty, que escucha por el puerto 7070 TCP. La configuración por defecto no está cifrada, de hecho, eso hace que tengamos que “parchear” el registro de Windows de los clientes para que funcione MS Office correctamente, como vimos en el webinar, o lidiar con la solicitud de contraseña varias veces. Si activamos SSL no es necesario modificar el registro en los clientes. Además, recuerda que se usará SSL en el mismo puerto (7070 TCP) y no estará disponible la comunicación no cifrada.

Aquí se pueden ver los pasos a para su activación:

http://docs.alfresco.com/4.0/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Ftasks%2FSharePoint-HTTPS-setup.html

  • SMTP -> SMTP SSL:

Correo saliente (notificaciones):

En este caso si hablamos de la conexión con el MTA de la organización para que Alfresco envíe notificaciones, no hay problema, podemos configurar Alfresco para que se conecte al servidor de correo remoto mediante SMTPS con autenticación y mediante TLS para cifrado. En el blog hablé de esto, puedes ver un ejemplo aquí, aunque en la versión 3.4 y superior es más sencillo, abajo vemos un ejemplo de parámetros para alfresco-global.properties usado con GMail:

[bash]
### Outbound mail SMTP ###
mail.host=smtp.gmail.com
mail.port=465
mail.protocol=smtps
mail.smtps.auth=true
[email protected]
mail.password=Contraseña
mail.encoding=UTF-8
[email protected]
mail.smtp.starttls.enable=true
[/bash]

Correo entrante:

Del correo entrante también hablé aquí. Hasta la versión 4.0 no está soportado SMTP TLS en Alfresco, como puedes ver en este bug reportado en Jira. En la wiki está bien explicado como configurarlo y en docs.alfresco.com también hay información útil.

  • JGroups -> JGroups SSL:

Aunque si usamos interfaces dedicadas para el tráfico entre nodos no sería necesario, JGroups soporta encriptación en el tráfico entre nodos del cluster, aunque en Alfresco no está contemplada esta opción, se podía hacer: http://www.jgroups.org/javadoc/org/jgroups/protocols/ENCRYPT.html

  • IMAP -> IMAPS:

IMAPS (993 TCP) no está soportado por Alfresco, pero se puede poner una capa por delante a modo de proxy e implementarlo. Existen varias soluciones genéricas como stunnel y algunas específicas como PerditionNginx. En este enlace se puede ver más información: https://issues.alfresco.com/jira/browse/ENH-1152

  • SOLR:

En la versión 4.0, que incorpora SOLR, la comunicación entre repositorio y motor de indexación está cifrada y la autenticación también, además es mutua. Todo ese tráfico es HTTPS. Para otro artículo dejo el uso de los keystores por defecto usados para la protección de la comunicación y acceso a SOLR, que este caso usa claves RSA y certificados x.509. Así como para el cifrado de metadatos con la nueva característica de la versión 4.0, el nuevo tipo “d:encrypted” que permite indicar que una propiedad de un nodo se puede cifrar. De cualquier forma podéis encontrar más info aquí.

Persistencia en las credenciales JMX de Alfresco

Aunque esta es una funcionalidad activada y útil sobre todo para Alfresco Enterprise, creo que es una recomendación de seguridad necesaria y a tener muy en cuenta para entornos en producción. Sobre todo si no filtras los puertos con un firewall. Además así evitarás que alguien modifique la configuración de Alfresco.
Vamos a ver cómo cambiar usuarios y contraseñas de acceso JMX por defecto que vienen en Alfresco y que no se sobreescriban cuando actualizamos la versión y siempre tengamos protegido de forma segura el acceso a la consola de configuración y monitorización de Alfresco.
La receta es muy sencilla:
  • Para ello debemos copiar los ficheros alfresco-jmxrmi.access y alfresco-jmxrmi.password que podemos encontrar por defecto en el directorio tomcat/webapps/alfresco/WEB-INF/classes/alfresco/ y los copiamos por ejemplo en tomcat/shared/classes/.
  • Una vez copiados, podemos editarlos y modificarlos a nuestro gusto, los ficheros están muy bien comentados y no dan lugar a dudas.
  • En el fichero alfresco-jmxrmi.access encontramos los nombres de usuario disponibles y el rol asignado:

[bash]
monitorRole   readonly
controlRole   readwrite
[/bash]

  • En el fichero alfresco-jmxrmi.password podemos cambiar la contraseña de cada uno de los usuarios disponibles:

[bash]
monitorRole  mi-nuevo-password1
controlRole  mi-nuevo-password2
[/bash]

  • Por último deberemos añadir la siguiente linea en alfresco-global.properties y reiniciar el servidor de aplicaciones:

[bash]
alfresco.jmx.dir=/directorio/instalacion/tomcat/shared/classes
[/bash]

Por lo tanto, usaríamos el usuario monitorRole para monitorización (aplicaciones externas como Hyperic o Nagios) y el usuario controlRole para acceder mediante jconsole y configurar Alfresco. De eso ya hablé aquí.

Video del webinar “Soluciones de escaneo con Alfresco”

Ya está disponible el video del webinar que hice con la colaboración de Baratz, partner de Alfresco en España. Hablamos de las diferentes opciones de integración con sistemas de escaneo y digitalización, OCR, clasificación, revisión, volcado, mapeo de metadatos, etc. Un webinar muy interesante y creo que bastante ilustrativo sobre las opciones que tenemos con Alfresco y una demo de Ephesoft.

Algunos apuntes sobre Lucene en el mundo de Alfresco

En este artículo quiero hablaros de Lucene. Aunque en la versión 4.0 de Alfresco ya se incorpora SOLR como motor de indexación alternativo y escalable, también se puede seguir usando Lucene. Además, existen multitud de instalaciones que utilizan Lucene y que posiblemente seguirán utilizándolo. Voy a ampliar algunos conceptos al respecto para intentar ayudaros a comprender cómo funciona y cómo solucionar posibles problemas que nos podemos encontrar.
  • NOTA/DISCLAIMER: Lo que aprendas en este artículo no lo uses en producción salvo que sepas realmente lo que estás haciendo. No me hago responsable de los problemas que puedas tener derivados de este artículo 😉
Empecemos por el principio, el documento. Hay dos partes de un documento en Alfresco, la primera es el documento por si mismo y su contenido, la segunda son los metadatos asociados a ese documento. Por defecto, se indexan esas dos partes de un documento, por eso podemos buscarlos y localizarlos. Esta es una explicación simple ya que por debajo hay una serie de tareas automáticas y un poco más complejas que la descripción anterior. Vamos a verlo.
  • En Alfresco puedes buscar información mediante las interfaces web Share o Explorer y también mediante las diferentes APIs disponibles. Las búsquedas pueden ser por palabras clave o búsquedas booleanas, Alfresco las traduce a formato Lucene Query y las ejecuta sobre los índices en su instancia de Alfresco.
  • ¿Cómo puedo saber que hay realmente en los índices de Alfresco? Los índices por defecto se almacenan en un directorio llamado “lucene-indexes” dentro del directorio “alf_data“. Dentro del directorio principal de índices hay más carpetas y ficheros que están relacionados con los índices de los que no podemos ver su contenido directamente ya que son binarios y de los que hablaremos más adelante.
  • Puedes ver el contenido de esos ficheros con una herramienta de debug muy útil y multiplataforma llamada Luke. Para abrir los índices por ejemplo del workspace/Spacestore, en el browser de Luke navega hasta alf_data/lucene-indexes/workspace/SpacesStore y selecciona el fichero IndexInfo. Luke te permite abrir los índices con la opción “Open in Read Only mode”, úsala. Ya que con Luke puedes hacer tareas de lectura sobre los índices y también ¡borrados! Lee bien la documentación antes de aventurarte a hacer alguna fechoría con esta herramienta. No es el objetivo de este artículo hacer un manual de Luke, simplemente darlo a conocer si no lo conocías ya. Si lo usas y lo dominas puedes escribir un artículo que será muy útil para todos.

Sigamos con los índices. Veamos qué hace Alfresco de forma genérica cuando se sube un documento o se actualiza:
Como vemos en la imagen anterior, a ese diagrama global podríamos añadir el siguiente resumen del proceso de indexación:
  • 1º Se transforma el contenido a texto
  • 2º Se usa un analizador basado en el idioma del documento para extraer cadenas derivadas de plurales, mayúsculas, etc. Dependiendo del idioma, estos analizadores serán más o menos complejos.
  • 3º Lucene indexa los metadatos que están marcados para ser indexados.
  • 4º Lucene indexa el contenido, que sea susceptible de indexar (por ejemplo un documento, si se trata de un binario como una imagen no se indexa el contenido). La indexación del contenido se podría desactivar.
  • 5º Si se trata de una actualización, la versión anterior se mueve a otro directorio (interno de los índices) y la nueva versión se crea en el índice activo (live index).
Hay tres directorios que afectan a los índices y que se pueden configurar en alfresco-global.properties mediante las siguientes propiedades (recuerda que se configuraría usando propiedad=valor y todas las opciones está disponibles en el fichero alfresco/WEB-INF/classes/alfresco/repository.properties):
  • dir.idexes y dir.indexes.lock que necesitan estar en los discos locales donde se instala el repositorio (alfresco.war), ya que se hace un uso intensivo de I/O de disco.
  • dir.indexes.backup podemos ubicarlo donde queramos siempre que esté accesible por el servidor, ahí se almacenan los backups automáticos nocturnos a las 3AM cada día. Aunque también se puede ejecutar manualmente mediante JMX en la versión Enterprise. Si quieres saber qué procesos nocturnos afectan a los índices y cómo, lee este artículo. No tener controlados los backups de los índices te pueden llevar a tener que reindexar todo un repositorio completo, que puede llevar varios días dependiendo de la cantidad de contenidos.
Dentro del directorio dir.indexes hay una serie de directorios que corresponden a cada uno de los stores de Alfresco (más info aquí). Cada directorio o subdirectorio contiene un fichero llamado IndexInfo que nos da información sobre los índices de cada uno de los stores.
La indexación de los contenidos se gestionan mediante el modelo de datos, por defecto se utiliza el siguiente fichero alfresco/WEB-INF/classes/alfresco/model/contentModel.xml. Y las opciones para todos los contenidos, si no tenemos ningún tipo adicional es como sigue:

[xml]
<type name="cm:content">
<title>Content</title>
<parent>cm:cmobject</parent>
<properties>
<property name="cm:content">
<type>d:content</type>
<mandatory>false</mandatory>
<index enabled="true">
<atomic>false</atomic>
<stored>false</stored>
<tokenised>true</tokenised>
</index>
</property>
</properties>
</type>
[/xml]

A este respecto, cuando un documento se sube a Alfresco, los metadatos se extraen y se indexan en el acto, pero el contenido no tiene por que ser indexado en ese momento (depende). Veremos más abajo que significan estas opciones y qué nos aportan.
Como vemos en la parte <index enabled=”true”>, hay diferentes opciones en cuanto a los índices de las propiedades o de los contenidos:
  • Enabled=”false”: Si está a “false” no se indexará esa propiedad.
  • Atomic=”true”: Si está a “true”, esa propiedad (metadato) es indexada en el momento de la transacción, si está a “false”, se indexará en background. La indexación de contenidos que necesitan transformación antes de ser indexados (p. ej. PDF), solo serán “atomic=true” si la transformación tarda menos tiempo que el valor especificado en el atributo lucene.maxAtomicTransformationTime. Todos los transformadores por defecto están aquí alfresco/WEB-INF/classes/alfresco/services-context.xml.
  • Stored=”true”: Si está a “true”, el valor de la propiedad se almacenará en el índice y debe ser consultado mediante la API de bajo nivel de Lucene. Esto es útil para debugging si queremos saber qué es exactamente lo que se está indexando, pero no está recomendado en absoluto para producción ya que escribe mucha más información en disco. Recomendado “false”.
  • Tokenised=”true”: Si está “true”, el valor de la cadena de la propiedad se tokeniza antes de ser indexado. Si está a “false”, se indexará como una única cadena, si está a “both” se harán las dos opciones. Valor recomendado “true”.
Recuerda que por defecto todo el contenido, si se indexa, es “not stored”, indexed y tokenized.
  • Si quieres cambiar el comportamiento por defecto puedes hacerlo pero deberás reindexar todos los contenidos tras hacer el cambio. No te recomiendo tocar el modelo por defecto, es mejor hacer el tuyo propio y heredar valores o no, dependiendo de las necesidades que tengas. Recuerda que si haces un tipo que herede del tipo raíz “cm:content” no podrás desactivar el indexado del contenido.
  • Por defecto, las versiones de un documento (que se almacenan en el store workspace://version2Store) no se indexan. Ese comportamiento se podría modificar modificando el fichero core-services-context.xml como se puede ver aquí, referenciando la entrada version2Store al bean avmLuceneIndexerAndSearcherFactory igual que se pueden ver el workspace y el avm. Si lo haces recuerda que tendrás un consumo mucho más elevado de disco en los índices (dependerá del número de versiones que tengas por contenido, si no lo controlas bien no lo hagas, puede ser una bomba). Aunque actives la indexación del store de versiones, los formularios de búsqueda de Share o Explorer no buscarán en version2Store, pero se puede usar la API para realizar la búsqueda.
En cuanto a la recuperación de índices, es importante saber que existen cuatro modos FULL, AUTO, VALIDATE y NONE, que se usan en alfresco-global.properties mediante el atributo index.recovery.mode.
  • index.recovery.mode=FULL: Borra todos los índices actuales y genera un nuevo índice de todo el contenido (reindexa), durante este proceso el servidor no estará disponible.
  • index.recovery.mode=AUTO: Comprueba los primeros y últimos 1000 identificadores de transacción (txn) son válidos en cada store (información en la BBDD y en los índices coincide). Si no son válidos, se realizará una indexación FULL. En un cluster es importante tener sincronizados horariamente los servidores porque de lo contrario se lanzarán las reindexaciones al no coincidir la BBDD con los índices y la hora del servidor.
  • index.recovery.mode=VALIDATE: Comprueba los primeros y últimos 1000 identificadores de transacción (txn) son válidos en cada store (información en la BBDD y en los índices coincide). Si no son válidos, simplente devolverá una excepción.
  • index.recovery.mode=NONE: No se hace ningún tipo de validación en los índices.
Como vemos, los índices son muy importantes para Alfresco, tanto que si al arrancar encuentra algún problema grave en ellos, que no se solucione reindexando, el servidor se parará automáticamente. Este comportamiento se controla mediante el valor system.bootstrap.config_check.strict que por defecto está a “true”, podríamos ponerlo a “false” para poder analizar mejor algún problema concreto del que no tenemos mucha información en los logs (úsalo sólo para debug, afecta a otras opciones de configuración) y que evita que Alfresco arranque totalmente.
Al principio decía que los índices deben estar en discos locales (lo más rápidos disponibles y dedicados si es posible) para garantizar el máximo rendimiento de la aplicación. Para evitar problemas de lentitud es recomendable tener el doble del tamaño del índice total como espacio libre, para evitar problemas en caso de reindexación y sobre todo para el merge de los índices que se realiza a menudo. De hecho si compruebas que la subida de ficheros es muy lenta comprueba que tienes suficiente espacio libre en la partición o disco de los índices y que tienes correctamente configurados los file descriptors del sistema operativo (ver este artículo).
En caso de reindexación FULL podrás ver en los logs trazas como las siguientes:

[bash]
20:33:02,502 INFO [node.index.FullIndexRecoveryComponent] 100 % complete.
20:33:55,753 INFO [node.index.FullIndexRecoveryComponent] Index recovery completed.
[/bash]

Eso no significa que se hayan reindexado todos los contenidos, sólo nos indica que se han reindexado todas las propiedades (metadatos). A partir de ese momento Alfresco se pondrá a reindexar el contenido de los documentos. ¿Como podemos comprobar que está ocurriendo eso? Viendo la actividad en la CPU que puede provocar OpenOffice, ya que éste es utilizado para transformar ficheros MS Word a texto para poder ser indexados, por ejemplo.
Aunque ya lo comenté un poco en este artículo, quiero recordaros que existe el “Adminstrador de índices” o “Index Checker Console” disponible en la versión Enterprise desde la 3.1, puedes encontrarlo aquí: http://localhost:8080/alfresco/service/enterprise/admin/indexcheck. Esta consola te permite:
  • a) Comprobar los índices: por ejemplo, comprobar que cada transacción realizada por el repositorio está contemplada en los índices. Se puede comprobar por rangos de tiempo o rangos de transacciones.
  • b) Comprobar que un nodeRef específico o los nodos de una transacción específica están en el índice.
  • c) Reindexar desde un punto concreto hacia delante.
  • d) Comprobar el estado de sincronización de los índices entre transacciones y identificadores.
Bueno, esto ha sido todo, seguro que se quedan muchas cosas en el tintero pero espero que estos tips os resulten útiles e interesantes.

Eventos de Alfresco en español en diciembre y principios de 2012

Como suele ser habitual, publicamos los próximos eventos de Alfresco en España y en español (salvo que vengan invitados de fuera). Todos estos eventos, ya sean presenciales (talleres expertos) o remotos (webinars), son gratuitos. ¡Nos vemos o nos oímos!

14 DIC: Soluciones de escaneo con Alfresco – con Baratz
Horario: a las 4pm hora de España (CET)
Registro aquí.

  • ¿Cómo podemos usar Alfresco con un sistema de escaneo? ¿Y el OCR? Hay muchas formas de integrarlo con aplicaciones como Ephesoft, Kofax u otras, e incluso directamente con escaners multifunción. Descubriremos cómo funciona y qué opciones tenemos para gestionar un sistema completo de digitalización.¿Cómo podemos usar Alfresco con un sistema de escaneo? ¿Y el OCR? Hay muchas formas de integrarlo con aplicaciones como Ephesoft, Kofax u otras, e incluso directamente con escaners multifunción. Descubriremos cómo funciona y qué opciones tenemos para gestionar un sistema completo de digitalización.

25 ENE: Alfresco y SOLR
Horario: a las 4pm hora de España (CET)

Registro aquí.

  • SOLR es el nuevo motor de indexación que incorpora Alfresco en su versión 4.0, no obstante, se puede seguir usando Lucene. Vamos a aprender qué es SOLR, cómo funciona y cómo está soportado, como configurarlo y migrar de Lucene a Solr, qué efectos tiene en el repositorio y que mejoras nos aporta.

1 FEB: Alfresco Social Publishing Framework – con atSistemas

Horario: a las 4pm hora de España (CET)
Registro aquí.

  • Desde la versión 4.0 Alfresco incorpora el nuevo Social Publishing Framework que nos permite publicar contenidos en diferentes canales como Facebook, Twitter, Slideshare, Linkedin, Flickr o Youtube. En este webinar vamos a ver como funciona el framework y como podemos ampliarlo en base a nuestras necesidades.

15 FEB: Fred – Integración de Alfresco para el escritorio – con Xenit
Horario: a las 4pm hora de España (CET)
Registro aquí.

  • Fred es una aplicación de escritorio que acerca Alfresco al ambiente de trabajo diario de sus usuarios. Reducimos en un 50% o más el tiempo de las tareas más comunes que se realizan sobre documentos. Uno puede arrastrar y soltar (drag and drop) documentos, e-mails y adjuntos desde y hacia Fred. Los metadatos pueden ser agregados en muy poco tiempo. Fred ofrece además soporte para sofisticados agrupamientos y filtros durante la búsqueda de carpetas y documentos. En este webinar veremos una demo de Fred y revisión de las nuevas características de la próxima versión.

14 MAR: Consejos de Seguridad con Alfresco
Horario: a las 4pm hora de España (CET)
Registro aquí.

  • Cuanta más información almacenamos en Alfresco, más necesidades de protegerla tenemos. En este webinar haremos un repaso sobre los consejos de seguridad más importantes a tener en cuenta en Alfresco, tanto a nivel de aplicación como a nivel de servidor, red e intrusiones.

15 DIC: Taller Experto (Madrid)
Horario de 9:30 a 14h
Registro aquí.

18 ENE: Taller Experto (Bilbao)
Horario de 9:30 a 14h
Registro aquí.

8 FEB: Taller Experto (Madrid)
Horario de 9:30 a 14h
Registro aquí.

21 MAR: Taller Experto (Barcelona)
Horario de 9:30 a 14h
Registro aquí.