(ITS#7840) bug with initial/seed syncrepl
by Jephte.Clain＠univ-reunion.fr
Full_Name: Jephte CLAIN
Version: 2.4.39
OS: Debian 6 64bits
URL: http://jclain.fr/openldap-its/
Submission from: (NULL) (93.176.62.129)
I have scripts to test several replication scenarii, that setup the LDAP
environment then allow me to play with parameters as I see fit.
I believe that there is a bug with the "seed replication" that allow one to
build an exact clone of a master with minimal configuration on the slave side.
note: the tests below require 2 VMs, or running the two slapd instances in
chroots, because a clone replica requires the data files to be in the same
path...
I attach two scripts to replicate the problem. they require root (they uses
chroots)
this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed
in the scripts below
use jclain-20140419-0start.sh to:
- create a ldap server to be served on ldap://localhost:3890
- start the master in chroot
(the logs are in /jclain-slapd-test/master.data/slapd.log)
- create a seed ldap replica to be served on ldap://localhost:3891 with
ldap://localhost:3890 as the provider
- start it in chroot with option -c rid=0
(the logs are in /jclain-slapd-test/slave.data/slapd.log)
use jclain-20140419-1stop.sh to:
- stop the servers
- umount the chroots
If I understand the manual correctly, after 0start.sh, the replica should be
identical to the master thanks to -c rid=0
BUT, the log on the replica says:
534d5481 dn_callback : new entry is older than ours cn=config ours
20140415154713.807278Z#000000#000#000000, new
20140415154704.888204Z#000000#000#000000
and indeed, the seed entries are NOT overwritten
I have to "touch" them on the master to force the replication.
I have uploaded the scripts to http://jclain.fr/openldap-its/
thanks in advance
7 years, 6 months
Re: (ITS#7839) openldap libdb5 support
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Further footnote - this is why we recommend nss-pam-ldapd or nssov, which
> fully isolates applications from the underlying nss/pam libraries. And why we
> don't recommend SSSD. A shame they had to go off and reinvent the wheel
> without actually fixing its underlying problems. Some people never learn.
Hmm. AFAICT sssd also isolates from the nss/pam libraries.
The pam_sss and libnss_sss modules also communicate with sssd over a Unix
domain socket just like the other demons and accompanying modules you prefer do.
Ciao, Michael.
7 years, 6 months
Re: (ITS#7839) openldap libdb5 support
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> --On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote:
>
>> Full_Name: Marc Schildt
>> Version: 2.4.24 - 2.4.39
>
> The OpenLDAP project is in no way associated with the utterly broken builds
> provided by Debian. I would note that you cannot simply change the version
> of BDB that OpenLDAP is linked to and expect your database to work. You
> *must* slapcat your db using the old version of BDB, then upgrade openldap,
> then import with slapdd into the new build of OpenLDAP with the newer BDB.
> Nothing in your report specifically sounds like an issue with OpenLDAP
> itself.
>
> I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS
> will be closed.
As a footnote - you cannot have two versions of BDB linked into the same
process and expect things to work. If changing the version of BDB that
OpenLDAP is built with breaks SSSD, then you have a runtime linking problem,
and again, that's something to take up with your distro. Not an OpenLDAP issue.
Further footnote - this is why we recommend nss-pam-ldapd or nssov, which
fully isolates applications from the underlying nss/pam libraries. And why we
don't recommend SSSD. A shame they had to go off and reinvent the wheel
without actually fixing its underlying problems. Some people never learn.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 6 months
Re: (ITS#7839) openldap libdb5 support
by quanah＠zimbra.com
--On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote:
> Full_Name: Marc Schildt
> Version: 2.4.24 - 2.4.39
The OpenLDAP project is in no way associated with the utterly broken builds
provided by Debian. I would note that you cannot simply change the version
of BDB that OpenLDAP is linked to and expect your database to work. You
*must* slapcat your db using the old version of BDB, then upgrade openldap,
then import with slapdd into the new build of OpenLDAP with the newer BDB.
Nothing in your report specifically sounds like an issue with OpenLDAP
itself.
I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS
will be closed.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 6 months
(ITS#7839) openldap libdb5 support
by marc.schildt＠idealo.de
Full_Name: Marc Schildt
Version: 2.4.24 - 2.4.39
OS: Debian wheezy
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.162.49.126)
Hello,
we identified problems with the slapd version provided with debian wheezy.
Our workstations are using sssd for auth against our openldap-server.
The setup works well with slapd 2.4.23-7.3 on Debian squeeze.
But, after building a new LDAP server on Debian wheezy, sssd stops working
correctly and authentification of the workstations is not working anymore.
Debian wheezy is using the slapd 2.4.31-1+nmu2.
The following sssd versions we had tested with on different OS:
sssd.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms
sssd-client.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms
sssd 1.8.6-0ubuntu0.3
We then tried to self compile openldap on debian wheezy (source from
openldap.org).
>From openldap2.4.39 down to 2.4.24 the built packages still did not work
correctly with sssd.
Reaching 2.4.23, the source won't compile anymore.
So, after checking the change log, we saw that in 2.4.24 support for Berkley DB
5.1 was introduced in the source and for 2.4.23, db4.8 is needed.
We have then compiled the Berkley DB 4.8 source from debian squeeze on debian
wheezy and 2.4.23 was compiling cleanly.
And, surprise, the combination of openldap and sssd was working as expected.
After this success, we continued with a rebuild of openldap 2.4.31-1+nmu2
against the newly installed libdb4.8-dev libs.
And again, we happily seeing openldap 2.4.31-1+nmu2 (built against libdb4.8)
working like a charm together with sssd.
So, maybe there is a major problem with libdb5 support introduced in openldap
version 2.4.24 ?
slapd.conf:
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#########################
# Global Directives #
#########################
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/my.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload memberof
moduleload refint
# The maximum number of entries that is returned for a search operation
sizelimit unlimited
loglevel stats
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
# Global ACL's
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to *
by * read
#########################
# DB Directives #
#########################
database hdb
cachesize 20000
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw {SSHA}123456
directory "/var/lib/ldap"
checkpoint 1024 5
# INDEXING
index default eq
index objectClass,memberUid,uidNumber,gidNumber eq,pres
index givenName,dc,displayName,distinguishedName eq,pres
index cn,sn,mail,uid eq,pres,sub
index member,memberOf,uniqueMember eq,pres
# syncprov
index entryUUID,entryCSN,ou eq
index nisMapName,nisMapEntry eq,pres,sub
# samba
index sambaSID,sambaPrimaryGroupSID,sambaDomainName,sambaGroupType,sambaSIDList
eq
syncrepl rid="200"
provider="ldaps://ldap-provider.example.com"
searchbase="dc=example,dc=com"
type="refreshAndPersist"
retry="2 30 60 +"
filter="objectClass=*"
scope="sub"
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
binddn="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com"
bindmethod="simple"
credentials="123456"
tls_reqcert="allow"
# DB ACL's
access to *
by dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com"
write
by * break
limits dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com"
size=unlimited time=unlimited
access to attrs=sambaNTPassword
by dn.exact="cn=sambaconnect,dc=example,dc=com" read
by self write
by * none
limits dn.exact="cn=sambaconnect,dc=example,dc=com"
size=unlimited time=unlimited
access to attrs=userPassword,userPKCS12
by self write
by * auth
access to *
by dn.exact="cn=accessuser,dc=example,dc=com" read
by * break
limits dn.exact="cn=accessuser,dc=example,dc=com"
size=unlimited time=unlimited
# Overlay Config
overlay memberof
memberof-refint true
memberof-dangling error
memberof-dn cn=memberof-overlay
overlay refint
refint_attributes member memberOf manager owner seeAlso
refint_nothing cn=refinit.nothing,ou=system,dc=example,dc=com
TLSCACertificateFile /etc/ldap/certs/ldap-ca.pem
TLSCertificateFile /etc/ldap/certs/ldap-consumer2.example.com.pem
TLSCertificateKeyFile /etc/ldap/certs/ldap-consumer2.example.com.key
TLSVerifyClient allow
sssd.conf:
#
# RESET SSS cache:
# service sssd stop
# rm /var/lib/sss/db/cache_*
# service sssd start
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = INTERN
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 50
entry_negative_timeout = 15
[pam]
reconnection_retries = 3
offline_credentials_expiration = 30
offline_failed_login_attempts = 0
offline_failed_login_delay = 5
[domain/LDAP]
enumerate = true
cache_credentials = true
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldap-consumer2.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/ssl/certs/ldap-ca.pem
slapd_sssd_request_succsess.log → slapd 2.4.23-7.3 / libdb 4.8.30-2:
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 ACCEPT from
IP=172.30.2.191:49845 (IP=0.0.0.0:636)
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 TLS established
tls_ssf=128 ssf=128
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH attr=* altServer
namingContexts supportedControl supportedExtension supportedFeatures
supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN
highestCommittedUSN
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SEARCH RESULT tag=101
err=0 nentries=1 text=
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 BIND dn="" method=128
Apr 15 17:43:45 ldap-slave slapd[1810]: slap_global_control: unrecognized
control: 1.3.6.1.4.1.42.2.27.8.5.1
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 RESULT tag=97 err=0
text=
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName
cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax
shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SEARCH RESULT tag=101
err=0 nentries=1000 text=
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName
cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax
shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap
Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SEARCH RESULT tag=101
err=0 nentries=181 text=
Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH attr=objectClass cn
userPassword gidNumber memberuid modifyTimestamp modifyTimestamp
Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SEARCH RESULT tag=101
err=0 nentries=253 text=
Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))"
Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH attr=objectClass cn
ipServicePort ipServiceProtocol modifyTimestamp
Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SEARCH RESULT tag=101
err=0 nentries=0 text=
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(uid=test.user)(objectClass=posixAccount))"
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName
cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax
shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SEARCH RESULT tag=101
err=0 nentries=1 text=
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH attr=objectClass cn
userPassword gidNumber memberuid modifyTimestamp modifyTimestamp
Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SEARCH RESULT tag=101
err=0 nentries=22 text=
Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 op=8 UNBIND
Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 fd=17 closed
slapd_sssd_request_no_succsess.log → slapd 2.4.31-1+nmu2 / libdb
5.1.29-5:
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 ACCEPT from
IP=172.30.2.191:58270 (IP=0.0.0.0:636)
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 TLS established
tls_ssf=128 ssf=128
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH attr=*
altServer namingContexts supportedControl supportedExtension supportedFeatures
supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN
highestCommittedUSN
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 BIND dn=""
method=128
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 RESULT tag=97 err=0
text=
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH
attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory
loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange
shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag
krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService
accountExpires userAccountControl nsAccountLock host loginDisabled
loginExpirationTime loginAllowedTimeMap
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH
attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp
modifyTimestamp
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))"
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH
attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp
Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(uid=test.user)(objectClass=posixAccount))"
Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH
attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory
loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange
shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag
krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService
accountExpires userAccountControl nsAccountLock host loginDisabled
loginExpirationTime loginAllowedTimeMap
Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH
attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp
modifyTimestamp
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(uid=test.user)(objectClass=posixAccount))"
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH
attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory
loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange
shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag
krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService
accountExpires userAccountControl nsAccountLock host loginDisabled
loginExpirationTime loginAllowedTimeMap
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH
attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp
modifyTimestamp
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH
attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp
modifyTimestamp
Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 op=10 UNBIND
Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 fd=28 closed
7 years, 6 months
Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com
One more thing to note:
We see some coincidence between the seg faults and situations where the load on
the machine goes up and number of pending threads in back-monitor had values in
the range of 16 to 22 (threads is 16 for four cores).
7 years, 6 months
Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com
Michael Ströder wrote:
> On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote
>> Can you run slapd with ElectricFence and post stack traces and diagnostics
>> from any crashes there?
>
> Hmm, I will look into it.
> But I'm a bit cautious running such a component in production.
> Would running with MALLOC_CHECK_ be also reasonable helpful?
Possibly using MALLOC_CHECK_=3 could give us a clue, yes.
>
> BTW: The configuration uses back-mdb.
>
> Another strange thing to note:
> The archived syslog files revealed that the bind-DN rewriting is currently
> *not* used by the LDAP clients at all. So I really wonder where it even calls
> into slapo-rwm during normal operation.
Good question.
>
> Ciao, Michael.
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 6 months
Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com
On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote
> Can you run slapd with ElectricFence and post stack traces and diagnostics
> from any crashes there?
Hmm, I will look into it.
But I'm a bit cautious running such a component in production.
Would running with MALLOC_CHECK_ be also reasonable helpful?
BTW: The configuration uses back-mdb.
Another strange thing to note:
The archived syslog files revealed that the bind-DN rewriting is currently
*not* used by the LDAP clients at all. So I really wonder where it even calls
into slapo-rwm during normal operation.
Ciao, Michael.
7 years, 6 months
Re: (ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com
----==c72dbb1057ded1e9651a6f0c83ebf46f
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
Attached a patch against git master.
Hopefully I did not mess up the ppolicy.ldif with the wrapped lines.
I, Michael Ströder, hereby place the attached modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
----==c72dbb1057ded1e9651a6f0c83ebf46f
Content-Type: text/x-patch; name="openldap-its-7838.patch"
Content-Disposition: attachment; filename="openldap-its-7838.patch"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZiBiL3NlcnZlcnMv
c2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZgppbmRleCBiMmYzODY3Li5mYTEwYjg4IDEwMDY0NAot
LS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LmxkaWYKKysrIGIvc2VydmVycy9zbGFw
ZC9zY2hlbWEvcHBvbGljeS5sZGlmCkBAIC0zNSwyOCArMzUsMzcgQEAgY246IHBwb2xpY3kKIG9s
Y0F0dHJpYnV0ZVR5cGVzOiB7MH0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjEgTkFNRSAncHdk
QXR0cmlidXRlJyBFUVVBTElUWQogICBvYmplY3RJZGVudGlmaWVyTWF0Y2ggU1lOVEFYIDEuMy42
LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjM4ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MX0oIDEuMy42
LjEuNC4xLjQyLjIuMjcuOC4xLjIgTkFNRSAncHdkTWluQWdlJyBFUVVBTElUWSBpbgotIHRlZ2Vy
TWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSAp
CisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYu
MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5
cGVzOiB7Mn0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjMgTkFNRSAncHdkTWF4QWdlJyBFUVVB
TElUWSBpbgotIHRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3
IFNJTkdMRS1WQUxVRSApCisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRj
aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkK
IG9sY0F0dHJpYnV0ZVR5cGVzOiB7M30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQgTkFNRSAn
cHdkSW5IaXN0b3J5JyBFUVVBTElUWQotICBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x
LjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgIGludGVnZXJNYXRjaCBPUkRFUklO
RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEK
KyAgLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezR9KCAxLjMuNi4xLjQu
MS40Mi4yLjI3LjguMS41IE5BTUUgJ3B3ZENoZWNrUXVhbGl0eScgRVFVQUwKLSBJVFkgaW50ZWdl
ck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUg
KQorIElUWSBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggU1lOVEFY
IDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyCisgMS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRy
aWJ1dGVUeXBlczogezV9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42IE5BTUUgJ3B3ZE1pbkxl
bmd0aCcgRVFVQUxJVFkKLSAgaW50ZWdlck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjEx
NS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorICBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdl
ck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuCisgIDEuMjcg
U0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7Nn0oIDEuMy42LjEuNC4xLjQyLjIu
MjcuOC4xLjcgTkFNRSAncHdkRXhwaXJlV2FybmluZycgRVFVQQotIExJVFkgaW50ZWdlck1hdGNo
IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorIExJ
VFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBTWU5UQVggMS4z
LjYuMS40LjEuMTQ2Ni4xMTUuCisgMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0
ZVR5cGVzOiB7N30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjggTkFNRSAncHdkR3JhY2VBdXRo
TkxpbWl0JyBFUQotIFVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYu
MTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgVUFMSVRZIGludGVnZXJNYXRjaCBPUkRFUklO
RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTEKKyA1LjEy
MS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezh9KCAxLjMuNi4xLjQu
MS40Mi4yLjI3LjguMS45IE5BTUUgJ3B3ZExvY2tvdXQnIEVRVUFMSVRZIGIKICBvb2xlYW5NYXRj
aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuNyBTSU5HTEUtVkFMVUUgKQogb2xj
QXR0cmlidXRlVHlwZXM6IHs5fSggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTAgTkFNRSAncHdk
TG9ja291dER1cmF0aW9uJyBFCi0gUVVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEu
NC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgUVVBTElUWSBpbnRlZ2VyTWF0
Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2
LjEKKyAxNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQogb2xjQXR0cmlidXRlVHlwZXM6IHsxMH0o
IDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExIE5BTUUgJ3B3ZE1heEZhaWx1cmUnIEVRVUFMCi0g
SVRZIGludGVnZXJNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcgU0lO
R0xFLVZBTFVFICkKKyBJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01h
dGNoICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMQorIDIxLjEuMjcgU0lOR0xFLVZBTFVF
ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTF9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMiBO
QU1FICdwd2RGYWlsdXJlQ291bnRJbnRlcgotIHZhbCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIFNZ
TlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgCi0gKQorIHZh
bCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBT
WU5UQVggMS4zLjYuMS40LjEuCisgMTQ2Ni4xMTUuMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9s
Y0F0dHJpYnV0ZVR5cGVzOiB7MTJ9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMyBOQU1FICdw
d2RNdXN0Q2hhbmdlJyBFUVVBTAogIElUWSBib29sZWFuTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x
LjE0NjYuMTE1LjEyMS4xLjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTN9
KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xNCBOQU1FICdwd2RBbGxvd1VzZXJDaGFuZ2UnIApk
aWZmIC0tZ2l0IGEvc2VydmVycy9zbGFwZC9zY2hlbWEvcHBvbGljeS5zY2hlbWEgYi9zZXJ2ZXJz
L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQppbmRleCA2YzVmYjcwLi5hYjE1NTgzIDEwMDY0
NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQorKysgYi9zZXJ2ZXJz
L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQpAQCAtMTEwLDYgKzExMCw3IEBAIGF0dHJpYnV0
ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xCiBhdHRyaWJ1dGV0eXBlICggMS4zLjYu
MS40LjEuNDIuMi4yNy44LjEuMgogICAgICAgTkFNRSAncHdkTWluQWdlJwogICAgICAgRVFVQUxJ
VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg
ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM
VUUgKQogCkBAIC0xMjUsNiArMTI2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy
LjIuMjcuOC4xLjIKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4zCiAg
ICAgICBOQU1FICdwd2RNYXhBZ2UnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAg
IE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEu
MTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE0MCw2ICsxNDIs
NyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMwogYXR0cmlidXRl
dHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQKICAgICAgIE5BTUUgJ3B3ZEluSGlzdG9y
eScKICAgICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9y
ZGVyaW5nTWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwog
ICAgICAgU0lOR0xFLVZBTFVFICkKIApAQCAtMTY2LDYgKzE2OSw3IEBAIGF0dHJpYnV0ZXR5cGUg
KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS40CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEu
NDIuMi4yNy44LjEuNQogICAgICAgTkFNRSAncHdkQ2hlY2tRdWFsaXR5JwogICAgICAgRVFVQUxJ
VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg
ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM
VUUgKQogCkBAIC0xODIsNiArMTg2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy
LjIuMjcuOC4xLjUKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42CiAg
ICAgICBOQU1FICdwd2RNaW5MZW5ndGgnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAg
ICAgIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40
LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE5OCw2ICsy
MDMsNyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNgogYXR0cmli
dXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjcKICAgICAgIE5BTUUgJ3B3ZEV4cGly
ZVdhcm5pbmcnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAgIE9SREVSSU5HIGlu
dGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIx
LjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTIxMCw2ICsyMTYsNyBAQCBhdHRyaWJ1
dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNwogYXR0cmlidXRldHlwZSAoIDEuMy42
LjEuNC4xLjQyLjIuMjcuOC4xLjgKICAgICAgIE5BTUUgJ3B3ZEdyYWNlQXV0aE5MaW1pdCcKICAg
ICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5n
TWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAg
U0lOR0xFLVZBTFVFICkKIApAQCAtMjQxLDYgKzI0OCw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMu
Ni4xLjQuMS40Mi4yLjI3LjguMS45CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4y
Ny44LjEuMTAKICAgICAgIE5BTUUgJ3B3ZExvY2tvdXREdXJhdGlvbicKICAgICAgIEVRVUFMSVRZ
IGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2gKICAgICAg
IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAgU0lOR0xFLVZBTFVF
ICkKIApAQCAtMjU0LDYgKzI2Miw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4y
LjI3LjguMS4xMAogYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiAg
ICAgICBOQU1FICdwd2RNYXhGYWlsdXJlJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisg
ICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEu
NC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCkBAIC0yNjksNiAr
Mjc4LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiBhdHRy
aWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTIKICAgICAgIE5BTUUgJ3B3ZEZh
aWx1cmVDb3VudEludGVydmFsJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisgICAgICBP
UkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0
NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCg==
----==c72dbb1057ded1e9651a6f0c83ebf46f--
7 years, 6 months
(ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com
Full_Name:
Version: HEAD and RE24
OS:
URL:
Submission from: (NULL) (212.227.35.93)
For search pwdPolicy entries with certain parameters it would be handy to be
able to search e.g. with (pwdMaxAge>=1).
Therefore ORDERING integerOrderingMatch should be added to all Integer attribute
types in ppolicy.schema and ppolicy.ldif.
7 years, 6 months
