[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Transferring LDAP databases between dissimilar DBs
I've got multiple versions of OpenLDAP running at this point, and I've always
had multiple backend formats because Red Hat hasn't been able to make up their
collective mind about what to use.
So a while back I just wrote a perl script that fires off an LDIF of the
locally running database and loads it into the remote system.
The order of operations is like this:
stop local slapd and slurpds
slapcat the entire database to ldif format
start local slapd and slurpds
use rsync over ssh2 to push the ldif to remote server
stop remote slapd
rename database files on old server to .old
slapadd the fresh ldif into the remote server
start remote slapd
Here are the problems:
1) I'm not a very good perl programmer IMnvHO.
2) This script has only been tested on Red Hat linux (works on versions 6.2,
7.x, 9, and ELes3, though) and probably won't work on other distros without
some minor tweaking.
3) The script depends on SSH keys that extend root access from the local server
to the remote server, so it's not suitable for extremely secure environments.
I just never got around to figuring out how to set up restricted keys under the
ldap userid. But if you use NIS or HESIOD or sync'd /etc/passwd files (or have
your privileged accounts in LDAP) this is not a new problem for you anyway.
4) Each server needs to have a backup source of LDAP information for nss_ldap
and pam_ldap to use while they have their local LDAP daemons shut off. I don't
consider this a real problem since I would never run a system without at least
two LDAP services defined for it.
5) It's slow over WAN links; rsync doesn't help as much as one might wish.
The nice thing about it is that it uses slapd.conf for its configuration file;
that is, it only works on replicas that are defined there. And it's pretty
painless; once the ssh keys are set up I can reload every single LDAP replica
in the enterprise (I have *lots*) with a single command. Very useful for
disaster recovery and system hardware upgrades.
If you want a copy of the code I can slap a GPL on it and send it along, or
post to the list if there is widespread interest.
--Charlie
On 2 Apr 2004 at 10:07, Kent L. Nasveschuk wrote:
> Hello Frank,
>
> Just a couple questions regarding, going from ldbm to bdb since bdb
> seems to be the a much better backend for OpenLDAP.
>
> I've got 4 OpenLDAP servers 2.1.23 (1 master 3 slaves) with ldbm
> backend. If I were to upgrade one at a time any suggestions on how to
> proceed with this? A server that went down in the past, I shutdown
> slapd, copied the db files to the new installations and restarted slapd
> and slurpd. I can't do a direct copy of files with different DB
> backends. Use slapcat on the master then ldapadd on the new machine?
>
> Thanks
>
> On Fri, 2004-04-02 at 07:59, Frank Swasey wrote:
> > On Thu, 1 Apr 2004 at 3:55pm, Michael J. Erdely wrote:
> >
> > > Is there a convincing reason to go use a dbm backend instead of ldbm?
> >
> > Yes, there are several.
> >
> > 1) ldbm is not receiving much (if any) development.
> >
> > 2) ldbm has a single lock, so if you can get yourself into a situation
> > where the whole server becomes unresponsive for an extended period of
> > time. For example, you fire off a search based on a non-indexed
> > attribute that takes a long time. Someone else asks to modify an
> > attribute. Their modify is stuck behind your search and any other
> > searches that try to start are now stuck behind their modify. Several
> > times before I switched to back-bdb, I had to recycle the servers
> > because things were not working. I haven't had a single one of those
> > deadlock situations since converting to back-bdb.
> >
> > 3) ldbm does not allow slapd to be up and running while performing a
> > slapcat (bdb does).
> >
> > > It seems that the ldbm backend is much easier to setup.
> >
> > That's true. However, it's kind of like saying an automatic
> > transmission is easier to drive than a manual transmission. There are
> > trade-offs. You'll get better gas mileage with a manual transmission
> > once you have learned how to properly operate it.
> >
> > > Iâ??m running OpenLDAP version 2.1.25 on Redhat Enterprise 3 and plan on
> > > supporting about 30k-50k users with about 6-9 indices.
> >
> > I would suggest that you upgrade to 2.1.29 (there were some interesting
> > features in 2.1.25 [as I recall -- but they may only be related to bdb]
> > that have been fixed in 2.1.27 and beyond).
> >
> > > With the ldbm backend, does anyone have any good equations to determine the
> > > â??cachesizeâ?? and â??dbcachesizeâ?? settings?
> >
> > I do not.
> >
> > > I have only 512 MB of memory but plan on ramping that up to 2 to 4 GB.
> >
> > For the size database you are running 4GB would be plenty for a well
> > tuned back-bdb installation. I am running several 2.1.27 servers. I
> > have a couple on RH9 with 2GB of memory and a couple more on RHEL3 with
> > 4GB of memory and they're all running back-bdb.
> >
> > I don't recommend RH9 (unless you also upgrade cyrus-sasl due to bugs in
> > the version RH shipped -- I have to recycle saslauthd once a week).
> --
> Kent L. Nasveschuk <kent@wareham.k12.ma.us>