[Freeipa-users] Upgraded replication slave server - dirsrv process dying

Rich Megginson rmeggins at redhat.com
Wed Aug 11 20:47:48 UTC 2010


Dan Scott wrote:
> Hi,
>
> [root at fileserver1 ~]# rpm -qa|grep 389
> 389-ds-base-1.2.6-0.1.a1.fc13.i686
>
> [djscott at fileserver2 ~]$ rpm -qa|grep 389
> 389-ds-base-1.2.5-1.fc11.i586
>
> 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
>   
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
> Thanks,
>
> Dan
>
> On Wed, Aug 11, 2010 at 12:26, Rob Crittenden <rcritten at redhat.com> wrote:
>   
>> Dan Scott wrote:
>>     
>>> Hi,
>>>
>>> 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
>>>
>>> nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com,
>>> 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
>>> threads
>>> [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:
>>>
>>>
>>> http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> Dan Scott
>>>       
>> What version of 389-ds are you running on both sides?
>>
>> rob
>>
>>     
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>   




More information about the Freeipa-users mailing list