mount via ssh/sftp schlägt fehl

Nachricht

RickX · #21

Barney hat geschrieben:Die Anbindung remoter Filesysteme via ssh/sftp ist weniger resourcen-intensiv als die Anbindung via NFS,.

Wo hast Du diese Information denn her? Gewagte These…
Ein Protokoll, dass auf der einen Seite verschlüsselt und auf der anderen Seite wieder entschlüsselt soll weniger resourcen-intensiv sein?
Ganz bestimmt…

rdamas · #22

Bei mir läuft ein selber übersetzter openssh-9.3p2. Die Version dürfte aber ziemlich schnuppe sein. Die Konfiguration ebenfalls - die ist bei mir bis auf wohl "PermitRootLogin yes" komplett Standard (alles andere hinter Kommentaren).

Wenn du Debug-Log vom Client und vom Server hast, solltest du aber doch klar sehen können, wo es hakt. Gerade mit deinen 30 Jahren Erfahrung. Wenn das nicht hilft: es gibt noch Tools wie strace et.al.

Barney · #23

RickX hat geschrieben:Wo hast Du diese Information denn her? Gewagte These…
Ein Protokoll, dass auf der einen Seite verschlüsselt und auf der anderen Seite wieder entschlüsselt soll weniger resourcen-intensiv sein?
Ganz bestimmt…

Sorry, da war ich etwas ungenau.

Mit Resource waren zwei Dinge gemeint: Arbeitsspeicher für die Programme und Platz auf dem Speichermedium. Diese Informationen kommen aus dem OpenWRT-Forum, kann ich aber auch aus eigener Erfahrung bestätigen.

Viele OpenWRT-Devices leiden unter chronischem Mangel an RAM- und Flash-Speicher. Also muss man mit beiden Resourcen sparsam umgehen.

Ebenso wie bei OpenATV kommt auch bei OpenWRT dropbear als SSHD zum Einsatz. Um per ssh/sftp mounten zu können, benötigt man nur noch den SFTPD. Der belegt weniger Speicher (RAM und Flash) als das NFS-Server Paket.

Was den CPU-Resourcen-Bedarf angeht, hast Du natürlich völlig recht: wegen der Verschlüsselung verschlingt sshfs natürlich mehr CPU-Leistung als NFS. Das ist aber nicht weiter tragisch, da bei einem Router (anders als bei einem NAS) nicht GB-weise Daten über die Leitung geschaufelt werden.

Ich danke Dir für Deinen Hinweis. Das hat mir die Gelegenheit gegeben, meine ursprüngliche Aussage weiter zu detaillieren.

Barney · #24

rdamas hat geschrieben:Bei mir läuft ein selber übersetzter openssh-9.3p2.

Unter openssh versteht man in der Regel die ganze Suite. Welche von den nachfolgenden Einzel-Komponenten sind denn bei Dir im Einsatz?

openssh-keygen
openssh-misc
openssh-scp
openssh-sftp
openssh-sftp-server
openssh-ssh
openssh-sshd

Per default ist dropbear im Standard-Image von OpenATV 7.3 enthalten. dropbear und openssh wollen beide den Port 22 belegen. Wie hast Du diesen Konflikt gelöst?

rdamas · #25

* ich habe kein OATV auf meiner Solo4k laufen, sondern ein uralt VTi.
* ich übersetze OpenSSH aus den Sourcen von deren Repo selber. Die Paket-Aufteilung so wie du sie aufzählst ist willkürlich; selbst Debian macht daraus nur 3 Pakete.
* mit den übersetzten Programmen baue ich mir dann zwei Pakete: openssh-server und openssh-client.
* dropbear ist bei mir deaktiviert - wie du schon richtig sagst ist der sftp-Server Voraussetzung für sshfs. Dropbear kann das nicht.

Barney · #26

rdamas hat geschrieben:* ich habe kein OATV auf meiner Solo4k laufen, sondern ein uralt VTi.

Wenn Du ein VTi und kein OpenATV auf Deiner Box hast, dann fehlt es natürlich an der Vergleichbarkeit. Wenn es mit Deinem VTi klappt, dann muss es unter OpenATV noch lange nicht funktionieren.

Nicht nur, dass Mounten via ssh/sftp unter OpenATV nicht wie bei anderen Distributionen funktioniert, auch in Sachen NFS verhält sich OpenATV anders als gängige Distributionen (siehe mein Thema "etc-exports-option-crossmnt-wird-ignoriert"). Offensichtlich wurde bei OpenATV einiges kaputt-konfiguriert.

rdamas hat geschrieben:* Die Paket-Aufteilung so wie du sie aufzählst ist willkürlich

Die Paket-Aufteilung stammt nicht von mir, sondern von OpenATV (opkg list | grep ^openssh | cut -f1 -d' ').

Ich finde die Paket-Aufteilung von OpenATV auch nicht richtig durchdacht. Will man eines dieser openssh-Pakete installieren, dann scheitert es daran, dass dieses Paket im Konflikt mit dropbear steht. dropbear selbst kann man aber nicht entfernen, weil es vom Paket oe-alliance-base abgängig ist. Also wer sich das ausgedacht hat, hat die Sache einfach nicht zu Ende gedacht.

Na gut, dann bleibt mein "mounten per ssh/sftp"-Problem weiterhin ungelöst. Auf jeden Fall danke ich Dir recht herzlich für Deine Zeit, die Du Dir genommen hast. Have a nice day.

#27

Aber seine Umsetzung zeigt den richtigen Weg. Wenn du per ssh/sftp mounten willst, lasse dropbear weg. Könnte man nach deiner Beschreibung oben auch drauf kommen. Das oATV ist eben suf deinen Anwendungswunsch nicht ab Werk ausgerichtet.