Posts on slash-root.fr

OPNsense : Serveur WireGuard et client KDE en split tunnel

Wed, 22 Jul 2026 00:00:00 +0000

L’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.

Depuis OPNsense 24.1, WireGuard est intégré au core. Plus besoin de jouer avec le plugin os-wireguard, c’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.

Voici le plan utilisé dans cet article :

LAN 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’IPv4. L’IPv6 n’est pas abordé ici.

Let’s go !!!

Pré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’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’instance

On commence par générer le serveur :

Aller dans VPN > WireGuard > 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'instant
Disable Routes : Décoché

Le MTU de 1420 tient compte de l’overhead d’encapsulation WireGuard (en-têtes IP/UDP/WireGuard, soit environ 60 à 80 octets). Ainsi, le paquet final reste sous les 1500 octets d’un lien Ethernet standard. En PPPoE, le MTU physique est souvent 1492, d’où la valeur 1412.

Note : si on active le mode avancé, laissez le champ DNS Server vide. Sinon WireGuard écrase la config DNS d’OPNsense et c’est la galère.

Sauvegarder, rouvrir l’instance et copier la clé publique générée. Elle servira à configurer le client KDE.

Cré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.

Aller dans VPN > WireGuard > Peers.
Cliquer sur +.

Enabled : Coché
Name : MonPC_KDE
Public Key : <clé publique du client KDE>
Allowed IPs : 10.10.10.2/32
Keepalive : 25

Le Keepalive à 25 secondes, c’est utile quand le client est derrière un NAT ou un pare-feu qui ferme les states trop vite.

Sauvegarder, puis retourner dans VPN > WireGuard > Instances, éditer HomeWireGuard et sélectionner le peer MonPC_KDE. Apply.

Mé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 > WireGuard > Peer generator.

Sélectionner l’instance HomeWireGuard.
Remplir les champs :

Name : MonPC_KDE
Endpoint Address: <ip_publique_ou_domaine_opnsense>
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'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’importer dans NetworkManager. Sinon tout le trafic partira dans le tunnel.

Cliquer sur Store and generate next pour valider le peer dans OPNsense, puis Apply dans VPN > WireGuard > Peers.
La clé privée n’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’est nettement plus rapide quand il y a plusieurs road warriors à déployer.

Activation de WireGuard

VPN > WireGuard > General.
Cocher Enable, puis Apply.
Si besoin, redémarrer WireGuard en le décochant/re-cochant.

Assigner une interface (recommandé)

Ce n’est pas strictement obligatoire pour un split tunnel, mais ça simplifie les règles firewall et ça crée l’alias HomeWireGuard net.

Interfaces > Assignments.
Sélectionner le device wg1 (ou wg0 selon l’installation) et l’ajouter.
Description : HomeWireGuard.
Éditer l’interface :

Enable : Coché
Description : HomeWireGuard
IPv4 Configuration Type : None
IPv6 Configuration Type : None

Save puis Apply changes. Redémarrer WireGuard si l’interface ne remonte pas proprement.

Règles firewall

1. Autoriser les connexions entrantes sur le WAN

Firewall > Rules > 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 > Rules > HomeWireGuard (ou WireGuard si vous n’avez pas assigné d’interface).
Ajouter une règle :

Action : Pass
Quick : Coché
Interface : HomeWireGuard
Protocol : any
Source : HomeWireGuard net
Destination : LAN net

C’est cette règle qui autorise le client KDE à joindre les machines du LAN.

Normalisation MSS (optionnel mais fortement recommandé)

Le MSS (Maximum Segment Size) est la taille maximale de la charge utile d’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’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’IPv6 n’est pas traité ici.

Firewall > Settings > Normalization.
Ajouter une règle sur l’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’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.

Partie 2 : KDE, le client WireGuard

Génération des clés

Sur le poste KDE :

wg genkey | tee private.key | wg pubkey > public.key

public.key : à copier dans le peer OPNsense (étape “Création du peer client”).
private.key : reste sur le client, ne jamais la balancer sur un chat.

Fichier de configuration `wg0.conf`

Créer /etc/wireguard/wg0.conf :

[Interface]
PrivateKey = <contenu de private.key>
Address = 10.10.10.2/32
# DNS optionnel, par exemple si vous voulez utiliser le DNS d'OPNsense
# DNS = 10.10.10.1

[Peer]
PublicKey = <clé publique d'OPNsense>
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24
Endpoint = <ip_publique_ou_domaine_opnsense>: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’interface classique.

Import dans NetworkManager

En ligne de commande (plus fiable)

sudo nmcli connection import type wireguard file /etc/wireguard/wg0.conf

Puis on s’assure que NetworkManager ne met pas cette connexion en passerelle par défaut :

sudo nmcli connection modify wg0 ipv4.never-default yes

En graphique (KDE Plasma)

Ouvrir Paramètres système > Connexions.
Ajouter une connexion > WireGuard.
Onglet WireGuard :
- Private key : coller la clé privée.
- Peers : ajouter le peer avec la clé publique d’OPNsense, l’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’option WireGuard n’apparaît pas dans l’interface graphique, vérifier que wireguard-tools est bien installé et que NetworkManager est assez récent.

Vérifications

Sur le client KDE, une fois connecté :

ip route show

On doit voir quelque chose comme :

default 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’important : la route default pointe toujours vers l’interface locale. Les routes 10.10.10.0/24 et 192.168.1.0/24 pointent vers wg0.

Tests basiques :

ping 10.10.10.1
ping 192.168.1.x

Vérifier que l’IP publique vue depuis le navigateur n’a pas changé (le trafic internet ne passe pas par le VPN) :

curl -4 ifconfig.me

Côté OPNsense, on peut surveiller l’état dans VPN > WireGuard > Status. On doit voir le peer MonPC_KDE avec un handshake récent et du trafic RX/TX.

Conclusion

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’ajouter le NAT outbound sur OPNsense. Mais ce n’est pas le sujet d’aujourd’hui.

KDE : double-clic sur un ISO pour le monter

Tue, 23 Jun 2026 00:00:00 +0000

Sous KDE, double-cliquer sur un .iso ouvre Ark. C’est le comportement par défaut, et c’est chiant quand on veut juste monter l’image pour parcourir son contenu.

Le problème vient de l’association MIME. On peut le confirmer :

xdg-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.

La solution

L’idée, c’est de créer un .desktop qui monte l’ISO via udisksctl et ouvre Dolphin sur le point de montage, puis de l’enregistrer comme handler MIME. Avec NoDisplay=true, il ne remonte pas dans le menu des applications, il n’existe que pour ça.

Créer : ~/.local/share/applications/iso-mount.desktop

[Desktop Entry]
Type=Application
Name=Monter l'image ISO
Exec=bash -c 'DEV=$(udisksctl loop-setup -f "%f" | grep -oP "/dev/loop\d+"); sleep 0.5; udisksctl mount -b "$DEV"; dolphin /run/media/$USER/'
Icon=media-optical
MimeType=application/x-iso9660-image;application/x-cd-image;
NoDisplay=true
Terminal=false

Ensuite on enregistre l’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’est un bug connu, ça n’empêche pas l’association d’être écrite correctement dans ~/.config/mimeapps.list.

On 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’image et ouvre le répertoire directement. Pour démonter, clic droit sur le périphérique dans le panneau latéral → Démonter.

Aptly : mirroiter Debian proprement

Fri, 13 Mar 2026 19:05:06 +0100

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 ?

La 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.

C'est là qu'aptly entre en jeu.

Ce qu’aptly fait vraiment

aptly, c'est un gestionnaire de dépôts Debian écrit en Go. Il sait faire trois choses fondamentales :

mirrorer 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 :

mirror create → mirror update → snapshot create → publish snapshot

Et quand il faut mettre à jour :

mirror 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.

Installation

Via les paquets Debian

C'est la méthode standard, celle qu'on va utiliser ici :

sudo 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.

Vérification :

$ aptly version
aptly version: 1.5.0

L’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 :

sudo mkdir -p /etc/apt/keyrings
wget -O /etc/apt/keyrings/aptly.asc https://www.aptly.info/pubkey.txt

echo "deb [signed-by=/etc/apt/keyrings/aptly.asc] http://repo.aptly.info/release trixie main" \
 | 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.

Configuration 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 :

sudo 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 :

cat > ~/.aptly.conf << 'EOF'
{
 "rootDir": "/var/aptly",
 "architectures": ["amd64"]
}
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.

Le rootDir, c'est la racine de tout. Dedans, aptly va créer :

db/ -- 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 :

gpg --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.

Cré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.

aptly mirror create \
 -architectures=amd64 \
 debian-trixie \
 http://ftp.fr.debian.org/debian/ \
 trixie main non-free-firmware

Quelques remarques :

Le 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.

Remplir 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é.

Vous pouvez suivre la progression dans le terminal. aptly affiche les paquets au fur et à mesure qu'il les télécharge.

Une fois terminé, vous pouvez voir ce que contient le miroir :

aptly mirror show debian-trixie

Ça vous donne le nombre de paquets, la taille totale, la date de dernière mise à jour, etc.

Cré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.

aptly 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.

Vous pouvez lister vos snapshots :

aptly snapshot list

Et voir le détail d'un snapshot :

aptly 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/.

aptly 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.

aptly 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 :

gpg --full-generate-key

Choisissez RSA 4096 bits, et renseignez un nom et un email.

Une 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.

L’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/.

Ça veut dire quoi concrètement ?

Pas 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.

Par 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).

Mettre à 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 :

# 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 :

Il 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.

Si le nouveau snapshot pose problème, vous rebasculez sur l'ancien :

aptly publish switch trixie trixie-20260313

C'est aussi rapide dans un sens que dans l'autre.

Les 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 :

# 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.

Exposer 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.

aptly serve -listen=:8080

Vous pouvez alors ajouter le dépôt sur une machine de test :

echo "deb http://votre-serveur:8080/ trixie main non-free-firmware" \
 | 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 :

server {
 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.

Côté client, vous ajoutez le dépôt :

echo "deb http://repo.example.com/ trixie main non-free-firmware" \
 | 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 :

gpg --armor --export VOTRE_KEY_ID > /var/aptly/public/repo-key.asc

Sur les clients :

wget -O /etc/apt/keyrings/mon-repo.asc http://repo.example.com/repo-key.asc

echo "deb [signed-by=/etc/apt/keyrings/mon-repo.asc] http://repo.example.com/ trixie main non-free-firmware" \
 | 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 :

#!/bin/bash
# /etc/cron.daily/aptly-update

set -euo pipefail

MIRROR="debian-trixie"
DATE=$(date +%Y%m%d)

# Mise à jour du miroir
aptly mirror update "$MIRROR"

# Nouveau snapshot
aptly snapshot create "trixie-${DATE}" from mirror "$MIRROR"

# Basculer la publication
aptly publish switch -batch -gpg-key="VOTRE_KEY_ID" trixie "trixie-${DATE}"

# Nettoyer les vieux snapshots (garder les 7 derniers)
aptly snapshot list -raw | grep "^trixie-" | sort | head -n -7 | while read snap; do
 aptly snapshot drop "$snap" 2>/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.

Pour é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.

Nettoyage 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 :

aptly db cleanup

Ça supprime les paquets orphelins. Si vous voulez voir ce qui va être supprimé avant de le faire :

aptly db cleanup -verbose -dry-run

Pour sauvegarder votre installation aptly, c'est simple : sauvegardez /var/aptly en entier. Tout est dedans.

tar -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 :

aptly mirror create -filter='nginx' -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.

Comparer deux snapshots. Pour voir ce qui a changé entre deux snapshots :

aptly 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 :

aptly 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.

Le 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.

Les 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.

Bref, si vous gérez des serveurs Debian sérieusement, aptly mérite sa place dans votre boîte à outils.

awaSCII+ Web : Quand l’encodage devient un art de vivre

Sun, 28 Sep 2025 03:55:27 +0200

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 "Hello World!" avec classe.

 awa 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 "awa"

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 "awa" et "wa". 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.

Comment ça marche ?

L'algorithme est d'une beauté simple :

Caractère → Index dans une table de 97 caractères
Index → Binaire 8 bits
0 devient " awa ", 1 devient "wa"
Magie : espaces → 💩, tabs → 💨, retours à la ligne → 🍆

Le projet est toujours en développement à l'heure actuelle.

Pourquoi 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 "Écouter" avec l'API Web Speech Synthesis.

Features qui claquent

100% compatible avec les scripts Bash originaux
Design terminal rétro qui fait plaisir aux yeux
Raccourci "Ctrl+Entrée" 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 "awa awa awawawawa" 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.

Alors la prochaine fois que vous voulez envoyer un message secret ou juste faire le malin, pensez awaSCII+ !

Liens utiles :

Interface 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.

Zoxide : Une alternative intelligente à la commande cd

Sun, 21 Sep 2025 00:00:10 +0200

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.

Zoxide 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 "sauter" vers eux en quelques frappes seulement.

Qu’est-ce que zoxide ?

Zoxide est un utilitaire de navigation rapide qui :

Apprend 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 :

sudo apt update
sudo apt install zoxide

Méthodes alternatives d’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 :

Via le script d’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.

Via 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 :

sudo 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.

Note : La commande zoxide init génère la configuration à ajouter à votre profil shell.

Configuration pour Bash

Ajoutez cette ligne à la fin de votre fichier ~/.bashrc :

eval "$(zoxide init bash)"

Configuration pour Zsh

Ajoutez cette ligne à la fin de votre fichier ~/.zshrc :

eval "$(zoxide init zsh)"

Configuration pour Fish

Ajoutez cette ligne à la fin de votre fichier ~/.config/fish/config.fish :

zoxide init fish | source

Rechargement de la configuration

Après avoir modifié votre fichier de configuration, rechargez-le suivant le shell utilisé :

source ~/.bashrc
source ~/.zshrc
source ~/.config/fish/config.fish

Utilisation de base

Une fois configuré, zoxide vous donne accès à plusieurs commandes puissantes :

La 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.

Autocomplétion

Sur les shells compatibles (Bash 4.4+, Fish, Zsh), vous pouvez utiliser l'autocomplétion :

z foo<SPACE><TAB>

Bonus : Alias `cd='z'`

Pour une intégration encore plus transparente, vous pouvez créer un alias qui remplace complètement cd par z :

Méthode recommandée : Configuration automatique via zoxide init

La meilleure approche est d'utiliser l'option --cmd cd lors de l'initialisation :

eval "$(zoxide init bash --cmd cd)"
eval "$(zoxide init zsh --cmd cd)"

Avec cette configuration, la commande cd sera automatiquement remplacée par z, tout en conservant la compatibilité avec l'utilisation classique de cd.

Alternative : Alias manuel

Si vous préférez ne pas modifier votre configuration zoxide init existante, vous pouvez simplement ajouter un alias :

alias cd='z'

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.

Options de configuration avancées

Personnalisation du préfixe des commandes

eval "$(zoxide init bash --cmd j)"
eval "$(zoxide init bash --cmd cd)"

Contrôle de la fréquence d’enregistrement

eval "$(zoxide init bash --hook pwd)"
eval "$(zoxide init bash --hook prompt)"
eval "$(zoxide init bash --hook none)"

Exemples pratiques d’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 "$line" | awk '{print $2}')
 [ ! -d "$path" ] && zoxide remove "$path"
done

Avantages par rapport aux alternatives

Comparaison avec `autojump`

Source : https://github.com/wting/autojump

Performance : 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

Algorithme : 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 :

# Fonction pour ouvrir un projet avec Neovim
function nvim-project() {
 local dir=$(zoxide query "$1")
 if [ -n "$dir" ]; then
 cd "$dir" && nvim .
 else
 echo "Projet non trouvé : $1"
 fi
}

# Fonction pour ouvrir un projet avec VS Code
function code-project() {
 local dir=$(zoxide query "$1")
 if [ -n "$dir" ]; then
 code "$dir"
 else
 echo "Projet non trouvé : $1"
 fi
}

Docker : Metrics port 9323

Sun, 15 Jun 2025 18:55:14 +0200

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.

Comprendre l’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.

Pourquoi 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 :

Mé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.

ℹ️ Point technique : Le format Prometheus utilise des "labels" qui permettent de filtrer et d'agréger les métriques de manière flexible.

Cas d’utilisation pour metrics-addr

L'activation de metrics-addr est particulièrement utile dans les scénarios suivants :

Supervision 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 :

