Hi,

you did send the data directly to me, maybe not wanting to share them to everyone. I'll continue discussion here, trying to be careful.

The "good" entry was created in April on replica 12 "0x0c"
createTimestamp;vucsn-5524d42b0067000c0000: 20150408070720Z

the "nsuniqueid" entry was created today on replica 26 "0x1a"
createTimestamp;vucsn-5580f3210000001a0000: 20150617040801Z

if the original entry would have existed on replica26 the new add should have been rejected, if it was not there the question is why.

Do you have any additional info on replica 26, when was it created, was it disconnected for some time ??

Ludwig

On 06/17/2015 08:13 AM, Alexander Frolushkin wrote:

Hello.

Anotherexample. Today appeared on servers of different site.

Original LDIF:

# extended LDIF

#

# LDAPv3

# base <cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# System: Manage Host Keytab, permissions, pbac, unix.megafon.ru

dn: cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc

=ru

ipaPermTargetFilter: (objectclass=ipahost)

ipaPermRight: write

ipaPermBindRuleType: permission

ipaPermissionType: V2

ipaPermissionType: MANAGED

ipaPermissionType: SYSTEM

cn: System: Manage Host Keytab

objectClass: ipapermission

objectClass: top

objectClass: groupofnames

objectClass: ipapermissionv2

member: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru

member: cn=Host Administrators,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru

ipaPermDefaultAttr: krbprincipalkey

ipaPermDefaultAttr: krblastpwdchange

ipaPermLocation: cn=computers,cn=accounts,dc=unix,dc=megafon,dc=ru

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

Duplicate:

# extended LDIF

#

# LDAPv3

# base <cn=System: Manage Host Keytab+nsuniqueid=708bba65-14a611e5-8a48fd19-df27ff01,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# System: Manage Host Keytab + 708bba65-14a611e5-8a48fd19-df27ff01, permissio

ns, pbac, unix.megafon.ru

dn: cn=System: Manage Host Keytab+nsuniqueid=708bba65-14a611e5-8a48fd19-df27ff

01,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru

ipaPermTargetFilter: (objectclass=ipahost)

ipaPermRight: write

ipaPermBindRuleType: permission

ipaPermissionType: V2

ipaPermissionType: MANAGED

ipaPermissionType: SYSTEM

cn: System: Manage Host Keytab

objectClass: ipapermission

objectClass: top

objectClass: groupofnames

objectClass: ipapermissionv2

member: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru

member: cn=Host Administrators,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru

ipaPermDefaultAttr: krbprincipalkey

ipaPermDefaultAttr: krblastpwdchange

ipaPermLocation: cn=computers,cn=accounts,dc=unix,dc=megafon,dc=ru

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

No other servers in IPA domain have such duplicates.

WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764

*From:*freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Ludwig Krispenz
*Sent:* Tuesday, June 16, 2015 3:52 PM
*To:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] replication conflicts

On 06/16/2015 11:42 AM, Alexander Frolushkin wrote:

    Hello.

    Just to remind if somebody still not familiar with our IPA
    installation J

    We currently have 18 IPA servers in domain, on 8 sites in
    different regions across the Russia.

    And now, our new problem.

    Regularly we getting a nsds5ReplConflict records on some of our
    servers, very often on servers from specific site. Usually it is
    simply a doubles and we can remove the renamed change to get
    everything back. But why do we have them at all?

    May be someone could explain, how we can detect the cause of this
    replication conflicts?

if you are talking about having two "duplicate" entries,
one: uid=xxxxx,<suffix>
one: nsuniqueid=nnnnnnnn+uid=xxxxx,<suffix>

these entries appear if the entry uid=xxxxx was added, simultaneously, on two servers. I think this can happen if a client tries to add an entry and if it doesn't get a response in some time retries on another server. to find out which client this is you need to check on which servers the entries were originally added and then see which client was doing it

Sometime it is moderately harmful, because, for example HBAC stops working on specific server while doubles still present.

Thanks in forward...

WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764

------------------------------------------------------------------------


Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof.

(c)20mf50



------------------------------------------------------------------------

Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
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