SASL LDAP binding over IPv6
by Xu, Qiang (FXSGSC)
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
14 years, 1 month
Solaris LDAP Mapping
by Matthew.GARRETT＠external.total.com
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.
14 years, 2 months
replicating cn=config
by Matthew Edlefsen
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
14 years, 2 months
Openldap 2.3 syncrepl filter problem
by Lanfeust troy
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,
14 years, 2 months
db_archive: DB_ENV->log_archive: DB_NOTFOUND: No matching key/data pair found
by Andreas Krummrich
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
14 years, 2 months
RE: MirrorMode VS load balancing
by Brett Maxfield
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.
14 years, 2 months
ppolicy and syncrepl aclaration
by Jordi Espasa Clofent
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
14 years, 2 months
openldap+sasl confusion
by Seau Yeen Su
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
14 years, 2 months
MirrorMode VS load balancing
by Hideo NAKAMITSU
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 ?
14 years, 2 months
Re: Case Ignore Ordering matching rule for IA5 String sysntax ?
by masarati＠aero.polimi.it
> 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.
14 years, 2 months
