Pour être très honnête, je n'en reviens toujours pas d'avoir pu écrire ce message sur LinkedIn.

Comme dit dans le billet, c'est une étape importante dans le voyage que j'ai entrepris il y a quelques années sous l'impulsion de Eric. Et, en parallèle de mes attributions professionnelles, je vais tenter une nouvelle hygiène d'écriture. C'est certain que cela fera un changement majeur par rapport au rythme habituel de ce site depuis quelques siècles…

Je vais donc tenter de publier un billet par semaine. Du technique, du perso, du sérieux ou du frivole (me connaissant, ce sujet sera rare) mais l'important est de publier quelque chose pour garder l'esprit et les doigts alertes. Non, je ne ferai pas de listing des dernières nouveautées chez AWS, vous avez assez de ressources pour cela. Je ne m'interdis pas cependant d'aborder le sujet.

Quant au jour de publication, j'hésite encore. Mais comme il y a un chouette flux RSS qui accompagne ce blog, vous savez comment suivre.

Being locked out of wifi is annoying, really. Especially when you're on a known network.

Thanks to my company, I'm the happy owner of a WeWork access card which allows me to go to any of their coworking sites and work from there. Today I had a day-long meeting with my team at one of these locations.

WeWork does not only offer nice locations and good coffee but also a unified wifi connection: on any place, you connect to the same wifi network with the same credentials. Usually, you come to the place, take a coffee, find a seat and enjoy a good working day. But today, it didn't work.

I was watching network-manager trying to connect continuously and failing with an SSL error. Strange. Some digging in my laptop's logs, some internet searches¹ and I found a solution. In Ubuntu 22.04, Canonical and the community finally upgraded OpenSSL to version 3. Included in this upgrade was the deprecation of some old ciphers and providers. And, unfortunately, the wifi system at my coworking location was not updated.

The fix is "simple" as it only impacts wpa_supplicant and won't lower the security level of your system.

Tout d'abord, un avertissement : ce que je vous décris fonctionne pour moi & ne fonctionnera pas tel quel pour un autre. Au fil de mes expériences, j'en suis arrivé à considérer toutes les méthodes d'organisation comme une boîte à outils plus que comme des dogmes à suivre à la lettre. Je me suis donc créé ma méthode avec mes outils.

Tout d'abord, et incidemment pour contredire le paragraphe au dessus, je suis un fervent partisan de la méthode GTD de David Allen. Et pour la mettre en oeuvre, j'utilise Remember the milk sur tous mes appareils.

Cela, c'est pour la «grande» organisation, celle au plus ou moins long cours. Pour l'organisation quotidienne, en sachant que je suis plongé en permanence sur mon écran avec le casque vissé aux oreilles (réunionite quand tu nous tiens…), je découpe mon temps en suivant la logique Pomodoro avec une app toute propre & simple (comme je les aime) sous linux qui s'appelle Pomotroid. Enfin, parce que le remote possède l'inconvénient d'être bruyant, surtout pendant les vacances scolaires, j'ai découvert il y a quelques années, un site/outil nommé Brain.fm qui permet de se mettre dans ce fameux état de flux propice à la réflexion & au travail en concentration.

Enfin, que ce soit pour la «grande» ou la «petite» organisation, cette méthode est totalement compatible avec des postures plus agiles comme scrum ou kanban car étant plus une méthode de flux.

Cover photo by Steve Johnson on Unsplash

Following my migration to molecule 3, all my testinfra tests were taking more time than before. Like 56 seconds for 6 tests !

As I changed nothing on the test side of my roles, I dug a bit to know what happened and try to recover my previously fast tests.

With the release of Molecule 3, the devs decided to ditch testinfra as the primary verifier tool in favor of ansible itself. While it isn't a bad decision, I'm not fond of it as I think ansible is not the best fit for a verification step as it is quite verbose and relies too heavily on register.

I still don't know who's the culprit but the slowness is linked to the connection backend used by testinfra to connect to test instance. Like it's already written in testinfra doc, the ansible backend is the slowest of all.

After digging in molecule code and testing things, the fix is really easy to deploy in your stack:

In your molecule.yml file, you need to declare the connection backend in testinfra options, like in my case, podman:

verifier:
  name: testinfra
  options:
    connection: podman

With this option, my tests are now running at lightspeed!

Ceux qui me connaissent savent que je suis un papivore acharné et que, malgré mon passage au numérique par manque de place, j'aime toujours autant le papier sous toutes ses formes¹.

Et trop régulièrement, l'actualité me rappelle que ce secteur est clairement en crise, quelque soit le pays & quelque soit le domaine.

