(ITS#7733) Assert failure calling mdb_cursor_del()
by dw＠botanicus.net
Full_Name: David Wilson
Version: LMDB 0.9.9
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (178.238.153.20)
Given a new environment whose main DBI has the following records inserted (in
the displayed order):
['a', '']
['b', '']
['baa', '']
['d', '']
mdb_cursor_set(MDB_LAST)
then
mdb_cursor_del(..., 0)
then
mdb_cursor_del(..., 0)
will cause an abort:
Assertion failed: (indx < NUMKEYS(mp)), function mdb_node_del, file lib/mdb.c,
line 6380.
9 years, 11 months
(ITS#7732) CSN too old MMR setup
by lanfeust99＠gmail.com
Full_Name: Lanfeut
Version: 2.4.36
OS: Centos
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.42.151.220)
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring
20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.36 (....)
4 server
host1 and host 2: only one database c=fr ( contain an ou=apps-ext )
host3 and host 4: tow database:
first ou=apps-ext (glued with c=fr ). writable by host1,2,3,4
second c=fr writable only by host1,2
ldap-int1 and ldap-int2 cn=config also into syncrepl mirrorMode
ldap-ext1 and ldap-ext2 cn=config also into syncrepl mirrorMode
all server are time sync.
Configuration:
grep serverID /etc/openldap/slapd.d/*
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 1 ldaps://ldap-int1.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 2 ldaps://ldap-int2.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 3
ldaps://ldap-ext1.vlandata.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 4
ldaps://ldap-ext2.vlandata.dom.fr
syncrepl:
ldap-int1 and ldap-int2 cn=config also into syncrepl
olcSyncrepl: {0}rid=101 provider=ldaps://ldap-int1.dom.fr binddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +"
timeout=1
olcSyncrepl: {1}rid=102 provider=ldaps://ldap-int2.cdoms.fr
binddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +"
timeout=1
olcSyncrepl: {2}rid=103 provider=ldaps://ldap-ext2.vlandata.dom.fr binddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XX
XXXX tls_reqcert=never searchbase="o=apps-ext,c=fr" type=refreshAndPersist r
etry="5 5 300 +" timeout=1
olcSyncrepl: {3}rid=104 provider=ldaps://ldap-ext1.vlandata.dom.fr binddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX
XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r
etry="5 5 300 +" timeout=1
syncrepl host3 and host4:
database apps-ext:
olcSyncrepl: {0}rid=303 provider=ldaps://ldap-ext1.vlandata.dom.fr binddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX
XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r
etry="5 5 300 +" timeout=1
olcSyncrepl: {1}rid=304 provider=ldaps://ldap-ext2.vlandata.dom.fr binddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX
XXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r
etry="5 5 300 +" timeout=1
database c=fr :
olcSyncrepl: {0}rid=201 provider=ldaps://ldap-int1.dom.fr binddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshAndPersist retry="5 5 300 +" tim
eout=1
olcSyncrepl: {1}rid=202 provider=ldaps://ldap-int2.dom.fr binddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX tls
_reqcert=never searchbase="c=fr" type=refreshAndPersist retry="5 5 300 +" tim
eout=1
ldap-int1 receive syncrepl modification from ldap-int2 with this log:
ldap-int1 log:
syncprov_matchops: skipping original sid 002
Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing
0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
... ...
ldap-ext2 receive the same modification an reply to ldap-int1 with new
cookie
ldap-int1 log
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE:
rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000
Another modification from ldap-int2 isn't apply to ldap-int1 because of csn
too old
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old,
ignoring 20131004150022.050845Z#000000#002#000000
(cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd)
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000
9 years, 11 months
Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by jsynacek＠redhat.com
On 10/15/2013 02:03 PM, hyc(a)symas.com wrote:
> Yes, your test config shows that the problem is that rwm_conn_destroy frees
> the session context while rwm_op_search is using it. Seems like the rwm
> overlay is not doing reference counting properly.
>
With the current master (fe49824f83bb0f2dd2f543c26f186b516c1d75bd), this is how
the trace looks like:
(gdb) t apply all bt
Thread 5 (Thread 0x7f53f9009700 (LWP 28210)):
#0 0x000000309360dded in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003093609ba1 in _L_lock_790 () from /lib64/libpthread.so.0
#2 0x0000003093609aa7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f5401b530a7 in ldap_pvt_thread_mutex_lock (mutex=0x7f53f980c768) at
thr_posix.c:296
#4 0x0000000000445287 in connection_operation (ctx=0x7f53f9008bb0,
arg_v=0x7f53e0001230) at connection.c:1147
#5 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at
tpool.c:945
#6 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0
#7 0x0000003092ef5e1d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f53f3fff700 (LWP 28215)):
#0 0x000000309360b575 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00007f5401b53054 in ldap_pvt_thread_cond_wait (cond=0x9373b8,
mutex=0x937390) at thr_posix.c:277
#2 0x00007f5401b518be in ldap_int_thread_pool_wrapper (xpool=0x937380) at
tpool.c:927
#3 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0
#4 0x0000003092ef5e1d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f54016dd740 (LWP 28178)):
#0 0x0000003093608d97 in pthread_join () from /lib64/libpthread.so.0
#1 0x00007f5401b52f95 in ldap_pvt_thread_join (thread=139998644971264,
thread_return=0x0) at thr_posix.c:197
#2 0x0000000000441bb4 in slapd_daemon () at daemon.c:2907
#3 0x000000000041b28a in main (argc=10, argv=0x7fff84c32388) at main.c:1013
Thread 2 (Thread 0x7f53f980a700 (LWP 28197)):
#0 0x0000003092ef63f3 in epoll_wait () from /lib64/libc.so.6
#1 0x00000000004406b4 in slapd_daemon_task (ptr=0x9c02d0) at daemon.c:2514
#2 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0
#3 0x0000003092ef5e1d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f53f8808700 (LWP 28214)):
#0 0x00000000004c121a in slap_sl_free (ptr=0x7f53e8000b40, ctx=0x7f53e80009d0)
at sl_malloc.c:513
#1 0x0000000000449520 in do_search (op=0x7f53e0103c60, rs=0x7f53f8807ad0) at
search.c:257
#2 0x00000000004451d4 in connection_operation (ctx=0x7f53f8807bb0,
arg_v=0x7f53e0103c60) at connection.c:1134
#3 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at
tpool.c:945
#4 0x0000003093607c53 in start_thread () from /lib64/libpthread.so.0
#5 0x0000003092ef5e1d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x00000000004c121a in slap_sl_free (ptr=0x7f53e8000b40, ctx=0x7f53e80009d0)
at sl_malloc.c:513
sh = 0x7f53e80009d0
size = 7286935691776455520
p = 0x7f53e8000b38
nextp = 0x6520e4bb49737e98
tmpp = 0x7f53f8807ad0
#1 0x0000000000449520 in do_search (op=0x7f53e0103c60, rs=0x7f53f8807ad0) at
search.c:257
base = {bv_len = 6, bv_val = 0x7f53e00009c7 "o=test"}
siz = 0
off = 0
i = 0
#2 0x00000000004451d4 in connection_operation (ctx=0x7f53f8807bb0,
arg_v=0x7f53e0103c60) at connection.c:1134
rc = 80
cancel = 0
op = 0x7f53e0103c60
rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 80,
sr_matched = 0x0, sr_text = 0x7f53f98d4fe6 "searchDN massage error", sr_ref =
0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0,
r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref
= 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata
= 0x0}}, sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f53f980c750
memctx = 0x7f53e80009d0
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#3 0x00007f5401b51993 in ldap_int_thread_pool_wrapper (xpool=0x937380) at
tpool.c:945
pq = 0x937380
pool = 0x937280
task = 0x7f53ec113d60
work_list = 0x9373f0
ctx = {ltu_pq = 0x937380, ltu_id = 139998628185856, ltu_key = {{ltk_key
= 0x444c86 <conn_counter_init>, ltk_data = 0x7f53e80008c0, ltk_free = 0x444a7d
<conn_counter_destroy>}, {ltk_key = 0x4c0182 <slap_sl_mem_init>,
ltk_data = 0x7f53e80009d0, ltk_free = 0x4bffa7
<slap_sl_mem_destroy>}, {ltk_key = 0x461f28 <slap_op_free>, ltk_data = 0x0,
ltk_free = 0x461e7b <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0x0} <repeats 29 times>}}
kctx = 0x0
i = 32
keyslot = 817
hash = 1596318513
pool_lock = 0
freeme = 0
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
I used the reproducer provided by Michael. The core was generated by the server
running with slapd1.conf.
--
Jan Synacek
Software Engineer, Red Hat
9 years, 11 months
Re: (ITS#7730) Error:passwd: Authentication token manipulation error
by quanah＠zimbra.com
--On Saturday, October 19, 2013 9:59 AM +0000 skadian1(a)gmail.com wrote:
> Full_Name: sumit kadian
> Version: 2.4.23
> OS: centos 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (122.176.201.133)
The ITS system is for bug reports, not usage questions. Send questions to
openldap-technical(a)openldap.org. This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
(ITS#7730) Error:passwd: Authentication token manipulation error
by skadian1＠gmail.com
Full_Name: sumit kadian
Version: 2.4.23
OS: centos 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (122.176.201.133)
Hi,
I have configured the openldap server with tls on Centos 6.4.
And also authenticated the client with authconfig-gtk.
Now I try to change the password of ldap user on the client machine, then it
giving following error:-
"passwd: Authentication token manipulation error "
here is the configuration file
==================================================================================
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
allow update_anon
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
#moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk
# at self-signed certificates, however.
#TLSCACertificatePath /etc/openldap/certs
#TLSCertificateFile "\"OpenLDAP Server\""
#TLSCertificateKeyFile /etc/openldap/certs/password
TLSCACertificatePath /etc/pki/tls/certs/
TLSCertificateFile /etc/pki/tls/certs/new.pem
TLSCertificateKeyFile /etc/pki/tls/certs/new.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to * by * read
# access to attrs=userPassword
# by self =xw
# access to * by * write
# access to * by anonymous none
# by self write
# by users read
# by anonymous auth
#
access to attrs=userPassword
by self write
by anonymous auth
by * none
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
# enable on-the-fly configuration (cn=config)
database config
access to *
by * read
by * write
# enable server status monitoring (cn=monitor)
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,dc=example,dc=com" read
by * write
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=example,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=example,dc=com"
#loglevel -1
#logfile /var/log/ldap.log
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw redhat
# rootpw {crypt}ijFYNcSNctBYg
#olcLogFile /var/log/slapd.log
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq
#index ou,cn,mail,surname,givenname eq,pres,sub
#index uidNumber,gidNumber,loginShell eq,pres
#index uid,memberUid eq,pres,sub
#index nisMapName,nisMapEntry eq,pres,sub
#index entryCSN,entryUUID eq
========================================
9 years, 11 months
Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms050104040805090407080805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
hyc(a)symas.com wrote:
> Yes, your test config shows that the problem is that rwm_conn_destroy f=
rees=20
> the session context while rwm_op_search is using it. Seems like the rwm=
=20
> overlay is not doing reference counting properly.
I had problems with a certain configuration of slapo-rwm where slapcat se=
g
faulted after writing all the LDIF data. Could this be related?
Never found the time to construct a simple config showing the issue thoug=
h.
Ciao, Michael.
--------------ms050104040805090407080805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE4MjIyOTE0WjAj
BgkqhkiG9w0BCQQxFgQUpusHNy0yKlNww0KbhZA5EJpix5kwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAshlSUWOl5MUBUKz+KUpiNpAdAxQObrGR
gVzeWE41HIVpNtzJ9Ay179lryM/geFL65OJlQuotw7qpwwCBQicr/ryYWwJzKbMMKRHROEkj
9J8vutxDnbK4ugSuW6FfoIbvSgV2+olagyKBtO6Cu+TFPUyXpyHS0FiPx6xyBFSMo/xkMZ03
DLd8UPAga+LrV/JRtMXShGsyNHifk7wl14lHxPi7OpZ53ny14PNhfRCC0vldD/2RX5hWWivU
0lkPd7QPGHZnsHZfsStnF7s6TdA578zumQTb23spRNrqS8OCWvxbr25K+srcQDgWM1Upe+K9
I1WTDt31Zw+km2DN1jTGvQAAAAAAAA==
--------------ms050104040805090407080805--
9 years, 11 months
Re: (ITS#7726) how to config kerberos with openldap via clear passwords?
by quanah＠zimbra.com
--On Friday, October 18, 2013 9:14 PM +0000 mostafa.basu(a)gmail.com wrote:
> Full_Name: Mostafa Moeini
> Version: 2.4.23
> OS: CentOS 5 X86
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (199.201.121.184)
>
>
> I want to use kerberos with openldap backend.
> but the problem is kerberos encrypt passwords before save into ldap
> database . how can I config kerberos to use clear mode for saving (and
> reading) passwords?
The ITS system is for reporting bugs. It is *not* for asking "how do I"
questions. Please use the appropriate resource (the
openldap-technical(a)openldap.org mailing list).
This ITS will be closed.
I would also strongly advise you to upgrade to a current openldap release.
2.4.23 is years old.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com
--On Tuesday, September 24, 2013 5:58 PM +0000 openldap(a)semyon.org wrote:
> On 13-09-23 10:16 PM, Howard Chu wrote:
>
>> If you backup the DB with slapcat and reload it on another server with
>> slapadd, can you still reproduce the fault on the copy?
>
> Unfortunately, yes. It breaks trying to retrieve the same record as
> before, on the same instruction in back_mdb:
>
> yesterday:
> [126393.233615] slapd[19244]: segfault at 7f499f38d000 ip
> 00007f4da0e9b6a1 sp 00007f499f1fa540 error 6 in
> back_mdb-2.4.so.2.9.2[7f4da0e80000+34000]
>
> today:
> [517860.953779] slapd[24871]: segfault at 7fdeb50a0000 ip
> 00007fe2b63ad6a1 sp 00007fdeb4f0d540 error 6 in
> back_mdb-2.4.so.2.9.2[7fe2b6392000+34000]
Please provide a useful bug report.
I.e., get a stack trace from gdb, as noted in:
<http://www.openldap.org/faq/data/cache/59.html>
Sample data/testcase/configs always welcome as well.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
