Static Binaries

    Außer dem Weglassen aller anderen Parameter via

    Code
    rsync -vvvv --no-perms --chmod=Da+rx,a-w,Fa+r,a-w --rsync-path=/rsync.amd64 ./neue-texte3.csv example.de:/csv-dateien/

    und Vergleich der Ausgabe mit dem vorherigen Test – oder in einem zweiten Schritt der Verwendung desselben rsync-Binaries wie auf der Zielseite in einer Linux-Quell-Umgebung mit obiger Parameterkombination – wüsste ich mangels Fehlermeldung nicht, wo man ansetzen könnte (denn auf der Zielseite dürfte eine Verwendung von strace "schwierig" sein).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Auf einem Debian-Linux als Quelle mit rsync 3.1.3

    Ich sehe in dem verbose gar nichts bezüglich des chmods ...


    Die Datei hat in der Quelle

    -rw-r--r--

    und im Ziel nach obigen Aufruf:

    -rw-------

    Offenbar reichen die "-v" noch nicht aus; lokaler Test:

    Die vierte Fundstelle oben zeigt die übersteuerten Zugriffsrechte in Oktalnotation, wie sie auch auf dem Dateisystem danach existieren. Wenn obiger rsync-Aufruf einmal gegen den Webhosting-Server und einmal gegen "localhost" ausgeführt wird (oder einen anderen lokaler Rechner), gibt es da Abweichungen in der rsync-Ausgabe?


    Wenn diese Ausgabe nicht mit den resultierenden Rechten übereinstimmt, könnte das daran liegen, dass hier bspw. ein NFS-Dateisystem auf der Zielseite stillschweigend chown-/chmod-Änderungen ignoriert – das würde aber dann auch beim manuellen Test via SSH-Login und Ausführung von touch, chmod fehlschlagen, und laut obiger Aussage gibt es hier ja keinerlei Probleme.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Edited 2 times, last by m_ueberall ().

    beim testen auch beachten, die ziel-testdateien vorher zu löschen, wenn --chmod ohne --perms verwendet wird, weil vorhandene files nicht geändert werden.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Like 1

    Ich habe die Tests gerade durchgeführt. Es gibt in den 2 Logfiles aber quasi keine Unterschiede (außer Server Name, pid, tmp Dateiname)


    Anbei das Logfile für den rsync von localhost auf meinen alten dedicated Debian Server:

    Code
    kai@MBP-von-Kai ~ % rsync --version | head -1
rsync version 3.3.0 protocol version 31

    Ich sehe hier leider auch wieder nichts bzgl chmod im Logfile. Sind das die sender Informationen?


    Die Datei bekommt aber in diesem Fall die gewünschten Dateirechte:

    Code
    -r-xr-xr-x 1 root root 0 Nov 8 21:53 source_file


    Beim Kopieren auf den netcup Reseller Server gibt es keine wirklichen Unterschiede im Logfile. Aber, die Datei bekommt nicht die erforderlichen Rechte

    Code
    -rwx------ 1 example.de psacln 0 Nov 8 22:00 source_file

    Leider gibt es auf dem netcup Reseller das stat Programm nicht.


    Aber hier noch der sender Output vom netcup Reseller Server:

    Code
    [sender] change_dir(/Users/kai/t1)
[sender] make_file(source_file,*,0)
[sender] flist start=0, used=1, low=0, high=0
[sender] i=0 t1 source_file mode=0100555 len=0 flags=1000
[sender] flist_eof=1
[sender] _exit_cleanup(code=0, file=main.c, line=1358): entered
[sender] _exit_cleanup(code=0, file=main.c, line=1358): about to call exit(0)

    und vom Debian Server:

    Code
    [sender] change_dir(/Users/kai/t1)
[sender] make_file(source_file,*,0)
[sender] flist start=0, used=1, low=0, high=0
[sender] i=0 t1 source_file mode=0100555 len=0 flags=1000
[sender] flist_eof=1
[sender] _exit_cleanup(code=0, file=main.c, line=1358): entered
[sender] _exit_cleanup(code=0, file=main.c, line=1358): about to call exit(0)

    es liegt am rsync.amd64.

    probier mal folgenden rsync:

    Code
    *link gelöscht*

