Cette espace vous permet de voir toutes les Voir les messages réalisées par ce membre. Vous ne pouvez voir que les Voir les messages réalisées dans les espaces auxquels vous avez accès.
Presque 1 an, en message privé sur le forum, on m'avait sollicité pour aborder le sujet de la configuration de pare-feu sur Linux.
J'avais répondu que le pare-feu le pratiquant depuis pas mal de temps, j'en avais que les bases pour les besoins de la maison : NAS, accès depuis l'extérieur, transfert automatique des donnés vers home. La gestion de pare-feu étant très complexe on ne peut que se cultiver selon les besoin du moment. Mais par-contre les bases, il fallait au moins les connaitre (pas les maitriser) , mais les connaitre pour savoir de quoi on parle et comment configurer un pare-feu le cas échéant.
Ayant un peu de temps, et étant en pleine configuration de pare-feu avec Neftables (j'ai abandonné FirewallD), je partage avec vous ma mise jour de la connaissance d'un pare-feu, avant de partager dans un autre poste ma configuration Neftables.
1. Définition d'un parefeu software & Netfilter Un pare-feu logiciel Linux est un programme qui contrôle le trafic réseau entrant et sortant sur un système d'exploitation Linux, en se basant sur des règles de sécurité prédéfinies. Il s'intègre directement au noyau Linux et utilise le framework Netfilter pour filtrer les paquets. Netfilter est donc le framework de filtrage de paquets intégré au noyau Linux depuis la version 2.4
2. Architecture de base de Netfilter L'architecture de Netfilter comprend plusieurs composants clés :
Hooks (points d'accroche)
Tables
Chaînes
Règles
3. Hooks Netfilter Les hooks sont des points d'interception dans la pile réseau du noyau. Les cinq hooks principaux sont :
NF_IP_PRE_ROUTING : Avant le routage
NF_IP_LOCAL_IN : Pour les paquets entrants destinés au système local
NF_IP_FORWARD : Pour les paquets routés
NF_IP_LOCAL_OUT : Pour les paquets générés localement
NF_IP_POST_ROUTING : Après le routage
4. Tables Les tables regroupent les règles selon leur fonction. Les tables principales sont :
filter : Pour le filtrage de paquets (pare-feu)
nat : Pour la traduction d'adresses réseau
mangle : Pour la modification des paquets
raw : Pour la configuration d'exemptions de suivi de connexion
5. Chaînes Les chaînes sont des séquences de règles attachées aux hooks. Les chaînes standard sont :
PREROUTING (hook PRE_ROUTING)
INPUT (hook LOCAL_IN)
FORWARD (hook FORWARD)
OUTPUT (hook LOCAL_OUT)
POSTROUTING (hook POST_ROUTING)
6. Règles Les règles sont des instructions spécifiques pour le traitement des paquets. Chaque règle comprend :
Des critères de correspondance (adresse IP, port, protocole, etc.)
Une action à effectuer (voir la liste des actions ci-dessous)
7. Actions (Verdicts) de Netfilter
ACCEPT : Accepte le paquet
DROP : Rejette silencieusement le paquet
QUEUE : Envoie le paquet vers l'espace utilisateur
RETURN : Arrête le traitement dans la chaîne actuelle et retourne à la chaîne appelante
REJECT : Rejette le paquet et envoie une réponse
LOG : Journalise les informations sur le paquet
MARK : Marque le paquet
DNAT : Modifie l'adresse de destination du paquet
SNAT : Modifie l'adresse source du paquet
MASQUERADE : Forme spéciale de SNAT pour les interfaces dynamiques
REDIRECT: Redirige le paquet vers un port local
TEE: Copie le paquet vers une autre destination
CONNMARK : Marque la connexion associée au paquet
8. Flux de traitement des paquets
Le paquet arrive à un hook.
Les chaînes associées à ce hook sont parcourues dans l'ordre.
Les règles de chaque chaîne sont évaluées séquentiellement.
La première règle correspondante détermine l'action à effectuer.
Si aucune règle ne correspond, la politique par défaut de la chaîne est appliquée.
9. Connection Tracking Netfilter inclut un système de suivi de connexion qui permet de maintenir l'état des connexions réseau, facilitant le filtrage basé sur l'état.
10. Interaction avec l'espace utilisateur Netfilter fournit des interfaces pour permettre aux outils en espace utilisateur (comme iptables ou nftables) de configurer les règles de filtrage et de NAT.
En Conclusion :
Cette présentation offre une vue d'ensemble complète & détaillée de Netfilter, couvrant ses composants principaux, son fonctionnement hiérarchique et ses capacités au niveau du noyau Linux.
C'est sur cette base que l'on utilise à partir du point : (4):
iptables
neftables
ufw
FirewallD
etc ect .... La base est Netfilter dans le noyau Linux
Comprendre et Gérer le "Out of Memory" (OOM) dans Linux
I. Concept de l'OOM dans Linux
1. Définition de l'OOM Killer • Mécanisme intégré au noyau Linux • Intervient lors d'un manque critique de mémoire (RAM ou swap) • Sélectionne et termine des processus pour libérer de la mémoire
2. Pourquoi l'OOM se produit-il ? • Linux utilise un modèle de surallocation de mémoire • Le noyau peut allouer plus de mémoire que disponible physiquement • Fonctionne bien car les applications n'utilisent pas toujours toute la mémoire demandée • Problème survient quand plusieurs applications utilisent toute leur mémoire allouée
II. Fonctionnement de l'OOM Killer
1. Processus de sélection automatique • Le noyau détecte une situation de mémoire critique • Évalue tous les processus en cours d'exécution • Attribue un score (oom_score) à chaque processus • Termine automatiquement le processus avec le score le plus élevé
2. Calcul du score OOM • Basé principalement sur l'utilisation de la mémoire • Tient compte d'autres facteurs (temps d'exécution, privilèges, etc.)
3. Paramètres dans linux pouvant gérer OOM
vm.overcommit_memory
vm.oom_kill_allocating_task
kernel.shmmax
kernel.shmall
vm.min_free_kbytes
III. Applications et outils pour gérer l'OOM
✅ À privilégier : • earlyoom : Tue les processus avant l'intervention de l'OOM Killer du noyau • systemd-oomd : Gestion OOM plus fine via systemd • cgroups v2 : Gestion granulaire des ressources, incluant la mémoire
⚠️ À tester : • nohang : Alternative à earlyoom avec fonctionnalités supplémentaires • oomd : Démon OOM de Facebook, puissant mais complexe • zram : Compression de la mémoire en RAM, retarde l'OOM
❌ À éviter : • Désactiver complètement l'OOM Killer • Régler vm.overcommit_memory à 2
IV. Pourquoi utiliser des applications tierces pour gérer l'OOM ?
Bien que Linux dispose d'un mécanisme OOM intégré, il existe plusieurs raisons d'utiliser des applications tierces :
1. Surveiller régulièrement l'utilisation de la mémoire 2. Optimiser les applications pour une meilleure gestion de la mémoire 3. Utiliser des outils comme earlyoom pour une intervention précoce 4. Ajuster les scores OOM des processus critiques 5. Considérer l'augmentation de la RAM ou du swap si les OOM sont fréquents
Conclusion Comprendre et gérer efficacement l'OOM est crucial pour maintenir la stabilité et les performances des systèmes Linux. Bien que le noyau Linux offre une gestion de base de l'OOM, l'utilisation d'outils tiers peut apporter une flexibilité et une efficacité supplémentaires, particulièrement dans des environnements complexes ou avec des exigences spécifiques.
Ce scénario réaliste illustre comment j'ai pu éviter le blocage de TW dans une situation d'utilisation intensive (OOM). La combinaison de la RAM physique, zram, du swap traditionnel, et d'earlyoom m'a permis de :
1. Exécuter simultanément des applications gourmandes en mémoire (VM, Kodi en 4K). 2. Maintenir une navigation web fluide avec certains onglets. 3. Effectuer des tâches système lourdes (mises à jour) sans compromettre la stabilité. 4. Éviter les blocages système et les pertes de données potentielles.
Photographie des mémoires activées : • 12 Go de RAM physique • 19 Go de swap total (incluant zram) • zram activé • earlyoom installé et configuré sysctl : * m.swappiness = 10 * vm.vfs_cache_pressure = 50 * vm.dirty_ratio = 10 * vm.dirty_background_ratio = 5
Scénario : J'utilise mon OS openSUSE Tumbleweed pour diverses tâches.
Situation Générale :
• Multimédia • Navigateur web avec 5 - 10 onglets • 2 instances de terminal (monitoring, maj, téléchargement iso..) • Applications récurrente Kvm , OnflyOffice
Total utilisé : environ 6-7 Go de RAM physique
Le Scénario progressif :
1. Phase 1 : Ouverture de mon navigateur • Utilisation de RAM : ~2 Go / 12 Go • Le swap et zram ne sont pas encore sollicités.
2. Phase 2 : Lancement de KVM • La VM Lite Linux est allouée avec 4 Go de RAM. • Utilisation de RAM : ~6 Go / 12 Go • zram commence à être légèrement utilisé pour les pages moins actives.
3. Phase 3 : Youtube adrien linuxtricks et Kodi ouvert film training day en pause • Youtube / Kodi ~2 Go. • Utilisation de RAM : ~8 Go / 12 Go • zram est modérément utilisé, offrant un espace de swap rapide en mémoire.
4. Phase 4 : ouverture 5-7 onglets en plus • La consommation des onglets supplémentaires ~3 Go. • Utilisation de RAM : ~11 Go / 12 Go • zram est fortement sollicité, compressant les pages mémoire moins utilisées.
5. Phase 5 : Terminal MAJ + reprise film training day sur kodi • Les processus de mise à jour consomment ~1 Go supplémentaire. • La RAM physique est presque entièrement utilisée. • Le système commence à utiliser le swap sur disque en plus de zram. • earlyoom détecte que la mémoire disponible approche du seuil critique (5%). • Une notification d'avertissement est envoyée.
6. Phase 6 : Intervention d'earlyoom Je constate que mon navigateur et moins réactif et que Kodi active la mise en cache du film. • La mémoire disponible atteint le seuil critique. • earlyoom identifie les processus les plus gourmands en mémoire. • Il termine certains onglets de mon navigateur, (comme configuré dans les préférences). • Le système libère de la mémoire et redevient réactif, pas de blocage de l'OS
Installation et configuration d'earlyoom sur openSUSE Tumbleweed
Qu'est-ce qu'earlyoom ? earlyoom est un démon léger qui améliore la réactivité du système en surveillant l'utilisation de la mémoire et en intervenant avant que le système ne devienne non réactif. Il termine les processus gourmands en mémoire pour éviter les blocages.
Installation d'earlyoom 1. Ouvrez un terminal. 2. Installez earlyoom avec la commande :
Configuration d'earlyoom cf manpage earlyoom 1. Modifiez le fichier de configuration situé à /etc/sysconfig/earlyoom. 2. Utilisez votre éditeur préféré pour ajuster les paramètres :
- -r 60 : Vérifie la mémoire toutes les 60 secondes. - -m 5,3 -s 5,3 : Envoie un SIGTERM à 5% de mémoire/swap libre et un SIGKILL à 3%. - -n : Active les notifications.
Surveillance d'earlyoom via terminal 1. Après modification, rechargez systemd et redémarrez earlyoom :
gsettings set com.github.unrud.VideoDownloader automatic-subtitles "[]"
Utilisation en Images :
Voilà une alternative à 4k videodownloader qui n'existe pas en RPM.[/list]
1 Si vous utilisez KDE et que vous souhaitez éviter que ce dépôt prenne le dessus lors des mises à jour, il est conseillé de lui attribuer une priorité plus basse (par exemple 120). ↵
OpenSUSE a annoncer le : 26. Octobre 2024 par Douglas DeMaione
Une mise à jour majeure de l'identité visuelle de ses distributions.
Leap et Tumbleweed. Voici les points clés :
Nouveau logo Tumbleweed
Passage d'un format horizontal à un design vertical, s'alignant sur les autres logos de la famille openSUSE.
Fonds d'écran Leap 16.0
Nouveaux thèmes jour/nuit avec des paysages naturels et des caméléons stylisés. Le design intègre subtilement le logo Leap dans les nuages et une constellation.
Processus collaboratif
Les designs ont été élaborés avec la participation active de la communauté, notamment lors d'une session de groupe à la conférence openSUSE 2024.
Concours photo
Un concours a été est ouvert jusqu'au 1er novembre, invitant les utilisateurs à soumettre des photos haute résolution de caméléons ou d'objets y ressemblant.
Évolution globale
Cette refonte s'inscrit dans une démarche plus large de modernisation de l'image de marque d'openSUSE, touchant également d'autres saveurs comme :
* Slowroll, Kalpa et Aeon.
Cette mise à jour visuelle reflète l'engagement continu de SUSE envers l'identité unique de chacune de ses distributions.
Soyez prudent lorsque vous accédez au contenu créé par des utilisateurs, ici. En effet, il peut contenir du code exécutable n'ayant pas été testé par KDE ou par votre distributeur concernant la sécurité, la stabilité ou la qualité.
Je conclus que quelque soit le message (mise à part "serveur indisponible"), KDE nous indique qu'il n'est pas responsable d'un dysfonctionnement lié à des thèmes extérieurs au siens... (certificats,bugs du thème.....)
Il faut contacter le mainteneur du thème en question..
Maintenant, avec le 8.8.8.8 tu es sur le DNS de Google. Si c'est ton choix, pourquoi pas. Si tu ne la savais pas et que tu préfères des communications plus confidentielles, tu peux essayer les DNS de Cloudflare ou mieux, ceux de Quad9.
Ou avoir ton propre résolveur DNS, regarde mon wiki sur opensuse : Unbound Opensuse
Et dans ce contexte la question est la suivante : existe t-il un instant t ou bien un nombre n minimal de candidats à passer en revue (selon qu'il existe une contrainte de temps ou de volume de candidats), à partir desquels le recruteur optimise ses chances de choisir le meilleur candidat?
Tu as énuméré certains critères de choix pour une décision qui dépend d'un contexte donné. Et là dessus je te rejoins. Est-ce qu'une règle mathématique peut éclairer nos choix d'un OS ? C'est une vraie question ... En faite sur quoi était basé notre choix d'un OS ? pas d'une règle mathématique c'est sûr. Nos choix ne sont pas binaire (1 ou 0) quoi que des fois ?
Bon c'était un débat gamberge, sorti des sentiers battus , je l'avoue...
tes critères sont biaisés puisque tu sais déjà ce qu'est un gestionnaire de paquets et un environnement de bureau, ce qui n'est pas le cas de la majorité des utilisateurs de PC qui utilisent du "clés en main" (Apple ou Microsoft).
Mes critères sont les miens et pas de tous. Chacun ses critères et évalueront si c'est pertinent ou pas , cette adaptation de règle des 37% à l'informatique.
Et bien si c'est pas pertinent, on aura des preuves pratiques que cela ne l'est pas, au même titre de tes arguments.
On a bien compris que ce n'est pas adaptable pour toi concernant le domaine OS informatique.
C'est une règle effectivement issue du monde informatique applicable dans tous les domaines. Effectivement curieuse, mais qui est censée aider les indécis. (Tout le monde n'est pas indécis).
Pourquoi ne pas la tester comme toutes autres règles pour évaluer sa pertinence ?
Après, ça reste un concept valable ou pas.
Ça m'a amusé de faire le point sur mes options de choix d'un OS :
Facilité d'installation Support matériel Gestion des paquets (difficile ou pas) Environnement bureau , ergonomie Logiciels disponibles et dernière version Personnalisation Aide, wiki, Communauté Sécurité, confidentialité
Cette règle peut théoriquement être appliquée dans le domaine informatique pour choisir parmi différentes distributions Linux.
Par exemple, si vous évaluez plusieurs distributions Linux pour vous aiderz à choisir votre distribution idéale.
Vous pourriez passer en revue 37% de vos options idéales, sans prendre de décision.
Ça c'est possible, il suffit de glaner le net et sélectionner les distributions qui pourraient vous convenir, selon vos options.
Entre nous, c'est largement faisable, et je l'ai fait en 15-25mn
Ensuite, vous allez examiner la première distribution qui vous semble meilleure sans réfléchir, et comparer aux 37% autres distributions que vous avez sélectionnées
Oui il va falloir éliminer sans réfléchir aux distributions qui ne répondent pas à vos options.
C'est là la prise de décision.
Cette méthode va vous aidez à éviter l'indécision et à prendre une décision optimale basée sur une évaluation initiale.
En Finale sur x distributions retenues, vous allez devoir examiner : x distributions / 37
qui répondent a vos critères d'options
Bizarrement pour moi sur les 12 restants.
C'est archlinux qui répondrait à mes options. Ensuite Debian et Fedora ( mode rolling relesease)
Ah oui j'ai oublié, il faut choisir au moins 10 options de votre distribution idéal doit répondre.
