openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Collaborative work of MirrorMode replication and LDAP Sync Replication
by Andrei Valoshyn 10 Mar '16

10 Mar '16

Hello! slapd.conf configuration used *1.* I have test LDAP master and a consumer with LDAP Sync Replication type: Master: / overlay syncprov// // syncprov-checkpoint 100 10// // syncprov-sessionlog 100 /Consumer: syncrepl rid=115 provider=ldaps://master \ type=refreshOnly \ interval=00:00:00:30 \ scope=sub \ schemachecking=off \ searchbase="dc=exadel,dc=com" \ bindmethod=simple \ binddn="dc=exadel,dc=com" \ credentials=password \ retry="60 10 300 10" Sync is work. *2.* After that I have switched to MirrorMode replication via reconfiguring Master and Consumer: Master1(Master): /serverID 1/ / overlay syncprov// // syncprov-checkpoint 100 10// // syncprov-sessionlog 100 / / syncrepl rid=001 provider=ldaps://Master2 \// // bindmethod=simple \// // interval=00:00:00:30 \// // scope=sub \// // binddn="dc=exadel,dc=com" \// // credentials=password \// // searchbase="dc=exadel,dc=com" \// // schemachecking=off \// // type=refreshOnly \// // retry="60 +"// // // mirrormode on// / Master2(Consumer): /serverID 2/ / overlay syncprov// // syncprov-checkpoint 100 10// // syncprov-sessionlog 100 / / syncrepl rid=002 provider=ldaps://Master1 \// // bindmethod=simple \// // interval=00:00:00:30 \// // scope=sub \// // binddn="dc=exadel,dc=com" \// // credentials=password \// // searchbase="dc=exadel,dc=com" \// // schemachecking=off \// // type=refreshOnly \// // retry="60 +"// // // mirrormode on// / In this case SYNC is work(between Master1 -> Master2(NOT in Master2) -> Master1 direction) and other consumer pointed to Master1 or Master2) *3.* For fun I change configuration on Master1(Master) to previous state(Case 1) Master1: / overlay syncprov// // syncprov-checkpoint 100 10// // syncprov-sessionlog 100 / /Master2(Consumer): /serverID 2/ / overlay syncprov// // syncprov-checkpoint 100 10// // syncprov-sessionlog 100 / / syncrepl rid=002 provider=ldaps://Master1 \// // bindmethod=simple \// // interval=00:00:00:30 \// // scope=sub \// // binddn="dc=exadel,dc=com" \// // credentials=password \// // searchbase="dc=exadel,dc=com" \// // schemachecking=off \// // type=refreshOnly \// // retry="60 +"// // // mirrormode on// //In this case we have the same situation with SYNC as in CASE 2 - all work fine. Is it good working SYNC schema? What chance of breaking down db on Master1 I have? -- With Best Wishes Andrei Valoshyn Exadel Inc. System Administrator avaloshyn(a)exadel.com -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

2 4

SASL2 and Openldap
by Jerry 10 Mar '16

10 Mar '16

I just started creating a new server with FreeBSD 11. I installed the openldap port. Now I am trying to figure out how to get sasl2 up and running. Openldap is running fine now without it, but I want to secure it further. Can anyone suggest a good "How to" on how to accomplish this on a FreeBSD OS (if that makes any difference). Examples are welcomed :) -- Jerry

3 4

Re: Antw: delta sync and strictrefresh
by Quanah Gibson-Mount 10 Mar '16

10 Mar '16

--On Thursday, March 10, 2016 8:27 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Quanah Gibson-Mount <quanah(a)zimbra.com> schrieb am 10.03.2016 um 04:49 >>>> in > Nachricht <07CEB0B0E429A934BA46C978(a)[192.168.1.9]>: >> --On Wednesday, March 09, 2016 8:46 AM +0100 Ulrich Windl >> <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> >>>> Sometimes it happen the consumer go out of sync. Convenient solution: >>> >>> What you describe is not a database out of sync, but a corrupted >>> database. You never have to delete a database that is out of sync; >>> you'll just have to refresh it, and that should be automatic if >>> configured and working correctly >> >> Except, as is often the case, you're generally wrong. Unfortunately, >> every > > You like being personal and inpolite? I really missed that! ;-) Generally, no, but unfortunately your answers to people's questions fall more on the incorrect side of things than the correct side of things, causing confusion and other problems. I appreciate that you want to participate and be helpful, but giving out advice that is wrong is not helpful at all. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Experience with LDAP monitoring (cn=monitor)
by Ulrich Windl 10 Mar '16

10 Mar '16

Hi! I'd like to inform you about my experience with LDAP monitoring using the cn=monitor DN to query openLDAP. I wrote a NRPE-plugin used from Nagios/Centreon to gather performance data. So my experience is this: Issues with LDAP Monitoring "Uptime" is in whole seconds only (minor issue). SNMP uptime has a finer resolution (but limited range, unfortunately). Detailed data per peer can only be retrieved through the "Connections", but that's a moment's view only: So if a client opens a connection, does a few operations, then closes the connection, a polling client of the monitor will never see those client operations. Also when needing a cumulative count of operations per peer (or just the number of connections per peer (for a rate)), a monitor client will have to accumulate the numbers from all peer connections. If a connection (with significant operations being done) was closed since the last poll, the total number will look negative. So the monitor client will have to store accumulated numbers for closed connections per peer also (Keeping numbers for all closed connections seems inefficient). "Current Connections" is returned as monitor _counter_ object (monitorCounter), where in fact it's of type "gauge", opposed to "Total Connections" (which is also returned as monitor counter) which is actually a counter. This makes the code harder than necessary. What I'm missing are some database (BDB/HDB) runtime statistics. Ok, I'll attach four PNG graphs to let you see how far I got. Regards, Ulrich

4 4

log_rdns.patch
by A. Schulze 10 Mar '16

10 Mar '16

Hi again, this is my third and last patch I send today :-) I compiled openldap with '--enable-rlookups' and set 'reverse-lookup on' in slapd.conf I like to see the remote hostname logged. That didn't work somehow. ( I wrote this patch months ago and could not describe the real problem anymore) Anyway: the patch modify log output: reverse-lookup off: conn=4846 fd=42 ACCEPT from IP=127.0.0.1:46058 (IP=127.0.0.1:389) reverse-lookup on: conn=4191 fd=18 ACCEPT from localhost (IP=127.0.0.1:389) I never tested with ldapi:// connections. Also I expect the patch is not optimal for performance. But it works here in a small environment. Andreas

6 9

delta sync and strictrefresh
by A. Schulze 10 Mar '16

10 Mar '16

Hello, I'm a longtime openldap and syncreplica user. Now I learned about delta replication and the option "strictrefresh". But it doesn't work as promised. Maybe my expectation is simply wrong... Let's describe my use case: One ore two provider serve data to numerous consumer. Application running on the consumer host are configured to query the local consumer first and fall back to the provider. A typical LDAP-URI looks like "ldap://localhost ldaps://provider1 ldaps://provider2" Application only /read/ data. Sometimes it happen the consumer go out of sync. Convenient solution: delete the consumer ldap database and restart slapd. Now it take some time to fetch the whole data from provider to consumer server. Just in this time frame the application may query ldap://localhost and get an answer which is simply wrong because the data transfer is still in progress. That's what I want to avoid. Is that possible with openldap at all Thanks, Andreas

4 4

Patch: CIPHER_SERVER_PREFERENCE
by A. Schulze 09 Mar '16

09 Mar '16

Hello, The patch implement a feature similar to http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist Not perfect, not configurable but works here without problems. Andreas

2 1

man page patches
by A. Schulze 09 Mar '16

09 Mar '16

Hello, here is my second patch set. They modify mostly man pages and spelling errors found by Debian lintain ( https://packages.debian.org/jessie/lintian) Andreas

2 1

Re: DB_LOG_AUTOREMOVE fails to suppress the log files
by jupiter 09 Mar '16

09 Mar '16

Thanks Quanah, you are right, the solution is to switch to mdb. Thank you very much. - jupiter On Tue, Mar 8, 2016 at 7:36 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, March 07, 2016 9:35 PM +1100 jupiter <jupiter.hce(a)gmail.com> > wrote: > > The logsize is set to 10 MB, it creates a 10 MB log file every 2 - 3 >> minutes (it grows so fast, like the movie "Evolution" :-)), I ran the >> db_archive -d 10 hours ago when the disk was full, and I have run the >> db_archive -d now as the disk is full again despite the server is not too >> busy. Why doesn't the slapd do it automatically? Apart that issue, the >> ldap is running very well. I really want to figure out what is going on, >> but if I cannot find a solution, I have no choice but run a cron job to >> call db_archive -d every 8 hours. I guess that should not cause ldap any >> side effect, right? >> > > The real solution, again, is to dump the broken RH build and switch to > MDB. Then there will no longer be any pointless log files created, and your > system will be both more secure and faster (and take a smaller footprint). > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc >

1 0

Returned mail: see transcript for details
by dieter＠dkluenter.de 08 Mar '16

08 Mar '16

Message could not be delivered

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