# sha256
46df116d4b7ea50602cc113192f5945e85a1b0b8d87e0d2647952f6abbb17c6f  rsync-3.2.4p.tar.gz

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Edited 2 times, last by Olivetti ().

    Ich habe anhand eines CIFS-Mountpoints nochmal verifiziert, dass rsync keinerlei Fehlermeldungen ausspuckt, wenn chmod fehlschlägt. Das sollte, ohne jetzt im Quellcode nachzusehen, dem Umstand geschuldet sein, dass rsync standardmäßig die resultierenden Zugriffsrechte nicht explizit durch erneuten Vergleich mit dem Sollwert kontrolliert, wenn der chmod-Aufruf ins Leere läuft.


    Nach erneutem Durchlesen des Manuals denke ich, dass doch -p verwendet werden muss – und dass wir bislang vergessen haben, die jeweils aktive umask zu beachten (bei Linux normalerweise 022), da rsync diese berücksichtigt.

    Dummerweise haben wir via --chmod nicht alle Zugriffsrechte gesetzt, sondern gerade auf die Schreibrechte verzichtet. Wenn man obiges t1/t2-Beispiel auf einem lokalen Linux-Rechner wiederholt mit "rm -vf /tmp/t2/source_file; rsync -v --chmod=Da+rwx,Fa+rwx t1/source_file localhost:/tmp/t2", dann sieht man, dass die Zieldatei nämlich keinesfalls "world-writable" (0x777) ist, sondern die Schreibrechte für die Gruppe und Andere maskiert sind.


    Endet die Ausgabe von umask, wenn man sich via ssh auf dem Webhosting-Server einloggt, zufälligerweise auf "77"?


    Und weil rsync die umask berücksichtigt, unterscheidet sich das Verhalten von einem explizit auf der SSH-Kommandozeile ausgeführten chmod-"Gegentest", da dieser den umask-Wert ignoriert.

    Quote

    --perms, -p

    This option causes the receiving rsync to set the destination permissions to be the same as the source permissions. (See also the --chmod option for a way to modify what rsync considers to be the source permissions.)

    When this option is off, permissions are set as follows:

    o Existing files (including updated files) retain their existing permissions, though the --executability option might change just the execute permission for the file.

    o New files get their "normal" permission bits set to the source file's permissions masked with the receiving directory's default permissions (either the receiving process's umask, or the permissions specified via the destination directory's default ACL), and their special permission bits disabled except in the case where a new directory inherits a setgid bit from its parent directory.

    Laut o.g. Text sollte "rsync -vvvvvvvvvvvvv -p --chmod=Da+rwx,Fa+rwx ..." funktionieren, weil in diesem Fall die umask keine Rolle spielt (was ich auch lokal nachvollziehen konnte). Hierbei ist es egal, ob die Datei vorher bereits existierte, die Zugriffsrechte werden auch auf existierende Dateien angewandt (vgl. weitere Ausführungen im Manual zu -p und --chmod).


    Das erklärt immer noch nicht, warum -p allein (ohne --chmod) nicht funktioniert, ermöglicht ggf. aber überhaupt erst einmal die Übersteuerung der Zugriffsrechte.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Edited 2 times, last by m_ueberall ().

    Like 2

    ich hab's auf einem WH2000 (ohne reseller) nachvollziehen können.

    mit rsync.amd64 und -p und umask 0022 (auf beiden seiten) bekomme ich das gleiche verhalten, wie vom TS:

    Code
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1336) [sender=3.2.7]

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Edited 3 times, last by Olivetti ().

    Warum sich das Verhalten der beiden rsync-Binaries unterscheidet, sofern eines nicht älter ist als v2.6.7 (vgl. Manual), wüßte ich nicht. Allerdings kann man (sofern der vorherige chmod-Test funktioniert) neben -p auch noch -A einsetzen, was bisher unterblieb, wenn ich es nicht überlesen habe. Das Vorhandensein von ACL auf der Zielseite – ebenfalls von aktuellen rsync-Versionen berücksichtigt – wurde bislang nämlich noch nicht thematisiert. (Diese müssten normalerweise auch explizit definiert und dementsprechend vom Betreiber dokumentiert werden.)

    Sofern getfacl verfügbar ist, sollte ein "getfacl /tmp/t2" bzw. "getfacl /tmp/t2/source_file" Hinweise darüber liefern, ob eingerichtete Benutzer bestimmte Rechte bei der Verzeichnis-/Dateierstellung (nicht) besitzen.

    Und damit … gn8 ;)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Guten Morgen ihr beiden,

    vielen Dank für die Rückmeldung zu so später Stunde.

    Olivetti : vielen Dank für die alternative Binary. Mit der funktioniert die Synchronisation ohne Probleme. Alle Optionen können fehlerfrei verwendet werden. Auch das von mir bevorzugte -arv (welches ja -p enthält).

    Die hochgeladenen Dateien haben dann im Ziel auch die identischen Berechtigungen wie die lokale Version.

    Man sollte vielleicht für andere noch anmerken, dass der Pfad in deinem Post NICHT der Download-Pfad ist. Man muss erst zu github und dort dann die Datei runterladen.


    Ich denke, damit wäre mein Problem gelöst. 1000 Dank an euch und ein schönes Wochenende

    der download ist nur für dich und wird bald gelöscht, weil es eine alte (noch dazu '…pre') version ist.

    ich hatte nur gestern nix neueres zum hochladen griffbereit.

    Quote from m_ueberall

    Sofern getfacl verfügbar ist

    nein, ist nicht verfügbar.


    wünsche ebenfalls ein schönes wochenende.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Happy Duck 1

    Am Lustigsten finde ich gerade, wie sich das Problem aus Post #6 hier im selben Thread, selbst auf Wiedervorlage gesetzt hat. :D

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Haha 2
    • New
    Quote from perryflynn

    Hat jemand ne kurze Info für mich, wieso mein rsync Binary da nicht funktioniert hat?

    evtl. sowas in der art -> https://github.com/RsyncProject/rsync/issues/109

    ---

    ich kriege rsync-3.4.1 unter ubuntu 20.04 aktuell gar nicht ge»static«t zum laufen (segmentation fault).

    das scheint aber auch von der entwicklerseite gar nicht mehr gewünscht, was man so liest.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    • New
    Quote from Olivetti

    ich kriege rsync-3.4.1 unter ubuntu 20.04 aktuell gar nicht ge»static«t zum laufen (segmentation fault).

    In einem älteren Beitrag meinte perryflynn, dass er sich an Ubuntu/Debian orientiert, was die Versionen/unterstützten Features betrifft – und hier ist man derzeit "noch" bei v3.3.0. Diese/letzte Woche gab es da ein paar zurückportierte Fixes [bleepingcomputer.com], da sollte man ggf. ein Auge drauf haben – die vorletzte Version hat mir bei einem Test (gegen eine ältere Version) auf der Zielseite ein paar Dateien gelöscht =O (unkritisch aufgrund von zurückgebliebenen Duplikaten auf der Quellseite, zeigt aber, dass man hier neue Versionen immer testen sollte).

    EDIT: Ich nutze unter Ubuntu 2[024].04 derzeit die v3.3.0+ds1-4 auf allen Rechnern und habe damit (wieder) keine Probleme (mehr).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Edited 2 times, last by m_ueberall ().