[obsolète] Installation de Crème CRM 1.7 sous Linux

[genglert]

Introduction

Pour ce tutoriel d'installation de Crème CRM sous Linux on va faire les choses du mieux possible. On va donc installer des choses qui pourraient vous sembler inutiles mais qui à terme permettront d'avoir une installation pérenne et qui ne rentrera pas en collision avec d'autres logiciels que vous pourriez vouloir installer.

Enfin, le tutoriel va être en deux parties, la première partie vous permet d'installer tout le nécessaire pour faire fonctionner Crème avec le serveur de développement intégré dans Django. Le serveur de développement n'est pas une façon pérenne de faire fonctionner une application Django. Mais c'est un moyen simple de vérifier que tout fonctionne et vous pouvez faire quelques tests avec pour vérifier que Crème vous convient.

La deuxième partie du tutoriel vous permettra d'utiliser Apache pour faire tourner votre Crème. Bien que plus compliqué à faire fonctionner, c'est une façon pérenne de faire les choses.

Une remarque très importante : si l'utilisation du serveur de développement est déconseillé pour une utilisation sur du long terme dans le cadre d'une machine personnelle, elle est par contre totalement interdite dans le cadre d'un hébergement sur un serveur. Si vous comptez installer Crème  tout de suite sur un serveur, il ne faut pas, pas une seule seconde, utiliser le serveur de développement. En effet celui-ci est fait pour le test et rien d'autre. Il n'est pas prévu, ni en terme de performance ni en terme de sécurité, pour être utilisé dans un vrai contexte de production.

Installation des bibliothèques "système"

On va donc commencer par installer Virtualenv. Virtualenv vous permet en effet d'avoir plusieurs environnements virtuels Python. L’intérêt est de pouvoir cloisonner les dépendances par projet. Vous êtes ainsi sûr que votre Crème n’arrêtera pas de fonctionner juste parce que vous avez dû mettre à jour une librairie Python pour pouvoir installer un autre logiciel. On ne va pas se contenter d'installer Virtualenv et on va installer aussi Virtualenvwrapper qui est une surcouche à Virtualenv et qui vous simplifiera les choses.

Pour installer tout cela, vous allez devoir commencer par installer python-setuptools et python-pip. Si vous êtes sous Debian ou Ubuntu il vous suffit de faire :

Code :

sudo apt-get install python-setuptools
sudo apt-get install python-pip

Ensuite, vous allez installer Virtualenvwrapper qui installera automatiquement Virtualenv en même temps.
Pour cela il vous suffit de taper :

Code :

sudo pip install virtualenvwrapper

Avant d'aller plus loin, il faut que vous vérifiez que les packages suivants sont bien installés, sinon, installez les :

