Sync replication failure during startup.
by Stelios Grigoriadis
OpenLDAP v. 2.3.32
Berkeley DB 4.6
gcc 4.1.0
Replication doesn't work if the master server is started after
the replica servers and a large amount of simoultaneous updates
are performed while the server is starting up.
The entries that didn't get replicated to the replicas will not
be replicated even after a restart of both master and replicas.
The contextCSN is set to a value larger than the entryCSN of the
"lost" entries.
This is what I think happens during a master server startup with
simoultaneous updates ongoing (and replicas trying to sync in the
initial phase).
Suppose that two clients (Client1 and Client2) are adding the entries
a and b respectively. If that happens between t1 and t2 (one second
between)
they will get the same entryCSN (same timestamp). If entry a is
committed
at tc1 and b at tc2, any replica search inbetween will only get the
entry a. The entry b will be lost.
Client1 entry=a, csn=x
Client2 entry=b, csn=x
Timeline ------+----------+---------+----+------>
| |
t1 | | t2=t1+1
| |
tc1=entry a tc2=entry b
committed committed
Replica search query between tc1 and tc2.
I don't know if a higher granularity would prevent this, or even better,
to have some kind of a counter so that every modification gets a unique
csn.
Can you please comment on our analyzis to let us know if the analyzis is
correct or if we have missed something important?
Any help or hints on how to avoid or fix this problem is greatly
appreciated.
If I receive useful information direcly in private email, I will post a
summary.
Regards
Stelios Grigoriadis
15 years, 5 months
Re: (ITS#4467) snprintf is consistenly used wrongly
by ando＠sys-net.it
h.b.furuseth(a)usit.uio.no wrote:
> OpenLDAP is full of code like
> ptr += snprintf( ptr, ... );
> and
> bv.bv_len = snprintf( ... );
> <use bv>;
Let me add that there seem to be occasional improper uses of sprintf()
too (usually in marginal code, fortunately).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it
hyc(a)symas.com wrote:
> Howard Chu wrote:
>> I just got tripped trying to import an LDIF with a cert with 16 byte
>> SerialNumber. I've patched this to just use the same hexadecimal format that
>> OpenSSL uses when the number is larger than ber_int_t. We really don't want
>> the format to change just because someone has a BigNum library available; it
>> needs to stay consistent.
>
> But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now.
> And in case somebody feeds in a very large decimal integer, we still need a
> multi-word decimal-to-binary converter. As such, this bug cannot be closed yet.
OK. Does it make any sense to just move to a hex-only syntax, perfixed
by "0x", with no sign as you mentioned earlier, or should we preserve
compatibility with the original form, where the minus sign is allowed
while a number not starting with "0x" should be treated as decimal? The
latter would be probably better, but we'd need to convert decimal to
hex, and this could fail if decimals are too large.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com
Howard Chu wrote:
> I just got tripped trying to import an LDIF with a cert with 16 byte
> SerialNumber. I've patched this to just use the same hexadecimal format that
> OpenSSL uses when the number is larger than ber_int_t. We really don't want
> the format to change just because someone has a BigNum library available; it
> needs to stay consistent.
But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now.
And in case somebody feeds in a very large decimal integer, we still need a
multi-word decimal-to-binary converter. As such, this bug cannot be closed yet.
--
-- 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/
15 years, 5 months
Re: (ITS#5146) slapo-ppolicy
by ando＠sys-net.it
hyc(a)symas.com wrote:
> Of course now that userPassword and authPassword already exist, all the good
> attribute names are already gone. ;)
"password"?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 5 months
(ITS#5159) make slap_passwd_parse() non-destructive
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD/RE24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (63.193.240.128)
Submitted by: hyc
In RE23 the slap_passwd_parse() function parses the exop data destructively, so
it cannot be successfully parsed again by any other function that needs to. In
HEAD there is a new LBER option to specify non-destructive parsing of strings,
and slap_passwd_parse() has been changed to use this option.
15 years, 5 months
(ITS#5158) contrib should use separate config OID arc
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD/RE24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (63.193.240.128)
Submitted by: hyc
Currently we track config OID allocations in slapd/bconfig.c for both core
modules and contrib modules. Since we really aren't maintaining the contrib
modules, they should use a separate OID arc and the OIDs should be tracked
elsewhere.
This has been changed in HEAD, and contrib/ConfigOIDs now exists for tracking
OIDs allocated to contrib modules.
15 years, 5 months
(ITS#5156) missing slapd.d man page
by gerard.ranke＠kmt.hku.nl
Full_Name: Gerard Ranke
Version: 2.3.35, 2.3.38
OS: IRIX 6.5.30
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.87.216.230)
Section 5.2 from the OpenLDAP Administrator's Guide mentions the slapd.d(5) man
page. However, this seems to be missing from the distribution. Would it be
possible to add it? Thanks for your time and effort.
Best regards,
Gerard Ranke
15 years, 5 months
Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de
On Sonntag, 23. September 2007, ando(a)sys-net.it wrote:
> Ralf Haferkamp wrote:
> > Please note that test020 currently fails in HEAD sometime. I think this
> > depends on the order in which the results for queries that hit the
> > sizelimit are returned.
>
> I added tests for sizelimit that were consistent with my changes;
> however, I'm now short of time to work on this, so feel free to back out
> those test changes if you believe the code is working correctly, while
> we design test improvements that are consistent with all fixes.
I have rearranged the pcache test case a bit. It succeeds now on my test
machine.
--
Ralf
15 years, 5 months
