openldap-technical June 2009

openldap-technical@openldap.org

87 participants
100 discussions

SASL LDAP binding over IPv6
by Xu, Qiang (FXSGSC) 07 Aug '09

07 Aug '09

Hi, all: In using ldapsearch to bind to a server with IPv6 address, some error pops up: =========================================================== qxu@durian(pts/3):/etc[133]$ kinit XCTEST100(a)XCIPV6.COM Password for XCTEST100(a)XCIPV6.COM: qxu@durian(pts/3):/etc[134]$ klist Ticket cache: FILE:/tmp/krb5cc_20153 Default principal: XCTEST100(a)XCIPV6.COM Valid starting Expires Service principal 06/09/09 17:35:18 06/10/09 03:34:41 krbtgt/XCIPV6.COM(a)XCIPV6.COM renew until 06/10/09 17:35:18 qxu@durian(pts/3):/etc[135]$ ldapsearch -Y GSSAPI -H 'ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail Could not create LDAP session handle for URI=ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c (-9): Bad parameter to an ldap routine qxu@durian(pts/3):/etc[136]$ ldapsearch -Y GSSAPI -H 'ldap://[3ffe:2000:0:1:e0be:1872:d4f8:6b2c]' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database) =========================================================== Shall I add the brackets [] around the IPv6 address? DNS server has been correctly set up, because sasl binding over IPv4 address is good. Any possible reason for the failure of ldapsearch? Thanks, Xu Qiang

3 20

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

Openldap 2.3 syncrepl filter problem
by Lanfeust troy 08 Jul '09

08 Jul '09

Hi list, In configuration of provider and consumer server with syncrepl is possible to modify the replication filter for add new user in replica. In fisrt time the replica is : syncrepl rid=123 provider=ldap://rh-test3.kvm.rla:389 type=refreshOnly interval=00:00:01:00 retry="30 10 600 20" searchbase="dc=local" filter="(|(objectClass=sambaGroupMapping)(uid=user1))" scope=sub schemachecking=off bindmethod=simple binddn="uid=syncrepl,ou=sysusers,dc=local" credentials=pwdsyncrepl # BEGIN Session TLS starttls="critical" tls_cacert=__CACERTFILE__ # End Session TLS When start the replica server it doing an ldapsearch and retrieve my data in replica. So now we modify the filter as the following : filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" Now when the replica doing the ldapsearch request it do with the new filter but returning numentrie to 0 like this in the log of master LDAP server: Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 BIND dn="uid=syncrepl,ou=sysusers,dc=local" mech=SIMPLE ssf=0 Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 RESULT tag=97 err=0 text= Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH base="dc=local" scope=2 deref=0 filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH attr=* + Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SEARCH RESULT tag=101 err=0 *nentries=0* text= And when i do ldapsearch manually : ldapsearch -x -b dc=local -H ldap://rh-test3.kvm.rla "(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 BIND dn="" method=128 Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 RESULT tag=97 err=0 text= Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SRCH base="dc=local" scope=2 deref=0 filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SEARCH RESULT tag=101 err=0 *nentries=13* text= I don't understand why my new user is not sync !! thanks for your help,

2 1

db_archive: DB_ENV->log_archive: DB_NOTFOUND: No matching key/data pair found
by Andreas Krummrich 01 Jul '09

01 Jul '09

Hi all, I'm running OpenLDAP 2.4.11 on a debian lenny box and it seems that I'm having trouble with the log files. I had a corrupt database some days ago and needed to restore the database from the backup. The log said: Jun 28 01:16:59 old slapd[17374]: bdb_db_open: database "dc=intern,dc=domain,dc=de": unclean shutdown detected; attempting recovery. Jun 28 01:16:59 old slapd[17374]: bdb_db_open: database "dc=intern,dc=domain,dc=de": dbenv_open(/var/lib/ldap). Jun 28 01:16:59 old slapd[17374]: bdb(dc=intern,dc=domain,dc=de): Ignoring log file: /var/lib/ldap/log.0000000005: magic number 0, not 40988 Jun 28 01:16:59 old slapd[17374]: bdb(dc=intern,dc=domain,dc=de): Invalid log file: log.0000000005: Invalid argument Jun 28 01:16:59 old slapd[17374]: bdb(dc=intern,dc=domain,dc=de): PANIC: Invalid argument Jun 28 01:16:59 old slapd[17374]: bdb(dc=intern,dc=domain,dc=de): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery Jun 28 01:16:59 old slapd[17374]: bdb_db_open: database "dc=intern,dc=domain,dc=de" cannot be recovered, err -30978. Restore from backup! Jun 28 01:16:59 old slapd[17374]: ====> bdb_cache_release_all Jun 28 01:16:59 old slapd[17374]: bdb(dc=intern,dc=domain,dc=de): txn_checkpoint interface requires an environment configured for the transaction subsystem Jun 28 01:16:59 old slapd[17374]: bdb_db_close: database "dc=intern,dc=domain,dc=de": txn_checkpoint failed: Invalid argument (22). Jun 28 01:16:59 old slapd[17374]: backend_startup_one: bi_db_open failed! (-30978) So I installed a new OpenLDAP server with the same versions and the same configuration. The first thing what I found out was that db_archive has some trouble: On the new box I get the following results from db_archive: root@new:/var/lib/ldap# db4.2_archive -sa /var/lib/ldap/cn.bdb /var/lib/ldap/dn2id.bdb /var/lib/ldap/gidNumber.bdb /var/lib/ldap/givenName.bdb /var/lib/ldap/id2entry.bdb /var/lib/ldap/loginShell.bdb /var/lib/ldap/objectClass.bdb /var/lib/ldap/sn.bdb /var/lib/ldap/uid.bdb /var/lib/ldap/uidNumber.bdb root@new:/var/lib/ldap# db4.2_archive -la /var/lib/ldap/log.0000000001 root@new:/var/lib/ldap# Looks good so far. On the old box I get the following results (there are the same databases) root@new:/var/lib/ldap# db4.2_archive -sa root@new:/var/lib/ldap# db4.2_archive -la db_archive: DB_ENV->log_archive: DB_NOTFOUND: No matching key/data pair found root@new:/var/lib/ldap# I searched the archive and googled this message, but found nothing that fits my case. Hope that someone can give me a hint, solving this issue. Thanks and kind regards, Andreas

4 6

RE: MirrorMode VS load balancing
by Brett Maxfield 30 Jun '09

30 Jun '09

Yes simple is a good thing, but you have to decide for yourself what risk and downtime is acceptable, how long to recover and how many writes is acceptable to lose. E.g. Is a one daily backup acceptable for recovery (and you lose changes since then), or do you need every single write to the hour/minute ? The more continously/frequently you write to both nodes, the more likely are sync errors, and also less recoverability of your bdb logs in the event of catastrophic power failure or inproper shutdown. I dont think anyone can decide this for you.. You need to evaluate your level of risk and what loss / downtime is acceptable to you / your employer / your customers etc., Cheers Brett -----Original Message----- From: Hideo NAKAMITSU <nomo(a)bluecoara.net> Sent: Monday, 29 June 2009 11:51 AM To: openldap-technical(a)openldap.org Subject: Re: MirrorMode VS load balancing and how about 1write/sec, 10writes/sec, 50writes/sec, 100writes/sec... I want to know this threshold like, - if writes happen 0-5/sec, it's 99% safe (at the worst unlucky case, only 2writes at the same time may break something) - 6-50/sec, may safe or not. - more than 50/sec, danger.

5 4

ppolicy and syncrepl aclaration
by Jordi Espasa Clofent 30 Jun '09

30 Jun '09

Hi, According to http://www.openldap.org/lists/openldap-software/200701/msg00149.html, the "In general, ppolicy related state values are not replicated; each replica is on its own as far as state-related attributes in enforcing password policy." ¿Is it means that of I've one provider and two consumers, the changes made in ppolicy statements in provider are not sync againt the consumers as other kind entries/attributes are? I need to know because of I've change my userPassword in provider and: * I can use without problems the new password using the provider * I cannot use the new password against the two consumers. I use LVS balancer in front of the 3 openldap servers (one provider and two consumers), so it's important that ANY change made in provider will be always synced. -- Thanks, Jordi Espasa Clofent

3 5

openldap+sasl confusion
by Seau Yeen Su 29 Jun '09

29 Jun '09

