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/config.py", line 305, in __init__
for db in dbs
File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/config.py", line 305, in <listcomp>
for db in dbs
File "/usr/lib/python3.6/site-packages/lib389/migrate/openldap/config.py", 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 ~]#
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 (1.4.4.17) on Oracle Linux 8. I posted in the Fedora forums because 389 DS is a Fedora project.
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: