Bug 236697 - RFE: Split padl migration tools into separate package
Summary: RFE: Split padl migration tools into separate package
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jan Safranek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-17 04:43 UTC by Michael Stahnke
Modified: 2008-03-06 10:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-29 11:33:05 UTC
Type: ---

Attachments (Terms of Use)

Description Michael Stahnke 2007-04-17 04:43:47 UTC
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):


How reproducible:

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)
Actual results:
Padl utilities only bundled with openldap-servers package.

Expected results:
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.

Comment 1 Jan Safranek 2008-02-28 09:11:00 UTC
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?

Comment 2 Jan Safranek 2008-02-28 11:43:55 UTC
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
and openldap-clients).

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.

Comment 3 Jan Safranek 2008-02-28 14:45:12 UTC
The migrationtools are carved out, see review request at
https://bugzilla.redhat.com/show_bug.cgi?id=435279. Feel free to take the review.

Comment 4 Jan Safranek 2008-02-29 11:33:05 UTC
migrationtools package has been built and should appear together with fixed
openldap in tomorrow's rawhide and in Fedora9.

Comment 5 Michael Stahnke 2008-03-04 03:49:32 UTC
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.  

Comment 6 Jan Safranek 2008-03-05 13:42:51 UTC
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.

Comment 7 Michael Stahnke 2008-03-05 23:13:19 UTC
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. 

Comment 8 Rich Megginson 2008-03-05 23:21:39 UTC
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[64]/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

Comment 9 Howard Chu 2008-03-06 00:42:20 UTC
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.

Comment 10 Jan Safranek 2008-03-06 10:06:53 UTC
This discussion is getting out of topic. I've created new bug #436274 for Fedora
DS support, let's move the discussion there.

Note You need to log in before you can comment on or make changes to this bug.