I have determined that Ulrich was actually correct... I was generating
the database dump of my production server via ldapsearch and then
copying that ldif file to the development server and using slapadd to
install it.
Since the entryDN and subschemaSubentry are not in the ldif created from
On Wed, 11 Jan 2017 at 3:15pm, Quanah Gibson-Mount wrote:
--On Wednesday, January 11, 2017 2:50 PM -0500 Frank Swasey
wrote:
My slapd.conf files are built using mustache templates with minimal
differences... Is there a specific config option I should be looking at
--On Wednesday, January 11, 2017 2:50 PM -0500 Frank Swasey
wrote:
My slapd.conf files are built using mustache templates with minimal
differences... Is there a specific config option I should be looking at
that could cause the operational attributes to be duplicated
Today at 1:48pm, Quanah Gibson-Mount wrote:
--On Wednesday, January 11, 2017 1:18 PM -0500 Frank Swasey
wrote:
Today at 12:44pm, Michael Ströder wrote:
Out of curiosity:
What happens if you slapcat the data on your development server?
slapcat dumps the data just
--On Wednesday, January 11, 2017 1:18 PM -0500 Frank Swasey
wrote:
Today at 12:44pm, Michael Ströder wrote:
Out of curiosity:
What happens if you slapcat the data on your development server?
slapcat dumps the data just fine (meaning that the two attributes are not
Today at 12:44pm, Michael Ströder wrote:
Out of curiosity:
What happens if you slapcat the data on your development server?
slapcat dumps the data just fine (meaning that the two attributes are not
duplicated).
- Frank
Frank Swasey wrote:
> I have discovered that I have a development server that is giving back
> multiple copies of the entryDN and subschemaSubentry values when operational
> attributes are requested.
> [..]
> $ ldapsearch -x -H ldaps://development_server -D cn=manager,dc=example,dc=com
> -y