J'ai intégré l'IA dans mon flux de travail de développement, mais j'ai rapidement réalisé que les coûts pouvaient exploser si je ne surveillais pas chaque appel d'API. Les assistants de codage basés sur l'IA avec leurs modèles d'abonnement et leurs "offres pro" peuvent devenir très chers - surtout pour des projets personnels ou open‑source où le budget est limité. Je devais suivre chaque appel d'API et surveiller mon utilisation comme un fou.

La barrière de coût pour les assistants de codage IA a finalement disparu. Après des mois d'expérimentations, j'ai trouvé une combinaison qui me permet de construire un logiciel de qualité production tout en dépensant presque rien : Claude Code associé aux modèles gratuits d'OpenRouter.

L'évolution de mon environnement d'IA​

Lorsque j'ai commencé à utiliser les assistants de codage IA, la réalité m'a rapidement frappé : la qualité a un prix. Les modèles premium d'Anthropic, OpenAI, et d'autres peuvent facilement faire exploser la facture de 50 $ à 100 $+ par mois pour un usage régulier. En tant que développeur indépendant, ce n'est pas durable.

Mon parcours s'est déroulé ainsi :

1. Premiers essais : appels API directs vers les modèles premium (coûteux) – Claude Opus/Sonnet était excellent mais prohibitif.
2. Phase intermédiaire : mélange de modèles premium et open‑source (coût moyen) – j'ai testé les modèles Mistral moins chers, mais la qualité était nettement inférieure.
3. Expériences locales : tentative d'exécuter les modèles en local avec Ollama – le MacBook Air M2 (16 Go) manque de VRAM pour les gros modèles, les petits modèles (Gemma) ont une qualité médiocre, et même avec le swap, les modèles moyens (Qwen quantifié) sont très lents.
4. Configuration actuelle : Claude Code + OpenRouter free tier (coût quasi nul).

Le déclic est intervenu quand j'ai compris que, pour de nombreuses tâches de codage, je n'avais pas besoin des modèles les plus chers et les plus récents. J'avais besoin de modèles qui :

• Soient suffisamment bons pour comprendre le contexte du code
• Puissent générer du code fonctionnel
• Soient assez rapides pour ne pas interrompre mon flux de travail
• Soient gratuits ou très bon marché

L'approche que j'ai gardé, c'est d'utiliser un modèle volumineux pour la phase de planification (mode plan Claude Code), j'utilise ensuite un modèle peu coûteux, souvent gratuit, pour développer la fonctionnalité. Cette approche hybride me permet de structurer la tâche avec la puissance d'un gros modèle tout en limitant les coûts pendant le codage réel.

Pourquoi Claude Code ?​

Claude Code est devenu mon interface principale pour le codage assisté par IA parce qu'il offre quelque chose d'unique : une expérience native du terminal qui ressemble à du pair‑programming avec un collègue expérimenté.

Points forts :​

• Intégration terminale fluide : aucune perte de contexte entre l'IDE et le chat.
• Opérations conscientes du fichier : il comprend la structure du projet et peut lire/écrire des fichiers directement.
• Flux de travail basé sur les commandes : intégration naturelle avec les pratiques de développement existantes.
• Mémoire de session : se souvient du contexte au cours d'une même session.
• Boucle agentique : Claude Code utilise une boucle d'agentisation qui analyse le contexte, propose des actions (édition, lecture, exécution) et les itère automatiquement, offrant une assistance réactive et proactive.
• Outils et skills : il intègre des compétences intégrées comme ultrareview, planification, gestion des dépendances et d’autres micro‑outils qui rendent le flux de travail fluides et puissants.

Ce qui distingue réellement Claude Code, c'est la façon dont il gère les opérations multi‑fichiers complexes. Au lieu de simplement proposer des extraits, il peut implémenter des fonctionnalités à travers plusieurs fichiers, exécuter des tests et même déboguer des problèmes.

L'avantage du tier gratuit d'OpenRouter​

OpenRouter propose plusieurs modèles de haute qualité sans frais :

Modèles que j'utilise régulièrement :

• Nemotron 3 Super (modèle principal gratuit, parfois avec une petite commission par requête) : excellent pour la génération de code et la compréhension – je l'ai choisi pour ses capacités de raisonnement, son temps de première token rapide et son débit.
• Modèles Mistral : bonnes performances sur les tâches de codage.
• Modèles Gemma de Google : étonnamment capables pour leur taille.
• OpenAI GPT OSS (120 b) : modèle open‑source très grand, offrant une compréhension approfondie du texte et du code, idéal pour les prompts détaillés et les tâches nécessitant de larges fenêtres de contexte.

Note importante sur les limites du tier gratuit : les modèles sont gratuits, mais OpenRouter impose des limites de débit pour éviter les abus. Les utilisateurs du tier gratuit sont limités à 20 requêtes par minute. Il existe également des limites quotidiennes basées sur le crédit :

• Moins de 10 crédits : 50 requêtes gratuites par jour.
• Au moins 10 crédits : 1000 requêtes gratuites par jour.

J'ai constaté qu'acheter seulement 10 $ de crédit sur OpenRouter (ce qui dure longtemps vu le faible coût des modèles) me donne largement de marge pour le travail quotidien. Le coût est négligeable comparé aux assistants IA traditionnels.

L'insight clé : choisir le bon modèle selon la tâche​

• Conversations d'architecture / design : utilisez le modèle gratuit le plus performant.
• Génération de code simple : les modèles de milieu de gamme suffisent largement.
• Débogage / analyse de logs : même les petits modèles excellent dans le pattern matching.
• Apprentissage / exploration : n'importe quel modèle peut aider à expliquer des concepts.

Analyse des coûts – Un développement quasi gratuit​

Approche traditionnelle :​

• Claude Pro : 20 $/mois
• GitHub Copilot : 10 $/mois
• Utilisation de l'API OpenAI : 20‑50 $/mois (selon l'usage)
• Total : 50‑80 $/mois

Mon approche actuelle :​

• Claude Code : gratuit (outil CLI open‑source)
• Tier gratuit d'OpenRouter : 0 $
• Utilisation occasionnelle de modèles premium pour les tâches complexes : < 2 $/mois
• Total : < 2 $/mois

Cela représente une réduction de 95‑97 % tout en conservant une excellente vélocité de développement.

Considérations de qualité​

Vous vous demandez peut‑être si l'utilisation de modèles gratuits compromet la qualité. Mon expérience montre que ce n'est pas le cas, avec quelques réserves :

Où les modèles gratuits excellent :

• Génération de code boilerplate
• Algorithmes et structures de données standards
• Intégration d'API
• Documentation et commentaires
• Corrections de bugs et refactorisations

Où vous pourriez préférer les modèles premium :

• Décisions architecturales complexes
• Développement d'algorithmes novateurs
• Gestion des cas limites dans du code critique pour la sécurité
• Quand une fiabilité maximale est requise

L'astuce consiste à savoir quand utiliser quel modèle. Pour 80 % de mes tâches de codage, les modèles gratuits d'OpenRouter sont largement suffisants.

Astuces pour maximiser l'utilisation du tier gratuit​

1. Soyez précis dans vos prompts : les requêtes vagues gaspillent des tokens et donnent de moins bons résultats.
2. Divisez les problèmes en plus petits morceaux : plus facile pour les modèles, moins de contexte nécessaire.
3. Utilisez le bon modèle pour chaque tâche : faites correspondre la capacité du modèle à la complexité de la tâche.
4. Exploitez les opérations de fichiers de Claude Code : laissez‑lui lire votre base de code pour un meilleur contexte.
5. Mettez en cache les bons prompts : sauvegardez les modèles de prompts efficaces pour les réutiliser.
6. Surveillez l'usage : gardez un œil sur les modèles que vous utilisez le plus efficacement.

La vision plus large : l'IA pour tous​

Ce qui me passionne le plus dans cette configuration, ce n'est pas seulement les économies - c'est l'effet de démocratisation. Lorsque le développement assisté par IA devient accessible à quasiment n'importe qui avec une connexion Internet, nous libérons un potentiel créatif immense.

Imaginez :

• Des étudiants dans des pays en développement apprenant à coder avec l'aide d'une IA.
• Des hobbyistes construisant des projets sans se soucier des factures d'API.
• Des entrepreneurs validant rapidement leurs idées à moindre coût.
• Des contributeurs open‑source œuvrant plus efficacement.

Ce n'est pas seulement une question d'économie ; c'est abaisser la barrière d'entrée pour la création de logiciels.

Pour commencer vous‑même​

1. Installez Claude Code : brew install claude-code (via Homebrew)
2. Inscrivez‑vous sur OpenRouter : OpenRouter (tier gratuit disponible immédiatement)
3. Configurez votre clé API OpenRouter dans les paramètres de Claude Code

   export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
   export ANTHROPIC_AUTH_TOKEN="<votre‑clé‑OpenRouter>"
   export ANTHROPIC_API_KEY=""
   

   Laisser ANTHROPIC_API_KEY vide indique à Claude Code d'ignorer la clé intégrée et d'utiliser l'URL et le token personnalisés ci‑dessus.
4. Commencez avec des tâches simples pour vous familiariser avec les réponses des modèles.
5. Expérimentez différents modèles pour identifier ce qui fonctionne le mieux dans votre flux de travail.

Configuration du modèle : J'utilise openai/gpt-oss-120b:free avec maxContextTokens réglé à 135000 dans ~/.claude/settings.json.

L'avenir du codage IA abordable​

À mesure que les modèles open‑source s'améliorent et que des plateformes comme OpenRouter élargissent leurs tiers gratuits, je suis convaincu que nous nous dirigeons vers un futur où l'IA‑assisted coding de haute qualité sera à la portée de tous, quel que soit le budget.

Les outils sont déjà là. La barrière de coût tombe. Il ne reste plus qu'à construire.

Je ne fais pas confiance aux applications avec ma crypto. Chaque wallet, exchange, et dapp est une boîte noire. Vous confiez votre clé privée, cliquez sur « envoyer », et espérez que le code fait ce qu'il prétend. Donc j'ai construit mes propres scripts à la place : de petits programmes Python auditables que je peux lire et comprendre complètement.

Les différences entre Stellar et Ethereum forcent à confronter la philosophie de conception de chaque blockchain. Voici ce que j'ai appris en construisant des scripts pour les deux.

Commencer : génération de paires de clés​

La première différence m'a frappé immédiatement : comment financer un compte testnet ?

Avec Stellar, c'est presque trop facile. Générer une paire de clés, puis appeler Friendbot une fois :

keypair = Keypair.random()
public_key = keypair.public_key

url = f"https://friendbot.stellar.org?addr={public_key}"
response = urllib.request.urlopen(url)
body = json.loads(response.read())
funding_tx = body.get("hash")

Boom. 10 000 XLM, instantanément. Stellar a été conçu pour les développeurs.

Ethereum ? Une histoire différente.

account = Account.create()
address = account.address
private_key = account.key.hex()

Puis il faut aller trouver un faucet qui permettra d'alimenter le compte sur le réseau testnet. J'ai opté pour l'Ethereum Sepolia Faucet de Google qui m'a permis de commencer rapidement avec 0.05 Sepolia ETH.

Le testnet d'Ethereum vous demande de prouver que vous êtes humain. Ce n'est pas un défaut, c'est un choix de conception. Sepolia est rare par conception, et cette rareté vous force à être intentionnel à propos des tests.

Le problème des décimales​

