- openldap-bugs - openldap.org

(ITS#6946) ldapexop: ber_free_buf: Assertion failed
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110519-ldapexop-double-free.patch Submission from: (NULL) (209.132.186.34) Hello. A problem with crashing ldapexop was reported to our bugzilla. All versions since 2.4.24 are affected. It seems that the bug was introduced by following change in ldapexop.c. http://www.openldap.org/devel/cvsweb.cgi/clients/tools/ldapexop.c.diff?r1=1… Easy to reproduce. With clean configuration run: $ ldapexop -H ldap:// -x whoami anonymous ldapexop: ../../../libraries/liblber/io.c:186: ber_free_buf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Aborted Complete steps to reproduce in Fedora are specified in the original bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=699683 I think it is cause by double freeing the result. I am attaching a proposed patch. Please, review my change. Thank you. Jan

1 0

(ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by bgmilne＠staff.telkomsa.net 19 May '11

19 May '11

Full_Name: Buchan Milne Version: 2.4.25 OS: Red Hat Enterprise Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.124.16) I am aware that these are old, and almost (or already) EOL distributions, but nssov does not build on RHEL3 and RHEL4. On RHEL3, I get: + make -C contrib/slapd-modules/nssov libdir=/usr/lib moduledir=/usr/lib/openldap2.4 make: Entering directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ../../../libtool --mode=compile gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c mkdir .libs gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c -fPIC -DPIC -o .libs/alias.o In file included from ../../../include/ldap_pvt_thread.h:21, from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_int_thread.h:69: syntax error before "ldap_int_thread_rdwr_t" ../../../include/ldap_int_thread.h:69: warning: data definition has no type or storage class In file included from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_pvt_thread.h:36: syntax error before "ldap_pvt_thread_rdwr_t" ../../../include/ldap_pvt_thread.h:36: warning: data definition has no type or storage class ../../../include/ldap_pvt_thread.h:154: syntax error before '*' token ../../../include/ldap_pvt_thread.h:157: syntax error before '*' token ../../../include/ldap_pvt_thread.h:160: syntax error before '*' token ../../../include/ldap_pvt_thread.h:163: syntax error before '*' token ../../../include/ldap_pvt_thread.h:166: syntax error before '*' token ../../../include/ldap_pvt_thread.h:169: syntax error before '*' token ../../../include/ldap_pvt_thread.h:172: syntax error before '*' token ../../../include/ldap_pvt_thread.h:175: syntax error before '*' token ../../../include/ldap_pvt_thread.h:191: syntax error before '*' token ../../../include/ldap_pvt_thread.h:194: syntax error before '*' token ../../../include/ldap_pvt_thread.h:197: syntax error before '*' token make: *** [alias.lo] Error 1 make: Leaving directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ldap_int_thread.h:69 #if defined( HAVE_PTHREAD_RWLOCK_DESTROY ) #define LDAP_THREAD_HAVE_RDWR 1 typedef pthread_rwlock_t ldap_int_thread_rdwr_t; #endif ldap_int_thread.h includes pthread.h, which includes bits/pthreadtypes.h which defines pthread_rwlock_t ... I can't see why this use fails, where the rest of OpenLDAP builds just fine prior to this. smbk5pwd is also affected. I don't have time to investigate further now, but wanted to capture what info I have now.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 19 May '11

19 May '11

The bug is caused by the fact that "mapping" is always on, and slapo-rwm checks whether there is anything it can/need to do about special attributes, and it (incorrectly) assumed attributes have an equality rule. It has nothing to do with the fact that you defined no rules for search or so. The quick fix would be to check whether sat_equality is NULL; the (possibly) long fix would be to entirely skip mapping when not needed. p.

1 0

(ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 19 May '11

19 May '11

Full_Name: Jorge Perez Burgos Version: 2.4.21 OS: SLES 10 SP3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Our slapd uses 256 threads with conn_max_pending_auth 5000. We have seen that with certain network traffic and conditions a huge increased in the amount of memory. After using valgrind and a little study, we have seen slapd cache operation structure in a list. These lists are per thread and could reach high values, in some cases we have seen 12500 operations cached, so 256*12500 could reach around 3GB. It's suggested adding an option to disable this cache or limit the growth of this one for future versions.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: >> We don't have any definition for apple-group-nestedgroup in any of the >> schemas that I have loaded. It's not something we support. We're also >> not doing any proxying. Note also that the search base it's using >> (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple >> system on campus that someone has set up to query our LDAP tree, looking >> for things that the Mac OS X expects to find, but that we don't have or >> support. >> >> One thing that confuses me a little -- I set the rwm-rewriteContext to >> "bindDN", which I perhaps incorrectly believed meant that rewriting would >> only be done for authenticated binds (i.e. not anonymous binds), and >> this client did not authenticate. I was under the mistaken impression >> that >> rwm shouldn't even be called in cases like this. I don't (currently) need >> to >> rewrite searches or results from searches, only the bind credentials, for >> when we eventually enable support for ldap authentication. >> >> Does that answer your question? Would it be helpful to see either my >> original slapd.conf or the slapd-config that results from the conversion? > > Yes, either would be useful. Thanks, p. Here it is. Thanks, Tim #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ #@ #@ TVM: this file is no longer used. All slapd configuration is done via #@ the LDAP/LDIF-based slapd-config(5) backend, using commands like ldapadd, #@ ldapmodify, etc. #@ #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ # # # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # TVM: changed all paths from /etc/openldap/schema to # /etc/local/openldap/schema. # TVM: prior slapd.conf files based on earlier distributions of openldap # had fewer default schemas included (the config file we used with 2.3.24 # on RH4 loaded only core, cosine, inetorgperson, misc, and our custom # ndusEduPerson.schema). # For the install on RHEL5, I started with the stock slapd.conf from openldap # 2.4.21 and then removed the ones I didn't think we needed, e.g. corba, # duaconf, dyngroup, java, nis, ppolicy, and collective. # #include /etc/local/openldap/schema/corba.schema include /etc/local/openldap/schema/core.schema include /etc/local/openldap/schema/cosine.schema #include /etc/local/openldap/schema/duaconf.schema #include /etc/local/openldap/schema/dyngroup.schema include /etc/local/openldap/schema/inetorgperson.schema #include /etc/local/openldap/schema/java.schema include /etc/local/openldap/schema/misc.schema #include /etc/local/openldap/schema/nis.schema include /etc/local/openldap/schema/openldap.schema #include /etc/local/openldap/schema/ppolicy.schema #include /etc/local/openldap/schema/collective.schema # # TVM: custom NDUS schema # include /etc/local/openldap/schema/ndusEduPerson.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # # TVM: the sizelimit and timelimits we've historically used for slapd # sizelimit 150 timelimit 180 # Load dynamic backend modules: # modulepath /usr/lib/openldap # or /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # # TVM: uncommented this, we need it for bindDN massaging # moduleload rwm.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/ldap.NoDak.edu.crt TLSCertificateKeyFile /etc/pki/tls/certs/ldap.NoDak.edu.key # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # # TVM: FIXME: for testing just require encryption for simple_bind # TVM: this can't be enabled until Dale's code to populate LDAP is ready # for it. #security simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # # TVM: added NDUS access controls (Note: these were at the bottom of # the older slapd.conf file before, now they're in an earlier section). # # I think we should seriously revisit these # access to filter=(cn=anonymous) attrs=cn,sn by * none # # TVM: inserted this ACL between the two that have been present since # the beginning. This is to try prevent userPassword: from showing up # in ldapsearch output, but still allow it to be used for auth # access to attrs=userPassword by anonymous auth access to * by * read # # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay # and add rules so that binds with the iid work. # overlay rwm rwm-rewriteEngine on # define a rewriteMap function that returns the dn for a particular attr # This is straight out of the first bindDN example in slapo-rwm(5) rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" rwm-rewriteContext bindDN # and now the magic: parse out the IID and pass it to the attr2dn function. # This is also almost exactly taken from slapo-rwm(5), though I'm using iid # instead of mail and I'm not anchoring the regex and using $1, so it doesn't # matter if it's qualified or not. rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=nodak,dc=edu" checkpoint 1024 15 # # TVM: I added these settings as part of the migration to 2.4.x. # These are pure guesses. If memory is still available, we should # probably increase both. Note section 21.4.3 of the guide, that indicates # the idlcachesize should match cachesize when using bdb, but it should # be 3*cachesize for hdb, which doesn't really make a lot # of sense to me, but oh well... See slapd-bdb for more info # cachesize 2048 idlcachesize 6144 # # TVM: using System V shared memory is much faster for recent versions of # the Linux kernel than using mmap(2) files, so we'll give it a try. # # shm_key can be anything, it just identifies a shared memory segment that # BDB can use for its shared memory regions. # shm_key 41 rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SHA}ceHixPjpYAryAobGXZyzztpweto= # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/data-1 # # Indices to maintain for this database # # TVM: with openldap 2.3.24 on RHEL4 we just commented all of these out and # added our own, some of which exactly duplicated these. I'll keep the first # two index lines and comment out the next three, then supplment with ours. # # Also, previously we maintained a presence (pres) index on *every* one of # these. Section 21.2.3 of the OpenLDAP admin guide makes it very clear # that presence indexing is almost always a bad idea. With that in mind, # I've removed presence indexing from all of these. # index objectClass eq index ou,cn,mail,surname,givenname eq,sub #index uidNumber,gidNumber,loginShell eq #index uid,memberUid eq,sub #index nisMapName,nisMapEntry eq,sub # # TVM: added indexes on all of these. # index mailLocalAddress,mailRoutingAddress,nid eq index iid,uid,services eq,sub index class,college,major eq,sub index group,department,institution,title eq,sub index physicalDeliveryOfficeName,telephoneNumber eq,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # TVM: this is new with 2.4.x, we'll leave it enabled, see chapter 20 of # the admin guide. # # enable monitoring database monitor rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # allow only rootdn to read the monitor access to * by * none

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 18 May '11

18 May '11

> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > >>> At the time of the search, the very last thing that was logged was >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH >>> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 >>> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn >>> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid >>> primaryGroupID apple-keyword apple-group-nestedgroup >>> >>> >>> I'll happily provide any details that I've mistakenly left out or that >>> would >>> aid >>> in debugging the issue. >>> >>> The issue certainly could be caused by an error in my rwmRewriteRule, >>> but I >>> imagine that slapd shouldn't segfault even if my rwmRewriteRule is >>> wrong. >> >> Yes (I believe), and yes. I believe the mapping is being applied to an >> attribute that is not explicitly defined in the schema, but rather >> proxied or >> somehow treated as undefined. For this reason, the matching rule >> pointer is >> NULL. Can you check the definition of "apple-group-nestedgroup", if >> any? Of >> course, slapo-rwm should not crash on something like this. > > Thank you Pierangelo. > > We don't have any definition for apple-group-nestedgroup in any of the > schemas that I have loaded. It's not something we support. We're also > not doing any proxying. Note also that the search base it's using > (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple > system on campus that someone has set up to query our LDAP tree, looking > for things that the Mac OS X expects to find, but that we don't have or > support. > > One thing that confuses me a little -- I set the rwm-rewriteContext to > "bindDN", which I perhaps incorrectly believed meant that rewriting would > only be done for authenticated binds (i.e. not anonymous binds), and > this client did not authenticate. I was under the mistaken impression > that > rwm shouldn't even be called in cases like this. I don't (currently) need > to > rewrite searches or results from searches, only the bind credentials, for > when we eventually enable support for ldap authentication. > > Does that answer your question? Would it be helpful to see either my > original slapd.conf or the slapd-config that results from the conversion? Yes, either would be useful. Thanks, p.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: >> At the time of the search, the very last thing that was logged was >> >> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH >> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 >> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" >> >> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn >> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid >> primaryGroupID apple-keyword apple-group-nestedgroup >> >> >> I'll happily provide any details that I've mistakenly left out or that would >> aid >> in debugging the issue. >> >> The issue certainly could be caused by an error in my rwmRewriteRule, but I >> imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong. > > Yes (I believe), and yes. I believe the mapping is being applied to an > attribute that is not explicitly defined in the schema, but rather proxied or > somehow treated as undefined. For this reason, the matching rule pointer is > NULL. Can you check the definition of "apple-group-nestedgroup", if any? Of > course, slapo-rwm should not crash on something like this. Thank you Pierangelo. We don't have any definition for apple-group-nestedgroup in any of the schemas that I have loaded. It's not something we support. We're also not doing any proxying. Note also that the search base it's using (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple system on campus that someone has set up to query our LDAP tree, looking for things that the Mac OS X expects to find, but that we don't have or support. One thing that confuses me a little -- I set the rwm-rewriteContext to "bindDN", which I perhaps incorrectly believed meant that rewriting would only be done for authenticated binds (i.e. not anonymous binds), and this client did not authenticate. I was under the mistaken impression that rwm shouldn't even be called in cases like this. I don't (currently) need to rewrite searches or results from searches, only the bind credentials, for when we eventually enable support for ldap authentication. Does that answer your question? Would it be helpful to see either my original slapd.conf or the slapd-config that results from the conversion? Thanks much, Tim

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 18 May '11

18 May '11

On 05/18/2011 12:42 AM, Tim.Mooney(a)ndsu.edu wrote: > Full_Name: Tim Mooney > Version: 2.4.25 > OS: Linux, RHEL 5.6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) > > > Recently replaced an OpenLDAP 2.3.x server with a newer system running RHEL 5.6 > x86_64. OpenLDAP 2.4.25 + Berkeley DB 4.8.30, built as x86_64 also. We've had > slapd segfault several times now, and the most recent time it happened, I had > slapd running under gdb and caught where it was happening. > > As part of the server and OpenLDAP replacement, we're beginning to support ldap > authentication via SASL pass-through to Kerberos. With the authentication, we > also have the need to do DN rewriting at auth time, which is why I've enabled > rwm and have the following in slapd-config: > > dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-rewriteEngine "on" > olcRwmRewrite: {1}rwm-rewriteMap "ldap" "attr2dn" "ldap://localhost/dc=nodak,d > c=edu?dn?sub" > olcRwmRewrite: {2}rwm-rewriteContext "bindDN" > olcRwmRewrite: {3}rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > structuralObjectClass: olcRwmConfig > > > This was generated via the automatic conversion from slapd.conf, the original > entries in slapd.conf were: > > # > # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay > # and add rules so that binds with the iid work. > # > overlay rwm > rwm-rewriteEngine on > > # define a rewriteMap function that returns the dn for a particular attr > # This is straight out of the first bindDN example in slapo-rwm(5) > rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" > > rwm-rewriteContext bindDN > # and now the magic: parse out the IID and pass it to the attr2dn function. > # This is also almost exactly taken from slapo-rwm(5), though I'm using iid > # instead of mail and I'm not anchoring the regex and using $1, so it doesn't > # matter if it's qualified or not. > rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" > > > With those rewrite rules in place, certain searches have been triggering the > slapd segfault. > > The segfault: > > [root@server2 ldap]# /etc/init.d/NDUS_ldap stop; gdb /usr/local/sbin/slapd > Stopping slapd: [ OK ] > GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > > warning: no loadable sections found in added symbol-file system-supplied DSO at > 0x2aaaaaf47000 > [Thread debugging using libthread_db enabled] > [New process 5168] > [Thread debugging using libthread_db enabled] > [New Thread 0x40800940 (LWP 5169)] > [New Thread 0x41001940 (LWP 5170)] > [New Thread 0x41802940 (LWP 5182)] > [New Thread 0x42003940 (LWP 5183)] > [New Thread 0x42804940 (LWP 5302)] > [New Thread 0x43005940 (LWP 5303)] > [New Thread 0x43806940 (LWP 7677)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42804940 (LWP 5302)] > 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, > mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, > remap=0, memctx=0x2aaadbb91740) > at ../../../../servers/slapd/overlays/rwmmap.c:439 > 439 } else if ( ad->ad_type->sat_equality->smr_usage& > SLAP_MR_MUTATION_NORMALIZER ) { > Load new symbol table from "/usr/local/sbin/slapd"? (y or n) y > Reading symbols from /usr/local/sbin/slapd...done. > > (gdb) where > #0 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, > mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, > remap=0, memctx=0x2aaadbb91740) > at ../../../../servers/slapd/overlays/rwmmap.c:439 > #1 0x00002aaab0a4ee87 in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x2aaae1001688, fstr=0x42802730) > at ../../../../servers/slapd/overlays/rwmmap.c:528 > #2 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x2aaae10016b0, fstr=0x428027d0) > at ../../../../servers/slapd/overlays/rwmmap.c:691 > #3 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x0, fstr=0x428028c0) > at ../../../../servers/slapd/overlays/rwmmap.c:691 > #4 0x00002aaab0a4f5eb in rwm_filter_map_rewrite (op=0x2aaaaaf29fc0, > dc=0x2aaaaaeab420, f=0x0, fstr=0x2aaaaaf67740) > at ../../../../servers/slapd/overlays/rwmmap.c:793 > #5 0x00002aaab0a4b542 in rwm_op_search (op=0x2aaadbb91380, rs=0x42803c10) > at ../../../../servers/slapd/overlays/rwm.c:969 > #6 0x00002aaaaab5ee0a in overlay_op_walk (op=0x2aaadbb91380, rs=0x42803c10, > which=op_search, oi=0x2aaaab01e060, on=0x2aaaab01e240) > at ../../../servers/slapd/backover.c:659 > #7 0x00002aaaaab5f418 in over_op_func (op=0x2aaadbb91380, rs=0x42803c10, > which=op_search) at ../../../servers/slapd/backover.c:721 > #8 0x00002aaaaaaf7325 in do_search (op=0x2aaadbb91380, rs=0x42803c10) > at ../../../servers/slapd/search.c:217 > #9 0x00002aaaaaaf4644 in connection_operation (ctx=0x42803d60, > arg_v=<value optimized out>) at ../../../servers/slapd/connection.c:1113 > #10 0x00002aaaaaaf4ca1 in connection_read_thread (ctx=0x42803d60, > argv=<value optimized out>) at ../../../servers/slapd/connection.c:1249 > #11 0x00002aaaaabf3d08 in ldap_int_thread_pool_wrapper (xpool=0x2aaaaaf7dfa0) > at ../../../libraries/libldap_r/tpool.c:685 > #12 0x00002aaaad5b973d in start_thread () from /lib64/libpthread.so.0 > #13 0x00002aaaadaac0cd in clone () from /lib64/libc.so.6 > (gdb) print dc > $1 = (dncookie *) 0x428028a0 > (gdb) print *dc > $2 = {rwmap = 0x2aaaab01e420, conn = 0x2aaab0c70330, > ctx = 0x2aaab0a50519 "searchFilterAttrDN", rs = 0x42803c10} > (gdb) print dc->rwmap > $3 = (struct ldaprwmap *) 0x2aaaab01e420 > (gdb) print *(dc->rwmap) > $4 = {rwm_rw = 0x2aaaab01e480, rwm_bva_rewrite = 0x2aaaab023a50, rwm_oc = { > drop_missing = 0, map = 0x0, remap = 0x0}, rwm_at = {drop_missing = 0, > map = 0x0, remap = 0x0}, rwm_bva_map = 0x0, rwm_flags = 2} > > (gdb) print adp > $5 = (AttributeDescription **) 0x428026b8 > (gdb) print *adp > $6 = (AttributeDescription *) 0x2aaae10015f0 > (gdb) print **adp > $7 = {ad_next = 0x7564652e6b61646f, ad_type = 0x2aaaaaeab420, ad_cname = { > bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"}, > ad_tags = {bv_len = 145, bv_val = 0x91<Address 0x91 out of bounds>}, > ad_flags = 4096} > (gdb) print ad->ad_type->sat_equality->smr_usage > Cannot access memory at address 0x58 > > > > (gdb) print ad->ad_type->sat_equality > $8 = (MatchingRule *) 0x0 > > (gdb) print *(ad->ad_type) > $10 = {sat_atype = {at_oid = 0x2aaaaac38a54 "1.1.1", at_names = 0x0, > at_desc = 0x2aaaaac35d10 "Catchall for undefined attribute types", > at_obsolete = 1, at_sup_oid = 0x0, at_equality_oid = 0x0, > at_ordering_oid = 0x0, at_substr_oid = 0x0, at_syntax_oid = 0x0, > at_syntax_len = 0, at_single_value = 0, at_collective = 0, > at_no_user_mod = 1, at_usage = 3, at_extensions = 0x0}, sat_cname = { > bv_len = 9, bv_val = 0x2aaaaac38a5a "UNDEFINED"}, sat_sup = 0x0, > sat_subtypes = 0x0, sat_equality = 0x0, sat_approx = 0x0, > sat_ordering = 0x0, sat_substr = 0x0, sat_syntax = 0x2aaaaaf694e0, > sat_check = 0, sat_oidmacro = 0x0, sat_soidmacro = 0x0, sat_flags = 768, > sat_next = {stqe_next = 0x0}, sat_ad = 0x0, sat_ad_mutex = {__data = { > __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, > __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, > __size = '\000'<repeats 39 times>, __align = 0}} > (gdb) print value > $11 = (struct berval *) 0x2aaae10015d0 > (gdb) print *value > $12 = {bv_len = 36, > bv_val = 0x2aaae1001650 "ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B"} > (gdb) print *mapped_value > $13 = {bv_len = 0, bv_val = 0x2aaae10015a0 "\243"} > (gdb) print *mapped_attr > $14 = {bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"} > > > At the time of the search, the very last thing that was logged was > > May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH > base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 > filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" > > May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn > apple-generateduid gidNumber apple-group-realname ttl sambaSID rid > primaryGroupID apple-keyword apple-group-nestedgroup > > > I'll happily provide any details that I've mistakenly left out or that would aid > in debugging the issue. > > The issue certainly could be caused by an error in my rwmRewriteRule, but I > imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong. Yes (I believe), and yes. I believe the mapping is being applied to an attribute that is not explicitly defined in the schema, but rather proxied or somehow treated as undefined. For this reason, the matching rule pointer is NULL. Can you check the definition of "apple-group-nestedgroup", if any? Of course, slapo-rwm should not crash on something like this. p.

1 0

(ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 17 May '11

17 May '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, RHEL 5.6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) Recently replaced an OpenLDAP 2.3.x server with a newer system running RHEL 5.6 x86_64. OpenLDAP 2.4.25 + Berkeley DB 4.8.30, built as x86_64 also. We've had slapd segfault several times now, and the most recent time it happened, I had slapd running under gdb and caught where it was happening. As part of the server and OpenLDAP replacement, we're beginning to support ldap authentication via SASL pass-through to Kerberos. With the authentication, we also have the need to do DN rewriting at auth time, which is why I've enabled rwm and have the following in slapd-config: dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-rewriteEngine "on" olcRwmRewrite: {1}rwm-rewriteMap "ldap" "attr2dn" "ldap://localhost/dc=nodak,d c=edu?dn?sub" olcRwmRewrite: {2}rwm-rewriteContext "bindDN" olcRwmRewrite: {3}rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE structuralObjectClass: olcRwmConfig This was generated via the automatic conversion from slapd.conf, the original entries in slapd.conf were: # # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay # and add rules so that binds with the iid work. # overlay rwm rwm-rewriteEngine on # define a rewriteMap function that returns the dn for a particular attr # This is straight out of the first bindDN example in slapo-rwm(5) rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" rwm-rewriteContext bindDN # and now the magic: parse out the IID and pass it to the attr2dn function. # This is also almost exactly taken from slapo-rwm(5), though I'm using iid # instead of mail and I'm not anchoring the regex and using $1, so it doesn't # matter if it's qualified or not. rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" With those rewrite rules in place, certain searches have been triggering the slapd segfault. The segfault: [root@server2 ldap]# /etc/init.d/NDUS_ldap stop; gdb /usr/local/sbin/slapd Stopping slapd: [ OK ] GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaf47000 [Thread debugging using libthread_db enabled] [New process 5168] [Thread debugging using libthread_db enabled] [New Thread 0x40800940 (LWP 5169)] [New Thread 0x41001940 (LWP 5170)] [New Thread 0x41802940 (LWP 5182)] [New Thread 0x42003940 (LWP 5183)] [New Thread 0x42804940 (LWP 5302)] [New Thread 0x43005940 (LWP 5303)] [New Thread 0x43806940 (LWP 7677)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42804940 (LWP 5302)] 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, remap=0, memctx=0x2aaadbb91740) at ../../../../servers/slapd/overlays/rwmmap.c:439 439 } else if ( ad->ad_type->sat_equality->smr_usage & SLAP_MR_MUTATION_NORMALIZER ) { Load new symbol table from "/usr/local/sbin/slapd"? (y or n) y Reading symbols from /usr/local/sbin/slapd...done. (gdb) where #0 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, remap=0, memctx=0x2aaadbb91740) at ../../../../servers/slapd/overlays/rwmmap.c:439 #1 0x00002aaab0a4ee87 in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x2aaae1001688, fstr=0x42802730) at ../../../../servers/slapd/overlays/rwmmap.c:528 #2 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x2aaae10016b0, fstr=0x428027d0) at ../../../../servers/slapd/overlays/rwmmap.c:691 #3 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x0, fstr=0x428028c0) at ../../../../servers/slapd/overlays/rwmmap.c:691 #4 0x00002aaab0a4f5eb in rwm_filter_map_rewrite (op=0x2aaaaaf29fc0, dc=0x2aaaaaeab420, f=0x0, fstr=0x2aaaaaf67740) at ../../../../servers/slapd/overlays/rwmmap.c:793 #5 0x00002aaab0a4b542 in rwm_op_search (op=0x2aaadbb91380, rs=0x42803c10) at ../../../../servers/slapd/overlays/rwm.c:969 #6 0x00002aaaaab5ee0a in overlay_op_walk (op=0x2aaadbb91380, rs=0x42803c10, which=op_search, oi=0x2aaaab01e060, on=0x2aaaab01e240) at ../../../servers/slapd/backover.c:659 #7 0x00002aaaaab5f418 in over_op_func (op=0x2aaadbb91380, rs=0x42803c10, which=op_search) at ../../../servers/slapd/backover.c:721 #8 0x00002aaaaaaf7325 in do_search (op=0x2aaadbb91380, rs=0x42803c10) at ../../../servers/slapd/search.c:217 #9 0x00002aaaaaaf4644 in connection_operation (ctx=0x42803d60, arg_v=<value optimized out>) at ../../../servers/slapd/connection.c:1113 #10 0x00002aaaaaaf4ca1 in connection_read_thread (ctx=0x42803d60, argv=<value optimized out>) at ../../../servers/slapd/connection.c:1249 #11 0x00002aaaaabf3d08 in ldap_int_thread_pool_wrapper (xpool=0x2aaaaaf7dfa0) at ../../../libraries/libldap_r/tpool.c:685 #12 0x00002aaaad5b973d in start_thread () from /lib64/libpthread.so.0 #13 0x00002aaaadaac0cd in clone () from /lib64/libc.so.6 (gdb) print dc $1 = (dncookie *) 0x428028a0 (gdb) print *dc $2 = {rwmap = 0x2aaaab01e420, conn = 0x2aaab0c70330, ctx = 0x2aaab0a50519 "searchFilterAttrDN", rs = 0x42803c10} (gdb) print dc->rwmap $3 = (struct ldaprwmap *) 0x2aaaab01e420 (gdb) print *(dc->rwmap) $4 = {rwm_rw = 0x2aaaab01e480, rwm_bva_rewrite = 0x2aaaab023a50, rwm_oc = { drop_missing = 0, map = 0x0, remap = 0x0}, rwm_at = {drop_missing = 0, map = 0x0, remap = 0x0}, rwm_bva_map = 0x0, rwm_flags = 2} (gdb) print adp $5 = (AttributeDescription **) 0x428026b8 (gdb) print *adp $6 = (AttributeDescription *) 0x2aaae10015f0 (gdb) print **adp $7 = {ad_next = 0x7564652e6b61646f, ad_type = 0x2aaaaaeab420, ad_cname = { bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"}, ad_tags = {bv_len = 145, bv_val = 0x91 <Address 0x91 out of bounds>}, ad_flags = 4096} (gdb) print ad->ad_type->sat_equality->smr_usage Cannot access memory at address 0x58 (gdb) print ad->ad_type->sat_equality $8 = (MatchingRule *) 0x0 (gdb) print *(ad->ad_type) $10 = {sat_atype = {at_oid = 0x2aaaaac38a54 "1.1.1", at_names = 0x0, at_desc = 0x2aaaaac35d10 "Catchall for undefined attribute types", at_obsolete = 1, at_sup_oid = 0x0, at_equality_oid = 0x0, at_ordering_oid = 0x0, at_substr_oid = 0x0, at_syntax_oid = 0x0, at_syntax_len = 0, at_single_value = 0, at_collective = 0, at_no_user_mod = 1, at_usage = 3, at_extensions = 0x0}, sat_cname = { bv_len = 9, bv_val = 0x2aaaaac38a5a "UNDEFINED"}, sat_sup = 0x0, sat_subtypes = 0x0, sat_equality = 0x0, sat_approx = 0x0, sat_ordering = 0x0, sat_substr = 0x0, sat_syntax = 0x2aaaaaf694e0, sat_check = 0, sat_oidmacro = 0x0, sat_soidmacro = 0x0, sat_flags = 768, sat_next = {stqe_next = 0x0}, sat_ad = 0x0, sat_ad_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}} (gdb) print value $11 = (struct berval *) 0x2aaae10015d0 (gdb) print *value $12 = {bv_len = 36, bv_val = 0x2aaae1001650 "ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B"} (gdb) print *mapped_value $13 = {bv_len = 0, bv_val = 0x2aaae10015a0 "\243"} (gdb) print *mapped_attr $14 = {bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"} At the time of the search, the very last thing that was logged was May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn apple-generateduid gidNumber apple-group-realname ttl sambaSID rid primaryGroupID apple-keyword apple-group-nestedgroup I'll happily provide any details that I've mistakenly left out or that would aid in debugging the issue. The issue certainly could be caused by an error in my rwmRewriteRule, but I imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong.

1 0

(ITS#6942) updateref config is inadequate
by hyc＠OpenLDAP.org 11 May '11

11 May '11

Full_Name: Howard Chu Version: 2.4.x OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc This was pointed out on the mailing list, I've lost the exact message now. We allow multiple consumers in a single DB, but we only allow a single updateref on the DB. This is clearly broken; we need to be able to specify an updateref per consumer. This also ties in with other discussions about moving updateref processing out of the frontend. Doing it in the frontend was OK back in OpenLDAP 2.3 and earlier, but not any more.

1 0

(ITS#6941
by tjgates＠castlebranch.com 11 May '11

11 May '11

------=_Part_26721_267475779.1305154501363 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Some how this got duplicated from ITS#6940, please close. -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. ------=_Part_26721_267475779.1305154501363 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'><span>Some how this got duplicated from ITS#6940, please close.<br><br>-- <br><br>Tyler Gates<br>Systems Administrator<br>Castle Branch Inc.<br>910-815-3880 ext 7230<br>tjgates(a)castlebranch.com<br><br>This e-mail message, including any attachments, may contain private,<br>confidential, and privileged information for the restricted use of the<br>intended recipient(s). If you are not the intended recipient(s), you<br>may NOT use, disclose, copy, or disseminate this information. Please<br>notify the sender by return e-mail of this misdirected correspondence<br>and destroy all copies of the original message including all attachments.<br>Your cooperation is appreciated.<br></span></div></body></html> ------=_Part_26721_267475779.1305154501363--

1 0

(ITS#6941) issues reading the db directory since 2.4.25
by tjgates＠castlebranch.com 11 May '11

11 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04.2 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) Ever since updating to OpenLDAP 2.4.25, I've been experiencing what seems to be read issues on the directory database. I get non-responsive queries and messages complaining about DB_CONFIG not being found even though these files are obviously being created by slapd without issues during startup: root@directory-proxy2:/var/lib/ldap# rm -rf /var/lib/ldap/* root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 8 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. root@directory-proxy2:/var/lib/ldap# service slapd start * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:28 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:28 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:28 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:28 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:28 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:28 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:28 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:28 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:28:34 directory-proxy2 slapd[7266]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". Fine. So now that DB_CONFIG obviously exists, I restart slapd: root@directory-proxy2:/var/lib/ldap# service slapd restart * Stopping OpenLDAP slapd ...done. * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:30 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:30 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:30 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:30 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:30 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:30 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:30 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:30 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:30 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:30:08 directory-proxy2 slapd[7297]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". As you can it still complains that DB_CONFIG does not exist when it obviously does and is owned correctly: root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 7297 0.0 0.5 56248 5928 ? Ssl 09:30 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d Any help would be appreciated.

1 0

(ITS#6940) issues reading the db directory since 2.4.25
by tjgates＠castlebranch.com 11 May '11

11 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04.2 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) Ever since updating to OpenLDAP 2.4.25, I've been experiencing what seems to be read issues on the directory database. I get non-responsive queries and messages complaining about DB_CONFIG not being found even though these files are obviously being created by slapd without issues during startup: root@directory-proxy2:/var/lib/ldap# rm -rf /var/lib/ldap/* root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 8 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. root@directory-proxy2:/var/lib/ldap# service slapd start * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:28 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:28 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:28 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:28 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:28 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:28 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:28 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:28 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:28:34 directory-proxy2 slapd[7266]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". Fine. So now that DB_CONFIG obviously exists, I restart slapd: root@directory-proxy2:/var/lib/ldap# service slapd restart * Stopping OpenLDAP slapd ...done. * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:30 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:30 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:30 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:30 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:30 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:30 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:30 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:30 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:30 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:30:08 directory-proxy2 slapd[7297]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". As you can it still complains that DB_CONFIG does not exist when it obviously does and is owned correctly: root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 7297 0.0 0.5 56248 5928 ? Ssl 09:30 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d Any help would be appreciated.

1 0

(ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by quanah＠OpenLDAP.org 11 May '11

11 May '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) *** glibc detected *** slapd: double free or corruption (top): 0x08894138 *** and slapd crashes with an abort signal. this happens when i set "olcTLSCipherSuite: ___" doesn't matter what, it crashes. doesn't happen with openssl-built slapd, but only with gnutls-built one.

1 0

(ITS#6938) Windows IPv6 support
by kurt＠OpenLDAP.org 11 May '11

11 May '11

Full_Name: Kurt Zeilenga Version: all OS: Windows7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.253) Feature request: extend Windows port to support IPv6

1 0

(ITS#6937) Remove --enable-proctitle and strdup(optarg)
by h.b.furuseth＠usit.uio.no 10 May '11

10 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.25 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "configure --enable-proctitle" uses setproctitle/proctitle(), which we no longer use. So I'll remove that and liblutil/setproctitle.c. That's the default implementation, which works by overwriting argv[]. That's got to be why we have strdup(optarg) instead of just optarg all over the place. So we can drop the strdup()s, which gets rid some admittedly unimportant memory leak reports from program checkers.

1 0

Re: (ITS#6897) segfault in lber on close
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

tarbuck(a)futurewest.ca writes: > backtrace shows what looks to be a double free() call from lber. > This is a production system, so I don't have a whole lot of > information (fixing was the priority). Well, can you show that backtrace? Otherwise there's no chance at all of investigating this further. slapd uses liblber for a lot of its allocations, so the double free could come from just about anywhere. -- Hallvard

1 0

(ITS#6935) Uninitialized variables with certificates
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.25 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) serialNumberAndIssuerNormalize() failure can free uninitialized variable s3. attributeCertificateExactNormalize() failure can free uninitialized variables sn2 and i_sn2. Klocwork issues #442-444. Fixing.

1 0

(ITS#6934) the typos in the man page slapo-nssov.5
by sergei＠bslos.com 09 May '11

09 May '11

Full_Name: Sergei Butakov Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.190.117.137) There are the typos in the man page contrib/slapd-modules/nssov/slapo-nssov.5 - in the string #216 instead of 'nssov-pam-minuid' must be 'nssov-pam-min-uid' and in the string #221 instead of 'nssov-pam-maxuid' must be 'nssov-pam-max-uid'.

1 0

(ITS#6933) Broken NT Service ConfigFile param
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Windows NT + what else? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) slapd/main.c does #ifdef HAVE_NT_SERVICE_MANAGER newConfigFile = (char*)lutil_getRegParam( regService, "ConfigFile" ); newConfigDir = (char*)lutil_getRegParam( regService, "ConfigDir" ); but does not strdup() newConfigFile even though lutil_getRegParam returns static memory. Thus ConfigDir can overwrite ConfigFile. Don't know if that only happens if both are set, since I do not know NT. Fixing: Adding the strdup()s. Which OSes does this apply to? Only Windows NT, or more than that the same way as #ifdef _WIN32 also tests for newer Windowses?

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 06 May '11

06 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/21/2011 04:11 AM, hyc(a)symas.com wrote: > ondrej.kuznik(a)acision.com wrote: >> After a conversation with Howard, I have modified the patches so that >> the overlay check for the ManageDsaIt control instead. That control >> should be set for each operation coming from replication. The patches >> are here: >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz >> >> Is there anything else that comes to mind? > > I'm not sure it merits a config keyword. We already have instances where > administrators are implicitly allowed to bypass rules that restrict normal > users, and replication is obviously a system-level operation, not user level. > Rereading the discussions makes me agree with you. I have prepared a patch without the config keyword and modified the slapo-unique manpage accordingly. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110506-unique_bypass_v3.tgz Again the IPR notice: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3D6ZkACgkQ9GWxeeH+cXtv7ACgl+6zPsyecGdWxjEnDL2CPDDp 2HoAoJ3D1XcuAJ1d+L/kwLLBltbo/ifo =RyJh -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6932) Strange assert()s
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Klocwork reports a number of strange assert()s, typically assert(function parameter != NULL) after dereferencing it. Also some pointless ones, like if (ptr->foo) { bar = ptr; assert(bar != NULL); } I'll move these, along with some not found by Klocwork. At the same time, I'll change some nearby code to use alredy-computed values, e.g. be = op->o_bd; bi = op->o_bd->bd_info; can become bi = be->bd_info;

1 0

(ITS#6931) ldap_get_option(NULL, LDAP_OPT_SESSION_REFCNT, ) crash
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_get_option(,LDAP_OPT_SESSION_REFCNT,) does not catch ld=NULL. Klocwork issue#111. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

hyc(a)symas.com writes: >quanah(a)zimbra.com wrote: >> --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> >>> hyc(a)symas.com writes: >>>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >>> >>> There are several fopen(filename, "w") calls, which truncate the file. >>> Maybe the error confuses slapd so it takes a detour into one of them. > > Irrelevant. In Windows the OS prevents you from writing to an executable file > that is currently running. I.e., it is impossible for this to be the cause. Aha. OK. I don't know Windows, so I was reacting to what you said, not to what you didn't say:-) > Try it yourself: Can't without Windows. > (...) > If you still believe it's happening inside slapd the obvious thing to do to > track this is to run slapd under gdb and set a few breakpoints. E.g., one at > the end of the config parser, and one at slapd's call to exit(). At each > breakpoint, check the filesize of the slapd.exe. Something like that was what I had in mind, yes. I might try anyway. -- Hallvard

1 0

(ITS#6930) Socket leak in ldap_connect_to_path(too long path)
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_connect_to_path() verifies its parameters after instead of before socket(), and does not close the socket on failure. Also the cleanup code can be simplified. Found by Klocwork, issue#117.

1 0

(ITS#6929) lutil_get_filed_password() filed descriptor leak
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard lutil_get_filed_password() does not always close the file on error. Found with Klocwork: Issue #203. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 05 May '11

05 May '11

quanah(a)zimbra.com wrote: > --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> hyc(a)symas.com writes: >>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >> >> There are several fopen(filename, "w") calls, which truncate the file. >> Maybe the error confuses slapd so it takes a detour into one of them. Irrelevant. In Windows the OS prevents you from writing to an executable file that is currently running. I.e., it is impossible for this to be the cause. Try it yourself: #include <stdio.h> main(int argc, char *argv[]) { FILE *f=fopen(argv[0], "w"); if (f) printf("opened!\n"); else printf("failed!\n"); } >> Quanah, can you provide a full slapd.conf and command line which causes >> this? Not that I have a Windows box to test it on, but still... > > The command line was just slapd.exe -d -1 -f slapd.conf > > The slapd.conf itself is fairly small. The line that wrapped was the > include for inetOrgPerson. Everything obviously stopped when it hit the > wrapped include. > > ucdata-path "/opt/zimbra/openldap/ucdata" > include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" > include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" > include > "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" Yes, but since "everything obviously stopped" there's nothing in slapd that fopen's any files from that point. First of all this problem cannot be specific to the include statement, since the input validation will reject the line before ever going anywhere the code for include handling. So, you ought to be able to reproduce this issue using any config statement that requires a single argument. Second, slapd stops all parsing and simply exits when it hits a config error. And this is early enough in the config file that nothing else has been initialized yet, so the teardown processing has very little to do. If you still believe it's happening inside slapd the obvious thing to do to track this is to run slapd under gdb and set a few breakpoints. E.g., one at the end of the config parser, and one at slapd's call to exit(). At each breakpoint, check the filesize of the slapd.exe. -- -- 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#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

The root cause in this case is that the schema differs on the consumer and schema violation errors were logged at the consumer. Obviously this is a configuration error but the provider should not crash because of this!

1 0

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

1 0

Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com 04 May '11

04 May '11

ryans(a)aweber.com wrote: > Full_Name: Ryan Steele > Version: 2.4.23 > OS: Ubuntu Server 10.04 (Lucid) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle > Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet > attribute, populating it with a value that does not take DST into account. As > an example, consider the following attributes from one of the entries in my > directory: > > pwdChangedTime: 20110502160329Z > sambaPwdLastSet: 1304352209 > > Obviously, pwdChangedTime specifies the timestamp: > > Mon May 2 16:03:29 EDT 2011 > > On the other hand, sambaPwdLastSet specifies the timestamp as being an hour > later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 > sec'): > > Mon May 2 17:03:29 EDT 2011 > > Right now we're in DST on the east coast, which is GMT -0400. This would mean > that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly > calculating results using GMT -0500. The sambaPwdLastSet value is not calculated at all, it is exactly what the OS system clock returns, and the OS system clock is in UTC so DST is irrelevant. Probably your machine's timezone is misconfigured; notice that pwdChangedTime is also in UTC so 20110502160329Z cannot be "May 2 16:03:29 EDT". Closing this ITS. -- -- 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#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com 04 May '11

04 May '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server 10.04 (Lucid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet attribute, populating it with a value that does not take DST into account. As an example, consider the following attributes from one of the entries in my directory: pwdChangedTime: 20110502160329Z sambaPwdLastSet: 1304352209 Obviously, pwdChangedTime specifies the timestamp: Mon May 2 16:03:29 EDT 2011 On the other hand, sambaPwdLastSet specifies the timestamp as being an hour later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 sec'): Mon May 2 17:03:29 EDT 2011 Right now we're in DST on the east coast, which is GMT -0400. This would mean that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly calculating results using GMT -0500.

1 0

(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de 04 May '11

04 May '11

Full_Name: Sascha Kuehndel Version: 2.4.25 OS: HP-UX 11.31 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.166.104.102) Hi, i tested the delta-sync in a multi-master (2 master) architecture. In a split-brain szenario the sync produced an undefinded state. Some times the data wasn't synchronized (both master hold there data unchanged), sometimes the data was fliped (master1 take data from master2, and master2 from master1). A defined and synchronized state must reached after the end of the split-brain. Senario: 1. master1 and master2 runs in sync 2. shutdown of master2 3. data change on master1 4. shutdown of master1 5. start of master2 6. data change on master2 (the same attribute on the same object, other value) > now the masters are out of sync in the same field 7. restart of master1 8. the sync process is running 9. take a look on the change field.. there are different regards Sascha Kuehndel PS - Nice to have: The posibility to define the action in thouch an situation - master1 or master2... wins - the newest win - or no change and the posibility to write a log-entry about it (with the exact dn,the attribute and the values before the synchronization)

1 0

Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com 03 May '11

03 May '11

--On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> Nothing in the OpenLDAP code issues a truncate operation of any sort. > > There are several fopen(filename, "w") calls, which truncate the file. > Maybe the error confuses slapd so it takes a detour into one of them. > > Quanah, can you provide a full slapd.conf and command line which causes > this? Not that I have a Windows box to test it on, but still... The command line was just slapd.exe -d -1 -f slapd.conf The slapd.conf itself is fairly small. The line that wrapped was the include for inetOrgPerson. Everything obviously stopped when it hit the wrapped include. ucdata-path "/opt/zimbra/openldap/ucdata" include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/schema/zimbra.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" modulepath /opt/zimbra/openldap/openldap moduleload back_bdb-2-4-2.dll moduleload back_monitor-2-4-2.dll access to dn.subtree="" by dn.children="cn=admins,cn=zimbra" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootpw {SSHA}8+r0nkcErptqasSrFPcT0k81NFrbTcAS database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra" read database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/opt/zimbra/data/ldap/hdb/db" index objectClass eq index uid pres,eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=objectclass,zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs
by daniel＠pluta.biz 03 May '11

03 May '11

In case authcIDs do not need to be normalized, this seems to be a better place to disable normalization: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110502.patch Now authzIDs of the form "u:xxxx" are also affected.

1 0

(ITS#6925) [PATCH] Use inet_ntop for server when available
by delphij＠gmail.com 02 May '11

02 May '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD/amd64 9.0-CURRENT URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) slapd uses inet_ntoa in several places and some of them does not use inet_ntop when it's available. The inet_ntoa is not thread-safe on FreeBSD and thus could cause denial of service if it loses the race, when an IP based ACL is in effect. diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c index aea3b39..65ce576 100644 --- a/servers/slapd/connection.c +++ b/servers/slapd/connection.c @@ -1500,12 +1500,21 @@ connection_input( Connection *conn , conn_readinfo *cri ) #ifdef LDAP_CONNECTIONLESS if ( conn->c_is_udp ) { char peername[sizeof("IP=255.255.255.255:65336")]; + const char *peeraddr = NULL; len = ber_int_sb_read(conn->c_sb, &peeraddr, sizeof(struct sockaddr)); if (len != sizeof(struct sockaddr)) return 1; +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &peeraddr.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ + peeraddr = inet_ntoa( peeraddr.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", - inet_ntoa( peeraddr.sa_in_addr.sin_addr ), + peeraddr, (unsigned) ntohs( peeraddr.sa_in_addr.sin_port ) ); Statslog( LDAP_DEBUG_STATS, "conn=%lu UDP request from %s (%s) accepted.\n", diff --git a/servers/slapd/daemon.c b/servers/slapd/daemon.c index 8e8a69d..ccfa2ee 100644 --- a/servers/slapd/daemon.c +++ b/servers/slapd/daemon.c @@ -1971,8 +1971,16 @@ slap_listener( # ifdef LDAP_PF_INET6 case AF_INET6: if ( IN6_IS_ADDR_V4MAPPED(&from.sa_in6_addr.sin6_addr) ) { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, + ((struct in_addr *)&from.sa_in6_addr.sin6_addr.s6_addr[12]), + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( *((struct in_addr *) &from.sa_in6_addr.sin6_addr.s6_addr[12]) ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in6_addr.sin6_port ) ); @@ -1989,12 +1997,19 @@ slap_listener( break; # endif /* LDAP_PF_INET6 */ - case AF_INET: + case AF_INET: { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &from.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( from.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in_addr.sin_port ) ); - break; + } break; default: slapd_close(sfd);

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by Mark.Selby＠deshaw.com 02 May '11

02 May '11

--_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "FWIW, we don't think this is the same problem. All the threads except the = main one and the one blocking on select(), are blocked on pthread_cond_wait= () - and, according to our analysis of the core file, while they all are us= ing different mutexes, they are all waiting on the same condition variable.= " Is there anything that we can do to have you look at the issue closer? --_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Calibri, sans-serif" size=3D"2"> <div><font color=3D"#1F497D">“FWIW, we don’t think this is the = same problem. All the threads except the main one and the one blocking on <= i>select(),</i> are blocked on <i>pthread_cond_wait() </i>– and, acco= rding to our analysis of the core file, while they all are using different mutexes, they are all waiting on the same condition var= iable.”</font></div> <div> </div> <div><font face=3D"Courier New, monospace" size=3D"2">Is there anything tha= t we can do to have you look at the issue closer?</font></div> <div> </div> </font> </body> </html> --_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_--

1 0

(ITS#6924) www.openldap.org and git.openldap.org serve different repositories
by ondrej.kuznik＠acision.com 02 May '11

02 May '11

Full_Name: Ondrej Kuznik Version: OS: URL: Submission from: (NULL) (62.168.56.1) It seems that the repositories served over http and git protocol (urls as advertised on http://www.openldap.org/devel/gitweb.cgi?p=openldap-etc.git;a=summary) differ. While containing roughly the same history, there are a few commits (at least) at the beginning that are unwound differently in each one. The list of differences between the two repos might be larger, however I have no tool at hand that could help me find them all.

1 0

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 02 May '11

02 May '11

hyc(a)symas.com writes: > Nothing in the OpenLDAP code issues a truncate operation of any sort. There are several fopen(filename, "w") calls, which truncate the file. Maybe the error confuses slapd so it takes a detour into one of them. Quanah, can you provide a full slapd.conf and command line which causes this? Not that I have a Windows box to test it on, but still... -- Hallvard

1 0

Re: (ITS#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by jarl＠dallur.com 01 May '11

01 May '11

--000e0cd48c428f954504a23eaa22 Content-Type: text/plain; charset=UTF-8 First of all let me apologize for the state of the config. As you say the logs don't show any crash yet the OpenLDAP server is not accepting any new connections after 20:36:37, there should be hundreds of connections being logged there but instead the server hangs completely and nothing is logged, even on log level 1. Perhaps someone could suggest a way of getting more information than what loglevel 1 shows? Would the only other step be a debug build? Jarl On Sun, May 1, 2011 at 4:01 AM, Howard Chu <hyc(a)symas.com> wrote: > jarl(a)dallur.com wrote: > >> Full_Name: Jarl Stefansson >> Version: 2.4.22 >> OS: Centos 5.5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.15.35.75) >> >> >> Two servers running OpenLDAP in master/master using syncrepl, roughly once >> per >> week one of the servers stops responding to new connections, I tried >> logging >> with loglevel=1 and this is all I got, all suggestions and comments >> appreciated. >> >> This is most likely a "load" related problem since we never experience >> this >> problem in the testlab, only production.: >> > > Your log doesn't indicate any kind of crash. It only shows that a shutdown > was requested, and apparently your startup scripts didn't wait for the > shutdown to complete before starting again. > > > Apr 23 20:36:37 ldap01 slapd2.4[32233]: >> bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") >> Apr 23 20:36:37 ldap01 slapd2.4[32233]: => >> bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") >> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<= bdb_dn2id: get failed: >> DB_NOTFOUND: >> No matching key/data pair found (-30988) >> Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: >> "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" >> Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): >> Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 >> >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and >> initiated. I have two Centos 5 servers running Openldap 2.4.22 with >> master/master syncrepl setup, >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 >> operations/tasks to finish >> Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean >> shutdown detected; attempting recovery. >> Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting >> > > Your config is a mess, with global directives and DB-specific directives > interleaved. That may not be the cause of any specific problems, but it > shows sloppiness on the part of the sysadmins. > > > ---------------------- Relevant Config >> ------------------------------------------------ >> moduleload syncprov.la >> TLSCertificateFile /etc/pki/tls/private/ldap.pem >> TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem >> TLSCACertificateFile /etc/pki/tls/private/ldap.pem >> >> serverID 001 >> database bdb >> sizelimit 50000 >> cachesize 10000 >> checkpoint 256 5 >> >> >> syncrepl rid=001 >> provider=ldap://10.10.10.10:389 >> bindmethod=simple >> binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" >> credentials=MyPassword >> searchbase="o=xxxx" >> schemachecking=on >> sizelimit="unlimited" >> timelimit="unlimited" >> type=refreshAndPersist >> interval=00:00:00:10 >> retry="5 5 60 +" >> attrs="*,+" >> >> mirrormode on >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> idletimeout 3600 >> threads 32 >> >> >> -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Regards Jarl jarl(a)dallur.com --000e0cd48c428f954504a23eaa22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First of all let me=C2=A0apologize=C2=A0for the state of the config.<div><b= r></div><div>As you say the logs don't show any crash yet the OpenLDAP = server is not accepting any new connections after=C2=A0<meta http-equiv=3D"= content-type" content=3D"text/html; charset=3Dutf-8">20:36:37, there should= be hundreds of connections being logged there but instead the server hangs= completely and nothing is logged, even on log level 1.</div> <div><br></div><div>Perhaps someone could suggest a way of getting more inf= ormation than what loglevel 1 shows?</div><div><br></div><div>Would the onl= y other step be a debug build?</div><div><br></div><div>Jarl<br><br><div cl= ass=3D"gmail_quote"> On Sun, May 1, 2011 at 4:01 AM, Howard Chu <span dir=3D"ltr"><<a href=3D= "mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex;"> <div class=3D"im"><a href=3D"mailto:jarl@dallur.com" target=3D"_blank">jarl= @dallur.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Jarl Stefansson<br> Version: =C2=A02.4.22<br> OS: Centos 5.5<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (81.15.35.75)<br> <br> <br> Two servers running OpenLDAP in master/master using syncrepl, roughly once = per<br> week one of the servers stops responding to new connections, I tried loggin= g<br> with loglevel=3D1 and this is all I got, all suggestions and comments<br> appreciated.<br> <br> This is most likely a "load" related problem since we never exper= ience this<br> problem in the testlab, only production.:<br> </blockquote> <br></div> Your log doesn't indicate any kind of crash. It only shows that a shutd= own was requested, and apparently your startup scripts didn't wait for = the shutdown to complete before starting again.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<br> bdb_dn2entry("macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,= o=3Dxxxx")<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]: =3D><br> bdb_dn2id("macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,o= =3Dxxxx")<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<=3D bdb_dn2id: get failed: DB_NO= TFOUND:<br> No matching key/data pair found (-30988)<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]: =3D> =C2=A0bdb_dn2id_add 0x2fed7= :<br> "macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,o=3Dxxxx&quot= ;<br> Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8):<br> Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1025 sd=3D= 16<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1022 sd=3D= 17<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1037 sd=3D= 18<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1038 sd=3D= 20<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1039 sd=3D= 25<br> <br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and<br> initiated. I have two Centos 5 servers running Openldap 2.4.22 with<br> master/master syncrepl setup,<br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=3D1005 sd=3D= 21<br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59<br> operations/tasks to finish<br> Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "":= unclean<br> shutdown detected; attempting recovery.<br> Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting<br> </blockquote> <br></div> Your config is a mess, with global directives and DB-specific directives in= terleaved. That may not be the cause of any specific problems, but it shows= sloppiness on the part of the sysadmins.<div><div></div><div class=3D"h5"> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> ---------------------- Relevant Config<br> ------------------------------------------------<br> moduleload =C2=A0 =C2=A0 <a href=3D"http://syncprov.la" target=3D"_blank">s= yncprov.la</a><br> TLSCertificateFile =C2=A0 =C2=A0 =C2=A0/etc/pki/tls/private/ldap.pem<br> TLSCertificateKeyFile =C2=A0 /etc/pki/tls/private/ldap.pem<br> TLSCACertificateFile =C2=A0 =C2=A0/etc/pki/tls/private/ldap.pem<br> <br> serverID =C2=A0 =C2=A0 =C2=A0 =C2=A0001<br> database =C2=A0 =C2=A0 =C2=A0 =C2=A0bdb<br> sizelimit =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A050000<br> cachesize 10000<br> checkpoint 256 5<br> <br> <br> syncrepl =C2=A0 =C2=A0 =C2=A0 =C2=A0rid=3D001<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 provider=3Dldap://= <a href=3D"http://10.10.10.10:389" target=3D"_blank">10.10.10.10:389</a><br= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bindmethod=3Dsimpl= e<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 binddn=3D"uid= =3Dxxxxrep,ou=3Dxxxxxx,o=3Dxxxxxx"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 credentials=3DMyPa= ssword<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 searchbase=3D&quot= ;o=3Dxxxx"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 schemachecking=3Do= n<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sizelimit=3D"= unlimited"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timelimit=3D"= unlimited"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type=3DrefreshAndP= ersist<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interval=3D00:00:0= 0:10<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retry=3D"5 5 = 60 +"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attrs=3D"*,+&= quot;<br> <br> mirrormode on<br> overlay syncprov<br> syncprov-checkpoint =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 10<br> syncprov-sessionlog =C2=A0 =C2=A0 100<br> <br> idletimeout 3600<br> threads 32<br> <br> <br> </blockquote></div></div><font color=3D"#888888"> -- <br> =C2=A0-- Howard Chu<br> =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards<br><br>J= arl<br><a href=3D"mailto:jarl@dallur.com">jarl(a)dallur.com</a><br> </div> --000e0cd48c428f954504a23eaa22--

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 30 Apr '11

30 Apr '11

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > An include statement in slapd.conf with no following text will overwrite > slapd.exe as a zero sized binary when it occurs on a windows box. Don't do that. > line 8 (include) > slapd.conf: line 8: keyword<include> missing<file> argument > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > > > After this windows does not recognize slapd.exe as a normal windows app.. > It has become 0 size Nothing in the OpenLDAP code issues a truncate operation of any sort. Nor would it, in the midst of a config statement that was rejected. If you're seeing odd behavior here, it's either a C library bug or a Windows OS bug. Closing this ITS. -- -- 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#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by hyc＠symas.com 30 Apr '11

30 Apr '11

mslby(a)deshaw.com wrote: > Full_Name: Mark Selby > Version: 2.4.25 > OS: Solaris 10 x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.104.214) > > > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. > > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated This appears to be a dup of ITS#6833. Your OS is broken. Closing this ITS. -- -- 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#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by hyc＠symas.com 30 Apr '11

30 Apr '11

jarl(a)dallur.com wrote: > Full_Name: Jarl Stefansson > Version: 2.4.22 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.15.35.75) > > > Two servers running OpenLDAP in master/master using syncrepl, roughly once per > week one of the servers stops responding to new connections, I tried logging > with loglevel=1 and this is all I got, all suggestions and comments > appreciated. > > This is most likely a "load" related problem since we never experience this > problem in the testlab, only production.: Your log doesn't indicate any kind of crash. It only shows that a shutdown was requested, and apparently your startup scripts didn't wait for the shutdown to complete before starting again. > Apr 23 20:36:37 ldap01 slapd2.4[32233]: > bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") > Apr 23 20:36:37 ldap01 slapd2.4[32233]: => > bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") > Apr 23 20:36:37 ldap01 slapd2.4[32233]:<= bdb_dn2id: get failed: DB_NOTFOUND: > No matching key/data pair found (-30988) > Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: > "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" > Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): > Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 > > Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and > initiated. I have two Centos 5 servers running Openldap 2.4.22 with > master/master syncrepl setup, > Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 > Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 > operations/tasks to finish > Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean > shutdown detected; attempting recovery. > Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting Your config is a mess, with global directives and DB-specific directives interleaved. That may not be the cause of any specific problems, but it shows sloppiness on the part of the sysadmins. > ---------------------- Relevant Config > ------------------------------------------------ > moduleload syncprov.la > TLSCertificateFile /etc/pki/tls/private/ldap.pem > TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem > TLSCACertificateFile /etc/pki/tls/private/ldap.pem > > serverID 001 > database bdb > sizelimit 50000 > cachesize 10000 > checkpoint 256 5 > > > syncrepl rid=001 > provider=ldap://10.10.10.10:389 > bindmethod=simple > binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" > credentials=MyPassword > searchbase="o=xxxx" > schemachecking=on > sizelimit="unlimited" > timelimit="unlimited" > type=refreshAndPersist > interval=00:00:00:10 > retry="5 5 60 +" > attrs="*,+" > > mirrormode on > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > idletimeout 3600 > threads 32 > > -- -- 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#6923) ldapsearch issue
by hyc＠symas.com 30 Apr '11

30 Apr '11

michael(a)stroeder.com wrote: > charles.merrick(a)nice.com wrote: >> I am trying to execute a ldapsearch command with a -w option for password. The >> problem occurs when I have an extended ASCII char in the password like the >> British Pound symbol "£" (ascii number 163) embedded in the password string. >> Are extended ASCII chars allowed in password string? LDAP passwords are Octet Strings. It doesn't matter if your octets correspond to ASCII or any other character set, as long as the tools you use all send the exact same sequence of octets. > I guess this depends on the locale's charset configured for your console. His console at Bind time is only part of the question. The other question is what locale was in effect when the password was originally set, and what tool was used to set it. Some tools may assume you're in an 8-bit ASCII environment and do no conversion of the input characters. Some may assume you're in a UTF-8 or ISO-8859 locale and transform the characters to some other octet sequence. -- -- 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#6921) bind failure with LDAP_OPT_NETWORK_TIMEOUT
by quanah＠zimbra.com 30 Apr '11

30 Apr '11

--On Friday, April 29, 2011 5:23 AM +0000 pravat.singh(a)nsn.com wrote: > Full_Name: Pravat Singh > Version: 2.4.23 > OS: solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.131.155.20) > > > I am facing problem while in ldap_simple_bind () while setting > LDAP_OPT_NETWORK_TIMEOUT. Can anybody let me know if I am missing > something. Just to add some information that I have compiled the > openldap-2.4.23 version on solaris 10 with sun studio compiler. The bind > api ?ldap_simple_bind()? is successful if don?t use > LDAP_OPT_NETWORK_TIMEOUT but fails if I use. The ITS system is for reporting bugs, not for asking how to program. I already noted to you there are multiple examples in the OpenLDAP source code itself for using this option. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by quanah＠zimbra.com 30 Apr '11

30 Apr '11

--On Thursday, April 28, 2011 6:05 PM +0000 mslby(a)deshaw.com wrote: > Full_Name: Mark Selby > Version: 2.4.25 > OS: Solaris 10 x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.104.214) > > > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on > Solaris 10 x86 using Sun Studio. OpenLDAP is used as the backend for > generic naming services (passwd, group, netgroup etc?) as well as holding > mail routing and some custom data. We have master and slave servers and > are using syncrepl refresh and persist. Correcting the from address (mselby(a)deshaw.com is correct). I will note that there have been numerous issues IIRC reported with using Solaris 10 and OpenLDAP, due to a kernel bug in Solaris. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6923) ldapsearch issue
by michael＠stroeder.com 30 Apr '11

30 Apr '11

charles.merrick(a)nice.com wrote: > I am trying to execute a ldapsearch command with a -w option for password. The > problem occurs when I have an extended ASCII char in the password like the > British Pound symbol "£" (ascii number 163) embedded in the password string. > Are extended ASCII chars allowed in password string? I guess this depends on the locale's charset configured for your console. Ciao, Michael.

1 0

(ITS#6923) ldapsearch issue
by charles.merrick＠nice.com 29 Apr '11

29 Apr '11

Full_Name: Charles Merrick Version: 2.1.29 OS: SunOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.91.126.66) I am trying to execute a ldapsearch command with a -w option for password. The problem occurs when I have an extended ASCII char in the password like the British Pound symbol "£" (ascii number 163) embedded in the password string. Are extended ASCII chars allowed in password string? I get the following error message: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece I understand that this means that the password is invalid. For example, if I have userID "Guest_01" and password "Test" then ldapsearch will work, but if I have userID "Guest_01" and passworrd "Test_£" then ldapsearch fails with above message. I have tried putting the -w password in double quotes and with no quotes. When password is -w Test or -w"Test" it works fine but when I use -w Test£ or -w"Test£", it fails. Thank you for your assistance. I am a developer who fixes bugs and ldap stuff is new to me for maintenance.

1 0

Re: (ITS#6922) connection_read(20): no connection!
by hyc＠symas.com 29 Apr '11

29 Apr '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> The debug output shows that a read attempt was queued up for a socket that was >> closed. This is a normal occurrence when an LDAP client closes its connection >> immediately after sending its last request (Unbind here) and slapd doesn't >> have enough CPU resources to process the read attempt immediately. > > Just because of not enough CPU? Are you sure? "not enough CPU" is relative here. The socket layer receives the Unbind and close pretty much atomically, while slapd receives them as two separate events. Given that slapd *always* receives these as two separate events, it can *never* be "fast enough" to process this without at least one extraneous "no connection" occurrence. > This is a local test server on a 99% idle dual-core notebook which did not do > anything else than processing a single search and after the client received > all the results (72 entries, few short text attributes) the client sends the > unbind. Nothing else is happening. And I can reproduce it everytime. >> If you're reporting a hang with OpenLDAP, you should have said that >> explicitly. If not, then I see no bug here and this ITS will be closed. > > I'm so cautious about this because I had a situation where a slapd process (a > provider) died several times. And the last message seen in the syslog was > exactly "connection_read(20): no connection!". If you see that, run the slapd with gdb attached and get a trace when it dies. There's nothing here that indicates anything abnormal. Closing this ITS. -- -- 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#6922) connection_read(20): no connection!
by michael＠stroeder.com 29 Apr '11

29 Apr '11

hyc(a)symas.com wrote: > The debug output shows that a read attempt was queued up for a socket that was > closed. This is a normal occurrence when an LDAP client closes its connection > immediately after sending its last request (Unbind here) and slapd doesn't > have enough CPU resources to process the read attempt immediately. Just because of not enough CPU? Are you sure? This is a local test server on a 99% idle dual-core notebook which did not do anything else than processing a single search and after the client received all the results (72 entries, few short text attributes) the client sends the unbind. Nothing else is happening. And I can reproduce it everytime. > If you're reporting a hang with OpenLDAP, you should have said that > explicitly. If not, then I see no bug here and this ITS will be closed. I'm so cautious about this because I had a situation where a slapd process (a provider) died several times. And the last message seen in the syslog was exactly "connection_read(20): no connection!". Ciao, Michael.

1 0

Re: (ITS#6922) connection_read(20): no connection!
by hyc＠symas.com 29 Apr '11

29 Apr '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: 2.4.25 > OS: openSUSE Linux 11.4 > URL: > Submission from: (NULL) (84.128.243.158) > > > Currently I observe something like below in my syslog. The syslog output you included doesn't show anything unusual. Did you have an actual bug to report? > This is a simple > python-ldap (linked against OpenLDAP libs 2.4.25) script doing LDAPI connect and > unbind. I occasionally experience hangs when doing unbind also to other LDAP > servers. Your syslog output doesn't show any problem. Your debug output also doesn't show any problem. The debug output shows that a read attempt was queued up for a socket that was closed. This is a normal occurrence when an LDAP client closes its connection immediately after sending its last request (Unbind here) and slapd doesn't have enough CPU resources to process the read attempt immediately. By the time slapd gets to this event in its queue, the connection is gone. If you're reporting a hang with OpenLDAP, you should have said that explicitly. If not, then I see no bug here and this ITS will be closed. > ---------------------- debug log ---------------------- > [..private search results snipped..] > <= send_search_entry: conn 1000 exit. > send_ldap_result: conn=1000 op=0 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=1 tag=101 err=0 > ber_flush2: 14 bytes to sd 18 > 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ > ldap_write: want=14, written=14 > 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ > conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= > daemon: activity on 1 descriptor > daemon: activity on: 18r > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > daemon: activity on 1 descriptor > daemon: activity on: > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > daemon: activity on 1 descriptor > daemon: activity on: > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > connection_get(18) > connection_get(18): got connid=1000 > connection_read(18): checking for input on id=1000 > ber_get_next > ldap_read: want=8, got=7 > 0000: 30 05 02 01 02 42 00 0....B. > ber_get_next: tag 0x30 len 5 contents: > ber_dump: buf=0xe9d5a0 ptr=0xe9d5a0 end=0xe9d5a5 len=5 > 0000: 02 01 02 42 00 ...B. > op tag 0x42, time 1304096292 > ber_get_next > ldap_read: want=8, got=0 > > ber_get_next on fd 18 failed errno=0 (Success) > connection_read(18): input error=-2 id=1000, closing. > connection_closing: readying conn=1000 sd=18 for close > connection_close: deferring conn=1000 sd=18 > conn=1000 op=1 do_unbind > conn=1000 op=1 UNBIND > connection_resched: attempting closing conn=1000 sd=18 > connection_close: conn=1000 sd=18 > =>ldap_back_conn_destroy: fetching conn 1000 > daemon: removing 18 > conn=1000 fd=18 closed > connection_get(18) > connection_get(18): connection not used > connection_read(18): no connection! > connection_read(18) error > connection_get(18) > connection_get(18): connection not used > connection_read(18): no connection! > connection_read(18) error > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > > -- -- 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#6922) connection_read(20): no connection!
by michael＠stroeder.com 29 Apr '11

29 Apr '11

Full_Name: Michael Ströder Version: 2.4.25 OS: openSUSE Linux 11.4 URL: Submission from: (NULL) (84.128.243.158) Currently I observe something like below in my syslog. This is a simple python-ldap (linked against OpenLDAP libs 2.4.25) script doing LDAPI connect and unbind. I occasionally experience hangs when doing unbind also to other LDAP servers. ---------------------- syslog ---------------------- Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 fd=20 ACCEPT from PATH=/tmp/openldap-socket (PATH=/tmp/openldap-socket) Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SRCH base="dc=stroeder,dc=de" scope=2 deref=0 filter="(dateOfBirth=*)" Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SRCH attr=telephoneNumber cn mobile dateOfBirth mail homePhone Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=1 UNBIND Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 fd=20 closed ---------------------- syslog ---------------------- ---------------------- debug log ---------------------- [..private search results snipped..] <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=101 err=0 ber_flush2: 14 bytes to sd 18 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= daemon: activity on 1 descriptor daemon: activity on: 18r daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(18) connection_get(18): got connid=1000 connection_read(18): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xe9d5a0 ptr=0xe9d5a0 end=0xe9d5a5 len=5 0000: 02 01 02 42 00 ...B. op tag 0x42, time 1304096292 ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 18 failed errno=0 (Success) connection_read(18): input error=-2 id=1000, closing. connection_closing: readying conn=1000 sd=18 for close connection_close: deferring conn=1000 sd=18 conn=1000 op=1 do_unbind conn=1000 op=1 UNBIND connection_resched: attempting closing conn=1000 sd=18 connection_close: conn=1000 sd=18 =>ldap_back_conn_destroy: fetching conn 1000 daemon: removing 18 conn=1000 fd=18 closed connection_get(18) connection_get(18): connection not used connection_read(18): no connection! connection_read(18) error connection_get(18) connection_get(18): connection not used connection_read(18): no connection! connection_read(18) error daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 29 Apr '11

29 Apr '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Note that with assertion control always >> Operations error: "unique_search failed" >> is returned even if the attribute values are unique. >> >> I'd really like to get this solved. web2ldap makes use of the assertion >> control to ensure that an entry has not been changed since being >> edited by the >> user. Otherwise I have to implement another vendor-specific hack >> switching off >> this feature when OpenLDAP is used as server. :-( > > First step toward a solution would be providing slapd -d output for the > problem. Probably a sample config would help too. (Sigh! Did anybody actually read through my report?) Take any slapd.conf with database hdb and add these lines (no other overlays configured): overlay unique unique_attributes uid uidNumber employeeNumber Or any other LDAP-URL-based unique constraint... Then apply a LDIF change record (example below) which contains any of the attributes defined as unique (no matter whether unique constraint is violated or not). ------------------------------- snip ------------------------------- dn: cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local changetype: modify replace: employeeNumber employeeNumber: 456 - ------------------------------- snip ------------------------------- Try these commands (bind-DN is the rootdn here): Without assertion control it works: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" Assertion control just contains objectClass filter: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(objectClass=*)' modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" This fails: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(cn=*)'modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" ldap_modify: Operations error (1) additional info: unique_search failed Output of slapd -d config,stats,stats2,acl,args,trace,sync: ------------------------------- snip ------------------------------- [..] conn=1000 op=1 modifications: replace: employeeNumber one value, length 3 conn=1000 op=1 MOD dn="cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" conn=1000 op=1 MOD attr=employeeNumber bdb_dn2entry("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local") => hdb_dn2id("ou=users,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: got id=0x6 => hdb_dn2id("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: got id=0xd entry_decode: "" <= entry_decode() ==> unique_modify <cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local> ==> unique_search (|(employeeNumber=456)) put_filter: "(|(employeeNumber=456))" put_filter: OR put_filter_list "(employeeNumber=456)" put_filter: "(employeeNumber=456)" put_filter: simple put_simple_filter: "employeeNumber=456" ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=schulung,dc=stroeder,dc=local") => access_allowed: search access to "ou=schulung,dc=stroeder,dc=local" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "ou=schulung,dc=stroeder,dc=local" "cn" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=122 matched="" text="" send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=1 matched="" text="unique_search failed" send_ldap_response: msgid=2 tag=103 err=1 ber_flush2: 34 bytes to sd 16 conn=1000 op=1 RESULT tag=103 err=1 text=unique_search failed connection_get(16) connection_get(16): got connid=1000 connection_read(16): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1304069972 ber_get_next ber_get_next on fd 16 failed errno=0 (Success) conn=1000 op=2 do_unbind conn=1000 op=2 UNBIND connection_close: conn=1000 sd=16 conn=1000 fd=16 closed ------------------------------- snip -------------------------------

1 0

(ITS#6921) bind failure with LDAP_OPT_NETWORK_TIMEOUT
by pravat.singh＠nsn.com 28 Apr '11

28 Apr '11

Full_Name: Pravat Singh Version: 2.4.23 OS: solaris 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.131.155.20) I am facing problem while in ldap_simple_bind () while setting LDAP_OPT_NETWORK_TIMEOUT. Can anybody let me know if I am missing something. Just to add some information that I have compiled the openldap-2.4.23 version on solaris 10 with sun studio compiler. The bind api ldap_simple_bind() is successful if dont use LDAP_OPT_NETWORK_TIMEOUT but fails if I use. >From my application bind() method I am using the following apis struct timeval tempTime; tempTime.tv_usec = 0; tempTime.tv_sec = 10; ldap_init((char*)theHost.c_str(), thePort); ldap_set_option(theLDAP, LDAP_OPT_PROTOCOL_VERSION, &desired_version); ldap_set_option(theLDAP, LDAP_OPT_DEREF, &desired_deref); ldap_set_option( theLDAP, LDAP_OPT_NETWORK_TIMEOUT, (void *)&tempTime ); ldap_simple_bind(theLDAP, (char*)theUserDN, (char*)theUserPW); here I am getting a bind failure and from openldap library in ldap_sasl_bind() of libldap_r/sasl.c where the following code fails and ld->ld_errno returns -1 /* send the message */ *msgidp = ldap_send_initial_request( ld, LDAP_REQ_BIND, dn, ber, id ); /liblber/sockbuf.c ------------------- Where ber_sockbuf_ctrl( Sockbuf *sb, int opt, void *arg ) function with opt=LBER_SB_OPT_GET_FD fails with sb->sb_fd is AC_SOCKET_INVALID. Could anybody help me to know if I am missing anything here or it is required to set any other ldap options or any compilation flag is required to be used for using LDAP_OPT_NETWORK_TIMEOUT).

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by hyc＠symas.com 28 Apr '11

28 Apr '11

michael(a)stroeder.com wrote: > Note that with assertion control always > Operations error: "unique_search failed" > is returned even if the attribute values are unique. > > I'd really like to get this solved. web2ldap makes use of the assertion > control to ensure that an entry has not been changed since being edited by the > user. Otherwise I have to implement another vendor-specific hack switching off > this feature when OpenLDAP is used as server. :-( First step toward a solution would be providing slapd -d output for the problem. Probably a sample config would help too. > Ciao, Michael. > > michael(a)stroeder.com wrote: >> Further observations show that... >> >> 1. processing add requests seems to behave like expected. >> >> 2. it depends on the assertion filter sent in the control value: >> >> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f >> uidnumber_clash.ldif -e 'assert=(cn=*)' >> modifying entry "uid=ttester,dc=stroeder,dc=de" >> ldap_modify: Operations error (1) >> additional info: unique_search failed >> >> $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f >> uidnumber_clash.ldif -e 'assert=(objectClass=*)' >> modifying entry "uid=ttester,dc=stroeder,dc=de" >> ldap_modify: Constraint violation (19) >> additional info: some attributes not unique > > > -- -- 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#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by mslby＠deshaw.com 28 Apr '11

28 Apr '11

Full_Name: Mark Selby Version: 2.4.25 OS: Solaris 10 x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.77.104.214) My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming services (passwd, group, netgroup etc?) as well as holding mail routing and some custom data. We have master and slave servers and are using syncrepl refresh and persist. Lately we have been experiencing hangs with slapd and I cannot figure out what the cause is. Things will be humming along and then slapd will simply stop accepting connections and answering any requests for reads/writes. We have set the loglevel to 256 and there is nothing in the logs that indicates what the issue it. At the time that the process goes catatonic all syslogs from slapd stop I have not found a way to reproduce this on demand. Today we have had three hangs and the truss ouput is exactly the same on all process. Once the slapd process gets in this state a simple kill does not work. The syslog always says that slapd is waiting for tasks to complete but this never happens. I need to kill -9 the pid. I am going to include all of the debug info that I have collected and hopefully someone will have some idea what is going on. I also have a gcore of the process if anyone wants and info from that All and any help is greatly appreciated ########### # version # ########### @(#) $OpenLDAP: slapd 2.4.25 (Mar 28 2011 16:47:13) $ Included static backends: config ldif monitor bdb hdb ldap relay ############# # DB_CONFIG # ############# set_cachesize 0 1073741824 1 ########################### # db parts of slapd.conf # ########################### cachesize 100000 checkpoint 512 720 ################ # truss output # ################ 12612/17: lwp_cond_wait(0xFFFFFD7FFC8B2C38, 0xFFFFFD7FFC8B2C20, 0x00000000, 1) (sleeping...) 12612/10: lwp_cond_wait(0xFFFFFD7FFC8B41C8, 0xFFFFFD7FFC8B41B0, 0x00000000, 1) (sleeping...) 12612/2: pollsys(0xFFFFFD7FBB3FE510, 59, 0xFFFFFD7FBB3FF290, 0x00000000) (sleeping...) 12612/15: lwp_cond_wait(0xFFFFFD7FFC8ABF78, 0xFFFFFD7FFC8ABF60, 0x00000000, 1) (sleeping...) 12612/14: lwp_cond_wait(0xFFFFFD7FFC895610, 0xFFFFFD7FFC8955F8, 0x00000000, 1) (sleeping...) 12612/16: lwp_cond_wait(0xFFFFFD7FFC86DA70, 0xFFFFFD7FFC86DA58, 0x00000000, 1) (sleeping...) 12612/18: lwp_cond_wait(0xFFFFFD7FFC888B18, 0xFFFFFD7FFC888B00, 0x00000000, 1) (sleeping...) 12612/1: lwp_wait(2, 0xFFFFFD7FFFDFFBE4) (sleeping...) 12612/8: lwp_cond_wait(0xFFFFFD7FFC8C7BD8, 0xFFFFFD7FFC8C7BC0, 0x00000000, 1) (sleeping...) 12612/6: lwp_cond_wait(0xFFFFFD7FFC8AFF38, 0xFFFFFD7FFC8AFF20, 0x00000000, 1) (sleeping...) 12612/3: lwp_cond_wait(0xFFFFFD7FFC8B0208, 0xFFFFFD7FFC8B01F0, 0x00000000, 1) (sleeping...) 12612/12: lwp_cond_wait(0xFFFFFD7FFC8B0118, 0xFFFFFD7FFC8B0100, 0x00000000, 1) (sleeping...) 12612/7: lwp_cond_wait(0xFFFFFD7FFC918A10, 0xFFFFFD7FFC9189F8, 0x00000000, 1) (sleeping...) 12612/11: lwp_cond_wait(0xFFFFFD7FFC7055C0, 0xFFFFFD7FFC7055A8, 0x00000000, 1) (sleeping...) 12612/13: lwp_cond_wait(0xFFFFFD7FFC901F40, 0xFFFFFD7FFC901F28, 0x00000000, 1) (sleeping...) 12612/5: lwp_cond_wait(0xFFFFFD7FFC8BCC10, 0xFFFFFD7FFC8BCBF8, 0x00000000, 1) (sleeping...) 12612/9: lwp_cond_wait(0xFFFFFD7FFC8684A8, 0xFFFFFD7FFC868490, 0x00000000, 1) (sleeping...) 12612/4: lwp_cond_wait(0xFFFFFD7FFC86C7B0, 0xFFFFFD7FFC86C798, 0x00000000, 1) (sleeping...) ################ # db_stat -C A # ################ Default locking region information: 323 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 80 Number of lock object partitions 60 Number of current locks 795 Maximum number of locks at any one time 17 Maximum number of locks in any one bucket 38 Maximum number of locks stolen by for an empty partition 12 Maximum number of locks stolen for any one partition 333 Number of current lockers 333 Maximum number of lockers at any one time 40 Number of current lock objects 457 Maximum number of lock objects at any one time 4 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 20686M Total number of locks requested (20686026845) 20686M Total number of locks released (20686020297) 0 Total number of locks upgraded 34 Total number of locks downgraded 6904 Lock requests not available due to conflicts, for which we waited 6439 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 776KB The size of the lock region 243M The number of partition locks that required waiting (0%) 74M The maximum number of times any partition lock was waited for (4%) 1 The number of object queue operations that required waiting (0%) 21M The number of locker allocations that required waiting (1%) 0 The number of region locks that required waiting (0%) 4 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /var/openldap/nyc.deshaw.com/data/__db.005 Region name 0xfffffd7ffc13d000 Region address 0xfffffd7ffc13d138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 3002 2KB 0 4KB 0 8KB 1 16KB 0 32KB 2 64KB 0 128KB 1 256KB 0 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 131101 Lock region region mutex [0/58970 0% 16074/1] 1031 locker table size 1031 object table size 944 obj_off 114072 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- b dd=331 locks held 1 write locks 0 pid/thread 12612/1 b READ 1 HELD id2entry.bdb handle 0 c dd=330 locks held 0 write locks 0 pid/thread 12612/1 d dd=329 locks held 1 write locks 0 pid/thread 12612/1 d READ 1 HELD dn2id.bdb handle 0 e dd=328 locks held 0 write locks 0 pid/thread 12612/1 f dd=327 locks held 0 write locks 0 pid/thread 12612/1 10 dd=324 locks held 0 write locks 0 pid/thread 12612/1 11 dd=321 locks held 0 write locks 0 pid/thread 12612/5 12 dd=320 locks held 1 write locks 0 pid/thread 12612/5 12 READ 1 HELD objectClass.bdb handle 0 13 dd=319 locks held 0 write locks 0 pid/thread 12612/5 14 dd=318 locks held 0 write locks 0 pid/thread 12612/5 15 dd=317 locks held 0 write locks 0 pid/thread 12612/5 16 dd=316 locks held 1 write locks 0 pid/thread 12612/5 16 READ 1 HELD cn.bdb handle 0 17 dd=315 locks held 0 write locks 0 pid/thread 12612/5 18 dd=314 locks held 0 write locks 0 pid/thread 12612/5 19 dd=313 locks held 1 write locks 0 pid/thread 12612/5 19 READ 1 HELD ipServiceProtocol.bdb handle 0 1a dd=312 locks held 0 write locks 0 pid/thread 12612/5 1b dd=311 locks held 0 write locks 0 pid/thread 12612/5 1c dd=310 locks held 0 write locks 0 pid/thread 12612/5 1d dd=309 locks held 0 write locks 0 pid/thread 12612/5 1e dd=308 locks held 0 write locks 0 pid/thread 12612/5 1f dd=307 locks held 0 write locks 0 pid/thread 12612/5 20 dd=306 locks held 0 write locks 0 pid/thread 12612/5 21 dd=305 locks held 0 write locks 0 pid/thread 12612/5 22 dd=303 locks held 1 write locks 0 pid/thread 12612/3 22 READ 1 HELD amdKey.bdb handle 0 23 dd=302 locks held 0 write locks 0 pid/thread 12612/3 24 dd=301 locks held 0 write locks 0 pid/thread 12612/3 25 dd=300 locks held 0 write locks 0 pid/thread 12612/3 26 dd=299 locks held 0 write locks 0 pid/thread 12612/4 27 dd=297 locks held 0 write locks 0 pid/thread 12612/4 28 dd=295 locks held 0 write locks 0 pid/thread 12612/7 29 dd=294 locks held 0 write locks 0 pid/thread 12612/7 2a dd=293 locks held 1 write locks 0 pid/thread 12612/4 2a READ 1 HELD uidNumber.bdb handle 0 2b dd=292 locks held 0 write locks 0 pid/thread 12612/4 2c dd=291 locks held 0 write locks 0 pid/thread 12612/4 2d dd=290 locks held 0 write locks 0 pid/thread 12612/6 2e dd=289 locks held 0 write locks 0 pid/thread 12612/6 2f dd=287 locks held 0 write locks 0 pid/thread 12612/6 30 dd=286 locks held 0 write locks 0 pid/thread 12612/3 31 dd=285 locks held 0 write locks 0 pid/thread 12612/8 32 dd=284 locks held 1 write locks 0 pid/thread 12612/8 32 READ 1 HELD uid.bdb handle 0 33 dd=283 locks held 0 write locks 0 pid/thread 12612/8 34 dd=282 locks held 0 write locks 0 pid/thread 12612/8 35 dd=281 locks held 1 write locks 0 pid/thread 12612/6 35 READ 1 HELD memberUid.bdb handle 0 36 dd=280 locks held 0 write locks 0 pid/thread 12612/6 37 dd=279 locks held 0 write locks 0 pid/thread 12612/6 38 dd=278 locks held 0 write locks 0 pid/thread 12612/6 39 dd=277 locks held 0 write locks 0 pid/thread 12612/8 3a dd=276 locks held 0 write locks 0 pid/thread 12612/4 3b dd=275 locks held 0 write locks 0 pid/thread 12612/5 3c dd=274 locks held 0 write locks 0 pid/thread 12612/4 3d dd=273 locks held 1 write locks 0 pid/thread 12612/3 3d READ 1 HELD sendmailMTACluster.bdb handle 0 3e dd=272 locks held 0 write locks 0 pid/thread 12612/3 3f dd=271 locks held 0 write locks 0 pid/thread 12612/3 40 dd=270 locks held 0 write locks 0 pid/thread 12612/3 41 dd=269 locks held 1 write locks 0 pid/thread 12612/3 41 READ 1 HELD sendmailMTAHost.bdb handle 0 42 dd=268 locks held 0 write locks 0 pid/thread 12612/3 43 dd=267 locks held 0 write locks 0 pid/thread 12612/3 44 dd=266 locks held 1 write locks 0 pid/thread 12612/3 44 READ 1 HELD sendmailMTAMapName.bdb handle 0 45 dd=265 locks held 0 write locks 0 pid/thread 12612/3 46 dd=264 locks held 0 write locks 0 pid/thread 12612/3 47 dd=263 locks held 1 write locks 0 pid/thread 12612/3 47 READ 1 HELD sendmailMTAKey.bdb handle 0 48 dd=262 locks held 0 write locks 0 pid/thread 12612/3 49 dd=261 locks held 0 write locks 0 pid/thread 12612/3 4a dd=260 locks held 1 write locks 0 pid/thread 12612/7 4a READ 1 HELD sendmailMTAAliasGrouping.bdb handle 0 4b dd=259 locks held 0 write locks 0 pid/thread 12612/7 4c dd=258 locks held 0 write locks 0 pid/thread 12612/7 4d dd=257 locks held 0 write locks 0 pid/thread 12612/7 4e dd=256 locks held 0 write locks 0 pid/thread 12612/7 4f dd=255 locks held 0 write locks 0 pid/thread 12612/7 50 dd=254 locks held 0 write locks 0 pid/thread 12612/6 51 dd=253 locks held 0 write locks 0 pid/thread 12612/4 52 dd=252 locks held 0 write locks 0 pid/thread 12612/8 53 dd=251 locks held 0 write locks 0 pid/thread 12612/7 54 dd=250 locks held 0 write locks 0 pid/thread 12612/7 55 dd=249 locks held 0 write locks 0 pid/thread 12612/6 56 dd=248 locks held 0 write locks 0 pid/thread 12612/6 57 dd=247 locks held 0 write locks 0 pid/thread 12612/3 58 dd=246 locks held 0 write locks 0 pid/thread 12612/3 59 dd=245 locks held 0 write locks 0 pid/thread 12612/7 5a dd=244 locks held 0 write locks 0 pid/thread 12612/7 5b dd=243 locks held 1 write locks 0 pid/thread 12612/6 5b READ 1 HELD gidNumber.bdb handle 0 5c dd=242 locks held 0 write locks 0 pid/thread 12612/6 5d dd=241 locks held 0 write locks 0 pid/thread 12612/6 5e dd=240 locks held 0 write locks 0 pid/thread 12612/3 5f dd=239 locks held 0 write locks 0 pid/thread 12612/3 60 dd=238 locks held 1 write locks 0 pid/thread 12612/6 60 READ 1 HELD desMapName.bdb handle 0 61 dd=237 locks held 0 write locks 0 pid/thread 12612/6 62 dd=236 locks held 0 write locks 0 pid/thread 12612/6 63 dd=231 locks held 1 write locks 0 pid/thread 12612/11 63 READ 1 HELD ipServicePort.bdb handle 0 64 dd=230 locks held 0 write locks 0 pid/thread 12612/11 65 dd=229 locks held 0 write locks 0 pid/thread 12612/11 66 dd=228 locks held 0 write locks 0 pid/thread 12612/10 67 dd=227 locks held 0 write locks 0 pid/thread 12612/10 68 dd=226 locks held 0 write locks 0 pid/thread 12612/6 69 dd=225 locks held 0 write locks 0 pid/thread 12612/10 6a dd=224 locks held 0 write locks 0 pid/thread 12612/11 6b dd=223 locks held 0 write locks 0 pid/thread 12612/6 6c dd=222 locks held 0 write locks 0 pid/thread 12612/7 6d dd=221 locks held 0 write locks 0 pid/thread 12612/6 6e dd=219 locks held 0 write locks 0 pid/thread 12612/14 6f dd=218 locks held 0 write locks 0 pid/thread 12612/14 70 dd=216 locks held 0 write locks 0 pid/thread 12612/5 71 dd=215 locks held 0 write locks 0 pid/thread 12612/11 72 dd=214 locks held 0 write locks 0 pid/thread 12612/12 73 dd=212 locks held 0 write locks 0 pid/thread 12612/10 74 dd=211 locks held 0 write locks 0 pid/thread 12612/3 75 dd=210 locks held 0 write locks 0 pid/thread 12612/6 76 dd=209 locks held 0 write locks 0 pid/thread 12612/7 77 dd=206 locks held 0 write locks 0 pid/thread 12612/12 78 dd=205 locks held 0 write locks 0 pid/thread 12612/13 79 dd=203 locks held 0 write locks 0 pid/thread 12612/9 7a dd=202 locks held 0 write locks 0 pid/thread 12612/5 7b dd=201 locks held 0 write locks 0 pid/thread 12612/11 7c dd=200 locks held 0 write locks 0 pid/thread 12612/3 7d dd=199 locks held 0 write locks 0 pid/thread 12612/10 7e dd=198 locks held 0 write locks 0 pid/thread 12612/5 7f dd=197 locks held 0 write locks 0 pid/thread 12612/6 80 dd=196 locks held 0 write locks 0 pid/thread 12612/15 81 dd=195 locks held 0 write locks 0 pid/thread 12612/3 82 dd=194 locks held 0 write locks 0 pid/thread 12612/11 83 dd=193 locks held 0 write locks 0 pid/thread 12612/3 84 dd=192 locks held 0 write locks 0 pid/thread 12612/10 85 dd=191 locks held 0 write locks 0 pid/thread 12612/6 86 dd=190 locks held 0 write locks 0 pid/thread 12612/7 87 dd=189 locks held 0 write locks 0 pid/thread 12612/11 88 dd=188 locks held 0 write locks 0 pid/thread 12612/18 89 dd=187 locks held 0 write locks 0 pid/thread 12612/15 8a dd=186 locks held 0 write locks 0 pid/thread 12612/9 8b dd=185 locks held 0 write locks 0 pid/thread 12612/5 8c dd=184 locks held 0 write locks 0 pid/thread 12612/12 8d dd=183 locks held 0 write locks 0 pid/thread 12612/15 8e dd=182 locks held 0 write locks 0 pid/thread 12612/6 8f dd=181 locks held 0 write locks 0 pid/thread 12612/15 90 dd=180 locks held 0 write locks 0 pid/thread 12612/8 91 dd=179 locks held 0 write locks 0 pid/thread 12612/8 92 dd=178 locks held 0 write locks 0 pid/thread 12612/9 93 dd=177 locks held 0 write locks 0 pid/thread 12612/4 94 dd=176 locks held 0 write locks 0 pid/thread 12612/14 95 dd=175 locks held 0 write locks 0 pid/thread 12612/4 96 dd=174 locks held 0 write locks 0 pid/thread 12612/4 97 dd=173 locks held 0 write locks 0 pid/thread 12612/10 98 dd=172 locks held 0 write locks 0 pid/thread 12612/5 99 dd=171 locks held 0 write locks 0 pid/thread 12612/17 9a dd=170 locks held 0 write locks 0 pid/thread 12612/15 9b dd=169 locks held 0 write locks 0 pid/thread 12612/5 9c dd=168 locks held 0 write locks 0 pid/thread 12612/3 9d dd=167 locks held 0 write locks 0 pid/thread 12612/4 9e dd=166 locks held 1 write locks 0 pid/thread 12612/4 9e READ 1 HELD desmailKey.bdb handle 0 9f dd=165 locks held 0 write locks 0 pid/thread 12612/4 a0 dd=164 locks held 0 write locks 0 pid/thread 12612/4 a1 dd=163 locks held 0 write locks 0 pid/thread 12612/17 a2 dd=162 locks held 0 write locks 0 pid/thread 12612/17 a3 dd=161 locks held 0 write locks 0 pid/thread 12612/3 a4 dd=160 locks held 0 write locks 0 pid/thread 12612/17 a5 dd=159 locks held 0 write locks 0 pid/thread 12612/5 a6 dd=158 locks held 0 write locks 0 pid/thread 12612/5 a7 dd=157 locks held 0 write locks 0 pid/thread 12612/4 a8 dd=156 locks held 0 write locks 0 pid/thread 12612/4 a9 dd=155 locks held 0 write locks 0 pid/thread 12612/13 aa dd=154 locks held 0 write locks 0 pid/thread 12612/5 ab dd=153 locks held 0 write locks 0 pid/thread 12612/5 ac dd=152 locks held 0 write locks 0 pid/thread 12612/6 ad dd=151 locks held 0 write locks 0 pid/thread 12612/15 ae dd=150 locks held 0 write locks 0 pid/thread 12612/5 af dd=149 locks held 0 write locks 0 pid/thread 12612/10 b0 dd=148 locks held 0 write locks 0 pid/thread 12612/12 b1 dd=147 locks held 0 write locks 0 pid/thread 12612/7 b2 dd=146 locks held 0 write locks 0 pid/thread 12612/5 b3 dd=145 locks held 0 write locks 0 pid/thread 12612/14 b4 dd=144 locks held 0 write locks 0 pid/thread 12612/11 b5 dd=143 locks held 0 write locks 0 pid/thread 12612/9 b6 dd=142 locks held 0 write locks 0 pid/thread 12612/16 b7 dd=141 locks held 0 write locks 0 pid/thread 12612/7 b8 dd=140 locks held 0 write locks 0 pid/thread 12612/11 b9 dd=139 locks held 0 write locks 0 pid/thread 12612/10 ba dd=138 locks held 0 write locks 0 pid/thread 12612/3 bb dd=137 locks held 0 write locks 0 pid/thread 12612/3 bc dd=136 locks held 0 write locks 0 pid/thread 12612/4 bd dd=135 locks held 0 write locks 0 pid/thread 12612/4 be dd=134 locks held 0 write locks 0 pid/thread 12612/6 bf dd=133 locks held 0 write locks 0 pid/thread 12612/6 c0 dd=132 locks held 0 write locks 0 pid/thread 12612/12 c1 dd=131 locks held 0 write locks 0 pid/thread 12612/12 c2 dd=130 locks held 0 write locks 0 pid/thread 12612/7 c3 dd=129 locks held 0 write locks 0 pid/thread 12612/7 c4 dd=128 locks held 0 write locks 0 pid/thread 12612/16 c5 dd=127 locks held 0 write locks 0 pid/thread 12612/16 c6 dd=126 locks held 0 write locks 0 pid/thread 12612/10 c7 dd=125 locks held 0 write locks 0 pid/thread 12612/7 c8 dd=124 locks held 0 write locks 0 pid/thread 12612/18 c9 dd=123 locks held 0 write locks 0 pid/thread 12612/6 ca dd=122 locks held 1 write locks 0 pid/thread 12612/11 ca READ 1 HELD desmiscKey.bdb handle 0 cb dd=121 locks held 0 write locks 0 pid/thread 12612/11 cc dd=120 locks held 0 write locks 0 pid/thread 12612/11 cd dd=119 locks held 1 write locks 0 pid/thread 12612/9 cd READ 1 HELD entryUUID.bdb handle 0 ce dd=118 locks held 0 write locks 0 pid/thread 12612/9 cf dd=117 locks held 0 write locks 0 pid/thread 12612/9 d0 dd=116 locks held 1 write locks 0 pid/thread 12612/9 d0 READ 1 HELD entryCSN.bdb handle 0 d1 dd=115 locks held 0 write locks 0 pid/thread 12612/9 d2 dd=114 locks held 0 write locks 0 pid/thread 12612/9 d3 dd=113 locks held 0 write locks 0 pid/thread 12612/17 d4 dd=112 locks held 0 write locks 0 pid/thread 12612/17 d5 dd=111 locks held 0 write locks 0 pid/thread 12612/5 d6 dd=110 locks held 0 write locks 0 pid/thread 12612/11 d7 dd=109 locks held 0 write locks 0 pid/thread 12612/9 d8 dd=108 locks held 0 write locks 0 pid/thread 12612/13 d9 dd=107 locks held 0 write locks 0 pid/thread 12612/3 da dd=106 locks held 0 write locks 0 pid/thread 12612/13 db dd=105 locks held 0 write locks 0 pid/thread 12612/15 dc dd=104 locks held 0 write locks 0 pid/thread 12612/16 dd dd=103 locks held 0 write locks 0 pid/thread 12612/8 de dd=102 locks held 0 write locks 0 pid/thread 12612/13 df dd=101 locks held 1 write locks 0 pid/thread 12612/17 df READ 1 HELD sendmailMTAListsyncValue.bdb handle 0 e0 dd=100 locks held 0 write locks 0 pid/thread 12612/17 e1 dd=99 locks held 0 write locks 0 pid/thread 12612/17 e2 dd=98 locks held 0 write locks 0 pid/thread 12612/17 e3 dd=97 locks held 0 write locks 0 pid/thread 12612/17 e4 dd=96 locks held 0 write locks 0 pid/thread 12612/11 e5 dd=95 locks held 0 write locks 0 pid/thread 12612/8 e6 dd=94 locks held 0 write locks 0 pid/thread 12612/13 e7 dd=93 locks held 0 write locks 0 pid/thread 12612/18 e8 dd=92 locks held 0 write locks 0 pid/thread 12612/4 e9 dd=91 locks held 0 write locks 0 pid/thread 12612/12 ea dd=90 locks held 0 write locks 0 pid/thread 12612/11 eb dd=89 locks held 0 write locks 0 pid/thread 12612/11 ec dd=88 locks held 0 write locks 0 pid/thread 12612/5 ed dd=87 locks held 0 write locks 0 pid/thread 12612/5 ee dd=86 locks held 0 write locks 0 pid/thread 12612/5 ef dd=85 locks held 0 write locks 0 pid/thread 12612/8 f0 dd=84 locks held 0 write locks 0 pid/thread 12612/8 f1 dd=83 locks held 0 write locks 0 pid/thread 12612/13 f2 dd=82 locks held 0 write locks 0 pid/thread 12612/13 f3 dd=81 locks held 0 write locks 0 pid/thread 12612/10 f4 dd=80 locks held 0 write locks 0 pid/thread 12612/4 f5 dd=79 locks held 0 write locks 0 pid/thread 12612/17 f6 dd=78 locks held 0 write locks 0 pid/thread 12612/13 f7 dd=77 locks held 0 write locks 0 pid/thread 12612/13 f8 dd=76 locks held 0 write locks 0 pid/thread 12612/13 f9 dd=75 locks held 0 write locks 0 pid/thread 12612/18 fa dd=74 locks held 0 write locks 0 pid/thread 12612/5 fb dd=73 locks held 0 write locks 0 pid/thread 12612/12 fc dd=72 locks held 0 write locks 0 pid/thread 12612/7 fd dd=71 locks held 1 write locks 0 pid/thread 12612/13 fd READ 1 HELD sendmailMTAAliasType.bdb handle 0 fe dd=70 locks held 0 write locks 0 pid/thread 12612/13 ff dd=69 locks held 0 write locks 0 pid/thread 12612/13 100 dd=68 locks held 0 write locks 0 pid/thread 12612/13 101 dd=67 locks held 0 write locks 0 pid/thread 12612/13 102 dd=66 locks held 1 write locks 0 pid/thread 12612/13 102 READ 1 HELD sendmailMTAAliasOrigin.bdb handle 0 103 dd=65 locks held 0 write locks 0 pid/thread 12612/13 104 dd=64 locks held 0 write locks 0 pid/thread 12612/13 105 dd=63 locks held 0 write locks 0 pid/thread 12612/13 106 dd=62 locks held 0 write locks 0 pid/thread 12612/13 107 dd=61 locks held 1 write locks 0 pid/thread 12612/12 107 READ 1 HELD macAddress.bdb handle 0 108 dd=60 locks held 0 write locks 0 pid/thread 12612/12 109 dd=59 locks held 0 write locks 0 pid/thread 12612/12 10a dd=58 locks held 0 write locks 0 pid/thread 12612/14 10b dd=57 locks held 0 write locks 0 pid/thread 12612/7 10c dd=56 locks held 0 write locks 0 pid/thread 12612/6 10d dd=55 locks held 0 write locks 0 pid/thread 12612/16 10e dd=54 locks held 0 write locks 0 pid/thread 12612/16 10f dd=53 locks held 0 write locks 0 pid/thread 12612/13 110 dd=52 locks held 0 write locks 0 pid/thread 12612/18 111 dd=51 locks held 0 write locks 0 pid/thread 12612/8 112 dd=50 locks held 0 write locks 0 pid/thread 12612/11 113 dd=49 locks held 1 write locks 0 pid/thread 12612/7 113 READ 1 HELD userPassword.bdb handle 0 114 dd=48 locks held 0 write locks 0 pid/thread 12612/7 115 dd=47 locks held 0 write locks 0 pid/thread 12612/7 116 dd=46 locks held 0 write locks 0 pid/thread 12612/7 117 dd=45 locks held 0 write locks 0 pid/thread 12612/7 118 dd=44 locks held 0 write locks 0 pid/thread 12612/18 119 dd=43 locks held 1 write locks 0 pid/thread 12612/13 119 READ 1 HELD sn.bdb handle 0 11a dd=42 locks held 0 write locks 0 pid/thread 12612/13 11b dd=41 locks held 0 write locks 0 pid/thread 12612/13 11c dd=40 locks held 0 write locks 0 pid/thread 12612/13 11d dd=39 locks held 0 write locks 0 pid/thread 12612/13 11e dd=38 locks held 1 write locks 0 pid/thread 12612/4 11e READ 1 HELD oncRpcNumber.bdb handle 0 11f dd=37 locks held 0 write locks 0 pid/thread 12612/4 120 dd=36 locks held 0 write locks 0 pid/thread 12612/4 121 dd=35 locks held 1 write locks 0 pid/thread 12612/3 121 READ 1 HELD automountKey.bdb handle 0 122 dd=34 locks held 0 write locks 0 pid/thread 12612/3 123 dd=33 locks held 1 write locks 0 pid/thread 12612/13 123 READ 1 HELD ou.bdb handle 0 124 dd=32 locks held 0 write locks 0 pid/thread 12612/13 125 dd=31 locks held 0 write locks 0 pid/thread 12612/13 126 dd=30 locks held 0 write locks 0 pid/thread 12612/18 127 dd=29 locks held 0 write locks 0 pid/thread 12612/12 128 dd=28 locks held 0 write locks 0 pid/thread 12612/5 129 dd=27 locks held 0 write locks 0 pid/thread 12612/13 12a dd=26 locks held 0 write locks 0 pid/thread 12612/13 12b dd=25 locks held 0 write locks 0 pid/thread 12612/6 12c dd=24 locks held 0 write locks 0 pid/thread 12612/6 12d dd=23 locks held 0 write locks 0 pid/thread 12612/8 12e dd=22 locks held 0 write locks 0 pid/thread 12612/8 12f dd=21 locks held 0 write locks 0 pid/thread 12612/4 130 dd=20 locks held 0 write locks 0 pid/thread 12612/4 131 dd=19 locks held 0 write locks 0 pid/thread 12612/13 132 dd=18 locks held 0 write locks 0 pid/thread 12612/13 133 dd=17 locks held 0 write locks 0 pid/thread 12612/4 134 dd=16 locks held 0 write locks 0 pid/thread 12612/14 135 dd=15 locks held 0 write locks 0 pid/thread 12612/14 136 dd=14 locks held 0 write locks 0 pid/thread 12612/14 137 dd=13 locks held 0 write locks 0 pid/thread 12612/8 138 dd=12 locks held 0 write locks 0 pid/thread 12612/8 139 dd=11 locks held 0 write locks 0 pid/thread 12612/17 13a dd=10 locks held 0 write locks 0 pid/thread 12612/16 13b dd= 9 locks held 0 write locks 0 pid/thread 12612/13 13c dd= 8 locks held 0 write locks 0 pid/thread 12612/11 13d dd= 7 locks held 0 write locks 0 pid/thread 12612/12 13e dd= 6 locks held 0 write locks 0 pid/thread 12612/17 13f dd= 5 locks held 0 write locks 0 pid/thread 12612/8 140 dd= 4 locks held 0 write locks 0 pid/thread 12612/8 141 dd= 3 locks held 0 write locks 0 pid/thread 12612/3 142 dd= 2 locks held 0 write locks 0 pid/thread 12612/13 143 dd= 1 locks held 0 write locks 0 pid/thread 12612/13 80000009 dd=326 locks held 0 write locks 0 pid/thread 12612/1 8000000a dd=325 locks held 0 write locks 0 pid/thread 12612/1 8000000b dd=323 locks held 1 write locks 1 pid/thread 12612/3 8000000b WRITE 1 HELD objectClass.bdb page 4 8000000c dd=322 locks held 0 write locks 0 pid/thread 12612/5 8000000c READ 1 WAIT objectClass.bdb page 4 80000010 dd=304 locks held 0 write locks 0 pid/thread 12612/4 80000010 READ 1 WAIT objectClass.bdb page 4 80000012 dd=298 locks held 0 write locks 0 pid/thread 12612/6 80000012 READ 1 WAIT objectClass.bdb page 4 80000013 dd=296 locks held 0 write locks 0 pid/thread 12612/7 80000013 READ 1 WAIT objectClass.bdb page 4 80000015 dd=288 locks held 0 write locks 0 pid/thread 12612/8 80000015 READ 1 WAIT objectClass.bdb page 4 8000001f dd=235 locks held 0 write locks 0 pid/thread 12612/9 8000001f READ 1 WAIT objectClass.bdb page 4 80000020 dd=234 locks held 0 write locks 0 pid/thread 12612/10 80000020 READ 1 WAIT objectClass.bdb page 4 80000021 dd=233 locks held 0 write locks 0 pid/thread 12612/11 80000021 READ 1 WAIT objectClass.bdb page 4 80000022 dd=232 locks held 0 write locks 0 pid/thread 12612/12 80000022 READ 1 WAIT objectClass.bdb page 4 80000024 dd=220 locks held 0 write locks 0 pid/thread 12612/14 80000024 READ 1 WAIT objectClass.bdb page 4 80000025 dd=217 locks held 0 write locks 0 pid/thread 12612/13 80000025 READ 1 WAIT objectClass.bdb page 4 80000026 dd=213 locks held 0 write locks 0 pid/thread 12612/15 80000026 READ 1 WAIT objectClass.bdb page 4 80000027 dd=208 locks held 0 write locks 0 pid/thread 12612/16 80000027 READ 1 WAIT objectClass.bdb page 4 80000028 dd=207 locks held 0 write locks 0 pid/thread 12612/17 80000028 READ 1 WAIT objectClass.bdb page 4 80000029 dd=204 locks held 0 write locks 0 pid/thread 12612/18 80000029 READ 1 WAIT objectClass.bdb page 4 8001cccd dd= 0 locks held 2 write locks 0 pid/thread 12612/3 8001cccd READ 1 HELD 0x464b0 len: 9 data: 0x620x7100000000000000 8001cccd READ 1 HELD 0x540b8 len: 9 data: 0xcf0x1d0x01000000000000 8001ccce dd= 0 locks held 11 write locks 5 pid/thread 12612/3 8001ccce READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 HELD objectClass.bdb page 3 8001ccce READ 1 HELD dn2id.bdb page 8 8001ccce WRITE 2 HELD dn2id.bdb page 1595 8001ccce READ 2 HELD dn2id.bdb page 1595 8001ccce WRITE 2 HELD dn2id.bdb page 2520 8001ccce READ 2 HELD dn2id.bdb page 2520 8001ccce WRITE 2 HELD dn2id.bdb page 2601 8001ccce READ 2 HELD dn2id.bdb page 2601 8001ccce WRITE 2 HELD dn2id.bdb page 3106 8001ccce READ 1 HELD dn2id.bdb page 3106 8001ccce WRITE 4 HELD dn2id.bdb page 3901 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 119 READ 1 HELD sn.bdb handle 0 d READ 1 HELD dn2id.bdb handle 0 8001ccce READ 1 HELD dn2id.bdb page 8 8001ccce READ 1 HELD dn2id.bdb page 3106 8001ccce WRITE 2 HELD dn2id.bdb page 3106 5b READ 1 HELD gidNumber.bdb handle 0 47 READ 1 HELD sendmailMTAKey.bdb handle 0 121 READ 1 HELD automountKey.bdb handle 0 ca READ 1 HELD desmiscKey.bdb handle 0 11e READ 1 HELD oncRpcNumber.bdb handle 0 3d READ 1 HELD sendmailMTACluster.bdb handle 0 35 READ 1 HELD memberUid.bdb handle 0 8001ccce WRITE 4 HELD dn2id.bdb page 3901 cd READ 1 HELD entryUUID.bdb handle 0 113 READ 1 HELD userPassword.bdb handle 0 b READ 1 HELD id2entry.bdb handle 0 22 READ 1 HELD amdKey.bdb handle 0 107 READ 1 HELD macAddress.bdb handle 0 60 READ 1 HELD desMapName.bdb handle 0 32 READ 1 HELD uid.bdb handle 0 44 READ 1 HELD sendmailMTAMapName.bdb handle 0 102 READ 1 HELD sendmailMTAAliasOrigin.bdb handle 0 fd READ 1 HELD sendmailMTAAliasType.bdb handle 0 8001ccce READ 2 HELD dn2id.bdb page 2601 8001ccce WRITE 2 HELD dn2id.bdb page 2601 8001ccce READ 2 HELD dn2id.bdb page 1595 8001ccce WRITE 2 HELD dn2id.bdb page 1595 8000000b WRITE 1 HELD objectClass.bdb page 4 80000015 READ 1 WAIT objectClass.bdb page 4 8000000c READ 1 WAIT objectClass.bdb page 4 8000001f READ 1 WAIT objectClass.bdb page 4 80000026 READ 1 WAIT objectClass.bdb page 4 80000012 READ 1 WAIT objectClass.bdb page 4 80000025 READ 1 WAIT objectClass.bdb page 4 80000021 READ 1 WAIT objectClass.bdb page 4 80000027 READ 1 WAIT objectClass.bdb page 4 80000022 READ 1 WAIT objectClass.bdb page 4 80000028 READ 1 WAIT objectClass.bdb page 4 80000013 READ 1 WAIT objectClass.bdb page 4 80000020 READ 1 WAIT objectClass.bdb page 4 80000010 READ 1 WAIT objectClass.bdb page 4 80000029 READ 1 WAIT objectClass.bdb page 4 80000024 READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 HELD objectClass.bdb page 3 12 READ 1 HELD objectClass.bdb handle 0 16 READ 1 HELD cn.bdb handle 0 8001cccd READ 1 HELD 0x540b8 len: 9 data: 0xcf0x1d0x01000000000000 df READ 1 HELD sendmailMTAListsyncValue.bdb handle 0 9e READ 1 HELD desmailKey.bdb handle 0 41 READ 1 HELD sendmailMTAHost.bdb handle 0 8001ccce READ 2 HELD dn2id.bdb page 2520 8001ccce WRITE 2 HELD dn2id.bdb page 2520 8001cccd READ 1 HELD 0x464b0 len: 9 data: 0x620x7100000000000000 63 READ 1 HELD ipServicePort.bdb handle 0 4a READ 1 HELD sendmailMTAAliasGrouping.bdb handle 0 2a READ 1 HELD uidNumber.bdb handle 0 d0 READ 1 HELD entryCSN.bdb handle 0 19 READ 1 HELD ipServiceProtocol.bdb handle 0 123 READ 1 HELD ou.bdb handle 0 ########## # pfiles # ########## 12612: /usr/local/pkgs/openldap-2.4.25/libexec/slapd -u ldap -g ldap -h ldap: Current rlimit: 16384 file descriptors 0: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 1: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 2: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 3: S_IFDOOR mode:0444 dev:295,0 ino:87 uid:0 gid:0 size:0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[16774] /var/run/name_service_door 4: S_IFCHR mode:0000 dev:286,0 ino:46256 uid:0 gid:0 rdev:21,90918 O_WRONLY|O_LARGEFILE FD_CLOEXEC /devices/pseudo/log@0:conslog 5: S_IFIFO mode:0000 dev:284,0 ino:64519629 uid:0 gid:0 size:0 O_RDWR 6: S_IFIFO mode:0000 dev:284,0 ino:64519629 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK 7: S_IFSOCK mode:0666 dev:293,0 ino:19448 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET6 :: port: 389 8: S_IFSOCK mode:0666 dev:293,0 ino:19912 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 389 9: S_IFSOCK mode:0666 dev:293,0 ino:41938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET6 :: port: 636 10: S_IFSOCK mode:0666 dev:293,0 ino:15348 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 636 11: S_IFREG mode:0644 dev:181,65539 ino:135521 uid:5202 gid:5202 size:4096 O_RDWR|O_CREAT|O_LARGEFILE /var/openldap/nyc.deshaw.com/data/alock 12: S_IFREG mode:0600 dev:181,65539 ino:135532 uid:5202 gid:5202 size:196657152 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/id2entry.bdb 13: S_IFREG mode:0600 dev:181,65539 ino:135528 uid:5202 gid:5202 size:52404224 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/dn2id.bdb 14: S_IFSOCK mode:0666 dev:293,0 ino:63587 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC SOCK_STREAM SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 59160 peername: AF_INET 149.77.10.1 port: 389 15: S_IFSOCK mode:0666 dev:293,0 ino:43942 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59986 16: S_IFSOCK mode:0666 dev:293,0 ino:17402 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 34188 17: S_IFREG mode:0600 dev:181,65539 ino:135539 uid:5202 gid:5202 size:4055040 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/objectClass.bdb 18: S_IFREG mode:0600 dev:181,65539 ino:135524 uid:5202 gid:5202 size:10395648 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/cn.bdb 19: S_IFREG mode:0600 dev:181,65539 ino:135534 uid:5202 gid:5202 size:65536 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ipServiceProtocol.bdb 20: S_IFSOCK mode:0666 dev:293,0 ino:19785 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 38338 21: S_IFSOCK mode:0666 dev:293,0 ino:33499 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.164 port: 52543 22: S_IFREG mode:0600 dev:181,65539 ino:135522 uid:5202 gid:5202 size:262144 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/amdKey.bdb 23: S_IFSOCK mode:0666 dev:293,0 ino:49461 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 24: S_IFSOCK mode:0666 dev:293,0 ino:29568 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 48334 25: S_IFSOCK mode:0666 dev:293,0 ino:38152 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59374 26: S_IFREG mode:0600 dev:181,65539 ino:135551 uid:5202 gid:5202 size:262144 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/uid.bdb 27: S_IFREG mode:0600 dev:181,65539 ino:135538 uid:5202 gid:5202 size:548864 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/memberUid.bdb 28: S_IFREG mode:0600 dev:181,65539 ino:135552 uid:5202 gid:5202 size:229376 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/uidNumber.bdb 29: S_IFSOCK mode:0666 dev:293,0 ino:2434 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59375 30: S_IFSOCK mode:0666 dev:293,0 ino:23938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43092 31: S_IFSOCK mode:0666 dev:293,0 ino:33275 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 37641 32: S_IFSOCK mode:0666 dev:293,0 ino:26310 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 38904 33: S_IFREG mode:0600 dev:181,65539 ino:135545 uid:5202 gid:5202 size:1359872 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTACluster.bdb 34: S_IFREG mode:0600 dev:181,65539 ino:135546 uid:5202 gid:5202 size:8192 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAHost.bdb 35: S_IFREG mode:0600 dev:181,65539 ino:135549 uid:5202 gid:5202 size:663552 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAMapName.bdb 36: S_IFREG mode:0600 dev:181,65539 ino:135547 uid:5202 gid:5202 size:2162688 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAKey.bdb 37: S_IFREG mode:0600 dev:181,65539 ino:135542 uid:5202 gid:5202 size:565248 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasGrouping.bdb 38: S_IFREG mode:0600 dev:181,65539 ino:135531 uid:5202 gid:5202 size:393216 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/gidNumber.bdb 39: S_IFSOCK mode:0666 dev:293,0 ino:17403 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59378 40: S_IFSOCK mode:0666 dev:293,0 ino:35237 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 47550 41: S_IFSOCK mode:0666 dev:293,0 ino:16350 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43152 42: S_IFSOCK mode:0666 dev:293,0 ino:14601 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 38324 43: S_IFSOCK mode:0666 dev:293,0 ino:15818 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43156 44: S_IFSOCK mode:0666 dev:293,0 ino:20675 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43153 45: S_IFSOCK mode:0666 dev:293,0 ino:16337 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 35520 46: S_IFSOCK mode:0666 dev:293,0 ino:25798 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 33501 47: S_IFSOCK mode:0666 dev:293,0 ino:9812 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 48: S_IFSOCK mode:0666 dev:293,0 ino:41267 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 49: S_IFSOCK mode:0666 dev:293,0 ino:35418 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 50: S_IFREG mode:0600 dev:181,65539 ino:165220 uid:5202 gid:5202 size:10485760 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/log.0000001693 51: S_IFSOCK mode:0666 dev:293,0 ino:35224 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43345 52: S_IFSOCK mode:0666 dev:293,0 ino:32036 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 52238 53: S_IFSOCK mode:0666 dev:293,0 ino:47033 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 52239 54: S_IFSOCK mode:0666 dev:293,0 ino:25757 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 55: S_IFSOCK mode:0666 dev:293,0 ino:33188 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46952 56: S_IFREG mode:0600 dev:181,65539 ino:135525 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desMapName.bdb 57: S_IFSOCK mode:0666 dev:293,0 ino:25792 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 58: S_IFSOCK mode:0666 dev:293,0 ino:2666 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 59: S_IFSOCK mode:0666 dev:293,0 ino:31202 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 60: S_IFREG mode:0600 dev:181,65539 ino:135537 uid:5202 gid:5202 size:40960 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/macAddress.bdb 61: S_IFSOCK mode:0666 dev:293,0 ino:109 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 62: S_IFSOCK mode:0666 dev:293,0 ino:49460 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 56494 63: S_IFSOCK mode:0666 dev:293,0 ino:14549 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 64: S_IFSOCK mode:0666 dev:293,0 ino:15785 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 65: S_IFSOCK mode:0666 dev:293,0 ino:18202 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 66: S_IFREG mode:0600 dev:181,65539 ino:135533 uid:5202 gid:5202 size:90112 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ipServicePort.bdb 67: S_IFSOCK mode:0666 dev:293,0 ino:61134 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 68: S_IFSOCK mode:0666 dev:293,0 ino:32793 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 69: S_IFSOCK mode:0666 dev:293,0 ino:15177 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 70: S_IFSOCK mode:0666 dev:293,0 ino:36966 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.174 port: 46335 71: S_IFSOCK mode:0666 dev:293,0 ino:38446 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 48341 72: S_IFSOCK mode:0666 dev:293,0 ino:52630 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 73: S_IFSOCK mode:0666 dev:293,0 ino:23603 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 74: S_IFSOCK mode:0666 dev:293,0 ino:35434 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 75: S_IFSOCK mode:0666 dev:293,0 ino:17400 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 76: S_IFSOCK mode:0666 dev:293,0 ino:17146 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 77: S_IFSOCK mode:0666 dev:293,0 ino:6611 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 78: S_IFSOCK mode:0666 dev:293,0 ino:65454 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.44.80 port: 45478 79: S_IFSOCK mode:0666 dev:293,0 ino:36072 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 47356 80: S_IFSOCK mode:0666 dev:293,0 ino:23126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 34315 81: S_IFSOCK mode:0666 dev:293,0 ino:35227 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.138 port: 53430 82: S_IFSOCK mode:0666 dev:293,0 ino:17401 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49626 83: S_IFSOCK mode:0666 dev:293,0 ino:44596 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 84: S_IFSOCK mode:0666 dev:293,0 ino:1812 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 85: S_IFSOCK mode:0666 dev:293,0 ino:39417 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 86: S_IFSOCK mode:0666 dev:293,0 ino:17492 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 41328 87: S_IFSOCK mode:0666 dev:293,0 ino:15128 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 88: S_IFSOCK mode:0666 dev:293,0 ino:43685 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.140 port: 37920 89: S_IFSOCK mode:0666 dev:293,0 ino:26309 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 90: S_IFSOCK mode:0666 dev:293,0 ino:28264 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 91: S_IFSOCK mode:0666 dev:293,0 ino:17542 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 92: S_IFSOCK mode:0666 dev:293,0 ino:938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 93: S_IFSOCK mode:0666 dev:293,0 ino:42650 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42415 94: S_IFSOCK mode:0666 dev:293,0 ino:19665 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 95: S_IFSOCK mode:0666 dev:293,0 ino:43128 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39733 96: S_IFSOCK mode:0666 dev:293,0 ino:16910 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 97: S_IFSOCK mode:0666 dev:293,0 ino:37339 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 98: S_IFSOCK mode:0666 dev:293,0 ino:20006 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 99: S_IFSOCK mode:0666 dev:293,0 ino:25557 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 39329 100: S_IFSOCK mode:0666 dev:293,0 ino:56649 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 101: S_IFSOCK mode:0666 dev:293,0 ino:18982 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 102: S_IFSOCK mode:0666 dev:293,0 ino:32278 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 103: S_IFSOCK mode:0666 dev:293,0 ino:18235 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 104: S_IFSOCK mode:0666 dev:293,0 ino:28594 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 105: S_IFSOCK mode:0666 dev:293,0 ino:14800 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 106: S_IFSOCK mode:0666 dev:293,0 ino:17966 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 107: S_IFSOCK mode:0666 dev:293,0 ino:22090 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 108: S_IFSOCK mode:0666 dev:293,0 ino:34027 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.36 port: 60711 109: S_IFSOCK mode:0666 dev:293,0 ino:18978 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.150 port: 53165 110: S_IFREG mode:0600 dev:181,65539 ino:135548 uid:5202 gid:5202 size:2736128 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAListsyncValue.bdb 111: S_IFSOCK mode:0666 dev:293,0 ino:19891 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 112: S_IFSOCK mode:0666 dev:293,0 ino:34944 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 113: S_IFSOCK mode:0666 dev:293,0 ino:5701 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 44998 114: S_IFSOCK mode:0666 dev:293,0 ino:42652 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39112 115: S_IFSOCK mode:0666 dev:293,0 ino:2670 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 116: S_IFSOCK mode:0666 dev:293,0 ino:46513 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 52131 117: S_IFSOCK mode:0666 dev:293,0 ino:20133 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.228 port: 48289 118: S_IFSOCK mode:0666 dev:293,0 ino:19898 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.174 port: 38366 119: S_IFSOCK mode:0666 dev:293,0 ino:33496 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 120: S_IFSOCK mode:0666 dev:293,0 ino:15916 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 121: S_IFSOCK mode:0666 dev:293,0 ino:20675 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.213 port: 48607 122: S_IFSOCK mode:0666 dev:293,0 ino:937 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 123: S_IFSOCK mode:0666 dev:293,0 ino:30209 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.242 port: 35720 124: S_IFSOCK mode:0666 dev:293,0 ino:32126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 43593 125: S_IFSOCK mode:0666 dev:293,0 ino:43681 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 126: S_IFSOCK mode:0666 dev:293,0 ino:14505 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 127: S_IFSOCK mode:0666 dev:293,0 ino:15888 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 36006 128: S_IFREG mode:0600 dev:181,65539 ino:135544 uid:5202 gid:5202 size:589824 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasType.bdb 129: S_IFSOCK mode:0666 dev:293,0 ino:43683 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 57449 130: S_IFSOCK mode:0666 dev:293,0 ino:16349 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 131: S_IFSOCK mode:0666 dev:293,0 ino:32124 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.201 port: 10026 132: S_IFSOCK mode:0666 dev:293,0 ino:23758 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39734 133: S_IFSOCK mode:0666 dev:293,0 ino:52628 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 134: S_IFSOCK mode:0666 dev:293,0 ino:41988 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.44.39 port: 36331 135: S_IFSOCK mode:0666 dev:293,0 ino:19204 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42027 136: S_IFSOCK mode:0666 dev:293,0 ino:21872 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 137: S_IFREG mode:0600 dev:181,65539 ino:135553 uid:5202 gid:5202 size:294912 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/userPassword.bdb 138: S_IFSOCK mode:0666 dev:293,0 ino:14208 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 139: S_IFSOCK mode:0666 dev:293,0 ino:17404 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 140: S_IFSOCK mode:0666 dev:293,0 ino:32795 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.9.48 port: 32789 141: S_IFSOCK mode:0666 dev:293,0 ino:29057 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 142: S_IFSOCK mode:0666 dev:293,0 ino:21253 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 143: S_IFSOCK mode:0666 dev:293,0 ino:19450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39735 144: S_IFSOCK mode:0666 dev:293,0 ino:43206 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 51744 145: S_IFSOCK mode:0666 dev:293,0 ino:57349 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39736 146: S_IFSOCK mode:0666 dev:293,0 ino:39892 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42028 147: S_IFREG mode:0600 dev:181,65539 ino:135543 uid:5202 gid:5202 size:671744 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasOrigin.bdb 148: S_IFSOCK mode:0666 dev:293,0 ino:16453 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 149: S_IFSOCK mode:0666 dev:293,0 ino:49134 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42414 150: S_IFSOCK mode:0666 dev:293,0 ino:14600 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.55.48 port: 53275 151: S_IFSOCK mode:0666 dev:293,0 ino:21874 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43168 152: S_IFSOCK mode:0666 dev:293,0 ino:41286 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39737 153: S_IFSOCK mode:0666 dev:293,0 ino:14916 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 154: S_IFSOCK mode:0666 dev:293,0 ino:17409 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 56930 155: S_IFSOCK mode:0666 dev:293,0 ino:20154 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35666 156: S_IFSOCK mode:0666 dev:293,0 ino:34681 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 157: S_IFREG mode:0600 dev:181,65539 ino:135523 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/automountKey.bdb 158: S_IFSOCK mode:0666 dev:293,0 ino:37237 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 159: S_IFSOCK mode:0666 dev:293,0 ino:42692 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 160: S_IFSOCK mode:0666 dev:293,0 ino:36760 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 161: S_IFSOCK mode:0666 dev:293,0 ino:14602 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 162: S_IFSOCK mode:0666 dev:293,0 ino:40345 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 163: S_IFSOCK mode:0666 dev:293,0 ino:20673 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43400 164: S_IFSOCK mode:0666 dev:293,0 ino:25056 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 165: S_IFSOCK mode:0666 dev:293,0 ino:19752 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 166: S_IFSOCK mode:0666 dev:293,0 ino:42553 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39738 167: S_IFSOCK mode:0666 dev:293,0 ino:21312 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 168: S_IFSOCK mode:0666 dev:293,0 ino:47141 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42796 169: S_IFSOCK mode:0666 dev:293,0 ino:21429 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 170: S_IFSOCK mode:0666 dev:293,0 ino:47140 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.121.27 port: 59433 171: S_IFSOCK mode:0666 dev:293,0 ino:57350 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 172: S_IFSOCK mode:0666 dev:293,0 ino:35613 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 173: S_IFSOCK mode:0666 dev:293,0 ino:41942 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 174: S_IFSOCK mode:0666 dev:293,0 ino:31694 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.217 port: 33509 175: S_IFSOCK mode:0666 dev:293,0 ino:36765 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.11.0.148 port: 36161 176: S_IFSOCK mode:0666 dev:293,0 ino:38156 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39739 177: S_IFSOCK mode:0666 dev:293,0 ino:63585 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 178: S_IFSOCK mode:0666 dev:293,0 ino:18243 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39740 179: S_IFSOCK mode:0666 dev:293,0 ino:15129 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 180: S_IFSOCK mode:0666 dev:293,0 ino:19892 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 181: S_IFSOCK mode:0666 dev:293,0 ino:20082 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 182: S_IFSOCK mode:0666 dev:293,0 ino:43680 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42780 183: S_IFSOCK mode:0666 dev:293,0 ino:40032 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 47042 184: S_IFREG mode:0600 dev:181,65539 ino:135550 uid:5202 gid:5202 size:1785856 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sn.bdb 185: S_IFSOCK mode:0666 dev:293,0 ino:18241 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.222 port: 53352 186: S_IFSOCK mode:0666 dev:293,0 ino:9808 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 46559 187: S_IFSOCK mode:0666 dev:293,0 ino:54886 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 188: S_IFSOCK mode:0666 dev:293,0 ino:19733 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59785 189: S_IFSOCK mode:0666 dev:293,0 ino:19891 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42773 190: S_IFSOCK mode:0666 dev:293,0 ino:31695 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 42968 191: S_IFSOCK mode:0666 dev:293,0 ino:54883 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 192: S_IFSOCK mode:0666 dev:293,0 ino:39858 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42263 193: S_IFSOCK mode:0666 dev:293,0 ino:20156 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 194: S_IFSOCK mode:0666 dev:293,0 ino:17150 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 195: S_IFSOCK mode:0666 dev:293,0 ino:35420 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37081 196: S_IFSOCK mode:0666 dev:293,0 ino:19786 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 197: S_IFSOCK mode:0666 dev:293,0 ino:15960 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42786 198: S_IFSOCK mode:0666 dev:293,0 ino:52627 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 38385 199: S_IFSOCK mode:0666 dev:293,0 ino:11403 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 200: S_IFSOCK mode:0666 dev:293,0 ino:15894 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 201: S_IFSOCK mode:0666 dev:293,0 ino:35234 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 202: S_IFSOCK mode:0666 dev:293,0 ino:17012 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 203: S_IFSOCK mode:0666 dev:293,0 ino:2438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 204: S_IFSOCK mode:0666 dev:293,0 ino:63483 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 54523 205: S_IFSOCK mode:0666 dev:293,0 ino:19933 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 206: S_IFSOCK mode:0666 dev:293,0 ino:18206 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 207: S_IFSOCK mode:0666 dev:293,0 ino:43452 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 208: S_IFSOCK mode:0666 dev:293,0 ino:14603 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43169 209: S_IFSOCK mode:0666 dev:293,0 ino:42169 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53444 210: S_IFSOCK mode:0666 dev:293,0 ino:31757 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53446 211: S_IFSOCK mode:0666 dev:293,0 ino:64212 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53448 212: S_IFSOCK mode:0666 dev:293,0 ino:42782 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.145 port: 32799 213: S_IFSOCK mode:0666 dev:293,0 ino:16342 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53450 214: S_IFSOCK mode:0666 dev:293,0 ino:17316 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53452 215: S_IFSOCK mode:0666 dev:293,0 ino:15890 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 53195 216: S_IFSOCK mode:0666 dev:293,0 ino:42780 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.164 port: 49503 217: S_IFSOCK mode:0666 dev:293,0 ino:885 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 218: S_IFREG mode:0600 dev:181,65539 ino:135527 uid:5202 gid:5202 size:147456 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desmiscKey.bdb 219: S_IFSOCK mode:0666 dev:293,0 ino:45058 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 220: S_IFSOCK mode:0666 dev:293,0 ino:21878 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.72.16 port: 42544 221: S_IFSOCK mode:0666 dev:293,0 ino:19270 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 58317 222: S_IFSOCK mode:0666 dev:293,0 ino:20674 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 53196 223: S_IFSOCK mode:0666 dev:293,0 ino:40873 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 224: S_IFSOCK mode:0666 dev:293,0 ino:31203 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 225: S_IFSOCK mode:0666 dev:293,0 ino:29294 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 34144 226: S_IFSOCK mode:0666 dev:293,0 ino:23936 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60182 227: S_IFSOCK mode:0666 dev:293,0 ino:35233 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 55970 228: S_IFSOCK mode:0666 dev:293,0 ino:15817 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 229: S_IFSOCK mode:0666 dev:293,0 ino:26811 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.143 port: 48789 230: S_IFSOCK mode:0666 dev:293,0 ino:18245 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.12 port: 44229 231: S_IFREG mode:0600 dev:181,65539 ino:135526 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desmailKey.bdb 232: S_IFSOCK mode:0666 dev:293,0 ino:18209 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46950 233: S_IFSOCK mode:0666 dev:293,0 ino:2933 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46745 234: S_IFSOCK mode:0666 dev:293,0 ino:1808 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 235: S_IFSOCK mode:0666 dev:293,0 ino:35819 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 56541 236: S_IFSOCK mode:0666 dev:293,0 ino:53314 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.121.28 port: 19711 237: S_IFSOCK mode:0666 dev:293,0 ino:32806 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.44.12 port: 61215 238: S_IFSOCK mode:0666 dev:293,0 ino:5889 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46968 239: S_IFSOCK mode:0666 dev:293,0 ino:52624 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 240: S_IFSOCK mode:0666 dev:293,0 ino:42649 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 241: S_IFSOCK mode:0666 dev:293,0 ino:32034 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 242: S_IFSOCK mode:0666 dev:293,0 ino:54880 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46970 243: S_IFSOCK mode:0666 dev:293,0 ino:18979 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.168 port: 59407 244: S_IFSOCK mode:0666 dev:293,0 ino:20157 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46746 245: S_IFSOCK mode:0666 dev:293,0 ino:41522 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46747 246: S_IFSOCK mode:0666 dev:293,0 ino:35438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 247: S_IFSOCK mode:0666 dev:293,0 ino:41284 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.237 port: 56119 248: S_IFSOCK mode:0666 dev:293,0 ino:35438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 249: S_IFSOCK mode:0666 dev:293,0 ino:53888 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 250: S_IFREG mode:0600 dev:181,65539 ino:135540 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/oncRpcNumber.bdb 251: S_IFSOCK mode:0666 dev:293,0 ino:23358 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 252: S_IFREG mode:0600 dev:181,65539 ino:135530 uid:5202 gid:5202 size:3727360 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/entryUUID.bdb 254: S_IFSOCK mode:0666 dev:293,0 ino:34685 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60180 255: S_IFSOCK mode:0666 dev:293,0 ino:18793 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.45.28 port: 51381 256: S_IFSOCK mode:0666 dev:293,0 ino:21254 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 257: S_IFREG mode:0600 dev:181,65539 ino:135529 uid:5202 gid:5202 size:19202048 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/entryCSN.bdb 258: S_IFSOCK mode:0666 dev:293,0 ino:35422 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.74 port: 32823 259: S_IFSOCK mode:0666 dev:293,0 ino:35784 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49619 260: S_IFSOCK mode:0666 dev:293,0 ino:43450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 54525 261: S_IFSOCK mode:0666 dev:293,0 ino:26304 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.45.27 port: 51371 262: S_IFSOCK mode:0666 dev:293,0 ino:18977 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 54171 263: S_IFSOCK mode:0666 dev:293,0 ino:37236 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43090 264: S_IFSOCK mode:0666 dev:293,0 ino:17964 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39096 265: S_IFSOCK mode:0666 dev:293,0 ino:18467 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 266: S_IFSOCK mode:0666 dev:293,0 ino:16010 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42788 267: S_IFSOCK mode:0666 dev:293,0 ino:35435 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59822 268: S_IFSOCK mode:0666 dev:293,0 ino:20225 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 269: S_IFSOCK mode:0666 dev:293,0 ino:32038 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42042 270: S_IFSOCK mode:0666 dev:293,0 ino:1126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 271: S_IFSOCK mode:0666 dev:293,0 ino:23605 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49627 272: S_IFSOCK mode:0666 dev:293,0 ino:42171 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 273: S_IFSOCK mode:0666 dev:293,0 ino:37693 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 274: S_IFSOCK mode:0666 dev:293,0 ino:22161 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35552 275: S_IFSOCK mode:0666 dev:293,0 ino:28632 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 276: S_IFSOCK mode:0666 dev:293,0 ino:22124 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39115 277: S_IFSOCK mode:0666 dev:293,0 ino:31347 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39116 278: S_IFSOCK mode:0666 dev:293,0 ino:37025 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 279: S_IFSOCK mode:0666 dev:293,0 ino:35228 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.204 port: 50620 280: S_IFSOCK mode:0666 dev:293,0 ino:42648 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60181 281: S_IFSOCK mode:0666 dev:293,0 ino:60569 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43403 282: S_IFSOCK mode:0666 dev:293,0 ino:20313 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 45147 283: S_IFSOCK mode:0666 dev:293,0 ino:22164 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43406 284: S_IFSOCK mode:0666 dev:293,0 ino:19448 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 285: S_IFSOCK mode:0666 dev:293,0 ino:44598 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37757 286: S_IFSOCK mode:0666 dev:293,0 ino:28744 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 287: S_IFSOCK mode:0666 dev:293,0 ino:19667 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 288: S_IFSOCK mode:0666 dev:293,0 ino:40038 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 289: S_IFSOCK mode:0666 dev:293,0 ino:35608 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 290: S_IFSOCK mode:0666 dev:293,0 ino:31693 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.244 port: 32836 291: S_IFSOCK mode:0666 dev:293,0 ino:16014 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 292: S_IFSOCK mode:0666 dev:293,0 ino:44595 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 36515 293: S_IFSOCK mode:0666 dev:293,0 ino:40037 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37639 294: S_IFSOCK mode:0666 dev:293,0 ino:20155 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 58314 295: S_IFSOCK mode:0666 dev:293,0 ino:34817 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 296: S_IFSOCK mode:0666 dev:293,0 ino:938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 297: S_IFSOCK mode:0666 dev:293,0 ino:18980 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 298: S_IFSOCK mode:0666 dev:293,0 ino:41201 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37080 299: S_IFSOCK mode:0666 dev:293,0 ino:15894 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.148 port: 62875 300: S_IFREG mode:0600 dev:181,65539 ino:135541 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ou.bdb 301: S_IFSOCK mode:0666 dev:293,0 ino:43450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 52054 302: S_IFSOCK mode:0666 dev:293,0 ino:60574 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49628 303: S_IFSOCK mode:0666 dev:293,0 ino:38153 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 49097 305: S_IFSOCK mode:0666 dev:293,0 ino:18982 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 306: S_IFSOCK mode:0666 dev:293,0 ino:47193 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37646 307: S_IFSOCK mode:0666 dev:293,0 ino:32723 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.102 port: 32798 309: S_IFSOCK mode:0666 dev:293,0 ino:8500 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 311: S_IFSOCK mode:0666 dev:293,0 ino:17011 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37647 313: S_IFSOCK mode:0666 dev:293,0 ino:28725 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35591 315: S_IFSOCK mode:0666 dev:293,0 ino:33273 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 316: S_IFSOCK mode:0666 dev:293,0 ino:35225 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37648 330: S_IFSOCK mode:0666 dev:293,0 ino:41741 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 44958 331: S_IFSOCK mode:0666 dev:293,0 ino:43200 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 40602 341: S_IFSOCK mode:0666 dev:293,0 ino:43449 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 49838 ########## # pstack # ########## 12612: /usr/local/pkgs/openldap-2.4.25/libexec/slapd -u ldap -g ldap -h ldap: ----------------- lwp# 1 / thread# 1 -------------------- fffffd7fff31ca7a lwp_wait (2, fffffd7fffdffbe4) fffffd7fff313b5e _thrp_join () + 3e fffffd7fff313d3c pthread_join () + 1c 000000000046a012 slapd_daemon () + 13a 0000657361626174 ???????? () ----------------- lwp# 2 / thread# 2 -------------------- fffffd7fff31c58a pollsys (fffffd7fbb3fe510, 44, fffffd7fbb3ff290, 0) fffffd7fff2c33a4 pselect () + 154 fffffd7fff2c3672 select () + 72 000000000046910f ???????? () 000000007c020002 ???????? () ----------------- lwp# 3 / thread# 3 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b0208, fffffd7ffc8b01f0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 4 / thread# 4 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc86c7b0, fffffd7ffc86c798, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 5 / thread# 5 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8bcc10, fffffd7ffc8bcbf8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 6 / thread# 6 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8aff38, fffffd7ffc8aff20, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 7 / thread# 7 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc918a10, fffffd7ffc9189f8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 8 / thread# 8 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8c7bd8, fffffd7ffc8c7bc0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 9 / thread# 9 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8684a8, fffffd7ffc868490, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 10 / thread# 10 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b41c8, fffffd7ffc8b41b0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 11 / thread# 11 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc7055c0, fffffd7ffc7055a8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 12 / thread# 12 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b0118, fffffd7ffc8b0100, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 13 / thread# 13 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc901f40, fffffd7ffc901f28, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 14 / thread# 14 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc895610, fffffd7ffc8955f8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 15 / thread# 15 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8abf78, fffffd7ffc8abf60, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 16 / thread# 16 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc86da70, fffffd7ffc86da58, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 17 / thread# 17 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b2c38, fffffd7ffc8b2c20, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 18 / thread# 18 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc888b18, fffffd7ffc888b00, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? ()

1 0

(ITS#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by jarl＠dallur.com 28 Apr '11

28 Apr '11

Full_Name: Jarl Stefansson Version: 2.4.22 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.15.35.75) Two servers running OpenLDAP in master/master using syncrepl, roughly once per week one of the servers stops responding to new connections, I tried logging with loglevel=1 and this is all I got, all suggestions and comments appreciated. This is most likely a "load" related problem since we never experience this problem in the testlab, only production.: Apr 23 20:36:37 ldap01 slapd2.4[32233]: bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") Apr 23 20:36:37 ldap01 slapd2.4[32233]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and initiated. I have two Centos 5 servers running Openldap 2.4.22 with master/master syncrepl setup, Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 operations/tasks to finish Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean shutdown detected; attempting recovery. Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting ---------------------- Relevant Config ------------------------------------------------ moduleload syncprov.la TLSCertificateFile /etc/pki/tls/private/ldap.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem TLSCACertificateFile /etc/pki/tls/private/ldap.pem serverID 001 database bdb sizelimit 50000 cachesize 10000 checkpoint 256 5 syncrepl rid=001 provider=ldap://10.10.10.10:389 bindmethod=simple binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" credentials=MyPassword searchbase="o=xxxx" schemachecking=on sizelimit="unlimited" timelimit="unlimited" type=refreshAndPersist interval=00:00:00:10 retry="5 5 60 +" attrs="*,+" mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 idletimeout 3600 threads 32

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 28 Apr '11

28 Apr '11

Note that with assertion control always Operations error: "unique_search failed" is returned even if the attribute values are unique. I'd really like to get this solved. web2ldap makes use of the assertion control to ensure that an entry has not been changed since being edited by the user. Otherwise I have to implement another vendor-specific hack switching off this feature when OpenLDAP is used as server. :-( Ciao, Michael. michael(a)stroeder.com wrote: > Further observations show that... > > 1. processing add requests seems to behave like expected. > > 2. it depends on the assertion filter sent in the control value: > > $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f > uidnumber_clash.ldif -e 'assert=(cn=*)' > modifying entry "uid=ttester,dc=stroeder,dc=de" > ldap_modify: Operations error (1) > additional info: unique_search failed > > $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f > uidnumber_clash.ldif -e 'assert=(objectClass=*)' > modifying entry "uid=ttester,dc=stroeder,dc=de" > ldap_modify: Constraint violation (19) > additional info: some attributes not unique

1 0

OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by Selby, Mark 28 Apr '11

28 Apr '11

My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming services (passwd, group, netgroup etc...) as well as holding mail routing and some custom data. We have master and slave servers and are using syncrepl refresh and persist. Lately we have been experiencing hangs with slapd and I cannot figure out what the cause is. Things will be humming along and then slapd will simply stop accepting connections and answering any requests for reads/writes. We have set the loglevel to 256 and there is nothing in the logs that indicates what the issue it. Today we have had three hangs and the truss ouput is exactly the same on all process. Once the slapd process gets in this state a simple kill does not work. The syslog always says that slapd is waiting for tasks to complete but this never happens. I need to kill -9 the pid. I am going to include all of the debug info that I have collected and hopefully someone will have some idea what is going on. I also have a gcore of the process if anyone wants and info from that All and any help is greatly appreciated! ########### # version # ########### @(#) $OpenLDAP: slapd 2.4.25 (Mar 28 2011 16:47:13) $ Included static backends: config ldif monitor bdb hdb ldap relay ############# # DB_CONFIG # ############# set_cachesize 0 1073741824 1 ########################### # db parts of slapd.conf # ########################### cachesize 100000 checkpoint 512 720 ################ # truss output # ################ 12612/17: lwp_cond_wait(0xFFFFFD7FFC8B2C38, 0xFFFFFD7FFC8B2C20, 0x00000000, 1) (sleeping...) 12612/10: lwp_cond_wait(0xFFFFFD7FFC8B41C8, 0xFFFFFD7FFC8B41B0, 0x00000000, 1) (sleeping...) 12612/2: pollsys(0xFFFFFD7FBB3FE510, 59, 0xFFFFFD7FBB3FF290, 0x00000000) (sleeping...) 12612/15: lwp_cond_wait(0xFFFFFD7FFC8ABF78, 0xFFFFFD7FFC8ABF60, 0x00000000, 1) (sleeping...) 12612/14: lwp_cond_wait(0xFFFFFD7FFC895610, 0xFFFFFD7FFC8955F8, 0x00000000, 1) (sleeping...) 12612/16: lwp_cond_wait(0xFFFFFD7FFC86DA70, 0xFFFFFD7FFC86DA58, 0x00000000, 1) (sleeping...) 12612/18: lwp_cond_wait(0xFFFFFD7FFC888B18, 0xFFFFFD7FFC888B00, 0x00000000, 1) (sleeping...) 12612/1: lwp_wait(2, 0xFFFFFD7FFFDFFBE4) (sleeping...) 12612/8: lwp_cond_wait(0xFFFFFD7FFC8C7BD8, 0xFFFFFD7FFC8C7BC0, 0x00000000, 1) (sleeping...) 12612/6: lwp_cond_wait(0xFFFFFD7FFC8AFF38, 0xFFFFFD7FFC8AFF20, 0x00000000, 1) (sleeping...) 12612/3: lwp_cond_wait(0xFFFFFD7FFC8B0208, 0xFFFFFD7FFC8B01F0, 0x00000000, 1) (sleeping...) 12612/12: lwp_cond_wait(0xFFFFFD7FFC8B0118, 0xFFFFFD7FFC8B0100, 0x00000000, 1) (sleeping...) 12612/7: lwp_cond_wait(0xFFFFFD7FFC918A10, 0xFFFFFD7FFC9189F8, 0x00000000, 1) (sleeping...) 12612/11: lwp_cond_wait(0xFFFFFD7FFC7055C0, 0xFFFFFD7FFC7055A8, 0x00000000, 1) (sleeping...) 12612/13: lwp_cond_wait(0xFFFFFD7FFC901F40, 0xFFFFFD7FFC901F28, 0x00000000, 1) (sleeping...) 12612/5: lwp_cond_wait(0xFFFFFD7FFC8BCC10, 0xFFFFFD7FFC8BCBF8, 0x00000000, 1) (sleeping...) 12612/9: lwp_cond_wait(0xFFFFFD7FFC8684A8, 0xFFFFFD7FFC868490, 0x00000000, 1) (sleeping...) 12612/4: lwp_cond_wait(0xFFFFFD7FFC86C7B0, 0xFFFFFD7FFC86C798, 0x00000000, 1) (sleeping...) ################ # db_stat -C A # ################ Default locking region information: 323 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 80 Number of lock object partitions 60 Number of current locks 795 Maximum number of locks at any one time 17 Maximum number of locks in any one bucket 38 Maximum number of locks stolen by for an empty partition 12 Maximum number of locks stolen for any one partition 333 Number of current lockers 333 Maximum number of lockers at any one time 40 Number of current lock objects 457 Maximum number of lock objects at any one time 4 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 20686M Total number of locks requested (20686026845) 20686M Total number of locks released (20686020297) 0 Total number of locks upgraded 34 Total number of locks downgraded 6904 Lock requests not available due to conflicts, for which we waited 6439 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 776KB The size of the lock region 243M The number of partition locks that required waiting (0%) 74M The maximum number of times any partition lock was waited for (4%) 1 The number of object queue operations that required waiting (0%) 21M The number of locker allocations that required waiting (1%) 0 The number of region locks that required waiting (0%) 4 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /var/openldap/nyc.deshaw.com/data/__db.005 Region name 0xfffffd7ffc13d000 Region address 0xfffffd7ffc13d138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 3002 2KB 0 4KB 0 8KB 1 16KB 0 32KB 2 64KB 0 128KB 1 256KB 0 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 131101 Lock region region mutex [0/58970 0% 16074/1] 1031 locker table size 1031 object table size 944 obj_off 114072 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- b dd=331 locks held 1 write locks 0 pid/thread 12612/1 b READ 1 HELD id2entry.bdb handle 0 c dd=330 locks held 0 write locks 0 pid/thread 12612/1 d dd=329 locks held 1 write locks 0 pid/thread 12612/1 d READ 1 HELD dn2id.bdb handle 0 e dd=328 locks held 0 write locks 0 pid/thread 12612/1 f dd=327 locks held 0 write locks 0 pid/thread 12612/1 10 dd=324 locks held 0 write locks 0 pid/thread 12612/1 11 dd=321 locks held 0 write locks 0 pid/thread 12612/5 12 dd=320 locks held 1 write locks 0 pid/thread 12612/5 12 READ 1 HELD objectClass.bdb handle 0 13 dd=319 locks held 0 write locks 0 pid/thread 12612/5 14 dd=318 locks held 0 write locks 0 pid/thread 12612/5 15 dd=317 locks held 0 write locks 0 pid/thread 12612/5 16 dd=316 locks held 1 write locks 0 pid/thread 12612/5 16 READ 1 HELD cn.bdb handle 0 17 dd=315 locks held 0 write locks 0 pid/thread 12612/5 18 dd=314 locks held 0 write locks 0 pid/thread 12612/5 19 dd=313 locks held 1 write locks 0 pid/thread 12612/5 19 READ 1 HELD ipServiceProtocol.bdb handle 0 1a dd=312 locks held 0 write locks 0 pid/thread 12612/5 1b dd=311 locks held 0 write locks 0 pid/thread 12612/5 1c dd=310 locks held 0 write locks 0 pid/thread 12612/5 1d dd=309 locks held 0 write locks 0 pid/thread 12612/5 1e dd=308 locks held 0 write locks 0 pid/thread 12612/5 1f dd=307 locks held 0 write locks 0 pid/thread 12612/5 20 dd=306 locks held 0 write locks 0 pid/thread 12612/5 21 dd=305 locks held 0 write locks 0 pid/thread 12612/5 22 dd=303 locks held 1 write locks 0 pid/thread 12612/3 22 READ 1 HELD amdKey.bdb handle 0 23 dd=302 locks held 0 write locks 0 pid/thread 12612/3 24 dd=301 locks held 0 write locks 0 pid/thread 12612/3 25 dd=300 locks held 0 write locks 0 pid/thread 12612/3 26 dd=299 locks held 0 write locks 0 pid/thread 12612/4 27 dd=297 locks held 0 write locks 0 pid/thread 12612/4 28 dd=295 locks held 0 write locks 0 pid/thread 12612/7 29 dd=294 locks held 0 write locks 0 pid/thread 12612/7 2a dd=293 locks held 1 write locks 0 pid/thread 12612/4 2a READ 1 HELD uidNumber.bdb handle 0 2b dd=292 locks held 0 write locks 0 pid/thread 12612/4 2c dd=291 locks held 0 write locks 0 pid/thread 12612/4 2d dd=290 locks held 0 write locks 0 pid/thread 12612/6 2e dd=289 locks held 0 write locks 0 pid/thread 12612/6 2f dd=287 locks held 0 write locks 0 pid/thread 12612/6 30 dd=286 locks held 0 write locks 0 pid/thread 12612/3 31 dd=285 locks held 0 write locks 0 pid/thread 12612/8 32 dd=284 locks held 1 write locks 0 pid/thread 12612/8 32 READ 1 HELD uid.bdb handle 0 33 dd=283 locks held 0 write locks 0 pid/thread 12612/8 34 dd=282 locks held 0 write locks 0 pid/thread 12612/8 35 dd=281 locks held 1 write locks 0 pid/thread 12612/6 35 READ 1 HELD memberUid.bdb handle 0 36 dd=280 locks held 0 write locks 0 pid/thread 12612/6 37 dd=279 locks held 0 write locks 0 pid/thread 12612/6 38 dd=278 locks held 0 write locks 0 pid/thread 12612/6 39 dd=277 locks held 0 write locks 0 pid/thread 12612/8 3a dd=276 locks held 0 write locks 0 pid/thread 12612/4 3b dd=275 locks held 0 write locks 0 pid/thread 12612/5 3c dd=274 locks held 0 write locks 0 pid/thread 12612/4 3d dd=273 locks held 1 write locks 0 pid/thread 12612/3 3d READ 1 HELD sendmailMTACluster.bdb handle 0 3e dd=272 locks held 0 write locks 0 pid/thread 12612/3 3f dd=271 locks held 0 write locks 0 pid/thread 12612/3 40 dd=270 locks held 0 write locks 0 pid/thread 12612/3 41 dd=269 locks held 1 write locks 0 pid/thread 12612/3 41 READ 1 HELD sendmailMTAHost.bdb handle 0 42 dd=268 locks held 0 write locks 0 pid/thread 12612/3 43 dd=267 locks held 0 write locks 0 pid/thread 12612/3 44 dd=266 locks held 1 write locks 0 pid/thread 12612/3 44 READ 1 HELD sendmailMTAMapName.bdb handle 0 45 dd=265 locks held 0 write locks 0 pid/thread 12612/3 46 dd=264 locks held 0 write locks 0 pid/thread 12612/3 47 dd=263 locks held 1 write locks 0 pid/thread 12612/3 47 READ 1 HELD sendmailMTAKey.bdb handle 0 48 dd=262 locks held 0 write locks 0 pid/thread 12612/3 49 dd=261 locks held 0 write locks 0 pid/thread 12612/3 4a dd=260 locks held 1 write locks 0 pid/thread 12612/7 4a READ 1 HELD sendmailMTAAliasGrouping.bdb handle 0 4b dd=259 locks held 0 write locks 0 pid/thread 12612/7 4c dd=258 locks held 0 write locks 0 pid/thread 12612/7 4d dd=257 locks held 0 write locks 0 pid/thread 12612/7 4e dd=256 locks held 0 write locks 0 pid/thread 12612/7 4f dd=255 locks held 0 write locks 0 pid/thread 12612/7 50 dd=254 locks held 0 write locks 0 pid/thread 12612/6 51 dd=253 locks held 0 write locks 0 pid/thread 12612/4 52 dd=252 locks held 0 write locks 0 pid/thread 12612/8 53 dd=251 locks held 0 write locks 0 pid/thread 12612/7 54 dd=250 locks held 0 write locks 0 pid/thread 12612/7 55 dd=249 locks held 0 write locks 0 pid/thread 12612/6 56 dd=248 locks held 0 write locks 0 pid/thread 12612/6 57 dd=247 locks held 0 write locks 0 pid/thread 12612/3 58 dd=246 locks held 0 write locks 0 pid/thread 12612/3 59 dd=245 locks held 0 write locks 0 pid/thread 12612/7 5a dd=244 locks held 0 write locks 0 pid/thread 12612/7 5b dd=243 locks held 1 write locks 0 pid/thread 12612/6 5b READ 1 HELD gidNumber.bdb handle 0 5c dd=242 locks held 0 write locks 0 pid/thread 12612/6 5d dd=241 locks held 0 write locks 0 pid/thread 12612/6 5e dd=240 locks held 0 write locks 0 pid/thread 12612/3 5f dd=239 locks held 0 write locks 0 pid/thread 12612/3 60 dd=238 locks held 1 write locks 0 pid/thread 12612/6 60 READ 1 HELD desMapName.bdb handle 0 61 dd=237 locks held 0 write locks 0 pid/thread 12612/6 62 dd=236 locks held 0 write locks 0 pid/thread 12612/6 63 dd=231 locks held 1 write locks 0 pid/thread 12612/11 63 READ 1 HELD ipServicePort.bdb handle 0 64 dd=230 locks held 0 write locks 0 pid/thread 12612/11 65 dd=229 locks held 0 write locks 0 pid/thread 12612/11 66 dd=228 locks held 0 write locks 0 pid/thread 12612/10 67 dd=227 locks held 0 write locks 0 pid/thread 12612/10 68 dd=226 locks held 0 write locks 0 pid/thread 12612/6 69 dd=225 locks held 0 write locks 0 pid/thread 12612/10 6a dd=224 locks held 0 write locks 0 pid/thread 12612/11 6b dd=223 locks held 0 write locks 0 pid/thread 12612/6 6c dd=222 locks held 0 write locks 0 pid/thread 12612/7 6d dd=221 locks held 0 write locks 0 pid/thread 12612/6 6e dd=219 locks held 0 write locks 0 pid/thread 12612/14 6f dd=218 locks held 0 write locks 0 pid/thread 12612/14 70 dd=216 locks held 0 write locks 0 pid/thread 12612/5 71 dd=215 locks held 0 write locks 0 pid/thread 12612/11 72 dd=214 locks held 0 write locks 0 pid/thread 12612/12 73 dd=212 locks held 0 write locks 0 pid/thread 12612/10 74 dd=211 locks held 0 write locks 0 pid/thread 12612/3 75 dd=210 locks held 0 write locks 0 pid/thread 12612/6 76 dd=209 locks held 0 write locks 0 pid/thread 12612/7 77 dd=206 locks held 0 write locks 0 pid/thread 12612/12 78 dd=205 locks held 0 write locks 0 pid/thread 12612/13 79 dd=203 locks held 0 write locks 0 pid/thread 12612/9 7a dd=202 locks held 0 write locks 0 pid/thread 12612/5 7b dd=201 locks held 0 write locks 0 pid/thread 12612/11 7c dd=200 locks held 0 write locks 0 pid/thread 12612/3 7d dd=199 locks held 0 write locks 0 pid/thread 12612/10 7e dd=198 locks held 0 write locks 0 pid/thread 12612/5 7f dd=197 locks held 0 write locks 0 pid/thread 12612/6 80 dd=196 locks held 0 write locks 0 pid/thread 12612/15 81 dd=195 locks held 0 write locks 0 pid/thread 12612/3 82 dd=194 locks held 0 write locks 0 pid/thread 12612/11 83 dd=193 locks held 0 write locks 0 pid/thread 12612/3 84 dd=192 locks held 0 write locks 0 pid/thread 12612/10 85 dd=191 locks held 0 write locks 0 pid/thread 12612/6 86 dd=190 locks held 0 write locks 0 pid/thread 12612/7 87 dd=189 locks held 0 write locks 0 pid/thread 12612/11 88 dd=188 locks held 0 write locks 0 pid/thread 12612/18 89 dd=187 locks held 0 write locks 0 pid/thread 12612/15 8a dd=186 locks held 0 write locks 0 pid/thread 12612/9 8b dd=185 locks held 0 write locks 0 pid/thread 12612/5 8c dd=184 locks held 0 write locks 0 pid/thread 12612/12 8d dd=183 locks held 0 write locks 0 pid/thread 12612/15 8e dd=182 locks held 0 write locks 0 pid/thread 12612/6 8f dd=181 locks held 0 write locks 0 pid/thread 12612/15 90 dd=180 locks held 0 write locks 0 pid/thread 12612/8 91 dd=179 locks held 0 write locks 0 pid/thread 12612/8 92 dd=178 locks held 0 write locks 0 pid/thread 12612/9 93 dd=177 locks held 0 write locks 0 pid/thread 12612/4 94 dd=176 locks held 0 write locks 0 pid/thread 12612/14 95 dd=175 locks held 0 write locks 0 pid/thread 12612/4 96 dd=174 locks held 0 write locks 0 pid/thread 12612/4 97 dd=173 locks held 0 write locks 0 pid/thread 12612/10 98 dd=172 locks held 0 write locks 0 pid/thread 12612/5 99 dd=171 locks held 0 write locks 0 pid/thread 12612/17 9a dd=170 locks held 0 write locks 0 pid/thread 12612/15 9b dd=169 locks held 0 write locks 0 pid/thread 12612/5 9c dd=168 locks held 0 write locks 0 pid/thread 12612/3 9d dd=167 locks held 0 write locks 0 pid/thread 12612/4 9e dd=166 locks held 1 write locks 0 pid/thread 12612/4 9e READ 1 HELD desmailKey.bdb handle 0 9f dd=165 locks held 0 write locks 0 pid/thread 12612/4 a0 dd=164 locks held 0 write locks 0 pid/thread 12612/4 a1 dd=163 locks held 0 write locks 0 pid/thread 12612/17 a2 dd=162 locks held 0 write locks 0 pid/thread 12612/17 a3 dd=161 locks held 0 write locks 0 pid/thread 12612/3 a4 dd=160 locks held 0 write locks 0 pid/thread 12612/17 a5 dd=159 locks held 0 write locks 0 pid/thread 12612/5 a6 dd=158 locks held 0 write locks 0 pid/thread 12612/5 a7 dd=157 locks held 0 write locks 0 pid/thread 12612/4 a8 dd=156 locks held 0 write locks 0 pid/thread 12612/4 a9 dd=155 locks held 0 write locks 0 pid/thread 12612/13 aa dd=154 locks held 0 write locks 0 pid/thread 12612/5 ab dd=153 locks held 0 write locks 0 pid/thread 12612/5 ac dd=152 locks held 0 write locks 0 pid/thread 12612/6 ad dd=151 locks held 0 write locks 0 pid/thread 12612/15 ae dd=150 locks held 0 write locks 0 pid/thread 12612/5 af dd=149 locks held 0 write locks 0 pid/thread 12612/10 b0 dd=148 locks held 0 write locks 0 pid/thread 12612/12 b1 dd=147 locks held 0 write locks 0 pid/thread 12612/7 b2 dd=146 locks held 0 write locks 0 pid/thread 12612/5 b3 dd=145 locks held 0 write locks 0 pid/thread 12612/14 b4 dd=144 locks held 0 write locks 0 pid/thread 12612/11 b5 dd=143 locks held 0 write locks 0 pid/thread 12612/9 b6 dd=142 locks held 0 write locks 0 pid/thread 12612/16 b7 dd=141 locks held 0 write locks 0 pid/thread 12612/7 b8 dd=140 locks held 0 write locks 0 pid/thread 12612/11 b9 dd=139 locks held 0 write locks 0 pid/thread 12612/10 ba dd=138 locks held 0 write locks 0 pid/thread 12612/3 bb dd=137 locks held 0 write locks 0 pid/thread 12612/3 bc dd=136 locks held 0 write locks 0 pid/thread 12612/4 bd dd=135 locks held 0 write locks 0 pid/thread 12612/4 be dd=134 locks held 0 write locks 0 pid/thread 12612/6 bf dd=133 locks held 0 write locks 0 pid/thread 12612/6 c0 dd=132 locks held 0 write locks 0 pid/thread 12612/12 c1 dd=131 locks held 0 write locks 0 pid/thread 12612/12 c2 dd=130 locks held 0 write locks 0 pid/thread 12612/7 c3 dd=129 locks held 0 write locks 0 pid/thread 12612/7 c4 dd=128 locks held 0 write locks 0 pid/thread 12612/16 c5 dd=127 locks held 0 write locks 0 pid/thread 12612/16 c6 dd=126 locks held 0 write locks 0 pid/thread 12612/10 c7 dd=125 locks held 0 write locks 0 pid/thread 12612/7 c8 dd=124 locks held 0 write locks 0 pid/thread 12612/18 c9 dd=123 locks held 0 write locks 0 pid/thread 12612/6 ca dd=122 locks held 1 write locks 0 pid/thread 12612/11 ca READ 1 HELD desmiscKey.bdb handle 0 cb dd=121 locks held 0 write locks 0 pid/thread 12612/11 cc dd=120 locks held 0 write locks 0 pid/thread 12612/11 cd dd=119 locks held 1 write locks 0 pid/thread 12612/9 cd READ 1 HELD entryUUID.bdb handle 0 ce dd=118 locks held 0 write locks 0 pid/thread 12612/9 cf dd=117 locks held 0 write locks 0 pid/thread 12612/9 d0 dd=116 locks held 1 write locks 0 pid/thread 12612/9 d0 READ 1 HELD entryCSN.bdb handle 0 d1 dd=115 locks held 0 write locks 0 pid/thread 12612/9 d2 dd=114 locks held 0 write locks 0 pid/thread 12612/9 d3 dd=113 locks held 0 write locks 0 pid/thread 12612/17 d4 dd=112 locks held 0 write locks 0 pid/thread 12612/17 d5 dd=111 locks held 0 write locks 0 pid/thread 12612/5 d6 dd=110 locks held 0 write locks 0 pid/thread 12612/11 d7 dd=109 locks held 0 write locks 0 pid/thread 12612/9 d8 dd=108 locks held 0 write locks 0 pid/thread 12612/13 d9 dd=107 locks held 0 write locks 0 pid/thread 12612/3 da dd=106 locks held 0 write locks 0 pid/thread 12612/13 db dd=105 locks held 0 write locks 0 pid/thread 12612/15 dc dd=104 locks held 0 write locks 0 pid/thread 12612/16 dd dd=103 locks held 0 write locks 0 pid/thread 12612/8 de dd=102 locks held 0 write locks 0 pid/thread 12612/13 df dd=101 locks held 1 write locks 0 pid/thread 12612/17 df READ 1 HELD sendmailMTAListsyncValue.bdb handle 0 e0 dd=100 locks held 0 write locks 0 pid/thread 12612/17 e1 dd=99 locks held 0 write locks 0 pid/thread 12612/17 e2 dd=98 locks held 0 write locks 0 pid/thread 12612/17 e3 dd=97 locks held 0 write locks 0 pid/thread 12612/17 e4 dd=96 locks held 0 write locks 0 pid/thread 12612/11 e5 dd=95 locks held 0 write locks 0 pid/thread 12612/8 e6 dd=94 locks held 0 write locks 0 pid/thread 12612/13 e7 dd=93 locks held 0 write locks 0 pid/thread 12612/18 e8 dd=92 locks held 0 write locks 0 pid/thread 12612/4 e9 dd=91 locks held 0 write locks 0 pid/thread 12612/12 ea dd=90 locks held 0 write locks 0 pid/thread 12612/11 eb dd=89 locks held 0 write locks 0 pid/thread 12612/11 ec dd=88 locks held 0 write locks 0 pid/thread 12612/5 ed dd=87 locks held 0 write locks 0 pid/thread 12612/5 ee dd=86 locks held 0 write locks 0 pid/thread 12612/5 ef dd=85 locks held 0 write locks 0 pid/thread 12612/8 f0 dd=84 locks held 0 write locks 0 pid/thread 12612/8 f1 dd=83 locks held 0 write locks 0 pid/thread 12612/13 f2 dd=82 locks held 0 write locks 0 pid/thread 12612/13 f3 dd=81 locks held 0 write locks 0 pid/thread 12612/10 f4 dd=80 locks held 0 write locks 0 pid/thread 12612/4 f5 dd=79 locks held 0 write locks 0 pid/thread 12612/17 f6 dd=78 locks held 0 write locks 0 pid/thread 12612/13 f7 dd=77 locks held 0 write locks 0 pid/thread 12612/13 f8 dd=76 locks held 0 write locks 0 pid/thread 12612/13 f9 dd=75 locks held 0 write locks 0 pid/thread 12612/18 fa dd=74 locks held 0 write locks 0 pid/thread 12612/5 fb dd=73 locks held 0 write locks 0 pid/thread 12612/12 fc dd=72 locks held 0 write locks 0 pid/thread 12612/7 fd dd=71 locks held 1 write locks 0 pid/thread 12612/13 fd READ 1 HELD sendmailMTAAliasType.bdb handle 0 fe dd=70 locks held 0 write locks 0 pid/thread 12612/13 ff dd=69 locks held 0 write locks 0 pid/thread 12612/13 100 dd=68 locks held 0 write locks 0 pid/thread 12612/13 101 dd=67 locks held 0 write locks 0 pid/thread 12612/13 102 dd=66 locks held 1 write locks 0 pid/thread 12612/13 102 READ 1 HELD sendmailMTAAliasOrigin.bdb handle 0 103 dd=65 locks held 0 write locks 0 pid/thread 12612/13 104 dd=64 locks held 0 write locks 0 pid/thread 12612/13 105 dd=63 locks held 0 write locks 0 pid/thread 12612/13 106 dd=62 locks held 0 write locks 0 pid/thread 12612/13 107 dd=61 locks held 1 write locks 0 pid/thread 12612/12 107 READ 1 HELD macAddress.bdb handle 0 108 dd=60 locks held 0 write locks 0 pid/thread 12612/12 109 dd=59 locks held 0 write locks 0 pid/thread 12612/12 10a dd=58 locks held 0 write locks 0 pid/thread 12612/14 10b dd=57 locks held 0 write locks 0 pid/thread 12612/7 10c dd=56 locks held 0 write locks 0 pid/thread 12612/6 10d dd=55 locks held 0 write locks 0 pid/thread 12612/16 10e dd=54 locks held 0 write locks 0 pid/thread 12612/16 10f dd=53 locks held 0 write locks 0 pid/thread 12612/13 110 dd=52 locks held 0 write locks 0 pid/thread 12612/18 111 dd=51 locks held 0 write locks 0 pid/thread 12612/8 112 dd=50 locks held 0 write locks 0 pid/thread 12612/11 113 dd=49 locks held 1 write locks 0 pid/thread 12612/7 113 READ 1 HELD userPassword.bdb handle 0 114 dd=48 locks held 0 write locks 0 pid/thread 12612/7 115 dd=47 locks held 0 write locks 0 pid/thread 12612/7 116 dd=46 locks held 0 write locks 0 pid/thread 12612/7 117 dd=45 locks held 0 write locks 0 pid/thread 12612/7 118 dd=44 locks held 0 write locks 0 pid/thread 12612/18 119 dd=43 locks held 1 write locks 0 pid/thread 12612/13 119 READ 1 HELD sn.bdb handle 0 11a dd=42 locks held 0 write locks 0 pid/thread 12612/13 11b dd=41 locks held 0 write locks 0 pid/thread 12612/13 11c dd=40 locks held 0 write locks 0 pid/thread 12612/13 11d dd=39 locks held 0 write locks 0 pid/thread 12612/13 11e dd=38 locks held 1 write locks 0 pid/thread 12612/4 11e READ 1 HELD oncRpcNumber.bdb handle 0 11f dd=37 locks held 0 write locks 0 pid/thread 12612/4 120 dd=36 locks held 0 write locks 0 pid/thread 12612/4 121 dd=35 locks held 1 write locks 0 pid/thread 12612/3 121 READ 1 HELD automountKey.bdb handle 0 122 dd=34 locks held 0 write locks 0 pid/thread 12612/3 123 dd=33 locks held 1 write locks 0 pid/thread 12612/13 123 READ 1 HELD ou.bdb handle 0 124 dd=32 locks held 0 write locks 0 pid/thread 12612/13 125 dd=31 locks held 0 write locks 0 pid/thread 12612/13 126 dd=30 locks held 0 write locks 0 pid/thread 12612/18 127 dd=29 locks held 0 write locks 0 pid/thread 12612/12 128 dd=28 locks held 0 write locks 0 pid/thread 12612/5 129 dd=27 locks held 0 write locks 0 pid/thread 12612/13 12a dd=26 locks held 0 write locks 0 pid/thread 12612/13 12b dd=25 locks held 0 write locks 0 pid/thread 12612/6 12c dd=24 locks held 0 write locks 0 pid/thread 12612/6 12d dd=23 locks held 0 write locks 0 pid/thread 12612/8 12e dd=22 locks held 0 write locks 0 pid/thread 12612/8 12f dd=21 locks held 0 write locks 0 pid/thread 12612/4 130 dd=20 locks held 0 write locks 0 pid/thread 12612/4 131 dd=19 locks held 0 write locks 0 pid/thread 12612/13 132 dd=18 locks held 0 write locks 0 pid/thread 12612/13 133 dd=17 locks held 0 write locks 0 pid/thread 12612/4 134 dd=16 locks held 0 write locks 0 pid/thread 12612/14 135 dd=15 locks held 0 write locks 0 pid/thread 12612/14 136 dd=14 locks held 0 write locks 0 pid/thread 12612/14 137 dd=13 locks held 0 write locks 0 pid/thread 12612/8 138 dd=12 locks held 0 write locks 0 pid/thread 12612/8 139 dd=11 locks held 0 write locks 0 pid/thread 12612/17 13a dd=10 locks held 0 write locks 0 pid/thread 12612/16 13b dd= 9 locks held 0 write locks 0 pid/thread 12612/13 13c dd= 8 locks held 0 write locks 0 pid/thread 12612/11 13d dd= 7 locks held 0 write locks 0 pid/thread 12612/12 13e dd= 6 locks held 0 write locks 0 pid/thread 12612/17 13f dd= 5 locks held 0 write locks 0 pid/thread 12612/8 140 dd= 4 locks held 0 write locks 0 pid/thread 12612/8 141 dd= 3 locks held 0 write locks 0 pid/thread 12612/3 142 dd= 2 locks held 0 write locks 0 pid/thread 12612/13 143 dd= 1 locks held 0 write locks 0 pid/thread 12612/13 80000009 dd=326 locks held 0 write locks 0 pid/thread 12612/1 8000000a dd=325 locks held 0 write locks 0 pid/thread 12612/1 8000000b dd=323 locks held 1 write locks 1 pid/thread 12612/3 8000000b WRITE 1 HELD objectClass.bdb page 4 8000000c dd=322 locks held 0 write locks 0 pid/thread 12612/5 8000000c READ 1 WAIT objectClass.bdb page 4 80000010 dd=304 locks held 0 write locks 0 pid/thread 12612/4 80000010 READ 1 WAIT objectClass.bdb page 4 80000012 dd=298 locks held 0 write locks 0 pid/thread 12612/6 80000012 READ 1 WAIT objectClass.bdb page 4 80000013 dd=296 locks held 0 write locks 0 pid/thread 12612/7 80000013 READ 1 WAIT objectClass.bdb page 4 80000015 dd=288 locks held 0 write locks 0 pid/thread 12612/8 80000015 READ 1 WAIT objectClass.bdb page 4 8000001f dd=235 locks held 0 write locks 0 pid/thread 12612/9 8000001f READ 1 WAIT objectClass.bdb page 4 80000020 dd=234 locks held 0 write locks 0 pid/thread 12612/10 80000020 READ 1 WAIT objectClass.bdb page 4 80000021 dd=233 locks held 0 write locks 0 pid/thread 12612/11 80000021 READ 1 WAIT objectClass.bdb page 4 80000022 dd=232 locks held 0 write locks 0 pid/thread 12612/12 80000022 READ 1 WAIT objectClass.bdb page 4 80000024 dd=220 locks held 0 write locks 0 pid/thread 12612/14 80000024 READ 1 WAIT objectClass.bdb page 4 80000025 dd=217 locks held 0 write locks 0 pid/thread 12612/13 80000025 READ 1 WAIT objectClass.bdb page 4 80000026 dd=213 locks held 0 write locks 0 pid/thread 12612/15 80000026 READ 1 WAIT objectClass.bdb page 4 80000027 dd=208 locks held 0 write locks 0 pid/thread 12612/16 80000027 READ 1 WAIT objectClass.bdb page 4 80000028 dd=207 locks held 0 write locks 0 pid/thread 12612/17 80000028 READ 1 WAIT objectClass.bdb page 4 80000029 dd=204 locks held 0 write locks 0 pid/thread 12612/18 80000029 READ 1 WAIT objectClass.bdb page 4 8001cccd dd= 0 locks held 2 write locks 0 pid/thread 12612/3 8001cccd READ 1 HELD 0x464b0 len: 9 data: 0x620x7100000000000000 8001cccd READ 1 HELD 0x540b8 len: 9 data: 0xcf0x1d0x01000000000000 8001ccce dd= 0 locks held 11 write locks 5 pid/thread 12612/3 8001ccce READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 HELD objectClass.bdb page 3 8001ccce READ 1 HELD dn2id.bdb page 8 8001ccce WRITE 2 HELD dn2id.bdb page 1595 8001ccce READ 2 HELD dn2id.bdb page 1595 8001ccce WRITE 2 HELD dn2id.bdb page 2520 8001ccce READ 2 HELD dn2id.bdb page 2520 8001ccce WRITE 2 HELD dn2id.bdb page 2601 8001ccce READ 2 HELD dn2id.bdb page 2601 8001ccce WRITE 2 HELD dn2id.bdb page 3106 8001ccce READ 1 HELD dn2id.bdb page 3106 8001ccce WRITE 4 HELD dn2id.bdb page 3901 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 119 READ 1 HELD sn.bdb handle 0 d READ 1 HELD dn2id.bdb handle 0 8001ccce READ 1 HELD dn2id.bdb page 8 8001ccce READ 1 HELD dn2id.bdb page 3106 8001ccce WRITE 2 HELD dn2id.bdb page 3106 5b READ 1 HELD gidNumber.bdb handle 0 47 READ 1 HELD sendmailMTAKey.bdb handle 0 121 READ 1 HELD automountKey.bdb handle 0 ca READ 1 HELD desmiscKey.bdb handle 0 11e READ 1 HELD oncRpcNumber.bdb handle 0 3d READ 1 HELD sendmailMTACluster.bdb handle 0 35 READ 1 HELD memberUid.bdb handle 0 8001ccce WRITE 4 HELD dn2id.bdb page 3901 cd READ 1 HELD entryUUID.bdb handle 0 113 READ 1 HELD userPassword.bdb handle 0 b READ 1 HELD id2entry.bdb handle 0 22 READ 1 HELD amdKey.bdb handle 0 107 READ 1 HELD macAddress.bdb handle 0 60 READ 1 HELD desMapName.bdb handle 0 32 READ 1 HELD uid.bdb handle 0 44 READ 1 HELD sendmailMTAMapName.bdb handle 0 102 READ 1 HELD sendmailMTAAliasOrigin.bdb handle 0 fd READ 1 HELD sendmailMTAAliasType.bdb handle 0 8001ccce READ 2 HELD dn2id.bdb page 2601 8001ccce WRITE 2 HELD dn2id.bdb page 2601 8001ccce READ 2 HELD dn2id.bdb page 1595 8001ccce WRITE 2 HELD dn2id.bdb page 1595 8000000b WRITE 1 HELD objectClass.bdb page 4 80000015 READ 1 WAIT objectClass.bdb page 4 8000000c READ 1 WAIT objectClass.bdb page 4 8000001f READ 1 WAIT objectClass.bdb page 4 80000026 READ 1 WAIT objectClass.bdb page 4 80000012 READ 1 WAIT objectClass.bdb page 4 80000025 READ 1 WAIT objectClass.bdb page 4 80000021 READ 1 WAIT objectClass.bdb page 4 80000027 READ 1 WAIT objectClass.bdb page 4 80000022 READ 1 WAIT objectClass.bdb page 4 80000028 READ 1 WAIT objectClass.bdb page 4 80000013 READ 1 WAIT objectClass.bdb page 4 80000020 READ 1 WAIT objectClass.bdb page 4 80000010 READ 1 WAIT objectClass.bdb page 4 80000029 READ 1 WAIT objectClass.bdb page 4 80000024 READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 WAIT objectClass.bdb page 4 8001ccce READ 1 HELD objectClass.bdb page 3 12 READ 1 HELD objectClass.bdb handle 0 16 READ 1 HELD cn.bdb handle 0 8001cccd READ 1 HELD 0x540b8 len: 9 data: 0xcf0x1d0x01000000000000 df READ 1 HELD sendmailMTAListsyncValue.bdb handle 0 9e READ 1 HELD desmailKey.bdb handle 0 41 READ 1 HELD sendmailMTAHost.bdb handle 0 8001ccce READ 2 HELD dn2id.bdb page 2520 8001ccce WRITE 2 HELD dn2id.bdb page 2520 8001cccd READ 1 HELD 0x464b0 len: 9 data: 0x620x7100000000000000 63 READ 1 HELD ipServicePort.bdb handle 0 4a READ 1 HELD sendmailMTAAliasGrouping.bdb handle 0 2a READ 1 HELD uidNumber.bdb handle 0 d0 READ 1 HELD entryCSN.bdb handle 0 19 READ 1 HELD ipServiceProtocol.bdb handle 0 123 READ 1 HELD ou.bdb handle 0 ########## # pfiles # ########## 12612: /usr/local/pkgs/openldap-2.4.25/libexec/slapd -u ldap -g ldap -h ldap: Current rlimit: 16384 file descriptors 0: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 1: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 2: S_IFCHR mode:0666 dev:286,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDWR|O_LARGEFILE /devices/pseudo/mm@0:null 3: S_IFDOOR mode:0444 dev:295,0 ino:87 uid:0 gid:0 size:0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[16774] /var/run/name_service_door 4: S_IFCHR mode:0000 dev:286,0 ino:46256 uid:0 gid:0 rdev:21,90918 O_WRONLY|O_LARGEFILE FD_CLOEXEC /devices/pseudo/log@0:conslog 5: S_IFIFO mode:0000 dev:284,0 ino:64519629 uid:0 gid:0 size:0 O_RDWR 6: S_IFIFO mode:0000 dev:284,0 ino:64519629 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK 7: S_IFSOCK mode:0666 dev:293,0 ino:19448 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET6 :: port: 389 8: S_IFSOCK mode:0666 dev:293,0 ino:19912 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 389 9: S_IFSOCK mode:0666 dev:293,0 ino:41938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET6 :: port: 636 10: S_IFSOCK mode:0666 dev:293,0 ino:15348 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 636 11: S_IFREG mode:0644 dev:181,65539 ino:135521 uid:5202 gid:5202 size:4096 O_RDWR|O_CREAT|O_LARGEFILE /var/openldap/nyc.deshaw.com/data/alock 12: S_IFREG mode:0600 dev:181,65539 ino:135532 uid:5202 gid:5202 size:196657152 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/id2entry.bdb 13: S_IFREG mode:0600 dev:181,65539 ino:135528 uid:5202 gid:5202 size:52404224 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/dn2id.bdb 14: S_IFSOCK mode:0666 dev:293,0 ino:63587 uid:0 gid:0 size:0 O_RDWR FD_CLOEXEC SOCK_STREAM SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 59160 peername: AF_INET 149.77.10.1 port: 389 15: S_IFSOCK mode:0666 dev:293,0 ino:43942 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59986 16: S_IFSOCK mode:0666 dev:293,0 ino:17402 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 34188 17: S_IFREG mode:0600 dev:181,65539 ino:135539 uid:5202 gid:5202 size:4055040 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/objectClass.bdb 18: S_IFREG mode:0600 dev:181,65539 ino:135524 uid:5202 gid:5202 size:10395648 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/cn.bdb 19: S_IFREG mode:0600 dev:181,65539 ino:135534 uid:5202 gid:5202 size:65536 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ipServiceProtocol.bdb 20: S_IFSOCK mode:0666 dev:293,0 ino:19785 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 38338 21: S_IFSOCK mode:0666 dev:293,0 ino:33499 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.164 port: 52543 22: S_IFREG mode:0600 dev:181,65539 ino:135522 uid:5202 gid:5202 size:262144 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/amdKey.bdb 23: S_IFSOCK mode:0666 dev:293,0 ino:49461 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 24: S_IFSOCK mode:0666 dev:293,0 ino:29568 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 48334 25: S_IFSOCK mode:0666 dev:293,0 ino:38152 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59374 26: S_IFREG mode:0600 dev:181,65539 ino:135551 uid:5202 gid:5202 size:262144 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/uid.bdb 27: S_IFREG mode:0600 dev:181,65539 ino:135538 uid:5202 gid:5202 size:548864 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/memberUid.bdb 28: S_IFREG mode:0600 dev:181,65539 ino:135552 uid:5202 gid:5202 size:229376 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/uidNumber.bdb 29: S_IFSOCK mode:0666 dev:293,0 ino:2434 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59375 30: S_IFSOCK mode:0666 dev:293,0 ino:23938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43092 31: S_IFSOCK mode:0666 dev:293,0 ino:33275 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 37641 32: S_IFSOCK mode:0666 dev:293,0 ino:26310 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 38904 33: S_IFREG mode:0600 dev:181,65539 ino:135545 uid:5202 gid:5202 size:1359872 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTACluster.bdb 34: S_IFREG mode:0600 dev:181,65539 ino:135546 uid:5202 gid:5202 size:8192 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAHost.bdb 35: S_IFREG mode:0600 dev:181,65539 ino:135549 uid:5202 gid:5202 size:663552 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAMapName.bdb 36: S_IFREG mode:0600 dev:181,65539 ino:135547 uid:5202 gid:5202 size:2162688 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAKey.bdb 37: S_IFREG mode:0600 dev:181,65539 ino:135542 uid:5202 gid:5202 size:565248 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasGrouping.bdb 38: S_IFREG mode:0600 dev:181,65539 ino:135531 uid:5202 gid:5202 size:393216 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/gidNumber.bdb 39: S_IFSOCK mode:0666 dev:293,0 ino:17403 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 59378 40: S_IFSOCK mode:0666 dev:293,0 ino:35237 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 47550 41: S_IFSOCK mode:0666 dev:293,0 ino:16350 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43152 42: S_IFSOCK mode:0666 dev:293,0 ino:14601 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 38324 43: S_IFSOCK mode:0666 dev:293,0 ino:15818 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43156 44: S_IFSOCK mode:0666 dev:293,0 ino:20675 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43153 45: S_IFSOCK mode:0666 dev:293,0 ino:16337 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 35520 46: S_IFSOCK mode:0666 dev:293,0 ino:25798 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 33501 47: S_IFSOCK mode:0666 dev:293,0 ino:9812 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 48: S_IFSOCK mode:0666 dev:293,0 ino:41267 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 49: S_IFSOCK mode:0666 dev:293,0 ino:35418 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 50: S_IFREG mode:0600 dev:181,65539 ino:165220 uid:5202 gid:5202 size:10485760 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/log.0000001693 51: S_IFSOCK mode:0666 dev:293,0 ino:35224 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43345 52: S_IFSOCK mode:0666 dev:293,0 ino:32036 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 52238 53: S_IFSOCK mode:0666 dev:293,0 ino:47033 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 52239 54: S_IFSOCK mode:0666 dev:293,0 ino:25757 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 55: S_IFSOCK mode:0666 dev:293,0 ino:33188 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46952 56: S_IFREG mode:0600 dev:181,65539 ino:135525 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desMapName.bdb 57: S_IFSOCK mode:0666 dev:293,0 ino:25792 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 58: S_IFSOCK mode:0666 dev:293,0 ino:2666 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 59: S_IFSOCK mode:0666 dev:293,0 ino:31202 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 60: S_IFREG mode:0600 dev:181,65539 ino:135537 uid:5202 gid:5202 size:40960 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/macAddress.bdb 61: S_IFSOCK mode:0666 dev:293,0 ino:109 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 62: S_IFSOCK mode:0666 dev:293,0 ino:49460 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 56494 63: S_IFSOCK mode:0666 dev:293,0 ino:14549 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 64: S_IFSOCK mode:0666 dev:293,0 ino:15785 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 65: S_IFSOCK mode:0666 dev:293,0 ino:18202 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 66: S_IFREG mode:0600 dev:181,65539 ino:135533 uid:5202 gid:5202 size:90112 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ipServicePort.bdb 67: S_IFSOCK mode:0666 dev:293,0 ino:61134 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 68: S_IFSOCK mode:0666 dev:293,0 ino:32793 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 69: S_IFSOCK mode:0666 dev:293,0 ino:15177 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 70: S_IFSOCK mode:0666 dev:293,0 ino:36966 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.174 port: 46335 71: S_IFSOCK mode:0666 dev:293,0 ino:38446 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 48341 72: S_IFSOCK mode:0666 dev:293,0 ino:52630 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 73: S_IFSOCK mode:0666 dev:293,0 ino:23603 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 74: S_IFSOCK mode:0666 dev:293,0 ino:35434 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 75: S_IFSOCK mode:0666 dev:293,0 ino:17400 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 76: S_IFSOCK mode:0666 dev:293,0 ino:17146 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 77: S_IFSOCK mode:0666 dev:293,0 ino:6611 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 78: S_IFSOCK mode:0666 dev:293,0 ino:65454 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.44.80 port: 45478 79: S_IFSOCK mode:0666 dev:293,0 ino:36072 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 47356 80: S_IFSOCK mode:0666 dev:293,0 ino:23126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 34315 81: S_IFSOCK mode:0666 dev:293,0 ino:35227 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.138 port: 53430 82: S_IFSOCK mode:0666 dev:293,0 ino:17401 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49626 83: S_IFSOCK mode:0666 dev:293,0 ino:44596 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 84: S_IFSOCK mode:0666 dev:293,0 ino:1812 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 85: S_IFSOCK mode:0666 dev:293,0 ino:39417 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 86: S_IFSOCK mode:0666 dev:293,0 ino:17492 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 41328 87: S_IFSOCK mode:0666 dev:293,0 ino:15128 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 88: S_IFSOCK mode:0666 dev:293,0 ino:43685 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.140 port: 37920 89: S_IFSOCK mode:0666 dev:293,0 ino:26309 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 90: S_IFSOCK mode:0666 dev:293,0 ino:28264 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 91: S_IFSOCK mode:0666 dev:293,0 ino:17542 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 92: S_IFSOCK mode:0666 dev:293,0 ino:938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 93: S_IFSOCK mode:0666 dev:293,0 ino:42650 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42415 94: S_IFSOCK mode:0666 dev:293,0 ino:19665 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 95: S_IFSOCK mode:0666 dev:293,0 ino:43128 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39733 96: S_IFSOCK mode:0666 dev:293,0 ino:16910 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 97: S_IFSOCK mode:0666 dev:293,0 ino:37339 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 98: S_IFSOCK mode:0666 dev:293,0 ino:20006 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 99: S_IFSOCK mode:0666 dev:293,0 ino:25557 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 39329 100: S_IFSOCK mode:0666 dev:293,0 ino:56649 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 101: S_IFSOCK mode:0666 dev:293,0 ino:18982 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 102: S_IFSOCK mode:0666 dev:293,0 ino:32278 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 103: S_IFSOCK mode:0666 dev:293,0 ino:18235 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 104: S_IFSOCK mode:0666 dev:293,0 ino:28594 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 105: S_IFSOCK mode:0666 dev:293,0 ino:14800 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 106: S_IFSOCK mode:0666 dev:293,0 ino:17966 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 107: S_IFSOCK mode:0666 dev:293,0 ino:22090 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 108: S_IFSOCK mode:0666 dev:293,0 ino:34027 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.36 port: 60711 109: S_IFSOCK mode:0666 dev:293,0 ino:18978 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.150 port: 53165 110: S_IFREG mode:0600 dev:181,65539 ino:135548 uid:5202 gid:5202 size:2736128 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAListsyncValue.bdb 111: S_IFSOCK mode:0666 dev:293,0 ino:19891 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 112: S_IFSOCK mode:0666 dev:293,0 ino:34944 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 113: S_IFSOCK mode:0666 dev:293,0 ino:5701 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 44998 114: S_IFSOCK mode:0666 dev:293,0 ino:42652 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39112 115: S_IFSOCK mode:0666 dev:293,0 ino:2670 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 116: S_IFSOCK mode:0666 dev:293,0 ino:46513 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 52131 117: S_IFSOCK mode:0666 dev:293,0 ino:20133 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.228 port: 48289 118: S_IFSOCK mode:0666 dev:293,0 ino:19898 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.174 port: 38366 119: S_IFSOCK mode:0666 dev:293,0 ino:33496 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 120: S_IFSOCK mode:0666 dev:293,0 ino:15916 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 121: S_IFSOCK mode:0666 dev:293,0 ino:20675 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.213 port: 48607 122: S_IFSOCK mode:0666 dev:293,0 ino:937 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 123: S_IFSOCK mode:0666 dev:293,0 ino:30209 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.242 port: 35720 124: S_IFSOCK mode:0666 dev:293,0 ino:32126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 43593 125: S_IFSOCK mode:0666 dev:293,0 ino:43681 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 126: S_IFSOCK mode:0666 dev:293,0 ino:14505 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 127: S_IFSOCK mode:0666 dev:293,0 ino:15888 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 36006 128: S_IFREG mode:0600 dev:181,65539 ino:135544 uid:5202 gid:5202 size:589824 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasType.bdb 129: S_IFSOCK mode:0666 dev:293,0 ino:43683 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 57449 130: S_IFSOCK mode:0666 dev:293,0 ino:16349 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 131: S_IFSOCK mode:0666 dev:293,0 ino:32124 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.201 port: 10026 132: S_IFSOCK mode:0666 dev:293,0 ino:23758 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39734 133: S_IFSOCK mode:0666 dev:293,0 ino:52628 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 134: S_IFSOCK mode:0666 dev:293,0 ino:41988 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.44.39 port: 36331 135: S_IFSOCK mode:0666 dev:293,0 ino:19204 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42027 136: S_IFSOCK mode:0666 dev:293,0 ino:21872 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 137: S_IFREG mode:0600 dev:181,65539 ino:135553 uid:5202 gid:5202 size:294912 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/userPassword.bdb 138: S_IFSOCK mode:0666 dev:293,0 ino:14208 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 139: S_IFSOCK mode:0666 dev:293,0 ino:17404 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 140: S_IFSOCK mode:0666 dev:293,0 ino:32795 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.9.48 port: 32789 141: S_IFSOCK mode:0666 dev:293,0 ino:29057 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 142: S_IFSOCK mode:0666 dev:293,0 ino:21253 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 143: S_IFSOCK mode:0666 dev:293,0 ino:19450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39735 144: S_IFSOCK mode:0666 dev:293,0 ino:43206 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 51744 145: S_IFSOCK mode:0666 dev:293,0 ino:57349 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39736 146: S_IFSOCK mode:0666 dev:293,0 ino:39892 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42028 147: S_IFREG mode:0600 dev:181,65539 ino:135543 uid:5202 gid:5202 size:671744 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sendmailMTAAliasOrigin.bdb 148: S_IFSOCK mode:0666 dev:293,0 ino:16453 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 149: S_IFSOCK mode:0666 dev:293,0 ino:49134 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42414 150: S_IFSOCK mode:0666 dev:293,0 ino:14600 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.55.48 port: 53275 151: S_IFSOCK mode:0666 dev:293,0 ino:21874 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43168 152: S_IFSOCK mode:0666 dev:293,0 ino:41286 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39737 153: S_IFSOCK mode:0666 dev:293,0 ino:14916 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 154: S_IFSOCK mode:0666 dev:293,0 ino:17409 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 56930 155: S_IFSOCK mode:0666 dev:293,0 ino:20154 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35666 156: S_IFSOCK mode:0666 dev:293,0 ino:34681 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 157: S_IFREG mode:0600 dev:181,65539 ino:135523 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/automountKey.bdb 158: S_IFSOCK mode:0666 dev:293,0 ino:37237 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 159: S_IFSOCK mode:0666 dev:293,0 ino:42692 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 160: S_IFSOCK mode:0666 dev:293,0 ino:36760 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 161: S_IFSOCK mode:0666 dev:293,0 ino:14602 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 162: S_IFSOCK mode:0666 dev:293,0 ino:40345 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 163: S_IFSOCK mode:0666 dev:293,0 ino:20673 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43400 164: S_IFSOCK mode:0666 dev:293,0 ino:25056 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 165: S_IFSOCK mode:0666 dev:293,0 ino:19752 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 166: S_IFSOCK mode:0666 dev:293,0 ino:42553 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39738 167: S_IFSOCK mode:0666 dev:293,0 ino:21312 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 168: S_IFSOCK mode:0666 dev:293,0 ino:47141 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42796 169: S_IFSOCK mode:0666 dev:293,0 ino:21429 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 170: S_IFSOCK mode:0666 dev:293,0 ino:47140 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.121.27 port: 59433 171: S_IFSOCK mode:0666 dev:293,0 ino:57350 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 172: S_IFSOCK mode:0666 dev:293,0 ino:35613 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 173: S_IFSOCK mode:0666 dev:293,0 ino:41942 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 174: S_IFSOCK mode:0666 dev:293,0 ino:31694 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.217 port: 33509 175: S_IFSOCK mode:0666 dev:293,0 ino:36765 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.11.0.148 port: 36161 176: S_IFSOCK mode:0666 dev:293,0 ino:38156 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39739 177: S_IFSOCK mode:0666 dev:293,0 ino:63585 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 178: S_IFSOCK mode:0666 dev:293,0 ino:18243 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.158 port: 39740 179: S_IFSOCK mode:0666 dev:293,0 ino:15129 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 180: S_IFSOCK mode:0666 dev:293,0 ino:19892 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 181: S_IFSOCK mode:0666 dev:293,0 ino:20082 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 182: S_IFSOCK mode:0666 dev:293,0 ino:43680 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42780 183: S_IFSOCK mode:0666 dev:293,0 ino:40032 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 47042 184: S_IFREG mode:0600 dev:181,65539 ino:135550 uid:5202 gid:5202 size:1785856 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/sn.bdb 185: S_IFSOCK mode:0666 dev:293,0 ino:18241 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.222 port: 53352 186: S_IFSOCK mode:0666 dev:293,0 ino:9808 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 46559 187: S_IFSOCK mode:0666 dev:293,0 ino:54886 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 188: S_IFSOCK mode:0666 dev:293,0 ino:19733 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59785 189: S_IFSOCK mode:0666 dev:293,0 ino:19891 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42773 190: S_IFSOCK mode:0666 dev:293,0 ino:31695 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 42968 191: S_IFSOCK mode:0666 dev:293,0 ino:54883 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 192: S_IFSOCK mode:0666 dev:293,0 ino:39858 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42263 193: S_IFSOCK mode:0666 dev:293,0 ino:20156 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 194: S_IFSOCK mode:0666 dev:293,0 ino:17150 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 195: S_IFSOCK mode:0666 dev:293,0 ino:35420 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37081 196: S_IFSOCK mode:0666 dev:293,0 ino:19786 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 197: S_IFSOCK mode:0666 dev:293,0 ino:15960 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42786 198: S_IFSOCK mode:0666 dev:293,0 ino:52627 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 38385 199: S_IFSOCK mode:0666 dev:293,0 ino:11403 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 200: S_IFSOCK mode:0666 dev:293,0 ino:15894 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 201: S_IFSOCK mode:0666 dev:293,0 ino:35234 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 202: S_IFSOCK mode:0666 dev:293,0 ino:17012 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 203: S_IFSOCK mode:0666 dev:293,0 ino:2438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 204: S_IFSOCK mode:0666 dev:293,0 ino:63483 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 54523 205: S_IFSOCK mode:0666 dev:293,0 ino:19933 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 206: S_IFSOCK mode:0666 dev:293,0 ino:18206 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 207: S_IFSOCK mode:0666 dev:293,0 ino:43452 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 208: S_IFSOCK mode:0666 dev:293,0 ino:14603 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.130 port: 43169 209: S_IFSOCK mode:0666 dev:293,0 ino:42169 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53444 210: S_IFSOCK mode:0666 dev:293,0 ino:31757 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53446 211: S_IFSOCK mode:0666 dev:293,0 ino:64212 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53448 212: S_IFSOCK mode:0666 dev:293,0 ino:42782 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.145 port: 32799 213: S_IFSOCK mode:0666 dev:293,0 ino:16342 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53450 214: S_IFSOCK mode:0666 dev:293,0 ino:17316 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.235 port: 53452 215: S_IFSOCK mode:0666 dev:293,0 ino:15890 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 53195 216: S_IFSOCK mode:0666 dev:293,0 ino:42780 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.164 port: 49503 217: S_IFSOCK mode:0666 dev:293,0 ino:885 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 218: S_IFREG mode:0600 dev:181,65539 ino:135527 uid:5202 gid:5202 size:147456 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desmiscKey.bdb 219: S_IFSOCK mode:0666 dev:293,0 ino:45058 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 220: S_IFSOCK mode:0666 dev:293,0 ino:21878 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.72.16 port: 42544 221: S_IFSOCK mode:0666 dev:293,0 ino:19270 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 58317 222: S_IFSOCK mode:0666 dev:293,0 ino:20674 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.50 port: 53196 223: S_IFSOCK mode:0666 dev:293,0 ino:40873 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 224: S_IFSOCK mode:0666 dev:293,0 ino:31203 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 225: S_IFSOCK mode:0666 dev:293,0 ino:29294 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 34144 226: S_IFSOCK mode:0666 dev:293,0 ino:23936 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60182 227: S_IFSOCK mode:0666 dev:293,0 ino:35233 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 55970 228: S_IFSOCK mode:0666 dev:293,0 ino:15817 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 229: S_IFSOCK mode:0666 dev:293,0 ino:26811 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.224.3.143 port: 48789 230: S_IFSOCK mode:0666 dev:293,0 ino:18245 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.12 port: 44229 231: S_IFREG mode:0600 dev:181,65539 ino:135526 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/desmailKey.bdb 232: S_IFSOCK mode:0666 dev:293,0 ino:18209 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46950 233: S_IFSOCK mode:0666 dev:293,0 ino:2933 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46745 234: S_IFSOCK mode:0666 dev:293,0 ino:1808 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 235: S_IFSOCK mode:0666 dev:293,0 ino:35819 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.168 port: 56541 236: S_IFSOCK mode:0666 dev:293,0 ino:53314 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.121.28 port: 19711 237: S_IFSOCK mode:0666 dev:293,0 ino:32806 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.44.12 port: 61215 238: S_IFSOCK mode:0666 dev:293,0 ino:5889 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46968 239: S_IFSOCK mode:0666 dev:293,0 ino:52624 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 240: S_IFSOCK mode:0666 dev:293,0 ino:42649 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 241: S_IFSOCK mode:0666 dev:293,0 ino:32034 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 242: S_IFSOCK mode:0666 dev:293,0 ino:54880 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 46970 243: S_IFSOCK mode:0666 dev:293,0 ino:18979 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.168 port: 59407 244: S_IFSOCK mode:0666 dev:293,0 ino:20157 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46746 245: S_IFSOCK mode:0666 dev:293,0 ino:41522 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.236 port: 46747 246: S_IFSOCK mode:0666 dev:293,0 ino:35438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 247: S_IFSOCK mode:0666 dev:293,0 ino:41284 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.122.237 port: 56119 248: S_IFSOCK mode:0666 dev:293,0 ino:35438 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 249: S_IFSOCK mode:0666 dev:293,0 ino:53888 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 250: S_IFREG mode:0600 dev:181,65539 ino:135540 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/oncRpcNumber.bdb 251: S_IFSOCK mode:0666 dev:293,0 ino:23358 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 252: S_IFREG mode:0600 dev:181,65539 ino:135530 uid:5202 gid:5202 size:3727360 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/entryUUID.bdb 254: S_IFSOCK mode:0666 dev:293,0 ino:34685 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60180 255: S_IFSOCK mode:0666 dev:293,0 ino:18793 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.45.28 port: 51381 256: S_IFSOCK mode:0666 dev:293,0 ino:21254 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 257: S_IFREG mode:0600 dev:181,65539 ino:135529 uid:5202 gid:5202 size:19202048 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/entryCSN.bdb 258: S_IFSOCK mode:0666 dev:293,0 ino:35422 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.74 port: 32823 259: S_IFSOCK mode:0666 dev:293,0 ino:35784 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49619 260: S_IFSOCK mode:0666 dev:293,0 ino:43450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 54525 261: S_IFSOCK mode:0666 dev:293,0 ino:26304 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.45.27 port: 51371 262: S_IFSOCK mode:0666 dev:293,0 ino:18977 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 54171 263: S_IFSOCK mode:0666 dev:293,0 ino:37236 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43090 264: S_IFSOCK mode:0666 dev:293,0 ino:17964 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39096 265: S_IFSOCK mode:0666 dev:293,0 ino:18467 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 266: S_IFSOCK mode:0666 dev:293,0 ino:16010 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 42788 267: S_IFSOCK mode:0666 dev:293,0 ino:35435 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 59822 268: S_IFSOCK mode:0666 dev:293,0 ino:20225 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 269: S_IFSOCK mode:0666 dev:293,0 ino:32038 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 42042 270: S_IFSOCK mode:0666 dev:293,0 ino:1126 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 271: S_IFSOCK mode:0666 dev:293,0 ino:23605 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49627 272: S_IFSOCK mode:0666 dev:293,0 ino:42171 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 273: S_IFSOCK mode:0666 dev:293,0 ino:37693 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 274: S_IFSOCK mode:0666 dev:293,0 ino:22161 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35552 275: S_IFSOCK mode:0666 dev:293,0 ino:28632 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 276: S_IFSOCK mode:0666 dev:293,0 ino:22124 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39115 277: S_IFSOCK mode:0666 dev:293,0 ino:31347 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 39116 278: S_IFSOCK mode:0666 dev:293,0 ino:37025 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 279: S_IFSOCK mode:0666 dev:293,0 ino:35228 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.204 port: 50620 280: S_IFSOCK mode:0666 dev:293,0 ino:42648 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 60181 281: S_IFSOCK mode:0666 dev:293,0 ino:60569 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43403 282: S_IFSOCK mode:0666 dev:293,0 ino:20313 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.162 port: 45147 283: S_IFSOCK mode:0666 dev:293,0 ino:22164 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 43406 284: S_IFSOCK mode:0666 dev:293,0 ino:19448 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 285: S_IFSOCK mode:0666 dev:293,0 ino:44598 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37757 286: S_IFSOCK mode:0666 dev:293,0 ino:28744 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 287: S_IFSOCK mode:0666 dev:293,0 ino:19667 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 288: S_IFSOCK mode:0666 dev:293,0 ino:40038 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 289: S_IFSOCK mode:0666 dev:293,0 ino:35608 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 290: S_IFSOCK mode:0666 dev:293,0 ino:31693 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.75.244 port: 32836 291: S_IFSOCK mode:0666 dev:293,0 ino:16014 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 292: S_IFSOCK mode:0666 dev:293,0 ino:44595 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 36515 293: S_IFSOCK mode:0666 dev:293,0 ino:40037 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37639 294: S_IFSOCK mode:0666 dev:293,0 ino:20155 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.40 port: 58314 295: S_IFSOCK mode:0666 dev:293,0 ino:34817 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 296: S_IFSOCK mode:0666 dev:293,0 ino:938 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 297: S_IFSOCK mode:0666 dev:293,0 ino:18980 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 298: S_IFSOCK mode:0666 dev:293,0 ino:41201 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 37080 299: S_IFSOCK mode:0666 dev:293,0 ino:15894 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.148 port: 62875 300: S_IFREG mode:0600 dev:181,65539 ino:135541 uid:5202 gid:5202 size:16384 O_RDWR|O_CREAT|O_LARGEFILE FD_CLOEXEC /var/openldap/nyc.deshaw.com/data/ou.bdb 301: S_IFSOCK mode:0666 dev:293,0 ino:43450 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 52054 302: S_IFSOCK mode:0666 dev:293,0 ino:60574 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 49628 303: S_IFSOCK mode:0666 dev:293,0 ino:38153 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 49097 305: S_IFSOCK mode:0666 dev:293,0 ino:18982 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 306: S_IFSOCK mode:0666 dev:293,0 ino:47193 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37646 307: S_IFSOCK mode:0666 dev:293,0 ino:32723 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(232.193.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 10.77.73.102 port: 32798 309: S_IFSOCK mode:0666 dev:293,0 ino:8500 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 311: S_IFSOCK mode:0666 dev:293,0 ino:17011 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37647 313: S_IFSOCK mode:0666 dev:293,0 ino:28725 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 35591 315: S_IFSOCK mode:0666 dev:293,0 ino:33273 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.192.0.0) sockname: AF_INET 0.0.0.0 port: 0 316: S_IFSOCK mode:0666 dev:293,0 ino:35225 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.122.166 port: 37648 330: S_IFSOCK mode:0666 dev:293,0 ino:41741 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.75.154 port: 44958 331: S_IFSOCK mode:0666 dev:293,0 ino:43200 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 40602 341: S_IFSOCK mode:0666 dev:293,0 ino:43449 uid:0 gid:0 size:0 O_RDWR|O_NONBLOCK SOCK_STREAM SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49232),IP_NEXTHOP(80.192.0.0) sockname: AF_INET 149.77.73.35 port: 389 peername: AF_INET 149.77.73.108 port: 49838 ########## # pstack # ########## 12612: /usr/local/pkgs/openldap-2.4.25/libexec/slapd -u ldap -g ldap -h ldap: ----------------- lwp# 1 / thread# 1 -------------------- fffffd7fff31ca7a lwp_wait (2, fffffd7fffdffbe4) fffffd7fff313b5e _thrp_join () + 3e fffffd7fff313d3c pthread_join () + 1c 000000000046a012 slapd_daemon () + 13a 0000657361626174 ???????? () ----------------- lwp# 2 / thread# 2 -------------------- fffffd7fff31c58a pollsys (fffffd7fbb3fe510, 44, fffffd7fbb3ff290, 0) fffffd7fff2c33a4 pselect () + 154 fffffd7fff2c3672 select () + 72 000000000046910f ???????? () 000000007c020002 ???????? () ----------------- lwp# 3 / thread# 3 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b0208, fffffd7ffc8b01f0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 4 / thread# 4 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc86c7b0, fffffd7ffc86c798, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 5 / thread# 5 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8bcc10, fffffd7ffc8bcbf8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 6 / thread# 6 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8aff38, fffffd7ffc8aff20, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 7 / thread# 7 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc918a10, fffffd7ffc9189f8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 8 / thread# 8 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8c7bd8, fffffd7ffc8c7bc0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 9 / thread# 9 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8684a8, fffffd7ffc868490, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 10 / thread# 10 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b41c8, fffffd7ffc8b41b0, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 11 / thread# 11 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc7055c0, fffffd7ffc7055a8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 12 / thread# 12 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b0118, fffffd7ffc8b0100, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 13 / thread# 13 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc901f40, fffffd7ffc901f28, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 14 / thread# 14 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc895610, fffffd7ffc8955f8, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 15 / thread# 15 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8abf78, fffffd7ffc8abf60, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 16 / thread# 16 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc86da70, fffffd7ffc86da58, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 17 / thread# 17 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc8b2c38, fffffd7ffc8b2c20, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? () ----------------- lwp# 18 / thread# 18 -------------------- fffffd7fff31cb1a lwp_cond_wait (fffffd7ffc888b18, fffffd7ffc888b00, 0, 1) fffffd7fff310ef9 cond_wait_kernel () + 59 fffffd7fff311094 cond_wait_common () + 134 fffffd7fff3112a7 _cond_wait () + 47 fffffd7fff3112e6 cond_wait () + 26 fffffd7fff311329 pthread_cond_wait () + 9 fffffd7ffec927ab __db_pthread_mutex_lock () + 163 0000000000000000 ???????? ()

2 1

"Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by Jarl Stefansson 28 Apr '11

28 Apr '11

Two servers running OpenLDAP in master/master using syncrepl, roughly once per week one of the servers stops responding to new connections, I tried logging with loglevel=1 and this is all I got, all suggestions and comments appreciated. This is most likely a "load" related problem since we never experience this problem in the testlab, only production.: Apr 23 20:36:37 ldap01 slapd2.4[32233]: bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") Apr 23 20:36:37 ldap01 slapd2.4[32233]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and initiated. I have two Centos 5 servers running Openldap 2.4.22 with master/master syncrepl setup, Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 operations/tasks to finish Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean shutdown detected; attempting recovery. Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting ---------------------- Relevant Config ------------------------------------------------ moduleload syncprov.la TLSCertificateFile /etc/pki/tls/private/ldap.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem TLSCACertificateFile /etc/pki/tls/private/ldap.pem serverID 001 database bdb sizelimit 50000 cachesize 10000 checkpoint 256 5 syncrepl rid=001 provider=ldap://10.10.10.10:389 bindmethod=simple binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" credentials=MyPassword searchbase="o=xxxx" schemachecking=on sizelimit="unlimited" timelimit="unlimited" type=refreshAndPersist interval=00:00:00:10 retry="5 5 60 +" attrs="*,+" mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 idletimeout 3600 threads 32 --------------------------------------------------------------- -- Regards Jarl jarl(a)dallur.com

2 1

Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com 27 Apr '11

27 Apr '11

--On Wednesday, April 27, 2011 2:26 AM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 That should be windows. ;) --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

(ITS#6918) #include statement unsafe
by quanah＠zimbra.com 26 Apr '11

26 Apr '11

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) An include statement in slapd.conf with no following text will overwrite slapd.exe as a zero sized binary when it occurs on a windows box. line 8 (include) slapd.conf: line 8: keyword <include> missing <file> argument slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. After this windows does not recognize slapd.exe as a normal windows app.. It has become 0 size

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by ebackes＠symas.com 26 Apr '11

26 Apr '11

The openldap-techincal traffic Michael mentioned is almost certainly the same issue. In our case, yes this could have appeared as early as 2.4.23. What I'm seeing now is that formerly memberof functioned with accesslog in a delta-syncrepl type environment by having each stage of replication (master, hub, replica, etc) run the overlay to supply the changes. It seems like originally only the group change went through and the overlay relied on reqStart collisions to prevent its internal operations from reaching the replication log. So: the recent change that exposed this was something that changed the order these things are applied and sent to accesslog. Changing memberof again to reveal only the group changes should probably a separate ITS, or perhaps a discussion (openldap-devel) on how we want it to work. As-is, the fix in git master breaks compatibility with configurations from prior releases. Emily Backes Symas - The LDAP Guys ebackes(a)symas.com

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 26 Apr '11

26 Apr '11

Further observations show that... 1. processing add requests seems to behave like expected. 2. it depends on the assertion filter sent in the control value: $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f uidnumber_clash.ldif -e 'assert=(cn=*)' modifying entry "uid=ttester,dc=stroeder,dc=de" ldap_modify: Operations error (1) additional info: unique_search failed $ ldapmodify -H ldap://localhost -D "uid=Mstroeder,dc=stroeder,dc=de" -W -f uidnumber_clash.ldif -e 'assert=(objectClass=*)' modifying entry "uid=ttester,dc=stroeder,dc=de" ldap_modify: Constraint violation (19) additional info: some attributes not unique

1 0

(ITS#6917) slapo-unique: filter in unique_uri not evaluated
by michael＠stroeder.com 26 Apr '11

26 Apr '11

Full_Name: Michael Ströder Version: 2.4.25 OS: openSUSE Linux URL: Submission from: (NULL) (195.145.144.134) I'd like to set a unique constraint on attribute gidNumber solely in entries of object class posixGroup. Therefore in slapd.conf I've added: unique_uri "ldap:///dc=stroeder,dc=de?gidNumber?sub?(objectClass=posixGroup)" But the unique constraint is also applied to entries of object class posixUser.

1 0

(ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 26 Apr '11

26 Apr '11

Full_Name: Michael Ströder Version: 2.4.25 OS: openSUSE Linux URL: Submission from: (NULL) (195.145.144.134) If an assertion control is sent along with a modify request slapo-unique returns operation error with diagnostic message "unique_search failed" instead of returning constraint violation.

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 24 Apr '11

24 Apr '11

Hopefully nobody else than me has wasted his/her time reviewing my previously submitted patches related to this ITS. They are completely wrong! Here you'll find a rewritten version from scratch which should work as expected or at least can be taken as a basis for further reviewing: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424-2.patch

1 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs
by daniel＠pluta.biz 24 Apr '11

24 Apr '11

this micro-patch "works for me": ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424.patch Disclaimer: I don't know the details regarding the need for normalization but ... ... to my current knowledge and opposed to authDNs, there's no need to normalize authcIDs at all? slapd's behaviour before the patch: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1001] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=userHAHAHA,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=userhahaha,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=userhahaha,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=userhahaha,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=userhahaha,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)'} slap_parseURI: parsing ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha) ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)) put_filter: "(userLogin=userhahaha)" slapd's behaviour after the patch has been applied: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth ==>slap_sasl2dn: converting SASL name uid=userHAHAHA,cn=DIGEST-MD5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)'} slap_parseURI: parsing ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA) ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)) put_filter: "(userLogin=userHAHAHA)" put_filter: simple put_simple_filter: "userLogin=userHAHAHA" note, the userLogin attribute is defined using octetString-Syntax and thus is compared case sensitive

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by michael＠stroeder.com 24 Apr '11

