Vue lecture

Maintenant - Le monitoring qui trouve vos conteneurs tout seul

"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !

Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.

Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.

Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.

Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.

Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.

Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.

Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...

A découvrir ici !

  •  

GitLab - la faille qui a fait rouvrir une version morte

GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

  •  

Cloudflare Computer - Un ordinateur dans le cloud pour votre agent IA

Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.

Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.

Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.

Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.

Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.

Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.

Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.

Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.

Il faut un compte Cloudflare, évidemment...

Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.

Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).

Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.

Source

  •  

Oracle’s AI Data Center Funding Tests OCI Delivery Timelines

Oracle is funding its AI data center expansion through corporate financing, customer-supplied hardware, and developer-level loans. Enterprise buyers still need to verify delivery dates, power dependencies, and contract protections before committing to future OCI capacity.

The post Oracle’s AI Data Center Funding Tests OCI Delivery Timelines appeared first on TechRepublic.

  •  
❌