openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

(ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 03 Apr '12

03 Apr '12

Full_Name: Hrvoje Version: 2.4.30 OS: Centos 6.2 x86_64 URL: http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log Submission from: (NULL) (195.29.148.138) Hi. While testing openlap, with some of my data, slapd regularly hangs. I did manage to "catch" it, but i need expert's interpretation of traces. I' using db-5.3.15 (latest), compiled with: ../dist/configure \ --enable-shared --enable-static \ --enable-tcl --with-tcl=/usr/lib64 \ --enable-cxx --enable-sql \ --enable-java \ --enable-test \ --with-tcl=/usr/lib64/tcl8.5 \ --disable-rpath \ --enable-debug \ --prefix=/usr/local/db and openldap-2.4.30, compiled with: CFLAGS="-g -I/usr/local/db/include" CPPFLAGS="-g -I/usr/local/db/include" LDFLAGS="-L/usr/local/db/lib -Wl,-R/usr/local/db/lib" ./configure \ --prefix=/usr/local/openldap \ --enable-local \ --enable-rlookups \ --with-tls=no \ --with-cyrus-sasl \ --enable-wrappers \ --enable-passwd \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --disable-lmpasswd \ --enable-modules \ --disable-sql \ --enable-slapd \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-shell \ --disable-ndb \ --enable-passwd \ --enable-sock \ --disable-perl \ --enable-relay \ --disable-shared \ --disable-dynamic \ --enable-overlays=mod \ --enable-mdb \ --enable-debug=yes Slapd is configured to use slapd.d directory (db). Inside, two databases are configured - ie. ou=p,dc=pero,dc=com and ou=d,dc=pero,dc=com, including monitor db. First database is using 10Gb on disk, and have around 10M unique dn's, while second one is using around 3-4Gb, few mil. dn's. Server have 16G of ram, and 2xquad core CPU - total of 8 cpu's (and disks are local). I'm using python scripts to generate load on openldap. First i fill in required data (10Gb), and then do some transaction processing (read/update/write). Filling part goes without problems, but on transaction processing, slapd regularly gets stuck. I'm only able to trigger this using more than one connection - simulating couple of clients, and high load (1-2 req/sec). Complete traces from gdb when this happens, are http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log . So, am i doing something wrong or openldap is...? H.

1 0

(ITS#7221) Support private keys in PKCS #8 in slapd when linked with gnutls
by komyagin＠altell.ru 03 Apr '12

03 Apr '12

Full_Name: Alexander Komyagin Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.16.156.18) Hi! I found out that when slapd is linked with gnutls, it fails to parse private key on startup if the one is given in PKCS #8 form (TLS init def ctx failed: -207). The problem is in tlsg_ctx_init() (tls_g.c) function, which calls gnutls_x509_privkey_import() from gnutls. But gnutls_x509_privkey_import() is designed to support only RSA/DSA keys, while for PKCS#8 gnutls_x509_privkey_import_pkcs8() shall be used. I think that incorporating such enhancement for slapd would make it even better (for example, some popular commands like "openssl req" generate keys in PKCS #8) :) Especially when such enhancement can be done in a few lines of code (just like certtool does): if (!info.pkcs8) ret = gnutls_x509_privkey_import (key, &pem, info.incert_format); /* If we failed to import the certificate previously try PKCS #8 */ if (info.pkcs8 || ret == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) { /* first try to import the key without asking any password */ ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, NULL, GNUTLS_PKCS_PLAIN); if (ret < 0) { if (info.pass) pass = info.pass; else pass = get_pass (); ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, pass, 0); } }

1 0

Re: RE : RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Apr '12

02 Apr '12

jiashun.qian(a)atos.net wrote: > After the tests, these patchs work but not work for what we expect. According to Howard Chu, "Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules." These patchs send binary data to backends. Could you change this ? I probably mis-spoke. Only back-shell deals exclusively in LDIF, back-perl is obviously passing native perl variables around. > ________________________________________ > De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de quanah(a)zimbra.com [quanah(a)zimbra.com] > Date d'envoi : jeudi 29 mars 2012 19:26 > À : openldap-its(a)openldap.org > Objet : Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data > > --On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net > wrote: > >> This is a multi-part message in MIME format. >> --------------060203070300020608020002 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >>> Laurent.LeGrandois(a)atos.net wrote: >>>> This is a multi-part message in MIME format. >>>> --------------070001090703090002060300 >>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Hi, >>>> >>>> any news concerning integration of this patch ? >>> An alternate patch is now in git master, please test. >> Ok, we will test it : any modifications to do for 2.4.28 version ? > > Please respond once you've tested. Since there were changes to back-perl > for 2.4.29, it may not apply cleanly to a 2.4.28 build. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > ________________________________ > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7220) Ldap_search_ext API blocked for around 20mints
by masarati＠aero.polimi.it 02 Apr '12

