(ITS#5393) syncrepl push based replication with back-ldap fails
by emmanuel.duru＠atosorigin.com
Full_Name: Emmanuel Duru
Version: 2.3.39
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.68.44.148)
I'm trying to set a directory architecture with a syncrepl push based
replication, as (partly) stated in the admin guide, chapter 16.1.1.
I have a provider slapd with bdb, an intermediate slapd with back-ldap, which
points to a consumer slapd with bdb.
First, I have to set an updateDN on the consumer slapd, else back-ldap gets a
"no user modification allowed" error on operational attributes
(structuralobjectclass, contextcsn) when it tries to update the consumer slapd
(the admin guide says the opposite).
Then this does not work at all when modifying an entry, because back-ldap gets a
"modify/delete: hasSubordinates: no such attribute" error when it tries to
update the entry.
13 years, 9 months
(ITS#5392) Some traces are lost
by emmanuel.duru＠atosorigin.com
Full_Name: Emmanuel Duru
Version: 2.3.39
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.68.44.148)
Traces related to connections are not logged on file (either default file, or
specified file). Examples of traces which are not logged :
conn=0 fd=2160 ACCEPT from IP=127.0.0.1:1299 (IP=0.0.0.0:4800)
conn=0 op=0 BIND dn="cn=manager,c=fr" method=128
conn=0 op=0 BIND dn="cn=manager,c=fr" mech=SIMPLE ssf=0
conn=0 op=0 RESULT tag=97 err=0 text=
conn=0 op=1 SRCH base="c=fr" scope=2 deref=0 filter="(o=soc)"
conn=0 op=1 SRCH attr=*
conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=0 op=2 UNBIND
conn=0 fd=2160 closed
These traces appear on screen but not on file. The problem is that when starting
slapd as a Windows service, these traces are lost.
13 years, 9 months
Bug in Proxy mode..
by K C, Sachin (Sachin)
OpenLDAP Team,
Seems to be a bug in OpenLDAP 2.4.8 configured in Proxy mode with
--enable-ldap and --enable-rewrite
The proxy config is
database ldap
suffix "o=<O>"
# List of proxy servers delimited by space
# uri <Server List>
uri "ldap://<Main>:<port>/ ldap://<Secondary>:<port>/"
When the "Main" was running, all requests were passed onto Main. I
brought it down and saw that the requests were sent to "Secondary"
server.
After sometime, I brought the Main server back to live simulating a
recovery from crash. The requests were still redirected to "Secondary"
despite the "Main" server being accessible.
I brought down the "Secondary" server and the requests were directed to
Main server.!!
Is this the correct behaviour? ( I believe that the server in the head
of the list should be contacted everytime a request comes to proxy! )
ThanX
Sachin
13 years, 9 months
Re: (ITS#5391) hdb deadlock
by hyc＠symas.com
richton(a)nbcs.rutgers.edu wrote:
> Full_Name: Aaron Richton
> Version: 2.3.40
> OS: Solaris 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (128.6.31.135)
>
>
> One hdb backend on one slave died ~21:58 yesterday...
>
> current thread: t@5
> [1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at
> 0xffffffff7f0a741c
> [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0,
> 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c
> [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at
> 0xffffffff7e0108e8
> =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in
> "os_sleep.c"
> [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op =
> DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c"
> [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c"
> [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
> flags = 0), line 1389 in "txn.c"
> [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
> flags = 0), line 1288 in "txn.c"
> [9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in
> "config.c"
> [10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c"
>
> (dbx) where
> current thread: t@16
> [1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at
> 0xffffffff7f0a741c
> [2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0,
> 0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c
> [3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at
> 0xffffffff7e0108e8
> =>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in
> "os_sleep.c"
> [5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op =
> DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c"
> [6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c"
> [7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
> flags = 0), line 1389 in "txn.c"
> [8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
> flags = 0), line 1288 in "txn.c"
> [9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in
> "delete.c"
> [10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil),
> modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0,
> syncCookie_req = 0xffffffff46fff360, syncCSN =
> 0xffffffff46fff390), line 2006 in "syncrepl.c"
> [11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in
> "syncrepl.c"
> [12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in
> "syncrepl.c"
> [13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c"
>
>
> I can't get db_stat to join the environment. If there's anything else that can
> be gleaned from slapd itself, I'd be glad to poke around the core; otherwise,
> I'm off to rm/slapadd...
>
> "This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of
> the changes (to my eye) looked locking related.
Unfortunately no, nothing familiar here. There's nothing in the BDB
documentation that says two threads are not allowed to call txn_checkpoint
concurrently, but I suppose it may be excessive to make multiple calls in
rapid succession.
One thing that I've started doing recently in my configs is to skip the #bytes
option (leave it zero), so that only time-based checkpoints occur. Since
they're done in a dedicated task, only one thread at a time can trigger a
checkpoint.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 9 months
(ITS#5391) hdb deadlock
by richton＠nbcs.rutgers.edu
Full_Name: Aaron Richton
Version: 2.3.40
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.6.31.135)
One hdb backend on one slave died ~21:58 yesterday...
current thread: t@5
[1] _libc_poll(0xffffffff4f3ff430, 0x0, 0x3e8, 0x0, 0x0, 0x0), at
0xffffffff7f0a741c
[2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0,
0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c
[3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff4f3ff5b0, 0x0), at
0xffffffff7e0108e8
=>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in
"os_sleep.c"
[5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op =
DB_SYNC_CACHE, wrotep = (nil)), line 362 in "mp_sync.c"
[6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c"
[7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
flags = 0), line 1389 in "txn.c"
[8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
flags = 0), line 1288 in "txn.c"
[9] hdb_checkpoint(ctx = 0xffffffff4f3ffc30, arg = 0x1004b4c60), line 165 in
"config.c"
[10] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c"
(dbx) where
current thread: t@16
[1] _libc_poll(0xffffffff46ffe3e0, 0x0, 0x3e8, 0x0, 0x0, 0x0), at
0xffffffff7f0a741c
[2] _select(0x3e8, 0xffffffff7f1bc728, 0xffffffff7f1bc728, 0x0,
0xffffffff7f1bc728, 0x0), at 0xffffffff7f05a74c
[3] select(0x0, 0x0, 0x0, 0x0, 0xffffffff46ffe560, 0x0), at
0xffffffff7e0108e8
=>[4] __os_sleep(dbenv = 0x1005b2610, secs = 1U, usecs = 0), line 84 in
"os_sleep.c"
[5] __memp_sync_int(dbenv = 0x1005b2610, dbmfp = (nil), trickle_max = 0, op =
DB_SYNC_CACHE, wrotep = (nil)), line 439 in "mp_sync.c"
[6] __memp_sync(dbenv = 0x1005b2610, lsnp = (nil)), line 99 in "mp_sync.c"
[7] __txn_checkpoint(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
flags = 0), line 1389 in "txn.c"
[8] __txn_checkpoint_pp(dbenv = 0x1005b2610, kbytes = 100000U, minutes = 10U,
flags = 0), line 1288 in "txn.c"
[9] hdb_delete(op = 0xffffffff46fff618, rs = 0xffffffff46fff088), line 537 in
"delete.c"
[10] syncrepl_entry(si = 0x1004b4e50, op = 0xffffffff46fff618, entry = (nil),
modlist = 0xffffffff46fff320, syncstate = 3, syncUUID = 0xffffffff46fff3c0,
syncCookie_req = 0xffffffff46fff360, syncCSN =
0xffffffff46fff390), line 2006 in "syncrepl.c"
[11] do_syncrep2(op = 0xffffffff46fff618, si = 0x1004b4e50), line 731 in
"syncrepl.c"
[12] do_syncrepl(ctx = 0xffffffff46fffc30, arg = 0x1004b5030), line 1095 in
"syncrepl.c"
[13] ldap_int_thread_pool_wrapper(xpool = 0x10041e500), line 478 in "tpool.c"
I can't get db_stat to join the environment. If there's anything else that can
be gleaned from slapd itself, I'd be glad to poke around the core; otherwise,
I'm off to rm/slapadd...
"This makes sense and shouldn't happen in 2.3.41" would be fine too, but none of
the changes (to my eye) looked locking related.
13 years, 9 months
Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com
Howard Chu wrote:
> Emmanuel Lecharny wrote:
>> Howard Chu wrote:
>>> There's no bug here, and the schema parser isn't causing your problem.
>>> As documented in slapd.conf(5), directives must form a single logical
>>> line. Lines that are split must be continued by a leading space
>>> character.
>
>> Assuming this is not a bug, this is still really painfull... It would be
>> much better to consider that the AttributeType, being parenthesed, can
>> be scanned without taking into account the leading white space, until
>> the closing ')'.
>
> The config file parser breaks the input into lines before scanning to
> see what keywords are actually on those lines. The syntax of the
> config file has been documented to behave this way for over 10 years.
> Nobody else has cared to change it until now...
FYI, before having RTFM, I thought that the only possible "include" I
can use was for schema file. It made sense to me then that OpenLDAP was
using a specific parser for schema, but I was wrong.
It seems that I have missed the part of the doc where this 'first space
requirement' is mentionned... We were lucky enough in ADS to be able to
use a contextfull parser for those schema file (we support the same
format), so we were able to relax this constraint. Supposing that ADS
behavior is to be expected by OpenLDAP is obviously a mistake ...
I wish I have some time to provide some patch for OpenLDAP to relax such
a constraint, but, eh, if I say so, that would be a damn lie !
>
> Of course, all of that is going to be phased out as we move to pure
> LDIF in the future. (Which again, requires a leading space character
> for line continuations. And again, is a well documented feature of the
> format.)
Yeah, the problem will remain, but at least, there is a RFC for idiot
like me who don't do their homeworks... The *big* advantage to have LDIF
formatted schemas is that you won't have anymore to care about ordering
the elements inside attributeTypes and objectClasses...
Btw, we do have some LDIF format for Shcema, and I was wondering if it
won't be a good idea to try to define a common format ? I would really
appreciate if a LDIF schema file could be directly injected in both ADS
and OpenLDAP !
Thanks.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
13 years, 9 months
Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com
Emmanuel Lecharny wrote:
> Howard Chu wrote:
>> There's no bug here, and the schema parser isn't causing your problem.
>> As documented in slapd.conf(5), directives must form a single logical
>> line. Lines that are split must be continued by a leading space
>> character.
> Assuming this is not a bug, this is still really painfull... It would be
> much better to consider that the AttributeType, being parenthesed, can
> be scanned without taking into account the leading white space, until
> the closing ')'.
The config file parser breaks the input into lines before scanning to see what
keywords are actually on those lines. The syntax of the config file has been
documented to behave this way for over 10 years. Nobody else has cared to
change it until now...
Of course, all of that is going to be phased out as we move to pure LDIF in
the future. (Which again, requires a leading space character for line
continuations. And again, is a well documented feature of the format.)
> That being said, as soon as I have fixed the schema file, I'm not
> suffering anymore. I was just thinking about the poor other users ;)
>
> Thanks Howard !
You're welcome ;)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 9 months
Re: (ITS#5390) Error while parsing a schema
by elecharny＠gmail.com
Howard Chu wrote:
> There's no bug here, and the schema parser isn't causing your problem.
> As documented in slapd.conf(5), directives must form a single logical
> line. Lines that are split must be continued by a leading space
> character.
Assuming this is not a bug, this is still really painfull... It would be
much better to consider that the AttributeType, being parenthesed, can
be scanned without taking into account the leading white space, until
the closing ')'.
That being said, as soon as I have fixed the schema file, I'm not
suffering anymore. I was just thinking about the poor other users ;)
Thanks Howard !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
13 years, 9 months
Re: (ITS#5390) Error while parsing a schema
by hyc＠symas.com
There's no bug here, and the schema parser isn't causing your problem.
As documented in slapd.conf(5), directives must form a single logical line.
Lines that are split must be continued by a leading space character.
elecharny(a)apache.org wrote:
> Full_Name: Emmanuel Lecharny
> Version: 2.3.39 (stable)
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.245.116.110)
>
>
> Trying to load a schema, I got an error because the schema parser is expecting a
> WSP before the closing parenthese. Here is the attributeType :
>
> attributetype ( 1.3.6.1.4.1.30267.0.1
> NAME 'ApplicationName'
> SUP name
> EQUALITY caseIgnoreMatch
> ORDERING caseIgnoreOrderingMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
> SINGLE-VALUE
> )
> ^
> |
> +--- note that there is no space here.
>
> If I add a spece before the ')', the schema is parsed correctly.
>
> This is breaking RFC 4512 :
This has nothing to do with RFC 4512.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 9 months
(ITS#5390) Error while parsing a schema
by elecharny＠apache.org
Full_Name: Emmanuel Lecharny
Version: 2.3.39 (stable)
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.245.116.110)
Trying to load a schema, I got an error because the schema parser is expecting a
WSP before the closing parenthese. Here is the attributeType :
attributetype ( 1.3.6.1.4.1.30267.0.1
NAME 'ApplicationName'
SUP name
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
^
|
+--- note that there is no space here.
If I add a spece before the ')', the schema is parsed correctly.
This is breaking RFC 4512 :
WSP = 0*SPACE ; zero or more " "
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
The main problem with this kind of parsing error is that some users may spent
_hours_ finding out what's going on... I just spoilt one full hour myself :/
Also the logs are not really self-explanatory... :
...
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other
; AttributeType
[ "EQUALITY" woid ] ; Matching Rule name
[ "ORDERING" woid ] ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
; userApplications
; directoryOperation
; distributedOperation
; dSAOperation
whsp ")"
/opt/ldap/openldap/etc/openldap/schema/sofinco.schema: line 13: <attributetype>
handler exited with 1!
...
13 years, 9 months
