Vérification

Centre Réseau et partage → Modifier les paramètres de la carte → clac (clic droit) sur la carte Éthernet → Statut → Détails.

● Nos deux adresses IP et nos deux passerelles son présentes.

● Fermer toutes les fenêtre.

C:\Windows\System32\drivers\etc\hosts.

Les CNAME de notre Serveur NethServer virtuel LOCAL sont présents.

- Sur le poste de travail, ouvrir un écran de commandes.
- ifconfig /flushdns.

Historique → Supprimer l'historique ré­cent… → tout → Effacer maintenant.

UploadMaxFilesize

Certains ajouts doivent 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.

Version PHP par défaut

On définit la version PHP par défaut pour Apache.

Configuration → Paramètres PHP → onglet Version PHP Apache → cliquer Php72 SCL Version → SOUMETTRE.

Ajustements des paramètres de la version PHP-7.2

Onglet Php V7.2 SCL
Ajuster tel que ci-contre (250M - 100M - 75M)
→ SOUMETTRE.

Allow PHP access to remote files est un bris de sécurité.

Onglet Version par défaut de PHP
Ajuster tel que ci-contre (250M - 75M - 75M)
→ SOUMETTRE.

Autoriser l'accès PHP aux fichiers distants est un bris de sécurité.

Lien du référentiel PostgreSQL

Pour connaître le lien URL du référentiel PostgreSQL, on se rends au site suivant: https://yum.postgresql.org/repopackages.php#pg11

Le référentiel EPEL (Extra Packages pour Enterprise Linux) est présent et Activé par défaut sur un Server NethServer.

Notre Serveur NethServer est un 64 bits issu de CentOS-7.6. Donc, nous choisissons CentOS 7 - x86 64.

On claque (clic droit) sur CentOS 7 - x86 64 et on copie l'a­dres­se du lien.

Le lien du référentiel PostgreSQL pour notre serveur est:
https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

À l'URL: http://mirror.centos.org/centos/7/sclo/x86_64/rh/, la dernière version disponible pour CentOS-7.6, donc pour NethServer-7.6.18101, est rh-python36.

Les versions disponibles se trouvent à l'URL: https://nodejs.org/download/release/.

À l'aide d'un navigateur Internet, on se rend à l'Url:
https://github.com/wkhtmltopdf/wkhtmltopdf/releases/.

On claque (clic droit) sur le fichier:
wkhtmltox-0.12.5-1.centos7.x86_64.rpm

Copier l'a­dresse du lien.

Le lien copié est: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox-0.12.5-1.centos7.x86_64.rpm

Si nous n'avons aucun site Web et que nous spécifions seulement http://www.micronator-dev.org/ ou http://10.10.10.75 sans spécifier le port 8069, nous verrions s'afficher le contenu du site Web par défaut du Serveur NethServer.

Avant d'installer un certificat Let's Encrypt selon la section Certificat pour un domaine LOCAL du Cahier-04 : NethServer LOCAL & Certificat Let's Encrypt du “Cours NethServer-101”, il faut ajouter les CNAME odoo, www.odoo, et mail.odoo chez https://www.cloudflare.com/.

- On entre le informations demandées.
- SOUMETTRE

On vérifie le résultat.

- Le cadenas est vert.
- On clique l'icône >.

Plus d'informations.

- Onglet Sécurité.
- Afficher le certificat.

- Onglet Général.
- Émis pour micronator-dev.org (le premier domai­ne de la liste, lors de la demande).
- Émis par Let's Encrypt Authority X3.

- Onglet Détails.
- Nom alternatif du sujet du certificat.
- Tous les CNAME sont présents.
- Fermer toutes les fenêtres.

APPLIQUER LES CHAN­GE­MENTS.

Recharger la page.

Le nouveau menu Proxy inverse est disponible.

On configure le Serveur NethServer en tant que mandataire inversé pour www.odoo.micronator-dev.org//. Passerelle → Proxy inverse → onglet Hôtes virtuels → CRÉER NOUVEAU. On entre les informations demandées. → SOUMETTRE. </WRAP>

On vérifie le résultat.

===== Vérification de la connexion redirigée et sécurisée ===== On vidange l'historique de notre navigateur et le cache DNS du poste de travail, puis on s'assure que java script et les témoins soient activés. On se rend à l'URL https://www.odoo.micronator-dev.org, on ajoute une exception pour le nouveau certificat. Si on utilise seulement le protocole http://..., il sera transformé en https://..., car lors de la configuration à l'onglet Hôtes virtuels, nous avons coché: ☑ Nécessite une connexion SSL chiffrée.

- Le cadenas est vert.
- On se connecte.

La page d'accueil d'Odoo s'affiche et le cadenas est toujours vert.

Le cadenas est toujours vert, car le certificat a été émis par Let's Encrypt qui est une autorité de certification reconnue et la connexion est sécurisée par un chiffrement TLS/SSL.
===== Messagerie électronique ===== On configure la messagerie électronique pour le domaine odoo.micronator-dev.org.

- Configuration → Messagerie électronique → onglet Domaines.
- CRÉER NOUVEAU.

- On entre les informations demandées.
- SOUMETTRE.

On vérifie le résultat.

Pour accéder à Webmail de ce domaine,
https://mail.odoo.micronator-dev.org/webmail/.

Le nom du serveur n'apparaît pas dans l'écran au-dessus de Connexion car nous l'avons enlevé. Pour plus de détails, voir dans le Cahier-03 du “Cours NethServer-101, la section:

Nom du serveur dans l'écran de connexion à Webmail

Instantané VirtualBox

À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

====== Odoo-12 - Post-scriptum ====== ===== Vérification du démarrages des services ===== ==== PostgreSQL ==== On vérifie son statut. <file> [root@tchana ~]# systemctl status postgresql-11 ● postgresql-11.service - PostgreSQL 11 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-11.service; enabled; vendor preset: disabled) Active: active (running) since sam. 2019-05-18 11:16:10 EDT; 5h 31min ago Docs: https://www.postgresql.org/docs/11/static/ Main PID: 3391 (postmaster) CGroup: /system.slice/postgresql-11.service ├─ 3391 /usr/pgsql-11/bin/postmaster -D /var/lib/pgsql/11/data/ ├─ 3882 postgres: logger ├─ 4688 postgres: checkpointer ├─ 4689 postgres: background writer ├─ 4690 postgres: walwriter ├─ 4691 postgres: autovacuum launcher ├─ 4692 postgres: stats collector ├─ 4693 postgres: logical replication launcher ├─11376 postgres: odoo Odoo-12 127.0.0.1(52196) idle ├─11385 postgres: odoo Odoo-12 127.0.0.1(52208) idle ├─11388 postgres: odoo Odoo-12 127.0.0.1(52214) idle └─11389 postgres: odoo Odoo-12 127.0.0.1(52216) idle mai 18 11:15:31 tchana.micronator-dev.org systemd[1]: Starting PostgreSQL 11 database se…. mai 18 11:15:43 tchana.micronator-dev.org postmaster[3391]: 2019-05-18 11:15:43.272 EDT …432 mai 18 11:15:43 tchana.micronator-dev.org postmaster[3391]: 2019-05-18 11:15:43.764 EDT …2 » mai 18 11:15:45 tchana.micronator-dev.org postmaster[3391]: 2019-05-18 11:15:45.430 EDT …2 » mai 18 11:15:46 tchana.micronator-dev.org postmaster[3391]: 2019-05-18 11:15:46.892 EDT …ces mai 18 11:15:46 tchana.micronator-dev.org postmaster[3391]: 2019-05-18 11:15:46.892 EDT … ». mai 18 11:16:10 tchana.micronator-dev.org systemd[1]: Started PostgreSQL 11 database server. Hint: Some lines were ellipsized, use -l to show in full. [root@tchana ~]# </file> ==== Odoo ==== On vérifie son statut. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since sam. 2019-05-18 11:16:10 EDT; 5h 33min ago Main PID: 4694 (scl) CGroup: /system.slice/odoo12.service ├─4694 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /o… ├─4697 /bin/bash /var/tmp/sclX2bC8i └─4700 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/odo… mai 18 11:16:10 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> ===== Administration d'Odoo ===== Pour administrer Odoo, il suffit de se connecter avec le justificatif choisi lors de la Finalisation de l'installation.
● On se rend à: https://www.odoo.micronator-dev.org.
● On peut aussi utiliser http://www.odoo.micronator-dev.org qui sera transformé en https…

- Le cadenas est vert.
- On se connecte.

La page d'accueil d'Odoo s'affiche et le cadenas est toujours vert.

===== Fichiers journaux ===== ==== PostgreSQL ==== Le fichier du journal de PostgreSQL se trouve dans le répertoire /var/lib/pgsql/11/data/log/. ==== Odoo ==== Afin de vous assurer que tout ait démarré correctement, on consulte les journaux. ● À l'aide de l'interface Web: Administration → Logs → /var/log/odoo/odoo-server.log.
● Directement dans les fichiers /var/log/messages et /var/log/odoo/odoo-server.log. ==== Fichier /var/log/odoo/odoo-server.log ==== On peut aussi utiliser la console du serveur pour vérifier le journal d'Odoo afin de s'assurer qu'il n'existe pas de modules manquants. <file> [root@tchana ~]# cat /var/log/odoo/odoo-server.log | grep “module is not available” 2019-05-29 17:04:13,742 4077 INFO Odoo-12 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. [root@tchana ~]# </file> On voit que le module phonenumbers n'est pas disponible. === Installation du module manquant === On se substitue à l'utilisateur odoo. <file> [root@tchana ~]# su - odoo Dernière connexion : mercredi 22 mai 2019 à 00:12:34 EDT sur pts/1 [odoo@tchana ~]$ </file> On active Python36. <file> [odoo@tchana ~]$ scl enable rh-python36 bash [odoo@tchana ~]$ </file> On s'assure que nous sommes dans le répertoire personnel de l'utilisateur odoo. <file> [odoo@tchana ~]$ pwd /opt/odoo [odoo@tchana ~]$ </file> On active l'environnement virtuel odoo12-venv. <file> [odoo@tchana ~]$ source odoo12-venv/bin/activate (odoo12-venv) [odoo@tchana ~]$ </file> On installe le module phonenumbers. <file> (odoo12-venv) [odoo@tchana ~]$ pip3 install phonenumbers Collecting phonenumbers Downloading https://files.pythonhosted.org/packages/00/13/118a79e417f06a23473d28de65db95f3a14a4548cf39cdf407f8ffb335a1/phonenumbers-8.10.12-py2.py3-none-any.whl (2.6MB) 100% |████████████████████████████████| 2.6MB 359kB/s Installing collected packages: phonenumbers Successfully installed phonenumbers-8.10.12 You are using pip version 9.0.1, however version 19.1.1 is available. You should consider upgrading via the 'pip install –upgrade pip' command. (odoo12-venv) [odoo@tchana ~]$ </file> On désactive l'environnement virtuel et on quitte. <file> (odoo12-venv) [odoo@tchana ~]$ deactivate && exit exit [odoo@tchana ~]$ </file> On vérifie qui nous sommes. <file> [odoo@tchana ~]$ whoami odoo [odoo@tchana ~]$ </file> On quitte la substitution d'utilisateur. <file> [odoo@tchana ~]$ exit déconnexion [root@tchana ~]# </file> On vérifie qui nous sommes. <file> [root@tchana ~]# whoami root [root@tchana ~]# </file> Le module manquant a été installé. On redémarre Odoo. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> On vérifie le journal. <file> [root@tchana ~]# cat /var/log/odoo/odoo-server.log | grep “module is not available” 2019-05-29 17:04:13,742 4077 INFO Odoo-12 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. [root@tchana ~]# </file> Il n'existe aucune nouvelle entrée indiquant un module manquant. On vérifie pour des erreurs. <file> [root@tchana ~]# cat /var/log/odoo/odoo-server.log | grep -i error [root@tchana ~]# </file> On vérifie pour des avertissements. <file> [root@tchana ~]# cat /var/log/odoo/odoo-server.log | grep -i warning 2019-05-29 16:35:20,393 4055 WARNING Odoo-12 odoo.http: CSRF validation failed on path '/web/login' 2019-05-29 16:35:36,662 4055 WARNING Odoo-12 odoo.http: CSRF validation failed on path '/web/login' 2019-05-29 16:35:58,848 4055 WARNING Odoo-12 odoo.http: CSRF validation failed on path '/web/login' 2019-05-29 16:36:10,038 4055 WARNING Odoo-12 odoo.http: CSRF validation failed on path '/web/login' [root@tchana ~]# </file> On peut ignorer ces avertissements car il se produisent si vous laissez la page '/web/login' ouverte trop longtemps: le jeton a une durée de vie limitée. Par conséquent, si vous attendez trop longtemps, la connexion peut échouer. Si cela se produit, recharger la page.

===== Changements de mots de passe ===== ==== Utilisateur odoo de PostgreSQL ==== Vous pouvez trouver le mot de passe de l'utilisateur odoo de PostgreSQL (l'utilisateur qui gère votre base de données Odoo-12) dans le fichier de configuration /etc/odoo-server.conf. <file> [root@tchana ~]# cat /etc/odoo-server.conf | grep db_password db_password = fghtbgh [root@tchana ~]# </file> Si le mot de passe a été perdu ou piraté, on doit changer le mot de passe de l'utilisateur odoo de PostgreSQL: * à la console du Serveur NethServer,
* à la console de PostgreSQL et * dans le fichier /etc/odoo-server.conf. ==== À la console du Serveur NethServer ==== On change le mot de passe Linux de l'utilisateur odoo. <file> [root@tchana ~]# passwd odoo Changement de mot de passe pour l'utilisateur odoo. Nouveau mot de passe : nouveau-mot-de-passe-pour-odoo MOT DE PASSE INCORRECT : Le mot de passe comporte moins de 8 caractères Retapez le nouveau mot de passe : nouveau-mot-de-passe-pour-odoo passwd : mise à jour réussie de tous les jetons d'authentification. [root@tchana ~]# </file> L'avertissement “MOT DE PASSE INCORRECT : Le mot de passe comporte moins de 8 caractères” est normal dans notre cas, car nous utilisons le mot de passe du fameux Général Toto qui n'a que 7 caractères. Il ne faut pas prendre notre exemple pour un serveur en Production, mais un mot de passe robuste.
À la console du serveur, NethServer exige seulement une longueur minimum de 8 caractères pour le mot de passe. Dans l'interface Web, il n'exige que 7 caractères, mais le mot de passe doit contenir: au moins 1 chiffre, 1 caractère majuscule, 1 caractère minuscule, 1 caractère spécial, 5 caractères différents, ne pas être présent dans les dictionnaires de mots courants et être différent du nom d'utilisateur. De plus, il est impossible de répéter des motifs formés de 3 caractères ou plus (par exemple, le mot de passe As1.$AS1.$ n'est pas valide). ==== A la console de PostgreSQL ==== Il faut se substituer au super-utilisateur postgres, puis ce dernier change le mot de passe de l'utilisateur odoo de PostgreSQL. À la console du serveur, on se substitue à l'utilisateur postgres. <file> [root@tchana ~]# su - postgres -bash-4.2$ </file> On vérifie. <file> -bash-4.2$ whoami postgres -bash-4.2$ </file> L'utilisateur postgres entre dans la console PostgreSQL. <file> -bash-4.2$ psql psql (11.3)) Saisissez « help » pour l'aide. postgres=# </file> On change le mot de passe de l'utilisateur odoo de PostgreSQL. <file> postgres=# ALTER ROLE odoo WITH PASSWORD 'nouveau-mot-de-passe'; ALTER ROLE postgres=# </file> On quitte la console PostgreSQL. <file> postgres=# \q -bash-4.2$ </file> On retourne à l'utilisateur root. <file> -bash-4.2$ exit déconnexion [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# whoami root [root@tchana ~]# </file> ==== Dans le fichier /etc/odoo-server.conf ==== IMPORTANT. Le changement de mot de passe de l'utilisateur odoo dans PostgreSQL ne modifie pas celui dans le fichier /etc/odoo-server.conf. Il faut éditer ce fichier et changer le mot de passe sur la ligne: db_password = nouveau-mot-de-passe. On édite le fichier /etc/odoo-server.conf et on change le mot de passe de l'utilisateur odoo de PostgreSQL. On vérifie. <file> [root@tchana ~]# cat /etc/odoo-server.conf | grep db_password db_password = fghtbgh [root@tchana ~]# </file> ==== Redémarrage de PostgreSQL ==== On redémarre le service PostgreSQL. <file> [root@tchana ~]# systemctl restart postgresql-11 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status postgresql-11 ● postgresql-11.service - PostgreSQL 11 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-11.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 13:16:36 EDT; 49s ago Docs: https://www.postgresql.org/docs/11/static/ Process: 7994 ExecStartPre=/usr/pgsql-11/bin/postgresql-11-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 8000 (postmaster) CGroup: /system.slice/postgresql-11.service ├─8000 /usr/pgsql-11/bin/postmaster -D /var/lib/pgsql/11/data/ ├─8002 postgres: logger ├─8004 postgres: checkpointer ├─8005 postgres: background writer ├─8006 postgres: walwriter ├─8007 postgres: autovacuum launcher ├─8008 postgres: stats collector └─8009 postgres: logical replication launcher mai 19 13:16:36 tchana.micronator-dev.org systemd[1]: Stopped PostgreSQL 11 database server. mai 19 13:16:36 tchana.micronator-dev.org systemd[1]: Starting PostgreSQL 11 database se…. mai 19 13:16:36 tchana.micronator-dev.org postmaster[8000]: 2019-05-19 13:16:36.472 EDT …432 mai 19 13:16:36 tchana.micronator-dev.org postmaster[8000]: 2019-05-19 13:16:36.475 EDT …2 » mai 19 13:16:36 tchana.micronator-dev.org postmaster[8000]: 2019-05-19 13:16:36.480 EDT …2 » mai 19 13:16:36 tchana.micronator-dev.org postmaster[8000]: 2019-05-19 13:16:36.495 EDT …ces mai 19 13:16:36 tchana.micronator-dev.org postmaster[8000]: 2019-05-19 13:16:36.495 EDT … ». mai 19 13:16:36 tchana.micronator-dev.org systemd[1]: Started PostgreSQL 11 database server. Hint: Some lines were ellipsized, use -l to show in full. [root@tchana ~]# </file> ==== Redémarrage d'Odoo ==== On redémarre le service Odoo. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 13:21:24 EDT; 41s ago Main PID: 8324 (scl) CGroup: /system.slice/odoo12.service ├─8324 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /o… ├─8325 /bin/bash /var/tmp/sclaw6YFd └─8328 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/odo… mai 19 13:21:24 tchana.micronator-dev.org systemd[1]: Stopped Odoo12. mai 19 13:21:24 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> Après un changement de mot de passe, on supprime l'historique du fureteur Internet, on se reconnecte à Odoo et on vérifie quelques pages. ==== Super-utilisateur de PostgreSQL ==== Si le mot de passe a été perdu ou piraté, on doit changer le mot de passe du super utilisateur PostgreSQL postgres. Vous pouvez trouver le mot de passe du super utilisateur PostgreSQL postgres dans le fichier de configuration /etc/odoo-server.conf. <file> [root@tchana ~]# cat /etc/odoo-server.conf | grep admin_passwd admin_passwd = fghtbgh [root@tchana ~]# </file> Si on veut changer le mot de passe du super utilisateur PostgreSQL postgres, il faut aussi le changer: - à la console du Serveur NethServer, - à la console de PostgreSQL, - dans le fichier /etc/odoo-server.conf et - dans le fichier /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh - pour ce dernier voir la section Script de sauvegarde PostgreSQL. ==== À la console du Serveur NethServer ==== On vérifie si nous sommes root. <file> root@tchana ~]# whoami root [root@tchana ~]# </file> On change le mot de passe Linux du super-utilisateur postgres. <file> [root@tchana ~]# passwd postgres Changement de mot de passe pour l'utilisateur postgres. Entrez le nouveau mot de passe UNIX : nouveau-mot-de-passe-pour-postgres Retapez le nouveau mot de passe UNIX : nouveau-mot-de-passe-pour-postgres passwd : mise à jour réussie de tous les jetons d'authentification. [root@tchana ~]# </file> ==== À la console de PostgreSQL ==== On se substitue au super-utilisateur postgres. <file> [root@tchana ~]# su - postgres Dernière connexion : dimanche 19 mai 2019 à 13:14:13 EDT sur pts/0 -bash-4.2$ </file> On ouvre la console PostgreSQL. <file> -bash-4.2$ psql psql (11.3) Saisissez « help » pour l'aide. postgres=# </file> On change le mot de passe du super-utilisateur postgres. <file> postgres=# \password Saisissez le nouveau mot de passe : nouveau-mot-de-passe-du-super-utilisateur Saisissez-le à nouveau : nouveau-mot-de-passe-du-super-utilisateur postgres=# </file> On sort de la console PostgreSQL. <file> postgres=# \q -bash-4.2$ </file> On retourne à l'utilisateur root. <file> -bash-4.2$ exit déconnexion [root@tchana ~]# </file> ==== Dans le fichier /etc/odoo-server.conf ==== On édite le fichier /etc/odoo-server.conf et on change le mot de passe du super-utilisateur de PostgreSQL. On vérifie. <file> [root@tchana ~]# cat /etc/odoo-server.conf | grep admin_passwd admin_passwd = fghtbgh [root@tchana ~]# </file> ==== 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 (voir le paragraphe Script de sauvegarde PostgreSQL) et on change le mot de passe PostgreSQL de l'utilisateur postgres. On vérifie. <file> [root@tchana ~]# cat /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh | grep MDP_SUPER_utilisateur= MDP_SUPER_utilisateur=fghtbgh [root@tchana ~]# </file> ==== Réamorçage de PostgreSQL ==== On réamorce PostgreSQL. <file> [root@tchana ~]# systemctl restart postgresql-11 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status postgresql-11 ● postgresql-11.service - PostgreSQL 11 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-11.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 14:03:45 EDT; 58s ago Docs: https://www.postgresql.org/docs/11/static/ Process: 11052 ExecStartPre=/usr/pgsql-11/bin/postgresql-11-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 11058 (postmaster) CGroup: /system.slice/postgresql-11.service ├─11058 /usr/pgsql-11/bin/postmaster -D /var/lib/pgsql/11/data/ ├─11061 postgres: logger ├─11063 postgres: checkpointer ├─11064 postgres: background writer ├─11065 postgres: walwriter ├─11066 postgres: autovacuum launcher ├─11067 postgres: stats collector └─11068 postgres: logical replication launcher mai 19 14:03:45 tchana.micronator-dev.org systemd[1]: Stopped PostgreSQL 11 database server. mai 19 14:03:45 tchana.micronator-dev.org systemd[1]: Starting PostgreSQL 11 database se…. mai 19 14:03:45 tchana.micronator-dev.org postmaster[11058]: 2019-05-19 14:03:45.169 EDT…432 mai 19 14:03:45 tchana.micronator-dev.org postmaster[11058]: 2019-05-19 14:03:45.172 EDT…2 » mai 19 14:03:45 tchana.micronator-dev.org postmaster[11058]: 2019-05-19 14:03:45.178 EDT…2 » mai 19 14:03:45 tchana.micronator-dev.org postmaster[11058]: 2019-05-19 14:03:45.193 EDT…ces mai 19 14:03:45 tchana.micronator-dev.org postmaster[11058]: 2019-05-19 14:03:45.193 EDT… ». mai 19 14:03:45 tchana.micronator-dev.org systemd[1]: Started PostgreSQL 11 database server. Hint: Some lines were ellipsized, use -l to show in full. [root@tchana ~]# </file> ==== Réamorçage d'Odoo ==== On réamorce le service Odoo. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 14:07:58 EDT; 7s ago Main PID: 11343 (scl) CGroup: /system.slice/odoo12.service ├─11343 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /… ├─11344 /bin/bash /var/tmp/sclhTImIl └─11347 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/od… mai 19 14:07:58 tchana.micronator-dev.org systemd[1]: Stopped Odoo12. mai 19 14:07:58 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> Après un changement de mot de passe, on supprime l'historique du fureteur Internet, on se reconnecte à Odoo et on vérifie quelques pages.
==== Administrateur Odoo ==== Si le mot de passe a été perdu ou piraté, on doit changer le mot de passe de l'administrateur d'Odoo en se connectant avec l'adresse courriel/mot de passe de l'administrateur utilisé pour la création de la base de données, lors de la finalisation de l'installation d'Odoo au paragraphe Création d'une nouvelle base de données.

On se déconnecte d'Odoo et on se reconnecte avec le nouveau mot de passe.

Le nouveau mot de passe de l'administrateur d'Odoo est fonctionnel.

====== Sauvegarde de la BD - Interface Odoo ====== ===== Introduction ===== On peut faire une sauvegarde/restauration de PostgreSQL directement avec l'interface d'Odoo. ===== Sauvegarde =====

- On se déconnecte.
- On supprime l'historique du navigateur.
- https://www.odoo.micronator-dev.org/
- Manage Databases.

Backup.

- Le nom de la base de donnée Odoo-12 est déjà affichée.
- Mot de passe du super-utilisateur postgres.
- On sélectionne zip (include filestore)
- Backup.

Enregistrer le fichier → OK.

Enregistrer.

===== Récupération du fichier de la sauvegarde PostgreSQL ===== - Depuis le poste de travail tel que ci-dessus au paragraphe Sauvegarde. - Depuis la sauvegarde NethServer décrite à la section Odoo-12.zip depuis une sauvegarde NethServer. Après avoir avoir récupéré cette sauvegarde, on la télécharge sur le poste de travail pour qu'Odoo puisse y accéder pour la restauration avec son interface Web. ===== Restriction des connexions à Odoo ===== Avant de pouvoir restaurer une sauvegarde PostgreSQL, il faut supprimer la BD actuelle. Vu qu'il n'y aura plus de BD, Odoo présentera l'écran de création de la base de données lorsqu'un utilisateur accédera à l'interface Odoo. Pour remédier à cette situation, il est préférable de restreindre l'accès seulement au poste de travail que vous utilisez pour la récupération de la BD. Si vous êtes sur un poste de travail qui n'est pas sur le segment IP LOCAL du Serveur NethServer, il est alors préférable d'utiliser une connexion TeamViewer vers une station qui est déjà branchée sur ce segment IP. Pour l'installation de TeamViewer sur un poste de travail, consultez la section TeamViewer du Cahier-02 : du “Cours NethServer-101” . Interface Web NethServer → Passerelle → Proxy inverse → onglet Hôtes virtuels → Éditer. Accéder depuis les réseaux CIDR
On entre l'adresse IP du poste de travail sous le format: xxx.xxx.xxx.xxx/32. Ce poste sera le seul à pouvoir accéder à Odoo.
Attention à ne pas vous peinturer dans un coin… → SOUMETTRE.

===== Restauration ===== Pour pouvoir restaurer une BD d'Odoo, il faut supprimer l'ancienne.

- On se déconnecte d'Odoo.
- On se rend à: https://www.odoo.micronator-dev.org/.
- Manage Databases.

Delete.

- On entre le mot de passe du super-utilisateur postgres.
- Le nom de la base de donnée Odoo-12 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 ===== ==== Interface Odoo ==== On se logue à Odoo et on vérifie si tout est tel qu'au moment de la sauvegarde.

==== Journal Odoo ==== On vérifie le journal d'Odoo. Interface Web NethServer → Administration → Logs. On clique /var/log/odoo/odoo-server.log.

On redémarre Odoo pour une vérification finale. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> On réexamine le fichier journal pour vérifier le redémarrage. <file> [root@tchana ~]# tail -n8 /var/log/odoo/odoo-server.log 2019-05-20 03:00:13,394 5225 INFO ? odoo.service.server: Initiating shutdown 2019-05-20 03:00:13,395 5225 INFO ? odoo.service.server: Hit CTRL-C again or send a second signal to force the shutdown. 2019-05-20 03:00:14,802 6892 INFO ? odoo: Odoo version 12.0 2019-05-20 03:00:14,803 6892 INFO ? odoo: Using configuration file at /etc/odoo-server.conf 2019-05-20 03:00:14,803 6892 INFO ? odoo: addons paths: ['/opt/odoo/.local/share/Odoo/addons/12.0', '/opt/odoo/odoo12/addons', '/opt/odoo/odoo12/odoo/addons'] 2019-05-20 03:00:14,805 6892 INFO ? odoo: database: odoo@localhost:5432 2019-05-20 03:00:15,092 6892 INFO ? odoo.addons.base.models.ir_actions_report: Will use the Wkhtmltopdf binary at /usr/local/bin/wkhtmltopdf 2019-05-20 03:00:15,458 6892 INFO ? odoo.service.server: HTTP service (werkzeug) running on tchana.micronator-dev.org:8069 [root@tchana ~]# </file>
===== Suppression de la restriction des connexions à Odoo ===== Interface Web NethServer → Passerelle → Proxy inverse → onglet Hôtes virtuels → Éditer. Accéder depuis les réseaux CIDR
On supprime l'adresse entrée précédemment. → SOUMETTRE.


===== Instantané VirtualBox ===== À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

====== Sauvegarde manuelle de la BD ====== ===== Description ===== Nous créons 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 script est alors sécurisé et seul l'utilisateur root pourra le lancer. Ce script sera lancé par une tâche cron qui s'exécutera à 02h00, juste avant la sauvegarde habituelle des données du Serveur NethServer 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-12 de PostgreSQL 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. <file> [root@tchana ~]# mkdir /var/lib/pgsql/sauvegarde [root@tchana ~]# </file> On change le propriétaire et le groupe. <file> [root@tchana ~]# chown postgres:postgres /var/lib/pgsql/sauvegarde [root@tchana ~]# </file> On ajuste tous les droits afin que seul l'utilisateur postgres puisse y accéder. <file> [root@tchana ~]# chmod 700 /var/lib/pgsql/sauvegarde [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# ls -alsd /var/lib/pgsql/sauvegarde 0 drwx—— 2 postgres postgres 6 19 mai 16:28 /var/lib/pgsql/sauvegarde [root@tchana ~]# </file> ===== Script de sauvegarde PostgreSQL ===== Prendre tout le contenu de l'encadré pour la commande. <file> cat > /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh «'EOT' #!/bin/sh # Script pour générer une sauvegarde de la BD PostgreSQL d'Odoo. # Michel-André 2018-09-17_11h16 # vars TEMPS_DE_PAUSE=10 REP_SAUVEGARDE=/var/lib/pgsql/sauvegarde NOM_BD_ODOO=Odoo-12 FORMAT_FICHIER=zip MDP_SUPER_utilisateur=fghtbgh PORT_ODOO=8069 # On vérifie qu'odoo-server est en cours d'exécution. if (!(/usr/bin/systemctl status odoo12 | grep “active (running)”)); 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 /usr/bin/systemctl start odoo12 /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 le démarrage d'Odoo” /bin/echo “Pause de $TEMPS_DE_PAUSE secondes pour le 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_utilisateur \ -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 </file> On vérifie les sept premières lignes du fichier. <file> [root@tchana ~]# head -n7 /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh #!/bin/sh # Script pour générer une sauvegarde de la BD PostgreSQL d'Odoo. # Michel-André 2018-09-17_11h16 # vars TEMPS_DE_PAUSE=10 [root@tchana ~]# </file> Il n'y a pas de ligne vide avant la ligne #!/bin/sh. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande. On sécurise le fichier en changeant le groupe et le propriétaire. <file> [root@tchana ~]# chown root:root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> On ajuste les droits pour rendre le fichier exécutable par l'utilisateur root uniquement. <file> [root@tchana ~]# chmod 700 /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# ls -als /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh 4 -rwx—— 1 root root 2308 19 mai 16:37 /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> ===== Sauvegarde ===== ==== Vérification du script de sauvegarde ==== On vérifie le fonctionnement de notre script de sauvegarde en simulant ce que fera cron. <file> [root@tchana ~]# /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh Active: active (running) since dim. 2019-05-19 15:59:27 EDT; 40min ago odoo-server est en cours d'execution… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2857k 0 2857k 100 357 821k 102 0:00:03 0:00:03 –:–:– 822k La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip [root@tchana ~]# </file> On vérifie le fichier de sauvegarde pour s'assurer que celle-ci ait réussie. <file> [root@tchana ~]# ls -ls /var/lib/pgsql/sauvegarde/Odoo-12.zip 2860 -rwx—— 1 root root 2925903 19 mai 16:40 /var/lib/pgsql/sauvegarde/Odoo-12.zip [root@tchana ~]# </file> Comme on le voit, seul root pourra manipuler le fichier de sauvegarde.
==== Journal du Serveur NethServer ====

...
May 19 16:40:04 tchana root: ********************  odoo-server ********************
May 19 16:40:04 tchana root: odoo-server est en cours d'execution...
May 19 16:40:07 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip
May 19 16:40:07 tchana 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. ==== Vérification ==== On affiche le status d'Odoo. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 15:59:27 EDT; 44min ago Main PID: 3996 (scl) CGroup: /system.slice/odoo12.service ├─3996 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /o… ├─4037 /bin/bash /var/tmp/sclbZ8ob8 └─4052 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/odo… mai 19 15:59:27 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> On arrête Odoo. <file> [root@tchana ~]# systemctl stop odoo12 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: inactive (dead) since dim. 2019-05-19 16:44:08 EDT; 4s ago Process: 3996 ExecStart=/usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/odoo-server.conf (code=killed, signal=TERM) Main PID: 3996 (code=killed, signal=TERM) mai 19 15:59:27 tchana.micronator-dev.org systemd[1]: Started Odoo12. mai 19 16:44:07 tchana.micronator-dev.org systemd[1]: Stopping Odoo12… mai 19 16:44:08 tchana.micronator-dev.org systemd[1]: Stopped Odoo12. [root@tchana ~]# </file> On relance le script de sauvegarde. <file> [root@tchana ~]# /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh odoo-server N'EST PAS en cours d'execution… odoo-server est relancé Pause de 10 secondes pour le démarrage d'Odoo odoo-server est en cours d'execution… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2857k 0 2857k 100 357 1169k 146 0:00:02 0:00:02 –:–:– 1169k La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip [root@tchana ~]# </file> On vérifie le statut d'Odoo. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since dim. 2019-05-19 16:47:46 EDT; 1min 13s ago Main PID: 8269 (scl) CGroup: /system.slice/odoo12.service ├─8269 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /o… ├─8271 /bin/bash /var/tmp/sclIPE437 └─8276 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/odo… mai 19 16:47:46 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> Le script a bien démarré Odoo.
On vérifie le fichier de sauvegarde pour s'assurer que celle-ci ait réussie. <file> [root@tchana ~]# ls -ls /var/lib/pgsql/sauvegarde/Odoo-12.zip 2860 -rwx—— 1 root root 2925903 19 mai 16:47 /var/lib/pgsql/sauvegarde/Odoo-12.zip [root@tchana ~]# </file> ==== Inclusion du répertoire dans la sauvegarde de NethServer ==== Le répertoire inclut le script sauvegarde-postgres.sh et le fichier Odoo-12.zip de la sauvegarde PostgreSQL. On vérifie si le nom du répertoire /var/lib/pgsql/sauvegarde/ est déjà inséré dans le fichier d'inclusion de la sauvegarde des données: /etc/backup-data.d/custom.include, sinon on l'insère. Prendre tout le contenu de l'encadré pour la commande. <file> NouvelleInclusion=”/var/lib/pgsql/sauvegarde/“ if grep -Fxq “$NouvelleInclusion” /etc/backup-data.d/custom.include then # L'entrée a été trouvée dans custom.include echo -e “\nLe fichier custom.include contient déjà l'entrée:\n$NouvelleInclusion \n” else # L'entrée n'a pas été trouvée dans custom.include echo -e “$NouvelleInclusion” » /etc/backup-data.d/custom.include echo -e “\nL'entrée: $NouvelleInclusion a été ajoutée\n” fi </file> On vérifie. <file> [root@tchana ~]# cat /etc/backup-data.d/custom.include | grep /var/lib/pgsql/sauvegarde/ /var/lib/pgsql/sauvegarde/ [root@tchana ~]# </file> Ci-dessus, il n'y a pas de ligne vide avant /var/lib/pgsql/sauvegarde/. Nous en avons inséré une afin de faciliter la copie de la commande.

===== Tâche cron ===== On crée une tâche cron qui s'exécutera quotidiennement à 02h00 (0 2 * * *), car la sauvegarde régulière des données du Serveur NethServer est programmée pour rouler à 03h00 et nous voulons y inclure la sauvegarde de PostgreSQL. ==== Répertoire pour un gabarit personnalisé ==== Création du répertoire.
Prendre tout le contenu de l'encadré pour la commande. <file> DIR=”/etc/e-smith/templates-custom/etc/crontab“ for NAME in $DIR do if [ ! -d $NAME ]; then mkdir -p $NAME chown odoo.odoo $NAME chmod 770 $NAME fi done </file> On vérifie. <file> [root@tchana ~]# ls -alsd /etc/e-smith/templates-custom/etc/crontab 0 drwxrwx— 2 odoo odoo 6 19 mai 16:59 /etc/e-smith/templates-custom/etc/crontab [root@tchana ~]# </file> ==== Création de la tâche cron ==== On crée le fichier de la tâche cron et on y insère son contenu. Elle s'exécutera quotidiennement à 02h00.
Prendre tout le contenu de l'encadré pour la commande. <file> 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-12. Cette tâche cron roulera quotidiennement à 02h30. # Michel-André, 2018-06-18_11h27 # ┌───────────── 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) # │ │ │ │ │ # * * * * * [utilisateur] commande à exécuter # 0 2 * * * root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh EOT </file> L'heure peut être choisie à votre entière discrétion.
On vérifie le contenu du fichier de la tâche. <file> [root@tchana ~]# cat /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql SHELL=/bin/bash MAILTO=root # # Tâche cron qui lance /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh afin # de sauvegarder la BD d'Odoo-12. Cette tâche cron roulera quotidiennement à 02h30. # Michel-André, 2018-06-18_11h27 # ┌───────────── 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) # │ │ │ │ │ # * * * * * [utilisateur] commande à exécuter # 0 2 * * * root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> Il n'y a pas de ligne vide avant la ligne SHELL=/bin/bash. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande. On sécurise le fichier. <file> [root@tchana ~]# chmod 700 /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql [root@tchana ~]# </file> On vérifie <file> [root@tchana ~]# ls -ls /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql 4 -rwx—— 1 root root 859 19 mai 17:14 /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql [root@tchana ~]# </file> On développe le gabarit personnalisé. <file> [root@tchana ~]# /sbin/e-smith/expand-template /etc/crontab [root@tchana ~]# </file> On redémarre le démon crond. <file> [root@tchana ~]# systemctl restart crond [root@tchana ~]# </file> ==== 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 afin de vérifier son exécution. On change l'heure de la tâche. <file> [root@tchana ~]# sed -i 's/^0 2/\* \*/' /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# tail -n3 /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql # * * * * * root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> On développe le gabarit personnalisé. <file> [root@tchana ~]# /sbin/e-smith/expand-template /etc/crontab [root@tchana ~]# </file> On redémarre le démon crond. <file> [root@tchana ~]# systemctl restart crond [root@tchana ~]# </file> ==== Suivi ==== On lance la commande ci-dessous pour suivre toutes les tâches cron et on filtre avec grep celles qui contiendront sauvegarde. <file> [root@tchana ~]# tail -F /var/log/messages | grep sauvegarde </file> À toutes les minutes, on voit notre tâche s'afficher.

...
May 19 17:19:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip
May 19 17:20:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip
May 19 17:21:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip
...

On arrête la commande tail avec [CTL] + [c]. <file> … May 19 17:21:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip ^C [root@tchana ~]# </file> ==== Vérification lorsqu'Odoo est arrêté ==== On arrête Odoo. <file> [root@tchana ~]# systemctl stop odoo12 [root@tchana ~]# </file> On relance la commande tail. <file> [root@tchana ~]# tail -F /var/log/messages | grep sauvegarde </file> À toutes les minutes, on voit notre tâche s'afficher. <file> … May 19 17:24:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip … </file> On arrête la commande tail avec [CTL] + [c]. <file> … May 19 17:24:03 tchana root: La sauvegarde de la BD Odoo-12 est dans: /var/lib/pgsql/sauvegarde/Odoo-12.zip ^C [root@tchana ~]# </file> On remet l'heure de la tâche cron à 02h00. <file> [root@tchana ~]# sed -i 's/\* \* \* \* \* root/0 2 \* \* \* root/' \ /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# tail -n3 /etc/e-smith/templates-custom/etc/crontab/sauvegarde_postgresql # * 2 * * * * root /var/lib/pgsql/sauvegarde/sauvegarde-postgres.sh [root@tchana ~]# </file> On développe le gabarit personnalisé. <file> [root@tchana ~]# /sbin/e-smith/expand-template /etc/crontab [root@tchana ~]# </file> On redémarre le démon crond. <file> [root@tchana ~]# systemctl restart crond [root@tchana ~]# </file> ==== Courriel de notification ==== L'utilisateur root (admin) recevra un courriel, semblable à celui ci-dessous, à la fin de la tâche cron. On se rend à l'URL: https://www.micronator-dev.org/webmail. On se logue avec l'utilisateur root et son mot de passe.

==== Inclusion du script dans la sauvegarde de NethServer ==== On vérifie si le nom du répertoire /etc/e-smith/templates-custom/etc/crontab/ est déjà inséré dans le fichier d'inclusion de la sauvegarde des données: /etc/backup-data.d/custom.include, sinon on l'insère. Prendre tout le contenu de l'encadré pour la commande. <file> NouvelleInclusion=”/etc/e-smith/templates-custom/etc/crontab/“ if grep -Fxq “$NouvelleInclusion” /etc/backup-data.d/custom.include then # L'entrée a été trouvée dans custom.include echo -e “\nLe fichier custom.include contient déjà l'entrée:\n$NouvelleInclusion \n” else # L'entrée n'a pas été trouvée dans custom.include echo -e “$NouvelleInclusion” » /etc/backup-data.d/custom.include echo -e “\nL'entrée: $NouvelleInclusion a été ajoutée\n” fi </file> On vérifie. <file> [root@tchana ~]# cat /etc/backup-data.d/custom.include | grep crontab /etc/e-smith/templates-custom/etc/crontab/ [root@tchana ~]# </file>

Notre tâche cron pour la sauvegarde automatique de PostgreSQL fonctionne parfaitement.

===== Récupération du fichier de sauvegarde ===== On peut choisir le fichier de sauvegarde qu'on veut restaurer. - /var/lib/pgsql/sauvegarde/Odoo-12.zip - Odoo-12.zip depuis une une sauvegarde NethServer ==== /var/lib/pgsql/sauvegarde/Odoo-12.zip ==== La dernière sauvegarde PostgreSQL est présente dans le répertoire /var/lib/pgsql/sauvegarde/. ==== Odoo-12.zip depuis une sauvegarde NethServer ==== Si le fichier de sauvegarde stocké sur le poste de travail n'est pas assez récent, on peut récupérer le fichier de sauvegarde PostgreSQL depuis les sauvegardes NethServer . On s'assure que le fichier Odoo-12.zip est présent dans les sauvegardes NethServer. <file> [root@tchana ~]# /sbin/e-smith/backup-data-list -b backup-data | grep Odoo-12.zip Mon May 20 10:37:07 2019 var/lib/pgsql/sauvegarde/Odoo-12.zip [root@tchana ~]# </file> Le fichier Odoo-12.zip est présent dans la dernière sauvegarde NethServer, mais on peut le choisir de n'importe quelle sauvegarde. Backup file
On choisit la sauvegarde désirée. ⦿ Restaurer les fichiers dans le chemin original
- On peut choisir la destination de la récupération.
Sélectionner un ou plusieurs dossiers/fichiers à restaurer
On sélectionne le répertoire: /var/lib/pgsql/sauvegarde/. Dossiers ou fichiers à restaurer affiche notre sélection. → RESTAURER.

===== Restriction des connexions ===== On restreint les connexions à Odoo selon la section Restriction des connexions à Odoo.
===== Suppression de la base de données actuelle ===== On vérifie si le service est en cours d'exécution. <file> [root@tchana ~]# systemctl status odoo12 ● odoo12.service - Odoo12 Loaded: loaded (/etc/systemd/system/odoo12.service; enabled; vendor preset: disabled) Active: active (running) since lun. 2019-05-20 09:03:22 EDT; 19s ago Main PID: 28231 (scl) CGroup: /system.slice/odoo12.service ├─28231 /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 /… ├─28232 /bin/bash /var/tmp/sclqm2WW4 └─28235 /opt/odoo/odoo12-venv/bin/python3 /opt/odoo/odoo12/odoo-bin -c /etc/od… mai 20 16:03:22 tchana.micronator-dev.org systemd[1]: Started Odoo12. [root@tchana ~]# </file> On arrête Odoo. <file> [root@tchana ~]# systemctl stop odoo12 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 | grep Active Active: inactive (dead) since lun. 2019-05-20 16:05:48 EDT; 1min 31s ago [root@tchana ~]# </file> On se substitue à l'utilisateur postgres. <file> root@tchana ~]# su - postgres Dernière connexion : vendredi 17 mai 2019 à 00:12:36 EDT sur pts/0 -bash-4.2$ </file> On entre dans la console PostgreSQL. <file> -bash-4.2$ psql psql (11.3) Saisissez « help » pour l'aide. postgres=# </file> On affiche les BD présentes. <file> postgres=# \list Liste des bases de données Nom | Propriétaire | Encodage | Collationnement | Type caract. | Droits d'accès ———–+————–+———-+—————–+————–+———————- Odoo-12 | odoo | UTF8 | C | fr_FR.utf8 | postgres | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | template0 | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | =c/postgres + | | | | | postgres=CTc/postgres (4 lignes) postgres=# </file> On supprime la BD actuelle d'Odoo (ne pas oublié les apostrophes ' ). <file> -bash-4.2$ dropdb 'Odoo-12' -bash-4.2$ </file> On affiche les BD présentes. <file> postgres=# \list Liste des bases de données Nom | Propriétaire | Encodage | Collationnement | Type caract. | Droits d'accès ———–+————–+———-+—————–+————–+———————- postgres | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | template0 | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | fr_FR.utf8 | fr_FR.utf8 | =c/postgres + | | | | | postgres=CTc/postgres (3 lignes) postgres=# </file> La base de données Odoo-12 n'est plus présente, elle a bien été supprimée. On quitte la console PostgreSQL. <file> postgres=# \q -bash-4.2$ </file> On revient à l'utilisateur root. <file> -bash-4.2$ exit déconnexion root@tchana ~]# </file> On relance Odoo pour pouvoir ré-insérer la bases de données originale. <file> root@tchana ~]# systemctl start odoo12 root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 | grep Active Active: active (running) since lun. 2019-05-20 16:22:45 EDT; 51s ago [root@tchana ~]# </file>
===== Restauration manuelle ===== Référence: https://linuxize.com/post/how-to-setup-automatic-odoo-backup/. On lance la restauration. (Peut prendre quelques instants.) Faire attention au mot de passe s'il a été changé. <file> [root@tchana ~]# curl -F 'master_pwd=fghtbgh' \ -F backup_file=@/var/lib/pgsql/sauvegarde/Odoo-12.zip \ -F 'copy=true' \ -F 'name=Odoo-12' \ http://localhost:8069/web/database/restore <!DOCTYPE html> <html> <head> <meta http-equiv=“content-type” content=“text/html; charset=utf-8”> <title>Odoo</title> <link rel=“shortcut icon” href=”/web/static/src/img/favicon.ico“ type=“image/x-icon”> … [root@tchana ~]# </file> ==== Vérification ==== On se logue à Odoo et on vérifie si tout est tel qu'avant la sauvegarde: https://www.odoo.micronator-dev.org.
Si on rencontre des difficultés à accéder, on vidange le cache DNS du poste de travail de même que l'historique du navigateur Internet.

** Tout est tel qu'auparavant. **

===== Suppression de la restriction des connexions ===== On supprime la restriction des connexions à Odoo selon la section Suppression de la restriction des connexions à Odoo.
===== Instantané VirtualBox ===== À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

La sauvegarde et la restauration manuelle fonctionnent correctement.

====== Sauvegarde NethServer ====== ===== Description ===== Référence: http://docs.nethserver.org/en/v7/backup.html. La récupération d'une sauvegarde est le seul moyen de restaurer une machine en cas de sinistre. Le système gère deux types de sauvegardes: - Sauvegarde de la configuration
Ce type de sauvegarde ne contient que les fichiers de configuration du système. Son objectif est de restaurer rapidement une machine en cas de récupération après sinistre. - Sauvegarde des données
Ce type de sauvegarde est activée par l’installation du module “Sauvegarde” et contient, par défaut, toutes les données stockées dans le système (répertoires des utilisateurs, dossiers partagés, courriels, etc). Cette sauvegarde s'exécute une fois par jour et peut être complète ou incrémentielle sur une base hebdomadaire (six incrémentielles et la septième complète). Elle contient également l'archive de la Sauvegarde de la configuration. Plusieurs sauvegardes peuvent être configurées pour enregistrer différentes données à des intervalles différents.
Lorsque la machine est fonctionnelle, une restauration complète des données peut être effectuée même si la machine est déjà en production.
===== Sauvegarde de la configuration ===== Référence: https://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-backup-config.html. Depuis la page Configuration → Sauvegarde (configuration), la sauvegarde de la configuration du système (passwd, config databases, etc) peut être créée, envoyée ou configurée. En outre, une tâche automatisée s'exécute chaque nuit à 00h15 et crée une nouvelle archive, /var/lib/nethserver/backup/backup-config.tar.xz si un des fichiers à sauvegarder a été modifié au cours des dernières 24 heures. ==== Config de la sauvegarde de la configuration=== Configuration → Sauvegarde (configuration) → onglet Configurer, on spécifie le nombre de sauvegardes automatiques à conserver.

Ces sauvegardes n'ont que quelques Ko; on peut en conserver un assez grand nombre. Elles sont stockées dans le répertoire /var/lib/nethserver/backup/history et son numérotées de c00.tar.xz à cnn.tar.xz. La liste des modules installés est incluse dans l'archive de sauvegarde. La procédure de restauration peut télécharger et installer automatiquement les modules énumérés. ==== Personnalisation ==== === Inclusion === Dans la plupart des cas, il n'est pas nécessaire de modifier la Sauvegarde de la configuration, mais peut être utile par exemple si vous avez une configuration httpd personnalisée. Dans ce cas, vous pouvez ajouter /chemin/nom du fichier contenant la personnalisation à la liste des fichiers à sauvegarder. Si vous souhaitez ajouter un fichier à la Sauvegarde de la configuration, ajoutez une ligne au fichier /etc/backup-config.d/custom.include. === Exclusion === Si vous souhaitez exclure un fichier de la Sauvegarde de la configuration, ajoutez une ligne au fichier /etc/backup-config.d/custom.exclude. ==== Lancement de la Sauvegarde de la configuration ==== Configuration → Sauvegarde (configuration) → CRÉER UNE SAUVEGARDE.

Si l'écran ne s'affiche pas correctement, on l'agrandit.

- On entre une Description.
- CRÉER UN SAUVEGARDE.

La sauvegarde a été créée et on voit sa description, entrée ci-dessus lors de sa création. On peut télécharger la sauvegarde sur le poste de travail en cliquant Télécharger.

Enregistrer le fichier → OK.

Enregistrer.

Ces fichiers ne sont pas très volumineux, quelques Ko seulement.

==== Restauration d'une configuration ==== On peut récupérer une ancienne sauvegarde stockée sur le poste de travail afin de la restaurer.

Envoyer.

Parcourir…

- On sélectionne la sauvegarde à récupérer.
- Ouvrir.

- On entre une description.
- ENVOYER.

La sauvegarde récupérée apparaît dans la liste et on peut la restaurer en cliquant Restaurer.

Les différentes paramètres de la sauvegarde récupérée apparaissent ci-dessous.

- Si l'option Télécharger les modules automatiquement est cochée, les modules nécessaires seront téléchargés et installés automatiquement.
- RESTAURER.

La restauration est en cours.

La restauration a réussie. Nous aurions pu récupérer directement Première sauvegarde, car elle est dans la liste de celles qui sont encore stockée sur le Serveur NethServer.

===== Sauvegarde des données ===== Les sauvegardes sont conservées dans: /var/lib/nethserver/backup/duplicity/backup-data/. NethServer implémente 2 types de sauvegarde des données: - Sauvegarde unique (primaire, par défaut, compatible avec les versions antérieures) - Sauvegardes multiples (multi-sauvegardes, multi-moteurs) La sauvegarde des données peut être effectuée à l'aide de différents moteurs: - Duplicity (défaut) - http://duplicity.nongnu.org/ - Restic - https://restic.net/ - rsync - https://rsync.samba.org/ ==== Duplicity ==== Duplicity est le moteur par défaut pour NethServer. Il dispose d'un bon algorithme de compression qui réduira le stockage sur la destination. Duplicity nécessite une sauvegarde complète une fois par semaine. Lorsque le jeu de données est très volumineux, le processus peut prendre plus de 24 heures. NethServer n’implémente pas le chiffrage des sauvegardes si le moteur est Duplicity. Applications dorsales⁵⁾ prises en charge: - CIFS - NFS - USB - WebDAV (seulement en cas de sauvegarde unique) ==== Sauvegarde unique ==== Il s'agit de la sauvegarde système par défaut pouvant être configurée et restaurée à l'aide de l'interface Web. - Peut être planifiée une fois par jour. - Peut inclure les journaux du système. - Envoie des notifications à l'administrateur du système ou à une adresse courriel externe. ==== Répertoire partagé pour les sauvegardes ==== - Nos sauvegardes utiliseront le protocol CIFS (Common Internet File System). - Elles seront téléversées automatiquement dans un répertoire partagé sur le poste de travail. Il nous faut donc un répertoire partagé sur le poste de travail afin que le Serveur NethServer puisse y déposer les fichiers de la sauvegarde.

- On peut utiliser le répertoire déjà utilisé par les sauvegardes des autres serveurs.
- On peut aussi créer un nouveau répertoire Sauvegarde sur le disque D:\ du poste de travail.

Si Partager avec offre seulement les choix ci-dessous, fermer et ouvrir un autre Explorateur Windows.

Dans les menus de l'Explorateur Windows, Affichage → Options.

- Onglet Affichage.
- Décocher Utiliser l'Assistant Partage (recommandé).
- OK.

- On retourne au dossier Sauvegarde.
- Clac sur le nom du répertoire → Partager avec → Partage Avancé.

Onglet Partage → Partage avancé…

Cocher Partager ce dossier → Nom du partage: Sauvegarde apparaît → Autorisations.

Ajouter…

On entre le nom d'un utilisateur de la machine Windows, ex: michelandre → Vérifier les noms.

Le nom vérifié apparaît → OK.

Sélectionner michelandre → cocher toutes les Autorisations.

Sélectionner Tout le monde → décocher toutes les Autorisations → OK.

- OK.

- Le répertoire est partagé → OK.

Vérification

Dans l'Explorateur Windows, l'utilisateur michelandre entre l'adresse du poste de travail: \\10.10.10.81.

Il voit le répertoire de partage: Sauvegarde.

Tout est bien paramétré.

==== Installation du module Sauvegarde ==== Administration → Gestionnaire des logiciels → on coche Sauvegarde → AJOUTER.

APPLIQUER LES CHANGEMENTS.

Recharger la page pour afficher les nouveaux menus.

==== Sauvegardes (données) ====

Configuration → Sauvegarde (données) → onglet Général → on entre les informations demandées.

On entre les informations demandées → SOUMETTRE.

Notification

⦿ Notifier
On préfère Toujours être notifié lorsqu'une sauvegarde est effectuée.

⦿ Adresse email personnalisée
Pour recevoir les courriels, on entre l'adresse courriel de l'administrateur de tous les serveurs de notre site.

Adresse de l'expéditeur
On spécifie l'adresse courriel de l'admin du serveur d'où provient la notification.

→ SOUMETTRE.

==== Vérifications à la ligne de commande ==== === Sauvegarde (configuration) === On affiche les propriétés de la configuration ”Sauvegarde (configuration)“. <file> [root@tchana ~]# config show backup-config backup-config=configuration HistoryLength=31 status=enabled [root@tchana ~]# </file> HistoryLength: la valeur donnée au paramètre Configuration → Sauvegarde (Configuration) → Automatic backups to keep à la section Config de la sauvegarde de la configuration. status: propriété qui active ou désactive la sauvegarde automatique, peut être activée (enabled) ou désactivée (disabled). La valeur par défaut est activée. Indépendamment de cette propriété, la sauvegarde est toujours exécutée si elle est démarrée manuellement === Sauvegarde (données) === On affiche les propriétés de la configuration ”Sauvegarde (données)“. <file> [root@tchana ~]# config show backup-data backup-data=configuration IncludeLogs=enabled [root@tchana ~]# </file> IncludeLogs: nous avons coché Configuration → Sauvegarde (données) → onglet Général → Advanced options → Include system logs à la section Sauvegarde (données). On affiche les propriétés Sauvegarde (données). <file> [root@tchana ~]# db backups show backup-data=duplicity BackupTime=0 3 * * * CleanupOlderThan=56D FullDay=0 NFSHost= NFSShare= Notify=always NotifyFrom=admin@micronator-dev.org NotifyTo=michelandre@micronator.org SMBHost=10.10.10.81 SMBLogin=michelandre SMBPassword=mot-de-passe SMBShare=Sauvegarde Type=incremental USBLabel= VFSType=cifs VolSize=250 WebDAVLogin= WebDAVPassword= WebDAVUrl= status=enabled [root@tchana ~]# </file> On vérifie la propriété FullDay (dimanche=0, lundi-1, mardi=2…)
==== Personnalisation ==== === Inclusion de fichiers/répertoires === On peut inclure des fichiers/répertoires supplémentaires en les spécifiant dans le fichier d'inclusion: /etc/backup-data.d/custom.include. === Grandeur des fichiers de sauvegarde === Comme on le voit avec la commande db backups show à la section Sauvegarde (données), la propriété VolSize=250 donnera des fichiers de sauvegarde de 250 Mo. Pour une sauvegarde de plusieurs Go, ce paramètre segmentera la sauvegarde en de très nombreux fichiers. Nous ajustons la grandeur des fichiers à 2 Go (2048 Mo) et ainsi facilitons l'examen du répertoire Sauvegarde. <file> [root@tchana ~]# db backups setprop backup-data VolSize 2048 [root@tchana ~]# </file> On signale le changement. <file> [root@tchana ~]# signal-event nethserver-backup-data-update [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# db backups show → grep VolSize VolSize=2048 [root@tchana ~]# </file> ==== Lancement forcé de la sauvegarde ==== === Première sauvegarde === On peut forcer le lancement d'une sauvegarde en exécutant la commande ci-dessous. <file> [root@tchana ~]# /sbin/e-smith/backup-data -b backup-data Backup: backup-data Backup started at 2019-02-08 13:28:03 Pre backup scripts status: SUCCESS ————–[ Backup Statistics ]————– StartTime 1549650495.78 (Fri Feb 8 13:28:15 2019) EndTime 1549650497.91 (Fri Feb 8 13:28:17 2019) ElapsedTime 2.13 (2.13 seconds) SourceFiles 419 SourceFileSize 24495192 (23.4 MB) NewFiles 419 NewFileSize 24495192 (23.4 MB) DeletedFiles 0 ChangedFiles 0 ChangedFileSize 0 (0 bytes) ChangedDeltaSize 0 (0 bytes) DeltaEntries 419 RawDeltaSize 24467434 (23.3 MB) TotalDestinationSizeChange 1963840 (1.87 MB) Errors 0 ————————————————- Action 'backup-data-duplicity backup-data': SUCCESS Post backup scripts status: SUCCESS Backup status: SUCCESS Backup ended at 2019-02-08 13:28:19 Time elapsed: 0 hours, 0 minutes, 16 seconds Disk Usage: Size Used Available Use% 917.83 GB 785.67 GB 132.16 GB 85.6% [root@tchana ~]# </file> Cette sauvegarde (1 918 Ko) est complète.

On vérifie la date. <file> [root@tchana ~]# date ven février 8 13:32:59 EDT 2019 [root@tchana ~]# </file> Même si nous sommes vendredi et que nous avons paramétré les sauvegardes complètes pour les dimanches seulement, cette sauvegarde est complète, car c'est la première à ce jour. === Deuxième sauvegarde === On peut forcer une autre sauvegarde pour générer une incrémentielle. <file> [root@tchana ~]# /sbin/e-smith/backup-data -b backup-data Backup: backup-data Backup started at 2019-02-08 13:35:07 Pre backup scripts status: SUCCESS ————–[ Backup Statistics ]————– StartTime 1549650912.53 (Fri Feb 8 13:35:12 2019) EndTime 1549650912.95 (Fri Feb 8 13:35:12 2019) ElapsedTime 0.42 (0.42 seconds) SourceFiles 422 SourceFileSize 24526628 (23.4 MB) NewFiles 9 NewFileSize 23980 (23.4 KB) DeletedFiles 0 ChangedFiles 70 ChangedFileSize 14856835 (14.2 MB) ChangedDeltaSize 0 (0 bytes) DeltaEntries 79 RawDeltaSize 457642 (447 KB) TotalDestinationSizeChange 76371 (74.6 KB) Errors 0 ————————————————- Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire. Date de la dernière sauvegarde complète : Fri Feb 08 13:28:03 2019 Aucun ancien jeu de sauvegarde n’a été trouvé, rien n’a été supprimé. Action 'backup-data-duplicity backup-data': SUCCESS Post backup scripts status: SUCCESS Backup status: SUCCESS Backup ended at 2019-02-08 13:35:14 Time elapsed: 0 hours, 0 minutes, 7 seconds Disk Usage: Size Used Available Use% 917.83 GB 785.68 GB 132.15 GB 85.6% [root@tchana ~]# </file> La deuxième sauvegarde n'est que de (75 Ko) et est une incrémentielle, car ce n'est pas la première à ce jour et nous ne sommes pas dimanche.

=== Troisième sauvegarde === Nous changeons la journée des sauvegardes complètes pour qu'elles aient lieu les vendredis au lieu des dimanches → SOUMETTRE.

On force une troisième sauvegarde. <file> [root@tchana ~]# /sbin/e-smith/backup-data -b backup-data Backup: backup-data Backup started at 2019-02-08 13:44:43 Pre backup scripts status: SUCCESS ————–[ Backup Statistics ]————– StartTime 1549651488.35 (Fri Feb 8 13:44:48 2019) EndTime 1549651489.30 (Fri Feb 8 13:44:49 2019) ElapsedTime 0.95 (0.95 seconds) SourceFiles 422 SourceFileSize 24547401 (23.4 MB) NewFiles 422 NewFileSize 24547401 (23.4 MB) DeletedFiles 0 ChangedFiles 0 ChangedFileSize 0 (0 bytes) ChangedDeltaSize 0 (0 bytes) DeltaEntries 422 RawDeltaSize 24519532 (23.4 MB) TotalDestinationSizeChange 1996425 (1.90 MB) Errors 0 ————————————————- Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire. Date de la dernière sauvegarde complète : Fri Feb 08 13:28:03 2019 Aucun ancien jeu de sauvegarde n’a été trouvé, rien n’a été supprimé. Action 'backup-data-duplicity backup-data': SUCCESS Post backup scripts status: SUCCESS Backup status: SUCCESS Backup ended at 2019-02-08 13:44:51 Time elapsed: 0 hours, 0 minutes, 8 seconds Disk Usage: Size Used Available Use% 917.83 GB 785.68 GB 132.15 GB 85.6% [root@tchana ~]# </file> La troisième sauvegarde est complète car nous avons paramétré les complètes pour les vendredis. Si nous lançons une quatrième sauvegarde, elle sera complète elle aussi, car nous sommes toujours vendredi. On remet le paramètre des sauvegardes complètes pour les dimanches.

=== Exemple de récupération du fichier de sauvegarde de la configuration === Pour une reprise après sinistre, on peut récupérer le fichier d'une sauvegarde de la configuration directement depuis le fichier backup-config.tar.xz dans le répertoire de stockage - Sauvegarde du poste de travail. On se rend dans le répertoire de stockage, on claque sur le fichier backup-config.tar.xz → 7-Zip → Ouvrir archive et on navigue jusqu'au répertoire \var/lib\nethserver\backup\history.

Les sauvegardes de la configuration du serveur sont incluses dans la sauvegarde des données, car nous avons fait ce choix lors de la configuration de la sauvegarde des données.

Clac sur le fichier xxx.tar.xz → Copier vers…

OK.

Le fichier de la configuration est récupéré de la sauvegarde des données.

=== Exclusion de fichiers/répertoire === On peut exclure des fichiers/répertoires en les spécifiant dans le fichier d'exclusion: /etc/backup-data.d/custom.exclude.

===== Restauration des données ===== 1) Nous créons un fichier dans le répertoire personnel de root.
2) Nous lançons une sauvegarde.
3) Nous supprimons le fichier créé avant la sauvegarde, celui de l' étape 1.
4) Nous récupérons ce fichier contenu dans la dernière sauvegarde.
5) On vérifie la récupération. 1) On crée le fichier <file> [root@tchana ~]# touch toto [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# ls -ls toto 0 -rw-r–r– 1 root root 0 Feb 8 13:55 toto [root@tchana ~]# </file> 2) On lance une sauvegarde. <file> [root@tchana ~]# /sbin/e-smith/backup-data -b backup-data Backup: backup-data Backup started at 2019-02-08 13:56:09 Pre backup scripts status: SUCCESS … Action 'backup-data-duplicity backup-data': SUCCESS Post backup scripts status: SUCCESS Backup status: SUCCESS Backup ended at 2019-02-08 13:56:17 Time elapsed: 0 hours, 0 minutes, 8 seconds Disk Usage: Size Used Available Use% 917.83 GB 785.68 GB 132.15 GB 85.6% [root@tchana ~]# </file> 3) Nous supprimons le fichier créé avant la sauvegarde, celui de la première étape. <file> [root@tchana ~]# rm toto rm : supprimer fichier vide « toto » ? y [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# ls -ls toto ls: impossible d'accéder à toto: Aucun fichier ou dossier de ce type [root@tchana ~]# </file> ==== Restauration ==== 4) On récupère le fichier. Configuration → Restaurer les données. Backup file
On choisit la dernière sauvegarde. Mode de restauration
⦿ Restaurer les fichiers dans le chemin original. Sélectionner un ou plusieurs dossiers ou fichiers à restaurer
On entre toto. - Dans l'arborescence, on choisit /root, le répertoire contenant le fichier à restaurer.
/root apparaît dans: Dossiers ou fichiers à restaurer. → RESTAURER. Le message sur fond vert, Restauré à la position initiale indique que le fichier a été trouvé et restauré. Si nous n'avions rien spécifié sous Sélectionner un ou plusieurs dossiers ou fichiers à restaurer, c'est tout l'arborescence /root qui aurait été alors restaurée. === Vérification === 5) On vérifie. <file> [root@tchana ~]# ls -ls toto 0 -rw-r–r– 1 root root 0 Feb 8 13:55 toto [root@tchana ~]# </file> Le fichier a été restauré.
==== Recherche de fichiers dans les sauvegardes ==== On peut rechercher un fichier dans les sauvegardes (peut prendre un certain temps). <file> [root@tchana ~]# /sbin/e-smith/backup-data-list -b backup-data | grep toto Ven février 8 13:55:22 2019 root/toto [root@tchana ~]# </file>

===== Instantané VirtualBox ===== À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

===== NethServer & BackupPC ===== Référence: NethServer-101, Cahier-11: NethServer & BackupPC. Cette section décrit la marche à suivre pour créer une sauvegarde d'un Serveur NethServer (dorgee.micronator-101.org, notre serveur physique principal) vers une station distante. La sauvegarde se fait en utilisant le protocol CIFS (Common Internet File System) vers le répertoire partagé D:\Sauvegarde sur la station de travail Win-81. Toutes les sauvegardes/restaurations sur les Serveurs NethServer fonctionnent exactement de la même façon. BackupPC, installé sur un Serveur NethServer dédié aux sauvegardes, peut sauvegarder tout Serveur NethServer et il sera alors possible de le restaurer/migrer sans qu'il ne soit nécessaire de réinstaller les Modules présents ou les autres logiciels installés sur le serveur; ils seront tous restaurés, car inclus dans la sauvegarde BackupPC. ==== Description du cahier ==== Le Cahier-11: NethServer & BackupPC du “Cours NethServer-101” décrit la marche à suivre pour: l’installation de BackupPC-3.3.1 et sa mise à jour vers BackupPC-4.3.0, les prises de sauvegardes de l’hôte de BackupPC et du serveur SOURCE et enfin la restauration de la sauvegarde de SOURCE sur DESTINATION pour que ce dernier devienne un clone du premier. Ce cahier est basé sur les pages Web suivantes: https://wiki.nethserver.org/doku.php?id=module:backuppc
https://www.veritech.net/centos-7-backuppc-installation-guide/
https://srbu.se/index.php?option=com_content&view=article&id=201:upgrading-backuppc-to-v4-2-1&catid=8&Itemid=121&lang=en Page officielle de BackupPC: https://backuppc.github.io/backuppc/. Référence: https://fr.wikipedia.org/wiki/BackupPC.
BackupPC est un logiciel LIBRE, publié sous licence GPL, pour la sauvegarde de systèmes de fichiers.
Il est utilisé pour sauvegarder sur disque un ensemble de postes clients et de serveurs, sous: Unix, Linux, Windows ou Mac OS X. Les protocoles utilisables pour les transferts sont: SMB, tar over SSH/rsh/nfs et rsync. Il ne nécessite l'installation d'aucun logiciel client sur les machines à sauvegarder. Il possède une interface Web pour lancer des sauvegardes ou restaurer des fichiers. Il est également possible de sauvegarder des bases de données via un script shell lancé avant la sauvegarde.

====== Activation du mode développeur d'Odoo ====== ===== Description ===== Référence: https://riptutorial.com/fr/odoo-8/topic/3311/comment-activer-le-mode-developpeur-openerp.
Le mode développeur Odoo vous permet d'apporter des modifications substantielles à la base de données Odoo, telles que l'ajout de champs à vos documents et vues. Vous modifiez les vues par défaut de vos actions et pouvez même créer des formulaires dynamiques basés sur d'autres champs dans vos modèles. ===== Avantage ===== Bien qu'Odoo soit un puissant cadre d'application, le cycle de développement peut être brutal pour tester les modifications apportées à votre application. En utilisant le mode développeur, vous pouvez tester des expressions et résoudre de nombreux problèmes fonctionnels sans avoir à redémarrer le serveur encore et encore pour tester des modifications simples. De plus, l'outil de développement Odoo est idéal pour examiner l'architecture des formulaires et des vues afin de voir comment les champs sont liés aux modules, à leurs domaines, contextes et autres attributs. ===== Limites ===== Bien qu'il soit très tentant d'utiliser le mode développeur pour apporter certaines modifications à votre application, il existe des inconvénients. Selon ce que vous modifiez, vous pouvez perdre ces modifications avec les futures mises à jour des modules ou lorsque vous installez des applications supplémentaires dans Odoo. Ceci est particulièrement véridique pour les changements de vues. ===== Activation par un ajout à l'URL ===== Après s'être logué, pour activer temporairement le mode développeur, on ajoute dans l'URL, après le mot clé web, ?debug= et on appuie sur [Entrée]. La page sera rechargée et le mode développeur/débogage activé.

===== Commandes du mode développeur =====

En cliquant l'icône des Outils développeur, un menu se déroule et affiche plusieurs choix de commandes.

Pour quitter le mode développeur, à la page Configuration, on clique l'icône des Outils développeur → Quitter les outils développeur.

À la page Configuration, on clique Technique, un menu se déroule et affiche plusieurs autres choix de commandes.

===== Activation par un clic de la souris ===== Sur la page Configuration, ci-contre dans le cadre Partagez l'engouement, on peut activer le mode développeur avec ou sans éléments d'actif (assets) en cliquant sur un des liens suivants: - Activer le mode développeur. - Activer le mode développeur (avec les assets).

====== Mises à jour ====== ===== Odoo ===== Nous avons utilisé git pour l'installation d'Odoo-12; il peut donc aussi servir pour la mise à jour du coeur d'Odoo et de ses extensions; puis ensuite on met à jour la base de données PostgreSQL afin qu'elle utilise le code le plus récent.

Pour le nom de la BD, voir la section Création d'une nouvelle base de données ou se rendre à la page:

https://www.odoo.micronator-dev.org/web/database/manager.

S'assurer d'avoir une sauvegarde de la base de donnée PostgreSQL avant de réaliser la mise à jour. Voir la section Sauvegarde.

==== Odoo et ses extensions ==== Référence: https://www.cier.tech/fr_FR/blog/notre-blog-1/post/how-to-update-odoo-from-github-25. On arrête Odoo. <file> [root@tchana ~]# systemctl stop odoo12 [root@tchana ~]# </file> On vérifie l'arrêt. <file> [root@tchana ~]# systemctl status odoo12 | grep -i Active: Active: inactive (dead) since mar. 2019-05-21 23:23:22 EDT; 44min ago [root@tchana ~]# </file> Notez que vous devez faire la mise à jour en tant qu'utilisateur odoo. On se substitue à l'utilisateur odoo. <file> [root@tchana ~]# su - odoo Dernière connexion : dimanche 19 mai 2019 à 21:23:18 EDT sur pts/0 [odoo@tchana ~]$ </file> On vérifie. <file> [odoo@tchana ~]$ whoami odoo [odoo@tchana ~]$ </file> On se rend dans le répertoire /opt/odoo/odoo12. <file> [odoo@tchana ~]$ cd /opt/odoo/odoo12 [odoo@tchana odoo12]$ </file> On vérifie. <file> [odoo@tchana odoo12]$ pwd /opt/odoo/odoo12 [odoo@tchana odoo12]$ </file> ==== Récupération des mises à jour ==== On récupère les mises à jour avec git. <file> [odoo@tchana odoo12]$ git fetch origin 12.0 –depth=1 remote: Enumerating objects: 2717, done. remote: Counting objects: 100% (2717/2717), done. remote: Compressing objects: 100% (926/926), done. remote: Total 1595 (delta 1226), reused 742 (delta 664), pack-reused 0 Receiving objects: 100% (1595/1595), 3.88 MiB | 1.44 MiB/s, done. Resolving deltas: 100% (1226/1226), completed with 1008 local objects. From https://github.com/odoo/odoo * branch 12.0 → FETCH_HEAD [odoo@tchana odoo12]$ </file> ==== Application des mises à jour ==== Nous avons récupérer toutes les mise à jour et nous devons demander au système de les appliquer. À ce stade, le système sait quelles sont les 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 survenir.
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. <file> [odoo@tchana odoo12]$ git reset –hard origin/12.0 HEAD is now at c545783 [FIX] account: communication size [odoo@tchana odoo12]$ </file> 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.
==== Base de donnée PostgreSQL ==== On met à jour la base de données PostgreSQL afin qu'elle prenne note de toutes les modifications et qu'elle se les applique à elle-même. <file> [odoo@tchana odoo12]$ /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 \ /opt/odoo/odoo12/odoo-bin -c /etc/odoo-server.conf \ -u all -d Odoo-12 </file> ● /usr/bin/scl enable rh-python36 – /opt/odoo/odoo12-venv/bin/python3 \
Indique au système d'activer la Collection rh-python36 et d'utiliser la commande python3 de l'environ­nement virtuel odoo12-venv. La commande se poursuit sur la ligne suivante ”\“. ● /opt/odoo/odoo12/odoo-bin -c /etc/odoo-server.conf \
Lance Odoo en utilisant le fichier de configuration /etc/odoo-server.conf et la commande se poursuit sur la ligne suivante ”\“. ● -u all -d Odoo-12
Indique de mettre à jour (update) tous les modules (all) de la base de données (database) Odoo-12. Pour une explication des paramètres de la commande odoo-bin, voir: https://www.odoo.com/documentation/11.0/reference/cmdline.html
==== Surveillance de la mise à jour de la BD ==== On ouvre une deuxième session PuTTY, on se connecte en tant que root et on lance la commande suivante pour surveiller la mise à jour de la base de données. <file> [root@tchana ~]# top -d1 | grep python3 7779 odoo 20 0 340396 39236 8208 R 74,5 1,0 0:00.76 python3 7779 odoo 20 0 469568 65684 10528 S 81,0 1,7 0:01.57 python3 … 7779 odoo 20 0 489852 77196 11732 S 77,0 2,0 0:19.79 python3 7779 odoo 20 0 563584 77416 11732 S 41,2 2,0 0:20.33 python3 5926 odoo 20 0 637460 80352 11672 S 1,0 2,1 0:20.78 python3 5926 odoo 20 0 637460 80352 11672 S 1,0 2,1 0:20.79 python3 5926 odoo 20 0 637460 80352 11672 S 1,0 2,1 0:20.80 python3 [root@tchana ~]# </file> C'est la commande python3, de l'environnement virtuel odoo12-venv, qui fait tout le travail de la mise à jour de la BD. Pour ce faire, elle utilise une forte proportion du temp CPU. Lorsque l'utilisation du temp CPU utilisé par python3 redevient normal (1,0), la mise à jour de la BD est terminée. On peut fermer cette deuxième session PuTTY.
==== Arrêt de la commande de mise à jour et redémarrage du service Odoo ==== On revient à l'écran original de la session PuTTY. Les paramètres de la mise à jour de la base de données (-u all -d Odoo-12) faisaient partie de la commande du lancement d'Odoo.

[odoo@tchana odoo12]$ /usr/bin/scl enable rh-python36 -- /opt/odoo/odoo12-venv/bin/python3 \
                      /opt/odoo/odoo12/odoo-bin  -c /etc/odoo-server.conf                  \
                      -u all  -d Odoo-12

La mise à jour de la base de données est terminée, mais la commande du lancement d'Odoo continue de rouler. Vu que nous n'avons pas utiliser systemctl pour lancer Odoo, ce dernier roule donc en tant que commande et non en tant que service. Si nous fermons la fenêtre de cette session PuTTY, Odoo s'arrêtera, car la fermeture d'une fenêtre termine toutes les commandes courantes lancées par cette session. On avorte la commande avec un [CTL] + [c]. <file> ^C [odoo@tchana odoo12]$ </file> On quitte la substitution d'utilisateur pour retourner à root. <file> [odoo@tchana odoo12]$ exit déconnexion [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# whoami root [root@tchana ~]# </file> On redémarre le service Odoo en utilisant systemctl.
Contrairement à une commande, un service ne s'arrête pas si on ferme la session qui l'a lancée. <file> [root@tchana ~]# systemctl start odoo12 [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# systemctl status odoo12 | grep Active: Active: active (running) since mer. 2019-05-22 01:44:10 EDT; 1min 4s ago [root@tchana ~]# </file> ==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour: https://www.odoo.micronator-dev.org.

===== PostgreSQL ===== On procède à la mise à jour de PostgreSQL-11. <file> [root@tchana ~]# yum update -y –disablerepo=* –enablerepo=pgdg11 \ postgresql11 postgresql11-libs \ postgresql11-server postgresql11-contrib \ postgresql11-devel postgresql11-docs \ postgresql11-test Modules complémentaires chargés : changelog, fastestmirror, nethserver_events, protectbase Loading mirror speeds from cached hostfile 0 packages excluded due to repository protections No packages marked for update [root@tchana ~]# </file> Si des mises à jour étaient disponibles, elles seraient installées et dans ce cas, il faudrait redémarrer PostgreSQL et Odoo. On redémarre le service PostgreSQL.

[root@tchana ~]# systemctl restart postgresql-11

[root@tchana ~]#

[root@tchana ~]# systemctl restart odoo12

[root@tchana ~]#

==== 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: https://www.odoo.micronator-dev.org.

===== RH-Python36 ===== Mise à jour de la Collection RH-Python36. <file> [root@tchana ~]# yum update -y –enablerepo=centos-sclo-rh rh-python36* Modules complémentaires chargés : changelog, fastestmirror, nethserver_events, protectbase Loading mirror speeds from cached hostfile * ce-base: mirror.genesisadaptive.com * ce-extras: mirror.genesisadaptive.com * ce-sclo-rh: mirror.genesisadaptive.com * ce-sclo-sclo: mirror.genesisadaptive.com * ce-updates: mirror.genesisadaptive.com * centos-sclo-rh: mirror.csclub.uwaterloo.ca * epel: mirror.csclub.uwaterloo.ca * nethforge: mirror.nethserver.org * nethserver-base: mirror.nethserver.org * nethserver-updates: mirror.nethserver.org * remi-safe: mirror.team-cymru.com 1447 packages excluded due to repository protections No packages marked for update [root@tchana ~]# </file> S'il y a eu des mises à jour, on doit redémarrer le service Odoo.

[root@tchana ~]# systemctl restart odoo12

[root@tchana ~]#

==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour de PostgreSQL: https://www.odoo.micronator-dev.org.

===== 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 nous l'avons installé comme prérequis d'Odoo. - npm fonctionne avec un terminal et gère les dépendances pour une application. - npm permet également d'installer des applications Node.js disponibles depuis le référentiel [npm]. ==== Impacts sur less et lessc ==== Lors de l'installation initiale d'Odoo-11, il ne fallait pas installer la dernière version de npm, car elle générait une erreur de style dûe à l'utilitaire lssc qui n'était 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.

(b'', b'The "--no-js" argument is deprecated, as inline JavaScript is disabled by default. Use "--js" to enable inline JavaScript (not recommended).
[TypeError: Object function Object() { [native code] } has no method 'assign']
')This error occured while compiling the bundle 'web.assets_common' containing:
    - /web/static/lib/bootstrap/less/variables.less
...

Les développeurs d'Odoo ne sont pas renommés pour la compatibilité avec les versions 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 NethServer: Cahier-11 du “Cours “NethServer-101”. On vérifie la version actuelle. <file> [root@tchana ~]# npm –version 6.4.1 [root@tchana ~]# </file> ==== Mise à jour de npm/node ==== <file> [root@tchana ~]# 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.9.0 added 54 packages from 9 contributors, removed 15 packages and updated 47 packages in 11.323s [root@tchana ~]# </file> Une mise à jour a été effectuée (…updated 47 packages…). Vu qu'il y a eu une mise à jour, on doit redémarrer le service Odoo. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> ==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour de npm: https://www.odoo.micronator-dev.org.
==== Retour à la version originalement installée ==== Au cas où la nouvelle version occasionnerait des problèmes, on peut retourner à la version originalement installée.

[root@tchana ~]# npm install -g npm@6.4.1

/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 15 packages from 11 contributors, removed 54 packages and updated 47 packages in 8.626s
[root@tchana ~]#

[root@tchana ~]# npm --version

6.4.1
[root@tchana ~]#

[root@tchana ~]# systemctl restart odoo12

[root@tchana ~]#

On vidange l'historique de notre navigateur et on s'assure que java script et les témoins soient activés.
On se connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avec la version de npm originalement installée: https://www.odoo.micronator-dev.org.

===== less et less-plugin-clean-css ===== On vérifie la version actuelle de less. <file> [root@tchana ~]# less –version less 458 (POSIX regular expressions) Copyright (C) 1984-2012 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 [root@tchana ~]# </file> On vérifie la version actuelle de lessc. <file> [root@tchana ~]# lessc –version lessc 3.9.0 (Less Compiler) [JavaScript] [root@tchana ~]# </file> Pour éviter les erreurs de certificats SSL et de téléchargement. <file> [root@tchana ~]# npm configset strict-ssl false [root@tchana ~]# </file> Mise à jour de less et de less-plugin-clean-css. <file> [root@tchana ~]# npm install -g less less-plugin-clean-css /usr/bin/lessc → /usr/lib/node_modules/less/bin/lessc + less@3.9.0 + less-plugin-clean-css@1.5.1 updated 2 packages in 3.269s [root@tchana ~]# </file> Deux paquets ont été mis à jour, on devra redémarrer le service Odoo après la vérification de less et lessc. On vérifie la version actuelle de less. <file> [root@tchana ~]# less –version less 458 (POSIX regular expressions) Copyright (C) 1984-2012 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 [root@tchana ~]# </file> Il n'y a pas eu de mises à jour de less. S'il y en avait eues, elles auraient été installées. On vérifie la version actuelle de lessc. <file> [root@tchana ~]# lessc –version lessc 3.9.0 (Less Compiler) [JavaScript] [root@tchana ~]# </file> Il n'y a pas eu de mises à jour de lessc. S'il y en avait eues, elles auraient été installées. Par contre, il y a eu la mise à jour de deux paquets selon le résultat du paragraphe “Mise à jour de less et de less-plugin-clean-css”. Redémarrage du service Odoo. <file> [root@tchana ~]# systemctl restart odoo12 [root@tchana ~]# </file> ==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour des deux paquets: https://www.odoo.micronator-dev.org.

===== wkhtmltox ===== ==== Dépendances pour wkhtmltopdf ==== Mise à jour des dépendances. <file> [root@tchana ~]# yum update -y fontconfig libpng libX11 libXext libXrender \ xorg-x11-fonts-Type1 xorg-x11-fonts-75dpi Modules complémentaires chargés : changelog, fastestmirror, nethserver_events, protectbase Configuration du processus de mise à jour Loading mirror speeds from cached hostfile * base: centos.mirror.ca.planethoster.net … No packages marked for update [root@tchana ~]# </file> ==== wkhtmltox ==== Pour trouver la dernière version de wkhtmltopdf on se rend à l'URL ci-dessous: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/.

La dernière version disponible est la même que celle qu'on a installée à la section wkhtmltox.

S'il y avait eu une nouvelle version, nous aurions pu l'installer de la même manière que celle que nous avons déjà installée.

Si des mises à jour ont été installées, il nous faut redémarrer Odoo.

[root@tchana ~]# systemctl restart odoo12

[root@tchana ~]#

==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour: https://www.odoo.micronator-dev.org.

===== Serveur NethServer ===== De temps à autre, il faut mettre à jour le Serveur NethServer pour diverses raisons: suite à des mises à jour des logiciels qui composent NethServer, failles de sécurité découvertes par des utilisateurs ou des développeurs, etc.

- Administration → Gestionnaire des logiciels → onglet Mises à jour.
- TÉLÉCHARGER ET INSTALLER.

À la fin de la mise à jour, Recharger la page.

La mise à jour du Serveur NethServer s'occupe aussi de celle de la Collection PHP. ==== 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 connecte à Odoo et on vérifie que tout fonctionne correctement tel qu'avant la mise à jour NethServer: https://www.odoo.micronator-dev.org.
===== Instantané VirtualBox ===== À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

====== Appendices ====== ===== Fuseau horaire ===== Pour le fuseau horaire, il existe un fichier pour Montréal. <file> [root@tchana ~]# ls -ls /usr/share/zoneinfo/America/ | grep Montreal 4 -rw-r–r– 3 root root 3477 1 avril 08:27 Montreal [root@tchana ~]# </file> ==== Changement du fuseau horaire ==== On affiche le fuseau horaire actuel. <file> [root@tchana ~]# ls -l /etc/localtime lrwxrwxrwx 1 root root 37 19 mai 23:48 /etc/localtime → ../usr/share/zoneinfo/America/Toronto [root@tchana ~]# </file> On change le fuseau horaire pour celui de Montréal. <file> [root@tchana ~]# timedatectl set-timezone America/Montreal [root@tchana ~]# </file> On vérifie. <file> [root@tchana ~]# ls -l /etc/localtime lrwxrwxrwx 1 root root 38 22 mai 14:02 /etc/localtime → ../usr/share/zoneinfo/America/Montreal [root@tchana ~]# </file> Voilà! Le fuseau horaire Montréal est récupéré…

===== Certificat Let's Encrypt ===== ==== Description ==== Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer les connexions de notre serveur avec une clé TLS/SSL reconnue mondialement. Les utilisateurs pourront utiliser https. Référence: https://fr.wikipedia.org/wiki/Let's_Encrypt.
Let's Encrypt est une autorité de certification (CA) lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d'un mécanisme automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites Internet. ==== Examen du certificat ==== Si la demande d'un certificat a fonctionnée sans erreur, essayez de vous connecter à la page de l'interface Web NethServer. Le certificat devrait incorporer tous les noms d'hôtes que vous avez inclus et être valide pour les quatre-vingt-dix prochains jours. On examine le certificat émis par Let's Encrypt pour un autre de nos serveurs: dorgee.micronator-101.org qui est directement branché à l'Internet. On se connecte à l'interface Web: https://www.micronator-101.org:980.

- Le cadenas est vert.
- On se logue.

- On clique le cadenas.
- On clique l'icône >.

Plus d'informations.

- Onglet Sécurité.
- Afficher le certificat.

- Onglet Détails.
- Émis pour micronator-101.org.
- Émis par Let's Encrypt Authority X3.
- On voit la date de début et de fin.

- Validité → Pas après.
- Le certificat est valide pour 90 jours.

- Nom alternatif du sujet du certificat.
- Tous nos CNAME choisis lors de la demande du certificat sont affichés.
- Fermer toutes les fenêtres du certificat.

==== Vérification par Qualsys SSLLabs ==== Pour un serveur branché directement à l'Internet seulement: une fois que vous avez obtenu votre certificat, testez-le en vous rendant chez Qualsys SSLLabs, https://www.ssllabs.com/ssltest/. Soumettez le nom FQDN de votre domaine pour vérifier que le certificat fonctionne correctement.

Hostname: → micronator-101.org → Submit.

- Overall Rating → A.
- Certificate → 100%.

==== Serveur de Production ==== Une fois que vous maîtrisez tous les aspects de: Odoo, Let's Encrypt, Fail2ban et de BackupPC, 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.

===== Changement du mot de passe de root ===== Référence: https://www.rootusers.com/how-to-reset-root-user-password-in-centos-rhel-7/.
Réinitialiser le mot de passe de root est normalement une tâche simple si vous êtes déjà connecté avec les privilèges de root. Toutefois, si vous oubliez le mot de passe et devez le changer, les choses deviennent un peu plus difficiles.
Le processus a changé de la version 6 de CentOS/RHEL (Red Hat Enterprise Linux) à la version 7. Auparavant, vous démarriez en mode mono-utilisateur, puis changiez le mot de passe en tant qu'utilisateur root. À partir de la version 7, les modes équivalents sont: mode de secours et mode d’urgence. Cependant, ces modes d'opération nécessitent le mot de passe de root avant de pouvoir faire quoi que ce soit. Cette section va vous guider dans le nouveau processus pour changer le mot de passe perdu de root. Cette procédure sera exécutée à la console du système Linux, assurez-vous donc que vous y avez accès avant de commencer. Comme pour toutes les tâches de maintenance du système, assurez-vous de disposer d'une sauvegarde/instantané du système avant de poursuivre. Si votre système Linux est en cours d'exécution, redémarrez-le. S'il ne roule pas, démarrez-le. Pour CentOS 7, le menu de démarrage vous laissera 5 secondes pour sélectionner le noyau du système d’exploitation à démarrer. Ces 5 secondes sont importantes, car elles permettent aux administrateurs de sélectionner différents noyaux ou d’éditer les paramètres du noyau existant avant le démarrage. Dans le menu de démarrage, appuyez sur “e” pour modifier le noyau existant tel qu'indiqué ci-dessous.
Dans les options de grub, recherchez la ligne qui commence par linux16 et allez à la fin. Entrez rd.break à la fin de cette ligne tel qu'indiqué ci-dessous. <file> rd.break </file>
Appuyez sur [Ctrl] + [x] pour démarrer avec ces options qui vous amèneront à l'invite initramfs avec un shell root.
À ce stade, le système de fichiers racine est monté en mode lecture seule (ro) dans le répertoire /sysroot et doit être remonté avec les autorisations de lecture/écriture (rw) pour que nous puissions réellement apporter certaines modifications. Ceci est réalisé avec la commande mount -o remount,rw /sysroot. <file> switch_root:/# mount -o remount,rw /sysroot switch_root:/# </file>
Une fois le système de fichiers remonté, changez-le en une prison chroot afin que le répertoire /sysroot soit utilisé comme racine du système de fichiers. Ceci est nécessaire pour que toutes les commandes que nous exécuterons se rapportent à /sysroot. La commande à lancer est chroot /sysroot. <file> switch_root:/# chroot /sysroot sh-4.2# </file>
À partir d'ici, le mot de passe de root peut être réinitialisé à l’aide de la commande passwd. <file> sh-4.2# passwd Changing password for user root. New password: Nouveau-mot-de-passe-de-root Retype new passwd: Nouveau-mot-de-passe-de-root passwd: all authentification tokens updated successfully. sh-4.2# </file>
Si vous n'utilisiez pas SELinux, vous pourriez redémarrer à ce stade et tout irait bien. Cependant, par défaut, CentOS/RHEL-7 active SELinux. Nous devons donc corriger le contexte du fichier /etc/shadow. En effet, lorsque la commande passwd est exécutée, elle crée un nouveau fichier /etc/shadow. SELinux n'étant pas en cours d'exécution dans ce mode, le fichier est créé sans aucun contexte SELinux, ce qui peut entraîner des problèmes lors du redémarrage. On crée le fichier /.autorelabel à l’aide de touch. <file> sh-4.2# touch /.autorelabel sh-4.2# </file> La création de ce fichier effectuera automatiquement un ré-étiquetage de tous les fichiers au prochain démarrage. Notez que cela peut prendre un certain temps en fonction de la quantité de fichiers que vous avez. Peut prendre environ 2 minutes pour un serveur CentOS-7 ordinaire. On quitte l'environnement “chroot”. <file> sh-4.2# exit exit sh-4.2# </file> On quitte le shell racine initramfs (peut prendre un certain temps, être patient…). Le serveur s'amorce. <file> sh-4.2# exit logout … </file> ==== Vérification ==== À la console du serveur, vous devriez pouvoir vous connecter et utiliser le système avec le nouveau mot de passe que vous avez créé.

Victoire totale, hissons la bannière de la victoire.
—- ====== Crédits ====== © 2015-2018-2019 RF-232
Auteur: Michel-André
Remerciement: Tous les contributeurs GNU/GPL
Intégré par: Michel-André Robillard CLP
Contact: michelandre at micronator.org Répertoire de ce document: E:\000_DocPourRF232_general\RF-232_NethServer-201\RF-232_Cours_NethServer-201-02_Odoo-12_2019-08-13_18h50.odt. Historique des modifications: ^Version^Date^Commentaire^Auteur| |RC-1|2015-01-11|Début.|Michel-André| |0.0.1|2015-01-24|Début.|Michel-André| |0.0.2|2015-02-22|Petites modifications.|Michel-André| |0.0.3|2015-03-13|Correction orthographique.|Michel-André| |0.0.4|2015-04-05|Vérification complète. Changement des propriétés du document dans LibreOffice pour ajuster le titre.|Michel-André| |0.1.0|2018-05-28|Mise à jour vers SME-9.2, PostgreSQL-10.4, RH-PHP70, RH-Python36 et Odoo-12.|Michel-André| |0.2.0|2018-07-21|- Forcer le lien pour l'arrêt de PostgreSQL car le lien créé par l'ins­tal­la­tion n'est pas fonctionnel.
- Modifications du chapitre Mises à jour pour inclure: Odoo, PostgreSQL, RH-PHP70, RH-Python36 et le Serveur SME.|Michel-André| |0.3.0|2018-08-08|PostgreSQL, RH-Python36, nodejs et corrections pour la MAJ d'Odoo.|Michel-André| |0.3.1|2018-09-03|Correction de quelques coquilles.|Michel-André| |0.4.0|2018-09-16|Mise à jour complète.|Michel-André| |0.5.0|2019-05-09|Adaptation pour NethServer-7.6.1810.|Michel-André| |0.5.1|2019-08-10|Ajustements pour DokuWiki.|Michel-André| |012345678901| | |012345678901| <html><hr style=“width:50%; margin: 0 auto;”></html> ===== AVIS DE NON-RESPONSABILITÉ ===== Ce document est uniquement destiné à informer. Les informations, ainsi que les contenus et fonctionnalités de ce do­cument sont fournis sans engagement et peuvent être modifiés à tout moment. RF‑232 n'offre aucune garantie quant à l'actualité, la conformité, l'exhaustivité, la qualité et la durabilité des informations, contenus et fonctionnalités de ce document. L'accès et l'utilisation de ce document se font sous la seule responsabilité du lecteur ou de l'utilisateur. RF‑232 ne peut être tenu pour responsable de dommages de quelque nature que ce soit, y compris des dommages di­rects ou indirects, ainsi que des dommages consécutifs résultant de l'accès ou de l'utilisation de ce document ou de son contenu. Chaque internaute doit prendre toutes les mesures appropriées (mettre à jour régulièrement son logiciel antivirus, ne pas ouvrir des documents suspects de source douteuse ou non connue) de façon à protéger le contenu de son ordina­teur de la contamination d'éventuels virus circulant sur la Toile. Toute reproduction interdite Vous reconnaissez et acceptez que tout le contenu de ce document, incluant mais sans s’y limiter, le texte et les images, sont protégés par le droit d’auteur, les marques de commerce, les marques de service, les brevets, les secrets industriels et les autres droits de propriété intellectuelle. Sauf autorisation expresse de RF-232, vous acceptez de ne pas vendre, délivrer une licence, louer, modifier, distribuer, copier, reproduire, transmettre, afficher publiquement, exécuter en public, publier, adapter, éditer ou créer d’oeuvres dérivées de ce document et de son contenu. ==== Avertissement==== Bien que nous utilisions ici un vocabulaire issu des techniques informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.