[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapadd: update failed: - Server Migration

Albert Whale wrote:

Ok, here's the situation. I am migrating an OpenLDAP environment from RedHat 8.0 to Mandrake 10.0. The RedHat disto is on it's last legs, and this is vital to replacement of the server.

I guess stating from what version of OpenLDAP to what version of OpenLDAP might be much more helpful...

Os far I have followed the Migration of the data from the RedHat 8.0 distribution as follows:

service ldap stop
slapcat -b "dc=example,dc=net" -l /var/example.ldif <----- Note example is not hte domain name.
service ldap start

scp /var/example.ldif newserver:/var

sladadd -l /var/example.ldif

This I Assume (I really don't like this word), migrates the existing LDAP DB to the New Server (I have implmented SIMILAR slapd.conf settings as well).

This is where the problem starts. When I attempt to add a New User to LDAP Service on the New Server I get the update failed.

/usr/bin/ldapadd -f /var/tmp/user.ldif -D "cn=manager,dc=example,dc=net" -H ldap://localhost -x -w secret
adding new entry "uid=adamw, ou=users, dc=example, dc=net"
ldapadd: update failed: uid=adamw, ou=users, dc=example, dc=net
ldap_add: Internal (implementation specific) error (80)
additional info: no structuralObjectClass operational attribute

The user.ldif file contains the following:

dn: uid=adamw, ou=users, dc=example, dc=net
cn: Test Account
sn: Test Account
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
objectclass: quotaAccount
uid: adamw
uidNumber: 500
gidNumber: 500
loginShell: /bin/sh
homeDirectory: /home/adamw
softWebQuota: 2048
hardWebQuota: 2048
softMailQuota: 20480
hardMailQuota: 20480
userPassword: {CRYPT}PsltqeQ3/fr9k

The contents of slad.conf includes the following:

loglevel 256
database        ldbm
suffix          "dc=example,dc=net"
rootdn          "cn=manager,dc=example,dc=net"
rootpw                  {CRYPT}cyreM52GE8p8c

directory       /var/lib/ldap

index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
index   cn,mail,surname,givenname                       eq,subinitial

updatedn        "cn=manager,dc=wpia,dc=net"

grep -v "^#" /etc/openldap/slapd.access.conf

access to dn=".*,dc=example,dc=net" by self write by * read

access to dn=".*,dc=example,dc=net" attr=userPassword
       by dn="cn=manager,o=limbach,c=us" write
       by self write
       by * auth

access to dn=".*,ou=users,dc=example,dc=net"
       by * read

access to dn=".*,ou=users,dc=example,dc=net" attr=userPassword
       by self write
       by * auth

Any ideas?

looks like the identity you're binding as is the updatedn of a replica; as such, slapd expects you to provide a set of operational attributes that must be sent when replicating info, but must not be provided for regular add operations. Indeed, you have an "updatedn" directive in your slapd.conf, but it's different from the identity you're using. Unless you massaged the info you cut'n'pasted in your mail, all I can infer is that the (yet unknown) version of slapd you're using simply uses the notion of an updatedn being defined to consider that database a replica, and thus expects replica-like modifications to be submitted with add operations, although they're not submitted via the appropriate identity. As soon as you submit appropriate data, it will check the identity of the issuer and refer you to a referral if you're not using the updatedn identity. In any case, you better remove the updatedn directive if your slapd instance is not a replica, otherwise you better use it as a replica (i.e. do not directly write to it).


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497