Hello All,
I've got a bit of a problem.... Management chose a software product that depends on OpenLDAP's SLAPD service and had us put it into production without our quite understanding the software well enough to be clueful. The deployment is across virtual and real servers, the virtual servers handling the web stack and other user-oriented functionality while "real" servers handle data management. Regarding the data management, one system was chosen as a replication master, and another as slave, but being understaffed, we never quite got the replication of the OpenLDAP data configured when, today, some serious networking problems cropped up.
The symptom is that we can establish an OpenLDAP (slapd) connection from the virtual side to the master, and a postgres connection - our RDBMS, but we can't get the rest of our primary application to connect properly so it's down. And it is absolutely not clear what's wrong with the master anyway. I can't get to the physical hardware because it's off in some data center somewhere that the founder located near him - and he's off traveling. So, we're "dead in the water."
I was thinking that we might salvage the situation by dumping the data from the Postgres and OpenLDAP databases and restoring them to the slave system - promoting it to master - and while I've succeeded in moving over the Postgres data, I haven't a CLUE how to get started unloading and reloading the OpenLDAP data.
...I'm very competent with most things related to computing but I am _completely_ inexperienced with OpenLDAP. I've never issued any commands to or with OpenLDAP / slapd and have no idea what's normal for dealing with it. Are there dump and reload utilities? Any and all pointers / help GREATLY appreciated.
Richard
Dump: slapcat -l [ldif file]
Add from dump, with slapd off: slapadd -l [ldif file]
If you're using BDB (typical backend), you can move the contents of the dbdir specified by your config first.
- chris
Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Thu Jan 06 18:32:15 2011 Subject: Emergency recovery strategy needed by novice
Hello All,
I've got a bit of a problem.... Management chose a software product that depends on OpenLDAP's SLAPD service and had us put it into production without our quite understanding the software well enough to be clueful. The deployment is across virtual and real servers, the virtual servers handling the web stack and other user-oriented functionality while "real" servers handle data management. Regarding the data management, one system was chosen as a replication master, and another as slave, but being understaffed, we never quite got the replication of the OpenLDAP data configured when, today, some serious networking problems cropped up.
The symptom is that we can establish an OpenLDAP (slapd) connection from the virtual side to the master, and a postgres connection - our RDBMS, but we can't get the rest of our primary application to connect properly so it's down. And it is absolutely not clear what's wrong with the master anyway. I can't get to the physical hardware because it's off in some data center somewhere that the founder located near him - and he's off traveling. So, we're "dead in the water."
I was thinking that we might salvage the situation by dumping the data from the Postgres and OpenLDAP databases and restoring them to the slave system - promoting it to master - and while I've succeeded in moving over the Postgres data, I haven't a CLUE how to get started unloading and reloading the OpenLDAP data.
...I'm very competent with most things related to computing but I am _completely_ inexperienced with OpenLDAP. I've never issued any commands to or with OpenLDAP / slapd and have no idea what's normal for dealing with it. Are there dump and reload utilities? Any and all pointers / help GREATLY appreciated.
Richard
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
On Fri, 7 Jan 2011, Chris Jacobs wrote:
Dump: slapcat -l [ldif file]
Add from dump, with slapd off: slapadd -l [ldif file]
If you're using BDB (typical backend), you can move the contents of the dbdir specified by your config first.
- chris
THANK YOU, Chris.
However, I can't login to the troubled server. When I try and login via ssh, I get the password prompt, then nothing and it eventually times out with simply, "connection lost."
I do have a connection from our application server to slapd which is visible via 'netstat -lT' as ldaps ("ESTABLISHED") - I presume this is via some kind of library available via Java as it's a EJB based application.
Further thoughts? Can I harness the ability to connect to get the data out even when I don't know the first thing about the data I want to fetch, similar to the slapcat command above?
Thanks again for any all help, comments, etc, Richard
Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- Sent: Thu Jan 06 18:32:15 2011 Subject: Emergency recovery strategy needed by novice
Hello All,
I've got a bit of a problem.... Management chose a software product that depends on OpenLDAP's SLAPD service and had us put it into production without our quite understanding the software well enough to be clueful. The deployment is across virtual and real servers, the virtual servers handling the web stack and other user-oriented functionality while "real" servers handle data management. Regarding the data management, one system was chosen as a replication master, and another as slave, but being understaffed, we never quite got the replication of the OpenLDAP data configured when, today, some serious networking problems cropped up.
The symptom is that we can establish an OpenLDAP (slapd) connection from the virtual side to the master, and a postgres connection - our RDBMS, but we can't get the rest of our primary application to connect properly so it's down. And it is absolutely not clear what's wrong with the master anyway. I can't get to the physical hardware because it's off in some data center somewhere that the founder located near him - and he's off traveling. So, we're "dead in the water."
I was thinking that we might salvage the situation by dumping the data from the Postgres and OpenLDAP databases and restoring them to the slave system - promoting it to master - and while I've succeeded in moving over the Postgres data, I haven't a CLUE how to get started unloading and reloading the OpenLDAP data.
...I'm very competent with most things related to computing but I am _completely_ inexperienced with OpenLDAP. I've never issued any commands to or with OpenLDAP / slapd and have no idea what's normal for dealing with it. Are there dump and reload utilities? Any and all pointers / help GREATLY appreciated.
Richard
On 1/7/11 8:17 PM, Richard Troy wrote:
On Fri, 7 Jan 2011, Chris Jacobs wrote:
Dump: slapcat -l [ldif file]
Add from dump, with slapd off: slapadd -l [ldif file]
If you're using BDB (typical backend), you can move the contents of the dbdir specified by your config first.
- chris
THANK YOU, Chris.
However, I can't login to the troubled server. When I try and login via ssh, I get the password prompt, then nothing and it eventually times out with simply, "connection lost."
I do have a connection from our application server to slapd which is visible via 'netstat -lT' as ldaps ("ESTABLISHED") - I presume this is via some kind of library available via Java as it's a EJB based application.
Further thoughts? Can I harness the ability to connect to get the data out even when I don't know the first thing about the data I want to fetch, similar to the slapcat command above?
*if* you can connect to the LDAP server, then you can also fetch all the Data as LDIF. You just have to know the admin user (and password) to be sure you get all the data from the LDAP server.
You'll then just have to inject them in your slave server.
Now, there are more than just the entries, you'll have to deal with the server configuration : schemas, index, etc.
If you just want to get back the data, then using a tool like Apache Directory Studio, LdapBrower, JExplore, etc could help. They all allows you to connect using only LDAP, and get back the data. You can even use a command line tool like ldapsearch, which can be installed easily - if it's not already present.
Hope it helps, because your story sounds like a nightmare ...
Further thoughts? Can I harness the ability to connect to get the
data out
even when I don't know the first thing about the data I want to
fetch,
similar to the slapcat command above?
*if* you can connect to the LDAP server, then you can also fetch all the Data as LDIF. You just have to know the admin user (and password) to be sure you get all the data from the LDAP server.
You'll then just have to inject them in your slave server.
Now, there are more than just the entries, you'll have to deal with the server configuration : schemas, index, etc.
If you just want to get back the data, then using a tool like Apache Directory Studio, LdapBrower, JExplore, etc could help. They all allows you to connect using only LDAP, and get back the data. You can even use a command line tool like ldapsearch, which can be installed easily - if it's not already present.
Hope it helps, because your story sounds like a nightmare ...
Also man ldapsearch(1)
ldapsearch -x -LLL -H 'ldap://hostname/' -d 'cn=Manager,dc=example,dc=com' -w password '(objectClass=*)' * + > backup.ldiff
change the ldap:// to ldaps:// if needed
the cn=Manager,dc=example,dc=com will need to be your manager/admin user DN (defined in your slapd config, cn=Manager is default/typical, dc=example,dc=com is your root/base DN, probably your company's domain broken into components)
if you use -W to have it prompt for pass, the prompt will get redirected with stdout into your file, so type it when its sitting on the newline.
This will also give an ldif that should be able to be imported via slapadd (with slapd stopped, see ldapadd/ldapmodify for doing stuff while its running). As this is the whole DB, you probably want to move your ldap db out of the way first if the target system already had a running slapd (mv /var/lib/ldap /var/lib/ldap.bak for debian defaults), mkdir a new ldap data dir and cp your old DB_CONFIG file into it (if you don't have one of these, don't worry, it will work without it but slower).
-T
SSH login: Sounds like local console access will be required then - and hope you can login as root. You don't mention if the LDAP server is a VM or not - if it is, then local console access /should/ be trivial. If all else fails, as long as you have console access, then you can boot to single user mode - slapcat should still work. Of course, it could be that the entire thing is hosed - at which point you'd need to revert to backups. Note: grab the config too - find where the slapd.conf file and/or slapd.d directory are and copy them off too. Use strings /path/to/slapd |grep slapd - and look for 2 lines, one references slapd.d and the next slapd.conf - those are the conf files. If you don't know the path to the binaries, examine the init script (typically /etc/init.d/slapd or /etc/init.d/ldap) to locate it. Of course, ALL of this requires local shell access.
Existing connection: /IF/ your app has read access to the entire LDAP db, and it will allow you to fetch all data (not just the typical ones - there's operational/meta data you'll want too), then perhaps that will work. I highly suspect that it doesn't have READ access to ALL data, nor that it will do random queries so as to return everything. And then you'll want to make sure you get the data in a usable format, ie, LDIF format.
- chris
PS: Disaster recovery planning: get and test backups. Prevent outages from affecting service through removing single point of failures - for OpenLDAP this means some sort of multi-master model; I'm a fan of mirror master pair behind a VIP on a load balancer that can be set to preference one server - and back them both up via slapcat and copying the backups off the servers. I know this is a bit moot now, but I'd start looking into it.
-----Original Message----- From: Richard Troy [mailto:rtroy@ScienceTools.com] Sent: Friday, January 07, 2011 11:18 AM To: Chris Jacobs Cc: 'openldap-technical@openldap.org' Subject: Re: Emergency recovery strategy needed by novice
On Fri, 7 Jan 2011, Chris Jacobs wrote:
Dump: slapcat -l [ldif file]
Add from dump, with slapd off: slapadd -l [ldif file]
If you're using BDB (typical backend), you can move the contents of the dbdir specified by your config first.
- chris
THANK YOU, Chris.
However, I can't login to the troubled server. When I try and login via ssh, I get the password prompt, then nothing and it eventually times out with simply, "connection lost."
I do have a connection from our application server to slapd which is visible via 'netstat -lT' as ldaps ("ESTABLISHED") - I presume this is via some kind of library available via Java as it's a EJB based application.
Further thoughts? Can I harness the ability to connect to get the data out even when I don't know the first thing about the data I want to fetch, similar to the slapcat command above?
Thanks again for any all help, comments, etc, Richard
Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- Sent: Thu Jan 06 18:32:15 2011 Subject: Emergency recovery strategy needed by novice
Hello All,
I've got a bit of a problem.... Management chose a software product that depends on OpenLDAP's SLAPD service and had us put it into production without our quite understanding the software well enough to be clueful. The deployment is across virtual and real servers, the virtual servers handling the web stack and other user-oriented functionality while "real" servers handle data management. Regarding the data management, one system was chosen as a replication master, and another as slave, but being understaffed, we never quite got the replication of the OpenLDAP data configured when, today, some serious networking problems cropped up.
The symptom is that we can establish an OpenLDAP (slapd) connection from the virtual side to the master, and a postgres connection - our RDBMS, but we can't get the rest of our primary application to connect properly so it's down. And it is absolutely not clear what's wrong with the master anyway. I can't get to the physical hardware because it's off in some data center somewhere that the founder located near him - and he's off traveling. So, we're "dead in the water."
I was thinking that we might salvage the situation by dumping the data from the Postgres and OpenLDAP databases and restoring them to the slave system - promoting it to master - and while I've succeeded in moving over the Postgres data, I haven't a CLUE how to get started unloading and reloading the OpenLDAP data.
...I'm very competent with most things related to computing but I am _completely_ inexperienced with OpenLDAP. I've never issued any commands to or with OpenLDAP / slapd and have no idea what's normal for dealing with it. Are there dump and reload utilities? Any and all pointers / help GREATLY appreciated.
Richard
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
openldap-technical@openldap.org
-
Chris Jacobs -
Emmanuel Lecharny -
Mackey, Theral -
Richard Troy