openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

solaris ssh key passwordless login openldap,
by Csaba Dobo 24 Apr '15

24 Apr '15

Hi, I am curerntly putting together a system to create a central authentication and have a problem with solaris machines to log in to openldap with sshkey that are stored in openldap. I have found a thread: http://www.openldap.org/lists/openldap-software/200710/msg00041.html that talks about the issue: it seems as if this control is needed in the rootdse request control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 Problem is I have no idea how to put that in? Do I have to create a special ppolicy? If yes, could you please help? Got any idea? many thanks, Csaba http://man7.org/linux/man-pages/man5/slapo-ppolicy.5.html

2 1

Re: Antw: LMDB usage with long or variable length keys
by Alex V. 24 Apr '15

24 Apr '15

On 4/24/2015 9:02 AM, Ulrich Windl wrote: > > I think this depends very much on your access patterns (which you didn't explain). > > Regards, > Ulrich What required is `get(key)` and `set(key, val)`. And, optional but not unwanted, range lookup.

1 0

mis-identified self-signed cert
by Chuck Theobald 24 Apr '15

24 Apr '15

Built openldap 2.4.40 from source, trying to replicate the directory structure used by RHEL, but using openssl instead of nss. Various dir-placement options to configure got me to a standard RHEL (and typical Linux) structure. I am now trying to start using the /etc/init.d/slapd script from a mostly-working (sans TLS) RHEL installation, but startup fails. Silently. This may be because slapd cannot read the private server key file, but should this not be read before changing the effective running user to ldap? I would like my slapd to be running as something other than user 0. Anyway, I managed to prop up a server from the command line: slapd -F ./slapd.d but now cannot talk to it with TLS enabled: TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root, issuer: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain) Enter LDAP Password: The server cert and ca certs I am using are not self-signed, at least by me, and were obtained through Internet2 via our University's central IS department. The same certs are working fine with the web server on my machine. I think the key clue is the "unknown CA" in the messages above. But, how to solve? -- Chuck Theobald System Administrator The Robert and Beverly Lewis Center for Neuroimaging University of Oregon P: 541-346-0343 F: 541-346-0345

2 1

Re: Antw: Re: Slapd running very slow
by Geoff Swan 22 Apr '15

22 Apr '15

On 2015-04-22 11:45 PM, Ulrich Windl wrote: >>>> Geoff Swan <gswan3(a)bigpond.net.au> schrieb am 22.04.2015 um 14:06 in Nachricht > <55378EE0.40103(a)bigpond.net.au>: > >> On 2015-04-22 4:49 PM, Ulrich Windl wrote: > [...] >>>> Are there any clues about key factors affecting this? Linux, in this >>>> case, has vm.swappiness set to 10, vm.dirty_ratio at 12 and >>>> vm.dirty_background at 3. However I've noticed that when dirty pages are >>>> flushed to disc, the system stalls. And that operation appears to take a >>>> relatively long time. Disc write speed should be close to 130MB/s (file >>>> copy, dd test etc) however it appears to be much slower than this with >>>> the page flush. >>> Did you try NOT tuning those? A swapped in-memory database is not the thing >> you usually want. >> Swappiness for an out-of-the-box kernel was 60, which sounds way too >> high. So I reduced it to 10. > Did we see your "free" stats? On a server running SLES11 SP3 (kernel 3.0.101) with similar memory (no slapd, but a huge Oracle and a NFS Server) I have: > # free > total used free shared buffers cached > Mem: 132156276 131202644 953632 40317620 5219804 95059508 > -/+ buffers/cache: 30923332 101232944 > Swap: 20956756 165852 20790904 > > I believe what the system pages out is really "dead meat". According to sar there is little actual paging: > > 00:00:01 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff > 11:00:01 12671.34 1979.03 4469.13 0.00 3412.08 0.00 0.00 0.00 0.00 > 11:10:01 11598.11 1693.74 4949.54 0.01 3466.14 0.00 0.00 0.00 0.00 > 11:20:01 12141.05 4759.01 4219.09 0.02 3753.33 0.00 0.00 0.00 0.00 > 11:30:01 14619.11 1562.84 4185.04 0.00 3134.25 0.00 0.00 0.00 0.00 > > (Most "fage faults" are due to processes staring and ending with demand paging, I guess) > > Regards, > Ulrich > Free stats look fine to me. No swap is being used, or has been used yet on this system. total used free shared buffers cached Mem: 132005400 21928192 110077208 10612 363064 19230072 -/+ buffers/cache: 2335056 129670344 Swap: 8388604 0 8388604 The effect I am seeing is that despite a reasonably fast disc system, the kernel writing of dirty pages is painfully slow.

1 0

Re: Antw: Re: Slapd running very slow
by Geoff Swan 22 Apr '15

22 Apr '15

On 2015-04-22 4:49 PM, Ulrich Windl wrote: >>>> Geoff Swan <gswan3(a)bigpond.net.au> schrieb am 21.04.2015 um 23:19 in Nachricht > <5536BEC9.3040902(a)bigpond.net.au>: > >> On 2015-04-22 6:04 AM, Howard Chu wrote: >>> Brian Reichert wrote: >>>> On Tue, Apr 21, 2015 at 08:23:31AM -0700, Quanah Gibson-Mount wrote: >>>>> --On Tuesday, April 21, 2015 11:54 AM -0400 Brian Reichert >>>>> <reichert(a)numachi.com> wrote: >>>>>> What does your config file look like? >>>>>> >>>>>> In particular, what does this setting look like for you: >>>>>> >>>>>> # Threads - four per CPU >>>>>> threads 8 >>>>> According to his summary, he's using 48 threads. >>>> Thanks for pointing that out; I should finish my coffee before >>>> posting. :) >>>> >>>>> 4 per CPU/core was a good >>>>> rule of thumb with bdb/hdb. So far in playing with back-mdb, it's >>>>> seemed >>>>> closer to 2 per CPU/core for me in benchmarking. >> Interesting. What is the relationship between the number of threads and >> the number of concurrent bind operations? >> If I have, say, 500 clients wanting access to perform simple >> authentication/bind and perform some read/write operation, how is this >> usually handled within slapd? >> >>>> Useful to note. Has this detail ended up in any docs yet? >>> No, nor should it. Performance depends on system environment and >>> workload - the right value is one that each site must discover for >>> themselves in their own deployment. >>> >> Are there any clues about key factors affecting this? Linux, in this >> case, has vm.swappiness set to 10, vm.dirty_ratio at 12 and >> vm.dirty_background at 3. However I've noticed that when dirty pages are >> flushed to disc, the system stalls. And that operation appears to take a >> relatively long time. Disc write speed should be close to 130MB/s (file >> copy, dd test etc) however it appears to be much slower than this with >> the page flush. > Did you try NOT tuning those? A swapped in-memory database is not the thing you usually want. > Swappiness for an out-of-the-box kernel was 60, which sounds way too high. So I reduced it to 10. >

2 2

Slapd running very slow
by Geoff Swan 22 Apr '15

22 Apr '15

I have an ldap server that appears to slow down significantly even under moderate load, and wondered if there were any suggestions as to where to look. Using openldap-2.4.40 with mdb backend, on a dual Xeon (6 cores each) server with 128GB ram. Linux kernel 3.13, separate ext4 db volume (SAS). Slapd configured with 48 threads. The problem appears that as soon as there are a handful of write operations, slapd appears to stall. Binding to the ldap port takes many seconds (instead of instant), and the slapd process appear to occupy 100% of a single CPU core.

4 7

Different contextCSN on multi-master replication servers
by Nicolás Kovac Neumann 21 Apr '15

21 Apr '15

