Concepts

Vérification de la cohérence de la configuration

Le Synchronizer et les outils 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

• Le chiffrement est-il activé ?
• Nom de la clé
• la clé a-t-elle changé entre le fichier de configuration et celle utilisée pour le chiffrement de la base ?

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

Ce tableau décrit les différents cas.

Chiffrement activé dans la base	Chiffrement activé dans la configuration	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 déchiffrer les données
		Nom différent	Le synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour déchiffrer les données
		Aucune incohérence	Le synchronizer démarrera et désactivera le chiffrement de la base
		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 ne modifiera pas l'état de la base

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

Lorsque le Synchronizer ne peut pas démarrer à cause de problèmes liés au chiffrement de données sensibles, il affichera l'un des messages d'erreurs suivants :

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

Le Synchronizer est configuré pour chiffrer les données, mais l'entrée protect_fields__encryption_keyfile  dans le fichier de configuration du Synchronizer est manquante ou vide.

Solution: Utilisez la commande shinken-healthcheck pour vérifier si la base est effectivement chiffrée et le nom de la clé utilisée.

• Si la base est chiffrée, alors shinken-healthcheck vous donne le nom de la clé, et vous pouvez alors la restaurer avec la commande shinken-protected-fields-keyfile-restore
• Si la base de données n'est pas chiffrée, alors vous pouvez utiliser la commande shinken-protected-fields-encryption-disable pour revenir dans l'état correct.

Cela restaurera les bons champs dans le fichier automatiquement, sans que vous ayez a manipuler le fichier.

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 chiffrement n'est pas lisible pour la raison indiquée dans le message d'erreur.

Il peut s'agir du fait que le fichier n'existe pas ou bien que le compte Linux "shinken" sous lequel fonctionne le Synchronizer n'a pas les droits d'accès au fichier.

• Si c'est un problème de droits Linux, redonnez au fichier indiqué dans le message d'erreur des droits permettant à l'utilisateur Linux de le lire (et uniquement cet utilisateur).
• Si le fichier n'existe pas vous pouvez le restaurer avec la commande shinken-protected-fields-keyfile-restore.

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

Le fichier contenant la clé de chiffrement 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 régénérer un fichier contenant les bonnes informations.

The Protected Fields key file was modified

Cette erreur se produit lorsque la clé décrite dans les fichiers de configuration est différente de celle utilisée pour le chiffrement des données. Deux cas peuvent se produire :

• Le nom de la clé est différent. Dans ce cas le log contient les deux noms, ce qui vous permet de restaurer la bonne clé avec la commande shinken-protected-fields-keyfile-restore
• La clé elle-même a changé alors que le nom reste identique. Cela signifie que le fichier contenant la clé a été corrompu et la meilleure solution est de la restaurer avec la commande shinken-protected-fields-keyfile-restore

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.

Nous vous conseillons alors de vous référer à la documentation de la commande shinken-protected-fields-keyfile-rescue-from-backup qui vous permettra de restaurer votre clé avec l'aide du support Shinken.