[Musique] Ruby Haunt – Jeune
De retour chez OVH
Article du samedi soir qui devrait rester court, simplement pour informer qu’Unicoda est de retour chez OVH depuis quelques heures. Cette fois, le serveur s’éloigne de moi de plusieurs centaines de kilomètres, alors qu’il était longtemps à moins de 15 kilomètres de mon domicile. Bref, retour en France, après un court passage chez Hetzner à Falkenstein en Allemagne. Tout a l’air de bien fonctionner. Vérification demain matin que le processus de sauvegarde quotidien s’est exécuté comme prévu et avec succès.
Au passage, j’en ai profité pour ajouter une sauvegarde distante supplémentaire. Le site est donc à présent sauvegardé vers deux services de stockage différents: Backblaze B2 (déjà évoqué ici) et désormais également dans le Cloud IBM. Je suivrai les sauvegardes vers ce nouveau dépôt dans les prochains jours afin de valider définitivement son bon fonctionnement.
J’ai profité de cette nouvelle migration pour jeter un œil du côté des logs Apache, pour la journée du 19 mars, en utilisant GoAccess, découvert pour l’occasion, et qui permet d’avoir quelques données agrégées directement accessible dans le terminal. Je note au passage l’option --ignore-crawlers permettant de filtrer les robots et autres bots. Difficile par contre de se faire une idée précise du nombre de lecteurs quotidiens, mais le flux RSS semble être appelé régulièrement: tant mieux !
C’est vraiment un point que je souhaite améliorer, à savoir la surveillance du serveur, en termes d’utilisation de ressources et d’analyse du trafic. Loin de moi l’idée de mettre en place du Google Analytics, mais quelque chose basé sur l’analyse des logs Apache devrait suffire et permettre, par exemple sur une durée d’un mois, de distinguer le trafic « réel », du trafic des bots, crawlers et autres spammers automatisés, et de savoir comment se comporte le serveur.
Pour finir, quelques données en vrac concernant les proportions de chaque système d’exploitation et les navigateurs pour cette journée du 19 mars. Pour les systèmes d’exploitation, je note environ (arrondi à la valeur inférieure):
- 36% Windows
- 25% GNU/Linux
- 18% Android
- 11% Macintosh
- 1% iOS
Pour les navigateurs:
- 37% Chrome
- 26% Firefox
- 19% Safari
- 2% MSIE
Sur ces quelques chiffres, amis lecteurs, bonne nuit !
Nouveau disque chiffré dédié à la sauvegarde
Ayant fait l’acquisition début d’année, d’un nouveau disque vierge d’une capacité de stockage de 1To, je me suis enfin occupé de sa configuration, afin de pouvoir y déposer les données numériques dont je souhaite absolument éviter la perte.
Mon choix s’est porté sur un disque de marque Seagate au format 2.5″, et j’ai choisi un boîtier « Mobility Disk S8 » de la marque Advance, pour protéger le disque et simplifier sa connexion comme disque externe. Esthétiquement parlant, le boîtier est très bien, sobre, en aluminium et simple dans l’installation du disque. Ce sera désormais mon choix par défaut pour les prochains disques externes dont je pourrais avoir besoin. En cas de problème sur le disque ou l’interface de connexion, il est en effet bien plus simple de changer l’un ou l’autre. Chose qui est impossible sur les disques externes tout assemblés comme ceux de Western Digital, où toute l’électronique est solidaire du disque.
Place ensuite à l’étape d’initialisation du disque chiffré et direction mon article « Chiffrer un support » de 2018, pour suivre la procédure et vérifier que celle-ci est toujours valable; ce qui est le cas.
Au passage, après avoir généré aléatoirement et stocké le mot de passe de la partition chiffrée dans pass, sous une arborescence spécifique crypt/usb/ et sauvegarder dans une entrée nommée suivant l’UUID du disque, j’en profite pour mettre à jour ma configuration de udiskie. udiskie, programme qui s’occupe de la gestion des médias amovibles sur mon système.
Je modifie donc le fichier .config/udiskie/config.yml pour y ajouter le contenu suivant:
program_options:
tray: auto
automount: false
notify: true
password_prompt: ["pass", "crypt/usb/{id_uuid}"]
Avec ces quelques lignes, j’indique au programme d’exécuter la commande pass pour accèder au mot de passe stocké dans crypt/usb et identifié par son UUID, d’où le choix du nommage au paragraphe précédent. UUID du disque qu’il est possible de connaître de plusieurs manières (décrites dans le wiki ArchLinux, partie Persistent block device naming – by-uuid), dont celle-ci:
$ ls -l /dev/disk/by-uuid/
On effectue ensuite un petit test pour vérifier le bon fonctionnement de la configuration via la commande:
$ udiskie-mount -r /dev/sdX
Cela fonctionne correctement. Après un redémarrage, je constate néanmoins que c’est la fenêtre de demande de mot de passe par défaut qui s’affiche lorsque j’utilise PCmanFM comme explorateur de fichier. Il me semble avoir résolu le problème en désactivant le montage automatique configuré dans PCmanFM. C’est alors bien udiskie qui prend la main.
Enfin, dernière étape incontournable pour conclure, la sauvegarde des entêtes du disque chiffré, afin de pouvoir restaurer un accès aux données chiffrées en cas de corruption des entêtes présentes sur le support. Une corruption des entêtes d’un disque chiffré entraîne en effet une impossibilité totale d’accéder à l’ensemble du contenu, et cela, même si cette partie du disque est parfaitement saine. C’est donc une opération à faire absolument, lorsqu’on décide de chiffrer un disque et on s’évitera ainsi des sueurs froides en cas de problème sur les entêtes.
Sauvegarde des entêtes LUKS
Petit pense-bête pour noter ici la procédure de sauvegarde des entêtes d’une partition chiffrée luks pour un disque nommé carbone, reconnu sur /dev/sde et stocker les informations dans une entrée de mon gestionnaire de mot de passe pass. Le tout, de la façon la plus sécurisée possible, avec l’utilisation d’un dossier monté en ram via ramfs, afin que l’information ne soit jamais écrite en clair sur le disque.
$ sudo mkdir /mnt/tmp $ sudo mount ramfs /mnt/tmp -t ramfs $ sudo cryptsetup luksHeaderBackup /dev/sde --header-backup-file /mnt/tmp/dump $ sudo chown vvision:vvision /mnt/tmp/dump $ pass insert -m crypt/luksheader/carbone < /mnt/tmp/dump $ sudo umount /mnt/tmp $ sudo rmdir /mnt/tmp
Procédure trouvée sur l’excellent blog de P. Hogg. Article LUKS Header Backup.
Les restes de SBG2
A la suite de l’article de Victor concernant la destruction du site OVHcloud qui hébergeait notre site unicoda.com je suis allé faire un petit tour du côté du port de Rhin à Strasbourg à quelques kilomètres à peine de chez moi pour immortaliser cet événement.
C’est un événement heureusement rare qui permettra à beaucoup de réfléchir à la pérennité de leur activité sur internet et aux moyens à allouer à la sauvegarde de leurs données.