7390: Netzwerkgeschwindigkeit zur Enigma-Box viel zu gering

Ok, ganz langweilig ist der Sat-Box nicht bei ca. 50% CPU, aber da ist noch Reserve.
Falsch. Der eine Prozessor, der sich mit dem SSH-Server vergnügt, ist nämlich am Anschlag, wie Du an den 99% des "dropbear" problemlos erkennst.

Beim Receiver kommt dann noch hinzu, daß es auch nicht nur um rohe Prozessorleistung geht. Auch die Anbindung des Netzwerk-Adapters spielt eine Rolle (auch wenn ich nicht weiß, wie die beim Duo2 realisiert ist). Wenn der z.B. über einen USB-Hub angebunden ist, ist das etwas vollkommen anderes, als wenn da ein PCI-Bus zwischen Netzwerkadapter und CPU existiert.

Ich verstehe offenbar immer noch nicht so richtig, was Du am Ende erreichen willst. Wenn es Dir nur um schnelles Kopieren von ts-Files vom Receiver auf einen PC geht, bleibe ich bei meiner Aussage zur Optimierung der verwendeten Software, zur Auslastung des Receivers beim scp sitzt Du in meinen Augen eben einem Irrtum bzw. einer falschen Interpretation der ps-Ausgabe auf (oder meinetwegen auch "top", keine Ahnung, was das am Ende ist, wo Du die Infos herholst). Wenn Du ein GBit-fähiges Netzwerk haben willst und mit dem Durchsatz des Zyxel-Switches nicht zufrieden bist, ist das nun mal eine andere Baustelle (jedenfalls nach meiner Meinung, das habe ich nun mehrfach wiederholt, wenn Du es anders siehst, kann ich es ja auch nicht ändern).

Du unterliegst hier für meine Begriffe demselben Irrtum wie jemand, der für das Kopieren von Daten vom Receiver auf eine WLAN-Verbindung per USB-Stick setzt (weil die max. 300 MBit/s schaffen könnte und das ist ja dreimal soviel wie ein FE-Anschluß) und dabei vollkommen übersieht, daß erstens die Anbindung über USB per se langsamer ist, zweitens die WLAN-Verschlüsselung zusätzliche Prozessorlast erzeugt und drittens die 300 MBit/s ein theoretisch möglicher Wert sind, wo schon verbleibende 100 MBit/s netto ein wahres Wunder wären.

Nur weil der Receiver eine GE-Schnittstelle hat, muß er noch lange keine Übertragungen > 10 MByte/s schaffen. Er kann es sicherlich, wenn man sich eben auf das Übertragen von Daten beschränkt und nicht noch allen möglichen Unfug parallel dazu macht. Ich habe keine Ahnung, was die Bemerkung zum Start des NFS-Servers auf dem Receiver am Ende bedeuten soll ... ich habe in einem VTI-Image ganz normal das NFS-Server-Paket installiert, eine exports-Datei erstellt und den Daemon auf automatischen Start gestellt. Das war es dann schon - wo Dein Problem beim Mounten liegt, verstehe ich nicht ... vor allem nicht, was da "nicht gewährleistet" ist. Der NFS-Server wird beim Start der Box hochgefahren und gut ist's. Wenn die Box nicht läuft, klappt ja auch kein rsync, das kann es also nicht sein, was Du da meintest.
 
Bitte nicht falsch verstehen, wenn ich widerspreche. Mir ist klar, dass du mit einigen Dingen (wahrscheinlich allen) recht hast. Ich wehre mich nur deswegen so und suche nach Lösungen, weil ich mir ein Bash-Script geschrieben habe, das zuverlässig funktioniert. Auch bei meiner 8-Core-CPU ist rsync fast am Anschlag soll ja so sein, dass die CPU möglichst gut genutzt wird.

Ich verstehe offenbar immer noch nicht so richtig, was Du am Ende erreichen willst.

Ich versuche das wichtigste zu erklären, ich habe ein Script, das einiges synchronisiert und zwar die Änderungen in beiden Richtungen, also zum einen neue DVB-Aufnahmen auf einen PC zu synchronisieren, wo sie dann weiterbearbeitet werden und zum anderen neue Mediadateien auf die HD der Duo2 zu synchronisieren. Ohne rsync komme ich da nicht weiter.

Nur weil der Receiver eine GE-Schnittstelle hat, muß er noch lange keine Übertragungen > 10 MByte/s schaffen

Ja schon, ich wundere mich, dass eine 1300MHz CPU so lahm ist. Ob bei der Übertragung was Unfug ist, stelle ich mal bei Seite.

Ich habe keine Ahnung, was die Bemerkung zum Start des NFS-Servers auf dem Receiver am Ende bedeuten soll ..

Fahr mal einen NFS-Server runter, wenn der NFS-Client noch angemeldet ist. Bei mir bleibt der Client hängen. Mein (1.) PC ist auch NFS-Server und wenn die Sat-Box dann ein 2. NFS-Server ist, dann kann folgendes passieren. Ich schalte die Satbox aus, der PC ist aber noch an und das Dateisystem von der Satbox ist gemountet. Darauf bekommt der Linux-PC ein Problem, weil das gemountete Verzeichnis von der Sat-Box abgeht. Ich kenne das nur von PCs, nehme aber an, dass das mit einer Satbox auch so sein wird. Man muss also immer aufpassen, was wann zuerst ausgeschaltet werden muss und wenn da mehrere Leute die Satbox nutzen, läuft die permanent, damit der PC nicht "einfriert". Im ungünstigen Fall kann man am PC nicht einmal mehr speichern, weil das NFS-Laufwerk fehlt. Auf Automount zu verzichten ist auch nicht bequem

Der NFS-Server wird beim Start der Box hochgefahren und gut ist's.

Eben, und wenn ein Client das exportierte Verzeichnis vom Server mountet und der Server runtergefahren wird, dann hat man ein Problem.

Wenn die Box nicht läuft, klappt ja auch kein rsync,

Ja, aber wenn dann nicht wer anderer die Satbox ausschaltet, dann hat man bei rsync kein Problem, weil das gemountete Verzeichnis nicht mehr da ist. Probiere es aus. Ich muss allerdings dazu sagen, dass ich mich schon längere Zeit nicht mehr mit dem Problem beschäftigt habe, ob es da vielleicht Mount-Optionen gibt, die das Problem des fehlenden Servers akzeptabel machen.

Vom Prinzip hast du aber recht, ich muss mir überlegen, wie ich ein Dateisystem von der Satbox exportiere und dann lokal am PC rsync ausführe. Vielleicht kann man das mit CIFS besser lösen. Ich frage mich warum es mit ftp deutlich schneller ist. Vielleicht ist curlftpfs eine Lösung. Die Frage ist dann ob der File-Server an der Satbox nicht auch viel Power braucht wie rsync ohne ssh.
 
rsync unterteilt ein File in Chunks und bildet für diese dann eine kryptographische Prüfsumme. Schon das ist ein erheblicher Aufwand, der erst einmal vollkommen unabhängig davon ist, ob da am Ende beim Kopieren eine Verschlüsselung verwendet wird oder nicht. Um diese Prüfsummen vergleichen zu können, muß das natürlich auf beiden Seiten stattfinden.

Stimmt diese Prüfsumme auf beiden Systemen für solch eine Teilmenge einer Datei nicht überein, ist die Datei ein Fall für die Synchronisierung, ansonsten nicht. Bei Verwendung passender rsync-Optionen wird das dann noch feiner granuliert und der Anfangspunkt einer Differenz weiter eingegrenzt.

Das führt aber am Ende dazu, daß durch das doppelte Verarbeiten (einmal für den Vergleich und einmal für das Übertragen) jeder Datei die doppelte Menge an Ein-/Ausgabe-Operationen erfolgen muß. Eine nicht ganz so schnelle HDD (in Receivern kommt ja gerne mal eine "green version" mit niedrigem Stromverbrauch und geringerer Geräuschentwicklung zum Einsatz, die dann aber eben auch entsprechend langsamer ist) ist da ein weiterer begrenzender Faktor, da die Receiver auch nicht so üppig mit Hauptspeicher ausgestattet sind, daß das Buffering da große Erfolge verzeichnen kann und damit tatsächlich in aller Regel zweimal von der Platte gelesen wird.

Wenn Dir NFS nicht zusagt, nimm eine andere Server-Software, aber verzichte in erster Linie auf die Verschlüsselung. Diese bringt am Ende doch im LAN nichts und kostet gerade auf so einer Set-Top-Box jede Menge Rechenleistung. Wer da wann den Receiver ein- und ausschalten kann oder könnte, ist mir absolut zu hoch. Ich würde in meiner Einfalt einfach hingehen und den Receiver max. bis in den Standby-Status herunterfahren, dabei läuft das Netzwerk durch. Der zusätzliche Stromverbrauch ist - in Anbetracht des restlichen Aufwands, den Du da bisher betreibst - schon fast zu vernachlässigen und dann stellt sich das Problem eines hängenden NFS-Clients gar nicht erst. Noch dazu, wenn - wie von Dir beschrieben - mehrere Leute auf den Receiver zugreifen könnten ... dann wird der Zeitraum, in dem der Receiver ausgeschaltet sein könnte, ja noch mehr eingeschränkt. Mit ein paar passenden Optionen kriegt man auch in akzeptablen Zeiträumen einen Fehlerstatus vom NFS-Client zurück, aber es muß ja auch nicht immer ein NFS-Client sein. Ein FTP-Server ist die nächste Möglichkeit, auch CIFS/Samba ist machbar. Wenn Du dann allerdings auf diese Filesysteme auch mit rsync losgehst, hast Du wieder das Problem der doppelten Zugriffe. Wenn Du beim rsync anstelle von "-e ssh" ein "-e rcmd" nimmst, bist Du zwar die Verschlüsselung der übertragenen Daten los, das Prüfsummen-Problem aber eben noch nicht. Klar ist rsync ein sehr bequemer Weg, aber dann (zumindest bei dem von Dir skizzierten "use case") mit den passenden Optionen und ohne inhaltliche Prüfung der Dateien auf Unterschiede (whole-file-Option).

Ich weiß ja nicht, was Dein Bash-Skript eigentlich macht, aber Du wirst bei Filmen ja eher selten erleben, daß die sich innerhalb einer Datei unterscheiden. Bei diesen Dateien macht es dann also eher Sinn, die gar nicht erst auf inhaltliche Unterschiede zu untersuchen (entweder die Datei ist da, dann wird Kongruenz angenommen oder sie fehlt, dann muß sie kopiert werden) und sie gleich zum Kopieren auszuwählen oder davon auszuschließen. Auch die teilweise Übertragung (partial) macht bei Filmen nur wenig Sinn und solange Du im LAN nicht mit Verbindungsabbrüchen und der anschließenden Wiederaufnahme abgebrochener Übertragungen zu kämpfen hast, ist auch das unnötiger Ballast, da immer erst festgestellt werden muß, ob der bereits übertragene Teil tatsächlich auf beiden Seiten identisch ist.

Am Ende ist es tatsächlich so, daß eine erneute Übertragung eines Gigabytes auf einen solchen Receiver schneller sein kann, als die Prüfung auf dem Receiver, wie weit die Datei mit der Quelle übereinstimmt ... einfach deshalb, weil das Bilden der Prüfsummen eben den Prozessor entsprechend fordert, während das (vielleicht unnötige, aber schnellere) erneute Schreiben der Daten "nur" das Netzwerk und die HDD richtig belastet (die CPU-Last durch die beteiligten Treiber mal nicht betrachtet, die ist beim Lesen von der HDD für den Vergleich ja auch vorhanden). Mach mal spaßeshalber auf dem Receiver und auf einem "normalen" Rechner einen "sha1sum"-Aufruf für eine größere Filmdatei (so 8 GB mit einer HD-Aufnahme) und vergleiche dabei die Zeit, die jedes der Geräte für diesen Aufruf braucht. Selbst eine "Duo2" dürfte da einem von Dir zitierten Celeron noch unterlegen sein ...

Was ich immer noch nicht so richtig begreife: Warum willst Du denn von einer anderen Quelle auf die HDD des Receivers synchronisieren? Wenn das keine Aufnahmen von einer anderen Box sind, die ebenfalls aus den sechs notwendigen Dateien für eine Aufnahme bestehen, kannst Du die auf der Box doch ohnehin nur eingeschränkt als "Aufnahmen" wiedergeben. Wenn es um die reine Wiedergabe (Video abspielen) geht, ist das doch "live" aus dem Netzwerk fast sinnvoller. Aber das nur am Rande ...

Deine Bemerkung zur 8-Core-CPU und rsync verstehe ich nicht, rsync macht eben auch auf der Dual-Core-CPU des Receivers entsprechenden Betrieb und der Vergleich der Prüfsummen funktioniert nun mal nur, wenn auf beiden Seiten diese Prüfsumme auch vorliegt. Wenn Du also ein rsync zwischen zwei eher ungleichen Partnern ausführen läßt, gibt immer der langsamere der beiden die Geschwindigkeit vor. Das hat - s.o. - erst einmal mit der Verschlüsselung der Übertragung noch nichts zu tun. Selbst wenn Du also ohne scp mit rsync arbeitest, bleibt da ein Overhead übrig. Außerdem kommt da in aller Regel noch hinzu, daß das ohnehin nicht im Multi-Threading läuft (einiges läßt sich schwer auf mehrere Prozesse aufteilen, wenn es voneinander abhängig ist) und es eigentlich vollkommen Wurst ist, ob da eine 8-Core-CPU oder nur ein einzelner Kern arbeitet, wenn z.B. die Daten erst noch von der HDD gelesen werden müssen. Wenn Du also mit einem einzelnen rsync-Prozess tatsächlich acht Kerne auslasten solltest, würde mich das eher verwundern. Vielleicht noch 2 kann ich mir vorstellen (einer für Analyse und einer für Verschlüsselung/Komprimierung) ... danach wird es schon schmaler. Allerdings habe ich auch in neuere rsync-Versionen schon lange nicht mehr hineingesehen, vielleicht gibt es da tatsächlich Optimierungen. Aber in den "normalen Paketen" einer Distribution halte ich das eher für unwahrscheinlich, ohne es genau zu wissen.
 
Also zuerst vielen Dank für die ausführliche und geduldige Antwort!

da die Receiver auch nicht so üppig mit Hauptspeicher ausgestattet sind
Die Duo2 hat 2GB DDR3, also so wenig ist das nicht.

Wenn Dir NFS nicht zusagt, nimm eine andere Server-Software, aber verzichte in erster Linie auf die Verschlüsselung.

Ich bin am probieren, was am schnellsten ist. Ich schaffe mit FTP (Filezilla-Anzeige) ca. 50-60MB/s, binde ich die Satbox via NFS am PC als Client ein, dann kostet das ca. 15MB/s (Anzeige von gcp). Witziges Detail am Rande, die Übertragung, wenn PC und Box an der FB mit kurzem Kabel angeschlossen sind, ist minimal langsamer, als wenn es über das Patchpanel und Ethernetdose 40-50m weiter geht.

Bei der CIFS-Variante kann ich die Box nicht mounten (Falscher Dateisystemtyp, Superblock ist beschädigt). Wenn also wer seine Box über cifs mounted, würde mich interessieren, wie man die Box _manuell_ mounten kann.

aber verzichte in erster Linie auf die Verschlüsselung

So weit sind wir uns einig.

Ich würde in meiner Einfalt einfach hingehen und den Receiver max. bis in den Standby-Status herunterfahren

So einfach ist das nicht, die Box unterscheidet zwischen Standbye und Deep-Standbye. Im Deep-Standbye ist das Netzwerk tot. Das macht ja auch Sinn, dass nach einer einstellbaren Zeit die Box Strom spart, immerhin wird die merklich warm, wenn sie im Standbye ist.

Der zusätzliche Stromverbrauch ist - in Anbetracht des restlichen Aufwands, den Du da bisher betreibst - schon fast zu vernachlässigen

Das sehe ich nicht so.

und dann stellt sich das Problem eines hängenden NFS-Clients gar nicht erst.

Ich denke, das kann man vielleicht anders im Script lösen, dh das Script mounted, wenn es startet und meldet dann das NFS-Share oder was immer ab. Das ist natürlich insbesondere ein Rechte-Problem.

Wenn Du beim rsync anstelle von "-e ssh" ein "-e rcmd" nimmst,

Ich habe da gar nichts eingetragen, vielleicht ist ssh default? Da muss ich recherchieren.

Bei diesen Dateien macht es dann also eher Sinn, die gar nicht erst auf inhaltliche Unterschiede zu untersuchen (entweder die Datei ist da, dann wird Kongruenz angenommen oder sie fehlt, dann muß sie kopiert werden)

Ich verwende "-rvLt --size-only", da wird also nur die Dateigröße geprüft und bei Änderung synchronisiert.

Code:
Am Ende ist es tatsächlich so, daß eine erneute Übertragung eines Gigabytes auf einen solchen Receiver schneller sein kann, als die Prüfung auf dem Receiver, wie weit die Datei mit der Quelle übereinstimmt ... einfach deshalb, weil das Bilden der Prüfsummen eben den Prozessor entsprechend fordert,

Nein, wegen --size-only

Was ich immer noch nicht so richtig begreife: Warum willst Du denn von einer anderen Quelle auf die HDD des Receivers synchronisieren?

Ich glaube, ich kann das nicht kurz erklären. Ich konvertiere meine DVB-Streams zu H.264/mkv auf ca. 1/10 der ursprünglichen Aufnahme, um die 10GB pro Aufnahme ist ja unnötig. Dann habe ich da zB noch meine geschnittenen Camcorder-Filme, die ich auf der Satbox haben will, da läuft auch noch ein DLNA-Server. In gewisser Weise ist das auch ein zusätzliches Backup, etc. Wenn ich fertig bin, überlege ich auch, inwieweit ich darauf via VPN von außen zugreifen kann, etc. Da gibt es verschiedenste Gründe warum ich das so machen will.

Wenn es um die reine Wiedergabe (Video abspielen) geht, ist das doch "live" aus dem Netzwerk fast sinnvoller. Aber das nur am Rande ...

Muss nicht sein, das setzt voraus, dass das komplette Netzwerk dauernd an ist, das ist es aber nicht. Die Satbox hat aber eine gute Chance, dass sie von Zeit zu Zeit wegen einer Aufnahme und der damit verbundenen Zeit bis zum Standbye an ist und dann hat man von unterwegs eine Chance darauf zuzugreifen, auch wenn das Netzwerk runtergefahren wurde, weil man nicht gerechnet hat, dass man was aus dem Netzwerk braucht, etc.
Selbst wenn Du also ohne scp mit rsync arbeitest, bleibt da ein Overhead übrig.

Grundsätzlich hast du recht, die Frage ist einfach, ist es in der Praxis akzeptabel. Ich frage mich, warum das mit meinem Handy in der Praxis mit rsync ganz gut funktioniert. Ok, die Datenmengen sind deutlich geringer, aber ein altes Android-Handy dürfte auch schwächer als ein Duo2 sein und da aktualisiere ich die Fotos von Zeit zu Zeit, etc. Inwieweit das Starten der Box über Internet vom Handy klappt, habe ich noch nicht probiert, über WLAN hat es schon tw. funktioniert.

Wenn Du also mit einem einzelnen rsync-Prozess tatsächlich acht Kerne auslasten solltest, würde mich das eher verwundern.

AFAIR ist 1 Kern auf ca. 100% und ein 2. Kern ist auch noch etwas genutzt.
 
@sipgateuser:
Ok, da kommen dann offenbar noch viele weitere Überlegungen dazu, die ja niemand ohne ihre Erwähnung auch nur ahnen kann. :)

Ich denke aber, das wir inzwischen das eigentliche Thema des Threads und die dort mitschwingende Vermutung, es hätte etwas mit der FRITZ!Box und deren GBit-Einstellungen zu tun, so weit abgehandelt haben? Es hat ja wohl mit der 7390 (und dann wohl auch mit den Zyxel-Switches - egal ob mit oder ohne QoS) nur noch am Rande zu tun ...

Wenn ich richtig liege, solltest Du hier zumachen (mach lieber einen weiteren Thread auf, in dem man das Thema: "DVB-Receiver und Dateitransfer" diskutieren kann, ein Link hierher reicht ja für den Kontext) und vielleicht sogar den Thread-Titel noch ändern. Findet jemand diesen Thread hier auf der Suche bei LAN-Problemen seiner 7390, wird er nicht sehr viele Informationen gebrauchen können.
 
Ok, da kommen dann offenbar noch viele weitere Überlegungen dazu, die ja niemand ohne ihre Erwähnung auch nur ahnen kann.

So ist es

Ich denke aber, das wir inzwischen das eigentliche Thema des Threads und die dort mitschwingende Vermutung, es hätte etwas mit der FRITZ!Box und deren GBit-Einstellungen zu tun, so weit abgehandelt haben?

Grundsätzlich ja, ich bin mir nicht sicher, ob die FB da noch mehr Infos hergibt. AFAIR gibt es da irgendwelche Logs mit Übertragungsraten. Ich habe da irgendwas dunkel mit einer 7270 in Erinnerung.

Dieses QoS habe ich sowieso noch nicht verstanden, wie man das nutzen kann, aber darüber wurde ja auch schon geschrieben. Wenn da also bestimmte Ports Prioritäten haben, dann wäre interessant zu wissen, welche Ports das sind. Die Beschreibung beim Zyxel hilft da nicht viel. Wenn ich das also richtig verstehe, dann werden Netzwerk-Ports, die keine Priorität haben, an allen Anschluss-Ports des Zyxel gleich behandelt, dh es ist egal wo ich das Kabel reinstecke. Primär verwende ich ssh / scp, NFS, DLNA und IP-Telefonie, selten alles gleichzeitig.
 
Da ich in die Falle getappt bin und die Satbox auf der der NFS-Server lief, ausgeschaltet wurde, dachte ich schon die HD sei kaputt. Der Filemanager stürzte ab, der Linux-PC konnte nicht mehr heruntergefahren werden, ich dachte schon die HD sei kaputt. Meine Quick and dirty Lösung ist, das Script als root auszuführen und danach einfach die Rechte der Dateien synchronisierten Dateien ändern.

Aber vielleicht ist ja einer der Poster hier ein Spezialist für die sudoer Konfiguration um dem User xy das Recht zu geben, den Mount-Befehl auszuführen.

Und nachdem es zum Thema selbst auch passt, wie kann ich ein Sambashare der Satbox einem Mounpoint des Linux-PC zuordnen. Im Filemanager kann ich das Samba-Share anzeigen lassen, bringt mir aber für das Script nichts. Ich frage das gerne auch in einem anderen Bereich, aber ich denke, meine Fragen könnte man in 2 Zeilen beantworten und thematisch passt es zur ganzen Diskussion.
 
Bestimmt steht hier im Thread auch schon irgendwo, was Du für eine Linux-Distribution verwendest ... ich suche jetzt trotzdem nicht. Wenn die Aussagen also nicht stimmen sollten, kann es am "flavour" liegen, ich beziehe mich auf openSuSE.

Vordefinierte Mountpoints werden in /etc/fstab eingetragen, wird dort die Option "user" verwendet, kann jeder normale Benutzer diesen Mountpoint (de)aktivieren, "noauto" verhindert das Einhängen beim Start. Damit wird aber das Recht zum Mounten nicht auf einen einzelnen User beschränkt.

Der Aufbau der /etc/sudoers ist in diversen Quellen im Internet beschrieben, zum Editieren nimmt man "visudo". Da die Syntax wegen der umfangreichen Möglichkeiten etwas komplexer ist, müßtest Du Dich schon genauer festlegen, was da wie von welchem Nutzer (mit oder ohne Password, in wessen Kontext, usw.) ausgeführt werden soll. Am einfachsten wäre es m.E., die "user"-Option in der /etc/fstab zu verwenden, dann brauchst Du gar kein "sudo". Die Wahrscheinlichkeit, daß ein anderer Benutzer die gerade benutzte Freigabe aushängt (wenn das überhaupt funktioniert und nicht mit "busy" fehlschlägt) ist sicherlich eher zu vernachlässigen, oder? Andererseits ist das bei Dir ja offenbar ein nicht exakt abgegrenzter Personenkreis, denn wenn ich mich recht erinnere, war bei Dir die Gefahr ja vorhanden, daß Dir jemand anderes den Receiver einfach in den "deep standby" versetzt oder sogar in den richtigen "Aus"-Zustand, während Du noch auf die NFS-Freigaben zugreifst.

Auch zum Mounten einer Samba-Freigabe gibt es zig (auch deutsche) Quellen im Internet, mit "cifs fstab" wirst Du da sehr schnell fündig. Das hier noch einmal auszuwalzen hilft niemandem ...
 
Erstmal sorry, dass ich zu sparsam mit den Voraussetzungen war, man hat da immer was im Kopf, das andere nicht wissen und woran man nicht denkt.

Ich verwende Ubuntu Trusty, aber ich denke, das ist für meine Frage völlig egal.

Es geht um manuelles Mounten im Script, dh die fstab-Lösung ist nicht das, was ich suche. Das Script soll mounten und wieder ein umount durchführen, also etwa so:

Code:
mount -t nfs "$duo2ip":"$DUO2_MOUNTPOINT" "$NFS_MOUNTPOINT"
und wenn alles abgearbeitet ist
Code:
umount -t nfs "$NFS_MOUNTPOINT"
Aber eigentlich will ich es nicht mit nfs machen, dazu unten.

Dafür suche ich nach einer sudoer-Konfiguration und wie du schon schreibst, das Web ist voll zu suduoer, aber leider komme ich mit der exakten Syntax nicht klar.

Damit rufe ich auf:
EDITOR=vim sudo -E visudo

Ist es nun egal, wo ich das hinschreibe oder muss das unter einem bestimmten Kommentar stehen? Ich vermute es ist egal wo es steht, aber ich frage vorsichtshalber

Es soll der User xy aus der Gruppe xy den Mount-Befehl ausführen dürfen und da ein Script ausgeführt wird, soll kein Passwort für den User xy notwendig sein. Reicht das als Info?
IMHO müsste es irgendwie so aussehen:
Code:
user xy=... NOPASSWD:/bin/mount
Das wär schon mal das wichtigste, optimal wäre es, wenn der User xy nur ohne PW mounten darf, wenn er ein bestimmtes Script ausführt.

Zum 2. Problem, Samba/CIFS. Da ich auf der Satbox möglichst wenig installieren will, würde ich gerne statt nfs cifs probieren, das ist nämlich per default installiert und nfs muss nachinstalliert werden und eckt ein wenig, aber es funktioniert. Es geht also darum, wie oben, im Bash-Script ein CIFS-Share zu mounten. Da ich im Filemanager unter Netzwerkssuche bereits die Satbox finde, sollte der Server ausreichend konfiguriert sein, es geht nur mehr darum, wie ich das manuell einem Mountpoint zuordne. Mein Verdacht geht in Richtung Sicherheitseinstellung (ntlmv2) am Linux-PC und ich vermute, dass ich ntlmv2 beim Linux-Client per Script aktivieren muss, notfalls via .smbcredentials, habe aber keine Ahnung zur Syntax. Ich denke die Defaultkonfiguration der Sat-Box verwendet kein PW, da "smbclient -L" eine Ausgabe ohne PW bringt.

Danke und ich hoffe, ich habe nichts wichtiges zu erwähnen vergessen.
 
Ich verwende Ubuntu Trusty, aber ich denke, das ist für meine Frage völlig egal.
Da zumindest bei den "Hauptzweigen" der linux-basierten Systeme die Vorgehensweise durchaus auch unterschiedlich ist, spielt das schon ein Rolle. Man muß wenigstens eine Vorstellung haben, in welche "Familie" Deine Distribution eigentlich gehört (das Schema mit der Abstammung ist der Grund für den Link). Bei Deinem Ubuntu gibt es eben in aller Regel kein Login für einen "root"-User im System und jede privilegierte Operation wird über "sudo" gestartet, das ist bei anderen Zweigen vollkommen anders. Auch die Pfade für bestimmte Binaries sind durchaus unterschiedlich (/bin vs. /usr/bin).

Den "Vorbehalt" gegen die /etc/fstab verstehe ich nicht. Dort kannst Du exakt denselben Mountpoint definieren, die IP-Adresse des Receivers und die Verzeichnisse nehme ich mal als fest an. Wenn das auch noch wechselt, mußt Du es eben in der fstab auch dynamisch in regelmäßigen Abständen prüfen oder das mount-Kommando durch ein Wrapper-Skript ersetzen, das eine entsprechende Aktualisierung auslöst, wenn der vorhandene Eintrag nicht paßt.

Die fstab ist ja genau dafür gedacht (neben dem automatischen Mounten beim Systemstart, was aber nicht obligatorisch ist), daß der Administrator auch nicht-privilegierten Benutzern das Mounten (mit exakt vorgegebenen Einschränkungen) von Datenträgern und Netzwerk-Freigaben erlauben kann, ohne sich einen abzubrechen.

Das Mount-Kommando an sich darf ohnehin jeder Benutzer ausführen, er darf aber nur bestimmte Mountpoints benutzen (eben die, die mit "user"-Option in der fstab stehen).

Wenn Du das trotzdem unbedingt in ein Skript packen willst, mußt Du entweder dafür sorgen, daß nur der eine spezielle Nutzer das "mount"-Kommando mit einer anderen Identität ausführen darf (eben als "root"). Das ist dann z.B. für den Benutzer "superperforator" auf dem lokalen Rechner mit dem Namen "puderrosaranch" die folgende Zeile:
Code:
superperforator puderrosaranch = (root) NOPASSWD: /bin/mount
Der darf also das /bin/mount-Binary mit der Identität von "root" ohne Eingabe eines Kennworts ausführen. Das erlaubte Kommando kann man natürlich auch auf ein bestimmtes Skript setzen, eine einfache Möglichkeit, das mount-Kommando nur aus diesem einen Skript zuzulassen, ist nicht so leicht zu realisieren. Zwar könnte man das auch mit einem solchen Skript anstelle des /bin/mount in die /etc/sudoers schreiben, dann wird aber das gesamte Skript im Kontext von "root" ausgeführt (und das mount-Kommando da drin braucht kein "sudo") ... das hat dann wieder Auswirkungen auf die Datei-Eigenschaften. Das muß man sich also gründlich überlegen, was am Ende leichter zu verschmerzen ist.
EDIT: Fast hätte ich noch eine Möglichkeit in der /etc/sudoers vergessen ... man kann auch weitere Parameter für das erlaubte Kommando spezifizieren. Wenn man da also das komplette mount-Kommando einträgt, dann kann der Benutzer auch keine anderen Mountpoints spezifizieren (zumindest nicht im Kontext von "root"). Beschränkt das zwar immer noch nicht auf das eine einzige Skript, aber auch den einen einzigen Mountpoint.

Ich bleibe dabei, ich würde gar keine Spielereien mit "sudo" machen. Einfach den passenden Eintrag in die fstab und die Geschichte ist gegessen. Solltest Du das trotzdem unbedingt per Skript mit mount/unmount machen wollen: Die Angabe des Dateisystem-Typs beim Dismounten ist überflüssig, das nur am Rande.

Ähnliches gilt für das Mounten von CIFS-Freigaben. Wenn ohnehin keine Anmeldung am Receiver notwendig ist, um auf die dort freigegebenen Shares zuzugreifen, dann sehe ich das Problem nicht. Welche Sicherheitseinstellung sollte dem dann noch entgegenstehen? Ich vermute eher, daß der von Dir verwendete Filemanager da vielleicht nicht so flexibel ist und auch bei eigentlich ohne Anmeldung möglichem Zugriff noch einen entsprechenden User/Password-Dialog verwendet. Was sollte man Dir hier anderes schreiben, das nicht schon geschrieben wurde, z.B. hier?

Wenn Du solche Probleme mit den Einschaltzeiten Deines Receivers hast, nimm einfach "autofs" und dismounte nach einiger Zeit ohne Zugriff auf ein gemountetes Verzeichnis. Zwar wird auch "autofs" beim Mounten u.U. etwas Zeit benötigen, bis da ein Timeout und damit dann ein Fehler auftritt, aber dann muß man in Deinem Synchronisationsskript auch nichts mehr machen, als das Vorhandensein der gemounteten Struktur ordentlich zu prüfen.
 
Zuletzt bearbeitet:
Bei Deinem Ubuntu gibt es eben in aller Regel kein Login für einen "root"-User

Ich habe einen aktiven root-User angelegt.

Den "Vorbehalt" gegen die /etc/fstab verstehe ich nicht.

Vielleicht emotional, aber ich habe ja schon ein funktionierendes Script. Wenn man Müll in die fstab schreibt, dann kann man vielleicht einigen Aufwand haben um das zu reparieren, wenn der PC nicht mehr bootet, bei einem Script nicht. Früher hatte ich das mal so. Ich will das jetzt gar nicht vertiefen.

Das ist dann z.B. für den Benutzer "superperforator" auf dem lokalen Rechner mit dem Namen "puderrosaranch" die folgende Zeile:

Muss man da den Hostnamen unbedingt angeben? Ich erinnere mich da in der letzten Zeit an unterschiedliche Ausgaben von "uname -n", kann man da auch localhost oder an 2. Stelle oder gar nichts hinschreiben? Und dann habe ich statt (root) auch schon (root:root) gesehen, verstehe aber den Unterschied nicht.

Wenn man da also das komplette mount-Kommando einträgt, dann kann der Benutzer auch keine anderen Mountpoints spezifizieren (zumindest nicht im Kontext von "root")

Betrifft das auch das automatische Mounten von USB-Sticks?

Ich bleibe dabei, ich würde gar keine Spielereien mit "sudo" machen.

Na gut, dann kann ich es gleich weiter als "echter" root ausführen.

Ich vermute eher, daß der von Dir verwendete Filemanager da vielleicht nicht so flexibel ist und auch bei eigentlich ohne Anmeldung möglichem Zugriff noch einen entsprechenden User/Password-Dialog verwendet.

Missverständnis, der Filemanager (Thunar) stellte die HD in der Satbox dar und ich konnte es öffnen. Keine Ahnung, ob es gerade deswegen ein Problem gibt, weil gerade 2 Satboxen im Netz hängen, vielleicht werden da idente Namen vergeben und jetzt kommt es zu einer Kollision, kann gerade nicht probieren, weil aufgenommen wird. Ich werde deinen Wiki-Link nochmals durchlesen, ich glaube bei mir ist nur eine Kleingkeit falsch, aber dazu muss ich erst wieder mit den Boxen testen können um zu zitieren, wo es hängt.

Wenn Du solche Probleme mit den Einschaltzeiten Deines Receivers hast, nimm einfach "autofs" und dismounte nach einiger Zeit ohne Zugriff auf ein gemountetes Verzeichnis.

Auch nicht so einfach, das Script kann 15min oder Stunden daueren, da werden die Streams zB auch noch konvertiert, da die gesendeten Streams oft kaputt sind und zum Schneiden ungeeignet sind. Es gibt Details über Details. Vom PC zur Satbox gibt es auch eine Reihe von Feinheiten.

aber dann muß man in Deinem Synchronisationsskript auch nichts mehr machen, als das Vorhandensein der gemounteten Struktur ordentlich zu prüfen.

Mache ich schon, ist aber auch komplizierter, da verschiedene Situationen unterschieden werden und dann soll das noch mit mehreren Satboxen funktionieren, Detail über Detail ... Aber wie schon gesagt, alles funktioniert schon als root und mit nfs. Das mit Samba wird nur ein Thema, wenn der Speicher knapp wird.
 
Zuletzt bearbeitet:
Ich habe einen aktiven root-User angelegt.
Das sind natürlich alles unwesentliche Details über Details ... :mrgreen:

Wenn man Müll in die fstab schreibt, dann kann man vielleicht einigen Aufwand haben um das zu reparieren, wenn der PC nicht mehr bootet, bei einem Script nicht.
Solange das rootfs da ordentlich drin steht, warum sollte der PC nicht mehr booten?

Muss man da den Hostnamen unbedingt angeben? Ich erinnere mich da in der letzten Zeit an unterschiedliche Ausgaben von "uname -n", kann man da auch localhost oder an 2. Stelle oder gar nichts hinschreiben? Und dann habe ich statt (root) auch schon (root:root) gesehen, verstehe aber den Unterschied nicht.
Nein, man kann natürlich auch "ALL" anstelle des Hostnamens verwenden, dann darf dieser Benutzer das Kommando allerdings von jedem beliebigen Host ausführen. Da bei Dir das "Sicherheitsbedürfnis" (mir fällt kein anderer Begriff ein) aber immer durchscheint (u.a. auch beim Wunsch, das mount-Kommando ohne Kennwort-Eingabe nur für ein einzelnes Skript zuzulassen), hielt ich eine Beschränkung auf einen einzelnen Computer für eine gute Idee. Aber da gibt es sicherlich Details über Details zu beachten.

Dieses Thema (hosts.allow/hosts.deny, remote logins/execution, NIS/YP im Linux-Netzwerk, usw.) werde ich aber nicht hier vertiefen. Das ist immer mehr Linux-Basiswissen - gepaart mit Ubuntu-Spezialitäten - und da gibt es bereits genug Foren an anderer Stelle, wo diese ganzen Fragen schon mindestens einmal behandelt wurden.

Es macht (zumindest mir) auch nur noch begrenzt Spaß, es kommen immer mehr Informationen tröpfchenweise zusammen. Jetzt sind es plötzlich 2 aktive Sat-Receiver. Ich habe extra noch einmal rückwärts gesucht, das ist die erste Erwähnung eines zweiten Receivers überhaupt, wenn ich nicht tatsächlich etwas überlesen habe. Abgesehen davon macht das auch keinen Unterschied, wenn man die Boxen ordentlich bzw. richtig konfiguriert, sind die zwei unterschiedliche Linux-Hosts im Netzwerk ... das ist ähnlich wie mit zwei PCs. Auch bei einem Aufruf Deiner Skripte mußt Du ja dann den zu benutzenden Receiver irgendwie angeben können ... aber das wird mir tatsächlich zu unübersichtlich und es ist wenig inspirierend, bei jedem Vorschlag auf ein neues (unerwartetes) Hindernis zu treffen. Ich sehe es inzwischen so, daß Du einen bestimmten Vorsatz hast und den willst Du auch genauso umsetzen. Wenn Du das in dieser Deutlichkeit sofort geschrieben hättest, wäre ein guter Teil dieser Konversation überflüssig gewesen.

Ein letzter "Tipp", wenn Du so willst ... ich habe - wie schon mal erwähnt - auch einen Receiver (bei mir allerdings 3x DVB-C im Ultimo) und mußte mich auch schon oft genug mit dem eher schwachbrüstigen Prozessor in dieser Kiste herumschlagen. Mache so wenig wie möglich auf dem Receiver selbst (auch wenn Dein Duo2 mehr Power hat, braucht er die z.B. bei HD-Wiedergaben mit Transkodierung selbst, die Reserven sind nicht so riesig), das ist kein "vollwertiger" Prozessor. Es ist und bleibt ein Embedded-Prozessor, der für spezielle Aufgaben entwickelt wurde und dazu gehört zwar der Umgang mit Video-Streams (von der Separation eines TS aus dem gesamten Datenstrom eines Transponders bis zur Dekodierung verschlüsselter Streams und der Verarbeitung von Video- und Audio-Formaten, das kann/macht der alles in Hardware, ansonsten würde er das gar nicht oder nur mit Einschränkungen schaffen), aber eben keine aktive Verschlüsselung (selbst die bei der HDMI-Ausgabe läuft in Hardware).

In der Konsequenz heißt das bei Deiner Anwendung dann, übertrage die Datei am besten vollständig vor irgendwelchen anderen Aktionen auf den verarbeitenden PC, verarbeite sie nur dort und übertrage sie zurück. Damit beschränkt sich der Netzwerkzugriff (NFS ist und bleibt - meine Ansicht - das am wenigsten "auftragende" Netzwerk-Protokoll, alles andere läuft am Ende wieder im Userspace und belastet den Prozessor im Receiver zusätzlich oder hat zusätzliche Layer über der Struktur des Dateisystems, die es eigentlich in diesem Kontext (Linux-Receiver und Linux-PC) nicht braucht, die "Dummheit" von NFS ist eben auch ein Grund für seine Geschwindigkeit, FTP wäre tatsächlich eine Alternative, denn eigentlich brauchst Du ja gar kein "Filesystem") genau auf die Zeit der Übertragung einer Datei und das dürfte pro Aufnahme nur für das TS-File eine relevante Zeitspanne sein. Jeder Netzwerk-Fehler außerhalb dieser Zeit, ob er nun durch das Ausschalten des Receivers oder "Erdstrahlen" ausgelöst wird, spielt dann absolut keine Geige. Klar ist der Einsatz von rsync verlockend und in den meisten Szenarien als Backup-Tool sogar sehr zu empfehlen ... aber wenn Du tatsächlich "nur" Namen und Größe vergleichst, dann kannst Du das auch gleich anhand eines einfachen "ls"-Kommandos (meinetwegen mit ein paar "stat"-Aufrufen) machen. Dann eine Liste der zu kopierenden "Filme" selbst erstellen und als Queue verwalten ... das erfordert zwar etwas mehr Arbeit im Skript, dafür kann man dann eben tatsächlich auf der "Film"-Ebene anstatt mit Dateien arbeiten. Ein Film sind dann - jedenfalls bei mir - 6 zusammengehörende Dateien, ohne Schnittliste auch weniger, wenn er vom Receiver auf den PC zu übertragen ist. In welchem Format Du die geschnittenen und ggf. konvertierten Dateien dann wieder zurück sendest, weiß ich nicht, spielt aber auch keine Rolle (und interessiert mich nicht mehr wirklich). Wenn man das dann auch noch in 3 verschiedene Queues unterteilt (Lesen, Verarbeiten, Schreiben), dann kann man erstens die Übertragungen tatsächlich nur im Hintergrund laufen lassen und sie zweitens an die momentane Auslastung der beteiligten Komponenten anpassen. Der Receiver läßt sich über HTTP befragen, was er gerade zu tun hat und wenn der keine Wiedergabe und/oder Aufnahme macht, dann kann man ihn eben ganz anders fordern, als wenn er selbst beschäftigt ist. Wenn jemand mit einem Tablet einen HD-Stream vom Receiver sieht und man parallel eine 8 GB-TS-Datei über ein GE-Netzwerk kopiert, dürfte am Ende nämlich die Festplatte im Receiver das Nadelöhr werden, bei Anbindung über USB anstelle von SATA schon wesentlich früher. Die nominelle Geschwindigkeit der einzelnen Schnittstellen gilt ja nur als Begrenzung nach oben, nach unten ist da jede Menge Luft und wer von einer "green HDD" am USB2-Anschluß eines Broadcom-Chipsets die Auslastung einer GE-Netzwerkverbindung erwartet, wird mit einiger Sicherheit schwer enttäuscht werden ... es ist alles ein Gesamtkunstwerk. Wenn der Schnitt die niedrigere Priorität hat, dann kann ein kleines NAS als zentrale Stelle für das Einsammeln und die Verteilung der Dateien das alles im Hintergrund erledigen, wenn die benötigten Geräte zwar eingeschaltet, ansonsten aber unbeschäftigt, sind. Im Extremfall weckt man sogar den/die Receiver in der Nacht auf, nur um den Datentransfer in einer Zeit zu machen, in der er nicht beim Ansehen von Live-TV oder Aufnahmen stört. Den Receiver anschließend wieder schlafen zu schicken, ist auch kein Problem. Dann hat man die zu schneidenden Filme (wenn da kein automatischer Werbungsfilter verwendet wird und tatsächlich manuell geschnitten wird) bereits zur Verfügung, wenn man sich die Zeit dafür nehmen will. Auch eine Transkodierung (oder die Fehlerkorrektur - ich nehme mal an, Demuxen und Paketkorrekturen vor dem Schneiden sind bei DVB-S2 noch wichtiger als bei DVB-C) kann dann im Hintergrund ablaufen ...

Aber das machst Du sicherlich ohnehin schon so ... es sei nur noch einmal für spätere Leser erwähnt, da das hier nun mal keine private Kommunikation ist, auch wenn es den Anschein erwecken mag.

Wenn man für die Übertragung der Dateien dann tatsächlich auf FTP ausweicht und die Liste der zu übertragenden Dateien selbst verwaltet, wird man - nur eine Prognose meinerseits, basierend auf Erfahrungen mit 3 Tunern und einem wesentlich schwächeren Prozessor - den höchsten Durchsatz im Netzwerk erzielen, da das FTP-Protokoll dann tatsächlich den geringsten Overhead hat (es heißt nicht umsonst "File Transfer Protocol").
Allerdings konterkariert man das irgendwie, wenn man es per Fuse als Dateisystem im Userspace betreibt. Da werden dann eben schon aus einem einfachen "stat"-Aufruf für dieses Filesystem (im schlechtesten Fall, wenn man mal null Caching unterstellt beim curlftpfs, ich weiß allerdings nicht, wie das tatsächlich umgesetzt ist) mehrere FTP-Kommandos (das geht mit "cd" los und endet mit "ls", solange sich die Userspace-Implementierung nicht sicher ist, in welchem Verzeichnis die FTP-Verbindung gerade "ist") und dann ist der Vorteil des einfachen Protokolls bei der Verwaltung schnell dahin. Bei der reinen Übertragung bleibt er aber erhalten ... FTP hat selbst nun mal keine Locking-Mechanismen u.ä., wie es bei einem Filesystem üblich ist, das ist ein Vorteil beim Overhead und ein Nachteil bei der Zusammenarbeit. Aber schon die Idee, mit rsync auf eine Filesystem-Emulation(!) loszugehen (sei es eine FTP- oder SSH-basierte), ist abwegig, wenn man Wert auf Geschwindigkeit (der Ausgangspunkt dieses Threads) legt ... meistens funktioniert es glücklicherweise ohnehin nicht. Wenn so ein "rsync" am Ende auf lokale zweite Instanz hinausläuft, die auf dieses "entfernte Dateisystem" zugreift, dann fällt der Vorteil von "rsync" (eben die leichte Feststellung geänderter/zu synchronisierender Dateien ohne die Notwendigkeit, schon für diese Feststellung nennenswerte Datenmengen übertragen zu müssen) wieder weg.

PS: Bei all der Schreiberei habe ich die Frage "root" vs. "root:root" aus den Augen verloren. Die zweite Form setzt die User- und die Group-ID, die erste nur die User-ID.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.