This is almost the same as the earlier Bug 201183 I reported:
Services using two different ports for tcp/udp cause migration scripts to fail.
The services currently causing the problems are:
With /usr/share/openldap/migration/migrate_all_offline.sh I get:
Preparing LDAP database...
=> bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists
slapadd: could not add entry dn="cn=raid-am,ou=Services,dc=domain" (line=16502):
txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996)
Migration failed: saving failed LDIF to /tmp/nis.ldif.WL3357
With /usr/share/openldap/migration/migrate_all_online.sh I get:
adding new entry "cn=nextstep,ou=Services,dc=intra"
ldapadd: Type or value exists (20)
additional info: cn: value #0 provided more than once
Please consider fixing. Please also double check other similar cases, I did only
these two quick tests.
This is a common limitation of LDAP schema for services, /etc/services cannot
be fully translated into ldap database. The RFC 2307 ("Using LDAP as a Network
Information Service") allows mapping from service name to port number/protocols
pair. It cannot map one service to port_A/udp and the same service to port_B/tcp
if A != B. LDAP server fails to add the second mapping.
It's up to the network administrator to decide:
- whether he/she wants to have only TCP or UDP in the LDAP database
- or rename the service to have different name for udp and tcp variant
- or change the port numbers to the same number for TCP and UDP
and manually modify the .ldif file.
So basically now the migration scripts cannot be used on standard Fedora
installation. It would be nice to get at least a clear warning about this or
perhaps even a command line switch to ignore problematic entries.