Hi, I am trying to install OpenLdap with SASL. The version of openldap i installed is openldap-2.4.16 whereas the cyrus-sasl version installed is cyrus-sasl-2.1.23. The BerkeleyDB version installed is 4.4. I followed the guidance in this link to do the installation : http://tldp.org/HOWTO/LDAP-HOWTO/sasl.html However, when i tried to add users defined in ldif file, I received ldap_sasl_interactive_bind_s: Invalid credentials (49) error when i keyed in the password generated for admin using saslpasswd2 command. I have a few questions: 1. After using saslpasswd2 to create the username and password in sasl database, do i need to add the entry into ldap database with slappasswd command? When i used slapadd command and it prompts for password, does it authenticate against sasl database or ldap database? 2. Do i need to issue saslpasswd2 for each and every user that i want to add into ldap database and to be authenticated via ldap? 3. In the slapd.conf file, under rootpw, am i supposed to use the word "secret" or the cleartext password that i keyed in using saslpasswd2 or some encrypted password? 4. What is the difference between sasl-regexp and authz-regexp? 5. Let's say i issued saslpasswd2 -c admin to create admin as the LDAP administrator. Does this mean in the slapd.conf, the rootdn should be admin or can it be another name, that will be mapped via sasl-regexp/authz-regexp? (Which does it use anyway between these 2 : sasl-regexp & authz-regexp?) 6. Previously I set up without sasl and it was rather straightforward, merely using slappasswd and save the encyrpted pasword into slapd.conf. Now, i am totally lost with its concept. I do know that names in ldap database has to be mapped to the names in sasl database. Hopefully you can enlighten me on the whole concept and how the configuration should be done. Thank you. Hope to receive some advice and guidance. -- Warmest Regards, Seau Yeen

3 5

MirrorMode VS load balancing
by Hideo NAKAMITSU 29 Jun '09

29 Jun '09

Guys, I've already read this, and understand the difference between MirrorMode and Multi Master. http://www.openldap.org/doc/admin24/replication.html Actually, when I setup 2-nodes MirrorMode and add too much entries to both nodes, at the same time, sometimes both databases weren't syncrhonized correctly. (I made a script to add 10,000 entries, and run it on both nodes at the same time.) In this case, we shouldn't update both nodes at the same time. and of course this is already discribed in the document as following. -------------------------------------------------------- MirrorMode is not what is termed as a Multi-Master solution. This is because writes have to go to just one of the mirror nodes at a time -------------------------------------------------------- but on some cases(including my environment), UPDATE happens 3-10 times in a day. it's much less than SEARCH. in this case, I think we can just put loadbalancer, and enable "load balancing" and "redundancy" (I understand UPDATE isn't load balanced.) -------------------------------------------------------- CLIENT | SLB(RoundRobin) | +-----+ SRV1 SRV2 * MirrorMode is enabled on SRV1 and SRV2 -------------------------------------------------------- My question is, MirrorMode document says "writes have to go to just one of the mirror nodes at a time." but if the writes don't happen very often, I think "writes can be done on every nodes at a time." When I did some tests, it could be done. but I'm not sure developer's thoughts. How do you think guys ?

5 9

Re: Case Ignore Ordering matching rule for IA5 String sysntax ?
by masarati＠aero.polimi.it 29 Jun '09

29 Jun '09

> Hi ! > > We are trying to define (in our own ldap schema) an IA5String attribute > type that > is required to be managed (from our ldap clients) as "case insensitive" > > "greaterOrEqual" and "lessOrEqual" filters are required to be managed > over this > attribute, so we wanted to assigne (in its attribute type definition) an > ORDERING > matching requesting "case insensitive" behaviour > > According to RFC4517 (http://tools.ietf.org/html/rfc4517) there is NO > any > ordering Matching Rule for IA5String syntax AND case insensitive support. > We > tried with the "caseIgnoreOrderingMatch" .. but slapd returns and error > (at schema > loading) as attribute type syntax (IA5String) is not allowed for this > "ordering match rule" Correct. > We checked that defining the attribute as "PrintableString" works (as > "caseIgnoreOrderingMatch" > is a valid matching rule for that sysntax according to RFC4517) ... but we > are really interested in > IA5String syntax .... > > Does openLDAP server technolgy provide a "case insensitive ordering > match" method > for IA5String syntax ? No. It doesn't because there's no standard track definition for it. However, there's nothing preventing OpenLDAP software from supporting this non-standard track feature. Adding custom matching rules is relatively "trivial". p.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2009