Page History

Concepts

Refus de démarrer du Synchronizer en cas de problème

Le Synchronizer refusera de démarrer dans les cas décrits ci-dessous ; vous pouvez voir plus de détails en consultant le fichier de log dont le Synchronizer précise le nom.

Encryption is activated but there no key file is defined in the configuration

Le paramètre protect_fields__activate_encryption a une valeur de 1 mais le paramètre protect_fields__encryption_keyfile n'est défini dans aucun fichier de configuration utilisé par le Synchronizer.

Si la base de données est effectivement chiffrée, l'absence de clé empêchera le Synchronizer de manipuler les données protégées.

Solution: Utiliser la commande shinken-healthcheck pour vérifier si la base est effectivement chiffrée le nom de la clé utilisée ; vous disposez alors des informations nécessaires pour corriger les fichiers de configuration du Synchronizer.

Note: Si vous n'utilisez que les commandes d'administration des champs protégés, cette erreur ne devrait pas se produire.

Cannot read the protected fields secret file <fichier> : <cause>

Le fichier contenant la clé de chiffrage n'est pas lisible pour la raison indiquée. Il peut s'agit du fait que le fichier n'existe pas (ou que la valeur du paramètre protect_fields__encryption_keyfile est erronée) ou bien que l'utilisateur UNIX sous lequel fonctionne le synchronizer n'a pas les droits d'accès au fichier.

The key contained in the keyfile does not have the right structure

Le fichier contenant la clé de chiffrage est lisible, mais ne contient pas d'information utilisable par le Synchronizer. Il peut s'agit d'un fichier corrompu, auquel cas utilisez la commande shinken-protected-fields-keyfile-restore pour regénérer un fichier contenant les bonnes informations.

The Protected Fields key file was modified

Cette erreur se produit dans deux cas :

• Le nom de la clé a changé entre celui décrit dans le fichier contenant la clé, et celui que le Synchronizer a utilisé lors de sa dernière exécution. Dans ce cas le log contient les deux noms, ce qui devrait vous permettre de savoir ce qui s'est passé et de restaurer la bonne clé avec la commande shinken-protected-fields-keyfile-restore
• La clé elle-même a changé entre celle utilisé pour le chiffrage de la base de données lors de la dernière exécution du Synchronizer et celle définie dans le fichier de configuration, bien que le nom des deux clés soit le même. Cela signifie que le fichier contenant la clé a probablement été corrompu et la meilleure solution est de la restaurer avec la commande shinken-protected-fields-keyfile-restore

Vérification de la cohérence de la configuration

Le Synchronizer et les outil d'administration des champs protégés vérifient la cohérence entre les fichiers de configuration et la base de données. Les points suivants sont vérifiés

• Statut du chiffrement (activé ou non)
• Nom de la clé
• Empreinte de la clé (la clé a-t'elle changé entre le fichier de configuration et celle utilisée pour le chiffrement courant de la base ?)

En fonction du risque de perte de données, cette vérification donnera lieu à une erreur ou pas.

Chiffrage activé dans les fichiers	Base chiffrée	Incohérence	Conséquences
		Clé différente	Lors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
		Nom différent	Lors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
		Aucune incohérence	Lors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
		Clé différente	Aucune conséquence
		Clé différente	Le synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour travailler
		Nom différent	Le synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour travailler
		Aucune incohérence	Le synchronizer démarrera et désactivera le chiffrement de la base
		Clé différente	Le synchronizer refusera de démarrer
		Nom différent	Le synchronizer refusera de démarrer
		Aucune incohérence	Le synchronizer démarrera et ne modifiera pas l'état de la base

En cas de perte de la sauvegarde de la clé

Si vous perdez la sauvegarde de votre clé ET la clé, il reste un recours si vous disposez d'un backup de la configuration effectué avec shinken-backup.

Le backup de la configuration contient une sauvegarde de votre clé, chiffrée avec une clé asymétrique. La partie chiffrement est fournie dans votre installation de Shinken, mais la partie permettant le déchiffrement est détenue exclusivement par Shinken.

La commande /var/lib/shinken/libexec/tools/shinken-protected-fields-rescue-from-backup permet d'extraire d'un backup Shinken la clé chiffrée. Vous pouvez alors l'envoyer à votre support Shinken, qui vous renverra alors une sauvegarde que vous pourrez restaurer de la manière habituelle, avec shinken-protected-fields-keyfile-restore.