perl-ldap-dev

Re: Bug? Changing netware home directory via LDAP.

[Fergus D. <Fer...@dc...>]

Hi Jim,

I've mapped the NDS "Home Directory" attribute to NWHomeDirectory as I want
"homeDirectoy" to be associated with the posixAccount homeDirectory
attribute. Using LDAP I populate these with values as given (now using
$NWHomeDirectory =~ s/\\/\\5c/g; as suggested by Chris. As I go through the
students I add lines to a batch file that is later run on a client logged
into the netware server as admin. The batch file does the following:

mkdir $path
rights $path <rights> /user=$username
flag $path +di +ri /do
setquota /d:t $vol:$path /b:m 50

I haven't finished testing the script yet and so can't confirm that
everything works perfectly - but we can create a/cs that can login to both
netware and Solaris and have a correct homedir path.

Fergus.

Jim Harle wrote:

> Fergus,
>   What Netware attribute did you map to NWHomeDirectory?  I am interested
> in setting home directories also.  What do you do to actually create the
> directories?  Any other hints?  I have account creation scripts that do
> everything but setup home directories and create GroupWise accounts.
>   --Jim harle
>
> On Thu, 31 Aug 2000, Fergus Donohue wrote:
>
> > Hi All,
> >
> > I have a problem with setting the Netware home directory attribute via
> > perl-ldap. Here's what I'm doing:
> >
> > I have an NDS8 server on which I'm creating user a/cs. This works fine
> > in the majority of cases but I found what may be a bug in perl-ldap
> > today. I'm setting the NWHomeDirectory attribute (changed name to avoid
> > clash with posixAccount) to items like:
> >
> > cn=CYAN_DATA4,ou=CYAN,o=DCU#0#\students\J-Z\xe\xe2\userj9
> >
> > with no problems - however when I try to set it to the following it
> > doesn't work:
> >
> > cn=CYAN_DATA2,ou=CYAN,o=DCU#0#\students\C-E\ca\ca2\userj9
> >
> > I get garbage in the "Home Directory" dialogue box under ConsoleOne
> > after the "C-E".
> >
> > I've tracked this down to perl -ldap interpreting \c (or \b, \a etc.) as
> > special characters. I build this string on the fly so I can't see an
> > easy way of single quoting it (if that would help?). I've tried setting
> >
> > $NWHomeDirectory="'".$NWHomeDirectory."'";
> >
> > but it didn't help.
> >
> > Has anyone any ideas?
> >
> > Thanks,
> >
> > Fergus.
> >
> >
> >

Re: Bug? Changing netware home directory via LDAP.

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

Fergus,
  What Netware attribute did you map to NWHomeDirectory?  I am interested
in setting home directories also.  What do you do to actually create the
directories?  Any other hints?  I have account creation scripts that do
everything but setup home directories and create GroupWise accounts.
  --Jim harle


On Thu, 31 Aug 2000, Fergus Donohue wrote:

> Hi All,
> 
> I have a problem with setting the Netware home directory attribute via
> perl-ldap. Here's what I'm doing:
> 
> I have an NDS8 server on which I'm creating user a/cs. This works fine
> in the majority of cases but I found what may be a bug in perl-ldap
> today. I'm setting the NWHomeDirectory attribute (changed name to avoid
> clash with posixAccount) to items like:
> 
> cn=CYAN_DATA4,ou=CYAN,o=DCU#0#\students\J-Z\xe\xe2\userj9
> 
> with no problems - however when I try to set it to the following it
> doesn't work:
> 
> cn=CYAN_DATA2,ou=CYAN,o=DCU#0#\students\C-E\ca\ca2\userj9
> 
> I get garbage in the "Home Directory" dialogue box under ConsoleOne
> after the "C-E".
> 
> I've tracked this down to perl -ldap interpreting \c (or \b, \a etc.) as
> special characters. I build this string on the fly so I can't see an
> easy way of single quoting it (if that would help?). I've tried setting
> 
> $NWHomeDirectory="'".$NWHomeDirectory."'";
> 
> but it didn't help.
> 
> Has anyone any ideas?
> 
> Thanks,
> 
> Fergus.
> 
> 
> 

Re: Bug? Changing netware home directory via LDAP.

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

Fergus Donohue <fer...@dc...> wrote:
> Hi All,
> 
> I have a problem with setting the Netware home directory attribute via
> perl-ldap. Here's what I'm doing:
> 
> I have an NDS8 server on which I'm creating user a/cs. This works fine
> in the majority of cases but I found what may be a bug in perl-ldap
> today. I'm setting the NWHomeDirectory attribute (changed name to avoid
> clash with posixAccount) to items like:
> 
> cn=CYAN_DATA4,ou=CYAN,o=DCU#0#\students\J-Z\xe\xe2\userj9
> 
> with no problems - however when I try to set it to the following it
> doesn't work:
> 
> cn=CYAN_DATA2,ou=CYAN,o=DCU#0#\students\C-E\ca\ca2\userj9
> 
> I get garbage in the "Home Directory" dialogue box under ConsoleOne
> after the "C-E".
> 
> I've tracked this down to perl -ldap interpreting \c (or \b, \a etc.) as
> special characters. I build this string on the fly so I can't see an
> easy way of single quoting it (if that would help?). I've tried setting
> 
> $NWHomeDirectory="'".$NWHomeDirectory."'";
> 
> but it didn't help.
> 
> Has anyone any ideas?
> 
> Thanks,
> 
> Fergus.
> 
> 

That sounds right. If you read RFC 2252 section 4.3 (penultimate
paragraph), you will find that backslashes are special in LDAP values
(actually, pretty much everywhere :-) so you will need to replace them with
\5c before sending them across the wire.

Something like:

$dir =~ s/\\/\\5c/g;

$ldap->modify(...,
              add => [ 'NWHomeDirectory' => [ "$dn#$foo#$dir" ] ]);

There are some other special characters which the RFC also mentions.

Cheers,

Chris

Bug? Changing netware home directory via LDAP.

[Fergus D. <fer...@dc...>]

Hi All,

I have a problem with setting the Netware home directory attribute via
perl-ldap. Here's what I'm doing:

I have an NDS8 server on which I'm creating user a/cs. This works fine
in the majority of cases but I found what may be a bug in perl-ldap
today. I'm setting the NWHomeDirectory attribute (changed name to avoid
clash with posixAccount) to items like:

cn=CYAN_DATA4,ou=CYAN,o=DCU#0#\students\J-Z\xe\xe2\userj9

with no problems - however when I try to set it to the following it
doesn't work:

cn=CYAN_DATA2,ou=CYAN,o=DCU#0#\students\C-E\ca\ca2\userj9

I get garbage in the "Home Directory" dialogue box under ConsoleOne
after the "C-E".

I've tracked this down to perl -ldap interpreting \c (or \b, \a etc.) as
special characters. I build this string on the fly so I can't see an
easy way of single quoting it (if that would help?). I've tried setting

$NWHomeDirectory="'".$NWHomeDirectory."'";

but it didn't help.

Has anyone any ideas?

Thanks,

Fergus.

modify problem

[Uwe G. <ug...@su...>]

Hi,

perl-ldap 0.20

$mesg = $ldap->modify( "cn=".$group.",".$ldapbase,
                       changes => [
                           replace => [ memberuid => "" ],  # change memberuids
                           replace => [ description => $desc ]
                          ]
             );

do not work but :

$mesg = $ldap->modify( "cn=".$group.",".$ldapbase, replace => { memberuid => "" });  # change memberuids
$mesg = $ldap->modify( "cn=".$group.",".$ldapbase, replace => { description => $desc });

works fine. Where is the problem ?


-- 
tschau , Uwe Gansert
-------------------------------------------------------------------------------
echo '$e=5;$p=3;$q=13;$h=$p*$q;while(($e*++$d)%($h-$p-$q+1)-1){};while($t=subst
r("82758c1b8939c7ef5c5d0°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°1eaa4aa38516aed5559fe
27fd0f5b0b464474b2316eac~~~~        ug...@su...        ~~~~390a03",$i,3)){$_.=pa
ck"I",(hex($t)%$h)**$d%$°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°h+95;s/_/ /g;$_=($i+=
3)%2?uc:lc;print"$_\n";}'|perl -ne"chomp;s/°|~|\s*ug@[^~]*//g;print"|perl

Re: Bind Return Code 86

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

use Net::LDAP::Util qw(ldap_error_text ldap_error_name);
print ldap_error_name(86),"\n",ldap_error_text(86);

Gives ...

LDAP_AUTH_UNKNOWN
The method of authentication requested in a bind request is unknown to
the server

Graham.

On Wed, Aug 30, 2000 at 01:53:16PM -0700, Steve Benson wrote:
> Hello everyone:
> 
> I'm getting a bind return code of 86 and the listing I have for LDAP return 
> codes only goes up to 80.
> 
> Does anyone know of a return code listing that would include 86 or the 
> meaning of return code 86?
> 
> Thanks,
> 
> ............ Steve
> 

Bind Return Code 86

[Steve B. <ste...@st...>]

Hello everyone:

I'm getting a bind return code of 86 and the listing I have for LDAP return 
codes only goes up to 80.

Does anyone know of a return code listing that would include 86 or the 
meaning of return code 86?

Thanks,

............ Steve

Problem when with mod_perl

[Jie G. <J....@is...>]

Hi All,

I have been trying to use Net::LDAP within mod_perl, and have encountered 
the following:

1. Getting a message upon starting Apache:

Constant subroutine cTAG redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine cTYPE redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine cVAR redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine cLOOP redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine cOPT redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine cCHILD redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opUNKNOWN redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opBOOLEAN redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opINTEGER redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opBITSTR redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opSTRING redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opNULL redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opOBJID redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opREAL redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opSEQUENCE redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opSET redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opUTIME redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opGTIME redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opUTF8 redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opANY redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.
Constant subroutine opCHOICE redefined at /usr/local/lib/perl5/site_perl/5.005/Convert/ASN1.pm line 47.

I know this is only used by Net::LDAP on this server. What was it that caused this?


2. Getting wrong returned results intermittently, or with a pattern
(every a few clicks). Debugging shows that password is to sent every
time:

Here's the debugging output of a "bad" access:

---------------------------------------------------------------------------
Net::LDAP=HASH(0x982aa4) sending:

30 3E 02 01 04 60 39 02 01 02 04 32 6C 6F 67 69 0>...`9....2logi
6E 6E 61 6D 65 3D 68 61 6E 64 79 6D 61 6E 2C 6F nname=handyman,o
75 3D 70 65 6F 70 6C 65 2C 64 63 3D 75 63 63 2C u=people,dc=ucc,
64 63 3D 75 73 79 64 2E 65 64 75 2E 61 75 80 00 dc=usyd.edu.au..

0000 30   62: SEQUENCE {
0002 02    1:   INTEGER = 4
0005 60   57:   [APPLICATION 0] {
0007 02    1:     INTEGER = 2
000A 04   50:     STRING = 'loginname=handyman,ou=people,dc=ucc,dc=usyd.edu.au'
003E 80    0:     [CONTEXT 0]
0040        :   }
0040        : }
Net::LDAP=HASH(0x982aa4) received:

30 0C 02 01 04 61 07 0A 01 00 04 00 04 00 __ __ 0....a........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 4
0005 61    7:   [APPLICATION 1] {
0007 0A    1:     ENUM = 0
000A 04    0:     STRING = ''
000C 04    0:     STRING = ''
000E        :   }
000E        : }
Net::LDAP=HASH(0x982aa4) sending:

30 53 02 01 05 6E 4E 04 30 6C 6F 67 69 6E 6E 61 0S...nN.0loginna
6D 65 3D 6A 69 65 67 61 6F 2C 6F 75 3D 70 65 6F me=jiegao,ou=peo
70 6C 65 2C 64 63 3D 75 63 63 2C 64 63 3D 75 73 ple,dc=ucc,dc=us
79 64 2E 65 64 75 2E 61 75 30 1A 04 07 63 6F 75 yd.edu.au0...cou
72 73 65 73 04 0F 32 30 30 30 3A 70 63 6F 6C 32 rses..2000:pcol2
30 30 31 3A 31 __ __ __ __ __ __ __ __ __ __ __ 001:1

0000 30   83: SEQUENCE {
0002 02    1:   INTEGER = 5
0005 6E   78:   [APPLICATION 14] {
0007 04   48:     STRING = 'loginname=jiegao,ou=people,dc=ucc,dc=usyd.edu.au'
0039 30   26:     SEQUENCE {
003B 04    7:       STRING = 'courses'
0044 04   15:       STRING = '2000:pcol2001:1'
0055        :     }
0055        :   }
0055        : }
Net::LDAP=HASH(0x982aa4) received:

30 0C 02 01 05 6F 07 0A 01 32 04 00 04 00 __ __ 0....o...2....

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 5
0005 6F    7:   [APPLICATION 15] {
0007 0A    1:     ENUM = 50
000A 04    0:     STRING = ''
000C 04    0:     STRING = ''
000E        :   }
000E        : }
status: The client does not have sufficient access to perform the requested
operation

---------------------------------------------------------------------------
With a "good" access, I would see the password there, and the compare operation
would return ENUM = 6.


Here's the subroutine that I use in a mod_perl handler:

---------------------------------------------------------------------------
sub get_crs_enrol_status ($$$) {
    my ($self, $r, @crs_allowed) = @_;
    my $status = '';

    my $debug = $r->dir_config("AuthCookieDebug") || 0;
    my $user = $r->connection->user;
       #$user = 'jcho1625';

    my $ldap = Net::LDAP->new('directory.usyd.edu.au', debug => 255) or die "$@";

    my $mesg = $ldap->bind(
                           dn =>  'loginname=handyman,ou=people,dc=ucc,dc=usyd.edu.au',
                     password =>  'test'
               );
    #warn ldap_error_text($mesg->code) if $mesg->code;


    my $dn = "loginname=$user,ou=people,dc=ucc,dc=usyd.edu.au";

    foreach my $i (@crs_allowed) {
        my $mesg_inner = $ldap->compare (
                                 $dn,
                                 attr    =>    'courses',
                                 value   =>    "$i"
                                );
        $status = ldap_error_text($mesg_inner->code) if $mesg_inner->code;

        if (defined $status && $status =~ /given is in/i) {
            print STDERR "status: $status\n";
            $status = 'Yes';
            print STDERR "$user is enrolled in $i\n" if $debug;
            last;

        } elsif (defined $status && $status =~ /not/) {
            print STDERR "status: $status\n";
            $status = '';
            print STDERR "$user is NOT enrolled in $i\n" if $debug;
        }
    }

    $mesg = $ldap->unbind;
    #warn ldap_error_text($mesg->code) if $mesg->code;
    if (defined $status && $status) {
        $status = '';
        return 'Yes';
    } else {
        return 'No';
    }
}
---------------------------------------------------------------------------

I can't see anything wrong here, and there doesn't seem to be a closure problem in particular.

Any help is appreciated.



Jie

Re: Can't call method "read" without a package or object reference at...

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

That means you didn't get back a file handle try doing
my $ldif = new .... || die("failed to open file $ldif_file. $!\n");

that will die and tell you the reason why it failed to create the
filehandle.

mark

On Tue, 29 Aug 2000, Bing Du wrote:

> The following code piece gave the following error.
> 
> ===============================
> #!/usr/sbin/perl
> 
> use Net::LDAP::LDIF;
> 
> $ldif_file = "/var/md/dsa/master/dump/mailusers.dump";
> 
> $ldif = Net::LDAP::LDIF->new("$ldif_file","r");
> 
> while ( $entry = $ldif->read() ) {
> $entry->dump;
> }
> 
> $ldif->done();
> ==============================
> 
> Can't call method "read" without a package or object reference at
> ./for-keith-ph
> .pl line 19.
> 
> Acctually, most part of the above code was from 'perldoc
> Net::LDAP::LDIF'.  Can anybody tell me what I did wrong?
> 
> Thanks,
> 
> Bing
> 

Can't call method "read" without a package or object reference at...

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

The following code piece gave the following error.

===============================
#!/usr/sbin/perl

use Net::LDAP::LDIF;

$ldif_file = "/var/md/dsa/master/dump/mailusers.dump";

$ldif = Net::LDAP::LDIF->new("$ldif_file","r");

while ( $entry = $ldif->read() ) {
$entry->dump;
}

$ldif->done();
==============================

Can't call method "read" without a package or object reference at
./for-keith-ph
.pl line 19.

Acctually, most part of the above code was from 'perldoc
Net::LDAP::LDIF'.  Can anybody tell me what I did wrong?

Thanks,

Bing

Re: LDAP search broke 0.19->0.20 ?

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

On Tue, Aug 29, 2000 at 09:48:56AM -0400, Jim Harle wrote:
> Graham,
>   I applaud your trying to make get or a rename of it function more as
> expected by an inexperienced person.  As much as I dislike using longis
> names when short ones are great, I think the approach of deprecating "get"
> is correct.

I also dislike longish names. Maybe when nobody is using ->get we can have
it as an alias for get_value :)

>  Note that you used "get" instead of get_value twice in the
> doc below, though.  Once in
>   Then a get for attribute "name" with alloptions set would return
> and again in

Thanks.

>           my @entry = $entr->get($field);

That was an extract of code from the original mail.

Thanks,
Graham.

> On Tue, 29 Aug 2000, Graham Barr wrote:
> 
> > On Sat, Aug 26, 2000 at 12:33:32PM -0700, Yann Ramin wrote:
> > > Hi,
> > > 
> > > Using the following code snippet under Net::LDAP 0.19 worked fine, but
> > > once I went to 0.20, it broke, and is now returning an array??? Is there
> > > something wrong with my code?
> > 
> > In 0.20 ->get was changed to match it's documentation. However it
> > seems that what get now returns is not what is "expected"
> > 
> > In the version in CVS, and what will be in 0.21, ->get has been
> > returned to it's previous implementation, but has also been
> > depricated.
> > 
> > ->get has been replaced by ->get_value which is described below.
> > 
> > I would appriciate any feedback on this.
> > 
> > Graham.
> > 
> > 
> > =item get_value ( ATTR [, OPTIONS ] )
> > 
> > Get the values for the attribute ATTR. In a list context returns all
> > values for the given attribute, or the empty list if the attribute does
> > not exist. In a scalar context returns the first value for the attribute
> > or undef if the attribute does not exist.
> > 
> > The return value may be changed by OPTIONS, which is a list of name => value
> > pairs, valid options are :-
> > 
> > =over 4
> > 
> > =item alloptions
> > 
> > If TRUE then the result will be a hash reference. The keys of the hash
> > will be the options and the hash value will be the values for those attributes.
> > For example if an entry had
> > 
> >   name: Graham Barr
> >   name;en-us: Bob
> > 
> > Then a get for attribute "name" with alloptions set would return
> > 
> >   {
> >     ''       => [ 'Graham Barr' ],
> >     ';en-us' => [ 'Bob' ]
> >   }
> > 
> > =item asref
> > 
> > If TRUE then the result will be a reference to an array containing all the
> > values for the attribute, or undef if the attribute does not exist.
> > 
> > =back
> > 
> > B<NOTE>: In the interest of performance the array references returned by C<get_value>
> > are references to structures held inside the entry object. These values and
> > thier contents should B<NOT> be modified directly.
> > 
> > > $ref is the DN, and $field is usualy 'cn' or 'uidnumber', both of which
> > > exist.
> > > 
> > > sub get_user_var {
> > >         my ($self, $ref, $field) = @_;
> > > 
> > >         my $mesg = $self->{LDAP}->search (
> > >                 base    =>      $ref,
> > >                 filter  =>      "(objectclass=*)"
> > >         );
> > > 
> > >         my @entries = $mesg->entries;
> > >         if (!@entries) { return; }
> > >         my $entr = $entries[0];
> > >         my @entry = $entr->get($field);
> > > 	my $e = $entry[0];
> > >         return $e;
> > > 
> > > }
> > 
> 
> 
> 

Re: LDAP search broke 0.19->0.20 ?

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

Graham,
  I applaud your trying to make get or a rename of it function more as
expected by an inexperienced person.  As much as I dislike using longis
names when short ones are great, I think the approach of deprecating "get"
is correct.  Note that you used "get" instead of get_value twice in the
doc below, though.  Once in
  Then a get for attribute "name" with alloptions set would return
and again in
          my @entry = $entr->get($field);

--Jim    


On Tue, 29 Aug 2000, Graham Barr wrote:

> On Sat, Aug 26, 2000 at 12:33:32PM -0700, Yann Ramin wrote:
> > Hi,
> > 
> > Using the following code snippet under Net::LDAP 0.19 worked fine, but
> > once I went to 0.20, it broke, and is now returning an array??? Is there
> > something wrong with my code?
> 
> In 0.20 ->get was changed to match it's documentation. However it
> seems that what get now returns is not what is "expected"
> 
> In the version in CVS, and what will be in 0.21, ->get has been
> returned to it's previous implementation, but has also been
> depricated.
> 
> ->get has been replaced by ->get_value which is described below.
> 
> I would appriciate any feedback on this.
> 
> Graham.
> 
> 
> =item get_value ( ATTR [, OPTIONS ] )
> 
> Get the values for the attribute ATTR. In a list context returns all
> values for the given attribute, or the empty list if the attribute does
> not exist. In a scalar context returns the first value for the attribute
> or undef if the attribute does not exist.
> 
> The return value may be changed by OPTIONS, which is a list of name => value
> pairs, valid options are :-
> 
> =over 4
> 
> =item alloptions
> 
> If TRUE then the result will be a hash reference. The keys of the hash
> will be the options and the hash value will be the values for those attributes.
> For example if an entry had
> 
>   name: Graham Barr
>   name;en-us: Bob
> 
> Then a get for attribute "name" with alloptions set would return
> 
>   {
>     ''       => [ 'Graham Barr' ],
>     ';en-us' => [ 'Bob' ]
>   }
> 
> =item asref
> 
> If TRUE then the result will be a reference to an array containing all the
> values for the attribute, or undef if the attribute does not exist.
> 
> =back
> 
> B<NOTE>: In the interest of performance the array references returned by C<get_value>
> are references to structures held inside the entry object. These values and
> thier contents should B<NOT> be modified directly.
> 
> > $ref is the DN, and $field is usualy 'cn' or 'uidnumber', both of which
> > exist.
> > 
> > sub get_user_var {
> >         my ($self, $ref, $field) = @_;
> > 
> >         my $mesg = $self->{LDAP}->search (
> >                 base    =>      $ref,
> >                 filter  =>      "(objectclass=*)"
> >         );
> > 
> >         my @entries = $mesg->entries;
> >         if (!@entries) { return; }
> >         my $entr = $entries[0];
> >         my @entry = $entr->get($field);
> > 	my $e = $entry[0];
> >         return $e;
> > 
> > }
> 

Re: LDAP search broke 0.19->0.20 ?

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

On Sat, Aug 26, 2000 at 12:33:32PM -0700, Yann Ramin wrote:
> Hi,
> 
> Using the following code snippet under Net::LDAP 0.19 worked fine, but
> once I went to 0.20, it broke, and is now returning an array??? Is there
> something wrong with my code?

In 0.20 ->get was changed to match it's documentation. However it
seems that what get now returns is not what is "expected"

In the version in CVS, and what will be in 0.21, ->get has been
returned to it's previous implementation, but has also been
depricated.

->get has been replaced by ->get_value which is described below.

I would appriciate any feedback on this.

Graham.


=item get_value ( ATTR [, OPTIONS ] )

Get the values for the attribute ATTR. In a list context returns all
values for the given attribute, or the empty list if the attribute does
not exist. In a scalar context returns the first value for the attribute
or undef if the attribute does not exist.

The return value may be changed by OPTIONS, which is a list of name => value
pairs, valid options are :-

=over 4

=item alloptions

If TRUE then the result will be a hash reference. The keys of the hash
will be the options and the hash value will be the values for those attributes.
For example if an entry had

  name: Graham Barr
  name;en-us: Bob

Then a get for attribute "name" with alloptions set would return

  {
    ''       => [ 'Graham Barr' ],
    ';en-us' => [ 'Bob' ]
  }

=item asref

If TRUE then the result will be a reference to an array containing all the
values for the attribute, or undef if the attribute does not exist.

=back

B<NOTE>: In the interest of performance the array references returned by C<get_value>
are references to structures held inside the entry object. These values and
thier contents should B<NOT> be modified directly.

> $ref is the DN, and $field is usualy 'cn' or 'uidnumber', both of which
> exist.
> 
> sub get_user_var {
>         my ($self, $ref, $field) = @_;
> 
>         my $mesg = $self->{LDAP}->search (
>                 base    =>      $ref,
>                 filter  =>      "(objectclass=*)"
>         );
> 
>         my @entries = $mesg->entries;
>         if (!@entries) { return; }
>         my $entr = $entries[0];
>         my @entry = $entr->get($field);
> 	my $e = $entry[0];
>         return $e;
> 
> }

updating attributes

[<ms...@ma...>]

hi folks,

i have a problem updating attributes.  what i did was the following:

my($ldap) = Net::LDAP->new($LDAPHOST);
my $result = $ldap->bind(dn=>$ROOTDN,password=>$ROOTPW);
my $mesg = $ldap->search(base=>$BASEDN,filter=>$UID);
.. 
my $entry = $mesg->entry(0);
$entry->replace($thisattr=>$value);
my $mesg = $entry->update($ldap);

when i check the return codes for the last line, perl reports:

LDAP_INSUFFICIENT_ACCESS
The client does not have sufficient access to perform the requested operation

i've checked the values up to the final line, and everything is as expected.  so what is the problem with access right?  am i already binded to the server using the root?

thanks
manuel.


_____________________________________________________________
Global Virtual Desktop
Get your free Desktop at http://www.magicaldesk.com

Great work

[ramprasad <ram...@ne...>]

Dear sir,
    I am a beginner with LDAP and I find your documentation extremely
useful ( not that I have gone thru it entirely )

    I think you can make your documentation even more friendly by using
frames  listing all the classes  (as links ) together in a frame    and
listing the methods of the class as targets of the links in the main
frame Something like JAVA Documentation online by SUN

Thanks and regards
Ramprasad A P
Netcore Solns

LDAP search broke 0.19->0.20 ?

[Yann R. <at...@at...>]

Hi,

Using the following code snippet under Net::LDAP 0.19 worked fine, but
once I went to 0.20, it broke, and is now returning an array??? Is there
something wrong with my code?

$ref is the DN, and $field is usualy 'cn' or 'uidnumber', both of which
exist.

sub get_user_var {
        my ($self, $ref, $field) = @_;

        my $mesg = $self->{LDAP}->search (
                base    =>      $ref,
                filter  =>      "(objectclass=*)"
        );

        my @entries = $mesg->entries;
        if (!@entries) { return; }
        my $entr = $entries[0];
        my @entry = $entr->get($field);
	my $e = $entry[0];
        return $e;

}

-- 

--------------------------------------------------------------------
Yann Ramin			at...@at...
Atrus Trivalie Productions	www.redshift.com/~yramin
Monterey High IT		www.montereyhigh.com
ICQ 				46805627
AIM				oddatrus
Marina, CA

IRM Developer                   Network Toaster Developer
SNTS Developer                  KLevel Developer

(yes, this .signature is way too big)

"All cats die.  Socrates is dead.  Therefore Socrates is a cat."
	- The Logician

		THE STORY OF CREATION

In the beginning there was data.  The data was without form and null,
and darkness was upon the face of the console; and the Spirit of IBM
was moving over the face of the market.  And DEC said, "Let there be
registers"; and there were registers.  And DEC saw that they carried;
and DEC seperated the data from the instructions.  DEC called the data
Stack, and the instructions they called Code.  And there was evening
and there was a maorning, one interrupt...
		-- Rico Tudor

William Safire's Rules for Writers:

Remembe

'diff' for Net::LDAP entries

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

Hi.

Attached is a gzipped patch which attempts to implement a ->diff() method
for Net::LDAP::Entry. There is a little POD in the patch too. Patch is
against vanilla 0.20.

The intention is that you can do things like:

	my $old_entry = ...read from LDAP server
	my $new_entry = ...read from LDIF

	my $diff_entry = $old_entry->diff( $new_entry );
	$diff_entry->update( $ldap_server );

The only benefit of this over an add/delete sequence is that it should
occur as one LDAP operation. Hence a power failure shouldn't leave you
with the potential embarassement of an entry missing from the server.

No attempt is made to reconcile changes in the DN - it just fails.

regards,

jb

Re: Convert::ASN1 loading times

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

At 02:21 PM 8/25/00 +0100, John Berthels wrote:
>What do other people think?

Well, since you asked...

I think it's a little premature to be optimizing net::LDAP.  I'd
prefer a complete and correct API over an optimized one any day.

And, when "completeness" is declared, the optimizations that
will be critical to me will improve overall runtime performance
(such as Convert::ASN1 optimizations).

As you've noted, start up time only matters for small "one-shot"
applications.  I would argue that such applications which were
also time critical would be reimplemented using a language/API
that compiled native executable.  

For my uses of net::ldap, start up time rarely factors in.
Even for small "one-shot" applications, they are usually just
a little script I just whipped up to fulfill a requirement
of the moment.  The startup cost of net::ldap (and perl in
general) is easily offset by other costs (such as my time
whipping the thing together).  And if this script ever became
time critical, I'd write the thing in C to avoid the perl
overhead or use another approach (such, as in the web space,
changing from CGI to mod_perl).

Now, I'd like to see the completed net::LDAP optimized.  I
believe net::LDAP can be optimized to operate at comparable
run time speeds of other Perl LDAP modules... and startup
time (if it's really an issue) could be improved as well...
but completeness and correctness first.

Kurt

Re: Login/Authentication

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

I'll bet that you are using a bind like this:

my $mesg = $ldap->(mewilcox,password => mypassword);

and it's returning error code 32. Correct?

LDAP bind takes a DN and their password, not just their userid.

So first you have to look up a user's DN by constructing a search and
looking up their entry using their userid as the search filter.

then you retrieve their DN 

and then you can authenticate like so:
my $mesg = $ldap->bind("uid=mewilcox,ou=people,o=unt.edu",password=>
mypassword);

Mark



On Fri, 25 Aug 2000, Chelsie Pentz wrote:

> Hi ALL,
> 	I am trying to connect people to LDAP to do self-admin on their
> entries through a web page.  I collect the users name and password and then
> try and do a bind using there info.   I am always able to connect with
> people I have manually entered into the directory through the Netscape
> Console, but any person I add through my perl-ldap interface will not
> connect.  I always get the same error, 32, LDAP_NO_SUCH_OBJECT.  This cannot
> be the actual case, however, because before the attempted bind with their
> password and uid, I search through the directory to make sure they already
> exist.  Has anyone come up against this problem?  
> 
> Thanks
> Chelsie
> 

Login/Authentication

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

Hi ALL,
	I am trying to connect people to LDAP to do self-admin on their
entries through a web page.  I collect the users name and password and then
try and do a bind using there info.   I am always able to connect with
people I have manually entered into the directory through the Netscape
Console, but any person I add through my perl-ldap interface will not
connect.  I always get the same error, 32, LDAP_NO_SUCH_OBJECT.  This cannot
be the actual case, however, because before the attempted bind with their
password and uid, I search through the directory to make sure they already
exist.  Has anyone come up against this problem?  

Thanks
Chelsie

Re: Convert::ASN1 loading times

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

On Thu, 24 Aug 2000, Graham Barr wrote:

> However I am thinking, is this really worth it ? According to the
> above the parse is taking 0.122 seconds and the load takes 0.028 a
> saving of 0.1 seconds at startup time. Even you times only said it
> saved 0.24, is this extra maintenance (ie any change to the parse tree
> will need to be accounted for) really woth that extra 0.24 seconds ?

I'm not sure. On my home box I found it took around 60% of the startup
time (for Net::LDAP::ASN) that it did previously.

It is only of use (if at all) for those one-shot applications where
command latency is an issue. This is something I've noticed in the past
being a little annoying. For me, this 'feels' snappier when I run one-shot
commands which use Net::LDAP.

The potential maintenance burden is not something to be taken lightly, I
agree. It might be possible to code a little more defensively against
ASN.1 tree format changes and/or have a fallback method to parse the
definition if the load fails. I don't know if that would help or not.

What do other people think? I believe that there was some discussion a few
weeks back about Net::LDAP seeming much slower than C APIs when used as a
command line tool which I believe boiled down to startup times. Would
anyone involved in that care to try this patch and see if there is a
significant improvement for their application?

If the current format of the patch is problematic to employ, mail me
directly and I'll provide a more easily tried version.

regards,

jb

Re: Convert::ASN1 loading times

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

This is great and I will add it in. However given

Benchmark: timing 1000 iterations of load, parse, storable...
      load: 28 wallclock secs (28.29 usr +  0.19 sys = 28.48 CPU)
     parse: 123 wallclock secs (122.90 usr +  0.06 sys = 122.96 CPU)
  storable:  4 wallclock secs ( 3.97 usr +  0.16 sys =  4.13 CPU)

It seems like it could be worth using storable. But is takes 0.02 to
loas Storable, so the benefit is lost.

However I am thinking, is this really worth it ? According to the
above the parse is taking 0.122 seconds and the load takes 0.028
a saving of 0.1 seconds at startup time. Even you times only said
it saved 0.24, is this extra maintenance (ie any change to the parse
tree will need to be accounted for) really woth that extra 0.24
seconds ?

Graham.

On Mon, Aug 21, 2000 at 12:44:05AM +0100, John Berthels wrote:
> 
> OK - here is the second cut of the Convert::ASN1 save/load. I've reworked
> it in the light of Graham's comments. (Including those on recursion :-)
> 
> Attached is a gzipped tar with the patch for Convert/ASN1.pm, an
> 'ldap.asn' file and an 'Net/LDAP/ASN.pm.new' which you need to use the
> ->load method when you start Net::LDAP. Patch is against version 0.07 of
> ASN1.pm (i.e. the current CPAN rather than the current CVS).
> 
> The fastest load time for this I've seen is 0.31s, against a fastest load
> time of 0.55s for the current code. (This is looking at 'time
> -MNet::LDAP::ASN -e exit').
> 
> Using '-d:DProf' and looking at the CumulS column: The new ->load function
> takes ~0.07s and the old ->prepare function takes ~0.31s. These
> measurements seem to agree with the 'time' method and suggest a nice
> speedup.
> 
> The format of the ldap.asn file should now be more obvious to humans.
> 
> The empty tag bug should be fixed.
> 
> It tests out OK with my test app here. YMMV.
> 
> regards,
> 
> jb

> --- /usr/lib/perl5/site_perl/5.005/Convert/ASN1.pm	Tue May 30 10:00:01 2000
> +++ Convert/ASN1.pm	Mon Aug 21 00:09:19 2000
> @@ -7,6 +7,7 @@
>  use strict;
>  use vars qw($VERSION @ISA @EXPORT_OK %EXPORT_TAGS @opParts @opName $AUTOLOAD);
>  use Exporter;
> +#se Data::Dumper;
>  
>  BEGIN {
>    @ISA = qw(Exporter);
> @@ -138,6 +139,219 @@
>    $self->{tree} = _pack_struct($tree);
>    $self->{script} = (values %$tree)[0];
>    $self;
> +}
> +
> +#
> +# Here we provide for dumping and reloading the ASN.1 tree from a file.
> +# Essentially this allows us to skip the 'prepare' method by doing a 'load'
> +# instead.
> +#
> +sub save {
> +    my $self = shift;
> +    my $file = shift;
> +
> +    open( OUT, "> $file" ) or die( "Can't write to file [$file] : $!" );
> +# Data::Dumper version
> +#    print OUT Data::Dumper->Dump( [$self], [ '$asn' ] );
> +#    close OUT;
> +#    return 1;
> +    my $tree = $self->{tree};
> +    my %seen;		# Avoid writing same ref twice
> +    my( $name, $base );
> +    while( ( $name, $base ) = each %$tree ) {
> +	# Start a new ASN.1 type definition
> +	print OUT $name, ":", _ref_to_name( $base ), "\n";
> +	foreach my $op ( @$base ) {
> +	    _write_op_tree( \*OUT, $base, \%seen )
> +		or die( "Unable to write op for [$name] : $!" );
> +	}
> +	print OUT "\n";			# End of type
> +    }
> +    close OUT;
> +    
> +    return 1;
> +}
> +
> +#
> +# We have two kinds of reference. An 'op' which has an ASN.1 tag
> +# and a plain array reference (AR). OPs may have an AR references as their
> +# cCHILD parameter and ARs contain OPs.
> +# Since we label each reference, the order we write out in does not matter.
> +#
> +sub _write_op_tree {
> +    my $fh = shift;
> +    my $base = shift;
> +    my $seen = shift;
> +    
> +    my @ars = ( $base ); 	# List of array refs to write
> +    my @ops;			# List of ops to write	
> +    while( @ars || @ops) {
> +	if( @ars ) {
> +	    my $array = shift @ars;
> +	    next if $seen->{$array};  	# Already written, so skip
> +	    _write_ar( $fh, $array )		# Do the output
> +		or return undef;
> +	    $seen->{$array}++;		# Remember
> +	    push @ops, @$array;		# And remember the contents
> +	}
> +	if( @ops ) {
> +	    my $op = shift @ops;
> +	    next if $seen->{$op};
> +	    _write_op( $fh, $op )
> +		or return undef;
> +	    $seen->{$op}++;	    
> +	    if( ref $op->[cCHILD] eq "ARRAY" ) {
> +		push @ars, $op->[cCHILD];
> +	    }		
> +	}
> +    }
> +
> +    return 1;
> +}
> +
> +sub _write_ar {
> +    my $fh = shift;
> +    my $array = shift;
> +    
> +    my $name = _ref_to_name( $array );
> +    print $fh $name, "[";
> +    print $fh join( ",", map { _ref_to_name( $_ ) } @$array );
> +    print $fh "]\n";
> +
> +    return 1;
> +}
> +
> +    
> +sub _write_op {
> +    my $fh = shift;
> +    my $op = shift;
> +    
> +#   cTAG cTYPE cVAR cLOOP cOPT cCHILD
> +
> +    my $name = _ref_to_name( $op );
> +    print $fh $name, ":";
> +    my @line;
> +    push @line, defined( $op->[cTAG] )
> +	? ($op->[cTAG] eq '')
> +	    ? ''
> +	    : ord $op->[cTAG]
> +       	: "_";
> +    push @line, $op->[cTYPE];
> +    push @line, defined( $op->[cVAR] ) ? $op->[cVAR] : "_";
> +    push @line, defined( $op->[cLOOP] ) ? $op->[cLOOP] : "_";
> +    push @line, defined( $op->[cOPT] ) ? $op->[cOPT] : "_";
> +
> +    if( ref $op->[cCHILD] eq "ARRAY" ) {
> +	push @line, _ref_to_name( $op->[cCHILD] );
> +    }
> +    else {
> +	push @line, "_";
> +    }
> +    print $fh join( ",", @line ), "\n";
> +    
> +    return 1;
> +}
> +
> +# We could use nice names here. At the moment, just use address. This
> +# is techically naughty since we assume something about their structure.
> +# A cleaner way would be to remember which we have seen and assign unique
> +# ids.
> +sub _ref_to_name {
> +    my $name = shift;
> +    return "_" unless defined $name;
> +    $name =~ s/^.*\(//;
> +    $name =~ s/\).*$//;
> +    return $name;
> +}
> +
> +#
> +# Read in the output of a 'save'. Here we overwrite the 'tree' and the
> +# 'script' in $self, just as if prepare had been called. Could probably
> +# share a few lines with ->prepare here and/or add some automagic to the
> +# args its args to take a saved file instead.
> +#
> +sub load {
> +    my $self = shift;
> +    my $file = shift;
> +
> +# Data::Dumper version    
> +#   my $asn;
> +#   require $file or die( "Can't load file : $!" );
> +#   $self = $asn;
> +#   return 1;
> +    
> +    my $tree = {};	# This is the structure we are building
> +    my %refs;		# And here we map ID -> array reference
> +
> +    open( IN, "< $file" ) or die( "Unable to open file [$file] : $!" );
> +
> +    my $at_start = 1;
> +    my $line;
> +    while( $line = <IN> ) {
> +	chomp $line;
> +
> +	unless( $line ) {
> +	    $at_start = 1;
> +	    next;
> +	}
> +
> +	if( $at_start ) {
> +	    my( $name, $id ) = split( /:/, $line, 2 );
> +	    die( "Invalid record start line [$line]" ) unless $name && $id;
> +	    $tree->{$name} = _id2ref( $id, \%refs );
> +	    $at_start = 0;
> +	    next;
> +	}
> +
> +	my( $id, $line ) = split( /[:[]/, $line, 2 );
> +	die( "Invalid input line [$line]" ) unless $id && $line;
> +
> +	# Get or create + store ref for this ID
> +	my $ref = _id2ref( $id, \%refs );
> +	
> +	if( $line =~ /]$/ ) {
> +	    # This is an array of IDs. Store in @$ref.
> +	    # Create them if neccesary.
> +	    $line =~ s/\]$//;
> +	    my @ids = split( /,/, $line );
> +	    foreach my $child_id ( @ids ) {
> +		die( "Invalid id [$line]" ) unless $child_id;
> +		push @$ref, _id2ref( $child_id, \%refs );
> +	    }
> +	}
> +	else {
> +	    # This is a tag definition - cTAG cTYPE cVAR cLOOP cOPT cCHILD
> +#	    $line =~ s/^.//;
> +	    
> +	    my @bits = split( /,/, $line );
> +	    my $tag = shift @bits;
> +	    push @$ref, ($tag eq "_") ? undef
> +		: ($tag eq '') ? ''
> +		    : chr $tag;
> +	    my $val;
> +	    while( $val = shift @bits ) {
> +		push @$ref, ($val eq "_") ? undef : $val;
> +	    }
> +	    #
> +	    # If last val was an id. Map it to a ref.
> +	    #
> +	    $ref->[cCHILD] = _id2ref( $ref->[cCHILD], \%refs )
> +		if( defined $ref->[cCHILD] );
> +	}
> +    }
> +    close IN;
> +
> +    $self->{tree} = $tree;
> +    $self->{script} = (values %$tree)[0];
> +    
> +    return 1;
> +}
> +
> +sub _id2ref {
> +    my $id = shift;
> +    my $refs = shift;
> +
> +    return ( $refs->{$id} ||= [] );
>  }
>  
>  # In XS the will convert the tree between perl and C structs

[Fwd] Perl and Net::LDAP question...

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

----- Forwarded message from Heggtveit Ketil Olav <Ket...@Dn...> -----

Date: Mon, 21 Aug 2000 13:55:31 +0200 (MET DST)
From: Heggtveit Ketil Olav <Ket...@Dn...>
To: gb...@po...
Subject: Perl and Net::LDAP question...

Hi,
I am trying to figure out how to use Net::LDAP and the reference 
I do have a ldap-server which gives me and referral to another ldap-server
(where my mail attribute is stored), and I want my perl-search program to
chase the referal to the second ldap-server. 
Do you have any excample code on the use of Net::LDAP package ?
Regards

Ketil Heggtveit
Den norske Bank


----- End forwarded message -----

Re: utf8

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

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

Re: ldap urls

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

At 08:25 AM 8/23/00 -0500, Mark Wilcox wrote:
>Kurt Z might pop in, but you'll likey have better luck with this question
>by asking on the openldap-server list.

I'll pop in just long enough to say:
        http://www.openldap.org/lists/

Please redirect questions to the most appropriate list.
For OpenLDAP software questions, that's <ope...@op...>.
You must be subscribed to post.

Kurt