[r...@fileserver1 ~]# rpm -qa|grep 389
[djsc...@fileserver2 ~]$ rpm -qa|grep 389
fileserver1 is the server with the problem, fileserver2 is the master.
Rich Megginson's post indicates that the errors in the log are fixed
in 389-ds-base-1.2.6.rc7 (I'm not sure whether that's earlier or later
than 389-ds-base-1.2.6-0.1.a1 - an alpha?). Hopefully there will be an
update soon, and this will resolve the problem.
On Wed, Aug 11, 2010 at 12:26, Rob Crittenden <rcrit...@redhat.com> wrote:
> Dan Scott wrote:
>> I have a FreeIPA slave server which used to be running Fedora 11 and
>> has recently been upgraded to Fedora 13. It is replicating from a
>> server which is still running Fedora 11.
>> Twice over the last week, the process providing LDAP (dirsrv?) has
>> died. I receive these errors in /var/log/messages:
>> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP
>> server ldap://localhost: Can't contact LDAP server
>> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP
>> server - Server is unavailable
>> This could well just be an artifact of the upgrade, since the upgrade
>> process does not install the sssd package by default. I have no idea
>> how nscd/sssd should be configured on a FreeIPA server.
>> And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around
>> the time that LDAP requests started failing.
>> [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry:
>> Param error: Empty entry
>> [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin -
>> _delete_tombstone: unable to delete tombstone
>> uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error.
>> [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin -
>> agmt="cn=meTofileserver2.example.com636" (fileserver2:636):
>> Incremental protocol: event update_window_opened should not occur in
>> state wait_for_changes
>> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation
>> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30
>> threads to terminate
>> Restarting dirsrv does not appear to help, the 'stop' process fails.
>> However, rebooting the PC does work, and the server processes LDAP
>> requests, until the replication occurs again.
>> With a little googling, I found this:
>> Which could well apply in my case, but I wanted to check to ensure
>> that this would apply to FreeIPA.
>> Does anyone have any comments suggestions about this?
>> Dan Scott
> What version of 389-ds are you running on both sides?
Freeipa-users mailing list