Éditez le fichier de configuration Docker :
```
sudo vi /etc/docker/daemon.json
```
Ajoutez la configuration pour activer l'API de métriques :
```
{
 "metrics-addr" : "127.0.0.1:9323",
 "experimental" : 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).
Redémarrez Docker pour appliquer les changements :
```
sudo systemctl restart docker
```
Vérifiez que les métriques sont disponibles :
```
curl http://localhost:9323/metrics
```
Vous devriez voir une sortie avec de nombreuses métriques au format Prometheus.

Visualisation simple avec Docker Stats

Pour un aperçu rapide des performances de vos conteneurs sans configuration supplémentaire :

docker stats

Cela affiche en temps réel les statistiques d'utilisation des ressources pour tous les conteneurs :

CPU% : 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 :

docker stats container1 container2

Note: Pour des solutions plus avancées comme Prometheus+Grafana ou cAdvisor, voir la section "Solutions avancées" en fin d'article.

Les limites à connaître

Limites des métriques natives :
- Pas de persistance des données historiques
- Interface de visualisation minimale
- Absence d'alertes automatiques
Considérations de performance :
- L'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 :
- Les 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
- Identifiez les métriques critiques pour votre cas d'usage
- Augmentez progressivement la complexité
Automatisez les alertes
- Configurez des alertes sur les seuils critiques
- Évitez les alertes trop sensibles qui causeraient de la fatigue d'alarme
Corrélation de métriques
- Combinez 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
- Dé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.

💡 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.

Solutions 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 :

# prometheus.yml
scrape_configs:
 - job_name: 'docker'
 static_configs:
 - targets: ['127.0.0.1:9323']

2. Utilisation de cAdvisor

Pour une solution prête à l'emploi avec interface web :

docker 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

Docker : live-restore, c’est quoi ?

Sun, 15 Jun 2025 18:06:04 +0200

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.

Le problème : Sans live-restore

Par défaut, quand vous exécutez systemctl restart docker :

Tous 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 !

La solution : Comment fonctionne live-restore ?

Quand vous activez live-restore, Docker modifie son comportement :

Dé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.

Quand utiliser live-restore ?

Cette fonctionnalité est particulièrement utile pour :

Mises à 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’activer ?

Éditez le fichier de configuration Docker :
```
sudo vi /etc/docker/daemon.json
```
Ajoutez ou modifiez la configuration :
```
{
 "live-restore": true
}
```
Redémarrez Docker :
```
sudo systemctl restart docker
```
Vérifiez l'activation :
```
docker info | grep -i live
```
Vous devriez voir : Live Restore Enabled: true

Les limites à connaître

Pas de protection contre :
- Les 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 :
- La CLI Docker est indisponible
- Pas de création/suppression de conteneurs
- Gestion réseau et stockage limitée
Compatibilité :
- Certains 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.

💡 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.

Docker : Configuration et gestion des logs

Sun, 15 Jun 2025 17:33:44 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans l'univers des logs Docker. Comme on dit dans notre jargon : "Sans logs, c'est comme chercher une erreur dans un datacenter éteint - théoriquement possible, mais pas vraiment efficace."

Comprendre 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]/.

Le 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.

Configuration 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 :

{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3"
 }
}

Note : Cette configuration limite la taille de chaque fichier de log à 10 Mo et permet une rotation sur 3 fichiers maximum.

Après cette modification, un petit redémarrage s'impose :

sudo 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 :

json-file : Le pilote par défaut
- Stocke 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é
- Format 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é

Envoie les logs au service syslog de l'hôte

Configuration type avec rotation via logrotate :

# Dans /etc/docker/daemon.json
{
"log-driver": "syslog",
"log-opts": {
 "syslog-address": "udp://192.168.1.100:514",
 "tag": "{{.ImageName}}/{{.Name}}/{{.ID}}",
 "syslog-facility": "local7"
}
}

Configuration équivalente dans docker-compose :

services:
app:
 image: nginx
 logging:
 driver: syslog
 options:
 syslog-address: "udp://192.168.1.100:514"
 tag: "{{.ImageName}}/{{.Name}}/{{.ID}}"

Petit prix à payer : docker logs ne fonctionne plus directement

journald : L'ami des systèmes modernes

Parfait pour les systèmes basés sur systemd

Exemple de configuration :

# Activer journald dans /etc/docker/daemon.json
{
"log-driver": "journald",
"log-opts": {
 "tag": "{{.ImageName}}/{{.Name}}/{{.ID}}",
 "labels": "app_name,environment"
}
}

Pour consulter les logs :

# Voir les logs d'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

Splunk :

docker run --log-driver=splunk \
 --log-opt splunk-token=YOUR_TOKEN \
 --log-opt splunk-url=https://your-splunk:8088 \
 --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}" \
 nginx

AWS CloudWatch Logs :

docker 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 :

# docker-compose.yml
version: '3'
services:
 app:
 image: nginx
 logging:
 driver: "fluentd"
 options:
 fluentd-address: localhost:24224
 tag: docker.{{.Name}}

 fluentd:
 image: fluent/fluentd
 volumes:
 - ./fluentd/conf:/fluentd/etc
 ports:
 - "24224:24224"

GELF (Graylog Extended Log Format) :

docker run --log-driver=gelf \
 --log-opt gelf-address=udp://graylog:12201 \
 --log-opt tag="{{.ImageName}}/{{.Name}}" \
 nginx

Ces solutions sont idéales pour les environnements de production à grande échelle nécessitant une analyse avancée des logs.

Configuration 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 :

docker run --log-driver=journald --log-opt labels=app_id --name=mon-app nginx

Ou dans un fichier docker-compose.yml :

version: '3'
services:
 mon_service:
 image: mon_image
 logging:
 driver: json-file
 options:
 max-size: "10m" # Taille maximale d'un fichier de log
 max-file: "3" # Nombre maximum de fichiers de rotation

Bonnes pratiques pour la gestion des logs

La rotation, c'est la vie
- Configurez toujours max-size et max-file
- Évitez les fichiers de logs de 42 Go qui font pleurer les disques durs
Étiquetez, c'est gagné
- Utilisez 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
- Centralisez avec ELK, Graylog ou Loki
- Pensez à la rétention et à l'archivage
La surveillance, c'est comme le café du matin : indispensable
- Surveillez 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

Conclusion

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.

Comme dirait un vieux barbu de l'IT : "Les logs, c'est comme le papier toilette - on ne réalise leur importance que quand on en a plus." Alors, à vos fichiers de configuration, et que la force des logs soit avec vous !

Et 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).

Docker : Configuration et gestion du stockage

Sun, 15 Jun 2025 16:56:25 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans les profondeurs du stockage Docker. Comme on dit dans notre jargon : "Un disque mal configuré est à un admin système ce que Kryptonite est à Superman - une faiblesse qui peut tout paralyser."

Comprendre 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.

Par 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.

Configuration 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 :

{
 "storage-driver": "overlay2"
}

Note : overlay2 est généralement le pilote recommandé pour les distributions Linux modernes, offrant le meilleur équilibre entre performance et fonctionnalités.

Après cette modification, un redémarrage du service Docker est nécessaire :

sudo systemctl restart docker

Les différents pilotes de stockage

overlay2 : Le pilote recommandé pour la plupart des cas d'usage
- Avantages : 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.
devicemapper : Utilisé principalement sur les anciennes versions de CentOS/RHEL
- Pour 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

{
 "storage-driver": "devicemapper",
 "storage-opts": [
 "dm.directlvm_device=/dev/xvdf"
 ]
}

Systèmes de fichiers avancés et distribués : Pour aller plus loin
- Les 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 "volume bind déguisé" qui permet de créer un volume Docker qui pointe vers un point de montage réseau

Dé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 :

{
 "data-root": "/mnt/docker-data"
}

Attention : Ne modifiez jamais ce paramètre sur une installation Docker existante sans migrer correctement les données !

Pour migrer les données d'une installation existante :

# 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 "volume bind déguisé" - 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.

Imaginez pouvoir dire à vos conteneurs : "Voici un volume Docker standard" 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.

Cette technique est particulièrement précieuse quand vous travaillez avec :

Des 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.

Nettoyage de l’espace disque

Docker a tendance à accumuler des données inutilisées. Voici quelques commandes pour faire le ménage :

# 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'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
Optimisez vos Dockerfiles :
- Combinez 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 && apt install -y \
 package1 \
 package2 \
 && apt clean \
 && rm -rf /var/lib/apt/lists/*

Utilisez .dockerignore pour exclure les fichiers inutiles du contexte de build
Surveillez régulièrement l'espace disque utilisé par Docker avec docker system df
Configurez un cron job pour nettoyer périodiquement les ressources inutilisées

Conclusion

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.

En 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 "hello-world" qui traînaient.

Et 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).

Docker : Configuration des réseaux par défaut

Sun, 15 Jun 2025 16:17:21 +0200

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 : "Un conteneur sans réseau, c'est comme un pingouin sans banquise - techniquement possible, mais pas vraiment utile."

Les réseaux Docker par défaut

Docker, cet invité un peu sans-gêne, s'installe et crée directement trois réseaux :

bridge : 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.

Ré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) :

{
 "default-address-pools": [
 {
 "base": "192.168.66.0/24",
 "size": 24
 }
 ]
}

Après cette modification, un petit redémarrage s'impose :

sudo 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 :

docker network create mon-super-reseau

Pour cette commande, Docker utilisera automatiquement la première plage disponible: 192.168.66.0/24

docker network create mon-autre-reseau

Pour ce deuxième réseau, Docker passera à la plage suivante: 192.168.67.0/24

C'est comme distribuer des tranches de gâteau - mais en version IP.

Si vous préférez choisir votre part vous-même :

docker 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 :

bridge : 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.
host : 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.
none : 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.
macvlan : 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.

# 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 :

overlay : 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 "au-dessus" de l'infrastructure physique.
ingress : 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.

# 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.

Le 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 :

Docker vous lance des erreurs cryptiques avec "network overlap"
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 à :

Supprimer 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 !

Bonnes 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
Choisissez le bon type de réseau : Ne vous limitez pas au bridge par défaut.
- Bridge 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
Adoptez une nomenclature claire : Préférez project_frontend_net ou prod_db_network à des noms génériques comme net1
Documentez votre architecture réseau : Votre futur vous (ou votre remplaçant après votre burnout) vous remerciera

Conclusion

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 "mais pourquoi ça ne communique pas ?".

Une 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.

Et 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).

Debian : Configuration complète d’unattended-upgrades pour une sécurité sans effort

Thu, 08 May 2025 14:03:19 +0200

1. Introduction, ou pourquoi il est temps d’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 && 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.

Heureusement, 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.

2. Unattended-upgrades : le sysadmin silencieux qui ne prend jamais de pause café

Contrairement à votre stagiaire qui croit que "mise à jour de sécurité" signifie "changer son mot de passe de 'password123' à 'password1234'", 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).

Techniquement parlant (et les vrais barbus aiment parler techniquement), c'est un démon qui s'exécute via systemd timers pour :

Chercher 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 "plus tard")
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.

3. 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 :

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

Ce que vous venez de conjurer :

unattended-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 "clique-bouton" (aucun jugement, enfin peut-être un peu), Debian vous offre un assistant :

sudo 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.

Un menu pseudo-graphique va apparaître dans votre terminal. Sélectionnez "Oui" (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.

4. Configuration pour les vrais barbus (ceux qui n’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 :

/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 :

Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename}-security";

 // "origin=Debian,codename=${distro_codename}-updates";

 // "origin=Debian,codename=${distro_codename}-proposed-updates";

 // "origin=Debian,codename=${distro_codename}-backports";
};

Guide de traduction du jargon Debian pour mortels :

Type de dépôt	Ce que Debian dit	Ce que ça signifie vraiment	À activer si...
-security	"Correctifs de sécurité critiques"	"Colmate les trous que les script kiddies utilisent déjà"	Vous avez un minimum d'instinct de survie
-updates	"Corrections importantes non sécuritaires"	"Bugs suffisamment gênants pour qu'on daigne les corriger"	Vous en avez assez que vos services plantent mystérieusement
-proposed-updates	"Candidats en attente de validation"	"Quelqu'un a bricolé ça, ça semble marcher, mais on n'est pas sûr"	Vous aimez vivre dangereusement (ou avez un environnement de test)
-backports	"Nouvelles versions portées vers stable"	"Du code récent greffé sur un OS dinosaure"	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.

4.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 :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Unattended-Upgrade-Time "3";
APT::Periodic::RandomSleep "60";

Explication pour ceux qui n'ont jamais lu le man :

Update-Package-Lists : À quelle fréquence votre système recherche de nouvelles mises à jour.
- "1" = tous les jours (pour les paranoïaques)
- "7" = une fois par semaine (pour les décontractés)
- "0" = jamais (pour ceux qui aiment jouer à la roulette russe avec les exploits)
Unattended-Upgrade : Quand appliquer réellement ces mises à jour.
- "1" = quotidiennement (recommandé par tous ceux qui ont déjà dû nettoyer un serveur compromis)
- "7" = hebdomadaire (un compromis pour les téméraires)
- "0" = jamais (alors pourquoi lire cet article ?)
Unattended-Upgrade-Time : L'heure à laquelle lancer le processus.
- "3" = 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.
- "60" = 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.

4.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 :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Ce que ces options signifient vraiment :

Automatic-Reboot : Le grand interrupteur de la terreur nocturne.
- "true" = "J'aime vivre dangereusement et mes backups sont à jour"
- "false" = "Je préfère avoir un noyau vulnérable mais au moins je sais quand mon serveur redémarre"
Automatic-Reboot-Time : L'heure du crime parfait.
- Format : "HH:MM" (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.
- "true" = "Les sessions des utilisateurs importent moins que la sécurité" (approche soviétique)
- "false" = "Les humains d'abord" (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.

4.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 :

Unattended-Upgrade::Mail "admin@domaine.fr";
Unattended-Upgrade::MailReport "on-change";

//Unattended-Upgrade::Mail-Server "smtp.example.com";
//Unattended-Upgrade::Mail-Server-Port "587";
//Unattended-Upgrade::Mail-Server-Login "votre_login";
//Unattended-Upgrade::Mail-Server-Password "votre_motdepasse";

Options pour votre spam personnel :

Mail : Qui recevra les rapports que personne ne lit.
- Mettez 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.
- "always" = pour ceux qui aiment leur boîte mail bien remplie
- "on-change" = le choix des gens raisonnables
- "only-on-error" = pour ceux qui adhèrent à la philosophie "pas de nouvelles, bonnes nouvelles"

📣 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 :
sudo apt install postfix
# OU
sudo apt install msmtp msmtp-mta

5. Dompter les mises à jour majeures (ou l’art d’é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.

5.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.

Le drame en 4 actes :

Acte	Tragédie	Résultat
1	Votre système découvre PHP 8.3 et pense "oh, quelle belle mise à jour !"	Installation lancée à 3h17 du matin
2	Le script demande poliment : "Voulez-vous faire de cette nouvelle version la version par défaut ?"	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 :

sudo echo "php8.3 php8.3/common/default_for_install boolean false" | sudo debconf-set-selections
sudo echo "php8.2 php8.2/common/default_for_install boolean true" | 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.

5.2.2 Expliquer à Debian ce qu’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 :

sudo 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.

5.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 :

sudo vi /etc/apt/apt.conf.d/99post-upgrade-hook

Ajoutez ce code vindicatif dans le fichier :

DPkg::Post-Invoke {
 "if [ -f /usr/bin/php8.2 ] && [ -f /usr/bin/php8.3 ]; then update-alternatives --set php /usr/bin/php8.2; fi";
};

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 "Merci pour ton opinion, maintenant on va faire à ma façon quand même".

5.2.4 Mettre un gilet pare-balles contre les versions majeures

Ajoutez à /etc/apt/apt.conf.d/50unattended-upgrades ce code défensif :

Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Allow-downgrade "false";
Unattended-Upgrade::Allow-APT-Mark-Fallback "false";

Décryptage des incantations de protection :

Option	Ce qu'elle fait vraiment	Traduction en langage barbu
MinimalSteps	Change en mode "un paquet à la fois"	"Je préfère que mon système plante sur UN paquet plutôt que sur TOUS"
Allow-downgrade	Empêche les retours en arrière	"Non, on ne revient pas à PHP 5 juste parce que tu as peur du changement"
Allow-APT-Mark-Fallback	Désactive l'auto-sélection de nouvelles versions	"Touche pas à mes versions majeures, animal ! "

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 :

Unattended-Upgrade::Blacklist {
 "php*";
 "mariadb-server";
 "postgresql*";
 "nginx";
 "apache2";
};

5.3 Le plan de bataille pour les vrais professionnels

📌 Stratégie de survie en environnement de production :

Bloquez 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.

6. Entrer dans la matrice : surveillance et déblocage des catastrophes nocturnes

6.1 Les logs que personne ne lit jamais (jusqu’à 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 :

Fichier 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 "que s'est-il passé ?"
`/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 :

sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log

sudo grep -i "error\|fail\|warning" /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 :

sudo 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 : "C'est exactement pourquoi j'utilise dry-run, voyez-vous".

6.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 :

sudo 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 "Voulez-vous que PHP 8.3 devienne le nouveau PHP par défaut ?", il est temps d'intervenir manuellement (comme arracher la manette des mains d'un enfant) :

sudo dpkg --configure -a
sudo dpkg-reconfigure php8.3-common

OPNsense : Configuration du NAT Reflection

Sat, 08 Feb 2025 16:23:40 +0100

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.

Dans 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.

Configuration des options du NAT Reflection

Pour configurer le NAT Reflection dans OPNsense, suivez ces étapes :

Se rendre dans Firewall (1), Settings (2), puis Advanced (3)
Faire défiler jusqu'à la section Network Address Translation

Deux options importantes sont à configurer :

Reflection 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’utilisation

Le NAT Reflection est particulièrement utile dans plusieurs scénarios :

Hé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.

Points d’attention

Quelques points importants à garder à l'esprit :

Le 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 :

Cliquer 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.

N'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.

Déployer une application sur Kubernetes

Thu, 06 Feb 2025 08:30:54 +0100

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.

Pourquoi ce changement ?
Car étant encore étudiant et en plein dans le sujet, quoi de mieux que de mettre les mains dans le camboui ?

Pré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.
C'est quoi Mealie ? Mealie est un gestionnaire de recettes de cuisine accessible via navigateur, entièrement self hosté.

L’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.

Nous pouvons y observer:

Une 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.
Les manifests Kubernetes sont des fichiers yaml déclaratif qui vont dire à Kubernetes comment on veut que notre application soit déployée.

Il 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.
Mealie é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.

(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.)

Reprenons notre liste à puce de la partie précédente.
Il nous faut:

Il nous faut un objet de type Deployment, il va servir à déployer les Pods avec des configuration que j'aurais définie.
Ce manifest yaml contiendra:
- L'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.
Le StatefulSet fonctionne presque exactement comme un Deployment, mais il est fait pour les services type stateful, les pods sont identifiés et non-interchangeable.
Ensuite, on va avoir besoin de créer les objets Configmap et Secret.
Ces 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.
La 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.
Exemple d'une configmap:
```
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mealie-configmap
 namespace: mealie
data:
 ALLOW_SIGNUP: "false"
 TZ: "Europe/Paris"
 DB_ENGINE: "postgres"
 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.
Les 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.
La logique d'un service fonctionne donc comme ça:
Les Pods ont des labels sous forme de clé valeur --> 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.
Un service au minimum demande:
- Le 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.

Pour les volumes, il faut faire une introduction aux PersistentVolumes (PV) et aux PersistentVolumeClaims (PVC).
Un PV est un volume de stockage défini provisionné manuellement ou dynamiquement (via une StorageClass).
Le PVC quant à lui est une requête pour consommer un PV.
Dans 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.
Il 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.
Un 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.
Un 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).
Il peut également gérer plusieurs noms de domaine, utiliser des headers de sécurité et implémenter un certificat SSL/TLS.
Normalement, 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.
Je 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.
Comment faire pour tout faire d'un coup ?
Avec la commande CLI builtin et les manifests Kustomize.

Voici un exemple d'un manifest kustomize:

---
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.
Kustomize va donc appeler chaque manifest yaml de la liste définie dans resources et les appliquer un à un dans Kubernetes.
On 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.

Conclusion

Et voilà ! À table !

Au final si jamais vous vous posez la question, est-ce que vous devez utiliser Kubernetes ou Docker dans votre homelab, sachez une chose.

Utiliser Docker est vraiment vraiment plus simple dans un petit environnement, quel intérêt d'utiliser Kubernetes ?
Apprendre et évoluer ! Bien sûr c'est suffisant d'utiliser Docker, mais Kubernetes apporte son lot d'avantage, de satisfaction, (de soirée perdues).

Libérez votre swap !

Sun, 01 Dec 2024 06:09:15 +0100

Préambule

Envie de libérer Britney ? Ou plutôt... votre swap ? 🎵

Si vous cherchez à optimiser l'utilisation de votre mémoire virtuelle sur une machine Debian, vous êtes au bon endroit !

Le `swappiness`, c’est quoi ?

Le swappiness est un paramètre du kernel Linux qui contrôle la "proportion" 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.

Quelques 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.

3. Rendre la configuration persistante

Ajoutez ou modifiez la ligne suivante dans /etc/sysctl.conf :

vm.swappiness=20

Appliquez ensuite la configuration :

sudo 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 && sudo swapon -a

⚠️ Assurez-vous que la RAM disponible est suffisante pour accueillir les données du swap avant de désactiver ce dernier.

6. Identifier les processus utilisant le swap

Pour examiner les processus gourmands en swap, utilisez cette commande :

for file in /proc/*/status ; do \
 awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $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 :

Script : `free-swap.sh`

#!/bin/bash

check_command() {
 if [[ $? -ne 0 ]]; then
 echo "Erreur lors de l'exécution de la commande: $1"
 exit 1
 fi
}

free_data=$(free)
check_command "free"
mem_data=$(echo "$free_data" | grep 'Mem:')
free_mem=$(echo "$mem_data" | awk '{print $4}')
buffers=$(echo "$mem_data" | awk '{print $6}')
cache=$(echo "$mem_data" | awk '{print $7}')
total_free=$((free_mem + buffers + cache))

if echo "$free_data" | grep -q 'Échange:'; then
 used_swap=$(echo "$free_data" | grep 'Échange:' | awk '{print $3}')
else
 used_swap=$(echo "$free_data" | grep 'Swap:' | awk '{print $3}')
fi

echo -e "Free memory:\t$total_free kB ($((total_free / 1024)) MB)\nUsed swap:\t$used_swap kB ($((used_swap / 1024)) MB)"

if [[ $used_swap -eq 0 ]]; then
 echo "Félicitations ! Aucun swap n'est utilisé."
elif [[ $used_swap -lt $total_free ]]; then
 echo "Libération du swap..."
 sudo swapoff -a
 check_command "swapoff"
 sudo swapon -a
 check_command "swapon"
else
 echo "Pas assez de mémoire libre pour libérer le swap. Arrêt."
 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.

Conclusion

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.

Et surtout, souvenez-vous : le swap, c'est bien... mais la RAM, c'est mieux ! 😉

Restic ou l’Importance des Sauvegardes de Données

Mon, 11 Nov 2024 13:55:45 +0100

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.

Face à 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.

Voyons 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.

Je commence par définir les variables essentielles de son script, qui permettront de personnaliser la sauvegarde en fonction de mes besoins spécifiques.

#!/bin/bash
export RESTIC_PASSWORD='ZZZZZZZZZZZZ'
export RESTIC_REPO='/mnt/restic'
export BACKUP_TARGET='.'
export BACKUP_SOURCE='/mnt/shared/nas'
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.

RESTIC_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).

BACKUP_TARGET : La destination de la sauvegarde.

BACKUP_SOURCE : La source des fichiers à sauvegarder, ici /mnt/shared/nas, qui est un répertoire contenant des fichiers critiques.

NUM_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.

L'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.

Cependant, 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.

DB_HOST="localhost"
DB_PORT="5432"
DB_USER="estx50"
DB_DUMP_PATH="/mnt/shared/nas/Trading/all_databases_backup.sql"

export PGPASSWORD='XXXXXXXXXXXXXX'

DAY_OF_WEEK=$(date +%u)
if [[ "$DAY_OF_WEEK" -ge 1 && "$DAY_OF_WEEK" -le 5 ]]; then
 echo "Jour de semaine - Création du dump de la base de données."
 pg_dumpall -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" > "$DB_DUMP_PATH" || exit 1
else
 echo "Aujourd'hui est le week-end, aucun dump de la base de données ne sera créé."
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.

J'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.

cd "$BACKUP_SOURCE" && restic -r "$RESTIC_REPO" backup --exclude "/mnt/shared/nas/récupération_Oscar" --exclude "/mnt/shared/nas/Trading/data" "$BACKUP_TARGET" --skip-if-unchanged || exit 1

Remarque importante
Vous noterez que les exclude requièrent le chemin absolu.

skip-if-unchanged:

Cette 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.

Une 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.

restic -r "$RESTIC_REPO" forget --keep-last "$NUM_KEEP_SNAPSHOTS" --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.

J'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é.

Enfin 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.

restic -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.

Conclusion : Un Outil de Sauvegarde Puissant

En 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.

Dans 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.

Git : How to smudge and clean ?

Sun, 27 Oct 2024 23:36:07 +0100

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.

À 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.

Face à 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 "smudge and clean".

Les faits

Il a ajouté dans le fichier .git/config de son projet, les lignes suivantes :

[filter "secrets"]
 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.

Filter secrets

Le script de filtrage filter-secrets.sh en question ressemblait à cela :

#!/bin/bash

if [ "$1" == "clean" ]; then
 # Clean (replace sensitive data with placeholders)
 sed -e 's/XXXXXXXXX/{API_KEY_PLACEHOLDER}/g' \
 -e 's/YYYYYYYYY/{SENDING_API_KEY_PLACEHOLDER}/g' \
 -e 's/ZZZZZZZZZ/{SMTP_PASSWORD_PLACEHOLDER}/g' \
 -e 's/AAAAAAAAA/{POSTGRES_PASSWORD_PLACEHOLDER}/g' \
 -e 's/BBBBBBBBB/{TWS_USERID_PLACEHOLDER}/g' \
 -e 's/CCCCCCCCCC/{TWS_PASSWORD_PLACEHOLDER}/g'

 # Si une erreur se produit avec sed, renvoyer un code d'erreur
 if [ $? -ne 0 ]; then
 echo "Erreur lors de l'exécution du clean"
 exit 1
 fi
elif [ "$1" == "smudge" ]; then
 # Smudge (replace placeholders with sensitive data)
 sed -e 's/{API_KEY_PLACEHOLDER}/XXXXXXXXX/g' \
 -e 's/{SENDING_API_KEY_PLACEHOLDER}/YYYYYYYYY/g' \
 -e 's/{SMTP_PASSWORD_PLACEHOLDER}/ZZZZZZZZZ/g' \
 -e 's/{POSTGRES_PASSWORD_PLACEHOLDER}/AAAAAAAAA/g' \
 -e 's/{TWS_USERID_PLACEHOLDER}/BBBBBBBBB/g' \
 -e 's/{TWS_PASSWORD_PLACEHOLDER}/CCCCCCCCCC/g'

 if [ $? -ne 0 ]; then
 echo "Erreur lors de l'exécution du smudge"
 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 :

config.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.

CrowdSec : Avoid a Duplicate Decision / Notification

Wed, 07 Aug 2024 10:52:44 +0200

Introduction

Prenons le cas de l'utilisation de CrowdSec pour protéger des applications web en analysant les logs du reverse-proxy.

Suivant 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.

Nous 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.

Pré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

Voici 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 && Alert.GetScope() == "Ip"
decisions:
 - type: ban
 duration: 4h
#duration_expr: "Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)"
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.

Voici le fichier modifié :

#/etc/crowdsec/profiles.yaml
name: default_ip_remediation
filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip" && GetDecisionsSinceCount(Alert.GetValue(), "2h") < 1
decisions:
 - type: ban
 duration: 4h
#duration_expr: "Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)"
on_success: break

Pour valider la modification, redémarrez le service :

systemctl restart crowdsec

Intérêt

On peut se dire : Mais pourquoi faire ça ?

A chaque fois que CrowdSec prendra une décision, si les notifications sont configurées, cela en déclenchera une systématiquement.

Dans mon cas, cela concernait les scans multi-ports et j'en avais marre de recevoir du spam de notification... (Effet JO 2024 ???).

Voici l'output que cela donnait en moins d'une minute :

Conclusion

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.

CrowdSec : Protéger l’authentification Gitlab

Fri, 19 Jul 2024 11:06:58 +0200

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.

Ce 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).

Pré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’API CrowdSec

Très important !

Avec 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.

Procédure décrite [ici]
Vérifiez bien que vos services crowdsec fonctionnent correctement :
```
journalctl -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.

Installer la collection :

cscli collections install timokoessler/gitlab

Ceci a pour effet d'installer 1 parser et 1 scénario.

Lister les parsers :

cscli parsers list
# timokoessler/gitlab-logs ✔️ enabled 0.1 /etc/crowdsec/parsers/s01-parse/gitlab-logs.yaml

Lister les sénarios :

cscli scenario list
# timokoessler/gitlab-bf ✔️ enabled 0.2 /etc/crowdsec/scenarios/gitlab-bf.yaml

Création du fichier d’acquisition

Afin que le parser Gitlab puisse être utilisé, il faut définir la méthode d'acquisition.

Cré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é :

systemctl reload crowdsec

Vérification

Nous allons vérifier le fonctionnement du parser et du nouveau scénario dédié à gitlab.

Pour cela, spammez la page de login de Gitlab, puis vérifiez les résultats :

Alertes :

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.

CrowdSec : Protéger l’authentification Proxmox

Thu, 18 Jul 2024 14:50:45 +0200

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.

Ce 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.

Pré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.

Installer la collection :

cscli collections install fulljackz/proxmox

Ceci a pour effet d'installer 2 parsers et 1 scénario.

Lister les parsers :

cscli 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 :

cscli 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.

Modification du parser proxmox

Le parser spécifique à proxmox se situe ici : /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml

Pour qu'il soit compatible avec la dernière version de Proxmox, nous allons l'éditer et apporter les modifications suivantes :

pattern_syntax:
 PVE_AUTH_FAIL: 'authentication failure; rhost=::ffff:%{IP:client_ip} user=%{USERNAME:source_user}@%{WORD:realm} msg='

Ajout : ::ffff:

Création du fichier d’acquisition

Afin que le parser Proxmox puisse être utilisé, il faut définir la méthode d'acquisition.

Utilisation avec journald

Pour utiliser le parser avec journald :

Cré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 :

Installez rsyslog si ce n'est pas déjà fait :
```
apt install -y rsyslog
```
Créez le fichier /etc/crowdsec/acquis.d/proxmox.yaml avec le contenu suivant :

---
filenames:
 - /var/log/syslog
labels:
 type: pvedaemon

Redémarrage du service

A présent, le service crowdsec peut être rechargé :

systemctl reload crowdsec

Vérification

Nous allons vérifier le fonctionnement des parsers et du nouveau scénario dédié à proxmox.

Pour cela, spammez la page de login de Proxmox, puis vérifiez les résultats :

Alertes :

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.

CrowdSec : Installation avec Bouncer Iptables sur Debian 12

Thu, 18 Jul 2024 10:28:12 +0200

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.

Pré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.

apt update
apt -y upgrade

Étape 2 : Installation de CrowdSec

Ajouter le dépôt CrowdSec

Téléchargez et ajoutez la clé GPG pour vérifier l'intégrité du dépôt :
```
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | bash
```
Installer CrowdSec

Installez le package CrowdSec :
```
apt install -y crowdsec
```
Vérifier l'installation

Assurez-vous que CrowdSec est correctement installé et en cours d'exécution :
```
systemctl 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.

Télécharger et installer le bouncer iptables

apt install -y crowdsec-firewall-bouncer-iptables

Configurer le bouncer

L'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.
Démarrer et activer le bouncer

Assurez-vous que le bouncer est activé au démarrage et qu'il est en cours d'exécution :
```
systemctl enable crowdsec-firewall-bouncer
systemctl start crowdsec-firewall-bouncer
```
Vérifier le bouncer

Vérifiez que le bouncer est correctement installé et en cours d'exécution :
```
systemctl 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.

Installer les scripts de complétion

Pour bash, vous pouvez utiliser le script de complétion fourni par CrowdSec. Tout d'abord, assurez-vous que bash-completion est installé :
```
apt install -y bash-completion
```
Activer la complétion

Installez le script de complétion pour cscli :
```
cscli completion bash > /etc/bash_completion.d/cscli
```
Recharger la configuration de bash

Rechargez votre configuration de bash pour que la complétion soit prise en compte :
```
source /etc/bash_completion.d/cscli
```
Vérifier la complétion

Testez la complétion automatique en tapant cscli suivi de Tab pour voir les options disponibles.

Étape 5 : Vérification de l’intégration

Pour vérifier que tout fonctionne correctement, vous pouvez consulter les journaux de CrowdSec et du bouncer iptables :

journalctl -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 :

Editez le fichier /etc/crowdsec/profiles.yaml
```
decisions:
- type: ban
 duration: 24h
```
Recharger le service crowdsec
```
systemctl 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 🙂

Créer un compte sur https://app.crowdsec.net/

Validez votre compte en vous authentifiant sur la plateforme
Rendez vous dans le menu "Security Engines" > "Engines"

Cliquez sur "Add Security Engine".
Exécutez la commande d'enrôlement sur votre serveur
```
cscli console enroll -e context YOUR-ENROLL-KEY
```
Dans un contexte d'automatisation, il est possible de spécifier le nom d'hôte :
```
cscli console enroll --name $(hostname) YOUR-ENROLL-KEY
```
Voici l'aide de la commande : https://docs.crowdsec.net/docs/next/cscli/cscli_console_enroll/
Acceptez l'enrôlement sur la plateforme web de CrowdSec
Redémarrez le service crowdsec sur le serveur
```
systemctl restart crowdsec
```

Modification du port de l’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.

Exemple pour utiliser le port TCP 6660 à la place du TCP 8080 :

Modifiez le fichier /etc/crowdsec/config.yaml

api:
 client:
 [...]
 server:
 [...]
 listen_uri: 127.0.0.1:6660

Modifiez le fichier /etc/crowdsec/local_api_credentials.yaml
```
url: http://127.0.0.1:6660
```
Modifier le fichier /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
```
api_url: http://127.0.0.1:6660/
```

Redémarrez les services crowdsec

systemctl 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.

Ressources supplémentaires

Compression Multithreading : pigz (gzip) & pbzip2 (bzip2)

Mon, 08 Jul 2024 15:05:42 +0200

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.

Cet 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.

Introduction à 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.

Limites 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.

Multithreading : 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) :

sudo apt install pigz

Exemples d’utilisation avec tar et l’option `-I`

Compression

Pour compresser une archive tar avec pigz :

tar -cvI pigz -f archive.tar.gz dossier/

Décompression

Pour décompresser une archive tar.gz avec pigz :

tar -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.

Multithreading : 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) :

sudo apt install pbzip2

Exemples d’utilisation avec tar et l’option `-I`

Compression

Pour compresser une archive tar avec pbzip2 :

tar -cvI pbzip2 -f archive.tar.bz2 dossier/

Décompression

Pour décompresser une archive tar.bz2 avec pbzip2 :

tar -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.

Ré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.

Exemple :
```
pigz -p 8 -c fichier > 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.

Exemple :
```
tar -cvI "pigz -p 4" -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.

Conclusion

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.

Références

Docker-Compose : Mise à jour manuelle des images

Mon, 01 Jul 2024 11:15:09 +0200

Pré-requis

Assurez-vous de vous placer dans le répertoire contenant le fichier docker-compose.yml avant de suivre les étapes ci-dessous.

É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 :

docker 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 :

docker 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 :

docker image prune

MySQL : Réinitialisation du mot de passe root dans un conteneur Docker

Mon, 17 Jun 2024 15:57:47 +0200

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.

Pré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.

USE mysql;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NEWPASSWORD';
FLUSH PRIVILEGES;

Remplacez NEWPASSWORD par le nouveau mot de passe souhaité.

2. Modifier `docker-compose.yml`

Pour utiliser le fichier de réinitialisation avec Docker, vous devez monter ce fichier dans le conteneur MySQL.

Ajoutez ou modifiez la section volumes pour inclure le montage du fichier mysql-init.sql :

services:
 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 :

docker compose stop mysql

2. Accéder au conteneur

Lancez le conteneur MySQL sans démarrer le service pour obtenir un shell bash :

docker compose run mysql bash

3. Exécuter le script de réinitialisation

Dans le conteneur, lancez MySQL avec le fichier de réinitialisation :

mysqld --init-file=/tmp/mysql-init.sql &

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.

4. Nettoyer et relancer le service

Quittez le conteneur et supprimez le montage du fichier SQL dans docker-compose.yml :

Supprimez ou commentez la ligne - ./mysql-init.sql:/tmp/mysql-init.sql.

Ensuite, arrêtez complètement la stack Docker :

docker compose down

Relancez la stack :

docker 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 :

docker exec -it <CONTENEUR_MYSQL> mysql -u root -p

Remplacez <CONTENEUR_MYSQL> par l'ID ou le nom du conteneur MySQL.

WordPress : Augmenter la taille d’upload des fichiers (Docker)

Sat, 15 Jun 2024 12:05:28 +0200

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

Docker-Compose : WordPress (MariaDB)

Sat, 15 Jun 2024 11:53:16 +0200

Le fichier docker-compose.yml

services:
 wordpress:
 image: wordpress
 container_name: "wordpress"
 restart: unless-stopped
 ports:
 - "8080:80"
 environment:
 WORDPRESS_DB_HOST: db
 WORDPRESS_DB_USER: "wordpress"
 WORDPRESS_DB_PASSWORD: "wordpress_db_password"
 WORDPRESS_DB_NAME: wordpress
 volumes:
 - ./wordpress:/var/www/html
 - /etc/localtime:/etc/localtime:ro
 depends_on:
 - db
 networks:
 - network

 db:
 image: mariadb
 container_name: "wordpress-db"
 restart: unless-stopped
 environment:
 MYSQL_RANDOM_ROOT_PASSWORD: '1'
 MYSQL_DATABASE: wordpress
 MYSQL_USER: "wordpress"
 MYSQL_PASSWORD: "wordpress_db_password"
 volumes:
 - ./db:/var/lib/mysql
 - /etc/localtime:/etc/localtime:ro
 networks:
 - network

networks:
 network:
 driver: bridge

Execution

docker compose up -d

Fail2ban : Installation et configuration (Debian 12)

Sat, 15 Jun 2024 10:20:35 +0200

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.

Cet 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.

Sous 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.

Les 2 méthodes sont présentées ici. Let's go !

Installation

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 .

Ces fichiers ne doivent pas être modifié. Ils seront écrasés à la prochaine mise à jour de fail2ban.
Fail2ban lit les fichiers de configurations dans cet ordre :
- Les fichiers .conf
- Les fichiers .local
Chaque directive définit dans le fichier de configuration .local, écrase la directive contenue dans son homologue .conf.

Ce 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.
Créer les fichiers de configuration adéquat en se basant sur ceux présents :
```
sudo cp /etc/fail2ban/jail.{conf,local}
```
Editer le fichier jail.local :
```
sudo 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.

Paramétrage

Il est utile d'indiquer des IPs en liste blanche pour éviter de s'auto-ban lors d'un retour de vacance.
Décommenter la ligne commençant par ignoreip et ajouter les adresses IPs séparées d'un espace :
```
ignoreip = 127.0.0.1/8 ::1 123.123.123.123 192.168.1.0/24
```
Il y a 3 directives importantes à connaitre :
- bantime : 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.
- findtime : La durée pour comptabiliser le nombre de tentatives maximales (maxretry) avant de déclencher un ban.
- maxretry : Le nombre de tentative durant la période indiquée dans findtime avant de ban une ip.
Exemple :
```
bantime = 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.
Pour être notifié par email, modifier la ligne commençant par action :
```
action = %(action_mw)s
```
- Pour avoir les logs dans l'email, indiquer %(action_mwl)s.
- Un serveur SMTP doit être installé sur le serveur (non abordé).

Modifier l'adresse de destinataire et d'expéditeur :

destemail = 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 :

sudo 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.

Fail2ban est fournit avec plusieurs jails pour différents services. Une jail peut être définie manuellement.

Pour activer une jail, il faut ajouter la directive enabled = true juste après le titre.
Exemple pour le service sshd (toujours dans le fichier jail.local) :
```
[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 's/backend = auto/backend = systemd/' /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.

Pour voir toutes les options disponibles :
```
fail2ban-client -h
```

Voici quelques exemples :

Connaitre 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

Proxmox : Template Oraclelinux9 avec Cloud-Init

Fri, 31 May 2024 22:46:12 +0200

Cette procédure va permettre de créer un template de VM Oraclelinux 9 pour Proxmox avec Cloud-Init.

L'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.

Ce template pourra éventuellement être utilisé par la suite avec une solution telle que Terraform / OpenTofu.

Cré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 "iothread" 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.

Ajouter 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.

Plus de détails ici https://pve.proxmox.com/wiki/Cloud-Init_Support sur les différents paramétrages.

Convertir 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="COLORS DISPLAY
 HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
 env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC
 LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
 secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User admin may run the following commands on ol9-cloudinit:
 (ALL) NOPASSWD: ALL

OPNsense : Block malicious IPs

Thu, 21 Mar 2024 10:08:02 +0100

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 : "Hey, rajoute cette liste comportant + de 200k IP !"

Cette fameuse liste est disponible sur ce dépôt git : https://github.com/duggytuxy/Intelligence_IPv4_Blocklist

En complément : Un clin dœil à Romain Marcoux pour ses travaux open source liés autour de la CTI : https://github.com/romainmarcoux

La 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.

Allez, c'est parti !

Mise en place d’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.

Tout 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

Valider 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).

Augmenter le nombre d’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.

Se 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é.

Se 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 !

Bien é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.

Proxmox : ACME Certificate

Mon, 22 Jan 2024 21:13:13 +0100

J'ai du mettre en place un certificat proxmox pour un serveur accessible publiquement.
Donc voici une procédure pour la mise en place de certificat avec l'aide de ACME.

Nous allons générer un certificat pour notre serveur proxmox avec l'aide de la technologie ACME.

Pour cela on va passer par la methode présente dans la configuration graphique de proxmox.

Dans un premier temps on va avoir besoin de créer un compte ACME qui va être utilisé pour la génération du certificat.

Il faut se rendre dans Datacenter > ACME

Puis il suffit d'ajouter un compte comme dans le screen présent ci dessous :

Une fois que le compte a été créé nous devons faire la demande de certificat.

Pour cela il faut se rendre dans la catégorie :
Datacenter > pve > System > Certificates

Nous allons utiliser la partie HTTP.
Pour cela il faut juste renseigner le FQDN de votre serveur :
pve.domaine.fr

Une fois que le domaine a été renseigné il suffit de générer la requette avec l'aide de l'utilitaire.
Il suffit de cliquer sur son certificat > (choisir son profile) > Order certificate Now

Il vous suffira d'attendre que le certificat soit généré.

Une fois que le certificat est généré, il vous suffira de recharger votre page et votre certificat sera mis à jour.

Erreur rencontrée

J'ai eu une erreur au moment de la génération.
L'erreur rencontrée était qu'il manquait l'utilisateur "default" dans les comptes ACME.
J'ai donc créer un compte "default" avec un mail bidon. Et après j'ai pu effectuer la demande de certificat sans problème.

Proxmox : Template Debian12 avec Cloud-Init

Thu, 09 Nov 2023 14:23:19 +0100

Cette procédure va permettre de créer un template de VM Debian 12 pour Proxmox avec Cloud-Init.

Ce template pourra éventuellement être utilisé par la suite avec une solution telle que Terraform / OpenTofu.

Cré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.

Ajouter 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.

Plus de détails ici https://pve.proxmox.com/wiki/Cloud-Init_Support sur les différents paramétrages.

Convertir 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.15
...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.16.20.15' (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.

Docker : Volume bind déguisé

Wed, 11 Oct 2023 11:25:12 +0200

Avec Docker, il y a principalement 2 types de volumes qui sont utilisés :

Les volumes "volume" : Permet de stocker un répertoire du conteneur dans un volume docker stocké sur l'host (/var/lib/docker/volumes).
Les volumes "bind" : 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 "bind" afin d'avoir de la persistence pour certaines données d'un conteneur. Par exemple, une base de donnée.

Le 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 "bind".

Avec un volume "volume", 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.

Alors, 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 🙂

Création du volume docker

Tout d'abord, créer un répertoire local sur l'host qui stockera les données :

sudo mkdir -m 775 -p /srv/docker/volumes/data

Puis, changer l'utilisateur et groupe propriétaire :

sudo chown -R $USER:docker /srv/docker/volumes

Enfin, créer le volume docker :

docker 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 :

$ docker volume list
DRIVER VOLUME NAME
local vol_data

Vérifier les propriétés du volume :

$ docker inspect vol_data
[
 {
 "CreatedAt": "2023-10-11T11:15:38+02:00",
 "Driver": "local",
 "Labels": null,
 "Mountpoint": "/var/lib/docker/volumes/vol_data/_data",
 "Name": "vol_data",
 "Options": {
 "device": "/srv/docker/volumes/data",
 "o": "bind",
 "type": "none"
 },
 "Scope": "local"
 }
]

Un volume nommé vol_data est à présent disponible pour un conteneur.

Utilisation du volume docker

Avec docker run

Pour utiliser ce volume docker avec docker run , comme avec un volume docker "classique", utiliser l'option --volume vol_data:/data. Cela montera le volume docker "vol_data" précédement créé dans le point de montage "/data" du conteneur.

Avec docker compose

Pour utiliser ce volume docker dans un docker-compose.yml, c'est comme un volume classique :

version: '3'
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 "Volumes" de l'interface web. Si vous créez vos conteneurs, services, stacks swarm sur Portainer, vous pourrez l'utiliser sans problème.

Toutefois, il est impossible de créer ce genre de volume via l'interface web de portainer.

Attention cependant au nom du volume que vous lui donner lors de sa création.

Par exemple, je souhaite utiliser un volume docker (qui finalement sera de type bind) dans une stack swarm qui s'appelle "webapp". Lors de la création du volume, je le nommerai "webapp_vol_data" et dans mon fichier yaml de la stack, j'appelerai ce volume uniquement "vol_data".

Si le volume utilisé dans un docker-compose n'est pas bien définit au niveau du nommage, un volume docker "standard" sera alors automatiquement créer à la place et celui-ci sera dans /var/lib/docker/volumes.

Donc 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 !

Debian : Optimisez votre distribution avec Tuned

Thu, 07 Sep 2023 00:56:00 +0200

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.

Installation 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 :

sudo apt install tuned

Une fois l'installation terminée, vous pouvez activer et configurer Tuned.

Service

Tuned déploie son propre service. Pour en consulter son status, exécutez la commande suivante :

sudo systemctl status tuned.service

Le service est activé par défaut :

● 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 :

sudo tuned-adm list

Les profils disponibles seront :

Available 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 :

sudo tuned-adm profile <nom-du-profil>

Remplacez <nom-du-profil> par le nom du profil que vous souhaitez utiliser. Par exemple, si vous souhaitez activer le profil "throughput-performance", exécutez la commande suivante :

sudo tuned-adm profile throughput-performance

Vous pouvez obtenir le profil recommandé par l'application avec la commande suivante :

sudo 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é "mon-profil", vous pouvez créer un fichier de configuration /etc/tuned/mon-profil/tuned.conf.

Voici un exemple de fichier de configuration Tuned pour un profil personnalisé :

[main]
include=throughput-performance

[cpu]
governor=performance

[sysctl]
vm.dirty_ratio=10

Ce fichier de configuration active d'abord le profil "throughput-performance" en utilisant l'instruction include. Ensuite, il définit le gouverneur du CPU sur "performance" pour maximiser les performances du processeur. Enfin, il ajuste un paramètre de sysctl pour contrôler la gestion de la mémoire.

Aprè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.

Conclusion

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.

N'hésitez pas à explorer davantage les possibilités de Tuned et à l'adapter à vos besoins pour obtenir des performances optimales sur votre serveur Debian.

Watch Tower : Auto update docker images

Tue, 11 Apr 2023 08:04:46 +0200

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.

La documentation complète peut être accessible ici : https://containrrr.dev/watchtower/

Installation

L'installation est très simple car Watch Tower va tourner lui-même en conteneur.

Je vais utiliser un fichier docker-compose.yml pour exécuter l'application :

version: '3.8'
services:
 watchtower:
 image: containrrr/watchtower:latest
 container_name: watchtower
 restart: unless-stopped
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 command: --schedule "0 0 4 * * *" --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.

D'autres options sont disponibles (Se référer à la documentation précisée en introduction).

Exécution

Lancer simplement le docker-compose.yml :

docker-compose up -d

Network : Désactiver l’IPv6 sur Debian

Fri, 03 Feb 2023 14:40:24 +0100

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

Scripting bash : Couleurs / Styles texte

Tue, 06 Dec 2022 18:13:55 +0100

Couleurs

Variables

neutre='\e[0;m'
noir='\e[0;30m'
gris='\e[1;30m'
rougefonce='\e[0;31m'
rose='\e[1;31m'
vertfonce='\e[0;32m'
vertclair='\e[1;32m'
orange='\e[0;33m'
jaune='\e[1;33m'
bleufonce='\e[0;34m'
bleuclair='\e[1;34m'
violetfonce='\e[0;35m'
violetclair='\e[1;35m'
cyanfonce='\e[0;36m'
cyanclair='\e[1;36m'
grisclair='\e[0;37m'
blanc='\e[1;37m'

Utilisation

echo -e "${rougefonce}Hello${neutre} ${jaune}World${neutre}"

-e : enable interpretation of backslash escapes

Styles

Variables

normal='\033[0m'
gras='\033[1m'
fin='\033[2m'
italic='\033[3m'
souligne='\033[4m'
flash='\033[5m'
inverse='\033[7m'
invisible='\033[8m'

Utilisation

echo -e "${gras}Hello${normal} ${flash}World${normal}"

-e : enable interpretation of backslash escapes

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 2/2]

Fri, 18 Nov 2022 15:17:42 +0100

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.

Configuration IP

1er démarrage

Lors du 1er démarrage de l'instance OPNsense, un écran similaire à celui-ci est affiché :

L'adressage IP des différentes interfaces réseaux est à paramétrer.

Attention à 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 :

vtnet0 = 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.

Login : root
Password : opnsense

Le menu d'administration de la console est maintenant disponible :

Assignation 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.

Faire 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é :

The interfaces will be assigned as follows :
WAN -> vtnet0
LAN -> 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.

Paramétrage IP

Avant d'aller plus loin, il va falloir récupérer quelques informations sur l'instance :

L'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 :

IP 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 :

Faire 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.

Maintenant, passer au paramétrage de l'interface LAN:

Refaire 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.

Interface 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.

Dans 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.

Pour se faire, dans la console VNC de l'instance :

Faire 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.

Il est maintenant possible de se connecter à l'interface web d'administration d'OPNsense à travers l'interface WAN.

Se 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.

Filtrage

Pour accéder à la page d'administration d'OPNsense, le pare-feu a été désactivé pour effectuer la 1ère connexion.

Rappel : A chaque rechargement de configuration, le pare-feu sera réactivé automatiquement.

Idéalement, il faut définir une seule adresse IP (ou plusieurs) qui sera autorisée à y accéder.

Tout d'abord, créer un alias afin de mieux identifier l'hôte qui sera autorisé à se connecter à l'interface web d'administration.

Se 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.

Ensuite, ajouter une règle sur l'interface WAN du pare-feu.

Se 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.

Pour être sûr et certain que le pare-feu soit bien actif :

Se rendre dans la console VNC de l'instance et exécuter la commande :

pfctl -e

Le shell doit renvoyer :

pfctl: 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.

Se 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é.

Hostname, Timezone…

Il peut être intéressant de modifier le nom d'hôte, le domaine, ou bien la timezone d'OPNsense.

Se rendre dans System (1), Settings (2), General (3)

Sécurité

Sujet très vaste !

Je vais m'attarder sur 2 points principaux :

La 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.

Se 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.

En bas de cette page, un bouton Update sera disponible. Il sera également indiqué si un redémarrage d'OPNsense est requis.

Certificat SSL Let’s Encrypt

Installation du client

La 1ère étape à réaliser est l'installation du client acme.

Se 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.

Se 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.

Création du compte Let’s Encrypt

Ensuite, un compte doit être créé et enregistré pour la génération du certificat chez Let's Encrypt.

Se 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).

Enregistrement 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.

Par exemple :

opnsense-demo.example.com. IN A xxx.xxx.xxx.237

xxx.xxx.xxx.237 = IP publique de l'interface WAN d'OPNsense

Bien vérifier que cet enregistrement a été répercuté sur les serveurs DNS de Google (Let's Encrypt s'appuie dessus).

Dans votre terminal GNU/Linux :

dig opnsense-demo.example.com @8.8.8.8

Il est également est possible de vérifier l'enregistrement à cette adresse : https://dns.google

Paramétrage du challenge

Une fois cet enregistrement fait et vérifié, paramétrer un type de challenge :

Se 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

Valider 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é.

Se 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.

Génération du certificat

Maintenant, un certificat peut être généré :

Se 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.

Valider 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é).

Se 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).

Valider avec le bouton Save

Et voilà !

Il 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.

En suivant l'exemple donné ici, l'accès se fera sur l'URL : https://opnsense-demo.example.com (Adresse fictive pour l'article !).

Rocket.Chat : Installation standalone

Tue, 04 Oct 2022 18:08:56 +0200

Installation d'un Rocket.Chat en mode standalone sur Debian 11.

Très important ! MongoDB 5.0 demande que le jeu d'instruction AVX soit géré par le CPU du serveur.

Vé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.

Pour mes essais, j'utilise un serveur Proxmox pour la virtualisation. J'ai dû passer le CPU de la machine virtuelle sur host.

MongoDB 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.

Installer 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 'deb [signed-by=/usr/share/keyrings/mongodb.gpg] http://repo.mongodb.org/apt/debian buster/mongodb-org/5.0 main' | 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.

Mettre à 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 :

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-database hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongodb-mongosh hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Configuration

Editer le fichier de configuration /etc/mongod.conf :

sudo vi /etc/mongod.conf

Attention, c'est un format YAML.

Définir le type de stockage sur wiredTiger :

storage:
 engine: wiredTiger

Activer et nommer la réplication :

replication:
 replSetName: rs01

Le fichier de configuration doit ressembler à quelques choses de similaire à ça :

storage:
 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.

Démarrer MongoDB :

sudo systemctl start mongod

Si une erreur indique que mongod.service est introuvable :

sudo 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 "printjson(rs.initiate())"

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.

Se 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 && 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 << 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.

Nextcloud : Add-in Outlook pour l’envoi de gros fichiers par mail sans effort

Thu, 29 Sep 2022 08:00:31 +0200

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.

Cet add-in permet :

D'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 :

Dé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 :

Free
Basic
Professional
Premium

Détails des différentes versions : https://nextcloud.com/outlook/

Ici, je vais utiliser la version Free. Cette version est limité à 50 utilisateurs.

Installation

Côté Nextcloud, il n'y a rien à faire 🙂

Sur 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.

Lien vers les add-ins : https://download.nextcloud.com/outlook/

Sur un Windows 10 64 bits, j'ai pris celui-ci : https://download.nextcloud.com/outlook/20190410/Setup_23117_x64_free.msi

Configuration

Au 1er lancement d'Outlook, il est demandé de renseigner les paramètres du compte Nextcloud à lié au client de messagerie.

Renseigner l'URL du serveur Nextcloud.

Ne surtout pas cliquer sur Connect.

Cliquer 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.

Ici dans la version Free :

L'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.

Par exemple :

L'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) :

Lors 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 :

Le 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) :

Lors 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.

Recommandation

Une utilisation abusive, avec de très gros fichiers, peut provoquer une surcharge au point de vue stockage sur le serveur Nextcloud.

De ce fait, il est important de définir une purge régulière des fichiers envoyés.

Du point de vue serveur, les données sont organisées ce cette façon :

www-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 :

Outlook
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...

Si cette méthode est employé :

Ré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 |
+---------+-------+--------------+

OPNsense : Déploiement d’une instance sur OVHcloud [Partie 1/2]

Fri, 23 Sep 2022 08:00:46 +0200

Dans cet article je vais décrire comment installer une instance sous OPNsense au sein d'OVHcloud.

Par défaut, il n'est pas possible de déployer une image OPNsense lors de la commande d'une instance sur OVHcloud.

En effet les distributions disponibles sont :

AlmaLinux
RockyLinux
CentOS
Debian
Fedora
Ubuntu

Pourtant, on peut très bien déployer un système complet OPNsense (FreeBSD) nativement sur une instance OVHcloud.

Un vRack sera déployé pour la partie LAN d'OPNsense.

Préparation de l’instance OVHcloud

Contexte

Voici un schéma simplifié du contexte de déploiement de l'OPNsense :

L'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’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.

Dans 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...

Une fois déployé et disponible, ce vRack apparait dans la liste des réseaux privés disponible avec la plage d'adresse attribuée.

Création de l’instance

Maintenant que le vRack est déployé, une nouvelle instance peut être créée.

Dans 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.

Installation 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.

En 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).

L'ISO d'OPNsense fait 1,3 Go

Il 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.

De celle que j'ai testé, c'est la Debian 9 qui est la plus approprié pour la suite des manipulations.

Dans 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.

Se 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’ISO d’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.

Vé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 :

Filesystem 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.

Se 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é).

Démarrage de l’installation d’OPNsense

A partir de maintenant, il est maintenant possible de se connecter en VNC sur 127.0.0.1:5900.

2 possibilités sont offertes lors du démarrage :

Boot 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.

Sé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 :

Après quelques instants votre instance démarrera normalement sur son disque principal avec le chargement d'OPNsense.

Configuration OPNsense

Pour procéder à la 1ère configuration de la solution OPNsense :

Se 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.

YubiKey : Paramétrage authentification Linux

Fri, 16 Sep 2022 04:28:23 +0200

Configuration d'une clef YubiKey Bio (FIDO Edition) sous Pop!_Os 22.04 pour l'authentification :

En mode graphique (Gnome)
En mode console
Avec sudo

Product : https://www.yubico.com/fr/product/yubikey-bio/

L'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.

Si la clef n'est pas présente / détectée ou que la reconnaissance de l'empreinte échoue, le mot de passe sera demandé.

Il 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).

Configuration 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’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.

Copier 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.

Editer 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.

Mettre à 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.

Authentification en mode graphique

Pour permettre l'utilisation de la YubiKey pour s'authentifier à l'environnement graphique (Gnome).

Editer 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.

Editer 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.

Editer 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.

Editer 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.

Docker-Compose : Drawio

Mon, 12 Sep 2022 07:24:05 +0200

Le fichier docker-compose.yml

version: '3.3'
services:
 drawio:
 image: jgraph/drawio
 container_name: drawio
 ports:
 # http://localhost:8080
 - 8080:8080
 # https://localhost:8443
 - 8443:8443

Execution

docker-compose up -d

Docker Swarm : Stack Drawio

Mon, 12 Sep 2022 07:21:23 +0200

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: '3.3'

services:
 drawio:
 image: jgraph/drawio
 networks:
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 labels:
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer l'URL d'accès à l'application
 - traefik.http.routers.drawio-http.rule=Host(<code>url.application.com</code>)
 - traefik.http.routers.drawio-http.entrypoints=http
 - traefik.http.routers.drawio-http.middlewares=https-redirect
 # Indiquer l'URL d'accès à l'application
 - traefik.http.routers.drawio-https.rule=Host(<code>url.application.com</code>)
 - 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

Docker-Compose : OpenVAS

Sun, 04 Sep 2022 22:36:59 +0200

Le fichier docker-compose.yml

version: '3.7'
services:
 openvas:
 image: immauss/openvas
 container_name: openvas
 environment:
 # Indiquer un MotDePasseTresSecure or play with env'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

Docker Swarm : Stack OpenVAS

Sun, 04 Sep 2022 12:16:16 +0200

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: '3.3'

services:

 app:
 image: immauss/openvas
 environment:
 # Indiquer un mot de passe pour le compte admin de l'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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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'URL de l'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'URL de l'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

Docker-Compose : OpenProject

Thu, 25 Aug 2022 11:55:11 +0200

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: '3.3'

services:

 openproject:
 image: openproject/community:12
 environment:
 OPENPROJECT_HOST__NAME: localhost:8080
 OPENPROJECT_HTTPS: "false"
 # head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 ; echo ''
 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

Keycloak : Federation d’un annuaire LDAPS (Active Directory)

Tue, 23 Aug 2022 15:10:58 +0200

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.

Testé avec un domaine Active Directory On-Premises et avec Azure Active Directory.

Contexte de l’infrastructure

L'infrastructure sur laquelle je vais m'appuyer est la suivante :

1 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.

Récupération du certificat

Pour commencer, il va falloir récupérer le certificat TLS utilisé pour la liaison LDAPS.

LDAP = 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) :

openssl s_client -connect dc01.aukfood.lan:636

Voici le retour pour cette infra :

depth=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 :

cat <<EOF > 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.

Tout d'abord, installer openjdk-11-jre :

sudo apt install openjdk-11-jre

Puis importer le certificat server-ldaps.cer dans un keystore nommé keystore.jks :

keytool -import -trustcacerts -alias dc01.aukfood.lan-CA -file server-ldaps.cer -keystore keystore.jks

Saisir un mot de passe à appliquer au keystore :

Entrez 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é :

keytool -list -keystore keystore.jks

Après avoir entrer le mot de passe du keystore, le certificat est bien présent :

Entrez 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'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é.

Dans 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.

Envoyer le keystore précédement généré dans le conteneur :

docker cp ./keystore.jks $(docker ps -qf name=keycloak):/opt/keycloak/conf/

Puis ajouter les variables suivantes sur la stack de keycloak :

services:
 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.

Lister les stacks dans docker swarm :

docker stack ls

Identifier l'ID du service docker exécutant

NAME 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.

Supprimer la stack keycloak :

docker stack rm keycloak

Puis relancer la stack kycloak pour prendre en compte les nouvelles variables d'environnement concernant le truststore :

docker 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.

Logs

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.

Pour cela, lister les services en cours au sein du cluster docker :

docker service ls

Identifier le service adéquat (ici : keycloak_app) :

ID 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 :

docker 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.

User federation

Sélectionner le royaume adéquat ou en créer un nouveau (1), puis se rendre sur User federation (2) :

Ajouter un fournisseur LDAP :

Note : 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/

Tous les paramètres de synchronisation y sont traités :

Gestion 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 "Common Name" du certificat. Celui-ci peut être identifié lors de l'utilisation de la commande openssl au début de cet article.

(2) Use Truststore SPI : Indiquer l'utilisation du truststore javax.net.ssl.trustStore (pour le keystore.jks) uniquement pour ldaps.

(3) Bind DN : Indiquer le DistinguishedName de l'utilisateur de l'annuaire qui sera utilisé par Keycloak. Pour le récupérer facilement :

Get-ADUser UTILISATEUR_AD | FT DistinguishedName

(4) Bind credentials : Mettre le mot de passe de l'utilisateur indiqué au point précédent.

A noter que pour le moment, il manque des informations dans le paramétrage de la liaison LDAPS. De ce fait, le "Test connection" et le "Test authentication" ne sont pas encore réalisables (Une des différences avec les versions de Keycloak sous Wildfly en version 16 et inférieure).

LDAP searching and updating

(1) Edit mode : Définir le mode d'édition de l'annuaire.

(2) Users DN : Indiquer le DistinguishedName de l'OU contenant les utilisateurs à fédérer.

Tests et import utilisateurs

Il est maintenant possible de tester la connexion LDAPS et l'authenfication.

Ces 2 tests doivent aboutir :

Ensuite, 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 :

L'importation des utilisateurs aboutie :

Dans les utilisateurs du royaume Keycloak, je retrouve bien les utilisateurs contenus dans l'OU définit dans la fédération.

Mappers

Dans ce contexte, l'utilisateur "Julien LOUIS", 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.

Pour voir tous les utilisateurs du royaume keycloak (fédération incluse), rechercher ***** comme utilisateur.

De plus, pour l'utilisateur final, cela ne correspondra pas au login auquel il est habitué d'utiliser.

Pour modifier ce comportement, il faut mapper l'attribut sAMAccountName de l'anuaire Active Directory vers l'attribut username de Keycloak.

Se 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) :

Modifier le champ LDAP Attribute pour y inscrire sAMAccountName :

Puis, enregistrer la modification en bas de page.

Ensuite, dans l'onglet Settings, modifier l'Username LDAP attribute en y inscrivant sAMAccountName :

Puis, enregistrer la modification en bas de page.

En relançant la synchronisation de tous les utilisateurs de l'annuaire vers Keycloak, les utilisateurs sont mis à jour :

A présent, le login des utilisateurs importés dans Keycloak est correctement paramétré.

Docker Swarm : Stack Keycloak (v19 latest)

Mon, 22 Aug 2022 10:39:09 +0200

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: '3.3'

services:

 app:
 image: quay.io/keycloak/keycloak:latest
 security_opt:
 - no-new-privileges:true
 command: start-dev
 environment:
 PROXY_ADDRESS_FORWARDING: "true"
 KC_FEATURES: token-exchange
 KC_PROXY: passthrough
 KEYCLOAK_ADMIN: admin
 # Indiquer un mot de passe pour le compte admin sur l'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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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'URL de l'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'URL de l'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

Docker Swarm : Stack Nextcloud

Thu, 18 Aug 2022 13:00:13 +0200

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: '3.3'

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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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'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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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'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'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'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

Docker Swarm : Stack Keycloak (v16 depreciated)

Thu, 18 Aug 2022 11:47:44 +0200

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/

Fichier stack.yml

version: '3.3'

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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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: 'true'
 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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Modifier le domaine de l'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'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

Docker Swarm : Stack Rocket.Chat

Thu, 18 Aug 2022 11:34:33 +0200

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: '3.3'

services:

 rocketchat:
 image: registry.rocket.chat/rocketchat/rocket.chat:latest
 environment:
 MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
 MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
 # Modifier l'URL d'accès à l'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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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'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'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: "true"
 ALLOW_EMPTY_PASSWORD: "yes"
 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: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #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

Docker Swarm : Stack Traefik

Thu, 18 Aug 2022 11:28:10 +0200

Export variables

export EMAIL=mon@email.com
export DOMAIN=traefik.example.com
export USERNAME=admin
export PASSWORD=MotDePasseTresSecure
export HASHED_PASSWORD=$(openssl passwd -apr1 "$PASSWORD")

Fichier stack.yml

version: '3.3'

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 "traefik.constraint-label=traefik-public"
 # 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 "le" (Let'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 "traefik.constraint-label=traefik-public"
 - --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 "http" listening on address 80
 - --entrypoints.http.address=:80
 # Create an entrypoint "https" listening on address 443
 - --entrypoints.https.address=:443
 # Create the certificate resolver "le" for Let's Encrypt, uses the environment variable EMAIL
 - --certificatesresolvers.le.acme.email=${EMAIL?Variable not set}
 # Store the Let's Encrypt certificates in the mounted volume
 - --certificatesresolvers.le.acme.storage=/certificates/acme.json
 # Use the TLS Challenge for Let'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'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 "traefik-public", 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

Docker-Compose : Portainer Agent

Mon, 15 Aug 2022 16:55:25 +0200

docker-compose.yml

version: '3'

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

Terminal: Fix broadcast command twice in Terminator

Mon, 15 Aug 2022 16:46:56 +0200

Contexte

Avec le logiciel terminator, il peut arriver que le broadcast de commande double les caractères tappés sur le clavier.

Exemple :

Dans mon contexte, je suis avec la version de terminator 2.1.1 fournit par les dépôts de Pop_OS 22.04.

Fix terminator

Pour corriger ce phénomène, j'ai édité le script de terminator.

Tout d'abord :

Où 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 :

"""Modifi broadcast twice"""
os.environ['DBUS_SESSION_BUS_ADDRESS']=''
"""End of modify broadcast twice"""

Enregistrer les modifications
Relancer terminator

Vérification

Le broadcast de commande dans terminator est maintenant pleinement fonctionnel 🙂

Docker-Compose : Portainer Server

Sat, 13 Aug 2022 17:53:08 +0200

docker-compose.yml

version: '3'

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

Pop!_OS 22.04 : Fix apt

Tue, 02 Aug 2022 10:10:08 +0200

#!/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

OPNsense : Configuration d’un VPN SSL Road Warrior avec PKI

Tue, 12 Jul 2022 23:21:48 +0200

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é.

Le 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.

Une autorité de certification sera créé pour délivrer un certificat afin de sécuriser les échanges.

Un exemple de configuration d'un client sous Windows 10 est traité à la fin.

Let's go !!!

Contexte

Voici la version utilisée d'OPNsense :

OPNsense 22.1.2_2-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

Au niveau des interfaces de paramétrées :

LAN = 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.

Tout le paramétrage sera à réaliser à travers l'interface web d'administration d'OPNsense.

PKI

Création de l’authorité de certification

Dans System (1), Trust (2), Authorities (3), cliquer sur + (4) pour ajouter une authorité de certification :
Sélectionner Create an internal Certificate Authority :

Je 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.

Entrer une Descriptive name ainsi que le Common Name et les informations désirées.
Enregistrer la nouvelle authorité de certification :

Génération du certificat serveur

Dans Certificates (1), cliquer sur + (2) pour ajouter un nouveau certificat :
Sélectionner Create an internal Certificate :

Même remarque que précédement concernant la partie algorithme, clef...

Entrer une Descriptive name. Sélectionner le bon Certificate authority et le type Server Certificate.
Les informations provenant de l'authorité de certification doivent être pré-remplies.
Renseigner le Common Name :
Enregistrer le nouveau certificat :

OpenVPN

Dans VPN (1), OpenVPN (2), Servers (3), cliquer sur l'icône du Wizard (4) :

En 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.

Type de serveur d'authentification : Local User Access
Authorité de certification : OPNsense-CA
Certificat : OPNsense-VPN-Cert
Dans la partie General OpenVPN Server Information, renseigner les paramètres suivants :
Les 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).
Dans la partie Tunnel Settings, renseigner les paramètres suivants :
Dans IPv4 Tunnel Network, entrer le réseau virtuel qui sera attribué aux clients VPN.
Dans IPv4 Local Network, entrer le réseau LAN qui doit être accessible aux clients VPN.

Le 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.

Passer à la prochaine étape en cliquant sur Next.
Cocher Firewall Rule et OpenVPN Rule pour générer les 2 règles adéquats dans le pare-feu :
Valider en cliquant sur Next puis Finish pour terminer le paramétrage du serveur VPN.

Utilisateur

Création d’un utilisateur

Dans System (1), Access (2), Users (3), cliquer sur + (4) pour ajouter un nouveau utilisateur :
Renseigner un Username et un Password :
Plus bas, cocher Click to create a user certificate :
Terminer en cliquant sur Save. Cela déclenche la génération d'un certificat.

Génération du certificat utilisateur

Sélectionner Create an internal Certificate :
Entrer une Descriptive name. Sélectionner le bon Certificate authority et le type Client Certificate.
Les informations provenant de l'authorité de certification doivent être pré-remplies.
Renseigner le Common Name.
Enregistrer le nouveau certificat.
Le certificat est maintenant associé à l'utilisateur :
Terminer en cliquant sur Save.

Client 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 :

En 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é.

Le contenu de l'archive récupérée contient les éléments suivant :

OPNsense_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 :

Télécharger le client OpenVPN Community : https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.7-I602-amd64.msi
Installer le client OpenVPN (Attention, il faudra des droits d'administrateur sur le poste Windows).
Un message d'avertissement indique qu'il n'y a aucun profil de connexion.
Copier le contenu de l'archive préalablement exporter dans le répertoire %USERPROFILE%\OpenVPN\config :
Se connecter :
Un message peut survenir indiquant que l'utilisateur Windows doit faire partie du groupe local de la machine OpenVPN Administrators :

Si contexte de domaine, une GPO peut appliquer ce paramètre automatiquement.

S'identifier avec le compte utilisateur créé précédement dans OPNsense :
La connexion VPN est établie :

Nextcloud : Intégration d’une authentification SSO avec AD FS

Fri, 08 Jul 2022 12:00:33 +0200

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.

Cela 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.

Environnement

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’s Encrypt

A effectuer sur le serveur Windows (Tous les services seront déployés sur le contrôleur de domaine) :

Installation de IIS en Powershell :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Faire un enregistrement de type A dans une zone DNS publique pour le serveur IIS :
```
adfs2-dev IN A xxx.xxx.xxx.xxx
```
Dans ce PoC, le domaine publique utilisé sera example.com.
Créer la racine du site web pour résoudre le challenge :
```
mkdir c:\inetpub\adfs2-dev.example.com
```
Créer un fichier index.html dans la racine du site web :
```
notepad c:\inetpub\adfs2-dev.example.com\index.html
```
Insérer le contenu suivant puis enregistrer :
```
Hello world
```
Ouvrir la console de Gestionnaire des services Internet (IIS).
Supprimer le site web par défaut.
Ajouter un nouveau site web :
Télécharger le client ACME pour Let's Encrypt ici : https://www.win-acme.com/

A 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
Décompresser l'archive et déplacer le fichier Web_Config.xml à la racine du site web.
Redémarrer le site web.
Lancer une ligne de commandes et se positionner dans le répertoire préalablement extrait.
Exécuter wacs.exe :
Créer un nouveau certificat (Choix N).
Sélectionner le site ajouté au préalable dans IIS :
Peu importe si le certificat est de type wildcard ou non.
Le certificat est généré avec une tâche planifiée qui va renouveller le certificat automatiquement :
Une liaison https (vhost) a été automatiquement générée pour le site web :
Ce certificat est celui qui sera exploité par le service AD FS.

Exportation du certificat au format pfx

Re-lancer l'outil wacs.exe.
Faire le choix A (Manage renewals) :
Afficher les détails avec D, puis noter le .pfx password :

Ouvrir le dossier des certificats Let's Encrypt :

explorer 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) :
Saisir le mot de passe de la clé privée (.pfx password noté au préalable) et cocher Marquer cette clé comme exportable :
Sélectionner automatiquement le magasin de certificats.
Terminer l'assistant d'importation du certificat.
Ouvrir la gestion des certificats de l'ordinateur local :
```
certlm.msc
```
Dans "Personnel\Certificats" (1), sélectionner le certificat préalablement importé (2). Dans "Toutes les tâches" (3), sélectionner "Exporter" (4) :
Il est maintenant possible d'exporter la clé privée du certificat :
Exporter toutes les propriétés étendues :
Saisir un mot de passe pour protéger la clé privée :
Spécifier le nom du fichier à exporter au format pfx.
Terminer l'assistant d'exportation du certificat.

Installation AD FS

Installer le service ADFS-Federation en Powershell :

Install-WindowsFeature -name ADFS-Federation -IncludeManagementTools

Créer la clé racine du service de distribution de clés en Powershell :
```
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
La configuration du service se fera en mode graphique à travers le gestionnaire de serveur servermanager.exe :
Créer le premier serveur de fédération dans une batterie de serveurs de fédération.
Importer le certificat préalablement exporté au format .pfx (1). Puis, entrer un nom pour le service FS (2) :
Spécifier un compte de service :
Une base de données SQL Server peut être exploitée. Dans ce PoC, une base de données interne Windows est utilisée.
Après examen des options, la configuration peut être lancée :
Redémarrer le serveur Windows.

Activer la page de login de l'ADFS en Powershell :

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

Tester la connexion : https://adfs2-dev.example.com/adfs/ls/IdpInitiatedSignon.aspx

Paramétrage Nextcloud

Se connecter en SSH sur le serveur Nextcloud et se positionner à la racine du projet web :
```
cd /var/www/nc-dev.example.com/www/
```

Installer l'application user_saml avec occ (A adapter selon le propriétaire du projet web) :

sudo -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.
Se rendre dans "Paramètres" (1) / "Authentification SSO & SAML" (2). Puis "Utiliser l'authentification SAML intégrée" (3) :
Dans la partie "Général", entrer l'Attribut pour relier l'UID :
```
http://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.
Configurer les options IdP :
- Identifiant de l'entité IdP : http://adfs2-dev.example.com/adfs/services/trust
- URL cible du fournisseur d'identités à qui le fournisseur de service enverra la requête d'authentification : https://adfs2-dev.example.com/adfs/ls
Cliquer sur "Hide optional Identity Provider settings" pour accéder au champ Certificat public X.509 de l'IdP.
Sur le serveur Windows, ouvrir la console de gestion de l'ADFS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Dans "Service" / "Certificats" (1), Afficher le certificat (2) utilisé pour la signature de jetons :
Dans l'onglet "Détails", copier dans un fichier :
Exporter au format : *X.509 encodé en base 64 (.cer)**
Spécifier un nom de fichier pour l'export.
Copier le contenu de ce fichier exporté au format .cer et le coller dans le champ Certificat public X.509 de l'IdP dans Nextcloud :
Mapper les attributs suivants au minimum :
- Attribut 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 :
Pour avoir la possibilité de garder l'authentification avec la base utilisateur interne de Nextcloud, cocher Autoriser l'utilisation de plusieurs systèmes d'authentification :

Bien vérifier l'enregistrement du paramétrage en quittant le menu "Authentification SSO & SAML" et en y revenant (Surtout sur le paramétrage du point précédent).

Paramétrage AD FS

Sur le serveur Windows, ouvrir la console de gestion de l'AD FS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Ajouter une approbation de partie de confiance :
Prendre en charge les revendications.
Importer les données concernant la partie de confiance à partir du fichier metadata.xml téléchargé préalablement :
Saisir un nom pour cette approbation et éventuellement des notes.
Sélectionner une stratégie de contrôle d'accès. Dans ce PoC, tout le monde sera autorisé :
La partie de confiance a été configurée à l'aide du fichier metadata.xml fourni.
Editer la stratégie d'émission de revendication :
2 règles de revendication de transformations sont à ajouter au minimum :
- userPrincipalName
- Email
Le modèle de régle de revendication à suivre est : Envoyer les attributs LDAP en tant que revendications.
Règle userPrincipalName :
Règle Email :
Appliquer les 2 règles ajoutées.

Vérification de l’authentification

Se connecter à Nextcloud, et choisir de s'authentifier au travers une Connection SSO & SAML :
Utiliser un compte de l'Active Directory autoriser à se connecter à travers l'AD FS :
Congratulations !

Ressources en vrac

Nextcloud : Importer ses données de Google

Thu, 16 Jun 2022 08:00:16 +0200

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 :

Les agendas
Les contacts
Les photos
Les fichiers

Pour se faire, plusieurs APIs Google vont être exploitées.

Google integration

Se connecter en admin sur l'interface web du Nextcloud.
Rechercher, télécharger, installer l'application Google integration.
Dans 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.
Cliquer 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.
S'identifier avec un compte Google sur la Google Cloud Platform.

Ce compte Google sera exploité uniquement pour l'API Google.

Google Cloud Platform

Projet

Créer un nouveau Projet.
Nommer le projet (1). Puis, valider (2).

Consentement

Dans Ecran de consentement OAuth (1), définir le type d'utilisateur (2). Puis, valider (3).
Entrer le nom de l'application demandant l'autorisation (1) ainsi que l'adresse mail d'assistance (2).

Il est possible de spécifier un logo qui apparaitra sur la page de consentement lorsque l'utilisateur saisira ces informations de compte Google.
Tout en bas de la page, indiquer vos coordonnées de développeur. Puis Enregistrer et continuer.
Sur l'écran suivant, Enregistrer et continuer tout en bas de la page.
A 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.
Un résumé de l'écran de consentement paramétré est afficher.

Identifiants

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.

Dans le menu API et services à gauche, se rendre dans Identifiants (1). Créer des identifiants (2) de type ID client OAuth (3).
Renseigner 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).
l'ID client et le code secret du client sont disponible.
Retourner sur l'interface web de Nextcloud dans la partie Intégration de Google. Puis, indiquer l'ID client (1) et le Secret client (2).

API

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.

Une 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.

Si aucune données n'est présente dans une des fonctionnalités Google, celle-ci ne sera pas proposée à l'import.

SSH : SSHS, une interface utilisateur pour SSH dans le terminal

Wed, 15 Jun 2022 10:21:30 +0200

Contexte

Je suis tombé par hasard sur ce projet : https://github.com/quantumsheep/sshs

Celui-ci permet d'avoir une interface utilisateur pour SSH dans un terminal.

Il y a également la possibilité d'effectuer des recherches.

Installation

Il est possible d'avoir SSHS sous Windows, Mac, Linux.

Dans mon cas, je travaille sous Pop!_OS, j'ai réalisé l'installation à partir des sources.

Avant tout chose, il faut installer le compilateur pour Go pour Golang.

Pour ma part, je l'ai faites avec snap :

snap install go --classic

Ensuite, j'ai cloné le projet avec git :

git clone https://github.com/quantumsheep/sshs.git

Puis, j'ai compilé les sources et installé SSHS :

cd sshs
make
make install

Réaliser l'installation avec make install en tant que root.

Il est maintenant possible de lancer le programme avec la commande :

sshs

Utilisation

Il n'y a pas de manuel avec la commande sshs.

Sans auncun argument, SSHS va charger le fichier ~/.ssh/config (et éventuellement les Include dedans).

Cependant, il y a quelques options possibles que l'on peut obtenir avec :

sshs --help

Voici le retour de l'aide succinte :

ssh clients manager

Usage:
 sshs [flags]

Flags:
 -c, --config string SSH config file (default "~/.ssh/config")
 -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

Nextcloud : Ajouter un calendrier Google privé (Sans credentials)

Thu, 09 Jun 2022 08:00:00 +0200

Contexte

Le but est d'ajouter un calendrier Google (Google Agenda) dans les calendriers d'un utilisateur Nextcloud.

Le calendrier Google restera privé et ne passera donc pas en publique.

De plus, il ne sera accessible qu'en lecture. C'est comme ça...

Attention : 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).

Cô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'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 "Copier" 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.

Cô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.

https://docs.nextcloud.com/server/19/user_manual/pim/calendar.html

Subscriptions are refreshed every week by default. Your admin may have changed this setting.

Modifier le taux de rafraîchissement :

Se connecter avec un terminal en root à l'instance Nextcloud.

Se positionner à la racine du site Nextcloud.

cd /var/www/nextcloud.example.com/www/ # Par exemple

Obtenir le propriétaire du fichier config.php.

