Blog

Un serveur virtuel (ou vhost) est une fonctionnalité offerte par les logiciels de serveur Web permettant de répartir sur un seul serveur applicatif une ou plusieurs applications. C’est peu ou prou le socle d’un reverse proxy : offrir un point d’entrée unique pour protéger l’accès des vraies applications. La configuration d’un tel vhost n’oppose aucune difficulté, mais cette configuration ne suffit pas pour le routage. Comme le dit si bien la documentation d’Apache :

Dans l’illustration de l’article « À quoi joue la sécurisation d’un système d’information », quelque chose à dû vous surprendre : passée la deuxième colonne de classe de caractères, il est plus long de déchiffrer un mot de passe lorsqu’on descend d’un cran vers le bas plutôt que quand on avance d’un cran vers la droite. Autrement dit, il est plus sécurisant de rallonger notre mot de passe plutôt que de le rendre plus complexe.

Personnellement, rsync me fascine. Au premier regard, c’est une simple copie à travers le réseau, mais sous le capot c’est plus que ça : s’il a écrasé tous les autres sur le même secteur, c’est parce qu’il fait de la synchronisation différentielle. C’est ça sa killer feature. À l’ère où nous avons des réseaux de diverses bandes passantes et des fichiers de toutes tailles, un mécanisme de transfert intelligent comme celui de rsync est bienvenu.

L’une des règles les plus importantes en sécurité, c’est de ne pas ignorer les alertes. Prenons un exemple de la vie de tous les jours : imaginons que votre activité se porte bien et que votre administrateur système ajoute un serveur à l’infrastructure. Un jour, vous tentez de vous y connecter et vous tombez sur le message suivant : > ssh ca.redwatch.io The authenticity of host 'ca.redwatch.io (172.18.0.3)' can't be established.

Quand on programme, arrive un moment où une situation de répétition survient. Dans ce cas-là, se pose la question « récursion vs itération » : autrement dit, doit-on voir cette répétition comme une séquence à recommencer ou comme un problème constitué de lui-même ? C’est un choix très personnel, basé entre autres sur l’aisance du développeur avec la pratique et ce qu’il y projette (soyons honnêtes, nous sommes sujets à des biais).

La sécurité de l’information est comme le jeu du chat et de la souris. Du point de vue de la souris, l’objectif du « jeu » est sa survie, mais pas de n’importe quelle façon : elle n’est biologiquement pas armée pour distancer le chat, donc son but est de trouver une cachette le plus rapidement possible pour échapper à son poursuivant. En IT, à quel jeu joue la cible des attaques ?

Le sujet du versionnement et les erreurs induites par semver m’importe, ça n’a pas dû vous échapper depuis la publication du billet Oubliez ce que vous pensez savoir sur semver. C’est pour cette raison que j’ai repris la conception d’un outil que j’avais commencé il y a 5 ans : checkbreak. Comme je l’évoquais, le problème de semver est le défaut de connaissances du responsable de la release, qu’il soit théorique ou conjoncturel.

En programmation orientée objet, les participants de l’environnement sont représentés comme des encapsulations autonomes décrivant complètement les attributs et les comportements du sujet. Ainsi, sans que ce soit un prérequis absolu à la POO, il est pratique de faire hériter des objets d’autres pour éviter la répétition ; on dit alors que l’objet A est fils de l’objet B. Seulement voilà, il arrive qu’en réalité A n’est pas vraiment un fils de B.

Combien cat consomme en mémoire vive ? Cette consommation croît-elle avec la taille du fichier ? Ces questions peuvent paraître triviales, mais posez-vous la question de la fréquence où vous utilisez cet outil… et la fréquence où vous vous interrogez sur le poids du fichier que vous faites ingérer à cat. On ne se pose tout simplement pas la question, précisément parce que l’outil ne bronche pas ; tout passe, et sur toute machine.

Il existe une diversité de systèmes de numérotation des logiciels, du plus simple (n+1) au plus exotique (suivant les décimales de Pi). Dans le lot, semver décrit une numérotation en trinôme M.m.p où M représente des changements non rétro-compatibles, m représente des changements rétrocompatibles et p représente des correctifs. Puisque chaque système vise à bien communiquer aux consommateurs, semver semble la solution parfaite. Semble seulement, car en fait cet idéal de communication parfaite n’est pas atteint ; le problème est la nature d’un changement rétro-incompatible.