openldap-bugs April 2014

openldap-bugs@openldap.org

18 participants
43 discussions

(ITS#7840) bug with initial/seed syncrepl
by Jephte.Clain＠univ-reunion.fr 19 Apr '14

19 Apr '14

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

1 0

Re: (ITS#7839) openldap libdb5 support
by michael＠stroeder.com 17 Apr '14

17 Apr '14

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.

1 0

Re: (ITS#7839) openldap libdb5 support
by hyc＠symas.com 17 Apr '14

17 Apr '14

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/

1 0

Re: (ITS#7839) openldap libdb5 support
by quanah＠zimbra.com 17 Apr '14

17 Apr '14

--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

1 0

(ITS#7839) openldap libdb5 support
by marc.schildt＠idealo.de 17 Apr '14

17 Apr '14

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

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 16 Apr '14

16 Apr '14

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).

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 15 Apr '14

15 Apr '14

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/

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 15 Apr '14

15 Apr '14

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.

1 0

Re: (ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

----==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--

1 0

(ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

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.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2014