openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

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

05 Dec '16

--On Monday, December 05, 2016 6:44 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > Ulrich Windl wrote: >>>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 05.12.2016 um 04:23 >>>>> in >>> There is zero requirement to put a load balancer in front of an MMR >>> setup. >> >> But it seems to make much sense: In my experience if you configure >> multiple LDAP servers, the NSS resolver always uses the first configured >> server as long as it's reachable; even if it's not, the first configured >> server is tried first. > > This depends very much on the client. E.g. sssd works fairly well even > with simple DNS round-robin. The load is almost equally spread. But again, the point with setting up mirror mode is not to spread the load at all. It is to force all writes to a single master. My point being, this is not a necessary requirement for MMR. --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 Howard Chu 05 Dec '16

05 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. > 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/

6 5

ACL advice needed ...
by Zeus Panchenko 05 Dec '16

05 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 greetings, I'm trying to configure ACL, I belive it is possible to ... but after some attempts I doubt it is ... please, help me to understand where I'm making the mistake/s ... I need to manage possibility for "coadmins" group members to manage all except the objects of "admins" group members forgive me please my long explanation ... so I have: Important: the starting point in my case is auth accounts structure: users do auth with (lets call it) "root" objects (most upper level): uid=<USER>,ou=People,dc=abc - ---[ accounts and groups start ]------------------------------------------- dn: uid=admin1,ou=People,dc=abc dn: uid=admin7,ou=People,dc=abc dn: uid=bil,authorizedService=serviceD,uid=admin7,ou=People,dc=abc dn: uid=coadmin5,ou=People,dc=abc dn: uid=johndoe,authorizedService=serviceA,uid=coadmin5,ou=People,dc=abc dn: uid=coadmin6,ou=People,dc=abc dn: cn=admins,dc=abc memberUid: admin1 - ---[ accounts and groups end ]------------------------------------------- group objects memberUid attribute value contains uid of the "root" objects - ---[ group structure start ]------------------------------------------- dn: cn=coadmins,ou=group,dc=abc memberUid: coadmin5 memberUid: coadmin6 - ---[ group structure end ]------------------------------------------- here is the ACL I managed to work as I want: - ---[ quotation start ]------------------------------------------- access to dn.subtree="dc=abc" attrs=userPassword by set="[cn=admin,ou=group,dc=abc]/memberUid & user/uid" manage by set.exact="this/-2 & user" write by self write by anonymous auth by * break - ---[ quotation end ]------------------------------------------- this allows admins to manage passwords of anybody and for all other users manage passwords of self "root" account and service accounts (look structure of account objects above) and now, I had a hope to do the same to get possibility for coadmins to manage passwords of anybody except admins, and here what I thought about: - ---[ quotation start ]------------------------------------------- access to dn.subtree="dc=abc" attrs=userPassword by set="[cn=admin,ou=group,dc=abc]/memberUid & user/uid" manage by set="(([cn=admin,ou=group,dc=abc]/memberUid & this/uid) | ([cn=admin,ou=group,dc=abc]/memberUid & [this/-2]/uid)) & ([cn=coadmin,ou=group,dc=abc]/memberUid & user/uid)" disclose by set="[cn=coadmin,ou=group,dc=abc]/memberUid & user/uid" manage by set.exact="this/-2 & user" write by self write by anonymous auth by * break - ---[ quotation end ]------------------------------------------- and it doesn't work the initial idea of the second `by set=' row is: for coadmins to disallow all access to userPassword if account belongs to admin am I right to expect: 1.1. "[cn=admin,ou=group,dc=abc]/memberUid & this/uid" is true if uid of current record is member of the group `admin' when `this' is the very "root" account (uid=admin7,ou=People,dc=abc) 1.2. "[cn=admin,ou=group,dc=abc]/memberUid & [this/-2]/uid" uid of the "root" account (uid=admin7,ou=People,dc=abc) is admin group member when `this' is service account like: uid=bil,authorizedService=serviceD,uid=admin7,ou=People,dc=abc `this/-2' trimms it to `uid=admin7,ou=People,dc=abc' and `/uid' have to provide uid value 1.3. "[cn=coadmin,ou=group,dc=abc]/memberUid & user/uid" true if currently loggedin user uid is coadmin group member so ... was I successfull to explain what I want? :) - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhFk1kACgkQr3jpPg/3oyp7XgCggcp9Y909JRQOknE7GkgjmZpw /sYAoIyimb3gcy38qZAjlyHfbF+rH63a =aqts -----END PGP SIGNATURE-----

1 0

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

05 Dec '16

--On Monday, December 05, 2016 9:07 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > But it seems to make much sense: In my experience if you configure > multiple LDAP servers, the NSS resolver always uses the first configured > server as long as it's reachable; even if it's not, the first configured > server is tried first. After connection timeout the second server is > tried... We had dhad a case when all LDAP operations were heavily delayed > when two out of three servers had failed (due to rebooting the machine). That still has absolutely zero to do with MMR replication. There are useful and valid reasons for using load balancers across a replicated pool. Your reponse however indicates a lack of comprehension of what Mirror Mode entails. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

04 Dec '16

--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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical