Beiträge von m_ueberall

  • Das längste Thema

    Zeit, das "VServer IOPS Comparison Sheet" zu aktualisieren; obwohl nicht ganz ausgeschlossen werden kann, dass derzeit mehrere fio-Tests insbesondere auf den ARM-Servern laufen, gibt es schon einen Unterschied wie Tag und Nacht zwischen einem "RS 2000 G11 SE VIE JA24" und einem "VPS 2000 ARM G11 SE VIE OST24" mit ZFS-Dateisystem:

    Für Buildserver noch akzeptabel, allerdings wären ARM-RS aus Nutzersicht durchaus attraktiv, denn auch die CPU-Leistung pro Kern unterscheidet sich merklich.

  • Static Binaries

    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 ;)

  • Static Binaries

    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.

    Zitat

    --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.

  • Static Binaries

    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.

  • 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).

  • Static Binaries

    Korrekt, "--no-perms" sollte das "-p in -a" übersteuern (und ist tatsächlich das, was ich für den --chmod-Test gemeint hatte).

    Aber: Ich verstehe nicht, warum es keine Fehler gibt, wenn die Attribute nicht wie gewünscht (a+r,a-w) gesetzt sind? Geht das manuell mittels ssh ... und cd /csv-dateien; touch "neue-texte2.csv"; chmod a+r,a-w "neue-texte2.csv"?

    EDIT: Siehe diesen späteren Post, welcher die Unterschiede erklärt.

  • Static Binaries

    Zitat von vistree

    Ich kann danach aber immer noch nicht mit der Option -p den rsync ausführen.

    Dann würde ich zu Testzwecken einmal neben der Option -p auch die Option --chmod=Da+rx,a-w,Fa+r,a-w anfügen (hiermit werden die Zugriffsrechte aller übertragenen Verzeichnisse/Dateien einheitlich übersteuert), um zu sehen, ob es ein generelles Problem mit der Ausführung von chmod auf der Zielseite gibt.

    • Wenn das nicht gehen sollte, kann es an rsync liegen. Gegentest in diesem Fall: Via Shell-Zugriff auf der Zielseite manuell Testdateien/-verzeichnisse via mkdir/touch anlegen und via chmod mit entsprechenden Zugriffsrechten versehen – funktioniert das auch nicht, ist etwas grundsätzlich im Argen.
    • Wenn das funktioniert, kann es an den Zugriffsrechten auf der Quellseite liegen (auch wenn es seltsam klingt; je nach Dateisystem können Dateien/Verzeichnisse explizit oder implizit erweiterte Zugriffsrechte besitzen, welche aber standardmäßig via rsync nicht übertragen werden sollen (geschieht dies doch, wäre dies das Seltsame)). Gegentest in diesem Fall: Auf der Quellseite mittels mkdir/touch die vorgenannten Schritte ausführen, und die resultierenden Rechte der Dateien/Verzeichnisse sicherheitshalber mit stat, lsattr o. ä. (je nach verwendeter Quellumgebung) explizit überprüfen – wenn diese plausibel aussehen, via rsync eine Übertragung anstoßen. Funktioniert das, liegt es an den Zugriffsrechten der Originaldateien auf der Quellseite.

  • Static Binaries

    Ich würde ausgehend vom Vorschlag von KB19 einmal langsam Option für Option durchgehen (und -a "nachbilden"), um den Fehler einzugrenzen, wobei -o, -g, -p abwechselnd zum Schluss ausgetestet werden, bevor man sie kombiniert und -D mbMn explizit wegfallen sollte (Grundsatz: "Nur das verwenden, was auch funktionieren kann/soll").

    Obwohl ich selbst rsync seit >20 Jahren regelmäßig verwende, kann ich mir die Bedeutung vieler Optionen immer noch nicht merken, also hier die in Beispielen dieses Diskussionsfadens vorgenannten Optionen von vistree gruppiert als Referenz:

    Wenn der Eigentümer mit dem SSH-Benutzer übereinstimmt, gibt es keinen Grund für -o; wenn man das Oberverzeichnis explizit mit "chmod [u+s,]g+s" modifizieren kann und die Benutzergruppe ansonsten einheitlich ist, gibt es auch keinen Grund für -g (und noch einen Grund weniger für -o).

    Gegebenenfalls könnte man im Nachgang einen Moderator bitten, diese (Teil-)Diskussion vom Diskussionsfaden "Static Binaries" abzuspalten, da es bestimmt nicht an den bereitgestellten Binärprogrammen liegt (sondern an der Kombination der Quell- und Zielumgebungskonfiguration).

    (EDIT: Andererseits ist man derzeit auf diese Binärprogramme angewiesen, um diese Aktion überhaupt durchführen zu können, also macht die Verschiebung vielleicht noch keinen Sinn.)

  • Das längste Thema

    Zitat von ThomasChr

    So ein Operation not permitted sollte man mit strace oder irgendeinem bpf script weiter verfolgen können. Aber ob das den Ärger wert ist?

    Da es eine Standardinstallation ist, hoffe ich, dass ich nicht der Einzige mit diesem Problem bleibe (so lange ist v10.6.20 ja noch nicht verfügbar) und überlege, auf das nächste Update (v10.6.21) zu warten. Erst, wenn der Fehler bestehen bleibt, wird mehr Zeit investiert. Solange die (internen) Anwendungen keinerlei Auffälligkeiten zeigen, welche durch die Release Notes adressiert werden, ist das nicht zeitkritisch.

  • Das längste Thema

    Zitat von ThomasChr

    Infos im Log?

    Nicht wirklich aussagekräftig – im Kern das hier (siehe "Operation not permitted"), was zu einer Endlosschleife führte, da der Dienst selbständig immer wieder neu gestartet wird (und was mit 10.6.19 sofort wieder funktionierte):

    Code
    Nov  6 09:50:55 vserver17 mariadbd[253932]: 2024-11-06  9:50:55 0 [ERROR] WSREP: Failed to read 'ready <addr>' (got '(null)') from: wsrep_sst_mariabackup --role 'joiner' --address 'ip4-vpn-vserver17.netcup.projektzentrisch.de' --datadir '/database/mariadb-data/data/' --parent 253932 --progress 0 --binlog '/database/mariadb-log/binlog/mariadb-bin' --mysqld-args --wsrep_start_position=4582ebfa-4bbb-11ec-a18d-36edbb1d57fe:45982435
