Hi Chris, Thanks for your round about way. As you suggested we have removed everything, along with that we have reinstalled the latest version in two machines, and kept one machine as is (in total we have 3 machines). Now, we configured these two servers in multi-master mode and initialized one of them from the old machine. Then all the data got pushed into the new servers. These two new machines are replicating properly. but the replication agreement between the old server and new server is breaking. But we used the console interface to push the delta of updates. But the process is very slow, may be because we haven''t done db2ldif to dump the data. We are planning to push delta of updates from old server to 2 new servers (using the console interface) and remove the old server from the system. Then these two servers will become primary point of live interaction for read and write. Since, we can''t afford for downtime, we have done like this. Till now the replication is happening fine. hope this continues. Thank you very much for your help. Regards, -Debu,vivek On Fri, 20 Jun 2008 Chris St.Pierre wrote :>Did you try the workaround in the bug report I sent to you on the >Redhat list? What were your results? > >For reference, that bug is https://bugzilla.redhat.com/show_bug.cgi?id=233642 > >Chris St. Pierre >Unix Systems Administrator >Nebraska Wesleyan University > >On Fri, 20 Jun 2008, debu wrote: > >> >> >>Hi Guys, >> >>I am stuck in a very crucial FDS server issue, it would be great if any one of you can help me somehow. >> >>We are upgrading from Fedora Directory Service from 1.0.4 to 1.1.0-3 >> >>We have one existing Server with 1.0.4 >> >>Now To one server we have initialized the data base and we were able to load the full DB. But, and when we start the replication we see the following error, and the incremental update is not happening. >> >>We are going for a multi master replication. >> >> >>Here is the error. >> >>On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES release 4 (Nahant) >> >> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - agmt="cn=Replication_to_10.91.X.Y" (10:8888): Unable to acquire replica: Excessive clock skew between the supplier and the consumer. Replication is aborting. >> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - agmt="cn=Replication_to_10.91.X.Y" (10:8888): Incremental update failed and requires administrator action >> >> >> >>On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux Server release 5.1 (Tikanga) >> >> >> >>[17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 op=1975 replica="o=TejaUsers": Unable to acquire replica: error: excessive clock skew >> >>[17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment limit exceeded; value - 86401, limit - 86400 >> >>[17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 op=792 replica="o=TejaUsers": Unable to acquire replica: error: excessive clock skew >> >> >>Now, My doubt is we succeded in a test environment with the same, with the only diference that we had the same OS in both the server, rest all same. Our servers are perfectly synced with NTP also. >> >>Please help in this scenario.. >> >>Regards >>~Debajit
debu wrote:> > Hi Chris, > > Thanks for your round about way. > As you suggested we have removed everything, along with that we have > reinstalled the latest version in two machines, and kept one machine > as is (in total we have 3 machines). > > Now, we configured these two servers in multi-master mode and > initialized one of them from the old machine. Then all the data got > pushed into the new servers. These two new machines are replicating > properly. > > but the replication agreement between the old server and new server is > breaking. But we used the console interface to push the delta of > updates. But the process is very slow, may be because we haven''t done > db2ldif to dump the data. > > We are planning to push delta of updates from old server to 2 new > servers (using the console interface) and remove the old server from > the system. > > Then these two servers will become primary point of live interaction > for read and write. > > Since, we can''t afford for downtime, we have done like this. > > Till now the replication is happening fine. > > hope this continues. > > Thank you very much for your help. >We are working on a fix for the time skew issue. However, we need your help. The bug https://bugzilla.redhat.com/show_bug.cgi?id=233642 has attached to it a script which will provide us with some much needed data. You basically run this on your masters like this: readNsState.py /etc/dirsrv/slapd-yourinstance/dse.ldif The data that it prints out is very useful for help with debugging this problem. You can either attach the output to the bug, or just email the output to me. Anyone else interested in helping? Anyone have MMR running? Please run the script and either attach the output to the bug or just send it to me.> > > Regards, > -Debu,vivek > > > On Fri, 20 Jun 2008 Chris St.Pierre wrote : > >Did you try the workaround in the bug report I sent to you on the > >Redhat list? What were your results? > > > >For reference, that bug is > https://bugzilla.redhat.com/show_bug.cgi?id=233642 > > > >Chris St. Pierre > >Unix Systems Administrator > >Nebraska Wesleyan University > > > >On Fri, 20 Jun 2008, debu wrote: > > > >> > >> > >>Hi Guys, > >> > >>I am stuck in a very crucial FDS server issue, it would be great if > any one of you can help me somehow. > >> > >>We are upgrading from Fedora Directory Service from 1.0.4 to 1.1.0-3 > >> > >>We have one existing Server with 1.0.4 > >> > >>Now To one server we have initialized the data base and we were able > to load the full DB. But, and when we start the replication we see the > following error, and the incremental update is not happening. > >> > >>We are going for a multi master replication. > >> > >> > >>Here is the error. > >> > >>On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES > release 4 (Nahant) > >> > >> > >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - > agmt="cn=Replication_to_10.91.X.Y" (10:8888): Unable to acquire > replica: Excessive clock skew between the supplier and the consumer. > Replication is aborting. > >> > >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - > agmt="cn=Replication_to_10.91.X.Y" (10:8888): Incremental update > failed and requires administrator action > >> > >> > >> > >>On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux > Server release 5.1 (Tikanga) > >> > >> > >> > >>[17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 > op=1975 replica="o=TejaUsers": Unable to acquire replica: error: > excessive clock skew > >> > >>[17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment > limit exceeded; value - 86401, limit - 86400 > >> > >>[17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 > op=792 replica="o=TejaUsers": Unable to acquire replica: error: > excessive clock skew > >> > >> > >>Now, My doubt is we succeded in a test environment with the same, > with the only diference that we had the same OS in both the server, > rest all same. Our servers are perfectly synced with NTP also. > >> > >>Please help in this scenario.. > >> > >>Regards > >>~Debajit > > > > Sharekhan Zero > > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
We have a downtime scheduled for our production FDS instance (used for our campus authentication service) this Friday, in order to reestablish MMR. After reestablishing MMR we will be monitoring with the script, so we should be able to provide some data shortly. Thanks, --Gary -- Gary Windham Senior Enterprise Systems Architect The University of Arizona, UITS +1 520 626 5981 On Jun 23, 2008, at 8:11 AM, Rich Megginson wrote:> debu wrote: >> >> Hi Chris, >> >> Thanks for your round about way. >> As you suggested we have removed everything, along with that we >> have reinstalled the latest version in two machines, and kept one >> machine as is (in total we have 3 machines). >> >> Now, we configured these two servers in multi-master mode and >> initialized one of them from the old machine. Then all the data got >> pushed into the new servers. These two new machines are replicating >> properly. >> >> but the replication agreement between the old server and new server >> is breaking. But we used the console interface to push the delta of >> updates. But the process is very slow, may be because we haven''t >> done db2ldif to dump the data. >> >> We are planning to push delta of updates from old server to 2 new >> servers (using the console interface) and remove the old server >> from the system. >> >> Then these two servers will become primary point of live >> interaction for read and write. >> Since, we can''t afford for downtime, we have done like this. >> >> Till now the replication is happening fine. >> >> hope this continues. >> >> Thank you very much for your help. >> > We are working on a fix for the time skew issue. However, we need > your help. The bug https://bugzilla.redhat.com/show_bug.cgi? > id=233642 has attached to it a script which will provide us with > some much needed data. You basically run this on your masters like > this: > readNsState.py /etc/dirsrv/slapd-yourinstance/dse.ldif > The data that it prints out is very useful for help with debugging > this problem. You can either attach the output to the bug, or just > email the output to me. > > Anyone else interested in helping? Anyone have MMR running? Please > run the script and either attach the output to the bug or just send > it to me. >> >> >> Regards, >> -Debu,vivek >> >> >> On Fri, 20 Jun 2008 Chris St.Pierre wrote : >> >Did you try the workaround in the bug report I sent to you on the >> >Redhat list? What were your results? >> > >> >For reference, that bug is https://bugzilla.redhat.com/show_bug.cgi?id=233642 >> > >> >Chris St. Pierre >> >Unix Systems Administrator >> >Nebraska Wesleyan University >> > >> >On Fri, 20 Jun 2008, debu wrote: >> > >> >> >> >> >> >>Hi Guys, >> >> >> >>I am stuck in a very crucial FDS server issue, it would be great >> if any one of you can help me somehow. >> >> >> >>We are upgrading from Fedora Directory Service from 1.0.4 to >> 1.1.0-3 >> >> >> >>We have one existing Server with 1.0.4 >> >> >> >>Now To one server we have initialized the data base and we were >> able to load the full DB. But, and when we start the replication we >> see the following error, and the incremental update is not happening. >> >> >> >>We are going for a multi master replication. >> >> >> >> >> >>Here is the error. >> >> >> >>On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES >> release 4 (Nahant) >> >> >> >> >> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Unable to acquire >> replica: Excessive clock skew between the supplier and the >> consumer. Replication is aborting. >> >> >> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Incremental update >> failed and requires administrator action >> >> >> >> >> >> >> >>On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux >> Server release 5.1 (Tikanga) >> >> >> >> >> >> >> >>[17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 >> op=1975 replica="o=TejaUsers": Unable to acquire replica: error: >> excessive clock skew >> >> >> >>[17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment >> limit exceeded; value - 86401, limit - 86400 >> >> >> >>[17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 >> op=792 replica="o=TejaUsers": Unable to acquire replica: error: >> excessive clock skew >> >> >> >> >> >>Now, My doubt is we succeded in a test environment with the same, >> with the only diference that we had the same OS in both the server, >> rest all same. Our servers are perfectly synced with NTP also. >> >> >> >>Please help in this scenario.. >> >> >> >>Regards >> >>~Debajit >> >> >> >> Sharekhan Zero >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
Gary Windham wrote:> We have a downtime scheduled for our production FDS instance (used for > our campus authentication service) this Friday, in order to > reestablish MMR. After reestablishing MMR we will be monitoring with > the script, so we should be able to provide some data shortly.Excellent. Thanks!> > Thanks, > --Gary > > -- > Gary Windham > Senior Enterprise Systems Architect > The University of Arizona, UITS > +1 520 626 5981 > > On Jun 23, 2008, at 8:11 AM, Rich Megginson wrote: > >> debu wrote: >>> >>> Hi Chris, >>> >>> Thanks for your round about way. >>> As you suggested we have removed everything, along with that we have >>> reinstalled the latest version in two machines, and kept one machine >>> as is (in total we have 3 machines). >>> >>> Now, we configured these two servers in multi-master mode and >>> initialized one of them from the old machine. Then all the data got >>> pushed into the new servers. These two new machines are replicating >>> properly. >>> >>> but the replication agreement between the old server and new server >>> is breaking. But we used the console interface to push the delta of >>> updates. But the process is very slow, may be because we haven''t >>> done db2ldif to dump the data. >>> >>> We are planning to push delta of updates from old server to 2 new >>> servers (using the console interface) and remove the old server from >>> the system. >>> >>> Then these two servers will become primary point of live interaction >>> for read and write. >>> Since, we can''t afford for downtime, we have done like this. >>> >>> Till now the replication is happening fine. >>> >>> hope this continues. >>> >>> Thank you very much for your help. >>> >> We are working on a fix for the time skew issue. However, we need >> your help. The bug >> https://bugzilla.redhat.com/show_bug.cgi?id=233642 has attached to it >> a script which will provide us with some much needed data. You >> basically run this on your masters like this: >> readNsState.py /etc/dirsrv/slapd-yourinstance/dse.ldif >> The data that it prints out is very useful for help with debugging >> this problem. You can either attach the output to the bug, or just >> email the output to me. >> >> Anyone else interested in helping? Anyone have MMR running? Please >> run the script and either attach the output to the bug or just send >> it to me. >>> >>> >>> Regards, >>> -Debu,vivek >>> >>> >>> On Fri, 20 Jun 2008 Chris St.Pierre wrote : >>> >Did you try the workaround in the bug report I sent to you on the >>> >Redhat list? What were your results? >>> > >>> >For reference, that bug is >>> https://bugzilla.redhat.com/show_bug.cgi?id=233642 >>> > >>> >Chris St. Pierre >>> >Unix Systems Administrator >>> >Nebraska Wesleyan University >>> > >>> >On Fri, 20 Jun 2008, debu wrote: >>> > >>> >> >>> >> >>> >>Hi Guys, >>> >> >>> >>I am stuck in a very crucial FDS server issue, it would be great >>> if any one of you can help me somehow. >>> >> >>> >>We are upgrading from Fedora Directory Service from 1.0.4 to 1.1.0-3 >>> >> >>> >>We have one existing Server with 1.0.4 >>> >> >>> >>Now To one server we have initialized the data base and we were >>> able to load the full DB. But, and when we start the replication we >>> see the following error, and the incremental update is not happening. >>> >> >>> >>We are going for a multi master replication. >>> >> >>> >> >>> >>Here is the error. >>> >> >>> >>On Supplier: (FDS Version 1.0.4) OS: Red Hat Enterprise Linux ES >>> release 4 (Nahant) >>> >> >>> >> >>> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >>> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Unable to acquire >>> replica: Excessive clock skew between the supplier and the consumer. >>> Replication is aborting. >>> >> >>> >>[17/Jun/2008:11:23:35 +051800] NSMMReplicationPlugin - >>> agmt="cn=Replication_to_10.91.X.Y" (10:8888): Incremental update >>> failed and requires administrator action >>> >> >>> >> >>> >> >>> >>On consumer: (FD version 1.1.0-3) OS: Red Hat Enterprise Linux >>> Server release 5.1 (Tikanga) >>> >> >>> >> >>> >> >>> >>[17/Jun/2008:11:12:59 +051800] NSMMReplicationPlugin - conn=46251 >>> op=1975 replica="o=TejaUsers": Unable to acquire replica: error: >>> excessive clock skew >>> >> >>> >>[17/Jun/2008:11:23:34 +051800] - csngen_adjust_time: adjustment >>> limit exceeded; value - 86401, limit - 86400 >>> >> >>> >>[17/Jun/2008:11:23:34 +051800] NSMMReplicationPlugin - conn=46461 >>> op=792 replica="o=TejaUsers": Unable to acquire replica: error: >>> excessive clock skew >>> >> >>> >> >>> >>Now, My doubt is we succeded in a test environment with the same, >>> with the only diference that we had the same OS in both the server, >>> rest all same. Our servers are perfectly synced with NTP also. >>> >> >>> >>Please help in this scenario.. >>> >> >>> >>Regards >>> >>~Debajit >>> >>> >>> >>> Sharekhan Zero >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users@redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users