OpenLDAP git repo?
by Volker Lendecke
Hi!
Out of several rumors I've heard that OpenLDAP converted it
source repo to git. Is that true? www.openldap.org still
speaks about cvs. If you changed to git, is the repo
publically available?
Thanks,
Volker
12 years, 5 months
librewrite & co vs. logging & ldap-int.h
by Hallvard B Furuseth
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
need of which I've just removed in HEAD, and set up libldap logging.
I expect the slapd components just as well can drop the #include and
use slapd logging? back-*/search.c then need lber-int.h instead.
librewrite still needs the #define ldap_debug in ldap-int.h.
Instead we could either:
(1) use liblber logging in librewrite,
(2) or throw the code LDAP_INT_IN_KERNEL .. #endif /* LDAP_DEBUG */
out of ldap-int.h to a separate file, either include/ldap_log.h or
something like libldap/ldap-int-log.h. This file would not expose
structs with different definitions depending on LDAP_R_COMPILE & co.
Since the file when not LDAP_INT_IN_KERNEL does need to refer
ldap_debug to ldap_int_global_options.ldo_debug, that can be done with:
/* This struct starts with the same members as ldapoptions */
struct ldapoptions_prefix {
short ldo_valid;
int ldo_debug;
};
#define ldap_debug \
(*(int *) ((char *) &ldap_int_global_options \
+ offsetof(struct ldapoptions_prefix, ldo_debug)))
struct ldapoptions;
LDAP_V ( struct ldapoptions ) ldap_int_global_options;
Opinions? Put it in ldap-int.h, or ldap_log.h? Maybe the latter
only if #defined LDAP_LIBRARY_LOGGING (defined by the user)?
--
Hallvard
12 years, 8 months
LDIF wrapping (Was: ITS#6645)
by masarati＠aero.polimi.it
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?
p.
12 years, 8 months
CSN of delete operations
by Rein Tollevik
The bdb/hdb and ldif backends assigns CSNs to delete operations that
lacks it, which causes problems in forwarding replication
configurations. During the refresh phase there may be legitimate delete
operations that should not have any CSN. When the forwarder adds its
CSN it might leave the forwarded and its consumers with a CSN set that
includes a SID not present on the provider, and they will never be able
to resync.
syncrepl_del_nonpresent() queues the minimum CSN received from the
provider, which partly obscures this problem but in return introduce
other :-( The CSN set received may include updates to more than one
CSN, and only one if these can be added on the queue. Much worse, the
first delete will commit the queued CSN. If there are more than one
entry that should be deleted this leaves an open window where the
forwarder (and its consumers) have an apparently up-to-date CSN set
without actually being in sync with the provider. Running the new
test061 with sync debugging shows traces of these problem in the logs.
In back-bdb/delete.c, the CSN of the delete operation appear to be added
as a value in the entryCSN index, which really puzzles me. If that
index is to be modified I would expect that it should delete the
entryCSN value of the entry being deleted, not to add anything. Why
this is only done in non-shadowed databases I cannot tell either.
I would fix these problems by assigning the CSN of delete operations in
the frontend, i.e on the server where ordinary delete operations where
done. syncrepl_del_nonpresent() should not queue the CSN, updating it
should be left to the syncrepl_updateCookie() call which takes place
when the refresh phase completes. But what to do about the index
manipulation I cannot tell. Anyone?
Rein
12 years, 8 months
LDAP Verify Credentials operation
by Kurt Zeilenga
I'm going to add a LDAP 'Verify Credentials' operation to the client side in OpenLDAP (as that's I'll I need). The operation behaves like LDAP Bind excepting it has no impact upon the underlying LDAP session (no change to the authorization associations, no change of layers, etc.). No spec yet, want to have a working implementation first.
The operation is intended to be used by LDAP clients which are application protocol servers to authenticate application protocol users. For instance, a web server could authenticate it's users via this operation. Multiple operations can be executed in parallel on a session. SASL can be used. Could also be used by a DSA to authenticate users whose entries (or complete entries) are not held by the DSA.
Wondering if there are any volunteers to implement the server side? Should be relatively straight forward.
-- Kurt
12 years, 8 months
vc function names (was: commit: ldap/include ldap.h)
by Hallvard B Furuseth
ldap.h declares ldap_parse_verify_credentials_result(), but the .c files
define and use ldap_parse_verify_credentials().
I guess the first name is most formally correct, but rather long.
I suppose you could s/credentials/creds/ in the operation name.
--
Hallvard
12 years, 8 months
Re: commit: ldap/tests/scripts test054-syncreplication-parallel-load
by Quanah Gibson-Mount
--On Sunday, August 29, 2010 4:11 AM +0000 ando(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/tests/scripts
>
> Modified Files:
> test054-syncreplication-parallel-load 1.6 -> 1.7
>
> Log Message:
> s/provider/producer/
I think this should be reverted. The master server(s) are providers. The
replicas are consumers. The master(s) provide the data. The replicas
consume them. End admins/users produce the data by modifying the
master(s), not the master(s) themselves.
--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
12 years, 9 months
back-ldif robustness hack (was: Filesystem & backend options for embedded openldap)
by Hallvard B Furuseth
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 in its directory.
Could fix this as follows. I guess it's worth the price of slowing down
LDAP Delete:
If a Delete operation would fail with notAllowedOnNonLeaf (rmdir gave
ENOTEMPTY), read the first directory entries. If we find an .ldif or
a directory, return notAllowedOnNonLeaf. Remove any temporary files
encountered until then, and try again if we removed them all.
back-ldif serializes write operations, so there won't be a conflict
unless the admin runs slapadd and slapd at the same time.
There could be files someone else has stored there which should not be
deleted, e.g. a README, so tempfiles should have recognizable names like
"<rdn>.tmp<6 random chars>" instead of just "<rdn>.<6 random chars>".
--
Hallvard
12 years, 9 months
Re: commit: ldap/ CHANGES
by Hallvard B Furuseth
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)
@@ -17 +17 @@
- Fixed slapd-ldap uninitialized tv_usec (ITS#6721)
+ Fixed slapd-ldap debug output of timeout (ITS#6721)
@@ -21 +21 @@
- Fixed slapd-null back-config support (ITS#6624)
+ Added slapd-null cn=config support (ITS#6624)
@@ -27 +27 @@
- Fixed slapo-syncprov properly mutex filter (ITS#6708)
+ Fixed slapo-syncprov filter race condition (ITS#6708)
--
Hallvard
12 years, 9 months
autoconf version update?
by Quanah Gibson-Mount
We are currently generating configure with autoconf 2.61. Is there any
objection to updating to autoconf 2.65?
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
12 years, 9 months
