openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 22 Apr '14

22 Apr '14

hello, FYI, I just stumbled on an old topic from 2011: --------------------------------- 8< --------------------------------- Re: cn=config replication to consumer / slave servers ________________________________ To: Christopher Strider Cook <ccook(a)pandora.com> Subject: Re: cn=config replication to consumer / slave servers From: Howard Chu <hyc(a)symas.com> Date: Tue, 19 Apr 2011 17:27:58 -0700 Cc: Quanah Gibson-Mount <quanah(a)zimbra.com>, openldap-technical(a)openldap.org ________________________________ Christopher Strider Cook wrote: > So, the pointer to test059 was exactly what this issue needed and > following it has lead me to an very good working setup with one puzzling > final step. > The problem I now face is that the initial cn=config entries used to do > the first sync do not get overwritten by the data from the master. So > the install password doesn't get replaced nor do the updated retry > timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries have > newer timestamps than those on the master. > How can this be overcome from the perspective of the slave server. > Updating the entries on the master triggers the update as you would > expect. Is there a way to put the stub entries onto the slave with a > timestamp in the past so that they get overwritten during the first > sync? Or is there another way to trigger them to be updated? Use slapd -c. Read the slapd(8) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------------------------- 8< --------------------------------- you always answer "use slapd -c" to this type of question, but you _never_ mention that newer entries are never overwritten by older entries. so _in this context_ this answer is useless building the consumer before the provider is not an option, also _in this context_ so the only option left is to update the master with an empty modify ldif to force update of the timestamps I personnaly use --------------------------------- 8< --------------------------------- dn: cn=config changetype: modify dn: olcDatabase={-1}frontend,cn=config changetype: modify dn: olcDatabase={0}config,cn=config changetype: modify --------------------------------- 8< --------------------------------- besides, if you do this update with a user from a different database, e.g cn=admin,dc=my,dc=tld the seed replication fails because modifiersName contains a non existing DN (at the time of the replication). I consider this a bug also. anyway, thanks for your dedicated time and effort. OpenLDAP is really a great software. I have a lot to learn yet. so please bear with me :-) best regards, 2014-04-20 11:33 GMT+04:00 Jephte Clain <jephte.clain(a)univ-reunion.fr>: > hello, > > thanks for your answer. > see my response below > > 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: >> Jephte.Clain(a)univ-reunion.fr wrote: >>> >>> 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. >> >> >> There is no bug. The syncrepl consumer is working as designed. If you want >> the consumer's entries to be automatically overwritten, create the consumer >> first so that its seed entries have older timestamps than the provider. > > ok, it works as designed. I just didn't know what the design was :-) > quoting man slapd: > Use only the rid part to force a full reload. > I guess I didn't notice that the word "full" have a different meaning > here than usual > > about creating the consumer first. you are kidding, right? in > production, the provider exists long before the consumer is set up. > the tests I do are based on the production state. > > anyway, my automated scripts "touch" the provider after setting up the > slave, so this is not a problem. > It's just that I would prefer not to have wasted time wondering why > the slave was not being updated even though I asked for a "full" > reload > > Thanks for your answer. It's now clearer in my mind. > I Cc the openldap-technical list, this can help others. > >> >>> 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... >> >> >> That's far overkill. All you need to do is configure your test scripts to >> use relative pathnames. test049 (and others) in the test suite already >> operates this way. > > ok thanks for pointing this out > It has been a while since I read the tests scripts. I should have paid > more attention... > >> >> Closing this ITS. >> >>> 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 >>> >>> -- Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

(ITS#7841) high disk utilization
by dmitrii.fonariuk＠gmail.com 21 Apr '14

21 Apr '14

Full_Name: Dmitrii Fonariuk Version: 2.4.38 OS: rhEL6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) There is a big value of DISK WRITE parameter in utility Iotop when in MDB a lot of Free pages (Freelist Status). Supposedly this situation arises from memory management algorithm. The algorithm FIFO is used for pages block allocation in free pages pool. We touched and dirty different pages on every modification transaction, which then flushed to disk by system process Flush. Perhaps it would be better to use the LIFO, which will to dirty the same pages by different transactions, which reduces the load on the disk? we use MDB with EnvFlags writemap and mapasync.

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 20 Apr '14

20 Apr '14

hello, thanks for your answer. see my response below 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: > Jephte.Clain(a)univ-reunion.fr wrote: >> >> 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. > > > There is no bug. The syncrepl consumer is working as designed. If you want > the consumer's entries to be automatically overwritten, create the consumer > first so that its seed entries have older timestamps than the provider. ok, it works as designed. I just didn't know what the design was :-) quoting man slapd: Use only the rid part to force a full reload. I guess I didn't notice that the word "full" have a different meaning here than usual about creating the consumer first. you are kidding, right? in production, the provider exists long before the consumer is set up. the tests I do are based on the production state. anyway, my automated scripts "touch" the provider after setting up the slave, so this is not a problem. It's just that I would prefer not to have wasted time wondering why the slave was not being updated even though I asked for a "full" reload Thanks for your answer. It's now clearer in my mind. I Cc the openldap-technical list, this can help others. > >> 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... > > > That's far overkill. All you need to do is configure your test scripts to > use relative pathnames. test049 (and others) in the test suite already > operates this way. ok thanks for pointing this out It has been a while since I read the tests scripts. I should have paid more attention... > > Closing this ITS. > >> 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 >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- cordialement, Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by hyc＠symas.com 20 Apr '14

20 Apr '14

Jephte.Clain(a)univ-reunion.fr wrote: > 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. There is no bug. The syncrepl consumer is working as designed. If you want the consumer's entries to be automatically overwritten, create the consumer first so that its seed entries have older timestamps than the provider. > 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... That's far overkill. All you need to do is configure your test scripts to use relative pathnames. test049 (and others) in the test suite already operates this way. Closing this ITS. > 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 > > -- -- 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

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs