[{"content":"L\u0026rsquo;objectif est simple : pouvoir depuis mon laptop KDE joindre les machines du LAN derrière un OPNsense via WireGuard, sans pour autant envoyer tout mon trafic internet dans le tunnel. Autrement dit, un split tunnel propre : seul le réseau derrière le pare-feu passe par le VPN, le reste reste sur ma connexion classique.\nDepuis OPNsense 24.1, WireGuard est intégré au core. Plus besoin de jouer avec le plugin os-wireguard, c\u0026rsquo;est déjà ça de gagné. La procédure reste assez directe, mais quelques points de routage sont à surveiller pour ne pas finir avec tout le trafic déporté sur le VPN.\nVoici le plan utilisé dans cet article :\nLAN derrière OPNsense : 192.168.1.0/24 Réseau du tunnel : 10.10.10.0/24 OPNsense (interface WireGuard, IP au sein du tunnel VPN) : 10.10.10.1/24 Client KDE (IP au sein du tunnel VPN) : 10.10.10.2/32 Port UDP : 51820 Note : cet article traite uniquement l\u0026rsquo;IPv4. L\u0026rsquo;IPv6 n\u0026rsquo;est pas abordé ici.\nLet\u0026rsquo;s go !!!\nPrérequis OPNsense accessible depuis Internet : IP publique sur son interface WAN, ou redirection du port UDP 51820 depuis le routeur amont. Le client KDE dispose de wireguard-tools et d\u0026rsquo;un NetworkManager gérant nativement WireGuard (à partir de la v1.16, ça marche out of the box sur la plupart des distros récentes). Partie 1 : OPNsense, le serveur WireGuard Création de l\u0026rsquo;instance On commence par générer le serveur :\nAller dans VPN \u0026gt; WireGuard \u0026gt; Instances. Cliquer sur +. Remplir comme suit : Enabled : Coché Name : HomeWireGuard Public Key : Générer via la roue crantée Private Key : Générer en même temps Listen Port : 51820 MTU : 1420 (1412 si PPPoE) Tunnel Address : 10.10.10.1/24 Peers : Laisser vide pour l\u0026#39;instant Disable Routes : Décoché Le MTU de 1420 tient compte de l\u0026rsquo;overhead d\u0026rsquo;encapsulation WireGuard (en-têtes IP/UDP/WireGuard, soit environ 60 à 80 octets). Ainsi, le paquet final reste sous les 1500 octets d\u0026rsquo;un lien Ethernet standard. En PPPoE, le MTU physique est souvent 1492, d\u0026rsquo;où la valeur 1412.\nNote : si on active le mode avancé, laissez le champ DNS Server vide. Sinon WireGuard écrase la config DNS d\u0026rsquo;OPNsense et c\u0026rsquo;est la galère.\nSauvegarder, rouvrir l\u0026rsquo;instance et copier la clé publique générée. Elle servira à configurer le client KDE.\nCréation du peer client Il faut maintenant déclarer le client. Pour ça, il faut sa clé publique. On peut la générer directement sur le client KDE (voir partie 2) et la copier ici, ou utiliser le Peer Generator intégré à OPNsense. Moi je préfère générer les clés sur le client pour ne pas stocker la privée ailleurs.\nAller dans VPN \u0026gt; WireGuard \u0026gt; Peers. Cliquer sur +. Enabled : Coché Name : MonPC_KDE Public Key : \u0026lt;clé publique du client KDE\u0026gt; Allowed IPs : 10.10.10.2/32 Keepalive : 25 Le Keepalive à 25 secondes, c\u0026rsquo;est utile quand le client est derrière un NAT ou un pare-feu qui ferme les states trop vite.\nSauvegarder, puis retourner dans VPN \u0026gt; WireGuard \u0026gt; Instances, éditer HomeWireGuard et sélectionner le peer MonPC_KDE. Apply.\nMéthode alternative : le Peer Generator Si vous devez créer plusieurs clients, ou si vous voulez générer directement le fichier de config sans taper de clés à la main, OPNsense intègre un Peer Generator sous VPN \u0026gt; WireGuard \u0026gt; Peer generator.\nSélectionner l\u0026rsquo;instance HomeWireGuard. Remplir les champs : Name : MonPC_KDE Endpoint Address: \u0026lt;ip_publique_ou_domaine_opnsense\u0026gt; Endpoint Port : 51820 Allowed IPs : 10.10.10.2/32 DNS : laisser vide, ou 10.10.10.1 si vous voulez utiliser le DNS d\u0026#39;OPNsense Cliquer sur Generate. Le générateur crée : la paire de clés du client le peer côté OPNsense (seule la clé publique est stockée) une config prête à copier/coller ou à scanner en QR code Attention : la config générée met souvent AllowedIPs = 0.0.0.0/0, ::/0 côté client. Si vous voulez du split tunnel, il faut remplacer cette ligne par AllowedIPs = 10.10.10.0/24, 192.168.1.0/24 dans le fichier récupéré avant de l\u0026rsquo;importer dans NetworkManager. Sinon tout le trafic partira dans le tunnel.\nCliquer sur Store and generate next pour valider le peer dans OPNsense, puis Apply dans VPN \u0026gt; WireGuard \u0026gt; Peers. La clé privée n\u0026rsquo;est pas conservée sur le firewall : copiez-la dans /etc/wireguard/wg0.conf sur le client, ou scannez le QR code depuis un téléphone. C\u0026rsquo;est nettement plus rapide quand il y a plusieurs road warriors à déployer.\nActivation de WireGuard VPN \u0026gt; WireGuard \u0026gt; General. Cocher Enable, puis Apply. Si besoin, redémarrer WireGuard en le décochant/re-cochant. Assigner une interface (recommandé) Ce n\u0026rsquo;est pas strictement obligatoire pour un split tunnel, mais ça simplifie les règles firewall et ça crée l\u0026rsquo;alias HomeWireGuard net.\nInterfaces \u0026gt; Assignments. Sélectionner le device wg1 (ou wg0 selon l\u0026rsquo;installation) et l\u0026rsquo;ajouter. Description : HomeWireGuard. Éditer l\u0026rsquo;interface : Enable : Coché Description : HomeWireGuard IPv4 Configuration Type : None IPv6 Configuration Type : None Save puis Apply changes. Redémarrer WireGuard si l\u0026rsquo;interface ne remonte pas proprement.\nRègles firewall 1. Autoriser les connexions entrantes sur le WAN Firewall \u0026gt; Rules \u0026gt; WAN. Ajouter une règle : Action : Pass Quick : Coché Interface : WAN Direction : in Protocol : UDP Source : any Destination : WAN address Destination port: 51820 2. Autoriser le trafic depuis le tunnel vers le LAN Firewall \u0026gt; Rules \u0026gt; HomeWireGuard (ou WireGuard si vous n\u0026rsquo;avez pas assigné d\u0026rsquo;interface). Ajouter une règle : Action : Pass Quick : Coché Interface : HomeWireGuard Protocol : any Source : HomeWireGuard net Destination : LAN net C\u0026rsquo;est cette règle qui autorise le client KDE à joindre les machines du LAN.\nNormalisation MSS (optionnel mais fortement recommandé) Le MSS (Maximum Segment Size) est la taille maximale de la charge utile d\u0026rsquo;un segment TCP. Comme WireGuard encapsule les paquets (en-têtes UDP/IP/WireGuard), le MTU utile du tunnel est réduit. Les hôtes du LAN peuvent négocier un MSS basé sur l\u0026rsquo;interface locale (1500 octets), ce qui donnerait des paquets trop gros une fois encapsulés. Le MSS clamping force la valeur négociée à MTU_tunnel - 40 pour IPv4, soit 1380 avec un MTU de 1420. L\u0026rsquo;IPv6 n\u0026rsquo;est pas traité ici.\nFirewall \u0026gt; Settings \u0026gt; Normalization. Ajouter une règle sur l\u0026rsquo;interface WireGuard (Group) : Direction : Any Protocol : any Source : any Destination : any Description : WireGuard MSS Clamping IPv4 Max mss : 1380 NAT outbound Pour un split tunnel pur, pas besoin de NAT outbound. OPNsense sait router le trafic entre HomeWireGuard et LAN car les deux réseaux lui sont directement attachés. Si jamais OPNsense n\u0026rsquo;est pas la passerelle par défaut du LAN, alors il faudra activer le NAT outbound ou ajouter une route statique sur le routeur intermédiaire.\nPartie 2 : KDE, le client WireGuard Génération des clés Sur le poste KDE :\nwg genkey | tee private.key | wg pubkey \u0026gt; public.key public.key : à copier dans le peer OPNsense (étape \u0026ldquo;Création du peer client\u0026rdquo;). private.key : reste sur le client, ne jamais la balancer sur un chat. Fichier de configuration wg0.conf Créer /etc/wireguard/wg0.conf :\n[Interface] PrivateKey = \u0026lt;contenu de private.key\u0026gt; Address = 10.10.10.2/32 # DNS optionnel, par exemple si vous voulez utiliser le DNS d\u0026#39;OPNsense # DNS = 10.10.10.1 [Peer] PublicKey = \u0026lt;clé publique d\u0026#39;OPNsense\u0026gt; AllowedIPs = 10.10.10.0/24, 192.168.1.0/24 Endpoint = \u0026lt;ip_publique_ou_domaine_opnsense\u0026gt;:51820 PersistentKeepalive = 25 Le point crucial du split tunnel : AllowedIPs ne contient pas 0.0.0.0/0. Seuls les réseaux à atteindre derrière OPNsense (192.168.1.0/24) et le tunnel (10.10.10.0/24) y figurent. Ainsi, seul ce trafic est routé vers wg0 ; le reste (internet) reste sur l\u0026rsquo;interface classique.\nImport dans NetworkManager En ligne de commande (plus fiable) sudo nmcli connection import type wireguard file /etc/wireguard/wg0.conf Puis on s\u0026rsquo;assure que NetworkManager ne met pas cette connexion en passerelle par défaut :\nsudo nmcli connection modify wg0 ipv4.never-default yes En graphique (KDE Plasma) Ouvrir Paramètres système \u0026gt; Connexions. Ajouter une connexion \u0026gt; WireGuard. Onglet WireGuard : Private key : coller la clé privée. Peers : ajouter le peer avec la clé publique d\u0026rsquo;OPNsense, l\u0026rsquo;endpoint, et Allowed IPs = 10.10.10.0/24, 192.168.1.0/24. Onglet IPv4 : Méthode : Manuel. Adresse : 10.10.10.2/32. Laisser la passerelle vide. Cocher Utiliser cette connexion uniquement pour les ressources de ce réseau. Sauvegarder et activer. Si l\u0026rsquo;option WireGuard n\u0026rsquo;apparaît pas dans l\u0026rsquo;interface graphique, vérifier que wireguard-tools est bien installé et que NetworkManager est assez récent.\nVérifications Sur le client KDE, une fois connecté :\nip route show On doit voir quelque chose comme :\ndefault via 192.168.0.1 dev eth0 proto dhcp metric 100 10.10.10.0/24 dev wg0 proto static scope link 192.168.1.0/24 dev wg0 proto static scope link L\u0026rsquo;important : la route default pointe toujours vers l\u0026rsquo;interface locale. Les routes 10.10.10.0/24 et 192.168.1.0/24 pointent vers wg0.\nTests basiques :\nping 10.10.10.1 ping 192.168.1.x Vérifier que l\u0026rsquo;IP publique vue depuis le navigateur n\u0026rsquo;a pas changé (le trafic internet ne passe pas par le VPN) :\ncurl -4 ifconfig.me Côté OPNsense, on peut surveiller l\u0026rsquo;état dans VPN \u0026gt; WireGuard \u0026gt; Status. On doit voir le peer MonPC_KDE avec un handshake récent et du trafic RX/TX.\nConclusion OPNsense : instance HomeWireGuard (10.10.10.1/24), peer MonPC_KDE (10.10.10.2/32), firewall WAN UDP 51820 + règle HomeWireGuard net → LAN net. Client KDE : AllowedIPs = 10.10.10.0/24, 192.168.1.0/24, ipv4.never-default yes. Résultat : les machines du LAN derrière OPNsense sont accessibles, mais internet continue de sortir par la connexion locale. Pas de fuites, pas de ralentissements inutiles. Et si un jour vous voulez forcer tout le trafic par le VPN, il suffit de remplacer AllowedIPs par 0.0.0.0/0 côté client et d\u0026rsquo;ajouter le NAT outbound sur OPNsense. Mais ce n\u0026rsquo;est pas le sujet d\u0026rsquo;aujourd\u0026rsquo;hui.\n","date":"2026-07-22T00:00:00Z","image":"/opnsense-serveur-wireguard-et-client-kde-en-split-tunnel/cover.png","permalink":"/opnsense-serveur-wireguard-et-client-kde-en-split-tunnel/","title":"OPNsense : Serveur WireGuard et client KDE en split tunnel"},{"content":"Sous KDE, double-cliquer sur un .iso ouvre Ark. C\u0026rsquo;est le comportement par défaut, et c\u0026rsquo;est chiant quand on veut juste monter l\u0026rsquo;image pour parcourir son contenu.\nLe problème vient de l\u0026rsquo;association MIME. On peut le confirmer :\nxdg-mime query default application/x-iso9660-image Ça retourne org.kde.ark.desktop. Ark est déclaré handler par défaut au niveau système pour ce type MIME, et KDE suit ça à la lettre.\nLa solution L\u0026rsquo;idée, c\u0026rsquo;est de créer un .desktop qui monte l\u0026rsquo;ISO via udisksctl et ouvre Dolphin sur le point de montage, puis de l\u0026rsquo;enregistrer comme handler MIME. Avec NoDisplay=true, il ne remonte pas dans le menu des applications, il n\u0026rsquo;existe que pour ça.\nCréer : ~/.local/share/applications/iso-mount.desktop [Desktop Entry] Type=Application Name=Monter l\u0026#39;image ISO Exec=bash -c \u0026#39;DEV=$(udisksctl loop-setup -f \u0026#34;%f\u0026#34; | grep -oP \u0026#34;/dev/loop\\d+\u0026#34;); sleep 0.5; udisksctl mount -b \u0026#34;$DEV\u0026#34;; dolphin /run/media/$USER/\u0026#39; Icon=media-optical MimeType=application/x-iso9660-image;application/x-cd-image; NoDisplay=true Terminal=false Ensuite on enregistre l\u0026rsquo;association : update-desktop-database ~/.local/share/applications/ xdg-mime default iso-mount.desktop application/x-iso9660-image xdg-mime default iso-mount.desktop application/x-cd-image Sous KDE 6, xdg-mime peut cracher un qtpaths: commande introuvable. C\u0026rsquo;est un bug connu, ça n\u0026rsquo;empêche pas l\u0026rsquo;association d\u0026rsquo;être écrite correctement dans ~/.config/mimeapps.list.\nOn vérifie : grep -i iso ~/.config/mimeapps.list application/x-iso9660-image=iso-mount.desktop application/x-cd-image=iso-mount.desktop À partir de là, un double-clic sur un .iso dans Dolphin monte l\u0026rsquo;image et ouvre le répertoire directement. Pour démonter, clic droit sur le périphérique dans le panneau latéral → Démonter.\n","date":"2026-06-23T00:00:00Z","image":"/kde-double-clic-sur-un-iso-pour-le-monter/cover.png","permalink":"/kde-double-clic-sur-un-iso-pour-le-monter/","title":"KDE : double-clic sur un ISO pour le monter"},{"content":"Quand on gère une flotte de serveurs Debian, on finit toujours par se poser la même question : comment maîtriser ce que mes machines vont installer ? Comment être sûr qu'un apt update ne va pas me ramener une version de paquet qui casse tout ? Et surtout, comment faire pour que mes serveurs de prod ne dépendent pas d'un miroir externe qui peut tomber au pire moment ?\nLa réponse classique, c'est de monter un miroir local. Sauf que mirrorer Debian avec les outils standards (debmirror, apt-mirror...), c'est lourd, c'est rigide, et ça ne répond qu'à la moitié du problème. On a une copie locale, d'accord, mais on n'a toujours aucun contrôle sur ce qui change d'un jour à l'autre.\nC'est là qu'aptly entre en jeu.\nCe qu\u0026rsquo;aptly fait vraiment aptly, c'est un gestionnaire de dépôts Debian écrit en Go. Il sait faire trois choses fondamentales :\nmirrorer un dépôt distant -- comme apt-mirror, mais en mieux Figer l'état d'un miroir dans un snapshot immuable -- ça, c'est la vraie valeur ajoutée Publier ce snapshot pour que vos machines puissent l'utiliser Le workflow de base, c'est ça :\nmirror create → mirror update → snapshot create → publish snapshot Et quand il faut mettre à jour :\nmirror update → snapshot create → publish switch Le publish switch bascule la publication d'un snapshot à un autre. Vos machines continuent de pointer sur la même URL, mais le contenu change de manière contrôlée. Si ça foire, vous rebasculez sur l'ancien snapshot. Pas de panique, pas de retélécharger quoi que ce soit.\nInstallation Via les paquets Debian C'est la méthode standard, celle qu'on va utiliser ici :\nsudo apt update sudo apt install aptly Sur Debian Trixie, ça installe la version 1.5.0. C'est pas la toute dernière (la 1.6.2 existe), mais c'est largement suffisant pour ce qu'on va faire.\nVérification :\n$ aptly version aptly version: 1.5.0 L\u0026rsquo;upstream (optionnel) Si vous voulez absolument la dernière version upstream, vous pouvez ajouter le dépôt officiel d'aptly. Mais franchement, pour un usage classique, la version Debian fait le job. Je mentionne juste l'option pour ceux qui en ont besoin :\nsudo mkdir -p /etc/apt/keyrings wget -O /etc/apt/keyrings/aptly.asc https://www.aptly.info/pubkey.txt echo \u0026#34;deb [signed-by=/etc/apt/keyrings/aptly.asc] http://repo.aptly.info/release trixie main\u0026#34; \\ | sudo tee /etc/apt/sources.list.d/aptly.list sudo apt update sudo apt install aptly Mais encore une fois, c'est optionnel. On va continuer avec la version des dépôts Debian.\nConfiguration de base aptly stocke tout dans ~/.aptly par défaut. En prod, on va plutôt utiliser /var/aptly. On crée le répertoire et on configure aptly pour l'utiliser :\nsudo mkdir -p /var/aptly sudo chown $USER:$USER /var/aptly Le fichier de config, c'est ~/.aptly.conf (ou /etc/aptly.conf pour une config globale). On va en créer un minimal :\ncat \u0026gt; ~/.aptly.conf \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; { \u0026#34;rootDir\u0026#34;: \u0026#34;/var/aptly\u0026#34;, \u0026#34;architectures\u0026#34;: [\u0026#34;amd64\u0026#34;] } EOF On restreint à amd64 parce que c'est ce qu'on utilise. Pas la peine de télécharger du i386, du arm64 ou du armhf si on n'en a pas besoin.\nLe rootDir, c'est la racine de tout. Dedans, aptly va créer :\ndb/ -- sa base de données interne pool/ -- les fichiers .deb téléchargés public/ -- les dépôts publiés, ceux qu'on va exposer Importer les clés GPG Avant de créer un miroir, aptly a besoin des clés GPG pour vérifier les signatures des dépôts distants. Sur Debian, les clés d'archive sont déjà présentes dans /usr/share/keyrings/. Il suffit de les importer dans le trousseau d'aptly :\ngpg --no-default-keyring \\ --keyring /usr/share/keyrings/debian-archive-keyring.gpg \\ --export | \\ gpg --no-default-keyring \\ --keyring trustedkeys.gpg \\ --import Ça importe les clés dans ~/.gnupg/trustedkeys.gpg, le trousseau qu'aptly utilise par défaut.\nCréer un miroir de Debian Trixie On va mirrorer le dépôt officiel français (ftp.fr.debian.org), avec les sections main et non-free-firmware. Pourquoi non-free-firmware ? Parce que depuis Debian 12, les firmwares non-libres (wifi, GPU...) sont dans cette section, et on en a souvent besoin.\naptly mirror create \\ -architectures=amd64 \\ debian-trixie \\ http://ftp.fr.debian.org/debian/ \\ trixie main non-free-firmware Quelques remarques :\nLe flag -architectures=amd64 se place avant la sous-commande mirror. C'est un flag global. Si vous le mettez après, aptly va râler. Le nom du miroir (debian-trixie), c'est vous qui le choisissez. Prenez un nom explicite. L'URL doit finir par un /. On spécifie la distribution (trixie) et les composants (main non-free-firmware). La commande crée la définition du miroir, mais ne télécharge rien encore. Pour ça, il faut lancer un mirror update.\nRemplir le miroir aptly mirror update debian-trixie Là, ça télécharge. Et ça prend du temps. Un miroir complet de Debian main + non-free-firmware en amd64, c'est plusieurs dizaines de Go. Prévoyez du café.\nVous pouvez suivre la progression dans le terminal. aptly affiche les paquets au fur et à mesure qu'il les télécharge.\nUne fois terminé, vous pouvez voir ce que contient le miroir :\naptly mirror show debian-trixie Ça vous donne le nombre de paquets, la taille totale, la date de dernière mise à jour, etc.\nCréer un snapshot Le miroir est à jour. Maintenant, on va en faire un snapshot. Un snapshot, c'est une copie figée et immuable de l'état du miroir à un instant T. Une fois créé, il ne bouge plus, quoi qu'il arrive au miroir source.\naptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie J'utilise la date dans le nom du snapshot. C'est une bonne pratique : ça permet de savoir immédiatement à quoi correspond chaque snapshot.\nVous pouvez lister vos snapshots :\naptly snapshot list Et voir le détail d'un snapshot :\naptly snapshot show trixie-20260313 Publier le snapshot Un snapshot qui n'est pas publié, ça ne sert à rien. La publication génère l'arborescence standard Debian (dists/, pool/, fichiers Release signés...) dans /var/aptly/public/.\naptly publish snapshot -distribution=trixie trixie-20260313 Le flag -distribution=trixie indique quelle distribution utiliser dans les métadonnées du dépôt publié. C'est ce que vos machines verront dans leur sources.list.\naptly va vous demander la passphrase de votre clé GPG pour signer le fichier Release. Si vous n'avez pas encore de clé GPG, créez-en une :\ngpg --full-generate-key Choisissez RSA 4096 bits, et renseignez un nom et un email.\nUne fois la publication terminée, vous avez un dépôt Debian complet dans /var/aptly/public/. Il ne reste plus qu'à l'exposer via un serveur web.\nL\u0026rsquo;impact des hard links Un détail important : quand aptly publie un snapshot, il ne copie pas les fichiers .deb. Il crée des hard links depuis le pool vers le répertoire public/.\nÇa veut dire quoi concrètement ?\nPas de duplication -- un paquet présent dans plusieurs snapshots n'occupe qu'une seule fois la place sur le disque Publication instantanée -- créer un hard link, c'est quasi gratuit en temps et en espace Plusieurs snapshots publiés en même temps -- vous pouvez avoir trixie-20260313 et trixie-20260310 publiés simultanément, ils partagent les fichiers communs C'est pour ça que le publish switch est si rapide. aptly ne déplace rien, il change juste les liens.\nPar contre, attention : si vous supprimez un snapshot publié avec snapshot drop, aptly refuse tant que la publication existe. Il faut d'abord dépublier (publish drop) ou basculer vers un autre snapshot (publish switch).\nMettre à jour le miroir et basculer Quelques jours passent. Le miroir Debian a évolué. Vous voulez mettre à jour votre dépôt local. Voilà le workflow complet :\n# 1. Mettre à jour le miroir aptly mirror update debian-trixie # 2. Créer un nouveau snapshot aptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie # 3. Basculer la publication vers le nouveau snapshot aptly publish switch trixie trixie-20260315 Le publish switch fait tout le boulot :\nIl met à jour les métadonnées (Release, Packages, Contents...) Il ajuste les hard links dans public/ Il signe le nouveau Release avec GPG Il nettoie les anciens liens qui ne servent plus Vos machines qui pointent sur ce dépôt voient le changement au prochain apt update. Pas de coupure, pas de temps d'arrêt.\nSi le nouveau snapshot pose problème, vous rebasculez sur l'ancien :\naptly publish switch trixie trixie-20260313 C'est aussi rapide dans un sens que dans l'autre.\nLes dépôts locaux (mention rapide) aptly sait aussi gérer des dépôts locaux, où vous poussez vos propres paquets .deb. Le workflow est similaire :\n# Créer un dépôt local aptly repo create mon-depot # Ajouter des paquets aptly repo add mon-depot /chemin/vers/*.deb # Snapshot aptly snapshot create mon-depot-v1 from repo mon-depot # Publier aptly publish snapshot mon-depot-v1 Je ne développe pas plus ici, parce que le cas d'usage principal d'aptly, c'est quand même le mirroring. Mais sachez que c'est possible.\nExposer le dépôt Le serveur embarqué (test uniquement) aptly a un petit serveur HTTP intégré. C'est pratique pour tester, mais la doc officielle est claire : not suitable for real production usage.\naptly serve -listen=:8080 Vous pouvez alors ajouter le dépôt sur une machine de test :\necho \u0026#34;deb http://votre-serveur:8080/ trixie main non-free-firmware\u0026#34; \\ | sudo tee /etc/apt/sources.list.d/aptly-test.list nginx (production) En prod, on utilise nginx. Je ne vais pas détailler ici parce que ça fera l'objet d'un second article si besoin, mais l'idée générale :\nserver { listen 80; server_name repo.example.com; root /var/aptly/public; location / { autoindex on; } } Vous activez le vhost, vous rechargez nginx, et c'est bon. Pour HTTPS, ajoutez Let's Encrypt avec certbot.\nCôté client, vous ajoutez le dépôt :\necho \u0026#34;deb http://repo.example.com/ trixie main non-free-firmware\u0026#34; \\ | sudo tee /etc/apt/sources.list.d/mon-miroir.list sudo apt update Si le dépôt est signé (et il devrait l'être), distribuez votre clé GPG publique aux clients :\ngpg --armor --export VOTRE_KEY_ID \u0026gt; /var/aptly/public/repo-key.asc Sur les clients :\nwget -O /etc/apt/keyrings/mon-repo.asc http://repo.example.com/repo-key.asc echo \u0026#34;deb [signed-by=/etc/apt/keyrings/mon-repo.asc] http://repo.example.com/ trixie main non-free-firmware\u0026#34; \\ | sudo tee /etc/apt/sources.list.d/mon-miroir.list Automatiser avec cron Un miroir, ça se met à jour régulièrement. Voici un script cron qui fait le job :\n#!/bin/bash # /etc/cron.daily/aptly-update set -euo pipefail MIRROR=\u0026#34;debian-trixie\u0026#34; DATE=$(date +%Y%m%d) # Mise à jour du miroir aptly mirror update \u0026#34;$MIRROR\u0026#34; # Nouveau snapshot aptly snapshot create \u0026#34;trixie-${DATE}\u0026#34; from mirror \u0026#34;$MIRROR\u0026#34; # Basculer la publication aptly publish switch -batch -gpg-key=\u0026#34;VOTRE_KEY_ID\u0026#34; trixie \u0026#34;trixie-${DATE}\u0026#34; # Nettoyer les vieux snapshots (garder les 7 derniers) aptly snapshot list -raw | grep \u0026#34;^trixie-\u0026#34; | sort | head -n -7 | while read snap; do aptly snapshot drop \u0026#34;$snap\u0026#34; 2\u0026gt;/dev/null || true done # Nettoyer la base aptly db cleanup Le flag -batch est crucial : il permet à GPG de fonctionner sans terminal interactif. Sans ça, le script va bloquer en attendant que vous tapiez la passphrase.\nPour éviter ça, vous pouvez aussi utiliser gpg-agent avec un cache de passphrase, ou stocker la passphrase dans un fichier sécurisé et utiliser -passphrase-file.\nNettoyage et maintenance aptly conserve tous les paquets téléchargés dans son pool, même ceux qui ne sont plus référencés par aucun snapshot. Pour faire le ménage :\naptly db cleanup Ça supprime les paquets orphelins. Si vous voulez voir ce qui va être supprimé avant de le faire :\naptly db cleanup -verbose -dry-run Pour sauvegarder votre installation aptly, c'est simple : sauvegardez /var/aptly en entier. Tout est dedans.\ntar -czf aptly-backup-$(date +%Y%m%d).tar.gz /var/aptly Quelques astuces Filtrer les paquets lors du mirroring. Si vous ne voulez mirrorer que certains paquets (par exemple, uniquement nginx et ses dépendances), vous pouvez utiliser des filtres :\naptly mirror create -filter=\u0026#39;nginx\u0026#39; -filter-with-deps \\ nginx-only \\ http://ftp.fr.debian.org/debian/ \\ trixie main Le flag -filter-with-deps est important : sans lui, vous récupérez nginx mais pas ses dépendances, et ça ne servira à rien.\nComparer deux snapshots. Pour voir ce qui a changé entre deux snapshots :\naptly snapshot diff trixie-20260313 trixie-20260315 Fusionner des snapshots. Vous pouvez combiner plusieurs snapshots en un seul. Utile si vous avez un miroir Debian et un dépôt local, et que vous voulez les publier ensemble :\naptly snapshot merge trixie-complet trixie-20260315 mon-depot-v1 Conclusion aptly résout un vrai problème : comment garder le contrôle sur ce que vos machines Debian vont installer. Les miroirs classiques vous donnent une copie locale, d'accord, mais ils ne vous donnent pas la maîtrise des changements. Avec aptly et ses snapshots, vous décidez quand et comment vos serveurs voient les mises à jour.\nLe workflow mirror create → mirror update → snapshot create → publish snapshot → publish switch devient vite un réflexe. Et le jour où une mise à jour casse quelque chose, vous serez bien content de pouvoir rebascule sur le snapshot d'hier en une commande.\nLes hard links font que tout ça reste léger en espace disque et rapide en exécution. Vous pouvez avoir plusieurs snapshots publiés en parallèle, pour des environnements de test et de prod différents, sans exploser votre stockage.\nBref, si vous gérez des serveurs Debian sérieusement, aptly mérite sa place dans votre boîte à outils.\n","date":"2026-03-13T19:05:06+01:00","image":"/aptly-mirroiter-debian-proprement/cover.jpg","permalink":"/aptly-mirroiter-debian-proprement/","title":"Aptly : mirroiter Debian proprement"},{"content":"Préambule J'ai mis en ligne une interface web awa.noobops.fr pour le délicieux système d'encodage awaSCII+ v5.0.666 de Penthium2 BZHack. Parce que parfois, on a besoin de dire \u0026quot;Hello World!\u0026quot; avec classe.\nawa awa awa awawa awa awa awa , awa awa awa awawawawawa, awa awa awawa awa awa awa awa , awa awa awawa awa awa awa awa , awa awa awawa awa awawawa, awa awawawa awawa awa awa , awa awa awa awa awa awa awawa, awa awa awawa awa awawawa, awa awawa awawa awa awawa, awa awa awawa awa awa awa awa , awa awawa awa awawawa awa , awa awawawa awawawawa Le projet qui fait \u0026quot;awa\u0026quot; Pour ceux qui connaissent pas encore cette merveille, awaSCII+ c'est un système d'encodage qui transforme n'importe quel texte en variations de \u0026quot;awa\u0026quot; et \u0026quot;wa\u0026quot;. Développé par Penthium2 BZHack, c'est le genre de projet qui te fait comprendre que l'informatique, c'est avant tout de l'art.\nComment ça marche ? L'algorithme est d'une beauté simple :\nCaractère → Index dans une table de 97 caractères Index → Binaire 8 bits 0 devient \u0026quot; awa \u0026quot;, 1 devient \u0026quot;wa\u0026quot; Magie : espaces → 💩, tabs → 💨, retours à la ligne → 🍆 Le projet est toujours en développement à l'heure actuelle.\nPourquoi une interface web ? Les scripts Bash originaux (awacoder.sh / awadecode.sh) c'est cool, mais parfois on veut juste encoder/décoder rapidement sans sortir du navigateur. Et puis, ça manquait cruellement d'un bouton \u0026quot;Écouter\u0026quot; avec l'API Web Speech Synthesis.\nFeatures qui claquent 100% compatible avec les scripts Bash originaux Design terminal rétro qui fait plaisir aux yeux Raccourci \u0026quot;Ctrl+Entrée\u0026quot; parce qu'on est des pros Boutons de copie intégrés (fini le Ctrl+A/Ctrl+C) Lecture audio du résultat (parce que entendre \u0026quot;awa awa awawawawa\u0026quot; c'est magique) Statistiques temps réel d'encodage/décodage Le mot de la fin awaSCII+ Web c'est l'exemple parfait que l'informatique peut être fun, absurde et techniquement propre à la fois. C'est compatible avec l'original, ça marche sur mobile, et ça fait sourire.\nAlors la prochaine fois que vous voulez envoyer un message secret ou juste faire le malin, pensez awaSCII+ !\nLiens utiles :\nInterface web : awa.noobops.fr Source originale : awaSCII_5.0.666 PS : Le site est aussi accessible via le menu de navigation. Parce qu'il faut bien que les gens puissent retrouver cette merveille technologique.\n","date":"2025-09-28T03:55:27+02:00","image":"/awascii-web-quand-lencodage-devient-un-art-de-vivre/cover.png","permalink":"/awascii-web-quand-lencodage-devient-un-art-de-vivre/","title":"awaSCII+ Web : Quand l’encodage devient un art de vivre"},{"content":"Introduction Naviguer dans l'arborescence des fichiers en ligne de commande peut rapidement devenir fastidieux, surtout lorsque vous travaillez avec des projets complexes comportant de nombreux répertoires imbriqués. C'est là qu'intervient zoxide, un outil révolutionnaire qui transforme votre expérience de navigation en shell.\nZoxide est une alternative moderne et intelligente à la commande cd traditionnelle. Inspiré par des outils comme z et autojump, il mémorise les répertoires que vous visitez le plus fréquemment et vous permet de \u0026quot;sauter\u0026quot; vers eux en quelques frappes seulement.\nQu\u0026rsquo;est-ce que zoxide ? Zoxide est un utilitaire de navigation rapide qui :\nApprend de vos habitudes : Il enregistre automatiquement les répertoires que vous visitez Propose une navigation intelligente : Plus vous visitez un répertoire, plus il devient facile d'y accéder Supporte tous les shells majeurs : Bash, Zsh, Fish, PowerShell, Nushell, et plus encore Offre une sélection interactive : Avec zi, vous pouvez choisir parmi plusieurs options via fzf Reste compatible : Fonctionne comme un cd classique quand nécessaire Installation sur Debian/Ubuntu et dérivés Installation via les dépôts officiels La méthode la plus simple pour installer zoxide sur Debian 11+ et Ubuntu est d'utiliser les dépôts officiels :\nsudo apt update sudo apt install zoxide Méthodes alternatives d\u0026rsquo;installation Si vous préférez une version plus récente ou si zoxide n'est pas disponible dans vos dépôts, vous pouvez utiliser :\nVia le script d\u0026rsquo;installation officiel curl -sSfL https://raw.githubusercontent.com/ajeetdsouza/zoxide/main/install.sh | sh ⚠️ Note de sécurité : Il est recommandé de lire le contenu du script avant de l'exécuter. Vous pouvez d'abord le télécharger avec curl -sSfL https://raw.githubusercontent.com/ajeetdsouza/zoxide/main/install.sh pour l'examiner.\nVia Cargo (si Rust est installé) cargo install zoxide --locked Via Homebrew sur Linux brew install zoxide Prérequis recommandé : fzf Pour profiter pleinement de zoxide, notamment de la commande interactive zi, il est recommandé d'installer fzf :\nsudo apt install fzf Configuration avec zoxide init Une fois zoxide installé, vous devez l'initialiser dans votre shell. Cette étape est cruciale car elle intègre zoxide à votre environnement shell.\nNote : La commande zoxide init génère la configuration à ajouter à votre profil shell.\nConfiguration pour Bash Ajoutez cette ligne à la fin de votre fichier ~/.bashrc :\neval \u0026#34;$(zoxide init bash)\u0026#34; Configuration pour Zsh Ajoutez cette ligne à la fin de votre fichier ~/.zshrc :\neval \u0026#34;$(zoxide init zsh)\u0026#34; Configuration pour Fish Ajoutez cette ligne à la fin de votre fichier ~/.config/fish/config.fish :\nzoxide init fish | source Rechargement de la configuration Après avoir modifié votre fichier de configuration, rechargez-le suivant le shell utilisé :\nsource ~/.bashrc source ~/.zshrc source ~/.config/fish/config.fish Utilisation de base Une fois configuré, zoxide vous donne accès à plusieurs commandes puissantes :\nLa commande z z foo z foo bar z foo/ z ~/Documents z .. z - La commande zi (navigation interactive) zi foo Cette commande ouvre une interface interactive où vous pouvez choisir parmi plusieurs répertoires correspondants.\nAutocomplétion Sur les shells compatibles (Bash 4.4+, Fish, Zsh), vous pouvez utiliser l'autocomplétion :\nz foo\u0026lt;SPACE\u0026gt;\u0026lt;TAB\u0026gt; Bonus : Alias cd='z' Pour une intégration encore plus transparente, vous pouvez créer un alias qui remplace complètement cd par z :\nMéthode recommandée : Configuration automatique via zoxide init La meilleure approche est d'utiliser l'option --cmd cd lors de l'initialisation :\neval \u0026#34;$(zoxide init bash --cmd cd)\u0026#34; eval \u0026#34;$(zoxide init zsh --cmd cd)\u0026#34; Avec cette configuration, la commande cd sera automatiquement remplacée par z, tout en conservant la compatibilité avec l'utilisation classique de cd.\nAlternative : Alias manuel Si vous préférez ne pas modifier votre configuration zoxide init existante, vous pouvez simplement ajouter un alias :\nalias cd=\u0026#39;z\u0026#39; Cette méthode produit le même résultat que --cmd cd, mais la méthode automatique avec --cmd cd est plus propre et évite les conflits potentiels.\nOptions de configuration avancées Personnalisation du préfixe des commandes eval \u0026#34;$(zoxide init bash --cmd j)\u0026#34; eval \u0026#34;$(zoxide init bash --cmd cd)\u0026#34; Contrôle de la fréquence d\u0026rsquo;enregistrement eval \u0026#34;$(zoxide init bash --hook pwd)\u0026#34; eval \u0026#34;$(zoxide init bash --hook prompt)\u0026#34; eval \u0026#34;$(zoxide init bash --hook none)\u0026#34; Exemples pratiques d\u0026rsquo;utilisation Scénario 1 : Développement web cd ~/projets/mon-site-web/src/components/header z header Scénario 2 : Administration système z logs z config Scénario 3 : Projets multiples z projet1 z projet2 backend z projet3 frontend Commandes utiles Gestion de la base de données zoxide zoxide query --list zoxide add /chemin/vers/repertoire zoxide remove /chemin/vers/repertoire # Nettoyer les répertoires inexistants zoxide query --list | while read -r line; do path=$(echo \u0026#34;$line\u0026#34; | awk \u0026#39;{print $2}\u0026#39;) [ ! -d \u0026#34;$path\u0026#34; ] \u0026amp;\u0026amp; zoxide remove \u0026#34;$path\u0026#34; done Avantages par rapport aux alternatives Comparaison avec autojump Source : https://github.com/wting/autojump\nPerformance : zoxide est écrit en Rust, plus rapide que autojump (Python) Maintenance : Projet activement maintenu Compatibilité : Support natif de plus de shells Comparaison avec z.sh Source : https://github.com/rupa/z\nAlgorithme : Meilleur algorithme de classement Fonctionnalités : Mode interactif avec zi Robustesse : Gestion d'erreurs améliorée Intégrations et outils complémentaires Avec votre éditeur Vous pouvez créer des fonctions personnalisées pour ouvrir directement des projets :\n# Fonction pour ouvrir un projet avec Neovim function nvim-project() { local dir=$(zoxide query \u0026#34;$1\u0026#34;) if [ -n \u0026#34;$dir\u0026#34; ]; then cd \u0026#34;$dir\u0026#34; \u0026amp;\u0026amp; nvim . else echo \u0026#34;Projet non trouvé : $1\u0026#34; fi } # Fonction pour ouvrir un projet avec VS Code function code-project() { local dir=$(zoxide query \u0026#34;$1\u0026#34;) if [ -n \u0026#34;$dir\u0026#34; ]; then code \u0026#34;$dir\u0026#34; else echo \u0026#34;Projet non trouvé : $1\u0026#34; fi } ","date":"2025-09-21T00:00:10+02:00","image":"/zoxide-une-alternative-intelligente-a-la-commande-cd/cover.png","permalink":"/zoxide-une-alternative-intelligente-a-la-commande-cd/","title":"Zoxide : Une alternative intelligente à la commande cd"},{"content":"L'option metrics-addr est une configuration importante du daemon Docker qui permet d'exposer les métriques de performance et d'utilisation des ressources via un endpoint HTTP. Cette fonctionnalité, combinée avec le port par défaut 9323, vous donne accès à une mine d'informations sur votre environnement Docker.\nComprendre l\u0026rsquo;option metrics-addr L'option metrics-addr configure l'adresse IP et le port sur lesquels le daemon Docker expose ses métriques. Par défaut, quand cette option est activée, Docker utilise le port 9323.\nPourquoi le port 9323 ? C'est un port non-privilégié (supérieur à 1024) Il est officiellement alloué à Docker par l'IANA pour cette fonctionnalité Il est peu susceptible d'entrer en conflit avec d'autres services courants Il suit la convention de Prometheus pour les ports d'exportation de métriques (9xxx) Ce que vous obtenez avec metrics-addr Activer l'option metrics-addr dans le daemon.json vous donne accès à de nombreuses métriques Docker formatées nativement pour Prometheus :\nMétriques système : Utilisation CPU, mémoire, disque et réseau par conteneur Métriques du daemon : État du daemon, nombre d'objets gérés (conteneurs, images, volumes) Métriques d'utilisation : Temps de démarrage des conteneurs, opérations réseau Métriques de performance : Latences des opérations de build et de déploiement Toutes ces métriques sont disponibles au format Prometheus, ce qui les rend facilement intégrables dans un système de monitoring existant.\nℹ️ Point technique : Le format Prometheus utilise des \u0026quot;labels\u0026quot; qui permettent de filtrer et d'agréger les métriques de manière flexible.\nCas d\u0026rsquo;utilisation pour metrics-addr L'activation de metrics-addr est particulièrement utile dans les scénarios suivants :\nSupervision d'infrastructure : Intégration avec Prometheus pour surveiller l'ensemble de votre environnement Docker Alerting automatisé : Déclencher des alertes basées sur des seuils de métriques spécifiques Dashboarding : Création de tableaux de bord Grafana pour visualiser les performances Analyse de tendance : Collecter des données sur de longues périodes pour identifier les tendances Détection d'anomalies : Repérer les comportements anormaux dans vos conteneurs Configuration de metrics-addr Configuration via daemon.json La méthode recommandée pour activer les métriques Docker est de modifier le fichier de configuration du daemon :\nÉditez le fichier de configuration Docker :\nsudo vi /etc/docker/daemon.json Ajoutez la configuration pour activer l'API de métriques :\n{ \u0026#34;metrics-addr\u0026#34; : \u0026#34;127.0.0.1:9323\u0026#34;, \u0026#34;experimental\u0026#34; : true } Note : L'adresse 127.0.0.1 limite l'accès à la machine locale. Pour exposer les métriques au réseau, utilisez 0.0.0.0:9323 (avec précaution).\nRedémarrez Docker pour appliquer les changements :\nsudo systemctl restart docker Vérifiez que les métriques sont disponibles :\ncurl http://localhost:9323/metrics Vous devriez voir une sortie avec de nombreuses métriques au format Prometheus.\nVisualisation simple avec Docker Stats Pour un aperçu rapide des performances de vos conteneurs sans configuration supplémentaire :\ndocker stats Cela affiche en temps réel les statistiques d'utilisation des ressources pour tous les conteneurs :\nCPU% : Pourcentage d'utilisation du CPU MEM% : Pourcentage d'utilisation de la mémoire NET I/O : Transfert réseau entrant/sortant BLOCK I/O : Lectures/écritures sur disque PIDS : Nombre de processus Pour cibler des conteneurs spécifiques :\ndocker stats container1 container2 Note: Pour des solutions plus avancées comme Prometheus+Grafana ou cAdvisor, voir la section \u0026quot;Solutions avancées\u0026quot; en fin d'article.\nLes limites à connaître Limites des métriques natives :\nPas de persistance des données historiques Interface de visualisation minimale Absence d'alertes automatiques Considérations de performance :\nL'activation des métriques consomme des ressources supplémentaires L'exposition sur le réseau nécessite des précautions de sécurité Le port 9323 doit être protégé par un pare-feu ou limité à localhost Limites de fonctionnalités :\nLes métriques Docker ne couvrent pas les métriques applicatives Pas d'information sur la santé des applications à l'intérieur des conteneurs Nécessite des outils complémentaires pour une vision complète Bonnes pratiques Commencez simplement\nIdentifiez les métriques critiques pour votre cas d'usage Augmentez progressivement la complexité Automatisez les alertes\nConfigurez des alertes sur les seuils critiques Évitez les alertes trop sensibles qui causeraient de la fatigue d'alarme Corrélation de métriques\nCombinez les métriques Docker avec des métriques système et applicatives Utilisez des dashboards qui montrent des corrélations entre métriques Conservation des données\nDéfinissez une politique de rétention adaptée à vos besoins Agrégez les données anciennes pour économiser de l'espace En résumé Les métriques Docker sont essentielles pour une gestion efficace des conteneurs en production. La configuration via daemon.json offre un moyen simple d'exposer ces données pour votre monitoring, vous donnant une première couche de visibilité sur vos conteneurs.\n💡 Astuce : Commencez par les métriques natives et docker stats pour comprendre vos besoins, puis évaluez si vous avez besoin de solutions plus avancées.\nSolutions avancées (Annexe) 1. Intégration avec Prometheus Les métriques exposées via daemon.json sont déjà au format Prometheus. Pour les collecter :\n# prometheus.yml scrape_configs: - job_name: \u0026#39;docker\u0026#39; static_configs: - targets: [\u0026#39;127.0.0.1:9323\u0026#39;] 2. Utilisation de cAdvisor Pour une solution prête à l'emploi avec interface web :\ndocker run \\ --volume=/:/rootfs:ro \\ --volume=/var/run:/var/run:ro \\ --volume=/sys:/sys:ro \\ --volume=/var/lib/docker/:/var/lib/docker:ro \\ --publish=8080:8080 \\ --detach=true \\ --name=cadvisor \\ gcr.io/cadvisor/cadvisor:latest Interface disponible sur http://localhost:8080\n","date":"2025-06-15T18:55:14+02:00","image":"/docker-metrics-port-9323/cover.png","permalink":"/docker-metrics-port-9323/","title":"Docker : Metrics port 9323"},{"content":"live-restore est une fonctionnalité de Docker qui permet aux conteneurs de continuer à fonctionner normalement pendant que le daemon Docker redémarre. En activant cette option, vous évitez l'arrêt intempestif de vos applications lors des mises à jour ou des modifications de configuration du daemon Docker.\nLe problème : Sans live-restore Par défaut, quand vous exécutez systemctl restart docker :\nTous les conteneurs en cours d'exécution s'arrêtent immédiatement Les applications deviennent inaccessibles Les connexions réseau sont brutalement coupées Les données en mémoire non sauvegardées peuvent être perdues C'est comme couper l'électricité d'un bâtiment entier pour changer une ampoule !\nLa solution : Comment fonctionne live-restore ? Quand vous activez live-restore, Docker modifie son comportement :\nDécouplage : Les conteneurs sont détachés du cycle de vie du daemon Maintien en vie : Les processus continuent de s'exécuter sous la supervision du noyau Linux Reprise : Le daemon Docker reprend le contrôle des conteneurs après son redémarrage ℹ️ Important : Cela ne protège que contre les redémarrages du daemon Docker, pas contre les arrêts du système d'exploitation ou les pannes matérielles.\nQuand utiliser live-restore ? Cette fonctionnalité est particulièrement utile pour :\nMises à jour de sécurité : Appliquer des correctifs sans interruption de service Maintenance planifiée : Modifier la configuration Docker sans impacter les applications Environnements critiques : Où la disponibilité est essentielle Déploiements complexes : Avec de nombreuses dépendances entre conteneurs Comment l\u0026rsquo;activer ? Éditez le fichier de configuration Docker :\nsudo vi /etc/docker/daemon.json Ajoutez ou modifiez la configuration :\n{ \u0026#34;live-restore\u0026#34;: true } Redémarrez Docker :\nsudo systemctl restart docker Vérifiez l'activation :\ndocker info | grep -i live Vous devriez voir : Live Restore Enabled: true\nLes limites à connaître Pas de protection contre :\nLes redémarrages du système d'exploitation Les pannes matérielles Les arrêts intempestifs du système Fonctionnalités limitées pendant le redémarrage :\nLa CLI Docker est indisponible Pas de création/suppression de conteneurs Gestion réseau et stockage limitée Compatibilité :\nCertains drivers de stockage peuvent poser problème Les fonctionnalités expérimentales ne sont pas toujours supportées Bonnes pratiques Testez d'abord en préproduction Surveillez les métriques système pendant les redémarrages Documentez la procédure pour votre équipe Ayez un plan de secours en cas de problème En résumé live-restore est un outil précieux pour maintenir la disponibilité de vos conteneurs lors des opérations de maintenance du daemon Docker. Bien qu'il ne soit pas une solution miracle, il peut vous aider à réduire considérablement les temps d'arrêt non planifiés.\n💡 Astuce : Pour une haute disponibilité complète, combinez live-restore avec d'autres stratégies comme l'orchestration de conteneurs (Swarm, Kubernetes) et la répartition de charge.\n","date":"2025-06-15T18:06:04+02:00","image":"/docker-live-restore-cest-quoi/cover.png","permalink":"/docker-live-restore-cest-quoi/","title":"Docker : live-restore, c’est quoi ?"},{"content":"Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans l'univers des logs Docker. Comme on dit dans notre jargon : \u0026quot;Sans logs, c'est comme chercher une erreur dans un datacenter éteint - théoriquement possible, mais pas vraiment efficace.\u0026quot;\nComprendre les logs dans Docker Docker propose plusieurs pilotes de journalisation pour gérer les logs de vos conteneurs. Par défaut, tous vos messages sont acheminés vers le pilote json-file, qui stocke les logs sous forme de fichiers JSON dans /var/lib/docker/containers/[container-id]/.\nLe problème ? Ces fichiers peuvent grossir... grossir... et encore grossir, jusqu'à dévorer tout l'espace disque de votre serveur. Une véritable histoire d'horreur pour tout admin système qui se respecte.\nConfiguration du pilote de logs par défaut La configuration des logs se fait dans le fichier /etc/docker/daemon.json. Voici comment éviter le scénario catastrophe du disque plein :\n{ \u0026#34;log-driver\u0026#34;: \u0026#34;json-file\u0026#34;, \u0026#34;log-opts\u0026#34;: { \u0026#34;max-size\u0026#34;: \u0026#34;10m\u0026#34;, \u0026#34;max-file\u0026#34;: \u0026#34;3\u0026#34; } } Note : Cette configuration limite la taille de chaque fichier de log à 10 Mo et permet une rotation sur 3 fichiers maximum.\nAprès cette modification, un petit redémarrage s'impose :\nsudo systemctl restart docker Les différents pilotes de logs Docker ne se limite pas au format JSON. Voici les principaux pilotes disponibles, chacun avec ses forces et ses faiblesses :\njson-file : Le pilote par défaut\nStocke les logs dans des fichiers JSON Accessible via docker logs Exemple de configuration personnalisée : docker run --log-driver=json-file \\ --log-opt max-size=10m \\ --log-opt max-file=3 \\ --log-opt labels=app_name \\ nginx Parfait pour le développement et les petits déploiements local : Le petit frère optimisé\nFormat binaire plus compact que JSON Toujours accessible via docker logs Exemple d'utilisation : docker run --log-driver=local \\ --log-opt max-size=10m \\ --log-opt max-file=5 \\ --log-opt compress=true \\ nginx Idéal pour les environnements de production avec espace disque limité syslog : L'option du barbu expérimenté\nEnvoie les logs au service syslog de l'hôte Configuration type avec rotation via logrotate : # Dans /etc/docker/daemon.json { \u0026#34;log-driver\u0026#34;: \u0026#34;syslog\u0026#34;, \u0026#34;log-opts\u0026#34;: { \u0026#34;syslog-address\u0026#34;: \u0026#34;udp://192.168.1.100:514\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;{{.ImageName}}/{{.Name}}/{{.ID}}\u0026#34;, \u0026#34;syslog-facility\u0026#34;: \u0026#34;local7\u0026#34; } } Configuration équivalente dans docker-compose : services: app: image: nginx logging: driver: syslog options: syslog-address: \u0026#34;udp://192.168.1.100:514\u0026#34; tag: \u0026#34;{{.ImageName}}/{{.Name}}/{{.ID}}\u0026#34; Petit prix à payer : docker logs ne fonctionne plus directement journald : L'ami des systèmes modernes\nParfait pour les systèmes basés sur systemd Exemple de configuration : # Activer journald dans /etc/docker/daemon.json { \u0026#34;log-driver\u0026#34;: \u0026#34;journald\u0026#34;, \u0026#34;log-opts\u0026#34;: { \u0026#34;tag\u0026#34;: \u0026#34;{{.ImageName}}/{{.Name}}/{{.ID}}\u0026#34;, \u0026#34;labels\u0026#34;: \u0026#34;app_name,environment\u0026#34; } } Pour consulter les logs :\n# Voir les logs d\u0026#39;un conteneur journalctl CONTAINER_NAME=mon_conteneur # Suivre les logs en temps réel journalctl -f CONTAINER_NAME=mon_conteneur # Filtrer par priorité journalctl -p err CONTAINER_NAME=mon_conteneur Le choix évident si vous utilisez déjà systemd pour tout le reste Les poids lourds : pour les environnements critiques\nSplunk :\ndocker run --log-driver=splunk \\ --log-opt splunk-token=YOUR_TOKEN \\ --log-opt splunk-url=https://your-splunk:8088 \\ --log-opt tag=\u0026#34;{{.ImageName}}/{{.Name}}/{{.ID}}\u0026#34; \\ nginx AWS CloudWatch Logs :\ndocker run --log-driver=awslogs \\ --log-opt awslogs-region=eu-west-1 \\ --log-opt awslogs-group=my-log-group \\ --log-opt awslogs-stream=my-stream \\ nginx Fluentd :\n# docker-compose.yml version: \u0026#39;3\u0026#39; services: app: image: nginx logging: driver: \u0026#34;fluentd\u0026#34; options: fluentd-address: localhost:24224 tag: docker.{{.Name}} fluentd: image: fluent/fluentd volumes: - ./fluentd/conf:/fluentd/etc ports: - \u0026#34;24224:24224\u0026#34; GELF (Graylog Extended Log Format) :\ndocker run --log-driver=gelf \\ --log-opt gelf-address=udp://graylog:12201 \\ --log-opt tag=\u0026#34;{{.ImageName}}/{{.Name}}\u0026#34; \\ nginx Ces solutions sont idéales pour les environnements de production à grande échelle nécessitant une analyse avancée des logs.\nConfiguration par conteneur Parfois, un conteneur mérite un traitement spécial. Vous pouvez configurer le pilote de logs individuellement, comme un couturier qui ajuste un costume sur mesure :\ndocker run --log-driver=journald --log-opt labels=app_id --name=mon-app nginx Ou dans un fichier docker-compose.yml :\nversion: \u0026#39;3\u0026#39; services: mon_service: image: mon_image logging: driver: json-file options: max-size: \u0026#34;10m\u0026#34; # Taille maximale d\u0026#39;un fichier de log max-file: \u0026#34;3\u0026#34; # Nombre maximum de fichiers de rotation Bonnes pratiques pour la gestion des logs La rotation, c'est la vie\nConfigurez toujours max-size et max-file Évitez les fichiers de logs de 42 Go qui font pleurer les disques durs Étiquetez, c'est gagné\nUtilisez des tags personnalisés pour chaque conteneur Ajoutez des labels pour plus de contexte Les logs, c'est comme le bon vin : ça se conserve\nCentralisez avec ELK, Graylog ou Loki Pensez à la rétention et à l'archivage La surveillance, c'est comme le café du matin : indispensable\nSurveillez l'espace disque utilisé par les logs Configurez des alertes pour les cas critiques, surtout en production Structurez vos logs : encouragez vos développeurs à générer des logs au format JSON pour faciliter leur analyse\nConclusion Les logs, c'est un peu comme le journal intime de vos conteneurs. Une bonne configuration peut transformer une enquête policière en simple coup d'œil. Ou l'inverse.\nComme dirait un vieux barbu de l'IT : \u0026quot;Les logs, c'est comme le papier toilette - on ne réalise leur importance que quand on en a plus.\u0026quot; Alors, à vos fichiers de configuration, et que la force des logs soit avec vous !\nEt souvenez-vous : dans un monde de conteneurs éphémères, seuls les logs racontent l'histoire complète (du moins jusqu'à ce qu'ils soient eux aussi supprimés par rotation).\n","date":"2025-06-15T17:33:44+02:00","image":"/docker-configuration-et-gestion-des-logs/cover.png","permalink":"/docker-configuration-et-gestion-des-logs/","title":"Docker : Configuration et gestion des logs"},{"content":"Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans les profondeurs du stockage Docker. Comme on dit dans notre jargon : \u0026quot;Un disque mal configuré est à un admin système ce que Kryptonite est à Superman - une faiblesse qui peut tout paralyser.\u0026quot;\nComprendre le stockage dans Docker Docker utilise un système de stockage en couches qui peut être à la fois génial et déroutant. Chaque instruction dans un Dockerfile crée une nouvelle couche en lecture seule, et seul le conteneur en fonctionnement dispose d'une couche supérieure en lecture-écriture.\nPar défaut, Docker stocke toutes ses données (images, conteneurs, volumes) dans /var/lib/docker. Sur un serveur de production, cette partition peut rapidement devenir le goulot d'étranglement de votre système.\nConfiguration du pilote de stockage Docker propose plusieurs pilotes de stockage, chacun avec ses avantages et inconvénients. Vous pouvez configurer le pilote à utiliser dans le fichier /etc/docker/daemon.json :\n{ \u0026#34;storage-driver\u0026#34;: \u0026#34;overlay2\u0026#34; } Note : overlay2 est généralement le pilote recommandé pour les distributions Linux modernes, offrant le meilleur équilibre entre performance et fonctionnalités.\nAprès cette modification, un redémarrage du service Docker est nécessaire :\nsudo systemctl restart docker Les différents pilotes de stockage overlay2 : Le pilote recommandé pour la plupart des cas d'usage\nAvantages : Bonnes performances, compatibilité Prérequis : Noyau Linux 4.0+ et systèmes de fichiers modernes Le pilote overlay2 repose sur la fonctionnalité OverlayFS du noyau Linux, qui permet de superposer plusieurs systèmes de fichiers. Il fonctionne avec la plupart des systèmes de fichiers courants (ext4, xfs) et offre de bien meilleures performances que l'ancien pilote overlay.\ndevicemapper : Utilisé principalement sur les anciennes versions de CentOS/RHEL\nPour la production, configurez-le en mode direct-lvm plutôt qu'en mode loop-lvm par défaut Permet d'utiliser un périphérique de bloc dédié pour les données Docker, offrant de meilleures performances { \u0026#34;storage-driver\u0026#34;: \u0026#34;devicemapper\u0026#34;, \u0026#34;storage-opts\u0026#34;: [ \u0026#34;dm.directlvm_device=/dev/xvdf\u0026#34; ] } Systèmes de fichiers avancés et distribués : Pour aller plus loin\nLes systèmes comme btrfs et zfs offrent des fonctionnalités avancées comme les snapshots Les systèmes de fichiers distribués comme Ceph ou GlusterFS permettent de créer une infrastructure de stockage Docker hautement disponible et évolutive Astuce : Pour tirer pleinement profit de ces systèmes distribués, utilisez la technique du \u0026quot;volume bind déguisé\u0026quot; qui permet de créer un volume Docker qui pointe vers un point de montage réseau\nDéplacer le répertoire de données Docker Si votre partition /var est trop petite, vous pouvez déplacer le répertoire de données Docker vers un autre emplacement :\n{ \u0026#34;data-root\u0026#34;: \u0026#34;/mnt/docker-data\u0026#34; } Attention : Ne modifiez jamais ce paramètre sur une installation Docker existante sans migrer correctement les données !\nPour migrer les données d'une installation existante :\n# Arrêter Docker sudo systemctl stop docker # Créer le nouveau répertoire sudo mkdir -p /mnt/docker-data # Copier les données existantes sudo rsync -aP /var/lib/docker/ /mnt/docker-data/ # Configurer le nouveau chemin dans daemon.json # Puis redémarrer Docker sudo systemctl start docker Volumes bind déguisés : la technique du ninja du stockage Une des techniques les plus astucieuses dans l'arsenal de l'admin Docker est celle du \u0026quot;volume bind déguisé\u0026quot; - ou comment faire passer un bind mount pour un volume Docker respectable, tout en gardant le contrôle sur l'emplacement physique des données.\nImaginez pouvoir dire à vos conteneurs : \u0026quot;Voici un volume Docker standard\u0026quot; alors qu'en coulisses, vous stockez les données sur votre cluster Ceph soigneusement configuré. C'est comme servir un plat végétarien à vos invités sans qu'ils ne remarquent l'absence de viande - l'élégance à l'état pur.\nCette technique est particulièrement précieuse quand vous travaillez avec :\nDes systèmes de stockage distribués (Ceph, GlusterFS) Des montages NFS pour un stockage partagé Des volumes qui doivent survivre à la migration de vos conteneurs Pour les détails d'implémentation, consultez mon article dédié : Docker : Volume bind déguisé qui vous explique pas à pas comment mettre en place cette technique.\nNettoyage de l\u0026rsquo;espace disque Docker a tendance à accumuler des données inutilisées. Voici quelques commandes pour faire le ménage :\n# Supprimer les conteneurs arrêtés, réseaux non utilisés, images dangling et cache de build docker system prune # Pour être encore plus agressif et supprimer aussi les images non utilisées docker system prune -a # Pour récupérer de l\u0026#39;espace sur les volumes non utilisés docker volume prune Bonnes pratiques pour la gestion du stockage Utilisez des images légères : Préférez les images basées sur Alpine quand c'est possible\nOptimisez vos Dockerfiles :\nCombinez les commandes RUN pour réduire le nombre de couches Nettoyez les caches de paquets dans la même instruction qui les installe RUN apt update \u0026amp;\u0026amp; apt install -y \\ package1 \\ package2 \\ \u0026amp;\u0026amp; apt clean \\ \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* Utilisez .dockerignore pour exclure les fichiers inutiles du contexte de build\nSurveillez régulièrement l'espace disque utilisé par Docker avec docker system df\nConfigurez un cron job pour nettoyer périodiquement les ressources inutilisées\nConclusion La gestion du stockage Docker ressemble parfois à un jeu de Tetris où les blocs seraient des gigaoctets - il faut savoir optimiser l'espace pour éviter le game over.\nEn configurant correctement votre pilote de stockage et en adoptant de bonnes pratiques de nettoyage, vous pourrez éviter ce moment gênant où vous devez expliquer pourquoi le serveur de production s'est arrêté juste parce qu'il y avait trop d'images \u0026quot;hello-world\u0026quot; qui traînaient.\nEt souvenez-vous : dans un monde de conteneurs éphémères, les données persistantes méritent toujours une réflexion approfondie (et un bon volume Docker).\n","date":"2025-06-15T16:56:25+02:00","image":"/docker-configuration-et-gestion-du-stockage/cover.png","permalink":"/docker-configuration-et-gestion-du-stockage/","title":"Docker : Configuration et gestion du stockage"},{"content":"Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans le fascinant (et parfois frustrant) monde des réseaux Docker. Comme on dit dans notre jargon : \u0026quot;Un conteneur sans réseau, c'est comme un pingouin sans banquise - techniquement possible, mais pas vraiment utile.\u0026quot;\nLes réseaux Docker par défaut Docker, cet invité un peu sans-gêne, s'installe et crée directement trois réseaux :\nbridge : Le réseau par défaut où tous vos conteneurs font la fête (172.17.0.0/16) host : Pour quand vos conteneurs veulent se sentir comme à la maison none : Pour les conteneurs asociaux qui préfèrent rester dans leur coin Le réseau bridge s'approprie allègrement la plage 172.17.0.0/16. Mais que se passe-t-il quand cette plage est déjà occupée par votre infrastructure existante ? Eh bien, c'est un peu comme deux familles qui réservent le même bungalow pour les vacances - ça crée des tensions.\nRésolution des conflits avec le réseau par défaut Pour modifier la plage d'adresses que Docker utilise par défaut, éditez le fichier /etc/docker/daemon.json (si le fichier n'existe pas, créez-le avec la même joie que lorsque vous créez un nouveau répertoire batman) :\n{ \u0026#34;default-address-pools\u0026#34;: [ { \u0026#34;base\u0026#34;: \u0026#34;192.168.66.0/24\u0026#34;, \u0026#34;size\u0026#34;: 24 } ] } Après cette modification, un petit redémarrage s'impose :\nsudo systemctl restart docker Incrémentation automatique des réseaux Docker Quand vous créez de nouveaux réseaux Docker avec docker network create, Docker fait preuve d'une logique implacable pour l'allocation des sous-réseaux. En fonction de votre configuration default-address-pools, Docker va attribuer automatiquement des plages d'adresses IP qui s'incrémentent à chaque nouveau réseau :\ndocker network create mon-super-reseau Pour cette commande, Docker utilisera automatiquement la première plage disponible: 192.168.66.0/24\ndocker network create mon-autre-reseau Pour ce deuxième réseau, Docker passera à la plage suivante: 192.168.67.0/24\nC'est comme distribuer des tranches de gâteau - mais en version IP.\nSi vous préférez choisir votre part vous-même :\ndocker network create --subnet=192.168.42.0/24 mon-reseau-avec-le-nombre-de-la-vie Les différents types de réseaux Docker Dans un Docker Engine standalone Un Docker Engine standard (non-Swarm) propose plusieurs types de réseaux pour répondre à des besoins distincts :\nbridge : Le réseau par défaut utilisé par les conteneurs. C'est un réseau virtuel interne qui permet aux conteneurs de communiquer entre eux et avec l'hôte.\nhost : Supprime l'isolation réseau entre le conteneur et l'hôte. Le conteneur utilise directement la pile réseau de l'hôte. Utile pour les performances mais réduit l'isolation.\nnone : Désactive complètement le réseau. Le conteneur n'a aucun accès réseau externe. Utile pour les traitements isolés ne nécessitant pas de communication.\nmacvlan : Attribue une adresse MAC physique aux conteneurs, les faisant apparaître comme des périphériques physiques sur le réseau. Idéal pour migrer des applications legacy qui dépendent d'IPs spécifiques.\n# Créer un réseau bridge personnalisé (recommandé au lieu du bridge par défaut) docker network create --driver bridge mon-reseau-bridge Dans un cluster Docker Swarm Docker Swarm, c'est comme une colocation de conteneurs répartis sur plusieurs serveurs. La communication entre nœuds nécessite des réseaux spéciaux :\noverlay : Permet aux conteneurs de différents nœuds de communiquer comme s'ils étaient sur le même hôte. Crée un réseau virtual \u0026quot;au-dessus\u0026quot; de l'infrastructure physique.\ningress : Un réseau overlay spécial qui facilite le routage du trafic entrant vers les services appropriés, indépendamment du nœud qui héberge le conteneur. Gère également l'équilibrage de charge interne.\n# Créer un réseau overlay pour les services Swarm docker network create --driver overlay --attachable mon-reseau-multi-hote Tous ces réseaux peuvent coexister sur le même hote ou cluster, permettant ainsi une architecture réseau flexible et adaptée à chaque cas d'usage.\nLe réseau Ingress et la plage 10.0.0.0/8 Par défaut, ce cher réseau ingress s'installe confortablement dans la plage 10.0.0.0/8. Si vous utilisez déjà cette plage, les symptômes sont clairs :\nDocker vous lance des erreurs cryptiques avec \u0026quot;network overlap\u0026quot; Vos conteneurs deviennent subitement muets Vous commencez à douter de vos choix de carrière Reconfiguration du réseau Ingress Contrairement à ce qu'on pourrait croire, pas besoin de quitter le swarm pour résoudre ce problème ! Une approche beaucoup plus civilisée consiste à :\nSupprimer poliment le réseau ingress existant : docker network rm ingress Créer un nouveau réseau ingress avec votre propre plage : docker network create \\ --driver overlay \\ --ingress \\ --subnet=172.30.0.0/16 \\ --gateway=172.30.0.1 \\ ingress Voilà qui est beaucoup moins traumatisant pour votre swarm que de tout démolir et reconstruire !\nBonnes pratiques pour la gestion des réseaux Docker Planifiez votre allocation d'adresses IP : Un schéma bien pensé vaut mieux qu'une nuit blanche de débogage\nChoisissez le bon type de réseau : Ne vous limitez pas au bridge par défaut.\nBridge personnalisé (docker network create my_bridge) : Résolution DNS entre conteneurs, isolation, idéal pour les applications sur un seul hôte Overlay (docker network create -d overlay my_overlay) : Communication entre hôtes dans Swarm Macvlan (docker network create -d macvlan --subnet=192.168.40.0/24 --gateway=192.168.40.1 -o parent=eth0 my_macvlan) : Intégration au réseau physique Sécurisez votre infrastructure : Évitez d'exposer les ports de base de données (comme MySQL, PostgreSQL, MongoDB) sur votre réseau hôte. C'est une faille de sécurité courante et totalement évitable. Dans les réseaux Docker Compose ou Swarm, la communication inter-services se fait nativement via le nom du service. En pratique, votre service d'application peut simplement utiliser db:3306 comme adresse de connexion, sans jamais avoir à publier le port 3306 sur l'interface de l'hôte. Dans Swarm, cette communication fonctionne même entre des conteneurs déployés sur différents nœuds physiques via les réseaux overlay\nAdoptez une nomenclature claire : Préférez project_frontend_net ou prod_db_network à des noms génériques comme net1\nDocumentez votre architecture réseau : Votre futur vous (ou votre remplaçant après votre burnout) vous remerciera\nConclusion La gestion des réseaux Docker ressemble parfois à un jeu de Tetris avec des blocs CIDR - challenging mais satisfaisant une fois maîtrisé. En comprenant comment Docker assigne et gère les adresses IP, vous pourrez éviter ces moments où, tard dans la nuit, vous fixez votre écran en murmurant \u0026quot;mais pourquoi ça ne communique pas ?\u0026quot;.\nUne bonne configuration réseau vous permettra de dormir tranquille, sachant que vos conteneurs peuvent socialiser entre eux sans créer d'incident diplomatique sur votre infrastructure.\nEt souvenez-vous : dans un monde de conteneurs éphémères, seule une bonne configuration réseau est éternelle (ou du moins, jusqu'au prochain docker-compose down).\n","date":"2025-06-15T16:17:21+02:00","image":"/docker-configuration-des-reseaux-par-defaut/cover.png","permalink":"/docker-configuration-des-reseaux-par-defaut/","title":"Docker : Configuration des réseaux par défaut"},{"content":"1. Introduction, ou pourquoi il est temps d\u0026rsquo;arrêter de faire semblant Laissez-moi deviner : vous êtes du genre à vous vanter d'être un administrateur système compétent, mais vous ne vous souvenez pas de la dernière fois que vous avez tapé apt update \u0026amp;\u0026amp; apt upgrade sur vos serveurs en production ? Pas étonnant que vos systèmes ressemblent à un gruyère numérique avec plus de trous que de fromage. Un bon sysadmin met à jour ses systèmes - un vrai sysadmin automatise ça et passe à autre chose.\nHeureusement, les créateurs de Debian n'ont pas supposé que vous étiez tous des héros de la ligne de commande avec une mémoire infaillible et un agenda aussi vide que /dev/null. Ils nous ont gratifiés d'unattended-upgrades, ce petit bijou d'automatisation que seuls les vrais barbus savent configurer correctement. Bien sûr, vous pourriez continuer à mettre à jour manuellement, de la même manière que vous pourriez continuer à croire que vi est plus difficile qu'Emacs.\n2. Unattended-upgrades : le sysadmin silencieux qui ne prend jamais de pause café Contrairement à votre stagiaire qui croit que \u0026quot;mise à jour de sécurité\u0026quot; signifie \u0026quot;changer son mot de passe de 'password123' à 'password1234'\u0026quot;, unattended-upgrades est un service qui prend son travail au sérieux. Cette petite merveille d'ingénierie fonctionne pendant que vous dormez profondément, rêvant probablement de clusters Kubernetes parfaitement orchestrés (on sait tous que ça n'arrive que dans les rêves).\nTechniquement parlant (et les vrais barbus aiment parler techniquement), c'est un démon qui s'exécute via systemd timers pour :\nChercher les mises à jour que vous auriez dû installer il y a des semaines Filtrer celles qui empêcheront votre système de se faire pwner par un script kiddie Les installer sans vous demander votre avis (parce qu'on sait tous que vous diriez \u0026quot;plus tard\u0026quot;) Redémarrer votre serveur au milieu de la nuit quand personne ne regardera vos graphs de monitoring chuter momentanément Ce paquet fonctionne sur n'importe quelle version de Debian (de l'antique Buster à la fraichement sortie Bookworm) et même sur ces ersatz de Debian comme Ubuntu, si vous vous abaissez à utiliser de telles distributions.\n3. Installation pour ceux qui savent encore taper sur un clavier 3.1 Les bases (même votre stagiaire pourrait le faire) Ouvrez votre terminal noir (parce que bien sûr, vous utilisez un fond noir avec des polices vertes, comme tout vrai barbu qui se respecte) et tapez ces incantations magiques :\nsudo apt update sudo apt install unattended-upgrades apt-listchanges Ce que vous venez de conjurer :\nunattended-upgrades : le véritable héros silencieux qui fera le travail que vous procrastinez habituellement apt-listchanges : pour recevoir des emails détaillés que vous prétendrez lire avant de les archiver automatiquement 3.2 Activation pour les admins qui ont peur de modifier les fichiers de configuration à la main Si vous préférez l'approche \u0026quot;clique-bouton\u0026quot; (aucun jugement, enfin peut-être un peu), Debian vous offre un assistant :\nsudo dpkg-reconfigure --priority=low unattended-upgrades 💡 Astuce de vrai barbu : L'argument --priority=low force l'affichage de toutes les options possibles, parce que les vrais barbus veulent tout contrôler. Les autres priorités sont pour ceux qui pensent qu'utiliser une souris sous Linux est une bonne idée.\nUn menu pseudo-graphique va apparaître dans votre terminal. Sélectionnez \u0026quot;Oui\u0026quot; (comme si vous aviez réellement le choix). Cette étape crée le fichier /etc/apt/apt.conf.d/20auto-upgrades avec une configuration basique pour les âmes simples.\n4. Configuration pour les vrais barbus (ceux qui n\u0026rsquo;utilisent pas de GUI) La configuration d'unattended-upgrades se fait dans deux fichiers de configuration. Si vous ne savez pas ce qu'est un fichier de configuration, fermez cet article et retournez installer Windows :\n/etc/apt/apt.conf.d/50unattended-upgrades - Où la vraie magie se passe /etc/apt/apt.conf.d/20auto-upgrades - Pour dire à votre système à quelle fréquence il doit se sauver lui-même 4.1 Sélection des dépôts (ou comment distinguer les mises à jour importantes des futilités) Éditez /etc/apt/apt.conf.d/50unattended-upgrades (avec vi, bien sûr, pas avec cette abomination qu'est nano). La section Origins-Pattern est comme le filtre de Tinder de votre système - elle décide quelles mises à jour méritent son attention :\nUnattended-Upgrade::Origins-Pattern { \u0026#34;origin=Debian,codename=${distro_codename}-security\u0026#34;; // \u0026#34;origin=Debian,codename=${distro_codename}-updates\u0026#34;; // \u0026#34;origin=Debian,codename=${distro_codename}-proposed-updates\u0026#34;; // \u0026#34;origin=Debian,codename=${distro_codename}-backports\u0026#34;; }; Guide de traduction du jargon Debian pour mortels :\nType de dépôt Ce que Debian dit Ce que ça signifie vraiment À activer si... -security \u0026quot;Correctifs de sécurité critiques\u0026quot; \u0026quot;Colmate les trous que les script kiddies utilisent déjà\u0026quot; Vous avez un minimum d'instinct de survie -updates \u0026quot;Corrections importantes non sécuritaires\u0026quot; \u0026quot;Bugs suffisamment gênants pour qu'on daigne les corriger\u0026quot; Vous en avez assez que vos services plantent mystérieusement -proposed-updates \u0026quot;Candidats en attente de validation\u0026quot; \u0026quot;Quelqu'un a bricolé ça, ça semble marcher, mais on n'est pas sûr\u0026quot; Vous aimez vivre dangereusement (ou avez un environnement de test) -backports \u0026quot;Nouvelles versions portées vers stable\u0026quot; \u0026quot;Du code récent greffé sur un OS dinosaure\u0026quot; Un fonctionnalité VRAIMENT nécessaire vous manque 🐑 Conseil de troupeau : La plupart des moutons n'activent que -security. Les vrais barbus activent tout puis blâment systemd quand ça casse.\n4.2 Planification des mises à jour (ou quand laisser votre système jouer au docteur) Modifiez /etc/apt/apt.conf.d/20auto-upgrades pour définir quand votre système se soignera tout seul :\nAPT::Periodic::Update-Package-Lists \u0026#34;1\u0026#34;; APT::Periodic::Unattended-Upgrade \u0026#34;1\u0026#34;; APT::Periodic::Unattended-Upgrade-Time \u0026#34;3\u0026#34;; APT::Periodic::RandomSleep \u0026#34;60\u0026#34;; Explication pour ceux qui n'ont jamais lu le man :\nUpdate-Package-Lists : À quelle fréquence votre système recherche de nouvelles mises à jour.\n\u0026quot;1\u0026quot; = tous les jours (pour les paranoïaques) \u0026quot;7\u0026quot; = une fois par semaine (pour les décontractés) \u0026quot;0\u0026quot; = jamais (pour ceux qui aiment jouer à la roulette russe avec les exploits) Unattended-Upgrade : Quand appliquer réellement ces mises à jour.\n\u0026quot;1\u0026quot; = quotidiennement (recommandé par tous ceux qui ont déjà dû nettoyer un serveur compromis) \u0026quot;7\u0026quot; = hebdomadaire (un compromis pour les téméraires) \u0026quot;0\u0026quot; = jamais (alors pourquoi lire cet article ?) Unattended-Upgrade-Time : L'heure à laquelle lancer le processus.\n\u0026quot;3\u0026quot; = 3h du matin, quand même les administrateurs système devraient dormir RandomSleep : Le délai aléatoire pour éviter d'être comme tout le monde.\n\u0026quot;60\u0026quot; = entre 0 et 60 minutes de décalage (pour ne pas faire tomber les miroirs Debian quand tout le monde se rue dessus à 3h00 pile) 🐔 Pour les insomniaques : Sur Debian 11+, RandomSleep est en minutes. Sur Debian 10 et avant, c'est en secondes. Pourquoi ? Parce que la cohérence, c'est surfait quand on peut introduire des bugs subtils dans votre configuration.\n4.3 Gestion du reboot automatique (ou comment faire pleurer vos utilisateurs) Les mises à jour du noyau sont comme les légumes - elles ne font effet que si vous redémarrez. Configurez le comportement dans /etc/apt/apt.conf.d/50unattended-upgrades :\nUnattended-Upgrade::Automatic-Reboot \u0026#34;true\u0026#34;; Unattended-Upgrade::Automatic-Reboot-Time \u0026#34;04:30\u0026#34;; Unattended-Upgrade::Automatic-Reboot-WithUsers \u0026#34;false\u0026#34;; Ce que ces options signifient vraiment :\nAutomatic-Reboot : Le grand interrupteur de la terreur nocturne.\n\u0026quot;true\u0026quot; = \u0026quot;J'aime vivre dangereusement et mes backups sont à jour\u0026quot; \u0026quot;false\u0026quot; = \u0026quot;Je préfère avoir un noyau vulnérable mais au moins je sais quand mon serveur redémarre\u0026quot; Automatic-Reboot-Time : L'heure du crime parfait.\nFormat : \u0026quot;HH:MM\u0026quot; (choisir une heure où personne ne remarquera que tout est tombé) Conseil de barbu : planifiez-le toujours APRÈS les mises à jour, pas pendant Automatic-Reboot-WithUsers : Le dilemme éthique.\n\u0026quot;true\u0026quot; = \u0026quot;Les sessions des utilisateurs importent moins que la sécurité\u0026quot; (approche soviétique) \u0026quot;false\u0026quot; = \u0026quot;Les humains d'abord\u0026quot; (approche diplomatique) 🔥 Histoire vraie : J'ai vu un administrateur configurer un redémarrage automatique à 14h sur un serveur de production. Il a ensuite passé trois semaines à se demander pourquoi les utilisateurs lui envoyaient des messages haineux tous les jours.\n4.4 Notifications pour prétendre que vous surveillez vos serveurs Les emails de notification sont là pour vous donner l'illusion que vous savez ce qui se passe sur vos serveurs. Configurez-les dans /etc/apt/apt.conf.d/50unattended-upgrades :\nUnattended-Upgrade::Mail \u0026#34;admin@domaine.fr\u0026#34;; Unattended-Upgrade::MailReport \u0026#34;on-change\u0026#34;; //Unattended-Upgrade::Mail-Server \u0026#34;smtp.example.com\u0026#34;; //Unattended-Upgrade::Mail-Server-Port \u0026#34;587\u0026#34;; //Unattended-Upgrade::Mail-Server-Login \u0026#34;votre_login\u0026#34;; //Unattended-Upgrade::Mail-Server-Password \u0026#34;votre_motdepasse\u0026#34;; Options pour votre spam personnel :\nMail : Qui recevra les rapports que personne ne lit.\nMettez votre email perso si vous aimez être réveillé à 3h du matin par des notifications Ou créez un filtre qui les envoie directement dans un dossier que vous n'ouvrirez jamais MailReport : La fréquence de spam.\n\u0026quot;always\u0026quot; = pour ceux qui aiment leur boîte mail bien remplie \u0026quot;on-change\u0026quot; = le choix des gens raisonnables \u0026quot;only-on-error\u0026quot; = pour ceux qui adhèrent à la philosophie \u0026quot;pas de nouvelles, bonnes nouvelles\u0026quot; 📣 Rappel essentiel : Ces mails ne serviront à rien si vous n'avez pas un MTA fonctionnel. Installez-en un ou tous ces paramètres ne seront que des vœux pieux :\nsudo apt install postfix # OU sudo apt install msmtp msmtp-mta 5. Dompter les mises à jour majeures (ou l\u0026rsquo;art d\u0026rsquo;éviter la crise cardiaque à 3h du matin) Les mises à jour de sécurité, c'est bien, mais les mises à jour majeures, c'est comme laisser un enfant de 5 ans conduire votre voiture - ça peut aller très mal, très vite. Particulièrement avec ces paquets qui utilisent le système d'alternatives de Debian, cette brillante invention qui garantit votre future migraine.\n5.1 Le piège des alternatives (ou comment se tirer une balle dans le pied automatiquement) Les langages comme PHP, Python ou Java utilisent ce merveilleux système d'alternatives, qui permet à plusieurs versions de coexister (comme vos ex, mais en plus utile). Malheureusement, ce système a été conçu par quelqu'un qui n'a manifestement jamais entendu parler de l'automatisation.\nLe drame en 4 actes :\nActe Tragédie Résultat 1 Votre système découvre PHP 8.3 et pense \u0026quot;oh, quelle belle mise à jour !\u0026quot; Installation lancée à 3h17 du matin 2 Le script demande poliment : \u0026quot;Voulez-vous faire de cette nouvelle version la version par défaut ?\u0026quot; Votre serveur fige, attendant une réponse qui ne viendra jamais 3 Vous dormez paisiblement pendant que votre installation reste suspendue Configuration en état zombie (sudo dpkg --configure -a sera votre mantra du matin) 4 Votre système de mise à jour automatique est lui-même bloqué Félicitations, vous venez de désactiver votre sécurité automatique 5.2 Solutions pour barbus confirmés (et amateurs de nuits tranquilles) 5.2.1 Entraîner debconf à ne pas vous demander votre avis Ce code est l'équivalent de mettre un bâillon sur debconf pour qu'il arrête de poser des questions stupides :\nsudo echo \u0026#34;php8.3 php8.3/common/default_for_install boolean false\u0026#34; | sudo debconf-set-selections sudo echo \u0026#34;php8.2 php8.2/common/default_for_install boolean true\u0026#34; | sudo debconf-set-selections Quand l'utiliser : Lorsque vous êtes un admin responsable qui teste d'abord les nouvelles versions avant de les infliger à votre production. Concept alien pour certains, je sais.\n5.2.2 Expliquer à Debian ce qu\u0026rsquo;est une priorité (comme à votre chef de projet) Le système de priorité d'alternatives est l'équivalent technique d'une hiérarchie féodale - celui avec le plus grand nombre gagne :\nsudo update-alternatives --install /usr/bin/php php /usr/bin/php8.2 82 \\ --slave /usr/bin/phar phar /usr/bin/phar8.2 \\ --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.2 sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.3 80 \\ --slave /usr/bin/phar phar /usr/bin/phar8.3 \\ --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.3 💡 Astuce de vrai barbu : La valeur numérique est juste une préférence, pas une garantie. Utilisez des nombres significativement différents si vous ne voulez pas être surpris. J'ai déjà vu des administrateurs utiliser 10 et 11, puis se plaindre que leur choix n'était pas respecté - niveau amateur.\n5.2.3 Le coup du hook post-installation (ou comment avoir le dernier mot) Quand vous en avez assez que Debian ignore vos préférences, créez un hook qui aura le dernier mot après chaque mise à jour :\nsudo vi /etc/apt/apt.conf.d/99post-upgrade-hook Ajoutez ce code vindicatif dans le fichier :\nDPkg::Post-Invoke { \u0026#34;if [ -f /usr/bin/php8.2 ] \u0026amp;\u0026amp; [ -f /usr/bin/php8.3 ]; then update-alternatives --set php /usr/bin/php8.2; fi\u0026#34;; }; Pourquoi c'est brillant : Cette approche passive-agressive rétablit votre version préférée après CHAQUE opération APT, même si un paquet tente sournoisement de changer la version par défaut. C'est l'équivalent de dire \u0026quot;Merci pour ton opinion, maintenant on va faire à ma façon quand même\u0026quot;.\n5.2.4 Mettre un gilet pare-balles contre les versions majeures Ajoutez à /etc/apt/apt.conf.d/50unattended-upgrades ce code défensif :\nUnattended-Upgrade::MinimalSteps \u0026#34;true\u0026#34;; Unattended-Upgrade::Allow-downgrade \u0026#34;false\u0026#34;; Unattended-Upgrade::Allow-APT-Mark-Fallback \u0026#34;false\u0026#34;; Décryptage des incantations de protection :\nOption Ce qu'elle fait vraiment Traduction en langage barbu MinimalSteps Change en mode \u0026quot;un paquet à la fois\u0026quot; \u0026quot;Je préfère que mon système plante sur UN paquet plutôt que sur TOUS\u0026quot; Allow-downgrade Empêche les retours en arrière \u0026quot;Non, on ne revient pas à PHP 5 juste parce que tu as peur du changement\u0026quot; Allow-APT-Mark-Fallback Désactive l'auto-sélection de nouvelles versions \u0026quot;Touche pas à mes versions majeures, animal ! \u0026quot; 5.2.5 La liste noire de la honte (ou comment bannir les paquets problématiques) Placez vos paquets critiques sur la liste des indésirables avec cette configuration :\nUnattended-Upgrade::Blacklist { \u0026#34;php*\u0026#34;; \u0026#34;mariadb-server\u0026#34;; \u0026#34;postgresql*\u0026#34;; \u0026#34;nginx\u0026#34;; \u0026#34;apache2\u0026#34;; }; 5.3 Le plan de bataille pour les vrais professionnels 📌 Stratégie de survie en environnement de production :\nBloquez les versions majeures avec la configuration 5.2.4, à moins que vous n'aimiez les appels nocturnes Blacklistez impitoyablement tout ce qui fait tourner votre business avec l'option 5.2.5 Construisez un environnement de test identique - les vrais barbus testent AVANT, pas en production Planifiez vos mises à jour majeures comme des opérations militaires, avec des plans de repli Faites des backups complets avant toute mise à jour majeure, ou préparez votre CV ⚠️ Alerte rouge : Les mises à jour majeures automatiques sur des composants critiques, c'est comme jouer à la roulette russe avec le serveur de production - vous pourriez vous en sortir, mais est-ce vraiment un risque que vous voulez prendre ? Pour tout ce qui fait tourner votre business (PHP, bases de données, serveurs web), planifiez, testez, puis priez avant de mettre à jour.\n6. Entrer dans la matrice : surveillance et déblocage des catastrophes nocturnes 6.1 Les logs que personne ne lit jamais (jusqu\u0026rsquo;à ce que tout explose) Même avec l'automatisation, il faut surveiller ce que fait cette bête sauvage qu'est unattended-upgrades. Sinon, c'est comme laisser votre adolescent seul à la maison pendant le week-end - tôt ou tard, vous le regretterez. Voici les fichiers que vous prétendrez consulter régulièrement :\nFichier log Ce qu'il contient réellement Quand le lire (soyons honnêtes) /var/log/unattended-upgrades/unattended-upgrades.log Le journal de bord du capitaine automatique Quand votre patron demande \u0026quot;que s'est-il passé ?\u0026quot; /var/log/unattended-upgrades/unattended-upgrades-dpkg.log Ce que dpkg marmonne dans sa barbe Quand le premier log ne vous dit pas pourquoi tout a explosé /var/log/apt/history.log La preuve que quelqu'un a fait quelque chose Pour savoir QUI blâmer (spoiler : c'est toujours systemd) /var/log/apt/term.log Les mêmes informations qu'avant, mais en plus verbeux Pour les masochistes qui aiment lire 5000 lignes de texte /var/log/dpkg.log Chaque respiration de dpkg Pour les vrais barbus qui lisent les logs comme d'autres lisent Game of Thrones Les logs sont automagiquement comprimés et rotatés (.1, .2.gz, etc.). Voici comment faire semblant de les surveiller régulièrement :\nsudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log sudo grep -i \u0026#34;error\\|fail\\|warning\u0026#34; /var/log/unattended-upgrades/unattended-upgrades.log 6.2 Déclencher manuellement les mises à jour (pour le plaisir de voir quelque chose se casser en temps réel) Pour voir unattended-upgrades en action, comme si vous regardiez un documentaire animalier sur un prédateur dans son habitat naturel :\nsudo unattended-upgrade --dry-run --debug sudo unattended-upgrade --debug sudo unattended-upgrade -d 🧪 Preuve d'expertise technique : Utilisez --dry-run lors des démos pour vos collègues. Si ça fonctionne, prenez un air suffisant. Si ça plante, dites nonchalamment : \u0026quot;C'est exactement pourquoi j'utilise dry-run, voyez-vous\u0026quot;.\n6.3 Techniques de réanimation pour système bloqué (ou comment sauver votre journée) Quand votre système de mise à jour automatique s'arrête en position fœtale, voici la trousse d'urgence du barbu :\nsudo dpkg --audit sudo dpkg --configure --pending sudo apt-get -f install sudo apt-mark showhold Si votre système est bloqué par une question existentielle comme \u0026quot;Voulez-vous que PHP 8.3 devienne le nouveau PHP par défaut ?\u0026quot;, il est temps d'intervenir manuellement (comme arracher la manette des mains d'un enfant) :\nsudo dpkg --configure -a sudo dpkg-reconfigure php8.3-common ","date":"2025-05-08T14:03:19+02:00","image":"/debian-configuration-complete-dunattended-upgrades-pour-une-securite-sans-effort/cover.jpg","permalink":"/debian-configuration-complete-dunattended-upgrades-pour-une-securite-sans-effort/","title":"Debian : Configuration complète d’unattended-upgrades pour une sécurité sans effort"},{"content":"Lors de la mise en place de services web ou d'applications sur son réseau local, on se retrouve souvent confronté à un problème courant : comment accéder à ces services depuis l'intérieur du réseau en utilisant la même adresse que les utilisateurs externes ? C'est là qu'intervient le NAT Reflection dans OPNsense, une fonctionnalité puissante mais parfois mal comprise.\nDans cet article, nous allons voir comment configurer correctement les options du NAT Reflection pour permettre un accès transparent à vos services, que ce soit depuis l'extérieur ou l'intérieur de votre réseau.\nConfiguration des options du NAT Reflection Pour configurer le NAT Reflection dans OPNsense, suivez ces étapes :\nSe rendre dans Firewall (1), Settings (2), puis Advanced (3) Faire défiler jusqu'à la section Network Address Translation Deux options importantes sont à configurer :\nReflection for port forwards : Cette option permet aux clients du réseau local d'accéder aux services redirigés via l'adresse IP publique du pare-feu. Automatic outbound NAT for Reflection : Cette option configure automatiquement les règles NAT sortantes nécessaires pour le NAT Reflection. Cas d\u0026rsquo;utilisation Le NAT Reflection est particulièrement utile dans plusieurs scénarios :\nHébergement d'un serveur web accessible via un nom de domaine Services internes nécessitant une URL cohérente (interne/externe) Applications utilisant des redirections de ports Par exemple, si vous hébergez un site web monsite.com qui pointe vers votre IP publique, le NAT Reflection permettra aux utilisateurs internes d'accéder au site via monsite.com au lieu d'utiliser une adresse IP locale.\nPoints d\u0026rsquo;attention Quelques points importants à garder à l'esprit :\nLe NAT Reflection peut légèrement impacter les performances du pare-feu Activez ces options uniquement si nécessaire Vérifiez régulièrement les logs pour détecter d'éventuelles anomalies Utilisez des règles de pare-feu strictes pour contrôler l'accès Application des changements Une fois les options configurées :\nCliquer sur Save en bas de la page Appliquer les changements en cliquant sur Apply Tester l'accès à vos services depuis le réseau local Conclusion Le NAT Reflection est une fonctionnalité essentielle d'OPNsense qui, une fois correctement configurée, permet une gestion transparente des services hébergés. Les deux options présentées ici simplifient grandement sa mise en œuvre tout en maintenant la sécurité du réseau.\nN'hésitez pas à activer ces options si vous avez besoin d'accéder à vos services hébergés via l'adresse IP publique depuis votre réseau local. Cependant, gardez toujours à l'esprit l'impact potentiel sur la sécurité et surveillez régulièrement votre configuration.\n","date":"2025-02-08T16:23:40+01:00","image":"/opnsense-configuration-du-nat-reflection/cover.jpg","permalink":"/opnsense-configuration-du-nat-reflection/","title":"OPNsense : Configuration du NAT Reflection"},{"content":"Introduction Aujourd'hui, je vous embarque à bord de mon voyage, ce voyage consiste à progressivement remplacer mes conteneurs Docker par des services Kubernetes dans mon homelab.\nPourquoi ce changement ?\nCar étant encore étudiant et en plein dans le sujet, quoi de mieux que de mettre les mains dans le camboui ?\nPréparation La cible Parmi la liste des applications que je dois migrer, j'ai dû en choisir une, et Mealie a été l'heureuse gagnante.\nC'est quoi Mealie ? Mealie est un gestionnaire de recettes de cuisine accessible via navigateur, entièrement self hosté.\nL\u0026rsquo;existant --- services: mealie: image: ghcr.io/mealie-recipes/mealie:latest container_name: mealie-front-01 restart: always networks: - mealie-network - reverse-proxy labels: - traefik.enable=true - traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto=https - traefik.http.routers.mealie-https.entrypoints=https - traefik.http.routers.mealie-https.rule=Host(`mealie.homelab.domain.fr`) volumes: - mealie-vol:/app/data/ env_file: - /opt/docker/apps/mealie/stack.env networks: reverse-proxy: external: true mealie-network: {} volumes: mealie-vol: {} Ci-haut, vous pouvez voir le yaml docker-compose ayant servi à créer mon conteneur Mealie.\nNous pouvons y observer:\nUne image en tag latest (on ne juge pas !). 2 Réseaux alloués mealie-network étant le réseau propre de cette stack. reverse-proxy permettant de relier le conteneur au conteneur Reverse Proxy traefik, permettant d'exposer Mealie et de lui attribuer un Certificat Let's Encrypt. Des labels: Des middlewares classiques pour sécuriser l'accès au service Mealie. Deux routeurs, un https pour forcer le port d'entrée sur le 443 et un routeur pour attribuer un hostname au conteneur. Un volume Docker monté sur le chemin /app/data du conteneur Un fichier d'environnement contenant toutes les clés-valeurs requises pour que Mealie fonctionne. Le port d'exposition du Conteneur dans le pod (ici, 9000) La migration Maintenant que nous avons décortiqué les éléments présents, il va falloir les traduire en manifests Kubernetes.\nLes manifests Kubernetes sont des fichiers yaml déclaratif qui vont dire à Kubernetes comment on veut que notre application soit déployée.\nIl est important de noter que mes volumes sont provisonnés sur mon TrueNAS Scale grâce à une StorageClass via le protocole NFS, contrairement à Docker, où les volumes étaient stockés en local.\nMealie étant une application tournant sur du LiteSQL, le site de l'application ne recommande pas de faire du LiteSQL avec du NFS, j'ai donc dû opter pour une PostgreSQL dédiée.\n(Petite information, il existe un binaire nommé kompose qui permet de faire une traduction d'un fichier docker-compose en manifests yaml, mais ça s'appelle enlever le fun de la découverte.)\nReprenons notre liste à puce de la partie précédente.\nIl nous faut:\nIl nous faut un objet de type Deployment, il va servir à déployer les Pods avec des configuration que j'aurais définie.\nCe manifest yaml contiendra:\nL'image Docker de Mealie (On enlève le tag latest, c'est risqué de pointer sur un tag d'image en mouvement perpétuel). Le nombre de Replicas du pod (Un replica est une copie d'un pod, si l'un tombe l'autre prend la relève, sert aussi de loadbalancing en cas de workload important). Un appel à des clés-valeurs d'une Configmap, qui est un objet contenant ici mes variables d'environnement. Un appel a des clés-valeurs d'un Secret, qui est un objet qui contient ici les mots de passe de la base de donnée PostgreSQL. Un appel à un PersistentVolumeClaim, qui lui même est lié à un PersistentVolume qui sera monté sur app/data nous reviendrons plus tard dessus, mais retenez que c'est le volume. Un objet de type StatefulSet pour déployer la base de donnée.\nLe StatefulSet fonctionne presque exactement comme un Deployment, mais il est fait pour les services type stateful, les pods sont identifiés et non-interchangeable.\nEnsuite, on va avoir besoin de créer les objets Configmap et Secret.\nCes objets permettent de stocker sous forme de clé-valeur des informations, que ce soit des variables d'environnement, des arguments de commande, etc.., ils peuvent ensuite être consommés par des pods.\nLa différence entre un Secret et une Configmap réside dans le fait que les Secrets sont encodés en base64, et sont fait pour contenir des données sensibles.\nExemple d'une configmap:\n--- apiVersion: v1 kind: ConfigMap metadata: name: mealie-configmap namespace: mealie data: ALLOW_SIGNUP: \u0026#34;false\u0026#34; TZ: \u0026#34;Europe/Paris\u0026#34; DB_ENGINE: \u0026#34;postgres\u0026#34; POSTGRES_USER: admin Pour que les pods puissent communiquer entre eux ET que le pod du front web soit disponible dehors, il nous faut des objets de type Services.\nLes Services permettent d'exposer un ou plusieurs pods, car les pods de nature sont amenés à être détruits et recréés, et leur IP changent également.\nLa logique d'un service fonctionne donc comme ça:\nLes Pods ont des labels sous forme de clé valeur --\u0026gt; Les Services qui ont une IP statique visent ces labels, et sont donc attribués à ces pods, le service peut même faire du LoadBalancing entre les pods qu'il expose.\nUn service au minimum demande:\nLe protocole du port qu'on va exposer (TCP ou UDP). Le port que le Service expose (donc son propre port). Le port du conteneur que le Service va viser. Pour nos besoins, il faudra créer un service pour exposer la base de donnée et un service pour exposer le front.\nPour les volumes, il faut faire une introduction aux PersistentVolumes (PV) et aux PersistentVolumeClaims (PVC).\nUn PV est un volume de stockage défini provisionné manuellement ou dynamiquement (via une StorageClass).\nLe PVC quant à lui est une requête pour consommer un PV.\nDans mon cas à moi, j'utilise une StorageClass qui est issue du CSI (Container Storage Interface) DemocraticCSI, ça me permet de créer un CSIDriver spécifiquement fait pour interagir avec l'API de TrueNAS, afin de provisionner des PV stockés sur un Dataset ZFS via le protocole NFS.\nIl nous faut donc 2 volumes: Le premier sera monté sur le app/data du front de Mealie, il stockera les Metadata du front, et fera 1Gi. Le deuxième sera le volume de la base de donnée PostgreSQL, ce dernier ne sera pas défini dans son propre manifest yaml mais directement dans le manifest du StatefulSet. Nous en avons terminé avec les objets qui constituent l'application en elle-même, pour finir il nous faut un objet de type Ingress.\nUn Ingress c'est un objet créé par un IngressController, vous connaissez surement quelques noms connus d'IngressController: Nginx, Traefik, HAProxy, par exemple, pour ma part, j'utilise Traefik car je m'en servais déjà sur Docker.\nUn Ingress est un Reverse Proxy et LoadBalancer de couche 7, il agit comme un point d'entrée pour des routes HTTP et HTTPS et redirige les requêtes selon les règles qu'il contient, par exemple, il peut rediriger une requête vers un objet de type service précis, lui même redirigeant à un pod , dépendant de l'URL (machin.fr/app qui redirige au service app).\nIl peut également gérer plusieurs noms de domaine, utiliser des headers de sécurité et implémenter un certificat SSL/TLS.\nNormalement, il faudrait créer un objet de type certificat contenu dans un Secret Kubernetes et appeler ce secret dans le manifest de l'Ingress, mais comme j'utilise Cert-Manager qui est relié à mon domaine dans Cloudflare, je n'ai qu'à rajouter une annotation dans l'objet pour faire une requête de Certificat Let's Encrypt.\nJe ne rentrerais pas en détail dans le sujet de Cert-Manager, cependant, voici la documentation officielle du projet. Construction . └── base ├── kustomization.yaml ├── mealie-configmap.yaml ├── mealie-db-service.yaml ├── mealie-deployment.yaml ├── mealie-pvc.yaml ├── mealie-secret.yaml ├── mealie-statefulset.yaml ├── mealie-ingressroute.yaml └── mealie-web-service.yaml Bon, appliquer tous ces fichiers yaml à la main, ça serait VRAIMENT pénible.\nComment faire pour tout faire d'un coup ?\nAvec la commande CLI builtin et les manifests Kustomize.\nVoici un exemple d'un manifest kustomize:\n--- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - mealie-deployment.yaml - mealie-statefulset.yaml - mealie-secret.yaml - mealie-web-service.yaml - mealie-db-service.yaml - mealie-ingressroute.yaml - mealie-configmap.yaml - mealie-pvc.yaml Pour appliquer ce fichier il faut lancer la commande kubectl apply -k ./base, le -k spécifie qu'on vise un manifest kustomize.\nKustomize va donc appeler chaque manifest yaml de la liste définie dans resources et les appliquer un à un dans Kubernetes.\nOn peut faire des choses très utiles avec Kustomize, mais ce n'est pas le but de l'article. Néamoins, Voici un article en parlant.\nConclusion Et voilà ! À table !\nAu final si jamais vous vous posez la question, est-ce que vous devez utiliser Kubernetes ou Docker dans votre homelab, sachez une chose.\nUtiliser Docker est vraiment vraiment plus simple dans un petit environnement, quel intérêt d'utiliser Kubernetes ?\nApprendre et évoluer ! Bien sûr c'est suffisant d'utiliser Docker, mais Kubernetes apporte son lot d'avantage, de satisfaction, (de soirée perdues).\n","date":"2025-02-06T08:30:54+01:00","image":"/deployer-une-application-sur-kubernetes/cover.png","permalink":"/deployer-une-application-sur-kubernetes/","title":"Déployer une application sur Kubernetes"},{"content":"Préambule Envie de libérer Britney ? Ou plutôt... votre swap ? 🎵\nSi vous cherchez à optimiser l'utilisation de votre mémoire virtuelle sur une machine Debian, vous êtes au bon endroit !\nLe swappiness, c\u0026rsquo;est quoi ? Le swappiness est un paramètre du kernel Linux qui contrôle la \u0026quot;proportion\u0026quot; du système à utiliser le swap. Une valeur faible favorise l'utilisation de la RAM, tandis qu'une valeur élevée incite à swapper rapidement sur le disque.\nQuelques commandes essentielles 1. Vérifier la valeur actuelle du swappiness cat /proc/sys/vm/swappiness 2. Modifier dynamiquement le swappiness sudo sysctl vm.swappiness=20 ⚠️ Cette modification n'est pas persistante et sera perdue au redémarrage.\n3. Rendre la configuration persistante Ajoutez ou modifiez la ligne suivante dans /etc/sysctl.conf :\nvm.swappiness=20 Appliquez ensuite la configuration :\nsudo sysctl -p 4. Comprendre les valeurs du swappiness 100 : Le système swap intensément. 0 : Swap uniquement en cas de RAM complètement saturée. Défaut : Généralement 60 sur Debian. 5. Désactiver et réactiver le swap sudo swapoff -a \u0026amp;\u0026amp; sudo swapon -a ⚠️ Assurez-vous que la RAM disponible est suffisante pour accueillir les données du swap avant de désactiver ce dernier.\n6. Identifier les processus utilisant le swap Pour examiner les processus gourmands en swap, utilisez cette commande :\nfor file in /proc/*/status ; do \\ awk \u0026#39;/VmSwap|Name/{printf $2 \u0026#34; \u0026#34; $3}END{ print \u0026#34;\u0026#34;}\u0026#39; $file; \\ done | \\ sort -k 2 -n -r | less Automatisation avec un script Bash Pour simplifier la gestion du swap, voici un script bash prêt à l'emploi :\nScript : free-swap.sh #!/bin/bash check_command() { if [[ $? -ne 0 ]]; then echo \u0026#34;Erreur lors de l\u0026#39;exécution de la commande: $1\u0026#34; exit 1 fi } free_data=$(free) check_command \u0026#34;free\u0026#34; mem_data=$(echo \u0026#34;$free_data\u0026#34; | grep \u0026#39;Mem:\u0026#39;) free_mem=$(echo \u0026#34;$mem_data\u0026#34; | awk \u0026#39;{print $4}\u0026#39;) buffers=$(echo \u0026#34;$mem_data\u0026#34; | awk \u0026#39;{print $6}\u0026#39;) cache=$(echo \u0026#34;$mem_data\u0026#34; | awk \u0026#39;{print $7}\u0026#39;) total_free=$((free_mem + buffers + cache)) if echo \u0026#34;$free_data\u0026#34; | grep -q \u0026#39;Échange:\u0026#39;; then used_swap=$(echo \u0026#34;$free_data\u0026#34; | grep \u0026#39;Échange:\u0026#39; | awk \u0026#39;{print $3}\u0026#39;) else used_swap=$(echo \u0026#34;$free_data\u0026#34; | grep \u0026#39;Swap:\u0026#39; | awk \u0026#39;{print $3}\u0026#39;) fi echo -e \u0026#34;Free memory:\\t$total_free kB ($((total_free / 1024)) MB)\\nUsed swap:\\t$used_swap kB ($((used_swap / 1024)) MB)\u0026#34; if [[ $used_swap -eq 0 ]]; then echo \u0026#34;Félicitations ! Aucun swap n\u0026#39;est utilisé.\u0026#34; elif [[ $used_swap -lt $total_free ]]; then echo \u0026#34;Libération du swap...\u0026#34; sudo swapoff -a check_command \u0026#34;swapoff\u0026#34; sudo swapon -a check_command \u0026#34;swapon\u0026#34; else echo \u0026#34;Pas assez de mémoire libre pour libérer le swap. Arrêt.\u0026#34; exit 1 fi Instructions : Enregistrez le script dans un fichier, par exemple : free-swap.sh. Rendez-le exécutable : chmod u+x free-swap.sh Exécutez-le : ./free-swap.sh ⚠️ Ne pas utiliser ce script si ZRAM est activé sur votre système, car cela pourrait entraîner des comportements inattendus.\nConclusion Vous venez de découvrir comment optimiser la gestion du swap sous Debian. Que ce soit via des commandes ou un script Bash, vous êtes désormais armé pour reprendre le contrôle de votre mémoire virtuelle.\nEt surtout, souvenez-vous : le swap, c'est bien... mais la RAM, c'est mieux ! 😉\n","date":"2024-12-01T06:09:15+01:00","image":"/liberez-votre-swap/cover.png","permalink":"/liberez-votre-swap/","title":"Libérez votre swap !"},{"content":"Dans un monde où les pertes de données peuvent avoir des conséquences catastrophiques, que ce soit pour des entreprises, des gouvernements, ou des individus, il devient impératif de prendre des mesures pour sécuriser ses informations. Une perte de données peut entraîner des interruptions de services, voire des pertes financières importantes.\nFace à cette réalité, la mise en place d’une stratégie de sauvegarde robuste devient essentielle. Dans cet article, nous allons explorer une solution pratique et accessible à tous : Restic. Cet outil, à la fois rapide, fiable et facile à configurer, permet de créer des sauvegardes cryptées et décentralisées, tout en offrant la possibilité de gérer facilement les anciennes versions de fichiers et d'automatiser le processus.\nVoyons maintenant comment mettre en place un script de sauvegarde avec Restic, en tenant compte de quelques bonnes pratiques essentielles pour une gestion sécurisée et automatisée des données.\nJe commence par définir les variables essentielles de son script, qui permettront de personnaliser la sauvegarde en fonction de mes besoins spécifiques.\n#!/bin/bash export RESTIC_PASSWORD=\u0026#39;ZZZZZZZZZZZZ\u0026#39; export RESTIC_REPO=\u0026#39;/mnt/restic\u0026#39; export BACKUP_TARGET=\u0026#39;.\u0026#39; export BACKUP_SOURCE=\u0026#39;/mnt/shared/nas\u0026#39; NUM_KEEP_SNAPSHOTS=15 RESTIC_PASSWORD : Cette variable contient le mot de passe nécessaire à l'accès au dépôt Restic. Ce mot de passe est utilisé pour chiffrer et déchiffrer les données sauvegardées.\nRESTIC_REPO : Le répertoire où les sauvegardes seront stockées. Cela peut être un stockage local ou distant (par exemple, un serveur S3 ou un serveur FTP).\nBACKUP_TARGET : La destination de la sauvegarde.\nBACKUP_SOURCE : La source des fichiers à sauvegarder, ici /mnt/shared/nas, qui est un répertoire contenant des fichiers critiques.\nNUM_KEEP_SNAPSHOTS : Le nombre de sauvegardes à conserver. Ce paramètre est essentiel pour éviter l'accumulation excessive de données, ce qui pourrait entraîner un encombrement du système.\nL'une des premières étapes de mon script consiste à sauvegarder les bases de données. Étant donné que les bases de données peuvent contenir des informations sensibles et cruciales, il est primordial de m'assurer qu'elles sont bien incluses dans mes sauvegardes.\nCependant, je sais que mes bases de données ne sont enrichies que les jours de semaine, c'est-à-dire du lundi au vendredi. Il n'a donc pas de sens de créer un dump de la base de données pendant le week-end, lorsque les données ne sont pas mises à jour. C'est pourquoi j'ai décidé de ne créer un dump de la base de données que durant les jours ouvrés, afin d'éviter une sauvegarde inutile et de préserver des ressources.\nDB_HOST=\u0026#34;localhost\u0026#34; DB_PORT=\u0026#34;5432\u0026#34; DB_USER=\u0026#34;estx50\u0026#34; DB_DUMP_PATH=\u0026#34;/mnt/shared/nas/Trading/all_databases_backup.sql\u0026#34; export PGPASSWORD=\u0026#39;XXXXXXXXXXXXXX\u0026#39; DAY_OF_WEEK=$(date +%u) if [[ \u0026#34;$DAY_OF_WEEK\u0026#34; -ge 1 \u0026amp;\u0026amp; \u0026#34;$DAY_OF_WEEK\u0026#34; -le 5 ]]; then echo \u0026#34;Jour de semaine - Création du dump de la base de données.\u0026#34; pg_dumpall -h \u0026#34;$DB_HOST\u0026#34; -p \u0026#34;$DB_PORT\u0026#34; -U \u0026#34;$DB_USER\u0026#34; \u0026gt; \u0026#34;$DB_DUMP_PATH\u0026#34; || exit 1 else echo \u0026#34;Aujourd\u0026#39;hui est le week-end, aucun dump de la base de données ne sera créé.\u0026#34; fi sleep 10 Une fois la base de données sauvegardée, je me tourne vers la sauvegarde de mes fichiers. Restic permet de sauvegarder facilement des répertoires et d'exclure certains fichiers ou dossiers.\nJ'ai décidé d'exclure certains répertoires spécifiques, comme récupération_Oscar et Trading/data, car ils contiennent des données que je ne souhaite pas inclure dans la sauvegarde, parce qu'elles ne sont pas pertinentes pour mes besoins de sauvegarde.\ncd \u0026#34;$BACKUP_SOURCE\u0026#34; \u0026amp;\u0026amp; restic -r \u0026#34;$RESTIC_REPO\u0026#34; backup --exclude \u0026#34;/mnt/shared/nas/récupération_Oscar\u0026#34; --exclude \u0026#34;/mnt/shared/nas/Trading/data\u0026#34; \u0026#34;$BACKUP_TARGET\u0026#34; --skip-if-unchanged || exit 1 Remarque importante\nVous noterez que les exclude requièrent le chemin absolu.\nskip-if-unchanged:\nCette option permet à Restic de vérifier si les fichiers ont changé avant de créer un nouveau snapshot. Si un fichier n'a pas été modifié depuis la dernière sauvegarde, Restic évite de le sauvegarder à nouveau. Cela permet de réduire le volume des données sauvegardées et d'économiser de l'espace disque.\nUne fois les sauvegardes effectuées, je dois gérer les anciens snapshots pour éviter que mon dépôt de sauvegarde ne devienne trop encombré. Pour cela, j'utilise la commande forget, qui permet de supprimer les snapshots anciens et inutiles. J'ai choisi de conserver un nombre limité de snapshots récents — ici, 15 — afin de m'assurer que je dispose toujours d'un historique suffisant, sans accumuler trop de données obsolètes.\nrestic -r \u0026#34;$RESTIC_REPO\u0026#34; forget --keep-last \u0026#34;$NUM_KEEP_SNAPSHOTS\u0026#34; --keep-tag preserve --prune || exit 1 --keep-last $NUM_KEEP_SNAPSHOTS : Cette option permet de définir le nombre de snapshots récents à conserver. Par exemple, si vous gardez 15 snapshots, seuls les 15 derniers seront conservés.\nJ'utilise également l'option --prune pour nettoyer les points de sauvegarde qui ne sont plus nécessaires, ce qui permet de récupérer de l'espace disque et de garder le dépôt de sauvegarde bien organisé.\nEnfin dernier point à noter : j'ai utilisé l'option --keep-tag preserve dans ma commande de nettoyage. En effet, il y a un point de sauvegarde que je ne veux en aucun cas voir supprimé lors des nettoyages. Pour cela, j'ai préalablement tagué ce snapshot avec la commande restic tag, ce qui me permet de l'identifier spécifiquement.\nrestic -r [RESTIC_REPO] tag [ID_SNAPSHOT] preserve La commande restic tag permet d'ajouter un tag personnalisé à un snapshot (dans mon cas je l'ai apppelé preserve), ce qui peut être très utile pour marquer des sauvegardes importantes ou spécifiques. Ainsi, le snapshot marqué avec le tag preserve restera dans le dépôt, grâce à --keep-tag preserve même lorsque je lance le nettoyage avec l'option --prune, qui supprimera tout autre snapshot plus ancien.\nConclusion : Un Outil de Sauvegarde Puissant\nEn appliquant ces pratiques, j'ai réussi à mettre en place une solution de sauvegarde fiable, efficace et parfaitement adaptée à mes besoins. L'automatisation de la sauvegarde de mes fichiers et bases de données, combinée à une gestion rigoureuse des anciens snapshots, me permet de garantir une protection optimale de mes données.\nDans le prochain épisode, je me pencherai sur l'utilisation de Restic pour stocker mes sauvegardes sur un espace S3 Amazon. Ce choix m'offrira encore plus de sécurité et de flexibilité pour mes sauvegardes, tout en ajoutant une couche de fiabilité supplémentaire.\n","date":"2024-11-11T13:55:45+01:00","image":"/restic-ou-limportance-des-sauvegardes-de-donnees/cover.png","permalink":"/restic-ou-limportance-des-sauvegardes-de-donnees/","title":"Restic ou l’Importance des Sauvegardes de Données"},{"content":"Préambule Il était une fois, dans le royaume du développement, un développeur nommé John. En plein milieu d'un projet complexe, qui impliquait des fichiers de configuration .env et .yaml pour se connecter à une API tournant dans un conteneur Docker, John a commis l'impensable : il a ouvert un dépôt contenant une clé API Mailgun en clair dans un fichier .env utilisé pour la configuration du docker compose.\nÀ peine avait-il réalisé son erreur qu'un désastre s'annonçait. Non seulement sa clé d'API avait été compromise, mais son compte Mailgun avait également été coupé, le plongeant dans un tourbillon de préoccupations. Une procédure rigoureuse devait être suivie pour le réactiver, impliquant la réinitialisation des mots de passe et des clés d'API. Une perte de temps énorme qui plongea notre petit John dans une énorme tristesse.\nFace à l'urgence de partager son code Python avec un autre développeur pour résoudre un problème pressant, John a décidé d'agir. Bien que la meilleure solution aurait été de monter un vault sécurisé, le temps pressait. Il a donc opté pour un mécanisme de nettoyage et de restauration connu sous le nom de \u0026quot;smudge and clean\u0026quot;.\nLes faits Il a ajouté dans le fichier .git/config de son projet, les lignes suivantes :\n[filter \u0026#34;secrets\u0026#34;] clean = ../scripts/filter-secrets.sh clean smudge = ../scripts/filter-secrets.sh smudge Ces lignes indiquaient à Git d'utiliser son script de filtrage chaque fois qu'il push ou pull des commits. Dans ce script, il a employé sed pour remplacer sa clé API par une phrase humoristique, de sorte qu'elle ne soit jamais exposée dans le dépôt.\nFilter secrets Le script de filtrage filter-secrets.sh en question ressemblait à cela : #!/bin/bash if [ \u0026#34;$1\u0026#34; == \u0026#34;clean\u0026#34; ]; then # Clean (replace sensitive data with placeholders) sed -e \u0026#39;s/XXXXXXXXX/{API_KEY_PLACEHOLDER}/g\u0026#39; \\ -e \u0026#39;s/YYYYYYYYY/{SENDING_API_KEY_PLACEHOLDER}/g\u0026#39; \\ -e \u0026#39;s/ZZZZZZZZZ/{SMTP_PASSWORD_PLACEHOLDER}/g\u0026#39; \\ -e \u0026#39;s/AAAAAAAAA/{POSTGRES_PASSWORD_PLACEHOLDER}/g\u0026#39; \\ -e \u0026#39;s/BBBBBBBBB/{TWS_USERID_PLACEHOLDER}/g\u0026#39; \\ -e \u0026#39;s/CCCCCCCCCC/{TWS_PASSWORD_PLACEHOLDER}/g\u0026#39; # Si une erreur se produit avec sed, renvoyer un code d\u0026#39;erreur if [ $? -ne 0 ]; then echo \u0026#34;Erreur lors de l\u0026#39;exécution du clean\u0026#34; exit 1 fi elif [ \u0026#34;$1\u0026#34; == \u0026#34;smudge\u0026#34; ]; then # Smudge (replace placeholders with sensitive data) sed -e \u0026#39;s/{API_KEY_PLACEHOLDER}/XXXXXXXXX/g\u0026#39; \\ -e \u0026#39;s/{SENDING_API_KEY_PLACEHOLDER}/YYYYYYYYY/g\u0026#39; \\ -e \u0026#39;s/{SMTP_PASSWORD_PLACEHOLDER}/ZZZZZZZZZ/g\u0026#39; \\ -e \u0026#39;s/{POSTGRES_PASSWORD_PLACEHOLDER}/AAAAAAAAA/g\u0026#39; \\ -e \u0026#39;s/{TWS_USERID_PLACEHOLDER}/BBBBBBBBB/g\u0026#39; \\ -e \u0026#39;s/{TWS_PASSWORD_PLACEHOLDER}/CCCCCCCCCC/g\u0026#39; if [ $? -ne 0 ]; then echo \u0026#34;Erreur lors de l\u0026#39;exécution du smudge\u0026#34; exit 1 fi fi exit 0 Les attributs Pour finaliser le tout, il a modifié un fichier .git/info/attributes où il a défini quels fichiers de configuration devaient passer par ce filtre :\nconfig.yaml filter=secrets .env filter=secrets Conclusion Grâce à son ingéniosité, John a pu collaborer sur son projet sans craindre pour la sécurité de ses informations sensibles en se donnant le temps de monter proprement un Vault. À la fin de la journée, il avait non seulement corrigé son erreur, mais aussi appris à jongler avec la sécurité dans le monde des dépôts Git. Et c'est ainsi qu'il a vécu heureux, protégé de la menace des fuites de secrets, et avec un compte Mailgun réactivé, prêt à affronter de nouveaux défis.\n","date":"2024-10-27T23:36:07+01:00","image":"/git-how-to-smudge-and-clean/cover.png","permalink":"/git-how-to-smudge-and-clean/","title":"Git : How to smudge and clean ?"},{"content":"Introduction Prenons le cas de l'utilisation de CrowdSec pour protéger des applications web en analysant les logs du reverse-proxy.\nSuivant le scénario qui se déclenchera, CrowdSec prendra une décision concernant l'adresse IP concernée. Par exemple, renvoyer un code HTTP 403. Dans ce cas de figure, si l'acteur malveillant persiste, une décision sera prise à chaque fois. Si des notifications sont envoyées à chaque prise de décision, cela peut vite devenir du spam ! C'est le comportement normal puisque le profil par défaut de CrowdSec prend une décision à chaque déclenchement de scénario.\nNous allons voir comment modifier la prise de décision pour vérifier au préalable si une décision identique n'a pas été prise récemment.\nPrérequis CrowdSec installé (voir ici : Installation de CrowdSec) Toutes les commandes / manipulations présentées ci-dessous seront à exécuter en tant que root. Modification de la Remediation Tout va se passer dans un seul fichier : /etc/crowdsec/profiles.yaml\nVoici un fichier classique qui ban pendant 4h l'adresse IP qui déclenche un scénario : #/etc/crowdsec/profiles.yaml name: default_ip_remediation filters: - Alert.Remediation == true \u0026amp;\u0026amp; Alert.GetScope() == \u0026#34;Ip\u0026#34; decisions: - type: ban duration: 4h #duration_expr: \u0026#34;Sprintf(\u0026#39;%dh\u0026#39;, (GetDecisionsCount(Alert.GetValue()) + 1) * 4)\u0026#34; on_success: break Nous allons modifier le filtre pour vérifier si une décision n'a pas été prise il y a moins de 2h pour l'adresse IP concernée.\nVoici le fichier modifié : #/etc/crowdsec/profiles.yaml name: default_ip_remediation filters: - Alert.Remediation == true \u0026amp;\u0026amp; Alert.GetScope() == \u0026#34;Ip\u0026#34; \u0026amp;\u0026amp; GetDecisionsSinceCount(Alert.GetValue(), \u0026#34;2h\u0026#34;) \u0026lt; 1 decisions: - type: ban duration: 4h #duration_expr: \u0026#34;Sprintf(\u0026#39;%dh\u0026#39;, (GetDecisionsCount(Alert.GetValue()) + 1) * 4)\u0026#34; on_success: break Pour valider la modification, redémarrez le service :\nsystemctl restart crowdsec Intérêt On peut se dire : Mais pourquoi faire ça ?\nA chaque fois que CrowdSec prendra une décision, si les notifications sont configurées, cela en déclenchera une systématiquement.\nDans mon cas, cela concernait les scans multi-ports et j'en avais marre de recevoir du spam de notification... (Effet JO 2024 ???).\nVoici l'output que cela donnait en moins d'une minute :\nConclusion Maintenant, CrowdSec prendra une décision concernant l'adresse IP qui déclenchera un scénario et qui n'a pas été ban il y a moins de 2h. Si celle-ci revient au bout de 3h et redéclenche un scénario, ça sera reparti pour 4h, etc.\n","date":"2024-08-07T10:52:44+02:00","image":"/crowdsec-avoid-a-duplicate-decision-notification/cover.png","permalink":"/crowdsec-avoid-a-duplicate-decision-notification/","title":"CrowdSec : Avoid a Duplicate Decision / Notification"},{"content":"Introduction Ce guide explique comment protéger l'authentification sur Gitlab contre les attaques de Bruteforce à l'aide de CrowdSec. Il est essentiel de sécuriser un portail d'authentification web. Une nouvelle collection crowdsec, comprenant 1 parser et 1 scénario, sera installée.\nCe guide se base sur une installation de Gitlab sur Debian 12. La version Gitlab utilisée est la dernière en date (17.2.0).\nPrérequis Une machine Debian 12 avec un accès root ou sudo. Toutes les commandes présentées ci-dessous seront à exécuter en tant que root. Une connexion internet active. Gitlab CE ou EE installé CrowdSec installé (voir ici : Installation de CrowdSec) Modification du port de l\u0026rsquo;API CrowdSec Très important !\nAvec une installation standard de Gitlab, le serveur PUMA (serveur web ruby faisant partie de gitlab) écoute sur le port TCP 8080. Il est donc impératif de modifier le port d'écoute de l'API de CrowdSec pour éviter tout conflit.\nProcédure décrite [ici]\nVérifiez bien que vos services crowdsec fonctionnent correctement :\njournalctl -u crowdsec journalctl -u crowdsec-firewall-bouncer Installation de la collection pour gitlab En navigant sur le hub de CrowdSec, une collection pour gitlab est disponible.\nInstaller la collection :\ncscli collections install timokoessler/gitlab Ceci a pour effet d'installer 1 parser et 1 scénario.\nLister les parsers :\ncscli parsers list # timokoessler/gitlab-logs ✔️ enabled 0.1 /etc/crowdsec/parsers/s01-parse/gitlab-logs.yaml Lister les sénarios :\ncscli scenario list # timokoessler/gitlab-bf ✔️ enabled 0.2 /etc/crowdsec/scenarios/gitlab-bf.yaml Création du fichier d\u0026rsquo;acquisition Afin que le parser Gitlab puisse être utilisé, il faut définir la méthode d'acquisition.\nCréez le fichier /etc/crowdsec/acquis.d/gitlab.yaml avec le contenu suivant : --- filenames: - /var/log/gitlab/gitlab-rails/production_json.log labels: type: gitlab Redémarrage du service A présent, le service crowdsec peut être rechargé :\nsystemctl reload crowdsec Vérification Nous allons vérifier le fonctionnement du parser et du nouveau scénario dédié à gitlab.\nPour cela, spammez la page de login de Gitlab, puis vérifiez les résultats :\nAlertes : cscli alerts list # 2 │ Ip:66.66.66.66 │ timokoessler/gitlab-bf │ │ │ ban:1 │ 2024-07-19 07:56:48.649063483 +0000 UTC Décisions : cscli decisions list # 15001 │ crowdsec │ Ip:66.66.66.66 │ timokoessler/gitlab-bf │ ban │ │ │ 6 │ 3h59m43.261827214s │ 2 Conclusion En suivant ce guide, vous avez sécurisé l'authentification de votre Gitlab contre les attaques de Bruteforce grâce à CrowdSec. ","date":"2024-07-19T11:06:58+02:00","image":"/crowdsec-proteger-lauthentification-gitlab/cover.png","permalink":"/crowdsec-proteger-lauthentification-gitlab/","title":"CrowdSec : Protéger l’authentification Gitlab"},{"content":"Introduction Ce guide explique comment protéger l'authentification sur Proxmox contre les attaques de Bruteforce à l'aide de CrowdSec. Suite aux dernières actualités de VMware, de nombreux utilisateurs ont migré vers Proxmox. Il est donc essentiel de sécuriser le portail d'authentification, exposé par défaut sur le port TCP 8006.\nCe guide se base sur une installation de Proxmox sur Debian 12. Par défaut, rsyslog n'est plus installé sur Debian 12. Nous verrons comment configurer cela avec journald mais également avec rsyslog si besoin.\nPrérequis Une machine Debian 12 avec un accès root ou sudo. Toutes les commandes présentées ci-dessous seront à exécuter en tant que root. Une connexion internet active. Proxmox installé CrowdSec installé (voir ici : Installation de CrowdSec) Installation de la collection pour proxmox En navigant sur le hub de CrowdSec, une collection pour proxmox est disponible.\nInstaller la collection :\ncscli collections install fulljackz/proxmox Ceci a pour effet d'installer 2 parsers et 1 scénario.\nLister les parsers :\ncscli parsers list # crowdsecurity/syslog-logs ✔️ enabled 0.8 /etc/crowdsec/parsers/s00-raw/syslog-logs.yaml # fulljackz/proxmox-logs ✔️ enabled 0.2 /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml Lister les sénarios :\ncscli scenario list # fulljackz/proxmox-bf ✔️ enabled 0.2 /etc/crowdsec/scenarios/proxmox-bf.yaml Pour que ceux-ci soient pris en compte, le service CrowdSec doit être rechargé. Nous le ferons après quelques modifications.\nModification du parser proxmox Le parser spécifique à proxmox se situe ici : /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml\nPour qu'il soit compatible avec la dernière version de Proxmox, nous allons l'éditer et apporter les modifications suivantes :\npattern_syntax: PVE_AUTH_FAIL: \u0026#39;authentication failure; rhost=::ffff:%{IP:client_ip} user=%{USERNAME:source_user}@%{WORD:realm} msg=\u0026#39; Ajout : ::ffff:\nCréation du fichier d\u0026rsquo;acquisition Afin que le parser Proxmox puisse être utilisé, il faut définir la méthode d'acquisition.\nUtilisation avec journald Pour utiliser le parser avec journald :\nCréez le fichier /etc/crowdsec/acquis.d/proxmox.yaml avec le contenu suivant : journalctl_filter: - _SYSTEMD_UNIT=pvedaemon.service labels: type: syslog Utilisation avec rsyslog Si vous préférez utiliser rsyslog avec le fichier de log /var/log/syslog :\nInstallez rsyslog si ce n'est pas déjà fait :\napt install -y rsyslog Créez le fichier /etc/crowdsec/acquis.d/proxmox.yaml avec le contenu suivant :\n--- filenames: - /var/log/syslog labels: type: pvedaemon Redémarrage du service A présent, le service crowdsec peut être rechargé :\nsystemctl reload crowdsec Vérification Nous allons vérifier le fonctionnement des parsers et du nouveau scénario dédié à proxmox.\nPour cela, spammez la page de login de Proxmox, puis vérifiez les résultats :\nAlertes : cscli alerts list # | 2 │ Ip:66.66.66.66 │ fulljackz/proxmox-bf │ │ │ ban:1 │ 2024-07-18 12:13:37.498899667 +0000 UTC Décisions : cscli decisions list # 15001 │ crowdsec │ Ip:66.66.66.66 │ fulljackz/proxmox-bf │ ban │ │ │ 7 │ 3h59m51.44622068s │ 2 Conclusion En suivant ce guide, vous avez sécurisé l'authentification de votre Proxmox contre les attaques de Bruteforce grâce à CrowdSec. ","date":"2024-07-18T14:50:45+02:00","image":"/crowdsec-proteger-lauthentification-proxmox/cover.png","permalink":"/crowdsec-proteger-lauthentification-proxmox/","title":"CrowdSec : Protéger l’authentification Proxmox"},{"content":"Introduction CrowdSec est un système de cybersécurité collaboratif qui utilise des mécanismes de détection et de prévention pour protéger votre infrastructure. Ce guide vous guidera à travers l'installation de CrowdSec ainsi que de son bouncer iptables sur une machine Debian 12, avec la complétion de la commande cscli.\nPrérequis Une machine Debian 12 avec un accès root ou sudo. Toutes les commandes présentées ci-dessous seront à exécuter en tant que root. Une connexion internet active. Étape 1 : Mise à jour du système Avant de commencer l'installation, assurez-vous que votre système est à jour.\napt update apt -y upgrade Étape 2 : Installation de CrowdSec Ajouter le dépôt CrowdSec\nTéléchargez et ajoutez la clé GPG pour vérifier l'intégrité du dépôt :\ncurl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | bash Installer CrowdSec\nInstallez le package CrowdSec :\napt install -y crowdsec Vérifier l'installation\nAssurez-vous que CrowdSec est correctement installé et en cours d'exécution :\nsystemctl status crowdsec Étape 3 : Installation du Bouncer Iptables Le bouncer iptables permet à CrowdSec de bloquer les adresses IP malveillantes directement au niveau du pare-feu. C'est lui qui applique les décisions prises par crowdsec.\nTélécharger et installer le bouncer iptables\napt install -y crowdsec-firewall-bouncer-iptables Configurer le bouncer\nL'installation crée un fichier de configuration par défaut à /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Vous pouvez vérifier et modifier ce fichier selon vos besoins.\nDémarrer et activer le bouncer\nAssurez-vous que le bouncer est activé au démarrage et qu'il est en cours d'exécution :\nsystemctl enable crowdsec-firewall-bouncer systemctl start crowdsec-firewall-bouncer Vérifier le bouncer\nVérifiez que le bouncer est correctement installé et en cours d'exécution :\nsystemctl status crowdsec-firewall-bouncer Étape 4 : Activer la complétion de la commande cscli La complétion de commande rend l'utilisation de cscli plus efficace en permettant l'auto-complétion des commandes et options disponibles.\nInstaller les scripts de complétion\nPour bash, vous pouvez utiliser le script de complétion fourni par CrowdSec. Tout d'abord, assurez-vous que bash-completion est installé :\napt install -y bash-completion Activer la complétion\nInstallez le script de complétion pour cscli :\ncscli completion bash \u0026gt; /etc/bash_completion.d/cscli Recharger la configuration de bash\nRechargez votre configuration de bash pour que la complétion soit prise en compte :\nsource /etc/bash_completion.d/cscli Vérifier la complétion\nTestez la complétion automatique en tapant cscli suivi de Tab pour voir les options disponibles.\nÉtape 5 : Vérification de l\u0026rsquo;intégration Pour vérifier que tout fonctionne correctement, vous pouvez consulter les journaux de CrowdSec et du bouncer iptables :\njournalctl -u crowdsec journalctl -u crowdsec-firewall-bouncer Étape 6 (Option) : Configuration bantime Par défaut, la décision qui est appliqué par le bouncer iptables est un ban de 4h. Bien évidement, il est possible de modifier ce comportement. Exemple pour passer cette durée à 24h :\nEditez le fichier /etc/crowdsec/profiles.yaml\ndecisions: - type: ban duration: 24h Recharger le service crowdsec\nsystemctl reload crowdsec Étape 7 (Option) : Enrôlement de la console Il est possible d'enrôler CrowdSec sur https://app.crowdsec.net/ pour avoir un jolie tableau de bord et une visualisation globale. L'autre intérêt, va être la possibilité d'ajouter des listes d'IP malveillantes maintenues par CrowdSec à nos instances. Coucou la liste disponible pour les JO 2024 🙂\nCréer un compte sur https://app.crowdsec.net/\nValidez votre compte en vous authentifiant sur la plateforme\nRendez vous dans le menu \u0026quot;Security Engines\u0026quot; \u0026gt; \u0026quot;Engines\u0026quot;\nCliquez sur \u0026quot;Add Security Engine\u0026quot;.\nExécutez la commande d'enrôlement sur votre serveur\ncscli console enroll -e context YOUR-ENROLL-KEY Dans un contexte d'automatisation, il est possible de spécifier le nom d'hôte :\ncscli console enroll --name $(hostname) YOUR-ENROLL-KEY Voici l'aide de la commande : https://docs.crowdsec.net/docs/next/cscli/cscli_console_enroll/\nAcceptez l'enrôlement sur la plateforme web de CrowdSec\nRedémarrez le service crowdsec sur le serveur\nsystemctl restart crowdsec Modification du port de l\u0026rsquo;API Par défaut CrowdSec utilise le port TCP 8080 pour accéder à son API. Si ce port est déjà utilisé sur votre serveur, il est important de modifier la configuration de CrowdSec pour que l'API en utilise un autre.\nExemple pour utiliser le port TCP 6660 à la place du TCP 8080 :\nModifiez le fichier /etc/crowdsec/config.yaml\napi: client: [...] server: [...] listen_uri: 127.0.0.1:6660 Modifiez le fichier /etc/crowdsec/local_api_credentials.yaml\nurl: http://127.0.0.1:6660 Modifier le fichier /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml\napi_url: http://127.0.0.1:6660/ Redémarrez les services crowdsec\nsystemctl restart crowdsec systemctl restart crowdsec-firewall-bouncer Conclusion Vous avez maintenant installé et configuré CrowdSec avec le bouncer iptables sur votre machine Debian 12, et activé la complétion de la commande cscli. Ce système devrait maintenant aider à protéger votre infrastructure contre les adresses IP malveillantes. Assurez-vous de consulter régulièrement les journaux et de maintenir votre système à jour pour garantir une protection optimale.\nRessources supplémentaires Documentation officielle de CrowdSec Dépot GitHub de CrowdSec Communauté CrowdSec ","date":"2024-07-18T10:28:12+02:00","image":"/crowdsec-installation-avec-bouncer-iptables-sur-debian-12/cover.png","permalink":"/crowdsec-installation-avec-bouncer-iptables-sur-debian-12/","title":"CrowdSec : Installation avec Bouncer Iptables sur Debian 12"},{"content":"Préambule Dans le monde de la gestion des fichiers et des données, l'efficacité des outils de compression est essentielle, surtout à l'ère des volumes de données croissants. Les formats de compression classiques, gzip et bzip2, bien que robustes et largement utilisés, peuvent devenir des goulets d'étranglement sur des systèmes modernes où la puissance de traitement parallèle est sous-exploitée. C'est dans ce contexte que les outils pigz (Parallel Implementation of gzip) et pbzip2 (Parallel bzip2) apportent une révolution significative en offrant une compression multithreading.\nCet article explore ces deux outils puissants, en les comparant aux utilitaires classiques, et en démontrant leur utilisation efficace avec tar, grâce à son option -I qui permet de spécifier un programme de compression externe. J’aborderai les avantages du multithreading pour la compression des données, présenterai des exemples pratiques d'utilisation, et fournirai des conseils pour optimiser vos flux de travail de gestion des fichiers en tirant parti de la parallélisation.\nIntroduction à la compression multithreading Contexte et importance de la compression des fichiers La compression des fichiers est cruciale pour économiser l'espace de stockage et réduire la bande passante lors des transferts de fichiers. Les outils classiques comme gzip et bzip2 sont largement utilisés pour leur efficacité en termes de taux de compression et de compatibilité. Toutefois, sur des systèmes multicœurs modernes, ces outils ne tirent pas parti de la puissance disponible car ils ne fonctionnent que sur un seul thread.\nLimites des outils traditionnels gzip et bzip2 Single-threaded : gzip et bzip2 ne peuvent exploiter qu'un seul cœur, ce qui limite leur vitesse de compression sur les systèmes modernes. Performance : Bien que gzip soit rapide pour la compression simple, il ne compresse pas autant que bzip2. bzip2, quant à lui, offre une meilleure compression mais à une vitesse plus lente. Présentation de pigz Fonctionnalités et avantages pigz (Parallel Implementation of gzip) est une version multi-thread de gzip. Il utilise plusieurs cœurs pour accélérer la compression et la décompression tout en maintenant la compatibilité avec le format gzip.\nMultithreading : Exploite plusieurs cœurs pour améliorer la vitesse de compression. Compatibilité : Produit des fichiers compatibles avec gzip. Options de compression : Offre des options pour ajuster le nombre de threads, le niveau de compression, etc. Installation et configuration Sur une distribution Linux (ex. Debian) :\nsudo apt install pigz Exemples d\u0026rsquo;utilisation avec tar et l\u0026rsquo;option -I Compression Pour compresser une archive tar avec pigz :\ntar -cvI pigz -f archive.tar.gz dossier/ Décompression Pour décompresser une archive tar.gz avec pigz :\ntar -xvI pigz -f archive.tar.gz Présentation de pbzip2 Fonctionnalités et avantages pbzip2 (Parallel bzip2) est une version multi-thread de bzip2 qui utilise plusieurs cœurs pour accélérer la compression et la décompression. Il produit des fichiers compatibles avec le format bzip2.\nMultithreading : Exploite plusieurs cœurs pour améliorer la vitesse de compression. Compatibilité : Produit des fichiers compatibles avec bzip2. Efficacité de compression : Offre généralement une meilleure compression que gzip. Installation et configuration Sur une distribution Linux (ex. Debian) :\nsudo apt install pbzip2 Exemples d\u0026rsquo;utilisation avec tar et l\u0026rsquo;option -I Compression Pour compresser une archive tar avec pbzip2 :\ntar -cvI pbzip2 -f archive.tar.bz2 dossier/ Décompression Pour décompresser une archive tar.bz2 avec pbzip2 :\ntar -xvI pbzip2 -f archive.tar.bz2 Comparaison des performances Test de performance : gzip vs pigz, bzip2 vs pbzip2 Pour évaluer les performances, j’ai compressé et décompressé un dossier de 10 Go de fichiers aléatoires avec gzip, pigz, bzip2, et pbzip2. Ces tests ont été réalisés sur une machine équipée d’un processeur AMD Ryzen 7 7700X @ 5.573GHz avec 16 threads.\nRésultats Outil Temps de Compression Temps de Décompression gzip 170 sec 25 sec pigz 18 sec 9 sec bzip2 565 sec 308 sec pbzip2 68 sec 30 sec Analyse des résultats et recommandations Les outils multithreading pigz et pbzip2 montrent une nette amélioration par rapport à leurs homologues single-threaded, surtout sur des systèmes avec plusieurs cœurs disponibles. Pour une compression rapide : Utilisez pigz si la vitesse est prioritaire. Pour une compression plus efficace : Utilisez pbzip2 si un meilleur taux de compression est nécessaire, tout en profitant d'une vitesse accrue par rapport à bzip2. Optimisations Conseils pour optimiser les opérations de compression Ajuster le Nombre de Threads : Utilisez les options -p de pigz et -p de pbzip2 pour ajuster le nombre de threads en fonction du nombre de cœurs disponibles.\nExemple :\npigz -p 8 -c fichier \u0026gt; fichier.gz pbzip2 -p8 fichier Combinaison avec tar : Utilisez l'option -I de tar pour spécifier le programme de compression, simplifiant ainsi les commandes complexes.\nExemple :\ntar -cvI \u0026#34;pigz -p 4\u0026#34; -f archive.tar.gz dossier/ Surveiller l'Utilisation des Ressources : Utilisez des outils comme htop ou top pour surveiller l'utilisation des ressources et ajuster les paramètres de compression en conséquence.\nConclusion La compression multithreading, grâce à des outils comme pigz et pbzip2, représente une avancée significative par rapport aux méthodes traditionnelles. En exploitant les capacités des systèmes multicœurs, ces outils offrent des performances de compression et de décompression bien supérieures. Que vous ayez besoin de rapidité avec pigz ou d'une compression plus efficace avec pbzip2, intégrer ces outils dans vos flux de travail peut transformer la gestion des fichiers et des archives, rendant vos processus plus efficaces et adaptés aux environnements modernes.\nRéférences Documentation de pigz Documentation de pbzip2 Documentation GNU tar ","date":"2024-07-08T15:05:42+02:00","image":"/compression-multithreading-pigz-gzip-pbzip2-bzip2/cover.jpg","permalink":"/compression-multithreading-pigz-gzip-pbzip2-bzip2/","title":"Compression Multithreading : pigz (gzip) \u0026 pbzip2 (bzip2)"},{"content":"Pré-requis Assurez-vous de vous placer dans le répertoire contenant le fichier docker-compose.yml avant de suivre les étapes ci-dessous.\nÉtapes pour la mise à jour Télécharger les images mises à jour Utilisez la commande suivante pour télécharger les dernières versions des images spécifiées dans le fichier docker-compose.yml :\ndocker compose pull Redémarrer les conteneurs avec les nouvelles images Redémarrez les conteneurs pour appliquer les mises à jour. Utilisez l'option -d pour détacher le processus et --remove-orphans pour supprimer les conteneurs qui ne sont plus définis dans le fichier docker-compose.yml :\ndocker compose up -d --remove-orphans Nettoyer les images obsolètes Pour libérer de l'espace disque, supprimez les images qui ne sont plus utilisées par aucun conteneur actif :\ndocker image prune ","date":"2024-07-01T11:15:09+02:00","image":"/docker-compose-mise-a-jour-manuelle-des-images/cover.png","permalink":"/docker-compose-mise-a-jour-manuelle-des-images/","title":"Docker-Compose : Mise à jour manuelle des images"},{"content":"Introduction Dans certains cas, vous pouvez perdre ou oublier le mot de passe root de votre base de données MySQL, rendant ainsi difficile l'exécution de tâches administratives essentielles. Cela peut se produire si le mot de passe a été généré automatiquement lors de l'initialisation du conteneur et non enregistré. Ce guide explique comment réinitialiser le mot de passe root de MySQL dans un environnement Docker.\nPréparation 1. Créer le fichier de réinitialisation Commencez par créer un fichier mysql-init.sql dans le même répertoire que votre fichier docker-compose.yml. Ce fichier contiendra une requête SQL pour réinitialiser le mot de passe root.\nUSE mysql; ALTER USER \u0026#39;root\u0026#39;@\u0026#39;localhost\u0026#39; IDENTIFIED BY \u0026#39;NEWPASSWORD\u0026#39;; FLUSH PRIVILEGES; Remplacez NEWPASSWORD par le nouveau mot de passe souhaité.\n2. Modifier docker-compose.yml Pour utiliser le fichier de réinitialisation avec Docker, vous devez monter ce fichier dans le conteneur MySQL.\nAjoutez ou modifiez la section volumes pour inclure le montage du fichier mysql-init.sql :\nservices: mysql: # Autres configurations de service volumes: # Autres volumes - ./mysql-init.sql:/tmp/mysql-init.sql Processus de Réinitialisation 1. Arrêter le conteneur MySQL Avant de réinitialiser le mot de passe, assurez-vous d'arrêter le conteneur MySQL :\ndocker compose stop mysql 2. Accéder au conteneur Lancez le conteneur MySQL sans démarrer le service pour obtenir un shell bash :\ndocker compose run mysql bash 3. Exécuter le script de réinitialisation Dans le conteneur, lancez MySQL avec le fichier de réinitialisation :\nmysqld --init-file=/tmp/mysql-init.sql \u0026amp; Attendez quelques instants que le processus se termine. Vous pouvez vérifier si le mot de passe a été réinitialisé en tentant une connexion à MySQL.\n4. Nettoyer et relancer le service Quittez le conteneur et supprimez le montage du fichier SQL dans docker-compose.yml :\nSupprimez ou commentez la ligne - ./mysql-init.sql:/tmp/mysql-init.sql. Ensuite, arrêtez complètement la stack Docker :\ndocker compose down Relancez la stack :\ndocker compose up -d Vérification Pour vérifier que le nouveau mot de passe fonctionne, essayez de vous connecter à MySQL en utilisant le nouveau mot de passe :\ndocker exec -it \u0026lt;CONTENEUR_MYSQL\u0026gt; mysql -u root -p Remplacez \u0026lt;CONTENEUR_MYSQL\u0026gt; par l'ID ou le nom du conteneur MySQL.\n","date":"2024-06-17T15:57:47+02:00","image":"/mysql-reinitialisation-du-mot-de-passe-root-dans-un-conteneur-docker/cover.jpg","permalink":"/mysql-reinitialisation-du-mot-de-passe-root-dans-un-conteneur-docker/","title":"MySQL : Réinitialisation du mot de passe root dans un conteneur Docker"},{"content":"Base /docker-compose-wordpress-mariadb/ Fichier uploads.ini Créer un fichier uploads.ini à côté du docker-compose.yml avec le contenu suivant : file_uploads = On memory_limit = 50M upload_max_filesize = 50M post_max_size = 50M max_execution_time = 600 Fichier docker-compose.yml Modifier la section volumes du service wordpress : volumes: - ./wordpress:/var/www/html - /etc/localtime:/etc/localtime:ro # Ajouter la ligne suivante : - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini Redémarrer WordPress docker compose down docker compose up -d ","date":"2024-06-15T12:05:28+02:00","image":"/wordpress-augmenter-la-taille-dupload-des-fichiers-docker/cover.jpg","permalink":"/wordpress-augmenter-la-taille-dupload-des-fichiers-docker/","title":"WordPress : Augmenter la taille d’upload des fichiers (Docker)"},{"content":"Le fichier docker-compose.yml services: wordpress: image: wordpress container_name: \u0026#34;wordpress\u0026#34; restart: unless-stopped ports: - \u0026#34;8080:80\u0026#34; environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: \u0026#34;wordpress\u0026#34; WORDPRESS_DB_PASSWORD: \u0026#34;wordpress_db_password\u0026#34; WORDPRESS_DB_NAME: wordpress volumes: - ./wordpress:/var/www/html - /etc/localtime:/etc/localtime:ro depends_on: - db networks: - network db: image: mariadb container_name: \u0026#34;wordpress-db\u0026#34; restart: unless-stopped environment: MYSQL_RANDOM_ROOT_PASSWORD: \u0026#39;1\u0026#39; MYSQL_DATABASE: wordpress MYSQL_USER: \u0026#34;wordpress\u0026#34; MYSQL_PASSWORD: \u0026#34;wordpress_db_password\u0026#34; volumes: - ./db:/var/lib/mysql - /etc/localtime:/etc/localtime:ro networks: - network networks: network: driver: bridge Directory mkdir {wordpress,db} sudo chmod 750 wordpress db sudo chown 999:root db sudo chown 33:33 wordpress Execution docker compose up -d ","date":"2024-06-15T11:53:16+02:00","image":"/docker-compose-wordpress-mariadb/cover.png","permalink":"/docker-compose-wordpress-mariadb/","title":"Docker-Compose : WordPress (MariaDB)"},{"content":" 15/06/2024 : Mise à jour pour Debian 12 (rsyslog, systemd) Introduction Le service Fail2ban va permettre de protéger un serveur Linux des attaques de brute-force automatiquement en surveillant les logs. Des que les conditions sont réunies (nombres de tentative dans un intervalle de temps), l'adresse IP suspecte est bannie durant un temps déterminé. Le ban est réalisé à l'aide du système de parefeu iptables.\nCet article traite de l'installation ainsi que la configuration de fail2ban sur une Debian 12. Le service SSHD servira d'exemple. Des commandes pour interagir avec le service fail2ban sont également présentées.\nSous Debian 12, le paquet rsyslog n'est plus installé par défaut. Celui-ci est nécessaire au bon fonctionnement sans modification de la configuration de fail2ban. Cependant, il est tout de même préférable de configurer celui-ci pour fonctionner avec systemd.\nLes 2 méthodes sont présentées ici. Let's go !\nInstallation Fail2ban est présent dans les dépôts de Debian 12 : sudo apt install -y fail2ban Si iptables n'est pas installé, le faire : sudo apt install -y iptables Configuration Création des fichiers de configuration Par défaut fail2ban est installé avec 2 fichiers de configuration : /etc/fail2ban/jail.conf et /etc/fail2ban/jail.d/defaults-debian.conf .\nCes fichiers ne doivent pas être modifié. Ils seront écrasés à la prochaine mise à jour de fail2ban.\nFail2ban lit les fichiers de configurations dans cet ordre :\nLes fichiers .conf Les fichiers .local Chaque directive définit dans le fichier de configuration .local, écrase la directive contenue dans son homologue .conf.\nCe fichier de configuration .local peut uniquement contenir les directives nécessaires pour compléter et/ou écraser de celles définies dans le fichier .conf.\nCréer les fichiers de configuration adéquat en se basant sur ceux présents :\nsudo cp /etc/fail2ban/jail.{conf,local} Editer le fichier jail.local :\nsudo vi /etc/fail2ban/jail.local Backend rsyslog Par défaut dans la configuration de fail2ban, il est indiqué : backend = auto Cela implique d'avoir rsyslog d'installer. Celui-ci fournira les logs dans /var/log/ comme le auth.log servant pour SSH. Dans Debian 12, ce paquet n'est plus installer par défaut. Il faut donc l'installer : sudo apt install -y rsyslog systemd Pour que fail2ban puisse se baser sur systemd, le backend doit être modifié dans la configuration de fail2ban : backend = systemd Rsyslog ne sera pas nécessaire dans ce cas.\nParamétrage Il est utile d'indiquer des IPs en liste blanche pour éviter de s'auto-ban lors d'un retour de vacance.\nDécommenter la ligne commençant par ignoreip et ajouter les adresses IPs séparées d'un espace :\nignoreip = 127.0.0.1/8 ::1 123.123.123.123 192.168.1.0/24 Il y a 3 directives importantes à connaitre :\nbantime : La durée de ban d'une adresse IP. Par défaut si aucun suffixe n'est spécifié, la durée est exprimée en secondes. Pour un ban permanent, indiquer un nombre négatif.\nfindtime : La durée pour comptabiliser le nombre de tentatives maximales (maxretry) avant de déclencher un ban.\nmaxretry : Le nombre de tentative durant la période indiquée dans findtime avant de ban une ip.\nExemple :\nbantime = 1d findtime = 10m maxretry = 5 Si 5 échecs d'authentification sont détectés dans un intervalle de 10 minutes, l'adresse IP sera ban pendant 24h.\nPour être notifié par email, modifier la ligne commençant par action :\naction = %(action_mw)s Pour avoir les logs dans l'email, indiquer %(action_mwl)s.\nUn serveur SMTP doit être installé sur le serveur (non abordé).\nModifier l'adresse de destinataire et d'expéditeur :\ndestemail = admin@linuxize.com sender = root@linuxize.com Service Après toute modification de la configuration et/ou l'installation de rsyslog, il est important de redémarrer le service fail2ban pour que les changements soient pris en compte :\nsudo systemctl restart fail2ban.service Vérification : systemctl status fail2ban.service Les jails Fail2ban utilise un concept de jails (prisons). Une jail décrit un service et comprend des notions de filtres ainsi que d'action. Lorsque les données sont écrites dans les logs, fail2ban va compter les patterns recherchés du service à surveiller pour y appliquer une action quand ça match.\nFail2ban est fournit avec plusieurs jails pour différents services. Une jail peut être définie manuellement.\nPour activer une jail, il faut ajouter la directive enabled = true juste après le titre.\nExemple pour le service sshd (toujours dans le fichier jail.local) :\n[sshd] enabled = true maxretry = 3 findtime = 1d bantime = 4w ignoreip = 127.0.0.1/8 192.168.1.0/24 Les adresses IP 127.x.x.x et 192.168.1.x sont en liste blanche. Toutes autres adresses IP sera ban, en cas de 3 échecs d'authentification au service ssh dans un laps de temps de 24h, pour une durée de 4 semaines. Resume Installation avec backend systemd sudo apt install -y fail2ban iptables sudo cp /etc/fail2ban/jail.{conf,local} sudo sed -i \u0026#39;s/backend = auto/backend = systemd/\u0026#39; /etc/fail2ban/jail.local sudo systemctl restart fail2ban.service systemctl status fail2ban.service sleep 2 sudo fail2ban-client status sshd Installation avec service rsyslog sudo apt install -y fail2ban iptables rsyslog sudo cp /etc/fail2ban/jail.{conf,local} sudo systemctl restart fail2ban.service systemctl status fail2ban.service sleep 2 sudo fail2ban-client status sshd Fail2ban client Fail2ban est fournit avec un outil en ligne de commande : fail2ban-client. Celui va permettre d'interagir avec le service fail2ban.\nPour voir toutes les options disponibles :\nfail2ban-client -h Voici quelques exemples :\nConnaitre le status du service : sudo fail2ban-client status Vérifier le status de la jail sshd : sudo fail2ban-client status sshd Unban une adresse IP : sudo fail2ban-client set sshd unbanip 11.22.33.44 Ban une adresse IP : sudo fail2ban-client set sshd banip 11.22.33.44 ","date":"2024-06-15T10:20:35+02:00","image":"/fail2ban-installation-et-configuration/cover.png","permalink":"/fail2ban-installation-et-configuration/","title":"Fail2ban : Installation et configuration (Debian 12)"},{"content":"Cette procédure va permettre de créer un template de VM Oraclelinux 9 pour Proxmox avec Cloud-Init.\nL'intérêt sera de cloner ce template, puis de pouvoir se connecter directement en ssh au 1er démarrage de la VM. Le nom d'hôte, l'adressage ip, la(es) clef(s) ssh seront configurés à l'initialisation de la VM grâce à cloud-init.\nCe template pourra éventuellement être utilisé par la suite avec une solution telle que Terraform / OpenTofu.\nCréation du template Se connecter sur un shell root de l'hôte Proxmox pvehost : ssh root@pvehost Télécharger la dernière image cloud d'Oracle Linux : wget https://yum.oracle.com/templates/OracleLinux/OL9/u4/x86_64/OL9U4_x86_64-kvm-b234.qcow2 Installer libguestfs-tools si nécessaire et ajouter qemu-guest-agent à l'image cloud précédemment téléchargée : apt install -y libguestfs-tools virt-customize -a OL9U4_x86_64-kvm-b234.qcow2 --install qemu-guest-agent Créer une VM avec l'ID 666 qui sera le template : qm create 666 --name oraclelinux9-cloudinit --net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single virtio-scsi-single va permettre d'activer le paramètre \u0026quot;iothread\u0026quot; pour une meilleure gestion des inputs ouputs dans ce cas. Elle sera nommée oraclelinux9-cloudinit et la 1ère carte réseau sera rattachée au vmbr1 du serveur Proxmox.\nAjouter un nouveau disque dur importé depuis l'image cloud : qm set 666 --scsi0 local:0,iothread=1,backup=off,format=qcow2,import-from=/root/OL9U4_x86_64-kvm-b234.qcow2 Définir le disque dur en 1er boot sur la VM : qm set 666 --boot order=scsi0 Définir le nombre de coeurs et la mémoire RAM de la VM : qm set 666 --cpu host --cores 2 --memory 4096 Attacher un disque Cloud-Init à la VM : qm set 666 --ide2 local:cloudinit qm set 666 --agent enabled=1 Ajuster les paramètres dans les options Cloud-Init qui figureront dans le template (si nécessaire) : Ces options sont disponibles dans la WebUI du serveur Proxmox au niveau de la VM.\nPlus de détails ici https://pve.proxmox.com/wiki/Cloud-Init_Support sur les différents paramétrages.\nConvertir la VM en template : qm template 666 Utilisation du template Cloner entièrement le template en VM. Ajuster les paramètres Cloud-Init de la VM si nécessaire. Démarrer la VM et récupérer l'IP (si nécessaire) : Se connecter en SSH sur la VM avec la clef ssh renseignée dans cloud-init : julien@mypc:~$ ssh -i .ssh/demo admin@172.16.20.23 ... [admin@ol9-cloudinit ~]$ sudo -l Matching Defaults entries for admin on ol9-cloudinit: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep=\u0026#34;COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS\u0026#34;, env_keep+=\u0026#34;MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE\u0026#34;, env_keep+=\u0026#34;LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES\u0026#34;, env_keep+=\u0026#34;LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE\u0026#34;, env_keep+=\u0026#34;LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY\u0026#34;, secure_path=/sbin\\:/bin\\:/usr/sbin\\:/usr/bin User admin may run the following commands on ol9-cloudinit: (ALL) NOPASSWD: ALL ","date":"2024-05-31T22:46:12+02:00","image":"/proxmox-template-oraclelinux9-avec-cloud-init/cover.png","permalink":"/proxmox-template-oraclelinux9-avec-cloud-init/","title":"Proxmox : Template Oraclelinux9 avec Cloud-Init"},{"content":"Un jour, j'ai décidé d'ajouter des blocklists à mes instances Crowdsec. Tout fier, j'en informe mon copain BoB sur Discord. C'est à ce moment là, qu'il me répond : \u0026quot;Hey, rajoute cette liste comportant + de 200k IP !\u0026quot;\nCette fameuse liste est disponible sur ce dépôt git : https://github.com/duggytuxy/Intelligence_IPv4_Blocklist\nEn complément : Un clin dœil à Romain Marcoux pour ses travaux open source liés autour de la CTI : https://github.com/romainmarcoux\nLa communauté BE.CYBER a même découpé cette liste pour bypass la limitation des équipements Fortinet. Pour ici, pas besoin de la découper puisque je vais présenter comment la mettre en place sur OPNsense et la mettre à jour automatiquement.\nAllez, c'est parti !\nMise en place d\u0026rsquo;un alias Pour la mise en place de la liste, il faudra créer un alias. C'est également grâce à cet alias qua liste se mettra à jour automatiquement.\nTout d'abord, se rendre dans Firewall (1), Aliases (2). Puis, ajouter un nouvel alias (3). 5 champs à remplir : Name (1) : Le nom qui permettra d'utiliser cet alias dans les règles du firewall. Type (2) : Sélectionner URL Table (IPs). Cela va permettre d'indiquer une fréquence de mise à jour. Refresh Frequency (3) : Indiquer la fréquence de mise à jour de la liste. Ici, tous les jours. Content (4) : La fameuse liste au format raw. Description (5) : Le nom de ce champs parle de lui-même. Lien de la liste : [Update 13/09/2025] https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt\nValider en cliquant sur Save, puis Apply. La liste est mise en place avec 8309 entrées à ce jour (1) à travers ce nouvel alias. De plus, on peut constater que le firewall d'OPNsense peut comporter jusqu'à 1 millions d'entrées par défaut (2).\nAugmenter le nombre d\u0026rsquo;entrées Si cette limite d'un million d'entrées dans le système n'est pas suffisante, il est possible de l'augmenter.\nSe rendre dans Firewall (1), Settings (2), Advanced (3), et indiquer le nombre désiré (4). Valider en cliquant sur Save. Configuration des règles du firewall Pour bloquer ces IPs malicieuses en entrées comme en sorties du firewall, il est nécessaire de créer 2 nouvelles règles. Pour réaliser ça, les définir dans Floating est intéressant. Ainsi ces règles vont s'appliquer sur toutes les interfaces en priorité.\nSe rendre dans Firewall (1), Rules (2), Floating (3). Puis ajouter une nouvelle règle (4). 4 champs importants : Action (1) : Par défaut, ce champs sera sur Pass. Le modifier pour Block Direction (2) : Peu importe la direction, on bloque ! Donc, any. Source (3) : Sélectionner l'alias créé précédemment. Destination (4) : Peu importe la destination ! Donc, any. Valider en cliquant sur Save. Créer une seconde règle identique à la première mais en inversant Source et Destination. Ne pas oublier de cliquer sur Apply pour valider l'ajout de ces 2 règles. Voilà, c'est mis en place !\nBien évidemment, il est possible d'activer les logs sur ces 2 règles afin d'en mesurer l'impact et/ou pouvoir les remonter dans un SIEM par exemple.\n","date":"2024-03-21T10:08:02+01:00","image":"/opnsense-block-malicious-ips/cover.jpg","permalink":"/opnsense-block-malicious-ips/","title":"OPNsense : Block malicious IPs"},{"content":"J'ai du mettre en place un certificat proxmox pour un serveur accessible publiquement.\nDonc voici une procédure pour la mise en place de certificat avec l'aide de ACME.\nNous allons générer un certificat pour notre serveur proxmox avec l'aide de la technologie ACME.\nPour cela on va passer par la methode présente dans la configuration graphique de proxmox.\nDans un premier temps on va avoir besoin de créer un compte ACME qui va être utilisé pour la génération du certificat.\nIl faut se rendre dans Datacenter \u0026gt; ACME\nPuis il suffit d'ajouter un compte comme dans le screen présent ci dessous :\nUne fois que le compte a été créé nous devons faire la demande de certificat.\nPour cela il faut se rendre dans la catégorie :\nDatacenter \u0026gt; pve \u0026gt; System \u0026gt; Certificates\nNous allons utiliser la partie HTTP.\nPour cela il faut juste renseigner le FQDN de votre serveur :\npve.domaine.fr\nUne fois que le domaine a été renseigné il suffit de générer la requette avec l'aide de l'utilitaire.\nIl suffit de cliquer sur son certificat \u0026gt; (choisir son profile) \u0026gt; Order certificate Now\nIl vous suffira d'attendre que le certificat soit généré.\nUne fois que le certificat est généré, il vous suffira de recharger votre page et votre certificat sera mis à jour.\nErreur rencontrée J'ai eu une erreur au moment de la génération.\nL'erreur rencontrée était qu'il manquait l'utilisateur \u0026quot;default\u0026quot; dans les comptes ACME.\nJ'ai donc créer un compte \u0026quot;default\u0026quot; avec un mail bidon. Et après j'ai pu effectuer la demande de certificat sans problème.\n","date":"2024-01-22T21:13:13+01:00","image":"/proxmox-acme-certificate/cover.png","permalink":"/proxmox-acme-certificate/","title":"Proxmox : ACME Certificate"},{"content":"Cette procédure va permettre de créer un template de VM Debian 12 pour Proxmox avec Cloud-Init.\nL'intérêt sera de cloner ce template, puis de pouvoir se connecter directement en ssh au 1er démarrage de la VM. Le nom d'hôte, l'adressage ip, la(es) clef(s) ssh seront configurés à l'initialisation de la VM grâce à cloud-init.\nCe template pourra éventuellement être utilisé par la suite avec une solution telle que Terraform / OpenTofu.\nCréation du template Se connecter sur un shell root de l'hôte Proxmox pvehost : ssh root@pvehost Télécharger la dernière image cloud de Debian 12 : wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2 Installer libguestfs-tools si nécessaire et ajouter qemu-guest-agent à l'image cloud précédemment téléchargée : apt install -y libguestfs-tools virt-customize -a debian-12-generic-amd64.qcow2 --install qemu-guest-agent Créer une VM avec l'ID 666 qui sera le template : qm create 666 --name debian12-cloudinit --net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single Elle sera nommée debian12-cloudinit et la 1ère carte réseau sera rattachée au vmbr1 du serveur Proxmox.\nAjouter un nouveau disque dur, importé depuis l'image cloud, de 20 G à la VM : qm set 666 --scsi0 local:0,iothread=1,backup=off,format=qcow2,import-from=/root/debian-12-generic-amd64.qcow2 qm disk resize 666 scsi0 20G Définir le disque dur en 1er boot sur la VM : qm set 666 --boot order=scsi0 Définir le nombre de coeurs et la mémoire RAM de la VM : qm set 666 --cpu host --cores 2 --memory 4096 Attacher un disque Cloud-Init à la VM : qm set 666 --ide2 local:cloudinit qm set 666 --agent enabled=1 Ajuster les paramètres dans les options Cloud-Init qui figureront dans le template (si nécessaire) : Ces options sont disponibles dans la WebUI du serveur Proxmox au niveau de la VM.\nPlus de détails ici https://pve.proxmox.com/wiki/Cloud-Init_Support sur les différents paramétrages.\nConvertir la VM en template : qm template 666 Utilisation du template Cloner entièrement le template en VM. Ajuster les paramètres Cloud-Init de la VM si nécessaire.\nDémarrer la VM et récupérer l'IP (si nécessaire) :\nSe connecter en SSH sur la VM avec la clef ssh renseignée dans cloud-init : julien@mypc:~$ ssh -i .ssh/demo admin@172.16.20.15 ... Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added \u0026#39;172.16.20.15\u0026#39; (ED25519) to the list of known hosts. Linux vm-deb12-01 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 ... admin@vm-deb12-01:~$ sudo -l ... User admin may run the following commands on vm-deb12-01: (ALL : ALL) ALL (ALL) NOPASSWD: ALL Par défaut l'utilisateur définit par cloud-init appartient au groupe sudo et peut exécuter absolument tout sans saisir son mot de passe.\n","date":"2023-11-09T14:23:19+01:00","image":"/proxmox-template-debian12-avec-cloud-init/cover.png","permalink":"/proxmox-template-debian12-avec-cloud-init/","title":"Proxmox : Template Debian12 avec Cloud-Init"},{"content":"Avec Docker, il y a principalement 2 types de volumes qui sont utilisés :\nLes volumes \u0026quot;volume\u0026quot; : Permet de stocker un répertoire du conteneur dans un volume docker stocké sur l'host (/var/lib/docker/volumes). Les volumes \u0026quot;bind\u0026quot; : Permet de monter un répertoire présent sur l'host dans un conteneur. Personnellement, j'utilise la plupart du temps des volumes de type \u0026quot;bind\u0026quot; afin d'avoir de la persistence pour certaines données d'un conteneur. Par exemple, une base de donnée.\nLe problème que je recontre parfois est la gestion des utilisateurs/groupes propriétaires et des permissions sur les données stockées dans ce type de volume \u0026quot;bind\u0026quot;.\nAvec un volume \u0026quot;volume\u0026quot;, l'avantage est que tout est géré par docker. Par contre, je ne souhaite pas forcément stocker ce volume docker dans /var/lib/docker/volumes de l'host.\nAlors, nous allons voir comment utilisé un volume docker mais qui en faites sera un volume de type bind. Ce que je nomme un volume bind déguisé en volume docker 🙂\nCréation du volume docker Tout d'abord, créer un répertoire local sur l'host qui stockera les données :\nsudo mkdir -m 775 -p /srv/docker/volumes/data Puis, changer l'utilisateur et groupe propriétaire :\nsudo chown -R $USER:docker /srv/docker/volumes Enfin, créer le volume docker :\ndocker volume create --driver local \\ --opt type=none \\ --opt device=/srv/docker/volumes/data \\ --opt o=bind vol_data --driver local : Définit le driver docker à utiliser à local (par défaut). --opt type=none : Il est important de bien définir le type à none. --opt device= : Où seront stocké les données du volume sur l'host. --opt o=bind : C'est avec cette option que le volume docker sera en faites un volume bind. Vérifier la création du volume :\n$ docker volume list DRIVER VOLUME NAME local vol_data Vérifier les propriétés du volume :\n$ docker inspect vol_data [ { \u0026#34;CreatedAt\u0026#34;: \u0026#34;2023-10-11T11:15:38+02:00\u0026#34;, \u0026#34;Driver\u0026#34;: \u0026#34;local\u0026#34;, \u0026#34;Labels\u0026#34;: null, \u0026#34;Mountpoint\u0026#34;: \u0026#34;/var/lib/docker/volumes/vol_data/_data\u0026#34;, \u0026#34;Name\u0026#34;: \u0026#34;vol_data\u0026#34;, \u0026#34;Options\u0026#34;: { \u0026#34;device\u0026#34;: \u0026#34;/srv/docker/volumes/data\u0026#34;, \u0026#34;o\u0026#34;: \u0026#34;bind\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;none\u0026#34; }, \u0026#34;Scope\u0026#34;: \u0026#34;local\u0026#34; } ] Un volume nommé vol_data est à présent disponible pour un conteneur.\nUtilisation du volume docker Avec docker run Pour utiliser ce volume docker avec docker run , comme avec un volume docker \u0026quot;classique\u0026quot;, utiliser l'option --volume vol_data:/data. Cela montera le volume docker \u0026quot;vol_data\u0026quot; précédement créé dans le point de montage \u0026quot;/data\u0026quot; du conteneur.\nAvec docker compose Pour utiliser ce volume docker dans un docker-compose.yml, c'est comme un volume classique :\nversion: \u0026#39;3\u0026#39; services app: #... volumes: - vol_data:/data #... volumes: vol_data: Portainer Si portainer est utilisé pour gérer l'hôte docker, le volume apparaitra dans la section \u0026quot;Volumes\u0026quot; de l'interface web. Si vous créez vos conteneurs, services, stacks swarm sur Portainer, vous pourrez l'utiliser sans problème.\nToutefois, il est impossible de créer ce genre de volume via l'interface web de portainer.\nAttention cependant au nom du volume que vous lui donner lors de sa création.\nPar exemple, je souhaite utiliser un volume docker (qui finalement sera de type bind) dans une stack swarm qui s'appelle \u0026quot;webapp\u0026quot;. Lors de la création du volume, je le nommerai \u0026quot;webapp_vol_data\u0026quot; et dans mon fichier yaml de la stack, j'appelerai ce volume uniquement \u0026quot;vol_data\u0026quot;.\nSi le volume utilisé dans un docker-compose n'est pas bien définit au niveau du nommage, un volume docker \u0026quot;standard\u0026quot; sera alors automatiquement créer à la place et celui-ci sera dans /var/lib/docker/volumes.\nDonc bien penser à vérifier que les données soient au bon endroit sur l'host. Surtout si les données doivent être stockées sur un volume réseau !\n","date":"2023-10-11T11:25:12+02:00","image":"/docker-volume-bind-deguise/cover.png","permalink":"/docker-volume-bind-deguise/","title":"Docker : Volume bind déguisé"},{"content":"Lorsque vous exécutez des applications exigeantes en termes de performances sur votre serveur Debian, il est essentiel de maximiser l'efficacité de votre matériel pour obtenir les meilleures performances possibles. L'utilitaire Tuned est un outil puissant qui vous permet de personnaliser les réglages du système en fonction de différents profils de performances, ce qui peut vous aider à optimiser votre serveur en fonction de vos besoins spécifiques.\nInstallation de Tuned Avant de commencer à utiliser Tuned, vous devez d'abord l'installer sur votre système Debian. Vous pouvez le faire en utilisant la commande suivante :\nsudo apt install tuned Une fois l'installation terminée, vous pouvez activer et configurer Tuned.\nService Tuned déploie son propre service. Pour en consulter son status, exécutez la commande suivante :\nsudo systemctl status tuned.service Le service est activé par défaut :\n● tuned.service - Dynamic System Tuning Daemon Loaded: loaded (/lib/systemd/system/tuned.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-09-06 20:17:21 CEST; 8min ago Docs: man:tuned(8) man:tuned.conf(5) man:tuned-adm(8) Main PID: 12013 (tuned) Tasks: 4 (limit: 2276) Memory: 15.9M CPU: 1.202s CGroup: /system.slice/tuned.service └─12013 /usr/bin/python3 -Es /usr/sbin/tuned -l -P sept. 06 20:17:21 debian systemd[1]: Starting Dynamic System Tuning Daemon... sept. 06 20:17:21 debian systemd[1]: Started Dynamic System Tuning Daemon. Activation de Tuned Tuned est conçu pour fonctionner avec des profils de performances prédéfinis. Vous pouvez les afficher en exécutant la commande suivante :\nsudo tuned-adm list Les profils disponibles seront :\nAvailable profiles: - accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states - atomic-guest - Optimize virtual guests based on the Atomic variant - atomic-host - Optimize bare metal systems running the Atomic variant - balanced - General non-specialized tuned profile - cpu-partitioning - Optimize for CPU partitioning - default - Legacy default tuned profile - desktop - Optimize for the desktop use-case - desktop-powersave - Optmize for the desktop use-case with power saving - enterprise-storage - Legacy profile for RHEL6, for RHEL7, please use throughput-performance profile - hpc-compute - Optimize for HPC compute workloads - intel-sst - Configure for Intel Speed Select Base Frequency - laptop-ac-powersave - Optimize for laptop with power savings - laptop-battery-powersave - Optimize laptop profile with more aggressive power saving - latency-performance - Optimize for deterministic performance at the cost of increased power consumption - mssql - Optimize for MS SQL Server - network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance - network-throughput - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks - optimize-serial-console - Optimize for serial console use. - oracle - Optimize for Oracle RDBMS - postgresql - Optimize for PostgreSQL server - powersave - Optimize for low power consumption - realtime - Optimize for realtime workloads - realtime-virtual-guest - Optimize for realtime workloads running within a KVM guest - realtime-virtual-host - Optimize for KVM guests running realtime workloads - sap-hana - Optimize for SAP HANA - sap-netweaver - Optimize for SAP NetWeaver - server-powersave - Optimize for server power savings - spectrumscale-ece - Optimized for Spectrum Scale Erasure Code Edition Servers - spindown-disk - Optimize for power saving by spinning-down rotational disks - throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads - virtual-guest - Optimize for running inside a virtual guest - virtual-host - Optimize for running KVM guests Vous pouvez ensuite activer le profil de performance de votre choix en utilisant la commande :\nsudo tuned-adm profile \u0026lt;nom-du-profil\u0026gt; Remplacez \u0026lt;nom-du-profil\u0026gt; par le nom du profil que vous souhaitez utiliser. Par exemple, si vous souhaitez activer le profil \u0026quot;throughput-performance\u0026quot;, exécutez la commande suivante :\nsudo tuned-adm profile throughput-performance Vous pouvez obtenir le profil recommandé par l'application avec la commande suivante :\nsudo tuned-adm recommend Configuration personnalisée Tuned permet également la création de profils de performance personnalisés. Pour ce faire, vous devez éditer le fichier de configuration de Tuned. Le fichier de configuration principal est situé dans le répertoire /etc/tuned/. Par exemple, pour créer un profil personnalisé nommé \u0026quot;mon-profil\u0026quot;, vous pouvez créer un fichier de configuration /etc/tuned/mon-profil/tuned.conf.\nVoici un exemple de fichier de configuration Tuned pour un profil personnalisé :\n[main] include=throughput-performance [cpu] governor=performance [sysctl] vm.dirty_ratio=10 Ce fichier de configuration active d'abord le profil \u0026quot;throughput-performance\u0026quot; en utilisant l'instruction include. Ensuite, il définit le gouverneur du CPU sur \u0026quot;performance\u0026quot; pour maximiser les performances du processeur. Enfin, il ajuste un paramètre de sysctl pour contrôler la gestion de la mémoire.\nAprès avoir créé votre profil personnalisé, vous pouvez l'activer de la même manière que les profils prédéfinis à l'aide de tuned-adm.\nConclusion L'utilitaire Tuned est un outil précieux pour optimiser les performances de votre serveur Debian en fonction de vos besoins spécifiques. En utilisant les profils prédéfinis ou en créant des profils personnalisés, vous pouvez tirer le meilleur parti de votre matériel tout en garantissant une utilisation efficace des ressources système.\nN'hésitez pas à explorer davantage les possibilités de Tuned et à l'adapter à vos besoins pour obtenir des performances optimales sur votre serveur Debian.\n","date":"2023-09-07T00:56:00+02:00","image":"/debian-optimisez-votre-distribution-avec-tuned/cover.png","permalink":"/debian-optimisez-votre-distribution-avec-tuned/","title":"Debian : Optimisez votre distribution avec Tuned"},{"content":"Présentation Watch Tower permet de mettre à jour les images docker utilisées de façon automatique. Il va permettre de télécharger la nouvelle image, supprimer proprement le conteneur l'utilisant et le relancer avec les mêmes options. Par défaut, cela utilise le Docker Hub, mais il est possible de paramétrer un registry privé en spécifiant des credentials.\nLa documentation complète peut être accessible ici : https://containrrr.dev/watchtower/\nInstallation L'installation est très simple car Watch Tower va tourner lui-même en conteneur.\nJe vais utiliser un fichier docker-compose.yml pour exécuter l'application :\nversion: \u0026#39;3.8\u0026#39; services: watchtower: image: containrrr/watchtower:latest container_name: watchtower restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock command: --schedule \u0026#34;0 0 4 * * *\u0026#34; --cleanup docker.sock : Indispensable pour avoir accès au socket docker de l'hôte dans le conteneur afin de surveiller tous les autres conteneurs. schedule : Permet de préciser quand vérifier les mises à jour sous un format à 6 colonnes (contrairement à crontab). La 1ère colonne correspond aux secondes. Ici, 4h tous les jours. cleanup : Permet de supprimer les anciennes images docker. Par défaut toutes les images de tous les conteneurs sont surveillées. Il est possible d'affiner ce comportement.\nD'autres options sont disponibles (Se référer à la documentation précisée en introduction).\nExécution Lancer simplement le docker-compose.yml :\ndocker-compose up -d ","date":"2023-04-11T08:04:46+02:00","image":"/docker-update-auto-images/cover.png","permalink":"/docker-update-auto-images/","title":"Watch Tower : Auto update docker images"},{"content":"Non-Persistance sysctl -w net.ipv6.conf.all.disable_ipv6=1 sysctl -w net.ipv6.conf.default.disable_ipv6=1 sysctl -w net.ipv6.conf.lo.disable_ipv6=1 sysctl -w net.ipv6.conf.all.autoconf=0 sysctl -w net.ipv6.conf.default.autoconf=0 Persistance Dans /etc/sysctl.conf : net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 net.ipv6.conf.lo.disable_ipv6=1 net.ipv6.conf.all.autoconf=0 net.ipv6.conf.default.autoconf=0 Exécuter la commande suivante pour la prise en compte : sysctl -p ","date":"2023-02-03T14:40:24+01:00","image":"/network-desactiver-lipv6-sur-debian/cover.jpg","permalink":"/network-desactiver-lipv6-sur-debian/","title":"Network : Désactiver l’IPv6 sur Debian"},{"content":"Couleurs Variables neutre=\u0026#39;\\e[0;m\u0026#39; noir=\u0026#39;\\e[0;30m\u0026#39; gris=\u0026#39;\\e[1;30m\u0026#39; rougefonce=\u0026#39;\\e[0;31m\u0026#39; rose=\u0026#39;\\e[1;31m\u0026#39; vertfonce=\u0026#39;\\e[0;32m\u0026#39; vertclair=\u0026#39;\\e[1;32m\u0026#39; orange=\u0026#39;\\e[0;33m\u0026#39; jaune=\u0026#39;\\e[1;33m\u0026#39; bleufonce=\u0026#39;\\e[0;34m\u0026#39; bleuclair=\u0026#39;\\e[1;34m\u0026#39; violetfonce=\u0026#39;\\e[0;35m\u0026#39; violetclair=\u0026#39;\\e[1;35m\u0026#39; cyanfonce=\u0026#39;\\e[0;36m\u0026#39; cyanclair=\u0026#39;\\e[1;36m\u0026#39; grisclair=\u0026#39;\\e[0;37m\u0026#39; blanc=\u0026#39;\\e[1;37m\u0026#39; Utilisation echo -e \u0026#34;${rougefonce}Hello${neutre} ${jaune}World${neutre}\u0026#34; -e : enable interpretation of backslash escapes\nStyles Variables normal=\u0026#39;\\033[0m\u0026#39; gras=\u0026#39;\\033[1m\u0026#39; fin=\u0026#39;\\033[2m\u0026#39; italic=\u0026#39;\\033[3m\u0026#39; souligne=\u0026#39;\\033[4m\u0026#39; flash=\u0026#39;\\033[5m\u0026#39; inverse=\u0026#39;\\033[7m\u0026#39; invisible=\u0026#39;\\033[8m\u0026#39; Utilisation echo -e \u0026#34;${gras}Hello${normal} ${flash}World${normal}\u0026#34; -e : enable interpretation of backslash escapes\n","date":"2022-12-06T18:13:55+01:00","image":"/scripting-bash-couleurs-styles-texte/cover.jpg","permalink":"/scripting-bash-couleurs-styles-texte/","title":"Scripting bash : Couleurs / Styles texte"},{"content":"Cet article fait suite à mon précédent OPNsense : Déploiement d'une instance sur OVHcloud [Partie 1/2] afin d'avoir un routeur opensource exploitable.\nConfiguration IP 1er démarrage Lors du 1er démarrage de l'instance OPNsense, un écran similaire à celui-ci est affiché :\nL'adressage IP des différentes interfaces réseaux est à paramétrer.\nAttention à la dénomination de LAN et de WAN. A ce stade, l'attribution du LAN et du WAN fait par l'installateur est incorrect. En réalite :\nvtnet0 = Adresse IP publique soit le WAN pour l'instance vtnet1 = Adresse IP du vRack soit le LAN pour l'instance Se connecter Pour réaliser la configuration IP nécessaire, il faut tout d'abord se connecter dans la console.\nLogin : root Password : opnsense Le menu d'administration de la console est maintenant disponible :\nAssignation des interfaces Comme évoqué précédemment, l'attribution des interfaces faites par l'installeur est erronée. Il faut donc refaire l'assignation des 2 interfaces.\nFaire le choix 1 : Assign interfaces Do you want to configure LAGGS now ? : N Do you want to configure VLANs now ? : N Enter the WAN interface name : vtnet0 Enter the LAN interface name : vtnet1 Enter the Optional interface 1 name : Press Enter Le récapitulatif suivant doit être affiché :\nThe interfaces will be assigned as follows : WAN -\u0026gt; vtnet0 LAN -\u0026gt; vtnet1 Appliquer les modifications Do you want to proceed ? : Y A présent, les interfaces sont correctement assignées. L'adresse IP publique est récupérée par le DHCP d'OVH sur l'interface WAN.\nParamétrage IP Avant d'aller plus loin, il va falloir récupérer quelques informations sur l'instance :\nL'adresse IP publique et sa passerelle : Ces informations sont disponibles dans le tableau de bord de l'instance. L'adresse IP sur le vRack : Cette information est disponible dans la liste des instances (colonne IP privée). Attention au masque de sous-réseau :\nIP publique = Masque de sous-réseau en 32 bits IP privée vRack = Masque de sous-réseau en 16 bits Puis passer au paramétrage des adresses IP sur OPNsense dans la console VNC :\nFaire le choix 2 : Set interface IP address Available interfaces : 1 - LAN (vtnet1 - static, track6) 2 - WAN (vtnet0 - dhcp, dhcp6) Paramétrer d'abord l'interface WAN Enter the number of the interface to configure : 2 Configure IPv4 address WAN interface via DHCP ? : N Enter the new WAN IPv4 address : Adresse IP publique relevée précédement Enter the new WAN IPv4 subnet bit count : 32 Enter the new WAN IPv4 upstream gateway address : Adresse passerelle / gateway relevé précédement Do you want to use the gateway as the IPv4 name server, too ? : N Enter the IPv4 name server : 213.186.33.99 (DNS OVH) Configure IPv6 address WAN interface via DHCP6 ? : N Enter the new WAN IPv6 address : Press Enter Do you want to change the web GUI protocol from HTTPS to HTTP ? : N (Un certificat SSL Let's Encrypt sera appliqué plus bas) Do you want to generate a new self-signed web GUI certificate ? : N Restore web GUI access defaults ? : N L'interface WAN est paramétrée.\nMaintenant, passer au paramétrage de l'interface LAN:\nRefaire le choix 2 : Set interface IP address Enter the number of the interface to configure : 1 Configure IPv4 address LAN interface via DHCP ? : N Enter the new LAN IPv4 address : Adresse IP privée du vRack relevée précédement Enter the new LAN IPv4 subnet bit count : 16 Enter the new LAN IPv4 upstream gateway address : Press Enter Configure IPv6 address LAN interface via DHCP6 ? : N Enter the new LAN IPv6 address : Press Enter Do you want to enable the DHCP server on LAN ? : N Do you want to change the web GUI protocol from HTTPS to HTTP ? : N Do you want to generate a new self-signed web GUI certificate ? : N Restore web GUI access defaults ? : N L'interface LAN est paramétrée.\nInterface web 1ère connexion Par défaut, pour se connecter à l'interface web d'administration de la solution OPNsense, il faut s'y connecter à travers l'interface LAN.\nDans le cas présent, il n'y a pas d'autre machine présente sur ce contexte réseau. Il faut donc s'y connecter à travers l'interface WAN.\nPour se faire, dans la console VNC de l'instance :\nFaire le choix 8 : Shell Désactiver le pare-feu : pfctl -d Attention, à chaque rechargement de la configuration d'OPNsense, le pare-feu sera réactivé. Une règle autorisant l'administration à distance par le WAN sera définie plus bas.\nIl est maintenant possible de se connecter à l'interface web d'administration d'OPNsense à travers l'interface WAN.\nSe rendre sur l'adresse https://IP_PUBLIC Accepter le certificat auto-signé Renseigner les credentials Username : root Password : opnsense Un assistant de configuration est proposé lors de la 1ère connexion, celui-ci peut être by-passé en cliquant sur le logo OPNsense en haut à gauche.\nFiltrage Pour accéder à la page d'administration d'OPNsense, le pare-feu a été désactivé pour effectuer la 1ère connexion.\nRappel : A chaque rechargement de configuration, le pare-feu sera réactivé automatiquement.\nIdéalement, il faut définir une seule adresse IP (ou plusieurs) qui sera autorisée à y accéder.\nTout d'abord, créer un alias afin de mieux identifier l'hôte qui sera autorisé à se connecter à l'interface web d'administration.\nSe rendre dans Firewall (1), Aliases (2) Ajouter un nouvel alias (3) Voici un exemple d'alias pour une adresse IP donnée. Bien penser à valider le Content en appuyant sur Enter, puis Save en bas à droite : Ne pas valider tout de suite les modifications avec le bouton Apply figurant en bas sur la page des Aliases. Sinon, le pare-feu se réactivera et la connexion sera perdue. Si cela se produit, revenir dans la console VNC de l'instance et refaire la commande pfcl -d.\nEnsuite, ajouter une règle sur l'interface WAN du pare-feu.\nSe rendre dans Firewall (1), Rules (2), WAN (3) Ajouter une nouvelle règle (4) La partie Source de la règle : La partie Destination de la règle : Enregistrer avec le bouton Save Valider toutes les modifications de configuration en cliquant sur Apply changes en haut à droite de la page L'alias créé ainsi que la règle ajoutée dans l'interface WAN du pare-feu vont être appliqué. Le pare-feu sera également réactivé automatiquement.\nPour être sûr et certain que le pare-feu soit bien actif :\nSe rendre dans la console VNC de l'instance et exécuter la commande : pfctl -e Le shell doit renvoyer :\npfctl: pf already enabled Mot de passe root Maintenant que l'accès externe à l'interface web d'administration est filtré, il est important de changer le mot de passe root.\nSe rendre dans Lobby (1), Password (2) La modification de ce mot passe entraine également la modification du mot de passe dans la console VNC et/ou par SSH si cet accès est activé.\nHostname, Timezone\u0026hellip; Il peut être intéressant de modifier le nom d'hôte, le domaine, ou bien la timezone d'OPNsense.\nSe rendre dans System (1), Settings (2), General (3) Sécurité Sujet très vaste !\nJe vais m'attarder sur 2 points principaux :\nLa mise à jour d'OPNsense La mise en place d'un certificat SSL avec Let's Encrypt Mise à jour Il est important de mettre régulièrement à jour la solution.\nSe rendre dans System (1), Firmware (2), Status (3) Puis Check for updates (4) Si des mises à jour sont disponibles, la liste des packages concernés sera affichée dans l'onglet Updates.\nEn bas de cette page, un bouton Update sera disponible. Il sera également indiqué si un redémarrage d'OPNsense est requis.\nCertificat SSL Let\u0026rsquo;s Encrypt Installation du client La 1ère étape à réaliser est l'installation du client acme.\nSe rendre dans System (1), Firmware (2), Plugins (3) Installer le client acme (4) Activation du plugin Une fois ce plugin installé, forcer un rafraichissement de l'interface web (CTRL+SHiFT+R) pour avoir le service ACME Client de disponible.\nSe rendre dans Services (1), ACME Client (2), Settings (3) Activer le plugin (4) Valider avec le bouton Apply Une tâche cron est générée afin de renouveler automatiquement le certificat. Celle-ci est définie dans l'onglet Update Schedule.\nCréation du compte Let\u0026rsquo;s Encrypt Ensuite, un compte doit être créé et enregistré pour la génération du certificat chez Let's Encrypt.\nSe rendre dans Accounts (1) Créer un compte (2) Compléter les champs requis Valider avec le bouton Save Enregistrer le compte Le status du compte passe en OK (registred).\nEnregistrement DNS Avant de passer à la suite, il est impératif de créer un enregistrement de type A dans la zone DNS publique adéquate pointant vers l'adresse IP publique d'OPNsense.\nPar exemple :\nopnsense-demo.example.com. IN A xxx.xxx.xxx.237 xxx.xxx.xxx.237 = IP publique de l'interface WAN d'OPNsense\nBien vérifier que cet enregistrement a été répercuté sur les serveurs DNS de Google (Let's Encrypt s'appuie dessus).\nDans votre terminal GNU/Linux :\ndig opnsense-demo.example.com @8.8.8.8 Il est également est possible de vérifier l'enregistrement à cette adresse : https://dns.google\nParamétrage du challenge Une fois cet enregistrement fait et vérifié, paramétrer un type de challenge :\nSe rendre dans Challenge Types (1) Créer un nouveau type de challenge (2) Choisir un challenge de type HTTP-01 Dans le champ IP Addresses bien valider l'adresse IP publique de l'interface WAN en appuyant sur Enter\nValider avec le bouton Save Automatisation Avant de passer à la génération du certificat, il est recommandé d'ajouter une tâche d'automatisation. Celle-ci sera effectuée à chaque fois que le certificat sera renouvelé.\nSe rendre dans Automations (1) Créer une tâche d'automatisation (2) Sélectionner la tâche de redémarrage de la Web UI d'OPNsense Cette partie d'automatisation est optionelle mais recommandée.\nGénération du certificat Maintenant, un certificat peut être généré :\nSe rendre dans Certificates (1) Créer un nouveau certificat (2) Dans le champ Common Name, bien renseigner l'URL d'accès qui permettra d'accéder à l'interface web d'administration d'OPNsense en correspondance avec l'enregistrement de type A faites dans la zone DNS au préalable. Bien spécifier la tâche d'automatisation dans le champ Automations.\nValider avec le bouton Save Générer le certificat avec le bouton Issue/Renew All Certificates Vérification Vérifier l'ajout de l'autorité de certification : Se rendre dans System (1), Trust (2), Authorities (3) L'authorité de certification Let's Encrypt doit être présente Vérifier la présence du certificat préalablement généré : Se rendre dans Certificates (1) Le certificat préalablement généré doit être présent Application du certificat A ce stade, ce nouveau certificat Let's Encrypt peut être appliqué pour la connexion à l'interface d'administration d'OPNsense (en lieu et place du certificat auto-signé).\nSe rendre dans System (1), Settings (2), Administration (3) Je recommande de modifier le port d'administration HTTPS et d'adapter la règle de filtrage (vu dans le chapitre Interface web / Filtrage de cet article).\nValider avec le bouton Save Et voilà !\nIl est désormais possible d'accéder de façon sécurisée à l'admimistration d'un OPNsense hébergé chez OVHcloud avec un certificat SSL reconnu.\nEn suivant l'exemple donné ici, l'accès se fera sur l'URL : https://opnsense-demo.example.com (Adresse fictive pour l'article !).\n","date":"2022-11-18T15:17:42+01:00","image":"/opnsense-deploiement-dune-instance-sur-ovhcloud-partie-2-2/cover.png","permalink":"/opnsense-deploiement-dune-instance-sur-ovhcloud-partie-2-2/","title":"OPNsense : Déploiement d’une instance sur OVHcloud [Partie 2/2]"},{"content":" Installation d'un Rocket.Chat en mode standalone sur Debian 11.\nTrès important ! MongoDB 5.0 demande que le jeu d'instruction AVX soit géré par le CPU du serveur.\nVérifier que AVX soit traité par le CPU : cat /proc/cpuinfo | grep avx Si rien ne s'affiche, cela ne sert à rien d'aller plus loin.\nPour mes essais, j'utilise un serveur Proxmox pour la virtualisation. J'ai dû passer le CPU de la machine virtuelle sur host.\nMongoDB Community Edition Installation Le paquet mongodb fournit par les dépôts Debian n'est pas maintenue par MongoDB Inc. Celui-ci rentre en conflit avec le paquet officiel mongodb-org. Si le paquet mongodb provenant des dépôts Debian est installé, il faudra au préalable le désinstaller.\nInstaller les pré-requis : sudo apt install dirmngr gnupg apt-transport-https software-properties-common ca-certificates curl Importer la clef publique PGP nécessaire : sudo wget -O- https://www.mongodb.org/static/pgp/server-5.0.asc | gpg --dearmor | sudo tee /usr/share/keyrings/mongodb.gpg Ajouter le dépôt de MongoDB Inc. pour Debian 11 : echo \u0026#39;deb [signed-by=/usr/share/keyrings/mongodb.gpg] http://repo.mongodb.org/apt/debian buster/mongodb-org/5.0 main\u0026#39; | sudo tee /etc/apt/sources.list.d/mongodb-org-5.0.list Actuellement, Rocket.Chat demande une version 5.0 de MongoDB. Il est indiqué Buster mais c'est bon aussi pour Bullseye.\nMettre à jour le cache des paquets : sudo apt update Installer la version 5.0.13 de MongoDB : sudo apt install mongodb-org (Optionnel) Afin de prévenir une mise à jour non désirée de MongoDB par apt :\necho \u0026#34;mongodb-org hold\u0026#34; | sudo dpkg --set-selections echo \u0026#34;mongodb-org-database hold\u0026#34; | sudo dpkg --set-selections echo \u0026#34;mongodb-org-server hold\u0026#34; | sudo dpkg --set-selections echo \u0026#34;mongodb-mongosh hold\u0026#34; | sudo dpkg --set-selections echo \u0026#34;mongodb-org-mongos hold\u0026#34; | sudo dpkg --set-selections echo \u0026#34;mongodb-org-tools hold\u0026#34; | sudo dpkg --set-selections Configuration Editer le fichier de configuration /etc/mongod.conf : sudo vi /etc/mongod.conf Attention, c'est un format YAML.\nDéfinir le type de stockage sur wiredTiger :\nstorage: engine: wiredTiger Activer et nommer la réplication :\nreplication: replSetName: rs01 Le fichier de configuration doit ressembler à quelques choses de similaire à ça :\nstorage: dbPath: /var/lib/mongodb journal: enabled: true engine: wiredTiger systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log net: port: 27017 bindIp: 127.0.0.1 processManagement: fork: true timeZoneInfo: /usr/share/zoneinfo replication: replSetName: rs01 Exécution Par défaut, MongoDB stocke les données dans /var/lib/mongodb et les logs dans /var/log/mongodb.\nDémarrer MongoDB : sudo systemctl start mongod Si une erreur indique que mongod.service est introuvable :\nsudo systemctl daemon-reload Vérifier que le service est bien démarré : sudo systemctl status mongod Activer le démarrage du service au boot du système : sudo systemctl enable mongod Créer le replicaset : mongo --eval \u0026#34;printjson(rs.initiate())\u0026#34; Node.js Installation Passer root : sudo -i Récupérer et exécuter le script suivant : curl -fsSL https://deb.nodesource.com/setup_14.x | bash - Installer Node.js v14 : apt install nodejs Actuellement, Rocket.Chat demande une version 14 pour Node.js.\nSe déconnecter de root. Rocket.Chat Installation Mettre à jour le système : sudo apt update sudo apt upgrade Installer les pré-requis : sudo apt install curl build-essential graphicsmagick Télécharger la dernière version de Rocket.Chat : curl -L https://releases.rocket.chat/latest/download -o /tmp/rocket.chat.tgz Extraire l'archive : tar xzf /tmp/rocket.chat.tgz -C /tmp Installer toutes les dépendances : (cd /tmp/bundle/programs/server; npm i) Déplacer le bundle pour Rocket.Chat dans opt : sudo mv /tmp/bundle /opt/Rocket.Chat Configuration Ajout de l'utilisateur rocketchat : sudo useradd -M rocketchat \u0026amp;\u0026amp; sudo usermod -L rocketchat Modification des permissions sur le dossier de Rocket.Chat : sudo chown -R rocketchat:rocketchat /opt/Rocket.Chat Sauvegarde le chemin vers le binaire de Node.js dans une variable : NODE_PATH=$(which node) Créer le fichier du service systemd : cat \u0026lt;\u0026lt; EOF |sudo tee -a /lib/systemd/system/rocketchat.service [Unit] Description=The Rocket.Chat server After=network.target remote-fs.target nss-lookup.target nginx.service mongod.service [Service] ExecStart=$NODE_PATH /opt/Rocket.Chat/main.js StandardOutput=syslog StandardError=syslog SyslogIdentifier=rocketchat User=rocketchat [Install] WantedBy=multi-user.target EOF Editer le service rocketchat : sudo systemctl edit rocketchat Définir les variables d'environnement : [Service] Environment=ROOT_URL=http://localhost:3000 Environment=PORT=3000 Environment=MONGO_URL=mongodb://localhost:27017/rocketchat?replicaSet=rs01 Environment=MONGO_OPLOG_URL=mongodb://localhost:27017/local?replicaSet=rs01 Sauvegarder et enregistrer. Exécution Activer le démarrage du service au boot du système : sudo systemctl enable rocketchat Démarrer le service rocketchat : sudo systemctl start rocketchat Accès Web Ouvrir un navigateur web. Accéder à l'adresse du service Rocket.Chat définit avec la variable d'environnement ROOT_URL. Suivre les instructions pour définir un compte admin et les informations du serveur Rocket.Chat. ","date":"2022-10-04T18:08:56+02:00","image":"/rocket-chat-installation-standalone/cover.png","permalink":"/rocket-chat-installation-standalone/","title":"Rocket.Chat : Installation standalone"},{"content":"Presentation Il est possible d'installer un add-in au client lourd Microsoft Office 2019 pour y intégrer de nouvelles fonctionnalités avec Nextcloud.\nCet add-in permet :\nD'upload automatiquement les fichiers vers Nextcloud et de générer un lien pour les destinataires dans le mail. Cela permet de pouvoir envoyer de très gros fichiers par mail sans les placer en pièce jointe. De créer et partager un espace publique avec les destinataires pour qu'ils puissent y uploader des fichiers au lieu de les envoyer par pièce jointe. Sur ces 2 fonctionnalités, il est possible de :\nDéfinir une date d'expiration du lien. Protéger les liens publiques par mot de passe. Regrouper un ensemble de fichiers pour un même lien. Personnaliser les messages qui seront inclus automatiquement dans le mail. Pre-requis Un compte sur un serveur Nextcloud (Testé avec un Nextcloud 24.0.5). Un client lourd Outlook 2019 sous Windows. Add-in Information Il existe plusieurs versions de cet add-in :\nFree Basic Professional Premium Détails des différentes versions : https://nextcloud.com/outlook/\nIci, je vais utiliser la version Free. Cette version est limité à 50 utilisateurs.\nInstallation Côté Nextcloud, il n'y a rien à faire 🙂\nSur le poste Windows, avec le client lourd Outlook 2019, télécharger l'add-in puis lancer son installation. Celle-ci est vraiment très brève.\nLien vers les add-ins : https://download.nextcloud.com/outlook/\nSur un Windows 10 64 bits, j'ai pris celui-ci : https://download.nextcloud.com/outlook/20190410/Setup_23117_x64_free.msi\nConfiguration Au 1er lancement d'Outlook, il est demandé de renseigner les paramètres du compte Nextcloud à lié au client de messagerie.\nRenseigner l'URL du serveur Nextcloud. Ne surtout pas cliquer sur Connect.\nCliquer sur Manual login. Renseigner les credentials du compte Nextcloud de l'utilisateur et Connect. Maintenant, lors de la création d'un nouveau mail, un onglet Nextcloud est disponible. Celui-ci permet d'accéder aux fonctionnalités de l'add-in.\nIci dans la version Free :\nL'envoi de fichier volumineux par mail avec génération d'un lien publique. La création d'un espace partagé avec génération d'un lien publique. Dans le menu Settings, il est possible de paramétrer l'add-in.\nPar exemple :\nL'activation ou non de la génération d'un mot de passe pour protéger l'URL. La personnalisation du message généré dans le corps du mail qui sera ajouté automatiquement. Appliquer pour valider les modifications. Utilisation Fichiers volumineux Pour la 1ère fonctionnalité qui permet de partager un ou des fichiers volumineux sans les mettre en pièces jointes (en générant automatiquement un lien publique par le biais de Nextcloud) :\nLors de la rédaction d'un nouveau mail, sélectionner Upload files. Sélectionner le ou les fichiers à partager. (Recommandé) : Définir une date d'expiration du lien. Valider avec le bouton Upload files. Un message, dans le corps du mail, s'ajoute automatiquement pour indiquer :\nLe lien publique pour accéder aux données. Le mot de passe (si activé) pour accéder à la ressource. La date d'expiration du lien. Espace partagé Pour la 2nde fonctionnalité qui permet la création d'un espace partagé avec les destinataires et en leurs donnant la possibilité d'upload leurs fichiers sans les joindre en retour par mail (en générant automatiquement un lien publique par le biais de Nextcloud) :\nLors de la rédaction d'un nouveau mail, sélectionner Share public folder. (Recommandé) : Définir une date d'expiration du lien. Valider avec le bouton Public share. Tout comme pour l'envoi de fichiers volumineux, un message s'insère dans le corps du mail en indiquant les informations nécessaires pour les destinataires.\nRecommandation Une utilisation abusive, avec de très gros fichiers, peut provoquer une surcharge au point de vue stockage sur le serveur Nextcloud.\nDe ce fait, il est important de définir une purge régulière des fichiers envoyés.\nDu point de vue serveur, les données sont organisées ce cette façon :\nwww-data@9938e68f8acd:/var/www/html/data/julien/files# tree -d -L 3 . |-- Documents |-- Outlook | |-- Public-Share | | `-- 20220928 | `-- Upload-Files | `-- 20220928 |-- Photos `-- Templates 8 directories Attention à préserver les répertoires suivant :\nOutlook Public-Share Upload-Files On peut constater qu'un sous-répertoire est créé automatiquement avec la date du jour suivant la fonctionnalité employée. Ces dossiers datés peuvent être supprimés directement sur le serveur par le biais de script, crontab, etc...\nSi cette méthode est employé :\nRéindexer les fichiers dans la BDD de Nextcloud : www-data@9938e68f8acd:/var/www/html# php occ files:scan --all Starting scan for user 1 out of 2 (admin) Starting scan for user 2 out of 2 (julien) +---------+-------+--------------+ | Folders | Files | Elapsed time | +---------+-------+--------------+ | 25 | 67 | 00:00:00 | +---------+-------+--------------+ ","date":"2022-09-29T08:00:31+02:00","image":"/nextcloud-add-in-outlook-pour-lenvoi-de-gros-fichiers-par-mail-sans-effort/cover.png","permalink":"/nextcloud-add-in-outlook-pour-lenvoi-de-gros-fichiers-par-mail-sans-effort/","title":"Nextcloud : Add-in Outlook pour l’envoi de  gros fichiers par mail sans effort"},{"content":"Dans cet article je vais décrire comment installer une instance sous OPNsense au sein d'OVHcloud.\nPar défaut, il n'est pas possible de déployer une image OPNsense lors de la commande d'une instance sur OVHcloud.\nEn effet les distributions disponibles sont :\nAlmaLinux RockyLinux CentOS Debian Fedora Ubuntu Pourtant, on peut très bien déployer un système complet OPNsense (FreeBSD) nativement sur une instance OVHcloud.\nUn vRack sera déployé pour la partie LAN d'OPNsense.\nPréparation de l\u0026rsquo;instance OVHcloud Contexte Voici un schéma simplifié du contexte de déploiement de l'OPNsense :\nL'instance qui hébergera OPNsense utilisera l'offre Discovery à 4.99€ HT/mois avec 1 vCPU, 2 Go de RAM, et 25GB de disque SSD. Un vRack sera déployé pour relier d'autres instances futures derrière l'OPNsense. Par exemple pour héberger un cluster swarm. Création d\u0026rsquo;un vRack En tout premier, il faut créer le vRack auquel sera rataché la future instance OPNsense. Cette opération se réalise dans le panel d'administration (OVH Manager) de vos services Public Cloud chez OVH.\nDans la catégorie Network, se rendre dans la partie Private Network. Créer un réseau privé. Définir un ID de VLAN (Recommandé) Choisir le mode de distribution des adresses (Statique recommandé). Dans la partie Localisation, il est possible de définir à quelle région sera rattaché ce vRack. Pour cet article tout ce passera à Gravelines. Définir un nom pour ce vRack (ClusterSwarm dans cet article). Cela peut prendre un peu de temps à être déployé la 1ère fois. Patience...\nUne fois déployé et disponible, ce vRack apparait dans la liste des réseaux privés disponible avec la plage d'adresse attribuée.\nCréation de l\u0026rsquo;instance Maintenant que le vRack est déployé, une nouvelle instance peut être créée.\nDans la partie Instances, créer une nouvelle instance. Choisir un modèle (Instance D2-2 amplement suffisante). Choisir une localistation (Gravelines par exemple). Sélectionner une image. Ici, je suis parti sur une Debian 11 mais peut importe le choix car l'installation d'OPNsense se fera à travers une image rescue. Ajouter sa clef SSH publique de type RSA ou ECDSA (Les clefs de type ED25519 ne sont pas pris en charge). Définir un nom pour cette instance (hostname). Sélectionner le réseau privé à attacher à cette instance (Le vRack préalablement créé doit être disponible). Sélectionner une période facturation (Mensuel ou horaire). Créer l'instance. Cette instance est maintenant disponible. Son adresse IP publique et son IP privée y sont indiquées.\nInstallation OPNsense Démarrage en mode rescue Pour pouvoir installer OPNsense, il est nécessaire de démarrer en mode rescue l'instance préalablement créée.\nEn mode rescue, le disque principal sera disponible mais non monté. Le système rescue sera chargé en RAM (soit 2 Go avec une instance D2-2).\nL'ISO d'OPNsense fait 1,3 Go\nIl est donc impératif de sélectionner une image rescue qui prend très d'espace afin d'y loger également l'iso d'OPNsense.\nDe celle que j'ai testé, c'est la Debian 9 qui est la plus approprié pour la suite des manipulations.\nDans les détails de l'instance, redémarrer en mode rescue. Sélectionner l'image Debian 9. Une fois le redémarrage effectué en mode rescue en Debian 9, il est possible de s'y connecter avec la clef SSH qui a été définie lors de la création de l'instance.\nSe connecter en SSH à l'instance : ssh -i ~/.ssh/ma_clef_privee debian@[IP_PUBLIC_INSTANCE] Adapter selon l'emplacement et le nom de la privée. [IP_PUBLIC_INSTANCE] = IP publique de l'instance OVHcloud. Récupération de l\u0026rsquo;ISO d\u0026rsquo;OPNsense Une fois connecté en SSH à l'instance en mode rescue Debian 9, il est important de controler qu'il y aura assez d'espace disque afin de récupérer et décompresser l'ISO d'OPNsense.\nVérifier l'espace disque disponible (Le rescue mode est chargé en RAM) : df -h | grep -v ^tmpfs L'espace restant disponible est de 1,9G. Cela sera suffisant pour récupéré l'ISO compressé et la décompresser :\nFilesystem Size Used Avail Use% Mounted on udev 968M 0 968M 0% /dev /dev/sda1 3.0G 954M 1.9G 34% / Télécharger la dernière ISO disponible d'OPNsense : wget -P /tmp https://mirror.vraphim.com/opnsense/releases/22.7/OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2 Installer bzip2 (Si celui-ci n'est pas disponible) : sudo apt update sudo apt install bzip2 Extraire et supprimer l'archive : cd /tmp bzip2 -dk OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2 rm OPNsense-22.7-OpenSSL-dvd-amd64.iso.bz2 Mise en place QEMU/VNC Afin de pouvoir déclencher l'installation en mode console d'OPNsense à partir de l'ISO récupérée, VNC sera utilisé à travers QEMU. Afin de pouvoir prendre réaliser cela, il est nécessaire de relancer la connexion SSH à l'instance à l'aide d'un tunnel SSH afin de mapper le port distant 5900 vers un port local.\nSe reconnecter à la session SSH de l'instance en rescue : ssh -i ~/.ssh/ma_clef_privee debian@[IP_PUBLIC_INSTANCE] -L 5900:localhost:5900 Télécharger le package : wget -qO- /tmp /vkvm.tar.gz | tar xvz -C /tmp Démarrer QEMU/VNC : sudo /tmp/qemu-system-x86_64 -net nic -net user,hostfwd=tcp::80-:80,hostfwd=tcp::443-:443 -m 1024M -localtime -enable-kvm -hda /dev/sda -hdb /dev/sdb -vnc 127.0.0.1:0 -cdrom /tmp/OPNsense-22.7-OpenSSL-dvd-amd64.iso -boot d En mode rescue, /dev/sda correspond à la racine (volume monté en RAM), et /dev/sdb dorrespond au disque principal de votre instance (disponible mais non monté).\nDémarrage de l\u0026rsquo;installation d\u0026rsquo;OPNsense A partir de maintenant, il est maintenant possible de se connecter en VNC sur 127.0.0.1:5900.\n2 possibilités sont offertes lors du démarrage :\nBoot en mode live : Se connecter en root avec le mot de passe opnsense. Lancement de l'installation : Se connecter en installer avec le mot de passe opnsense . Le boot en mode live ne présente aucun intérêt dans ce cas de figure. Le compte installer est donc à utiliser pour déclencher l'installation de la solution.\nSélectionner le bon disque pour l'installation (ada1 25GB car instance d2-2) : vtnet0 = Interface publique vtnet1 = IP vRack Une fois l'installation terminée, dans les détails de l'instance sur le manager OVH, sortir du mode rescue :\nAprès quelques instants votre instance démarrera normalement sur son disque principal avec le chargement d'OPNsense.\nConfiguration OPNsense Pour procéder à la 1ère configuration de la solution OPNsense :\nSe rendre dans les détails de l'instance. Puis console VNC dans le 2nd onglet. Dans un prochain article, je traiterai de la configuration des interfaces avec une IP FailOver, la mise en place d'un certificat SSL avec Let's Encrypt.\n","date":"2022-09-23T08:00:46+02:00","image":"/opnsense-deploiement-dune-instance-sur-ovhcloud-partie-1-2/cover.png","permalink":"/opnsense-deploiement-dune-instance-sur-ovhcloud-partie-1-2/","title":"OPNsense : Déploiement d’une instance sur OVHcloud [Partie 1/2]"},{"content":"Configuration d'une clef YubiKey Bio (FIDO Edition) sous Pop!_Os 22.04 pour l'authentification :\nEn mode graphique (Gnome) En mode console Avec sudo Product : https://www.yubico.com/fr/product/yubikey-bio/\nL'intérêt est de ne plus à avoir à saisir de mot de passe de plus en plus long au quotidien et de rapidement pouvoir d'authentifier avec une empreinte digitale posée sur la clef.\nSi la clef n'est pas présente / détectée ou que la reconnaissance de l'empreinte échoue, le mot de passe sera demandé.\nIl est possible de rendre obligatoire la présence de la clef. Dans ce cas, il est fortement recommandée de posséder une seconde YubiKey en backup (de secours).\nConfiguration des empreintes digitales Télécharger l'application pour Linux : wget https://developers.yubico.com/yubioath-desktop/Beta/yubioath-desktop-6.0.0-beta.1-linux.tar.gz Extraire l'archive compressée : mkdir yubiauth tar xzvf yubioath-desktop-6.0.0-beta.1-linux.tar.gz -C yubiauth/ Lancer l'application : cd yubiauth ./authenticator Insérer la YubiKey quand l'application le demande. Définir un code PIN pour la YubiKey. Ajouter une empreinte : Poser son empreinte plusieurs fois pour bien la définir et saisir un nom : Depuis le menu Options, il est possible de modifier le code PIN et de ré-initialiser la YubiKey : Configuration de l\u0026rsquo;authentification Module U2F pour PAM Installer le module U2F pour PAM et son outil de configuration : sudo apt install libpam-u2f pamu2fcfg Génération de la configuration de PAM pour l'utilisateur courant : pamu2fcfg -u `whoami` -opam://`hostname` -ipam://`hostname` Au moment de la validation de la commande, la YubiKey se mettra à clignoter en vert. Il faudra saisir une des empreintes digitales enregistrées précédement.\nCopier le résultat : # Le résultat à récupérer sera sous cette forme (... = raccourci) julien:ehi46df...QBGFSsdf+q...70Z3A==,nbWH7...nRGyfSpJ3GS+UFkaf...YssmeKD/uiefF5...2W/RvMb8oNwA==,es256,+presence Coller le résultat dans le fichier /etc/u2f_mappings : sudo vi /etc/u2f_mappings Je déconseille fortement de vouloir piper / rediriger le résultat de la commande pamu2cfg directement dans le fichier.\nEditer le fichier /etc/pam.d/common-auth : sudo vi /etc/pam.d/common-auth Ajouter la ligne suivante (remplacer $HOSTNAME par le nom de la machine) en haut du fichier : auth sufficient pam_u2f.so origin=pam://$HOSTNAME appid=pam://$HOSTNAME authfile=/etc/u2f_mappings cue Avec cette configuration, il sera toujours possible de s'authentifier avec un mot de passe. Pour rendre l'utilisation obligatoire de la YubiKey, remplacer sufficient par required.\nMettre à jour PAM : sudo pam-auth-update Avant la mise à jour du fonctionnement de PAM, je recommande fortement de garder un shell ouvert à côté sous l'identité de root avec sudo -i. Cela permettra de rétablir la configuration initiale en cas d'erreur de manipulation.\nAuthentification en mode graphique Pour permettre l'utilisation de la YubiKey pour s'authentifier à l'environnement graphique (Gnome).\nEditer le fichier /etc/pam.d/gdm-password : sudo vi /etc/pam.d/gdm-password Ajouter la ligne suivante (remplacer $HOSTNAME par le nom de la machine) juste après la ligne @include common-auth : auth sufficient pam_u2f.so origin=pam://$HOSTNAME appid=pam://$HOSTNAME authfile=/etc/u2f_mappings cue Authentification en mode console Pour permettre l'utilisation de la YubiKey pour s'authentifier en mode console.\nEditer le fichier /etc/pam.d/login : sudo vi /etc/pam.d/login Ajouter la ligne suivante (remplacer $HOSTNAME par le nom de la machine) en haut du fichier : auth sufficient pam_u2f.so origin=pam://$HOSTNAME appid=pam://$HOSTNAME authfile=/etc/u2f_mappings cue Authentification avec sudo Pour permettre l'utilisation de la YubiKey pour s'authentifier avec la commande sudo.\nEditer le fichier /etc/pam.d/sudo : sudo vi /etc/pam.d/sudo Ajouter la ligne suivante (remplacer $HOSTNAME par le nom de la machine) en haut du fichier : auth sufficient pam_u2f.so origin=pam://$HOSTNAME appid=pam://$HOSTNAME authfile=/etc/u2f_mappings cue La YubiKey clignote en vert lorsqu'une empreinte doit être saisie : Si la YubiKey n'est pas connectée ou bien que l'empreinte n'est pas reconnue, le mot de passe habituel sera demandé. Par défaut, sudo ne redemande pas d'authentification avant 15 min. Avec sudo -k, il est possible de forcer l'expiration de ce temps. Pour rendre ce comportement persistent, la configuration de sudo doit être modifiée.\nEditer le fichier /etc/sudoers : sudo visudo Modifier comme suit : # Avant Defaults env_reset # Après Defaults env_reset,timestamp_timeout=0 Maintenant, à chaque fois que sudo sera invoqué, une demande d'authentification sera effectuée.\n","date":"2022-09-16T04:28:23+02:00","image":"/yubikey-parametrage-authentification-linux/cover.png","permalink":"/yubikey-parametrage-authentification-linux/","title":"YubiKey : Paramétrage authentification Linux"},{"content":"Le fichier docker-compose.yml version: \u0026#39;3.3\u0026#39; services: drawio: image: jgraph/drawio container_name: drawio ports: # http://localhost:8080 - 8080:8080 # https://localhost:8443 - 8443:8443 Execution docker-compose up -d ","date":"2022-09-12T07:24:05+02:00","image":"/docker-compose-drawio/cover.png","permalink":"/docker-compose-drawio/","title":"Docker-Compose : Drawio"},{"content":"Informations importantes Avoir réalisé l'enregistrement DNS adéquat pour url.application.com Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Bien modifier ce qu'il faut dans le stack (voir commentaires) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: drawio: image: jgraph/drawio networks: - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M labels: - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Indiquer l\u0026#39;URL d\u0026#39;accès à l\u0026#39;application - traefik.http.routers.drawio-http.rule=Host(\u0026lt;code\u0026gt;url.application.com\u0026lt;/code\u0026gt;) - traefik.http.routers.drawio-http.entrypoints=http - traefik.http.routers.drawio-http.middlewares=https-redirect # Indiquer l\u0026#39;URL d\u0026#39;accès à l\u0026#39;application - traefik.http.routers.drawio-https.rule=Host(\u0026lt;code\u0026gt;url.application.com\u0026lt;/code\u0026gt;) - traefik.http.routers.drawio-https.entrypoints=https - traefik.http.routers.drawio-https.tls=true - traefik.http.routers.drawio-https.tls.certresolver=le - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin - traefik.http.routers.drawio-https.middlewares=hsts-headers - traefik.http.services.drawio.loadbalancer.server.port=8080 networks: traefik-public: external: true Déploiement docker stack deploy -c stack.yml drawio Accès https://url.application.com ","date":"2022-09-12T07:21:23+02:00","image":"/docker-swarm-stack-drawio/cover.png","permalink":"/docker-swarm-stack-drawio/","title":"Docker Swarm : Stack Drawio"},{"content":"Le fichier docker-compose.yml version: \u0026#39;3.7\u0026#39; services: openvas: image: immauss/openvas container_name: openvas environment: # Indiquer un MotDePasseTresSecure or play with env\u0026#39;s file PASSWORD: MotDePasseTresSecure volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro - ./data:/data ports: - 9392:9392 Execution mkdir data docker-compose up -d ","date":"2022-09-04T22:36:59+02:00","image":"/docker-compose-openvas/cover.png","permalink":"/docker-compose-openvas/","title":"Docker-Compose : OpenVAS"},{"content":"Informations importantes Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Bien modifier ce qu'il faut dans le stack (voir commentaires) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: app: image: immauss/openvas environment: # Indiquer un mot de passe pour le compte admin de l\u0026#39;application PASSWORD: MotDePasseTresSecure volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label. - data:/data networks: # Indispensable pour communiquer avec traefik - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: - node.labels.openvas_data == true labels: # Activation de traefik - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Indiquer l\u0026#39;URL de l\u0026#39;application (openvas.example.com) - traefik.http.routers.openvas-http.rule=Host(`openvas.example.com`) - traefik.http.routers.openvas-http.entrypoints=http - traefik.http.routers.openvas-http.middlewares=https-redirect # Indiquer l\u0026#39;URL de l\u0026#39;application (openvas.example.com) - traefik.http.routers.openvas-https.rule=Host(`openvas.example.com`) - traefik.http.routers.openvas-https.entrypoints=https - traefik.http.routers.openvas-https.tls=true - traefik.http.routers.openvas-https.tls.certresolver=le # Indiquer le nomagentapplication pour les headers à travers traefik - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin - traefik.http.routers.openvas-https.middlewares=hsts-headers - traefik.http.services.openvas.loadbalancer.server.port=9392 networks: traefik-public: external: true volumes: data: driver: local Déploiement docker stack deploy -c stack.yml openvas ","date":"2022-09-04T12:16:16+02:00","image":"/docker-swarm-stack-openvas/cover.png","permalink":"/docker-swarm-stack-openvas/","title":"Docker Swarm : Stack OpenVAS"},{"content":"Changelog 04/09/2022 : Fix environnement Informations importantes Tous les services tournent dans un seul conteneur. Le compte par défaut est admin avec le mot de passe admin. URL d'accès : http://localhost:8080 Par défaut des connexions anonymes sont autorisées. Dans le menu Administration / Authentification, il est possible de modifier ce comportement : Fichier docker-compose.yml version: \u0026#39;3.3\u0026#39; services: openproject: image: openproject/community:12 environment: OPENPROJECT_HOST__NAME: localhost:8080 OPENPROJECT_HTTPS: \u0026#34;false\u0026#34; # head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 ; echo \u0026#39;\u0026#39; OPENPROJECT_SECRET_KEY_BASE: A_GENERER_AVEC_LA_CMD_CI-DESSUS volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro - pgdata:/var/openproject/pgdata - assets:/var/openproject/assets ports: - 8080:80 volumes: pgdata: driver: local assets: driver: local Execution docker-compose up -d ","date":"2022-08-25T11:55:11+02:00","image":"/docker-compose-openproject/cover.png","permalink":"/docker-compose-openproject/","title":"Docker-Compose : OpenProject"},{"content":"Cet article a pour but de décrire la mise en place de la fédération d'un annuaire LDAPS (Active Directory) au sein d'un royaume Keycloak.\nTesté avec un domaine Active Directory On-Premises et avec Azure Active Directory.\nContexte de l\u0026rsquo;infrastructure L'infrastructure sur laquelle je vais m'appuyer est la suivante :\n1 contrôleur de domaine Active Directory (AD DS) avec sa PKI (AD CS) sous Windows Serveur 2019 Standard Domaine : aukfood.lan FQDN du contrôleur de domaine : dc01.aukfood.lan 1 serveur Keycloak en version 19.0.1 Déployé dans docker swarm avec ce stack : /docker-swarm-stack-keycloak-v19-latest/ URL : keycloak.example.com Certificat TLS Note : Les commandes de ce chapitre sont réalisées depuis le serveur hébergeant le conteneur keycloak.\nRécupération du certificat Pour commencer, il va falloir récupérer le certificat TLS utilisé pour la liaison LDAPS.\nLDAP = Port 389 TCP LDAPS = Port 636 TCP Avec l'utilitaire openssl, il est possible de tester que la liaison LDAPS est fonctionelle ainsi que de récupérer différentes informations (dont le certificat du serveur) :\nopenssl s_client -connect dc01.aukfood.lan:636 Voici le retour pour cette infra :\ndepth=0 CN = dc01.aukfood.lan --- Certificate chain 0 s:CN = dc01.aukfood.lan i:DC = lan, DC = aukfood, CN = aukfood-DC01-CA --- Server certificate -----BEGIN CERTIFICATE----- MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF [...] AniSQdTOnACZrX//9tDg73RV9w== -----END CERTIFICATE----- subject=CN = dc01.aukfood.lan issuer=DC = lan, DC = aukfood, CN = aukfood-DC01-CA Copier le Server certificate commençant par -----BEGIN CERTIFICATE----- et se terminant par -----END CERTIFICATE----- dans un fichier server-ldaps.cer :\ncat \u0026lt;\u0026lt;EOF \u0026gt; server-ldaps.cer -----BEGIN CERTIFICATE----- MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF [...] AniSQdTOnACZrX//9tDg73RV9w== -----END CERTIFICATE----- EOF Création du keystore Maintenant que le certificat TLS du contrôleur de domaine a été récupéré, il va falloir l'importer dans un keystore.\nTout d'abord, installer openjdk-11-jre :\nsudo apt install openjdk-11-jre Puis importer le certificat server-ldaps.cer dans un keystore nommé keystore.jks :\nkeytool -import -trustcacerts -alias dc01.aukfood.lan-CA -file server-ldaps.cer -keystore keystore.jks Saisir un mot de passe à appliquer au keystore :\nEntrez le mot de passe du fichier de clés : Ressaisissez le nouveau mot de passe : Vérifier la présence du certificat dans le keystore généré :\nkeytool -list -keystore keystore.jks Après avoir entrer le mot de passe du keystore, le certificat est bien présent :\nEntrez le mot de passe du fichier de clés : Type de fichier de clés : PKCS12 Fournisseur de fichier de clés : SUN Votre fichier de clés d\u0026#39;accès contient 1 entrée dc01.aukfood.lan-ca, 22 août 2022, trustedCertEntry, Empreinte du certificat (SHA-256) : 61:EA:83:97:92:[...]:B5:59:EE:2C:8A:2D:EA Déclaration du keystore Maintenant que le keystore a été généré avec le certificat TLS du contrôleur de domaine, il va falloir le déclarer au sein de Keycloakpour qu'il puisse être exploité.\nDans la stack keycloak (voir lien en début d'article), un volume conf est monté pour la persistance des données du répertoire /opt/keycloak/conf dans le conteneur.\nEnvoyer le keystore précédement généré dans le conteneur :\ndocker cp ./keystore.jks $(docker ps -qf name=keycloak):/opt/keycloak/conf/ Puis ajouter les variables suivantes sur la stack de keycloak :\nservices: app: [...] environment: [...] # Indiquer le mot de passe du keystore KC_SPI_TRUSTSTORE_FILE_FILE: /opt/keycloak/conf/keystore.jks KC_SPI_TRUSTSTORE_FILE_PASSWORD: MotDePasseTresSecure [...] Le MotDePasseTresSecure est celui qui a été indiqué lors de la création du keystore.\nLister les stacks dans docker swarm :\ndocker stack ls Identifier l'ID du service docker exécutant\nNAME SERVICES ORCHESTRATOR keycloak 1 Swarm nextcloud 2 Swarm portainer 2 Swarm rocketchat 2 Swarm swarmpit 4 Swarm traefik 1 Swarm La stack faisant tourner le keycloack en v19 est nommé keycloak dans ce cluster docker.\nSupprimer la stack keycloak :\ndocker stack rm keycloak Puis relancer la stack kycloak pour prendre en compte les nouvelles variables d'environnement concernant le truststore :\ndocker stack deploy -c ./keycloak/stack.yml keycloak Le fichier stack.yml est stocké dans un répertoire nommé keycloak de mon répertoire courant. A adapter suivant son emplaccement dans le FHS.\nLogs Avant de passer à la configuration de la fédération de l'annuaire Active Directory via LDAPS à Keycloak, il est important de vérifier et de de s'assurer du bon redémarrage du conteneur.\nPour cela, lister les services en cours au sein du cluster docker :\ndocker service ls Identifier le service adéquat (ici : keycloak_app) :\nID NAME MODE REPLICAS IMAGE PORTS 2degmsl8r3se dashy replicated 0/0 lissy93/dashy:latest 7jq3dje5b0t8 keycloak_app replicated 1/1 quay.io/keycloak/keycloak:latest ubq1dvhwv0st nextcloud_app replicated 1/1 nextcloud:latest arz4ca4gvfgv nextcloud_mariadb replicated 1/1 mariadb:latest vr2c7ptq6a8k portainer_agent global 5/5 portainer/agent:latest h6h5merxg9a2 portainer_portainer replicated 1/1 portainer/portainer-ce:latest mzsq3uof6c1r rocketchat_mongodb replicated 1/1 bitnami/mongodb:4.4 tmu3kz5n7xq9 rocketchat_rocketchat replicated 1/1 registry.rocket.chat/rocketchat/rocket.chat:latest kos1zg1wowxi swarmpit_agent global 5/5 swarmpit/agent:latest gtjs3mikbtaf swarmpit_app replicated 1/1 swarmpit/swarmpit:latest nx6s2mt19bzx swarmpit_db replicated 1/1 couchdb:2.3.0 n5oq9gx05bnd swarmpit_influxdb replicated 1/1 influxdb:1.7 u7b8rsym5lzp traefik_traefik replicated 1/1 traefik:latest Vérifier la bonne exécution du service en gardant un shell ouvert avec la lecture des logs en temps réel :\ndocker service logs -f keycloak_app Configuration de la fédération LDAPS Note : A partir de maintenant, la configuration est à effectuer à travers la console web d'administration du service Keycloak.\nUser federation Sélectionner le royaume adéquat ou en créer un nouveau (1), puis se rendre sur User federation (2) :\nAjouter un fournisseur LDAP :\nNote : Pour les explications des différents champs, leurs fonctions, leurs utilités, etc... qui vont suivre, se référer à cet article que j'ai écris en 2021 sur l'intégration d'un annuaire LDAP (OpenLDAP, huhu) : /keycloak-integration-ldap-externe/\nTous les paramètres de synchronisation y sont traités :\nGestion du stockage des utilisateurs L'influence du mode Import Users sur les requêtes LDAP (LDAPS, même combat) L'Edit Mode et ses différents paramètres Les types de Vendor Les différents champs Users DN ou Bind DN Les configurations possibles pour la synchronisation ainsi que leurs périodicités General options (1) Console display name : Entrer un nom afin d'identifier cette fédération d'utilisateurs au sein de Keycloak. (2) Vendor : Indiquer le type d'annuaire. Connection and authentication settings (1) Connection URL : Renseigner l'URL de connexion à l'annuaire LDAPS sous la forme ldaps://FQDN_DC:636. Cette URL doit correspondre au \u0026quot;Common Name\u0026quot; du certificat. Celui-ci peut être identifié lors de l'utilisation de la commande openssl au début de cet article.\n(2) Use Truststore SPI : Indiquer l'utilisation du truststore javax.net.ssl.trustStore (pour le keystore.jks) uniquement pour ldaps.\n(3) Bind DN : Indiquer le DistinguishedName de l'utilisateur de l'annuaire qui sera utilisé par Keycloak. Pour le récupérer facilement :\nGet-ADUser UTILISATEUR_AD | FT DistinguishedName (4) Bind credentials : Mettre le mot de passe de l'utilisateur indiqué au point précédent.\nA noter que pour le moment, il manque des informations dans le paramétrage de la liaison LDAPS. De ce fait, le \u0026quot;Test connection\u0026quot; et le \u0026quot;Test authentication\u0026quot; ne sont pas encore réalisables (Une des différences avec les versions de Keycloak sous Wildfly en version 16 et inférieure).\nLDAP searching and updating (1) Edit mode : Définir le mode d'édition de l'annuaire.\n(2) Users DN : Indiquer le DistinguishedName de l'OU contenant les utilisateurs à fédérer.\nTests et import utilisateurs Il est maintenant possible de tester la connexion LDAPS et l'authenfication.\nCes 2 tests doivent aboutir :\nEnsuite, en haut à droite de la page, bien s'assurer que cette fédération soit enabled. Puis dans action (1), déclencher la synchronisation (2) de tous les utilisateurs :\nL'importation des utilisateurs aboutie :\nDans les utilisateurs du royaume Keycloak, je retrouve bien les utilisateurs contenus dans l'OU définit dans la fédération.\nMappers Dans ce contexte, l'utilisateur \u0026quot;Julien LOUIS\u0026quot;, se retrouve avec un username contenant des espaces. Cela est dû au faites que l'attribut cn de l'annuaire a été mappé vers l'attribut username de Keycloak.\nPour voir tous les utilisateurs du royaume keycloak (fédération incluse), rechercher ***** comme utilisateur.\nDe plus, pour l'utilisateur final, cela ne correspondra pas au login auquel il est habitué d'utiliser.\nPour modifier ce comportement, il faut mapper l'attribut sAMAccountName de l'anuaire Active Directory vers l'attribut username de Keycloak.\nSe rendre sur les paramétrages de la fédération précédement réalisée, puis dans l'onglet Mappers (1), éditer le mapper username (2) :\nModifier le champ LDAP Attribute pour y inscrire sAMAccountName :\nPuis, enregistrer la modification en bas de page.\nEnsuite, dans l'onglet Settings, modifier l'Username LDAP attribute en y inscrivant sAMAccountName :\nPuis, enregistrer la modification en bas de page.\nEn relançant la synchronisation de tous les utilisateurs de l'annuaire vers Keycloak, les utilisateurs sont mis à jour :\nA présent, le login des utilisateurs importés dans Keycloak est correctement paramétré.\n","date":"2022-08-23T15:10:58+02:00","image":"/keycloak-federation-dun-annuaire-ldaps-active-directory/cover.png","permalink":"/keycloak-federation-dun-annuaire-ldaps-active-directory/","title":"Keycloak : Federation d’un annuaire LDAPS (Active Directory)"},{"content":"Informations importantes Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Cette stack est faites pour du développement (avec persistance des données) et non de la production Bien modifier ce qu'il faut dans le stack (voir commentaires) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: app: image: quay.io/keycloak/keycloak:latest security_opt: - no-new-privileges:true command: start-dev environment: PROXY_ADDRESS_FORWARDING: \u0026#34;true\u0026#34; KC_FEATURES: token-exchange KC_PROXY: passthrough KEYCLOAK_ADMIN: admin # Indiquer un mot de passe pour le compte admin sur l\u0026#39;application keycloak KEYCLOAK_ADMIN_PASSWORD: MotDePasseTresSecure volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label. - conf:/opt/keycloak/conf - data:/opt/keycloak/data - providers:/opt/keycloak/providers - themes:/opt/keycloak/themes networks: # Indispensable pour communiquer avec traefik - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: - node.labels.keycloak_quay-io_conf == true - node.labels.keycloak_quay-io_data == true - node.labels.keycloak_quay-io_providers == true - node.labels.keycloak_quay-io_themes == true labels: # Activation de traefik - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Indiquer l\u0026#39;URL de l\u0026#39;application (keycloak.example.com) - traefik.http.routers.keycloak_quay-io-http.rule=Host(`keycloak.example.com`) - traefik.http.routers.keycloak_quay-io-http.entrypoints=http - traefik.http.routers.keycloak_quay-io-http.middlewares=https-redirect # Indiquer l\u0026#39;URL de l\u0026#39;application (keycloak.example.com) - traefik.http.routers.keycloak_quay-io-https.rule=Host(`keycloak.example.com`) - traefik.http.routers.keycloak_quay-io-https.entrypoints=https - traefik.http.routers.keycloak_quay-io-https.tls=true - traefik.http.routers.keycloak_quay-io-https.tls.certresolver=le - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin - traefik.http.routers.keycloak_quay-io-https.middlewares=hsts-headers - traefik.http.services.keycloak_quay-io.loadbalancer.server.port=8080 networks: traefik-public: external: true volumes: conf: driver: local data: driver: local providers: driver: local themes: driver: local Déploiement docker stack deploy -c stack.yml keycloak ","date":"2022-08-22T10:39:09+02:00","image":"/docker-swarm-stack-keycloak-v19-latest/cover.png","permalink":"/docker-swarm-stack-keycloak-v19-latest/","title":"Docker Swarm : Stack Keycloak (v19 latest)"},{"content":"Changelog 22/08/2022 : Fix traefik headers as same origin, trusted proxy, redirectregex Informations importantes Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Bien modifier ce qu'il faut dans le stack (voir commentaires) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: mariadb: image: mariadb command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --skip-innodb-read-only-compressed environment: # Indiquer les mots de passe souhaités MYSQL_ROOT_PASSWORD: MotDePasseTresSecure MYSQL_PASSWORD: MotDePasseTresSecure MYSQL_DATABASE: nextcloud MYSQL_USER: nextcloud volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label. - mariadb:/var/lib/mysql networks: - net deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: #- node.role == worker - node.labels.nextcloud_mariadb == true app: image: nextcloud environment: # Indiquer le mot de passe inscrit précédement MYSQL_PASSWORD: MotDePasseTresSecure MYSQL_DATABASE: nextcloud MYSQL_USER: nextcloud MYSQL_HOST: mariadb TRUSTED_PROXIES: traefik # Indiquer le domaine souhaité de l\u0026#39;application OVERWRITEHOST: nextcloud.example.com OVERWRITEPROTOCOL: https volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label. - nextcloud:/var/www/html networks: - net # Indispensable pour communiquer avec traefik - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: #- node.role == worker - node.labels.nextcloud_nextcloud == true labels: # Activation de traefik - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Indiquer le domaine souhaité pour l\u0026#39;application - traefik.http.routers.nextcloud-http.rule=Host(`nextcloud.example.com`) - traefik.http.routers.nextcloud-http.entrypoints=http - traefik.http.routers.nextcloud-http.middlewares=https-redirect # Indiquer le domaine souhaité pour l\u0026#39;application - traefik.http.routers.nextcloud-https.rule=Host(`nextcloud.example.com`) - traefik.http.routers.nextcloud-https.entrypoints=https - traefik.http.routers.nextcloud-https.tls=true - traefik.http.routers.nextcloud-https.tls.certresolver=le # Middleware pour nextcloud - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.permanent=true - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.regex=https://(.*)/.well-known/(card|cal)dav - traefik.http.middlewares.nextcloud-redirectregex.redirectRegex.replacement=https://$${1}/remote.php/dav/ - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin - traefik.http.routers.nextcloud-https.middlewares=hsts-headers,nextcloud-redirectregex # Indiquer le port utiliser de l\u0026#39;application - traefik.http.services.nextcloud.loadbalancer.server.port=80 networks: net: driver: overlay attachable: true traefik-public: external: true volumes: mariadb: driver: local nextcloud: driver: local Déploiement docker stack deploy -c stack.yml nextcloud ","date":"2022-08-18T13:00:13+02:00","image":"/docker-swarm-stack-nextcloud/cover.png","permalink":"/docker-swarm-stack-nextcloud/","title":"Docker Swarm : Stack Nextcloud"},{"content":"Changelog 22/08/2022 : Ajout information depreciated Informations importantes Nécessite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Bien modifier ce qu'il faut dans le stack (voir commentaires) Ce stack utilise une image docker provenant de jboss qui est un keycloak en v16. La dernière version actuelle est la v19. Stack disponible ici : /docker-swarm-stack-keycloak-v19-latest/\nFichier stack.yml version: \u0026#39;3.3\u0026#39; services: postgres: image: postgres environment: POSTGRES_DB: keycloak POSTGRES_USER: keycloak # Indiquer le mot de passe souhaité POSTGRES_PASSWORD: MotDePasseTresSecure volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro - postgres_data:/var/lib/postgresql/data networks: - net deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph) - node.labels.keycloak_postgres_data == true keycloak: image: jboss/keycloak:latest environment: PROXY_ADDRESS_FORWARDING: \u0026#39;true\u0026#39; DB_VENDOR: POSTGRES DB_ADDR: postgres DB_DATABASE: keycloak DB_USER: keycloak # Indiquer le mot de passe inscrit dans le service postgre DB_PASSWORD: MotDePasseTresSecure KEYCLOAK_USER: admin # Indiquer le mot de passe souhaité KEYCLOAK_PASSWORD: MotDePasseTresSecure volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro networks: - net # Réseau utilisé par le conteneur traefik - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M labels: # Activation de traefik - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Modifier le domaine de l\u0026#39;application keyclaok - traefik.http.routers.keycloak-http.rule=Host(`keycloak.example.com`) - traefik.http.routers.keycloak-http.entrypoints=http - traefik.http.routers.keycloak-http.middlewares=https-redirect - traefik.http.routers.keycloak-https.rule=Host(`keycloak.example.com`) - traefik.http.routers.keycloak-https.entrypoints=https - traefik.http.routers.keycloak-https.tls=true - traefik.http.routers.keycloak-https.tls.certresolver=le # Indiquer le port utiliser de l\u0026#39;application - traefik.http.services.keycloak.loadbalancer.server.port=8080 networks: net: driver: overlay attachable: true traefik-public: external: true volumes: postgres_data: driver: local Déploiement docker stack deploy -c stack.yml keycloak ","date":"2022-08-18T11:47:44+02:00","image":"/docker-swarm-stack-keycloak/cover.png","permalink":"/docker-swarm-stack-keycloak/","title":"Docker Swarm : Stack Keycloak (v16 depreciated)"},{"content":"Informations importantes Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/ Bien modifier ce qu'il faut dans le stack (voir commentaires) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: rocketchat: image: registry.rocket.chat/rocketchat/rocket.chat:latest environment: MONGO_URL: \u0026#34;mongodb://mongodb:27017/rocketchat?replicaSet=rs0\u0026#34; MONGO_OPLOG_URL: \u0026#34;mongodb://mongodb:27017/local?replicaSet=rs0\u0026#34; # Modifier l\u0026#39;URL d\u0026#39;accès à l\u0026#39;application RocketChat ROOT_URL: https://rocketchat.example.com PORT: 3000 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro - uploads:/app/uploads networks: - net # Réseau utilisé par le conteneur traefik - traefik-public deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph) - node.labels.rocketchat_uploads == true labels: # Activation de traefik - traefik.enable=true - traefik.docker.network=traefik-public - traefik.constraint-label=traefik-public # Modifier le domaine de l\u0026#39;application RocketChat - traefik.http.routers.rocketchat-http.rule=Host(`rocketchat.example.com`) - traefik.http.routers.rocketchat-http.entrypoints=http - traefik.http.routers.rocketchat-http.middlewares=https-redirect # Modifier le domaine de l\u0026#39;application RocketChat - traefik.http.routers.rocketchat-https.rule=Host(`rocketchat.example.com`) - traefik.http.routers.rocketchat-https.entrypoints=https - traefik.http.routers.rocketchat-https.tls=true - traefik.http.routers.rocketchat-https.tls.certresolver=le - traefik.http.services.rocketchat.loadbalancer.server.port=3000 mongodb: image: docker.io/bitnami/mongodb:4.4 environment: MONGODB_REPLICA_SET_MODE: primary MONGODB_REPLICA_SET_NAME: rs0 MONGODB_PORT_NUMBER: 27017 MONGODB_INITIAL_PRIMARY_HOST: mongodb MONGODB_INITIAL_PRIMARY_PORT_NUMBER: 27017 MONGODB_ADVERTISED_HOSTNAME: mongodb MONGODB_ENABLE_JOURNAL: \u0026#34;true\u0026#34; ALLOW_EMPTY_PASSWORD: \u0026#34;yes\u0026#34; volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /etc/localtime:/etc/localtime:ro - mongodb_data:/bitnami/mongodb networks: - net deploy: #resources: #limits: #cpus: \u0026#39;0.50\u0026#39; #memory: 1024M #reservations: #cpus: \u0026#39;0.25\u0026#39; #memory: 512M placement: constraints: # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph) - node.labels.rocketchat_mongodb_data == true networks: net: driver: overlay attachable: true # Réseau utilisé par le conteneur traefik traefik-public: external: true volumes: mongodb_data: driver: local uploads: driver: local Deploiement docker stack deploy -c stack.yml rocketchat ","date":"2022-08-18T11:34:33+02:00","image":"/docker-swarm-stack-rocket-chat/cover.png","permalink":"/docker-swarm-stack-rocket-chat/","title":"Docker Swarm : Stack Rocket.Chat"},{"content":"Export variables export EMAIL=mon@email.com export DOMAIN=traefik.example.com export USERNAME=admin export PASSWORD=MotDePasseTresSecure export HASHED_PASSWORD=$(openssl passwd -apr1 \u0026#34;$PASSWORD\u0026#34;) Fichier stack.yml version: \u0026#39;3.3\u0026#39; services: traefik: # Use the latest Traefik image image: traefik:latest ports: # Listen on port 80, default for HTTP, necessary to redirect to HTTPS - target: 80 published: 80 mode: host # Listen on port 443, default for HTTPS - target: 443 published: 443 mode: host deploy: placement: constraints: # Make the traefik service run only on the node with this label # as the node with it has the volume for the certificates - node.labels.traefik-public.traefik-public-certificates == true labels: # Enable Traefik for this service, to make it available in the public network - traefik.enable=true # Use the traefik-public network (declared below) - traefik.docker.network=traefik-public # Use the custom label \u0026#34;traefik.constraint-label=traefik-public\u0026#34; # This public Traefik will only use services with this label # That way you can add other internal Traefik instances per stack if needed - traefik.constraint-label=traefik-public # admin-auth middleware with HTTP Basic auth # Using the environment variables USERNAME and HASHED_PASSWORD - traefik.http.middlewares.admin-auth.basicauth.users=${USERNAME?Variable not set}:${HASHED_PASSWORD?Variable not set} # https-redirect middleware to redirect HTTP to HTTPS # It can be re-used by other stacks in other Docker Compose files - traefik.http.middlewares.https-redirect.redirectscheme.scheme=https - traefik.http.middlewares.https-redirect.redirectscheme.permanent=true # traefik-http set up only to use the middleware to redirect to https # Uses the environment variable DOMAIN - traefik.http.routers.traefik-public-http.rule=Host(`${DOMAIN?Variable not set}`) - traefik.http.routers.traefik-public-http.entrypoints=http - traefik.http.routers.traefik-public-http.middlewares=https-redirect # traefik-https the actual router using HTTPS # Uses the environment variable DOMAIN - traefik.http.routers.traefik-public-https.rule=Host(`${DOMAIN?Variable not set}`) - traefik.http.routers.traefik-public-https.entrypoints=https - traefik.http.routers.traefik-public-https.tls=true # Use the special Traefik service api@internal with the web UI/Dashboard - traefik.http.routers.traefik-public-https.service=api@internal # Use the \u0026#34;le\u0026#34; (Let\u0026#39;s Encrypt) resolver created below - traefik.http.routers.traefik-public-https.tls.certresolver=le # Enable HTTP Basic auth, using the middleware created above - traefik.http.routers.traefik-public-https.middlewares=admin-auth # Define the port inside of the Docker service to use - traefik.http.services.traefik-public.loadbalancer.server.port=8080 volumes: # Add Docker as a mounted volume, so that Traefik can read the labels of other services - /var/run/docker.sock:/var/run/docker.sock:ro # Mount the volume to store the certificates - traefik-public-certificates:/certificates command: # Enable Docker in Traefik, so that it reads labels from Docker services - --providers.docker # Add a constraint to only use services with the label \u0026#34;traefik.constraint-label=traefik-public\u0026#34; - --providers.docker.constraints=Label(`traefik.constraint-label`, `traefik-public`) # Do not expose all Docker services, only the ones explicitly exposed - --providers.docker.exposedbydefault=false # Enable Docker Swarm mode - --providers.docker.swarmmode # Create an entrypoint \u0026#34;http\u0026#34; listening on address 80 - --entrypoints.http.address=:80 # Create an entrypoint \u0026#34;https\u0026#34; listening on address 443 - --entrypoints.https.address=:443 # Create the certificate resolver \u0026#34;le\u0026#34; for Let\u0026#39;s Encrypt, uses the environment variable EMAIL - --certificatesresolvers.le.acme.email=${EMAIL?Variable not set} # Store the Let\u0026#39;s Encrypt certificates in the mounted volume - --certificatesresolvers.le.acme.storage=/certificates/acme.json # Use the TLS Challenge for Let\u0026#39;s Encrypt - --certificatesresolvers.le.acme.tlschallenge=true # Enable the access log, with HTTP requests - --accesslog # Enable the Traefik log, for configurations and errors - --log # Enable the Dashboard and API - --api # Set CA Server fir Let\u0026#39;s Encrypt # - --certificatesresolvers.le.acme.caServer= networks: # Use the public network created to be shared between Traefik and # any other service that needs to be publicly available with HTTPS - traefik-public volumes: # Create a volume to store the certificates, there is a constraint to make sure # Traefik is always deployed to the same Docker node with the same volume containing # the HTTPS certificates traefik-public-certificates: networks: # Use the previously created public network \u0026#34;traefik-public\u0026#34;, shared with other # services that need to be publicly available via this Traefik traefik-public: external: true Déploiement docker stack deploy -c stack.yml traefik ","date":"2022-08-18T11:28:10+02:00","image":"/docker-swarm-stack-traefik/cover.png","permalink":"/docker-swarm-stack-traefik/","title":"Docker Swarm : Stack Traefik"},{"content":"docker-compose.yml version: \u0026#39;3\u0026#39; services: agent: image: portainer/agent container_name: portainer_agent restart: unless-stopped security_opt: - no-new-privileges:true volumes: - /etc/localtime:/etc/localtime:ro - /var/run/docker.sock:/var/run/docker.sock:ro - /var/lib/docker/volumes:/var/lib/docker/volumes ports: - 9001:9001 ","date":"2022-08-15T16:55:25+02:00","image":"/docker-compose-portainer-agent/cover.png","permalink":"/docker-compose-portainer-agent/","title":"Docker-Compose : Portainer Agent"},{"content":"Contexte Avec le logiciel terminator, il peut arriver que le broadcast de commande double les caractères tappés sur le clavier.\nExemple :\nDans mon contexte, je suis avec la version de terminator 2.1.1 fournit par les dépôts de Pop_OS 22.04.\nFix terminator Pour corriger ce phénomène, j'ai édité le script de terminator.\nTout d'abord :\nOù est terminator ? whereis terminator # terminator: /usr/bin/terminator /usr/share/terminator /usr/share/man/man1/terminator.1.gz Editer le script de lancement : sudo vi /usr/bin/terminator Ajouter ceci juste après les imports en début de fichier : \u0026#34;\u0026#34;\u0026#34;Modifi broadcast twice\u0026#34;\u0026#34;\u0026#34; os.environ[\u0026#39;DBUS_SESSION_BUS_ADDRESS\u0026#39;]=\u0026#39;\u0026#39; \u0026#34;\u0026#34;\u0026#34;End of modify broadcast twice\u0026#34;\u0026#34;\u0026#34; Enregistrer les modifications\nRelancer terminator\nVérification Le broadcast de commande dans terminator est maintenant pleinement fonctionnel 🙂\n","date":"2022-08-15T16:46:56+02:00","image":"/terminal-fix-broadcast-command-twice-in-terminator/cover.png","permalink":"/terminal-fix-broadcast-command-twice-in-terminator/","title":"Terminal: Fix broadcast command twice in Terminator"},{"content":"docker-compose.yml version: \u0026#39;3\u0026#39; services: portainer: image: portainer/portainer-ce:latest container_name: portainer_server restart: unless-stopped security_opt: - no-new-privileges:true volumes: - /etc/localtime:/etc/localtime:ro - /var/run/docker.sock:/var/run/docker.sock:ro - ./portainer-data:/data ports: # Only to http # - 9000:9000 # Only to Edge Agent # - 8000:8000 # Only to https - 9443:9443 ","date":"2022-08-13T17:53:08+02:00","image":"/docker-compose-portainer/cover.png","permalink":"/docker-compose-portainer/","title":"Docker-Compose : Portainer Server"},{"content":"#!/bin/bash # purge old apt configuration files sudo rm -rf /var/lib/apt/lists/ sudo apt clean; sudo apt autoclean # get fresh configuration files, resolve package conflicts sudo apt update sudo dpkg --configure -a sudo apt --fix-broken install # and finally resume the upgrade sudo apt upgrade -y ","date":"2022-08-02T10:10:08+02:00","image":"/pop_os-22-04-fix-apt/cover.png","permalink":"/pop_os-22-04-fix-apt/","title":"Pop!_OS 22.04 : Fix apt"},{"content":"Le but de cette documentation va être de configurer un serveur VPN dit SSL Road Warrior sur OPNsense (Un PFsense en mieux et totalement opensource :P). Les clients VPN pourront accéder à des ressources sur le réseau LAN distant de façon sécurisé.\nLe serveur VPN sera OpenVPN et celui-ci sera configuré de façon à accepter les connexions sur le port HTTPS (TCP 443). De cette façon, l'accès pourra se faire de n'importe où car ce port n'est pas (ou très très très rarement) filtré sur une connexion standard à Internet.\nUne autorité de certification sera créé pour délivrer un certificat afin de sécuriser les échanges.\nUn exemple de configuration d'un client sous Windows 10 est traité à la fin.\nLet's go !!!\nContexte Voici la version utilisée d'OPNsense :\nOPNsense 22.1.2_2-amd64 FreeBSD 13.0-STABLE OpenSSL 1.1.1m 14 Dec 2021 Au niveau des interfaces de paramétrées :\nLAN = 192.168.56.254/24 WAN = IP_PUBLIC Aucune configuration particulière à été apportée après l'installation d'OPNsense à part l'adressage IP des interfaces WAN et LAN.\nTout le paramétrage sera à réaliser à travers l'interface web d'administration d'OPNsense.\nPKI Création de l\u0026rsquo;authorité de certification Dans System (1), Trust (2), Authorities (3), cliquer sur + (4) pour ajouter une authorité de certification :\nSélectionner Create an internal Certificate Authority :\nJe ne vais pas traiter la partie algorithme ni de type ou de longueur de clef. Je laisse les paramètres par défaut mais dans un contexte de production, il sera important de modifier ces différents paramètres.\nEntrer une Descriptive name ainsi que le Common Name et les informations désirées.\nEnregistrer la nouvelle authorité de certification :\nGénération du certificat serveur Dans Certificates (1), cliquer sur + (2) pour ajouter un nouveau certificat :\nSélectionner Create an internal Certificate :\nMême remarque que précédement concernant la partie algorithme, clef...\nEntrer une Descriptive name. Sélectionner le bon Certificate authority et le type Server Certificate.\nLes informations provenant de l'authorité de certification doivent être pré-remplies.\nRenseigner le Common Name :\nEnregistrer le nouveau certificat :\nOpenVPN Dans VPN (1), OpenVPN (2), Servers (3), cliquer sur l'icône du Wizard (4) :\nEn passant par le wizard, il y aura la possibilité de créer automatiquement les 2 règles nécessaires pour autoriser le flux provenant des clients VPN.Sinon, il faudra les ajouter à la main, ça fonctionne très bien aussi.\nType de serveur d'authentification : Local User Access\nAuthorité de certification : OPNsense-CA\nCertificat : OPNsense-VPN-Cert\nDans la partie General OpenVPN Server Information, renseigner les paramètres suivants :\nLes clients se connecteront sur l'interface WAN d'OPNsense par le protocol TCP sur le port 443. Par défaut OpenVPN écoute sur le port 1194 en UDP. Pour que la connexion soit possible depuis n'importe quel réseau Internet, il faut bien modifier ce paramètre. C'est quasiment indétectablement par les pare-feux pour faire la différence avec du flux HTTPS (du stateful inspection permet de faire la différence).\nDans la partie Tunnel Settings, renseigner les paramètres suivants :\nDans IPv4 Tunnel Network, entrer le réseau virtuel qui sera attribué aux clients VPN.\nDans IPv4 Local Network, entrer le réseau LAN qui doit être accessible aux clients VPN.\nLe reste des paramètres sont laissés par défaut. Ils pourront être définis si besoin mais ne seront pas traités dans cet article.\nPasser à la prochaine étape en cliquant sur Next.\nCocher Firewall Rule et OpenVPN Rule pour générer les 2 règles adéquats dans le pare-feu :\nValider en cliquant sur Next puis Finish pour terminer le paramétrage du serveur VPN.\nUtilisateur Création d\u0026rsquo;un utilisateur Dans System (1), Access (2), Users (3), cliquer sur + (4) pour ajouter un nouveau utilisateur :\nRenseigner un Username et un Password :\nPlus bas, cocher Click to create a user certificate :\nTerminer en cliquant sur Save. Cela déclenche la génération d'un certificat.\nGénération du certificat utilisateur Sélectionner Create an internal Certificate :\nEntrer une Descriptive name. Sélectionner le bon Certificate authority et le type Client Certificate.\nLes informations provenant de l'authorité de certification doivent être pré-remplies.\nRenseigner le Common Name.\nEnregistrer le nouveau certificat.\nLe certificat est maintenant associé à l'utilisateur :\nTerminer en cliquant sur Save.\nClient Windows Exportation de la configuration client Dans VPN (1), OpenVPN (2), Client Export (3), télécharger l'archive contenant la confirmation client d'OpenVPN avec le certificat utilisateur correspondant :\nEn cochant Windows Certificate System Store, un certificat .crt est récupéré. Malgré le faites de l'inscrire (ou d'inscrire le CA) dans le magasin (des certificats de l'ordinateur) des autorités de certification racines de confiance, celui-ci ne sera pas approuvé.\nLe contenu de l'archive récupérée contient les éléments suivant :\nOPNsense_VPN_Server_batman_vpn-tls.key OPNsense_VPN_Server_batman_vpn.ovpn OPNsense_VPN_Server_batman_vpn.p12 Installation du client Sur le poste client en Windows 10 :\nTélécharger le client OpenVPN Community : https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.7-I602-amd64.msi\nInstaller le client OpenVPN (Attention, il faudra des droits d'administrateur sur le poste Windows).\nUn message d'avertissement indique qu'il n'y a aucun profil de connexion.\nCopier le contenu de l'archive préalablement exporter dans le répertoire %USERPROFILE%\\OpenVPN\\config :\nSe connecter :\nUn message peut survenir indiquant que l'utilisateur Windows doit faire partie du groupe local de la machine OpenVPN Administrators :\nSi contexte de domaine, une GPO peut appliquer ce paramètre automatiquement.\nS'identifier avec le compte utilisateur créé précédement dans OPNsense :\nLa connexion VPN est établie :\n","date":"2022-07-12T23:21:48+02:00","image":"/opnsense-configuration-dun-vpn-ssl-road-warrior-avec-pki/cover.jpg","permalink":"/opnsense-configuration-dun-vpn-ssl-road-warrior-avec-pki/","title":"OPNsense : Configuration d’un VPN SSL Road Warrior avec PKI"},{"content":"Cet article fait office de PoC (Proof of Concept) sur la mise en place d'une authentification SSO (Single-Sign-On) à travers le service ADFS (Active Directory Federation Services) de Microsoft et l'application Open Source Nextcloud.\nCela va permettre aux utilisateurs de la plateforme Nextcloud de s'authentifier avec leur compte Active Directory en utilisant le protocole SAML dans des contextes réseaux totalement différents.\nEnvironnement Environnements déjà déployés : Nextcloud v24.0.2 Contrôleur de domaine Windows Serveur 2019 Informations : Domaine AD : aukfood.lan Nom serveur AD : adfs-dev Domaine publique utilisé : example.com (remplace les parties floutées dans les captures d'écrans) URL Nextcloud : https://nc-dev.example.com Enregistrement DNS pour l'ADFS : adfs2-dev.example.com Génération du certificat Let\u0026rsquo;s Encrypt A effectuer sur le serveur Windows (Tous les services seront déployés sur le contrôleur de domaine) :\nInstallation de IIS en Powershell :\nInstall-WindowsFeature -name Web-Server -IncludeManagementTools Faire un enregistrement de type A dans une zone DNS publique pour le serveur IIS :\nadfs2-dev IN A xxx.xxx.xxx.xxx Dans ce PoC, le domaine publique utilisé sera example.com.\nCréer la racine du site web pour résoudre le challenge :\nmkdir c:\\inetpub\\adfs2-dev.example.com Créer un fichier index.html dans la racine du site web :\nnotepad c:\\inetpub\\adfs2-dev.example.com\\index.html Insérer le contenu suivant puis enregistrer :\nHello world Ouvrir la console de Gestionnaire des services Internet (IIS).\nSupprimer le site web par défaut.\nAjouter un nouveau site web :\nTélécharger le client ACME pour Let's Encrypt ici : https://www.win-acme.com/\nA l'heure actuelle, la dernière version : https://github.com/win-acme/win-acme/releases/download/v2.1.22.1267/win-acme.v2.1.22.1267.x64.pluggable.zip\nDécompresser l'archive et déplacer le fichier Web_Config.xml à la racine du site web.\nRedémarrer le site web.\nLancer une ligne de commandes et se positionner dans le répertoire préalablement extrait.\nExécuter wacs.exe :\nCréer un nouveau certificat (Choix N).\nSélectionner le site ajouté au préalable dans IIS :\nPeu importe si le certificat est de type wildcard ou non.\nLe certificat est généré avec une tâche planifiée qui va renouveller le certificat automatiquement :\nUne liaison https (vhost) a été automatiquement générée pour le site web :\nCe certificat est celui qui sera exploité par le service AD FS.\nExportation du certificat au format pfx Re-lancer l'outil wacs.exe.\nFaire le choix A (Manage renewals) :\nAfficher les détails avec D, puis noter le .pfx password :\nOuvrir le dossier des certificats Let's Encrypt :\nexplorer C:\\ProgramData\\win-acme\\acme-v02.api.letsencrypt.org\\Certificates\\ Sélectionner le certificat .pfx correspondant puis démarrer l'assistant d'importation du certificat au niveau de l'ordinateur local (Pour rappel : c'est le DC) :\nSaisir le mot de passe de la clé privée (.pfx password noté au préalable) et cocher Marquer cette clé comme exportable :\nSélectionner automatiquement le magasin de certificats.\nTerminer l'assistant d'importation du certificat.\nOuvrir la gestion des certificats de l'ordinateur local :\ncertlm.msc Dans \u0026quot;Personnel\\Certificats\u0026quot; (1), sélectionner le certificat préalablement importé (2). Dans \u0026quot;Toutes les tâches\u0026quot; (3), sélectionner \u0026quot;Exporter\u0026quot; (4) :\nIl est maintenant possible d'exporter la clé privée du certificat :\nExporter toutes les propriétés étendues :\nSaisir un mot de passe pour protéger la clé privée :\nSpécifier le nom du fichier à exporter au format pfx.\nTerminer l'assistant d'exportation du certificat.\nInstallation AD FS Installer le service ADFS-Federation en Powershell :\nInstall-WindowsFeature -name ADFS-Federation -IncludeManagementTools Créer la clé racine du service de distribution de clés en Powershell :\nAdd-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) La configuration du service se fera en mode graphique à travers le gestionnaire de serveur servermanager.exe :\nCréer le premier serveur de fédération dans une batterie de serveurs de fédération.\nImporter le certificat préalablement exporté au format .pfx (1). Puis, entrer un nom pour le service FS (2) :\nSpécifier un compte de service :\nUne base de données SQL Server peut être exploitée. Dans ce PoC, une base de données interne Windows est utilisée.\nAprès examen des options, la configuration peut être lancée :\nRedémarrer le serveur Windows.\nActiver la page de login de l'ADFS en Powershell :\nSet-AdfsProperties -EnableIdpInitiatedSignonPage $true Tester la connexion : https://adfs2-dev.example.com/adfs/ls/IdpInitiatedSignon.aspx\nParamétrage Nextcloud Se connecter en SSH sur le serveur Nextcloud et se positionner à la racine du projet web :\ncd /var/www/nc-dev.example.com/www/ Installer l'application user_saml avec occ (A adapter selon le propriétaire du projet web) :\nsudo -u nextcloud php8.0 occ app:install user_saml # user_saml 5.0.2 installed # user_saml enabled Se connecter à l'interface web du Nextcloud en admin.\nSe rendre dans \u0026quot;Paramètres\u0026quot; (1) / \u0026quot;Authentification SSO \u0026amp; SAML\u0026quot; (2). Puis \u0026quot;Utiliser l'authentification SAML intégrée\u0026quot; (3) :\nDans la partie \u0026quot;Général\u0026quot;, entrer l'Attribut pour relier l'UID :\nhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn C'est l'UPN du compte de l'utilisateur dans l'AD qui fera office de nom d'utilisateur au sein de l'instance Nextcloud.\nConfigurer les options IdP :\nIdentifiant de l'entité IdP : http://adfs2-dev.example.com/adfs/services/trust\nURL cible du fournisseur d'identités à qui le fournisseur de service enverra la requête d'authentification : https://adfs2-dev.example.com/adfs/ls\nCliquer sur \u0026quot;Hide optional Identity Provider settings\u0026quot; pour accéder au champ Certificat public X.509 de l'IdP.\nSur le serveur Windows, ouvrir la console de gestion de l'ADFS :\n%windir%\\ADFS\\Microsoft.IdentityServer.msc Dans \u0026quot;Service\u0026quot; / \u0026quot;Certificats\u0026quot; (1), Afficher le certificat (2) utilisé pour la signature de jetons :\nDans l'onglet \u0026quot;Détails\u0026quot;, copier dans un fichier :\nExporter au format : *X.509 encodé en base 64 (.cer)**\nSpécifier un nom de fichier pour l'export.\nCopier le contenu de ce fichier exporté au format .cer et le coller dans le champ Certificat public X.509 de l'IdP dans Nextcloud :\nMapper les attributs suivants au minimum :\nAttribut pour relier le nom d'utilisateur : http://schemas.microsoft.com/identity/claims/displayname Attribut pour relier l'adresse mail : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Télécharger le fichier metadata.xml :\nPour avoir la possibilité de garder l'authentification avec la base utilisateur interne de Nextcloud, cocher Autoriser l'utilisation de plusieurs systèmes d'authentification :\nBien vérifier l'enregistrement du paramétrage en quittant le menu \u0026quot;Authentification SSO \u0026amp; SAML\u0026quot; et en y revenant (Surtout sur le paramétrage du point précédent).\nParamétrage AD FS Sur le serveur Windows, ouvrir la console de gestion de l'AD FS :\n%windir%\\ADFS\\Microsoft.IdentityServer.msc Ajouter une approbation de partie de confiance :\nPrendre en charge les revendications.\nImporter les données concernant la partie de confiance à partir du fichier metadata.xml téléchargé préalablement :\nSaisir un nom pour cette approbation et éventuellement des notes.\nSélectionner une stratégie de contrôle d'accès. Dans ce PoC, tout le monde sera autorisé :\nLa partie de confiance a été configurée à l'aide du fichier metadata.xml fourni.\nEditer la stratégie d'émission de revendication :\n2 règles de revendication de transformations sont à ajouter au minimum :\nuserPrincipalName Email Le modèle de régle de revendication à suivre est : Envoyer les attributs LDAP en tant que revendications.\nRègle userPrincipalName :\nRègle Email :\nAppliquer les 2 règles ajoutées.\nVérification de l\u0026rsquo;authentification Se connecter à Nextcloud, et choisir de s'authentifier au travers une Connection SSO \u0026amp; SAML :\nUtiliser un compte de l'Active Directory autoriser à se connecter à travers l'AD FS :\nCongratulations !\nRessources en vrac https://blog.kveer.fr/login-nextcloud-saml-adfs/\nhttps://www.virtualease.fr/nextcloud-authentication-active-directory-sso-via-adfs-saml/\nhttp://os-zenia.blogspot.com/2021/01/nextcloud-sso-adfs.html\nhttps://rephlex.de/blog/2018/04/05/how-to-connect-nextcloud-to-active-directory-using-ad-fs-without-losing-your-mind/\nhttps://www.myworkdrive.com/fr/support/adfs-single-sign-sso-integration-guide/\nhttps://www.infotechram.com/wp-content/uploads/2020/07/Installing-Active-Directory-Federation-Services.pdf\nhttps://www.alitajran.com/export-lets-encrypt-certificate-in-windows-server/\nhttps://www.rcfed.com/SAMLWSFed/CommonClaimtypelist\nhttps://docs.microsoft.com/fr-fr/dotnet/api/system.security.claims.claimtypes?view=net-6.0\nhttps://docs.microsoft.com/fr-fr/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon\nhttps://help.mulesoft.com/s/article/Configuring-ADFS-SLO-endpoint\nhttps://pitstop.manageengine.com/portal/en/kb/articles/saml-auto-login-with-adfs\n","date":"2022-07-08T12:00:33+02:00","image":"/nextcloud-integration-dune-authentification-sso-avec-ad-fs/cover.png","permalink":"/nextcloud-integration-dune-authentification-sso-avec-ad-fs/","title":"Nextcloud : Intégration d’une authentification SSO avec AD FS"},{"content":"Contexte Il est possible de donner aux utilisateurs, un moyen de pouvoir importer plusieurs données de leur compte Google au sein de leur compte Nextcloud comme :\nLes agendas Les contacts Les photos Les fichiers Pour se faire, plusieurs APIs Google vont être exploitées.\nGoogle integration Se connecter en admin sur l'interface web du Nextcloud.\nRechercher, télécharger, installer l'application Google integration.\nDans les Paramètres d'Administration, se rendre dans Comptes connectés (1). C'est à cet endroit qu'il va falloir renseigner l'ID Client et le Secret client (2) afin de pouvoir autoriser les utilisateurs à s'authentifier plus tard sur leur compte Google afin de procéder à l'importation de leur données dans leur espace Nextcloud.\nCliquer sur Paramètres de l'API Google (3) afin de créer une application OAuth Google et de récupérer les informations à renseigner (2) pour finaliser l'intégration de Google.\nS'identifier avec un compte Google sur la Google Cloud Platform.\nCe compte Google sera exploité uniquement pour l'API Google.\nGoogle Cloud Platform Projet Créer un nouveau Projet.\nNommer le projet (1). Puis, valider (2).\nConsentement Dans Ecran de consentement OAuth (1), définir le type d'utilisateur (2). Puis, valider (3).\nEntrer le nom de l'application demandant l'autorisation (1) ainsi que l'adresse mail d'assistance (2).\nIl est possible de spécifier un logo qui apparaitra sur la page de consentement lorsque l'utilisateur saisira ces informations de compte Google.\nTout en bas de la page, indiquer vos coordonnées de développeur. Puis Enregistrer et continuer.\nSur l'écran suivant, Enregistrer et continuer tout en bas de la page.\nA ce stade le projet a un status de publication à l'état de Test. Il est nécessaire d'ajouter (1) les comptes Google (2) que les utilisateurs utiliseront pour les autoriser à utiliser ce projet. Puis, Enregistrer et continuer.\nUn résumé de l'écran de consentement paramétré est afficher.\nIdentifiants Maintenant, il faut générer des identifiants de type OAuth dans le projet Google Cloud Platform créé. Ceux-ci seront à renseigner par la suite dans le paramétrage de Nextcloud.\nDans le menu API et services à gauche, se rendre dans Identifiants (1). Créer des identifiants (2) de type ID client OAuth (3).\nRenseigner le Type d'application (1). Indiquer un Nom (2) pour identifier le client dans la console Google Cloup Platform. Indiquer l'URI de redirection (3) autorisés. Cette URI est disponible dans l'interface Nextcloud vu précédemment, dans la parti Intégration de Google. Puis, Créer (4).\nl'ID client et le code secret du client sont disponible.\nRetourner sur l'interface web de Nextcloud dans la partie Intégration de Google. Puis, indiquer l'ID client (1) et le Secret client (2).\nAPI Toujours sur Google Cloud Platform, dans API et services, se rendre dans Bibliothèque. Rechercher et activer les API suivantes : Google Drive API Google Calendar API Google People API Photos Library API Nextcloud Dorénavant, lorsqu'un utilisateur se connectera sur l'interface web de son Nextcloud, une section Migration de données (1) est disponible dans ses paramètres. Cela va permettre à l'utilisateur de connecter son compte Google (2) afin de migrer les données voulues vers son compte Nextcloud.\nUne fois que l'utilisateur a connecté son compte Google et autorisé l'accès aux données à migrer, il suffit de sélectionner les éléments à importer.\nSi aucune données n'est présente dans une des fonctionnalités Google, celle-ci ne sera pas proposée à l'import.\n","date":"2022-06-16T08:00:16+02:00","image":"/nextcloud-importer-ses-donnees-de-google/cover.png","permalink":"/nextcloud-importer-ses-donnees-de-google/","title":"Nextcloud : Importer ses données de Google"},{"content":"Contexte Je suis tombé par hasard sur ce projet : https://github.com/quantumsheep/sshs\nCelui-ci permet d'avoir une interface utilisateur pour SSH dans un terminal.\nIl y a également la possibilité d'effectuer des recherches.\nInstallation Il est possible d'avoir SSHS sous Windows, Mac, Linux.\nDans mon cas, je travaille sous Pop!_OS, j'ai réalisé l'installation à partir des sources.\nAvant tout chose, il faut installer le compilateur pour Go pour Golang.\nPour ma part, je l'ai faites avec snap :\nsnap install go --classic Ensuite, j'ai cloné le projet avec git :\ngit clone https://github.com/quantumsheep/sshs.git Puis, j'ai compilé les sources et installé SSHS :\ncd sshs make make install Réaliser l'installation avec make install en tant que root.\nIl est maintenant possible de lancer le programme avec la commande :\nsshs Utilisation Il n'y a pas de manuel avec la commande sshs.\nSans auncun argument, SSHS va charger le fichier ~/.ssh/config (et éventuellement les Include dedans).\nCependant, il y a quelques options possibles que l'on peut obtenir avec :\nsshs --help Voici le retour de l'aide succinte :\nssh clients manager Usage: sshs [flags] Flags: -c, --config string SSH config file (default \u0026#34;~/.ssh/config\u0026#34;) -h, --help help for sshs -p, --proxy Display full ProxyCommand -s, --search string Host search filter --sort Sort hosts by name (default true) -v, --version version for sshs ","date":"2022-06-15T10:21:30+02:00","image":"/ssh-sshs-une-interface-utilisateur-pour-ssh-dans-le-terminal/cover.jpg","permalink":"/ssh-sshs-une-interface-utilisateur-pour-ssh-dans-le-terminal/","title":"SSH : SSHS, une interface utilisateur pour SSH dans le terminal"},{"content":"Contexte Le but est d'ajouter un calendrier Google (Google Agenda) dans les calendriers d'un utilisateur Nextcloud.\nLe calendrier Google restera privé et ne passera donc pas en publique.\nDe plus, il ne sera accessible qu'en lecture. C'est comme ça...\nAttention : L'accès au calendrier ne se fera pas avec les credentials du compte mais à l'aide d'une URL secrète (A ne surtout pas diffuser).\nCôté Google Se connecter au compte Google à ajouter dans Nextcloud. Dans la partie gauche de l'interface web, cliquer sur les 3 petits points à droite du calendrier à intégrer dans Nextcloud (1). Puis sélectionner Paramètres et partage (2). Faire défiler jusqu'à la partie Intégrer l\u0026#039;agenda. L'adresse secrète au format iCal est disponible (1). Afin de mettre cette adresse dans le presse-papier, cliquer sur l'icône \u0026quot;Copier\u0026quot; en bout de ligne (2). En utilisant cette adresse secrète, il n'est pas obligatoire de rendre l'agenda publique. De ce fait, le calendrier Google restera privé. Attention toutefois, son accès se fait sans credentials mais uniquement en lecture seule.\nCôté Nextcloud Se connecter sur le compte Nextcloud qui doit bénificer de l'agenda Google et se rendre dans la section Agenda. Ajouter un nouvel agenda (1). Puis, créer un nouvel abonnement par lien (2). Coller l'adresse secrète récupérée précédemment. Puis, valider. Un nouveau calendrier calendar.google.com a été ajouté en lecture seule. Il est possible de la renommer pour lui donner un nom plus explicite. Taux de rafraîchissement Le taux de rafraîchissement (refresh rate), d'une souscription à un calendrier dans Nextcloud, est d'une fois toutes les semaines par défaut.\nhttps://docs.nextcloud.com/server/19/user_manual/pim/calendar.html\nSubscriptions are refreshed every week by default. Your admin may have changed this setting.\nModifier le taux de rafraîchissement :\nSe connecter avec un terminal en root à l'instance Nextcloud.\nSe positionner à la racine du site Nextcloud.\ncd /var/www/nextcloud.example.com/www/ # Par exemple Obtenir le propriétaire du fichier config.php.\nls -l config/config.php .rw-r----- nextcloud nextcloud 1.5 KB Wed May 25 10:17:35 2022 config/config.php Modifier la valeur de l'option calendarSubscriptionRefreshRate de l'application calendrier de Nextcloud à 5 minutes.\nsudo -u nextcloud php8.0 occ config:app:set dav calendarSubscriptionRefreshRate --value \u0026#34;PT5M\u0026#34; # Résultat : # Config value calendarSubscriptionRefreshRate for app dav set to PT5M Utiliser l'utilisateur étant propriétaire du fichier config .php avec la commande sudo. Utiliser le binaire php correspondant à la version du Nextcloud. Vérifier la prise en compte.\nsudo -u nextcloud php8.0 occ config:list | grep -i calendar # Résultat : # \u0026#34;calendar\u0026#34;: { # \u0026#34;calendarSubscriptionRefreshRate\u0026#34;: \u0026#34;PT5M\u0026#34;, Crontab Editer la crontab de l'utilisateur étant propriétaire du fichier config.php vu précédemment.\nsudo -u nextcloud crontab -e Ajouter une tâche toutes les 5 minutes exécutant le script php situé à la racine du site Nextcloud.\n*/5 * * * * php8.0 -f /var/www/nextcloud.example.com/www/cron.php Utiliser le binaire php correspondant à la version du Nextcloud.\nSe connecter en admin sur l'interface web de Nextcloud. Puis se rendre dans Paramètres.\nDans la section Administration en bas à gauche, se rendre dans Paramètres de base.\nS'assurer que les Tâches de fond soient configurées avec Cron.\nSources https://docs.nextcloud.com/server/19/user_manual/pim/calendar.html https://docs.nextcloud.com/server/latest/admin_manual/groupware/calendar.html#refresh-rate https://www.php.net/manual/fr/dateinterval.construct.php ","date":"2022-06-09T08:00:00+02:00","image":"/nextcloud-ajouter-un-calendrier-google-prive-sans-credentials/cover.png","permalink":"/nextcloud-ajouter-un-calendrier-google-prive-sans-credentials/","title":"Nextcloud : Ajouter un calendrier Google privé (Sans credentials)"},{"content":"Contexte WordPress 6.0 WP-Optimize 3.2.5 Avec le module WP-Optimize, il peut se produire l'erreur suivante :\n[Fri Jan 21 15:48:12.414615 666] [proxy_fcgi:error] [pid 5281:tid 140595150419712] [client 156.251.145.63:37469] AH01071: Got error \u0026#39;PHP message: PHP Fatal error: Uncaught Error: Class \u0026#34;WPO_Page_Cache\u0026#34; not found in /var/www/blog.example.com/wp-content/plugins/wp-optimize/cache/file-based-page-cache-functions.php:813\\nStack trace:\\n#0 /var/www/blog.example.com/wp-content/plugins/wp-optimize/cache/file-based-page-cache-functions.php(889): wpo_get_conditional_tags_exceptions()\\n#1 /var/www/blog.example.com/wp-content/plugins/wp-optimize/cache/file-based-page-cache.php(31): wpo_url_in_conditional_tags_exceptions()\\n#2 /var/www/blog.example.com/wp-content/advanced-cache.php(58): include_once(\u0026#39;...\u0026#39;)\\n#3 /var/www/blog.example.com/www/wp-settings.php(95): include(\u0026#39;...\u0026#39;)\\n#4 /var/www/blog.example.com/www/wp-config.php(81): require_once(\u0026#39;...\u0026#39;)\\n#5 /var/www/blog.example.com/www/wp-load.php(50): require_once(\u0026#39;...\u0026#39;)\\n#6 /var/www/blog.example.com/www/wp-blog-header.php(13): require_once(\u0026#39;...\u0026#39;)\\n#7 /var/www/blog.example.com/www/index.php(17): require(\u0026#39;...\u0026#39;)\\n#8 {main}\\n thrown in /var/www/blog.example.com/wp-content/plugins/wp-optimize/cache/file-based-page-cac...\u0026#39;, referer: https://blog.example.com/blablablabla... Cela peut se produire lors de l'installation ou bien lors d'une mise à jour manuelle / automatique.\nFix Se connecter sur le serveur hébergeant le site. Supprimer le plugin wp-optimize : rm -r /var/www/blog.example.com/wp-content/plugins/wp-optimize Modifier le fichier wp-config.php : vi /var/www/blog.example.com/wp-config.php Supprimer la ligne suivante : define(\u0026#39;WP_CACHE\u0026#39;, true); // WP-Optimize Cache Re-Install Le module WP-Optimize peut être réinstallé dans les extensions du site WordPress.\n","date":"2022-06-04T13:34:42+02:00","image":"/wordpress-fix-wp-optimize-vpo_page-cache-not-found/cover.jpg","permalink":"/wordpress-fix-wp-optimize-vpo_page-cache-not-found/","title":"WordPress : Fix WP-Optimize (VPO_Page-Cache not found)"},{"content":"Contexte Nextcloud est orienté utilisateurs.\nC'est à dire que si l'on souhaite partager des données à d'autres utilisateurs et/ou groupes d'utilisateurs, ces partages se retrouveront à la racine (par défaut) de chaque espace de travail des utilisateurs sans conserver toute l'arborescence.\nUn exemple concret :\nUn utilisateur nommé \u0026quot;Jean-Jacques\u0026quot; possède une arborescence comme suit :\nCe dossier partagé se retrouvera à la racine (par défaut) du Nextcloud des destinataires concernés.\nL'arborescence complète ne sera pas visible.\nCela n'est pas adapté si l'on souhaite partager toute une arborescence avec des droits spécifiques et diverses en son sein.\nC'est la que l'application Group Folders intervient.\nGroup Folders Présentation Group Folders est une application que l'on va pouvoir greffer à Nextcloud.\nCette application va permettre de configurer des dossiers partagés à un / des groupe(s) d'utilisateurs.\nEnsuite, l'administrateur va pouvoir configurer finement des droits spécifiques (lecture / écriture / partage / quota) sur ces dossiers partagés.\nDe plus l'intérêt est qu'avec cette application, les données ne seront plus dépendantes d'un utilisateur. Par exemple si Jean-Jacques est supprimé, toutes ces données seront supprimmées ainsi que les partages qu'il a pu faire.\nLien vers le projet : https://github.com/nextcloud/groupfolders\nExemple Dans mon Nextcloud, je possède plusieurs utilisateurs repartis dans les groupes suivant :\nComptabilité Direction Technique Invité Je souhaite déployer une arborescence de ce type au sein de mon Nextcloud :\n. ├── compta # Accessible en écriture au groupe comptabilité et en lecture au groupe direction │ ├── note_de_frais │ └── salaires ├── direction # Accessible en écriture au groupe direction │ ├── courriers │ └── projets ├── public # Accessible en écriture à tous les groupes sauf au groupe invité qui sera en lecture seule │ ├── documents │ └── entreprise └── technique # Accessible en écriture au groupe technique et en lecture au groupe direction ├── manuels └── procedures Installation Pour installer Group Folders, il faut se connecter en tant qu'admin sur la plateforme Nextcloud puis se rendre dans les Applications.\nEnsuite, rechercher Group Folders puis Télécharger et activer :\nConfiguration Toujours en tant qu'admin, se rendre dans les Paramètres d'Administration puis Dossiers du groupe :\nCréer dans un 1er temps les dossiers qui figureront à la racine des utilisateurs :\nEnsuite, y associer les groupes d'utilisateurs désirés avec les permissions adéquates :\nIci pour le dossier compta, le groupe Comptabilité pourra lire et écrire et le groupe Direction aura simplement un droit de lecture. Naturellement, je refuse que ces données soient partageables par les utilisateurs qui y auront accès.\nIl est possible d'y définir un quota maximal :\nPuis, définir qui pourra gérer les droits de ce dossier :\nIl faut que ce soit un utlisateur / groupe qui ait accès au dossier.\nConfigurer l'intégralité des autorisations souhaitées comme suit :\nBien entendu, il faut ensuite créer les sous-dossiers dans chaque Group Folders dans l'espace Fichiers de Nextcloud.\nMaintenant, les utilisateurs verront uniquement ce à quoi ils doivent avoir accès à la racine de leur Nextcloud.\nPar exemple, pour mon utilisateur Pierre qui fait partie du groupe Comptabilité :\nAutorisation avancée Il est possible d'aller encore plus loin dans les autorisations.\nJe pourrais souhaiter qu'un utilisateur qui fait partie d'un groupe (ayant des autorisations d'écriture) ait finalement q'un droit de lecture (un stagiaire par exemple). Pour cela dans les détails d'un dossier, des règles d'autorisations avancées peuvent être appliquées :\nIci, je dis que Pierre du groupe Comptabilité peut finalement que lire et non modifier ce qui se trouve dans ce dossier :\nLigne de commande L'intégralité de la configuration peut être réalisé en ligne de commande via occ :\nocc groupfolders:create \u0026lt;name\u0026gt; → create a group folder occ groupfolders:delete \u0026lt;folder_id\u0026gt; [-f|--force] → delete a group folder and all its contents occ groupfolders:expire → trigger file version and trashbin expiration (see Nextcloud docs for versionning and Nextcloud docs for the trash bin for details) occ groupfolders:group \u0026lt;folder_id\u0026gt; \u0026lt;group_id\u0026gt; [-d|--delete] [write|share|delete] → assign groups and their rights to a group folder occ groupfolders:list → list configured group folders occ groupfolders:permissions → configure advanced permissions (see below for details) occ groupfolders:quota \u0026lt;folder_id\u0026gt; [\u0026lt;quota\u0026gt;|unlimited] → set a quota for a group folder occ groupfolders:rename \u0026lt;folder_id\u0026gt; \u0026lt;name\u0026gt; → rename a group folder occ groupfolders:scan \u0026lt;folder_id\u0026gt; → trigger a filescan for a group folder occ groupfolders:trashbin:cleanup → empty the trashbin of all group folders Conclusion Group Folders permet d'aller beaucoup plus loin dans la gestion des droits que peut le faire naturellement Nextcloud.\nEt surtout, ces données ne sont pas dépendante d'un utilisateur.\nBien entendu, cela est synchronisable avec les clients desktop Nextcloud Windows, Mac, Linux.\n","date":"2022-05-05T08:00:20+02:00","image":"/nextcloud-group-folders/cover.png","permalink":"/nextcloud-group-folders/","title":"Nextcloud : Group Folders"},{"content":"Contexte Lors de l'utilisation de plusieurs moniteurs, j'ai été confronté à un problème assez pénible.\nEn effet, au démarrage de mon système la disposition de mes différents moniteurs s'appliquent après l'ouverture de ma session.\nC'est à dire que je me suis retrouvé avec la saisie de mon login/password sur un moniteur qui n'est pas du tout mon écran principal.\nJ'ai donc appliqué la méthode suivante...\nMéthode Tout d'abord, j'ai effectué le réglage de mes moniteurs dans Paramètres -\u0026gt; Ecrans :\nUne fois cela fait, j'ai exporté cette configuration pour l'appliquer à GDM :\nsudo cp ~/.config/monitors.xml ~gdm/.config/monitors.xml Puis, j'ai modifié l'appartenance du fichier monitors.xml :\nsudo chown gdm:gdm ~gdm/.config/monitors.xml Maintenant, mon invite de login, s'affiche bien sur mon écran principal.\n","date":"2022-04-05T11:05:22+02:00","image":"/pop_os-21-10-fix-login-on-multiples-monitors/cover.png","permalink":"/pop_os-21-10-fix-login-on-multiples-monitors/","title":"Pop!_OS 21.10 : Fix login on multiples monitors"},{"content":"Présentation Une machine Windows Server 2019 contrôleur de domaine. Une machine client sous Windows 10 Professionnel. Le but est de ne plus avoir l'onglet Web ni la mention Rechercher sur le Web\nPremière solution Dans le Gestionnaire du serveur / Outils / Gestion des stratégies de groupe Dans Objets de stratégie de groupe / Clic droit -\u0026gt; Nouveau. Nommez votre stratégie et faites un clic droit / Modifier sur votre nouvelle GPO Cette fenêtre apparait :\nSélectionnez une stratégie Configuration Ordinateur / Modèles d'administration / Composants Windows / Rechercher\nActivez les trois paramètres suivants :\nNe pas autoriser la recherche Web Ne pas effectuer des recherches sur le Web ou afficher des résultats Web dans Search Ne pas effectuer des recherches sur le Web ou afficher des résultats Web dans Search via des connexions limitées Pensez à positionnez votre nouvelle GPO sur l'unité organisationnelle concernée\nAppliquez la GPO à l'aide de la commande gpudate /force dans l'invite de commande\ngpupdate /force Deuxième solution Il est possible que la première solution ne fonctionne pas, dans ce cas il faudra créer une GPO qui modifiera le registre.\nToujours dans l'éditeur de gestion des stratégies de groupe, après avoir créé une nouvelle GPO :\nSélectionnez une stratégie Configuration utilisateur / Préférences / Paramètres Windows Effectuez un clic droit sur Registre / Nouveau / Élément Registre La fenetre suivante apparait :\nRemplissez cette fenêtre comme suit :\nAction : Créer Ruche : HKEY_CURRENT_USER Chemin d'accès de la clé : Software\\Policies\\Microsoft\\Windows\\Explorer Nom de la valeur : DisableSearchBoxSuggestions Type de valeur : REG_DWORD Données de valeur : 1 L'élément de registre a bien été ajouté :\nPensez à positionnez votre nouvelle GPO sur l'unité organisationnelle concernée\nAppliquez la GPO à l'aide de la commande gpudate /force dans l'invite de commande\ngpupdate /force Vérification L'onglet Web ainsi que la mention Rechercher sur le web ont bien été désactivés :\n","date":"2022-03-24T22:49:53+01:00","image":"/gpo-disable-web-search-from-taskbar/cover.png","permalink":"/gpo-disable-web-search-from-taskbar/","title":"GPO: Disable web search from taskbar"},{"content":"Contexte Je cherchais à améliorer mon prompt bash dans mon terminal afin d'améliorer mon expérience.\nLe résultat me satisfait pleinement. Il est épuré et agréable. De plus, cela m'a permis d'avoir une indication de la branche git sur laquelle je travaille ainsi que les codes erreurs de retour.\nExemple :\nLa personnalisation peut être plus avancée (se référer aux sources en bas de page).\nParamétrage Editer son fichier .bashrc :\nvi ~/.bashrc Ajouter les lignes suivantes :\nexport POWERLINE_SEGMENTS=\u0026#34;hostname pwd git git_sync status\u0026#34; source ~/.powerline.bash Télécharger le fichier powerline.bash et le déplacer dans sa home directory :\nwget https://gitlab.com/bersace/powerline.bash/-/raw/master/powerline.bash mv powerline.bash ~/.powerline.bash Télécharger le package de polices nécessaire Hack Nerd Font :\nwget https://github.com/ryanoasis/nerd-fonts/releases/download/v2.1.0/Hack.zip Si le dossier ~/.fonts n'existe pas, le créer !\nmkdir ~/.fonts Décompresser l'archive des polices dans son dossier ~/.fonts :\nunzip -d ~/.fonts Hack.zip Supprimer l'archive Hack.zip :\nrm Hack.zip Mettre à jour le cache des polices :\nfc-cache -vf ~/.fonts Sélectionner la police Hack Nerd Font pour son terminal :\nIl peut être utile de redémarrer son terminal pour avoir le choix des nouvelles polices installées 🙂\nMaintenant, à l'ouverture de son terminal ce prompt apparait :\nLSD Dans mes recherches, je suis également tombé sur un projet nommé lsd (se référer aux sources en bas de page).\nCelui-ci permet d'afficher des icônes sympa en fonction du type de fichiers.\nTélécharger la dernière release dispo ici : https://github.com/Peltoche/lsd/releases\nA l'heure où j'écris ces lignes c'est la version 0.21.0, donc pour ma Pop!_Os en 64 bits :\nwget https://github.com/Peltoche/lsd/releases/download/0.21.0/lsd_0.21.0_amd64.deb Installer le paquet :\nsudo dpkg -i lsd_0.21.0_amd64.deb Et voilà !\nIl suffit de remplacer la commande ls par lsd :\nCes quelques alias peuvent être très agréables :\nalias ls=\u0026#39;lsd\u0026#39; alias ll=\u0026#39;ls -lh\u0026#39; alias la=\u0026#39;ls -ah\u0026#39; alias lla=\u0026#39;ls -lah\u0026#39; alias lt=\u0026#39;ls --tree\u0026#39; Sources https://gitlab.com/bersace/powerline.bash https://www.nerdfonts.com https://github.com/Peltoche/lsd ","date":"2022-03-20T19:56:57+01:00","image":"/terminal-le-prompt-avec-powerline/cover.png","permalink":"/terminal-le-prompt-avec-powerline/","title":"Terminal: Le prompt avec Powerline sous LSD"},{"content":"Contexte Cet article à pour but de servir de base pour l'installation d'un serveur web sous Apache2 avec un certificat SSL.\nLet's Encrypt est utilisé et la résolution du challenge se fera sur le port 666 (donc sans interruption de service).\nRéalisé sous Debian 11\nInstallation Apache2 Installation du serveur web apache2 :\nsudo apt install apache2 Modification du fichier /etc/apache2/apache2.conf comme suit :\n# Les variables d\u0026#39;environnement sont définies dans /etc/apache2/envvars DefaultRuntimeDir ${APACHE_RUN_DIR} PidFile ${APACHE_PID_FILE} Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 User ${APACHE_RUN_USER} Group ${APACHE_RUN_GROUP} HostnameLookups Off ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf Include ports.conf \u0026lt;Directory /\u0026gt; # Pas de suivi des liens symboliques Options -FollowSymLinks AllowOverride None Require all denied \u0026lt;/Directory\u0026gt; \u0026lt;Directory /usr/share\u0026gt; AllowOverride None Require all granted \u0026lt;/Directory\u0026gt; \u0026lt;Directory /var/www/\u0026gt; # Pas de listage des fichiers du site mais ok pour le suivi des liens symboliques Options -Indexes +FollowSymLinks AllowOverride None Require all granted \u0026lt;/Directory\u0026gt; AccessFileName .htaccess \u0026lt;FilesMatch \u0026#34;^\\.ht\u0026#34;\u0026gt; Require all denied \u0026lt;/FilesMatch\u0026gt; LogFormat \u0026#34;%v:%p %h %l %u %t \\\u0026#34;%r\\\u0026#34; %\u0026gt;s %O \\\u0026#34;%{Referer}i\\\u0026#34; \\\u0026#34;%{User-Agent}i\\\u0026#34;\u0026#34; vhost_combined LogFormat \u0026#34;%h %l %u %t \\\u0026#34;%r\\\u0026#34; %\u0026gt;s %O \\\u0026#34;%{Referer}i\\\u0026#34; \\\u0026#34;%{User-Agent}i\\\u0026#34;\u0026#34; combined LogFormat \u0026#34;%h %l %u %t \\\u0026#34;%r\\\u0026#34; %\u0026gt;s %O\u0026#34; common LogFormat \u0026#34;%{Referer}i -\u0026gt; %U\u0026#34; referer LogFormat \u0026#34;%{User-agent}i\u0026#34; agent IncludeOptional conf-enabled/*.conf IncludeOptional sites-enabled/*.conf Modification du fichier /etc/apache2/ports.conf comme suit :\n# Ecoute sur le port 80 et 443 Listen 80 Listen 443 Modification du fichier /etc/apache2/conf-available/security.conf comme suit :\n# Definit les informations du serveur retourné par l\u0026#39;en-tête HTTP ServerTokens Prod # Serveur version et nom du vhost désactivés ServerSignature Off TraceEnable Off Activation des modules de bases :\nsudo a2enmod rewrite actions headers expires ssl Activation du site par défaut en SSL :\nsudo a2ensite default-ssl Redémarrage du serveur web apache2 :\nsudo systemctl restart apache2 A ce stade, le serveur web doit être accessible : http://ip_srv_web/ et https://ip_srv_web/ (erreur de certificat)\nUne fois cette vérification faites, désactivation des sites par défaut :\nsudo a2dissite 000-default default-ssl Puis rechargement de la configuration du serveur web :\nsudo systemctl reload apache2 Certificat SSL Installation de Let's Encrypt :\nsudo apt install letsencrypt Modification du fichier /etc/apache2/mods-available/proxy.conf comme suit :\n# Permet d\u0026#39;effectuer les challenges acme sur le port 666 \u0026lt;IfModule mod_proxy.c\u0026gt; ProxyPass \u0026#34;/.well-known/acme-challenge/\u0026#34; \u0026#34;http://127.0.0.1:666/.well-known/acme-challenge/\u0026#34; retry=1 ProxyPassReverse \u0026#34;/.well-known/acme-challenge/\u0026#34; \u0026#34;http://127.0.0.1:666/.well-known/acme-challenge/\u0026#34; \u0026lt;Location \u0026#34;/.well-known/acme-challenge/\u0026#34;\u0026gt; ProxyPreserveHost On Order allow,deny Allow from all Require all granted \u0026lt;/Location\u0026gt; \u0026lt;/IfModule\u0026gt; Activation des modules nécessaires :\nsudo a2enmod proxy proxy_http ssl Redémarrer le serveur web apache2 :\nsudo systemctl restart apache2 Edition de la crontab pour le renouvellement automatique du certificat :\nsudo crontab -e Indiquer un renouvellement tous les dimanche à 5h00 du matin :\n# Autorenew let\u0026#39;s encrypt cert 00 05 * * 0 letsencrypt renew --standalone --preferred-challenges http-01 --http-01-port 666 Générer le certificat :\nsudo letsencrypt certonly -d \u0026#34;monsite.example.org\u0026#34; --standalone --preferred-challenges http-01 --http-01-port 666 -m monadresse@email.org --agree-tos -n Au préalable, un enregistrement DNS correspondant à mon site.example.org a été fait dans la zone DNS example.org.\nConfiguration vhost Création du fichier /etc/apache2/sites-available/monsite.example.org.conf :\n# Example pour le site : monsite.example.org # DirectoryRoot : /var/www/monsite.example.org/www/ # Les logs seront dans /var/log/apache2/ \u0026lt;VirtualHost *:80\u0026gt; ServerName monsite.example.org Redirect Permanent / https://monsite.example.org/ \u0026lt;/VirtualHost\u0026gt; \u0026lt;VirtualHost *:443\u0026gt; ServerName monsite.example.org LogLevel warn ErrorLog \u0026#34;|/usr/bin/rotatelogs -lc /var/log/apache2/error.monsite.example.org.%Y.%m.%d 86400\u0026#34; CustomLog \u0026#34;|/usr/bin/rotatelogs -lc /var/log/apache2/access.monsite.example.org.%Y.%m.%d 86400\u0026#34; combined SSLEngine on SSLCertificateFile /etc/letsencrypt/live/monsite.example.org/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/monsite.example.org/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/monsite.example.org/chain.pem DocumentRoot /var/www/monsite.example.org/www \u0026lt;Directory /var/www/monsite.example.org/www/\u0026gt; Require all granted AllowOverride All DirectoryIndex index.html \u0026lt;/Directory\u0026gt; \u0026lt;/VirtualHost\u0026gt; SSLProtocol -all +TLSv1.2 SSLCipherSuite +HIGH:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305-D:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off Création de l'arborescence du site :\nsudo mkdir -p /var/www/monsite.example.org/www/ Déplacer le fichier index.html de base à des fins de test :\nsudo mv /var/www/html/index.html /var/www/monsite.example.org/www/ Attribuer les droits pour www-data :\nsudo chown -R www-data:www-data /var/www/ Activation du site monsite.example.org :\nsudo a2ensite monsite.example.org Recharger le serveur web apache2 :\nsudo systemctl reload apache2 Vérification Si tout c'est bien passé, le site monsite.example.org doit être accessible à l'adresse https://monsite.example.org sans erreur de certificat.\nL'URL http://monsite.example.org doit rediriger vers https://monsite.example.org\nPour tester le renouvellement du certificat SSL sur le port 666 :\nsudo letsencrypt renew --standalone --preferred-challenges http-01 --http-01-port 666 --dry-run Sujet non abordé Les règles de pare-feu ","date":"2022-03-08T21:13:57+01:00","image":"/apache2-installation-serveur-web-de-base-ssl/cover.png","permalink":"/apache2-installation-serveur-web-de-base-ssl/","title":"Apache2 : Installation serveur web de base + SSL"},{"content":"Contexte J'utilise virt-manager pour gérer mes VMs sous QEMU/KVM et je suis sous Pop!_OS 21.10.\nVoir /2022/01/31/virt-manager-installation/\nLe réseau de ma machine hôte est prise en charge par Network-Manager.\nJ'ai eu le besoin de créer des VMs avec un réseau bridgé sur mon LAN.\nPour se faire je suis passé par l'interface graphique de ma Pop!_OS 21.10.\nCet article me fait office de mémo.\nCréation d\u0026rsquo;un pont Lancer la configuration avancée du réseau :\nnm-connection-editor Créer un Pont :\nAjouter un pont vers une interface réseau :\nSélectionner l'interface réseau à lié au pont :\nConfigurer l'adressage IP souhaité :\nSupprimer la connexion liée au pont précédement créé :\nRedémarrer le service Network-Manager :\nsystemctl restart NetworkManager Vérifier la configuration avec la commande ip a :\nConfiguration réseau VM Dans les propriétés réseau de la VM, passer la configuration réseau en Bridge :\nLa VM sera maintenant visible comme une machine à part entière sur le LAN de mon hôte.\n","date":"2022-03-08T20:27:38+01:00","image":"/network-manager-configuration-dun-reseau-bridge-pour-qemu-kvm/cover.png","permalink":"/network-manager-configuration-dun-reseau-bridge-pour-qemu-kvm/","title":"Network-Manager : Configuration d’un réseau bridgé pour QEMU/KVM"},{"content":"Contexte Lors de l'installation de Pop!_OS sur certaines machines, la touche CAPS LOCK permet d'écrire les majuscules accentuées mais pas les chiffres.\nIl est possible de changer ce comportement. Par contre, il ne sera plus possible d'utiliser cette touche pour les majuscules accentuées.\nDans mon cas de figure, j'ai la disposition du clavier en français standard et ma touche CAPS LOCK ne me permet pas d'écrire les chiffres (Je n'ai aucun besoin des majuscules accentuées).\nJ'ai donc appliqué la méthode suivante...\nMéthode Editer le fichier /usr/share/X11/xkb/symbols/fr en tant que root :\nsudo vi /usr/share/X11/xkb/symbols/fr Repérer la ligne suivante :\ninclude \u0026#34;latin\u0026#34; Et juste en-dessous, insérer ceci :\ninclude \u0026#34;mswindows-capslock\u0026#34; Ensuite, créer le fichier /usr/share/X11/xkb/symbols/mswindows-capslock :\nsudo vi /usr/share/X11/xkb/symbols/mswindows-capslock Insérer les lignes suivantes :\n// Replicate a \u0026#34;feature\u0026#34; of MS Windows on AZERTY keyboards // where Caps Lock also acts as a Shift Lock on number keys. // Include keys \u0026lt;AE01\u0026gt; to \u0026lt;AE10\u0026gt; in the FOUR_LEVEL_ALPHABETIC key type. partial alphanumeric_keys xkb_symbols \u0026#34;basic\u0026#34; { key \u0026lt;AE01\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ ampersand, 1, bar, exclamdown ] }; key \u0026lt;AE02\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ eacute, 2, at, oneeighth ] }; key \u0026lt;AE03\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ quotedbl, 3, numbersign, sterling ] }; key \u0026lt;AE04\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [apostrophe, 4, onequarter, dollar ] }; key \u0026lt;AE05\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ parenleft, 5, onehalf, threeeighths ] }; key \u0026lt;AE06\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ section, 6, asciicircum, fiveeighths ] }; key \u0026lt;AE07\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ egrave, 7, braceleft, seveneighths ] }; key \u0026lt;AE08\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ exclam, 8, bracketleft, trademark ] }; key \u0026lt;AE09\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ ccedilla, 9, braceleft, plusminus ] }; key \u0026lt;AE10\u0026gt; { type= \u0026#34;FOUR_LEVEL_ALPHABETIC\u0026#34;, [ agrave, 0, braceright, degree ] }; }; Enregistrer et redémarrer la machine.\n","date":"2022-02-01T10:04:54+01:00","image":"/pop_os-21-10-modifier-caps-lock-pour-les-chiffres/cover.png","permalink":"/pop_os-21-10-modifier-caps-lock-pour-les-chiffres/","title":"Pop!_OS 21.10 : Modifier CAPS LOCK pour les chiffres"},{"content":"Contexte Mon laptop sous Pop!_OS 21.10 possède 2 GPUs :\n1 dédié NVIDIA 1 intégré INTEL Lorsque je suis en mode graphique Nvidia ou Hybrid, mon navigateur Firefox se lance correctement.\nPar contre, lorsque je suis en mode graphique Integrated (donc avec exclusivement mon GPU Intel), Firefox se lance 2 fois sur 3 avec une fenètre transparente :\nCause Cela est dû au non chargement des librairies ICD nécessaires pour l'IGPU.\nCorrectif Pour corriger cela, j'ai ajouté les lignes suivantes dans mon fichier ~/.profile :\n# fix firefox in integrated graphics if ! grep -w -q nvidia \u0026lt;(lsmod) ; then export __EGL_VENDOR_LIBRARY_FILENAMES=\u0026#34;/usr/share/glvnd/egl_vendor.d/50_mesa.json\u0026#34; fi Puis, j'ai déconnecté et reconnecté mon utilisateur.\nMaintenant, le problème est corrigé. Firefox se lance désormais correctement lorsque mon laptop fonctionne uniquement sur l'iGPU.\n","date":"2022-02-01T08:29:34+01:00","image":"/pop_os-21-10-fix-transparent-firefox-with-integrated-graphics/cover.png","permalink":"/pop_os-21-10-fix-transparent-firefox-with-integrated-graphics/","title":"Pop!_OS 21.10 : Fix transparent Firefox with Integrated Graphics"},{"content":"Contexte Le contexte est simple. Je souhaitais avoir de meilleures performances sur mes machines virtuelles Linux qu'avec l'excellent VirtualBox.\nJ'ai donc entrepris l'installation de l'outil virt-manager.\nVirt-manager permet de gérer graphiquement les machines virtuelles sur le module KVM qui fait partie du noyau Linux.\nCet article me fait office de mémo. J'ai réalisé cette installation sous Pop!_OS 21.10.\nInstallation Tout d'abord, l'installation des paquets indispensables :\nsudo apt install qemu qemu-kvm libvirt-daemon-system python3-docutils sudo apt install python3-distutils gir1.2-libvirt-glib-1.0 libosinfo-1.0-dev sudo apt install python3-libvirt python3-libxml2 gir1.2-gtk-vnc-2.0 gir1.2-spiceclientgtk-3.0 Ensuite, l'installation de virt-manager :\nsudo apt install virt-manager Maintenant l'outil est exécutable avec la commande :\nvirt-manager La connexion à l'hyperviseur se verra refusée car celle-ci nécessite, à ce stade, de se faire en tant que root. Voir la section Permission de cet article pour une exécution avec un compte utilisateur standard. Permission A ce stade, l'utilisation de virt-manager est possible mais la connexion à l'hyperviseur QEMU/KVM n'est possible qu'avec l'utilisateur root.\nAfin de pouvoir me connecter à mon hyperviseur avec mon compte utilisateur, j'ai d'abord vérifié que je faisais bien partie du groupe libvirt :\nsudo getent group | grep libvirt Dans mon cas présent, cela était déjà effectif mais dans le cas contraire, il faut créer le groupe et ajouter l'utilisateur en cours :\nsudo groupadd --system libvirt sudo usermod -a -G libvirt $(whoami) newgrp libvirt L'appartenance au groupe pour l'utilisateur en cours peut être vérifiée :\nid $(whoami) Ensuite, j'ai édité le fichier libvirtd.conf :\nsudo vi /etc/libvirt/libvirtd.conf J'ai modifié ces 2 lignes comme suit :\nunix_sock_group = \u0026#34;libvirt\u0026#34; unix_sock_rw_perms = \u0026#34;0770\u0026#34; Puis, j'ai redémarré le service libvirtd.service :\nsudo systemctl restart libvirtd.service A présent, l'outil virt-manager peut se connecter sans être root à l'hyperviseur QEMU/KVM.\nDans mon cas, j'ai dû tout de même redémarrer mon système afin que la configuration soit prise en compte.\n","date":"2022-01-31T18:01:43+01:00","image":"/virt-manager-installation/cover.png","permalink":"/virt-manager-installation/","title":"Virt-Manager : Installation"},{"content":"Contexte Dans le cadre de mon travail, j'ai récement migré sur Pop!_OS pour mon environnement du quotidien. Etant un utilisateur de plusieurs comptes OneDrive (perso \u0026amp; pro), il me fallait pouvoir synchroniser ceux-ci dans des dossiers différents de mon système.\nPar exemple :\nMon compte OneDrive perso dans ~/OneDrive_Perso Mon compte OneDrive pro dans ~/OneDrive_Pro Bien evidément, cela doit fonctionner en tant que service.\nJe suis tombé sur ce projet : https://github.com/skilion/onedrive\nUpdate 07/12/2023 :\nLe projet utilisé dans cet article est stoppé.\nUtiliser / Adapter avec celui-ci : https://github.com/abraunegg/onedrive.git\nC'est un outil sous licence GPL3 permettant d'intéragir avec OneDrive sous Linux.\nLes fonctionnalités sont les suivantes : State caching Real-Time file monitoring with Inotify Resumable uploads Support OneDrive for Business (part of Office 365) Shared folders (only OneDrive Personal) J'ajouterai également qu'il est possible de faire du multi-comptes.\nC'est parfait car c'est mon besoin 🙂\nInstallation Pour information, j'ai réalisé cette installation sous Pop!_OS 21.10 mais celle-ci devrait fonctionner à partir des dérivés d'Ubuntu 18+. Pour Fedora, CentOS, ArchLinux, se référer directement à la page du projet cité plus haut.\nTout d'abord l'installation des pré-requis :\nsudo apt install git libcurl4-openssl-dev libsqlite3-dev snap snapd sudo snap install --classic dmd Puis le clonage du projet et l'installation de l'outil :\ngit clone https://github.com/skilion/onedrive.git cd onedrive make sudo make install Configuration La configuration est optionnelle. Par défaut, tous les fichiers seront stockés dans ~/OneDrive et les fichiers/dossiers commençant par . et ~ seront ignorés.\n3 directives sont définissables :\nsync_dir : Le répertoire où seront stockés les données.\nskip_file : Les fichiers / dossiers à ne pas synchroniser. L'utilisation des wildcards * et ? sont autorisés. Le | peut être employé pour séparer différents patterns.\nL'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.\nsync_list : Spécifier les fichiers / dossiers à synchroniser. J'en parlerai dans un prochain article.\nL'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.\nComme je veux utiliser 2 configurations différentes (une perso et une pro), j'ai créé 1 répertoire pour chaque compte où seront stockés mes données respectives :\nmkdir -p ~/{OneDrive_Perso,OneDrive_Pro} Ensuite, j'ai créé 2 dossiers de configuration (un dossier par compte) :\nmkdir -p ~/.config/{onedrive_perso,onedrive_pro} J'ai ensuite créé mes 2 fichiers de configurations (un fichier par compte).\nOneDrive perso :\ncat \u0026gt; ~/.config/onedrive_perso/config \u0026lt;\u0026lt; EOF # Directory where the files will be synced sync_dir = \u0026#34;~/OneDrive_Perso\u0026#34; # Skip files and directories that match this pattern skip_file = \u0026#34;.*|~*\u0026#34; EOF OneDrive pro :\ncat \u0026gt; ~/.config/onedrive_pro/config \u0026lt;\u0026lt; EOF # Directory where the files will be synced sync_dir = \u0026#34;~/OneDrive_Pro\u0026#34; # Skip files and directories that match this pattern skip_file = \u0026#34;.*|~*\u0026#34; EOF Initialisation L'étape suivante que j'ai réalisé a été de lier chaque configuration (perso et pro) à un compte OneDrive. Pour se faire j'ai exécuté dans un 1er temps la synchronisation de mon OneDrive perso :\nonedrive --monitor --confdir=\u0026#34;~/.config/onedrive_perso\u0026#34; Un lien est généré :\nAuthorize this app visiting: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=22c49a0d-d21c-4792-aed1-8f163c982546\u0026amp;scope=files.readwrite%20files.readwrite.all%20offline_access\u0026amp;response_type=code\u0026amp;redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient Enter the response uri: En visitant cette URL, une authentification sur le compte OneDrive désiré est demandé. Puis, viens une page blanche (ou noire suivant votre thème) :\nJ'ai copié l'URI de cette page en réponse à mon prompt Enter the response uri: La synchro démarre (oui, j'aime bien watch dogs legion...) :\nEnsuite, je teste mon compte OneDrive_Pro :\nonedrive --monitor --confdir=\u0026#34;~/.config/onedrive_pro\u0026#34; Il est important de libèrer le token office avant. J'étais, au préalablement, identifié sur mon compte perso.\nPour cela, je me suis déconnecté avec mon navigateur internet de mon compte office perso précédement connecté à l'aide de l'URL suivante : https://www.office.com/?auth=2\n5. Services Lors de l'installation de l'outil un service a été créé : /usr/lib/systemd/user/onedrive.service.\nJ'ai décidé de garder ce service pour mon compte perso et d'en créer un second pour mon compte pro :\ncp /usr/lib/systemd/user/onedrive.service /usr/lib/systemd/user/onedrive_pro.service J'ai ensuite édité mon 1er service (onedrive perso) pour correspondre à sa configuration :\nvi /usr/lib/systemd/user/onedrive.service Puis, j'ai modifié la ligne ExecStart :\nExecStart=/usr/local/bin/onedrive --monitor --confdir=\u0026#34;~/.config/onedrive_perso\u0026#34; Et enfin la même modification pour mon serive OneDrive pro :\nvi /usr/lib/systemd/user/onedrive_pro.service Cette fois-ci, j'ai modifié comme suit :\nExecStart=/usr/local/bin/onedrive --monitor --confdir=\u0026#34;~/.config/onedrive_pro\u0026#34; Pour terminer, j'ai activé mes 2 services :\nsystemctl --user enable onedrive.service systemctl --user enable onedrive_pro.service systemctl --user start onedrive.service systemctl --user start onedrive_pro.service 6. Vérifications / Logs Pour vérifier le bon fonctionnement des services, j'utilise ces 2 commandes :\njournalctl --user-unit onedrive -f journalctl --user-unit onedrive_pro -f 7. Désinstallation sudo make uninstall rm -rf ~/.config/onedrive* ","date":"2022-01-14T14:56:22+01:00","image":"/onedrive-client-linux-opensource/cover.jpg","permalink":"/onedrive-client-linux-opensource/","title":"OneDrive : Client Linux OpenSource"},{"content":"Présentation Open Centreon Discover est un module indépendant qui permet l'autodiscover des équipements SNMP, de les ajouter à la plateforme Centreon à l'aide de CLAPI. OCD permet également un scan des réseaux en tâche de fond, et cerise sur la gateau, il est possible d'affecter automatiquement les templates en fonction de l'OS détecté.\nSource: L'atelier de Kermith et Github du créateur\nInstallation Téléchargement du module Créer un dossier:\nmkdir /usr/share/discovery Récupérer le dépôt:\ngit clone https://github.com/romnvll/Open-Centreon-Discovery.git Configuration d\u0026rsquo;Apache Pour qu'Apache reconnaisse OCD, il faut créer le fichier de configuration:\nvim /etc/httpd/conf.d/discovery.conf Copiez ces lignes dans le fichier:\n########################################### Alias /discovery /usr/share/discovery/ \u0026lt;LocationMatch ^/discovery/(.*\\.php(/.*)?)$\u0026gt; ProxyPassMatch fcgi://127.0.0.1:9042/usr/share/discovery/$1 \u0026lt;/LocationMatch\u0026gt; ProxyTimeout 300 \u0026lt;Directory \u0026#34;/usr/share/discovery\u0026#34;\u0026gt; DirectoryIndex index.php Options Indexes AllowOverride all Order allow,deny Allow from all Require all granted \u0026lt;IfModule mod_php5.c\u0026gt; php_admin_value engine Off \u0026lt;/IfModule\u0026gt; AddType text/plain hbs \u0026lt;/Directory\u0026gt; RedirectMatch ^/$ /discovery ########################################### En fonction de votre configuration vous devrez modifier le port d'écoute de php-fpm (904x). Pour savoir quel port est utilisé: netstat -paunt | grep php\nRedémarrez Apache:\nsystemctl restart httpd Installation des fichiers Déplacez vous dans le dossier téléchargé au préalable et copiez les fichiers dans son répertoire dédié:\ncd Open-Centreon-Discovery cp -r * /usr/share/discovery Pour que le scan en tâche de fond puisse être réalisé, Apache nécessite les permissions sur ce dossier:\nchown -R apache: /usr/share/discovery Modifiez le fichier de configuration d'OCD. Un fichier d'exemple de configuration existe déjà, je vous suggère de l'utiliser (vous pouvez utiliser le fichier d'exemple déjà présent mais il faudra le renommer):\nmv /usr/share/discovery/config{php.example,php} vim /usr/share/config.php Placez y le login/password d'un utilisateur ayant les droits de modification avec CLAPI, ainsi que le chemin de CLAPI (admin dispose des droits, mais vous pouvez créer un utilisateur de service dédié à cela) :\n//Vos identifiants centreon $config[\u0026#39;centreon\u0026#39;][\u0026#39;user\u0026#39;] = \u0026#39;user\u0026#39;; $config[\u0026#39;centreon\u0026#39;][\u0026#39;password\u0026#39;] = \u0026#39;password\u0026#39;; //chemin de clapi $config[\u0026#39;centreon\u0026#39;][\u0026#39;clapi\u0026#39;] = \u0026#39;/usr/share/centreon/bin/centreon\u0026#39;; Scanner manuellement le réseau Connexion à l\u0026rsquo;interface du module Connectez vous à l'interface web d'OCD avec l'url http://ip-centreon-central/discovery avec l'utilisateur que vous avez déclaré dans le fichier config.php\nVous arriverez alors sur la page suivante:\nSi à ce moment vous tombez sur une page blanche, il se peut que vous identifiants soient incorrects. La découverte SNMP avec ce module ne prend en charge que la v1 et la v2c.\nNous reviendrons plus tard sur le message concernant le scan en tâche de fond.\nConfiguration du réseau à scanner Pour lancer votre premier scan afin de trouver des hôtes qui ne seraient pas intégrés à votre plateforme Centreon, vous devez entrer manuellement les informations nécessaires au scan: le réseau, la communauté snmp, la version et le timeout.\nUne fois ces paramètres rentrés, cliquez sur le bouton Scan.\nLe réseau Il s'agit du sous-réseau en notation CIDR sur lequel vous voulez détecter des hôtes.\nLa communauté Il n'est pas forcément nécessaire de configurer le fichier de configuration snmpd.conf si vous utilisez la communauté public avec ses paramètres par défaut, mais dans le cas où vous souhaiteriez utiliser une communauté personnalisé avec vos propres vues et ouvertures de MIB, petit rappel :\nDéplacez le fichier de conf par défaut et créez le votre:\nmv /etc/snmp/snmpd.{conf,conf.default} Il est toujours utile de garder de côté ce fichier par défaut.\nvim /etc/snmp/snmpd.conf agentAddress udp:161 # sec.name source community com2sec masecu ip.srv.centreon macommu # groupname securityModel securityName group groupdesecu v1 masecu group groupdesecu v2c masecu # name incl/excl subtree mask(optional) view mavue included .1.3.6.1.2.1.1 view mavue included .1.3.6.1.2.1.25.1.1 # group context sec.model sec.level prefix read write notif access groupedesecu \u0026#34;\u0026#34; any noauth exact mavue none none Redémarrez snmpd:\nsystemctl restart snmpd La version Il s'agit tout simplement de la version utilisée pour Le timeout Si le scan est trop long vous pouvez redescendre ce timeout à des valeurs inférieures. Attention toutefois, un timeout trop court peut empêcher la découverte de certains équipements.\nLe résultat du scan Après avoir cliqué sur Scan, au bout de quelques secondes vous arriverez sur cette page:\nCette liste affiche les hôtes découvrables (voir config snmp) et qui ne sont pas encore intégrés à Centreon.\nVous pouvez cliquer sur le bouton Magie et celui-ci affectera automatiquement le template d'hôte associé à l'os détecté.\nIl sera également possible de rajouter manuellement deux autres templates supplémentaires.\nVeillez également à sélectionner le bon poller, cochez le ou les équipement(s) à exporter puis cliquez sur Valider.\nDeux choix s'offrent alors à vous:\nSoit la configuration actuelle vous suffit, et vous pouvez cliquer sur Appliquer et redémarrer le moteur ce qui revient à faire l'export de la nouvelle configuration dans l'interface Centreon; Soit vous cliquez sur Appliquer dans centreon ce qui vous permet d'intégrer ces hôtes dans Centreon, sans pour autant appliquer de suite la nouvelle configuration. Libre à vous ensuite d'affiner selon vos besoins la configuration de vos hôtes dans l'interface web Centreon. Par acquis de conscience vérifiez l'intégralité des hôtes et services déployés.\nBackground autodiscover Le scan manuel reste un outil pratique pour des besoins ponctuels ou une petite structure, mais lorsque vos besoins couvrent un large panel d'équipements, réseaux et communautés différentes, Open Centreon Discovery embarque un autre outil qui va vous simplifier la vie et vous faire gagner du temps: la découverte SNMP en tâche de fond.\nAjout de réseaux à scanner Il faut au préalable venir écrire les réseaux à scanner dans le fichier de configuration d'OCD:\nvim /usr/share/discovery/config.php La variable $config[\u0026#039;backGroundScanUse\u0026#039;] est activé par défaut. C'est elle qui défini l'activation ou l'arrêt du processus.\nLa variable $config[\u0026#039;backGroundRoot\u0026#039;] permet de déclarer le chemin où viendra s'enregistrer le fichier de résultat du scan ( resultScan ). Attention: si vous modifiez ce chemin, veillez à bien donner les droits nécessaires au fonctionnement du backgroundScan:\nL'application de tâche de fond doit avoir les droits en lecture/écriture. L'application web nécessite les droits en lecture. //pour le scan BackGround //activation du scan backGround pour les /16 et plus : true or false $config[\u0026#39;backGroundScanUse\u0026#39;] = true ; //chemin de l\u0026#39;executable scanBackGround $config[\u0026#39;backGroundRoot\u0026#39;] = \u0026#39;/usr/share/discovery\u0026#39;; $config[\u0026#39;backGroundScan\u0026#39;][0] = array(\u0026#34;network\u0026#34; =\u0026gt; \u0026#34;192.168.1.0/24\u0026#34;, \u0026#34;community\u0026#34;=\u0026gt;\u0026#34;public\u0026#34;, \u0026#34;version\u0026#34;=\u0026gt;\u0026#34;2\u0026#34; ); $config[\u0026#39;backGroundScan\u0026#39;][1] = array(\u0026#34;network\u0026#34; =\u0026gt; \u0026#34;192.168.4.0/24\u0026#34;, \u0026#34;community\u0026#34;=\u0026gt;\u0026#34;macommuperso\u0026#34;, \u0026#34;version\u0026#34;=\u0026gt;\u0026#34;2\u0026#34; ); Planifier la tâche Après avoir configuré vos réseaux, il est temps de planifier vos scans.\nTout d'abord, tester la commande qui exécute le scan:\ncd /usr/share/discovery \u0026amp;\u0026amp; /usr/bin/php -q backGroundScan.php Le cd ici est indispensable. Le code php étant rédigé avec des chemins relatifs il est nécessaire de se placer dans le dossier discovery.\nATTENTION: après avoir testé manuellement la commande il se peut que les droits du fichier resulScan soit attribué à l'utilisateur qui a lancé la commande. Il est indispensable de rendre apache propriétaire du fichier!!!\nchown apache: resulScan Au bout de quelques secondes vous devriez voir apparaitre vos hôtes sur l'interface web d'OCD\nCliquez ensuite sur Go.\nVous arriverez alors sur la même page que le scan manuel où vos hôtes seront listés, avec le bouton magie pour associer vos templates.\nMerci à romnvll, qui a créé ce module et qui m'a aidé à sa mise en place, et merci à Kermith pour ses tutos très éclairés qui m'ont inspiré.\n","date":"2021-12-14T11:03:02+01:00","image":"/supervision-et-autodiscover-open-centreon-discovery/cover.png","permalink":"/supervision-et-autodiscover-open-centreon-discovery/","title":"Supervision et autodiscover: Open Centreon Discovery"},{"content":"docker-compose.yml version: \u0026#34;3.7\u0026#34; # networks networks: proxy: driver: bridge ipam: driver: default config: - subnet: 172.20.0.0/24 api-db: null redis: null mesh-db: null # docker managed persistent volumes volumes: tactical_data: null postgres_data: null mongo_data: null mesh_data: null redis_data: null services: # postgres database for api service tactical-postgres: container_name: trmm-postgres image: postgres:13-alpine restart: always environment: POSTGRES_DB: tacticalrmm POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASS} volumes: - ./postgres_data:/var/lib/postgresql/data networks: - api-db # redis container for celery tasks tactical-redis: container_name: trmm-redis image: redis:6.0-alpine command: redis-server --appendonly yes restart: always volumes: - ./redis_data:/data networks: - redis # used to initialize the docker environment tactical-init: container_name: trmm-init image: ${IMAGE_REPO}tactical:${VERSION} restart: on-failure command: [ \u0026#34;tactical-init\u0026#34; ] environment: POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASS: ${POSTGRES_PASS} APP_HOST: ${APP_HOST} API_HOST: ${API_HOST} MESH_USER: ${MESH_USER} MESH_HOST: ${MESH_HOST} TRMM_USER: ${TRMM_USER} TRMM_PASS: ${TRMM_PASS} depends_on: - tactical-postgres - tactical-meshcentral networks: - api-db - proxy volumes: - ./tactical_data:/opt/tactical # nats tactical-nats: container_name: trmm-nats image: ${IMAGE_REPO}tactical-nats:${VERSION} restart: always environment: API_HOST: ${API_HOST} ports: - \u0026#34;4222:4222\u0026#34; volumes: - ./tactical_data:/opt/tactical networks: api-db: null proxy: aliases: - ${API_HOST} default: # meshcentral container tactical-meshcentral: container_name: trmm-meshcentral image: ${IMAGE_REPO}tactical-meshcentral:${VERSION} restart: always environment: MESH_HOST: ${MESH_HOST} MESH_USER: ${MESH_USER} MESH_PASS: ${MESH_PASS} MONGODB_USER: ${MONGODB_USER} MONGODB_PASSWORD: ${MONGODB_PASSWORD} MESH_PERSISTENT_CONFIG: ${MESH_PERSISTENT_CONFIG} networks: proxy: aliases: - ${MESH_HOST} mesh-db: null volumes: - ./tactical_data:/opt/tactical - ./mesh_data:/home/node/app/meshcentral-data depends_on: - tactical-mongodb # mongodb container for meshcentral tactical-mongodb: container_name: trmm-mongodb image: mongo:4.4 restart: always environment: MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USER} MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD} MONGO_INITDB_DATABASE: meshcentral networks: - mesh-db volumes: - ./mongo_data:/data/db # container that hosts vue frontend tactical-frontend: container_name: trmm-frontend image: ${IMAGE_REPO}tactical-frontend:${VERSION} restart: always networks: - proxy environment: API_HOST: ${API_HOST} # container for django backend tactical-backend: container_name: trmm-backend image: ${IMAGE_REPO}tactical:${VERSION} command: [ \u0026#34;tactical-backend\u0026#34; ] restart: always networks: - proxy - api-db - redis volumes: - ./tactical_data:/opt/tactical depends_on: - tactical-postgres # container for django websockets connections tactical-websockets: container_name: trmm-websockets image: ${IMAGE_REPO}tactical:${VERSION} command: [ \u0026#34;tactical-websockets\u0026#34; ] restart: always networks: - proxy - api-db - redis volumes: - ./tactical_data:/opt/tactical depends_on: - tactical-postgres - tactical-backend # container for tactical reverse proxy tactical-nginx: container_name: trmm-nginx image: ${IMAGE_REPO}tactical-nginx:${VERSION} restart: always environment: APP_HOST: ${APP_HOST} API_HOST: ${API_HOST} MESH_HOST: ${MESH_HOST} CERT_PUB_KEY: ${CERT_PUB_KEY} CERT_PRIV_KEY: ${CERT_PRIV_KEY} networks: proxy: ipv4_address: 172.20.0.20 ports: - \u0026#34;8010:80\u0026#34; - \u0026#34;8011:443\u0026#34; volumes: - ./tactical_data:/opt/tactical # container for celery worker service tactical-celery: container_name: trmm-celery image: ${IMAGE_REPO}tactical:${VERSION} command: [ \u0026#34;tactical-celery\u0026#34; ] restart: always networks: - redis - proxy - api-db volumes: - ./tactical_data:/opt/tactical depends_on: - tactical-postgres - tactical-redis # container for celery beat service tactical-celerybeat: container_name: trmm-celerybeat image: ${IMAGE_REPO}tactical:${VERSION} command: [ \u0026#34;tactical-celerybeat\u0026#34; ] restart: always networks: - proxy - redis - api-db volumes: - ./tactical_data:/opt/tactical depends_on: - tactical-postgres - tactical-redis .env IMAGE_REPO=tacticalrmm/ VERSION=latest # tactical credentials (Used to login to dashboard) TRMM_USER=tacticalrmm TRMM_PASS=password # dns settings APP_HOST=rmm.example.com API_HOST=api.example.com MESH_HOST=mesh.example.com # mesh settings MESH_USER=tacticalrmm MESH_PASS=password MONGODB_USER=mongouser MONGODB_PASSWORD=password MESH_PERSISTENT_CONFIG=0 # database settings POSTGRES_USER=postgres POSTGRES_PASS=password certificates echo -e \u0026#34;\\n# certs\u0026#34; \u0026gt;\u0026gt; .env echo \u0026#34;CERT_PUB_KEY=$(base64 -w 0 /path/to/fullchain.pem)\u0026#34; \u0026gt;\u0026gt; .env echo \u0026#34;CERT_PRIV_KEY=$(base64 -w 0 /path/to/privkey.pem)\u0026#34; \u0026gt;\u0026gt; .env ","date":"2021-12-13T11:56:12+01:00","image":"/docker-compose-tactical-rmm/cover.png","permalink":"/docker-compose-tactical-rmm/","title":"Docker-Compose : Tactical RMM"},{"content":"docker-compose.yml version: \u0026#39;2\u0026#39; services: rocketchat: image: registry.rocket.chat/rocketchat/rocket.chat:latest container_name: rocketchat command: \u0026gt; bash -c \u0026#34;for i in `seq 1 30`; do node main.js \u0026amp;\u0026amp; s=$$? \u0026amp;\u0026amp; break || s=$$?; echo \\\u0026#34;Tried $$i times. Waiting 5 secs...\\\u0026#34;; sleep 5; done; (exit $$s)\u0026#34; restart: unless-stopped volumes: - ./uploads:/app/uploads environment: - PORT=3000 - ROOT_URL=https://rocketchat.example.com - MONGO_URL=mongodb://mongo:27017/rocketchat - MONGO_OPLOG_URL=mongodb://mongo:27017/local # - MAIL_URL=smtp://smtp.email # - HTTP_PROXY=http://proxy.domain.com # - HTTPS_PROXY=http://proxy.domain.com depends_on: - mongo ports: - 3000:3000 labels: - \u0026#34;traefik.backend=rocketchat\u0026#34; - \u0026#34;traefik.frontend.rule=Host: your.domain.tld\u0026#34; mongo: image: mongo:4.0 container_name: rocketchat_mongo restart: unless-stopped volumes: - ./data/db:/data/db #- ./data/dump:/dump command: mongod --smallfiles --oplogSize 128 --replSet rs0 --storageEngine=mmapv1 labels: - \u0026#34;traefik.enable=false\u0026#34; # this container\u0026#39;s job is just run the command to initialize the replica set. # it will run the command and remove himself (it will not stay running) mongo-init-replica: image: mongo:4.0 command: \u0026gt; bash -c \u0026#34;for i in `seq 1 30`; do mongo mongo/rocketchat --eval \\\u0026#34; rs.initiate({ _id: \u0026#39;rs0\u0026#39;, members: [ { _id: 0, host: \u0026#39;localhost:27017\u0026#39; } ]})\\\u0026#34; \u0026amp;\u0026amp; s=$$? \u0026amp;\u0026amp; break || s=$$?; echo \\\u0026#34;Tried $$i times. Waiting 5 secs...\\\u0026#34;; sleep 5; done; (exit $$s)\u0026#34; depends_on: - mongo # hubot, the popular chatbot (add the bot user first and change the password before starting this image) hubot: image: rocketchat/hubot-rocketchat:latest restart: unless-stopped environment: - ROCKETCHAT_URL=rocketchat:3000 - ROCKETCHAT_ROOM=GENERAL - ROCKETCHAT_USER=bot - ROCKETCHAT_PASSWORD=password - BOT_NAME=bot # you can add more scripts as you\u0026#39;d like here, they need to be installable by npm - EXTERNAL_SCRIPTS=hubot-help,hubot-seen,hubot-links,hubot-diagnostics depends_on: - rocketchat labels: - \u0026#34;traefik.enable=false\u0026#34; volumes: - ./scripts:/home/hubot/scripts # this is used to expose the hubot port for notifications on the host on port 3001, e.g. for hubot-jenkins-notifier ports: - 3001:8080 #traefik: # image: traefik:latest # restart: unless-stopped # command: \u0026gt; # traefik # --docker # --acme=true # --acme.domains=\u0026#39;your.domain.tld\u0026#39; # --acme.email=\u0026#39;your@email.tld\u0026#39; # --acme.entrypoint=https # --acme.storagefile=acme.json # --defaultentrypoints=http # --defaultentrypoints=https # --entryPoints=\u0026#39;Name:http Address::80 Redirect.EntryPoint:https\u0026#39; # --entryPoints=\u0026#39;Name:https Address::443 TLS.Certificates:\u0026#39; # ports: # - 80:80 # - 443:443 # volumes: # - /var/run/docker.sock:/var/run/docker.sock ","date":"2021-12-13T11:48:02+01:00","image":"/docker-compose-rocketchat/cover.png","permalink":"/docker-compose-rocketchat/","title":"Docker-Compose : RocketChat"},{"content":"docker-compose.yml qbittorrent: image: gists/qbittorrent container_name: qbittorrent ports: - \u0026#34;8080:8080\u0026#34; - \u0026#34;6881:6881\u0026#34; - \u0026#34;6881:6881/udp\u0026#34; volumes: - ./data:/data environment: - UID=1000 - GID=1000 restart: unless-stopped ","date":"2021-12-13T11:44:54+01:00","image":"/docker-compose-qbittorrent/cover.png","permalink":"/docker-compose-qbittorrent/","title":"Docker-Compose : qBittorrent"},{"content":"docker-compose.yml version: \u0026#34;3\u0026#34; # More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/ services: pihole: container_name: pihole image: pihole/pihole:latest ports: - \u0026#34;53:53/tcp\u0026#34; - \u0026#34;53:53/udp\u0026#34; - \u0026#34;67:67/udp\u0026#34; - \u0026#34;8085:80/tcp\u0026#34; environment: TZ: \u0026#39;Europe/Paris\u0026#39; WEBPASSWORD: \u0026#34;password\u0026#34; # Volumes store your data between container upgrades volumes: - \u0026#39;./etc-pihole/:/etc/pihole/\u0026#39; - \u0026#39;./etc-dnsmasq.d/:/etc/dnsmasq.d/\u0026#39; # Recommended but not required (DHCP needs NET_ADMIN) # https://github.com/pi-hole/docker-pi-hole#note-on-capabilities cap_add: - NET_ADMIN restart: unless-stopped ","date":"2021-12-13T11:43:04+01:00","image":"/docker-compose-pi-hole/cover.png","permalink":"/docker-compose-pi-hole/","title":"Docker-Compose : Pi-Hole"},{"content":"docker-compose.yml version: \u0026#39;3\u0026#39; services: app: image: \u0026#39;jc21/nginx-proxy-manager:latest\u0026#39; container_name: npm restart: unless-stopped ports: - \u0026#39;80:80\u0026#39; - \u0026#39;8082:81\u0026#39; - \u0026#39;443:443\u0026#39; volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt Credentials Email: admin@example.com Password: changeme ","date":"2021-12-13T11:41:08+01:00","image":"/docker-compose-nginx-proxy-manager/cover.png","permalink":"/docker-compose-nginx-proxy-manager/","title":"Docker-Compose : Nginx Proxy Manager"},{"content":"docker-compose.yml version: \u0026#39;2\u0026#39; services: db: image: mariadb container_name: nextcloud_mariadb restart: unless-stopped command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --skip-innodb-read-only-compressed volumes: - ./db:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=password - MYSQL_PASSWORD=password - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud - APACHE_DISABLE_REWRITE_IP=1 - TRUSTED_PROXIES=172.16.0.10 # Si reverse proxy, mettre son IP sinon commenter la ligne app: image: nextcloud container_name: nextcloud restart: unless-stopped ports: - 8084:80 links: - db volumes: - ./nextcloud:/var/www/html environment: - MYSQL_PASSWORD=password - MYSQL_DATABASE=nextcloud - MYSQL_USER=nextcloud - MYSQL_HOST=db - APACHE_DISABLE_REWRITE_IP=1 - TRUSTED_PROXIES=172.16.0.10 # Si reverse proxy, mettre son IP sinon commenter la ligne ","date":"2021-12-13T11:37:28+01:00","image":"/docker-compose-nextcloud/cover.png","permalink":"/docker-compose-nextcloud/","title":"Docker-Compose : Nextcloud"},{"content":"docker-compose.yml version: \u0026#39;3\u0026#39; services: netdata: image: netdata/netdata container_name: netdata hostname: HOSTNAME # set to fqdn of host ports: - 19999:19999 restart: unless-stopped cap_add: - SYS_PTRACE security_opt: - apparmor:unconfined volumes: - ./netdataconfig/netdata:/etc/netdata:ro - netdatalib:/var/lib/netdata - netdatacache:/var/cache/netdata - /etc/passwd:/host/etc/passwd:ro - /etc/group:/host/etc/group:ro - /proc:/host/proc:ro - /sys:/host/sys:ro - /etc/os-release:/host/etc/os-release:ro volumes: netdatalib: netdatacache: ","date":"2021-12-13T11:33:45+01:00","image":"/docker-compose-netdata/cover.png","permalink":"/docker-compose-netdata/","title":"Docker-Compose : Netdata"},{"content":"docker-compose.yml version: \u0026#39;3.3\u0026#39; services: postgres: restart: unless-stopped image: postgres container_name: keycloak_postgres volumes: - ./postgres_data:/var/lib/postgresql/data environment: POSTGRES_DB: keycloak POSTGRES_USER: keycloak POSTGRES_PASSWORD: password keycloak: container_name: keycloak restart: unless-stopped image: jboss/keycloak:latest environment: PROXY_ADDRESS_FORWARDING: \u0026#39;true\u0026#39; DB_VENDOR: POSTGRES DB_ADDR: postgres DB_DATABASE: keycloak DB_USER: keycloak DB_PASSWORD: password KEYCLOAK_USER: admin KEYCLOAK_PASSWORD: password ports: - 8083:8080 depends_on: - postgres ","date":"2021-12-13T11:30:58+01:00","image":"/docker-compose-keycloak/cover.png","permalink":"/docker-compose-keycloak/","title":"Docker-Compose : Keycloak"},{"content":"docker-compose.yml version: \u0026#34;3\u0026#34; services: dashy: # To build from source, replace \u0026#39;image: lissy93/dashy\u0026#39; with \u0026#39;build: .\u0026#39; # build: . image: lissy93/dashy container_name: dashy # Pass in your config file below, by specifying the path on your host machine volumes: - ./my-config.yml:/app/public/conf.yml ports: - 8081:80 # Set any environmental variables environment: - NODE_ENV=production # Specify your user ID and group ID. You can find this by running `id -u` and `id -g` - UID=1000 - GID=1000 # Specify restart policy restart: unless-stopped # Configure healthchecks healthcheck: test: [\u0026#39;CMD\u0026#39;, \u0026#39;node\u0026#39;, \u0026#39;/app/services/healthcheck\u0026#39;] interval: 1m30s timeout: 10s retries: 3 # start_period: 40s ","date":"2021-12-13T11:27:42+01:00","image":"/docker-compose-dashy/cover.png","permalink":"/docker-compose-dashy/","title":"Docker-Compose : Dashy"},{"content":"Historique CentCTL est un exécutable indépendant créé en 2020 par Mélissa Bertin au sein de la société YPSI. Tout comme CLAPI, il utilise l'API pour réaliser la majeure partie des tâches sur Centreon en ligne de commande. CLAPI nécessite d'être exécuté localement sur le serveur Centreon Central. Vous aurez donc besoin d'une connexion SSH pour pouvoir l'administrer depuis votre poste de travail. De plus, les commandes nécessitent systématiquement une authentification avec mot de passe en clair, et a parfois une syntaxe de commande peu intuitive.\nCentCTL utilise l'API REST v1 pour opérer les différentes tâches d'administration. En ayant seulement accès à l'API, on peut administrer notre solution de supervision sans connexion SSH. Aucunement besoin d'interface web, seul un utilisateur avec les droits d'accès à l'API est nécessaire. Le module est développé en langage Go, ce qui le rend multiplateforme et plaira donc à la fois à nos amis pingouins comme aux croqueurs de pommes et aux afficionados des solutions Microsoft. Centreon \u0026amp; CentCTL: l\u0026rsquo;importance de la convention de nommage. Il est très important d'adopter une convention de nommage précise et de s'y tenir!!! Il est très facile de filtrer les éléments dont vous avez besoin grâce à des regex dans CentCTL. Mais pour cela, il faut adopter une convention assez précise.\nCi-dessous je détaille une proposition de convention de nommage.\nLes commandes ChC = Check Command NoC = Notification Command DiC = Discovery Command MiC = Miscellaneous Command CoC = Connectors Command Puis ajoutez le nom de la commande. Prenez soit l'objet utilisé par le plugin Centreon, Nagios ou autre pour les commandes de check (par exemple check_ping), soit un descriptif très succinct comme nous pouvons l'avoir de base dans les commandes de notification déjà intégrées à Centreon (host-notify-by-email).\nLe résultat donnera quelque chose comme:\nChC_CHECK_PING NoC_HOST_EMAIL Si votre commande est spécifiquement adapté à un seul type d'OS, alors il faudra le préciser avant le nom:\nChC_OS_ORACLE8_DISK_SPACE_VAR ChC_OS_WINSRV16_DISK_SPACE_D Ect... Libre à vous d'imaginer le plus parlant. Les templates Les templates de configuration Une bonne pratique est de créer, pour les services et pour les hôtes, des templates de configuration (pour configurer d'autres templates).\nExemple: template de configuration de notifications.\nLors de la création d'un modèle d'hôte ou de service, liez directement le Template de configuration de notifications, et vous n'aurez pas à configurer les notifications pour ce template. Ce qui, grâce aux relations avec les modèles d'hôte ou de service fonctionnels, évitera les manipulations trop lourdes et trop contraignantes dans leurs nombres pour venir modifier un paramètre concernant les notifications. Vous changez votre paramètre directement dans le template de configuration de notification et cela s'applique absolument à tout les templates liés, se répercutant donc sur les hôtes et services. Lors de la création de ce template, ne configurez que les paramètres notifications (ce qui correspond à l'onglet du même nom dans l'interface web).\nPar exemple, ces templates se nommeront ainsi:\nNom =\u0026gt; STC_NOTIF = Service Template Configuration\nNom =\u0026gt; HTC_NOTIF = Host Template Configuration\nVous pouvez mettre la même chose dans l'alias. Libre à vous de créer les template de configuration de votre choix, par exemple plusieurs templates de configuration pour vos différentes communautés snmp, etc... Adaptez selon vos besoins.\nLes templates de service Ces templates de baseront sur le nom de la commande qu'ils représentent:\nNom =\u0026gt; ST_ChC_OS_DEB10_DISK_SPACE_VAR (ST pour Service Template) Alias =\u0026gt; SFT_ChC_OS_DEB10_DISK_SPACE_VAR (SFT pour Service From Template) Ici, définir un alias correctement peut vous permettre de différencier sur la page des services par hôtes, les services hérités d'un modèle de service, et ceux créés manuellement sans passer par un template.\nLes templates d\u0026rsquo;hôte Décrivez succinctement l'OS et la fonction de l'hôte en question:\nNom =\u0026gt; HT_OS_WINSRV19_WEB_SRV (HT pour Host Template) Alias =\u0026gt; HFT_OS_WINSRV19_WEB_SRV (HFT pour Host From Template) Les hôtes Le nom de l'hôte supervisé sera basé sur le nom de la société et/ou sa localisation (si vous supervisez plusieurs entreprises ou sites), son os, sa fonction, éventuellement le service auquel il est affecté et un numéro (utile si vous supervisez de très nombreux postes de travail ou une ferme de serveurs)\nNom: Aukfood_Linux_Server_Web_001 ou encore: CrdAgr_RSY-PlaceVendee_Win10_Direction_001 Pour l'alias, inscrivez simplement son FQDN.\nLes services Si vous créez un service automatiquement lors de la création d'un hôte en relation avec un template d'hote et des templates de service alors celui ci portera le nom de l'alias donné au template de service:\nSFT_ChC_CHECK_PING Si vous créez un service manuellement sans passer par un template:\nS_ChC_CHECK_PING Pourquoi tout ça? Et bien, lorsque vous allez utiliser des commandes CentCTL par la suite pour créer des listes à utiliser dans un script pour automatiser un déploiement par exemple, vous n'aurez qu'à filtrer avec un peu de regex des ensembles d'éléments, rediriger le flux de sortie dans un fichier, un peu de substitution massive par de la regex (encore) dans vim et le tour est joué. J'y reviendrai plus tard.\nPréparer le poste de travail Le reste de cet article décrit des procédures qui ont été réalisées sous Rocky Linux 8.4.\nTéléchargement de CentCTL Créer un dossier dans lequel récupérer CentCTL puis télécharger la dernière version:\nmkdir $HOME/centctl cd $HOME/centctl wget https://github.com/YPSI-SAS/centctl/releases/download/v2.5/centctl_linux_amd64 -O centctl Rendre ce fichier exécutable:\nchmod +x centctl Préparation de la commande Configurer la variable d'environnement CENTCTL_CONF avec le chemin et le nom du fichier de configuration nommé centctl.yaml. Modifier le .bashrc de l'utilisateur qui utilisera CentCTL avec la ligne suivante en bas du fichier:\nexport CENTCTL_CONF=/home/USER/centctl/centctl.yaml USER étant votre nom d'utilisateur, bien entendu !\nConfigurer l'auto-complétion :\nSi le paquet n'est pas installé:\ndnf install bash-completion Puis exécuter les commandes:\nsource ~/.bashrc type _init_completion Si la commande réussi, on peut passer à la suite, sinon:\nDans le .bashrc, écrivez cette ligne de commande en bas du fichier:\nsource /usr/share/bash-compltion/bash_completion Rechargez votre shell avec source .bashrc puis vérifiez que la complétion et correctement installée avec la commande type _init_completion.\nPour terminer, ajouter le script de complétion dans le répertoire /etc/bash_completion.d:\nsudo su /home/USER/centctl/centctl completion bash \u0026gt; /etc/bash_completion.d/centctl Configuration de CentCTL Il faut maintenant construire de fichier de configuration centctl.yaml. vim centctl.yaml Pour déclarer un serveur, utilisez la configuration ci-dessous en remplaçant les mots en MAJUSCULE.\nNAMESERVER c'est le nom du serveur à utiliser avec le flag --server. ATTENTION: le nom du serveur doit être unique. URL: c'est l'adresse utilisée pour l'accès à l'interface web de Centreon au format: https://monserveurcentreon.fr (ou avec l'IP). ATTENTION: si l'url n'est pas sécurisée, mettre http. insecure est utilisé quand l'URL du server est en https. Le flag est le même ( --insecure) pour forcer la connexion. LOGIN est le login avec les droits d'accès RestAPI utilisé pour la connexion au serveur. CONSEIL: utiliser admin qui est automatiquement autorisé pour l'API Rest. PASSWORD est le mot de passe de l'utilisateur VERSION est la version du Rest API (v1 ou v2) default défini le server par défaut auquel se connecter Exemple de fichier de configuration:\nservers: - server: \u0026#34;centreon-centos\u0026#34; url: \u0026#34;https://centreon21.aukfood.fr\u0026#34; insecure: true login: \u0026#34;admin\u0026#34; password: \u0026#34;Pa55word\u0026#34; version: \u0026#34;v1\u0026#34; default: true - server: \u0026#34;centreon-rocky\u0026#34; url: \u0026#34;http://192.168.1.222/centreon\u0026#34; login: \u0026#34;admin\u0026#34; password: \u0026#34;azerty666\u0026#34; version: \u0026#34;v1\u0026#34; Pour rappel CentCTL utilise la V1 de Rest API.\nTester la configuration Pour exécuter les commandes ./centctl, se placer dans le répertoire centctl Un test tout simple qui permet de voir si la configuration est bonne:\n./centctl --server=centreon-centos list host Voici le résultat, au format json par défaut:\n{ \u0026#34;server\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;centreon-centos\u0026#34;, \u0026#34;hosts\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;23\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Aukfood_Rocky_Client_001\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;RockyLinux.aukfood.fr\u0026#34;, \u0026#34;address\u0026#34;: \u0026#34;192.168.1.148\u0026#34;, \u0026#34;activate\u0026#34;: \u0026#34;1\u0026#34; } ] } } D'autres formats sont disponibles avec le flag --output en fin de commande:\n./centctl --server=centreon-centos list host --output yaml ./centctl --server=centreon-centos list host --output csv ./centctl --server=centreon-centos list host --output text D'autres options sont disponibles, comme filtrer avec des regex... Rendez-vous sur la page d'aide /.centctl --help\nExporter les configurations La migration de la configuration de la plateforme Centreon est possible avec CentCTL, même par exemple depuis la 20.10 vers une version supérieure comme la 21.10.\nPersonnellement je préfère éviter d'exporter toute la configuration d'un coup surtout si celle-ci est importante, j'ai été confronté à certains problèmes lors de test. Je préfère être méticuleux et catégoriser.\nLa configuration du moteur Centreon J'utilise le flag -r ^.* pour tout selectionner mais le flag --all marche très bien aussi.\n./centctl --server=centreon-centos export engineCFG -r ^.* -f engine.csv Les ressources du poller ./centctl --server=centreon-centos export resourceCFG -r ^.* -f ressources.csv Les contacts/utilisateurs ./centctl --server=centreon-centos export contact -r ^.* -f contacts.csv Les paramètres de notification ne seront pas exportés, attention lors de l'importation à les configurer de nouveau à la main. En effet, l'API REST v1 ne prend pas en charge ces paramètres et la v2 ne supporte pas les contacts.\nLes commandes Exportez les commandes:\n./centctl --server=centreon-centos export commands -r ^ChC -f check_commands.csv ./centctl --server=centreon-centos export commands -r ^NoC -f notification_commands.csv (etc...) Les Templates Les templates de notification Exportez les templates de notifications des services et des hôtes à part du reste des templates:\n./centctl --server=centreon-centos export template service -r ^STC -f conf_serv_temp.csv ./centctl --server=centreon-centos export template host -r ^HTC -f conf_host_temp.csv Les templates d\u0026rsquo;hôte ./centctl --server=centreon-centos export template host -r ^HT -f host_temp.csv Les templates de service ./centctl --server=centreon-centos export template service -r ^ST -f serv_temp.csv Les hôtes ./centctl --server=centreon-centos export host -r ^.* -f hosts.csv Les services ./centctl --server=centreon-centos export service -r ^*$ -f services.csv Importer vos configurations Cet ordre d'importation me parait le plus logique en fonction des dépendances/héritages qu'il peut y avoir. La configuration du moteur Les ressources du poller Les templates de configuration Les commandes Les utilisateurs Les templates d'hôtes Les templates de services Les hôtes Les services Si différents éléments n'ont pas tous les paramètres renseignés car ceux-ci sont hérités de templates, alors de nombreux messages de warning apparaitront, mais ne gêneront pas le processus.\n./centctl --server=centreon-rocky import -f engine.csv ./centctl --server=centreon-rocky import -f ressources.csv ./centctl --server=centreon-rocky import -f contacts.csv ./centctl --server=centreon-rocky import -f check_commands.csv (ect... pour les commandes)\n./centctl --server=centreon-rocky import -f conf_host_temp.csv ./centctl --server=centreon-rocky import -f conf_serv_temp.csv ./centctl --server=centreon-rocky import -f host_temp.csv ./centctl --server=centreon-rocky import -f serv_temp.csv ./centctl --server=centreon-rocky import -f hosts.csv ./centctl --server=centreon-rocky import -f services.csv Déployer la configuration ./centctl --server=centreon-rocky import -f engine.csv Il peut être préférable de vérifier la configuration dans l'interface web plutot que d'appliquer directement lors d'une grosse importation. CentCTL: de la commande à l\u0026rsquo;hôte. Les manipulations qui vont suivre peuvent paraitre longues et fastidieuses comparé à la simplicité d'utilisation de l'interface web Centreon. En effet, pour un besoin ponctuel, il est préférable de passer par l'interface.\nMais ces commandes sont nécessaires dans le cadre de la réalisation d'un script pour automatiser et accélérer la configuration de nombreux éléments. Créer une commande ./centctl --server=centreon-rocky add command -l \u0026#34;\\$USER1$/check_ping -H \\$HOSTADDRESS$ -w \\$_SERVICEWARNING$ \\$_SERVICECRITICAL$ -p \\$_SERVICENBPACKETS$ -4\u0026#34; -n ChC_CHECK_PING -t check Il est impératif de banaliser le premier $ des macros avec un antislash sinon le shell va interpréter comme une variable vide et ça ne va pas correctement s'implanter dans Centreon.\nCréer un template de service: Exemple avec la commande check_ping:\n./centctl --server=centreon-rocky add template service -a SFT_ChC_CHECK_PING -n ST_ChC_CHECK_PING -t CST_NOTIF Configurer les paramètres généraux:\n./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value=\u0026#34;WARNING|3,40%|0|seuil d\u0026#39;alerte 1\u0026#34; ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value=\u0026#34;CRITICAL|5,60%|0|seuil d\u0026#39;alerte 2\u0026#34; ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value=\u0026#34;NBPACKETS|5|0|nombre de paquets\u0026#34; ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p check_period -v 24x7 ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p normal_check_interval -v 5 ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p retry_check_interval -v 5 ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p active_checks_enabled -v 1 ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p passive_checks_enabled -v 0 ./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p is_volatile -v 0 Configurer les paramètres de notification:\nNous allons utiliser un autre template, dédié à la configuration des notifications\n./centctl --server=centreon-rocky modify template service -n STC_NOTIF -p notifications_enabled -v 1 ./centctl --server=centreon-rocky modify template service -n STC_NOTIF -p contact -v \u0026#34;admin\u0026#34; /centctl --server=centreon-rocky modify template service -n STC_NOTIF -p contactgroup -v \u0026#34;Supervisors\u0026#34; /centctl --server=centreon-rocky modify template service -n STC_NOTIF -p notification_interval -v 10 ./centctl --server=centreon-rocky modify template service -n STC_NOTIF -p notification_period -v 24x7 ./centctl --server=centreon-rocky modify template service -n STC_NOTIF -p notification_options -v \u0026#34;w,u,c,r,f,s\u0026#34; ./centctl --server=centreon-rocky modify template service -n STC_NOTIF -p recovery_notification_delay -v 0 Pour les temps définis à zero il n'est pas utile de taper la commande\nCréer un template d\u0026rsquo;hôte ./centctl --server=centreon-rocky add template host -a HFT_DEBIAN_WEB_SERVER -n HT_DEBIAN_WEB_SERVER -t HTC_NOTIF ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p snmp_community -v public ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p snmp_version -v 2c ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p timezone -v Europe/Paris ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p check_command -v ChC_HOSTALIVE ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p max_check_attempts -v 5 ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p check_interval -v 1 ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p retry_check_interval -v 1 ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p active_checks_enabled -v 1 ./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p passive_checks_enabled -v 0 Ici la commande ChC_HOSTALIVE liée au template ne comporte pas de macros perso ni d'arguments. Dans le cas où vous auriez des macros à configurer, les valeurs de celles-ci se déclarent de la même manière que pour les macros des templates de service.\nLes commandes pour les paramètres de notifications sont les mêmes que pour les templates de service.\nPour lier des templates de service:\n./centctl --server=centreon-rocky modify template host -n HT_DEBIAN_WEB_SERVER -p linkedservice -v ST_ChC_CHECK_PING Répéter la commande autant de fois qu'il y a de templates de service à lier.\nCréer un hôte ./centctl --server=centreon-rocky add host -i 192.168.1.148 -a websrv01.aukfood.fr -n Aukfood_Debian_Web_Server_001 -p Central -t HT_DEBIAN_WEB_SERVER Par défaut, l'ajout de l'hôte par CentCTL créé automatiquement les services liés aux templates.\nPour définir d'autres paramètres (soit non définis dans un template d'hôte ou volonté de le changer, soit pour configurer l'hôte manuellement sans relation avec un template), se référer aux commandes listées plus haut.\n./centctl --server=centreon-rocky modify host -n Aukfood_Debian_Web_Server_001 -p ..... Créer un service ./centctl --server=centreon-rocky add service -n Aukfood_Debian_Web_Server_001 -t ST_ChC_CHECK_PING -d SFT_ChC_CHECK_PING -n nom de l'hôte, -t template de service, -d description (nom du service/alias du template de service)\nPour aller plus loin De nombreux autres paramètres n'ont pas été abordés! Pour en découvrir d'autres, c'est par ici !!!\nExemple pratique: automatiser le déploiement d\u0026rsquo;un nouveau service sur tout un parc Afin d'éviter de devoir faire une myriade de clics pour déployer un nouveau service sur des centaines de machines, nous pouvons à l'aide d'un petit script très basique déployer en un temps record la nouvelle sonde.\nContexte Nous avons correctement créé nos hôtes, hérités d'un Template d'hôte, qui est en relation avec un ou plusieurs Template de service qui contiennent une commande.\nExtraire une liste d\u0026rsquo;hôtes ./centctl --server=centreon-rocky list host -r ^.* --output csv \u0026gt; hosts.csv vim hosts.csv La liste se présente sous ce format: ID,Name,Alias,Address,Activate 5,Aukfood_Debian_Web_Server_001,websrv01.aukfood.fr,192.168.1.148,1 6,Aukfood_Debian_Web_Server_002,websrv02.aukfood.fr,192.168.1.149,1 7,Aukfood_Win19srv_Dns_Server_001,dnssrv01.aukfood.fr,192.168.1.253,1 Quelques petites manips avec vim:\nÔter la premiere ligne en plaçant le curseur en début de ligne et appuyez 2 fois rapidement sur d\nEntrez ces commandes:\n:g/^\\d*,/s/// :g/,.*$/s/// \u0026gt; Selon les préférences, la commande sed ira très bien aussi!\nAprès manipulation nous obtennons une liste ne contenant que les noms d'hôtes.\nAukfood_Debian_Web_Server_001 Aukfood_Debian_Web_Server_002 Aukfood_Win19srv_Dns_Server_001 Créer le script vim autodeploy.sh #!/bin/bash #Déclare la liste d\u0026#39;hôte listhost=\u0026#34;$(\u0026lt;hosts.csv)\u0026#34; #Boucle sur tout les hôtes for host in $listhost; do ./centctl --server=centreon-rocky add service -n $host -t ST_ChC_CHECK_PING -d SFT_ChC_CHECK_PING done #Exporte la configuration sur le poller selectionné et le recharge ./centctl --server=centreon-rocky apply -n Central echo \u0026#34;Wouah, c\u0026#39;était long! Tu as bien travaillé, vas te reposer maintenant ;)\u0026#34; Maintenant, vous pouvez grâce à toutes les commandes CentCTL vues précédemment vous amuser à scripter dans tout les sens...\nSources L'atelier de Kermith qui est une vraie pépite pleine de bonne choses!\nGithub de CentCTL dans lequel j'ai trouvé nombreuses réponses.\nMes cours sur la supervision lors de ma formation TSSR à l'ENI de St-Herblain ( coucou Fred 🙂 )\nMerci Merci de m'avoir lu, et soyez indulgent pour mon 1er article dans le monde de l'IT !!! (et du monde libre, une pierre deux coups, tant qu'à faire)\nCharles, stagiaire TSSR.\n","date":"2021-11-26T14:51:09+01:00","image":"/supervision-tour-dhorizon-avec-centctl-pour-centreon-open-source/cover.png","permalink":"/supervision-tour-dhorizon-avec-centctl-pour-centreon-open-source/","title":"Supervision: tour d’horizon avec CentCTL pour Centreon Open Source."},{"content":" Cet article a été écrit par la société AukFood, n'hésitez pas à les contacter pour la mise en place d'un tel outil.\nVous connaissez certainement UptimeRobot, qui est une solution qui permet de monitorer un ou plusieurs sites web et d'être alerté le plus rapidement possible. C'est un outil de monitoring extrêmement simple, qui surveille une URL donnée. 👀\nCependant ce service est payant, la version gratuite étant limitée à 50 URLs. C'est pour cela que je vais vous présenter à travers cet article, la solution Uptime Kuma, qui offre les mêmes features. C'est évidemment un projet open-source. ✌️\nLe projet est assez jeune, mais compte 24 releases à ce jour, et près de 9k d'étoiles sur GitHub. Les fonctionnalités sont les suivantes : Surveillance des protocoles HTTP(s), TCP, Ping, DNS ; Notifications via Telegram, Discord, Slack, Rocket.Chat, Pushover, Email, etc... ; Surveillance des certificats SSL ; Mais également un thème sombre ! 🌙 La surveillance des services s'effectue sur une intervalle de 20 secondes.\nUptime Kuma s'installe sur un serveur, principalement en conteneur Docker (une version autonome est possible également). Nous allons voir dans cet article l'installation avec Docker. 🐳\nPremièrement, créer un volume : $ docker volume create uptime_kuma_storage Puis créer le conteneur : $ docker run -d --restart=always -p 3001:3001 -v uptime-kuma_storage:/app/data --name uptime-kuma louislam/uptime-kuma:1 Comme vous pouvez le constater sur la deuxième commande, Uptime Kuma écoute sur le port 3001.\nAllez sur l'interface web (par défaut : http://localhost:3001), vous pouvez configurer une écoute distante, à travers un reverse-proxy par exemple.\nVous voici sur la page d'inscription. L'utiliseateur qui sera créé sera de type administrateur. Après avoir rempli le formulaire, vous vous trouverez sur le tableau de bord par défaut : Dans le cadre de notre article, nous allons ajouter notre site web en supervision. Pour cela, cliquez sur \u0026quot;Ajouter une nouvelle sonde\u0026quot;.\nVous avez différentes options possibles, dans notre cas on restera sur celles de base (URL, protocole, intervalle de vérification...) mais vous pouvez paramétrer par exemple les codes HTTP acceptés (par défaut compris entre 200 et 299, le 404 par exemple sera considéré) comme un downtime.\nQuelques secondes plus tard, le résultat est déjà affiché ! Faisons la même chose avec le DNS : Les notifications sont paramétrables, ce qui fera l'objet d'un article prochainement.\nEn résumé, Uptime Kuma est un outil très simple d'utilisation, dont l'interface est intuitive, attractive, et accessible à un public non technique. Il se concentre sur son but principal, à savoir vérifier si un service est UP ou DOWN, ni plus ni moins. On va droit à l'essentiel, et c'est très bien comme cela.\nCet article a été écrit par la société AukFood, n'hésitez pas à les contacter pour la mise en place d'un tel outil.\n","date":"2021-11-24T09:51:40+01:00","image":"/uptime-kuma-une-alternative-a-uptime-robot/cover.png","permalink":"/uptime-kuma-une-alternative-a-uptime-robot/","title":"Uptime Kuma : Une alternative à Uptime Robot !"},{"content":"Apache / Nginx configuration La 1ère chose à faire est de configurer le serveur web pour le passer en HTTPS.\nSuivre cet article par exemple : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS - slash-root.fr LemonLDAP configuration La 2nde étape est de configurer les URL en HTTPS pour le portail, cookie, ...\nA exécuter en tant que root :\n/usr/share/lemonldap-ng/bin/lemonldap-ng-cli -yes 1 \\ set \\ portal https://auth.example.com \\ mailUrl https://auth.example.com/resetpwd \\ registerUrl https://auth.example.com/register \\ https 1 \\ securedCookie 1 Reverse-Proxy configuration Nginx : Reverse Proxy avec SSL - slash-root.fr\nSi le portail est derrière un reverse-proxy en HTTPS, il est impératif d'effectuer les manipulations plus haut.\nExemple d'un vhost sous Nginx pour le portail :\nserver { listen 80; server_name auth.example.fr; rewrite ^ https://auth.example.fr permanent; } server { listen 443 ssl; server_name auth.example.fr; ssl_certificate /etc/letsencrypt/live/auth.example.fr/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/auth.example.fr/privkey.pem; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; error_log /var/log/nginx/error.log; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://192.168.49.68:80; } } Exemple d'un vhost sous Nginx pour le manager :\nserver { listen 80; server_name manager.example.fr; rewrite ^ https://manager.example.fr permanent; } server { listen 443 ssl; server_name manager.example.fr; ssl_certificate /etc/letsencrypt/live/manager.example.fr/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/manager.example.fr/privkey.pem; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://192.168.49.68:80; } } Le serveur web doit être compilé avec le module --with-http_realip_module.\nPour vérifier :\nnginx -V ## Retour attendu : nginx version: nginx/1.14.2 built with OpenSSL 1.1.1d 10 Sep 2019 TLS SNI support enabled configure arguments: --with-cc-opt=\u0026#39;-g -O2 -fdebug-prefix-map=/build/nginx-m1Thpq/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2\u0026#39; --with-ld-opt=\u0026#39;-Wl,-z,relro -Wl,-z,now -fPIC\u0026#39; --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-echo --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-subs-filter ","date":"2021-11-20T15:36:41+01:00","image":"/lemonldap-activer-le-https/cover.png","permalink":"/lemonldap-activer-le-https/","title":"LemonLDAP : Activer le HTTPS + Reverse-Proxy"},{"content":"Objectif L'objectif de ce document est de mettre en place une synchronisation des utilisateurs, des mots de passes, et des groupes d'un Active directory local vers une infrastructure Azure AD et d'attribuer des licences Microsoft 365 aux utilisateurs du domaine. Ceux-ci n'auront qu'une seule identité entre le domaine local et leurs services Microsoft 365.\nContexte Contrôleur de domaine local : SRV-AD (Windows Serveur 2019 Standard) Domaine local : starwars-bzh.local Tenant Azure AD : starwarsbzh.onmicrosoft.com Architecture du domaine local : Vérifier l\u0026rsquo;activation de la corbeille Active Directory En PowerShell : Get-ADOptionalfeature -Filter {name -like \u0026#34;Recycle Bin Feature\u0026#34;} Si la valeur EnabledScope est vide, cela signifie que la corbeille Active Directory n'est pas activée.\nActiver la corbeille Active Directory En PowerShell : Enable-ADOptionalFeature \u0026#34;Recycle Bin Feature\u0026#34; -Scope ForestOrConfigurationSet -Target \u0026#34;starwars-bzh.local\u0026#34; -server srv-ad Les options -Target et -Server doivent être adapté avec l'infrastructure du domaine local. Un message d'avertissement apparait car c'est une action irréversible mais ça peut sauver des vies.\nMaintenant, la corbeille Active Directory est activée.\nConfigurer l\u0026rsquo;alias UPN Le domaine local est starwars-bzh.local et le domaine Microsoft 365 public associé est starwarsbzh.onmicrosoft.com. Pour que la synchronisation fonctionne, un alias UPN doit être mis en place dans le domaine local. L'idée est de remplacer le @starwars-bzh.local par @starwarsbzh.onmicrosoft.com pour tous les utilisateurs qui seront synchronisés vers Azure.\nSur le contrôleur de domaine, ouvrir la MMC Domaines et approbation Active Directory : domain.msc Effectuer un clic droit sur le nom de la console et cliquer sur Propriétés : Renseigner la zone Autres suffixes UPN avec le domaine Microsoft 365 déclaré soit starwarsbzh.onmicrosoft.com puis appliquer. Ensuite, il faut modifier en masse l'UPN par défaut des utilisateurs qui seront synchronisés dans Azure AD. Si on regarde les propriétés d'un compte utilisateur dans l'AD, on voit que l'on peut changer l'UPN par défaut.\nChanger l'UPN par défaut : Au lieu de la faire à la main sur chaque utilisateur, il est possible de le faire en masse.\nEn PowerShell : Get-ADUser -Filter * -SearchBase \u0026#34;OU=Services,OU=Starwars-BZH,DC=starwars-bzh,DC=local\u0026#34; | Foreach{ $UPNNew = $_.UserPrincipalName -replace \u0026#34;@starwars-bzh.local\u0026#34;,\u0026#34;@starwarsbzh.onmicrosoft.com\u0026#34; Set-ADUser -UserPrincipalName $UPNNew -Identity $_.SamAccountName } L'option -SearchBase est à adapter selon les OU contenant les utilisateurs qui seront à synchroniser. La cmdlet Get-ADUser est récursive.\nInstaller Azure AD Connect Télécharger l'outil à l'adresse suivante : https://www.microsoft.com/en-us/download/details.aspx?id=47594\nPuis lancer l'installation sur le contrôleur de domaine local.\nAccepter les termes de la licence puis continuer :\nUn message d'avertissement s'affiche indiquant que le domaine local n'est pas routable sur Internet. Une installation personnalisée est donc préférable : Aucune des options suivantes n'est nécessaire. Il n'y a donc rien à cocher. Cliquer sur Installer : Dans la partie Connexion utilisateur, Synchronisation de hachage du mot de passe est coché. Cela permet de synchroniser le mot de passe de l'AD local avec Azure AD. Le mot de passe ne transite pas en clair mais uniquement son hash. La case Activer l\u0026#039;authentification unique peut être cochée si on souhaite mettre en place du SSO (Single-Sign-On). Ainsi l'utilisateur n'aura pas à ressaisir sont mot de passe du domaine lors de l'accès aux services Azure (Microsoft 365). Dans la partie Connexion à Azure AD, un compte administrateur général du tenant Azure est requis : Dans la partie Connexion de vos annuaires, la forêt locale est bien détectée. Cliquer sur Ajout d\u0026#039;un annuaire. Il est préférable de créer un nouveau compte dans l'AD local qui sera utilisé par les outils effectuant la synchronisation entre l'AD local et Azure AD. Un compte administrateur du domaine est requis afin de pouvoir créer cet utilisateur. Cet utilisateur sera stocké dans le container Users. Il ne devra être en aucun cas modifié ou supprimé. La connexion à l'AD local est configurée : Les suffixes UPN apparaissent comme Non ajouté. Cela est tout à fait normal car il n'y a pas de domaines DNS spécifiques du type starwarsbzh.fr. Si un domaine DNS en .fr a été ajouté au tenant Azure, celui-ci sera noté comme Vérifié. Nom d\u0026#039;utilisateur principal doit être sur userPrincipalName. La case Continuer sans faire correspondre tous les suffixes UPN à des domaines vérifiés est à cocher. Sélectionner les OU à synchroniser entre l'AD local et Azure AD : Dans la partie Identification de manière unique de vos utilisateurs, laisser le choix par défaut : Dans la partie Filtrer les utilisateurs et appareils, laisser le choix par défaut : Dans la partie Fonctionnalités facultatives, laisser par défaut. A noter que la Réécriture du mot de passe peut être intéressante afin de permettre aux utilisateurs de réinitialiser leur mot de passe directement à partir de Microsoft 365. Toutefois cela demande un niveau de licence Azure AD Premium P1. Sans cette option, le mot de passe est écrit dans l'Active Directory et synchronisé sur votre tenant, et non l'inverse. Le processus de synchronisation peut démarrer : Pour modifier la configuration, il suffit de relancer l'assistant en cliquant sur l'icône Azure AD Connect présente sur le bureau puis sur le bouton Configurer (Modification des OU à synchroniser, ajout de nouvelles fonctionnalités). Vérifier la bonne présence des utilisateurs et des groupes dans le portail d'administration de Azure AD. Affecter les licences Microsoft 365 Afin de pouvoir affecter une licence Microsoft 365 à un utilisateur, il va falloir dans 1er temps lui attribuer un Lieu d'utilisation. Ce paramètre se trouve dans le profil de l'utilisateur dans Azure AD :\nAttention, une fois le Lieu d\u0026#039;utilisation affecté à un utilisateur. Un délai de 5 minutes peut être nécessaire avant de pouvoir lui attribuer une licence.\nUne licence Microsoft 365 peut ensuite être attribué à un utilisateur :\nVérifier la synchronisation Un outil nommé Synchronization Service Manager a également été installé sur le contrôleur de domaine local permettant de vérifier l'état de la synchronisation. Par défaut celle-ci s'effectue toutes les 30 minutes.\nA noter que si un mot de passe est modifié dans l'AD local, celui-ci sera répliqué sous 2 minutes au sein d'Azure AD.\n","date":"2021-11-20T04:03:05+01:00","image":"/azure-synchronisation-ad-on-premise-azure-ad/cover.jpg","permalink":"/azure-synchronisation-ad-on-premise-azure-ad/","title":"Azure : Synchronisation AD On-Premise \u003c\u003e Azure AD"},{"content":"Introduction LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française. Il fournit une solution d' authentification unique distribuée avec gestion centralisée des droits sous licence GPL.\nLe logiciel LemonLDAP::NG est issu d'un logiciel créé par Eric German suivant le protocole de gestion d'annuaire LDAP sous TCP/IP pour le Ministère des finances français. La Gendarmerie nationale reprend ce logiciel pour l'élargir et le conformer à ses besoins.\nLe logiciel fonctionne avec les serveurs web Apache ou Nginx mais un mode reverse proxy permet de l'utiliser avec des applications exécutées sur un autre serveur (IIS, Tomcat, etc.)3,4.\nIl peut gérer plus de 200000 utilisateurs de différentes organisations, il implémente à la fois5 :\nles services de fournisseur d'identité et de service SAML, OpenID, CAS et OpenID Connect6 ; peut-être utilisé comme Proxy protocolaire en fédération des identités ; l'authentification basée sur LDAP, Kerberos, SQL, Twitter et d'autres protocoles ; l'authentification à double facteur (U2F, TOTP, Yubikey, REST ou externe tels SMS ou mails)7 un système d'authentification unique basé sur des cookies sécurisés ; un menu dynamique des applications ; un module de réinitialisation de mots de passe ; un module d'auto-création de compte ; un dispositif de notification ; un explorateur de sessions. Depuis la version 1.9, il propose un connecteur FranceConnect, lui permettant d'être simplement soit fournisseur d'identités, soit fournisseur de services8.\nLa version 2.0.6 apporte, entre autres évolutions, les nouvelles fonctionnalités suivantes :\nla sur-charge des seconds facteurs et la prise en charge du protocole RADIUS ; la possibilité de définir une politique locale des mots de passe ; un module de simulation d'identités pour des environnements de formation ; un module d'endossement d'identité pouvant être activé à des fins de diagnostic ; un module permettant de consulter le profil SSO d'un utilisateur et de vérifier ses droits d'accès ainsi que les en-têtes transmis ; un module pour éditer la configuration en lecture seule. La version 2.0.7 permet un meilleur support du protocole OpenId Connect et apporte de nombreuses améliorations ou correctifs.\nLa version 2.0.8 offre de nombreuses API et améliorations.\nLa version 2.0.9 apporte un outil de gestion des sessions, ameliore la gestion des mots de passe, une documentation intégrée au code source et des correctifs.\nSource : LemonLDAP::NG — Wikipédia (wikipedia.org)\nPré-requis Un serveur OpenLDAP installé et fonctionnel FusionDirectory déployé sur le serveur LDAP Un nom de domaine avec la gestion de sa zone DNS Suite directe de : OpenLDAP : Installation avec FusionDirectory - slash-root.fr Le nom de domaine utilisé dans cet article sera : example.com LemonLDAP sera déployé sur le même serveur qu'OpenLDAP / FusionDirectory Installation LemonLDAP Utiliser le dépôt officiel :\nsudo cat \u0026gt; /etc/apt/sources.list.d/lemonldap-ng.list \u0026lt;\u0026lt; \u0026#39;EOL\u0026#39; # LemonLDAP::NG repository deb https://lemonldap-ng.org/deb 2.0 main deb-src https://lemonldap-ng.org/deb 2.0 main EOL Récupérer la clef GPG :\nwget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | sudo apt-key add - Mise à jour du cache apt :\nsudo apt update Installer le package principal et le module Perl pour Apache2 :\nsudo apt install libapache2-mod-perl2 lemonldap-ng LemonLDAP est également compatible avec Nginx mais cela ne sera pas abordé dans cet article.\nInstaller le module FCGID pour Apache :\nsudo apt install libapache2-mod-fcgid Activer les modules et les configurations :\nsudo a2ensite manager-apache2.conf sudo a2ensite portal-apache2.conf sudo a2ensite handler-apache2.conf sudo a2enmod fcgid perl alias rewrite headers Tester la configuration d'Apache2 :\nsudo apachectl configtest Redémarrer Apache2 :\nsudo systemctl restart apache2 Par défaut, le domaine est example.com. Celui-ci peut être changé.\nPour changer le nom de domaine par défaut :\nsed -i \u0026#39;s/example\\.com/mondomaine.local/g\u0026#39; /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.json Adapter la suite des instructions avec le domaine utilisé en lieu et place d'example.com.\nAccès Web UI Pour accéder à la Web UI et effectuer les tests nécessaires, il y a 4 enregistrements A à réaliser dans la zone DNS du domaine :\nauth.example.com manager.example.com test1.example.com test2.example.com C'est 4 URLs sont à rediriger vers le même serveur. test1 et test2 sont là pour simuler 2 applications différentes.\nAvec un navigateur web, accéder à http://auth.example.com :\nDans un 1er temps, utiliser le login dwho avec le mot de passe dwho. Ce compte est local à LemonLDAP et à des droits administrateur sur la plateforme.\nSe rendre sur WebSSO Manager ou directement via l'URL : http://manager.example.com : La configuration qui va être appliqué peut se faire intégralement par cette Web UI : Afin de pouvoir automatiser tout ce processus plus tard, la configuration sera réalisée en ligne de commande à l'aide de l'outil :\n/usr/share/lemonldap-ng/bin/lemonldap-ng-cli help Activer les applications de démonstration LemonLDAP est fournit avec 2 applications de démonstration qui permettent de lire les en-têtes HTTP. Pour les activer :\nsudo a2ensite test-apache2.conf sudo systemctl reload apache2 C'est un vhost standard d'Apache2 :\nsudo cat /etc/apache2/sites-enabled/test-apache2.conf Remarquer la ligne qui à été ajoutée concernant le SSO :\n# SSO protection PerlHeaderParserHandler Lemonldap::NG::Handler::ApacheMP2 Vérifier l'accès aux applications de démonstration en se rendant sur :\nhttp://test1.example.com http://test2.example.com Pas besoin de s'authentifier car cela a été fait l'autre de l'accès à la plateforme LemonLDAP :\nIl est possible de se déconnecter de cette application test1, en bas de la page : Lors de la prochaine tentative d'accès, une demande d'authentification de LemonLDAP sera demandée. Configuration avec OpenLDAP / FusionDirectory Pour le moment LemonLDAP est en mode démo et utilise une base de compte interne. La configuration de LemonLDAP va consister à utiliser l'annuaire OpenLDAP préalablement déployé avec FusionDirectory. Une chose à savoir est que l'accès au manager est réservé exclusivement à l'utilisateur dwho de la base de compte interne à LemonLDAP. Lors de la jonction de l'annuaire LDAP à LemonLDAP, la base de compte interne ne sera plus exploitable. Par conséquence, l'accès au WebSSO Manager ne se fera plus. Il y a plusieurs méthodes possibles pour retrouver cet accès. En voici une qui consiste à n'autoriser que l'utilisateur fd-admin de l'annuaire LDAP :\nAvec l'utilisateur dwho se rendre dans le Manager. Puis Hôtes virtuels, manager.example.com, Règles d\u0026#039;accès :\nModifier la partie Règles à droite comme ci-dessus. Puis Sauver la configuration.\nParamétrer la liaison à l'annuaire LDAP :\nsudo /usr/share/lemonldap-ng/bin/lemonldap-ng-cli -yes 1 \\ set \\ authentication LDAP \\ userDB LDAP \\ passwordDB LDAP \\ registerDB LDAP \\ ldapServer \u0026#39;ldap://localhost\u0026#39; \\ managerDn \u0026#39;cn=admin,dc=example,dc=com\u0026#39; \\ managerPassword \u0026#39;MonSuperPassword\u0026#39; \\ ldapBase \u0026#39;ou=people,dc=example,dc=com\u0026#39; \\ Pour des raisons de praticité, le managerDn utilisé est le compte admin de l'annuaire. Dans un contexte de production un autre compte sera utilisé. Afin d'avoir une vue synthétique de l'annuaire et obtenir les chemins complets pour la précédente commande, utiliser :\nsudo slapcat | grep \u0026#34;dn:\u0026#34; Exporter les attributs souhaités :\nsudo /usr/share/lemonldap-ng/bin/lemonldap-ng-cli -force 1 -yes 1 \\ addKey \\ ldapExportedVars uid uid \\ ldapExportedVars cn cn \\ ldapExportedVars sn sn \\ ldapExportedVars mail mail \\ ldapExportedVars givenName givenName Voici le retour attendu :\nStatus : [ { \u0026#39;localhost\u0026#39; =\u0026gt; \u0026#39;OK\u0026#39; } ]; Redémarrer Apache2 :\nsudo systemctl restart apache2 L'utilisateur fd-admin peut maintenant s'authentifier, avec accès au manager, sur la plateforme : http://auth.example.com.\n","date":"2021-11-16T14:48:52+01:00","image":"/lemonldap-installation-avec-un-ldap-et-fusiondirectory/cover.png","permalink":"/lemonldap-installation-avec-un-ldap-et-fusiondirectory/","title":"LemonLDAP : Installation avec un LDAP et FusionDirectory"},{"content":"Contexte L'erreur est apparue sur un poste en Windows 10. Toutes les applications du Windows Store pouvaient être installées. Windows Update fonctionnait correctement Ajout d'une clef produit (AoE 4) Impossible d'installer AoE, erreur 0x80070424 Resolution Ré-enregistrement des applications du Windows Store en PowerShell : Get-AppxPackage -AllUsers| Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\\AppXManifest.xml”} ","date":"2021-11-14T10:50:08+01:00","image":"/windows-store-error-code-0x80070424/cover.png","permalink":"/windows-store-error-code-0x80070424/","title":"Windows Store : Error code 0x80070424"},{"content":"Introduction La solution Keycloak est embarqué avec la possibilité de joindre un annuaire LDAP/AD. Il est possible de fédérer plusieurs serveurs d'annuaires au sein d'un même royaume keycloak. Les attributs utilisateurs de l'annuaire LDAP peuvent être mappé dans un model d'utilisateur keycloak. Par défaut, les attributs username, email, first name, last name sont mappés mais d'autres attributs peuvent l'être également.\nCet article fait suite à :\nKeycloak : Installation avec Docker et reverse-proxy SSL Nginx OpenLDAP : Installation avec FusionDirectory Prérequis Un serveur Keycloak fonctionnel Un serveur OpenLDAP/FusionDirectory fonctionnel Toute la procédure fera référence aux configuration déployées dans les articles cités en introduction.\nConfiguration Se rendre sur la WebUI du serveur Keycloak : https://keycloak.example.com\nSe rendre dans la partie User Federation et ajouter ldap en provider :\nParamétrage - 1ère partie Stockage Par défaut, Keycloak importe les utilisateurs de l'annuaire LDAP dans sa base locale d'utilisateurs. Cette copie des utilisateurs peut être synchronisée soit manuellement soit automatiquement toutes les x minutes par exemple. Seul les mots de passes ne sont pas synchronisés. Dans le processus d'identification de l'utilisateur, la validation du mot de passe est délégué au serveur LDAP. L'avantage de cette approche est que toutes les fonctionnalités de Keycloak fonctionneront avec des attributs utilisateurs supplémentaires qui sont stockés localement sur Keycloak. Cela permet également de réduire la charge sur le serveur LDAP.\nIl est possible de ne pas importer les utilisateurs de l'annuaire LDAP dans Keycloak en décochant Import Users. Cela aura pour effet d'augmenter les requêtes vers le serveur LDAP car aucune information utilisateur ne sera stockée localement sur Keycloak. L'autre conséquence de ce choix est que si une fonctionnalité de Keycloak repose sur une partie non supporté par l'annuaire LDAP, celle-ci ne fonctionnera pas. En revanche, l'avantage est de ne pas avoir à gérer la synchronisation des comptes.\nEdition L'Edit Mode permet aux utilisateurs et aux administrateurs, à travers leurs consoles respectives sur Keycloak, de modifier les metadas utilisateur.\nREADONLY : Les attributs utilisateurs resteront inchangés. Une erreur apparaitra si une modification d'attribut est faites. Cela est également valable pour la modification d'un mot de passe utilisateur. WRITABLE : Tous les attributs utilisateurs modifiés seront synchronisés automatiquement avec l'annuaire LDAP. UNSYNCED : Tous les changements d'attributs seront stockés localement dans la base de Keycloak. La synchronisation des modifications au sein de Keycloak vers l'annuaire LDAP devra être faites manuellement. Vendor Plusieurs choix sont possibles suivant le type d'annuaire LDAP en face :\nActive Directory Red Hat Directory Server Tivoli Novell eDirectory Other L'annuaire installé étant OpenLDAP, other est le choix à faire.\nParamétrage - 2nd partie Connection URL : Indiquer le chemin d'accès au serveur LDAP Users DN : Indiquer le chemin d'accès aux utilisateurs dans l'annuaire. Bind DN : Indiquer un compte dans l'annuaire ayant des droits d'écriture. Bind Credential : Le mot de passe du compte spécifié dans \u0026quot;Bind DN\u0026quot;. Synchronisation Un peu plus bas de la page de configuration de la connexion au serveur LDAP, un menu Sync Settings est disponible :\nBatch Size : Le nombre de compte utilisateurs qui seront traités en une synchronisation. Periodic Full Sync : La planification en secondes de la synchronisation totale / complète. Periodic Changed Users Sync : La planification en secondes de la synchronisation des changements apportés aux attributs utilisateurs. Après avoir sauvegarder tous les paramètres, il est possible de déclencher manuellement une première synchronisation des utilisateurs de l'annuaire LDAP dans Keycloak :\nMappers Par défaut, des Mappers sont mis en place. Un mapper va permettre de mapper un attribut utilisateur de l'annuaire LDAP à un attribut utilisateur de Keycloak :\nDans mes différents essais, en déployant cette solution de SSO avec un OpenLDAP, il est apparu que l'attribut firstName de Keycloak est mappé avec l'attribut cn de l'annuaire LDAP. L'attribut cn dans l'annuaire (avec la couche FusionDirectory) est une concaténation du prénom et du nom de l'utilisateur :\nAu lieu de modifier la configuration de l'annuaire LDAP, modifier le mapper first name dans Keycloak :\nModifier LDAP Attribute pour indiquer givenName.\ngivenName est le nom de l'attribut prénom au sein de l'annuaire LDAP dans notre configuration.\n","date":"2021-11-04T17:33:31+01:00","image":"/keycloak-integration-ldap-externe/cover.png","permalink":"/keycloak-integration-ldap-externe/","title":"Keycloak : Integration LDAP externe"},{"content":"Introduction OpenLDAP est un annuaire informatique qui fonctionne sur le modèle client/serveur. Il contient des informations de n'importe quelle nature qui sont rangées de manière hiérarchique. Pour bien comprendre le concept, il est souvent comparé aux pages jaunes, où le lecteur recherche un numéro de téléphone particulier : il va d'abord sélectionner la profession, puis la ville, puis le nom de l'entrée pour trouver finalement le numéro de téléphone. En pratique, dans un réseau informatique, il est utilisé pour enregistrer une grande quantité d'utilisateurs ou de services, parfois des centaines de milliers. Il permet d'organiser hiérarchiquement les utilisateurs par département, par lieu géographique ou par n'importe quel autre critère. C'est une alternative libre à Microsoft Active Directory.\nSource : OpenLDAP — Wikipédia (wikipedia.org)\nFusionDirectory est une application web qui permet la gestion des infrastructures et le déploiement des systèmes. Son but est de faciliter le travail de l’administrateur système indépendamment de la taille et de la variété du parc à gérer.\nSource : FusionDirectory — Wikilivres (wikibooks.org)\nDans cet article, je vais présenter l'installation et la configuration initiale d'OpenLDAP avec FusionDirectory sur un même serveur Debian 10 fraîchement installé avec les outils de base.\nPrérequis Un serveur Debian 10 fraîchement installé et à jour.\nUne adresse IP statique doit être configuré sur le serveur.\nLe nom d'hôte du serveur doit être le FQDN futur dans l'annuaire ldap.\nVérifier les fichiers /etc/hostname et /etc/hosts.\n# Exemple d\u0026#39;un fichier /etc/hostname srv-ldap.domaine.local # Exemple d\u0026#39;un fichier /etc/hosts 127.0.0.1 localhost 127.0.1.1 srv-ldap 192.168.1.10 srv-ldap.domaine.local srv-ldap Installation OpenLDAP Installer les paquets nécessaires :\nsudo apt install slapd ldap-utils Saisir le mot de passe souhaité pour le compte admin de l'annuaire :\nSaisir une seconde fois le mot de passe pour confirmer.\nVérifier l'installation d'OpenLDAP :\nsudo slapcat Voici le retour attendu :\ndn: dc=domaine,dc=local objectClass: top objectClass: dcObject objectClass: organization o: domaine.local dc: domaine structuralObjectClass: organization entryUUID: a91714fa-d1a0-103b-9752-7ba3681b6a0b creatorsName: cn=admin,dc=domaine,dc=local createTimestamp: 20211104095226Z entryCSN: 20211104095226.276305Z#000000#000#000000 modifiersName: cn=admin,dc=domaine,dc=local modifyTimestamp: 20211104095226Z dn: cn=admin,dc=domaine,dc=local objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9bHRGR2hnUTNCMTdLcWlUSTI1UVU2TjI2d3U4dmhydWc= structuralObjectClass: organizationalRole entryUUID: a9175640-d1a0-103b-9753-7ba3681b6a0b creatorsName: cn=admin,dc=domaine,dc=local createTimestamp: 20211104095226Z entryCSN: 20211104095226.278012Z#000000#000#000000 modifiersName: cn=admin,dc=domaine,dc=local modifyTimestamp: 20211104095226Z La configuration du schéma de l'annuaire sera faites à travers FusionDirectory.\nFusionDirectory Récupérer et ajouter la clef GPG officielle de FusionDirectory :\nwget https://public.fusiondirectory.org/FD-archive-key sudo apt install -y gnupg2 \u0026amp;\u0026amp; sudo apt-key add FD-archive-key Ajouter le repository de fusiondirectory pour debian :\nsudo cat \u0026gt; /etc/apt/sources.list.d/fusiondirectory-release.list \u0026lt;\u0026lt; \u0026#39;EOL\u0026#39; #fusiondirectory repository deb https://public.fusiondirectory.org/stretch-fusiondirectory-release/ stretch main EOL Ajouter le repository de schema2ldif pour debian :\nsudo cat \u0026gt; /etc/apt/sources.list.d/schema2ldif-release.list \u0026lt;\u0026lt; \u0026#39;EOL\u0026#39; #latest version of schema2ldif deb https://public.fusiondirectory.org/stretch-schema2ldif-release/ stretch main EOL Mettre à jour la liste des paquets :\nsudo apt update Les repositories étant en https, installer le paquet apt-transport-https :\nsudo apt install apt-transport-https Installer les paquets pour FusionDirectory :\nsudo apt install fusiondirectory fusiondirectory-schema Apache2 sera déployé en même temps. Il est possible de se reposer sur un autre serveur web mais cela ne sera pas abordé ici.\nInstaller les paquets manquant pour PHP :\nsudo apt install php-xml Installer les schémas FusionDirectory dans la base LDAP :\nsudo fusiondirectory-insert-schema Redémarrer Apache2 :\nsudo systemctl restart apache2.service Configuration Se connecter à la WebUI de FusionDirectory : http://srv-ldap.domaine.local/fusiondirectory/\nPour accéder au serveur, il est nécessaire de mettre un token dans un fichier. Celui-ci est indiquer sur la WebUI :\nCopier / Coller la commande avant de cliquer sur Suivant :\nsudo echo -n cm5ch69brdj9jdm8uejjrfans0 \u0026gt; /var/cache/fusiondirectory/fusiondirectory.auth Configurer la langue :\nVérifier que l'installation soit entièrement en vert avant de continuer :\nVérifier les informations de connexion au serveur LDAP et saisir le mot de passe du compte admin de l'annuaire spécifié lors de l'installation d'OpenLDAP plus haut :\nRégler le fuseau horaire :\nLa configuration par défaut est conservé dans cette procédure. Il est bien évidement possible de la modifier plus tard pour par définir une politique de sécurité des mots de passes par exemple.\nUne inspection LDAP est effectuée et propose plusieurs actions afin d'être pleinement compatible avec FusionDirectory. Effectuer les actions nécessaires :\nTélécharger le fichier de configuration :\nPlacer ce fichier fusiondirectory.conf dans le répertoire du serveur /etc/fusiondirectory/.\nVérifier la configuration de FusionDirectory :\nsudo fusiondirectory-setup --check-config Une erreur est détectée. Répondre Yes afin de corriger les permissions du fichier de configuration de fusion :\nChecking FusionDirectory\u0026#39;s config file /etc/fusiondirectory/fusiondirectory.conf exists… /etc/fusiondirectory/fusiondirectory.conf is not set properly, do you want to fix it ?: [Yes/No]? Yes OpenLDAP et FusionDirectory sont fonctionnels :\nAttribut mail Par défaut, il n'y pas d'attribut mail sur un utilisateur. Cependant, il est possible de l'ajouter.\nInstaller les paquets nécessaires :\nsudo apt install fusiondirectory-plugin-mail fusiondirectory-plugin-mail-schema Modifier le schéma de l'annuaire afin de faire apparaitre l'attribut mail :\nsudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/mail-fd.schema Il est désormais possible de spécifier une adresse mail pour les utilisateurs :\n","date":"2021-11-04T13:12:04+01:00","image":"/openldap-installation-avec-fusiondirectory/cover.png","permalink":"/openldap-installation-avec-fusiondirectory/","title":"OpenLDAP : Installation avec FusionDirectory"},{"content":"Introduction Samba permet d'implémenter le protocole propriétaire SMB/CIFS de Microsoft sous un environnement Unix et ses dérivés. Il offre la possibilité de partager des ressources dans un SI hétérogène Windows/Linux.\nA partir de la version 3, Samba fournit le partage de fichiers/imprimantes et peut intégrer un domaine Active Directory en tant que membre. Il peut également être PDC (Primary Domain Controller) avec un niveau fonctionnel NT4.\nA partir de la version 4, Samba peut servir de contrôleur de domaine Active Directory avec un niveau fonctionnel Windows Server 2008 et offre les services d'authentification AD. Des GPOs peuvent être déployées.\nDans cette procédure, une distribution Debian 10 et Samba en version 4 sont utilisées.\nLe serveur samba sera nommé : srv-samba Le domaine sera : domaine.local L'adresse IP du serveur samba sera : 192.168.1.10 Préparation Modifier le nom du serveur en y indiquant le futur domaine :\nsudo echo \u0026#34;srv-samba.domaine.local\u0026#34; \u0026gt; /etc/hostname # Pour la persistence après un reboot sudo hostname $(cat /etc/hostname) # Pour modifier le nom sans avoir à reboot Attribuer une adresse IP fixe :\nsudo vi /etc/network/interfaces # Exemple : # auto ens18 # iface ens18 inet static # address 192.168.1.10 # netmask 255.255.255.0 # gateway 192.168.1.254 Modifier le fichier hosts en conséquence :\nsudo echo \u0026#34;192.168.1.10 srv-samba.domaine.local srv-samba\u0026#34; \u0026gt;\u0026gt; /etc/hosts Installation et configuration de Samba Installation des paquets nécessaires :\nsudo apt -y install samba krb5-config winbind smbclient Modifier smb.conf pour utiliser les paramètres WINS fournis par DHCP ? : Non Royaume (« realm ») Kerberos version 5 par défaut : domaine.local Serveurs Kerberos du royaume : srv-samba.domaine.local Serveur administratif du royaume Kerberos : srv-samba.domaine.local Samba est installé.\nCréation du domaine Renommer le fichier de configuration principal de samba /etc/samba/smb.conf :\nsudo mv /etc/samba/smb.conf /etc/samba/smb.conf.org Provisionner le domaine :\nsudo samba-tool domain provision Realm [DOMAINE.LOCAL]: Appuyer sur Entrée Domain [DOMAINE]: Appuyer sur Entrée Server Role (dc, member, standalone) [dc]: Appuyer sur Entrée DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: Appuyer sur Entrée (Le serveur DNS sera interne à Samba dans cette installation) DNS forwarder IP address (write 'none' to disable forwarding) [1.1.1.1]: Appuyer sur Entrée Administrator password: Saisir le mot de passe admin du domaine Retype password: Ressaisir le mot de passe admin du domaine Le domaine est créé :\nLooking up IPv4 addresses Looking up IPv6 addresses No IPv6 address will be assigned Setting up share.ldb Setting up secrets.ldb Setting up the registry Setting up the privileges database Setting up idmap db Setting up SAM db Setting up sam.ldb partitions and settings Setting up sam.ldb rootDSE Pre-loading the Samba 4 and AD schema Unable to determine the DomainSID, can not enforce uniqueness constraint on local domainSIDs Adding DomainDN: DC=domaine,DC=local Adding configuration container Setting up sam.ldb schema Setting up sam.ldb configuration data Setting up display specifiers Modifying display specifiers and extended rights Adding users container Modifying users container Adding computers container Modifying computers container Setting up sam.ldb data Setting up well known security principals Setting up sam.ldb users and groups Setting up self join Adding DNS accounts Creating CN=MicrosoftDNS,CN=System,DC=domaine,DC=local Creating DomainDnsZones and ForestDnsZones partitions Populating DomainDnsZones and ForestDnsZones partitions Setting up sam.ldb rootDSE marking as synchronized Fixing provision GUIDs A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink! Once the above files are installed, your Samba AD server will be ready to use Server Role: active directory domain controller Hostname: srv-samba NetBIOS Domain: DOMAINE DNS Domain: domaine.local DOMAIN SID: S-1-5-21-1555810112-1359199810-2012430263 Mise en service du domaine Copier le fichier de configuration de kerberos dans le répertoire /etc :\nsudo cp /var/lib/samba/private/krb5.conf /etc/ Arrêter les services SMB, NMBD et Bind :\nsudo systemctl stop smbd nmbd winbind Désactiver les services SMB, NMBD et Bind :\nsudo systemctl disable smbd nmbd winbind Rendre visible le service samba-ad-dc :\nsudo systemctl unmask samba-ad-dc Démarrer le service :\nsudo systemctl start samba-ad-dc Activer le service :\nsudo systemctl enable samba-ad-dc Vérifier le statut de Samba :\nsmbclient -L localhost -U% Tout est OK :\nSharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.9.5-Debian) Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- ------- WORKGROUP SRV-SAMBA Vérifier le niveau fonctionnel du domaine :\nsudo samba-tool domain level show Le niveau fonctionnel du domaine est Windows 2008 R2 :\nDomain and forest function level for domain \u0026#39;DC=domaine,DC=local\u0026#39; Forest function level: (Windows) 2008 R2 Domain function level: (Windows) 2008 R2 Lowest function level of a DC: (Windows) 2008 R2 Création utilisateur Créer un 1er utilisateur dans l'annuaire :\nsudo samba-tool user create superman Indiquer le mot de passe de superman :\nNew Password: Retype Password: User \u0026#39;superman\u0026#39; created successfully Jonction au domaine La jonction au domaine d'un poste Windows est identique qu'avec un contrôleur de domaine Microsoft. Les outils d'administrations (RSAT) peuvent être employé pour administrer les objets du domaine (dsa.msc), les gpo (gpmc.msc), le serveur dns (dnsmgmt.msc)...\nAvec un DC Microsoft, un compte utilisateur du domaine peut être employé pour joindre un poste au domaine. Avec samba, le compte administrator doit être employé.\n","date":"2021-10-29T10:40:56+02:00","image":"/samba-installation-dun-controleur-de-domaine/cover.png","permalink":"/samba-installation-dun-controleur-de-domaine/","title":"Samba : Installation d’un contrôleur de domaine"},{"content":"Introduction Par défaut, OpenProject utilise une base locale d'utilisateurs pour gérer l'authentification. Afin de centraliser l'authentification sur un serveur dédié (avec OpenID-Connect) Keycloak, une configuration SSO est nécessaire sur OpenProject.\nOpenProject va utiliser OpenID-Connect pour faire du SSO. Ca tombe bien Keycloak aussi ! Un paramétrage concernant cela est disponible via la web UI d'administration d'OpenProject mais celle-ci ne concerne que Google et Azure. Fort heureusement, c'est tout de même possible en éditant un fichier.\nRéférence :\nOpenProject : Installation Keycloak : Installation avec Docker et reverse-proxy SSL Nginx Pré-requis Pour mener à bien cette procédure, il faut :\nUn serveur OpenProject installé avec une licence Entreprise Un serveur Keycloak installé Pour la licence OpenProject Entreprise, il est possible de faire un essai de 14 jours gratuitement. Sans licence Entreprise, le SSO n'est pas pris en charge par OpenProject. Lorsque l'essai de la version Entreprise arrive à son terme et que celle-ci n'est pas prolongé, alors la licence repasse automatique en Community Edition (Free).\nConfiguration partie Keycloak Création d'un royaume : Création d'un client : Root URL : L'URL d'accès au serveur OpenProject.\nDans les propriétés du client nouvellement créer, définir l' Access Type sur confidential afin de générer un secret : Bien penser à sauvegarder la modification en bas de la page.\nUn nouvel onglet Credentials est apparu dans les propriétés du client. Un secret a été généré : Créer un compte utilisateur si le serveur Keycloak est fraichement installé : Attention : Sur l'illustration, seul le champ Username est indiqué comme obligatoire. Lorsque qu'un utilisateur s'authentifiera avec son compte Keycloak sur OpenProject, les champs Email , First Name , Last Name seront obligatoires. Ces propriétés ne peuvent en cas cas être communes à un autre compte.\nUne fois l'utilisateur créé, dans l'onglet Credentials , définir son mot de passe : Configuration partie OpenProject Pour qu'un utilisateur puisse utiliser son compte Keycloak pour s'authentifier sur OpenProject, celui-ci doit être activé dans OpenProject. Par défaut l'activation se fait manuellement. Pour automatiser ce processus, une option d' activation automatique du compte existe dans OpenProject.\nSe connecter en admin sur OpenProject puis \u0026quot;Administration -\u0026gt; Authentification\u0026quot;, modifier l'option Auto-enregistrement comme suit : Pour la suite des opérations, se connecter en SSH sur le serveur OpenProject.\nModifier le fichier /opt/openproject/config/configuration.yml afin d'ajouter la possibilité de s'authentifier sur OpenProject au travers du serveur SSO Keycloak. Ajouter les lignes suivantes dans la section default : default: # omniauth_direct_login_provider: openid openid_connect: openid: host: \u0026#34;keycloak.example.fr\u0026#34; identifier: \u0026#34;MonOpenProject\u0026#34; secret: \u0026#34;af90aced-0000-0000-0000-0959e6fd5226\u0026#34; icon: \u0026#34;openid_connect/auth_provider-google.png\u0026#34; display_name: \u0026#34;SSO\u0026#34; authorization_endpoint: \u0026#34;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth\u0026#34; token_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token\u0026#39; userinfo_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo\u0026#39; end_session_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout\u0026#39; check_session_iframe: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html\u0026#39; sso: true issuer: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume\u0026#39; discovery: false Adapter les valeurs suivantes :\nhost : Le FQDN du serveur Keycloak identifier : Le nom du client créé dans Keycloak secret : Le secret du client généré dans Keycloak # Les URLS suivantes peuvent facilement être obtenues dans Keycloak # Realm Settings -\u0026gt; Endpoints : OpenIP Endpoint Configuration authorization_endpoint: \u0026#34;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth\u0026#34; token_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token\u0026#39; userinfo_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo\u0026#39; end_session_endpoint: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout\u0026#39; check_session_iframe: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html\u0026#39; issuer: \u0026#39;https://keycloak.example.fr/auth/realms/MonRoyaume\u0026#39; La directive omniauth_direct_login_provider indique que seul l'authentification passera par keycloak. Commenter cette directive pour avoir le choix d'authentification entre keycloak (SSO) ou la base locale d'OpenProject.\nOpenProject : Redémarrer le service openproject sudo systemctl restart openproject Vérification du fonctionnement Dorénavant lors de la connexion sur OpenProject, une option de connexion SSO est disponible : Le serveur Keycloak prends le relais pour demander les credentials : Après la 1ère connexion d'un utilisateur au travers du SSO, celui-ci est présent dans OpenProject avec un fournisseur d'authentification OpenID : ","date":"2021-10-28T14:40:22+02:00","image":"/openproject-mise-en-place-du-sso-avec-keycloak/cover.jpg","permalink":"/openproject-mise-en-place-du-sso-avec-keycloak/","title":"OpenProject : Mise en place du SSO avec Keycloak"},{"content":"Introduction WordPress est une application web extrêmement populaire. Il existe de nombreuses attaques de brute-force sur la page de login de WordPress. Ces attaques peuvent générées des milliers de tentatives de login à votre application WordPress.\nCet article fait suite à Fail2ban : Installation et configuration.\nPar défaut fail2ban est embarqué avec de nombreuses jails mais aucune pour protéger l'authentification de WordPress. Avant de configurer une jail pour WordPress, il va falloir faire quelques modifications en son sein. En effet par défaut, lorsqu'un utilisateur tente de s'authentifier, un message s'affiche à l'écran indiquant une erreur mais surtout la page retourne un code HTTP 200 (le même que celui lors d'un succès d'authentification). Cela sera modifié.\nConfiguration Prérequis L'installation et les explications sur la configuration général de fail2ban est décrite dans cet article : Fail2ban : Installation et configuration. Fail2ban doit être installé et fonctionnel. Modification du code HTTP Comme expliqué en introduction, lors d'un échec d'authentification sur la page de login de WordPress, celui-ci génère un code http identique à celui d'un succès.\nModifier le fichier functions.php de votre thème WordPress pour y inclure :\n/* Change WP-Admin login error message to be more generic */ function generic_login_msg ($msg) { global $errors; $err_codes = $errors-\u0026gt;get_error_codes(); if ( in_array( \u0026#39;invalid_username\u0026#39;, $err_codes ) || in_array(\u0026#39;incorrect_password\u0026#39;, $err_codes )) { $msg = \u0026#39;ERROR: Invalid credential.\u0026#39;; } return $msg; } add_filter(\u0026#39;login_errors\u0026#39;, \u0026#39;generic_login_msg\u0026#39;); /* Return 403 instead of 200 when wp-login failed */ add_action( \u0026#39;wp_login_failed\u0026#39;, function () { status_header(403); } ); Cela aura pour effet d'indiquer un message générique sur la page lors d'un échec d'authentification et surtout de générer un code HTTP 403. Le code HTTP 200 sera toujours le code retour lors d'un succès d'authentification.\n11.22.33.44 - - [26/Oct/2021:01:52:10 +0200] \u0026#34;POST /wp-login.php HTTP/1.1\u0026#34; 403 3149 \u0026#34;https://wordpress.example.com/wp-login.php\u0026#34; \u0026#34;Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30\u0026#34; Création du filtre fail2ban Fail2ban n'a pas de preset de filtre pour l'authentification de WordPress. Créer un filtre :\nsudo vi /etc/fail2ban/filter.d/wp-login.conf Ajouter le filtre suivant :\n[Definition] _daemon = wp-login failregex = \u0026lt;HOST\u0026gt;.*POST.*(wp-login\\.php|xmlrpc\\.php).* 403 failregex va matcher sur les requêtes POST à destination de wp-login.php et xmlrpc.php portant un code HTTP 403.\nAjouter la jail dans /etc/fail2ban/jail.local :\n[wordpress] enabled = true port = http,https filter = wp-login logpath = /var/log/nginx/access.log Redémarrer fail2ban :\nsudo systemctl restart fail2ban Vérifier la prise en compte de la jail avec :\nsudo fail2ban-client status Le retour doit être :\nStatus |- Number of jail: 1 `- Jail list: wordpress ","date":"2021-10-26T02:43:26+02:00","image":"/fail2ban-proteger-lauthentification-wordpress-sous-nginx/cover.png","permalink":"/fail2ban-proteger-lauthentification-wordpress-sous-nginx/","title":"Fail2ban : Protéger l’authentification WordPress sous Nginx"},{"content":"Introduction Keycloak est une solution opensource permettant d'implémenter du SSO (Single-Sign-On) au sein d'une infrastructure. Il est compatible avec les principaux protocoles d'authentification (OAuth2.0, OpenID-Connect). Il peut être couplé à un annuaire LDAP.\nDans cet article, Keycloak, va être déployé sur une Debian 10 conteneurisé dans 2 images dockers. Docker-Compose va orchestrer le tout. Un serveur nginx sera en frontal en tant que reverse-proxy.\nPrérequis 1 serveur Debian 10 à jour qui sera dédié à hébergé le serveur Keycloack\n1 serveur web Nginx opérationnel\nCertificats SSL générés pour votre nom de domaine\nVoir article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS\nInstallation Installation des paquets Installer docker :\nsudo apt install docker Installer docker-compose :\nsudo apt install docker-compose Vérifier l'installation de docker-compose :\ndocker-compose --version Création du docker-compose Créer un répertoire afin d'y stocker le fichier docker-compose :\nsudo mkdir keycloak Se positionner dans le répertoire nouvellement créé :\ncd keycloak Créer un fichier docker-compose.yml :\nsudo vi docker-compose.yml Attention, le fichier doit être au format YAML ce qui signifie que la tabulation est interdite (il faut mettre des espaces pour l'indentation).\nCopier / Coller le fichier suivant :\nversion: \u0026#39;3.3\u0026#39; volumes: postgres_data: driver: local services: postgres: image: postgres volumes: - postgres_data:/var/lib/postgresql/data environment: POSTGRES_DB: keycloak POSTGRES_USER: keycloak POSTGRES_PASSWORD: password keycloak: image: jboss/keycloak:latest environment: PROXY_ADDRESS_FORWARDING: \u0026#39;true\u0026#39; DB_VENDOR: POSTGRES DB_ADDR: postgres DB_DATABASE: keycloak DB_USER: keycloak DB_PASSWORD: password KEYCLOAK_USER: admin KEYCLOAK_PASSWORD: Mon_mot_de_passe ports: - 9090:8080 depends_on: - postgres Le numéro de version indiqué en 1ère ligne peut varier suivant votre version de docker-compose. Dans mon cas, j'ai une version de docker-compose en 1.21.0.\nLe port de keycloak dans le conteneur est le 8080, il sera bind sur le 9090 du serveur.\nLa directive PROXY_ADDRESS_FORWARDING est très importante dans le cas d'une utilisation de reverse proxy.\nLancement du docker-compose Exécuter le docker-compose :\nsudo docker-compose -f ~/keycloak/docker-compose.yml up Pour lancer le docker-compose en arrière-plan :\nsudo docker-compose -f ~/keycloak/docker-compose.yml up -d Vérifier que les conteneurs docker soient bien démarrés :\nsudo docker ps Le résultat soit être similaire à :\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 643f26101b75 jboss/keycloak:latest \u0026#34;/opt/jboss/tools/do…\u0026#34; About a minute ago Up 52 seconds 8443/tcp, 0.0.0.0:9090-\u0026gt;8080/tcp keycloak_keycloak_1 6789a8285283 postgres \u0026#34;docker-entrypoint.s…\u0026#34; About a minute ago Up 52 seconds 5432/tcp keycloak_postgres_1 Configuration reverse-proxy SSL avec Nginx Un serveur Nginx doit être opérationnel.\nS'appuyer sur cet article : Nginx : Installation d’un Reverse Proxy\nLes certificats SSl doivent être générés.\nS'appuyer sur cet article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS\nCréer le fichier de configuration du virtual host :\nsudo vi /etc/nginx/sites-available/keycloak.conf Copier / Coller le fichier suivant :\nserver { listen 80; server_name keycloak.example.com; rewrite ^ https://keycloak.example.com permanent; } server { listen 443 ssl; server_name keycloak.example.com; ssl_certificate /etc/letsencrypt/live/keycloak.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/keycloak.example.com/privkey.pem; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://IP_MON_SERVEUR_KEYCLOACK:9090; } } Remplacer keycloak.example.com par le nom de domaine pour le serveur keycloak. Le nécessaire doit être fait au sein de la zone DNS. Vérifier les chemins d'accès aux certificats SSL. Modifier la directive proxy_pass pour correspondre avec le serveur keycloak. Créer un lien symbolique pour activer le virtual host :\nsudo ln -s /etc/nginx/sites-available/keycloak.conf /etc/nginx/sites-enabled/keycloak.conf Vérifier la configuration de Nginx avec :\nsudo nginx -t Redémarrer le service nginx :\nsudo systemctl restart nginx Accès administrateur à Keycloak Se rendre à l'adresse : https://keycloak.example.com\nAccéder à Administration Console :\nLes credentials à entrer sont ceux définit dans le fichier docker-compose.yml aux lignes suivantes :\nKEYCLOAK_USER: admin KEYCLOAK_PASSWORD: Mon_mot_de_passe Démarrage automatique avec le système Avec la configuration actuelle au redémarrage du serveur keycloak, le docker-compose ne sera pas lancé.\nPour activer le démarrage automatique des conteneurs Postegresql et Keycloak au boot du serveur, modifier le docker-compose.yml et ajouter cette ligne dans chaque services qui doit démarrer avec le service docker :\nrestart: always Si les conteneurs sont arrêtés à la main, ils ne démarreront pas automatiquement. Docker comprend que c'est une action manuelle et que c'est l'état désiré.\nPour que cela soit fonctionnel, le service docker.service doit être en status enable :\nsudo systemctl status docker.service Le résultat doit être le suivant :\nLoaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Si cela n'est pas le cas :\nsudo systemctl enable docker.service ","date":"2021-10-25T17:37:16+02:00","image":"/keycloak-installation-avec-docker-et-reverse-proxy-ssl-nginx/cover.png","permalink":"/keycloak-installation-avec-docker-et-reverse-proxy-ssl-nginx/","title":"Keycloak : Installation avec Docker et reverse-proxy SSL Nginx"},{"content":"A lire Pour l'instant seul un agent Windows est pleinement fonctionnel. Les versions Linux et macOS sont en cours de développement.\nAfin d'éviter la détection de l'agent par l'antivirus, 2 solutions :\nAgent avec code signé par Microsoft. Un don mensuel de 50$ est demandé afin d'avoir accès à l'agent avec le code signé Microsoft. Le status Sponsor est alors attribué au sein du projet Tactical RMM.\nAgent sans code signé par Microsoft. Le setup généré dynamiquement de l'agent (explications plus bas) sans code signé peut provoquer une alerte virale sur votre système. L'utilisation de l'agent générique (via script, gpo) ne provoque pas d'alerte virale.\nPenser à vérifier vos exclusions antivirus une fois l'agent Windows déployé:\nC:\\Program Files\\TacticalAgent\\* C:\\Program Files\\Mesh Agent\\* C:\\Windows\\Temp\\winagent-v*.exe C:\\Windows\\Temp\\trmm\\* C:\\temp\\tacticalrmm*.exe Lors du déploiement de l'agent, les exclusions sont automatiquement créées dans Windows Defender.\nPar défaut les mises à jour Windows sont désactivées automatiquement après l'installation de l'agent.\nDéploiement agent L'exécution de l'installation des agents doit être effectué sur les hôtes à surveiller.\nDéploiement manuel Se rendre sur https://rmm.example.com.\nClic droit sur le client/site puis Install Agent.\nVérifier que le Client et le Site soient corrects.\nDéfinir le type de machine (Server / Workstation) à qui s'adresse l'agent.\nDéfinir le temps de validité de l'agent (Token expiration).\nDéfinir les options appliqués par l'agent (Enable RDP, Enable Ping, Disable sleep/hibernate).\nSélectionner la méthode d'installation souhaitée :\nAgent généré dynamiquement Attention à l'antivirus si le code de l'agent est non signé par Microsoft. Voir la section A lire au début de cet article.\nPowershell : Génération d'un script Powershell. L'agent est générique et le scripts contient tous les paramètres de l'agent.\nAutoriser l'exécution du script Powershell :\nPS C:\\\u0026gt; Set-ExecutionPolicy Unrestricted Manuel : L'agent est générique. Le script d'exécution est afficher à l'écran. Cette méthode est préconisée pour l'intégration dans des scripts et/ou des GPOs. Attention à la durée du token si cette méthode est choisie pour une utilisation dans des scripts et/ou GPOs. Mettre une valeur très importante si besoin d'une validité permanente.\nLien de déploiement A partir du client, se rendre sur https://rmm.example.com.\nMenu Agents puis Manage Deployments.\nAstuce : Créer un client/site default avec un lien de déploiement (token avec une longue expiration) pour avoir une URL générique. Puis déplacer l'agent dans le client / site souhaité.\nL'agent téléchargé à travers ce lien est de type dynamique. Il est potentiellement détectable par les antivirus (si code non signé). Se référer à la section A lire en début de cet article. Déploiement par GPO La GPO de déploiement de l'agent doit être appliquée au niveau ordinateur afin que l'installation de l'agent se déroule sous un compte Local System ayant les droits nécessaires.\nRécupérer le script d'installation de l'installation manuelle (voir plus haut) ainsi que l'exécutable de l'agent générique.\nStocker le script et l'agent.exe dans un dossier partager du contrôleur de domaine (exemple: C:\\agent_rmm\\).\nSur le domaine Windows, ouvrir la console MMC des GPOs :\ngpmc.msc Créer une nouvelle GPO ciblant une OU contenant des Ordinateurs. Editer cette GPO. Trois étapes sont nécessaire pour que celle-ci fonctionne parfaitement.\nLa création d'un dossier sur le poste client. La copie du script et de l'agent.exe sur le poste client. L'exécution d'un script au démarrage du poste client : cd c:\\agent_rmm agent_rmm.bat Patienter ou forcer l'application de la nouvelle GPO :\ngpupdate /force Un modèle de GPO importable dans un domaine est disponible : ICI Arguments optionnels Quelques arguments qui peuvent être utilisés dans des scripts :\n-log debug : Affiche un log verbeux lors de l'installation de l'agent\n-silent : Aucun message durant l'installation de l'agent\n-proxy \u0026quot;http://proxyserver:port\u0026quot; : Pour utiliser un proxy\n-meshdir \u0026quot;C:\\Mesh Agent\u0026quot; : Spécifier le chemin contenant meshagent.exe\n-nomesh : N'installe pas l'agent meshcentral. Pas de take control, remote terminal, file browser\n","date":"2021-10-21T10:35:03+02:00","image":"/tactical-rmm-agent-installation/cover.png","permalink":"/tactical-rmm-agent-installation/","title":"Tactical RMM : Agent installation"},{"content":"Recommandations Le système doit être à jour (exemple sur Debian) : sudo apt -y update sudo apt -y upgrade Cela est important car sinon le script de mise à jour pour Tactical RMM peut rencontrer des erreurs.\nNe jamais programmer de mise à jour automatique du serveur RMM via une tâche cron. Certaines mise à jour demande une interaction de l'utilisateur dans le prompt. Dans le cas d'une mise à jour automatisée, cela pourrait casser le serveur.\nDe même, modifier le script de mise à jour (update.sh) est fortement déconseillé. Celui-ci est mis à jour automatiquement si besoin vers une nouvelle version.\nToujours exécuter la mise à jour du serveur RMM avec l'utilisateur créé lors de l'installation du serveur Tactical RMM. Faire la mise à jour en tant que root provoquerait des permissions erronées au sein de Tactical RMM.\nMise à jour Télécharger le script de mise à jour : wget -N https://raw.githubusercontent.com/wh1te909/tacticalrmm/master/update.sh Le rendre exécutable : chmod +x update.sh Exécuter la mise à jour : ./update.sh Si la dernière version est déjà présente, le script le notifiera immédiatement. Avec le flag --force, il est possible de bypass la vérification de la version. Cela peut être intéressant pour une mise à jour qui aurait été interrompue et/ou pour résoudre les erreurs de permission (ex: exécution accidentelle en root de script de mise à jour).\nWarning Ne jamais faire de mise à jour manuelle de MashCentral vers une nouvelle version. Le script de mise à jour de tactical rmm le fera pour nous si cela est nécessaire.\nCette procédure de mise à jour a été réalisée pour mettre à jour un serveur Tactical RMM v0.8.4 vers la v0.8.5.\n","date":"2021-10-20T19:43:10+02:00","image":"/tactical-rmm-mise-a-jour-du-serveur/cover.png","permalink":"/tactical-rmm-mise-a-jour-du-serveur/","title":"Tactical RMM : Mise à jour du serveur"},{"content":"Environnement virtuel Python Se connecter en SSH au serveur Tactical RMM.\nLancer l'environnement virtuel python :\ncd /rmm/api/tacticalrmm source ../env/bin/activate Les commandes Reset a user's password :\npython manage.py reset_password USERNAME Reset a user's 2fa token :\npython manage.py reset_2fa USERNAME Find all agents that have X software installed :\npython manage.py find_software \u0026#34;adobe\u0026#34; Show outdated online agents :\npython manage.py show_outdated_agents Log out all active web sessions :\npython manage.py delete_tokens Check for orphaned tasks on all agents and remove them :\npython manage.py remove_orphaned_tasks Create a MeshCentral agent invite link :\npython manage.py get_mesh_exe_url Bulk update agent offline/overdue time :\nChange offline time on all agents to 5 minutes : python manage.py bulk_change_checkin --offline --all 5 Change offline time on all agents in site named Example Site to 2 minutes : python manage.py bulk_change_checkin --offline --site \u0026#34;Example Site\u0026#34; 2 Change offline time on all agents in client named Example Client to 12 minutes : python manage.py bulk_change_checkin --offline --client \u0026#34;Example Client\u0026#34; 12 Change overdue time on all agents to 10 minutes : python manage.py bulk_change_checkin --overdue --all 10 Change overdue time on all agents in site named Example Site to 4 minutes : python manage.py bulk_change_checkin --overdue --site \u0026#34;Example Site\u0026#34; 4 Change overdue time on all agents in client named Example Client to 14 minutes : python manage.py bulk_change_checkin --overdue --client \u0026#34;Example Client\u0026#34; 14 ","date":"2021-10-20T19:12:35+02:00","image":"/tactical-rmm-les-commandes-de-management/cover.png","permalink":"/tactical-rmm-les-commandes-de-management/","title":"Tactical RMM : Les commandes de management"},{"content":"Contexte OpenProject sera installé sur Debian 10. La base de données recommandée est PostgreSQL. Le serveur web recommandé est Apache. Installation Installer gnupg2 :\nsudo apt install gnupg2 Importer la clef PGP utilisées pour signer les paquets openproject :\nwget -qO- https://dl.packager.io/srv/opf/openproject/key | sudo apt-key add - Ajouter le repo adéquat :\nsudo wget -O /etc/apt/sources.list.d/openproject.list \\ https://dl.packager.io/srv/opf/openproject/stable/11/installer/debian/10.repo Télécharger et installer openproject :\nsudo apt-get update sudo apt-get install openproject Configuration Pré-requis Si une base de données PostgreSQL externe veut être utilisée en lieu et place d'une base de données locale, s'assurer d'avoir les informations suivantes : database hostname port username password L'utilisateur utilisé pour la connexion à la base de données doit avoir le privilège CREATE DATABASE.\nSi le HTTPS est utilisé, prévoir le chemin d'accès vers le : certificate file private key file CA bundle file Lancer le wizard Exécuter le wizard :\nsudo openproject configure Si une erreur se produit et/ou une reconfiguration est nécessaire, annuler le wizard avec CTRL+C et relancer le wizard avec sudo openproject reconfigure. Les choix fait durant le wizard sont persistent dans le fichier /etc/openproject/installer.datet l'exécution de sudo openproject configureréutilise ces valeurs. Seul les options non présentes dans le fichier installer.datseront alors demandées. Pour relancer la demande de tous les paramètres : sudo openproject reconfigure. Choisir l\u0026rsquo;édition OpenProject est fournit avec 2 éditions :\nL'édition par défaut : Pour une gestion de projet générale. L'édition BIM : Pour une gestion de projet axée dans l'industrie du bâtiment/construction. Plus d'information sur la BIM Edition ici.\nLa slection de l'édition est uniquement disponible sur les distributions suivantes :\nRHEL/CentOS 8 Ubuntu 20.04 Ubuntu 18.04 Debian 10 Debian 11 Configuration base de données OpenProject requiert une base de données PostgreSQL pour stocker les données.\nCette étape va permettre de sélectionner la méthode de connexion à cette base de données.\n3 options :\nSkip : Pas de connexion à une base de données. Il sera nécessaire de spécifier une base de données manuellement à l'aide de la variable DATABASE_URL : sudo openproject config:set DATABASE_URL=\u0026#34;postgresql://[user[:password]@][host][:port][/dbname][?param1=value1\u0026amp;...]\u0026#34; Install : Le wizard installe et configure une base de données PostgreSQL locale. C'est cette option qui sera retenu dans cette documentation.\nReuse : Pour utiliser une base de données PostgreSQL existante. Des paramètres de connexion supplémentaire sont demandés lors de ce choix.\nApache2 OpenProject comprend un serveur d'application en ruby interne. Seulement le serveur écoute uniquement sur une interface locale.\nPour pouvoir y accéder d'Internet, il est nécessaire d'avoir un serveur web comme proxy transférer les connexions entrantes vers le serveur applicatif OpenProject.\nLe wizard propose d'installer automatiquement un serveur web Apache2 pour agir comme un proxy.\n2 options :\nInstall : Option recommandée. Installe et configure un serveur web Apache2 avec un virtual host du nom de domaine fournit. C'est ce serveur qui fournira du SSL/TLS. Plusieurs options sont demandées par la suite.\nLe nom de domaine pleinement qualifié. Correspond à la valeur ServerNamedu virtual host d'apache.\nPour spécifier un prefix afin d'accéder à l'applicatif (exemple : mondomaine.example.com/openproject) : /openproject. Laisser vide si l'accès désiré à l'application est http(s)://mondomaine.example.com.\nPour utiliser des certificats SSL/TLS, 3 choix supplémentaires sont à faire pour spécifier l'accès aux certificats.\nSkip : Non recommandé. Un serveur web Apache ou Nginx doit être installé et configuré manuellement pour rediriger les requêtes entrantes vers localhost:6000.\nAttention avec un serveur Nginx, toutes les fonctionnalités ne sont pas disponible pour OpenProject.\nSVN/Git intégration Si le choix d'installer automatiquement Apache2 est fait, il est demandé si une intégration de SVN/Git doit être faites.\nPlus d'informations ici\nConfiguration email Configurer la méthode d'envoie de mail pour les diverses notifications.\n3 options :\nSendmail : Utilisation d'une installation de sendmail en locale ou d'un serveur postfix local. SMTP : Option recommandée en production. Autorise la connexion à un serveur SMTP à travers une authentification de type : NONE, PLAIN, LOGIN, CRAM-MD5. Skip : Aucune configuration. Néanmoins, la configuration peut se faire plus tard en se rendant sur l'URL : openproject.example.com/settings?tab=notifications. Serveur Memcached OpenProject a besoin d'un serveur local memcached. L'installation de celui-ci doit \u0026quot;toujours\u0026quot; être faites.\nAccès OpenProject L'installation est terminée.\nL'application OpenProject est disponible à l'adresse : http(s)://openproject.example.com/server prefix.\nUsername = admin\nPassword = admin\nChanger le mot de passe admin immédiatement\nMise à jour PostgreSQL La version actuelle d'OpenProject est la 11.4.0.\nLa prochaine version majeure sera la 12.0 (fin 2021).\nPostgreSQL v13 sera nécessaire.\nInstaller la nouvelle version de PostgreSQL :\nsudo apt-get update sudo apt-get install postgresql-13 Arrêter les serveurs PostgreSQL :\nsudo su - postgres -c \u0026#34;/usr/lib/postgresql/10/bin/pg_ctl stop --wait --pgdata=/var/lib/postgresql/10/main\u0026#34; sudo su - postgres -c \u0026#34;/usr/lib/postgresql/13/bin/pg_ctl stop --wait --pgdata=/var/lib/postgresql/13/main\u0026#34; Migrer les données vers PostgreSQL v13 :\nsudo su - postgres \u0026lt;\u0026lt; CMD /usr/lib/postgresql/13/bin/pg_upgrade \\ --old-bindir=/usr/lib/postgresql/10/bin \\ --new-bindir=/usr/lib/postgresql/13/bin \\ --old-datadir=/var/lib/postgresql/10/main \\ --new-datadir=/var/lib/postgresql/13/main \\ --old-options \u0026#39;-c config_file=/etc/postgresql/10/main/postgresql.conf\u0026#39; \\ --new-options \u0026#39;-c config_file=/etc/postgresql/13/main/postgresql.conf\u0026#39; CMD Faire de PostgreSQL v13 le serveur par défaut sur le port 45432 :\nsudo su - postgres -c \u0026#34;cp /etc/postgresql/{10,13}/main/conf.d/custom.conf\u0026#34; sudo su - postgres -c \u0026#34;sed -i \u0026#39;s|45432|45433|\u0026#39; /etc/postgresql/10/main/conf.d/custom.conf\u0026#34; sudo su - postgres -c \u0026#34;/usr/lib/postgresql/13/bin/pg_ctl start --wait --pgdata=/var/lib/postgresql/13/main -o \u0026#39;-c config_file=/etc/postgresql/13/main/postgresql.conf\u0026#39;\u0026#34; Vérifier dans OpenProject la version de PostgreSQL.\nSupprimer l'ancienne version de PostgreSQL :\nsudo rm -rf /var/lib/postgresql/10/main sudo apt-get purge postgresql-10 ","date":"2021-10-20T14:55:58+02:00","image":"/installation-openproject/cover.jpg","permalink":"/installation-openproject/","title":"OpenProject : Installation"},{"content":"Préambule Redmine peut être installé sur la plupart des systèmes Unix, Linux, macOS, Windows\nLa base de données qu'utilise Redmine peut être MySQL (MariaDB), PostgreSQL, Microsoft SQL, SQLite\nDebian 10 sera choisit pour cette installation avec une base de données MySQL (MariaDB)\nInstallation Apache et paquets nécessaires Installation dépendances nécessaires :\nsudo apt install apt-transport-https ca-certificates dirmngr gnupg2 Installation Apache, MariaDB, Passenger et les autres paquets nécessaires :\nsudo apt install apache2 apache2-dev libapache2-mod-passenger mariadb-server mariadb-client build-essential ruby-dev libxslt1-dev libmariadb-dev libxml2-dev zlib1g-dev imagemagick libmagickwand-dev curl Une fois tous ces paquets et dépendances installés, créer la base de données pour Redmine\nCréation de la base de données Sécurisation de la base de données :\nsudo mysql_secure_installation Suivre les recommandations de sécurisation\nSe connecter en root puis à MariaDB :\nsu - mysql Création d'une base de données \u0026quot;redminedb\u0026quot; et d'un utilisateur mysql \u0026quot;redmineuser\u0026quot; :\nCREATE DATABASE redminedb CHARACTER SET utf8mb4; GRANT ALL PRIVILEGES ON redminedb.* TO \u0026#39;redmineuser\u0026#39;@\u0026#39;localhost\u0026#39; IDENTIFIED BY \u0026#39;my_secure_password\u0026#39;; Flush les privilèges et quitter MariaDB :\nFLUSH PRIVILEGES; EXIT; Se déconnecter de l'utilisateur root :\nexit Installation et configuration Redmine Création d'un utilisateur linux \u0026quot;redmine\u0026quot; pour Redmine :\nsudo useradd -r -m -d /opt/redmine -s /usr/bin/bash redmine Ajout de l'utilisateur redmine au groupe \u0026quot;www-data\u0026quot; :\nsudo usermod -aG redmine www-data Se connecter avec l'utilisateur redmine et télécharger la dernière version de Redmine :\nsu - redmine wget https://www.redmine.org/releases/redmine-4.2.3.tar.gz Extraire l'archive téléchargée :\ntar -xvzf redmine-4.2.3.tar.gz -C /opt/redmine/ --strip-components=1 Copie des fichiers de configurations exemples :\ncp /opt/redmine/config/configuration.yml{.example,} cp /opt/redmine/public/dispatch.fcgi{.example,} cp /opt/redmine/config/database.yml{.example,} Editer le fichier database.yml et y définir les paramètres de la base de données :\nvi /opt/redmine/config/database.yml Faire les modifications suivantes :\nproduction: adapter: mysql2 database: redminedb host: localhost username: redmineuser password: \u0026#34;my_secure_password\u0026#34; Sauvegarder le fichier et quitter l'utilisateur redmine :\nexit Se rendre dans le répertoire \u0026quot;/opt/redmine\u0026quot; et installer \u0026quot;Bundler\u0026quot; :\ncd /opt/redmine sudo gem install bundler Se connecter avec l'utilisateur redmine et installer les dépendances gems nécessaires :\nsu - redmine bundle install --without development test --path vendor/bundle Générer un token secret :\nbundle exec rake generate_secret_token Créer une structure de base de données Rails et insérer les données de configuration par défaut dans la bdd :\nRAILS_ENV=production bundle exec rake db:migrate RAILS_ENV=production REDMINE_LANG=en bundle exec rake redmine:load_default_data Créer les répertoires et fichiers nécessaires :\nfor i in tmp tmp/pdf public/plugin_assets; do [ -d $i ] || mkdir -p $i; done Définir les permission sur le dossier /opt/redmine :\nchown -R redmine:redmine files log tmp public/plugin_assets chmod -R 755 /opt/redmine Se déconnecter de l'utilisateur Redmine :\nexit Configuration Apache Désactiver le site par défaut :\nsudo a2dissite 000-default.conf Créer un virtual host pour Redmine :\nsudo vi /etc/apache2/sites-available/redmine.conf Ajout des lignes suivantes :\n\u0026lt; VirtualHost *:80\u0026gt; ServerName redmine.example.com RailsEnv production DocumentRoot /opt/redmine/public \u0026lt; Directory \u0026#34;/opt/redmine/public\u0026#34;\u0026gt; Allow from all Require all granted \u0026lt; /Directory\u0026gt; ErrorLog ${APACHE_LOG_DIR}/redmine_error.log CustomLog ${APACHE_LOG_DIR}/redmine_access.log combined \u0026lt; /VirtualHost\u0026gt; Attention ! Enlever l'espace après le 1er chevron.\nSauvegarder le fichier, activer le virtual host redmine et redémarrer le service apache :\nsudo a2ensite redmine sudo systemctl restart apache2 Accès Redmine Ouvrir un navigateur web et se rendre sur http://redmine.example.com\nCliquer sur \u0026quot;Connexion\u0026quot;\nRenseigner le compte admin et le mot de passe par défaut : admin/admin. Un nouveau mot de passe est demandé\nL'installation de Redmine est terminée\n","date":"2021-10-18T12:24:49+02:00","image":"/redmine-installation/cover.png","permalink":"/redmine-installation/","title":"Redmine : Installation"},{"content":"Contexte de l\u0026rsquo;environnement 1 Serveur sous Debian 10 où sera installé la solution Ansible 1 Serveur sous Debian 10 qui sera un routeur pour le LAN 11 1 Serveur sous Ubuntu Server 20.04 qui sera un routeur pour le LAN 12 1 Serveur sous CentOS 7 qui sera un routeur pour le LAN 13 Objectif L’objectif de ce document est d’obtenir l’environnement ci-dessous après le déploiement automatisé à l’aide de la solution Ansible. Pré-requis Tous les serveurs sont installés avec leur distribution respective. La configuration IP de SRV-ANSIBLE est effectuée sur la carte réseau ens32 avec pour IP 10.0.0.11/16. La configuration IP de RNAT-11 est effectuée sur la carte réseau ens32 avec pour IP 10.0.0.11/16. Une seconde carte réseau ens34 est également présente sans aucun paramétrage. La configuration IP de RNAT-12 est effectuée sur la carte réseau ens32 avec pour IP 10.0.0.12/16. Une seconde carte réseau ens35 est également présente sans aucun paramétrage. La configuration IP de RNAT-13 est effectuée sur la carte réseau ens33 avec pour IP 10.0.0.13/16. Une seconde carte réseau ens32 est également présente sans aucun paramétrage. Un serveur SSH est opérationnel sur chaque RNAT. Le compte root est activé sur RNAT-12 (Ubuntu) : sudo passwd root Installation d\u0026rsquo;Ansible L’installation d’Ansible se fait sur SRV-ANSIBLE. Ansible est présent nativement dans les dépôts de Debian 10. L’installation peut donc se faire à l’aide d’apt : sudo apt-get install ansible A ce jour, la version 2.7.7 d’Ansible est installée ainsi que Python version 3.7.3.\nModification du fichier /etc/hosts Pour des questions de praticité, le fichier /etc/hosts de SRV-ANSIBLE est modifié afin de travailler avec des noms d’hôtes plutôt que les adresses IP des différents RNAT. Création d\u0026rsquo;un utilisateur ansible Pour éviter d’exécuter le déploiement en tant que root sur SRV-ANSIBLE, un utilisateur ansible est crée : sudo useradd -d /home/ansible -m -s /bin/bash ansible sudo passwd ansible L’ensemble des commandes exécutées par la suite sur SRV-ANSIBLE sont faites avec cet utilisateur ansible. L’ensemble des fichiers de configurations de la solution Ansible seront stockés dans la home directory de cet utilisateur ansible.\nsu - ansible Création de l\u0026rsquo;inventaire Un fichier inventory est créé afin de répertorier les RNAT sur lequel le playbook sera joué. La variable ansible_user définit quel utilisateur est utilisé pour la connexion ssh aux RNAT. Pour éviter que ce fichier d'inventaire soit lu par d'autres utilisateurs du système, ses droits sont modifiés : chmod 0600 inventory Génération et copie des clefs SSH Afin d'éviter de saisir les mots de passe SSH sur les RNAT lors de l'exécution du playbook, une clef SSH est générée sur SRV-ANSIBLE : ssh-keygen La clef peut être laissée à son emplacement par défaut. Aucune passphrase ne sera définie. Pour copier la clef SSH publique sur les 3 RNAT, il est nécessaire d'autoriser root à se connecter en SSH par mot de passe. Décommenter et modifier l'option PermitRootLogin dans le fichier /etc/ssh/sshd_config des 3 RNAT pour avoir PermitRootLogin yes. Relancer le service sshd.service après la modification sur les 3 RNAT : sudo systemctl restart sshd.service La clef SSH publique peut être copiée sur les 3 RNAT. A partir de SRV-ANSIBLE : ssh-copy-id root@rnat-11 \u0026amp;\u0026amp; ssh-copy-id root@rnat-12 \u0026amp;\u0026amp; ssh-copy-id root@rnat-13 Une fois la clef publique SSH de SRV-ANSIBLE copiée sur les 3 RNAT, autoriser la connexion SSH en tant que root sur les 3 RNAT uniquement par clef SSH. Modifier l'option PermitRootLogin dans le fichier /etc/ssh/sshd_config des 3 RNAT pour avoir PermitRootLogin prohibit-password. Relancer le service sshd.service après la modification sur les 3 RNAT : sudo systemctl restart sshd.service Vérifier que la connexion SSH de SRV-ANSIBLE vers les RNAT fonctionne correctement sans demande de mot de passe : ssh root@rnat-11 ssh root@rnat-12 ssh root@rnat-13 Vérification de la communication entre le SRV-ANSIBLE et les 3 RNAT A partir de maintenant, toutes les commandes seront exécutées à partir de SRV-ANSIBLE.\nUne des 1ères choses à vérifier à ce stade est la bonne communication entre SRV-ANSIBLE et les 3 RNAT. Ansible regorge d'énormément de module. Dans le cas présent, l'utilisation du module ping est parfaitement indiqué : ansible -i inventory -m ping routeurs -i \u0026lt;le fichier d'inventaire\u0026gt;\n-m \u0026lt;le module à utiliser\u0026gt;\nLe dernier argument routeurs correspond au type de serveur, définit dans l’inventaire, sur lequel exécuter le module.\nRNAT-11 et RNAT-13 répondent correctement. RNAT-12 est en erreur. Cela est dû au fait que le serveur Ansible requiert d'avoir Python version 2.7 qui n'est pas installé par défaut sur le serveur Ubuntu.\nA partir de RNAT-12 : sudo apt-get install python On remarque qu'en spécifiant uniquement le paquet python, c'est python2.7 qui est installé.\nUne fois cela fait, revérifier la bonne communication entre SRV-ANSIBLE et les 3 RNAT : ansible -i inventory -m ping routeurs Création de l\u0026rsquo;arborescence où seront stockée les configurations des RNAT La configuration IP des RNAT va être stockée sur SRV-ANSIBLE dans un dossier ~/conf_routeurs et chaque RNAT aura son dossier. Ces dossiers sont à protéger des autres utilisateurs du système : mkdir -p conf_routeurs/{rnat-11,rnat-12,rnat-13} \u0026amp;\u0026amp; chmod -R 0700 conf_routeurs/ Création des fichiers de configuration pour RNAT-11 RNAT-11 étant sous Debian 10, la configuration IP est stockée dans le fichier /etc/network/interfaces et le routage dans le fichier /etc/sysctl.conf.\nCréation du fichier de configuration IP pour RNAT-11 :\nvi conf_routeurs/rnat-11/interfaces # Interface loopback auto lo iface lo inet loopback # Interface LAN 10.0.0.0 /16 auto ens32 iface ens32 inet static address 10.0.0.11 netmask 255.255.0.0 gateway 10.0.0.254 # Interface LAN 192.168.11.0 /24 auto ens34 iface ens34 inet static address 192.168.11.254 netmask 255.255.255.0 Création du fichier permettant le routage IPv4 pour RNAT-11 : vi conf_routeurs/rnat-11/sysctl.conf # Activation du routage IPv4 net.ipv4.ip_forward=1 Création des fichiers de configuration pour RNAT-12 RNAT-12 étant sous Ubuntu Server 20.04, la configuration IP est stockée dans le dossier /etc/netplan/ avec un fichier yaml pour chaque interface et le routage dans le fichier /etc/sysctl.conf.\nCréation des fichiers de configuration IP pour RNAT-12 :\nvi conf_routeurs/rnat-12/00-lan_10.0.0.0.yaml # Configuration IP pour le LAN 10.0.0.0 /16 network: ethernets: ens32: dhcp4: false addresses: [10.0.0.12/16] gateway4: 10.0.0.254 nameservers: addresses: [192.168.1.1] version: 2 vi conf_routeurs/rnat-12/01-lan_192.168.12.0.yaml # Configuration IP pour le LAN 192.168.12.0 /24 network: ethernets: ens35: dhcp4: false addresses: [192.168.12.254/24] version: 2 Création du fichier permettant le routage IPv4 pour RNAT-12 : vi conf_routeurs/rnat-12/sysctl.conf # Activation du routage IPv4 net.ipv4.ip_forward=1 Création des fichiers de configuration pour RNAT-13 RNAT-13 étant sous CentOS 7, la configuration IP est stockée dans le dossier /etc/sysconfig/network-scripts/ avec un fichier de type ifcfg-ensXX pour chaque interface et le routage dans le fichier /etc/sysctl.conf.\nCréation des fichiers de configuration IP pour RNAT-13 :\nvi conf_routeurs/rnat-13/ifcfg-ens33 # Interface LAN 10.0.0.0 /16 DEVICE=ens33 BOOTPROTO=none ONBOOT=yes PREFIX=16 IPADDR=10.0.0.13 NETMASK=255.255.0.0 GATEWAY=10.0.0.254 DNS1=192.168.1.1 vi conf_routeurs/rnat-13/ifcfg-ens32 # Interface LAN 192.168.13.0 /24 DEVICE=ens32 BOOTPROTO=none ONBOOT=yes PREFIX=24 IPADDR=192.168.13.254 NETMASK=255.255.255.0 Création du fichier permettant le routage IPv4 pour RNAT-13 : vi conf_routeurs/rnat-13/sysctl.conf # Activation du routage IPv4 net.ipv4.ip_forward=1 Création du playbook pour l’installation des RNAT Les modules copy, shell, service, apt, et yum vont être utilisés dans le playbook. Au lancement du playbook, un Gathering Facts est exécuté pour récupérer toutes les informations nécessaires concernant les RNAT. Grâce à cela, un filtrage par nom d'hôte et par type de distribution est appliqué sur chaque action du playbook.\nCréation du playbook pour l'installation et la configuration des 3 RNAT : vi install_routeurs.yml --- - hosts: routeurs tasks: - name: Copie du fichier de la configuration IP pour RNAT-11 copy: src: ~/conf_routeurs/rnat-11/interfaces dest: /etc/network/interfaces force: yes when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Activation des cartes réseaux pour RNAT-11 shell: | ip l set ens32 up ip l set ens34 up when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Redémarrage du service réseau pour RNAT-11 service: name: networking state: restarted when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Copie du fichier activant le routage IPv4 pour RNAT-11 copy: src: ~/conf_routeurs/rnat-11/sysctl.conf dest: /etc/sysctl.conf force: yes when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Activation du routage IPv4 permanent pour RNAT-11 shell: | sysctl -p when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Création du SNAT pour RNAT-11 shell: | iptables -t nat -A POSTROUTING -o ens32 -j SNAT --to 10.0.0.11 when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Mise en persistence du SNAT pour RNAT-11 apt: name: iptables-persistent state: present when: ansible_hostname == \u0026#34;rnat-11\u0026#34; and ansible_distribution == \u0026#34;Debian\u0026#34; - name: Suppression des configurations IP existantes pour RNAT-12 shell: | warn: false rm /etc/netplan/*.yaml when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Copie du fichier de la configuration IP du LAN 10.0.0.0 /16 pour RNAT-12 copy: src: ~/conf_routeurs/rnat-12/00-lan_10.0.0.0.yaml dest: /etc/netplan/00-lan_10.0.0.0.yaml force: yes when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Copie du fichier de la configuration IP du LAN 192.168.12.0 /24 pour RNAT-12 copy: src: ~/conf_routeurs/rnat-12/01-lan_192.168.12.0.yaml dest: /etc/netplan/01-lan_192.168.12.0.yaml force: yes when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Activation des cartes réseaux pour RNAT-12 shell: | ip l set ens32 up ip l set ens35 up when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Application de la configuration IP pour RNAT-12 shell: | netplan apply when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Copie du fichier activant le routage IPv4 pour RNAT-12 copy: src: ~/conf_routeurs/rnat-12/sysctl.conf dest: /etc/sysctl.conf force: yes when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Activation du routage IPv4 permanent pour RNAT-12 shell: | sysctl -p when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Création du SNAT pour RNAT-12 shell: | iptables -t nat -A POSTROUTING -o ens32 -j SNAT --to 10.0.0.12 when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Mise en persistence du SNAT pour RNAT-12 apt: name: iptables-persistent state: present when: ansible_hostname == \u0026#34;rnat-12\u0026#34; and ansible_distribution == \u0026#34;Ubuntu\u0026#34; - name: Copie du fichier de la configuration IP du LAN 10.0.0.0 /16 pour RNAT-13 copy: src: ~/conf_routeurs/rnat-13/ifcfg-ens33 dest: /etc/sysconfig/network-scripts/ifcfg-ens33 force: yes when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Copie du fichier de la configuration IP du LAN 192.168.13.0 /24 pour RNAT-13 copy: src: ~/conf_routeurs/rnat-13/ifcfg-ens32 dest: /etc/sysconfig/network-scripts/ifcfg-ens32 force: yes when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Activation des cartes réseaux pour RNAT-13 shell: | ip l set ens33 up ip l set ens32 up when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Redémarrage du service réseau pour RNAT-13 service: name: network state: restarted when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Copie du fichier activant le routage IPv4 pour RNAT-13 copy: src: ~/conf_routeurs/rnat-13/sysctl.conf dest: /etc/sysctl.conf force: yes when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Activation du routage IPv4 permanent pour RNAT-13 shell: | echo 1 \u0026gt; /proc/sys/net/ipv4/ip_forward when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Suppression de firewalld pour RNAT-13 yum: name: firewalld state: absent when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Installation des services iptables pour RNAT-13 yum: name: iptables-services state: present when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Démarrage des services iptables pour RNAT-13 service: name: iptables state: started when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Purge des règles iptables existantes pour RNAT-13 shell: | iptables -F iptables -X when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Mise en place des nouvelles règles iptables pour RNAT-13 shell: | iptables -t nat -A POSTROUTING -o ens33 -j SNAT --to 10.0.0.13 iptables -t filter -A FORWARD -i ens32 -o ens33 -j ACCEPT when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Sauvegarde des règles iptables pour RNAT-13 shell: | warn: false service iptables save when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; - name: Chargement des services iptables au démarrage pour RNAT-13 shell: | chkconfig iptables on when: ansible_hostname == \u0026#34;rnat-13\u0026#34; and ansible_distribution == \u0026#34;CentOS\u0026#34; Le playbook est format YAML ce qui signifie que l’indentation doit se faire avec des espaces et non avec des tabulations.\nExécution du playbook pour le déploiement des RNAT Le playbook d'installation des 3 RNAT est exécuté par la commande : ansible-playbook -i inventory install_routeurs.yml Un résumé des actions réalisées est affiché à la fin de l'exécution du playbook : Vérification de l’installation des 3 RNAT A l'aide d'un client sur chaque LAN, le routage est bien actif avec les bonnes règles dans iptables afin de pouvoir communiquer avec l’extérieur. ","date":"2021-10-16T09:20:29+02:00","image":"/ansible-deploiement-de-3-routeurs-linux-en-milieu-heterogene/cover.png","permalink":"/ansible-deploiement-de-3-routeurs-linux-en-milieu-heterogene/","title":"Ansible : Déploiement de 3 routeurs Linux en milieu hétérogène"},{"content":"Pré-requis Avoir suivi : Nginx : Installation d’un Reverse Proxy Avoir suivi : Nginx : Ajouter un certificat SSL Lets Encrypt pour passer en HTTPS Nginx configuration Editez le fichier de configuration du reverse proxy : sudo vim /etc/nginx/sites-available/reverse-proxy.example.conf En principe, après avoir suivi l'installation d'un reverse proxy avec Nginx, le server block suivant va être modifié : server { listen 80; server_name blog.example.com; location / { proxy_pass http://172.0.1.10:80; } } En premier lieu, nous allons réécrire l'url de http://blog.example.com en https://blog.example.conf, pour cela nous allons modifié le server block précédent en : server { listen 80; server_name blog.example.com; rewrite ^ https://blog.example.com permanent; } Ajouter un nouveau server block pour permettre de faire du reverse proxy SSL comme suit : server { listen 443 ssl; server_name blog.example.com; ssl_certificate /etc/letsencrypt/live/blog.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass https://172.0.1.10:443; proxy_read_timeout 90; } } ssl_certificate et ssl_certificate_key contiendront le chemin d'accès au certificat et à la clef privée. Bien entendu, il faudra les transféré sur le serveur reverse proxy au bon endroit avec les bonnes permissions. Générer un certificat wildcard est fortement recommandé si vous souhaitez développer plusieurs sous-domaine. Cette partie ne sera pas détaillé dans ce tutorial ainsi que la gestion de son renouvelement.\nproxy_pass : L'URL http / https vers le serveur hébergeant blog.example.com.\nVérifiez la configuration de Nginx avec : sudo nginx -t Aucune erreur ne doit être retournée : nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Redémarrer le serveur reverse proxy : sudo systemctl restart nginx ","date":"2021-10-15T15:00:06+02:00","image":"/nginx-reverse-proxy-avec-ssl/cover.png","permalink":"/nginx-reverse-proxy-avec-ssl/","title":"Nginx : Reverse Proxy avec SSL"},{"content":"Présentation Durant mes années d'administrateur systèmes Microsoft Windows (Il en faut bien), j'ai régulièrement été confronté à un souci de gestion de parc complet, simple, et efficace.\nLors de mes recherches, de nombreuses solutions se sont révélées être intéressantes (SolarWinds RMM, NinjaRMM, etc...).\nComme vous le savez, chez AukFood, on ne mange qu'OpenSource.\nDe ce fait, une solution s'est révélée pertinente : Tactical RMM (Remote Monitoring \u0026amp; Management)\nTactical RMM fournit une interface web pour la gestion de flotte d'ordinateur permettant :\nLa prise en main sur les postes (comme un TeamViewer) Obtenir une ligne de commande à distance Parcourir, télécharger, uploader des fichiers à distance Surveiller les logs Gérer les MAJ Windows, les services Mise en place d'alertes (CPU, espace disque, RAM...) Inventaire matériel et logiciels en place Déploiement d'applications via Chocolatey L'exécution de tâches en masse sur un ensemble de ressources Tactical RMM s'appuie sur Django, Vue et Golang. Il utilise MeshCentral et un agent écrit en Golang.\nLe serveur web utilisé est Nginx et la base de données MongoDB.\nCette solution est directement inspirée de l'outil commercial SolarWinds RMM (un des leaders du marché dans le RMM).\nContrairement à toutes les solutions de RMM performantes, celle-ci est sous licence MIT et est donc libre.\nActuellement, seul un agent Windows x86 et x64 sont disponibles. Un agent Linux et macOS sont en cours de développement.\nLes versions de Windows supportés sont : Windows 7, 8.1, 10, Server 2008R2, 2012R2, 2016, 2019.\nPour obtenir un agent Windows avec du code signé (Pas d'alerte antivirale), un don mensuel au projet de 50$ (statut sponsor) est nécessaire. Pas de panique, lors du déploiement d'un agent, des exclusions antivirus seront faites automatiquement. Nous y reviendrons un peu plus tard.\nInstallation 2 méthodes d'installation sont possibles :\nClassique / Traditionnelle Docker Avant de commencer Dans cette démonstration, une installation fraîche de Debian 10 est utilisée pour le serveur et la méthode d'installation classique est employée.\nUn domaine résolvable sur Internet pour la génération de certificats Let's Encrypt est nécessaire ainsi qu'une application basée sur TOTP (Microsoft Authenticator, Authy, PrivacyIDEA...)\nPour la connexion à la Web UI, il faudra vous munir d'un des navigateurs suivants :\nChrome \u0026gt;= 93 Edge \u0026gt;= 93 Firefox \u0026gt;= 92 Safari \u0026gt;= 15 Let's Go Pinguy !\nPrérequis Mise à jour système et installation des prérequis.\napt update apt install -y wget curl sudo apt -y upgrade Si un nouveau kernel a été installé, redémarrez dessus.\nCréation d\u0026rsquo;un utilisateur Créez un utilisateur \u0026quot;tactical\u0026quot; et ajoutez-le au groupe sudoers.\nuseradd -m -s /bin/bash tactical usermod -a -G sudo tactical passwd tactical Le mot de passe renseigné à ce niveau servira pour la connexion en SSH au serveur et non à la Web UI. Celui-ci sera défini un peu plus tard.\nOuverture des ports Configurez votre pare-feu :\nPort TCP 443 : Accès Web UI Port TCP 22 : Accès SSH Port TCP 4222 : Communication avec l'agent Script d\u0026rsquo;installation Il est impératif de vérifier la bonne conformité de fichier /etc/hosts en premier lieu. Si le nom du serveur n'est pas correct, des erreurs d'installation se produiront.\nBasculez sur l'utilisateur tactical.\nsu - tactical Téléchargez et exécutez le script d'installation.\nwget https://raw.githubusercontent.com/wh1te909/tacticalrmm/master/install.sh chmod +x install.sh ./install.sh Répondez aux questions en remplaçant example.com par votre domaine ainsi qu'une adresse de messagerie valide.\nEnregistrement TXT Un challenge DNS est demandé afin de permettre la génération d'un certificat wildcard Let's Encrypt. Ce challenge DNS est demandé lors de la phase d'installation.\nUne fois la propagation de l'entrée DNS effectuée, vérifiez celle-ci.\ndig -t txt _acme-challenge.example.com L'enregistrement DNS TXT doit impérativement retourner la bonne valeur sous peine d'un échec de la génération du certificat wildcard.\nCréation accès Web UI Un couple login/password est à renseigner pour l'accès web durant le processus d'installation : https://rmm.example.com\nUn résumé de toutes les informations de connexions sera affiché à la fin du processus d'installation.\nMFA et Authenticator Par défaut du MFA est mis en place avec une authentification par QR Code après la validation du couple login/password. Ce QR code est généré durant l'installation.\nNous vous recommandons l'utilisation d'une application mobile OpenSource comme PrivacyIDEA ou Authy.\nRécupération de l\u0026rsquo;agent Récupérez l'agent via https://mesh.example.com:443/agentinvite?c=abcdef.\nCe lien sera affiché dans le résumé affiché à la fin de l'installation.\nConfiguration initiale Rendez-vous sur https://rmm.example.com.\nCréez le premier client/site. Définissez le fuseau horaire. Uploadez l'agent RMM préalablement récupéré. L'installation est terminée.\nFonctionnalités (aperçus) Voici quelques captures des fonctionnalités disponibles (non exhaustives).\nSummary Checks Tasks Patches Software History Scripting Bulk Conclusion Tactical RMM est une solution robuste et en constante évolution. Les gestionnaires du projet ainsi que les contributeurs sont très réactifs et à l'écoute.\nC'est une solution alternative parfaitement viable face aux concurrents propriétaires.\nDans un prochain article, je vous décrirai les différentes méthodes de déploiements de l'agent (manuellement, automatiquement, par GPO...), approfondissement les différentes fonctionnalités, les commandes de management spécifiques, comment réaliser une mise à jour de Tactical RMM, la sauvegarde, la restauration, etc...\nSource Projet : GitHub - wh1te909/tacticalrmm: A remote monitoring \u0026amp; management tool, built with Django, Vue and Go.\n","date":"2021-10-15T14:48:51+02:00","image":"/tactical-rmm-presentation-et-installation/cover.png","permalink":"/tactical-rmm-presentation-et-installation/","title":"Tactical RMM : Présentation et installation"},{"content":"Installation de Certbot pour Nginx Installez les deux paquets nécessaires à l'utilisation de Certbot sous Debian avec un serveur Nginx : sudo apt install certbot python3-certbot-nginx Let\u0026rsquo;s Encrypt : Demander un certificat SSL pour Nginx Effectuez une demande de certificat : sudo certbot --nginx -d www.example.com --nginx : Pour spécifier que l'on utilise un serveur web sous Nginx\n-d www.example.com : Pour préciser le nom de domaine\nVotre adresse e-mail vous sera demandé. Un e-mail vous sera envoyé dans le cas où le certificat ne parvient pas à se renouveler automatiquement avant expiration. Il vous sera demandé si vous souhaitez rediriger automatiquement le traffic HTTP vers HTTPS : Si tout se passe bien, un message de congratulations doit apparaitre : Il a noté que dans le message final, les emplacements du certificat, clef privée, etc... sont également indiquées.\nCertbot c'est occupé de configurer automatiquement le bloc server correspondant. Vous pouvez aller voir les modifications apportées par Certbot dans le fichier de configuration de votre site. Les ajouts / modifications apportés par Certbot seront commentés en fin de ligne par # managed by Certbot\nRenouvellement automatique du certificat SSL Un certificat Let's Encrypt a une durée de validité de 90 jours. Certbot va s'occuper tout seul du renouvellement de celui-ci. Une tâche cron a été créée automatiquement par Certbot. Pour se rassurer : sudo vim /etc/cron.d/certbot La tâche planifiée va s'exécuter de façon à renouveler le certificat avant qu'il expire. Il est possible de faire une simulation de renouvellement du certificat : sudo certbot renew --dry-run --dry-run : Permet de faire une simulation\nLe message \u0026quot;Congratulations, all renewals succeded.\u0026quot; doit apparaitre si la simulation du renouvellement du certificat est un succès. La tâche planifiée va s'occuper de gérer cette opération à notre place. En cas de soucis, un e-mail sera envoyé à l'adresse indiqué lors de la demande de certificat. ","date":"2021-10-15T14:05:01+02:00","image":"/nginx-ajouter-un-certificat-ssl-lets-encrypt-pour-passer-en-https/cover.png","permalink":"/nginx-ajouter-un-certificat-ssl-lets-encrypt-pour-passer-en-https/","title":"Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS"},{"content":"Préambule Un des outils reverse proxy le + populaires du moment est Nginx\nUn reverse proxy est un serveur positionné entre les applications web internes et les utilisateurs extérieurs. Le reverse proxy aiguille les requêtes des utilisateurs vers le serveur approprié.\nLe service reverse proxy agis comme un front-end qui traite toutes les requetes clientes entrantes et les distribue vers le back-end, bdd, ou autres serveurs. Puis il redirige les réponses en retour vers le client.\nNginx en tant que reverse proxy permet :\nLoad balancing Améliore la sécurité Meilleur performance Point de terminaison SSL Installation d\u0026rsquo;un reverse proxy avec Nginx Une Debian 10 sera utilisée avec 4GB de RAM, 2 vCPU, 20GB de disque Installer Nginx Installer Nginx :\nsudo apt install nginx Après l'installation, vous pouvez vérifier que Nginx c'est correctement installé en vérifiant la version :\nnginx -v Configurer Nginx Nous allons considérer que le site principal example.com est sur le même serveur que notre Nginx. Un site WordPress est disponible sur un sous domaine blog.example.com hébergé sur un serveur différent ayant l'adresse IP 172.0.1.10\nNous devons configurer un reverse proxy avec Nginx pour rediriger les requêtes à destination de blog.example.com vers le serveur 172.0.1.10\nDésactivez le vhost pré-configuré par défaut :\nunlink /etc/nginx/sites-enabled/default Rendez-vous dans le répertoire /etc/nginx/sites-available et créez le fichier de configuration du reverse proxy :\ncd /etc/nginx/sites-available sudo vim example.conf Collez cette configuration Nginx :\nserver { listen 80; server_name example.com www.example.com; location / { try_files $uri $uri/ /index.php?$query_string; } } server { listen 80; server_name blog.example.com; location / { proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://172.0.1.10:80; } } Dans cet exemple, le site example.com et www.example.com reste accessible sur la même instance Nginx. Par contre, Nginx redirige toutes les connexions entrantes pour blog.example.com sur le port 80 vers le serveur 127.0.1.10 écoutant sur le port 80\nSauvegardez le fichier et activez le en créant un lien symbolique :\nsudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/ Testez Nginx pour d'éventuelles erreurs de configuration :\nsudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Si aucune erreur, redémarrez Nginx pour prendre en compte les modifications :\nsudo systemctl restart nginx C'est terminé !\n","date":"2021-10-15T13:50:26+02:00","image":"/nginx-installation-dun-reverse-proxy/cover.png","permalink":"/nginx-installation-dun-reverse-proxy/","title":"Nginx : Installation d’un Reverse Proxy"}]