Ubuntu on Zwindler's Reflection

Sidero Omni - Talos Linux sur Oracle Cloud (en free tier)

Sat, 04 Jan 2025 18:00:00 +0200

Fun fact, le 4 janvier 2024 (il y a tout pile un an donc), mon premier article de l’année était sur Maas. Commencer 2025, le même jour, avec un autre article à propos d’une solution qui vise à automatiser de l’infra, notamment en bare metal, c’est drôle :)

Contexte

J’ai gagné !!!

Je joue de temps en temps à des jeux sur les réseaux sociaux (plus rarement maintenant) et il m’arrive aussi de faire des concours parfois en conférence.

Et là, j’ai gagné un an d’abonnement au SaaS de Sidero Labs (les créateurs de Talos Linux), Omni.

Pour celles et ceux qui se demandent, Omni est une solution de déploiement de clusters Kubernetes qui permet d’orchestrer des serveurs sous Talos, un système d’exploitation Linux minimaliste et sécurisé dédié à Kubernetes. Pour ce qui est de Talos, on en reparlera certainement dans de prochains articles.

Quel rapport avec Oracle Cloud ?

Gagner, c’est bien, ça fait toujours plaisir. Mais j’en fais quoi, désormais, de ce SaaS ?

La première idée qui vient à l’esprit est de commander un serveur dédié quelque part et d’installer Talos dessus (avec un ISO généré par Omni), ou alors de faire la même chose, mais d’installer un hyperviseur, puis de créer des VMs Talos Linux (là encore, grâce à Omni).

Mais je suis ~~radin~~ un éternel économe et j’ai vu qu’Oracle Cloud Infrastructure (OCI) est supporté par Talos Linux et Omni, et donc j’ai voulu essayer.

Pour ceux qui ne connaissent pas OCI, j’ai fait une série d’articles en 2023 pour expliquer comment créer un cluster gratuit avec kubeadm sur le free tier (assez généreux) :

On va donc réutiliser le free tier ici, mais pour déployer et gérer des clusters avec Omni.

Note : vous pouvez les relire, mais j’ai fait mieux depuis car j’ai réussi à intégrer les machines du free tier DANS un cluster Kubernetes managé, bien plus agréable à utiliser. Stay tuned pour l’article à venir ;).

Prérequis

Pour Talos Linux sur Oracle Cloud Infrastructure (OCI) et plus spécifiquement intégrer les machines à Omni, il y a quelques étapes de configuration nécessaires.

Note : ce tutoriel s’appuie partiellement sur la documentation officielle de Talos Linux, adaptée pour Omni et avec des détails complémentaires sur Oracle Cloud Infrastructure.

Je pars du principe que vous avez déjà un compte sur Oracle Cloud Infrastructure, ainsi que les binaires talosctl et la CLI oci. Sinon un petit :

brew update && brew install oci-cli talosctl

Authentifiez-vous avec l’outil CLI :

oci session authenticate

Lorsque l’authentification est demandée, choisissez la région correspondant à votre localisation (par exemple, eu-paris-1). Une fois terminé, vous verrez un message de confirmation dans le navigateur et il faudra donner un petit nom mignon au profil pour oci dans le terminal et valider.

Récupération du compartment ID

Un des concepts intéressants d’Oracle Cloud Infrastructure (qu’on retrouve chez d’autres cloud providers sous une forme ou une autre) est la notion de “compartment”. Grosso modo, les ressources sont stockées dans des “compartiments” (la traduction littérale fonctionne pour comprendre) pour organiser les ressources.

On peut travailler dans le “root” compartment, mais c’est quand même plus propre d’en créer un spécifique pour l’occasion.

Exemple d’OCID :

ocid1.compartment.oc1..aaaaaaaayrmiilkb5m2b7never345435gonna345give87978you12upu6ifoh6csihm4awsjq

Préparation de l’environnement Oracle Cloud

Une fois qu’on a ça, on va utiliser la CLI pour créer tous les trucs dont on va avoir besoin pour que nos machines virtuelles puissent s’enregistrer sur le SaaS d’omni.

Création d’un VCN (Virtual Cloud Network) et configuration réseau :

export cidr_block=10.0.0.0/16
export subnet_block=10.0.0.0/24
export compartment_id=<votre_ocid_compartment>

Créer le VCN et le sous-réseau :

export vcn_id=$(oci network vcn create --cidr-block $cidr_block --display-name talos-example --compartment-id $compartment_id --query data.id --raw-output)
export rt_id=$(oci network subnet create --cidr-block $subnet_block --display-name kubernetes --compartment-id $compartment_id --vcn-id $vcn_id --query data.route-table-id --raw-output)

À l’issue de la 2e commande, on récupère non pas l’OCID du subnet (on n’en a pas besoin), mais celui de la “Route Table”, un sous-composant du subnet, qui permet de définir la table de routage du subnet qu’on vient de créer.

Configurer une passerelle (Internet Gateway) :

export ig_id=$(oci network internet-gateway create --compartment-id $compartment_id --is-enabled true --vcn-id $vcn_id --query data.id --raw-output)

Ajouter une règle de routage (à notre route table) pour permettre l’accès Internet :

oci network route-table update --rt-id $rt_id --route-rules "[{\"cidrBlock\":\"0.0.0.0/0\",\"networkEntityId\":\"$ig_id\"}]" --force

Désactiver les règles par défaut du pare-feu (YOLO) :

export sl_id=$(oci network vcn list --compartment-id $compartment_id --query 'data[0]."default-security-list-id"' --raw-output)

À partir de là, on a la partie réseau fonctionnelle, prête à accueillir nos machines !

Mais ce n’est pas terminé :-/

Chez Oracle Cloud Infrastructure, il est possible de booter une liste d’OS prédéfinis, mais dans notre cas, Talos Linux n’est pas dans la liste.

Heureusement, Omni va nous générer un disque virtuel préconfiguré avec nos credentials, qui va nous permettre d’enrôler des serveurs Talos Linux à notre SaaS Omni dès le premier boot. Classe 😎.

On se connecte donc à notre interface Omni et on télécharge l’image de Talos Linux adaptée :

Ici, j’ai choisi la version 1.9.1 (la toute dernière car on aime le danger), pour architecture amd64. Je récupère l’image oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz que je décompresse :

xz --decompress ./oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz

Rappel : le free tier d’OCI consiste en :

2 machines amd64 de 1 oCPU (= vCPU) et 1 Go de RAM chacune
une combinaison flexible d’instances arm64 ayant 1 x n oCPU et 6 x n Go, tant que le total n’excède pas 4 oCPU (et donc 6x4 = 24 Go de RAM).

Sur OCI, il existe plusieurs formats pour importer des disques. Le plus simple est d’utiliser le format “maison” d’OCI (le .oci, extra original comme nom), qui se compose d’un fichier de métadonnées et du QCOW2.

Créez le fichier de métadonnées pour l’importation, avec la shape VM.Standard.E2.1.Micro car on a une image amd64 (sinon c’est VM.Standard.A1.Flex) :

cat > image_metadata.json << EOF
{
 "version": 2,
 "externalLaunchOptions": {
 "firmware": "UEFI_64",
 "networkType": "PARAVIRTUALIZED",
 "bootVolumeType": "PARAVIRTUALIZED",
 "remoteDataVolumeType": "PARAVIRTUALIZED",
 "localDataVolumeType": "PARAVIRTUALIZED",
 "launchOptionsSource": "PARAVIRTUALIZED",
 "pvAttachmentVersion": 2,
 "pvEncryptionInTransitEnabled": true,
 "consistentVolumeNamingEnabled": true
 },
 "imageCapabilityData": null,
 "imageCapsFormatVersion": null,
 "operatingSystem": "Talos",
 "operatingSystemVersion": "1.9.1",
 "additionalMetadata": {
 "shapeCompatibilities": [
 {
 "internalShapeName": "VM.Standard.E2.1.Micro",
 "ocpuConstraints": null,
 "memoryConstraints": null
 }
 ]
 }
}
EOF

Et créez ensuite l’image pour l’importation :

qemu-img convert -f raw -O qcow2 oracle-amd64-omni-zwindler-v1.9.1.raw oracle-amd64-omni-zwindler-v1.9.1.qcow2
tar zcf oracle-amd64-omni-zwindler-v1.9.1.oci oracle-amd64-omni-zwindler-v1.9.1.qcow2 image_metadata.json

Importation de l’image sur Oracle Cloud

