Re: Config questions for back-ldap, back-meta, and back-asyncmeta

On 06/14/2018 11:58 PM, Howard Chu wrote: > Michael Ströder wrote: >> On 06/14/2018 10:44 PM, Howard Chu wrote: >>> Quanah Gibson-Mount wrote: >>>> idle-timeout -> The man page says takes an integer, but is defined as >>>> a string.  Howeve

Re: Config questions for back-ldap, back-meta, and back-asyncmeta

On 06/14/2018 10:44 PM, Howard Chu wrote: > Quanah Gibson-Mount wrote: >> idle-timeout -> The man page says takes an integer, but is defined as >> a string.  However, I think the man page for this parameter is >> incorrect, and in fact it takes a possible string as defined in the >> back-meta/async

cn=config schema, matching rules and UX with web2ldap

HI! I'd like to highlight a bit why I'm nitpicking on schema definitions for back-config and how careful schema crafting can help to have a better UX with less effort (even though I'm personally using back-config read-only for monitoring). The goals of web2dap are: 1. guide the user to do i

Re: ITS#8286 pending questions

Howard Chu wrote: > Michael Ströder wrote: >> Quanah Gibson-Mount wrote: >>> servers/slapd/bconfig.c --- >>> olcInclude -- case ignore match? >> >> Is already defined with caseExactMatch via "SUP labeledURI". &g

Re: ITS#8286 pending questions

Some more comments on a sub-set of the attributes. Quanah Gibson-Mount wrote: > olcReferral -- case ignore match? It's already declared SUP labeledURI and therefore has caseExactMatch. This makes sense because it could specify an LDAPI URL with case-sensitive socket path name. > olcRootPw -- cas

Re: ITS#8286 pending questions

Quanah Gibson-Mount wrote: > I've done a first pass through the source tree adding missing matching > rules to the olc* attributes to address ITS#8286 > ().  However, > many of the attributes are string types, and can either be case > exact/i

2.4.27? (was: RE24 testing call ..)

Quanah Gibson-Mount wrote: > --On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder > wrote: > >> Howard Chu wrote: >>> We can schedule it for .47, and .47 can be pushed out shortly after .46. >>> We can also include other minor non-core enhancements in.

Re: RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22)

Howard Chu wrote: > We can schedule it for .47, and .47 can be pushed out shortly after .46. > We can also include other minor non-core enhancements in.47 (like > back-sock extensions) as well. Hmm, the back-sock changes are well tested and do not have any incompatible impact. When .47 would be re

Re: RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22)

Quanah Gibson-Mount wrote: > At this point, I believe we're ready to being testing for a 2.4.46 > release. I know 2.4.x should not add new features. But these two ITS patches run well in production, affect only back-sock and would avoid that I have to use backport-patches: (ITS#8714) RFE: Sendou

Re: release 2.4.46?

Ozgur wrote: > I will have some questions. for OpenLDAP next versions; Please do not hijack this mailing list thread, which has a *very* specific subject. So better start a new thread for your topic with a different subject. Thank you. Ciao, Michael. smime.p7s Description: S/MIME Cryptograph

Re: release 2.4.46?

Quanah Gibson-Mount wrote: > --On Monday, January 08, 2018 4:12 PM +0100 Michael Ströder > wrote: >> What are currently the plans for releasing 2.4.46? >> It's hanging in branch RE24 for quite while now. > > When it's ready. I expected this answer. So after al

release 2.4.46?

HI! BTW: Happy New Year. What are currently the plans for releasing 2.4.46? It's hanging in branch RE24 for quite while now. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: ACL checks and slapo-unique

Ondřej Kuzník wrote: > On Wed, Nov 15, 2017 at 05:09:31PM +0100, Michael Ströder wrote: >> HI! >> >> What really strikes users is the lack of feedback in case a unique >> constraint or other constraint fails. >> >> Let's look at error messages of sla

ACL checks and slapo-unique

HI! What really strikes users is the lack of feedback in case a unique constraint or other constraint fails. Let's look at error messages of slapo-unique first. I'm experimenting with a pretty simple patch for returning the effective uniqueness filter in the diagnosticMessage. Example output wit

Re: Persistent sessionlog

Ondřej Kuzník wrote: > On Tue, Oct 24, 2017 at 01:43:21PM +0200, Ondřej Kuzník wrote: >> There are a few tasks that need to be done in order to achieve this: >> [...] >> - update accesslog to log entryUUID for the entry that has just been >> written >> [...] > > Ah, slapo-accesslog already seems

Re: ITS review 9/29/2017

Quanah Gibson-Mount wrote: > --On Friday, October 06, 2017 5:43 PM -0700 Quanah Gibson-Mount > wrote: > >>> This is debatable: >>> >>> 1. OpenLDAP 2.4.x accepts modify operations with LDAP_MOD_INCREMENT >>> >>> 2. OpenLDAP 2.4.x sends modify operations via back-sock to external >>> listeners >>>

Re: ITS review 9/29/2017

Quanah Gibson-Mount wrote: > --- > Purely for RE25: > --- What about ITS#8714? RFE: Sendout EXTENDED operation message in back-sock Could this make it into RE25? Another one which really strikes me: (ITS#7796) LDAP_DEBUG_TRACE for "not indexed" log message

Re: ITS review 9/29/2017

Quanah Gibson-Mount wrote: >>> its8692 - Support LDAP_MOD_INCREMENT with back-sock >>> >> >> Why is this super-trivial patch postponed to RE25? > > It's a new feature. This is debatable: 1. OpenLDAP 2.4.x accepts modify operations with LD

Re: ITS review 9/29/2017

Quanah Gibson-Mount wrote: > --- > Purely for RE25: > --- > > its8692 - Support LDAP_MOD_INCREMENT with back-sock > Why is this super-trivial patch postponed to RE25? Ciao, Michael. smime.p7s Des

LDAP_FEATURE_SUBORDINATE_SCOPE

HI! Does the commit below mean that this feature is not supported at all? IIRC search with subordinate scope even works in 2.4.x. IMHO it would be ok to also announce that feature in rootDSE. BTW: There are many expired I-Ds (e.g. draft-behera-ldap-password-policy) implemented in OpenLDAP serv

Re: ITS review 9/12/2017

Quanah Gibson-Mount wrote: --On Monday, September 18, 2017 10:29 PM +0200 Michael Ströder wrote: ITS#8051: 2fbecdd756a288c787d8326d6630ab8500058e2f 129299a9337287527f2046fe5385cdb2afb35f0b Ah, it seems to be complete. IMO this would also be an interesting candiate for RE24. If you port it

Re: ITS review 9/12/2017

Quanah Gibson-Mount wrote: --On Wednesday, September 13, 2017 9:50 AM +0200 Michael Ströder wrote: There is also a 'sockdnpat' config directive in git-master. But it seems only the config. This would be very helpful for my deployments. I don't know which ITS tho

Re: ITS review 9/12/2017

Quanah Gibson-Mount wrote: --- Suggested for RE25, possibly RE24: [..] its8692 - Support LDAP_MOD_INCREMENT with back-sock Yes, please. It would be also helpful if this could land in RE24: (ITS#8714) RFE: Sendout EX

Re: LMDB encryption support

Howard Chu wrote: > I've recently added support for page-level encryption to LMDB 1.x using > user-supplied > callbacks: Interesting. > Thoughts? Hardcode 1 algorithm, or leave it pluggable? "Cryptographic algorithms age; they become weaker with time." [1] Ciao, Michael. [1] https://tools.iet

slapo-memberOf and replication (was ITS#8613)

Hmm, thinking about this some more... slapo-dynlist(5) says: "dynamically added attributes do not participate in the filter matching phase of the search request handling." This is a big drawback of slapo-dynlist rendering the work-arounds mentioned in ITS#8613 nearly useless. I have to step b

Re: Additional bug in OpenLDAP TLS code

Quanah Gibson-Mount wrote: > Attempting to connect via ldapsearch to ldap://127.0.0.1 and initiate > startTLS will > fail, as the IP gets mapped to "localhost", and then the FQDN check fails. Yes, this is a bug. Especially since the mapping to "localhost" does not have a trustable source for thi

Re: Bug in tlso_session_chkhost?

Howard Chu wrote: > Wrong. The FQDN of the system is the entire point of this discussion. ^^ No! No! No! Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: Bug in tlso_session_chkhost?

Howard Chu wrote: > The point is there is nothing on your machine that says your hostname is > "localhost". > Therefore, since the subjectAltName of DNS:localhost doesn't match any known > name for > your host, the cert is rejected. The machine's hostname is completely irrelevant. The TLS hostn

Re: Bug in tlso_session_chkhost?

Quanah Gibson-Mount wrote: > --On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu wrote: > >> No. One or the other must match, but the CN must be an FQDN. The point of >> alternatives is to support wildcards, aliases, and non-DNS name forms >> (such as IP address). > > RFC reference? RFC 6125

Re: Bug in tlso_session_chkhost?

Howard Chu wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu wrote: >> if I remove the check against the "localhost" name, things succeed as expected. >>> >>> Fwiw, I routinely test with a localhost cert, and this check has never >>> tripped for

Re: serverID 0 and MMR

Quanah Gibson-Mount wrote: > --On Thursday, April 20, 2017 11:34 PM +0200 Michael Ströder > > wrote: > >> qua...@symas.com wrote: >>> It's fine for there to be legacy entryCSNs and a contextCSN for serverID >>> of 0. However, it is not fine

serverID 0 and MMR (was: ITS#8609)

qua...@symas.com wrote: > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. Would it be possible to check serverID during slapd startup with MMR setup and fail to start wit

Re: Storing TLS credentials in the directory

Howard Chu wrote: > It's clear that nobody in the standards organizations considers storing > private keys in > the directory to be a safe thing to do. IMO this is just a matter of password > security > and good ACLs, and the standards should not preclude the option. It is no > worse than > stor

Re: Storing TLS credentials in the directory

Turbo Fredriksson wrote: > On 9 Apr 2017, at 14:40, Michael Ströder wrote: > >> Hmm, every time in a customer encryption/PKI project the customer requested >> that it >> should be secure *and* easy to use. This is kind of a contradiction to begin >> with. >&g

Re: Storing TLS credentials in the directory

Howard Chu wrote: > Turbo Fredriksson wrote: >> Everything I’ve seen about the subject is so darn _complex_! It shouldn’t >> HAVE >> to be. > > Indeed, there's no reason for it. Hmm, every time in a customer encryption/PKI project the customer requested that it should be secure *and* easy to us

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash

Michael Ströder wrote: > Emily Backes wrote: >> It's sounding like the newer and more complicated hashes have a lot of >> configurable >> features that may need site-local tuning. Should these be part of e.g. >> slapd.conf >> config or be settings embedded

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash

Emily Backes wrote: > It's sounding like the newer and more complicated hashes have a lot of > configurable > features that may need site-local tuning. Should these be part of e.g. > slapd.conf > config or be settings embedded in the value format for later clarity, like > > {HASHNAME:attr=val,a

Re: Revisiting the SHA1 default password hash

Michael Ströder wrote: > I was referring to strength of password hashing scheme. And yes, I read your note about bcrypt. But I assumed that something which is already there and tested may be the most successful route for now. Ciao, Michael. smime.p7s Description: S/MIME Cryptograp

Re: Revisiting the SHA1 default password hash

Quanah Gibson-Mount wrote: > --On Friday, February 24, 2017 9:06 PM +0100 Michael Ströder > wrote: > >> Quanah Gibson-Mount wrote: >>> I think it would be wise to update OpenLDAP to a different default for >>> userPassword. >> >> Yes! >> >&

Re: Revisiting the SHA1 default password hash

Quanah Gibson-Mount wrote: > I think it would be wise to update OpenLDAP to a different default for > userPassword. Yes! > We currently have the Contrib SHA2 module, SHA-2 hashes with one round are also way too fast to be a good password hash algorithm. > It may be time to move the SHA2 mod

Re: Patch adding command line TLS support to the ldap utilities

Quanah Gibson-Mount wrote: > Michael Ströder wrote: >> Quanah Gibson-Mount wrote: >>> In working on creating a TLS testsuite for OpenLDAP, a glaring omission >>> in the abilities of the command line tools quickly became apparent. >>> Specifically, the inab

Re: Patch adding command line TLS support to the ldap utilities

Quanah Gibson-Mount wrote: > In working on creating a TLS testsuite for OpenLDAP, a glaring omission in the > abilities of the command line tools quickly became apparent. Specifically, the > inability to set any TLS related options. Just out of curiosity: Wasn't using the env vars not enough in th

Re: back-llog

Howard Chu wrote: > Michael Ströder wrote: >> There could be conflicting timestamps from different MMR replicas. Maybe >> appending the serverID could be a solution? > > Just keep them all in their own separate filesystem directories. Ah, as separate DBs with own suffix unde

Re: back-llog

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> Was just thinking we could do a quite simple backend for use with the >>> accesslog >>> overlay and delta-syncrepl. It would write into flat files and do typical >>> logfile rotati

Re: back-llog

Howard Chu wrote: > Was just thinking we could do a quite simple backend for use with the > accesslog > overlay and delta-syncrepl. It would write into flat files and do typical > logfile rotation on its own. The backing store would have a minimum of two > files > - one for the suffix entry, one

Re: Supported backends/overlays in 2.5

Clément OUDOT wrote: > > > Le 23/02/2016 07:54, Michael Ströder a écrit : >> Quanah Gibson-Mount wrote: >>> back-sock is a better solution. OTOH, We >>> have gotten contributions fixing issues in it as recently as April 2015, so >>> there may be folks

Re: Supported backends/overlays in 2.5

Ryan Tandy wrote: > On Mon, Feb 22, 2016 at 06:33:47PM -0800, Quanah Gibson-Mount wrote: >> I would like to see us retire slapd-bdb and slapd-hdb. > > How much work is it costing to keep them around? > > I agree completely with marking them deprecated and having configure disable > them by defaul

Re: Supported backends/overlays in 2.5

Quanah Gibson-Mount wrote: > back-sock is a better solution. OTOH, We > have gotten contributions fixing issues in it as recently as April 2015, so > there may be folks using it who would like to see it continue. There is back-sock in production (as an overlay) for an OATH-LDAP installation. > I

Re: RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #2 (0.9.18)

Quanah Gibson-Mount wrote: > Changes since testing call #1: > >Fixed slapo-syncprov ctxcsn snapshot on refresh (ITS#8281, ITS#8365) git revision 03b6c1ef63578008a2f5ce11e421c6eef955d2b2 seems to work with normal "make test" on openSUSE Tumbleweed x86_64 with gcc 5.2.1. FWIW: ./run -b mdb

Re: RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #1 (0.9.18)

Quanah Gibson-Mount wrote: > --On Friday, January 29, 2016 11:58 PM +0100 Michael Ströder > wrote: > >> make test works on openSUSE Tumbleweed x86_64 (gcc version 5.2.1). > > Thanks Michael. I just added another ITS (8226). Can you re-run with the > updated code? :)

Re: RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #1 (0.9.18)

make test works on openSUSE Tumbleweed x86_64 (gcc version 5.2.1). Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 testing call #4 (2.4.43) LMDB RE0.9 testing call #4 (0.9.17)

Seems ok on openSUSE Tumbleweed x86_64. What is missing for final release? Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: openldap.git branch master updated. 2d5996ac603391ddbd618425f88eb13e5e0e2cc0

Howard Chu wrote: > A note about this revised patch - accesslog uses op->o_time/op->o_tincr to > generate its RDNs. We actually have a problem here in that microsecond > resolution may no longer be adequate. Back in January I was on site with a > customer whose 64-core server was hitting ~1 million

Re: RE24 testing call #2 (2.4.43) LMDB RE0.9 testing call #2 (0.9.17)

Seems to work for me (openSUSE Tumbleweed x86_64). Looking forward to this release. I need the fix for ITS#8289... Ciao, Michael. Quanah Gibson-Mount wrote: > OpenLDAP 2.4.43 Engineering >Fixed liblber remove obsolete assert (ITS#8240) >Fixed libldap file URLs on windows (ITS#827

Re: RE24 testing call #1 (2.4.43) LMDB RE0.9 testing call #1 (0.9.16)

Michael Ströder wrote: > I will investigate a seg fault with MOD_INCREMENT on a Integer attribute I've > experienced today. Hmmpf! SUP does not work with MOD_INCREMENT: https://www.openldap.org/its/index.cgi?findid=8289 Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 testing call #1 (2.4.43) LMDB RE0.9 testing call #1 (0.9.16)

(ITS#8069) > > > Thanks! > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > > Zimbra :: the leader in open source messaging and collaboration > > -- Michael Ströder K

Re: str2result() and slapd-sock

Michael Ströder wrote: > Michael Ströder wrote: >> I'm trying to find out why slapd-socks always outputs all lines returned by >> the external sock listeners with comment "unknown" although everything seems >> to work correctly. >

Re: str2result() and slapd-sock

Michael Ströder wrote: > I'm trying to find out why slapd-socks always outputs all lines returned by > the external sock listeners with comment "unknown" although everything seems > to work correctly. > > - snip -

str2result() and slapd-sock

HI! I'm trying to find out why slapd-socks always outputs all lines returned by the external sock listeners with comment "unknown" although everything seems to work correctly. - snip - 5603fc08 conn=1000 op=1 BIND dn="uid=äöüÄÖÜß,ou=realdb,d

asserts and manadatory build instructions (was ITS#8240)

h...@symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to > resolve. > Closing this ITS, not an

warnings with gcc 5.1.1

HI! When building OpenLDAP's contrib overlays gcc outputs lots of warnings. Are you interested in getting an ITS for that or not? Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 testing call #1 (2.4.42) LMDB RE0.9 testing call #1 (0.9.16)

Quanah Gibson-Mount wrote: > OpenLDAP 2.4.42 Engineering > [..] > This release is primarly addressing crash related problems and to fix the > configure script for gcc 5.x. Build and "make test" worked on openSUSE Tumbleweed x86_64 with gcc 5.1.1. Ciao, Michael. smime.p7s Description: S/MIME C

Re: libdb detection with gcc 5.1.1

Quanah Gibson-Mount wrote: > --On Saturday, July 04, 2015 6:27 PM +0200 Michael Ströder > >> Wouldn't this justify to re-roll a OpenLDAP release? > > First step would be to file an ITS. Please do so. :) http://www.openldap.org/its/index.cgi?findid=8189 Ciao, Michael.

Re: libdb detection with gcc 5.1.1

Aaron Richton wrote: > On Sat, 4 Jul 2015, Michael Ströder wrote: > >> HI! >> >> This seems to be already fixed: >> >> ITS#8056: libdb detection with gcc 5 >> >> But gcc-5.1.1 arrived on openSUSE Tumbleweed and now libdb detection fails: > >

libdb detection with gcc 5.1.1

HI! This seems to be already fixed: ITS#8056: libdb detection with gcc 5 But gcc-5.1.1 arrived on openSUSE Tumbleweed and now libdb detection fails: checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... none confi

Re: Use of gethostbyaddr_r on openSUSE

Aaron Richton wrote: > On Thu, 2 Jul 2015, Michael Ströder wrote: > [...] >> https://build.opensuse.org/package/view_file/home:stroeder:branches:network:ldap/openldap2/0004-libldap-use-gethostbyname_r.dif?expand=1 >> >> This patch seems to fail now (see below). I'

Use of gethostbyaddr_r on openSUSE

HI! I'm still fighting with building newer OpenLDAP RPMs for openSUSE. Originally Ralf Haferkamp generated the .spec files several years ago but is not involved anymore. He added this patch: https://build.opensuse.org/package/view_file/home:stroeder:branches:network:ldap/openldap2/0004-libldap-

unbind requests to all backends?

HI! Are unbind requests always propagated to all backends? Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

back-sock: Format of RESULT

HI! I'm really confused by this part of slapd-sock(5): - snip - If the overlay is configured to send response messages to the external program, they will appear as an extended RESULT message or as an ENTRY messag

enhancements for back-sock, especially MONITOR

HI! I'm currently working on implementing a generic back-sock listener in Python and two special instances of it. Mainly the current use-case is overlay usage intercepting bind requests. Of course I'd like to monitor the back-sock listeners (internal state like counters etc.), probably via LDAP i

slapd-sock: extensions always UTF-8

HI! Are these extensions guaranteed to be always sent by back-sock as raw UTF-8 in one line? Or does the listener also has to handle base64 encoding and line-folding like in LDIF for these extension lines? binddn: peername: IP=: ssf: connid: Ciao, Michael.

Re: RE24 testing call #4 (2.4.41), LMDB RE0.9 testing call #4 (0.9.15)

Thanks to all for working on it. make test seems to work on openSUSE Tumbleweed x86_64 on ext4 FS. Any tests you want to run many times? Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: ppolicy: pardon password history

Andrew Findlay wrote: On Mon, Apr 20, 2015 at 07:28:31PM +0200, Michael Ströder wrote: herch...@hrz.uni-marburg.de wrote: Whenever a login fails due to a invalid password, the ppolicy-module will count this as a failure. After a configurable number of password failures in a given time

Re: ppolicy: pardon password history

herch...@hrz.uni-marburg.de wrote: I have made a tiny modification to the ppolicy-module. The aim is to go easy on people who forgot their password, or forgot to deploy their recently changed password to all devices (think of laptops, smartphones, etc.). Whenever a login fails due to a invalid pa

Re: www.openldap.org not mobile-friendly

Clément OUDOT wrote: 2015-04-14 10:18 GMT+02:00 Hallvard Breien Furuseth : It will drop in Google's ratings next week because it fails the tests. Maybe someone can fix the web pages up a bit? I'm too busy now. Already fixed in the mea

Re: version numbers for release candidates

Howard Chu wrote: > Michael Ströder wrote: >> HI! >> >> Sometimes many interesting changes are solely in RE24 and releasing the next >> true release takes some time. During this period I'd love to see pre-release >> version numbers assigned to RE24. >&g

version numbers for release candidates

HI! Sometimes many interesting changes are solely in RE24 and releasing the next true release takes some time. During this period I'd love to see pre-release version numbers assigned to RE24. Especially in case Quanah sends out an inquiry for another RE24 test round something like currently 2.4.4

Re: Enhancing back-sock to use JSON

Dagobert Michelsen wrote: > Hi Michael, > >> Am 08.03.2015 um 10:18 schrieb Michael Ströder : >> >> Dagobert Michelsen wrote: >>>> Am 19.02.2015 um 18:05 schrieb Howard Chu : >>>>> Dagobert Michelsen wrote: >>>>> >>&

Re: Enhancing back-sock to use JSON

Dagobert Michelsen wrote: >> Am 19.02.2015 um 18:05 schrieb Howard Chu : >>> Dagobert Michelsen wrote: >>> >>> I have made some enhancements to back-sock to use JSON for the passed data >>> and JSON-RPC >>> to map LDAP calls to method invocations. >> >> my initial reaction: the current format is j

Re: Security alerts on OpenLDAP (CVE-2015-1545 / CVE-2015-1546)

Howard Chu wrote: > Given that the deref overlay isn't even documented and is probably used by > only a handful of OpenLDAP developers I don't believe it even merited a CVE > record. Hmm, not sure. Arthur de Jong implemented support for this control in nss-pam-ldapd a year ago [1] and IIRC also di

git.openldap.org (port 9418) (Name or service not known)

HI! What's wrong with the git server's DNS RR? $ git pull fatal: Unable to look up git.openldap.org (port 9418) (Name or service not known) Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 testing call #3 (2.4.41), LMDB RE0.9 testing call #3 (0.9.15)

Seems to be ok on openSUSE 13.2 x86_64 Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: syncrepl consumer is slow

Hallvard Breien Furuseth wrote: > On 29. jan. 2015 04:12, Howard Chu wrote: >> I'm considering adding an option to the consumer to write its entries with >> dbnosync during the refresh phase. The rationale being, there's nothing to >> lose anyway if the refresh is interrupted. I.e., the consumer ca

Re: RE24 testing call #2 (2.4.41), LMDB RE0.9 testing call #2 (0.9.15)

Quanah Gibson-Mount wrote: > OpenLDAP 2.4.41 Engineering make test seems fine on openSUSE 13.2 x86_64. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 testing call #1 (2.4.41), LMDB RE0.9 testing call #1 (0.9.15)

Quanah Gibson-Mount wrote: > The following changes have been made to OpenLDAP directly for 2.4.41: make test and my local deployment works on openSUSE 13.2 x86_64 Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: Don't Use Copy Control (1.3.6.1.4.1.4203.666.5.15 vs. 1.3.6.1.1.22)

Quanah Gibson-Mount wrote: > 2.4 is done. Howard already stated that. AFAICS 2.4.40 is not released yet. And IIRC there were commits to RE24 after tagging 2.4.40. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: Don't Use Copy Control (1.3.6.1.4.1.4203.666.5.15 vs. 1.3.6.1.1.22)

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> Michael Ströder wrote: >>>>> Is there any issue with using OID 1.3.6.1.1.22 as controlType for Don't >>>>> Use >>>>> Cop

Re: Don't Use Copy Control (1.3.6.1.4.1.4203.666.5.15 vs. 1.3.6.1.1.22)

Howard Chu wrote: > Michael Ströder wrote: >> Michael Ströder wrote: >>> Is there any issue with using OID 1.3.6.1.1.22 as controlType for Don't Use >>> Copy Control as defined in RFC 6171? Currently an experimental OpenLDAP .666 >>> OID s used which m

Re: Don't Use Copy Control (1.3.6.1.4.1.4203.666.5.15 vs. 1.3.6.1.1.22)

Michael Ströder wrote: > Is there any issue with using OID 1.3.6.1.1.22 as controlType for Don't Use > Copy Control as defined in RFC 6171? Currently an experimental OpenLDAP .666 > OID s used which makes this control rather unusable outside OpenLDAP > implementation. Filed

Re: TXN in master

Howard Chu wrote: > Michael Ströder wrote: >> It seems TXN support has landed in git master. >> Is it ready for interop testing? > > Yes, go for it. More questions: In case of using Assertion Control: At which state is the assertion tested? During TXN settlement? If an u

Don't Use Copy Control (1.3.6.1.4.1.4203.666.5.15 vs. 1.3.6.1.1.22)

HI! Is there any issue with using OID 1.3.6.1.1.22 as controlType for Don't Use Copy Control as defined in RFC 6171? Currently an experimental OpenLDAP .666 OID s used which makes this control rather unusable outside OpenLDAP implementation. Ciao, Michael. smime.p7s Description: S/MIME Cryptog

TXN in master

HI! It seems TXN support has landed in git master. Is it ready for interop testing? Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature

Re: RE24 Testing Call #4

Two typos in CHANGES: diff --git a/CHANGES b/CHANGES index 8bbc521..3827404 100644 --- a/CHANGES +++ b/CHANGES @@ -26,7 +26,7 @@ OpenLDAP 2.4.40 Engineering Fixed slapo-memberof frontendDB handling (ITS#7249) Fixed slapo-pcache config processing (ITS#7919) Added slapo-ppoli

Re: RE24 Testing Call #4

On Fri, 15 Aug 2014 13:42:48 +0200 "Michael Ströder" wrote > With git RE24 9321ecc040deb025675888559cc43052ee563c6a (with updates for mdb) > > Checking contextCSN after site2 servers repopulated... > Found 1 errors > >>>>> test058-syncrepl-asymmetric fa

Re: RE24 Testing Call #4

With git RE24 9321ecc040deb025675888559cc43052ee563c6a (with updates for mdb) Checking contextCSN after site2 servers repopulated... Found 1 errors > test058-syncrepl-asymmetric failed for mdb (exit 1) I will file an ITS with copy of testrun/ if needed. Ciao, Michael.

Re: RE24

Howard Chu wrote: > Michael Ströder wrote: >> With recent RE24 10cee57e5ecd1709eabe200714b8995f738ddf48 some operational >> attributes are doubled like in this example: > > Not happening here. Hmmpf. I've loaded a LDIF with slapadd which was generated by ldapsear

[no subject]

HI! With recent RE24 10cee57e5ecd1709eabe200714b8995f738ddf48 some operational attributes are doubled like in this example: dn: ou=example auditContext: cn=accesslog auditContext: cn=accesslog objectClass: organizationalUnit ou: example structuralObjectClass: organizationalUnit subschemaSubentry:

Re: ppolicy draft again

Howard Chu wrote: > xml2rfc controls white space, for the most part. Definitely not something to > focus attention on first. Uummh... It seems to me that different versions of xml2rfc produce pretty different boilerplate text, formatting etc. The diff of the compiled .txt looks much different to

Re: ppolicy draft again

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> Quanah Gibson-Mount wrote: >>>>> 7838 - Add ORDERING matching rule to ppolicy (RFC issue?) >>>> >>>> re: 7838 - the draft need

Re: ppolicy draft again

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> Quanah Gibson-Mount wrote: >>>> 7838 - Add ORDERING matching rule to ppolicy (RFC issue?) >>> >>> re: 7838 - the draft needs a number of edits. I'm willing to commit this if

<    1   2   3   4   5   6   >