How to control public shared content in Alfresco

Last day, I was asked for a client about how to control "public" shared content in Alfresco Share in a simple way. These are some of the ideas of the support conversation:
[me] First, just write in the Alfresco Share search box, the next querys. You should see your shared content. 
ASPECT:"qshare:shared" AND @cm:creator:"ccl001"
ASPECT:"qshare:shared" AND @qshare:sharedBy:"ccl001"
ASPECT:"qshare:shared" AND @cm:modified:["2014-12-31" TO NOW]
ASPECT:"qshare:shared" AND @cm:modified:[MIN TO "2013-12-31"]
[client] OMG! There exists a lot of public documents... What can we do for managing this ? Querys are right but many final users do not understand complex queries, and they are not familiar with aspects.
[me] Right, we can implement a document filter query in sites and/or in My documents dashlet, for final users.
[client] We are not sure about document library filters... because filters will appear in all sites, for all users. What about for Alfresco Admins ? May we get a list of public nodes ? How can we unshare these public urls ? 
[me] Just removing qhare:shared aspect. For alfresco admins, we can run a simple script in Javascript API for getting a brief report in CSV, via Alfresco Javascript Console. This should be valid also for users that create rules on their sites, executing the JS code. This is only valid for 1000 items, although you can run it several times (which is not always possible). 
var nodes = search.luceneSearch('ASPECT:"qshare:shared"');
var count = 0;
for each(var node in nodes) {
        count = count + 1;
        logger.log(count + ": "+node.displayPath+"/";           
        // Uncomment these two lines for unsharing
        //logger.log("  Cleaning the aspect..");    
        //logger.log("  Done");                        
[client] Mmm... I don't see the full picture, yet.
[me] Ok, we can filter query by modified date too. You can assume that content is shared before being modified and then to unpublish them if the content was modified many time ago.
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:modified:["2014-12-31" TO NOW]'); 
[client] This is a little tricky... but I'm not sure about it.
[me] Ok, you can use cm:effectivity aspect in Alfresco content, and use cm:to property for controlling the end lifecycle on your public nodes and urls. So, add aspect Effectivity, to the node to be shared, and then edit effectivity properties.
[client] I don't see it, this implies more work for final users.
[me] Well, you may also use content rules, for setting cm:to by a default relative date, if the content is shared.
[client] Better. Something more ?
[me] Then, we can write another script that checks the expiration date cm:to (i.e. today), and then remove the aspect or aspects.
var today  = new Date();
var month = today.getMonth() + 1; //months from 1-12
var day     = today.getDate();
var year    = today.getFullYear();
var mydate = year+"-"+month+"-"+day;
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:to:"'+mydate+'"');
var count = 0;
for each(var node in nodes) {
  count = count + 1;
  logger.log(count + ": "+node.displayPath+"/";
  logger.log(" This public url is expired --> "["cm:to"]);
  logger.log(" Cleaning the aspect..");
[client] It sounds even better.
[me] And finally, we can do a daily quartz executing the javascript code, to unshare the public urls.
[client] Ok, let's do it. 
P.S: Tested in Alfresco 4.2.4 EE (although it may work in other versions).
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Avro RCP yarn and slider II

Siguiendo con la visión de una arquitectura basada en yarn y mirco servicios ... os dejo un diagrama completo de los componentes y su comportamiento



Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Avro RCP yarn and slider

Siguiendo con los artículos relacionados con YARN, SLIDER y arquitecturas relacionadas con BigData mostramos a continuación una posible arquitectura basda en los siguientes tres elementos

Donde lo importante es que con este tipo de arquitectura podríamos disponer de servicios con las caraterísticas indicadas

La idea en este caso es desplegar los servicios que se pueden generar con AVRO en un cluster de yarn empaquetando estos servicios como aplicaciones YARN.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Online edition with Libreoffice in Alfresco 5

Last days I was asked for a tip (again) for enabling online edition via webdav with Libreoffice in Alfresco 5. It is tested with this setup:
  • Ubuntu 14.04 LTS (although it can work in other Linux)
  • Libreoffice (it comes with the Linux distro)
  • Alfresco CE 5.0c && 5.0d (the jar is valid for Alfresco 4 too)
  • Last versions of Firefox and Chrome
So, in your Alfresco 5 server you need to download the jar file and copy in $ALF_HOME/tomcat/shared/lib directory, restarting alfresco service:
Once, you should see "Edit. Online" action for MS-Office and Libreoffice mimetypes. It is clear that you need webdav enabled in your repository (and access to the webdav context).
Then, for make it work, you need to register an url-handler based protocol for dav:// and davs:// urls with Libreoffice. This can be done via two methods (that can work in different versions of Linux).
Method 1:
Create the next file, and the corresponding path, if it does not exist.
$ vim ~/.local/share/applications/libreoffice-alf.desktop 
[Desktop Entry]
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Exec=soffice %U
2. Create the mimeapps.list file, if it does not exist. If it exist, just add the two x-scheme handlers,
$ vim ~/.local/share/applications/mimeapps.list
[Added Associations]
Method 2: 
This is done for all users of the operating systems, you need sudoer privileges
1. Just create the file in the next path:
$ sudo vim /usr/share/applications/libreoffice-alf.desktop
[Desktop Entry]
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Exec=soffice %U
2. Add x-scheme-handlers to mimeinfo.cache
$ sudo vim /usr/share/applications/mimeinfo.cache
# Add to the file
3. Update desktop cache
$ sudo update-desktop-database 
Then when you "Edit. online", you see some dialog for remembering the action for opening the url. Libreoffice asks for your credentials once in a session.
For Windows users, it is possible to register the protocol too, with the help of (there is also a .reg file in the downloads section of the googlecode project - put the correct path for the Libreoffice command):
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Usando yarn y slider para levantar procesos en un cluster de hortonworks

Siguiendo con las pruebas y las arquitecturas relacionados con bigdata vamos a inspeccionar las capacidades de yarn para levantar procesos en un cluster HDP. Lo primero que habría que introducir es el producto yarn. De la página siguiente de hortonworks podemos obtener la siguiente definición

YARN is the prerequisite for Enterprise Hadoop, providing resource management and a central platform to deliver consistent operations, security, and data governance tools across Hadoop clusters.
YARN also extends the power of Hadoop to incumbent and new technologies found within the data center so that they can take advantage of cost effective, linear-scale storage and processing. It provides ISVs and developers a consistent framework for writing data access applications that run IN Hadoop.

Por tanto como podemos ver yarn es una suerte de sistema operativo para interactuar con hadoop y que éste (yarn) gestione los recursos del cluster de hadoop/hortonworks.

Sobre Yarn existen varios APIs que podemos usar para desplegar nuestros propios procesos.

  • YARN (API de más bajo nivel sobre el que se montan, TEZ y SLIDER)
  • TEZ (API para simplificar el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, se puede ver como un API para ejecutar procesos, por ejemplo scripts de PIG, HIVE etc...)
  • SLIDER (API que simplifica el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, a diferencia de TEZ slider está diseñado para es levantar servicios, como explican el la página de howtonworks, Slider is a framework for deployment and management of these long-running data access applications in Hadoop)

Una vez presentados los tres "sabores" principales vamos con el caso de uso que estamos probando. En este caso lo que vamos a crear es bot para slack que va a leer los mensajes de un canal y va a contestar a los mensajes de dicho canal. La idea es que una vez que tengamos esa aplicación java desarrollada la levantemos sobre el cluster de hdp/yarn usando slider.

La arquitectura general de la solución es la siguiente

Donde podemos ver que los eventos producidos en un canal de slack son consumidos por el bot que se ha levantado en un cluster de hadoop usando slider. Para desarrollar esta prueba de concepto los requisitos son

El primer requisito se ha tratado en otros posts en este blog. El segundo requisito es la parte en la que nos hemos centrado para crear esta entrada. Un paquete slider se compone (a grandes rasgos) de los elementos que vemos en la siguiente imagen

Donde lo principal son los ficheros de configuración, los scripts de arranque, y los binarios que se ejecutan. Los binarios son la parte que en este caso hemos desarrollado en java. Los archivos de configuración nos permiten definir las siguientes características:

  • classloader de la aplicación
  • version de java que se quiere usar
  • memoria reservada para el proceso
  • nombre del paquete/servicio
  • parámetros extra que se pasan al proceso (pueden ser parámetros gestionados por el que despliega el proceso o por el propio nodo donde se levanta el proceso)
  • threshold que nos permite definir los límites que hacen que un proceso que se ha detenido se vuelva a levantar automáticamente. Por ejemplo si se ha producido un error de comunicación y el proceso se muere según definamos los límites el proceos se volverá a levantar de manera automática.
  • numero mínimo y máximo de procesos que se deben levantar
  • ... y un montón más de características que podemos ver en el site del proyecto

Una vez que tenemos el paquete creado podríamos desplegarlo usando los siguientes comandos de slider

  • slider  package --install --replacepkg  --name MOMO_BOT --package /home/hadoop/jenkins/jobs/slack_bot/
  • slider stop momo_bot
  • slider  destroy momo_bot
  • slider  create momo_bot --template /home/hadoop/jenkins/jobs/slack_bot/appConfig-default.json --resources /home/hadoop/jenkins/jobs/slack_bot/resources-default.json

Una vez ejecutada esta secuencia podremos ver nuestro proceso desde la vista slider de nuestro ambari.

Para la generación del paquete hemos usando maven y para el despliegue automatizado jenkins. El objetivo de esta prueba era analizar las características de slider como modelo de despliegue de aplicaciones. El hecho de desplegar una aplicación usando este modelo dota al servicio de las siguientes características

  • auto-escalado
  • monitorización y re-arranque de containers en base de los parámetros definidos en la configuración del paquete slider
  • gestión de los recursos asociados al servicio usando del modelo de containers de yarn
  • registro automático del servicio etc..

En esta página se puede ver todo lo que slider puede hacer ( Lo más destacable a nuestro modo de ver sería

  • A user can create an application instance.
  • Users can flex an application instance: adding or removing components dynamically. If the application instance is live, the changes will have immediate effect. If not, the changes will be picked up when the instance is next started.

Y como última conclusión ... slider es mucho más que de lo que se ha explicado en este post... parafraseando a pedro salinas ... Eso no es nada aún. Buscaos bien, hay más.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

How to track SOLR indexation process in Alfresco

For tracking indexation in SOLR, we have the Alfresco Administration Console, which gives us the indexation status, the indices in disk, and an estimation of the remaining time of transactions to be indexed. This is available in Enterprise edition in Admin Console:
This information is directly taken from SOLR Summary XML Report (in this case the url is using 8080 instead of the default secured 8843):
Another way for tracking or monitoring the indexation progress is to set debug logger in of SOLR application:
In SOLR, the log4j can not be extended out of WEB-INF (as in Alfresco Share) and you should change it directly under WEB-INF directory at:
The best part of this is that you can activate it or reload it (without restarting the service) with this action:
By last, you can monitor size data.dir.root for SOLR via operating system, or via JMX (only in EE edition) with the next bean and their corresponding variables:
In jmxterm the sequence is the next one:
> jvms
> open <tomcat-id>
> domain Alfresco
> bean Alfresco:Category=Search,Type=Configuration,id1=managed,id2=solr
> get
> get tracker.alfresco.approx.indexing.time.remaining
> get tracker.alfresco.approx.txns.remaining
> get tracker.alfresco.disk
> get tracker.alfresco.lag
> get tracker.alfresco.lag.duration
> get tracker.alfresco.last.indexed.txn
> get tracker.alfresco.memory
Finally, you must take into consideration that there is an issue for getting this data if archive core is disabled by config in SOLR (in < Alfresco 4.2.5).
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

How to get logs for Alfresco querys

For getting more information about Alfresco querys just edit (extend) in extension directory, for example:
SQL queries:
Be careful, this is pretty verbose. Be careful with caches too!.
SOLR queries:
Javascript API queries:
In Alfresco Enterprise, you have more options for doing this without restarting the service:
although not all classes are enabled via JMX or support tools, for example the SQL and DbOrIndexSwitchingQueryLanguage loggers. Tested in Alfresco 4.2.4 EE.
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Ambari hortonworks stacks and services solrCloud for liferay

Siguiendo con el post de ayer y después de unos mínimos ajustes en los scripts del stack, ya podemos crear un cluster de solr (tipo cloud) y crear en él una collection con dos shards y factor de replica 2. Para ellos basta con ejecutar el siguiente comando en alguno de los nodos gestionados desde ambari

./bin/solr create_collection -c liferay-collection -shards 2 -replicationFactor 2

Este comando crea una collection con dos shards y replica 2 llamada liferay-collection que la usaremos más adelante para almacenar los índices de liferay. SolrCloud se apoya en el zookeeper del laboratorio de bigdata (hortonworks 2.3). A continuación unas imágenes de cómo se ve esta colección desde la consola web de administración de solr

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Ambari hortonworks stacks and services


Dentro del proyecto ambari[0] hay dos partes que son claramente extensibles.

  1. Las vistas[1]
  2. Los stacks services[2]

En este artículo vamos a ver, muy someramente, para que creemos que se pueden usar los stacks y un ejemplo de stack para gestionar un motor de búsqueda como solr[3].

Según el propio proyecto ambari la definición de un stack es

Ambari supports the concept of Stacks and associated Services in a Stack Definition. By leveraging the Stack Definition, Ambari has a consistent and defined interface to install, manage and monitor a set of Services and provides extensibility model for new Stacks + Services to be introduced.

Por tanto creemos que es bastante claro para que sirve y cual podría ser su uso extendido. En este caso vamos a analizar la anatomía de un paquete tipo stack. Analizando e instalando el stack anteriormente mencionado [3]

Según vemos en el git del proyecto a primera nivel tenemos

  • kerberos.json (define el modelo de seguridad)
  • metainfo.xml (define las dependencias del stack, el nombre que se va a visualizar en la interfaz de ambari etc..)
  • (el script que elimina un servicio ya instalado de un nodo del cluster gestionado por ambari)
  • configuration (contiene los ficheros de configuración que ambari va a manejar para gestionar el servicio instalado)
  • package (el paquete con las dependencias, scripts de instalación, arranque, monitorización etc...)

Una vez que más o menos tenemos claro que es un stack, procederemos a su instalación. Para ello seguimos el readme que tiene el propio proyecto y vemos que lo único que hay que hacer es copiar estos ficheros/carpetas en la zona reservada a tal efecto en el servidor de ambari y reiniciarlo. En este caso se ha hecho clonando el repositorio git en nuestra máquina lug012 que es la que contiene el servidor ambari. En nuestro caso lo haremos clonando el repositorio git

  • sudo git clone /var/lib/ambari-server/resources/stacks/HDP/2.3/services/SOLR
  • sudo service ambari-server restart

Y ya podemos ver en el ambari el nuevo servicio de solr que podremos instalar, configurar y monitorizar desde la interfaz web de ambari.

A continuación dejamos unas imágenes del proceso de instalación de un nodo master de solr[4]. El proceso de instalación tiene sus particularidades y hay que ayudarle un poco para que finalice correctamente ;-)


Siguiendo este modelo lo siguiente que queremos añadir a nuestro laboratorio de bigdata son servicios/stacks de tomcat, por ejemplo. Para poder gestionar desde ambari las aplicaciones java normales que desarrollamos en


UPDATE: Hablando ayer con una otro developer me hizo el siguiente comentario, que creo que es interesante añadir en la entrada (Ya que creo que tiene razón y que en el post no queda suficientemente claro, gracias Carlos por la apreciación) :


A mi entender, HDP es un STACK de Ambari, que tiene disponible N servicios (HDFS, HBase, YARN…). En la entrada del blog, lo que se da a entender es que se ha creado un stack cuando en realidad lo que se ha creado es un servicio para un stack, en el caso de zylk para el stack de HDP.







Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude