Sysvol sync

Ich habe das Problem, dass zwischen einem Master und Backup das SYSVOL Verzeichnis nicht synchronisiert wird. Das Verzeichnis ist am Backup komplett leer. Eine manuelle Ausführung des Scripts hilft auch nichts.

mastersrv ucr:

[code]samba/share/sysvol/readonly:
If this variable is set to ‘yes’ the SYSVOL share is not writable. This setting shouldn’t usually be set.

samba/share/sysvol:
If this option is activated or unset, the Samba server provides the SYSVOL share which amongst other things contains the GPO data.

samba4/sysvol/cleanup/cron: 4 4 * * *
This variable configures the time/interval when the group policy objects (GPOs), which are no longer referenced in the LDAP are deleted from the Sysvol share. The format is documented under ‘man 5 crontab’. If the variable is unset, unreferenced GPOs are not removed.

samba4/sysvol/cleanup/parameters:
Additional parameters for the sysvol cleanup Cron job.

samba4/sysvol/sync/cron: */5 * * * *
This variable configures the time/interval when the Sysvol replication occurs. The format is documented under ‘man 5 crontab’.

samba4/sysvol/sync/host: mastersrv

samba4/sysvol/sync/jitter: 60
To prevent that all Sysvol replications start at the same time, a random time span between 0 and the number of seconds configured in this variable is waited before the Sysvol replication is initiated.

samba4/sysvol/sync/setfacl/AU: false
If this option is activated the ACLs are set during each Sysvol replication. If the variable is unset, this isn’t done.[/code]

backupsrv ucr:

[code]samba/share/sysvol/readonly:
If this variable is set to ‘yes’ the SYSVOL share is not writable. This setting shouldn’t usually be set.

samba/share/sysvol:
If this option is activated or unset, the Samba server provides the SYSVOL share which amongst other things contains the GPO data.

samba4/sysvol/cleanup/cron: 4 4 * * *
This variable configures the time/interval when the group policy objects (GPOs), which are no longer referenced in the LDAP are deleted from the Sysvol share. The format is documented under ‘man 5 crontab’. If the variable is unset, unreferenced GPOs are not removed.

samba4/sysvol/cleanup/parameters:
Additional parameters for the sysvol cleanup Cron job.

samba4/sysvol/sync/cron: */5 * * * *
This variable configures the time/interval when the Sysvol replication occurs. The format is documented under ‘man 5 crontab’.

samba4/sysvol/sync/host: mastersrv

samba4/sysvol/sync/jitter: 60
To prevent that all Sysvol replications start at the same time, a random time span between 0 and the number of seconds configured in this variable is waited before the Sysvol replication is initiated.

samba4/sysvol/sync/setfacl/AU: false
If this option is activated the ACLs are set during each Sysvol replication. If the variable is unset, this isn’t done.[/code]

Hallo,

das Log dazu ist /var/log/univention/sysvol-sync.log.
Man kann auch mal schauen, was bei

bash -x /usr/share/univention-samba4/scripts/sysvol-sync.sh

passiert.

Viele Grüße,
Dirk Ahrnke

Beim mastersrv wo der SYSVOL Inhalt vorhanden sieht die Ausgabe von sysvol-sync so aus:

[code]++ /usr/sbin/univention-config-registry shell hostname samba4/sysvol/sync/host

  • eval ‘hostname=mastersrv
    samba4_sysvol_sync_host=mastersrv’
    ++ hostname=mastersrv
    ++ samba4_sysvol_sync_host=mastersrv
  • SYSVOL_PATH=/var/lib/samba/sysvol
  • SYSVOL_SYNCDIR=/var/cache/univention-samba4/sysvol-sync
  • SYSVOL_SYNC_TRIGGERDIR=/var/cache/univention-samba4/sysvol-sync/.trigger
  • ‘[’ -d /var/cache/univention-samba4/sysvol-sync/.trigger ‘]’
  • chgrp ‘DC Slave Hosts’ /var/cache/univention-samba4/sysvol-sync/.trigger
  • chmod g+w /var/cache/univention-samba4/sysvol-sync/.trigger
  • univention_samba4_is_ucr_false samba4/sysvol/sync/setfacl/AU
  • local value
    ++ univention-config-registry get samba4/sysvol/sync/setfacl/AU
  • value=false
  • case “$(echo -n “$value” | tr [:upper:] [:lower:])” in
    ++ echo -n false
    ++ tr ‘[:upper:]’ ‘[:lower:]’
  • return 0
    ++ find /var/cache/univention-samba4/sysvol-sync/.trigger -mindepth 1 -maxdepth 1 -type f
  • for s4dc in ‘$samba4_sysvol_sync_host’
  • ‘[’ mastersrv = mastersrv ‘]’
  • continue[/code]

beim Backup (datensrv) sieht es so aus:

[code]++ /usr/sbin/univention-config-registry shell hostname samba4/sysvol/sync/host

  • eval ‘hostname=datensrv
    samba4_sysvol_sync_host=mastersrv’
    ++ hostname=datensrv
    ++ samba4_sysvol_sync_host=mastersrv
  • SYSVOL_PATH=/var/lib/samba/sysvol
  • SYSVOL_SYNCDIR=/var/cache/univention-samba4/sysvol-sync
  • SYSVOL_SYNC_TRIGGERDIR=/var/cache/univention-samba4/sysvol-sync/.trigger
  • ‘[’ -d /var/cache/univention-samba4/sysvol-sync/.trigger ‘]’
  • chgrp ‘DC Slave Hosts’ /var/cache/univention-samba4/sysvol-sync/.trigger
  • chmod g+w /var/cache/univention-samba4/sysvol-sync/.trigger
  • univention_samba4_is_ucr_false samba4/sysvol/sync/setfacl/AU
  • local value
    ++ univention-config-registry get samba4/sysvol/sync/setfacl/AU
  • value=false
  • case “$(echo -n “$value” | tr [:upper:] [:lower:])” in
    ++ echo -n false
    ++ tr ‘[:upper:]’ ‘[:lower:]’
  • return 0
    ++ find /var/cache/univention-samba4/sysvol-sync/.trigger -mindepth 1 -maxdepth 1 -type f
  • for s4dc in ‘$samba4_sysvol_sync_host’
  • ‘[’ mastersrv = datensrv ‘]’
  • univention-ssh-rsync /etc/machine.secret -autAX ‘datensrv$@mastersrv:/var/lib/samba/sysvol/’ /var/lib/samba/sysvol
  • univention-ssh /etc/machine.secret ‘datensrv$@mastersrv’ ‘mkdir -p ‘’’/var/cache/univention-samba4/sysvol-sync/.trigger’’’; touch ‘’’/var/cache/univention-samba4/sysvol-sync/.trigger/datensrv’’’’[/code]

Das was mir auffällt ist das in der vorletzten Zeile beim mastesrv " ‘[’ mastersrv = mastersrv ‘]’" steht und beim datensrv in der drittvorletzten Zeile “’[’ mastersrv = datensrv ‘]’”

lg

Hallo,

nimm mal bitte “code”-Blöcke für solche Ausgaben, das ist dann etwas besser lesbar.
Mich irritiert etwas die rsync-Option “autAX”:
Ab Zeile 61 von /usr/share/univention-samba4/scripts/sysvol-sync.sh (Version 3.0.39-32.585.201407281655) sehe ich keine “t”-Option. Ich finde auch keinen Bug, der auf eine Änderung in der Vergangenheit schließen lässt.
Hat jemand da manuell geändert?

Die Tests sollte man auch besser durchführen, wenn man weiß, dass etwas geändert wurde. Es bietet sich an, im scripts-Verzeichnis auf dem Master etwas abzulegen.

Viele Grüße,
Dirk Ahrnke

Hallo,
geändert wurde in den Scripts gar nichts. Auch das manuelle erstellen einer Datei im Script Verzeichnis hilft nichts.
Ich weiß jetzt nicht was mit der “t” Option gemein ist. In beide Scripts ist die Zeile “univention-ssh-rsync /etc/machine.secret -atAX --delete” mit den Parametern -atAX vorhanden.

lg

Hallo,

von welcher Version des Pakets univention-samba4-sysvol-sync reden wir hier? Die UCS-Version hast Du auch noch nicht mitgeteilt.

In Version 3.0.39-32.585.201407281655 von univention-samba4-sysvol-sync hat die Zeile, die bei Deiner Ausgabe von datensrv “univention-ssh-rsync” ruft, keine hart-kodierten rsync Optionen sondern nimmt die weiter oben definierten “rsync_options”. Und der einzige Ruf mit “–delete” ist der “## step one: pull over network from downstream s4dc” (und selbst dort habe ich hier kein -t). Aber das ist eben auch nicht

Hast Du ggf. die Möglichkeit das Skript mit einem anderen System zu vergleichen?

Viele Grüße,
Dirk

Ja es gibt Unterschiede zu Univention
version/erratalevel: 111
version/patchlevel: 2
version/releasename: Borgfeld
version/version: 3.2

gegenüber der älteren installierten Version
version/erratalevel: 3
version/patchlevel: 0
version/releasename: Borgfeld
version/version: 3.2

Kann ich das neuere Script einfach drüberkopieren? Ich möchte jetzt nicht unbedingt eine Univentionupdate einspielen.

Hier sind die Unterschiede:
61,66d60
< if [ “$1” = ‘–overwrite-local’ ]; then
< rsync_options=("-aAX")
< else
< rsync_options=("-auAX" “–dirs-update”)
< fi
<
81c75
< univention-ssh-rsync /etc/machine.secret -aAX --delete \

  univention-ssh-rsync /etc/machine.secret -atAX --delete \

85c79
< rsync “${rsync_options[@]}” “$importdir”/ “$SYSVOL_PATH”

  rsync -autAX "$importdir"/ "$SYSVOL_PATH"

94c88
< univention-ssh-rsync /etc/machine.secret “${rsync_options[@]}” \

  univention-ssh-rsync /etc/machine.secret -autAX \

Hallo,

also ich denke ja, dass der Sinn der Errata die Beseitigung von festgestellten Fehlern ist. Gerade im Kontext Samba 4 würde ich daher doch eher für das Einspielen der Updates plädieren.

Warum der Sysvol-Sync hier fehlschlägt, ist letztendlich auch nicht geklärt. Die abweichenden rsync-Optionen fielen mir halt nur auf, da anscheinend der eigentliche Synchronisationsprozess nichts holt. Da könnte z.B. auch ein Berechtigungsproblem die Ursache sein. Also so was wie [bug]35564[/bug].

Viele Grüße,
Dirk

Also mit Script einfach kopieren tut sich auch nichts. Man muss wahrscheinlich das ganze Univention updaten. Hoffentlich funktioniert es dann … :frowning:

Hallo,

ich würde noch mal einen elementaren Berechtigungstest machen.

root@backup:/tmp# univention-ssh-rsync /etc/machine.secret -auAXnv 'backup$@master:/var/lib/samba/sysvol' .

Das funktioniert wie im Skript. Unterschied sind die Optionen “v” für verbose und “n” für "keine Daten transportieren. Hostnamen musst Du natürlich noch anpassen.

Viele Grüße,
Dirk

Es dürfte an einer Berechtigung liegen:
cd /tmp

univention-ssh-rsync /etc/machine.secret -auAXnv ‘datensrv$@mastersrv:/var/lib/samba/sysvol’ .
Could not chdir to home directory /dev/null: Not a directory
receiving incremental file list
rsync: opendir “/var/lib/samba/sysvol” failed: Permission denied (13)
sysvol/

sent 15 bytes received 283 bytes 198.67 bytes/sec
total size is 0 speedup is 0.00 (DRY RUN)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1526) [generator=3.0.7]

Hallo,
prüf mal das und gleiche es mit den Informationen aus [bug]35564[/bug] ab:

root@master:/var/lib/samba# ls -ld sysvol
drwxrwx---+ 3 Administrator Administrators 4096  6. Jul 2012  sysvol

root@master:/var/lib/samba# getfacl sysvol
# file: sysvol
# owner: Administrator
# group: Administrators
user::rwx
user:Administrator:rwx
group::rwx
group:Administrators:rwx
group:System\040Operators:r-x
group:Authenticated\040Users:r-x
group:System:rwx
mask::rwx
other::---
default:user::rwx
default:user:Administrator:rwx
default:group::---
default:group:Administrators:rwx
default:group:System\040Operators:r-x
default:group:Authenticated\040Users:r-x
default:group:System:rwx
default:mask::rwx
default:other::---

root@master:/var/lib/samba# id backup$
uid=2108(backup$) gid=5005(DC Backup Hosts) groups=5005(DC Backup Hosts),5007(Computers),1005(Windows Hosts),5006(DC Slave Hosts),5037(Authenticated Users),5045(Denied RODC Password Replication Group),5054(Domain Controllers),5060(Enterprise Domain Controllers)

Viele Grüße,
Dirk

Die Berechtigungen passen soweit. Die Befehle vom Bugreport habe ich auch ausgeführt.

Das was mir auffällt ist das:

id datensrv$ # backupserver
uid=2006(datensrv$) gid=5005(DC Backup Hosts) Gruppen=5005(DC Backup Hosts),1015(Enterprise Domain Controllers)

So wie es aussieht soll hier mehr drinnen stehen:
uid=2108(backup$) gid=5005(DC Backup Hosts) groups=5005(DC Backup Hosts),5007(Computers),1005(Windows Hosts),5006(DC Slave Hosts),5037(Authenticated Users),5045(Denied RODC Password Replication Group),5054(Domain Controllers),5060(Enterprise Domain Controllers)

Also ich interpretiere im Moment die Voraussetzungen wie folgt:

Das lesende System ist über die Mitgliedschaft in “Authenticated Users” berechtigt, Daten zu sehen. Diese fehlt bei Dir. Du solltest mal die Gruppenmitglidschaften inklusive der Verschachtelungen mit einem funktionierenden System vergleichen.

nachdem ich die gruppenmitgliedschaften hinzugefügt habe funktioniert das ganze wieder. Danke!

Mastodon