ls -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.
```
sudo -u nextcloud php8.0 occ config:app:set dav calendarSubscriptionRefreshRate --value "PT5M"
# 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.

sudo -u nextcloud php8.0 occ config:list | grep -i calendar
# Résultat :
# "calendar": {
# "calendarSubscriptionRefreshRate": "PT5M",

Crontab

Editer la crontab de l'utilisateur étant propriétaire du fichier config.php vu précédemment.
```
sudo -u nextcloud crontab -e
```
Ajouter une tâche toutes les 5 minutes exécutant le script php situé à la racine du site Nextcloud.
```
*/5 * * * * php8.0 -f /var/www/nextcloud.example.com/www/cron.php
```
Utiliser le binaire php correspondant à la version du Nextcloud.
Se connecter en admin sur l'interface web de Nextcloud. Puis se rendre dans Paramètres.
Dans la section Administration en bas à gauche, se rendre dans Paramètres de base.
S'assurer que les Tâches de fond soient configurées avec Cron.

Sources

WordPress : Fix WP-Optimize (VPO_Page-Cache not found)

Sat, 04 Jun 2022 13:34:42 +0200

Contexte

WordPress 6.0
WP-Optimize 3.2.5

Avec le module WP-Optimize, il peut se produire l'erreur suivante :

[Fri Jan 21 15:48:12.414615 666] [proxy_fcgi:error] [pid 5281:tid 140595150419712] [client 156.251.145.63:37469] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Class "WPO_Page_Cache" 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('...')\n#3 /var/www/blog.example.com/www/wp-settings.php(95): include('...')\n#4 /var/www/blog.example.com/www/wp-config.php(81): require_once('...')\n#5 /var/www/blog.example.com/www/wp-load.php(50): require_once('...')\n#6 /var/www/blog.example.com/www/wp-blog-header.php(13): require_once('...')\n#7 /var/www/blog.example.com/www/index.php(17): require('...')\n#8 {main}\n thrown in /var/www/blog.example.com/wp-content/plugins/wp-optimize/cache/file-based-page-cac...', referer: https://blog.example.com/blablablabla...

Cela peut se produire lors de l'installation ou bien lors d'une mise à jour manuelle / automatique.

Fix

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('WP_CACHE', true); // WP-Optimize Cache

Re-Install

Le module WP-Optimize peut être réinstallé dans les extensions du site WordPress.

Nextcloud : Group Folders

Thu, 05 May 2022 08:00:20 +0200

Contexte

Nextcloud est orienté utilisateurs.

C'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.

Un exemple concret :

Un utilisateur nommé "Jean-Jacques" possède une arborescence comme suit :

Ce dossier partagé se retrouvera à la racine (par défaut) du Nextcloud des destinataires concernés.

L'arborescence complète ne sera pas visible.

Cela n'est pas adapté si l'on souhaite partager toute une arborescence avec des droits spécifiques et diverses en son sein.

C'est la que l'application Group Folders intervient.

Group Folders

Présentation

Group Folders est une application que l'on va pouvoir greffer à Nextcloud.

Cette application va permettre de configurer des dossiers partagés à un / des groupe(s) d'utilisateurs.

Ensuite, l'administrateur va pouvoir configurer finement des droits spécifiques (lecture / écriture / partage / quota) sur ces dossiers partagés.

De 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.

Lien vers le projet : https://github.com/nextcloud/groupfolders

Exemple

Dans mon Nextcloud, je possède plusieurs utilisateurs repartis dans les groupes suivant :

Comptabilité
Direction
Technique
Invité

Je souhaite déployer une arborescence de ce type au sein de mon Nextcloud :

.
├── 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.

Ensuite, rechercher Group Folders puis Télécharger et activer :

Configuration

Toujours en tant qu'admin, se rendre dans les Paramètres d'Administration puis Dossiers du groupe :

Créer dans un 1er temps les dossiers qui figureront à la racine des utilisateurs :

Ensuite, y associer les groupes d'utilisateurs désirés avec les permissions adéquates :

Ici 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.

Il est possible d'y définir un quota maximal :

Puis, définir qui pourra gérer les droits de ce dossier :

Il faut que ce soit un utlisateur / groupe qui ait accès au dossier.

Configurer l'intégralité des autorisations souhaitées comme suit :

Bien entendu, il faut ensuite créer les sous-dossiers dans chaque Group Folders dans l'espace Fichiers de Nextcloud.

Maintenant, les utilisateurs verront uniquement ce à quoi ils doivent avoir accès à la racine de leur Nextcloud.

Par exemple, pour mon utilisateur Pierre qui fait partie du groupe Comptabilité :

Autorisation avancée

Il est possible d'aller encore plus loin dans les autorisations.

Je 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 :

Ici, je dis que Pierre du groupe Comptabilité peut finalement que lire et non modifier ce qui se trouve dans ce dossier :

Ligne de commande

L'intégralité de la configuration peut être réalisé en ligne de commande via occ :

occ groupfolders:create <name> → create a group folder
occ groupfolders:delete <folder_id> [-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 <folder_id> <group_id> [-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 <folder_id> [<quota>|unlimited] → set a quota for a group folder
occ groupfolders:rename <folder_id> <name> → rename a group folder
occ groupfolders:scan <folder_id> → 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.

Et surtout, ces données ne sont pas dépendante d'un utilisateur.

Bien entendu, cela est synchronisable avec les clients desktop Nextcloud Windows, Mac, Linux.

Pop!_OS 21.10 : Fix login on multiples monitors

Tue, 05 Apr 2022 11:05:22 +0200

Contexte

Lors de l'utilisation de plusieurs moniteurs, j'ai été confronté à un problème assez pénible.

En effet, au démarrage de mon système la disposition de mes différents moniteurs s'appliquent après l'ouverture de ma session.

C'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.

J'ai donc appliqué la méthode suivante...

Méthode

Tout d'abord, j'ai effectué le réglage de mes moniteurs dans Paramètres -> Ecrans :

Une fois cela fait, j'ai exporté cette configuration pour l'appliquer à GDM :

sudo cp ~/.config/monitors.xml ~gdm/.config/monitors.xml

Puis, j'ai modifié l'appartenance du fichier monitors.xml :

sudo chown gdm:gdm ~gdm/.config/monitors.xml

Maintenant, mon invite de login, s'affiche bien sur mon écran principal.

GPO: Disable web search from taskbar

Thu, 24 Mar 2022 22:49:53 +0100

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

Première solution

Dans le Gestionnaire du serveur / Outils / Gestion des stratégies de groupe

Dans Objets de stratégie de groupe / Clic droit -> Nouveau.
Nommez votre stratégie et faites un clic droit / Modifier sur votre nouvelle GPO

Cette fenêtre apparait :

Sélectionnez une stratégie Configuration Ordinateur / Modèles d'administration / Composants Windows / Rechercher
Activez les trois paramètres suivants :
- Ne 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
Appliquez la GPO à l'aide de la commande gpudate /force dans l'invite de commande

gpupdate /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.

Toujours dans l'éditeur de gestion des stratégies de groupe, après avoir créé une nouvelle GPO :

Sé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 :

Remplissez cette fenêtre comme suit :

Action : 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é :

Pensez à positionnez votre nouvelle GPO sur l'unité organisationnelle concernée
Appliquez la GPO à l'aide de la commande gpudate /force dans l'invite de commande

gpupdate /force

Vérification

L'onglet Web ainsi que la mention Rechercher sur le web ont bien été désactivés :

Terminal: Le prompt avec Powerline sous LSD

Sun, 20 Mar 2022 19:56:57 +0100

Contexte

Je cherchais à améliorer mon prompt bash dans mon terminal afin d'améliorer mon expérience.

Le 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.

Exemple :

La personnalisation peut être plus avancée (se référer aux sources en bas de page).

Paramétrage

Editer son fichier .bashrc :

vi ~/.bashrc

Ajouter les lignes suivantes :

export POWERLINE_SEGMENTS="hostname pwd git git_sync status"
source ~/.powerline.bash

Télécharger le fichier powerline.bash et le déplacer dans sa home directory :

wget 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 :

wget https://github.com/ryanoasis/nerd-fonts/releases/download/v2.1.0/Hack.zip

Si le dossier ~/.fonts n'existe pas, le créer !

mkdir ~/.fonts

Décompresser l'archive des polices dans son dossier ~/.fonts :

unzip -d ~/.fonts Hack.zip

Supprimer l'archive Hack.zip :

rm Hack.zip

Mettre à jour le cache des polices :

fc-cache -vf ~/.fonts

Sélectionner la police Hack Nerd Font pour son terminal :

Il peut être utile de redémarrer son terminal pour avoir le choix des nouvelles polices installées 🙂

Maintenant, à l'ouverture de son terminal ce prompt apparait :

LSD

Dans mes recherches, je suis également tombé sur un projet nommé lsd (se référer aux sources en bas de page).

Celui-ci permet d'afficher des icônes sympa en fonction du type de fichiers.

Télécharger la dernière release dispo ici : https://github.com/Peltoche/lsd/releases

A l'heure où j'écris ces lignes c'est la version 0.21.0, donc pour ma Pop!_Os en 64 bits :

wget https://github.com/Peltoche/lsd/releases/download/0.21.0/lsd_0.21.0_amd64.deb

Installer le paquet :

sudo dpkg -i lsd_0.21.0_amd64.deb

Et voilà !

Il suffit de remplacer la commande ls par lsd :

Ces quelques alias peuvent être très agréables :

alias ls='lsd'
alias ll='ls -lh'
alias la='ls -ah'
alias lla='ls -lah'
alias lt='ls --tree'

Sources

Apache2 : Installation serveur web de base + SSL

Tue, 08 Mar 2022 21:13:57 +0100

Contexte

Cet article à pour but de servir de base pour l'installation d'un serveur web sous Apache2 avec un certificat SSL.

Let's Encrypt est utilisé et la résolution du challenge se fera sur le port 666 (donc sans interruption de service).

Réalisé sous Debian 11

Installation Apache2

Installation du serveur web apache2 :

sudo apt install apache2

Modification du fichier /etc/apache2/apache2.conf comme suit :

# Les variables d'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

<Directory />
# Pas de suivi des liens symboliques
 Options -FollowSymLinks
 AllowOverride None
 Require all denied
</Directory>

<Directory /usr/share>
 AllowOverride None
 Require all granted
</Directory>

<Directory /var/www/>
# Pas de listage des fichiers du site mais ok pour le suivi des liens symboliques
 Options -Indexes +FollowSymLinks
 AllowOverride None
 Require all granted
</Directory>

AccessFileName .htaccess

<FilesMatch "^\.ht">
 Require all denied
</FilesMatch>

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

Modification du fichier /etc/apache2/ports.conf comme suit :

# Ecoute sur le port 80 et 443
Listen 80
Listen 443

Modification du fichier /etc/apache2/conf-available/security.conf comme suit :

# Definit les informations du serveur retourné par l'en-tête HTTP
ServerTokens Prod
# Serveur version et nom du vhost désactivés
ServerSignature Off
TraceEnable Off

Activation des modules de bases :

sudo a2enmod rewrite actions headers expires ssl

Activation du site par défaut en SSL :

sudo a2ensite default-ssl

Redémarrage du serveur web apache2 :

sudo systemctl restart apache2

A ce stade, le serveur web doit être accessible : http://ip_srv_web/ et https://ip_srv_web/ (erreur de certificat)

Une fois cette vérification faites, désactivation des sites par défaut :

sudo a2dissite 000-default default-ssl

Puis rechargement de la configuration du serveur web :

sudo systemctl reload apache2

Certificat SSL

Installation de Let's Encrypt :

sudo apt install letsencrypt

Modification du fichier /etc/apache2/mods-available/proxy.conf comme suit :

# Permet d'effectuer les challenges acme sur le port 666
<IfModule mod_proxy.c>
 ProxyPass "/.well-known/acme-challenge/" "http://127.0.0.1:666/.well-known/acme-challenge/" retry=1
 ProxyPassReverse "/.well-known/acme-challenge/" "http://127.0.0.1:666/.well-known/acme-challenge/"
 <Location "/.well-known/acme-challenge/">
 ProxyPreserveHost On
 Order allow,deny
 Allow from all
 Require all granted
 </Location>
 </IfModule>

Activation des modules nécessaires :

sudo a2enmod proxy proxy_http ssl

Redémarrer le serveur web apache2 :

sudo systemctl restart apache2

Edition de la crontab pour le renouvellement automatique du certificat :

sudo crontab -e

Indiquer un renouvellement tous les dimanche à 5h00 du matin :

# Autorenew let's encrypt cert
00 05 * * 0 letsencrypt renew --standalone --preferred-challenges http-01 --http-01-port 666

Générer le certificat :

sudo letsencrypt certonly -d "monsite.example.org" --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.

Configuration vhost

Création du fichier /etc/apache2/sites-available/monsite.example.org.conf :

# Example pour le site : monsite.example.org
# DirectoryRoot : /var/www/monsite.example.org/www/
# Les logs seront dans /var/log/apache2/
<VirtualHost *:80>
 ServerName monsite.example.org
 Redirect Permanent / https://monsite.example.org/
</VirtualHost>
<VirtualHost *:443>
 ServerName monsite.example.org

 LogLevel warn 
 ErrorLog "|/usr/bin/rotatelogs -lc /var/log/apache2/error.monsite.example.org.%Y.%m.%d 86400"
 CustomLog "|/usr/bin/rotatelogs -lc /var/log/apache2/access.monsite.example.org.%Y.%m.%d 86400" 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
 <Directory /var/www/monsite.example.org/www/>

 Require all granted 

 AllowOverride All
 DirectoryIndex index.html

 </Directory>
</VirtualHost>
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 :

sudo mkdir -p /var/www/monsite.example.org/www/

Déplacer le fichier index.html de base à des fins de test :

sudo mv /var/www/html/index.html /var/www/monsite.example.org/www/

Attribuer les droits pour www-data :

sudo chown -R www-data:www-data /var/www/

Activation du site monsite.example.org :

sudo a2ensite monsite.example.org

Recharger le serveur web apache2 :

sudo 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.

L'URL http://monsite.example.org doit rediriger vers https://monsite.example.org

Pour tester le renouvellement du certificat SSL sur le port 666 :

sudo letsencrypt renew --standalone --preferred-challenges http-01 --http-01-port 666 --dry-run

Sujet non abordé

Les règles de pare-feu

Network-Manager : Configuration d’un réseau bridgé pour QEMU/KVM

Tue, 08 Mar 2022 20:27:38 +0100

Contexte

J'utilise virt-manager pour gérer mes VMs sous QEMU/KVM et je suis sous Pop!_OS 21.10.

Voir /2022/01/31/virt-manager-installation/

Le réseau de ma machine hôte est prise en charge par Network-Manager.

J'ai eu le besoin de créer des VMs avec un réseau bridgé sur mon LAN.

Pour se faire je suis passé par l'interface graphique de ma Pop!_OS 21.10.

Cet article me fait office de mémo.

Création d’un pont

Lancer la configuration avancée du réseau :

nm-connection-editor

Créer un Pont :

Ajouter un pont vers une interface réseau :

Sélectionner l'interface réseau à lié au pont :

Configurer l'adressage IP souhaité :

Supprimer la connexion liée au pont précédement créé :

Redémarrer le service Network-Manager :

systemctl restart NetworkManager

Vérifier la configuration avec la commande ip a :

Configuration réseau VM

Dans les propriétés réseau de la VM, passer la configuration réseau en Bridge :

La VM sera maintenant visible comme une machine à part entière sur le LAN de mon hôte.

Pop!_OS 21.10 : Modifier CAPS LOCK pour les chiffres

Tue, 01 Feb 2022 10:04:54 +0100

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.

Il est possible de changer ce comportement. Par contre, il ne sera plus possible d'utiliser cette touche pour les majuscules accentuées.

Dans 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).

J'ai donc appliqué la méthode suivante...

Méthode

Editer le fichier /usr/share/X11/xkb/symbols/fr en tant que root :

sudo vi /usr/share/X11/xkb/symbols/fr

Repérer la ligne suivante :

include "latin"

Et juste en-dessous, insérer ceci :

include "mswindows-capslock"

Ensuite, créer le fichier /usr/share/X11/xkb/symbols/mswindows-capslock :

sudo vi /usr/share/X11/xkb/symbols/mswindows-capslock

Insérer les lignes suivantes :

// Replicate a "feature" of MS Windows on AZERTY keyboards 
// where Caps Lock also acts as a Shift Lock on number keys.
// Include keys <AE01> to <AE10> in the FOUR_LEVEL_ALPHABETIC key type.

partial alphanumeric_keys
xkb_symbols "basic" {
 key <AE01> { type= "FOUR_LEVEL_ALPHABETIC", [ ampersand, 1, bar, exclamdown ] };
 key <AE02> { type= "FOUR_LEVEL_ALPHABETIC", [ eacute, 2, at, oneeighth ] };
 key <AE03> { type= "FOUR_LEVEL_ALPHABETIC", [ quotedbl, 3, numbersign, sterling ] };
 key <AE04> { type= "FOUR_LEVEL_ALPHABETIC", [apostrophe, 4, onequarter, dollar ] };
 key <AE05> { type= "FOUR_LEVEL_ALPHABETIC", [ parenleft, 5, onehalf, threeeighths ] };
 key <AE06> { type= "FOUR_LEVEL_ALPHABETIC", [ section, 6, asciicircum, fiveeighths ] };
 key <AE07> { type= "FOUR_LEVEL_ALPHABETIC", [ egrave, 7, braceleft, seveneighths ] };
 key <AE08> { type= "FOUR_LEVEL_ALPHABETIC", [ exclam, 8, bracketleft, trademark ] };
 key <AE09> { type= "FOUR_LEVEL_ALPHABETIC", [ ccedilla, 9, braceleft, plusminus ] };
 key <AE10> { type= "FOUR_LEVEL_ALPHABETIC", [ agrave, 0, braceright, degree ] };
};

Enregistrer et redémarrer la machine.

Pop!_OS 21.10 : Fix transparent Firefox with Integrated Graphics

Tue, 01 Feb 2022 08:29:34 +0100

Contexte

Mon laptop sous Pop!_OS 21.10 possède 2 GPUs :

1 dédié NVIDIA
1 intégré INTEL

Lorsque je suis en mode graphique Nvidia ou Hybrid, mon navigateur Firefox se lance correctement.

Par 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 :

Cause

Cela est dû au non chargement des librairies ICD nécessaires pour l'IGPU.

Correctif

Pour corriger cela, j'ai ajouté les lignes suivantes dans mon fichier ~/.profile :

# fix firefox in integrated graphics
if ! grep -w -q nvidia <(lsmod) ; then
 export __EGL_VENDOR_LIBRARY_FILENAMES="/usr/share/glvnd/egl_vendor.d/50_mesa.json"
fi

Puis, j'ai déconnecté et reconnecté mon utilisateur.

Maintenant, le problème est corrigé. Firefox se lance désormais correctement lorsque mon laptop fonctionne uniquement sur l'iGPU.

Virt-Manager : Installation

Mon, 31 Jan 2022 18:01:43 +0100

Contexte

Le contexte est simple. Je souhaitais avoir de meilleures performances sur mes machines virtuelles Linux qu'avec l'excellent VirtualBox.

J'ai donc entrepris l'installation de l'outil virt-manager.

Virt-manager permet de gérer graphiquement les machines virtuelles sur le module KVM qui fait partie du noyau Linux.

Cet article me fait office de mémo. J'ai réalisé cette installation sous Pop!_OS 21.10.

Installation

Tout d'abord, l'installation des paquets indispensables :

sudo 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 :

sudo apt install virt-manager

Maintenant l'outil est exécutable avec la commande :

virt-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.

Afin de pouvoir me connecter à mon hyperviseur avec mon compte utilisateur, j'ai d'abord vérifié que je faisais bien partie du groupe libvirt :

sudo 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 :

sudo 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 :

id $(whoami)

Ensuite, j'ai édité le fichier libvirtd.conf :

sudo vi /etc/libvirt/libvirtd.conf

J'ai modifié ces 2 lignes comme suit :

unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"

Puis, j'ai redémarré le service libvirtd.service :

sudo systemctl restart libvirtd.service

A présent, l'outil virt-manager peut se connecter sans être root à l'hyperviseur QEMU/KVM.

Dans mon cas, j'ai dû tout de même redémarrer mon système afin que la configuration soit prise en compte.

OneDrive : Client Linux OpenSource

Fri, 14 Jan 2022 14:56:22 +0100

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 & pro), il me fallait pouvoir synchroniser ceux-ci dans des dossiers différents de mon système.

Par exemple :

Mon compte OneDrive perso dans ~/OneDrive_Perso
Mon compte OneDrive pro dans ~/OneDrive_Pro

Bien evidément, cela doit fonctionner en tant que service.

Je suis tombé sur ce projet : https://github.com/skilion/onedrive

Update 07/12/2023 :
Le projet utilisé dans cet article est stoppé.
Utiliser / Adapter avec celui-ci : https://github.com/abraunegg/onedrive.git

C'est un outil sous licence GPL3 permettant d'intéragir avec OneDrive sous Linux.

Les 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.

C'est parfait car c'est mon besoin 🙂

Installation

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.

Tout d'abord l'installation des pré-requis :

sudo 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 :

git 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.

3 directives sont définissables :

sync_dir : Le répertoire où seront stockés les données.
skip_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.

L'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.
sync_list : Spécifier les fichiers / dossiers à synchroniser. J'en parlerai dans un prochain article.

L'outil doit être relancé avec l'argument --resync après une modification de la directive skip_file.

Comme 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 :

mkdir -p ~/{OneDrive_Perso,OneDrive_Pro}

Ensuite, j'ai créé 2 dossiers de configuration (un dossier par compte) :

mkdir -p ~/.config/{onedrive_perso,onedrive_pro}

J'ai ensuite créé mes 2 fichiers de configurations (un fichier par compte).

OneDrive perso :

cat > ~/.config/onedrive_perso/config << EOF
# Directory where the files will be synced
sync_dir = "~/OneDrive_Perso"
# Skip files and directories that match this pattern
skip_file = ".*|~*"
EOF

OneDrive pro :

cat > ~/.config/onedrive_pro/config << EOF
# Directory where the files will be synced
sync_dir = "~/OneDrive_Pro"
# Skip files and directories that match this pattern
skip_file = ".*|~*"
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 :

onedrive --monitor --confdir="~/.config/onedrive_perso"

Un lien est généré :

Authorize this app visiting:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=22c49a0d-d21c-4792-aed1-8f163c982546&scope=files.readwrite%20files.readwrite.all%20offline_access&response_type=code&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) :

J'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...) :

Ensuite, je teste mon compte OneDrive_Pro :

onedrive --monitor --confdir="~/.config/onedrive_pro"

Il est important de libèrer le token office avant. J'étais, au préalablement, identifié sur mon compte perso.

Pour 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

5. Services

Lors de l'installation de l'outil un service a été créé : /usr/lib/systemd/user/onedrive.service.

J'ai décidé de garder ce service pour mon compte perso et d'en créer un second pour mon compte pro :

cp /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 :

vi /usr/lib/systemd/user/onedrive.service

Puis, j'ai modifié la ligne ExecStart :

ExecStart=/usr/local/bin/onedrive --monitor --confdir="~/.config/onedrive_perso"

Et enfin la même modification pour mon serive OneDrive pro :

vi /usr/lib/systemd/user/onedrive_pro.service

Cette fois-ci, j'ai modifié comme suit :

ExecStart=/usr/local/bin/onedrive --monitor --confdir="~/.config/onedrive_pro"

Pour terminer, j'ai activé mes 2 services :

systemctl --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 :

journalctl --user-unit onedrive -f
journalctl --user-unit onedrive_pro -f

7. Désinstallation

sudo make uninstall
rm -rf ~/.config/onedrive*

Supervision et autodiscover: Open Centreon Discovery

Tue, 14 Dec 2021 11:03:02 +0100

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é.

Source: L'atelier de Kermith et Github du créateur

Installation

Téléchargement du module

Créer un dossier:

mkdir /usr/share/discovery

Récupérer le dépôt:

git clone https://github.com/romnvll/Open-Centreon-Discovery.git

Configuration d’Apache

Pour qu'Apache reconnaisse OCD, il faut créer le fichier de configuration:

vim /etc/httpd/conf.d/discovery.conf

Copiez ces lignes dans le fichier:

###########################################
Alias /discovery /usr/share/discovery/
<LocationMatch ^/discovery/(.*\.php(/.*)?)$>
 ProxyPassMatch fcgi://127.0.0.1:9042/usr/share/discovery/$1
</LocationMatch>
ProxyTimeout 300
<Directory "/usr/share/discovery">
 DirectoryIndex index.php
 Options Indexes
 AllowOverride all
 Order allow,deny
 Allow from all
 Require all granted
 <IfModule mod_php5.c>
 php_admin_value engine Off
 </IfModule>
 AddType text/plain hbs

</Directory>

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

Redémarrez Apache:

systemctl 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é:

cd 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:

chown -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):

mv /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) :

//Vos identifiants centreon
$config['centreon']['user'] = 'user';
$config['centreon']['password'] = 'password';

//chemin de clapi
$config['centreon']['clapi'] = '/usr/share/centreon/bin/centreon';

Scanner manuellement le réseau

Connexion à l’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

Vous arriverez alors sur la page suivante:

Si à 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.

Nous reviendrons plus tard sur le message concernant le scan en tâche de fond.

Configuration 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.

Une fois ces paramètres rentrés, cliquez sur le bouton Scan.

Le réseau

Il s'agit du sous-réseau en notation CIDR sur lequel vous voulez détecter des hôtes.

La 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 :

Déplacez le fichier de conf par défaut et créez le votre:

mv /etc/snmp/snmpd.{conf,conf.default}

Il est toujours utile de garder de côté ce fichier par défaut.

vim /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 "" any noauth exact mavue none none

Redémarrez snmpd:

systemctl 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.

Le résultat du scan

Après avoir cliqué sur Scan, au bout de quelques secondes vous arriverez sur cette page:

Cette liste affiche les hôtes découvrables (voir config snmp) et qui ne sont pas encore intégrés à Centreon.

Vous pouvez cliquer sur le bouton Magie et celui-ci affectera automatiquement le template d'hôte associé à l'os détecté.

Il sera également possible de rajouter manuellement deux autres templates supplémentaires.

Veillez également à sélectionner le bon poller, cochez le ou les équipement(s) à exporter puis cliquez sur Valider.

Deux choix s'offrent alors à vous:

Soit 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.

Background 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.

Ajout de réseaux à scanner

Il faut au préalable venir écrire les réseaux à scanner dans le fichier de configuration d'OCD:

vim /usr/share/discovery/config.php

La variable $config['backGroundScanUse'] est activé par défaut. C'est elle qui défini l'activation ou l'arrêt du processus.

La variable $config['backGroundRoot'] 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:

L'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['backGroundScanUse'] = true ;
//chemin de l'executable scanBackGround

$config['backGroundRoot'] = '/usr/share/discovery';

$config['backGroundScan'][0] = array("network" => "192.168.1.0/24",
 "community"=>"public",
 "version"=>"2" );

$config['backGroundScan'][1] = array("network" => "192.168.4.0/24",
 "community"=>"macommuperso",
 "version"=>"2" );

Planifier la tâche

Après avoir configuré vos réseaux, il est temps de planifier vos scans.

Tout d'abord, tester la commande qui exécute le scan:

cd /usr/share/discovery && /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.

ATTENTION: 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!!!
chown apache: resulScan

Au bout de quelques secondes vous devriez voir apparaitre vos hôtes sur l'interface web d'OCD

Cliquez ensuite sur Go.

Vous 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.

Merci à 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é.

Docker-Compose : Tactical RMM

Mon, 13 Dec 2021 11:56:12 +0100

docker-compose.yml

version: "3.7"

# 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: [ "tactical-init" ]
 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:
 - "4222:4222"
 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: [ "tactical-backend" ]
 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: [ "tactical-websockets" ]
 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:
 - "8010:80"
 - "8011:443"
 volumes:
 - ./tactical_data:/opt/tactical

 # container for celery worker service
 tactical-celery:
 container_name: trmm-celery
 image: ${IMAGE_REPO}tactical:${VERSION}
 command: [ "tactical-celery" ]
 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: [ "tactical-celerybeat" ]
 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 "\n# certs" >> .env
echo "CERT_PUB_KEY=$(base64 -w 0 /path/to/fullchain.pem)" >> .env
echo "CERT_PRIV_KEY=$(base64 -w 0 /path/to/privkey.pem)" >> .env

Docker-Compose : RocketChat

Mon, 13 Dec 2021 11:48:02 +0100

docker-compose.yml

version: '2'

services:
 rocketchat:
 image: registry.rocket.chat/rocketchat/rocket.chat:latest
 container_name: rocketchat
 command: >
 bash -c
 "for i in `seq 1 30`; do
 node main.js &&
 s=$$? && break || s=$$?;
 echo \"Tried $$i times. Waiting 5 secs...\";
 sleep 5;
 done; (exit $$s)"
 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:
 - "traefik.backend=rocketchat"
 - "traefik.frontend.rule=Host: your.domain.tld"

 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:
 - "traefik.enable=false"

 # this container'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: >
 bash -c
 "for i in `seq 1 30`; do
 mongo mongo/rocketchat --eval \"
 rs.initiate({
 _id: 'rs0',
 members: [ { _id: 0, host: 'localhost:27017' } ]})\" &&
 s=$$? && break || s=$$?;
 echo \"Tried $$i times. Waiting 5 secs...\";
 sleep 5;
 done; (exit $$s)"
 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'd like here, they need to be installable by npm
 - EXTERNAL_SCRIPTS=hubot-help,hubot-seen,hubot-links,hubot-diagnostics
 depends_on:
 - rocketchat
 labels:
 - "traefik.enable=false"
 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: >
 # traefik
 # --docker
 # --acme=true
 # --acme.domains='your.domain.tld'
 # --acme.email='your@email.tld'
 # --acme.entrypoint=https
 # --acme.storagefile=acme.json
 # --defaultentrypoints=http
 # --defaultentrypoints=https
 # --entryPoints='Name:http Address::80 Redirect.EntryPoint:https'
 # --entryPoints='Name:https Address::443 TLS.Certificates:'
 # ports:
 # - 80:80
 # - 443:443
 # volumes:
 # - /var/run/docker.sock:/var/run/docker.sock

Docker-Compose : qBittorrent

Mon, 13 Dec 2021 11:44:54 +0100

docker-compose.yml

qbittorrent:
 image: gists/qbittorrent
 container_name: qbittorrent
 ports:
 - "8080:8080"
 - "6881:6881"
 - "6881:6881/udp"
 volumes:
 - ./data:/data
 environment:
 - UID=1000
 - GID=1000
 restart: unless-stopped

Docker-Compose : Pi-Hole

Mon, 13 Dec 2021 11:43:04 +0100

docker-compose.yml

version: "3"

# 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:
 - "53:53/tcp"
 - "53:53/udp"
 - "67:67/udp"
 - "8085:80/tcp"
 environment:
 TZ: 'Europe/Paris'
 WEBPASSWORD: "password"
 # Volumes store your data between container upgrades
 volumes:
 - './etc-pihole/:/etc/pihole/'
 - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
 # 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

Docker-Compose : Nginx Proxy Manager

Mon, 13 Dec 2021 11:41:08 +0100

docker-compose.yml

version: '3'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 container_name: npm
 restart: unless-stopped
 ports:
 - '80:80'
 - '8082:81'
 - '443:443'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt

Credentials

Email: admin@example.com
Password: changeme

Docker-Compose : Nextcloud

Mon, 13 Dec 2021 11:37:28 +0100

docker-compose.yml

version: '2'

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

Docker-Compose : Netdata

Mon, 13 Dec 2021 11:33:45 +0100

docker-compose.yml

version: '3'
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:

Docker-Compose : Keycloak

Mon, 13 Dec 2021 11:30:58 +0100

docker-compose.yml

version: '3.3'

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: 'true'
 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

Docker-Compose : Dashy

Mon, 13 Dec 2021 11:27:42 +0100

docker-compose.yml

version: "3"
services:
 dashy:
 # To build from source, replace 'image: lissy93/dashy' with 'build: .'
 # 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: ['CMD', 'node', '/app/services/healthcheck']
 interval: 1m30s
 timeout: 10s
 retries: 3
 # start_period: 40s

Supervision: tour d’horizon avec CentCTL pour Centreon Open Source.

Fri, 26 Nov 2021 14:51:09 +0100

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.

CentCTL 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 & CentCTL: l’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.

Ci-dessous je détaille une proposition de convention de nommage.

Les 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).

Le résultat donnera quelque chose comme:

ChC_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:

ChC_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).

Exemple: template de configuration de notifications.

Lors 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).

Par exemple, ces templates se nommeront ainsi:

Nom => STC_NOTIF = Service Template Configuration
Nom => HTC_NOTIF = Host Template Configuration

Vous 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.

Les templates de service

Ces templates de baseront sur le nom de la commande qu'ils représentent:

Nom => ST_ChC_OS_DEB10_DISK_SPACE_VAR (ST pour Service Template)
- Alias => 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.

Les templates d’hôte

Décrivez succinctement l'OS et la fonction de l'hôte en question:

Nom => HT_OS_WINSRV19_WEB_SRV (HT pour Host Template)
- Alias => 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)

Nom: Aukfood_Linux_Server_Web_001
- ou encore: CrdAgr_RSY-PlaceVendee_Win10_Direction_001

Pour l'alias, inscrivez simplement son FQDN.

Les 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:

SFT_ChC_CHECK_PING

Si vous créez un service manuellement sans passer par un template:

S_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.

Pré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.

Téléchargement de CentCTL

Créer un dossier dans lequel récupérer CentCTL puis télécharger la dernière version:

mkdir $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:

chmod +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:

export CENTCTL_CONF=/home/USER/centctl/centctl.yaml

USER étant votre nom d'utilisateur, bien entendu !

Configurer l'auto-complétion :

Si le paquet n'est pas installé:

dnf install bash-completion

Puis exécuter les commandes:

source ~/.bashrc
type _init_completion

Si la commande réussi, on peut passer à la suite, sinon:

Dans le .bashrc, écrivez cette ligne de commande en bas du fichier:
```
source /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.

Pour terminer, ajouter le script de complétion dans le répertoire /etc/bash_completion.d:

sudo su
/home/USER/centctl/centctl completion bash > /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.

NAMESERVER 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:

servers:
 - server: "centreon-centos"
 url: "https://centreon21.aukfood.fr"
 insecure: true
 login: "admin"
 password: "Pa55word"
 version: "v1"
 default: true
 - server: "centreon-rocky"
 url: "http://192.168.1.222/centreon"
 login: "admin"
 password: "azerty666"
 version: "v1"

Pour rappel CentCTL utilise la V1 de Rest API.

Tester 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:

./centctl --server=centreon-centos list host

Voici le résultat, au format json par défaut:

{
 "server": {
 "name": "centreon-centos",
 "hosts": [
 {
 "id": "23",
 "name": "Aukfood_Rocky_Client_001",
 "alias": "RockyLinux.aukfood.fr",
 "address": "192.168.1.148",
 "activate": "1"
 }
 ]
 }
}

D'autres formats sont disponibles avec le flag --output en fin de commande:

./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

Exporter 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.

Personnellement 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.

La configuration du moteur Centreon

J'utilise le flag -r ^.* pour tout selectionner mais le flag --all marche très bien aussi.

./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.

Les commandes

Exportez les commandes:

./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:

./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’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.

./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)

./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’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.

Mais 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 "\$USER1$/check_ping -H \$HOSTADDRESS$ -w \$_SERVICEWARNING$ \$_SERVICECRITICAL$ -p \$_SERVICENBPACKETS$ -4" -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.

Créer un template de service:

Exemple avec la commande check_ping:

./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:

./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value="WARNING|3,40%|0|seuil d'alerte 1"
./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value="CRITICAL|5,60%|0|seuil d'alerte 2"
./centctl --server=centreon-rocky modify template service -n ST_ChC_CHECK_PING -p macro --value="NBPACKETS|5|0|nombre de paquets"
./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:

Nous allons utiliser un autre template, dédié à la configuration des notifications

./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 "admin"
/centctl --server=centreon-rocky modify template service -n STC_NOTIF -p contactgroup -v "Supervisors"
/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 "w,u,c,r,f,s"
./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

Créer un template d’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.

Les commandes pour les paramètres de notifications sont les mêmes que pour les templates de service.

Pour lier des templates de service:

./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.

Cré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.

Pour 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.

./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)

Pour aller plus loin

De nombreux autres paramètres n'ont pas été abordés! Pour en découvrir d'autres, c'est par ici !!!

Exemple pratique: automatiser le déploiement d’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.

Contexte

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.

Extraire une liste d’hôtes

./centctl --server=centreon-rocky list host -r ^.* --output csv > 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:

Ôter la premiere ligne en plaçant le curseur en début de ligne et appuyez 2 fois rapidement sur d
Entrez ces commandes:
```
:g/^\d*,/s///
:g/,.*$/s///
```
> Selon les préférences, la commande sed ira très bien aussi!

Après manipulation nous obtennons une liste ne contenant que les noms d'hôtes.

Aukfood_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'hôte
listhost="$(<hosts.csv)"

#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 "Wouah, c'était long! Tu as bien travaillé, vas te reposer maintenant ;)"

Maintenant, vous pouvez grâce à toutes les commandes CentCTL vues précédemment vous amuser à scripter dans tout les sens...

Sources

L'atelier de Kermith qui est une vraie pépite pleine de bonne choses!
Github de CentCTL dans lequel j'ai trouvé nombreuses réponses.
Mes cours sur la supervision lors de ma formation TSSR à l'ENI de St-Herblain ( coucou Fred 🙂 )

Merci

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)

Charles, stagiaire TSSR.

Uptime Kuma : Une alternative à Uptime Robot !

Wed, 24 Nov 2021 09:51:40 +0100

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.

Vous 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. 👀

Cependant 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. ✌️

Le 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.

Uptime 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. 🐳

Premiè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.

Allez sur l'interface web (par défaut : http://localhost:3001), vous pouvez configurer une écoute distante, à travers un reverse-proxy par exemple.

Vous 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 "Ajouter une nouvelle sonde".

Vous 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.

Quelques 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.

En 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.

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.

LemonLDAP : Activer le HTTPS + Reverse-Proxy

Sat, 20 Nov 2021 15:36:41 +0100

Apache / Nginx configuration

La 1ère chose à faire est de configurer le serveur web pour le passer en HTTPS.

Suivre 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, ...

A exécuter en tant que root :

/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

Si le portail est derrière un reverse-proxy en HTTPS, il est impératif d'effectuer les manipulations plus haut.

Exemple d'un vhost sous Nginx pour le portail :

server {
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 :

server {
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.

Pour vérifier :

nginx -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='-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' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --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

Azure : Synchronisation AD On-Premise <> Azure AD

Sat, 20 Nov 2021 04:03:05 +0100

Azure AD" />

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.

Contexte

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’activation de la corbeille Active Directory

En PowerShell :

Get-ADOptionalfeature -Filter {name -like "Recycle Bin Feature"}

Si la valeur EnabledScope est vide, cela signifie que la corbeille Active Directory n'est pas activée.

Activer la corbeille Active Directory

En PowerShell :

Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "starwars-bzh.local" -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.

Maintenant, la corbeille Active Directory est activée.

Configurer l’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.

Sur 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.

Changer l'UPN par défaut :

Au lieu de la faire à la main sur chaque utilisateur, il est possible de le faire en masse.

En PowerShell :

Get-ADUser -Filter * -SearchBase "OU=Services,OU=Starwars-BZH,DC=starwars-bzh,DC=local" | Foreach{

$UPNNew = $_.UserPrincipalName -replace "@starwars-bzh.local","@starwarsbzh.onmicrosoft.com"

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.

Installer Azure AD Connect

Télécharger l'outil à l'adresse suivante : https://www.microsoft.com/en-us/download/details.aspx?id=47594
Puis lancer l'installation sur le contrôleur de domaine local.
Accepter les termes de la licence puis continuer :

Un 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'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'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'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 :

Attention, une fois le Lieu d'utilisation affecté à un utilisateur. Un délai de 5 minutes peut être nécessaire avant de pouvoir lui attribuer une licence.

Une licence Microsoft 365 peut ensuite être attribué à un utilisateur :

Vé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.

A 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.

LemonLDAP : Installation avec un LDAP et FusionDirectory

Tue, 16 Nov 2021 14:48:52 +0100

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.

Le 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.

Le 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.

Il peut gérer plus de 200000 utilisateurs de différentes organisations, il implémente à la fois5 :

les 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.

La version 2.0.6 apporte, entre autres évolutions, les nouvelles fonctionnalités suivantes :

la 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.

La version 2.0.8 offre de nombreuses API et améliorations.

La 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.

Source : LemonLDAP::NG — Wikipédia (wikipedia.org)

Pré-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 :

sudo cat > /etc/apt/sources.list.d/lemonldap-ng.list << 'EOL'
# 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 :

wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | sudo apt-key add -

Mise à jour du cache apt :
```
sudo apt update
```
Installer le package principal et le module Perl pour Apache2 :
```
sudo apt install libapache2-mod-perl2 lemonldap-ng
```
LemonLDAP est également compatible avec Nginx mais cela ne sera pas abordé dans cet article.
Installer le module FCGID pour Apache :
```
sudo apt install libapache2-mod-fcgid
```

Activer les modules et les configurations :

sudo 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 :
```
sudo apachectl configtest
```
Redémarrer Apache2 :
```
sudo systemctl restart apache2
```

Par défaut, le domaine est example.com. Celui-ci peut être changé.

Pour changer le nom de domaine par défaut :
```
sed -i 's/example\.com/mondomaine.local/g' /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.

Accè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 :
- auth.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.
Avec un navigateur web, accéder à http://auth.example.com :

Dans 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.

Se 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 :
```
/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 :
```
sudo a2ensite test-apache2.conf
sudo systemctl reload apache2
```

C'est un vhost standard d'Apache2 :

sudo cat /etc/apache2/sites-enabled/test-apache2.conf

Remarquer la ligne qui à été ajoutée concernant le SSO :

 # SSO protection
 PerlHeaderParserHandler Lemonldap::NG::Handler::ApacheMP2

Vérifier l'accès aux applications de démonstration en se rendant sur :
- http://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 :

Il 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 :

Avec l'utilisateur dwho se rendre dans le Manager. Puis Hôtes virtuels, manager.example.com, Règles d'accès :
Modifier la partie Règles à droite comme ci-dessus. Puis Sauver la configuration.

Paramétrer la liaison à l'annuaire LDAP :

sudo /usr/share/lemonldap-ng/bin/lemonldap-ng-cli -yes 1 \
 set \
 authentication LDAP \
 userDB LDAP \
 passwordDB LDAP \
 registerDB LDAP \
 ldapServer 'ldap://localhost' \
 managerDn 'cn=admin,dc=example,dc=com' \
 managerPassword 'MonSuperPassword' \
 ldapBase 'ou=people,dc=example,dc=com' \

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 :
```
sudo slapcat | grep "dn:"
```

Exporter les attributs souhaités :

sudo /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 :

Status : [
 {
 'localhost' => 'OK'
 }
 ];

Redémarrer Apache2 :
```
sudo systemctl restart apache2
```
L'utilisateur fd-admin peut maintenant s'authentifier, avec accès au manager, sur la plateforme : http://auth.example.com.

Windows Store : Error code 0x80070424

Sun, 14 Nov 2021 10:50:08 +0100

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”}

Keycloak : Integration LDAP externe

Thu, 04 Nov 2021 17:33:31 +0100

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.

Cet article fait suite à :

Keycloak : 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.

Configuration

Se rendre sur la WebUI du serveur Keycloak : https://keycloak.example.com
Se rendre dans la partie User Federation et ajouter ldap en provider :

Paramé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.

Il 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.

Edition

L'Edit Mode permet aux utilisateurs et aux administrateurs, à travers leurs consoles respectives sur Keycloak, de modifier les metadas utilisateur.

READONLY : 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 :

Active Directory
Red Hat Directory Server
Tivoli
Novell eDirectory
Other

L'annuaire installé étant OpenLDAP, other est le choix à faire.

Paramé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 "Bind DN".

Synchronisation

Un peu plus bas de la page de configuration de la connexion au serveur LDAP, un menu Sync Settings est disponible :

Batch 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 :

Mappers

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 :

Dans 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 :

Au lieu de modifier la configuration de l'annuaire LDAP, modifier le mapper first name dans Keycloak :

Modifier LDAP Attribute pour indiquer givenName.

givenName est le nom de l'attribut prénom au sein de l'annuaire LDAP dans notre configuration.

OpenLDAP : Installation avec FusionDirectory

Thu, 04 Nov 2021 13:12:04 +0100

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.

Source : OpenLDAP — Wikipédia (wikipedia.org)

FusionDirectory 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.

Source : FusionDirectory — Wikilivres (wikibooks.org)

Dans 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.

Prérequis

Un serveur Debian 10 fraîchement installé et à jour.
Une adresse IP statique doit être configuré sur le serveur.

Le nom d'hôte du serveur doit être le FQDN futur dans l'annuaire ldap.

Vérifier les fichiers /etc/hostname et /etc/hosts.

# Exemple d'un fichier /etc/hostname
srv-ldap.domaine.local

# Exemple d'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 :
```
sudo apt install slapd ldap-utils
```
Saisir le mot de passe souhaité pour le compte admin de l'annuaire :
Saisir une seconde fois le mot de passe pour confirmer.
Vérifier l'installation d'OpenLDAP :
```
sudo slapcat
```

Voici le retour attendu :

dn: 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.

FusionDirectory

Récupérer et ajouter la clef GPG officielle de FusionDirectory :

wget https://public.fusiondirectory.org/FD-archive-key
sudo apt install -y gnupg2 && sudo apt-key add FD-archive-key

Ajouter le repository de fusiondirectory pour debian :

sudo cat > /etc/apt/sources.list.d/fusiondirectory-release.list << 'EOL'
#fusiondirectory repository
deb https://public.fusiondirectory.org/stretch-fusiondirectory-release/ stretch main
EOL

Ajouter le repository de schema2ldif pour debian :

sudo cat > /etc/apt/sources.list.d/schema2ldif-release.list << 'EOL'
#latest version of schema2ldif
deb https://public.fusiondirectory.org/stretch-schema2ldif-release/ stretch main
EOL

Mettre à jour la liste des paquets :
```
sudo apt update
```
Les repositories étant en https, installer le paquet apt-transport-https :
```
sudo apt install apt-transport-https
```

Installer les paquets pour FusionDirectory :

sudo 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.

Installer les paquets manquant pour PHP :
```
sudo apt install php-xml
```
Installer les schémas FusionDirectory dans la base LDAP :
```
sudo fusiondirectory-insert-schema
```
Redémarrer Apache2 :
```
sudo systemctl restart apache2.service
```

Configuration

Se connecter à la WebUI de FusionDirectory : http://srv-ldap.domaine.local/fusiondirectory/
Pour accéder au serveur, il est nécessaire de mettre un token dans un fichier. Celui-ci est indiquer sur la WebUI :

Copier / Coller la commande avant de cliquer sur Suivant :

sudo echo -n cm5ch69brdj9jdm8uejjrfans0 > /var/cache/fusiondirectory/fusiondirectory.auth

Configurer la langue :
Vérifier que l'installation soit entièrement en vert avant de continuer :
Vé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 :
Régler le fuseau horaire :

La 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.

Une inspection LDAP est effectuée et propose plusieurs actions afin d'être pleinement compatible avec FusionDirectory. Effectuer les actions nécessaires :
Télécharger le fichier de configuration :
Placer ce fichier fusiondirectory.conf dans le répertoire du serveur /etc/fusiondirectory/.
Vérifier la configuration de FusionDirectory :
```
sudo fusiondirectory-setup --check-config
```

Une erreur est détectée. Répondre Yes afin de corriger les permissions du fichier de configuration de fusion :

Checking FusionDirectory'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 :

Attribut mail

Par défaut, il n'y pas d'attribut mail sur un utilisateur. Cependant, il est possible de l'ajouter.

Installer les paquets nécessaires :

sudo apt install fusiondirectory-plugin-mail fusiondirectory-plugin-mail-schema

Modifier le schéma de l'annuaire afin de faire apparaitre l'attribut mail :

sudo 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 :

Samba : Installation d’un contrôleur de domaine

Fri, 29 Oct 2021 10:40:56 +0200

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.

A 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.

A 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.

Dans cette procédure, une distribution Debian 10 et Samba en version 4 sont utilisées.

Le 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 :

sudo echo "srv-samba.domaine.local" > /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 :

sudo 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 :

sudo echo "192.168.1.10 srv-samba.domaine.local srv-samba" >> /etc/hosts

Installation et configuration de Samba

Installation des paquets nécessaires :
```
sudo 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é.

Création du domaine

Renommer le fichier de configuration principal de samba /etc/samba/smb.conf :
```
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.org
```
Provisionner le domaine :
```
sudo 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éé :

Looking 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 :
```
sudo cp /var/lib/samba/private/krb5.conf /etc/
```
Arrêter les services SMB, NMBD et Bind :
```
sudo systemctl stop smbd nmbd winbind
```
Désactiver les services SMB, NMBD et Bind :
```
sudo systemctl disable smbd nmbd winbind
```
Rendre visible le service samba-ad-dc :
```
sudo systemctl unmask samba-ad-dc
```
Démarrer le service :
```
sudo systemctl start samba-ad-dc
```
Activer le service :
```
sudo systemctl enable samba-ad-dc
```
Vérifier le statut de Samba :
```
smbclient -L localhost -U%
```

Tout est OK :

 Sharename 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 :
```
sudo samba-tool domain level show
```

Le niveau fonctionnel du domaine est Windows 2008 R2 :

Domain and forest function level for domain 'DC=domaine,DC=local'

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 :
```
sudo samba-tool user create superman
```

Indiquer le mot de passe de superman :

New Password:
Retype Password:
User 'superman' 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)...

Avec 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é.

OpenProject : Mise en place du SSO avec Keycloak

Thu, 28 Oct 2021 14:40:22 +0200

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.

OpenProject 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.

Référence :

OpenProject : Installation

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Pré-requis

Pour mener à bien cette procédure, il faut :

Un 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).

Configuration partie Keycloak

Création d'un royaume :

Création d'un client :

Root URL : L'URL d'accès au serveur OpenProject.

Dans 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.

Un 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.

Une 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.

Se connecter en admin sur OpenProject puis "Administration -> Authentification", modifier l'option Auto-enregistrement comme suit :

Pour la suite des opérations, se connecter en SSH sur le serveur OpenProject.

Modifier 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: "keycloak.example.fr"
 identifier: "MonOpenProject"
 secret: "af90aced-0000-0000-0000-0959e6fd5226"
 icon: "openid_connect/auth_provider-google.png"
 display_name: "SSO"
 authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
 token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
 userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
 end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
 check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
 sso: true
 issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'
 discovery: false

Adapter les valeurs suivantes :

host : 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 -> Endpoints : OpenIP Endpoint Configuration

authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'

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.

OpenProject : 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 :

Fail2ban : Protéger l’authentification WordPress sous Nginx

Tue, 26 Oct 2021 02:43:26 +0200

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.

Cet article fait suite à Fail2ban : Installation et configuration.

Par 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é.

Configuration

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.

Modifier le fichier functions.php de votre thème WordPress pour y inclure :

/* Change WP-Admin login error message to be more generic */
function generic_login_msg ($msg) {
 global $errors;
 $err_codes = $errors->get_error_codes();
 if ( in_array( 'invalid_username', $err_codes ) || in_array('incorrect_password', $err_codes )) {
 $msg = 'ERROR: Invalid credential.';
 }
 return $msg;
}
add_filter('login_errors', 'generic_login_msg');

/* Return 403 instead of 200 when wp-login failed */
add_action( 'wp_login_failed', 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.

11.22.33.44 - - [26/Oct/2021:01:52:10 +0200] "POST /wp-login.php HTTP/1.1" 403 3149 "https://wordpress.example.com/wp-login.php" "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"

Création du filtre fail2ban

Fail2ban n'a pas de preset de filtre pour l'authentification de WordPress. Créer un filtre :
```
sudo vi /etc/fail2ban/filter.d/wp-login.conf
```
Ajouter le filtre suivant :
```
[Definition]
_daemon = wp-login
failregex = <HOST>.*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.

Ajouter la jail dans /etc/fail2ban/jail.local :

[wordpress]
enabled = true
port = http,https
filter = wp-login
logpath = /var/log/nginx/access.log

Redémarrer fail2ban :
```
sudo systemctl restart fail2ban
```
Vérifier la prise en compte de la jail avec :
```
sudo fail2ban-client status
```

Le retour doit être :

Status
|- Number of jail: 1
`- Jail list: wordpress

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Mon, 25 Oct 2021 17:37:16 +0200

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.

Dans 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.

Prérequis

1 serveur Debian 10 à jour qui sera dédié à hébergé le serveur Keycloack
1 serveur web Nginx opérationnel
Certificats SSL générés pour votre nom de domaine

Voir article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Installation

Installation des paquets

Installer docker :
```
sudo apt install docker
```
Installer docker-compose :
```
sudo apt install docker-compose
```
Vérifier l'installation de docker-compose :
```
docker-compose --version
```

Création du docker-compose

Créer un répertoire afin d'y stocker le fichier docker-compose :
```
sudo mkdir keycloak
```
Se positionner dans le répertoire nouvellement créé :
```
cd keycloak
```
Créer un fichier docker-compose.yml :
```
sudo 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).

Copier / Coller le fichier suivant :

version: '3.3'

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: 'true'
 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.

Le port de keycloak dans le conteneur est le 8080, il sera bind sur le 9090 du serveur.

La directive PROXY_ADDRESS_FORWARDING est très importante dans le cas d'une utilisation de reverse proxy.

Lancement du docker-compose

Exécuter le docker-compose :

sudo docker-compose -f ~/keycloak/docker-compose.yml up

Pour lancer le docker-compose en arrière-plan :

sudo docker-compose -f ~/keycloak/docker-compose.yml up -d

Vérifier que les conteneurs docker soient bien démarrés :
```
sudo docker ps
```

Le résultat soit être similaire à :

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
643f26101b75 jboss/keycloak:latest "/opt/jboss/tools/do…" About a minute ago Up 52 seconds 8443/tcp, 0.0.0.0:9090->8080/tcp keycloak_keycloak_1
6789a8285283 postgres "docker-entrypoint.s…" 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.

S'appuyer sur cet article : Nginx : Installation d’un Reverse Proxy
Les certificats SSl doivent être générés.

S'appuyer sur cet article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS
Créer le fichier de configuration du virtual host :
```
sudo vi /etc/nginx/sites-available/keycloak.conf
```

Copier / Coller le fichier suivant :

server {
 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 :

sudo ln -s /etc/nginx/sites-available/keycloak.conf /etc/nginx/sites-enabled/keycloak.conf

Vérifier la configuration de Nginx avec :
```
sudo nginx -t
```
Redémarrer le service nginx :
```
sudo systemctl restart nginx
```

Accès administrateur à Keycloak

Se rendre à l'adresse : https://keycloak.example.com
Accéder à Administration Console :

Les credentials à entrer sont ceux définit dans le fichier docker-compose.yml aux lignes suivantes :
 KEYCLOAK_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é.
Pour 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 :
```
restart: 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é.
Pour que cela soit fonctionnel, le service docker.service doit être en status enable :
```
sudo systemctl status docker.service
```

Le résultat doit être le suivant :

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Si cela n'est pas le cas :
```
sudo systemctl enable docker.service
```

Tactical RMM : Agent installation

Thu, 21 Oct 2021 10:35:03 +0200

A lire

Pour l'instant seul un agent Windows est pleinement fonctionnel. Les versions Linux et macOS sont en cours de développement.
Afin d'éviter la détection de l'agent par l'antivirus, 2 solutions :
- Agent 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.
- Agent 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.
Penser à vérifier vos exclusions antivirus une fois l'agent Windows déployé:
```
C:\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.
Par défaut les mises à jour Windows sont désactivées automatiquement après l'installation de l'agent.

Déploiement agent

L'exécution de l'installation des agents doit être effectué sur les hôtes à surveiller.

Déploiement manuel

Se rendre sur https://rmm.example.com.
Clic droit sur le client/site puis Install Agent.
Vérifier que le Client et le Site soient corrects.
Définir le type de machine (Server / Workstation) à qui s'adresse l'agent.
Définir le temps de validité de l'agent (Token expiration).
Définir les options appliqués par l'agent (Enable RDP, Enable Ping, Disable sleep/hibernate).
Sélectionner la méthode d'installation souhaitée :
- Agent 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.
- Powershell : Génération d'un script Powershell. L'agent est générique et le scripts contient tous les paramètres de l'agent.
- Autoriser l'exécution du script Powershell :
```
PS C:\> 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.

Lien de déploiement

A partir du client, se rendre sur https://rmm.example.com.
Menu Agents puis Manage Deployments.

Astuce : 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é.

L'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.

Récupérer le script d'installation de l'installation manuelle (voir plus haut) ainsi que l'exécutable de l'agent générique.
Stocker le script et l'agent.exe dans un dossier partager du contrôleur de domaine (exemple: C:\agent_rmm\).
Sur le domaine Windows, ouvrir la console MMC des GPOs :

gpmc.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.
- La 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 :

gpupdate /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 :
- -log debug : Affiche un log verbeux lors de l'installation de l'agent
- -silent : Aucun message durant l'installation de l'agent
- -proxy "http://proxyserver:port" : Pour utiliser un proxy
- -meshdir "C:\Mesh Agent" : Spécifier le chemin contenant meshagent.exe
- -nomesh : N'installe pas l'agent meshcentral. Pas de take control, remote terminal, file browser

Tactical RMM : Mise à jour du serveur

Wed, 20 Oct 2021 19:43:10 +0200

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.

Ne 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.
De 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.
Toujours 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.

Mise à 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).

Warning

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.
Cette 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.

Tactical RMM : Les commandes de management

Wed, 20 Oct 2021 19:12:35 +0200

Environnement virtuel Python

Se connecter en SSH au serveur Tactical RMM.

Lancer l'environnement virtuel python :

cd /rmm/api/tacticalrmm
source ../env/bin/activate

Les commandes

Reset a user's password :

python manage.py reset_password USERNAME

Reset a user's 2fa token :
```
python manage.py reset_2fa USERNAME
```
Find all agents that have X software installed :
```
python manage.py find_software "adobe"
```
Show outdated online agents :
```
python manage.py show_outdated_agents
```
Log out all active web sessions :
```
python manage.py delete_tokens
```
Check for orphaned tasks on all agents and remove them :
```
python manage.py remove_orphaned_tasks
```
Create a MeshCentral agent invite link :
```
python manage.py get_mesh_exe_url
```
Bulk update agent offline/overdue time :
- Change 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 "Example Site" 2
```
- Change offline time on all agents in client named Example Client to 12 minutes :
```
python manage.py bulk_change_checkin --offline --client "Example Client" 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 "Example Site" 4
```
- Change overdue time on all agents in client named Example Client to 14 minutes :
```
python manage.py bulk_change_checkin --overdue --client "Example Client" 14
```

OpenProject : Installation

Wed, 20 Oct 2021 14:55:58 +0200

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 :
```
sudo apt install gnupg2
```

Importer la clef PGP utilisées pour signer les paquets openproject :

wget -qO- https://dl.packager.io/srv/opf/openproject/key | sudo apt-key add -

Ajouter le repo adéquat :

sudo 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 :

sudo 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.

Si 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 :
```
sudo 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’édition

OpenProject est fournit avec 2 éditions :
- L'é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.
La slection de l'édition est uniquement disponible sur les distributions suivantes :
- RHEL/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.
Cette étape va permettre de sélectionner la méthode de connexion à cette base de données.
3 options :
- Skip : 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="postgresql://[user[:password]@][host][:port][/dbname][?param1=value1&...]"
```
- Install : Le wizard installe et configure une base de données PostgreSQL locale. C'est cette option qui sera retenu dans cette documentation.
- Reuse : Pour utiliser une base de données PostgreSQL existante. Des paramètres de connexion supplémentaire sont demandés lors de ce choix.

Apache2

OpenProject comprend un serveur d'application en ruby interne. Seulement le serveur écoute uniquement sur une interface locale.
Pour 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.
Le wizard propose d'installer automatiquement un serveur web Apache2 pour agir comme un proxy.
2 options :
- Install : 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.
- Le nom de domaine pleinement qualifié. Correspond à la valeur ServerNamedu virtual host d'apache.
- Pour 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.
- Pour utiliser des certificats SSL/TLS, 3 choix supplémentaires sont à faire pour spécifier l'accès aux certificats.
- Skip : Non recommandé. Un serveur web Apache ou Nginx doit être installé et configuré manuellement pour rediriger les requêtes entrantes vers localhost:6000.
Attention avec un serveur Nginx, toutes les fonctionnalités ne sont pas disponible pour OpenProject.

SVN/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.
Plus d'informations ici

Configuration email

Configurer la méthode d'envoie de mail pour les diverses notifications.
3 options :
- Sendmail : 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 "toujours" être faites.

Accès OpenProject

L'installation est terminée.
L'application OpenProject est disponible à l'adresse : http(s)://openproject.example.com/server prefix.
Username = admin
Password = admin
Changer le mot de passe admin immédiatement

Mise à jour PostgreSQL

La version actuelle d'OpenProject est la 11.4.0.
La prochaine version majeure sera la 12.0 (fin 2021).
PostgreSQL v13 sera nécessaire.

Installer la nouvelle version de PostgreSQL :

sudo apt-get update
sudo apt-get install postgresql-13

Arrêter les serveurs PostgreSQL :

sudo su - postgres -c "/usr/lib/postgresql/10/bin/pg_ctl stop --wait --pgdata=/var/lib/postgresql/10/main"
sudo su - postgres -c "/usr/lib/postgresql/13/bin/pg_ctl stop --wait --pgdata=/var/lib/postgresql/13/main"

Migrer les données vers PostgreSQL v13 :

sudo su - postgres << 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 '-c config_file=/etc/postgresql/10/main/postgresql.conf' \
--new-options '-c config_file=/etc/postgresql/13/main/postgresql.conf'
CMD

Faire de PostgreSQL v13 le serveur par défaut sur le port 45432 :

sudo su - postgres -c "cp /etc/postgresql/{10,13}/main/conf.d/custom.conf"
sudo su - postgres -c "sed -i 's|45432|45433|' /etc/postgresql/10/main/conf.d/custom.conf"
sudo su - postgres -c "/usr/lib/postgresql/13/bin/pg_ctl start --wait --pgdata=/var/lib/postgresql/13/main -o '-c config_file=/etc/postgresql/13/main/postgresql.conf'"

Vérifier dans OpenProject la version de PostgreSQL.

Supprimer l'ancienne version de PostgreSQL :

sudo rm -rf /var/lib/postgresql/10/main
sudo apt-get purge postgresql-10

Redmine : Installation

Mon, 18 Oct 2021 12:24:49 +0200

Préambule

Redmine peut être installé sur la plupart des systèmes Unix, Linux, macOS, Windows
La base de données qu'utilise Redmine peut être MySQL (MariaDB), PostgreSQL, Microsoft SQL, SQLite
Debian 10 sera choisit pour cette installation avec une base de données MySQL (MariaDB)

Installation Apache et paquets nécessaires

Installation dépendances nécessaires :

sudo apt install apt-transport-https ca-certificates dirmngr gnupg2

Installation Apache, MariaDB, Passenger et les autres paquets nécessaires :

sudo 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

Création de la base de données

Sécurisation de la base de données :
```
sudo mysql_secure_installation
```

Suivre les recommandations de sécurisation

Se connecter en root puis à MariaDB :
```
su -
mysql
```

Création d'une base de données "redminedb" et d'un utilisateur mysql "redmineuser" :

CREATE DATABASE redminedb CHARACTER SET utf8mb4;
GRANT ALL PRIVILEGES ON redminedb.* TO 'redmineuser'@'localhost' IDENTIFIED BY 'my_secure_password';

Flush les privilèges et quitter MariaDB :
```
FLUSH PRIVILEGES;
EXIT;
```
Se déconnecter de l'utilisateur root :
```
exit
```

Installation et configuration Redmine

Création d'un utilisateur linux "redmine" pour Redmine :

sudo useradd -r -m -d /opt/redmine -s /usr/bin/bash redmine

Ajout de l'utilisateur redmine au groupe "www-data" :
```
sudo usermod -aG redmine www-data
```
Se connecter avec l'utilisateur redmine et télécharger la dernière version de Redmine :
```
su - redmine
wget https://www.redmine.org/releases/redmine-4.2.3.tar.gz
```

Extraire l'archive téléchargée :

tar -xvzf redmine-4.2.3.tar.gz -C /opt/redmine/ --strip-components=1

Copie des fichiers de configurations exemples :

cp /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 :
```
vi /opt/redmine/config/database.yml
```

Faire les modifications suivantes :

production:
adapter: mysql2
database: redminedb
host: localhost
username: redmineuser
password: "my_secure_password"

Sauvegarder le fichier et quitter l'utilisateur redmine :
```
exit
```
Se rendre dans le répertoire "/opt/redmine" et installer "Bundler" :
```
cd /opt/redmine
sudo gem install bundler
```
Se connecter avec l'utilisateur redmine et installer les dépendances gems nécessaires :
```
su - redmine
bundle install --without development test --path vendor/bundle
```
Générer un token secret :
```
bundle 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 :

RAILS_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 :

for i in tmp tmp/pdf public/plugin_assets; do [ -d $i ] || mkdir -p $i; done

Définir les permission sur le dossier /opt/redmine :

chown -R redmine:redmine files log tmp public/plugin_assets
chmod -R 755 /opt/redmine

Se déconnecter de l'utilisateur Redmine :
```
exit
```

Configuration Apache

Désactiver le site par défaut :
```
sudo a2dissite 000-default.conf
```

Créer un virtual host pour Redmine :

sudo vi /etc/apache2/sites-available/redmine.conf

Ajout des lignes suivantes :

< VirtualHost *:80>
ServerName redmine.example.com
RailsEnv production
DocumentRoot /opt/redmine/public

< Directory "/opt/redmine/public">
 Allow from all
 Require all granted
< /Directory>

ErrorLog ${APACHE_LOG_DIR}/redmine_error.log
CustomLog ${APACHE_LOG_DIR}/redmine_access.log combined
< /VirtualHost>

Attention ! Enlever l'espace après le 1er chevron.

Sauvegarder le fichier, activer le virtual host redmine et redémarrer le service apache :
```
sudo a2ensite redmine
sudo systemctl restart apache2
```

Accès Redmine

Ouvrir un navigateur web et se rendre sur http://redmine.example.com
Cliquer sur "Connexion"
Renseigner le compte admin et le mot de passe par défaut : admin/admin. Un nouveau mot de passe est demandé
L'installation de Redmine est terminée

Ansible : Déploiement de 3 routeurs Linux en milieu hétérogène

Sat, 16 Oct 2021 09:20:29 +0200

Contexte de l’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’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.

Modification 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’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.

su - ansible

Création de l’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 && ssh-copy-id root@rnat-12 && 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.

Une 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 <le fichier d'inventaire>

-m <le module à utiliser>

Le dernier argument routeurs correspond au type de serveur, définit dans l’inventaire, sur lequel exécuter le module.

RNAT-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.

A 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é.

Une 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’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} && 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.
Création du fichier de configuration IP pour RNAT-11 :

vi 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.
Création des fichiers de configuration IP pour RNAT-12 :

vi 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.
Création des fichiers de configuration IP pour RNAT-13 :

vi 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.

Cré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 == "rnat-11" and ansible_distribution == "Debian"

 - name: Activation des cartes réseaux pour RNAT-11
 shell: |
 ip l set ens32 up
 ip l set ens34 up
 when: ansible_hostname == "rnat-11" and ansible_distribution == "Debian"

 - name: Redémarrage du service réseau pour RNAT-11
 service:
 name: networking
 state: restarted
 when: ansible_hostname == "rnat-11" and ansible_distribution == "Debian"

 - 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 == "rnat-11" and ansible_distribution == "Debian"

 - name: Activation du routage IPv4 permanent pour RNAT-11
 shell: |
 sysctl -p
 when: ansible_hostname == "rnat-11" and ansible_distribution == "Debian"

 - 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 == "rnat-11" and ansible_distribution == "Debian"

 - name: Mise en persistence du SNAT pour RNAT-11
 apt:
 name: iptables-persistent
 state: present
 when: ansible_hostname == "rnat-11" and ansible_distribution == "Debian"

 - name: Suppression des configurations IP existantes pour RNAT-12
 shell: |
 warn: false
 rm /etc/netplan/*.yaml
 when: ansible_hostname == "rnat-12" and ansible_distribution == "Ubuntu"

 - 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 == "rnat-12" and ansible_distribution == "Ubuntu"

 - 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 == "rnat-12" and ansible_distribution == "Ubuntu"

 - name: Activation des cartes réseaux pour RNAT-12
 shell: |
 ip l set ens32 up
 ip l set ens35 up
 when: ansible_hostname == "rnat-12" and ansible_distribution == "Ubuntu"

 - name: Application de la configuration IP pour RNAT-12
 shell: |
 netplan apply
 when: ansible_hostname == "rnat-12" and ansible_distribution == "Ubuntu"

 - 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 == "rnat-12" and ansible_distribution == "Ubuntu"

 - name: Activation du routage IPv4 permanent pour RNAT-12
 shell: |
 sysctl -p
 when: ansible_hostname == "rnat-12" and ansible_distribution == "Ubuntu"

 - 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 == "rnat-12" and ansible_distribution == "Ubuntu"

 - name: Mise en persistence du SNAT pour RNAT-12
 apt:
 name: iptables-persistent
 state: present
 when: ansible_hostname == "rnat-12" and ansible_distribution == "Ubuntu"

 - 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 == "rnat-13" and ansible_distribution == "CentOS"

 - 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 == "rnat-13" and ansible_distribution == "CentOS"

 - name: Activation des cartes réseaux pour RNAT-13
 shell: |
 ip l set ens33 up
 ip l set ens32 up
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Redémarrage du service réseau pour RNAT-13
 service:
 name: network
 state: restarted
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - 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 == "rnat-13" and ansible_distribution == "CentOS"

 - name: Activation du routage IPv4 permanent pour RNAT-13
 shell: |
 echo 1 > /proc/sys/net/ipv4/ip_forward
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Suppression de firewalld pour RNAT-13
 yum:
 name: firewalld
 state: absent
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Installation des services iptables pour RNAT-13
 yum:
 name: iptables-services
 state: present
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Démarrage des services iptables pour RNAT-13
 service:
 name: iptables
 state: started
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Purge des règles iptables existantes pour RNAT-13
 shell: |
 iptables -F
 iptables -X
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - 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 == "rnat-13" and ansible_distribution == "CentOS"

 - name: Sauvegarde des règles iptables pour RNAT-13
 shell: |
 warn: false
 service iptables save
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

 - name: Chargement des services iptables au démarrage pour RNAT-13
 shell: |
 chkconfig iptables on
 when: ansible_hostname == "rnat-13" and ansible_distribution == "CentOS"

Le playbook est format YAML ce qui signifie que l’indentation doit se faire avec des espaces et non avec des tabulations.

Exé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.

Nginx : Reverse Proxy avec SSL

Fri, 15 Oct 2021 15:00:06 +0200

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.

proxy_pass : L'URL http / https vers le serveur hébergeant blog.example.com.

Vé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

Tactical RMM : Présentation et installation

Fri, 15 Oct 2021 14:48:51 +0200

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.
Lors de mes recherches, de nombreuses solutions se sont révélées être intéressantes (SolarWinds RMM, NinjaRMM, etc...).
Comme vous le savez, chez AukFood, on ne mange qu'OpenSource.
De ce fait, une solution s'est révélée pertinente : Tactical RMM (Remote Monitoring & Management)

Tactical RMM fournit une interface web pour la gestion de flotte d'ordinateur permettant :

La 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.
Le serveur web utilisé est Nginx et la base de données MongoDB.
Cette solution est directement inspirée de l'outil commercial SolarWinds RMM (un des leaders du marché dans le RMM).
Contrairement à toutes les solutions de RMM performantes, celle-ci est sous licence MIT et est donc libre.

Actuellement, seul un agent Windows x86 et x64 sont disponibles. Un agent Linux et macOS sont en cours de développement.
Les versions de Windows supportés sont : Windows 7, 8.1, 10, Server 2008R2, 2012R2, 2016, 2019.

Pour 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.

Installation

2 méthodes d'installation sont possibles :

Classique / 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.
Un 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...)
Pour la connexion à la Web UI, il faudra vous munir d'un des navigateurs suivants :

Chrome >= 93
Edge >= 93
Firefox >= 92
Safari >= 15

Let's Go Pinguy !

Prérequis

Mise à jour système et installation des prérequis.

apt update
apt install -y wget curl sudo
apt -y upgrade

Si un nouveau kernel a été installé, redémarrez dessus.

Création d’un utilisateur

Créez un utilisateur "tactical" et ajoutez-le au groupe sudoers.

useradd -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.

Ouverture des ports

Configurez votre pare-feu :

Port TCP 443 : Accès Web UI
Port TCP 22 : Accès SSH
Port TCP 4222 : Communication avec l'agent

Script d’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.

Basculez sur l'utilisateur tactical.

su - tactical

Téléchargez et exécutez le script d'installation.

wget 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.

Enregistrement 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.

Une fois la propagation de l'entrée DNS effectuée, vérifiez celle-ci.

dig -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.

Cré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

Un résumé de toutes les informations de connexions sera affiché à la fin du processus d'installation.

MFA 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.

Nous vous recommandons l'utilisation d'une application mobile OpenSource comme PrivacyIDEA ou Authy.

Récupération de l’agent

Récupérez l'agent via https://mesh.example.com:443/agentinvite?c=abcdef.

Ce lien sera affiché dans le résumé affiché à la fin de l'installation.

Configuration initiale

Rendez-vous sur https://rmm.example.com.

Créez le premier client/site.
Définissez le fuseau horaire.
Uploadez l'agent RMM préalablement récupéré.

L'installation est terminée.

Fonctionnalités (aperçus)

Voici quelques captures des fonctionnalités disponibles (non exhaustives).

Summary

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.
C'est une solution alternative parfaitement viable face aux concurrents propriétaires.

Dans 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...

Source

Projet : GitHub - wh1te909/tacticalrmm: A remote monitoring & management tool, built with Django, Vue and Go.

Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Fri, 15 Oct 2021 14:05:01 +0200

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’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

-d www.example.com : Pour préciser le nom de domaine

Votre 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.

Certbot 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

Renouvellement 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

Le message "Congratulations, all renewals succeded." 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.

Nginx : Installation d’un Reverse Proxy

Fri, 15 Oct 2021 13:50:26 +0200

Préambule

Un des outils reverse proxy le + populaires du moment est Nginx
Un 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é.
Le 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.
Nginx en tant que reverse proxy permet :
- Load balancing
- Améliore la sécurité
- Meilleur performance
- Point de terminaison SSL

Installation d’un reverse proxy avec Nginx

Une Debian 10 sera utilisée avec 4GB de RAM, 2 vCPU, 20GB de disque

Installer Nginx

Installer Nginx :
```
sudo apt install nginx
```
Après l'installation, vous pouvez vérifier que Nginx c'est correctement installé en vérifiant la version :
```
nginx -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
Nous devons configurer un reverse proxy avec Nginx pour rediriger les requêtes à destination de blog.example.com vers le serveur 172.0.1.10
Désactivez le vhost pré-configuré par défaut :
```
unlink /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 :
```
cd /etc/nginx/sites-available
sudo vim example.conf
```

Collez cette configuration Nginx :

server {
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

Sauvegardez le fichier et activez le en créant un lien symbolique :

sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/

Testez Nginx pour d'éventuelles erreurs de configuration :

sudo 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 :
```
sudo systemctl restart nginx
```
C'est terminé !

Posts on slash-root.fr

OPNsense : Serveur WireGuard et client KDE en split tunnel

Prérequis

Partie 1 : OPNsense, le serveur WireGuard

Création de l’instance

Création du peer client

Méthode alternative : le Peer Generator

Activation de WireGuard

Assigner une interface (recommandé)

Règles firewall

1. Autoriser les connexions entrantes sur le WAN

2. Autoriser le trafic depuis le tunnel vers le LAN

Normalisation MSS (optionnel mais fortement recommandé)

NAT outbound

Partie 2 : KDE, le client WireGuard

Génération des clés

Fichier de configuration wg0.conf

Import dans NetworkManager

En ligne de commande (plus fiable)

En graphique (KDE Plasma)

Vérifications

Conclusion

KDE : double-clic sur un ISO pour le monter

La solution

Aptly : mirroiter Debian proprement

Ce qu’aptly fait vraiment

Installation

Via les paquets Debian

L’upstream (optionnel)

Configuration de base

Importer les clés GPG

Créer un miroir de Debian Trixie

Remplir le miroir

Créer un snapshot

Publier le snapshot

L’impact des hard links

Mettre à jour le miroir et basculer

Les dépôts locaux (mention rapide)

Exposer le dépôt

Le serveur embarqué (test uniquement)

nginx (production)

Automatiser avec cron

Nettoyage et maintenance

Quelques astuces

Conclusion

awaSCII+ Web : Quand l’encodage devient un art de vivre

Préambule

Le projet qui fait "awa"

Comment ça marche ?

Pourquoi une interface web ?

Features qui claquent

Le mot de la fin

Zoxide : Une alternative intelligente à la commande cd

Introduction

Qu’est-ce que zoxide ?

Installation sur Debian/Ubuntu et dérivés

Installation via les dépôts officiels

Méthodes alternatives d’installation

Via le script d’installation officiel

Via Cargo (si Rust est installé)

Via Homebrew sur Linux

Prérequis recommandé : fzf

Configuration avec zoxide init

Configuration pour Bash

Configuration pour Zsh

Configuration pour Fish

Rechargement de la configuration

Utilisation de base

La commande z

La commande zi (navigation interactive)

Autocomplétion

Bonus : Alias cd='z'

Méthode recommandée : Configuration automatique via zoxide init

Alternative : Alias manuel

Options de configuration avancées

Personnalisation du préfixe des commandes

Contrôle de la fréquence d’enregistrement

Exemples pratiques d’utilisation

Scénario 1 : Développement web

Scénario 2 : Administration système

Fichier de configuration `wg0.conf`

Configuration avec `zoxide init`

La commande `z`

La commande `zi` (navigation interactive)

Bonus : Alias `cd='z'`

Comparaison avec `autojump`

Comparaison avec `z.sh`