openldap-software March 2010

openldap-software@openldap.org

55 participants
43 discussions

understanding replication
by Alan Batie 03 Mar '10

03 Mar '10

I'm a little puzzled by the openldap replication docs; in particular rid, entryuuid, entrycsn, contextcsn fields that I see referenced a lot. I'm guessing the rid is a random chosen id number for the secondary server (consumer?) that is used to compare the master db (entryuuid?) for context? information that indicates sync state? Basically, I'd like to understand the replication process at a slightly higher level than http://www.openldap.org/doc/admin24/syncrepl.html describes not quite completely enough... The specific task at hand is trying to understand what I'm seeing in the logs, having setup a master, loaded the db, configured replication, setup a fresh secondary mirror and turned on replication there. I let it run over the weekend, and see debug logs of what I assume is polling on the secondary, but 'slapcat | grep -c "dn:"' returns (and has been for a while) a suspiciously round number of "500" (there are around 38,000 records in the master), though I don't see any such limit anywhere in the configs. master config: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 secondary config: syncrepl rid=314 provider=ldap://master-server.peak.org:389 type=refreshOnly interval=00:00:05:00 retry="60 10 300 +" searchbase="dc=peak,dc=org" schemachecking=off bindmethod=simple binddn="cn=replicator,dc=peak,dc=org" credentials="somepassword" syncdata="accesslog" > Mar 1 17:43:33 ldap04 slapd[6242]: >>> dnPrettyNormal: <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:33 ldap04 slapd[6242]: <<< dnPrettyNormal: <uid=someuser,dc=peak,dc=org>, <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:33 ldap04 slapd[6242]: >>> dnPretty: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:33 ldap04 slapd[6242]: <<< dnPretty: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnNormalize: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnNormalize: <cn=directory manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnPretty: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnPretty: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnNormalize: <cn=Directory Manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnNormalize: <cn=directory manager,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnPretty: <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnPretty: <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnNormalize: <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnNormalize: <uid=someuser,dc=peak,dc=org> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnPretty: <cn=Subschema> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnPretty: <cn=Subschema> > Mar 1 17:43:34 ldap04 slapd[6242]: >>> dnNormalize: <cn=Subschema> > Mar 1 17:43:34 ldap04 slapd[6242]: <<< dnNormalize: <cn=subschema> > Mar 1 17:43:34 ldap04 slapd[6242]: syncrepl_entry: rid 314 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > Mar 1 17:43:34 ldap04 slapd[6242]: => bdb_search > Mar 1 17:43:34 ldap04 slapd[6242]: bdb_dn2entry("dc=peak,dc=org") > Mar 1 17:43:34 ldap04 slapd[6242]: search_candidates: base="dc=peak,dc=org" (0x00000001) scope=2 > Mar 1 17:43:34 ldap04 slapd[6242]: => bdb_dn2idl("dc=peak,dc=org") > Mar 1 17:43:34 ldap04 slapd[6242]: => bdb_filter_candidates > Mar 1 17:43:34 ldap04 slapd[6242]: AND > Mar 1 17:43:35 ldap04 slapd[6242]: => bdb_list_candidates 0xa0 > Mar 1 17:43:35 ldap04 slapd[6242]: => bdb_filter_candidates > Mar 1 17:43:35 ldap04 slapd[6242]: EQUALITY > Mar 1 17:43:35 ldap04 slapd[6242]: => bdb_equality_candidates (entryUUID) > Mar 1 17:43:35 ldap04 slapd[6242]: => key_read > Mar 1 17:43:35 ldap04 slapd[6242]: bdb_idl_fetch_key: [15cb4950] > Mar 1 17:43:35 ldap04 slapd[6242]: <= bdb_index_read 1 candidates > Mar 1 17:43:35 ldap04 slapd[6242]: <= bdb_equality_candidates: id=1, first=169, last=169 > Mar 1 17:43:35 ldap04 slapd[6242]: <= bdb_filter_candidates: id=1 first=169 last=169 > Mar 1 17:43:35 ldap04 slapd[6242]: <= bdb_list_candidates: id=1 first=169 last=169 > Mar 1 17:43:35 ldap04 slapd[6242]: <= bdb_filter_candidates: id=1 first=169 last=169 > Mar 1 17:43:35 ldap04 slapd[6242]: bdb_search_candidates: id=1 first=169 last=169 > Mar 1 17:43:35 ldap04 slapd[6242]: => test_filter > Mar 1 17:43:35 ldap04 slapd[6242]: EQUALITY > Mar 1 17:43:35 ldap04 slapd[6242]: => access_allowed: search access to "uid=someuser,dc=peak,dc=org" "entryUUID" requested > Mar 1 17:43:35 ldap04 slapd[6242]: <= root access granted > Mar 1 17:43:35 ldap04 slapd[6242]: <= test_filter 6 > Mar 1 17:43:35 ldap04 slapd[6242]: send_ldap_result: conn=-1 op=0 p=3 > Mar 1 17:43:35 ldap04 slapd[6242]: send_ldap_result: err=0 matched="" text="" > Mar 1 17:43:35 ldap04 slapd[6242]: syncrepl_entry: rid 314 be_search (0) > Mar 1 17:43:35 ldap04 slapd[6242]: syncrepl_entry: rid 314 uid=someuser,dc=peak,dc=org

4 3

using translucent proxy as syncrepl provider?
by Christoph Herrmann 03 Mar '10

03 Mar '10

Hi, I'm running openldap-2.4.21 and like to use a translucent proxy as syncrepl provider. My translucent proxy starts without complaining and runs. And the syncprov consumer also did not complain about anything, but it did start to sync. My config is very simple and syncrepl runs wihtout the translucent overlay. Is it supported to stack syncprov and translucnet? Which is the right order of the overlays in slapd.conf? Here is my translucent/syncprov slapd.conf: # include schemafiles ... # backend bdb backend ldap database bdb suffix "o=example,c=de" rootdn cn=manager,ou=private,ou=testing,o=example,c=de rootpw secret directory /var/ldap-translucent cachesize 100000 sizelimit 80000 checkpoint 16384 30 dbconfig set_cachesize 0 300000000 1 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay translucent uri "ldap://127.0.0.5" translucent_local objectClass,otherAttribute translucent_remote objectClass access to * by read overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 lastmod on # EOF Cheers Christoph &:-) -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196

1 0

Replicated cluster reindexing and log level
by Ryan Steele 02 Mar '10

02 Mar '10

I actually have two separate questions, both aimed at performance tuning my database. The first is about running slapindex on individual cluster members to preserve high availability. Namely, if each cluster member is brought offline individually for reindexing (as opposed to putting them all in read-only mode) and no new indices are added while any of the nodes are offline, are there any risks posed (if the nodes not currently being indexed are left in read/write mode) to the reindexed node when is brought back into the cluster? Or is this a relatively safe plan? The second revolves around log size. In my current environment, using the 'stats' loglevel, I get about 600-700 lines per second, and the cumulative size of the logs rotated throughout the day can reach in the area of 25G or more. Even though disk space is cheap, I'd love to rotate logs less frequently and consume fewer CPU cycles when gzipping and rotating said logs, while still having good visibility if I need to troubleshoot a problem. Is there any other loglevel folks can recommend that will still give me adequate information if I need to go back and glean information from the logs, while perhaps being a bit less verbose? Thanks as always. Respectfully, Ryan

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software March 2010