Bug 798381 - ipa-client-install failing with "ipaserver.testrelm.com is not an IPA v2 Server."
ipa-client-install failing with "ipaserver.testrelm.com is not an IPA v2 Serv...
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa (Show other bugs)
6.3
Unspecified Unspecified
urgent Severity unspecified
: rc
: ---
Assigned To: Rob Crittenden
IDM QE LIST
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-28 13:50 EST by Jenny Galipeau
Modified: 2012-05-09 10:42 EDT (History)
3 users (show)

See Also:
Fixed In Version: ipa-2.2.0-9.el6
Doc Type: Bug Fix
Doc Text:
No documentation needed.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-09 10:42:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jenny Galipeau 2012-02-28 13:50:02 EST
Description of problem:

With latest builds can not install ipa client


# ipa-client-install --domain=testrelm.com --realm=TESTRELM.COM -p admin -w mysecret -U --server=ipaserver.testrelm.com
ipaserver.testrelm.com is not an IPA v2 Server.

<rcrit> Invalid ACL element: any;
<rcrit> I"m not sure this is an ipa server problem. I'll see if I can find a workaround

<jgalipea> from the client I can ping the outside world ... so ipaserver.testrelm.com is forwarding non-authoritative requests ...

<rcrit> it's not allowing queries I presume
<rcrit> ipa dnszone-mod testrelm.com --delattr idnsallowquery=any; && ipa dnszone-mod testrelm.com --delattr idnsallowtransfer=none;
<rcrit> jgalipea, that is how I got resolution working again, along with a named restart



Version-Release number of selected component (if applicable):
ipa-server-2.2.0-102.20120228T1040zgit449c71c.el6.x86_64
ipa-client-2.2.0-102.20120228T1040zgit449c71c.el6.x86_64

How reproducible:


Steps to Reproduce:
1. 
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 Martin Kosek 2012-02-29 03:54:26 EST
What is the version of bind-dyndb-ldap? It looks like you have the old RHEL build where idnsAllowQuery was still a multivalued LDAP attribute where ACL elements were added separately. The new version have all ACL elements as one attribute value, separated with ";".
Comment 3 Jenny Galipeau 2012-02-29 07:02:49 EST
bind-dyndb-ldap.x86_64 0:1.1.0-0.6.a1.20120228T1006z.el6
Comment 4 Martin Kosek 2012-02-29 07:43:34 EST
Thanks. I see I was right, ACL format is fixed in bind-dyndb-ldap >= 1.1.0-0.8.a2. You would need an updated version of this package.
Comment 6 Rob Crittenden 2012-02-29 09:28:51 EST
We'll need to reset the Conflicts version number to whatever the build is as well (Conflicts because we don't require bind-dyndb-ldap to be installed but if it is we use this to require a specific version).
Comment 8 Rob Crittenden 2012-04-18 16:30:31 EDT
We have added a Conflicts to require a minimum n-v-r on bind-dyndb-ldap as part of BZ 805814. Is this problem still occurring?
Comment 9 Jenny Galipeau 2012-04-19 10:44:31 EDT
I have not seen this error in quite sometime.  I suggest we close as works for me and if we come across it again we can re-open.
Comment 12 Martin Kosek 2012-04-19 14:07:27 EDT
(In reply to comment #9)
> I have not seen this error in quite sometime.  I suggest we close as works for
> me and if we come across it again we can re-open.

Yes, this was just an issue of in-compatibility between ipa and bind-dyndb-ldap which should no longer occur because of ipa package requirements. +1 for closing as WORKSFORME.
Comment 14 Martin Kosek 2012-04-24 09:31:50 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed.
Comment 15 Namita Soman 2012-05-09 10:42:00 EDT
closing as worksforme

Note You need to log in before you can comment on or make changes to this bug.