tip pentaho/déploiements: rafraîchir le repository

Le problème est très vite arrivé quand on veut déployer de nouveaux rapports sur plusieurs serveurs différents de façon automatique.
imaginons que ayez un nouveau rapport de type CDE ( kesako ?)que vous avez fabriqué sur votre serveur local.

Vous avez copié les fichiers physiques du rapports  sur le serveur de production grâce à  un script shell par exemple.
Si vous vous connectez sur votre console utilisateur (https://monserveur:8080/pentaho/Home), vous ne voyez pas le nouveau rapport !!
L’explication est simple, tant que vous n’avez pas rafraîchi la solution , les nouveaux fichiers ne sont pas pris en compte par le moteur Pentaho.
Sous le capot, Pentaho utilise un indexage des fichiers qu’il enregistre dans la base de données ( tables PRO_FILES  et PRO_ACLS_LIST dans la base de données hibernate).
Tant que l’on a pas commandé à  pentaho de rafraîchir le repository, les nouveaux objets qui ont été copiés n’ont pas été enregistrés dans l’index pentaho.
Comment on peut piloter ce rafraîchissement, par exemple par script shell ?
La seule façon que j’ai trouvé est de créer une page jsp que je vais installer dans le contexte d’exécution de pentaho.
Je vais l’appeler RefreshRepository.jsp et voici le code :

<%@ page language= »java »
import= »org.pentaho.platform.engine.core.system.PentahoSystem,
org.pentaho.platform.api.engine.IPentahoSession,
org.pentaho.platform.web.jsp.messages.Messages,
org.pentaho.platform.api.engine.IUITemplater,
org.pentaho.platform.web.http.WebTemplateHelper,
org.pentaho.platform.util.messages.LocaleHelper,
org.pentaho.platform.api.repository.ISolutionRepository,
org.pentaho.platform.repository.solution.dbbased.DbBasedSolutionRepository,
org.pentaho.platform.web.http.PentahoHttpSessionHelper » %>
<%
response.setCharacterEncoding(LocaleHelper.getSystemEncoding());
IPentahoSession userSession = PentahoHttpSessionHelper.getPentahoSession( request );
String content = «  »;
ISolutionRepository solutionRepository = PentahoSystem.get(ISolutionRepository.class, userSession);
solutionRepository.reloadSolutionRepository(userSession, userSession.getLoggingLevel());
content = « OK refresh »;
%>
<%= content %>

Je n’ai plus qu’à  déployer cette page dans le répertoire suivant :

biserver-ce/tomcat/webapps/pentaho/jsp/

Une fois fait, je peux maintenant piloter le refresh  en faisant  :

https://monserveur:8080/pentaho/RefreshRepository?userid=totologin&password=XXXX

Du coup je peux piloter le refresh  par script Shell :

 wget  –quiet  -O – « https://monserveur:8080/pentaho/RefreshRepository?userid=totologin&password=XXXX »

tip trac/ldap : usage de ldap-filter

Il y a quelques temps j’ai dû ouvrir à des personnes externes un site de gestion d’incidents ( trac). Il se trouve que nous gérons les clients comme des contacts dans notre système openldap.
En gros un client a type a comme structure dans ldap :

dn: cn=jean Filemonpul,ou=clients,ou=Users,dc=masociete,dc=com
cn: jean Filemonpul
givenname: jeanfil
mail: jean.filemonpul@parlespieds.com
mobile: +33473000011
objectclass: inetOrgPerson
objectclass: extensibleObject
objectclass: person
objectclass: mailAccount
objectclass: top
ou: client
sn: filmonpul
uid: jfil
userpassword: {MD5}9×2+54ef34zeLOL4OneqsqsrSUgXUlsdsg==se

Par opposition, un utilisateur interne a cette structure:

dn: cn=pikki@masociete.com,ou=Users,dc=masociete,dc=com
cn: pikki@masociete.com
givenname: pikki
mail: pikki@masociete.com
mailbox: /home/vmail/masociete.com/pikki
mailenable: OK
mailuserquota: 1048576
mobile: +336XXXXXXXX
objectclass: inetOrgPerson
objectclass: extensibleObject
objectclass: person
objectclass: mailAccount
objectclass: top
ou: masociete
sn: pikki
uid: pikki
userpassword: {MD5}q09j+fqgfg4645refgzereza33454==

 La grosse différence est donc l’unité organisationnelle ( ou)  qui est soit « masociete » soit « client ».
On veut donc autoriser l’accès au gestionnaire d’incident ( trac) à ces deux profils.
Pour cela, dans le fichier de configuration dans /etc/apache2/sites-enabled on va utiliser l’instruction Require ldap-filter dont la doc est à  cette adresse .

Le truc est de savoir si la requête ldap va fonctionner ou pas. pour cela j’ai testé cette requete: 

ldapsearch -W -x -D « cn=moimeme,dc=masociete,dc=com » '(|(ou=masociete)(ou=client))'

qui veut dire: << cherche toutes les entrées du ldap ayant comme "ou" soit "masociete", soit "client" >> .Nickel, il me renvoie bien des entrées. Du coup, je me dis, je vais mettre ça dans mon fichier de config apache : 

Require ldap-filter (|(ou=client) (ou=masociete))

katastrof, en rechargeant apache( service apache2 reload)  , impossible de se connecter ni en tant que client , ni en tant qu’utilisateur.

Il suffit juste d’enlever les parenthèses les plus excentrées pour que ça marche ( va comprendre..) .


Voici mon fichier de configuration: 

 ServerAdmin admin-system@masociete.com
 ServerName tickets.masociete.com
 DocumentRoot /var/www/tickets
 
  Options FollowSymLinks MultiViews
   AllowOverride AuthConfig
 

 
  Options +SymLinksIfOwnerMatch
  AllowOverride All
  Order allow,deny
  Allow from all
 

 ErrorLog /var/log/apache2/trac/error.log
 LogLevel warn
 CustomLog /var/log/apache2/trac/access.log combined
 ServerSignature On
  #set up Trac handling
  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnv /var/www/tickets
  PythonOption TracUriRoot /
  PythonPath « sys.path + [‘/var/www/tickets’] »
 

 
  AuthType Basic
  AuthName « LDAP auth »
  AuthBasicProvider ldap
  AuthLDAPUrl ldap://127.0.0.1/ou=Users,dc=masociete,dc=com?uid?sub
  AuthLDAPBindDN « cn=rechercheuser,dc=masociete,dc=com »
  AuthLDAPBindPassword XXXXXXX
  Require ldap-filter |(ou=client) (ou=masociete)