
[Musique] Shine – Hicham Chahidi

Pensées Libres dans un Monde Binaire
L’astuce consiste en l’utilisation d’une image buildah
officielle, disponible à l’adresse quay.io/buildah/stable
. Je distingue trois étapes dans mon build: la construction de l’image, la récupération de la clef de chiffrement depuis le Secret Manager et enfin, le stockage dans le Container Registry. Ce qui nous donne donc la configuration ci-dessous.
# Build image with buildah - id: 'build' name: 'quay.io/buildah/stable' args: ['buildah', 'bud', '-t', 'mon-image', '.'] volumes: - name: varlibcontainers path: '/var/lib/containers'
# Get public key from secret manager - id: 'get public key' name: gcr.io/cloud-builders/gcloud entrypoint: 'bash' args: [ '-c', "gcloud secrets versions access latest --secret=pub-key --format='get(payload.data)' | tr '_-' '/+' | base64 -d > pub-key.pem" ]
# Push image with buildah - id: 'push' name: 'quay.io/buildah/stable' args: ['buildah', 'push', '--encryption-key', 'jwe:./pub-key.pem', 'mon-image', 'eu.gcr.io/$PROJECT_ID/mon-image'] volumes: - name: varlibcontainers path: '/var/lib/containers'
Précisons que ce Cloud Build est déclenché en cas de push sur une branche particulière d’un dépôt git, ici hébergé chez GitHub et connecté à la GCP. Ce dépôt contient bien entendu un fichier Dockerfile
à sa racine.
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):
Pour les navigateurs:
Sur ces quelques chiffres, amis lecteurs, bonne nuit !
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.