RE: Openldap server with TLS not working
by Christian Kratzer
Hi,
On Thu, 3 Oct 2013, Axel Grosse wrote:
> Hi Ben, Dieter
> can we focus on LDAPS because TLS1 is not an option and even if LDAPS is deprecated I should be able to configure it ..
>
> TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt
> TLSCertificateFile /etc/openldap/ssl/VordelDev.crt
> TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key
> TLSVerifyClient never
>
>
> are this entries in the slapd.conf sutable for LDAPS ?
> if not whats missing ?
>
> start the server with
> /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
in that case you need ldaps:// and not ldap:/ in the url. Now you are starting plaintext ldap on port 636.
Please just start slapd without any host specification and test using openssl s_client connect target:636
After that works start trimming down the ports slapd binds to.
Greetings
Christian
>
>
> thanks a lot
> Axel
>
>
> AXEL GROSSE
> Principal Solution Architect, Sales Solution Center, Axway
> P: +61-405-995-768
> 828 Pacific Highway
> Gordon, 2072 NSW
> agrosse(a)axway.com
> http://www.axway.com
>
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter
> Sent: Thursday, 3 October 2013 6:46 PM
> To: openldap-technical(a)openldap.org
> Subject: Re: Openldap server with TLS not working
>
> Am Thu, 3 Oct 2013 00:16:28 +0000
> schrieb Axel Grosse <agrosse(a)axway.com>:
>
>> Hi ben,
>> thanks for the comment.
>> agree with you on TLS usage should be perferred
>> but the client that is connecting is only capable of LDAPS ... he has
>> not implemented TLS Client jet .
>>
>> But can you please take a look to the error I am facing
>>
>> openssl s_client -connect 192.168.30.169:389 -showcerts
>> -CAfile ./ssl/VordelCA.crt CONNECTED(00000003)
>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>> failure:s23_lib.c:188:
>>
>> any idea what can cause this ?
>>
>>
>> AXEL GROSSE
>> Principal Solution Architect, Sales Solution Center, Axway
>> P: +61-405-995-768
>> 828 Pacific Highway
>> Gordon, 2072 NSW
>> agrosse(a)axway.com
>> http://www.axway.com
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
>> Sent: Wednesday, 2 October 2013 10:57 PM To:
>> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS
>> not working
>>
>> On 2013.10.02 07.29, Axel Grosse wrote:
>>
>>> when I test on the server itself ..
>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
>>> ./ssl/VordelCA.crt
>>> CONNECTED(00000003)
>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:188:
>>
>> ldaps [port 636] is deprecated. use starttls with the standard port
>> [389]. to test, just use ldapsearch [see the reference to -Z in the
>> man page]
>
> You are connnecting to port 389, but s_client is not able to initiate a
> LDAP startTLS session (only SMTP and IMAP), so you have to connect
> ldaps and port 636.
>
> -Dieter
>
>
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
11 years, 8 months
Re: TLSVerifyClient => no login possible
by Dieter Kluenter
Hello Sebastian,
Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
> Dieter Kluenter schrieb:
>> Hello Sebastian,
>>
>> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
>>
>>
>>> Dieter Kluenter schrieb:
>>>
>>>> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
[...]
>>> Now I have set the loglevel to "3" and I get the following output if I
>>> try to login (still fails):
>>>
>>
>> loglevel is != debug level, man slapd(8), run slapd -d3
>>
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>
>>
>> [...]
>>
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search
>>> LDAP server - Server is unavailable
>>>
>> [...]
>>
>>
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s:
>>> Connect error
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>
>>> I am not sure, if this is an configuration or certificate error? Do You
>>> understand this output above?
>>>
>>
>> The clients are nss_ldap and pam_ldap, check the clients
>> configuration for starttls parameters.
>> With debug level 3 you should see something like
[...]
> Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file
> properly. The certifikate entries were missing.
>
> Here is my /etc/ldap.conf:
> -------------------/etc/ldap.conf-------------------------------------------
> host 127.0.0.1
This Hostadress is probabely not the certifcate DN
> base dc=lmv,dc=lmv
> #uri ldap://127.0.0.1/
> #uri ldaps://127.0.0.1/
> #uri ldapi://%2fvar%2frun%2fldapi_sock/
> #ldap_version 3
> #binddn cn=proxyuser,dc=example,dc=com
> #bindpw secret
> rootbinddn cn=ldaproot,dc=lmv,dc=lmv
To bind as rootdn is not a good idea.
[...]
> #ssl on
> sslpath /etc/openldap/
although it is not the base of your problem, omit sslpath
> ssl start_tls
> ldap_version 3
> pam_filter objectclass=posixAccount
> nss_base_passwd ou=users,dc=lmv,dc=lmv
> nss_base_shadow ou=users,dc=lmv,dc=lmv
> nss_base_group ou=groups,dc=lmv,dc=lmv
> tls_checkpeer yes
> #ssl on
> tls_cacertfile /etc/openldap/cacert.pem
> tls_cacertdir /etc/openldap/
omit tls_cacertdir
> #tls_randfile /var/run/egd-pool
> #tls_ciphers TLSv1
> tls_cert /etc/openldap/clientcert_201.pem
> tls_key /etc/openldap/clientkey_201.pem
> #sasl_secprops maxssf=0
> #krb5_ccname FILE:/etc/.ldapcache
> -------------------/etc/ldap.conf-------------------------------------------
>
> And also my /etc/openldap/ldap.conf:
> -------------------/etc/openldap/ldap.conf-----------------------------
> TLS_CACERT /etc/openldap/cacert.pem
> TLS_CERT /etc/openldap/clientcert_201.pem
> TLS_KEY /etc/openldap/clientkey_201.pem
> TLS_REQCERT demand
> host 127.0.0.1
[...]
>
> TLS: can't accept.
> connection_read(14): TLS accept failure error=-1 id=33, closing
[...]
> What is wrong? The certificate is not accepted? Is the certificae not ok?
I presume the certificate DN is not in conformance with the called URI
To test this, just do a ldapsearch with a simple bind and starttls,
that is ldapsearch -x -D some DN -w passwd -ZZ ldap://my.remote.host
-b "" -s base +
You may do a strace on this process, that is "strace -o /tmp/myfile.txt
ldapsearch ...."
As you use a host certificate, on a successful session ou may see
something like
TLS trace: SSL_accept:SSLv3 flush data
connection_read(19): unable to get TLS client DN, error=49 id=8
But despite a error 49, the session is established.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
sip: +49.180.1555.7770535
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
16 years, 3 months
Re: mmr of cn=config with OpenLDAP 2.6
by Stefan Kania
The problem is solved,
in my configuration I wrote:
----------------
dn: olcDatabase={2}mdb,cn=config
objectClass: olcmdbConfig
----------------
but with 2.6 ldapmodify is looking for:
objectClass: olcMdbConfig
so it must be a capital "M". With a small "m" you will get "err=53"
"server unwilling to perform"
@Quanah: In your blog about mmr it's also with a small "m", maybe you
can change it.
Am 07.12.21 um 16:52 schrieb Stefan Kania:
> Hi to all,
>
> is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it
> running with 4 server.
> I'm installing all 4 server with Ansible so I created a basic configuration:
> ------------------
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcLogLevel: sync
> olcLogLevel: stats
> olcPidFile: /var/symas/run/slapd.pid
> olcArgsFile: /var/symas/run/slapd.args
> olcToolThreads: 1
> olcServerID: 4
>
> dn: cn=schema,cn=config
> objectClass: olcSchemaConfig
> cn: schema
>
> # Read all needed schema from variable in default/main.yml
> include: file:///opt/symas/etc/openldap/schema/core.ldif
> include: file:///opt/symas/etc/openldap/schema/cosine.ldif
> include: file:///opt/symas/etc/openldap/schema/nis.ldif
> include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
> include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif
> include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
>
> # Read all modules from variable in default/main.yml
> dn: cn=module{0},cn=config
> objectClass: olcModuleList
> cn: module{0}
> olcModulePath: /opt/symas/lib/openldap
> olcModuleLoad: back_mdb
> olcModuleLoad: back_monitor
> olcModuleLoad: autoca.la
> olcModuleLoad: otp.la
> olcModuleLoad: argon2.la
> olcModuleLoad: syncprov
> olcModuleLoad: back_monitor
> olcModuleLoad: accesslog.la
>
> dn: olcDatabase={-1}frontend,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcFrontendConfig
> olcDatabase: {-1}frontend
> olcSizeLimit: 500
> olcAccess: {0}to *
> by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> manage
> by
> dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
> manage
> by * break
> olcAccess: {1}to dn="" by * read
> olcAccess: {2}to dn.base="cn=subschema" by * read
> olcPasswordHash: {ARGON2}
>
> dn: olcBackend={0}mdb,cn=config
> objectClass: olcBackendConfig
> olcBackend: {0}mdb
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootDN: cn=admin,cn=config
> olcRootPW:
> {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
> olcAccess: {0}to *
> by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> manage
> by
> dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
> manage
> by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
> by * break
>
> dn: olcDatabase={1}monitor,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {1}monitor
> olcAccess: {0}to dn.subtree="cn=monitor"
> by dn.exact=cn=admin,cn=config read
> by dn.exact=cn=admin,dc=example,dc=net read
>
> dn: olcDatabase={2}mdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcmdbConfig
> olcDatabase: {2}mdb
> olcSuffix: dc=example,dc=net
> olcRootDN: cn=admin,dc=example,dc=net
> olcRootPW:
> {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
> olcSizeLimit: unlimited
> olcTimeLimit: unlimited
> olcDbCheckpoint: 512 30
> olcDbDirectory: /var/symas/openldap-data
> olcDbIndex: default eq
> olcDbIndex: objectClass
> olcDbIndex: entryUUID
> olcDbIndex: entryCSN
> olcDbIndex: cn pres,eq,sub
> olcDbIndex: uid pres,eq,sub
> olcDbIndex: mail pres,eq,sub
> olcDbIndex: sn pres,eq,sub
> olcDbIndex: description pres,eq,sub
> olcDbIndex: title pres,eq,sub
> olcDbIndex: givenName pres,eq,sub
> olcDbMaxSize: 85899345920
> olcAccess: {0} to *
> by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> manage
> by
> dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
> manage
> by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
> by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read
> by * break
> olcAccess: {1}to dn.exact="" by * read
> olcAccess: {2}to dn.base="cn=subschema" by * read
> olcAccess: {3} to attrs=userPassword
> by anonymous auth by self write by * none
> olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net"
> time=unlimited
> size=unlimited
> olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net"
> time=unlimited
> size=unlimited
>
> ------------------
> The "ServerID" is different for every server, every thing else is
> identical.
>
> Then I created a file to change the serverID:
> ------------------
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://ldap01.example.net
> olcServerID: 2 ldap://ldap02.example.net
> olcServerID: 3 ldap://ldap03.example.net
> olcServerID: 4 ldap://ldap04.example.net
> ------------------
>
> and a file to configure the replication:
> ------------------
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> replace: olcSyncRepl
> olcSyncRepl: rid=1
> provider=ldap://ldap01.example.net
> binddn="cn=admin,cn=config"
> bindmethod=simple
> credentials=secret
> searchbase="cn=config"
> type=refreshAndPersist
> retry="5 5 300 20"
> timeout=1
> starttls=yes
> olcSyncRepl: rid=2
> provider=ldap://ldap02.example.net
> binddn="cn=admin,cn=config"
> bindmethod=simple
> credentials=secret
> searchbase="cn=config"
> type=refreshAndPersist
> retry="5 5 300 20"
> timeout=1
> starttls=yes
> olcSyncRepl: rid=3
> provider=ldap://ldap03.example.net
> binddn="cn=admin,cn=config"
> bindmethod=simple
> credentials=secret
> searchbase="cn=config"
> type=refreshAndPersist
> retry="5 5 300 20"
> timeout=1
> starttls=yes
> olcSyncRepl: rid=4
> provider=ldap://ldap04.example.net
> binddn="cn=admin,cn=config"
> bindmethod=simple
> credentials=secret
> searchbase="cn=config"
> type=refreshAndPersist
> retry="5 5 300 20"
> timeout=1
> starttls=yes
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
> ------------------
>
> When I configure the server via Ansible (everything in one playbook) the
> replication of cn=config is not working. When I only do the basic
> configuration via Ansible and then add the change of serverID and then
> the replication of cn=config step by step on every single server:
> -------------
> ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif
> ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
> -------------
> everything is fine. The two files "serverid.ldif" and "repl_config.ldif"
> are the files Ansible created, so the content of the file is the same.
>
> Can it be, that the problem is because Ansible first sets all the
> ServerIDs on all servers and then configure the replication of cn=config
> on all servers?
>
>
> For setting up the configuration I took:
> https://www.openldap.org/devel/admin/replication.html
> Starting at 18.3.3
>
> What I don't understand: Do I realy have to put all Servers in the
> replication, even the server it self? So do I realy have to add on
> Server-01, the Server "server-01, server-02, server-03 ,server-04" to
> the replication? Dosn't it mean that server-01 is replicating to it
> self? If it's correct, can someone explain why? O did I understud
> something wrong on the webpage?
>
> Stefan
>
>
>
>
>
--
Stefan Kania
Landweg 13
25693 St. Michaelisdonn
Signieren jeder E-Mail hilft Spam zu reduzieren und schützt Ihre
Privatsphäre. Ein kostenfreies Zertifikat erhalten Sie unter
https://www.dgn.de/dgncert/index.html
Download der root-Zertifikate: https://www.dgn.de/dgncert/downloads.html
3 years, 5 months
slapd + TLS + SAMBA
by Alessandro Baggi
Hi there. I've another problem with TLS slapd and samba.
For each operation with slapd (ldapsearch -x -ZZ, getent, or samba tls
connection) I receive from slapd:
Aug 2 11:31:05 PDC slapd[1709]: connection_read(23): unable to get TLS
client DN, error=49 id=4
What's the problem? My certificate?
Certificate's creation is:
/usr/lib/ssl/misc/CA.pl -newca
openssl req -newkey rsa:1024 -nodes -keyout key.pem -out newreq.pem
/usr/lib/ssl/misc/CA.pl -sign
Then another problem is when I start slapd on the boot, after slapd
startup, samba , that try to connect to ldap with tls, could not connect
to slapd and give me:
2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_parse_extended_result
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_parse_result
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_msgfree
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] TLS: can't connect: Error in the push function..
[2009/08/01 17:45:15, 0] lib/smbldap.c:smb_ldap_start_tls(596)
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_err2string
Failed to issue the StartTLS instruction: Connect error
This only if I put in slapd.conf TLSClientVerify demand, if I put
TLSClientVerify never, samba connect to it, under TLS without problems.
Another issue is that, if i run slapd on startup and run samba after
login with /etc/init.d/samba start, it makes the connection successfully
without error. In the same script of slapd boot I set an "ldapsearch -x
-ZZ -d -1" I receive:
TLS: can't connect: Error in the push function.. the same of samba.
Anyone has ideas? The problem is in certificates?
thanks in advance
15 years, 10 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by A. Schulze
Am 30.01.2017 um 21:49 schrieb Quanah Gibson-Mount:
> For this testing call, we particularly need folks to test OpenLDAP with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with the 1.1 series).
Hello,
nearly a week I now run that release without any noise.
It's compiled against openssl-1.1.0d and run on a ipv6 only host.
but: it's a small private server, no load, no replication...
One point is worth to mention:
I exposed the server also on port 443 and did a scan with ssllabs.com.
While I'm pretty sure to configure certificates properly,
ssllabs proof, the server deliver not only certificate and intermediate
but also the root as part of the initial SSL handshake.
my TLS settings are:
TLSCertificateFile /path/to/cert.pem
TLSCertificateKeyFile /path/to/key.pem
TLSCACertificateFile /path/to/intermediate.pem
TLSCACertificatePath /path/to/an/empty/directory/
TLSProtocolMin 3.3
$ openssl x509 -noout -in /path/to/cert.pem -issuer -subject
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
subject= /CN=ldap-test.example.org
$openssl x509 -noout -in /path/to/intermediate.pem -issuer -subject
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
a manual test using openssl s_client also proof the root is wrongly delivered:
$ echo | openssl11 s_client -connect ldap-test.example.org:443 -showcerts
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = ldap-test.example.org
verify return:1
---
Certificate chain
...
Ultimate features would be OCSP stapling ( OK, no ldap client currently implement that )
and setting ecdh_curve via SSL_CTX_set1_curves_list
Andreas
8 years, 4 months
Re: memberOf data in new replica servers 2.4.31
by Marco Pizzoli
On Thu, Jun 28, 2012 at 2:09 AM, Todd Stein <todd.stein(a)openx.org> wrote:
> Hi,
>
> I have a provider server and five consumer servers, all of which have the
> memberOf overlay configured:
>
> overlay memberof
> memberof-group-oc groupOfUniqueNames
> memberof-member-ad uniqueMember
> memberof-refint true
> memberof-dangling ignore
>
> syncrepl rid=005
> provider=ldap://<server>:389
> type=refreshAndPersist
> interval=00:00:05:00
> retry="60 10 600 +"
> searchbase="dc=<removed>,dc=<removed>"
> filter="(objectClass=*)"
> scope=sub
> attrs="*"
> schemachecking=off
> starttls=no
> bindmethod=simple
> binddn="cn=replica,dc=<removed>,dc=<removed>"
> credentials=<removed>
>
> When I bring a new replica online, it appears that entries are replicated
> in the order that they were created on the provider server which produces
> many "memberof_value_modify failed err=32" messages in the log, and
> incomplete memberOf data. To get around this, I wrote a script which
> empties all groups prior to replication, and then recreates the memberships
> after the initial replication. This seems to work, but is hardly ideal. Is
> there a "more correct" way of replicating memberOf values without
> manipulating my provider each time I bring up a new consumer?
>
>
I'm facing the same problem with OpenLDAP 2.4.33. Does anyone have any idea
on how to deal with this problem?
Thanks in advance
Marco
12 years, 7 months
Re: TLS problem
by Chris
On 04/02/2013 20:08, Quanah Gibson-Mount wrote:
> --On Monday, February 04, 2013 9:16 AM +0200 Chris
> <chris(a)flamengro.co.za> wrote:
>
>> Thank you for the link. I have downloaded the newest version.
>
> Please keep replies on the list.
>
>> I get the following error message in my messages file when I start slapd
>>
>> Feb 4 09:15:53 ibm-01 slapd[25637]: [INFO] Using /etc/default/slapd for
>> configuration
>> Feb 4 09:15:53 ibm-01 slapd[25642]: [INFO] Launching OpenLDAP
>> configuration test...
>> Feb 4 09:15:53 ibm-01 nslcd[18834]: [a6c6dc] failed to bind to LDAP
>> server ldaps://ibm-01: Can't contact LDAP server
>
>> ldpasearch gives the following results
>>
>> ldapsearch -x -Z -b'dc=flamengro,dc=co,dc=za' uid=izak
>> ldap_start_tls: Protocol error (2)
>> additional info: unsupported extended operation
>
> Are you using startTLS (extended operation) or ldaps? These are two
> different things, and yet it seems you are trying to use both.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
I ask forgiveness for replying to your email, I have just press reply
and did not looked at the address.
What I try to do is login from different machines on the network using
openldap. I have tried to set it up as I have read, maybe I must just go
over it again. Sorry for wasting your time.
12 years, 4 months
How to debug single object syncrepl failure
by Geoff Crompton
Hi,
I have a particular object in my LDAP database that is failing to
replicate (using syncrepl between two slapd's running 2.4.31-1+nmu2 on
Debian Wheezy), despite other objects succeeding to replicate. I'm not
using a 'filter' configuration in my olcSyncrepl configuration that
might exclude this particular object, and I've checked that the binddn
I'm using has permission to see this object all the attributes of the
object that isn't replicating.
The (sanitised) configuration on the consumer is:
dn: olcDatabase={1}hdb,cn=config
olcSyncrepl: {0}rid=104 provider=ldap://producer.example.com
bindmethod=simple
binddn="uid=replicator,ou=pseudoaccounts,dc=example,dc=com"
credentials="..."
searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&
(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off
type=refreshAndPersist
retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
On the producer the overlay configuration for the database being
replicated is:
dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
olcSpNoPresent: TRUE
If I follow the sanitising I did in the above, then the failing object
would be uid=replicationcheck,ou=pseudoaccounts,dc=example,dc=com, and a
successfully replicated object would be
uid=geoffc,ou=People,dc=example,dc=com.
I've stopped slapd on the consumer and deleted all the /var/lib/ldap/
database files, to force re-replication. I get the same symptoms, this
one object doesn't replicate, but lots of other objects do replicate.
Any tips on how to further debug this?
Many thanks,
--
Geoff Crompton, System Administrator
T: +61 (0)3 9348 7138
Trinity College | University of Melbourne | Royal Parade, Parkville |
Victoria 3052, Australia
www.trinity.unimelb.edu.au
10 years, 4 months
Syncrepl and mmr
by Borresen, John - 0442 - MITLL
For some reason the original never made it. Not sure why.
________________________________________
From: Borresen, John - 0442 - MITLL
Sent: Wednesday, January 29, 2014 4:41 PM
To: openldap-technical(a)openldap.org
Subject: Syncrepl -- MMR
All,
Troubleshooting some issues, not to mention to verify that Syncrepl are working as they should, following setting up a 2-way multi-master in our test environment.
1) I noticed that the “userPassword” attributes have all disappeared?!
2) On one of the masters I was able to add it back in (for my account, of course) and added a password (SHA). It has not propagated over to the other master.
-->Here is the slapd.log from server#1:
Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 ACCEPT from IP=155.34.133.44:54271 (IP=0.0.0.0:389)
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 STARTTLS
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 RESULT oid= err=0 text=
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1216 ber write failed.
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 closed (connection lost on write)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 ACCEPT from IP=172.25.91.233:36144 (IP=0.0.0.0:389)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 STARTTLS
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 RESULT oid= err=0 text=
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=3 UNBIND
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 closed
Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 ACCEPT from IP=155.34.133.44:54273 (IP=0.0.0.0:389)
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 STARTTLS
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 RESULT oid= err=0 text=
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1218 ber write failed.
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 closed (connection lost on write)
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH attr=hasSubordinates objectClass
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SEARCH RESULT tag=101 err=0 nentries=36 text=
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH attr=*
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 ACCEPT from IP=172.25.91.233:36146 (IP=0.0.0.0:389)
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 STARTTLS
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 RESULT oid= err=0 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=3 UNBIND
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 closed
Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 ACCEPT from IP=155.34.133.44:54275 (IP=0.0.0.0:389)
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 STARTTLS
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 RESULT oid= err=0 text=
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1220 ber write failed.
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 closed (connection lost on write)
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 fd=31 ACCEPT from IP=172.25.91.233:36149 (IP=0.0.0.0:389)
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 STARTTLS
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 RESULT oid= err=0 text=
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=3 UNBIND
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 closed
Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 ACCEPT from IP=155.34.133.44:54277 (IP=0.0.0.0:389)
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 STARTTLS
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 RESULT oid= err=0 text=
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=3 UNBIND
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 closed
-->Here is the log from the other server, same time frame:
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 ACCEPT from IP=172.25.91.233:41849 (IP=0.0.0.0:389)
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 STARTTLS
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 RESULT oid= err=0 text=
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3232 ber write failed.
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 closed (connection lost on write)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 ACCEPT from IP=155.34.133.44:38468 (IP=0.0.0.0:389)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 STARTTLS
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 RESULT oid= err=0 text=
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:10:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3233 ber write failed.
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 closed (connection lost on write)
Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 ACCEPT from IP=172.25.91.233:41852 (IP=0.0.0.0:389)
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 STARTTLS
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 RESULT oid= err=0 text=
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3234 ber write failed.
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 closed (connection lost on write)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 ACCEPT from IP=155.34.133.44:38470 (IP=0.0.0.0:389)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 STARTTLS
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 RESULT oid= err=0 text=
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:11:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3235 ber write failed.
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 closed (connection lost on write)
Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH attr=*
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH attr=hasSubordinates objectClass
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SEARCH RESULT tag=101 err=4 nentries=500 text=
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH attr=*
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 ACCEPT from IP=172.25.91.233:41854 (IP=0.0.0.0:389)
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 STARTTLS
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 RESULT oid= err=0 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3236 ber write failed.
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 closed (connection lost on write)
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH base="dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH attr=hasSubordinates objectClass
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SEARCH RESULT tag=101 err=0 nentries=15 text=
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH base="dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH attr=*
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH base="ou=Users,dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH attr=hasSubordinates objectClass
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SEARCH RESULT tag=101 err=0 nentries=123 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 ACCEPT from IP=155.34.133.44:38472 (IP=0.0.0.0:389)
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH base="uid=daveb,ou=Users,dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH attr=*
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 STARTTLS
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 RESULT oid= err=0 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=3 UNBIND
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 closed
Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 ACCEPT from IP=172.25.91.233:41857 (IP=0.0.0.0:389)
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 STARTTLS
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 RESULT oid= err=0 text=
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=3 UNBIND
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 closed
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 ACCEPT from IP=155.34.133.44:38474 (IP=0.0.0.0:389)
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 STARTTLS
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 RESULT oid= err=0 text=
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=3 UNBIND
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 closed
Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
-->When trying to get a copy of the olcDatabase={0}bdb,cn=config from server#1, I receive the following:
# slapcat -s olcDatabase=\{1\}bdb,cn=config
52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"
52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: _____________________________________=
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 5a87b5f1-c445-4e0e-ba97-6d2d63093704
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcMirrorMode: TRUE
entryCSN: 20140129193518.096476Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129193518Z
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 04afe1bf-40c7-425a-8b25-74f8687323fc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180447Z
entryCSN: 20140129180447.701059Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180447Z
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 54b5fa00-8244-41d3-923d-0743a10bf192
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180903Z
entryCSN: 20140129180903.479192Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180903Z
-->From server#2:
# slapcat -s olcDatabase=\{1\}bdb,cn=config
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: ________________________________=
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}#set_cachesize 0 268435456 1
olcDbConfig: {17}set_cachesize 0 2147483648 1
olcDbConfig: {18}
olcDbConfig: {19}# Data Directory
olcDbConfig: {20}#set_data_dir db
olcDbConfig: {21}
olcDbConfig: {22}# Archive/deletion
olcDbConfig: {23}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {24}
olcDbConfig: {25}# Transaction Log settings
olcDbConfig: {26}set_lg_regionmax 262144
olcDbConfig: {27}set_lg_bsize 2097152
olcDbConfig: {28}#set_lg_dir logs
olcDbConfig: {29}
olcDbConfig: {30}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezMxfSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: mail eq,sub
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 94ff450b-aa70-4507-9ca6-51cdd740ea3e
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by * none
olcAccess: {1}to * by * read
olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcMirrorMode: TRUE
entryCSN: 20140129193241.088847Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129193241Z
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {0}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 6e4e1508-5eb9-4372-bbd1-813f859b0acc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182321Z
entryCSN: 20140129182321.004272Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182321Z
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9108e0db-ba9e-4b40-b743-4016c61582bc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129183014Z
entryCSN: 20140129183014.073365Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129183014Z
Thank you in advance, let me know if any expanding information is needed.
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Surveillance Systems Group
244 Wood St
Lexington, MA 02420
email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>
11 years, 4 months
Re: Syncrepl partial replication based on attribute problem
by Jeffrey Crawford
Ok I think I got this to work I didn't add a filter to the syncrepl
parameter so I'm using ACL's as before, however I changed the acls to
allow the replica account access to the attributes entry and entryUUID
only on every item in the directory, now setting attributes to values
so that they no longer match the access to the rest of the acls seem
to do what I wan't however I'm not quite sure how. so in short the
provider looks something like this:
olcAccess: to dn.subtree="dc=example,dc=org"
attrs=entry,entryUUID
by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
by * none break
olcAccess: to dn.subtree="dc=example,dc=org"
filter="(replicateMe=TRUE)"
attrs=@inetOrgPerson,@posixAccount,entryCSN,contextCSN,createTimestamp,modifyTimestamp,structuralObjectClass
by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
by * none break
And the replicas are configured as so:
dn: olcDatabase={1}hdb,cn=config
changeType: modify
replace: olcSyncrepl
olcSyncrepl: rid=1
provider=ldap://ldap-!!!!ENV!!!!-1.example.org:1389/
starttls=critical
tls_reqcert=never
bindmethod=simple
retry="60 10 900 92 86400 3"
binddn="cn=replica,ou=admins,dc=example,dc=org"
credentials=!!!!PW!!!!
schemachecking=off
searchbase="dc=example,dc=org"
type=refreshAndPersist
olcSyncrepl: rid=2
provider=ldap://ldap-!!!!ENV!!!!-2.example.org:1389/
starttls=critical
tls_reqcert=never
bindmethod=simple
retry="60 10 900 92 86400 3"
binddn="cn=replica,ou=admins,dc=example,dc=org"
credentials=!!!!PW!!!!
schemachecking=off
searchbase="dc=example,dc=org"
type=refreshAndPersist
now the following will add a record to the replica:
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: TRUE
And the following will take it away (delete):
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: FALSE
However I don't know enough about the underlying code to be sure the
following is working as designed. Meaning I don't want to be relying
on a bug that might get fixed later.
Thanks
Jeffrey
access:
On Fri, Jun 1, 2012 at 9:26 AM, Jeffrey Crawford <jeffreyc(a)ucsc.edu> wrote:
>
> Humm and taking this one step further I'm guessing that the replication account probably needs to see at least the entryUUID and entryCSN for all accounts to make sure that it can see the records it needs to delete. Okay at least I have some direction to go on now.
>
> Jeffrey
>
>
> On Fri, Jun 1, 2012 at 9:06 AM, Nick Milas <nick(a)eurobjects.com> wrote:
>>
>> On 1/6/2012 8:54 πμ, Jeffrey Crawford wrote:
>>
>>> Are you saying that syncprov looks at the account that is bound and sends deletes if a record would become invisible after a modification?
>>
>>
>> I understand the opposite: syncprov will only send add/delete message based on base/scope/filter and not on ACL-visibility. So in essence Howard says that ACL-based filtering in replication does not result in proper results to consumers.
>>
>> This is tricky! (I didn't know either.) It means that we should *not* design our replication based on ACL-filtering (which, unfortunately, we have done too), but, on the contrary, that we should design our DIT so that it can cover our replication needs based on consumer base/scope/filter configuration, and we should design/adapt our ACLs with the above rule in mind.
>>
>> Please confirm the above thoughts.
>>
>> Thanks,
>> Nick
>
>
>
>
> --
> I fly because it releases my mind from the tyranny of petty things . . .
>
> — Antoine de Saint-Exupéry
>
> Jeffrey E. Crawford
> ITS Application Administrator (IDM)
> 831-459-4365
> jeffreyc(a)ucsc.edu
--
I fly because it releases my mind from the tyranny of petty things . . .
— Antoine de Saint-Exupéry
Jeffrey E. Crawford
ITS Application Administrator (IDM)
831-459-4365
jeffreyc(a)ucsc.edu
13 years