24 Apr '11

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4.25 > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > In recent OpenLDAPs (2.4.25 at least, but I haven't found exactly where > it started), memberof interacts badly with accesslog. See also: http://www.openldap.org/lists/openldap-technical/201104/msg00242.html > In a simple test case with a groupOfNames and two people, if you add a > person to the group, memberOf should set their memberOf opeational > attribute to point to the group. That works! But currently the > accesslog db will only show the change for the memberof update and not > the original group change. I can confirm that. > Digging deeper, I found: > [..] > The changes are reaching accesslog, but don't make it into the logdb > because their generated DNs based on reqStart match. Ah, that explains it. > reqStart is generated with a generalizedTime stamp where the > microseconds are an incrementing count based on o_tincr, but this does > not seem to be incremented, or incremented enough. > > It's not entirely clear why this is a problem now and not earlier. Maybe it was always a problem. Because I've started the thread above before installing 2.4.25: http://www.openldap.org/lists/openldap-technical/201103/msg00032.html I had 2.4.24 or 2.4.23 installed back then. > This may be related to ITS#6766. Seems similar and the group modification is the same like in cases where I observed the behaviour described in my postings. Ciao, Michael.

1 0

Re: (ITS#6914) Feature Request: slapd.conf "include" extension
by marco.pizzoli＠gmail.com 24 Apr '11

24 Apr '11

--0015175746fc400b2404a1a5d46f Content-Type: text/plain; charset=ISO-8859-1 On 23 Apr 2011 21:08, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: > > > > --On April 23, 2011 1:17:44 PM +0000 marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.x >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (217.133.1.151) >> >> >> Hi, >> this is a feature request. >> > > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does. > > --Quanah > > I know that. Btw I'm still hoping that slapd.conf will not be dismissed... --0015175746fc400b2404a1a5d46f Content-Type: text/html; charset=ISO-8859-1 <p><br> On 23 Apr 2011 21:08, "Quanah Gibson-Mount" <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> wrote:<br> ><br> ><br> ><br> > --On April 23, 2011 1:17:44 PM +0000 <a href="mailto:marco.pizzoli@gmail.com">marco.pizzoli(a)gmail.com</a> wrote:<br> ><br> >> Full_Name: Marco Pizzoli<br> >> Version: 2.4.x<br> >> OS: Linux<br> >> URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a><br> >> Submission from: (NULL) (217.133.1.151)<br> >><br> >><br> >> Hi,<br> >> this is a feature request.<br> >><br> ><br> > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does.<br> ><br> > --Quanah<br> ><br> ></p> <p>I know that. Btw I'm still hoping that slapd.conf will not be dismissed...</p> --0015175746fc400b2404a1a5d46f--

1 0

Re: (ITS#6909)
by hyc＠symas.com 23 Apr '11

23 Apr '11

diego.jesus.granados.lopez(a)ericsson.com wrote: > --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > It was difficult to achieve, but I was able to include several errors (rega= > rding line numbers) in my two-line patch XD Thanks for the report and patch. I've committed a different solution in HEAD, please test. > > The correct one: > > --- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c 200= > 9-08-14 22:54:14.000000000 +0200 > +++ ./servers/slapd/back-meta/search.c 2011-04-15 13:11:51.395261000 +0200 > @@ -309,6 +309,8 @@ > > if ( rc =3D=3D LDAP_SUCCESS ) { > candidates[ candidate ].sr_msgid =3D META_M= > SGID_IGNORE; > + binddn =3D msc->msc_bound_ndn; > + cred =3D msc->msc_cred; > goto retry; > } > } > > > Regards, > Diego -- -- 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#6915) memberof+accesslog duplicate reqStart
by ebackes＠symas.com 23 Apr '11

23 Apr '11

Full_Name: Emily Backes Version: 2.4.25 OS: any URL: Submission from: (NULL) (76.88.107.46) In recent OpenLDAPs (2.4.25 at least, but I haven't found exactly where it started), memberof interacts badly with accesslog. In a simple test case with a groupOfNames and two people, if you add a person to the group, memberOf should set their memberOf opeational attribute to point to the group. That works! But currently the accesslog db will only show the change for the memberof update and not the original group change. Digging deeper, I found: ==> hdb_add: reqStart=20110422103943.000001Z,cn=log oc_check_required entry (reqStart=20110422103943.000001Z,cn=log), objectClass "auditModify" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "reqStart" oc_check_allowed type "reqEnd" oc_check_allowed type "reqType" oc_check_allowed type "reqSession" oc_check_allowed type "reqAuthzID" oc_check_allowed type "reqDN" oc_check_allowed type "reqResult" oc_check_allowed type "reqMod" bdb_dn2entry("reqStart=20110422103943.000001Z,cn=log") send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=68 matched="" text="" The changes are reaching accesslog, but don't make it into the logdb because their generated DNs based on reqStart match. reqStart is generated with a generalizedTime stamp where the microseconds are an incrementing count based on o_tincr, but this does not seem to be incremented, or incremented enough. It's not entirely clear why this is a problem now and not earlier. This may be related to ITS#6766.

1 0

Re: (ITS#6914) Feature Request: slapd.conf "include" extension
by quanah＠zimbra.com 23 Apr '11

23 Apr '11

--On April 23, 2011 1:17:44 PM +0000 marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.133.1.151) > > > Hi, > this is a feature request. > slapd.conf is being phased out. I cannot imagine why anyone would work on extending what it does. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6914) Feature Request: slapd.conf "include" extension
by marco.pizzoli＠gmail.com 23 Apr '11

23 Apr '11

Full_Name: Marco Pizzoli Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.133.1.151) Hi, this is a feature request. I would like to extend "include" directive of slapd.conf by having defined a default path in witch beginning to search for the filename specified by "include" directive(s). In short I would like to mimic the behaviour of "modulepath" and "moduleload" directives. "includepath" could be a suggestion of the name of this new directive. Thanks Marco

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 21 Apr '11

21 Apr '11

Once again an update of this patch: One more step further dnattr's documented behaviour: Now the DN in dnattr is additionally allowed to remove the whole entry. The update can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110422.patch I'm not quite satisfied with my code and its internal processing. It's more some kind of a prototype. Probably you guys do have the knowlege to "convert" it into a better and slapd-like design... Thanks a lot!

1 0

Re: (ITS#6873) Feature request slapo-lastbind: authTimestamp and relax rules control
by michael＠stroeder.com 21 Apr '11

21 Apr '11

I tried to find the magic flag where to put SLAP_AT_MANAGEABLE but failed. It must be something emotional with C code on my side... ;-) Ciao, Michael.

1 0

Re: (ITS#6911) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

> > Patches welcome. > I would like to contribute but I'm not a developer and I have no overlay development documentation available Marco

1 0

Re: (ITS#6913) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

I had a refresh on the submit page. This erroneous ITS can be closed, sorry. On Thu, Apr 21, 2011 at 1:33 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6913. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6913) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6913) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6913 > > Please remember to retain your issue tracking number (ITS#6913) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

1 0

(ITS#6913) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

Full_Name: Marco Pizzoli Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) This is a feature request. I would like to further extend accesslog filtering capabilities. It would be useful to me exclude logging of operations made by a specific user (DN). My usage case is a DBMS (DB2) using native LDAP authentication, which does extensive search operations on my DIT (quite 2 millions searches per day per instance). I assigned a specific technical user (DN) to these DB2 instancies and so I am able to identify operations made by those users. This filter would allow me to reduce very much my accesslog db size and augment my data retention. Thanks Marco Pizzoli

1 0

(ITS#6912) authz-regexp DN
by daniel＠pluta.biz 21 Apr '11

21 Apr '11

Full_Name: authz-regex dnNormalize() filter expression with matching rule assertion Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:fe00:200:5efe:81bb:f4c) We tried to support/implement case-sensitive logins using SASL DIGEST-MD5. Imagine the following partial authz-regexp statement: ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=$1) During "dnNormalize" the uid is transformed into lowercase which cause the caseExactMatch to fail: SASL [conn=1010] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=user1HAHA,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=user1HAHA,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=user1HAHA,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=user1HAHA,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=user1HAHA,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=user1HAHA,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=user1haha)'}

1 0

Re: (ITS#6911) Feature Request: accesslog filter on DN
by hyc＠symas.com 21 Apr '11

21 Apr '11

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.174.164.11) > > > This is a feature request. > > I would like to further extend accesslog filtering capabilities. > It would be useful to me exclude logging of operations made by a specific user > (DN). > > My usage case is a DBMS (DB2) using native LDAP authentication, which does > extensive search operations on my DIT (quite 2 millions searches per day per > instance). > I assigned a specific technical user (DN) to these DB2 instancies and so I am > able to identify operations made by those users. > > This filter would allow me to reduce very much my accesslog db size and augment > my data retention. Patches welcome. -- -- 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#6911) Feature Request: accesslog filter on DN
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

Full_Name: Marco Pizzoli Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) This is a feature request. I would like to further extend accesslog filtering capabilities. It would be useful to me exclude logging of operations made by a specific user (DN). My usage case is a DBMS (DB2) using native LDAP authentication, which does extensive search operations on my DIT (quite 2 millions searches per day per instance). I assigned a specific technical user (DN) to these DB2 instancies and so I am able to identify operations made by those users. This filter would allow me to reduce very much my accesslog db size and augment my data retention. Thanks Marco Pizzoli

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 21 Apr '11

21 Apr '11

It works! :-) In next 2 days I will test other configurations and I will let you know! By now, thanks a lot! Marco On Wed, Apr 20, 2011 at 9:26 PM, Howard Chu <hyc(a)symas.com> wrote: > Marco Pizzoli wrote: >> >> Trying a more complex configuration I found my first problem. >> This is my configuration: >> >> logbase session dc=mycorp,dc=mydc.it >> logbase all ou=groups,dc=mycorp,dc=mydc.it >> logbase all ou=people,dc=mycorp,dc=mydc.it >> >> Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an >> authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", >> I obtain this accesslog >> >> >> # 20110420141404.000000Z, log03, mydc.it >> dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it >> objectClass: auditBind >> reqStart: 20110420141404.000000Z >> reqEnd: 20110420141404.000001Z >> reqType: bind >> reqSession: 1000 >> reqAuthzID: >> reqDN: cn=manager,dc=mycorp,dc=mydc.it >> reqResult: 0 >> reqVersion: 3 >> reqMethod: SIMPLE >> >> # 20110420141404.000002Z, log03, mydc.it >> dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it >> objectClass: auditSearch >> reqStart: 20110420141404.000002Z >> reqEnd: 20110420141404.000003Z >> reqType: search >> reqSession: 1000 >> reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it >> reqDN: ou=groups,dc=mycorp,dc=mydc.it >> reqResult: 0 >> reqScope: sub >> reqDerefAliases: never >> reqAttrsOnly: FALSE >> reqFilter: (cn=minnie) >> reqAttr: dn >> reqEntries: 0 >> reqTimeLimit: -1 >> reqSizeLimit: -1 >> >> As you can see, there isn't the unbind operation log... >> It's an error of mine? >> > Looks like Unbind has not been modified to handle logbase yet. Will fix this > shortly. > > -- > -- 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

1 0

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

20 Apr '11

Marco Pizzoli wrote: > Trying a more complex configuration I found my first problem. > This is my configuration: > > logbase session dc=mycorp,dc=mydc.it > logbase all ou=groups,dc=mycorp,dc=mydc.it > logbase all ou=people,dc=mycorp,dc=mydc.it > > Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an > authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", > I obtain this accesslog > > > # 20110420141404.000000Z, log03, mydc.it > dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it > objectClass: auditBind > reqStart: 20110420141404.000000Z > reqEnd: 20110420141404.000001Z > reqType: bind > reqSession: 1000 > reqAuthzID: > reqDN: cn=manager,dc=mycorp,dc=mydc.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > > # 20110420141404.000002Z, log03, mydc.it > dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it > objectClass: auditSearch > reqStart: 20110420141404.000002Z > reqEnd: 20110420141404.000003Z > reqType: search > reqSession: 1000 > reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it > reqDN: ou=groups,dc=mycorp,dc=mydc.it > reqResult: 0 > reqScope: sub > reqDerefAliases: never > reqAttrsOnly: FALSE > reqFilter: (cn=minnie) > reqAttr: dn > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: -1 > > As you can see, there isn't the unbind operation log... > It's an error of mine? > Looks like Unbind has not been modified to handle logbase yet. Will fix this shortly. -- -- 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 20 Apr '11

20 Apr '11

Trying a more complex configuration I found my first problem. This is my configuration: logbase session dc=mycorp,dc=mydc.it logbase all ou=groups,dc=mycorp,dc=mydc.it logbase all ou=people,dc=mycorp,dc=mydc.it Using my rootdn (cn=manager,dc=mycorp,dc=mydc.it) and submitting an authenticated ldapsearch under base "ou=groups,dc=mycorp,dc=mydc.it", I obtain this accesslog # 20110420141404.000000Z, log03, mydc.it dn: reqStart=20110420141404.000000Z,cn=log03,dc=mydc.it objectClass: auditBind reqStart: 20110420141404.000000Z reqEnd: 20110420141404.000001Z reqType: bind reqSession: 1000 reqAuthzID: reqDN: cn=manager,dc=mycorp,dc=mydc.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE # 20110420141404.000002Z, log03, mydc.it dn: reqStart=20110420141404.000002Z,cn=log03,dc=mydc.it objectClass: auditSearch reqStart: 20110420141404.000002Z reqEnd: 20110420141404.000003Z reqType: search reqSession: 1000 reqAuthzID: cn=manager,dc=mycorp,dc=mydc.it reqDN: ou=groups,dc=mycorp,dc=mydc.it reqResult: 0 reqScope: sub reqDerefAliases: never reqAttrsOnly: FALSE reqFilter: (cn=minnie) reqAttr: dn reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: -1 As you can see, there isn't the unbind operation log... It's an error of mine?

1 0

Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com 20 Apr '11

20 Apr '11

I compiled HEAD/Master branch and I tried setting logbase directive. It seems to work as requested! Thanks Marco

1 0

(ITS#6909)
by diego.jesus.granados.lopez＠ericsson.com 18 Apr '11

18 Apr '11

--_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It was difficult to achieve, but I was able to include several errors (rega= rding line numbers) in my two-line patch XD The correct one: --- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c 200= 9-08-14 22:54:14.000000000 +0200 +++ ./servers/slapd/back-meta/search.c 2011-04-15 13:11:51.395261000 +0200 @@ -309,6 +309,8 @@ if ( rc =3D=3D LDAP_SUCCESS ) { candidates[ candidate ].sr_msgid =3D META_M= SGID_IGNORE; + binddn =3D msc->msc_bound_ndn; + cred =3D msc->msc_cred; goto retry; } } Regards, Diego --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Arial, sans-serif" size=3D"2"> <div>It was difficult to achieve, but I was able to include several errors = (regarding line numbers) in my two-line patch XD </div> <div> </div> <div>The correct one: </div> <div> </div> <div>--- ../../origtmp/openldap-2.4.21/servers/slapd/back-meta/search.c&nbs= p;     2009-08-14 22:54:14.000000000 +0200</div> <div>+++ ./servers/slapd/back-meta/search.c  2011-04-15 13= :11:51.395261000 +0200</div> <div>@@ -309,6 +309,8 @@</div> <div> </div> <div>           &nbs= p;             = if ( rc =3D=3D LDAP_SUCCESS ) {</div> <div>           &nbs= p;            &= nbsp;        candidates[ candidate ].sr_= msgid =3D META_MSGID_IGNORE;</div> <div>+          &nbsp= ;            &n= bsp;       binddn =3D msc->msc_bound_ndn;<= /div> <div>+          &nbsp= ;            &n= bsp;       cred =3D msc->msc_cred;</div> <div>           &nbs= p;            &= nbsp;        goto retry;</div> <div>           &nbs= p;             = }</div> <div>           &nbs= p;     }</div> <div> </div> <div> </div> <div>Regards, </div> <div>Diego</div> <div> </div> </font> </body> </html> --_000_7A5601613D0AF042A5EDA8C8A7AA805D0E3E82C53DESESSCMS0356e_--

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 15 Apr '11

15 Apr '11

Hi, it's me again, with another small but also very important bugfix for the previous two versions of my patch. This patch does not change the correct (as documented by the project) behaviour of "dnattr=... selfwrite". It can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110415.patch FYI and the log: Next to some simple always reproducible test-shellscripts (ldapmodify add/delete distinct values) I have been also using Apache Directory Studio to test and workout the intended behavior of my ACLs, which is the root cause for these two updates: I've not been aware of the difference between "to value" and "to all values", yet and all my testcases (ldif changetype modify) only have been using "to value" operations. I've used following ACL to test this second patch of my original patch: access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users read by * none access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description by users read by * none break access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member by dnattr=member selfwrite by * none Based on these ACL each user that is a member of a group entry seems to be just the only member of these group (from the user's point of view, in case the user accesses the group's member attribute by read). When using Apache Directoy Studio to delete this only/single/last group member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation. => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr "member" requested => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0) It seems to me that this appears to be a bug in ADS, where the client (ADS) tries to be more inteligent/comfortable/strict than needed. OTOH based on this strange behaviour I've learned something "new" (and quite important to me in regard to acl design and testcases during testing). Sorry for these kind of SPAM and the circumstances. Hopefully that's the last bugfix for that patch.

1 0

Re: (ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by rmeggins＠redhat.com 15 Apr '11

15 Apr '11

When https://bugzilla.mozilla.org/show_bug.cgi?id=172051 is fixed, error messages will magically appear.

1 0

Re: (ITS#6908) Query
by h.b.furuseth＠usit.uio.no 15 Apr '11

15 Apr '11

preeti(a)omnimessaging.com writes: > My OpenLdap Client file "ldapmodify" is missing. > Can you please provide me with the "openldap-client-2.3.32.tgz" file. Ask whoever provided your OpenLDAP installation. The OpenLDAP project distributes only source code, and openldap-2.3.32.tgz does include ldapmodify. Also, the ITS system is for bug reports, not help requests. The openldap-technical mailinglist is for issues related to use of OpenLDAP. https://www.openldap.org/lists/mm/listinfo/openldap-technical -- Regards, Hallvard

1 0

(ITS#6910) Ldap fails to start when duplicate entries are in /etc/hosts
by quanah＠zimbra.com 14 Apr '11

14 Apr '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) If an IP address entry for a host appears more than once in /etc/hosts, slapd fails to start, complaining the port is already in use. Failed to start slapd. Attempting debug start to determine error. daemon: listen(ldap://zre-ldap002.eng.vmware.com:389, 5) failed errno=98 (Address already in use) Sample /etc/hosts: zimbra@zre-ldap002:~$ cat /etc/hosts 127.0.0.1 localhost 10.137.242.52 zre-ldap002.eng.vmware.com zre-ldap002 10.137.242.52 zre-ldap002.eng.vmware.com zre-ldap002 It appears that we don't validate whether or not we've already tried to start up on a given interface...

1 0

(ITS#6909) High asynchronous traffic handled by back-meta causes multiple err=34 errors
by diego.jesus.granados.lopez＠ericsson.com 14 Apr '11

14 Apr '11

Full_Name: Diego Granados López Version: 2.4.21 OS: SUSE Linux Enterprise Server 10 SP3 (x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) The issue arises when running a large number (200+) of asynchronous clients issuing queries vs slapd. Back-meta is configured to use a single remote target. Eventually, during a connection re-bind (function meta_search_dobind_init), one thread goes into the block of code which starts on line 322: case LDAP_SERVER_DOWN: down:; /* This is the worst thing that could happen: * the search will wait until the retry is over. */ in that block, the meta_single_conn is cleaned up inside the call: meta_clear_one_candidate( op, mc, candidate ); Inside that function, the msc->msc_bound_ndn memory is freed if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) { ber_memfree_x( msc->msc_bound_ndn.bv_val, NULL ); BER_BVZERO( &msc->msc_bound_ndn ); } ; later, the call rc = meta_back_init_one_conn( op, rs, mc, candidate, LDAP_BACK_CONN_ISPRIV( mc ), LDAP_BACK_DONTSEND, 0 ); takes the connection to a healthy state again, but the problem is that binddn & cred vars, which had been assigned at function start, struct berval binddn = msc->msc_bound_ndn, cred = msc->msc_cred; are not being assigned to the new correct values, and after going into "goto retry" call, those vars are used in the bind retry, but they are pointing still to the previously freed memory , containing garbage). The remote server shows the incorrect content of the dns being send: cat /var/log/ldapfe* | grep "invalid dn (" Apr 8 12:41:17 xx slapd[10482]: conn=47925 op=0 do_bind: invalid dn ( Iµ) Apr 8 12:41:17 xx slapd[10482]: conn=47926 op=0 do_bind: invalid dn (àí@ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47928 op=0 do_bind: invalid dn (`úö¯ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47929 op=0 do_bind: invalid dn (0÷¯ª*) Apr 8 12:41:17 xx slapd[10482]: conn=47927 op=0 do_bind: invalid dn (èº¬ª*) slapd[10482]: conn=47925 fd=155 ACCEPT from IP=172.80.0.168:56451 (IP=0.0.0.0:389) Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=0 do_bind: invalid dn ( Iµ) Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=0 RESULT tag=97 err=34 text=invalid DN Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 op=1 UNBIND Apr 8 12:41:17 PL_2_3 slapd[10482]: conn=47925 fd=155 closed Please find attached our proposed patch for this: --- servers/slapd/back-meta/search.c 2011-04-11 11:23:14.000000000 +0200 +++ /home/devel/ediegra_[...]/bin/openldap-2.4.21/servers/slapd/back-meta/search.c 2011-04-14 11:21:03.000000000 +0200 @@ -363,6 +363,10 @@ if ( rc == LDAP_SUCCESS ) { candidates[ candidate ].sr_msgid = META_MSGID_IGNORE; + binddn = msc->msc_bound_ndn; + cred = msc->msc_cred; goto retry; } } Kind regards, Diego

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by quanah＠zimbra.com 13 Apr '11

13 Apr '11

--On Wednesday, April 13, 2011 3:09 PM +0000 quanah(a)zimbra.com wrote: As a follow up -- This issue is caused by instantiating overlays outside of the database. Specifically this will trigger the problem: # INCLUDES include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/dyngroup.schema # RUNFILE LOCATIONS pidfile /usr/local/var/run/openldap/slapd.pid argsfile /usr/local/var/run/openldap/slapd.args security ssf=127 # MODULES modulepath /usr/local/libexec/openldap moduleload back_hdb moduleload refint moduleload dynlist moduleload memberof # OVERLAYS AND OVERLAY CONFIG overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=EMPTY overlay dynlist dynlist-attrset groupOfURLs memberURL member overlay memberof memberof-refint TRUE # DATABASE database hdb directory /usr/local/var/openldap-data # GLOBAL LDAP SETTINGS suffix "dc=example,dc=org" rootdn "cn=root,dc=example,dc=org" rootpw blahblahblah # SSL / TLS - note - these are all real, valid, issued certs. TLSCACertificatePath /etc/ssl/certs TLSCACertificateFile /etc/ssl/certs/gd_bundle.crt TLSCertificateFile /etc/ssl/certs/ldap.example.org.combined.crt TLSCertificateKeyFile /etc/ssl/private/ldap.example.org.key access to * by * write # PERFORMANCE index objectClass eq index cn eq,sub,pres,approx index uid eq,sub,pres index sn eq,sub,approx index member eq index givenName eq,sub,approx index mail eq,sub,approx #limits limits users size=10000 size.pr=unlimited -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by catchall＠bromberger.com 13 Apr '11

13 Apr '11

It went on for screens; here's the top of it: (gdb) thr apply all bt full Thread 3 (Thread 0x7ffff48fb700 (LWP 12771)): #0 0x00000000004d2d7d in over_op_func (op=0x0, rs=0x0, which=op_bind) at backover.c:698 oi = 0x0 on = 0x0 be = 0x0 db = {bd_info = 0x0, bd_self = 0x0, be_ctrls = '\000' <repeats 32 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 0, lms_t_hard = 0, lms_s_soft = 0, lms_s_hard = 0, lms_s_unchecked = 0, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_NONE, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0, sc_cleanup = 0, sc_private = 0x0} sc = 0x0 rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #1 0x00000000004d31f1 in over_aux_chk_controls (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:814 No locals. #2 0x0000000000454d49 in backend_check_restrictions (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, opdata=0x0) at backend.c:1039 fssf = 0x45419a bssf = 0x0 rc = 32768 i = 0 restrictops = 0 requires = 0 ---Type <return> to continue, or q <return> to quit--- opflag = 9482848 exopflag = 0 ssfs = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0x7ffff40fc220 updateop = 0 starttls = 0 session = 0 #3 0x000000000044580a in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:340 bd = 0x7ffff40fc3d0 #4 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #5 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, ---Type <return> to continue, or q <return> to quit--- __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fc670, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #7 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fc6c0 #8 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #9 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, ---Type <return> to continue, or q <return> to quit--- be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fc960, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #11 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fc9b0 #12 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #13 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, ---Type <return> to continue, or q <return> to quit--- be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fcc50, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #14 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #15 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fcca0 #16 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #17 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fcf40, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #18 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #19 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fcf90 #20 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #21 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, ---Type <return> to continue, or q <return> to quit--- sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd230, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #22 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #23 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd280 #24 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #25 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, ---Type <return> to continue, or q <return> to quit--- be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd520, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #26 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #27 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd570 #28 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #29 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 ---Type <return> to continue, or q <return> to quit--- oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fd810, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #30 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #31 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fd860 #32 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 ---Type <return> to continue, or q <return> to quit--- func = 0x80c078 rc = 32768 #33 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fdb00, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #34 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #35 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) ---Type <return> to continue, or q <return> to quit--- at search.c:372 bd = 0x7ffff40fdb50 #36 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #37 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fddf0, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" ---Type <return> to continue, or q <return> to quit--- #38 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #39 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fde40 #40 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #41 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x809780, be_private = 0x90b3f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff40fe0e0, sc_response = 0x4d19e4 <over_back_response>, sc_cleanup = 0, ---Type <return> to continue, or q <return> to quit--- sc_private = 0x90a760} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #42 0x00000000004d3023 in over_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at backover.c:748 No locals. #43 0x00000000004459e9 in fe_op_search (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0) at search.c:372 bd = 0x7ffff40fe130 #44 0x00000000004d2cce in overlay_op_walk (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search, oi=0x90a760, on=0x0) at backover.c:669 func = 0x80c078 rc = 32768 #45 0x00000000004d2f0c in over_op_func (op=0x7ffff48f9df0, rs=0x7ffff48f9cd0, which=op_search) at backover.c:721 oi = 0x90a760 on = 0x90afd0 be = 0x90b260 db = {bd_info = 0x80c020, bd_self = 0x90b260, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 127, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x90a240, be_nsuffix = 0x90c9f0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 27, bv_val = 0x90cb60 "cn=root,dc=energysec,dc=org"}, be_rootndn = { bv_len = 27, bv_val = 0x90cbb0 "cn=root,dc=energysec,dc=org"}, be_rootpw = {bv_len = 38, bv_val = 0x90c8c0 "{SSHA}SzNdsqMzXBawtR/jr3jHWYZBzdr/eD0J"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x90ce20, be_acl = 0x90f1d0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b66c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, ...

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by catchall＠bromberger.com 13 Apr '11

13 Apr '11

I don't know whether I did it correctly, but here's my first attempt at a gdb backtrace. Note that it keeps going - I went to #7500 before I gave up - it was just repeating, e.g., lines 5-7. Does this help? What else should I be providing? Seth. Starting program: /usr/local/libexec/slapd -d 256 -h "ldaps:///" -u openldap -g openldap -f /usr/local/etc/openldap/slapd.conf [Thread debugging using libthread_db enabled] ... conn=1000 op=4 MODRDN dn="uid=myuid,ou=Testing,dc=example,dc=org" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff4901700 (LWP 12020)] 0x000000000049af05 in ?? () (gdb) backtrace #0 0x000000000049af05 in ?? () #1 0x00000000004421e3 in backend_check_restrictions () #2 0x0000000000437220 in fe_op_search () #3 0x000000000049a577 in overlay_op_walk () #4 0x000000000049afb8 in ?? () #5 0x00000000004373f1 in fe_op_search () #6 0x000000000049a577 in overlay_op_walk () #7 0x000000000049afb8 in ?? () #8 0x00000000004373f1 in fe_op_search () #9 0x000000000049a577 in overlay_op_walk () #10 0x000000000049afb8 in ?? () #11 0x00000000004373f1 in fe_op_search () #12 0x000000000049a577 in overlay_op_walk () #13 0x000000000049afb8 in ?? () #14 0x00000000004373f1 in fe_op_search () #15 0x000000000049a577 in overlay_op_walk () #16 0x000000000049afb8 in ?? () #17 0x00000000004373f1 in fe_op_search () #18 0x000000000049a577 in overlay_op_walk () #19 0x000000000049afb8 in ?? () #20 0x00000000004373f1 in fe_op_search () #21 0x000000000049a577 in overlay_op_walk () #22 0x000000000049afb8 in ?? () #23 0x00000000004373f1 in fe_op_search () #24 0x000000000049a577 in overlay_op_walk () #25 0x000000000049afb8 in ?? () #26 0x00000000004373f1 in fe_op_search () #27 0x000000000049a577 in overlay_op_walk () #28 0x000000000049afb8 in ?? () #29 0x00000000004373f1 in fe_op_search () #30 0x000000000049a577 in overlay_op_walk () #31 0x000000000049afb8 in ?? () #32 0x00000000004373f1 in fe_op_search () #33 0x000000000049a577 in overlay_op_walk () #34 0x000000000049afb8 in ?? () #35 0x00000000004373f1 in fe_op_search () #36 0x000000000049a577 in overlay_op_walk () #37 0x000000000049afb8 in ?? () #38 0x00000000004373f1 in fe_op_search () #39 0x000000000049a577 in overlay_op_walk () #40 0x000000000049afb8 in ?? () #41 0x00000000004373f1 in fe_op_search ()

1 0

Re: (ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by quanah＠zimbra.com 13 Apr '11

13 Apr '11

--On Wednesday, April 13, 2011 12:26 AM +0000 openldap(a)bromberger.com wrote: > Full_Name: Seth > Version: 2.4.25 > OS: Linux (Ubuntu) 2.6.35.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.13.140.242) > > > Using Apache Directory Studio to interface with hdb-based openldap server > via TLS. Moving a DN from one ou to another crashes slapd. The move (the > first one if there are multiples) appears to work before slapd segfaults. > An example in the logfile: > > > Apr 12 17:17:52 ldap slapd[11278]: conn=1000 op=13 MODRDN > dn="uid=someuserid,ou=Organizations,dc=example,dc=org" > Apr 12 17:17:52 ldap kernel: [974579.184525] slapd[11281]: segfault at > 7f0bdfab7ff8 ip 000000000049af05 sp 00007f0bdfab8000 error 6 in > slapd[400000+19e000] > > This is 100% reproducible. Also affects 2.4.23-0ubuntu3.5 (ubuntu > package) - I upgraded from source to try to work around this bug. > Please provide a gdb backtrace. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6789)
by sgallagh＠redhat.com 13 Apr '11

13 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has there been any progress on this issue? It causes a lot of headaches trying to debug connection issues in SSSD. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lsTIACgkQeiVVYja6o6Nh7wCdF5Sn/IsMpNH9gB8WA9A7tEgB ctUAoKPTUIL1rfZPnArrNBmAxQ/VuEq7 =DxDR -----END PGP SIGNATURE-----

1 0

(ITS#6908) Query
by preeti＠omnimessaging.com 13 Apr '11

13 Apr '11

Full_Name: Preeti Version: 2.3.32 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.143.122.119) My OpenLdap Client file "ldapmodify" is missing. Can you please provide me with the "openldap-client-2.3.32.tgz" file.

1 0

(ITS#6907) openldap 2.4.25 segfaults when using apache directory studio to rename objects
by openldap＠bromberger.com 12 Apr '11

12 Apr '11

Full_Name: Seth Version: 2.4.25 OS: Linux (Ubuntu) 2.6.35.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.13.140.242) Using Apache Directory Studio to interface with hdb-based openldap server via TLS. Moving a DN from one ou to another crashes slapd. The move (the first one if there are multiples) appears to work before slapd segfaults. An example in the logfile: Apr 12 17:17:52 ldap slapd[11278]: conn=1000 op=13 MODRDN dn="uid=someuserid,ou=Organizations,dc=example,dc=org" Apr 12 17:17:52 ldap kernel: [974579.184525] slapd[11281]: segfault at 7f0bdfab7ff8 ip 000000000049af05 sp 00007f0bdfab8000 error 6 in slapd[400000+19e000] This is 100% reproducible. Also affects 2.4.23-0ubuntu3.5 (ubuntu package) - I upgraded from source to try to work around this bug.

1 0

(ITS#6906) fix Admin guide cachesize calculations to remove refence to Hash-format
by Tim.Mooney＠ndsu.edu 12 Apr '11

12 Apr '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/TimMooney-110412-04.patch Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) As I mentioned here: http://www.openldap.org/lists/openldap-technical/201104/msg00088.html and Quanah clarified here: http://www.openldap.org/lists/openldap-technical/201104/msg00123.html The admin guide chapter on tuning still mentions that indexes are in Hash format, though that's no longer true. I've uploaded patch TimMooney-110412-04.patch against HEAD that clarifies that indexes are now also in B-tree format and so the same calculations for cache on dn2id can be used with each index. I also corrected one other typo, changing To avoid thrashing the, your cache to To avoid thrashing, your cache

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs