[Date Prev][Date Next]
Re: issue w/ LDAP that I have encountered
Comments follow :
"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:Guess I should have clarified that. I meant everything was fine w/ the
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"
), 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.
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
So I started testing out various parameters for
queries and selects and whatnot in slapd.conf ( which, by the way, is here :
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"
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 ;).
Anyways, I removed the statement
( which, I realized, isn't in the above file :
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
# 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".
I will, since behavior exhibited is nothing short of bizarre.
Re-creating the database got rid of the behavior.
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"): error executing query ("SELECT
id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn_ru=?",
Return code: -1
Native error code: 1054
SQL engine state: S0022
Message: [unixODBC][MySQL][ODBC 3.51
column 'dn_ru' in 'where clause'
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
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.
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.
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.
What the strace and slapd -d1 output seems to point to is that the
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.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA
org:University of Houston;Texas Learning and Computation Center
adr:;;218 Philip G. Hoffman Hall;Houston;Texas;77204-3058;United States of America
title:Linux Cluster Administrator