Univention Bugzilla – Bug 33388
DC Slave \0ACNF: object after joining via DC Backup
Last modified: 2016-10-21 06:28:48 CEST
Created attachment 5632 [details] Short overview of the essential timestamps. In a test domain the following situation led to a \0ACNF: object for the DC Slave account after the DC Slave joined via the DC Backup: 1. DC Master with Samba4 2. DC Backup installation/join started 3. DC Slave installation/join started (maybe before DC Backup join finished). The join.log on the DC Slave shows that samba-tool decided to join against the DC Backup. Accordingly object timesamps show that the original DC account object for the DC Slave was created in the Samba4 diectory of the DC Backup. Some minutes later (assuming the clocks of master and backup have been in sync), the connector-s4.log on the DC Master shows a "modification" (I guess it's an add?) of the DC Slave account object coming from UCS LDAP. Accordingly there is a second DC Slave account created at that time. And then a DRS replication confliced occurred, renaming the "older" Samba4 object to \0ACNF:. Maybe there is something we can learn from this case to avoid this.
Created attachment 5633 [details] s4slave-join.log
Created attachment 5634 [details] connector-s4.log
Created attachment 5635 [details] s4search outputs for the objects collected from s4master and s4-backup.
Created attachment 5640 [details] Timestamps of the s4slave and s4-backup LDAP objects The timestamps show that the DC Backup account was created in UCS LDAP just 1 minute 21 seconds before the account of the DC Slave. Then, the sync of the DC Backup account from LDAP to Samba4 took about 2:42 but the sync of the DC Slave account then took about 8:29. So I guess S4 Connector sync delay / load plays a considerable role here.
Just some quick notes, maybe it helps to reproduce this one day. The test setup had been created with virtualized systems, setup with the appliance setup. The DC backup and slave system were running their installation procedure simultaneously.
IMHO the most straight forward solution to avoid this situation would be to always let systems join against the System which runs the S4 Connector (UCS@school Bug 32187 should be borne in mind while designing this solution). The second, more complicated solution might be to change the UDM machine account creation process during join (univention-server-join?) to create machine accounts always without samba option and let this option be added at a later stage via the following three possible samba machine account creation mechanisms: 1. by letting the S4-Connector do this (in the UCS default Samba4 domain) 2. by umc_module_selective_udm (in UCS@school) 3. by the Samba 3 LDAP passdb backend
See also Bug 32257.
Can it still happen? I didn't see it again.
(In reply to Stefan Gohmann from comment #8) > Can it still happen? I didn't see it again. Works for me.