openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

(ITS#7131) Wrong integer types for connection loops
by h.b.furuseth＠usit.uio.no 23 Jan '12

23 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.28, master OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard connection_<first,next,done>() expect a ber_socket_t*connindex, but the callers pass an int*. Fixing.

1 0

Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by masarati＠aero.polimi.it 23 Jan '12

23 Jan '12

> Full_Name: Manny > Version: 2.4.23 > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.171.77.1) > > > Hi there. > > I'm posting this into the ITS as I didn't get a response on the mailing > list > after 1 week. > > I'm using the latest stable release of openldap, with back-sql and > postgresql as a backend. > I have an sssd which uses this openldap server for ID providing and > authentication. > A recent update in this sssd changed the filter used to retrieve > groupids of users, which surfaced what seems to be a bug in backsql. > >>From my investigation it seems to me that when constructing the search > query, openldap tries to use the UPPER function on every criteria in > the WHERE clause, no matter which type it is. This causes an error in > postgresql, as the gidNumber that is supposed to be filtered is of > type "bigint". I don't recall seeing your message in openldap-technical, which it belongs to. In any case, there should be a field in ldap_at_mappings that tells how and when an attribute value needs to be uppercased. However, I can't check right now whether it works as intended, and back-sql is unmaintained. p.

1 0

(ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac＠gmail.com 23 Jan '12

23 Jan '12

Full_Name: Manny Version: 2.4.23 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.171.77.1) Hi there. I'm posting this into the ITS as I didn't get a response on the mailing list after 1 week. I'm using the latest stable release of openldap, with back-sql and postgresql as a backend. I have an sssd which uses this openldap server for ID providing and authentication. A recent update in this sssd changed the filter used to retrieve groupids of users, which surfaced what seems to be a bug in backsql. >From my investigation it seems to me that when constructing the search query, openldap tries to use the UPPER function on every criteria in the WHERE clause, no matter which type it is. This causes an error in postgresql, as the gidNumber that is supposed to be filtered is of type "bigint". I could simply remove "upper_func" from my slapd.conf, but I need it for other queries. Changing the field gidNumber in the database to text would also be a workaround, but I'd rather prefer this fixed in backsql. Anyways, here is the important part of my slapd.conf: #----------------------------------------------- database sql suffix "dc=mydomain,dc=at" rootdn "cn=Manager,dc=mydomain,dc=at" rootpw mysecret dbname mydbname dbuser mydbuser dbpasswd myuserpw subtree_cond "UPPER(ldap_entries.dn) LIKE UPPER('%'||?)" insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)" upper_func "upper" upper_needs_cast "yes" strcast_func "text" concat_pattern "?||?" has_ldapinfo_dn_ru no sizelimit -1 #----------------------------------------------- The error can be reproduced in my case when running this command: #----------------------------------------------- ldapsearch -H ldaps://127.0.0.1/ -b ou=groups,ou=myserver,dc=mydomain,dc=at -D "uid=myuser,ou=users,ou=myserver,dc=mydomain,DC=at" '(gidNumber=512)' -W #----------------------------------------------- Which results in this output: #----------------------------------------------- # extended LDIF # # LDAPv3 # base <ou=groups,ou=myserver,dc=mydomain,dc=at> with scope subtree # filter: (gidNumber=512) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error #----------------------------------------------- Here is the interesting part of the level 255 log output: #----------------------------------------------- <==backsql_oc_get_candidates(): 0 ==>backsql_oc_get_candidates(): oc="sambaDomain" ==>backsql_srch_query() ==>backsql_process_filter() <==backsql_process_filter() succeeded <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap WHERE samba_domain_ldap.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND 7=7 Constructed query: SELECT DISTINCT ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap WHERE samba_domain_ldap.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND 7=7 id: '6' (sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT" <==backsql_oc_get_candidates(): 0 ==>backsql_oc_get_candidates(): oc="inetOrgPerson" ==>backsql_srch_query() ==>backsql_process_filter() ==>backsql_process_filter_attr(gidNumber) <==backsql_process_filter_attr(gidNumber) <==backsql_process_filter() succeeded <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND (upper(OS_USER.gidnumber)='512') Constructed query: SELECT DISTINCT ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND (upper(OS_USER.gidnumber)='512') id: '8' (sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT" backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: function upper(bigint) does not exist at character 288;#012Error while executing the query" #----------------------------------------------- Thanks a lot

1 0

Re: (ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by hyc＠symas.com 21 Jan '12

21 Jan '12

kacarstensen(a)csupomona.edu wrote: > I've investigated this issue a little bit more since my initial bug > report. > I'm not sure if connection_write is supposed to validate that a stream > is active before or after calling slapd_clr_write, but it seems like the > assertion wouldn't be an issue if that validation were performed before > calling slapd_clr_write. To test this thought, I rebuilt openldap 2.4.28 > with the following patch: > > --- openldap-2.4.28/servers/slapd/connection.c 2011-11-25 10:52:29.000000000 -0800 > +++ openldap-2.4.28-new/servers/slapd/connection.c 2012-01-12 13:35:45.000000000 -0800 > @@ -1893,8 +1893,6 @@ > > assert( connections != NULL ); > > - slapd_clr_write( s, 0 ); > - > c = connection_get( s ); > if( c == NULL ) { > Debug( LDAP_DEBUG_ANY, > @@ -1903,6 +1901,8 @@ > return -1; > } > > + slapd_clr_write( s, 0 ); > + > #ifdef HAVE_TLS > if ( c->c_is_tls&& c->c_needs_tls_accept ) { > connection_return( c ); > > and tried to reproduce the problem under the same circumstances as > reported in my initial bug report. The master slapd tolerated the > misconfigured replicas for 5 days without crashing; before, it would > crash reliably within a half hour or so. I didn't notice any regressions > due to the patch, though the master slapd wasn't exposed to a typical > workload during the experiment. > > Any thoughts on this patch? Sounds OK to me, committed to git master. Thanks. -- -- 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

(ITS#7129) slapo-valsort(5) missing description of LDAP_CONTROL_VALSORT
by quanah＠OpenLDAP.org 20 Jan '12

20 Jan '12

Full_Name: Version: 2.4.28 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) While the slapo-valsort manual page describes the ways in which data can be sorted and displayed, it does not note the fact that there is a control that can be used to disable it from applying to a search result: LDAP_CONTROL_VALSORT This is useful information for people wishing to use the overlay.

1 0

Re: (ITS#7127) Syncrepl config uses freed data
by hyc＠symas.com 19 Jan '12

19 Jan '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.21++, master > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > In syncrepl_config(), ldap_pvt_runqueue_remove() frees 're', > then the retract statement reads 're->routine': > > ldap_pvt_runqueue_remove(&slapd_rq, re ); > ldap_pvt_thread_mutex_unlock(&slapd_rq.rq_mutex ); > if ( ldap_pvt_thread_pool_retract(&connection_pool, > re->routine, re )> 0 ) > > Formally I think the pointer 're' itself is invalid after freeing it, > so the ISO C-clean fix would involve calling retract() first. If > that's wrong: I assume the thread pool is paused at this point, so > the task can not be started (and use re) before it can be retracted, > and we can just just read re->routine before freeing re. Makes sense. Fixed in master. > > Found by Valgrind in test063-delta-multimaster. -- -- 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

(ITS#7127) Syncrepl config uses freed data
by h.b.furuseth＠usit.uio.no 19 Jan '12

19 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.21++, master OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard In syncrepl_config(), ldap_pvt_runqueue_remove() frees 're', then the retract statement reads 're->routine': ldap_pvt_runqueue_remove( &slapd_rq, re ); ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); if ( ldap_pvt_thread_pool_retract( &connection_pool, re->routine, re ) > 0 ) Formally I think the pointer 're' itself is invalid after freeing it, so the ISO C-clean fix would involve calling retract() first. If that's wrong: I assume the thread pool is paused at this point, so the task can not be started (and use re) before it can be retracted, and we can just just read re->routine before freeing re. Found by Valgrind in test063-delta-multimaster.

1 0

Re: (ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by kacarstensen＠csupomona.edu 17 Jan '12

17 Jan '12

I've investigated this issue a little bit more since my initial bug report. With loglevel conns sync in slapd.conf, the following are the last messages written to the log before slapd crashes: Jan 12 09:33:19 shelley slapd[2482]: Jan 12 09:33:19 shelley slapd[2482]: daemon: write active on 15 Jan 12 09:33:19 shelley slapd[2482]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jan 12 09:33:19 shelley slapd[2482]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jan 12 09:33:19 shelley slapd[2482]: daemon: activity on 1 descriptor Jan 12 09:33:19 shelley slapd[2482]: daemon: activity on: Jan 12 09:33:19 shelley slapd[2482]: 15rw Jan 12 09:33:19 shelley slapd[2482]: ber_flush2 failed errno=32 reason="Broken pipe" Jan 12 09:33:19 shelley slapd[2482]: connection_closing: readying conn=1377 sd=15 for close Jan 12 09:33:19 shelley slapd[2482]: send_search_entry: conn 1377 ber write failed. Jan 12 09:33:19 shelley slapd[2482]: connection_resched: attempting closing conn=1377 sd=15 Jan 12 09:33:19 shelley slapd[2482]: daemon: removing 15 Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: Jan 12 09:33:19 shelley slapd[2482]: daemon: write active on 15 "daemon: write active on 15" comes from line 2660 or so of daemon.c. Here's that with some context: for ( i = 0; nwfds > 0; i++ ) { ber_socket_t wd; if ( ! SLAP_EVENT_IS_WRITE( i ) ) continue; wd = i; SLAP_EVENT_CLR_WRITE( wd ); nwfds--; Debug(LDAP_DEBUG_CONNS, "daemon: write active on %d\n", wd, 0, 0); /* * NOTE: it is possible that the connection was closed and that * the stream is now inactive. connection_write() must validate * the stream is still active. * * ITS#4338: if the stream is invalid, there is no need to close it * here. It has already been closed in connection.c. */ if ( connection_write( wd ) < 0 ) { if ( SLAP_EVENT_IS_READ( wd)) { SLAP_EVENT_CLR_READ( (unsigned) wd); nrfds--; } } } We do some housekeeping on the descriptor, then call connection_write to take care of the write. Here's connection_write from connection.c: int connection_write(ber_socket_t s) { Connection *c; Operation *op; assert( connections != NULL ); slapd_clr_write( s, 0 ); c = connection_get( s ); if( c == NULL ) { Debug( LDAP_DEBUG_ANY, "connection_write(%ld): no connection!\n", (long)s, 0, 0 ); return -1; } [...] connection_get seems to perform the validation that is mentioned by the comment in daemon.c, but connection_get is called after slapd_clr_write, which is the source of the assertion implicated by the backtrace in the initial bug report: void slapd_clr_write( ber_socket_t s, int wake ) { int id = DAEMON_ID(s); ldap_pvt_thread_mutex_lock( &slap_daemon[id].sd_mutex ); if ( SLAP_SOCK_IS_WRITE( id, s )) { assert( SLAP_SOCK_IS_ACTIVE( id, s )); SLAP_SOCK_CLR_WRITE( id, s ); slap_daemon[id].sd_nwriters--; } ldap_pvt_thread_mutex_unlock( &slap_daemon[id].sd_mutex ); WAKE_LISTENER(id,wake); } I'm not sure if connection_write is supposed to validate that a stream is active before or after calling slapd_clr_write, but it seems like the assertion wouldn't be an issue if that validation were performed before calling slapd_clr_write. To test this thought, I rebuilt openldap 2.4.28 with the following patch: --- openldap-2.4.28/servers/slapd/connection.c 2011-11-25 10:52:29.000000000 -0800 +++ openldap-2.4.28-new/servers/slapd/connection.c 2012-01-12 13:35:45.000000000 -0800 @@ -1893,8 +1893,6 @@ assert( connections != NULL ); - slapd_clr_write( s, 0 ); - c = connection_get( s ); if( c == NULL ) { Debug( LDAP_DEBUG_ANY, @@ -1903,6 +1901,8 @@ return -1; } + slapd_clr_write( s, 0 ); + #ifdef HAVE_TLS if ( c->c_is_tls && c->c_needs_tls_accept ) { connection_return( c ); and tried to reproduce the problem under the same circumstances as reported in my initial bug report. The master slapd tolerated the misconfigured replicas for 5 days without crashing; before, it would crash reliably within a half hour or so. I didn't notice any regressions due to the patch, though the master slapd wasn't exposed to a typical workload during the experiment. Any thoughts on this patch? -- Kevan Carstensen <kacarstensen(a)csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

1 0

RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 14 Jan '12

14 Jan '12

--_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBIb3dhcmQsDQoNCk5pY2UgdG8ga25vdyB5b3XimLoNCldvdWxkIHlvdSB0ZWxsIG1lIHdo byBJIGNhbiBjb250YWN0IHRvIGdldCB0aGlzIHJvYWRtYXAgaW5mb3JtYXRpb24gb2YgT3BlbkxE QVAgZGlyZWN0b3J5IHNlcnZlciBpbiAyMDEyPw0KVGhhbmtzIGluIGFkdmFuY2UuDQoNCkJlc3Qg cmVnYXJkcywNCkhlbnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dh cmQgQ2h1IFttYWlsdG86aHljQHN5bWFzLmNvbV0NClNlbnQ6IDIwMTLlubQx5pyIMTTml6UgMTg6 MzcNClRvOiBRaW5neXVuIFpodQ0KQ2M6IG9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmcNClN1Ympl Y3Q6IFJlOiAoSVRTIzcxMjQpIENvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9hZG1h cCBvZiBPcGVuTERBUCBkaXJlY3Rvcnkgc2VydmVyIGZvciAyMDEyPw0KDQpxemh1QHRpYmNvLXN1 cHBvcnQuY29tIHdyb3RlOg0KPiBIZWxsbywgVGVhbSwNCj4NCj4gU29ycnkgdG8gZGlzdHVyYiB5 b3UsIGhvd2V2ZXIsIGl0IGlzIHVyZ2VudCBmb3IgdXMgdG8ga25vdyB0aGUgcm9hZG1hcCBvZiBP cGVuTERBUCBEaXJlY3RvcnkgU2VydmVyIHNvZnR3YXJlIGluIDIwMTIuIE1lYW53aGlsZSwgSSB0 aGluayB0aGF0IGl0IGlzIGFsc28gaGVscGZ1bCB0byB5b3VyIHByb2R1Y3QuIEkgbG9vayBmb3J3 YXJkcyB0byB5b3VyIHF1aWNrIHJlc3BvbnNlLiBJdCBpcyBmaW5lIHRoYXQgeW91IGNhbiB0ZWxs IHVzIHdobyBjYW4gYW5zd2VyIHRoaXMgcXVlc3Rpb24gZm9yIG1lIGlmIHlvdSBjYW4ndCBhbnN3 ZXIgdGhlc2UgcXVlc3Rpb25zLCB3ZSBzaGFsbCBkaXJlY3RseSBjb250YWN0IHRoZW0uIFRoYW5r cy4NCg0KVGhlIElUUyBpcyBmb3IgYnVnIHJlcG9ydHMsIG5vdCBmb3IgaW5mb3JtYXRpb24gcmVx dWVzdHMuIFRoaXMgSVRTIHdpbGwgYmUgY2xvc2VkLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEhl bnJ5DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFpbmd5dW4gWmh1DQo+ IFNlbnQ6IDIwMTLDhMOqMcOUw4IxMsOIw5UgMjA6MjUNCj4gVG86ICdvcGVubGRhcC1pdHNAT3Bl bkxEQVAub3JnJw0KPiBDYzogJ01hZ2dpZSBXb25nJw0KPiBTdWJqZWN0OiBSRTogKElUUyM3MTI0 KSBDb3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGly ZWN0b3J5IHNlcnZlciBmb3IgMjAxMj8NCj4NCj4gRGVhciB0ZWFtLA0KPg0KPiBDb3VsZCB5b3Ug cGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGlyZWN0b3J5IHNlcnZl ciBmb3IgMjAxMj8NCj4gV2UgYXJlIGludGVyZXN0ZWQgaW4gZmluZGluZyBvdXQNCj4gICDCocKk IEFueSBuZXcgcmVsZWFzZXMgcGxhbm5pbmcgaW4gMjAxMi4gSWYgYW55LCB3aGF0IGFyZSB0aGUg bmV3IGZlYXR1cmVzPw0KPiAgIMKhwqQgQW55IHBsYW4gdG8gc3VwcG9ydCBXaW5kb3dzNywgUkhF TDYueCBhbmQgQUlYIDcuMT8NCj4NCj4gVGhhbmtzJiAgQmVzdCByZWdhcmRzLA0KPiBIZW5yeQ0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvcGVubGRhcC1pdHNAT3BlbkxE QVAub3JnIFttYWlsdG86b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZ10NCj4gU2VudDogMjAxMsOE w6oxw5TDgjEyw4jDlSAyMDoyMg0KPiBUbzogUWluZ3l1biBaaHUNCj4gU3ViamVjdDogUmU6IChJ VFMjNzEyNCkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1lIHRoZSByb2FkbWFwIG9mIE9wZW5M REFQIGRpcmVjdG9yeSBzZXJ2ZXIgZm9yIDIwMTI/DQo+DQo+DQo+ICoqKiBUSElTIElTIEFOIEFV VE9NQVRJQ0FMTFkgR0VORVJBVEVEIFJFUExZICoqKg0KPg0KPiBUaGFua3MgZm9yIHlvdXIgcmVw b3J0IHRvIHRoZSBPcGVuTERBUCBJc3N1ZSBUcmFja2luZyBTeXN0ZW0uICBZb3VyDQo+IHJlcG9y dCBoYXMgYmVlbiBhc3NpZ25lZCB0aGUgdHJhY2tpbmcgbnVtYmVyIElUUyM3MTI0Lg0KPg0KPiBP bmUgb2Ygb3VyIHN1cHBvcnQgZW5naW5lZXJzIHdpbGwgbG9vayBhdCB5b3VyIHJlcG9ydCBpbiBk dWUgY291cnNlLg0KPiBOb3RlIHRoYXQgdGhpcyBtYXkgdGFrZSBzb21lIHRpbWUgYmVjYXVzZSBv dXIgc3VwcG9ydCBlbmdpbmVlcnMNCj4gYXJlIHZvbHVudGVlcnMuICBUaGV5IG9ubHkgd29yayBv biBPcGVuTERBUCB3aGVuIHRoZXkgaGF2ZSBzcGFyZQ0KPiB0aW1lLg0KPg0KPiBJZiB5b3UgbmVl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0byB5b3VyDQo+ IGlzc3VlIHJlcG9ydCwgeW91IG1heSBkbyBzbyBieSByZXBseWluZyB0byB0aGlzIG1lc3NhZ2Uu ICBOb3RlIHRoYXQNCj4gYW55IG1haWwgc2VudCB0byBvcGVubGRhcC1pdHNAb3BlbmxkYXAub3Jn IHdpdGggKElUUyM3MTI0KQ0KPiBpbiB0aGUgc3ViamVjdCB3aWxsIGF1dG9tYXRpY2FsbHkgYmUg YXR0YWNoZWQgdG8gdGhlIGlzc3VlIHJlcG9ydC4NCj4NCj4gICAgICAgICAgbWFpbHRvOm9wZW5s ZGFwLWl0c0BvcGVubGRhcC5vcmc/c3ViamVjdD0oSVRTIzcxMjQpDQo+DQo+IFlvdSBtYXkgZm9s bG93IHRoZSBwcm9ncmVzcyBvZiB0aGlzIHJlcG9ydCBieSBsb2FkaW5nIHRoZSBmb2xsb3dpbmcN Cj4gVVJMIGluIGEgd2ViIGJyb3dzZXI6DQo+ICAgICAgaHR0cDovL3d3dy5PcGVuTERBUC5vcmcv aXRzL2luZGV4LmNnaT9maW5kaWQ9NzEyNA0KPg0KPiBQbGVhc2UgcmVtZW1iZXIgdG8gcmV0YWlu IHlvdXIgaXNzdWUgdHJhY2tpbmcgbnVtYmVyIChJVFMjNzEyNCkNCj4gb24gYW55IGZ1cnRoZXIg bWVzc2FnZXMgeW91IHNlbmQgdG8gdXMgcmVnYXJkaW5nIHRoaXMgcmVwb3J0LiAgSWYNCj4geW91 IGRvbid0IHRoZW4geW91J2xsIGp1c3Qgd2FzdGUgb3VyIHRpbWUgYW5kIHlvdXJzIGJlY2F1c2Ug d2UNCj4gd29uJ3QgYmUgYWJsZSB0byBwcm9wZXJseSB0cmFjayB0aGUgcmVwb3J0Lg0KPg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBJc3N1ZSBUcmFja2luZyBTeXN0ZW0gaXMgbm90IGludGVuZGVk IHRvDQo+IGJlIHVzZWQgdG8gc2VlayBoZWxwIGluIHRoZSBwcm9wZXIgdXNlIG9mIE9wZW5MREFQ IFNvZnR3YXJlLg0KPiBTdWNoIHJlcXVlc3RzIHdpbGwgYmUgY2xvc2VkLg0KPg0KPiBPcGVuTERB UCBTb2Z0d2FyZSBpcyB1c2VyIHN1cHBvcnRlZC4NCj4gICAgICAgICAgaHR0cDovL3d3dy5PcGVu TERBUC5vcmcvc3VwcG9ydC8NCj4NCj4gLS0tLS0tLS0tLS0tLS0NCj4gQ29weXJpZ2h0IDE5OTgt MjAwNyBUaGUgT3BlbkxEQVAgRm91bmRhdGlvbiwgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCj4NCj4N Cj4NCj4NCg0KDQotLQ0KICAgLS0gSG93YXJkIENodQ0KICAgQ1RPLCBTeW1hcyBDb3JwLiAgICAg ICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCiAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAg IGh0dHA6Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KICAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERB UCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8NCg0K --_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSLlrovkvZMiIHNpemU9IjIiPg0KPGRpdj5EZWFy IEhvd2FyZCw8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBzZXJpZiI+ Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj5OaWNlIHRvIGtub3cgeW91PGZvbnQgZmFjZT0iV2lu Z2RpbmdzIiBzaXplPSIyIj5KPC9mb250PjwvZGl2Pg0KPGRpdj5Xb3VsZCB5b3UgdGVsbCBtZSB3 aG8gSSBjYW4gY29udGFjdCB0byBnZXQgdGhpcyByb2FkbWFwIGluZm9ybWF0aW9uIG9mIE9wZW5M REFQIGRpcmVjdG9yeSBzZXJ2ZXIgaW4gMjAxMj88L2Rpdj4NCjxkaXY+VGhhbmtzIGluIGFkdmFu Y2UuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiwgc2VyaWYiPiZuYnNw OzwvZm9udD48L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj5IZW5yeTwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KDQpGcm9tOiBIb3dh cmQgQ2h1IFs8YSBocmVmPSJtYWlsdG86aHljQHN5bWFzLmNvbSI+bWFpbHRvOmh5Y0BzeW1hcy5j b208L2E+XSA8YnI+DQoNClNlbnQ6IDIwMTLlubQx5pyIMTTml6UgMTg6Mzc8YnI+DQoNClRvOiBR aW5neXVuIFpodTxicj4NCg0KQ2M6IG9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmc8YnI+DQoNClN1 YmplY3Q6IFJlOiAoSVRTIzcxMjQpIENvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9h ZG1hcCBvZiBPcGVuTERBUCBkaXJlY3Rvcnkgc2VydmVyIGZvciAyMDEyPzwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2PnF6aHVAdGliY28tc3VwcG9ydC5jb20gd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgSGVsbG8s IFRlYW0sPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBTb3JyeSB0byBkaXN0dXJi IHlvdSwgaG93ZXZlciwgaXQgaXMgdXJnZW50IGZvciB1cyB0byBrbm93IHRoZSByb2FkbWFwIG9m IE9wZW5MREFQIERpcmVjdG9yeSBTZXJ2ZXIgc29mdHdhcmUgaW4gMjAxMi4gTWVhbndoaWxlLCBJ IHRoaW5rIHRoYXQgaXQgaXMgYWxzbyBoZWxwZnVsIHRvIHlvdXIgcHJvZHVjdC4gSSBsb29rIGZv cndhcmRzIHRvIHlvdXIgcXVpY2sgcmVzcG9uc2UuIEl0IGlzIGZpbmUgdGhhdCB5b3UgY2FuIHRl bGwgdXMNCndobyBjYW4gYW5zd2VyIHRoaXMgcXVlc3Rpb24gZm9yIG1lIGlmIHlvdSBjYW4ndCBh bnN3ZXIgdGhlc2UgcXVlc3Rpb25zLCB3ZSBzaGFsbCBkaXJlY3RseSBjb250YWN0IHRoZW0uIFRo YW5rcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBJVFMgaXMgZm9yIGJ1ZyBy ZXBvcnRzLCBub3QgZm9yIGluZm9ybWF0aW9uIHJlcXVlc3RzLiBUaGlzIElUUyB3aWxsIGJlIGNs b3NlZC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEJlc3QgcmVnYXJkcyw8L2Rp dj4NCjxkaXY+Jmd0OyBIZW5yeTwvZGl2Pg0KPGRpdj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPC9kaXY+DQo8ZGl2PiZndDsgRnJvbTogUWluZ3l1biBaaHU8L2Rpdj4NCjxkaXY+Jmd0 OyBTZW50OiAyMDEyPGZvbnQgZmFjZT0iQ291cmllciBOZXcsIG1vbm9zcGFjZSI+w4TDqjwvZm9u dD4xPGZvbnQgZmFjZT0iQ291cmllciBOZXcsIG1vbm9zcGFjZSI+w5TDgjwvZm9udD4xMjxmb250 IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOIw5U8L2ZvbnQ+IDIwOjI1PC9kaXY+DQo8 ZGl2PiZndDsgVG86ICdvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnJzwvZGl2Pg0KPGRpdj4mZ3Q7 IENjOiAnTWFnZ2llIFdvbmcnPC9kaXY+DQo8ZGl2PiZndDsgU3ViamVjdDogUkU6IChJVFMjNzEy NCkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1lIHRoZSByb2FkbWFwIG9mIE9wZW5MREFQIGRp cmVjdG9yeSBzZXJ2ZXIgZm9yIDIwMTI/PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyBEZWFyIHRlYW0sPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBDb3VsZCB5b3Ug cGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGlyZWN0b3J5IHNlcnZl ciBmb3IgMjAxMj88L2Rpdj4NCjxkaXY+Jmd0OyBXZSBhcmUgaW50ZXJlc3RlZCBpbiBmaW5kaW5n IG91dDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7IDxmb250IGZhY2U9IkNvdXJpZXIgTmV3 LCBtb25vc3BhY2UiPsKhwqQ8L2ZvbnQ+IEFueSBuZXcgcmVsZWFzZXMgcGxhbm5pbmcgaW4gMjAx Mi4gSWYgYW55LCB3aGF0IGFyZSB0aGUgbmV3IGZlYXR1cmVzPzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5i c3A7Jm5ic3A7IDxmb250IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsKhwqQ8L2ZvbnQ+ IEFueSBwbGFuIHRvIHN1cHBvcnQgV2luZG93czcsIFJIRUw2LnggYW5kIEFJWCA3LjE/PC9kaXY+ DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGFua3MmYW1wOyZuYnNwOyBCZXN0IHJlZ2Fy ZHMsPC9kaXY+DQo8ZGl2PiZndDsgSGVucnk8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7IEZyb206IG9wZW5sZGFwLWl0c0BPcGVuTERB UC5vcmcgWzxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnIj5tYWlsdG86 b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZzwvYT5dPC9kaXY+DQo8ZGl2PiZndDsgU2VudDogMjAx Mjxmb250IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOEw6o8L2ZvbnQ+MTxmb250IGZh Y2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOUw4I8L2ZvbnQ+MTI8Zm9udCBmYWNlPSJDb3Vy aWVyIE5ldywgbW9ub3NwYWNlIj7DiMOVPC9mb250PiAyMDoyMjwvZGl2Pg0KPGRpdj4mZ3Q7IFRv OiBRaW5neXVuIFpodTwvZGl2Pg0KPGRpdj4mZ3Q7IFN1YmplY3Q6IFJlOiAoSVRTIzcxMjQpIENv dWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9hZG1hcCBvZiBPcGVuTERBUCBkaXJlY3Rv cnkgc2VydmVyIGZvciAyMDEyPzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rp dj4NCjxkaXY+Jmd0OyAqKiogVEhJUyBJUyBBTiBBVVRPTUFUSUNBTExZIEdFTkVSQVRFRCBSRVBM WSAqKio8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFRoYW5rcyBmb3IgeW91ciBy ZXBvcnQgdG8gdGhlIE9wZW5MREFQIElzc3VlIFRyYWNraW5nIFN5c3RlbS4mbmJzcDsgWW91cjwv ZGl2Pg0KPGRpdj4mZ3Q7IHJlcG9ydCBoYXMgYmVlbiBhc3NpZ25lZCB0aGUgdHJhY2tpbmcgbnVt YmVyIElUUyM3MTI0LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgT25lIG9mIG91 ciBzdXBwb3J0IGVuZ2luZWVycyB3aWxsIGxvb2sgYXQgeW91ciByZXBvcnQgaW4gZHVlIGNvdXJz ZS48L2Rpdj4NCjxkaXY+Jmd0OyBOb3RlIHRoYXQgdGhpcyBtYXkgdGFrZSBzb21lIHRpbWUgYmVj YXVzZSBvdXIgc3VwcG9ydCBlbmdpbmVlcnM8L2Rpdj4NCjxkaXY+Jmd0OyBhcmUgdm9sdW50ZWVy cy4mbmJzcDsgVGhleSBvbmx5IHdvcmsgb24gT3BlbkxEQVAgd2hlbiB0aGV5IGhhdmUgc3BhcmU8 L2Rpdj4NCjxkaXY+Jmd0OyB0aW1lLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg SWYgeW91IG5lZWQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIHJlZ2FyZHMg dG8geW91cjwvZGl2Pg0KPGRpdj4mZ3Q7IGlzc3VlIHJlcG9ydCwgeW91IG1heSBkbyBzbyBieSBy ZXBseWluZyB0byB0aGlzIG1lc3NhZ2UuJm5ic3A7IE5vdGUgdGhhdDwvZGl2Pg0KPGRpdj4mZ3Q7 IGFueSBtYWlsIHNlbnQgdG8gb3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZyB3aXRoIChJVFMjNzEy NCk8L2Rpdj4NCjxkaXY+Jmd0OyBpbiB0aGUgc3ViamVjdCB3aWxsIGF1dG9tYXRpY2FsbHkgYmUg YXR0YWNoZWQgdG8gdGhlIGlzc3VlIHJlcG9ydC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnP3N1YmplY3Q9KElU UyM3MTI0Ij5tYWlsdG86b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZz9zdWJqZWN0PShJVFMjNzEy NDwvYT4pPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBZb3UgbWF5IGZvbGxvdyB0 aGUgcHJvZ3Jlc3Mgb2YgdGhpcyByZXBvcnQgYnkgbG9hZGluZyB0aGUgZm9sbG93aW5nPC9kaXY+ DQo8ZGl2PiZndDsgVVJMIGluIGEgd2ViIGJyb3dzZXI6PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5PcGVuTERBUC5vcmcv aXRzL2luZGV4LmNnaT9maW5kaWQ9NzEyNCI+aHR0cDovL3d3dy5PcGVuTERBUC5vcmcvaXRzL2lu ZGV4LmNnaT9maW5kaWQ9NzEyNDwvYT48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 IFBsZWFzZSByZW1lbWJlciB0byByZXRhaW4geW91ciBpc3N1ZSB0cmFja2luZyBudW1iZXIgKElU UyM3MTI0KTwvZGl2Pg0KPGRpdj4mZ3Q7IG9uIGFueSBmdXJ0aGVyIG1lc3NhZ2VzIHlvdSBzZW5k IHRvIHVzIHJlZ2FyZGluZyB0aGlzIHJlcG9ydC4mbmJzcDsgSWY8L2Rpdj4NCjxkaXY+Jmd0OyB5 b3UgZG9uJ3QgdGhlbiB5b3UnbGwganVzdCB3YXN0ZSBvdXIgdGltZSBhbmQgeW91cnMgYmVjYXVz ZSB3ZTwvZGl2Pg0KPGRpdj4mZ3Q7IHdvbid0IGJlIGFibGUgdG8gcHJvcGVybHkgdHJhY2sgdGhl IHJlcG9ydC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFBsZWFzZSBub3RlIHRo YXQgdGhlIElzc3VlIFRyYWNraW5nIFN5c3RlbSBpcyBub3QgaW50ZW5kZWQgdG88L2Rpdj4NCjxk aXY+Jmd0OyBiZSB1c2VkIHRvIHNlZWsgaGVscCBpbiB0aGUgcHJvcGVyIHVzZSBvZiBPcGVuTERB UCBTb2Z0d2FyZS48L2Rpdj4NCjxkaXY+Jmd0OyBTdWNoIHJlcXVlc3RzIHdpbGwgYmUgY2xvc2Vk LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgT3BlbkxEQVAgU29mdHdhcmUgaXMg dXNlciBzdXBwb3J0ZWQuPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5PcGVuTERB UC5vcmcvc3VwcG9ydC8iPmh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL3N1cHBvcnQvPC9hPjwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgLS0tLS0tLS0tLS0tLS08L2Rpdj4NCjxkaXY+ Jmd0OyBDb3B5cmlnaHQgMTk5OC0yMDA3IFRoZSBPcGVuTERBUCBGb3VuZGF0aW9uLCBBbGwgUmln aHRzIFJlc2VydmVkLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+LS08L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IC0tIEhvd2FyZCBD aHU8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IENUTywgU3ltYXMgQ29ycC4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cDovL3d3dy5zeW1hcy5jb20iPmh0dHA6Ly93d3cuc3ltYXMuY29tPC9hPjwvZGl2Pg0KPGRp dj4mbmJzcDsmbmJzcDsgRGlyZWN0b3IsIEhpZ2hsYW5kIFN1biZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8iPmh0dHA6Ly9oaWdobGFu ZHN1bi5jb20vaHljLzwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IENoaWVmIEFyY2hpdGVj dCwgT3BlbkxEQVAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVj dC8iPmh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3QvPC9hPjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8L2Zv bnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_--

1 0

Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by hyc＠symas.com 14 Jan '12

14 Jan '12

qzhu(a)tibco-support.com wrote: > Hello, Team, > > Sorry to disturb you, however, it is urgent for us to know the roadmap of OpenLDAP Directory Server software in 2012. Meanwhile, I think that it is also helpful to your product. I look forwards to your quick response. It is fine that you can tell us who can answer this question for me if you can't answer these questions, we shall directly contact them. Thanks. The ITS is for bug reports, not for information requests. This ITS will be closed. > > Best regards, > Henry > -----Original Message----- > From: Qingyun Zhu > Sent: 2012Äê1ÔÂ12ÈÕ 20:25 > To: 'openldap-its(a)OpenLDAP.org' > Cc: 'Maggie Wong' > Subject: RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? > > Dear team, > > Could you please provide me the roadmap of OpenLDAP directory server for 2012? > We are interested in finding out > ¡¤ Any new releases planning in 2012. If any, what are the new features? > ¡¤ Any plan to support Windows7, RHEL6.x and AIX 7.1? > > Thanks& Best regards, > Henry > -----Original Message----- > From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] > Sent: 2012Äê1ÔÂ12ÈÕ 20:22 > To: Qingyun Zhu > Subject: Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? > > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7124. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7124) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7124) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7124 > > Please remember to retain your issue tracking number (ITS#7124) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > > > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs