Système de fichiers : tmpfs et absence de swap#

Pourquoi#

Une carte microSD a un nombre d’écritures limité avant dégradation. Les journaux système, en particulier, génèrent des écritures continues. La solution retenue ici : déplacer tout ce qui est volatile (logs, répertoires temporaires) en RAM via tmpfs, et accepter la contrepartie, ces données sont perdues à chaque redémarrage. Pour un serveur de temps, c’est un compromis raisonnable : ce qui compte est l’état courant, pas l’historique.

Comment#

/etc/fstab#

cp -a /etc/fstab /etc/fstab.bak
tmpfs   /tmp        tmpfs   defaults,noatime,nosuid,size=100m           0 0
tmpfs   /var/tmp    tmpfs   defaults,noatime,nosuid,size=100m           0 0
tmpfs   /var/log    tmpfs   defaults,noatime,nosuid,mode=0755,size=256m 0 0
tmpfs   /var/nts    tmpfs   defaults,noatime,nosuid,mode=0755,size=16m  0 0
tmpfs   /var/time   tmpfs   defaults,noatime,nosuid,mode=0755,size=64m  0 0
  • noatime sur la racine : supprime l’écriture systématique de l’horodatage de lecture, une source d’usure discrète mais continue.

Les tailles (size=) sont dimensionnées par usage observé, pas au hasard : 100m pour /tmp et /var/tmp couvre largement les fichiers temporaires d’une installation de paquets ou d’un renouvellement certbot, sans jamais peser sur la RAM disponible du Pi 5 (4 ou 8 Go) tant que ce volume n’est pas réellement utilisé (allocation paresseuse, voir plus bas). 256m pour /var/log doit couvrir en même temps les logs nginx, la rotation interne d’auditd (dimensionnée à 32 Mo maximum, chapitre Durcissement système) et journald, avec une marge confortable. 64m pour /var/time (chapitres Munin et Télémétrie publique) est volontairement plus modeste : ce point de montage ne contient que de petits graphiques PNG et un fichier de statistiques texte régénérés périodiquement, jamais un historique qui grossit indéfiniment. 16m pour /var/nts (clés et cookies NTS, chapitre Chrony) est la plus modeste de toutes : une marge d’un facteur dix sur le volume réellement observé, de l’ordre d’une centaine de Kio.

/etc/tmpfiles.d/ : reconstruire l’arborescence à chaque boot#

Un tmpfs est vide à chaque démarrage. Sans reconstruction explicite des répertoires attendus, plusieurs services (auditd, nginx) refusent simplement de démarrer.

# nginx - logs sur tmpfs /var/log
d /var/log/nginx       0750 -      -      -
f /var/log/nginx/error.log  0664  -      -      -
f /var/log/nginx/access.log 0664  -      -      -

# auditd refuse de démarrer si /var/log/audit/ est absent
d /var/log/audit       0750 root   root   -
systemctl daemon-reload
mount -a
systemd-tmpfiles --create /etc/tmpfiles.d/orlinum.conf

Erreurs à éviter#

Un service qui référence un utilisateur système pas encore créé fait échouer toute l’application des tmpfiles.d. Si une règle référence un utilisateur créé par un paquet pas encore installé (par exemple un compte système propre à un démon spécifique), systemd-tmpfiles échoue avec Failed to resolve user '...'. Solution : installer le paquet concerné d’abord, ou ré-appliquer les règles tmpfiles.d après coup.

  • Dimensionner les tailles tmpfs au hasard. Une taille trop petite provoque des écritures qui échouent silencieusement une fois le quota atteint (le service continue de tourner, mais les logs les plus récents disparaissent). Le dimensionnement doit se baser sur un besoin observé, avec une marge confortable : l’allocation tmpfs est paresseuse, la RAM n’est consommée qu’à proportion de l’usage réel, une taille max généreuse ne coûte rien tant qu’elle n’est pas atteinte.
  • Oublier que les logs disparaissent au reboot. C’est un compromis assumé, pas un oubli, mais ce choix ne convient pas tel quel dès lors qu’un historique de logs persistant est requis pour des raisons de conformité/traçabilité : il faudrait alors exporter les logs en continu vers un système distant. rsyslog, classique et éprouvé pour cet usage (envoi vers un collecteur de log, y compris chiffré), est une piste à creuser ; sa mise en œuvre sort du cadre de ce guide, et le lecteur intéressé trouvera pléthore de documentation utile en ligne.

Vérifier#

findmnt -t tmpfs
# Doit lister /tmp, /var/tmp, /var/log, /var/nts, /var/time

df -h /var/log /var/nts /var/time
# Confirme l'usage réel, généralement très faible en régime nominal (1-3%)

ls -ld /var/log/nginx /var/log/audit
# Les répertoires doivent exister avec les bons propriétaires après un reboot

Le test le plus révélateur : redémarrer le serveur et vérifier que tous les services concernés démarrent normalement : c’est la preuve que la reconstruction tmpfiles.d fonctionne dans l’ordre correct par rapport au montage des tmpfs.