openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Re: LDAP Replication settings
by Quanah Gibson-Mount 29 Mar '17

29 Mar '17

--On Wednesday, March 29, 2017 7:39 PM +0200 Ondřej Kuzník <ondra(a)mistotebe.net> wrote: > On the other hand, AFAIK syncprov knows what clients are in the > persistent search state at any moment, so it might be able to export > that under cn=monitor. Not that anyone has implemented this monitoring > yet or even sure how useful that would be... Yes, but you can pull that information out of syslog if you have stats logging enabled. But I think (hard to know for sure) they are asking for a way to know /all/ possibly replicas (currently connected or not). You used to be able to do that with slurpd back in OpenLDAP 2.3 and prior. Simply not possible with syncrepl if it's not set up using back-ldap to push out to the clients. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: LDAP Replication settings
by Quanah Gibson-Mount 29 Mar '17

29 Mar '17

--On Tuesday, March 28, 2017 5:39 PM -0700 Jai Bheemsen Rao Dhanwada <jaibheemsen(a)gmail.com> wrote: > > I am using OLC configuration for LDAP setup > > > On Tue, Mar 28, 2017 at 4:21 PM, Jai Bheemsen Rao Dhanwada > <jaibheemsen(a)gmail.com> wrote: > > > Hello, > > > I have multi master replication with 4 LDAP servers. Is there a > ldapsearch query to get all the replica servers? Not quite sure what you mean by your question. Since replication configuration is most often done on the client (replica) side, the master doesn't have any knowledge you can query about what its replicas are. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: SV: 100.000 pr. second: "connection_read(64): no connection" from slapd
by Quanah Gibson-Mount 29 Mar '17

29 Mar '17

--On Wednesday, March 29, 2017 3:37 PM +0000 Ole Nomann Thomsen <ole.nomann(a)stil.dk> wrote: > [Side note, do I answer this directly to you, or to the list? I choose > directly for now ] The list. > Thanks for your answer > > I use -d because I run slapd under deamontools > (https://cr.yp.to/daemontools/faq/create.html) and multilog > (https://cr.yp.to/daemontools/multilog.html) that are both suited for > servers that run in the foreground. So the "not in the background" thing > is intentional. I realize that I might be misusing the -d facility > somewhat, but it has been working fine until now. Reworking the setup to > use backgrounding and syslog is really not an option at this time. > > I use bdb backend database. I'd strongly advise not using back-bdb. > I agree that I have lots of clients that disconnect without closing. > Could this somehow provoke the error? It seems to be cycling in this > line: > > /* get (locked) connection */ > c = connection_get( s ); > > if( c == NULL ) { > Debug( LDAP_DEBUG_ANY, > "connection_read(%ld): no connection!\n", > (long) s, 0, 0 ); > > return -1; > } > > > > > 2017-03-06 13:56:23.140091500 58bd5c77 connection_read(64): no connection! > 2017-03-06 13:56:23.140093500 58bd5c77 connection_read(64): no connection! > 2017-03-06 13:56:23.140095500 58bd5c77 connection_read(64): no connection! > 2017-03-06 13:56:23.140097500 58bd5c77 connection_read(64): no connection! > > Once in every 2 microseconds - that suggest som kind of unintended loop > to me. No, you simply have clients that have disconnected before slapd could finish sending them results. Given that you clearly have broken clients, I'd suggest you see about setting the (olc)writetimeout parameter documented in slapd.conf(5)/slapd-config(5) and see if it alleviates the issue you are facing. --Quanah > Regards > Ole Nomann Thomsen > Seniorkonsulent > > Undervisningsministeriet > Styrelsen for It og Læring > Center for Digitale Overgange og it-styring > > Telefon: 3587 8889 > Direkte: +45 35 87 85 35 > > ole.nomann(a)stil.dk > www.stil.dk > > > >> -----Oprindelig meddelelse----- >> Fra: Quanah Gibson-Mount [mailto:quanah@symas.com] >> Sendt: 23. marts 2017 19:42 >> Til: Ole Nomann Thomsen; 'openldap-technical(a)openldap.org' >> Emne: Re: 100.000 pr. second: "connection_read(64): no connection" from >> slapd >> >> --On Thursday, March 23, 2017 2:37 PM +0000 Ole Nomann Thomsen >> <ole.nomann(a)stil.dk> wrote: >> >> > >> > >> > Hi all, >> > >> > >> > >> > my slapd (@(#) $OpenLDAP: slapd 2.4.44 (Feb 9 2017 13:38:13) $) has >> > developed a tendency to become unresponsive for 10-30 minutes at a >> time. >> > >> > I run it with -dStats,Sync which gets me a fair amount of debugging >> > info. This I pipe thru multilog to get the timestamps below. >> >> Why are you using -d? This prevents slapd from forking. It is better to >> set the loglevel to be stats+sync, and push out data to syslog. >> >> > 2017-03-10 14:39:08.686058500 58c2ac7c slapd shutdown: waiting for >> > 3643059 operations/tasks to finish >> >> You need to determine why tasks are not finishing and instead are >> remaining unfinished. What databse backend are you using? I would note >> that it would appear that you have clients disconnecting w/o waiting for >> the server to respond (thus the no connection messages). >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

LDAP Replication settings
by Jai Bheemsen Rao Dhanwada 28 Mar '17

28 Mar '17

Hello, I have multi master replication with 4 LDAP servers. Is there a ldapsearch query to get all the replica servers? I am using LDAP 2.4.43

1 1

Re: Dogtag CA with OpenLDAP?
by Howard Chu 28 Mar '17

28 Mar '17

Turbo Fredriksson wrote: > On 27 Mar 2017, at 22:09, Michael Ströder <michael(a)stroeder.com> wrote: > >> I've looked at dogtag approx. two years ago. The use of LDAP was, uumh, somewhat strange: > > Ouch, nah that doesn’t make much sense :(. > > > Do anyone know of any other product/project (open source preferred, but not > a requirement) that can do the same - provide certificates programatically? We had a module for OpenLDAP 2.0, way back when. It hasn't been maintained in years. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

Re: Large user bases cause huge number of roleOccupant in role organizationalRole
by Quanah Gibson-Mount 27 Mar '17

27 Mar '17

--On Monday, March 27, 2017 11:16 AM +0200 Huang Hongfu <huang.hongfu(a)adnovum.ch> wrote: > Dear Quanah, > > When will the OpenLDAP 2.5 be published? What is the maximum size of a > large set? Hi Hongfu, There is no timeline for when 2.5 will be released at the moment. 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: Large user bases cause huge number of roleOccupant in role organizationalRole
by Quanah Gibson-Mount 27 Mar '17

27 Mar '17

--On Friday, March 24, 2017 8:25 PM +0000 Howard Chu <hyc(a)symas.com> wrote: > Meanwhile, for people with stupid data models, performance with large > attributes in back-mdb is greatly improved in OpenLDAP 2.5. I would note that Symas's OpenLDAP build includes support for attributes with a large set of values as well, as it is undetermined when OpenLDAP 2.5 will release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Large user bases cause huge number of roleOccupant in role organizationalRole
by Howard Chu 27 Mar '17

27 Mar '17

Huang Hongfu wrote: > Hello, > > In a general design, we have a role, which is an object of organizationalRole. > Within this role, let us say it will have more than 10 million users. Each > user has a roleOccupant in the role object. > > You can imagine how huge this role object can be! This will cause a big > performance problem. Especially with LMDB as backend, the "add new user" will > become very slow at some point; and the replication will be very difficult > even we setup a delta (with accesslog and session log) replication. > > From my point of view, organizationalRole is not designed for large user bases. > > Or someone has a better idea? The same logic as used in indexing applies here - it is stupid to define a case for something that matches the majority of your population. I.e., it's stupid to define a presence index on an attribute if that attribute occurs in the majority of your entries. It is stupid to define a group or role if the majority of entries will be a member of it. A presence index is only useful if the attribute occurs rarely. A group/role is only useful if the members are a minority of the total population. In this case you should define a group/role for all users who *aren't* part of the majority. Meanwhile, for people with stupid data models, performance with large attributes in back-mdb is greatly improved in OpenLDAP 2.5. -- -- 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

Large user bases cause huge number of roleOccupant in role organizationalRole
by Huang Hongfu 24 Mar '17

24 Mar '17

Hello, In a general design, we have a role, which is an object of organizationalRole. Within this role, let us say it will have more than 10 million users. Each user has a roleOccupant in the role object. You can imagine how huge this role object can be! This will cause a big performance problem. Especially with LMDB as backend, the "add new user" will become very slow at some point; and the replication will be very difficult even we setup a delta (with accesslog and session log) replication. From my point of view, organizationalRole is not designed for large user bases. Or someone has a better idea? Best regards Hongfu -- Hongfu Huang, Senior System Engineer MSc in Computer Science We're the tech in Fintech: www.adnovum.ch/fintech AdNovum Informatik AG Wengistrase 7, 8005 Zurich, Switzerland phone +41 44 272 6111, Direct: +41 44 270 5266 huang.hongfu(a)adnovum.ch www.adnovum.ch Locations: Zurich (HQ), Bern, Budapest, Ho Chi Minh City, Singapore

2 1

Re: 100.000 pr. second: "connection_read(64): no connection" from slapd
by Quanah Gibson-Mount 23 Mar '17

23 Mar '17

--On Thursday, March 23, 2017 2:37 PM +0000 Ole Nomann Thomsen <ole.nomann(a)stil.dk> wrote: > > > Hi all, > > > > my slapd (@(#) $OpenLDAP: slapd 2.4.44 (Feb 9 2017 13:38:13) $) has > developed a tendency to become unresponsive for 10-30 minutes at a time. > > I run it with -dStats,Sync which gets me a fair amount of debugging info. > This I pipe thru multilog to get the timestamps below. Why are you using -d? This prevents slapd from forking. It is better to set the loglevel to be stats+sync, and push out data to syslog. > 2017-03-10 14:39:08.686058500 58c2ac7c slapd shutdown: waiting for > 3643059 operations/tasks to finish You need to determine why tasks are not finishing and instead are remaining unfinished. What databse backend are you using? I would note that it would appear that you have clients disconnecting w/o waiting for the server to respond (thus the no connection messages). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical