Menu
▾
▴
perl-ldap-dev
|
From: Tom S. <to...@un...> - 2000-08-15 14:29:40
|
I'm attempting to delete an entry that contains sub entries that contain sub entries and receiving this error: LDAP_NOT_ALLOWED_ON_NONLEAF I've found that if I go down to the bottom, I could delete, by working my way back out. Is there a simpler way? Is there a way to tell from an entry if there are sub trees besides checking for the error or searching down? Tom Sherrod to...@sa... |
|
From: Mark W. <mew...@un...> - 2000-08-15 15:28:55
|
You must delete all children entries first before you can delete any parent entries. Mark On Tue, 15 Aug 2000, Tom Sherrod wrote: > I'm attempting to delete an entry that contains sub entries that > contain sub entries and receiving this error: > LDAP_NOT_ALLOWED_ON_NONLEAF > > I've found that if I go down to the bottom, I could delete, by working my > way back out. > Is there a simpler way? Is there a way to tell from an entry if there are > sub trees besides checking for the error or searching down? > > Tom Sherrod to...@sa... > > > |
|
From: John B. <joh...@ne...> - 2000-08-16 13:29:37
|
> You must delete all children entries first before you can delete any > parent entries. Net::LDAP::Util::ldap_delete_tree anyone? Is the consensus that things which are high-level and which several applications might want to do could find a home in the ::Util module? > On Tue, 15 Aug 2000, Tom Sherrod wrote: > > > I'm attempting to delete an entry that contains sub entries that > > contain sub entries and receiving this error: > > LDAP_NOT_ALLOWED_ON_NONLEAF > > > > I've found that if I go down to the bottom, I could delete, by working my > > way back out. > > Is there a simpler way? Is there a way to tell from an entry if there are > > sub trees besides checking for the error or searching down? > > > > Tom Sherrod to...@sa... > > > > > > > > |
|
From: Graham B. <gb...@po...> - 2000-08-16 13:58:38
|
On Wed, Aug 16, 2000 at 02:29:20PM +0100, John Berthels wrote: > > > > You must delete all children entries first before you can delete any > > parent entries. > > Net::LDAP::Util::ldap_delete_tree anyone? Sure, but someone mentioned a control for this. > Is the consensus that things which are high-level and which several > applications might want to do could find a home in the ::Util module? That is what is was intended for. Graham. > > > On Tue, 15 Aug 2000, Tom Sherrod wrote: > > > > > I'm attempting to delete an entry that contains sub entries that > > > contain sub entries and receiving this error: > > > LDAP_NOT_ALLOWED_ON_NONLEAF > > > > > > I've found that if I go down to the bottom, I could delete, by working my > > > way back out. > > > Is there a simpler way? Is there a way to tell from an entry if there are > > > sub trees besides checking for the error or searching down? > > > > > > Tom Sherrod to...@sa... > > > > > > > > > > > > > > > > |
|
From: John B. <joh...@ne...> - 2000-08-17 12:16:01
|
On Wed, 16 Aug 2000, John Berthels wrote:
>
>
> > You must delete all children entries first before you can delete any
> > parent entries.
>
> Net::LDAP::Util::ldap_delete_tree anyone?
This one return true/false and sets $!. I realise this is a bit odd -
would it be better to propogate the Net::LDAP::Message back to the caller?
jb
sub ldap_delete_tree {
my $ldap = shift;
my $dn = shift;
my $msg = $ldap->search( base => $dn,
scope => 1,
filter => "(objectclass=*)",
attr => [ "1.1" ]
);
unless( $msg->code() == LDAP_SUCCESS ) {
$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
return undef;
}
#
# Recursively get rid of children, if any
#
foreach my $entry ( $msg->entries() ) {
my $dn = $entry->dn();
return undef unless ldap_delete_tree( $ldap, $dn );
}
# And then ourselves
$msg = $ldap->delete( $dn );
unless( $msg->code() == LDAP_SUCCESS ) {
$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
return undef;
}
return 1;
}
|
|
From: Graham B. <gb...@po...> - 2000-08-17 12:42:52
|
On Thu, Aug 17, 2000 at 01:15:50PM +0100, John Berthels wrote:
> On Wed, 16 Aug 2000, John Berthels wrote:
>
> >
> >
> > > You must delete all children entries first before you can delete any
> > > parent entries.
> >
> > Net::LDAP::Util::ldap_delete_tree anyone?
>
>
> This one return true/false and sets $!. I realise this is a bit odd -
You cannot set $!, Reading $! always reads errno from C. Setting $@ would
be better.
> would it be better to propogate the Net::LDAP::Message back to the caller?
How would you do that ? Return the message on error and undef otherwise ?
Also I would rather avoid recursion if possible, I hate recursion.
Something like (untested)
sub ldap_delete_tree {
my $ldap = shift;
my @dn = @_;
while (@dn) {
my $msg = $ldap->search( base => $dn[0],
scope => 1,
filter => "(objectclass=*)",
attr => [ "1.1" ]
);
unless( $msg->code() == LDAP_SUCCESS ) {
$@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
return undef;
}
if ($msg->count) {
#
# We have children
#
unshift @dn, $msg->entries;
next;
}
# And then ourselves
$msg = $ldap->delete( shift @dn );
unless( $msg->code() == LDAP_SUCCESS ) {
$@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
return undef;
}
}
return 1;
}
Graham.
|
|
From: John B. <joh...@ne...> - 2000-08-17 15:57:18
|
> > This one return true/false and sets $!. I realise this is a bit odd -
>
> You cannot set $!, Reading $! always reads errno from C. Setting $@ would
> be better.
Gack. I should have read the complete perlvar entry. Apparently you can
set it but only numeric values, which would then get represented as the
relevent errno strings. Not useful, $@ it is.
> > would it be better to propogate the Net::LDAP::Message back to the caller?
>
> How would you do that ? Return the message on error and undef otherwise ?
I guess you could (gack. 'undef' return means success). Or construct a new
::Message object with a success code? Or stay with what we have here?
> Also I would rather avoid recursion if possible, I hate recursion.
Fair enough. Its your module. I've got as far as putting the opening brace
of a sub on the same line as the name, so I'm gradually getting in sync
with your style :-)
I'm not sure I'll easily do the ->save/load as non-recursive though.
[snip nice non-recursive tree_delete]
Nice - except this bit:
> my $msg = $ldap->search( base => $dn[0],
> scope => 1,
> filter => "(objectclass=*)",
> attr => [ "1.1" ]
> );
>
> unless( $msg->code() == LDAP_SUCCESS ) {
> $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
> return undef;
> }
>
> unshift @dn, $msg->entries;
needs
> unshift @dn, map { $_->dn() } $msg->entries;
Or perhaps you mean:
unshift @dn, $ldap->list( $dn );
instead :-)
regards,
jb
|
|
From: Graham B. <gb...@po...> - 2000-08-17 16:11:59
|
On Thu, Aug 17, 2000 at 04:56:56PM +0100, John Berthels wrote:
> > > would it be better to propogate the Net::LDAP::Message back to the caller?
> >
> > How would you do that ? Return the message on error and undef otherwise ?
>
> I guess you could (gack. 'undef' return means success). Or construct a new
> ::Message object with a success code? Or stay with what we have here?
Well the ::Message in CVS now has is_error, which could be changed to
->success
But you loose the usage of the return value as a meaning of success :(
> > Also I would rather avoid recursion if possible, I hate recursion.
>
> Fair enough. Its your module.
Not really, not any more. Yes I started it and I may have written most
of whats there. But I see most of it's future development coming
from others, hopefully I can be a good guide in the process.
> I've got as far as putting the opening brace
> of a sub on the same line as the name, so I'm gradually getting in sync
> with your style :-)
:)
> I'm not sure I'll easily do the ->save/load as non-recursive though.
Oh, I don't know. There is normally a way. But write it as recursive if
thats what you feel most comfortable with. Someone with some spare
time can always change it later. Often there is not much to change, notice I made little change to your
code for the tree delete.
>
> [snip nice non-recursive tree_delete]
>
> Nice - except this bit:
>
> > my $msg = $ldap->search( base => $dn[0],
> > scope => 1,
> > filter => "(objectclass=*)",
> > attr => [ "1.1" ]
> > );
> >
> > unless( $msg->code() == LDAP_SUCCESS ) {
> > $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
> > return undef;
> > }
> >
> > unshift @dn, $msg->entries;
>
> needs
>
> > unshift @dn, map { $_->dn() } $msg->entries;
No. base to ->search can be an Entry object. In which case ->search
will call ->dn for you.
> Or perhaps you mean:
>
> unshift @dn, $ldap->list( $dn );
>
> instead :-)
Maybe, but then I loose the Message, so I don't know if there are no
children of if there was an error. I guess I could check $@.
Graham.
|
|
From: John B. <joh...@ne...> - 2000-08-17 16:24:46
|
> Not really, not any more. Yes I started it and I may have written most
> of whats there. But I see most of it's future development coming
> from others, hopefully I can be a good guide in the process.
Yes. Someone needs to enforce taste and decency otherwise things become a
mess.
> > I'm not sure I'll easily do the ->save/load as non-recursive though.
>
> Oh, I don't know. There is normally a way. But write it as recursive
> if thats what you feel most comfortable with. Someone with some spare
> time can always change it later. Often there is not much to change,
> notice I made little change to your code for the tree delete.
Yes. I'm sure its do-able, just not sure *I'll* do it easily :-)
> > > unshift @dn, map { $_->dn() } $msg->entries;
>
> No. base to ->search can be an Entry object. In which case ->search
> will call ->dn for you.
Hmm. Has that changed recently in CVS? I actually tried it and got a 'Bad
DN Syntax' error. But I was using an old version of Net::LDAP I think.
> > Or perhaps you mean:
> >
> > unshift @dn, $ldap->list( $dn );
> >
> > instead :-)
>
> Maybe, but then I loose the Message, so I don't know if there are no
> children of if there was an error. I guess I could check $@.
Or save the original DN arg as $dn_orig and:
return !$ldap->exists( $dn_orig );
at the end.
jb
|
|
From: Graham B. <gb...@po...> - 2000-08-17 16:45:51
|
On Thu, Aug 17, 2000 at 05:24:34PM +0100, John Berthels wrote:
>
> > Not really, not any more. Yes I started it and I may have written most
> > of whats there. But I see most of it's future development coming
> > from others, hopefully I can be a good guide in the process.
>
> Yes. Someone needs to enforce taste and decency otherwise things become a
> mess.
I hope to be that person.
> > > > unshift @dn, map { $_->dn() } $msg->entries;
> >
> > No. base to ->search can be an Entry object. In which case ->search
> > will call ->dn for you.
>
> Hmm. Has that changed recently in CVS? I actually tried it and got a 'Bad
> DN Syntax' error. But I was using an old version of Net::LDAP I think.
Veru old. It went in version 0.16, which was when I changed from Convert::BER
to Convert::ASN1
> > > Or perhaps you mean:
> > >
> > > unshift @dn, $ldap->list( $dn );
> > >
> > > instead :-)
> >
> > Maybe, but then I loose the Message, so I don't know if there are no
> > children of if there was an error. I guess I could check $@.
>
> Or save the original DN arg as $dn_orig and:
>
> return !$ldap->exists( $dn_orig );
>
> at the end.
But not existing may not be the only reason for failure.
Graham.
|
|
From: Stefan P. <st...@me...> - 2000-08-18 08:24:44
|
Hi there,
is there any good way to read/write into the DS
in utf8 ?
i dont wanna do it that way :
print utf8($entry->get("configattributname"));
by the way, i am still using 0.14 ..
will the application still work when i upgrade ?
thanx,
stefan
|
|
From: Mark W. <mew...@un...> - 2000-08-18 13:03:24
|
as I understand it (I"m sure Chris or Kurt will correct me :), the
'native' string format for LDAP 3 is utf8.
Many LDAP APIs use utf8 internally, but Net::LDAP isn't one of them
because Perl doesn't have true, native support for utf8 yet (it's better
in 5.6, but don't use 5.6, it's buggy & Net::LDAP is great bug bait for
5.6).
Until then, you might have to do something like you showed below.
Mark
On Fri, 18 Aug 2000, Stefan Poschenrieder wrote:
> Hi there,
>
> is there any good way to read/write into the DS
> in utf8 ?
> i dont wanna do it that way :
> print utf8($entry->get("configattributname"));
>
> by the way, i am still using 0.14 ..
> will the application still work when i upgrade ?
>
>
> thanx,
> stefan
>
>
|
|
From: Chris R. <chr...@me...> - 2000-08-21 12:02:03
|
Mark Wilcox <mew...@un...> wrote:
> as I understand it (I"m sure Chris or Kurt will correct me :), the
> 'native' string format for LDAP 3 is utf8.
>
> Many LDAP APIs use utf8 internally, but Net::LDAP isn't one of them
> because Perl doesn't have true, native support for utf8 yet (it's better
> in 5.6, but don't use 5.6, it's buggy & Net::LDAP is great bug bait for
> 5.6).
>
> Until then, you might have to do something like you showed below.
>
> Mark
Yup, I agree. We also should remember that Net::LDAP supports LDAPv2, and
will bind by default also using LDAPv2. It is not legal to use UTF-8 using
LDAPv2.
>
>
> On Fri, 18 Aug 2000, Stefan Poschenrieder wrote:
>
>> Hi there,
>>
>> is there any good way to read/write into the DS
>> in utf8 ?
>> i dont wanna do it that way :
>> print utf8($entry->get("configattributname"));
>>
>> by the way, i am still using 0.14 ..
>> will the application still work when i upgrade ?
There are some minor API differences. The ChangeLog file should list all of
these:
http://perl-ldap.sourceforge.net/perl-ldap-0.20/ChangeLog
Cheers,
Chris (back from Japan!)
|
|
From: Kurt D. Z. <Ku...@Op...> - 2000-08-23 14:26:27
|
At 07:56 AM 8/18/00 -0500, Mark Wilcox wrote: >as I understand it (I"m sure Chris or Kurt will correct me :), the >'native' string format for LDAP 3 is utf8. More precisely, LDAPv3 strings are UTF-8 encoded ISO/IEC 10646-1. LDAPv2 strings are T.61. Most APIs I use (C and Perl) are charset neutral. That is, they require the client to provide properly encoded strings per the protocol in use. Notable exceptions are Java based APIs. Java supports Unicode, albeit a 16-bit version. This is actually quite problematic. Besides the obvious 16-bit<->31-bit issue and the Unicode<->T.61 issues, the API is generally not schema aware. The attribute value in question may require some other encoding. I believe it best for low-level protocol APIs to be dumb. That is, they should provide as direct as possible interface between the application and the protocol. The more stuff this API does on behalf of the application, the less applications can do with it. I am, however, a big fan of layering high-level APIs on top of lower-level ones... In terms of charset issues, I rather the low-level API just pass a string of octets. Kurt |
|
From: Mark W. <mew...@un...> - 2000-08-17 14:13:01
|
I'm +1 for returning Net::LDAP::Message because that's what we normally
get.
I think anything under Net::LDAP:: that's not part of the simple API, it
should return the Message object.
Mark
On Thu, 17 Aug 2000, John Berthels wrote:
> On Wed, 16 Aug 2000, John Berthels wrote:
>
> >
> >
> > > You must delete all children entries first before you can delete any
> > > parent entries.
> >
> > Net::LDAP::Util::ldap_delete_tree anyone?
>
>
> This one return true/false and sets $!. I realise this is a bit odd -
> would it be better to propogate the Net::LDAP::Message back to the caller?
>
> jb
>
>
>
> sub ldap_delete_tree {
> my $ldap = shift;
> my $dn = shift;
>
> my $msg = $ldap->search( base => $dn,
> scope => 1,
> filter => "(objectclass=*)",
> attr => [ "1.1" ]
> );
> unless( $msg->code() == LDAP_SUCCESS ) {
> $! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> return undef;
> }
>
> #
> # Recursively get rid of children, if any
> #
> foreach my $entry ( $msg->entries() ) {
> my $dn = $entry->dn();
> return undef unless ldap_delete_tree( $ldap, $dn );
> }
>
> # And then ourselves
> $msg = $ldap->delete( $dn );
> unless( $msg->code() == LDAP_SUCCESS ) {
> $! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> return undef;
> }
>
> return 1;
> }
>
>
>
>
|
|
From: Graham B. <gb...@po...> - 2000-08-17 14:31:02
|
On Thu, Aug 17, 2000 at 09:06:07AM -0500, Mark Wilcox wrote:
> I'm +1 for returning Net::LDAP::Message because that's what we normally
> get.
Hm..
> I think anything under Net::LDAP:: that's not part of the simple API, it
> should return the Message object.
Well I guess this is debatable if it is part of either.
I would not say it is part of the main API as it performs multiple requests
and so cannot be used in async mode. (well it could if it was re-written
to do everything with callback, an exercise for the reader :)
And I would not say it was part of the simple API because it's not
a simplified view of something the main API can do. Well it is, but
it's also useful to the main API. So it is a Util.
Now the question of what Util subs should return ?
Graham,
> Mark
>
> On Thu, 17 Aug 2000, John Berthels wrote:
>
> > On Wed, 16 Aug 2000, John Berthels wrote:
> >
> > >
> > >
> > > > You must delete all children entries first before you can delete any
> > > > parent entries.
> > >
> > > Net::LDAP::Util::ldap_delete_tree anyone?
> >
> >
> > This one return true/false and sets $!. I realise this is a bit odd -
> > would it be better to propogate the Net::LDAP::Message back to the caller?
> >
> > jb
> >
> >
> >
> > sub ldap_delete_tree {
> > my $ldap = shift;
> > my $dn = shift;
> >
> > my $msg = $ldap->search( base => $dn,
> > scope => 1,
> > filter => "(objectclass=*)",
> > attr => [ "1.1" ]
> > );
> > unless( $msg->code() == LDAP_SUCCESS ) {
> > $! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> > return undef;
> > }
> >
> > #
> > # Recursively get rid of children, if any
> > #
> > foreach my $entry ( $msg->entries() ) {
> > my $dn = $entry->dn();
> > return undef unless ldap_delete_tree( $ldap, $dn );
> > }
> >
> > # And then ourselves
> > $msg = $ldap->delete( $dn );
> > unless( $msg->code() == LDAP_SUCCESS ) {
> > $! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> > return undef;
> > }
> >
> > return 1;
> > }
> >
> >
> >
> >
>
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X