3

I am setting up a login node and am using openLDAP from the repository on Ubuntu 14.04 and I am running into an issue of duplicate attributeTypes.

The problem seems to lie in the "gecos" field attribute. when I try to run slapcat or slapadd or slapindex, I get this output:

$ slapcat
53ecd288 olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"
53ecd288 config error processing cn={3}nis,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"
slapcat: bad configuration file!

And when I grep for 1.3.6.1.1.1.1.2 I get

$ cd /etc/ldap/ && grep -r '1.3.6.1.1.1.1.2' *
schema/nis.schema:attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
schema/nis.ldif:olcAttributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
slapd.d/cn=config/cn=schema/cn={3}nis.ldif:olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
slapd.d/cn=config/cn=schema/cn={2}nis.ldif:olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th

Needless to say, slapd fails to start.

I don't know how I should go about troubleshooting this problem. When searching for this problem, I saw that people were having a similar problem when trying to use core.schema files from a different, older server. I have not used any files from a different server, and have not edited core.schema or any other core files, with the exception of ldap.conf and slapd.conf.

Does anyone have insight into this problem? What can I do to fix it?

  • 1
    Are you writing a slapd.conf which references schema files? If yes, stop it, this is the old method, these days schemas are stored in the cn=config tree. – Sven Aug 14 '14 at 16:54
  • 1
    @SvW I'm really new here, but I really appreciate your answer. If this were reddit, you'd get upvoted. I am writing a slapd.conf. So is all the configuration set in cn=config? is there any use in a slapd.conf file? – Zachary Aug 14 '14 at 17:01
  • 1
    Please read help.ubuntu.com/14.04/serverguide/openldap-server.html, they are doing a pretty good job of explaining this. IF you have more questions, come back. Also: Whenever you search for an OpenLDAP problem and find something about modifying slapd.conf, this is usually outdated. Lastly, you can upvote here. Proper answers like @FalconMomot's are obvious to upvote and result in reputation points, but if you hover the mouse over a commment, an upvote arrow appears as well (but doesn't grant rep changes). – Sven Aug 14 '14 at 17:20
4

It looks as though the problem is that you have used the OID 1.3.6.1.1.1.1.2 to define two "different" attributes (really the same attribute twice), once in cn=config,cn=schema,cn={3}nis, and once in cn=config,cn=schema,cn={2}nis. OIDs referencing attributes must be unique.

I don't know what stage you're at in the process of migrating, here, but it looks like you might have imported the same schema twice somehow. If you just did some kind of migration you may want to try it again, taking care to migrate the schema just once.

If you had just converted a bunch of schema files to LDIFs for importing into cn=config,cn=schema, check that in the cn=config/cn=schema folder you do not have multiple entries for NIS (or any other schema component) there. I think you have files cn={2}nis.ldif and cn={3}nis.ldif; use diff to see that they are the same (or how they differ), merge them if necessary, and try importing (freshly) with only one of them present.

| improve this answer | |
  • 1
    It looks like the schemas were already defined in the cn=config tree and then included a second time in the now obsolete slapd.conf I took your advice and used a fresh install of the server and it seems to have worked! I can now authenticate. – Zachary Aug 15 '14 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.