On Thu, 19 Sep 2013, espeake(a)oreillyauto.com wrote:
> We have a client server that is failing on the ssl handshake using TLS.
> The following is from the server log when the client is trying to connect.
>
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
> IP=172.17.1.10:55469 (IP=0.0.0.0:389)
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
> err=0 text=
> Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
> negotiation failure)
>
> On the client when I run the following:
>
> openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389
That doesn't do StartTLS (like your client is attempting), though.
Try something like
https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw
if you'd like. Or OpenLDAP Software such as ldapsearch(1).
Turning up the slapd(8) debug level may be of some use, too.
> I get this on the client
>
> CONNECTED(00000003)
> 139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:177:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 226 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
>
> If I do the same command on port 636 I can see the certificate. All of our
> applications that use ldap are all set for TLS. Even if I force them to
> port 636 they fail.
>
> Any ideas to look at are appreciated.
>
> Eric Speake
> Web Systems Administrator
> O'Reilly Auto Parts
>
> This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ? 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
>
>
Hello,
I’m trying to set up an OpenLDAP architecture where a client connects to a proxy using an unencrypted connection with a simple bind (e.g., via ldapsearch), and the proxy then connects securely to a backend LDAP server using TLS client certificate authentication via SASL EXTERNAL.
Here is what I’m aiming for:
• The client uses simple bind over ldap:// to connect to the proxy.
• The proxy should ignore the client’s bind credentials and use its own certificate to connect to the backend via ldaps:// or ldap+starttls:// using SASL EXTERNAL.
• The backend uses authz-regexp rules to map the proxy’s certificate DN to a local identity, which is authorized to perform the search on behalf of the client.
I’ve tested this setup with OpenLDAP versions 2.4, 2.5, and 2.6 but have not been able to make it work.
I gave a configuration in my first message and I tried several configurations but I always come back to this one when I read the docs or look at the forums
Regards
On 05/18/2011 08:26 AM, Sayantan Ray wrote:
> Hi,
> During initial communication setup with LDAP server with TLS on we are
> doing:
> ldap_initialize()
> ldap_set_option()
> ldap_start_tls_s()
> ldap_sasl_bind_s()
> and
> We are running the LDAP server remotely
> We observed that ldap_start_tls_s() is taking around 15 sec time to
> execute.
> Anybody has any idea why this is taking this much time?
> Please help
> Thanks,
> Sayantan Ray
Could it be a DNS issue?
R's,
Hugo Monteiro.
--
fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.monteiro(a)fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net
Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.fct.unl.pt apoio(a)fct.unl.pt
fct.unl.pt:~# _
On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
> I understand that, but this way, even when you're forcing TLS, users can
> still expose their passwords if their computers are mal-configured.
> SMTP, IMAP, FTP, etc don't allow this, because they reject the
> connection if LOGINNAME is given before STARTTLS.
That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or
IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both send
the username and password without waiting for a response from the
server**.
> It's kind of a security issue. Is it because in LDAP, username and
> password are given as one command, and the server doesn't have the
> chance to abort at that point? If so, then I guess it's unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server
response if the server doesn't support the SASL-IR capability
I'm having a lot of trouble with replication when using SSL. If I configure
everything exactly the same without SSL, it works flawlessly. The instant I
try to encrypt traffic, one or both servers will deadlock, even after
restart.
I'm configuring according to the instructions at
http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master,
except using ldaps:// instead of ldap://.
In cn=config, I've setup:
olcTLSCACertificateFile: /etc/openldap/certs/Operations_CA_Certificate.pem
olcTLSCertificateFile: /etc/openldap/certs/ldap.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
I've also tried using STARTTLS over ldap:// and it seems to make no
difference.
Permissions are right and I can connect via SSL from clients without issue.
I'm completely stumped as to what might be going on. Has anyone seen this
before?
This is running on Scientific Linux 6 with the following packages:
openldap-2.4.23-32.el6_4.x86_64
openldap-clients-2.4.23-32.el6_4.x86_64
openldap-servers-2.4.23-32.el6_4.x86_64
Yeah, that's the trick though. The OP indicated if they used uri ldap://[hostname] StartTLS doesn't work.
- chris
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Andreas Ntaflos
Sent: Friday, January 07, 2011 10:46 AM
To: openldap-technical(a)openldap.org
Subject: Re: Strange behavior with TLS with self-signed certs
On Friday 07 January 2011 04:18:40 Michael Starling wrote:
> #TLS settings
> ssl start_tls
> ssl on
That should be either "ssl start_tls" OR "ssl on", not both. If you specify "ssl start_tls" then you should use the ldap:// URL schema, if you specify "ssl on" then you should use ldaps://.
Andreas
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Stopping users that are "unauthenticated" makes no sense; everything's
unauthenticated at time=0. You might as well stop slapd if you want a 100%
inability to serve data.
You can deny anonymous users that aren't plaintext, including any
ldaps:/// connections, with something like:
access to *
by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
StartTLS users on 389, though; not sure if that's what you want. I can't
think of any way to use the slapd access language to differentiate based
on listeners, which would probably be the most elegant way to handle what
you asked. To be fair, this entire exercise seems really odd from where I
sit -- are you positive that this will have the desired effect? (If
somebody out in Peru is permitted to connect in unencrypted and make
anonymous queries, why not allow them to make those same queries
encrypted? What's the difference?)
--On Monday, January 28, 2008 2:57 PM +0000 Chris Carr
<chris.carr(a)Camden.gov.uk> wrote:
> Hi All,
>
> I've been running slapd with "-h ldaps:///" so that it takes SSL/TLS
> connections on port 636. This has worked with most clients (Outlook,
> Seamonkey, Thunderbird) but does not work for Evolution. I don't know
> why not, but Evolution seems to insist on using port 389 for secure
> connections.
>
> When I type
>
> openssl s_client -connect my.server.com:389
If you read the documentation on openssl, it clearly states it doesn't
support doing LDAP startTLS over port 389.
I suggest using ldapsearch -ZZ -H ldap://my.server.com:389/
or similar.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Thanks Quanah for your reply. It answered a lot of questions.
I took a back step, and slapcat'd all my cn=configs and main_dbase from all three servers, then ran slapadd to put each into place. Taking one of the cn=configs (using mm-server2's) I modified it for each server pretty much based on your suggestions below to set up Syncreplication with mm-server1 as the master (right now). When I brought them up, they were replicating (I was so happy!) --> any change I made on mm-server1 was immediately replicated over to mm-server2 and 3.
I did learn a great deal over the last week or so. Patience being one of them. I will forward to you in a separate email my cn=configs.
When running slapadd, I did run into this error (which I resolved -- but am curious about) on mm-server1:
First had this (mm-server1):
5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260)
Resolution: set olcMirrorMode to FALSE (made this change on the other servers' ldifs)
This caused an error when, later, running ldapmodify on the main dbase when all servers were running slapd.
ldap_modify: server unwilling to perform (53)
additional info: shadow context: no update referral
Resolution: Removed olcMirrorMode from all ldifs.
Why, even with it set to FALSE, would MirrorMode cause this issue?
Thanks,
John
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Wednesday, February 19, 2014 2:02 PM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
Hi John,
SIDs (server IDs) must be unique across servers.
RIDs (replication IDs) must be unique inside a single server.
So the answer to your question is essentially "no".
If you email me your full cn=config db bits from both servers (minus passwords), there's some cleanup on them I can send back.
The serverID: 1 <URI> bit is only necessary if you are doing cn=config replication, which you are not doing. If you are going to use the <#> <URI> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started with.
Personally, since I do not do cn=config replication, and the URIs are customizable by customers, I go with the much simpler:
olcServerID: <#>
form. Then each server only has a single value for olcServerID, which is its specific serverID. This way I never have to worry that MMR replication is going to get mesed up because of URI changes.
--Quanah
--On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote:
> All,
>
> The long weekend didn't help...still at a loss. Question...
>
> If the olcServerIDs look like, on all three servers:
>
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
> olcServerID: 3 ldap://mm-server3.example.ldap
>
> Should the Replica IDs (rid) in the olcSycnrepl directive be:
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
> schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
> schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no
>
> OR
>
> olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>
> OR
>
> Does it matter?
>
> Also, should the all three olcSycrepl directives be loaded on all
> three servers so they look identical. What I mean by that is should
> each Server "replicate" to itself? There is confusion on this matter.
> I asked Quanah that back in late January, and he stated that the
> system knows about itself so it knows what to ignore. Then last week,
> he asked why I had the master replicating to itself.
>
> Also, since I have refreshAndPersist configured do I need an interval
> as well?
>
> Thanks in advance,
>
> John
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> All,
>
> I just created an mm-server3, using the config_dbase and main_dbase
> from
> mm-server2 -- copied the ldif's I created from mm-server2 then ran
> slapadd.
>
> On mm-server3:
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
> olcServerID: 3 ldap://mm-server3.example.ldap
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
> schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
> schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no
>
> Started slapd, no errors. It immediately sync'd up with mm-server1!
> Changes that I made on mm-server1 days ago which have never replicated
> over to mm-server2...replicated to mm-server3 immediately on startup.
>
> I had not even got around to adding mm-server3 to mm-server1 (or
> mm-server2) yet.
>
> The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show:
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog"
> schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist
> retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>
> So...now, I am at even more of a loss. Why would mm-server1 be
> replicating to mm-server3 and not 2? When the configs are the same
> between mm-server2 and 3???
>
>
>
> Thanks in advance...
> John
>
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> All,
>
> If I went off the beaten' path...where did I go wrong? (my config and
> error messages are in a previous posting)
>
> Thanks in advance,
> John
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of
> Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> Thanks Quanah,
>
> A few weeks back I asked that question (on 1/30):
>> All Masters in the chain have the olcServerID's and olcSynRepl for
>> itself and its partner? I can understand having each knowing about
>> the others but why itself? It's replicating to itself?
> -You replied
> -It knows about itself so it knows what to ignore.
>
> Even in the Admin Guide is specifies setting it up that way...each
> server has all the others and itself listed. I was following the
> procedures delineated in the Admin Guide and in the man-pages
> (including how I understood what was put out on the board): From the Admin Guide:
> 8.3.3. N-Way Multi-Master
>
> For the following example we will be using 3 Master nodes. Keeping in
> line with test050-syncrepl-multimaster of the OpenLDAP test suite, we
> will be configuring slapd(8) via cn=config
>
> This sets up the config database:
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 1
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
> second and third servers will have a different olcServerID obviously:
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 2
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
> This sets up syncrepl as a provider (since these are all masters):
>
> dn: cn=module,cn=config
> objectClass: olcModuleList
> cn: module
> olcModulePath: /usr/local/libexec/openldap
> olcModuleLoad: syncprov.la
>
> Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc.
> with your actual ldap urls):
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 $URI1
> olcServerID: 2 $URI2
> olcServerID: 3 $URI3
>
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcSyncRepl
> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> I followed what is put in the Admin Guide, etc...
>
> Thanks
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah
> Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: Re: Syncrepl and mmr
>
> --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442
> - MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> All,
>
> Your configuration is very confused. Why do you have the master
> replicate to itself, for example?
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
>
>
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
All,
I just created an mm-server3, using the config_dbase and main_dbase from mm-server2 -- copied the ldif's I created from mm-server2 then ran slapadd.
On mm-server3:
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
olcServerID: 3 ldap://mm-server3.example.ldap
olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1} rid=002 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
Started slapd, no errors. It immediately sync'd up with mm-server1! Changes that I made on mm-server1 days ago which have never replicated over to mm-server2...replicated to mm-server3 immediately on startup.
I had not even got around to adding mm-server3 to mm-server1 (or mm-server2) yet.
The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show:
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1} rid=002 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
So...now, I am at even more of a loss. Why would mm-server1 be replicating to mm-server3 and not 2? When the configs are the same between mm-server2 and 3???
Thanks in advance...
John
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL
Sent: Friday, February 14, 2014 1:34 PM
To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
All,
If I went off the beaten' path...where did I go wrong? (my config and error messages are in a previous posting)
Thanks in advance,
John
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL
Sent: Friday, February 14, 2014 8:40 AM
To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
Thanks Quanah,
A few weeks back I asked that question (on 1/30):
> All Masters in the chain have the olcServerID's and olcSynRepl for
> itself and its partner? I can understand having each knowing about
> the others but why itself? It's replicating to itself?
-You replied
-It knows about itself so it knows what to ignore.
Even in the Admin Guide is specifies setting it up that way...each server has all the others and itself listed.
I was following the procedures delineated in the Admin Guide and in the man-pages (including how I understood what was put out on the board):
>From the Admin Guide:
8.3.3. N-Way Multi-Master
For the following example we will be using 3 Master nodes. Keeping in line with test050-syncrepl-multimaster of the OpenLDAP test suite, we will be configuring slapd(8) via cn=config
This sets up the config database:
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret
second and third servers will have a different olcServerID obviously:
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 2
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret
This sets up syncrepl as a provider (since these are all masters):
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/libexec/openldap
olcModuleLoad: syncprov.la
Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 $URI1
olcServerID: 2 $URI2
olcServerID: 3 $URI3
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
I followed what is put in the Admin Guide, etc...
Thanks
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount
Sent: Thursday, February 13, 2014 1:57 PM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: Re: Syncrepl and mmr
--On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote:
> All,
Your configuration is very confused. Why do you have the master replicate to itself, for example?
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
