(ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by nick＠eurobjects.com
Full_Name: Nikolaos Milas
Version: 2.4.26 (LTB RPM)
OS: CentOS 5.7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.251.204.222)
We use the following schema (among others):
DN: cn={5}postfix,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {5}postfix
olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid'
DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines
the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC
'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A
flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC
'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $
mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) )
olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual
account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid
$ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) )
olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email
account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY (
mailacceptinggeneralid $ aliasInactive ) )
olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox
for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description )
We run:
# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
"cn=admin,cn=config" -f /root/work/schemachange1
where /root/work/schemachange1:
dn: cn={5}postfix,cn=schema,cn=config
changetype: modify
delete: olcAttributeTypes
olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid'
DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
add: olcAttributeTypes
olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC
'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This is successful:
[root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
"cn=admin,cn=config" -f /root/work/schemachange1
ldap_initialize( ldap://localhost )
Enter LDAP Password:
delete olcAttributeTypes:
{0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines
an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
add olcAttributeTypes:
{0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines
an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
modifying entry "cn={5}postfix,cn=schema,cn=config"
modify complete
However, then we try to run:
# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
"cn=admin,cn=config" -f /root/work/schemachange2
where /root/work/schemachange2:
dn: cn={5}postfix,cn=schema,cn=config
changetype: modify
delete: olcAttributeTypes
olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines
the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
add: olcAttributeTypes
olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the
address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
and this causes an OpenLDAP crash:
[root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
"cn=admin,cn=config" -f /root/work/schemachange2
ldap_initialize( ldap://localhost )
Enter LDAP Password:
delete olcAttributeTypes:
{1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address
mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
add olcAttributeTypes:
{1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address
mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
modifying entry "cn={5}postfix,cn=schema,cn=config"
This hangs, and we interrupt with Ctrl-C.
gdb reports:
-------------------------------------------
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x42e54940 (LWP 4089)]
0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366
366 *at = LDAP_STAILQ_NEXT(*at,sat_next);
(gdb) backtrace full
#0 0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366
__PRETTY_FUNCTION__ = "at_next"
#1 0x000000000042c816 in config_generic (c=0x42e51610) at bconfig.c:1667
i = 0
at = 0x0
prev = 0x0
i = <value optimized out>
__PRETTY_FUNCTION__ = "config_generic"
#2 0x00000000004317eb in config_set_vals (Conf=0x81e1e0, c=0x42e51610) at
config.c:334
rc = <value optimized out>
arg_type = 0
ptr = <value optimized out>
#3 0x00000000004355fd in config_parse_add (ct=0x81e1e0, c=0x42e51610,
valx=<value optimized out>) at config.c:678
rc = <value optimized out>
#4 0x0000000000427fe9 in config_modify_add (ct=0x81e1e0, ca=0x42e51610,
ad=<value optimized out>, i=1) at bconfig.c:5420
rc = <value optimized out>
#5 0x000000000042a486 in config_modify_internal (op=0x13086920, rs=0x42e53c20)
at bconfig.c:5689
a = <value optimized out>
colst = 0x131f7f80
dels = <value optimized out>
ml = <value optimized out>
e = 0x12955548
rc = <value optimized out>
oc_at = <value optimized out>
s = 0x12d56d48
ct = 0x81e1e0
i = 2
nocs = 2
#6 config_back_modify (op=0x13086920, rs=0x42e53c20) at bconfig.c:5802
cfb = 0x82a640
ce = <value optimized out>
last = <value optimized out>
ml = <value optimized out>
ca = {argc = 19, argv = 0x131f5120, argv_size = 513,
line = 0x132030b3 "( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC
'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )", tline =
0x13203ce0 "(", fname = 0x587799 "slapd", lineno = 0,
log = "olcAttributeTypes: value #1", '\000' <repeats 4096 times>,
reply = {err = 0,
msg = "\000lcAttributeTypes: Duplicate attributeType:
\"1.3.6.1.4.1.25260.1.0\"", '\000' <repeats 188 times>}, depth = 0, valx = 1,
values = {
v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ber_t = 0,
v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0,
bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad =
0x0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 25,
ca_op = 0x13086920, be = 0x82c1a0, bi = 0x0, ca_entry = 0x12955548,
ca_private = 0x129aeaf0, cleanup = 0, table = Cft_Schema}
---Type <return> to continue, or q <return> to quit---
rdn = {bv_len = 2, bv_val = 0x129dac10
"cn={5}postfix,cn=schema,cn=config"}
rad = 0x12903de0
do_pause = 1
#7 0x0000000000452a07 in fe_op_modify (op=0x13086920, rs=0x42e53c20) at
modify.c:303
repl_user = <value optimized out>
bd = 0x82c1a0
textbuf = "@\270\220\022", '\000' <repeats 12 times>,
"@\270\220\022\000\000\000\000\316YE\000\000\000\000\000\260\u01dd\022\000\000\000\000\260[\217\022\000\000\000\000\002\000\000\000\000\000\000\000\262\u01dd\022\000\000\000\000\001\000\000\000\000\000\000\000\261\u01dd\022\000\000\000\000\003\000\000\000\000\000\000\000\260\u01dd\022\000\000\000\000\260\000\000\000\000\000\000\000\060~\037\023",
'\000' <repeats 20 times>, " u\037\023", '\000' <repeats 12 times>"\360,
\271\220\022\000\000\000\000 ", '\000' <repeats 15 times>,
"\023$E\000\000\000\000\000\300\312\005\023\000\000\000\000\000\001\000\000\000\000\000\000\320:\345B\000\000\000\000@<\345B\000\000\000\000
i\b\023\000\000\000\000\001\000\000\000\000\000\000\000Xi\b\023\000\000\000\000Hi\b\023\000\000\000\000\300\312\005\023\000\000\000\000\311"...
#8 0x0000000000453172 in do_modify (op=0x13086920, rs=0x42e53c20) at
modify.c:177
dn = {bv_len = 33, bv_val = 0x13202669
"cn={5}postfix,cn=schema,cn=config"}
textbuf = "\327k\b\023", '\000' <repeats 52 times>"\273,
(\207?9\000\000\000\000\000\037\023", '\000' <repeats 16 times>,
"\001\000\000\000\260\200\037\023", '\000' <repeats 12 times>"\211, \331\000@9",
'\000' <repeats 11 times>"\365,
\377\377\377\377\377\377\377oy\037\023\000\000\000\000\b\000\000\000\000\000\000\000H:\265?9\000\000\000\251oW",
'\000' <repeats 13 times>"\361,
\001\000\000\000\000\000\000\333\001\000\000\000\000\000\000@\000\000\000\000\000\000\000H:\265?9\000\000\000\020<\345B",
'\000' <repeats 12 times>,
"!\000\000\000\000\000\000\000\023\000\000\000\000\000\000\000v\277H\000\000\000\000\000\020o\030\023\000\000\000\000\200g\270\022\000\000\000"
tmp = 0x0
#9 0x000000000043b965 in connection_operation (ctx=0x42e53d70, arg_v=<value
optimized out>) at connection.c:1138
rc = <value optimized out>
cancel = <value optimized out>
op = 0x13086920
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0,
sr_matched = 0x0, sr_text = 0x0, 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 = 102
opidx = SLAP_OP_MODIFY
conn = 0x12b86780
memctx = 0x1305cac0
memctx_null = 0x0
__PRETTY_FUNCTION__ = "connection_operation"
#10 0x000000000043bf3f in connection_read_thread (ctx=0x42e53d70, argv=<value
optimized out>) at connection.c:1274
s = 31
#11 0x000000000054d68c in ldap_int_thread_pool_wrapper (xpool=0x12907380) at
tpool.c:685
task = 0x12e1b240
work_list = <value optimized out>
ctx = {ltu_id = 1122322752, ltu_key = {{ltk_key = 0x43a8d0, ltk_data =
0x1305c9b0, ltk_free = 0x43a9a0 <conn_counter_destroy>}, {ltk_key = 0x48c440,
ltk_data = 0x1305cac0, ltk_free = 0x48c320 <slap_sl_mem_destroy>},
{ltk_key = 0x12b25e30, ltk_data = 0x1305cce0,
ltk_free = 0x4e0010 <bdb_reader_free>}, {ltk_key = 0x44e220,
ltk_data = 0x0, ltk_free = 0x44e000 <slap_op_q_destroy>}, {ltk_key = 0x0,
---Type <return> to continue, or q <return> to quit---
ltk_data = 0x131f5120, ltk_free = 0}, {ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0} <repeats 27 times>}}
kctx = <value optimized out>
keyslot = 976
hash = <value optimized out>
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#12 0x000000394000673d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#13 0x000000393f8d44bd in clone () from /lib64/libc.so.6
No symbol table info available.
-------------------------------------------
11 years, 9 months
Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by quanah＠zimbra.com
--On Tuesday, November 29, 2011 12:35 AM +0000 paul(a)scom.ca wrote:
> this issue googles alot without any clear explanation.
Read your config.log file that is generated to see why it doesn't like the
sql.h file.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 9 months
(ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by paul＠scom.ca
Full_Name: Paul Kudla
Version: 2.4.23 & 2.4.28
OS: Freebsd 8.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (69.171.154.78)
Simply put openldap will not configure
How do i get it to find the sql.h file
checking number of arguments of ctime_r... 2
checking number of arguments of gethostbyname_r... 6
checking number of arguments of gethostbyaddr_r... 8
checking for openlog... yes
checking sql.h usability... no
checking sql.h presence... no
checking for sql.h... no
configure: error: could not locate SQL headers
installed UnixODBC version unixODBC-2.3.1
[00:28:54] root@ldap /usr/local/src/openldap-2.4.23
# ll /usr/local/include/sql.h
-rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h
[00:34:18] root@ldap /usr/local/src/openldap-2.4.23
#
this issue googles alot without any clear explanation.
have no problem contributing to the cause - let me know how.
11 years, 9 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com
--On Friday, November 25, 2011 10:15 AM +0000 michael(a)stroeder.com wrote:
> hyc(a)symas.com wrote:
>> michael(a)stroeder.com wrote:
>>> hyc(a)symas.com wrote:
>>>>> You don't have to teach me anything in the testing field.
>>>>
>>>> Clearly I *do* need to, based on the completely useless content-free
>>>> emails you've posted so far.
>>>
>>> Maybe then you should learn to read. The cause was already mentioned in
>>> a message before. I did not expect that you are not able to generate
>>> test data not in tree order yourself.
>>
>> You're assuming I've been sitting on my ass waiting for your followups.
>
> Well, and you assume that I have endless spare times tracking down bugs. I
> don't. Especially at the current moment.
Hi Michael,
No one assumed any such thing. All that was every requested from you was
information that only you had. The information on how exactly to reproduce
this issue that you found, because no one else was able to reproduce with
the information you had provided. Now that you finally provided the
requisite information, someone *else* was able to track down and fix the
actual bug.
It is very unfortunate that you find requests for information to be so
tedious. Having to continually request basic information from you is also
quite tedious. If you could just provide the requisite information up
front, then entire situations like this could be entirely avoided.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
hyc(a)symas.com wrote:
> michael(a)stroeder.com wrote:
>> hyc(a)symas.com wrote:
>>>> You don't have to teach me anything in the testing field.
>>>
>>> Clearly I *do* need to, based on the completely useless content-free emails
>>> you've posted so far.
>>
>> Maybe then you should learn to read. The cause was already mentioned in a
>> message before. I did not expect that you are not able to generate test data
>> not in tree order yourself.
>
> You're assuming I've been sitting on my ass waiting for your followups.
Well, and you assume that I have endless spare times tracking down bugs. I
don't. Especially at the current moment.
Ciao, Michael.
11 years, 10 months
Re: (ITS#7096) Make depend error on redhat 6 with OpenLDAP 2.3.43
by h.b.furuseth＠usit.uio.no
llx88217(a)126.com writes:
> Version: OpenLDAP 2.3.43
> In file included from slurp.h:53,
> from ri.c:45:
> ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before
> token "("
OpenLDAP 2.3 is not under development, please check bugs against the
latest release before reporting. This one is ITS#5824, fixed in by
commit debfd2d796fd47481e077dff97fb38b21b030af7 in the Git repository.
--
Hallvard
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com
michael(a)stroeder.com wrote:
> hyc(a)symas.com wrote:
>>> You don't have to teach me anything in the testing field.
>>
>> Clearly I *do* need to, based on the completely useless content-free emails
>> you've posted so far.
>
> Maybe then you should learn to read. The cause was already mentioned in a
> message before. I did not expect that you are not able to generate test data
> not in tree order yourself.
You're assuming I've been sitting on my ass waiting for your followups. I fed
a number of unordered LDIFs into slapadd and the problem never surfaced.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
hyc(a)symas.com wrote:
>> You don't have to teach me anything in the testing field.
>
> Clearly I *do* need to, based on the completely useless content-free emails
> you've posted so far.
Maybe then you should learn to read. The cause was already mentioned in a
message before. I did not expect that you are not able to generate test data
not in tree order yourself.
Ciao, Michael.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by masarati＠aero.polimi.it
On 11/25/2011 09:31 AM, hyc(a)symas.com wrote:
> this and the typos in back-sql
On a related note, I merely found those typos by building back-sql
statically, as it wouldn't allow slapd to start. I haven't tested its
functionality yet. Sorry for this, too busy.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> One crucial step in isolating the problem would be to determine if the error
>> actually occurs during slapadd or slapcat.
>
> I revise my statement that data looks ok via LDAP. Messing up the data seems
> to happen during slapadd if the LDIF is not in tree order (as already
> suspected in a former posting which was not read I guess).
>
> Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is
> in tree order while in data1.ldif subordinate entries come before their
> superior entries (which is what slapcat sometimes produce).
Interestingly enough, my results differed from yours. Also the results
differed depending on whether I slapadd'd the bare LDIF, or an LDIF with all
operational attributes included. But this is now fixed in git master. Given
this and the typos in back-sql it appears we should scratch 2.4.27 and push a
new release.
> These entries
>
> dn: ou=Groups,ou=schulung,dc=stroeder,dc=local
> objectClass: organizationalUnit
> ou: Groups
>
> dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local
> cn: slapd-1
> objectClass: applicationProcess
> objectClass: simpleSecurityObject
> userPassword: pw_slapd1
>
> get mixed into that:
>
> dn: ou=Groups,ou=schulung,dc=stroeder,dc=local
> cn: slapd-1
> hasSubordinates: TRUE
> objectClass: applicationProcess
> objectClass: simpleSecurityObject
> userPassword: pw_slapd1
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 10 months
