Re: LD_LIBRARY_PATH for make test
by Gavin Henry
> Seems to work (at least until test002)...
>
> Ciao, Michael.
On test002 is it just sitting there? I think my build options are wrong for Ubuntu.
My build script runs fine on Red Hat/Centos, but sits on test002.
Will check my options too.
--
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, 8 months
Mirror Mode, MMR and replicas
by Quanah Gibson-Mount
A number of our clients have requested "fail-over"/redundancy capabilities
for the LDAP master, and as I'm currently working on moving our product to
use OpenLDAP 2.4, this becomes a distinct possibility. However, I have
some questions about the viability/reliability/effectiveness of using
multiple masters combined with replicas. I don't see these answered in the
Admin Guide.
I'll start with replication under MMR.
As I understand it, the replicas can only point at a single master. So, if
I have a 2 master MMR setup, I assume I would want to point half my
replicas at master A and the other half at master B for their updates.
This leads to a problem in my mind, in that if master A goes down, then
half of my replica pool is now going to remain completely out of sync with
the remaining master until master A is recovered. Throwing a Load balancer
in front of the two masters, and pointing the replicas at that instead, is
not a viable option because the two masters may be getting updates in a
different sequence, so if a replica disconnects from the LB and then
reconnects, the updates it could get fed from whatever master the LB is
pointing at could lead to inconsistencies. Neither of these seem like a
good option. I don't see a good solution here to resolve this issue,
either, unless the replica could somehow know which master it had been
talking to, and drop into refresh mode if it found itself talking to a new
master? I'm also not clear on what happens if your replicas are
delta-syncrepl based, rather than normal syncrepl, in the LB setup.
For Mirror Mode, I would assume you could point the replicas at the LB
fronting the two masters, since only one master is ever receiving changes.
I also assume delta-syncrepl would be a completely valid option for
replication to the replicas, again because only one master is getting the
updates, so all updates would be logged in the same sequence on both
servers. However, I don't know if this is correct or not, or if there are
limitations here I haven't considered. When I was first pondering this on
the #openldap-devel channel in IRC, Matt Backes made a comment about
delta-syncrepl not working with Mirror Mode.
So, basically, I'm at a loss if my understanding things is correct, on how
I provide a consistent replicated environment for my customers, while also
providing master/master failover.
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 8 months
Please test RE24
by Quanah Gibson-Mount
Please test RE24 as it is being considered for 2.4.16. Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 8 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, 8 months
Re: commit: ldap/servers/slapd/overlays syncprov.c
by Pierangelo Masarati
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
>
> Modified Files:
> syncprov.c 1.272 -> 1.273
>
> Log Message:
> More for #6020
Howard,
I'm running a set of private tests loosely derived from test050. There
is one which basically consisted in simultaneously running 3 concurrency
tests (slapd-tester) with 3 MMR (intensive potentially conflicting write
load). It didn't use to pass until this last fix.
Now all modifications seem to apply and replicate consistently.
However, in the end the entryCSN of some entries differ (occasionally,
the test just passes). Does this give you some useful indication? I
can share the tests (they were meant for inclusion in OpenLDAP, all in
all, although they are under development). It may require a while,
because they need harmonization.
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, 8 months
Re: commit: ldap/servers/slapd/overlays syncprov.c
by Howard Chu
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
>
> Modified Files:
> syncprov.c 1.266 -> 1.267
>
> Log Message:
> ITS#6020 better tracking of where changes came from
Note that this is an incompatible change on the wire. Previously the rid and
sid that a consumer sends to a provider were returned unchanged in any
responses from the provider. (Which was, in retrospect, a mistake... It
allowed the syncprov to know the sid of the consumer, but the consumer didn't
know the sid of the provider.)
Now the current server's serverID is always sent. This allows both sides of
the connection to know each other's serverID, which is essential for routing
decisions.
--
-- 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, 8 months
Re: Please test RE24
by Quanah Gibson-Mount
--On Tuesday, March 10, 2009 7:58 PM +0100 Jens Vagelpohl
<jens(a)dataflake.org> wrote:
>> This should be fixed now, please test further. :)
>
> Not yet :-(
>
> testrun tarball attached.
Thanks. Please keep replies on the list though. :)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 8 months
Enforce serverID 0 is for single-master only
by Rein Tollevik
ServerID 0 should be reserved for single-master configurations, ref
http://www.openldap.org/lists/openldap-bugs/200809/msg00131.html. But
this is neither enforced in the code, nor mentioned in the doc. as far
as I can see.
Reserving serverID 0 for the single-master case would make it easier to
distinguish between old single-master and new multi-master configuration
based on the SID of the CSNs. But the main benefit would be to catch
the apparently far too common configuration error of failing to set a
correct serverID in multi master configurations. Is it OK if I implement it?
This would mean that slapd would refuse to start if syncrepl or syncprov
finds a contextCSN value with SID=0 in the database upon startup and
there is more than one contextCSN, or if MirrorMode is enabled. Syncrepl
should refuse to receive updates to contextCSN values under the same
conditions, and tear down the connection (and retry later) if one is seen.
Syncprov should also refuse slapd to start if serverID is 0 and
MirrorMode is enabled or any contextCSN with non-zero SIDs are found.
This would require a non-zero serverID also on pure forwarding servers
that never changes anything by them self. But I think this minor
drawback is worth it if it allows us to catch the serverID configuration
errors. Syncrepl should probably allow serverID 0, so that pure
consumers can exist without requiring separate serverID values.
Comments?
Rein
14 years, 8 months
