Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
https://fedorahosted.org/freeipa/ticket/5575
^--- That was the one. It triggered differently for me because I had manually
re-replaced the aci in the dc=domain,dc=mapping tree branch.
Had I left it alone it would have triggered exactly as in thebug report.
However, that bug report did let me know how to fix it.
I made a brand new FreeIPA 4.3.0 domain with a single master (which has the
correct ACI entries for the mapping tree branch), then copied those ACIs into
my existing domain (edit dse.ldif when the server is turned off).
I was able to successfully install a replica after that.
Thanks for pointing out the actual bug. I'm fairly new to debugging 389 DS so
knowing what branch needed to be fixed was invaluable.
-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-26-16 12:57 PM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with
DuplicateEntry: This entry already exists
On 26.01.2016 21:51, Martin Basti wrote:
>
>
> On 26.01.2016 21:03, Nathan Peters wrote:
>> After some more investigation, it appears that there may be more ACIs
>> missing.
>>
>> I added the missing permission (System: Read Replication Agreements)
>> on all my masters, and then the installation failed at this point :
>> ---
>> [28/43]: setting up initial replication Starting replication, please
>> wait until this has completed.
>>[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write'
>> privilege to the 'nsds5BeginReplicaRefresh' attribute of entry
>> 'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2c
>> dc\\3dnet,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient
>> access'} Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info':
>> "Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh'
>> attribute of entry
>> 'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2c
>> dc\\3dnet,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient
>> access'}
>> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
>> ipa-replica-install command failed. See
>> /var/log/ipareplica-install.log for more information
>>
>> Because of that and a comparison of my earlier version of ldif files
>> from earlier versions of FreeIPA, I noticed the following ACI also
>> missing from the mapping tree :
>> --
>> # dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
>> dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
>> aci: (targetattr=*)(version 3.0;acl "permission:Add Replication
>> Agreements";al
>> low (add) groupdn = "ldap:///cn=Add Replication
>> Agreements,cn=permissions,cn=
>> pbac,dc=mydomain,dc=net";)
>> aci:
>> (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass
>> =nsd
>> s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
>> ass=nsMappingTree))")(version 3.0; acl "permission:Modify
>> Replication Agreeme
>> nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify
>> Replication Ag
>> reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)
>>
>> After I added that, I attempted my replica installation again this
>> time it failed on the o=ipaca branch
>>
>> Configuring certificate server (pki-tomcatd). Estimated time: 3
>> minutes 30 seconds
>>[1/23]: creating certificate server user
>>[2/23]: creating certificate server db
>>[3/23]: setting up initial replication
>>[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write'
>> privilege to the 'nsDS5ReplicaBindDN' attribute of entry
>> 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc':
>> 'Insufficient access'}
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info':
>> "Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute
>> of entry 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n",
>> 'desc': 'Insufficient access'
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 26.01.2016 21:51, Martin Basti wrote:
On 26.01.2016 21:03, Nathan Peters wrote:
After some more investigation, it appears that there may be more ACIs
missing.
I added the missing permission (System: Read Replication Agreements)
on all my masters, and then the installation failed at this point :
---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write'
privilege to the 'nsds5BeginReplicaRefresh' attribute of entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info':
"Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh'
attribute of entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
Because of that and a comparison of my earlier version of ldif files
from earlier versions of FreeIPA, I noticed the following ACI also
missing from the mapping tree :
--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication
Agreements";al
low (add) groupdn = "ldap:///cn=Add Replication
Agreements,cn=permissions,cn=
pbac,dc=mydomain,dc=net";)
aci:
(targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
ass=nsMappingTree))")(version 3.0; acl "permission:Modify
Replication Agreeme
nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify
Replication Ag
reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)
After I added that, I attempted my replica installation again this
time it failed on the o=ipaca branch
Configuring certificate server (pki-tomcatd). Estimated time: 3
minutes 30 seconds
[1/23]: creating certificate server user
[2/23]: creating certificate server db
[3/23]: setting up initial replication
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write'
privilege to the 'nsDS5ReplicaBindDN' attribute of entry
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc':
'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info':
"Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute
of entry 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n",
'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
Looking at that branch of the ldap tree, I noticed some differences
---
In the cn=yourdomain,cn=mapping tree,cn=config you will find the
following permissions :
permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the
following permissions :
cert manager: Add Replication Agreements
=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
branch
3. acis are on the o=ipaca branch, but they are wrong as they only
apply to cert manager, and not all users
I'm not sure if this covers your issues, but it may be related
https://fedorahosted.org/freeipa/ticket/5412
Martin
and this https://fedorahosted.org/freeipa/ticket/5575
-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails
with DuplicateEntry: This entry already exists
Thank you,
I found root cause why "System: Read Replication Agreements" ACI is
not on replica.
https://fedorahosted.org/freeipa/ticket/5631
I have to figure out why this permission is added on centos7.2,
because IMO this bug is there fr
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 26.01.2016 21:03, Nathan Peters wrote:
After some more investigation, it appears that there may be more ACIs missing.
I added the missing permission (System: Read Replication Agreements) on all my
masters, and then the installation failed at this point :
---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the
'nsds5BeginReplicaRefresh' attribute of entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': "Insufficient
'write' privilege to the 'nsds5BeginReplicaRefresh' attribute of entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log for
more information
Because of that and a comparison of my earlier version of ldif files from
earlier versions of FreeIPA, I noticed the following ACI also missing from the
mapping tree :
--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al
low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=
pbac,dc=mydomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme
nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag
reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)
After I added that, I attempted my replica installation again this time it
failed on the o=ipaca branch
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
[1/23]: creating certificate server user
[2/23]: creating certificate server db
[3/23]: setting up initial replication
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the
'nsDS5ReplicaBindDN' attribute of entry 'cn=replica,cn=o\\3dipaca,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': "Insufficient
'write' privilege to the 'nsDS5ReplicaBindDN' attribute of entry
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient
access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log for
more information
Looking at that branch of the ldap tree, I noticed some differences
---
In the cn=yourdomain,cn=mapping tree,cn=config you will find the following
permissions :
permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the following
permissions :
cert manager: Add Replication Agreements
=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config branch
3. acis are on the o=ipaca branch, but they are wrong as they only apply to
cert manager, and not all users
I'm not sure if this covers your issues, but it may be related
https://fedorahosted.org/freeipa/ticket/5412
Martin
-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with
DuplicateEntry: This entry already exists
Thank you,
I found root cause why "System: Read Replication Agreements" ACI is not on
replica.
https://fedorahosted.org/freeipa/ticket/5631
I have to figure out why this permission is added on centos7.2, because IMO
this bug is there from 4.0.
On 24.01.2016 03:22, Nathan Peters wrote:
I can now confirm that this is a 100% reproducible bug, and a pretty
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
After some more investigation, it appears that there may be more ACIs missing.
I added the missing permission (System: Read Replication Agreements) on all my
masters, and then the installation failed at this point :
---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the
'nsds5BeginReplicaRefresh' attribute of entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info':
"Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh' attribute of
entry
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log for
more information
Because of that and a comparison of my earlier version of ldif files from
earlier versions of FreeIPA, I noticed the following ACI also missing from the
mapping tree :
--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al
low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=
pbac,dc=mydomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme
nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag
reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)
After I added that, I attempted my replica installation again this time it
failed on the o=ipaca branch
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
[1/23]: creating certificate server user
[2/23]: creating certificate server db
[3/23]: setting up initial replication
[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the
'nsDS5ReplicaBindDN' attribute of entry 'cn=replica,cn=o\\3dipaca,cn=mapping
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info':
"Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute of entry
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient
access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log for
more information
Looking at that branch of the ldap tree, I noticed some differences
---
In the cn=yourdomain,cn=mapping tree,cn=config you will find the following
permissions :
permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the following
permissions :
cert manager: Add Replication Agreements
=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config branch
3. acis are on the o=ipaca branch, but they are wrong as they only apply to
cert manager, and not all users
-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with
DuplicateEntry: This entry already exists
Thank you,
I found root cause why "System: Read Replication Agreements" ACI is not on
replica.
https://fedorahosted.org/freeipa/ticket/5631
I have to figure out why this permission is added on centos7.2, because IMO
this bug is there from 4.0.
On 24.01.2016 03:22, Nathan Peters wrote:
> I can now confirm that this is a 100% reproducible bug, and a pretty severe
> one at that. You should be able to reproduce this issue at will if you
> follow these steps. It may actually be possible with less servers and less
> ste
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
n=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr = "cn || createtimestamp || entryusn || modifytimestamp || ob jectclass || passsyncmanagersdns*")(target = "ldap:///cn=ipa_pwd_extop,cn=plu gins,cn=config")(version 3.0;acl "permission:Read PassSync Managers Configura tion";allow (compare,read,search) groupdn = "ldap:///cn=Read PassSync Manager s Configuration,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr = "passsyncmanagersdns*")(target = "ldap:///cn=ipa_pwd_extop, cn=plugins,cn=config")(version 3.0;acl "permission:Modify PassSync Managers C onfiguration";allow (write) groupdn = "ldap:///cn=Modify PassSync Managers Co nfiguration,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr = "cn || createtimestamp || entryusn || modifytimestamp || ns slapd-directory* || objectclass")(target = "ldap:///cn=config,cn=ldbm databas e,cn=plugins,cn=config")(version 3.0;acl "permission:Read LDBM Database Confi guration";allow (compare,read,search) groupdn = "ldap:///cn=Read LDBM Databas e Configuration,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) g roupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc= ipatestdomain,dc=net";) # SNMP, config dn: cn=SNMP,cn=config aci: (target="ldap:///cn=SNMP,cn=config";)(targetattr !="aci")(version 3.0;acl "snmp";allow (read, search, compare)(userdn = "ldap:///anyone";);) # tasks, config dn: cn=tasks,cn=config aci: (targetattr=*)(version 3.0; acl "Run tasks after replica re-initializatio n"; allow (add) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permis sions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(version 3.0; acl "cert manager: Run tasks after replica re -initialization"; allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipa ca";) aci: (targetattr="*")(version 3.0; acl "Admin can read all tasks"; allow (read , compare, search) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,dc=grip atestdomain,dc=net";) # csusers, config dn: ou=csusers,cn=config aci: (targetattr != aci)(version 3.0; aci "cert manager manage replication use rs"; allow (all) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # 1.3.6.1.4.1.4203.1.9.1.1, features, config dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea d, search ) userdn = "ldap:///all";;) # 2.16.840.1.113730.3.4.9, features, config dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config aci: (targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone";; ) # dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn= pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag reements,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "permission:Rem ove Replication Agreements";allow (delete) groupdn = "ldap:///cn=Remove Repli cation Agreements,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) # o\3Dipaca, mapping tree, config dn: cn=o\3Dipaca,cn=mapping tree,cn=config aci: (targetattr=*)(version 3.0;acl "cert manager: Add Replication Agreements" ;allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl e,o=ipaca";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager: Remove Replication Agreements";allow (delete) userdn = "ldap:///
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
"ldap:///cn=ipa_pwd_extop, cn=plugins,cn=config")(version 3.0;acl "permission:Modify PassSync Managers C onfiguration";allow (write) groupdn = "ldap:///cn=Modify PassSync Managers Co nfiguration,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr = "cn || createtimestamp || entryusn || modifytimestamp || ns slapd-directory* || objectclass")(target = "ldap:///cn=config,cn=ldbm databas e,cn=plugins,cn=config")(version 3.0;acl "permission:Read LDBM Database Confi guration";allow (compare,read,search) groupdn = "ldap:///cn=Read LDBM Databas e Configuration,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) g roupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc= ipatestdomain,dc=net";) # SNMP, config dn: cn=SNMP,cn=config aci: (target="ldap:///cn=SNMP,cn=config";)(targetattr !="aci")(version 3.0;acl "snmp";allow (read, search, compare)(userdn = "ldap:///anyone";);) # tasks, config dn: cn=tasks,cn=config aci: (targetattr=*)(version 3.0; acl "Run tasks after replica re-initializatio n"; allow (add) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permis sions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(version 3.0; acl "cert manager: Run tasks after replica re -initialization"; allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipa ca";) aci: (targetattr="*")(version 3.0; acl "Admin can read all tasks"; allow (read , compare, search) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,dc=grip atestdomain,dc=net";) # csusers, config dn: ou=csusers,cn=config aci: (targetattr != aci)(version 3.0; aci "cert manager manage replication use rs"; allow (all) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # 1.3.6.1.4.1.4203.1.9.1.1, features, config dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea d, search ) userdn = "ldap:///all";;) # 2.16.840.1.113730.3.4.9, features, config dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config aci: (targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone";; ) # dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn= pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag reements,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "permission:Rem ove Replication Agreements";allow (delete) groupdn = "ldap:///cn=Remove Repli cation Agreements,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) # o\3Dipaca, mapping tree, config dn: cn=o\3Dipaca,cn=mapping tree,cn=config aci: (targetattr=*)(version 3.0;acl "cert manager: Add Replication Agreements" ;allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl e,o=ipaca";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager: Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser ,ou=people,o=ipaca";) # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a llow (read) userdn="ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue || dnaThre shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range"; allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss ions,cn=pbac,dc=ipatestdomain,dc=net";) # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement s,cn=permissions,cn=pbac,dc=ipatestdomain,dc=net";) # search result search: 2 result: 0 Success # numResponses: 12 # numEntries: 11 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-22-16 10:24 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/22/2016 11:04 AM, Nathan Peters wrote: > Wow, strange stuff, the search I linked in the last email for our non working > dev environment seems short some entries. > > For comparison, here is the same search run against our currently working > prod environment. > > As you can see, our prod environment has a huge aci on the config tree. > > For reference, our prod and dev environments were identical (FreeIPA > 4.1.4/CentOS7.1) before I updated our dev environment to > CentOS7.2/FreeIPA4.2.0 -> Fedora23/FreeIPA4.2.3 -> Fedora23/FreeIPA4.3.0. So > at some point during this upgrade process I assume maybe one of the > installers deleted acis on our tree? That sounds like the kind of thing that > would happen when introducing the new domain level functionality in 4.3, like > if someone accidentally thought "oh this replica branch is now in a globally > replicated section, we can remove these acis for this local stuff..." and > then put that logic into the installer or something... > > The real question is, is there some good way of getting those aci's back, > like a fixaci command? I don't know. -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
"; allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss ions,cn=pbac,dc=myproddomain,dc=net";) # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement s,cn=permissions,cn=pbac,dc=myproddomain,dc=net";) # search result search: 2 result: 0 Success # numResponses: 12 # numEntries: 11 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-22-16 9:18 AM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists [root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" aci Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (aci=*) # requesting: aci # # config dn: cn=config aci: (targetattr != aci)(version 3.0; aci "cert manager read access"; allow (r ead, search, compare) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) aci: (target = "ldap:///cn=automember rebuild membership,cn=tasks,cn=config")( targetattr=*)(version 3.0;acl "permission:Add Automember Rebuild Membership T ask";allow (add) groupdn = "ldap:///cn=Add Automember Rebuild Membership Task ,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr = "cn || createtimestamp || entryusn || modifytimestamp || ob jectclass || passsyncmanagersdns*")(target = "ldap:///cn=ipa_pwd_extop,cn=plu gins,cn=config")(version 3.0;acl "permission:Read PassSync Managers Configura tion";allow (compare,read,search) groupdn = "ldap:///cn=Read PassSync Manager s Configuration,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr = "passsyncmanagersdns*")(target = "ldap:///cn=ipa_pwd_extop, cn=plugins,cn=config")(version 3.0;acl "permission:Modify PassSync Managers C onfiguration";allow (write) groupdn = "ldap:///cn=Modify PassSync Managers Co nfiguration,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr = "cn || createtimestamp || entryusn || modifytimestamp || ns slapd-directory* || objectclass")(target = "ldap:///cn=config,cn=ldbm databas e,cn=plugins,cn=config")(version 3.0;acl "permission:Read LDBM Database Confi guration";allow (compare,read,search) groupdn = "ldap:///cn=Read LDBM Databas e Configuration,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (version 3.0;acl "permission:Add Configuration Sub-Entries";allow (add) g roupdn = "ldap:///cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc= dev-mydomain,dc=net";) # mapping tree, config dn: cn=mapping tree,cn=config aci: (target = "ldap:///cn=meTo($dn),cn=*,cn=mapping tree,cn=config")(targetat tr = "objectclass || cn")(version 3.0; acl "Allow hosts to read their replica tion agreements"; allow(read, search, compare) userdn = "ldap:///fqdn=($dn),c n=computers,cn=accounts,dc=dev-mydomain,dc=net";) # SNMP, config dn: cn=SNMP,cn=config aci: (target="ldap:///cn=SNMP,cn=config";)(targetattr !="aci")(version 3.0;acl "snmp";allow (read, search, compare)(userdn = "ldap:///anyone";);) # tasks, config dn: cn=tasks,cn=config aci: (targetattr=*)(version 3.0; acl "Run tasks after replica re-initializatio n"; allow (add) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permis sions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr=*)(version 3.0; acl "cert manager: Run tasks after replica re -initialization"; allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipa ca";) aci: (targetattr="*")(version 3.0; acl "Admin can read all tasks"; allow (read , compare, search) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,dc=dev- mydomain,dc=net";) # csusers, config dn: ou=csusers,cn=config aci: (targetattr != aci)(version 3.0; aci "cert manager manage replication use rs"; allow (all) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # 1.3.6.1.4.1.4203.1.9.1.1, features, config dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea d, search ) userdn = "ldap:///all";;) # 2.16.840.1.113730.3.4.9, features, config dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config aci: (targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) us
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
g tree, config dn: cn=dc\3Ddev-mydomain\2Cdc\3Dnet,cn=mapping tree,cn=config aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "permission:Rem ove Replication Agreements";allow (delete) groupdn = "ldap:///cn=Remove Repli cation Agreements,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) # o\3Dipaca, mapping tree, config dn: cn=o\3Dipaca,cn=mapping tree,cn=config aci: (targetattr=*)(version 3.0;acl "cert manager: Add Replication Agreements" ;allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl e,o=ipaca";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager: Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser ,ou=people,o=ipaca";) # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a llow (read) userdn="ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue || dnaThre shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range"; allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss ions,cn=pbac,dc=dev-mydomain,dc=net";) # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement s,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-22-16 6:26 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 08:48 PM, Nathan Peters wrote: > Here are the results for that aci search using a non gssapi bind by directory > manager on the old master that we are attempting to join agains. I don't see > anything in this list that would indicate that some users should or should > not have access through a certain method. Unless one of those sasl config > settings is doing it ? > > [root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b > "cn=config" "(aci=*)" You almost got it. You left out the most important part, at the end of the command, specifying the "aci" attribute: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html # ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" aci -- 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 -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
ttr=*)(version 3.0;acl "cert manager: Add Replication Agreements" ;allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl e,o=ipaca";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager: Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser ,ou=people,o=ipaca";) # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a llow (read) userdn="ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue || dnaThre shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range"; allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss ions,cn=pbac,dc=dev-mydomain,dc=net";) # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement s,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-22-16 6:26 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 08:48 PM, Nathan Peters wrote: Here are the results for that aci search using a non gssapi bind by directory manager on the old master that we are attempting to join agains. I don't see anything in this list that would indicate that some users should or should not have access through a certain method. Unless one of those sasl config settings is doing it ? [root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" You almost got it. You left out the most important part, at the end of the command, specifying the "aci" attribute: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html # ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" aci -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl e,o=ipaca";) aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager: Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser ,ou=people,o=ipaca";) # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a llow (read) userdn="ldap:///uid=pkidbuser,ou=people,o=ipaca";;) # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue || dnaThre shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range"; allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss ions,cn=pbac,dc=dev-mydomain,dc=net";) # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement s,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";) # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-22-16 6:26 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 08:48 PM, Nathan Peters wrote: > Here are the results for that aci search using a non gssapi bind by directory > manager on the old master that we are attempting to join agains. I don't see > anything in this list that would indicate that some users should or should > not have access through a certain method. Unless one of those sasl config > settings is doing it ? > > [root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b > "cn=config" "(aci=*)" You almost got it. You left out the most important part, at the end of the command, specifying the "aci" attribute: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html # ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" aci -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
:389/dc%3Ddev-mydomain%2Cdc%3Dnet nsslapd-state: backend objectClass: top objectClass: extensibleObject objectClass: nsMappingTree # o\3Dipaca, mapping tree, config dn: cn=o\3Dipaca,cn=mapping tree,cn=config cn: o=ipaca nsslapd-backend: ipaca nsslapd-referral: ldap://dc1-ipa-dev-nvan.dev-mydomain.net:389/o%3Dipaca nsslapd-referral: ldap://dc1-ipa-dev-van.dev-mydomain.net:389/o%3Dipaca nsslapd-state: Backend objectClass: top objectClass: extensibleObject objectClass: nsMappingTree # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config cn: ldbm database nsslapd-plugin-depends-on-type: Syntax nsslapd-plugin-depends-on-type: matchingRule nsslapd-pluginDescription: high-performance LDAP backend database plugin nsslapd-pluginEnabled: on nsslapd-pluginId: ldbm-backend nsslapd-pluginInitfunc: ldbm_back_init nsslapd-pluginPath: libback-ldbm nsslapd-pluginType: database nsslapd-pluginVendor: 389 Project nsslapd-pluginVersion: 1.3.4.5 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config cn: Posix IDs dnaExcludeScope: cn=provisioning,dc=dev-mydomain,dc=net dnaFilter: (|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) dnaMagicRegen: -1 dnaMaxValue: 1100 dnaNextValue: 1101 dnaScope: dc=dev-mydomain,dc=net dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=dev-mydomain,dc=net dnaThreshold: 500 dnaType: uidNumber dnaType: gidNumber objectClass: top objectClass: extensibleObject # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: userRoot objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance nsslapd-suffix: dc=dev-mydomain,dc=net nsslapd-cachesize: -1 nsslapd-cachememsize: 10485760 nsslapd-readonly: off nsslapd-require-index: off nsslapd-directory: /var/lib/dirsrv/slapd-DEV-mydomain-NET/db/userRoot nsslapd-dncachememsize: 10485760 # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-21-16 7:29 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 12:50 AM, Nathan Peters wrote: I don't know if this makes a difference too, but I performed the same checks on a different completely working and joined FreeIPA master, against other masters, and even against itself directly. It seems that no account, no keytab, and no host can see that mapping tree branch no matter who they search from or against if GSSAPI is used. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-20-16 11:41 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists All checks below were performed from the host we are trying to turn into a replica and they were performed against the master who logs I also show The first check was to kinit admin and try the search. Surprisingly, the GSSAPI bind returns no results when we search that. In my previous email you can see that the standard bind gets a result as admin for that search. Next, I tried as the host by kinit with its keytab. Same result, nothing back. Finally I tried as my own personal admin user. Same result, nothing back. For good measure, I tried a broad search against the base "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand lines of screenshot but the results were as expected, several thousand entries in that tree. Although the output differed slightly. This is the total as admin or my personal user # numResponses: 3372 # numEntries: 3371 and this is the total as the host keytab account # numResponses: 3371 # numEntries: 3370 To be even more thorough, I did searches farther and farther up the config tree using GSSAPI until I found something. The only thing that is visible through GSSAPI searches is the base of the config tree. Even the mapping tree branch doesn't seem to be visible. At the very bottom of this email is the results of the search against cn=config directly as the attempted new replica and as admin. Admin gets about 50 results and the host only gets about 30 for some reason. I get the same results as admin on my personal account so I've excluded those. So if I got all that right I was able to determine that only the base of the config tree is available using GSSAPI for any account, users for some reason get slightly more results than hosts, and all accounts can see the dc=mydomain,dc=net tree just fine using GSSAPI. So does that help shed some light on what the cause of this
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
pd-referral: ldap://dc1-ipa-dev-nvan.dev-mydomain.net:389/o%3Dipaca nsslapd-referral: ldap://dc1-ipa-dev-van.dev-mydomain.net:389/o%3Dipaca nsslapd-state: Backend objectClass: top objectClass: extensibleObject objectClass: nsMappingTree # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config cn: ldbm database nsslapd-plugin-depends-on-type: Syntax nsslapd-plugin-depends-on-type: matchingRule nsslapd-pluginDescription: high-performance LDAP backend database plugin nsslapd-pluginEnabled: on nsslapd-pluginId: ldbm-backend nsslapd-pluginInitfunc: ldbm_back_init nsslapd-pluginPath: libback-ldbm nsslapd-pluginType: database nsslapd-pluginVendor: 389 Project nsslapd-pluginVersion: 1.3.4.5 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config cn: Posix IDs dnaExcludeScope: cn=provisioning,dc=dev-mydomain,dc=net dnaFilter: (|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) dnaMagicRegen: -1 dnaMaxValue: 1100 dnaNextValue: 1101 dnaScope: dc=dev-mydomain,dc=net dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=dev-mydomain,dc=net dnaThreshold: 500 dnaType: uidNumber dnaType: gidNumber objectClass: top objectClass: extensibleObject # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: userRoot objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance nsslapd-suffix: dc=dev-mydomain,dc=net nsslapd-cachesize: -1 nsslapd-cachememsize: 10485760 nsslapd-readonly: off nsslapd-require-index: off nsslapd-directory: /var/lib/dirsrv/slapd-DEV-mydomain-NET/db/userRoot nsslapd-dncachememsize: 10485760 # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-21-16 7:29 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 12:50 AM, Nathan Peters wrote: I don't know if this makes a difference too, but I performed the same checks on a different completely working and joined FreeIPA master, against other masters, and even against itself directly. It seems that no account, no keytab, and no host can see that mapping tree branch no matter who they search from or against if GSSAPI is used. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-20-16 11:41 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists All checks below were performed from the host we are trying to turn into a replica and they were performed against the master who logs I also show The first check was to kinit admin and try the search. Surprisingly, the GSSAPI bind returns no results when we search that. In my previous email you can see that the standard bind gets a result as admin for that search. Next, I tried as the host by kinit with its keytab. Same result, nothing back. Finally I tried as my own personal admin user. Same result, nothing back. For good measure, I tried a broad search against the base "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand lines of screenshot but the results were as expected, several thousand entries in that tree. Although the output differed slightly. This is the total as admin or my personal user # numResponses: 3372 # numEntries: 3371 and this is the total as the host keytab account # numResponses: 3371 # numEntries: 3370 To be even more thorough, I did searches farther and farther up the config tree using GSSAPI until I found something. The only thing that is visible through GSSAPI searches is the base of the config tree. Even the mapping tree branch doesn't seem to be visible. At the very bottom of this email is the results of the search against cn=config directly as the attempted new replica and as admin. Admin gets about 50 results and the host only gets about 30 for some reason. I get the same results as admin on my personal account so I've excluded those. So if I got all that right I was able to determine that only the base of the config tree is available using GSSAPI for any account, users for some reason get slightly more results than hosts, and all accounts can see the dc=mydomain,dc=net tree just fine using GSSAPI. So does that help shed some light on what the cause of this might be or why the server is not answering as expected? Is there some way I can adjust this so everyone can see the results they do using regular binds as they do using GSSAPI binds ? Is there some way I can check ACLS on stu
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
om] On Behalf Of Ludwig Krispenz Sent: January-21-16 7:45 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 08:50 AM, Nathan Peters wrote: > I don't know if this makes a difference too, but I performed the same checks > on a different completely working and joined FreeIPA master, against other > masters, and even against itself directly. > > It seems that no account, no keytab, and no host can see that mapping tree > branch no matter who they search from or against if GSSAPI is used. there should be no difference in the result, it should only depend on the acis and in one of your previous posts you said that you don't get a result bound as admin: >>> [root@dc2-ipa-dev-van ~]# ldapsearch -Hldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D "uid=admin,cn=users,cn=accounts,dc=mydomain,dc=net" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ---snip--- So we know that for whatever reason, this particular DN cannot be searched from anyone other than directory manager. <<< so could you provide the result and log of a search with gssapi and directly bound to the same server. And as directory manager query the acis in the mapping tree entry -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
t objectClass: nsMappingTree # ldbm database, plugins, config dn: cn=ldbm database,cn=plugins,cn=config cn: ldbm database nsslapd-plugin-depends-on-type: Syntax nsslapd-plugin-depends-on-type: matchingRule nsslapd-pluginDescription: high-performance LDAP backend database plugin nsslapd-pluginEnabled: on nsslapd-pluginId: ldbm-backend nsslapd-pluginInitfunc: ldbm_back_init nsslapd-pluginPath: libback-ldbm nsslapd-pluginType: database nsslapd-pluginVendor: 389 Project nsslapd-pluginVersion: 1.3.4.5 objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config cn: Posix IDs dnaExcludeScope: cn=provisioning,dc=dev-mydomain,dc=net dnaFilter: (|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) dnaMagicRegen: -1 dnaMaxValue: 1100 dnaNextValue: 1101 dnaScope: dc=dev-mydomain,dc=net dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=dev-mydomain,dc=net dnaThreshold: 500 dnaType: uidNumber dnaType: gidNumber objectClass: top objectClass: extensibleObject # userRoot, ldbm database, plugins, config dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: userRoot objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance nsslapd-suffix: dc=dev-mydomain,dc=net nsslapd-cachesize: -1 nsslapd-cachememsize: 10485760 nsslapd-readonly: off nsslapd-require-index: off nsslapd-directory: /var/lib/dirsrv/slapd-DEV-mydomain-NET/db/userRoot nsslapd-dncachememsize: 10485760 # search result search: 2 result: 0 Success # numResponses: 13 # numEntries: 12 -Original Message- From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: January-21-16 7:29 AM To: Nathan Peters; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/21/2016 12:50 AM, Nathan Peters wrote: > I don't know if this makes a difference too, but I performed the same checks > on a different completely working and joined FreeIPA master, against other > masters, and even against itself directly. > > It seems that no account, no keytab, and no host can see that mapping tree > branch no matter who they search from or against if GSSAPI is used. > > > -Original Message- > From: freeipa-users-boun...@redhat.com > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters > Sent: January-20-16 11:41 PM > To: Rich Megginson; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails > with DuplicateEntry: This entry already exists > > All checks below were performed from the host we are trying to turn > into a replica and they were performed against the master who logs I > also show > > The first check was to kinit admin and try the search. Surprisingly, the > GSSAPI bind returns no results when we search that. In my previous email you > can see that the standard bind gets a result as admin for that search. > > Next, I tried as the host by kinit with its keytab. Same result, nothing > back. > > Finally I tried as my own personal admin user. Same result, nothing back. > > For good measure, I tried a broad search against the base > "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand > lines of screenshot but the results were as expected, several thousand > entries in that tree. > Although the output differed slightly. This is the total as admin or > my personal user # numResponses: 3372 # numEntries: 3371 > > and this is the total as the host keytab account > > # numResponses: 3371 > # numEntries: 3370 > > To be even more thorough, I did searches farther and farther up the config > tree using GSSAPI until I found something. The only thing that is visible > through GSSAPI searches is the base of the config tree. Even the mapping > tree branch doesn't seem to be visible. > > At the very bottom of this email is the results of the search against > cn=config directly as the attempted new replica and as admin. Admin gets > about 50 results and the host only gets about 30 for some reason. I get the > same results as admin on my personal account so I've excluded those. > > So if I got all that right I was able to determine that only the base of the > config tree is available using GSSAPI for any account, users for some reason > get slightly more results than hosts, and all accounts can see the > dc=mydomain,dc=net tree just fine using GSSAPI. > > So does that help shed some light on what the cause of this might be or why > the server is not answering as expected? > > Is there some way I can adjust this so everyone can see the results they do > using reg
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 01/21/2016 08:50 AM, Nathan Peters wrote: I don't know if this makes a difference too, but I performed the same checks on a different completely working and joined FreeIPA master, against other masters, and even against itself directly. It seems that no account, no keytab, and no host can see that mapping tree branch no matter who they search from or against if GSSAPI is used. there should be no difference in the result, it should only depend on the acis and in one of your previous posts you said that you don't get a result bound as admin: >>> [root@dc2-ipa-dev-van ~]# ldapsearch -Hldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D "uid=admin,cn=users,cn=accounts,dc=mydomain,dc=net" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ---snip--- So we know that for whatever reason, this particular DN cannot be searched from anyone other than directory manager. <<< so could you provide the result and log of a search with gssapi and directly bound to the same server. And as directory manager query the acis in the mapping tree entry -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-20-16 11:41 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists All checks below were performed from the host we are trying to turn into a replica and they were performed against the master who logs I also show The first check was to kinit admin and try the search. Surprisingly, the GSSAPI bind returns no results when we search that. In my previous email you can see that the standard bind gets a result as admin for that search. Next, I tried as the host by kinit with its keytab. Same result, nothing back. Finally I tried as my own personal admin user. Same result, nothing back. For good measure, I tried a broad search against the base "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand lines of screenshot but the results were as expected, several thousand entries in that tree. Although the output differed slightly. This is the total as admin or my personal user # numResponses: 3372 # numEntries: 3371 and this is the total as the host keytab account # numResponses: 3371 # numEntries: 3370 To be even more thorough, I did searches farther and farther up the config tree using GSSAPI until I found something. The only thing that is visible through GSSAPI searches is the base of the config tree. Even the mapping tree branch doesn't seem to be visible. At the very bottom of this email is the results of the search against cn=config directly as the attempted new replica and as admin. Admin gets about 50 results and the host only gets about 30 for some reason. I get the same results as admin on my personal account so I've excluded those. So if I got all that right I was able to determine that only the base of the config tree is available using GSSAPI for any account, users for some reason get slightly more results than hosts, and all accounts can see the dc=mydomain,dc=net tree just fine using GSSAPI. So does that help shed some light on what the cause of this might be or why the server is not answering as expected? Is there some way I can adjust this so everyone can see the results they do using regular binds as they do using GSSAPI binds ? Is there some way I can check ACLS on stuff ? === search as admin === [nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: KEYRING:persistent:756600344:756600344 Default principal: ad...@mydomain.net Valid starting ExpiresService principal 20/01/16 22:53:18 21/01/16 22:53:08 krbtgt/mydomain@mydomain.net [nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" SASL/GSSAPI authentication started SASL username: ad...@mydomain.net SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 4 result: 0 Success # numResponses: 1 check host keytab [root@dc2-ipa-dev-van ipa]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal - 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 01/21/2016 12:50 AM, Nathan Peters wrote: I don't know if this makes a difference too, but I performed the same checks on a different completely working and joined FreeIPA master, against other masters, and even against itself directly. It seems that no account, no keytab, and no host can see that mapping tree branch no matter who they search from or against if GSSAPI is used. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-20-16 11:41 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists All checks below were performed from the host we are trying to turn into a replica and they were performed against the master who logs I also show The first check was to kinit admin and try the search. Surprisingly, the GSSAPI bind returns no results when we search that. In my previous email you can see that the standard bind gets a result as admin for that search. Next, I tried as the host by kinit with its keytab. Same result, nothing back. Finally I tried as my own personal admin user. Same result, nothing back. For good measure, I tried a broad search against the base "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand lines of screenshot but the results were as expected, several thousand entries in that tree. Although the output differed slightly. This is the total as admin or my personal user # numResponses: 3372 # numEntries: 3371 and this is the total as the host keytab account # numResponses: 3371 # numEntries: 3370 To be even more thorough, I did searches farther and farther up the config tree using GSSAPI until I found something. The only thing that is visible through GSSAPI searches is the base of the config tree. Even the mapping tree branch doesn't seem to be visible. At the very bottom of this email is the results of the search against cn=config directly as the attempted new replica and as admin. Admin gets about 50 results and the host only gets about 30 for some reason. I get the same results as admin on my personal account so I've excluded those. So if I got all that right I was able to determine that only the base of the config tree is available using GSSAPI for any account, users for some reason get slightly more results than hosts, and all accounts can see the dc=mydomain,dc=net tree just fine using GSSAPI. So does that help shed some light on what the cause of this might be or why the server is not answering as expected? Is there some way I can adjust this so everyone can see the results they do using regular binds as they do using GSSAPI binds ? Is there some way I can check ACLS on stuff ? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html Note: There is a bug in the docs. You have to also specify the suffix e.g. "-b cn=config", and make sure the search filter is quoted e.g. '(aci=*)' If it is not aci related, I have no idea why you would get different results depending on if you did a simple bind vs. a gssapi bind with the same user that mapped to the same bind DN. === search as admin === [nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: KEYRING:persistent:756600344:756600344 Default principal: ad...@mydomain.net Valid starting ExpiresService principal 20/01/16 22:53:18 21/01/16 22:53:08 krbtgt/mydomain@mydomain.net [nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" SASL/GSSAPI authentication started SASL username: ad...@mydomain.net SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 4 result: 0 Success # numResponses: 1 check host keytab [root@dc2-ipa-dev-van ipa]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal - 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net kinit host keytab [root@dc2-ipa-dev-van ipa]# kinit -t /etc/krb5.keytab keytab specified, forcing -k [root@dc2-ipa-dev-van ipa]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_uwO1f2L Default principal: host/dc2-ipa-dev-van.mydomain@mydomain.net Valid starting E
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
I don't know if this makes a difference too, but I performed the same checks on a different completely working and joined FreeIPA master, against other masters, and even against itself directly. It seems that no account, no keytab, and no host can see that mapping tree branch no matter who they search from or against if GSSAPI is used. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters Sent: January-20-16 11:41 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists All checks below were performed from the host we are trying to turn into a replica and they were performed against the master who logs I also show The first check was to kinit admin and try the search. Surprisingly, the GSSAPI bind returns no results when we search that. In my previous email you can see that the standard bind gets a result as admin for that search. Next, I tried as the host by kinit with its keytab. Same result, nothing back. Finally I tried as my own personal admin user. Same result, nothing back. For good measure, I tried a broad search against the base "cn=mydomain,cn=net" as each user as well and I'll spare you the ten thousand lines of screenshot but the results were as expected, several thousand entries in that tree. Although the output differed slightly. This is the total as admin or my personal user # numResponses: 3372 # numEntries: 3371 and this is the total as the host keytab account # numResponses: 3371 # numEntries: 3370 To be even more thorough, I did searches farther and farther up the config tree using GSSAPI until I found something. The only thing that is visible through GSSAPI searches is the base of the config tree. Even the mapping tree branch doesn't seem to be visible. At the very bottom of this email is the results of the search against cn=config directly as the attempted new replica and as admin. Admin gets about 50 results and the host only gets about 30 for some reason. I get the same results as admin on my personal account so I've excluded those. So if I got all that right I was able to determine that only the base of the config tree is available using GSSAPI for any account, users for some reason get slightly more results than hosts, and all accounts can see the dc=mydomain,dc=net tree just fine using GSSAPI. So does that help shed some light on what the cause of this might be or why the server is not answering as expected? Is there some way I can adjust this so everyone can see the results they do using regular binds as they do using GSSAPI binds ? Is there some way I can check ACLS on stuff ? === search as admin === [nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: KEYRING:persistent:756600344:756600344 Default principal: ad...@mydomain.net Valid starting ExpiresService principal 20/01/16 22:53:18 21/01/16 22:53:08 krbtgt/mydomain@mydomain.net [nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" SASL/GSSAPI authentication started SASL username: ad...@mydomain.net SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 4 result: 0 Success # numResponses: 1 check host keytab [root@dc2-ipa-dev-van ipa]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal - 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net 5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net kinit host keytab [root@dc2-ipa-dev-van ipa]# kinit -t /etc/krb5.keytab keytab specified, forcing -k [root@dc2-ipa-dev-van ipa]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_uwO1f2L Default principal: host/dc2-ipa-dev-van.mydomain@mydomain.net Valid starting ExpiresService principal 20/01/16 23:01:11 21/01/16 23:01:11 krbtgt/mydomain@mydomain.net [root@dc2-ipa-dev-van ipa]# = ldap search against master as host == [root@dc2-ipa-dev-van ipa]# ldapsearch -Y GSSAPI -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" SASL/GSSAPI authentication started SASL username: host/dc2-ipa-dev-van.mydomain@mydomain.net SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (o
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
fig cn: targetuniqueid objectClass: top objectClass: nsIndex # telephoneNumber, default indexes, config, ldbm database, plugins, config dn: cn=telephoneNumber,cn=default indexes,cn=config,cn=ldbm database,cn=plugin s,cn=config cn: telephoneNumber objectClass: top objectClass: nsIndex # uid, default indexes, config, ldbm database, plugins, config dn: cn=uid,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config cn: uid objectClass: top objectClass: nsIndex # uniquemember, default indexes, config, ldbm database, plugins, config dn: cn=uniquemember,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,c n=config cn: uniquemember objectClass: top objectClass: nsIndex # search result search: 4 result: 0 Success # numResponses: 51 # numEntries: 50 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson Sent: January-20-16 11:44 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/20/2016 12:24 PM, Nathan Peters wrote: > Now we are starting to get somewhere (although a resolution still is > not visible) :) > > First, thank you Petr and Rob for your help on this issue. I apologize for > our hard to parse server names. I'm not a fan of them myself and in earlier > reports I had been reformatting everything nicely with dc1, dc2, dc3 etc. > After having to submit so many reports I started to get lazy an thought it > may be more helpful to see data closer to what we are actually using. > > Petr hit the nail on the head with the "does everyone who binds get the same > result" question, which although it has not revealed a resolution, has > revealed a bunch of really interesting facts about the process. > > Going back to the original logs that were running on the remote master during > the replica installation attempt I see the following : > > [18/Jan/2016:09:28:32 -0800] conn=18732 fd=77 slot=77 connection from > 10.21.0.98 to 10.178.0.98 >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=0 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=2 RESULT err=0 tag=97 nentries=0 >> etime=0 >> dn="fqdn=dc2-ipa-dev-van.mydomain.net,cn=computers,cn=accounts,dc=mydomain,dc=net" >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=3 SRCH >> base="cn=replication,cn=etc,dc=mydomain,dc=net" scope=0 >> filter="(objectClass=*)" attrs=ALL >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=4 SRCH base="cn=schema" scope=0 >> filter="(objectClass=*)" attrs="attributeTypes objectClasses" >> [18/Jan/2016:09:28:32 -0800] conn=18732 op=4 RESULT err=0 tag=101 >> nentries=1 etime=0 > So, conn18732 was opened with a bind dn of "" ? Is this supposed to happen? Yes. GSSAPI/SASL binds are multi-stage binds. You'll notice that the last stage is op=2, and the result has the full bind DN to which the kerberos principals mapped to. The dn="" until the last stage at which time the mapped DN is known and logged. > > Here is what I see when I search that base using the same empty bind dn : nack - you have to first use "kinit myusername@MYDOMAIN", then use ldapsearch -Y GSSAPI , to do the bind in the same way to use GSSAPI. -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
UpdateStatus: 0 Replica acquired successfully: Incremental upd ate succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 1970010100Z nsds5replicaLastInitEnd: 1970010100Z # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 -----Original Message----- From: Petr Vobornik [mailto:pvobo...@redhat.com] Sent: January-20-16 2:02 AM To: Rob Crittenden; Nathan Peters; Ludwig Krispenz Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists On 01/20/2016 12:31 AM, Rob Crittenden wrote: Nathan Peters wrote: [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 ADD dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config" [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 RESULT err=68 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:33 -0800] conn=18732 op=11 UNBIND Do you mean that log entry ^? I am seeing that entry on dc2-ipa-dev-nvan, the host that dc1-ipa-dev-van is contacting as its master when we attempt the ipa-replica-install. Look through my earlier posts in this thread for a full log. Don't assume we have any idea what your hostnames mean, especially when they differ only by a few characters. It is good to list them but I'd also suggest you use terms like existing master and new server or something so we can distinguish the players without having to slowly parse every name. Yes, of course that DN exists on all my masters. With a 3 way replication it would have to exist because the current master is replicating to 2 other masters. Here is the ldapsearch for all 3 existing hosts showing that DN (dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config") which is apparently failing to be added because it already exists on all my hosts. The important thing here is that cn=config is not replicated. It is configured on each master during replica setup, exactly where it is failing for you. Given that it is failing on ANOTHER server says a lot. It is failing, I think in part, because this search on the remote master is returning no entries: [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 RESULT err=0 tag=101 nentries=0 etime=0 IMO this is the culprit. It should return the entry if it is in fact there. Right after this is the ADD which fails with err=68 which means that in fact, it does exist. I'm not sure why this is happening. I don't immediately see why a NotFound would be raised in this case but I'm guessing it is. It would be interesting to walk through the code using the python debugger, pdb. In any case the duplicate entry is due to the replica setup code trying to configure the remote master for basic replication and this has already been done. Yes the replica code works as expected. Next step is to investigate why the search returns nothing. ACI issue? Weird DB state? Can other user fetch it? E.g. admin? If so wow does "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" on the master server looks like? -- Petr Vobornik -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
ctClass: nsds5replica
objectClass: top
objectClass: extensibleobject
nsds5ReplicaChangeCount: 91169
nsds5replicareapactive: 0
# meTodc1-ipa-dev-nvan.mydomain.net, replica, dc\3Dmydomain\2Cdc\
3Dnet, mapping tree, config
dn:
cn=meTodc1-ipa-dev-nvan.mydomain.net,cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping
tree,cn=config
cn: meTodc1-ipa-dev-nvan.mydomain.net
description: me to dc1-ipa-dev-nvan.mydomain.net
nsDS5ReplicaBindMethod: SASL/GSSAPI
nsDS5ReplicaHost: dc1-ipa-dev-nvan.mydomain.net
nsDS5ReplicaPort: 389
nsDS5ReplicaRoot: dc=mydomain,dc=net
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
uccessfulauth krblastfailedauth krbloginfailedcount
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 16 ldap://dc1-ipa-dev-nvan.mydomain.net:389} 569afd
260010 569b920100220010
nsds50ruv: {replica 17 ldap://dc1-ipa-dev-van.mydomain.net:389} 569b124
b0011 569b91af000d0011
nsds50ruv: {replica 15 ldap://dc2-ipa-dev-nvan.mydomain.net:389} 569aee
04000f 569b92010002000f
nsds50ruv: {replica 14 ldap://dc2-ipa-dev-van.mydomain.net:389} 569ae7b
b000e 569b91320014000e
nsds5ReplicaEnabled: on
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
ternalModifyTimestamp
nsds5replicaTimeout: 120
nsruvReplicaLastModified: {replica 16 ldap://dc1-ipa-dev-nvan.mydomain.
net:389}
nsruvReplicaLastModified: {replica 17 ldap://dc1-ipa-dev-van.mydomain.n
et:389}
nsruvReplicaLastModified: {replica 15 ldap://dc2-ipa-dev-nvan.mydomain.
net:389}
nsruvReplicaLastModified: {replica 14 ldap://dc2-ipa-dev-van.mydomain.n
et:389}
objectClass: nsds5replicationagreement
objectClass: top
objectClass: ipaReplTopoManagedAgreement
ipaReplTopoManagedAgreementState: managed agreement - controlled by topology p
lugin
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160120190605Z
nsds5replicaLastUpdateEnd: 20160120190605Z
nsds5replicaChangesSentSinceStartup:: MTU6NjY3LzIyNTk3NTEgMTQ6MS8wIDE3OjIyLzAg
MTY6Mi8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd
ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z
# meTodc1-ipa-dev-van.mydomain.net, replica, dc\3Dmydomain\2Cdc\3
Dnet, mapping tree, config
dn:
cn=meTodc1-ipa-dev-van.mydomain.net,cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping
tree,cn=config
cn: meTodc1-ipa-dev-van.mydomain.net
description: me to dc1-ipa-dev-van.mydomain.net
nsDS5ReplicaBindMethod: SASL/GSSAPI
nsDS5ReplicaHost: dc1-ipa-dev-van.mydomain.net
nsDS5ReplicaPort: 389
nsDS5ReplicaRoot: dc=mydomain,dc=net
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
uccessfulauth krblastfailedauth krbloginfailedcount
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
ternalModifyTimestamp
nsds5replicaTimeout: 120
objectClass: nsds5replicationagreement
objectClass: top
objectClass: ipaReplTopoManagedAgreement
ipaReplTopoManagedAgreementState: managed agreement - controlled by topology p
lugin
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 17 ldap://dc1-ipa-dev-van.mydomain.net:389} 569b124
b0011 569b920100050011
nsds50ruv: {replica 16 ldap://dc1-ipa-dev-nvan.mydomain.net:389} 569afd
260010 569b918d004a0010
nsds50ruv: {replica 15 ldap://dc2-ipa-dev-nvan.mydomain.net:389} 569aee
04000f 569b92010002000f
nsds50ruv: {replica 14 ldap://dc2-ipa-dev-van.mydomain.net:389} 569ae7b
b000e 569b91320014000e
nsruvReplicaLastModified: {replica 17 ldap://dc1-ipa-dev-van.mydomain.n
et:389}
nsruvReplicaLastModified: {replica 16 ldap://dc1-ipa-dev-nvan.mydomain.
net:389}
nsruvReplicaLastModified: {replica 15 ldap://dc2-ipa-dev-nvan.mydomain.
net:389}
nsruvReplicaLastModified: {replica 14 ldap://dc2-ipa-dev-van.mydomain.n
et:389}
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160120190602Z
nsds5replicaLastUpdateEnd: 20160120190602Z
nsds5replicaChangesSentSinceStartup:: MTU6ODgzLzQwNDIwNTcgMTY6MjQzLzAgMTc6Mi8w
IDA6MS8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd
ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: January-20-16 2:02 AM
To: Rob Crit
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 01/20/2016 12:31 AM, Rob Crittenden wrote: Nathan Peters wrote: [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 ADD dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config" [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 RESULT err=68 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:33 -0800] conn=18732 op=11 UNBIND Do you mean that log entry ^? I am seeing that entry on dc2-ipa-dev-nvan, the host that dc1-ipa-dev-van is contacting as its master when we attempt the ipa-replica-install. Look through my earlier posts in this thread for a full log. Don't assume we have any idea what your hostnames mean, especially when they differ only by a few characters. It is good to list them but I'd also suggest you use terms like existing master and new server or something so we can distinguish the players without having to slowly parse every name. Yes, of course that DN exists on all my masters. With a 3 way replication it would have to exist because the current master is replicating to 2 other masters. Here is the ldapsearch for all 3 existing hosts showing that DN (dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config") which is apparently failing to be added because it already exists on all my hosts. The important thing here is that cn=config is not replicated. It is configured on each master during replica setup, exactly where it is failing for you. Given that it is failing on ANOTHER server says a lot. It is failing, I think in part, because this search on the remote master is returning no entries: [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 RESULT err=0 tag=101 nentries=0 etime=0 IMO this is the culprit. It should return the entry if it is in fact there. Right after this is the ADD which fails with err=68 which means that in fact, it does exist. I'm not sure why this is happening. I don't immediately see why a NotFound would be raised in this case but I'm guessing it is. It would be interesting to walk through the code using the python debugger, pdb. In any case the duplicate entry is due to the replica setup code trying to configure the remote master for basic replication and this has already been done. Yes the replica code works as expected. Next step is to investigate why the search returns nothing. ACI issue? Weird DB state? Can other user fetch it? E.g. admin? If so wow does "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" on the master server looks like? -- Petr Vobornik -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
Nathan Peters wrote: > [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 ADD > dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config" > [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 RESULT err=68 tag=105 > nentries=0 etime=0 > [18/Jan/2016:09:28:33 -0800] conn=18732 op=11 UNBIND > > Do you mean that log entry ^? I am seeing that entry on dc2-ipa-dev-nvan, > the host that dc1-ipa-dev-van is contacting as its master when we attempt the > ipa-replica-install. Look through my earlier posts in this thread for a full > log. Don't assume we have any idea what your hostnames mean, especially when they differ only by a few characters. It is good to list them but I'd also suggest you use terms like existing master and new server or something so we can distinguish the players without having to slowly parse every name. > Yes, of course that DN exists on all my masters. With a 3 way replication it > would have to exist because the current master is replicating to 2 other > masters. Here is the ldapsearch for all 3 existing hosts showing that DN > (dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping > tree,cn=config") which is apparently failing to be added because it already > exists on all my hosts. The important thing here is that cn=config is not replicated. It is configured on each master during replica setup, exactly where it is failing for you. Given that it is failing on ANOTHER server says a lot. It is failing, I think in part, because this search on the remote master is returning no entries: [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:33 -0800] conn=18732 op=9 RESULT err=0 tag=101 nentries=0 etime=0 Right after this is the ADD which fails with err=68 which means that in fact, it does exist. I'm not sure why this is happening. I don't immediately see why a NotFound would be raised in this case but I'm guessing it is. It would be interesting to walk through the code using the python debugger, pdb. In any case the duplicate entry is due to the replica setup code trying to configure the remote master for basic replication and this has already been done. 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
.net
description: me to dc1-ipa-dev-nvan.dev-mydomain.net
nsDS5ReplicaBindMethod: SASL/GSSAPI
nsDS5ReplicaHost: dc1-ipa-dev-nvan.dev-mydomain.net
nsDS5ReplicaPort: 389
nsDS5ReplicaRoot: dc=dev-mydomain,dc=net
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
uccessfulauth krblastfailedauth krbloginfailedcount
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 16 ldap://dc1-ipa-dev-nvan.dev-mydomain.net:389} 569afd
260010 569b920100220010
nsds50ruv: {replica 17 ldap://dc1-ipa-dev-van.dev-mydomain.net:389} 569b124
b0011 569b91af000d0011
nsds50ruv: {replica 15 ldap://dc2-ipa-dev-nvan.dev-mydomain.net:389} 569aee
04000f 569b92010002000f
nsds50ruv: {replica 14 ldap://dc2-ipa-dev-van.dev-mydomain.net:389} 569ae7b
b000e 569b91320014000e
nsds5ReplicaEnabled: on
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
ternalModifyTimestamp
nsds5replicaTimeout: 120
nsruvReplicaLastModified: {replica 16 ldap://dc1-ipa-dev-nvan.dev-mydomain.
net:389}
nsruvReplicaLastModified: {replica 17 ldap://dc1-ipa-dev-van.dev-mydomain.n
et:389}
nsruvReplicaLastModified: {replica 15 ldap://dc2-ipa-dev-nvan.dev-mydomain.
net:389}
nsruvReplicaLastModified: {replica 14 ldap://dc2-ipa-dev-van.dev-mydomain.n
et:389}
objectClass: nsds5replicationagreement
objectClass: top
objectClass: ipaReplTopoManagedAgreement
ipaReplTopoManagedAgreementState: managed agreement - controlled by topology p
lugin
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160119214250Z
nsds5replicaLastUpdateEnd: 20160119214250Z
nsds5replicaChangesSentSinceStartup:: MTU6NDk2LzE2MjI3NzggMTQ6MS8wIDE3OjIyLzAg
MTY6Mi8wIA==
nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z
# meTodc1-ipa-dev-van.dev-mydomain.net, replica, dc\3Ddev-mydomain\2Cdc\3
Dnet, mapping tree, config
dn:
cn=meTodc1-ipa-dev-van.dev-mydomain.net,cn=replica,cn=dc\3Ddev-mydomain\2Cdc\3Dnet,cn=mapping
tree,cn=config
cn: meTodc1-ipa-dev-van.dev-mydomain.net
description: me to dc1-ipa-dev-van.dev-mydomain.net
nsDS5ReplicaBindMethod: SASL/GSSAPI
nsDS5ReplicaHost: dc1-ipa-dev-van.dev-mydomain.net
nsDS5ReplicaPort: 389
nsDS5ReplicaRoot: dc=dev-mydomain,dc=net
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
uccessfulauth krblastfailedauth krbloginfailedcount
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
ternalModifyTimestamp
nsds5replicaTimeout: 120
objectClass: nsds5replicationagreement
objectClass: top
objectClass: ipaReplTopoManagedAgreement
ipaReplTopoManagedAgreementState: managed agreement - controlled by topology p
lugin
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 17 ldap://dc1-ipa-dev-van.dev-mydomain.net:389} 569b124
b0011 569b920100050011
nsds50ruv: {replica 16 ldap://dc1-ipa-dev-nvan.dev-mydomain.net:389} 569afd
260010 569b918d004a0010
nsds50ruv: {replica 15 ldap://dc2-ipa-dev-nvan.dev-mydomain.net:389} 569aee
04000f 569b92010002000f
nsds50ruv: {replica 14 ldap://dc2-ipa-dev-van.dev-mydomain.net:389} 569ae7b
b000e 569b91320014000e
nsruvReplicaLastModified: {replica 17 ldap://dc1-ipa-dev-van.dev-mydomain.n
et:389}
nsruvReplicaLastModified: {replica 16 ldap://dc1-ipa-dev-nvan.dev-mydomain.
net:389}
nsruvReplicaLastModified: {replica 15 ldap://dc2-ipa-dev-nvan.dev-mydomain.
net:389}
nsruvReplicaLastModified: {replica 14 ldap://dc2-ipa-dev-van.dev-mydomain.n
et:389}
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160119214305Z
nsds5replicaLastUpdateEnd: 20160119214305Z
nsds5replicaChangesSentSinceStartup:: MTU6NjQ0LzI4NDc1OTggMTY6MTc2LzAgMTc6Mi8w
IDA6MS8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd
ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: January-19-16 12:33 PM
To: Nathan Peters; Ludwig Krispenz
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with
DuplicateEntry: This entry already exists
Nathan Peters wrote:
> Ok, after rm-rf /etc/dirsrv I was able to re-install again, but back to the
> old i
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
on=3 mech=EXTERNAL > [18/Jan/2016:09:28:31 -0800] conn=2 op=0 RESULT err=0 tag=97 nentries=0 > etime=0 dn="cn=Directory Manager" > [18/Jan/2016:09:28:31 -0800] conn=2 op=1 SRCH > base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs=ALL > [18/Jan/2016:09:28:31 -0800] conn=2 op=1 RESULT err=32 tag=101 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=2 SRCH > base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs=ALL > [18/Jan/2016:09:28:32 -0800] conn=2 op=2 RESULT err=32 tag=101 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=3 SRCH base="cn=schema" scope=0 > filter="(objectClass=*)" attrs="attributeTypes objectClasses" > [18/Jan/2016:09:28:32 -0800] conn=2 op=3 RESULT err=0 tag=101 nentries=1 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=4 ADD > dn="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" > [18/Jan/2016:09:28:32 -0800] conn=2 op=4 RESULT err=0 tag=105 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=5 SRCH base="cn=config,cn=ldbm > database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" > attrs="nsslapd-directory" > [18/Jan/2016:09:28:32 -0800] conn=2 op=5 RESULT err=0 tag=101 nentries=1 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=6 ADD dn="cn=changelog5,cn=config" > [18/Jan/2016:09:28:32 -0800] conn=2 op=6 RESULT err=0 tag=105 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=7 ADD > dn="cn=ldap/dc2-ipa-dev-nvan.mydomain@mydomain.net,cn=config" > [18/Jan/2016:09:28:32 -0800] conn=2 op=7 RESULT err=0 tag=105 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=8 SRCH > base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" > scope=0 filter="(objectClass=*)" attrs=ALL > [18/Jan/2016:09:28:32 -0800] conn=2 op=8 RESULT err=0 tag=101 nentries=1 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=9 MOD > dn="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" > [18/Jan/2016:09:28:32 -0800] conn=2 op=9 RESULT err=0 tag=103 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=10 ADD dn="cn=Peer > Master,cn=mapping,cn=sasl,cn=config" > [18/Jan/2016:09:28:32 -0800] conn=2 op=10 RESULT err=0 tag=105 nentries=0 > etime=0 > [18/Jan/2016:09:28:32 -0800] conn=2 op=11 UNBIND > [18/Jan/2016:09:28:32 -0800] conn=2 op=11 fd=65 closed - U1 > [18/Jan/2016:09:28:33 -0800] conn=3 fd=64 slot=64 connection from 10.178.6.56 > to 10.21.0.98 > [18/Jan/2016:09:28:33 -0800] conn=3 op=0 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl > supportedExtension supportedFeatures supportedLDAPVersion > supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext > lastusn highestcommittedusn aci" > [18/Jan/2016:09:28:33 -0800] conn=3 op=0 RESULT err=0 tag=101 nentries=1 > etime=0 > [18/Jan/2016:09:28:33 -0800] conn=3 op=1 UNBIND > [18/Jan/2016:09:28:33 -0800] conn=3 op=1 fd=64 closed - U1 > INSTALLATION CRASHED HERE BUT CLEARLY THE DS SERVICE ITSELF IS STILL > RUNNING BECAUSE MORE LOGS HAPPEN BELOW > [18/Jan/2016:09:29:11 -0800] conn=4 fd=64 slot=64 connection from 10.21.5.132 > to 10.21.0.98 > > > > > -Original Message- > From: freeipa-users-boun...@redhat.com > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Vobornik > Sent: January-18-16 3:57 AM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with > DuplicateEntry: This entry already exists > >> look at the DS access log, you should see an ADD operation with RESULT >> err=68 tag=105 > > According to code it's most likely > cn=replica,cn=$DOMAIN_SUFFIX,cn=mapping tree,cn=config > > I don't know why it happens because installer should add it only if the entry > does not exist. Would be worth to check the DS access log if base > search(which should happen before the add) for the dn fails or succeeds. > > -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
ctClasses" [18/Jan/2016:09:28:27 -0800] conn=2 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:27 -0800] conn=2 op=4 ADD dn="cn=RSA,cn=encryption,cn=config" [18/Jan/2016:09:28:27 -0800] conn=2 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:27 -0800] conn=2 op=5 UNBIND [18/Jan/2016:09:28:27 -0800] conn=2 op=5 fd=64 closed - U1 [18/Jan/2016:09:28:29 -0800] conn=1 fd=64 slot=64 connection from ::1 to ::1 [18/Jan/2016:09:28:29 -0800] conn=1 op=-1 fd=64 closed - B1 [18/Jan/2016:09:28:29 -0800] conn=2 fd=64 slot=64 connection from local to /var/run/slapd-MYDOMAIN-NET.socket [18/Jan/2016:09:28:29 -0800] conn=2 op=0 BIND dn="cn=directory manager" method=128 version=3 [18/Jan/2016:09:28:29 -0800] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [18/Jan/2016:09:28:29 -0800] conn=2 op=1 SRCH base="cn=IPA Version Replication,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:29 -0800] conn=2 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:29 -0800] conn=2 op=2 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [18/Jan/2016:09:28:29 -0800] conn=2 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:30 -0800] conn=2 op=3 MOD dn="cn=IPA Version Replication,cn=plugins,cn=config" [18/Jan/2016:09:28:30 -0800] conn=2 op=3 RESULT err=0 tag=103 nentries=0 etime=0 [18/Jan/2016:09:28:30 -0800] conn=2 op=4 UNBIND [18/Jan/2016:09:28:30 -0800] conn=2 op=4 fd=64 closed - U1 [18/Jan/2016:09:28:31 -0800] conn=1 fd=64 slot=64 connection from ::1 to ::1 [18/Jan/2016:09:28:31 -0800] conn=2 fd=65 slot=65 connection from local to /var/run/slapd-MYDOMAIN-NET.socket [18/Jan/2016:09:28:31 -0800] conn=1 op=-1 fd=64 closed - B1 [18/Jan/2016:09:28:31 -0800] conn=2 AUTOBIND dn="cn=Directory Manager" [18/Jan/2016:09:28:31 -0800] conn=2 op=0 BIND dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL [18/Jan/2016:09:28:31 -0800] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=Directory Manager" [18/Jan/2016:09:28:31 -0800] conn=2 op=1 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:31 -0800] conn=2 op=1 RESULT err=32 tag=101 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=2 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:32 -0800] conn=2 op=2 RESULT err=32 tag=101 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=3 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [18/Jan/2016:09:28:32 -0800] conn=2 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=4 ADD dn="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" [18/Jan/2016:09:28:32 -0800] conn=2 op=4 RESULT err=0 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=5 SRCH base="cn=config,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="nsslapd-directory" [18/Jan/2016:09:28:32 -0800] conn=2 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=6 ADD dn="cn=changelog5,cn=config" [18/Jan/2016:09:28:32 -0800] conn=2 op=6 RESULT err=0 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=7 ADD dn="cn=ldap/dc2-ipa-dev-nvan.mydomain@mydomain.net,cn=config" [18/Jan/2016:09:28:32 -0800] conn=2 op=7 RESULT err=0 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=8 SRCH base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs=ALL [18/Jan/2016:09:28:32 -0800] conn=2 op=8 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=9 MOD dn="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" [18/Jan/2016:09:28:32 -0800] conn=2 op=9 RESULT err=0 tag=103 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=10 ADD dn="cn=Peer Master,cn=mapping,cn=sasl,cn=config" [18/Jan/2016:09:28:32 -0800] conn=2 op=10 RESULT err=0 tag=105 nentries=0 etime=0 [18/Jan/2016:09:28:32 -0800] conn=2 op=11 UNBIND [18/Jan/2016:09:28:32 -0800] conn=2 op=11 fd=65 closed - U1 [18/Jan/2016:09:28:33 -0800] conn=3 fd=64 slot=64 connection from 10.178.6.56 to 10.21.0.98 [18/Jan/2016:09:28:33 -0800] conn=3 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext lastusn highestcommittedusn aci" [18/Jan/2016:09:28:33 -0800] conn=3 op=0 RESULT err=0 tag=101 nentries=1 etime=0 [18/Jan/2016:09:28:33 -0800] conn=3 op=1 UNBIND [18/Jan/2016:09:28:33 -0800] conn=3 op=1 fd=64 closed - U1 INSTALLATION CRASHED HERE BUT CLEARLY THE DS SERVICE ITSELF IS STILL RUNNING BECAUSE MORE LOGS HAPPEN BELOW [18/Jan/2016:09:29:11 -0800] conn=4 fd=64 slot=64 connection from 10.21.5.132 to 10.21.0.98 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Vobornik Sent: January-18-16 3:57 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists > look at the DS access log, you should see an ADD operation with RESULT > err=68 tag=105 According to code it's most likely cn=replica,cn=$DOMAIN_SUFFIX,cn=mapping tree,cn=config I don't know why it happens because installer should add it only if the entry does not exist. Would be worth to check the DS access log if base search(which should happen before the add) for the dn fails or succeeds. -- 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
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 01/18/2016 11:04 AM, Ludwig Krispenz wrote: On 01/18/2016 04:47 AM, Nathan Peters wrote: This is another issue I'm not sure how to debug or solve in 4.3.0. A failed replica installation left a replica with stuff in the tree, but not configured properly on the localhost. I did ipa-server-install --uninstall as suggested by the installation program and it deleted the local copy of the data, but did not clean the tree. Now all subsequent installations are failing with some duplicate entry error. All packages are up to date so this is not the pki-ca 10.2.6-13 fix issue. I've checked the whole tree for any references to the old copy of the master but I can't find them. That error log is typically unhelpful as it doesn't tell me what entry or where it is looking or finding a duplicate or I would just go delete it myself. look at the DS access log, you should see an ADD operation with RESULT err=68 tag=105 According to code it's most likely cn=replica,cn=$DOMAIN_SUFFIX,cn=mapping tree,cn=config I don't know why it happens because installer should add it only if the entry does not exist. Would be worth to check the DS access log if base search(which should happen before the add) for the dn fails or succeeds. 2016-01-18T03:29:55Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2016-01-18T03:29:55Z DEBUG Successfully updated nsDS5ReplicaId. 2016-01-18T03:29:55Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 447, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 437, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 413, in __setup_replica repl.setup_promote_replication(self.master_fqdn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 1589, in setup_promote_replication self.basic_replication_setup(r_conn, r_id, self.repl_man_dn, None) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 983, in basic_replication_setup self.replica_config(conn, replica_id, repldn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 467, in replica_config conn.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1442, in add_entry self.conn.add_s(str(entry.dn), list(attrs.items())) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 947, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG [error] DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, in execute for nothing in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 571, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2
Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
On 01/18/2016 04:47 AM, Nathan Peters wrote: This is another issue I'm not sure how to debug or solve in 4.3.0. A failed replica installation left a replica with stuff in the tree, but not configured properly on the localhost. I did ipa-server-install --uninstall as suggested by the installation program and it deleted the local copy of the data, but did not clean the tree. Now all subsequent installations are failing with some duplicate entry error. All packages are up to date so this is not the pki-ca 10.2.6-13 fix issue. I've checked the whole tree for any references to the old copy of the master but I can't find them. That error log is typically unhelpful as it doesn't tell me what entry or where it is looking or finding a duplicate or I would just go delete it myself. look at the DS access log, you should see an ADD operation with RESULT err=68 tag=105 2016-01-18T03:29:55Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2016-01-18T03:29:55Z DEBUG Successfully updated nsDS5ReplicaId. 2016-01-18T03:29:55Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 447, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 437, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 413, in __setup_replica repl.setup_promote_replication(self.master_fqdn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 1589, in setup_promote_replication self.basic_replication_setup(r_conn, r_id, self.repl_man_dn, None) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 983, in basic_replication_setup self.replica_config(conn, replica_id, repldn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 467, in replica_config conn.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1442, in add_entry self.conn.add_s(str(entry.dn), list(attrs.items())) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 947, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG [error] DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, in execute for nothing in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 571, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-pac
[Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists
This is another issue I'm not sure how to debug or solve in 4.3.0. A failed replica installation left a replica with stuff in the tree, but not configured properly on the localhost. I did ipa-server-install -uninstall as suggested by the installation program and it deleted the local copy of the data, but did not clean the tree. Now all subsequent installations are failing with some duplicate entry error. All packages are up to date so this is not the pki-ca 10.2.6-13 fix issue. I've checked the whole tree for any references to the old copy of the master but I can't find them. That error log is typically unhelpful as it doesn't tell me what entry or where it is looking or finding a duplicate or I would just go delete it myself. 2016-01-18T03:29:55Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2016-01-18T03:29:55Z DEBUG Successfully updated nsDS5ReplicaId. 2016-01-18T03:29:55Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 447, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 437, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 413, in __setup_replica repl.setup_promote_replication(self.master_fqdn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 1589, in setup_promote_replication self.basic_replication_setup(r_conn, r_id, self.repl_man_dn, None) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 983, in basic_replication_setup self.replica_config(conn, replica_id, repldn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 467, in replica_config conn.add_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1442, in add_entry self.conn.add_s(str(entry.dn), list(attrs.items())) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 947, in error_handler raise errors.DuplicateEntry() DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG [error] DuplicateEntry: This entry already exists 2016-01-18T03:29:55Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, in execute for nothing in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 571, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for noth
