openldap-software

openldap-software@openldap.org

2719 discussions

tlsverifyclient security implications
by Josh Mullis 22 Aug '09

22 Aug '09

Hello all, Having a hard time finding the answer to this question... What are the security implications concerning the following setting in slapd.conf: tlsverifyclient allow I see a lot of openldap/tls related howto's stating to use this setting. Thanks for any help. -Josh

2 1

Re: OpenLDAP Overlay modules load problem
by Matthew Backes 20 Aug '09

20 Aug '09

> After that I configure slapd.conf to load denyop overlay module but > slapd can not load it .I have not seen any file name denyop or > similar one in file sysem.Where is a path of openldap overlay > moudules? Other issues aside, why are you trying to use denyop? It's rather obsolete and was only designed to be a tutorial for how to write a module. In that regard it is now useless as it predates the dynamic configuration system. See the modules in the servers/slapd/ overlays directory for more up to date examples. To accomplish the same deny-functionality, see the restrict option for slapd.conf, or olcRestrict for back-config. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: Using replication on RedHat servers
by Pierre Laporte 19 Aug '09

19 Aug '09

On Tue, Aug 18, 2009 at 9:50 PM, Rick Stevens <rps2(a)socal.rr.com> wrote: > > Did you install openldap-servers-overlays? I think syncprov is in that > RPM. > > Well, sice i installed the symas' rpm, everything related to openldap goes in /opt/symas/ and is built for openldap 2.4.16. I think the rpm you mention (openldap-servers-overlay) is the RedHat one, so i'm not sure it'd be compatible. On Tue, Aug 18, 2009 at 9:53 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > > Or it is already built into slapd, and no reason to module load it. > > I tought that at the beggining, I just can't include the syncprov module. When I add the line "overlay syncprov" in my slapd.conf file (without loading syncprov.la), slapd fails to start and i get this error message : Aug 6 17:29:21 localhost slapd[25880]: overlay "syncprov" not found

2 1

Re: syncrepl replication taking too long(not sync)
by Rodrigo Costa 19 Aug '09

19 Aug '09

Buchan, I have a 32bit system so I can only allocate 3GB for slapd. The machines have 12GB each but I can only allocate 3GB for a single process in a 32bit system with CentOS5.3. The tuning is done based on memory constraints and I think it should be more than enough since the traffic I have is low; only DB is a little large(4 million entrances). In the end of the day I think that I cannot have dncache with a smaller number than records in your DB. This means I cannot have a DB that cannot have all dncache allocated in memory. I was wondering if this is the case so I will about to use search or replication. The DB can run only in single system with these restrictions. Thanks, Rodrigo. Buchan Milne wrote: > On Tuesday, 18 August 2009 21:30:31 Rodrigo Costa wrote: > >> openldap software community, >> >> I'm facing some difficulties to have database synchronized with >> syncrepl. I'm running the latest openldap 2.4.17 version which after >> these issues I compiled with gdb. >> >> I have a DB(divided really in 2 DBs) where each one has around 4 million >> entrances. Based in memory limitations I have a dncachesize configured >> with around 3000000, or smaller than the maximum number of entrances in >> DBs. >> >> I loaded both server with all indexes and the same data. Starting both >> there isn't any need for syncrepl(thread from slapd) to make any search >> and then both mirrors are in sync and consuming each other. If a new >> entrance is create the other consumes since both are listening right on >> when it happens. >> >> If I stop one mirror and create even small number of entrances in the >> other, like 10, when I try to start the other provider the syncrepl >> enters in conventional syncrepl replication which search the DB for >> synchronization. >> >> This never ends causing mirrors not in synchronization. What I can see is : >> >> 1) Stop the Second mirror, like for slapcat(calling second and first as >> reference); >> 2) Add a few entrances in First mirror(kept on-line); >> 3) Second mirror start again after First mirror had some new entrances >> added by normal operation; >> 4) Syncrepl in second mirror enters in the conventional syncrepl >> replication since it detects that something is different between mirrors; >> 5) Until dncache is not filled the First mirror slapd cpu consumption is >> below 100%(around 50%) and search happens in a good manner since monitor >> shows it; >> 6) After dncache is filled(oscillates above 3mi) the First mirror cpu >> consumption enter in 100% consumption, oscillating between 98% to 102%; >> 7) The search never ends and then systems are never in sync. Cpu is >> permanently in high consumption, almost always in 100%. >> >> I let days this process running and I could see only a one or two >> entrances in sync. By the CPU looks like something is hanging the search >> where some loop is keeping the thread consuming one full cpu processing. >> >> I could collect some GDB information which I'm sending attached. Not >> sure how to interpret this overlay_walk. >> >> The idea is to stop one mirror for backup releasing this task from the >> primary server. For this replication would need to happen. >> >> Your comments are very welcome. >> > > You have provided absolutely no configuration information. There may well be > other explanations for this behaviour than the dncachesize. I can think of at > least two. > > You also haven't provided information on the systems you are using. E.g., you > may be trying on systems with too little memory (e.g., <1GB), which might be > totally inadequate for the amount of data you have. > > Regards, > Buchan > > >

2 1

Using replication on RedHat servers
by Pierre Laporte 19 Aug '09

19 Aug '09

Hello, I am setting up several openldap servers, and would like them to be synchronized, multi-master style. Configuration : Version: 2.4.16 packaged by Symas OS: RedHat 5.3 I have tried following the Admin guide but for some reason, I just can't include the syncprov module. When I add the line "overlay syncprov" in my slapd.conf file, slapd fails to start and i get this error message : Aug 6 17:29:21 localhost slapd[25880]: overlay "syncprov" not found I found some information about this bug at https://bugzilla.redhat.com/show_bug.cgi?id=466937 , but i'm not sure whether it applies for symas'package : "syncprov is compiled statically into slapd daemon to keep backward compatibility" I tried to skip this part, but as expected, replication doesn't work. I keep getting this message in logs. Aug 6 17:33:10 localhost slapd[25901]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1 According to a thread in this mailing list, this error appears when syncprov is not loaded in slapd.conf ( http://www.openldap.org/lists/openldap-software/200605/msg00277.html) So here I am, stuck. I can't find syncprov.la in my module folder (/opt/symas/lib64/openldap), and I can't find any way to solve this problem. Did I miss something ? How can i get this to work ? Any advice would be very appreciated. -- Pierre

3 5

syncrepl replication taking too long(not sync)
by Rodrigo Costa 19 Aug '09

19 Aug '09

openldap software community, I'm facing some difficulties to have database synchronized with syncrepl. I'm running the latest openldap 2.4.17 version which after these issues I compiled with gdb. I have a DB(divided really in 2 DBs) where each one has around 4 million entrances. Based in memory limitations I have a dncachesize configured with around 3000000, or smaller than the maximum number of entrances in DBs. I loaded both server with all indexes and the same data. Starting both there isn't any need for syncrepl(thread from slapd) to make any search and then both mirrors are in sync and consuming each other. If a new entrance is create the other consumes since both are listening right on when it happens. If I stop one mirror and create even small number of entrances in the other, like 10, when I try to start the other provider the syncrepl enters in conventional syncrepl replication which search the DB for synchronization. This never ends causing mirrors not in synchronization. What I can see is : 1) Stop the Second mirror, like for slapcat(calling second and first as reference); 2) Add a few entrances in First mirror(kept on-line); 3) Second mirror start again after First mirror had some new entrances added by normal operation; 4) Syncrepl in second mirror enters in the conventional syncrepl replication since it detects that something is different between mirrors; 5) Until dncache is not filled the First mirror slapd cpu consumption is below 100%(around 50%) and search happens in a good manner since monitor shows it; 6) After dncache is filled(oscillates above 3mi) the First mirror cpu consumption enter in 100% consumption, oscillating between 98% to 102%; 7) The search never ends and then systems are never in sync. Cpu is permanently in high consumption, almost always in 100%. I let days this process running and I could see only a one or two entrances in sync. By the CPU looks like something is hanging the search where some loop is keeping the thread consuming one full cpu processing. I could collect some GDB information which I'm sending attached. Not sure how to interpret this overlay_walk. The idea is to stop one mirror for backup releasing this task from the primary server. For this replication would need to happen. Your comments are very welcome. Regards, Rodrigo.

3 2

Re: syncrepl replication taking too long(not sync)
by Rodrigo Costa 18 Aug '09

18 Aug '09

Quanah, I forget to mention that even if I stop the second mirror is stopped again the first mirror cpu still being consumed. I was expecting that after the search from the second mirror is stopped the cpu consumption would be finished. Not sure if with dncache unlimited, even all other caches equal to 0, if the memory will be enough. Looks like memory needs to be enough to handle all dncache for DBs in system. Thanks, Rodrigo. Quanah Gibson-Mount wrote: > --On Tuesday, August 18, 2009 2:13 PM -0700 Rodrigo Costa > <rlvcosta(a)yahoo.com> wrote: > >> Quanah, >> >> The issue is that if I do not limit dncache the slapd crashes since >> after sometime it cannot allocate more system memory(malloc). Only >> dncache in two DBs can consume all memory possible to allocate. > > See below. You obviously need to better tune other things. > >>> Limit your memory consumption in other ways if you need >>> to (Smaller BDB cache, smaller entry cache, smaller idlcache). >>> Limiting the dncachesize is pretty much suicidal in any large db. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: syncrepl replication taking too long(not sync)
by Rodrigo Costa 18 Aug '09

18 Aug '09

Quanah, The issue is that if I do not limit dncache the slapd crashes since after sometime it cannot allocate more system memory(malloc). Only dncache in two DBs can consume all memory possible to allocate. Thanks, Rodrigo. Quanah Gibson-Mount wrote: > --On Tuesday, August 18, 2009 1:30 PM -0700 Rodrigo Costa > <rlvcosta(a)yahoo.com> wrote: > >> openldap software community, >> >> I'm facing some difficulties to have database synchronized with >> syncrepl. I'm running the latest openldap 2.4.17 version which after >> these issues I compiled with gdb. >> >> I have a DB(divided really in 2 DBs) where each one has around 4 million >> entrances. Based in memory limitations I have a dncachesize configured >> with around 3000000, or smaller than the maximum number of entrances in >> DBs. > > Don't use a limited dncachesize. With 2.4.18, you'll be able to set > it to zero (unlimited), and that will be the default, to match the old > 2.3 behavior. Limit your memory consumption in other ways if you need > to (Smaller BDB cache, smaller entry cache, smaller idlcache). > Limiting the dncachesize is pretty much suicidal in any large db. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

2 1

Proxy cache privateDB control
by Dieter Kluenter 17 Aug '09

17 Aug '09

Hi, I just want to understand the function of pcache privateDB control, could someone enlighten me? If I do a search with the control enabled, bound as user, I get Server is unwilling to perform: pcachePrivDB: operation not allowed, bound as rootdn I get Critical extension is unavailable: critical control unavailable in context What are the operations allowed with this control enabled? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

2 1

Re: OpenLDAP Overlay modules load problem
by Jonathan Clarke 17 Aug '09

17 Aug '09

On 16/08/2009 13:46, Jittinan Suwanrueangsri wrote: > I have compiled OpenLDAP 2.4.16 from source by using following command > > *CC=gcc CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include > LDFLAGS=-L/usr/local/BerkeleyDB.4.7/lib > LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.7/lib ./configure --enable-bdb > --enable-hdb --with-cyrus-sasl --with-tls --enable-ldap --enable-overlays > * > > After that I configure slapd.conf to load denyop overlay module but > slapd can not load it .I have not seen any file name denyop or similar > one in file sysem.Where is a path of openldap overlay moudules? Hi, Given the command line you used to configure OpenLDAP, all overlays are built statically into the slapd executable. You don't need to load them, you can just use them. If you want to use dynamic modules, configure with --enable-modules and --enable-overlays=mod. The default path for modules is $PREFIX/libexec/openldap/. Hope this helps, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software