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 al
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://
ipa/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 alr
@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 A
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
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 steps, but
here is what I did in a test lab today:
1. Create a brand
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
On 01/22/2016 04:48 AM, 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
[root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b
"cn=config" "(aci=*)" aci
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base
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
On 01/22/2016 10:15 AM, Nathan Peters wrote:
[root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b "cn=config"
"(aci=*)" aci
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base
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
@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
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
Ok, here are the logs and console session from those searches as admin and as
the host on the new master against itself. Same result, nothing in there.
See my email reply to Rich I sent a few minutes ago for the directory manager
aci search results.
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
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
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
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
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=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
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
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
I assume you mean look at the DS log on the machine being installed?
There is no "err=68" anywhere in the access file :
[root@dc2-ipa-dev-van slapd-DEV-GLOBALRELAY-NET]# grep "err=68" access
[root@dc2-ipa-dev-van slapd-DEV-GLOBALRELAY-NET]#
Here is the last few lines of the latest attempt to
Nathan Peters wrote:
> I assume you mean look at the DS log on the machine being installed?\
I think he meant on the master that generated the prepare file. There
may be some left-over, unexpected entry.
rob
>
> There is no "err=68" anywhere in the access file :
>
> [root@dc2-ipa-dev-van
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
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
27 matches
Mail list logo
