openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5098) No Internationalization for certain attributes
by binoy＠cordys.com 20 Aug '07

20 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E312.FF391C61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Sorry for the confusion. What I meant was that I tried to enter Chinese values for these attributes. And it failed. It succeeds otherwise. =20 Thanks and Regards, Binoy Joseph =20 *********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it is prohibited and may be unlawful. Please immediately contact=20 the sender if you have received this message in error. This email does not constitute any commitment from Cordys Holding BV or any of its subsidiaries except when expressly agreed in a written agreement between the intended recipient and Cordys Holding BV or its subsidiaries. *********************************************************************** ------_=_NextPart_001_01C7E312.FF391C61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)"> <style>  </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> Hi,   Sorry for the confusion. What I meant was that I tried to enter Chinese values = for these attributes. And it failed. It succeeds otherwise.   Thanks and Regards, Binoy Joseph   </div> *********************= ************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it is prohibited and may be unlawful. Please immediately contact the sender if you hav= e received this message in error. This email does not constitute any commitment from Cordys Holding BV or any of its subsidiaries except when expressly agreed in a written agreement between the intended recipient and Cordys Holding BV or its subsidiaries. ***********************************************************************</sp= an>    </bo= dy> </html> ------_=_NextPart_001_01C7E312.FF391C61--

1 0

(ITS#5098) No Internationalization for certain attributes
by binoy＠cordys.com 20 Aug '07

20 Aug '07

Full_Name: Binoy Joseph Version: 3 OS: Windows XP URL: Submission from: (NULL) (210.210.79.19) Certain attributes of a user, like telephoneNumber, mail, facsimileTelephoneNumber... cannot be entered in other languages. They do not support internationalization.

1 0

(ITS#5097) slapo-refint apply to subtree renaming
by zhangweiwu＠realss.com 20 Aug '07

20 Aug '07

Full_Name: Zhang Weiwu Version: 2.3.37 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (218.193.55.195) It would be nice if referential integrity is maintained during subtree renaming. entries: dn: cn=Wang,ou=sales,o=example.com ... dn: o=Su,ou=sales,o=example.com manager: cn=Wang,ou=sales,o=example.com do this: $ ldapmodrdn ou=sales,o=example.com ou=sales,ou=marketing,o=example.com Expected result dn: cn=Wang,ou=sales,ou=marketing,o=example.com ... dn: o=Su,ou=sales,ou=marketing,o=example.com manager: cn=Wang,ou=sales,ou=marketing,o=example.com ... I marked this as a bug rather than feature request because this is the expected behavior for using with hdb backend.

1 0

Re: (ITS#5095) back-sql concurrency issues
by ando＠sys-net.it 20 Aug '07

20 Aug '07

ando(a)sys-net.it wrote: > In this sense I think it's meaningless to share > handles for write operations based on the client connection. All in all, the > same user is always used to access the DB, and access control is done by the > backend, while there's no guarantee the client will serialize requests. So a > separate pool of handles could be maintained and used for write operations only; > handles wouldn't need to be created all times, they can be reused. Only, they > need to be used exclusively by one operation, so that SQLTransact() is only > called for the specified sequence of operations. The pool could be fixed size, > deferring operations when busy, or grow on request. Actually, there's no need to cache handles based on the connection or so. It's better to have connections cached per-thread, to make sure they can only be used one at a time. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5096) [enhancement] back-sql should provide a means to reload schema mapping runtime
by ando＠sys-net.it 19 Aug '07

19 Aug '07

Full_Name: Pierangelo Masarati Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando This is a request enhancement for a means to reload schema mapping run-time, without the need to stop slapd. The ideal candidate for this feature seems to be back-monitor.

1 0

(ITS#5095) back-sql concurrency issues
by ando＠sys-net.it 19 Aug '07

19 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I believe there are (at least) two issues with back-sql: 1) cached db handle AVL access in backsql_get_db_conn() is not protected by mutex, as insertion/deletion. 2) cached db handles are shared by operations performed by the same client connection, so concurrent operations use the same db handle. I believe each write operation should use a separate handle in order to be atomic. Issue (1) will be fixed shortly; issue (2) will be fixed as soon as I finish rewriting db handle code. In this sense I think it's meaningless to share handles for write operations based on the client connection. All in all, the same user is always used to access the DB, and access control is done by the backend, while there's no guarantee the client will serialize requests. So a separate pool of handles could be maintained and used for write operations only; handles wouldn't need to be created all times, they can be reused. Only, they need to be used exclusively by one operation, so that SQLTransact() is only called for the specified sequence of operations. The pool could be fixed size, deferring operations when busy, or grow on request. p.

1 0

Re: (ITS#5089) test043-delta-syncrepl: test failed - producer and consumer databases differ
by michael＠stroeder.com 18 Aug '07

18 Aug '07

It seems this has been fixed in the meantime by one of the many changes during the last time. Ciao, Michael.

1 0

(ITS#5094) shutting down multiple ppolicy instances yields double-free
by mbackes＠symas.com 16 Aug '07

16 Aug '07

Full_Name: Matthew Backes Version: 2.3.x, head OS: all URL: Submission from: (NULL) (132.241.73.19) slapo-ppolicy's close method frees the static pwcons without checking to see if someone else is using or has freed it already. This issue appears at shutdown when trying to use slapo-ppolicy on multiple backends. Revisions 1.105 and 1.106 to ppolicy.c (in HEAD) fix this problem.

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

ando(a)sys-net.it writes: > The "right" solution would be to protect the identity of the rootdn > with ACLs, so that regular users cannot add/modify it. Good idea, but that too depends on your policy. If you you have a cron job or whatever which updates entries, including that of the rootdn, you may not want it to have full rootdn access. If nothing else, it's a bit like logging in as root instead of as a regular user - if you screw up you have the opportunity to create much more havoc. I wonder if we need a rootpolicy config parameter to tune the details of all this. Then we can set a fairly paranoid default, and people who need it to work differently can override. (Another thing I remember someone asked about was to only accept rootdn login from some specific IP address. But now that I think of it, normal ACLs could ensure that if he had the password in an entry instead of in rootpw.) -- Hallvard

1 0

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by hyc＠symas.com 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com wrote: > Over the years i have > seen quite some Active Directories customers and many of them are very > afraid when you ask them you change some configuration or extending the > schema. Doesn't it seem odd to you that people would voluntarily use software that they are afraid of? Never mind, this discussion has gone far enough off-topic. -- -- Howard Chu Chief Architect, 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