NFS derrière un VPN : montage au démarrage ou montage automatique à la demande ?

Deux configurations résolvent le même problème et échouent dans des directions opposées. Monter le partage au démarrage donne à chaque service un système de fichiers qui est soit présent, soit une raison pour laquelle le démarrage s’est bloqué. Un montage automatique à la demande donne à la machine un démarrage rapide et remet l’attente à celui qui touche le chemin en premier. Derrière un VPN, le second est généralement le meilleur compromis, et la raison est que le tunnel impose un ordre que la séquence de démarrage ne peut pas voir.

Montage au démarrage contre montage automatique

Un montage au démarrage est simple à raisonner. La cible du système de fichiers attend le montage, les services qui déclarent une dépendance envers elle démarrent ensuite, et si le serveur est injoignable la machine attend ou échoue selon les options. Tout ce qui suit hérite de cette unique décision.

Un montage automatique inverse cela. Le chemin existe immédiatement, le montage réel se produit quand quelque chose l’ouvre, et les services qui démarrent tôt ne se bloquent pas sur un tunnel qui n’est pas encore levé.

La comparaison revient à qui doit absorber le délai. Un poste de travail qui a besoin du partage avant que l’utilisateur puisse travailler devrait probablement attendre. Un portable qui démarre dans un sac, ou un serveur dont le partage est facultatif, ne devrait pas.

Aucune des deux options ne corrige une route manquante. Les deux décident simplement quand la panne est observée.

La ligne fstab, option par option

Supposons qu’une instance cliente OpenVPN existante soit [email protected], que le serveur soit files.corp.example et que le point de montage soit /mnt/work. Remplacez les trois par les valeurs autorisées de votre site. Une ligne qui fonctionne ressemble à ceci :

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev marque le montage comme nécessitant le réseau, et il ne nomme aucun tunnel. nofail garde le partage facultatif pour la cible normale du système de fichiers. x-systemd.automount crée le déclencheur à la demande au lieu de monter immédiatement.

x-systemd.requires= est la partie qui lie la tentative de montage à l’unité VPN, et elle appartient à l’opération de montage plutôt qu’au déclencheur. Placer un ordre large sur l’unité de montage automatique elle-même est la façon dont les gens créent des cycles dont systemd se plaint ensuite dans une langue que personne ne lit deux fois.

x-systemd.mount-timeout=30s borne la commande de montage initiale. Il ne borne rien de ce qui se passe ensuite, et c’est le malentendu le plus courant à propos de cette option.

Ce que « démarré » ne veut pas dire

Vérifiez ce que actif signifie pour l’unité VPN que vous avez nommée. Un service de tunnel peut se déclarer démarré avant que la route vers le serveur de fichiers existe ou avant que le nom privé ne se résolve, et ordonner après lui ne vous achète alors rien. C’est dans cet écart que vit presque toute tentative ratée. Il est aussi invisible sauf si vous regardez la route et le résolveur plutôt que l’état de l’unité.

Utilisez le signal de disponibilité propre au propriétaire de la connexion comme prérequis supplémentaire là où il en existe un. Un sommeil fixe est une supposition qui fonctionne sur votre bureau et échoue sur un réseau plus lent ou après une reconnexion.

Inspectez les unités générées pour le chemin de l’exemple : mnt-work.automount et mnt-work.mount. Après une modification de fstab relue, rechargez systemd et gérez ces unités directement plutôt que de lancer une commande de montage globale qui exerce des entrées sans rapport.

Une mise en garde de plus a sa place ici. Un service qui touche /mnt/work au démarrage déclenche toujours le montage et l’attend toujours, donc marquer le partage comme facultatif ne rend pas chaque application patiente.

Après le montage, c’est une autre panne

Une fois NFS monté, le comportement de nouvelle tentative et de récupération du système de fichiers régit ce qu’une panne ultérieure fait à une lecture ou à une écriture. Le délai de montage que vous avez fixé n’a aucune influence là-dessus.

Un montage souple raccourcit certaines attentes et change la sémantique des erreurs, avec des conséquences sur l’intégrité des données faciles à négliger quand l’objectif est un démarrage plus rapide. Le choisir pour gagner deux secondes de démarrage est rarement un bon compromis. Si l’exigence est vraiment une opération bornée pendant une panne, c’est une décision au niveau de l’application, pas un indicateur de fstab.

Décidez ce qui doit arriver à un processus en pleine écriture quand le tunnel tombe, et écrivez-le. Cette réponse est plus utile que n’importe quelle chaîne d’options.

Testez quatre états, pas un

Un démarrage normal avec le tunnel disponible est le cas facile et ne prouve presque rien. Il confirme que la chaîne est correctement orthographiée, et rien de plus. Testez le premier accès sans le VPN, puis la récupération quand il monte, puis une panne contrôlée après un montage réussi.

Quatre états, quatre observations, et les notes vont à côté de l’entrée fstab. La personne suivante hérite d’un comportement au lieu d’une configuration qu’elle doit rétro-ingénier.