Tout comme le chevalier Jedi fabrique son propre sabre laser, le hacker chevronné se doit de fabriquer son propre clavier... Sobre ou avec une forme futuriste, avec une myriade de LED clignotantes ou bien clavier à vocation ergonomique, chacun est libre de ses choix. Nous allons regarder les étapes essentielles d’une conception afin de vous lancer en toute connaissance.

Dans le numéro 54 [1], nous avions exploré la façon d'interfacer une smartcard avec une carte Raspberry Pi Pico (RP2040) et un MCU ESP32, jusqu'à arriver à converser et à échanger des données avec une applet Java que nous avions développée par ailleurs [2], et ce sans aucun circuit spécialisé. Nous allons ici recycler ces travaux et découvrir qu'il est parfaitement possible de faire de même avec un adaptateur USB à 4 €, normalement destiné aux manipulations de cartes SIM avec de douteuses applications Windows.

Nous explorons les divers outils permettant de sonder l’état de la mémoire de microcontrôleurs au cours de l’exécution d’un programme pour en identifier les dysfonctionnements ou suivre le statut des variables ou registres internes à l’unité arithmétique et logique. Ces explorations se feront soit sur matériel, soit dans le domaine virtuel des émulateurs, avec ou sans la supervision d’un système d’exploitation.

Proposer une ligne de commande, ou du moins une forme de REPL (read–eval–print loop) pour manipuler interactivement un montage ou une installation à base de microcontrôleur est un grand classique. Lorsque cela se fait via une connexion réseau, par opposition à une liaison série, par exemple, on en arrive souvent à utiliser quelque chose qui ressemble à Telnet avec une authentification assez basique et surtout une absence totale de chiffrement. Sur PC ou SBC, cela fait longtemps que ce genre de choses est devenu totalement obsolète, au bénéfice du classique SSH. Pourquoi n'en serait-il pas de même avec un MCU un peu « musclé » ?

Versé dans l'art de la programmation et coutumier des subtilités du fonctionnement d'un OS, vous savez. L'utopie d'un système parfait, exempt de tout bug et de toute faille n'existe pas, et n'existera probablement jamais. Mais ce savoir n'est pas courant, ni chez le commun des mortels ni chez le politicien, l'élu ou le parlementaire (probablement même encore moins, d'ailleurs). Et c'est précisément là que le déséquilibre existe entre la praticité subjective d'une solution et le risque, bien réel, qu'elle implique dès lors que l'informatique s'en mêle.

Si Ansible facilite l’installation et le maintien en condition opérationnelle d’une infrastructure logicielle, l’outil peut aller encore plus loin et devenir un atout précieux pour continuer de faire évoluer son système au cours du temps. Voyons ceci en détail, et par la pratique, dans ce premier article sur le thème « Day One operations » avec Ansible !

Après avoir étudié les bases et les prérequis pour l’intégration d’un cluster Ceph externe avec Kubernetes [0], passons maintenant à la pratique. Dans cet article, nous allons aborder la configuration de l’opérateur Rook, l’importation des données Ceph dans Kubernetes, et la mise en place d’un cas d’utilisation avec le stockage CephFS. Au programme : scripts d’export/import, déploiement d’une application concrète comme Nextcloud, et surveillance via le tableau de bord Ceph.

Dans le monde réel, la continuité de service informatique est cruciale, il est donc indispensable de garantir l’accès aux ressources informatiques de façon continue. Disposer d’un serveur de fichiers hautement disponible et tolérant aux pannes permet de répondre à cet enjeu. Dans cet article, nous allons mettre en place une architecture composée de GlusterFS pour une réplication distribuée, CTDB pour assurer la récupération et le basculement des nœuds et Samba pour exporter les volumes GlusterFS via le protocole SMB/CIFS pour garantir une intégration transparente et une disponibilité continue pour les clients Windows.