My apologies, I have been side-tracked for a few days.
Here are the latest tests.
I installed a new virtual DC_slave and got the same result with the install failing at the Domain join.
The failed.ldif on this machine was the same length (60Kb) as that on the DC_backup.
Back on the DC_backup I repeated the routine in What to do if a failed.ldif is found
root@deimos:~#/etc/init.d/slapd restart
[....] Restarting slapd (via systemctl): slapd.service
ps aux | grep /usr/sbin/univention-directory-replication-resync show nothing running
Eventually ldap fails as mentioned before.
slapd.service failed
No new entry’s in /var/log/univention/listener.log and /var/log/univention/ldap-replication-resync.log
I deleted the failed.ldif and re-ran univention-join
The join log contained an conflicting name error
12.03.18 17:11:30.948 LISTENER ( WARN ) : Set Schema ID to 6
12.03.18 17:11:30.948 LISTENER ( WARN ) : initializing module replication
12.03.18 17:12:30.439 LISTENER ( ERROR ) : replication: Naming violation; dn="krb5PrincipalName=ldap/apollo.e
nviroscience.intranet@ENVIROSCIENCE.INTRANET,cn=kerberos,dc=enviroscience,dc=intranet": Error
12.03.18 17:12:30.440 LISTENER ( ERROR ) : additional info: value of single-valued naming attribute 'k
rb5PrincipalName' conflicts with value present in entry
12.03.18 17:12:32.405 LISTENER ( WARN ) : finished initializing module replication with rv=0
12.03.18 17:12:32.405 LISTENER ( WARN ) : initializing module bind
12.03.18 17:12:32.688 LISTENER ( WARN ) : finished initializing module bind with rv=0
12.03.18 17:12:32.689 LISTENER ( WARN ) : initializing module well-known-sid-name-mapping
12.03.18 17:12:39.663 LISTENER ( WARN ) : finished initializing module well-known-sid-name-mapping with rv=0
listener.log now contains:
> Try to sync changes stored in /var/lib/univention-directory-replication/failed.ldif into local LDAP
> USER PID ACCESS COMMAND
> /var/lib/univention-directory-replication/failed.ldif:
> root 22726 F.... univention-dire
> File still in use: /var/lib/univention-directory-replication/failed.ldif
> 12.03.18 17:23:57.911 DEBUG_INIT
> UNIVENTION_DEBUG_BEGIN : uldap.__open host=phobos.enviroscience.intranet port=7389 base=dc=enviroscience,dc=intranet
> UNIVENTION_DEBUG_END : uldap.__open host=phobos.enviroscience.intranet port=7389 base=dc=enviroscience,dc=intranet
Is ‘file still in use’ unexpected? After everything completed I ran
lsof |grep failed.ldif and nothing had the file open then.
And ldap-replication-resync.log
Try to sync changes stored in /var/lib/univention-directory-replication/failed.ldif into local LDAP
USER PID ACCESS COMMAND
/var/lib/univention-directory-replication/failed.ldif:
root 22726 F.... univention-dire
File still in use: /var/lib/univention-directory-replication/failed.ldif
12.03.18 17:23:57.911 DEBUG_INIT
UNIVENTION_DEBUG_BEGIN : uldap.__open host=phobos.enviroscience.intranet port=7389 base=dc=enviroscience,dc=intranet
UNIVENTION_DEBUG_END : uldap.__open host=phobos.enviroscience.intranet port=7389 base=dc=enviroscience,dc=intranet
What can I do about the ‘name violation error’ on join?
Why doesn’t slapd restart do anything, including re-read the failed.ldif?
Why did I get this error on a fresh new server with no existing ldap database?
Thanks for your help.