Hide Forgot
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:
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 ";".
bind-dyndb-ldap.x86_64 0:1.1.0-0.6.a1.20120228T1006z.el6
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.
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).
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?
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.
(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.
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.
closing as worksforme