Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu
--On Tuesday, October 31, 2006 5:50 PM +0000 quanah(a)stanford.edu wrote:
>
>
> --On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods
> <mike(a)arishi.com> wrote:
>
>> As promised, my log entries
>>
>> from my ldap log we have
>>
>> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from
>> IP=127.0.0.1:61497 (IP=0.0.0.0:340)
>> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND
>> dn="uid=replicator,o=menchi" method=128
>> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49
>> text= Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND
>> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed
>>
>> And from the test modules log we have this.
>>
>> Oct 31 10:30:58 Menchi Glue: New
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Config
>> Oct 31 10:30:58 Menchi Glue: Init
>>
>> This is all i get, it starts up, runs through new, all the config calls
>> and then init, slapd stays up and seems perfectly well but when anything
>> attempts to bind to it we get nothing at all!
>
> I need you to reproduce the behavior involved using the "ldapsearch"
> command.
I'm going to elaborate on this a little more. Your operation is performing
a simple bind. The BIND operation is *only* going to get passed into the
PERL backend if it controls the suffix which the binding identity is
attempting to bind to. Since you haven't supplied your slapd.conf
information for back-perl, this is impossible to determine. However, I
will note that unless your slapd.conf has:
database perl
suffix "o=menchi"
I do not expect to see the bind operation in the perl backend.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 4 months
Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu
--On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods <mike(a)arishi.com>
wrote:
> As promised, my log entries
>
> from my ldap log we have
>
> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from
> IP=127.0.0.1:61497 (IP=0.0.0.0:340)
> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND
> dn="uid=replicator,o=menchi" method=128
> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49 text=
> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND
> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed
>
> And from the test modules log we have this.
>
> Oct 31 10:30:58 Menchi Glue: New
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Config
> Oct 31 10:30:58 Menchi Glue: Init
>
> This is all i get, it starts up, runs through new, all the config calls
> and then init, slapd stays up and seems perfectly well but when anything
> attempts to bind to it we get nothing at all!
I need you to reproduce the behavior involved using the "ldapsearch"
command.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 4 months
Re: (ITS#4728) accesslog dont write attributes removing
by hyc＠symas.com
surnu(a)alkohol.ee wrote:
> Full_Name: Andres Kahk
> Version: 2.3.28
> OS: Gentoo Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.80.105.102)
>
>
> if i change attribute, everythings are fine i got:
> reqMod:
> autoReply:= FALSE
> entryCSN:= 20061031104835Z#000000#00#000000
> modifiersName:=
> modifyTimestamp:= 20061031104835Z
>
> but if i remove attribute from object then i got:
> reqMod:
> entryCSN:= 20061031104852Z#000000#00#000000
> modifiersName:=
> modifyTimestamp:= 20061031104852Z
>
> There is no entry to remove. That means the entry is removed in write server,
> but it still exists in read server
>
> If you got any info or patch to fix this and get syncrepl work correctly, please
> send it :)
It works fine here. Does test043 in the test suite succeed or fail for
you? It succeeds here, and it also performs modifications that delete an
attribute from an entry. You'll have to provide more information, e.g.
your slapd configuration would be a good start.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 4 months
(ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee
Full_Name: Andres Kahk
Version: 2.3.28
OS: Gentoo Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.80.105.102)
if i change attribute, everythings are fine i got:
reqMod:
autoReply:= FALSE
entryCSN:= 20061031104835Z#000000#00#000000
modifiersName:=
modifyTimestamp:= 20061031104835Z
but if i remove attribute from object then i got:
reqMod:
entryCSN:= 20061031104852Z#000000#00#000000
modifiersName:=
modifyTimestamp:= 20061031104852Z
There is no entry to remove. That means the entry is removed in write server,
but it still exists in read server
If you got any info or patch to fix this and get syncrepl work correctly, please
send it :)
16 years, 4 months
Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu
--On Monday, October 30, 2006 11:09 AM +0000 mike(a)arishi.com wrote:
> Full_Name: Mike Woods
> Version: 2.3.28
> OS: FreeBSD 6.1 RELEASE 4
> URL: http://geofront.co.uk/GlueTest.pm
> Submission from: (NULL) (207.138.125.56)
>
>
> When using back-perl openldap fails to call the bind methog on
> connection, i've tried this with the 2.2 branch and 2.3.28 to the same
> effect.
>
> The failure to call bind essentialy renders back-perl useless.
>
> I've written and attached a basic "test" module so I can see what
> openldap is doing.
I am unable to reproduce this issue with 2.3.28. How are you testing this?
For me:
ldapsearch -LLL -x -h ldap-uat00 -b o=anyorg,c=us -D
"uid=quanah,o=anyorg,c=us" -w test
tribes:~>
And the log clearly shows bind being called:
Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 fd=8 ACCEPT from
IP=171.64.19.55:41385 (IP=0.0.0.0:389)
Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 op=0 BIND
dn="uid=quanah,o=anyorg,c=us" method=128
Oct 30 18:38:13 ldap-uat00 Glue: Bind
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 4 months
(ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.3.28
OS: Linux 2.6 (64-bit)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.81)
In working to test other bugs, I found that building slapd static allows you to
use back-perl, but building slapd with modular back_perl it fails to resolve
symbols. Investigation ongoing. This is with perl 5.8.8.
--Quanah
16 years, 4 months
(ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com
Full_Name: Eric Covener
Version: 2.4.3
OS: ppc linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.33.49.251)
I'm using 2.4.3 and trying to set SSL client certificates on a per-connection
basis.
A call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &newctx) fails in my simple
test application because ldap_pvt_tls_init hasn't had a chance to call
SSLeay_add_ssl_algorithms() yet.
I'm not familiar enough w/ openldap to track down how this path occurs, but it
seems like the code in tls.c that handles the SSL_CTX_new() in the event of
LDAP_OPT_X_TLS_NEWCTX should make sure the initializer has been run by calling
ldap_pvt_tls_init()
(My simple test app works when I add SSLeay_add_ssl_algorithms() before
ldap_set_option). The failure without the call is
TLS: could not allocate default ctx (336236705).
16 years, 4 months
(ITS#4725) back-perl not calling bind method
by mike＠arishi.com
Full_Name: Mike Woods
Version: 2.3.28
OS: FreeBSD 6.1 RELEASE 4
URL: http://geofront.co.uk/GlueTest.pm
Submission from: (NULL) (207.138.125.56)
When using back-perl openldap fails to call the bind methog on connection, i've
tried this with the 2.2 branch and 2.3.28 to the same effect.
The failure to call bind essentialy renders back-perl useless.
I've written and attached a basic "test" module so I can see what openldap is
doing.
16 years, 4 months
