When I try to use migrationtools to migrate my existing data to LDAP I get several errors related to wrong attribute and class names. Reproducible: Always Steps to Reproduce: 1. emerge openldap migrationtools 2. configure LDAP server and migration tools (related information provided below) 3. cd /usr/share/migrationtools 4. ./migrate_all_online.sh Actual Results: migrationtools fail with errors related to wrong attribute and class names. The first of these errors follow: adding new entry "uid=root,ou=People,dc=opentechnet,dc=com" ldapadd: update failed: uid=root,ou=People,dc=opentechnet,dc=com ldap_add: Undefined attribute type (17) additional info: krbName: attribute type undefined /usr/bin/ldapadd: returned non-zero exit status In this case krbName should be (I'm guessing here) krb5PrincipalName (found in /etc/openldap/schema/krb5-kdc.schema). Fixing this error leads to other similar errors. Expected Results: migrationtools should have imported all the NIS information in plain files into the LDAP server. Only a part of this information is imported into the server (base OUs, groups, hosts) I get this problem using openldap-2.1.26 and migrationtools-45 From /etc/openldap/slapd.conf: # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.8 2003/05/24 23:19:14 kurt Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/krb5-kdc.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema From /usr/share/migrationtools/migrate_common.ph [snip] # Default DNS domain $DEFAULT_MAIL_DOMAIN = "opentechnet.com"; # Default base $DEFAULT_BASE = "dc=opentechnet,dc=com"; # Turn this on for inetLocalMailReceipient # sendmail support; add the following to # sendmail.mc (thanks to Petr@Kristof.CZ): ##### CUT HERE ##### #define(`confLDAP_DEFAULT_SPEC',`-h "ldap.padl.com"')dnl #LDAPROUTE_DOMAIN_FILE(`/etc/mail/ldapdomains')dnl #FEATURE(ldap_routing)dnl ##### CUT HERE ##### # where /etc/mail/ldapdomains contains names of ldap_routed # domains (similiar to MASQUERADE_DOMAIN_FILE). $DEFAULT_MAIL_HOST = "mail.opentechnet.com"; # turn this on to support more general object clases # such as person. $EXTENDED_SCHEMA = 1; [snip] Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.25-gentoo-r2) ================================================================= System uname: 2.4.25-gentoo-r2 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.9 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon -O3 -pipe -mmmx -m3dnow" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 apm arts avi berkdb crypt cups doc encode flash foomaticdb gd gdbm gif gpm gtk2 imap imlib innodb java jpeg kerberos krb4 lcms ldap libg++ libwww mad mcalc mikmod motif mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png postgres ppds python quicktime readline samba sasl sdl slang slp spell ssl svga tcpd tetex tiff truetype x86 xml2 xmms xv zlib" A quick Google search about this showed that several related issues has been detected and fixed in Conectiva: http://bugzilla.conectiva.com/show_bug.cgi?id=4171 So the question is, are we using the scripts rigth from the PADL guys? Is there any other source for this? Are they (or me) using the right schemas? Maybe I'm missing anything? I'll be willing to contribute a corrected version of the migrate_passwd.ph script should you confirm I'm using the right openldap and schema versions.
These tools come straight from PADL. From what I can tell in the conectiva bug report (my Portuguese is pretty weak), it looks like the PADL tools aren't quite in sync w/ openldap. I'm not using ldap these days, so I can't test right now. Do we have an LDAP expert these days?
Guys, can y'all help?
I'll be working again on this soon, but I'm not an expert on LDAP, so I can only guess whenever a deprecated attribute is used from the information in the schemas provided in OpenLDAP. Anyway, I have a few questions: 1. As I told you before, it seems that these errros were fixed in the Conectiva distribution, so: are they using another source for the migrationtools? Do the PADL guys still maintain these tools? From http://www.padl.com/download/ it seems their latest version is dated ten months ago. 2. The migrationtools use some classes that seem to be missing in the schemas provided by OpenLDAP. I'm talking about kerberosSecurityObject. This can be found in http://people.redhat.com/nalin/schema/kerberosobject.schema. Is this a standard schema? It seems this schema is included in the RedHat distribution. Where did it come from?
Definitely, the kerberosobject.schema was created by Red Hat. As you can read at http://www.alvestrand.no/objectid/1.3.6.1.4.1.2312.html or http://www.iana.org/assignments/enterprise-numbers, the 1.3.6.1.4.1.2312 OID is a private enterprise number belonging to Red Hat.
I've been working on this. I have found the following problems: A. migrate_passwd.pl file: 1. Undefined attribute krbName. This seems to be an attribute needed for integration between Kerberos 4 and LDAP (http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/15.html). I have found the definition of this attribute in an old version of core.schema (v 1.7.2.19). I found this in the openldap-servers-2.0.27-8.i386.rpm package from Red Hat. 2. Undefined objectClass mailRecipient, (line 128). This seems to be wrong, changed to inetLocalMailRecipient, found in misc.schema, line 37. 3. Problem while adding entries, with EXTENDED_SCHEMA activated (migrate_common.ph, line 90). The error follows: ldap_add: Object class violation (65) additional info: invalid structural object class chain (inetOrgPerson/account) The problem here is that in recent versions of LDAP, you can only assign one STRUCTURAL objectClass to any object, unless they are in the same hierarchy. In this case, the scripts are trying to assign (line 130) two conflicting object classes: inetOrgPerson (inetorgperson.schema, line 129) and account (cosine.schema, line 1092). A possible workaround for this is to change the account object class from STRUCTURAL to AUXILIARY. The real problem here is that I don't really know if both sets of attributes from inetOrgPerson and account are needed, and in case they are, it seems you should have 'duplicated' objects in the LDAP directory, one for storing information about somebody and another one for storing its account. 4. Undefined objectClass kerberosSecurityObject. After googling for this, I found it in the openldap-servers-2.0.27-8.i386.rpm package from Red Hat in a file named kerberosobject.schema. I added it to the openldap schemas B. migrate_services.pl 1. Error while migrating services. The problem seems to be that the scripts try to add the services using the following DNs: cn=service,ou=Services,... In /etc/services there are several duplicated services, with one line for tcp and another one for udp. I think the scripts are trying to import both of them with the same DN. To continue testing I bypass this step. And that's all. Additionaly, the Aliases, Mounts and Netgroup don't get populated. I've found that the line relative to fstab has been commented out... why? (migrate_all_online.sh, line 171)
Created attachment 32145 [details] Missing attribute and object class I include this file with the missing attribute krbName and the missing class kerberosSecurityObject. I have extracted this information from the schemas found in the OpenLDAP package, v2.0.27-8 from Red Hat
Can someone fix up the metadata.xml for this package please? It lists robbat2@gentoo.org and g2boojum@gentoo.org as maintainers right now which seems to be incorrect.
net-nds/migrationtools was designed and published for the 2.0 series of openldap. PADL still keeps it at the openldap-2.0 level with the barest of maintenance, while Connectiva seems to have upgraded it to be usable with openldap-2.1. The scripts were originally designed that you would modify them, then use them once-off to migrate your installation. If somebody could track down the SRPM of the connectiva package and/or Connectiva's patchs to fix it, I'd be willing to integrate it. Otherwise, due to the large scope of changes between 2.0 and 2.1 (And the impending release of 2.2), I'm strongly inclined to drop support of the package given that upstream doesn't support it much anymore. I've checked Debian's patches for migrationtools and they don't have any fix for the problem.
Created attachment 42684 [details, diff] Fix for "object class violation" error. I've just removed the account object class from the user entry. This might sound harsh for some (it sounded to me when I though about trying it) but please consider: 1. There are no attributes related to the account object class that aren't related to some other object class also included (like posixAccount); 2. I have been using the so migrated accounts for almost a month now without problems. At least none related to this issue ;) Resume: I can't find any reason to keep the account object class in the user entry and without it Migrationtools work.
I forgot to mention that the http://bugs.gentoo.org/attachment.cgi?id=42684&action=view patch applies cleanly both to Migrationtools-44 and to Migrationtools-45. Please consider including it on both ebuilds.
Just to clarify, my patch fixes issue 3 from comment #5 from Jose Gonzalez Gomez.
fixed in cvs for 44-r1 and 45.
