Hello,

Can I know the reason why it is not implemented?

Thanks in advance,

Arunachalam

**************************************************************************** ****************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Monday, August 06, 2007 11:46 PM To: arunachalamp@huawei.com Cc: openldap-software@openldap.org Subject: Re: Deleting subtree - server side

Arunachalam Parthasarathy wrote:

Hello all,

Is the openldap2.3.36 server supports, deleting a subtree. I mean, I know

that through -r option to ldapdelete, this is possible. Using HDB, as

openldap server is supporting move, is delete subtree possible in server

side?

No, it's not.

p.

Ing. Pierangelo Masarati

OpenLDAP Core Team

SysNet s.r.l.

via Dossi, 8 - 27100 Pavia - ITALIA

http://www.sys-net.it

---------------------------------------

Office: +39 02 23998309

Mobile: +39 333 4963172

Email: pierangelo.masarati@sys-net.it

---------------------------------------

Hello mr. Pierangelo Masarati,

Thanks for the reply. But, is move subtree operation (implemented in openldap server side) is a combination of delete subtree and add right?

Or is it like changing the references in the dn2id file?

Thanks in advance,

Arunachalam.

**************************************************************************** ****************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Tuesday, August 07, 2007 3:28 PM To: arunachalamp@huawei.com Cc: openldap-software@openldap.org Subject: Re: Deleting subtree - server side

Arunachalam Parthasarathy wrote:

Hello,

Can I know the reason why it is not implemented?

Yes.

Basically, it's an operation that is not atomic in pure LDAP (namely, it

requires more than a write operation), and thus it could be implemented

in many different ways (I mean: handling errors and conflicts in many

different ways). So there should be:

1) a need for it

2) an agreed specification about how to do it

3) someone who codes it.

I recall seeing some old specification (e.g.

<draft-armijo-ldap-treedelete>, expired 2001). A much better approach

would be to use LDAP transactions (e.g. <draft-zeilenga-ldap-txn>) so

that the operation either fails or succeeds atomically. In OpenLDAP

there's experimental support for transactions, but I'm not sure subtree

deletion can be performed right now.

p.

Ing. Pierangelo Masarati

OpenLDAP Core Team

SysNet s.r.l.

via Dossi, 8 - 27100 Pavia - ITALIA

http://www.sys-net.it

---------------------------------------

Office: +39 02 23998309

Mobile: +39 333 4963172

Email: pierangelo.masarati@sys-net.it

---------------------------------------

Pierangelo Masarati wrote:

Arunachalam Parthasarathy wrote:

...

Thanks for the reply. But, is move subtree operation (implemented in openldap server side) is a combination of delete subtree and add right?

Or is it like changing the references in the dn2id file?

No, if it were like that it would be uniformly available for all databases.

It actually consists in changing the parent/child relationship between two entries, exploiting underlying Berkeley DB transactions while performing an LDAP atomic operation (rename). This is possible because slapd-hdb does not store the full name of an entry within the entry itself, but only parent/child relationships (the "h" stands for "hierarchical" and not for "Howard", the author ;), from which the full DN is recursively reconstructed.

"Howard DB", I wonder what you would store in it ;-)

Pierangelo Masarati wrote:

...

I recall seeing some old specification (e.g. <draft-armijo-ldap-treedelete>, expired 2001).

I'm confused now. HEAD announces LDAP_SERVER_TREE_DELETE_OID (1.2.840.113556.1.4.805) in its rootDSE. So I thought this control is already implemented in HEAD (upcoming 2.4). Yes?

No. Some time ago, I was planning to implement it in back-sql, but never completed that work. So, yes, slapd recognizes this control (HEAD only), but no backend handles it.

...

A much better approach would be to use LDAP transactions (e.g. <draft-zeilenga-ldap-txn>) so that the operation either fails or succeeds atomically.

Hmm, but with this approach the client would still have to send all the delete requests for single entries. Yes? This is bad for performance (very chatty on the wire, many LDAP requests to process in the frontend of the server. etc.). I think subtree deletion could be handled on the server-side more efficiently. From the client's perspective it's atomic processing of a single delete request.

Well, I didn't mean it like that. I meant that along the lines of the implementation of txn, transactional multiple deletes could be performed. This would allow back-bdb and back-hdb to support that control (and ease many internal operations that would be much better with transactional semantics, think of slapo-refint and so).

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------

Then please remove it from rootDSE. It does not make sense at all to be advertised in 'supportedControl'.

It's hidden, in fact. You're not supposed to treat HEAD as released code, and you won't see it advertised in re24 (until it works, at least).

In any case, there's nothing wrong in advertising support for a control and returning unwillingToPerform or unavailableCriticalExtension: in both cases it's correct. It means that the DSA recognizes the control but either does not want, or cannot apply it in the case requested by the client. It's LDAPv3 anyway.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------

Michael Ströder wrote:

Pierangelo Masarati wrote:

...

...

Then please remove it from rootDSE. It does not make sense at all to be advertised in 'supportedControl'.

It's hidden, in fact. You're not supposed to treat HEAD as released code, and you won't see it advertised in re24 (until it works, at least).

But it's not hidden behind LDAP_DEVEL.

Yes, it is: it's registered as SLAP_CTRL_HIDE

...

In any case, there's nothing wrong in advertising support for a control and returning unwillingToPerform or unavailableCriticalExtension: in both cases it's correct. It means that the DSA recognizes the control but either does not want, or cannot apply it in the case requested by the client. It's LDAPv3 anyway.

I expected this answer.

:)

But it makes life of a client developer even more miserable than it already is. See, I'd like to implement support for draft-armijo-ldap-treedelete in web2ldap. And off course I'd like to provide an appropriate UI. Hence I have to somewhat trust what's there in rootDSE in attributes supported* (except things like StartTLS ext. op. off course).

But, for example, there's cases like syncrepl, which is advertised by the rootDSE but only supported by a fraction of the databases, namely those that instantiate the syncprov overlay (and not all of the backends actaully support it).

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------