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.