- openldap-bugs - openldap.org

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon You're passing both -W and -w, which are mutually exclusive. p.

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org 01 Mar '11

01 Mar '11

----- Original Message ----- > --GRPZ8SYKNexpdSJ7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > > > re: TLS Authentication Identity Format > > > > Strictly speaking, the order of components is not changed at all. > > The sequence of RDNs in the DN is what it is; just that the > > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > > the wording here will confuse people into thinking that the > > *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. > > Andrew Thanks for all this Andrew, much appreciated! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com 01 Mar '11

01 Mar '11

Full_Name: plop Version: OS: ubuntu last release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.206.236.129) This is what I got on a CLI: ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' failed. Abandon $ ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools (LDAP library: OpenLDAP 20423) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ apt-cache show ldap-utils Package: ldap-utils Priority: optional Section: net Installed-Size: 768 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: amd64 Source: openldap Version: 2.4.23-0ubuntu3 Replaces: openldap-utils, openldapd, slapd (<< 2.2.23-0.pre6) Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.4), libgnutls26 (>= 2.7.14-0), libgssapi-krb5-2 (>= 1.6.dfsg.2), libldap-2.4-2 (= 2.4.23-0ubuntu3), libsasl2-2 Recommends: libsasl2-modules Conflicts: ldap-client, openldap-utils, umich-ldap-utils Filename: pool/main/o/openldap/ldap-utils_2.4.23-0ubuntu3_amd64.deb Size: 343860 MD5sum: 5c7834714c933288181d660e34c0b3d6 SHA1: a18afe09abd61bcf6a722135bb82c308104fa15c SHA256: 1b2d43b4dc82843047d6930f8e1f4145a8cf40f9435d9d58389c7acd1a4d4b04 Description-fr: Utilitaires OpenLDAP

1 0

Re: (ITS#6848) wait timeout for slapd startup
by hyc＠symas.com 01 Mar '11

01 Mar '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > >> When LDAP is used as a dependency for other software during the init process (as >> a kerberos backend, for example), the fact that slapd exits with success prior >> to it being ready to accept connections can cause problems for the later >> services that depend on it. It would be useful to have an (optional) flag "-w >> <seconds>" that if provided, would have slapd wait up until<seconds> amount of >> time has passed for the daemon to fully initialize. > > Some distros already deal with this in other ways - e.g. OpenSuSE waits > until an ldapsearch on the null DN succeeds. This is done in the init.d > script. This is still by far the best solution. The current patch simply shifts the slapd parent process' exit a little later, to after the databases are started up. The listener thread still has not yet been created by this time. On a lightly loaded system the time till that is running should be trivial, but on a heavily loaded system who knows. > One advantage of putting explicit support into OpenLDAP for this is > that it may be possible to have an option to delay starting the > listners on a replication consumer until a full refresh has been done > from the master (this would need a timeout option too). There are > obvious deadlock issues in multi-master configs, but admins would at > least have the option of using this on pure consumers. We've discussed this option many times in the past but it generally seems to come out being more bad than good. Also it implies an expectation for consistency that simply isn't offered by the syncrepl spec. Best to leave this alone for now. When we get to LDAP Transactions, and figuring out how to represent them in a syncrepl exchange, then it would be meaningful. -- -- 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#6848) wait timeout for slapd startup
by andrew.findlay＠skills-1st.co.uk 01 Mar '11

01 Mar '11

On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > When LDAP is used as a dependency for other software during the init process (as > a kerberos backend, for example), the fact that slapd exits with success prior > to it being ready to accept connections can cause problems for the later > services that depend on it. It would be useful to have an (optional) flag "-w > <seconds>" that if provided, would have slapd wait up until <seconds> amount of > time has passed for the daemon to fully initialize. Some distros already deal with this in other ways - e.g. OpenSuSE waits until an ldapsearch on the null DN succeeds. This is done in the init.d script. One advantage of putting explicit support into OpenLDAP for this is that it may be possible to have an option to delay starting the listners on a replication consumer until a full refresh has been done from the master (this would need a timeout option too). There are obvious deadlock issues in multi-master configs, but admins would at least have the option of using this on pure consumers. 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#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

Andrew Elble wrote: > Howard Chu<hyc(a)symas.com> writes: > >>> It would seem that attr_merge() (in attr.c) should have something like this: >>> >>> if ( *a == NULL ) { >>> *a = attr_alloc( desc ); >>> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { >>> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; >>> } >>> } else { >> >> This is now fixed in HEAD in value.c. > > Tested, bad behavior still persists. The call path I've observed > is as follows: > > T@5 : | | | | |>bdb_modify_internal > T@5 : | | | | | |>modify_add_values > T@5 : | | | | | | |>attr_merge > T@5 : | | | | | | | |>attr_alloc > > ordered_value_add() doesn't seem to be involved (I can provide the > entire trace if necessary) Thanks, my mistake. Fixed now in HEAD attr.c (redundant code removed from add.c) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6848) wait timeout for slapd startup
by quanah＠OpenLDAP.org 28 Feb '11

28 Feb '11

Full_Name: Quanah Gibson-Mount Version: 2.4.24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When LDAP is used as a dependency for other software during the init process (as a kerberos backend, for example), the fact that slapd exits with success prior to it being ready to accept connections can cause problems for the later services that depend on it. It would be useful to have an (optional) flag "-w <seconds>" that if provided, would have slapd wait up until <seconds> amount of time has passed for the daemon to fully initialize. If it fails to initialize and be ready to accept connections by the end of the time period (when specified), slapd should exit with a new unique error code. This would allow for avoiding the startup problem. An example of this (and a terrible solution) can be found in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589915 Debian implemented a broken solution for this, but it is a general issue for anyone who has dependencies on slapd being ready.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 28 Feb '11

28 Feb '11

> On 02/28/2011 04:57 AM, Howard Chu wrote: >> Right, no problem. I've run your updated script against HEAD and see no >> errors, nor is there a duplicate result sent for the Bind operation. > > That's a good datapoint. I'll look into building HEAD on my system and > validate that the duplicate result messages are gone. I was able to build HEAD pretty quickly (much quicker than I've been able to in the past :-) ), and was able to validate that the test succeeds. -Kartik

1 0

Re: (ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu 28 Feb '11

28 Feb '11

Howard Chu <hyc(a)symas.com> writes: >> It would seem that attr_merge() (in attr.c) should have something like this: >> >> if ( *a == NULL ) { >> *a = attr_alloc( desc ); >> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { >> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; >> } >> } else { > > This is now fixed in HEAD in value.c. Tested, bad behavior still persists. The call path I've observed is as follows: T@5 : | | | | | >bdb_modify_internal T@5 : | | | | | | >modify_add_values T@5 : | | | | | | | >attr_merge T@5 : | | | | | | | | >attr_alloc ordered_value_add() doesn't seem to be involved (I can provide the entire trace if necessary) >> Further pursuing the issue, I started to focus on the index deletion >> code that was changed as a part of ITS#5183. Specifically, the >> portion of code within bdb_modify_internal() (in back-bdb/modify.c) >> that is commented: >> >> /* Move deleted values to end of array */ >> >> This code modifies save_attrs, which is actually apparently a pointer >> to memory that resides within the cache. If a deadlock occurs, these >> changes are not reverted, thereby corrupting the entry in the cache. I >> replaced this code with the pre-ITS#5183 code and I am no longer able >> to 'break' the object and insert duplicate member/memberUids. > > This is now fixed in HEAD. Looks good, thanks. -- Andrew W. Elble aweits(a)discipline.rit.edu Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 28 Feb '11

28 Feb '11

On 02/28/2011 04:57 AM, Howard Chu wrote: > Kartik Subbarao wrote: >> I'd like to add one clarification to this message. I named the attached >> test script that illustrates the two RESULT messages problem >> test099-ppolicy-update, per Howard's previous advice not to duplicate >> existing names. But I just realized that this script relies on the same >> data files that I previously submitted (slapd-ppolicy.conf, >> ppolicy.ldif) so when running this script please ensure that those files >> are in place. > > Right, no problem. I've run your updated script against HEAD and see no > errors, nor is there a duplicate result sent for the Bind operation. That's a good datapoint. I'll look into building HEAD on my system and validate that the duplicate result messages are gone. Alternatively, is there an easy way for you to run the script against 2.4.23 on your side? If so, and if you can reproduce the error that I got with 2.4.23, that would be a solid confirmation that the bug has since been fixed. Don't worry about it though if it would be too much of a hassle -- I appreciate all your help with this. Thanks, -Kartik

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 28 Feb '11

28 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > When idassert-bind is configured to use SASL bind, an "authcID" needs to be > provided, while the "binddn" is not needed. However, if a "binddn" is not > provided as well, in some cases the proxiedAuthz control may be used > incorrectly. The need to configure the "binddn" is not documented, so this ITS > is minimally addressed by documenting this requirement. I tripped over this change while investigating #6711. Adding this requirement is certainly not the right solution; SASL Binds ordinarily don't require a BindDN and requiring it here just makes things confusing. Also with the fixes that I made for #6711 I don't believe the issue exists any more. Please describe the conditions where the problem occurs. > If the "binddn" is provided, everything works as expected, with the only minor > issue that the DN of the user as it is known to back-meta may not match the > actual identity the "authcID" assumed on the remote server. The "right" way to > address this problem consists in performing a "WhoAmI" (RFC 4532) right after > the bind, or better use a "authorization identity control" (RFC 3829) along with > the bind operation. Both approaches should be implemented, but they should not > be used unless explicitly requested. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Feb '11

28 Feb '11

Kartik Subbarao wrote: > I'd like to add one clarification to this message. I named the attached > test script that illustrates the two RESULT messages problem > test099-ppolicy-update, per Howard's previous advice not to duplicate > existing names. But I just realized that this script relies on the same > data files that I previously submitted (slapd-ppolicy.conf, > ppolicy.ldif) so when running this script please ensure that those files > are in place. Right, no problem. I've run your updated script against HEAD and see no errors, nor is there a duplicate result sent for the Bind operation. There's a config error because back-ldap in HEAD now always requires the binddn to be set in the idassert-bind directive. I have a feeling that this new requirement is bogus, and I just patched your script to set binddn="" to get around it for the moment. > Thanks, > > -Kartik > > On 02/02/2011 11:50 AM, Kartik Subbarao wrote: >>>> Another problem is that bind operations to the consumer server start to >> >> return two result messages -- one with the error code of the chained >> >> operation, and one with the error code of the bind operation. >> >> I'm continuing to see this problem, even after I fix the acl-bind and >> the 'manage' ACL configuration. See the attached for an updated test >> script that illustrates the problem -- I've added a bind with an >> incorrect password which should return 49, but instead is returning 0 to >> the client. >> >> The last line of output from the test script is: >> >> ldap bind operation returned 0, expected 49 >> >> For the relevant operation in slapd.2.log, I see the following: >> >> conn=1003 op=0 RESULT tag=103 err=0 text= >> [...] >> conn=1003 op=0 RESULT tag=97 err=49 text= >> >> slapd is returning two RESULT messages for the BIND operation. Error 0 >> seems to be from the successful chained modification of the >> pwdFailureTime attribute, and Error 49 seems to be for the incorrect >> password. >> >> -Kartik > > -- -- 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#6847) slapd segmentation fault
by Howard Chu 28 Feb '11

28 Feb '11

The information you provided is useless. Please read http://www.openldap.org/faq/data/cache/59.html

1 0

Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

aweits(a)rit.edu wrote: > Full_Name: Andrew Elble > Version: 2.4.24 / CVS Head > OS: Solaris / MacOS > URL: > Submission from: (NULL) (129.21.6.207) > Thanks for the detailed report. > > We are using sortvals on both member and memberUid. We have been > seeing duplicate member/memberUid attributes on some objects that have > been modified (as well as a lack of sorting on those attributes). It > seemed that there was a correlation between modifies to objects that > experienced deadlocks and the objects that had duplicate > member/memberUid attributes on them. We put the seqmod overlay in > place - and this reduced the number of occurrences of the issue but > did not eliminate them. > > Upon further investigation, I discovered that it was possible to > bypass the sorting behavior if the object was not created with an > instance of the attribute with sorting enabled as a part of it. > > It would seem that attr_merge() (in attr.c) should have something like this: > > if ( *a == NULL ) { > *a = attr_alloc( desc ); > if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { > (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; > } > } else { This is now fixed in HEAD in value.c. > Further pursuing the issue, I started to focus on the index deletion > code that was changed as a part of ITS#5183. Specifically, the > portion of code within bdb_modify_internal() (in back-bdb/modify.c) > that is commented: > > /* Move deleted values to end of array */ > > This code modifies save_attrs, which is actually apparently a pointer > to memory that resides within the cache. If a deadlock occurs, these > changes are not reverted, thereby corrupting the entry in the cache. I > replaced this code with the pre-ITS#5183 code and I am no longer able > to 'break' the object and insert duplicate member/memberUids. This is now fixed in HEAD. > I also found it surprising that the call to bdb_idl_cache_del() in > bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to > the database? I see what you mean. I don't think this causes any harm though. > I can answer any questions about the specifics of the environment > in which where we are seeing this - it is a somewhat difficult problem to > reproduce outside of our production environment. I'm not terribly > familiar with the code - I'm looking to see if I have collected enough > data here to open an ITS to have this fixed. (or if I'm just way off base) > > > Thanks, > > Andy > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6847) slapd segmentation fault
by dkastens＠uos.de 28 Feb '11

28 Feb '11

Full_Name: Dirk Kastens Version: 2.4.24 OS: Red Hat Enterprise Linux Server release 5.6 (kernel 2.6.18-238.1.1.el5xen) URL: Submission from: (NULL) (2001:638:508:3d0:74e8:28f7:184a:4cdf) I updated our openldap master and two replica servers to 2.4.24 (self-compiled) last week. Saturday morning, both replicas crashed at the same time with a segementation fault: kernel: slapd[2150]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 0000000042f9e630 error 4 kernel: slapd[9451]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 000000004563f630 error 4 Running slapd with valgrind --tool=memcheck --leak-check=full gives: ==31485== LEAK SUMMARY: ==31485== definitely lost: 0 bytes in 0 blocks ==31485== indirectly lost: 0 bytes in 0 blocks ==31485== possibly lost: 110,162 bytes in 4,698 blocks ==31485== still reachable: 6,942,591 bytes in 26,974 blocks ==31485== suppressed: 0 bytes in 0 blocks ==31485== Reachable blocks (those to which a pointer was found) are not shown. ==31485== To see them, rerun with: --leak-check=full --show-reachable=yes ==31485== ==31485== For counts of detected and suppressed errors, rerun with: -v ==31485== ERROR SUMMARY: 256 errors from 256 contexts (suppressed: 16 from 7) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (defined) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (noaccess) ==31485== Warning: invalid file descriptor -1 in syscall read()

1 0

(ITS#6846) Deadlock in back-meta
by jorge.perez.burgos＠ericsson.com 28 Feb '11

28 Feb '11

Full_Name: Jorge Perez Burgos Version: 2.4.15 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) There is a deadlock in back-meta code, the problem is that this thread get the lock two times, the first is the one that show the trace, but previous in the method meta_back_retry it has already the lock. (gdb) bt #0 0x00002b6e1a0706a8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b6e1a06c9fb in _L_mutex_lock_92 () from /lib64/libpthread.so.0 #2 0x00002b6e1a06c455 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004eb715 in meta_back_bind_op_result (op=0x2aab35d80020, rs=0x6eb6ad20, mc=0x2aab35e58be0, candidate=4, msgid=1, sendok=<value optimized out>) at bind.c:388 #4 0x00000000004eba9f in meta_back_proxy_authz_bind (mc=0x2aab35e58be0, candidate=4, op=0x2aab35d80020, rs=0x6eb6ad20, sendok=LDAP_BACK_SENDERR) at bind.c:1534 #5 0x00000000004ebc21 in meta_back_single_dobind (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR, nretries=276864893, dolock=0) at bind.c:600 #6 0x00000000004f3c4f in meta_back_retry (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR) at conn.c:721 #7 0x00000000004e9ffc in meta_back_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:184 #8 0x000000000044c196 in fe_op_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:334 #9 0x00000000004a4832 in overlay_op_walk (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add, oi=0x905850, on=0x0) at backover.c:669 #10 0x00000000004a4db5 in over_op_func (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add) at backover.c:721 #11 0x000000000044ca02 in do_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:194 #12 0x0000000000445bab in connection_operation (ctx=0x6eb6ae70, arg_v=<value optimized out>) at connection.c:1115 #13 0x0000000000446087 in connection_read_thread (ctx=0x6eb6ae70, argv=<value optimized out>) at connection.c:1241 #14 0x000000000052398a in ldap_int_thread_pool_wrapper (xpool=0x788e70) at tpool.c:663 #15 0x00002b6e1a06a193 in start_thread () from /lib64/libpthread.so.0 #16 0x00002b6e19814dfd in clone () from /lib64/libc.so.6

1 0

(ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu 25 Feb '11

25 Feb '11

Full_Name: Andrew Elble Version: 2.4.24 / CVS Head OS: Solaris / MacOS URL: Submission from: (NULL) (129.21.6.207) We are using sortvals on both member and memberUid. We have been seeing duplicate member/memberUid attributes on some objects that have been modified (as well as a lack of sorting on those attributes). It seemed that there was a correlation between modifies to objects that experienced deadlocks and the objects that had duplicate member/memberUid attributes on them. We put the seqmod overlay in place - and this reduced the number of occurrences of the issue but did not eliminate them. Upon further investigation, I discovered that it was possible to bypass the sorting behavior if the object was not created with an instance of the attribute with sorting enabled as a part of it. It would seem that attr_merge() (in attr.c) should have something like this: if ( *a == NULL ) { *a = attr_alloc( desc ); if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) { (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; } } else { Further pursuing the issue, I started to focus on the index deletion code that was changed as a part of ITS#5183. Specifically, the portion of code within bdb_modify_internal() (in back-bdb/modify.c) that is commented: /* Move deleted values to end of array */ This code modifies save_attrs, which is actually apparently a pointer to memory that resides within the cache. If a deadlock occurs, these changes are not reverted, thereby corrupting the entry in the cache. I replaced this code with the pre-ITS#5183 code and I am no longer able to 'break' the object and insert duplicate member/memberUids. I also found it surprising that the call to bdb_idl_cache_del() in bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to the database? I can answer any questions about the specifics of the environment in which where we are seeing this - it is a somewhat difficult problem to reproduce outside of our production environment. I'm not terribly familiar with the code - I'm looking to see if I have collected enough data here to open an ITS to have this fixed. (or if I'm just way off base) Thanks, Andy

1 0

(ITS#6844) AIX 6.1 | 7.1 not supported in "configure"
by joshua.taylor＠ubs.com 25 Feb '11

25 Feb '11

Full_Name: Joshua Taylor Version: 2.4.24 OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.134.254.26) the configure script has no support for aix6* or aix7*, resulting in assuming no shared libraries are supported. Simply going in after each reference to "aix5*" and adding, " | aix6* | aix7* " enables shared library support. Also, support for IA64 on aix is no more. I'm not even sure there was ever a version that *actually* ran on IA64 cpus.

1 0

Re: (ITS#6841) slapd segfault error 7
by quanah＠zimbra.com 24 Feb '11

24 Feb '11

--On Tuesday, February 22, 2011 10:54 AM +0000 tecnica(a)florasul.pt wrote: > This is the output from strace -o slapd strace is useless. Please have a core file generated, with debugging symbols, and send the full backtrace. Thanks, 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

2.4.23 / Debian 6.0 i386: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd
by David Touzeau 24 Feb '11

24 Feb '11

Dear We have an problem using $OpenLDAP: slapd 2.4.23 (Nov 22 2010 23:39:34) $#012#011@biber:/build/buildd-openldap_2.4.23-7-i386-mi96UQ/openldap-2.4.23/debian/build/servers/slapd The same issue has been be replicated on 2.4.24 When we analyze the debug logs, the crash is performed each time we see this line : is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute How can we prevent this crash or fix it ? here it is a piece of logs that detect the crash. Feb 22 14:50:21 pm02 slapd[12126]: >>> dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: <<< dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>, <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: oc_check_required entry (cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com), objectClass "ArticaHostName" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "objectClass" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "cn" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "structuralObjectClass" Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute Feb 22 14:50:21 pm02 kernel: [13697.801217] slapd[13777]: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd[8048000+11b000] best regards

2 1

(ITS#6843) Can't slapadd cn=config LDIF with global chaining overlay
by rhafer＠suse.de 24 Feb '11

24 Feb '11

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.251.8) slapadd-ing the following LDIF (a stripped down slapcat output) fails: ------------------------- dn: cn=config objectClass: olcGlobal cn: config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcChainDatabase objectClass: olcLDAPConfig olcDatabase: {0}ldap dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config --------------------------------------- The error message is: slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=20): Already exists The problem is the olcChainDatabase Entry. As it appears before the config-database entry config_tool_entry_put() will autocreate an olcDatabase={0}config,cn=config and after that choke up when trying to add the olcDatabase={0}config,cn=config that appears later in the LDIF file. I have a fix for this mostly ready. (Just skipping autocreation of the config-Database if child-entries of the frontendDatabase are added)

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 02:02:17PM +0000, hyc(a)symas.com wrote: > > A URI-based restriction specification could include/exclude based on > > suffix, filter and listed attributes with a unified syntax. > > Yes... But what does the filter *mean* in > a modify op? filter on the target entry before it was modified, or after? Hmm - I was thinking of matching on the *modified attributes* (just their presence, not taking account of value). However, I can see that pre- and post-conditions might matter so: logrecord <operations> prefilter|changefilter|postfilter <LDAP URL> logignore <operations> prefilter|changefilter|postfilter <LDAP URL> ... > a search op? match the search request's filter, or filter on the search base? Both if present. Again, I might restrict the filter to matching on the presence of attributes in the filter rather than their actual value. > a compare op? Whatever works for search should be very close. 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#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 05:25:28AM -0800, Howard Chu wrote: > >Extending this idea slightly, would it be possible to have > >exclusions based on changes to specific attributes? The > >particular case I have in mind is where accesslog is used to > >keep a permanent audit log of changes, and ppolicy is also > >in use, resulting in one audit entry for every login > >failure. I have one site where a large proportion of the auditlog > >entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods > to be internal-only and bypass the accesslog overlay. (Currently it > does this already, if the server is a single-master replica.) There are all sorts of problems to do with ppolicy and replication... Bypassing accesslog is an interesting idea, but I can see that people who use n-failure-lockout might want the lockout events to be auditable. I wonder if there might be some benefit to giving such control on a per-operation basis. Then ppolicy might be configurable to have some automatic ops logged and others not. It could also be the start of a way to make ppolicy actions rather more global across a replication group (e.g. by putting in the ability to queue some ops for replication back to a master server). > So far you're talking about two different enhancements - the > original poster is trying to exclude a set of searches, and you're > talking about excluding modify ops. I'm not seeing any way yet to > generalize from here such that all operation types are addressed > meaningfully, and I don't want to introduce multiple special cases > to the config language. Rather than logbase <operations> <baseDN> how about logfilter <operations> <LDAP URL> where the whole clause may be repeated as many times as needed? The LDAP URL can then specify a search base, a filter, and a list of attributes of interest. Extending this to support both inclusion and exclusion clauses might be harder, as you would then need some way to give them an order of precedence. The case I mentioned before would need a rule of the form 'dont log this op if the only change concerns the atttribute pwdFailureTime'. Perhaps a simple list of rules: logrecord <operations> <LDAP URL> logignore <operations> <LDAP URL> ... and if anything is left at the end of the list then it gets logged. The filters would determine whether a log entry would be made at all, and the attribute lists would determine the content. 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#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 23 Feb '11

23 Feb '11

Hi! Thanx for your reply. We have been able to reproduce the problem on a test system and found out that setting "idletimeout" seems to fix this issue for us. Note that we enabled gentlehup! We have now the new configuration on our production environment and everything seems stable. We are not able to change solaris versions. If there are still problems we will upgrade the openldap version. On another system we have the same ldap configuration (gentlehup and no idletimeout set) and do not experience any problem. Best regards, Thomas -------- Original-Nachricht -------- > Datum: Wed, 23 Feb 2011 02:26:01 GMT > Von: hyc(a)symas.com > An: openldap-its(a)openldap.org > Betreff: Re: (ITS#6833) LDAP hangs on Solaris > tombolala(a)gmx.de wrote: > > Hi Quanah! > > > > sorry for the wrong release, I meant 2.4.22 of course. > > I recall we also experienced hangs with Solaris 10 during the testing > leading > up to the 2.4.24 release. Yet with identical code, no such hangs were > reported > on Solaris 9 or Solaris 11. I suspect there's a bug in the implementation > of > select() on Solaris 10, causing it to fail to report the connection close > events. > > Some discussion of this problem occurred in this email thread > > http://www.openldap.org/lists/openldap-devel/201101/msg00033.html > > Try 2.4.24, and try a different Solaris release. Aside from that, we have > no > answers for you. > > > /Thomas > > > > -------- Original-Nachricht -------- > >> Datum: Wed, 16 Feb 2011 16:34:39 GMT > >> Von: quanah(a)zimbra.com > >> An: openldap-its(a)openldap.org > >> Betreff: Re: (ITS#6833) LDAP hangs on Solaris > > > >> --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de > wrote: > >> > >>> Full_Name: Thomas Bopp > >>> Version: 4.2.22 > >> > >>> I really need a solution for this problem. > >> > >> I suggest you list an actual OpenLDAP release. It's near impossible to > >> help you without that. > >> > >> --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 > >> > >> > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

masarati(a)aero.polimi.it wrote: > hyc(a)symas.com wrote: >> Andrew Findlay wrote: >>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: >>> >>>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>>> to simplify this case. >>> Extending this idea slightly, would it be possible to have >>> exclusions based on changes to specific attributes? The >>> particular case I have in mind is where accesslog is used to >>> keep a permanent audit log of changes, and ppolicy is also >>> in use, resulting in one audit entry for every login >>> failure. I have one site where a large proportion of the auditlog >>> entries are login failures... >> >> Perhaps in that case, it would be simpler just to set ppolicy's mods to be >> internal-only and bypass the accesslog overlay. (Currently it does this >> already, if the server is a single-master replica.) >> >> So far you're talking about two different enhancements - the original poster >> is trying to exclude a set of searches, and you're talking about excluding >> modify ops. I'm not seeing any way yet to generalize from here such that all >> operation types are addressed meaningfully, and I don't want to introduce >> multiple special cases to the config language. > > A URI-based restriction specification could include/exclude based on > suffix, filter and listed attributes with a unified syntax. Yes... But what does the filter *mean* in a modify op? filter on the target entry before it was modified, or after? a search op? match the search request's filter, or filter on the search base? a compare op? -- -- 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#6815) Feature Request: Accesslog filter
by masarati＠aero.polimi.it 23 Feb '11

23 Feb '11

hyc(a)symas.com wrote: > Andrew Findlay wrote: >> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: >> >>> Possibly we can extend the directive to handle exclusion as well as inclusion, >>> to simplify this case. >> Extending this idea slightly, would it be possible to have >> exclusions based on changes to specific attributes? The >> particular case I have in mind is where accesslog is used to >> keep a permanent audit log of changes, and ppolicy is also >> in use, resulting in one audit entry for every login >> failure. I have one site where a large proportion of the auditlog >> entries are login failures... > > Perhaps in that case, it would be simpler just to set ppolicy's mods to be > internal-only and bypass the accesslog overlay. (Currently it does this > already, if the server is a single-master replica.) > > So far you're talking about two different enhancements - the original poster > is trying to exclude a set of searches, and you're talking about excluding > modify ops. I'm not seeing any way yet to generalize from here such that all > operation types are addressed meaningfully, and I don't want to introduce > multiple special cases to the config language. A URI-based restriction specification could include/exclude based on suffix, filter and listed attributes with a unified syntax. p.

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

Andrew Findlay wrote: > On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: > >> Possibly we can extend the directive to handle exclusion as well as inclusion, >> to simplify this case. > > Extending this idea slightly, would it be possible to have > exclusions based on changes to specific attributes? The > particular case I have in mind is where accesslog is used to > keep a permanent audit log of changes, and ppolicy is also > in use, resulting in one audit entry for every login > failure. I have one site where a large proportion of the auditlog > entries are login failures... Perhaps in that case, it would be simpler just to set ppolicy's mods to be internal-only and bypass the accesslog overlay. (Currently it does this already, if the server is a single-master replica.) So far you're talking about two different enhancements - the original poster is trying to exclude a set of searches, and you're talking about excluding modify ops. I'm not seeing any way yet to generalize from here such that all operation types are addressed meaningfully, and I don't want to introduce multiple special cases to the config language. -- -- 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#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote: > Possibly we can extend the directive to handle exclusion as well as inclusion, > to simplify this case. Extending this idea slightly, would it be possible to have exclusions based on changes to specific attributes? The particular case I have in mind is where accesslog is used to keep a permanent audit log of changes, and ppolicy is also in use, resulting in one audit entry for every login failure. I have one site where a large proportion of the auditlog entries are login failures... 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#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 23 Feb '11

23 Feb '11

--0016363b8528ec55d3049cef5b03 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc(a)symas.com> wrote: > Marco Pizzoli wrote: > >> Hi Howard, >> thanks for this work. >> >> I noticed that you give me a baseDN under which I can have operations >> logged. >> If I would like to exclude one subtree from my principal tree, I need to >> specify all the baseDN of other sibling-subtrees. >> To do this do I need to poli-invoke accesslog overlay? >> > > No, you can specify logbase multiple times in a single overlay. > Ok, thanks. > Possibly we can extend the directive to handle exclusion as well as > inclusion, to simplify this case. > This is effectively what I would need, in this case. --0016363b8528ec55d3049cef5b03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu = <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&gt= ; wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0= pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;= "> <div class=3D"im">Marco Pizzoli wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logge= d. If I would like to exclude one subtree from my principal tree, I need to<br= > specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? </blockquote> </div> No, you can specify logbase multiple times in a single overlay. </blockq= uote><div> Ok, thanks. =A0</div><blockquote class=3D"gmail_quote"= style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 2= 04); padding-left: 1ex;"> Possibly we can extend the directive to handle exclusion as well as inclusi= on, to simplify this case. </blockquote><div> This is effectively wha= t I would need, in this case. </div></div> --0016363b8528ec55d3049cef5b03--

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com 23 Feb '11

23 Feb '11

Marco Pizzoli wrote: > Hi Howard, > thanks for this work. > > I noticed that you give me a baseDN under which I can have operations logged. > If I would like to exclude one subtree from my principal tree, I need to > specify all the baseDN of other sibling-subtrees. > To do this do I need to poli-invoke accesslog overlay? No, you can specify logbase multiple times in a single overlay. Possibly we can extend the directive to handle exclusion as well as inclusion, to simplify this case. > > Thanks again > Marco > > On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > marco.pizzoli(a)gmail.com <mailto:marco.pizzoli@gmail.com> wrote: > > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations > that match > some sort of filter, or, in particular, to not to log searches that > matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every > 30seconds do > a dummy ldap search only to keep alive their connection to the ldap > server. > These searches are frequent and I have many of these clients in my > deploy, so my > accesslog become full of not significant entries. > > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > _________________________________________ > Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. > Jim Morrison -- -- 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#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 23 Feb '11

23 Feb '11

--0016363b85287ec3a0049cef245f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, thanks for this work. I noticed that you give me a baseDN under which I can have operations logged. If I would like to exclude one subtree from my principal tree, I need to specify all the baseDN of other sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? Thanks again Marco On Wed, Feb 23, 2011 at 3:15 AM, Howard Chu <hyc(a)symas.com> wrote: > marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: ALL >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.41.84.11) >> >> >> Hi, >> this is a feature request. >> >> I would like to have accesslog writing to his db only ldap operations th= at >> match >> some sort of filter, or, in particular, to not to log searches that >> matches a >> specific pattern. >> >> This request is spotted by some ldap clients that I have that every >> 30seconds do >> a dummy ldap search only to keep alive their connection to the ldap >> server. >> These searches are frequent and I have many of these clients in my deplo= y, >> so my >> accesslog become full of not significant entries. >> > > I've added a simple subtree-matching feature to accesslog in HEAD. Please > test and let us know if it addresses this request. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016363b85287ec3a0049cef245f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, thanks for this work. I noticed that you give me a bas= eDN under which I can have operations logged. If I would like to exclude= one subtree from my principal tree, I need to specify all the baseDN of ot= her sibling-subtrees. To do this do I need to poli-invoke accesslog overlay? Thanks again<= br>Marco <div class=3D"gmail_quote">On Wed, Feb 23, 2011 at 3:15 AM,= Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc@syma= s.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><a href=3D"mailto= :marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli(a)gmail.com</a> wro= te: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Full_Name: Marco Pizzoli Version: ALL OS: URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (193.41.84.11) Hi, this is a feature request. I would like to have accesslog writing to his db only ldap operations that = match some sort of filter, or, in particular, to not to log searches that matches= a specific pattern. This request is spotted by some ldap clients that I have that every 30secon= ds do a dummy ldap search only to keep alive their connection to the ldap server.= These searches are frequent and I have many of these clients in my deploy, = so my accesslog become full of not significant entries. </blockquote> I've added a simple subtree-matching feature to accesslog in HEAD. Plea= se test and let us know if it addresses this request. -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- ________________= _________________________ Non =E8 forte chi non cade, ma chi cadendo ha = la forza di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morri= son --0016363b85287ec3a0049cef245f--

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by hyc＠symas.com 22 Feb '11

22 Feb '11

Andrew Findlay wrote: > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > >> re: TLS Authentication Identity Format >> >> Strictly speaking, the order of components is not changed at all. >> The sequence of RDNs in the DN is what it is; just that the >> convention for *displaying* it is ass-backwards in LDAP. I'm afraid >> the wording here will confuse people into thinking that the >> *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. Thanks, applied with formatting tweaks. > > Andrew > > > sasl-x509-dn-doc.patch > > > --- sasl.sdf.head 2011-02-18 23:03:07.000000000 +0000 > +++ sasl.sdf 2011-02-22 14:30:25.947887979 +0000 > @@ -1,4 +1,4 @@ > -# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.51 2011/02/18 23:03:07 hyc Exp $ > +# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.34.2.12 2011/01/04 23:49:40 kurt Exp $ > # Copyright 1999-2011 The OpenLDAP Foundation, All Rights Reserved. > # COPYING RESTRICTIONS APPLY, see COPYRIGHT. > > @@ -302,9 +302,9 @@ > > H4: TLS Authentication Identity Format > > -This is usually the Subject DN from the client-side certificate. > -The order of the components will be changed to follow LDAP conventions, > -so a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} > +This is the Subject DN from the client-side certificate. > +Note that DNs are displayed differently by LDAP and by X.509, so > +a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} > will produce an authentication identity of: > > > cn=A Person,o=The Example Organisation,c=gb -- -- 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#6833) LDAP hangs on Solaris
by hyc＠symas.com 22 Feb '11

22 Feb '11

tombolala(a)gmx.de wrote: > Hi Quanah! > > sorry for the wrong release, I meant 2.4.22 of course. I recall we also experienced hangs with Solaris 10 during the testing leading up to the 2.4.24 release. Yet with identical code, no such hangs were reported on Solaris 9 or Solaris 11. I suspect there's a bug in the implementation of select() on Solaris 10, causing it to fail to report the connection close events. Some discussion of this problem occurred in this email thread http://www.openldap.org/lists/openldap-devel/201101/msg00033.html Try 2.4.24, and try a different Solaris release. Aside from that, we have no answers for you. > /Thomas > > -------- Original-Nachricht -------- >> Datum: Wed, 16 Feb 2011 16:34:39 GMT >> Von: quanah(a)zimbra.com >> An: openldap-its(a)openldap.org >> Betreff: Re: (ITS#6833) LDAP hangs on Solaris > >> --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: >> >>> Full_Name: Thomas Bopp >>> Version: 4.2.22 >> >>> I really need a solution for this problem. >> >> I suggest you list an actual OpenLDAP release. It's near impossible to >> help you without that. >> >> --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 >> >> > -- -- 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#6815) Feature Request: Accesslog filter
by hyc＠symas.com 22 Feb '11

22 Feb '11

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: ALL > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > this is a feature request. > > I would like to have accesslog writing to his db only ldap operations that match > some sort of filter, or, in particular, to not to log searches that matches a > specific pattern. > > This request is spotted by some ldap clients that I have that every 30seconds do > a dummy ldap search only to keep alive their connection to the ldap server. > These searches are frequent and I have many of these clients in my deploy, so my > accesslog become full of not significant entries. I've added a simple subtree-matching feature to accesslog in HEAD. Please test and let us know if it addresses this request. -- -- 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#6841) slapd segfault error 7
by masarati＠aero.polimi.it 22 Feb '11

22 Feb '11

> Full_Name: André Bolinhas > Version: 2.4.24 > OS: ubuntu 10.4 x86 > URL: > Submission from: (NULL) (217.129.0.33) > > > Dear, > > My ldap crash every 2 minutes, I get this error on syslog > > kernel: [35483.930213] slapd[3892]: segfault at 8127238 ip 080c6fcc sp > b60ffb00 > error 7 in slapd[8048000+123000] > > How can help to solve this problem ? Usage help requests should be directed to openldap-technical mailing list. The ITS is for bug tracking. I infer you didn't read the instructions from the fact that you clicked the "Major Security Issue?" for ITS#6840). This ITS will be closed. p.

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by andrew.findlay＠skills-1st.co.uk 22 Feb '11

22 Feb '11

--GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > re: TLS Authentication Identity Format > > Strictly speaking, the order of components is not changed at all. > The sequence of RDNs in the DN is what it is; just that the > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > the wording here will confuse people into thinking that the > *semantics* of the DN are changed, when it's only a display issue. Good point. Updated wording attached. 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 | ----------------------------------------------------------------------- --GRPZ8SYKNexpdSJ7 Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="sasl-x509-dn-doc.patch" --- sasl.sdf.head 2011-02-18 23:03:07.000000000 +0000 +++ sasl.sdf 2011-02-22 14:30:25.947887979 +0000 @@ -1,4 +1,4 @@ -# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.51 2011/02/18 23:03:07 hyc Exp $ +# $OpenLDAP: pkg/openldap-guide/admin/sasl.sdf,v 1.34.2.12 2011/01/04 23:49:40 kurt Exp $ # Copyright 1999-2011 The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. @@ -302,9 +302,9 @@ H4: TLS Authentication Identity Format -This is usually the Subject DN from the client-side certificate. -The order of the components will be changed to follow LDAP conventions, -so a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} +This is the Subject DN from the client-side certificate. +Note that DNs are displayed differently by LDAP and by X.509, so +a certificate issued to {{EX:C=gb, O=The Example Organisation, CN=A Person}} will produce an authentication identity of: > cn=A Person,o=The Example Organisation,c=gb --GRPZ8SYKNexpdSJ7--

1 0

Re: (ITS#6841) slapd segfault error 7
by tecnica＠florasul.pt 22 Feb '11

22 Feb '11

This is the output from strace -o slapd execve("/usr/sbin/slapd", ["slapd"], [/* 18 vars */]) = 0 brk(0) = 0x88b6000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7795000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7789000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libldap_r-2.4.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\274\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=982577, ...}) = 0 mmap2(NULL, 285892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7743000 mprotect(0xb7785000, 4096, PROT_NONE) = 0 mmap2(0xb7786000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42) = 0xb7786000 mmap2(0xb7788000, 3268, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7788000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/liblber-2.4.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300*\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=143488, ...}) = 0 mmap2(NULL, 49716, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7736000 mmap2(0xb7741000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0xb7741000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\20\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=14000, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7735000 mmap2(NULL, 16592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7730000 mmap2(0xb7733000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7733000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.6.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@}\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1230912, ...}) = 0 mmap2(NULL, 1234236, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7602000 mmap2(0xb772d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0xb772d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 J\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=117086, ...}) = 0 mmap2(NULL, 98792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75e9000 mmap2(0xb75fe000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb75fe000 mmap2(0xb7600000, 4584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7600000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libiodbc.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300M\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=305108, ...}) = 0 mmap2(NULL, 308068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb759d000 mmap2(0xb75e6000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x48) = 0xb75e6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libslp.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P.\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=59008, ...}) = 0 mmap2(NULL, 61888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb758d000 mmap2(0xb759b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd) = 0xb759b000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2201\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=79676, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb758c000 mmap2(NULL, 92136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7575000 mmap2(0xb7588000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7588000 mmap2(0xb758a000, 6120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb758a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libsasl2.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3602\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=91892, ...}) = 0 mmap2(NULL, 94764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb755d000 mmap2(0xb7573000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15) = 0xb7573000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libgnutls.so.26", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\334\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=629248, ...}) = 0 mmap2(NULL, 632024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb74c2000 mmap2(0xb7558000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x95) = 0xb7558000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\7\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=38360, ...}) = 0 mmap2(NULL, 201052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7490000 mmap2(0xb7499000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8) = 0xb7499000 mmap2(0xb749b000, 155996, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb749b000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000&\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=71432, ...}) = 0 mmap2(NULL, 79944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb747c000 mmap2(0xb748c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10) = 0xb748c000 mmap2(0xb748e000, 6216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb748e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libltdl.so.7", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\32\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=30168, ...}) = 0 mmap2(NULL, 32988, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7473000 mmap2(0xb747a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb747a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9736, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7472000 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb746e000 mmap2(0xb7470000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7470000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libwrap.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\"\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=31020, ...}) = 0 mmap2(NULL, 35868, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7465000 mmap2(0xb746c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb746c000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0 mmap2(NULL, 1415592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb730b000 mprotect(0xb745e000, 4096, PROT_NONE) = 0 mmap2(0xb745f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0xb745f000 mmap2(0xb7462000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7462000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libtasn1.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\21\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=62936, ...}) = 0 mmap2(NULL, 66180, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb72fa000 mmap2(0xb7309000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe) = 0xb7309000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\31\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=79512, ...}) = 0 mmap2(NULL, 82188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb72e5000 mmap2(0xb72f8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb72f8000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libgcrypt.so.11", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340M\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=470976, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb72e4000 mmap2(NULL, 470348, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7271000 mmap2(0xb72e1000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x70) = 0xb72e1000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libgpg-error.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\6\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=13604, ...}) = 0 mmap2(NULL, 16432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb726c000 mmap2(0xb726f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb726f000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb726b000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb726a000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb726a700, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb726f000, 4096, PROT_READ) = 0 mprotect(0xb72e1000, 4096, PROT_READ) = 0 mprotect(0xb72f8000, 4096, PROT_READ) = 0 mprotect(0xb7309000, 4096, PROT_READ) = 0 mprotect(0xb745f000, 8192, PROT_READ) = 0 mprotect(0xb746c000, 4096, PROT_READ) = 0 mprotect(0xb7470000, 4096, PROT_READ) = 0 mprotect(0xb747a000, 4096, PROT_READ) = 0 mprotect(0xb748c000, 4096, PROT_READ) = 0 mprotect(0xb7499000, 4096, PROT_READ) = 0 mprotect(0xb7558000, 16384, PROT_READ) = 0 mprotect(0xb7573000, 4096, PROT_READ) = 0 mprotect(0xb7588000, 4096, PROT_READ) = 0 mprotect(0xb759b000, 4096, PROT_READ) = 0 mprotect(0xb75e6000, 4096, PROT_READ) = 0 mprotect(0xb75fe000, 4096, PROT_READ) = 0 mprotect(0xb772d000, 8192, PROT_READ) = 0 mprotect(0xb7733000, 4096, PROT_READ) = 0 mprotect(0xb7741000, 4096, PROT_READ) = 0 mprotect(0xb7786000, 4096, PROT_READ) = 0 mprotect(0x816b000, 4096, PROT_READ) = 0 mprotect(0xb77b3000, 4096, PROT_READ) = 0 munmap(0xb7789000, 45329) = 0 set_tid_address(0xb726a768) = 13593 set_robust_list(0xb726a770, 0xc) = 0 futex(0xbfc2c7f0, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0xbfc2c7f0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, bfc2c800) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0xb75ed410, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb75ed8f0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 brk(0) = 0x88b6000 brk(0x88d7000) = 0x88d7000 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 open("/etc/resolv.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "search evora01.florasul.lan\nname"..., 4096) = 80 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=475, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 475 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7789000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \32\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=42572, ...}) = 0 mmap2(NULL, 45772, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb725e000 mmap2(0xb7268000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9) = 0xb7268000 close(3) = 0 mprotect(0xb7268000, 4096, PROT_READ) = 0 munmap(0xb7789000, 45329) = 0 open("/etc/host.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=92, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "# The \"order\" line is only used "..., 4096) = 92 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb7463b44, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat64(3, {st_mode=S_IFREG|0644, st_size=4050, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "192.168.2.103\tpm02.evora01.flora"..., 4096) = 4050 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=245, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(3, "#\n# LDAP Defaults\n#\n\n# See ldap."..., 4096) = 245 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7794000, 4096) = 0 geteuid32() = 0 getuid32() = 0 open("/root/ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/root/.ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0 time(NULL) = 1298368862 open("/etc/localtime", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=3439, ...}) = 0 fstat64(4, {st_mode=S_IFREG|0644, st_size=3439, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\v\0\0\0\v\0\0\0\0"..., 4096) = 3439 _llseek(4, -27, [3412], SEEK_CUR) = 0 read(4, "\nWET0WEST,M3.5.0/1,M10.5.0\n", 4096) = 27 close(4) = 0 munmap(0xb7794000, 4096) = 0 send(3, "<167>Feb 22 10:01:02 slapd[13593"..., 184, MSG_NOSIGNAL) = 184 uname({sys="Linux", node="webmail.e.florasul.pt", ...}) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 open("/etc/resolv.conf", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=80, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "search evora01.florasul.lan\nname"..., 4096) = 80 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7794000, 4096) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=4050, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(4, "192.168.2.103\tpm02.evora01.flora"..., 4096) = 4050 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7794000, 4096) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 pipe([4, 5]) = 0 fcntl64(5, F_GETFL) = 0x1 (flags O_WRONLY) fcntl64(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 epoll_create(1024) = 6 socket(PF_NETLINK, SOCK_RAW, 0) = 7 bind(7, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(7, {sa_family=AF_NETLINK, pid=13593, groups=00000000}, [12]) = 0 time(NULL) = 1298368862 sendto(7, "\24\0\0\0\26\0\1\3^\211cM\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0^\211cM\0315\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0^\211cM\0315\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0^\211cM\0315\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(7) = 0 open("/etc/gai.conf", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=2987, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=2987, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(7, "# Configuration for getaddrinfo("..., 4096) = 2987 read(7, "", 4096) = 0 close(7) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb7462cf0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 7 connect(7, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 getsockname(7, {sa_family=AF_INET6, sin6_port=htons(48150), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 connect(7, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 connect(7, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(7, {sa_family=AF_INET6, sin6_port=htons(37782), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 close(7) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(7, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 8 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(8, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 bind(8, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 brk(0x88f8000) = 0x88f8000 getuid32() = 0 geteuid32() = 0 getgid32() = 0 getegid32() = 0 open("/etc/sasl/slapd.conf", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/sasl2/slapd.conf", O_RDONLY) = -1 ENOENT (No such file or directory) getuid32() = 0 geteuid32() = 0 getgid32() = 0 getegid32() = 0 open("/usr/lib/sasl2", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 9 fcntl64(9, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(9, /* 45 entries */, 32768) = 1212 open("/usr/lib/sasl2/libldapdb.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libdigestmd5.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libcrammd5.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=976, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7794000 read(10, "# libcrammd5.la - a libtool libr"..., 4096) = 976 close(10) = 0 munmap(0xb7794000, 4096) = 0 futex(0xb747106c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/usr/lib/sasl2/libcrammd5.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17764, ...}) = 0 mmap2(NULL, 20640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb778f000 mmap2(0xb7793000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb7793000 close(10) = 0 mprotect(0xb7793000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libldapdb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=983, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb778e000 read(10, "# libldapdb.la - a libtool libra"..., 4096) = 983 close(10) = 0 munmap(0xb778e000, 4096) = 0 open("/usr/lib/sasl2/libldapdb.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\20\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17648, ...}) = 0 mmap2(NULL, 20528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7789000 mmap2(0xb778d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb778d000 close(10) = 0 mprotect(0xb778d000, 4096, PROT_READ) = 0 time(NULL) = 1298368862 send(3, "<35>Feb 22 10:01:02 slapd[13593]"..., 79, MSG_NOSIGNAL) = 79 time(NULL) = 1298368862 send(3, "<39>Feb 22 10:01:02 slapd[13593]"..., 104, MSG_NOSIGNAL) = 104 open("/usr/lib/sasl2/libntlm.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libcrammd5.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libplain.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=970, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb725d000 read(10, "# libplain.la - a libtool librar"..., 4096) = 970 close(10) = 0 munmap(0xb725d000, 4096) = 0 open("/usr/lib/sasl2/libplain.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=17760, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7259000 mmap2(0xb725c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x3) = 0xb725c000 close(10) = 0 mprotect(0xb725c000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libsasldb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1001, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7258000 read(10, "# libsasldb.la - a libtool libra"..., 4096) = 1001 close(10) = 0 munmap(0xb7258000, 4096) = 0 open("/usr/lib/sasl2/libsasldb.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\17\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=21736, ...}) = 0 mmap2(NULL, 24620, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7252000 mmap2(0xb7257000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x4) = 0xb7257000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb7246000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.8.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320L\1\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1439772, ...}) = 0 mmap2(NULL, 1442512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70e5000 mmap2(0xb7243000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x15d) = 0xb7243000 close(10) = 0 mprotect(0xb7243000, 8192, PROT_READ) = 0 mprotect(0xb7257000, 4096, PROT_READ) = 0 munmap(0xb7246000, 45329) = 0 open("/usr/lib/sasl2/liblogin.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libanonymous.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libplain.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/liblogin.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=970, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7251000 read(10, "# liblogin.la - a libtool librar"..., 4096) = 970 close(10) = 0 munmap(0xb7251000, 4096) = 0 open("/usr/lib/sasl2/liblogin.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=13664, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb724d000 mmap2(0xb7250000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2) = 0xb7250000 close(10) = 0 mprotect(0xb7250000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libanonymous.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=990, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb724c000 read(10, "# libanonymous.la - a libtool li"..., 4096) = 990 close(10) = 0 munmap(0xb724c000, 4096) = 0 open("/usr/lib/sasl2/libanonymous.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\f\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=13668, ...}) = 0 mmap2(NULL, 16544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb7248000 mmap2(0xb724b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2) = 0xb724b000 close(10) = 0 mprotect(0xb724b000, 4096, PROT_READ) = 0 open("/usr/lib/sasl2/libsasldb.la", O_RDONLY) = 10 close(10) = 0 open("/usr/lib/sasl2/libdigestmd5.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=999, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(10, "# libdigestmd5.la - a libtool li"..., 4096) = 999 close(10) = 0 munmap(0xb7247000, 4096) = 0 open("/usr/lib/sasl2/libdigestmd5.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\21\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=46712, ...}) = 0 mmap2(NULL, 49544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70d8000 mmap2(0xb70e3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0xa) = 0xb70e3000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb70cc000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libcrypto.so.0.9.8", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\334\3\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1364764, ...}) = 0 mmap2(NULL, 1380472, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6f7a000 mmap2(0xb70b2000, 90112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x137) = 0xb70b2000 mmap2(0xb70c8000, 12408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb70c8000 close(10) = 0 mprotect(0xb70b2000, 32768, PROT_READ) = 0 mprotect(0xb70e3000, 4096, PROT_READ) = 0 munmap(0xb70cc000, 45329) = 0 open("/usr/lib/sasl2/libntlm.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=964, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(10, "# libntlm.la - a libtool library"..., 4096) = 964 close(10) = 0 munmap(0xb7247000, 4096) = 0 open("/usr/lib/sasl2/libntlm.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\21\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=30048, ...}) = 0 mmap2(NULL, 32928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb70cf000 mmap2(0xb70d6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x6) = 0xb70d6000 close(10) = 0 mprotect(0xb70d6000, 4096, PROT_READ) = 0 getdents(9, /* 0 entries */, 32768) = 0 close(9) = 0 stat64("/etc/ldap/slapd.d", 0xbfc2b020) = -1 ENOENT (No such file or directory) stat64("/etc/ldap/slapd.conf", {st_mode=S_IFREG|0644, st_size=2787, ...}) = 0 open("/etc/ldap/slapd.conf", O_RDONLY|O_LARGEFILE) = 9 fstat64(9, {st_mode=S_IFREG|0644, st_size=2787, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(9, "pidfile /var/run/slapd/s"..., 4096) = 2787 stat64("/etc/ldap/schema/core.schema", {st_mode=S_IFREG|0777, st_size=20346, ...}) = 0 open("/etc/ldap/schema/core.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=20346, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# OpenLDAP Core schema\n# $OpenLD"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.44{64} )\n\natt"..., 4096) = 4096 read(10, "C2256: supported application con"..., 4096) = 4096 read(10, "schema\n#objectclass ( 2.5.6.0 NA"..., 4096) = 4096 read(10, "Certificate )\n\nobjectclass ( 2.5"..., 4096) = 3962 brk(0x8919000) = 0x8919000 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/cosine.schema", {st_mode=S_IFREG|0777, st_size=14030, ...}) = 0 open("/etc/ldap/schema/cosine.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=14030, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# RFC1274: Cosine and Internet X"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.15{256} )\n\nat"..., 4096) = 4096 read(10, "1.1.15 )\n\nattributetype ( 0.9.23"..., 4096) = 4096 read(10, "$\n\t\tphysicalDeliveryOfficeName $"..., 4096) = 1742 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/mod_vhost_ldap.schema", {st_mode=S_IFREG|0777, st_size=2100, ...}) = 0 open("/etc/ldap/schema/mod_vhost_ldap.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=2100, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "##\n## OIDs are owned by Globe In"..., 4096) = 2100 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/nis.schema", {st_mode=S_IFREG|0777, st_size=7723, ...}) = 0 open("/etc/ldap/schema/nis.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=7723, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# $OpenLDAP: pkg/ldap/servers/sl"..., 4096) = 4096 read(10, "etype ( 1.3.6.1.1.1.1.18 NAME 'o"..., 4096) = 3627 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/inetorgperson.schema", {st_mode=S_IFREG|0777, st_size=6360, ...}) = 0 open("/etc/ldap/schema/inetorgperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=6360, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# inetorgperson.schema -- InetOr"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.15\n\tSINGLE-VA"..., 4096) = 2264 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/evolutionperson.schema", {st_mode=S_IFREG|0777, st_size=6659, ...}) = 0 open("/etc/ldap/schema/evolutionperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=6659, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# Depends upon\n# Definition "..., 4096) = 4096 read(10, "6.1.2.23\n\tNAME 'categories'\n\tEQU"..., 4096) = 2563 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/postfix.schema", {st_mode=S_IFREG|0777, st_size=142898, ...}) = 0 open("/etc/ldap/schema/postfix.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=142898, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# Extensions to support Postfix "..., 4096) = 4096 read(10, "butetype (1.1.2.1.1.10.1.21 NAME"..., 4096) = 4096 read(10, "Recipient'\n DESC 'Antivirus n"..., 4096) = 4096 read(10, ".3.6.1.4.1.1466.115.121.1.26 SIN"..., 4096) = 4096 read(10, "onf'\n EQUALITY caseIgnoreIA5M"..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, ".4.1.1466.115.121.1.26 SINGLE-VA"..., 4096) = 4096 read(10, "-------\nattributetype (1.1.2.1.1"..., 4096) = 4096 read(10, "caseIgnoreIA5Match\n SYNTAX 1."..., 4096) = 4096 read(10, "EQUALITY caseIgnoreIA5Match\n "..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 brk(0x893a000) = 0x893a000 read(10, "--------------------------------"..., 4096) = 4096 read(10, "-------------------------\nattrib"..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, "ALITY caseIgnoreIA5Match\n SYN"..., 4096) = 4096 read(10, "NTAX 1.3.6.1.4.1.1466.115.121.1."..., 4096) = 4096 read(10, "--------------------------------"..., 4096) = 4096 read(10, ".1.26 SINGLE-VALUE)\n#-----------"..., 4096) = 4096 read(10, "E-VALUE)\n#----------------------"..., 4096) = 4096 read(10, "sDay'\n DESC 'How long the log"..., 4096) = 4096 read(10, "d the squid settings'\n# EQUAL"..., 4096) = 4096 read(10, "1.1.10.1.346 NAME 'AlternateSmtp"..., 4096) = 4096 read(10, "attributetype (1.1.2.1.1.10.1.36"..., 4096) = 4096 read(10, "4.1.1466.115.121.1.7\n SINGLE-VA"..., 4096) = 4096 read(10, "---------------------\n\n\n#deleted"..., 4096) = 4096 read(10, "assList $ PostFixRestrictionClas"..., 4096) = 4096 read(10, "n distributions lists'\n\tSUP top\n"..., 4096) = 4096 read(10, "SC 'DansGuardian Master configur"..., 4096) = 4096 read(10, "inAccount $ ClamavMilterEnabled "..., 4096) = 4096 read(10, "ternet $ \n\tAlternateSmtpRelay $ "..., 4096) = 4096 read(10, "Infos'\n \tDESC 'Postfix smtp_s"..., 4096) = 4096 brk(0x895b000) = 0x895b000 read(10, "count'\n DESC 'master user Obj"..., 4096) = 4096 read(10, " ( 1.3.6.1.4.1.15312.2.2.1.21\n "..., 4096) = 4096 read(10, "ain'\n DESC 'OBM domain for th"..., 4096) = 4096 read(10, "69.1.1.1.6\n NAME 'myDesti"..., 4096) = 3634 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dhcp.schema", {st_mode=S_IFREG|0777, st_size=21482, ...}) = 0 open("/etc/ldap/schema/dhcp.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=21482, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 2.16.840.1.11371"..., 4096) = 4096 read(10, "N' \n\tEQUALITY distinguishedNameM"..., 4096) = 4096 read(10, "r) to this name.' \n\tSYNTAX 1.3.6"..., 4096) = 4096 read(10, "EQUALITY distinguishedNameMatch "..., 4096) = 4096 read(10, "ements $ dhcpComments $ dhcpOpti"..., 4096) = 4096 read(10, "13719.1.203.6.15 \n\tNAME 'dhcpFai"..., 4096) = 1002 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/samba.schema", {st_mode=S_IFREG|0777, st_size=19424, ...}) = 0 open("/etc/ldap/schema/samba.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=19424, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "##\n## schema file for OpenLDAP 2"..., 4096) = 4096 read(10, "ributetype ( 1.3.6.1.4.1.7165.2."..., 4096) = 4096 read(10, "4.1.7165.2.1.32 NAME 'sambaKicko"..., 4096) = 4096 read(10, "1.42 NAME 'sambaOptionName'\n\tDES"..., 4096) = 4096 read(10, "ds\n## compatibility with 2.2 ins"..., 4096) = 3040 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/ISPEnv.schema", {st_mode=S_IFREG|0777, st_size=1443, ...}) = 0 open("/etc/ldap/schema/ISPEnv.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1443, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.1104"..., 4096) = 1443 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/mozilla-thunderbird.schema", {st_mode=S_IFREG|0777, st_size=3380, ...}) = 0 open("/etc/ldap/schema/mozilla-thunderbird.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=3380, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# mozillaOrgPerson schema v. 0"..., 4096) = 3380 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/officeperson.schema", {st_mode=S_IFREG|0777, st_size=1029, ...}) = 0 open("/etc/ldap/schema/officeperson.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1029, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.4203"..., 4096) = 1029 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/pureftpd.schema", {st_mode=S_IFREG|0777, st_size=2548, ...}) = 0 open("/etc/ldap/schema/pureftpd.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=2548, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# pureftpd.schema\n#\n# Pure-FTP"..., 4096) = 2548 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/joomla.schema", {st_mode=S_IFREG|0777, st_size=1348, ...}) = 0 open("/etc/ldap/schema/joomla.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=1348, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# Joomla Group Attribute; free f"..., 4096) = 1348 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/autofs.schema", {st_mode=S_IFREG|0777, st_size=830, ...}) = 0 open("/etc/ldap/schema/autofs.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=830, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "#\n# $id$\n#\n# Depends upon core.s"..., 4096) = 830 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dnsdomain2.schema", {st_mode=S_IFREG|0777, st_size=4044, ...}) = 0 open("/etc/ldap/schema/dnsdomain2.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=4044, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# A schema for storing DNS zones"..., 4096) = 4044 read(10, "", 4096) = 0 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/zarafa.schema", {st_mode=S_IFREG|0777, st_size=7268, ...}) = 0 open("/etc/ldap/schema/zarafa.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0777, st_size=7268, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "attributetype ( 1.3.6.1.4.1.2627"..., 4096) = 4096 brk(0x897c000) = 0x897c000 read(10, ".4.1.1466.115.121.1.15\n\t)\n\nattri"..., 4096) = 3172 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 stat64("/etc/ldap/schema/dyngroup.schema", {st_mode=S_IFREG|0444, st_size=3376, ...}) = 0 open("/etc/ldap/schema/dyngroup.schema", O_RDONLY|O_LARGEFILE) = 10 fstat64(10, {st_mode=S_IFREG|0444, st_size=3376, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# dyngroup.schema -- Dynamic Gro"..., 4096) = 3376 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 open("/usr/lib/ldap/back_hdb.la", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1106, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7246000 read(10, "# back_hdb.la - a libtool librar"..., 4096) = 1106 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb7246000, 4096) = 0 open("/usr/lib/ldap/back_hdb-2.4.so.2", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 J\0\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=186696, ...}) = 0 mmap2(NULL, 239408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6f3f000 mmap2(0xb6f6c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x2c) = 0xb6f6c000 mmap2(0xb6f6e000, 46896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f6e000 close(10) = 0 open("/etc/ld.so.cache", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=45329, ...}) = 0 mmap2(NULL, 45329, PROT_READ, MAP_PRIVATE, 10, 0) = 0xb6f33000 close(10) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.7.so", O_RDONLY) = 10 read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\204\1\0004\0\0\0"..., 512) = 512 fstat64(10, {st_mode=S_IFREG|0644, st_size=1386564, ...}) = 0 mmap2(NULL, 1389884, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb6ddf000 mmap2(0xb6f30000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x150) = 0xb6f30000 close(10) = 0 mprotect(0xb6f30000, 8192, PROT_READ) = 0 mprotect(0xb6f6c000, 4096, PROT_READ) = 0 munmap(0xb6f33000, 45329) = 0 open("/var/lib/ldap/DUMMY", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 10 close(10) = 0 unlink("/var/lib/ldap/DUMMY") = 0 open("/var/lib/ldap/DB_CONFIG", O_RDONLY|O_LARGEFILE) = 10 close(10) = 0 time(NULL) = 1298368863 read(9, "", 4096) = 0 read(9, "", 4096) = 0 close(9) = 0 munmap(0xb7247000, 4096) = 0 access("/etc/gcrypt/fips_enabled", F_OK) = -1 ENOENT (No such file or directory) open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 9 fstat64(9, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7247000 read(9, "0\n", 1024) = 2 close(9) = 0 munmap(0xb7247000, 4096) = 0 brk(0x899d000) = 0x899d000 access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 time(NULL) = 1298368863 open("/dev/urandom", O_RDONLY) = 9 fcntl64(9, F_GETFD) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999998}) read(9, "V\355n\346\250\277C\236\242\22\216\376\207\213\315#\220\177\300\200X\302\26097F-y\347V\33@"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\\hu\244\247j5^\374\5\250\316\227`F_\nU\302\244d\365\246\267\266\276\312\350\330%\tP"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\371\350I=\343\17_\222b\\\177U\236\341\256\333\212\215DP;\375|\366\7y4\257d\343\343="..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "7\307\214\372Ll\213\270\270\267\202\256c,\256\260\337(\\\210\202\234\313\267|Q/-\315\356\33\325"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\270\275\236\343\347O\226o\342gi\305i\300\3464?~\v\347\271\34\271\264\177\222\245u%&\222\7"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\372%\231\247i\222\\\6D\267\265mc\02159u\334P(\\~P\f\266\256\213\255\3267\3037"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "=u\216J|\267cm\345\356L\312\17`\215\304\227\220W\24\315}\315\227_-\245.tg{\366"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\256\r\323\304\233\362\34\334]w\232T\226\341|Ms\240G\261\361\374\364\v\256\304\260J\232fvQ"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\36%\300\25\340\210\231HP\304\300\227\6dm\270\33\22\367J\251\303(\231d\235ku\330\307\245["..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "k\244\242\6,!\0306\fZ\356\321\263s\35\17v,\350d\335_;\263d\265\343X-jcn"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\n\35\200Q:\226\22\226\33\340\322f\216`\350\210\316\277\4y\272\206uQ5#\342@\326B\236$"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\363\302E\334\357\355;\272\325\205MN_\261oX\216\26kpr\350s\302J0n\341\326\365J*"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\rY\301\t\34\334\200\275u\316\31\234\242b\336\246\264p\203>\261yq\2333\27\203/t\355\254\224"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "g\227[\233s%\34wI\245HE\3\347\200\32\364\20QF\4l7\7oD\240_\243j\0055"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\351o\341\235\247\375.\333\325\374\337\265\352\330\\\36\365\241\200\201\233 Z'g\304\312\326\222!\333\345"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\320\334\21\35\377s\353o\2745\313\200\263\305\253em\331dp\377e\267\323\26\32\202\211\7\262g\37"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\320\toN\301\312@;T\206\326\321s\321\244\244\216\341\350p\216=\277_$\26\331;K2\275\342"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\234\230\20686 \245i<\31~N\"ylw\262\307r6B\vg\243d\226\215E7\233\260u"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "1B\"%?J\343\6\206?\263\372\363 \316l\3059\36\251\2016\360\374[\225\236\35\321\313?_"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\323\6\325\222g\353\177\363\3725\250\271e\3309\235u\30\226\200\304\214\23\v\331m\23~N\205\245\346"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\252\f@\337\6\377\341\377\254 \212\253\216*\3244}I\261\257\352UV4%\30z\350\260\375\332\201"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\24\340jX\354(\257\236\363\275\217\341caE\376\n\307\253A\361\17\357\222{\0064\f\322\\@3"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "\276\237\35\256\211z\203z\241\205\365\234\363\374\344T%\362\34\327iq5U\224\323\271Y\277\235n\220"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "~)\"\357\21$\222W\314\270\221\311\245\275\253N\351\341(\260\1W?\5\210-n\311\10\3\230f"..., 120) = 120 select(10, [9], NULL, NULL, {3, 0}) = 1 (in [9], left {2, 999999}) read(9, "Ilo\36\377i\v\rd\244\253j\2354\274\227\351\311D\31\201\305\\@\263\367\10\202Q\3750\305"..., 120) = 120 gettimeofday({1298368863, 23980}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 24001}, ru_stime={0, 8000}, ...}) = 0 time(NULL) = 1298368863 times({tms_utime=2, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1724596866 gettimeofday({1298368863, 24186}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 24001}, ru_stime={0, 8000}, ...}) = 0 time(NULL) = 1298368863 times({tms_utime=2, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1724596866 rt_sigaction(SIGUSR1, {0x8072800, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGUSR2, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGHUP, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTRAP, {0x8072840, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGCHLD, {0x805d190, [], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb726a768) = 13602 exit_group(0) = ?

1 0

(ITS#6841) slapd segfault error 7
by andre.bolinhas＠hotmail.com 21 Feb '11

21 Feb '11

Full_Name: André Bolinhas Version: 2.4.24 OS: ubuntu 10.4 x86 URL: Submission from: (NULL) (217.129.0.33) Dear, My ldap crash every 2 minutes, I get this error on syslog kernel: [35483.930213] slapd[3892]: segfault at 8127238 ip 080c6fcc sp b60ffb00 error 7 in slapd[8048000+123000] How can help to solve this problem ? Best regards André Bolinhas

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began working again), the following entries popped up in the log: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get the following error on the CLI (and this is with a successful bind as the directory admin): ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid No such object (32) Matched DN: dc=example,dc=com Debugging logs generated by that query can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t…

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began working again), the following entries popped up in the log: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get the following error on the CLI (and this is with a successful bind as the directory admin): ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid No such object (32) Matched DN: dc=example,dc=com Debugging logs generated by that query can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t…

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Additionally, today I found myself in a situation where reversing the order of *just* the objectClasses in the filter - i.e., from (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) to (&(|(objectClass=bar)(objectClass=foo))(uid=jdoe1)) - didn't fix things, but changing the search base (from ou=Users,dc=example,dc=com to dc=example,dc=com) did. I was then able to issue the original search with searchbase ou=Users,dc=example,dc=com and filter (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) and it worked fine.

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

Additionally, today I found myself in a situation where reversing the order of *just* the objectClasses in the filter - i.e., from (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) to (&(|(objectClass=bar)(objectClass=foo))(uid=jdoe1)) - didn't fix things, but changing the search base (from ou=Users,dc=example,dc=com to dc=example,dc=com) did. I was then able to issue the original search with searchbase ou=Users,dc=example,dc=com and filter (&(|(objectClass=foo)(objectClass=bar))(uid=jdoe1)) and it worked fine. Strange...

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 21 Feb '11

21 Feb '11

I just uploaded two log file snippets for consideration (also posted to ITS#6831, since there has not been a formal merge or acceptance of the two being one and the same). One is a failed query to the proxycache database exhibiting this problem, and the other is a successful query to the same proxycache database. A gzipp'ed tarball can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-logs-for-comp…. For reference, the queries issued and results for each were: ## Failed query ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid ## Successful query ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 The cache reported both to be "ANSWERABLE" before attempting to retrieve the data. Up until the point where the unsuccessful query fails to read the key for the UID equality candidate, both the failed query and the successful query lock the same exact QC index (0x7f50429860f0), attempt to fetch the exact same keys ([b49d1940], [807e234d], [8f951c4a]), and compare the exact same equality/filter/list candidates ("id=9, first=2699, last=2731"). This is what I would expect, since the values for the two objectClasses in the search filter are the same. However, once it gets to the point where it compares the bdb_equality_candidates for the UID, the values of the bdb_filter_candidates, bdb_equality_candidates, and bdb_list_candidates in logs for the unsuccessful query are a little confusing: ## UID portion of unsuccessful query Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:02:00 blog2 slapd[18797]: EQUALITY Feb 21 10:02:00 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:02:00 blog2 slapd[18797]: => key_read Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [efb8b856] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=0, first=0, last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: bdb_search_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: hdb_search: no candidates ## UID portion of successful query Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:06:22 blog2 slapd[18797]: EQUALITY Feb 21 10:06:22 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:06:22 blog2 slapd[18797]: => key_read Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [ea38ed84] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 1 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=1, first=2701, last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: bdb_search_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: => test_filter I gather that a value of "0" for id/first/last is normal when it cannot find the index in question (as it does for the UID value that it had deemed to be answerable), but the "first=2" and "first=2699" values seem a little strange, especially since the "first=2699" value supposedly matches the bdb_equality_candidates "first" value found at one of the indices searched for the objectClass attribute(s). I have no idea where the value "2" comes from, but it too seems incorrect if it couldn't find the index. Perhaps those values make more sense in the context of it thinking it could find the values, but then ultimately not being able to (though I admit that sounds like a pretty big stretch). Unfortunately, I don't understand enough about what's going here, or where things might be going awry in the codebase, to abstract something more meaningful from these logs, but hopefully this provides a little bit of framing/contextual information to someone else that does. Cheers

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

I just uploaded two log file snippets for consideration. One is a failed query to the proxycache database exhibiting this problem, and the other is a successful query to the proxycache database. A gzipp'ed tarball can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-logs-for-comp…. Up until the point where the unsuccessful query fails to read the key for the UID equality candidate, both the failed query and the successful query are locking the same exact QC index (0x7f50429860f0), trying to fetch the exact same keys ([b49d1940], [807e234d], [8f951c4a]), and comparing the same equality/filter/list candidates ("id=9, first=2699, last=2731"). This is what I would expect, since the values for the two objectClasses in the search filter are the same. However, once it gets to the point where it compares the bdb_equality_candidates for the UID, the values of the bdb_filter_candidates, bdb_equality_candidates, and bdb_list_candidates in logs for the unsuccessful query are a little confusing. I gather that a value of "0" for id/first/last is normal when it cannot find the index in question (as it does for the UID value that it said was "ANSWERABLE" but was unable to find), but the "first=2" and "first=2699" values seem a little strange, especially since the "first=2699" value supposedly matches the bdb_equality_candidates value found at one of the indices for the objectClass searches. I have no idea where the value "2" comes from, but it too seems out of place if it couldn't find the index. Perhaps those values make more sense in the context where it thought it *could* find the values, but then wasn't able to (though I admit that sounds like a pretty big stretch). ## UID portion of unsuccessful query Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:02:00 blog2 slapd[18797]: EQUALITY Feb 21 10:02:00 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:02:00 blog2 slapd[18797]: => key_read Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [efb8b856] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=0, first=0, last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: bdb_search_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: hdb_search: no candidates ## UID portion of successful query Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:06:22 blog2 slapd[18797]: EQUALITY Feb 21 10:06:22 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:06:22 blog2 slapd[18797]: => key_read Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [ea38ed84] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 1 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=1, first=2701, last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: bdb_search_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: => test_filter I unfortunately don't have enough knowledge about what's going here, or where things go awry in the codebase, to abstract something more meaningful from these logs, but hopefully this provides a little bit of framing/contextual information to someone else that does.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 18 Feb '11

18 Feb '11

masarati(a)aero.polimi.it wrote: > >> The cleanest solution would probably be to make olcChainDatabase >> structural, >> copying all of the attributes of olcLDAPConfig into it, and dropping >> olcLDAPConfig itself from this situation. Too bad changing that now would >> break existing deployments. > >> From a protocol point of view, olcChainDatabase could be derived from > olcLDAPConfig; at this point the two could coexist in existing > deployments. back-config could take care of objectClass inheritance while > selecting configuration tables. back-config already uses inheritance to order the objectClasses. But I think it may be happening too late to address this. Still looking, probably a simple fix in that case. -- -- 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#6837) slapd doesn't start anymore after adding olcChainDatabase
by masarati＠aero.polimi.it 18 Feb '11

18 Feb '11

> The cleanest solution would probably be to make olcChainDatabase > structural, > copying all of the attributes of olcLDAPConfig into it, and dropping > olcLDAPConfig itself from this situation. Too bad changing that now would > break existing deployments. >From a protocol point of view, olcChainDatabase could be derived from olcLDAPConfig; at this point the two could coexist in existing deployments. back-config could take care of objectClass inheritance while selecting configuration tables. p.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 18 Feb '11

18 Feb '11

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.243.151) > > > After adding the following LDIF to cn=config (via ldapadd), slapd does not start > anymore: > ------------------------------------ > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcChainConfig > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcLDAPConfig > objectclass: olcChainDatabase > olcDbUri: ldap://ldap.server > olcDatbase: {0}ldap > ------------------------------------ > > To add some fun. Everything works as expected if I reorder the "objectClass" > Values so that "olcLDAPConfig" appears after "olcChainDatabase". > > Additionally the error messages I get in the log when slapd fails to start with > the above config seem to be completely unrelated: > ------ > olcRootPW: value #0:<olcRootPW> can only be set when rootdn is under suffix > config error processing olcDatabase={0}config,cn=config:<olcRootPW> can only be > set when rootdn is under suffix > ------ > > The underlying problem seems to be that, when the "olcLDAPConfig" objectclass > appears first slapd seems to choose the wrong ConfigTable for the olcDatabase > attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as > defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the > LDAP Database as if it were in "normal" database, including adding it to the > backendDB list. As I configured the chain overlay as a global overlay this > back-ldap database is put to the front of the backendDB list leading to problems > when initializing the cn=config database itself, because the code assumes that > the config database is always the first one, which will than lead to the strange > error message above. > > (... that's how far I got with analyzing the problem, I have no idea yet how to > fix it though. Suggestions are welcome.) > The cleanest solution would probably be to make olcChainDatabase structural, copying all of the attributes of olcLDAPConfig into it, and dropping olcLDAPConfig itself from this situation. Too bad changing that now would break existing deployments. I'll look into this some more. -- -- 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#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by hyc＠symas.com 18 Feb '11

18 Feb '11

Andrew Findlay wrote: > On Thu, Feb 17, 2011 at 04:21:35PM -0800, Howard Chu wrote: > >>> URL: ftp://ftp.openldap.org/incoming/afindlay-slapi-doc-patch-20110217a > >> This patch fails to apply to HEAD. Please re-read the contributing >> guidelines; all patches must be against HEAD. > > It applies perfectly to the copy of HEAD that I downloaded this > morning: Strange. Must have had some end-of-line issues here. re: TLS Authentication Identity Format Strictly speaking, the order of components is not changed at all. The sequence of RDNs in the DN is what it is; just that the convention for *displaying* it is ass-backwards in LDAP. I'm afraid the wording here will confuse people into thinking that the *semantics* of the DN are changed, when it's only a display issue. > andrew@slab:~/src/openldap-head> cvs -z3 checkout -P -rHEAD openldap > ... much logging deleted ... > andrew@slab:~/src/openldap-head> cd openldap > andrew@slab:~/src/openldap-head/openldap> patch -b -p0< ../afindlay-slapi-doc-patch-20110217a > patching file doc/man/man8/slapd.8 > patching file doc/guide/admin/runningslapd.sdf > patching file doc/guide/admin/sasl.sdf > patching file doc/guide/preamble.sdf > > Andrew -- -- 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#6838) TLS client will not accept certificate for 'localhost'
by Kurt＠OpenLDAP.org 18 Feb '11

18 Feb '11

And, for the OP, I suggest issuing your test certificates for the FQDN = "test" and then setting up name service to resolve this to local host. = Using "test" indicates that the scope of name is limited to some = infrastructure used for testing (and is not a name used on the public = Internet). -- Kurt=

1 0

Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
by Kurt＠OpenLDAP.org 18 Feb '11

18 Feb '11

On Feb 18, 2011, at 9:37 AM, hyc(a)symas.com wrote: > Closing this ITS. It's not a regression and not a bug, just a long = established=20 > feature. Right, the bug is listing non-fully-qualified names as subjects in the = certificate. So, generally speaking, subject names checks fail, as they should fail, = when the asserted name is not fully-qualified. The intent of the code is avoid always failing when the = non-fully-qualified asserted name can be securely transformed into a = fully-qualified name. This is a feature. -- Kurt=

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs