rsynd backup: uid gid vs. rsync-Parameter

[wired2051]

Ich habe vor einiger Zeit angefangen ein Backup von meinem PC (Kubuntu-Linux) auf HD1 der DS zu machen. Soweit erfolgreich. Nun will ich alles noch einmal überarbeiten und komme etwas ins schwimmen.

Zum einen habe ich auf der DS in etc/rsyncd.conf ein Module eintragen:

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

Das Backup starte ich auf dem PC mit diesem Befehlt:

rsync -rlptDHKvu --delete /media/Daten/ IP_DER_DS::backupDaten

Meine Frage ist nun, ob uid = root und gid = root nicht der Option -p widerspricht?

Ausserdem habe ich offenbar ein Problem mit dem Besitzer, denn auf DS hat mein User die UID 1026 und auf dem PC die UID 1000, was dazu führt, dass im DSM immer Besitzer und Gruppe "0" angezeigt wird.

PC: /etc/passwd
root:x:0:0:root:/root:/bin/bash
user:x:1000:1000:User Name,,,:/home/user:/bin/bash

DS /etc/passwd
root:x:0:0:root:/root:/bin/ash
user:x:1026:100::/var/services/homes/user:/sbin/nologin

Wenn ich über Telnet direkt auf der DS nachschaue (ls -l), wird merkwürdiger weise "root root" angezeigt. Was kann ich da tun?

 

[itari]

Hast schon mal probiert, im Module in UID und GUI die Nummern, die du auf der DS hast, einzutragen?

Itari

 

[wired2051]

Nein, habe ich nicht, ich wusste aber auch nicht, dass das geht. Meine Überlegungen gehen aber auch eher in eine andere Richtung:

1. Muss als UID überhaupt root eingetragen sein, schliesslich kommt der doch sowieso immer an die Daten?

2. Kann es zu Problemen kommen, wenn der Besitzer auf dem PC (user mit UID 1000) ein anderer ist als auf der DS (user mit UID 1026)?

3. Macht es Sinn, den rsync-Daemon mit uid = 1000 und gid = 1000 auf einen user einzuschwören, der der DS nicht bekannt ist?

4. Sind die rsync Parameter -rlptDHKvu, besonders -p (preserve permissions) wirklich sinnvoll?

 

[jahlives]

4. Bei einem Backup ist natürlich preserve permissions sehr sinnvoll. Sonst Gnade dir Gott wenn du das Backup zurückspielen willst
Btw: Kennst du den Parameter -a? Der fasst die meisten deiner Optionen zusammen

 

[wired2051]

Btw: Kennst du den Parameter -a? Der fasst die meisten deiner Optionen zusammen

Das Problem ist, dass -a auch -o und -g enthält, was eben zu Problemen mit den Besitzern führt. Hier im Forum (Posting #10 und #15) hast Du mir deshalb geraten -a nicht zu nutzen.

Wenn ich das richtig sehe, ist das Problem nun, dass ich als User (UID 1000) auf dem PC ein Backup mit rsyncd mache und dabei uid = root gid = root erzwungen wird. Eigentlich brauch ich beim Backup ja keine root-Rechte, User reicht und daran anschliessend eben die Frage, ob es schlimm ist, wenn UID auf PC und DS unterschiedlich sind (es ist nicht schön) und ob man das ändern könnte in dem man uid = user gid = user (genauer uid = 1026 oder 1000?) im Modul einträgt?

 

[jahlives]

Dann leg dir doch auf der DS einen User an mit derselben UID/GUID wie der User, der den Job auf dem PC startet. Dann sollte das übereinstimmen.
Du könntest aber auch wie du bereits vorgeschlagen hast mal probieren die UID/GUID im Modul so zu setzen, dass sie mit dem PC übereinstimmt, ohne den User wirklich auf der DS zu erstellen.

 

[wired2051]

Dann leg dir doch auf der DS einen User an mit derselben UID/GUID wie der User, der den Job auf dem PC startet. Dann sollte das übereinstimmen.

Das geht mit dem DSM leider nicht. Und wenn ich es über die Konsole mache, kann ich danach die Benutzerverwaltung über DSM nicht mehr nutzen. Das ist mir zu gefährlich, weil ich mich in ein paar Jahren sicher nicht mehr daran erinnere, dass ich da was mit der Konsole gemacht habe (oder zu spät).

Du könntest aber auch wie du bereits vorgeschlagen hast mal probieren die UID/GUID im Modul so zu setzen, dass sie mit dem PC übereinstimmt, ohne den User wirklich auf der DS zu erstellen.

Ich habe jetzt im Modul UID = user und GID = GRUPPE_VON_USER, wie auf der DS definiert, eingetragen. Leider war das Ergebnis nicht befriedigend:

2010/06/11 21:40:53 [10368] building file list
2010/06/11 21:40:54 [10368] done
2010/06/11 21:40:54 [10368] rsync: delete_file: unlink(Test.txt) failed: Permission denied (13)
2010/06/11 21:40:56 [10368] .d..t...... ./
2010/06/11 21:40:56 [10368] rsync: failed to set times on "." (in backupDaten): Operation not permitted (1)
2010/06/11 21:40:56 [10368] rsync: open(.directory) failed!!: Permission denied (13)
2010/06/11 21:40:56 [10368] rsync: open(Test.pdf) failed!!: Permission denied (13)

Warum ist der Zugriff verweigert, wenn ich doch mit der User/Gruppe zugreifen will, die auf der DS für den Zielordner von rsyncd definiert ist?

 

[jahlives]

Wie sehen denn die Rechte der Test.txt Datei aus? Eigentümer und Gruppe?
Letzendlich hast du nur die Rechte des Moduls angepasst. Wenn aber die Dateien im Modul andere Rechte (Eigentümer und Gruppen) haben, als du im Modul selber definiert hast, dann geht des auch nicht.
Darum verwende ich persönlich immer root für meine Backup-Jobs. Dann muss ich mir um solche Dinge keine Sorgen machen

 

[wired2051]

Wie sehen denn die Rechte der Test.txt Datei aus? Eigentümer und Gruppe?

Das ist ja eben das Problem: user und GRUPPE_VON_USER, wie sie auf dem PC gelten, halt mit anderer UID und GID als auf der DS.

Darum verwende ich persönlich immer root für meine Backup-Jobs. Dann muss ich mir um solche Dinge keine Sorgen machen

Mmmh, vielleicht sollte ich das auch machen. Ich versuche halt, root, soweit es geht, aus allem raus zu halten.

Das würde bedeuten, rsync muss von root gestartet werden und demnach muss das Script auch in /etc/crontab eingetragen sein, richtig? Muss ich sonst noch was beachten (root ist in /etc/rsyncd.conf ja schon eingetragen)? Wie stelle ich sicher, dass am Ziel dann nicht root der Besitzer ist sondern user (von mir aus auch user mit der UID und GID von der DS)?

 

[jahlives]

Das Problem bei root könnte dann noch dein Client sein. Viele Linux lassen es nicht wirklich zu root zu verwenden.
Mit dem PreserveRights sollte dann sichergestellt sein, dass die Datei immer noch user gehört und nicht root. Die Verwendung von root stellt nur sicher, dass du in jedem Fall über alle nötigen Rechte verfügst die Backupdateien zu bearbeiten/löschen

 

[wired2051]

Mit dem PreserveRights sollte dann sichergestellt sein, dass die Datei immer noch user gehört und nicht root.

Das verstehe ich nicht.

Ich bin doch nur ein Dilettant. Andererseits denke ich mir, diese Probleme müssten doch längst gelöst sein, schliesslich bin ich sicher nicht der erste der seine Daten auf einer DS sichern will. Also kann es nur daran liegen, dass ich es noch nicht verstanden habe.

 

[jahlives]

Mit PreserveRight-Parameter stellst du sicher, dass die Datei, die auf dem Client dem User wired gehört, auch auf der DS die nummerische UID/GUID von wired erhält. Ohne dies würde es dazu führen, dass die UID/GUID von dem User übernommen würde, der den Backupjob gestartet hat (z.B. 0/0 für root)

 

[wired2051]

Ah, ich glaube, jetzt habe ich verstanden: Du meinst also, ich soll rsyncd als root starten und dabei -p (preserve permissions) verwenden, damit user:gruppe erhalten bleibt.

Danke.

Aber wäre es nicht einfacher, wenn ich auf dem PC und der DS jeweils user:gruppe (also UID und GID) verwende, die dort auch bekannt sind? Als root kann ich die Daten doch jederzeit hin und her kopieren und dabei die jeweiligen Benutzer anpassen. Wo wäre da der Nachteil?

 

[jahlives]

Aber wäre es nicht einfacher, wenn ich auf dem PC und der DS jeweils user:gruppe (also UID und GID) verwende, die dort auch bekannt sind? Als root kann ich die Daten doch jederzeit hin und her kopieren und dabei die jeweiligen Benutzer anpassen. Wo wäre da der Nachteil?

Dann musst du sicherstellen, dass auf der DS ein User/Gruppe existiert mit den gleichen nummerischen Werten wie auf dem PC.
Wenn du also auf dem PC den User wired hast mit z.B. UID/GID 1000/125, dann muss auf der DS ebenfalls ein User mit diesen Werten existieren. Ob der dann auch wired heisst oder hubert sollte egal sein. Die nummerischen Werte müssen stimmen!

 

[wired2051]

*grummel* genau da liegt ja das Problem, das bekomme ich offenbar nicht ohne Probleme hin.

Kriege ich auf der DS denn keine Probleme, wenn Dateien/Verzeichnisse von Usern existieren, die die DS nicht kennt?

 

[jahlives]

Kriege ich auf der DS denn keine Probleme, wenn Dateien/Verzeichnisse von Usern existieren, die die DS nicht kennt?

Eigentümer und Gruppe werden ja nummerisch gespeichert und nicht zum Namen aufgelöst. Wenn die Daten also einem User gehören, den die DS ned kennt, dann werden einfach die Nummern angezeigt beim dir oder ls -al
Problematisch wird dies erst wenn du auf der DS als non-root User diese Daten lesen und ggf ändern willst. Dann wird sich die DS, je nach Rechten der Dateien, querlegen und den Zugriff verweigern

 

[wired2051]

Problematisch wird dies erst wenn du auf der DS als non-root User diese Daten lesen und ggf ändern willst. Dann wird sich die DS, je nach Rechten der Dateien, querlegen und den Zugriff verweigern

OK, damit werde ich dann wohl leben müssen.

Mich wundert nur, warum Synology so komische UIDs verwendet. 1026?

Da fällt mir noch etwas ein: kann man evtl. so etwas wie einen Zähler zurücksetzen, damit ein mit dem DSM erstellter User eine passende UID hat? Die GID 100 existiert bei Kubuntu-Linux sogar, wird nur nicht genutzt, wenn ich nicht irre...

 

[jahlives]

Da fällt mir noch etwas ein: kann man evtl. so etwas wie einen Zähler zurücksetzen, damit ein mit dem DSM erstellter User eine passende UID hat? Die GID 100 existiert bei Kubuntu-Linux sogar, wird nur nicht genutzt, wenn ich nicht irre...

Diese Idee hatte glaub ich goetz auch einmal. Ich weiss ned ob er das an Synology herangtragen hat. Müsstest ihn mal fragen...

 

[goetz]

Hallo,
ich habe es auf der Cebit angesprochen und man hat es auch als Problem erkannt. Ob es sich aber jemals ändern wird würde ich eher bezweifeln, bestehende Stations umzustricken dürfte nicht so einfach sein.

Gruß Götz

 

[goetz]

Hallo,
Du kannst mit adduser und addgroup den entsprechenden User und die Gruppe anlegen. Dieser User ist dann aber nicht über DSM verwaltbar.
Quelle:

addgroup
addgroup [-g GID] [user_name] group_name
Add a group or add a user to a group
Options:
-g GID Group id
-S Create a system group

adduser
adduser [OPTIONS] user_name
Add a user
Options:
-h DIR Home directory
-g GECOS GECOS field
-s SHELL Login shell
-G GRP Add user to existing group
-S Create a system user
-D Do not assign a password
-H Do not create home directory
-u UID User id

Gruß Götz