Dan Scott wrote:

[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?).
Yes, an alpha
Hopefully there will be an
update soon, and this will resolve the problem.
The update is in updates-testing now, and we would really appreciate some testing and some feedback (hint, hint). The more positive feedback we get, the faster we can move the packages to stable and out of testing (as per Fedora policy).
yum update --enablerepo=updates-testing 389-ds-base
See also http://directory.fedoraproject.org/wiki/Release_Notes


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

Freeipa-users mailing list

Reply via email to