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

Re: back-sql insert: entry at root denied


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.


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



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

I've tried to give access both by using
rootdn		"dc=utips_admin,dc=my,dc=uen,dc=org"
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