openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

RedHat 6 & 7 disable TLSv1.0
by Gaurav Swami 03 Oct '16

03 Oct '16

Hello, I have Redhat 6 where am trying to disable TLSv1.0 protocol.I have tried below configuration RHEL6 ----------------------------------------- [root@ldap1 ~]# rpm -qa | grep -we openldap -we openssl -we nss krb5-pkinit-openssl-1.10.3-10.el6_4.6.x86_64 openldap-servers-2.4.40-12.el6.x86_64 nss-util-3.21.0-2.el6.x86_64 nss-3.21.0-8.el6.x86_64 openssl-devel-1.0.1e-48.el6_8.1.x86_64 openssl-1.0.1e-48.el6_8.1.x86_64 openldap-clients-2.4.40-12.el6.x86_64 nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 nss-sysinit-3.21.0-8.el6.x86_64 nss-tools-3.21.0-8.el6.x86_64 openldap-2.4.40-12.el6.x86_64 nss-softokn-3.14.3-23.3.el6_8.x86_64 ---------------------------------------------------------------------------- RHEL6 Configuration ---------------------------------------- TLSProtocolMin 3.2 TLSCipherSuite HIGH ----------------------------------------- But still when I ran third party tool to check offered protocol am getting --> Testing protocols (via sockets except TLS 1.2 and SPDY/NPN) SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 offered TLS 1.1 offered TLS 1.2 offered (OK) SPDY/NPN not offered --> Testing ~standard cipher lists TLSv1.0 is still offered ,I want to disable TLSv1.0 also Any suggestiosn? -- Thanks & Regards, **Gaurav Swami**

4 3

Test
by dieter＠dkluenter.de 01 Oct '16

01 Oct '16

1 0

Fine grained access to attributes
by Ralf Mattes 29 Sep '16

29 Sep '16

Just a quick question: isit possible to control access to attributes based on an attribute tag? The idea is to hide certain attributes by adding a "...;x-hidden' tag. TIA Ralf Mattes :wq

4 8

Syncrepl initial sync provider sends entries in wrong order
by Γ. Μηλιώτης 29 Sep '16

29 Sep '16

Hello everyone, I'm wondering if a syncrepl behaviour I'm seeing is correct. My consumer is 4.4.42 and my provider 4.4.40. I'm using refreshOnly replication and when I first create the database entry on the consumer the whole process stops after 5-6 records. I have tested the syncuser and its searches against the provider return >9000 results. So it's not a limit or auth issue. I have matched the schemas on both servers successfully. I believe the issue is that the provider is sending the records in an incorrect order. I get a record with an entryCSN in 20151001 and then a record with an entryCSN before that. So, if I understand it, operating correctly, the consumer complains the record is too old and ignores it, stopping replication. The contextCSN of the provider is in the 2016* range, the consumer's is stuck in 2015* range and the log spams "too old". I'm using the -c rid=XXX option to run slapd and deleting the DB between tests. Shouldn't the provider send the entries in a entryCSN-ascending order during the initial sync? Thanks for any insight you can provide. --GM

1 0

N-Way replication
by rammohan ganapavarapu 28 Sep '16

28 Sep '16

Hi, I have n-way replication setup in ldap version 2.4.43 and i have basic technical question, do we have to specify nth server details in replication config? lets say i have server1 server2 and server3 and i wanted to setup n-way replication among these servers Part of my config looks like this # Global section serverID 1 ldap://server1 serverID 2 ldap://server2 serverID 3 ldap://server3 # database section # syncrepl directive syncrepl rid=001 provider=ldap://server1 syncrepl rid=002 provider=ldap://server2 syncrepl rid=003 provider=ldap://server3 mirrormode on So if i include the nth server itlsef in the replication provider doesn't it try to replicate it self and get it into loop condition? Please advice Thanks, Ram

1 0

Re: Fwd: Using lmdb as a pure in memory store
by Howard Chu 23 Sep '16

23 Sep '16

Russell Haley wrote: > Thanks so much for your response and thanks for the link. I've been > pouring over that documentation off and on. > > The developer currently doing the prototyping has said he ran into an > issue where the use of a very large key value caused the system to > slow down (he didn't give specifics and I didn't have time to ask). He > said it was a sparsely populated record set of about 100,00 rows but > he specifically used a large value for the key as we hope to support > UInt64 for keys (I don't know why, apparently we're indexing > sub-atomic particles?). I saw a setting for MDB_MAXKEYSIZE which was > 0 for computed, but I don't know what that means on an ARM (v6 - 32 > bit) system. Would you have any idea what would cause the performance > hit he was referring too? At a guess, you're slowing down because you're using 64bit values on a 32bit processor and once you exceed the range of a 32bit integer you need twice as many memory accesses to fetch/compare keys. Anyway, if you're using MDB_INTEGERKEY (which you should be, in this case) then you'll never get anywhere near the max keysize. > Sorry if my questions are weird, I'm trying to learn C and embedded > development through osmosis. > > Anyway, on a personal note, I was thoroughly happy to get lmdb working > in Lua through > > https://github.com/shmul/lightningmdb > > and can't wait to try his Mule Round-Robin Database tool > > https://github.com/shmul/mule > > Awesome stuff. > > Russ > > > On Thu, Sep 22, 2016 at 4:25 PM, Howard Chu <hyc(a)symas.com> wrote: >> Russell Haley wrote: >>> >>> Hello, >>> >>> I wasn't fully subscribed when I sent this so I'll send it again. >>> >>> Any input or reference hints would be great. I love reading manuals. :) >> >> >> http://lmdb.tech/doc/ >>> >>> >>> Russ >>> >>> >>> ---------- Forwarded message ---------- >>> From: Russell Haley <russ.haley(a)gmail.com> >>> Date: Tue, Sep 20, 2016 at 4:52 PM >>> Subject: Using lmdb as a pure in memory store >>> To: openldap-technical(a)openldap.org >>> >>> >>> Hi there, >>> >>> We are currently evaluating in memory key value stores for ~100,000 - >>> 200,000 records in an embedded system. I suggested lmdb but it is >>> being discounted for some reasons I thought I'd validate: >>> >>> 1) It is currently thought that a on disk file is REQUIRED for the >>> system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a >>> pure in-memory database? Could the file not just be mapped to a >>> memdisk? >> >> >> A file is required. Whether the file is on-disk or not is irrelevant. It can >> of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it >> pure in-memory. >> >> MDB_NOSYNC turns off syncing, that's why it is named that. >> >>> 2) Because these values can come very fast, that the use of a lock >>> file would cause delay and too much wear on the nand based disk (SSD). >> >> >> No. That's not how the lock file is used. >> >>> I see a no locking option ( MDB_NOLOCK) that would stop a lock file >>> being written. >> >> >> This option should only be used if you're implementing your own lock >> manager. Hint - no matter what approach you use, any other lock manager you >> use will be slower than LMDB's. >> >>> Again, another option would be mapping the lock file to >>> a memdisk to handle that? >> >> >> Yes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Using lmdb as a pure in memory store
by Howard Chu 23 Sep '16

23 Sep '16

Russell Haley wrote: > Hello, > > I wasn't fully subscribed when I sent this so I'll send it again. > > Any input or reference hints would be great. I love reading manuals. :) http://lmdb.tech/doc/ > > Russ > > > ---------- Forwarded message ---------- > From: Russell Haley <russ.haley(a)gmail.com> > Date: Tue, Sep 20, 2016 at 4:52 PM > Subject: Using lmdb as a pure in memory store > To: openldap-technical(a)openldap.org > > > Hi there, > > We are currently evaluating in memory key value stores for ~100,000 - > 200,000 records in an embedded system. I suggested lmdb but it is > being discounted for some reasons I thought I'd validate: > > 1) It is currently thought that a on disk file is REQUIRED for the > system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a > pure in-memory database? Could the file not just be mapped to a > memdisk? A file is required. Whether the file is on-disk or not is irrelevant. It can of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it pure in-memory. MDB_NOSYNC turns off syncing, that's why it is named that. > 2) Because these values can come very fast, that the use of a lock > file would cause delay and too much wear on the nand based disk (SSD). No. That's not how the lock file is used. > I see a no locking option ( MDB_NOLOCK) that would stop a lock file > being written. This option should only be used if you're implementing your own lock manager. Hint - no matter what approach you use, any other lock manager you use will be slower than LMDB's. > Again, another option would be mapping the lock file to > a memdisk to handle that? Yes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Fwd: Using lmdb as a pure in memory store
by Russell Haley 22 Sep '16

22 Sep '16

Hello, I wasn't fully subscribed when I sent this so I'll send it again. Any input or reference hints would be great. I love reading manuals. :) Russ ---------- Forwarded message ---------- From: Russell Haley <russ.haley(a)gmail.com> Date: Tue, Sep 20, 2016 at 4:52 PM Subject: Using lmdb as a pure in memory store To: openldap-technical(a)openldap.org Hi there, We are currently evaluating in memory key value stores for ~100,000 - 200,000 records in an embedded system. I suggested lmdb but it is being discounted for some reasons I thought I'd validate: 1) It is currently thought that a on disk file is REQUIRED for the system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a pure in-memory database? Could the file not just be mapped to a memdisk? 2) Because these values can come very fast, that the use of a lock file would cause delay and too much wear on the nand based disk (SSD). I see a no locking option ( MDB_NOLOCK) that would stop a lock file being written. Again, another option would be mapping the lock file to a memdisk to handle that? Thanks! Russ

1 0

How to move from hdb to mdb
by Nikolas Stylianides 22 Sep '16

22 Sep '16

Hi there. Is there a howto move from hdb to mdb? What we need to do is to transfer our directory from hdb to the mdb. Is there a book to learn about openldap? With the new OLC way of doing things? Can i have hdb and mdb running at the same time? Currently I have done the following: 1. Load the Module back_mdb 2. Created a OlcBackend 3. Created a OlcDatabase Thank you in advance -- Δρ. Νικόλας Στυλιανίδης Ηλεκτρολόγος Μηχανικός και Μηχ. Υπολογιστών Nikolas Stylianides, Dr. Dr. Eng. in Electrical & Computer Engineering Contacts ------------- Mobile Tel.: +35796741315 Email: nstylianides(a)leafnet.com.cy, nstylianides(a)gmail.com Skype: nicostyl Affilication --------------- LEAF NET LTD: Research & Development Open University of Cyprus: Research Associate, APPLIED HEALTH INFORMATICS Master Programme Academic Board Member Tο λακωνίζειν εστί φιλοσοφείν / Μηδέν Άγαν - Χίλων ο Λακεδαιμόνιος: Brevity is the soul of wit - Shakespeare William (Hamlet)

5 7

ACL privilege for MOD_INCREMENT
by Michael Ströder 20 Sep '16

20 Sep '16

HI! Considering to use LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation I'd like to reduce write access to an Integer attribute "nextID" to MOD_INCREMENT. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). I suspect the ideal solution results in a feature request for a new privilege "i". ;-) access to attrs=nextID by group=... =ri Or at least avoid that someone sets the value to a lower value. Maybe this can be achieved with slapo-constraint. Any more ideas? Ciao, Michael.

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