- openldap-bugs - openldap.org

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

05 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 05 Dec '08

05 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 04 Dec '08

04 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 03 Dec '08

03 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 03 Dec '08

03 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 03 Dec '08

03 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 03 Dec '08

03 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 03 Dec '08

03 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 03 Dec '08

03 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 01 Dec '08

01 Dec '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 30 Nov '08

30 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 29 Nov '08

29 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 29 Nov '08

29 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 29 Nov '08

29 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

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

29 Nov '08

--On November 28, 2008 10:49:36 PM +0000 quanah(a)OpenLDAP.org wrote: > slapd ends up hanging indefinitely. This happened with 8 replicas > connected to the server, where for four of those replicas, the connection > between the master and the replica wouldn't connect (but you could go > from the replica to the master) at some point after the initial > connection was made. > > Patch to HEAD from Howard is committed. 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. --Quanah

1 0

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

28 Nov '08

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24/RE23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a scenario where the network is broken (or other reasons, but that's where I hit it), slapd can get locked up waiting on writers to finish. When that happens, everything ends up in a pthread_cond_wait, like this: Thread 8 (Thread 1098918240 (LWP 18884)): #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=0x385bdf0, mutex=0x385bca0) at thr_posix.c:299 #2 0x000000000043dc91 in send_ldap_ber (conn=0x385bc88, ber=0x41680610) at result.c:198 #3 0x0000000000441450 in slap_send_search_entry (op=0x625bc00, rs=0x41801d60) at result.c:1137 #4 0x0000002a9717b9e1 in bdb_search (op=0x625bc00, rs=0x41801d60) at search.c:879 #5 0x000000000049b9c9 in overlay_op_walk (op=0x625bc00, rs=0x41801d60, which=op_search, oi=0xdece00, on=0x0) at backover.c:650 #6 0x000000000049bb91 in over_op_func (op=0x625bc00, rs=0x41801d60, which=op_search) at backover.c:702 #7 0x000000000049bc27 in over_op_search (op=0x625bc00, rs=0x41801d60) at backover.c:724 #8 0x000000000042f1d8 in fe_op_search (op=0x625bc00, rs=0x41801d60) at search.c:355 #9 0x000000000042ecac in do_search (op=0x625bc00, rs=0x41801d60) at search.c:217 #10 0x000000000042bd9c in connection_operation (ctx=0x41801e90, arg_v=0x625bc00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41801e90, argv=0x1f) at connection.c:1261 #12 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a2f00) at tpool.c:478 #13 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #14 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #15 0x0000000000000000 in ?? () slapd ends up hanging indefinitely. This happened with 8 replicas connected to the server, where for four of those replicas, the connection between the master and the replica wouldn't connect (but you could go from the replica to the master) at some point after the initial connection was made. Patch to HEAD from Howard is committed. --Quanah

1 0

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

28 Nov '08

quanah(a)zimbra.com wrote: > --On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > >> >> --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: >> >>> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >>> >>>> Turns out 'val' is nil and it doesn't seem like there's any check for >>>> that. Maybe naive fix: >>> I see Ando committed it. But there are many other locations in the file >>> where acl_string_expand is called with an unchecked val->bv_val. It >>> seems these also need to be fixed, but I miaght be missing a point. >> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. > > Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. :) I've reworked the use of string expansion (and lined up regex expansion in "by" dn). In order to fix ACIs, the dynacl API needs to be enhanced to support AclRegexMatches. 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 28 Nov '08

28 Nov '08

--On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > > > --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > >> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >> >>> Turns out 'val' is nil and it doesn't seem like there's any check for >>> that. Maybe naive fix: >> >> I see Ando committed it. But there are many other locations in the file >> where acl_string_expand is called with an unchecked val->bv_val. It >> seems these also need to be fixed, but I miaght be missing a point. > > IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. --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 quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > >> Turns out 'val' is nil and it doesn't seem like there's any check for >> that. Maybe naive fix: > > I see Ando committed it. But there are many other locations in the file > where acl_string_expand is called with an unchecked val->bv_val. It > seems these also need to be fixed, but I miaght be missing a point. IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. --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

Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > Turns out 'val' is nil and it doesn't seem like there's any check for > that. Maybe naive fix: I see Ando committed it. But there are many other locations in the file where acl_string_expand is called with an unchecked val->bv_val. It seems these also need to be fixed, but I miaght be missing a point. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

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

28 Nov '08

--On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > > >> As you can see, we lose a connection and then try to read from it (FD >> 40). This is where the log ends because the assert triggered. > > Printing the connection struct shows it is actually an issue with FD 26: The previous connection on FD 26 shows: Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 ACCEPT from IP=192.168.61.154:40988 (IP=192.168.58.179:389) Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 STARTTLS Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 RESULT oid= err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 TLS established tls_ssf=256 ssf=256 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 RESULT tag=97 err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN [then nothing for a long time until]: Nov 29 00:29:41 new slapd[8930]: conn=335 fd=26 closed (connection lost) Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 RESULT tag=97 err=0 text= Nov 29 00:29:41 new slapd[8930]: conn=498 fd=26 ACCEPT from IP=192.168.58.231:45575 (IP=192.168.58.179:389) Nov 29 00:29:41 new slapd[8930]: connection_read(40): no connection! Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 RESULT tag=97 err=0 text= [slapd crashes] The consumer here in conn 335 is a refreshAndPersist consumer. Not entirely clear why it's connection gets closed. --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 28 Nov '08

28 Nov '08

--On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > As you can see, we lose a connection and then try to read from it (FD > 40). This is where the log ends because the assert triggered. Printing the connection struct shows it is actually an issue with FD 26: (gdb) print *c $1 = {c_struct_state = 2, c_conn_state = 2, c_conn_idx = 26, c_close_reason = 0x4be9fb "?", c_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x1000022ee, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0xdcb1de0, c_starttime = 1227898781, c_activitytime = 1227898781, c_connid = 498, c_peer_domain = {bv_len = 7, bv_val = 0xe61c50 "unknown"}, c_peer_name = {bv_len = 23, bv_val = 0xc89d900 "IP=192.168.58.231:45575"}, c_listener = 0x88cf00, 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 = 0xdeda80, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 30, bv_val = 0xdcb1d60 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ndn = {bv_len = 30, bv_val = 0xdcb1cc0 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 3, c_ops = {stqh_first = 0x0, stqh_last = 0x3670150}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x3670160}, 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 = 111669149696, __spinlock = 13}, __c_waiting = 0xd, __padding = "\r\000\000\000\000\000\000\000H\000g\003\000\000\000", __align = 0}, c_currentber = 0xdc6d410, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x5d65000, c_sasl_sockctx = 0x0, c_sasl_extra = 0x5d64d98, 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 = 0, c_n_ops_pending = 0, c_n_ops_completed = 1, 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 = 0x43ea28 <slap_send_ldap_result>, c_send_search_entry = 0x43f723 <slap_send_search_entry>, c_send_search_reference = 0x441829 <slap_send_search_reference>, c_send_ldap_extended = 0x43f296 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x43f51a <slap_send_ldap_intermediate>} which is the connection currently logged as binding right before slapd crashes. --quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.uoa.gr wrote: > The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is > not implemented. Instead there is a undocumented context called 'renameDN' which > when undefined will use the default context. The submitted patch simply enables > the 'modrDN' context. The fix required a little bit more than that, in order to deal with errors and cleanup as appropriate. Fixed in HEAD, including slapo-rwm(5). Thanks, 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs