Libtool library linking (ITS#3776)

s compiled. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operations against schools and libraries are stronger than ever in the present religio-political climate. They

Re: Libtool library linking (ITS#3776)

--On Thursday, June 30, 2005 9:58 AM -0700 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: At 05:03 PM 6/28/2005, Quanah Gibson-Mount wrote: This particular change in behavior is really impacting my ability to easily build OpenLDAP. It's unclear to me how this change

Re: Bug in slapi_int_init_connection

Although, may be it'll be better, if Operation allocation would be define as function in slapd/operation.c and slap_op_alloc and slapi_int_init_conenction would call to the same function. Best, Nikita -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford Univer

Re: leaks in slapd

n a 32 bit environment, but neither of those patches solved the problem. So at this point, it is not clear where specifically the problem lies (somewhere between slapd & heimdal). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University G

Re: back-config design considerarions - Admin Guide fodder

extensively to switch between configuration files on the same host, which is a lot simpler than mucking around with various config backends. Other people may want to keep their slapd.conf files for things like version control, etc, as well. --Quanah -- Quanah Gibson-Mount Principal Software

Re: back-config design considerarions - Admin Guide fodder

nsequently to avoid inconsistencies and double effort. And sometimes, there is more than one route to a destination, each route with its pros and cons. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.e

Re: back-config design considerarions - Admin Guide fodder

--On Thursday, July 28, 2005 8:51 PM +0200 Michael Ströder <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount wrote: => One has to decide which route to go and after that one has to follow that route consequently to avoid inconsistencies and double effort. And sometimes, there is

Re: back-config design considerarions - Admin Guide fodder

--On Thursday, July 28, 2005 1:46 PM -0700 Howard Chu <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount wrote: --On Thursday, July 28, 2005 8:07 PM +0200 Michael Ströder <[EMAIL PROTECTED]> wrote: > Quanah, I do see all the advantages of slapd.conf mentioned above. > But I a

OpenLDAP and OpenSSL 0.9.8

ion to the server, but at least compiling works just fine, and that is where the user reported a problem. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

2.3.6?

Is 2.3.6 being released today/this weekend? Just curious. :) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operations against schools and libraries are str

Re: Revamping statslog (loglevel 256) output

sult entry/referral. < Final response to a request (or maybe unsolicited notification). - Not I/O, just change of state or something. Hm.. I like my error codes, really. Makes quick searching through the ldap log grep err= /var/log/ldap | grep -v err=0 to find anything interestin

tool mode & syslog

Tool mode (slapadd, slapcat, slapindex) commands continue to log to the default syslog levels instead of local4, meaning that important messages do not get into custom ldap logs if they are specified in syslog.conf. See ITS#3937 for an example. --Quanah -- Quanah Gibson-Mount Principal

Re: slapadd -q (quick mode)

that -q applies to slapindex, where I've had a single indexing time drop from 35 minutes to two minutes because of it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "T

Re: slapadd -q (quick mode)

--On Friday, August 26, 2005 7:09 PM +0200 Hallvard B Furuseth <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount writes: <[EMAIL PROTECTED]> wrote: slapadd -q has been entirely safe for me as long. The point of that paragraph is that if you kill slapadd, or an error occurs during

Re: slapadd -q (quick mode)

--On Friday, August 26, 2005 9:36 AM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: I'll also note that -q applies to slapindex, where I've had a single indexing time drop from 35 minutes to two minutes because of it. For my db, today, "time slapindex" too

Re: Please test OPENLDAP_REL_ENG_2_3

ving directory `/usr/local/build/openldap-2.3.7-beta/tests' make: *** [test] Error 2 wrap: make test failed with exit status 2 ldap-dev0:/usr/local/build/openldap-2.3.7-beta/tests/data# ls -l slapd-v* ls: No match. ldap-dev0:/usr/local/build/openldap-2.3.7-beta/tests/data# --Quanah -

CVS server?

I've been attempting to update my REL_ENG_23 checkout for about an hour now with the latest checkins, and it isn't happening. Is there something wrong with the CVS server? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University Gn

Re: CVS server?

--On Monday, August 29, 2005 3:21 PM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: I've been attempting to update my REL_ENG_23 checkout for about an hour now with the latest checkins, and it isn't happening. Is there something wrong with the CVS server? It has

test039-glue-ldap-concurrency time...

dd/Delete done (0). PID=29165 - Search done (0). PID=29157 - Search done (0). PID=29476 - Read done (0). PID=29149 - Search done (0). PID=29239 - Search done (0). PID=29434 - Search done (0). PID=29462 - Search done (0). ^^^ is where it has been for about the last 40 minutes. Note

Re: test039-glue-ldap-concurrency time...

--On Monday, August 29, 2005 4:51 PM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: I've noticed on several occasions that test039-glue-ldap-concurrency takes an extremely long time to run. Currently, on my dev box it is at 50 minutes. Is this normal on all platforms, or

Major crashes in syncprov.c

My 2.3.6 test master server is no longer stable, and crashes in syncprov every time, after a process made modifications to it today. Just a heads up if 2.3.7 is in progress, we may want to hold on this. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford

Re: Major crashes in syncprov.c

--On Tuesday, August 30, 2005 8:01 PM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: My 2.3.6 test master server is no longer stable, and crashes in syncprov every time, after a process made modifications to it today. Just a heads up if 2.3.7 is in progress, we may want to h

Re: Please test OPENLDAP_REL_ENG_2_3

guessing, since it isn't in 2.3.7. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operations against schools and libraries are stronger than ever in t

Import Cache vs. Running cache

rmance from the running process (a good size entry/idl cache). This would easily allow the flexibility, without having to manually go and hack DB_CONFIG and then recreate the DB environment all the time. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford U

Enough for a new release?

Curious if there are enough fixes now for a new 2.3 release... Syncprov is finally working, and some other interesting commits to back-ldap and back-sql have been going through. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public

Re: ITS#3611 Index clustering patch for fast slapadd

igate a separate DB_CONFIG for slapadd as well (as per my 9/8/2005 email "Import Cache vs. Running cache"). Only available if you use back-config would be my thought. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http:

back-hdb and HEAD

tial improvement. ;) --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

Syncrepl: full sync vs. delta

syncrepl (via accesslog) is that there is no way for a slave to become fully refreshed if its contextCSN is out of date. It looks like this would take an extension to the syncrepl protocol for this to be done properly. Objections? comments? --Quanah -- Quanah Gibson-Mount Principal Software D

Re: ITS#3975: Lightweight Listener

vious implementations (ITS#3835) had a 5% performance decrease on systems that were purely busy. I won't be able to get to that until after 10/17 however, as I'm in the process of moving. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford Un

Re: Syncrepl: full sync vs. delta

crepl with a fallback of a full refresh, don't the CSN's need to be coordinated between the accesslog backend and their main (bdb/hdb) backend? I'm guessing that is what you mean will happen in the SLAP_DBFLAG_DEFER_CSN bit. --Quanah -- Quanah Gibson-Mount Principal Software Deve

Re: order of attribute values

sent since 2.3.7 and later). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operations against schools and libraries are stronger than ever in the present religi

Re: order of attribute values

g of elements in a SET OF AttributeValues and, hence, makes no attempt to maintain that order or any other perceived ordering. (ignoring certain slapd(8) cn=config extensions to LDAP) Unless of course, you use the valsort overlay. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS

Re: syncrepl refresh

write my LB software to see if it is refreshing, and keep it out of the pool until it isn't. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operation

Re: syncrepl refresh

date with the log, but for regular syncrepl there's still no distinction. That is fine by me, I plan on using delta-syncrepl. ;) Is there a way to query the consumer to see if it is in refresh-only mode (like via back-monitor)? --Quanah -- Quanah Gibson-Mount Principal Software Develope

Re: upgrading source base from 2.2.19 to 2.3.11

've made sure that domain is defined in the schema. Are you loading the cosine.schema? That is where the domain objectClass is defined. BTW, one would usually use the "dcObject" objectClass here rather than "domain". --Quanah -- Quanah Gibson-Mount Principal Soft

Re: slapadd/slapindex

1:/tmp/db# time slapadd -q -l dev1-db [] (100%) 01h25m 367339 obj 10425.20u 2625.06s 1:29:58.64 241.7% Which is approximately 1 hour less than it took before threaded slapindex -- A *major* performance improvement. --Quanah -- Quanah Gibson-Mount Pr

Re: slapadd/slapindex

--On Thursday, October 27, 2005 2:36 PM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: --On Thursday, October 27, 2005 5:08 AM -0700 Howard Chu <[EMAIL PROTECTED]> wrote: Using two threads (my machine is dual-core) the slapindex -q time is now only 10 minutes, using a

Re: ltdl support in 2.3.x

y-developed dependent libraries as they are, well, independently developed. We rather not maintain a separate copy or the issues that result from doing so. And some of us don't want OpenLDAP linked against libltdl.so at all. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS

Re: [Fwd: Re: (ITS#4108) LWL causing core dumps in HEAD]

second. Another way to think of it is that HEAD with LWL is 23% slower than 2.3. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2.3 updates?

least when these fixes will get merged into REL_23? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: 2.3 updates?

--On Monday, October 31, 2005 1:11 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: There have been some significant fixes checked into HEAD for issues in 2.3, most specifically the fixes for delta-syncrepl and the fixes to connection management issues (ITS#4108) that are se

Re: [Fwd: commit: ldap/servers/slapd connection.c]

e gain at all with HEAD as I increased the number of querying clients -- Rates dropped off the same as they did in 2.3.11. So this may prevent connections from being deferred, but it doesn't appear to allow any more work to be done, at least where READs are concerned. --Quanah -- Qu

Re: RE23 ready for release

file. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html "These censorship operations against schools and libraries are stronger than ever in the present religio-political climate

Re: RE23 ready for release

:50:36 ldap9.Stanford.EDU slapd[28393]: [ID 167594 local4.debug] conn=11685 op=3 SEARCH RESULT tag=101 err=1 nentries=0 text=SASL bind in progress --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.e

Re: RE23 ready for release

--On Saturday, November 05, 2005 12:05 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Looking at the log on my one production 2.3 system seems to indicate this is likely the case, and given that this is impacting production servers, I'm gonna have to drop it out of the p

Re: RE23 ready for release

--On Saturday, November 05, 2005 3:04 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: --On Saturday, November 05, 2005 12:05 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Looking at the log on my one production 2.3 system seems to indicate this is likely t

ODD in 2006?

I see there is a small note on the conferences site about a possible ODD this spring in Europe. Is there any more detail on this? I'd like to go, and my manager supports me in that, but I'd need some advance time to get things put together to go... --Quanah -- Quanah Gibson-Mount

Re: ODD in 2006?

--On Monday, November 14, 2005 8:57 AM -0800 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: At 02:42 PM 11/11/2005, Quanah Gibson-Mount wrote: I see there is a small note on the conferences site about a possible ODD this spring in Europe. Is there any more detail on th

RE22

Just to note, that until Howard's patches get into the 2.2 tree, SASL binds are *broken* in 2.2. So, the new release will be broken unless the bind_cb changes are reverted, or the fixes are backported to 2.2. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Ser

BDB 4.4 and configure

run a MOD/ADD test against it yet outside of slapadd. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

Re: BDB 4.4 and configure

--On Wednesday, November 16, 2005 9:08 AM -0800 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: At 09:01 PM 11/15/2005, Quanah Gibson-Mount wrote: It might be worthwhile to update configure to build against BDB 4.4 (which will be going GA very soon). So far, none of the i

Re: [ANNOUNCE] Berkeley DB 4.4.16 (fwd)

? (I'd probably run mine monthly or something. :P ). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: replicated cn=config

have to try delta-syncrepl instead. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: replicated cn=config

--On Monday, November 21, 2005 10:42 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Then either slurpd or syncrepl can be used to keep the slaves' configurations up to date. To follow up on this, it is impossible to do this with slurpd unless you are using simple bin

Re: replicated cn=config

--On Monday, November 21, 2005 11:15 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: --On Monday, November 21, 2005 10:42 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Then either slurpd or syncrepl can be used to keep the slaves' configurations up to

Re: ACL state & value dependent ACLs

Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: file name and stable tag to 2.3.13 (was: Openldap 2.3.11 cannot autorecover from abnormal shutdown.)

--On Tuesday, December 20, 2005 9:23 AM +0100 Michael Ströder <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount wrote: --On Tuesday, December 20, 2005 11:20 AM +0800 Yingbo Qiu <[EMAIL PROTECTED]> wrote: If the slapd was killed by SIGKILL(9), bdb database will be autorecovere

ITS#3950

--Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: ITS#3950

n RE23. Perhaps, but it could also be the case that changes made since 2.3.11 tend to make the issue more visible. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: Testing OPENLDAP_REL_ENG_2_3

--On Friday, January 06, 2006 12:51 PM -0800 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: Please test OPENLDAP_REL_ENG_2_3. It is hoped that .16 can be marked "stable" soon after its release... It passes all "make test" tests on my Solaris 8 system

http://www.openldap.org/faq/data/cache/44.html

This entry needs some major rewriting, as the BDB patch is no longer necessary in 2.3 (nor has been for several releases). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: http://www.openldap.org/faq/data/cache/44.html

--On Monday, January 09, 2006 2:04 PM -0800 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: At 01:46 PM 1/9/2006, Quanah Gibson-Mount wrote: This entry needs some major rewriting, as the BDB patch is no longer necessary in 2.3 (nor has been for several releases). The FA

Re: RE_23 hangs in test039 (back-hdb)

couple of hours with no hangs on my dual-core x86_64 Linux system. I'll try looping the other tests as well. I've been unable to reproduce the hang on my 4 CPU Solaris 8 system. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University G

Re: SASL_MECH and useronly

omeday). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

OpenLDAP 2.4 plans?

27;t need to be serialized) Just in case there isn't a defined project plan somewhere, I thought this might be useful for discussion pre-fork. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: obsoleting LDBM

7;t volunteered by Tuesday, I'll look at working on it, since it'll be back from vacation for me at that time. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: ITS#3950

k up. I then tested #define REPLACE_BROKEN_YIELD 1 #undef HAVE_NANOSLEEP This also brought performance back up. So some part of this change likely needs to be reverted, and is also likely the cause of the performance issue reports seen on -software. --Quanah -- Quanah Gibson-Mount Product Engi

Re: ITS#3950

--On Friday, January 13, 2006 11:28 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: I started benchmarking on OpenLDAP 2.3.17 tonight. I found that on Solaris, there was no change in performance over previous OpenLDAP releases. However, I found that on linux, performance o

Re: ITS#3950

--On Saturday, January 14, 2006 12:18 AM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Here is a further update. First, I note that the above tests, and the following, were all done on a Linux 2.4 kernel. I believe the REPLACE_BROKEN_YIELD bit *must* be disabled for 2.4 k

Re: ITS#3950

--On Saturday, January 14, 2006 11:59 PM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: If there is an X in the B/E/N column, it is defined. B N E R X X X 5,726.250 searches/second X X 5,626.316 searches/second X X 5,637.446 searches/second* X 5,764.666 searches/secon

2.3.18 not stable on Solaris

servers/slapd/daemon.c. I'm guessing that a small 2.3.19 release might be worthwhile. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: 2.3.18 not stable on Solaris

s more than once a second). Prior to 2.3.18, I had *never* hit it running a slamd job. I had a patch from Howard in place to prevent slapd from shutting down when it occurred (its close to the fix in HEAD) so that I could log how often it happened. --Quanah -- Quanah Gibson-Mount Principal Soft

Re: 2.3.18 not stable on Solaris

--On Friday, January 20, 2006 11:21 AM -0800 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: --On Friday, January 20, 2006 2:16 PM -0500 Aaron Richton <[EMAIL PROTECTED]> wrote: How reliably are you reproducing this with, say, test008? (I'm not sure what your definiti

Re: cn=config

Not sure why you answered to -devel instead of -software, but... --On Monday, February 20, 2006 3:03 PM -0700 Jon Roberts <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount wrote: Here are the reasons I would like to use cn=config: (a) The ability to modify ACL's on the f

Re: JLDAP, TLS, and DNS

caching off isn't an option for some reason I don't recall. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: slapd quits under heavy load

rious problems with your OS. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: slapd quits under heavy load

to get triggered when there are serious problems with your OS. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html We're running Openldap 2.2.23 under Solaris 8 Generi

2.3.21

Is there any traction on getting a 2.3.21 cut? There have been some issues fixed, and the ucgen* stuff is causing a lot of incoming bugs... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http

Re: SIGSEGV in OpenLDAP 2.3.20 Stable

also note that it looks like you are using LDBM in OL 2.3, which is generally recommended against for OL 2.2-OL 2.3.It will be removed from the OL 2.4 release branch. You may wish to switch off of using LDBM, see: <http://www.openldap.org/faq/data/cache/756.html> for the various r

RE_23 updates

. The fix for ITS#4433 is in place (Fixing the arguments to threads, and documenting it) has been done, but is not in the CHANGES file. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http

Re: RE_23 updates

--On Wednesday, April 05, 2006 11:33 PM +0200 Pierangelo Masarati <[EMAIL PROTECTED]> wrote: On Wed, 2006-04-05 at 13:56 -0700, Quanah Gibson-Mount wrote: Large parts of the fix for ITS#4419 that I sent to the committers list is missing still. This is back-meta related, I

Re: RE_23 updates

--On Wednesday, April 05, 2006 2:45 PM -0700 Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote: Also the forced commit to uctable.h for ITS#4415 has not been done for RE_23. This final bit is still missing. I know it is only a timestamp update, but we got a bunch of ITS's and e

Re: RE_23 updates

CVS web repository at the CHANGES file and see the descriptions for the fixed ITS', or check out the RE_23 tree and read it there. If nothing addresses what you've seen, then file an ITS. And please keep replies to the list. Thanks, Quanah Quanah Gibson-Mount wrote: The fix for ITS#4

Pending issues of concern for RE_23 & 2.3.21

0, proto-slap.h 1.669->1.670). ITS#4477, which actually answers some questions I've seen in the past about large group membership adds failing. (servers/slapd/sl_malloc.c 1.37->1.39). The one here I'm somewhat unsure of is ITS#4476. Thoughts on all this welcome. ;) --Qua

RE_23 passes all tests on Solaris 8

RE_23 currently passes all tests for me on Solaris 8. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

More 2.4 possibilities

follow-up. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: tuning.sdf needs updating for 2.4

anah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: server unavailable in proxy backends

u'll note the weights are factors of 10 in this case. What this means (with ldap-mail1, for example) is that if the load on ldap1 is more than 10 times that of ldap2, the pool return ldap2 instead. Essentially, I think this problem should be solvable with a weighted load balancing

Re: server unavailable in proxy backends

t membership in the pool is controlled by a client on the ldap server. If a given ldap server (or set of ldap servers) drops into a crack opened up by an earthquake, they are no longer listed as part of the pool. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Appl

slapd lightweight dispatcher

slapdindex as well, and the tool-threads parameter could be replaced by the new one. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

Re: slapd lightweight dispatcher

d systems) are doing 30-40 searches/second while the 2.3.21 systems (ldap4-ldap7) are doing 6.5-9 searches/second. The graph also demonstrates how the two upgraded systems have consistently outperformed the other ldap servers in the pool since being upgraded. --Quanah -- Quanah Gibso

Re: LDAP load testing (Was: Re: slapd lightweight dispatcher)

uanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: Patch against 2.3.24 // wishlist

ches should generally be contributed via the ITS system at <http://www.openldap.org/its/>. Please read: <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University

Re: Patch against 2.3.24 // wishlist

Do you agree? I'm sure Pierangelo will be happy to discuss that with you, since he maintains back-sql. please keep replies to the list. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Incompatibilities between 2.1 ldapsearch and 2.3 servers?

="dc=stanford,dc=edu" scope=2 deref=0 filter="(suPrivilegeGroup=stanford:staff)" Jul 17 09:58:14 ldap1 slapd[16672]: conn=27534 op=4 SRCH attr=suregid Jul 17 09:58:14 ldap1 slapd[16672]: conn=27534 op=5 UNBIND Jul 17 09:58:14 ldap1 slapd[16672]: conn=27534 fd=376 closed

Re: Incompatibilities between 2.1 ldapsearch and 2.3 servers?

--On Monday, July 17, 2006 10:41 AM -0700 Howard Chu <[EMAIL PROTECTED]> wrote: Quanah Gibson-Mount wrote: I thought that the "ldapsearch" binary from any given release should work with a server running a different release, but this does not appear to be the case. Our 2.3.

Re: RE23 ready for release

--On Tuesday, August 15, 2006 10:13 AM -0700 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: Please test. Thanks, Kurt Built and tested on Solaris 8 w/ Howards latest checkins... All tests passed. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Sh

Re: commit: ldap/servers/slapd DB_CONFIG

old DB_CONFIG is necessary before the update will proceed. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: Is back-perl still required?

understood the need or desire to use the various back-(shell, tcl, perl) bits, but that is probably because I use OpenLDAP purely as an LDAP server. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: better malloc strategies?

a minimum to start, we could add a --with-umem flag to configure, and then build liblber with it as a replacement for the standard memory allocator if it is found, right? ;) Because the improvements we got were enormous. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Sh

  1   2   3   4   5   6   7   8   >