On 10/21/2021 6:06 PM, Howard Chu wrote:
You should change this configuration to use 2.5 dynlist's memberOf support.
Ah, it seems I stupidly didn't look at the examples at the bottom of the
man page 8-/.
I'm not using any dynamic groups, so I guess the example relevant to me is:
On 10/21/2021 6:06 PM, Howard Chu wrote:
Then this is probably dynlist searching for objectclass=cppEduPerson.
You should change this configuration to use 2.5 dynlist's memberOf support.
I must have missed that, I wasn't aware of any new specific memberOf
support in dynlist? I don't see
Paul B. Henson wrote:
> Okay, here is the start of the search:
>
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: conn=1001 op=1 do_search
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: >>> dnPrettyNormal:
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <<< dnPrettyNormal: ,
>
> Oct 21 17:14:35 ldap-dev-03
Okay, here is the start of the search:
Oct 21 17:14:35 ldap-dev-03 slapd[4335]: conn=1001 op=1 do_search
Oct 21 17:14:35 ldap-dev-03 slapd[4335]: >>> dnPrettyNormal:
Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <<< dnPrettyNormal:
,
Oct 21 17:14:35 ldap-dev-03 slapd[4335]: SRCH "dc=cpp,dc=edu" 2
Paul B. Henson wrote:
> Any thoughts on what might be going on or how I can debug it to track down
> exactly what is causing it? There was obviously a lot more debug info in the
> logs
> that I didn't include, but none of it jumped out to me as "smoking gun".
Try the search again with -d5.
So I upgraded one of my test systems to 2.5, from 2.4. Doing a quick
basic functionality check after the upgrade, I noticed that the
performance on the upgraded system was significantly slower.
When the system was running 2.4, searching for my entry after a cold
start took a little more than
--On Thursday, October 21, 2021 7:54 PM +0300 Nick Milas
wrote:
On 21/10/2021 6:39 μ.μ., Nick Milas wrote:
From the journal, some excerpts (it is very long):
My fault: I copied parts from the journal before the restart :(
Here is the actual log after restart:
The client side still
On 21/10/2021 6:39 μ.μ., Nick Milas wrote:
From the journal, some excerpts (it is very long):
My fault: I copied parts from the journal before the restart :(
Here is the actual log after restart:
Oct 21 18:31:28 ldap.noa.gr systemd[1]: slapd.service start operation
timed out. Terminating.
Nick Milas wrote:
> Thank you for the reply:
>
> Here it is:
> It shows that the CA/cert has issues. Yet, everything was working fine until
> last upgrade!
Well, it's not going to lie to you. Your CA cert isn't recognized, so some
other upgrade must
have mucked with your certs or LDAP config.
Thank you for the reply:
Here it is:
# ldapwhoami -H ldaps://ldap.noa.gr:636 -x -d -1
ldap_url_parse_ext(ldaps://ldap.noa.gr:636)
ldap_create
ldap_url_parse_ext(ldaps://ldap.noa.gr:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
Nick Milas wrote:
> Hello,
>
> Our main OpenLDAP Server (running on CentOS 7) has been working fine with
> 2.4.58.
>
> Since yesterday, after a (minor, see at the end) OS upgrade which included an
> update to LTB Openldap 2.4.59, SSL clients see:
>
> # ldapwhoami -H ldaps://ldap.noa.gr:636 -x
Hello,
Our main OpenLDAP Server (running on CentOS 7) has been working fine
with 2.4.58.
Since yesterday, after a (minor, see at the end) OS upgrade which
included an update to LTB Openldap 2.4.59, SSL clients see:
# ldapwhoami -H ldaps://ldap.noa.gr:636 -x
ldap_sasl_bind(SIMPLE): Can't
Dears,
Correction, you should read :
Issue was to NOT use the olcRootDN in the olcSyncrepl lines.
Brgds,
J-L.
13 matches
Mail list logo
