On 02/09/2011 03:38 AM, Juan Carlos Camargo Carrillo wrote: > No prob, I had a backup at hand. > I've updated the product with the latest alfpha release and the > problem persists. Also tried with 1.2.7 on Centos5. And to add more, > I've noticed that everytime I delete a windows sync agreement, the > nslapd service woes. This should have been fixed in 1.2.7.5. If you can verify that you can reproduce this problem with 1.2.7.5, please let us know and we will reopen that bug (and fix it). > > El mar, 08-02-2011 a las 14:27 +0100, Carsten Grzemba escribi?: >> Sorry, than I'am wrong! Then there is another problem and do not change in dse.ldif! >> >> Regards, >> Carsten >> >> ----- Urspr?ngliche Nachricht ----- >> Von: Juan Carlos Camargo Carrillo<juancar at eprinsa.es <mailto:juancar at eprinsa.es>> >> Datum: Dienstag, 8. Februar 2011, 14:08 >> Betreff: Re: 1.2.8 Windows sync agreement initialization >> An: "General discussion list for the 389 Directory server project."<389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>> >> >> > >> > >> > >> > >> > >> > >> > >> >> > Hi, >> > >> > >> > >> > I'm not using any particular winsync plugin different that the one that comes with the product. The error message begins with: "NSMMReplicationPlugin - agmt="cn=windowsagreement (myserver:389): Replica has no update vector. It has never been initialized". >> > >> > According to this I presume I'm using the NSMMReplicationPlugin but I cant find it in the dse.ldif file. Also I've searched for the line "nsslapd-plugin-depends-on-name" and found it on the Legacy Replication Plugin DN. To give a try, I've removed it from there and still the problem continues to appear. >> > >> > >> > >> > Thanks! >> > >> > >> > >> > >> > >> > El mar, 08-02-2011 a las 13:28 +0100, Carsten Grzemba escribi?: >> > >> > >> >> > These modifications can you make in the /etc/dirserv/slap-<instance>/ds.ldif. The ns-slapd process has to be stopped! >> > >> > Which winsync plugin you are use? >> > >> > >> > >> > In the dse.ldif look for the entry like that: >> > >> > dn: cn=test-winsync,cn=plugins,cn=config >> > >> > >> > >> > there remove >> > > > nsslapd-plugin-depends-on-named: Multimaster Replication Plugin >> > >> > if exists. >> > >> > >> > >> > and look for the entry: >> > >> > dn: cn=Multimaster Replication Plugin,cn=plugins,cn=config >> > >> > >> > >> > there add: >> > > > nsslapd-plugin-depends-on-named: test Winsync AP >> > >> > and start the ns-slapd process. >> > >> > >> > >> > If you enable 'Replication' and 'Plug-ins' for the error logfile, you can see if the winsync API functions are called. >> > >> > These are at least every 5 min (winsyncinterval): >> > >> > >> > >> > [08/Feb/2011:11:16:57 +0100] test-winsync - --> test_winsync_begin_update_cb -- begin >> > >> > [08/Feb/2011:11:16:57 +0100] test-winsync -<-- test_winsync_begin_update_cb -- end >> > >> > [08/Feb/2011:11:16:57 +0100] test-winsync - --> test_winsync_end_update_cb -- begin >> > >> > [08/Feb/2011:11:16:57 +0100] test-winsync -<-- test_winsync_end_update_cb -- end >> > >> > even if there are no changes. >> > >> > >> > >> > Regards >> > >> > Carsten >> > >> > >> > >> > ----- Urspr?ngliche Nachricht ----- >> > >> > Von: Juan Carlos Camargo Carrillo<juancar at eprinsa.es <mailto:juancar at eprinsa.es>> >> > >> > Datum: Dienstag, 8. Februar 2011, 12:56 >> > >> > Betreff: Re: 1.2.8 Windows sync agreement initialization >> > >> > An: "General discussion list for the 389 Directory server project."<389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>> >> > >> > >> > >> > > >> > >> > > >> > >> > >> > >> > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> > >> > >> > > Hi Carten, >> > >> > > >> > >> > > >> > >> > > >> > >> > > Thanks for your answer. In my case there's not a testing plugin but the one that governs the win synchronization. As I am a sort of deep newbie can you tell me where should I made those modifications in an out-of-the box configuration, so I can retry your guidelines? >> > >> > > >> > >> > > >> > >> > > >> > >> > > Regards! >> > >> > > >> > >> > > >> > >> > > >> > >> > > El mar, 08-02-2011 a las 12:17 +0100, Carsten Grzemba escribi?: >> > >> > > >> > >> > >> > >> > >> > >> > >> > > >> > > >> > > No, it is not a normaly behaviour. >> > > >> > > I had a similar problem because my winsync plugin was not registered after a restart. I have fixed the problem that I have changed the plugin dependencies. But I do not know if it is the right way. >> > > >> > > see thread "[389-devel] Problem using winsync API" in December 2010: >> > > >> > > ... >> > > I have removed from win sync plugin: >> > > >> > > nsslapd-plugin-depends-on-named: Multimaster Replication Plugin >> > > >> > > from the plugin configuration, and instead added on the Multimaster Plugin config >> > > >> > > nsslapd-plugin-depends-on-named: test Winsync API >> > > ... >> > > >> > > Regards >> > > Carsten >> > > >> > > ----- Urspr?ngliche Nachricht ----- >> > > Von: Juan Carlos Camargo Carrillo<juancar at eprinsa.es <mailto:juancar at eprinsa.es>> >> > > Datum: Dienstag, 8. Februar 2011, 11:49 >> > > Betreff: 1.2.8 Windows sync agreement initialization >> > > An:389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > > >> > > > Hi, >> > > > >> > > > I'm running 389-ds version 1.2.8 on CentOS 5x and configured a windows sync agreement against a 2003 active directory server. Everything works as expected. However, everytime I restart the directory server (service dirsrv restart) I need to reinitialize the windows agreement. Messages such as "Replica has no update vector. It has never been initialized" continously filling the error log until I proceed with the init. But the replica was initialized and conversations between 389 and AD were working nicely. And what I would not want at all is to lose any changes made on either side as a result of the initialization process. My question then, is this the normal behaviour ? >> > > > >> > > > Thanks! >> > > > > -- >> > > > 389 users mailing list >> > > > 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > > > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > -- >> > > 389 users mailing list >> > > 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > >> > >> > >> > >> > > >> > >> > >> > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > > -- >> > >> > > 389 users mailing list >> > >> > > 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > >> > > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > -- >> > 389 users mailing list >> > 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > https://admin.fedoraproject.org/mailman/listinfo/389-users >> > >> > >> > >> > >> > >> > >> > > -- >> > 389 users mailing list >> > 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> > https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org> >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110209/26fd4454/attachment-0001.html
