Re: ldapadd: update failed: - Server Migration

[Pierangelo Masarati <ando@sys-net.it>]

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).

p.




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