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: Voglmaier, R. E. <rv...@Gl...> - 2003-01-28 08:52:50
|
Graham, I agree with Paul, a cook-book of how to use Net::LDAP and comments about the internals would be great. Your package contains a number of objects, interdepending from each other. To have a schema of the interdepencies would help very much of who's beginning work with your package. btw compliments for the design !!!!!!!!!!!!! > Examples are great, though please be sure to include at least one or > two chapters for the gearheads who want to know the nasty details of > what's going on in there. (Not that we couldn't just read the > code.....) > > > We would like to fill these chapters with the most relevant topics > > we can, so we thought we would ask the largest, most inteligent > > resource we have, which means we won't be asking here :) Er no > > seriously, we would be glad to hear from anyone what areas of LDAP > > would be the most useful to cover. > > I'd vote for a step-by-step example chain that shows how to *create* an > entire directory, from building a root DN up. If that's not an option, > references would be good, but I *hate* having to go through iPlanet's > GUI for so much. I'd rather edit the core LDIF's by hand, lol.... > [Voglmaier, Reinhard Erich] I am finishing a book about LDAP in this moment. The goal of this book is to help the beginner to make the first steps in LDAP land. There's a chapter that does exactly this, but ..... I am using the command line tools since I assume that they are available everywhere. > (Most people probably don't mind it so much, but I *really* prefer to > stay away from proprietary pieces of any puzzle as much as I can. We > just migrated to iPlanet by company mandate, which I don't expect to > last any longerthan any of our other company "standards". I want to > keep my options as portable as possible for the next nasty > migration....) > [Voglmaier, Reinhard Erich] iPlanet is not the worst thing that could happen to you, its very similar in design with OpenLDAP that IMHO is a very good implementation inasmuch it is very close standard oriented. > Also, LDAP is handy for a lot of things besides the obvious uses it > gets shoehorned into. How about some examples of how to use Net::LDAP > to build custom objects and attributes? Or is that out of the intended > scope? [Voglmaier, Reinhard Erich] Be careful about custom objects and attributes, rather look if what you need is just defined by any standard. It comes sooner or later the moment you will want to integrate your application with a commercial product or with another application. If you try to follow standard you will not have hard problems, if not, who kwnows ............... > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com |
|
From: Abhishek K. <abh...@wi...> - 2003-01-28 06:42:13
|
Hello, Is there any module for MS Active directory ? LDAP was being used in one of the applications here but want to move it to active directory authentication... any help towards this will be appreciated. abhi |
|
From: David B. <d.b...@ma...> - 2003-01-28 00:45:10
|
Personally, I'd definitely like to see a section in the book dedicated to
cross-platform account management/creation etc. Ie: how to
create/delete/update/disable account/s and groups etc stored in the
following LDAP server types...and their differences etc.:
1) Novell E-Directory
2) MS-Active Directory
3) OpenLDAP
4) Sun One/iPlanet LDAP
5) ...others...
what do others want to see in this book? ;-)
--------------------------------------------------------------------
David Bussenschutt Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
RedHat Certified Engineer.
Member of Systems Administrators Guild of Australia.
Location: Griffith University. Information Technology Services
Brisbane Qld. Aust. (Willett Centre rm0.36) Ph: (07)38757079
--------------------------------------------------------------------
Graham Barr <gb...@po...>
Sent by: per...@li...
28/01/2003 05:35 AM
To: LDAP Mailing List <per...@li...>
cc:
Subject: Re: perl-ldap book
PS: People who have replied to any list post of mine will know this
already,
but please reply to the list, not to me personally.
Thanks,
Graham.
On Mon, Jan 27, 2003 at 06:36:17PM +0000, Graham Barr wrote:
> Many will be please to know that work has finally started on a book
> for Net::LDAP. The book is being authored by myself and Robbie
> Allen.
>
> Details are still in the early stages. However one section of the
> book, 3 chapters, are being done in the form of a cookbook. We are
> currently planning about 10 example per chapter.
>
> We would like to fill these chapters with the most relevant topics
> we can, so we thought we would ask the largest, most inteligent
> resource we have, which means we won't be asking here :) Er no
> seriously, we would be glad to hear from anyone what areas of LDAP
> would be the most useful to cover.
>
> Graham.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
|
|
From: Clif H. <cl...@go...> - 2003-01-27 23:13:57
|
On Mon, Jan 27, 2003 at 10:51:23PM +0000, Graham Barr wrote: > Several people have made reference to ldapi:// on this list recently. > > Can anyone point me at a definition so I can write a URI class to handle > it. > > Graham. > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com Graham, I do not think there is a formal definition. At least I have not seen one, maybe Kurt at openldap may know of one. Last I heard this was still an experimental. There was one individual on the list that said he had converted LDAPS to handle LDAPI. Regards, Clif Harden INTERNET: c-h...@ti... Texas Instruments Directory Services 6500 Chase Oaks Blvd, M/S 8401 Plano, TX 75023 Voice: 214-567-0855 |
|
From: Graham B. <gb...@po...> - 2003-01-27 22:52:37
|
Several people have made reference to ldapi:// on this list recently. Can anyone point me at a definition so I can write a URI class to handle it. Graham. |
|
From: Jim H. <ha...@us...> - 2003-01-27 21:29:22
|
I would like to see it include server-brand specific gotchas such as anonymous binds in Active Directory, password changing in eDirctory, etc. Related to that, I would like to see discussion of how to keep one's code as vendor neutral as possible. Perhaps that can all be rolled into one chapter. --Jim Harle |
|
From: Paul <yd...@ya...> - 2003-01-27 21:13:31
|
--- Graham Barr <gb...@po...> wrote: > PS: People who have replied to any list post of mine will know this > already, but please reply to the list, not to me personally. > Thanks, > Graham. oops -- sent my response without ever even looking.... I assumed the Reply-To: *was* the list. Just goes to show -- look before you leap. Sorry, all. :) --- Graham Barr <gb...@po...> wrote: > Many will be please to know that work has finally started on a book > for Net::LDAP. The book is being authored by myself and Robbie > Allen. yayy! Put me on the purchase list. Can I reserve an early copy? :) > Details are still in the early stages. However one section of the > book, 3 chapters, are being done in the form of a cookbook. We are > currently planning about 10 example per chapter. Examples are great, though please be sure to include at least one or two chapters for the gearheads who want to know the nasty details of what's going on in there. (Not that we couldn't just read the code.....) > We would like to fill these chapters with the most relevant topics > we can, so we thought we would ask the largest, most inteligent > resource we have, which means we won't be asking here :) Er no > seriously, we would be glad to hear from anyone what areas of LDAP > would be the most useful to cover. I'd vote for a step-by-step example chain that shows how to *create* an entire directory, from building a root DN up. If that's not an option, references would be good, but I *hate* having to go through iPlanet's GUI for so much. I'd rather edit the core LDIF's by hand, lol.... (Most people probably don't mind it so much, but I *really* prefer to stay away from proprietary pieces of any puzzle as much as I can. We just migrated to iPlanet by company mandate, which I don't expect to last any longerthan any of our other company "standards". I want to keep my options as portable as possible for the next nasty migration....) Also, LDAP is handy for a lot of things besides the obvious uses it gets shoehorned into. How about some examples of how to use Net::LDAP to build custom objects and attributes? Or is that out of the intended scope? __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Graham B. <gb...@po...> - 2003-01-27 19:37:10
|
PS: People who have replied to any list post of mine will know this already, but please reply to the list, not to me personally. Thanks, Graham. On Mon, Jan 27, 2003 at 06:36:17PM +0000, Graham Barr wrote: > Many will be please to know that work has finally started on a book > for Net::LDAP. The book is being authored by myself and Robbie > Allen. > > Details are still in the early stages. However one section of the > book, 3 chapters, are being done in the form of a cookbook. We are > currently planning about 10 example per chapter. > > We would like to fill these chapters with the most relevant topics > we can, so we thought we would ask the largest, most inteligent > resource we have, which means we won't be asking here :) Er no > seriously, we would be glad to hear from anyone what areas of LDAP > would be the most useful to cover. > > Graham. |
|
From: Justin <da...@io...> - 2003-01-27 18:47:33
|
I think Markus makes a great point. Whichever language the developer is best at is probably the best one to use. I'll just throw in my two cents since I haven't seen anyone yet address Java's LDAP capabilities. Java uses the JNDI (Java Naming and Directory Interface) to access LDAP directories. It actually covers more than just LDAP, and can be used for DNS and a few other data types that fit into the directory model. Java is typically very well documented in my experience and Sun has a nice set of information here: http://java.sun.com/products/jndi/ I've used both the Java and Perl implementations and found them both to be usable and not all that different. Again, it's really a choice of language. Best of luck, Justin > as many others have already pointed out, there is no definite answer. > > but there is one experience which i would like to share with you.... > > NEVER EVER "force" a developer to do something with a tool he doesn't > like. > |
|
From: Graham B. <gb...@po...> - 2003-01-27 18:37:28
|
Many will be please to know that work has finally started on a book for Net::LDAP. The book is being authored by myself and Robbie Allen. Details are still in the early stages. However one section of the book, 3 chapters, are being done in the form of a cookbook. We are currently planning about 10 example per chapter. We would like to fill these chapters with the most relevant topics we can, so we thought we would ask the largest, most inteligent resource we have, which means we won't be asking here :) Er no seriously, we would be glad to hear from anyone what areas of LDAP would be the most useful to cover. Graham. |
|
From: Graham B. <gb...@po...> - 2003-01-27 18:32:08
|
0.2701 has just been released to SourceForge and CPAN There is a 01 release because I messed up the 0.27 release by not updating my CVS client to get all the contrib changes. There are no changes to the modules between the two released. Graham. |
|
From: Graham B. <gb...@po...> - 2003-01-27 14:29:59
|
On Sun, Jan 12, 2003 at 03:13:27PM -0600, Terry Davis wrote:
> Hello,
>
> I am apparently having difficulty with my design.
Sorry for the late replay.
my $results = displayResults("$lines");
Your problem is that you have stringified the search object. Try removing
the "'s
Graham.
>
> Can't locate object method "as_struct" via package "Net::LDAP::Search=HASH
> (0x83807cc)" (perhaps you forgot to load "Net::LDAP::Search=HASH(0x83807cc)"?)
>
> This is where the error occurs:
> sub displayResults
> {
> my $result = shift;
> my $href = $result->as_struct;
> my @arrayOfDNs = keys %$href ; # use DN hashes
> foreach (@arrayOfDNs) {
> print $_,"\n";
> my $valref = $$href{$_};
> my @arrayOfAttrs = sort keys %$valref; #use Attr hashes
> my $attrName;
> foreach $attrName (@arrayOfAttrs) {
> next if ( $attrName =~ /;binary$/ );
> my $attrVal = @$valref{$attrName} ;
> print "\t $attrName: @$attrVal \n";
> }
> }
> }
>
>
> I ask for this subroutine here:
>
> sub read_user
> {
> my $user = shift;
> my @attrs = ();
> my $lines = ldapsearch($slaveLDAP,"(&(objectclass=posixAccount)
> (uid=$user))",\@attrs );
> chomp $lines;
> if ($lines eq '') {
> return undef;
> }
>
> my $results = displayResults("$lines");
>
> return $results;
> }
>
>
> which is called from:
> my $lines = read_user($user);
> if (!defined($lines)) {
> print "$0: user $user doesn't exist\n";
> exit (1);
> }
>
> print $lines;
>
>
> I worked this email backwards hoping that would help clear it up. I of course
> do this in one of my config files:
> use Net::LDAP qw(:all);
>
>
> Any ideas?
>
> --
> Terry Davis
> http://approbation.org/
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
|
|
From: Graham B. <gb...@po...> - 2003-01-27 14:28:36
|
Thanks.
I am very much coming around to the idea of passing URIs instead of just hostnames,
defaulting to ldap: if no scheme is passed. But to do this properly I think we
need to merge LDAPS and LDAPI into LDAP.pm. Whith the approch below, while it
does allow for new schemes to be added, it does now allow for Net::LDAP
to be subclassed.
Anyway, I am releasing 0.27 today and we can look into all of this after that.
Graham.
On Sun, Jan 26, 2003 at 08:24:27PM +0100, Ziya Suzen wrote:
> This one uses LDAPI.pm and LDAPS.pm. Attached a patch file, which
> includes a couple of test cases as well as the diff below. You will
> need to apply LDAPI patch separately to test LDAPI URIs as well as
> LDAPS. Unfortunately (Although URL test written for LDAPS as well) I
> couldn't run it for LDAPS. Only with LDAP and LDAPI.
>
> Cheers,
>
> Ziya.
>
> --- ldap/lib/Net/LDAP.pm 2003-01-26 16:56:06.730623000 +0000
> +++ ldap_patch.d/lib/Net/LDAP.pm 2003-01-26 16:55:52.100623000 +0000
> @@ -97,10 +97,30 @@
> my $obj = bless {}, $type;
>
> foreach my $h (ref($host) ? @$host : ($host)) {
> +
> + my $save_port = $arg->{port};
> +
> + # Check for URL
> + if ($h =~m!^([a-z]+)://([/\w\.\-\@\#\~]+?)(?::(\d+))?/?$!i) {
> + my $uri = uc($1);
> + my $new_type = "Net::$uri";
> + $h = $2;
> + $arg->{port} = $3 if $3;
> + eval "require $new_type" and bless $obj, $new_type and $obj->isa('Net::LDAP')
> + or require Carp and Carp::croak("Cannot handle $uri URIs");
> +
> + $obj->can('_connect')
> + or require Carp and Carp::croak("$new_type does not implement Net::LDAP interface");
> + }
> +
> if ($obj->_connect($h, $arg)) {
> $obj->{net_ldap_host} = $h;
> last;
> }
> +
> + # Restore to defaults
> + $arg->{port} = $save_port;
> + bless $obj, $type;
> }
>
> return undef unless $obj->{net_ldap_socket};
>
>
> On 2003-01-16 19:14:46 +0000, Graham Barr wrote:
> > On Sat, Jan 11, 2003 at 04:48:18PM +0100, Peter Marschall wrote:
> > > Hi,
> > >
> > > On Thursday 09 January 2003 14:43, Ziya Suzen wrote:
> > > > I was running some tests on my sand-box station and because my OpenLDAP
> > > > is compiled with TCP wrappers I cannot connect to it. Sure the
> > > > solution can be adding slapd to hosts.allow but I thought a better
> > > > solution could be using Unix sockets. And I came up with the following
> > > > patch to LDAP.pm. What do you think?
> > > >
> > > > BTW, I have only tested ldapi:// syntax. I wanted to get your opinions
> > > > before going any further.
> >
> > I think your ldaps:// implementation is wrong. It needs todo what Net::LDAPS
> > is currently doing.
> >
> > I also think the connect dispatch should look something like
> >
> > if ($host_or_url =~m!^([a-z]+)://([/\w\.\-\@\#\~]+?)(?::(\d+))?/?$!i) {
> > my $connect = $obj->can("_connect_$1") or croak("Cannot handle $1 URIs");
> > $host = $2;
> > local $arg->{port} = $3 if $3;
> >
> > $obj->$connect($host, $arg);
> > }
> >
> > The foreach to allow the user to pass multiple hosts should be around this and
> > the old code.
> >
> > > there has been a similar patch on the list a few weeks ago.
> > > It added a Net::LDAPI.pm file for the ldapi:// connection.
> >
> > That was going to be my reply too :)
> >
> > However after thinking for a bit, I think I like the option to pass a URI to
> > Net::LDAP and have it DWIM. Being able to specify different protocols when
> > giving a list of hosts to try to connect to might be useful.
> >
> > Graham.
> diff -Nur -xCVS ldap/MANIFEST ldap_patch.d/MANIFEST
> --- ldap/MANIFEST 2003-01-26 16:56:03.460624000 +0000
> +++ ldap_patch.d/MANIFEST 2003-01-26 16:55:48.190624000 +0000
> @@ -83,6 +83,7 @@
> lib/Net/LDAP/Security.pod
> lib/Net/LDAP/Util.pm
> lib/Net/LDAPS.pm
> +lib/Net/LDAPI.pm
> mkmanf
> t/00ldif-entry.t
> t/01canon_dn.t
> @@ -93,6 +94,8 @@
> t/53schema.t
> t/54dse.t
> t/55ssl.t
> +t/56ipc.t
> +t/57url.t
> t/70sortctrl.t
> t/common.pl
> test.cfg
> diff -Nur -xCVS ldap/lib/Net/LDAP.pm ldap_patch.d/lib/Net/LDAP.pm
> --- ldap/lib/Net/LDAP.pm 2003-01-26 16:56:06.730623000 +0000
> +++ ldap_patch.d/lib/Net/LDAP.pm 2003-01-26 16:55:52.100623000 +0000
> @@ -97,10 +97,30 @@
> my $obj = bless {}, $type;
>
> foreach my $h (ref($host) ? @$host : ($host)) {
> +
> + my $save_port = $arg->{port};
> +
> + # Check for URL
> + if ($h =~m!^([a-z]+)://([/\w\.\-\@\#\~]+?)(?::(\d+))?/?$!i) {
> + my $uri = uc($1);
> + my $new_type = "Net::$uri";
> + $h = $2;
> + $arg->{port} = $3 if $3;
> + eval "require $new_type" and bless $obj, $new_type and $obj->isa('Net::LDAP')
> + or require Carp and Carp::croak("Cannot handle $uri URIs");
> +
> + $obj->can('_connect')
> + or require Carp and Carp::croak("$new_type does not implement Net::LDAP interface");
> + }
> +
> if ($obj->_connect($h, $arg)) {
> $obj->{net_ldap_host} = $h;
> last;
> }
> +
> + # Restore to defaults
> + $arg->{port} = $save_port;
> + bless $obj, $type;
> }
>
> return undef unless $obj->{net_ldap_socket};
> diff -Nur -xCVS ldap/my.cfg ldap_patch.d/my.cfg
> --- ldap/my.cfg 1970-01-01 00:00:00.000000000 +0000
> +++ ldap_patch.d/my.cfg 2003-01-26 16:55:52.720623000 +0000
> @@ -0,0 +1,25 @@
> +# Currently test that require a server are only implemented to work
> +# with slapd from the OpenLDAP project. Edit this file so the tests
> +# can find the executable and know what type of server it is
> +
> +# Set this to the path to where you have slapd
> +$SERVER_EXE = "/usr/local/ldap-2.0/libexec/slapd";
> +
> +# This should be one of
> +# openldap1
> +# openldap2[+ssl][+ipc][+sasl]
> +$SERVER_TYPE = "openldap2+ipc";
> +
> +# $HOST = "localhost";
> +
> +$EXTERNAL_TESTS = 0;
> +
> +# %sortctrl = (
> +# host => '<ldap server hostname>',
> +# base => '<search base>',
> +# filter => '<search filter>',
> +# order => '<sort attribute name>',
> +# );
> +
> +1;
> +
> diff -Nur -xCVS ldap/t/56ipc.t ldap_patch.d/t/56ipc.t
> --- ldap/t/56ipc.t 1970-01-01 00:00:00.000000000 +0000
> +++ ldap_patch.d/t/56ipc.t 2003-01-26 16:55:52.670622000 +0000
> @@ -0,0 +1,31 @@
> +#!perl
> +
> +BEGIN {
> + require "t/common.pl";
> + start_server(ldap_version());
> +}
> +
> +print "1..12\n";
> +
> +$ldap = client();
> +ok($ldap, "client");
> +
> +$mesg = $ldap->bind($MANAGERDN, password => $PASSWD, ldap_version());
> +
> +ok(!$mesg->code, "bind: " . $mesg->code . ": " . $mesg->error);
> +
> +ok(ldif_populate($ldap, "data/50-in.ldif"), "data/50-in.ldif");
> +
> +$mesg = $ldap->search(base => $BASEDN, filter => 'objectclass=*');
> +ok(!$mesg->code, "search: " . $mesg->code . ": " . $mesg->error);
> +
> +compare_ldif("50",$mesg,$mesg->sorted);
> +
> +$ldap = client(ipc => 1);
> +ok($ldap, "ipc client");
> +
> +$mesg = $ldap->search(base => $BASEDN, filter => 'objectclass=*');
> +ok(!$mesg->code, "search: " . $mesg->code . ": " . $mesg->error);
> +
> +compare_ldif("50",$mesg,$mesg->sorted);
> +
> diff -Nur -xCVS ldap/t/57url.t ldap_patch.d/t/57url.t
> --- ldap/t/57url.t 1970-01-01 00:00:00.000000000 +0000
> +++ ldap_patch.d/t/57url.t 2003-01-26 16:55:52.610624000 +0000
> @@ -0,0 +1,35 @@
> +#!perl
> +
> +BEGIN {
> + require "t/common.pl";
> + start_server(ldap_version(), ssl => $SSL_PORT);
> +}
> +
> +my @urls = split/ /, $URL;
> +my $num_tests = @urls * 5 + 7;
> +
> +print "1..$num_tests\n";
> +
> +$ldap = client();
> +ok($ldap, "client");
> +
> +$mesg = $ldap->bind($MANAGERDN, password => $PASSWD, ldap_version());
> +
> +ok(!$mesg->code, "bind: " . $mesg->code . ": " . $mesg->error);
> +
> +ok(ldif_populate($ldap, "data/50-in.ldif"), "data/50-in.ldif");
> +
> +$mesg = $ldap->search(base => $BASEDN, filter => 'objectclass=*');
> +ok(!$mesg->code, "search: " . $mesg->code . ": " . $mesg->error);
> +
> +compare_ldif("50",$mesg,$mesg->sorted);
> +
> +for my $url (@urls) {
> + $ldap = client(url => $url);
> + ok($ldap, "$url client");
> +
> + $mesg = $ldap->search(base => $BASEDN, filter => 'objectclass=*');
> + ok(!$mesg->code, "search: " . $mesg->code . ": " . $mesg->error);
> +
> + compare_ldif("50",$mesg,$mesg->sorted);
> +}
> diff -Nur -xCVS ldap/t/common.pl ldap_patch.d/t/common.pl
> --- ldap/t/common.pl 2003-01-26 16:56:07.160624000 +0000
> +++ ldap_patch.d/t/common.pl 2003-01-26 16:55:52.590624000 +0000
> @@ -32,10 +32,13 @@
> }
> elsif ($SERVER_TYPE eq 'openldap2') {
> $SSL_PORT = 9010 if grep { $_ eq 'ssl' } @server_opts;
> + $IPC_SOCK = '_s' if grep { $_ eq 'ipc' } @server_opts;
> + $SASL = 1 if grep { $_ eq 'sasl' } @server_opts;
> $CONF_IN = "./data/slapd2-conf.in";
> - my $url = "ldap://${HOST}:$PORT/";
> - $url .= " ldaps://${HOST}:$SSL_PORT/" if $SSL_PORT;
> - @LDAPD = ($SERVER_EXE, '-f',$CONF,'-h',$url,qw(-d 1));
> + $URL = "ldap://${HOST}:$PORT/";
> + $URL .= " ldaps://${HOST}:$SSL_PORT/" if $SSL_PORT;
> + $URL .= " ldapi://$IPC_SOCK/" if $IPC_SOCK;
> + @LDAPD = ($SERVER_EXE, '-f',$CONF,'-h',$URL,qw(-d 1));
> $LDAP_VERSION = 3;
> }
>
> @@ -69,6 +72,7 @@
> while(<CONFI>) {
> s/\$(\w+)/${$1}/g;
> s/^TLS/#TLS/ unless $SSL_PORT;
> + s/^(sasl.*)/#\1/ unless $SASL;
> print CONFO;
> }
> close(CONFI);
> @@ -118,6 +122,21 @@
> sleep 1;
> }
> }
> + elsif ($arg{ipc}) {
> + require Net::LDAPI;
> + until($ldap = Net::LDAPI->new($IPC_SOCK, ldap_version())) {
> + die "ldapi://$IPC_SOCK/ $@" if ++$count > 10;
> + sleep 1;
> + }
> + }
> + elsif ($arg{url}) {
> + print "Trying $arg{url}\n";
> + until($ldap = Net::LDAP->new($arg{url}, ldap_version())) {
> + die "$arg{url} $@" if ++$count > 10;
> + print "$arg{url} failed.\n";
> + sleep 1;
> + }
> + }
> else {
> until($ldap = Net::LDAP->new($HOST, port => $PORT)) {
> die "ldap://$HOST:$PORT/ $@" if ++$count > 10;
> @@ -181,6 +200,11 @@
> $ok;
> }
>
> +sub ldap_version {
> + return version => 3 if $SSL_PORT;
> + return ();
> +}
> +
> my $number = 0;
> sub ok {
> my ($condition, $name) = @_;
> diff -Nur -xCVS ldap/test.cfg ldap_patch.d/test.cfg
> --- ldap/test.cfg 2003-01-26 16:56:03.530624000 +0000
> +++ ldap_patch.d/test.cfg 2003-01-26 16:55:48.330622000 +0000
> @@ -7,8 +7,7 @@
>
> # This should be one of
> # openldap1
> -# openldap2
> -# openldap2+ssl
> +# openldap2[+ssl][+ipc][+sasl]
> $SERVER_TYPE = "openldap2";
>
> # $HOST = "localhost";
|
|
From: Ziya S. <zi...@ri...> - 2003-01-26 19:24:39
|
This one uses LDAPI.pm and LDAPS.pm. Attached a patch file, which
includes a couple of test cases as well as the diff below. You will
need to apply LDAPI patch separately to test LDAPI URIs as well as
LDAPS. Unfortunately (Although URL test written for LDAPS as well) I
couldn't run it for LDAPS. Only with LDAP and LDAPI.
Cheers,
Ziya.
--- ldap/lib/Net/LDAP.pm 2003-01-26 16:56:06.730623000 +0000
+++ ldap_patch.d/lib/Net/LDAP.pm 2003-01-26 16:55:52.100623000 +0000
@@ -97,10 +97,30 @@
my $obj = bless {}, $type;
foreach my $h (ref($host) ? @$host : ($host)) {
+
+ my $save_port = $arg->{port};
+
+ # Check for URL
+ if ($h =~m!^([a-z]+)://([/\w\.\-\@\#\~]+?)(?::(\d+))?/?$!i) {
+ my $uri = uc($1);
+ my $new_type = "Net::$uri";
+ $h = $2;
+ $arg->{port} = $3 if $3;
+ eval "require $new_type" and bless $obj, $new_type and $obj->isa('Net::LDAP')
+ or require Carp and Carp::croak("Cannot handle $uri URIs");
+
+ $obj->can('_connect')
+ or require Carp and Carp::croak("$new_type does not implement Net::LDAP interface");
+ }
+
if ($obj->_connect($h, $arg)) {
$obj->{net_ldap_host} = $h;
last;
}
+
+ # Restore to defaults
+ $arg->{port} = $save_port;
+ bless $obj, $type;
}
return undef unless $obj->{net_ldap_socket};
On 2003-01-16 19:14:46 +0000, Graham Barr wrote:
> On Sat, Jan 11, 2003 at 04:48:18PM +0100, Peter Marschall wrote:
> > Hi,
> >
> > On Thursday 09 January 2003 14:43, Ziya Suzen wrote:
> > > I was running some tests on my sand-box station and because my OpenLDAP
> > > is compiled with TCP wrappers I cannot connect to it. Sure the
> > > solution can be adding slapd to hosts.allow but I thought a better
> > > solution could be using Unix sockets. And I came up with the following
> > > patch to LDAP.pm. What do you think?
> > >
> > > BTW, I have only tested ldapi:// syntax. I wanted to get your opinions
> > > before going any further.
>
> I think your ldaps:// implementation is wrong. It needs todo what Net::LDAPS
> is currently doing.
>
> I also think the connect dispatch should look something like
>
> if ($host_or_url =~m!^([a-z]+)://([/\w\.\-\@\#\~]+?)(?::(\d+))?/?$!i) {
> my $connect = $obj->can("_connect_$1") or croak("Cannot handle $1 URIs");
> $host = $2;
> local $arg->{port} = $3 if $3;
>
> $obj->$connect($host, $arg);
> }
>
> The foreach to allow the user to pass multiple hosts should be around this and
> the old code.
>
> > there has been a similar patch on the list a few weeks ago.
> > It added a Net::LDAPI.pm file for the ldapi:// connection.
>
> That was going to be my reply too :)
>
> However after thinking for a bit, I think I like the option to pass a URI to
> Net::LDAP and have it DWIM. Being able to specify different protocols when
> giving a list of hosts to try to connect to might be useful.
>
> Graham.
|
|
From: Markus W. <mw...@fa...> - 2003-01-24 22:46:19
|
as many others have already pointed out, there is no definite answer. but there is one experience which i would like to share with you.... NEVER EVER "force" a developer to do something with a tool he doesn't like. if you have good expierience with that contractor and the suggested solution by that contractor doesn't break up the complete architecure you already have, let the contractor take what he wants. if you want/need it in another way, search for another contractor. if you ask you java prefering contractor to do it in perl, he will most likley do it (for the money), but the code you will get will most propably not as good as the java implementation by the same contractor. I assume that the java solution from a java programmer will have about the same quality as the perl solution from a perl programmer. but if you cross this out, you might become really ugly code.... both technologies have great capabilies to build web applications. i believe both technologies have great capabilities to access LDAP directories (perl has, but I have never used the java ones). I really believe the programming language itself does not lead to a qualified decision (as far as i can evaluate this from your info), so maybe you should focus on the "meta" criteria like how well will it fit into the existing architecture, who will it maintain and so on... -markus On Fri, 24 Jan 2003, Betsy Hasman wrote: > If this isn't appropriate for this list, I apologize in advance. > We are building web-based tools to maintain our LDAP Directory and folks > upstairs initially decided Perl was the tool to use. > I have been dutifully making my way through the otter, etc so that after > they are built, by an outside consultant, I can maintain the code. > Our consultant, who is primarily a java developer, says that using java > would be better, quicker to develop, etc. > "Why do you want to use Perl?" he's asked and he almost has my boss > convinced that java is the way to go. > Any feedback one way or the other? Can I give a compelling argument for > Perl, or shall I go by "Java for Dummies"? > Thanks, > betsy > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > |
|
From: Philip L. <pl...@ar...> - 2003-01-24 22:25:38
|
Betsy: When I started with LDAP two years ago I knew almost nothing about Perl or Java (or LDAP for that matter). Our consultants on the Directory project did all their coding in Perl, and first introduced me to Net::LDAP. At the same time, our in house developers built a number of new, and recoded a number of existing, line of business applications to make them LDAP-aware using the Netscape LDAP SDK for Java. That experience has led me to favor Perl for administrative tools. It is not only faster to develop in, but also easier to maintain. The stock CGI module can be used in combination with Net::LDAP to get web based tools off the ground in a hurry without sacrificing functionality. Modules like Unicode::Lite and Text::Unidecode can solve many issues with international characters. Perl/Tk can be used to build GUI interfaces for interactive tools that are not deployed through a web interface. The excellent resources available in documentation and lists like this are invaluable aids in successfully completing projects. In addition to administration, all of my current processes to exchange data between the Directory and other systems are written in Perl, using Net::LDAP, the Perl DBI and other modules. My own advice would be to go with Perl, but to have someone on your staff, who either knows Perl or is willing to learn, "shadow" the consultants so that you have someone in house who knows the code delivered as well as they do. Make sure that knowledge transfer is an explicit part of the engagement, and that your management enforces this provision strictly. That way you can both maintain and improve the code over time, fixing the inevitable bugs and adding functionality as needed. This is probably an option you wouldn't have if the tools are written in Java, since Java programming isn't something most system administrators have the time (or energy) to master and make part of their daily routine. Phil Lembo |
|
From: Prabhakar R. <jet...@ya...> - 2003-01-24 21:29:18
|
Hello all, I have Sun iplanet 5.1 installed in a Solaris 8 system. I'm using replcheck.pl script that came with idsrk pkg to monitor the replication between master and replicator hub and the rest of the consumers. I have the script working fine and I get the output telling me whether the replication is in sync or not as shown below. /opt/iplanet/server51/bin/slapd/admin/bin/perl replcheck.pl -w adm -b "o=example.com" 1.3.6.136:389 1.3.6.137:389 Connected to 1.3.6.136 Connected to 1.3.6.137 ------------------------- Getting replication update vector for 1.3.6.136 replica of o=sprintpcs.com => {replica 1 ldap://master-ldap2-1:389} => {replicageneration} 3e274275000000010000 Getting replication update vector for 1.3.6.137 replica of o=sprintpcs.com => {replica 1 ldap://master-ldap2-1:389} => {replicageneration} 3e274275000000010000 Servers are in synch If the servers are not in synch or synchronizing, is there any way to find out how many changes (entries) or the change numbers (versions) is the replicator hub behind? How is replicageneration number generated? Is that the replication vector? Can we compare the replicageneration number of the two systems to find out the difference? Any help would be appreciated. Thanks. --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now |
|
From: Paul <yd...@ya...> - 2003-01-24 17:58:14
|
--- Betsy Hasman <Jea...@pi...> wrote: > If this isn't appropriate for this list, I apologize in advance. > We are building web-based tools to maintain our LDAP Directory and > folks upstairs initially decided Perl was the tool to use. You should ask them why. If they decided Perl was the right tool based on poor evidence, they might need to reconsider, though I personally concur wholeheartedly with the end decision, whtever their reasoning. Personally, I find the learning curve for Perl vastly preferable. I can code quick-and-dirty tools to get a feel for an app, then prototype from them into full-blown interfaces using warnings and strict and modules and objects..... Perl has great speed, both in code time and run time, and though I might be able to write faster code in C, I can almost certainly write code faster in Perl, and my time is usually much more valuable than that of the processor. I also believe that well written Perl compares well against similar Java code. And don't forget that while dynamic code-on-the-fly is an amazingly useful abstraction tool, Perl lets me to explicit taint checking to keep my data secure.... My experience with Java is rather limited as well (a lot of people on this list are saying that -- becausemany of us have looked at both, and chosen Perl) but it's major strength have been threads, Unicode, and implicit safety. Perl can enforce safety as well with taint checking and Safe compartments, and let's you *choose* what level of control-freak-ishness is appropriate for your app. Likewise, while Perl's documentation leaves much to be desired, I have always found it *WAY* easier to fond what I want in Perl than Java. > I have been dutifully making my way through the otter, etc so that > after they are built, by an outside consultant, I can maintain the > code. Kudos. :) > Our consultant, who is primarily a java developer, says that using > java would be better, quicker to develop, etc. That's his indoctrination. Has he learned enough Perl to judge it, or is he just repeating the dogma? I'll admit that I like Java, but that I'd *SO* much rather code in Perl. I can't say that quite as quickly if I'm looking at maintaining someone else's code; Perl can be easily abused to write unmaintainable messes (and I've done it <guiltily raising hand>), and they say mainaining Java is easy. I haven't had to maintain someone else's Java (or really Perl, either), so any hard comment would be unfounded. Still, I can say that from what I know of both, I'd rather work in Perl. That said, since _NO_ code will ever be so good that it can't be improved, and since time will require additions, and since I'd so much rather write in Perl, I'd have to say I'd rather maintain Perl, as well. > "Why do you want to use Perl?" he's asked and he almost has my boss > convinced that java is the way to go. Did the boss not answer him? And did the boss not ask "Why do you think we should use Java?" The contractor will want to use what he's most familiar and comfortable with, naturally, and I don't blame him. Your company should be more concerned with who'd maintaining the code, and what *they* (you) are more familiar and comfortable with. If his answers are that Java is "better", have him cite sources, and check them out. I can cite sources that prove either side of that argument, from either camp. Take it all with a slightly cynical grain of salt, and evaluate for the long haul. But I'd go with Perl. :) > Any feedback one way or the other? Can I give a compelling argument > for Perl, or shall I go by "Java for Dummies"? > Thanks, > betsy My advice? Do some research yourself on the comparisons, and try to find arguments that support each side. Compare the arguments you find, and see which one more appropriately represents your situation. Go with that. But if Java for Dummies is an option, consider that one more good reason to use Perl. Paul __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: <ch...@po...> - 2003-01-24 17:51:00
|
Betsy, I use both Java and Perl to access/support our x.500 and native ldap systems. We use perl for just about everything, from taking HR feeds thru MQseries to doing web page development. I used to use Java for supporting MS Windows type systems for directory access, but with the SOAP perl module I now use perl for for this process too. By using the SOAP perl module with apache we now have full access to our directories thru Visual Basic, etc. It will depend on the programming task, but I would have say that perl is much faster to develop in than Java. Also speed of program execution will be faster with Perl. I use Java, and I like programming in it, but I choose to use Perl for almost all our programs. It is portable, is fast to program with, and it is not tied to, or controlled by, any vendor. Regards, Clif Harden Texas Instruments Directory Services > If this isn't appropriate for this list, I apologize in advance. > We are building web-based tools to maintain our LDAP Directory and folks > upstairs initially decided Perl was the tool to use. > I have been dutifully making my way through the otter, etc so that after > they are built, by an outside consultant, I can maintain the code. > Our consultant, who is primarily a java developer, says that using java > would be better, quicker to develop, etc. > "Why do you want to use Perl?" he's asked and he almost has my boss > convinced that java is the way to go. > Any feedback one way or the other? Can I give a compelling argument for > Perl, or shall I go by "Java for Dummies"? > Thanks, > betsy > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > > --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ |
|
From: <rg...@cu...> - 2003-01-24 16:22:01
|
Betsy, I can't speak for or against Java, except to say that some of my co-workers have 'not' found JAVA to be as easy to get working, or as easy to maintain as other languages. Could that have been because of their lack of JAVA experience?... I don't know. I can speak about the PERL argument though, as our company's primary web interface builder for our corporate Directory Services, we have selected and continue to advocate PERL because of its, portability, speed in development, and ease of maintenance. Yes,... all the buzz word you hear from everyone... so let me give you some hard details... We take our primary input for people from two major sources HR and Security. There are other secondary input groups that maintain different peices of information like e-mail or shipping information. In almost all of these case, we build the processing mechanism to handle the data as it goes into the directory. As for my web pages, we also allow each individual the flexibility of changing much of their own data in the directory, by themselves without 3rd person intervention. We could have picked C for the data feeds and JAVA or PHP for the web pages, but didn't. The LDAP and Web page look and feel code is small compared to the code needed to break apart data and check if for validity. So what am I getting at? PERL gives us the power in a language to verify, scrutinize, correct, re-arrange, etc., data that has been given to us (via a feed or web pages) so that we minimize problems and corruption of our Directory database. You'll be amazed at what people will put in as data, and if you deal with the international community, you'll need to take their view of things into perspective. So the less time you spend cleaning up your directory data, the happier your customers, your boss and you will be. I can't speak for JAVA, hopefully someone else will, but in our group PERL will have the job for a long time to come. I hope that helps. Regards Rusty TI Corporate Directory Services Team On Jan 24, 8:40am, Betsy Hasman wrote: > Subject: perl or java > If this isn't appropriate for this list, I apologize in advance. > We are building web-based tools to maintain our LDAP Directory and folks > upstairs initially decided Perl was the tool to use. > I have been dutifully making my way through the otter, etc so that after > they are built, by an outside consultant, I can maintain the code. > Our consultant, who is primarily a java developer, says that using java > would be better, quicker to develop, etc. > "Why do you want to use Perl?" he's asked and he almost has my boss > convinced that java is the way to go. > Any feedback one way or the other? Can I give a compelling argument for > Perl, or shall I go by "Java for Dummies"? > Thanks, > betsy > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com >-- End of excerpt from Betsy Hasman -- Russell Biggs (Rusty) Internet: r-...@ti... 6500 Chase Oaks Blvd, M/S 8412 Phone: (214) 567-0826 Texas Instruments Fax: (972) 575-4853 Plano Tx 75023 "Is dark outside... or are the windows painted black?" ...Directory Services Admin |
|
From: Joseph K. <jk...@do...> - 2003-01-24 15:59:28
|
Betsy, Java has a nice API called JLDAP from Novell. Perl has a nice API called Net::LDAP. Perl is a script or a CGI. Java has the ability to make a full fledged standalone GUI application. well.... using Perl/Tk you could simulate the same thing. In my opinion(being a java developer myself) perl is super easy for writting tools that quickly query data from directory services. Java is good to develop BIG tools, that you can reuse the java objects wherein defined. Java Servlets are a nice way to go as well. It appears I am inadvertantly flaundering. I have LDAP tools written both in Java and in Perl. For a non-programmer, the perl tools are easier to maintain. PS. If you havent bought a contractor as of yet keep me in mind ;-) Thanks, Joe Kezar ----- Original Message ----- From: "Betsy Hasman" <Jea...@pi...> To: <per...@li...> Sent: Friday, January 24, 2003 10:40 AM Subject: perl or java > If this isn't appropriate for this list, I apologize in advance. > We are building web-based tools to maintain our LDAP Directory and folks > upstairs initially decided Perl was the tool to use. > I have been dutifully making my way through the otter, etc so that after > they are built, by an outside consultant, I can maintain the code. > Our consultant, who is primarily a java developer, says that using java > would be better, quicker to develop, etc. > "Why do you want to use Perl?" he's asked and he almost has my boss > convinced that java is the way to go. > Any feedback one way or the other? Can I give a compelling argument for > Perl, or shall I go by "Java for Dummies"? > Thanks, > betsy > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > |
|
From: Betsy H. <Jea...@pi...> - 2003-01-24 15:40:49
|
If this isn't appropriate for this list, I apologize in advance. We are building web-based tools to maintain our LDAP Directory and folks upstairs initially decided Perl was the tool to use. I have been dutifully making my way through the otter, etc so that after they are built, by an outside consultant, I can maintain the code. Our consultant, who is primarily a java developer, says that using java would be better, quicker to develop, etc. "Why do you want to use Perl?" he's asked and he almost has my boss convinced that java is the way to go. Any feedback one way or the other? Can I give a compelling argument for Perl, or shall I go by "Java for Dummies"? Thanks, betsy |
|
From: Norbert K. <nor...@bu...> - 2003-01-24 12:42:44
|
--On Mittwoch, 22. Januar 2003 17:49 -0500 Kyle Stone
<KS...@co...> wrote:
> I'm attempting to build some ldifs and doo some inserts and I need a bit
> of help. I'm real green at perl.
>
>
>
> Here's what I'm doing..
>
> $entry = Net::LDAP::Entry->new;
> <SNIP>
>
> #Generating entries..
> $mesg = $ldap->add(dn=>"cn=$zonename,$BASEDN",
> attr=>list_attrs(\%attr));
> print "Failed to add entry:", $zonename, " ",
> $mesg->error if ($mesg->code);
>
>
> $entry->Net::LDAP::Entry::add(dn=>"cn=$zonename,$BASEDN",
> attr=>list_attrs(\%attr));
> Anyone have an idea how I can generate an ldif output correctly?
use
my $ldif = Net::LDAP::LDIF->new("-", "w");
$ldif->write_entry( $entry );
Norbert
|
|
From: Hutchins, M. <mhu...@am...> - 2003-01-23 20:10:43
|
As many as it takes.. :-) -----Original Message----- From: Paul Harwood [mailto:ha...@ny...]=20 Sent: Thursday, January 23, 2003 1:01 PM To: Graham Barr Cc: per...@li... Subject: RE: Question on filter syntax That worked. :) Jeez - how many parenthesis are needed? :) -----Original Message----- From: Graham Barr [mailto:gb...@po...]=20 Sent: Thursday, January 23, 2003 11:54 AM To: Paul Harwood Cc: per...@li... Subject: Re: Question on filter syntax On Thu, Jan 23, 2003 at 11:47:55AM -0800, Paul Harwood wrote: > I am writing a script using the following LDAP search filter: >=20 > filter =3D> "(objectclass=3DmsexchExchangeServer)", >=20 > This works fine. >=20 > I want to exclude the objectlass=3DmsexchExchangeServerPolicy. I am trying > the following with no success: >=20 > filter =3D> "(objectclass=3DmsexchExchangeServer)(!objectclass=3DmsexchExchangeServer= Pol icy)", Try filter =3D> "(&(objectclass=3DmsexchExchangeServer)(!(objectclass=3DmsexchExchangeSer= ver Policy)))", Graham. >=20 > filter =3D> > "(|(objectclass=3DmsexchExchangeServer)(!objectclass=3DmsexchExchangeServ= erP > olicy))", >=20 > =20 >=20 > =20 >=20 > Any help is appreciated. >=20 > =20 >=20 > --Paul >=20 ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See! http://www.vasoftware.com |
|
From: Paul H. <ha...@ny...> - 2003-01-23 20:00:35
|
That worked. :) Jeez - how many parenthesis are needed? :) -----Original Message----- From: Graham Barr [mailto:gb...@po...]=20 Sent: Thursday, January 23, 2003 11:54 AM To: Paul Harwood Cc: per...@li... Subject: Re: Question on filter syntax On Thu, Jan 23, 2003 at 11:47:55AM -0800, Paul Harwood wrote: > I am writing a script using the following LDAP search filter: >=20 > filter =3D> "(objectclass=3DmsexchExchangeServer)", >=20 > This works fine.=20 >=20 > I want to exclude the objectlass=3DmsexchExchangeServerPolicy. I am trying > the following with no success: >=20 > filter =3D> "(objectclass=3DmsexchExchangeServer)(!objectclass=3DmsexchExchangeServer= Pol icy)", Try filter =3D> "(&(objectclass=3DmsexchExchangeServer)(!(objectclass=3DmsexchExchangeSer= ver Policy)))", Graham. >=20 > filter =3D> > "(|(objectclass=3DmsexchExchangeServer)(!objectclass=3DmsexchExchangeServ= erP > olicy))", >=20 > =20 >=20 > =20 >=20 > Any help is appreciated. >=20 > =20 >=20 > --Paul >=20 |
7902 messages has been excluded from this view by a project administrator.
