Re: back-sql insert: entry at root denied

[Brad Midgley <bmidgley@xmission.com>]

Pierangelo

I was hoping to preserve the view. The data is being changed by sybase 
clients and I'd need to set up the appropriate triggers to update it. 
That is an option I'll consider though.

This version of sybase does not support union in a view. I already 
looked down that avenue.

From reading the code, I started to think it was possible to do without 
the parent in the db. The suffix entry is not found, but down later in 
that section of code is

if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
 || !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e ) )
{ ... } else {
	parent_id.eid_id = 0;
}

So I was thinking I could coax it to take that branch and assume the 
parent has the id 0 even though it wasn't found. Does this approach have 
implications that make it too messy or painful?

I have insentry_query set to "" in my config. I could test for that 
empty value if necessary when handling add or modrdn. Or I could set 
insentry_query to some kind of no-op that accepts four parameters, but I 
certainly prefer to have any patches I make accepted upstream. I don't 
think you'd want the blind assumption that if the parent isn't found we 
can just use an id of 0.

Brad

> After reading your link, I realized what the problem is: if you intend to
> add (or modrdn) you can't use a view like that, because adds and modrdns
> need to write table ldap_entries.  I don't know yet what type of
> interaction prevents you from writing; I guess the view is somehow failing
> when there's no data to view?  In any case, you definitely need a real
> table
> to do writes.  In principle, you could work things around by adding a
> "parent" to your view, e.g. by UNIONing your view with another that
> defines your rootdn, and tweaking the "insentry_query" directive to
> actually do nothing instead of trying to add to ldap_entries.  I've never
> tried anything like that, though.  If you succeed, please post.  I'll be
> creating a subfolder for back-sql hints in the FAQ shortly.
>
> p.
>
>
> > Hi
> >
> > I am trying to take back-sql to the next step and allow inserts. I have
> > been able to get by without having the actual suffix dcObject in the
> > directory and it looks like the back-sql backend can deal with that.
> > However, it fails because this clause in add.c fires:
> >
> > if ( ( ( !be_isroot( op ) && !be_shadow_update( op ) )
> >  || !BER_BVISEMPTY( &pdn ) ) && !is_entry_glue( op->oq_add.rs_e ) )
> >
> > The log produces "entry at root denied" so BER_BVISEMPTY( &pdn ) returns
> > false.
> >
> > I've tried to give access both by using
> > rootdn		"dc=utips_admin,dc=my,dc=uen,dc=org"
> > and
> > access to dn="dc=my,dc=uen,dc=org"
> >         by dn="uid=utips_admin,dc=my,dc=uen,dc=org" write
> >
> > Using openldap-cvs updated today.
> >
> > in slapd.conf:
> > suffix		"dc=my,dc=uen,dc=org"
> >
> > new record:
> > dn: uid=pbmidgley,dc=my,dc=uen,dc=org
> > changetype: add
> > objectclass: inetOrgPerson
> > uid: pbmidgley
> > telephoneNumber: 801-555-5561
> > userPassword: passiton
> > sn: Midgley
> > cn: Brad Midgley
> >
> > command & output:
> > ldapadd -H ldap://iceman.uen.org -D uid=utips_admin,dc=my,dc=uen,dc=org
> > -x -W -f mid
> > adding new entry "uid=pbmidgley,dc=my,dc=uen,dc=org"
> > ldapadd: update failed: uid=pbmidgley,dc=my,dc=uen,dc=org
> > ldap_add: No such object (32)
> >
> > fwiw, more logs and configs are at
> > http://www.xmission.com/~bmidgley/openldap2/
> >
> > Brad