perl-ldap-dev

Re: Convert::ASN1 loading times

[John B. <jj...@be...>]

On Mon, 14 Aug 2000, Graham Barr wrote:

> John, this looks good and is certainly what I was thinking of.
> 
> Could you describe the format of your custom format. I cannot see
> exactly how it works.

Fair enough. Its pretty convoluted since I didn't initially allow for the
fact that the ASN.1 tree contains nodes which don't refer to tags (e.g.
the LDAPEntry definition, which is COMPONENTS OF). This was hacked on
later. I may need to rethink the whole thing :-)

> For example search for 0x80cadc0, which I think
> if supposed to be the root of the Filter, but I cannot see what I
> think is a definition.

That first (only) reference is a definition.

Pointers are defined in one of two ways. By occurring as the first or last
item on a line.

If the first item in a line is not a '_' it defines a new array reference
(blessed to be a Convert::ASN::parser). The contents of the referenced
array are the rest of the line. These correspond to the "cTAG cTYPE cVAR
cLOOP cOPT cCHILD".

If the last item in a line is not a '_' it either creates a new array
reference or adds to an existing one. In either case the reference is not
blessed and is stored as the cCHILD member of the containing array. The
contents of the referenced array are the nodes created by the following
lines (up to the next line with just a '-' on it).

The indentation is not used for parsing - but makes it more readable.

If the last item in a line is a '_' then the line was simple (no children)
and we stop recursion.

The case I initially didn't catch is the one now represented by a leading
'_'. This refers to a node in the tree which is a straight array ref, not
blessed to Convert::ASN::parser


There are currently bugs relating to the fact that for the cTAG member, I
map '' -> '0' -> (chr 0). I also introduce missing array elts as undef -
but I suspect that it OK. I don't fully understand your structures, I've
just tried to preserve them.


Comparing the Data::Dumper output of the tree as created by the real
Net::LDAP::ASN and as loaded from the file using the ->load() method show
a few differences, especially in the Filter definition. However, I'm not
sure that that isn't down to cosmetic reordering.


I wanted initially to order the output so that the reading order contained
no forward references. I then realised that this wasn't possible given the
self-referential nature of e.g. Filter. Thats when I gave up trying to
make it pretty :-)


If you haven't found it already, the ->save() method allows you to create
the .asn output.


If you like the idea I'll try and clean things up.


regards,

jb


PS. Some time ago you suggested I check out the Devel:: modules.  The
Devel::DProf module is cool. It shows up that
Net::LDAP::Schema::_get_one_word is a significant proportion (10-20%) of a
typical Schema load time. It is a one-liner used in two places, so
inlining is probably a good idea... are there any perl pragma's for this
yet or do we just cut and paste?

Re: new version of perl-ldap-0.20 (fwd)

[John B. <jj...@be...>]

> This email is highlighting more than one issue. Lets break it into parts and
> see what we can develop
> 
>  1) Net::LDAP::Entry
>
> In the case of 1) lets list what we should be able to do with an Entry and
> what a newbie would probably expect. Then compare that with what an expert
> would expect/need. It may not be that different.

Getting data simply
===================

This feels too indirect:

	my $msg = $l->search( ... );
	my @entries = $msg->entries();
	foreach my $entry ( @entries ) {
		my $attrs = $entry->get( "cn" );
		my $cn = shift @$attrs;	# Take first
		print "(First) Common name is {$cn]\n" if $cn;
	}

This also relates to the ->simple_read() in the other email about
Net::LDAP methods. It might be nice to have a '->get_one( "attr name" )'
method for ::Entry. This would return the first (or only) value from an
attribute. I guess it could keep an index so you step through them by
repeated calling - I don't know.




New advanced feature:
=====================

I think the ->update() method is really cool. However, I often find that I
am in a situation where I have (the moral equivalent of) a
Net::LDAP::Entry (from an LDIF, composed from a web form) and I want to
replace the directory entry.

->delete() followed by ->add() is easy but isn't atomic so you run the
risk of losing data.

->search(..) (or ->read() :-), followed by ->modify() is cool (only danger
is entry changing after the read()...less of a problem).
However, you need to compare the entry from the Diry to the entry you
have in order to generate the modify changelist.

A ->diff() method would be cool:

	my $old_entry = $l->read( $dn );
	my $new_entry = $ldif->read();
	my $changes_entry = $old_entry->diff( $new_entry );
	$changes_entry->update( $l );	# Maps down to a ->modify() call
	

Replace or delete existing picture

[Chelsie P. <Che...@ip...>]

Hi all,
	Does anyone know how to delete or replace an existing picture in the
repository?  It doesn't seem to be the same syntax as modifing the other
attributes.

Thanks,
Chelsie

Re: Perl-LDAP and returning the ou attribute...

[Mark W. <mew...@un...>]

it doesn't treat any attribute special (unless you talk about the DN, but
then the DN isn't really an attribute).

the values of the attribute come back as an array. like

my $vals = $entry->get('ou');

or
my @vals = $entry->get('ou);

what you probably did was something like:
print $vals (actually this should have printed out that it wasn an ARRAY 
reference )or print @vals;

to get the values on a single line like you want, you must step through
each value of the array:

for my $v (@{vals})
{
  print "ou:$v\n";
}

mark



On Mon, 14 Aug 2000, Joshua Lavalleur wrote:

> Exactly how does Perl-LDAP treat the ou attribute. When it comes back in my
> results I get:
> 
> ou: AdminITPeople
> 
> as opposed to something more like:
> 
> ou: Admin
> ou: IT
> ou: People
> 
> Is there something on the Perl-LDAP side that will allow me to do this or do
> I just need to use the power of Perl to chop that string up in the the
> pieces I want.
> 
> Thanks,
> 
> Joshua J. Lavalleur
> IT Intern
> Advanced Radio Telecom
> P. 425-688-8700 ext 1973
> Jos...@ip...
> 
> 
> 

Perl-LDAP and returning the ou attribute...

[Joshua L. <Jos...@ip...>]

Exactly how does Perl-LDAP treat the ou attribute. When it comes back in my
results I get:

ou: AdminITPeople

as opposed to something more like:

ou: Admin
ou: IT
ou: People

Is there something on the Perl-LDAP side that will allow me to do this or do
I just need to use the power of Perl to chop that string up in the the
pieces I want.

Thanks,

Joshua J. Lavalleur
IT Intern
Advanced Radio Telecom
P. 425-688-8700 ext 1973
Jos...@ip...

Re: new version of perl-ldap-0.20

[Graham B. <gb...@po...>]

On Mon, Aug 14, 2000 at 02:45:44PM +0100, John Berthels wrote:
> 
> > > This leads me to think that a high level interface might be useful. Here
> > > are a couple of suggestions on how this might differ from Net::LDAP.
> > > 
> > > 1) The ->new method takes an optional username/password and does a
> > > Net::LDAP->new and a ->bind. Returns object or under if anything fails.
> > 
> > IMO, this is bad. I even want to move the connect out of new and into a
> > separate method so that errors can be returned with more ease.
> 
> I agree that it would be bad for the Net::LDAP API.
> 
> However, for an 'easy to use' interface (Net::LDAP::For::Dummies) I just
> want a handle for a connection I can do things with. If the API fails to
> create it (for any reason) then fine, return undef and put some
> descriptive text in $! but don't make me do 2 or 3 calls to get the
> handle. In the common case it will 'just work'.

I am all for having some way for Net::LDAP to have "common use" functions. But
having a separate API "for dummies" no.

> > > i.e. you could write:
> > > 
> > > #!/usr/bin/perl -w
> > > use Net::LDAP::Cooked;	# or whatever
> > > 
> > > my $l = Net::LDAP::Cooked->new( "local.ldap.server" )
> > > 	or die( "Can't connect : $!" );
> > > my @staff = $l->list( "ou=staff, o=myorg" )
> > > 	or die( "Can't list staff : $!" );
> > 
> > I think this is coming back to having someway, other than inheritance (maybe)
> > to extend Net::LDAP.
> 
> Yes. Exactly. I suspect that lots of people writing apps using Net::LDAP
> have similar code in their apps. I want to pull that similar code into a
> companion module for Net::LDAP for standard code reuse reasons.

Right, then lets define a way to do that.

> > > foreach my $person( @staff ) {
> > > 	my $name = $person->get( "cn" );
> > > 	my $phone = $person->get( "telephoneNumber" );
> > 
> > For the ::Entry I would prefer to keep one module and have it work as
> > expected.
> 
> Again - expected by who?

A perl programmer.

> It may be possible to define an ::Entry API which
> satisfies both camps, but if not then why not have two? The 'hard core'
> users don't have the impact of the additional fluff and the 'just want it
> to work' users don't have to go through additional levels of indirection
> to get to their data.

I don't think the two camps are that different in terms of 'understandability'
just in what level they want access to.

> > And I think the above it the "expected" behaviour. Which would mean
> > that get returns a list and we add exists. Then we split out the
> > extra option code I added into another method, say get_nooptions
> > which always returns a hashref
> 
> Something like this would be fine. The only negatives for this would be
> bloating the module and which camp was annoyed by having to use the longer
> name :-)

It would not be bloat as all of it is there now. It just seems the API
is hard for some to understand. I belive we should be able to get a
single API ot ::Entry that is both powerful enough for the hard core
user and simple enough for the beginner.

> > > The kinds of things going on here would be:
> > > 
> > > - additional methods which reduce the need to construct arguments to
> > > ->search. e.g. ->list, ->read, ->exists
> > 
> > What are ->read and ->exist and called on what object ?
> 
> my $entry = $ldap->read( $dn );		# Call search with scope 0 and filter
> 
> ->exists( $dn ) is true if the entry is in the Directory. At first sight
> seems the same as ->read( $dn ) but could be more efficient since it need
> not pull back all attributes. Both are syntactic sugar around ->search().
> 
> The previous discussions around $ldap->alive() (or $ldap->ping()) fit
> right in here too. Syntactic sugar. This is perl after all :-)

Right. We need a way to add extensions. This can be done in many ways.

1) Inheritance
2) MI
3) allowing others to import into Net::LDAP with a register module.

> > > - avoid Net::LDAP::Message returns, give back arrays of
> > > Net::LDAP::Cooked::Entry
> > 
> > I would rather just keep one Entry object.
> 
> Fair enough, but see above regarding two audiences.

I think we can keep both happy.

> > > So, is this something which would be useful to people (or would have been
> > > useful to them when starting with Net::LDAP) or does it just hide too much
> > > from the user and is likely to confuse them?
> > 
> > Confusion is one thing that concerns me. Because you teach them one
> > theng then they have to learn something else if they want to go
> > beyond its boundaries. I would prefer to make the API as natural/easy
> > as possible.
> 
> This is a very good point. The documentation of all this would have to be
> done very carefully. To some extent I think that this might be alleviated
> by having the two APIs appear less related. "Oh...you're using
> Net::LDAP::Simple. Thats OK, but to do *that* you need to read up on
> Net::LDAP".

Two documents, yes. Two APIs, I would rather not.

We could just make these methods avaliable via the AUTOLOADer or have the
user type

  use Net::LDAP::Extn qw(:simple);

to get Net::LDAP::Extn to import some subs into Net::LDAP or just have
Net::LDAP::Simple inherit from Net::LDAP and provide these subs.

But some of these may be of use to 'hard core' users too, which is why
I don't really like the ::Simple appraoch as we will see more and more
::Simple being the main API.

> This is why I was thinking inheritance might be bad, since it might appear
> to mix the two.

Yes.

> > > If this is something worth doing, should we add bloat to Net::LDAP to
> > > support things like this or should we create a wrapper module.
> > 
> > bloat is something I want to avoid if possible.
> 
> This is the main reason I was thinking about a second API, rather than
> trying to make one API all things to all people.
> 
> > > If we create a wrapper module should it live within the Net::LDAP
> > > namespace or somewhere else?
> > 
> > probably within.
> 
> Agreed. (But its your namespace :-)

But my preference is a way to provide extensions to Net::LDAP, but still
(maybe) via a Net::LDAP method. The other option is to provide subs
in Net::LDAP::Util

> > > Should it inherit from Net::LDAP and add/override methods or should it be
> > > a seperate object?
> > 
> > What would it gain from being a separate module ? I would say it
> > should inherit, if we have it at all. I would prefer to get the current
> > module "fixed" rather than create another module just to provide a different
> > API.
> 
> My real question is whether it is better to extend Net::LDAP to make it
> easier for novice users (or those who like convenience) or instead to
> recognise that there are different types of users and so implement a new
> API to meet a different need. I think Net::LDAP is nice, clean and
> precise. I like that. I also find myself replicating wrapper functions
> from app to app and wishing that they lived in the distribution.

What kind of wrapper functions ? give some examples

Well we need to define a way for people to make these things easy.

> As I see it, the downsides of extending Net::LDAP are bloat and
> conflicting design goals. The downsides of a new API are that it is a
> little more work.

And the fact you end up with two APIs and people asking questions which to
use etc...

I am sure it is possible to meet the demands of both camps without creating
a completely new API.

This email is highlighting more than one issue. Lets break it into parts and
see what we can develop

 1) Net::LDAP::Entry
 2) Extending Net::LDAP with common methods

In the case of 1) lets list what we should be able to do with an Entry and
what a newbie would probably expect. Then compare that with what an expert
would expect/need. It may not be that different.

Graham.

Re: new version of perl-ldap-0.20

[John B. <joh...@ne...>]

> > This leads me to think that a high level interface might be useful. Here
> > are a couple of suggestions on how this might differ from Net::LDAP.
> > 
> > 1) The ->new method takes an optional username/password and does a
> > Net::LDAP->new and a ->bind. Returns object or under if anything fails.
> 
> IMO, this is bad. I even want to move the connect out of new and into a
> separate method so that errors can be returned with more ease.

I agree that it would be bad for the Net::LDAP API.

However, for an 'easy to use' interface (Net::LDAP::For::Dummies) I just
want a handle for a connection I can do things with. If the API fails to
create it (for any reason) then fine, return undef and put some
descriptive text in $! but don't make me do 2 or 3 calls to get the
handle. In the common case it will 'just work'.

> > 2) In general, methods return true on success, undef or () on failure Yes,
> > this means you can't tell the difference between 'no data' or 'error'. If
> > the user doesn't care that's fine (since they may need to handle 'no data'
> > as an application error anyway). Otherwise we could set $! (or $@?) and/or
> > provide a 'did an error happen' function.
> 
> I can see why some people may want this. But I am not sure I like it
> too much.

It should be OK for any app which wants to attempt to get data and can
throw an error if it can't get it. If the app is implementing recovery
then the user is 'sophisticated' and can use straight 'Net::LDAP'.

> > 3) Object destructor does an unbind and closes the socket. (Not sure if
> > Net::LDAP does this already...probably)
> 
> No it does not. And I am not sure about the unbind, I have had bad experiences
> with other modules doing quit on DESTROY. An perl will close the socket
> anyway.

Fair enough.

> > i.e. you could write:
> > 
> > #!/usr/bin/perl -w
> > use Net::LDAP::Cooked;	# or whatever
> > 
> > my $l = Net::LDAP::Cooked->new( "local.ldap.server" )
> > 	or die( "Can't connect : $!" );
> > my @staff = $l->list( "ou=staff, o=myorg" )
> > 	or die( "Can't list staff : $!" );
> 
> I think this is coming back to having someway, other than inheritance (maybe)
> to extend Net::LDAP.

Yes. Exactly. I suspect that lots of people writing apps using Net::LDAP
have similar code in their apps. I want to pull that similar code into a
companion module for Net::LDAP for standard code reuse reasons.

> > foreach my $person( @staff ) {
> > 	my $name = $person->get( "cn" );
> > 	my $phone = $person->get( "telephoneNumber" );
> 
> For the ::Entry I would prefer to keep one module and have it work as
> expected.

Again - expected by who? It may be possible to define an ::Entry API which
satisfies both camps, but if not then why not have two? The 'hard core'
users don't have the impact of the additional fluff and the 'just want it
to work' users don't have to go through additional levels of indirection
to get to their data.

> And I think the above it the "expected" behaviour. Which would mean
> that get returns a list and we add exists. Then we split out the
> extra option code I added into another method, say get_nooptions
> which always returns a hashref

Something like this would be fine. The only negatives for this would be
bloating the module and which camp was annoyed by having to use the longer
name :-)

> > The kinds of things going on here would be:
> > 
> > - additional methods which reduce the need to construct arguments to
> > ->search. e.g. ->list, ->read, ->exists
> 
> What are ->read and ->exist and called on what object ?

my $entry = $ldap->read( $dn );		# Call search with scope 0 and filter

->exists( $dn ) is true if the entry is in the Directory. At first sight
seems the same as ->read( $dn ) but could be more efficient since it need
not pull back all attributes. Both are syntactic sugar around ->search().

The previous discussions around $ldap->alive() (or $ldap->ping()) fit
right in here too. Syntactic sugar. This is perl after all :-)

> > - avoid Net::LDAP::Message returns, give back arrays of
> > Net::LDAP::Cooked::Entry
> 
> I would rather just keep one Entry object.

Fair enough, but see above regarding two audiences.

> > - The 'cooked' entries support simple retrieval of scalars. If attr is
> > multi-valued simply give back first. Provide ->get_all() get an array of
> > all values back.
> 
> I would prefer to just make get context sensetive.

Ditto last comment.

> > So, is this something which would be useful to people (or would have been
> > useful to them when starting with Net::LDAP) or does it just hide too much
> > from the user and is likely to confuse them?
> 
> Confusion is one thing that concerns me. Because you teach them one
> theng then they have to learn something else if they want to go
> beyond its boundaries. I would prefer to make the API as natural/easy
> as possible.

This is a very good point. The documentation of all this would have to be
done very carefully. To some extent I think that this might be alleviated
by having the two APIs appear less related. "Oh...you're using
Net::LDAP::Simple. Thats OK, but to do *that* you need to read up on
Net::LDAP".

This is why I was thinking inheritance might be bad, since it might appear
to mix the two.

> > If this is something worth doing, should we add bloat to Net::LDAP to
> > support things like this or should we create a wrapper module.
> 
> bloat is something I want to avoid if possible.

This is the main reason I was thinking about a second API, rather than
trying to make one API all things to all people.

> > If we create a wrapper module should it live within the Net::LDAP
> > namespace or somewhere else?
> 
> probably within.

Agreed. (But its your namespace :-)

> > Should it inherit from Net::LDAP and add/override methods or should it be
> > a seperate object?
> 
> What would it gain from being a separate module ? I would say it
> should inherit, if we have it at all. I would prefer to get the current
> module "fixed" rather than create another module just to provide a different
> API.

My real question is whether it is better to extend Net::LDAP to make it
easier for novice users (or those who like convenience) or instead to
recognise that there are different types of users and so implement a new
API to meet a different need. I think Net::LDAP is nice, clean and
precise. I like that. I also find myself replicating wrapper functions
from app to app and wishing that they lived in the distribution.

As I see it, the downsides of extending Net::LDAP are bloat and
conflicting design goals. The downsides of a new API are that it is a
little more work.

regards,

jb

Re: new version of perl-ldap-0.20

[Graham B. <gb...@po...>]

On Mon, Aug 14, 2000 at 11:26:25AM +0100, John Berthels wrote:
> 
> [snip get now returns array ref or hash ref]
> 
> > I am open to suggestions. The only thing I can think of is to revert to
> > what was there, allow the hash return in a list context too and add and
> > exists method to check if an attribute exists.
> > 
> > Comments.
> 
> I get the feeling (perhaps wrongly) that users of Net::LDAP divide up into
> two camps. Those that want/require the level of control which the protocol
> provides (access to all options, methods mapping onto single operations,
> etc) and those that just want to push and pull data from an LDAP server in
> the simplest way possible. Additionally, the same person might place
> themselves in either camp depending on the task at hand.

True.

> This leads me to think that a high level interface might be useful. Here
> are a couple of suggestions on how this might differ from Net::LDAP.
> 
> 1) The ->new method takes an optional username/password and does a
> Net::LDAP->new and a ->bind. Returns object or under if anything fails.

IMO, this is bad. I even want to move the connect out of new and into a
separate method so that errors can be returned with more ease.

> 2) In general, methods return true on success, undef or () on failure Yes,
> this means you can't tell the difference between 'no data' or 'error'. If
> the user doesn't care that's fine (since they may need to handle 'no data'
> as an application error anyway). Otherwise we could set $! (or $@?) and/or
> provide a 'did an error happen' function.

I can see why some people may want this. But I am not sure I like it too much.

> 3) Object destructor does an unbind and closes the socket. (Not sure if
> Net::LDAP does this already...probably)

No it does not. And I am not sure about the unbind, I have had bad experiences
with other modules doing quit on DESTROY. An perl will close the socket
anyway.

> i.e. you could write:
> 
> #!/usr/bin/perl -w
> use Net::LDAP::Cooked;	# or whatever
> 
> my $l = Net::LDAP::Cooked->new( "local.ldap.server" )
> 	or die( "Can't connect : $!" );
> my @staff = $l->list( "ou=staff, o=myorg" )
> 	or die( "Can't list staff : $!" );

I think this is coming back to having someway, other than inheritance (maybe)
to extend Net::LDAP.

> foreach my $person( @staff ) {
> 	my $name = $person->get( "cn" );
> 	my $phone = $person->get( "telephoneNumber" );

For the ::Entry I would prefer to keep one module and have it work as
expected.

And I think the above it the "expected" behaviour. Which would mean
that get returns a list and we add exists. Then we split out the
extra option code I added into another method, say get_nooptions
which always returns a hashref

> The kinds of things going on here would be:
> 
> - additional methods which reduce the need to construct arguments to
> ->search. e.g. ->list, ->read, ->exists

What are ->read and ->exist and called on what object ?

> - avoid Net::LDAP::Message returns, give back arrays of
> Net::LDAP::Cooked::Entry

I would rather just keep one Entry object.

> - The 'cooked' entries support simple retrieval of scalars. If attr is
> multi-valued simply give back first. Provide ->get_all() get an array of
> all values back.

I would prefer to just make get context sensetive.

> So, is this something which would be useful to people (or would have been
> useful to them when starting with Net::LDAP) or does it just hide too much
> from the user and is likely to confuse them?

Confusion is one thing that concerns me. Because you teach them one
theng then they have to learn something else if they want to go
beyond its boundaries. I would prefer to make the API as natural/easy
as possible.

> If this is something worth doing, should we add bloat to Net::LDAP to
> support things like this or should we create a wrapper module.

bloat is something I want to avoid if possible.

> If we create a wrapper module should it live within the Net::LDAP
> namespace or somewhere else?

probably within.

> Should it inherit from Net::LDAP and add/override methods or should it be
> a seperate object?

What would it gain from being a separate module ? I would say it
should inherit, if we have it at all. I would prefer to get the current
module "fixed" rather than create another module just to provide a different
API.

Graham.

Re: Convert::ASN1 loading times

[Graham B. <gb...@po...>]

John, this looks good and is certainly what I was thinking of.

Could you describe the format of your custom format. I cannot see
exactly how it works. For example search for 0x80cadc0, which I think
if supposed to be the root of the Filter, but I cannot see what I
think is a definition.

Graham.

Re: new version of perl-ldap-0.20

[John B. <joh...@ne...>]

[snip get now returns array ref or hash ref]

> I am open to suggestions. The only thing I can think of is to revert to
> what was there, allow the hash return in a list context too and add and
> exists method to check if an attribute exists.
> 
> Comments.

I get the feeling (perhaps wrongly) that users of Net::LDAP divide up into
two camps. Those that want/require the level of control which the protocol
provides (access to all options, methods mapping onto single operations,
etc) and those that just want to push and pull data from an LDAP server in
the simplest way possible. Additionally, the same person might place
themselves in either camp depending on the task at hand.

This leads me to think that a high level interface might be useful. Here
are a couple of suggestions on how this might differ from Net::LDAP.

1) The ->new method takes an optional username/password and does a
Net::LDAP->new and a ->bind. Returns object or under if anything fails.

2) In general, methods return true on success, undef or () on failure Yes,
this means you can't tell the difference between 'no data' or 'error'. If
the user doesn't care that's fine (since they may need to handle 'no data'
as an application error anyway). Otherwise we could set $! (or $@?) and/or
provide a 'did an error happen' function.

3) Object destructor does an unbind and closes the socket. (Not sure if
Net::LDAP does this already...probably)


i.e. you could write:

#!/usr/bin/perl -w
use Net::LDAP::Cooked;	# or whatever

my $l = Net::LDAP::Cooked->new( "local.ldap.server" )
	or die( "Can't connect : $!" );
my @staff = $l->list( "ou=staff, o=myorg" )
	or die( "Can't list staff : $!" );
foreach my $person( @staff ) {
	my $name = $person->get( "cn" );
	my $phone = $person->get( "telephoneNumber" );
	print "$name\t$phone\n";
}


The kinds of things going on here would be:

- additional methods which reduce the need to construct arguments to
->search. e.g. ->list, ->read, ->exists

- avoid Net::LDAP::Message returns, give back arrays of
Net::LDAP::Cooked::Entry

- The 'cooked' entries support simple retrieval of scalars. If attr is
multi-valued simply give back first. Provide ->get_all() get an array of
all values back.


So, is this something which would be useful to people (or would have been
useful to them when starting with Net::LDAP) or does it just hide too much
from the user and is likely to confuse them?

If this is something worth doing, should we add bloat to Net::LDAP to
support things like this or should we create a wrapper module.

If we create a wrapper module should it live within the Net::LDAP
namespace or somewhere else?

Should it inherit from Net::LDAP and add/override methods or should it be
a seperate object?

regards,

jb

Convert::ASN1 loading times

[John B. <jj...@be...>]

Dear Graham and List Folk,

Hello. I was playing around with Graham's idea of dumping the parsed ASN.1
tree to a file and loading it again. The motivation of this is to reduce
startup time for Net::LDAP and so improve interactive response of 'one
shot' commands - following Graham's observation that a significant
proportion of the startup time was parsing the ASN.1 definitions.


I managed to get the following results:

[Current code]
time perl -MNet::LDAP::ASN -e exit
Fastest time 0.55s

[Using Data::Dumper]
time perl -I. -MNet::LDAP::ASN -e exit
Fastest time 0.45s

[Using 'custom' loader/unloader]
time perl -I. -MNet::LDAP::ASN -e exit
Fastest time 0.35s


On my system the equivalent timings for Net::LDAP are:

time perl -MNet::LDAP -e exit
Fastest time 0.76s

[Using 'custom' loader/unloader]
time perl -I. -MNet::LDAP -e exit
Fasttest time 0.55s


So I didn't manage a dramatic speedup but there may be more mileage in
tweaking it further (this is the first 'working' version...hence
unoptimised). The code isn't 100% yet (some 'undefined value' warnings
when running) but I managed to run a Tk LDAP browser using it and do some
searches so it seems sensible as a proof of concept. The dump file format
is subject to refinement too.


I'd appreciate anyone's views as to whether this is something worth
pursuing further. The Net::LDAP startup time does annoy me a little
(typing 'phone bloggs' and getting their phone no. is only cool if it is
quicker than turning away from the keyboard to look at the phone list
behind you :-).


Attached is a gzip'd tar containing a patch against Convert::ASN1.pm
(v0.20, not the current CVS I'm afraid), a 'Net::LDAP::ASN2.pm' and an
'ldap.asn'. To force your Net::LDAP to use the new loader, replace your
Net::LDAP::ASN.pm with the ASN2.pm and patch your Convert::ASN. Then
you'll need the 'ldap.asn' in the current directory of your app when it
runs.


regards,

jb

Re: createTimestamp?

[Chris R. <chr...@me...>]

David Bussenschutt <d.b...@ma...> wrote:
> Actually, what I want to do is change the attributes that are returned so
> that it returns what are currently considered by my server to be (I guess)
> operational attributes.
> 
> You see, if I do a LDAP search in my NDS tree, I only get a very limited
> list of attributes returned when I request '*', but if I request them by
> name...no probs. There are many attributes that I would have expected a
> normal search to return. (like whether an account is locked or not)
> 
> So, what I want is not to ADD another attribute, and control it's access
> with an ACL, but MODIFY existing attributes so that they are more visible.
> Is this part of a system ACL too?
> 
> David.
> 
> 
> At 05:58 PM 8/10/00 -0500, you wrote:
>> What you want to do should be accomplished via an ACL , not an
>> operational attribute. 
>> From my understanding an operational attribute is one that is determined
>> by the sever and is not attatched to the entry. And they can cause a load
>> on the server to generate them, thus you don't want them returned unless
>> they're specifically requested & you probably don't want them allowed to
>> just anyone.
>> 
>> Mark
>> 
>> On Fri, 11 Aug 2000, David Bussenschutt wrote:
>> 
>>> What mechanism does a server use to decide what is an operational
>>> attribute, and what is not?  Can I add operational attributes? (ie not
>>> have them returned in a normal search unless explicitly requested)
>>> 
>>> David.

I didn't see the original message, so I'm going to comment on both at the
same time.

The schema defined in the server defines which attributes are operational,
and which are not. (Non-operational attributes are called user attributes.)

So can you add operational attributes? Depends on what you mean by "you".
The administrator of the server *may* be able to do this.

A normal person cannot.

You should certainly not attempt to change anything that is in a standard
schema from being a user attr to an operational attr or vice versa.
Attributes are often marked as operational because they are treated
differently by the server, so changing things here might completely confuse
the directory server! I would recommend trying to work 'with' the directory
server rather than 'against' it, which is what it seems you're trying to do.

Access controls are a separate issue. Because operational attributes are
just attributes, they are subject to any access controls that grant or deny
access to them, the same as access controls for other attributes.

As to why your server's not returning attributes you think are user
attributes, well you could check the server's schema to see if they are or
not. If they are user attributes, and you can only get the attributes by
getting them explicitly, then I think you should report a bug to the server
vendor.

Re: ldap->modify

[Jim H. <ha...@us...>]

Eric,

Below is a full, relatively general purpose program that modifies
attribues.
 --Jim Harle

On Fri, 11 Aug 2000, Eric Zhou wrote:

> hi,everyone:
> 
> I wish to modify an attribute in ldap tree.
> I have see the online document about ldap->modify.
> 
> is there a more concrete example about any of the
> ldap-> modify() methods.
> 
________________________________
#!/usr/local/bin/perl

use Net::LDAP qw(:all);
use Net::LDAP::Constant;
use Net::LDAP::Util;
use Term::ReadKey;
use strict;

my $ldap = Net::LDAP->new('directory.somewhere') or die "$@";

print "your login ";
chomp ( my $login = <>);
print "your passwd ";
ReadMode 'noecho'; my $password = ReadLine 0; chomp $password; ReadMode
'normal'
;
print "\n";
$ldap->bind ( version=>3) ; #first find dn for this login
my $basedn = "o=somewhere";
my $filter = "(|(uid=$login)(cn=$login))";
my $mesg = $ldap->search(
             base => $basedn,
             filter => $filter,
             attrs => ["dn"]
             );
if ($mesg->code || ($mesg->count() != 1)) {
    print "Couldn't find $login, message is \n  ",
         Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
    exit;
}
my $entry = $mesg->entry(0);
my $admindn = $entry->dn;
#print "binding to $admindn\n";
$mesg = $ldap->bind (dn => $admindn, password  => $password, version => 3)
; 
if ($mesg->code) {
    print "Couldn't bind to $login, message is \n  ",
         Net::LDAP::Util::ldap_error_name($mesg->code), "\n";
    exit;
}


while (1) {
  print "login for which changes are to be done ";
  my $who = <>;
  chomp $who;
  last unless $who;
  #find correct dn for this login
  my $mesg = $ldap->search (
             base => $basedn,
             filter => "(cn=$who)",
             attrs => ["sn"]
             );
  unless ($mesg->count() ) {
    print "bad id\n";
    next;
  }
  die ("multiple IDs\n") if $mesg->count() > 1;
  
  my $entry = $mesg->entry(0);
  my $dn = $entry->dn;
  while (1) {
    print "attribute to change ";
    my $attr = <>;
    chomp $attr;
    last unless $attr;
    print "new value for $attr ";
    my $value = <>;
    chomp $value;
    print "add or replace ";
    my $a = <>; chomp $a;
   
    
    if (lc(substr($a,0,1)) eq "a") {
      $mesg = $ldap->modify ($dn,
                    add => {$attr => $value} );
    } else {
      $mesg = $ldap->modify ($dn,
                    replace => {$attr => $value} );
    }
    print Net::LDAP::Util::ldap_error_text($mesg->code),"\nfor $dn\n" if
$mesg->
code;
  }  
}

$ldap->unbind;   # take down session

Re: ldap->modify

[Graham B. <gb...@po...>]

Hm, there is some inconsistency in the docs. All examples should show
the return of a result mesg.

If you know the DN of the entry where you want to modify
the attribute.

  $mesg = $ldap->modify($dn, replace => { attribute => $value })

will do what you want. Alternativly if you have a ::Entry object
from a search, then you can do.

  $entry->replace( attribute => $value );
  $mesg = $entry->update( $ldap );

Hope that helps.

Graham.

On Fri, Aug 11, 2000 at 10:06:19AM -0700, Eric Zhou wrote:
> hi,everyone:
> 
> I wish to modify an attribute in ldap tree.
> I have see the online document about ldap->modify.
> 
> is there a more concrete example about any of the
> ldap-> modify() methods.
> 
> besides, I always use 
> 
> Net::LDAP::Util qw( ldap_error_name
>                           ldap_error_text) ;
> with a sub procedure LDAPerror
> in ldap->add(), ldap->search() etc.
> 
> can we still get result->code? after $result is
> returned from sub modify? It seems the program doesn't
> know about this "code".
> 
> thanks a lot.
> 
> 
> Eric
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
> 
> 

ldap->modify

[Eric Z. <eri...@ya...>]

hi,everyone:

I wish to modify an attribute in ldap tree.
I have see the online document about ldap->modify.

is there a more concrete example about any of the
ldap-> modify() methods.

besides, I always use 

Net::LDAP::Util qw( ldap_error_name
                          ldap_error_text) ;
with a sub procedure LDAPerror
in ldap->add(), ldap->search() etc.

can we still get result->code? after $result is
returned from sub modify? It seems the program doesn't
know about this "code".

thanks a lot.


Eric



__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Re: Uploading Pictures to LDAP...

[Mark W. <mew...@un...>]

jpegPhoto takes the binary data and then shoves it into the LDAP server.

Like this:

my $photofile ;
my $jpeg;

open(DATA,$photofile) || die("failed to open $photofile.$!\n");

binmode($photofile); #only required on Windows

{
   local $/;
   #slurp entire file
  $jpeg = <DATA>;
}

$ldap = new Net::LDAP...

$ldap->modify($dn,
                        add => {"jpegphoto" => $jpeg}
                         );

...

Mark



Joshua Lavalleur wrote:

> When using Perl-LDAP what does the attribute jpegphoto require when you add
> or modify a record? I would guess just a path name? Is that correct?.
>
> Joshua J. Lavalleur
> IT Intern
> Advanced Radio Telecom
> P. 425-688-8700 ext 1973
> Jos...@ip...

Uploading Pictures to LDAP...

[Joshua L. <Jos...@ip...>]

When using Perl-LDAP what does the attribute jpegphoto require when you add
or modify a record? I would guess just a path name? Is that correct?.

Joshua J. Lavalleur
IT Intern
Advanced Radio Telecom
P. 425-688-8700 ext 1973
Jos...@ip...

Re: createTimestamp?

[Mark W. <mew...@un...>]

The only way that I know of to get the type of behavior you wish is to change the
server itself, as in rewrite it or extend the server via an API. I don't think
this is possible via NDS.

Also keep in mind, you probably don't want things like account information going
out over just any search. There's a reason why it's harder to get that stuff, it's
called security :). If you make it easier, then it's just that much easier to
exploit that information.

