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 <tbor...@redhat.com>: > 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 <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