Codex en terminal avec un daemon local : mon plan B à VS Code Web

La licorne Geekeries utilise Codex en terminal relié à un daemon local pendant qu'une fenêtre web se déconnecte

Bonjour à tous, mon passage à Codex en terminal n’était pas vraiment prévu. Tout a commencé avec ce message dans VS Code Web :

Cannot activate the 'Codex – OpenAI’s coding agent' extension because it depends on the 'Codex Audio' extension which is disabled.

Le petit bricolage qui me permettait d’utiliser l’extension Codex dans mon VS Code Web venait peut-être d’atteindre sa limite. Je pouvais chercher une nouvelle rustine, mais ce genre de dépendance interne est précisément ce que je ne contrôle pas. J’ai donc préféré sortir Pwny de l’extension et revenir à une base officiellement prise en charge : le client Codex en ligne de commande.

L’objectif restait le même que dans mon article sur VS Code Web et Codex sur serveur : ouvrir un navigateur, retrouver mon espace de travail et discuter directement avec la licorne. La différence est que VS Code Web ne sert désormais plus que de fenêtre et de terminal. La session Codex vit indépendamment derrière.

Pourquoi sortir Codex de l’extension VS Code ?

Une extension intégrée reste plus confortable. Les liens vers les fichiers s’ouvrent mieux, les images se joignent plus naturellement et l’interface donne davantage l’impression de travailler dans un petit cockpit. Je … Lire la suite

Fail2ban devant Nginx Proxy Manager : bloquer les attaques sans casser Docker

Une licorne Geekeries protège Nginx Proxy Manager avec un bouclier Fail2ban devant des requêtes rejetées

Salut les Geeks ! Après avoir placé mon VS Code Web derrière une Basic Auth, il restait un détail : un attaquant pouvait toujours essayer des mots de passe toute la journée sur la basic auth et chopper un accès root au serveur. J’ai donc configuré Fail2ban avec Nginx Proxy Manager, sans modifier l’image Docker de NPM et sans ajouter un conteneur privilégié de plus. La recette paraît courte, mais Docker cache un petit piège dans ses chaînes iptables.

Ce tutoriel part d’un Nginx Proxy Manager installé avec Docker Compose, dont le dossier /data est persistant sur l’hôte. Adaptez les chemins et l’identifiant du Proxy Host à votre installation. Surtout, gardez une seconde session SSH ouverte pendant les essais. Du coup on va dire que cet article est un Spin-off de la la série « Docker et Portainer », pour rappel

  1. Les conteneurs pour les débutants
  2. Créer une stack vsftpd mono-image
  3. Déployer une stack Docker Guacamole
  4. Docker, OpenVPN et Splunk
  5. Customiser un conteneur PHP-FPM
  6. Déployer Nextcloud avec Docker
  7. Mettre à jour Portainer et ses conteneurs
  8. Déployer Jitsi Meet avec Docker
  9. Superviser Docker avec Splunk
  10. Installer TheHive et Cortex avec Docker
  11. Installer OpenCTI avec Docker
  12. MariaDB, quand latest casse
… Lire la suite

VS Code Web et Codex sur mon serveur : du conteneur au système

Une licorne Geekeries utilise VS Code dans son navigateur à travers un reverse proxy pour administrer un serveur, tandis qu’un conteneur vide reste de côté

Bonjour à tous, après avoir utilisé Codex en Remote SSH pour moderniser mon système de backup, j’avais envie d’aller un cran plus loin : retrouver VS Code Web sur mon serveur, directement dans un navigateur, avec le même workspace et un Codex capable d’investiguer sur la machine. Bref, comme à la maison, mais en version Web, depuis n’importe où.

Le besoin est assez concret. Depuis mon PC personnel, le client lourd VS Code et Remote SSH font parfaitement le travail. Depuis un PC professionnel (ou en nomadisme) sur lequel je ne veux pas, ou ne peux pas, installer toute ma configuration, je voulais simplement ouvrir une URL, passer l’authentification et retrouver mon environnement de dev sur le serveur.

Sur le papier, cela ressemble à une stack Portainer de plus. J’avais déjà Docker, un reverse proxy, un réseau de conteneurs et l’habitude de déployer des services web avec Compose. Il suffisait donc de trouver une image contenant VS Code et Codex, de monter mon workspace et de cliquer sur Deploy the stack.

Évidemment, si cela s’était passé comme ça, cet article ferait huit lignes au lieu de frôler les 5000 mots… Entre le bureau Kasm qui ne … Lire la suite

Moderniser iptables après 10 ans… sans casser Docker !

Licorne sysadmin réorganisant un ancien classeur de règles firewall en chemins SSH, Docker et blacklist IP

Bonjour à tous, aujourd’hui on va parler du firewall iptables, et de vieux articles qui ont plutôt bien vieilli (et d’un quatrième encore tout frais), et d’une petite modification d’interface réseau qui aurait pu mettre le serveur dans le noir. Bref, un sujet parfaitement raisonnable à traiter un soir en SSH.

Pour rappel, ou pour les nouveaux qui nous rejoignent (coucou 👋) le serveur qui héberge ce site est directement exposé dans un datacenter OVH. Il porte plusieurs services web derrière un Nginx Proxy Manager, lui-même dans Docker (cf. ma série sur Docker), sans WAF ou CDN externe pour cacher la m… poussière sous le tapis. Les ports 22, 80 et 443 doivent rester accessibles depuis Internet. Et toute la politique du firewall doit donc fonctionner pour de vrai, dans l’environnement « à peine agressif d’Internet », pas seulement avoir l’air impressionnante dans un article du blog.

La leçon de cette migration tient en une phrase : un firewall n’est pas une liste de règles, c’est le chemin réel suivi par les paquets. Et ce chemin avait beaucoup changé depuis 2017.

Quatre articles, quatre couches de défense du firewall iptables

Ce chantier est le fils spirituel … Lire la suite