- openldap-bugs - openldap.org

(ITS#5868) failed assertion with back-relay
by Guillaume.Rousse＠inria.fr 22 Dec '08

22 Dec '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: Mandriva linux URL: Submission from: (NULL) (193.55.250.67) Here's my back-relay configuration: database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr rwm-map attribute telephoneNumber homePhone rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute uid * rwm-map attribute * access to dn.subtree="ou=telephony,dc=msr-inria,dc=inria,dc=fr" by * read The server crashes immediatly when attempting a query for given prefix. Here is debug trace: slap_listener_activate(7): >>> slap_listener(ldap:///) connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 17 do_bind: v3 anonymous bind connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 77 contents: ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=0 op=1 dn="[anonymous]" ==> rewrite_context_apply [depth=1] string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=telephony,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=users,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr>, <ou=users,dc=msr-inria,dc=inria,dc=fr> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ber_scanf fmt (m) ber: => bdb_search bdb_dn2entry("ou=users,dc=msr-inria,dc=inria,dc=fr") => bdb_dn2id("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x2 entry_decode: "ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(ou=users,dc=msr-inria,dc=inria,dc=fr) search_candidates: base="ou=users,dc=msr-inria,dc=inria,dc=fr" (0x00000002) scope=2 => bdb_dn2idl("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2idl: id=90 first=2 last=190 => bdb_presence_candidates (objectClass) bdb_search_candidates: id=90 first=2 last=190 ==> rewrite_context_apply [depth=1] string='ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 93 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x4 ==> rewrite_context_apply [depth=1] string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 229 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x6 ==> rewrite_context_apply [depth=1] string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="(null)" slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed I'm running openldap 2.4.12 (official mandriva package) under mandriva x86_64.

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 22 Dec '08

22 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-26328-1229943475-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 'HEAD' I get the following: ./slapd -h "ldap:///" slapo-ppolicy cannot be global Seems like a decent solution Thanks --=20 Mark Janssen Visit HAR2009, the four-yearly Dutch outdoor technology-conference August 13-16, 2009, vierhouten. http://www.har2009.org --=_server11-26328-1229943475-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklPcrIACgkQb6urvDV9IXhs4gCeM0FRAXrZ1NKGZn5V3w9Igs07 STMAn1zn7owuM9xj5K7+YdR3QGUhEWGo =8U9N -----END PGP SIGNATURE----- --=_server11-26328-1229943475-0001-2--

1 0

Re: (ITS#5861) Assert control on Add request fails
by ando＠sys-net.it 20 Dec '08

20 Dec '08

Kurt Zeilenga wrote: > This is not to say slapd(8) shouldn't be updated to make use of the > control when provided with Add requests, just saying it's technically > okay that it doesn't. Slapd(8) has been updated. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5867) back-config does not return sizeLimitExceeded
by ando＠sys-net.it 20 Dec '08

20 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > back-config obeys sizelimit, but returns success instead of sizeLimitExceeded. should be fixed in HEAD, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5861) Assert control on Add request fails
by Kurt＠OpenLDAP.org 20 Dec '08

20 Dec '08

On Dec 20, 2008, at 12:13 PM, ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> RFC 4528 says the Assert control is appropriate for Add. Yes. >> Slapd disagrees: No. slapd(8) is saying the control is unavailable. That's quite different than saying it is inappropriate. >> >> >> $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' >> <test.ldif >> adding new entry "o=test" >> ldap_add: Critical extension is unavailable (12) >> additional info: critical extension is unavailable > > According to this thread > > <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> > > the author of the assertion control (Kurt :) believes the current > specification is flawed. In fact, the assertion control is intended > to > apply to the contents of the DIT. The entry does not belong to the > DIT > until the operation is completed, so assertion cannot apply. Those comments were in respect to the I-D (when it was a work in progress). The specification does allow for the control to be attached to Add requests. Though it might seem kind of pointless, a client might do it as it is not itself capable of evaluating some assertion. I would argue that it fine for a server which cannot handle the control in this (or other cases) to return unavailableCriticalExtension. The specification certainly doesn't require a server to make use of the control in cases where it might be asserted. This is not to say slapd(8) shouldn't be updated to make use of the control when provided with Add requests, just saying it's technically okay that it doesn't.

1 0

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by ando＠sys-net.it 20 Dec '08

20 Dec '08

guillaume.pujol(a)eds.com wrote: > idassert-bind bindmethod=simple mode=self This line makes no sense. In fact, it assumes an empty DN ("anonymous") can authorize users. This idassert-bind statement should be invalid. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by ando＠sys-net.it 20 Dec '08

20 Dec '08

rlvcosta(a)yahoo.com wrote: > Full_Name: Rodrigo Costa > Version: 2.4.11 > OS: RHEL4 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.82.161.220) > > > Opeldap dev team, > > I'm facing an issue and after many tentatives I believe this is really a bug > that maybe could be identified and solved by openldap community. I tried to > include dmalloc into openldap 2.4.11 code but even I could compile with it any > tentative to execute the code generated "Segmentation Fault" so I could not use > dmalloc to identify where the memory leak is happening. Can you try with valgrind? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by ando＠sys-net.it 20 Dec '08

20 Dec '08

A workaround is in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5861) Assert control on Add request fails
by ando＠sys-net.it 20 Dec '08

20 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: > > $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif > adding new entry "o=test" > ldap_add: Critical extension is unavailable (12) > additional info: critical extension is unavailable According to this thread <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> the author of the assertion control (Kurt :) believes the current specification is flawed. In fact, the assertion control is intended to apply to the contents of the DIT. The entry does not belong to the DIT until the operation is completed, so assertion cannot apply. > back-bdb and back-sql do not apply the assert control to Add. As per what seems to be the intention of the author of the specification (although it is in contrast with the current specification, RFC4528). > The message comes from slapd/controls.c. Don't fix that before fixing > Add in the backends, otherwise critical controls can be ignored. > > Another strangeness: overlays/syncprov.c applies the Assert control to > Compare but not other operations. I don't know why, there are no > comments about it. No clue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5867) back-config does not return sizeLimitExceeded
by h.b.furuseth＠usit.uio.no 20 Dec '08

20 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-config obeys sizelimit, but returns success instead of sizeLimitExceeded. slapd.conf: database config access to * by * read sizelimit 2 $ ldapsearch -xhlocalhost:3890 -b cn=config 1.1 # extended LDIF # (...) # config dn: cn=config # schema, config dn: cn=schema,cn=config # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2

1 0

(ITS#5866) syncrepl : all entries not replicated (glue entryCSN problem)
by julien.combes＠i-carre.net 19 Dec '08

19 Dec '08

Full_Name: Julien Combes Version: 2.4.13 OS: debian 4.0 etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.23.162.38) Hello, I am studying the migration of my architecture from 2.3.39 to 2.4.13. The provider is in 2.4.13. I have a problem with syncrepl (and delta-syncrepl) with two consumers in openldap 2.4.13 when I start them with an empty database : some entries are not replicated. A consumer with openldap 2.3.39 is not affected by the problem : all entries are replicated correctly. All consumers are using the same replication account. As I am in a testing environment, I have retried several times the test: every time, the same entries are not replicated on both consumers. All entries not replicated are "organizationalUnit" on the provider and have entries below them. All entries below them are correctly replicated. With a slapcat on the consumers I can see that the entries not replicated are "glue". Servers : -> provider : openldap 2.4.13, BDB 4.7.25 - number of entries : 191961 -> consumer-1 : openldap 2.4.13, BDB 4.7.25 - number of entries after replication : 191937 -> consumer-2 : openldap 2.4.13, BDB 4.7.25 - number of entries after replication : 191937 -> consumer-3 : openldap 2.3.39, BDB 4.2.52 - number of entries after replication : 191961 The logfile (sync, stats) indicate that : -> one entry below the organizationalUnit (not replicated) is replicated before the organizationalUnit itself Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain -> when it's the turn of this organizationalUnit to be replicated, the log indicate lignes like that : Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 be_add (68) Dec 18 18:18:17 consumer-2 slapd[13897]: dn_callback : new entry is older than ours ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain ours 20081204104512.468400Z#000000#000#000000, new 20081020233519.000000Z#000018#000#000000 Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 entry unchanged, ignored (ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain) About the entryCSN of this log : -> "ours 20081204104512.468400Z#000000#000#000000" seems to be the entryCSN of the entry below replicated befor the organizationalUnit : On consumer-[12] : dn: mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081204104512.468400Z#000000#000#000000 On Provider : dn: mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081204104512.468400Z#000000#000#000000 -> "new 20081020233519.000000Z#000018#000#000000" is the entryCSN of the organisazionalUnit on the provider : dn: ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081020233519.000000Z#000018#000#000000 All servers are a the same time. Configuration files : ===================================================================== provider : openldap 2.4.13, BDB 4.7.25 ===================================================================== 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/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 5000 timelimit 10 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload syncprov moduleload accesslog moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/provider.my.domain.pem TLSCertificateKeyFile /etc/certs/provider.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to dn.subtree="cn=accesslog" by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" read by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by * none access to attrs=userPassword by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by anonymous auth by self write by * none access to * by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by * read database hdb suffix "cn=accesslog" rootdn "cn=accesslog" directory "/var/lib/ldap/accesslog" index entryCSN,objectClass,reqEnd,reqResult,reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database hdb suffix "dc=my,dc=domain" directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 heckpoint 512 10 index objectClass eq index mineqMelPartages,mineqLiensImport,mineqMelmailEmission,cn pres,eq,sub index mail pres,eq index uid,mineqMelMembres,employeeNumber,ou,gidnumber,uidNumber,mineqTypeEntree,sn,drink,aliasedObjectName,memberUid pres,eq index entryCSN,entryUUID eq lastmod on overlay syncprov syncprov-checkpoint 100 10 overlay accesslog logdb "cn=accesslog" logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 limits dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database monitor ===================================================================== consumer-1 : openldap 2.4.13, BDB 4.7.25 ===================================================================== allow bind_v2 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/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 20000 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-01.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-01.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" limits dn.exact="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited syncrepl rid=2 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> logbase="cn=accesslog" syncdata=accesslog updateref ldaps://provider.my.domain directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 0 10 index objectClass eq index uid,mail pres,eq index cn pres,eq,sub index entryCSN,entryUUID eq lastmod on database monitor ===================================================================== consumer-2 : openldap 2.4.13, BDB 4.7.25 ===================================================================== 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/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 5000 timelimit 10 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-02.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-02.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 512 10 index objectClass eq index mineqMelPartages,mineqLiensImport,mineqMelmailEmission,cn eq,sub index mail eq index uid,mineqMelMembres,employeeNumber,ou,gidnumber,uidNumber,mineqTypeEntree,sn,drink,aliasedObjectName,memberUid eq index entryCSN,entryUUID eq lastmod on syncrepl rid=3 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> updateref ldaps://provider.my.domain limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database monitor ===================================================================== consumer-3 : openldap 2.3.39, BDB 4.2.52 ===================================================================== allow bind_v2 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/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema schemacheck on sizelimit 20000 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-03.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-03.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" limits dn.exact="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited syncrepl rid=1 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> logbase="cn=accesslog" syncdata=accesslog updateref ldaps://provider.my.domain directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 0 10 index objectClass eq index uid,mail eq index cn eq,sub index entryCSN,entryUUID eq lastmod on database monitor Regards, Julien

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 18 Dec '08

18 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-8238-1229608279-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've figured it out... I got everything working now with 2.4.13. I had the overlay configured before the database definition... this caused the segfault. This same setup didn't segfault on 2.3.x, but still didn't work. Once I got it working on 2.3.x I migrated my config back to 2.4.13, and it works again. Still, openldap shouldn't segfault on something like this, but I am a happy camper again. Mark --=_server11-8238-1229608279-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklKVVcACgkQb6urvDV9IXjZdwCdFnV9JBfHsdiHDGunptLUs25H VJwAn3m2OQQ/lo/yJ6Z/KwWkmOqGRlZV =A0Pg -----END PGP SIGNATURE----- --=_server11-8238-1229608279-0001-2--

1 0

Re: (ITS#5859) back-hdb entrycache problem
by rhafer＠suse.de 17 Dec '08

17 Dec '08

Am Mittwoch 17 Dezember 2008 15:03:49 schrieb rhafer(a)suse.de: > This problem seems to be only present when using an empty suffix. I wasn't > able to reproduce it with a non-empty suffix at least. > > It seems to be a problem with the idlcache. After setting "idlcachesize" to > 0 the problem went a way for me. > > And yes, it seems to have been in the RE24 tree for a longer time already > (2.4.12 was affected as well). Digging a bit deeper into this, I found that only back-hdb is affected and that it is most probably a bug in hdb_dn2id_add(). It seems that after adding a new entry, hdb_dn2id_add() fails to correctly update the IDLs in the idl- cache for the entry's parent entries. The following patch seems to fix the problem for me: --- dn2id.c 31 Oct 2008 23:23:59 -0000 1.137.2.13 +++ dn2id.c 17 Dec 2008 19:45:32 -0000 @@ -620,6 +620,11 @@ tmp[1] = eip->bei_id; bdb_idl_cache_add_id( bdb, db, &key, e->e_id ); } + if ( !op->o_bd->be_suffix[0].bv_len && eip) + { + tmp[1] = eip->bei_id; + bdb_idl_cache_add_id( bdb, db, &key, e->e_id ); + } } } I suspect that hdb_dn2id_delete() has a similar issue. -- Ralf

1 0

Re: (ITS#5859) back-hdb entrycache problem
by rhafer＠suse.de 17 Dec '08

17 Dec '08

This problem seems to be only present when using an empty suffix. I wasn't able to reproduce it with a non-empty suffix at least. It seems to be a problem with the idlcache. After setting "idlcachesize" to 0 the problem went a way for me. And yes, it seems to have been in the RE24 tree for a longer time already (2.4.12 was affected as well). -- Ralf

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 17 Dec '08

17 Dec '08

On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: > Andrew: > > One suggestion following a very quick scan of the code: I think it > > would be worth bringing the warning about turning off TLS checks > > into the manual page. > > Agreed. Done. The tarball is uploaded as adauth-20081217.tar.gz Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by quanah＠zimbra.com 16 Dec '08

16 Dec '08

--On Tuesday, December 16, 2008 3:20 PM +0000 guillaume.pujol(a)eds.com wrote: > I'm not sure if this crash is due to an incoherent configuration, or to an > interaction problem with the Active Directory backend. > In the former case, I think the server should output an error message when > started. In the later case, it is probably a bug. > > Please let me know if you need more specific information. Can you reproduce with OpenLDAP 2.4.13? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5864) slapadd trickle task slows down slapadd when using libdb-4.5
by rhafer＠suse.de 16 Dec '08

16 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: openSUSE 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.233.197) Regardless of the recent slapadd fixes discussed on the -devel list (http://www.openldap.org/lists/openldap-devel/200811/msg00126.html), slapadd performance is still bad when linking against berkely-db 4.5.X, there seem to be problems with libdb-4.5's memp_trickle() function. IMO we should just disable the trickle_task when linking against libdb < 4.6.

1 0

(ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by guillaume.pujol＠eds.com 16 Dec '08

16 Dec '08

Full_Name: Guillaume Pujol Version: 2.4.11 (latest debian package) OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.251.11.120) Hello, I have an OpenLDAP test instance configured as a translucent proxy to an Active Directory server (the later running on W2k3). The relevant database configuration (from slapd.conf) is as follows: database hdb directory /var/lib/ldap-proxy suffix "dc=eds,dc=local" index objectClass eq overlay translucent uri ldap://192.168.65.130:389 lastmod off acl-bind bindmethod=simple binddn="CN=ldapsync,CN=Users,DC=EDS,DC=local" credentials="ldapsync" idassert-bind bindmethod=simple mode=self chase-referrals yes The server loads and runs fine with this configuration, as long as no one binds. The credentials for acl-bind are valid. When I connect to the server and bind with valid credentials, the server crashes with a SIG_ABRT due to an assertion failed (backtrace below). Steps to reproduce: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ps aux | grep slapd openldap 5978 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5983 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd root@debian:~# ldapsearch -H ldap://192.168.65.134 -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W -LL Enter LDAP Password: <input correct password here> ldap_result: Can't contact LDAP server (-1) root@debian:~# ps aux | grep slapd root 5970 0.0 0.2 3144 764 pts/2 S+ 14:20 0:00 grep slapd # TO MAKE SURE THE SERVER WORKS FINE, I TRY TO BIND WITH A WRONG PASSWORD: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ldapsearch -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <input wrong password here> ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece root@debian:~# ps aux | grep slapd openldap 5982 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5984 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd The backtrace of the SIG_ABRT is as follows: #0 0xb7faf424 in __kernel_vsyscall () #1 0xb7bbb640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7bbd018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7bb45be in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb7f62d3b in ber_bvreplace_x (dst=0x8b3d458, src=0xb6981d48, ctx=0x0) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 #5 0xb7f62d6c in ber_bvreplace (dst=0x8b3d458, src=0xb6981d48) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:715 #6 0xb77c78ff in ldap_back_dobind_int (lcp=0xb6981e78, op=0x8b3d018, rs=0xb6983148, sendok=22, retries=0, dolock=1) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/bind.c:2211 #7 0xb77c2ecd in ldap_back_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/search.c:166 #8 0xb77b65d2 in translucent_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/overlays/translucent.c:976 #9 0x080db6c6 in overlay_op_walk (op=0x8b3d018, rs=0xb6983148, which=op_search, oi=0x8ae4028, on=0x8ae4128) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:636 #10 0x080dc205 in over_op_func (op=0x8b3d018, rs=0xb6983148, which=op_search) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:698 #11 0x08078a23 in fe_op_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:366 #12 0x08079290 in do_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:217 #13 0x08076436 in connection_operation (ctx=0xb6983238, arg_v=0x8b3d018) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1084 #14 0x08076eb7 in connection_read_thread (ctx=0xb6983238, argv=0x13) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1211 #15 0xb7f73fb8 in ldap_int_thread_pool_wrapper (xpool=0x8ab46f8) at /build/buildd/openldap-2.4.11/libraries/libldap_r/tpool.c:663 #16 0xb7cf14c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #17 0xb7c7061e in clone () from /lib/i686/cmov/libc.so.6 So it looks like this assert fails for some reason: at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 assert( !BER_BVISNULL( src ) ); Reproducible: always with the configuration above. If I remove "mode=self" in the configuration above, the server loads and runs fine (no crash when binding), but I can't search anything in the database: root@debian:~# ldapsearch -LL -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <correct password> result: 1 Operations error text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope ration a successful bind must be completed on the connection., data 0, vece I'm not sure if this crash is due to an incoherent configuration, or to an interaction problem with the Active Directory backend. In the former case, I think the server should output an error message when started. In the later case, it is probably a bug. Please let me know if you need more specific information. Regards,

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 16 Dec '08

16 Dec '08

Andrew: > One suggestion following a very quick scan of the code: I think it > would be worth bringing the warning about turning off TLS checks > into the manual page. Agreed. Done. > In particular, there is no reason for this > to be AD-specific and it should be easy to adapt it to authenticate > against any [collection of] remote LDAP servers. Actually, it may not be AD specific as is. If you define default_domain to be some rubbish, and default_realm to be the remote AD server, then everything else (including the remote bind DN) can be fetched from the DIT. But I haven't tried this. But what wouldn't get passed back is any information flowing from password controls - and that's an annoyance, which is why I didn't generalise the code (and because HP had no business need for that approach anyway). Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25943-1229438597-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can also NOT reproduce this with OpenLDAP 2.3.43 on Solaris 10. So this seems to be a regression in OpenLDAP 2.4.x For the moment I'm sticking with 2.3, though it still doens't solve my problem of hashing passwords on change (exop's don't seem to be triggered) Mark --=_server11-25943-1229438597-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHvocACgkQb6urvDV9IXhY5ACgkuKEb8H03RbTZWDAthb/n10Z d5AAoLsPNEL3UONsg0oG90coRtIT0ktq =T44A -----END PGP SIGNATURE----- --=_server11-25943-1229438597-0001-2--

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25317-1229436747-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Also tested my config on OpenLDAP 2.3.27 on CentOS 5 (i386) with packages from: http://dev.centos.org/centos/5/testing/i386/RPMS/ This hasn't resulted in a segfault yet.=20 I will try version 2.3.27 on Solaris now. --=_server11-25317-1229436747-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHt0gACgkQb6urvDV9IXjtlwCeJ8q/q2q+kX48VSoWCyaAfEE5 TIIAoKHn1k0gkXrxqZjiCekBQC3OMR9D =+iFS -----END PGP SIGNATURE----- --=_server11-25317-1229436747-0001-2--

1 0

(ITS#5862) Assert control ignored on non-database entries
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd does not apply the Assert control to non-database entries (at least the root and subschema entries), yet does not reject a critical control either. I have not explored the magnitutde of the problem: Where the control can get ignored, and which other controls are ignored. $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b "" -s base dn: objectClass: top objectClass: OpenLDAProotDSE $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b cn=subschema -s base dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema -b "" -s sub does apply the control with database bdb + suffix "". Don't know about back-sql. However I imagine it varies how careful backends "" are about generating the root DSE when suffix == "" so controls can be applied to it. Might need a backend flag which says whether the backend does this, and reject the critical controls with unwillingToPerform if this flag is not set.

1 0

(ITS#5861) Assert control on Add request fails
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif adding new entry "o=test" ldap_add: Critical extension is unavailable (12) additional info: critical extension is unavailable back-bdb and back-sql do not apply the assert control to Add. The message comes from slapd/controls.c. Don't fix that before fixing Add in the backends, otherwise critical controls can be ignored. Another strangeness: overlays/syncprov.c applies the Assert control to Compare but not other operations. I don't know why, there are no comments about it.

1 0

(ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 15 Dec '08

15 Dec '08

Full_Name: Rodrigo Costa Version: 2.4.11 OS: RHEL4 U4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.82.161.220) Opeldap dev team, I'm facing an issue and after many tentatives I believe this is really a bug that maybe could be identified and solved by openldap community. I tried to include dmalloc into openldap 2.4.11 code but even I could compile with it any tentative to execute the code generated "Segmentation Fault" so I could not use dmalloc to identify where the memory leak is happening. I compiled both Berkeley DB 4.6.21 with its patches from source and then compiled openldap 2.4.11 also from source. I download both from links provided at Oracle and Openldap so I think the code is ok. For reference I compiled Berkeley DB with the following configuration : env CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" \ ../dist/configure --enable-largefiles --enable-java --prefix=/usr It compiled without problems. The openldap is compiled with the following configuration : env CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" ./configure --with-tls --enable-crypt --enable-syslog --enable-modules --enable-bdb=mod --enable-monitor=mod --enable-shared --with-gnu-ld --enable-overlays=mod --sysconfdir=/etc --prefix=/usr It identifies correctly bdb libraries and compile without any problem. The CHANGES file make reference for ITS#5557 which I saw as possible candidate for the problem I'm having. Even with it looks like there is memory leak. My system is a HP DL380-G3 32 bits with 12GB of memory. The OS is Red Hat Enterprise Linux 4 Update 4. I have actually an old version of OpenLdap(version 2.1.30 with bdb 4.2.52) running in a similar machine without any problem. The specific details are "Linux brtldp11 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux". I made several slapd.conf files trying to control cache and see this could be a configuration problem. I put into debug 64 and the file is read correctly without any problem. Please see output below : all schema stuff... line 23 (pidfile /var/run/slapd.pid) line 24 (argsfile /var/run/slapd.args) line 26 (allow bind_v2) line 28 (sizelimit 10000) line 29 (timelimit 5400) line 31 (loglevel 0) line 34 (modulepath /usr/libexec/openldap) line 35 (moduleload back_bdb.la) loaded module back_bdb.la module back_bdb.la: null module registered line 36 (moduleload back_monitor.la) loaded module back_monitor.la module back_monitor.la: null module registered line 78 (database bdb) line 79 (suffix "ou=CONTENT,o=alcatel,c=fr") line 80 (rootdn "cn=admin,ou=CONTENT,o=alcatel,c=fr") line 84 (rootpw ***) line 87 (directory /var/openldap-data/bdb1) line 90 (index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres) index uid 0x0006 index pnnumber 0x0006 index submxid 0x0006 index maillogin 0x0006 index abookaliasid 0x0006 line 91 (index objectClass eq) index objectClass 0x0004 line 93 (cachesize 45000) line 94 (dncachesize 45000) line 95 (idlcachesize 45000) line 96 (cachefree 9000) line 104 (database bdb) line 105 (suffix "ou=INDEXES,o=alcatel,c=fr") line 106 (rootdn "cn=admin,ou=INDEXES,o=alcatel,c=fr") line 110 (rootpw ***) line 113 (directory /var/openldap-data/bdb2) line 116 (index weblogin,maillogin,mail,pnnumber eq,pres) index weblogin 0x0006 index maillogin 0x0006 index mail 0x0006 index pnnumber 0x0006 line 117 (index profileid,loginname eq,pres) index profileid 0x0006 index loginname 0x0006 line 118 (index objectClass eq) index objectClass 0x0004 line 120 (cachesize 45000) line 121 (dncachesize 45000) line 122 (idlcachesize 45000) line 123 (cachefree 9000) line 131 (database monitor) slapd starting My DB has around 4 million entrances and the bdb DB file size is around 15GB. The DB itself is not big since the entrances are not soo big. By openLDAP documents a DB with 4million entrances should be supported correctly into a 32 bits system. The issue becomes clear when I try to make a ldapsearch in these DBs(bdb1 and bdb2). If I do it the memory usage by slapd start to increase until all possible memory be allocated and system start to paging. After sometime slapd cannot allocate anymore memory using malloc and slapd crashes. After I put the cache this behavior is taking a little longer but not much longer. It ends memory in around 1 hour. Even if I stop the ldapsearch the memory previously allocated by slad isn't released and the process can be seen in the machine top with a lot of allocated memory. The only way to release this memory is to stop slapd process manually. I beleive there is a memory leakage but I could not identify where. My tentatives to used dmalloc were not successful and then I would like to report this bug. Your expertise identifying if the correct patches are really applied into the openldap2.4.11 is really important to solve this issue. Please let me know if you need more information. Regards, Rodrigo Costa.

1 0

Re: (ITS#5856) adauth overlay contribution
by andrew.findlay＠skills-1st.co.uk 15 Dec '08

15 Dec '08

On Fri, Dec 12, 2008 at 07:31:47PM +0000, kartik_subbarao(a)hp.com wrote: > As discussed with Howard Chu, HP is contributing the code for an Active > Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP. > > The adauth overlay provides passthrough authentication to Active Directory for > LDAP simple bind operations. The local LDAP entry referenced in the bind > operation is mapped to its counterpart in the Active Directory, an LDAP bind > operation is performed against Active Directory, and results are returned based > on the results of that remote operation. If a local userPassword attribute is > populated for the entry, it is used instead of the AD authentication. This is very good news, as it deals with a common requirement without having to configure saslauthd. One suggestion following a very quick scan of the code: I think it would be worth bringing the warning about turning off TLS checks into the manual page. It is worth noting that this overlay raises issues similar to those raised by the contributed adpwc/extpwc module - see ITS#5042. In this case the access to AD is via LDAP rather than Kerberos, but most of the arguments are similar. In particular, there is no reason for this to be AD-specific and it should be easy to adapt it to authenticate against any [collection of] remote LDAP servers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5859) back-hdb entrycache problem
by quanah＠OpenLDAP.org 15 Dec '08

15 Dec '08

--On Monday, December 15, 2008 4:16 PM +0000 openldap-its(a)OpenLDAP.org wrote: Appears to be broken in 2.4.13 as well. Search prior to adding zimbra-3 entry: [zimbra@freelancer ~]$ ldapsearch -x -h freelancer -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" -W # com_zimbra_license, zimlets, zimbra dn: cn=com_zimbra_license,cn=zimlets,cn=zimbra zimbraZimletTarget: admin-main zimbraZimletDescription: License Management for Admin UI zimbraZimletVersion: 5.2 objectClass: zimbraZimletEntry zimbraZimletIndexingEnabled: TRUE zimbraZimletKeyword: com_zimbra_license cn: com_zimbra_license zimbraZimletIsExtension: TRUE zimbraZimletPriority: 1 zimbraZimletEnabled: TRUE # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 Then we add the new entry: [zimbra@freelancer ~]$ ldapadd -f /tmp/test.ldif -x -h freelancer -D "uid=zimbra,cn=admins,cn=zimbra" -W Enter LDAP Password: adding new entry "cn=zimbra-3,cn=zimlets,cn=zimbra" Now we search again: # com_zimbra_license, zimlets, zimbra dn: cn=com_zimbra_license,cn=zimlets,cn=zimbra zimbraZimletTarget: admin-main zimbraZimletDescription: License Management for Admin UI zimbraZimletVersion: 5.2 objectClass: zimbraZimletEntry zimbraZimletIndexingEnabled: TRUE zimbraZimletKeyword: com_zimbra_license cn: com_zimbra_license zimbraZimletIsExtension: TRUE zimbraZimletPriority: 1 zimbraZimletEnabled: TRUE # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 Same result, this is bad. Now we stop/restart slapd: [zimbra@freelancer ~]$ ldap stop Killing slapd with pid 15613 done. [zimbra@freelancer ~]$ ldap start Started slapd: pid 20224 search again: # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # zimbra-3, zimlets, zimbra dn: cn=zimbra-3,cn=zimlets,cn=zimbra cn: zimbra-3 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 And there is our missing entry. --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

(ITS#5859) back-hdb entrycache problem
by quanah＠OpenLDAP.org 15 Dec '08

15 Dec '08

Full_Name: Quanah Gibson-Mount Version: 2.4.13+patches OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In using 2.4.13 + the slapadd fix from Ralf, ITS#5841, ITS#5842,ITS#5849,ITS#5850, ITS#5854, I found the following: Create an database with back-hdb with a few subtrees, with several entries under that subtree (My database is rooted at "". I have a "cn=zimbra" tree, with "cn=zimlets,cn=zimbra" underneath it). Now, create a brand new entry under one of those subtrees. The new entry will not be returned in queries rooted at the upper level ("cn=zimbra"). It will show up at its level ("cn=zimlets,cn=zimbra"). If you stop/restart slapd to flush the entry/idl cache, things work correctly.

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 15 Dec '08

15 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-3551-1229353986-0001-2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I spoke too soon, both on Solaris and on Linux I still get reproducable segfaults with 2.4.13 as soon as I use a ppolicy overlay in my configuration and query the directory. I have a public shellbox available which has the config loaded Mark --=_server11-3551-1229353986-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJRnQBb6urvDV9IXgRAt7aAKCC3GveYtw6mHaWWi/EkStXn6YtFwCeIKNx mFaCqgogqL0dkjGJQ6mul4s= =ADsB -----END PGP SIGNATURE----- --=_server11-3551-1229353986-0001-2--

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 15 Dec '08

15 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-2243-1229351458-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can reproduce this problem also on Linux/amd64 (Debian Testing) with OpenLDAP 2.4.11. I can confirm that it is FIXED on OpenLDAP 2.4.13 on Linux (and am now compiling it on Solaris) Mark --=_server11-2243-1229351458-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklGaiIACgkQb6urvDV9IXiCRQCgoNI6qsFg+gORmzPaYtWLSmmE higAoI2Cq0G0HQevFuC6Q7y1L/62geES =FKcN -----END PGP SIGNATURE----- --=_server11-2243-1229351458-0001-2--

1 0

(ITS#5858) Segfault with overlay ppolicy
by maniac-openldap＠maniac.nl 15 Dec '08

15 Dec '08

Full_Name: Mark Janssen Version: 2.4.11 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.64.241.2) Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 3] over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 394 return overlay_entry_get_ov( op, dn, oc, ad, rw, e, on ); (gdb) bt full #0 over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 oi = (slap_overinfo *) 0x293788 on = (slap_overinst *) 0x275148 #1 0x0009b8a8 in fe_entry_get_rw (op=Cannot access memory at address 0xfcfffec0 ) at frontend.c:62 bd = Cannot access memory at address 0xfcfffe88 (gdb) info threads 4 LWP 4 0xfe3c4a9c in __lwp_park () from /lib/libc.so.1 * 3 LWP 3 over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 2 LWP 2 0xfe3c57c8 in __pollsys () from /lib/libc.so.1 1 LWP 1 0xfe3c5c1c in __lwp_wait () from /lib/libc.so.1 (gdb) As soon as I enable 'ppolicy' I get a segfault when I login (with lbe) to the ldap server. Repeatable 100% (goes away when I remove ppolicy overlay from slapd.conf) Config snippet: overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=domain,dc=tld" ppolicy_hash_cleartext

1 0

(ITS#5856) adauth overlay contribution
by kartik_subbarao＠hp.com 12 Dec '08

12 Dec '08

Full_Name: Kartik Subbarao Version: 2.4 OS: Red Hat Enterprise Linux URL: ftp://ftp.openldap.org/incoming/adauth.tar.gz Submission from: (NULL) (76.99.180.78) As discussed with Howard Chu, HP is contributing the code for an Active Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP. The adauth overlay provides passthrough authentication to Active Directory for LDAP simple bind operations. The local LDAP entry referenced in the bind operation is mapped to its counterpart in the Active Directory, an LDAP bind operation is performed against Active Directory, and results are returned based on the results of that remote operation. If a local userPassword attribute is populated for the entry, it is used instead of the AD authentication.

1 0

(ITS#5855) slapd crash at hang or shutdown
by carlcarl＠comcast.net 12 Dec '08

12 Dec '08

Full_Name: Carl Traub Version: all ? OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.202.248.52) On Windows,I have found that by simply starting slapd, waiting a few minutes for it to get fully loaded, and then hitting Ctrl-C, slapd will often hang and not terminate properly. It occasionally crashed, and that may been related. The problem is that in slapd_daemon_destroy(), tcp_close() was being called for both wake_sds[1] and wake_sds[0], and the 2 values were always the same. This meant that Windows was being asked to close a connection that had already been closed and was no longer valid. A coworker stated that on Windows, these 2 values are always the same, but he thought that on Unix they would always be different. I uploaded the diff file "carlTraub-121208.diff". I wasn't clear on using the diff tool. Below is the diff. --- P:\temp\daemon.c_bef Fri Dec 12 10:05:38 2008 +++ P:\temp\daemon.c_after Fri Dec 12 10:24:30 2008 @@ -1645,14 +1645,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); + // If the 2 connections are actually the same, closing it twice can cause bad things, like hangs or crashes. + // It may be that they are always the same on Windows, always different on Unix. + if (wake_sds[1] != wake_sds[0] ) { #ifdef HAVE_WINSOCK + if ( wake_sds[1] != INVALID_SOCKET ) - if ( wake_sds[1] != INVALID_SOCKET ) #endif /* HAVE_WINSOCK */ + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + } - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); #ifdef HAVE_WINSOCK if ( wake_sds[0] != INVALID_SOCKET ) #endif /* HAVE_WINSOCK */

1 0

Re: (ITS#5854) Double send response in meta backend
by ando＠sys-net.it 12 Dec '08

12 Dec '08

jorge.perez(a)adaptia.net wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.11 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz > Submission from: (NULL) (194.237.142.20) > > > Meta backend send two response codes when trying to reconnect to other slapd. > > Steps to reproduce: > Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough > meta backend. Do some traffic operations. Restart slapd_B and do some modify, > delete or add operation, response code 52 is received although the operation is > sucessful. Using a tcpdump you can see two response codes for the request. > > I attach a possible patch for this issue. Thanks. I've committed an alternative fix to this issue, in line with the analogous code in back-ldap. It makes use of the specific bit of the ldap_back_send_t mask instead of an additional argument. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote: >> Andrew Bartlett wrote: >>> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >>>> A tentative implementation is in HEAD, please test. You need to: >>> Thankyou very much. I downloaded CVS HEAD and tested it out (finally - >>> the Samba4 side of the implementation took far longer than I expected). >>> >>>> - configure as --enable-deref >>>> >>>> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >>>> work as global overlay yet, sorry). >>> This is something Samba4 will need, as many of our links are >>> cross-database. But fixing this for a single DB is a big help in any >>> case. >>> >>>> - run searches like >>>> >>>> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' >>>> >>>> you'll see results like >>> When using Samba4's client, it seems to work, but it is as if it extends >>> the control to the full expected length, but not the data. Ie, attached >>> this is the control response I got back from the 'make testenv' >>> environment in Samba4. I've also attached the full LDAP request. >>> >>> The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 >>> parsing bug). >> I've found the bug (erroneous manipulation of octet strings containing >> '\0' octets). The objectSid is octet string-valued. Should be fixed >> now; please test. > > While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's > implementation matches your IETF draft (if not, an education on subtle > details of ASN.1 will be appreciated) > > draft-masarati-ldap-deref-00 > > >> 2.3. Control Response >> >> >> The control type is deref-oid (IANA assigned; see Section 6). The >> specification of the Dereference Control response is: >> >> controlValue ::= SEQUENCE OF derefRes DerefRes >> >> DerefRes ::= SEQUENCE { >> derefAttr AttributeDescription, >> derefVal LDAPDN, >> attrVals [0] PartialAttributeList OPTIONAL } >> >> PartialAttributeList ::= SEQUENCE OF >> partialAttribute PartialAttribute >> >> PartialAttribute is defined in [RFC4511]; the definition is reported >> here for clarity: >> >> PartialAttribute ::= SEQUENCE { >> type AttributeDescription, >> vals SET OF value AttributeValue } >> > > the output of dumpasn1 on the control: > >> 0 983: SEQUENCE { >> 4 168: SEQUENCE { >> 7 8: OCTET STRING 'memberOf' >> 17 56: OCTET STRING >> : 'cn=Enterprise Admins,cn=Users,dc=samba,dc=exampl' >> : 'e,dc=com' >> 75 98: [0] { >> 77 51: SEQUENCE { > > Shouldn't there be another SEQUENCE { here? Well, that was my intention when I ber_printf("{{OOt{{O[W]}{O[W]}}}}"), which, AFAIK, means: "{" SEQUENCE "{" SEQUENCE "OO" derefAttr, derefVal "t" [0] "{" SEQUENCE "{O[W]}" SEQUENCE, type, SET OF vals Am I missing anything? Couldn't "[0] {" be a shortcut in dumpasn1 to indicate SEQUENCE OF and the presence of a context+constructed tag? Looking at the raw data of an example, I see a sequence 240 126 060 063 004 011 which means: 240 context + constructed 126 (the length, 86 octets) 060 sequence 063 (the length, 51 octets) 004 octet string 011 (the length, 9 octets: "entryUUID") I'm not an expert in ASN.1, but from what I infer by looking at LDAP specs and at OpenLDAP implementation, this is consistent with the way similar cases are dealt with (e.g. the "Controls" at the end of a request message). p. > >> 79 9: OCTET STRING 'entryUUID' >> 90 38: SET { >> 92 36: OCTET STRING >> '24476f18-5c24-102d-9945-7320c1040f54' >> : } >> : } >> 130 43: SEQUENCE { >> 132 9: OCTET STRING 'objectSid' >> 143 30: SET { >> 145 28: OCTET STRING >> : 01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B >> : 16 72 AE E6 53 BE 65 6F 07 02 00 00 >> : } >> : } >> : } >> : } >> > > Thanks, > > Andrew Bartlett > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5854) Double send response in meta backend
by ando＠sys-net.it 11 Dec '08

11 Dec '08

hyc(a)symas.com wrote: > Thanks for your report. Sounds a lot like ITS#4782... Howard, the proposed fix is fine, but I think the issue is better addressed in back-ldap by means of the ldap_back_send_t mask without the need of an additional argument. I'm testing a different fix. p. > On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: >> Full_Name: Jorge Perez Burgos >> Version: 2.4.11 >> OS: SLES 10 >> URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz >> Submission from: (NULL) (194.237.142.20) >> >> >> Meta backend send two response codes when trying to reconnect to other slapd. >> >> Steps to reproduce: >> Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough >> meta backend. Do some traffic operations. Restart slapd_B and do some modify, >> delete or add operation, response code 52 is received although the operation is >> sucessful. Using a tcpdump you can see two response codes for the request. >> >> I attach a possible patch for this issue. >> >> > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5854) Double send response in meta backend
by hyc＠symas.com 11 Dec '08

11 Dec '08

Thanks for your report. Sounds a lot like ITS#4782... On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.11 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz > Submission from: (NULL) (194.237.142.20) > > > Meta backend send two response codes when trying to reconnect to other slapd. > > Steps to reproduce: > Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough > meta backend. Do some traffic operations. Restart slapd_B and do some modify, > delete or add operation, response code 52 is received although the operation is > sucessful. Using a tcpdump you can see two response codes for the request. > > I attach a possible patch for this issue. > >

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-3TUJtt6yg+CvD9VzraMk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. >=20 > Apparently this was fixed during the overlay's shakedown, as it seems to=20 > work as expected when only instantiated as global. In fact, nothing was=20 > preventing it from working this way by design, it only didn't work at=20 > some point of its evolution. Please test. Indeed, it works well as a global. Thanks! My only issue remaining is the clarification over the ASN.1 encoding of the control. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-3TUJtt6yg+CvD9VzraMk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQdk5z4A8Wyi0NrsRAiiOAKCUywnlFS2RIZlclADU/woC7id7OwCfbfwD fh4vPeyWTWqBYACEYVFgdZA= =UdNB -----END PGP SIGNATURE----- --=-3TUJtt6yg+CvD9VzraMk--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-WGywWWDfCXc78PSX7dDA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. > >=20 > >> - run searches like > >> > >> $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >> > >> you'll see results like > >=20 > > When using Samba4's client, it seems to work, but it is as if it extend= s > > the control to the full expected length, but not the data. Ie, attache= d > > this is the control response I got back from the 'make testenv' > > environment in Samba4. I've also attached the full LDAP request. > >=20 > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > > parsing bug). >=20 > I've found the bug (erroneous manipulation of octet strings containing=20 > '\0' octets). The objectSid is octet string-valued. Should be fixed=20 > now; please test. While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's implementation matches your IETF draft (if not, an education on subtle details of ASN.1 will be appreciated) draft-masarati-ldap-deref-00 > 2.3. Control Response >=20 >=20 > The control type is deref-oid (IANA assigned; see Section 6). The > specification of the Dereference Control response is: >=20 > controlValue ::=3D SEQUENCE OF derefRes DerefRes >=20 > DerefRes ::=3D SEQUENCE { > derefAttr AttributeDescription, > derefVal LDAPDN, > attrVals [0] PartialAttributeList OPTIONAL } >=20 > PartialAttributeList ::=3D SEQUENCE OF > partialAttribute PartialAttribute >=20 > PartialAttribute is defined in [RFC4511]; the definition is reported > here for clarity: >=20 > PartialAttribute ::=3D SEQUENCE { > type AttributeDescription, > vals SET OF value AttributeValue } >=20 the output of dumpasn1 on the control: > 0 983: SEQUENCE { > 4 168: SEQUENCE { > 7 8: OCTET STRING 'memberOf' > 17 56: OCTET STRING > : 'cn=3DEnterprise Admins,cn=3DUsers,dc=3Dsamba,dc=3Dexamp= l' > : 'e,dc=3Dcom' > 75 98: [0] { > 77 51: SEQUENCE { Shouldn't there be another SEQUENCE { here? > 79 9: OCTET STRING 'entryUUID' > 90 38: SET { > 92 36: OCTET STRING > '24476f18-5c24-102d-9945-7320c1040f54' > : } > : } > 130 43: SEQUENCE { > 132 9: OCTET STRING 'objectSid' > 143 30: SET { > 145 28: OCTET STRING > : 01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B > : 16 72 AE E6 53 BE 65 6F 07 02 00 00 > : } > : } > : } > : } >=20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-WGywWWDfCXc78PSX7dDA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQa1Nz4A8Wyi0NrsRAtyAAJ9Dqzqn3DknKqThzy7KML5Z+i/h2wCfZ2nM d8HdE9UXPLaN2DZRwIseCk0= =HFZS -----END PGP SIGNATURE----- --=-WGywWWDfCXc78PSX7dDA--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. Apparently this was fixed during the overlay's shakedown, as it seems to work as expected when only instantiated as global. In fact, nothing was preventing it from working this way by design, it only didn't work at some point of its evolution. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. > >> - run searches like >> >> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' >> >> you'll see results like > > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). I've found the bug (erroneous manipulation of octet strings containing '\0' octets). The objectSid is octet string-valued. Should be fixed now; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5854) Double send response in meta backend
by jorge.perez＠adaptia.net 11 Dec '08

11 Dec '08

Full_Name: Jorge Perez Burgos Version: 2.4.11 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz Submission from: (NULL) (194.237.142.20) Meta backend send two response codes when trying to reconnect to other slapd. Steps to reproduce: Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough meta backend. Do some traffic operations. Restart slapd_B and do some modify, delete or add operation, response code 52 is received although the operation is sucessful. Using a tcpdump you can see two response codes for the request. I attach a possible patch for this issue.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-svDYOuAyXlEqIDWU48Ko Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 12:22 +1100, Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > > A tentative implementation is in HEAD, please test. You need to: >=20 > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). >=20 > > - configure as --enable-deref > >=20 > > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > > work as global overlay yet, sorry). >=20 > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. >=20 > > - run searches like > > > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >=20 > > you'll see results like >=20 > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. >=20 > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). >=20 > I can make the Samba4 tree that reproduces this available as a GIT > repository if you like. =20 To reproduce: In a checkout from git://git.samba.org/abartlet/samba.git master run: OPENLDAP_ROOT=3D/usr/local/ TEST_LDAP=3Dyes make testenv Then in the xterm that pops up, run: bin/ldbsearch -H ldap://localdc1 cn=3Dadministrator --controls=3Dextended_dn:1:1 This will not return the extended DN (compare with TEST_LDAP=3Dno), because it fails to parse the returned control in libcli/ldap/ldap_controls.c (I suspect my parser also needs work) Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-svDYOuAyXlEqIDWU48Ko Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQJosz4A8Wyi0NrsRAuLgAJwIYEfeK/rj9xXw+/2KiVhDPw6bvwCeJwaj Q/I64Xu6suP53nnqNT6Bkv0= =GSzF -----END PGP SIGNATURE----- --=-svDYOuAyXlEqIDWU48Ko--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-3DGTDdLilVnhuysLkRP/ Content-Type: multipart/mixed; boundary="=-vUh+QDuuW5KKlkVC19pp" --=-vUh+QDuuW5KKlkVC19pp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > A tentative implementation is in HEAD, please test. You need to: Thankyou very much. I downloaded CVS HEAD and tested it out (finally - the Samba4 side of the implementation took far longer than I expected). > - configure as --enable-deref >=20 > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > work as global overlay yet, sorry). This is something Samba4 will need, as many of our links are cross-database. But fixing this for a single DB is a big help in any case. > - run searches like > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' >=20 > you'll see results like When using Samba4's client, it seems to work, but it is as if it extends the control to the full expected length, but not the data. Ie, attached this is the control response I got back from the 'make testenv' environment in Samba4. I've also attached the full LDAP request. The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 parsing bug). I can make the Samba4 tree that reproduces this available as a GIT repository if you like. =20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=control Content-Type: application/octet-stream; name=control Content-Transfer-Encoding: base64 MIIDnzCBqAQIbWVtYmVyT2YEOGNuPUVudGVycHJpc2UgQWRtaW5zLGNuPVVzZXJzLGRjPXNhbWJh LGRjPWV4YW1wbGUsZGM9Y29toGIwMwQJZW50cnlVVUlEMSYEJGU4MmNiMjE4LTViNmEtMTAyZC05 MDk4LTU1MGYxMWFkZWE4OTArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA== --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=request Content-Type: application/octet-stream; name=request Content-Transfer-Encoding: base64 MIINiwIBBmOBvQQaREM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20KAQIKAQACAQACAQABAQCgKqIT oxEECWlzRGVsZXRlZAQEVFJVRaMTBAJjbgQNYWRtaW5pc3RyYXRvcjBkBAlpc0RlbGV0ZWQEAmNu BAEqBAllbnRyeVVVSUQED2NyZWF0ZVRpbWVzdGFtcAQPbW9kaWZ5VGltZXN0YW1wBA9jcmVhdGVU aW1lc3RhbXAECGVudHJ5Q1NOBAhtZW1iZXJPZqCCDMQwggzABBkxLjMuNi4xLjQuMS40MjAzLjY2 Ni41LjE2BIIMoTCCDJ0wIQQHb3duZXJCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAiBAhtZW1i ZXJPZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAtBBNub25TZWN1cml0eU1lbWJlckJMMBYECWVu dHJ5VVVJRAQJb2JqZWN0U0lEMCsEEWROUmVmZXJlbmNlVXBkYXRlMBYECWVudHJ5VVVJRAQJb2Jq ZWN0U0lEMCQECnNpdGVPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRaXNQcml2aWxl Z2VIb2xkZXIwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2VydmVyUmVmZXJlbmNlQkwwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLZE1ETG9jYXRpb24wFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwKwQRcXVlcnlQb2xpY3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJYXNzaXN0 YW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDEEF21zRFMtTWVtYmVyc0ZvckF6Um9sZUJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED2xhc3RLbm93blBhcmVudDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAnBA1mU01PUm9sZU93bmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCgEDm1zQ09N LVVzZXJMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCQECm1hc3RlcmVkQnkwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwMwQZbXNEUy1OQy1SZXBsaWNhLUxvY2F0aW9uczAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAuBBRpcHNlY0lTQUtNUFJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJ RDAhBAdzZWVBbHNvMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCYEDGhhc01hc3Rlck5DczAWBAll bnRyeVVVSUQECW9iamVjdFNJRDAuBBRmUlNNZW1iZXJSZWZlcmVuY2VCTDAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAwBBZtc0RTLVNEUmVmZXJlbmNlRG9tYWluMBYECWVudHJ5VVVJRAQJb2JqZWN0 U0lEMCoEEG5vdGlmaWNhdGlvbkxpc3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLcHJlZmVy cmVkT1UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPbXNEUy1Ob25NZW1iZXJzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMC8EFW1zRFMtVGFza3NGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDArBBFpcHNlY05GQVJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAjBAlz ZWNyZXRhcnkwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwMAQWYnJpZGdlaGVhZFNlcnZlckxpc3RC TDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAqBBBySURTZXRSZWZlcmVuY2VzMBYECWVudHJ5VVVJ RAQJb2JqZWN0U0lEMDAEFmZyc0NvbXB1dGVyUmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmpl Y3RTSUQwNAQabXNDT00tVXNlclBhcnRpdGlvblNldExpbmswFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwLwQVbXNEUy1UYXNrc0ZvckF6VGFza0JMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCMECW1h bmFnZWRCeTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAvBBVkZWZhdWx0T2JqZWN0Q2F0ZWdvcnkw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRbm9uU2VjdXJpdHlNZW1iZXIwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwIAQGbWVtYmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCsEEXN1YlNjaGVt YVN1YkVudHJ5MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDIEGGRlZmF1bHRMb2NhbFBvbGljeU9i amVjdDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDArBBFkeW5hbWljTERBUFNlcnZlcjAWBAllbnRy eVVVSUQECW9iamVjdFNJRDArBBFtc0RTLU5vbk1lbWJlcnNCTDAWBAllbnRyeVVVSUQECW9iamVj dFNJRDAoBA5kb21haW5Dcm9zc1JlZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDA0BBptc0RTLU9w ZXJhdGlvbnNGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAsBBJkb21haW5Qb2xp Y3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQOb2JqZWN0Q2F0ZWdvcnkwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwLgQUaGFzUGFydGlhbFJlcGxpY2FOQ3MwFgQJZW50cnlVVUlEBAlv YmplY3RTSUQwJgQMc2l0ZU9iamVjdEJMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCcEDXF1ZXJ5 UG9saWN5QkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRZGlzdGluZ3Vpc2hlZE5hbWUwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwMQQXYnJpZGdlaGVhZFRyYW5zcG9ydExpc3QwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwNAQabXNEUy1PcGVyYXRpb25zRm9yQXpUYXNrQkwwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwKwQRbXNEUy1oYXNNYXN0ZXJOQ3MwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQw KwQRZGVmYXVsdENsYXNzU3RvcmUwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2hvd0luQWRk cmVzc0Jvb2swFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwLgQUaXBzZWNPd25lcnNSZWZlcmVuY2Uw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPc2VydmVyUmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJ b2JqZWN0U0lEMCsEEW1zRFMtSGFzRG9tYWluTkNzMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC4E FG1zRFMtT2JqZWN0UmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDAEFm1zRFMtT2Jq ZWN0UmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJgQMbmV0Ym9vdFNDUEJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED21zRHMtbWFzdGVyZWRCeTAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAwBBZtc0NPTS1QYXJ0aXRpb25TZXRMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE MCYEDGRlZmF1bHRHcm91cDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAuBBRpcHNlY0ZpbHRlclJl ZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAnBA1kaXJlY3RSZXBvcnRzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCUEC3RydXN0UGFyZW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC0E E3JJRE1hbmFnZXJSZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIQQHbWFuYWdlcjAW BAllbnRyeVVVSUQECW9iamVjdFNJRDAwBBZwaHlzaWNhbExvY2F0aW9uT2JqZWN0MBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCEEB3N1YlJlZnMwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJcm9v dFRydXN0MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDkEH2lwc2VjTmVnb3RpYXRpb25Qb2xpY3lS ZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQObWFuYWdlZE9iamVjdHMwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwIAQGbkNOYW1lMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=response Content-Type: application/octet-stream; name=response Content-Transfer-Encoding: base64 MIITbwIBBmSCD54ENGNuPUFkbWluaXN0cmF0b3IsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20wgg9kMBUEAmNuMQ8EDUFkbWluaXN0cmF0b3IwRwQLZGVzY3JpcHRpb24xOAQ2QnVp bHQtaW4gYWNjb3VudCBmb3IgYWRtaW5pc3RlcmluZyB0aGUgY29tcHV0ZXIvZG9tYWluMB0EEnVz ZXJBY2NvdW50Q29udHJvbDEHBAU2NjA0ODArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAUVAAAAUZnM kG8t4Wyarf059AEAADARBAphZG1pbkNvdW50MQMEATEwJwQOYWNjb3VudEV4cGlyZXMxFQQTOTIy MzM3MjAzNjg1NDc3NTgwNzAhBA5zQU1BY2NvdW50TmFtZTEPBA1BZG1pbmlzdHJhdG9yMCAEFmlz Q3JpdGljYWxTeXN0ZW1PYmplY3QxBgQEVFJVRTAcBAlzYW1iYTRSRE4xDwQNQWRtaW5pc3RyYXRv cjBDBAtvYmplY3RDbGFzczE0BAN0b3AEBnBlcnNvbgQUb3JnYW5pemF0aW9uYWxQZXJzb24EBHVz ZXIECXNhbWJhNFRvcDBTBA5vYmplY3RDYXRlZ29yeTFBBD9jbj1QZXJzb24sY249U2NoZW1hLGNu PUNvbmZpZ3VyYXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20wggPGBBRuVFNlY3VyaXR5 RGVzY3JpcHRvcjGCA6wEggOoAQAEgBQAAAAgAAAAAAAAADAAAAABAQAAAAAABRIAAAABAgAAAAAA BSAAAAAgAgAABAB4AxcAAAAAACQA/wEPAAEFAAAAAAAFFQAAAFGZzJBvLeFsmq39OQACAAAAABQA /wEPAAEBAAAAAAAFEgAAAAAAGAD/AQ8AAQIAAAAAAAUgAAAAJAIAAAAAFACUAAIAAQEAAAAAAAUK AAAABQAoAAABAAABAAAAUxpyqy8e0BGYGQCqAEBSmwEBAAAAAAAFCgAAAAUAKAAAAQAAAQAAAFQa cqsvHtARmBkAqgBAUpsBAQAAAAAABQoAAAAFACgAAAEAAAEAAABWGnKrLx7QEZgZAKoAQFKbAQEA AAAAAAUKAAAABQAoADAAAAABAAAAhri1d0qU0RGuvQAA+ANnwQEBAAAAAAAFCgAAAAUAKAAwAAAA AQAAALKVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQoAAAAFACgAMAAAAAEAAACzlVfkVZTREa69AAD4 A2fBAQEAAAAAAAUKAAAABQAsABAAAAABAAAA+IhwA+EK0hG0IgCgyWj5OQECAAAAAAAFIAAAACkC AAAFACwAEAAAAAEAAAAAQhZMwCDQEadoAKoAbgUpAQIAAAAAAAUgAAAAKQIAAAUALAAQAAAAAQAA AEDCCrypedARkCAAwE/C1M8BAgAAAAAABSAAAAApAgAAAAAUAAAAAgABAQAAAAAABQsAAAAFACgA EAAAAAEAAABCL7pZonnQEZAgAMBPwtPPAQEAAAAAAAULAAAABQAoABAAAAABAAAAhri1d0qU0RGu vQAA+ANnwQEBAAAAAAAFCwAAAAUAKAAQAAAAAQAAALOVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQsA AAAFACgAEAAAAAEAAABUAY3k+LzREYcCAMBPuWBQAQEAAAAAAAULAAAABQAoAAABAAABAAAAUxpy qy8e0BGYGQCqAEBSmwEBAAAAAAABAAAAAAUALAAQAAAAAQAAABAgIF+ledARkCAAwE/C1M8BAgAA AAAABSAAAAApAgAABQA4ADAAAAABAAAAf3qWv+YN0BGihQCqADBJ4gEFAAAAAAAFFQAAAFGZzJBv LeFsmq39OQUCAAAFACwAEAAAAAEAAAAdsalGrmBaQLfo/4pY1FbSAQIAAAAAAAUgAAAAMAIAAAUA LAAwAAAAAQAAAByatm0ilNERrr0AAPgDZ8EBAgAAAAAABSAAAAAxAgAAMBIEC2JhZFB3ZENvdW50 MQMEATAwDwQIY29kZVBhZ2UxAwQBMDASBAtjb3VudHJ5Q29kZTEDBAEwMBYED2JhZFBhc3N3b3Jk VGltZTEDBAEwMBEECmxhc3RMb2dvZmYxAwQBMDAQBAlsYXN0TG9nb24xAwQBMDAXBA5wcmltYXJ5 R3JvdXBJRDEFBAM1MTMwEQQKbG9nb25Db3VudDEDBAEwMB0EDnNBTUFjY291bnRUeXBlMQsECTgw NTMwNjM2ODAgBAp1bmljb2RlUHdkMRIEEFbmq7Kw6TnpZ8QxgOHGErcwHQQHZEJDU1B3ZDESBBBX Elb3c3RGQrJn3yLLlF4+MCIEDG50UHdkSGlzdG9yeTESBBBW5quysOk56WfEMYDhxhK3MCIEDGxt UHdkSGlzdG9yeTESBBBXElb3c3RGQrJn3yLLlF4+MIIGIgQXc3VwcGxlbWVudGFsQ3JlZGVudGlh bHMxggYFBIIGAQAAAAD0BQAAAAAAACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgAFAAAwAgADABAQBQAHIAaQBtAGEAcgB5ADoASwBlAHIAYgBlAHIAbwBzADAzMDAwMDAwMDIw MDAwMDAzQzAwM0MwMDRDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzMDAwMDAwMDgwMDAwMDA4ODAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMTAwMDAwMDA4MDAwMDAwOTAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwNTMwMDQxMDA0RDAwNDIwMDQxMDAyRTAwNDUwMDU4 MDA0MTAwNEQwMDUwMDA0QzAwNDUwMDJFMDA0MzAwNEYwMDREMDA0MTAwNjQwMDZEMDA2OTAwNkUw MDY5MDA3MzAwNzQwMDcyMDA2MTAwNzQwMDZGMDA3MjAwNzk0OUNCRkJGNDBCMjM0OTc5NDlDQkZC RjQwQjIzNDkQAEAAAgBQAGEAYwBrAGEAZwBlAHMANEIwMDY1MDA3MjAwNjIwMDY1MDA3MjAwNkYw MDczMDAwMDAwNTcwMDQ0MDA2OTAwNjcwMDY1MDA3MzAwNzQwMB4AwAMBAFAAcgBpAG0AYQByAHkA OgBXAEQAaQBnAGUAcwB0ADMxMDAwMTFEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwRUI2RjczQUZC QzMzOTYxNEVFNjQ3MUZDMEVEQ0FEN0VBMTk5RThCRjEwNDc5NzJCMjE1NzUwNEM0RUM4OUJCM0M1 MERFNDc4OTk5OEQwODdCQkJCQkFFREVGMjE3OUVGRUI2RjczQUZCQzMzOTYxNEVFNjQ3MUZDMEVE Q0FEN0U4MjNERDkxRUQ2NzI1NjU3RUUxQTNDRDQ0NTFGRTZGRTFFOEU0OEEyMjYxNTYwNDcwQzkz MUQwMTAxM0I3OEYzRDI4QzI1RjU1Nzk2QzhFM0FDRjIwQURFNjZGRTMwMDY4NjNGOTA4QTE2RkZG QzZFQTAzM0Q1OTFERkQzRUJGRjlGRjI3OEU1NEM2NjQ1MzM2RTcyNUM5NkNDQkJDMUZGQkM3QTA0 QUI5QTg3NzVCQkIyRkExMEQ0RkQ0QkY0MUIxNTY1QjJFMzNCRjA4ODUzMjI2MDVDQTRERTM2NEU3 Qzg2M0Y5MDhBMTZGRkZDNkVBMDMzRDU5MURGRDNFQkZGNjI5NzU5N0MxNThBNzA4QTM4MEVDOTZE MTY0MzhERjZGMjAyQ0QwNUQ4QjcxRjgzQjBBQkY0OEMzOEFERjJGNDhBMTA0MzA1OEExNDU0RTk2 NUE0NjI5REYzMjZGMjQ4QkYxQUZFNkFDQTU0OEU0OEVBN0I1NUQ4ODJGMDY2MEE4QTMyRTI5RkQ0 RDMyMzI3Mjk1Qzk5QTUyQzA4NTY3NUZENDVCNTI2M0MxMDQ2NDhBQ0Y4QUNEQjExNDVFQ0JEQzMy OTc5RkQ4RjZCMkU0RTI0MkQ4N0JFRTlGMEREODVDMzA2NTZFQTJENTUyRjhCNEExNzQ5QTA0OTFD QTA2NDMwQkM2NjlCNjIwNDlEQTdGRkY5MzI5Nzc1RDk1QjZERTg3OUExMTg5QjM2QUNFNTlFMDEx MzNCQTJFNDM5RTJENzQ5MTYzRDI4MEI1Q0VEMDQyMEE4RTUyRERFMTkzRjRFM0Q2OUY5REQ4NThB ODBFQjI5NUY0ODEwOUQ3RDlCMkVFOUUyNzY0NTQxOTNERDgxOUUzNjg1RUVDM0VDMEI4MzRBRDQ3 OTk4NEM3MjUxNzRDNzk4NTNDNUZGMDkwRUE1Q0M0RjU5QjIzREEzOTBDMEM4MkMyRTEyMkQwOEM1 M0IxMjAzRTdDRkNBN0UzQjI2Q0Y1MkREQjczRjFBM0VGQzExQjdEREQ4M0YyREJERDgzMzY2RTM5 MEYwMkNGOQAwIgQKcHdkTGFzdFNldDEUBBIxMjg3MzQzMDg1NDAwMDAwMDAwHAQVbXNEUy1LZXlW ZXJzaW9uTnVtYmVyMQMEATEwEwQMaW5zdGFuY2VUeXBlMQMEATQwMwQJZW50cnlVVUlEMSYEJGU4 MDFjMTBjLTViNmEtMTAyZC05MDk2LTU1MGYxMWFkZWE4OTAkBA9jcmVhdGVUaW1lc3RhbXAxEQQP MjAwODEyMTEwMTAwNTRaMDYECGVudHJ5Q1NOMSoEKDIwMDgxMjExMDEwMDU0LjQwNjkzOFojMDAw MDAwIzAwMCMwMDAwMDAwJAQPbW9kaWZ5VGltZXN0YW1wMREEDzIwMDgxMjExMDEwMDU0WjCCATEE CG1lbWJlck9mMYIBIwQ4Y249RW50ZXJwcmlzZSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9 ZXhhbXBsZSxkYz1jb20ENGNuPVNjaGVtYSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhh bXBsZSxkYz1jb20ENGNuPURvbWFpbiBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20EQmNuPUdyb3VwIFBvbGljeSBDcmVhdG9yIE93bmVycyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbQQ3Y249QWRtaW5pc3RyYXRvcnMsY249QnVpbHRpbixkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaCCA8YwggPCBBkxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjE2BIID ozCCA58wgagECG1lbWJlck9mBDhjbj1FbnRlcnByaXNlIEFkbWlucyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaBiMDMECWVudHJ5VVVJRDEmBCRlODJjYjIxOC01YjZhLTEwMmQt OTA5OC01NTBmMTFhZGVhODkwKwQJb2JqZWN0U2lkMR4EHAEFAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-vUh+QDuuW5KKlkVC19pp-- --=-3DGTDdLilVnhuysLkRP/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQGs/z4A8Wyi0NrsRApYSAKCypwyLcW8Xy7h/bZm+jVgwfXsrzACgqKLt aQNMQH/eZvlH1z5jyZ7/FYA= =OLsg -----END PGP SIGNATURE----- --=-3DGTDdLilVnhuysLkRP/--

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by ando＠sys-net.it 10 Dec '08

