Reprise après sinistre grâce à la gestion des identités
Récupération de l'IdM après une perte de serveur ou de données
Résumé
Rendre l'open source plus inclusif
Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.
Fournir un retour d'information sur la documentation de Red Hat
Nous apprécions vos commentaires sur notre documentation. Faites-nous savoir comment nous pouvons l'améliorer.
Soumettre des commentaires sur des passages spécifiques
- Consultez la documentation au format Multi-page HTML et assurez-vous que le bouton Feedback apparaît dans le coin supérieur droit après le chargement complet de la page.
- Utilisez votre curseur pour mettre en évidence la partie du texte que vous souhaitez commenter.
- Cliquez sur le bouton Add Feedback qui apparaît près du texte en surbrillance.
- Ajoutez vos commentaires et cliquez sur Submit.
Soumettre des commentaires via Bugzilla (compte requis)
- Connectez-vous au site Web de Bugzilla.
- Sélectionnez la version correcte dans le menu Version.
- Saisissez un titre descriptif dans le champ Summary.
- Saisissez votre suggestion d'amélioration dans le champ Description. Incluez des liens vers les parties pertinentes de la documentation.
- Cliquez sur Submit Bug.
Chapitre 1. Scénarios de catastrophe dans l'IdM
Il existe deux grandes catégories de scénarios de catastrophe : server loss et data loss.
Tableau 1.1. Perte de serveur ou perte de données
| Type de catastrophe | Exemple de causes | Comment réagir |
| Server loss: Le déploiement de l'IdM perd un ou plusieurs serveurs. |
| |
| Data loss: Les données IdM sont modifiées de manière inattendue sur un serveur et le changement est propagé à d'autres serveurs. |
|
Chapitre 2. Récupération d'un serveur unique avec réplication
Si un seul serveur est gravement perturbé ou perdu, le fait de disposer de plusieurs répliques permet de créer une réplique de remplacement et de rétablir rapidement le niveau de redondance antérieur.
Si votre topologie IdM contient une autorité de certification (AC) intégrée, les étapes de retrait et de remplacement d'une réplique endommagée diffèrent selon qu'il s'agit du serveur de renouvellement de l'AC ou d'autres répliques.
2.1. Récupération après la perte du serveur de renouvellement de l'autorité de certification
Si le serveur de renouvellement de l'autorité de certification (CA) est perdu, vous devez d'abord promouvoir une autre réplique de CA pour remplir le rôle de serveur de renouvellement de CA, puis déployer une réplique de CA de remplacement.
Conditions préalables
- Votre déploiement utilise l'autorité de certification interne de l'IdM.
- Les services CA sont installés sur une autre réplique de l'environnement.
Un déploiement IdM est irrécupérable si :
- Le serveur de renouvellement de l'AC a été perdu.
- Aucun autre serveur ne dispose d'une autorité de certification.
Aucune sauvegarde d'un réplica avec le rôle CA n'existe.
Il est essentiel d'effectuer des sauvegardes à partir d'un réplica ayant le rôle d'autorité de certification afin de protéger les données des certificats. Pour plus d'informations sur la création et la restauration de sauvegardes, voir Préparation à la perte de données avec les sauvegardes IdM.
Procédure
- À partir d'une autre réplique de votre environnement, faites en sorte qu'une autre réplique de l'autorité de certification de l'environnement agisse en tant que nouveau serveur de renouvellement de l'autorité de certification. Voir Modification et réinitialisation du serveur de renouvellement de l'autorité de certification IdM.
- À partir d'un autre réplica de votre environnement, supprimez les accords de réplication vers le serveur de renouvellement de l'autorité de certification perdu. Voir Suppression d'un serveur de la topologie à l'aide de l'interface de ligne de commande.
- Installez un nouveau réplica CA pour remplacer le réplica CA perdu. Voir Installation d'un réplica IdM avec une autorité de certification.
- Mettre à jour le DNS pour refléter les changements dans la topologie du réplica. Si IdM DNS est utilisé, les enregistrements de service DNS sont mis à jour automatiquement.
- Vérifiez que les clients IdM peuvent atteindre les serveurs IdM. Voir Ajustement des clients IdM pendant la récupération.
Verification steps
Testez le serveur Kerberos sur la nouvelle réplique en récupérant avec succès un Ticket-Granting-Ticket Kerberos en tant qu'utilisateur IdM.
[root@server ~]# kinit admin Password for admin@EXAMPLE.COM: [root@server ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 15:51:37 11/01/2019 15:51:02 HTTP/server.example.com@EXAMPLE.COM 10/31/2019 15:51:08 11/01/2019 15:51:02 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Testez la configuration du serveur d'annuaire et du SSSD en récupérant les informations relatives aux utilisateurs.
[root@server ~]# ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Principal alias: admin@EXAMPLE.COM UID: 1965200000 GID: 1965200000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: TrueTestez la configuration de l'autorité de certification à l'aide de la commande
ipa cert-show.[root@server ~]# ipa cert-show 1 Issuing CA: ipa Certificate: MIIEgjCCAuqgAwIBAgIjoSIP... Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Oct 31 19:43:29 2019 UTC Not After: Mon Oct 31 19:43:29 2039 UTC Serial number: 1 Serial number (hex): 0x1 Revoked: False
Ressources supplémentaires
2.2. Récupération après la perte d'une réplique régulière
Pour remplacer un réplica qui n'est pas le serveur de renouvellement de l'autorité de certification (CA), supprimez le réplica perdu de la topologie et installez un nouveau réplica à sa place.
Conditions préalables
- Le serveur de renouvellement de l'AC fonctionne correctement. Si le serveur de renouvellement de l'autorité de certification a été perdu, voir Récupération après la perte du serveur de renouvellement de l'autorité de certification.
Procédure
- Supprimez les accords de réplication pour le serveur perdu. Voir Désinstallation d'un serveur IdM.
- Déployez un nouveau réplica avec les services souhaités (CA, KRA, DNS). Voir Installation d'une réplique IdM.
- Mettre à jour le DNS pour refléter les changements dans la topologie du réplica. Si IdM DNS est utilisé, les enregistrements de service DNS sont mis à jour automatiquement.
- Vérifiez que les clients IdM peuvent atteindre les serveurs IdM. Voir Ajustement des clients IdM pendant la récupération.
Verification steps
Testez le serveur Kerberos sur la nouvelle réplique en récupérant avec succès un Ticket-Granting-Ticket Kerberos en tant qu'utilisateur IdM.
[root@newreplica ~]# kinit admin Password for admin@EXAMPLE.COM: [root@newreplica ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 15:51:37 11/01/2019 15:51:02 HTTP/server.example.com@EXAMPLE.COM 10/31/2019 15:51:08 11/01/2019 15:51:02 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Testez le serveur d'annuaire et la configuration SSSD sur la nouvelle réplique en récupérant les informations sur les utilisateurs.
[root@newreplica ~]# ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Principal alias: admin@EXAMPLE.COM UID: 1965200000 GID: 1965200000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: True
Chapitre 3. Récupération de plusieurs serveurs par réplication
Si plusieurs serveurs sont perdus en même temps, déterminez si l'environnement peut être reconstruit en examinant lequel des cinq scénarios suivants s'applique à votre situation.
3.1. Récupération après la perte de plusieurs serveurs dans le cadre d'un déploiement sans autorité de certification
Les serveurs dans un déploiement sans AC sont tous considérés comme égaux, vous pouvez donc reconstruire l'environnement en supprimant et en remplaçant les répliques perdues dans n'importe quel ordre.
Conditions préalables
- Votre déploiement utilise une autorité de certification (AC) externe.
Procédure
3.2. Récupération après la perte de plusieurs serveurs lorsque le serveur de renouvellement de l'autorité de certification est indemne
Si le serveur de renouvellement de l'AC est intact, vous pouvez remplacer les autres serveurs dans n'importe quel ordre.
Conditions préalables
- Votre déploiement utilise l'autorité de certification interne de l'IdM.
Procédure
3.3. Récupération après la perte du serveur de renouvellement de l'autorité de certification et d'autres serveurs
Si vous perdez le serveur de renouvellement de l'autorité de certification et d'autres serveurs, faites passer un autre serveur de l'autorité de certification au rôle de serveur de renouvellement de l'autorité de certification avant de remplacer les autres répliques.
Conditions préalables
- Votre déploiement utilise l'autorité de certification interne de l'IdM.
- Au moins une réplique de l'AC est indemne.
Procédure
- Promouvoir un autre réplica de CA pour remplir le rôle de serveur de renouvellement de CA. Voir Récupération après la perte du serveur de renouvellement de l'autorité de certification.
- Remplacez toutes les autres répliques perdues. Voir Récupération après la perte d'un réplica normal.
3.4. Récupération après la perte de toutes les répliques de l'autorité de certification
Sans aucune réplique d'autorité de certification, l'environnement IdM a perdu la capacité de déployer des répliques supplémentaires et de se reconstruire.
Conditions préalables
- Votre déploiement utilise l'autorité de certification interne de l'IdM.
Procédure
- Cette situation est une perte totale.
Ressources supplémentaires
- Pour se préparer à une perte totale de l'infrastructure, voir Préparation à la perte de données avec les snapshots de VM.
3.5. Récupération d'une perte totale d'infrastructure
Si tous les serveurs sont perdus en même temps et qu'il n'y a pas d'instantanés de la machine virtuelle (VM) ou de sauvegardes de données à partir desquelles restaurer, cette situation est irrécupérable.
Procédure
- Cette situation est une perte totale.
Ressources supplémentaires
Chapitre 4. Récupération des données perdues grâce aux instantanés de VM
En cas de perte de données, vous pouvez restaurer un instantané de machine virtuelle (VM) d'une réplique d'autorité de certification (CA) pour réparer les données perdues ou déployer un nouvel environnement à partir de cet instantané.
4.1. Récupération à partir d'un instantané de VM uniquement
Si un sinistre affecte tous les serveurs IdM et qu'il ne reste qu'un instantané d'une machine virtuelle (VM) répliquée de l'autorité de certification IdM, vous pouvez recréer votre déploiement en supprimant toutes les références aux serveurs perdus et en installant de nouvelles répliques.
Conditions préalables
- Vous avez préparé un instantané de VM d'une réplique de VM CA. Voir Préparation à la perte de données avec les snapshots VM.
Procédure
- Démarrez l'instantané souhaité de la réplique de la VM CA.
Supprimez les accords de réplication pour toutes les répliques perdues.
[root@server ~]# ipa server-del lost-server1.example.com [root@server ~]# ipa server-del lost-server2.example.com ...
- Installez un deuxième réplica de CA. Voir Installation d'un réplica IdM avec une autorité de certification.
- Le réplica CA de la VM est maintenant le serveur de renouvellement CA. Red Hat recommande de promouvoir une autre réplique CA dans l'environnement pour qu'elle agisse en tant que serveur de renouvellement CA. Voir Modification et réinitialisation du serveur de renouvellement CA IdM.
- Recréer la topologie de réplique souhaitée en déployant des répliques supplémentaires avec les services souhaités (CA, DNS). Voir Installation d'un réplica IdM
- Mettre à jour le DNS pour refléter la nouvelle topologie des répliques. Si IdM DNS est utilisé, les enregistrements de service DNS sont mis à jour automatiquement.
- Vérifiez que les clients IdM peuvent atteindre les serveurs IdM. Voir Ajustement des clients IdM pendant la récupération.
Verification steps
Testez le serveur Kerberos sur chaque réplique en récupérant avec succès un ticket Kerberos en tant qu'utilisateur IdM.
[root@server ~]# kinit admin Password for admin@EXAMPLE.COM: [root@server ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 15:51:37 11/01/2019 15:51:02 HTTP/server.example.com@EXAMPLE.COM 10/31/2019 15:51:08 11/01/2019 15:51:02 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Testez le serveur d'annuaire et la configuration SSSD sur chaque réplique en récupérant les informations sur les utilisateurs.
[root@server ~]# ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Principal alias: admin@EXAMPLE.COM UID: 1965200000 GID: 1965200000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: TrueTestez le serveur CA sur chaque réplique CA à l'aide de la commande
ipa cert-show.[root@server ~]# ipa cert-show 1 Issuing CA: ipa Certificate: MIIEgjCCAuqgAwIBAgIjoSIP... Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Oct 31 19:43:29 2019 UTC Not After: Mon Oct 31 19:43:29 2039 UTC Serial number: 1 Serial number (hex): 0x1 Revoked: False
Ressources supplémentaires
4.2. Récupération d'un instantané de VM dans un environnement partiellement fonctionnel
Si un sinistre affecte certains serveurs IdM alors que d'autres fonctionnent encore correctement, il se peut que vous souhaitiez restaurer le déploiement à l'état capturé dans un instantané de machine virtuelle (VM). Par exemple, si toutes les répliques d'autorité de certification (CA) sont perdues alors que d'autres répliques sont encore en production, vous devrez ramener une réplique de CA dans l'environnement.
Dans ce scénario, supprimez les références aux répliques perdues, restaurez la réplique CA à partir de l'instantané, vérifiez la réplication et déployez de nouvelles répliques.
Conditions préalables
- Vous avez préparé un instantané de VM d'une réplique de VM CA. Voir Préparation à la perte de données avec les snapshots VM.
Procédure
- Supprimez tous les accords de réplication vers les serveurs perdus. Voir Désinstallation d'un serveur IdM.
- Démarrez l'instantané souhaité de la réplique de la VM CA.
Supprimez tout accord de réplication entre le serveur restauré et les serveurs perdus.
[root@restored-CA-replica ~]# ipa server-del lost-server1.example.com [root@restored-CA-replica ~]# ipa server-del lost-server2.example.com ...
Si le serveur restauré n'a pas d'accords de réplication avec l'un des serveurs encore en production, connectez le serveur restauré à l'un des autres serveurs pour mettre à jour le serveur restauré.
[root@restored-CA-replica ~]# ipa topologysegment-add Suffix name: domain Left node: restored-CA-replica.example.com Right node: server3.example.com Segment name [restored-CA-replica.com-to-server3.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: restored-CA-replica.example.com Right node: server3.example.com Connectivity: both
-
Examinez les journaux d'erreurs du serveur d'annuaire à l'adresse
/var/log/dirsrv/slapd-YOUR-INSTANCE/errorspour voir si la réplique de l'autorité de certification de l'instantané se synchronise correctement avec les autres serveurs IdM. Si la réplication sur le serveur restauré échoue parce que sa base de données est trop obsolète, réinitialisez le serveur restauré.
[root@restored-CA-replica ~]# ipa-replica-manage re-initialize --from server2.example.com- Si la base de données sur le serveur restauré est correctement synchronisée, continuez en déployant des répliques supplémentaires avec les services souhaités (CA, DNS) conformément à la section Installation d'une réplique IdM.
Verification steps
Testez le serveur Kerberos sur chaque réplique en récupérant avec succès un ticket Kerberos en tant qu'utilisateur IdM.
[root@server ~]# kinit admin Password for admin@EXAMPLE.COM: [root@server ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 15:51:37 11/01/2019 15:51:02 HTTP/server.example.com@EXAMPLE.COM 10/31/2019 15:51:08 11/01/2019 15:51:02 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Testez le serveur d'annuaire et la configuration SSSD sur chaque réplique en récupérant les informations sur les utilisateurs.
[root@server ~]# ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Principal alias: admin@EXAMPLE.COM UID: 1965200000 GID: 1965200000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: TrueTestez le serveur CA sur chaque réplique CA à l'aide de la commande
ipa cert-show.[root@server ~]# ipa cert-show 1 Issuing CA: ipa Certificate: MIIEgjCCAuqgAwIBAgIjoSIP... Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Oct 31 19:43:29 2019 UTC Not After: Mon Oct 31 19:43:29 2039 UTC Serial number: 1 Serial number (hex): 0x1 Revoked: False
Ressources supplémentaires
4.3. Récupération d'un snapshot de VM pour établir un nouvel environnement IdM
Si le réplica de l'autorité de certification (CA) à partir d'un snapshot de machine virtuelle (VM) restauré ne peut pas se répliquer avec d'autres serveurs, créez un nouvel environnement IdM à partir du snapshot de VM.
Pour établir un nouvel environnement IdM, isolez le serveur VM, créez des répliques supplémentaires à partir de celui-ci et basculez les clients IdM dans le nouvel environnement.
Conditions préalables
- Vous avez préparé un instantané de VM d'une réplique de VM CA. Voir Préparation à la perte de données avec les snapshots VM.
Procédure
- Démarrez l'instantané souhaité de la réplique de la VM CA.
Isoler le serveur restauré du reste du déploiement actuel en supprimant tous ses segments de topologie de réplication.
Tout d'abord, affichez tous les segments de topologie de réplication
domain.[root@restored-CA-replica ~]# ipa topologysegment-find Suffix name: domain ------------------ 8 segments matched ------------------ Segment name: new_segment Left node: restored-CA-replica.example.com Right node: server2.example.com Connectivity: both ... ---------------------------- Number of entries returned 8 ----------------------------
Ensuite, supprimez tous les segments de la topologie
domainimpliquant le serveur restauré.[root@restored-CA-replica ~]# ipa topologysegment-del Suffix name: domain Segment name: new_segment ----------------------------- Deleted segment "new_segment" -----------------------------
Enfin, effectuez les mêmes opérations avec tous les segments de la topologie
ca.[root@restored-CA-replica ~]# ipa topologysegment-find Suffix name: ca ------------------ 1 segments matched ------------------ Segment name: ca_segment Left node: restored-CA-replica.example.com Right node: server4.example.com Connectivity: both ---------------------------- Number of entries returned 1 ---------------------------- [root@restored-CA-replica ~]# ipa topologysegment-del Suffix name: ca Segment name: ca_segment ----------------------------- Deleted segment "ca_segment" -----------------------------
- Installez un nombre suffisant de répliques IdM à partir du serveur restauré pour gérer la charge de déploiement. Il y a maintenant deux déploiements IdM déconnectés fonctionnant en parallèle.
- Commuter les clients IdM pour utiliser le nouveau déploiement en codant en dur les références aux nouvelles répliques IdM. Voir Ajustement des clients IdM pendant la récupération.
- Arrêter et désinstaller les serveurs IdM du déploiement précédent. Voir Désinstallation d'un serveur IdM.
Verification steps
Testez le serveur Kerberos sur chaque nouvelle réplique en récupérant avec succès un ticket Kerberos en tant qu'utilisateur IdM.
[root@server ~]# kinit admin Password for admin@EXAMPLE.COM: [root@server ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 15:51:37 11/01/2019 15:51:02 HTTP/server.example.com@EXAMPLE.COM 10/31/2019 15:51:08 11/01/2019 15:51:02 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Testez le serveur d'annuaire et la configuration SSSD sur chaque nouvelle réplique en récupérant les informations relatives aux utilisateurs.
[root@server ~]# ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Principal alias: admin@EXAMPLE.COM UID: 1965200000 GID: 1965200000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: TrueTestez le serveur CA sur chaque nouvelle réplique CA à l'aide de la commande
ipa cert-show.[root@server ~]# ipa cert-show 1 Issuing CA: ipa Certificate: MIIEgjCCAuqgAwIBAgIjoSIP... Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Oct 31 19:43:29 2019 UTC Not After: Mon Oct 31 19:43:29 2039 UTC Serial number: 1 Serial number (hex): 0x1 Revoked: False
Chapitre 5. Récupérer les données perdues grâce aux sauvegardes IdM
Vous pouvez utiliser l'utilitaire ipa-restore pour restaurer un serveur IdM à un état antérieur capturé dans une sauvegarde IdM.
5.1. Quand restaurer à partir d'une sauvegarde IdM
Vous pouvez répondre à plusieurs scénarios de désastre en restaurant à partir d'une sauvegarde IdM :
- Undesirable changes were made to the LDAP content: Des entrées ont été modifiées ou supprimées, la réplication a effectué ces changements tout au long du déploiement et vous souhaitez revenir sur ces modifications. La restauration d'une sauvegarde de données uniquement permet de rétablir l'état antérieur des entrées LDAP sans affecter la configuration IdM elle-même.
- Total Infrastructure Loss, or loss of all CA instances: Si un sinistre endommage toutes les répliques d'autorité de certification, le déploiement a perdu la capacité de se reconstruire en déployant des serveurs supplémentaires. Dans ce cas, il faut restaurer une sauvegarde d'une réplique d'autorité de certification et construire de nouvelles répliques à partir de celle-ci.
An upgrade on an isolated server failed: Le système d'exploitation reste fonctionnel, mais les données IdM sont corrompues, c'est pourquoi vous souhaitez restaurer le système IdM dans un état de bon fonctionnement connu. Red Hat recommande de travailler avec le support technique pour diagnostiquer et résoudre le problème. Si ces efforts échouent, restaurez à partir d'une sauvegarde complète du serveur.
ImportantLa solution préférée en cas de défaillance matérielle ou de mise à niveau consiste à reconstruire le serveur perdu à partir d'un réplica. Pour plus d'informations, voir Récupération d'un serveur unique avec réplication.
5.2. Considérations à prendre en compte lors de la restauration à partir d'une sauvegarde IdM
Si vous disposez d'une sauvegarde créée avec l'utilitaire ipa-backup, vous pouvez restaurer votre serveur IdM ou le contenu LDAP dans l'état où ils se trouvaient lorsque la sauvegarde a été effectuée.
Voici les principales considérations à prendre en compte lors de la restauration d'une sauvegarde IdM :
Vous ne pouvez restaurer une sauvegarde que sur un serveur dont la configuration correspond à celle du serveur sur lequel la sauvegarde a été créée à l'origine. Le serveur must a :
- Le même nom d'hôte
- La même adresse IP
- La même version du logiciel IdM
- Si un serveur IdM parmi d'autres est restauré, le serveur restauré devient la seule source d'information pour IdM. Tous les autres serveurs must sont réinitialisés à partir du serveur restauré.
- Étant donné que toutes les données créées après la dernière sauvegarde seront perdues, n'utilisez pas la solution de sauvegarde et de restauration pour la maintenance normale du système.
- Si un serveur est perdu, Red Hat recommande de reconstruire le serveur en le réinstallant en tant que réplique, au lieu de le restaurer à partir d'une sauvegarde. La création d'une nouvelle réplique préserve les données de l'environnement de travail actuel. Pour plus d'informations, voir Préparation à la perte d'un serveur avec la réplication.
- Les fonctions de sauvegarde et de restauration ne peuvent être gérées qu'à partir de la ligne de commande et ne sont pas disponibles dans l'interface web de l'IdM.
-
Vous ne pouvez pas restaurer des fichiers de sauvegarde situés dans les répertoires
/tmpou/var/tmp. Le serveur d'annuaire IdM utilise un répertoire PrivateTmp et ne peut pas accéder aux répertoires/tmpou/var/tmpgénéralement disponibles pour le système d'exploitation.
La restauration à partir d'une sauvegarde nécessite les mêmes versions de logiciels (RPM) sur l'hôte cible que celles qui ont été installées lorsque la sauvegarde a été effectuée. Pour cette raison, Red Hat recommande de restaurer à partir d'un instantané de machine virtuelle plutôt qu'à partir d'une sauvegarde. Pour plus d'informations, voir Récupérer des données perdues avec des snapshots de VM.
5.3. Restauration d'un serveur IdM à partir d'une sauvegarde
La procédure suivante décrit la restauration d'un serveur IdM ou de ses données LDAP à partir d'une sauvegarde IdM.
Figure 5.1. Topologie de réplication utilisée dans cet exemple
Tableau 5.1. Conventions de dénomination des serveurs utilisées dans cet exemple
| Nom d'hôte du serveur | Fonction |
|---|---|
|
| Le serveur qui doit être restauré à partir de la sauvegarde. |
|
|
Une réplique de l'autorité de certification (CA) connectée à l'hôte |
|
|
Une réplique connectée à l'hôte |
Conditions préalables
-
Vous avez généré une sauvegarde complète du serveur ou des données uniquement du serveur IdM à l'aide de l'utilitaire
ipa-backup. Voir Création d'une sauvegarde. -
Vos fichiers de sauvegarde ne se trouvent pas dans les répertoires
/tmpou/var/tmp. - Avant d'effectuer une restauration complète du serveur à partir d'une sauvegarde complète du serveur, désinstallez IdM du serveur et réinstallez IdM en utilisant la même configuration de serveur qu'auparavant.
Procédure
Utilisez l'utilitaire
ipa-restorepour restaurer un serveur complet ou une sauvegarde de données uniquement.Si le répertoire de sauvegarde se trouve dans l'emplacement par défaut
/var/lib/ipa/backup/, saisissez uniquement le nom du répertoire :[root@server1 ~]# ipa-restore ipa-full-2020-01-14-12-02-32Si le répertoire de sauvegarde ne se trouve pas à l'emplacement par défaut, saisissez son chemin d'accès complet :
[root@server1 ~]# ipa-restore /mybackups/ipa-data-2020-02-01-05-30-00NoteL'utilitaire
ipa-restoredétecte automatiquement le type de sauvegarde que le répertoire contient et effectue le même type de restauration par défaut. Pour effectuer une restauration de données uniquement à partir d'une sauvegarde complète du serveur, ajoutez l'option--dataà la commandeipa-restore:[root@server1 ~]# ipa-restore --data ipa-full-2020-01-14-12-02-32
Saisissez le mot de passe du gestionnaire de répertoire.
Mot de passe du gestionnaire d'annuaire (maître existant) :
Entrez
yespour confirmer l'écrasement des données actuelles par la sauvegarde.Preparing restore from /var/lib/ipa/backup/ipa-full-2020-01-14-12-02-32 on server1.example.com Performing FULL restore from FULL backup Temporary setting umask to 022 Restoring data will overwrite existing live data. Continue to restore? [no]: yesL'utilitaire
ipa-restoredésactive la réplication sur tous les serveurs disponibles :Each master will individually need to be re-initialized or re-created from this one. The replication agreements on masters running IPA 3.1 or earlier will need to be manually re-enabled. See the man page for details. Disabling all replication. Disabling replication agreement on server1.example.com to caReplica2.example.com Disabling CA replication agreement on server1.example.com to caReplica2.example.com Disabling replication agreement on caReplica2.example.com to server1.example.com Disabling replication agreement on caReplica2.example.com to replica3.example.com Disabling CA replication agreement on caReplica2.example.com to server1.example.com Disabling replication agreement on replica3.example.com to caReplica2.example.com
L'utilitaire arrête ensuite les services IdM, restaure la sauvegarde et redémarre les services :
Stopping IPA services Systemwide CA database updated. Restoring files Systemwide CA database updated. Restoring from userRoot in EXAMPLE-COM Restoring from ipaca in EXAMPLE-COM Restarting GSS-proxy Starting IPA services Restarting SSSD Restarting oddjobd Restoring umask to 18 The ipa-restore command was successfulRéinitialiser toutes les répliques connectées au serveur restauré :
Listez tous les segments de topologie de réplication pour le suffixe
domain, en prenant note des segments de topologie impliquant le serveur restauré.[root@server1 ~]# ipa topologysegment-find domain ------------------ 2 segments matched ------------------ Segment name: server1.example.com-to-caReplica2.example.com Left node: server1.example.com Right node: caReplica2.example.com Connectivity: both Segment name: caReplica2.example.com-to-replica3.example.com Left node: caReplica2.example.com Right node: replica3.example.com Connectivity: both ---------------------------- Number of entries returned 2 ----------------------------
Réinitialisez le suffixe
domainpour tous les segments de la topologie avec le serveur restauré.Dans cet exemple, il s'agit de réinitialiser
caReplica2avec des données provenant deserver1.[root@caReplica2 ~]# ipa-replica-manage re-initialize --from=server1.example.com Update in progress, 2 seconds elapsed Update succeededEn ce qui concerne les données relatives à l'autorité de certification, dressez la liste de tous les segments de la topologie de réplication pour le suffixe
ca.[root@server1 ~]# ipa topologysegment-find ca ----------------- 1 segment matched ----------------- Segment name: server1.example.com-to-caReplica2.example.com Left node: server1.example.com Right node: caReplica2.example.com Connectivity: both ---------------------------- Number of entries returned 1 ----------------------------
Réinitialisez toutes les répliques de CA connectées au serveur restauré.
Dans cet exemple, nous effectuons une réinitialisation de
csreplicaà partir decaReplica2avec des données provenant deserver1.[root@caReplica2 ~]# ipa-csreplica-manage re-initialize --from=server1.example.com Directory Manager password: Update in progress, 3 seconds elapsed Update succeeded
Continuez à vous déplacer vers l'extérieur dans la topologie de réplication, en réinitialisant les répliques successives, jusqu'à ce que tous les serveurs aient été mis à jour avec les données du serveur restauré
server1.example.com.Dans cet exemple, il suffit de réinitialiser le suffixe
domainsurreplica3avec les données decaReplica2:[root@replica3 ~]# ipa-replica-manage re-initialize --from=caReplica2.example.com Directory Manager password: Update in progress, 3 seconds elapsed Update succeededVider le cache de SSSD sur chaque serveur pour éviter les problèmes d'authentification dus à des données non valides :
Arrêtez le service SSSD :
[root@server ~]# systemctl stop sssdSupprimer tout le contenu mis en cache du SSSD :
[root@server ~]# sss_cache -EDémarrez le service SSSD :
[root@server ~]# systemctl start sssd- Redémarrer le serveur.
Ressources supplémentaires
-
La page de manuel
ipa-restore (1)couvre également en détail la manière de gérer les scénarios de réplication complexes lors de la restauration.
5.4. Restauration à partir d'une sauvegarde cryptée
Cette procédure permet de restaurer un serveur IdM à partir d'une sauvegarde IdM cryptée. L'utilitaire ipa-restore détecte automatiquement si une sauvegarde IdM est cryptée et la restaure à l'aide du trousseau de clés racine GPG2.
Conditions préalables
- Une sauvegarde IdM chiffrée par GPG. Voir Création de sauvegardes IdM cryptées.
- Le mot de passe du gestionnaire de répertoire LDAP
- La phrase de passe utilisée lors de la création de la clé GPG
Procédure
Si vous avez utilisé un emplacement de trousseau personnalisé lors de la création des clés GPG2, assurez-vous que la variable d'environnement
$GNUPGHOMEest définie sur ce répertoire. Voir Création d'une clé GPG2.[root@server ~]# echo $GNUPGHOME /root/backup
Indiquez à l'utilitaire
ipa-restorel'emplacement du répertoire de sauvegarde.[root@server ~]# ipa-restore ipa-full-2020-01-13-18-30-54Saisissez le mot de passe du gestionnaire de répertoire.
Mot de passe du gestionnaire d'annuaire (maître existant) :
Saisissez la phrase de passe que vous avez utilisée lors de la création de la clé GPG.
┌────────────────────────────────────────────────────────────────┐ │ Please enter the passphrase to unlock the OpenPGP secret key: │ │ "GPG User (first key) <root@example.com>" │ │ 2048-bit RSA key, ID BF28FFA302EF4557, │ │ created 2020-01-13. │ │ │ │ │ │ Passphrase: <passphrase> │ │ │ │ <OK> <Cancel> │ └────────────────────────────────────────────────────────────────┘
- Réinitialisez toutes les répliques connectées au serveur restauré. Voir Restauration d'un serveur IdM à partir d'une sauvegarde.
Chapitre 6. Restauration des serveurs IdM à l'aide de playbooks Ansible
En utilisant le rôle Ansible ipabackup, vous pouvez automatiser la restauration d'un serveur IdM à partir d'une sauvegarde et le transfert de fichiers de sauvegarde entre les serveurs et votre contrôleur Ansible.
Cette section couvre les sujets suivants :
- Préparation du nœud de contrôle Ansible pour la gestion de l'IdM
- Utiliser Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur le serveur
- Utiliser Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur votre contrôleur Ansible
- Utiliser Ansible pour copier une sauvegarde d'un serveur IdM sur votre contrôleur Ansible
- Utilisation d'Ansible pour copier une sauvegarde d'un serveur IdM depuis votre contrôleur Ansible vers le serveur IdM
- Utiliser Ansible pour supprimer une sauvegarde d'un serveur IdM
6.1. Préparation du nœud de contrôle Ansible pour la gestion de l'IdM
En tant qu'administrateur système gérant la gestion des identités (IdM), lorsque vous travaillez avec Red Hat Ansible Engine, il est recommandé de procéder comme suit :
- Créez un sous-répertoire dédié aux playbooks Ansible dans votre répertoire personnel, par exemple ~/MyPlaybooks.
-
Copiez et adaptez les exemples de playbooks Ansible des répertoires et sous-répertoires
/usr/share/doc/ansible-freeipa/*et/usr/share/doc/rhel-system-roles/*dans votre répertoire ~/MyPlaybooks. - Incluez votre fichier d'inventaire dans votre répertoire ~/MyPlaybooks.
En suivant cette pratique, vous pouvez trouver tous vos playbooks en un seul endroit et vous pouvez exécuter vos playbooks sans invoquer les privilèges root.
Vous n'avez besoin que des privilèges root sur les nœuds gérés pour exécuter les rôles ipaserver, ipareplica, ipaclient, ipabackup, ipasmartcard_server et ipasmartcard_client ansible-freeipa . Ces rôles nécessitent un accès privilégié aux répertoires et au gestionnaire de paquets logiciels dnf.
Cette section décrit comment créer le répertoire ~/MyPlaybooks et le configurer de manière à ce que vous puissiez l'utiliser pour stocker et exécuter des playbooks Ansible.
Conditions préalables
- Vous avez installé un serveur IdM sur vos nœuds gérés, server.idm.example.com et replica.idm.example.com.
- Vous avez configuré le DNS et le réseau pour pouvoir vous connecter aux nœuds gérés, server.idm.example.com et replica.idm.example.comdirectement à partir du nœud de contrôle.
-
Vous connaissez le mot de passe de l'IdM
admin.
Procédure
Créez un répertoire pour votre configuration Ansible et vos playbooks dans votre répertoire personnel :
$ mkdir ~/MyPlaybooks/Allez dans le répertoire ~/MyPlaybooks/:
$ cd ~/MyPlaybooksCréez le fichier ~/MyPlaybooks/ansible.cfg avec le contenu suivant :
[defaults] inventory = /home/your_username/MyPlaybooks/inventory [privilege_escalation] become=TrueCréez le fichier ~/MyPlaybooks/inventory avec le contenu suivant :
[ipaserver] server.idm.example.com [ipareplicas] replica1.idm.example.com replica2.idm.example.com [ipacluster:children] ipaserver ipareplicas [ipacluster:vars] ipaadmin_password=SomeADMINpassword [ipaclients] ipaclient1.example.com ipaclient2.example.com [ipaclients:vars] ipaadmin_password=SomeADMINpassword
Cette configuration définit deux groupes d'hôtes, eu et us, pour les hôtes de ces sites. En outre, cette configuration définit le groupe d'hôtes ipaserver, qui contient tous les hôtes des groupes eu et us.
[Facultatif] Créez une clé publique et une clé privée SSH. Pour simplifier l'accès dans votre environnement de test, ne définissez pas de mot de passe pour la clé privée :
$ ssh-keygenCopiez la clé publique SSH dans le compte IdM
adminsur chaque nœud géré :$ ssh-copy-id admin@server.idm.example.com $ ssh-copy-id admin@replica.idm.example.com
Vous devez saisir le mot de passe IdM
adminlorsque vous entrez dans ces commandes.
Ressources supplémentaires
6.2. Utiliser Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur le serveur
La procédure suivante décrit comment utiliser un playbook Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur cet hôte.
Conditions préalables
Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :
- Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipasur le contrôleur Ansible. - L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
-
L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre
ipaadmin_password. - Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipa. - Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez ces options.
-
Votre fichier d'inventaire Ansible est situé dans le répertoire
~/MyPlaybooks/.
- Vous connaissez le mot de passe du gestionnaire de répertoire LDAP.
Procédure
Naviguez jusqu'au répertoire
~/MyPlaybooks/:$ cd ~/MyPlaybooks/
Faites une copie du fichier
restore-server.ymlsitué dans le répertoire/usr/share/doc/ansible-freeipa/playbooks:$ cp /usr/share/doc/ansible-freeipa/playbooks/restore-server.yml restore-my-server.yml
-
Ouvrez le fichier
restore-my-server.ymlAnsible playbook pour l'éditer. Adaptez le fichier en définissant les variables suivantes :
-
Définissez la variable
hostssur un groupe d'hôtes de votre fichier d'inventaire. Dans cet exemple, il s'agit du groupe d'hôtesipaserver. -
Attribuez à la variable
ipabackup_namele nom du siteipabackupà restaurer. Définissez la variable
ipabackup_passwordavec le mot de passe du gestionnaire d'annuaire LDAP.--- - name: Playbook to restore an IPA server hosts: ipaserver become: true vars: ipabackup_name: ipa-full-2021-04-30-13-12-00 ipabackup_password: <your_LDAP_DM_password> roles: - role: ipabackup state: restored
-
Définissez la variable
- Enregistrer le fichier.
Exécutez le playbook Ansible en spécifiant le fichier d'inventaire et le fichier du playbook :
$ ansible-playbook --vault-password-file=password_file -v -i ~/MyPlaybooks/inventory restore-my-server.yml
Ressources supplémentaires
-
Le fichier
README.mddans le répertoire/usr/share/doc/ansible-freeipa/roles/ipabackup. -
Le répertoire
/usr/share/doc/ansible-freeipa/playbooks/.
6.3. Utiliser Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur votre contrôleur Ansible
La procédure suivante décrit comment utiliser un playbook Ansible pour restaurer un serveur IdM à partir d'une sauvegarde stockée sur votre contrôleur Ansible.
Conditions préalables
Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :
- Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipasur le contrôleur Ansible. - L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
-
L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre
ipaadmin_password. - Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipa. - Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez ces options.
-
Votre fichier d'inventaire Ansible est situé dans le répertoire
~/MyPlaybooks/.
- Vous connaissez le mot de passe du gestionnaire de répertoire LDAP.
Procédure
Naviguez jusqu'au répertoire
~/MyPlaybooks/:$ cd ~/MyPlaybooks/
Faites une copie du fichier
restore-server-from-controller.ymlsitué dans le répertoire/usr/share/doc/ansible-freeipa/playbooks:$ cp /usr/share/doc/ansible-freeipa/playbooks/restore-server-from-controller.yml restore-my-server-from-my-controller.yml
-
Ouvrez le fichier
restore-my-server-from-my-controller.ymlpour le modifier. Adaptez le fichier en définissant les variables suivantes :
-
Définissez la variable
hostssur un groupe d'hôtes de votre fichier d'inventaire. Dans cet exemple, il s'agit du groupe d'hôtesipaserver. -
Attribuez à la variable
ipabackup_namele nom du siteipabackupà restaurer. Définissez la variable
ipabackup_passwordavec le mot de passe du gestionnaire d'annuaire LDAP.--- - name: Playbook to restore IPA server from controller hosts: ipaserver become: true vars: ipabackup_name: server.idm.example.com_ipa-full-2021-04-30-13-12-00 ipabackup_password: <your_LDAP_DM_password> ipabackup_from_controller: yes roles: - role: ipabackup state: restored
-
Définissez la variable
- Enregistrer le fichier.
Exécutez le playbook Ansible, en spécifiant le fichier d'inventaire et le fichier du playbook :
$ ansible-playbook --vault-password-file=password_file -v -i ~/MyPlaybooks/inventory restore-my-server-from-my-controller.yml
Ressources supplémentaires
-
Le fichier
README.mddans le répertoire/usr/share/doc/ansible-freeipa/roles/ipabackup. -
Le répertoire
/usr/share/doc/ansible-freeipa/playbooks/.
6.4. Utiliser Ansible pour copier une sauvegarde d'un serveur IdM sur votre contrôleur Ansible
La procédure suivante décrit comment utiliser un playbook Ansible pour copier une sauvegarde d'un serveur IdM depuis le serveur IdM vers votre contrôleur Ansible.
Conditions préalables
Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :
- Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipasur le contrôleur Ansible. - L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
-
L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre
ipaadmin_password. - Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipa. - Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez ces options.
-
Votre fichier d'inventaire Ansible est situé dans le répertoire
~/MyPlaybooks/.
Procédure
Pour stocker les sauvegardes, créez un sous-répertoire dans votre répertoire personnel sur le contrôleur Ansible.
$ mkdir ~/ipabackups
Naviguez jusqu'au répertoire
~/MyPlaybooks/:$ cd ~/MyPlaybooks/
Faites une copie du fichier
copy-backup-from-server.ymlsitué dans le répertoire/usr/share/doc/ansible-freeipa/playbooks:$ cp /usr/share/doc/ansible-freeipa/playbooks/copy-backup-from-server.yml copy-backup-from-my-server-to-my-controller.yml
-
Ouvrez le fichier
copy-my-backup-from-my-server-to-my-controller.ymlpour le modifier. Adaptez le fichier en définissant les variables suivantes :
-
Définissez la variable
hostssur un groupe d'hôtes de votre fichier d'inventaire. Dans cet exemple, il s'agit du groupe d'hôtesipaserver. -
Définissez la variable
ipabackup_nameavec le nom deipabackupsur votre serveur IdM à copier dans votre contrôleur Ansible. Par défaut, les sauvegardes sont stockées dans le répertoire de travail actuel du contrôleur Ansible. Pour spécifier le répertoire que vous avez créé à l'étape 1, ajoutez la variable
ipabackup_controller_pathet définissez-la sur le répertoire/home/user/ipabackups.--- - name: Playbook to copy backup from IPA server hosts: ipaserver become: true vars: ipabackup_name: ipa-full-2021-04-30-13-12-00 ipabackup_to_controller: yes ipabackup_controller_path: /home/user/ipabackups roles: - role: ipabackup state: present
-
Définissez la variable
- Enregistrer le fichier.
Exécutez le playbook Ansible, en spécifiant le fichier d'inventaire et le fichier du playbook :
$ ansible-playbook --vault-password-file=password_file -v -i ~/MyPlaybooks/inventory copy-backup-from-my-server-to-my-controller.yml
Pour copier les sauvegardes de all IdM sur votre contrôleur, définissez la variable ipabackup_name dans Ansible playbook à all:
vars:
ipabackup_name: all
ipabackup_to_controller: yes
Pour un exemple, voir le playbook Ansible copy-all-backups-from-server.yml dans le répertoire /usr/share/doc/ansible-freeipa/playbooks.
Verification steps
Vérifiez que votre sauvegarde se trouve dans le répertoire
/home/user/ipabackupssur votre contrôleur Ansible :[user@controller ~]$ ls /home/user/ipabackups server.idm.example.com_ipa-full-2021-04-30-13-12-00
Ressources supplémentaires
-
Le fichier
README.mddans le répertoire/usr/share/doc/ansible-freeipa/roles/ipabackup. -
Le répertoire
/usr/share/doc/ansible-freeipa/playbooks/.
6.5. Utilisation d'Ansible pour copier une sauvegarde d'un serveur IdM depuis votre contrôleur Ansible vers le serveur IdM
La procédure suivante décrit comment utiliser un playbook Ansible pour copier une sauvegarde d'un serveur IdM depuis votre contrôleur Ansible vers le serveur IdM.
Conditions préalables
Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :
- Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipasur le contrôleur Ansible. - L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
-
L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre
ipaadmin_password. - Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipa. - Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez ces options.
-
Votre fichier d'inventaire Ansible est situé dans le répertoire
~/MyPlaybooks/.
Procédure
Naviguez jusqu'au répertoire
~/MyPlaybooks/:$ cd ~/MyPlaybooks/
Faites une copie du fichier
copy-backup-from-controller.ymlsitué dans le répertoire/usr/share/doc/ansible-freeipa/playbooks:$ cp /usr/share/doc/ansible-freeipa/playbooks/copy-backup-from-controller.yml copy-backup-from-my-controller-to-my-server.yml
-
Ouvrez le fichier
copy-my-backup-from-my-controller-to-my-server.ymlpour le modifier. Adaptez le fichier en définissant les variables suivantes :
-
Définissez la variable
hostssur un groupe d'hôtes de votre fichier d'inventaire. Dans cet exemple, il s'agit du groupe d'hôtesipaserver. Définissez la variable
ipabackup_nameavec le nom deipabackupsur votre contrôleur Ansible à copier sur le serveur IdM.--- - name: Playbook to copy a backup from controller to the IPA server hosts: ipaserver become: true vars: ipabackup_name: server.idm.example.com_ipa-full-2021-04-30-13-12-00 ipabackup_from_controller: yes roles: - role: ipabackup state: copied
-
Définissez la variable
- Enregistrer le fichier.
Exécutez le playbook Ansible, en spécifiant le fichier d'inventaire et le fichier du playbook :
$ ansible-playbook --vault-password-file=password_file -v -i ~/MyPlaybooks/inventory copy-backup-from-my-controller-to-my-server.yml
Ressources supplémentaires
-
Le fichier
README.mddans le répertoire/usr/share/doc/ansible-freeipa/roles/ipabackup. -
Le répertoire
/usr/share/doc/ansible-freeipa/playbooks/.
6.6. Utiliser Ansible pour supprimer une sauvegarde d'un serveur IdM
La procédure suivante décrit comment utiliser un playbook Ansible pour supprimer une sauvegarde d'un serveur IdM.
Conditions préalables
Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :
- Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipasur le contrôleur Ansible. - L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
-
L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre
ipaadmin_password. - Vous utilisez la version 2.8 ou ultérieure d'Ansible.
-
Vous avez installé le paquetage
ansible-freeipa. - Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM sur lequel vous configurez ces options.
-
Votre fichier d'inventaire Ansible est situé dans le répertoire
~/MyPlaybooks/.
Procédure
Naviguez jusqu'au répertoire ~/MyPlaybooks/ :
$ cd ~/MyPlaybooks/
Faites une copie du fichier
remove-backup-from-server.ymlsitué dans le répertoire/usr/share/doc/ansible-freeipa/playbooks:$ cp /usr/share/doc/ansible-freeipa/playbooks/remove-backup-from-server.yml remove-backup-from-my-server.yml
-
Ouvrez le fichier
remove-backup-from-my-server.ymlpour le modifier. Adaptez le fichier en définissant les variables suivantes :
-
Définissez la variable
hostssur un groupe d'hôtes de votre fichier d'inventaire. Dans cet exemple, il s'agit du groupe d'hôtesipaserver. Attribuez à la variable
ipabackup_namele nom du siteipabackupà supprimer de votre serveur IdM.--- - name: Playbook to remove backup from IPA server hosts: ipaserver become: true vars: ipabackup_name: ipa-full-2021-04-30-13-12-00 roles: - role: ipabackup state: absent
-
Définissez la variable
- Enregistrer le fichier.
Exécutez le playbook Ansible, en spécifiant le fichier d'inventaire et le fichier du playbook :
$ ansible-playbook --vault-password-file=password_file -v -i ~/MyPlaybooks/inventory remove-backup-from-my-server.yml
Pour supprimer les sauvegardes all IdM du serveur IdM, définissez la variable ipabackup_name dans le carnet de commande Ansible à all:
vars:
ipabackup_name: all
Pour un exemple, voir le playbook Ansible remove-all-backups-from-server.yml dans le répertoire /usr/share/doc/ansible-freeipa/playbooks.
Ressources supplémentaires
-
Le fichier
README.mddans le répertoire/usr/share/doc/ansible-freeipa/roles/ipabackup. -
Le répertoire
/usr/share/doc/ansible-freeipa/playbooks/.
Chapitre 7. Gérer la perte de données
La réponse appropriée à une perte de données dépend du nombre de répliques affectées et du type de données perdues.
7.1. Réagir à une perte de données isolée
Lorsqu'une perte de données se produit, minimisez la réplication de la perte de données en isolant immédiatement les serveurs affectés. Créez ensuite des répliques de remplacement à partir du reste de l'environnement non affecté.
Conditions préalables
- Une topologie de réplication IdM robuste avec plusieurs répliques. Voir Préparation à la perte d'un serveur avec réplication.
Procédure
Pour limiter la réplication de la perte de données, déconnectez toutes les répliques concernées du reste de la topologie en supprimant leurs segments de topologie de réplication.
Affichez tous les segments de topologie de réplication
domaindans le déploiement.[root@server ~]# ipa topologysegment-find Suffix name: domain ------------------ 8 segments matched ------------------ Segment name: segment1 Left node: server.example.com Right node: server2.example.com Connectivity: both ... ---------------------------- Number of entries returned 8 ----------------------------
Supprimez tous les segments de la topologie
domainimpliquant les serveurs concernés.[root@server ~]# ipa topologysegment-del Suffix name: domain Segment name: segment1 ----------------------------- Deleted segment "segment1" -----------------------------
Effectuez les mêmes actions avec tous les segments de la topologie
caimpliquant des serveurs affectés.[root@server ~]# ipa topologysegment-find Suffix name: ca ------------------ 1 segments matched ------------------ Segment name: ca_segment Left node: server.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 1 ---------------------------- [root@server ~]# ipa topologysegment-del Suffix name: ca Segment name: ca_segment ----------------------------- Deleted segment "ca_segment" -----------------------------
- Les serveurs affectés par la perte de données doivent être abandonnés. Pour créer des répliques de remplacement, voir Récupération de plusieurs serveurs à l'aide de la réplication.
7.2. Réponse à une perte de données limitée sur l'ensemble des serveurs
Une perte de données peut affecter toutes les répliques de l'environnement, par exemple si la réplication effectue une suppression accidentelle sur tous les serveurs. Si la perte de données est connue et limitée, réajoutez manuellement les données perdues.
Conditions préalables
- Un instantané de machine virtuelle (VM) ou une sauvegarde IdM d'un serveur IdM contenant les données perdues.
Procédure
- Si vous avez besoin de revoir les données perdues, restaurez l'instantané ou la sauvegarde de la VM sur un serveur isolé sur un réseau distinct.
-
Ajoutez les informations manquantes à la base de données en utilisant les commandes
ipaouldapadd.
Ressources supplémentaires
7.3. Réponse à une perte de données non définie sur l'ensemble des serveurs
Si la perte de données est importante ou indéfinie, déployez un nouvel environnement à partir d'un instantané de machine virtuelle (VM) d'un serveur.
Conditions préalables
- Un instantané de machine virtuelle (VM) contient les données perdues.
Procédure
- Restaurer une réplique d'autorité de certification (AC) IdM à partir d'un instantané de VM dans un état connu et déployer un nouvel environnement IdM à partir de cette réplique. Voir Récupération à partir d'un instantané de VM uniquement.
-
Ajoutez toutes les données créées après la prise de l'instantané à l'aide des commandes
ipaouldapadd.
Ressources supplémentaires
Chapitre 8. Ajustement des clients IdM pendant la récupération
Pendant la restauration des serveurs IdM, il se peut que vous deviez ajuster les clients IdM pour refléter les changements dans la topologie du réplica.
Procédure
Adjusting DNS configuration:
-
Si
/etc/hostscontient des références à des serveurs IdM, assurez-vous que les correspondances IP-nom d'hôte codées en dur sont valides. -
Si les clients IdM utilisent IdM DNS pour la résolution de noms, assurez-vous que les entrées
nameserverdans/etc/resolv.confpointent vers des répliques IdM opérationnelles fournissant des services DNS.
-
Si
Adjusting Kerberos configuration:
Par défaut, les clients IdM consultent les enregistrements du service DNS pour les serveurs Kerberos et s'adaptent aux changements dans la topologie de la réplique :
[root@client ~]# grep dns_lookup_kdc /etc/krb5.conf dns_lookup_kdc = true
Si les clients IdM ont été codés en dur pour utiliser des serveurs IdM spécifiques dans
/etc/krb5.conf:[root@client ~]# grep dns_lookup_kdc /etc/krb5.conf dns_lookup_kdc = false
assurez-vous que les entrées
kdc,master_kdcetadmin_serverdans/etc/krb5.confpointent vers des serveurs IdM qui fonctionnent correctement :[realms] EXAMPLE.COM = { kdc = functional-server.example.com:88 master_kdc = functional-server.example.com:88 admin_server = functional-server.example.com:749 default_domain = example.com pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem }
Adjusting SSSD configuration:
Par défaut, les clients IdM consultent les enregistrements du service DNS pour les serveurs LDAP et s'adaptent aux changements dans la topologie des répliques :
[root@client ~]# grep ipa_server /etc/sssd/sssd.conf ipa_server = _srv_, functional-server.example.com
Si les clients IdM ont été codés en dur pour utiliser des serveurs IdM spécifiques dans
/etc/sssd/sssd.conf, assurez-vous que les points d'entrée deipa_serverpointent vers des serveurs IdM qui fonctionnent correctement :[root@client ~]# grep ipa_server /etc/sssd/sssd.conf ipa_server = functional-server.example.com
Clearing SSSD’s cached information:
Le cache SSSD peut contenir des informations obsolètes concernant les serveurs perdus. Si les utilisateurs rencontrent des problèmes d'authentification incohérents, purgez le cache SSSD :
[root@client ~]# sss_cache -E
Verification steps
Vérifiez la configuration Kerberos en récupérant un Ticket-Granting-Ticket Kerberos en tant qu'utilisateur IdM.
[root@client ~]# kinit admin Password for admin@EXAMPLE.COM: [root@client ~]# klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 18:44:58 11/25/2019 18:44:55 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Vérifiez la configuration SSSD en récupérant les informations sur l'utilisateur IdM.
[root@client ~]# id admin uid=1965200000(admin) gid=1965200000(admins) groups=1965200000(admins)
