staging.inyokaproject.org

Hallo,

@Benno-007: Danke für den Hinweis ☺ Für meine Verständnis (bevor ich das korrigiere): Das Problem besteht also _nicht_, wenn man bei der Hin- als auch Rücksicherung -l als Option mit angibt?

Gruß, noisefloor

Das müsste man testen, aber so dachte ich das und so verstehe ich die man. Hab von dem Problem noch nie gehört. Da müsste ich sonst mal nachgucken. -a hat die Option ja implizit:

        -a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)

Daher dachte ich, dass mich das sowieso nicht betrifft, da ich andere Optionen habe. Allerdings hat sein Beispiel auch -a - da dürfte das eigentlich gar nicht auftreten? Oder rsync ist noch nicht fertig mit syncen oder hat einen Bug? Ich find das nur als allgemeines Vorgehen etwas seltsam.

In der man rsyncd.conf steht recht viel dazu, muss ich mal durchlesen, sehe aber schon, dass das mit chroot usw. etwas sehr weit ausholend ist:

       munge symlinks
              This parameter tells rsync to modify all symlinks  in  the  same
              way  as  the  (non-daemon-affecting)  --munge-links command-line
              option (using a method described below).  This should help  pro‐
              tect  your  files  from user trickery when your daemon module is
              writable.  The default is disabled when "use chroot" is  on  and
              the inside-chroot path is "/", otherwise it is enabled.

              If you disable this parameter on a daemon that is not read-only,
              there are tricks that a user can play with uploaded symlinks  to
              access  daemon-excluded  items (if your module has any), and, if
              "use chroot" is off, rsync can even be tricked into  showing  or
              changing  data that is outside the module’s path (as access-per‐
              missions allow).

              The way rsync disables the use of symlinks is to prefix each one
              with the string "/rsyncd-munged/".  This prevents the links from
              being used as long as that directory does not exist.  When  this
              parameter is enabled, rsync will refuse to run if that path is a
              directory or a symlink to a directory.  When  using  the  "munge
              symlinks"  parameter  in a chroot area that has an inside-chroot
              path of "/", you should add  "/rsyncd-munged/"  to  the  exclude
              setting for the module so that a user can’t try to create it.

              Note:   rsync  makes  no attempt to verify that any pre-existing
              symlinks in the module’s hierarchy are as safe as you want  them
              to  be  (unless,  of course, it just copied in the whole hierar‐
              chy).  If you setup an rsync daemon on a new area or locally add
              symlinks,  you  can  manually  protect  your symlinks from being
              abused by prefixing "/rsyncd-munged/" to the start of every sym‐
              link’s  value.   There is a perl script in the support directory
              of the source code named "munge-symlinks" that can  be  used  to
              add or remove this prefix from your symlinks.

              When  this  parameter  is disabled on a writable module and "use
              chroot" is off (or the inside-chroot path is not "/"),  incoming
              symlinks  will be modified to drop a leading slash and to remove
              ".." path elements that rsync believes will allow a  symlink  to
              escape  the  module’s  hierarchy.  There are tricky ways to work
              around this, though, so you had better trust your users  if  you
              choose this combination of parameters.

Vielleicht sollte man solche Fragen einfach mit wired2051 direkt klären, welcher das Thema vermutlich nicht abonniert hat.

Grüße, Benno

Hallo,

habe ihm mal eine PN geschrieben mit der Bitte, hier im Thread dazu was zu posten.

Gruß, noisefloor

Wow, ich bin beeindruckt, dass meine Änderung zu schnell Beachtung findet.

Ich kann dazu erstmal nur soviel sagen, dass ich seit ca. 4 Jahren mit rsync und rsync-Daemon auf dem NAS meine Daten sichere:

1

rsync -au --log-file=/home/USER/logs/DatenAufNAS.log exclude=.Trash-1000/ /media/Daten/ IP_DES_NAS::backupDaten

Und auf dem NAS steht in der /etc/rsyncd.conf

1
2
3
4
5
6
7
8

[backupDaten]
path = /volume1/Daten
comment = Daten
uid = root
gid = root
read only = no
list = yes
charset = utf-8

Ich würde also Benno-007 nicht zustimmen, dass --links (enthalten in --archive) das "Problem" verhindert. Vermutlich ist zwischen der Nutzung von rsync und rsyncd zu unterscheiden. Bei mir waren und sind die Symlinks auf dem NAS verändert, also durch den rsync-Daemon und nicht zwangsläufig durch rsync? Den in der Manpage von rsyncd.conf erwähnte lqmunge symlinksrq parameter sagt mir leider nichts aber ich bin wirklich kein Auskenner. 😳

Gegen eine Verlagerung in einen Problemlösungsabschnitt habe ich überhaupt nichts. Ich habe das aber so verstanden, dass die Veränderung der Links eine sinnvolle Vorsichtsmassnahme ist und da das Ändern der Links mit dem Script völlig simpel erledigt wird, würde ich eher nicht von einem Problem reden.

Aber etwas anderes: Ich habe keine Ahnung wie das rechtlich ist, deshalb habe ich nur einen Link gesetzt aber vermutlich wäre es besser, wenn man das Script hier auch irgendwo speichern würde.

Ja, eine Sicherheitsmaßnahme, die von -l unberührt bleibt, wie es sich zwischenzeitlich las. Diese könne man abstellen (wenn kein chroot und keine Gefahr, wie eignes LAN/ nur "harmlose" Mitbewohner?). Entweder durch --no-munge-links oder durch

munge symlinks = no

in der rsyncd.conf. Über meinem zitierten Abschnitt steht noch mehr zu chroot und Sicherheit.

Falls sich damit keiner auskennt, Vorschlag einiger Überarbeitungen der Formulierung:

Ich hab aber nur die Manpages angeschaut, vielleicht liefert das Web exaktere Erklärungen. Das ist fast schon ein eigener Artikel, allein die Recherche. 😉 Kann auch sein, es ist was falsch, aber irgendwie müssen wir die Information ja nun erhalten und verarbeiten. Ich denke aber, ich hab's nun so relativ richtig erfasst.

rsync -auve ssh root@IP:/PFAD_DER_SICHERUNG/ /PFAD_DES_ZIELS 

Sieht für mich sehr gut aus! 👍 Vielen Dank. Einzig vielleicht noch der Hinweis auf die Usage aber der steht auch im Code:

Script-Aufruf um den Wert /rsyncd-munged/ zu entfernen:

munge-symlinks --unmunge [--all] [DIR|SYMLINK...]

Script-Aufruf um den Wert /rsyncd-munged/ hinzuzufügen:

munge-symlinks --munge [--all] [DIR|SYMLINK...]

Hallo,

IMHO ist der Abschnitt ok, kann Benno-007 einbauen.

Gruß, noisefloor

Danke für den Einbau, wired2051.

letzte Änderung:

Fiodin 10. Januar 2015 11:02 : Die Syntax für "exclude" war falsch

laut manpage ist die vorgenomme Änderung falsch - bitte mal gegenchecken

Vielen Dank u1000

Hallo,

in der Optionen-Tabelle steht in der Tat --exclude=, in einem Beispiel weiter oben steht's aber auch ohne... Da's in der tabellarischen Auflistung aber mit = steht habe die die letzte Änderung rückgängig gemacht.

Danke für den Hinweis!

Vielleicht meldet sich Fiodin hier im Thread mal dazu ☺

Gruß, noisefloor

Die manpage deckt sich mit meinen Erfahrungen: --exclude=PATTERN funktioniert (nur 1x '='). Die aktuelle Fassung ist korrekt.

Hallo,

genau, ein = - hab's in meinem letzten Post korrigiert.

Gruß, noisefloor

Frage:
Der angegebene Syntax lautet:

rsync [OPTIONEN] QUELLE ZIEL 

Gibt es einen guten Grund, warum die Option:

... --backup-dir=~/old 

Im Beispiel Sicherung-von-entferntem-Rechner-auf-lokalen-Rechner angehängt wird? (Inkonsistent)

EDIT
Außerdem müsste es wohl eigentlichen

rsync [OPTIONEN] QUELLE(N) ZIEL 

heißen?! - Da dieser Syntax (Angabe mehrerer Quellen) im Beispiel Differentielle-Sicherung-des-Systems genutzt wird.

TausB

Ich nehme an, keiner will es machen - ich für einen Anschiss auch nicht, aber irgendjemand muss es ja machen.

TausB schrieb:

Frage:
Der angegebene Syntax lautet:

rsync [OPTIONEN] QUELLE ZIEL 

Gibt es einen guten Grund, warum die Option:

... --backup-dir=~/old 

Zumindest ich hab das nicht angefasst, da es so wohl getestet ist und einem zeigt, dass es um den Ordner auf dem Server geht.

Im Beispiel Sicherung-von-entferntem-Rechner-auf-lokalen-Rechner angehängt wird? (Inkonsistent)

EDIT
Außerdem müsste es wohl eigentlichen

rsync [OPTIONEN] QUELLE(N) ZIEL 

heißen?!

Hab den Vorschlag nun direkt so umgesetzt. Begleittext habe ich unverändert gelassen, auch da er sich in der Mehrzahl letztlich nur verkompliziert. Meiner Ansicht nach reicht der Hinweis in der Syntax für die, die es brauchen, vollkommen.

- Da dieser Syntax (Angabe mehrerer Quellen) im Beispiel Differentielle-Sicherung-des-Systems genutzt wird.

Mein Beispiel, ist richtig so. Daher nun oben ergänzt.

Grüße, Benno