10 Dec '08

jsafrane(a)redhat.com wrote: > Following ldapsearch crashes when referral chasing is enabled in very unusual > environment with many AD servers referring to each other (I had to increase > refhoplimit to chase all the referrals). Thanks for the detailed report. However, IMHO, automatic referral chasing Is Broken. Clients should explicitly chase them, possibly providing some interactive means for rebinding. This is what is currently done, for example, by slapd when using slapo-chain(5), and what should be done by proxy backends as well. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 09 Dec '08

09 Dec '08

Full_Name: Jan Safranek Version: 2.4.13 OS: Linux. Fedora 9, x86_64 URL: http://people.redhat.com/jsafrane/openldap-referral-crash/ Submission from: (NULL) (89.102.11.105) Following ldapsearch crashes when referral chasing is enabled in very unusual environment with many AD servers referring to each other (I had to increase refhoplimit to chase all the referrals). $ ldapsearch -x -C -D cn=uzivatelk,ou=Services,ou=BOUDA,ou=administrace,dc=broken,dc=net -w 'mojeheslo' -b "dc=broken,dc=net" -h f9 "(sAMAccountName=uzivatel)" ldapsearch: sockbuf.c:88: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)' failed. You can find the stack trace below and ldapsearch -d -1 output at http://people.redhat.com/jsafrane/openldap-referral-crash/, together with LDAP traffic in pcap format. IMO, if there are more referrals involved (A refers to B, which refers to C), wait4msg() and try_read1msg() functions are called recursively several times. When referral to C is being resolved, the stack looks like this: 1: try_read1msg 2: wait4msg 3: ldap_result ... 4: ldap_chase_v3referrals 5: try_read1msg 6: wait4msg 7: ldap_result ... 8: ldap_chase_v3referrals 9: try_read1msg 10: ldap_result 11: wait4msg 12: do_search 13: main Looking at the wait4msg(), result.c:393, it goes through all connections inside LDAP structure: for ( lc = ld->ld_conns; rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL; ) { if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { <...mutexes...> rc = try_read1msg( ld, msgid, all, &lc, result ); <...mutexes...> if ( lc == NULL ) { /* if lc gets free()'d, * there's no guarantee * lc->lconn_next is still * sane; better restart * (ITS#4405) */ lc = ld->ld_conns; /* don't get to next conn! */ break; } } /* next conn */ lc = lc->lconn_next; } And try_read1msg() can release the connection and change the list of connections, see result.c:944: ldap_free_connection( ld, lc, 0, 1 ); <...mutexes...> lc = *lcp = NULL; The calling wait4msg() expects that called try_read1msg() may free a connection and does not crash. But if more wait4msg() are called recursively, the "bottom ones", #6 and #11 in my stack example above, do not know about the change which try_read1msg() in #1 has made and can hold already freed 'lc' pointer -> crash. IMHO there should be some other check, that ensures that wait4msg() restarts the loop even if some inner try_read1msg() modifies the list. Or there could be some ldap_use_connecion() in try_read1msg() when referrals are being chased, so the connection does get freed only by the right try_read1msg() - #5 in my case and not #1. However, my knowledge of OpenLDAP internals is somewhat limited and I am not able to tell which way is the best. It's quite hard to reproduce the bug, the packets must arrive in the right order, so the connection to B is being freed when referral to C is being chased. I am not able to reproduce it in more controlled environment, the log is quite huge and it contains some other not so interesting referrals. The connection, which is freed too early, is connection to 'sec.broken.net' - look for the last 'ldap_free_connection: actually freed' in the log. I hope my explanation above is somewhat readable and I didn't confuse you too much :). Do not hesitate to ask for specific details. Here is the promised real stack trace. It asserts when the 'lc' in wait4msg() has been freed by previous call to try_read1msg. (gdb) bt full #0 0x0000003b49632215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003b49633d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003b4962b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000044d4b1 in ber_sockbuf_ctrl (sb=0x0, opt=8, arg=0x0) at sockbuf.c:88 p = (Sockbuf_IO_Desc *) 0x452f65 ret = 0 __PRETTY_FUNCTION__ = "ber_sockbuf_ctrl" #4 0x0000000000416222 in try_read1msg (ld=0x1b80fa0, msgid=18, all=1, lcp=0x7fffe4f67ae8, result=0x7fffe4f67be8) at result.c:1190 ber = (BerElement *) 0x1b8c040 newmsg = (LDAPMessage *) 0x1b91ca0 l = (LDAPMessage *) 0x0 prev = (LDAPMessage *) 0x1b8d370 id = 2 idx = 0 tag = 115 len = 78 foundit = 0 lr = (LDAPRequest *) 0x0 tmplr = (LDAPRequest *) 0x1b8d220 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} lc = (LDAPConn *) 0x1b8e3e0 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = -1}, ber_tag = 0, ber_len = 87, ber_usertag = 0, ber_buf = 0x1b8c0a0 "\002\001\005s\204", ber_ptr = 0x1b8c0f7 "", ber_end = 0x1b8c0f7 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 1 hadref = 1 simple_request = 0 err = 5 lderr = 1 __PRETTY_FUNCTION__ = "try_read1msg" bv_nod = {bv_len = 22, bv_val = 0x452b0b "1.3.6.1.4.1.1466.20036"} #5 0x0000000000414c67 in wait4msg (ld=0x1b80fa0, msgid=18, all=1, timeout=0x7fffe4f67bf0, result=0x7fffe4f67be8) at result.c:402 err = 0 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 100000} tv0 = {tv_sec = 0, tv_usec = 100000} start_time_tv = {tv_sec = 1228828417, tv_usec = 878311} tvp = (struct timeval *) 0x7fffe4f67b10 lc = (LDAPConn *) 0x1b8e3e0 __PRETTY_FUNCTION__ = "wait4msg" #6 0x0000000000414433 in ldap_result (ld=0x1b80fa0, msgid=18, all=1, timeout=0x7fffe4f67bf0, result=0x7fffe4f67be8) at result.c:127 lm = (LDAPMessage *) 0x0 rc = 18 __PRETTY_FUNCTION__ = "ldap_result" #7 0x0000000000428313 in ldap_new_connection (ld=0x1b80fa0, srvlist=0x7fffe4f67df0, use_ldsb=0, connect=1, bind=0x7fffe4f67dc0) at request.c:560 tv = {tv_sec = 0, tv_usec = 100000} res = (LDAPMessage *) 0x0 msgid = 18 rc = 0 passwd = {bv_len = 0, bv_val = 0x0} err = 1 savedefconn = (LDAPConn *) 0x1b8a380 lc = (LDAPConn *) 0x1b8c690 async = 0 __PRETTY_FUNCTION__ = "ldap_new_connection" ---Type <return> to continue, or q <return> to quit--- #8 0x00000000004276b5 in ldap_send_server_request (ld=0x1b80fa0, ber=0x1b8d290, msgid=17, parentreq=0x1b8a6e0, srvlist=0x7fffe4f67df0, lc=0x0, bind=0x7fffe4f67dc0) at request.c:207 lr = (LDAPRequest *) 0x1b8d290 incparent = 1 rc = 389 #9 0x0000000000429be6 in ldap_chase_v3referrals (ld=0x1b80fa0, lr=0x1b8cb40, refs=0x0, sref=1, errstrp=0x1b8cb70, hadrefp=0x7fffe4f67f2c) at request.c:1209 unfollowed = 0x0 unfollowedcnt = 0 origreq = (LDAPRequest *) 0x1b8a6e0 srv = (LDAPURLDesc *) 0x1b8c7b0 ber = (BerElement *) 0x1b8d290 refarray = (char **) 0x1b8c670 lc = (LDAPConn *) 0x0 rc = 0 count = 0 i = 0 j = 0 id = 17 rinfo = {ri_msgid = 2, ri_request = 99, ri_url = 0x1b91c30 "ldap://DomainDnsZones.sec.broken.net/DC=DomainDnsZones,DC=sec,DC=broken,DC=…"} #10 0x000000000041553d in try_read1msg (ld=0x1b80fa0, msgid=-1, all=0, lcp=0x7fffe4f680e8, result=0x7fffe4f68228) at result.c:729 refs = (char **) 0x1b8c670 ber = (BerElement *) 0x1b8ae00 newmsg = (LDAPMessage *) 0x0 l = (LDAPMessage *) 0x1e4f68080 prev = (LDAPMessage *) 0x7fffe4f68080 id = 2 idx = 0 tag = 115 len = 80 foundit = 0 lr = (LDAPRequest *) 0x1b8cb40 tmplr = (LDAPRequest *) 0x1b8a550 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} lc = (LDAPConn *) 0x1b8beb0 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = -1}, ber_tag = 0, ber_len = 89, ber_usertag = 0, ber_buf = 0x1b8c600 "\002\001\003s\204", ber_ptr = 0x1b8c659 "", ber_end = 0x1b8c659 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 err = 4 lderr = 1 __PRETTY_FUNCTION__ = "try_read1msg" bv_nod = {bv_len = 22, bv_val = 0x452b0b "1.3.6.1.4.1.1466.20036"} #11 0x0000000000414c67 in wait4msg (ld=0x1b80fa0, msgid=-1, all=0, timeout=0x0, result=0x7fffe4f68228) at result.c:402 err = 0 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 0, tv_usec = 0} tvp = (struct timeval *) 0x0 lc = (LDAPConn *) 0x1b8beb0 __PRETTY_FUNCTION__ = "wait4msg" #12 0x0000000000414433 in ldap_result (ld=0x1b80fa0, msgid=-1, all=0, timeout=0x0, result=0x7fffe4f68228) at result.c:127 lm = (LDAPMessage *) 0x0 rc = 100 __PRETTY_FUNCTION__ = "ldap_result" ---Type <return> to continue, or q <return> to quit--- #13 0x0000000000408dbf in dosearch (ld=0x1b80fa0, base=0x1b7f5e0 "dc=broken,dc=net", scope=2, filtpatt=0x0, value=0x7fffe4f6b881 "(sAMAccountName=uzivatel)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=-1) at ldapsearch.c:1280 filter = 0x7fffe4f6b881 "(sAMAccountName=uzivatel)" rc = 0 nresponses = 7 nentries = 1 nreferences = 6 nextended = 0 npartial = 0 res = (LDAPMessage *) 0x0 msg = (LDAPMessage *) 0x0 msgid = 2 retoid = 0x0 retdata = (struct berval *) 0x0 nresponses_psearch = -1 cancel_msgid = -1 #14 0x00000000004084cc in main (argc=14, argv=0x7fffe4f6a4f8) at ldapsearch.c:1112 filtpattern = 0x7fffe4f6b881 "(sAMAccountName=uzivatel)" attrs = (char **) 0x0 line = '\0' <repeats 1344 times>, "\006\000\000\000\000\000\000\000\200\220öäÿ\177\000\000\220\220öäÿ\177\000\000\231C!J;\000\000\000\237C!J;\000\000\000\023pdI;", '\0' <repeats 47 times>, "º\005\000\000\004\000\000\000\000\000\000\000à\220öäÿ\177\000\000ð\220öäÿ\177\000\000ÔB!J;\000\000\000ØB!J;\000\000\000\023pdI;", '\0' <repeats 47 times>, "º\005\000\000X\220öäÿ\177\000\000x\220öäÿ\177\000\000 \220öäÿ\177\000\000p\220öäÿ\177\000\000Ð\213öäÿ\177", '\0' <repeats 18 times>, "\205ç Iøÿÿÿ\000\000\000\000\000\000\000\000èÔAI;\000\000\000"... fp = (FILE *) 0x0 rc = 4213523 rc1 = 0 i = 0 first = 32767 ld = (LDAP *) 0x1b80fa0 seber = (BerElement *) 0x0 vrber = (BerElement *) 0x0 syncber = (BerElement *) 0x0 syncbvalp = (struct berval *) 0x0 err = 4216832 (gdb)

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by h.b.furuseth＠usit.uio.no 09 Dec '08

