On 10/15/2014 10:05 PM, Rob Crittenden wrote:
Clint Savage wrote:
$ rpm -q ipa-server

I was thinking that this might be an issue with the rhel7 version. I'm
going to be trying the same migration tonight on rhel6. I know the IPA
version is older, and samba stuff might not work as it does in 3.3. I
haven't looked in RHEL 6.6 yet to see what version of IPA is available.
I tested using a fairly recent IPA master build (4.1+). I'm not
convinced it is related to any specific version, but different features
are available so I thought I'd try to duplicate on a more similar
footing (apples to apples comparision).

The trick is to try to narrow down what attribute the LDAP server thinks
already exists. We don't get a very nice error out of LDAP, like *what*
attribute already exists, for example :-(
It is all there:
[15/Oct/2014:18:35:48 -0400] conn=606 op=8 ADD dn="uid=amyengh,cn=users,cn=accounts,dc=example,dc=com", add values for type objectClass failed [15/Oct/2014:18:35:48 -0400] conn=606 op=8 RESULT err=20 tag=105 nentries=0 etime=0
and err=20 is type_or_value_exists.

Now this confirms Clint's observation that the problem goes away if the custom objectclass is removed.
And he said that adding the entry manually (I assume ldapmodify) works.
Is there a possibility that the migrate script adds the custom objectclass again ?

It may be possible to set the 389-ds debug level to such that you get
some decent output, but trying to find the right balance of output can
be challenging. See their FAQ troubleshooting section.



On Wed, Oct 15, 2014 at 1:16 PM, Rob Crittenden <rcrit...@redhat.com
<mailto:rcrit...@redhat.com>> wrote:

     Ludwig Krispenz wrote:
     > On 10/14/2014 06:58 PM, Clint Savage wrote:
     >> Hi all,
     >> I've been working on a migration plan using three custom user
     >> objectClasses and one group objectclass. In my attempt, I've setup an
     >> openldap server with the proper schemas, imported the ldif and have
     >> records that look something like this in ldif format.
     >> dn: dc=example,dc=com
     >> objectClass: top
     >> objectClass: domain
     >> dc: example
     >> dn: ou=Groups,dc=example,dc=com
     >> objectClass: top
     >> objectClass: organizationalunit
     >> ou: Groups
     >> dn: ou=People,dc=example,dc=com
     >> objectClass: top
     >> objectClass: organizationalunit
     >> ou: People
     >> dn: uid=amyengh,ou=People,dc=example,dc=com
     >> objectClass: inetOrgPerson
     >> objectClass: posixAccount
     >> objectClass: top
     >> objectClass: organizationalPerson
     >> objectClass: person
     >> objectClass: radiusProfile
     >> objectClass: sambaSamAccount
     >> objectClass: customPersonAttributes
     >> cn: Amy Engh
     >> gidNumber: 1141801056
     >> homeDirectory: /home/amyengh
     >> sn: Engh
     >> uid: amyengh
     >> uidNumber: 1141801056
     >> displayName: Amy Engh
     >> givenName: Amy
     >> loginShell: /sbin/nologin
     >> mail: amye...@attask.com <mailto:amye...@attask.com>
     <mailto:amye...@attask.com <mailto:amye...@attask.com>>
     >> userPassword:: REDACTED
     >> dialupAccess: yes
     >> radiusTunnelMediumType: IEEE-802
     >> radiusTunnelPrivateGroupId: 1421
     >> radiusTunnelType: VLAN
     >> emailPassword:: REDACTED
     >> sambaAcctFlags: [U          ]
     >> sambaLMPassword: REDACTED
     >> sambaNTPassword: REDACTED
     >> sambaPasswordHistory:
     >> 000000000000000000000000000000000000000000000000000000
     >>  0000000000
     >> sambaPwdLastSet: 1402698001
     >> sambaSID: S-1-5-21-2332447373-4108748234-3602490535-3146
     >> dn: cn=amyengh,ou=Groups,dc=example,dc=com
     >> objectClass: top
     >> objectClass: posixGroup
     >> cn: amyengh
     >> gidNumber: 1141801056
     >> memberUid: amyengh
     >> --------------------------------------------------------------------
     >> I then run the migration (with or without compat makes no difference)
     >> and get the following:
     >> ipa migrate-ds --with-compat --user-container="ou=People"
     >> --group-container="ou=Groups" --user-objectclass=posixAccount
     >> --group-objectclass=posixgroup ldap://
     >> <> --bind-dn="cn=Manager,dc=example,dc=com"
     >> Password:
     >> -----------
     >> migrate-ds:
     >> -----------
     >> Migrated:
     >> Failed user:
     >>   amyengh: Type or value exists:
     >> Failed group:
     >>   amyengh: This entry already exists.
     > "type or value exists" and "This entry already exists" are just
     > explanations of the ldap return code, do you see anything in the 389 ds
     > error logs ?

     I doubt that he would see any errors.

     The entry already existing is because this isn't his first migration, it
     is unrelated.

     I'm not able to reproduce this. What version of IPA is it?


     Manage your subscription for the Freeipa-users mailing list:
     Go To http://freeipa.org for more info on the project

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to