Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Starting OpenLDAP: slapd - failed. The operation failed but no output was produced. For hints on what went wrong please refer to the system's logfiles (e.g. /var/log/syslog) or try running the daemon in Debug mode like via "slapd -d 16383" (warning: this will create copious output).
From syslog:
Jul 18 08:08:01 maude slapd[27079]: main: TLS init def ctx failed: -1 Jul 18 08:08:01 maude slapd[27079]: slapd stopped. Jul 18 08:08:01 maude slapd[27079]: connections_destroy: nothing to destroy.
If I then try to start slapd using slapd -d 16383, it seems to start up fine, but can't read the database.
maude:/etc/ldap# ldapsearch -x "uid=maria"
<output truncated to what I think is the pertinent info>
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=32 matched="" text="" send_ldap_response: msgid=2 tag=101 err=32 ber_flush: 14 bytes to sd 12 0000: 30 0c 02 01 02 65 07 0a 01 20 04 00 04 00 0....e... .... # search result search: 2 result: 32 No such object
Any ideas, or any other troubleshooting to try?
thanks, maria
I have had some success. Slapd seems to be running, but it appears slapadd did not add things to the database:
maude:/etc/ldap# ldapsearch -x "uid=maria" # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=maria # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1 maude:/etc/ldap# ldapsearch -x "uid=ichbin" # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=ichbin # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1 maude:/etc/ldap# ldapadd -f ldif ldap_sasl_interactive_bind_s: No such attribute (16)
Any ideas? thanks again, maria
Augh. scratch that last email. That isn't what i meant to do. Here is what I did (and meant it. ;-))
I stopped slapd, and tried to put stuff in the database:
maude:/etc/ldap# slapadd -v -l ldif
got no error messages, restarted slapd, tried to search on something that should be there, but couldn't find it:
maude:/etc/ldap# ldapsearch -x "uid=ichbin" # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=ichbin # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
Any ideas why I can't put stuff in the database? And any ideas why I have to start slapd using slapd instead of /etc/init.d/slapd start? I'm still pretty new at this stuff obviously...
thanks, maria
Jul 18 08:08:01 maude slapd[27079]: main: TLS init def ctx failed: -1
[but]
If I then try to start slapd using slapd -d 16383, it seems to start up fine, but can't read the database.
Are you starting it with -d at the command line (perhaps as root), but the init script uses -u slapd or similar non-root uid? It's very odd to me tha the TLS complaint doesn't show up with -d, and I wonder about certificate permissions.
I'd try slaptest and/or slapd -d config to make sure that's all sane, again making sure to run it as the slapd user.
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
Import the ldap database
sysserv0 ~ # slapadd -l /home/Administrator/ldap1.20061006.ldif sysserv0 ~ # chown ldap:ldap /var/lib/openldap-data/*
Start the destination ldap server
sysserv0 ~ # /etc/init.d/slapd start
John
Hello!
On Wed, Jul 18, 2007 at 05:45:06PM -0700, Maria McKinley wrote:
Augh. scratch that last email. That isn't what i meant to do. Here is what I did (and meant it. ;-))
I stopped slapd, and tried to put stuff in the database:
maude:/etc/ldap# slapadd -v -l ldif
got no error messages, restarted slapd, tried to search on something that should be there, but couldn't find it:
maude:/etc/ldap# ldapsearch -x "uid=ichbin"
[...]
# search result search: 2 result: 32 No such object
# numResponses: 1
Any ideas why I can't put stuff in the database? And any ideas why I have to start slapd using slapd instead of /etc/init.d/slapd start? I'm still pretty new at this stuff obviously...
A possible reason for the first point is that you have declared an index on "uid". If you have any indices declared and slapadd a database then you have to slapindex it as well. OpenLDAP will not regenerate a missing index on its own.
The log lines before those you posted in your first mail would hint at an index miss if I'm barking up the right tree here. Anyway, slapindex'ing the cold(!) database cannot hurt.
The second point sounds like a file permission problem to me, especially since the error occurs during TLS context(?) initialization(?). Makes me think of a private key that "root" is allowed to read but "openldap", which is the user that slapd runs under in the default Debian installation, is not. I suggest that you take a look at the certificate / CA certificate / private key file permissions. You may end up having to use ACLs on the key file to permit slapd reading it.
I don't know how familiar you are with strace but you might just syscall trace the startup skript and watch out for the deadly EACCESS.
Regards, Ralph Rößner
On Wed, Jul 18, 2007 at 05:45:06PM -0700, Maria McKinley wrote:
maude:/etc/ldap# slapadd -v -l ldif
got no error messages, restarted slapd, tried to search on something that should be there, but couldn't find it:
maude:/etc/ldap# ldapsearch -x "uid=ichbin"
Typically you specify the base to start at. Something like dc=u,dc=washington,dc=edu This will find your user if he/she is located at uid=ichbin,o=office,ou=users,dc=u,dc=washington,dc=edu
# base <> with scope subtree
Set the base and this will start working. The base should be whatever you have set as your basedn in your slapd.conf file.
# egrep ^suffix /etc/openldap/slapd.conf suffix "dc=ivenue,dc=net"
The following example search has been sanitized but it shows how not specifying a base DN to search causes it to not know where to look (and so it looks nowhere).
[todd@tlyons ~/git/IV]$ ldapsearch -x uid=user@domain.com -h admin51 # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=user@domain.com # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1 [todd@tlyons ~/git/IV]$ ldapsearch -x uid=user@domain.com -h provision -b dc=ivenue,dc=net # extended LDIF # # LDAPv3 # base <dc=ivenue,dc=net> with scope subtree # filter: uid=user@domain.com # requesting: ALL #
# user@domain.com, users, ivenue.net dn: uid=user@domain.com,ou=users,dc=ivenue,dc=net gidNumber: 1000 uidNumber: 1008 shadowMax: 99999 objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: account objectClass: CourierMailAccount uid: user@domain.com gecos:: IA== shadowLastChange: 11740 cn:: IA== homeDirectory: /netapp1/mail/maildirs/user@domain.com description: customerNumber->58144 shadowWarning: 7 mail: user@domain.com loginShell: /bin/sh quota: 314572800S
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Ralph Rößner wrote:
Hello!
On Wed, Jul 18, 2007 at 05:45:06PM -0700, Maria McKinley wrote:
Augh. scratch that last email. That isn't what i meant to do. Here is what I did (and meant it. ;-))
I stopped slapd, and tried to put stuff in the database:
maude:/etc/ldap# slapadd -v -l ldif
got no error messages, restarted slapd, tried to search on something that should be there, but couldn't find it:
maude:/etc/ldap# ldapsearch -x "uid=ichbin"
[...]
# search result search: 2 result: 32 No such object
# numResponses: 1
Any ideas why I can't put stuff in the database? And any ideas why I have to start slapd using slapd instead of /etc/init.d/slapd start? I'm still pretty new at this stuff obviously...
A possible reason for the first point is that you have declared an index on "uid". If you have any indices declared and slapadd a database then you have to slapindex it as well. OpenLDAP will not regenerate a missing index on its own.
Not quite. slapadd will generate indices for everything that was configured at the time of the slapadd. You only need to run slapindex if you define a new index on an existing DB.
The log lines before those you posted in your first mail would hint at an index miss if I'm barking up the right tree here. Anyway, slapindex'ing the cold(!) database cannot hurt.
Well... It generally performs twice as much DB I/O as slapadd, since it must read every entry in order to generate the index data. In that respect, it can be painfully slow.
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
thanks, maria
Import the ldap database
sysserv0 ~ # slapadd -l /home/Administrator/ldap1.20061006.ldif sysserv0 ~ # chown ldap:ldap /var/lib/openldap-data/*
Start the destination ldap server
sysserv0 ~ # /etc/init.d/slapd start
John
On 7/19/07, Maria McKinley parody@u.washington.edu wrote:
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
tar xf file.tar named_file will extract named_file FROM file.tar.
It's another way of saying "backup & restore your DB_CONFIG file." http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107... http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107...
On 7/19/07, matthew sporleder msporleder@gmail.com wrote:
On 7/19/07, Maria McKinley parody@u.washington.edu wrote:
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
tar xf file.tar named_file will extract named_file FROM file.tar.
It's another way of saying "backup & restore your DB_CONFIG file." http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107... http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107...
I see, I should have read the tar error message more carefully. I have no DB_CONFIG file in my old database, so I think this can't be the problem unless the new version of ldap requires it.
~maria
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
Import the ldap database
sysserv0 ~ # slapadd -l /home/Administrator/ldap1.20061006.ldif sysserv0 ~ # chown ldap:ldap /var/lib/openldap-data/*
In my old database, everything in /var/lib/ldap was owned by root. This is true in the new database as well, and there appears to be no user ldap.
~maria
Start the destination ldap server
sysserv0 ~ # /etc/init.d/slapd start
John
On 7/19/07, Maria McKinley parody@u.washington.edu wrote:
On 7/19/07, matthew sporleder msporleder@gmail.com wrote:
On 7/19/07, Maria McKinley parody@u.washington.edu wrote:
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
On 7/18/07, Maria McKinley parody@u.washington.edu wrote:
Hi there,
I am trying to move my ldap to a new machine to upgrade from openldap2.2 to openldap2.3. I moved all of my config files and created new certificates, but I am having difficulties. I am running on Debian, and if I start slapd by /etc/init.d/slapd start, I get:
Did you export the database with slapcat and reimport it with slapadd?
Here are the instructions I use (taken from a local wiki):
Export the ldap database to an ldif file
This is done using slapcat.
[root@ldap1 root]# slapcat > /home/Administrator/ldap1.20061006.ldif
Stop the destination ldap server
sysserv0 ~ # /etc/init.d/slapd stop
Backup the old ldap database folder
We can use tar here.
sysserv0 ~ # tar cjf slapd.tar.bz2 /var/lib/openldap-data/
Prepare the ldap folder
sysserv0 ~ # rm /var/lib/openldap-data/* sysserv0 ~ # tar xjf /root/slapd.tar.bz2 var/lib/openldap-data/DB_CONFIG
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
tar xf file.tar named_file will extract named_file FROM file.tar.
It's another way of saying "backup & restore your DB_CONFIG file." http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107... http://www.openldap.org/faq/index.cgi?_highlightWords=db_config&file=107...
I see, I should have read the tar error message more carefully. I have no DB_CONFIG file in my old database, so I think this can't be the problem unless the new version of ldap requires it.
It's not required, just recommended. Since /etc/init.d/slapd is not shipped with openldap, there's really no way to tell on this list why it isn't working. If openldap is working when you start it manually, then it's a problem with that script and not with openldap. Try searching for links on shell scripting and troubleshooting.
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
Ahh sorry. That step is unnecessary as it was meant to backup whatever existing ldap database was on the new server. In your case this should be empty.
John
On 7/19/07, John Drescher drescherjm@gmail.com wrote:
I don't get this. You tar the entire openldap-data folder, but then empty it into a new directory called DB_CONFIG? This step I was not doing, so it must be what is wrong, but it doesn't make sense to me.
Ahh sorry. That step is unnecessary as it was meant to backup whatever existing ldap database was on the new server. In your case this should be empty.
John
Well, I've figured out that my problem (at least part of my problem) is definitely my certificates, which I don't know how to fix yet. I know it is outside the scope of this mailing list, but thought I'd mention what I figured out the problem to be for future googlers.
thanks for the help, maria
openldap-software@openldap.org
-
Aaron Richton -
Howard Chu -
John Drescher -
Maria McKinley -
matthew sporleder -
Ralph Rößner -
Todd Lyons