1

I have to create a development server to mirror a customer LDAP installation. The customer gave me a db.ldif file beginning with 

cn: cn=Subschema
ldapSyntaxes: ( 1.3.6.1.1.16.1 DESC 'UUID' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.1 DESC 'RFC2307 Boot Parameter' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.0 DESC 'RFC2307 NIS Netgroup Triple' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' X-BINAR
 Y-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
and so on

But I can't find how to load it : 

ldapadd -Y EXTERNAL -H ldapi:// -f /ldap/db.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=Subschema"
ldap_add: Already exists (68)
        additional info: subschema subentry already exists

slapadd -l /ldap/db.ldif 
57aca988 str2entry: attributeType ldapSyntaxes #0: no validator for syntax 1.3.6.1.4.1.1466.115.121.1.54
slapadd: could not parse entry (line=1)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB..

My installation : 

slapd -V       
@(#) $OpenLDAP: slapd  (Ubuntu) (Jun 24 2016 15:39:52) $
        buildd@lgw01-24:/build/openldap-MhQj18/openldap-2.4.31/debian/build/servers/slapd

I try to change EOL to linux ones, and others file structure stuff. How can I do my work ?

Cédric Girard
  • 397
  • 2
  • 11
  • 25

1 Answers1

2

This looks like the LDIF file (at least in part) contains a dump of the root DSE from an LDAP server, obtained by using a base of "cn=Subschema" with something like:

ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b 'cn=Subschema' +

So to answer your question, you can't ldapadd this because cn=Subschema already exists, as the error states. It's one of these special objects maintained by the server itself; you probably don't want or need a dump of this.

You really just want a dump of some/all of the cn=config database; at the very least the schemas in use and then a dump of the main database itself. Having a more comprehensive dump of the cn=config database can't hurt as that will have things like ACL definitions, overlays, etc. that might be important.

bodgit
  • 4,661
  • 13
  • 26