Red Hat Bugzilla – Bug 236697
RFE: Split padl migration tools into separate package
Last modified: 2008-03-06 05:06:53 EST
Description of problem:
Currently the padl scripts found in /usr/share/openldap/migration are part of
openldap-servers. They have uses with any ldap-directory and certainly do not
require a local ldap server to be effective. Could this be broken into a
separate package (still from openldap src.rpm or completely separate since they
have a separate upstream) with only the padl migration tools?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Looks for padl migration utils without openldap-servers installed (notice
you can't find them)
2. install openldap-servers
3. Look again, (now you find them)
Padl utilities only bundled with openldap-servers package.
padl utilities its own package for easy use with fedora-ds, rhds, openldap ...etc.
Additional info: If you want someone to modify the spec file and submit a
patch, I certainly can. If there are other reasons not to make the change,
please just post here so I can know.
Finally I got some time to look at it... My intention is to split migration
tools as you suggest and make openldap-servers dependent on it.
The migration tools would be installed into /usr/bin, which will make many
openldap tutorials obsolete (they expect the scripts in /usr/share/openldap/),
but that's life. I'll try to put some READMEs there.
Any other pitfalls I should avoid?
it is more complicated than I though... migration tools must depend on
Ipenldap-servers and openldap-clients (they use slapadd and ldapadd), so the
dependencies must be other way around (migration tools require openldap-servers
Also the location in /usr/bin is not a good idea, the scipts needs to be edited
before use -> better have them in /usr/share/migrationtools and let user copy
them somewhere if he/she needs to edit them.
The migrationtools are carved out, see review request at
https://bugzilla.redhat.com/show_bug.cgi?id=435279. Feel free to take the review.
migrationtools package has been built and should appear together with fixed
openldap in tomorrow's rawhide and in Fedora9.
Thanks for getting to this. I was hoping to not require the openldap server
when using Fedora DS. I guess that's still not going to be the case? I
normally do use openldap-clients, but not so much the server. It just seems odd
that the flagship directory product (and education classes from RH) require you
to install openldap-* (and padl tools) to use Fedora/Red Hat DS.
The migrationtools require ldapadd and ldif2dbm utilities. In OpenLDAP world,
this functionality is provided by openldap-clients (ldapadd) and
openldap-servers (slapadd). If I am looking right, in Fedora DS this is provided
by mozldap (ldapmodify) and fedora-ds-base (ns-slapd with some parameters).
I have no experience with Fedora DS and I need your help - could you please
confirm, that PADL migrationtools work with ldapmodify and ns-slapd? Try:
export LDAPADD="/usr/lib/mozldap/ldapmodify -a"
export LDIF2DBM="/usr/sbin/ns-slapd ldif2db -f $NSHOME/slapd-$serverID" (if it
is the right command, I really do not know)
and run migrate_all_online/offline
If it works, we can play with dependencies:
- mozldap Provides: ldapadd
- fedora-ds-base Provides: ldif2dbm
- openldap-clients Provides: ldapadd
- openldap-servers Provides: ldif2dbm
- migrationtools Requires: ldapadd, ldif2dbm
-> migrationtools would work whith any combination providing both ldif2dbm and
ldapadd. I could also fix the migrationtools to look in the right directories,
so it could work out of the box without magic env. variables.
I can run these test, but it might take me a day or two. I also posted this bug
notice in IRC #fedora-ds to ask for any other testers, etc.
A couple of problems:
export LDAPADD="/usr/lib/mozldap/ldapmodify -a"
will not work on a 64-bit system - /usr/lib64/mozldap
export LDIF2DBM="/usr/sbin/ns-slapd ldif2db -f $NSHOME/slapd-$serverID"
Is not quite right either. There is usually only one "instance" of OpenLDAP
running on a machine. Fedora DS by default supports more than one. So you have
to provide the instance name. Also, the fedora ds ldif2db tool supports
multiple database backend instances, you have to specify one either by name
(e.g.-n userRoot) or by suffix (e.g. -s "dc=example,dc=com"). I suppose with
openldap it either assumes only one database, or it is smart enough to parse the
ldif into multiple databases if necessary.
So something like this:
/usr/lib/dirsrv/slapd-$serverid/ldif2db -n userRoot
should work in most cases.
Finally, the OpenLDAP libraries must usually be present on the system for things
like nss_ldap, pam_ldap, and other ldap aware apps. It is a small matter to
also install the openldap-clients package to get ldapsearch, etc. You can use
the openldap ldapsearch et. al. with Fedora DS - you do not have to use the
mozldap ldapsearch (although Fedora DS scripts do use mozldap ldapsearch, so
mozldap-tools is a requirement for Fedora DS - but users can use openldap
slapadd tries the first database instance by default. It will return an error if
that database's suffix doesn't match the LDIF. You can select a specific one by
suffix (-b dc=example,dc=com) or by number (-n 1 = first database in
configuration) If the configuration uses multiple glued databases, then by
default the LDIF is parsed into the individual databases automatically.
This discussion is getting out of topic. I've created new bug #436274 for Fedora
DS support, let's move the discussion there.