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. However, my production server (running the same locally compiled version of 2.4.44) does not.
My question is what the dickens have I misconfigured that would cause this?
Examples:
$ ldapsearch -x -H ldaps://production_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111164206.727511Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog hasSubordinates: TRUE
$ 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 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111013201.758363Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog
- Frank Swasey
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.
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.
openldap-technical@openldap.org
-
Frank Swasey -
Michael Ströder