moznss, gnutls, openssl
by Chuck Theobald
What is the current wisdom regarding which tls library to use?
I've got a version 2.4.39 installation on RHEL 6.6 for which I cannot
get tls to work. I end up with the "TLS: can't connect: TLS error
-5938:Encountered end of file." error. Likely a misconfiguration of
moznss, though I followed one set of directions using certutil, but lack
the proper setting for my ldap TLSCACertificateFile.
My Debian-based ldap servers run with either openssl or gnutls.
Thanks,
--
Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345
7 years, 11 months
Re: Antw: LMDB usage with long or variable length keys
by Alex V.
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.
7 years, 11 months
mis-identified self-signed cert
by Chuck Theobald
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
7 years, 11 months
Re: Antw: Re: Slapd running very slow
by Geoff Swan
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.
7 years, 11 months
Re: Antw: Re: Slapd running very slow
by Geoff Swan
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.
>
7 years, 11 months
Slapd running very slow
by Geoff Swan
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.
7 years, 11 months
Different contextCSN on multi-master replication servers
by Nicolás Kovac Neumann
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
7 years, 11 months
C++11 wrapper for LMDB
by Arto Bendiken
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
7 years, 11 months
slapd verifyclient fails on demand
by E.therepa
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
7 years, 11 months
