openldap-technical

openldap-technical@openldap.org

9937 discussions

LibLmdb non string data
by Tim Uckun 04 Dec '16

04 Dec '16

I am writing a wrapper for liblmdb and one thing I was able to do was to store simple integers and floats as the value into the database. This seems to work pretty well but I am wondering if this is somehow against best practice. One bad thing about this is that when you are doing a seek or a cursor operation the code does not know what kind of data is at the record. I have some routines to cast them back from the pointers but the user has to know what to cast them to. It would be very handy if the MDB_val struct had a field for metadata, even if it just a byte. Anyway I am wondering how much trouble I am getting myself with this practice. Thanks.

3 3

Re: n-way multi master and mirror mode
by Howard Chu 04 Dec '16

04 Dec '16

Brendan Kearney wrote: > On 12/04/2016 04:49 PM, Quanah Gibson-Mount wrote: >> Again, Mirror Mode is a concept, not a setting. The setting you refer to, >> is, as I previously noted, misnamed. Either your servers are configured to >> do multimaster replication, or they aren't. Mirrormode - the concept - is irrelevant here. All of the official docs show the mirrormode setting being used in N-Way multimaster. > yes, i seem to be in the trap about the mirror mode misnomer. though > ambiguous, your statements indicate that mirror mode the setting is required > for n-way multi master replication. That is what the Admin Guide already says. > > i agree most of my traffic is reads. i have 7 examples of connections with > deferred operations. they are all SRCH's (i.e. reads). I seem to misrember > the source of the deferred connections. bind-dyndb-ldap does not show in my > logs. sssd access is what 6 of 7 examples show. below is one sample. This is just due to sssd being very poorly written. It spews out a bunch of LDAP requests without waiting for replies. It then abandons N-1 of the requests as soon as it reads the first reply. And then it reissues the remaining requests, over and over. Instead it should just wait a little longer for all the replies, instead of abandoning and resubmitting the same requests and wasting redundant work. You're better off using nslcd or nssov, since they actually implement LDAP queries in a competent fashion. > ReceivedAt FromHost SysLogTag Message > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 fd=29 ACCEPT from > IP=192.168.88.4:59233 (IP=192.168.88.1:389) > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=0 SRCH base="" > scope=0 deref=0 filter="(objectClass=*)" > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=0 SRCH attr=* > altServer namingContexts supportedControl supportedExtension supportedFeatures > supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality > defaultNamingContext lastUSN highestCommittedUSN > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=0 SEARCH RESULT > tag=101 err=0 nentries=1 text= > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=1 BIND dn="" > method=163 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=1 RESULT tag=97 > err=14 text=SASL(0): successful result: > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=2 BIND dn="" > method=163 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=2 RESULT tag=97 > err=14 text=SASL(0): successful result: > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=3 BIND dn="" > method=163 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=3 BIND > authcid="host/hypervisor.bpk2.com(a)BPK2.COM" > authzid="host/hypervisor.bpk2.com(a)BPK2.COM" > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=3 BIND > dn="cn=hypervisor,ou=computers,dc=bpk2,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=3 RESULT tag=97 > err=0 text= > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=4 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=4 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=8 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=8 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=9 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=9 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=10 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=10 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=6 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=6 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=7 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=7 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=5 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=5 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=11 ABANDON msg=5 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=12 ABANDON msg=6 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=13 ABANDON msg=7 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=14 ABANDON msg=8 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=15 ABANDON msg=9 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=16 ABANDON msg=10 > 12/04/16 04:00 PM server1 slapd[5033]: conn=2434 op=17 ABANDON msg=11 > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=19 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=18 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=18 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=19 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=20 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=20 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=21 ABANDON msg=19 > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=22 ABANDON msg=20 > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=23 ABANDON msg=21 > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=24 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=24 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=26 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=26 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=27 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=27 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=25 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=25 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=28 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:03 PM server1 slapd[5033]: conn=2434 op=28 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:03 PM server1 slapd[5033]: connection_input: conn=2434 > deferring operation: too many executing > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=29 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=29 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=30 ABANDON msg=25 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=31 ABANDON msg=26 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=32 ABANDON msg=27 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=33 ABANDON msg=28 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=34 ABANDON msg=29 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=35 ABANDON msg=30 > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=36 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=36 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:04 PM server1 slapd[5033]: conn=2434 op=37 ABANDON msg=37 > 12/04/16 04:07 PM server1 slapd[5033]: conn=2434 op=38 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:07 PM server1 slapd[5033]: conn=2434 op=38 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:07 PM server1 slapd[5033]: conn=2434 op=39 ABANDON msg=39 > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=40 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=41 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=41 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=40 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=42 SRCH > base="ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com" scope=2 deref=0 > filter="(&(objectClass=sudoRole)(modifyTimestamp>=20150104230653Z)(!(modifyTimestamp=20150104230653Z)))" > > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=42 SRCH > attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs > sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=43 ABANDON msg=41 > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=44 ABANDON msg=42 > 12/04/16 04:12 PM server1 slapd[5033]: conn=2434 op=45 ABANDON msg=43 > 12/04/16 04:15 PM server1 slapd[5033]: conn=2434 op=46 UNBIND > 12/04/16 04:15 PM server1 slapd[5033]: conn=2434 fd=29 closed > > > -- -- 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: n-way multi master and mirror mode
by Quanah Gibson-Mount 04 Dec '16

04 Dec '16

--On Sunday, December 04, 2016 3:42 PM -0500 Brendan Kearney <bpk678(a)gmail.com> wrote: > my line of thinking was that if mirror mode was not appropriate for multi > master replication, then i would remove the setting and eliminate the > item from my list of potential contributing factors. if mirror mode is > not needed, there are potential efforts and cpu cycles being spent on > doing work that is unnecessary or even detrimental to the performance of > slapd. i am looking make sure mirror mode is safe to remove from my > configs, so i can test the theory. Hi Brendan, Again, Mirror Mode is a concept, not a setting. The setting you refer to, is, as I previously noted, misnamed. Either your servers are configured to do multimaster replication, or they aren't. The only time /any/ type of replication, whether it is multimaster or provider/consumer, is really going to have an impact is if you have a significant amount of sustained writes happening. So far, it sounds like your traffic is almost entirely reads. > ReceivedAt SysLogtag Message > 2016-11-15 20:35:05 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:05 slapd[1514]: connection_input: conn=6836 > deferring operation: pending operations > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing > 2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836 > deferring operation: too many executing Yes, you'd need stats logging, and it appears that all of those were only deferred for fractions of a second, which is why you see multiple messages per second. So there's not really any indication here of a problem that I can see. > i am running OpenLDAP: slapd 2.4.44 on fedora 24 using lmdb. > listener threads are the default of 1, and the value is not set. I was asking about "threads/olcThreads", not the listener threads value. That default is 16. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: n-way multi master and mirror mode
by Quanah Gibson-Mount 04 Dec '16

04 Dec '16

--On Saturday, December 03, 2016 6:42 PM -0500 Brendan Kearney <bpk678(a)gmail.com> wrote: > where do i chase down the source of roughly 10k messages a week, given > that this is my home network? do i have a bottleneck in ldap? is > bind-dyndb-ldap pounding on ldap for some unknown reason? i dont believe > this to an appropriate amount of logs for what seems to be a low volume > network. Hi Brendan, a) This has nothing to do with MMR/Mirror Mode b) It's not uncommon, and it rarely indicates a problem. Again, you would need to show that things are actually being deferred for a significant amount of time. Most often it is only for milliseconds. I.e., it's an informational message that may or may not be indicative of a real issue. Overall, you haven't really provided a lot of the necessary information to help you move forward, such as: OpenLDAP release OpenLDAP backend(s) in use Thread settings concurrency settings Specific messages of the problem etc For example, it could be the application(s) are poorly written, and fail to use persistent connections, causing binds to be constantly be deferred. Or it could be searches being deferred, etc. I.e., we have no idea /which/ operations are being deferred because you haven't provided that information. I personally prefer applying the patch to OpenLDAP that provides timing information for every operation so that I can actually tell whether or not real problems are occurring. If that interests you, I can point you at it. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: n-way multi master and mirror mode
by brendan kearney 04 Dec '16

04 Dec '16

so is it intended to indicate or dictate active vs standby status? I would want to maintain active/active status for load sharing. I am also not using a load balancer, and rely on SRV records or configs to share load. any ideas why I am seeing deferred operations, otherwise? On Dec 3, 2016 4:28 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Saturday, December 03, 2016 3:13 PM -0500 Brendan Kearney < > bpk678(a)gmail.com> wrote: > > i have a n-way multi master replicated directory, and i currently have >> mirror mode turned on. i am getting events in my logs about deferring >> operations (too many executing, etc) and want to know if i am causing >> these with mirror mode. the reading i am able to do on the topic seems >> to indicate that mirror mode is only necessary in provider/consumer >> replication, but i wanted to clarify that. is mirror mode necessary for >> n-way multi master replication? am i safe to turn it off, if it not >> needed? >> > > Mirror-Mode is a concept that has nothing to do with OpenLDAP > configuration in and of itself. The parameter in slapd.conf/cn=config is > badly misnamed. Either your servers are configured for multi-master > replication, or they aren't. > > Mirror mode is simply where you put a load balancer or similar device in > front of your LDAP servers and direct write traffic to only one > multi-master configured node at a time. > > See also <http://www.openldap.org/its/index.cgi/?findid=8511>. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Re: n-way multi master and mirror mode
by Quanah Gibson-Mount 03 Dec '16

03 Dec '16

--On Saturday, December 03, 2016 4:53 PM -0500 brendan kearney <bpk678(a)gmail.com> wrote: > > so is it intended to indicate or dictate active vs standby status? I > would want to maintain active/active status for load sharing. I am also > not using a load balancer, and rely on SRV records or configs to share > load. > > > any ideas why I am seeing deferred operations, otherwise? That's generally normal. Unless you are seeing them be deferred for a significant amount of time, I wouldn't worry about it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Having issue with openldap with TLS as a AD proxy
by Patrick.Ouellet＠promutuel.ca 03 Dec '16

03 Dec '16

Hello everyone, I hope Im at the right place for these kind of question, please tell me if I’m wrong. I just installed openldap as a proxy for AD. The proxy in itself works fine, I have made a few ldapsearch and got result I was expecting. Now I want to add TLS to it for security reason. I’m using openldap 2.4.42 on Ubuntu 16.04.1 LTS unfortunately it’s built with gnutls which I don’t know much about I would have preferred it to be built with openssl. So Im trying to make TLS work so I added these to slapd.conf TLSCipherSuite HIGH:!NULL TLSCACertificateFile /etc/SSL/LDAP/certificate_chain.cer.pem.gnutls TLSCertificateFile /etc/SSL/LDAP/p01ldp5001.cer.pem TLSCertificateKeyFile /etc/SSL/LDAP/p01ldp5001.key.pem TLSVerifyClient never security ssf=128 I also used certtool (gnutls tool) to validate my certificate I can verify my certificate_chain.cer.pem.gnutls with certtool so the file in itself is okay. certtool -e --infile certificate_chain.cer.pem.gnutls Loaded 2 certificates, 1 CAs and 0 CRLs Subject: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Checked against: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. I can also verify the whole chain if I make a file containing the 3 certs, CA, Intermediate and Server certtool -e --infile full_chain.pem --verify-hostname p01ldp5001.services.local --verify-purpose 1.3.6.1.5.5.7.3.1 Loaded 3 certificates, 1 CAs and 0 CRLs Subject: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Issuer: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Checked against: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Root CA Output: Verified. The certificate is trusted. Subject: C=CA,ST=Quebec,L=Quebec,O=Promutuel CES,OU=Operations,CN=p01ldp5001.services.local Issuer: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Checked against: C=CA,ST=Quebec,O=Promutuel CES,OU=Operations,CN=Promutuel HWS Intermediate CA 1 Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. Yet when I try to start the server I get this error main: TLS init def ctx failed: -1 Can someone help me with this? Patrick Ouellet [ligne] Administrateur Linux Operation VPSI [promutuel-assurance] Groupe Promutuel 2000, boulevard Lebourgneuf, 4e étage, Québec (Québec) G2K 0B6 [tel] 418 840-1188, poste 2393 / 1 800 510-4630 [telec] 418 840-9900 promutuelassurance.ca<https://www.promutuelassurance.ca/> Si vous devez imprimer ce document, faites-le recto verso. Si vous n'êtes pas le destinataire de ce message, veuillez le détruire après avoir informé l'expéditeur de son erreur. Par ailleurs, il est interdit de copier ou de modifier tout courriel sans l'autorisation de l'auteur. Promutuel Assurance n'assume aucune responsabilité à l'égard du contenu des messages personnels envoyés par ses employés. If you need to print this document, please print it double-sided. If you are not the intended recipient of this message, please notify the sender of the error and destroy the message. Please further note that it is prohibited to copy or modify any email without the author’s permission. Promutuel Insurance accepts no liability whatsoever with regard to the content of personal messages sent by its employees.

3 2

n-way multi master and mirror mode
by Brendan Kearney 03 Dec '16

03 Dec '16

i have a n-way multi master replicated directory, and i currently have mirror mode turned on. i am getting events in my logs about deferring operations (too many executing, etc) and want to know if i am causing these with mirror mode. the reading i am able to do on the topic seems to indicate that mirror mode is only necessary in provider/consumer replication, but i wanted to clarify that. is mirror mode necessary for n-way multi master replication? am i safe to turn it off, if it not needed? thanks in advance, brendan

1 0

Re: Building OpenLDAP with TLS support
by Quanah Gibson-Mount 02 Dec '16

02 Dec '16

--On Thursday, December 01, 2016 4:58 PM -0800 Tom Leach <leach(a)coas.oregonstate.edu> wrote: > So, as a followup to anyone else who may hit this issue, OpenLDAP 2.4.44 > won't build (without a set of patches) using OpenSSL 1.1.0c. I downloaded > the older OpenSSL 1.0.2j and everything built fine. > Hopefully the patches that allow OpenSSL 1.1.0 will be rolled into > OpenLDAP 2.4.45 but it may be longer as there seem to be a number of > OpenSSL API changes. > Tom Hi Tom, This has already been discussed several times in the last month on the list. ;) <http://www.openldap.org/lists/openldap-technical/201611/msg00016.html> is a recent example. Full support for OpenSSL 1.1 is scheduled for 2.4.45. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: LibLmdb non string data
by Howard Chu 02 Dec '16

02 Dec '16

Hallvard Breien Furuseth wrote: > On 02. des. 2016 12:26, Tim Uckun wrote: >> I am writing a wrapper for liblmdb and one thing I was able to do was to >> store simple integers and floats as the value into the database. This seems >> to work pretty well but I am wondering if this is somehow against best >> practice. >> >> One bad thing about this is that when you are doing a seek or a cursor >> operation the code does not know what kind of data is at the record. I have >> some routines to cast them back from the pointers but the user has to know >> what to cast them to. It would be very handy if the MDB_val struct had a >> field for metadata, even if it just a byte. > > LMDB handles binary data fine. The problem is ordering: > > Use a single datatype for each DB, and mdb_set_compare() > mdb_set_dupsort() to order data in that DB properly. Or > MDB_INTEGERKEY/MDB_INTEGERDUP which do this for unsigned int/size_t. > > If that is not feasible and you are mixing different datatypes in a > single database, you need to tag each data item so the compare function > can figure out how to parse and order them all. Note that a slow > compare function can degrade LMDB's performance. > > Note that the compare functions may receive unaligned values. Though > you can hack alignment 2, 4, or sizeof(size_t) = 4 or 8 by ensuring > *every* key and value in a DB has size = multiple of that alignment. > Keys always have alignment of at least 2. Hmm, I should add some > code so data will too except when both key and data have uneven size. > > Requests to add a user-defined argument to the compare functions have > been rejected. If you need that, maybe your wrapper can emulate it by > setting thread-specific data before calling LMDB, and then your sort > function can read that data. That gets cumbersome, though. > > If this is all generic, maybe define a DB with meta-info where your > wrapper can look up which datatypes (sizes, compare functions, whatever) > are in which database. > Or just stick your own identifier byte at the beginning of each data value. (Or key, if you're trying to use different type'd keys.) -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical