Après un mois d'utilisation du logiciel de GED Nuxeo DM, le bilan est plutôt négatif. Je pensais naïvement avoir mis la main sur une application correcte (comme elle est en JAVA, elle peut tout au plus être correcte). Un pré-requis très important pour moi était la possibilité d'utiliser MySQL comme moteur de base de données. En réalité, bien que Nuxeo supporte MySQL officiellement, l'usage de ce moteur est absolument découragé. Les développeurs listent une série de raisons somme-toute valables, et qui peuvent se résumer comme ceci : il aurait fallu coder Nuxeo pour qu'il supporte les spécificités de MySQL, et on a eu la flemme. En réalité, rien ne fonctionne vraiment correctement si on utilise Nuxeo avec MySQL. À tel point qu'il ne devrait même pas être possible de choisir ce serveur de base de données dans les menus de configuration de Nuxeo. Et c'est bien ça qui me met en rogne. J'ai perdu un mois, et de nombreuses heures de travail pour un logiciel qui oscille finalement entre le "peu fiable" et le "carrément inutilisable".
Entre alors en scène Alfresco. Un logiciel concurrent, codé lui aussi en (wait for it) JAVA. Ce dernier fonctionne très bien avec MySQL, je l'ai donc installé sans tarder pour me faire une opinion sur ses capacités. Les différences avec Nuxeo sont importantes.
Continue reading
Archives
Welcome to our Z410 Storage Beta program
C'est Noël ! Dommage que mes congés soient terminés...
Installation de Nuxeo DM sur FreeBSD, épisode 3
Avec un peu de travail, Nuxeo DM peut être abrité en HTTPS derrière un serveur Apache. Je fais l'impasse sur la configuration interne à Nuxeo, elle se fait très simplement à la première connexion via l'assistant fourni. Si vous êtes arrivés jusque là, il ne manque plus qu'un script de démarrage pour que tout fonctionne de manière transparente sur votre serveur.
Voici le contenu du script de lancement/arrêt pour une instance de Nuxeo DM, /usr/local/etc/rc.d/nuxeo. N'oubliez pas de remplacer la valeur de nuxeo_home par le chemin de votre répertoire nuxeo :
#!/bin/sh
# PROVIDE: nuxeo
# REQUIRE: DAEMON
# BEFORE: LOGIN
# Define these nuxeo_* variables in one of these files:
# /etc/rc.conf
# /etc/rc.conf.local
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
nuxeo_enable="${nuxeo_enable-NO}"
nuxeo_user="${nuxeo_user-nuxeo}"
nuxeo_home="/CHEMIN/DE/nuxeo"
. /etc/rc.subr
name="nuxeo"
rcvar=`set_rcvar`
start_cmd=${name}_start
stop_cmd=${name}_stop
nuxeo_start()
{
cd $nuxeo_home
$nuxeo_auditflags sudo -u $nuxeo_user ./bin/nuxeoctl startbg
}
nuxeo_stop()
{
cd $nuxeo_home
sudo -u $nuxeo_user ./bin/nuxeoctl stop
}
load_rc_config $name
run_rc_command "$1"
Une fois le fichier créé, rempli, et rendu exécutable, il faut ajouter ces quelques lignes à votre fichier /etc/rc.conf :
nuxeo_enable="YES" nuxeo_user="NUXEO_USER"
Vous remplacerez bien sûr NUXEO_USER par le nom du compte utilisateur qui fera tourner l'application Nuxeo DM. Après cela, les commandes /usr/local/etc/rc.d/nuxeo restart, /usr/local/etc/rc.d/nuxeo stop et /usr/local/etc/rc.d/nuxeo start doivent fonctionner.
Attention, suivant la puissance de votre machine, et l'état de remplissage de Nuxeo, le temps de lancement peut varier énormément.
Côté mise à jour, vous pouvez accéder aux "hotfix" officiels, gratuitement pendant 30 jours, moyennant une inscription sur le site web de Nuxeo. L'inscription se passe facilement, par contre les mise à jour sont délicates et nécessitent de suivre scrupuleusement les instructions du support Nuxeo. Notamment, relancez bien l'application entre chaque mise à jour.
Installation de Nuxeo DM sur FreeBSD, épisode 2
Une application Tomcat ne devrait pas se trouver nue sur internet. J'ai pour habitude de toujours placer un frontal Apache devant. Cela autorise divers améliorations du service. Apache peut par exemple gérer l'authentification des utilisateurs, faire une balance de charge entre plusieurs instances de l'application, etc. Il permet aussi à votre application d'être joignable sur les port HTTP(S) standard (80 et 443) sans que l'application doive être lancée en root (et sans recourir à une redirection dans votre firewall).
Il existe plusieurs moyens de présenter Nuxeo DM au travers d'un proxy Apache. J'ai choisi d'utiliser mod_proxy. Avec mod_proxy, la configuration est assez standard. Tout, ou presque, est réglé en 3 lignes si on se contente de l'HTTP. Mais pour sécuriser mes connexions à Nuxeo, qui contiendra mes documents personnels et confidentiels, j'ai décidé d'utiliser HTTPS.
J'ai donc un virtual host Apache, et un certificat SSL associé, dans le quel j'inclue les directives de mod_proxy.
<VirtualHost IP.DU.SER.VEUR:443>
ServerName DOMAINE.TLD:443
UseCanonicalName On
DocumentRoot "/chemin/de/nuxeo/"
SSLEngine on
#... config SSL ...
RequestHeader append nuxeo-virtual-host "https://DOMAINE.TLD/"
<IfModule proxy_module>
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /nuxeo/ http://localhost:8080/nuxeo/
ProxyPassReverse /nuxeo/ http://localhost:8080/nuxeo/
ProxyPreserveHost On
</IfModule>
</VirtualHost>
Ça c'est d'après la documentation. En réalité, ce n'est pas suffisant. Tout d'abord, il faut bien placer la directive RequestHeader à l'extérieur du bloc proxy_module, sinon elle est juste ignorée par le serveur. Il ne m'a pas fallu moins qu'un tcpdump pour localiser le problème.
J'ai aussi constaté qu'avec ces directives, la première connexion à l'application se fait bien, puis on est immédiatement redirigé vers le même virtual host mais sur le port 80. Je règle le problème avec une directive de redirection dans le vhost http :
<VirtualHost *>
ServerName DOMAINE.TLD
DocumentRoot /chemin/de/nuxeo
Redirect / https://DOMAINE.TLD/
</VirtualHost>
Ce n'est pas totalement satisfaisant, mais faute de mieux, cela fonctionne parfaitement.
En relançant Apache à ce stade, on obtient un proxy fonctionnel et sécurisé par SSL pour Nuxeo.
Avant d'aller plus loin, on peut prendre quelques minutes pour créer une base de données MySQL (ou autre) et un utilisateur MySQL associé à cette base. C'est ce compte de base de données qu'il faudra fournir au moment de la configuration de Nuxeo.
Je fais totalement l'impasse sur la configuration de Nuxeo DM dans le "wizard", elle est bien documentée, et plutôt simple. Il suffit de lancer l'application par la commande ad-hoc si ce n'est pas déjà fait :
# cd /chemin/du/répertoire/nuxeo # sudo -u nuxeo_user ./bin/nuxeoctl startbg
Ensuite on se connecte à l'adresse https://DOMAINE.TLD/nuxeo et on peut entamer la configuration.
Installation de Nuxeo DM sur FreeBSD, épisode 1
J'ai récemment choisi Nuxeo DM comme application de GED. C'est une application en JAVA, tournant dans un serveur d'application Tomcat. Nuxeo est packagé sous différentes formes, une seule est utilisable sur FreeBSD : Nuxeo DM Tomcat bundle.
L'installation de Nuxeo sur FreeBSD nécessite trois choses : installer les pré-requis logiciels, configurer l'environnement pour sécuriser l'application, et configurer l'application elle-même.
Côté pré-requis, il faut tout d'abord installer le Java Runtime Environment, et le Java Development Kit. Sous FreeBSD, il faut donc installer les ports java/diablo-jdk16 et java/diablo-jre16. Pour une question de licence, il faut télécharger à la main les packages nécessaires chez Oracle. Il suffit simplement de suivre les instructions obtenues pour chaque port au moment du make. Par exemple :
$ cd /usr/ports/java/diablo-jdk16/ $ make ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for diablo-jdk-1.6.0.07.02_12 Because of licensing restrictions, you must fetch the distribution manually. Please open http://www.oracle.com/technetwork/java/javase/downloads/index.html in a web browser and follow the "Download" link for "JDK DST Timezone Update Tool - 1_3_42" to obtain the time zone update file, tzupdater-1_3_42-2011k.zip. Please place the downloaded file(s) in /usr/ports/distfiles. ...
Une fois les ports java/diablo-jdk16 et java/diablo-jre16 installés, il faut installer un serveur web comme Apache 2.2, un serveur de bases de données (MySQL ou PostgreSQL par exemple), et à minima pdftohtml. Il est aussi possible d'installer OpenOffice, mais comme il n'existe pas de version "headless" dans les ports de FreeBSD, cela vous embarque dans l'installation complète avec gestionnaire de fenêtre et tutti quanti. Une calamité.
Pour utiliser l'application sur une connexion sécurisée (HTTPS), il faut qu'Apache dispose d'un certificat SSL adéquat.
Quand tout ceci est installé et configuré, il faut encore ajouter un compte utilisateur pour l'application Nuxeo. Les paresseux pourront la faire tourner sous le compte www. J'ai préféré un utilisateur indépendant, plus facile à tracer via auditd et l'accounting.
On peut alors télécharger et décompresser le package multiplateforme à partir du site internet de Nuxeo. On obtient un répertoire nommé nuxeo-dm-5.4.2-tomcat. J'ai pour habitude d'exploiter une application à partir d'un répertoire ne portant pas de numéro de version. On aura intérêt à renommer ce répertoire en nuxeo, car ici, faire un lien symbolique de nuxeo-dm-5.4.2-tomcat vers nuxeo ne donne pas vraiment satisfaction.
Pour en finir avec les fichiers, il faut faire un chown -R sur le répertoire nuxeo pour que les fichiers appartiennent tous à l'utilisateur non privilégié que l'on a créé plus haut.
Ensuite, comme nous sommes sur FreeBSD et pas Linux, il faut revoir certains scripts shell. Ces derniers ont un shebang qui pointe vers /bin/bash alors que notre bash est dans /usr/local/bin/. Les scripts à modifier sont les suivants : bin/monitorctl.sh, bin/nuxeoctl, bin/pack.
Arrivé là, il est intéressant de lancer l'application via la ligne de commande pour tester qu'au moins elle se lance et répond sur le port 8080 :
# cd nuxeo # sudo -u nuxeo_user ./bin/nuxeoctl startbg ... No current configuration, generating files... Configuration files generated. Server started with process ID 1438.
Le serveur est lancé, et il écoute bien sur le port 8080 :
# netstat -alnf inet | grep 8080 tcp4 0 0 *.8080 *.* LISTEN
Ce que l'on peut aisément vérifier avec un client HTTP en ligne de commande, ou un coup de telnet :
$ curl http://127.0.0.1:8080 <META HTTP-EQUIV="refresh" CONTENT="0;URL=/nuxeo">
On a maintenant une application Tomcat/Java qui tourne sur notre serveur FreeBSD, sous un compte utilisateur dédié. Il reste à brancher devant un proxy Apache HTTPS, créer un script de démarrage automatique pour l'application, et configurer cette dernière.
La suite au prochain épisode :)
Utiliser auditd sur Mac OS X et FreeBSD – 3
Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD - 2
Exploiter les résultats de l'audit
Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd. Continue reading
Utiliser auditd sur Mac OS X et FreeBSD – 2
Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD - 1
Configuration : quid des utilisateurs comme www ?
J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.
À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :
# pour freebsd remplacer _www par www _www:fc,fd,ex:
Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.
Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.
En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.
curl -LO http://www.freebsd.org/~csjp/setaudit.c cc -o setaudit -lbsm setaudit.c
Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :
setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache
Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :
setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart setaudit -a _www -m ex /usr/sbin/apachectl restart
Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.
Pour résumer :
- Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier
audit_control, et gérer les cas particuliers dansaudit_user. - Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à
setauditpour activer l'audit au moment du lancement du service correspondant. - Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.
Utiliser auditd sur Mac OS X et FreeBSD – 1
FreeBSD et les versions récentes de Mac OS X sont livrées avec un système d'audit intégré, dérivé du Basic Security Module de SUN, et disponible en logiciel libre sous le nom d'OpenBSM. Ce système d'audit se décompose en deux parties : un ensemble d'appels systèmes dédiés et de librairies d'un côté, et des logiciels "utilisateur" de l'autre. Sauf précision contraire, les explications présentées ici sont valables à la fois pour FreeBSD 7 et 8, et Mac OS X 10.6. Dans cette série d'articles je ne vais aborder que l'aspect "utilisateur" du système d'audit : comment l'activer, comment le configurer, comment exploiter les résultats.
Le système d'audit fourni par OpenBSM a pour but la surveillante des actions des utilisateurs. Un certain nombre d'évènements peuvent être mis sous surveillance, pour tout ou partie des utilisateurs. Quand le système d'exploitation détecte qu'un utilisateur sous surveillance génère un des évènements à surveiller, il averti le démon auditd qui se charge de reporter cet évènement dans un fichier de log. Continue reading