02 Apr '12

> Full_Name: Kona Jagan > Version: libldap-2.2.so.7.0.6 > OS: Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.17.121.249) > > > Hi All, > > I have written a ldap client application in Linux which uses > ldap_search_ext() > API for querying details of a user. I am using two threads, one for > sending ldap > search queries and other for receiving response from Ldap server which > uses > ldap_result API. > > At production i am facing a issue which breaks down to ldap_search_ext() > API got > blocked which is causing all ldap request's to timeout. Can anyone help me > to > understand about the blocking behavior of ldap_search_ext() API. I mean > when > ldap_search_ext() API gets blocked.please provide me the user cases which > can > cause this behavior. As far as I know, asynchronous LDAP calls can only block when connect(2) blocks. There's a workaround for that (which only prevents blocking) but since blocking on connect(2) indicates a more serious issue (e.g. network misconfiguration), I'd address that issue first. In any case, there is nothing so far indicating a bug in OpenLDAP software, so I'd consider this ITS closed.

1 0

(ITS#7220) Ldap_search_ext API blocked for around 20mints
by konajagan＠gmail.com 02 Apr '12

02 Apr '12

Full_Name: Kona Jagan Version: libldap-2.2.so.7.0.6 OS: Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.17.121.249) Hi All, I have written a ldap client application in Linux which uses ldap_search_ext() API for querying details of a user. I am using two threads, one for sending ldap search queries and other for receiving response from Ldap server which uses ldap_result API. At production i am facing a issue which breaks down to ldap_search_ext() API got blocked which is causing all ldap request's to timeout. Can anyone help me to understand about the blocking behavior of ldap_search_ext() API. I mean when ldap_search_ext() API gets blocked.please provide me the user cases which can cause this behavior. Thanks in advance. regards, Jagan

1 0

RE : RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 02 Apr '12

02 Apr '12

After the tests, these patchs work but not work for what we expect. According to Howard Chu, "Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules." These patchs send binary data to backends. Could you change this ? ________________________________________ De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de quanah(a)zimbra.com [quanah(a)zimbra.com] Date d'envoi : jeudi 29 mars 2012 19:26 À : openldap-its(a)openldap.org Objet : Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data --On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------060203070300020608020002 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >> Laurent.LeGrandois(a)atos.net wrote: >>> This is a multi-part message in MIME format. >>> --------------070001090703090002060300 >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> Content-Transfer-Encoding: quoted-printable >>> >>> Hi, >>> >>> any news concerning integration of this patch ? >> An alternate patch is now in git master, please test. > Ok, we will test it : any modifications to do for 2.4.28 version ? Please respond once you've tested. Since there were changes to back-perl for 2.4.29, it may not apply cleanly to a 2.4.28 build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

1 0

(ITS#7219) back-mdb crash when used as accesslog
by quanah＠OpenLDAP.org 30 Mar '12

30 Mar '12

Full_Name: Quanah Gibson-Mount Version: HEAD 3/30/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) 4f764244 => access_allowed: search access to "reqStart=20120330232137.000001Z,cn=accesslog" "reqStart" requested 4f764244 <= root access granted 4f764244 => access_allowed: search access granted by manage(=mwrscxd) 4f764244 <= test_filter 6 4f764244 send_ldap_result: conn=-1 op=0 p=0 4f764244 send_ldap_result: err=0 matched="" text="" 4f764244 ==> mdb_delete: reqStart=20120330215514.000205Z,cn=accesslog 4f764244 mdb_dn2entry("cn=accesslog") 4f764244 => mdb_dn2id("cn=accesslog") 4f764244 <= mdb_dn2id: got id=0x1 4f764244 => mdb_entry_decode: 4f764244 <= mdb_entry_decode 4f764244 mdb_dn2entry("reqStart=20120330215514.000205Z,cn=accesslog") 4f764244 => mdb_dn2id("reqStart=20120330215514.000205Z,cn=accesslog") 4f764244 <= mdb_dn2id: got id=0x12d 4f764244 => mdb_entry_decode: 4f764244 <= mdb_entry_decode 4f764244 => access_allowed: delete access to "cn=accesslog" "children" requested 4f764244 <= root access granted 4f764244 => access_allowed: delete access granted by manage(=mwrscxd) 4f764244 => access_allowed: delete access to "reqStart=20120330215514.000205Z,cn=accesslog" "entry" requested 4f764244 <= root access granted 4f764244 => access_allowed: delete access granted by manage(=mwrscxd) 4f764244 => mdb_dn2id_delete 0x12d slapd: ./../../../libraries/libmdb/mdb.c:5136: mdb_node_move: Assertion `!((long)srcnode&1)' failed. Thread 6 (Thread 0x7fd7d82b6700 (LWP 32051)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565021419264, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x934f10, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda4bc010, ltk_data = 0x934f50, ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 448 hash = 3457894848 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 0x7fd7d8ab7700 (LWP 32050)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565029811968, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 336 hash = 1932182864 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7fd7d92b8700 (LWP 32049)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565038204672, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 545 hash = 1836313121 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 0x7fd7d9ab9700 (LWP 32048)): #0 0x00007ffff6372a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007ffff63765c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00007ffff140aedc in mdb_node_move (csrc=0x7fd7d9ab7890, cdst=0x7fd7d9ab7b30) at ./../../../libraries/libmdb/mdb.c:5136 rc = 0 srcnode = 0x661d8b9 key = {mv_size = 44, mv_data = 0x7fffda4bc0d0} data = {mv_size = 1, mv_data = 0x817c60} srcpg = 140737240913598 flags = 0 __PRETTY_FUNCTION__ = "mdb_node_move" #4 0x00007ffff140c8e7 in mdb_rebalance (mc=0x7fd7d9ab7b30) at ./../../../libraries/libmdb/mdb.c:5537 node = 0x661a502 rc = 0 ptop = 1 mn = {mc_next = 0x100000000, mc_orig = 0x700000008, mc_xcursor = 0x0, mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40, mc_dbflag = 0x800000008 <Address 0x800000008 out of bounds>, mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040, 0x661d070, 0x7fd7d9ab7920, 0x7ffff140fb9c, 0x7fd7d9ab7af0, 0x7fffda4bc0d0, 0x7fd7d9ab7b80, 0x400000004, 0x7fd7d9ab7b80, 0x7ffff1401865, 0x1d9ab99c0, 0x934a00, 0x78, 0x7fd7d9ab7bd0, 0x6613328, 0x84, 0x1, 0x1, 0x7fd7d9ab79b0, 0x1f14056be, 0x934d40, 0x7fd7d9ab7bd0, 0x6614ff0, 0x6614ff0, 0x6614ff0, 0x6613300, 0x7fd7d9ab7bb0, 0x7ffff1405cdf, 0x8, 0x1da52fff0, 0x661c8b8}, mc_ki = {1, 12, 30, 0, 20464, 1633, 0, 0, 49142, 1633, 0, 0, 49224, 1633, 0, 0, 48240, 1633, 0, 0, 984, 0, 0, 0, 18409, 63036, 32767, 0, 4, 0, 23, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #5 0x00007ffff140bf61 in mdb_page_merge (csrc=0x7fd7d9ab7b30, cdst=0x934b88) at ./../../../libraries/libmdb/mdb.c:5366 rc = 0 i = 12 j = 24 srcnode = 0x7febda5e4c28 key = {mv_size = 74, mv_data = 0x7febda5e4c30} data = {mv_size = 0, mv_data = 0x7febda5e4c7a} nkeys = 12 __PRETTY_FUNCTION__ = "mdb_page_merge" #6 0x00007ffff140c938 in mdb_rebalance (mc=0x934b88) at ./../../../libraries/libmdb/mdb.c:5541 node = 0x661bff6 rc = 0 ptop = 2 mn = {mc_next = 0x661c060, mc_orig = 0x7ffff140195a, mc_xcursor = 0x0, mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40, mc_dbflag = 0x6613328 "x\372\317", mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040, 0x661b050, 0x7febda5e4000, 0x300000000, 0x6613300, 0x6613300, 0x7fd7d9ab7d70, 0x7ffff1407bc7, 0x817c60, 0x934b88, 0x6618020, 0x0, 0x0, 0x6613300, 0x1, 0x6613398, 0x91bcb0, 0x6614f69, 0x1, 0x6614ff0, 0x7fd7d9ab7d70, 0x0, 0x0, 0x6613300, 0x1, 0x6613398, 0x91bcb0, 0x6614f69, 0x1, 0x6614ff0, 0x1}, mc_ki = {1, 13, 0, 0, 32208, 55723, 32727, 0, 53262, 1633, 0, 0, 53344, 1633, 0, 0, 52360, 1633, 0, 0, 984, 0, 0, 0, 18409, 63036, 32767, 0, 32056, 55723, 32727, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #7 0x00007ffff140caf0 in mdb_cursor_del0 (mc=0x934b88, leaf=0x661d00e) at ./../../../libraries/libmdb/mdb.c:5569 rc = 0 #8 0x00007ffff1409637 in mdb_cursor_del (mc=0x934b88, flags=0) at ./../../../libraries/libmdb/mdb.c:4524 leaf = 0x661d00e rc = 0 #9 0x00007ffff14094f8 in mdb_cursor_del (mc=0x934a00, flags=0) at ./../../../libraries/libmdb/mdb.c:4497 leaf = 0x6618f7c rc = 0 #10 0x00007ffff13f9c30 in mdb_dn2id_delete (op=0x7fd7d9ab8460, mc=0x934a00, id=301) at dn2id.c:220 rc = 0 #11 0x00007ffff13e938c in mdb_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0) at delete.c:336 mdb = 0x7ffff7e2c010 pdn = {bv_len = 12, bv_val = 0x937500 "cn=accesslog"} e = 0xeffce0 p = 0xeffb40 manageDSAit = 0 children = 0x7cfc20 entry = 0x7cf980 txn = 0x6613300 mc = 0x934a00 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7ffff7e2c010}, moi_txn = 0x6613300, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fd7d9ab7ef0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7fd7d9ab7f30, 0x800000, 0x7fd7d9ab99c0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #12 0x00000000004d4a48 in overlay_op_walk (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0, which=op_delete, oi=0x9a3d80, on=0x0) at backover.c:671 func = 0x7ffff1617d18 rc = 32768 #13 0x00000000004d4c86 in over_op_func (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0, which=op_delete) at backover.c:723 oi = 0x9a3d80 on = 0x8bca80 be = 0x8b75f0 db = {bd_info = 0x7ffff1617cc0, bd_self = 0x8b75f0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8bdcd0, be_nsuffix = 0x8b8390, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x8aab00 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8c4af0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a34a0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x91bc60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7ffff1617ac0, be_private = 0x7ffff7e2c010, be_next = {stqe_next = 0x8a7a80}} cb = {sc_next = 0x7ffff0fa1c60, sc_response = 0x4d3780 <over_back_response>, sc_cleanup = 0, sc_private = 0x9a3d80} sc = 0x823978 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #14 0x00000000004d4e6f in over_op_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0) at backover.c:780 No locals. #15 0x00007ffff0d97f61 in accesslog_purge (ctx=0x7fd7d9ab8b70, arg=0x8c4220) at accesslog.c:689 i = 0 rtask = 0x8c4220 li = 0x8c4110 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_listener = 0x501ca0, 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 = 0, 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 = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454a15 <slap_send_ldap_result>, c_send_search_entry = 0x45571d <slap_send_search_entry>, c_send_search_reference = 0x457c43 <slap_send_search_reference>, c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fd7d9ab85d0, o_tag = 74, o_time = 1333150209, o_tincr = 3, o_bd = 0x7fd7d9ab80e0, o_req_dn = {bv_len = 44, bv_val = 0x926990 "reqStart=20120330215514.000205Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0x9374e0 "reqStart=20120330215514.000205Z,cn=accesslog"}, o_request = { oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rb_ssf = 3651896336, rb_mech = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rs_nnewrdn = {bv_len = 140565046592528, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0xeffa98, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x75cd60, rs_filter = 0x7fd7d9ab8410, rs_filterstr = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7720288, bv_val = 0x7fd7d9ab8410 "\246"}, rs_new = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fd7d9ab8718, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x8aab00 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x8c4af0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0xeffa98, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fd7d9ab8ae0 "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}, o_private = 0x0, o_extra = {slh_first = 0x7fd7d9ab7ef0}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7fd7d9ab8820, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565046597376, oh_threadctx = 0x7fd7d9ab8b70, oh_tmpmemctx = 0x932e70, oh_tmpmfuncs = 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fd7d9ab8460 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x7ffff0d9787e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7fd7d9ab8380} f = {f_choice = 166, f_un = {f_un_result = -643070992, f_un_desc = 0x7fd7d9ab83f0, f_un_ava = 0x7fd7d9ab83f0, f_un_ssa = 0x7fd7d9ab83f0, f_un_mra = 0x7fd7d9ab83f0, f_un_complex = 0x7fd7d9ab83f0}, f_next = 0x0} ava = {aa_desc = 0x825a60, aa_value = {bv_len = 15, bv_val = 0x7fd7d9ab8b20 "20120330232509Z"}} pd = {slots = 699800, used = 699702, dn = 0x7fd7d43d0010, ndn = 0x7fd7d32eb010, csn = {bv_len = 40, bv_val = 0x7fd7d9ab8ae0 "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}} timebuf = "20120330232509Z\000\300\231\253\331\327\177" csnbuf = "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177", '\000' <repeats 11 times>"\227, \253\331\327\177\000" old = 1333149909 __PRETTY_FUNCTION__ = "accesslog_purge" #16 0x00007ffff7b8ccc9 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:688 pool = 0x7d4520 task = 0x9267e0 work_list = 0x7d45b8 ctx = {ltu_id = 140565046597376, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x932e70, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda4bc010, ltk_data = 0x933110, ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key = 0x7ffff13f23c4, ltk_data = 0x7fd7d54b4010, ltk_free = 0x7ffff13f23a1 <search_stack_free>}, { ltk_key = 0x7ffff13efda9, ltk_data = 0x7fd7d74b5010, ltk_free = 0x7ffff13efd61 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 433 hash = 310601137 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #18 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #19 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7fd7da2ba700 (LWP 32047)): #0 0x00007ffff6425d03 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x0000000000439597 in slapd_daemon_task (ptr=0x7fffffffe3bc) at daemon.c:2539 ns = 1 at = 0 nfds = 2 revents = 0x7ffff4b31010 tvp = 0x7fd7da2b7dc0 cat = {tv_sec = 1333150509, tv_usec = 0} i = 1 nwriters = 0 now = 1333150209 tv = {tv_sec = 300, tv_usec = 0} tdelta = 1 rtask = 0x8ab9c0 l = 1 last_idle_check = 1333150209 ebadf = 0 tid = 0 #2 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ffff7fef700 (LWP 32046)): #0 0x00007ffff66ca03d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e1ff in ldap_pvt_thread_join (thread=140565054990080, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043a7a9 in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 listener_tid = 0x926840 #3 0x0000000000416d4f in main (argc=11, argv=0x7fffffffe5c8) at main.c:1012 i = 11 no_detach = 1 rc = 0 urls = 0x7b10b0 "ldapi:///" username = 0x7b1090 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {3817984, 0} g_argc = 11 g_argv = 0x7fffffffe5c8 configfile = 0x0 configdir = 0x7b10d0 "/opt/zimbra/data/ldap/config" serverName = 0x7fffffffe871 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9828 "" l = 140737488348318 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by quanah＠zimbra.com 29 Mar '12

29 Mar '12

--On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------060203070300020608020002 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >> Laurent.LeGrandois(a)atos.net wrote: >>> This is a multi-part message in MIME format. >>> --------------070001090703090002060300 >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> Content-Transfer-Encoding: quoted-printable >>> >>> Hi, >>> >>> any news concerning integration of this patch ? >> An alternate patch is now in git master, please test. > Ok, we will test it : any modifications to do for 2.4.28 version ? Please respond once you've tested. Since there were changes to back-perl for 2.4.29, it may not apply cleanly to a 2.4.28 build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 29 Mar '12

29 Mar '12

Ondrej Kuznik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: >> ondrej.kuznik(a)acision.com wrote: >>> Full_Name: Ondrej Kuznik >>> Version: HEAD >>> OS: Linux >>> >> I have pushed patches 1-3 to git master. patch 4 seems to require additional work. > > I have reworked the remaining patches according to your suggestions, the > resulting patchset is at: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… Committed to master, thanks for the patches. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > - -- > Ondrej Kuznik > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5 > YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP > =8OdU > -----END PGP SIGNATURE----- > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net 29 Mar '12

29 Mar '12

This is a multi-part message in MIME format. --------------060203070300020608020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : > Laurent.LeGrandois(a)atos.net wrote: >> This is a multi-part message in MIME format. >> --------------070001090703090002060300 >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> Content-Transfer-Encoding: quoted-printable >> >> Hi, >> >> any news concerning integration of this patch ? > An alternate patch is now in git master, please test. Ok, we will test it : any modifications to do for 2.4.28 version ? Thanks >> Thanks >> >> Laurent Le Grandois >> >> >> Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =3DE9crit : >>> Now the new patch encode the binary data to base64 by using slap_ad_i= s_=3D >> binary to check if it's binary data, and using lutil_b64_ntop for the = enc=3D >> ode. > --=20 Cordialement, *Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>= * Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex Signature IOC <http://www.atos.net> --------------060203070300020608020002 Content-Type: multipart/related; boundary="------------050102040904060500010807" --------------050102040904060500010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Le 29/03/2012 15:14, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit : <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:Laurent.LeGrandois@atos.net">Laurent.LeGrandois(a)atos.net</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">This is a multi-part message in MIME format. --------------070001090703090002060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, any news concerning integration of this patch ? </pre> </blockquote> <pre wrap=""> An alternate patch is now in git master, please test.</pre> </blockquote> Ok, we will test it : any modifications to do for 2.4.28 version ? Thanks <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> Thanks Laurent Le Grandois Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a =E9crit : </pre> <blockquote type="cite"> <pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_= </pre> </blockquote> <pre wrap="">binary to check if it's binary data, and using lutil_b64_ntop for the enc= ode. </pre> <blockquote type="cite"> <pre wrap=""> </pre> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> <div class="moz-signature">-- <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-signature"> Cordialement, <img src="cid:part1.08050501.09040401@atos.net" border="0"> <a href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent Le Grandois</a> Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex <a href="http://www.atos.net"> <img src="cid:part3.07070802.03040503@atos.net" alt="Signature IOC" border="0"></a> </div> </div> </body> </html> --------------050102040904060500010807 Content-Type: image/gif; name="blue_strip.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.08050501.09040401(a)atos.net> Content-Disposition: inline; filename="blue_strip.gif" R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7 --------------050102040904060500010807 Content-Type: image/gif; name="atos_logo_small.gif" Content-Transfer-Encoding: base64 Content-ID: <part3.07070802.03040503(a)atos.net> Content-Disposition: inline; filename="atos_logo_small.gif" R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P 4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7 fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6 rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11 xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2 NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD 3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq 4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw qBchAAA7 --------------050102040904060500010807-- --------------060203070300020608020002--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs