Re: Odd ldapsearch behavior (RESOLVED)

[Frank Swasey]

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 
a slapcat of the production server, I suspect if I were to root around 
in the source code that the ldapsearch process adds them to the returned 
ldif.


Therefore, I had two options, I could filter those two attributes out of 
what ldapsearch returns or I could stop using ldapsearch and use 
slapcat.  Since I assume there may well be other attributes that 
ldapsearch could add which would cause me headaches in the future, I 
have opted to use slapcat (via ssh to the server) which is the proper 
mirror of the slapadd (via ssh to the server) that I use to install the 
production database on the development server.


Sorry to (once again) ask for help with something I should be smart 
enough to figure out.  I could have figured this out quickly had I just 
done a comparison of what ldapsearch generated against what slapcat 
generated from the production server.


--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

Re: Odd ldapsearch behavior

[Frank Swasey]

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
that could cause the operational attributes to be duplicated in the
output of ldapsearch but not slapcat?


Well, it'd be a bug, so I've no idea what would specifically trigger it. :) I 
guess you could diff the slapd.conf files and see what differences exist and 
start from there?


Quanah,

  The only differences in the slapd.conf files are the URN's of systems 
which are specified as ServerID 1/2 and as provider in the corresponding 
syncrepl config statements, and the TLS certificates.  I can't see those 
things being the source of this problem :(


 - Frank

Re: Odd ldapsearch behavior

[Quanah Gibson-Mount]

--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 in the
output of ldapsearch but not slapcat?


Well, it'd be a bug, so I've no idea what would specifically trigger it. :) 
I guess you could diff the slapd.conf files and see what differences exist 
and start from there?



--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Odd ldapsearch behavior

[Frank Swasey]

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 fine (meaning that the two attributes are not
duplicated).


If you are using cn=config, slapcat it and compare?


  I let it build the cn=config when it starts, but I'm still one of the 
miscreants that is using slapd.conf...


  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 in the 
output of ldapsearch but not slapcat?


 - Frank

Re: Odd ldapsearch behavior

[Quanah Gibson-Mount]

--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
duplicated).


If you are using cn=config, slapcat it and compare?

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Odd ldapsearch behavior

[Frank Swasey]

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

Re: Odd ldapsearch behavior

[Michael Ströder]

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 password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+'
> dn: dc=example,dc=com
> [..]
> entryDN: dc=example,dc=com
> subschemaSubentry: cn=Subschema
> hasSubordinates: TRUE
> entryDN: dc=example,dc=com
> subschemaSubentry: cn=Subschema
> auditContext: cn=accesslog

Out of curiosity:
What happens if you slapcat the data on your development server?

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature