Re: Openldap 2.3 syncrepl filter problem
by Jonathan Clarke
Hi,
On 25/06/2009 15:56, Lanfeust troy wrote:
> Hi list,
>
> In configuration of provider and consumer server with syncrepl is
> possible to modify the replication filter for add new user in replica.
>
> In fisrt time the replica is :
>
> syncrepl rid=123
> provider=ldap://rh-test3.kvm.rla:389
> type=refreshOnly
> interval=00:00:01:00
> retry="30 10 600 20"
> searchbase="dc=local"
> filter="(|(objectClass=sambaGroupMapping)(uid=user1))"
> scope=sub
> schemachecking=off
> bindmethod=simple
> binddn="uid=syncrepl,ou=sysusers,dc=local"
> credentials=pwdsyncrepl
> # BEGIN Session TLS
> starttls="critical"
> tls_cacert=__CACERTFILE__
> # End Session TLS
Be careful of this syntax. Every line beginning with white space is
considered a continuation of the previous line.
So when this configuration file is read, it appears as one long line
starting with syncrepl... and anything after a "#" is a comment. So your
tls options are not being used, here.
> When start the replica server it doing an ldapsearch and retrieve my
> data in replica.
>
> So now we modify the filter as the following :
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
>
> Now when the replica doing the ldapsearch request it do with the new
> filter but returning numentrie to 0
> like this in the log of master LDAP server:
>
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 BIND
> dn="uid=syncrepl,ou=sysusers,dc=local" mech=SIMPLE ssf=0
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 RESULT tag=97 err=0
> text=
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH base="dc=local"
> scope=2 deref=0
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH attr=* +
> Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SEARCH RESULT
> tag=101 err=0 *nentries=0* text=
>
> And when i do ldapsearch manually :
>
> ldapsearch -x -b dc=local -H ldap://rh-test3.kvm.rla
> "(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
>
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 BIND dn="" method=128
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 RESULT tag=97 err=0
> text=
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SRCH
> base="dc=local" scope=2 deref=0
> filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
> Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SEARCH RESULT
> tag=101 err=0 *nentries=13* text=
>
>
> I don't understand why my new user is not sync !!
The reason for this is that syncrepl is state-based. This means that
when you restart your replica server, it only queries the master for
changes since the last know replication. If the object uid=user2 had
been changed since then, it would have been replicated.
If you change your syncrepl configuration, you should reset this status
by launching slapd with "-c rid=123". This will cause it to start
syncrepl from scratch, and will replicate all entries.
Regards,
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan(a)phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
15 years, 11 months
Re: Syncrepl over TLS for mirrormode
by Chris Jacobs
Apologies for taking a while (and top posting - blackberry).
1)I setup the mirror-mode servers behind a VIP (named ldapmaster1 & 2). VIP hosted on an F5 BigIP - which doesn't load balance StartTLS - which was fine by us - all 389 connections are insecure and all 686 (?) are secure.
2) I created a cert via a CA trusted on all my client machines with:
2.A) Subject: ldap-vip.[domain]
2.B) subjectAltName(s): ldapmaster1.[domain], ldapmaster2.[domain], ldap-vip.[domain]
(Subject included in alt name list as some clients - like firefox - ignore the subject if alt names exist - dumb IMNSHO.)
Then the servers use the same cert to sync w/ each other as the clients use to connect to the VIP (or if needed, directly to the ldapmaster servers).
The subjectAltName part of a cert is the 'tricky' part I think you're missing knowledge of.
A wildcard cert works too, but then it'd be valid for any host *.[domain]. Not the most secure setup.
- chris
Chris Jacobs, Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing and Product Development | Aptimus, Inc.
2001 6th Ave | Suite 3200 | Seattle, WA 98121
direct 206.839.8245 | cell 206.601.3256 | fax 206.839.8106
email chris.jacobs(a)apollogrp.edu
________________________________
From: Daniel Qian <daniel(a)up247solution.com>
To: Chris Jacobs
Cc: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org>
Sent: Fri Aug 26 13:35:10 2011
Subject: Re: Syncrepl over TLS for mirrormode
Still not sure how you did it. Are you saying you set the same certificate in slapd and played with DNS to make it look like only one server(URL) to everyone?
Thanks,
Daniel
On 11-08-26 4:03 PM, Chris Jacobs wrote:
What I did:
* setup servers behind VIP
* obtain cert with primary name of vip DNS w/ secondary names of the servers.
That way, the servers can sync/tryst each other via the same cert used by clients.
Note: some clients (lookin at you Firefox) won't use the primary name if subjectaltname exists - so include primary name in the alt names JIC.
- chris
Chris Jacobs, Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing and Product Development� |� Aptimus, Inc.
2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
email chris.jacobs(a)apollogrp.edu<mailto:chris.jacobs@apollogrp.edu>
________________________________
From: openldap-technical-bounces(a)OpenLDAP.org<mailto:openldap-technical-bounces@OpenLDAP.org> <openldap-technical-bounces(a)OpenLDAP.org><mailto:openldap-technical-bounces@OpenLDAP.org>
To: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> <openldap-technical(a)openldap.org><mailto:openldap-technical@openldap.org>
Sent: Fri Aug 26 12:49:04 2011
Subject: Syncrepl over TLS for mirrormode
From the openldap website the two nodes have to use different URLs like below:
syncrepl rid=001
provider=ldap://ldap-sid2.example.com
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"
credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
and
syncrepl rid=001
provider=ldap://ldap-sid1.example.com
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"
credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
I can set two different certificates so that TLS is fine for sync between the two nodes. However we will have regular Ldap client access these two nodes behind a loadbalancer over TLS too. Obviously the client can't connect with ldap-sid2.example.com, nor with ldap-sid1.example.com. So what is the solution to this scenario? Setup a pool of consumers with same hostname?
Thanks,
Daniel
________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
________________________________
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
13 years, 9 months
Re: openLDAP upgrate
by Scott Classen
I recently upgrade from source and this is my procedure. Your's will certainly be different, but it gives you the basic steps.
First check to make sure we have an LDIF backup of entire LDAP database.
1. install new openldap
cd /usr/local/src
wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.42.tgz
tar zxvf
cd openldap-2.4.42
./configure --enable-bdb=no --enable-hdb=no --enable-mdb --with-tls=openssl --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-modules --enable-cleartext --enable-overlays --enable-accesslog --enable-auditlog --with-threads --enable-shared --enable-ldap --enable-monitor --enable-deref --enable-slapd --enable-ppolicy --enable-memberof
make depend
make
make test
make install <-- be careful after this point, as a "slapd restart" will then use the new code. Must complete step 2 before restarting slapd.
2. copy our custom schema files to new scheme directory
cd /usr/local/etc/openldap
cp custom_schema_files/* schema/
3. start new slapd
/etc/init.d/slapd stop *** to stop currently running old version***
/etc/init.d/slapd start *** new version***
Aug 17 13:23:13 slapd[3881]: slapd shutdown: waiting for 0 operations/tasks to finish
Aug 17 13:23:13 slapd[3881]: slapd stopped.
Aug 17 13:23:17 slapd[4647]: @(#) $OpenLDAP: slapd 2.4.42 (Aug 17 2015 12:47:46) $#012#011root@:/usr/local/src/openldap-2.4.42/servers/slapd
Aug 17 13:23:29 slapd[4648]: slapd starting
Aug 17 13:23:34 slapd[4648]: conn=1000 fd=10 ACCEPT from IP=192.168.1.104:33256 (IP=0.0.0.0:389)
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 STARTTLS
Aug 17 13:23:34 slapd[4648]: conn=1000 op=0 RESULT oid= err=0 text=
Aug 17 13:23:34 slapd[4648]: conn=1000 fd=10 TLS established tls_ssf=256 ssf=256
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 BIND dn="uid" method=128
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 BIND dn="uid" mech=SIMPLE ssf=0
Aug 17 13:23:34 slapd[4648]: conn=1000 op=1 RESULT tag=97 err=0 text=
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SRCH base="ou=People," scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=))"
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SRCH attr=userPassword cn gidNumber uidNumber loginShell objectClass gecos uid homeDirectory
Aug 17 13:23:34 slapd[4648]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OK it appears that OpenLDAP 2.4.42 is running.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
###########################################################
#################### BACK OUT PLAN ####################
###########################################################
if things go badly revert by going to previous /usr/local/src/openldap directory and doing a
make install
/usr/local/src/openldap-2.4.xxx
check schema files and restart slapd
> On Aug 27, 2015, at 6:47 AM, mdii <mdii.alias(a)gmail.com> wrote:
>
> Hi all,
>
> I'm starting as an openLDAP administrator, and here in my company they are running the openLDAP 2.4.35.
>
> - I found this avec la commande ldapsearch -VV
>
> I want to upgrade to the letest version available (2.4.42), how should I procede ?
>
> I read that I just need to download the new package, stop the server, install the new version and then restart the server, is that all?
>
>
> Thanks in advance for your help,
> Marc
9 years, 9 months
Re: top-level data entries not replicating, 2.4.15
by Jonathan Clarke
On 20/08/2009 14:39, Brian Neu wrote:
> Forgive me if pasting here is bad etiquette.
>
>
> <consumer slapd.conf>
>
> include /etc/openldap/schema/corba.schema
> include /etc/openldap/schema/core.schema
> include /etc/openldap/schema/cosine.schema
> include /etc/openldap/schema/duaconf.schema
> include /etc/openldap/schema/dyngroup.schema
> include /etc/openldap/schema/inetorgperson.schema
> include /etc/openldap/schema/java.schema
> include /etc/openldap/schema/misc.schema
> include /etc/openldap/schema/nis.schema
> include /etc/openldap/schema/openldap.schema
> include /etc/openldap/schema/ppolicy.schema
> include /etc/openldap/schema/collective.schema
> include /etc/openldap/schema/samba.schema
>
> allow bind_v2
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
>
> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
> TLSCertificateFile /etc/openldap/keys/victory3cert.pem
> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
>
> database hdb
> suffix "dc=srg,dc=com"
> checkpoint 1024 15
> rootdn "cn=Manager,dc=srg,dc=com"
>
> rootpw {MD5}blah
>
> directory /var/lib/ldap
>
> index objectClass eq,pres
> index ou,cn,mail,surname,givenname eq,pres,sub
> index uidNumber,gidNumber,loginShell eq,pres
> index uid,memberUid eq,pres,sub
> index nisMapName,nisMapEntry eq,pres,sub
>
> syncrepl rid=0
> provider=ldap://victory2.srg.com:389
> bindmethod=simple
> starttls=critical
> binddn="cn=replicator,dc=srg,dc=com"
> credentials=blah
> searchbase="dc=srg,dc=com"
> logbase="cn=accesslog"
> schemachecking=on
> type=refreshAndPersist
> retry="60 +"
> syncdata=accesslog
I don't see anything wrong with this - although I'm not very familiar
with accesslog configuration.
Does the "cn=replicator,dc=srg,dc=com" have full access on the provider
to read necessary data?
> updateref ldaps://victory2.srg.com
>
> database monitor
>
> access to *
> by dn.exact="cn=Manager,dc=srg,dc=com" write
> by * none
>
> </consumer slapd.conf>
>
>
> --- On Thu, 8/20/09, Jonathan Clarke<jonathan(a)phillipoux.net> wrote:
>
>> From: Jonathan Clarke<jonathan(a)phillipoux.net>
>> Subject: Re: top-level data entries not replicating, 2.4.15
>> To: "Brian Neu"<proclivity76(a)yahoo.com>
>> Cc: openldap-technical(a)openldap.org
>> Date: Thursday, August 20, 2009, 8:02 AM
>> On 19/08/2009 19:29, Brian Neu
>> wrote:
>>> Even with no logfilter on the consumer,
>>>
>> cn=replicator,dc=domain,dc=com&
>>>
>> sambaDomainName=SRG,dc=domain,dc=com
>>>
>>> don't replicate, even after wiping the database and
>> restarting. Everything else seems to replicate fine.
>>>
>>> How do I get top-level data entries to replicate?
>>
>> This really depends on your syncrepl configuration on the
>> consumer.
>> If you provide it here, maybe we can take a look.
>>
>> Aside from that, the latest version, 2.4.17, contains a few
>> fixes that
>> might help with this problem.
>>
>> Jonathan
>>
15 years, 9 months
Re: TLS CA Chain Problem
by Iruwen
Quanah Gibson-Mount schrieb:
> --On Monday, October 12, 2009 11:18 AM -0700 Quanah Gibson-Mount
> <quanah(a)zimbra.com> wrote:
>
>> --On Monday, October 12, 2009 3:02 PM +0200 Iruwen <iruwen(a)gmx.net>
>> wrote:
>>
>>
>>> Seems like the ca-bundle wouldn't be used at all, does slapd expect a
>>> different format or something?
>>>
>>> Maybe someone could shed some light on this for me, thanks a lot in
>>> advance.
>>
>> You need to provide the full train of trust when using Comodo certs.
>
> s/train/chain/ :P
So... I'd have to change what exactly? ;)
I created the ca-bundle following the information this page:
https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarti…
And the format generally seems to be correct since it works for HTTPS
(and SMTP with TLS in postfix, just tried that too).
HTTPS:
office:/etc/ssl/private# openssl s_client -connect localhost:443
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
SMTP with TLS:
office:/etc/ssl/private# openssl s_client -connect localhost:25
-starttls smtp
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
External CA Root
But LDAPS:
office:/etc/ssl/private# openssl s_client -connect localhost:636
CONNECTED(00000003)
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=27:certificate not trusted
verify return:1
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.de
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA
Limited/CN=PositiveSSL CA
I don't get it :(
15 years, 8 months
LDAP password information update failed: Insufficient access
by Roberto Gherardi de Candei
Hi i'm a newbie
doesn't succeed has change the password of the on maturity consumer of the
password
help where is my error
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/certs/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/certs/slapdkey.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#access to dn.subtree="ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=adminU,ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=anonymous,dc=ldap,dc=inail.dc=it" read
# by self write
# by anonymous auth
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=ldap,dc=inail,dc=it"
rootdn "cn=admin,dc=ldap,dc=inail,dc=it"
#rootpw {SSHA}PU4cboMpOsn7YBWDaP9xwRdP82k5O7gV
rootpw {SSHA}mcFkKPNevo77jAq0+MdWNmX7F7roGk+v
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
thank's
--
RGdC
--
RGdC
15 years, 7 months
Re: Problem getting monitor backend and syncrepl overlay to work
by Christian Manal
DeMoNs(a)web.de schrieb:
> Hi all,
>
> i have a problem getting openldap to run monitor backend AND syncrepl
> overlay.
> i'm running freebsd-7.2-release-p6 in combination with
> openldap-server-2.4.19 with sasl support compiled in.
>
> i use the following slapd config:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/misc.schema
> include /usr/local/etc/openldap/schema/ldapns.schema
> include /usr/local/etc/openldap/schema/radius.schema
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
> logfile /var/log/slapd.log
>
> password-hash {SSHA}
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
> moduleload back_monitor
>
> access to dn.base="" by * read
> access to dn.base="cn=Subschema" by * read
> access to *
> by ssf=128 dn="cn=admin,dc=example,dc=de" write
> by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
> by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
> by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
> by anonymous auth
> by * none
> access to attrs=userPassword
> by self write
> by anonymous auth
> by * none
>
> database bdb
> suffix "dc=example,dc=de"
> rootdn "dc=example,dc=de"
> directory /var/db/openldap-data
> index objectClass,entryCSN,entryUUID eq
> index uid pres,eq,sub
> index memberUID eq
> index uidNumber,gidNumber eq
> index host eq
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
>
> access to dn.subtree="cn=Monitor"
> by dn="cn=nssadmin,dc=example,dc=de"
> by * none
>
> syncrepl rid=041
> provider=ldap://ldap-master.example.de
> type=refreshOnly
> interval=00:00:35:00
> searchbase="dc=example,dc=de"
> schemachecking=off
> bindmethod=simple
> starttls=yes
> binddn="cn=syncuser,dc=example,dc=de"
> credentials="strongsecretpassword"
>
> TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
> TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
>
> loglevel 256
>
> now, when i run slaptest i receive following error:
>
> /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
> support operations required for syncrepl
> slaptest: bad configuration file!
>
> Line 59 corresponds to the credentials option in the synrepl statement.
> i can't figure out whats wrong, so if anyone can point me in the right
> direction that would be really helpful.
>
> thanks in advance,
> david
>
Hi David,
from the slapd.conf(5) manpage:
The slapd.conf file consists of a series of global confi-
guration options that apply to slapd as a whole (including
all backends), followed by zero or more database backend
definitions that contain information specific to a backend
instance.
Which means that your syncrepl stuff is placed in the back-monitor
specific part of the configuration. Put the syncrepl part before the
monitor definition and behind the bdb definition.
Regards,
Christian Manal
15 years, 3 months
Re: Problem getting monitor backend and syncrepl overlay to work
by Pierangelo Masarati
DeMoNs(a)web.de wrote:
> Hi all,
>
> i have a problem getting openldap to run monitor backend AND syncrepl
> overlay.
> i'm running freebsd-7.2-release-p6 in combination with
> openldap-server-2.4.19 with sasl support compiled in.
>
> i use the following slapd config:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/misc.schema
> include /usr/local/etc/openldap/schema/ldapns.schema
> include /usr/local/etc/openldap/schema/radius.schema
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
> logfile /var/log/slapd.log
>
> password-hash {SSHA}
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
> moduleload back_monitor
>
> access to dn.base="" by * read
> access to dn.base="cn=Subschema" by * read
> access to *
> by ssf=128 dn="cn=admin,dc=example,dc=de" write
> by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
> by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
> by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
> by anonymous auth
> by * none
> access to attrs=userPassword
> by self write
> by anonymous auth
> by * none
>
> database bdb
> suffix "dc=example,dc=de"
> rootdn "dc=example,dc=de"
> directory /var/db/openldap-data
> index objectClass,entryCSN,entryUUID eq
> index uid pres,eq,sub
> index memberUID eq
> index uidNumber,gidNumber eq
> index host eq
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
>
> access to dn.subtree="cn=Monitor"
> by dn="cn=nssadmin,dc=example,dc=de"
> by * none
>
> syncrepl rid=041
> provider=ldap://ldap-master.example.de
> type=refreshOnly
> interval=00:00:35:00
> searchbase="dc=example,dc=de"
> schemachecking=off
> bindmethod=simple
> starttls=yes
> binddn="cn=syncuser,dc=example,dc=de"
> credentials="strongsecretpassword"
>
> TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
> TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
>
> loglevel 256
>
> now, when i run slaptest i receive following error:
>
> /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
> support operations required for syncrepl
> slaptest: bad configuration file!
>
> Line 59 corresponds to the credentials option in the synrepl statement.
> i can't figure out whats wrong, so if anyone can point me in the right
> direction that would be really helpful.
"Line 59" means the whole statement ending at line 59, so in general the
error can be anywhere in the statement. In this case, the error is the
statement itself. As the error message is saying, back-monitor is
missing some essential function that is required by syncrepl (I bet
bi_op_add()). What's puzzling me is: back-monitor is (almost)
read-only, and contains mostly dynamically generated information on the
state of a server; what's the purpose of replicating it? Your
configuration makes no sense.
p.
15 years, 3 months
Syncrepl and MMR
by Borresen, John - 0442 - MITLL
All,
Ok, grasping at straws here. This is the cn=config for mm-server1 as of yesterday.
mm-server1:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 1b256f1e-2f15-4538-8a6f-5b021d015e35
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211613.134974Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211613Z
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: 1191cf8f-8d46-4f2e-8aba-e65537210029
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175231Z
entryCSN: 20140129175429.232704Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129175429Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 77451682-9629-4753-9a80-5cc0e69a7482
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: d7f25d3b-7ad1-4625-a577-a23a22b5494d
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
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
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,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=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,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
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" read by * none
olcAccess: {1}to * by * read
entryCSN: 20140203200931.503493Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203200931Z
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
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: ff63820b-fbe4-4a65-8c00-99e2cc28fca5
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175923Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190415.581904Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190415Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9246709d-7a9b-41f3-bca8-f665add4e4f2
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180331Z
entryCSN: 20140129180331.702641Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180331Z
mm-server2:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 84a58742-a1ce-4714-a743-14daf3f40c75
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211906.564734Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211906Z
contextCSN: 20140206183618.370299Z#000000#002#000000
contextCSN: 20140121211615.993780Z#000000#004#000000
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: ab2c7f52-e10f-4233-aa17-ac8b051defcf
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
entryCSN: 20140129182642.147840Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182642Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 46ec808c-285f-442f-8c70-d5bb8c2d39de
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 4354a8b6-8a36-4804-81f8-14a8550aef74
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 644d3984-d125-446e-aae2-1ddc541f4661
creatorsName: cn=admin,cn=config
createTimestamp: 20140121191314Z
entryCSN: 20140121191314.076259Z#000000#004#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140121191314Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
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
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,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=ldap://mm-server2.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,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
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=r
eplicator,ou=Admins,dc=example,dc=ldap" read
olcAccess: {1}to * by * read
entryCSN: 20140206183618.370299Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140206183618Z
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
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: 9b42a346-de9b-42d5-8a3b-3167f80d4b01
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190210.968231Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190210Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 0366206b-4295-4463-952c-0b233646c24d
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182831Z
entryCSN: 20140129182831.866738Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182831Z
dn: olcDatabase={3}monitor,cn=config
objectClass: olcDatabaseConfig
olcAccess: {0}to dn.children="cn=monitor" by dn.children="cn=admin,cn=config"
read
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig
entryUUID: 691d6dfc-82af-4e12-8f03-be93d5d5436b
creatorsName: cn=admin,cn=config
createTimestamp: 20140114170424Z
entryCSN: 20140114170424.436842Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140114170424Z
olcDatabase: {3}monitor
An attempt IS being made between mm-server1 and mm-server2:
Log output from mm-server1:
<= ldap_dn2bv(cn=accesslog)=0
52fb7a31 SRCH "cn=accesslog" 2 052fb7a31 0 0 0
52fb7a31 filter: (objectClass=*)
52fb7a31 attrs:52fb7a31 reqDN52fb7a31 reqType52fb7a31 reqMod52fb7a31 reqNewRDN52fb7a31 reqDeleteOldRDN52fb7a31 reqNewSuperior52fb7a31 entryCSN52fb7a31
52fb7a31 base_candidates: base: "cn=accesslog" (0x00000001)
52fb7a31 send_ldap_result: err=0 matched="" text=""
52fb7a31 send_ldap_result: err=0 matched="" text=""
52fb7a31 connection_get(36)
52fb7a6d connection_get(36)
=> ldap_bv2dn(cn=ldapadmin,dc=example,dc=ldap,0)
<= ldap_bv2dn(cn=ldapadmin,dc=example,dc=ldap)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldapadmin,dc=example,dc=ldap)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldapadmin,dc=example,dc=ldap)=0
Log output from mm-server2:
52fb7a0f attrs:52fb7a0f *52fb7a0f
52fb7a0f base_candidates: base: "cn=role2,ou=sudoers,dc=example,dc=ldap" (0x00000271)
52fb7a0f send_ldap_result: err=0 matched="" text=""
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7a31 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7a31 do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7a6d do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7a6d do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7aa9 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7aa9 do_syncrepl: rid=001 rc -1 retrying
ldap_build_search_req ATTRS: reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
52fb7ae5 do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
52fb7ae5 do_syncrepl: rid=001 rc -1 retrying
Thanks in advance...
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, 3 months
Re: Problem with new writetimeout
by Quanah Gibson-Mount
--On Monday, July 20, 2009 1:37 PM +0200 Christian Manal
<moenoel(a)informatik.uni-bremen.de> wrote:
> Hi everyone,
>
> I have noticed a problem regarding the new writetimeout feature in
> OpenLDAP 2.4.17. I have a setup with one master and four replicas running
> on Solaris 10, using the hdb-backend with BDB 4.4 from the opencsw
> repository. Clients are Sun, Linux and Mac boxes in every possible
> variation.
>
> I updated my servers last Friday from version 2.4.15 and now some
> cronjobs accessing the directory were sporadically failing over the
> weekend.
>
> I monitored the server logs (log level 'stats') while running the
> involved scripts repeatedly and got something like the following results
> after fail-runs on all servers:
> (IPs and DNs altered)
>
>> Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug]
>> conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) Jul
>> 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479
>> op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 20 11:42:43 ldapserver
>> slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS Jul 20
>> 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479
>> op=0 RESULT oid= err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID
>> 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256
>> Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug]
>> conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com"
>> method=128 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343
>> local4.debug] conn=12479 op=1 BIND
>> dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 20
>> 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479
>> op=1 RESULT tag=97 err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]:
>> [ID 469902 local4.debug] conn=12479 op=2 SRCH
>> base="ou=people,dc=example,dc=com" scope=2 deref=2
>> filter="(objectClass=posixAccount)" Jul 20 11:42:43 ldapserver
>> slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid
>> userpassword uidnumber gidnumber gecos homedirectory loginshell Jul 20
>> 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479
>> fd=79 closed (writetimeout)
>
>
> I don't have the writetimeout keyword configured on any of the boxes and
> the affected script doesn't do any writes anyway. Also, the problem only
> seems to arise if the client takes a while to process a search result.
> The failing scripts are Net::LDAP based Perl scripts running on some old
> SPARC boxes, so it took them up to half a minute and more to complete.
>
> Setting writetimeout to a high enough value seems solve the problem, but
> referring to the docs, this shouldn't happen with the keyword unset or
> set to 0.
>
> Is this a bug or did I miss something? Did anyone else encounter this so
> far?
File an ITS:
<http://www.openldap.org/its/> and include your server config.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 10 months