openldap-technical March 2016

openldap-technical@openldap.org

51 participants
51 discussions

Re: After power reset, LMDB sub-DBs' key-pairs are missing
by Arto Bendiken 16 Mar '16

16 Mar '16

Hi Ulrich, On Tue, Mar 15, 2016 at 9:00 AM, Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Arto Bendiken <arto(a)bendiken.net> schrieb am 14.03.2016 um 17:30 in Nachricht > <CAE7aNuS4=5ENrgL7w=zDqUe2dE7WH01nkAkAX76Msuw_uj=xug(a)mail.gmail.com>: >> Here's a curious case that I had not encountered with LMDB as yet previously: >> >> 1. There was a power reset of a virtual machine with an active LMDB >> writer process (standalone use, not OpenLDAP) on an LMDB file >> containing three sub-DBs. > [...] > > Hi! > > What is a "power reset of a virtual machine"? A virtual power reset (i.e. reset), or a power reset of the host? > In the latter case some writes that the VM considers done may not be committed on the host, depending on the exact configuration. You didn't give any details on that, so I can only guess... The latter, with the VM's virtio disks being LVM volumes assigned and dedicated to it using libvirt--a run-of-the-mill configuration. -- Arto Bendiken | @bendiken | http://ar.to

2 1

Re: olcAccess/olcLimits modifications
by PenguinWhispererThe . 15 Mar '16

15 Mar '16

It's still weird that adding and deleting works with the index but the replace not. No consistent usage there. Probably the devs had better things to do ;) Anyway. Thanks for clarifying indexes and where I can and can't use them ;) <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> 0 viruses found. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2016-03-15 17:19 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, March 15, 2016 1:58 PM +0200 Cole <cole(a)opteqint.net> wrote: > > To replace the 12th index, you could do: >>> >>> changetype: modify >>> delete: olcAccess >>> olcAccess: {11} >>> >>> ^ deletes the 12th index, since it is ZERO based. If you want the 13th >>> index ({12}), adjust appropriately. >>> >>> changetype: modify >>> add: olcAccess >>> olcAccess: {11} <new rule> >>> >> >> So in order to modify olcAccess: {11}, you first have to delete it and >> then re-add it? There is no way to modify it in place and change its >> contents? >> > > No. What I generally do is read the value, store that, tweak it how I > want, and then write it back (delete, add modified value). What's handed > with the way things are ordered in cn=config is that you don't have to run > the delete command against the full exact value, but only the index. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc >

2 1

Re: olcAccess/olcLimits modifications
by Cole 15 Mar '16

15 Mar '16

> The poster who gave you that advice is wrong. "replace" replaces the entire > entry with what you've added. You want add: value, not replace: value, like > you originally had. Thanks Quanah for providing the correct answer. I could not find an example, and did not have a ldap server handy in order to test. > > To replace the 12th index, you could do: > > changetype: modify > delete: olcAccess > olcAccess: {11} > > ^ deletes the 12th index, since it is ZERO based. If you want the 13th > index ({12}), adjust appropriately. > > changetype: modify > add: olcAccess > olcAccess: {11} <new rule> So in order to modify olcAccess: {11}, you first have to delete it and then re-add it? There is no way to modify it in place and change its contents? Thanks /Cole > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc

2 1

Error 80 with ldapmodify
by Christian Schmidt 15 Mar '16

15 Mar '16

Hi all, we're running Debian Jessie with slapd-2.4.40+dfsg-1+deb8u2 and ldap-utils-2.4.40+dfsg-1+deb8u2. No special modifications have been taken to slapd's configuration and/or the directory itself , and trying to add the following ldif file... dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.gnutls.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/ssl/ldap.gnutls.crt - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/ssl/intermediate.pem ...results in error 80: # ldapmodify -Y EXTERNAL -H ldapi:/// -f ./ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) All the files are readable for the user slapd is running as. Invoking slapd with debug level 255 shows: [..] 56e2e677 => slap_access_allowed: add access granted by manage(=mwrscxd) 56e2e677 => access_allowed: add access granted by manage(=mwrscxd) 56e2e677 oc_check_required entry (cn=config), objectClass "olcGlobal" 56e2e677 oc_check_allowed type "objectClass" 56e2e677 oc_check_allowed type "cn" 56e2e677 oc_check_allowed type "olcArgsFile" 56e2e677 oc_check_allowed type "olcLogLevel" 56e2e677 oc_check_allowed type "olcPidFile" 56e2e677 oc_check_allowed type "olcToolThreads" 56e2e677 oc_check_allowed type "structuralObjectClass" 56e2e677 oc_check_allowed type "entryUUID" 56e2e677 oc_check_allowed type "creatorsName" 56e2e677 oc_check_allowed type "createTimestamp" 56e2e677 oc_check_allowed type "olcTLSCertificateKeyFile" 56e2e677 oc_check_allowed type "olcTLSCertificateFile" 56e2e677 oc_check_allowed type "olcTLSCACertificateFile" 56e2e677 oc_check_allowed type "entryCSN" 56e2e677 oc_check_allowed type "modifiersName" 56e2e677 oc_check_allowed type "modifyTimestamp" 56e2e677 send_ldap_result: conn=1002 op=1 p=3 56e2e677 send_ldap_result: err=80 matched="" text="" 56e2e677 send_ldap_response: msgid=2 tag=103 err=80 <---- Error 80 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 02 67 07 0a 01 50 04 00 04 00 0....g...P.... ldap_write: want=14, written=14 0000: 30 0c 02 01 02 67 07 0a 01 50 04 00 04 00 0....g...P.... 56e2e677 conn=1002 op=1 RESULT tag=103 err=80 text= [..] What's wrong there? I couldn't find anything useful to feed $SEARCHENGINE with. Thanks & Regards, Christian -- No signature available.

3 6

Replication Failing with TLS ... Sneaky Little Config Error
by Daniel Howard 14 Mar '16

14 Mar '16

I have set up OpenLDAP per the nice tutorial at https://help.ubuntu.com/lts/serverguide/openldap-server.html and on my previous run-throughs, I succeeded at setting up replication via TLS. But now that I'm implementing on the dedicated hardware, I am not able to replicate via TLS. SOLUTION: It turns out the solution was to add a space to an LDIF file ... On PROVIDER I will see, for example: Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 fd=49 ACCEPT from IP= 10.10.3.117:60277 (IP=0.0.0.0:389) Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 BIND dn="" method=128 Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 RESULT tag=97 err=0 text= Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH base="dc=qxxxxxxxxd,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=2043))" Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Mar 14 16:13:15 ldap0 slapd[1536]: <= bdb_equality_candidates: (uidNumber) not indexed Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH base="dc=qxxxxxxxxd,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=djh))" Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 14 16:13:16 ldap0 slapd[1536]: conn=1392 op=3 UNBIND While on CONSUMER: Mar 14 16:13:15 ldap1 slapd[3672]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15 2015 18:19:13) $#012#011buildd@lgw01-53 :/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd Mar 14 16:13:16 ldap1 slapd[3673]: slapd starting Mar 14 16:13:16 ldap1 slapd[3673]: do_syncrepl: rid=317 rc -1 retrying Mar 14 16:13:16 ldap1 sudo: pam_unix(sudo:session): session closed for user root Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 ACCEPT from IP= 10.10.5.3:15197 (IP=0.0.0.0:389) Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 closed (connection lost) I *CAN* to TLS from consumer to master: 0-16:18 djh@ldap1 ~$ *ldapsearch -LLL -x -ZZ -H ldap://ldap0.mtv.**qxxxxxxxxd.com uid=djh cn* dn: uid=djh,ou=People,dc=qxxxxxxxxd,dc=com cn: djh So, I increase olcLogLevel to add sync: Mar 14 16:22:09 ldap1 slapd[4133]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15 2015 18:19:13) $#012#011buildd@lgw01-53 :/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd Mar 14 16:22:10 ldap1 slapd[4134]: slapd starting Mar 14 16:22:10 ldap1 sudo: pam_unix(sudo:session): session closed for user root Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrep2: rid=317 cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000 Mar 14 16:22:10 ldap1 slapd[4134]: slap_queue_csn: queing 0x7f0c5c114995 20160314224255.836334Z#000000#000#000000 Mar 14 16:22:10 ldap1 slapd[4134]: slap_graduate_commit_csn: removing 0x7f0c5c114d10 20160314224255.836334Z#000000#000#000000 Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrepl: rid=317 rc -1 retrying THAT is the contextCSN on the provider! 0-16:24 djh@ldap0 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=qxxxxxxxxd,dc=com contextCSN # provider* dn: dc=qxxxxxxxxd,dc=com contextCSN: 20160314224255.836334Z#000000#000#000000 0-16:22 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=qxxxxxxxxd,dc=com contextCSN # consumer* dn: dc=qxxxxxxxxd,dc=com contextCSN: 20160314224152.708568Z#000000#000#000000 As best I can tell, the connection works, the replication works, but the consumer is not asking for TLS. 0-16:29 djh@ldap1 ~$ *sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config* olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com bindmethod=si mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase ="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=audi tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry=" 60 +" syncdata=accesslogstarttls=critical tls_reqcert=demand If I rip out starttls=critical tls_reqcert=demand then sync works no problem. If I enable logging on the PROVIDER I see: Mar 14 16:35:46 ldap0 slapd[6838]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15 2015 18:19:13) $#012#011buildd@lgw01-53 :/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd Mar 14 16:35:46 ldap0 slapd[6839]: slapd starting Mar 14 16:35:46 ldap0 sudo: pam_unix(sudo:session): session closed for user root Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 ACCEPT from IP= 10.10.5.3:17876 (IP=0.0.0.0:389) Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 closed (connection lost) Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 ACCEPT from IP= 10.10.3.117:60312 (IP=0.0.0.0:389) Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc= *qxxxxxxxxd*,dc=com" method=128 Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc= *qxxxxxxxxd*,dc=com" mech=SIMPLE ssf=0 Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 RESULT tag=97 err=0 text= Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH attr=targetDN changeType changes newRDN deleteOldRDN newSuperior entryCSN Mar 14 16:35:55 ldap0 slapd[6839]: Entry reqStart=20160314224152.000005Z,cn=accesslog CSN 20160314224152.708568Z#000000#000#000000 older or equal to ctx 20160314224152.708568Z#000000#000#000000 Mar 14 16:35:55 ldap0 slapd[6839]: syncprov_search_response: cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000 Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=2 UNBIND Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 closed So .......... it looks like ... sync works until it doesn't because ... we're not binding consumer to provider TLS because .. ? WAIT A GOSH DARN SECOND HERE .... 0-16:41 djh@ldap1 ~$ *sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config* olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com bindmethod=si mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase ="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=audi tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry=" 60 +" *syncdata=accesslogstarttls=critical* tls_reqcert=demand Yeah ... 0-16:43 djh@ldap1 ~$ *cat consumer_sync_tls.ldif* dn: olcDatabase={1}hdb,cn=config replace: olcSyncRepl olcSyncRepl: rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com bindmethod=simple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand 0-16:43 djh@ldap1 ~$ *sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldifSASL/EXTERNAL authentication started* SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}hdb,cn=config" No errors ... **edit consumer_sync_tls.ldif, add a space to the end of the line ending in syncdata=accesslog** 0-16:45 djh@ldap1 ~$ *sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldifSASL/EXTERNAL authentication started* SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}hdb,cn=config" Same result, no errors, aaand: 0-16:46 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=**qxxxxxxxxd,dc=com contextCSN # consumer* dn: dc=qxxxxxxxxd,dc=com contextCSN: 20160314224255.836334Z#000000#000#000000 Well, I just paid some dues. I want to add olcLogLevel config perhaps? Would that have helped me here? Thanks ... -danny -- http://dannyman.toldme.com

1 0

Re: olcAccess/olcLimits modifications
by PenguinWhispererThe . 14 Mar '16

14 Mar '16

I tried exactly that notation however that replaced the whole entry (so only one index left). I only wanted to replace the 12th index. On Mar 14, 2016 15:12, "Cole" <cole(a)opteqint.net> wrote: > Hi, > Yes, it should be possible, so from your first example: > > dn: olcDatabase={2}mdb,cn=config > changetype:modify > add: olcAccess > olcAccess: {0}full accessrule > > > Change that to: > > dn: olcDatabase={2}mdb,cn=config > changetype:modify > replace: olcAccess > olcAccess: {0}full accessrule > > > Notice the use of "replace" instead of "add". > > Regards > /Cole > > On 14 March 2016 at 15:01, PenguinWhispererThe . < > th3penguinwhisperer(a)gmail.com> wrote: > >> I was successfully able to modify the olcLimits and olcAccess. >> >> What I still wonder if it's possible to just replace one index. I've >> tried but all the indexes got removed and replaced with the one I put. >> >> >> Thanks in advance! >> >> 2016-03-11 16:27 GMT+01:00 Cole <cole(a)opteqint.net>: >> >>> Hi, >>> >>> That is correct. Also if you leave out the {#} entry, the value will be >>> added at the end of any current values. >>> >>> I learnt most of these details from the zytrax book on openldap, as it >>> contained non-trivial examples. This section: >>> http://www.zytrax.com/books/ldap/ch6/slapd-config.html#use-security >>> describes the {} functionality. >>> >>> Regards >>> /Cole >>> >>> On 10 March 2016 at 22:56, PenguinWhispererThe . < >>> th3penguinwhisperer(a)gmail.com> wrote: >>> >>>> > That's completely missing the point of these ordering prefixes. >>>> I honestly don't see a lot of mentioning about this except for replace >>>> and deletes. Maybe it was my use of keywords. >>>> >>>> I did some tries but I failed. I couldn't find any clear examples on >>>> doing what I wanted. I mostly saw add/replace options but without the {} >>>> ordering. I'm very new to this. >>>> >>>> I'll try again tomorrow. >>>> >>>> So from the IETF I understand I should be using something like this to >>>> insert a row at the beginning: >>>> >>>> dn: olcDatabase={2}mdb,cn=config >>>> changetype:modify >>>> add: olcAccess >>>> olcAccess: {0}full accessrule >>>> >>>> >>>> Thanks for your responses! Greatly appreciated! >>>> >>>> >>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> 0 >>>> viruses found. www.avast.com >>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >>>> <#1102690717_582214293_-541461954_-448044489_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>> >>>> 2016-03-10 18:39 GMT+01:00 Ryan Tandy <ryan(a)nardis.ca>: >>>> >>>>> On Thu, Mar 10, 2016 at 05:18:01PM +0100, PenguinWhispererThe . wrote: >>>>> >>>>>> I've been looking for examples for inserting in between but couldn't >>>>>> find >>>>>> any. Maybe I use the wrong keywords in our favorite search engine. >>>>>> >>>>>> Is this deleting and adding or replacing the way to go to make these >>>>>> changes? >>>>>> Are there alternatives? >>>>>> >>>>> >>>>> You can add a new entry with the index {n} specified. Existing entries >>>>> will be re-numbered (their index incremented) to make room. >>>>> >>>> >>>> >>> >> >

3 2

After power reset, LMDB sub-DBs' key-pairs are missing
by Arto Bendiken 14 Mar '16

14 Mar '16

Here's a curious case that I had not encountered with LMDB as yet previously: 1. There was a power reset of a virtual machine with an active LMDB writer process (standalone use, not OpenLDAP) on an LMDB file containing three sub-DBs. 2. After rebooting, the previously-populated LMDB file (~7 GB in size) appears mostly empty, including when examined with mdb_stat or mdb_dump. Mostly empty meaning that each of three sub-DBs now has only one K/V entry, instead of 7M+ as they used to. In addition, the main DB now indicates six entries instead of the expected three (for the sub-DBs). 3. mdb_copy (with or without -c) does not remedy the situation, producing a mostly (logically) empty database. This is with LMDB release 0.9.18 running on Ubuntu 14.04.4 (kernel 3.13.0-79-generic) on an ext4 partition (noatime,nodev,nosuid,noexec) on Intel SSD storage in SW RAID-1 configuration. As mentioned, the LMDB file had three sub-DBs, each with 7M+ entries (as of last backup). No new sub-DBs are created after the database is initially initialized. After initial creation, these three sub-DBs only ever get appended to with new key/value pairs, no code ever deletes or modifies key/value pairs in them. The writer code inserts new entries one at a time, commits the LMDB transaction, and syncs to disk. I've enclosed mdb_stat output from before/after (before being from a backup, after which numerous more writes had been done). I've also included mdb_dump output of the main DB and three sub-DBs. The mdb_dump output for the sub-DBs indicates that they each now contain only a single entry (instead of 7M+), that entry being in each case the first key/value pair that was ever inserted into that sub-DB (ages ago). The mdb_dump output for the main DB is baffling--instead of the three expected entries, or the six that mdb_stat indicates after the reboot, the output includes a multitude of entries--some 2,590. (I've omitted most of them in the attached, but can provide a copy privately.) What are my options for recovering an LMDB database in this state, to the extent possible? Has anyone else experienced a similar scenario? Thanks, Arto -- Arto Bendiken | @bendiken | http://ar.to

2 4

How to find master server in dual master replica setup
by Kartik Vashishta 14 Mar '16

14 Mar '16

Hi, I followed this: http://www.server-world.info/en/note?os=CentOS_7&p=openldap&f=6 to set up Master-Master replica's. Now the ldif files in the tmp directory are gone and I need to figure out which one was the Master in the replica setup. I only have access to the replicated master server. I need to know the hostname of the "main" master server. Thanks in advance. Regards, Kartik Vashishta

1 0

Why is MDB_USE_PWRITEV disabled by default?
by Bryan Matsuo 13 Mar '16

13 Mar '16

I have tried to find information on the internet about the flag MDB_USE_PWRITEV but haven't had much luck. I was a little surprised to find that the pwritev() system call is never used by default (in liblmdb or openldap itself AFAICT). Because a naive analysis would suggest that pwritev() is always better than the alternative. The Makefile for liblmdb suggests that the defaults for flags should be correct for most platforms. So I am just left wondering why the default on all systems is to avoid pwritev(). Can anyone provide some insight on this matter for me? I maintain some bindings for the Go language and it has been asked that this flag be applied to all Linux builds by default. I am trying to make the most appropriate decision for general use of the library. Thanks, - Bryan

1 0

Enable memberof in static mode configuration
by Elias Pereira 12 Mar '16

12 Mar '16

Hello guys, In all searches that I did, I found only how to make in the dynamic configuration (cn=config). How do I enable the attribute in the old way (slapd.conf)? -- Elias Pereira

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2016