Le Blog de C-quad

Archive pour juin 2011

Installer SpagoBI 3.0 sur Fedora


Même si ce blog ne le reflète pas, je suis ingénieur décisionnel et mes activités professionnelles sont clairement BI et très peu Open Source. J’ai eu la joie de pouvoir concilier un peu les 2 avec Talend. Et maintenant, je compte essayer de le faire aussi dans la mesure du possible avec SpagoBI.

Pour reprendre la définition de wikipedia : SpagoBI est la seule suite pour la Business Intelligence entièrement open source, une solution faisant partie de l’initiative libre/open source SpagoWorld, fondée et soutenue par Engineering Group.

SpagoBI tourne sur un serveur d’application. J’ai donc choisi Tomcat qui est disponible dans les dépôts de base, mais il est tout à fait possible d’utiliser Jonas ou JBoss.

Mise à jour 27/07/2011 :

  • A noter que peu de temps après la version 3.0 SpagoBI a publié une nouvelle version 3.1. Cette version corrige notamment les divers bug que j’avais remonté dans cet article.
  • A noter qu’une nouvelle version de tomcat a été déployée sur les dépots fedora et qu’elle corrige le bug remonté dans cet article

Il est donc désormais beaucoup plus simple de mettre en place SpagoBI dès l’instant que l’on installe la dernière version sur une Fedora à jour de ses mises à jour.

Téléchargement de SpagoBI

Avant de commencer, il faut télécharger les fichiers :

directement sur la forge de Spagoworld

Pour cet article nous n’utiliserons que mysql-dbscript-3.0.0_06152011.zip et SpagoBI-bin-3.0.0_06152011.zip

Je vous invite a tester les divers moteurs fournis. Je compte vous présenter pour ma part le moteur QbeEngine dans un futur article.

A noter que SpagoBI 3.0 est très récent, il est donc très difficile voire même impossible de trouver une documentation sur cette version.

Préparation de la base de données

SpagoBI peut s’installer sur Ingres, Mysql, Oracle et Postgresql. Il s’agit la des tables qui servent au moteur de SpagoBI. L’outil en lui même est capable de se connecter à n’importe quelle base de données dès l’instant qu’il est possible d’y établir une connexion jdbc.

Nous allons donc l’installer sur une base de données MySQL.

Commençons par créer un utilisateur :

CREATE USER 'SpagoBI'@'%' IDENTIFIED  BY  '***';
GRANT  USAGE  ON  *  .  *  TO  'SpagoBI'@'%' IDENTIFIED  BY  '***' WITH  MAX_QUERIES_PER_HOUR 0  MAX_CONNECTIONS_PER_HOUR 0  MAX_UPDATES_PER_HOUR 0  MAX_USER_CONNECTIONS 0 ;
CREATE  DATABASE IF  NOT  EXISTS  `SpagoBI` ;
GRANT  ALL  PRIVILEGES  ON  `SpagoBI`  .  *  TO  'SpagoBI'@'%';

Nous pouvons ensuite nous connecter avec cet utilisateur et lancer la création des tables :

$ mysql -u SpagoBI -p SpagoBI < MySQL_create.sql
$ mysql -u SpagoBI -p SpagoBI < MySQL_create_quartz_schema.sql

Nous sommes maintenant prêt à installer SpagoBI sur le serveur d’applications.

Installation et configuration de Tomcat

L’installation de Tomcat se fait comme d’habitude simplement avec yum

# yum install tomcat6*

Nous allons nous connecter à une base de donnée mysql il nous faut donc le connecteur :

# yum install mysql-connector-java

On ajoute ce driver dans les libraires de tomcat :

# ln -s /usr/share/java/mysql-connector-java.jar /usr/share/tomcat6/lib/

Il est maintenant nécessaire de définir un utilisateur dans tomcat, pour se faire éditer le fichier /etc/tomcat6/tomcat-users.xml et ajouter les lignes suivantes dans la section tomcat-users :

<role rolename="manager"/>
<user username="tomcat" password="tomcat" roles="manager"/>

Nous allons maintenant configurer la connexion à la base de données précédemment crée, pour cela éditer le fichier /etc/tomcat6/server.xml.
On ajoutera dans la section GlobalNamingResources

<GlobalNamingResources>

<Resource name="UserDatabase" auth="Container"
          type="org.apache.catalina.UserDatabase"
          description="User database that can be updated and saved"
          factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
          pathname="conf/tomcat-users.xml" />

<Environment name="spagobi_resource_path" type="java.lang.String" value="webapps/resources"/>
<Environment name="spagobi_sso_class" type="java.lang.String" value="it.eng.spagobi.services.common.FakeSsoService"/>
<Environment name="spagobi_service_url" type="java.lang.String" value="http://localhost:8080/SpagoBI"/>
<Environment name="spagobi_host_url" type="java.lang.String" value="http://localhost:8080"/>

<Resource name="jdbc/spagobi" auth="Container" type="javax.sql.DataSource"
          maxActive="100" maxIdle="30" maxWait="10000"
          username="SpagoBI" password="SpagoBI" driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/SpagoBI"/>

 </GlobalNamingResources>

Nous pouvons maintenant démarrer tomcat :

# service tomcat6 start

Une fois tomcat démarré nous pouvons nous rendre sur la page d’accueil de Tomcat à l’adresse suivante : http://localhost:8080/

Vous devriez obtenir un écran similaire à celui ci-dessus.

Nous allons dans Tomcat Manager. Un login/mot de passe vous est demandé, il correspond à celui que vous avez renseigné dans le fichier tomcat-users.xml. Dans notre cas c’est tomcat/tomcat.

Il faut ensuite décompressé l’archive SpagoBI-bin-3.0.0_06152011.zip téléchargée précédemment. Vous obtenez donc un fichier nommé SpagoBI.war. Il faut déployer ce fichier sur tomcat :

Tomcat Manager -> Deployer – Parcourir -> Sélectionner SpagoBI.war et cliquer sur déployer

Et maintenant il ne nous reste plus qu’a aller à l’adresse http://localhost:8080/SpagoBI pour admirer un joli portail … ah non une erreur :

Si l’on va voir dans le fichier /var/log/tomcat6/SpagoBI.log on trouve l’erreur suivante :

find datasource: java:/comp/env/jdbc/spagobi
javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory]
 at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:118)
 at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:140)

Cette erreur vient du fait que tomcat ne va pas chercher BasicDataSourceFactory dans le bon paquet. Il est nécessaire de modifier le fichier /etc/sysconfig/tomcat6 en ajoutant la ligne suivante :

# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"
JAVA_OPTS="${JAVA_OPTS} -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory"

Ce problème a été déposé sur le bugzilla redhat : https://bugzilla.redhat.com/show_bug.cgi?id=669969

Il nous reste ensuite à redémarrer tomcat6

# service tomcat6 restart

Et nous pouvons voir le joli portail … ah non même écran :-(

Allons voir la log :

at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'SpagoBI.hibernate_sequences' doesn't exist
 at sun.reflect.GeneratedConstructorAccessor37.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:407)

Le problème c’est qu’il y a beaucoup trop de développeur sous Windows…  La table hibernate_sequences existe pourtant bien, mais en majuscule. Vu que mysql stocke ses données dans des fichiers qui portent les mêmes noms que les tables, la casse a son importance sur les systèmes d’exploitation ou le système de fichier fait la différence entre majuscules et minuscules.

Il nous suffit donc de recréer la table en minuscules :

drop table HIBERNATE_SEQUENCES;

CREATE TABLE IF NOT EXISTS `hibernate_sequences` (
 `SEQUENCE_NAME` varchar(200) NOT NULL,
 `NEXT_VAL` int(11) NOT NULL,
 PRIMARY KEY (`SEQUENCE_NAME`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

edit : il existe une solution plus simple pour renommer une table 😉

RENAME TABLE `SpagoBI`.`HIBERNATE_SEQUENCES`  TO `SpagoBI`.`hibernate_sequences` ;

edit2: J’ai créé un rapport de bug sur SpagoWorld : bug 623

Il est nécessaire de redémarrer le serveur tomcat6 suite à cette modification.

Et enfin nous voila sur la page d’accueil de SpagoBI :


Il nous reste à nous identifier avec le login biadmin/biadmin :

Je compte essayer de vous présenter les diverses fonctionnalités de ce produit prochainement. (Quand j’aurais réussi à  les faire tourner ;-))

autohebergement et fortes chaleurs

Bonsoir,

Certains l’auront peut être constaté, mon blog était inaccessible aujourd’hui, cet après midi pour être précis. Je pensais que c’était une surchauffe du serveur et que le système de ventilation mis en place n’était pas suffisant.

Mais en réalité, mon blog était inaccessible à cause de la surchauffe d’un boitier CPL. Je sais bien qu’on ne peux difficilement mieux faire qu’un vrai câble Ethernet niveau fiabilité. Mais vu que l’ordinateur tourne 24/24, je veux limiter au mieux les désagréments et donc le pc est situé dans un lieu que je ne peux câbler facilement.

Je constate après coup que la température dans la pièce est montée à 45 degrés… Le boitier CPL a laché en premier, mais je pense qu’il ne fallait pas beaucoup plus pour que l’ordinateur se sache plus se refroidir non plus.

J’ai ajouté un puissant ventilateur fonctionnant sur le 220v qui souffle directement sur le boitier CPL en attendant de trouver une solution plus pérenne.

Quelles solutions avez vous mis en place en général, pour pallier à ces fortes chaleur dans le cas de pc qui tournent 24/24  ?

 

Augmenter la taille d’un disque virtuel vdi sous VirtualBox

Il m’arrive fréquemment d’utiliser des machines virtuelles pour tester tout un tas de choses.
Par défaut, je donne en général 8Giga maximum au disque dur virtuel.
Il est vrai qu’en n’allouant pas la place tout de suite je pourrais être moins avare en disque, mais cela me permet aussi de bien maitriser le volume total qui pourra être utilisé par les machines virtuelles.

Malheureusement, 8 Giga ne sont pas toujours suffisant. Deux solutions s’offrent à nous :

1) Ajouter un nouveau vdi en plus de l’existant
2) étendre le disque virtuel existant

La première solution c’est comme si vous ajoutiez un nouveau disque dur à votre ordinateur.
Il suffit donc d’ajouter un nouveau vdi, et sur la machine virtuelle ajouter le nouveau disque à LVM il vous restera ensuite à distribuer la volumétrie disponible au volume groupe et logique qui sont à l’étroit.

Je vais donc détailler la solution 2.

Étendre le disque virtuel

Cette solution n’est pas réalisable dans l’interface graphique, il sera nécessaire de passer par une ligne de commande

VBoxManage modifyhd MonDisque.vdi --resize 20000

Cette commande permet de redéfinir la taille du disque à 20 Giga.

Étendre sur la machine virtuelle

On constate bien dans VirtualBox que le disque est passé à 20 giga.

Créer une partition

Il est nécessaire de créer une partition dans l’espace disponible, je vous conseille si vous avez une interface graphique d’utiliser l’excellent Gparted, sinon il vous reste fdisk …


Ma machine virtuelle utilise LVM, il n’est donc pas nécessaire de formater la partition, ni de choisir un système de fichier.

LVM

L’objectif est maintenant d’ajouter la volumétrie au système grâce à LVM.
On peux le faire soit via l’interface graphique (system-config-lvm), soit directement ligne de commande. Je vous présente ci dessous les captures d’écran de la méthode par l’interface graphique ainsi que les commandes à lancer pour ceux qui doivent passer par le terminal.

Nous allons commencer par initialiser la volumétrie ajoutée.

Cliquer sur « initialiser l’entité ». Cela va créer un « volume physique » ce qui correspond à lancer la commande suivante :

# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created

On a maintenant un volume physique qui n’est pas alloué.

# pvs
PV         VG          Fmt  Attr PSize PFree
/dev/sda2  vg_fedora14 lvm2 a-   9,50g    0
/dev/sda3              lvm2 a-   9,53g 9,53g

On choisi donc d’ajouter le volume physique au « groupe de volume » existant (vg_fedora14 ici), ce qui se fera via la commande :

# vgextend vg_fedora14 /dev/sda3
Volume group "vg_fedora14" successfully extended

Il faut maintenant étendre le volume logique

Cliquer sur « éditer les propriétés » et choisir ce que vous désirez faire.
Ce qui correspond à la commande suivante :

# lvdisplay
--- Logical volume ---
LV Name                /dev/vg_fedora14/lv_root
VG Name                vg_fedora14
LV UUID                mB1JCC-N7VF-YSZA-IaTt-W3Ch-GylR-Czg7WB
LV Write Access        read/write
LV Status              available
# open                 1
LV Size                7,56 GiB
Current LE             242
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:0

--- Logical volume ---
LV Name                /dev/vg_fedora14/lv_swap
VG Name                vg_fedora14
LV UUID                9NZFBl-T10T-Wdt5-2AIX-WTxI-NjxT-Ubp2TR
LV Write Access        read/write
LV Status              available
# open                 1
LV Size                1,94 GiB
Current LE             62
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:1

Pour connaitre le nom des volumes logiques disponibles. Le volume que je compte étendre c’est « lv_root ».

# lvresize --size +5G /dev/vg_fedora14/lv_root
Extending logical volume lv_root to 12,56 GiB
Logical volume lv_root successfully resized

Il faut ensuite adapter la taille du filesystem au volume, grâce à la commande resize2fs :

# resize2fs /dev/vg_fedora14/lv_root
resize2fs 1.41.12 (17-May-2010)
Le système de fichiers de /dev/vg_fedora14/lv_root est monté sur / ; le changement de taille doit être effectué en ligne
old desc_blocks = 1, new_desc_blocks = 1
En train d'effectuer un changement de taille en ligne de /dev/vg_fedora14/lv_root vers 3293184 (4k) blocs.
Le système de fichiers /dev/vg_fedora14/lv_root a maintenant une taille de 3293184 blocs.

Et voila on a désormais un peu plus de place :

# df -h /
Sys. de fichiers                   Taille  Uti. Disp. Uti% Monté sur
/dev/mapper/vg_fedora14-lv_root       13G  6,2G  5,6G  53% /

Forcer l’utilisation d’une résolution avec Xrandr

Ce weekend j’avais besoin d’utiliser la 2ème sortie vidéo de mon netbook pour le connecter à un vidéoprojecteur. Je branche donc le vidéoprojecteur, il est bien détecté et j’ai bien une image qui s’affiche.  Néanmoins, la résolution affichée ne me satisfait pas.

J’ai beau chercher, sous Gnome 3, je peux effectivement changer la résolution, mais uniquement vers une résolution plus basse. Ce qui bien sur n’est pas mon objectif. La résolution de mon vidéoprojecteur n’est pas détectée, et je suis donc en 1024×768, alors qu’il est capable de faire du 1280×720.

La solution pour ajouter une nouvelle résolution passe par Xrandr.

Lancer la commande xrandr sans arguments va permettre d’en savoir un peu plus sur la configuration actuelle et les résolutions possibles:

$ xrandr
Screen 0: minimum 320 x 200, current 2048 x 768, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 222mm x 125mm
 1024x600       60.0*+
 800x600        60.3     56.2 
 640x480        59.9 
VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm
 1024x768       60.0*
 800x600        60.3     56.2 
 848x480        60.0 
 640x480        59.9

La résolution 1280×720 n’est pas disponible, nous allons utiliser la commande cvt pour avoir la bonne ligne à ajouter:

$ cvt 1280 720
# 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz
Modeline "1280x720_60.00"   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync

il nous suffit de recopier le modèle affiché et de créer le nouveau mode avec xrandr :

$ xrandr --newmode "1280x720_60.00"   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync

vous pouvez vérifier que le mode a bien été créé en lancant xrandr sans arguments:

$ xrandr
Screen 0: minimum 320 x 200, current 2048 x 768, maximum 4096 x 4096
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 222mm x 125mm
 1024x600       60.0*+
 800x600        60.3     56.2 
 640x480        59.9 
VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm
 1024x768       60.0*
 800x600        60.3     56.2 
 848x480        60.0 
 640x480        59.9 
 1280x720_60.00 (0xc5)   74.5MHz
 h: width  1280 start 1344 end 1472 total 1664 skew    0 clock   44.8KHz
 v: height  720 start  723 end  728 total  748           clock   59.9Hz

Il nous reste maintenant à associer cette résolution à l’écran :

$ xrandr --addmode VGA1 1280x720_60.00

et pour appliquer la résolution :

$ xrandr --output VGA1 --mode 1280x720_60.00

La résolution est désormais correcte, néanmoins gnome-shell utilise 90% du CPU en continu suite à cette modification… donc ce n’est pas pleinement satisfaisant.
A noter que la même action sur Fedora 14 fonctionne parfaitement pour moi.