Univention Bugzilla – Bug 27483
sysvol-sync inconsistent 5 minutes
Last modified: 2020-07-03 20:52:44 CEST
Bei der Sysvol-Synchronisierung fiel noch folgendes auf: Tätigt man Änderungen an einer GPO (oder erstellt eine neue GPO) und erstellt dann im Anschluss einen Report der Einstellungen, so führt dies zu einer Fehlermeldung, sofern hier zufällig ein Backupcontroller abgefragt wird. "Unbekannter Fehler bei der Zusamenstellung von Informationen. [...] ein Teil des Pfades (Policy im Sysvol-Pfad) konnte nicht gefunden werden." Ursache ist hier, dass die LDB-Einstellungen und die Grundstruktur der GPO im Dateisystem zwar per DRS annähernd in Echtzeit synchronsiert werden, die konkreten Einstellungen unterhalb der Policy in "/var/lib/samba/sysvol" aber erst nach 5 Minuten per Cron repliziert werden. In diesen 5 Minuten kann die geänderte GPO nicht vollständig von einem DC Backup abgefragt werden. Für das Generieren eines Reports ist das nicht kritisch. Es ist aber beispielsweise auch denkbar, dass während dieser 5 Minuten eine Anmeldung gegen einen der Backups durchgeführt wird - das wird dann vermutlich zu Problemen führen.
Ja, das ist im Moment by Design so. Falls eine GPO nicht auf dem DC angelegt wird, der den S4 Connector bereitstellt, dann dauert es max. 5 min bis dieser die Policy-Dateien im Dateisystem per rsync zu sich gezogen hat und weitere 5 min. bis andere DCs die GPO erhalten. Die UCR Variable samba4/sysvol/sync/cron kann angepasst werden. Mit der Synchronisation der GPO-Objekte nach OpenLDAP, die in UCS@School implementiert wurde, könnte ich mir spontan alternativ vorstellen, die Synchronisation per Listener zu triggern. Dafür müsste der Connector vermutlich an die Kopie des GPO-Objekts im OpenLDAP in einem separaten Attribut vermerken, welcher DC gerade eine aktualisierte Version des GPO-Objekts geschrieben hat. Übersehe ich dabei etwas?
Direktere Alternative: Samba4 LDB-Modul statt Listener-Modul.
Spricht was gegen incron? incron verbindet inotify und cron. Gibt es Änderungen in einem Verzeichnis, wird incron ähnlich wie cron aktiv. http://packages.debian.org/search?keywords=incron
Mit inotify hatte ich das Problem, die Triggerbedingung so zu definieren, dass der Sync nur einmal ausgeführt wird, wenn die GPO-Definition im Dateisystem "fertig" ist. Man müsste sich da das Schreibverhalten von Samba4 nochmal genauer anschauen.
Wurde mit Ticket#: 2013011121000717 von mehreren Kunden angefragt.
This issue has been filed against UCS 3.0. UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please reopen.
Still an issue of our current sysvol-replication design. Alternative approaches: * Comment 3 (incron) + rsync * I'll attach an inotify event log example which I have gathered lately. * smbclient "notify" (change notify) + rsync * https://msdn.microsoft.com/en-us/library/dn392331.aspx * showstopper: didn't listen on subdirs in my quick test * But there is a new "notifyd" in samba 4.3 (not shipped), maybe that works * Optional: Make sysvol writable only on the master to avoid concurrency & locking issues and replication storms right from the start. This bug is about the trigger part of the synchronization, not about the rsync part (note that we had to patch rsync to make dir facl modifications work)
Created attachment 8784 [details] gpo_inotify.log
*** Bug 39521 has been marked as a duplicate of this bug. ***
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.