09 Dec '08

hyc(a)symas.com writes: >ando(a)sys-net.it wrote: >>h.b.furuseth(a)usit.uio.no wrote: >>> If it knows enough to complain, why not restart the indexing task? >> >> There should be an option in doing that. I don't quite see why. If you add an index via cn=config, that starts an indexing task while slapd is running. A following shutdown-restart is not necessarily related to a desire to not run that task. >> In fact, I suspect running slapindex -q can be much more efficient >> than letting slapd index while serving without index. (...) If you shut down slapd because you want to use slapindex, then you know what you want - so just go ahead and use slapindex. No extra flag needed. I suppose there could be a flag to _not_ start the indexing task when you add an index via cn=config, so you always must slapindex. > I suppose we should save the last entryID that was indexed at shutdown time, > so that the indexer task can resume at the next startup. We'd also need some > coordination with slapindex, so that if you ran slapindex after shutdown, it > would erase the saved status. Rather than add any fields to the DB index > files, it would probably be OK to write the status in the cn=config tree. Or a status file in the database directory. A cn=config attribute would make it messy to swap database directories around, since one must also modify cn=config when doing so. -- Hallvard

1 0

Re: (ITS#5852) ACL behaviour does not match Admin Guide
by andrew.findlay＠skills-1st.co.uk 09 Dec '08

09 Dec '08

On Mon, Dec 08, 2008 at 09:01:44PM +0000, quanah(a)zimbra.com wrote: > > Full_Name: Andrew Findlay > > Version: HEAD 2008-12-05 > > OS: SuSE 10.2 > > URL: > > Submission from: (NULL) (88.97.25.132) > > > > > > Section 7.2.5 Access Control Examples says: > > ... > > Also note that if no access to directive matches or no by <who> clause, > > access is denied. That is, every access to directive ends with an > > implicit by * none clause and every access list ends with an implicit > > access to * by * none directive. > > > > The statement about access *lists* ending with a deny directive is wrong > > (or at least misleading). > > I think it is quite clear: > > The structure of the access control directives is > ... > Lists of access directives are evaluated in the order they appear in > slapd.conf. > > Each <who> clause list is implicitly terminated by a > > by * none stop > > > So, there are acl directives where each directive is an element of a list. > Every element of a list of acl directives is terminated by * none stop. That is not the aspect that worries me here. The statement in 7.2.5 agrees with what you say about individual directives. I am concerned about the behaviour of complete access *lists*. For example, if my global acccess list says: access to * by * read and the access list for a BDB database holding the suffix 'dc=example,dc=org' says: access to dn.exact="cn=nonesuch,dc=example,dc=org" by users read (i.e. it is very restrictive and does not give ANON anything) In this case the statement in 7.2.5 implies that ANON should not be able to read dc=example,dc=org but tests show that it can. Changing the global access list to: access to * by users read prevents ANON from reading dc=example,dc=org and thus proves that the per-database access list does not end with 'by * none stop' (but the complete list including the global section does). Sections 7.2.4 and 7.3.4 describe this behaviour rather better, but do not mention the default-deny that gets appended to a non-empty access list. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 09 Dec '08

09 Dec '08

Am Montag 08 Dezember 2008 16:39:33 schrieb Hallvard B Furuseth: > Yes, this sounds familiar. I guess I mentioned it but didn't have time > to check it. The offending if() comes from tpool.c rev 1.81, which was > apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. > (Except I'm not so sure it was the _complete_ fix - might need to lock > ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or > something like that...) > > Anyway, the patch looks correct to me, undoing rev 1.81. Thanks very much for the clarification. > The current code is clear enough in retrospect - a thread pool pause in > halts pool_destroy() since pool_resume() doesn't broadcast - and thus a > cn=config update (or access?) aborts slapd shutdown:-( It doesn't really abore shutdown in sense of slapd accepting requests again. slapd is completely lockup in such a condition. It doesn't accept requests anymore, neither does it shutdown completely. Anyway, I've just applied the fix to HEAD. -- regards, Ralf

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 08 Dec '08

08 Dec '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> - the index should be invalidated >>> - slapd, at the next manual startup, should complain about the need to >>> run slapindex first. >> If it knows enough to complain, why not restart the indexing task? > > There should be an option in doing that. In fact, I suspect running > slapindex -q can be much more efficient than letting slapd index while > serving without index. Of course, slapd cannot serve while > slapindex'ing, so I think human intervention is needed to determine > what's most appropriate on a case by case basis. I suppose we should save the last entryID that was indexed at shutdown time, so that the indexer task can resume at the next startup. We'd also need some coordination with slapindex, so that if you ran slapindex after shutdown, it would erase the saved status. Rather than add any fields to the DB index files, it would probably be OK to write the status in the cn=config tree. -- -- 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#5852) ACL behaviour does not match Admin Guide
by quanah＠zimbra.com 08 Dec '08

08 Dec '08

--On Monday, December 08, 2008 7:33 PM +0000 andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: HEAD 2008-12-05 > OS: SuSE 10.2 > URL: > Submission from: (NULL) (88.97.25.132) > > > Section 7.2.5 Access Control Examples says: > ... > Also note that if no access to directive matches or no by <who> clause, > access is denied. That is, every access to directive ends with an > implicit by * none clause and every access list ends with an implicit > access to * by * none directive. > > The statement about access *lists* ending with a deny directive is wrong > (or at least misleading). I think it is quite clear: The structure of the access control directives is ... Lists of access directives are evaluated in the order they appear in slapd.conf. Each <who> clause list is implicitly terminated by a by * none stop So, there are acl directives where each directive is an element of a list. Every element of a list of acl directives is terminated by * none stop. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5852) ACL behaviour does not match Admin Guide
by andrew.findlay＠skills-1st.co.uk 08 Dec '08

08 Dec '08

Full_Name: Andrew Findlay Version: HEAD 2008-12-05 OS: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) Section 7.2.5 Access Control Examples says: ... Also note that if no access to directive matches or no by <who> clause, access is denied. That is, every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive. The statement about access *lists* ending with a deny directive is wrong (or at least misleading). The truth is that the global access list is effectively appended to each per-database list. If the resulting list is non-empty then a default deny is appended. If there are *no* access directives applicable to a backend at all then a default read is used. slapd.access(5) is clearer about this but still not clear enough about the default-deny case. Sections 7.2.4 and 7.3.4 are fairly clear about the drop-though from backend ACLs to global ACLs, but say nothing about the default-deny case. Clearly the docs do not match the code in this area. In many ways I prefer the idea that an access list should end with a default deny (and *not* get the global list appended), but there may well be people depending on the current behaviour.

1 0

(ITS#5851) ACL behaviour does not match slapd.access(5)
by andrew.findlay＠skills-1st.co.uk 08 Dec '08

08 Dec '08

Full_Name: Andrew Findlay Version: HEAD 2008-12-05 OS: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) Some ACL behaviours do not match slapd.access(5). slapd.access(5) says: > For entries not held in any backend (such as a root DSE), > the directives of the first backend (and any global directives) are used. I created a slapd.conf where the global ACL was: access to * by * none and the single BDB backend had acls: access to dn.exact="" by * read access to dn.exact="cn=nonesuch" by * read The anon user could not read the root DSE: ldapsearch -LLL -H ldap://localhost:1389/ -b '' -s base -x '(objectclass=*)' + I next moved the root access clause to the global section: access to dn.exact="" by * read access to * by * none The BDB backend now had this ACL: access to dn.exact="cn=nonesuch" by * read Anon was now able to read the root DSE. Thus it appears that the root DSE is controlled by the global ACL but not by the first backend ACL. My feeling is that the behaviour is right and the manpage needs updating. The Admin Guide has similar statements in 7.2.4 and 7.3.4. The complete slapd.conf file follows for reference: ------------------------------------------------------------------------------- # Logging - this goes to syslog as 'local4' # # 512+256 to enable stats logging # loglevel 768 # Schema definitions # include ../../etc/schema/core.schema include ../../etc/schema/cosine.schema include ../../etc/schema/inetorgperson.schema # These should have absolute pathnames on production systems pidfile ./slapd.pid argsfile ./slapd.args ######################################################################## # Default ACL ######################################################################## access to * by * none ######################################################################## ####################################################################### # The main database ####################################################################### ######################################################################## database bdb suffix "dc=example,dc=org" rootdn "cn=root,dc=example,dc=org" password-hash {SSHA} # rootpw password # The database directory MUST exist prior to running slapd AND # should only be accessable by the slapd/tools. Mode 700 recommended. # This should be an absolute pathname on production servers. # directory ./openldap-db # Entry cache size # cachesize 4000 # How often we force a checkpoint on the underlying database # kilobytes and seconds # checkpoint 128 300 ######################################################################## # Indices to maintain ######################################################################## index objectClass eq ######################################################################## # ACLs for this database ######################################################################## access to dn.exact="" by * read access to dn.exact="cn=nonesuch" by * read

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by ando＠sys-net.it 08 Dec '08

08 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> - the index should be invalidated >> - slapd, at the next manual startup, should complain about the need to >> run slapindex first. > > If it knows enough to complain, why not restart the indexing task? There should be an option in doing that. In fact, I suspect running slapindex -q can be much more efficient than letting slapd index while serving without index. Of course, slapd cannot serve while slapindex'ing, so I think human intervention is needed to determine what's most appropriate on a case by case basis. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

ando(a)sys-net.it writes: > - the index should be invalidated > - slapd, at the next manual startup, should complain about the need to > run slapindex first. If it knows enough to complain, why not restart the indexing task? -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by h.b.furuseth＠usit.uio.no 08 Dec '08

08 Dec '08

Yes, this sounds familiar. I guess I mentioned it but didn't have time to check it. The offending if() comes from tpool.c rev 1.81, which was apparently a wrong fix to ITS#5194. rev 1.82 was the right fix. (Except I'm not so sure it was the _complete_ fix - might need to lock ldap_pvt_thread_pool_mutex while changing or even accessing *tpool, or something like that...) Anyway, the patch looks correct to me, undoing rev 1.81. The current code is clear enough in retrospect - a thread pool pause in halts pool_destroy() since pool_resume() doesn't broadcast - and thus a cn=config update (or access?) aborts slapd shutdown:-( -- Hallvard

1 0

Re: slapd hanging upon shutdown (ITS#5841)
by rhafer＠suse.de 08 Dec '08

08 Dec '08

Am Freitag 05 Dezember 2008 09:07:53 schrieb Howard Chu: > I seem to recall there was a race such that the condvar had already been > destroyed before it got here. Don't remember the details at the moment, and > not in a position to look it up either, but perhaps trawling thru -devel > will reveal it. Sounds like something Hallvard brought up in the past. I failed to see how such a race could happen with the current code in HEAD. The condvar is only destroyed after ltp_open_count decreased to 0. There might have been such problems when _thread_pool_destroy just used a simple if statement (instead of a while loop) for checking ltp_open_count. But that has been changed long ago, as part of ITS#4943. Maybe Hallvard can shed some light on this. -- regards, Ralf

1 0

(ITS#5850) adding a new server to ammr pool switches mirror-mode off
by ando＠sys-net.it 06 Dec '08

06 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When adding a new value to olcSyncrepl to a member of a mmr pool, in order to configure a new pool member, olcMirrorMode is automatically reset since the URI of the new olcSyncrepl differs from the olcServerID. A workaround consists in explicitly reseting olcMirrorMode to TRUE within the same modify operation. p.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > dhawes(a)vt.edu wrote: >> Full_Name: David Hawes >> Version: 2.4.13 >> OS: Debian GNU/Linux 4.0 >> URL: >> Submission from: (NULL) (98.117.88.57) >> >> >> As outlined at: >> >> http://www.openldap.org/lists/openldap-software/200811/msg00136.html >> >> OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd >> under valgrind yields the following: >> >> ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are >> definitely lost in loss record 19 of 23 >> ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) >> ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) >> ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) >> ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) >> ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) >> ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) >> ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) >> ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) >> ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) >> ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) >> ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) >> ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) >> ==13311== by 0x8076926: connection_read_thread (connection.c:1286) >> ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==13311== by 0x415823F: start_thread (in >> /lib/tls/i686/cmov/libpthread-2.3.6.so) >> ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) >> >> Philip Guenther notes: >> >> In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: >> the call to SSL_get_peer_certificate() in tls_get_cert() increments the >> reference count on the cert and it never gets decremented by a call to >> X509_free(). Simply adding the call there might not be safe, depending on >> whether the berval that tls_get_cert_dn() sets up relies on the underlying >> X509 to stay valid for longer than this chain of calls, as the X509 may be >> invalidated by a rehandshake. > > Calling X509_free(x) before the return statement in tls_get_cert_dn() > does fix the memory leak, though I do not know if this is proper, as > Philip noted. My apologies for not checking the ITS before sending that message. The fix in HEAD works.

1 0

Re: (ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 05 Dec '08

05 Dec '08

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.13 > OS: Debian GNU/Linux 4.0 > URL: > Submission from: (NULL) (98.117.88.57) > > > As outlined at: > > http://www.openldap.org/lists/openldap-software/200811/msg00136.html > > OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd > under valgrind yields the following: > > ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are > definitely lost in loss record 19 of 23 > ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) > ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) > ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) > ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) > ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) > ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) > ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) > ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) > ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) > ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) > ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) > ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) > ==13311== by 0x8076926: connection_read_thread (connection.c:1286) > ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) > ==13311== by 0x415823F: start_thread (in > /lib/tls/i686/cmov/libpthread-2.3.6.so) > ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) > > Philip Guenther notes: > > In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: > the call to SSL_get_peer_certificate() in tls_get_cert() increments the > reference count on the cert and it never gets decremented by a call to > X509_free(). Simply adding the call there might not be safe, depending on > whether the berval that tls_get_cert_dn() sets up relies on the underlying > X509 to stay valid for longer than this chain of calls, as the X509 may be > invalidated by a rehandshake. Calling X509_free(x) before the return statement in tls_get_cert_dn() does fix the memory leak, though I do not know if this is proper, as Philip noted.

1 0

Re: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 04 Dec '08

04 Dec '08

I could have sworn I had uploaded the revised version of the patch back in August after some cleaning by Kurt, but have no way of confirming it. So I've uploaded it again as guenther-20081204.patch.

1 0

(ITS#5849) memory leak when using client certificates
by dhawes＠vt.edu 04 Dec '08

04 Dec '08

Full_Name: David Hawes Version: 2.4.13 OS: Debian GNU/Linux 4.0 URL: Submission from: (NULL) (98.117.88.57) As outlined at: http://www.openldap.org/lists/openldap-software/200811/msg00136.html OpenLDAP 2.4 leaks memory when TLS client certificates are used. Running slapd under valgrind yields the following: ==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23 ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) ==13311== by 0x8076926: connection_read_thread (connection.c:1286) ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) ==13311== by 0x415823F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) Philip Guenther notes: In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.

1 0

ITS#5847 back-ndb indexing
by hyc＠symas.com 04 Dec '08

04 Dec '08

This is a known limitation in the current version of back-ndb. (See this message for further details http://www.openldap.org/lists/openldap-devel/200810/msg00094.html ) Note that back-ndb is marked "Experimental". You should not use it unless you're prepared to write fixes for it.

1 0

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 03 Dec '08

03 Dec '08

--0-334172624-1228364660=:46006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Andrew for the reply.=0A=0A=0AQMail schema didn't seem to work for a= distribution list. I am looking for other options as well.=0A=0AI agree th= at this is a mail system issue. I am using Exim/Dovecot for mails. I though= t it was the LDAP which gets the group mail id from the address book for th= e Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick.=0A= =0AWith Regards=0ABejoy=0A=0A=0A=0A________________________________=0AFrom:= Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>=0ATo: bejnet(a)yahoo.com=0A= Cc: openldap-its(a)openldap.org=0ASent: Wednesday, 3 December, 2008 2:02:05 P= M=0ASubject: Re: (ITS#5845) Distribution List support for OpenLDAP schema= =0A=0AOn Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote:=0A= =0A> I want to create distribution list in OpenLDAP. Meaning - If I have a = group=0A> called admins(a)ldap.com and there are two members - bejoy(a)ldap.com= and=0A> bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com =3D both thes= e members must=0A> get the email. Exchange has this feature. This mail id s= hould have a display=0A> name feature as well - that would show up on searc= h of address books.=0A> =0A> At present the work around is using qmail's sc= hema for this distribution list. I=0A> believe inetOrgPerson schema could h= ave a group version too - which would need a=0A> compulsory attribute calle= d members which must have atleast one member mentioned=0A> under it.=0A=0AI= think you have just described groupOfNames. I do not like groupOfNames=0A*= because* it makes the member attribute mandatory, which makes management=0A= complicated.=0A=0AAnyway, I cannot see this as a defect in OpenLDAP. LDAP s= chema is=0Aextensible: if you want something that is not in the standard se= t=0Ayou can add it locally. You say that you have used qmail's schema:=0Ais= there anything wrong with that?=0A=0AMost LDAP-capable mail systems can be= persuaded to use groups as=0Amailing lists, but that is a mail system issu= e not an OpenLDAP one.=0AIt could be argued that simple groups are not rich= enough to use=0Afor list expansion (no way to keep track of per-member lis= t=0Apreferences etc) but if we are going to talk about defining an=0Aimprov= ed group this is the wrong place to do it: maybe IETF's=0Aldapext list woul= d be better.=0A=0AAndrew=0A-- =0A------------------------------------------= -----------------------------=0A| From Andrew Findlay, Skil= ls 1st Ltd |=0A| Consultant in large-scale systems, network= s, and directory services |=0A| http://www.skills-1st.co.uk/ = +44 1628 782565 |=0A-----------------------------------------------= ------------------------=0A=0A=0A=0A From Chandigarh to Chennai - find= friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups= / --0-334172624-1228364660=:46006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon= t-size:12pt"><div>Thanks Andrew for the reply. </div><div style=3D"font-= family: times new roman,new york,times,serif; font-size: 12pt;"> QMail s= chema didn't seem to work for a distribution list. I am looking for other o= ptions as well. I agree that this is a mail system issue. I am using= Exim/Dovecot for mails. I thought it was the LDAP which gets the group mai= l id from the address book for the Mail Client. Eg. In Outlook+AD+Exchange we have the CTRL+K option which g= ets the group id that points to more than one mailing address. I think ther= e is a basic understanding between Exchange and AD that does the trick. = With Regards Bejoy <div style=3D"font-family: arial,helvetica= ,sans-serif; font-size: 13px;"><hr size=3D"1">From: Andrew F= indlay <andrew.findlay(a)skills-1st.co.uk> To: bejnet(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, 3 December, 2008 2:02:05 PM<b= r>Subject: Re: (ITS#5845) = Distribution List support for OpenLDAP schema On Wed, Dec 03,= 2008 at 05:02:52AM +0000, <a ymailto=3D"mailto:bejnet@yahoo.com" href=3D"m= ailto:bejnet@yahoo.com">bejnet(a)yahoo.com</a> wrote: > I want to c= reate distribution list in OpenLDAP. Meaning - If I have a group > ca= lled <a ymailto=3D"mailto:admins@ldap.com" href=3D"mailto:admins@ldap.com">= admins(a)ldap.com</a> and there are two members - <a ymailto=3D"mailto:bejoy@= ldap.com" href=3D"mailto:bejoy@ldap.com">bejoy(a)ldap.com</a> and > <a ymailto=3D"mailto:bejnet@ldap.com" href=3D"mailto:bejnet@ldap.com">bejnet@= ldap.com</a>; and mail is sent to <a ymailto=3D"mailto:admins@ldap.com" hre= f=3D"mailto:admins@ldap.com">admins(a)ldap.com</a> =3D both these members mus= t > get the email. Exchange has this feature. This mail id should hav= e a display > name feature as well - that would show up on search of = address books. > > At present the work around is using qmail's= schema for this distribution list. I > believe inetOrgPerson schema = could have a group version too - which would need a > compulsory attr= ibute called members which must have atleast one member mentioned > u= nder it. I think you have just described groupOfNames. I do not like= groupOfNames *because* it makes the member attribute mandatory, which m= akes management complicated. Anyway, I cannot see this as a defec= t in OpenLDAP. LDAP schema is extensible: if you want something that is = not in the standard set you can add it locally. You say that you have used = qmail's schema: is there anything wrong with that? Most LDAP-capa= ble mail systems can be persuaded to use groups as mailing lists, but th= at is a mail system issue not an OpenLDAP one. It could be argued that s= imple groups are not rich enough to use for list expansion (no way to ke= ep track of per-member list preferences etc) but if we are going to talk= about defining an improved group this is the wrong place to do it: mayb= e IETF's ldapext list would be better. Andrew -- ---------= -------------------------------------------------------------- |  &= nbsp;             From Andrew Findlay, Skill= s 1st Ltd                | | Co= nsultant in large-scale systems, networks, and directory services | |&nb= sp;   <a href=3D"http://www.skills-1st.co.uk/" target=3D"_blank">http://www.skills-1st.co.uk/</a>      &nb= sp;         +44 1628 782565    | --------= --------------------------------------------------------------- </div></= div></div> =0A <hr size=3D1></hr> Add more friends to your = messenger and enjoy! <a href=3D"http://in.rd.yahoo.com/tagline_messenger_6/= *http://messenger.yahoo.com/invite/"> Invite them now.</a></body></html> --0-334172624-1228364660=:46006--

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 22:14:20 schrieb Quanah Gibson-Mount: > <http://www.oracle.com/technology/software/products/berkeley-db/db/index.ht >ml> > > Berkeley DB Release History > > > Latest Production Release > 4.7.25 > Requires log file format upgrade. change log - patches (1) > > Click on the "1", it's a link to the patch: > > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> > After applying the patches, everything seems to be working working now. Thank you very much for your assistance! tk

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

--On Wednesday, December 03, 2008 9:54 PM +0100 Thomas Koeller <thomas(a)koeller.dyndns.org> wrote: > Am Mittwoch, 3. Dezember 2008 21:22:11 schrieb Quanah Gibson-Mount: >> Did you apply the patch from Oracle? And did you apply the patch in the >> build/ directory shipped with OpenLDAP? Both are necessary. It'd be >> nice if Oracle would add the second patch to their website, since it's >> needed, and it came from them. > > No, I missed that. I found the patch shipped with OpenLDAP, but what do > you mean by '_the_ patch from Oracle'? I revisited their website but could > not spot any patches there. <http://www.oracle.com/technology/software/products/berkeley-db/db/index.html> Berkeley DB Release History Latest Production Release 4.7.25 Requires log file format upgrade. change log - patches (1) Click on the "1", it's a link to the patch: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 21:22:11 schrieb Quanah Gibson-Mount: > Did you apply the patch from Oracle? And did you apply the patch in the > build/ directory shipped with OpenLDAP? Both are necessary. It'd be nice > if Oracle would add the second patch to their website, since it's needed, > and it came from them. No, I missed that. I found the patch shipped with OpenLDAP, but what do you mean by '_the_ patch from Oracle'? I revisited their website but could not spot any patches there. thanks, tk

1 0

(ITS#5848) INDEXES IN BACK-NDB
by evaristojosec＠yahoo.es 03 Dec '08

03 Dec '08

Full_Name: Evaristo Camarero Version: 2.4.13 OS: SuSe 10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.32.53.80) The issue is related with indexes support in the back-ndb that uses MySQL Cluster NDB backend. The problem happens when you define more than one index in the slapd.conf, and you try a search operation using a filter that does not contain the first define index. This my config in slapd.conf for the back-ndb ######################################################## # NDB ######################################################### database ndb suffix dc=example,dc=com rootdn cn=Manager,dc=example,dc=com rootpw secret dbname OpenLDAP dbuser root dbpass whatever # MySQL Server dbhost localhost # NDB management host dbconnect localhost # Number of API connections in the NDB cluster dbconnections 5 dbsocket /tmp/mysql.sock index cn index sn I have loaded the following LDIF file in the server: # root dn: dc=example,dc=com objectClass: organization objectClass: dcObject o: Example, Inc. dc: example # people dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People # company-wide address book dn: ou=Address Book,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in company-wide address book dn: cn=Rosco P. Coltrane,ou=Address Book,dc=example,dc=com objectClass: inetOrgPerson cn: Rosco P. Coltrane sn: Coltrane mail: rpc(a)example.com # address book administrator dn: cn=Admin,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Admin sn: Admin userPassword: admin # person dn: cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Flash Gordon sn: Gordon mail: fg(a)example.com userPassword: secret # person's personal address book dn: ou=Address Book,cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # another person dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Clark Kent sn: Kent mail: ck(a)example.com userPassword: secret # another person's personal address book dn: ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in another person's personal address book dn: cn=Mickey Mouse,ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Mickey Mouse sn: Mouse mail: mickey.mouse(a)example.com # one more person, yet without personal address book dn: cn=Donald Duck,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Donald Duck sn: Duck mail: dd(a)example.com userPassword: secret Using the first defined index (cn), works fine: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'cn=Clark Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: cn=Clark Kent # requesting: ALL # # Clark Kent, People, example.com dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson userPassword:: c2VjcmV0 sn: Kent cn: Clark Kent mail: ck(a)example.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But using the second defined index, does not work: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'sn=Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: sn=Kent # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Tell me if you need more details. Thanks in advance

1 0

(ITS#5847) INDEXES IN BACK-NDB
by evaristojosec＠yahoo.es 03 Dec '08

03 Dec '08

Full_Name: Evaristo Camarero Version: 2.4.13 OS: SuSe 10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.32.53.80) The issue is related with indexes support in the back-ndb that uses MySQL Cluster NDB backend. The problem happens when you define more than one index in the slapd.conf, and you try a search operation using a filter that does not contain the first define index. This my config in slapd.conf for the back-ndb ######################################################## # NDB ######################################################### database ndb suffix dc=example,dc=com rootdn cn=Manager,dc=example,dc=com rootpw secret dbname OpenLDAP dbuser root dbpass whatever # MySQL Server dbhost localhost # NDB management host dbconnect localhost # Number of API connections in the NDB cluster dbconnections 5 dbsocket /tmp/mysql.sock index cn index sn I have loaded the following LDIF file in the server: # root dn: dc=example,dc=com objectClass: organization objectClass: dcObject o: Example, Inc. dc: example # people dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People # company-wide address book dn: ou=Address Book,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in company-wide address book dn: cn=Rosco P. Coltrane,ou=Address Book,dc=example,dc=com objectClass: inetOrgPerson cn: Rosco P. Coltrane sn: Coltrane mail: rpc(a)example.com # address book administrator dn: cn=Admin,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Admin sn: Admin userPassword: admin # person dn: cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Flash Gordon sn: Gordon mail: fg(a)example.com userPassword: secret # person's personal address book dn: ou=Address Book,cn=Flash Gordon,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # another person dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Clark Kent sn: Kent mail: ck(a)example.com userPassword: secret # another person's personal address book dn: ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: organizationalUnit ou: Address Book # entry in another person's personal address book dn: cn=Mickey Mouse,ou=Address Book,cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Mickey Mouse sn: Mouse mail: mickey.mouse(a)example.com # one more person, yet without personal address book dn: cn=Donald Duck,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Donald Duck sn: Duck mail: dd(a)example.com userPassword: secret Using the first defined index (cn), works fine: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'cn=Clark Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: cn=Clark Kent # requesting: ALL # # Clark Kent, People, example.com dn: cn=Clark Kent,ou=People,dc=example,dc=com objectClass: inetOrgPerson userPassword:: c2VjcmV0 sn: Kent cn: Clark Kent mail: ck(a)example.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But using the second defined index, does not work: ldapsearch -x -h localhost -p 20389 -b "dc=example,dc=com" 'sn=Kent' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: sn=Kent # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Tell me if you need more details. Thanks in advance

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

--On Wednesday, December 03, 2008 9:15 PM +0100 Thomas Koeller <thomas(a)koeller.dyndns.org> wrote: > Am Mittwoch, 3. Dezember 2008 02:39:58 schrieb Quanah Gibson-Mount: >> What version of BDB? > > db-4.7.25 Did you apply the patch from Oracle? And did you apply the patch in the build/ directory shipped with OpenLDAP? Both are necessary. It'd be nice if Oracle would add the second patch to their website, since it's needed, and it came from them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 03 Dec '08

03 Dec '08

Am Mittwoch, 3. Dezember 2008 02:39:58 schrieb Quanah Gibson-Mount: > What version of BDB? db-4.7.25 I ran 'make test' under strace, here's what I got. Seems to be some kind of deadlock. [pid 14035] pwrite(6, "\261\244\0\0O\20\0\0003\237E\251\221\0\0\0\10\0\0\200\1"..., 8453, 42224) = 8453 [pid 14035] fdatasync(6) = 0 [pid 14035] rename("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/__db.80000007.336a56f4", "/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb") = 0 [pid 14035] stat("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb", {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0 [pid 14035] open("/home/thomas/build/openldap-2.4.13/tests/testrun/db.1.a/objectClass.bdb", O_RDWR|O_CREAT, 0) = 10 [pid 14035] fcntl(10, F_GETFD) = 0 [pid 14035] fcntl(10, F_SETFD, FD_CLOEXEC) = 0 [pid 14035] fstat(10, {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0 [pid 14035] pread(10, "\0\0\0\0\1\0\0\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 4096, 0) = 4096 [pid 14035] pwrite(6, "\216\305\0\0(\0\0\0\311\30\225\0\f\0\0\0\7\0\0\200\0\0"..., 176, 50677) = 176 [pid 14035] fdatasync(6) = 0 [pid 14035] pread(10, "\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\1\5\0"..., 4096, 4096) = 4096 [pid 14035] pwrite(6, "y\306\0\0D\0\0\0\0028\257o)\0\0\0\6\0\0\200\1\0\0\0i\244"..., 1682, 50853) = 1682 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] pwrite(6, "\v\315\0\0]\0\0\0F\205\277r)\0\0\0\t\0\0\200\0\0\0\0\0"..., 1633, 52535) = 1633 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] pwrite(6, "l\323\0\0]\0\0\0\222\264S5)\0\0\0\n\0\0\200\0\0\0\0\0\0"..., 1404, 54168) = 1404 [pid 14035] fdatasync(6) = 0 [pid 14035] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 [pid 14035] sched_yield() = 0 [pid 14035] futex(0x2aaf71fe7924, FUTEX_WAIT, 1, NULL *** hangs *** tk

1 0

Re: (ITS#5839) overlay glue
by rein＠OpenLDAP.org 03 Dec '08

03 Dec '08

LEHOUELLEUR, Marin wrote: > Can you confirm your sentence is it "for the same consumer" or "from the same provider" that syncrepl may not behave properly ? Both, i.e not "or" but "and".. Each consumer can only have one syncrepl instance below a common glue database that replicates from the same provider. Multiple providers is OK as long as they all have different serverID (although this might require 2.4). Each provider can replicate to an unlimited number of clients. If you configure syncrepl on both the glue database and a subordinate then syncrepl on the glue db will, when it start up, try to wipe out everything in the subordinate db (unless the content in the subordinate db is also replicated to syncrepl in the glue db, in which case the subordinate syncrepl is useless). If you have two subordinate databases on a consumer that replicates from the same provider, then syncrepl on one of them can (when slapd start) pick up a newer sync cookie saved by the other without actually being in sync with the provider. I.e it would miss some modifications. > I'm about to deliver so if I have no misfunction with 2.3 when I test it, i may go with it. I would definitely reconsider, unless you have an extremely good test scenario you are unlike to have tested all the pitfalls.. There can be som nasty race situations involved here. > But I'm worried about the syncrepl bugs your talking about. Does two replica may support to feed about thirty (30) consumers as the DB is very little ?? The number of servers is no problem, it is the number of syncrepl instances on the same consumer that can cause problems as outlined above. > Master replicates to two replica the full database. 30 Consumers plugged to the replicas with each a different login (SASL authentication). No problem as long as you don't have more than one syncrepl instance on each server. This ITS should probably be closed and further questions directed to the openldap-software list. Rein

1 0

Re: (ITS#5839) overlay glue
by quanah＠zimbra.com 03 Dec '08

03 Dec '08

Your message is unreadable. --Quanah --On Wednesday, December 03, 2008 3:15 PM +0000 Marin.LEHOUELLEUR(a)astrium.eads.net wrote: > This is a multi-part message in MIME format. > > > ------_=_NextPart_001_01C95559.E58ECC4C > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I=20have=20no=20other=20impact=20than=20not=20having=20the=20glued=20bran= > ch=20visible=20in > LDAPBrowser=20: > Search=20queries=20on=20the=20glued=20branch=20works=20perfectly. > I'm=20wondering=20about=20the=20proper=20use=20of=20overlay=20glue=20as= > =20error=20message > appears=20in=20slapd=20log=20(directive=20glue-sub=20ignored). > > Solution=20offered=20by=20Rein=20is=20good=20looking=20but=20I'll=20have= > =20to=20deal=20with=2030 > ACLs=20on=20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20con= > sumers=20!! > > I'll=20do=20that=20if=20any=20bug=20shows=20its=20face.=20Still=20better= > =20than=20migrating=20the > servers=20(gloups,=20oh=20no=20I=20don't=20want=20that). > > Thank=20you=20for=20helping. > > M > > Marin=20Le=20Houelleur > Projet=20Pharos=20-=20Capgemini > marin.lehouelleur(a)astrium.eads.net > 05=2062=2019=2068=2059 > > > Ce=20courriel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut= > =20contenir=20des=20informations=20confidentielles=20et/ou=20protegees=20= > ou=20dont=20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu= > =20ce=20courriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,= > =20ni=20l'utiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.= > =20Merci=20d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer= > =20ce=20courriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20re= > sponsabilite=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration= > =20ou=20de=20falsification=20de=20ce=20courriel=20lors=20de=20sa=20transm= > ission=20par=20voie=20electronique. > This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= > tial=20and/or=20privileged=20information=20or=20information=20otherwise= > =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= > =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= > =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= > =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= > person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= > =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= > f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= > =20falsified.=20 > --------------------------------------------------------------------- > Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= > =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France > > ------_=_NextPart_001_01C95559.E58ECC4C > Content-Type: text/html; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE=20HTML=20PUBLIC=20"-//W3C//DTD=20HTML=203.2//EN"> > <HTML> > <HEAD> > <META=20HTTP-EQUIV=3D"Content-Type"=20CONTENT=3D"text/html;=20charset=3Du= > s-ascii"> > <META=20NAME=3D"Generator"=20CONTENT=3D"MS=20Exchange=20Server=20version= > =206.5.7653.2"> > <TITLE>Re:=20(ITS#5839)=20overlay=20glue</TITLE> > </HEAD> > <BODY> >  > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I=20have=20no=20other=20impact=20tha= > n=20not=20having=20the=20glued=20branch=20visible=20in=20LDAPBrowser=20:<= > /FONT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Search=20queries=20on=20the=20glued= > =20branch=20works=20perfectly. > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I'm=20wondering=20about=20the=20pro= > per=20use=20of=20overlay=20glue=20as=20error=20message=20appears=20in=20s= > lapd=20log=20(directive=20glue-sub=20ignored). > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Solution=20offered=20by=20Rein=20is= > =20good=20looking=20but=20I'll=20have=20to=20deal=20with=2030=20ACLs=20on= > =20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20consumers=20= > !! > > <FONT=20SIZE=3D2=20FACE=3D"Arial">I'll=20do=20that=20if=20any=20bug=20= > shows=20its=20face.=20Still=20better=20than=20migrating=20the=20servers= > =20(gloups,=20oh=20no=20I=20don't=20want=20that). > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Thank=20you=20for=20helping. > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">M > > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Marin=20Le=20Houelleur > > <FONT=20SIZE=3D2=20FACE=3D"Arial">Projet=20Pharos=20-=20Capgemini</FO= > NT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">marin.lehouelleur(a)astrium.eads.net<= > /FONT> > > <FONT=20SIZE=3D2=20FACE=3D"Arial">05=2062=2019=2068=2059 > > > </BODY> > </HTML> > <table><tr><td=20bgcolor=3D#ffffff><font=20color=3D#000000><pre>Ce=20cour= > riel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut=20conteni= > r=20des=20informations=20confidentielles=20et/ou=20protegees=20ou=20dont= > =20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu=20ce=20co= > urriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,=20ni=20l'u= > tiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.=20Merci=20= > d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer=20ce=20cou= > rriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20responsabilit= > e=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration=20ou=20de=20= > falsification=20de=20ce=20courriel=20lors=20de=20sa=20transmission=20par= > =20voie=20electronique. > This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= > tial=20and/or=20privileged=20information=20or=20information=20otherwise= > =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= > =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= > =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= > =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= > person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= > =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= > f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= > =20falsified.=20 > --------------------------------------------------------------------- > Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= > =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France</pre></td></t= > r></table> > > ------_=_NextPart_001_01C95559.E58ECC4C-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5846) Support Solaris 10U6 GSS library
by andjo＠ida.liu.se 03 Dec '08

03 Dec '08

Full_Name: Andreas Johansson Version: 2.4.13 OS: Solaris 10 URL: http://www.ida.liu.se/~andjo/tmp/openldap-solaris-gssapi.patch Submission from: (NULL) (2001:6b0:17:f020:203:baff:fe7b:3cfa) The OpenLDAP configure script does not detect the GSSAPI library in Solaris 10 (at least the one in update 6). The library is named gss instead of gssapi or gssapi_krb5. Referenced is a small patch for configure.in to search for gss_wrap in libgss as well.

1 0

Re: (ITS#5839) overlay glue
by Marin.LEHOUELLEUR＠astrium.eads.net 03 Dec '08

03 Dec '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I=20have=20no=20other=20impact=20than=20not=20having=20the=20glued=20bran= ch=20visible=20in LDAPBrowser=20: Search=20queries=20on=20the=20glued=20branch=20works=20perfectly. I'm=20wondering=20about=20the=20proper=20use=20of=20overlay=20glue=20as= =20error=20message appears=20in=20slapd=20log=20(directive=20glue-sub=20ignored). Solution=20offered=20by=20Rein=20is=20good=20looking=20but=20I'll=20have= =20to=20deal=20with=2030 ACLs=20on=20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20con= sumers=20!! I'll=20do=20that=20if=20any=20bug=20shows=20its=20face.=20Still=20better= =20than=20migrating=20the servers=20(gloups,=20oh=20no=20I=20don't=20want=20that). Thank=20you=20for=20helping. M Marin=20Le=20Houelleur Projet=20Pharos=20-=20Capgemini marin.lehouelleur(a)astrium.eads.net 05=2062=2019=2068=2059 Ce=20courriel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut= =20contenir=20des=20informations=20confidentielles=20et/ou=20protegees=20= ou=20dont=20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu= =20ce=20courriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,= =20ni=20l'utiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.= =20Merci=20d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer= =20ce=20courriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20re= sponsabilite=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration= =20ou=20de=20falsification=20de=20ce=20courriel=20lors=20de=20sa=20transm= ission=20par=20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE=20HTML=20PUBLIC=20"-//W3C//DTD=20HTML=203.2//EN"> <HTML> <HEAD> <META=20HTTP-EQUIV=3D"Content-Type"=20CONTENT=3D"text/html;=20charset=3Du= s-ascii"> <META=20NAME=3D"Generator"=20CONTENT=3D"MS=20Exchange=20Server=20version= =206.5.7653.2"> <TITLE>Re:=20(ITS#5839)=20overlay=20glue</TITLE> </HEAD> <BODY>  <FONT=20SIZE=3D2=20FACE=3D"Arial">I=20have=20no=20other=20impact=20tha= n=20not=20having=20the=20glued=20branch=20visible=20in=20LDAPBrowser=20:<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">Search=20queries=20on=20the=20glued= =20branch=20works=20perfectly. <FONT=20SIZE=3D2=20FACE=3D"Arial">I'm=20wondering=20about=20the=20pro= per=20use=20of=20overlay=20glue=20as=20error=20message=20appears=20in=20s= lapd=20log=20(directive=20glue-sub=20ignored). <FONT=20SIZE=3D2=20FACE=3D"Arial">Solution=20offered=20by=20Rein=20is= =20good=20looking=20but=20I'll=20have=20to=20deal=20with=2030=20ACLs=20on= =20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20consumers=20= !! <FONT=20SIZE=3D2=20FACE=3D"Arial">I'll=20do=20that=20if=20any=20bug=20= shows=20its=20face.=20Still=20better=20than=20migrating=20the=20servers= =20(gloups,=20oh=20no=20I=20don't=20want=20that). <FONT=20SIZE=3D2=20FACE=3D"Arial">Thank=20you=20for=20helping. <FONT=20SIZE=3D2=20FACE=3D"Arial">M <FONT=20SIZE=3D2=20FACE=3D"Arial">Marin=20Le=20Houelleur <FONT=20SIZE=3D2=20FACE=3D"Arial">Projet=20Pharos=20-=20Capgemini</FO= NT> <FONT=20SIZE=3D2=20FACE=3D"Arial">marin.lehouelleur(a)astrium.eads.net<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">05=2062=2019=2068=2059 </BODY> </HTML> <table><tr><td=20bgcolor=3D#ffffff><font=20color=3D#000000><pre>Ce=20cour= riel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut=20conteni= r=20des=20informations=20confidentielles=20et/ou=20protegees=20ou=20dont= =20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu=20ce=20co= urriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,=20ni=20l'u= tiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.=20Merci=20= d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer=20ce=20cou= rriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20responsabilit= e=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration=20ou=20de=20= falsification=20de=20ce=20courriel=20lors=20de=20sa=20transmission=20par= =20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France</pre></td></t= r></table> ------_=_NextPart_001_01C95559.E58ECC4C--

1 0

Re: (ITS#5841) slapd hanging upon shutdown
by rhafer＠suse.de 03 Dec '08

03 Dec '08

The thread running ldap_pvt_thread_pool_destroy and the one that ran the index task (which was immediately finished after receiving the shutdown signal) are both waiting for the pool->ltp_cond to be signalled. Under normal conditions (slapd is not shutting down) the signal would have been sent by ldap_pvt_thread_pool_resume(), called by the thread that handled the second modify request. But there is an explicit check for pool->ltp_finishing in ldap_pvt_thread_pool_resume(). When pool->ltp_finishing is set this signal is not send. The check for pool->ltp_finishing has been introduced with r1.81 of tpool.c. I am unsure what this was supposed to fix the log message is just: "In pool_resume don't touch the condvar if the pool is tearing down." This patch solves the problem for me, so I am unsure if it'll break other things: --- libraries/libldap_r/tpool.c 10 Mar 2008 12:21:24 -0000 1.97 +++ libraries/libldap_r/tpool.c 3 Dec 2008 14:43:28 -0000 @@ -785,8 +785,7 @@ SET_VARY_OPEN_COUNT(pool); pool->ltp_work_list = &pool->ltp_pending_list; - if (!pool->ltp_finishing) - ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); + ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex); return(0);

1 0

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by andrew.findlay＠skills-1st.co.uk 03 Dec '08

03 Dec '08

On Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote: > I want to create distribution list in OpenLDAP. Meaning - If I have a group > called admins(a)ldap.com and there are two members - bejoy(a)ldap.com and > bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com = both these members must > get the email. Exchange has this feature. This mail id should have a display > name feature as well - that would show up on search of address books. > > At present the work around is using qmail's schema for this distribution list. I > believe inetOrgPerson schema could have a group version too - which would need a > compulsory attribute called members which must have atleast one member mentioned > under it. I think you have just described groupOfNames. I do not like groupOfNames *because* it makes the member attribute mandatory, which makes management complicated. Anyway, I cannot see this as a defect in OpenLDAP. LDAP schema is extensible: if you want something that is not in the standard set you can add it locally. You say that you have used qmail's schema: is there anything wrong with that? Most LDAP-capable mail systems can be persuaded to use groups as mailing lists, but that is a mail system issue not an OpenLDAP one. It could be argued that simple groups are not rich enough to use for list expansion (no way to keep track of per-member list preferences etc) but if we are going to talk about defining an improved group this is the wrong place to do it: maybe IETF's ldapext list would be better. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by ando＠sys-net.it 03 Dec '08

03 Dec '08

rhafer(a)suse.de wrote: > Am Mittwoch 03 Dezember 2008 04:10:36 schrieb hyc(a)symas.com: >> On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: >>> Full_Name: Ralf Haferkamp >>> Version: HEAD, RE24 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (89.166.134.124) >>> >>> >>> When slapd is shutdown while the online indexing task is active it will >>> stop the indexing task immediately leaving a half created index files >>> behind. Searches that use the index afterwards will return imcomplete >>> results. >>> >>> I wonder if we should wait for the indexing task to complete when >>> shutting down the daemon or if there are any other ways to put the >>> databases and the configuration back into a consistant state. (Apart from >>> manually running slapindex) >> That's documented behavior. (See the Admin Guide: >> If slapd is stopped before the index task completes, indexing >> will have to be manually completed using the slapindex tool. >> >> Generally when people issue a shutdown command to slapd they want it to >> Stop Right Now. I think it would be a bad idea to wait, and I see nothing >> to change here. This ITS should be closed. > Ok, waiting for the index task to complete is a bad idea as it can take very > long to complete. But could we indicate the condition somehow that warn the > user about an incomplete run upon next startup? - the index should be invalidated - slapd, at the next manual startup, should complain about the need to run slapindex first. - in order to allow consistent batch restart with no human intervention, slapd could allow to be restarted without running slapindex first, but without making use of the inconsistent index. my 2c, not volunteering right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by rhafer＠suse.de 03 Dec '08

03 Dec '08

Am Mittwoch 03 Dezember 2008 04:10:36 schrieb hyc(a)symas.com: > On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: HEAD, RE24 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.134.124) > > > > > > When slapd is shutdown while the online indexing task is active it will > > stop the indexing task immediately leaving a half created index files > > behind. Searches that use the index afterwards will return imcomplete > > results. > > > > I wonder if we should wait for the indexing task to complete when > > shutting down the daemon or if there are any other ways to put the > > databases and the configuration back into a consistant state. (Apart from > > manually running slapindex) > > That's documented behavior. (See the Admin Guide: > If slapd is stopped before the index task completes, indexing > will have to be manually completed using the slapindex tool. > > Generally when people issue a shutdown command to slapd they want it to > Stop Right Now. I think it would be a bad idea to wait, and I see nothing > to change here. This ITS should be closed. Ok, waiting for the index task to complete is a bad idea as it can take very long to complete. But could we indicate the condition somehow that warn the user about an incomplete run upon next startup? -- Ralf

1 0

(ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 02 Dec '08

02 Dec '08

Full_Name: Bejoy Abraham Mathews Version: 2.4.11 OS: gNewSense Gnu/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.101.252.217) I want to create distribution list in OpenLDAP. Meaning - If I have a group called admins(a)ldap.com and there are two members - bejoy(a)ldap.com and bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com = both these members must get the email. Exchange has this feature. This mail id should have a display name feature as well - that would show up on search of address books. At present the work around is using qmail's schema for this distribution list. I believe inetOrgPerson schema could have a group version too - which would need a compulsory attribute called members which must have atleast one member mentioned under it.

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 02 Dec '08

02 Dec '08

On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD, RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.134.124) > > > When slapd is shutdown while the online indexing task is active it will stop the > indexing task immediately leaving a half created index files behind. Searches > that use the index afterwards will return imcomplete results. > > I wonder if we should wait for the indexing task to complete when shutting down > the daemon or if there are any other ways to put the databases and the > configuration back into a consistant state. (Apart from manually running > slapindex) That's documented behavior. (See the Admin Guide: If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool. Generally when people issue a shutdown command to slapd they want it to Stop Right Now. I think it would be a bad idea to wait, and I see nothing to change here. This ITS should be closed.

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Wednesday, December 03, 2008 1:02 AM +0000 thomas(a)koeller.dyndns.org wrote: > Full_Name: Thomas Koeller > Version: 2.4.13 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.39.153.46) > > > I just built openldap-2.4.13. Issuing the 'make test' command after > building results in slapadd hanging: What version of BDB? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 02 Dec '08

02 Dec '08

Full_Name: Thomas Koeller Version: 2.4.13 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.39.153.46) I just built openldap-2.4.13. Issuing the 'make test' command after building results in slapadd hanging: >---------------------------------------------------------------------- bash-3.2$ make test cd tests; make test make[1]: Entering directory `/home/thomas/build/openldap-2.4.13/tests' make[2]: Entering directory `/home/thomas/build/openldap-2.4.13/tests' Initiating LDAP tests for BDB... Running /home/thomas/src/openldap-2.4.13/tests/scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch to retrieve the cn=Monitor... dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: cn=Monitor supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: OTP vendorName: The OpenLDAP Project <http://www.openldap.org/> entryDN: subschemaSubentry: cn=Subschema dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor objectClass: monitorServer cn: Monitor description: This subtree contains monitoring/managing objects. description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. monitoredInfo: OpenLDAP: slapd 2.4.13 (Dec 3 2008 01:43:49) >>>>> Test succeeded >>>>> /home/thomas/src/openldap-2.4.13/tests/scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... *** hangs here *** >---------------------------------------------------------------------- If I ignore this problem and install anyway, I cannot use the bdb backend. If I do, slapd will hang upon any access. However, if I use the ldif backend, slapd works as expected, so I suspect the problem is in the bdb backend. These are my build options: bash-3.2$ ./config.status --version config.status configured by /home/thomas/src/openldap-2.4.13/configure, generated by GNU Autoconf 2.59, with options "'--prefix=/usr' '--enable-crypt' '--enable-bdb=mod' '--enable-hdb=mod' '--enable-ldap=mod' '--enable-monitor=mod' '--enable-null=mod' '--enable-passwd=mod' '--enable-local' '--enable-overlays=mod' '--with-cyrus-sasl' '--with-threads' '--enable-dynamic' '--enable-modules' 'CC=/usr/gcc/bin/gcc' 'CFLAGS=-pipe -O3 -fomit-frame-pointer -march=native -m64' 'CPP=/usr/gcc/bin/cpp' 'LDFLAGS=-O3 -Wl,--enable-new-dtags,--hash-style=gnu'"

1 0

(ITS#5843) Multi-master doesn't replicate deletes under certain circumstances.
by ildefonso_camargo＠yahoo.com 02 Dec '08

02 Dec '08

Full_Name: Jose Ildefonso Camargo Tolosa Version: 2.4.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (190.73.138.178) Hi! I just configured multi-master replication (with N=3) for testing purposes, and I just found an annoying problem, under these conditions: 1. Configure a N number of "masters", and have them replicate happily (this is important). 2. Stop slapd service on all of the servers. 3. Start slapd service on any number of servers < N (ie, leave at least one stopped). 4. Delete any entry (yes, it only fails with deletes, you can combine changes: modify, add, and delete, and only deletes will fail to replicate). 5. Stop slapd service on *all of the servers again* (this is the most important part). 6. Start slapd service on all the servers. 7. Look for the deleted entry on the server(s) that you left stopped in steps 3 and 4, the entry is there!, but it isn't on the server(s) that were running in step 3 and 4. You will see that, on the servers that you left down on step 3, the deleted entries are still present. If you leave at least one server up, it replicates just fine, the problem is when you stop all of the masters, and then start them again. If you need further info, just ask! I hope this helps, Ildefonso Camargo

1 0

Re: (ITS#5839) overlay glue
by rein＠OpenLDAP.org 02 Dec '08

02 Dec '08

marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) > > Working for one year now with this version of Openldap. I come to the point I > need to glue different branch of my master to the slaves to manage complexe > filtering that I'm unable to manage with overlay syncrepl filters First of all you should upgrade, preferrable to the latest 2.4 release. There have been a lot of syncrepl fixes since this version. But your config design is likely to not function, as only one syncrepl consumer can reliably be configured within a glued set of databases to replicate from the same consumer. You should instead configure syncrepl on the glue suffix with a simple filter that matches all you replicate (or just leave it out and use the default). Configure ACLs on the master that gives each consumer access to only those entries it should receive. Rein

1 0

Re: (ITS#5842) test049, test050 fail on Windows due to "con" filename
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 3:59 PM +0000 test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.11 / HEAD > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) > > > ``make test'' on Cygwin fails with test049, test050, because "con" is a > special device name on Windows. Thanks, fixed in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Monday, December 01, 2008 9:51 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 28, 2008 7:40 PM +0000 quanah(a)zimbra.com wrote: > >> >> >> --On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: > > Latest backtrace, with the patch from HEAD about idletimeout, we get: As a side note, here's a working teardown: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: connection_closing: readying conn=52 sd=22 for close Dec 2 17:45:05 ldap slapd[29835]: connection_close: deferring conn=52 sd=-1 Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: connection_resched: attempting closing conn=52 sd=22 Dec 2 17:45:05 ldap slapd[29835]: daemon: removing 22 Dec 2 17:45:05 ldap slapd[29835]: conn=52 fd=22 closed (idletimeout) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 busy Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: listen=7, new connection on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: 22r Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: read active on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: added 22r (active) listener=(nil) Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: conn=63 fd=22 ACCEPT from IP=192.168.61.36:49196 (IP=192.168.58.179:389) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: As you can see, there's a break between the teardown and accept in this case, as compared to the scneario where it asserts. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5839) overlay glue
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 1:41 PM +0000 marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) The current OpenLDAP release is 2.4.13. The final OpenLDAP 2.3 release was 2.3.43. I suggest you try with either 2.3.43 if you don't want to move yet to OpenLDAP 2.4, or you switch to using OpenLDAP 2.4. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5842) test049, test050 fail on Windows due to "con" filename
by test.007＠seznam.cz 02 Dec '08

02 Dec '08

Full_Name: Test Seven Version: 2.4.11 / HEAD OS: Windows URL: Submission from: (NULL) (195.39.55.20) ``make test'' on Cygwin fails with test049, test050, because "con" is a special device name on Windows. Solution: simply use another name for consumer dir. --- test049-sync-config.orig Tue Feb 12 00:26:52 2008 +++ test049-sync-config Tue Dec 02 16:17:28 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons --- test050-syncrepl-multimaster.orig Mon May 05 23:42:54 2008 +++ test050-syncrepl-multimaster Tue Dec 02 16:25:52 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons

1 0

(ITS#5841) slapd hanging upon shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) After doing these two ldapmodify calls, shutting down slapd while the indexing task is running does not work anymore. slapd just keeps hanging. # ldapmodify -H ldapi:/// dn: olcDatabase={1}hdb,cn=config add: olcDbIndex olcDbIndex: cn eq,sub The above modification will trigger the indexing task. # ldapmodify -H ldapi:/// dn: cn=config replace: olcSizeLimit olcSizeLimit: 10000 When this operation is send while the indexing task is still running, it will wait for the task to complete. When slapd is shutdown during this timeframe, it will just lock up. Here is the backtrace of the hanging process: Thread 3 (Thread 0x7ff2ca2a5950 (LWP 13006)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f24fb in ldap_pvt_thread_pool_destroy (tpool=0x853688, run_pending=1) at ../../../libraries/libldap_r/tpool.c:570 pool = <value optimized out> pptr = (struct ldap_int_thread_pool_s *) 0x885540 task = <value optimized out> #2 0x0000000000431f9f in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2591 l = 2 last_idle_check = 0 ebadf = 0 #3 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ff2c9aa4950 (LWP 13007)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f2a4d in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at ../../../libraries/libldap_r/tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x885540 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x1c ctx = {ltu_id = 140680742193488, ltu_key = {{ltk_key = 0x4337e0, ltk_data = 0xb0ee20, ltk_free = 0x4338b0 <conn_counter_destroy>}, { ltk_key = 0x488c10, ltk_data = 0xb0ef30, ltk_free = 0x488710 <slap_sl_mem_destroy>}, {ltk_key = 0x4478f0, ltk_data = 0xb0e9d0, ltk_free = 0x4476d0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = <value optimized out> keyslot = 829 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #2 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ff2d0714710 (LWP 12992)): #0 0x00007ff2ce07c7b5 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042ee3c in slapd_daemon () at ../../../servers/slapd/daemon.c:2656 listener_tid = 140680750586192 rc = 0 #2 0x000000000041cd95 in main (argc=7, argv=0x7fffd874b9e8) at ../../../servers/slapd/main.c:948 i = <value optimized out> no_detach = 1 rc = -12 urls = 0x854030 "ldap:/// ldapi:///" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x0 configdir = 0x854010 "/etc/openldap/slapd.d" serverName = 0x7fffd874d63b "lt-slapd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"

1 0

(ITS#5840) bdb_online_index and shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) When slapd is shutdown while the online indexing task is active it will stop the indexing task immediately leaving a half created index files behind. Searches that use the index afterwards will return imcomplete results. I wonder if we should wait for the indexing task to complete when shutting down the daemon or if there are any other ways to put the databases and the configuration back into a consistant state. (Apart from manually running slapindex)

1 0

(ITS#5839) overlay glue
by marin.lehouelleur＠astrium.eads.net 02 Dec '08

02 Dec '08

Full_Name: Marin Le Houelleur Version: 2.3.32 OS: Linux RH5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.94.82.30) Working for one year now with this version of Openldap. I come to the point I need to glue different branch of my master to the slaves to manage complexe filtering that I'm unable to manage with overlay syncrepl filters Master : 1 db database bdb suffix dc=exemple,dc=com It contains following ou's : sites, applis and orgz sites itselfs contains site1, site2... and may contain more which should not be replicated to other sites overlay synchrorepl Slaves (1 per site) : 2 dbs database bdb suffix ou=sites,dc=exemple,dc=com synchrepl rid=111 searchbase ou=sites,dc=exemple,dc=com filter="(ou:dn:=site1)" database bdb suffix dc=exemple,dc=com synchrepl rid=222 searchbase dc=exemple,dc=com filter="(|(ou:dn:=orgz)(ou:dn:=applis))" overlay glue glue-sub ou=sites,dc=exemple,dc=com @ slapd start the directive glue-sub is ignored I tried on the first db to had directive "subordinate advertise" instead but it's documented not to be needed when using glue overlay. Nevertheless the 1st db is synchronised and searchable but not visible in tools such as ldapbrowser. best regards,

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 02 Dec '08

02 Dec '08

It seems OK with 2.4.13 > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : mardi 18 novembre 2008 22:39 > À : Emmanuel Duru > Cc : 'Hallvard Breien Furuseth'; openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > Emmanuel Duru wrote: > > OK, my mistake, here follows a completely detailed description. > > I confirm HEAD and re24 behave as expected. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 01 Dec '08

01 Dec '08

--On Friday, November 28, 2008 7:40 PM +0000 quanah(a)zimbra.com wrote: > > > --On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: Latest backtrace, with the patch from HEAD about idletimeout, we get: (gdb) bt #0 0x0000003fca02e21d in raise () from /lib64/tls/libc.so.6 #1 0x0000003fca02fa1e in abort () from /lib64/tls/libc.so.6 #2 0x0000003fca027ae1 in __assert_fail () from /lib64/tls/libc.so.6 #3 0x000000000042b5c1 in connection_close (c=0x3b69520) at connection.c:877 #4 0x0000000000429e7d in connections_timeout_idle (now=1228167365) at connection.c:242 #5 0x0000000000428097 in slapd_daemon_task (ptr=0x0) at daemon.c:2039 #6 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #8 0x0000000000000000 in ?? () Looking at the connection, we see: (gdb) frame 3 #3 0x000000000042b5c1 in connection_close (c=0x3b69520) at connection.c:877 877 connection.c: No such file or directory. in connection.c (gdb) print *c $1 = {c_struct_state = 2, c_conn_state = 3, c_conn_idx = 28, c_close_reason = 0x4bea5b "?", c_mutex = {__m_reserved = 2, __m_count = 0, __m_owner = 0x100002068, __m_kind = 0, __m_lock = { __status = 0, __spinlock = 0}}, c_sb = 0x13b4d860, c_starttime = 1228167365, c_activitytime = 1228167365, c_connid = 3120, c_peer_domain = {bv_len = 7, bv_val = 0xdfac1b0 "unknown"}, c_peer_name = {bv_len = 23, bv_val = 0x108dc558 "IP=192.168.58.225:53050"}, c_listener = 0x88df00, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = { sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x64abc00, stqh_last = 0x64abd58}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x3b69650}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 3556232921088, __spinlock = 414}, __c_waiting = 0x19e, __padding = "\236\001\000\000\000\000\000\0008\225ï¿½\003\000\000\000", __align = 0}, c_currentber = 0xe032000, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0xe035400, c_sasl_sockctx = 0x0, c_sasl_extra = 0x669cac8, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 1, c_n_ops_executing = 1, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 1, c_n_read = 1, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x43ea8c <slap_send_ldap_result>, c_send_search_entry = 0x43f787 <slap_send_search_entry>, c_send_search_reference = 0x44188d <slap_send_search_reference>, c_send_ldap_extended = 0x43f2fa <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x43f57e <slap_send_ldap_intermediate>} So this was file descriptor 28. This is definitely the same assert as before in connection.c: assert( c->c_conn_state == SLAP_C_CLOSING ); being line 877. Line 242 is: if( difftime( c->c_activitytime+global_idletimeout, now) < 0 ) { /* close it */ connection_closing( c, "idletimeout" ); --> connection_close( c ); i++; } The log file shows: Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: 28r Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:04 ldap slapd[8292]: Dec 2 03:06:04 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:06:04 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:06:04 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:06:05 ldap slapd[8292]: daemon: activity on: Dec 2 03:06:05 ldap slapd[8292]: Dec 2 03:06:05 ldap slapd[8292]: daemon: hangup on 28 Dec 2 03:06:05 ldap slapd[8292]: connection_closing: readying conn=3049 sd=28 for close Dec 2 03:06:05 ldap slapd[8292]: connection_resched: attempting closing conn=3049 sd=28 Dec 2 03:06:05 ldap slapd[8292]: daemon: removing 28 Dec 2 03:06:05 ldap slapd[8292]: conn=3049 fd=28 closed (idletimeout) Dec 2 03:06:05 ldap slapd[8292]: daemon: listen=7, new connection on 28 Dec 2 03:06:05 ldap slapd[8292]: daemon: added 28r (active) listener=(nil) Dec 2 03:06:05 ldap slapd[8292]: conn=3120 fd=28 ACCEPT from IP=192.168.58.225:53050 (IP=192.168.58.179:389) Dec 2 03:06:05 ldap slapd[8292]: conn=3120 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 And here's the start of the previous connection on descriptor 28: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 busy Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: listen=7, new connection on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: added 28r (active) listener=(nil) Dec 2 03:03:53 ldap slapd[8292]: conn=3049 fd=28 ACCEPT from IP=192.168.61.35:57352 (IP=192.168.58.179:389) Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 2 descriptors Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=0 STARTTLS Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=0 RESULT oid= err=0 text= Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=1 RESULT tag=97 err=0 text= Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: 28r Dec 2 03:03:53 ldap slapd[8292]: Dec 2 03:03:53 ldap slapd[8292]: daemon: read active on 28 Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dec 2 03:03:53 ldap slapd[8292]: conn=3049 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on 1 descriptor Dec 2 03:03:53 ldap slapd[8292]: daemon: activity on: Dec 2 03:03:53 ldap slapd[8292]: Then nothing logged again until the first segment quoted where it crashed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 01 Dec '08

01 Dec '08

Full_Name: Howard Allison Version: 2.4.11 OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.153.217.235) After running for a few hours slapd crashes and dumps core. here is the output from dbx: IOT/Abort trap in pthread_kill at 0xd04a73c0 ($t19) 0xd04a73c0 (pthread_kill+0xa0) 80410014 lwz r2,0x14(r1) slapd was compiled under AIX 6100-00-03-0808 using gcc 4.2.0-3 with these flags: --prefix=/opt/pware/openldap-2.4.11 --with-openssl --with-shared=yes --enable-policy --enable-unique --enable-ssl Here is the slapd.conf file(DB part): database bdb suffix (excluded) rootdn (excluded) rootpw (excluded) index objectClass eq,pres index entryCSN,entryUUID eq index cn eq,sub index uid eq index memberUid eq index uidNumber eq index gidNumber eq directory /app/openldap/var/openldap-data/ checkpoint 1024 120 overlay syncprov syncprov-checkpoint 256 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_hash_cleartext Here is the output from ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited memory(kbytes) unlimited coredump(blocks) 2097151 nofiles(descriptors) 5000 threads(per process) unlimited processes(per user) unlimited

1 0

FW: (ITS#5832) Networking and Replication.
by Nils.Hammar＠cybercomgroup.com 30 Nov '08

30 Nov '08

------=_NextPart_000_0005_01C95387.D1D6DEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nils Hammar Direct / Mobile / SMS / MMS +46 733 12 34 63 Please remove the number 744 81 49 from your address book, it will be invalid after May 26, 2008. -----Original Message----- From: Nils Hammar Sent: den 28 november 2008 09:57 To: 'Quanah Gibson-Mount' Subject: RE: (ITS#5832) Networking and Replication. Oh - sorry, that was a reply to the wrong error, this commend should have been to #5831. /Nils Nils Hammar Direct / Mobile / SMS / MMS +46 733 12 34 63 Please remove the number 744 81 49 from your address book, it will be invalid after May 26, 2008. -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: den 28 november 2008 09:25 To: Nils Hammar; openldap-its(a)openldap.org Subject: RE: (ITS#5832) Networking and Replication. --On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. That makes no sense to me, BDB isn't communicating at the network level... Everything at that level is LDAP protocol. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------=_NextPart_000_0005_01C95387.D1D6DEA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZI AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2 YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8E KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHoweKFj pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/iKs s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEnw9G 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DWZj9 Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaMIIB HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UE CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEAxQL TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYVzyz IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4UbdPZT tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfMAkG A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZBJCs jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQesJ4 bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDOoYd N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smzKVM ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDgxMjAxMDYzODM2WjAjBgkqhkiG9w0BCQQxFgQUxURdhNsEQuE10rmYAI4Q 40H7rcowZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggED BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYA5egAZCGPWaNZiOwYxxabYlhLwFxUlQTF3yznX XvQVMRiTt3XzlZwcZGoYQchD044ZU+ZmeWxABbn26OmKfEAtHrocVHxoWrdRqoVoRj0PmFtCUkGn kLT5USDAZFRT7DTh+cZTvTflP5XvSL3Zt08O3JAhcfD4AwYoCYwdxFF2WAAAAAAAAA== ------=_NextPart_000_0005_01C95387.D1D6DEA0--

1 0

Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it 30 Nov '08

30 Nov '08

quanah(a)zimbra.com wrote: > --On Saturday, November 29, 2008 5:32 AM +0000 manu(a)netbsd.org wrote: > >> Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: >> >>> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as >>> well. >> Did it? Where is the report about that? > > Can't find it atm, but I remember someone writing in about ACI's being > broken in HEAD right now, and I believe it was related to this change. > RE2.4 was a typo on my part, since this isn't in RE24 right now. Yes (I think it was Hallvard). ACIs broke since acl_string_expand() changed prototype, but the number of args was the same, and compiling succeeded with a warning (which I didn't notice, btw). To make it worse, test041 did not fail (apparently, it makes no use of string expansion). Now it's fixed; I'd say hacked, since I did not want to change the API of dynacl, yet. Changing the API should not be a big deal, given the presumably limited number of custom dynacl 'round. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5804) attribute value regex expantion
by quanah＠zimbra.com 29 Nov '08

29 Nov '08

--On Saturday, November 29, 2008 5:32 AM +0000 manu(a)netbsd.org wrote: > Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > >> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as >> well. > > Did it? Where is the report about that? Can't find it atm, but I remember someone writing in about ACI's being broken in HEAD right now, and I believe it was related to this change. RE2.4 was a typo on my part, since this isn't in RE24 right now. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 28 Nov '08

28 Nov '08

Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. Did it? Where is the report about that? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 29, 2008 1:33:51 AM +0000 quanah(a)OpenLDAP.org wrote: > > > --On November 28, 2008 11:37:25 PM +0000 quanah(a)OpenLDAP.org wrote: > > >> Patch from Howard needs to be expanded so that a new keyword is used for >> the idle timer here, rather than the value from idletimeout. This will >> require some reworking of the daemon to wake up for that interval as >> well. > > After this patch, slapd can stay up, but seems to not be able to shut > down. The threads show: Ok, it did eventually finish. After starting slapd again, however, I noticed: Nov 29 07:06:41 new slapd[26537]: conn=8 fd=31 ACCEPT from IP=192.168.61.21:36322 (`ï¿½) --Quanah

1 0

Re: (ITS#5836) hung writers
by quanah＠OpenLDAP.org 28 Nov '08

28 Nov '08

--On November 28, 2008 11:37:25 PM +0000 quanah(a)OpenLDAP.org wrote: > Patch from Howard needs to be expanded so that a new keyword is used for > the idle timer here, rather than the value from idletimeout. This will > require some reworking of the daemon to wake up for that interval as well. After this patch, slapd can stay up, but seems to not be able to shut down. The threads show: (gdb) thr apply all bt Thread 4 (Thread 1082132832 (LWP 2205)): #0 0x0000003fca9089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8f58 in ldap_pvt_thread_cond_wait (cond=0x8a2f30, mutex=0x8a2f08) at thr_posix.c:299 #2 0x0000002a956c78e8 in ldap_pvt_thread_pool_destroy (tpool=0x617648, run_pending=1) at tpool.c:381 #3 0x0000000000429704 in slapd_daemon_task (ptr=0x0) at daemon.c:2516 #4 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #5 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #6 0x0000000000000000 in ?? () Thread 3 (Thread 1115703648 (LWP 2209)): #0 0x0000003fca90bd9c in __pread_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000002a97348edc in __os_io (dbenv=0xdc2100, op=1, fhp=0xf8d4d8, pgno=399474, pagesize=16384, buf=0x2ae8a1cc20 "Y,", niop=0x42681c30) at ../dist/../os/os_rw.c:55 #2 0x0000002a973405ea in __memp_pgread (dbmfp=0xeab3c0, mutexp=0x2bb963f008, bhp=0x2ae8a1cb88, can_create=0) at ../dist/../mp/mp_bh.c:219 #3 0x0000002a973413f7 in __memp_fget (dbmfp=0xeab3c0, pgnoaddr=0x42681d84, flags=0, addrp=0x42681d88) at ../dist/../mp/mp_fget.c:580 #4 0x0000002a972d18b3 in __bam_search (dbc=0xd2dc380, root_pgno=Variable "root_pgno" is not available. ) at ../dist/../btree/bt_search.c:307 #5 0x0000002a972c6e27 in __bam_c_search (dbc=0xd2dc380, root_pgno=0, key=0x42682050, flags=28, exactp=0x42681eb4) at ../dist/../btree/bt_cursor.c:2547 #6 0x0000002a972c7b7e in __bam_c_get (dbc=0xd2dc380, key=0x42682050, data=0x42682030, flags=28, pgnop=0x42681f24) at ../dist/../btree/bt_cursor.c:962 #7 0x0000002a9730f51b in __db_c_get (dbc_arg=0xd2dc1c0, key=0x42682050, data=0x42682030, flags=28) at ../dist/../db/db_cam.c:643 #8 0x0000002a973177d7 in __db_c_get_pp (dbc=0xd2dc1c0, key=0x42682050, data=0x42682030, flags=28) at ../dist/../db/db_iface.c:1836 #9 0x0000002a97184a16 in bdb_id2entry (be=0x42802a40, tid=0x0, locker=23, id=3443171, e=0x42682148) at id2entry.c:130 #10 0x0000002a97189e18 in bdb_cache_find_id (op=0x428025e0, tid=0x0, id=3443171, eip=0x42682310, islocked=0, locker=23, lock=0x42682250) at cache.c:714 #11 0x0000002a9717b1c7 in bdb_search (op=0x428025e0, rs=0x42802570) at search.c:696 #12 0x0000002a975921eb in syncprov_findcsn (op=0x5c1bc00, mode=FIND_PRESENT) at syncprov.c:681 #13 0x0000002a9759690a in syncprov_op_search (op=0x5c1bc00, rs=0x42803d60) at syncprov.c:2074 #14 0x000000000049b999 in overlay_op_walk (op=0x5c1bc00, rs=0x42803d60, which=op_search, oi=0xdec8c0, on=0xdec700) at backover.c:640 #15 0x000000000049bbf5 in over_op_func (op=0x5c1bc00, rs=0x42803d60, which=op_search) at backover.c:702 #16 0x000000000049bc8b in over_op_search (op=0x5c1bc00, rs=0x42803d60) at backover.c:724 #17 0x000000000042f23c in fe_op_search (op=0x5c1bc00, rs=0x42803d60) at search.c:355 #18 0x000000000042ed10 in do_search (op=0x5c1bc00, rs=0x42803d60) at search.c:217 #19 0x000000000042bdff in connection_operation (ctx=0x42803e90, arg_v=0x5c1bc00) at connection.c:1133 #20 0x000000000042c2ef in connection_read_thread (ctx=0x42803e90, argv=0x1e) at connection.c:1261 #21 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #22 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #23 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #24 0x0000000000000000 in ?? () Thread 2 (Thread 1124096352 (LWP 2210)): #0 bdb_idl_union (a=0xb3ff000, b=0xb1ff000) at idl.c:1151 #1 0x0000002a971829fc in inequality_candidates (op=0x5b11c00, ava=0x5a06518, ids=0xb3ff000, tmp=0xb1ff000, gtorlt=165) at filterindex.c:1063 #2 0x0000002a9717ff83 in bdb_filter_candidates (op=0x5b11c00, f=0x5a064f8, ids=0xb3ff000, tmp=0xb1ff000, stack=0xb4ff000) at filterindex.c:158 #3 0x0000002a97180595 in list_candidates (op=0x5b11c00, flist=0x5a064f8, ftype=160, ids=0xb2ff000, tmp=0xb1ff000, save=0xb3ff000) at filterindex.c:503 #4 0x0000002a97180213 in bdb_filter_candidates (op=0x5b11c00, f=0x5a064d8, ids=0xb2ff000, tmp=0xb1ff000, stack=0xb3ff000) at filterindex.c:183 #5 0x0000002a97180595 in list_candidates (op=0x5b11c00, flist=0x42e83670, ftype=160, ids=0x42f03970, tmp=0xb1ff000, save=0xb2ff000) at filterindex.c:503 #6 0x0000002a97180213 in bdb_filter_candidates (op=0x5b11c00, f=0x42e836d0, ids=0x42f03970, tmp=0xb1ff000, stack=0xb2ff000) at filterindex.c:183 #7 0x0000002a9717c2f1 in search_candidates (op=0x5b11c00, rs=0x43004d60, e=0x42e83910, locker=57, ids=0x42f03970, scopes=0x42e83970) at search.c:1124 #8 0x0000002a9717ad57 in bdb_search (op=0x5b11c00, rs=0x43004d60) at search.c:595 #9 0x000000000049ba2d in overlay_op_walk (op=0x5b11c00, rs=0x43004d60, which=op_search, oi=0xdece00, on=0x0) at backover.c:650 #10 0x000000000049bbf5 in over_op_func (op=0x5b11c00, rs=0x43004d60, which=op_search) at backover.c:702 #11 0x000000000049bc8b in over_op_search (op=0x5b11c00, rs=0x43004d60) at backover.c:724 #12 0x000000000042f23c in fe_op_search (op=0x5b11c00, rs=0x43004d60) at search.c:355 #13 0x000000000042ed10 in do_search (op=0x5b11c00, rs=0x43004d60) at search.c:217 #14 0x000000000042bdff in connection_operation (ctx=0x43004e90, arg_v=0x5b11c00) at connection.c:1133 #15 0x000000000042c2ef in connection_read_thread (ctx=0x43004e90, argv=0x19) at connection.c:1261 #16 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #17 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #18 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #19 0x0000000000000000 in ?? () Thread 1 (Thread 182904263232 (LWP 2201)): #0 0x0000003fca906ffb in pthread_join () from /lib64/tls/libpthread.so.0 #1 0x0000002a956c8eb0 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:193 #2 0x00000000004297d1 in slapd_daemon () at daemon.c:2581 #3 0x00000000004129d9 in main (argc=10, argv=0x7fbfffb918) at main.c:859 --Quanah

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs