Tag: enterprise applications

Buenas Prácticas de Seguridad en Docker

Toni de la Fuente Leave a comment
DockerLogoNota: Este artículo lo escribí para SecurityByDefault.com el 18/05/2015, espero que lo disfrutéis.
Docker es una plataforma abierta que permite construir, portar y ejecutar aplicaciones distribuidas, se basa en contenedores que corren en Linux y funcionan tanto en máquinas físicas como virtuales simplemente usando un runtime. Está escrito en Go y usa librerías del sistema operativo así como funcionalidades del kernel de Linux en el que se ejecuta. Consta de un engine con API RESTful y un cliente que pueden ejecutarse en la misma máquina o en máquinas separadas. Es Open Source (Apache 2.0) y gratuito.
Los contenedores existen desde hace muchos años, Docker no ha inventado nada en ese sentido, o casi nada, pero no hay que quitarles mérito, están en el momento adecuado y aportan las características y herramientas concretas que se necesitan en la actualidad, donde la portabilidad, escalabilidad, alta disponibilidad y los microservicios en aplicaciones distribuidas son cada vez más utilizados, y no sólo eso, sino que también son mejor entendidos por la comunidad de desarrolladores y administradores de sistemas. Cada vez se desarrollan menos aplicaciones monolíticas y más basadas en módulos o en microservicios, que permiten un desarrollo más ágil, rápido y a la vez portable. Empresas de sobra conocidas como Netflix, Spotify o Google e infinidad de Start ups usan arquitecturas basadas en microservicios en muchos de los servicios que ofrecen.
Te estarás preguntando ¿Y no es más o menos lo mismo que hacer un chroot de una aplicación? Sería como comparar una rueda con un coche. El concepto de chroot es similar ya que se trata de aislar una aplicación, pero Docker va mucho más allá, sería un chroot con esteroides, muchos esteroides. Por ejemplo, puede limitar y controlar los recursos a los que accede la aplicación en el contenedor, generalmente usan su propio sistema de archivos como UnionFS o variantes como AUFS, btrfs, vfs, Overlayfs o Device Mapper que básicamente son sistemas de ficheros en capas. La forma de controlar los recursos y capacidades que hereda del host es mediante namespaces y cgroups de Linux. Esas opciones de Linux no son nuevas en absoluto, pero Docker lo hace fácil y el ecosistema que hay alrededor lo ha hecho tan utilizado.
Adicionalmente, la flexibilidad, comodidad y ahorro de recursos de un contenedor es mayor a la que aporta una máquina virtual o un servidor físico, esto es así en muchos casos de uso, no en todos. Por ejemplo, tres servidores web para un cluster con Nginx en una VM con una instalación de Linux CentOS mínima ocuparía unos 400MB, multiplicado por 3 máquinas sería total de uso en disco de 1,2 GB, con contenedores serían 400MB las mismas 3 máquinas corriendo ya que usa la misma imagen para múltiples contenedores. Eso es sólo por destacar una característica interesante a nivel de recursos. Otro uso muy común de Docker es la portabilidad de aplicaciones, imagina una aplicación que solo funciona con Python 3.4 y hacerla funcionar en un sistema Linux con Python 2.x es complicado, piensa en lo que puede suponer en un sistema en producción actualizar Python, con contenedores sería casi automático, descargar la imagen del contenedor y ejecutar la aplicación de turno.
Solo por ponernos en situación de la envergadura Docker, unos números alrededor del producto y la compañía (fuente aquí):
  • 95 millones de dólares de inversión.
  • Valorada en 1.000 millones de dólares.
  • Más de 300 millones de descargas en 96 releases desde marzo de 2013
Pero un contenedor no es para todo, ni hay que volverse loco “dockerizando” cualquier cosa, aunque no es este el sitio para esa reflexión. Al cambiar la forma de desarrollar, desplegar y mantener aplicaciones, también cambia en cierto modo la forma de securizar estos nuevos actores.
Docker aporta seguridad en capas, aísla aplicaciones entre ellas y del host sin usar grandes recursos, también se pueden desplegar contenedores en máquinas virtuales lo que aporta otra capa adicional de aislamiento (estaréis pensando en VENOM pero eso es otra película que no afecta directamente a Docker). Dada la arquitectura de Docker y usando buenas prácticas, aplicar parches de seguridad al anfitrión o a aplicaciones suele ser más rápido y menos doloroso.
Buenas Prácticas de Seguridad:
Aunque la seguridad es algo innato en un contenedor, desde Docker Inc. están haciendo esfuerzos por la seguridad, por ejemplo, contrataron hace unos meses a ingenieros de seguridad de Square, que no son precisamente nuevos en el tema. Ellos, junto a compañías como VMware entre otras, han publicado recientemente un extenso informe de sobre buenas prácticas de seguridad en Docker en el CIS. Gracias a este informe tenemos acceso a más de 90 recomendaciones de seguridad a tener siempre en cuenta cuando vamos a usar Docker en producción. En la siguiente tabla podemos ver las recomendaciones de seguridad sugeridas, algunas son muy obvias pero un check list así nunca viene mal:
1. Recomendaciones a nivel de host
1.1. Crear una partición separada para los contenedores 
1.2. Usar un Kernel de Linux actualizado 
1.3. No usar herramientas de desarrollo en producción
1.4. Securizar el sistema anfitrión 
1.5. Borrar todos los servicios no esenciales en el sistema anfitrión
1.6. Mantener Docker actualizado 
1.7. Permitir solo a los usuarios autorizados controlar el demonio Docker
1.8. Auditar el demonio Docker  (auditd)
1.9. Auditar el fichero o directorio de Docker – /var/lib/docker 
1.10. Auditar el fichero o directorio de Docker – /etc/docker 
1.11. Auditar el fichero o directorio de Docker – docker-registry.service 
1.12. Auditar el fichero o directorio de Docker – docker.service 
1.13. Auditar el fichero o directorio de Docker – /var/run/docker.sock 
1.14. Auditar el fichero o directorio de Docker – /etc/sysconfig/docker 
1.15. Auditar el fichero o directorio de Docker – /etc/sysconfig/docker-network 
1.16. Auditar el fichero o directorio de Docker – /etc/sysconfig/docker-registry 
1.17. Auditar el fichero o directorio de Docker – /etc/sysconfig/docker-storage 
1.18. Auditar el fichero o directorio de Docker – /etc/default/docker 
 
2. Recomendaciones a nivel de Docker Engine (daemon)
2.1 No usar el driver obsoleto de ejecución de lxc 
2.2 Restringir el tráfico de red entre contenedores 
2.3 Configurar el nivel de logging deseado 
2.4 Permitir a Docker hacer cambios en iptables 
2.5 No usar registros inseguros (sin TLS)
2.6 Configurar un registro espejo local
2.7 No usar aufs como driver de almacenamiento
2.8 No arrancar Docker para escuchar a  una IP/Port o Unix socket diferente
2.9 Configurar autenticación TLS para el daemon de Docker
2.10 Configurar el ulimit por defecto de forma apropiada

3. Recomendaciones a nivel de configuración de Docker
3.1 Verificar que los permisos del archivo docker.service están como root:root 
3.2 Verificar que los permisos del archivo docker.service están en 644 o más restringidos 
3.3 Verificar que los permisos del archivo docker-registry.service están como root:root 
3.4 Verificar que los permisos del archivo docker-registry.service están en 644 o más restringidos
3.5 Verificar que los permisos del archivo docker.socket están como root:root 
3.6 Verificar que los permisos del archivo docker.socket están en 644 o más restringidos
3.7  Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están como root:root 
3.8 Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están en 644 o más restringidos
3.9 Verificar que los permisos del archivo /etc/sysconfig/docker-network (si se usa systemd) están como root:root 
3.10 Verificar que los permisos del archivo /etc/sysconfig/docker-network están en 644 o más restringidos
3.11  Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están como root:root
3.12 Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están en 644 o más restringidos
3.13 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están como root:root 
3.14 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están en 644 o más restringidos 
3.15 Verificar que los permisos del directorio /etc/docker están como root:root 
3.16 Verificar que los permisos del directorio /etc/docker están en 755 o más restrictivos 
3.17 Verificar que los permisos del certificado del registry están como root:root 
3.18 Verificar que los permisos del certificado del registry están en 444 o más restringidos 
3.19 Verificar que los permisos del certificado TLS CA están como root:root 
3.20 Verificar que los permisos del certificado TLS CA están en 444 o más restringidos 
3.21 Verificar que los permisos del certificado del servidor Docker están como root:root 
3.22 Verificar que los permisos del certificado del servidor Docker están en 444 o más restringidos 
3.23 Verificar que los permisos del archivo de clave del certificado del servidor Docker están como root:root 
3.24 Verificar que los permisos del archivo de clave del certificado del servidor Docker están en 400 
3.25 Verificar que los permisos del archivo de socket de Docker están como root:docker 
3.26 Verificar que los permisos del archivo de socket de Docker están en 660 o más restringidos 
 
4 Imágenes de Contenedores y Dockerfiles
4.1 Crean un usuario para el contenedor
4.2 Usar imágenes de confianza para los contenedores 
4.3 No instalar paquetes innecesarios en el contenedor
4.4 Regenerar las imágenes si es necesario con parches de seguridad
 
5 Runtime del contenedor
5.1 Verificar el perfil de AppArmor (Debian o Ubuntu) 
5.2 Verificar las opciones de seguridad de SELinux (RedHat, CentOS o Fedora) 
5.3 Verificar que los contenedores esten ejecutando un solo proceso principal
5.4 Restringir las Linux Kernel Capabilities dentro de los contenedores 
5.5 No usar contenedores con privilegios   
5.6 No montar directorios sensibles del anfitrión en los contenedores
5.7 No ejecutar ssh dentro de los contenedores
5.8 No mapear puertos privilegiados dentro de los contenedores
5.9 Abrir solo los puertos necesarios en un contenedor
5.10 No usar el modo “host network” en un contenedor 
5.11 Limitar el uso de memoria por contenedor 
5.12 Configurar la prioridad de uso de CPU apropiadamente 
5.13 Montar el sistema de ficheros raíz de un contenedor como solo lectura
5.14 Limitar el tráfico entrante al contenedor mediante una interfaz específica del anfitrión
5.15 Configurar la política de reinicio ‘on-failure’ de un contenedor a 5 
5.16 No compartir PID de procesos del anfitrión con contenedores
5.17 No compartir IPC del anfitrión con contenedores 
5.18 No exponer directamente dispositivos del anfitrión en contenedores
5.19 Sobre-escribir el ulimit por defecto en tiempo de ejecución solo si es necesario
 
6 Operaciones de Seguridad en Docker
6.1 Realizar auditorías de seguridad tanto en el anfitrión como en los contenedores de forma regular
6.2 Monitorizar el uso, rendimiento y métricas de los contenedores
6.3 Endpoint protection platform (EPP) para contenedores (si las hubiese) 
6.4 Hacer Backup de los datos del contenedor 
6.5 Usar un servicio centralizado y remoto para recolección de logs
6.6 Evita almacenar imágenes obsoletas, sin etiquetar correctamente o de forma masiva.   
6.7 Evita almacenar contenedores obsoletos, sin etiquetar correctamente o de forma masiva.
En algunos casos, hay recomendaciones que merecen un artículo por si solas. Si quieres profundizar más en este tema recuerda que los pormenores de estos aspectos de seguridad y auditoría los ampliaremos durante el curso online “Hardening de Windows, Linux e Infraestructuras” en el que colaboraré junto a Lorenzo Martínez, Yago Jesús, Juan Garrido y Pedro Sanchez, todo un lujo de curso en el que aportaré mi granito de arena con seguridad en Docker completando el módulo de Hardening Linux. Más información aquí: https://www.securizame.com/curso-online-de-hardening-de-sistemas-windows-y-linux-e-infraestructuras_yj/
Para otros posibles artículos en el futuro me parece interesante ver algunas consideraciones de seguridad en Docker Hub y otros componentes relacionados, así como auditorías de contenedores con Lynis.
Recursos y referencias:

 

Deploying an Alfresco cluster in Amazon AWS in just minutes

Toni de la Fuente 7 Comments

I have been playing with Amazon Web Services since few months ago. AWS is for a SysAdmin like Disneyland is for a 8 years old child, I enjoy so much doing this kind of stuff.
If you are not familiar with AWS products/services, let me describe with Amazon words and in my own words what are the most important services and concepts we have been using for deploying an Alfresco on-premise installation in AWS:

  • EC2: virtual servers in the cloud.
  • VPC: isolated cloud resources. Yes, a real isolated cloud architecture and resources.
  • S3: Scalable storage, like a CAS (Content Addressable Storage) for your local or cloud servers.
  • RDS: Managed Relational Database Service (MySQL, Oracle or MS SQL Server).
  • ELB: Elastic Load Balancer, as part of EC2 allows you to create load balancers easily.
  • CloudFormation: Templated AWS resource creation. *This is why I’m writing this article. A CloudFormation template is a json file which creates a wizard and options based in our needs.
  • AWS Region: a location with multiples AZ .
  • AZ: Availability Zone (data centers connected through low-latency links in the same region).

Once said so, my colleague Luis Sala has been working together with the Amazon AWS crew and they have made a CloudFormation template to deploy an Alfresco cluster in just minutes. This template is available here: https://github.com/AlfrescoLabs/alfresco-cloudformation.

This CloudFormation template will create a 2 nodes Alfresco cluster inside a virtual private cloud (VPC), a Load Balancer (ELB) with sticky sessions bases on the Tomcat JSESSIONID, a shared ContentStore based on S3, a shared MySQL DB based on a RDS instance. Each Alfresco node will be in a separate Availability Zone and finally the template includes auto-scaling roles for add extra Alfresco nodes when some thresholds are reached.

We will have something like the diagram below, I say “like this” because we will have only 2 Alfresco nodes in the cluster and the auto-scaling will add more nodes in case of thresholds are reached (clic to see it bigger).

aws-cf-alfresco

Finally in the video below you can see step by step a real CloudFormation deployment, I think the video screencast is self-explanatory, it does not have audio. As you can see, the video is 6 minutes length after cropping some dead times but it was around 15 minutes total.

I thought it is a very interesting approach about Alfresco clustering and it worth it to share with you all. Any question or feedback is welcome, even in spanish or english 😉

OpenDJ (LDAP Server) and how to configure with Alfresco for your best demos

Toni de la Fuente 2 Comments

OpenDJ is a fork of the former Sun OpenDS. Is a free and Open Source LDAPv3 server. It is not under our Alfresco Supported Platforms umbrella but it works fine for demo porpuses and is very easy to install, configure and maintain. Since OpenDJ is a Java application you can run it in Linux, Mac or “even” Windows 😉

Lets see how how to start with OpenDJ from scratch.

  • Installation and configuration of OpenDJ:

Download the application downloader and launcher here: http://download.forgerock.org/downloads/opendj/20130305020001/install/QuickSetup.jnlp (you may also download the entire package from here http://www.forgerock.org/opendj.html  but I think with QuickSetup is the easier way)

Download this initial LDIF file with demo users and groups for the first population of our new brand LDAP server.

You must have installed Java in your system in order to execute file QuickSetup.jnlp. Then double click to open it. And follow as in the video:

Now lets configure our Alfresco Server (I did all this steps with Alfresco Enterprise 4.1.3 but should be valid for any 4.X version).

  •  Alfresco configuration:

[bash]
# vi tomcat/shared/classes/alfresco-global.properties
[/bash]

Add next line with our new authentication system before the default chain.

[bash]
authentication.chain=ldap1:ldap,alfrescoNtlm1:alfrescoNtlm
[/bash]

Create the needed directory for our new settings:

[bash]
# mkdir -p tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1
[/bash]

Create your own config file, set as your needs:

[bash]
vi tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties
[/bash]

File:

[bash]
ldap.authentication.active=true
ldap.authentication.allowGuestLogin=false
ldap.authentication.userNameFormat=uid=%s,ou=people,dc=alfresco,dc=com
ldap.authentication.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
ldap.authentication.java.naming.provider.url=ldap://localhost:1389
ldap.authentication.java.naming.security.authentication=simple
ldap.authentication.escapeCommasInBind=false
ldap.authentication.escapeCommasInUid=false
ldap.authentication.defaultAdministratorUserNames=
ldap.synchronization.active=false
ldap.synchronization.java.naming.security.authentication=simple
ldap.synchronization.java.naming.security.principal=cn\=Directory Manager
ldap.synchronization.java.naming.security.credentials=secret
ldap.synchronization.queryBatchSize=0
ldap.synchronization.attributeBatchSize=0
ldap.synchronization.groupQuery=(objectclass\=groupOfNames)
ldap.synchronization.groupDifferentialQuery=(&(objectclass\=groupOfNames)(!(modifyTimestamp<\={0})))
ldap.synchronization.personQuery=(objectclass\=inetOrgPerson)
ldap.synchronization.personDifferentialQuery=(&(objectclass\=inetOrgPerson)(!(modifyTimestamp<\={0})))
ldap.synchronization.groupSearchBase=ou\=groups,dc\=alfresco,dc\=com
ldap.synchronization.userSearchBase=ou\=people,dc\=alfresco,dc\=com
ldap.synchronization.modifyTimestampAttributeName=modifyTimestamp
ldap.synchronization.timestampFormat=yyyyMMddHHmmss’Z’
ldap.synchronization.userIdAttributeName=uid
ldap.synchronization.userFirstNameAttributeName=givenName
ldap.synchronization.userLastNameAttributeName=sn
ldap.synchronization.userEmailAttributeName=mail
ldap.synchronization.userOrganizationalIdAttributeName=o
ldap.synchronization.defaultHomeFolderProvider=largeHomeFolderProvider
ldap.synchronization.groupIdAttributeName=cn
ldap.synchronization.groupDisplayNameAttributeName=description
ldap.synchronization.groupType=groupOfNames
ldap.synchronization.personType=inetOrgPerson
ldap.synchronization.groupMemberAttributeName=member
ldap.synchronization.enableProgressEstimation=true
ldap.authentication.java.naming.read.timeout=0
[/bash]

To have a full control about what is happening during the LDAP authentication add next lines to your custome log configuration file like next one. If you don’t have a custom log file already you can create it:

[bash]
cp tomcat/webapps/alfresco/WEB-INF/classes/log4j.properties tomcat/shared/classes/alfresco/extension/custom-log4j.properties
[/bash]

Add next options to the file:

[bash]
vi tomcat/shared/classes/alfresco/extension/custom-log4j.properties
[/bash]

Content:

[bash]
# LDAP
log4j.logger.org.alfresco.repo.importer.ImporterJob=debug
log4j.logger.org.alfresco.repo.importer.ExportSourceImporter=debug
log4j.logger.org.alfresco.repo.security.authentication.ldap=debug
[/bash]

Now reboot and try. Also you can do that easily and without reboot using JMX with console

Remember to keep watching your logs:

[bash]
tail -f tomcat/logs/catalina.out
[/bash]

When Alfresco is starting after our changes, you must see something like this:

[bash]
2013-03-07 09:46:26,175  INFO  [management.subsystems.ChildApplicationContextFactory] [main] Starting ‘Authentication’ subsystem, ID: [Authentication, managed, ldap1]
2013-03-07 09:46:26,212  WARN  [authentication.ldap.LDAPInitialDirContextFactoryImpl] [main] LDAP server supports anonymous bind ldap://localhost:1389
2013-03-07 09:46:26,234  INFO  [authentication.ldap.LDAPInitialDirContextFactoryImpl] [main] LDAP server does not support simple string user ids and invalid credentials at ldap://localhost:1389
2013-03-07 09:46:26,235  INFO  [authentication.ldap.LDAPInitialDirContextFactoryImpl] [main] LDAP server does not fall back to anonymous bind for a simple dn and password at ldap://localhost:1389
2013-03-07 09:46:26,237  INFO  [authentication.ldap.LDAPInitialDirContextFactoryImpl] [main] LDAP server does not fall back to anonymous bind for known principal and invalid credentials at ldap://localhost:1389
2013-03-07 09:46:26,247  INFO  [management.subsystems.ChildApplicationContextFactory] [main] Startup of ‘Authentication’ subsystem, ID: [Authentication, managed, ldap1] complete
[/bash]

And after your first login:

[bash]
2013-03-07 09:47:34,404  DEBUG [authentication.ldap.LDAPAuthenticationComponentImpl] [http-8080-5] Authenticating user "toni"
2013-03-07 09:47:34,421  DEBUG [authentication.ldap.LDAPAuthenticationComponentImpl] [http-8080-5] Setting the current user to "toni"
2013-03-07 09:47:34,422  DEBUG [authentication.ldap.LDAPAuthenticationComponentImpl] [http-8080-5] User "toni" authenticated successfully
[/bash]

Remember to change your LDAP log debug level before going live, something like INFO could be enough.

Revisión del libro “Intelligent Document Capture with Ephesoft” de PacktPub

Toni de la Fuente 1 Comment

Packt Publishing, la editorial que ha publicado varios libros sobre Alfresco, ha lanzado recientemente un nuevo libro llamado Intelligent Document Capture with Ephesoft. Ha sido escrito por Pat Myers, VP de Zia Consulting (partner de Alfresco) e  Ike Kavas fundador y CTO de Ephesoft que también fue empleado de Kofax antes de empezar este nuevo proyecto.

En blyx.com ya he escrito varias veces [1] , [2] sobre soluciones de digitalización y escaneo, incluso hicimos un webinar con Baratz sobre Alfresco y Ephesoft con demo incluida .

Este libro, basado en la versión 3 del producto, es estupendo para reforzar todo lo comentado anteriormente ya que Ephesoft es una herramienta que ha evolucionado mucho en los pocos años de vida que tiene.

Ephesoft es una solución para procesar documentos en papel, fax, correo electrónico, desde un ERP o cualquier otra herramienta corporativa que genere documentos gráficos o imágenes de los mismos, está hecha en Java (contiene Spring, Lucene, Hibernate, Jbpm, etc.) y es Open Source (con versión Community y Enterprise), clasifica, separa y extrae metadatos de forma inteligente implementando OCR desde una interfaz web bastante intuitiva y orientada tanto a administradores como a revisores u operadores. Además soporta interfaces de integración y exportación de los documentos con sus metadatos (personalizados o no) a diferentes soluciones de ECM mediante CMIS, como puede ser el caso de la integración con Alfresco que vimos en el webinar. Ephesoft es una alternativa a otras soluciones que hay en el mercado como Kofax o Athento.

  • El libro comienza con una introducción genérica pero completa sobre el mundo de la digitalización y ejemplos reales muy útiles para todos los perfiles involucrados a la hora de hacer un proyecto de digitalización (desde el comercial que lo vende, hasta el programador, administrador y  operador). Es una base esencial e ilustrativa para aprender bien  conceptos como los diferentes métodos de entrada, clasificación, extracción y exportación. También contempla tipos de documentos con ejemplos.
  • En el capitulo segundo se hace una descripción completa sobre todas las características de Ephesoft y muestra las interfaces web de administrador y operador.
  • En el tercer capítulo se va al grano y nos enseña a hacer cargas masivas y gestión de procesos batch para automatizar el procesamiento e ingesta de documentos escaneados (creación de batch, tipos documentales, clasificación, creación de nuevos campos, extracción de valores, expresiones regulares y exportación).
  • Tras esto, se pasa al procesado, revisión y verificación de toda la información en el capitulo cuatro.
  • El quinto capítulo es el clave desde mi punto de vista, ya que cubre características internas de Ephesoft y permite  comprender correctamente el funcionamiento del sistema en cuanto a clasificación, extracción y exportación. Cómo usar códigos de barras, imágenes, documentos complejos y clasificación automática o personalizada. Combinación con valores en BBDD externas, escáner web con origen TWAIN, exportación CMIS integrado con Alfresco (con un ejemplo de configuración paso a paso con Alfresco) y enumeración de otros ECM conocidos que también se pueden integrar.
  • En el capítulo seis se cubre todo lo relacionado con extender y personalizar la plataforma, añadir métodos de clasificación, extracción, scripts, integraciones, procesos automáticos para rellenar o extender datos concretos, gestión de digitalización distribuida geográficamente, aprendizaje automático del tipo clave/valor con expresiones regulares, etc.
  • Por último, el capítulo siete habla sobre algunos trucos, buenas prácticas y resolución de problemas comunes como gestión de logs, integración con Active Directory o LDAP y temas más variados.

Generalmente, los libros que comento en el blog y no me parecen medianamente provechosos no les dedico un post. Este libro es una referencia interesante y un punto inicial para hacer proyectos con Ephesoft. Si estás en este mundo de digitalización y ECM, y sea cual sea tu nivel de responsabilidad te recomiendo este libro, aunque hay capítulos muy específicos y orientados a desarrolladores, seguro que te aportará argumentos para tu día a día y mejorar o reforzar los conocimientos de captura inteligente. Si ya dominas totalmente la solución y has hecho proyectos con Ephesoft posiblemente aprendas poco leyendo el libro. Aunque muchos de los temas cubiertos en el libro se pueden encontrar por Internet, aquí lo tienes todo en el mismo sitio, explicado con fluidez y bien organizado. ¿Le falta algo? Si, parte de instalación, despliegue y arquitectura, pero también se encuentra por internet. ¿Lo recomiendo? Si.

Video del webinar “Alfresco One, sincronización y mucho más”

Toni de la Fuente Leave a comment

En este video mostramos en que consiste esta nueva oferta llamada Alfresco One, las nuevas características de Alfresco y capacidades de sincronización. La demo comienza a partir del minuto 21 (Sincronización con la nube, Alfresco Mobile y Alfresco Desktop Sync). En definitiva, las nuevas tecnologías están cambiando la forma en que las organizaciones trabajan con los contenidos, cómo los comparten, como se realizan los procesos de negocio y como se organizan. Desde la nube a instalaciones de Alfresco en local y la necesidad de acceso a los contenidos desde dispositivos móviles. Aprende como Alfresco resuelve estos problemas para usuarios, departamentos de IT y organizaciones en general.

Alfresco One, sincronización y mucho más from Alfresco Spain Portugal on Vimeo.

[GTranslate]

Webinar: Alfresco Enterprise – Servicios de Suscripción y Soporte

Toni de la Fuente Leave a comment

En este webinar hablamos sobre los servicios de suscripción y soporte que ofrecemos en Alfresco a nuestros clientes de la versión Enterprise. Nuestro objetivo con esta presentación es dar a conocer los servicios y valor añadido que obtienen nuestros clientes cuando adquieren la suscripción de Alfresco Enterprise.

Recuerda que puedes encontrar otros webinars, presentaciones y vídeos en nuestra web de Eventos OnDemand.

Servicios de Suscripción y Soporte con Alfresco

Otros videos de Toni de la Fuente en Slideshare.

Libro: Liferay Portal 6 Enterprise Intranets

Toni de la Fuente 7 Comments

liferay6La editorial Packt Publishing ha publicado un interesante libro sobre Liferay llamado “Liferay Portal 6 Enterprise Intranets”. Si estás interesado en montar una intranet y conocer a fondo esta tecnología, seguramente este es el libro que necesitas, completo y de fácil lectura. Como siempre, Packt pone a disposición de los clientes tanto la versión en papel como la versión en PDF del libro (o los dos a la vez), algo que sin duda es una idea genial para consultas, búsquedas, eBooks readers y por qué no, para los más impacientes. También puedes adquirirlo en Amazon aquí.

En el libro, orientado a usuarios avanzados, administradores y desarrolladores, encontramos temas interesantes (incluyendo un agradecimiento especial al amigo Jorge Ferrer), entre ellos me gustaría destacar las siguientes:

  • Varias formas de integrar Liferay con Alfresco.
  • LDAP, SSO y OpenX.
  • CMS y WCM.
  • Usabilidad y funcionalidades.
  • Formularios, blogs, wikis y RSS.
  • Sección interesante aunque escueta sobre Liferay en la nube.

Aquí puedes descargar el capítulo 11 que trata sobre gestión de servidores y clustering.

Ya sabes, comprar un libro es la mejor inversión. Yo sigo ampliando mi biblioteca y lo iré compartiendo con vosotros.

Alfresco Hack: Las consolas “escondidas” de Alfresco

Toni de la Fuente 14 Comments

Los que conocéis Alfresco en profundidad sabéis que éste guarda algunas sorpresas interesantes. Entre ellas se encuentran las consolas. Básicamente son herramientas que nos permiten acceder a información o hacer tareas de bajo nivel con Alfresco vía web, destinado principalmente a programadores o administradores.

Vamos a ver que consolas tenemos disponibles y en qué nos pueden ayudar cada una de ellas.

Nota 1: para acceder a estas consolas previamente hay que estar logueado como usuario “admin” en Alfresco Explorer (http://localhost:8080/alfresco).
Nota 2: para ejecutar comandos en estas consolas hay que escribir el comando y pinchar en “Submit”, si escribimos el comando y pulsamos “Enter” no ejecutará el comando.

La “Consola del Repositorio” es una alternativa al cliente web (Alfresco Explorer) y nos permite desplegar, recargar, activar y desactivar modelos en caliente. Podemos hacer lo mismo con ficheros .properties relacionados con idiomas. Un comando de ejemplo podría ser “deploy model alfresco/extension/exampleModel.xml“.

Permite cargar los cambios realizados en el fichero “web-client-config-custom.xml” sin necesidad de reiniciar el servidor. Relmente recarga toda la información modificada que contenga el bean webClientConfigSource en el archivo “alfresco/web-client-application-context.xml” de ahí que digamos que recarga los cambios en “web-client-config-custom.xml“. Más información aquí. Hacer esa tarea es tan fácil como escribir “reload” y hacer clic en “Submit“. Veremos algo como lo siguiente:

<Built-in evaluators> ---> OK
classpath:alfresco/web-client-config.xml ---> OK
classpath:alfresco/web-client-config-dialogs.xml ---> OK
classpath:alfresco/web-client-config-wizards.xml ---> OK
classpath:alfresco/web-client-config-properties.xml ---> OK
classpath:alfresco/web-client-config-navigation.xml ---> OK
classpath:alfresco/web-client-config-wcm.xml ---> OK
classpath:alfresco/web-client-config-actions.xml ---> OK
classpath:alfresco/web-client-config-forum-actions.xml ---> OK
classpath:alfresco/web-client-config-wcm-actions.xml ---> OK
classpath:alfresco/web-client-config-workflow-actions.xml ---> OK
classpath:alfresco/extension/web-client-config-custom.xml ---> Skipped - not available
workspace://SpacesStore/app:company_home/app:dictionary/app:webclient_extension/cm:web-client-config-custom.xml ---> OK

Esta consola nos permite hacer tareas de bajo nivel sobre la AVM (Advanced Versioning Manager), sistema usado por Alfresco WCM, posiblemente la consola más desconocida y compleja de utilizar. AVM Console cuenta con una ayuda (http://localhost:8080/alfresco/faces/jsp/admin/avm-console-help.txt) aunque tenemos más información aquí y aquí.

Este es el más conocido ya que es accesible desde la “Consola de Administración”. Es una herramienta muy útil para desarrolladores y administradores. Permite hacer búsquedas y localizar información extendida sobre los contenidos del repositorio. Soporta búsquedas de varios tipos:

  1. noderef, por ejemplo workspace://SpacesStore/3d9b49aa-54b5-41b7-8842-eecde41a9b73
  2. xpath
  3. lucene
  4. fts-alfresco (full text search)
  5. cmis-strict
  6. cmis-alfresco
  7. selectnodes.

Posiblemente el mejor amigo de un programador de workflows. Esta consola es una caja de herramientas completa para depurar nuestros workflows. Más info y sintaxis aquí.

Consola para gestión, creación y borrado, activación/desactivación, exportación e importación de tenants. Recuerda que para activar el multitenant en Alfresco hay que renombrar sin .sample los ficheros en tomcat/shared/classes/alfresco/extension/mt y reiniciar el servidor.
Otras URLs interesantes dentro de nuestro sistema:

Aquí no voy a explicar nada, ejecútala espera unos segundos y mira. ¿Interesante verdad?

Esta nos sirve para ver todos los WebScripts disponibles, información de uso de cada uno de ellos y además podremos desplegar nuevos WebScripts.

¡Que curioso! Cuando he terminado de escribir el artículo he hecho una búsqueda en Google y me encuentro esto, un post del gran Jeff Potts sobre esto mismo…

Actualización 27 Mayo 2014:

A esos que cito habría que añadir:

http://localhost:8080/alfresco/service/enterprise/admin -> Consola de Administración desde 4.2 (configuración de cluster, ldap, mail, etc. via web). Solo Alfresco Enterprise.

http://localhost:8080/share/service/index -> web scripts de Alfresco Share

http://localhost:8080/alfresco/activiti-admin -> Activiti Admin para Alfresco Enterprise

http://localhost:8080/share/page/modules/deploy -> Despliegue y control de módulos en Share

http://localhost:8080/alfresco/service/cmis/index.html -> CMIS panel

Adicionalmente para Alfresco Enterprise desde la 4.2 hay un módulo muy útil que se llama Alfresco Support Tools, se puede encontrar aquí:

https://addons.alfresco.com/addons/support-tools-admin-console

Arquitecturas en Alfresco

Toni de la Fuente 42 Comments

alfresco_repository_architecture_diagram1_coloredCon este post me gustaría hacer una pequeña introducción a los diferentes diseños de arquitecturas que podemos llevar a cabo con Alfresco dependiendo del uso, usuarios, rendimiento, concurrencia y almacenamiento requerido.

Alfresco es un producto que acaba de cumplir 5 años, tras pasar por varias etapas con versiones más o menos estables, podemos decir, que desde hace un tiempo contamos con un producto confiable, robusto, estable y escalable. Preparado para pequeños proyectos con decenas de usuarios y unos cuantos miles de contenidos y para entornos con miles de usuarios y millones de contenidos. Y cada vez nos encontramos más y más instalaciones consolidadas.

Algo muy común que veo en las implantaciones de Alfresco, salvo casos muy concretos, es que muchas veces se instala la aplicación, base de datos y content store en la misma máquina, tanto para un piloto, desarrollo, test o producción. Para un piloto y desarrollo o incluso test es válido, o para producción si los requisitos no son demasiado exigentes. Teniendo todas las capas de la aplicación en la misma máquina (física o virtual), cuando el entorno pasa a producción y empieza a crecer considerablemente en número de usuarios y contenidos se suele experimentar un problema de rendimiento. Tiempos de respuesta elevados en el acceso, reglas, workflows, etc.

Vamos a ver, de forma resumida, algunos conceptos a tener en cuenta a la hora de hacer despliegues de Alfresco que nos permita crecer tanto horizontal como verticalmente.

Antes de seguir, para entender bien todo esto, veamos los componentes de la infraestructura que debemos conocer y diferenciar para diseñar una correcta arquitectura:

  • Repositorio Alfresco: hablamos de la aplicación principal de Alfresco (alfresco.war) que gestiona todo el repositorio (contenidos) y el core, así como las diferentes interfaces de acceso como CIFS, FTP, WebServices, Alfresco Explorer y muchas otras más.
  • Alfresco Share: aplicación (share.war) que es interfaz web de Alfresco y nos permite acceder al repositorio una interfaz ligera y potente para gestión de contenidos y colaboración. Mediante Share podemos activar sitios favoritos para su posterior acceso por IMAP. Este componente puede estar en una capa diferente al repositorio y escalar de forma separada tanto vertical como horizontalmente.
  • Aplicaciones de terceros: nos referimos a las aplicaciones que necesita Alfresco para funcionar al 100% como OpenOffice, ImageMagik y Pdftools. Recuerda que desde la versión 3.2, OpenOffice funciona como un subsistema y podemos instalarlo en una máquina diferente al repositorio.
  • Base de datos: será el motor de base de datos a usar por el software, como ya sabemos, pueden ser de varios tipos y “sabores” como MySQL, MS SQL Server, PostgreSQL, Oracle, etc. Alfresco almacena en la base de datos toda la información (metadatos, reglas, permisos… todo) excepto los índices y los ficheros físicos. Dicho esto, podemos adivinar que el uso de base de datos que hace Alfresco es importante.
  • Almacén de contenido o content store: será el sistema de ficheros, directorio o directorios del sistema operativo donde Alfresco deposita los ficheros que maneja, los ordena por diferentes niveles de directorios (año/mes/dia/hora/minuto). Por defecto se almacena dentro de alf_data/contentstore. En contentstore.deleted tendremos los ficheros borrados, tras 15 días de ser eliminados, y audit.contentstore que será la información extra que genera la aplicación si activamos las auditorías.
  • Índices: hablamos de la información que genera el motor de indexación y búsqueda que incorpora Alfresco, Lucene. Esta información se almacena en un directorio del sistema operativo llamado lucene-indexes dentro de alf_data por defecto. Diariamente a las 3 AM se genera un backup automático de los índices en el directorio alf_data/lucene-indexes.backup. Como decía, ahí se almacenan todos los índices de los contenidos del repositorio y tendrá un puntero a los mismos desde la base de datos. Podemos imaginar que cuanto más rápido sea el disco o discos donde residan los índices, más rápido funcionará nuestro sistema a nivel general.

Dicho lo anterior y conociendo el funcionamiento de Alfresco, podemos averiguar donde tenemos los cuellos de botella en las implantaciones.

Por ejemplo, tener el content store y la base de datos en la misma máquina sobre el mismo disco duro supone que cada vez que subimos un fichero o realizamos alguna acción con el mismo se escribe simultáneamente en base de datos y content store; moraleja: el disco duro debe escribir al mismo tiempo en varios sitios diferentes = sistema lento. Claro está, esto nos pasará si estamos haciendo un uso intensivo del sistema.

Todos esos componentes los podemos implementar de diferentes formas, dependiendo de la ubicación de cada componente hablaremos de diferentes capas o niveles.

  • Una capa única: es el despliegue por defecto que podemos realizar con los instaladores bundle de Alfresco. Todos los elementos de la infraestructura los tendríamos en la misma máquina. ¿Para qué es válido este tipo de despliegue? Para pruebas piloto, desarrollos o incluso pequeñas instalaciones orientadas a departamentos. Por supuesto, este tipo de despliegues no se recomiendan para sistemas críticos o con grandes expectativas por razones obvias de escalabilidad y rendimiento.
  • Dos capas: en este despliegue podemos empezar a usar una arquitectura realmente empresarial y escalable. Aquí separaremos en capas independientes:

Capa de contenidos: repositorio, Share, índices y aplicaciones de terceros que necesita Alfresco.
Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.

Esta arquitectura permite más escalabilidad y rendimiento, configuración simple y la gestión del crecimiento del contenido es transparente para la aplicación. Si añadimos que en este caso los índices estarán en la capa de contenidos tendremos como resultado un entorno que imprima un rendimiento considerable para entornos de tipo medio que incluso pueden ponerse en alta disponibilidad, pero ojo, si crecen mucho los contenidos también crecerán los índices y en ese casos podríamos necesitar hacer cambios en la infraestructura o en la configuración de los servidores (asignar más almacenamiento, etc.).

  • Tres capas distribuidas: en versiones 3.X podemos separar en varias capas componentes de la capa web de Alfresco, es decir, separar Alfresco Share del repositorio. Este caso será el más escalable y nos permitirá implementar entornos con una gran carga y altas exigencias en cuanto a rendimiento. Esta arquitectura añade a la de dos capas la distribución de la capa web. Las capas serían las siguientes:

Capa web: donde tendríamos Alfresco Share o/y otras aplicaciones frontales que podamos tener para trabajar con Alfresco (Liferay, Joomla, Drupal, etc.) u otras hechas desde cero y opcionalmente un servidor web que proteja al servidor de aplicaciones vía mod_proxy, Varnish o similares.

Capa de contenidos: repositorio, índices y aplicaciones de terceros que necesita Alfresco.

Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.

Podríamos añadir una capa extra entre la capa web y capa de contenidos que nos permita hacer caché, control de acceso o balanceo de carga. Como vemos, esta es la mejor forma de ofrecer el máximo rendimiento tanto de lectura como de escritura, que además podemos configurar en alta disponibilidad en todas las capas. Este tipo de arquitectura no es recomendada para pequeños despliegues departamentales y necesita un alto grado de conocimiento de Alfresco, sistemas y redes en general. Salvo uso de software específico, no se recomienda separar cada una de las capas de forma geográfica ya que una alta latencia entre capas puede influir negativamente en el rendimiento.