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 <mailto: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
    <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
        <rmegg...@redhat.com <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
            <rmegg...@redhat.com <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
                <rmegg...@redhat.com <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
                    <rmegg...@redhat.com
                    <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=<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
                        <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 <rmegg...@redhat.com
                            <mailto:rmegg...@redhat.com>
                            >> <mailto: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>
                            >>>    <mailto:rmegg...@redhat.com
                            <mailto:rmegg...@redhat.com>>>:
                            >>>
                            >>>        On 04/15/2015 09:46 AM,
                            James James wrote:
                            >>>>        Hello,
                            >>>>
                            >>>>        I have been looking to
                            solve my problem but I 'm asking for
                            >>>>        some help.
                            >>>>
                            >>>>        The replication begins
                            but cannot be completed ....
                            >>>>
                            >>>>        I want to install a new
                            fresh replica but I've always got
                            >>>>        this error :
                            >>>>
                            >>>>  [21/35]: configure dirsrv ccache
                            >>>>  [22/35]: enable SASL mapping
                            fallback
                            >>>>  [23/35]: restarting directory
                            server
                            >>>>  [24/35]: setting up initial
                            replication
                            >>>>  Starting replication, please
                            wait until this has completed.
                            >>>>        Update in progress, 127
                            seconds elapsed
                            >>>>        Update in progress yet
                            not in progress
                            >>>>
                            >>>>        Update in progress yet
                            not in progress
                            >>>
                            >
                            > in progress yet not in
                            progress???? The error log below
                            clearly shows
                            > that replica init succeeded after
                            127 seconds.
                            >
                            > IPA-ers - wasn't there some bug
                            about checking replica status properly?
                            >

                            The loop looks at
                            nsds5BeginReplicaRefresh,
                            nsds5replicaUpdateInProgress
                            and nsds5ReplicaLastInitStatus.

                            It loops looking for
                            nsds5BeginReplicaRefresh. If there
                            is no value it
                            prints "Update in progress, %d
                            seconds elapsed". Once it gets a status,
                            the update is done, and it looks at
                            nsds5ReplicaLastInitStatus. If it
                            isn't empty, doesn't include
                            'replica busy' or 'Total update
                            succeeded'
                            then it looks to see if
                            nsds5replicaUpdateInProgress is
                            TRUE. If it is,
                            ir prints Update in progress yet not
                            in progress and tries the loop again.

                            AFAICT this part of a replica
                            install doesn't restart 389-ds.

                            /var/log/ipareplica-install.log may
                            hold some details.

                            rob

















-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to