Description of problem: running ipa-defaultoptions --maxusername=12 results in a cannot contact ldap server error. Version-Release number of selected component (if applicable): ipa-server-1.2.1-5.fc11.x86_64 How reproducible: everytime Steps to Reproduce: 1. install ipa-server 2. run ipa-defaultoptions --maxusername=12 Actual results: [root@management ~]# ipa-defaultoptions --maxusername=12 /usr/lib/python2.6/site-packages/ipa/ipaerror.py:30: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message /usr/sbin/ipa-defaultoptions:174: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 print "%s" % (e.message) A database error occurred: Can't contact LDAP server: Expected results: command succeeding Additional info: ldapsearches like the ones below all work fine directly against 389-ds-base It seems like prior to the rename/build last week all was working fine, but I can query ldap manually fine so that points me to ipa. ldapsearch -h 127.0.0.1 -b cn=ipaConfig,cn=etc,dc=jboggs,dc=com -x ldapsearch -h 127.0.0.1 -b cn=kerberos,dc=jboggs,dc=com -x From /var/log/dirsrv/slapd-JBOGGS-COM/errors: [20/Aug/2009:16:03:36 -0400] - 389-Directory/1.2.1 B2009.224.1954 starting up [20/Aug/2009:16:03:36 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [20/Aug/2009:16:03:36 -0400] - Listening on All Interfaces port 636 for LDAPS requests [20/Aug/2009:16:03:40 -0400] - PR_Write(70) Netscape Portable Runtime error -5991 (I/O function error.) [20/Aug/2009:16:06:49 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.) [20/Aug/2009:16:07:35 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.) [20/Aug/2009:16:11:05 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.) [20/Aug/2009:16:11:08 -0400] - PR_Write(69) Netscape Portable Runtime error -5991 (I/O function error.)
Did some more testing, this version of directory server works: fedora-ds-base-1.2.0-4.fc11.x86_64.rpm if I rip 389-ds-base out and put fedora-ds-base back in. Feel free to move this to 389 if need be
It is failing trying to get the schema so it can validate the objectclasses in the configuration. This only happens when doing a SASL authenticated query: These work: % ldapsearch -x -b "cn=schema" "(objectclass=*)" "* aci" % ldapsearch -x -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" -W -b "cn=schema" "(objectclass=*)" "* aci" This fails: % ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)" "* aci" Note that other GSSAPI-based queries work fine. % ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=example,dc=com" "uid=admin" dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com objectClass: top objectClass: person objectClass: posixAccount ...
Can you attach directory server access log excerpts from the failed attempt and a successful attempt? Anything interesting in the directory server errors log?
Created attachment 358257 [details] snippet of access log The first request is an anonymous bind searching cn=schema. The second is a GSSAPI bind searching cn=schema. The only thing logged in errors is: [21/Aug/2009:11:08:13 -0400] - PR_Write(65) Netscape Portable Runtime error -5991 (I/O function error.)
So SASL/GSSAPI BIND and search works fine if you're not searching cn=schema? Can you search the root DSE "" or cn=config or cn=monitor? I'm wondering if there is some weird problem with SASL and the config suffixes.
Yes, all 3 of those work: % ldapsearch -Y GSSAPI -b "cn=config" "(objectclass=*)" % ldapsearch -Y GSSAPI -b "cn=monitor" "(objectclass=*)" % ldapsearch -Y GSSAPI -b "" -s base "(objectclass=*)" This still fails: % ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)" ldap_result: Can't contact LDAP server (-1) Note that I continued messing with this and if I specify objectclasses as the attribute to retrieve it works. It fails if I try to get matchingRules or attributetypes.
mea culpa - the sasl io layer changes I made broke this - working on a fix now
Created attachment 358289 [details] patch
Pushed to master commit 132f46e98c2a6bdaf1248952c3bf90f2d32fff08 Author: Rich Megginson <rmeggins> Date: Thu Aug 20 12:59:08 2009 -0600 Retry SASL writes if buffer not fully sent
pushed to 1.2 branch
this is the 1.2 branch commit: commit 0d1f300d0e4e41d96f3022c5c80bfcb34507f5b5 Author: Rich Megginson <rmeggins> Date: Thu Aug 20 12:59:08 2009 -0600
*** Bug 544927 has been marked as a duplicate of this bug. ***
The oVirt docs at http://ovirt.org/install-instructions.html refer to this bug as an installation blocker, and instruct one to instead install an old F11 package from Koji. Although this is marked as "modified" rather than resolved or closed, it looks like it's actually committed and in current Fedora. Is that correct, or is there still something to do here? Thanks!
(In reply to comment #13) > The oVirt docs at http://ovirt.org/install-instructions.html refer to this bug > as an installation blocker, and instruct one to instead install an old F11 > package from Koji. Although this is marked as "modified" rather than resolved > or closed, it looks like it's actually committed and in current Fedora. Is that > correct, or is there still something to do here? Thanks! MODIFIED means the bug has been fixed and released in Fedora, but the bug has not been through "official" Red Hat QA.
fix verified Fedora 11 versions: ipa-server-1.2.2-3.fc12.i686 389-ds-base-1.2.5-1.fc12.i686 1. install ipa-server 2. # ipa-defaultoptions --maxusername=12 Update successful. # ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)" SASL/GSSAPI authentication started SASL username: admin.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL # # schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1