Hello,
In my config there is:
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 )
When I try to change attribute OID value, for example: 1.3.6.1.4.1.25260.1.000 to 1.3.6.1.4.1.25260.1.0 (using a visual LDAP client) then the server hangs and will not restart. (I had to restore from backup and restart.)
What is the recommended way to do this change?
Thanks, Nick
--On Monday, November 28, 2011 7:09 PM +0200 Nick Milas nick@eurobjects.com wrote:
When I try to change attribute OID value, for example: 1.3.6.1.4.1.25260.1.000 to 1.3.6.1.4.1.25260.1.0 (using a visual LDAP client) then the server hangs and will not restart. (I had to restore from backup and restart.)
What is the recommended way to do this change?
If you are using the latest OpenLDAP, I would suggest you get a backtrace of the hung process and file an ITS. I would note that changing an OID on an existing schema is a bit of an odd thing to do.
--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
On 28/11/2011 9:04 μμ, Quanah Gibson-Mount wrote:
If you are using the latest OpenLDAP, I would suggest you get a backtrace of the hung process and file an ITS. I would note that changing an OID on an existing schema is a bit of an odd thing to do.
I am using 2.4.26. I'll try to do a core dump and file an ITS per your instructions. Or this would be acceptable only with the latest version (.28) ?
I did this change as part of a test, because - surprisingly - Apache Directory Studio did not work properly with OID values like xxx.000, xxx.001 etc.
You may want to see: https://issues.apache.org/jira/browse/DIRSTUDIO-748
Nick
--On Monday, November 28, 2011 9:18 PM +0200 Nick Milas nick@eurobjects.com wrote:
On 28/11/2011 9:04 μμ, Quanah Gibson-Mount wrote:
If you are using the latest OpenLDAP, I would suggest you get a backtrace of the hung process and file an ITS. I would note that changing an OID on an existing schema is a bit of an odd thing to do.
I am using 2.4.26. I'll try to do a core dump and file an ITS per your instructions. Or this would be acceptable only with the latest version (.28) ?
2.4.26 is probably fine. You shouldn't need to take a core dump, just a full backtrace of the hung process.
I.e., gdb /path/to/slapd pid
--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
On 28/11/2011 9:24 μμ, Quanah Gibson-Mount wrote:
2.4.26 is probably fine. You shouldn't need to take a core dump, just a full backtrace of the hung process.
I.e., gdb /path/to/slapd pid
OK, I hope I've done it right (I'm inexperienced with gdb).
Please check whether sufficient information has been logged, so I can file a meaningful ITS.
If additional info would be required, please provide details.
The debugging session follows.
Nick
First I successfully changed OID value xxxxx.000 to 0. No error.
Then I tried to change OID value xxxxx.001 to 1 and program stalled.
Here is the gdb output. First is a backtrace before the error occurs:
============================= Initialization =============================
[root@ldap ~]# gdb /usr/local/openldap/libexec/slapd 2295 GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/openldap/libexec/slapd...Reading symbols from /usr/lib/debug/usr/local/openldap/libexec/slapd.debug...done. done. Attaching to program: /usr/local/openldap/libexec/slapd, process 2295 Reading symbols from /lib64/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/local/berkeleydb/lib64/libdb-4.6.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/berkeleydb/lib64/libdb-4.6.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x43d36940 (LWP 3136)] [New Thread 0x43535940 (LWP 3123)] [New Thread 0x42d34940 (LWP 2656)] [New Thread 0x42533940 (LWP 2655)] [New Thread 0x41d32940 (LWP 2297)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libltdl.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffb1ffd000 0x0000003940007b35 in pthread_join () from /lib64/libpthread.so.0
========================================================= A backtrace after changing 000 to 0 =========================================================
(gdb) backtrace full #0 0x0000003940007b35 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000043613d in slapd_daemon () at daemon.c:2922 i = -4 rc = <value optimized out> listener_tid = 0xd1343b0 #2 0x00000000004234bb in main (argc=<value optimized out>, argv=0x7fffb1f79508) at main.c:983 i = 216361728 no_detach = 0 rc = 0 urls = <value optimized out> username = 0xcbe7460 "localhost" groupname = 0xcbe73b0 "`\232\276\f" sandbox = 0x0 syslogUser = 160 configfile = <value optimized out> configdir = <value optimized out> serverName = 0x9 <Address 0x9 out of bounds> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"
=============================================================== I submit a change of OID xxxxx.001 to 1 and an error occurs ===============================================================
(gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42533940 (LWP 2655)] 0x000000000047ab0c in at_next (at=0x42530498) at at.c:366 366 *at = LDAP_STAILQ_NEXT(*at,sat_next); (gdb) backtrace full #0 0x000000000047ab0c in at_next (at=0x42530498) at at.c:366 __PRETTY_FUNCTION__ = "at_next" #1 0x000000000042c816 in config_generic (c=0x42530690) 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=0x42530690) at config.c:334 rc = <value optimized out> arg_type = 0 ptr = <value optimized out> #3 0x00000000004355fd in config_parse_add (ct=0x81e1e0, c=0x42530690, valx=<value optimized out>) at config.c:678 rc = <value optimized out> #4 0x0000000000427fe9 in config_modify_add (ct=0x81e1e0, ca=0x42530690, ad=<value optimized out>, i=1) at bconfig.c:5420 rc = <value optimized out> #5 0x000000000042a486 in config_modify_internal (op=0xd141780, rs=0x42532ca0) at bconfig.c:5689 a = <value optimized out> colst = 0xd141580 dels = <value optimized out> ml = <value optimized out> e = 0xcc66548 rc = <value optimized out> oc_at = <value optimized out> s = 0xd05edb0 ct = 0x81e1e0 i = 2 nocs = 2 #6 config_back_modify (op=0xd141780, rs=0x42532ca0) at bconfig.c:5802 cfb = 0x82a640 ce = <value optimized out> last = <value optimized out> ml = <value optimized out> ca = {argc = 19, argv = 0xd378f20, argv_size = 513, line = 0xd370103 "( 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 = 0xd35ebc0 "(", 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 = 0xd141780, be = 0x82c1a0, bi = 0x0, ca_entry = 0xcc66548, ca_private = 0xccbfaf0, cleanup = 0, table = Cft_Schema} ---Type <return> to continue, or q <return> to quit--- rdn = {bv_len = 2, bv_val = 0xccebc10 "cn={5}postfix,cn=schema,cn=config"} rad = 0xcc14de0 do_pause = 1 #7 0x0000000000452a07 in fe_op_modify (op=0xd141780, rs=0x42532ca0) at modify.c:303 repl_user = <value optimized out> bd = 0x82c1a0 textbuf = "@\310\301\f", '\000' <repeats 12 times>, "@\310\301\f\000\000\000\000\316YE\000\000\000\000\000\020\005\024\r\000\000\000\000\260k\300\f\000\000\000\000\002\000\000\000\000\000\000\000\022\005\024\r\000\000\000\000\001\000\000\000\000\000\000\000\021\005\024\r\000\000\000\000\003\000\000\000\000\000\000\000\020\005\024\r\000\000\000\000\260\000\000\000\000\000\000\000P\352\065\r", '\000' <repeats 20 times>, "\020E7\r", '\000' <repeats 12 times>"\360, \311\301\f\000\000\000\000 ", '\000' <repeats 15 times>, "\023$E\000\000\000\000\000\300\034\024\r\000\000\000\000\000\001\000\000\000\000\000\000P+SB\000\000\000\000\300,SB\000\000\000\000\200\027\024\r\000\000\000\000\001\000\000\000\000\000\000\000\270\027\024\r\000\000\000\000\250\027\024\r"... #8 0x0000000000453172 in do_modify (op=0xd141780, rs=0x42532ca0) at modify.c:177 dn = {bv_len = 33, bv_val = 0xd3621b9 "cn={5}postfix,cn=schema,cn=config"} textbuf = "\357\064\066\r\000\000\000\000@\035$\r\000\000\000\000\b\000\000\000\000\000\000\000\251oW\000\000\000\000\000H:\265?9\000\000\000\360+SB\000\000\000\000\370\001\000\000\000\000\000\000!\000\000\000\000\000\000\000\023", '\000' <repeats 15 times>, "0\033\067\r\000\000\000\000\200K\351\f\000\000\000\000\060\033\067\r\000\000\000\000\020-SB\000\000\000\000P\000\000\000\000\000\000\000\343\u0544?9\000\000\000(\000\000\000\060\000\000\000\260,SB\000\000\000\000\360+SB\000\000\000\000\343\u0544?\004\000\000\000(\000\000\000\060\000\000\000\320,SB\000\000\000\000\020,SB\000\000\000\000\357\064\066\r\000\000\000\000\300$\023\r\000\000\000\000\357\064\066\r\000\000\000\000\b\000\000\000\000\000\000\000\240\070SB\000\000\000\000\300"... tmp = 0x0 #9 0x000000000043b965 in connection_operation (ctx=0x42532d70, arg_v=<value optimized out>) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> op = 0xd141780 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 = 0xce94b80 memctx = 0xd141cc0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000054d68c in ldap_int_thread_pool_wrapper (xpool=0xcc18380) at tpool.c:685 task = 0xd13faa0 work_list = <value optimized out> ctx = {ltu_id = 1112750400, ltu_key = {{ltk_key = 0x43a8d0, ltk_data = 0xd141bb0, ltk_free = 0x43a9a0 <conn_counter_destroy>}, {ltk_key = 0x48c440, ltk_data = 0xd141cc0, ltk_free = 0x48c320 <slap_sl_mem_destroy>}, {ltk_key = 0x44e220, ltk_data = 0x0, ltk_free = 0x44e000 <slap_op_q_destroy>}, {ltk_key = 0xce36e30, ltk_data = 0xd241d70, ltk_free = 0x4e0010 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <value optimized out> keyslot = 174 ---Type <return> to continue, or q <return> to quit--- hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x000000394000673d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x000000393f8d44bd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) quit A debugging session is active.
Inferior 1 [process 2295] will be detached.
Quit anyway? (y or n) y Detaching from program: /usr/local/openldap/libexec/slapd, process 2295
--On Tuesday, November 29, 2011 12:33 AM +0200 Nick Milas nick@eurobjects.com wrote:
Here is the gdb output. First is a backtrace before the error occurs:
Just to note, a backtrace from before an error occurs is almost never useful. ;)
=============================================================== I submit a change of OID xxxxx.001 to 1 and an error occurs ===============================================================
This backtrace is useful. It shows clearly that slapd died (SEGV) in the file at.c at line 366. I would suggest you file an ITS with this backtrace and the steps on how to reproduce it (the ldapmodify of the OIDs).
--Quanah
(gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42533940 (LWP 2655)] 0x000000000047ab0c in at_next (at=0x42530498) at at.c:366 366 *at = LDAP_STAILQ_NEXT(*at,sat_next); (gdb) backtrace full # 0 0x000000000047ab0c in at_next (at=0x42530498) at at.c:366 __PRETTY_FUNCTION__ = "at_next" # 1 0x000000000042c816 in config_generic (c=0x42530690) 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=0x42530690) # at config.c:334 rc = <value optimized out> arg_type = 0 ptr = <value optimized out> # 3 0x00000000004355fd in config_parse_add (ct=0x81e1e0, c=0x42530690, # valx=<value optimized out>) at config.c:678 rc = <value optimized out> # 4 0x0000000000427fe9 in config_modify_add (ct=0x81e1e0, ca=0x42530690, # ad=<value optimized out>, i=1) at bconfig.c:5420 rc = <value optimized out> # 5 0x000000000042a486 in config_modify_internal (op=0xd141780, # rs=0x42532ca0) at bconfig.c:5689 a = <value optimized out> colst = 0xd141580 dels = <value optimized out> ml = <value optimized out> e = 0xcc66548 rc = <value optimized out> oc_at = <value optimized out> s = 0xd05edb0 ct = 0x81e1e0 i = 2 nocs = 2 # 6 config_back_modify (op=0xd141780, rs=0x42532ca0) at bconfig.c:5802 cfb = 0x82a640 ce = <value optimized out> last = <value optimized out> ml = <value optimized out> ca = {argc = 19, argv = 0xd378f20, argv_size = 513, line = 0xd370103 "( 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 = 0xd35ebc0 "(", 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 = 0xd141780, be = 0x82c1a0, bi = 0x0, ca_entry = 0xcc66548, ca_private = 0xccbfaf0, cleanup = 0, table = Cft_Schema} ---Type <return> to continue, or q <return> to quit--- rdn = {bv_len = 2, bv_val = 0xccebc10 "cn={5}postfix,cn=schema,cn=config"} rad = 0xcc14de0 do_pause = 1 # 7 0x0000000000452a07 in fe_op_modify (op=0xd141780, rs=0x42532ca0) at # modify.c:303 repl_user = <value optimized out> bd = 0x82c1a0 textbuf = "@\310\301\f", '\000' <repeats 12 times>, "@\310\301\f\000\000\000\000\316YE\000\000\000\000\000\020\005\024\r\000\ 000\000\000\260k\300\f\000\000\000\000\002\000\000\000\000\000\000\000\02 2\005\024\r\000\000\000\000\001\000\000\000\000\000\000\000\021\005\024\r \000\000\000\000\003\000\000\000\000\000\000\000\020\005\024\r\000\000\00 0\000\260\000\000\000\000\000\000\000P\352\065\r", '\000' <repeats 20 times>, "\020E7\r", '\000' <repeats 12 times>"\360, \311\301\f\000\000\000\000 ", '\000' <repeats 15 times>, "\023$E\000\000\000\000\000\300\034\024\r\000\000\000\000\000\001\000\000 \000\000\000\000P+SB\000\000\000\000\300,SB\000\000\000\000\200\027\024\r \000\000\000\000\001\000\000\000\000\000\000\000\270\027\024\r\000\000\00 0\000\250\027\024\r"... # 8 0x0000000000453172 in do_modify (op=0xd141780, rs=0x42532ca0) at # modify.c:177 dn = {bv_len = 33, bv_val = 0xd3621b9 "cn={5}postfix,cn=schema,cn=config"} textbuf = "\357\064\066\r\000\000\000\000@\035$\r\000\000\000\000\b\000\000\000\000 \000\000\000\251oW\000\000\000\000\000H:\265?9\000\000\000\360+SB\000\000 \000\000\370\001\000\000\000\000\000\000!\000\000\000\000\000\000\000\023 ", '\000' <repeats 15 times>, "0\033\067\r\000\000\000\000\200K\351\f\000\000\000\000\060\033\067\r\000 \000\000\000\020-SB\000\000\000\000P\000\000\000\000\000\000\000\343\u054 4?9\000\000\000(\000\000\000\060\000\000\000\260,SB\000\000\000\000\360+S B\000\000\000\000\343\u0544?\004\000\000\000(\000\000\000\060\000\000\000 \320,SB\000\000\000\000\020,SB\000\000\000\000\357\064\066\r\000\000\000\ 000\300$\023\r\000\000\000\000\357\064\066\r\000\000\000\000\b\000\000\00 0\000\000\000\000\240\070SB\000\000\000\000\300"... tmp = 0x0 # 9 0x000000000043b965 in connection_operation (ctx=0x42532d70, # arg_v=<value optimized out>) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> op = 0xd141780 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 = 0xce94b80 memctx = 0xd141cc0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" # 10 0x000000000054d68c in ldap_int_thread_pool_wrapper (xpool=0xcc18380) # at tpool.c:685 task = 0xd13faa0 work_list = <value optimized out> ctx = {ltu_id = 1112750400, ltu_key = {{ltk_key = 0x43a8d0, ltk_data = 0xd141bb0, ltk_free = 0x43a9a0 <conn_counter_destroy>}, {ltk_key = 0x48c440, ltk_data = 0xd141cc0, ltk_free = 0x48c320 <slap_sl_mem_destroy>}, {ltk_key = 0x44e220, ltk_data = 0x0, ltk_free = 0x44e000 <slap_op_q_destroy>}, {ltk_key = 0xce36e30, ltk_data = 0xd241d70, ltk_free = 0x4e0010 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <value optimized out> keyslot = 174 ---Type <return> to continue, or q <return> to quit--- hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" # 11 0x000000394000673d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. # 12 0x000000393f8d44bd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) quit A debugging session is active.
Inferior 1 [process 2295] will be detached.Quit anyway? (y or n) y Detaching from program: /usr/local/openldap/libexec/slapd, process 2295
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 29/11/2011 12:44 πμ, Quanah Gibson-Mount wrote:
I would suggest you file an ITS with this backtrace and the steps on how to reproduce it (the ldapmodify of the OIDs).
I have filed ITS #7098 (http://www.openldap.org/its/index.cgi/Incoming?id=7098).
Nick
On 29/11/2011 12:33 πμ, Nick Milas wrote:
Please check whether sufficient information has been logged, so I can file a meaningful ITS.
Also, until a bug fix is made and a release which includes the fix is published, is there a way we can change the OID values?
It would not be easy for me to compile from source code (which would include a fix), unless clear and detailed directions are given.
Nick
--On Tuesday, November 29, 2011 12:48 AM +0200 Nick Milas nick@eurobjects.com wrote:
On 29/11/2011 12:33 πμ, Nick Milas wrote:
Please check whether sufficient information has been logged, so I can file a meaningful ITS.
Also, until a bug fix is made and a release which includes the fix is published, is there a way we can change the OID values?
It would not be easy for me to compile from source code (which would include a fix), unless clear and detailed directions are given.
You can slapcat the config database, change the OIDs in the output, and slapadd it while the server is offline.
--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
On 28/11/2011 7:09 μμ, Nick Milas wrote:
In my config there is:
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 )
Hi,
Following the fix of ITS 7098, now (after upgrading to a version with the fix) I changed successfully the values of OIDs 1.3.6.1.4.1.25260.1.00x to 1.3.6.1.4.1.25260.1.x. (No service stop followed.)
Yet, after these changes, we could not modify the associated attributes any more. We got errors of the form:
Feb 14 20:59:23 ldap slapd[1061]: Entry (cn=userx_alias,ou=Aliases,dc=example,dc=com): object class 'maillist' requires attribute 'mailacceptinggeneralid' Feb 14 20:59:23 ldap slapd[1061]: entry failed schema check: object class 'maillist' requires attribute 'mailacceptinggeneralid'
I tried reindexing the directory and this solved the problem.
Is this expected behavior?
Thanks, Nick
On 14/2/2012 11:21 μμ, Nick Milas wrote:
Following the fix of ITS 7098, now (after upgrading to a version with the fix) I changed successfully the values of OIDs 1.3.6.1.4.1.25260.1.00x to 1.3.6.1.4.1.25260.1.x. (No service stop followed.)
Yet, after these changes, we could not modify the associated attributes any more. ... I tried reindexing the directory and this solved the problem.
Is this expected behavior?
Sorry, may I ask again if it is the expected behavior to have to reindex the directory after OID changes?
Thanks, Nick
Nick Milas wrote:
On 14/2/2012 11:21 μμ, Nick Milas wrote:
Following the fix of ITS 7098, now (after upgrading to a version with the fix) I changed successfully the values of OIDs 1.3.6.1.4.1.25260.1.00x to 1.3.6.1.4.1.25260.1.x. (No service stop followed.)
Yet, after these changes, we could not modify the associated attributes any more. ... I tried reindexing the directory and this solved the problem.
Is this expected behavior?
Sorry, may I ask again if it is the expected behavior to have to reindex the directory after OID changes?
Yes, the OID is included in the index computation.
On 17/2/2012 10:07 πμ, Howard Chu wrote:
Yes, the OID is included in the index computation.
Thank you.
Could/Should the software automatically reindex the directory after OID change or - if not possible - inform the administrator with a message that such reindexing should be done manually?
Thanks again, Nick
Nick Milas wrote:
On 17/2/2012 10:07 πμ, Howard Chu wrote:
Yes, the OID is included in the index computation.
Thank you.
Could/Should the software automatically reindex the directory after OID change or - if not possible - inform the administrator with a message that such reindexing should be done manually?
No. It is our policy to expect sysadmins to know what they're doing. Admins should know that OIDs are meant to be constants; you should have very good reasons for changing them, otherwise you should never change them.
Howard Chu wrote:
Admins should know that OIDs are meant to be constants; you should have very good reasons for changing them, otherwise you should never change them.
Another reason why the current experimental .666 OID policy is non-sense and should be revisited...
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount