[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: issue w/ LDAP that I have encountered

Pierangelo,
Comments follow :

Derek R.
---
derek.richardson@ieee.org
derekr42@gmail.com
derekr@tlc2.uh.edu
dmrichar@uh.edu
drichardson4@uh.edu
---
"As a rule, dictatorships guarantee safe streets and
terror of the doorbell. In democracy the streets
may be unsafe after dark, but the most likely visitor
in the early hours will be the milkman."
-- Adam Michnik



Pierangelo Masarati wrote:
On Thu, 2006-07-06 at 13:06 -0500, Derek R. wrote:
All,
I am setting up OpenLDAP w/ the back-sql ( using MySQL ) db module and GSSAPI authentication. I had the authentication working fine, as well as the SQL database created ( via the scripts included w/ the openldap-servers-sql RPM ) and everything seemed to be fine, except that when I submitted any queries ( for example :
ldapsearch -h ldap.ui.tlc2.uh.edu -p 389 -D "uid=ldap,cn=gssapi,cn=auth" -W -b"dc=tlc2,dc=uh,dc=edu"
), then I would get a no such object error ( something similar, I can't find it in my terminals now, it's been buried under mounds of strace and slapd -d1 output ).

Your idea of "everything seeming to be fine" looks a bit curious, then.
Guess I should have clarified that. I meant everything was fine w/ the GSSAPI authentication.
So I started testing out various parameters for queries and selects and whatnot in slapd.conf ( which, by the way, is here :
<snip>

I don't have time to go thru each of the issues I noted; let me just
tell you that half of the statements in your slapd.conf are pointless,
since they either appear too early (e.g. per-database only statements
before any database) or out of scope anyway (e.g. "index" in back-sql,
which supports none). I suggest you read the related man pages or the
admin guide to make sure you understand what each statement means and
what's supposed to do. Note that you'll get all of them pointed out if
you run with "-d config"
I already caught the index thing already, and I have read the man pages and the admin guides. The file was a bit sloppy, I've been trying quite a few things, and have cleaned it up already. Thanks for the tip about '-d config'.
Anyways, I removed the statement ( which, I realized, isn't in the above file :

has_ldapinfo_dn_ru no

This should __always__ be present, unfortunately.
) from the file and then restarted slapd. Now, after this, when I repeated the above command, I get :

[root@uiln001 bin]# ldapsearch -h ldap.ui.tlc2.uh.edu -p 389 -D "uid=ldap,cn=gssapi,cn=auth" -W -b"dc=tlc2,dc=uh,dc=edu"
Enter LDAP Password:
SASL/GSSAPI authentication started
SASL username: root/admin@TLC2.UH.EDU
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <dc=tlc2,dc=uh,dc=edu> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

ldap_result: Can't contact LDAP server (-1)

and the slapd process dies. Okay, that's what debugging mode is for, right? Well, once I run :

slapd -h ldap:/// ldaps:/// -u ldap -d1

"-d 1" is "almost" pointless unless you know what to do with it.  I
suggest you first go with something very smooth, like "-d stats", so
that you see very basic logging.  Then, when you locate where the
relevant problem is, you can increase the debug level ("increase" means
"combine" different levels so that you get a useful blend of different
logging subsystems; for example, "-d stats,args,trace" is appropriate
for most needs; I wouldn't go "-d packets" unless you really know what
you're doing.  Unless you intended to enable as much debug as possible;
in that case, it's "-d -1".

Once again, I appreciate the tips. I'm new to LDAP, and under a lot of time pressure to get a basic implementation going, I swear I'm generally not this scrambled ;). 
slapd will not crash, just returns :

ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Permission denied)

to my queries, as above. That's interesting, since when I run it w/out the -d1, it seems to authenticate properly and then crash.

Still no clue.


==>backsql_dn2id("dc=tlc2,dc=uh,dc=edu") matched expected
backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn_ru=?"
backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): upperdn="UDE=CD,HU=CD,2CLT=CD"
backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn_ru=?", "UDE=CD,HU=CD,2CLT=CD"):
Return code: -1
Native error code: 1054
SQL engine state: S0022
Message: [unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.22]Unknown
column 'dn_ru' in 'where clause'
Segmentation fault

There you go: unless you have the column "dn_ru" in your database's
ldap_entries(), you're off. Well, the reason for the crash is unknown;
I suggest you file an ITS after reading and following instructions at
<http://www.openldap.org/faq/data/cache/56.html>
I will, since behavior exhibited is nothing short of bizarre. Re-creating the database got rid of the behavior.
That's weird, it appears as if running as the ldap user, there's something we can't access, yet as root, we get it and it causes a SEGFAULT. Hmm...here's what strace

Don't strace when you can gdb. Follow instructions above and you might
get help and support.
I like strace to just get a very simple look at what is causing a crash. Gdb is a lot more accurate, however, sometimes all what you need is a clue as to what's wrong. It's like the difference between lighting up a room and shining a flashlight in it : if you're taking an inventory of the room, you need it lit, if you're just looking to see if it's full of boxes or wheels, a flashlight will do. 
What the strace and slapd -d1 output seems to point to is that the

has_ldapinfo_dn_ru      no

statement fried something in my SQL database. From what I can find online, it appears that the statement handles how back-sql maps queries into the database, but I couldn't find one definitive answer ( the most complete answer I found is on Microsoft's website, and I hardly think that would be very compatible w/ OpenLDAP's implementation, unless MS has really changed their definition of the word 'standards' ). Could someone please explain this to me, and why it is now causing slapd to alternately crash or returns unauthorized? Also, any hints as to what I was doing wrong in the first place that I wasn't able to find any of the LDAP tables in the first place would be much appreciated.

During its long and troublesome life, back-sql was modified (not sure by
whom, check the CVS) to support "optimized" DN operations by adding a
column in ldap_entries that contained the DN uppercased and reversed, so
that subtree searches could be done by running things like
"MOC=CD,ELPMAXE=CD,%" instead of "UPPER('%,dc=example,dc=com')" and
similar.  Since no-one wants to build and maintain anything like that in
their ldap_entries table, you need to tell back-sql it's not available
(although it could be inferred at startup by reading the schema of the
table; you may submit a feature request...).

I know this is not going to fix your problem, but at least you know why
you wasted so much time. If we'd ever vote for anything like that, I'd
vote for trimming all that portion of code out of back-sql.
Thanks for the explanation, at least I know what the statement is meant to do. Since the statement seems to be required, I will try to sort it out or possibly shift to using bdb.
Thanks again,
Derek R. 
p.




Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309 Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------
begin:vcard
fn:Derek Richardson
n:Richardson;Derek
org:University of Houston;Texas Learning and Computation Center
adr:;;218 Philip G. Hoffman Hall;Houston;Texas;77204-3058;United States of America
email;internet:derekr@tlc2.uh.edu
title:Linux Cluster Administrator
tel;work:7137433361
tel;fax:7137433376 
tel;home:7138191303
tel;cell:7138191303
x-mozilla-html:TRUE
url:http://www.tlc2.uh.edu
version:2.1
end:vcard