[Date Prev][Date Next]
Re: OpenLDAP and DB2 backend.
From: "Roman Scherer" <firstname.lastname@example.org>
Sent: Tuesday, June 08, 2004 1:44 PM
Subject: OpenLDAP and DB2 backend.
> Hi list,
> i'm trying to use IBM's DB2 as a backend for OpenLDAP. I read the common
> documentation and tried it also with PostgreSQL, which worked fine. I
> can also connect and query the database with the "isql GOYALDAP -v"
> command. The ldap tables are also created and filled with the test data
> from the openldap ibm-db2 examples.
> But when i fire up the slapd I get the following debug output, which
> says, that something is wrong with the database connection:
> "SQLConnect() to database 'GOYALDAP' as user 'db2inst1' failed".
> Does someone has a clue what the problem is? Or does someone has a
> working configuration with OpenLDAP + IBM DB2 + unixODBC and can send it
> to me for studying?
> Thanks for help, Roman.
> ---- slapd debug messages ----------------------------------------------
> slapd startup: initiated.
> ==>backsql_db_open(): testing RDBMS connection
> backsql_db_open(): concat func not specified (use "concat_pattern"
> directive in slapd.conf)
> backsql_db_open(): setting 'upper(ldap_entries.dn)=upper(?)' as default
> backsql_db_open(): objectclass mapping SQL statement not specified (use
> "oc_query" directive in slapd.conf)
> backsql_db_open(): setting 'SELECT
FROM ldap_oc_mappings' by default
> backsql_db_open(): attribute mapping SQL statement not specified (use
> "at_query" directive in slapd.conf)
> backsql_db_open(): setting 'SELECT
eturn,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?' by default
> backsql_db_open(): entry deletion SQL statement not specified (use
> "delentry_query" directive in slapd.conf)
> backsql_db_open(): setting 'DELETE FROM ldap_entries WHERE id=?' by
> backsql_open_db_conn: SQLConnect() to database 'GOYALDAP' as user
> 'db2inst1' failed:
> Return code: -1
> Native error code: -1013
> SQL engine state:
> backsql_get_db_conn(): could not get connection handle -- returning NULL
> backsql_db_open(): connection failed, exiting
> backend_startup: bi_db_open(0) failed! (1)
> slapd shutdown: initiated
> slapd shutdown: freeing system resources.
> slapd stopped.
> connections_destroy: nothing to destroy.
> ---- /etc/odbc.ini -----------------------------------------------------
> Description = Goya DB2
> Driver = /opt/IBM/db2/V8.1/lib/libdb2.so
> Database = goyaldap
> Servername = localhost
> UserName = db2inst1
> Password = secret
> ---- /etc/odbcinst.ini -------------------------------------------------
> Trace = Yes
> TraceFile = /var/log/odbc-trace.log
> ---- /etc/ldap/slapd.conf ----------------------------------------------
> # include <filename>
> # Read additional configuration information from the given
> # file before continuing with the next line of the current file.
> include /etc/ldap/schema/core.schema
> include /etc/ldap/schema/cosine.schema
> include /etc/ldap/schema/nis.schema
> include /etc/ldap/schema/inetorgperson.schema
> # Schema check allows for forcing entries to
> # match schemas for their objectClasses's
> schemacheck on
> # pidfile <filename>
> # The (absolute) name of a file that will hold the slapd
> # server's process ID ( see getpid(2) ) if started without the
> # debugging command line option.
> pidfile /var/run/slapd/slapd.pid
> # argsfile <filename>
> # The (absolute) name of a file that will hold the slapd server's
> # command line options if started without the debugging command line
> # option.
> argsfile /var/run/slapd.args
> # loglevel <integer>
> # Specify the level at which debugging statements and
> # operation statistics should be syslogged (currently logged to the
> # syslogd(8) LOG_LOCAL4 facility). Log levels are additive, and
> # available levels are:
> # 1 trace function calls
> # 2 debug packet handling
> # 4 heavy trace debugging
> # 8 connection management
> # 16 print out packets sent and received
> # 32 search filter processing
> # 64 configuration file processing
> # 128 access control list processing
> # 256 stats log connections/operations/results
> # 512 stats log entries sent
> # 1024 print communication with shell backends
> # 2048 entry parsing
> loglevel 256
> # modulepath <pathspec>
> # Specify a list of directories to search for loadable modules.
> # Typically the path is colon-separated but this depends on the
> # operating system.
> modulepath /usr/lib/ldap
> # moduleload <filename>
> # Specify the name of a dynamically loadable module to load. The
> # filename may be an absolute path name or a simple filename. Non-
> # absolute names are searched for in the directories specified by the
> # modulepath option. This option and the modulepath option are only
> # usable if slapd was compiled with --enable-modules.
> #moduleload back_bdb
> moduleload back_sql
> # database <databasetype>
> # Mark the beginning of a new database instance
> # definition. <databasetype> should be one of bdb, dnssrv, ldap, ldbm,
> # meta, monitor, null, passwd, perl, shell, sql, or tcl, depending on
> # which backend will serve the database.
> database sql
> suffix "o=sql,c=RU"
> #rootdn "cn=root,o=sql,c=RU"
> #rootpw dub13+
> dbname GOYALDAP
> dbuser db2inst1
> dbpasswd dub13+
> subtree_cond "upper(ldap_entries.dn) LIKE CONCAT('%',?)"
> insentry_query "insert into ldap_entries (id,dn,oc_map_id,parent,keyval)
> values ((select max(id)+1 from ldap_entries),?,?,?,?)"
> upper_func "upper"
> upper_needs_cast "yes"
> create_needs_select "yes"
> has_ldapinfo_dn_ru "no"
I've never configured OpenLDAP to use db2 or any other ODBC as a backend.
I'll also note back-sql is considered experimental. However...
Debug db2 first. First things to check are:
* Does the user "db2inst1" exist on the server?
* Does the user "db2inst1" have access to the database called "GOYALDAP"?
Test the above questions with the following in sequence:
#> su - db2inst1
#> db2 "connect to GOYALDAP user db2inst1 using dub13+"
#> db2 "connect to GOYALDAP user db2inst1 using secret"
#> db2 "list tablespaces"
If the su - fails... well... enough said. If one the above connect commands
works, there are possible inconsistencies regarding passwords in your
slapd.conf and odbc.ini which you need to investigate:
>> dbpasswd dub13+ <<
Database = goyaldap
Servername = localhost
UserName = db2inst1
>> Password = secret <<
If neither of the above db2 connect commands work, your db2 instance/db is
misconfigured or does not exist... and that's definitely off topic for this