J'ai découvert le problème des limites de décimales par accident. J'ai essayé d'envoyer 10.12345678 XLM et Stellar l'a rejeté silencieusement au niveau RPC. Il s'avère que Stellar s'arrête à 7 décimales :

value = Decimal(amount)
decimals = abs(value.as_tuple().exponent)  # Stellar : max 7

Ethereum va beaucoup plus loin. 18 décimales, parce que wei (10^-18 ETH) est la plus petite unité :

value = Decimal(amount)
amount_wei = Web3.to_wei(value, "ether")  # Ethereum : max 18

Cela m'a enseigné quelque chose : les blockchains ne sont pas interchangeables. Elles ont des contraintes dures intégrées dans leur protocole. On ne peut pas simplement déplacer du code de l'une à l'autre, il faut comprendre et respecter les limites de chaque système.

Mémos : différents compromis​

Je voulais inclure des mémos descriptifs dans les transactions, quelque chose comme « facture #12345 » pour suivre les paiements. Stellar l'a rendu simple :

memo = "payment"
builder.add_text_memo(memo)  # 28 octets UTF-8, gratuit

28 octets, inclus dans les frais de base. Terminé.

Ethereum n'a pas de mémos natifs. À la place, vous encodez les données dans la transaction elle-même :

memo = "payment"
data = "0x" + memo.encode("utf-8").hex()
tx["data"] = data  # Chaque octet ≈ 16 gaz

C'est coûteux. Un mémo de 256 octets coûte ~4 000 gaz, ce qui aux taux actuels représente environ 0,10 $. Donc sur Ethereum, vous y pensez à deux fois avant d'ajouter des métadonnées à une transaction. Sur Stellar, vous le mettez sans y penser. Conception différente, compromis différents.

Le problème de destination​

Quand j'ai testé l'envoi vers un compte inexistant, j'ai obtenu des comportements complètement différents.

Sur Stellar, cela échoue :

server.load_account(destination)  # Vérifier si le compte existe

Stellar vous oblige à prouver que le compte de destination est réel. S'il n'existe pas, vous ne pouvez pas envoyer. Vous avez besoin d'une opération create_account d'abord, puis d'un envoi. Deux étapes. Cela vous force à réfléchir à ce que vous faites.

Sur Ethereum, n'importe quelle adresse est valide :

destination = Web3.to_checksum_address(destination)  # Normaliser avec checksum

Ethereum enverra volontiers des fonds vers une adresse qui n'existe pas encore. L'adresse est valide, la transaction réussit, et maintenant ces fonds sont verrouillés dans une adresse contractuelle que personne ne possède. Pour toujours. Le checksum vous aide à éviter les fautes de frappe, mais il ne peut pas vous sauver d'une mauvaise adresse.

Modèles de frais : la plus grande différence​

C'est ici que Stellar et Ethereum ont révélé leurs philosophies fondamentalement différentes.

Le modèle de frais de Stellar est d'une simplicité désarmante :

base_fee = server.fetch_base_fee()
ops_count = len(transaction.transaction.operations)
fee = base_fee * ops_count / 10_000_000

print(f"Frais : {fee} XLM ({ops_count} opérations)")

Récupérer les frais de base, multiplier par le nombre d'opérations, terminé. Les frais sont prévisibles. Ils s'ajustent doucement avec la charge du réseau. Vous pouvez estimer les coûts de gaz avec précision avant de soumettre.

Le modèle d'Ethereum est... plus complexe :

gas_price = w3.eth.gas_price
tx = {"from": source, "to": dest, "value": amount_wei}
gas_limit = w3.eth.estimate_gas(tx)

fee = gas_limit * gas_price
print(f"Frais : ~{Web3.from_wei(fee, 'ether'):.8f} ETH")

Vous devez estimer. Et l'estimation peut changer. Le ~ dans ma sortie n'est pas cosmétique, c'est un avertissement que ce frais est approximatif. Les prix du gaz augmentent. Les estimations sont incorrectes. Vous devez vérifier à nouveau juste avant de soumettre. Cela impose un workflow différent : toujours faire un dry-run d'abord.

Séquences et nonces : le problème de synchronisation​

Les deux blockchains utilisent des compteurs pour garantir que les transactions ne soient pas dupliquées ou réordonnées. Mais elles exposent le problème différemment.

Les numéros de séquence de Stellar s'auto-incrémentent :

source_account = server.load_account(public_key)
builder = TransactionBuilder(source_account=source_account, ...)
transaction = builder.build()

Commode, mais aussi dangereux. Si vous soumettez deux transactions simultanément, elles auront le même numéro de séquence et l'une échouera. Pour les scripts, je le documente simplement comme une limitation. Pour les systèmes de production, vous auriez besoin d'une file d'attente ou d'un mutex.

Le nonce d'Ethereum est quelque chose que vous récupérez :

nonce = w3.eth.get_transaction_count(source_address)
tx = {"nonce": nonce, ...}

Même problème, même solution nécessaire, mais maintenant c'est explicite. Vous êtes responsable de la récupération du nonce. Vous voyez le problème immédiatement. D'une certaine manière, Ethereum vous force à réfléchir à la concurrence.

Gestion des clés : deux philosophies​

Pour les tests, les deux blockchains vous permettent d'utiliser des clés privées en clair. Mais Ethereum a également un format de clé prêt pour la production : le keystore chiffré.

Stellar : texte en clair avec permissions restrictives :

with open(f"keys/{public_key}.secret", "w") as f:
    os.chmod(f.name, 0o600)  # chmod 600
    f.write(secret_key)

Pour testnet, c'est correct. Pour mainnet, vous êtes livré à vous-même.

Ethereum : chiffrement intégré :

password = getpass.getpass("Choisir un mot de passe :")
keystore = Account.encrypt(private_key, password)

# L'utiliser plus tard
python send_eth.py --keystore keystores/0x123....json
# Demande le mot de passe lors de l'exécution

Donc j'ai construit les deux workflows. Pour Ethereum mainnet, j'utilise toujours des keystores chiffrés. Le mot de passe n'est jamais stocké, je le tape à chaque utilisation. C'est une étape supplémentaire, mais cela compte.

Fiabilité RPC : Stellar vs Ethereum​

Stellar a un seul point de terminaison officiel : Horizon. Solide comme le roc.

Ethereum en a des centaines de publics, et ils sont tous peu fiables :

rpcs = ["https://ethereum-sepolia-rpc.publicnode.com", "https://rpc.sepolia.org", ...]

for rpc_url in rpcs:
    w3 = Web3(Web3.HTTPProvider(rpc_url))
    if w3.is_connected():
        break

Les RPC publics tombent. Ils limitent le débit. Ils sont peu fiables. Donc je réessaie plusieurs points de terminaison. C'est ennuyeux, mais nécessaire.

Messages d'erreur : structurés vs analysés​

Quand une transaction échoue, Stellar est explicite :

# Horizon retourne des codes structurés comme :
# "tx_insufficient_balance", "tx_bad_seq", "op_no_destination"

Lire le code, comprendre ce qui ne va pas, le corriger.

Ethereum retourne des messages d'erreur :

# Les erreurs RPC arrivent comme des chaînes :
# "insufficient funds", "nonce too low", "gas too low"

J'ai dû écrire une logique d'analyse de chaînes pour extraire l'erreur réelle. Pas élégant, mais ça fonctionne.

Journalisation d'audit : non-négociable​

Après une transaction réussie sur l'une ou l'autre blockchain, je la journalise immédiatement :

timestamp = datetime.now(timezone.utc).isoformat()
log_line = f"{timestamp} | {network} | from={source} | to={dest} | amount={amount} | tx={tx_hash}\n"

with open(f"transactions.{network}.log", "a") as f:
    f.write(log_line)

Ne jamais journaliser les clés privées, juste la source, la destination, le montant, et le hash de transaction. C'est votre reçu. Des mois plus tard, vous aurez besoin de la preuve de ce qui s'est passé. Le journal est cette preuve.

Dry-run : toujours tester d'abord​

Les deux scripts supportent un drapeau --dry-run qui simule la transaction sans la soumettre :

if dry_run:
    print(f"De       : {source}")
    print(f"À        : {destination}")
    print(f"Montant  : {amount}")
    print(f"Frais    : {fee}")
    print(f"Solde    : {balance}")
    return

Sur Ethereum surtout, c'est critique. Vous voyez le coût du gaz avant de vous engager. Vous vérifiez le solde. Vous vérifiez l'adresse de destination. Le workflow devient : dry-run testnet, dry-run mainnet, soumission mainnet.

La vraie leçon​

J'ai construit ces scripts parce que je ne fais pas confiance aux boîtes noires avec ma crypto. Chaque exchange, chaque wallet, chaque dapp est un point centralisé de défaillance. N'importe lequel d'eux pourrait avoir un bug qui vide votre compte. N'importe lequel pourrait être piraté. N'importe lequel pourrait disparaître.

Mais quand je lis mon propre code, quand j'ai écrit chaque ligne, je sais exactement ce qui se passe quand j'appuie sur Entrée. Pas de points de terminaison cachés. Pas d'intermédiaires. Juste Python + bibliothèques standard + appels blockchain directs.

Stellar et Ethereum sont des plateformes solides. Mais elles ne peuvent pas vous protéger de :

• Un wallet buggué qui calcule mal le gaz
• Un exchange qui verrouille votre compte
• Une dapp qui demande trop de permissions
• Une clé privée volée du cache d'un navigateur

L'auto-garde via du code auditable est la réponse.

Si vous construisez ceci aussi​

1. Faire confiance au code, pas aux interfaces, Vous devriez comprendre chaque ligne qui déplace vos actifs.
2. Commencer sur testnet, Fonds gratuits. Zéro risque. Parfait pour apprendre.
3. Tout journaliser, Vous avez besoin de la preuve. Le journal est votre reçu.
4. Dry-run d'abord, Voir les frais. Voir la structure. Avant de vous engager.
5. Garder simple, Pas d'abstractions. Pas de magie. Juste des étapes simples.

Si vous n'êtes pas à l'aise avec le code qui déplace vos actifs, ne l'utilisez pas. Et si vous utilisez un service dont vous ne pouvez pas lire le code, vous faites confiance au jugement de quelqu'un d'autre avec votre argent.

Lire le code. L'auditer. Le modifier. Le posséder.

Code source​

Les deux scripts sont open source :

• Stellar XLM: https://github.com/Lunik/stellar_xlm
• Ethereum: https://github.com/Lunik/ethereum

Il y a quelque temps j'ai écrit un article sur comment j'avais créé ce blog. À l'époque c'était Pelican, un générateur de site statique en Python. Ensuite je l'ai migré vers MkDocs — toujours en Python, un peu plus moderne, un meilleur support pour mon setup bilingue. Et nous voilà encore. Troisième fois.

Voici l'histoire de pourquoi je l'ai fait et comment ça s'est passé.

L'ancien setup​

Laissez-moi décrire ce que j'avais avant pour que vous compreniez pourquoi je voulais changer.

Le portfolio​

Un site HTML/CSS/JavaScript brut. Pas d'étape de build. Pas de bundler. Juste des fichiers sur un disque que j'uploadais sur S3.

Ça fonctionnait. Mais c'était douloureux à maintenir. Tout le CSS était dans un seul fichier de 600 lignes mélangeant couleurs, mise en page et composants. Il n'y avait pas de séparation claire entre les données et la présentation. Le JavaScript était procédural, avec des appels à eval() pour mapper des noms de propriétés en chaînes de caractères vers des attributs DOM. Les dépendances étaient chargées depuis des CDN avec des numéros de version codés en dur dans des balises <script>.

À chaque fois que je devais toucher quelque chose, je devais redécouvrir comment c'était assemblé.

Le blog​

MkDocs est un générateur de site statique tout à fait correct. Je n'ai rien de négatif à dire dessus. Mais c'était un projet séparé, avec son propre environnement Python, son propre pipeline GitLab CI, et son propre processus de déploiement S3. Deux projets, deux pipelines, deux processus de déploiement.

Et MkDocs n'est pas vraiment conçu pour un blog. J'utilisais le plugin Blog de MkDocs Material qui est très bien mais qui ajoute une couche sur quelque chose qui n'a pas été construit pour ce cas d'usage dès le départ.

La situation CI​

Deux fichiers .gitlab-ci.yml. Deux stratégies de cache séparées. Deux jobs de déploiement séparés. Quand je voulais faire un changement qui touchait à la fois le portfolio et le blog — comme mettre à jour les liens du footer — je devais coordonner deux pipelines séparés et deux déploiements séparés. C'était pénible.

Pourquoi Docusaurus et Vite​

Docusaurus​

Docusaurus est un générateur de site statique basé sur React fait par Meta, principalement conçu pour la documentation. Mais il a un mode blog qui est assez bon. Il supporte :

• Le contenu bilingue nativement avec son système i18n
• L'estimation du temps de lecture
• Les profils d'auteurs
• Les flux RSS/Atom
• Les pages de tags

Il est construit sur Node.js et npm, ce qui signifie que je suis de retour dans l'écosystème que je déteste mais au moins c'est le même écosystème que les outils de build du portfolio. La cohérence a une valeur.

J'ai considéré Astro et 11ty. Astro est intéressant mais il nécessitait plus de configuration pour le même résultat. 11ty est élégant dans sa simplicité mais le support i18n de Docusaurus est difficile à égaler sans l'écrire soi-même.

Vite​

Vite est le choix évident pour le portfolio. C'est rapide, ça gère bien les applications multi-pages, et il a un support de première classe pour les ES modules. La migration du HTML brut + JavaScript procédural vers une vraie application multi-pages Vite m'a donné la structure dont j'avais besoin sans me forcer à adopter un framework de composants.

La structure monorepo​

La décision de fusionner les deux projets en un seul dépôt était la plus importante. Tout le reste en découle.

my_website_v2/
├── package.json          # racine npm workspaces
├── packages/
│   ├── website/          # portfolio Vite
│   └── blog/             # blog Docusaurus
└── dist/                 # output assemblé

Le package.json racine déclare les deux packages comme npm workspaces et orchestre le build :

{
  "scripts": {
    "build": "npm run build:website && npm run build:blog && npm run assemble",
    "assemble": "mkdir -p dist && cp -r packages/website/dist/. dist/ && mkdir -p dist/blog && cp -r packages/blog/build/. dist/blog/"
  }
}

Le portfolio se build dans dist/, le blog se build dans dist/blog/. La structure d'URL est préservée : / pour le portfolio, /blog/ pour le blog. Une seule commande rclone sync en CI pour tout pousser vers S3.

Migration du portfolio​

Refactoring CSS​

La première chose que j'ai faite a été d'extraire la palette de couleurs Gruvbox en propriétés CSS personnalisées :

:root {
  --gb-bg:      #1d2021;
  --gb-bg1:     #282828;
  --gb-fg:      #ebdbb2;
  --gb-cyan:    #689d6a;
  --gb-yellow:  #d79921;
  /* ... */
}

Ensuite j'ai remplacé chaque couleur codée en dur dans les feuilles de style des composants par ces variables. Aucun changement visuel, mais maintenant le thème est en un seul endroit.

Modules JavaScript​

Le principal défi était le pattern eval(). Le code original utilisait des noms de propriétés en chaîne pour définir des variables CSS dynamiques :

// Avant
config.forEach(function(item) {
  Object.keys(item).forEach(function(key) {
    eval("element." + key + " = item[key]");
  });
});

Je l'ai remplacé par une map de propriétés explicite :

// Après
const PROPERTY_MAP = {
  textContent: (el, v) => { el.textContent = v },
  href: (el, v) => { el.href = v },
  style: (el, v) => { el.setAttribute('style', v) },
};

Moins malin, mais ça fonctionne sans eval() et c'est lisible.

UAParser.js​

Le portfolio utilise UAParser.js pour afficher le navigateur et l'OS du visiteur sur la homepage terminal. Avant il était chargé depuis un CDN :

<script src="https://cdn.jsdelivr.net/npm/ua-parser-js@1/src/ua-parser.min.js"></script>

Maintenant c'est une dépendance npm correcte importée en tant qu'ES module :

import { UAParser } from 'ua-parser-js'

Migration du contenu du blog​

Le script de migration​

J'ai écrit un script Node.js à usage unique pour migrer tous les articles MkDocs vers le format Docusaurus. Les principales choses qu'il devait gérer :

Frontmatter : MkDocs Material utilise categories et tags comme champs séparés, Docusaurus n'a que tags. Le script les fusionne et déduplique. Il supprime aussi le champ readtime car Docusaurus calcule automatiquement le temps de lecture.

Admonitions : MkDocs utilise la syntaxe !!! warning "Titre", Docusaurus utilise :::warning[Titre]. Une regex gère la conversion :

content = content.replace(
  /^!!!\s+(\w+)(?:\s+"([^"]*)")?\n\n?((?:(?:    |\t)[^\n]*\n?)+)/gm,
  (_, type, title, body) => {
    const dedented = body.replace(/^(    |\t)/gm, '')
    const header = title ? `:::${type}[${title}]` : `:::${type}`
    return `${header}\n${dedented.trim()}\n:::\n`
  }
)

Structure des répertoires : Les articles MkDocs sont dans docs/en/posts/slug/index.md sans date dans le chemin. Docusaurus veut blog/YYYY-MM-DD-slug/index.md. Le script lit le champ date: du frontmatter et préfixe le nom du répertoire.

Marqueurs de troncature : MkDocs utilise <!-- more --> pour le cutoff de l'extrait d'article. Docusaurus utilise <!-- truncate -->. Un simple chercher et remplacer.

Contenu bilingue​

Les articles EN vont dans packages/blog/blog/. Les articles FR vont dans packages/blog/i18n/fr/docusaurus-plugin-content-blog/. Les images sont stockées avec l'article EN et les articles FR les référencent avec le même chemin relatif — Docusaurus les résout correctement au moment du build.

Les problèmes amusants​

Node 25 et l'erreur localStorage​

Le build SSG de Docusaurus crashait sur Node.js 25 avec :

Cannot initialize local storage without a --localstorage-file path.

Node.js 25 embarque l'API Web Storage nativement, mais contrairement aux navigateurs, il nécessite un chemin de fichier explicite pour persister les données. Docusaurus utilise localStorage en interne lors du SSG pour la persistance du thème et n'avait aucune idée que cette API nécessitait maintenant une initialisation.

Le fix est un flag Node.js :

NODE_OPTIONS='--localstorage-file=/tmp/docusaurus-ls' docusaurus build

Il est dans le script build du package.json et dans le bloc variables du GitLab CI.

Les espaces insécables​

Le HTML réduit les espaces consécutifs ordinaires en un seul. Tout le monde le sait. Moins de monde y pense quand on écrit des chaînes qui seront injectées via innerHTML.

La homepage terminal a deux commandes dont l'affichage repose sur l'alignement en colonnes : locate (les liens sont paddés à une largeur commune avant le commentaire #) et ls -l /bin (les tailles de fichiers et les dates sont alignées à droite). Le code source original utilisait des espaces insécables U+00A0 pour ce padding, pas des espaces normaux. En HTML,   ou son équivalent Unicode est le seul caractère d'espacement qui ne se réduit pas.

Pendant la migration, chaque éditeur de texte, outil de diff, et copier-coller impliqué dans le déplacement de ces chaînes a traité U+00A0 comme un espace ordinaire. Ils sont tous ressortis en U+0020. Les colonnes ont disparu silencieusement — pas d'erreur de build, pas d'échec de test, juste une régression cosmétique qu'on ne remarque que si on regarde la page.

Le fix est chirurgical : retrouver le code source original, extraire les octets bruts, les restaurer. Un one-liner Python pour grep le fichier original et compter les occurrences de \xa0 l'a confirmé, puis une substitution directe au niveau des octets les a remis en place.

Leçon : si l'alignement en colonnes dans du HTML est important, utiliser un <pre> ou white-space: pre et garder la chaîne dans un fichier séparé où un linter ne peut pas la toucher.

webpack 5.106 et webpackbar​

Docusaurus 3 utilise webpack 5 en interne. webpackbar — le plugin de barre de progression — a été mis à jour vers la version 6.0.1, qui passait des options (name, color, reporters) au ProgressPlugin de webpack. Mais webpack 5.100+ avait supprimé ces options de ProgressPlugin.

Le résultat : le build du blog crashait au démarrage avec une erreur obscure sur les options du plugin.

Le fix a été de fixer webpack à 5.95.0 comme devDependency directe dans packages/blog/package.json. La résolution npm workspaces le récupère et l'utilise à la place de résoudre la dernière version 5.x.

{
  "devDependencies": {
    "webpack": "5.95.0"
  }
}

Pas idéal, mais ça fonctionne jusqu'à ce que Docusaurus publie un fix en amont.

Le pipeline CI​

Le nouveau .gitlab-ci.yml est en trois étapes : install, build, deploy.

install → build → pages (branche develop)
                → publish (branche master)

Le job pages copie dist/ vers public/ pour GitLab Pages sur la branche develop. Le job publish lance rclone sync pour pousser dist/ vers S3 sur la branche master.

Avant, j'avais deux pipelines avec deux jobs de déploiement S3 séparés, dont l'un utilisait un pattern d'exclusion pour éviter d'écraser le blog déployé depuis l'autre pipeline. Maintenant c'est un seul rclone sync sans exclusions :

rclone sync --checksum --delete-during --quiet \
  --s3-provider AWS \
  --s3-access-key-id "$AWS_ACCESS_KEY_ID" \
  --s3-secret-access-key "$AWS_SECRET_ACCESS_KEY" \
  --s3-region eu-west-3 \
  ./dist :s3:website-lunik.tiwabbit.fr

--delete-during supprime du bucket les fichiers qui n'existent plus dans dist/ pendant la synchronisation. --checksum utilise des checksums plutôt que les dates de modification pour détecter les changements — plus fiable pour des fichiers réassemblés depuis les mêmes sources. Propre.

Conclusion​

Trois itérations de ce blog. Pelican, puis MkDocs, maintenant Docusaurus. À chaque fois les outils s'améliorent et la charge de maintenance diminue.

Le monorepo était le bon choix. Avoir le portfolio et le blog dans le même dépôt, avec le même pipeline de build, est vraiment moins pénible que de maintenir deux projets séparés. J'aurais dû le faire plus tôt.

Le code source est sur gitlab.com/Lunik/my_website_v2.

Cliquez avec le clic droit sur l'image ci-dessous et enregistrez-la au format de fichier SVG.

N'oubliez pas de créditer Apple pour le design original. Tous droits réservés. Et moi pour l'approximation.

Dans cet article, j'expliquerai pourquoi les environnements virtuels Python sont si intéressants lorsqu'on sait les utiliser correctement. Je vous montrerai également comment les utiliser correctement.

De quoi s'agit-il ?​

Les environnements virtuels Python sont un moyen d'isoler votre environnement Python de l'environnement Python du système. C'est utile lorsque vous travaillez sur plusieurs projets qui nécessitent différentes versions de Python ou différentes versions du même paquetage.

J'ai souvent entendu dire que les gens avaient peur d'utiliser les environnements virtuels Python parce qu'ils pensaient que c'était compliqué et inutile. Mais en même temps, il y a plus de centaines de paquets Python qui tentent de résoudre le même problème : pyenv, virtualenv, pipenv, conda, poetry, pew, et bien d'autres.

Un peu d'histoire​

Revenons aux bases. Il existe un module intégré pour cela : venv ! Qui l'aurait cru ? Il a été introduit pour la première fois dans Python 3.3 avec le PEP 405 - Python Virtual Environments.

Ce PEP propose d'ajouter à Python un mécanisme pour des "environnements virtuels" légers avec leurs propres répertoires de site, éventuellement isolés des répertoires de site du système. Chaque environnement virtuel possède son propre binaire Python (ce qui permet de créer des environnements avec différentes versions de Python) et peut avoir son propre ensemble indépendant de paquets Python installés dans ses répertoires de site, mais partage la bibliothèque standard avec le Python de base installé.

Qu'en est-il de tous ces gens qui tentent de résoudre le même problème ? Eh bien, ils essaient de faciliter l'utilisation et la gestion. Mais au final, ils fournissent tous la même chose : un moyen d'isoler votre environnement Python.

Comment les utiliser correctement ?​

Il suffit de connaître 3 commandes pour utiliser les environnements virtuels Python de la bonne manière.

Créer un nouvel environnement virtuel​

python -m venv myenv

Cette commande va créer un nouveau répertoire appelé myenv qui contient un environnement Python. Vous pouvez remplacer myenv par n'importe quel nom. Le nom le plus courant est venv de .venv. (N'oubliez pas de l'ajouter à votre fichier .gitignore si vous utilisez git).

Activer l'environnement virtuel​

source myenv/bin/activate

Cette commande activera l'environnement virtuel. Vous pouvez constater que l'invite a changé. Elle contient désormais le nom de l'environnement virtuel en début de ligne.

(myenv) user@host:~$

Vous pouvez vérifier les binaires Python utilisés par l'environnement virtuel à l'aide de la commande suivante.

which python

Désactiver l'environnement virtuel​

deactivate

Cette commande désactive l'environnement virtuel. Vous êtes maintenant de retour dans l'environnement Python du système.

Et maintenant ?​

Maintenant que vous savez comment utiliser les environnements virtuels Python, vous pouvez les utiliser dans vos projets.

Dans ma routine, lorsque je démarre un nouveau projet ou que je travaille sur un projet existant, la première chose que je fais est de créer un nouvel environnement virtuel. Ensuite, je l'active et j'installe les paquets nécessaires.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Cela me permet de travailler sur plusieurs projets qui nécessitent différentes versions de Python ou différentes versions du même paquetage sans aucun conflit. Sans cette technique, je devrais faire face à de nombreux conflits et je devrais désinstaller et réinstaller les paquets en permanence.

Conclusion​

Les environnements virtuels Python sont un excellent moyen d'isoler votre environnement Python de l'environnement Python du système. Ils sont faciles à utiliser et très utiles lorsque vous travaillez sur plusieurs projets qui nécessitent différentes versions de Python ou différentes versions d'un même paquetage. Vous devriez les utiliser dans vos projets. Vous gagnerez beaucoup de temps et vous vous épargnerez bien des maux de tête.

N'oubliez pas que Python fournit déjà un module intégré pour créer des environnements virtuels. Vous n'avez pas besoin d'utiliser un paquetage tiers pour le faire. Faites confiance à Python, pas à un paquet que vous avez trouvé au hasard sur Internet

Aujourd'hui, j'ai mis à jour mon serveur Fedora depuis la version 33 vers 38 mais tout ne s'est pas passé comme prévu.

J'ai OpenZFS d'intallé pour gérer mon stockage et la version actuelle de OpenZFS (2.2.2) n'est pas compatible avec le dernier kernel (6.7). J'étais coincé avec mon nouveau kernel et incapable d'accéder à mes données.

Pour référence, voici le message d'erreur que j'obtenais :

zfs list

Output :

The ZFS modules cannot be auto-loaded.
Try running 'modprobe zfs' as root to manually load them.

Et :

modprobe zfs

Output :

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.7.3-100.fc38.x86_64

Troubleshooting​

La première chose que j'ai faite a été de vérifier quelle version de kernel est supportée par la dernière version de OpenZFS (2.2.2) et j'ai découvert que la dernière version supportée de kernel est 6.6. Je l'ai manqué d'une version mineure.

Ce n'est pas grave, je peux juste installer le kernel précédent et démarrer dessus, non ?

Voyons quels sont les noyaux disponibles :

dnf --releasever=38 --showduplicates list kernel

Output :

Paquets disponibles
kernel.x86_64          6.2.9-300.fc38          fedora  
kernel.x86_64          6.7.3-100.fc38          pdates 

Installer le noyau précédent​

Ce n'est pas vraiment ce à quoi je m'attendais. J'espérais voir la version précédente kernel 6.6 mais elle n'est pas là. Essayons d'installer la version 6.2.9 et voyons ce qui se passe :

dnf install kernel-6.2.9-300.fc38

Redémarrons et voyons si ça fonctionne.

uname -r

Output :

6.7.3-100.fc38.x86_64

Après avoir redémarré, je démarrais toujours avec le dernier kernel 6.7.

Branchons un écran et voyons ce qui se passe pendant le processus de démarrage.

Grub2​

Pendant le processus de démarrage, j'ai obtenu le menu Grub2 et j'ai pu sélectionner la version précédente kernel 6.2.9 mais ce n'était pas l'image de démarrage par défaut. Je dois la sélectionner manuellement à chaque fois que je redémarre le serveur.

Résolution des problèmes (à nouveau)​

Jetons un coup d'oeil à la configuration de Grub2 pour voir quelle est la configuration par défaut :

cat /etc/default/grub

Output :

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

Hum. GRUB_DEFAULT=saved. On dirait que l'image de démarrage par défaut est sauvegardée quelque part. Jetons un coup d'oeil au fichier de configuration de Grub2 :

grep saved /etc/grub2.cfg

Output :

   set default="${saved_entry}"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
function savedefault {
    saved_entry="${chosen}"
    save_env saved_entry

Le fichier de configuration de grub2 est assez complexe et je ne veux pas y toucher, mais il semble qu'il définisse l'image de démarrage par défaut dans la variable saved_entry.

J'ai découvert qu'il existe un binaire pour travailler avec les variables d'environnement de grub2 : grub2-editenv.

grub2-editenv list

Output :

saved_entry=8bfb6e63623d4ee6aab1634ebafdd5d4-5.6.15-200.fc31.x86_64
kernelopts=root=/dev/mapper/fedora_nubs-root ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0
boot_success=0
boot_indeterminate=1

5.6.15 ! C'est une vieille version du noyau. Je suppose que ma précédente mise à jour depuis Fedora 31 n'était pas aussi propre que je le pensais.

Comment je peux changer l'image de démarrage par défaut ? Et quelle est cette longue chaîne hexadécimale au début de la variable saved_entry ?

Changer l'image de démarrage par défaut​

Nous devons d'abord trouver la liste des images de démarrage disponibles. J'ai trouvé un autre binaire pratique pour faire cela grubby.

grubby --info ALL

Output :

index=0
kernel="/boot/vmlinuz-6.7.3-100.fc38.x86_64"
args="ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0"
root="/dev/mapper/fedora_nubs-root"
initrd="/boot/initramfs-6.7.3-100.fc38.x86_64.img"
title="Fedora Linux (6.7.3-100.fc38.x86_64) 38 (Server Edition)"
id="8bfb6e63623d4ee6aab1634ebafdd5d4-6.7.3-100.fc38.x86_64"

index=1
kernel="/boot/vmlinuz-6.5.12-100.fc37.x86_64"
args="ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0"
root="/dev/mapper/fedora_nubs-root"
initrd="/boot/initramfs-6.5.12-100.fc37.x86_64.img"
title="Fedora Linux (6.5.12-100.fc37.x86_64) 37 (Server Edition)"
id="8bfb6e63623d4ee6aab1634ebafdd5d4-6.5.12-100.fc37.x86_64"

index=2
kernel="/boot/vmlinuz-6.2.9-300.fc38.x86_64"
args="ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0"
root="/dev/mapper/fedora_nubs-root"
initrd="/boot/initramfs-6.2.9-300.fc38.x86_64.img"
title="Fedora Linux (6.2.9-300.fc38.x86_64) 38 (Server Edition)"
id="8bfb6e63623d4ee6aab1634ebafdd5d4-6.2.9-300.fc38.x86_64"

index=3
kernel="/boot/vmlinuz-0-rescue-8bfb6e63623d4ee6aab1634ebafdd5d4"
args="ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0"
root="/dev/mapper/fedora_nubs-root"
initrd="/boot/initramfs-0-rescue-8bfb6e63623d4ee6aab1634ebafdd5d4.img"
title="Fedora (0-rescue-8bfb6e63623d4ee6aab1634ebafdd5d4) 30 (Thirty)"
id="8bfb6e63623d4ee6aab1634ebafdd5d4-0-rescue"

Attendez un peu. La liste de sortie est vraiment similaire à ce que j'ai sur mon moniteur pendant le processus de démarrage. Et le champ id a le même format que la variable saved_entry.

Je suppose que si je change la variable saved_entry par l'id de l'image de démarrage sur laquelle je veux démarrer, cela devrait fonctionner.

grub2-editenv - set saved_entry='8bfb6e63623d4ee6aab1634ebafdd5d4-6.2.9-300.fc38.x86_64'

Vérification de la variable saved_entry :

grub2-editenv list

Output :

saved_entry=8bfb6e63623d4ee6aab1634ebafdd5d4-6.2.9-300.fc38.x86_64
kernelopts=root=/dev/mapper/fedora_nubs-root ro resume=/dev/mapper/fedora_nubs-swap rd.lvm.lv=fedora_nubs/root rd.lvm.lv=fedora_nubs/swap rhgb quiet systemd.unified_cgroup_hierarchy=0
boot_success=1
boot_indeterminate=1

Ça a l'air pas mal. Il est temps de procéder au test final. Redémarrage du serveur...

Je vois le menu Grub2 et l'image sélectionnée par défaut est celle que j'ai définie. Ne bougez pas ... 5 ... 4 ... 3 ... 2 ... 1 ... 0.

Ca démarre !

Dernière vérification :

uname -r

Output :

6.2.9-300.fc38.x86_64

Et mon ZFS ?

zfs list

Output :

The ZFS modules cannot be auto-loaded.
Try running 'modprobe zfs' as root to manually load them.

Argh. J'ai oublié de réinstaller les modules OpenZFS pour le nouveau kernel. Faisons ça.

dnf install zfs

zfs list

Output :

NAME                           USED  AVAIL  REFER  MOUNTPOINT
poule                         3.64T  3.47T   141K  /poule
...

C'est vivant !

Conclusion​

J'espère que ce guide vous aidera à configurer l'image de démarrage par défaut dans Grub2. C'est une tâche simple mais qui peut s'avérer délicate si vous ne savez pas où chercher. Soyez également très prudent lorsque vous jouez avec Grub2, vous pouvez facilement casser votre système. Ayez toujours un plan de secours (je ne l'ai pas fait ... YOLO).

Aujourd'hui, j'ai été confronté à un problème assez ennuyeux. J'ai un serveur avec une carte réseau de 1Gbps connectée à un switch de 1Gbps. J'ai essayé de sauvegarder mes données comme d'habitude mais le transfert était plus lent que d'habitude. En utilisant ethtool, j'ai vu que la vitesse du lien n'était que de 100Mbps !

Debug the current link speed (déboguer la vitesse de la liaison)​

Tout d'abord, je dois récupérer le nom de l'interface réseau. Je pensais que c'était eth0 mais c'était enp2s0. Merci à Fedora pour cette nouvelle convention de nommage !

En utilisant la commande ip, je peux donc obtenir la liste de toutes les interfaces réseau et leur statut actuel.

ip link show

Output :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff

L'interface enp2s0 est celle que je recherche. Je peux maintenant utiliser ethtool pour obtenir la vitesse actuelle du lien.

ethtool enp2s0

Output :

Settings for enp2s0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  100baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: external
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: g
	Link detected: yes

La ligne Speed est celle que je recherche. Elle indique 1000b/s, ce qui n'est pas ce que j'attends. Auto-negotiation est on donc la carte réseau devrait être capable de négocier la vitesse du lien avec le switch.

Ma carte supporte 1000baseT/Full comme le montre la ligne Supported link modes. Le switch supporte également 1000baseT/Full comme le montre la ligne Link partner advertised link modes. Alors pourquoi la vitesse du lien n'est-elle que de 100Mbps ?

Forcer la vitesse du lien​

Je peux forcer la vitesse du lien en utilisant la commande ethtool.

ethtool -s enp2s0 speed 1000

Vérifions à nouveau la vitesse du lien.

ethtool enp2s0

Output :

Settings for enp2s0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: external
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: g
	Link detected: yes

La ligne Speed indique maintenant 1000Mb/s, ce qui correspond à ce que j'attendais.

Conclusion​

Je ne sais pas vraiment pourquoi la vitesse du lien n'était que de 100Mbps. Peut-être y avait-il un problème avec le switch ou le câble. Je ferai des recherches plus tard. Pour l'instant, je suis content de ma vitesse de liaison de 1Gbps.

Cet article décrit comment utiliser une autorité de certification SSH pour s'authentifier auprès des serveurs SSH. Ceci est particulièrement utile lorsque vous avez beaucoup de serveurs à gérer et que vous souhaitez éviter les tracas liés à la gestion d'un grand nombre de clés SSH.

L'idée de base est d'avoir une AC (Certificate Authority) qui signera les clés publiques des utilisateurs. Ensuite, les utilisateurs pourront s'authentifier auprès des serveurs en utilisant leur clé publique signée. De cette façon, vous n'avez pas à gérer les clés publiques des utilisateurs sur les serveurs, vous n'avez qu'à gérer les clés publiques de l'AC. Vous pouvez également limiter la validité des clés publiques signées à une certaine durée ou à un certain ensemble de serveurs et d'utilisateurs.

Conditions préalables​

Cet article suppose que vous disposez d'une connaissance de base de SSH et que vous disposez d'un serveur SSH exécuté sur une machine Linux.

La théorie​

Qu'est-ce qu'une autorité de certification SSH ?​

Une autorité de certification SSH est simplement une paire de clés SSH de base (publique et privée) utilisée pour signer d'autres clés publiques SSH. La clé publique de l'AC est ensuite distribuée aux serveurs et la clé privée est gardée secrète.

Comment ça marche?​

Lorsqu'un utilisateur souhaite s'authentifier auprès d'un serveur, le serveur lui demandera de fournir une clé publique. L'utilisateur fournira ensuite une clé publique signée par l'AC. Le serveur vérifiera alors la signature de la clé publique à l'aide de la clé publique de l'AC. Si la signature est valide, l'utilisateur sera authentifié.

La pratique​

Générer la paire de clés CA​

La première étape consiste à générer la paire de clés CA. Pour ce faire, vous pouvez utiliser la commande ssh-keygen :

ssh-keygen \
  -t rsa \
  -b 4096 \
  -f my_ssh_ca

Cela générera deux fichiers : my_ssh_ca et my_ssh_ca.pub. La première est la clé privée de l’AC et la seconde est la clé publique de l’AC.

Générer une paire de clés SSH personnelles (facultatif)​

Cette étape suppose que vous disposez déjà d’une paire de clés SSH personnelle. Si ce n'est pas le cas, vous pouvez en générer un à l'aide de la commande ssh-keygen :

ssh-keygen \
  -t ed25519 \
  -b 256 \
  -f my_ssh_key

Distribuer la clé publique de l'AC​

Configurer le serveur SSH​

Tout d’abord, vous devez configurer le serveur SSH pour accepter la clé publique SSH de l'AC. Pour ce faire, vous devez vous authentifier auprès du serveur et devenir root. Ensuite, vous devez éditer le fichier /etc/ssh/sshd_config et ajouter la ligne suivante à la fin du fichier :

Match Address 192.168.42.*
  TrustedUserCAKeys /etc/ssh/ssh_user_ca
  AuthorizedPrincipalsFile /etc/ssh/authorized_principals/%u
  RevokedKeys /etc/ssh/revoked_keys

Ensuite, vous devez créer le fichier /etc/ssh/ssh_user_ca et y ajouter la clé publique de l'AC SSH :

cat my_ssh_ca.pub > /etc/ssh/ssh_user_ca

Pour l'instant, nous n'avons aucune clé publique SSH CA à révoquer, il nous suffit donc de créer un fichier vide pour le paramètre RevokedKeys :

touch /etc/ssh/revoked_keys

Enfin, nous devons créer le répertoire /etc/ssh/authorized_principals pour stocker la liste des principaux SSH autorisés à s'authentifier auprès des utilisateurs :

mkdir /etc/ssh/authorized_principals

Configurer l'authentification basée sur le principal​

A titre d'exemple, nous allons configurer le serveur SSH pour me permettre de m'authentifier auprès de l'utilisateur wabbit. Pour ce faire, nous devons créer le fichier /etc/ssh/authorized_principals/wabbit et y ajouter la ligne suivante :

wabbit_ops

Cela me permettra de m'authentifier auprès de l'utilisateur wabbit en utilisant le principal wabbit_ops. Attention, un principal n'est pas un nom d'utilisateur, c'est juste un nom qui servira à identifier l'utilisateur ou un rôle. Vous pouvez utiliser le nom de votre choix, mais il est préférable d'utiliser un nom facile à retenir.

Appliquer la configuration​

Une fois la configuration effectuée, vous devez redémarrer le serveur SSH pour appliquer les modifications :

systemctl restart sshd

Configurer le client SSH​

Maintenant que le serveur SSH est configuré, nous devons configurer le client SSH pour qu'il utilise l'autorité de certification SSH pour s'authentifier auprès du serveur SSH.

Signez la clé publique SSH personnelle​

Tout d’abord, nous devons signer la clé publique SSH personnelle à l’aide de la clé privée CA. Pour ce faire, nous devons utiliser la commande ssh-keygen :

ssh-keygen \
  -s my_ssh_ca \
  -I lunik@my_server \
  -n wabbit_ops \
  -V +1d \
  my_ssh_key.pub

Cela générera un fichier my_ssh_key-cert.pub qui contient la clé publique signée.

Pour vérifier la signature de la clé publique signée, vous pouvez utiliser la commande ssh-keygen :

ssh-keygen \
  -L \
  -f my_ssh_key-cert.pub

Cela imprimera le résultat suivant :

my_ssh_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:Nbe7SXv788c0t3g8D8GQ/5dwHXX4zXtoaEC7r97h5oM
        Signing CA: RSA SHA256:jitBsmIydxjgdW7DttD9piKIWmb4RPQQ7i7wfQ+M4Vg (using rsa-sha2-512)
        Key ID: "lunik@my_server"
        Serial: 0
        Valid: from 2023-09-19T19:13:00 to 2023-09-20T19:14:07
        Principals: 
                wabbit_ops
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

S'authentifier sur le serveur SSH​

Maintenant que le client SSH est configuré, nous pouvons nous authentifier auprès du serveur SSH à l'aide de la clé publique signée. Pour ce faire, nous devons utiliser la commande ssh :

ssh \
  -i my_ssh_key \
  wabbit@my_server

J'ai beaucoup de médias à regarder et je ne veux pas passer du temps à les chercher, les télécharger, les renommer, les déplacer, etc. Je veux pouvoir demander un film ou une émission de télévision et le regarder en moins de 5 minutes. Je veux également pouvoir le regarder sur n'importe quel appareil, n'importe où, à tout moment.

Je n'utilise pas cette configuration pour télécharger et regarder du contenu piraté. Aucun contenu piraté n'a été téléchargé lors de la rédaction de cet article. Des fichiers de substitution ont été utilisés à la place.

Prérequis​

Nous allons utiliser les outils suivants :

• Plex : Serveur et lecteur multimédia
• Sonarr : Gestionnaire d'émissions de télévision
• Radarr : Gestionnaire de films
• Prowlarr : Indexeur de torrents
• Overseerr : Gestionnaire de demandes
• qBittorrent : Client de torrents

Nous aurons également besoin d'un serveur basé sur Linux pour héberger tout cela.

Déploiement​

Pour le déploiement, nous allons utiliser Docker et Docker Compose.

Docker Compose​

Le fichier docker-compose.yml complet est disponible ici.

Ensuite, nous pouvons démarrer la pile avec la commande suivante :

docker compose up -d

Ensuite, nous pouvons vérifier que tout fonctionne avec :

docker compose ps

Le résultat devrait ressembler à ceci :

NAME                              IMAGE                                    COMMAND             SERVICE             CREATED             STATUS              PORTS
auto-media-center-prowlarr-1      lscr.io/linuxserver/prowlarr:latest      "/init"             prowlarr            20 minutes ago      Up 20 minutes       0.0.0.0:9696->9696/tcp
auto-media-center-overseerr-1     lscr.io/linuxserver/overseerr:latest     "/init"             overseerr           9 minutes ago       Up 9 minutes        0.0.0.0:5055->5055/tcp
auto-media-center-plex-1          lscr.io/linuxserver/plex:latest          "/init"             plex                9 minutes ago       Up 9 minutes        0.0.0.0:3005->3005/tcp, 0.0.0.0:8324->8324/tcp, 0.0.0.0:1900->1900/udp, 0.0.0.0:32410->32410/udp, 0.0.0.0:32400->32400/tcp, 0.0.0.0:32412-32414->32412-32414/udp, 0.0.0.0:32469->32469/tcp, 5353/udp
auto-media-center-qbittorrent-1   lscr.io/linuxserver/qbittorrent:latest   "/init"             qbittorrent         20 minutes ago      Up 20 minutes       0.0.0.0:6881->6881/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:6881->6881/udp
auto-media-center-radarr-1        lscr.io/linuxserver/radarr:latest        "/init"             radarr              20 minutes ago      Up 19 minutes       0.0.0.0:7878->7878/tcp
auto-media-center-sonarr-1        lscr.io/linuxserver/sonarr:latest        "/init"             sonarr              20 minutes ago      Up 19 minutes       0.0.0.0:8989->8989/tcp

Configuration​

Maintenant que tout est en place, nous pouvons commencer la configuration.

Plex​

C'est la première chose que nous allons configurer. Plex est le serveur multimédia et le lecteur. C'est le cœur de notre centre multimédia.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 32400. Nous pouvons donc y accéder à l'adresse http://<adresse-ip-du-serveur>:32400/web.

Si vous n'avez pas de compte Plex, vous pouvez en créer un gratuitement. Ensuite, vous pourrez accéder à l'interface web.

Après avoir suivi l'assistant, vous devriez voir quelque chose comme ceci :

Nous pouvons maintenant ajouter nos bibliothèques multimédia. Dans cet exemple, je vais ajouter une bibliothèque de séries TV et une bibliothèque de films.

Tout d'abord, la configuration de la bibliothèque de films :

Ensuite, la configuration de la bibliothèque de séries TV :

Enfin, le serveur Plex devrait ressembler à ceci :

QBittorrent​

qBittorrent est un client de torrents. Il nous permettra de télécharger des torrents.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 8080. Nous pouvons donc y accéder à l'adresse suivante : http://<adresse-ip-du-serveur>:8080. Le nom d'utilisateur par défaut est admin et le mot de passe par défaut est adminadmin.

Vous devriez voir quelque chose comme ceci :

Ensuite, nous devons configurer le dossier de téléchargement dans (Options > Downloads). Pour cet exemple, j'utiliserai /downloads comme dossier de téléchargement et /incomplete-downloads comme dossier de téléchargements incomplets. N'oubliez pas de cliquer sur Save en bas de la page.

Sonarr​

Sonarr est un gestionnaire de séries télévisées. Il nous permettra de rechercher des séries télévisées et de les télécharger automatiquement.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 8989. Nous pouvons donc y accéder à l'adresse suivante : http://<adresse-serveur>:8989.

Vous devriez voir quelque chose comme ceci :

Indexeurs​

Nous allons voir la configuration des indexeurs dans (Paramètres > Indexeurs). Cela sera automatiquement configuré par Prowlarr plus tard.

Client de téléchargement​

Nous allons configurer le client de téléchargement dans (Settings > Download Client). Pour cet exemple, je vais utiliser la configuration suivante :

Nous pouvons tester la connexion en cliquant sur Test en bas de la page.

Note : Vous pouvez définir l'Initial State sur Paused si vous ne souhaitez pas que Sonarr télécharge tous les épisodes des séries que vous ajoutez.

Gestion des médias​

Nous allons configurer la gestion des médias dans (Settings > Media Management). Cela permettra à Sonarr de renommer et déplacer les épisodes téléchargés depuis qBittorrent dans le dossier approprié pour que Plex puisse les trouver.

Pour cet exemple, je vais utiliser la configuration suivante :

Test​

Maintenant, nous devrions pouvoir ajouter une série télévisée. Dans (Séries > Ajouter une série), nous pouvons rechercher Game of Thrones et l'ajouter :

Ensuite, nous cliquons sur la carte Game of Thrones et nous devrions voir quelque chose comme ceci :

Ensuite, nous pouvons cliquer sur le bouton Recherche interactive (icône de personne) pour rechercher les torrents de la première saison :

Nous pouvons cliquer sur le bouton Télécharger pour déclencher le téléchargement de la première saison.

Dans la section (Activity > Queue), nous pouvons voir l'avancement du téléchargement :

Et dans qBittorrent, nous pouvons voir l'avancement du téléchargement :

Enfin, lorsque le téléchargement est terminé, Sonarr renommera et déplacera l'épisode dans le dossier approprié. Et Plex détectera le nouvel épisode et l'ajoutera à la bibliothèque.

Radarr​

Radarr est un gestionnaire de films. Il nous permettra de rechercher des films et de les télécharger automatiquement.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 7878. Nous pouvons y accéder à l'adresse suivante : http://<adresse-ip-serveur>:7878.

Vous devriez voir quelque chose comme ceci :

Indexeurs​

Nous allons voir la configuration des indexeurs dans (Paramètres > Indexeurs). Cela sera automatiquement configuré par Prowlarr plus tard.

Client de téléchargement​

Nous allons configurer le client de téléchargement dans (Settings > Download Client). Pour cet exemple, je vais utiliser la configuration suivante :

Nous pouvons tester la connexion en cliquant sur Test en bas de la page.

Note : Vous pouvez définir l'Initial State sur Paused si vous ne souhaitez pas que Radarr télécharge tous les films que vous ajoutez.

Gestion des médias​

Nous allons configurer la gestion des médias dans (Settings > Media Management). Cela permettra à Radarr de renommer et déplacer les films téléchargés depuis qBittorrent dans le dossier approprié pour que Plex puisse les trouver.

Pour cet exemple, je vais utiliser la configuration suivante :

Test​

Maintenant, nous devrions pouvoir ajouter une série TV. Dans (Series > Add Series), nous pouvons rechercher Avengers et l'ajouter :

Ensuite, nous cliquons sur la carte The Avengers et nous devrions voir quelque chose comme ceci :

Ensuite, nous pouvons cliquer sur l'onglet Search pour rechercher les torrents de films :

Nous pouvons cliquer sur le bouton Télécharger pour déclencher le téléchargement de la première saison.

Dans la section (Activity > Queue), nous pouvons voir l'avancement du téléchargement :

Et dans qBittorrent, nous pouvons voir l'avancement du téléchargement :

Et enfin, lorsque le téléchargement est terminé, Radarr renommera et déplacera l'épisode dans le bon dossier. Et Plex détectera le nouvel épisode et l'ajoutera à la bibliothèque.

Prowlarr​

Prowlarr est un indexeur de torrents. Il nous permettra de rechercher des torrents sur plusieurs trackers en même temps.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 9696. Nous pouvons donc y accéder à l'adresse suivante : http://<adresse-ip-du-serveur>:9696.

Vous devriez voir quelque chose comme ceci :

Ensuite, nous devons ajouter quelques indexeurs. Pour cet exemple, je vais ajouter les indexeurs suivants :

Applications​

Cette section dans Paramètres permettra de lier Prowlarr à Radarr et Sonarr. Ainsi, tous les indexeurs que nous ajoutons dans Prowlarr seront automatiquement ajoutés dans Radarr et Sonarr.

Ajoutez deux applications :

En allant véfier dans Radarr et Sonarr, on peut voir que les indexers ont bien été ajoutés dans la section Indexers.

Overseerr​

Comme vous pouvez le constater, Radarr et Sonarr sont de superbes outils. Cependant, ils ne sont pas très conviviaux. Overseerr nous permettra de demander des séries télévisées et des films via une interface web agréable.

Tout d'abord, nous devons accéder au service via l'interface web. Le port par défaut est 5055. Nous pouvons donc y accéder à l'adresse http://<adresse-serveur>:5055.

Lors de la première configuration, nous devons remplir les champs suivants :

Paramètres Plex

Cela permettra à Overseerr de se connecter à Plex et de vérifier si les médias sont déjà disponibles dans la bibliothèque.

Paramètres Radarr

Cela permettra à Overseerr de se connecter à Radarr et de déclencher le téléchargement des films demandés.

Paramètres Sonarr

Cela permettra à Overseerr de se connecter à Sonarr et de déclencher le téléchargement des séries télévisées demandées.

Si tout est configuré correctement, vous devriez voir quelque chose comme ceci dans l'onglet Découverte :

Nous pouvons voir que le film Avengers et la série télévisée Game of Thrones sont déjà disponibles dans Plex.

Remarques : Les utilisateurs qui ont accès à votre serveur Plex pourront demander des films et des séries télévisées. Ils peuvent se connecter avec leur compte Plex.

Vous pouvez configurer les utilisateurs dans l'onglet Utilisateurs. Par exemple, vous pouvez créer des utilisateurs locaux qui pourront accéder à Overseerr sans compte Plex.

Demande de média​

Nous allons maintenant essayer de demander un film à Overseerr. Nous utiliserons un utilisateur local pour cet exemple.

Essayons de demander le film Le Daim. Depuis l'onglet Discover, nous pouvons rechercher Le Daim et nous devrions voir quelque chose comme ceci :

Ensuite, nous pouvons cliquer sur le bouton Request pour demander le film.

En revenant à l'onglet Requests avec notre compte administrateur, nous pouvons voir la demande :

Nous pouvons cliquer sur le bouton Approve pour approuver la demande. Cela déclenchera le téléchargement du film dans Radarr et le téléchargera comme nous l'avons vu précédemment dans la section Radarr.

Et enfin, lorsque tout le processus est terminé, nous pouvons voir que le film est disponible dans Overseerr et Plex.

Maintenant que j'ai généré ma propre chaîne de certification personnalisé dans l'article précédent "gestion de certificats x509", je dois installer l'autorité de certification (CA) sur mon iPhone.

Installer le certificat​

Je dois d'abord installer le certificat CA sur l'appareil.

Le fichier était sur l'appareil et je l'ai ouvert à partir de l'explorateur de fichiers.

Ensuite, je dois aller dans les paramètres IOS. Dans la rubrique "Général".

Puis dans la rubrique "VPN et gestion de l'appareil".

Je clique sur l'autorité de certification dans la section "Profil téléchargé".

J'ai ensuite suivi le processus d'installation.

Vérifié ensuite l'installation.

Enfin, je dois approuver l'autorité de certification en tant qu'autorité racine sur l'appareil. En revenant à la rubrique "Général". Maintenant dans la section "Informations".

Puis dans la rubrique "Réglages des certificats".

Enfin, j'ai activé le certificat et terminé l'installation.

En supposant que vous utilisez la fonctionnalité de stockage des states Terraform dans GitLab dans votre instance managée et que vous utilisez l'utilitaire intégré de sauvegarde fourni par GitLab.

Les fichiers de state Terraform sont chiffrés avant d'être stockés. Cela signifie que vous ne pouvez pas récupérer leur contenu à froid. À cette fin, GitLab utilise applications secrets (et dérive de nouveaux secrets à partir de ces clés si nécessaire) pour chiffrer le contenu sensible.

Vous souhaitez récupérer le contenu d'un fichier de state à partir d'une sauvegarde GitLab. Comme expliqué dans cette issue, il n'est pas possible de récupérer facilement un contenu déchiffré si l'instance est hors ligne.

Procédure de récupération​

Récupération des secrets d'instance GitLab​

En utilisant la documentation GitLab sur les secrets d'application, vous devez récupérer la valeur de db_key_base.

Récupération des informations du projet​

Le stockage des states Terraform est lié à un projet GitLab. Si le projet existe toujours dans votre instance, enregistrez le project_id pour plus tard.

Si vous avez supprimé le projet, nous aurons besoin de la sauvegarde de la base de données (également stockée dans la sauvegarde GitLab).

Commencez par rechercher dans la table public.routes votre projet. Vous pouvez filtrer par source_type=Project et path=path/of/your/project. Notez la valeur dans la colonne namespace_id.

Regardez ensuite la table public.projects filtrant le namespace_id récupéré juste avant. Notez l'id du projet.

Calcul du chemin de stockage du state​

Les states sont stockés avec un chemin haché.

La première partie est la somme hash256 du projet id. Vous pouvez utiliser la commande suivante pour le calculer :

echo -n "<id_projet>" | openssl dgst-sha256

La deuxième partie peut être récupérée de la base de données dans la table public.terraform_states. Filtrez par project_id et le name du state enregistrez le uuid.

Le chemin complet du dossier contenant le fichier de state est maintenant :

<part_1[0:1]>/<part_1[2:3]>/<part_1>/<part_2>

Si vous avez activé le versionning, le state est stocké avec le nom de fichier <serial_number>.tfstate

Récupération du contenu​

C'est la partie la plus difficile et vous devez être un peu familier avec Ruby.

GitLab utilise un outil nommé Lockbox pour chiffrer le contenu du state de Terraform avant de le stocker. Nous allons utiliser le même outil pour déchiffrer nos fichiers.

Compléter et utilisez le script suivant :

#################
# Configuration #
#################

# Retreived from GitLab rails secrets
# https://docs.gitlab.com/ee/development/application_secrets.html
# This is a dummy key base. Don't bother using it
db_key_base = "<FILL_DB_KEY_BASE>"

# The project ID in GitLab
project_id = "<FILL_PROJECT_ID>"

# The file to decrypt
input_file = "<FILL_ENCRYPTED_STATE_FILE_PATH>"

# The file where to write the terraform state content
output_file = "<FILL_DECRYPTED_STATE_FILE_PATH>"

#############
# ALGORITHM #
#############

# Compute encryption key
key = OpenSSL::HMAC.digest('SHA256', db_key_base, project_id)

# Generate LockBox tool
# https://github.com/ankane/lockbox
lockbox = Lockbox.new(key: key)

encrypted_state_content = File.binread(input_file)
state_content = lockbox.decrypt_str(encrypted_state_content)
File.write(output_file, state_content)

Je ne suis pas un expert en Ruby mais voici un simple script bash pour configurer le bon environnement :

#!/bin/bash

rails new myapp
cd myapp/

echo 'gem "lockbox"' >> Gemfile
bundle install

bundle exec rails runner decode.rb

Resources​

• Code source GitLab utilisé pour chiffrer les fichiers d'état
• Problème GitLab pour documenter la procédure de récupération

Tout développeur utilise ou utilisera Git à un moment donné de sa carrière. La plupart du temps, ils devront travailler avec d'autres personnes sur le même dépôt Git. Pour éviter que ce soit un champ de bataille de branche et commit, voici un guide simple sur la façon de contribuer correctement sur un dépôt Git.

Bases​

Tout d'abord, le dépôt Git devrait avoir une branche par défaut souvent appelée master ou main (cela peut être n'importe quoi d'autre tant que tout le monde s'accorde sur le nom).

Ensuite, une deuxième branche utilisée à des fins de développement. Celle-ci suivra de très près la branche par défaut. Elle sera un réceptacle pour tout nouveau développement. Cette branche est la seule autorisée à être fusionnée sur la branche par défaut.

Enfin, toutes les autres branches entrent dans la dernière catégorie. Ce sont des fonctionnalités, des corrections de bogues et autres.

Remarque : Seules les branches HotFix sont autorisées à contourner la branche de développement.

Voici un exemple de dépôt Git simple

Exemple complet d'un cycle de vie de d'un dépôt​

Initialisation d'un dépôt​

La première chose à faire lors de la création d'un nouveau référentiel est d'initialiser la structure de base.

Créez le dépôt Git :

mkdir -p myrepository

cd myrepository

git init

Vous voudrez peut-être créer vos premiers fichiers. Comme le README.md/.gitignore et certains fichiers de package comme package.json ou pom.xml.

Créez ensuite le commit initial du dépôt avec ces fichiers :

git add .
git commit -m "Initial commit"
git tag v0.0.0

Créez enfin la branche de développement :

git branch develop

Le référentiel devrait ressembler à :

Initialisation de la branche de développement​

Maintenant que vous avez notre structure de base sur le dépôt Git, il est temps d'initialiser la branche de développement.

Créer en premier la branche développement :

git checkout develop

Parfois, vous voudrez peut-être ajouter un commit initial sur la branche de développement avec la modification de la version actuelle dans votre fichier de package package.json, pom.xml ou autre.

Editez ces fichiers puis créez un commit :

git add .
git commit -m "Prepare development version"

Le dépôt devrait ressembler à :

Ajouter la première fonctionnalité​

Créons maintenant la première fonctionnalité de notre application.

Vérifiez que vous êtes bien sur la branche développement :

git branch

Résultat :

* develop
  master

Si ce n'est pas le cas, changer pour la branche de développement.

Ensuite, créer une branche de fonctionnalité :

git checkout -b feature/my-first-feature

Maintenant, écrivez la fonctionnalité et commitez de temps en temps avec :

git add .
git commit -m "save dev"

Le dépôt devrait ressembler à :

Travailler sur une fonctionnalité requise​

Vous travailliez sur la première fonctionnalité mais vous réalisez que vous en aviez besoin d'une autre pour continuer.

/!\ Assurez-vous que vous n'avez pas de modifications non commités avant de changer de branche

Reproduisez les mêmes commandes que pour la première fonctionnalité :

• Checkout sur la branche développement
• Ensuite, création d'une branche de fonctionnalité
• Écrivez votre code et créez des commits

git checkout develop
git checkout -b feature/my-required-feature

Le dépôt devrait ressembler à :

Fusionner la fonctionnalité requise​

Maintenant que vous avez terminé votre travail sur la fonctionnalité requise, il est temps de fusionner le code avec la branche de développement.

Vous devez d'abord rebaser la branche pour supprimer tous les commits inutiles :

git rebase -i develop

Le premier commit doit toujours être sélectionné. Tous les autres commits peuvent être écrasés.

pick fa71872 save dev
squash 5d9a97a save dev

Le dépôt devrait ressembler à :

Passez à la branche de développement et fusionnez la branche de fonctionnalité requise :

git checkout develop
git merge --no-ff feature/my-required-feature

Le dépôt devrait ressembler à :

Poursuivre le travail sur la première fonctionnalité​

Maintenant que vous avez terminé la fonctionnalité requise, vous souhaitez rebaser votre travail actuel sur la première fonctionnalité pour récupérer le contenu de la fonctionnalité requise.

• Changement pour la branche de fonctionnalités
• La rebaser sur la branche de développement

git checkout feature/my-first-feature
git rebase develop

Ce que fait cette commande, c'est prendre tous les commits de la branche de fonctionnalité et les appliquer à la fin de la branche de développement.

Le dépôt devrait ressembler à :

Fusion de la première fonctionnalité​

Maintenant que vous avez terminé votre travail sur la première fonctionnalité, il est temps de fusionner le code avec la branche de développement.

Vous devez d'abord rebaser la branche pour supprimer tous les commits inutiles :

git rebase -i develop

Le premier commit doit toujours être sélectionné. Tous les autres commits peuvent être écrasés.

pick 717051b save dev
squash 7d39273 save dev
squash 7b700f1 save dev

Le dépôt devrait ressembler à :

Passez à la branche de développement et fusionnez la branche de fonctionnalité requise :

git checkout develop
git merge --no-ff feature/my-first-feature

Le dépôt devrait ressembler à :

Correction d'un problème critique​

Un problème critique a été découvert sur l'application de production et vous devez produire rapidement un correctif. Vous n'avez pas le temps de parcourir tout le processus de publication.

• Changement pour la branche par défaut
• Créez une nouvelle branche de correctifs et changer pour la branche
• Faire la correction
• Fusionner dans la branche par défaut
• Taguez votre nouvelle version

Le dépôt devrait ressembler à :

Publier votre travail​

Il est maintenant temps de publier tout ce travail acharné.

Vous devez d'abord fusionner la branche par défaut pour récupérer toutes les correctifs.

git checkout develop
git merge --no-ff master

Le dépôt devrait ressembler à :

Et enfin, fusionnez votre développement sur la branche par défaut.

git checkout master
git merge --no-ff develop

Le dépôt devrait ressembler à :

Nettoyer​

Faisons un peu de nettoyage en supprimant certaines références inutilisées telles que les branches de fonctionnalités et de correctifs.

git branch -D feature/my-first-feature
git branch -D feature/my-required-feature
git branch -D hotfix/correct-critical-issue  

Le référentiel devrait ressembler à :

Remarques​

Tous les graphiques Git ont été générés avec Bit-Booster app

Using OpenSource software written by unkown people sometimes can be a little scary. Even more when I deploy them I a production environment in my company. On my case, I have created a brand new Kubernetes cluster to host some private services on my local network and I wanted to be sure that they don't do anything malicious on my network.

Isolate applications and services​

First thing to do is to isolate each of the services inside a Kubernetes namespace. This is a core resource of Kubernetes that allow to isolate groups of resources within a single cluster. It then allow to have a more fine control on access, permissions, network on the resources.

A Namespace can be create pretty easily with the following command :

kubectl create namespace <insert-namespace-name-here>

Then I can list Namespaces with :

kubectl get namespaces

Result :

NAME              STATUS   AGE
default           Active   4h52m
kube-system       Active   4h52m
kube-public       Active   4h52m
kube-node-lease   Active   4h52m
tiwabbit-prod     Active   2s

Ignore Namespaces prefixed with kube- who are defined for the Kubernetes control plane

I can now create resources inside my Namespace. Let's start with a Secret for example :

kubectl \
  --namespace tiwabbit-prod \
  create secret generic \
  db-credentials \
  --from-literal=username=tiwabbit \
  --from-literal=password=mysecurepassword

If I list all Secrets in my cluster :

kubectl get secrets --all-namespaces

Result :

NAMESPACE       NAME                  TYPE                                  DATA   AGE
[...]
default         default-token-m59jl   kubernetes.io/service-account-token   3      4h58m
tiwabbit-prod   default-token-8zkr2   kubernetes.io/service-account-token   3      3m15s
tiwabbit-prod   db-credentials        Opaque                                2      49s

In theory, only Pods running inside my Namespace (tiwabbit-prod) can mount this secret and read it.

RBAC securization​

By default all Pods without specific configuration use the default ServiceAccount of the Namespace they are running in. This last one dosn't have any right on the Kubernetes API witch is a great thing and should not be changed.

How ever in some scenarios my application may needs to call the Kubernetes API. For exemple if it need to create batch using a Kubernetes Job. Let's take that last exemple to create a ServiceAccount with those permission an assign it to my application Pod.

First I need to create a new ServiceAccount :

kubectl \
  --namespace tiwabbit-prod \
  create serviceaccount \
  my-application

Then I need a Role that implement the level of permission that my Pod need. here is the manifest :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-application-batch-creator
  namespace: tiwabbit-prod
rules:
- apiGroups: []
  resources: [ pods, pods/status, pods/log ]
  verbs: [ get, list, watch ]

- apiGroups: [ batch ]
  resources: [ jobs ]
  verbs: [ create, get, list, watch, patch, update, delete ]

Finally, I need to assign the Role to my ServiceAccount using a RoleBinding with the following manifest definition :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-application-permissions
  namespace: tiwabbit-prod
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: my-application-batch-creator
subjects:
- kind: ServiceAccount
  name: my-application
  namespace: tiwabbit-prod

Now let's create a Pod with the ServiceAccount and review the actions allowed by the role. Here is a Deployment manifest :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-application
  namespace: tiwabbit-prod
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-application
  template:
    metadata:
      labels:
        app: my-application
    spec:
      serviceAccountName: my-application
      containers:
      - command:
        - sleep
        - 1d
        image: alpine:latest
        name: alpine

Geting inside the Pod and follow the Kubernetes documentation to install kubectl.

Let's check if I can list Pods by querying the Kubernetes API :

kubectl get pods

Result :

NAME                             READY   STATUS    RESTARTS   AGE
my-application-df5b5cb75-8twc5   1/1     Running   0          5m21s

Then I should try to create a batch execution with a Job :

kubectl create job my-application-batch --image alpine:latest -- echo "Hello World"

Listing all the Jobs in the Namespace :

kubectl get jobs

Result :

NAME                   COMPLETIONS   DURATION   AGE
my-application-batch   0/1           2s         2s

Listing the Pods in the Namespace :

kubectl get pods

Result :

NAME                             READY   STATUS    RESTARTS   AGE
my-application-df5b5cb75-8twc5   1/1     Running   0          11m
my-application-batch-f2pf6       1/1     Running   0          3s

My Job finished and I can delete it with :

kubectl delete job/my-application-batch

Conclusions​

If the process in my Pod doesn't need to communicate with the Kubernetes API (for creating, querying, deleting ressources), use the default ServiceAccount witch give zero permission to my Pod. In other case, use a custom ServiceAccount for each of my apps and multiple Role and RoleBinding for each of my application use case.

Prevent usage of root user or privileged escalation​

Kubernetes allow by default multiple security options that can be applied to pods and underlaying containers. Most of them can be configured with the SecurityContext block as follow :

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext: {}
  containers:
  - name: my-secure-container
    image: nginx:latest
    securityContext: {}
  - name: my-second-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext: {}

Obviously such options can be added to a StatefulSet or Deployment template.

Running pod as non root​

The easiest setup to secure the Pod is to overwrite the UID and GID of the user running the main process. This way, what ever the default user in the image, Kubernetes will bypass it. An UID and GID superior or equal to 1000 should be used.

Three parameters can be used :

• runAsUser : Allow to change the UID of the default process
• runAsGroup : Allow to change the GID of the default process
• fsGroup : If specified, the user will also be in that group and all files and directories created will take that GID as owner.
  • This last parameter can increase the mount time of a given external volume because Kubernetes ensure that files are owned by the group defined by fsGroup. Resulting on an chmod -R of all the filesystem.
  • fsGroupChangePolicy can be used to change this behaviour with those values :
    • OnRootMismatch : only check the root directory and change all filesystem if the group mismatch
    • Always : it's in the option name

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 2000
    fsGroupChangePolicy: OnRootMismatch
  containers:
  - name: my-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 2000

Enforcing running as non root could be achieved with runAsNonRoot parameter :

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext:
    runAsNonRoot: true
  containers:
  - name: my-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext: {}

Use readonly filesystem​

Preventing all write/update/delete operation on the root filesystem can prevent malicious process (or breached application) to take advantage of the container environment and modify it. The readOnlyRootFilesystem option allow to achieve that :

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext: {}
  containers:
  - name: my-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext:
      readOnlyRootFilesystem: true

If the application need to write temporary or application data during the runtime, I can still create an EmptyDir volume and mounting it inside the container :

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext: {}
  containers:
  - name: my-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
    - mountPath: /data
      name: my-data
  volumes:
  - name: my-data
    emptyDir: {}

Prevent priviled escalation​

Linux kernel expose low level function for a process to change is current UID or GID. For example using [setuid][linux-setuid-wikipedia] or setgid privitive functions.

Using the option allowPrivilegeEscalation can prevent this to happens.

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext: {}
  containers:
  - name: my-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext:
      allowPrivilegeEscalation: false

Dropping all capabilities​

As for privileged escalation, Linux give Capabilities to process allowing them to make high privileged system calls. Like binding network ports under 1024.

We want to only give our process only the necessary capabilities for it to run. In the cas of the exemple we can have :

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext: {}
  containers:
  - name: my-second-secure-container
    image: busybox:latest
    command: ["sleep", "infinity"]
    securityContext:
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE

Network communication hardening​

In the world of pods, by default every pods in every namespace can talk to each other. If you have multiple application or even multiple clients on the same Kubernetes cluster, you should not allow them to communicate (at least not by default).

That's why, NetworkPolicies must be created with deny all by default. Then open point to point connections if services/clients needs to communicates with each others.

The default deny all config will looks like this :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Then if you have a third party application that needs to access your application pods :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      application: my-application
      component: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: my-friend-namespace
        - podSelector:
            matchLabels:
              application: his-application
      ports:
        - protocol: TCP
          port: 8080

Maintenant que tous les services web nous encouragent, de plus en plus, à utiliser une MFA pour sécuriser nos compte, l'un d'entre eux reste le plus utilisé que les autres : Mot de passe à usage unique basé sur le temps ou TOTP génère un code unique de 6 chiffres ou plus à saisir juste après avoir tapé votre mot de passe.

Le serveur ou l'application Web permettant de configurer le TOTP donne un QRCode à scanner (ou une chaîne Base32) à configurer dans une application génératrice de TOTP comme Microsoft Authenticator, Google Authenticator, Bitwarden ou plus.

Nous l'utilisons tous, mais comment ça marche ? Est-ce sécurisé ? Mon compte est-il sécurisé lorsque j'utilise un générateur de TOTP tiers ??

Le protocole​

Je vais approfondir dans les détails le protocole sous-jacent vous permettant de générer des TOTP et comment le serveur le vérifie.

Bases​

L'idée de base est assez simple. Vous et le serveur avez partagé un secret, une chaîne Base32 de 16 caractères (parfois stockée dans un QRCode). Puis vous synchronisez tous les deux vos horloges.

Enfin, lorsque vous souhaitez vous connecter, vous exécutez une fonction magique sophistiquée et vous obtenez un TOTP. Le serveur calcule le TOTP de son côté et vous demande celui que vous avez généré de votre côté. Si les deux TOTP correspondent, le serveur vous autorise à entrer.

Protocole TOTP​

Explorons le protocole TOTP. Selon la RFC 6238 vous avez besoin :

• Un compteur changeant qui doit être synchronisé entre les deux parties
• Un secret partagé entre les deux parties

Le compteur est calculé sur la base du temps epoch (Ainsi tout le monde est synchronisé) avec la formule suivante :

C = (T - T0) / X

Avec :

• C la valeur du compteur
• T l'heure Unix actuelle en secondes depuis epoch
• T0 une heure Unix de début arbitraire. 0 par défaut
• X le pas de temps en secondes ou la fréquence de mise à jour du code. 30 par défaut

Si nous essayons de faire une implémentation Python, cela ressemblera à :

t0 = 0
# https://docs.python.org/3/library/time.html#time.time
current_unix_time = time.time()
time_step = 30

counter = int((current_unix_time - t0) / time_step)

current_unix_time: 1651094239.491242


counter => 55036474

Maintenant la valeur TOTP peut être récupérée avec la formule suivante :

TOTP = HOTP(K, C, D)

Avec:

• C la valeur du compteur
• K la clé secrète
• D le nombre de chiffres dans nos TOTPs
• HOTP la fonction magique qui calcule l'OTP

En Python, on obtient :

counter = 55036474
key = "ABCDEFGHYJKLMNOP"
digits = 6

totp = hotp(key, counter, digits)

totp => 934929

Protocole HOTP​

Ce deuxième protocole est utilisé pour calculer une valeur unique, une valeur compteur et une clé secrete. De la RFC rfc4226, nous apprenons qu'il est basé sur le protocole de hachage HMAC.

Asseyez-vous bien car cela va commencer à être difficile et j'espère que vous êtes à l'aise avec les opérations binaires.

Gérer les entrées​

Tout d'abord, nous devons gérer les 2 de nos 3 paramètres d'entrée : counter, key

• counter doit être converti en une liste d'octets de type unsigned long long et big-endian.

En Python :

import struct
# https://docs.python.org/3/library/struct.html#struct.pack
# https://docs.python.org/3/library/struct.html#byte-order-size-and-alignment
# https://docs.python.org/3/library/struct.html#format-characters
bytes_counter = struct.pack('>Q', counter)

counter: 55036474


bytes_counter(bin) => 00000011 01000111 11001010 00111010
bytes_counter(hex) => 03 47 ca 3a

• key doit être une chaîne Base32 valide. La RFC 4648 nous indique que la longueur de la chaîne doit être un facteur de 8. Ainsi, du "padding" peut être ajouté avec le caractère = à la fin s'il est trop court. Par exemple : AA => AA======, BBBBBBBBBB => BBBBBBBBBB======, CCCCCCCC => CCCCCCCC

padding = '=' * ((8 - len(key)) % 8)
valid_key = key + padding

key: ABCDEFGHIJKLMNOP


valid_key => ABCDEFGHIJKLMNOP

Ensuite, nous convertissons la clé mise à jour en valeur en liste d'octets :

import base64

bytes_key = base64.b32decode(key)

valid_key: ABCDEFGHIJKLMNOP


bytes_key(bin) => 10001000 01100100 00101001 10001110 10000100 10101001 01101100 0110101 11001111
bytes_key(hex) => 44 32 14 c7 42 54 b6 35 cf

Calculer le HMAC​

En utilisant la RFC 2104 nous pouvons en comprendre le fonctionnement de la fonction HMAC. Nous devons choisir une fonction de hachage. HOTP ou RFC 4226 utilise la fonction de hachage cryptographique SHA-1.

Python implémente la bibliothèque HMAC :

import hmac

# Calculate the HMAC-SHA1 value
# Produce a 20 bytes (or 160 bites) long string
mac = hmac.new(bytes_key, bytes_counter, "SHA1").digest()

bytes_counter(hex): 03 47 ca 3a
bytes_key(hex): 44 32 14 c7 42 54 b6 35 cf


mac(bin) => 10110100 11010010 01111010 10110100 10111101 00110101 11111110 00100011 11101101 01011001 01111110 10111100 11110000 01111001 11000001 01001010 00000110 01101100 01010001 00101111
mac(hex) => b4 d2 7a b4 bd 35 fe 23 ed 59 7e bc f0 79 c1 4a 06 6c 51 2f

Calculer le HOTP​

Conformément à la section 5.3 de la RFC 4226.

Trouver le décalage​

Nous devons d'abord trouver la valeur offset en obtenant les 4 bits les moins significatifs du MAC (Les 4 à droite) en utilisation de opération bit à bit AND

En Python & peut être utilisé pour faire une opération binaire AND entre deux nombres. Avec la valeur 0x0F (en hexadécimal et équivalent à 00001111 en binaire) on peut extraire deux 4 derniers bits. Étant donné que offset est un entier stocké sur 4 bits, la valeur est comprise entre 0 et 15. En Python, nous pouvons utiliser mac[-1] pour obtenir le dernier octet de la liste d'octets converti en entier.

offset = mac[-1] & 0x0F

mac(bin): 10110100 11010010 01111010 10110100 10111101 00110101 11111110 00100011 11101101 01011001 01111110 10111100 11110000 01111001 11000001 01001010 00000110 01101100 01010001 00101111
mac(hex): b4 d2 7a b4 bd 35 fe 23 ed 59 7e bc f0 79 c1 4a 06 6c 51 2f


offset(bin) => 1111
offset(hex) => f
offset(dec) => 15

Recherche de la troncation dynamique​

En utilisant le offset trouvé précédemment, nous allons extraire la Troncation dynamique du MAC. Nous devons récupérer les 4 octets à la position offset, offset+1, offset+2 et offset+3 dans la liste d'octets MAC.

Nous avons :

dynamic_truncation = mac[offset:(offset+3)+1]

En Python, la valeur après le : n'est pas incluse. Afin d'extraire la valeur offset + 3, nous devons mettre (offset + 3) + 1

offset(bin): 1111
offset(hex): f
offset(dec): 15

offset(dec) from 15 to 18

mac(bin): 10110100 11010010 01111010 10110100 10111101 00110101 11111110 00100011 11101101 01011001 01111110 10111100 11110000 01111001 11000001 01001010 00000110 01101100 01010001 00101111
mac(hex): b4 d2 7a b4 bd 35 fe 23 ed 59 7e bc f0 79 c1 4a 06 6c 51 2f


dynamic_truncation(bin) => 10010100 00001100 11011000 1010001
dynamic_truncation(hex) => 4a 06 6c 51