Un diagramme montre un utilisateur sur un ordinateur portable étiqueté "Utilisateur" sur Windows ou macOS, une flèche vers des serveurs empilés étiquetés "Serveur proxy", et une autre flèche vers un globe étiqueté "Internet", illustrant comment tester un serveur proxy processus.

Tester un proxy sous Windows, macOS et Linux

Si vous avez suivi l’article précédent intitulé le proxy ou comment renforcer anonymat et sécurité, vous savez qu’il existe plusieurs types de proxy, avec différentes couches d’anonymat.

Un proxy peut servir à filtrer le trafic, sortir par une autre adresse IP, diagnostiquer une application, accéder à un réseau d’entreprise, tester une API, ou vérifier le comportement d’un site depuis un autre point de sortie.

Mais avant de l’utiliser sérieusement, il faut répondre à une question simple : ce proxy fonctionne-t-il vraiment ?

Un proxy qui “répond” n’est pas forcément utilisable. Il peut être lent, bloquer HTTPS, exiger une authentification, transmettre votre IP réelle dans les en-têtes, résoudre les DNS localement, ou ne fonctionner que depuis certains réseaux.

Voici une méthode moderne, claire et durable pour tester un proxy sous Windows, macOS et Linux, avec les réglages système, Firefox, curl, PowerShell, les variables d’environnement et quelques tests réseau fiables.

Lire la suite

Illustration d'un ordinateur portable fonctionnant sous Ubuntu avec du code sur son écran, un grand bouclier avec un cadenas devant, et des serveurs derrière. Des engrenages, des camemberts et des graphiques représentent la cybersécurité, la protection des données et l'importance de réparer la mise à niveau.

Ubuntu : réparer une mise à niveau plantée ou interrompue

Une mise à niveau Ubuntu peut parfois mal se terminer : coupure de courant, batterie vide, paquet cassé, pilote graphique incompatible, partition pleine, GRUB endommagé ou redémarrage au mauvais moment. Résultat : Ubuntu ne démarre plus, reste bloqué sur un écran noir, affiche un shell d’urgence ou refuse d’ouvrir la session graphique.

Bonne nouvelle : dans beaucoup de cas, le système n’est pas perdu. Il faut surtout terminer proprement la mise à niveau, réparer les paquets cassés, régénérer GRUB ou corriger les pilotes. Mauvaise nouvelle : il faut procéder méthodiquement. Le mode “je tape dix commandes trouvées au hasard” marche rarement mieux qu’un tournevis dans un grille-pain.

Voici une méthode moderne pour réparer Ubuntu après une mise à niveau plantée ou interrompue, depuis le mode recovery ou depuis une clé USB live.

Lire la suite

Le logo de MySQL représente le contour minimaliste d'un dauphin sautant au-dessus du mot "MySQL". Le mot "My" est en bleu et le mot "SQL" en orange, le tout dans une police de caractères moderne et arrondie. Le dauphin symbolise la vitesse et la fiabilité lors des opérations sur les tables.

MySQL : gérer, purger ou désactiver les binary logs

Sur un serveur MySQL, les binary logs peuvent vite prendre beaucoup de place. Il n’est pas rare de découvrir plusieurs dizaines, voire plusieurs centaines de gigaoctets de fichiers binlog.* après quelques mois d’activité.

Ces fichiers ne sont pas des logs applicatifs classiques. Ils enregistrent les modifications effectuées sur les bases de données, afin de permettre la réplication, certaines stratégies de sauvegarde, et la restauration à un point précis dans le temps.

En clair : avant de les supprimer ou de les désactiver, il faut comprendre à quoi ils servent sur votre serveur. Sinon, vous risquez de récupérer de l’espace disque tout en cassant votre stratégie de backup. Mauvais troc.

À quoi servent les binary logs MySQL ?

Les binary logs, ou journaux binaires, enregistrent les événements qui modifient les données : INSERT, UPDATE, DELETE, créations de tables, modifications de structure, etc.

Ils servent principalement à trois choses :

  • répliquer les modifications vers un ou plusieurs serveurs replicas ;
  • rejouer des transactions après une restauration de sauvegarde ;
  • faire du point-in-time recovery, c’est-à-dire restaurer une base jusqu’à un instant précis.

Si votre serveur MySQL est autonome, sans réplication, sans cluster, sans sauvegarde incrémentale basée sur les binary logs, et sans besoin de restauration fine, vous pouvez envisager de désactiver les binary logs.

En revanche, si vous utilisez la réplication, MySQL Router, un cluster, un service de backup qui lit les binlogs, ou une stratégie de restauration avancée, ne les désactivez pas. Dans ce cas, configurez plutôt une rétention raisonnable.

Lire la suite