Il y a quelques temps, aux Restos du Coeur, un collègue m'a demandé d'afficher des vidéos en boucle pour le forum des associations de Chartres.

La première chose qui m'est venue en tête était de mettre un VLC sur un PC en plein écran en mode "boucle". 🤘

Sur le papier c'était OK, mais cette solution posée quelques problèmes :

• Pas super pratique pour les personnes ne travaillant pas dans l'informatique (dans l'associatif on a tous les niveaux) 😜
• Cette solution prend pas mal de place
• Elle est relativement honéreuse (car nécessite un pc à minima)
• Il faut tout relancer manuellement à chaque coupure/réinstallation

J'avais un Raspberry Pi sous la main, je me suis donc mis à la recherche d'une solution avant de vouloir réinventer la roue. 🙃

Mon besoin était simple, je veux que l'utilisateur n'ait qu'une clé usb à connecter avec ses vidéso et que ça tourne en boucle. Et là, bingo ! J'ai trouvé la solution.

Elle se nomme "Raspberry Pi Video Looper". Autant vous dire qu'avec un tel nom, je n'ai pas mis 15 ans à la trouver. 😍

Son fonctionnement est plutôt simple, vous devez récupérer l'image et l'installer sur une Carte SD/microSD de votre choix. Je ne vais pas vous expliquer comment flasher ici une carte, il y a une ribambelle d'articles sur le sujet. 🫡

Une fois que l'image est présente sur la carte et que cette dernière est installée, vous n'avez plus qu'à démarrer le Raspberry. Et là, encore une fois, magie, ce dernier vous demande d'insérer votre clé USB.

Vidéo Looper va lire toutes les vidéos présentent sur le support, idéalement, faites une clé dédiée pour cet usage, enfin, c'est ce que je recommande. 😜

Voilà, maintenant, vous avez une solution qui charge et lit les vidéos en boucle de manière totalement fluide et sans effort/configuration.

La solution étant portable, elle peut être réutilisée sans à devoir repasser par de la configuration. Eteindre et rallumer fait refonctionner la chose automatiquement.

Magique ! 🥳

Cette année j'ai eu la chance et le privilège d'avoir été sélectionné pour 2 talks.

Un premier sur VictoriaMetrics, une solution que j'apprécie tout particulièrement et qui vient donner un coup de neuf à Prometheus. 👀

Un très grand merci une nouvelle fois à l'organisation et au CFP pour m'avoir donné la chance de parler de solutions que j'affectionne et que j'utilise au quotidien (notamment dans un cadre associatif 🩷).

Observabilité : dépoussiérer Prometheus avec VictoriaMetrics (30 mn)

Asbtract :

Prometheus s'est imposé comme un standard de facto dans nos infrastructures lorsque l'on souhaite faire de l'observabilité en collectant des métriques. Dans un contexte où l'on a besoin de se mettre rapidement à l'échelle (scalable), Prometheus commence à montrer ses faiblesses.

Prometheus ne possède pas de système de haute disponibilité de manière native, il faut obligatoirement passer par des solutions plus ou moins complexes comme Thanos ou Cortex. Ces solutions s'ajoutent à la lourdeur originelle de Prometheus.

VictoriaMetrics vient corriger tout cela en offrant une architecture micro-services où tout est découpé pour de meilleures performances et une meilleure disponibilité sans perte de données.
Ainsi je ferais un bref historique de l'observabilité, des solutions existantes, et du pourquoi complet de VictoriaMetrics, car il y en a beaucoup à dire sur cet outil prometteur !

Je vous ferais également un retour d'expérience sur l'utilisation de VictoriaMetrics Cluster aux Restos du Cœur et comment nous avons pu ainsi réduire les coûts en consommant plus de métriques qu'auparavant.

Le replay 📺 :

Les slides 📄 :

Pour le second talk, c'est la toute première fois que je donnais une université (3h - deep dive) avec les amis Idriss Neumann et Alexis Fala. Très certainement la première d'une longue série ! 💜 On a déjà quelques idées pour une prochaine université, on en reparlera sûrement très bientôt.

Pulumi, ou comment gérer votre infrastructure avec votre langage préféré (3h)

Abstract :

N’avez-vous jamais rêvé de pouvoir gérer votre infrastructure avec votre langage de programmation préféré ? D'exposer vos scripts de provisionnement et déploiement d'infrastructure comme un véritable service web moderne et utilisable par le plus grand nombre ?

Vous connaissez certainement Terraform ; Pulumi se positionne comme une alternative sérieuse à cette solution extrêmement populaire dans le domaine de l'infrastructure en tant que code (IaC).

Dans cette université nous vous proposons de découvrir ce challenger en mettant en lumière ses points forts comme la programmation multi-langages, la possibilité de mieux tester son code, d'avoir une couche d'abstraction multi-cloud plus efficace et même la capacité de réaliser de véritables applications web modernes de déploiement ...

Venez découvrir Pulumi, l'essayer et qui sait ? Peut-être l'adopter !

Le replay 📺 :

Les slides 📄 :

On se retrouvera peut-être l'année prochaine, qui sait ! 😇

Au quotidien, j'utilise Rudder pour maintenir une certaine cohérence dans la configuration de base appliquée sur mes différents serveurs et de reprendre la main sur les drifts de configuration qui peuvent être observés.

Cet article va être hyper rapide mais je souhaitais partager avec vous comment y arriver. 🙏

Pour des raisons de lisibilité, vous trouverez le fichier de configuration Cloud-Init ici :

Deploy Rudder Agent with Cloud-Init on Ubuntu Server 22.04

Deploy Rudder Agent with Cloud-Init on Ubuntu Server 22.04 - rudder-agent-cloud-init

262588213843476Gist

En complément, vous pouvez facilement accepter cette machine (qui arrive dans les "pending nodes") une fois l'agent exécuté via l'API. 😎

Pour y arriver, vous devez vous générer un token d'API puis :

# Stocker le nom de la machine à accepter
RUDDER_AGENT_HOSTNAME="demo-rudder-cloud-init"

# Récupérer l'ID de la machine en question
NODE_ID=$(curl -sk -H "X-API-Token: xxxxxx" 'https://rudder.example.org/rudder/api/latest/nodes/pending?where=\[\{"objectType":"node","attribute":"OS","comparator":"eq","value":"Linux"\},\{"objectType":"node","attribute":"nodeHostname","comparator":"regex","value":"${RUDDER_AGENT_HOSTNAME}"\}\]' | jq '.data.nodes[0].id' | tr -d '"')

# L'accepter
curl -sk -H "X-API-Token: xxxxxxx" --request POST https://rudder.example.org/rudder/api/latest/nodes/pending/${NODE_ID} --data "status=accepted"

Cet article est là pour donner une astuce rapide si vous souhaitez éviter de commuter d'un résolveur DNS à un autre (lorsque vous changez d'environnement).

A noter qu'il également possible d'utiliser des outils comme Unbound localement sur votre poste, le but de cet article est de montrer comment le faire directement avec les outils proposés par Apple. 😌

Apple macOS fournit l'outil scutil qui va nous permettre de modifier la configuration système.

Pour spécifier à votre système d'utiliser un résolveur spécifique pour un domaine donné, il faut utiliser la syntaxe suivante :

sudo echo 'nameserver 10.0.0.1' > /etc/resolver/example.org
sudo echo 'nameserver 10.0.0.2' >> /etc/resolver/example.org

A noter que la commande dig ne prendra pas les résolveurs déclarés de cette sorte. Il faudra donc spécifier l'adresse du résolveur lors de la tentative de résolution. 😎

Exemple :

dig @10.0.0.1 -t A example.org

Sinon, vous pouvez utiliser l'outil directement fournit par Apple pour réaliser une résolution DNS :

dscacheutil -q host -a name example.org

Et voilà ! C'était ma petite astuce du jours. 🤓

Cet article va être très rapide. Je voulais simplement vous partager commenter créer un template Proxmox VE de FreeBSD avec Cloud-init. 😁

Cet article vient en complément de celui-ci :

Pulumi + Proxmox VE + Cloud-Init = ❤️

> Cet article sera très certainement le premier d’une longue série sur ce sujet. Il est là pour vous donner un premier exemple concret. Bon, il y a de très fortes chances que vous soyez tombés dessus, mais il y a peu de temps, Hashicorp annoncé le passage à la licence BSL (Business Source License) […

Julien Briaultju_hnny5

A noter que cette procédure fonctionne pour toutes les images disponibles ici :

A collection of prebuilt BSD cloud images

Mark Otto, Jacob Thornton, and Bootstrap contributors

Voici l'ensemble des commandes à utiliser pour y arriver :

cd /tmp
wget https://object-storage.public.mtl1.vexxhost.net/swift/v1/1dbafeefbd4f4c80864414a441e72dd2/bsd-cloud-image.org/images/freebsd/13.2/2023-04-21/zfs/freebsd-13.2-zfs-2023-04-21.qcow2

qm create 9001 --name freebsd132-cloudinit-template --memory 1024 --net0 virtio,bridge=vmbr0

qm importdisk 9001 freebsd-13.2-zfs-2023-04-21.qcow2 local-lvm
qm set 9001 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9001-disk-0
qm set 9001 --ide2 local-lvm:cloudinit
qm set 9001 --boot c --bootdisk scsi0
qm set 9001 --ide2 local-lvm:cloudinit
qm set 9001 --serial0 socket --vga serial0
qm template 9001

Ainsi, à la toute fin, vous aurez votre template disponible avec l'id 9001.

L'infrastructure en tant que code (IaC) a transformé la gestion informatique, et Terraform d'HashiCorp a été un pilier dans ce domaine.

Mais que se passerait-il si vous pouviez combiner la puissance des providers de Terraform avec la flexibilité des langages de programmation populaires comme Python et JavaScript ?

C'est précisément ce que propose Pulumi et le Pulumi Terraform Bridge. 🙏

Vous avez été relativement nombreux/ses à vouloir un article sur ce sujet, c'est maintenant chose faite.

Avant de commencer, je souhaiterais préciser qu'il vous faudra quelques connaissances en Go pour y arriver sans trop de difficulté. 🫡

C'est parti, allons-y !

Récupération des prérequis 😄

Vous devez, avant de commencer avoir en votre possession :

• GNU Make (pour le Makefile)
• Golang (vers 1.18 ou supérieur)
• Goreleaser
• Git (obviously).

Et le "Terraform Bridge Provider Boilerplate" : https://github.com/pulumi/pulumi-tf-provider-boilerplate

Ce projet doit être forké chez vous, en respectant le format suivant :

pulumi-<provider_name>

Ce qui donne par exemple :

pulumi-maas

Ni plus, ni moins ! Ne reste plus qu'à cloner le repo chez vous :

git clone https://github.com/juhnny5/pulumi-maas.git
cd pulumi-maas/

Initialiser le repo

Le boilerplate, comme son nom l'indique fournit une base qu'il va falloir un peu adapter par rapport à notre provider à créer.

Pour ce faire, nous allons utiliser la commande suivante :

make prepare NAME=maas REPOSITORY=github.com/juhnny5/pulumi-maas

Cette commande va venir modifier les différents fichiers nécessaires au build et à la transformation, notamment le go.mod par exemple.

Elle va également générer les ressources qui vont nous être utiles par la suite :

• provider/cmd/pulumi-resource-maas
• provider/cmd/pulumi-tfgen-maas
• provider/resources.go

Cette commande modifie pas mal de choses, mais, dans mon cas, je vais chercher à convertir un provider qui n'est pas dans le repo officiel de Terraform. En effet, le provider de MaaS est sur le repo de l'orga du même nom, à savoir :

GitHub - maas/terraform-provider-maas: Terraform MAAS provider

Terraform MAAS provider. Contribute to maas/terraform-provider-maas development by creating an account on GitHub.

maasGitHub

Ainsi, dans le fichier Makefile, il me suffira de modifier les variables de cette sorte :

PROJECT_NAME := maas Package

SHELL            := /bin/bash
PACK             := maas
ORG              := juhnny5
PROJECT          := github.com/${ORG}/pulumi-${PACK}
NODE_MODULE_NAME := @juhnny5/${PACK}
TF_NAME          := ${PACK}
PROVIDER_PATH    := provider
VERSION_PATH     := ${PROVIDER_PATH}/pkg/version.Version

TFGEN           := pulumi-tfgen-${PACK}
PROVIDER        := pulumi-resource-${PACK}
VERSION         := $(shell pulumictl get version)

TESTPARALLELISM := 4

WORKING_DIR     := $(shell pwd)

OS := $(shell uname)
EMPTY_TO_AVOID_SED := ""

Dans mon exemple, j'utilise un provider Terraform en source qui est un peu particulier. En effet, si on regarde le go.mod du projet, celui-ci, on se rend compte que le nom du projet n'est pas le FQDN du projet sur GitHub mais simplement le nom du repo.

module terraform-provider-maas

go 1.19

require (
	github.com/bflad/tfproviderlint v0.28.1
	github.com/hashicorp/go-cty v1.4.1-0.20200414143053-d3edf31b6320
	github.com/hashicorp/terraform-plugin-docs v0.16.0
	github.com/hashicorp/terraform-plugin-sdk/v2 v2.27.0
	github.com/maas/gomaasclient v0.0.0-20230512141257-d73401ee0dc8
	github.com/stretchr/testify v1.8.4
)

Ainsi, côté boilerplate, il faudra modifier notre go.mod également pour que nous puissions utiliser cette lib en entrée. Ainsi donc :

vi provider/go.mod

On va remplacer le nom en spécifiant la version souhaitée. 🙃

module github.com/juhnny5/pulumi-maas/provider

go 1.19

replace (
	github.com/hashicorp/terraform-plugin-sdk/v2 => github.com/pulumi/terraform-plugin-sdk/v2 v2.0.0-20230710100801-03a71d0fca3d
	terraform-provider-maas v1.2.0 => github.com/maas/terraform-provider-maas v1.2.0
)

require (
	github.com/pulumi/pulumi-terraform-bridge/v3 v3.57.0
	github.com/pulumi/pulumi/sdk/v3 v3.76.1
	terraform-provider-maas v1.2.0
)

Ainsi, nous pourrons utiliser le nom terraform-provider-maas dans notre code. A noter que cette subtilité n'est pas toujours présente, cette manipulation est à réaliser dans le cas ou le provider source ne spécifie pas le FQDN Github dans son go.mod.

Maintenant, il suffit de rajouter la dépendance vers ce provider Terraform dans notre fichier de resources. 🫡

Pour ce faire :

vi provider/resources.go

Et y ajouter terraform-provider-maas/maas, de cette sorte :

package maas

import (
	"fmt"
	"path/filepath"

	"terraform-provider-maas/maas"

	"github.com/juhnny5/pulumi-maas/provider/pkg/version"
	"github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge"
	"github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge/tokens"
	shim "github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfshim"
	shimv2 "github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfshim/sdk-v2"
	"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
)

Un coup de tfgen 🥸

Pour continuer, il faut lancer la commande :

make tfgen

Modifier les infos du futur provider Pulumi 👀

Par défaut, lorsque vous avez fait initialisé le projet, le fichier resources.go a ajouté plusieurs infos concernant le projet.  😋

Nous allons y modifier d'autres infos avant de générer les SDKs. Le nom du Publisher :

	prov := tfbridge.ProviderInfo{
		P:    p,
		Name: "maas",
		// DisplayName is a way to be able to change the casing of the provider
		// name when being displayed on the Pulumi registry
		DisplayName: "MAAS",
		// The default publisher for all packages is Pulumi.
		// Change this to your personal name (or a company name) that you
		// would like to be shown in the Pulumi Registry if this package is published
		// there.
		Publisher: "Julien Briault",

Mais également la description et l'org Github si celle-ci n'a pas été correctement modifiée.

Description:       "A Pulumi package for creating and managing Canonical Metal-As-A-Service (MAAS) resources.",
GitHubOrg: "juhnny5",
Repository: "https://github.com/juhnny5/pulumi-maas",
Keywords:   []string{"pulumi", "maas", "category/cloud"},

Ensuite, nous allons spécifier la configuration de chaque SDK à générer. Quand je parle de chaque SDK, j'entends par chaque langage de programmation à supporter par votre provider. 😈

Ainsi, vous pouvez obtenir ce résultat :

		JavaScript: &tfbridge.JavaScriptInfo{
			// List any npm dependencies and their versions
			Dependencies: map[string]string{
				"@pulumi/pulumi": "^3.0.0",
			},
			DevDependencies: map[string]string{
				"@types/node": "^10.0.0", // so we can access strongly typed node definitions.
				"@types/mime": "^2.0.0",
			},
			// See the documentation for tfbridge.OverlayInfo for how to lay out this
			// section, or refer to the AWS provider. Delete this section if there are
			// no overlay files.
			//Overlay: &tfbridge.OverlayInfo{},
		},
		Python: &tfbridge.PythonInfo{
			// List any Python dependencies and their version ranges
			PackageName: "pulumi-maas",
			Requires: map[string]string{
				"pulumi": ">=3.0.0,<4.0.0",
			},
		},
		Golang: &tfbridge.GolangInfo{
			ImportBasePath: filepath.Join(
				fmt.Sprintf("github.com/juhnny5/pulumi-%[1]s/sdk/", mainPkg),
				tfbridge.GetModuleMajorVersion(version.Version),
				"go",
				mainPkg,
			),
			GenerateResourceContainerTypes: true,
		},
		CSharp: &tfbridge.CSharpInfo{
			PackageReferences: map[string]string{
				"Pulumi": "3.*",
			},
		},

Générer le code ! ☺️

Maintenant que l'on est tout bon sur les dépendances et dans l'initialisation du projet, nous allons pouvoir transformer notre code Terraform en code Pulumi et générer les SDKs appropriés. 😄

make build_sdks

Vous retrouverez automatiquement le code des différents SDKS dans sdk/.

Une fois que c'est fait, il ne reste plus qu'à release votre code sur Github, je ne vais pas expliquer comment fonctionne Goreleaser ici, par contre, je vous invite à créer votre fichier de cette sorte :

archives:
  - id: archive
    name_template: '{{ .Binary }}-{{ .Tag }}-{{ .Os }}-{{ .Arch }}'
before:
  hooks:
    - make tfgen
builds:
  - binary: pulumi-resource-maas
    dir: provider
    env:
      - CGO_ENABLED=0
    goarch:
      - amd64
      - arm64
    goos:
      - darwin
      - windows
      - linux
    ldflags:
      # The line below MUST align with the module in current provider/go.mod
      - -X github.com/juhnny5/pulumi-maas/provider/pkg/version.Version={{.Tag }}
    main: ./cmd/pulumi-resource-maas/
changelog:
  skip: true
release:
  disable: false
  prerelease: auto
snapshot:
  name_template: '{{ .Tag }}-SNAPSHOT'

A noter que vous trouverez un exemple dans le dossier deploymen-templates/. Vous y trouverez également le README expliquant comment release votre projet.

Pour terminer, vous trouverez tout le code disponible ici si vous souhaitez un exemple concret :

GitHub - juhnny5/pulumi-maas

Contribute to juhnny5/pulumi-maas development by creating an account on GitHub.

juhnny5GitHub

Vous l'aurez compris, plus d'excuse pour ne pas migrer vers Pulumi. Le prochain article traitera de comment publier ces différentes ressources (sdks). 🤭

Bon, il y a de très fortes chances que vous soyez tombés dessus, mais il y a peu de temps, Hashicorp annoncé le passage à la licence BSL (Business Source License) pour leur projet Terraform. 💩

Je vous conseil d'ailleurs d'aller consulter le site du collègue et ami Denis aka Zwindler, qui a écrit un billet sur le sujet.

D open source à BullShit Licence (BSL)

Résumé des épisodes précédents Il y a à peine un mois, j’écrivais mon billet d’humeur annuel sur une boite, championne de l’open source (RHEL), qui utilise une faille de la licence GPL pour gratter un peu de thune en fermant ses sources aux “rebuilders” (je parle évidem…

Zwindler's Reflection

De mon côté, j'utilise Pulumi depuis un bon moment à titre personnel, j'ai d'ailleurs préparé un talk sur ce sujet pour expliquer son fonctionnement. Ce talk arrivera dès la rentrée. 😊

Dans cet article, je vais simplement vous partager un usage simple pour commencer.

Contexte 😬

J'utilise Proxmox VE à la maison pour réaliser des PoCs. Proxmox VE (ou pve) possède une API qui permet d'intéragir avec celui-ci. Pour des raisons de simplicité, j'ai passé un peu de temps à déporter la création de vms dans un fichier YAML dédié.

Création du premier projet 😎

Pour une question de simplicité, ici je vais créer un projet Python pour la compréhension d'un plus grand nombre. A noter que le gros avantage de Pulumi est de pouvoir utiliser son langage de prédilection (dans la limite de ceux supportés).

mkdir -p pulumi-proxmox
cd pulumi-proxmox/
pulumi new python --name pulumi-proxmox --stack dev --description "Pulumi with Proxmox VE" --force
pip install pulumi-proxmoxve
pulumi stack init dev

Maintenant que notre projet est intialisé, nous allons attaquer la configuration de l'utilisateur Pulumi sur Proxmox VE pour que l'outil du même nom puisse intérragir avec l'API de Proxmox VE. 😊

Il est important de souligner que par défaut, Pulumi stock le state sur sa plateforme. Il est possible de le garder localement ou de l'envoyer dans du stockage objet (type S3).

Configuration de l'utilisateur Pulumi sur Proxmox VE

Il faut commencer par créer le role Pulumi avec les bons droits :

pveum role add Pulumi -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.Monitor VM.Audit VM.PowerMgmt Datastore.AllocateSpace Datastore.Audit"

Ensuite, ajouter l'utilisateur :

pveum user add pulumi@pve -password <password> -comment "Pulumi account"

Spécifier le rôle que doit utiliser l'utilisateur pulumi@pve :

pveum aclmod / -user pulumi@pve -role Pulumi

Créer un token :

pveum user token add pulumi@pve pulumi -expire 0 -privsep 0 -comment "Pulumi token"

Ne reste plus qu'à tester que celui-ci fonctionne ! ☺️

curl -X GET 'https://mox.homelab.lan:8006/api2/json/nodes' -H 'Authorization: PVEAPIToken=pulumi@pve!pulumi=xxxxxxxxxxxxxxx'

Ok, maintenant que la configuration de l'utilisateur Pulumi est faite côté Proxmox VE, nous allons créer le template Ubuntu Server 22.04 via la`cloudimg` qui supporte l'utilisation de cloud-init.

D'ailleurs, si vous ne connaissez pas cloud-init, je vous conseil de lire cette introduction (en Français) :

Introduction à Cloud-init

Lors de précédents articles, nous avons vu comment installer et déployer des applications à l’aide de Docker, et de cloud providers. Faut-il que je réalise mon installation de Docker à chaque création d’instance ? Comment garantir une homogénéité dans mes installations ? Gagner du temps ?

Loïc FACHELa Grotte du Barbu

Création du template 🥸

Pour ce faire on va récupérer l'image sur le site de Canonical et installer les dépendances. 😁

cd /tmp
wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img

apt update -y && apt install libguestfs-tools -y

On va ensuite installer le paquet qemu-guest-agent, ajouter notre premier utilisateur (ici jbriault), créer le path et injecter la clé SSH. On termine par définir les bons droits.

virt-customize -a jammy-server-cloudimg-amd64.img --install qemu-guest-agent

virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'useradd jbriault'

virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'mkdir -p /home/jbriault/.ssh'

virt-customize -a jammy-server-cloudimg-amd64.img --ssh-inject jbriault:file:/home/jbriault/.ssh/id_rsa.pub

virt-customize -a jammy-server-cloudimg-amd64.img --run-command 'chown -R jbriault: /home/jbriault'

Maintenant, on rentre dans le dur et on créé le template qui aura pour id 9000. 🚀

qm create 9000 --name "ubuntu-2204-cloudinit-template" --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 9000 jammy-server-cloudimg-amd64.img local-lvm
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --boot c --bootdisk scsi0
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --serial0 socket --vga serial0
qm set 9000 --agent enabled=1

qm template 9000

Vous devriez voir sur Proxmox VE:

Maintenant, pour une question de simplification (dans cette première version du projet), j'ai fait en sorte de pouvoir déclarer ses vms au format YAML. ☺️

Voici un exemple :

---
vms:
  - name: "vm1"
    node_name: "mox"
    resource_name: "vm1"
    vm_id: 1000
    agent:
      enabled: false
      trim: true
      type: "virtio"
    bios: "seabios"
    cpu:
      cores: 1
      sockets: 1
    cloud_init:
      type: "nocloud"
      datastore_id: "local-lvm"
      dns:
        domain: "homelab.lan"
        server: "1.1.1.1 1.0.0.1"
      ip_configs:
        - ipv4:
            address: "192.168.0.110/24"
            gateway: "192.168.0.254"
        - ipv6:
            address: "fd91:0812:a17f:6194::10/64"
            gateway: "fd91:0812:a17f:6194::1"
      user_account:
        username: "ubuntu"
        password: "ubuntu"
        keys:
          - ssh-rsa AAAAB3Nza .........
    clone:
      node_name: "mox"
      vm_id: 9000
      full: true
    disks:
      - disk1:
          interface: "scsi0"
          datastore_id: "local-lvm"
          size: 32
          file_format: "raw"
          cache: "none"
      - disk2:
          interface: "scsi1"
          datastore_id: "local-lvm"
          size: 32
          file_format: "raw"
          cache: "none"
    memory:
      dedicated: 512
    network_devices:
      - net1:
          bridge: "vmbr0"
          model: "virtio"
      - net2:
          bridge: "vmbr0"
          model: "virtio"
    on_boot: true
  - name: "vm2"
    node_name: "mox"
    resource_name: "vm2"
    vm_id: 1001
    agent:
      enabled: false
      trim: true
      type: "virtio"
    bios: "seabios"
    cpu:
      cores: 1
      sockets: 1
    cloud_init:
      type: "nocloud"
      datastore_id: "local-lvm"
      dns:
        domain: "homelab.lan"
        server: "1.1.1.1 1.0.0.1"
      ip_configs:
        - ipv4:
            address: "192.168.0.111/24"
            gateway: "192.168.0.254"
        - ipv6:
            address: "fd91:0812:a17f:6194::10/64"
            gateway: "fd91:0812:a17f:6194::1"
      user_account:
        username: "ubuntu"
        password: "ubuntu"
        keys:
          - ssh-rsa AAAAB3Nza .........
    clone:
      node_name: "mox"
      vm_id: 9000
      full: true
    disks:
      - disk1:
          interface: "scsi0"
          datastore_id: "local-lvm"
          size: 32
          file_format: "raw"
          cache: "none"
      - disk2:
          interface: "scsi1"
          datastore_id: "local-lvm"
          size: 32
          file_format: "raw"
          cache: "none"
    memory:
      dedicated: 512
    network_devices:
      - net1:
          bridge: "vmbr0"
          model: "virtio"
      - net2:
          bridge: "vmbr0"
          model: "virtio"
    on_boot: true

Et le coeur du projet en Python qui vient lire les informations du fichier vms.yaml et les importer pour les créer avec Pulumi sur Proxmox VE.

import yaml
import pulumi
import pulumi_proxmoxve as proxmox

with open('vms.yaml', 'r') as file:
    yaml_content = file.read()

parsed_data = yaml.safe_load(yaml_content)

for vm in parsed_data['vms']:
    disks = []
    nets = []
    ip_configs = []
    ssh_keys = []

    for disk_entry in vm.get('disks', []):
        disk = disk_entry.popitem()[1]
        disks.append(
            proxmox.vm.VirtualMachineDiskArgs(
                interface=disk.get('interface', ''),
                datastore_id=disk.get('datastore_id', ''),
                size=disk.get('size', 0),
                file_format=disk.get('file_format', ''),
                cache=disk.get('cache', '')
            )
        )

    for ip_config_entry in vm['cloud_init']['ip_configs']:
        ipv4 = ip_config_entry.get('ipv4')
        ipv6 = ip_config_entry.get('ipv6')

        if ipv4:
            ip_configs.append(
                proxmox.vm.VirtualMachineInitializationIpConfigArgs(
                    ipv4=proxmox.vm.VirtualMachineInitializationIpConfigIpv4Args(
                        address=ipv4.get('address', ''),
                        gateway=ipv4.get('gateway', '')
                    )
                )
            )

        if ipv6:
            ip_configs.append(
                proxmox.vm.VirtualMachineInitializationIpConfigArgs(
                    ipv6=proxmox.vm.VirtualMachineInitializationIpConfigIpv6Args(
                        address=ipv6.get('address', ''),
                        gateway=ipv6.get('gateway', '')
                    )
                )
            )

    for ssk_keys_entry in vm['cloud_init']['user_account']['keys']:
        ssh_keys.append(ssk_keys_entry)


    for net_entry in vm.get('network_devices', []):
        net = net_entry.popitem()[1]
        nets.append(
            proxmox.vm.VirtualMachineNetworkDeviceArgs(
                bridge=net.get('bridge', ''),
                model=net.get('model', '')
            )
        )

    virtual_machine = proxmox.vm.VirtualMachine(
        vm_id=vm['vm_id'],
        resource_name=vm['resource_name'],
        node_name=vm['node_name'],
        agent=proxmox.vm.VirtualMachineAgentArgs(
            enabled=vm['agent']['enabled'],
            trim=vm['agent']['trim'],
            type=vm['agent']['type']
        ),
        bios=vm['bios'],
        cpu=proxmox.vm.VirtualMachineCpuArgs(
            cores=vm['cpu']['cores'],
            sockets=vm['cpu']['sockets']
        ),
        clone=proxmox.vm.VirtualMachineCloneArgs(
            node_name=vm['clone']['node_name'],
            vm_id=vm['clone']['vm_id'],
            full=vm['clone']['full'],
        ),
        disks=disks,
        memory=proxmox.vm.VirtualMachineMemoryArgs(
            dedicated=vm['memory']['dedicated']
        ),
        name=vm['name'],
        network_devices=nets,
        initialization=proxmox.vm.VirtualMachineInitializationArgs(
            type=vm['cloud_init']['type'],
            datastore_id=vm['cloud_init']['datastore_id'],
            dns=proxmox.vm.VirtualMachineInitializationDnsArgs(
                domain=vm['cloud_init']['dns']['domain'],
                server=vm['cloud_init']['dns']['server']
            ),
            ip_configs=ip_configs,
            user_account=proxmox.vm.VirtualMachineInitializationUserAccountArgs(
                username=vm['cloud_init']['user_account']['username'],
                password=vm['cloud_init']['user_account']['password'],
                keys=ssh_keys
            ),
        ),
        on_boot=vm['on_boot']
    )
    
    pulumi.export(vm['name'], virtual_machine.id)

Il ne reste plus qu'à vérifier les modifications qui vont être apportées (équivalent du plan sur Terraform) :

pulumi preview
Previewing update (dev)

View in Browser (Ctrl+O): https://app.pulumi.com/........

     Type                            Name       Plan       
     pulumi:pulumi:Stack             pulumi-pro             
 +   ├─ proxmoxve:VM:VirtualMachine  vm2        create     
 +   └─ proxmoxve:VM:VirtualMachine  vm1        create   

Il ne reste plus qu'à déployer nos modifications.

pulumi up

Vous pouvez retrouver tout le code ici :

GitHub - juhnny5/pulumi-proxmox-cloud-init: Manage Proxmox VE vms with Pulumi

Manage Proxmox VE vms with Pulumi. Contribute to juhnny5/pulumi-proxmox-cloud-init development by creating an account on GitHub.

juhnny5GitHub

Si vous souhaitez clean tout ça, vous pouvez lancer un destroy. 😈

pulumi destroy

Il y a pas très longtemps sur Twitter, j'annoncais avoir installé OpenWRT sur des bornes Cisco Meraki MR42 (non pas sans mal). 😅

Lien du Tweet en question : https://twitter.com/ju_hnny5/status/1679581547513389057?s=20

Avant de commencer, j'imagine que le projet OpenWRT ne parle pas à tout le monde, pour faire sur ce qu'est ce projet puisque sa présentation n'est pas le but de cet article est :

• Un firmware open source (basé sur GNU/Linux) permettant de recycler du vieux matériel ou du matériel propriétaire en routeur libre. 😍

Ce n'est pas forcémment toujours très facile à déployer mais ça a le mérite de permettre de recycler du matériel voué à la poubelle (comme le matériel Cisco Meraki, qui sans licence ne sert à rien).

J'avais d'aillers déjà écrit un précédent article sur le déploiement d'OpenWRT sur une borne MR33 qui est lisible ici. 😎

Intéressant mais commençons à détailler ce qu'est OpenWISP.

Qu'est-ce qu'un contrôleur Wi-Fi ? 🤪

Avant de parler d'OpenWISP, j'aimerais simplement faire un rappel de ce qu'est un contrôleur Wi-FI, de son intérêt pour que vous puissiez facilement comprendre l'intérêt d'OpenWISP. 😋

Ainsi un contrôleur Wi-Fi va principalement servir à :

• Gérer de manière centralisée un ensemble de bornes Wi-Fi (leurs configurations, leurs utilisateurs; leurs mises à jours, etc).
• Collecter (superviser) l'état en temps réel des différentes bornes.
• Fournir des informations rapide sur l'emplacement des bornes et intéragir avec elles.
• Fournir de l'accès dynamique (via RADIUS ou autre) et/ou un portail captif (pratique dans des contextes de lieux publiques comme des hôtels, restaurants mais aussi du BYOD).
• Et bien d'autres choses ! 😎

Ok cool, mais OpenWISP dans tout ça ? Eh bien globalement il fait tout ce qui est cité plus haut ! 🤓

Installer OpenWISP 2

Globalement, la meilleure manière (et surtout la plus simple), c'est par le biais de la collection Ansible fournit par OpenWISP.

Pour ce faire, il faut commencer par install cette collection :

ansible-galaxy install openwisp.openwisp2
ansible-galaxy collection install "community.general:>=3.6.0"
ansible-galaxy collection install "ansible.posix"

On va créer ensuite le dossier où l'on va travailler :

mkdir ~/openwisp2-ansible-playbook
cd ~/openwisp2-ansible-playbook

On va créer le fichier d'inventaire :

[controller]
openwisp.homelab.lan

Et maintenant créer le playbook.yml :

- hosts: controller
  become: "{{ become | default('yes') }}"
  roles:
    - openwisp.homelab.lan
  vars:
    openwisp2_default_from_email: "contact@homelab.lan"

Ne reste plus qu'à appliquer le playbook :

Biensûr, il faudra remplacer <user> par votre nom d'utilisateur souhaité ! 😁

Il ne restera plus qu'à tenter d'accéder à l'interface Web :

• https://mon_ip/admin

Maintenant, nous devons y joindre nos bornes Wi-Fi.

Installer l'agent OpenWISP 2

Ce n'est pas magique, pour qu'OpenWISP soit capable de déployer des configurations et intérragir avec les bornes, il faut déployer l'agent sur celles-ci. 😄

Pour ce faire :

opkg update
opkg install https://storage.googleapis.com/downloads.openwisp.io/openwisp-config/latest/openwisp-config_1.1.0a-1_all.ipk

Il faut redémarrer le service après installation :

/etc/init.d/openwisp_config start

On va à présent configurer l'agent pour qu'il sache qui contacter en éditant le fichier /etc/config/openwisp et en ajoutant le contenu suivant :

config controller 'http'
        option url 'https://192.168.4.1'
        option verify_ssl '0'
        option management_interface 'br-lan'
        option uuid '4917xxxxxxxx'
        option key '91d9xxxxxx'
        option shared_secret 'dPacHxxxxxx'

Il ne restera qu'à redémarrer une nouvelle fois le service :  

/etc/init.d/openwisp_config start

A noter que la partie uuid, key et shared_secret est à récupérer dans l'interface lorsque vous déclarez votre nouvel AP. 😇

Une fois que c'est OK, on peut visualiser les bornes ici :

• https://mon_ip/admin/config/device/

Publier un SSID en roaming 🥸

Comme première configuration, nous allons déployer un nouveau réseau Wi-Fi (visible via le SSID) en roaming, quand je parle de roaming, je parle de la norme 802.11r.

Cette norme permet aux appareils de se déplacer sans se déconnecter en passant d'une borne à l'autre (ce que l'on appelle également donc du "roaming"). 😎

Sur le lab, nous avons 3 bornes espacées pour que le roaming puisse fonctionner.

Ainsi pour commencer, nous allons créer un nouveau "template" de configuration dans la section du même nom dans l'interface.

Dans notre cas, nous allons le nommer "SSID Home" (mais peu importe son nom à vrai dire ...).

Pour simplifier la suite de la configuration, nous allons devoir ajouter 2 variables qui seront réutilisées, à savoir le nom du SSID et le mot de passe :

Ensuite, il faudra ajouter une nouvelle interface que l'on nommera wlan0 si celle-ci n'est pas déjà utilisée sur vos bornes :

Dans mon cas je vais utiliser la radio2 de mes bornes Cisco Meraki MR42 car c'est celle qui est compatible avec le plus de normes.

Il nous faudra utiliser notre variable wlan0_ssid pour référer le SSID. A noter que le moteur de templating est jinja2 puisque l'application est écrite en Python 3.

Il faudra absolument cocher les cases :

• Roaming
• FT PSK Generate local

Les autres sont normalement pré-cochées. 🙃

Pour continuer on va déclarer la carte réseau qui fournira le réseau, dans notre cas il se nomme "lan". Et pour terminer la configuration, on va spécifier le type de chiffrement de mot de passe et la clé.

Cette configuration devrait s'appliquer automatiquement sur vos bornes. Pour vérifier, vous pouvez vous rendre sur l'interface LuCI des bornes. ☺️

Conclusion

Vous l'aurez compris, on peut facilement déployer de la configuration par le bias d'OpenWISP sur des bornes OpenWRT sans trop de difficulté et ainsi maintenir un parc homogène en terme de configuration. 😇

Bon, on va pas se le cacher, en terme de sécurité c'est pas terrible de faire ça. Dans certains cas en entreprise (ou en perso d'ailleurs), on est parfois obligé d'utiliser une version d'un package d'antan. 😆

Globalement, c'est pas hyper compliqué, pour ce faire, vous devez éditer le package :

brew edit ansible@2.9

Supprimez la ligne suivante :

disable! date: "2022-07-31", because: :unmaintained

Et ensuite, ne reste plus qu'à l'installer ! 🤷🏼‍♂️

HOMEBREW_NO_INSTALL_FROM_API=1 brew install ansible@2.9

Avant toutes choses, merci Idriss pour la photo. 😊

Après avoir publié mon premier article dans Linux Pratique, magazine spécialisé, autour du projet OctoDNS, je me suis lancé dans la conception d'un talk autour de ce sujet. 🤠

Dans l'article je présentais le fonctionnement de l'outil en donnant des exemples techniques. Intéressant mais rien ne vaut une démo et un véritable cas pratique d'utilisation de cet outil ainsi qu'un retour d'expérience.

C'est donc pour cela que je me suis lancé en croisade pour vous présenter cet outil durant Devoxx FR (encore merci à eux de m'avoir fait confiance). 🙏

J'ai donc pu y présenter d'où on vient sur la gestion des entrées DNS, les différentes tentatives réalisées avec d'autres outils comme Ansible ou Terraform qui sont bien plus utilisés. Je présente également ce pour quoi ces outils ne sont pas toujours adaptés.

J'aurais pu également présenter dnscontrol ou lexicon qui ont un fonctionnement similaire à OctoDNS, mais j'ai choisi ce dernier pour sa simplicité d'utilisation et de syntaxe, syntaxe à la portée de tout le monde.‌

J'ai pris la décision de faire 3 démos simples pour des raisons de temps (30 minutes ça passe vite) :

• créer des enregistrements sur une instance PowerDNS (on-prem)
• récupérer les enregistrements de l'instance PowerDNS au format OctoDNS (dump)
• migrer de l'on-prem (PowerDNS) vers du Cloud (AWS)

Vous retrouverez ici le code de la présentation ainsi que les slides :

GitHub - juhnny5/DevoxxFR2023-OctoDNS: DevoxxFR 2023 | Infra : Donnez de l’autonomie à vos développeurs avec OctoDNS

DevoxxFR 2023 | Infra : Donnez de l’autonomie à vos développeurs avec OctoDNS - GitHub - juhnny5/DevoxxFR2023-OctoDNS: DevoxxFR 2023 | Infra : Donnez de l’autonomie à vos développeurs avec OctoDNS

juhnny5GitHub

Bon, je commence à vieillir et certains diront (Cc Antoine Daniel) que ce n'est qu'être un boomer que de faire référence à The Office, mais bon, je n'ai que 24 ans donc bon ... Je vieillis. 😬

Sur ce, bon visionnage.

N'hésitez pas à me faire des retours, je reste novice pour le moment en tant que speaker je prends toutes vos remarques (bienveillantes). 😊

PS : J'ai déjà eu une première suggestion : Autonomie ➡️ Octonomie, merci Geoffrey. 😆

Il peut être parfois intéressant d'avoir à récupérer le nom du dépôt Git dans lequel vous travaillez. Git possède une commande pour le faire et nous allons l'utiliser pour récupérer cette information.

Cette fameuse commande est git rev-parse --show-toplevel. 😁

Le seul problème avec cette commande est quelle vous retourne le chemin complet du dépôt Git localement stocké.

Ainsi, nous récupèrerons le nom du dépôt avec Go :

package main

import (
	"bytes"
	"fmt"
	"os/exec"
	"strings"
)

func main() {
	// Run the "git rev-parse --show-toplevel" command to get the path of the top-level directory of the repository.
	cmd := exec.Command("git", "rev-parse", "--show-toplevel")

	// Get the output of the command.
	var out bytes.Buffer
	cmd.Stdout = &out
	err := cmd.Run()
	if err != nil {
		fmt.Printf("Failed to run command: %v\n", err)
	}

	// Extract the repository name from the path.
	repoPath := strings.TrimSpace(out.String())
	repoName := filepath.Base(repoPath)

	fmt.Printf("Current repository name: %s\n", repoName)
}

Le code va extraire le nom du dépôt à partir du chemin en utilisant la fonction filepath.Base.

J'espère que cela vous aidera ! 🤷🏼‍♂️

Sur ce, bonne année 2023 ! 🚀

Au travail, je suis passé du côté obscur de la force, je me suis laissé tenté par un Macbook Pro M1, la machine marche plutôt bien et j'utilise un classique pour gérer les packages à installer sur celui-ci qui est : homebrew. 😄

J'étais curieux de trouver la commande qui permet de clean tous les packages installés avec ce gestionnaire, histoire de faire un peu de ménage.

Eh bien la réponse est relativement simple :

brew remove --force $(brew list --formula) --ignore-dependencies

Et voilà !

J'avais depuis quelques temps, une borne d'accès Wi-Fi (autrement appelée Access Point, Cisco Meraki MR33) qui prenait la poussière dans l'un de mes tiroir, j'ai décidé d'essayer (sans mal), d'installer OpenWRT et de vous donner la manip à suivre pour que vous puissiez y arriver du premier coup. 😊

Cette borne m'avait été offerte à l'époque par Cisco Meraki en ayant simplement suivi un webinar, d'ailleurs ce format est toujours d'actualité chez eux. 😱

D'ailleurs, j'avais également reçu un switch PoE+ 8 ports en suivant ce webinar.

Bon, revenon à nos moutons, avant d'entreprendre quoi que ce-soit, vous devez possèder le matériel suivant :

• Des câbles Jumper Wire (x3), lien.
• Un RaspberryPI avec RaspberryPI OS
• Un tournevis torx, diammètre 4
• Un câble RJ45
• Et votre cerveau 🤯

Une fois que vous avez tout celà, vous allez devoir cloner le repo suivant sur votre Raspberry.

git clone https://github.com/julienbriault/mr33-openwrt.git

Installation des prérequis 😆

Si vous avez installé la toute dernière version de RaspberryPI OS et que vous avez fait un cat /etc/debian-release vous vous rendrez compte que celui-ci est basé sur Debian 11 (obviously). 😇

Cette version ne possède plus dans ses repos pip2 Ainsi, il nous faut l'installer manuellement :

sudo apt update; sudo apt install python2 curl -y
curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py
sudo python2 get-pip.py


# On peut vérifier que ça marche bien avec la commande
pip2 --version

Une fois que c'est fait, on va pouvoir installer la seule dépendance du script ubootwrite.py à savoir 'serial' :

pip2 install serial

‼️ A noter que toute cette partie peut être réalisée avec Docker également (allez voir le README du repo suivant).

Activation du mode console sur le RaspberryPI 🧐

Grosso merdo, sur votre Raspberry, nous allons utiliser 3 pins pour la console (dont un qui est pour la masse: GND).

Il faudra d'ailleurs faire très attention à ne pas se décaler en connectant les jumpers car sinon, ça ne risque pas de fonctionner. 😄

Ainsi pour activer ce fameux mode console (un peu comme si on voulait activer un port RS232 sur un pc classique), il faut utiliser l'utilitaire "raspi-config" en CLI et se rendre dans 'Interfacing options' > 'serial'.

Sur le prompt 1, vous devez spécifier 'no', sur le prompt 2 vous devez spécifier 'yes' pour l'activer. 🥸

Il vous faudra redémarrer dans l'idéal. Ainsi, vous pouvez ensuite contrôler avec la commande :

ls -l /dev | grep serial

Vous devriez obtenir :

• serial0 -> ttyS0
• serial1 -> ttyAMA0

Démontage et connexion

Sous votre borne, il vous faudra retirer les patins pour y dévisser les vis présentent en dessous.

Je vous conseil de vous aider d'un médiator en plastique pour déclipser la borne sans l'abîmer.

Maintenant que votre borne est éventrée. Nous allons devoir la connecter en console au RaspberryPI. 😇

Pour ce faire, munissez-vous de vos jumpers et connectez comme suit :

• GND > blanc > pin tout à droite de la borne ;
• GPIO14 > bleu > pin au centre de la borne ;
• GPIO15 > rouge > pin à gauche (à côté de celui qui possède la flèche blanche).

Il est important de noter qu'il ne faut surtout rien connecter sur le pin avec un flèche blanche sur la borne.

Une fois que c'est fait, nous allons pouvoir flasher la borne (envoyer uboot). 😊

Envoyer uboot 🤗

Pour ce faire rien de bien compliqué, vous devez utiliser les commandes suivantes :

cd mr33-openwrt/ubootwrite
chmod a+x ubootwrite.py
./ubootwrite.py --write=mr33-uboot.bin --serial=/dev/ttyS0

Lancez le script sans avoir allumé la borne, vous devriez, tant que la borne n'est pas allumée, avoir le prompt "Uploading Image".

Allumez-la, et l'upload de l'image devrait commencer.

Uboot va nous être très pratique car il va nous fournir un serveur ftp pour envoyer l'image d'OpenWRT par la suite.

Une fois que l'image est envoyée, vous devriez obtenir un "Hello from MR33 U-BOOT".

Envoyer l'image initramfs 😱

Vous devez connecter votre raspberry avec une adresse IP dans le subnet 192.168.1.0/24 pour que vous puissiez accéder à la borne qui possède à présent l'IP (192.168.1.1).

Il nous faut à présent envoyer l'image avec la commande suivante :

echo -e "openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb" | tftp 192.168.1.1

Une fois que c'est envoyé, laissez le temps au MR33 de démarrer.

Vous pouvez passer à l'étape suivante lorsque la LED d'état passe au vert et cesse de clignoter. 🤠

Il ne vous reste plus qu'à vous connecter en SSH pour valider qu'OpenWRT est bien présent. Attention à ne pas redémarrer la borne, sinon, il faudra tout recommencer, pour le moment, nous n'avons rien écrit dans la NVRAM.

ssh root@192.168.1.1
root@OpenWrt:~#

Prévoir un retour arrière 🤩

Comme nous n'avons pas encore fait de sauvegarde de l'OS déjà présent, et que nous n'avons pas écrasé la NVRAM, il nous faut le faire pour pouvoir faire une marche arrière si tel est le cas.

Pour ce faire, il faut utiliser les commandes suivantes :

file="openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb"
size=$(cat "$file" | wc -c)
ubirename /dev/ubi0 part.old part.meraki.old
ubimkvol /dev/ubi0 --size=$size --type=static 
--name=part.old

Volume ID 99, size 49 LEBs (6221824 bytes, 5.9 MiB), LEB size 126976 bytes (124.0 KiB), static, name
"part.old", alignment 1
Ubimkvol generates a new Volume ID (marked in red). This ID is used for the next command so please
replace the 99 with the correct value.

ubiupdatevol /dev/ubi0_99 "$file"

A noter que /dev/ubi0_99 correspond au Volume ID 99 présent un peu plus haut, ainsi ce numéro pourra changer en fonction du cas de figure. 😎

Installer OpenWRT pour toujours !

Maintenant que l'on a préparé un retour arrière, nous allons pouvoir installer OpenWRT, pour ça, il faut copier le fichier openwrt-ipq40xx-meraki_mr33-squashfs-sysupgrade.bin sur notre machine avec la commande :

scp openwrt-ipq40xx-meraki_mr33-squashfs-sysupgrade.bin root@192.168.1.1:/root/

Ainsi le fichier sera présent dans la home directory de root. 🤭

Il restera donc sur la machine à utiliser les commandes :

ubirename /dev/ubi0 part.safe part.meraki
sysupgrade -v openwrt-ipq40xx-meraki_mr33-squashfs-sysupgrade.bin

Une fois que c'est fait, la borne va à nouveau redémarrer, vous pourrez ensuite vous connecter à l'interface web d'OpenWRT (via http://192.168.1.1).

Restaurer le firmware d'origine 😜

Pour restaurer le firmware d'origine, il suffit d'utiliser les commande suivantes :

ubirename /dev/ubi0 part.safe part.openwrt part.old part.fallback
ubirename /dev/ubi0 part.meraki part.safe part.meraki.old part.old

# Supprimer les partitions OpenWRT
ubirmvol /dev/ubi0 --name=rootfs
ubirmvol /dev/ubi0 --name=rootfs_data

Sources

MR33 – Google Drive

Il n'y a pas très longtemps, j'ai découvert cet outil écrit en Python par Intentionet, une boîte américaine qui développe également un superbe outil nommé Batfish Enterprise.

Mais à quoi ça peut bien me servir me direz-vous ? Eh bien, ne vous est-il jamais arrivé d'avoir eu besoin d'envoyer votre configuration à un tiers mais que vous ne souhaitiez pas qu'il accède à certaines informations de celle-ci. Eh bien c'est faisable de cacher certaines informations, en les remplaçant par d'autres, avec l'outil nommé netconan. 🤯

Avant toutes choses, vous devez bien évidemment avoir Python d'installé sur votre machine et son gestionnaire de dépendances (pip ✔️).

Dès que vous avez tout ce qu'il faut pour commencer, vous pouvez utiliser la commande suivante pour installer l'outil :

pip install netconan

Maintenant que l'outil est installé, on va pouvoir commencer à jouer ! 😬

⚠️ A noter tout de même avant toutes choses que les tests ont été réalisés avec une configuration Cisco.

Pour l'exemple, j'ai utilisé un pack CVD de configuration (de Cisco obviously).

Dans ce pack on retrouve le fichier nommé "i4-201i-IWAN-CFG_Sep2017_rs32-4451x-2-confg_BGP". Pour les tests je l'ai renommé en "original-cfg". J'ai d'ailleurs supprimé les autres configs, elles ne me servent à rien pour l'exemple.

Voici un premier exemple tout simple permettant d'anonymiser les mots de passes et bien plus :

netconan -i original-cfg -o anonymized-cfg --anonymize-passwords

Vous avez plusieurs options très pratique avec cet outil qui sont :

• --anonymise-passwords qui comme son nom l'indique permet de cacher les mots de passe de la configuration par d'autres hashs. D'ailleurs cette option permet également de cacher les communautés SNMP 😜
• --anonymize-ips permet de cacher les adresses IP (v4/v6).
• --sensitive-words permet de cacher des mots sensibles comme le nom de la société, d'un client.
• On peut également cacher/remplacer les numéros d'AS dans le cas d'une configuration pour du BGP avec l'option `--as-numbers

Voici un exemple un peu plus complexe :

netconan -i original-cfg -o anonymized-cfg \
    --sensitive-words customer1,customer2,my-company \
    --anonymize-passwords \
    --anonymize-ips

On peut aller encore plus loin ? Oui ! 🤯

La section features de la doc officielle de l'outil détail comment préserverune structure utilisable, eneffet, parfois, nous souhaitons juste diffuser une configuration à un collègue tout en empêchant que celle-ci soit compréhensible par une tierse personne qui l'aurait intercepté. 😅

Vous n'aurez plus d'excuses pour échanger des configuration de manière un peu plus sécurisée à présent ! 😎

Depuis la version 1.16 de Golang, il est possible d'intégrer des fichiers statiques dans nos binaires au build. C'est faisable grâce à l'ajout d'un nouveau package nommé embed. Ce package fournit un ensemble pratique d'interfaces, de méthodes pour embarquer des fichiers statiques dans les binaires Go. 🤯

La préhistoire

Avant ça, pendant un long moment, j'utilisais un projet nommé "go-bindata" mais qui est déprécié depuis un long moment.

Bon, c'était du passé, maintenant on peut intégrer facilement un fichier statique directement dans le binaire sans passer par des dépendances autres. 😅

Un peu de doc 🎓

Vous pouvez retrouver toute la documentation du package embed en utilisant la commande :

go doc embed

Cette commande est vraiment à retenir quand on utilise Golang au quotidien, c'est super pratique, la doc n'est pas toujours très exhaustive mais le 3/4 du temps, vous avez de bons exemples.

D'ailleurs en bon complément de la documentation officielle, vous avez cet excellent livre de référence en français de Frédéric G. Marand (FGM pour les intimmes). 👏🏼

Un p'tit exemple 😆

On va se créer un petit projet Go tout simple avec un fichier .txt et .html pour l'exemple.

mkdir embed && cd $_

tree
.
├── static
│   └── index.html
├── example.txt
└── main.go

Notre code sera socké dans le fichier main.go. Go nous offre 3 façons d'intégrer du contenu dans un binaire :

• Sur type string
• Sur type byte
• Sur type FS

On va explorer chaque type, un par un, histoire de rendre plus visuel la chose! 😜

package main

import (
	_ "embed"
	"fmt"
)

func main() {
    //go:embed example.txt
    var s string
    fmt.Println(s)
}

Pour spécifier quelle variable va contenir le contenu du fichier statique example.txt, on va utiliser un commentaire uniquement lu par le compilateur Go. Ce commentaire est //go:embed suivit du nom de votre fichier. A noter qu'il ne faut surtout pas qu'il y ait d'espace entre "//" et "go", l'espace transformerait la chose en commentaire standard du langage. 🤗

Ainsi dans notre fichier, on retrouve le contenu suivant :

Hello with embed package! 😜

Et donc maintenant si on exectute notre programme :

$ go run main.go
Hello with embed package! 😜

Ok, c'est cool me direz-vous, maintenant voyons plutôt comment embarquer tout un répertoire avec embed.FS. 😎

package main

import (
	"embed"
	"fmt"
	"html/template"
	"os"
)

func main() {
	//go:embed static/*
	var assetData embed.FS
	t, err := template.ParseFS(assetData, "static/index.html")
	if err != nil {
		fmt.Println(err)
	}
	templateData := struct {
		Title string
	}{
		Title: "File inside Go binary",
	}
	t.Execute(os.Stdout, templateData)
}

embed.FS nous permet d'intégrer une arborescence de fichiers statiques, c'est-à-dire, dans notre cas, d'embarquer le répertoire static dicté par la directive //go:embed static/*.

Ce répertoire, comme vous avez pu le constater plus haut ne possède qu'un fichier : index.html, bien sûr, ça fonctionne avec tout un ensemble. 😜

D'ailleurs ce fichier possède le contenu suivant :

<html>
  <head>
    <title>{{$.Title}}</title>
  </head>
  <body>
    <h1>Go is so cool!!!!</h1>
  </body>
</html>

Les patterns de la directive ne peuvent pas contenir de "." ou ".." ni commencer par un slash pour déclarer un chemin vers un répertoire.

Pour correspondre à tout ce qui se trouve dans le répertoire courant, il faut utiliser le "*" (comme ici : //go:embed static/* ). 😅

Et donc :

$ go run main.go 
<html>
  <head>
    <title>File inside Go binary</title>
  </head>
  <body>
    <h1>Go is so cool!!!!</h1>
  </body>
</html>