En France, on rit (très jaune) de Presstalis et on subit tous la crise sanitaire qui oblige les éditeurs à trouver de nouvelles sources de revenus pour survivre.

C'est cette fois CanardPC qui se relance. Leur avantage dans cette course à la survie est qu'ils traitent d'un domaine spécialisé avec un effet communautaire important qui leur a déjà permis de faire le tour de table. Mais cette opération ne doit pas occulter le fait que, comme tout éditeur de presse de taille moyenne, ils n'ont quasiment aucune subvention, doivent aider à éponger la dette de Presstalis tout en subissant les affres d'une distribution physique malmenée tant par la crise sanitaire que Presstalis (encore)

De l'autre côté de l'Atlantique, le même son de cloche mais à une autre échelle : la dernière journée de l'imprimerie historique du Philadelphia Inquirer. Pourquoi ? Une rationalisation des coûts et une mutualisation des ressources dans un contexte tout aussi rouge qu'en France.

Cover photo by Yang Xi on Unsplash

Caveat: This solution only applies on states stored on AWS and relying on DynamoDB, the default, to store the lock/checksum. YMMV on other platforms, but the logic is the same.

Usually, running a terraform command is easy and, even if your plan contains errors, returns everything in a clean state. Sometimes, it fails badly¹ and you get the following error:

Error: Error locking state: Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed
        status code: 400, request id: P5T1PGB8VQDI4GKIIT8G5B9K0VVV4KQNSO5AEMVJF66Q9ASUAAJG
Lock Info:
  ID:        c18b397f-817b-b5dc-53cb-cd24ab01f789
  Path:      path/terraform.tfstate
  Operation: OperationTypeApply
  Who:       user@box
  Version:   0.11.7
  Created:   2018-08-03 12:24:03.5267495 +0000 UTC
  Info:

Terraform acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and try
again. For most commands, you can disable locking with the "-lock=false"
flag, but this is not recommended.

This error is easily fixed by running the force-unlock command with the ID given in message.

But sometimes, even after running the force-unlock command, you still get an error:

Error loading state: state data in S3 does not have the expected content.

This may be caused by unusually long delays in S3 processing a previous state
update. Please wait for a minute or two and try again. If this problem
persists, and neither S3 nor DynamoDB are experiencing an outage, you may need
to manually verify the remote state and update the Digest value stored in the
DynamoDB table to the following value: 9355476ad083c709fe8da56ca7b60b73uri

If you're not familiar with DynamoDB, or don't have direct access to table due to IAM restrictions, here is a single aws command to run to reset the digest :

$ aws dynamodb update-item --table-name terraform-states-lock --key '{"LockID": {"S": "<LOCKID_PATH>"}}' --attribute-updates '{"Digest": {"Value": {"S": "<DIGEST>"},"Action": "PUT"}}' --return-values UPDATED_NEW | jq '.Attributes.RuleSetVersion.S'

You need to change the values of <LOCKID_PATH> and <DIGEST> to match your own, of course.

Une fois n'est pas coutume, je démarre l'année avec quelques outils & liens que j'ai glané depuis mon déménagement¹.

• Parce que j'ai fortement travaillé sur le rendu lors du travail sur le nouveau thème de ce blog, les extensions Markdown sont rapidement rentrées dans la liste des packages python que je garde sous la main.
• L'ami Frédéric m'a converti à Notion (lien sponsorisé). Il faut le temps de se mettre à l'outil et comprendre ce qui se passe. Je vais certainement quitter Remember The Milk grâce à cela.
• Au début, on rit. Au fur & à mesure de la lecture, on sourit de moins en moins en se disant que l'on a déjà commis ce genre d'horreur. A la fin, on se promet de ne plus jamais recommencer². Le guide des anti-patterns en python devrait être enseigné en école tellement il nous renvoie à nos crimes (pas si ) passés.
• Il est toujours difficile d'écrire des documentations à destination de personnes peu versées sur le sujet. Je redécouvre cela depuis quelques mois en travaillant avec des clients pour qui le mot cloud est encore un gros mot. What make a good runbook est une réflexion ouverte et utile sur la qualité des livrables que l'on fournit.
• Certainement la liste la plus complète de ressources gratuites pour les développeurs. Clairement à garder en tête à chaque nouveau projet OSS.
• Un pan méconnu de l'histoire de l'informatique.
• Les bases de Go, une série d'articles plutôt courts et complets pour tenter, comme moi, de se lancer dans ce langage.
• Régime minceur pour images Docker. C'est un peu magique, il faut parfois mettre les mains dans le cambouis. Mais parvenir à réduire la taille d'une image docker de 250Mo à seulement 42Mo avec les même fonctionnalités reste un exploit.
• Pour continuer sur Docker, un runtime alternatif: podman. J'ai rapidement eu l'occasion de le voir fonctionner, j'espère pouvoir y toucher un peu plus en détails.
• Enfin, pour ceux qui ont encore du mal à comprendre IaaS & PaaS, un article complet et clair sur le sujet.

