openldap-devel

openldap-devel@openldap.org

2 participants
1419 discussions

RE24 testing call #2 (OL2.4.24)
by Quanah Gibson-Mount 09 Jan '11

09 Jan '11

There have been substantial updates to RE24. Please test! Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

6 11

multiple listener threads (was: commit: ldap/servers/slapd bconfig.c daemon.c proto-slap.h)
by Hallvard B Furuseth 07 Jan '11

07 Jan '11

quanah(a)OpenLDAP.org writes: > Tag: OPENLDAP_REL_ENG_2_4 > bconfig.c 1.202.2.88 -> 1.202.2.89 > daemon.c 1.380.2.37 -> 1.380.2.38 > proto-slap.h 1.670.2.63 -> 1.670.2.64 > > Add support for multiple listener threads. Needs fixing, see: ITS#6745 HEAD emfile race condition -> slapd stopping listening? -- Hallvard

1 0

Re: LDAP Verify Credentials operation
by Kurt Zeilenga 05 Jan '11

05 Jan '11

Ando and I have been discussing off-list the need for this op's request and response to carry additional fields. The discussion started with a separate error code to distinguish errors which might be communicated back to authenticating entity (as opposed to the LDAP client submitting the VC request). My current proposal is: /* * LDAP Verify Credentials operation * * The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5 with value of * the BER encoding of: * * VCRequest ::= SEQUENCE { * cookie [0] OCTET STRING OPTIONAL, * name LDAPDN, * authentication AuthenticationChoice * controls [3] Controls OPTIONAL * } * * where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC 4511. * * The response is an extended response with no OID and a value of the BER encoding of * * VCResponse ::= SEQUENCE { * resultCode ResultCode, * diagnosticMessage LDAPString, * cookie [0] OCTET STRING OPTIONAL, * serverSaslCreds [1] OCTET STRING OPTIONAL * authzid [2] OCTET STRING OPTIONAL * controls [3] Controls OPTIONAL * } * * where ResultCode is the result code enumeration from RFC 4511, and LDAPString and Controls are as * defined in RFC 4511. */ The use of controls here is to allow both the request/return of password policy information to the authenticating entity (as opposed those used on the extended operation itself to request/return password policy information about the LDAP client submitting the VC request). Comments? -- Kurt

3 5

Re: commit: ldap/contrib/slapd-modules/cloak cloak.c
by Hallvard B Furuseth 04 Jan '11

04 Jan '11

ando(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

2 1

LDIF wrapping (Was: ITS#6645)
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

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.

3 5

CSN of delete operations
by Rein Tollevik 30 Dec '10

30 Dec '10

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

2 1

LDAP Verify Credentials operation
by Kurt Zeilenga 30 Dec '10

30 Dec '10

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

2 1

vc function names (was: commit: ldap/include ldap.h)
by Hallvard B Furuseth 28 Dec '10

28 Dec '10

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

2 1

Re: commit: ldap/tests/scripts test054-syncreplication-parallel-load
by Quanah Gibson-Mount 22 Dec '10

22 Dec '10

--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

1 0

back-ldif robustness hack (was: Filesystem & backend options for embedded openldap)
by Hallvard B Furuseth 20 Dec '10

20 Dec '10

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel