Re: where is debuglevel documented ?

[Quanah Gibson-Mount]

--On Monday, July 22, 2019 10:56 AM -0400 Brian Reichert 
 wrote:



I think that the OpenLDAP server and client share debug flags.  I may be
wrong on this.

  https://www.openldap.org/doc/admin24/runningslapd.html


This is correct.  It's trivial to grep the source and confirm this as well.

--Quanah




--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: where is debuglevel documented ?

[Brian Reichert]

On Mon, Jul 22, 2019 at 12:37:10PM +0200, Michael Str??der wrote:
> On 7/22/19 9:59 AM, A. Schulze wrote:
> >Am 21.07.19 um 17:27 schrieb danielle lampert:
> >>Where can I find the debuglevel values and their meaning ?
> >
> >man 8 slapd and search for "-d"
> 
> The original poster was asking for the log levels of the command-line 
> tools like ldapsearch.
> 
> I cannot find details for this.

I think that the OpenLDAP server and client share debug flags.  I may be
wrong on this.

  https://www.openldap.org/doc/admin24/runningslapd.html

Some oneline mapages for ldapsearch reinforce this, e.g.

  http://www-it.desy.de/cgi-bin/man-cgi?ldapsearch+1
  http://www.shrubbery.net/solaris9ab/SUNWaman/hman1/ldapsearch.1.html


> 
> Ciao, Michael.
> 



-- 
Brian Reichert  
BSD admin/developer at large

Re: Intensive disk write after long-running LDAP activity terminated

[Quanah Gibson-Mount]

--On Monday, July 22, 2019 2:20 PM +0200 Tamás Rébeli-Szabó 
 wrote:






Hello,

we had a long-running (several days) process doing add and modify
operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3.


I would note you're talking about OpenLDAP and LMDB releases that are over 
4 years old, past which point numerous issues have been fixed for both.


LMDB 0.9.15 Release (2015/06/19)
OpenLDAP 2.4.41 Release (2015/06/21)

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Antw: Re: where is debuglevel documented ?

[Ulrich Windl]

>>> Dieter Klünter  schrieb am 21.07.2019 um 22:10 in
Nachricht <20190721221044.086cb...@pink.fritz.box>:
> Am Sun, 21 Jul 2019 17:27:53 +0200
> schrieb danielle lampert :
> 
>> hello
>> 
>> the ldapsearch man page (
>> 
>
https://www.openldap.org/software//man.cgi?query=ldapsearch=0=1

> =OpenLDAP+2.4-Release=html
>> ) says :
>> 
>> *-d* *debuglevel*
>>  Set  the LDAP debugging level to *debuglevel*.
>> 
>> 
>> Where can I find the debuglevel values and their meaning ?
> 
> RFC4511, Section 4.1.9. Result Message

I think he was asking for the magic debug bitmask values, not LDAP error
codes.

> 
> -Dieter
> -- 
> Dieter Klünter | Systemberatung
> http://sys4.de 
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E

Antw: Re: Error when try modify olcTLS*

[Ulrich Windl]

>>> Igor Sousa  schrieb am 18.07.2019 um 19:16 in
Nachricht
:
> Hi Howard,
> 
> Howard Chu wrote:
> 
>>
>>  ^^ shouldn't this also be replace: ?
>>
> 
> By default, the Openldap-Servers-Symas (or openldap-servers from default
> repository) doesn't have olcTLSCACertificateFile entry. Due to this, I've
> used add operation instead of replace.
> 
> I've tried to set this entries in the cn=config following the commands
> below:
> 
> systemctl stop slapd
> slapcat -n 0 >> config.ldif
> rm -rf /etc/openldap/slapd.d/*
> cat config.ldif | slapadd -v -F /etc/openldap/slapd.d -n 0
> chown ldap:ldap -R /etc/openldap/slapd.d
> 
> 
> I've got to set this entries, but slapd hasn't started and when I've
> checked systemctl status slapd, I've seen as the slapd hasn't got to read
> key file. I've checked again and ldap user has had privilegies to read all
> entires has set in *olcTLSCACertificateFile*, *olcTLSCertificateFile *and
> *olcTLSCertificateKeyFile.*

Random thought: Could it be "selinux" policy that prtevents reading the file?
And does your certificate really have "localhost.localdomain" as subject?

> 
> [root@localhost ~]# systemctl status slapd
> ● slapd.service - OpenLDAP Server Daemon
>Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor
> preset: disabled)
>Active: failed (Result: exit-code) since Thu 2019-07-18 11:55:29 -03; 2h
> 5min ago
>  Docs: man:slapd
>man:slapd-config
>man:slapd-hdb
>man:slapd-mdb
>file:///usr/share/doc/openldap-servers/guide.html
>   Process: 2133 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS}
> $SLAPD_OPTIONS (code=exited, status=1/FAILURE)
>   Process: 2120 ExecStartPre=/usr/libexec/openldap/check-config.sh
> (code=exited, status=0/SUCCESS)
>  Main PID: 1928 (code=exited, status=0/SUCCESS)
> 
> Jul 18 11:55:29 localhost.localdomain runuser[2123]:
> pam_unix(runuser:session): session opened for user ldap by (uid=0)
> Jul 18 11:55:29 localhost.localdomain slapd[2133]: @(#) $OpenLDAP: slapd
> 2.4.47 (Mar 11 2019 17:22:04) $
>build@c7rpm
> :/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd
> Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx
> failed: -1
> Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase:
> Jul 18 11:55:29 localhost.localdomain slapd[2133]: slapd stopped.
> Jul 18 11:55:29 localhost.localdomain slapd[2133]: connections_destroy:
> nothing to destroy.
> Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service: control
> process exited, code=exited status=1
> Jul 18 11:55:29 localhost.localdomain systemd[1]: Failed to start OpenLDAP
> Server Daemon.
> Jul 18 11:55:29 localhost.localdomain systemd[1]: Unit slapd.service
> entered failed state.
> Jul 18 11:55:29 localhost.localdomain systemd[1]: slapd.service failed.
> 
> -
> 
> [root@localhost ~]# ls /etc/openldap/certs -l
> total 100
> -rw-r--r--. 1 root ldap  2078 Jul 18 10:47 ca.cert.pem
> -rw-r--r--. 1 root root 65536 Jul 15 15:16 cert8.db
> -rw-r--r--. 1 root root 16384 Jul 15 15:16 key3.db
> -rw-r--r--. 1 root ldap  3326 Jul 18 10:47 ldap.key.pem
> -rw-r--r--. 1 root ldap  1732 Jul 18 10:47 ldap.local.csr
> -rw-r--r--. 1 root ldap  2102 Jul 18 11:55 ldap.local.pem
> -r--r-. 1 root ldap45 Jun 21 16:09 password
> -rw-r--r--. 1 root root 16384 Jun 21 16:09 secmod.db
> 
> OBS: I've changed *olcTLSCACertificateFile*, *olcTLSCertificateFile
> *and *olcTLSCertificateKeyFile
> *files to ca.cert.pem, ldap.local.pem and ldap.key.pem respectively.
> 
> I've started thinking to test it on a Debian system aiming it works better.
> I don't have any idea about it.
> 
> --
> Igor Sousa

Intensive disk write after long-running LDAP activity terminated

[Tamás Rébeli-Szabó]

Hello,

we had a long-running (several days) process doing add and modify
operations in OpenLDAP 2.4.41 + LMDB backend + SLES 11.3.

When the process was stopped, we experienced minutes of intensive disk
write by LMDB.

The LMDB option dbnosync is not set.

Checking git we see that there should be a transaction commit in LMDB after
every LDAP add/modify operation, and the updating of on-disk contents
should happen after each LDAP add/modify operation.

Furthermore, at the OS level, dirty pages should be generally flushed every
5 seconds.

So we wonder what could possibly cause such a significant I/O burst?

Regards,

tamas

Antw: Re: Error when try modify olcTLS*

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 18.07.2019 um 22:35 in
Nachricht <0DBBAC4F8151F9DFD2CCA8D6@[192.168.1.39]>:
> --On Thursday, July 18, 2019 1:08 PM -0700 Quanah Gibson-Mount 
>  wrote:
> 
>>>  build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD...lapd
>>> Jul 18 11:55:29 localhost.localdomain slapd[2133]: main: TLS init def ctx
>>> failed: -1
>>> Jul 18 11:55:29 localhost.localdomain slapd[2133]: Enter PEM pass phrase:
>>
>> This clearly indicates your key file is password protected, which is not
>> supported.
> 
> To be clear, it's not supported to use a password protected key file and 
> then try and start slapd via an automated init system such as systemd.  To 
> use a password protected key file requires that you start slapd manually so 
> you can provide the password as part of the startup process so slapd can 
> access it.

Well, it wopuldn't really add security, but maybe slapd should have a mechanism 
to read the private key's password from some file or pipe in the future.

> 
> Regards,
> Quanah
> 
> 
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Re: where is debuglevel documented ?

[Michael Ströder]

On 7/22/19 9:59 AM, A. Schulze wrote:

Am 21.07.19 um 17:27 schrieb danielle lampert:

Where can I find the debuglevel values and their meaning ?


man 8 slapd and search for "-d"


The original poster was asking for the log levels of the command-line 
tools like ldapsearch.


I cannot find details for this.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: where is debuglevel documented ?

[Dieter Klünter]

Am Sun, 21 Jul 2019 22:50:35 +0200
schrieb Michael Ströder :

> On 7/21/19 10:10 PM, Dieter Klünter wrote:
> > Am Sun, 21 Jul 2019 17:27:53 +0200
> > schrieb danielle lampert :  
> >> the ldapsearch man page (
> >> https://www.openldap.org/software//man.cgi?query=ldapsearch=0=1=OpenLDAP+2.4-Release=html
> >> ) says :
> >>
> >> *-d* *debuglevel*
> >>   Set  the LDAP debugging level to *debuglevel*.
> >>
> >> Where can I find the debuglevel values and their meaning ?  
> > 
> > RFC4511, Section 4.1.9. Result Message  
> 
> Dieter, are you referring to ldapsearch setting a return code to the 
> LDAP result code?
> 
> The original poster asked for log levels though.

Sorry my bad. slapd -d? will show  all debug levels, plus undocumeneted
pcache.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

Re: where is debuglevel documented ?

[A. Schulze]

Am 21.07.19 um 17:27 schrieb danielle lampert:
> Where can I find the debuglevel values and their meaning ?

man 8 slapd and search for "-d"