feat: view_previews debloque les avant-premieres sur accueil et article
This commit is contained in:
Cedric Abonnel
@@ -0,0 +1,134 @@
|
||||
Une fois le système de base configuré (dépôts, mises à jour, `sudo`, identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.
|
||||
|
||||
## Sécuriser l'accès SSH
|
||||
|
||||
SSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.
|
||||
|
||||
### Passer à l'authentification par clé
|
||||
|
||||
Les mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.
|
||||
|
||||
Côté poste de travail, on génère une paire de clés modernes :
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -C "cedrix@laptop"
|
||||
```
|
||||
|
||||
L'algorithme `ed25519` est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire (`-C`) facilite l'identification de la clé quand on en gère plusieurs.
|
||||
|
||||
On copie ensuite la clé publique sur le serveur :
|
||||
|
||||
```bash
|
||||
ssh-copy-id utilisateur@serveur
|
||||
```
|
||||
|
||||
Cette commande dépose la clé publique dans `~/.ssh/authorized_keys` côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.
|
||||
|
||||
### Désactiver la connexion root et les mots de passe
|
||||
|
||||
Une fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est `/etc/ssh/sshd_config` :
|
||||
|
||||
```bash
|
||||
sudo nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
Les directives importantes à positionner (ou décommenter) sont :
|
||||
|
||||
```
|
||||
PermitRootLogin no
|
||||
PasswordAuthentication no
|
||||
PubkeyAuthentication yes
|
||||
```
|
||||
|
||||
La première interdit toute connexion directe en `root` via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via `sudo`. La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.
|
||||
|
||||
On recharge ensuite le service pour appliquer les changements :
|
||||
|
||||
```bash
|
||||
sudo systemctl reload ssh
|
||||
```
|
||||
|
||||
Important : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.
|
||||
|
||||
Pour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.
|
||||
|
||||
## Mettre en place un pare-feu
|
||||
|
||||
Par défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : `nftables` (le successeur officiel d'`iptables`, bas niveau et puissant) et `ufw` (une surcouche pensée pour la simplicité). Pour démarrer, `ufw` est le bon compromis.
|
||||
|
||||
```bash
|
||||
sudo apt install ufw
|
||||
```
|
||||
|
||||
La logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :
|
||||
|
||||
```bash
|
||||
sudo ufw default deny incoming
|
||||
sudo ufw default allow outgoing
|
||||
sudo ufw allow ssh
|
||||
sudo ufw enable
|
||||
```
|
||||
|
||||
Si SSH écoute sur un port non standard, remplacer `ufw allow ssh` par `ufw allow 2222/tcp` (ou le port choisi). Oublier cette étape avant un `ufw enable` est un grand classique du verrouillage involontaire.
|
||||
|
||||
Pour les services web, on ouvrira typiquement les ports 80 et 443 :
|
||||
|
||||
```bash
|
||||
sudo ufw allow 80/tcp
|
||||
sudo ufw allow 443/tcp
|
||||
```
|
||||
|
||||
L'état du pare-feu se vérifie avec :
|
||||
|
||||
```bash
|
||||
sudo ufw status verbose
|
||||
```
|
||||
|
||||
Sur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.
|
||||
|
||||
## Automatiser les correctifs de sécurité
|
||||
|
||||
Les failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement `apt upgrade` chaque matin sur dix machines. Le paquet `unattended-upgrades` applique automatiquement les mises à jour du dépôt `security`.
|
||||
|
||||
```bash
|
||||
sudo apt install unattended-upgrades
|
||||
sudo dpkg-reconfigure --priority=low unattended-upgrades
|
||||
```
|
||||
|
||||
La configuration se trouve ensuite dans `/etc/apt/apt.conf.d/50unattended-upgrades`. Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.
|
||||
|
||||
Quelques options qui méritent l'attention dans ce fichier :
|
||||
|
||||
- `Unattended-Upgrade::Automatic-Reboot` : à régler sur `"true"` si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou `"false"` si l'on préfère les piloter à la main. La directive `Automatic-Reboot-Time` permet alors de choisir l'horaire.
|
||||
- `Unattended-Upgrade::Mail` : pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.
|
||||
|
||||
Le bon réflexe consiste à vérifier de temps en temps les logs dans `/var/log/unattended-upgrades/` pour s'assurer que tout se déroule sans heurts.
|
||||
|
||||
## Soigner les détails opérationnels
|
||||
|
||||
Quelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.
|
||||
|
||||
**Fail2ban** surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :
|
||||
|
||||
```bash
|
||||
sudo apt install fail2ban
|
||||
```
|
||||
|
||||
La configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans `/etc/fail2ban/jail.d/`.
|
||||
|
||||
**Logwatch** ou **journalctl** méritent qu'on s'y attarde. Sur une Debian récente, `journalctl` est l'outil central pour consulter les logs systemd :
|
||||
|
||||
```bash
|
||||
journalctl -u ssh --since "1 hour ago"
|
||||
journalctl -p err --since today
|
||||
```
|
||||
|
||||
Prendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.
|
||||
|
||||
**Un swap raisonnable**, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.
|
||||
|
||||
## Et après ?
|
||||
|
||||
Avec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.
|
||||
|
||||
Comme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif.
|
||||
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"uuid": "0bba1ad7-e4cb-49a6-9467-fcfac2e09a93",
|
||||
"slug": "deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian",
|
||||
"title": "Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian",
|
||||
"author": "cedric@abonnel.fr",
|
||||
"published": true,
|
||||
"published_at": "2026-06-08 07:00",
|
||||
"created_at": "2026-05-12 23:01:34",
|
||||
"updated_at": "2026-05-12 23:01:34",
|
||||
"revisions": [],
|
||||
"cover": "",
|
||||
"files_meta": [],
|
||||
"external_links": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "",
|
||||
"og_image": "",
|
||||
"category": "informatique"
|
||||
}
|
||||
@@ -0,0 +1,107 @@
|
||||
Lorsqu'on vient de provisionner une machine Debian — que ce soit un conteneur LXC, une VM ou un serveur dédié — quelques étapes initiales sont incontournables avant de pouvoir vraiment travailler dessus. Ce petit guide reprend les gestes de base : passer en `root`, configurer les dépôts officiels, mettre le système à jour, installer `sudo`, et terminer par quelques réglages d'identification qui éviteront des surprises plus tard. Rien de sorcier, mais autant prendre de bonnes habitudes dès le départ.
|
||||
|
||||
## Passer en utilisateur root
|
||||
|
||||
La première étape consiste à obtenir les droits administrateur. Sur une Debian fraîche, l'utilisateur `root` existe déjà et possède un mot de passe défini lors de l'installation. Pour ouvrir une session avec son environnement complet (variables, PATH, répertoire personnel), on utilise :
|
||||
|
||||
```bash
|
||||
su - root
|
||||
```
|
||||
|
||||
Le tiret est important : sans lui, on hérite uniquement de l'UID de root sans charger son shell de connexion, ce qui peut donner lieu à des surprises (PATH incomplet, absence de `/sbin` dans la recherche des commandes, etc.).
|
||||
|
||||
À noter que si `sudo` est déjà installé et que l'utilisateur courant fait partie du groupe `sudo`, on peut aussi écrire `sudo -i` pour obtenir le même résultat. Mais sur une Debian minimale tout juste installée, `sudo` n'est généralement pas présent — d'où la nécessité de passer par `su` dans un premier temps.
|
||||
|
||||
## Configurer les dépôts officiels
|
||||
|
||||
Debian s'appuie sur APT pour gérer ses paquets, et APT a besoin de savoir où les chercher. Cette configuration se trouve dans le fichier `/etc/apt/sources.list` (et, sur les versions récentes, éventuellement dans `/etc/apt/sources.list.d/` pour les dépôts additionnels).
|
||||
|
||||
On l'ouvre avec un éditeur de texte :
|
||||
|
||||
```bash
|
||||
nano /etc/apt/sources.list
|
||||
```
|
||||
|
||||
Un contenu typique pour Debian 12 (Bookworm) ressemble à ceci :
|
||||
|
||||
```
|
||||
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
|
||||
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
|
||||
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
|
||||
```
|
||||
|
||||
Quelques explications rapides sur les composants :
|
||||
|
||||
- **main** contient les paquets libres officiellement supportés par Debian
|
||||
- **contrib** regroupe les paquets libres qui dépendent de logiciels non libres
|
||||
- **non-free** et **non-free-firmware** contiennent les paquets non libres (utiles notamment pour les pilotes matériels)
|
||||
|
||||
Le dépôt `bookworm-updates` apporte les mises à jour stables non urgentes, tandis que `bookworm-security` fournit les correctifs de sécurité — celui-ci est essentiel et ne doit jamais être omis sur une machine connectée au réseau.
|
||||
|
||||
Pour une version différente de Debian, il suffit de remplacer `bookworm` par le nom de code correspondant (`bullseye`, `trixie`, etc.).
|
||||
|
||||
## Mettre le système à jour
|
||||
|
||||
Une fois les dépôts configurés, on récupère la liste des paquets disponibles puis on applique les mises à jour :
|
||||
|
||||
```bash
|
||||
apt update
|
||||
apt upgrade
|
||||
```
|
||||
|
||||
La distinction entre les deux est importante :
|
||||
|
||||
- `apt update` ne met rien à jour : la commande synchronise simplement l'index local des paquets avec ce que les dépôts annoncent. Sans cette étape, APT ignore l'existence des nouvelles versions.
|
||||
- `apt upgrade` installe effectivement les versions plus récentes des paquets déjà présents.
|
||||
|
||||
Pour les mises à jour plus profondes qui peuvent ajouter ou retirer des paquets (changement de dépendances, transitions majeures), il existe aussi `apt full-upgrade`. À utiliser avec un peu plus de précaution, mais c'est ce qu'il faut pour suivre l'évolution complète d'une distribution.
|
||||
|
||||
Sur un conteneur ou une VM fraîche, cette première mise à jour peut tirer un certain nombre de paquets. C'est normal : l'image de base est figée au moment de sa publication, et plusieurs mois de correctifs se sont souvent accumulés depuis.
|
||||
|
||||
Petit conseil pour la suite, dès qu'on commencera à scripter ces opérations : préférer `apt-get` à `apt` dans les scripts, car son interface est garantie stable entre versions. Et pour éviter les questions interactives bloquantes lors d'installations automatisées, positionner `DEBIAN_FRONTEND=noninteractive` dans l'environnement.
|
||||
|
||||
## Installer sudo
|
||||
|
||||
Par défaut, Debian n'installe pas `sudo` sur un système minimal. Travailler en permanence en `root` n'est pourtant pas une bonne pratique : on perd la traçabilité des actions, et la moindre erreur de frappe peut avoir des conséquences sérieuses. L'idée derrière `sudo` est de déléguer ponctuellement des droits administrateur à un utilisateur normal, commande par commande, avec un journal des actions effectuées.
|
||||
|
||||
L'installation se fait classiquement :
|
||||
|
||||
```bash
|
||||
apt install sudo
|
||||
```
|
||||
|
||||
Ensuite, il faut ajouter son utilisateur (celui avec lequel on se connectera au quotidien) au groupe `sudo` :
|
||||
|
||||
```bash
|
||||
usermod -aG sudo nom_utilisateur
|
||||
```
|
||||
|
||||
Le drapeau `-a` (pour *append*) est crucial : sans lui, `usermod -G` remplacerait la liste des groupes secondaires de l'utilisateur au lieu d'y ajouter `sudo`, ce qui peut avoir des effets de bord désagréables.
|
||||
|
||||
L'utilisateur doit ensuite se déconnecter puis se reconnecter pour que sa nouvelle appartenance au groupe soit prise en compte. À partir de là, il peut préfixer ses commandes par `sudo` pour les exécuter avec les droits administrateur, en saisissant son propre mot de passe (et non celui de root).
|
||||
|
||||
## Régler l'identité et l'horloge de la machine
|
||||
|
||||
Deux derniers détails de configuration qui paraissent anodins, mais qui simplifient grandement la vie sur un parc qui grandit.
|
||||
|
||||
D'abord, fixer le nom de la machine. Sur une infrastructure organisée, le hostname et le FQDN suivent généralement une convention de nommage (par exemple `dafactures.acegrp.lan` pour un projet de facturation sur un réseau interne). La commande `hostnamectl` s'en charge proprement :
|
||||
|
||||
```bash
|
||||
hostnamectl set-hostname dafactures.acegrp.lan
|
||||
```
|
||||
|
||||
Penser à vérifier ensuite que `/etc/hosts` contient bien une ligne associant l'IP locale au FQDN, sous peine de voir certains services (Postfix notamment, ou des outils de log) se plaindre de ne pas résoudre leur propre nom.
|
||||
|
||||
Ensuite, le fuseau horaire. Détail souvent négligé qui complique pourtant le débogage dès qu'on croise des logs entre plusieurs machines :
|
||||
|
||||
```bash
|
||||
timedatectl set-timezone Europe/Paris
|
||||
```
|
||||
|
||||
La synchronisation NTP est généralement déjà active via `systemd-timesyncd` sur les Debian récentes — un `timedatectl status` permet de le vérifier.
|
||||
|
||||
## Et après ?
|
||||
|
||||
Une fois ces étapes franchies, la machine est dans un état sain et utilisable. Les pistes naturelles pour la suite tournent autour du durcissement (configuration SSH avec authentification par clé et désactivation de la connexion root à distance, mise en place d'un pare-feu, installation de `unattended-upgrades` pour les correctifs de sécurité automatiques), puis de l'installation des outils métier proprement dits — serveur web, base de données, runtime applicatif.
|
||||
|
||||
Garder en tête que ces gestes initiaux, aussi triviaux paraissent-ils, méritent d'être scriptés dès qu'on les répète plus de deux ou trois fois. C'est précisément là que la démarche DevOps prend tout son sens : transformer des manipulations manuelles en code reproductible, versionné et partageable.
|
||||
@@ -1,13 +1,20 @@
|
||||
{
|
||||
"uuid": "ad43fd21-ddcf-4ce2-b924-fdaadc8a6cdd",
|
||||
"slug": "post-install",
|
||||
"title": "Post installation Debian",
|
||||
"title": "Premiers pas DevOps : préparer un système Debian fraîchement installé",
|
||||
"author": "cedric@abonnel.fr",
|
||||
"published": true,
|
||||
"published_at": "2023-02-09 15:18:57",
|
||||
"published_at": "2023-02-09 15:18",
|
||||
"created_at": "2023-02-09 15:18:57",
|
||||
"updated_at": "2026-05-12 22:54:18",
|
||||
"revisions": [],
|
||||
"updated_at": "2026-05-12 22:57:49",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
"date": "2026-05-12 22:57:49",
|
||||
"comment": "Contenu modifié",
|
||||
"title": "Premiers pas DevOps : préparer un système Debian fraîchement installé"
|
||||
}
|
||||
],
|
||||
"cover": "",
|
||||
"files_meta": [],
|
||||
"external_links": [],
|
||||
|
||||
@@ -0,0 +1,107 @@
|
||||
Lorsqu'on vient de provisionner une machine Debian — que ce soit un conteneur LXC, une VM ou un serveur dédié — quelques étapes initiales sont incontournables avant de pouvoir vraiment travailler dessus. Ce petit guide reprend les gestes de base : passer en `root`, configurer les dépôts officiels, mettre le système à jour, installer `sudo`, et terminer par quelques réglages d'identification qui éviteront des surprises plus tard. Rien de sorcier, mais autant prendre de bonnes habitudes dès le départ.
|
||||
|
||||
## Passer en utilisateur root
|
||||
|
||||
La première étape consiste à obtenir les droits administrateur. Sur une Debian fraîche, l'utilisateur `root` existe déjà et possède un mot de passe défini lors de l'installation. Pour ouvrir une session avec son environnement complet (variables, PATH, répertoire personnel), on utilise :
|
||||
|
||||
```bash
|
||||
su - root
|
||||
```
|
||||
|
||||
Le tiret est important : sans lui, on hérite uniquement de l'UID de root sans charger son shell de connexion, ce qui peut donner lieu à des surprises (PATH incomplet, absence de `/sbin` dans la recherche des commandes, etc.).
|
||||
|
||||
À noter que si `sudo` est déjà installé et que l'utilisateur courant fait partie du groupe `sudo`, on peut aussi écrire `sudo -i` pour obtenir le même résultat. Mais sur une Debian minimale tout juste installée, `sudo` n'est généralement pas présent — d'où la nécessité de passer par `su` dans un premier temps.
|
||||
|
||||
## Configurer les dépôts officiels
|
||||
|
||||
Debian s'appuie sur APT pour gérer ses paquets, et APT a besoin de savoir où les chercher. Cette configuration se trouve dans le fichier `/etc/apt/sources.list` (et, sur les versions récentes, éventuellement dans `/etc/apt/sources.list.d/` pour les dépôts additionnels).
|
||||
|
||||
On l'ouvre avec un éditeur de texte :
|
||||
|
||||
```bash
|
||||
nano /etc/apt/sources.list
|
||||
```
|
||||
|
||||
Un contenu typique pour Debian 12 (Bookworm) ressemble à ceci :
|
||||
|
||||
```
|
||||
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
|
||||
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
|
||||
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
|
||||
```
|
||||
|
||||
Quelques explications rapides sur les composants :
|
||||
|
||||
- **main** contient les paquets libres officiellement supportés par Debian
|
||||
- **contrib** regroupe les paquets libres qui dépendent de logiciels non libres
|
||||
- **non-free** et **non-free-firmware** contiennent les paquets non libres (utiles notamment pour les pilotes matériels)
|
||||
|
||||
Le dépôt `bookworm-updates` apporte les mises à jour stables non urgentes, tandis que `bookworm-security` fournit les correctifs de sécurité — celui-ci est essentiel et ne doit jamais être omis sur une machine connectée au réseau.
|
||||
|
||||
Pour une version différente de Debian, il suffit de remplacer `bookworm` par le nom de code correspondant (`bullseye`, `trixie`, etc.).
|
||||
|
||||
## Mettre le système à jour
|
||||
|
||||
Une fois les dépôts configurés, on récupère la liste des paquets disponibles puis on applique les mises à jour :
|
||||
|
||||
```bash
|
||||
apt update
|
||||
apt upgrade
|
||||
```
|
||||
|
||||
La distinction entre les deux est importante :
|
||||
|
||||
- `apt update` ne met rien à jour : la commande synchronise simplement l'index local des paquets avec ce que les dépôts annoncent. Sans cette étape, APT ignore l'existence des nouvelles versions.
|
||||
- `apt upgrade` installe effectivement les versions plus récentes des paquets déjà présents.
|
||||
|
||||
Pour les mises à jour plus profondes qui peuvent ajouter ou retirer des paquets (changement de dépendances, transitions majeures), il existe aussi `apt full-upgrade`. À utiliser avec un peu plus de précaution, mais c'est ce qu'il faut pour suivre l'évolution complète d'une distribution.
|
||||
|
||||
Sur un conteneur ou une VM fraîche, cette première mise à jour peut tirer un certain nombre de paquets. C'est normal : l'image de base est figée au moment de sa publication, et plusieurs mois de correctifs se sont souvent accumulés depuis.
|
||||
|
||||
Petit conseil pour la suite, dès qu'on commencera à scripter ces opérations : préférer `apt-get` à `apt` dans les scripts, car son interface est garantie stable entre versions. Et pour éviter les questions interactives bloquantes lors d'installations automatisées, positionner `DEBIAN_FRONTEND=noninteractive` dans l'environnement.
|
||||
|
||||
## Installer sudo
|
||||
|
||||
Par défaut, Debian n'installe pas `sudo` sur un système minimal. Travailler en permanence en `root` n'est pourtant pas une bonne pratique : on perd la traçabilité des actions, et la moindre erreur de frappe peut avoir des conséquences sérieuses. L'idée derrière `sudo` est de déléguer ponctuellement des droits administrateur à un utilisateur normal, commande par commande, avec un journal des actions effectuées.
|
||||
|
||||
L'installation se fait classiquement :
|
||||
|
||||
```bash
|
||||
apt install sudo
|
||||
```
|
||||
|
||||
Ensuite, il faut ajouter son utilisateur (celui avec lequel on se connectera au quotidien) au groupe `sudo` :
|
||||
|
||||
```bash
|
||||
usermod -aG sudo nom_utilisateur
|
||||
```
|
||||
|
||||
Le drapeau `-a` (pour *append*) est crucial : sans lui, `usermod -G` remplacerait la liste des groupes secondaires de l'utilisateur au lieu d'y ajouter `sudo`, ce qui peut avoir des effets de bord désagréables.
|
||||
|
||||
L'utilisateur doit ensuite se déconnecter puis se reconnecter pour que sa nouvelle appartenance au groupe soit prise en compte. À partir de là, il peut préfixer ses commandes par `sudo` pour les exécuter avec les droits administrateur, en saisissant son propre mot de passe (et non celui de root).
|
||||
|
||||
## Régler l'identité et l'horloge de la machine
|
||||
|
||||
Deux derniers détails de configuration qui paraissent anodins, mais qui simplifient grandement la vie sur un parc qui grandit.
|
||||
|
||||
D'abord, fixer le nom de la machine. Sur une infrastructure organisée, le hostname et le FQDN suivent généralement une convention de nommage (par exemple `dafactures.acegrp.lan` pour un projet de facturation sur un réseau interne). La commande `hostnamectl` s'en charge proprement :
|
||||
|
||||
```bash
|
||||
hostnamectl set-hostname dafactures.acegrp.lan
|
||||
```
|
||||
|
||||
Penser à vérifier ensuite que `/etc/hosts` contient bien une ligne associant l'IP locale au FQDN, sous peine de voir certains services (Postfix notamment, ou des outils de log) se plaindre de ne pas résoudre leur propre nom.
|
||||
|
||||
Ensuite, le fuseau horaire. Détail souvent négligé qui complique pourtant le débogage dès qu'on croise des logs entre plusieurs machines :
|
||||
|
||||
```bash
|
||||
timedatectl set-timezone Europe/Paris
|
||||
```
|
||||
|
||||
La synchronisation NTP est généralement déjà active via `systemd-timesyncd` sur les Debian récentes — un `timedatectl status` permet de le vérifier.
|
||||
|
||||
## Et après ?
|
||||
|
||||
Une fois ces étapes franchies, la machine est dans un état sain et utilisable. Les pistes naturelles pour la suite tournent autour du durcissement (configuration SSH avec authentification par clé et désactivation de la connexion root à distance, mise en place d'un pare-feu, installation de `unattended-upgrades` pour les correctifs de sécurité automatiques), puis de l'installation des outils métier proprement dits — serveur web, base de données, runtime applicatif.
|
||||
|
||||
Garder en tête que ces gestes initiaux, aussi triviaux paraissent-ils, méritent d'être scriptés dès qu'on les répète plus de deux ou trois fois. C'est précisément là que la démarche DevOps prend tout son sens : transformer des manipulations manuelles en code reproductible, versionné et partageable.
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user