Ce message peut être présent, qu'on utilise le logiciel client OpenERP ou bien qu'on utilise l'interface web du logiciel client-web OpenERP avec un navigateur internet. Ce message indique que le logiciel client OpenERP ou le logiciel client-web ne parviennent pas à dialoguer avec le serveur OpenERP. Tant qu'il est présent, rien n'est possible.

Comment analyser la situation et remédier au problème ?

Cet article traite du cas de l'utilisation d'un environnement Linux, mais les utilisateurs d'OpenERP sous Windows pourront sans doute s'inspirer de la méthode de diagnostique proposée.

1_Vérifier les paramètres de connexion au serveur

Bien sûr, ce message est attendu si une erreur s'est glissée dans les paramètres utilisés pour se connecter au serveur.

Sur le client OpenERP, ces paramètres sont simplement modifiables sur la petite fenêtre de connexion. Faites bien correspondre les trois éléments suivants

  • le nom du serveur
  • le port du serveur
  • le protocole du serveur

Sur le client-web OpenERP, ces paramètres concernent la communication entre le logiciel client-web OpenERP et le logiciel serveur OpenERP. Ils sont fixés au démarrage du logiciel client-web OpenERP, dans le fichier de configuration du logiciel. Il vous faut trouver ce fichier sur le serveur qui fournit le service client-web et le modifier par un éditeur de texte, puis relancer le logiciel client-web OpenERP. Si vous n'avez pas accès à ce fichier, votre administrateur système doit le faire pour vous.

Cas particuliers concernant le client-web OpenERP :

  • Si vous utilisez l'outil xoe fourni par SISalp. Les paramètres utilisés par le logiciel client-web OpenERP sont modifiables par la commande
su utilisateur_unix_qui_va_bien
xoe --config -edit

qui ouvre l'éditeur disponible (vi ou gedit) . Les paramètres à adapter pour le logiciel client-web se trouvent sur la ligne commençant par etiny:lambda: pour le serveur nommé lambda, ils doivent être conformes aux paramètres du serveur OpenERP qui se trouvent sur la ligne commençant par service:lambda: sur la machine qui tourne le serveur OpenERP.

  • Si vous utilisez un serveur OpenERP On-Line ONL ou OES mis à disposition par SISalp et bdll.fr, si ce message apparaît dans votre navigateur quand vous utilisez l'interface web : C'est une anomalie, signalez-la selon les instructions que vous avez reçues.

Le problème a t-il été résolu ? Si oui, poursuivez votre utilisation en créant votre première base de données. Sinon, continuons nos recherches.

2_Est-ce un problème de résolution de nom du serveur ?

Si vous utilisez le client OpenERP : Tentez d'utiliser directement l'adresse IP du serveur en lieu et place du nom du serveur dans les paramètres de connexion du client OpenERP.

Cas particuliers:

  • Votre serveur devrait être démarré avec cette adresse ip explicitement passée en paramètre ( --interface=xxx.xxx.xxx.xxx), certaines versions ne sachant sinon servir des clients locaux.
  • Si vous utilisez un serveur OpenERP On-Line ONL ou OES, ne tentez pas d'utiliser l'adresse ip au lieu du sous domaine qui est le votre avec le client-web et le navigateur. Sur les serveurs SISalp, votre propre adresse ip serait automatiquement blacklistée jusqu'au lendemain. Vous ne devez utiliser l'adresse ip qu'avec le client OpenERP et sur le port qui vous est assigné.

3_Le serveur OpenERP et le serveur de base de données sont-ils en fonctionnement ?

A partir de maintenant vous devez disposer d'un accès sur la machine qui offre le service du logiciel serveur OpenERP. Si vous n'y avez pas accès, vous devez maintenant vous tourner vers votre administrateur système et poursuivre l'analyse avec lui.

Tout d'abord vérifier que le serveur Postgresql est bien en fonctionnement par la commande

ps aux | grep "postgres"

Si vous trouvez votre processus comme /usr/lib/postgresql/8.3/bin/postgres sur un serveur Debian-Linux, le serveur de base de données est en fonctionnement. Attention, la commande ci-dessus fait apparaître une ligne supplémentaire "grep postgres" qui n'est pas votre processus.

Ensuite vérifier que le serveur OpenERP est bien en fonctionnement par la commande

ps aux | grep "openerp-server.py"

Si vous trouvez votre processus python, le serveur est en fonctionnement. Attention, la commande ci-dessus fait apparaître une ligne supplémentaire "grep openerp-server.py" qui n'est pas votre processus.

Si le processus du serveur de base de données n'est pas présent, il faut le démarrer avec les privilèges root :

/etc/init.d/postgresql-8.3 start

Si le processus du serveur OpenERP n'est pas présent, il faut le démarrer sur le serveur OpenERP et contrôler sa trace log. Si le serveur ne survit pas, vérifier l'installation des dépendances et la version du code OpenERP utilisé.

Cas particuliers :

  • Si vous utilisez xoe, la commande
xoe --status lambda

vous résume l'ensemble des paramètres du service OpenERP lambda, la commande

xoe --start lambda

démarre le serveur OpenERP pour le service lambda et la commande

xoe --log lambda

vous présente la trace log du démarrage.

Ces actions ont-elles résolu le problème ? Sinon, vérifions les autres points critiques

4_Vérification de la liaison entre le Serveur OpenERP et le serveur de base de données.

Il se peut qu'OpenERP refuse les sollicitations des logiciels clients parce que lui même ne peut accéder aux fonctions du serveur de base de données.

Il faut regarder de près la trace log du serveur OpenERP lors de son démarrage et remarquer un message indiquant qu'il n'accède pas à postgresql, puis vérifier dans le log de postgresql (dans /var/log) qu'il n'a pas rejeté de demande venant d'OpenERP.

Dans ce cas, il faut mettre en concordance les paramètres utilisés par le serveur OpenERP, précisés en option de la commande ou dans le fichier de configuration du démarrage, et les paramètres d'autorisation de postgresql qui se trouvent dans le fichier pg_hba.conf. Dans le cas d'un serveur sous Debian-Linux :

cat /etc/postgresql/8.3/main/pg_hba.conf

Pour connaître les options possibles au démarrage du serveur OpenERP, utiliser l'option -h ou --help

./openerp-serveur.py --help

Cas particuliers

  • Si vous utilisez xoe, chaque service dispose d'un rôle postgres qui lui est réservé et le fichier pg_hba a été adapté en conséquence. La commande
xoe --pg -list -db

vous donne la liste des bases postgres éxistentes et la commande

xoe --pg -list -user

la liste des rôles postgres déclarés, enfin la commande

xoe --pg -help lambda

vous fourni la liste des options de démarrage disponibles sur le serveur OpenERP du service lambda. Enfin, vous pouvez lancer le service OpenERP lambda en mode terminal pour suivre sa trace pas à pas avec la commande

xoe --start -terminal lambda

Si le problème est résolu, notez la solution quelque part pour la retrouver plus tard. Sinon, il reste à suspecter la liaison réseau avec le serveur OpenERP

5_Contrôler que le client OpenERP est relié au serveur OpenERP par le réseau

En cas de problème sur le réseau, le message "Impossible de se connecter au serveur !" apparaîtra également. C'est notre dernière chance d'explication puisque nous avons maintenant vérifié que toute la chaîne des logiciels est opérationnelle.

Un moyen rapide pour valider la continuité du réseau entre le poste de travail et le serveur OpenERP est d'utiliser le navigateur internet et de l'utiliser pour tenter une connexion sur le serveur OpenERP, en indiquant dans la ligne d'url les paramètres destinés au client OpenERP.

Si votre serveur répond sur le protocole http, appelé xml-rpc,

pour un test de continuité avec le serveur de démonstration et test dev5.sisalp.net qui répond au port 8073 :

http://dev5.sisalp.net:8073

Dans l'exemple donné, vous obtenez une réponse explicite

Error response
Error code 501.
Message: Unsupported method ('GET').
Error code explanation: 501 = Server does not support this operation.

Puis de contrôler le log du serveur OpenERP qui ne doit pas manquer de crier et de menacer, car le navigateur ne respecte aucunement le protocole attendu par le serveur.

Si votre serveur répond sur le protocole https, appelé xml-rpc (secure),

remplacer http:// par

https://votre_serveur:votre_port

vous aurez peut-être un dialogue sur la validité du certificat, puis, si vous en suivez les étapes, ce qui n'est pas nécessaire car le réseau est d'ores et déjà validé, vous obtiendrez la même réponse que dans le cas précédent,

Une fois n'est pas coutume, si des messages d'erreur apparaissent dans le log du serveur OpenERP, c'est que le réseau fonctionne correctement entre le poste du client OpenERP et le serveur OpenERP. Si rien n'apparaît dans le log, il y probablement un problème à ce niveau.

Cette opération peut également être réalisée sur la machine qui fournit l'interface web en tournant le logiciel client-web OpenERP. On utilisera lynx qui ne nécessite pas d'interface graphique.

Voici l'exemple d'un test de continuité avec le serveur de démonstration et test dev5.sisalp.net qui répond au port 8073, sous Debian-Linux :

apt-get install lynx
lynx http://dev5.sisalp.net:8073
ou lynx https://votre_serveur:votre_port

qui doit également émouvoir le serveur OpenERP qui s'indignera dans son log si le réseau entre la machine client-web OpenERP et la machine serveur OpenERP fonctionne correctement.

Votre problème est-il résolu ? Je l'espère. Après de nombreuses mises en route, je n'ai jamais rencontré d'autres causes qui provoqueraient l'affichage de ce message.

D'autres informations peuvent vous être utiles sur le forum communautaire d'OpenERP sur lequel vous pouvez demander de l'aide.

Merci pour vos remarques et suggestions sur cette première version.