Mark

David Bussenschutt wrote:

> Actually, what I want to do is change the attributes that are returned so
> that it returns what are currently considered by my server to be (I guess)
> operational attributes.
>
> You see, if I do a LDAP search in my NDS tree, I only get a very limited
> list of attributes returned when I request '*', but if I request them by
> name...no probs. There are many attributes that I would have expected a
> normal search to return. (like whether an account is locked or not)
>
> So, what I want is not to ADD another attribute, and control it's access
> with an ACL, but MODIFY existing attributes so that they are more visible.
> Is this part of a system ACL too?
>
> David.
>
> At 05:58 PM 8/10/00 -0500, you wrote:
> >What you want to do should be accomplished via an ACL , not an operational
> >attribute.
> >From my understanding an operational attribute is one that is determined
> >by the sever and is not attatched to the entry. And they can cause a load
> >on the server to generate them, thus you don't want them returned unless
> >they're specifically requested & you probably don't want them allowed to
> >just anyone.
> >
> >Mark
> >
> >On Fri, 11 Aug 2000, David Bussenschutt wrote:
> >
> >> What mechanism does a server use to decide what is an operational
> >> attribute, and what is not?  Can I add operational attributes? (ie not have
> >> them returned in a normal search unless explicitly requested)
> >>
> >> David.
> >>
> >> At 05:40 PM 8/10/00 -0500, you wrote:
> >> >If you don't provide any attributes to search, you'll get back all
> >> >non-operational attributes available to you (of course this depends on the
> >> >server's ACLs as to which ones you can actually get).
> >> >
> >> >If you want operational attributes you must requet them in the search
> >> >(sorry I overlooked that yesterday).
> >> >
> >> >If you want all of the attributes, either list everything in the search,
> >> >or do 2 searches, one without listing and one with a listing of all of the
> >> >operational attributes.
> >> >
> >> >Mark
> >> >
> >> >On Thu, 10 Aug 2000, Bing Du wrote:
> >> >
> >> >> Thanks all.  Ok, I have given up using as_struct.
> >> >>
> >> >> I saw 'createtimestamp' finally by using $ldcon->search(base =>
> >> >> $BASEDN, scope => 'sub', filter => $filter,attrs=>
> >> >> ["createtimestamp"],typesonly => 0) :).
> >> >>
> >> >> A new question:
> >> >>
> >> >> I used to use
> >> >> $ldcon->search(base...,scope...,filter...,attrs=>[],typesonly...) to
> >> >> retrieve values of all attributes without specificly listing all
> >> >> attributes' names in @attrs (e.g. @attrs = ('cn', 'phone','email')), and
> >> >> then use attrs=>@attrs in 'search'.   By doing this, I do not need to
> >> >> change my script whenever new attributes are added in.
> >> >>
> >> >> But now I have to explicitly specify operational attributes in
> >> >> attrs=>[] because I want them.   So is there a way to represent all
> >> >> other regular attributes still without listing them explicitly?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Bing
> >> >>
> >> >> >>> Chris Ridd <chr...@me...> 08/10/00 02:34AM >>>
> >> >> Mark Wilcox <mew...@un...> wrote:
> >> >> > Chris Ridd (who works for Messanging Direct) will be the best one to
> >> >> > answer this. But he's leaving on a trip, so I don't know if he's
> >> >> online
> >> >> > right now.
> >> >>
> >> >> Still here...
> >> >>
> >> >> > Have you verified that the attribute is actually there (ie. have you
> >> >> > dumped it out with ldapsearch or MD's version of db2ldif?)
> >> >> >
> >> >> > Mark
> >> >>
> >> >> The default access controls we have in our directory will only permit
> >> >> the
> >> >> DSA manager - which Bing is binding as, so that's OK - read access to
> >> >> createTimestamp.
> >> >>
> >> >> As others have pointed out, createTimestamp is an operational
> >> >> attribute, so
> >> >> will only be returned over LDAP when the client explicitly asks for
> >> >> it.
> >> >>
> >> >> So I suspect the problem is either that you aren't explicitly
> >> >> specifying in
> >> >> the search operation that you want the createTimestamp back, or the
> >> >> way
> >> >> you're accessing the entries back via as_struct is wrong.
> >> >>
> >> >> To check the attributes are really coming back over the network, set
> >> >> debug
> >> >> => 12 when you create the LDAP object. You will then get a whole load
> >> >> of
> >> >> output to stderr which is a dump of the raw protocol. Hopefully you'll
> >> >> see
> >> >> the createTimestamps being returned.
> >> >>
> >> >> I haven't used as_struct myself, so can't comment on that part.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Chris
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >> --------------------------------------------------------------------
> >> David Bussenschutt          Email: D.B...@ma...
> >> Senior Computing Support Officer & Systems Administrator/Programmer
> >> Location: Griffith University. Information Technology Services
> >>           Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
> >> --------------------------------------------------------------------
> >>
> >
> >
> >
> >
>
> --------------------------------------------------------------------
> David Bussenschutt          Email: D.B...@ma...
> Senior Computing Support Officer & Systems Administrator/Programmer
> Location: Griffith University. Information Technology Services
>           Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
> --------------------------------------------------------------------

Re: Extended schema

[Mark W. <mew...@un...>]

Did you populate your entries with values for these new attributes?

mark

spencer wrote:

> Hi,
> I have extended the ldap directory schema. However, the search based on the
> newly defined attribute/object class yields nothing. How can I enable the
> search to recognise the new attribute/object class?
>
> Thanks.
>
> spencer

Extended schema

[spencer <sp...@co...>]

Hi,
I have extended the ldap directory schema. However, the search based on the
newly defined attribute/object class yields nothing. How can I enable the
search to recognise the new attribute/object class?

Thanks.

spencer

Re: createTimestamp?

[David B. <d.b...@ma...>]

Actually, what I want to do is change the attributes that are returned so
that it returns what are currently considered by my server to be (I guess)
operational attributes.

You see, if I do a LDAP search in my NDS tree, I only get a very limited
list of attributes returned when I request '*', but if I request them by
name...no probs. There are many attributes that I would have expected a
normal search to return. (like whether an account is locked or not)

So, what I want is not to ADD another attribute, and control it's access
with an ACL, but MODIFY existing attributes so that they are more visible.
Is this part of a system ACL too?

David.


At 05:58 PM 8/10/00 -0500, you wrote:
>What you want to do should be accomplished via an ACL , not an operational
>attribute. 
>From my understanding an operational attribute is one that is determined
>by the sever and is not attatched to the entry. And they can cause a load
>on the server to generate them, thus you don't want them returned unless
>they're specifically requested & you probably don't want them allowed to
>just anyone.
>
>Mark
>
>On Fri, 11 Aug 2000, David Bussenschutt wrote:
>
>> What mechanism does a server use to decide what is an operational
>> attribute, and what is not?  Can I add operational attributes? (ie not have
>> them returned in a normal search unless explicitly requested)
>> 
>> David.
>> 
>> At 05:40 PM 8/10/00 -0500, you wrote:
>> >If you don't provide any attributes to search, you'll get back all
>> >non-operational attributes available to you (of course this depends on the
>> >server's ACLs as to which ones you can actually get).
>> >
>> >If you want operational attributes you must requet them in the search
>> >(sorry I overlooked that yesterday).
>> >
>> >If you want all of the attributes, either list everything in the search,
>> >or do 2 searches, one without listing and one with a listing of all of the
>> >operational attributes.
>> >
>> >Mark
>> >
>> >On Thu, 10 Aug 2000, Bing Du wrote:
>> >
>> >> Thanks all.  Ok, I have given up using as_struct.
>> >>   
>> >> I saw 'createtimestamp' finally by using $ldcon->search(base =>
>> >> $BASEDN, scope => 'sub', filter => $filter,attrs=>
>> >> ["createtimestamp"],typesonly => 0) :).
>> >> 
>> >> A new question:
>> >> 
>> >> I used to use
>> >> $ldcon->search(base...,scope...,filter...,attrs=>[],typesonly...) to 
>> >> retrieve values of all attributes without specificly listing all
>> >> attributes' names in @attrs (e.g. @attrs = ('cn', 'phone','email')), and
>> >> then use attrs=>@attrs in 'search'.   By doing this, I do not need to
>> >> change my script whenever new attributes are added in.   
>> >> 
>> >> But now I have to explicitly specify operational attributes in
>> >> attrs=>[] because I want them.   So is there a way to represent all
>> >> other regular attributes still without listing them explicitly?
>> >> 
>> >> Thanks,
>> >> 
>> >> Bing
>> >> 
>> >> >>> Chris Ridd <chr...@me...> 08/10/00 02:34AM >>>
>> >> Mark Wilcox <mew...@un...> wrote:
>> >> > Chris Ridd (who works for Messanging Direct) will be the best one to
>> >> > answer this. But he's leaving on a trip, so I don't know if he's
>> >> online
>> >> > right now.
>> >> 
>> >> Still here...
>> >> 
>> >> > Have you verified that the attribute is actually there (ie. have you
>> >> > dumped it out with ldapsearch or MD's version of db2ldif?)
>> >> > 
>> >> > Mark
>> >> 
>> >> The default access controls we have in our directory will only permit
>> >> the
>> >> DSA manager - which Bing is binding as, so that's OK - read access to
>> >> createTimestamp.
>> >> 
>> >> As others have pointed out, createTimestamp is an operational
>> >> attribute, so
>> >> will only be returned over LDAP when the client explicitly asks for
>> >> it.
>> >> 
>> >> So I suspect the problem is either that you aren't explicitly
>> >> specifying in
>> >> the search operation that you want the createTimestamp back, or the
>> >> way
>> >> you're accessing the entries back via as_struct is wrong.
>> >> 
>> >> To check the attributes are really coming back over the network, set
>> >> debug
>> >> => 12 when you create the LDAP object. You will then get a whole load
>> >> of
>> >> output to stderr which is a dump of the raw protocol. Hopefully you'll
>> >> see
>> >> the createTimestamps being returned.
>> >> 
>> >> I haven't used as_struct myself, so can't comment on that part.
>> >> 
>> >> Cheers,
>> >> 
>> >> Chris
>> >> 
>> >
>> >
>> >
>> >
>> 
>> --------------------------------------------------------------------
>> David Bussenschutt          Email: D.B...@ma...
>> Senior Computing Support Officer & Systems Administrator/Programmer
>> Location: Griffith University. Information Technology Services
>>           Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
>> --------------------------------------------------------------------
>> 
>
>
>
>

--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Re: createTimestamp?

[Mark W. <mew...@un...>]

What you want to do should be accomplished via an ACL , not an operational
attribute. 
From my understanding an operational attribute is one that is determined
by the sever and is not attatched to the entry. And they can cause a load
on the server to generate them, thus you don't want them returned unless
they're specifically requested & you probably don't want them allowed to
just anyone.

Mark

On Fri, 11 Aug 2000, David Bussenschutt wrote:

> What mechanism does a server use to decide what is an operational
> attribute, and what is not?  Can I add operational attributes? (ie not have
> them returned in a normal search unless explicitly requested)
> 
> David.
> 
> At 05:40 PM 8/10/00 -0500, you wrote:
> >If you don't provide any attributes to search, you'll get back all
> >non-operational attributes available to you (of course this depends on the
> >server's ACLs as to which ones you can actually get).
> >
> >If you want operational attributes you must requet them in the search
> >(sorry I overlooked that yesterday).
> >
> >If you want all of the attributes, either list everything in the search,
> >or do 2 searches, one without listing and one with a listing of all of the
> >operational attributes.
> >
> >Mark
> >
> >On Thu, 10 Aug 2000, Bing Du wrote:
> >
> >> Thanks all.  Ok, I have given up using as_struct.
> >>   
> >> I saw 'createtimestamp' finally by using $ldcon->search(base =>
> >> $BASEDN, scope => 'sub', filter => $filter,attrs=>
> >> ["createtimestamp"],typesonly => 0) :).
> >> 
> >> A new question:
> >> 
> >> I used to use
> >> $ldcon->search(base...,scope...,filter...,attrs=>[],typesonly...) to 
> >> retrieve values of all attributes without specificly listing all
> >> attributes' names in @attrs (e.g. @attrs = ('cn', 'phone','email')), and
> >> then use attrs=>@attrs in 'search'.   By doing this, I do not need to
> >> change my script whenever new attributes are added in.   
> >> 
> >> But now I have to explicitly specify operational attributes in
> >> attrs=>[] because I want them.   So is there a way to represent all
> >> other regular attributes still without listing them explicitly?
> >> 
> >> Thanks,
> >> 
> >> Bing
> >> 
> >> >>> Chris Ridd <chr...@me...> 08/10/00 02:34AM >>>
> >> Mark Wilcox <mew...@un...> wrote:
> >> > Chris Ridd (who works for Messanging Direct) will be the best one to
> >> > answer this. But he's leaving on a trip, so I don't know if he's
> >> online
> >> > right now.
> >> 
> >> Still here...
> >> 
> >> > Have you verified that the attribute is actually there (ie. have you
> >> > dumped it out with ldapsearch or MD's version of db2ldif?)
> >> > 
> >> > Mark
> >> 
> >> The default access controls we have in our directory will only permit
> >> the
> >> DSA manager - which Bing is binding as, so that's OK - read access to
> >> createTimestamp.
> >> 
> >> As others have pointed out, createTimestamp is an operational
> >> attribute, so
> >> will only be returned over LDAP when the client explicitly asks for
> >> it.
> >> 
> >> So I suspect the problem is either that you aren't explicitly
> >> specifying in
> >> the search operation that you want the createTimestamp back, or the
> >> way
> >> you're accessing the entries back via as_struct is wrong.
> >> 
> >> To check the attributes are really coming back over the network, set
> >> debug
> >> => 12 when you create the LDAP object. You will then get a whole load
> >> of
> >> output to stderr which is a dump of the raw protocol. Hopefully you'll
> >> see
> >> the createTimestamps being returned.
> >> 
> >> I haven't used as_struct myself, so can't comment on that part.
> >> 
> >> Cheers,
> >> 
> >> Chris
> >> 
> >
> >
> >
> >
> 
> --------------------------------------------------------------------
> David Bussenschutt          Email: D.B...@ma...
> Senior Computing Support Officer & Systems Administrator/Programmer
> Location: Griffith University. Information Technology Services
>           Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
> --------------------------------------------------------------------
> 

Re: createTimestamp?

[Kurt D. Z. <Ku...@Op...>]

At 05:40 PM 8/10/00 -0500, Mark Wilcox wrote:
>If you don't provide any attributes to search, you'll get back all
>non-operational attributes available to you (of course this depends on the
>server's ACLs as to which ones you can actually get).
>
>If you want operational attributes you must requet them in the search
>(sorry I overlooked that yesterday).
>
>If you want all of the attributes, either list everything in the search,
>or do 2 searches, one without listing and one with a listing of all of the
>operational attributes.

or list '*' plus the specific operational attributes you desire in
one search.

Re: createTimestamp?

[Mark W. <mew...@un...>]

If you don't provide any attributes to search, you'll get back all
non-operational attributes available to you (of course this depends on the
server's ACLs as to which ones you can actually get).

If you want operational attributes you must requet them in the search
(sorry I overlooked that yesterday).

If you want all of the attributes, either list everything in the search,
or do 2 searches, one without listing and one with a listing of all of the
operational attributes.

Mark

On Thu, 10 Aug 2000, Bing Du wrote:

> Thanks all.  Ok, I have given up using as_struct.
>   
> I saw 'createtimestamp' finally by using $ldcon->search(base =>
> $BASEDN, scope => 'sub', filter => $filter,attrs=>
> ["createtimestamp"],typesonly => 0) :).
> 
> A new question:
> 
> I used to use
> $ldcon->search(base...,scope...,filter...,attrs=>[],typesonly...) to 
> retrieve values of all attributes without specificly listing all
> attributes' names in @attrs (e.g. @attrs = ('cn', 'phone','email')), and
> then use attrs=>@attrs in 'search'.   By doing this, I do not need to
> change my script whenever new attributes are added in.   
> 
> But now I have to explicitly specify operational attributes in
> attrs=>[] because I want them.   So is there a way to represent all
> other regular attributes still without listing them explicitly?
> 
> Thanks,
> 
> Bing
> 
> >>> Chris Ridd <chr...@me...> 08/10/00 02:34AM >>>
> Mark Wilcox <mew...@un...> wrote:
> > Chris Ridd (who works for Messanging Direct) will be the best one to
> > answer this. But he's leaving on a trip, so I don't know if he's
> online
> > right now.
> 
> Still here...
> 
> > Have you verified that the attribute is actually there (ie. have you
> > dumped it out with ldapsearch or MD's version of db2ldif?)
> > 
> > Mark
> 
> The default access controls we have in our directory will only permit
> the
> DSA manager - which Bing is binding as, so that's OK - read access to
> createTimestamp.
> 
> As others have pointed out, createTimestamp is an operational
> attribute, so
> will only be returned over LDAP when the client explicitly asks for
> it.
> 
> So I suspect the problem is either that you aren't explicitly
> specifying in
> the search operation that you want the createTimestamp back, or the
> way
> you're accessing the entries back via as_struct is wrong.
> 
> To check the attributes are really coming back over the network, set
> debug
> => 12 when you create the LDAP object. You will then get a whole load
> of
> output to stderr which is a dump of the raw protocol. Hopefully you'll
> see
> the createTimestamps being returned.
> 
> I haven't used as_struct myself, so can't comment on that part.
> 
> Cheers,
> 
> Chris
> 

Re: createTimestamp?

[Bing D. <Bi...@ci...>]

Thanks all.  Ok, I have given up using as_struct.
  
I saw 'createtimestamp' finally by using $ldcon->search(base =>
$BASEDN, scope => 'sub', filter => $filter,attrs=>
["createtimestamp"],typesonly => 0) :).

A new question:

I used to use
$ldcon->search(base...,scope...,filter...,attrs=>[],typesonly...) to 
retrieve values of all attributes without specificly listing all
attributes' names in @attrs (e.g. @attrs = ('cn', 'phone','email')), and
then use attrs=>@attrs in 'search'.   By doing this, I do not need to
change my script whenever new attributes are added in.   

But now I have to explicitly specify operational attributes in
attrs=>[] because I want them.   So is there a way to represent all
other regular attributes still without listing them explicitly?

Thanks,

Bing

>>> Chris Ridd <chr...@me...> 08/10/00 02:34AM >>>
Mark Wilcox <mew...@un...> wrote:
> Chris Ridd (who works for Messanging Direct) will be the best one to
> answer this. But he's leaving on a trip, so I don't know if he's
online
> right now.

Still here...

> Have you verified that the attribute is actually there (ie. have you
> dumped it out with ldapsearch or MD's version of db2ldif?)
> 
> Mark

The default access controls we have in our directory will only permit
the
DSA manager - which Bing is binding as, so that's OK - read access to
createTimestamp.

As others have pointed out, createTimestamp is an operational
attribute, so
will only be returned over LDAP when the client explicitly asks for
it.

So I suspect the problem is either that you aren't explicitly
specifying in
the search operation that you want the createTimestamp back, or the
way
you're accessing the entries back via as_struct is wrong.

To check the attributes are really coming back over the network, set
debug
=> 12 when you create the LDAP object. You will then get a whole load
of
output to stderr which is a dump of the raw protocol. Hopefully you'll
see
the createTimestamps being returned.

I haven't used as_struct myself, so can't comment on that part.

Cheers,

Chris