> It works fine here. Does test043 in the test suite succeed or fail for you?
It succeed, i send my configuration.
slapd.conf:
# Schema and objectClass definitions
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba-tng.schema
include /etc/openldap/schema/myown.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/openldap/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/openldap/slapd.args
# Read slapd.conf(5) for possible values
loglevel 256
# Allow LDAPv2 for legacy clients
allow bind_v2
security update_ssf=128
# Allow nof entries with single search
sizelimit -1
timelimit 30
#threads
threads 256
# TLS
TLSCertificateFile /etc/openldap/ssl/example.crt
TLSCertificateKeyFile /etc/openldap/ssl/example.key
TLSCACertificateFile /etc/openldap/ssl/ca.crt
# REFERRAL
referral ldap://example.org
# ACL
include /etc/openldap/example.acl
# Database conf
include /etc/openldap/slapd.bdb.log.example
include /etc/openldap/slapd.bdb.example
slapd.bdb.log.example:
database bdb
suffix "cn=example_log,dc=logs"
directory /var/lib/openldap-data/example/example_log
rootdn "cn=example_log,dc=logs"
rootpw "secret"
cachesize 5000
idlcachesize 1000
checkpoint 128 30
lastmod on
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
# Indexid
include /etc/openldap/slapd.log.index
slapd.bdb.example:
database bdb
suffix "dc=example"
rootdn "cn=admin,dc=example"
rootpw "secret"
directory "/var/lib/openldap-data/example/"
cachesize 100000
idlcachesize 100000
schemacheck on
checkpoint 8 15
lastmod on
include /etc/openldap/slapd.index
overlay accesslog
logdb cn=pop_log,dc=logs
logops writes
logpurge 7+00:00 1+00:00
limits dn.exact="uid=sync,ou=sync,dc=example" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
overlay syncprov
syncprov-checkpoint 1000 60
syncprov-sessionlog 1000
modulepath /usr/lib/openldap/openldap/
moduleload back_monitor
database monitor
rootdn "cn=monitor"
--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
--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
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/
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 :)
This can be closed, the problem was tracked down to a broken build of
libltdl in Debian Sarge 64-bit. sigh.
--Quanah
--
Quanah Gibson-Mount
QA Engineer
<http://www.openldap.org>
--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
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
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).