Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kurt D. Z. <Ku...@Op...> - 2000-11-29 17:00:54
|
BTW, OpenLDAP 2.x provides an LDAPv3 implementation. At 10:46 AM 11/29/00 +0000, Chris Ridd wrote: >OK, that's not the way LDAP does it really. LDAPv3 servers store schema in >special places called subentries in the directory, and places pointers (ie >DNs) to those subentries in the subschemaSubentry attribute in the root DSE. Every entry should have a subschemaSubentry attribute whose value refers to the subschema entry (or subentry) which controls it. One must be very careful using the subschemaSubentry attribute in the root DSE due to the fact that there may be multiple subschema subentries and the root DSE provides no mechanism for the client to relate which subentry controls which entry held by the server. Client developers should avoid using the subschemaSubentry within the root DSE as this mechanism is likely to be changed when LDAPv3 goes from Proposed to Draft Standard. >What $ldap->schema() does is read the root entry, read the >subschemaSubentry attribute from there, and then read the schema from those >subentries. > >To shortcut this extra read, and to support servers that don't contain a >subschemaSubentry attribute in the root DSE but do hold schema in the >directory, you can also tell $ldap->schema() to read the subschema from a >certain DN, by saying $ldap->schema(dn => 'where the subschema is') > >I think you should probably just remove the dn arguments from the call to >$ldap->schema(). > >Cheers, > >Chris |
|
From: Clif H. <c-h...@ti...> - 2000-11-29 14:12:06
|
Javier,
Attached is a simple perl script that will get and display
the schema contents of a directory server.
You will need perl-ldap 0.22 and to change a couple of
lines in the code to make it work for you.
You may need to change the first line of the script to
point to your location of perl.
Change the word "cnb0116358" to the name of your directory
server. It is near the top of the file.
You may need to bind to your directory as the directory
admin in order to get the schema, change the ldap->ldapbind
line to include you directory admin "cn" and password if
needed.
You will probably want to pipe the output to a file.
I have not tried this script out on a openldap 2.x system
yet, but it does work on our x.500 and Netscape directory
servers.
Clif Harden INTERNET: c-h...@ti...
Javier wrote:
>
> Hello guys!
>
> Can somebody help me about this:
>
> I'm triying to get the object's schema from LDAP server, but I can't.
>
> I'm working with OpenLdap 2.0.7, I think that this version of LDAP
> server support LDAPv3.
> Is it correct?
>
> I do this to get the schema:
>
> $dn="cn=Jane, ou=myDept, o=myorg, c=ES";
> $ldap= Net::LDAP->new('192.168.0.44',
> debug=>0,
> async=>1,);
> $ldap->bind;
>
> $schema = $ldap->schema (dn => $dn);
>
> @attr_person = $schema->attributes( "person" );
>
> $ldap->unbind;
>
> # End of example script
>
> I debug this script and the variable $schema return from $ldap->schema
> is not full!
> and Schema.pm's methods , for example $schema->attributes( "person" )
> don't return anything.
>
> Can somebody tell me step by step how I can get the schema from the server?
> I do need configure Openldap for do this?
>
> Thanks for all!! Sorry for my English
> Javier
-- |
|
From: Chris R. <chr...@me...> - 2000-11-29 14:07:31
|
Chris Ridd <chr...@me...> wrote: > Net::LDAP doesn't support it yet as I cannot work out how to switch an > existing IO::Socket::INET into an IO::Socket::SSL. If someone can work > that out, adding StartTLS support will be relatively straightforward. The current version of IO::Socket::SSL appears to have some code which performs this conversion, interestingly. I wonder if it works? Cheers, Chris |
|
From: Chris R. <chr...@me...> - 2000-11-29 11:56:37
|
Jeremy Anderson <je...@az...> wrote:
> This isn't REALLY a Net::LDAP problem (the problem is down in
> IO::Socket::SSL and SSLeay), but the support for these modules seems to be
> near-zero, and I figure that someone who's working on Net::LDAP should
> have seen this before.
Yeah, the SSLeay and IO::Socket::SSL modules are a bit "fragile", and I had
some problems in getting them working properly when writing Net::LDAPS.
Looking at my installation, I've got IO::Socket::SSL version 0.73,
Net::SSLeay version 1.05, and I built with OpenSSL 0.9.4. I'm running on
the same version of perl but on RedHat 6.1. There's only a single CPU in my
laptop though!
I mean to look at getting the 'current' versions of all these bits of code
working properly...
> t/fh-test...........Use of uninitialized value at blib/lib/Net/SSLeay.pm
> (autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1159. Use of
> uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into
All those warnings are 'normal' with SSLeay.pm and documented by the author
of that module (or maybe the IO::Socket::SSL module, I forget.) The best
way around it I've found is to initialize IO::Socket::SSL and Net::SSLeay
with warnings turned off and 'no strict'. Here's what I wrote in the LDAPS
pod:
BEGIN {
# Turn off all warnings etc whilst initializing
# IO::Socket::SSL and Net::SSLeay.
local $^W = 0;
no strict;
require Net::SSLeay;
# The /dev/urandom is a device on Linux that returns
# random data.
Net::SSLeay::randomize('/dev/urandom');
require Net::LDAPS;
}
Hideous, huh?
> Has anyone seen this problem before? Is there a workaround? I have seen
> some mention on the mailing list about StartTLS (which seems to be another
> way of getting from a to b), but I'm not clear as to how to code
> for this. Both the documentation and the Net::LDAP code seem to be mute
> on the subject.
StartTLS is an extended LDAP request (RFC 2830) which lets you take a
normal 'plaintext' LDAP connection and switch it into a TLS connection on
the fly (ie without closing and reopening a socket.) Pretty cool, and it is
the IETF-recommended way of using a confidential connection with LDAP.
Net::LDAP doesn't support it yet as I cannot work out how to switch an
existing IO::Socket::INET into an IO::Socket::SSL. If someone can work that
out, adding StartTLS support will be relatively straightforward.
(One issue for adding that support is that the IO code in Net::LDAP needs
abstracting, as IO::Socket::SSL doesn't support all the methods that normal
sockets support. Maybe this means that IO::Socket::SSL needs fixing, but
abstracting Net::LDAP's IO is still sensible so it can support CLDAP. I
worry that this extra bit of abstraction will slow Net::LDAP down though.)
Looks like I've got some work to do!
Cheers,
Chris
|
|
From: Chris R. <chr...@me...> - 2000-11-29 10:46:19
|
Javier <te...@rd...> wrote:
> Hello guys!
>
> Can somebody help me about this:
>
> I'm triying to get the object's schema from LDAP server, but I can't.
>
> I'm working with OpenLdap 2.0.7, I think that this version of LDAP server
> support LDAPv3. Is it correct?
Don't know, sorry.
> I do this to get the schema:
>
> $dn="cn=Jane, ou=myDept, o=myorg, c=ES";
> $ldap= Net::LDAP->new('192.168.0.44',
> debug=>0,
> async=>1,);
> $ldap->bind;
>
> $schema = $ldap->schema (dn => $dn);
OK, that's not the way LDAP does it really. LDAPv3 servers store schema in
special places called subentries in the directory, and places pointers (ie
DNs) to those subentries in the subschemaSubentry attribute in the root DSE.
What $ldap->schema() does is read the root entry, read the
subschemaSubentry attribute from there, and then read the schema from those
subentries.
To shortcut this extra read, and to support servers that don't contain a
subschemaSubentry attribute in the root DSE but do hold schema in the
directory, you can also tell $ldap->schema() to read the subschema from a
certain DN, by saying $ldap->schema(dn => 'where the subschema is')
I think you should probably just remove the dn arguments from the call to
$ldap->schema().
Cheers,
Chris
|
|
From: John B. <joh...@ne...> - 2000-11-29 10:33:35
|
> I'm working with OpenLdap 2.0.7, I think that this version of LDAP > server support LDAPv3. > Is it correct? I'm not sure, but I suspect that you are bound using version 2, because... > I do this to get the schema: [snip] > $ldap->bind; If you don't specify a version to the bind command, Net::LDAP defaults to v2. (At least it looks that way in the Version 0.22 I have installed). Can you try: my $m = $ldap->bind( version => 3 ); die( "Can't bind" ) unless $m->code() == 0; # or LDAP_SUCCESS :-) instead? Does this help? > I debug this script and the variable $schema return from $ldap->schema > is not full! > and Schema.pm's methods , for example $schema->attributes( "person" ) > don't return anything. If the server is returning data [you could see this by using $ldap = Net::LDAP->new( debug => 1)] there is a reasonably high chance that the Schema code doesn't understand it since it isn't used much. If binding v3 doesn't help you (or if I got that wrong, and Net::LDAP binds v3 by default) we should be able to fix this up for you. Let us know how you get on. > Can somebody tell me step by step how I can get the schema from the server? > I do need configure Openldap for do this? I don't know if OpenLDAP supports this, the above is really just a guess. regards, jb |
|
From: Javier <te...@rd...> - 2000-11-29 07:35:14
|
Hello guys!
Can somebody help me about this:
I'm triying to get the object's schema from LDAP server, but I can't.
I'm working with OpenLdap 2.0.7, I think that this version of LDAP
server support LDAPv3.
Is it correct?
I do this to get the schema:
$dn="cn=Jane, ou=myDept, o=myorg, c=ES";
$ldap= Net::LDAP->new('192.168.0.44',
debug=>0,
async=>1,);
$ldap->bind;
$schema = $ldap->schema (dn => $dn);
@attr_person = $schema->attributes( "person" );
$ldap->unbind;
# End of example script
I debug this script and the variable $schema return from $ldap->schema
is not full!
and Schema.pm's methods , for example $schema->attributes( "person" )
don't return anything.
Can somebody tell me step by step how I can get the schema from the server?
I do need configure Openldap for do this?
Thanks for all!! Sorry for my English
Javier
|
|
From: Jeremy A. <je...@az...> - 2000-11-29 03:21:20
|
This isn't REALLY a Net::LDAP problem (the problem is down in
IO::Socket::SSL and SSLeay), but the support for these modules seems to be
near-zero, and I figure that someone who's working on Net::LDAP should
have seen this before.
More notes are at the bottom.
--------------------------------------------------------------------------
[root@foobar Net_SSLeay.pm-1.05]# perl Makefile.PL
Checking for OpenSSL-0.9.3a or newer...
You have OpenSSL-0.9.6 installed in /usr/local/ssl
That's is newer than what this module was tested with (0.9.3a). You should
consider checking if there is a newer release of this module
available. Everything will probably work OK, though.
Checking if your kit is complete...
Looks good
Writing Makefile for Net::SSLeay
[root@foobar Net_SSLeay.pm-1.05]# make
mkdir blib
mkdir blib/lib
mkdir blib/lib/Net
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/Net
mkdir blib/arch/auto/Net/SSLeay
mkdir blib/lib/auto
mkdir blib/lib/auto/Net
mkdir blib/lib/auto/Net/SSLeay
mkdir blib/man3
cp SSLeay.pm blib/lib/Net/SSLeay.pm
AutoSplitting blib/lib/Net/SSLeay.pm (blib/lib/auto/Net/SSLeay)
blib/lib/Net/SSLeay.pm: some names are not unique when truncated to 8 characters:
directory blib/lib/auto/Net/SSLeay:
ssl_read_all.al, ssl_read_until.al, ssl_read_CRLF.al truncate to ssl_read
ssl_write_all.al, ssl_write_CRLF.al truncate to ssl_writ
/usr/bin/perl -I/usr/lib/perl5/5.00503/i386-linux -I/usr/lib/perl5/5.00503 /usr/lib/perl5/5.00503/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.00503/ExtUtils/typemap -typemap typemap SSLeay.xs >xstmp.c && mv xstmp.c SSLeay.c
cc -c -I/usr/local/ssl/include -Dbool=char -DHAS_BOOL -I/usr/local/include -O2 -m486 -fno-strength-reduce -DVERSION=\"1.05\" -DXS_VERSION=\"1.05\" -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE SSLeay.c
SSLeay.c: In function `XS_Net__SSLeay_get_cipher_list':
SSLeay.c:2505: warning: assignment discards `const' from pointer target type
SSLeay.c: In function `XS_Net__SSLeay_get_cipher':
SSLeay.c:2538: warning: assignment discards `const' from pointer target type
Running Mkbootstrap for Net::SSLeay ()
chmod 644 SSLeay.bs
LD_RUN_PATH="/usr/local/ssl/lib" cc -o blib/arch/auto/Net/SSLeay/SSLeay.so -shared -L/usr/local/lib SSLeay.o -L/usr/local/ssl -L/usr/local/ssl/lib -lssl -lcrypto
chmod 755 blib/arch/auto/Net/SSLeay/SSLeay.so
cp SSLeay.bs blib/arch/auto/Net/SSLeay/SSLeay.bs
chmod 644 blib/arch/auto/Net/SSLeay/SSLeay.bs
Manifying blib/man3/Net::SSLeay.3
[root@foobar Net_SSLeay.pm-1.05]# make install
(note... As you can see, we've been through this before)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/SSLeay.so (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/SSLeay.bs (unchanged)
Files found in blib/arch --> Installing files in blib/lib into architecture dependend library tree!
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/Net/SSLeay.pm (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/open_tcp_connection.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/ssl_read_all.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/ssl_write_all.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/ssl_read_until.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/ssl_read_CRLF.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/ssl_write_CRLF.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/dump_peer_certificate.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/randomize.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/sslcat.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/https_cat.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/set_server_cert_and_key.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/make_form.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/make_headers.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/do_https.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/get_https.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/post_https.al (unchanged)
Skipping /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/autosplit.ix (unchanged)
Skipping /usr/lib/perl5/man/man3/Net::SSLeay.3 (unchanged)
Writing /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Net/SSLeay/.packlist
Appending installation info to /usr/lib/perl5/5.00503/i386-linux/perllocal.pod
[root@foobar Net_SSLeay.pm-1.05]# cd ../IO-Socket-SSL-0.75
[root@foobar IO-Socket-SSL-0.75]# perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for IO::Socket::SSL
[root@foobar IO-Socket-SSL-0.75]# make
mkdir blib
mkdir blib/lib
mkdir blib/lib/IO
mkdir blib/lib/IO/Socket
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/IO
mkdir blib/arch/auto/IO/Socket
mkdir blib/arch/auto/IO/Socket/SSL
mkdir blib/lib/auto
mkdir blib/lib/auto/IO
mkdir blib/lib/auto/IO/Socket
mkdir blib/lib/auto/IO/Socket/SSL
mkdir blib/man3
cp lib/IO/Socket/SSL.pm blib/lib/IO/Socket/SSL.pm
Manifying blib/man3/IO::Socket::SSL.3
[root@foobar IO-Socket-SSL-0.75]# make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib
-I/usr/lib/perl5/5.00503/i386-linux -I/usr/lib/perl5/5.00503 -e 'use
Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/fh-test...........Use of uninitialized value at blib/lib/Net/SSLeay.pm
(autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1159.
Use of uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into
blib/lib/auto/Net/SSLeay/randomize.al) line 1163.
ok
t/lwptest...........Use of uninitialized value at blib/lib/Net/SSLeay.pm
(autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1159.
Use of uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into
blib/lib/auto/Net/SSLeay/randomize.al) line 1163.
request 1: failed: 'Protocol scheme 'https' is not supported'.
FAILED tests 1-2
Failed 2/3 tests, 33.33% okay
t/test1.............Use of uninitialized value at blib/lib/Net/SSLeay.pm
(autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1159.
Use of uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into
blib/lib/auto/Net/SSLeay/randomize.al) line 1163.
ok
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.00503/i386-linux -I/usr/lib/perl5/5.00503 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/fh-test...........Use of uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1159.
Use of uninitialized value at blib/lib/Net/SSLeay.pm (autosplit into blib/lib/auto/Net/SSLeay/randomize.al) line 1163.
make: *** [test_dynamic] Interrupt
[root@foobar IO-Socket-SSL-0.75]#
--------------------------------------------------------------------------
* I compiled and installed OpenSSL-0.9.6 (as the build data below
indicates). Because I suspected that this was the source of our problems,
I downgraded to OpenSSL-0.9.3a. No change whatsoever.
Has anyone seen this problem before? Is there a workaround? I have seen
some mention on the mailing list about StartTLS (which seems to be another
way of getting from a to b), but I'm not clear as to how to code
for this. Both the documentation and the Net::LDAP code seem to be mute
on the subject.
Best Regards,
j.
|
|
From: Jurgen B. <ju...@bo...> - 2000-11-27 20:48:32
|
"Bing Du" wrote: > Does Net::LDAP provide any mechanism to lock an entry before modifying > it? So other script using Net::LDAP or ldapmodify command can not > modify the same entry. LDAP v3 doesn't have any locking mechanisms, therefor Net::LDAP doesn't have any. From an application's perspective you can come up with your own locking protocol... for example, you could define some naming convention for special lock entries, then to lock a record you'd attempt to create the lock entry; if creating the lock succeeds you do your thing and then remove the lock entry. If the create fails you assume that it's because another process already created a lock entry and wait and retry or return an error to the user. This works because you can't create an entry that already exists, so it's a valid locking protocol. Of course it only works if all applications that use your directory adhere to the protocol. I use a slightly different protocol to atomically read and increment a special counter entry... I have some LDAP entries which have a single relevant attribute that's an integer which I want to be able to read and increment (I use these as UIDs for new user entries). To do this I rename the entry with modrdn to name containing a unique (partly random) string, and if the rename succeeds read the counter, increment and write it, then rename the entry back to it's normal rdn. If the rename fails it's because the entry didn't exist (because another process had already renamed it) so I wait a while and try again. - Jürgen > perl -MNet::LDAP -e 'print $Net::LDAP::VERSION,"\n"' shows 0.14. > > Thanks, > > Bing > > Bing Du <bi...@ta..., 979-845-9577> > Texas A&M University, CIS, Operating Systems, Unix > |
|
From: Graham B. <gb...@po...> - 2000-11-27 17:43:20
|
write() and write_cmd() takes multiple arguments. Each argument should be a Net::LDAP::Entry object. Graham. On Mon, Nov 27, 2000 at 10:19:28AM -0600, Bing Du wrote: > 'perldoc Net::LDAP::LDIF' does not provide much detail about > 'write(ENTRIES)' and 'write_cmd(ENTRIES)'. I need to know what data > structure ENTRIES should be? Where can I find an example of using > 'write'? > > By the way, how can I check what version of Net::LDAP I have? > > Thanks, > > Bing > > Bing Du <bi...@ta..., 979-845-9577> > Texas A&M University, CIS, Operating Systems, Unix > |
|
From: Bing D. <Bi...@ci...> - 2000-11-27 17:10:54
|
Does Net::LDAP provide any mechanism to lock an entry before modifying it? So other script using Net::LDAP or ldapmodify command can not modify the same entry. perl -MNet::LDAP -e 'print $Net::LDAP::VERSION,"\n"' shows 0.14. Thanks, Bing Bing Du <bi...@ta..., 979-845-9577> Texas A&M University, CIS, Operating Systems, Unix |
|
From: Chris R. <chr...@me...> - 2000-11-27 16:50:24
|
Bing Du <Bi...@ci...> wrote:
> 'perldoc Net::LDAP::LDIF' does not provide much detail about
> 'write(ENTRIES)' and 'write_cmd(ENTRIES)'. I need to know what data
> structure ENTRIES should be? Where can I find an example of using
> 'write'?
I think they are supposed to be arrays of Net::LDAP::Entry objects. Judging
from LDIF.pm line 168pp anyway:
[...]
foreach $entry (@_) {
print "\n" if tell($self->{'fh'});
my $dn = $entry->dn;
[...]
> By the way, how can I check what version of Net::LDAP I have?
Check the $Net::LDAP::VERSION variable.
> Thanks,
>
> Bing
>
> Bing Du <bi...@ta..., 979-845-9577>
> Texas A&M University, CIS, Operating Systems, Unix
Cheers,
Chris
|
|
From: Bing D. <Bi...@ci...> - 2000-11-27 16:20:01
|
'perldoc Net::LDAP::LDIF' does not provide much detail about 'write(ENTRIES)' and 'write_cmd(ENTRIES)'. I need to know what data structure ENTRIES should be? Where can I find an example of using 'write'? By the way, how can I check what version of Net::LDAP I have? Thanks, Bing Bing Du <bi...@ta..., 979-845-9577> Texas A&M University, CIS, Operating Systems, Unix |
|
From: shell b <she...@ya...> - 2000-11-27 06:39:45
|
can any one give me the steps for installing and configuring the LDAP server and LDAP client onto a network using Linux thanks in advance __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
|
From: ritu r. j. <lin...@re...> - 2000-11-24 11:35:00
|
please can someone help to know the source of getting full information about access control lists. and replication in LDAP thanks in advance _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ |
|
From: Chris R. <chr...@me...> - 2000-11-24 08:44:21
|
Terence Ho <ter...@ka...> wrote:
> I have code the follwing and want to get the result of the compare :
>
> part of the code :
>
> $mesg = $ldap->compare(dn => 'cn=test2,o=kader,c=hk',
> attr => 'cn',
> value => 'test2'
> );
> print $mesg;
> print "not 4" if $mesg->code;
> print "ok 4\n";
>
> result :
> Net::LDAP::Compare=HASH(0x830dbd4)not 4ok 4
>
> Can anyone tell me where I can find more info or just give me a short
> example.
>
> Best regards,
> Terence
>
The $mesg value returned by $ldap->compare is an object, and printing an
object (like you are) will usually not give you the results you desire.
What you need to do is to look at the code in $mesg->code; it'll be either
LDAP_COMPARE_TRUE, or LDAP_COMPARE_FALSE, or something else if Bad Things
Happened.
Try this:
use Net::LDAP::Util qw(ldap_error_name);
use Net::LDAP::Constant qw(LDAP_COMPARE_TRUE LDAP_COMPARE_FALSE);
$mesg = $ldap->compare(...); # As before
if ($mesg->code == LDAP_COMPARE_TRUE) {
print "ok\n";
} elsif ($mesg->code == LDAP_COMPARE_FALSE) {
print "not ok\n";
} else {
print "error " . ldap_error_name($mesg->code) . "\n";
}
Cheers,
Chris
|
|
From: Terence H. <ter...@ka...> - 2000-11-24 07:18:12
|
I have code the follwing and want to get the result of the compare :
part of the code :
$mesg = $ldap->compare(dn => 'cn=test2,o=kader,c=hk',
attr => 'cn',
value => 'test2'
);
print $mesg;
print "not 4" if $mesg->code;
print "ok 4\n";
result :
Net::LDAP::Compare=HASH(0x830dbd4)not 4ok 4
Can anyone tell me where I can find more info or just give me a short
example.
Best regards,
Terence
|
|
From: Chris R. <chr...@me...> - 2000-11-23 07:41:01
|
ritu rani jaiswal <lin...@re...> wrote: > where will i get the full information about replication in ldap > and the ACL . > > please help There are no LDAP standards which specify these. You will need to look for Internet drafts. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2000-11-23 07:24:26
|
On Wed, Nov 22, 2000 at 11:02:35AM +0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Tue, Nov 21, 2000 at 01:33:46PM +0000, Chris Ridd wrote: > >> So since Net::LDAP is character-set agnostic, it handles UTF-8 values OK. > >> What you do with the bytes of the value once you get them from Net::LDAP > >> is up to you. Presumably there are ways in perl 5.6 to convert a string > >> full of bytes which happen to be a UTF-8 representation of a string into > >> a string which is interpreted by perl as UTF-8. I seem to recall that > >> perl 5.6 has ways to do these conversions. > > > > In 5.6 (if Net::LDAP will work with 5.6) the strings should be returned as > > UTF8 IIRC. > > > > Graham. > > Even when talking to an LDAPv2 server? You don't know what character set is > being used by the LDAPv2 server, so converting to UTF-8 won't be possible. Hm, yes had not thought about that. Ah well if it causes a problem we will fix it. Graham. |
|
From: ritu r. j. <lin...@re...> - 2000-11-23 06:43:07
|
where will i get the full information about replication in ldap and the ACL . please help _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-11-22 18:43:30
|
At 06:23 AM 11/22/00 +0000, ritu rani jaiswal wrote: >can u please tell me where to get the information regarding > >the differences between LDAP Version 2 and LDAP Version 3 I recently submitted a Internet Draft discussing some of the LDAPv2 v. LDAPv3 issues. http://search.ietf.org/internet-drafts/draft-zeilenga-ldapbis-vd-00.txt Comments in regard to this 'work in progress' should be provided as indicated the I-D. Kurt |
|
From: Chris R. <chr...@me...> - 2000-11-22 11:05:30
|
Sim...@wi... wrote: > Looking in the debug traces it seems that the attribute is not > returned by the server. That's correct behaviour. > I've seen this behaviour from Novell when a user does not have > rights to an attribute. That's entirely possible. > I would have expected that the attribute would exist even if it was > a zero length string. That would depend on the schema. I suspect having a zero length value would not make sense (what time would that represent?) Cheers, Chris |
|
From: Chris R. <chr...@me...> - 2000-11-22 11:05:14
|
James Chang <Jam...@ms...> wrote: > Thanks guys, I've managed to get Utf8 characters into and out of > attributes using the Net::LDAP module as well as perform searches on it. > > I've done it the hard way comparing the unicode characters equivalent (via > Unicode::String) going in and coming out of the LDAP server (open LDAP > 2.06). > > I was primarily concerned with the base 64 encoding aspect of any > character not within the ASCII character set but from the tests I've run > so far it looks good. You don't need to base 64 encode/decode any values when using Net::LDAP, as LDAP is a binary protocol and can therefore handle arbitrary binary values. Cheers, Chris |
|
From: Chris R. <chr...@me...> - 2000-11-22 11:03:08
|
Graham Barr <gb...@po...> wrote: > On Tue, Nov 21, 2000 at 01:33:46PM +0000, Chris Ridd wrote: >> So since Net::LDAP is character-set agnostic, it handles UTF-8 values OK. >> What you do with the bytes of the value once you get them from Net::LDAP >> is up to you. Presumably there are ways in perl 5.6 to convert a string >> full of bytes which happen to be a UTF-8 representation of a string into >> a string which is interpreted by perl as UTF-8. I seem to recall that >> perl 5.6 has ways to do these conversions. > > In 5.6 (if Net::LDAP will work with 5.6) the strings should be returned as > UTF8 IIRC. > > Graham. Even when talking to an LDAPv2 server? You don't know what character set is being used by the LDAPv2 server, so converting to UTF-8 won't be possible. Cheers, Chris |
|
From: James C. <Jam...@ms...> - 2000-11-22 09:01:09
|
Thanks guys, I've managed to get Utf8 characters into and out of attributes using the Net::LDAP module as well as perform searches on it. I've done it the hard way comparing the unicode characters equivalent (via Unicode::String) going in and coming out of the LDAP server (open LDAP 2.06). I was primarily concerned with the base 64 encoding aspect of any character not within the ASCII character set but from the tests I've run so far it looks good. Great job! Message Central plc. Suite K307 Tower Bridge Business Complex 100 Clements Road London SE16 4DG Web: www.msgc.com Email: in...@ms... Tel: +44 20 7394 9511 Fax: +44 20 7231 8201 If you receive this email by mistake, please destroy your copy, having returned this copy to the sender. This email and any attachments to it may have been tampered with. Message Central plc cannot warrant the accuracy, completeness or freedom from viruses of this email or any attachments. You are strongly advised to check this email for viruses before downloading or opening any attachments. Opinions expressed in this email are those of the author and not of Message Central plc. -----Original Message----- From: Graham Barr [mailto:gb...@po...] Sent: Wednesday, November 22, 2000 06:33 To: Chris Ridd Cc: James Chang; 'per...@li...' Subject: Re: Greek characters - Utf8 encoding. On Tue, Nov 21, 2000 at 01:33:46PM +0000, Chris Ridd wrote: > So since Net::LDAP is character-set agnostic, it handles UTF-8 values OK. > What you do with the bytes of the value once you get them from Net::LDAP is > up to you. Presumably there are ways in perl 5.6 to convert a string full > of bytes which happen to be a UTF-8 representation of a string into a > string which is interpreted by perl as UTF-8. I seem to recall that perl > 5.6 has ways to do these conversions. In 5.6 (if Net::LDAP will work with 5.6) the strings should be returned as UTF8 IIRC. Graham. |
7902 messages has been excluded from this view by a project administrator.