Hi, We're currently using N-way multimaster replication on two servers for our LDAP directory, both for the config and the hdb databases. It's working fine mostly, but we've run into a possible issue with the syncrepl engine which we would like to cast light on. We're using CentOS 7 with openldap-servers version 2.4.39-6. We made an update on one of the entries (server1, in this case), so server2 replicated that change (as shown below in the log): ==> server1/ldap.log <== Apr 21 13:38:55 server1 slapd[1835]: do_syncrep2: rid=002 cookie=rid=002,sid=002,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_message_to_entry: rid=002 DN: uid=user1,cn=subtree,dc=example,dc=org, UUID: 18a2436c-73ce-1030-95dd-b52dc05ced13 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 be_search (0) Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 uid=user1,cn=subtree,dc=example,dc=org Apr 21 13:38:55 server1 slapd[1835]: slap_queue_csn: queing 0x7ff8f42789f0 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_graduate_commit_csn: removing 0x7ff8f435e770 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: syncrepl_entry: rid=002 be_modify uid=user1,cn=subtree,dc=example,dc=org (0) Apr 21 13:38:55 server1 slapd[1835]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_queue_csn: queing 0x7ff8f42789f0 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server1 slapd[1835]: slap_graduate_commit_csn: removing 0x7ff8f41b7b90 20150421123855.643239Z#000000#002#000000 ==> server2/ldap.log <== Apr 21 13:38:55 server2 slapd[1948]: slap_queue_csn: queing 0x7f897affb220 20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server2 slapd[1948]: syncprov_sendresp: to=001, cookie=rid=002,sid=002,csn=20150421123855.643239Z#000000#002#000000 Apr 21 13:38:55 server2 slapd[1948]: slap_graduate_commit_csn: removing 0x7f89307f42a0 20150421123855.643239Z#000000#002#000000 Nothing strange up to now, however, if we query the contextCSN, it differs on both servers. For server1, we have: contextCSN: 20150421123523.281736Z#000000#001#000000 contextCSN: 20150421123417.889477Z#000000#002#000000 For server2, the value for server ID 001 differs: contextCSN: 20150421115324.003502Z#000000#001#000000 contextCSN: 20150421123417.889477Z#000000#002#000000 However, the entry seems to replicate the entryCSN correctly on both servers: entryCSN: 20150421123417.889477Z#000000#002#000000 Is this the expected behavior? Shouldn't both contextCSN values match on both servers? Thanks! Regards, Nicolás

2 1

C++11 wrapper for LMDB
by Arto Bendiken 21 Apr '15

21 Apr '15

Figured I'd announce this here in case it might be useful to others working with LMDB from C++: https://github.com/bendiken/lmdbxx This is a <lmdb++.h> header file that implements a comprehensive C++ wrapper for LMDB, offering both an error-checked procedural interface and an object-oriented resource interface with RAII semantics. See here for a basic example program using this wrapper: https://github.com/bendiken/lmdbxx/blob/master/example.cc#L1 A quick summary of features (read the README for more information): • Designed to be entirely self-contained as a single <lmdb++.h> header file that can be dropped into a project. • Implements a straightforward mapping from C to C++, with consistent naming. • Provides both a procedural interface and an object-oriented RAII interface. • Simplifies error handling by translating error codes into C++ exceptions. • Carefully differentiates logic errors, runtime errors, and fatal errors. • Exception strings include the name of the LMDB function that failed. • Plays nice with others: all symbols are placed into the lmdb namespace. • 100% free and unencumbered public domain software. The <lmdb++.h> header file requires a C++11 compiler and standard library. Recent releases of Clang or GCC will work fine. The wrapper is pretty complete at this point and is used in a production setting in the implementation of an RDF graph database. Next steps would be to figure out a versioning policy (vis-a-vis LMDB), package it up as a tarball release, and publish the generated Doxygen HTML documentation somewhere. Best regards from springtime Berlin, Arto -- Arto Bendiken | @bendiken | http://ar.to

1 0

slapd verifyclient fails on demand
by E.therepa 21 Apr '15

21 Apr '15

Dear Tech list, I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list. In order to use this in slapd/ldap utils i use this settings, slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard Slapd debug, 55353d59 slapd starting 55353d5b conn=1000 fd=16 ACCEPT from IP=10.50.2.12:50764 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 55353d5b conn=1000 fd=16 closed (TLS negotiation failure) ldapsearch debug, ldap_start_tls: Can't contact LDAP server (-1) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server. Best regards, E.therepa

6 6

Re: R: Antw: Re: Elapsed Time logging
by Quanah Gibson-Mount 21 Apr '15

21 Apr '15

--On Tuesday, April 21, 2015 1:16 PM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> "fabymoscarella(a)virgilio.it" <fabymoscarella(a)virgilio.it> schrieb am >>>> 21.04.2015 > um 11:23 in Nachricht <14cdb4a4678.fabymoscarella(a)virgilio.it>: >> Hi, >> thank you for your interest. I was mistakenly sure of the field's >> availability. >> >> I would have liked to use the "etime" field to monitor OpenLDAP >> dependability through my SIEM platform, by identifying long lasting >> operations. >> Could you please give me some pointers about monitoring "operations >> completed" or any other useful parameter? > ># if you configured monitoring... ># just querying "search" operations here... > e.g. ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=operations,cn=monitor' -s > sub '(cn=Search)' monitorOpCompleted As Ulrich notes, simply enable the monitoring backend. I suggest reading up on the slapd-monitor(5) man page. Btw, I've patched my openldap build with the ITS noted, and it's working just fine, although the term is "duration" not "etime". --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical