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.
