contextCSN of subordinate syncrepl DBs
by Rein Tollevik
I've been trying to figure out why syncrepl used on a backend that is
subordinate to a glue database with the syncprov overlay should save the
contextCSN in the suffix of the glue database rather than the suffix of
the backend where syncrepl is used. But all I come up with are reasons
why this should not be the case. So, unless anyone can enlighten me as
to what I'm missing, I suggest that this be changed.
The problem with the current design is that it makes it impossible to
reliably replicate more than one subordinate db from the same remote
server, as there are now race conditions where one of the subordinate
backends could save an updated contextCSN value that is picked up by the
other before it has finished its synchronization. An example of a
configuration where more than one subordinate db replicated from the
same server might be necessary is the central master described in my
previous posting in
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
My idea as to how this race condition could be verified was to add
enough entries to one of the backends (while the consumer was stopped)
to make it possible to restart the consumer after the first backend had
saved the updated contextCSN but before the second has finished its
synchronization. But I was able to produce it by simply add or delete
of an entry in one of the backends before starting the consumer. Far to
often was the backend without any changes able to pick up and save the
updated contextCSN from the producer before syncrepl on the second
backend fetched its initial value. I.e it started with an updated
contextCSN and didn't receive the changes that had taken place on the
producer. If syncrepl stored the values in the suffix of their own
database then they wouldn't interfere with each other like this.
There is a similar problem in syncprov, as it must use the lowest
contextCSN value (with a given sid) saved by the syncrepl backends
configured within the subtree where syncprov is used. But to do that it
also needs to distinguish the contextCSN values of each syncrepl
backend, which it can't do when they all save them in the glue suffix.
This also implies that syncprov must ignore contextCSN updates from
syncrepl until all syncrepl backends has saved a value, and that
syncprov on the provider must send newCookie sync info messages when it
updates its contextCSN value when the changed entry isn't being
replicated to a consumer. I.e as outlined in the message referred to above.
Neither of these changes should interfere with ordinary multi-master
configurations where syncrepl and syncprov are both use on the same
(glue) database.
I'll volunteer to implement and test the necessary changes if this is
the right solution. But to know whether my analysis is correct or not I
need feedback. So, comments please?
--
Rein Tollevik
Basefarm AS
13 years, 6 months
dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea
of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
In the meanwhile slapd could accept definitions for both in slapd.conf
and simply pass them on to a schema-aware LDAP client for informational
purpose without enforcing them. Same function like rootDSE <file> in
slapd.conf.
Opinions?
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
14 years, 2 months
cancel operation
by manu＠netbsd.org
Hello
I found a bug in slapo-nops: if all modify operations are idempotent, I
end up with op->orm_modlist being NULL, and slapd stops there.
Here is the current code in slapo-nops that deals with that condition:
if ((m = op->orm_modlist) == NULL) {
op->o_bd->bd_info = (BackendInfo *)(on->on_info);
send_ldap_error(op, rs, LDAP_SUCCESS, "");
return(rs->sr_err);
}
Obviously, this is not doing what it should. I need to abort the
operation while returning LDAP_SUCCESS to the client. How should this be
done?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
14 years, 2 months
Implementing a matching rule for binary (ie: 1.3.6.1.4.1.1466.115.121.1.5)
by Stef
I'm working on using openldap to store certificate requests (ie: PKCS#10
and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for
my custom attribute. However there doesn't seem to be a equality
matching rule for that syntax.
I could implement one, but would such a contribution be accepted by the
openldap project? I've looked around online, but I can't seem to find an
OID for such a matching rule declared anywhere.
Am I barking up the wrong tree? If not I'll whip up a patch.
Cheers,
Stef Walter
14 years, 3 months
Re: commit: ldap/servers/slapd schema_check.c
by Pierangelo Masarati
ando(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> schema_check.c 1.118 -> 1.119
>
> Log Message:
> don't allow to add distinguished values when other values of naming attributes are already present (ITS#5965)
... and the naming attribute is single-valued! :)
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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
14 years, 3 months
Re: N-Way docs
by Gavin Henry
Good point. Will clear it up then.
------Original Message------
From: Howard Chu
To: Gavin Henry
Cc: OpenLDAP Devel
Subject: Re: N-Way docs
Sent: 19 Feb 2009 21:16
Gavin Henry wrote:
> Hi All,
>
> I would like to re-write the N-Way section using slapd.conf syntax to make
things easier for people and show how to convert it to slapd.d at the end.
>
> It looks like cn=config is getting in the way of people testing N-Way for now.
>
> Thoughts?
No. slapd.conf is being phased out. People need to get used to cn=config.
People who can't read LDIF need to learn how, otherwise they're in no position
to be administering an LDAP server.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
14 years, 3 months
RE: 2.4.14 prerelease call for testing #2
by Brett Maxfield
Doesnt "currently asm" indicate asm spinlocks.. Which can be unreliable. These can be even more unreliable with unpatched bdb?
So perhaps you should try posix style semaphores.. Forcing posix/pthreads both at compile time and at run time..
-----Original Message-----
From: Howard Chu <hyc(a)symas.com>
Sent: Tuesday, 17 February 2009 1:26 AM
To: Dieter Kluenter <dieter(a)dkluenter.de>
Cc: openldap-devel(a)openldap.org
Subject: Re: 2.4.14 prerelease call for testing #2
Dieter Kluenter wrote:
> Aaron Richton<richton(a)nbcs.rutgers.edu> writes:
[..snip..]
> #0 0x00002b77bc3da12d in __lock_detect ()
> from /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so
> Current language: auto; currently asm
Which is pretty squarely inside BerkeleyDB. But nobody else reported any such
problem yet. Seems you'll have to check your BDB build.
14 years, 3 months
N-Way docs
by Gavin Henry
Hi All,
I would like to re-write the N-Way section using slapd.conf syntax to make things easier for people and show how to convert it to slapd.d at the end.
It looks like cn=config is getting in the way of people testing N-Way for now.
Thoughts?
Thanks.
--
Kind Regards,
Gavin Henry.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
14 years, 3 months
2.4.14 prerelease call for testing #2
by Quanah Gibson-Mount
Several more fixes completed, please test.
Thanks!
Still waiting on confirmation from someone with gnutls. ;)
--Quanah
--On February 9, 2009 8:11:20 AM -0800 Quanah Gibson-Mount
<quanah(a)zimbra.com> wrote:
> Please test current RE24 CVS. In particular, if people can test:
>
> (a) Building without TLS & without sasl
> (b) Building without TLS
> (c) Building without sasl
> (d) If at least one person can build against GnuTLS instead of OpenSSL
>
> Much appreciated. :)
>
> Thanks,
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
Old ITSs again
by Howard Chu
ITS#2560 and #2802 are both EBCDIC dependencies, from nearly 6 years ago.
Since it appears no one has cared in the intervening time, do we want to pay
them any more attention, or just close them?
I borrowed access to the mainframe when I completed the port in 2002, and
don't have that access any more, so I have no way to verify any fixes anyway.
Anyone else?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 3 months
