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): openldap-servers-2.3.34-0.fc7 How reproducible: Always 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.
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 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.
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[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 ldapsearch).
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.