Sollte der SSHFS-Mount über VPN der Benutzersitzung gehören?

Das Einbinden eines freigegebenen Ordners nach dem Aufbau der VPN-Verbindung betrifft zwei Identitäten, die leicht verwechselt werden: die Komponente, die das Netzwerk konfigurieren darf, und das Konto, das sich am Dateiserver anmelden darf. Sie sind selten dieselbe. Ein VPN-Hook unter root ist ein schlechter Ausgangspunkt für den SSHFS-Mount eines Desktop-Benutzers, weil ihm weder der Agent des Benutzers noch die beabsichtigte Mount-Eigentümerschaft zur Verfügung steht. Wer die Eigentümerschaft zuerst richtig festlegt, hält den Auslöser einfach.

Zwei Identitäten, zwei getrennte Berechtigungen

Der VPN-Client braucht Rechte, um Routen und Schnittstellen zu ändern. Der SSHFS-Mount braucht eine SSH-Identität, die der Dateiserver akzeptiert, und einen FUSE-Mount, der dem Konto gehört, das die Dateien liest. Ein Skript unter root erfüllt die erste Anforderung und bricht die zweite stillschweigend.

Ein Mount unter root lässt die Dateien außerhalb der Desktop-Sitzung und möglicherweise ohne Zugriff auf den Agenten, der den Schlüssel des Benutzers hält. Der Mount existiert, der Benutzer kann nicht durch ihn schreiben, und der Fehler sieht nach einem serverseitigen Berechtigungsproblem aus. Diese Fehldiagnose kostet einen Nachmittag und ein Ticket an das Storage-Team.

Entscheiden Sie, welches Konto den Mount besitzt, bevor Sie eine Automatisierung schreiben, denn diese Wahl bestimmt, wo der Auslöser lebt und welche Anmeldedaten er erreichen kann.

Richten Sie zuerst von Hand einen benutzereigenen Mount ein

Beginnen Sie mit einem angemeldeten Benutzer, einem leeren Einhängepunkt, einem autorisierten SSH-Konto und einem funktionierenden Pfad zum Server durch den Tunnel. Ein manueller Mount schafft die Grundlage, die jede Automatisierung reproduzieren muss.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Die Namen sind Beispiele, ersetzen Sie also den Host und den Exportpfad, die Ihr Server tatsächlich anbietet. Prüfen Sie den Hostschlüssel bei dieser ersten Verbindung über den genehmigten Ablauf. Beachten Sie, dass ein VPN-Kontopasswort nicht automatisch die Anmeldedaten des Storage-Kontos sind, was eine häufige Ursache für fehlgeschlagene Versuche ist.

Führen Sie es als normaler Benutzer mit einem Einhängepunkt aus, der diesem Benutzer gehört. Standardmäßig erreicht nur das einbindende Konto die Dateien, und allow_other weitet diese Grenze auf jeden lokalen Benutzer aus. Das ist eine bewusste Ausweitung des Zugriffs, kein Workaround für die Automatisierung.

Lassen Sie den Auslöser im selben Sitzungskontext handeln

Lassen Sie die unterstützte VPN-Ereignisintegration eine Aktion der Benutzersitzung anfordern, statt anzunehmen, ein privilegierter Callback könne die Anmeldedaten eines Desktops übernehmen. Beschränken Sie den Auslöser auf die vorgesehene Verbindungskennung statt auf eine beliebige Schnittstelle, die zufällig tun0 heißt. Eine Dispatcher-Regel, die auf das Falsche passt, feuert bei jeder Netzwerkänderung, auch bei solchen, die nichts mit diesem Mount zu tun haben.

Die Aktion sollte den erwarteten Hostnamen bestätigen, einen vorhandenen Mount bemerken und einen begrenzten Versuch unternehmen. Eine Abfrageschleife, die alle paar Sekunden einen neuen SSHFS-Prozess startet oder eine Anmeldeabfrage wiederholt, während der Server ausgefallen ist, macht aus einer kurzen Störung einen Haufen hängender Prozesse. Begrenzen Sie den Versuch mit einem Timeout und einem einzigen Wiederholungsversuch.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

Der erste Befehl liefert die Verbindungskennung, auf die der Dispatcher passen soll. Die anderen beiden zeigen, ob bereits ein Versuch läuft, und das ist die Prüfung, die Duplikate verhindert.

Ein unbeaufsichtigter Dienst braucht eigene genehmigte Anmeldedaten und eine eigene Hostprüfung in seinem eigenen Ausführungskontext. Er kann nicht davon ausgehen, dass ein grafischer Agent entsperrt ist, und er sollte nicht versuchen, einen zu entsperren.

Planen Sie das Trennen, bevor Sie die Bereinigung erzwingen

Schließen Sie bei einer geplanten Trennung die Dateioperationen ab und hängen Sie im eigenen Ablauf des einbindenden Benutzers aus. Richten Sie sich auf den Einhängepunkt statt auf den Prozess, und bestätigen Sie das Ergebnis, bevor Sie Erfolg melden.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Hängen Sie nur den Mount aus, den dieser Ablauf erstellt hat. Wenn er belegt ist, ist das eine Entscheidung der Anwendung: Ein erzwungenes Trennen, das nur dazu dient, einem Hook Erfolg zurückzugeben, verbirgt Datenverlust, statt ihn zu verhindern.

Unerwarteter Verlust verhält sich anders. SSHFS dokumentiert, dass eine Netzwerkunterbrechung eine Dateisystemoperation blockieren kann, und die Option reconnect stellt den Transport wieder her, ohne Handles wiederherzustellen: Eine vor dem Wiederverbinden geöffnete Datei kann beim nächsten Schreiben fehlschlagen, und ein unterbrochenes Schreiben bleibt nicht erhalten. Dieser Unterschied ist am wichtigsten für Editoren, die eine Datei stundenlang geöffnet halten. Planen Sie einen Schritt zum erneuten Öffnen, statt von einer Wiederherstellung auszugehen.

Testen Sie das Verhalten mit Wegwerfdateien, bevor Sie sich darauf verlassen. Ein Verzeichnis, das nach der Rückkehr des Tunnels wieder erscheint, beweist nicht, dass frühere Handles oder ungespeicherte Arbeit überlebt haben.