Nov  6 09:50:55 vserver17 mariadbd[253932]: 2024-11-06  9:50:55 0 [ERROR] WSREP: Process completed with error: wsrep_sst_mariabackup --role 'joiner' --address 'ip4-vpn-vserver17.netcup.projektzentrisch.de' --datadir '/database/mariadb-data/data/' --parent 253932 --progress 0 --binlog '/database/mariadb-log/binlog/mariadb-bin' --mysqld-args --wsrep_start_position=4582ebfa-4bbb-11ec-a18d-36edbb1d57fe:45982435: 1 (Operation not permitted)
Nov  6 09:50:55 vserver17 mariadbd[253932]: 2024-11-06  9:50:55 2 [ERROR] WSREP: Failed to prepare for 'mariabackup' SST. Unrecoverable.
Nov  6 09:50:55 vserver17 mariadbd[253932]: 2024-11-06  9:50:55 2 [ERROR] WSREP: SST request callback failed. This is unrecoverable, restart required.

  • Das längste Thema

    Zitat von aRaphael

    Kann man eigentlich irgendwo die Sitzungsdauer des CCP einstellen/verlängern?

    Ich hab nix gefunden und die ständige Rausschmeißerei und erneute 2FA ist nervig.

    Ich habe es jetzt nicht ausprobiert, aber verlängern regelmäßige Aktivitäten (Laden verschiedener Seiten) nicht die Sitzungsdauer? Wenn dem so ist, vielleicht tut's auch ein einfacher automatisierter Refresh derselben Seite alle 5min?

  • Das längste Thema

    Zitat von VeePay

    Da es online ist, solltest du hier ebenfalls ein 14 tägiges Widerrufsrecht haben. Ist Standard bei Käufen, die du online tätigst.

    Vorsicht! Die entsprechenden Anbieter dürften in ihren Geschäftsbedingungen OHNE AUSNAHME auf folgenden Umstand hinweisen: "[…] Domainbestellung [ist] ein Recht und nicht [die Erwerbung einer] Dienstleistung oder [einer] Sache [und somit] ist das aus Fernabsatzverträgen bekannte Widerrufsrecht (vgl. § 355 BGB) nicht zutreffend (vgl. § 312b BGB). […]"

  • Das längste Thema

    Es ist ja bald wieder Weihnachten, höchste Zeit also, mit dem Sparen anzufangen (und bei dieser Gelegenheit nach einer passenden 59/60cm breiten Handgelenkstütze zu suchen):

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • Taugen VServer ARM? Welcher Server passt am besten?

    Zitat von Ecki

    Ich denke mal, das Feature was es bei den X86 Prozessoren ermöglicht die Cores durchzureichen

    haben die ARM Prozessoren einfach nicht

    Doch, das sollte generell funktionieren, wenn der Kernel nicht zu (sehr) alt ist. Ist bspw. auch bei LXD schon länger möglich (lxc info --resources liefert hier die CPU-IDs, welche man dann mit lxc config set <container> limits.cpu c1[,c2[,...]] einem Container zuordnen kann) und erlaubt gerade bei ARM-SBC mit "big.LITTLE"-Architekturen, eine Vermischung verschiedener Core-Typen zu vermeiden*.

    * (In jüngster Vergangenheit gab es zu diesem Thema auch Youtube-Videos mit Proxmox-Beispielen, um neuere Intel-CPU-Modelle mit verschiedenen Cores entsprechend stabil mehrere VM betreiben zu lassen.)