• mysql_config libmysqlclient-devpython-devredis-serverlibxslt1-devdefault-jrelibjpeg-dev (et potentiellement les autres bibliothèques de gestion d'images selon vos besoins, comme libpng*-dev)graphvizgraphviz-dev

Installation de l'environnement virtuel

Nous allons va pouvoir créer le Virtualenv pour Crème.

Il reste une dernière petite config à faire, à savoir indiquer où vous allez stocker vos différents Virtualenv. Je vais partir du principe que vous utilisez le répertoire Envs à la racine de votre home. Il va falloir que dans le fichier de configuration de votre shell (.bashrc si vous utilisez le bash) vous configuriez la variable WORKON_HOME. Cela se fait de la manière suivante (pour bash)

Code :

export WORKON_HOME=~/Envs

Une fois cela fait et après avoir rechargé votre configuration, vous pouvez créer votre Virtualenv en tapant la commande :

Code :

mkvirtualenv creme

L'option –no-site-packages permet d'être sûr que votre Virtualenv sera bien isolé de votre système et que vous n'utiliserez pas par inadvertance un package de celui-ci. Il faut d'ailleurs noter que dans les dernières versions de Virtualenvwrapper, cette option est obsolète. En effet, l'isolation des Virtualenv est devenu le comportement par défaut.

Une fois que votre Virtualenv est créé, il faut l'activer pour votre console. Vous allez en effet installer de nouveaux packages Python et faire des commandes Django et tout doit se faire dans votre Virtualenv. L'activation d'un Virtualenv se fait avec la commande workon. Si vous la lancez sans argument elle vous donnera la liste des Virtualenv possibles. Avec un nom de Virtualenv, elle l'active.

Ici, vous devez donc taper

Code :

workon creme

Il y a d'autre commandes intéressantes dans Virtualenvwrapper. Vous les trouverez dans le man. Une commande qui vous sera utile est la commande deactivate qui permet de sortir d'un Virtualenv pour revenir à votre environnement système classique.

Maintenant que vous avez activé votre Virtualenv, il vous faut récupérer Crème. Pour cela il suffit d'utiliser mercurial (que vous devez avoir installé avec votre gestionnaire de package préféré).

Taper simplement à l'endroit où vous voulez déposer le code source de Crème :

Code :

hg clone https://bitbucket.org/hybird/creme_crm-1.7

Vous remarquerez que les sources de Crème contiennent (dans le répertoire 'creme/)' un petit fichier 'requirements.txt'. C'est ce fichier qui va servir à installer de manière automatique les dépendances.

Il vous suffit donc de taper (suivant l'endroit d'où vous vous trouvez)

Code :

pip install -r creme/requirements.txt

ou

Code :

pip install -r requirements.txt

Configuration de la base de données

Django utilise un système de configuration qui utilise un fichier python stockant des valeurs ; ce fichier s'appelle de base 'settings.py' (vous le trouverez dans le répertoire 'creme/'). Mais afin de ne pas modifier un fichier "appartenant " à Creme (ce qui vous obligerez à gérer des conflits lors de mise-à-jour du code de Creme), nous allons mettre la configuration spécifique à votre serveur dans un fichier qui vous appartient.

Rendez-vous dans le répertoire 'creme/' et créez un fichier de configuration propre à votre machine:  local_settings.py
(attention le nom est important, puisque settings.py importe explicitement ce fichier s'il existe).

Pour le moment, Il doit contenir les lignes suivantes (que nous allons compléter par la suite) :

Code :

# -*- coding: utf-8 -*-

DATABASES = {
   'default': {
       'ENGINE':   '',
       'NAME':     '',
       'USER':     '',
       'PASSWORD': '',
       'HOST':     '',    # Une chaîne vide pour le localhost.
       'PORT':     '',    # Une chaîne vide pour le port par défaut.
   },
}

SECRET_KEY = ''

Avant de passer au déploiement de Crème proprement dit, on va devoir configurer la base de données. Creme est testé avec trois systèmes de gestion de base de données: SQLite, MySQL & PostgreSQL. Django permet aussi d'utiliser une base Oracle, mais nous n'avons jamais eu l'occasion de tester une telle configuration (mais pourquoi utiliser un SGBDR propriétaire quand l'offre libre est aussi bonne ?). Il existe aussi des backends pour d'autres SGBDR (firebird, sqlserver ...) qui sont distribués à part de Django ; là encore nous ne les avons pas testé, et ne pouvons garantir leur fonctionnement (mais si vous avez essayé, vos retours sont évidemment les bienvenus, ne serait-ce que par curiosité technique).

SQLite

SQLite est surtout utile si vous êtes un développeur, afin de tester rapidement votre travail. C'est aussi envisageable si vous comptez utiliser Creme
en tant qu'application monoposte et avec peu de données (c'est sûrement une mauvaise idée pour des dizaines de milliers de fiches). Si vous n'êtes pas dans ces 2 cas, nous vous déconseillons vivement une telle configuration.

Si vous choisissez SQLite, la configuration est très simple (pas d'utilisateur ou de mot de passe) ; éditez la variable DATABASES de votre local_settings.py ainsi :

Code :

DATABASES = {
   'default': {
       'ENGINE':   'django.db.backends.sqlite3',
       'NAME':     '/chemin/absolu/vers/un/fichier.db',
       'HOST':     '',
       'PORT':     '',
   },
}

Vous devez évidemment mettre une chemin valide en tant que NAME (le fichier sera créé s'il n'existe pas, mais faites attention que Creme ait bien les permissions d'écrire dans le répertoire choisi).

MySQL

MySQL est un choix classique pour un serveur de production ; il est très répandu et facile à configurer. En revanche, il n'est pas toujours possible de le configurer aussi finement qu'on le voudrait, et a tendance à voir ses performances varier étrangement au grès des versions (la plupart du temps dans le bon sens, mais pas toujours) . C'est donc un bon choix si vous le connaissez déjà, et que vous ne visez pas des volumes importants de données (pour quelques centaines de milliers de fiches ça devrait être satisfaisant -- ça dépend de votre matériel évidemment).

Pour que Crème puisse utiliser MySQL, il faut créer une base de données et un utilisateur qui a les droits sur celle-ci. Vous pouvez bien entendu le faire en graphique grâce à un outil d'administration de BD.

Voici comment le faire en console. Logguez vous dans MySQL avec la commande suivante :

Code :

mysql -uroot -p

Puis passez sur la base de configuration avec la commande :

Code :

use mysql;

Ajoutez maintenant votre utilisateur (en remplaçant les valeurs d'exemple par vos propres valeurs) avec la commande :

Code :

INSERT INTO user(host,user,password) VALUES ('localhost','cremeuser',PASSWORD('34jkfue1dioaA'));

Il ne vous reste plus alors qu'à créer la base de données
create database bdcremecrm ;
et à donner à votre utilisateurs les bonnes permissions.

Code :

GRANT SELECT ,
INSERT ,
UPDATE ,
DELETE ,
CREATE ,
DROP ,
INDEX ,
ALTER ,
CREATE TEMPORARY TABLES ,
CREATE VIEW ,
EVENT,
TRIGGER,
SHOW VIEW ,
CREATE ROUTINE,
ALTER ROUTINE,
EXECUTE ON `bdcremecrm` . * TO 'cremeuser'@'localhost';

Éditez la variable DATABASES de votre local_settings.py ainsi (vous devrez si nécessaire remplacer les noms de la base, de l'utilisateur et son mot de passe par les valeurs que vous avez défini précédemment)  :

Code :

DATABASES = {
   'default': {
       'ENGINE':   'django.db.backends.mysql',
       'NAME':     'bdcremecrm',
       'USER':     'cremeuser',
       'PASSWORD': '34jkfue1dioaA',
       'HOST':     '',    # Une chaîne vide pour le localhost.
       'PORT':     '',    # Une chaîne vide pour le port par défaut.
   },

PostgreSQL

PostgreSQL est sûrement le meilleur choix pour les volumes de données importants ; non seulement ses performances sont excellentes, mais c'est aussi le SGBDR le plus rigoureux en terme de cohérence des données.

Les instructions du début de ce tutoriel étaient plutôt faites pour un déploiement avec MySQL ; aussi il va falloir installer des paquets supplémentaires si vous souhaitez utiliser PostgreSQL.

Du point de vue des bibliothèques systèmes, il vous  évidemment le serveur lui-même ; sous Ubuntu par exemple le paquet "postgresql-client-common" permettra d'installer le nécessaire.
Dans votre virtualenv, il faudra installer le paquet permettant à python de faire ses requêtes à PGSQL:

Code :

pip install psycopg2

Comme pour MySQL, il vous faut maintenant créer un utilisateur dédié à Creme, ainsi qu'une base sur lequel l'utilisateur a tous les droits. Là encore c'est possible en console comme en graphique (en graphique, le programme "pgAdmin III" fait un très bon travail).

Lorsque c'est fait, éditez la variable DATABASES de votre local_settings.py ainsi (vous devrez remplacer les noms de la base de l'utilisateur et son mot de passe par les valeurs que vous avez choisies juste avant)  :

Code :

DATABASES = {
   'default': {
       'ENGINE':   'django.db.backends.postgresql_psycopg2',
       'NAME':     'nom_de_la_base',
       'USER':     'nom_de_l_utilisateur',
       'PASSWORD': 'm0t_de_p4$$',
       'HOST':     '',    # Une chaîne vide pour le localhost.
       'PORT':     '',    # Une chaîne vide pour le port par défaut.
   },

Remplissage de la base de données

Vous devez revenir dans le répertoire 'cremecrm/' (et ne pas rester dans le répertoire 'creme/') ; il vous suffit de taper :

Code :

cd ..

Avec la commande suivante, vous allez générer votre clé secrète ; il faudra mettre la valeur retournée dans votre local_settings.py, dans la variable SECRET_KEY (entre les '' ; exemple: SECRET_KEY = 'abcd123'):

Code :

python manage.py build_secret_key

Avec la commande suivante, on va créer les tables de la base :

Code :

python manage.py migrate

Puis on remplit la base avec les données initiales (utilisateur administrateur, société initiale, configuration par défaut etc…) :

Code :

python manage.py creme_populate

Ne vous inquiétez pas des messages du genre , ils indiquent juste que certaines apps n'ont pas besoin de créer des données initiales.

Génération des bundles d'assets statiques

Il s'agit de créer des fichiers optimisés pour le CSS et le JavaScript, ainsi que des images avec des noms pensés pour être mises en cache intelligemment :

Code :

python manage.py generatemedia

Ici , vous pouvez avoir des messages d'erreur parlant d'images non trouvées (voir ci dessous ). Ce n'est pas grave du tout, les choses ont tout de même fonctionné.

Code :

/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/usr/local/lib/python2.7/dist-packages/virtualenvwrapper': missing __init__.py
 file, filename, etc = imp.find_module(subname, path)
Generating l10n.js with variation {'language': 'en'}
Generating l10n.js with variation {'language': 'fr'}
Generating main.js with variation {}
Generating icecreammain.css with variation {}
2018-02-13 11:17:32 [ERROR] - root : URL not found: icecream/images/expandme.gif
2018-02-13 11:17:32 [ERROR] - root : URL not found: icecream/images/expanded.gif

Lancement du serveur

Une fois cela fait il ne nous reste plus qu'à lancer le serveur de test en faisant :

Code :

python manage.py runserver

Vous pouvez maintenant vous connecter sur http://localhost:8000 pour voir que votre Crème fonctionne. Mais, et je vais le répéter, ce serveur de développement n'est pas fait pour être utiliser dans un contexte de production. Par exemple, pour mettre en production avec Apache et mod_wsgi, vous pouvez suivre cet autre billet: posting.php?mode=reply&f=14&t=660#pr1090

Lancement du gestionnaire de jobs

Dans Creme1.7 certaines fonctionnalités (import des fichiers CSV/XLS, envoi des campagnes d'e-mails...) sont effectuées par des jobs tournant en parallèle du serveur Web. Ces jobs sont gérés par un gestionnaire qui s'occupent de créer ces processus lorsque c'est nécessaire.

Ce gestionnaire doit être lancé à part, et tourner en permanence  ; si ce n'est pas le cas, la majorité de Creme fonctionnera parfaitement, mais pas les fonctionnalités basées sur les jobs. Si vous allez sur la liste des jobs (menu > Outils > Jobs) un message d'erreur vous indiquera si le gestionnaire est injoignable. Pour lancer le gestionnaire :

Code :

python manage.py creme_job_manager

[igualada]

J'ai completé avec succès une installation neuve de creme_crm-1.7 (une base de données neuve).

Je viens de me lancer sur la mise à niveau de ma version 1.6 avec un nouvel environnement virtuel et un nouveau téléchargement de la version 1.7.

En faisant la commande "python manage.py migrate --fake-initial" j'ai eu l'erreur suivante à partir de "persons.0013_v1_7__image_to_doc_1".

Applying persons.0013_v1_7__image_to_doc_1... OK
Applying persons.0014_v1_7__image_to_doc_2...Traceback (most recent call last):
File "manage.py", line 10, in
execute_from_command_line(sys.argv)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line
utility.execute()
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 346, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/core/management/base.py", line 394, in run_from_argv
self.execute(*args, **cmd_options)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/core/management/base.py", line 445, in execute
output = self.handle(*args, **options)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 222, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 148, in apply_migration
state = migration.apply(state, schema_editor)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/db/migrations/migration.py", line 112, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages/django/db/migrations/operations/special.py", line 183, in database_forwards
self.code(from_state.apps, schema_editor)
File "~/creme_crm-1.7/creme/persons/migrations/0014_v1_7__image_to_doc_2.py", line 132, in fix_relation_blocks
cells_map = json_load(rbi.json_cells_map)
File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: expected string or buffer

Est-ce que vous pouvez m'aider pour trouver l'origine de cette erreur?

[genglert]

Bonjour,

pouvez vous m'indiquer si votre table "creme_core_relationblockitem" de la base de données contient une valeur NULL dans la colonne "json_cells_map" ?
En investiguant, j'ai l'impression que c'est possible si votre base est issue à l'origine d'une base Creme 1.3 (ou plus vieux) migrée en Creme 1.4.

Si c'est bien le cas, je mettrai la correction dans la version 1.7.1 que j'aimerai publier ces jours-ci (j'ai quelques patches mineures en attente).

[igualada]

Bonjour,

Merci pour votre réponse.

Vous avez raison - j’ai trois lignes dans le tableau ”creme_core_relationblockitem", chacune avec une valeur de ”NULL” dans la colonne "json_cells_map".

En plus, ma base de données est à l’origine de la version 1.3 et ensuite migrée vers 1.4, 1.5, et 1.6.

[genglert]

Voila j'ai releasé une 1.7.1 qui devrait régler ce bug.
J'espère que la suite de votre mise-à-jour se passera sans accroc.

Bonne soirée.

[igualada]

Mes excuses pour le retard.

Je viens de faire une nouvelle mise à jour de la version 1.6 vers la version 1.7.

Les modifications que vous avez apportées dans 1.7.1 ont bien rectifié le problème précédent – je vous en remercie.

Néanmoins, j’ai eu le message suivant à la fin de « python manage.py migrate –fake-initial »

Applying recurrents.0005_v1_7__description_not_null_2... OK
The following content types are stale and need to be deleted:

auth | message

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

Type 'yes' to continue, or 'no' to cancel: no
The following content types are stale and need to be deleted:

recurrents | periodicity

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

Type 'yes' to continue, or 'no' to cancel: no

J’ai répondu « no » dans les deux cas.

Tout s’est bien passé pour terminer la mise à jour, mais suite à mon login sur « 127.0.0.1:8000 » j’ai eu le debug log suivant.

AttributeError at /

'str' object has no attribute 'model_class'

Request Method: GET
Request URL: http://127.0.0.1:8000/
Django Version: 1.8.19
Exception Type: AttributeError
Exception Value:

'str' object has no attribute 'model_class'

Exception Location: ~/creme_crm-1.7/creme/creme_core/templatetags/creme_widgets.py in _build_icon, line 84
Python Executable: ~/Envs/creme_crm-1.7/bin/python
Python Version: 2.7.9
Python Path:

['~/creme_crm-1.7',
'~/Envs/creme_crm-1.7/lib/python2.7',
'~/Envs/creme_crm-1.7/lib/python2.7/plat-i386-linux-gnu',
'~/Envs/creme_crm-1.7/lib/python2.7/lib-tk',
'~/Envs/creme_crm-1.7/lib/python2.7/lib-old',
'~/Envs/creme_crm-1.7/lib/python2.7/lib-dynload',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-i386-linux-gnu',
'/usr/lib/python2.7/lib-tk',
'~/Envs/creme_crm-1.7/local/lib/python2.7/site-packages',
'~/Envs/creme_crm-1.7/lib/python2.7/site-packages']

Server time: jeu, 15 Mar 2018 17:47:52 +0100

Je peux vous envoyer le « traceback » si vous pouvez me transmettre une adresse courriel.

[genglert]

j’ai eu le message suivant à la fin de « python manage.py migrate –fake-initial »

J’ai répondu « no » dans les deux cas.

À noter que l'argument "–fake-initial" est désormais inutile (avec la transition au système de migration intégré a Django 1.8 complète). Il n'est plus présent dans le tutoriel ci-dessus et dans le fichier README.

Pour les messages à propos des 'content types' obsolètes, dans le cas "recurrents | periodicity", c'est un modèle que j'ai supprimé dans Creme1.5 (pour l'autre je n'ai pas regardé le détail mais ça date aussi). Et donc :

• Il semble que j'ai oublié dans Creme 1.5 de supprimer le ContentType afin que les utilisateurs n'aient pas à répondre à cette question inutilement. Mais maintenant c'est un peu tard
  
• La question vous a sûrement déjà été posée lors des passages à Creme1.5 et Creme1.6. Elle vous sera posée à chaque migration si vous ne répondez jamais "oui", ce que vous pouvez faire sans danger.

Je peux vous envoyer le « traceback » si vous pouvez me transmettre une adresse courriel.

Oui avec ce que vous m'avez envoyé, je devine que dans un template, le tag "{% widget_icon ctype=... %}" est appelé avec un argument "ctype" bizarrement invalide. Mais je ne sais pas par exemple dans quel template ça arrive, et encore moins pourquoi. Même avec une stacktrace je doute arriver à comprendre directement pourquoi ça arrive, mais il faut bien commencer par quelque chose ; donc voici mon adresse :
genglert le_petit_arobase_qui_va_bien hybird un_point org