openldap-bugs September 2008

openldap-bugs@openldap.org

39 participants
206 discussions

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

Michael Ströder wrote: > Pierangelo Masarati wrote: >> I have a patch >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> >> that implements support for "ldapsyntax" (slapd.conf) and >> "olcLdapSyntaxes" (back-config) in order to allow run-time configuration >> of syntaxes that have NULL handlers and thus need to have the X-SUBST >> extension in place. > > You rock! I'll give it a try. > >> ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' >> DESC 'this is the description' >> X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) > > Looking at RFC 4512 the SyntaxDescription does not mention NAME > (although I'd appreciate it would). Correct. I was mistaken by the presence of the field in the schema stucture of include/ldap_schema.h: typedef struct ldap_syntax { char *syn_oid; /* REQUIRED */ char **syn_names; /* OPTIONAL */ char *syn_desc; /* OPTIONAL */ LDAPSchemaExtensionItem **syn_extensions; /* OPTIONAL */ } LDAPSyntax; We should probably trim it, although it could (would) break binary interoperability at the libldap level. I'd note rfc4517 does not mention extensions, either... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by michael＠stroeder.com 16 Sep '08

16 Sep '08

Pierangelo Masarati wrote: > > I have a patch > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> > that implements support for "ldapsyntax" (slapd.conf) and > "olcLdapSyntaxes" (back-config) in order to allow run-time configuration > of syntaxes that have NULL handlers and thus need to have the X-SUBST > extension in place. You rock! I'll give it a try. > ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' > DESC 'this is the description' > X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) Looking at RFC 4512 the SyntaxDescription does not mention NAME (although I'd appreciate it would). Ciao, Michael.

1 0

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 16 Sep '08

16 Sep '08

On Tue, 16 Sep 2008, Howard Chu wrote: > What is the value of c_conn_state in each of these occurrences? In case 1 and 2, connections[*index].c_conn_state = 2 (SLAP_C_ACTIVE). In case 3, connections[*index].c_conn_state = 1 (SLAP_C_INACTIVE).

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 16 Sep '08

16 Sep '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Rare connection.c assertion during test008s of RE24. Here are three different > examples: > > t@6 (l@6) terminated by signal ABRT (Abort) > 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xffffffff7f0a8d5c > Current function is connection_next > 871 assert( connections[*index].c_conn_state == > SLAP_C_INVALID ); What is the value of c_conn_state in each of these occurrences? > I have the testrun directories from each of these runs, if desired. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 15 Sep '08

15 Sep '08

Michael, I have a patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> that implements support for "ldapsyntax" (slapd.conf) and "olcLdapSyntaxes" (back-config) in order to allow run-time configuration of syntaxes that have NULL handlers and thus need to have the X-SUBST extension in place. The patch is very intrusive, that's why I didn't commit it right now, as I'd like someone to give it a look first. It applies to HEAD as of right now. Please test and report. My current test configuration is something like ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' DESC 'this is the description' X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) followed by attributeType ( <my-at-oid> NAME 'MyAttr' SYNTAX <my-syntax-oid> ) It seems to work just fine, although I didn't check many features like deletion of schema via back-config and so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 15 Sep '08

15 Sep '08

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Rare connection.c assertion during test008s of RE24. Here are three different examples: t@6 (l@6) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@6 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff76bfeb30, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x100427478, 0x100427480), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff76bfefec), line 871 in "connection.c" [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" [7] monitor_entry_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 90 in "entry.c" [8] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c03d8, sub = 1), line 53 in "search.c" [9] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 245 in "search.c" [11] fe_op_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 366 in "search.c" [12] do_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff76bffc20, arg_v = 0x103a359b0), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff76bffc20, argv = 0xe), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@18 (l@18) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff6dbfeb20, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x16, 0x1006b9cd8, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff6dbff02c), line 871 in "connection.c" [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 187 in "rww.c" [7] monitor_entry_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 59 in "entry.c" [8] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [9] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 245 in "search.c" [11] fe_op_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 366 in "search.c" [12] do_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff6dbffc20, arg_v = 0x102c3dd70), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff6dbffc20, argv = 0x1e), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@3 (l@3) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@3 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff78ffea50, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x0, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff78fff02c), line 871 in "connection.c" [6] connection_first(index = 0xffffffff78fff02c), line 829 in "connection.c" [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 185 in "rww.c" [8] monitor_entry_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 59 in "entry.c" [9] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [10] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [11] monitor_back_search(op = 0x100922640, rs = 0xffffffff78fff998), line 245 in "search.c" [12] fe_op_search(op = 0x100922640, rs = 0xffffffff78fff998), line 366 in "search.c" [13] do_search(op = 0x100922640, rs = 0xffffffff78fff998), line 217 in "search.c" [14] connection_operation(ctx = 0xffffffff78fffc20, arg_v = 0x100922640), line 1084 in "connection.c" [15] connection_read_thread(ctx = 0xffffffff78fffc20, argv = 0x22), line 1211 in "connection.c" [16] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" I have the testrun directories from each of these runs, if desired.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 15 Sep '08

15 Sep '08

I have uploaded a patch that incorporates yours into the code as after applying my fixes to certificate stuff and the implementation of certificateList matching as of last night (ITS#5700). I have modified your contribution to reflect the functionalities I have added to certificate handling in order to minimize code duplication. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2008-09-15-pmi.patch> Note that the OIDs used in the above patch are from OpenLDAP's development arc, but I didn't register them yet, because I first want to be sure there are no official OIDs for those syntaxes yet. The patch also includes the complete schema (objectClasses and attributeTypes) concerning PMI as of X.509. I'll commit it as soon as I get some feedback about your copyright notice and OID registration. In the meanwhile, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5673) Replication delete problem
by ghenry＠OpenLDAP.org 15 Sep '08

15 Sep '08

Miguel Jinez wrote: > I was making a test deleting 8600 users in my ldap DIT, but I think > meanwhile Master A perform the actions the synchronization doesn't > respect the hierachy and deletes fathers but not his sons. > Why I said that, because I try to upload again the users and in some > cases they alredy exist I think I recall an ITS for this. Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5700) [enhancement] add support for certificateListExactMatch (RFC4523)
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando About to commit... p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Other comments: - you seem to have hijacked the OIDs for the AttributeCertificate and attributeCertificateExactAssertion syntaxes. I'll generate two under the OpenLDAP experimental arc, unless anyone can point me to any officially assigned. I don't think so, as the only document I could locate on the topic is a draft expired in 2001 (draft-ietf-pkix-ldap-schema), with no OID assigned by IANA. - as far as I can understand, the attributeCertificateExactAssertion allows more options; a fairly generic case would be { serialNumber 'dd'H, issuer { issuerName { directoryName:rdnSequence:"cn=y" }, -- optional baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" }, issuerUID "<value>" -- optional }, -- optional objectDigestInfo { ... } -- optional } } while your implementation requires { serialNumber 'dd'H, issuer { baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" } } } } nothing more and nothing less. If I'm correct, your implementation would pose some interoperability issues; yet, it represents a good starting point, given the absence of any standard track specification of PMI. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2008