Odoo-11
 Mise en garde:Cette marche à suivre fonctionne correctement aujourd'hui (5 septembre 2018).
Le développement étant très rapide vu la mise à jour quotidienne d'Odoo, elle peut ne pas fonctionner demain.
|
Description générale
Introduction
Cette marche à suivre décrit l'installation d'Odoo-11 sur un Serveur SME-9.2.
Le logiciel Odoo
Référence: http://fr.wikipedia.org/wiki/Odoo
Odoo, anciennement OpenERP et Tiny ERP, est initialement un progiciel LIBRE de gestion intégrée comprenant de très nombreux modules permettant de simplifier la gestion d'une société dans son ensemble. Le logiciel est utilisé par plus de deux millions d’utilisateurs pour gérer leur entreprise à travers le monde. Odoo est le système ERP LIBRE le plus populaire.
Il existe une version Communautaire gratuite, sous licence LGPLv3, et une version Entreprise sous licence propriétaire Odoo Enterprise Edition License v1.0.
À l’origine un ERP, le logiciel s’est vu étendre ses fonctionnalités à des applications de "front office" (CMS, e-commerce, blogs, forums, nouvelles, événements, chat en direct, offre d'emplois…).
L’aspect LIBRE du logiciel a permis le développement de nombreux modules tiers créés par sa communauté de développeurs. Ces applications sont pour certaines, officiellement validées par l’éditeur tandis que d’autres ne sont destinées qu’à des versions spécifiques.
Le logiciel compte 260 modules officiels et 7300 modules communautaires. En décembre 2012, la version 7.0 d'OpenERP est lancée et peut être testée en ligne, téléchargée ou vue en version de démonstration. Mai 2014: OpenERP change de nom et devient Odoo.
La société éditrice OpenERP SA
OpenERP S.A. est également le nom de l’entreprise qui édite le logiciel. Dans le reste de ce document, on utilise le terme Odoo pour désigner le logiciel et OpenERP SA pour désigner l’entreprise de façon univoque.
Étapes
- Installer le serveur de bases de données PostgreSQL-10.
- Installer la Collection RH-Python36, pour ne pas interférer avec la version de Python fourni par défaut avec le Serveur SME.
- Remplir les prérequis pour Odoo.
- Télécharger avec git, le dernier code Odoo et créer un script de lancement compatible avec le Serveur SME.
- Programmer un script de sauvegarde pour la base de données PostgreSQL et créer une tâche cron qui l'activera quotidiennement. Ainsi, la sauvegarde PostgreSQL sera intégrée à la sauvegarde régulière du Serveur SME.
Cette marche à suivre assume que:
- Vous avez réalisé l'installation d'un Serveur SME-9.2/64 sur votre réseau local et, dédié à Odoo seulement.
- Vous allez rouler Odoo-11 et PostgreSQL-10 sur le même serveur.
- L'adresse IP du serveur est: 192.168.1.11/24
Préparation du serveur
Mise à jour du Serveur
Avant de commencer quoi que ce soit, il est toujours préférable de mettre à jour le Serveur SME.
Mode de fonctionnement du Serveur SME
Si nous sommes sur un réseau local ou sur une machine virtuelle, il est recommandé de choisir Serveur uniquement comme Mode de fonctionnement car, il pourrait y avoir certaines difficultés à accéder à Odoo par le réseau externe du serveur.
| Mode de fonctionnement: Serveur uniquement. |
Interface de liaison de canaux: Désactivé. | Configuration du serveur DHCP: Désactivé. |
 |
 |
 |
Configuration des paramètres d'Accès à distance
| Gestion à distance
- il n’est pas nécessaire d’ajouter le réseau LOCAL 192.168.1.0/24 pour la gestion à distance car, il est autorisé par défaut.
- Accès par terminal sécurisé (SSH): Autoriser l’accès que depuis les réseaux locaux - Autoriser l'administrateur à se connecter au serveur par SSH: Oui - Autoriser l'authentification par SSH à l'aide de mots de passe standards: Oui - Port TCP pour l’accès SSH: 2222 *** On change le port SSH de 22 à 2222 pour dérouter, un peu plus, les intrusions malveillantes |
 |
Paramètres FTP
|
- Pour conserver votre sécurité, il n'est pas obligatoire d'accorder l'Accès FTP à l'Internet complet, on peut choisir: N'autoriser l'accès que depuis les réseaux locaux seulement. - Idem pour l'Accès FTP par mot de passe, on peut choisir N'autoriser l'authentification que depuis les réseaux locaux seulement. - Cliquer Enregistrer pour sauvegarder tous les nouveaux paramètres de cette page.
|
 |
Serveur DNS du domaine
Pour les Serveurs DNS du domaine, il faut toujours utiliser Serveurs DNS de l'Internet pour un site dans l'i-bay Primary et Résolu localement pour tous les sites dans une autre i-bay, que vous ayez un domaine FQDN ou non.
Notre Serveur SME n'est pas accessible depuis l'Internet. Dans un tel cas, il nous faut obligatoirement spécifier Résolu Localement, même si nous utilisons l'i-bay Primary sinon, nous ne pourrons pas accéder à notre serveur.
| Domaines > Modifier. | Résolu localement > Modifier. |
 |
 |
Si nous avons un serveur DNS sur le réseau local, nous pouvons accéder à notre site Odoo en spécifiant son FQDN sinon, nous devons utiliser son adresse IP.
Fail2ban
Il est fortement recommandé d'installer Fail2ban pour sécuriser votre futur site Odoo.
Certificat Let's Encrypt
Dans la prochaine marche à suivre, nous installerons un certificat Let's Encrypt pour pouvoir nous connecter de manière sécuritaire à Odoo mais, sans perdre notre connexion au gestionnaire Server Manager.
Création d'usagers dans le gestionnaire Server Manager
- michelandre: usager pour des tests à la console PostgreSQL.
 |
 |
 |
 |
 |
Autoriser un utilisateur à exploiter la ligne de commande
Référence: http://smeserver.fr/astuces.php?astuce=user_shell.
Par défaut, sous SME, seuls les comptes admin et root peuvent ouvrir une session; admin accède directement à la console du serveur et root à un shell (bash, par défaut).
Par mesure de sécurité, aucun utilisateur ajouté au système ne peut ouvrir de session en ligne de commande. Le shell par défaut est le programme /usr/bin/rssh qui n'autorise l'utilisateur qu'à ouvrir une session en SCP, SFTP ou rsync. En cas de tentative d'ouverture d'une session shell, un message d'avertissement apparaît, indiquant cette limitation.
Mais en cas de besoin avéré, vous avez la possibilité de modifier cette restriction en vous loguant root et en changeant le shell par défaut de l'utilisateur en question.
Changement du shell de l'usager michelandre
On affiche le shell de michelandre.
# cat /etc/passwd | grep michelandre
michelandre:x:5000:5000:Michel-Andre Rob:/home/e-smith/files/users/michelandre:/usr/bin/rssh
On change le shell.
# db accounts setprop michelandre Shell /bin/bash
On signale le changement pour qu'il devienne permanent.
# signal-event user-modify michelandre
On vérifie.
# cat /etc/passwd | grep michelandre
michelandre:x:5000:5000:Michel-Andre Rob:/home/e-smith/files/users/michelandre:/bin/bash
Mot de passe pour les usagers SME
Référence: https://www.micronator.org/affaires/manuel-de-ladministrateur/.
Il n'est pas possible pour l'administrateur de récupérer un mot de passe oublié par un utilisateur. Tout ce qu'il peut faire est de définir un nouveau mot de passe pour l'utilisateur.
Le système de vérification de la complexité du mot de passe demande une valeur trop élevée, comment puis-je la changer?
D'abord, un avertissement - Beaucoup trop de systèmes ont des mots de passe faibles et cela créé une vulnérabilité pour le serveur. Il faut éduquer les utilisateurs sur la nécessité de mots de passe robustes ou complexes; ceci reste la meilleure option. Si cette éducation échoue, vous pouvez, en passant par le terminal root du serveur ou en installant la Contrib Password, changer le contrôle de la complexité du mot de passe de "fort" à "normal" qui était le réglage par défaut des versions précédentes du Serveur SME.
Paramètres
strong Le mot de passe est envoyé au programme Cracklib pour vérifier qu'il ne fasse pas partie d'un dictionnaire et qu'il possède des majuscules, des minuscules, un nombre, des caractères non alphanumériques et une longueur minimum de 7 caractères.
normal Le mot de passe nécessite des caractères majuscules, minuscules, numérique, non alphanumériques et une longueur minimale de 7 caractères.
none Le mot de passe n'a aucune vérification d'effectuer.
Veuillez noter que "none" ne veut pas dire aucun mot de passe mais, signifie simplement qu'aucune vérification de la complexité du mot de passe ne sera faite. Vous pouvez entrer un mot de passe (faible) si vous voulez, tant qu'il possède au moins 7 caractères.
Veillez à utiliser la casse exacte dans un terminal root.
Les exemples ci-dessous n'ont pas à être exécutés. Ils ne servent qu'à la démonstration des paramètres des mots de passe.
| # config setprop passwordstrength Users normal |
| # config setprop passwordstrength Ibays normal |
Il est également possible, mais fortement déconseillé, de désactiver la vérification de la complexité du mot de passe en mettant le paramètre à "none".
| # config setprop passwordstrength Users none |
| # config setprop passwordstrength Ibays none |
Après une modification, il faut signaler le(s) changement(s).
| # signal-event password-modify |
On vérifie.
| # config show passwordstrength Admin=strong |
Changement du mot de passe par l'utilisateur lui-même
Une fois qu'ils ont un compte actif, les utilisateurs peuvent définir leurs propres mots de passe en accédant à l'URL user-password qui est seulement accessible à partir du réseau local. Ils le font par le biais de leur navigateur Web en visitant l'URL http://mon-domaine.xxx/user-password (où "mon-domaine.xxx" est le nom du domaine qu'on a entré dans le gestionnaire du serveur).
Pour faire le changement, un utilisateur entrera son nom de compte (les caractères avant "@"), l'ancien mot de passe et le nouveau (pour assurer l'exactitude, l'écran demandera deux fois le nouveau mot de passe). Notez que la modification du mot de passe d'un utilisateur dans le gestionnaire du serveur remplace tout précédent mot de passe entré par l'utilisateur. Par conséquent, lorsqu'un utilisateur oublie son mot de passe, l'usager admin peut le réinitialiser dans le gestionnaire du serveur.
Changement d'un mot de passe à la console du serveur
Sur un Serveur SME, un utilisateur possède en réalité deux mots de passe. Le premier est celui auquel nous sommes tous habitués et qui est utilisé pour se connecter au serveur. Le deuxième est celui utilisé par l'usager pour tout ce qui a trait à Samba. Habituellement, les deux mots de passe sont identiques. Lorsque le gestionnaire Server Manager crée/change le mot de passe d'un usager ou d'une i-bay, il commence par vérifier si le mot de passe répond aux critères définis pour ceux-ci: longueur, composition, robustesse etc. Ensuite, il crée/change non seulement le mot de passe standard mais aussi, il change automatiquement celui utilisé pour Samba. L'opération est invisible.
Le gestionnaire Server Manager utilise deux commandes distinctes pour créer/changer un mot de passe: passwd pour le mot de passe standard et smbpasswd pour celui utilisé pour Samba. Ces deux commandes sont identiques en tous points et sont utilisées avec les mêmes paramètres.
Si on utilise ces commandes à la console du serveur, elles ne vérifient pas la conformité du mot de passe.
Mot de passe standard de michelandre
Pour faciliter les login pour cette marche à suivre, on passe outre à la conformité des mots de passe et on utilise la console du serveur pour changer nos mots de passe afin de profiter d'un mot simple. Tous les mots de passe seront celui du célèbre Général Toto qui utilise toujours fghtbgh.
Non recommandé pour un serveur en production.
Mot de passe standard de l'usager michelandre.
# passwd michelandre Changement de mot de passe pour l'utilisateur michelandre. Entrez le nouveau mot de passe UNIX :fghtbgh Retapez le nouveau mot de passe UNIX :fghtbgh passwd : mise à jour réussie de tous les jetons d'authentification.
Mot de passe Samba de michelandre
Non recommandé pour un serveur en production.
Changement du mot de passe Samba de l'usager michelandre.
# smbpasswd michelandre New SMB password:fghtbgh Retype new SMB password:fghtbgh
Usager odoo
- odoo: usager qui sera le propriétaire/groupe de l'environnement Odoo.
 |
 |
Changement du shell de l'usager odoo
On affiche le shell de l'usager odoo.
# cat /etc/passwd | grep odoo
odoo:x:5001:5001:Utilisateur Environnement virtuel:/home/e-smith/files/users/odoo:/usr/bin/rssh
On change le shell.
# db accounts setprop odoo Shell /bin/bash
On signale le changement pour qu'il devienne permanent.
# signal-event user-modify odoo
On vérifie.
# cat /etc/passwd | grep odoo
odoo:x:5001:5001:Utilisateur Environnement virtuel:/home/e-smith/files/users/odoo:/bin/bash
Mot de passe standard de l'usager odoo
Non recommandé pour un serveur en production.
Changement du mot de passe standard de l'usager odoo.
# passwd odoo Changement de mot de passe pour l'utilisateur odoo. Entrez le nouveau mot de passe UNIX :fghtbgh Retapez le nouveau mot de passe UNIX :fghtbgh passwd : mise à jour réussie de tous les jetons d'authentification.
Mot de passe Samba de l'usager odoo
Non recommandé pour un serveur en production.
Changement du mot de passe Samba de l'usager odoo
# smbpasswd odoo New SMB password:fghtbgh Retype new SMB password:fghtbgh
Paramètres SSHD
Désactivation d'AutoBlock
Vu que nous avons installé Fail2ban sur notre serveur, il n'est plus nécessaire de surveiller les connexions avec AutoBlock; Fail2ban s'en occupe.
# config setprop sshd AutoBlock disabled
# signal-event remoteaccess-update
# config show sshd | grep AutoBlock
AutoBlock=disabled
AutoBlockTime=900
AutoBlockTries=4
i-bay Primary
Ajustement des paramètres de l'i-bay Primary
Les valeurs de certains paramètres de PHP ne sont pas suffisants. Ces paramètres sont: MemoryLimit, PostMaxSize et UploadMaxFilesize. Il faut les ajuster.
L'installation d'Odoo se fera dans l'i-bay Primary et vu qu'on pourrait utiliser une Collection PHP, on ajuste alors les paramètres de l'i-bay Primary.
Il faut obligatoirement que le paramètre PostMaxSize soit plus grand que celui de UploadMaxFilesize. Si on modifie l'un, il faut vérifier l'autre pour que la correspondance des grandeurs soit respectée. MemoryLimit (512M) > PostMaxSize (52M) > UploadMaxFilesize (50M).
MemoryLimit
Chaque fois qu'un client fait une requête au serveur Web, PHP génère un processus PHP. Le travail de ce processus est de générer du code HTML qu'il envoie au client. Le processus fournit un temps d'exécution à un script qui crée la réponse à la requête. La limite de mémoire MemoryLimit est la quantité maximale de mémoire que ce processus peut utiliser. Si la limite est atteinte ou dépassée, le processus échoue et Apache signale une erreur HTTP 500.
On ajuste le paramètre pour l'i-bay Primary.
# db accounts setprop Primary MemoryLimit 512M
PostMaxSize
Le paramètre PostMaxSize définit la taille maximale autorisée pour les données d'un post. Ce paramètre affecte également le téléchargement de fichiers. Pour télécharger des fichiers volumineux, cette valeur doit absolument être toujours supérieure à UploadMaxFilesize.
On ajuste le paramètre pour l'i-bay Primary.
# db accounts setprop Primary PostMaxSize 52M
UploadMaxFilesize
Pour certaines extensions, on doit autoriser le téléversement de fichiers et la grandeur de ceux-ci ne peut dépasser la limite définie par le paramètre UploadMaxFilesize de PHP.
On ajuste le paramètre pour l'i-bay Primary.
# db accounts setprop Primary UploadMaxFilesize 50M
Répertoire temporaire de téléchargement
On doit spécifier un répertoire temporaire à l'i-bay Primary pour le téléchargement de fichiers, extensions, modules, etc. Ce répertoire servira pour tous les programmes PHP installés dans l'i-bay Primary ou ses sous-répertoires, lorsque ceux-ci auront besoin d'un répertoire temporaire pour leurs téléchargements. Si ce répertoire n'existe pas, certains CMS pourraient afficher le message suivant:
| Le fichier que vous voulez téléverser semble vide. Ceci peut être dû à une erreur dans le nom du fichier. Veuillez vérifier que vous désirez vraiment téléverser ce fichier. |
On active la propriété.
# db accounts setprop Primary PHPBaseDir /home/e-smith/files/ibays/Primary:/tmp
Apache
- Permettre à Apache de lire les fichiers
.htaccessde l'i-bay Primary et de ses sous-répertoires.
# db accounts setprop Primary AllowOverride all
- Permettre à Apache de suivre les liens symboliques.
# db accounts setprop Primary FollowSymLinks enabled
- Défendre à Apache d'afficher le contenu des répertoires.
# db accounts setprop Primary Indexes disabled
Signalisation des changements
On signale les changements pour qu'ils deviennent permanents.
# signal-event ibay-modify Primary
On vérifie.
# db accounts show Primary
Primary=ibay
AllowOverride=all
CgiBin=enabled
FollowSymLinks=enabled
Group=shared
Indexes=disabled
MemoryLimit=512M
Modifiable=no
Name=Primary i-bay
PHPBaseDir=/home/e-smith/files/ibays/Primary:/tmp
PasswordSet=no
Passwordable=no
PostMaxSize=52M
PublicAccess=global
Removable=no
UploadMaxFilesizee=52M=50M
UserAccess=wr-admin-rd-group
- Les grandeurs maximales sont maintenant de: MemoryLimit (512M) > PostMaxSize (52M) > UploadMaxFilesize (50M).
- PHPBaseDir pointe vers
/tmp. - Apache lira les fichiers
.htaccess, suivra les liens symboliques et n'affichera pas le contenu des répertoires.
PostgreSQL
Dépôt de logiciels PostgreSQL (pgdg) et clé
Version CentOS
Pour connaître la version CentOS dont notre serveur est issu.
# cat /etc/centos-release
CentOS release 6.10 (Final)
Lien du dépôt PostgreSQL
Pour connaître le lien URL du dépôt (repository) de la dernière version de PostgreSQL, on se rends au site suivant: http://yum.postgresql.org/repopackages.php#pg10.
On claque (clic droit) sur CentOS 6 - x86 64 et on copie l'adresse du lien.
Le lien pour notre serveur est: https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-6-x86_64/pgdg-centos10-10-2.noarch.rpm.
Création du dépôt
Téléchargement du dépôt pgdg-10-centos.repo
Le dépôt pgdg-10-centos.repo contient les descriptions de quatre dépôts CentOS relatifs à PostgreSQL: pgdg10, pgdg10-source, pgdg10-updates-testing et pgdg10-source-updates-testing.
La commande pour télécharger ces dépôts est composé de 2 parties:
- yum install -y
- l'URL du paquet de ces dépôt
On installe le paquet décrivant le dépôt de logiciels de PostgreSQL pour les serveurs CentOS-6 dont le Serveur SME-9 est issu.
On entre yum install -y (suivi d'un espace) et on colle l'URL copié précédemment.
# yum install -y https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-6-x86_64/pgdg-centos10-10-2.noarch.rpm ... Installation de 1 paquet(s) Taille totale : 2.7 k Taille d'installation : 2.7 k ...
Importation de la clé PKI
On affiche les clés PKI pour ces dépôts.
# ls -als /etc/pki/rpm-gpg/
total 28
4 drwxr-xr-x 2 root root 4096 17 juin 13:17 .
4 drwxr-xr-x 11 root root 4096 17 juin 09:36 ..
4 -rw-r--r-- 1 root root 1706 28 mars 2017 RPM-GPG-KEY-CentOS-6
4 -rw-r--r-- 1 root root 1730 28 mars 2017 RPM-GPG-KEY-CentOS-Debug-6
4 -rw-r--r-- 1 root root 1730 28 mars 2017 RPM-GPG-KEY-CentOS-Security-6
4 -rw-r--r-- 1 root root 1734 28 mars 2017 RPM-GPG-KEY-CentOS-Testing-6
4 -rw-r--r-- 1 root root 1726 24 sept. 2017 RPM-GPG-KEY-PGDG-10
On importe la clé.
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-10
Affichage des paramètres du dépôt pgdg-10-centos.repo
# cat /etc/yum.repos.d/pgdg-10-centos.repo [pgdg10] name=PostgreSQL 10 $releasever - $basearch baseurl=https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-$releasever-$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-10 [pgdg10-source] name=PostgreSQL 10 $releasever - $basearch - Source ...
Transformation du dépôt pgdg10 vers le format SME
On crée le dépôt pgdg10 sous format SME et on l'ajoute à la base de données des dépôts de SME-9.2.
Porter une attention particulière aux: ['], [\], et [:///].
Prendre tout le contenu de l'encadré pour la commande.
/sbin/e-smith/db yum_repositories set pgdg10 repository \ Name 'PostgreSQL 10' \ BaseURL 'https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-$releasever-$basearch' \ EnableGroups no \ GPGCheck yes \ GPGKey file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-10 \ Visible no \ status disabled
Exclusion des rpm absolete
On ne veut pas de RPM "absolete" donc, on les exclut du dépôt de base (base) car autrement, on rencontrera des difficultés lorsqu'on fera des mises à jour du Serveur SME-9.2.
Cette commande ajoute seulement postgresql* aux exclusions déjà présentes dans le dépôt de base.
# db yum_repositories setprop base Exclude 'initscripts,libgsf,postgresql*'
On signale la modification.
# signal-event yum-modify
Après une commande yum-modify, attendre 20-30 secondes avant de lancer une commande d'installation.
Ce délais est nécessaire afin que yum ait le temps d'accomplir sa mise à jour sinon, le message suivant s'affichera en boucle jusqu'à ce que yum ait terminé son travail.
| Verrou /var/run/yum.pid existant : une autre copie est lancée avec le pid 2322. Une autre application verrouille actuellement l'utilisation de yum ; attente de déverrouillage... |
Vérification du dépôt base.
# db yum_repositories show base
base=repository
EnableGroups=no
Exclude=initscripts,libgsf,postgresql*
GPGCheck=yes
MirrorList=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
Name=CentOS - os
Visible=yes
status=enabled
Installation de PostgreSQL
Maintenant, on peut procéder à l'installation de PostgreSQL-10.
La commande s'étale sur deux lignes.
# yum install -y --enablerepo=pgdg10 postgresql10 postgresql10-libs postgresql10-server \
postgresql10-contrib postgresql10-devel postgresql10-docs postgresql10-test
...
Installation de 9 paquet(s)
Taille totale des téléchargements : 31 M
Taille d'installation : 115 M
...
Initialisation de la base de données
# /etc/init.d/postgresql-10 initdb
Lancement manuel de PostgreSQL
# /etc/init.d/postgresql-10 start
On vérifie.
# /etc/init.d/postgresql-10 status
postgresql-10 (pid 2435) en cours d'exécution...
Démarrage/arrêt automatiques
On veut que PostgreSQL se lance automatiquement à tous les amorçages du Serveur SME-9.2. On ajoute un lien vers /etc/rc.d/init.d/postgresql-10 dans le répertoire /etc/rc.d/rc7.d.
# ln -s /etc/rc.d/init.d/postgresql-10 /etc/rc.d/rc7.d/S51postgresql-10
Un lien pour l'arrêt a déjà été créé, par l'installation de PostgreSQL, dans /etc/rc.d/rc6.d/K36postgresql-10. Ce lien ne fonctionne pas bien. On force donc son remplacement.
# ln -sf /etc/rc.d/init.d/postgresql-10 /etc/rc.d/rc6.d/K36postgresql-10
Signalisation des changements
Nous avons fait plusieurs changements, on signale ceux-ci de manière traditionnelle et on pourra en profiter pour vérifier l'arrêt et le redémarrage de PostgreSQL-10.
# signal-event post-upgrade; signal-event reboot
- Arrêt de PostgreSQL.
- Démarrage de PostgreSQL.
 |
 |
Après le ré-amorçage, on se logue et on vérifie le statut de PostgreSQL.
# /etc/init.d/postgresql-10 status
postgresql-10 (pid 1706) en cours d'exécution...
Pour en savoir un peu plus
Consulter l'URL: http://www.ird.fr/us191/spip.php?article16.
Premiers pas avec PostgreSQL
Référence: Cette section s'est inspirée de l'article suivant: https://wiki.postgresql.org/wiki/First_steps. Elle démontre quelques commandes à la console psql.
On se connecte au Serveur SME en tant que root puis, on change d'usager pour devenir le super-utilisateur postgres.
# su - postgres
On lance le terminal interactif de PostgreSQL.
$ psql
(10.5)
Saisissez « help » pour l'aide.
L'invite # est devenu $ car, postgres est un utilisateur standard dans SME.
On vérifie que l'aide fonctionne.
# HELP
Vous utilisez psql, l'interface en ligne de commande de PostgreSQL.
Saisissez:
\copyright pour les termes de distribution
\h pour l'aide-mémoire des commandes SQL
\? pour l'aide-mémoire des commandes psql
\g ou point-virgule en fin d'instruction pour exécuter la requête
\q pour quitter
Lorsque l'utilisateur postgres est entré dans psql, l'invite est devenu # car, il est le super-utilisateur de PostgreSQL.
SCHEMA
Une base de données contient un ou plusieurs schémas, qui eux, contiennent des tables. Les schémas contiennent aussi d'autres types d'objets y compris des types de données, fonctions et opérateurs. Seul le nom d'objet peut être utilisé sans conflit i.e. schema1 et mon_schema peuvent tous les deux contenir des tables mytable. Contrairement aux bases de données; les schémas ne sont pas séparés de manière rigide; un utilisateur peut accéder aux objets de n'importe lequel des schémas de la base de données auxquels il se connecte s'il a les privilèges pour le faire. On crée un schéma qu'on appellera test dans la base de données par défaut appelée postgres.
# CREATE SCHEMA test; CREATE SCHEMA
RÔLE
Un rôle est une entité qui peut posséder des objets de la base de données et avoir des droits sur la base. Il peut être considéré comme un "utilisateur", un "groupe" ou les deux suivant la façon dont il est utilisé.
On crée un rôle (rôle = user = usager) avec un mot de passe.
L'usager michelandre que PostgreSQL va créer n'a rien à voir avec l'utilisateur standard SME michelandre.
# CREATE USER michelandre PASSWORD 'fghtbgh';
CREATE ROLE
GRANT
La commande GRANT a deux variantes de base: la première donne des droits sur un objet de la base de données (table, vue, séquence, base de données, fonction, langage de procédure, schéma ou espace logique), la seconde gère les appartenances à un rôle.
On donne au nouveau rôle tous les droits (tel que la possibilité de créer des tables) sur le nouveau schéma.
# GRANT ALL ON SCHEMA test TO michelandre; GRANT
On donne au nouveau rôle tous les droits (tel que la possibilité d'insertion) sur toutes les tables du nouveau schéma.
# GRANT ALL ON ALL TABLES IN SCHEMA test TO michelandre; GRANT
Sortie de la console PostgreSQL
On se déconnecte.
# \q
On se déconnecte de l'usager postgres et on retourne à l'usager root.
$ exit logout
Usager standard SME (michelandre) et PostgreSQL
On se substitue à l'usager michelandre (celui du Serveur SME).
# su - michelandre
Connexion à la BD avec un usager standard SME
Par défaut, le mode d'authentification pour se loguer dans PostgreSQL est "ident" qui signifie qu'un usager xxx de Linux ne peut se connecter qu'en tant qu'usager PostgreSQL xxx.
On se logue, en tant qu'usager ordinaire (michelandre qui a été créé précédemment dans PostgreSQL par le super-utilisateur postgres) à la base de données par défaut i.e. la BD postgres.
$ psql -d postgres psql (10.5) Saisissez « help » pour l'aide. =>
Lorsque l'utilisateur michelandre de SME est entré dans psql et se connectant au schéma postgres, il est devenu l'usager michelandre de PostgreSQL et il est, dans ce contexte, un usager standard PostgreSQL dont l'invite est => pour un tel rôle.
HELP
On essaie l'aide.
=> HELP
Vous utilisez psql, l'interface en ligne de commande de PostgreSQL.
Saisissez:
\copyright pour les termes de distribution
\h pour l'aide-mémoire des commandes SQL
\? pour l'aide-mémoire des commandes psql
\g ou point-virgule en fin d'instruction pour exécuter la requête
\q pour quitter
CREATE
Dans le schéma test, on crée une table test.
=> CREATE TABLE test.test (testdecol varchar(20)); CREATE TABLE
INSERT
On insère une entrée dans la nouvelle table.
=> insert into test.test (testdecol) values ('Ça fonctionne!');
INSERT 0 1
SELECT
Sélection depuis une table.
=> SELECT * from test.test;
testdecol
-----------
Ça fonctionne!
(1 ligne)
Déconnexion
On se déconnecte de PostgreSQL.
=> \q
L'invite redevient $ et on retourne à l'usager root.
$ exit
Nous sommes revenu à l'usager root et son invite est toujours #.
# whoami
root
Configuration finale de PostgreSQL
MD5
Maintenant, il nous faut configurer PostgreSQL pour qu'il accepte les connexions avec mots de passe chiffrés MD5 pour être ainsi compatible avec les modules Python.
En tant qu'usager root, on remplace ident par md5 dans le fichier pg_hba.conf.
# sed -i "/^host/s/ident/md5/g" /var/lib/pgsql/10/data/pg_hba.conf
On vérifie.
# cat /var/lib/pgsql/10/data/pg_hba.conf | grep md5 # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256", # Note that "password" sends passwords in clear text; "md5" or host all all 127.0.0.1/32 md5 host all all ::1/128 md5 host replication all 127.0.0.1/32 md5 host replication all ::1/128 md5
Création de l'usager odoo dans PostgreSQL
On peut choisir le mot de passe qu'on veut mais, l'important est de le mémoriser. De plus, il est préférable qu'il réponde aux normes de SME pour les mots de passe.
Pour notre démonstration seulement, on déroge aux normes de SME et on choisit "fghtbgh" qui est le mot de passe préféré du fameux Général Toto.
# echo -e "fghtbgh\nfghtbgh\n" | su - postgres -c "createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt odoo"
Le mot de passe a été donné à l'intérieur de la commande.
L'usager odoo a été créé dans PostgreSQL par le super-utilisateur postgres su - postgres et non dans le Serveur SME.
Sécurité
Référence: https://www.odoo.com/documentation/11.0/setup/deploy.html.
Sécurité de base
Pour commencer, gardez à l'esprit que la sécurisation d'un système d'information est un processus continu et non pas une opération ponctuelle. A tout moment, vous ne serez pas plus sécurisé que le maillon le plus faible de votre environnement.
- Alors, s'il vous plaît, ne prenez pas ce paragraphe comme la liste ultime des mesures qui préviendront tous les problèmes de sécurité. Il est seulement conçu comme un résumé des premières mesures importantes que vous devriez être certain d'inclure dans votre plan d'action de sécurité. Le reste proviendra des meilleures pratiques de sécurité pour votre système d'exploitation/distribution de même que des meilleures pratiques en termes d'utilisateurs, mot de passe, gestion du contrôle d'accès, etc.
- Lors du déploiement d'un serveur connecté à l'Internet, veillez à prendre en compte les sujets suivants relatifs à la sécurité:
- Définissez toujours un mot de passe administrateur (super-utilisateur) robuste et restreignez l'accès aux pages de gestion de base de données dès que le système est configuré. Voir: Sécurité du gestionnaire de base de données au prochain paragraphe.
- Choisissez des login uniques et des mots de passe robustes pour tous les comptes d'administrateur sur toutes les bases de données. N'utilisez pas 'admin' comme identifiant. N'utilisez pas ces login pour les opérations quotidiennes mais, uniquement pour contrôler/gérer l'installation. N'utilisez jamais de mot de passe par défaut comme admin/admin, même pour les bases de données de test.
- Utilisez les filtres de base de données appropriés (--db-filter) pour restreindre la visibilité de vos bases de données en fonction du nom d'hôte. Vous pouvez également utiliser -d pour fournir votre propre liste (séparée par des virgules) de bases de données disponibles à filtrer, au lieu de laisser le système les récupérer à partir de l'arrière-plan de la base de données
- Une fois que vos paramètres db_name et db_filter sont configurés et ne correspondent qu'à une seule base de données par nom d'hôte, vous devez définir l'option de configuration list_db à False pour empêcher l'affichage complet des bases de données et bloquer l'accès aux écrans de gestion de BD. (Ce paramètre est également présenté comme option de ligne de commande: --no-database-list.)
- Assurez-vous que l'utilisateur PostgreSQL (--db_user) n'est pas un super-utilisateur et que vos bases de données appartiennent à un utilisateur différent. Par exemple, elles pourraient être la propriété du super-utilisateur postgres si vous utilisez un utilisateur db_user non privilégié.
- Maintenez les installations à jour en installant régulièrement les dernières versions, soit via GitHub, soit en téléchargeant la dernière version de https://www.odoo.com/page/download ou http://nightly.odoo.com.
- Configurez votre serveur en mode multiprocessus1 avec des limites adaptées à votre utilisation habituelle (mémoire/CPU/délais d'attente). Voir Builtin server sur la page de référence.
- Exécutez Odoo derrière un serveur Web fournissant une connexion HTTPS avec Certificat SSL valide, afin d'empêcher l'écoute clandestine des communications, en texte clair. De nos jours, les Certificats SSL ne sont plus aussi dispendieux qu'autrefois et, de nombreuses options gratuites existent (Let's Encrypt - voir: https://www.micronator.org/affaires/produit/micronator-101-cahier-4certificat-lets-encrypt/).
- Configurez le mandataire (proxy) Web pour limiter la taille des demandes, définissez des délais d'attente appropriés puis, activez le mode du mandataire. Voir HTTPS server sur la page de référence.
- Si vous devez autoriser l'accès SSH à distance à vos serveurs, veillez à définir un mot de passe robuste pour tous les comptes et non pas seulement pour root.
- Il est fortement recommandé de désactiver complètement l'authentification par mot de passe et d'autoriser uniquement l'authentification par clé publique. Envisagez également de restreindre l'accès via un VPN, en autorisant uniquement les adresses IP approuvées dans le pare-feu et/ou en installant un système de détection d'attaque de force brute tel que Fail2ban ou équivalent. (Voir: https://www.micronator.org/affaires/produit/sme-9-x8-x-fail2ban/.)
- Dans la mesure du possible, hébergez vos instances de démo/test sur des machines différentes de celles de production et leur appliquer les mêmes précautions de sécurité que celles pour les serveurs en production.
- Si vous hébergez plusieurs clients, isolez les données des clients et leurs fichiers les uns des autres en utilisant des conteneurs ou des techniques appropriées de "jail".
- Configurez les sauvegardes quotidiennes de vos bases de données/fichiers et copiez-les sur un serveur d'archivage distant qui n'est pas accessible depuis le serveur lui-même.
Sécurité du gestionnaire des bases de données
Sur la page de référence, le paragraphe Configuring Odoo mentionne le paramètre admin_passwd.
"Les écrans de gestion de base de données sont protégés par le paramètre admin_passwd. Ce paramètre ne peut être défini qu'à l'aide de fichiers de configuration et il est toujours vérifié avant d'effectuer des modifications sur une base de données. Il doit être défini sur une valeur générée aléatoirement pour s'assurer que les tiers ne peuvent pas utiliser cette interface." Ce paramètre est utilisé sur tous les écrans de gestion de base de données (créer, supprimer, vider ou restaurer des bases de données).
Si les écrans de gestion ne doivent pas être accessibles du tout, vous devez définir l'option de configuration list_db à False pour bloquer l'accès à tous les écrans de sélection et de gestion de bases de données. Il faut absolument vous assurer de configurer un paramètre db_name approprié (et éventuellement aussi db_filter) afin que le système puisse déterminer la base de données cible pour chaque requête sinon, les utilisateurs seront bloqués car, ils ne seront pas autorisés à choisir eux-mêmes la base de données.
Si les écrans de gestion ne doivent être accessibles qu'à partir d'un ensemble de machines sélectionnées, utilisez les fonctions du serveur mandataire pour bloquer l'accès à toutes les routes commençant par /web/database sauf (peut-être) /web/database/selector qui affiche l'écran de sélection de la BD.
Si l'écran de gestion de la base de données doit toujours demeurer accessible, le paramètre admin_passwd doit être modifié par rapport à l'admin par défaut: ce mot de passe est vérifié avant d'autoriser les opérations de modification de la BD.
Il devrait être stocké en toute sécurité et être généré de manière aléatoire.
Exemple qui générera une chaîne imprimable pseudo-aléatoire de 32 caractères:
| python -c 'import base64, os; print(base64.b64encode(os.urandom(24)))' |
Collection RH-Python36
Les développeurs de RedHat ont pensé qu'un inconvénient avec leurs versions de Python, PHP, etc... allait survenir tôt ou tard et ont écrit les paquets des Collections.
Nous allons installer la Collection RH-Python36 pour pouvoir utiliser la version Python-3.6 qui est une version plus récente que celle installée par défaut avec le Serveur SME-9.2 (Python 2.6.6).
Toutes les Collections Centos-6.10 x86 ou 64 se trouvent à l'URL: http://mirror.centos.org/centos/6/sclo/x86_64/rh/
Dépôt centos-sclo-rh
Pour installer un logiciel, il faut indiquer à yum de quel URL il doit le télécharger. Pour ce faire, il faut configurer une description du dépôt de logiciels et y décrire la source du téléchargement.
Description du dépôt de logiciels sous format SME
On décrit un dépôt centos-sclo-rh au format SME et on l'ajoute à la base de données des dépôts de SME-9.2.
Porter une attention particulière aux: ['], [\], et [:///].
Prendre tout le contenu de l'encadré pour la commande.
/sbin/e-smith/db yum_repositories set centos-sclo-rh repository \ Name 'Centos - RH Software Collections' \ BaseURL 'http://mirror.centos.org/centos/6/sclo/x86_64/rh/' \ EnableGroups no \ GPGCheck yes \ GPGKey file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 \ Visible no \ status disabled
On signale la modification.
# signal-event yum-modify
Attendre 20-30 secondes pour que yum ait terminé sa mise à jour.
Installation de la Collection RH-Python36
À l'URL: http://mirror.centos.org/centos/6/sclo/x86_64/rh/, la dernière version disponible pour CentOS-6.10, donc pour SME-9.2, est RP-Python36.
On lance l'installation.
# yum install -y --enablerepo=centos-sclo-rh rh-python36* Modules complémentaires chargés : fastestmirror, smeserver ... Résolution des dépendances ... Dépendances résolues ... Résumé de la transaction ========================================================== Installation de 66 paquet(s) Taille totale des téléchargements : 77 M Taille d'installation : 346 M ... Installé: rh-python36.x86_64 0:2.0-1.el6 ... Dépendance(s) installée(s) : atlas.x86_64 0:3.8.4-2.el6 ... Terminé !
Une fois la Collection RH-Python36 installée, on peut vérifier sa présence sur le serveur.
# scl -l
httpd24
rh-python36
La collection http24 est incluse dans l'installation de la collection RH-Python36.
Vérification de la version Python de la Collection RH-Python36
Le chemin de python de la collection est: /opt/rh/rh-python36/root/usr/bin/python.
# ls -als /opt/rh/rh-python36/root/usr/bin/python 0 lrwxrwxrwx 1 root root 7 31 août 22:30 /opt/rh/rh-python36/root/usr/bin/python -> python3
On affiche la version Python de la Collection RH-Python36.
# /opt/rh/rh-python36/root/usr/bin/python --version Python 3.6.3
Activation de l'environnement RH-Python36 au démarrage
Référence: http://appdev.oit.umn.edu/2015/02/11/scl/.
Pour activer de manière permanente l'environnement scl python36 à la reconnexion ou au (re)démarrage, on ajoute un script personnalisé appelé activer-rh-python36.sh dans le répertoire /etc/profile.d/.
On crée le script et on y ajoute son contenu avec la commande ci-dessous.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/profile.d/activer-rh-python36.sh <<'EOT'
#!/bin/bash
source /opt/rh/rh-python36/enable
if [[ "$X_SCLS" != *rh-python36* ]]; then
src="`scl enable rh-python36 'echo $X_SCLS'`"
pkgs=(${src// / })
uniq=($(printf "%s\n" "${pkgs[@]}" | sort -u));
export X_SCLS="${uniq[@]}"
fi
EOT
On rend le script exécutable.
# chmod +x /etc/profile.d/activer-rh-python36.sh
On vérifie.
# ls -ls /etc/profile.d/activer-rh-python36.sh 4 -rwxr-xr-x 1 root root 231 31 août 22:37 /etc/profile.d/activer-rh-python36.sh
Ce script prendra effet après une déconnexion/reconnexion ou un réamorçage du serveur.
Vérification
Le moyen le plus simple pour la vérification est de vous déconnecter de la console et de vous reconnecter.
On se déconnecte, on se reconnecte et on vérifie.
# which python /opt/rh/rh-python36/root/usr/bin/python
# python --version
Python 3.6.3
Prérequis pour Odoo
Odoo-11 requière un assez grand nombre de dépendances avant d'être installé.
Toutes ces dépendances sont installées en tant qu'usager root.
Logiciels généraux
Le compilateur gcc est nécessaire lors de l'installation de certains prérequis qui doivent être compiler avant leur installation. Comme la présence de gcc sur un serveur est un bris majeur de sécurité, une fois l'installation d'Odoo terminée, on le désinstallera et on fera de même de sa dépendance cpp. Voir le paragraphe: Désinstallation des compilateurs gcc et cpp.
Installation
# yum install -y git gcc zlib-devel bzip2-devel openssl-devel \ ncurses-devel sqlite-devel readline-devel tk-devel \ libffi-devel libxslt libxslt-devel libxml2-devel \ openldap-devel libjpeg-turbo-devel openjpeg-devel \ libtiff-devel libXext libz.so.1 xorg-x11-fonts-Type1 ... Installation de 50 paquet(s) Taille totale des téléchargements : 36 M Taille d'installation : 100 M ...
Logiciels du dépôt EPEL
Configuration pour le dépôt de logiciels EPEL.
Prendre tout le contenu de l'encadré pour la commande.
db yum_repositories set epel repository \ Name 'Epel - EL6' \ BaseUrl 'http://download.fedoraproject.org/pub/epel/6/$basearch' \ MirrorList 'http://mirrors.fedoraproject.org/mirrorlist?repo=epel-6&arch=$basearch' \ EnableGroups no \ GPGCheck yes \ GPGKey http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL \ Visible no \ status disabled
On signale les changements à yum.
# signal-event yum-modify
Attendre 20-30 secondes pour que yum ait le temps d'accomplir sa mise à jour.
cabextract
L'utilitaire cabextract est un logiciel pour l'extraction des fichiers CAB de Microsoft (.cab) ou tout fichier binaire qui incorpore un fichier CAB (fréquemment trouvé dans les fichiers .exe).
# yum install -y --enablerepo=epel cabextract
Modules complémentaires chargés : fastestmirror, smeserver
...
Installation de 2 paquet(s)
Taille totale des téléchargements : 110 k
Taille d'installation : 248 k
...
Installé:
cabextract.x86_64 0:1.5-1.el6
Dépendance(s) installée(s) :
libmspack.x86_64 0:0.6-0.1.alpha.el6
Terminé !
La dépendance qui a été installée, libmspack.x86_64 0:0.6-0.1.alpha.el6, contient les polices de base de Microsoft afin qu'elles soient disponibles lorsque vous générez des rapports dans Odoo.
npm
Référence: https://fr.wikipedia.org/wiki/Npm.
L'utilitaire npm est le gestionnaire officiel des paquets de Node.js. Depuis la version 0.6.3 de Node.js, npm fait partie de l'environnement et est donc automatiquement installé par défaut. L'utilitaire npm fonctionne avec un terminal et gère les dépendances pour les applications. Il permet également d'installer les applications Node.js disponibles dans le dépôt npm.
Il ne faut pas installer la dernière version car, elle génère une erreur de style dûe à l'utilitaire lssc qui n'est pas reconnue.
| Style error
The style compilation failed, see the error below. Your recent actions may be the cause, please try reverting the changes you made. |
On installe plutôt Node.js-10.5.0 qui installera aussi npm.
Les versions disponibles se trouvent à l'URL: https://nodejs.org/download/release/
On crée un répertoire de travail.
# mkdir /temp
On s'y rend.
# cd /temp/
On télécharge la version Node.js-10.5.0.
# wget https://nodejs.org/download/release/v10.5.0/node-v10.5.0-linux-x64.tar.gz --2018-08-31 22:53:58-- https://nodejs.org/download/release/v10.5.0/node-v10.5.0-linux-x64.tar.gz Résolution de nodejs.org... 104.20.23.46, 104.20.22.46, 2400:cb00:2048:1::6814:172e, ... Connexion vers nodejs.org|104.20.23.46|:443...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 18362640 (18M) [application/gzip] Sauvegarde en : «node-v10.5.0-linux-x64.tar.gz» 100%[==================================================>] 18 362 640 1,80M/s ds 9,7s 2018-08-31 22:54:08 (1,80 MB/s) - «node-v10.5.0-linux-x64.tar.gz» sauvegardé [18362640/18362640]
On extraie vers le répertoire /usr.
# tar -C /usr --strip-components 1 -xzf node-v10.5.0-linux-x64.tar.gz
On vérifie.
# which npm
/usr/bin/npm
# npm --version
6.1.0
Logiciels spéciaux
less
Référence: https://fr.wikipedia.org/wiki/Less_(langage).
L'utilitaire less est un langage dynamique de génération de CSS conçu par Alexis Sellier. Initialement inspiré par Sass, il l'influence à son tour avec l'apparition de la syntaxe SCSS par laquelle Sass reprend des éléments de la syntaxe CSS classique. Le principe de Less est en effet de ne pas rompre avec la syntaxe CSS: tout code CSS est aussi du code Less valide et sémantiquement équivalent. Less y ajoute notamment les mécanismes suivants: variables, imbrication, mixins, opérateurs et fonctions.
less-plugin-clean-css
Référence: https://github.com/less/less-plugin-clean-css.
Cet utilitaire compresse la sortie css de less en utilisant clean-css.
Pour éviter les erreurs de certificats SSL et de téléchargement.
# npm config set strict-ssl false
On installe ces deux logiciels.
# npm install -g less less-plugin-clean-css /usr/local/bin/lessc -> /usr/local/lib/node_modules/less/bin/lessc + less-plugin-clean-css@1.5.1 + less@3.8.1 added 65 packages from 127 contributors in 4.786s
On vérifie.
# which less
/usr/bin/less
# less --version less 436 Copyright (C) 1984-2009 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less
# which lessc
/usr/bin/lessc
# lessc --version
lessc 3.8.1 (Less Compiler) [JavaScript]
wkhtmltox
Référence: https://wiki.contribs.org/Odoo.
Les wkhtmltox disponibles à partir de CentOS ou du dépôt EPEL sont d'une version inférieure à celle requise par Odoo. De plus, ces versions ne convertissent pas les en-têtes et les pieds de page. Il est fortement recommandé d'obtenir la dernière version stable directement de la source.
Dépendances pour wkhtmltopdf
Référence: https://wkhtmltopdf.org/.
wkhtmltopdf et wkhtmltoimage sont des outils de ligne de commande LIBRE (LGPLv3) pour convertir du code HTML en PDF ou en divers autres formats d'image en utilisant le moteur de rendu Qt WebKit. Ces outils fonctionnent entièrement "sans tête" (headless) et ne nécessitent pas de service d'écran ou d'affichage.
On installe les dépendances.
# yum install -y fontconfig libpng libX11 libXext libXrender xorg-x11-fonts-Type1 xorg-x11-fonts-75dpi Modules complémentaires chargés : fastestmirror, smeserver ... Résumé de la transaction Installation de 1 paquet(s) Taille totale des téléchargements : 2.8 M Taille d'installation : 2.9 M ... Installé: xorg-x11-fonts-75dpi.noarch 0:7.2-11.el6 Terminé !
Installation de wkhtmltox
On se rend dans le répertoire de travail.
# cd /temp
On nettoie le répertoire /temp.
# rm -rf *
On se rend à l'Url: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/.
On claque (clic droit) sur le fichier: wkhtmltox-0.12.4_linux-generic-amd64.tar.xz > Copier l'adresse du lien.
Dans le répertoire de travail on entre wget suivi d'un espace puis, on colle le lien copié ci-dessus.
On télécharge le fichier tar.xz.
# wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.4/wkhtmltox-0.12.4_linux-generic-amd64.tar.xz --2018-08-31 23:05:16-- https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.4/wkhtmltox-0.12.4_linux-generic-amd64.tar.xz Résolution de github.com... 192.30.253.113, 192.30.253.112 Connexion vers github.com|192.30.253.113|:443...connecté. requête HTTP transmise, en attente de la réponse...302 Found Emplacement: https://github-production-release-asset-2e65be.s3.amazonaws.com/271714/6b136718-52da-11e7-93f3-2b4ee2eccece?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20180901%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20180901T030517Z&X-Amz-Expires=300&X-Amz-Signature=aa11f2fbbf9c4ab3bffdda49c5e1ea2322c8bcc87ebdcbdcc76904402dbedcb9&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dwkhtmltox-0.12.4_linux-generic-amd64.tar.xz&response-content-type=application%2Foctet-stream [suivant] --2018-08-31 23:05:17-- https://github-production-release-asset-2e65be.s3.amazonaws.com/271714/6b136718-52da-11e7-93f3-2b4ee2eccece?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20180901%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20180901T030517Z&X-Amz-Expires=300&X-Amz-Signature=aa11f2fbbf9c4ab3bffdda49c5e1ea2322c8bcc87ebdcbdcc76904402dbedcb9&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dwkhtmltox-0.12.4_linux-generic-amd64.tar.xz&response-content-type=application%2Foctet-stream Résolution de github-production-release-asset-2e65be.s3.amazonaws.com... 52.216.96.235 Connexion vers github-production-release-asset-2e65be.s3.amazonaws.com|52.216.96.235|:443...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 14541904 (14M) [application/octet-stream] Sauvegarde en : «wkhtmltox-0.12.4_linux-generic-amd64.tar.xz» 100%[==================================================>] 14 541 904 1,80M/s ds 7,9s 2018-08-31 23:05:28 (1,75 MB/s) - «wkhtmltox-0.12.4_linux-generic-amd64.tar.xz» sauvegardé [14541904/14541904]
Une première extraction avec l'utilitaire unxz.
# unxz wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
Une deuxième extraction avec tar.
# tar -xvf wkhtmltox-0.12.4_linux-generic-amd64.tar ... wkhtmltox/include/wkhtmltox/dllend.inc wkhtmltox/bin/ wkhtmltox/bin/wkhtmltoimage wkhtmltox/bin/wkhtmltopdf wkhtmltox/share/ ...
On déplace le contenu du répertoire wkhtmltox/bin/ dans /usr/bin/ afin de le rendre disponible à tous les utilisateurs du Serveur SME.
# mv wkhtmltox/bin/* /usr/bin/
On vérifie.
# ls -als /usr/bin/wkhtmlto* 38796 -rwxr-xr-x 1 1000 1000 39723880 22 nov. 2016 /usr/bin/wkhtmltoimage 38872 -rwxr-xr-x 1 1000 1000 39804584 22 nov. 2016 /usr/bin/wkhtmltopdf
On supprime tout dans le répertoire /temp.
rm -rf /temp/*
On retourne dans le répertoire personnel de root.
# cd
pychart
PyChart est une bibliothèque Python pour la création de PDF, PNG ou graphiques SVG en PostScript encapsulé de haute qualité. Il prend actuellement en charge les traçage linéaires, les graphiques circulaires et par barres. Parce qu'il est basé sur Python, vous pouvez utiliser le pouvoir de scriptage de Python.
On copie le lien depuis: https://centos.pkgs.org/6/centos-i386/pychart-1.39-10.1.el6.noarch.rpm.html
On installation pychart-1.39-10.1.
# rpm -Uvh http://mirror.centos.org/centos/6/os/i386/Packages/pychart-1.39-10.1.el6.noarch.rpm Récupération de http://mirror.centos.org/centos/6/os/i386/Packages/pychart-1.39-10.1.el6.noarch.rpm Préparation... ########################################### [100%] 1:pychart ########################################### [100%]
Vérifications
NPM
# which npm
/usr/bin/npm
# npm --version
6.1.0
LESS
# which less
/usr/bin/less
# less --version less 436 Copyright (C) 1984-2009 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less
LESSC
# which lessc
/usr/bin/lessc
# lessc --version
lessc 3.8.1 (Less Compiler) [JavaScript]
Signalisation des changements
Nous avons fait plusieurs changements, il est temps de les signaler avec les commandes traditionnelles.
Peut prendre un certain temps, être patient!
# signal-event post-upgrade; signal-event reboot
Installation d'Odoo
Usager odoo
On a déjà crée l'usager odoo, changer son mot de passe et son shell.
Pour cette contribution, on présume que le mot de passe de l'usager odoo est: fghtbgh; le mot de passe qu'utilise habituellement le fameux Général Toto.
On vérifie le shell de l'usager odoo.
# cat /etc/passwd | grep odoo
odoo:x:5001:5001:Utilisateur Environnement virtuel:/home/e-smith/files/users/odoo:/bin/bash
Répertoire racine d'Odoo
On crée le répertoire qui contiendra la suite des logiciels Odoo dans le répertoire racine de l'i-bay Primary.
# mkdir /home/e-smith/files/ibays/Primary/html/odoo
On change le propriétaire et le groupe de ce répertoire.
# chown odoo:odoo /home/e-smith/files/ibays/Primary/html/odoo
Installation avec git
On se substitue à l'usager odoo.
# su - odoo
L'invite va passer de # à $ car, odoo est un usager standard de SME.
On se rend dans le répertoire racine de l'i-bay Primary.
$ cd /home/e-smith/files/ibays/Primary/html/
On télécharge la branche 11.0 d'Odoo.
$ git clone https://github.com/odoo/odoo.git --branch 11.0 --depth=1 Initialized empty Git repository in /home/e-smith/files/ibays/Primary/html/odoo/.git/ remote: Counting objects: 418372, done. remote: Compressing objects: 100% (204776/204776), done. remote: Total 418372 (delta 320772), reused 265639 (delta 209054), pack-reused 0 Receiving objects: 100% (418372/418372), 667.04 MiB | 1.80 MiB/s, done. Resolving deltas: 100% (320772/320772), done.
On revient à l'usager root.
$ exit
requirements.txt
Obligatoirement en tant qu'usager root.
# cd /home/e-smith/files/ibays/Primary/html/odoo/
Avec l'utilitaire pip, on installe tous les prérequis contenus dans le fichier requirements.txt.
# /opt/rh/rh-python36/root/usr/bin/pip install -r requirements.txt ... Successfully installed Babel-2.3.4 Jinja2-2.8.1 Mako-1.0.4 MarkupSafe-0.23 Pillow-4.0.0 PyPDF2-1.26.0 Werkzeug-0.11.15 XlsxWriter-0.9.3 beautifulsoup4-4.6.3 decorator-4.0.10 docutils-0.12 ebaysdk-2.1.5 feedparser-5.2.1 gevent-1.1.2 greenlet-0.4.10 html2text-2016.9.19 lxml-3.7.1 mock-2.0.0 num2words-0.5.4 ofxparse-0.16 olefile-0.45.1 passlib-1.6.5 pbr-4.2.0 psutil-4.3.1 psycopg2-2.7.3.1 pydot-1.2.3 pyldap-2.4.28 pyparsing-2.1.10 pyserial-3.1.1 python-dateutil-2.5.3 python-stdnum-1.9 pytz-2016.7 pyusb-1.0.0 qrcode-5.3 reportlab-3.3.0 requests-2.11.1 suds-jurko-0.6 vatnumber-1.2 vobject-0.9.3 xlrd-1.0.0 xlwt-1.3.0 You are using pip version 9.0.1, however version 18.0 is available. You should consider upgrading via the 'pip install --upgrade pip' command.
On retourne dans le répertoire personnel de root.
# cd
Propriétaire, groupe et droits
Après une installation quelconque, on s'assure que le propriétaire et le groupe sont odoo:odoo en changeant Récursivement le propriétaire et le groupe dans tout le répertoire d'Odoo.
# chown -R odoo:odoo /home/e-smith/files/ibays/Primary/html/odoo
On enlève Récursivement tous les droits que pourrait avoir "other" dans tout le répertoire d'Odoo.
# chmod -R o-rwx /home/e-smith/files/ibays/Primary/html/odoo
Création des répertoires PIDFILE et LOGFILE
Répertoires à créer: PIDFILE=/var/run/odoo/odoo-server.pid et LOGFILE=/var/log/odoo/odoo-server.log.
On crée les répertoires en prenant tout le contenu de l'encadré pour la commande.
DIR="/var/run/odoo /var/log/odoo" for NAME in $DIR do if [ ! -d $NAME ]; then mkdir $NAME chown odoo.odoo $NAME chmod 770 $NAME fi done
logrotation
Nous autorisons la rotation des journaux d'Odoo de telle sorte qu'ils seront gérés de la même manière que ceux de toutes les autres applications du Serveur SME.
Vous pourrez vérifier les fichiers journaux d'Odoo dans le gestionnaire Server Manager: Visualisation des fichiers journaux > odoo/odoo-server.log.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/logrotate.d/odoo-server << EOF
/var/log/odoo/odoo-server.log {
# Fichier de logrotate pour /var/log/odoo/odoo-server.log
#
# Si le fichier n'existe pas, pas de problème
missingok
# Rotation quotidienne
daily
# Grandeur maximale de 100k
maxsize 100k
# Ne conserver que 21 fichiers de log
rotate 21
# Ne pas faire de rotation si le fichier est vide.
notifempty
}
EOF
Fichier de configuration: /etc/odoo-server.conf
Pour débuter, nous activons log_handler = :DEBUG pour voir tous les messages d'Odoo dans le fichier journal. Lorsque tout fonctionnera correctement, on remettra la valeur par défaut.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/odoo-server.conf <<'EOT' [options] ; Ceci est le mot de passe qui autorise les oprérations sur la base de données: admin_passwd = fghtbgh ; OPTIONS DE LA BASE DE DONNÉES> db_host = localhost db_port = 5432 db_user = odoo db_password = fghtbgh ; PARAMÈTRES DIVERS addons_path = /home/e-smith/files/ibays/Primary/html/odoo/addons load = web timezone = America/Montreal without-demo=all no-xmlrpc = True no-xmlrpcs = True no-netrpc = True ; PARAMÈTRES DES JOURNAUX logfile = /var/log/odoo/odoo-server.log ; - Ceci est le défault ;log_handler = werkzeug:WARNING ; - Pour voir tous les messageS d'Odoo, on active à :DEBUG log_handler = :DEBUG ;log_level = warn no-logrotate = True EOT
Faille de sécurité car, ce fichier contient les mots de passe du super-utilisateur et celui de la BD; ils sont lisibles par "other" i.e. tout le monde.
On vérifie les droits du fichier.
# ls -als /etc/odoo-server.conf
4 -rw-r--r-- 1 root root 664 31 août 23:38 /etc/odoo-server.conf
On rend le script exécutable et on enlève tous les droits à "other".
# chmod 550 /etc/odoo-server.conf
On change le propriétaire et le groupe pour odoo:odoo
# chown odoo:odoo /etc/odoo-server.conf
On vérifie.
# ls -ls /etc/odoo-server.conf 4 -r-xr-x--- 1 odoo odoo 665 31 août 23:38 /etc/odoo-server.conf
Fichier /etc/rc.d/init.d/odoo
Pour lancer, arrêter, demander le statut... du démon odoo.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/rc.d/init.d/odoo <<'EOT'
#!/bin/bash
# odoo-server - Ce script s'occupe du démarrage et de l'arrêt d'Odoo
# description: Odoo server
# pidfile: /var/run/odoo-server.pid
# config: /etc/odoo-server.conf
### BEGIN INIT INFO
# Provides: odoo-server
# Required-Start: postgresql
# Required-Stop: postgresql
# Should-Start: $network harddrake
# Default-Start: 345
# Short-Description: Démarre le serveur Odoo.
# Description: Ce script démarre le serveur Odoo.
### END INIT INFO
# Source function library.
. /etc/rc.d/init.d/functions
PIDFILE=/var/run/odoo/odoo-server.pid
LOCKFILE=/var/lock/subsys/odoo-server
LOGFILE=/var/log/odoo/odoo-server.log
OPTS="--pidfile=$PIDFILE --logfile=$LOGFILE"
prog="odoo-server"
desc="Odoo Server Daemon"
# Vérifie si le fichier de configuration odoo-server.conf est présent et si oui, il est utilisé
if [ -f /etc/odoo-server.conf ]; then
OPTS="$OPTS -c /etc/odoo-server.conf"
fi
# Source function library
if [ -f /etc/init.d/functions ] ; then
. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functions
else
exit 0
fi
start() {
echo -n $"Starting $desc ($prog): "
daemon --user odoo --check odoo-server \
"/opt/rh/rh-python36/root/usr/bin/python /home/e-smith/files/ibays/Primary/html/odoo/odoo-bin \
-c /etc/odoo-server.conf \
--pidfile=$PIDFILE \
--logfile=$LOGFILE &"
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch $LOCKFILE
return $RETVAL
}
stop() {
echo -n $"Stopping $desc ($prog): "
kill -TERM `cat $PIDFILE` > /dev/null 2>&1
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
rm -f $LOCKFILE
echo_success
echo
else
echo_failure
echo
fi
return $RETVAL
}
restart() {
stop
start
}
condrestart() {
[ -e $LOCKFILE ] && restart || :
}
status() {
if [ -f $PIDFILE ] ; then
checkpid `cat $PIDFILE`
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
echo $"$prog is running..."
else
echo $"$prog is stopped"
fi
else
echo $"$prog is stopped"
fi
return $RETVAL
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
restart
;;
condrestart)
condrestart
;;
status)
status
;;
probe)
exit 0
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"
exit 1
esac
EOT
On rend le script exécutable.
# chmod 550 /etc/rc.d/init.d/odoo
Démarrage
On veut qu'Odoo-11 se lance automatiquement à tous les amorçages du Serveur SME-9.2. On ajoute donc un lien vers /etc/rc.d/init.d/odoo dans le répertoire /etc/rc.d/rc7.d.
ln -s /etc/rc.d/init.d/odoo /etc/rc.d/rc7.d/S99odoo
Arrêt
On veut qu'Odoo-11 s'arrête automatiquement lorsque le Serveur SME-9.2 s'arrête. On ajoute donc un lien vers /etc/rc.d/init.d/odoo dans le répertoire /etc/rc.d/rc6.d.
ln -s /etc/rc.d/init.d/odoo /etc/rc.d/rc6.d/K95odoo
Signalisation des changements
Nous avons fait plusieurs changements, on signale ceux-ci de manière traditionnelle et on pourra en profiter pour vérifier l'arrêt et le redémarrage d'Odoo-11.
Peut prendre quelques temps avant de voir une réponse à ces commandes.
# signal-event post-upgrade; signal-event reboot
Après le ré-amorçage, on se logue et on vérifie le statut d'Odoo.
# /etc/init.d/odoo status
odoo-server est en cours d'exécution...
Finalisation de l'installation
Accès à Odoo
Autoriser les témoins et activer JavaScript.
À l'aide d'un fureteur Internet, on se rend à la page de notre site Odoo en spécifiant le port :8069.
PAS DE https:, SEULEMENT http://192.168.1.11:8069.
L'affichage de la page peut prendre un certain temps (quelques 10 secondes).
Création d'une nouvelle base de données
- Master password: le mot de passe,
db_password =fghtbgh, qu'on a spécifié dans le fichier de configuration/etc/odoo-server.conf. - Database name: le nom de la base de données pour Odoo.
- Email: notre adresse courriel. On utilisera cette adresse pour se loguer en tant qu'Administrateur d'Odoo.
- Password: le mot de passe pour l'Administrateur d'Odoo (usager spécifié ci-dessus dans le champ Email).
- Language: on choisit, dans le menu déroulant, la langue par défaut pour notre site.
- Country: Choisir le pays pour notre site.
- ☑ Load demonstration data (Check this box to evaluate Odoo): cocher si on veut installer des données fictives pour l'évaluation d'Odoo. (Ne pas cocher pour un site en Production.)
On clique Create Database pour créer la base de données pour notre société.
 |
Après qu'on a cliqué Create Database, Odoo manipule plusieurs fichiers.
|
Lien de redirection dans l'i-bay Primary
Si nous n'avons aucun site Web dans l'i-bay Primary et que nous spécifions seulement http://192.168.1.11 sans spécifier le port 8069, nous verrons s'afficher le contenu du fichier par défaut, index.htm, contenu dans le répertoire /home/e-smith/files/ibays/Primary/html.
|
 |
Même si nous supprimons ce fichier et qu'il n'y ait aucun autre fichier index.* tel que index.php, le fichier index.htm sera recréé si nous exécutons les commandes signal-event post-upgrade; signal-event reboot ou, après une mise à jour du Serveur SME.
Contenu du répertoire après les commandes: signal-event post-upgrade; signal-event reboot.
# ls -als /home/e-smith/files/ibays/Primary/html total 16 4 drwxr-s--- 3 admin shared 4096 17 juin 22:01 . 4 drwxr-xr-x 6 root root 4096 17 juin 12:59 .. 4 -rw-r----- 1 admin shared 202 20 nov. 2005 index.htm 4 drwxr-sr-x 10 odoo odoo 4096 17 juin 22:12 odoo
On pourrait créer une règle iptables qui redirigerait le port standard 80 vers le port 8069. Le problème avec un tel scénario est qu'on perdrait l'accès à notre site Internet standard qui pourrait être aussi hébergé sur le serveur.
Redirection par le fichier index.htm
On modifie le fichier index.html, dans le répertoire Primary/html, pour qu'il fasse une redirection HTML vers le port 8069.
On vérifie si nous sommes toujours l'usager root.
# whoami
root
Ici, pour cette documentation, on utilise l'adresse IP de notre serveur mais, il faudra utiliser le vrai nom du domaine pour un serveur en Production.
On modifie le fichier index.html.
Prendre tout le contenu de l'encadré pour la commande.
cat > /home/e-smith/files/ibays/Primary/html/index.htm << EOF <head> <META http-EQUIV="Refresh" CONTENT="0; url=http://192.168.1.11:8069"> </head> EOF
On ajuste le propriétaire et le groupe.
# chown admin:shared /home/e-smith/files/ibays/Primary/html/index.htm
Vérification de la redirection
On vidange l'historique de notre navigateur.
Il faut autoriser java script et les témoins (cookies) dans notre fureteur.
| http://192.168.1.11 (sans le port 8069) | Comme on le voit ci-dessous, la redirection a eu lieu → http://192.168.1.11:8069/web/login |
 |
 |
On est automatiquement redirectionné vers la page de login car, la vidange de l'historique a aussi supprimé le témoin d'Odoo, il ne nous reconnaît plus et présente alors la page de login.
Redirection dans le répertoire .../Primary/html/odoo
Nous pourrions être tentés de faire le même genre de redirection HTML dans le répertoire racine d'Odoo qui est /home/e-smith/files/ibays/Primary/html/odoo et ainsi accéder à notre site en spécifiant: http://192.168.1.11/odoo et être redirigé vers http://192.168.1.11:8069.
Malheureusement, la redirection dans un répertoire autre que .../Primary/html/. est impossible dûe au fait de l'utilisation de la directive Indexes disabled pour l'i-bay Primary.
Fichier de configuration /etc/odoo-server.conf
Maintenant que tout fonctionne correctement, on peut remettre le paramètre log_handler à sa valeur par défaut en dé-commentant la ligne log_handler = werkzeug:WARNING et en commentant la ligne ;log_handler = :DEBUG.
On utilise vi ou Notepad++ pour éditer le fichier.
# vi /etc/odoo-server.conf
Vu que le fichier n'a pas de droit d'écriture, lorsque root écrira les modifications, il devra utiliser w! (w et !).
... ; - Ceci est le défault log_handler = werkzeug:WARNING ; - Pour voir tous les messageS d'Odoo, on active à :DEBUG ;log_handler = :DEBUG ;log_level = warn no-logrotate = True ...
Nous avons changé un paramètre important, on redémarre le démon odoo.
# /etc/init.d/odoo restart Arrêt de Odoo Server Daemon (odoo-server) : [ OK ] Démarrage de Odoo Server Daemon (odoo-server) : [ OK ]
On vérifie les changements dans le fichiers /etc/odoo-server.conf.
# cat /etc/odoo-server.conf | grep log_handler log_handler = werkzeug:WARNING ;log_handler = :DEBUG
Désinstallation des compilateurs gcc et cpp
Avoir gcc installé sur un serveur est un risque majeur de sécurité vu qu'un pirate pourrait s'en servir pour compiler un logiciel malveillant. Il faut donc le désinstaller.
Si, plus tard, nous avions encore besoin de gcc, il suffirait de l'installer à nouveau.
Le paquet gcc vient avec cpp.
Nous forçons la désinstallation de ces deux RPMs.
# rpm -e --nodeps gcc cpp
On vérifie cpp.
# rpm -qa | grep cpp
La commande ne retourne rien, le compilateur cpp a été supprimé.
On vérifie gcc.
# rpm -qa | grep gcc
libgcc-4.4.7-23.el6.x86_64
La librairie libgcc est utilisée par beaucoup de logiciels; il ne faut absolument pas la désinstaller car, un de ses utilisateurs le plus important est le programme dar pour les sauvegardes du Serveur SME.
Les compilateurs gcc et cpp ont été supprimés.
Post-scriptum Odoo
Après un réamorçage, on peut vérifier les démarrages de nos démons.
PostgreSQL
Usage: /etc/init.d/postgresql-10 {start|stop|status|restart|initdb|promote|upgrade|condrestart|reload|promote|force-reload}
Exemple:
# /etc/init.d/postgresql-10 status
Odoo
Usage: /etc/init.d/odoo {start|stop|restart|condrestart|status}
Exemple:
# /etc/init.d/odoo status
Administration du serveur Odoo
Pour administrer le serveur Odoo, il suffit de se loguer avec le nom de l'usager Administrateur (choisi lors de la Création d'une nouvelle base de données).
Fichiers journaux
PostgreSQL
Les fichiers journaux de PostgreSQL se trouvent dans le répertoire /var/lib/pgsql/10/data/log.
Odoo
Vous pouvez vérifier les journaux: /var/log/messages et /var/log/odoo/odoo-server.log ou dans le gestionnaire: Visualisation des fichiers journaux > odoo/odoo-server.log pour vous assurer que tout a démarré correctement.
Mots de passe
† Usager odoo de PostgreSQL
Vous pouvez trouver le mot de passe de l'usager odoo de PostgreSQL (l'usager qui gère votre base de données odoo-11) dans le fichier de configuration d'Odoo: /etc/odoo-server.conf.
Si le mot de passe a été perdu ou piraté, on peut changer le mot de passe de l'usager odoo de PostgreSQL.
Il faut changer d'usager pour devenir le super-utilisateur postgres puis, ce dernier change le mot de passe de l'usager odoo de PostgreSQL.
- Dans PostgreSQL
À la console du serveur, on se substitue à l'usager postgres.
# su - postgres
L'usager postgres entre dans la console PostgreSQL.
$ psql
On change le mot de passe de l'usager odoo de PostgreSQL. (Il faut garder les apostrophes.)
ALTER ROLE odoo WITH PASSWORD 'nouveau-mot-de-passe';
On sort de la console PostgreSQL.
# \q
On retourne à l'usager root.
$ exit
- Dans le fichier /etc/odoo-server.conf
IMPORTANT. Le changement de mot de passe de l'usager odoo dans PostgreSQL ne modifie pas celui dans /etc/odoo-server.conf. Il faut éditer ce fichier et changer le mot de passe sur la ligne: db_password =.
On édite le fichier /etc/odoo-server.conf et on change le mot de passe de l'utilisateur de la BD odoo-11 (l'usager odoo).
On vérifie.
# cat /etc/odoo-server.conf | grep db_password db_password = fghtbgh
- Dans le gestionnaire Server Manager ou à la console du serveur
On doit changer le mot de passe Linux de l'usager odoo afin que tous les mots de passe de l'usager odoo soient les mêmes pour PostgreSQL et Linux.
Dans le gestionnaire Server Manager: Server-Manager > Utilisateurs > vis-à-vis odoo, cliquer Réinitialiser le mot de passe > entrer le nouveau mot de passe > confirmer le nouveau mot de passe > Enregistrer.
On arrête et on relance le démon Odoo.
# /etc/rc.d/init.d/odoo restart
Après un changement de mot de passe, on supprime l'historique du fureteur Internet, on se connecte à Odoo et on vérifie quelques pages.
† Usager super-utilisateur de PostgreSQL
Si vous changez le mot de passe du super-utilisateur (postgres) de PostgreSQL, il faut aussi le changer ailleurs.
- Dans le fichier /etc/odoo-server.conf
On édite le fichier /etc/odoo-server.conf, on change le mot de passe du super-utilisateur de PostgreSQL et on vérifie.
cat /etc/odoo-server.conf | grep admin_passwd admin_passwd = fghtbgh
- Dans le fichier /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh
Il faut aussi changer le mot de passe du super-utilisateur postgres dans le script de sauvegarde/récupération de la base de données odoo.
On édite le fichier /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh, on change le mot de passe du super-usager postgres et on vérifie.
Ce fichier est créé plus loin, au paragraphe #Script de sauvegarde PostgreSQL. La commande ci-dessous ne fonctionnera seulement qu'après la création dudit fichier.
cat /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh | grep MDP_SUPER_USAGER MDP_SUPER_USAGER=fghtbgh
- Dans le gestionnaire Server Manager ou à la console du serveur
À la console du serveur, on change le mot de passe Linux de l'usager postgres afin que tous les mots de passe de l'usager postgres soient les mêmes pour PostgreSQL et Linux.
On vérifie si nous sommes root.
# whoami
root
À la console du serveur, on change le mot de passe Linux du super-utilisateur postgres.
# passwd postgres Changement de mot de passe pour l'utilisateur postgres. Entrez le nouveau mot de passe UNIX : entrer-le-nouveau-mot-de-passe Retapez le nouveau mot de passe UNIX : entrer-le-nouveau-mot-de-passe passwd : mise à jour réussie de tous les jetons d'authentification.
Après un changement du mot de passe du super-utilisateur PostgreSQL, on arrête et on relance le démon PostgreSQL-10.
# /etc/rc.d/init.d/postgresql-10 restart
Il faut aussi réamorcer le démon Odoo.
# /etc/rc.d/init.d/odoo restart
Après un changement de mot de passe, on supprime l'historique du fureteur Internet, on se connecte à Odoo et on vérifie quelques pages.
† Administrateur d'Odoo
On peut aussi changer le mot de passe de l'Administrateur d'Odoo en se loguant avec le nom de l'usager Administrateur (choisi lors de la Création d'une nouvelle base de données).
 |
 |
 |
Sauvegarde/restauration de la BD de PostgreSQL
- Nous allons créer un script Bash qui générera, dans le répertoire
/var/lib/pgsql/sauvegarde, un fichier ZIP de sauvegarde de la BD de PostgreSQL du site Odoo. - Le fichier sera sécurisé et seul l'usager root pourra le lire.
- Ce script sera lancé par une tâche cron qui s'exécutera à 02h00, juste avant la sauvegarde habituelle du Serveur SME, et ainsi cette dernière inclura la sauvegarde quotidienne de PostgreSQL.
Répertoire de sauvegarde
Tout ce qui a trait à la sauvegarde de la BD odoo-11 se trouvera dans un répertoire dédié à cette fin uniquement: /var/lib/pgsql/sauvegarde/.
- Le propriétaire et le groupe du répertoire seront postgres:postgres.
- Le fichier de la nouvelle sauvegarde:
- sera généré et écrasera la sauvegarde précédente et
- sera sécurisé par le script en changeant le propriétaire et le groupe pour root:root et en donnant des droits à root seulement.
On crée le répertoire.
# mkdir /var/lib/pgsql/sauvegarde
On change le propriétaire et le groupe.
# chown postgres:postgres /var/lib/pgsql/sauvegarde
On ajuste tous les droits pour que seul l'usager postgres puisse y accéder.
# chmod 700 /var/lib/pgsql/sauvegarde
On vérifie.
# ls -lsd /var/lib/pgsql/sauvegarde 4 drwx------ 2 postgres postgres 4096 29 août 13:24 /var/lib/pgsql/sauvegarde
Script de sauvegarde PostgreSQL
Prendre tout le contenu de l'encadré pour la commande.
cat > /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh <<'EOT'
#!/bin/sh
# Script pour générer une sauvegarde de la BD PostgreSQL d'Odoo.
# vars
TEMPS_DE_PAUSE=10
REP_SAUVEGARDE=/var/lib/pgsql/sauvegarde
NOM_BD_ODOO=odoo-11
FORMAT_FICHIER=zip
MDP_SUPER_USAGER=fghtbgh
PORT_ODOO=8069
# On vérifie qu'odoo-server est en cours d'exécution.
if (!(/etc/rc.d/init.d/odoo status | grep "odoo-server est en cours d'exécution...")); then
# Message au système et à la console
/bin/logger "******************** odoo-server ******************** "
/bin/logger "odoo-server N'EST PAS en cours d'execution..."
/bin/echo "odoo-server N'EST PAS en cours d'execution..."
# On relance server-odoo pour la sauvegarde de la BD $NOM_BD_ODOO
/etc/rc.d/init.d/odoo start
/bin/logger "odoo-server est relancé"
/bin/logger " ***** odoo-server *****"
/bin/echo "odoo-server est relancé"
# Message au système et à la console
/bin/logger "Pause de $TEMPS_DE_PAUSE secondes pour démarrage d'Odoo"
/bin/echo "Pause de $TEMPS_DE_PAUSE secondes pour démarrage d'Odoo"
# On fait une pause de $TEMPS_DE_PAUSE secondes pour le démarrage d'Odoo.
/bin/sleep $TEMPS_DE_PAUSE
fi
/bin/logger "******************** odoo-server ******************** "
/bin/logger "odoo-server est en cours d'execution..."
/bin/echo "odoo-server est en cours d'execution..."
# On sauvegarde la BD dans $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER.
# La sauvegarde du jour écrase la sauvegarde du jour précédent.
curl -X POST \
-F master_pwd=$MDP_SUPER_USAGER \
-F name=$NOM_BD_ODOO \
-F backup_format=$FORMAT_FICHIER \
-o $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER \
http://localhost:$PORT_ODOO/web/database/backup
# On sécurise le fichier de $NOM_BD_ODOO.$FORMAT_FICHIER.
/bin/chown root:root $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER > /dev/null 2>&1
/bin/chmod 700 $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER > /dev/null 2>&1
# On écrit une entrée dans le journal du système.
/bin/logger "La sauvegarde de la BD $NOM_BD_ODOO est dans: $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER"
/bin/logger "******************** odoo-server ******************** "
/bin/echo "La sauvegarde de la BD $NOM_BD_ODOO est dans: $REP_SAUVEGARDE/$NOM_BD_ODOO.$FORMAT_FICHIER"
exit 1
EOT
On sécurise le fichier du script en changeant le groupe et le propriétaire.
# chown root:root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh
On ajuste les droits pour rendre le fichier exécutable par l'usager root uniquement.
# chmod 700 /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh
On vérifie.
# ls -ls /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh 4 -rwx------ 1 root root 2308 29 août 13:40 /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh
Sauvegarde
Vérification du script de sauvegarde
On vérifie le fonctionnement de notre script de sauvegarde en simulant ce que fera cron.
# /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh
odoo-server est en cours d'exécution...
odoo-server est en cours d'execution...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3653k 0 3653k 119 357 1844k 180 0:00:01 0:00:01 --:--:-- 1845k
La sauvegarde de la BD odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip
On affiche le fichier de sauvegarde pour s'assurer que la sauvegarde a réussie.
# ls -ls /var/lib/pgsql/sauvegarde/odoo-11.zip 3648 -rwx------ 1 root root 3740775 29 août 13:41 /var/lib/pgsql/sauvegarde/odoo-11.zip
Comme on le voit, seul root pourra manipuler le fichier de sauvegarde.
Journal du Serveur SME
... Aug 29 13:41:48 odoo-11 root: ******************** odoo-server ******************** Aug 29 13:41:48 odoo-11 root: odoo-server est en cours d'execution... Aug 29 13:41:50 odoo-11 root: La sauvegarde de la BD odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip Aug 29 13:41:50 odoo-11 root: ******************** odoo-server ******************** ...
Si odoo-server n'est pas en exécution (arrêté)
Il en sera exactement de même si odoo-server n'est pas en exécution. Le début du script relancera Odoo mais, à la fin, il ne l'arrêtera pas.
Tâche cron
On va créer une tâche cron qui s'exécutera quotidiennement à 02h00 car, la sauvegarde régulière du Serveur SME est programmée pour rouler à 03h00 et nous voulons y inclure la sauvegarde de PostgreSQL.
On crée le répertoire pour le gabarit personnalisé.
# mkdir -p /etc/e-smith/templates-custom/etc/crontab
On crée le fichier de la tâche cron et on y insère son contenu.
La tâche s'exécutera quotidiennement à 02h00. L'heure peut être choisie à votre entière discrétion.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql <<'EOT' SHELL=/bin/bash MAILTO=root # # Tâche cron qui lance /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh afin # de sauvegarder la BD d'Odoo-11. Cette tâche cron roulera quotidiennement à 02h00. # ┌───────────── min (0 - 59) # │ ┌────────────── heure (0 - 23) # │ │ ┌─────────────── jour du mois (1 - 31) # │ │ │ ┌──────────────── mois (1 - 12) # │ │ │ │ ┌───────────────── jour de la semaine (0 - 6) (0 à 6 sont de dimanche à samedi, # │ │ │ │ │ 7 est dimanche, même que 0) # │ │ │ │ │ # * * * * * [usager] commande à exécuter # 0 2 * * * root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh EOT
On sécurise le fichier.
# chmod 700 /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql
On développe le gabarit personnalisé.
# expand-template /etc/crontab
On redémarre le démon crond.
# service crond restart
Vérification de la tâche cron
On modifie l'heure de la tâche cron pour qu'elle soit lancée à toutes les minutes pour vérifier son exécution.
# sed -i 's/^0 2/\* \*/' /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql
On développe le gabarit personnalisé.
# expand-template /etc/crontab
On redémarre le démon crond.
# service crond restart
- Suivi
On lance la commande tail ci-dessous pour suivre toutes les tâches cron et on filtre avec grep celles qui contiendront sauvegarde.
# tail -F /var/log/messages | grep sauvegarde
À toutes les minutes, on verra notre tâche s'afficher.
... Jun 18 11:30:04 odoo-11 root: La sauvegarde de la BD odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip Jun 18 11:31:03 odoo-11 root: La sauvegarde de la BD odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip Jun 18 11:32:03 odoo-11 root: La sauvegarde de la BD odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip ...
On arrête la commande tail avec [CTL - c].
- Vérification lorsque le démon Odoo est arrêté
On arrête Odoo.
# /etc/rc.d/init.d/odoo stop
On relance la commande tail.
# tail -F /var/log/messages | grep sauvegarde
À toutes les minutes, on verra notre tâche s'afficher.
...
Jun 18 11:40:04 odoo-11 root: La sauvegarde de la BD Odoo-11 est dans: /var/lib/pgsql/sauvegarde/odoo-11.zip
...
On arrête la commande tail avec [CTL - c].
On remet l'heure de la tâche cron à 02h00.
# sed -i 's/\* \* \* \* \* root/0 2 \* \* \* root/' /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql
On développe le gabarit personnalisé.
# expand-template /etc/crontab
On redémarre le démon crond.
# service crond restart
- Courriel de notification
À la fin de la tâche cron, l'utilisateur root (admin) recevra un courriel, semblable à celui ci-dessous.
On se rend à l'URL: https://192.168.1.11/webmail. On se logue obligatoirement avec l'usager admin et le mot de passe de root.
 |
 |
Restauration
Choix du fichier de sauvegarde
/var/lib/pgsql/sauvegarde/odoo-11.zip
- Restauration manuelle:
- On supprime la BD actuelle d'Odoo selon le paragraphe #Suppression de la base de données actuelle et on restaure manuellement selon le paragraphe #Restauration manuelle.
- Restauration graphique avec Odoo:
- On copie le fichier /var/lib/pgsql/sauvegarde/odoo-11.zip sur le poste de travail et on restaure la BD odoo-11.zip selon le paragraphe #Restauration graphique.
odoo-11.zip inclus dans une sauvegarde régulière du Serveur SME
- On récupère le fichier odoo-11.zip selon le paragraphe #Récupération du fichier odoo-11.zip de la sauvegarde SME puis, on restaure manuellement ou graphiquement.
Sauvegarde/restauration avec l'interface d'Odoo
On peut faire une sauvegarde/restauration de PostgreSQL directement avec l'interface d'Odoo.
Sauvegarde graphique
| - On se déconnecte.
- On supprime l'historique du navigateur. - Manage Databases. |
Backup. |
 |
 |
| - La base de donnée odoo-11 est déjà affichée.
- On entre le mot de passe du super-utilisateur postgres. - On sélectionne zip (include filestore) > Backup. |
Enregistrer le fichier > OK. |
 |
 |
| Enregistrer. |
 |
Restauration graphique
Pour pouvoir restaurer une BD, il faut supprimer l'ancienne.
| - http://192.168.1.11:8069.
- Manage Databases. |
Delete. |
 |
 |
| - On entre le mot de passe du super-utilisateur postgres.
- La base de donnée odoo-11 est déjà affichée. - Delete. |
- Au retour, vu qu'il n'y a plus de BD, Odoo présente l'écran de création de la base de données.
- On clique: or restore a database. |
 |
 |
| On entre le mot de passe du super-utilisateur postgres > Parcourir... | On sélectionne la BD à restaurer > Ouvrir. |
 |
 |
| On entre le nom de la BD > Continue. | La BD est restaurée. |
 |
 |
Vérification
On se logue dans Odoo et on vérifie si tout est tel qu'au moment de la sauvegarde. http://192.168.1.11:8069
Journal Odoo
On vérifie le journal d'Odoo.
| Server Manager > Visualisation des fichiers journaux >
odoo/odoo-server.log > Suivant. |
Tout fonctionne correctement. |
 |
 |
On réamorce le Serveur SME pour une vérification finale.
# reboot
On réexamine le fichier journal et on s'aperçoit que quelque chose cloche:
... 2018-06-18 19:49:29,567 3043 INFO ? odoo.addons.sms.wizard.send_sms: The `phonenumbers` Python module is not available. Phone number validation will be skipped. Try `pip3 install phonenumbers` to install it. ...
On va installer le module manquant.
Il faut absolument l'installer en tant qu'usager root.
# whoami
root
On se rend dans le répertoire racine d'Odoo.
# cd /home/e-smith/files/ibays/Primary/html/odoo/
On installe phonenumbers en utilisant obligatoirement l'utilitaire pip de la Collection RH-Python36.
# /opt/rh/rh-python36/root/usr/bin/pip install phonenumbers Collecting phonenumbers Downloading https://files.pythonhosted.org/packages/a0/f2/986647e374a474cf821c50a0a70129236b32510452e87d26061e26c4893e/phonenumbers-8.9.8-py2.py3-none-any.whl (3.1MB) 100% |████████████████████████████████| 3.1MB 290kB/s Installing collected packages: phonenumbers Successfully installed phonenumbers-8.9.8 You are using pip version 9.0.1, however version 10.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command.
Ajustement de tous les droits du répertoire d'Odoo
Après une installation quelconque, on s'assure que le propriétaire et le groupe sont odoo:odoo en changeant Récursivement le propriétaire et le groupe dans tout le répertoire d'Odoo.
# chown -R odoo:odoo /home/e-smith/files/ibays/Primary/html/odoo
On enlève Récursivement tous les droits que pourrait avoir "other" dans tout le répertoire d'Odoo.
# chmod -R o-rwx /home/e-smith/files/ibays/Primary/html/odoo
Réamorçage
On réamorce le Serveur SME pour s'assurer que le module manquant a bien été installé correctement.
On réamorce avec la signalisation post-upgrade pour être certain que nous n'avons rien oublié.
# signal-event post-upgrade ; signal-event reboot
Après le réamorçage, on vérifie le journal d'Odoo.
# cat /var/log/odoo/odoo-server.log | grep phonenumbers 2018-06-18 19:49:29,567 3043 INFO ? odoo.addons.sms.wizard.send_sms: The `phonenumbers` Python module is not available. Phone number validation will be skipped. Try `pip3 install phonenumbers` to install it.
L'entrée est la même que celle affichée précédemment et exactement à la même heure. On peut donc être certain que cette information est la précédente.
Il n'y a pas eu de nouvelle lignes INFO et on peut affirmer que le problème a bien été résolu.
Répertoires et fichiers spéciaux à sauvegarder
Référence: https://wiki.contribs.org/Backup_with_dar#Adding.2FExcluding_Directories_and_Files_from_the_backup_list.
Les sous-répertoires de /etc ne sont pas tous inclus dans la sauvegarde standard du Serveur SME. Il en est de même pour les répertoires /opt et /var/lib/pgsql/.
Répertoires et fichiers à inclure dans la sauvegarde
Nous allons créer un gabarit personnalisé pour ajouter, dans la sauvegarde standard du Serveur SME, certains répertoires et fichiers particuliers.
Répertoires
- /opt - répertoires des collections.
- /var/run/odoo - pour le répertoire PIDFILE.
- /var/log/odoo - pour les fichiers journaux.
- /var/lib/pgsql/sauvegarde - le répertoire de sauvegarde PostgreSQL.
- /etc/dehydrated - le répertoire des certificats Let's Encrypt (si utilisé).
Fichiers
- /var/lib/pgsql/10/data/pg_hba.conf - fichier de configuration de PostgreSQL.
- /etc/rc.d/init.d/postgresql-10 - fichier de départ/arrêt automatique de PostgreSQL.
- /etc/rc.d/rc7.d/S51postgresql-10 - lien de départ de PostgreSQL.
- /etc/rc.d/rc6.d/K36postgresql-10 - lien d'arrêt de PostgreSQL.
- /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql - script de sauvegarde de PostgreSQL.
- /etc/odoo-server.conf - la configuration du démon Odoo.
- /etc/rc.d/init.d/odoo - fichier de départ/arrêt automatique d'Odoo.
- /etc/logrotate.d/odoo-server - fichier de rotation des journaux d'Odoo.
Création d'un gabarit personnalisé
# mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf
On sécurise.
# chmod 600 /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf
On crée le fichier 41go-into et on y insère le contenu de l'encadré ci-dessous pour indiquer d'inclure les fichiers et répertoires désirés.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into <<'EOT'
#
# Indique au Serveur SME d'inclure les fichiers et
# répertoires/sous-répertoires dans la sauvegarde standard.
# Répertoires
--go-into opt
--go-into var/run/odoo
--go-into var/log/odoo
--go-into var/lib/pgsql/sauvegarde
# Décommenter si un certificat Let's Encrypt est utilisé par le Serveur SME.
# --go-into etc/dehydrated
# Fichiers
--go-into var/lib/pgsql/10/data/pg_hba.conf
--go-into etc/rc.d/init.d/postgresql-10
--go-into etc/rc.d/rc7.d/S51postgresql-10
--go-into etc/rc.d/rc6.d/K36postgresql-10
--go-into etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql
--go-into etc/odoo-server.conf
--go-into etc/rc.d/init.d/odoo
--go-into etc/logrotate.d/odoo-server
EOT
Il n'y a pas de caractère "/" au début des chemins des fichiers et répertoires.
Contrairement à ce qui est décrit dans la Contrib, il faut aussi utiliser --go-into pour les fichiers.
On développe le gabarit personnalisé.
# expand-template /etc/dar/DailyBackup.dcf
Si le fichier pg_hba.conf a bien été incorporé dans DailyBackup.dcf, les autres l'ont été aussi.
# cat /etc/dar/DailyBackup.dcf | grep pg_hba.conf
--go-into var/lib/pgsql/10/data/pg_hba.conf
Lancement de la sauvegarde
- On peut générer une sauvegarde régulière du Serveur SME qui serait lancée dans quelques minutes.
- Autrement, on peut utiliser la commande ci-dessous pour en lancer une immédiatement.
Il faut que les sauvegardes soient activées pour utiliser cette commande.
# /sbin/e-smith/do_backupwk
Ci-dessus, l'invite ne revient pas. Elle le fera seulement après la fin de do_backupwk.
Avec une autre session PuTTY, on peut vérifier si la sauvegarde est en exécution.
# ps aux | grep dar
root 2733 0.3 0.3 173544 12536 pts/0 S+ 15:13 0:00 /usr/bin/perl -w /etc/e-smith/events/actions/workstation-backup-dar DailyBackup
root 2767 63.0 0.8 163512 35316 pts/0 RL+ 15:13 0:20 /usr/bin/dar -Q -asecu --create /mnt/smb/odoo-11.micronator-101.org/full-20180618151337 -B /etc/dar/DailyBackup.dcf
root 2768 0.0 0.2 173544 10448 ? Ss 15:13 0:00 /usr/bin/perl -w /etc/e-smith/events/actions/workstation-backup-dar DailyBackup
root 2790 0.0 0.0 103340 884 pts/1 S+ 15:14 0:00 grep dar
Si on veut utiliser la même connexion et retrouver l'invite tout de suite après le lancement de la commande, on ajoute le caractère "&" (sans guillemets) à la fin de la ligne de commande pour une exécution en arrière-plan.
| # /sbin/e-smith/do_backupwk & |
On peut suivre la sauvegarde en utilisant l'utilitaire top.
# top -d 1
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2768 root 20 0 130m 5480 2124 R 90.3 0.1 0:02.35 dar 1 root 20 0 19352 1536 1228 S 0.0 0.0 0:00.87 init |
Comme on le voit, DAR est très énergivore de temps CPU.
Après la sauvegarde, DAR met à jour le catalogue des sauvegardes.
# ps aux | grep dar_manager root 2797 91.6 1.1 173856 45292 pts/0 RL+ 15:18 0:11 /usr/bin/dar_manager -Q -B /mnt/smb/odoo-11.micronator-101.org/dar-catalog -D 1 root 2803 0.0 0.0 103344 888 pts/2 S+ 15:18 0:00 grep dar_manager
Vérification
On vérifie le répertoire Sauvegarde sur le poste de travail.
- DAR a créé le répertoire
odoo-11.micronator-101.orgdans ce répertoire. - On examine le répertoire
D:\Sauvegarde\odoo-11.micronator-101.org\. - On examine son sous-répertoire
set1.
 |
 |
 |
Récupération manuelle de la sauvegarde PostgreSQL
Voir plus haut pour le Script de sauvegarde PostgreSQL de la base de données odoo-11.
On va récupérer le fichier odoo-11.zip de la sauvegarde standard du Serveur SME.
Préparation
À la console du serveur, on se rend dans le répertoire de sauvegarde de la base de données odoo-11.
# cd /var/lib/pgsql/sauvegarde
On affiche le contenu.
# ls -ls
total 3648
3644 -rwx------ 1 root root 3730924 18 juin 11:33 odoo-11.zip
4 -rwx------ 1 root root 2308 18 juin 11:17 sauvegarde-postgres.sh
On renomme la sauvegarde actuelle pour pouvoir la conserver et la comparer avec celle récupérée.
# mv odoo-11.zip odoo-11.zip-org
Récupération du fichier odoo-11.zip de la sauvegarde SME
On se logue dans le gestionnaire du Serveur SME avec l'usager admin et le mot de passe de root. https://192.168.1.11/server-manager
- Sauvegarde et restauration > Restauration sélective de fichier depuis un ordinateur distant > Exécuter.
- On choisit la sauvegarde, on entre le nom du fichier à récupérer (odoo-11.zip) > Exécuter.
- On sélectionne le fichier à récupérer (var/lib/pgsql/sauvegarde/odoo-11.zip) > Exécuter.
- Le fichier contenu dans la sauvegarde habituelle du Serveur SME a été récupéré et déposé à son emplacement original.
 |
 |
 |
 |
On vérifie.
# ls -ls total 7292 3644 -rwx------ 1 root root 3730924 18 juin 11:33 odoo-11.zip 3644 -rwx------ 1 root root 3730924 18 juin 11:33 odoo-11.zip-org 4 -rwx------ 1 root root 2308 18 juin 11:17 sauvegarde-postgres.sh
Le fichier récupéré est exactement le même que l'original avec les mêmes: propriétaire, groupe, grandeur et heure.
On ajoute le droit de lecture au fichier de la sauvegarde récupérée pour que l'usager postgres puisse le lire et replacer la sauvegarde dans la base de données de PostgreSQL.
# chmod +r odoo-11.zip
Suppression de la base de données actuelle
On vérifie si le démon Odoo est en cours d'exécution.
# /etc/rc.d/init.d/odoo status
odoo-server est en cours d'exécution...
On arrête Odoo.
# /etc/rc.d/init.d/odoo stop
On se substitue à l'usager postgres.
# su - postgres
On supprime la BD actuelle d'Odoo (ne pas oublier les apostrophes).
$ dropdb 'odoo-11'
On entre dans la console de PostgreSQL pour vérifier la suppression de la BD.
$ psql
On affiche les BD présentes.
# \list
Liste des bases de données
Nom | Propriétaire | Encodage | Collationnement | Type caract. | Droits d'accès
----------+--------------+----------+-----------------+--------------+----------------------
postgres | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 |
template0 | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(3 lignes)
La base de données odoo-11 n'est plus présente, elle a bien été supprimée.
On quitte la console PostgreSQL.
# \q
On revient à l'usager root.
$ exit
On relance Odoo pour pouvoir ré-insérer la base de données originale.
# /etc/rc.d/init.d/odoo start
Restauration manuelle
Référence: https://linuxize.com/post/how-to-setup-automatic-odoo-backup/.
On lance la restauration.
Prende tout le contenu de l'ancadré pour la commande.
curl -F 'master_pwd=fghtbgh' \ -F backup_file=@/var/lib/pgsql/sauvegarde/odoo-11.zip \ -F 'copy=true' \ -F 'name=odoo-11' \ http://localhost:8069/web/database/restore
Vérification
On se logue dans Odoo et on vérifie si tout est tel qu'avant la sauvegarde. http://192.168.1.11:8069
Mises à jour
Odoo
- Nous avons utilisé
gitpour l'installation d'Odoo-11, il peut donc aussi servir pour la mise à jour du coeur d'Odoo et de ses extensions.
- Après une mise à jour d'Odoo, on met à jour la base de données d'Odoo afin d'utiliser le code le plus récent.
Voir: https://www.odoo.yenthevg.com/update-odoo-environment-github/.
Mise à jour d'Odoo et de ses extensions.
Vous devez faire la mise à jour en tant qu'utilisateur odoo.
On se substitue à l'utilisateur odoo.
# su - odoo
On se rend dans le répertoire .../Primary/html/odoo.
# cd /home/e-smith/files/ibays/Primary/html/odoo
Maintenant que nous sommes dans le bon dossier, on doit récupérer le contenu de Github pour, plus tard, l'appliquer localement.
On récupère le contenu de Github.
# git fetch origin 11.0 remote: Counting objects: 217, done. remote: Compressing objects: 100% (72/72), done. remote: Total 217 (delta 178), reused 183 (delta 145), pack-reused 0 Receiving objects: 100% (217/217), 26.85 KiB, done. Resolving deltas: 100% (178/178), completed with 121 local objects. From https://github.com/odoo/odoo * branch 11.0 -> FETCH_HEAD
Application des mises à jour
Nous avons maintenant tout récupéré et nous devons demander au système d'appliquer les mises à jour. À ce stade, le système sait quelles modifications qui doivent être effectuées mais, nous ne les avons pas encore appliquées; nous pouvons le faire avec git reset.
La commande git reset –hard appliquera toutes les modifications, peu importe ce qui pourrait arriver.
Si vous avez ajouté du code personnalisé dans des modules déjà existants (donc dans le code source et non dans un module autonome), vous ne devez pas l'utiliser cette commande car, votre code personnalisé sera écrasé! Ajouté du code personnalisé dans des modules originaux est contraire à toutes les règles. Si vous devez ajouter du code, commencez par créer vos propres modules au lieu de modifier le code source.
On applique les mises à jour.
$ git reset --hard origin/11.0
Checking out files: 100% (22400/22400), done.
HEAD is now at a8469c4 [FIX] tools: handle code in po
On peut voir qu'un bogue a été résolu [FIX].
Le code Odoo est maintenant à jour et a été synchronisé avec les derniers changements apportés.
Mise à jour de la BD
On redevient l'usager root.
$ exit
On met à jour la base de données afin qu'elle reconnaisse toutes les modifications et se les applique à elle-même.
Paramètres de la commande:
- /etc/rc.d/init.d/odoo restart: indique au système de redémarrer le démon Odoo.
- -u all: indique à Odoo de mettre à jour toutes (all) les extensions.
- -d NomDeLaBD: indique à Odoo d'appliquer les changements sur la base de données nommée NomDeLaBD. Pour le nom de la BD, voir Création d'une nouvelle base de données
# /etc/rc.d/init.d/odoo restart -u all -d odoo-11 Arrêt de Odoo Server Daemon (odoo-server) : [ OK ] Démarrage de Odoo Server Daemon (odoo-server) : [ OK ]
Pour une explication des paramètres de la commande odoo, voir: https://www.odoo.com/documentation/11.0/reference/cmdline.html.
On vérifie le statut du démon.
# /etc/init.d/odoo status
odoo-server est en cours d'exécution...
Vérification du site Odoo
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
Odoo-11 et ses extensions sont à jour.
PostgreSQL
Mise à jour de PostgreSQL.
# yum update -y --enablerepo=pgdg10 postgresql10 postgresql10-libs \ postgresql10-server postgresql10-contrib \ postgresql10-devel postgresql10-docs postgresql10-test Modules complémentaires chargés : fastestmirror, smeserver Configuration du processus de mise à jour Loading mirror speeds from cached hostfile * base: mirror.csclub.uwaterloo.ca * smeaddons: mirror.canada.pialasse.com * smeextras: mirror.canada.pialasse.com * smeos: mirror.canada.pialasse.com * smeupdates: mirror.canada.pialasse.com * updates: mirror.netflash.net pgdg10 | 4.1 kB 00:00 Aucun paquet marqué pour mise à jour
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
RH-Python36
Mise à jour de la Collection RH-Python36.
# yum update -y --enablerepo=centos-sclo-rh rh-python36*
Modules complémentaires chargés : fastestmirror, smeserver
Configuration du processus de mise à jour
Loading mirror speeds from cached hostfile
* base: centos.mirror.netelligent.ca
* smeaddons: mirror.canada.pialasse.com
* smeextras: mirror.canada.pialasse.com
* smeos: mirror.canada.pialasse.com
* smeupdates: mirror.canada.pialasse.com
* updates: centos.mirror.netelligent.ca
Aucun paquet marqué pour mise à jour
Vérification du site Odoo
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
npm/node
Référence: https://fr.wikipedia.org/wiki/Npm.
L'utilitaire npm est le gestionnaire officiel des paquets de Node.js.
Depuis la version 0.6.3 de Node.js:
- npm fait partie de l'environnement et est donc automatiquement installé par défaut.
- npm fonctionne avec un terminal et gère les dépendances pour une application.
- npm permet également d'installer des applications Node.js disponibles dans le dépôt npm.
Impacts sur less et lessc
Lors de l'installation initiale d'Odoo-11, il ne faut pas installer la dernière version car, elle générera une erreur de style dûe à l'utilitaire lssc qui ne sera pas reconnue.
| Style error
The style compilation failed, see the error below. Your recent actions may be the cause, please try reverting the changes you made. |
Odoo n'est pas renommé pour sa compatibilité avec les versions les plus récentes des logiciels prérequis.
Il est plus que fortement recommandé de toujours utiliser un système de développement pour vérifier les mises à jours du code Odoo et surtout pour les logiciels prérequis.
Vous pouvez consulter le document suivant pour la création d'un clone d'un Serveur SME: https://www.micronator.org/affaires/produit/micronator-101-supplementsme-backuppc/
On vérifie la version actuelle.
# npm --version
6.1.0
Mise à jour
Mise à jour de npm/node.
# npm install -g npm
/usr/bin/npm -> /usr/lib/node_modules/npm/bin/npm-cli.js
/usr/bin/npx -> /usr/lib/node_modules/npm/bin/npx-cli.js
+ npm@6.4.1
added 8 packages from 4 contributors, removed 35 packages and updated 38 packages in 15.024s
On vérifie la nouvelle version de npm.
# npm --version
6.4.1
Vérification du site Odoo
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
Retour à la version originalement installée
Au cas où la nouvelle version occasionnerait des problèmes, on peut retourner à la version originalement installée.
# npm install -g npm@6.1.0
/usr/bin/npm -> /usr/lib/node_modules/npm/bin/npm-cli.js
/usr/bin/npx -> /usr/lib/node_modules/npm/bin/npx-cli.js
+ npm@6.1.0
added 551 packages from 158 contributors, removed 256 packages and updated 23 packages in 21.123s
On vérifie.
npm --version
6.1.0
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
less et less-plugin-clean-css
Pour éviter les erreurs de certificats SSL et de téléchargement.
# npm config set strict-ssl false
Mise à jour de less et de less-plugin-clean-css.
# npm install -g less less-plugin-clean-css
/usr/bin/lessc -> /usr/lib/node_modules/less/bin/lessc
+ less@3.8.1
+ less-plugin-clean-css@1.5.1
updated 2 packages in 4.086s
Vérification du site Odoo
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
wkhtmltox
Si ce n'est déjà fait, on crée un répertoire de travail.
# mkdir /temp
On s'y rend.
# cd /temp/
On nettoie le répertoire /temp en supprimant tout ce qui pourrait s'y trouver.
# rm -rf *
Dépendances pour wkhtmltopdf
Mise à jour des dépendances.
# yum update -y fontconfig libpng libX11 libXext libXrender xorg-x11-fonts-Type1 xorg-x11-fonts-75dpi
Modules complémentaires chargés : fastestmirror, smeserver
Configuration du processus de mise à jour
Loading mirror speeds from cached hostfile
* base: centos.mirror.ca.planethoster.net
* smeaddons: mirror.canada.pialasse.com
* smeextras: mirror.canada.pialasse.com
* smeos: mirror.canada.pialasse.com
* smeupdates: mirror.canada.pialasse.com
* updates: centos.mirror.vexxhost.com
Aucun paquet marqué pour mise à jour
S'il existe des mises à jour, elles s'afficheront ici et seront installées.
wkhtmltox
Pour trouver la dernière version de wkhtmltopdf on se rend à l'URL: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/.
En commençant avec la version 0.12.5, on peut utiliser un RPM pour la mise à jour de wkhtmltox. Sous la dernière version, on claque (clic droit) sur le fichier ...centos6.x86_64.rpm > Copier l'adresse du lien.
Présentement pour nous, c'est la version 0.12.5 et le lien est: http://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox-0.12.5-1.centos6.x86_64.rpm
Dans le répertoire de travail, on entre rpm -Uvh suivi d'un espace puis, on colle le lien copié ci-dessus.
# rpm -Uvh https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox-0.12.5-1.centos6.x86_64.rpm Récupération de https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox-0.12.5-1.centos6.x86_64.rpm Préparation... ########################################### [100%] 1:wkhtmltox ########################################### [100%]
On vérifie les exécutables et leur version.
# which wkhtmltopdf
/usr/local/bin/wkhtmltopdf
# wkhtmltopdf --version
wkhtmltopdf 0.12.5 (with patched qt)
# which wkhtmltoimage
/usr/local/bin/wkhtmltoimage
# wkhtmltoimage --version
wkhtmltoimage 0.12.5 (with patched qt)
Vérification du site Odoo
On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se rend à notre site et on s'assure que tout fonctionne correctement: http://192.168.1.11.
Signalisation des changements
On peut signaler les changements tout de suite ou attendre après la mise à jour du Serveur SME.
S'il n'y a pas de mises à jour pour le Serveur SME, il faudra obligatoirement signaler les changements précédents.
Si on a fait quelques changements, on les signale avec les commandes traditionnelles.
Peut prendre un certain temps, être patient!
# signal-event post-upgrade; signal-event reboot
Désintallation d'Odoo
Vu que le Serveur SME ne sert uniquement qu'à rouler Odoo, il n'y a pas de désinstallation.
Suite de cette marche à suivre
La marche à suivre https://wiki.contribs.org/Odoo-11_%26_HTTPS est la suite de celle-ci et décrit l'installation d'un certificat Let's Encrypt et les étapes pour assurer une connexion sécuritaire SSL/TLS à Odoo-11 roulant sur un Serveur SME.
Mot de la fin
Une fois que vous maîtrisez tous les aspects de: Fail2ban, Let's Encrypt, Odoo, BackupPC et VirtualBox, vous pouvez créer un réseau de Production incluant un serveur Odoo, un serveur de sauvegardes et un serveur de développement; ce qui est le but ultime que nous vous souhaitons!
Victoire totale, hissons la bannière de la victoire.