Accueil › Archive pour TP Linux

TP Linux

Créer un dashboard Splunk d’audience avec les logs Nginx

Posté le de — Aucun commentaire ↓
La licorne Geekeries transforme d’anciens tableaux de bord en un dashboard Splunk d’audience qui sépare visiteurs humains et robots

Bonjour à tous, une fois les logs Nginx de Geekeries.org correctement ingérés dans Splunk après la dernière upgrade serveur, j’avais une question assez simple : est-ce que je pouvais faire un « vrai » dashboard Splunk de mesure d’audience, façon Google Analytics, mais sans ajouter de JavaScript, de cookie ou de nouveau tracker dans votre navigateur ?

Je voulais connaître les pages lues, les sources du trafic, les appareils utilisés et la place occupée par les robots. Je voulais aussi les visiteurs uniques, le nombre de sessions ou encore le taux de rebond. Tout en sachant que Nginx n’observe qu’une suite de requêtes HTTP. Il ne voit ni vos clics dans la page, ni votre scroll, ni le moment où vous partez faire un café en laissant l’onglet ouvert.

Le projet a commencé avec douze vieux (genre j’y avais pas touché depuis 4 ans) dashboards récupérés de mon précédent serveur. Il s’est terminé avec une vue Audience & Web Analytics de 26 panneaux, directement alimentée par les journaux du site. Entre les deux, le plus gros travail n’a pas été de dessiner des camemberts (Ca Splunk le fait très bien). Il a fallu décider ce que les données permettaient … Lire la suite

Docker et Portainer part 13 : Authentik avec Nginx Proxy Manager et des passkeys

Posté le de — Aucun commentaire ↓
La licorne Geekeries présente deux clés de sécurité devant un portail d’identité qui protège plusieurs applications derrière un proxy

Salut à tous, aujourd’hui on regarde comment déployer Authentik devant son Nginx Proxy Manager. Si vous vous rappelez j’ai plusieurs services web derrière mon reverse proxy NPM (et presque autant de façons de me connecter à chacun d’eux). Une Basic Auth par-ci, un compte local par-là, puis un autre mot de passe dans l’application elle-même. Cela fonctionnait, mais la collection de creds commençait sérieusement à ressembler à un élevage industriel (avez vous entendus parler de bitwarden notre sauveur?).

Bref, je voulais donc mettre en place un SSO : une seule identité, une authentification forte avec mes YubiKeys ou une passkey, puis des droits différents selon l’application. Comme tout passait déjà par mon reverse proxy, le projet s’est assez naturellement transformé en déploiement d’Authentik avec Nginx Proxy Manager.

Le but n’était pas de remplacer NPM. Il sait déjà très bien publier les services, gérer les certificats TLS et envoyer chaque requête au bon conteneur. Authentik devait seulement lui apporter ce qui lui manquait : savoir qui se présente et décider s’il a le droit de passer.

Bienvenue dans la treizième partie de ma série Docker et Portainer. Celle où l’on remplace enfin les petites fenêtres grises … Lire la suite

LeanCTX avec Codex : retour d’expérience après presque deux mois

Posté le de — Aucun commentaire ↓
Illustration d'une licorne rose Geekeries qui trie un tas de journaux et de documents en une pile compacte validée.

Bonjour à tous, depuis que j’utilise Codex directement sur mon serveur comme agent (Pwny), je me suis retrouvé avec un problème très connu : pour être vraiment badass, l’agent doit lire un grand volume d’information. Fichiers de configuration, journaux d’événements, le résultat de tests, et le même fichier est relu parfois trois fois pendant qu’on affine un projet. Tout ce texte part dans le contexte du modèle sous forme de fameux tokens, et un contexte rempli de lignes déjà vues est plus cher, plus lent, et… pas forcément plus intelligent.

J’ai donc testé LeanCTX avec Codex. Presque deux mois plus tard, j’avais assez de recul pour répondre à trois questions simples : qu’est-ce que cet outil fait réellement, est-ce qu’il m’a apporté quelque chose, et pourquoi je n’ai pas empilé un autre optimiseur comme RTK par-dessus ?

LeanCTX, c’est quoi au juste ?

Imaginez Codex comme le meilleur stagiaire que vous aurez jamais : rapide, bien informé, bosseur, etc., et à qui vous transmettez le résultat de vos commandes et les fichiers qu’il doit examiner. Sans LeanCTX, si vous lui donnez 5 000 lignes de logs pour retrouver une erreur, les 5 000 lignes arrivent dans sa todo, aka « … Lire la suite

Script de veille serveur sous Linux et Docker : alertes CVE, silence radio et vrais pièges

Posté le de — Aucun commentaire ↓
Illustration Geekeries d'un script de veille serveur Linux et Docker filtrant le bruit pour détecter les mises à jour de sécurité CVE

Bonjour à tous, quand on administre un serveur Linux qui héberge une vingtaine de conteneurs Docker en production, on finit vite écartelé entre deux extrêmes. Soit on délègue tout à des mises à jour automatiques aveugles (ce que je vous racontais récemment dans mon article sur MariaDB et les surprises de Watchtower et comment ça peut casser silencieusement un schéma de base de données), soit on reprend le contrôle en manuel… au risque d’oublier de vérifier les correctifs pendant trois semaines et de se faire poncer bien comme il faut ! Pour sortir de ce dilemme, j’ai construit un script de veille serveur, léger, en Python, piloté par systemd, qui inspecte l’état réel de la machine deux fois par jour sans jamais toucher à la production.

L’idée de départ est très simple : je voulais un observateur strictement en lecture seule (observer-only), capable de croiser en quelques secondes les paquets APT en attente, les images Docker (qu’elles viennent de Docker Hub, de GitHub ou d’un build local), les extensions WordPress, la fraîcheur des sauvegardes et les unités systemd. Surtout, je voulais qu’il respecte une règle d’or : se taire quand tout va bien, mais ne jamais rater … Lire la suite