openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

integrate motd on openldap
by Alejandro Feijoo Fraga 10 Jul '09

10 Jul '09

Hi. i have a large number of users... from diferent language (spanish,english,etc...) all under the same ldap directory and i need change de /etc/motd if user speak spanish or english. I not found info if ldap can do that, i think put a new entry at ldap (like lenguage:es/en/ga/..) and de /etc/bashrc or similar make a if and compare that entry... any diferent idea? or any method more easy? thanks!

2 1

Re: slapd + tls problem
by Alessandro Baggi 10 Jul '09

10 Jul '09

Gavin Henry wrote: > > # openssl req -newkey rsa:1024 -nodes -keyout key.pem -out > >> newreq.pem /*for server/client certificate building and >> sing*/ >> # /usr/lib/ssl/misc/CA.pl -sign >> >> I've tried using only openssl with slapd and all work very good, but not >> with GnuTLS. My system is Debian Lenny. >> >> > > What version of OpenLDAP? > > > Hi there. The problem was solved. It works fine with tls, the problem was that TLS works on port 389 not 636 (ldaps). This is the first time for me to use openldap with gnutls support. With OpenSSL works very good. Then, there was an configuration mismatch. Thanks

1 0

Query several LDAP servers
by tmp123＠menta.net 10 Jul '09

10 Jul '09

Hello, Please, are you so kind of provide me a hint about how to configure or develop the following feature?: A proxy LDAP, like the ones with slapd-ldap, must forward all received queries to a LDAP server1. If this server contains the requested item, the answer is send backward and handling stops. If the server doesn't contains the requested item, the query must be sent to a second LDAP server2. In the worst case, a maximum of 5 different servers should be queried in sequence. Initially, any server can contain any item. Nowadays, there are no tree estructure. Thanks a lot.

1 0

Solaris LDAP Mapping
by Matthew.GARRETT＠external.total.com 09 Jul '09

09 Jul '09

Folks I hope this is the right list for this. I am trying to get our Solaris Machine use LDAP for automounts. Under Solaris the file I would normally change is /var/ldap/ldap_client_file for Solaris using Ldap Version 2.0 But I am not 100% sure what I need to get LDAP automount to work. The OpenLdap Server has the following entries dn: ou=auto.apps,dc=unix,dc=total objectClass: top objectClass: automountMap ou: auto.apps A typical Map entry is dn: cn=acrobat,ou=auto.apps,dc=unix,dc=total objectClass: automount cn: acrobat automountInformation: uk-abz-vgl:/apps/acrobat Can anybody suggest suitable entries for the above ? Thanks Matthew Registered in England and Wales No.811900 Registered Office 33 Cavendish Square, London W1G 0PW This e-mail and any attachments are intended only for the person or entity to whom it is addressed and may contain confidential or privileged information. If you are not the addressee, any disclosure, reproduction, copying, distribution, or use of this communication is strictly prohibited. If you are not the intended recipient or person responsible for delivering this message to the named addressee, please notify us immediately and delete this e-mail. It is the responsibility of the addressee to scan this email and any attachments for computer viruses or other defects. The sender does not accept liability for any loss or damage of any nature, however caused, which may result directly or indirectly from this email or any file attached.

2 1

replicating cn=config
by Matthew Edlefsen 09 Jul '09

09 Jul '09

Hi, I've been trying to use syncrepl to replicate my cn=config tree and have been running into some issues. After running into a number of things not working I completely stripped everything down and attempted to follow test049 by building it from scratch. I've gotten it to work by running two instances of slapd on the same machine, on both machines, but I still can't get it to work between the two machines. System info Provider: FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Nov 15 18:38:32 EST 2008 OpenLDAP 2.4.16 Consumer: FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #1: Mon Jun 1 12:29:14 EDT 2009 OpenLDAP 2.4.16 My process is this: First I create slapd.d directories for both servers and populate them with a basic config mkdir slapd.d slapadd -n 0 -F slapd.d <<END dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: Trace olcLogLevel: Config olcLogLevel: Stats olcLogLevel: Sync olcLogLevel: Args olcLogLevel: Conns dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcRootDN: $MANAGER olcRootPW: $CONFIGPW olcDatabase: {0}config dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov END chown -R ldap:ldap slapd.d Then I launch slapd with: /usr/local/libexec/slapd -h $URI -u ldap -g ldap on both machines. At this point I can do ldapsearch on both servers and get back the correct results. I then do: ldapmodify -D "$MANAGER" -x -w "$CONFIGPW" <<END dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$PROVIDER_URI binddn="$MANAGER" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 - add: olcUpdateRef olcUpdateRef: $PROVIDER_URI END At this point I start logging the same error over and over. Here are the log messages I get: Consumer: Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: dn_callback : entries have identical CSN cn=config 20090603203325.264042Z#000000#000#000000 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=config Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=config) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=schema,cn=config>, <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=schema,cn=config Jun 3 19:55:35 jet slapd[51003]: conn=-1 op=0: config_add_internal: DN="cn=schema,cn=config" already exists Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=68 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_add cn=schema,cn=config (68) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=1 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: null_callback : error code 0x1 Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify cn=schema,cn=config (1) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify failed (1) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: do_syncrepl: rid=001 rc 1 retrying (4 retries left) Provider: Jun 3 17:02:36 rock slapd[75268]: slap_listener_activate(6): Jun 3 17:02:36 rock slapd[75268]: >>> slap_listener($PROV_URI) Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 ACCEPT from IP=$CONS_IP:56003 (IP=$PROV_IP:389) Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 do_bind Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=manager,cn=config>, <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: do_bind: version=3 dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" mech=SIMPLE ssf=0 Jun 3 17:02:36 rock slapd[75268]: do_bind: v3 bind: "cn=manager,cn=config" to "cn=manager,cn=config" Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=0 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=1 tag=97 err=0 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 RESULT tag=97 err=0 text= Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 do_search Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 17:02:36 rock slapd[75268]: => get_ctrls Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical) Jun 3 17:02:36 rock slapd[75268]: <= get_ctrls: n=2 rc=0 err="" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH attr=* + Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock last message repeated 2 times Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={0}core,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={1}cosine,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={2}inetorgperson,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={3}nis,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={-1}frontend,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75/: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_intermediate: err=0 oid=1.3.6.1.4.1.4203.1.9.1.4 len=56 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=2 tag=121 err=0 Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: ber_get_next on fd 8 failed errno=0 (Undefined error: 0) Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 do_unbind Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 UNBIND Jun 3 17:02:36 rock slapd[75268]: connection_close: conn=391 sd=8 Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 closed As I said it works perfectly if it's two slapd instances on the same machine on different ports. The machines can talk to each other and can both ldapsearch the other one. Also the firewall is reporting no blocks. If anybody has seen this before or has some insight into what the problem might be it would be very much apprectiated. Thank you in advance, Matt Edlefsen Earlham College

2 1

LDAP Access controls
by Darryl Moore 09 Jul '09

09 Jul '09

Hi all, I've installed a LDAP server on my network against which all my users can authenticate. They can even change their passwords via GUI or CLI without any issue. What I am trying to do now is allow each one of them to have an address book in their subtree. I created a subtree in each authentication relm that looks like this ou=Contacts,uid=user,ou=People,dc=domain,dc=ca Their is no problem with the rootdn adding entries below this, but I am unable to get the user to be able to. In fact I can't seem to allow the user to write anywhere. Even with the lone access rule: access to * by * write in the /etc/ldap/ldap.conf file (and yes I restart slapd everytime I change this file) I beleive the correct access rule for what I want is: access to dn.children="ou=People,dc=domain,dc=ca" by self write but that doesn't work either and I figured I'd ruduce the number of unknowns by trying to give global write permission first. A commandline test to create an entry yields this result: darryl@bison:~$ ldapadd -w ${NETPASS} -x -D "uid=darryl,ou=People,dc=domain,dc=ca" -f ~/tmp adding new entry "cn=test_test1,ou=Contacts,uid=darryl,ou=People,dc=domain,dc=ca" ldap_add: Insufficient access (50) additional info: no write access to parent ~/tmp looks like this: dn: cn=test_test1,ou=Contacts,uid=darryl,ou=People,dc=domain,dc=ca cn: test_test1 objectClass: inetOrgPerson sn: testestestets It's not an authentication issue because if NETPASS is wrong it returns: ldap_bind: Invalid credentials (49) Anyone have any ideas? There must be somthing simple I am missing, but I'm stumped! cheers, darryl

2 8

Delete operation is delayed...
by Bad Guy 09 Jul '09

09 Jul '09

Dear all, I have a 4 way Multi-master LDAP synchronization version 2.4.11 configured to run in refreshonly mode, config is below : # syncrepl directives syncrepl rid=001 provider=ldap://ldap01 bindmethod=simple binddn="cn=Manager" credentials=xxxxx searchbase="o=ABCDE" schemachecking=off type=refreshOnly interval="00:00:00:30" attrs="*,+" retry="5 5 300 +" #syncrepl rid=002 # provider=ldap://ldap02 # bindmethod=simple # binddn="cn=Manager" # credentials=xxxxx # searchbase="o=ABCDE" # schemachecking=off # type=refreshOnly # interval="00:00:00:30" # attrs="*,+" # retry="5 5 300 +" syncrepl rid=003 provider=ldap://ldap03 bindmethod=simple binddn="cn=Manager" credentials=xxxxx searchbase="o=ABCDE" schemachecking=off type=refreshOnly interval="00:00:00:30" attrs="*,+" retry="5 5 300 +" syncrepl rid=004 provider=ldap://ldap04 bindmethod=simple binddn="cn=Manager" credentials=xxxxx searchbase="o=ABCDE" schemachecking=off type=refreshOnly interval="00:00:00:30" attrs="*,+" retry="5 5 300 +" #overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Performance tuning directives sizelimit 5000 threads 16 idletimeout 0 cachesize 10000 checkpoint 256 15 We will do add/modify/delete operation daily and I have a script to check record by record of the sync status. From time to time, there is some records deleted in one of the LDAP server will not be replicated to the other servers occasionaly. But it will eventually deleted after long random time. (may be 1-2 days) Any idea ? Thanks _________________________________________________________________ 5 GB 超大容量、創新便捷、安全防護垃圾郵件和病毒 — 立即升級 Windows Live Hotmail http://mail.live.com

5 11

syncrepl consumer process
by Allan Lyons 09 Jul '09

09 Jul '09

Hi, I'm looking at developing a simple internal app that is supposed to do things based on changes to our directory. One solution would be to periodically poll the directory. A seemingly better solution would be to have some client watch for changes using the refreshAndPersist mode of syncrepl. Does anyone know of any example code that connects to the directory as a syncrepl consumer? Python examples would be preferred. Thanks, Allan.

2 2

Max number of attributes in entry
by Patric 09 Jul '09

09 Jul '09

Hi all, I am attempting to add an entry to my directory with a large number of mail attributes. This works fine until I have more than 51 mail attributes. Any more than that and the add fails with the following: Error 80 - Unknown error What I find strange is that if I add the entry with up to 51 mail attributes, I can then go and add individual mail attributes to the existing entry. If I attempt to delete the entry when it has more than 51 mail attributes I get the same error: Error 80 - Unknown error But if I remove individual mail attributes until there are only 51 then I am able to remove the entire entry. Is there some limitation that I am not aware of, and could any body suggest a method for me to get around this? Any advice would be much appreciated! Regards, Patric

1 0

Checkpointing and syncrepl
by John Kane 08 Jul '09

08 Jul '09

I am a bit confused with the difference between the slapd.bdb 'checkpoint' option and the syncprov overlay option 'syncprov-checkpoint'. On the provider, will these basically do the same thing? If so, is there an advantage to using one over the other? Also, should we do checkpointing on the consumers as well? Thanks, John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.

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