Re: Re: delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30)
by frank.offermanns＠caseris.de
I tested with 2.4.30 and still have the same problems.
Frank
--
Von: Frank Offermanns/CAE
An: openldap-technical(a)openldap.org
Datum: 17.02.2012 11:35
Betreff: Re: delta-syncrepl and mirrormode problem (2.4.29)
I wanted to add, that one database is empty when I start and the other has
only some data. But with master/slave this is no problem, so I think it
should also work for master/master, doesn't it?
I retried with a patched version with these patches:
<
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=8e7af63...
>
<
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=d4...
>
<
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=ea...
>
Unfortunately the problem still persists.
Could at least anyone confirm that the configuration is correct?
Then I can at last stop searching for a error I possibly did and accept
that OpenLDAP with Master/Master (delta-syncrepl) for Windows simply does
not work.
Best regards,
Frank
--
openldap-technical-bounces(a)OpenLDAP.org schrieb am 13.02.2012 11:53:16:
> Von: frank.offermanns(a)caseris.de
> An: openldap-technical(a)openldap.org
> Datum: 13.02.2012 12:07
> Betreff: delta-syncrepl and mirrormode problem (2.4.29)
> Gesendet von: openldap-technical-bounces(a)OpenLDAP.org
>
> Hi,
>
> I want to use delta-syncrepl replication with 2 masters.
> But each slapd-process permanently needs about 25 % CPU usage without
any
> traffic on it.
>
> The log looks endless like this:
>
> ** ld 01e43698 Outstanding Requests:
> * msgid 55, origid 55, status InProgress
> outstanding referrals 0, parent count 0
> ld 01e43698 request count 1 (abandoned 18)
> ** ld 01e43698 Response Queue:
> Empty
> ld 01e43698 response count 0
> ldap_chkResponseList ld 01e43698 msgid 55 all 0
> ldap_chkResponseList returns ld 01e43698 NULL
> ldap_int_select
> read1msg: ld 01e43698 msgid 55 all 0
> ber_get_next
> ber_get_next: tag 0x30 len 1187 contents:
> abandoned/discarded ld 01e43698 msgid 53 message type search-entry
> wait4msg continue ld 01e43698 msgid 55 all 0
> ** ld 01e43698 Connections:
> * host: secondmaster.mydomain.local port: 389 (default)
> refcnt: 2 status: Connected
> last used: Mon Feb 13 11:26:53 2012
>
>
> ** ld 01e43698 Outstanding Requests:
> * msgid 55, origid 55, status InProgress
> outstanding referrals 0, parent count 0
> ld 01e43698 request count 1 (abandoned 18)
> ** ld 01e43698 Response Queue:
> Empty
> ld 01e43698 response count 0
> ldap_chkResponseList ld 01e43698 msgid 55 all 0
> ldap_chkResponseList returns ld 01e43698 NULL
> ldap_int_select
> read1msg: ld 01e43698 msgid 55 all 0
> ber_get_next
> ber_get_next: tag 0x30 len 1187 contents:
> abandoned/discarded ld 01e43698 msgid 53 message type search-entry
> wait4msg continue ld 01e43698 msgid 55 all 0
> ** ld 01e43698 Connections:
> * host: secondmaster.mydomain.local port: 389 (default)
> refcnt: 2 status: Connected
> last used: Mon Feb 13 11:26:53 2012
>
>
> here is my configuration (completely the same for both masters):
>
-----------------------------------------------------------------------------------------------------
> ucdata-path ./ucdata
> include ./schema/core.schema
> include ./schema/cosine.schema
> include ./schema/Personcaesar.schema
> include ./schema/ConfigObjects.schema
>
> loglevel 0
> logfile "C:/test/slapd.log"
>
> pidfile ./run/slapd.pid
> argsfile ./run/slapd.args
>
> access to * by dn.one="ou=Admins,o=caesar" write
> by anonymous auth
>
> ServerID 1 "ldap://firstmaster.mydomain.local"
> ServerID 2 "ldap://secondmaster.mydomain.local"
>
> ######################################################################
> database config
> rootdn cn=config
> rootpw {SHA}secret
>
> #######################################################################
> # BDB database definitions
> #######################################################################
> # Accesslog database definitions
> database hdb
> suffix cn=accesslog
> checkpoint 1024 5
> cachesize 10000
> directory "C:/test/accessdata"
> dbconfig set_cachesize 0 30000000 1
> dbconfig set_flags DB_LOG_AUTOREMOVE
> dbconfig set_lg_regionmax 1048576
> dbconfig set_lg_max 10485760
> dbconfig set_lg_bsize 2097152
> rootdn cn=accesslog
> index objectClass,entryCSN,entryUUID eq
> # I even tried removing reqMod, reading your docs I am not sure if this
is
> needed here
> index reqEnd,reqResult,reqMod,reqStart eq
>
> overlay syncprov
> syncprov-nopresent TRUE
> syncprov-reloadhint TRUE
> # Let the replica DN have limitless searches
> limits dn.exact="cn=Replicator,ou=admins,o=caesar" time.soft=unlimited
> time.hard=unlimited size.soft=unlimited size.hard=unlimited
>
> # Primary database definitions
> database hdb
> suffix "o=caesar"
> checkpoint 1024 5
> cachesize 10000
> idlcachesize 30000
> rootdn "cn=Administrator,o=caesar"
> rootpw {SHA}secret
> directory "C:/test/data"
> dbconfig set_cachesize 0 100000000 1
> dbconfig set_flags DB_LOG_AUTOREMOVE
> dbconfig set_lg_regionmax 1048576
> dbconfig set_lg_max 10485760
> dbconfig set_lg_bsize 2097152
>
>
> # syncprov specific indexing
> index sn pres,eq
> index cn pres,eq,sub
> ...
> index entryUUID eq
> index entryCSN eq
> index objectClass eq
>
> # syncrepl Provider for primary db
> overlay syncprov
> syncprov-checkpoint 1000 60
> syncprov-sessionlog 10000
>
> # accesslog overlay definitions for primary db
> overlay accesslog
> logdb cn=accesslog
> logops writes
> logsuccess TRUE
> # scan the accesslog DB every day, and purge entries older than 7 days
> logpurge 07+00:00 01+00:00
>
> sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited
> # Let the replica DN have limitless searches
> limits dn.exact="cn=Replicator,ou=admins,o=caesar" time.soft=unlimited
> time.hard=unlimited size.soft=unlimited size.hard=unlimited
>
> syncrepl rid=001
> provider="ldap://firstmaster.mydomain.local"
> searchbase="o=caesar"
> type=refreshAndPersist
> retry="5 3 15 +"
> binddn="cn=Replicator,ou=admins,o=caesar"
> bindmethod=simple
> credentials="secret"
> logbase="cn=accesslog"
> logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> schemachecking=on
> syncdata=accesslog
>
>
> syncrepl rid=002
> provider="ldap://secondmaster.mydomain.local"
> searchbase="o=caesar"
> type=refreshAndPersist
> retry="5 3 15 +"
> binddn="cn=Replicator,ou=admins,o=caesar"
> bindmethod=simple
> credentials="secret"
> logbase="cn=accesslog"
> logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> schemachecking=on
> syncdata=accesslog
>
>
> MirrorMode On
>
-----------------------------------------------------------------------------------------------------
>
> I did my test on 2 Windows PCs and OpenLDAP 2.4.29 with Berkeley 5.1 .
>
>
>
> Thanks for any hints,
> FO
>
11 years, 9 months
<what> in ACL defined by set?
by Michael Ströder
HI!
Is it possible to specify the <what> clause in an ACL with a set?
We have several applications and for each application there's a specific
AUXILIARY object class for application-specific user attributes.
So for each application I add ACLs like this:
access to
dn.onelevel="ou=Users,dc=example,dc=org"
attrs=@app1User
by dn.subtree="cn=app1,ou=Systems,dc=example,dc=org" read
by * break
Obviously I'd like to have one ACL which references an attribute specifying
the auxiliary object class in the app's system entry. Is that possible?
Ciao, Michael.
11 years, 9 months
production best-practices for cn=monitor
by Aaron Bennett
Hi,
I'm curious what people think about best practices for cn=monitor in production environments. Do people generally keep it enabled? Is there a drawback to keeping it enabled? Are there any specific security or performance concerns?
Best,
Aaron Bennett
11 years, 9 months
syncrepl simple bind
by S.A.
Hello,
For syncrepl to work do we need to enable the sasl? I had the sasl
disabled and configured to replicate using simple bindmethod, with
the following config:
syncrepl rid=001
provider=ldap://ldap2.example.com
type=refreshAndPersist
retry="5 5 300 +"
searchbase="o=tld"
bindmethod=simple
binddn="uid=admin,ou=users,o=tld"
credentials=password
schemachecking=on
but I get the following error:
slap_client_connect: URI=ldap://ldap2.example.com
DN="uid=admin,ou=users,o=tld" ldap_sasl_bind_s failed (-1)
However, I can bind and search entries both in cn=config and o=tld
from command line using the above binddn and credentials.
Thanks
11 years, 9 months
LDAP_OPT_X_TLS_xxx option in SSL/TLS connection
by Qiang Xu
Hello All,
Today I came across a strange problem.
I wrote a program to test ldap ssl/tls connection with OpenLDAP library.
Something like the code snippet as follows:
int ret = LDAP_OPT_SUCCESS;
int cert_flag = LDAP_OPT_X_TLS_NEVER;
...
ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_flag);
if (ret != LDAP_OPT_SUCCESS)
{
fprintf(stderr, "unable to set require cert option
(LDAP_OPT_X_TLS_REQUIRE_CERT): %s\n",
ldap_err2string(ret));
}
... // bind to the server
cert_flag = LDAP_OPT_X_TLS_DEMAND;
ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_flag);
if (ret != LDAP_OPT_SUCCESS)
{
fprintf(stderr, "unable to set require cert option
(LDAP_OPT_X_TLS_REQUIRE_CERT): %s\n",
ldap_err2string(ret));
}
... // bind to the server
The first binding is successful, as expected. However, the second binding
is also successful, which is contrary to my expectation, because I didn't
create any cert file yet.
Another observation here is that if the first binding with
LDAP_OPT_X_TLS_NEVER is removed, and the second binding with
LDAP_OPT_X_TLS_DEMAND set is done right from the beginning, then it will
fail, as expected.
So, it seems the first value set to the option LDAP_OPT_X_TLS_REQUIRE_CERT
will override the later values, isn't it? Is it possible to change this
option's value on the fly (means different bindings use different values
for this cert option)?
Thanks,
Qiang
11 years, 9 months
Connection timeouts
by Marcin S
Hello,
I have a question, lets say i have web application with ldap
authentication. User that log in to page opens new LDAP connection,
our LDAP also holds some security attributes per application and they
are verified for certain app operations, so connections remains open
for a whole time.
Question is when user close web browser or suddenly disconnects, will
this connection be timed out and closed by server?
Marcin
11 years, 9 months
A question about the sssvlv overlay
by Chris Card
Hi all,
When using the sssvlv overlay I see the following behaviour:
(a) Updating an attribute value while an sssvlv request is active:
1. do a request containing a vlv control and a sort control, which returns a subset of a total result set defined by the search parameters, and the context id for the request. 2. update an attribute value in one of the objects which was returned in the result set 3. repeat the request in step 1, specifying the context id in the vlv control, which returns the same results as in step 1, except that the attribute value updated in step 2 has changed
(b) Deleting an object while an sssvlv request is active:
1. do a request containing a vlv control and a sort control, which returns a subset of a total result set defined by the search parameters, and the context id for the request. 2. delete one of the objects which was returned in the result set 3. repeat the request in step 1, specifying the context id in the vlv control, which returns the same results as in step 1, except that the object deleted in step 2 has gone
(c) Adding an object while an sssvlv request is active:
1. do a request containing a vlv control and a sort control, which returns a subset of a total result set defined by the search parameters, and the context id for the request. 2. add a new object which would have been returned by step 1 if the object had existed already 3. repeat the request in step 1, specifying the context id in the vlv control, which returns the same results as in step 1. The new object is not returned in the results.
(d) Deleting and re-adding an object while an sssvlv request is active:
1. do a request containing a vlv control and a sort control, which returns a subset of a total result set defined by the search parameters, and the context id for the request. 2. delete one of the objects which was returned in the result set 3. repeat the request in step 1, specifying the context id in the vlv control, which returns the same results as in step 1, except that the object deleted in step 2 has gone 4. add the deleted object back in 5. repeat the request in step 1, specifying the context id in the vlv control, which returns the same results as in step 1. The object deleted in step 2 is back.
Is this the expected behaviour of the sssvlv overlay?
Or is the behaviour in (c) a bug?
The draft RFC http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09 does not specify what the behaviour ought to be as far as I can see, but the current behaviour seems inconsistent.
[tested using openldap 2.4.26 patched with all the available fixes to the sssvlv overlay]
Chris
11 years, 9 months
Collabograte project
by Kartik Subbarao
I'm integrating OpenLDAP as an LDAP Directory component in the open
source Collabograte project that I recently announced:
http://kartiksubbarao.com/announcing-collabograte
Here are some areas of integration configured with OpenLDAP:
+ Username and password authentication to MediaWiki, WordPress
Multisite, Cyrus IMAP, Sympa, and ejabberd
+ LDAP Groups used as Sympa Mailing Lists and ejabberd groups
If you want to see the implementation details, you can look at the
puppet manifest and other files:
https://github.com/kartiksubbarao/collabograte/blob/master/puppet/modules...
https://github.com/kartiksubbarao/collabograte/tree/master/puppet/modules...
https://github.com/kartiksubbarao/collabograte/tree/master/puppet/modules...
I'd be very interested in hearing any comments, ideas, suggestions, or
questions you might have on this. I want to help Enterprise IT do a
better job of integrating open source into their environments, as well
as improve the collaboration between Enterprise IT and open source
project communities.
Please feel free to respond here, on the Collabograte mailing list, or
email me directly, whichever you prefer.
Thanks,
-Kartik
11 years, 9 months
OpenLDAP TLS server authority verification
by Daniel Pocock
http://tools.ietf.org/html/rfc4513#section-3.1.3 gives some detail about
how a client should check an LDAP server's TLS certificate. The
language used there is very general though.
Can anyone comment on how OpenLDAP does this, and whether it can be
tweaked from the client side (e.g. through settings in
/etc/ldap/ldap.conf or URI parameters) to mandate a particular policy
for choosing the `reference identity'?
>From RFC 4513, "The client determines the type (e.g., DNS name or IP
address) of the reference identity and performs a comparison between the
reference identity and each subjectAltName value of the corresponding
type until a match is produced" is very vague.
My understanding of `reference identity' is that it should be a
statically/administratively configured value on the client host. On the
other hand, a value derived/mapped from a network source (e.g. DNS SRV
lookup) can never be trusted as a reference identity. To give an example:
ldap[12].outsource.com:
- are the OpenLDAP hosts (run by an external company)
- both have a TLS certificate with CN=ldap[12].outsource.com, and
subjectAltName mycompany.com
_ldap._tcp.mycompany.com:
- an SRV record pointing to ldap[12].outsource.com
- mycompany.com DNS is not secured (no DNSSEC)
webserver.mycompany.com:
- wants to authenticate a user logging in
- has dc=mycompany,dc=com statically configured in some cfg file, so it
trusts mycompany.com as a `reference identity'
- discovers ldap1.outsource.com from DNS SRV lookup on mycompany.com,
(so the LDAP client should not consider ldap1.outsource.com as a
reference identity, because it is a value from DNS)
- therefore, when it connects to ldap1.outsource.com, if the TLS
certificate contains CN=ldap1.outsource.com only, it would not trust the
connection,
- but when it finds the subjectAltName mycompany.com in the cert too, it
should trust the connection
11 years, 9 months
SSL, TLS and DNS SRV
by Daniel Pocock
I have slapd listening on port 636 only because I want to enforce use of
SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a
dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this
would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
- if I create _ldaps._tcp.example.org SRV records, they are ignored
- if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the
_ldap._tcp SRV record that is working, this doesn't seem right
I've also found that other LDAP apps have slightly different
expectations too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661955
I went searching for a definite answer:
+site:ietf.org ldaps srv
http://tools.ietf.org/html/rfc2782 refers to the name of the service
from `Assigned Numbers',
http://tools.ietf.org/html/rfc1700
which omits ldaps, but it is defined elsewhere as a distinct service name:
http://www.ietf.org/assignments/service-names-port-numbers/service-names-...
Therefore, my feeling is that
- if an ldaps: URI is used, the SRV query should be seeking
_ldaps._tcp, and
-if an ldap: URI is used (and StartTLS may or may not be requested by
the user), the SRV query should be looking for _ldap._tcp
Also, can anyone comment on why the URI needs to be escaped manually
when using DNS SRV?
11 years, 9 months
