Le réseau local, qu'il soit public, d'entreprise ou domestique, ne doit pas être considéré comme sûr. En effet, même si le pare-feu réseau (votre box) est bien configuré, un petit malin connecté au même réseau local peut très bien tenter de s'introduire sur une autre machine du même réseau.

Un pare-feu applicatif, comme il en existe sur tous les systèmes d'exploitation, permet d'autoriser ou d'interdire des connexions entrantes ou sortantes vers et depuis la machine sur laquelle il est installé.

Dans cet article, je vais documenter mon utilisation du pare-feu applicatif par défaut sur Debian Buster, nftables.

Après avoir mis en place une infrastructure LXD, il convient de créer un premier conteneur.

Dans mon cas, j'ai choisi de créer un conteneur servant de "modèle" à tous les autres. Des méthodes un peu plus technique existent pour faire exactement la même chose mais en partant des modèles officiels (cloud-init ou salt pour n'en citer que deux).

Cet article documente la création et configuration d'un conteneur LXC servant de base à l'ensemble de mes conteneurs.

Les utilisateurs système ont parfois des choses à dire. Imaginons par exemple qu'une tâche planifiée tourne et que sa sortie vous intéresse ; ça pourrait être pratique de la voir, non ?

Dans cet article, je documente l'installation et la configuration d'un client permettant d'envoyer des courriels (SMTP) depuis un fournisseur tiers.

Avant de louer mon premier serveur dédié, je me suis posé la question du cloisonnement des différents services que je souhaitais héberger. N'ayant pas les moyens de louer un serveur performant pour faire de la virtualisation, je me suis intéressé à la conteneurisation. A l'époque, j'ai fait la découverte de Proxmox VE qui m'a permis d'apprendre, de façon simple, la conteneurisation via OpenVZ, puis LXC.

Quelques mois après avoir acquis un mini-ordinateur Rock64, je me suis naturellement tourné vers Proxmox VE. Malheureusement, le projet ne supporte pas (encore ?) l'architecture arm64 ou armhf. Je me suis alors tourné vers une autre solution, LXD. D'abord testé sur mon Rock64, j'ai finalement décidé de louer un serveur dédié encore moins onéreux et performant pour y déployer LXD.

Cet article documente l'installation et la configuration de LXD sur un serveur Kimsifu KS-3.

Acheté à l'occasion d'une promotion sur Steam, je ne regrette pas mon achat mais ne comprends pas comment on peut salir autant la licence.

Le jeu est plein d'aberrations graphiques. Je ne parle pas de bug parce que le jeu est sorti il y a suffisamment longtemps pour laisser le temps aux développeurs de corriger ces phénomènes. Deux exemples qui m'ont profondément agacé :

• lors de la première arrivée dans le vaisseau, les vêtements continuent à flotter au vent lors du tout premier dialogue avec Cere
• après avoir personnalisé son sabre laser dans le vaisseau, une animation fait sortir la lame qui passe au travers d'une poutre située au dessus de la table de personnalisation Alors oui, on pourrait se dire que ce n'est pas dramatique, mais il s'agit là d'un jeu Electronics Art et non d'un tout petit studio indépendant...

Les scènes d'action dans le jeu ont été particulièrement frustrantes pour moi. A aucun moment je n'avais la sensation de vraiment combattre. Cela m'a poussé à progressivement passer du niveau de difficulté Grand Maître Jedi à Mode Histoire.

Point positif qui fait que je ne regrette pas mon achat : le scénario. On est plongé dans un univers post-purge où on évolue avec un Jedi qui y a survécu en s'enfuyant au bon moment et en se cachant depuis. On rencontre quelques têtes connues ce qui nous permet d'avoir une idée d'où ces personnages en sont lorsque les Jedi les ont abandonné à leur sort.

Pour conclure, un jeu à acheter en promo et uniquement si vous accrochez vraiment avec l'environnement Star Wars.

Depuis de nombreuses années, je m'agace de l'image de Debian qu'OVH a créé pour les serveurs Kimsufi. Cette image dispose de paquets dont je n'ai pas utilité et certains choix d'OVH me posent problème, comme par exemple, désactiver BTRFS.

Bref, j'ai cherché une solution et comme toujours, j'ai trouvé. Vive l'informatique ! La solution consiste à installer Debian depuis le mode de récupération d'OVH. Le mode de récupération n'est autre qu'une session live de Debian Jessie (à l'heure où j'écris).

L'installation se fait via le paquet debootstrap qui permet d'installer Debian depuis une autre Debian.

Bref, à l'attaque !

Avec le déménagement qui approche, cela fait presque deux mois que je n'ai rien publié. Ce n'est pas la plus longue période d'inactivité, mais aujourd'hui je viens justement vous prouver que je n'ai pas été inactif. En effet, avec le déménagement, je vais enfin avoir une vraie place pour un projet que j'ai en tête depuis un moment : l'auto-hébergement à domicile.

Toute l'impatience qui me caractérise m'a fait acheter un Rock64. Ce mini-ordinateur de type Rapsberry Pi est le tout premier d'une ferme de trois permettant, à terme, d'héberger l'ensemble de mes services.

En lisant la suite de cet article, vous trouverez une documentation sur ma façon de configurer la Debian 10 dédiée au Rock64. Cette documentation va servir de base à un playbook Ansible me permettant de configurer à l'identique l'ensemble des trois hôtes de mon futur cluster.

Ce n'est pas une vraie question, mais plutôt ce que je pense et constate.

Un exemple qui me vient tout de suite en tête, c'est la saga Star Wars. Pour moi, les épisodes de 4 à 6, dans leur version cinéma originale, sont un excellent exemple de films ayant très bien vieilli. Évidemment, si on s'attarde sur certains plans, on se rend compte de l'aspect "faux" de quelques éléments. Toutefois, "faux" n'est pas le bon terme puisque la majorité de ce qu'on voit à l'image existe réellement sous forme de maquette. À l’inverse, les épisodes 1 à 3 utilisent énormément d'images de synthèse, aussi appelées infographies (CGI en anglais).

Nous y voilà, le cœur de la cerise du nœud du problème. L'infographie vieillit plus vite que des décors sous forme de maquettes, surtout si ces dernières ont été particulièrement soignées. Malheureusement, de plus en plus de films utilisent massivement l'infographie pour pratiquement tout ce que voit le spectateur. Si cela permet d'avoir de très beaux films lors de leur sortie en salle, ils ont du mal à supporter mon oeil critique cinq ou dix ans après. Afin d'illustrer mes propos, je suggère de comparer le tout premier Avengers (2012), au tout dernier Avengers: Endgame (2019). Même si le premier tient encore la route, les images de synthèses font pâle figure par rapport au dernier. Pourtant, moins de dix ans séparent ces deux films !

Dans quinze ou vingt ans, que va-t-il rester des films utilisant massivement l'infographie ? Va-t-on avoir le droit à des reboot/remake sous forme de boucle ? Ou alors, peut-on tout simplement considérer que ce sont des films jetables ?

J'ai enfin terminé ce jeu ! Après 7 heures de stress permanent, c'est la délivrance. Les graphismes sont magnifiques, l'histoire est bien ficelée et que dire de l'ambiance... magistrale ! Je ne suis pas du genre peureux et pourtant, je n'étais pas tranquille en jouant à ce jeu. La psychose du personnage est parfaitement délivrée au joueur. J'avais initialement prévu de finir le jeu en une seule fois, mais l'atmosphère pesait beaucoup trop sur mon état moral et mental. Il ne faut clairement pas mettre ce jeu entre toutes les mains.

A ceux qui pensent que c'est un jeu d'horreur, il n'en est rien. On est purement dans l'angoisse permanente, et ce, uniquement grâce à l'ambiance qui a été créée. J'imagine que certains sont plus affectés que d'autres en jouant à ce jeu et que cela détermine finalement le plaisir qu'on a en y jouant.

L'audio du jeu est entièrement en anglais. Ça m'arrange parce que le doublage n'est pas toujours au top, mais cela pourrait en gêner certains.

Petite remarque pour finir, les fautes de frappe en fin de jeu sont un peu décevantes.

Depuis bien longtemps, j'utilise cet article comme documentation, mais je me suis dit que ça ne serait pas mal de faire la mienne.

L'idée ici est de générer deux clefs permettant de rendre la connexion SSH fluide mais aussi de pouvoir exécuter des tâches. Il est nécessaire de créer deux clefs :

• la clef privée : à ne jamais transmettre à qui que ce soit, elle permet d'identifier qui glisse la clef dans la serrure
• la clef publique : qui doit être placée sur l'ensemble des machines où l'on souhaite se connecter, c'est elle la clef de la serrure