: : blyx.com : : Blog : : Toni de la Fuente : :

Toni Marzo 26th, 2012

De entre los muchos sistemas de indexación que existen para las empresas está Constellio, un producto realizado por la gente de Doculibre y basado en Apache Solr. Constellio es Open Source y se puede contratar soporte con el fabricante dependiendo de las necesidades del cliente. Es una herramienta multiplataforma, instalación bastante sencilla con un asistente (java -jar constellio_install_1.3.jar).

Tags: alfresco, solr

• administración de sistemas
• Comments(1)

Toni Marzo 7th, 2012

Cuanta más información almacenamos en Alfresco, más necesidad de protegerla tenemos y también más necesidad de disponer de la misma. Por eso pienso que este webinar puede ser muy interesante para cualquiera que debe mantener un entorno con Alfresco independientemente de la criticidad del mismo.

En este webinar de unos 50 minutos de duración vamos a ver qué aspectos relacionados con la seguridad debemos tener en cuenta en los diferentes procesos del ciclo de un proyecto con Alfresco como durante la planificación, instalación, configuración y fortificación así como en el mantenimiento, monitorización y auditoría.

Básicamente, este webinar es una colección de consejos y trucos que nos ayudan a fortificar y controlar nuestro entorno ECM.

Aquí está la presentación utilizada para poder descargarla desde la web de Slideshare:

Tags: alfresco, Seguridad

• Seguridad , administración de sistemas
• Comments(2)

Toni Enero 26th, 2012

SOLR es el nuevo motor de indexación que incorpora Alfresco en su versión 4.0, no obstante, se puede seguir usando Lucene. En este webinar de una hora de duración, junto a Baratz (Partner Gold de Alfresco), 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.

Tags: alfresco, solar, webinar

• Formación , administración de sistemas
• Comments(18)

Toni Enero 24th, 2012

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:

• 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:

• 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:

### Outbound mail SMTP ###
mail.host=smtp.gmail.com
mail.port=465
mail.protocol=smtps
mail.smtps.auth=true
mail.username=correo@gmail.com
mail.password=Contraseña
mail.encoding=UTF-8
mail.from.default=correo@gmail.com
mail.smtp.starttls.enable=true

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 Perdition o Nginx. 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í.

Tags: alfresco, Seguridad

• Seguridad , administración de sistemas
• Comments(0)

Toni Diciembre 20th, 2011

monitorRole   readonly
controlRole   readwrite

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

monitorRole  mi-nuevo-password1
controlRole  mi-nuevo-password2

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

alfresco.jmx.dir=/directorio/instalacion/tomcat/shared/classes

Tags: alfresco, monitorización, Seguridad

• Seguridad , administración de sistemas
• Comments(4)

Toni Diciembre 7th, 2011

     <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>

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

Tags: alfresco

• administración de sistemas
• Comments(6)

Toni Agosto 19th, 2011

Cuando vamos a tener un sistema con gran cantidad de usuarios (miles) y con necesidades importantes de transformación de formatos o incluso para lanzar una reindexación completa de ficheros, metadatos y contenido de los ficheros, puede ser útil escalar, ampliar nuestra infraestructura de Alfresco para usar recursos que tengamos disponibles en otras máquinas.

En este artículo voy a enseñar como configurar Alfresco Enterprise para usar un Open Office corriendo como servidor en un servidor remoto.

/usr/bin/soffice -headless -nofirststartwizard -accept="socket,host=192.168.0.30,port=8100;urp;StarOffice.ServiceManager" &

### External executable locations ###
ooo.exe=/backup/alfresco/alfresco-enterprise-3.4.3/openoffice/program/soffice.bin
ooo.enabled=false
ooo.port=8100
ooo.server=192.168.0.30
img.root=/backup/alfresco/alfresco-enterprise-3.4.3/common
img.dyn=${img.root}/lib
img.exe=${img.root}/bin/convert
swf.exe=/backup/alfresco/alfresco-enterprise-3.4.3/common/bin/pdf2swf
jodconverter.enabled=true
jodconverter.officeHome=/backup/alfresco/alfresco-enterprise-3.4.3/openoffice
jodconverter.portNumbers=8100

Recuerda, en el archivo anterior, activar “jodconverter.enabled=true” y añadir el valor “ooo.server” con la IP donde estará el servidor dedicado con Open Office.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>

<beans>

<bean id="openOfficeConnection" class="net.sf.jooreports.openoffice.connection.SocketOpenOfficeConnection">
   <constructor-arg type="java.lang.String" value="${ooo.server}"/>
   <constructor-arg type="int" value="${ooo.port}"/>
</bean>

<bean id="transformer.OpenOffice" class="org.alfresco.repo.content.transform.RemoteOpenOfficeContentTransformer" parent="baseContentTransformer" >
   <property name="connection">
         <ref bean="openOfficeConnection" />
   </property>
   <property name="documentFormatsConfiguration">
         <value>classpath:alfresco/mimetype/openoffice-document-formats.xml</value>
   </property>
</bean>

<bean id="openOfficeConnectionTester" class="org.alfresco.util.OpenOfficeConnectionTester">
   <property name="connection">
         <ref bean="openOfficeConnection"/>
   </property>
   <property name="strict">
         <value>false</value>
   </property>
</bean>

</beans>

Hechos esos cambios debemos reiniciar el servidor de aplicaciones y listo. Asegúrate que desde el servidor de Alfresco se llega al puerto de OpenOffice remoto por ejemplo haciendo “telnet 192.168.0.30 8100″, también puedes ver el tráfico que se genera entre los servidores lanzando el comando “tcpdump -nni eth0|grep 8100″ en el servidor de OpenOffice.

Recuerda que esta es una funcionalidad de escalabilidad adicional que está disponible en Alfresco Enterprise. Yo la he probado con la versión 3.4.3.

Tags: alfresco

• administración de sistemas
• Comments(10)

Toni Julio 1st, 2011

En la sección “Operations” de cada “Trigger” encontrarás un botón llamado “executeNow“, adivina para que sirve Cada tarea o trigger tiene una serie de propiedades que se explican por si solas, aunque me gustaría destacar la propiedad “Priority” que permite ejecutar una tarea sobre otra en caso de coincidir.

Tags: alfresco

• administración de sistemas
• Comments(5)

Toni Junio 2nd, 2011

Como muchos ya sabréis, Alfresco utiliza Log4j para los logs. Log4j es una herramienta Open Source para gestionar logs y permite a programadores y administradores controlar lo que ocurre en la aplicación de forma granular y a diferentes niveles de detalle.

Controlar cómo funcionan los logs en Alfresco es la mejor forma de conocer como funciona el sistema tanto para administradores como programadores y poder detectar/solucionar problemas en una instalación.

Se configura mediante un fichero de texto llamado log4j.properties que se encuentra dentro de alfresco.war concretamente en el caso de Tomcat en ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes. En este fichero se especifica qué queremos que registre el log y cómo queremos que lo muestre (mayor o menor detalle). También es donde se establece el nombre del fichero de log (alfresco.log) y los ficheros de log anteriores a los que le añade fecha (alfresco.log.YYYY-MM-DD). Estos ficheros de logs generados los encontraremos en la raíz del directorio donde hemos instalado Alfresco también conocido como ${ALFRESCO_HOME}, ojo, ni esta variable ni ${TOMCAT_HOME} existen salvo que se declaren, se usa para indicar el directorio raíz de instalación de Alfresco y de Tomcat respectivamente.

Vamos a ver como cambiar la ubicación del fichero de log de Alfresco. Copiamos el fichero log4j.properties al directorio extension con otro nombre, por ejemplo custom-log4j.properties:

# cp ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes/log4j.properties ${TOMCAT_HOME}/tomcat/shared/classes/alfresco/extension/custom-log4j.properties

Este cambio nos permitirá tener siempre la misma configuración de logs independientemente de que actualicemos Alfresco y despleguemos un nuevo alfresco.war donde se sobreescribiría la configuración personalizada si la hacemos dentro del war desplegado.

Editamos el fichero custom-log4j.properties y localizamos la línea:

log4j.appender.File.File=alfresco.log

para especificar la siguiente:

log4j.appender.File.File=/var/log/alfresco/alfresco.log

Como veis, este ejemplo está orientado a un sistema Linux o Unix, hay que tener en cuenta que si queréis poner los logs como he indicado hay que crear el directorio /var/log/alfresco y darle los permisos necesarios para que el usuario con el que se ejecuta Alfresco pueda escribir. También podríais poner los logs en alf_data/logs y así tener todo más centralizado. Para Windows habría que cambiar la ruta absoluta en el siguiente formato, por ejemplo “D:\logs\alfresco\alfresco.log”. Una recomendación de índole general para cualquier aplicativo y sus logs es disponer de una partición independiente encargado de almacenar estos ficheros (generalmente /var/log), de forma que si nos quedamos sin espacio en disco tanto en la aplicación como en los logs, no afecte al funcionamiento y podamos detectarlo de forma anticipada ya sea chequeando manualmente o con un sistema de monitorización, evidentemente también podemos poner una partición dedicada a los logs de Alfresco. Recuerda hacer backup de los logs regularmente.

