[Date Prev][Date Next]
Re: (ITS#8130) ldif export / import issue when memberURL used in groupOfURLs object class
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8130) ldif export / import issue when memberURL used in groupOfURLs object class
- From: firstname.lastname@example.org
- Date: Wed, 06 May 2015 15:48:27 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On Wed, May 06, 2015 at 08:00:02AM +0000, email@example.com wrote:
>2>> But when I am exporting the ldif file, then dynamically populated attributes
>in groupOfURLs objects and their values are also getting exported in the ldif
>file, which should not happen because it is creating issue when I am trying to
>import the same ldif in the destination environment.
How are you doing that export? slapcat(8) is the tool that you should
use to dump a slapd database.
>3>> The reason is, these dynamically populated attributes in groupOfURLs object
>is not the part of dyngroup.schema (because it is dynamically populated from
>other object) that?s why during ldif IMPORT in the target environment, ldap is
>expecting these attributes should be part of dyngroup.schema and then will allow
>the import, and because this not allowed to import the data.
Normally those attributes should not be present in a slapcat(8) dump. If
you are finding that they are, would you please provide an example
configuration with clear and complete steps to reproduce it?
>What is the solution for this? As per my understanding product should support to
>migrate the ldif or other configuration from one environment to other without
>any issue, this industry standard. I am looking for help on this issue from
Community support is handled on the openldap-technical mailing list; the
ITS is for bug reports only. I would suggest that you consult that list
for help, and follow up here again if the consensus is that you are
doing things correctly and have encountered a bug.