Re: (ITS#8284) back-relay: olcRelay issues with values containing white spaces
by michael@stroeder.com
hyc(a)symas.com wrote:
>> To reproduce the problem just configure back_relay with a value containing white
>> spaces
>> (i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di
>> Milano,c=IT)
>
> Use double-quotes around arguments containing whitespace.
Attribute 'olcRelay' is of LDAP syntax Distinguished Name
(1.3.6.1.4.1.1466.115.121.1.12). So your statement is pretty surprising.
> Closing this ITS.
Really?
Ciao, Michael.
7 years, 5 months
Re: (ITS#8284) back-relay: olcRelay issues with values containing white spaces
by michele.bensi@fisica.unimi.it
Well this was the first thing I tried, but when I use
olcRelay: "ou=Dipartimento di Fisica,o=Università degli Studi di Milano,c=IT"
I got
ldap_add: Invalid syntax (21)
additional info: olcRelay: value #0 invalid per syntax
Then I tried with
olcRelay: ou="Dipartimento di Fisica",o="Università degli Studi di Milano",c=IT
I had the same error of extra cruft.
I solved patching servers/slapd/back-relay/init.c this way
--- a/servers/slapd/back-relay/init.c 2015-10-20 15:22:20.511667130 +0200
+++ b/servers/slapd/back-relay/init.c 2015-10-21 10:27:02.649251347 +0200
@@ -32,7 +32,7 @@
static ConfigTable relaycfg[] = {
{ "relay", "relay", 2, 2, 0,
- ARG_MAGIC|ARG_DN,
+ ARG_MAGIC|ARG_DN|ARG_QUOTE,
relay_back_cf, "( OLcfgDbAt:5.1 "
"NAME 'olcRelay' "
"DESC 'Relay DN' "
On Wed, Oct 21, 2015 at 03:12:14PM +0100, Howard Chu wrote:
> michele.bensi(a)fisica.unimi.it wrote:
> >Full_Name: Michele Bensi
> >Version: 2.4.42
> >OS: Linux
> >URL: ftp://ftp.openldap.org/incoming/
> >Submission from: (NULL) (159.149.47.246)
> >
> >
> >When configuring realy backend using a relay suffix containg spaces I got this
> >error:
> >
> >ldap_add: Constraint violation (19)
> > additional info: <olcRelay> extra cruft after <relay>
> >A%A
> >To reproduce the problem just configure back_relay with a value containing white
> >spaces
> >(i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di
> >Milano,c=IT)
>
> Use double-quotes around arguments containing whitespace.
>
> Closing this ITS.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
Michele Bensi
Unità Calcolo
Dipartimento di Fisica
Università degli Studi di Milano
Via Celoria, 16
20133 Milano (MI)
ITALY
Phone: +39 02503 17341
Fax: +39 02503 17280
Room: I/T/4
"Unix is user-friendly. It's just very selective about who its friends are."
7 years, 5 months
(ITS#8284) back-relay: olcRelay issues with values containing white spaces
by michele.bensi@fisica.unimi.it
Full_Name: Michele Bensi
Version: 2.4.42
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (159.149.47.246)
When configuring realy backend using a relay suffix containg spaces I got this
error:
ldap_add: Constraint violation (19)
additional info: <olcRelay> extra cruft after <relay>
A%A
To reproduce the problem just configure back_relay with a value containing white
spaces
(i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di
Milano,c=IT)
7 years, 5 months
Re: (ITS#8270) win32: fix conversion error
by hyc@symas.com
Леонид Юрьев wrote:
> 2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com <mailto:hyc@symas.com>>:
>
> nacho.resa(a)gmail.com <mailto:nacho.resa@gmail.com> wrote:
> > --047d7bb03a5ac118d20522842ead
> > Content-Type: text/plain; charset=UTF-8
> >
> > So I took another closer look at this issue and I went for this possible
> > solution:
> >
> https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5a...
>
> That looks OK.
>
> > Basically it errors out because MSVC needs stdcall on that method.
>
> You realize of course, that this change actually has no effect on the code
> here? stdcall uses Pascal argument order instead of C order but it's moot
> since the function only has 1 argument.
> No, there is another important difference:
> cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N);
> stdcall = the callee is responsible to clean stack from args (e.g. retn N);
True, but not relevant here. This is a ThreadProc, and threads never return to
their caller. Windows implicitly calls ExitThread() when this function
returns, and the stack will be destroyed anyway.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by quanah@openldap.org
Full_Name: Quanah Gibson-Mount
Version: RE24 Sept 11, 2015
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
Seeing a scenario where if slapd is stopped on a new MMR node while a full
REFRESH is occurring, the state of that refresh is not tracked, and the wrong
CSN value is stored.
This dataset has 15,000 users. We see it get up to user 625:
Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_search (0)
Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100
uid=user625,ou=people,dc=q1,dc=aon,dc=zimbraview,dc=com
Oct 20 16:13:09 q2 slapd[18724]: slap_queue_csn: queueing 0x44c7e30
20151020185526.862768Z#000000#000#000000
Oct 20 16:13:09 q2 slapd[18724]: slap_graduate_commit_csn: removing 0x44c87c0
20151020185526.862768Z#000000#000#000000
Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_add
uid=user625,ou=people,dc=q2C2Cdc=aon,dc=zimbraview,dc=com (0)
Oct 20 16:13:09 q2 slapd[18724]: slapd stopped.
Then when slapd is restarted:
Oct 20 16:13:16 q2 slapd[18970]: do_syncrep2: rid=100
cookie=rid=100,sid=001,csn=20151020201231.263989Z#000000#001#000000
Oct 20 16:13:16 q2 slapd[18970]: sp_p_queue_csn: queueing 0x309dfd8
20151020201231.263989Z#000000#001#000000
Oct 20 16:13:16 q2 slapd[18970]: slap_queue_csn: queueing 0x5054008
20151020201231.263989Z#000000#001#000000
Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x49353c0
20151020201231.263989Z#000000#001#000000
Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x4935060
20151020201231.263989Z#000000#001#000000
Oct 20 16:13:16 q2 slapd[18970]: syncrepl_message_to_op: rid=100 be_add
cn=q2.aon.zimbraview.com,cn=servers,cn=zimbra (0)
which causes it to skip the other 14,000+ users.
7 years, 5 months
(ITS#8280) test056 fails due to EOL differences
by hyc@openldap.org
Full_Name: Howard Chu
Version: 2.4
OS: Win32
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.155.231.14)
Submitted by: hyc
The 2nd comparison in test056 diffs ldapsearch output against the static
testdata/monitor2.out file. The output from ldapsearch contains DOS \r\n EOLs
while the static file contains Unix \n EOLs and so the diff fails.
In all the tests up to this point, comparisons are always between equally
processed files, instead of 1 processed file and 1 static file, so there were no
EOL differences to contend with.
7 years, 5 months
Re: (ITS#8270) win32: fix conversion error
by leo@yuriev.ru
2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com>:
>
> nacho.resa(a)gmail.com wrote:
> > --047d7bb03a5ac118d20522842ead
> > Content-Type: text/plain; charset=UTF-8
> >
> > So I took another closer look at this issue and I went for this possible
> > solution:
> > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5a...
>
> That looks OK.
>
> > Basically it errors out because MSVC needs stdcall on that method.
>
> You realize of course, that this change actually has no effect on the code
> here? stdcall uses Pascal argument order instead of C order but it's moot
> since the function only has 1 argument.
>
Oops, sorry (dummy gmail...).
No, there is another important difference:
cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N);
stdcall = the callee is responsible to clean stack from args (e.g. retn N);
7 years, 5 months