subject:"Re\: \[Freeipa\-users\] Replication seems to begin but failed after 127 seconds ..."

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-06-08 Thread James James

Yes,

as soon as 389-ds-base-1.2.11.15-56.el6 will be available, I will update
the master.

Rich Megginson says that  389-ds-base-1.2.11.15-56.el6 will be shipped with
rhel 6.7.

Thus I will wait for 6.7 before trying to update the master and create a
rhel 7 replica.

Many thanks.



2015-06-08 14:56 GMT+02:00 thierry bordaz :

>  Hi,
>
> Would you update your master to 389-ds-base-1.2.11.15-56.el6, before
> attempting the upgrade to 7 ?
>
> thanks
> thierry
>
> On 06/08/2015 12:30 PM, James James wrote:
>
> 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 :
>
>>  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 :
>>
>>>  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 :
>>>
  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 :

>  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 :
>
>>  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 :
>>
>>>  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=>> 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=>> 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   [er

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-06-08 Thread thierry bordaz


Hi,

Would you update your master to 389-ds-base-1.2.11.15-56.el6, before 
attempting the upgrade to 7 ?


thanks
thierry
On 06/08/2015 12:30 PM, James James wrote:

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 >:


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 mailto: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
mailto: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
mailto: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
mailto: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
mailto: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=
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=
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-06-08 Thread James James

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 :

>  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 :
>
>>  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 :
>>
>>>  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 :
>>>
  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 :

>  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 :
>
>>  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=> 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=> 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 :
>>
>>> Rich Megginson wrote:
>>> > On 04/15/2

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-06-08 Thread thierry bordaz


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 >:


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 mailto: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
mailto: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
mailto: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
mailto: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=
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=
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-06-08 Thread James James

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 :

>  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 :
>
>>  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 :
>>
>>>  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 :
>>>
  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 :

>  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= 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= 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 :
>
>> 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 > >> >:
>> >>
>> >> 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
>> >>>

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-18 Thread thierry bordaz

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 >:

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 mailto: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
mailto: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
mailto: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=
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=
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
mailto: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:
>
>>

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread James James

ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 .

Best.

James

2015-05-15 16:58 GMT+02:00 Rich Megginson :

>  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 :
>
>>  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 :
>>
>>>  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 :
>>>
  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=>>> 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=>>> 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 :

> 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  >> >:
> >>
> >> On 04/15/2015 12:43 PM, James James wrote:
> >>> Here the log
> >>>
> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson  >>> >:
> >>>
> >>> 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
> >>>

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread Rich Megginson

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 >:

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 mailto: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
mailto: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=
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=
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
mailto: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
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
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread James James

[root@ipa ~]#  rpm -q 389-ds-base
389-ds-base-1.2.11.15-50.el6_6.x86_64



2015-05-15 16:32 GMT+02:00 Rich Megginson :

>  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 :
>
>>  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 :
>>
>>>  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=>> 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=>> 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 :
>>>
 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 >>> >> >:
 >>
 >> On 04/15/2015 12:43 PM, James James wrote:
 >>> Here the log
 >>>
 >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >>> >>> >:
 >>>
 >>> 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".

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread Rich Megginson

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 >:

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 mailto: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=
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=
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
mailto: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
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
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 ye

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread James James

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

2015-05-15 16:00 GMT+02:00 Rich Megginson :

>  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 :
>
>>  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=> 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=> 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 :
>>
>>> 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 >> >> >:
>>> >>
>>> >> On 04/15/2015 12:43 PM, James James wrote:
>>> >>> Here the log
>>> >>>
>>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >> >>> >:
>>> >>>
>>> >>> 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.l

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread Rich Megginson

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 >:

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=
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=
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 mailto: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
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
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-05-15 Thread James James

Is it possible to change the nsds5ReplicaTimeout value to get rid of this
timeout error ?

2015-04-17 4:52 GMT+02:00 Rich Megginson :

>  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= 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= 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 :
>
>> 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 > >> >:
>> >>
>> >> On 04/15/2015 12:43 PM, James James wrote:
>> >>> Here the log
>> >>>
>> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson > >>> >:
>> >>>
>> >>> 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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-16 Thread Rich Megginson

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=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=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 >:

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 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
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread James James

The ipareplica-install.log file in attachment ...

2015-04-16 2:22 GMT+02:00 Rob Crittenden :

> 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  >> >:
> >>
> >> On 04/15/2015 12:43 PM, James James wrote:
> >>> Here the log
> >>>
> >>> 2015-04-15 18:58 GMT+02:00 Rich Megginson  >>> >:
> >>>
> >>> 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
>
>
2015-04-15T15:06:11Z DEBUG /usr/sbin/ipa-replica-install was invoked with argument "/var/lib/ipa/replica-info-ipa1.example.com.gpg" and options: {'no_forwarders': False, 'conf_ssh': True, 'skip_schema_check': False, 'ui_redirect': True, 'trust_sshfp': False, 'unattended': False, 'ip_addresses': [], 'no_host_dns': False, 'mkhomedir': False, 'no_reverse': False, 'setup_dns': False, 'create_sshfp': True, 'conf_sshd': True, 'forwarders': None, 'debug': False, 'conf_ntp': True, 'setup_ca': False, 'skip_conncheck': False, 'reverse_zones': []}
2015-04-15T15:06:11Z DEBUG IPA version 4.1.0-18.el7.centos.3
2015-04-15T15:06:11Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-04-15T15:06:11Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2015-04-15T15:06:11Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
2015-04-15T15:06:11Z DEBUG Starting external process
2015-04-15T15:06:11Z DEBUG args='/usr/sbin/httpd' '-t' '-D' 'DUMP_VHOSTS'
2015-04-15T15:06:11Z DEBUG Process finished, return code=0
2015-04-15T15:06:11Z DEBUG stdout=VirtualHost configuration:
*:8443 is a NameVirtualHost
 default server ipa1.example.com (/etc/httpd/conf.d/nss.conf:86)
 port 8443 namevhost ipa1.example.com (/etc/httpd/conf.d/nss.conf:86)
 port 8443 namevhost ipa1.example.com (/etc/httpd/conf.d/nss.conf:86)

2015-04-15T15:06:11Z DEBUG stderr=
2015-04-15T15:06:11Z DEBUG Starting external process
2015-04-15T15:06:11Z DEBUG args='/bin/systemctl' 'is-enabled' 'chronyd.service'
2015-04-15T15:06:11Z DEBUG Process finished, return code=1
2015-04-15T15:06:11Z DEBUG stdout=
2015-04-15T15:06:11Z DEBUG stderr=Failed to issue method call: No such file or directory

2015-04-15T15:06:11Z DEBUG Starting external process
2015-04-15T15:06:11Z DEBUG args='/bin/systemctl' 'is-active' 'chronyd.service'
2015-04-15T15:06:11Z DEBUG Process finished, return code=3
2015-04-15T15:06:11Z DEBUG stdout=unknown

2015-04-15T15:06:11Z DEBUG stderr=
2015-04-15T15:06:15Z DEBUG Starting external process
2015-04-15T15:06:15Z DEBUG args='/usr/bin/gpg-agent' '--batch' '--homedir' '/tmp/tmpxNp5r9ipa/ipa-8fobNZ/.gnupg' '--daemon' '/usr/bin/gpg' '--batch' '--homedir' '/tmp/tmpxNp5r9ipa/ipa-8fobNZ/.gnupg' '--passphrase-fd' '0' '--yes' '--no-tty' '-o' '/tmp/tmpxNp5r9ipa/files.tar' '-d' '/var/lib/ipa/replica-info-ipa1.example.com.gpg'
2015-04-15T15:06:15Z DEBUG Process fin

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread Rob Crittenden

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 > >:
>>
>> On 04/15/2015 12:43 PM, James James wrote:
>>> Here the log
>>>
>>> 2015-04-15 18:58 GMT+02:00 Rich Megginson >> >:
>>>
>>> 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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread Rich Megginson


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 >:


On 04/15/2015 12:43 PM, James James wrote:

Here the log

2015-04-15 18:58 GMT+02:00 Rich Megginson 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?



[ipa.example.com ] reports: Update
failed! Status: [10 Total update abortedLDAP error: Referral]

  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin -
CleanAllRUV Task: Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com "
(ipa1:389): Replica has a different generation ID than the
local data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin -
Beginning total update of replica
"agmt="cn=meToipa1.example.com
" (ipa1:389)".


What is happening on the consumer (ipa1.example.com
) error and access log at this time?



[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr
is going offline; disabling replication
[15/Apr/2015:17:06:33 +0200] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to
access the database
[15/Apr/2015:17:06:53 +0200] - import userRoot: Processed 1399
entries -- average rate 70.0/sec, recent rate 69.9/sec, hit ratio 0%
...
[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

So it would appear that initialization finished successfully.  But
then . . .




[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com "
(ipa1:389): Unable to receive the response for a
startReplication extended operation to consumer (Can't
contact LDAP server). Will retry later.




[15/Apr/2015:17:41:16 +0200] - slapd shutting down - freed 1 work
q stack objects - freed 2 op stack objects
[15/Apr/2015:17:41:16 +0200] - slapd stopped.

So the server is down.  Did someone or some process shutdown the
replica at this time?


[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could
not send startTLS request: error -1 (Can't contact LDAP
server) errno 107 (Transport endpoint is not connected)

Any hints will be useful.

Thanks.






--
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







-- 
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread James James

Nothing on the replica .. maybye a process on the master. How can I check
that ?

2015-04-15 21:37 GMT+02:00 Rich Megginson :

>  On 04/15/2015 12:43 PM, James James wrote:
>
> Here the log
>
> 2015-04-15 18:58 GMT+02:00 Rich Megginson :
>
>>  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
>>
>> [ipa.example.com] reports: Update failed! Status: [10 Total update
>> abortedLDAP error: Referral]
>>
>>   [error] RuntimeError: Failed to start replication
>>
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> Failed to start replication
>>
>>
>>  On the master I have this message :
>> 15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin - CleanAllRUV Task:
>> Successfully cleaned rid(19).
>> [15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin - agmt="cn=
>> meToipa1.example.com" (ipa1:389): Replica has a different generation ID
>> than the local data.
>> [15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - Beginning total
>> update of replica "agmt="cn=meToipa1.example.com" (ipa1:389)".
>>
>>
>>  What is happening on the consumer (ipa1.example.com) error and access
>> log at this time?
>>
>
> [15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin -
> multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is going
> offline; disabling replication
> [15/Apr/2015:17:06:33 +0200] - WARNING: Import is running with
> nsslapd-db-private-import-mem on; No other process is allowed to access the
> database
> [15/Apr/2015:17:06:53 +0200] - import userRoot: Processed 1399 entries --
> average rate 70.0/sec, recent rate 69.9/sec, hit ratio 0%
> ...
> [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
>
> So it would appear that initialization finished successfully.  But then .
> . .
>
>
>>  [15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin - agmt="cn=
>> meToipa1.example.com" (ipa1:389): Unable to receive the response for a
>> startReplication extended operation to consumer (Can't contact LDAP
>> server). Will retry later.
>>
>>
> [15/Apr/2015:17:41:16 +0200] - slapd shutting down - freed 1 work q stack
> objects - freed 2 op stack objects
> [15/Apr/2015:17:41:16 +0200] - slapd stopped.
>
> So the server is down.  Did someone or some process shutdown the replica
> at this time?
>
> [15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could not send
>> startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport
>> endpoint is not connected)
>>
>> Any hints will be useful.
>>
>>  Thanks.
>>
>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
-- 
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread Rich Megginson


On 04/15/2015 12:43 PM, James James wrote:

Here the log

2015-04-15 18:58 GMT+02:00 Rich Megginson >:


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

[ipa.example.com ] reports: Update
failed! Status: [10 Total update abortedLDAP error: Referral]

  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin - CleanAllRUV
Task: Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com "
(ipa1:389): Replica has a different generation ID than the local
data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - Beginning
total update of replica "agmt="cn=meToipa1.example.com
" (ipa1:389)".


What is happening on the consumer (ipa1.example.com
) error and access log at this time?



[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is 
going offline; disabling replication
[15/Apr/2015:17:06:33 +0200] - WARNING: Import is running with 
nsslapd-db-private-import-mem on; No other process is allowed to access 
the database
[15/Apr/2015:17:06:53 +0200] - import userRoot: Processed 1399 entries 
-- average rate 70.0/sec, recent rate 69.9/sec, hit ratio 0%

...
[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


So it would appear that initialization finished successfully.  But then 
. . .





[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com "
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Can't contact LDAP server). Will
retry later.




[15/Apr/2015:17:41:16 +0200] - slapd shutting down - freed 1 work q 
stack objects - freed 2 op stack objects

[15/Apr/2015:17:41:16 +0200] - slapd stopped.

So the server is down.  Did someone or some process shutdown the replica 
at this time?



[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could not
send startTLS request: error -1 (Can't contact LDAP server) errno
107 (Transport endpoint is not connected)

Any hints will be useful.

Thanks.






--
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




-- 
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

2015-04-15 Thread Rich Megginson


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

[ipa.example.com ] reports: Update failed! 
Status: [10 Total update abortedLDAP error: Referral]


  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin - CleanAllRUV Task: 
Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa1.example.com " 
(ipa1:389): Replica has a different generation ID than the local data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - Beginning total 
update of replica "agmt="cn=meToipa1.example.com 
" (ipa1:389)".


What is happening on the consumer (ipa1.example.com) error and access 
log at this time?


[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa1.example.com " 
(ipa1:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.
[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could not send 
startTLS request: error -1 (Can't contact LDAP server) errno 107 
(Transport endpoint is not connected)


Any hints will be useful.

Thanks.





-- 
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

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

20 matches

Site Navigation

Mail list logo

Footer information