Rechercher dans la communauté

Je suis enfin arrivé à jouer à mes jeux favoris sous Linux, et sans trop de difficulté finalement... J'ai installé la distribution Linux Pop!_OS qui est prête pour jouer sous Linux, en suivant ce tuto : Après l'installation et le redémarrage, ainsi que les quelques outils supplémentaires indiqués dans la vidéo précédente, voici la copie d'écran réalisée en jouant à Trackmania Stadium. Le jeu est très fluide, comme sous Windows, c'est parfait.

durée de lecture : 7 min Parmi les fonctionnalités offertes par Proxmox VE pour gérer les machines virtuelles et les conteneurs, il y a les snapshots et les sauvegardes. Bien que ces deux fonctionnalités soient associées à la protection des données, elles servent des objectifs distincts et fonctionnent différemment. Cet article fait un focus sur les snapshots avec les machines virtuelles Proxmox, mais il me semble important d'y associer un rappel sur les différences entre les snapshots et les sauvegardes (backup). Cliquez ici pour regarder la vidéo sur YouTube Il y a parfois une certaine confusion entre les snapshots et les backups, et pourtant, les intérêts de ces deux fonctionnalités sont différents. Snapshots (Instantanés) Un snapshot dans Proxmox VE est une capture de l'état d'une VM ou d'un conteneur à un moment précis. Son principal objectif est de créer un point de restauration rapide afin de pouvoir revenir en arrière (ou naviguer entre plusieurs états). Lorsque vous prenez un snapshot, Proxmox VE enregistre la configuration de la VM à ce moment-là. Ensuite, toutes les modifications ultérieures de la VM sont écrites dans un nouveau fichier, tandis que les données d'origine restent inchangées, permettant ainsi de revenir rapidement à l'état capturé. En général, ces données sont stockées dans le même répertoire que les données de la machine virtuelle en elle-même. L'objectif principal est de pouvoir revenir rapidement à un état antérieur en cas de problème (par exemple, après une mise à jour logicielle ratée, une modification de configuration risquée ou pour des tests). Le snapshot a vocation à être temporaire. Backups (Sauvegardes) Une sauvegarde est une copie complète et autonome des données et de la configuration d'une VM ou d'un conteneur à un moment donné. Pour réaliser ses sauvegardes, Proxmox VE s'appuie l'outil de sauvegarde intégré : vzdump, à ne pas confondre avec la solution Proxmox Backup Server. Cet outil crée une archive complète des données de la ressource (machine virtuelle ou snapshot), y compris les fichiers de configuration. La sauvegarde, quant à elle, est de préférence stockée sur un espace de stockage externe (NAS ou autre). L'objectif principal est d'assurer la récupération après sinistre (perte de données, erreur système critique, etc.) ou l'archivage à long terme. Une sauvegarde, contrairement à un snapshot, est associé à une stratégie de rétention. Pour commencer, nous verrons comment créer, modifier, restaurer et supprimer un snapshot à partir de l'interface web (GUI) de Proxmox VE. Ce sera l'occasion de voir la mécanique de fonctionnement des snapshots en prenant un exemple. Avant de commencer, voici une précision associée au format du disque et la compatibilité avec les snapshots : Le format qcow2 (QEMU image format) prend en charge nativement les snapshots de l'image disque. Le format raw (image disque brute) ne prend pas en charge les snapshots par lui-même, donc il nécessite que la couche de stockage gère cette fonctionnalité. Autrement dit, dans certains cas, il se peut que les snapshots ne soient pas possibles ! Vous pouvez consulter le tableau sur cette page, il offre une bonne vue d'ensemble. Nous allons voir comment créer un snapshot d'une VM Proxmox. Actuellement, nous avons l'état suivant : une machine Debian 12 sur laquelle Apache2 n'est pas installé. Avant de procéder à l'installation, et pour avoir la possibilité de revenir en arrière, nous allons faire un snapshot. Voici les étapes à suivre : 1. Connectez-vous à votre interface web Proxmox VE. Dans l'arborescence des ressources à gauche, sélectionnez le nœud sur lequel la VM est hébergée. 2. Sélectionnez la VM pour laquelle vous souhaitez créer un snapshot, ici c'est la VM avec l'ID 100. 3. Dans le menu dédié à la VM, cliquez sur "Snapshots" puis sur le bouton "Take Snapshot". Une boîte de dialogue s'ouvrira. Vous devez alors saisir un nom, par exemple Snap1-20250723-Avant-Apache et une description. Sachez que vous pouvez créer plusieurs snapshots pour une même VM. Lors de la création d'un instantané sur une machine virtuelle, il y a une option nommée "Include RAM". Cochez cette option si vous souhaitez que le snapshot inclue l'état de la mémoire vive de la VM. Cela permet de restaurer la VM exactement dans l'état où elle se trouvait au moment du snapshot, sans nécessiter un démarrage complet. Cliquez sur "Take Snapshot" pour confirmer. La création du snapshot est un succès, comme le prouve le message TASK OK dans la sortie. Désormais, l'état actuel (NOW) est positionné sous notre snapshot, puisque ce dernier correspond à un état antérieur. La date et l'heure à laquelle le snapshot a été créé est clairement spécifiée, ce qui est une information essentielle. Vous pouvez éditer un snapshot à tout moment, ce sera l'occasion de modifier sa description. Toujours sur ce même machine Debian 12, j'ai pu procéder à l'installation d'Apache2. Mais, finalement, j'aimerais revenir en arrière. Je pourrais prendre le temps de supprimer le paquet et nettoyer le système. Néanmoins, nous allons simplement restaurer le snapshot pour revenir à l'état antérieur. Suivez ces étapes : 1 - Toujours dans la gestion de la VM, cliquez sur "Snapshots" 2 - Sélectionnez le snapshot à restaurer. 3 - Cliquez sur le bouton d'action nommé "Rollback". 4 - Cliquez sur "Yes" pour valider. Attention, les modifications effectuées après l'état capturé dans l'instantané seront perdues. Patientez le temps de l'opération. À partir de là, le snapshot a été restauré, mais il est toujours présent. Si vous n'en avez plus besoin, il conviendra de le supprimer. J'en profite pour évoquer la possibilité de créer plusieurs snapshots. Vous pouvez ensuite naviguer entre les différents états. Ce qui est important, c'est le positionnement du pointeur "NOW". Ici, nous pouvons voir que l'état actuel est basé sur le snapshot Snap1, et non sur le Snap2. Avec ce second exemple, l'état actuel est basé sur le Snap2. Nous n'avons plus besoin de notre snapshot, alors il est temps de le supprimer. En effet, le snapshot peut avoir un impact sur les performances et aussi augmenter la consommation sur l'espace de stockage. N'oublions pas qu'il a vocation à être temporaire. Pour supprimer un snapshot, procédez toujours depuis la section "Snapshots" de la ressource. Vous devez simplement sélectionner le snapshot à supprimer et cliquez sur le bouton "Remove". Confirmez l'opération. Dans la suite de ce tutoriel, nous allons basculer en ligne de commande pour effectuer la gestion des snapshots sur une machine virtuelle. Avant de commencer, vous devez accéder à ce terminal, soit via l'interface web de Proxmox VE ou en connexion SSH directe. 1 - Cliquez sur votre nœud PVE sur la gauche. 2 - Sélectionnez "Shell" dans le menu et connectez-vous avec votre compte. 3 - Vous pouvez lister vos machines virtuelles avec la commande qm list. Vous devez utiliser la commande qm snapshot pour créer un snapshot. Celle-ci attend plusieurs informations comme l'ID de la VM et le nom du snapshot. La syntaxe à adopter est la suivante : qm snapshot <VMID> <NOM_DU_SNAPSHOT> [OPTIONS] Donc, pour créer un snapshot sur la VM avec l'ID 100, nommer ce snapshot Snap-avec-Shell et lui ajouter une description, tout en capturant l'état de la RAM, il conviendra d'exécuter cette commande : qm snapshot 100 Snap-avec-Shell --description "Snapshot créé depuis le Shell Proxmox" --vmstate true Vous pouvez ensuite lister les snapshots de cette VM : qm listsnapshot 100 Bien entendu, sur l'interface web de Proxmox, cet instantané est visible : Pour restaurer le snapshot que nous venons de créer, nous devons utiliser la commande qm rollback de cette façon : qm rollback <VMID> <NOM_DU_SNAPSHOT> Dans notre cas, la commande serait donc : qm rollback 100 Snap-avec-Shell Enfin, si nous n'avons plus besoin de ce snapshot, nous pouvons le supprimer avec une autre commande prévue à cet effet : qm delsnapshot. Elle s'utilise sur le même principe que la commande pour le rollback : qm delsnapshot <VMID> <NOM_DU_SNAPSHOT> Dans le cas présent, nous devons exécuter cette commande : qm delsnapshot 100 Snap-avec-Shell Logical volume "vm-100-state-Snap-avec-Shell" successfully removed. Logical volume "snap_vm-100-disk-0_Snap-avec-Shell" successfully removed. En suivant ce tutoriel, vous êtes en mesure de créer, restaurer et supprimer les snapshots sur les machines virtuelles (et les conteneurs) hébergés sur Proxmox VE. Vous pouvez procéder via l'interface web ou la ligne de commande, selon vos besoins. La ligne de commande est plus intéressante lorsqu'il y a des tâches à automatiser. Afficher l’article complet

durée de lecture : 9 min Surveiller et comprendre les logs serveur Linux est une compétence essentielle pour tout administrateur système. Que ce soit pour diagnostiquer un problème au démarrage ou auditer les connexions SSH, les logs de démarrage Linux et les logs de connexion Linux offrent une mine d’informations précieuses. Grâce à des outils comme journalctl ou en consultant des fichiers tels que /var/log/auth.log, vous pouvez facilement repérer les tentatives de connexion échouées, détecter des comportements anormaux ou encore assurer la sécurité de votre serveur Linux. Dans ce tutoriel, nous allons voir comment analyser les logs de démarrage et de connexion, quels fichiers et commandes utiliser, et quelles bonnes pratiques adopter pour l’analyse des logs Linux. Que vous soyez débutant ou administrateur expérimenté, cet article vous donnera toutes les clés pour maîtriser l’analyse des logs sur un serveur Linux. Sommaire de l'article 1 Comprendre les logs serveur Linux et leur rôle essentiel 1.1 Importance des logs pour la sécurité et le diagnostic 1.2 Emplacement des fichiers de logs principaux 2 Analyser les logs de démarrage 2.1 Utilisation de journalctl pour les logs de démarrage 2.2 Commande Last et fichier wtmp 2.3 Interprétation des messages de démarrage 3 Sécuriser votre système grâce à l’analyse des logs serveur Linux 3.1 Analyse de /var/log/auth.log pour les connexions SSH 3.2 Détection des tentatives de connexion échouées 4 Mettre en place la rotation de fichier log 5 FAQ – Analyse des logs de démarrage et de connexion sur un serveur Linux Comprendre les logs serveur Linux et leur rôle essentiel Importance des logs pour la sécurité et le diagnostic Les logs système sous Linux jouent un rôle essentiel dans la gestion, le diagnostic et la sécurité d’un serveur. Ils permettent de retracer les événements du système, d’identifier des erreurs au démarrage, de surveiller l’activité des utilisateurs et de détecter d’éventuelles tentatives de connexion non autorisées. Une bonne maîtrise de l’analyse des logs permet de réagir rapidement face à un dysfonctionnement ou une menace de sécurité. En consultant régulièrement les logs de démarrage Linux et les logs de connexion Linux, un administrateur peut anticiper les problèmes et renforcer la sécurité du serveur Linux. Emplacement des fichiers de logs principaux Sous Linux, la majorité des fichiers de logs sont stockés dans le répertoire /var/log. Voici quelques-uns des fichiers les plus utilisés pour l’analyse : /var/log/syslog ou /var/log/messages : contiennent des informations générales sur le système. /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (CentOS/RHEL) : enregistrent les connexions SSH, les authentifications et les tentatives échouées. /var/log/dmesg : stocke les messages du noyau au démarrage. /var/log/boot.log : affiche les messages relatifs à la séquence de démarrage. /var/log/faillog et /var/log/lastlog : utiles pour suivre les échecs d’authentification et les dernières connexions. Pour une vision consolidée des événements, l’outil journalctl, utilisé avec systemd, permet de consulter l’ensemble des logs système de manière centralisée et filtrée, notamment ceux liés au démarrage et aux connexions utilisateur. Analyser les logs de démarrage Utilisation de journalctl pour les logs de démarrage Sous les distributions Linux utilisant systemd, la commande journalctl est l’outil principal pour consulter les logs de démarrage Linux. Elle permet d’extraire toutes les informations liées à la séquence de démarrage, depuis le moment où le noyau est chargé jusqu’au lancement complet du système. Pour visualiser les logs du dernier démarrage, on peut utiliser la commande : journalctl -b Vous pouvez également filtrer par niveau de gravité (erreur, avertissement, etc.) ou par unité systemd spécifique. Cela permet de diagnostiquer rapidement les lenteurs de démarrage ou les services défaillants sur votre serveur Linux. Commande Last et fichier wtmp Sous Linux, la commande last permet de lire le contenu des fichiers /var/log/wtmp et /var/log/btmp. Pour connaître les dates et heures ou la machine s’est arrêtée il suffit de taper la commande : #last –x shutdown --time-format iso Les différents shutdown, sont classés du plus récent au plus vieux. Le paramètre –time-format iso permet d’ajouter des informations comme l’année par exemple et à un format de date plus lisible, du moins pour ma part. Pour connaître les dates et heures ou la machine a rebooté, il suffit de taper la commande : #last –x reboot --time-format iso Nous voyons ici que le denier reboot date du 1 mai 2025 à 19h25. Information!!! Le paramètre –x permet d’afficher également les arrêts du système et les modifications de niveau d’exécution (run level). Le fichier wtmp contient une trace de toutes les connexion et déconnexions du système (arrêt, reboot). Le fichier btmp contient tous les échecs de connexions à votre système. Il est impossible de lire directement ces fichiers avec un éditeur de texte type vi ou vim. Voici un exemple avec le fichier btmp : Ah oui, pas facile pour récupérer les informations. Pour lire le fichier de façon plus agréable, vous devez utiliser la commande suivante (vous pouvez utiliser la même commande pour le fichier wtmp): #last –f /var/log/btmp 1: login utilisé pour se connecter à votre machine. 2: type de connexion utilisée, ici ssh 3: adresse ip du hackeur 4: date de tentative de connexion Comme vous pouvez le constater ici l’ip 185.227.152.113 effectue de la brute force pour récupérer un accès sur ma machine. Interprétation des messages de démarrage Les messages de démarrage fournissent des indications précieuses sur le bon fonctionnement des différents composants du système. Ils incluent notamment : Le chargement du noyau et des modules, La détection du matériel, Le montage des systèmes de fichiers, Le démarrage des services systemd. Il est essentiel d’identifier les messages d’erreur (souvent signalés par Failed ou Error) qui peuvent ralentir ou bloquer le démarrage du serveur. De même, les messages comme Job running, Timeout, ou Dependency failed indiquent des problèmes de dépendances ou de services mal configurés. Une analyse régulière des logs de démarrage permet de s’assurer que le système reste stable et performant, et d’intervenir rapidement en cas d’anomalie. Sécuriser votre système grâce à l’analyse des logs serveur Linux Analyse de /var/log/auth.log pour les connexions SSH L’un des fichiers les plus importants pour suivre l’activité des connexions SSH sur un serveur Linux est le fichier /var/log/auth.log (ou /var/log/secure sur CentOS/RHEL). Il enregistre toutes les tentatives d’authentification, qu’elles soient réussies ou échouées, ainsi que les élévations de privilèges via sudo. Pour examiner ces logs de connexion Linux, vous pouvez utiliser une commande comme : grep sshd /var/log/auth.log Cela vous permettra d’identifier quels utilisateurs se sont connectés, à quel moment, depuis quelle adresse IP, et s’ils ont été authentifiés avec succès. Cette analyse est essentielle pour auditer les connexions SSH et maintenir la traçabilité des accès sur votre serveur. Détection des tentatives de connexion échouées Les tentatives de connexion échouées sont des indicateurs clés d’une éventuelle tentative d’intrusion. Elles apparaissent souvent dans les logs sous la forme : Failed password for invalid user ... Pour extraire rapidement ces événements, vous pouvez utiliser : grep "Failed password" /var/log/auth.log ou, pour une vue plus synthétique : awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log | sort | uniq -c | sort -nr Cela vous permet de repérer les adresses IP à l’origine de plusieurs échecs, et de mettre en place des contre-mesures (comme fail2ban ou des règles de pare-feu) pour renforcer la sécurité de votre serveur Linux. La surveillance proactive des logs SSH permet non seulement de détecter les attaques en cours, mais aussi d’identifier les failles potentielles dans la configuration du serveur ou dans les pratiques des utilisateurs. Mettre en place la rotation de fichier log Il vous est possible de définir la durée de conservation de ces logs. Pour ce faire vous devez éditer le fichier /etc/logrotate.conf. Ce qui nous intéresse ici se sont les lignes surlignées en jaune. Voici quelques explications de ces lignes : monthly : La rotation s’effectuera tous les mois. Nous pouvons aussi mettre daily pour tous les jours, weekly pour toutes les semaines. create 0664 root utmp : Les fichiers secondaire créés auront pour créateur root et appartienne au groupe utmp et auront les droits 664. minsize : demande la rotation des log si le fichier fait au minimum la taille définie par cette variable. size : les fichiers ne sont archivés que si leur taille dépasse la valeur définie ici. rotate 1 : Nous garderons 1 fichiers de log missingok : signifie que l’absence du/des fichier(s) log(s) n’est pas anormale. Si cette option n’est pas active alors l’administrateur recevra un mail si le/les log(s) est/sont manquant(s). D’autres paramètres existent comme : compress : Les fichiers logs secondaire c’est à dire tout ce qui n’est pas le fichier de log principal seront compressés. delaycompress : Reporte la compression du journal précédent au prochain cycle de permutation. Ceci n’a un effet qu’utilisé en combinaison avec l’option compress. Elle peut être utilisée quand il n’est pas possible de demander à un programme de fermer son journal et qu’il puisse par conséquent continuer à écrire pour un moment dans le journal précédent. notifempty : permet de ne pas permuter le journal lorsqu’il est vide prerotate, postrotate/endscript : Les lignes entre prerotate et endscript (chacun devant apparaître sur une ligne isolée) seront exécutées avant permutation du journal. Ces directives doivent apparaîtrent dans la définition d’un journal Pour connaître les autres options vous pouvez consulter le man à cette adresse : man logrotate. Afin d’avoir un peu d’historique, j’ai configuré la rotation de cette manière : Dans l’exemple ci-dessus, la rotation s’effectue au bout d’un an à moins que la taille du fichier atteigne les 15 Mo. Par défaut (les cinq premières lignes), la durée de rotation est d’une semaine et la conservation sur 1 mois (rotate 4). Une fois la configuration de votre logrotate terminé, vous pouvez forcer sont exécution de cette manière : #logrotate -f /etc/logrotate.conf ou pour débugger : #logrotate -d /etc/logrotate.conf Si vous souhaitez découvrir d’autres commandes ou astuces pratiques sous Linux, vous pouvez consulter ce tutoriel : Optimiser et dépanner un serveur Linux. FAQ – Analyse des logs de démarrage et de connexion sur un serveur Linux Comment accéder aux logs de démarrage sur un serveur Linux ? Vous pouvez consulter les logs de démarrage Linux en utilisant la commande journalctl -b. Cette commande affiche tous les messages du journal générés depuis le dernier démarrage du système. Pour analyser un démarrage précédent, utilisez journalctl -b. Où trouver les logs de connexion SSH sur Linux ? Les logs de connexion Linux, notamment ceux liés à SSH, sont généralement stockés dans le fichier /var/log/auth.log (sur les distributions Debian/Ubuntu) ou /var/log/secure (sur CentOS/RHEL). Ces logs permettent de suivre les connexions réussies et échouées. Comment détecter les tentatives de connexion échouées ? Vous pouvez utiliser la commande suivante pour repérer les tentatives échouées dans le fichier de log : grep "Failed password" /var/log/auth.log C’est utile pour auditer les connexions SSH et identifier d’éventuelles attaques par force brute. Quels outils permettent d’analyser les logs sous Linux ? En plus de journalctl, vous pouvez utiliser des outils comme : logwatch : pour générer des rapports quotidiens des logs. logrotate : pour gérer l’archivage des logs. Des solutions comme ELK Stack ou Loggly pour une analyse avancée des logs Linux avec visualisation. Pourquoi est-il important de surveiller les logs serveur Linux ? L’analyse régulière des logs permet de : Identifier rapidement des erreurs système ou des problèmes de configuration. Détecter des tentatives d’intrusion ou des connexions suspectes. Maintenir un haut niveau de sécurité sur le serveur Linux. Afficher l’article complet

Vu sur le Shaarli de SebSauvage : Source : https://sebsauvage.net/links/?uzjm5A

Une nouvelle invitation de traduction française de Maxthon Cloud pour Linux vient de me parvenir et je suppose que comme les fois précédentes, vous devriez pouvoir y participer en cliquant sur le lien suivant : https://crowdin.net/project/maxthon-for-linux/invite?d=9525i4j675v6c563m4a393f3 Voici le courriel de Sasha que je viens de recevoir :