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