Howard Chu writes:
That's interesting. That would require receiving a Hangup event on a
descriptor we've already removed from epoll's event list. How can that be?
OS bug? Race condition?
Valgrind bug, since it so far will only happen under Valgrind?
Have you seen this with CONNS debug
I wrote:
Howard Chu writes:
That's interesting. That would require receiving a Hangup event on a
descriptor we've already removed from epoll's event list. How can that be?
OS bug? Race condition?
Valgrind bug, since it so far will only happen under Valgrind?
Happened without Valgrind
h...@openldap.org writes:
set SLEEP1 default to 7 seconds, 5 is sometimes too short for replication
Isn't there anything the tests can read e.g. once a second to see if
replication is done? Compare a contextCSNs of both servers, maybe?
--
Hallvard
Quanah Gibson-Mount wrote in openldap-technical:
You need to specify that you want to use the config db (-n 0) with your
slapadd command.
If neither -n nor -b is given, maybe slapadd should decide
which database to open from the DN of the first input entry?
--
Hallvard
Michael Ströder writes:
Hallvard B Furuseth wrote:
Quanah Gibson-Mount wrote in openldap-technical:
You need to specify that you want to use the config db (-n 0) with your
slapadd command.
If neither -n nor -b is given, maybe slapadd should decide
which database to open from the DN
h...@openldap.org wrote:
rewrite-int.h 1.24 -gt; 1.25
ITS#6005 librewrite must use the same mem allocators as slapd
If you are killing C free/mallocs, here are some others from 'nm *.o'
to look at. I don't have time at the moment. Hopefully most are
malloced/freed by the same code, not
Howard Chu writes:
ITS#6011 better fix for connection queue
It occurs to me that an even better fix may have been to provide an
ldap_pvt_thread_pool_cancel() function to remove submitted tasks that
haven't started yet. Any other uses for such a function?
For LDAP Abandon/Cancel requests,
Michael Ströder writes:
So this works great for you. But this won't work for others. And I'd
really like to know what's wrong with my suggestion to generally set
LD_LIBRARY_PATH in tests/scripts/defines.sh like this:
Does that help? man ld.so on RHEL 5.3 says $LD_LIBRARY_PATH is used
_after_
Howard Chu writes:
For backends that support the olcDbDirectory keyword, we should also
define a write-only olcDbMkdir attribute. If it's provided when
ldapadd'ing an olcDatabase entry, or when ldapmodifying, then its
values are treated as pathnames that we will attempt to create before
Howard Chu writes:
Since we're just talking about a simple for-loop, why are we even
bothering to look for strnlen() at all?
Now, that's a good point...
--
Hallvard
Ralf Haferkamp writes:
Btw, you mentioned that sending Abandon 0 will be sufficient as a no-op.
How's
that going to work?
It's a no-op, thus it can be sent when you just want to send some message:
* The Abandon request has no reponse.
* rfc4511 §4.11: Servers MUST discard Abandon requests
Rein Tollevik writes:
The sufficient control should act like stop (i.e grant access) if
the effective access is sufficient for the requested access level,
continue otherwise.
It's access which grants access, stop just says don't look for
more access rules to apply. So this in particular
Howard Chu writes:
The basic idea is to construct a database that is always mmap'd to a
fixed virtual address, and which returns its mmap'd data pages directly
to the caller (instead of copying them to a newly allocated
buffer). Given a fixed address, it becomes feasible to make the on-disk
I ought to try syncrepl before talking too much, but anyway:
Quanah Gibson-Mount writes:
It sounds like it gracefully solves the ability of keeping both master
and replica configurations around for the most part. What still
remains sticky is ACLs. There are plenty of valid reasons for the
Rein Tollevik writes:
(...) Regexp matching of integer ranges is always awkward..
As is regexp matching of any complexity.
Hm, it might be sufficient with a syncrepl option that makes it match
entries against its configured searchbase and filter, and ignore entries
that fails to match.
Howard Chu writes:
The other alternative, which is much simpler to implement, is just to
add a suffixmassage/rewrite keyword to the syncrepl config, allowing
it to pull from a particular remote base and map it to the local
base. Then it's up to the sysadmin to create a complete cn=config
Howard Chu writes:
Hallvard B Furuseth wrote:
Unless you have different servers for different purposes, which share
_some_ data - e.g. a database with user/group info. Though then it may
be about time to give up the idea of replicating config. It might only
be feasible to replicate
Howard Chu writes:
Hallvard B Furuseth wrote:
Can translucent be made to combine with back-relay and rwm? Then the
other database need only maintain differences from the main config, and
there's less problem with keeping the two config databases in sync.
Translucent is currently a bit too
./configure --disable-backends --disable-overlays --enable-bdb --enable-dds \
CC=gcc CFLAGS=-g -O0 CPPFLAGS=-DLDAP_MEMORY_DEBUG -DSLAP_NO_SL_MALLOC
...
./run test046-dds
...
Re-vitalizing the initial dynamic entry...
Re-renaming the subordinate dynamic entry (new superior)...
Deleting a
Quanah Gibson-Mount wrote:
Please test RE24 and report any issues. All known regressions are now
believed fixed. Thanks!
test057-memberof-refint failed with hdb the 10th 'make test'.
testrun/ and testrun.out in
http://folk.uio.no/hbf/OpenLDAP/testrun-test057.tgz
Unexpected ldapsearch
I wrote:
test057-memberof-refint failed with hdb the 10th 'make test'.
testrun/ and testrun.out in
http://folk.uio.no/hbf/OpenLDAP/testrun-test057.tgz
Unexpected ldapsearch result, diff -U5 ldapsearch.flt ldif.flt shows
dn: cn=Roger Rabbit,ou=Toons,dc=example,dc=com
objectClass:
Jens Vagelpohl writes:
Starting test056-monitor ...
running defines.sh
Starting slapd on TCP/IP port ...
Using ldapsearch to check that slapd is running...
Using ldapsearch to read connection monitor entries...
Filtering ldapsearch results...
Comparing filter output...
comparison failed -
Quanah Gibson-Mount writes:
OL 2.4 with howard and hallvard's patches: 17,086 auths/second.
I'm tempted to backport the patches to 2.3 so we can compare with
what 2.3 could have been:-)
That still leaves us over 4,500 auths/second (or 9000 searches/second)
slower than RE2.3. I.e., 21.5%
Quanah Gibson-Mount writes:
h.b.furus...@usit.uio.no wrote:
Maybe --disable-debug is a place to fetch some speed. If it makes a
enough difference from loglevel 0, it might be an idea to disable _some_
loglevels and some asserts in the default build. (...)
I'm running with loglevel none,
Howard Chu writes:
I just did a quick review of the deref control code. I thought we had
already established this policy since the OpenLDAP 2.1 days: no more
naked char *'s in new code. Always use struct bervals, (...)
Yes, I remember that for data structures at least. And exposed
prototypes,
be to rewrite such code to extract the bv
members to a local variable, but that'd be more work per function.)
Howard Chu writes:
Hallvard B Furuseth wrote:
(...) it might be an idea to disable _some_
loglevels and some asserts in the default build. After we've done
something about that broken log
Aaron Richton writes:
On Sat, 1 Aug 2009, Howard Chu wrote:
OK, that lends some weight to the idea that we have too many
assert()s in the 2.4 code...
Or too many Debug()s. To test which, you could make include/ac/assert.h
contain just the line #include assert.h, then configure with one but
masar...@aero.polimi.it writes:
In fact, it makes no sense that ber_ptr ber_buf; if it happens, the
BerElement is corrupted, and an assertion failure may be more appropriate.
Right now, no test is done, and the (trivial) function could be replaced
with a macro... Since this is part of the
masar...@aero.polimi.it writes:
In fact, it makes no sense that ber_ptr ber_buf; if it happens, the
BerElement is corrupted, and an assertion failure may be more appropriate.
Right now, no test is done, and the (trivial) function could be replaced
with a macro... Since this is part of the
Howard Chu writes:
Looks like this is related to recent liblber changes. What's the test
environment that caused this? Can you reproduce it? And can you try again
using the 2.4.17 liblber?
...including 2.4.17/include/lber.h.
--
Hallvard
masar...@aero.polimi.it writes:
I'm inclined towards defining a private function, with an interface
analogous to that of the tread-safe function, and use it all times,
re-entrant as appropriate. If the re-entrant function is available, a
#define could be used instead. Otherwise, the wrapper
struct tm *ldap_pvt_gmtime(
const /* and LDAP_CONST in the .h file */
time_t *t, struct tm *tm)
{
struct tm *tm_ptr;
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_lock( gmtime_mutex );
#endif
tm_ptr = gmtime( t );
Howard Chu writes:
That's fine, but this tends to imply that the lutil_tm stuff needs to move
into libldap as well.
libldap already uses liblutil:
ldap_sync.c: lutil_uuidstr_from_normalized().
ac/string.h: #define memcmp lutil_memcmp, #define memrchr lutil_memrchr.
Of course, there's a lot
masar...@aero.polimi.it writes:
That code is only in use when sizeof(wchar_t) = 4. The C library
standard mandates wchar_t to be integer, thus signed. If I promote
0x8000 to 0x8000LL, when sizeof(wchar_t) == 4, like in my case,
the test will always be true, and the compiler will
masar...@aero.polimi.it writes:
Now C90 compilers get to warn about long long instead.
With the new #if SIZEOF_WCHAR_T 4, if(wchar (wchar_t)0x8000UL)
should be sufficient.
0x8000UL is == 0x8000, as costants = 0x are automatically
promoted to unsigned.
True enough, but
masar...@aero.polimi.it writes:
The gcc warning explained clearly enough what was wrong.
I meant: in terms of opportunity. You can fix it directly by declaring
the structure, or by anticipating the inclusion of lutil.h, since
ldap_pvt.h depends on it.
Fine by me either way. Users of the
back-ldap/bind.c needs lutil.h for lutil_strcopy().
Beyond that, passes all tests on Ubuntu --with-tls=gnutls.
--
Hallvard
Hallvard B Furuseth writes:
Beyond that, passes all tests on Ubuntu --with-tls=gnutls.
Correction, it passed with --enable-tls=gnutls, which is a no-op:-(
--with-tls=gnutls fails badly in liblutil/passwd.c:
./configure --prefix=/home/hbf/ldap/install --enable-aci --enable-crypt
I'm not sure how you expect a portable format anyway, when you are
planning to store pointers in the database. Even on hosts with the
same pointer format, I imagine which address ranges are available
for the fixed address may differ.
--
Hallvard
Howard Chu writes:
Yeah, it would require pretty near identical machines and software
configurations. And no address-space-layout-randomization. Never mind...
BTW, I hope an mdb database will eventually be recoverable with slapcat
if the fixed address becomes unavailable after an OS upgrade or
Howard Chu writes:
The obvious fix is to adopt the same strategies that tcmalloc uses. (And
unfortunately we can't simply rely on tcmalloc always being available, or
always being stable in a given environment.)
Good, though I'd like to see these slapd re-implementations of system
features
masar...@aero.polimi.it writes:
ITS#6337 seems to indicate that it's time to move bind response inside the
backends. Unfortunately right now the need to send bind response from
outside the backends is well-bundled into slapd, so the whole thing might
not be trivial.
Yes. Also Extended
Hallvard B Furuseth writes:
masar...@aero.polimi.it writes:
ITS#6337 seems to indicate that it's time to move bind response inside the
backends. Unfortunately right now the need to send bind response from
outside the backends is well-bundled into slapd, so the whole thing might
not be trivial
Still seems wrong: Caller passes len=500, generic_sb_sasl_write()
returns 0 or -1 with LDAP_PVT_SASL_PARTIAL_WRITE, caller collects 300
more bytes and passes len=800, then generic_sb_sasl_write() ignores
not 500 but 800 bytes and tells caller that they were all written.
Either make p-flags a
Michael Ströder writes:
Michael Ströder wrote:
Something's screwed up in BER decoding of RE24 now. I get a
LDAP_DECODING_ERROR but it used to work with former versions.
Workaround in HEAD: liblber/decode.c rev 1.129. Please test.
It was due to ITS#6353: reject embedded NUL bytes in plain
h...@openldap.org writes:
backend.c 1.412 - 1.413
ITS#6393 syncrepl internal connids are now = -1000
backend.c: 'op-o_connid = -1000' is wrong. o_connid is unsigned long,
so this is compiled as 'op-o_connid = (unsigned long) -1000'.
I haven't looked at possible connid values, but maybe
syncrepl.c accepts rids up to SLAP_SYNC_SID_MAX = 4095,
rather than up to SLAP_SYNC_RID_MAX = 999.
Also I suppose SLAPD_SYNC_SYNCCONN_OFFSET should be
-SLAP_SYNC_RID_MAX-1, so that constant is only hardcoded once.
(I don't know what a rid and a sid actually is though.)
--
Hallvard
a...@openldap.org writes:
config.c 1.506 - 1.507
silence signedness warnings
- } else if ( rc == ARG_BAD_CONF ) {
+ } else if ( (unsigned long)rc == ARG_BAD_CONF ) {
That breaks working code. Never shut up signedness warnings without
working
masar...@aero.polimi.it writes:
My PC is 32-bit, so int is 32-bit. If I do
int rc = 0xdead;
(0xdead == (unsigned long)rc) is true. Am I doing anything wrong?
Yes, I explained how. Test (0xdead == (unsigned long long)rc)
instead, then you'll see the problem with
h...@openldap.org writes:
ITS#6419 also init for ldaps:// URIs
Does it work for ldapi:// as well? (And should it?) I seem to
remember StartTLS does work for ldapi, though I don't know what
a sensible host name in the server cert would be in that case.
--
Hallvard
Howard Chu writes:
Hallvard B Furuseth wrote:
[Rearranging a little]
Since this is all ber/LBER, it should go in an lber_* header file, not
ac/assert.h.
OK. I guess that means
lber_pvt.h: ber_pvt_assertz(), ber_pvt_static_assert()
since on second thought I don't see much need to export
I wrote:
I too prefer to avoid a name parameter, so if a linker symbol is a
problem I suggest the __LINE__ variant for now. We can also add a
symbol the macro can use in the future, but not use it yet to keep
compatibility with existing binaries.
Add a linked symbol, I mean - extern const
r...@openldap.org writes:
ITS#6441 cyrus-sasl 2.1.24 auxprop_lookup plugin returns status.
+#if SASL_VERSION_FULL = 0x020118
If it's for 2.1.24, checking for 2.1.18 looks somewhat suboptimal.
--
Hallvard
Rein Tollevik writes:
24 decimal is 18 hexadecimal...
Duh... sorry.
--
Hallvard
Please use tab-width 4 like most of the rest of the code. Unless you
are in a tab-width 8 file, anyway. This mixture of tab-width 4 and 8
keeps misaligning more and more of the code, one line here and one there
over the years. In this case the 'struct ldif_tool' contents, which was
aligned
[Reply for reference, reflecting offline discussions]
Quanah Gibson-Mount writes:
sl_malloc.c 1.67 - 1.68
zn_malloc.c 1.14 - 1.15
Gentler message when falling back to ch_malloc
The new error message doesn't make sense, English wise. It doesn't even
parse.
-
masar...@aero.polimi.it writes:
ITS#6505: add const to attrs in libldap search API: not a big deal, it
would change a consolidated API, but the change should be harmless.
Not in the middle of RE24. It breaks code with function pointers to API
functions. Some compilers reject that, while
r...@openldap.org writes:
controls.c 1.212 - 1.213
new call unregister_supported_control(), will be
needed for cn=config delete support
Gcc complains about at this line:
slap_known_controls[i++] = slap_known_controls[i];
because you are mixing read and write of 'i'. Use
Pierangelo Masarati writes:
Modified Files:
extended.c 1.100 - 1.101
proto-slap.h 1.799 - 1.800
Log Message:
implement unload_extop for symmetry (needs test)
Quick comment for future reference: I've left the flags argument,
(...)
I've got an idea: If someone feels some code
Howard Chu writes:
Unfortunately, at this time writing lockless algorithms means
resorting to heavily machine-dependent code and we've been trying to
stick to standardized e.g. POSIX APIs. It would be pretty easy to
write a CPU-cache-friendly producer/consumer queue in assembly
language for a
Howard Chu writes:
What problems are we signing up for by allowing use of alloca()?
This is from memory, and for all I know outdated:
It's somewhat unportable, and alloca from GNU something (gcc? glibc?)
is or was a malloc wrapper on systems where it cannot provide a proper
alloca(). So I
man alloca on my Linux system says:
NOTES ON THE GNU VERSION
(...) there is no NULL error return.
BUGS
The alloca() function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
On many systems alloca() cannot be used inside
A reminder:
The OpenLDAP source code uses tab-width 4 and generally lines 80
chars. Please commit code written the same way, except in files
that are already written with tab-width 8.
Some people have been committing with tab-width 8, so the code now
contains a mixture of tab-width 4 and 8,
The ITS#6625 patch causes preprocessor warnings about conflicts
with ldap-int.h, so I'm looking again at old ITS#5421 to kill off
#include ...libldap/ldap-int.h
These occur in librewrite, rwm, back-ldap and back-meta.
The #include is for two things: Expose struct ldapmsg LDAP_FREE, the
masar...@aero.polimi.it writes:
I'd like to resolve the ITS#6645 issue, either by committing or wiping out
this patch from my working directory, as it conflicts with ITS#6737.
Comments?
OK, here's a comment:
If the slapmodify patch couldn't make do with the ldif patch as
written, this
Let's try to keep CHANGES talking in user-visible rather than
source-code-visible terms when that makes sense. Something like this:
Index: CHANGES
@@ -14 +14 @@
- Fixed slapd modify leaving rc uninitialized (ITS#6715)
+ Fixed slapd 'sortvals' of attributes with 1 value (ITS#6715)
@@
Moved from openldap-technical.
Hallvard B Furuseth writes:
[back-ldif] can leave behind a temporary file if you pull the plug on
slapd at just the wrong moment, when an entry is being written. That
won't affect the entry, but the parent entry cannot be deleted when
there are temporary files
a...@openldap.org writes:
fix cloak behavior; plug leak (ITS#6762)
Oh, there actually was a leak?:-) What I meant in ITS#6762 was
I assumed my workaround would have have introduced a leak.
--
Hallvard
Quanah Gibson-Mount writes:
This was just a checkpoint to make sure what was done so far doesn't break
anything.
Ah, OK.
Some issues it'd be nice to have in, if they're simple for those who
know the code in question:
ITS#6760 rwm broken entry handling
Fixed, I think, but needs review
May I wrap all foo-backend_op(op, rs) calls in new macros
SLAP_OP()/slap_be_op()/slap_bi_op()?
It's for ITS#6758, SlapReply cleanup. The macros expand to the
original code, except CPPFLAGS=-DSOMETHING uncovers a backend.c
function with assertions before and after the backend call. Also
code
I wrote:
Also, possibly the rest of ITS#6739 broken do_syncrep2() is simple.
Almost fixed.
If you get these committed, I can add them.
I've committed my part, but someone who knows syncrepl must do the rest.
OTOH... I've marked it Test, do import it. Just got reminded why I patched
it,
masar...@aero.polimi.it writes:
Not sure whether it is related, but I'm currently running test036 with
-DLDAP_THREAD_DEBUG (for unrelated purposes) and I see some mutex-related
failures, of the type
conn=1031 op=1 SRCH base=cn=Monitor scope=2 deref=0 filter=(objectClass=*)
h...@openldap.org writes:
Silence stupid MUTEX_FIRSTCREATE warnings
And here I was hoping these warnings would prompt someone to pick up
ITS#5421/librewrite co vs. logging ldap-int.h (-devel nov 2010)...
--
Hallvard
a...@openldap.org writes:
rwm.c 1.138 - 1.139
make sure rwm_response returns SLAP_CB_CONTINUE (ITS#6792, as indicated by
Hallvard)
Why the new 'default: rwm_matched( op, rs );'?
So you can rewrite matchedDN in responses to Abandon and Unbind? :-)
--
Hallvard
Hallvard B Furuseth writes:
Wishes:
...and ITS#6758, finally marked Test after much self-inflicted confusion
--
Hallvard
h...@openldap.org writes:
Note perlModuleConfig, break in compatibility with older versions
Why? This sounds like it will break existing back-perl installations
slightly, but maybe not so thoroughly that the admin realizes why
his back-perl now misbehaves.
If we are going to redesign the
Howard Chu writes:
Since 2.4 slapd dies on unknown config directives, they won't get very far
before it becomes obvious what needs to be fixed.
Ah, OK. Sounds worthy of an ITS though.
And it makes the rest of my last message a different issue:
If we are going to redesign the interface, it
h...@openldap.org writes:
Modified Files:
detach.c 1.25 - 1.26
Log Message:
ITS#6848 Add -w option to wait for DB startup before parent exits
If someone using lutil_detach() for something else than slapd, this will
break their application. I suggest renaming the function and making
I'd like a simple way to manipulate an off-line database while slapd
is running, e.g. to slapadd it from scratch and activate it when done.
Here is one suggestion:
Make olcHidden a dynamic attribute computed from an attribute
olcLabel=some text + a startup option -L label to activate,
Howard Chu writes:
Hallvard B Furuseth wrote:
I'd like a simple way to manipulate an off-line database while slapd
is running, e.g. to slapadd it from scratch and activate it when done.
Here is one suggestion:
Make olcHidden a dynamic attribute computed from an attribute
olcLabel=some text
Howard Chu writes:
Actually I don't know who setup the repo on github.com. Anyway, things have
progressed. Read-only repos are now available on git.openldap.org. You can
also browse them at http://www.openldap.org/devel/gitweb.cgi .
Beware that these repositories are preliminary and may well
k...@openldap.org writes:
Removed Files:
crupdate 1.12 - NONE
Remove from CVS (now in openldap-etc.git)
No big deal, but I think such changes belong in Git only.
Might as well leave the frozen CVS repo in a working state, e.g. if we
find we need to use it for one more release or want to
I've thrown together a quick style sheet to view the XML file with
issues, if anyone cares. It works, but can definitely be improved:-)
--
Hallvard
/*
Quick stylesheet to display issues.xml downloaded from the klocwork
issues list. It lacks klocwork's ability to jump around in the
code
Should .gitattributes and .gitignore be included in releases?
If not, .gitattributes needs the lines:
.gitignore export-ignore
.gitattributes export-ignore
--
Hallvard
ldap_unbind() co fail without doing anything if a critical client
control is set with ldap_set_option() or passed to ldap_unbind_ext_s().
This seems wrong, since ldap_unbind() has always been documented as the
way to both close the connection and free the LDAP structure.
Yet if some code does
We can drop the new CRC code in back-ldif in favor of the stronger MD5
from liblutil. They have the same speed on my host: CRC is simpler,
but memory-bound. CRC guarantees to catch certain transmission errors
like a few wrong bits, but this comes at the expense of its quality as
a general hash
Howard Chu writes:
I didn't really spend a lot of time comparing the two functions'
speed. But even with the memory access bottleneck, I would guess that
on a loaded system with many threads running, the algorithm with fewer
instructions is the better choice. Have you measured the throughput
Howard Chu writes:
I had considered MD5 before (especially since we already had code for
it) but it was slower, and we're not looking for cryptographic
assurances or hash distribution anyway.
Yes, I was thinking mostly of killing unnecessary code and exposed
features. After a brief test, I
Eek, too fast cutpaste...
I'd expect MD5 to be more costly on
an older or cheaper machine where the which hasn't outpaced memory speed
where the *CPU* hasn't
as much as modern workhorses.
--
Hallvard
I think we should not have symlinks in Git. I does strange things with
them. In particular on a system without symlinks, but also in my
checkout now:
$ git checkout mdb
$ cd servers/slapd/back-mdb/
$ ls -l mdb.c libmdb/mdb.c
ls: cannot access libmdb/mdb.c: No such file or directory
lrwxrwxrwx 1
openldap-commit2de...@openldap.org writes:
commit b68fa5ecd73037ebd436a2663003f544d482f71e
Author: Howard Chu h...@openldap.org
Date: Tue Nov 1 13:17:06 2011 -0700
ITS#6981 don't flush entries until after cleanup callbacks
This sounds like it breaks REP_ENTRY_MUSTRELEASE's original
Xin LI writes:
http://people.freebsd.org/~delphij/misc/openldap.diff.gz
Please read http://www.openldap.org/devel/contributing.html
(...)
I've changed the file to include the copyright notice as well as the
rights statement putting the modification into public domain as
comments to the
Howard Chu writes:
All of these have been addressed, except stdint.h vs inttypes.h.
Since it builds fine for me as-is on Solaris, I haven't changed
that. I guess that's still open to discussion if anyone else has info
on which is more commonly provided.
Might as well switch to inttypes and
Quick answer: Don't know. Longer:
It'd be nice to do if that would avoid most nameclashes, but as Michael
says, letterdb will clash. E.g. I thought of sdb (single-level store)
or odb (Openldap's DB). But they clash with OpenOffice databases which
is perhaps worse than with Microsoft stuff.
I wrote:
- Some sort of 'devel' branch, branched off 'maint' and current
'master', merging 'maint' after releases.
Like to today's 'master' but without unfinished features other than
code behind #ifdef LDAP_DEVEL. That way it can be merged into
maint
now and then (like before a
On Fri, 10 Feb 2012 05:18:58 -0800, Kurt Zeilenga k...@openldap.org
wrote:
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:
Oh well, sorry about the abandonware stuff. Getting back to the
more prosaic subject,
First, whether to use a back-port or a forward-port model has nothing
to do
On Fri, 09 Mar 2012 15:01:44 -0800, Quanah Gibson-Mount wrote:
Looking at open ITSes, I would note the following are probably
worthwhile to fix for 2.4.31:
6825, 6942, 7042, 7088, 7100, 7102, 7109, 7149, 7168, 7197, 7202
I know Hallvard is also looking at 6883.
No. I noted some portability
On Fri, 16 Mar 2012 12:40:31 +0100, Michael Ströder wrote:
We saw this assertion in a production server during processing a
modify of an
entry. My co-worker said he could reproduce it. Does it mean the BDB
files
were corrupt?
Maybe, in particular if you upgraded without doing
Michael Ströder wrote:
Upgraded what? slapd? Was there a change in BDB format from 2.4.29 to
2.4.30?
No.
My question was about the state of the assertion and whether the
interpretation (and as a consequence the slapcat/slapadd-operation)
was correct.
Howard says schema change can be one
201 - 299 of 299 matches
Mail list logo
