Re: misconfigured read-only replica causes master slapd to crash

at will, and would be happy to provide whatever additional data or assistance is required to diagnose and resolve the underlying issue. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University

RE: auditing failed login attempts

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] slapo-auditlog? From the documentation, it looks like that only logs changes, not accesses/binds? slapo-accesslog? That is one of the options I mentioned in my initial inquiry, it's just going to induce a bit more overhead than I would

RE: auditing failed login attempts

From: Michael Ströder [mailto:mich...@stroeder.com] Paul B. Henson wrote: our security group is pushing us to enable failed login lockout ..which will stupidly open a DoS attack vector... Preaching to the choir on that one, my friend. I already promised our ISO that the day we turn

memberof overlay results in unexpected slapd death?

Our LDAP infrastructure is currently running 2.4.35, and consists of two read/write masters configured in mirror mode behind the load balancer, with three additional read-only slaves using syncrepl. We recently decided to add the memberof overlay to our configuration, due to an application that

memberof overlay replicating memberOf attribute?

Based on the documentation, my understanding was that the memberof overlay maintained the memberOf attribute locally, and this attribute was not replicated? While I was recently working on implementing the memberof overlay, I noticed that after I had enabled it on one server, before enabling it on

mysterious glue record with empty dn

While I was trying to recover my directory from an aborted attempt to implement the memberof overlay, I ended up dumping the database with slapcat and then reloading it with slapadd after removing the now invalid MEMBEROF attributes that lingered after the overlay was disabled. Strangely, on some

RE: memberof overlay results in unexpected slapd death?

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Friday, October 11, 2013 1:25 PM Enable core files: http://wiki.zimbra.com/wiki/Enabling_Core_Files Thanks for the link, I will do so when I get the test environment up. I'd also note

RE: memberof overlay results in unexpected slapd death?

From: Michael Ströder [mailto:mich...@stroeder.com] Sent: Friday, October 11, 2013 1:47 PM Could you please try to reproduce this with OpenLDAP from git repo? It contains a fix for ITS#7710: http://www.openldap.org/its/index.cgi?findid=7710 Once I make sure I can reliably reproduce it

RE: memberof overlay replicating memberOf attribute?

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Friday, October 11, 2013 1:49 PM This seems contrary to the documentation and I found it confusing. Am I missing something? The memberof overlay should be loaded on all servers. Also see the ITS I just referenced to you... In

RE: mysterious glue record with empty dn

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Friday, October 11, 2013 2:22 PM Did you correctly load the memberof overlay onto all servers? Evidently not. While the overlay was eventually configured on all of the servers, in order to avoid a service outage it was not done at

Re: memberof overlay results in unexpected slapd death?

On Sat, Oct 12, 2013 at 10:45:30AM +0200, Michael Ströder wrote: If you enable slapo-memberof on all your replicas you will see it. I did have it enabled on everything for about a day and a half without noticing it. But it looks like the fix for that inconsistency will hopefully come along with

mdb_stat

Where does one typically acquire the mdb_stat binary for use with openldap? It appears to be part of liblmdb. openldap includes a bundled copy of liblmdb, but does not actually build mdb_stat. Is the intention for distributions to have a separate package for liblmdb, which would include mdb_stat,

configuring mdb maxsize

I'd like to clarify the requirements for the mdb maxsize parameter. According to the current admin guide: This should be the largest that the database is ever anticipated to grow Which would seem to imply it cannot later be changed without completely rebuilding the database. According to the

optimal mdb flags

So if it's not obvious, we're working on migrating our openldap deployment to mdb from hdb :), I apologize for the flurry of questions, this will be the last, at least for today ;). I'm trying to evaluate the optimal configuration for mdb; it seems like for the most part you can just set maxsize

RE: mdb_stat

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Wednesday, January 08, 2014 8:21 AM I build out the mdb_* utilities when I build OpenLDAP. Yeah, that probably seems best, to make sure it is the same version as the library openldap is using. Hopefully I can get a Gentoo dev to agree

RE: optimal mdb flags

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Wednesday, January 08, 2014 8:22 AM I use writemap and nometasync. I've never encountered corruption because of using writemap. Excellent. Do you use nometasync because otherwise the performance isn't good enough for your use case?

RE: mdb searchstack parameter

From: Howard Chu [mailto:h...@symas.com] Sent: Wednesday, January 08, 2014 9:21 AM Since you mention that you're migrating from hdb, you can most likely ignore this parameter. It has the identical meaning in hdb after all, and if you never had to change it under hdb there's no reason to

RE: optimal mdb flags

From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Wednesday, January 08, 2014 4:48 PM I don't set any checkpoint directive with back-mdb. I have debated off and on whether or not to keep nometasync, but haven't done in-depth testing at this time as to its pros and cons. I settled

RE: configuring mdb maxsize

From: Howard Chu [mailto:h...@symas.com] Sent: Wednesday, January 08, 2014 8:19 PM I rather thought the manpage was self-explanatory. The man page is reasonably clear, but it does not jibe with the documentation in the admin guide, which adds a degree of confusion, resulting in my inquiry.

mdb expected growth

So after updating our dev ldap environment to use mdb, and slapadd'ing a fresh copy from our production environment into it, the database was using 828M: Environment Info Map address: (nil) Map size: 2147483648 Page size: 4096 Max pages: 524288 Number of pages used: 211612 Last

Re: mdb expected growth

On Fri, Jan 10, 2014 at 01:00:32PM -0800, Paul B. Henson wrote: I then proceeded to run a test load on it (basically, I had a script I put together when I added the memberof overlay that ripped through all of our groups, removing and then re-adding all members). After this test run, the use

Re: mdb expected growth

On Sat, Jan 11, 2014 at 12:45:13PM -0800, Quanah Gibson-Mount wrote: Yes, this is generally what I see when re-running massive changes. There is a one time growth jump, and then it stabilizes. Interestingly, the massive growth is only seen on the master (fosse-dev in the list below), the

RE: mdb expected growth

From: Howard Chu [mailto:h...@symas.com] Sent: Sunday, January 12, 2014 1:41 PM From the sound of your quite vague test description, sure. As it states in the LMDB doc, long-lived reader transactions prevent reuse of freed pages. http://symas.com/mdb/doc/ You have a long search operation

migrating from syncrepl to delta syncrepl

When we first deployed openldap a decade or so ago, we implemented regular syncrepl rather than delta syncrepl because at the time the latter did not support mirror mode. As part of a project to implement the password policy overlay, we plan to switch to delta syncrepl to make the replication of

Re: migrating from syncrepl to delta syncrepl

On Thu, Jan 30, 2014 at 10:57:06AM -0800, Quanah Gibson-Mount wrote: Looked fairly sane when I gave it a brief glance over. Cool, thanks much for the feedback.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Quanah Gibson-Mount Sent: Thursday, January 30, 2014 1:09 PM Having used both methods for years, I disagree. It is a learning curve to understand the cn=config backend, but once you do, it is far superior to the old flat file, and to me, much easier to use. My main issue with the

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

Regardless of what you may think about the tone of postings on this list (which is ludicrous to begin with since emails by their nature are horrible at conveying tone or emotion), actual subject matter experts monitor this list and make sure that correct answers get posted and that BS is

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Quanah Gibson-Mount Sent: Friday, January 31, 2014 6:03 PM Our servers do a nightly backup of cn=config via slapcat -n 0, and those are kept for a month. Since this is for clients, there's no revision control involved, but it would be trivial for someone to check in the resulting

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM As Howard confirmed on this mailing list static configuration will still be available in OpenLDAP 2.5.x. Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5.

deploying password policy module

We are planning to deploy the password policy module to satisfy our security groups requirement for account lockouts (a.k.a., intentionally provided DoS attack vectors sigh). I had a couple of questions regarding the deployment I was hoping someone might be kind enough to answer. Does the

Re: deploying password policy module

to retroactively apply a policy that might be added in the future based on historical authentication failures. On Wed, Apr 23, 2014 at 05:23:28PM -0700, Paul B. Henson wrote: We are planning to deploy the password policy module to satisfy our security groups requirement for account lockouts (a.k.a

ppolicy module limited to catching 1 login failure per second?

We're testing the ppolicy module for the purposes of enabling account lockout on our ldap infrastructure. During initial testing, I noticed that it didn't seem to be catching all of the failed logins, and then realized that the pwdFailureTime attribute in which they are stored seems to have a

RE: deploying password policy module

From: Michael Ströder Sent: Sunday, April 27, 2014 11:27 PM Sometimes it's handy to see when people had failed logins even if you don't apply lockout policy. It would be even more handy to be able to roll out password policy support without having to shut down your entire LDAP infrastructure

RE: ppolicy module limited to catching 1 login failure per second?

From: Michael Ströder Sent: Sunday, April 27, 2014 11:22 PM Yes, there's already an ITS present for that: http://www.openldap.org/its/index.cgi?findid=7161 Hmm, I see that was opened over two years ago and as of yet still has no response :(. It would appear the generalized time syntax the

slap_timestamp with microsecond granularity?

Reviewing current time handling code, while lutil_parsetime understands and can parse a generalized time that includes fractions of a second, there doesn't seem to be any code that can generate a generalized time string including fractions of a second, in particular to microsecond resolution (to

RE: Antw: slap_timestamp with microsecond granularity?

From: Ulrich Windl Sent: Monday, April 28, 2014 11:22 PM Here you can see that the C Library has come to ages: stuct tm lacks fractional seconds, nad strftime is based on struct tm. In a similar problem I used a hybrid approach like this: Thanks for the example; I was thinking of

RE: slap_timestamp with microsecond granularity?

From: Michael Ströder Sent: Monday, April 28, 2014 11:47 PM slapo-accesslog records fractions of a second in attributes reqStart and reqEnd which both are declared use Generalized Time syntax. Cool, thanks for the pointer. It looks like that code uses the second of the options I considered,

RE: deploying password policy module

From: Michael Ströder Sent: Monday, April 28, 2014 11:50 PM 1. If HA is important you surely have more than one replica and a decent fail-over mechanism. Absolutely. 2. Loading slapo-ppolicy and the schema file in one restart is trivial. Agreed. Sorry. I don't see the problem. The

RE: deploying password policy module

From: Michael Ströder Sent: Tuesday, April 29, 2014 12:50 PM AFAICS nothing prevents you from loading the schema first on all replicas. And after that load the overlay. The attribute in question is not defined in the external schema, in fact, it is commented out: #5.3.4 pwdFailureTime # #

RE: deploying password policy module

From: Michael Ströder Sent: Friday, May 02, 2014 4:21 AM If just add moduleload ppolicy to your slapd.conf (or similar action for [...] In a second step you have to add overlay ppolicy to the database section Sweet, I never considered loading the module but not using it. Thanks much for the

password policy module memory leaks / excessive replication?

I've been testing the password policy module lately. I updated our development LDAP infrastructure Monday, basically loading and enabling the module, adding a default policy: dn: cn=default,ou=ppolicy,dc=csupomona,dc=edu cn: default objectClass: organizationalRole objectClass: pwdPolicy

development mailing list?

I subscribed to the development mailing list Tuesday, to migrate a thread discussing the password policy implementation that I was told belonged there. However, neither of my two postings to that list seem to have been delivered. I am definitely subscribed, having received a message from the list,

RE: deploying password policy module

From: Michael Ströder Sent: Saturday, May 03, 2014 4:22 AM BTW: AFAIK write operations to 'pwdFailureTime' are normally not replicated. Hmm, in my initial testing, it seemed to be. Account lockout wouldn't be nearly as useful if the failures were not synchronized across all of the servers

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Friday, May 02, 2014 7:22 PM I would suggest (if you haven't) enabling sync replication logging (loglevel sync) in addition to whatever other loglevels you have. I've found it is possible to send MMR into an endless loop in some cases recently. I'm still

Re: password policy module memory leaks / excessive replication?

On Fri, May 02, 2014 at 07:22:10PM -0700, Quanah Gibson-Mount wrote: I would suggest (if you haven't) enabling sync replication logging (loglevel sync) in addition to whatever other loglevels you have. Ok, so I reloaded my dev environment with a fresh snapshot of production data, and started

Re: password policy module memory leaks / excessive replication?

On Wed, May 07, 2014 at 09:42:12AM -0700, Quanah Gibson-Mount wrote: One other thing -- Did any of your servers go into refresh mode prior to this loop starting? Yes, it started logging: May 5 19:00:38 filmore-dev slapd[7665]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Tuesday, May 06, 2014 9:43 PM beginning, and will see if it does it again. When it happens to your client in production, how do you resolve it? You can gdb slapd, and manually fix the serverID in the syncinfo structure, or you can restart all your slapd

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Wednesday, May 07, 2014 5:58 PM I've filed an ITS on the issue and will see if I can replicate it in our lab. This looks exactly like what I am seeing as well. Howard may be able to provide some gdb actions he would like to see as well. Cool, I see it is

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Mike Jackson Sent: Tuesday, May 13, 2014 2:02 AM In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. It enables you to perform critical adjustments to your service without interrupting your service (more or less depending

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Thursday, May 08, 2014 3:43 PM Nope... I think I have moderator privs even, but I don't recall where I have to log into to do it. :/ There's a couple of people I can bug about it though. The list administrative interface is at:

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Monday, May 12, 2014 7:00 PM I haven't had any luck in reproducing it in my lab. I'd be curious to know if you could share your cn=config setup (minus rootdn passwords), and describe how you are triggering the ppolicy updates in the lab. I'll send you my

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Tuesday, May 13, 2014 3:56 PM It was the only sane choice, and as you are not a developer and were not participating in the design discussions back in 2002-2003 you're not in any position to comment or critique on it. And judging from your commentary, you're not

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Tuesday, May 13, 2014 3:59 PM That's not really dynamic configuration. Anything that requires you to physically login to a server to issue a change is not scalable. With cn=config you can delegate configuration privileges across an arbitrarily large network, without

RE: password policy module memory leaks / excessive replication?

From: Quanah Gibson-Mount Sent: Tuesday, May 13, 2014 2:21 PM That's interesting... it was totally idle (doing nothing at all?). Yes, the absolute only activity after slappadd'ing the data and starting the server were the automated accesses to the monitoring backend by a service account.

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Tuesday, May 13, 2014 6:35 PM You're not a developer and clearly unable to write code that behaves as you suggest. [...] Your opinion is worthless noise. [...] Your examples are irrelevant and not applicable. [...] But hey moron, that didn't work with threaded

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Mike Jackson Sent: Tuesday, May 13, 2014 10:59 PM you're simply not important in the grand scheme of things. So before you all go blowing smoke out of your asses, Stroeder, that includes you, too, it might be wise not to underestimate with whom you are speaking. The ego is strong

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

On Wed, May 14, 2014 at 11:57:22PM +0200, Michael Ströder wrote: Well, judging from your postings my impression of your analytical skills are pretty precise. Hey now, you do realize that back in 2002-2003, as a *core architect*, Mike *personally* made the decision regarding which LDAP server

Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

On Thu, May 15, 2014 at 01:28:16AM +0300, Mike Jackson wrote: I was reverse-engineering the management protocols of commercial LDAP servers with ethereal so I could build automated installations and command-line management tools to said management interfaces already 15 years ago. So, when

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Wednesday, May 14, 2014 4:43 PM If it's not the best design, then it's not worth doing. So you're changing your position from it's impossible to do to it's not worth doing? You're still acting as if nobody ever considered what you're suggesting, which is just plain

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Wednesday, May 14, 2014 6:41 PM Not at all. My position is still that we tried multiple alternatives and ruled them out. Yes, 10 odd years ago you looked at reloading a flat text configuration file and decided not to do it. And since not a single thing could have

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Wednesday, May 14, 2014 8:15 PM There's no point in people writing email replies to you if you're incapable of reading. If you're unwilling to read information that people provide you in links, you're just wasting everyone's time. So far I've seen a lot of links and

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Howard Chu Sent: Wednesday, May 14, 2014 10:25 PM There's a difference between expressing a desire, and insisting upon it. Yup. Can't speak for anybody else, but I'm pretty sure I've never insisted on or demanded anything from you. The desire has been expressed, hooray, move on now.

RE: Antw: RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Ulrich Windl Sent: Wednesday, May 14, 2014 11:13 PM Well if you want to sync your configuration with LDAP means, the LDAP representation (as well as DIT metadata) makes sense. Yes, if you eat LDAP for breakfast, lunch, and dinner, dream about LDAP, and don't really work with anything

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Michael Ströder Sent: Thursday, May 15, 2014 1:02 AM Wir können ja auch auf Deutsch schreiben. Dann habe ich den Vorteil der Muttersprache. Was auf der Erde haben die Menschen tun, bevor Google übersetzen? Ciao, Michael. So your native language is German, you're posting on a

RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?

From: Mike Jackson Sent: Thursday, May 15, 2014 10:44 PM Herein lies the problem: your sense of entitlement - your sense of entitlement to receive an answer simply because you asked someone a question. Hmm, I'm not sure how continuing to engage in a discussion in which two people are

ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

parse_time to pull seconds out of it (ignoring the fractional second part), so other than modifying the format the attribute is stored in I don't believe there are any other changes required with this. From 800de5001a42fb421d814b04b09154f1ecccdc0b Mon Sep 17 00:00:00 2001 From: Paul B. Henson hen

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Sat, May 24, 2014 at 10:56:50AM +0200, Michael Ströder wrote: 'pwdFailureTime' gets replicated? Based on my testing, in a multimaster environment, that attribute is indeed replicated. For account lockout purposes, that's required if you want the failure count to be across all servers and

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Fri, May 23, 2014 at 08:51:02PM -0700, Howard Chu wrote: The *failure* occurred at that instant, not at the instant the request was received. It is simply a matter of correctness. For my purposes, it doesn't really matter whether the bind is considered to have failed as of when it was

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

to be fixed or changed. Thanks... From 4db8660f6616a70a67feba1e07ee6f866014b1d2 Mon Sep 17 00:00:00 2001 From: Paul B. Henson hen...@acm.org Date: Fri, 30 May 2014 16:47:34 -0700 Subject: [PATCH] ITS#7161 ppolicy pwdFailureTime resolution should be better than 1 second --- servers/slapd/overlays

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

I haven't seen any response to this updated patch I submitted last week; is this now something that would be considered for integration, or are there any other changes you'd like to see first? Thanks... On Fri, May 30, 2014 at 05:09:18PM -0700, Paul B. Henson wrote: On Fri, May 23, 2014 at 08

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Fri, Jun 06, 2014 at 01:58:39PM -0700, Paul B. Henson wrote: I haven't seen any response to this updated patch I submitted last week; is this now something that would be considered for integration, or are there any other changes you'd like to see first? Still looking for some feedback

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Sun, Jun 15, 2014 at 06:04:20AM -0700, Howard Chu wrote: ldap_pvt_gettime() returns structured time. There is no reason to then call lutil_tm2time() to turn it into seconds, and then call slap_timestamp() which must turn seconds into structured time again for formatting. Personally I

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Sun, Jun 15, 2014 at 12:56:34PM -0700, Howard Chu wrote: No, good point, I'd overlooked the other uses of now in the function. In that case we may just go ahead with the patch in its current form. Cool. Let me know either way, thanks...

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Sun, Jun 15, 2014 at 01:47:27PM -0700, Howard Chu wrote: Passes test022, committed to master. Cool, much appreciated. Any chance of backporting it to RE24? It actually applies cleanly, with just a couple offsets. Unless I'm not thinking of something, it should be backwards compatible with

Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second

On Mon, Jun 16, 2014 at 12:23:55PM -0700, Paul B. Henson wrote: Cool, much appreciated. Any chance of backporting it to RE24? Never mind, Quanah told me off list he'd pulled it back to RE24. Thanks again for merging it.

Re: RE24 testing call (2.4.40)

On Mon, Aug 11, 2014 at 11:52:55AM -0700, Quanah Gibson-Mount wrote: If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.39 release, please do so. [...] Execute the test suite (via make test) after it is built. Built and tested

ITS#8046 - remote unauth DoS on 2.4.40

I haven't seen any announcement of this other than on security lists, but there's an unauthenticated remote DoS bug in 2.4.40: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776991 The actual ITS is a bit confusing, the reporter at one point says he had the issue with a beta version of 2.4.40

Re: ITS#8046 - remote unauth DoS on 2.4.40

On Fri, Feb 06, 2015 at 02:09:47PM -0800, Xin Li wrote: Is there a CVE number for this one? There's been a request: http://www.openwall.com/lists/oss-security/2015/02/06/3 but I haven't seen one assigned. I forgot to mention there's also a remote DoS in the deref overlay in slapd 2.4.13

Re: accesslog purge starves kerberos kdc authentications

On Wed, Nov 04, 2015 at 07:46:47AM +0100, Michael Ströder wrote: > Do you have an eq-index on the reqStart attribute as recommended > in slapo-accesslog(5)? Yes: index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart

Re: Antw: accesslog purge starves kerberos kdc authentications

On Wed, Nov 04, 2015 at 09:08:47AM +0100, Ulrich Windl wrote: > What type of indexes do you have for your accesslog? Any warning about > missing index in syslog? The overall accesslog config is: database mdb directory /var/lib/openldap-data/accesslog maxsize 2147483648 suffix cn=accesslog rootdn

accesslog purge starves kerberos kdc authentications

We're running MIT kerberos with the ldap backend, specifically 3 openldap servers doing delta syncrepl. We started having a problem a while back where once a day the kdc would time out authentication requests, and finally tracked it down to openldap purging the accesslog. We currently have the

RE: accesslog purge starves kerberos kdc authentications

> From: Quanah Gibson-Mount > Sent: Wednesday, November 04, 2015 6:34 PM > > I set up my accesslog to do the purges every 4 hours by default, rather > than once a day, to get around this. You may want to do it more frequently > than that. I would say once a day clearly isn't often enough for

RE: Antw: accesslog purge starves kerberos kdc authentications

> From: Dameon Wagner > Sent: Thursday, November 05, 2015 3:01 AM > > Just a simple question, is /var/lib/openldap-data/accesslog on the > same physical disk as the rest of your directory storage? I note from > your initial thread on the kerberos list that there's small io spike > at the same

RE: Antw: Re: accesslog purge starves kerberos kdc authentications

> From: Ulrich Windl > Sent: Wednesday, November 04, 2015 11:26 PM > > Maybe you have an I/O bottleneck? Could you try (for a test) to put the > accesslog into a RAM disk? What filesystem are you using? Special mount > options? Yes, I'm pretty sure it is an I/O issue. The problem only occurs on

disable TLS compression with openssl?

We're currently running through all of our SSL/TLS using apps to disable SSLv3 and update the accepted ciphers list, as well as other current best practices. I don't see any way to disable SSL compression in openldap? Does SSL compression with ldap traffic not lead to the same issue as it does in

RE: disable TLS compression with openssl?

> From: Howard Chu > Sent: Monday, December 07, 2015 6:26 AM > > OpenLDAP does not enable compression so there is nothing to disable. Hmm, that's not what I am seeing. Using the latest sslscan: --- $ sslscan ldap.cpp.edu:636 Version: 1.10.6 OpenSSL 1.0.1p 9 Jul 2015 Testing

Re: Odd MMR behaviour with delta-syncrepl and refreshAndPersist

On Fri, Jun 03, 2016 at 04:06:45PM -0700, Quanah Gibson-Mount wrote: > Likely This is a new issue with 2.4.44? We've been running a 4 node MMR system under 2.4.43 that's been very stable and were planning to update to 2.4.44 this summer. Would

Re: MMR: How do you tell that the MMR servers are in sync?

On Fri, May 27, 2016 at 08:45:28AM -0400, Frank Swasey wrote: > How are you folks, who are already using MMR, checking/verifying that > the MMR participants (and their replicas) are actually in sync? To clarify, are you directing all writes to one master, or are you actually spreading writes

Re: MMR: How do you tell that the MMR servers are in sync?

On Tue, Jun 07, 2016 at 08:02:14AM -0400, Frank Swasey wrote: > I am intending that only one will officially be active at a time. > However, I am doing that by activating the service IP addresses on the > system that I want to be active instead of using a load balancer. Cool. In that case,

Re: Odd MMR behaviour with delta-syncrepl and refreshAndPersist

On Thu, Jun 16, 2016 at 10:10:19AM +0100, Mark Cairney wrote: > I'll fill in an ITS as suggested. Hmm, this is on a 2.4.44 deployment with the patch from head applied that Quanah indicated fixed the original problem he was having? I just compiled 2.4.44 with that patch last week in preparation

RE: openldap 2.4.44 + ITS 8432 patch still infinitely replicates

> From: Howard Chu > Sent: Thursday, July 21, 2016 3:36 AM > > The fix for #8432 only prevents the redundant mod from being processed on > a particular node. If other nodes are still accepting the redundant op then yes, > it will continue to propagate. So yes, you need the patched code on all >

Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates

On Thu, Jul 28, 2016 at 04:09:27PM -0700, Quanah Gibson-Mount wrote: > > The bug noted in ITS#8460 is not present in 2.4 at all. Quanah is also > > running experimental backports of features from 2.5 and forgets to > > mention that sometimes. This particular issue is from 2.5 (and is now > >

openldap 2.4.44 + ITS 8432 patch still infinitely replicates

I upgraded one of the nodes of a four node MMR delta syncrepl openldap system today to 2.4.44 + the backported ITS 8432 patch (the other three nodes were still running 2.4.41, which all four had been running for quite some time with no issues) and within a few hours they started blowing up with

RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

> From: Quanah Gibson-Mount > Subject: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20) > > For this testing call, we particularly need folks to test OpenLDAP with > startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with > the 1.1 series). Compiled successfully

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

On Fri, Feb 03, 2017 at 01:25:30PM -0800, Quanah Gibson-Mount wrote: > It turned out to not be related. :/ Oh, that's disappointing :(. I'm reproducing it multiple times on a daily basis on my production systems 8-/, is there anything I can do to help track it down? Log dumps from high log

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values

On Wed, Feb 15, 2017 at 12:22:29PM -0800, Quanah Gibson-Mount wrote: > I would suggest filing an ITS with the full backtrace info, so I can track > it. Ok, will do. > It could be useful to have the entry data from the accesslog as > well for the failed replication op, as we can see the failed

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values

On Thu, Feb 16, 2017 at 03:53:40PM -0800, Quanah Gibson-Mount wrote: > It appears to be crashing while writing the change to the accesslog > database. It's odd that the value for the attribute is NULL. Do we know > for sure what the client doing the write op to the server is sending? The

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values

On Tue, Feb 21, 2017 at 01:04:33PM +, Frank Swasey wrote: > case. I've not had any issues since. Perhaps, your Net::LDAP module > version has changed and it is sending what is being logged across the > wire instead of the delete you are expecting. Hmm, I don't believe we've updated

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

On Tue, Feb 21, 2017 at 01:14:58PM -0800, Quanah Gibson-Mount wrote: > So I'd like to know the order in which your overlays are loaded. First there's database mdb suffix cn=accesslog overlay syncprov Then databasemdb suffix "dc=cpp,dc=edu" overlay memberof overlay syncprov

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values

On Mon, Feb 20, 2017 at 04:30:00PM -0800, Quanah Gibson-Mount wrote: > Ok, I can see if I can reproduce something like this. Do you have a link > to the schema file in use that adds this attribute? https://spaces.internet2.edu/display/macedir/OpenLDAP+eduPerson > Also, can you confirm your

  1   2   >