OpenLDAP import into 389 Directory Server failing

After RHEL, etc dropped OpenLDAP, I’ve begun testing with 389 Directory Server. Currently, I’m trying to use openldap_to_ds to import slapd.d config and an LDIF export to import my old database into the new server.

I’ve created a new instance in 389-ds named terminal-config. I’ve tried the following variations on the idea, all of which gave me the same results:

  • exported the LDIF from OpenLDAP 2.4 on Oracle Linux 7 and CentOS 6 servers.
  • Rewrote all files being imported to make sure they weren’t corrupt.
  • used relative and absolute path names to the files
  • Tried importing with a new instance (as mentioned above) and no instance at all
  • When using dscreate to make the new instance, I’ve tried setting it up differently (allowed sample entries and not, etc)

No matter what I do, this is what I get when I try:

[root@ldaptest ~]# openldap_to_ds terminal-config /root/slapd.d  /root/terminals.ldif
Examining OpenLDAP Configuration ...
Traceback (most recent call last):
  File "/usr/sbin/openldap_to_ds", line 250, in <module>
    result = do_migration(inst, log, args, skip_overlays)
  File "/usr/sbin/openldap_to_ds", line 178, in do_migration
    config = olConfig(args.slapd_config, log)
  File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/", line 305, in __init__
    for db in dbs
  File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/", line 305, in <listcomp>
    for db in dbs
  File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/", line 112, in __init__
    self.suffix = ensure_str(self.config[1]['olcSuffix'][0])
KeyError: 'olcSuffix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/sbin/openldap_to_ds", line 257, in <module>
    log.error("Error: %s" % " - ".join(str(val) for val in msg.values()))
AttributeError: 'str' object has no attribute 'values'
[root@ldaptest ~]#

Any thoughts on what could be causing this?


Not sure about the specific error, but this general Python error merely means that self.config[1] is a dictionary that is missing a olcSuffix key. I don’t know what this config is, though.

What release of Fedora would this be please? It could be a bug, and this issue may be specific enough to try the 389 directory server communication channels too.

Since this is self.config, I presume it isn’t a file, but something dynamically generated. If that’s the case, then it sounds like it’s not finding the LDAP suffix, which is curious, because the OpenLDAP database was exported using the suffix, and I’ve put the same suffix in the 389 db I created with dscreate. Maybe I need to take a better look at slapd.d and the export.

As for the Fedora release… It’s not on Fedora at all; I’m running the EPEL build ( on Oracle Linux 8. I posted in the Fedora forums because 389 DS is a Fedora project.

1 Like

Not really, in the sense that the Fedora project does not develop 389 DS as part of its objectives or deliverables. (In my 15 years in the community, I’ve never had anything to do with 389 DS, for example). It’s a FOSS project in its own right, like all the other packages in Fedora. It was initially called Fedora directory server because of historical reasons from the looks of it. It sits on Fedora infrastructure because it’s a Red Hat sponsored project too, but apart from that, it doesn’t really have any connections to Fedora.

So, it’s just another package that is shipped in Fedora, but it’s not special in any way. So, it may be worth using their communication channels directly because you’ll probably get better support there:

1 Like

Ok, so that’s why I couldn’t find a forum; it doesn’t exist, and I wasn’t looking for mailing lists. Thanks for the tip, I will give that a try.

Thanks for all the info too, that clarifies a few things.

1 Like

Yeh, looks like they’re still using mailing lists as their main communication channel, so the users list is probably your best bet.

HTH, hope you get it all sorted out.

In my case, the missing key came from the cn=monitor , I had the ldif file removed and retried successfully

You can try running the command with the -vvv flag to point out in which item in your configuration the script fails

Hoped I helped