From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030718 Epiphany/0.8.2 Description of problem: When converting the /etc/{passwd,group,aliases} files, slapadd fails when given the resulting ldif.file file for input. The file name "ldif.file" is, here, arbitrary and used to identify the output from /usr/share/openldap/migration/migrate_{passwd,group,aliases}.pl. The offending attribute is "mailRecipient", as supplied by migrate_passwd.pl, where it should be "inetLocalMailRecipient." While this is *one* issue, the default installed "slapd.conf" file is missing an "include" statement pointing to /etc/openldap/schema/misc.schema which defines the correct "inetLocalMailRecipient" attribute... and it is the combination of both the incorrect attribute, and missing include of the misc.schema that results in a slapadd error related to the "inability" to parse the "rfc822MailMember," and the LDAP database is not built. (See error excerpt below) Version-Release number of selected component (if applicable): openldap-servers-2.0.27-11 How reproducible: Always Steps to Reproduce: 1. Install openldap-servers, in addition to nss_ldap, and openldap 2. Run '/usr/share/openldap/migration/migrate_base.pl >/tmp/ldif.file' 3. Run '[...]/migrate_passwd.pl /etc/passwd >> /tmp/ldif.file' 4. Same as 3., but replace passwd with group, hosts and aliases. 5. Run `/usr/sbin/slapadd -v -d3 -l /tmp/ldif.file &> /tmp/slapadd.out 6. View last 60 lines of /tmp/slapadd.out for error listed below Actual Results: Undefined attribute "type" encountered, LDAP database not created. Expected Results: LDAP database created from user, group and mail aliases as configured on the system. Additional info: NB-The /etc/openldap/slapd.conf and /usr/share/openldap/migration/migrate_common.ph files were edited to define the BaseDN and "DEFAULT_MAIL_DOMAIN"... omitted from the steps as these were not in play. Excerpt from slapadd output: ... <= str2entry: str2ad(rfc822MailMember): attribute type undefined slapadd: could not parse entry (line=2105) ...
After digging through the migration scripts, and schemas, it seems this issue is mostly concerning the migration of mail aliases. Line 73 of the /usr/share/openldap/migration/migrate_aliases.pl script calls `print $HANDLE "rfc822MailMember: $_\n";' While this attribute type is defined in /etc/openldap/schema/misc.schema, this schema configuration file *also* states its contents are experimental(!)... With the mere inclusion of the misc.schema pointer in slapd.conf, the aliases entries are added to the LDAP database without error. Running... ldapsearch -LL -H ldap://localhost -b"dc=lala,dc=to" -x \ "(rfc822MailMember=*)" ...brings up a healthy list of mail aliases where cn="alias" and rfc822MailMember="user". The objectClass is nisMailAlias. If the "misc.schema" is not a default include in slapd.conf, then the creation of mail aliases from the local /etc/aliases file will fail. That there indeed need be an attribute type "rfc822MailMember" to have a functional LDAP service to mail servers seems dependent on the server(sendmail,exim,postfix). This schema, however experimental, seems the only one to define it. Aside from that, the migration script for passwd should have the "mailRecipient" replaced with "inetLocalMailRecipient" but only really neccessary when DEFAULT_MAIL_HOST or EXTENDED_SCHEMA are set.
The attribute is fixed in the current version (46) of the migration tools (http://www.padl.com/OSS/MigrationTools.html). Rawhide bundles version 45.
Unable to use migration scripts on RHES3 update 6. Following the instructions listed above I downloaded the new Migration tools from padl.com. I also added the misc.scripts include to slapd.conf. Here're the results that I get now: [root@central1 MigrationTools-46]# ./migrate_all_offline.sh Creating naming context entries... Migrating aliases... Migrating groups... Migrating hosts... Migrating networks... Migrating users... Migrating protocols... Migrating rpcs... Migrating services... Migrating netgroups... Importing into LDAP... Migrating netgroups (by user)... Migrating netgroups (by host)... Preparing LDAP database... slapadd: could not add entry dn="dc=insiderpages,dc=com" (line=5) Migration failed: saving failed LDIF to /tmp/nis.4759.ldif If I add "-v -d 3" to the slapadd command line within the migrate_offline script I get the following: <snip> added: "cn=zip,ou=Services,dc=insiderpages,dc=com" (00000192) => str2entry <= str2entry(cn=echo,ou=Services,dc=insiderpages,dc=com) -> -1 (0x8950ed8) oc_check_required entry (cn=echo,ou=Services,dc=insiderpages,dc=com), objectClass "ipService" oc_check_required entry (cn=echo,ou=Services,dc=insiderpages,dc=com), objectClass "top" oc_check_allowed type "objectClass" oc_check_allowed type "ipServicePort" oc_check_allowed type "ipServiceProtocol" oc_check_allowed type "cn" => ldbm_tool_entry_put( 403, "cn=echo,ou=Services,dc=insiderpages,dc=com" ) => dn2id( "CN=ECHO,OU=SERVICES,DC=INSIDERPAGES,DC=COM" ) => ldbm_cache_open( "dn2id.dbb", 9, 600 ) <= ldbm_cache_open (cache 2) <= dn2id 400 <= ldbm_tool_entry_put: "CN=ECHO,OU=SERVICES,DC=INSIDERPAGES,DC=COM" already exists (id=400) slapadd: could not add entry dn="cn=echo,ou=Services,dc=insiderpages,dc=com" (line=3325) => ldbm_cache_open( "nextid.dbb", 9, 600 ) <= ldbm_cache_open (cache 1) slapadd shutdown: initiated ldbm backend syncing ldbm flushing db (id2entry.dbb) ldbm closing db (id2entry.dbb) ldbm flushing db (nextid.dbb) ldbm closing db (nextid.dbb) ldbm flushing db (dn2id.dbb) ldbm closing db (dn2id.dbb) ldbm flushing db (objectClass.dbb) ldbm closing db (objectClass.dbb) ldbm flushing db (cn.dbb) ldbm closing db (cn.dbb) ldbm flushing db (gidNumber.dbb) ldbm closing db (gidNumber.dbb) ldbm flushing db (memberUid.dbb) ldbm closing db (memberUid.dbb) ldbm flushing db (uid.dbb) ldbm closing db (uid.dbb) ldbm flushing db (uidNumber.dbb) ldbm closing db (uidNumber.dbb) ldbm backend done syncing ====> cache_release_all slapadd shutdown: freeing system resources. Migration failed: saving failed LDIF to /tmp/nis.4953.ldif I then commented out the following line in /etc/services echo 4/ddp # AppleTalk Echo Protocol And the script ran successfully. Perhaps this should be in a different bug, but this was the closest one I could find.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.