Catégorie : Sauvegarde

Sauvegarde distante dans le Cloud IBM avec restic

Bien que n’ayant subi aucune perte de données, à proprement parler (grâce à la sauvegarde, le serveur étant tout de même parti en fumé), dans l’incendie du datacenter OVH de Strasbourg, je me suis tout de même interrogé sur la pertinence du processus en place. Le système en place est-il suffisant ? Quelles sont ses limites ? Ses faiblesses ? Quels scénarios pourrait mettre en échec toute la politique de sauvegarde: corruption des données, échec silencieux du processus, problème technique chez les deux hébergeurs, etc ?

Au détour d’une lecture, je découvre peu après l’événement, l’existence d’un cloud IBM et surtout, son plafond d’utilisation gratuite pour la partie Object Storage, à savoir 25Go. Parfait pour mettre en place un deuxième point de sauvegarde distant et découvrir la plateforme !

Je liste à la suite les étapes qui m’ont permis de configurer un espace de stockage et d’obtenir les identifiants nécessaires à un accès distant, en espérant ne pas en avoir oublié (et que l’interface n’ai pas changé entre le moment d’écriture de ces lignes et le moment où vous les lisez).

Étapes de mise en place

  • Créer un compte sur https://cloud.ibm.com/registration.
  • Cliquer sur « Créer une ressource ».
  • Chercher et cliquer sur Object Storage.
  • Créer l’objet en lui donnant un nom de service.
  • Créer un compartiment (= bucket).
  • Donnez-lui un nom (correspondra à BUCKET_NAME).
  • Choisissez une classe de stockage (Standard par exemple).
  • Aller dans « Configuration » pour trouver les informations de points d’extrémité.
  • C’est le point d’extrémité public qui nous intéresse, s3.eu-de.cloud-object-storage.appdomain.cloud dans mon cas. C’est notre PUBLIC_ENDPOINT_LOCATION .
  • Ensuite, direction « Données d’identification pour le service ».
  • Cliquer sur « Nouvelles données d’identification ».
  • Activer l’option « Inclure un identifiant HMAC ».
  • Cliquer sur « Ajouter ».
  • Copier les données d’identification ainsi créées.
  • Parmi ces données, celles qui nous intéressent sont access_key_id et secret_access_key.

Configuration restic

Pour la configuration de restic, je reste bref et vous renvoi à la documentation. J’utilise cet outil de sauvegarde depuis au moins deux années sans aucun problème et je me rends compte que je ne lui ai jamais consacré d’article, ce qu’il faudra que je corrige. Pour faire simple, je configure les paramètres de connexion comme variables d’environnement. Ensuite, j’initialise le dépôt distant avec la commande d’initialisation restic, afin de pouvoir ensuite y envoyer des données. L’URL du stockage distant est de la forme: s3:http://PUBLIC_ENDPOINT_LOCATION/BUCKET_NAME.

$ export AWS_ACCESS_KEY_ID=access_key_id
$ export AWS_SECRET_ACCESS_KEY=secret_access_key
restic -r s3:http://PUBLIC_ENDPOINT_LOCATION/BUCKET_NAME init

Conclusion

Après quelques heures de tests et de configuration, je dispose maintenant d’un deuxième emplacement de sauvegarde distant, sans coûts supplémentaires autre que le temps de mise en place. Avec déjà quelques semaines d’utilisation, je n’ai pas rencontré d’erreurs lors de l’exécution de mes sauvegardes journalières, ce qui est toujours agréable. Un petit bémol tout de même, il ne semble pas possible de créer plusieurs buckets différents en version gratuite. Tous mes essais se sont soldés par une erreur dans l’interface de création, malheureusement sans information sur la raison précise de l’erreur. N’hésitez donc pas à refaire une tentative pour vérifier si le problème était temporaire ou non. De mon côté, je me suis accommodé d’un bucket unique.

Cette deuxième sauvegarde accroît encore davantage mon niveau de sérénité et ma certitude d’avoir peu de risque de subir une perte de données. Il me reste encore à trouver une bonne solution pour effectuer périodiquement un déploiement local à partir de la sauvegarde et ainsi vérifier son intégrité.

Inspirations

Unicoda a brûlé !

Amis lecteurs bonsoir !

Étrange journée que cette journée du 10 mars 2021, car, s’il y a bien un risque qu’on envisage pas immédiatement pour son serveur, lorsqu’on fait la liste des périls qui le guettent, c’est celui de l’incendie. Eh oui, en ce mercredi 10 mars 2021, Unicoda, où plutôt son serveur de résidence, est parti en fumée avec le reste des serveurs et des sites hébergés dans le datacenter SBG2 d’OVH à Strasbourg.

Pour Unicoda, plus de peur que de mal, puisque si vous lisez ces lignes, c’est que nous sommes (déjà) de retour. C’est bien sûr un événement dont tout le monde se passerait. J’ai pu voir quelques annonces de données irrémédiablement perdues, par exemple, du côté des serveurs du jeu Rust. Un événement qui démontre encore une fois, l’importance des sauvegardes, et que, même en environnement contrôlé, personne n’est à l’abri.

Voici donc un petit retour pour décrire la façon dont nous avons réagi à cet incident.

Tout commence ce matin vers 10h, lorsque mon frère Mathieu m’appelle au téléphone, en me demandant où est hébergé Unicoda dans les infrastructures OVH. Il continue en m’annonçant qu’il vient de lire qu’un incendie s’est déclaré dans le datacenter SBG2, que tout SBG est à l’arrêt et que Unicoda ne répond plus. Je lui confirme qu’Unicoda est bien hébergé à Strasbourg dans SBG2 et vérifie rapidement la connexion au serveur (en échec bien sûr). Vérification dans mes mails, pas de rapport journalier de sauvegarde ce matin, le feu s’étant déclaré peu avant le processus de sauvegarde automatique.

Je prends ensuite un peu de temps pour réfléchir. Je suis à 80% sûr qu’Unicoda était hébergé dans SBG2, rien dans la console d’administration d’OVH ne permet de valider l’information, rien sur les factures. Le rapport de sauvegarde du 9 mars indique qu’il s’est terminé avec succès. Enfin, SBG est à l’arrêt pour plusieurs jours, voir semaine, il faut donc préparer le redéploiement d’Unicoda sur un nouveau serveur. Profitant d’une pause dans ma matinée de travail, je commande donc un nouveau VPS OVH dans le datacenter de Gravelines.

Arrive le temps de la pause méridienne. Le VPS n’étant toujours pas disponible, je commande un VPS chez Hetzner en Allemagne, VPS facturé à l’heure avec un plafond mensuel, extrêmement pratique pour effectuer des tests de courtes durées. Livraison en moins d’une minute. J’ouvre le dépôt contenant mon script de déploiement automatisé ansible, change les DNS pour pointer vers la nouvelle machine et démarre l’exécution. Quelques erreurs du fait d’une réorganisation récente de l’ensemble de mes rôles ansible (et dont les tests devaient avoir lieu dans les prochains mois) interrompront deux fois la réinstallation. Au troisième essai, après quelques dizaines de minutes, Unicoda est à nouveau accessible.

Quels enseignements retenir de cet incident ?

Comme énoncé déjà ici: sauvegarder, sauvegarder et sauvegarder !! Je suis une nouvelle fois très satisfait par la solution de sauvegarde et de déploiement automatique que j’ai mise en place pour Unicoda et qui est le résultat de plusieurs années d’améliorations. Néanmoins, il serait bon d’ajouter un deuxième emplacement distant de stockage des sauvegardes. En effet, si par un hasard extraordinaire, un problème similaire était arrivé au datacenter stockant la sauvegarde chiffrée, c’eût été retour à la sauvegarde enregistrée sur mon poste local et pouvant parfois remonter à plusieurs semaines. Un emplacement distant pour les sauvegardes, c’est bien, deux, c’est mieux.

Deuxième point à noter, en cas de réorganisation complexe des scripts de déploiement automatique, il aurait été utile de conserver une copie du dépôt avant réorganisation, lorsque les scripts fonctionnaient sans erreurs et avait été testé. Ainsi, on s’évite quelques corrections en état de stress et pressé par le temps. Cela est bien entendu variable en fonction du service affecté, dans le cas d’Unicoda, je ne suis pas à la minute près, bien que j’apprécie d’avoir le moins de temps d’indisponibilité possible.

Enfin, j’ai apporté des modifications sur le Time To Live (TLL) du champ A des DNS d’Unicoda, entrée DNS responsable de la redirection vers le serveur. J’avais jusqu’à présent laissé ce champ à la valeur par défaut dans l’interface à savoir 86400 secondes soit 1 jour. Si cela ne pose guère de problèmes dans le cas d’une migration programmée, où l’ancien serveur continue de fonctionner quelques jours, c’est plus embêtant dans le cas d’un incident comme celui d’aujourd’hui, où on voudra que la modification DNS soit propagée le plus rapidement possible une fois le serveur de remplacement opérationnel. J’ai donc choisi une valeur de 7200 secondes (2 heures) de TTL, ce qui me semble être un bon compromis.

En conclusion, Unicoda s’en sort bien, plus de peur que de mal. On a beau avoir un processus de sauvegarde, des scripts de déploiement automatique, un léger doute subsiste toujours. Cet incident a permis de vérifier, en dehors d’un événement programmé, que les processus mis en place fonctionnent: une très bonne chose. Il me reste à vérifier dans les prochains jours que la sauvegarde s’effectue correctement sur ce nouveau serveur et, dans les prochaines semaines, à migrer une nouvelle fois Unicoda pour un retour chez OVH. A tous mes camarades informaticiens ayant perdu un serveur dans cet incendie: courage !

P.S. Pour suivre l’avancement de la remise en service, voici les tickets liés à l’incident:

Récupération de variables système sur Windows

Aujourd’hui j’ai installé Python et Django sur mon système Windows pour essayer de faire un petit site web rapidement, disons avant la fin de la journée.

Je commence donc ma configuration sur mon système Windows et en parallèle je fais la même chose en SSH sur une console MSYS2,une VM en mode console d’un système linux pour faire simple.

Sur windows je teste alors que sur la console MYSYS je suis connecté à mon serveur dédié de l’autre côté de la France mon serveur de production en quelque sorte.

Arrivé à l’étape d’installation de Django sur mon Windows, j’ai un message qui attire mon attention. Il semblerait qu’il manque un chemin dans PATH.

Pas de soucis. Touche Windows, j’écris « path » et j’appuie sur entrée. Je me retrouve sur les propriétés système.

Un clic de plus sur « Variables d’environnement… » et je me retrouve devant deux choix.

  • Variables utilisateur pour MonOrdinateur
  • Variables système

Dans les deux cas j’ai accès à une variable PATH que je peux modifier. Je ne me pose pas plus de questions et je modifie la variable Path dans variables système et y ajoute mon chemin.

Je valide tout, je suis content, tout va marcher et la commande 

django-admin --version

devrait enfin m’afficher quelque chose à l’écran. Mais ce n’est pas le cas…

Je retourne dans les propriétés système et je commence vraiment à avoir peur. Plus aucuns chemins n’est accessible dans la liste PATH des variables système. Je pose la question à mon moteur de recherche qui m’indique qu’une restauration est le seul moyen de retrouver mes données perdues. Mais pour cela, il faut un point de restauration.

Je n’ai pas de point de restauration actif, la protection du système semble désactivée.

Je continue les recherches avec de moins en moins d’espoir de pouvoir redémarrer mon système dans de bonne condition. Pour ce qui ne le savent pas, les variables système dans PATH conditionnent beaucoup de chemins vers des exécutables utiles au bon fonctionnement de votre ordinateur.

Plus d’une heure passe, en désespoir de cause je récupère quelques PATH sur un autre ordinateur et un ami m’envoie les siens, mais je vois bien qu’il n’y a pas tous les chemins que j’avais avant de tout casser.

Quand mes recherches prennent un tournant inattendu. Je trouve enfin quelque chose d’intéressant. On peut exécuter la commande set pour lister et modifier les variables d’environnement et système propre à l’exécution d’un interpréteur de commande (CMD). D’ailleurs si on modifie des chemins dans l’interpréteur et qu’on le quitte, les chemins ajoutés ne sont pas sauvegardés. De la même manière si j’ai modifié les variables PATH par l’interface graphique sans relancer l’interpréteur celui-ci connait encore les anciennes valeurs de PATH.

J’ai un sursaut d’excitation. Est-ce que j’ai encore une CMD ouverte ?

Malheureursment non. Je n’ai plus aucune CMD ouvertes dans la barre des tâches. Par contre il y a toujours MYSYS ouvert avec une connexion SSH en cours vers mon serveur.

Se pourrait-il que j’avais la solution pour récupérer mes variables système PATH sous les yeux depuis le début ?

Après avoir mis fin à la connexion ssh avec le serveur. Le verdict. Je tape au hasard la commande Windows « SET » dans l’interpréteur MYSYS Linux. Un résultat ! Peut être que j’ai de la chance après tout ? Je fracasse la molette pour remonter rapidement tout en haut de la sortie affichée, quand enfin j’ai ce que je cherchais !

Toutes mes variables PATH gardées en mémoire par MSYS2. Avec pour seul inconvénient un typage Unix et non Windows. Dix minutes plus tard j’ai mes variables système PATH d’origine. Et en bonus, j’ai même compris mon erreur. J’aurais du mettre mon chemin dans les variables utilisateur et vérifier qu’il était bien écrit. En plus j’aurais pu tester que tout fonctionne en le faisant avec la commande set en console avant de faire la modification réel.

Conclusion

Si vous perdez toutes vos variables système ou variables utilisateur sur Windows vous pouvez les récupérer en dernier recours si il vous reste une console ouverte avant la réalisation des modifications qui ont détruits vos chemins. Pour les trouver il suffit de taper la commande « set » ou « path » dans cette console et de récupérer et mettre en forme les chemins, puis de les réinsérer par l’interface graphique dans PATH en vérifiant si ce sont des variables utilisateur ou système.

Pour la petite astuce, ne faites pas comme moi et pensez à faire des points de restauration système réguliers.

Utilisation du jeton cryptographique Gnuk de secours

Dans un précédent article, j’avais décrit la manière de reprogrammer un STLinkv2 pour en faire un jeton cryptographique Gnuk. J’aurais pu m’arrêter là dans mes tests, mais alors, je n’aurais pas eu la garantie que ma solution de secours est valable. J’ai donc vérifié ma procédure, pas à pas, en reprenant si besoin les différents articles faisant offices de documentation. Voici quelques éléments à considérer.

Pour mener à bien la création d’un nouveau jeton cryptographique contenant les mêmes clés que mon jeton source, je commence par réinitialiser l’environnement sur le poste sécurisé ayant servi à la création des clés, après avoir pris soin de déchiffrer le dossier de sauvegarde contenant un exemplaire des clés :

export GNUPGHOME=/path/to/working/directory
cp dir-backup-mastersubkeys/* $GNUPGHOME/*

Pour la suite, l’export des clés sur le jeton s’effectue comme décrit dans les parties « Configuration de la cible » et « Export des sous-clefs vers la Yubikey » de mon article intitulé « GnuPG, clefs, YubiKey : c’est parti« . Par ailleurs, avant de commencer l’export des clés et pour compléter la configuration du jeton, on exécutera la commande kdf-setup dans l’éditeur de cartes GnuPG en mode admin, le but étant de renforcer la sécurité des clefs (Pour plus de détails à ce sujet, lire la partie « Protection des clefs » de l’article « Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre« ). Après import des clefs, on dispose alors d’un nouveau jeton cryptographique prêt à être utilisé.

Afin de faire fonctionner ma clé Gnuk avec gpg –card-status sans utiliser sudo, ajout d’une règle udev dans le fichier /lib/udev/rules.d/60-gnuk.rules.

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0000", ENV{ID_MODEL_ID}=="0000", MODE="660", GROUP="users"

Puis application des changements.

# rechargement des règles
sudo udevadm control --reload-rules
# Éventuellement redémarrage du système
sudo reboot

Sur le poste cible, sauvegarde du dossier .gnupg/private-keys-v1.d. Puis suppression de son contenu.

cp -r .gnupg/private-keys-v1.d .gnupg/private-keys-v1.d-save
rm .gnupg/private-keys-v1.d/*
gpg --card-status

La commande gpg –card-status a pour effet de réimporter les informations des clefs présentes sur la carte. Ainsi, si j’effectue une commande pass pour déchiffrer l’un de mes mots de passe, c’est bien la nouvelle clé Gnuk qui est attendue et non ma Yubikey. Pour repasser à la Yubikey, il suffit de supprimer à nouveau le contenu du dossier private-keys-v1.d et le tour est joué (et d’inverser jeton Gnuk et YubiKey).

Je note qu’il n’est pas possible en l’état d’utiliser deux supports différents pour les mêmes clefs, sans une intervention de l’utilisateur ou une automatisation des changements à effectuer en fonction du support branché. Pour utiliser indifféremment deux supports différents, un internaute proposait de créer trois sous-clefs supplémentaires, soit six en tout et de répartir les trois nouvelles sous-clefs sur le support supplémentaire.

Effectuer ce que je peux qualifier de « test grandeur nature » était ici indispensable, afin de s’assurer de la robustesse de la solution retenue pour la sécurisation de mon environnement informatique. En effet, s’appuyer sur une solution sans jamais avoir vérifié les procédures de restauration, le retour à un fonctionnement normal, me semble bien périlleux. C’est donc un pas de plus sur le chemin de ma résilience informatique !

Source:
GnuPG mailing list – GnuPG card && using the backup secret key

Restauration d’un dossier à partir de la sauvegarde avec duplicity

Pour une raison obscure, ma dernière tentative de mise à jour de Nextcloud a échoué et laissé le contenu du dossier dans un état instable. J’ai donc récupéré la dernière version stable depuis la sauvegarde de la veille.

sudo pip install --upgrade b2
sudo duplicity restore --force --file-to-restore path/to/nextcloud -t now b2://[applicationKeyId]:[application key]@[B2 bucket name] /path/to/nextcloud