Sinon, un peu de retape ne faisant jamais de mal, je travaille toujours sur ce projet et devrai avoir un prototype web.

Cover by Stanislav Kondratiev

I listen to around twenty podcasts each month. Music, videogames, politics, radio shows, I have an eclectic library.

Currently, my listening app is Spotify. Why? A centralized location for files, offline downloading and it keeps a track of what is played and where to restart between devices.

One major drawback is the inability to add podcasts from another source than their catalog. At least one french radio, RTL, did not add their feed to the catalog as they want to be paid (article in french).

Moreover, I'm fully dependant on Spotify goodwill to keep my feeds, it implies my politics ones, mainly, may disappear without any notice.

So I'm thinking to develop my own dedicated podcast listening app. It would be a "simple" webapp, django based, for feeds management and preview associated with a mobile app, Android at first, for listening, offline and/or online.

The idea is not to offer another service which would have to be monetized someday but something anyone could deploy on their own server as long as they have docker deployed on their server.

If you're interested and want to help, leave a comment below or drop me a line at bonjour[chez]pygillier.me. When I'll really start to develop, I'll let you know.

Cover image by Juja Han

At Claranet, our clients come with their own requirements, even on clouds like AWS. And, due to my previous experience at The Food Assembly I now have the habit to test my code, always. It includes Ansible with its testing framework called Molecule.

For one client, I had to deliver a complete playbook with several roles covering a quite complex setup. It included several systemd services and had to be run on Amazon Linux EC2 instances.

As this distro is loosely based on redhat, afaik, I began to test on CentOS containers with systemd enabled. It was working but I wasn't quite confident as it wasn't the very same OS as Amazon Linux.

Luckily, AWS provides Docker images for this distro. I could then use them and be more confident in my code at one exception: systemd.

Out of box, these images don't include systemd binaries. Moreover, they follow the release cycle of their VM counterpart by being updated regularly. As my client let the updater run on their EC2 instances, I couldn't build a derivate image with systemd.

Fortunately, Molecule helped me achieve having a "rolling" systemd image for tests. Version 2.0 of molecule changed its inner settings and exposed one interesting file : molecule/default/Dockerfile.j2. As its name implies, this file is used by molecule in the create part to build a usable image for testing by inheriting from provided one, in my case amazonlinux:latest and, by modifying this file, I could install systemd on it.

Here is the content of the file:

# Molecule managed

{% if item.registry is defined %}
FROM {{ item.registry.url }}/{{ item.image }}
{% else %}
FROM {{ item.image }}
{% endif %}

{% if item.env is defined %}
{% for var, value in item.env.items() %}
{% if value %}
ENV {{ var }} {{ value }}
{% endif %}
{% endfor %}
{% endif %}

RUN if [ $(command -v apt-get) ]; then apt-get update && apt-get install -y python sudo bash ca-certificates iproute2 && apt-get clean; \
    elif [ $(command -v dnf) ]; then dnf makecache && dnf --assumeyes install python sudo python-devel python*-dnf bash iproute && dnf clean all; \
    elif [ $(command -v yum) ]; then yum makecache fast && yum install -y **systemd** python sudo yum-plugin-ovl bash iproute && sed -i 's/plugins=0/plugins=1/g' /etc/yum.conf && yum clean all; \
    elif [ $(command -v zypper) ]; then zypper refresh && zypper install -y python sudo bash python-xml iproute2 && zypper clean -a; \
    elif [ $(command -v apk) ]; then apk update && apk add --no-cache python sudo bash ca-certificates; \
    elif [ $(command -v xbps-install) ]; then xbps-install -Syu && xbps-install -y python sudo bash ca-certificates iproute2 && xbps-remove -O; fi

Then, I had to make sure my container was correctly started using systemd by editing the platform section of file molecule/default/molecule.yml:

platforms:
  - name: amazonlinux-2018
    image: amazonlinux:latest
    command: /usr/lib/systemd/systemd
    tmpfs:
      - /run
      - /tmp
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro

And voilà I have a fully usable Amazon Linux docker image with systemd enabled.