On a le fichier prêt à être uploadé… mais on l’uploade où ??

Pas de chance, cette étape se fait en 2 parties. D’abord, il faut uploader le fichier .oci sur un bucket. C’est assez simple à faire dans l’UI (on aurait aussi pu le faire en CLI) :

Créez un bucket dans la section Storage pour uploader l’image compressée.
Uploadez l’image (oracle-amd64-omni-zwindler-v1.9.1.oci) dans ce bucket.

Deuxième étape, on transforme le fichier en “Custom images” (dans la section Compute) :

Cette étape est bizarrement assez longue, l’image qui ne fait que 100 Mo a pris 10 minutes à chaque essai que j’ai fait pour l’instant.

Création de la VM

Une fois l’image importée, on peut maintenant utiliser notre image customisée par Omni pour booter nos machines free tier.

Je l’ai fait là aussi via l’interface OCI, mais là encore, on pourrait le faire en CLI.

Quelques secondes après le boot, elle apparaît dans l’UI d’Omni et peut être ajoutée à un cluster.

Have fun !!

Addendum : est-ce que c’est vraiment gratuit ?

Oui…-ish.

En théorie, les machines sont gratuites (forever free comme ils disent). Mais attention, plein de petits trucs peuvent être payants.

Par exemple, le bucket sur lequel on a uploadé le QCOW2/.oci est très probablement payant. Idem pour la custom image, qui est facturée comme 1 Go de stockage (selon l’UI, je n’ai pas encore la facture LOL).

Si vous mettez les VMs derrière un load balancer (il n’y a pas de raison que vous le fassiez ici), attention, seul le LB “non flexible” bridé à 10 Mbps est gratuit (et un seul).

Et si comme moi, vous avez déjà 4 disques de 50 Go, le stockage de l’OS est payant (1,85€ / mois).

Bref, vous l’aurez compris, c’est comme souvent dans le cloud, rien n’est vraiment gratuit et il faut bien lire tous les petits caractères.

Déployer un hyperviseur VMware ESXi avec MAAS

Mon, 08 Jan 2024 18:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Résumé des épisodes précédents

Dans les deux derniers épisodes, on a vu comment déployer MAAS sur un lab perso, comment déployer ensuite nos premiers OS sur des machines baremetal de manière automatisée, comment les customiser en changeant de version d’Ubuntu ou avec cloud-init.

Mais dans les promesses de MAAS, il y a plus que ça. En théorie, on doit pouvoir démarrer “out of the box” (ouais pas tout à fait, mais je ne spoil pas plus) des serveurs d’autres OS, comme Windows (beurk) ou des hyperviseurs VMware ESXi. Et même plus (mais ça n’est pas le but de cet article pour l’instant).

ESXi ?

Vous l’avez compris, point de Windows Server dans ce tutoriel, cependant sachez qu’avec les deux liens que j’ai déjà donnés dans l’article précédent, vous devriez pouvoir vous en sortir :

Même si c’est un hyperviseur propriétaire, j’ai quand même passé pas mal de temps à travailler avec VMware et j’ai toujours été relativement content d’ESXi (no comment sur le reste de la “suite” par contre).

Note : vous pouvez d’ailleurs retrouver tous les articles qui parlent de VMware sur ce blog, ça date un peu, mais il reste peut-être des trucs utiles.

On va donc voir si c’est si facile que ça…

Ubuntu Pro ?

La première chose qu’on apprend dans la doc, c’est qu’il existe 2 manières de customiser des OS non Ubuntu pour les faire marcher dans MAAS :

Packer MAAS
MAAS Image Builder

MAAS Image Builder nécessitant une souscription Ubuntu Pro, je vais évidemment me rabattre uniquement sur Packer MAAS…

Heureusement, le projet est relativement bien fourni, avec des CentOS (8 ou 9 stream), des Debian jusqu’à la 12, et donc… VMware ESXi, de la 6 à la 8.

Pour cet article, je me suis d’abord basé sur le tutoriel officiel, mais il est sévèrement “pas à jour” (on a un petit doute dès la première étape qui demande d’utiliser Ubuntu 18.04) et pointe vers des versions obsolètes…

Installer Packer

Comme son nom le laisse deviner, on va avoir besoin de Packer, un tool de mes copain⋅es de chez Hashicorp. Pour l’instant personne n’a forké Packer, donc :

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install packer

On vérifie que ça a bien marché

packer --version
 Packer v1.10.0

Récupérer un ISO chez VMware

Alors, là, c’est la partie pénible. Si on n’est pas client VMware, il n’est pas possible de télécharger d’ISO de VMware ESXi sans :

se créer un compte
demander un trial sur une version (idéalement la dernière) d’ESXi

C’est pénible, ça demande plein d’infos personnelles et ça pourri les BAL, mais bon… c’est ça aussi, d’utiliser des logiciels privateurs. Avant, l’usage de l’ESXi était gratuit, mais visiblement, c’est de l’histoire ancienne…

Pas de bol, j’avais fait mes premiers tests sur VMware ESXi 8.0u1, et j’ai voulu récupérer la u2, mais voici ce que me dit VMware

Your evaluation has expired on August 29, 2023

Pour paraphraser un certain Linus T., F… YOU VMware! Tant pis, je vais donc faire avec l’ISO que j’ai…

VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso

Récupérer packer-maas

Si vous suivez le tuto que je vous ai donné en début d’article, il y a un moment où on va vous demander un Nom/Prénom/Email pour avoir le droit de télécharger un script pour transformer notre ISO VMware en image MAAS.

maas.io/vmware-images

Sauf que :

l’archive que vous allez télécharger est obsolète et ne fonctionnera pas
les sources et les releases sont dispos et à jour sur le github du projet

Rant: Je suis éventuellement OK pour donner mes informations personnelles en échange de l’outil, mais s’il vous plait, gardez vos tutos à jour !?!

On va donc plutôt télécharger directement la dernière version de packer-maas qui supporte les Debian et des variantes de RHEL supplémentaires :) et est disponible ici (page de la release / archive tgz)

wget https://github.com/canonical/packer-maas/archive/refs/tags/v1.1.0.tar.gz
tar xzf v1.1.0.tar.gz
cd packer-maas-1.1.0/vmware-esxi/

Construire l’image VMware ESXi pour MAAS

On commence par charger le driver nbd. Si comme moi, vous ne savez pas ce que c’est, sachez que c’est Network Block Devices.

sudo modprobe nbd
# si ça ne renvoie rien, c'est bon

Ensuite, on lance Packer avec les arguments suivants :

sudo packer init .
sudo PACKER_LOG=1 packer build -var 'vmware_esxi_iso_path=../../VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso' .

Note: packer-maas fourni aussi un Makefile pour vous simplifier encore plus la vie… Vous pouvez juste lancer make ISO=/path/to/VMware-VMvisor-Installer.iso

À ce moment-là, les scripts de packer-maas vont booter une VM avec notre ISO et réaliser des actions pour “l’installer” en envoyant des caractères dans une session VNC !

Quand on y réfléchit, c’est à la fois un peu bourrin et awesome à la fois.

Si tout se passe bien, vous devriez vous retrouver avec un fichier vmware-esxi.dd.gz au bout de quelques minutes.

ESXi dans MAAS

Maintenant qu’on a notre image, on va l’envoyer dans MAAS !

Sur l’UI, récupérer une clé pour API (sinon on ne pourra pas pousser l’image) sur votre utilisateur (il doit être avec des privilèges admin) :

Je n’ai pas trouvé de menu dans la GUI pour le faire, mais on peut loguer notre terminal avec la commande suivante (en n’oubliant pas de renseigner l’API key) :

maas login admin http://192.168.x.y:5240/MAAS/
API key (leave empty for anonymous access):

Puis envoyer l’image en CLI

maas admin boot-resources create name='esxi/8.0u1' title='VMware ESXi 8.0u1' architecture='amd64/generic' filetype='ddgz' content@=vmware-esxi.dd.gz

Note 1 : ne faites pas de Packer sur une partition Windows montée sous Linux (fuse + packer = KK) Note 2 : si vous avez installé MAAS en tant que snap sur votre poste, vous ne pouvez accéder aux fichiers que dans votre /home (vous vous prendrez un “no such file or directory”)

À partir de là, elle devrait apparaitre dans la liste des “Images” disponibles !

Let’s go la déployer sur une machine du lab… Et au bout de quelques minutes…

Victoire !

Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Thu, 04 Jan 2024 06:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Introduction

