[389-users] Replica has no update vector.

Thu Apr 8 14:04:27 UTC 2010

Techie wrote:
> On Wed, Apr 7, 2010 at 11:12 AM, Rich Megginson <rmeggins at redhat.com> wrote:
>   
>> Techie wrote:
>>     
>>> On Wed, Apr 7, 2010 at 9:35 AM, Rich Megginson <rmeggins at redhat.com> wrote:
>>>
>>>       
>>>> Techie wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> I have Winsync agreements simply to pull accounts from AD. No pass
>>>>> sync configured, nothing pushed from Directory Server to AD, simply
>>>>> pulling account info from AD to Directory Server with no password.
>>>>>
>>>>> I did full synchronization to pull accounts from AD and it was
>>>>> successful, many accounts were populated.
>>>>> My issue is that I get this in the error log..
>>>>>
>>>>> NSMMReplicationPlugin - agmt="cn=winsync" Replica has no update vector
>>>>>
>>>>> It seems that Winsync is working but I don't know how serious this is
>>>>> or if it can be ignored. My feeling is that it must mean something
>>>>> because it is consistently logging every 4 seconds.
>>>>>
>>>>> I did some reading and RUV is described as..
>>>>> A collection of information within each replica that determines how up
>>>>> to date the replica is with respect to other replicas for that
>>>>> partition.
>>>>> I also read that...
>>>>> This information is stored on both the supplier and the consumer and
>>>>> that it determines which changes need to be replicated..And that each
>>>>> server should know more about its own replica ID than the other
>>>>> servers do.
>>>>>
>>>>> I am probably missing the obvious as I have only 1 replica..  can
>>>>> someone please help my understanding?
>>>>>
>>>>>
>>>>>           
>>>> It seems that windows sync can require several initializations before it
>>>> starts working correctly.
>>>>
>>>>         
>>> Thanks for the answer.
>>> I have a few questions that will help my understanding.
>>>
>>> 1)By initializations you mean to do a full resynchronization or just
>>> send and receive updates?
>>>
>>>       
>> Full resync
>>     
>>> 2)Once I have already done an initial full resynchronization and my
>>> accounts are populated in 389, will initiating another full
>>> resynchronization delete all account information in 389 and pull it
>>> back down, or will it just search for changes? I have attributes that
>>> I have added and dont want to lose those by doing a full
>>> resynchronization. The documentation indicates that it will not
>>> delete, just looking for confirmation.
>>>
>>>       
>> The docs are correct.
>>     
>>> 3)I have already populated 389 via winsync. Can I import these
>>> accounts onto another server and then create a Winsync agreement to AD
>>> and have that agreement search for any changes?
>>>       
>> Yes and no.  Winsync is not multi-master - you cannot have more than one
>> directory server sync'ing to more than one AD if the directory servers
>> use MMR to each other, and the AD's are replicating to each other.
>>     
> Thank you for the response..
> The plan is to export the accounts from old server, delete the Winsync
> agreements, shut off this 389 server. From there import accounts on
> the new server and create the Winsync agreements. I will have 2 389
> servers participating in a MMR setup. One of these 389 masters will
> have the Winsync agreements between itself and an AD Domain controller
> for each of 2 domains..
>
> I have multiple AD domains. So on the 389 server with the winsync
> agreements I have the userroot setup as 1 DB containing an AD domain.
> I also have a sub suffix within its own database with another AD
> domain.
>
> Do you see any issue with this? It seems to work. I have winsync
> agreements between the single Directory server and a domain controller
> for each of the 2 AD domains. The AD domains are in separate DBs as I
> mentioned.
> The layout is described below.
>
> root suffix = DC=EXAMPLE,DC=COM(within userRoot obviously)
> userRoot DB contains this
> ou=ADDOMAIN1,dc=EXAMPLE,DC=COM(Winsync agreement 1)
>
> sub suffix = ou=ADDOMAIN2,dc=EXAMPLE,DC=COM
> db1 DB contains this
> ou=ADDOMAIN2,dc=EXAMPLE,DC=COM(Winsync agreement 2)
>   
looks good
> Thanks again
> TC
>   
>>> I mean will Winsync
>>> leave my accounts intact in the 389 directory?
>>>       
>> Yes.
>>     
>>> Almost the same
>>> question as the last except I need to move these accounts to a new
>>> server eventually and want to keep all attributes and mods intact on
>>> the new server.
>>>
>>>       
>> Ok.
>>     
>>> 4)All the accounts created by winsync in 389 have the ntUser
>>> objectClass. However according to the documentation they should not
>>> attempt to sync to AD unless they have the ntUserCreateNewAccount
>>> attribute. Is this correct?
>>>
>>>       
>> If you create a new user in the DS, and in that new entry you have the
>> ntUserCreateNewAccount attribute set to true, then winsync will create
>> that user in AD.  By default, if you create a user in the DS, that user
>> is not created in AD.  If you have a user in the DS that you want to
>> create in AD, you can add the ntUser objectclass to the entry along with
>> the required attribute ntUserDomainID set to the AD samAccountName, and
>> set the ntUserCreateNewAccount to true.
>>     
>>> Thanks again
>>> TC
>>>
>>>       
>>>>> Thank you
>>>>> TC
>>>>> --
>>>>> 389 users mailing list
>>>>> 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
>>>>
>>>>
>>>>         
>>> --
>>> 389 users mailing list
>>> 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
>>
>>     
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users