My master version is 389-ds-base-1.2.11.15-50.el6_6.x86_64 .

Thanks.



2015-06-08 10:25 GMT+02:00 thierry bordaz <tbor...@redhat.com>:

>  Hello James,
>
> The fact that the master is more powerfull than the replica increase the
> possibility to hit that bug.
> The bug fix is on the master side. The master is made smarter to adapt its
> replication flow to the speed of the consumer.
> The bug is fixed in 389-ds-base-1.3.3.1-10.el7 and
> 389-ds-base-1.2.11.15-56.el6.
>
> What is the current version of your master ?
>
> thanks
> thierry
>
> On 06/08/2015 09:49 AM, James James wrote:
>
> Hi Thierry,
>
>  thanks for you answer.
>
>  I was away for a long time, this is why my post comes later .
>
>  This timing issue is coming when you try to upgrade from rhel 6
> (ipa-3.0) to rhel7 (ipa4.xx) ?
>
>  I have a physical machine for the master and a VM as replica. The
> solution is to use a physical machine for the replica ?
>
>  How can I limit the cpu/memory in the physical machine (with cgroups ??).
>
>  Any  hints will be appreciated ..
>
>  Regards
>
>  James
>
> 2015-05-18 14:04 GMT+02:00 thierry bordaz <tbor...@redhat.com>:
>
>>  On 05/15/2015 05:11 PM, James James wrote:
>>
>>  ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 .
>>
>>
>>  Hi James,
>>
>> Unfortunately there is no workaround. This is a timing issue mostly seen
>> when the master is more powerful than the consumer.
>> If you are using VM you may try to get master/replica with nearly the
>> same cpu/memory.
>>
>> thanks
>> thierry
>>
>>
>>  Best.
>>
>>  James
>>
>> 2015-05-15 16:58 GMT+02:00 Rich Megginson <rmegg...@redhat.com>:
>>
>>>  On 05/15/2015 08:46 AM, James James wrote:
>>>
>>> [root@ipa ~]#  rpm -q 389-ds-base
>>> 389-ds-base-1.2.11.15-50.el6_6.x86_64
>>>
>>>
>>>  Ok.  Looks like this is planned to be fixed in RHEL 6.7 with version
>>> 389-ds-base-1.2.11.15-56.el6
>>>
>>> I don't know if there are any workarounds.
>>>
>>>
>>>
>>>
>>>
>>> 2015-05-15 16:32 GMT+02:00 Rich Megginson <rmegg...@redhat.com>:
>>>
>>>>  On 05/15/2015 08:22 AM, James James wrote:
>>>>
>>>>  I think that :
>>>>
>>>> Starting replication, please wait until this has completed.
>>>> Update in progress, 127 seconds elapsed
>>>> Update in progress yet not in progress
>>>>
>>>>
>>>>  looks like a time error : https://fedorahosted.org/freeipa/ticket/4756
>>>>
>>>>
>>>>  That issue should have been fixed in 389-ds-base-1.3.3 branch.  What
>>>> version of 389-ds-base?  rpm -q 389-ds-base
>>>>
>>>>
>>>>
>>>> 2015-05-15 16:00 GMT+02:00 Rich Megginson <rmegg...@redhat.com>:
>>>>
>>>>>  On 05/15/2015 07:55 AM, James James wrote:
>>>>>
>>>>> Is it possible to change the nsds5ReplicaTimeout value to get rid of
>>>>> this timeout error ?
>>>>>
>>>>>
>>>>> What timeout error?
>>>>>
>>>>>
>>>>> 2015-04-17 4:52 GMT+02:00 Rich Megginson <rmegg...@redhat.com>:
>>>>>
>>>>>>  On 04/15/2015 10:44 PM, James James wrote:
>>>>>>
>>>>>> The ipareplica-install.log file in attachment ...
>>>>>>
>>>>>>
>>>>>>  Here are the pertinent bits:
>>>>>>
>>>>>> 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389]
>>>>>> timeout 300
>>>>>> 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from
>>>>>> SchemaCache
>>>>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=
>>>>>> ldap://ipa.example.com:389 conn=<ldap.ldapobject.SimpleLDAPObject
>>>>>> instance at 0x484f4d0>
>>>>>> 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636
>>>>>> from SchemaCache
>>>>>> 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=
>>>>>> ldaps://ipa1.example.com:636 conn=<ldap.ldapobject.SimpleLDAPObject
>>>>>> instance at 0x4170290>
>>>>>> 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last):
>>>>>>   File
>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
>>>>>> 382,
>>>>>> in start_creation
>>>>>>     run_step(full_msg, method)
>>>>>>   File
>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
>>>>>> 372,
>>>>>> in run_step
>>>>>>     method()
>>>>>>   File
>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
>>>>>> 368, in __setup_replica
>>>>>>     r_bindpw=self.dm_password)
>>>>>>   File
>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line
>>>>>> 969, in setup_replication
>>>>>>     raise RuntimeError("Failed to start replication")
>>>>>> RuntimeError: Failed to start replication
>>>>>>
>>>>>>  2015-04-15T15:08:44Z DEBUG   [error] RuntimeError: Failed to start
>>>>>> replication
>>>>>>
>>>>>> The times are a little off, but I believe this corresponds to
>>>>>> [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete.
>>>>>> Processed 1539 entries in 126 seconds. (12.21 entries/sec)
>>>>>> [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin -
>>>>>> multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is
>>>>>> coming online; enabling replication
>>>>>>
>>>>>>  I don't know why setup_replication is reporting an error if
>>>>>> replication completed successfully.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-04-16 2:22 GMT+02:00 Rob Crittenden <rcrit...@redhat.com>:
>>>>>>
>>>>>>> Rich Megginson wrote:
>>>>>>> > On 04/15/2015 02:58 PM, James James wrote:
>>>>>>> >> Nothing on the replica .. maybye a process on the master. How can
>>>>>>> I
>>>>>>> >> check that ?
>>>>>>> >
>>>>>>> > I have no idea.  But it seems highly unlikely that a process on the
>>>>>>> > master is able to shutdown a process on the replica . . .
>>>>>>> >
>>>>>>> > I would say that there is some problem with the
>>>>>>> ipa-replica-install not
>>>>>>> > properly checking the status - see below:
>>>>>>> >
>>>>>>> >>
>>>>>>> >> 2015-04-15 21:37 GMT+02:00 Rich Megginson <rmegg...@redhat.com
>>>>>>> >> <mailto:rmegg...@redhat.com>>:
>>>>>>> >>
>>>>>>> >>     On 04/15/2015 12:43 PM, James James wrote:
>>>>>>> >>>     Here the log
>>>>>>> >>>
>>>>>>> >>>     2015-04-15 18:58 GMT+02:00 Rich Megginson <
>>>>>>> rmegg...@redhat.com
>>>>>>> >>>     <mailto:rmegg...@redhat.com>>:
>>>>>>> >>>
>>>>>>> >>>         On 04/15/2015 09:46 AM, James James wrote:
>>>>>>> >>>>         Hello,
>>>>>>> >>>>
>>>>>>> >>>>         I have been looking to solve my problem but I 'm asking
>>>>>>> for
>>>>>>> >>>>         some help.
>>>>>>> >>>>
>>>>>>> >>>>         The replication begins but cannot be completed ....
>>>>>>> >>>>
>>>>>>> >>>>         I want to install a new fresh replica but I've always
>>>>>>> got
>>>>>>> >>>>         this error :
>>>>>>> >>>>
>>>>>>> >>>>         [21/35]: configure dirsrv ccache
>>>>>>> >>>>           [22/35]: enable SASL mapping fallback
>>>>>>> >>>>           [23/35]: restarting directory server
>>>>>>> >>>>           [24/35]: setting up initial replication
>>>>>>> >>>>         Starting replication, please wait until this has
>>>>>>> completed.
>>>>>>> >>>>         Update in progress, 127 seconds elapsed
>>>>>>> >>>>         Update in progress yet not in progress
>>>>>>> >>>>
>>>>>>> >>>>         Update in progress yet not in progress
>>>>>>> >>>
>>>>>>> >
>>>>>>> > in progress yet not in progress????  The error log below clearly
>>>>>>> shows
>>>>>>> > that replica init succeeded after 127 seconds.
>>>>>>> >
>>>>>>> > IPA-ers - wasn't there some bug about checking replica status
>>>>>>> properly?
>>>>>>> >
>>>>>>>
>>>>>>> The loop looks at nsds5BeginReplicaRefresh,
>>>>>>> nsds5replicaUpdateInProgress
>>>>>>> and nsds5ReplicaLastInitStatus.
>>>>>>>
>>>>>>> It loops looking for nsds5BeginReplicaRefresh. If there is no value
>>>>>>> it
>>>>>>> prints "Update in progress, %d seconds elapsed". Once it gets a
>>>>>>> status,
>>>>>>> the update is done, and it looks at nsds5ReplicaLastInitStatus. If it
>>>>>>> isn't empty, doesn't include 'replica busy' or 'Total update
>>>>>>> succeeded'
>>>>>>> then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it
>>>>>>> is,
>>>>>>> ir prints Update in progress yet not in progress and tries the loop
>>>>>>> again.
>>>>>>>
>>>>>>> AFAICT this part of a replica install doesn't restart 389-ds.
>>>>>>>
>>>>>>> /var/log/ipareplica-install.log may hold some details.
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to