Dans la première partie, nous nous étions arrêté au moment où MAAS était installé sur un Raspberry Pi, routeur entre mon LAN et mon lab. Nous avions également déployé un OS (Ubuntu 20.04 par défaut) pour valider que l’installation fonctionnait

Dans cette partie, on va essayer d’aller un peu plus loin et de faire des trucs plus funs pour déployer des OS différents, et pourquoi pas des hyperviseurs !

Modifier l’OS par défaut

Il est possible de modifier l’OS installé par défaut sur nos machines lors des phases “Commissioning” et “Deploying”

Comme j’avais déjà récupéré les ISO pour Ubuntu 22.04, j’ai donc essayé de modifier toutes les étapes en Ubuntu 22.04.

La procédure est assez simple, on peut même changer le kernel par défaut (pratique pour profiter des dernières avancées eBPF, notamment si vous voulez faire du Kubernetes! )

Rappel : la phase commissioning sert à faire une première installation d’un hôte minimal pour l’enrôler dans notre pool de serveurs disponibles avec MAAS, en vue d’une future installation. Si on veut modifier l’OS installé par défaut quand on déploie une machine, c’est bien le menu de la phase “Deploying” qu’il faut modifier.

Déployer un hôte “KVM”

Par défaut, il est également possible de déployer des hôtes qui vont gérer des machines virtuelles directement depuis MAAS.

Même si j’avais le doute au début, les machines LXD sont bien de vraies machines virtuelles (pas de containers LXC), comme l’explique la documentation officielle LXD vs libvirt - maas.io/docs/virtual-machines (lien mort, j’utilise Internet Archive)

Both libvirt KVMs and LXD VMs are based on QEMU, but LXD VMs offer more advantages such as enhanced security and a robust API. Unlike libvirt KVMs, LXD VMs can be managed remotely without requiring SSH access.

A noter, les machines libvirt sont aujourd’hui considérées comme “legacy” et il n’est pas possible d’en ajouter provenant de l’extérieur dans l’UI 3.4.0 beta que j’ai installé, contrairement aux machines LXD qui peuvent être ajoutées à MAAS même si elles ne sont pas sur des serveurs gérés par MAAS.

On peut ensuite aller dans virsh/LXD (selon ce qu’on a choisi) et poper des VMs depuis l’interface de MAAS.

Et ce qui est rigolo, c’est qu’on peut ensuite installer des trucs sur ces machines, qui se retrouvent dans notre liste :

Machines making machines! How perverse.

– C3PO - Star Wars Episode 2

Et on peut déployer des trucs dessus bien sûr ;-)

Bon, ce n’est par contre pas spécialement user friendly (mais ça marche). L’idée est probablement un peu plus utile avec Juju (que je ne testerai pas ici).

VM hosts offer unique benefits when integrated with Juju, including dynamic VM allocation with custom interface constraints.

Customiser son OS avec cloud-init

Avouez que déployer des OS nus (juste l’OS, rien d’autre) avec MAAS, c’est cool, mais c’est quand même un poil limité en prod. Pour aller plus loin, MAAS nous donne accès à plusieurs mécanismes pour customiser notre OS.

Pour faire simple et parce que c’est devenu un des standards du marché, je vais tester l’utilisation de cloud-init avec MAAS pour customiser mon OS.

Et parce que j’aime Kubernetes, je vais poper un “cluster” de test avec microk8s. En l’état celà ne servira pas à grand-chose en utilisation réelle, mais ça vous donne une idée de ce qu’on peut faire avec.

#cloud-config
runcmd:
- |
# install and start microk8s
snap install microk8s --classic
microk8s start
usermod -a -G microk8s ubuntu
mkdir /home/ubuntu/.kube
chown -R ubuntu ~/.kube
apt_update: true
apt_upgrade: true
package_update: true
package_upgrade: true
package_reboot_if_required: false

Au bout de quelques minutes, la machine est déployée, et l’OS est correctement customisé :

ssh -J 192.168.x.y ubuntu@10.10.0.4

microk8s kubectl get pods
No resources found in default namespace.

Note : Ici j’utilise le RPi comme “JumpHost” car je n’ai pas d’accès direct aux machines depuis mon LAN.

Aller plus loin - déployer ses propres images sur ses machines

Ici, je tease un peu le(s) prochain(s) article(s). Ne vous attendez pas à lire la solution ici, il faudra attendre un peu ;-).

Par défaut, les OS disponibles sur MAAS proviennent d’images qui sont stockées sur maas.io. On y retrouve toutes les LTS d’Ubuntu jusqu’à la 12.04 (!?!) ainsi que les non-LTS de la 20.10 à la 23.10, et pour plusieurs architectures.

Dans la section “Other Images”, il n’y a malheureusement que CentOS 7 et 8.

Pour utiliser d’autres images, on va pouvoir utiliser des registry customs depuis l’interface ou créer nos propres builds qu’on poussera sur l’interface.

Si vous êtes trop curieux, je vous laisse quand même quelques liens qui devraient vous donner une bonne idée de ce qu’on va faire la prochaine fois.

En attendant, have fun !

Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Thu, 21 Dec 2023 14:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Introduction

Il y a quelques mois, après plusieurs discussions avec mon collègue (et ami!) Julien, j’ai voulu tester MAAS (Metal As A Service) sur mon homelab.

Pour ceux qui ne connaissent pas cet outil, c’est un logiciel qui va permettre de déployer des machines baremetal de manière automatique.

En théorie, l’outil est plutôt prévu pour faciliter le déploiement de serveurs de manière flexible en datacenters, mais il existe plusieurs exemples de personnes qui ont réussi à l’utiliser sur des NUCs ou des machines desktop.

C’est donc un parfait premier cas d’usage pour mon homelab, composé de 3 dell micro et d’un raspberry pi.

J’avais deux possibilités en termes d’architecture et j’ai d’ailleurs testé les deux. La première était de créer le lab dans mon LAN. Ca nécessite de bidouiller un peu le DHCP de ma box Bouygues pour que MAAS puisse gérer les IPs des machines ainsi que de configurer le DHCP pour propager le PXE.

A priori c’est faisable, mais j’ai trouvé ça pénible dans l’idée et potentiellement disruptif pour mon LAN perso, alors j’ai décidé de mettre le homelab dans un LAN à part, dont le RPi serait le routeur. J’ai ajouté une interface réseau à l’aide d’un adaptateur ethernet USB et roule ma poule.

A l’époque (en juin), ça n’avait pas marché (peut être à cause d’un bug ?), les machines étaient bien déployables, mais je ne pouvais pas réaliser l’action “Deploy”.

Node has no address family in common with the server

Cependant, cette fois-ci, ça a marché ! Voici donc un premier article sur le sujet !

Préparer le RPI

Avant de toucher aux Dell micro, j’ai donc commencé par configurer le Raspberry Pi, avec Rpi Imager.

https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview

Une fois la carte préparée, sur la partition system-boot, éditer le fichier config.txt pour configurer l’écran portable (ou /boot/firmware/config.txt une fois booté). Ici, ça sert juste pour mon petit écran portable 7 pouces (peut être que ça peut aider dans d’autres cas) mais je vous le mets quand même, pour info.

[all]
max_usb_current=1
hdmi_force_hotplug=1
config_hdmi_boost=10
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0

On boot le pi, on se connecte en ssh, on update/upgrade tous les packages et on reboot, histoire de commencer sur des bases saines.

Installer MAAS sur le RPI

maas.io/docs/how-to-do-a-fresh-install-of-maas

En prérequis MAAS demande de désactiver le client ntp existant pour éviter des conflits

sudo systemctl disable --now systemd-timesyncd

Et comme j’ai décidé que mes machines seraient dans un LAN à part (cf schéma ci-dessus) et que le RPi serait le “routeur” entre les deux, il faut bien sûr autoriser le routage :

sudo vi /etc/sysctl.conf
 net.ipv4.ip_forward = 1
 net.ipv6.conf.all.forwarding=1

sudo sysctl -p /etc/sysctl.conf

Et pour finir, je vais configurer mon resolver DNS dans /etc/resolv.conf sur ma Box internet

sudo vi /etc/resolv.conf
[...]
 nameserver @IP
[...]

Addendum : histoire d’éviter des soucis de changement d’adresse IP à cause de mon DHCP pourri, on fixe les IPs via une configuration netplan. Ici, mon interface ethernet du RPi est eth0 (celle reliée à mon LAN) et celle (USB) reliée à mon lab et aux 3 dell micros est enxa0cec80428b7.

vi /etc/netplan/50-cloud-init.yaml
network:
 ethernets:
 eth0:
 dhcp4: false
 addresses: [192.168.x.y/24]
 gateway4: 192.168.x.z
 nameservers:
 addresses: [9.9.9.9,192.168.x.z]
 enxa0cec80428b7:
 dhcp4: false
 addresses: [10.10.0.1/16]
 version: 2

Et on valide avec

netplan apply

Si vous suivez la doc bêtement comme je le fais moi, MAAS propose de s’installer en tant que snap. Si c’est le cas, il ne pourra accéder qu’à /home et /media (cf ce post sur le discourse de maas.io). Il existe aussi une version .deb de MAAS mais pour le test je me suis contenté de ça.

zwindler@maas:~$ sudo snap install --channel=3.4/beta maas
maas (3.4/beta) 3.4.0-14319-g.3ab76533f from Canonical✓ installed

Note : point important, l’expérience utilisateur entre la version 3.3 et la version 3.4 est significativement différente. Au delà de l’UI qui change d’un menu horizontal à un menu vertical, certaines opérations semblent ne pas être totalement identiques. Il est possible que ce tuto ne marche pas en 3.3.

Plutôt qu’installer une base PostgreSQL pour stocker les données de MAAS, je vais également simplement utiliser le snap maas-test-db, qui comme son nom l’indique, est une base de données postgres préconfigurée pour faire des tests avec MAAS (donc pas production ready !).

zwindler@maas:~$ sudo snap install maas-test-db
maas-test-db (3.3/stable) 14.2-29-g.ed8d7f2 from Canonical✓ installed

A partir de là, mon Raspberry Pi 4 modèle 2 Go (oui j’ai été radin) est à l’agonie. Heureusement, un petit reboot suffit à lui donner un second souffle.

Configurer MAAS

Une fois que c’est fait, on peut initialiser notre MAAS en mode “region+rack”. Ca va nous permettre d’avoir la totalité des fonctionnalités sur le serveur MAAS du RPi.

zwindler@maas:~$ sudo maas init region+rack --database-uri maas-test-db:///
MAAS URL [default=http://@IP:5240/MAAS]: (valider avec entrée)
[/] Performing database migrations
MAAS has been set up.

If you want to configure external authentication or use
MAAS with Canonical RBAC, please run

 sudo maas configauth

To create admins when not using external authentication, run

 sudo maas createadmin

To enable TLS for secured communication, please run

 sudo maas config-tls enable

Pour faire simple, je ne vais pas configurer une authentification externe et me contenter (là encore) de simplement créer un utilisateur local d’administration :

zwindler@maas:~$ sudo maas createadmin
Username: zwindler
Password:
Again:
Email: blog@zwindler.fr
Import SSH keys [] (lp:user-id or gh:user-id):

On peut donc ouvrir la page d’admin (http://@IP:5240/MAAS/r/) et rentrer le login/mdp qu’on vient de créer.

La première chose qu’on va nous demander c’est de finir le setup via un wizard. On va créer notre première région, ajouter nos premières images, ajouter une clé SSH

Configurer un subnet

Une fois le wizard terminé, on va avoir l’auto-découverte de ce qui se passe sur notre LAN. Le truc, c’est que dans mon cas précis, ce n’est pas ce qui est sur mon LAN (de ma box) qui m’intéresse, mais ce qui va être sur le LAN de MAAS, via mon autre interface Ethernet (USB).

Je vais donc créer un réseau interne 10.10.0.0/16 (cf la doc maas.io/docs/about-networking)

Une fois créé, je l’édite pour ajouter des infos

De retour sur la fabric, on va sur le VLAN par défaut et on configure le DHCP

Une fois que c’est fait, on va pouvoir commencer à booter des machines en PXE pour les enroller dans MAAS !!

Enroller des machines

A partir de là en vrai, il n’y a plus grand-chose à faire. J’ai configuré le BIOS de mes dell micro pour qu’il boot d’abord sur le PXE. Le serveur DHCP / PXE de MAAS sur le RPi a pris le relai, et a fait booter la machine sur une image d’enrôlement.

Au bout de plusieurs minutes, dans l’onglet Machines, on voit mon Dell micro arriver. On peut la tester :

Et là, patatra, error !

En vrai, c’est parce qu’il me manque une étape. J’ai oublié d’indiquer à MAAS comment démarrer la machine.

Dans mon cas, il ne s’agit pas de matériel de type “serveur”. Je ne peux donc pas piloter l’allumage de la machine à distance avec un ILO / iDRAC. De même, je n’ai pas pris de multiprise manageable (je vais y réfléchir cela dit). Je dois donc configurer la “power source” de la machine et indiquer comme “Power type” la valeur “Manual”.

Une fois que c’est fait, je fais un “Commission” (et j’appuie moi même si le bouton “On”).

Et si tous les tests sont bien passés, on doit se retrouver avec une machine à l’état “Ready”. A partir de là, je peux la “Deploy” (et il faut encore que j’appuie sur le bouton “On”).

Et cette fois-ci, c’est une victoire ;-)

➜ ~ ssh -J zwindler@@IP ubuntu@10.10.0.2
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-169-generic x86_64)
[...]
ubuntu@daring-tomcat:~$

Liens en vrac

Kubeadm, Ubuntu 22.04 et cilium - mes petites galères récentes

Tue, 06 Jun 2023 12:00:00 +0200

Kubernetes, le retour de la vengeance

J’ai été pas mal pris ces derniers temps, autant côté pro que côté perso, et j’ai un peu délaissé mes clusters Kubernetes (qui vivent leur vie).

Aussi, quand j’ai eu le temps de m’y remettre, j’ai perdu pas mal de temps sur plusieurs “petites” bêtises liés, la plupart du temps à des modifications introduites dans les composants de ma stacks.

Une preuve (si c’était nécessaire) qu’il est important de se maintenir à la page, à jour et surtout de bien lire les changelogs.

Voici donc la liste des soucis que j’ai rencontrés et de comment on les corrige / contourne.

cilium et kernel Ubuntu Minimal

L’an dernier, j’ai décidé de concevoir un nouveau talk inspiré de “dessine moi un cluster” de Jérôme Petazzoni. Dans ce talk dont j’ai déjà parlé ici, je construis en live coding un “cluster” Kubernetes brique par brique, binaire par binaire.

Et pour le CNI, j’avais choisi Cilium que j’utilise par ailleurs et que j’aime bien.

Sauf que 2 jours avant de monter sur scène, j’ai changé d’hébergeur un peu en urgence (problème de disponibilité) et patatra, le talk ne marchait plus. Cilium avait l’air de s’installer correctement mais les pods finissaient par crasher, rendant toute communication avec les Pods / Services de mon cluster impossible…

En creusant un peu, je suis tombé sur ces logs dans le container de l’agent cilium sur mon node :

level=warning msg="+ tc qdisc replace dev cilium_vxlan clsact" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="+ true" subsys=datapath-loader
level=warning msg="++ grep -v 'pref 1 bpf chain 0 $\\|pref 1 bpf chain 0 handle 0x1'" subsys=datapath-loader
level=warning msg="++ tc filter show dev cilium_vxlan ingress" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="Dump terminated" subsys=datapath-loader
level=warning msg="+ '[' -z '' ']'" subsys=datapath-loader
level=warning msg="+ cilium bpf migrate-maps -s bpf_overlay.o" subsys=datapath-loader
level=warning msg="+ tc filter replace dev cilium_vxlan ingress prio 1 handle 1 bpf da obj bpf_overlay.o sec from-overlay" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="We have an error talking to the kernel" subsys=datapath-loader
level=warning msg="+ cilium bpf migrate-maps -e bpf_overlay.o -r 1" subsys=datapath-loader
level=warning msg="+ return 1" subsys=datapath-loader
level=fatal msg="Error while creating daemon" error="error while initializing daemon: failed while reinitializing datapath: exit status 1" subsys=daemon

Et le message important là dedans, c’est RTNETLINK answers: Operation not supported, qui m’a permis de trouver cette issue sur le dépôt github de cilium.

Lorsque j’avais changé d’hébergeur, je n’avais pas fait attention mais les machines Ubuntu livrées l’étaient avec une install “minimal” sur laquelle il manque des capabilities, en particulier CONFIG_NET_CLS_ACT=y qui est un des prérequis de cilium.

Cependant, l’installation échoue silencieusement (ou alors c’est discret). Un gros warning aurait été le bienvenu…

L’erreur disparaît quand on change de kernel ou d’image de base.

containerd et cgroups systemd

En essayant de créer un nouveau cluster Kubernetes avec kubeadm sur des machines Ubuntu 22.04, je me suis retrouvé assez vite avec un problème bizarre et très vite bloquant : les noeuds de mon cluster etcd tombaient les uns à la suite des autres, provoquant on crash du cluster.

Alors que tout semble ok, le container s’arrête avec un laconique received signal; shutting down :

2022-02-05T00:46:42.582666628Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"embed/serve.go:188","msg":"serving client traffic securely","address":"172.31.58.179:2379"}
2022-02-05T00:46:42.582757689Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"etcdmain/main.go:47","msg":"notifying init daemon"}
2022-02-05T00:46:42.58276643Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"etcdmain/main.go:53","msg":"successfully notified init daemon"}
2022-02-05T00:46:42.582906352Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"embed/serve.go:188","msg":"serving client traffic securely","address":"127.0.0.1:2379"}
2022-02-05T00:56:02.302978572Z stderr F {"level":"info","ts":"2022-02-05T00:56:02.302Z","caller":"osutil/interrupt_unix.go:64","msg":"received signal; shutting down","signal":"terminated"}

En réalité, il s’agit d’une modification d’un paramètre de containerd que je n’avais jamais eu besoin de modifier lors de mes installations précédentes mais qui semble nécessaire maintenant.

En effet, quand on génère la configuration par défaut de container avec la commande containerd config default, la valeur SystemdCgroup est à false.

J’ai perdu un peu de temps mais heureusement je suis assez vite tombé sur cette issue, ainsi que sur la documentation officielle qui indique bien la bonne configuration à faire.

`kubeadm` et plusieurs interfaces

Jusqu’à présent, je n’avais travaillé qu’avec des nodes qui n’avaient qu’une seule IP principale. Récemment, j’ai dû configurer kubeadm sur des machines avec plusieurs IPs/VLAN.

Lorsque j’ai commencé à essayer de configurer kubeadm pour qu’il en tienne compte, je me suis emmêlé les pinceaux

J’avais bien remarqué la présence d’un flag --api-advertise dans la commande kubeadm init mais je ne pouvais pas utiliser ce flag car j’utilise des fichiers de configuration kubeadmcfg de manière à pouvoir customiser de manière plus poussée mes clusters, et l’usage de flags conjointement avec le --config n’est pas supporté

Mon erreur avait été d’insérer un le bloc localAPIEndpoint (l’équivalent du --api-advertise mais dans la config) dans la ClusterConfiguration alors qu’il faut créer un autre manifest dans le même fichier avec pour kind InitConfiguration.

---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
 advertiseAddress: 10.0.0.4
 bindPort: 6443
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controlPlaneEndpoint: 10.10.10.10
[...]

Cette valeur qui a priori semble ne concerner que l’API server override en fait tous les composants dans votre control plane (etcd, scheduler, controller manager) donc pas besoin de les configurer en plus.

A noter, pour tout ce qui est utilisation d’une Virtual IP qui loadbalancerait les requêtes vers vos APIservers, c’est bien controlPlaneEndpoint qu’il faut utiliser.

Et alors, `kubelet` et plusieurs interfaces ?

Si jamais vous voulez modifier les IPs des composants du control plane, il est probable que vous voudrez aussi modifier celle du kubelet.

Pour modifier l’InternalIP de vos nodes, il est nécessaire de modifier les paramètres dans le kubelet.conf.

A partir de là, vous avez deux possibilités. La plus simple si vous avez plusieurs hostnames pour chaque IP, est d’utiliser le paramètre --hostname-override qui va permettre d’à la fois changer le hostname par défaut de la machine quand elle s’enregistre dans Kubernetes, mais aussi L’InternalIP.

Dans mon cas, ça ne m’aidait pas car l’IP qui m’intéressait n’avait pas de résolution DNS et je ne voulais pas modifier le hostname tel qu’il était.

Pour modifier l’interface sur laquelle kubelet écoute et l’InternalIP, il est nécessaire de modifier 2 paramètres : --address (pour l’interface d’écoute) et --node-ip (modifier l’InternalIP)

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
zwindler-01 Ready control-plane 28m v1.24.14 10.0.0.4 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-02 Ready control-plane 28m v1.24.14 10.0.0.5 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-03 Ready control-plane 27m v1.24.14 10.0.0.6 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-04 Ready node 27m v1.24.14 10.0.0.7 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-05 Ready node 27m v1.24.14 10.0.0.8 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21

Ubuntu 22.04 et ManageForeignRoutes

Je ne me suis pas le seul à s’être mangé de plein fouet cette modification de systemd sur les Ubuntu récents, puisque cette modification est la “rootcause” de l’incident global de mars de Datadog (vous pouvez aller lire le postmortem ici)

Quand j’installais cilium sur des serveurs Ubuntu 22.04, instantanément, il n’était plus possible de ping et/ou contacter les IPs locale de la machine, mais aucun problème pour contacter le reste du monde.

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4076ms
$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=0.285 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=0.233 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=63 time=0.248 ms
$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
1 * * *
2 zwindler-01 (10.0.0.1) 0.084 ms 0.079 ms 0.060 ms
3 * * *
4 zwindler-01 (10.0.0.1) 0.075 ms 0.097 ms 0.081 ms
5 * * *
6 zwindler-01 (10.0.0.1) 0.121 ms 0.137 ms 0.145 ms
7 * * *
[...]

Je montre avec ping, mais c’était pareil avec tous les ports. Et donc, toutes les liveness des composants du control plane crashaient puisque je ne pouvais plus contacter les IPs locales !

En réalité, si on creuse les system requirements de cilium, c’est écrit !

Par défaut, systemd-networkd supprime toutes les routes qu’il ne connaît pas et rentre en conflit direct avec cilium, d’où les problématiques de routage cheloues.

Et c’est exactement le même problème qu’a rencontré Datadog, puisqu’ils utilisent eux aussi Ubuntu 22.04 et cilium. Quand les updates sont passées, ils se sont retrouvés avec tous leurs clusters (worldwide) en vrac.

on start-up of v248, systemd-networkd flushes all IP rules it does not know about. Five months after this initial change, an additional commit introduced in v249 made it possible to opt out of this behavior using a new ManageForeignRoutingPolicyRules setting. Both these changes were backported to systemd v248 and v247.

Mon iPad (ou Android), un écran de plus pour Ubuntu !

Fri, 05 Aug 2022 15:00:00 +0200

Astuce bien pratique

Vous avez sûrement vu des gens sur Mac connecter un iPad comme écran secondaire, en nomadisme ? C’est officiellement supporté et mis en avant comme une fonctionnalité par Apple.

De même, vous avez peut-être aussi croisé des gens qui ont investi dans des écrans secondaires nomades pour ordinateur portable (dans les 150€ souvent, parfois beaucoup plus).

Mais admettons que vous n’ayez ni Mac, ni envie de payer pour cet équipement supplémentaire, et que vous avez une vieille tablette Android ou un iPad à disposition.

C’est typiquement mon cas. J’ai un laptop sous Ubuntu et un iPad acheté il y a quelques années que j’utilise de manière occasionnelle.

Et rarement (surtout en conférence), il m’arrive d’avoir besoin d’un second écran (typiquement quand j’ai un livecoding et ma doc à côté).

GNOME 42 à la rescousse

J’avais vu passer la news sur Twitter il y a 2 mois, mais je n’avais pas encore essayé.

Tout est parti de ce commentaire sur reddit, faisant suite à cette PR.

Pour vous la faire courte, les développeurs de Gnome ont ajouté (entre autres choses), les virtual monitors dans l’implémentation du bureau à distance inclus avec Gnome.

On va tirer parti de cette fonctionnalité pour se connecter sur notre PC depuis l’iPad, mais au lieu d’afficher l’écran principal, on va afficher sur l’iPad un nouvel écran, virtuel.

Comment on l’active

Pour l’instant c’est encore un peu caché. En lisant le post reddit, vous verrez qu’il faut activer la fonction en ligne de commande

gsettings set org.gnome.desktop.remote-desktop.rdp screen-share-mode extend

Une fois que c’est fait, allez dans les paramètres (Partage ou Sharing en anglais) de votre laptop. Il faut activer “Partage” tout en haut, avant de pouvoir activer “Bureau à distance” (grisé).

On active le bureau à distance RDP (avec un login et un mot de passe hein).

On récupère notre IP avec votre méthode préférée (ip --brief address show par exemple).

Dans le cas d’un setup en nomadisme, il faudra donc connecter tout ce petit monde sur un seul et même Wi-Fi pour que ça fonctionne, ou via un VPN (sur lequel serait le laptop ET la tablette).

Client RDP

Ensuite, sur l’iPad (ou la tablette android ou tout autre device avec un écran et capable de faire du RDP), on installe un client RDP.

Le post initial parle du client officiel de Microsoft et a priori il marche bien.

On configure l’iPad pour se connecter à l’IP récupérée à l’étape d’avant, on renseigne le username et le password et …

TADAM

Premiers retours

Contrairement à la fonctionnalité officielle d’Apple ou à un écran nomade, ici c’est clairement du “just hack it”.

Mais… ça fonctionne.

crude, but effective

Il y a un peu de lag avec l’aller-retour wifi, mais c’est supportable. L’écran est bien détecté même si ça me casse le positionnement de mes écrans à chaque fois.

N’imaginez pas en revanche passer une vidéo dessus (quoique ?) ça ne sera probablement pas très agréable.

Je verrai si j’ose l’utiliser la prochaine fois que je fais un livecoding en présentiel, ou pas :).

Mon PeerTube sur Ubuntu 20.04

Mon, 06 Dec 2021 06:00:00 +0000

Pourquoi Peertube ?

Il y a plus de 15 ans (autour de 2003-2004), je m’adonnais abondamment à ma passion du moment : l’écriture, le tournage et le montage de vidéos humoristiques. J’ai fais, avec des copains, une grosse dizaine de sketch pendant une très courte période. Un genre de “Youtubeur” avant l’heure, on dira.

A l’époque, quand on voulait partager en ligne des vidéos et surtout diffuser du contenu, il n’y avait pas 50 choix. On pouvait héberger soit même les vidéos sur un serveur HTTP ou FTP, mais je n’avais (du haut de mes 16 ans) pas encore l’infrastructure nécessaire pour le faire (et encore moins la ligne télécom). Du coup, je gravais mes productions sur DVDs et les projetais à un peu tout le monde dès que j’en avais l’occasion. Pas super pratique…

C’est à peu près à ce moment là que Youtube et Dailymotion ont été créés (début 2005) et j’ai sauté sur l’occasion pour utiliser ces services qui me permettaient de diffuser à toutes mes connaissances ces vidéos sans effort.

Je n’ai malheureusement plus le temps de faire le clown comme je le faisais avant (en vrai ça m’arrive encore mais 🤫) donc pendant longtemps je me suis contenté de ces services. Cependant, je ne suis pas insensible à l’hégémonie de Google sur les services en ligne. C’est pour ça qu’en tant qu’ancien utilisateur de ce type de solutions, j’ai vu d’un très bon oeil le crowfunding en 2018 de Framasoft dans le but de créer un logiciel permettant d’héberger soit même des plateformes de streaming vidéo.

PeerTube, proposé par Framasoft, est l’alternative libre et décentralisée aux plateformes vidéos, qui vous donne accès à plus de 400 000 vidéos proposées par 60 000 utilisateur⋅ices et visionnées plus de 15 millions de fois

Je ne me suis jamais trop plus intéressé que ça, n’en ayant plus vraiment l’usage. Jusqu’à ce que je décide de rapatrier au même endroit toutes les vidéos enregistrées de tous mes talks, sur un coup de tête, un lundi soir.

Fonctionnalités

Ce que je trouve bien avec Framasoft (ainsi que d’autres outils / projets) c’est qu’ils ont bien compris qu’ils ne battraient pas les big techs en proposant un clone libre ou open source des outils du marché. Il faut proposer aux utilisateurs un logiciel avec les fonctionnalités minimales similaires certes, MAIS, aussi proposé autre chose (en plus, ou différent).

C’est totalement ce qui est fait avec PeerTube. Au delà d’une simple plateforme de streaming qu’on peut auto-héberger (et donc permettre de contribuer à un web décentralisé), c’est surtout une plateforme de streaming de vidéos en mode peer-to-peer.

Un des challenges quand on fait du streaming en ligne, a fortiori quand il s’agit de vidéo, c’est qu’il est nécessaire de disposer d’une bande passante colossale pour permettre à des centaines, milliers, voire plus, d’utilisateurs de regarder plusieurs vidéos en non synchrone en même temps (pas en multicast comme l’IPTV). C’est d’ailleurs un des terrains sur lesquels se battent les ISP contre Youtube et maintenant Netflix : un portion très significative de la bande passante totale d’Internet est consommée par ces services.

La solution “maline” est donc de permettre aux instances PeerTube de se fédérer entre elles afficher du contenu de plusieurs plateformes sur une seule, mais aussi aux clients connectés eux même de participer à l’envoie des “chunks” de vidéos à d’autres utilisateurs (en peer-to-peer). On peut ainsi héberger PeerTube sur des machines assez modestes et que ça marche quand même.

Au delà de ça, les avantages de ce type de solutions par rapport à un hébergeur central sont :

le code open source de la solution
l’absence de traçage publicitaire
l’absence de mécanismes de censure automatisée des vidéos

Qu’est ce que je rigole quand je vois certains vidéastes, open source bashers notoires, cracher sur PeerTube et vénérer le sacro-saint Youtube, qui les châtie autant qu’il les nourri…

Installer PeerTube

Bref, je venais de télécharger l’ensemble des replays de mes confs, j’avais installé une VM Ubuntu 20.04 vierge avec 2 vCPU, 4 Go de RAM et 100 Go de stockage plutôt véloce. En théorie, c’est suffisant si j’en crois cette page dédiée sizing de la doc officielle.

La documentation d’installation est elle disponible sur le site docs.joinpeertube.org. Au fil des années, j’en ai vu des docs d’install. C’est d’ailleurs une des raisons d’être du blog, certains softs étant très déficitaires de ce côté et nécessitant des explications complémentaires pour le profane.

Ce n’est pas du tout le cas ici. C’est sans aucun doute une des docs les plus claires, propres, détaillées que j’aie été amené de voir au fil des ans. D’autant qu’elle est rédigée en français et en anglais, et se paie le luxe d’être proposée pour une large gamme d’OS. Un grand BRAVO.

Bon… Elle est claire, que j’ai sauté un peu vite l’introduction 🤦‍♂️. J’ai donc évidemment commencé par louper l’encart Dependencies (oups) qui pointe vers tout ce qu’on doit installer AVANT de commencer la doc d’installation elle même…

Tout ce qui est dépendances/prérequis est donc détaillé ici.

Je vous conseille plutôt de suivre la doc d’installation plutôt que ce billet si vous voulez installer un PeerTube. Mais pour montrer que c’est vraiment simple, je vous “dump” les commandes que moi j’ai lancées, dans mon contexte personnel.

apt update
apt upgrade

apt-get install curl sudo unzip vim
apt install python3-dev python-is-python3
apt install certbot nginx ffmpeg postgresql postgresql-contrib openssl g++ make redis-server git cron wget

Une fois tout ce beau petit monde installé, on démarre redis (pas encore bien compris à quoi il servait) et postgresql.

sudo systemctl start redis postgresql

Pour l’installation de la version 14 de nodeJS, la documentation nous laisse un peu nous débrouiller, mais grosso modo on trouve tout ce qu’il faut ici.

curl -fsSL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt-get install -y nodejs

Grrrr, un curl | sudo bash en 2021…

Ensuite, rebelote pour yarn, il faut aller chercher la dernière version disponible sur Github et pas celle installable avec apt sinon ça ne fonctionnera pas (car il existe 2 versions majeures avec 2 CLI totalement différentes).

wget https://github.com/yarnpkg/yarn/releases/download/v1.22.17/yarn_1.22.17_all.deb
apt install ./yarn_1.22.17_all.deb

Préparation de PeerTube

Maintenant qu’on a installé tous les prérequis, il faut paramétrer l’utilisateur unix PeerTube :

mkdir /var/www/peertube -p
useradd -m -d /var/www/peertube -s /bin/bash -p peertube peertube
chown peertube: /var/www/peertube
passwd peertube
sudo -u peertube mkdir config storage versions
sudo -u peertube chmod 750 config/

Puis celui de la base de données postgresql :

pg_ctlcluster 12 main start

cd /var/www/peertube
sudo -u postgres createuser -P peertube
sudo -u postgres psql -c "CREATE EXTENSION pg_trgm;" peertube_prod
sudo -u postgres psql -c "CREATE EXTENSION unaccent;" peertube_prod

Installation de PeerTube lui même

Enfin, on peut télécharger PeerTube lui même et l’installer

VERSION=$(curl -s https://api.github.com/repos/chocobozzz/peertube/releases/latest | grep tag_name | cut -d '"' -f 4) && echo "Latest Peertube version is $VERSION"
sudo -u peertube wget -q "https://github.com/Chocobozzz/PeerTube/releases/download/${VERSION}/peertube-${VERSION}.zip"
sudo -u peertube unzip -q peertube-${VERSION}.zip && sudo -u peertube rm peertube-${VERSION}.zip
sudo -u peertube ln -s versions/peertube-${VERSION} ./peertube-latest
cd ./peertube-latest && sudo -H -u peertube yarn install --production --pure-lockfile

Puis configurer le service

sudo -u peertube cp peertube-latest/config/default.yaml config/default.yaml
sudo -u peertube cp peertube-latest/config/production.yaml.example config/production.yaml

Les variables permettant de définir les informations de votre DB (mot de passe notamment), hostname, etc, sont à modifier dans le fichier config/production.yaml.

Et enfin, on peut tout démarrer :

sudo cp /var/www/peertube/peertube-latest/support/systemd/peertube.service /etc/systemd/system/
sudo systemctl enable peertube
sudo systemctl start peertube

A partir de là, vous avez une instance PeerTube disponible en local uniquement sur le port 9000. Je ne vais pas détailler cette partie, vous avez compris le principe ; on va copier le fichier de configuration nginx d’exemple fourni par PeerTube et utiliser nginx+certbot comme point d’entrée / reverse proxy HTTPS de notre instance.

Vous voyez, j’ai pas menti quand je dis qu’on peut installer un PeerTube en moins d’une heure. Franchement, je pense qu’en 10 minutes, c’est jouable. D’autant qu’il existe des gens qui ont écrit des roles ansible sur galaxy pour l’automatiser (ici et là (github.com/kotovalexarian/ansible-role-peertube, lien mort, pas testé).

Une fois tout correctement configuré, vous pourrez vous connecter en tant qu’admin et créer vos premiers utilisateurs.

Et ça ressemble à quoi ?

Si vous voulez voir mon instance (et pourquoi pas regarder un de mes replays), elle est disponible ici.

L’interface est hyper agréable et très intuitive (encore BRAVO). On est pas perdus, l’ajout des utilisateurs est simple à réaliser.

On peut ensuite les configurer, comme leur ajouter des quotas par exemple.

Une fois connecté avec l’utilisateur (il n’est pas recommandé d’utiliser l’utilisateur d’admin pour publier des vidéos), on se connecte avec et on peut commencer à créer des “chaînes”, configurer des valeurs par défaut pour nos vidéos, etc.

L’interface d’upload est elle aussi hyper intuitive, on sélectionne le fichier, on configure la description et les catégorie et hop, ça upload.

Une fois la vidéo publiée, elle est ajoutée dans une file de transcodage pour être adaptée au streaming (ça prend environ 1 CPU). Même en envoyant 9 vidéos d’un coup, je n’ai pas mis à genou le serveur (c’est bien géré).

Ensuite, une fois la vidéo transcodée, elle devient visible et tout un chacun peu la lire, s’abonner à votre flux, etc.

Quant au player, que ce soit sur un navigateur ou depuis un smartphone, tout est bien intégré et fonctionne de manière fluide.

Et demain ?

C’est amusant que j’aie décidé de travailler sur PeerTube 3.4 pile cette semaine, car entre le moment où j’ai installé l’instance et le moment où j’ai rédigé l’article, Framasoft a publié un billet de blog pour annoncer la disponibilité de la prochaine majeure (version 4 rc1) de Peertube.

Le billet en question est ici. Grosso modo, après de gros ajouts de features techniques (les lives dispos en 3.0), les features que la v4 inclue sont surtout à destination des vidéastes, pour faciliter l’administration des chaines disposant d’un grand nombre de vidéos.

Ca ne m’intéresse pas forcément mais ça montre la vigueur du projet qui ajoute des fonctionnalités au fur et à mesure.

Pour moi c’est un carton plein, ce projet est une grande réussite de la part de Framasoft (et Chocobozzz), le logiciel est abouti dans tous les domaines.

J’ai envie de soutenir ce genre de projets, même si je ne suis pas sûr de vraiment l’utiliser au quotidien et j’ai donc fais un don (certes symbolique) à Framasoft pour que ce genre d’initiatives perdurent. Si vous trouvez vous aussi ce projet utile et que vous en avez les moyens, je vous invite à faire de même.

Sources additionnelles

k3os, le reboot de RancherOS à la sauce k3s

Tue, 08 Dec 2020 07:45:00 +0000

k3os, encore un produit Rancher ?

Oui, k3os. Je vais donc ENCORE parler d’un produit de Rancher aujourd’hui, et la raison principale est que cet article est plus ou moins la suite logique des deux précédents sur RancherOS et RKE

Dans Kubernetes avec RancherOS et RKE partie 1, je vous expliquais que j’avais ENCORE changé d’infra et que pour le fun, j’avais souhaité essayer d’installer RancherOS puis RKE, respectivement comme distrib pour mes nodes Kubernetes et comme méthode d’installation de Kubernetes lui même.

Bon, alors d’abord j’ai pas été super convaincu par RancherOS (pas seulement pour mon usage perso, mais aussi plus globalement) et en plus, j’ai découvert grâce aux commentaires que RancherOS était en fait abandonné.

Bummer…

k3s pour mon usecase c’est quand même mieux

Bon en vrai ce n’était pas bien grave, car le but était de tester ces produits dont j’entendais parler depuis un moment. Mais du coup, je n’ai toujours pas de Kubernetes viable pour mes geekeries…

Un des outils qui correspond le mieux à mon usecase, là encore chez Rancher, c’est k3s. Un Kubernetes minimaliste qui prend très peu de ressources et qui est simple à installer.

J’avais d’ailleurs fait quelques articles dessus, notamment pour parler d’un playbook Ansible qui permettait de déployer k3s sur des instances ARM dans le cloud de Scaleway (la bonne époque où ils en proposaient, en tout cas…).

Le code est toujours dispo et n’était pas spécifique à ARM ni à Scaleway, si ça vous intéresse.

Et k3os dans tout ça ?

La méthode d’installation de Kubernetes est donc choisie. Mais ça ne répond pas à la seconde question, à savoir, sur quelle distribution je l’installe.

Je peux l’installer sur n’importe quel OS Linux généraliste (Debian, Ubuntu, CentOS, … you name it), mais le but, c’est quand même d’installer un Kubernetes le plus léger possible (car je suis radin sur les serveurs que je loue et ils sont peu puissants).

Qu’à cela ne tienne, me dis-je ! Pourquoi ne pas retenter l’expérience CoreOS et RancherOS avec k3os ?

Et c’est vraiment une bonne question…

k3OS donc

k3OS is a Linux distribution designed to remove as much OS maintenance as possible in a Kubernetes cluster. It is specifically designed to only have what is needed to run k3s. Additionally the OS is designed to be managed by kubectl once a cluster is bootstrapped. Nodes only need to join a cluster and then all aspects of the OS can be managed from Kubernetes. Both k3OS and k3s upgrades are handled by the k3OS operator. github.com/rancher/k3os

k3os est donc une distribution optimisée par Rancher pour fonctionner avec k3s et consommer le moins de ressources possibles.

Les avantages mis en avant sont que dès que l’OS est installé, on a un Kubernetes fonctionnel puisque k3s est préinstallé et configuré à l’install de l’OS.

L’autre avantage mis en avant est que tout la gestion du cycle de vie de l’OS est piloté à l’aide d’un operateur dans Kubernetes (k3OS operator) qui va nous permettre de gérer l’OS depuis Kubernetes directement.

Mkay, pourquoi pas.

Et c’est reparti pour un tour

Même procédure que pour l’article sur RancherOS, les principes sont très similaires. On va télécharger une image iso, créer une VM et se connecter dessus en liveCD pour installer l’OS sur le disque.

La page des releases est ici : github.com/rancher/k3os/releases

cd /var/lib/vz/template/iso
wget https://github.com/rancher/k3os/releases/download/v0.11.1/k3os-amd64.iso

To copy k3OS to local disk, after logging in as rancher run sudo k3os install. Then remove the ISO from the virtual machine and reboot.

STOOOOOP

Exactement comme dans l’install de RancherOS, si vous partez bille en tête vous risquez de tomber sur un OS (ahah).

Dans l’article précédent, j’avais fait l’andouille et lancé la commande, pour me rendre compte qu’une fois installé, je n’avais ni réseau, ni clé SSH pour me connecter sur l’utilisateur rancher post install.

En vrai, tout doit se faire via cloud-config…

Bon, pour être honnête, cette fois-ci, ils ont quand même un peu plus prévu le coup. Si vous ne fournissez pas de cloud-config, cette fois-ci k3os vous propose de rentrer un mot de passe pour votre rancher.

Mais vous n’aurez pas plus de réseau si comme moi vous n’avez pas mis de DHCP sur votre LAN (cf aparté pour les bolosses qui n’ont pas de DHCP plus tard dans l’article).

cloud-config

Partons donc pour l’instant du principe que vous avez un DHCP et que vous aurez donc, une fois k3OS installé, accès réseau à votre machine.

Proxmox a la bonne idée de permettre la création de volume cloud-init directement depuis l’UI.

Cependant, j’ai bien l’impression que le format du cloud-init de Proxmox ne correspond pas au format attendu par k3OS…

OK, je suis pas fâché.

On va donc devoir le faire à la mimine et ça tombe bien, car on a ENCORE le souci du clavier Qwerty/Azerty… (cf Bonus Qwerty), ce qui est parfait pour copier à la main une clé SSH, c’est bien connu.

Vous l’aurez compris, on va s’en sortir une fois de plus avec un port série et la console de type xterm.js…

Grosso modo, mon cloud config s’est limité à ça.

cat > config.yml << EOF
k3os:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQAaaaaaaaaaaaaaaaaaaaaaaaaaaaOF0lZiHOjIZ/27aaHmNTq27Vws2dhzJ9 rancher
EOF

Tout ça pour ça me direz-vous ? Oui…

Mais bon, une fois qu’on a ça, on peut passer à l’install elle-même, qui est en fait un mini installeur qui vous pose quelques questions un peu triviales comme « rôle du node », « token », « chemin de la clé SSH ».

k3os-15121 [~]$ sudo k3os install
Running k3OS configuration
Choose operation
1. Install to disk
2. Configure server or agent
Select Number [1]:
Config system with cloud-init file? [y/N]: y
cloud-init file location (file path or http URL): config.yml
[...]

Ces valeurs peuvent d’ailleurs être ajoutées au cloud-config pour vous permettre d’automatiser la totalité de l’opération.

A l’issue de l’opération… magie ! vous aurez un Kubernetes tout neuf et tout léger :)

Aparté pour les bolosses qui n’ont pas de DHCP (aka. moi)

Ça aurait été plus simple de monter un petit serveur DHCP vite fait mais je suis têtu comme pas deux.

La blague avec k3OS est que, contrairement à RancherOS, il n’est tout simplement pas possible d’installer l’OS en lui spécifiant l’adresse réseau physique qu’il devra avoir post install.

En fait au début, j’avais copié ce que j’avais fait pour RancherOS. L’installeur de k3OS ne râle pas, mais il ignore simplement le code en trop.

Et vous ne pourrez plus vous connecter…

Mais comme je suis têtu (je me répète), j’ai cherché à tout prix la solution.

L’idée ici est de feinter l’installeur en ne lui donnant PAS de cloud config. On garde ainsi la possibilité de se loguer à l’utilisateur rancher avec un mot de passe (pas bien ça…).

Une fois k3OS installé, on se connecte une nouvelle fois en console (oui, on risque pas de le faire en SSH…) et on configure la carte réseau.

k3OS est un dérivé d’Alpine (pour les binaires userspace) avec le kernel d’Ubuntu 20.04 (oh…kay ?).

Pour setter le réseau, vous pouvez donc faire :

sudo connmanctl services
*AR Wired ethernet_c6eb50d8c655_cable

Cette commande vous renvoie le nom de la carte réseau virtuelle. Vous pouvez maintenant regarder la configuration par défaut

sudo connmanctl services ethernet_c6eb50d8c655_cable
/net/connman/service/ethernet_c6eb50d8c655_cable
Type = ethernet
Security = [ ]
State = ready
Favorite = True
Immutable = False
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=eth0, Address=C6:EB:50:D8:C6:55, MTU=1500 ]
IPv4 = [ Method=auto, Address=169.254.126.16, Netmask=255.255.0.0 ]
IPv4.Configuration = [ Method=auto ]
IPv6 = [ ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ 8.8.8.8 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]

Grande classe. 8.8.8.8 en DNS… No comment.

Et setter votre carte réseau post installation avec cette dernière commande (à remplacer par vos valeurs à vous, hein) :

sudo connmanctl config ethernet_d2416991aa5b_cable --ipv4 manual 192.168.1.15 255.255.255.0 192.168.1.1 --nameservers 192.168.1.1

Conclusion

Bon je crois qu’il est temps d’arrêter de se faire du mal…

Oui clairement, je me suis mis dans un exemple un peu foireux. Tout le monde de normalement constitué dispose d’un DHCP de nos jours. Surtout que k3OS cible les usages de k3s, à savoir le edge et l’IoT.

Mais du coup, j’ai l’impression qu’on est vraiment dans le marché de niche de la niche : un OS optimisé pour l’IoT ou l’edge uniquement. Je ne suis clairement pas ciblé par k3OS.

Ça ne m’a pas vraiment donné envie de regarder plus en détails la partie k3OS operator, qui permet de gérer les mises à jours de l’OS depuis Kube.

La documentation sur le sujet est disponible ici et ça a l’air d’avoir beaucoup bougé entre la v0.9, la v0.10 et la v0.11, puisqu’il y a des exceptions dans tous les sens…

github.com/rancher/k3os#upgrade-and-maintenance

Bref… il est temps que je m’installe un bête OS généraliste…

Ubuntu on Zwindler's Reflection

Sidero Omni - Talos Linux sur Oracle Cloud (en free tier)

Contexte

Quel rapport avec Oracle Cloud ?

Prérequis

Récupération du compartment ID

Préparation de l’environnement Oracle Cloud

Mais ce n’est pas terminé :-/

Importation de l’image sur Oracle Cloud

Création de la VM

Addendum : est-ce que c’est vraiment gratuit ?

Déployer un hyperviseur VMware ESXi avec MAAS

Résumé des épisodes précédents

ESXi ?

Ubuntu Pro ?

Installer Packer

Récupérer un ISO chez VMware

Récupérer packer-maas

Construire l’image VMware ESXi pour MAAS

ESXi dans MAAS

Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Introduction

Modifier l’OS par défaut

Déployer un hôte “KVM”

Customiser son OS avec cloud-init

Aller plus loin - déployer ses propres images sur ses machines

Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Introduction

Préparer le RPI

Installer MAAS sur le RPI

Configurer MAAS

Configurer un subnet

Enroller des machines

Liens en vrac

Kubeadm, Ubuntu 22.04 et cilium - mes petites galères récentes

Kubernetes, le retour de la vengeance

cilium et kernel Ubuntu Minimal

containerd et cgroups systemd

kubeadm et plusieurs interfaces

Et alors, kubelet et plusieurs interfaces ?

Ubuntu 22.04 et ManageForeignRoutes

Mon iPad (ou Android), un écran de plus pour Ubuntu !

Astuce bien pratique

GNOME 42 à la rescousse

Comment on l’active

Client RDP

Premiers retours

Mon PeerTube sur Ubuntu 20.04

Pourquoi Peertube ?

Fonctionnalités

Installer PeerTube

Préparation de PeerTube

Installation de PeerTube lui même

Et ça ressemble à quoi ?

Et demain ?

Sources additionnelles

k3os, le reboot de RancherOS à la sauce k3s

k3os, encore un produit Rancher ?

k3s pour mon usecase c’est quand même mieux

Et k3os dans tout ça ?

k3OS donc

Et c’est reparti pour un tour

cloud-config

Aparté pour les bolosses qui n’ont pas de DHCP (aka. moi)

Conclusion

`kubeadm` et plusieurs interfaces

Et alors, `kubelet` et plusieurs interfaces ?