Para entender mejor la sintaxis y opciones que encontramos en el fichero de configuración os recomiendo leer esta entrada en la Wikipedia. Destacaría el parámetro log4j.appender.File que especifica la rotación diaria del fichero de log y log4j.appender.File.File que permite indicar el nombre y path del fichero de log.

En cuanto a los niveles de detalle es importante conocer que existen los siguientes (de menos a mas detalle): OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE y ALL. Así que hay que tener cuidado con tener DEBUG, TRACE o ALL en un sistema en producción, salvo que sea necesario para solucionar un problema. Aquí puedes ver más información al respecto.

Si usáis un servidor de aplicaciones Tomcat, también es recomendable cambiar la ubicación del fichero de logs de Tomcat (o cualquier otro servidor de aplicaciones soportado), aquí vemos como cambiar el sitio donde se almacena el fichero catalina.out:

Editamos el fichero ${TOMCAT_HOME}/bin/catalina.sh, localizamos las líneas:

if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="$CATALINA_BASE"/logs/catalina.out
fi

Y cambiamos la ruta de CATALINA_OUT por la ruta deseada:

if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="/var/log/alfresco/catalina.out"
fi

Para que los cambios anteriores surtan efecto hay que reiniciar el servidor de aplicaciones. Una vez reiniciado ya veremos los ficheros creados en el directorio correspondiente.

Todo lo que hemos visto anteriormente se puede hacer de una forma más sencilla accediendo al servidor con jconsole mediante RMI y sin tener que reiniciar el servidor. En Alfresco Enterprise 3.4 ya está activado el acceso remoto. Aquí expliqué como acceder por jconsole a Alfresco.

Como vemos en la siguiente captura de pantalla, en la sección MBeans podemos encontrar un grupo llamado “log4j” y desplegado podemos ver todas sus opciones.

Concretamente en la captura anterior vemos los “Attributes” del bean “File“, y ahí podemos cambiar las opciones como por ejemplo “file”, el fichero y ruta de log. Una vez cambiado a nuestro gusto, para que tenga efecto vamos a “Operations“, hacemos clic en “activateOptions” y listo.

Por ejemplo, los logs de Webdav por defecto están configurados como detalle tipo “ERROR”, si queremos hacer un análisis más exhaustivo podríamos localizar el bean “org.alfresco.webdav.protocol” y desplegamos el menú “Attributes” y hacemos clic en “priority“, doble clic en “ERROR” para editarlo y lo cambiamos por “DEBUG” (sin comillas), a continuación guardamos simplemente pulsando la tecla “Enter” y ya tendríamos configurado el nivel de log del componente de turno. Fácil ¿no?

Para terminar quiero mencionar este pequeño desarrollo que ha realizado Tjarda Peelen – @tpeelen que permite ver los logs en la propia interfaz de la aplicación. Puede ser útil.

También se podría usar Log4mongo u otras aplicaciones para presentar logs vía web, pero eso ya es otra historia.

¿Algún consejo más? ¡Cualquier comentario es bienvenido!

Tags: alfresco

• administración de sistemas
• Comments(5)

Toni Marzo 7th, 2011

Como muchos ya sabéis y también hablé aquí hace tiempo, Alfresco dispone de varios recursos internos que nos pueden ayudar en la administración y del servidor y también de cara a desarrollar. He preparado unos ficheros que nos permiten tener acceso a todos ellos de una forma sencilla y cómoda desde el menú de herramientas en Alfresco Share, como se puede ver aquí (pincha para ver la captura):

He creado un proyecto en Google Code para almacenar estos pequeños ficheros, lo he llamado alfresco-useful-admin-links. La instalación es muy sencilla, no hay que reiniciar el servidor:

1. Descargar el conjunto de ficheros necesarios en el servidor desde aquí.
2. Copia el contenido del fichero zip (sólo los ficheros contenido, no el directorio) en <tomcat home>/shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/console. Si no existen esos directorios debes crearlos y si ya los tienes debes sobreescribir los ficheros existentes. Si no lo copias en esa dirección no te funcionará.
3. Accede a la consola de Web Scripts de Alfresco Share http://localhost:8080/share/service/index.html
4. Haz clic en “Refresh Web Scripts” y listo
5. Accede a Alfresco Share, visita la sección “Herramientas” pinchando sobre el menú superior “Más…” -> “Repositorio“

Lo he probado en Enterprise 3.4, si lo probáis en otras versiones y encontráis algún problema me indicáis para corregirlo.

Actualización: ¿Quieres instalarlo como AMP? Mira en el blog de Fernando Gonzalez, uno de los expertos españoles de Alfresco.

Tags: alfresco

• administración de sistemas
• Comments(8)