Utilisateurs, permissions et services

Objectifs

À la fin de cette leçon, vous saurez :

• lire et modifier les permissions rwx ;
• gérer propriétaires et groupes avec chown/chgrp ;
• administrer un service systemd.

🔗 Pour vous rafraîchir la mémoire : processus et signaux (ps, kill, top) · lecture de fichiers et aide (cat, grep, man) · redirections et pipes

Lire -rwxr-x---

-rwxr-x--- 1 cours admin 1024 janv 12 deploy.sh
└┬┘ └──┬──┘└─┬─┘
type   user group others

Trois triplets : lecture (4), écriture (2), exécution (1). chmod en octal ou symbolique :

chmod 750 deploy.sh     # user rwx, group rx, others rien
chmod +x script.sh      # exécutable pour tous

Règles de survie serveur : scripts de déploiement en 750, clés privées en 600, jamais de 777 « parce que ça marche ».

Propriétaire : chown

sudo chown app:app /srv/app        # utilisateur:groupe
sudo chown -R app /var/log/app     # récursif

Moindre privilège appliqué aux fichiers : chaque service tourne sous son propre compte système (useradd --system app) qui ne possède que ses dossiers. Un compromis du service ne touche pas le reste.

Services systemd

Une application de production doit démarrer seule et redémarrer après crash — travail de systemd :

# /etc/systemd/system/todo.service
[Unit]
Description=API Todo
After=network.target postgresql.service

[Service]
User=app
WorkingDirectory=/srv/app
ExecStart=/usr/bin/node dist/main.js
Restart=always
EnvironmentFile=/srv/app/.env

[Install]
WantedBy=multi-user.target

Les commandes quotidiennes :

Commande	Effet
systemctl start/stop/restart todo	piloter
systemctl status todo	état + derniers logs
systemctl enable todo	démarrage au boot
journalctl -u todo -f	suivre les logs en continu

journalctl centralise tout : plus besoin de chercher des fichiers de log éparpillés. --since "1 hour ago" filtre dans le temps.

Redémarrer proprement : processus et signaux

Vous avez vu systemctl restart agir ; voici ce qu'il fait vraiment : envoyer un signal au processus. Un signal est un petit message du système — SIGTERM (15) « merci de terminer », SIGKILL (9) « terminé immédiatement ».

• Arrêt gracieux : SIGTERM laisse le service finir les requêtes en cours, fermer les connexions, flusher ses écritures — puis s'éteindre. C'est ce que fait systemctl stop/restart.
• Arrêt brutal : SIGKILL ne laisse aucune chance (données en mémoire perdues, connexions coupées net). Réservé aux processus bloqués.

kill -15 1234    # gracieux (défaut de kill)
kill -9 1234     # dernier recours
ps aux | grep todo   # retrouver un PID hors systemd
journalctl -u todo -n 50 --no-pager   # voir l'arrêt/redémarrage dans les logs

Côté Node, l'arrêt gracieux se programme : écouter process.on("SIGTERM", ...) pour clore le serveur HTTP avant de sortir. Vous retrouverez exactement cette paire SIGTERM/SIGKILL au chapitre Docker — les conteneurs reçoivent les mêmes signaux.

Exercice

1. Créez un script, mettez-le en 750, vérifiez avec ls -l.
2. Écrivez le service systemd pour votre API ; démarrez-la, tuez son processus (kill) : elle revient.
3. Suivez ses logs avec journalctl pendant une requête curl.

Résumé

• rwx × user/group/others, chiffres 4/2/1.
• Un compte système par service : moindre privilège.
• systemd = démarrage, redémarrage, logs centralisés.